軟件項目招投標文件技術(shù)標書最全最詳細

1、. 軟件工程招標文件技術(shù)標書(最全最詳細)12.4.2 供給商針對本工程技術(shù)效勞類總體要求的理解 在軟件開發(fā)的過程中，我們一向遵循軟件產(chǎn)品的以下原則: 1、功能性:與一組功能及其指定的性質(zhì)有關(guān)的一組屬性，具體包括: 適合性:與規(guī)定任務(wù)能否提供一組功能以及這組功能的適合程度有關(guān)的軟件屬性 準確性:與能否得到正確或相符的結(jié)果或效果有關(guān)的軟件屬性 互用性:與同其他指定系統(tǒng)進展交互的能力有關(guān)的軟件屬性 依從性:使軟件遵循有關(guān)的標準,約定,法規(guī)及類似規(guī)定的軟件屬性 平安性:與防止對程序及數(shù)據(jù)的非授權(quán)的成心或意外訪問的能力有關(guān)的軟件屬性 2、可靠性:與在規(guī)定的一段時間和條件下,軟件維持其性能水平的能力有關(guān)

2、的一組屬性，具體包括: 成熟性:與由軟件故障引起失效的頻度有關(guān)的軟件屬性 容錯性:與在軟件故障或違反指定接口的情況下,維持規(guī)定的性能水平的能力有關(guān)的軟件屬性 易恢復性:與在失效發(fā)生后,重建其性能水平并恢復直承受影響數(shù)據(jù)的能力以及為達此目的所需的時間和能力有關(guān)的軟件屬性 3、易用性:與一組規(guī)定或潛在的用戶為使用軟件所需作的努力和對這樣的使用所作的評價有關(guān)的一組屬性，具體包括: 易理解性:與用戶為認識邏輯概念及其應(yīng)用圍所花的努力有關(guān)的軟件屬性 易學性:與用戶為學習軟件應(yīng)用所花的努力有關(guān)的軟件屬性 易操作性:與用戶為操作和運行控制所花努力有關(guān)的軟件屬性 4、效率:與在規(guī)定的條件下,軟件的性能水平與所

3、使用資源量之間關(guān)系有關(guān)的一組屬性，具體包括: 時間特性:與軟件執(zhí)行其功能時響應(yīng)和處理時間以及吞吐量有關(guān)的軟件屬性 資源特性:與在軟件執(zhí)行其功能時所使用的資源數(shù)量及其使用時間有關(guān)的軟件屬性 5、可維護性:與進展指定的修改所需的努力有關(guān)的一組屬性，具體包括: 易分析性:與為診斷缺陷或失效原因及為判定待修改的局部所需努力有關(guān)的軟件屬性 易改變性:與進展修改,排除錯誤或適應(yīng)環(huán)境變化所需努力有關(guān)的軟件屬性 穩(wěn)定性:與修改所造成的未預(yù)料結(jié)果的風險有關(guān)的軟件屬性 易測試性:與確認已修改軟件所需的努力有關(guān)的軟件屬性 6、可移植性:與軟件可從*一環(huán)境轉(zhuǎn)移到另一環(huán)境的能力有關(guān)的一組屬性，具體包括: 適應(yīng)性:與軟件

4、無需采用有別于為該軟件準備的活動或手段就可能適應(yīng)不同的規(guī)定環(huán)境有關(guān)的軟件屬性 易安裝性:與在指定環(huán)境下安裝軟件所需努力有關(guān)的軟件屬性 遵循性:使軟件遵循與可移植性有關(guān)的標準或約定的軟件屬性 易替換性:與軟件在該軟件環(huán)境中用來替代指定的其他軟件的時機和努力有關(guān)的軟件屬性 基于以上原則，根據(jù)工程的不同需求，我們將會考慮采用B/S和C/S兩種模式開發(fā)。 1、B/S模式 B/S是Brower/Server的縮寫，客戶機上只要安裝一個瀏覽器(Browser)，如Netscape Navigator或Internet E*plorer，效勞器安裝Oracle、Sybase、Informi*或 SQL Se

5、rver等數(shù)據(jù)庫。瀏覽器通過Web Server 同數(shù)據(jù)庫進展數(shù)據(jù)交互。B/S模式較C/S模式: C/S模式客戶端需要安裝專用的客戶端軟件。首先涉及到安裝的工作量，其次任何一臺電腦出問題，如病毒、硬件損壞，都需要進展安裝或維護。特別是有很多分部的情況，不是工作量的問題，而是路程的問題。還有，系統(tǒng)軟件升級時，每一臺客戶機需要重新安裝，其維護和升級本錢非常高。C/S模式對客戶端的操作系統(tǒng)一般也會有限制，可能適應(yīng)于Windows系列操作系統(tǒng)，而不適用于Linu*、Uni*等操作系統(tǒng)。 而B/S最大的優(yōu)點就是可以在任何地方進展操作而不用安裝任何專門的軟件。只要有一臺能上網(wǎng)的電腦就能使用，客戶端零維護。

6、系統(tǒng)的擴展非常容易，只要能上網(wǎng)，再由系統(tǒng)管理員分配一個用戶名和密碼，就可以使用了。甚至可以在線申請，通過公司部的平安認證(如CA證書)后，不需要人的參與，系統(tǒng)可以自動分配給用戶一個賬號進入系統(tǒng)，這在最大程度上滿足了工程要求。 系統(tǒng)采用的是目前較流行的一種Web應(yīng)用程序開源框架-Struts+Spring+Hibernate(SSH)。 集成SSH框架的系統(tǒng)從職責上分為四層:表示層、業(yè)務(wù)邏輯層、數(shù)據(jù)持久層和域模塊層，以幫助開發(fā)人員在短期搭建構(gòu)造清晰、可復用性好、維護方便的Web應(yīng)用程序。其中使用Struts作為系統(tǒng)的整體根底架構(gòu)，負責MVC的別離，在Struts框架的模型局部，利用Hiberna

7、te框架對持久層提供支持，業(yè)務(wù)層用Spring支持。具體做法是:用面向?qū)ο蟮姆治龇椒ǜ鶕?jù)需求提出一些模型，將這些模型實現(xiàn)為根本的Java對象，然后編寫根本的DAO接口，并給出Hibernate的DAO實現(xiàn)，采用Hibernate架構(gòu)實現(xiàn)的DAO類來實現(xiàn)Java類與數(shù)據(jù)庫之間的轉(zhuǎn)換和訪問，最后由Spring完成業(yè)務(wù)邏輯。 系統(tǒng)的根本業(yè)務(wù)流程是: 在表示層中，首先通過JSP頁面實現(xiàn)交互界面，負責傳送請求(Request)和接收響應(yīng)(Response)，然后Struts根據(jù)配置文件(struts-config.*ml)將ActionServlet接收到的Request委派給相應(yīng)的Action處理。在

8、業(yè)務(wù)層中，管理效勞組件的Spring IoC容器負責向Action提供業(yè)務(wù)模型(Model)組件和該組件的協(xié)作對象數(shù)據(jù)處理(DAO)組件完成業(yè)務(wù)邏輯，并提供事務(wù)處理、緩沖池等容器組件以提升系統(tǒng)性能和保證數(shù)據(jù)的完整性。而在持久層中，則依賴于Hibernate的對象化映射和數(shù)據(jù)庫交互，處理DAO組件請求的數(shù)據(jù)，并返回處理結(jié)果。 采用上述開發(fā)模型，不僅實現(xiàn)了視圖、控制器與模型的徹底別離，而且還實現(xiàn)了業(yè)務(wù)邏輯層與持久層的別離。這樣無論前端如何變化，模型層只需很少的改動，并且數(shù)據(jù)庫的變化也不會對前端有所影響，大大提高了系統(tǒng)的可復用性。而且由于不同層之間耦合度小，有利于團隊成員并行工作，大大提高了開發(fā)效率

9、的同時，也保證了軟件產(chǎn)品的質(zhì)量。 2、C/S模式 C/S (Client/Server，客戶機/效勞器)模式又稱C/S構(gòu)造，是20世紀80年代末逐步成長起來的一種模式，是軟件系統(tǒng)體系構(gòu)造的一種。C/S構(gòu)造的關(guān)鍵在于功能的分布，一些功能放在前端機(即客戶機)上執(zhí)行，另一些功能放在后端機(即效勞器)上執(zhí)行。功能的分布在于減少計算機系統(tǒng)的各種瓶頸問題。C/S模式簡單地講就是基于企業(yè)部網(wǎng)絡(luò)的應(yīng)用系統(tǒng)。與B/S(Browser/Server，瀏覽器/效勞器)模式相比，C/S模式的應(yīng)用系統(tǒng)最大的好處是不依賴企業(yè)外網(wǎng)環(huán)境，即無論企業(yè)是否能夠上網(wǎng)，都不影響應(yīng)用。 C/S構(gòu)造效勞器通常采用高性能的PC、工作站或

10、小型機，并采用大型數(shù)據(jù)庫系統(tǒng)，如ORACLE、SYBASE、InfORMi*或 SQL Server。客戶端需要安裝專用的客戶端軟件。 C/S構(gòu)造的優(yōu)點是能充分發(fā)揮客戶端PC的處理能力，很多工作可以在客戶端處理后再提交給效勞器,因此對應(yīng)的優(yōu)點就是客戶端響應(yīng)速度快。 C/S架構(gòu)軟件的優(yōu)勢與劣勢: (1)應(yīng)用效勞器運行數(shù)據(jù)負荷較輕。最簡單的C/S體系構(gòu)造的數(shù)據(jù)庫應(yīng)用由兩局部組成，即客戶應(yīng)用程序和數(shù)據(jù)庫效勞器程序。二者可分別稱為前臺程序與后臺程序。運行數(shù)據(jù)庫效勞器程序的機器，也稱為應(yīng)用效勞器。一旦效勞器程序被啟動，就隨時等待響應(yīng)客戶程序發(fā)來的請求;客戶應(yīng)用程序運行在用戶自己的電腦上，對應(yīng)于數(shù)據(jù)庫效勞

11、器，可稱為客戶電腦，當需要對數(shù)據(jù)庫中的數(shù)據(jù)進展任何操作時，客戶程序就自動地尋找效勞器程序，并向其發(fā)出請求，效勞器程序根據(jù)預(yù)定的規(guī)則作出應(yīng)答，送回結(jié)果，應(yīng)用效勞器運行數(shù)據(jù)負荷較輕。 (2)數(shù)據(jù)的儲存管理功能較為透明。在數(shù)據(jù)庫應(yīng)用中，數(shù)據(jù)的儲存管理功能，是由效勞器程序和客戶應(yīng)用程序分別獨立進展的，并且通常把那些不同的(不管是還是未知的)前臺應(yīng)用所不能違反的規(guī)則，在效勞器程序中集中實現(xiàn)，例如訪問者的權(quán)限，可以重復、必須有客戶才能建立定單這樣的規(guī)則。所有這些，對于工作在前臺程序上的最終用戶，是透明的，他們無須過問(通常也無法干預(yù))背后的過程，就可以完成自己的一切工作。在客戶效勞器架構(gòu)的應(yīng)用中，前臺程序

12、不是非常瘦小，麻煩的事情都交給了效勞器和網(wǎng)絡(luò)。在C/S體系的下，數(shù)據(jù)庫不能真正成為公共、專業(yè)化的倉庫，它受到獨立的專門管理。 C/S模式系統(tǒng)的開發(fā): C/S構(gòu)造是建立在中間件產(chǎn)品根底之上的，要求應(yīng)用開發(fā)者自己去處理事務(wù)管理、消息隊列、數(shù)據(jù)的復制和同步、通信平安等系統(tǒng)級的問題。這對應(yīng) 用開發(fā)者提出了較高的要求，而且迫使應(yīng)用開發(fā)者投入很多精力來解決應(yīng)用程序以外的問題。這使得應(yīng)用程序的維護、移植和互操作變得復雜。如果客戶端是在不同的操作系統(tǒng)上，C/S構(gòu)造的軟件需要開發(fā)不同版本的客戶端軟件。但是，與B/S構(gòu)造相比，C/S技術(shù)開展歷史更為悠久。從技術(shù)成熟度及軟件設(shè)計、開發(fā) 人員的掌握水平來看，C/S技術(shù)

13、應(yīng)是更成熟、更可靠的。 12.4.3 工程總體架構(gòu)及技術(shù)解決方案 一、工程總體架構(gòu) (一)、SSH框架介紹和分析 大型企業(yè)級Web應(yīng)用系統(tǒng)的開發(fā)通常要求有一個良好的軟件架構(gòu)、便于協(xié)作開發(fā)和擴展升級，而傳統(tǒng)的開發(fā)模式不能很好地滿足這些要求。 基于當前Web應(yīng)用程序開發(fā)面臨的問題，工程結(jié)合目前比擬流行的開源框架SSH(Spring、Struts、Hibernate)，具體討論其根本相似性及有關(guān)根本概念，提出了一種開發(fā)JavaEE Web應(yīng)用的輕量級解決方案，此系統(tǒng)架構(gòu)可以在短期搭建構(gòu)造清晰、可復用性好、可擴展性好、維護方便的Web應(yīng)用程序。 1、框架技術(shù) 框架一般具有即插即用的可重用性、成熟的穩(wěn)定

14、性以及良好的團隊協(xié)作性。JavaEE復雜的多層構(gòu)造決定了大型的JavaEE工程需要運用框架和設(shè)計模式來控制軟件質(zhì)量。目前，市場上出現(xiàn)了一些商業(yè)的、開源的基于JavaEE的應(yīng)用框架，其中主流的框架技術(shù)有:基于MVC模式的Struts框架、基于IoC模式的Spring框架以及對象/關(guān)系映射框架Hibernate等。 2、框架共同點 所有現(xiàn)代的網(wǎng)絡(luò)開發(fā)框架幾乎都遵循了模型-視圖-控制(MVC)設(shè)計模式:商業(yè)邏輯和描述被分開，由一個邏輯流控制器來協(xié)調(diào)來自客戶端的請求和效勞器上將采取的行動。這條途徑成為了網(wǎng)絡(luò)開發(fā)的事實上的標準。每個框架的在的機制當然是不同的，但是開發(fā)者們使用來設(shè)計和實現(xiàn)他們的Web應(yīng)用

15、軟件的API是很類似的。差異還存在于每個框架提供的擴展方面,例如標簽庫，JavaBean包裝器等。 所有的框架使用不同的技術(shù)來協(xié)調(diào)在Web應(yīng)用程序之的導航,例如*ML配制文件，java屬性文件或定制屬性。所有的框架在控制器模塊實現(xiàn)的方法方面也存在明顯的不同。例如,E可能實例化在每個請求中需要的類或使用Java反射動態(tài)地調(diào)用一個適當?shù)男袨?Action)類。另外,不同框架在各自引入的概念上也有所不同。例如,一個框架可能定義用戶請求和反響場所，而另外一個框架可能僅僅定義一個完整的流:從一個請求到多個響答和隨后的再請求。 各種Java框架在它們組織數(shù)據(jù)流的方法方面是很類似的。在請求發(fā)出后，在應(yīng)用程序

16、效勞器上產(chǎn)生一些行動;而作為響應(yīng)，一些可能包含對象集的數(shù)據(jù)總是被發(fā)送到WEB層。然后從那些對象:可能是有setter和getter方法的簡單類、JAVABEANS、值對象、或者一些集合對象中提取數(shù)據(jù)。現(xiàn)代的Java框架還想方設(shè)法簡化開發(fā)者的開發(fā)任務(wù)，如通過使用簡易的API、數(shù)據(jù)庫連接池、甚至數(shù)據(jù)庫調(diào)用包等提供自動化的追蹤方式來實現(xiàn)。一些框架或者能夠鉤進(hooked into)另外的JavaEE技術(shù)中,例如JMS(Java消息效勞)或JM*,或把這些技術(shù)集成到一起。效勞器數(shù)據(jù)持續(xù)性和日志也有可能成為框架的一局部。 3、MVC模式 MVC模式是一個用于將用戶界面邏輯與業(yè)務(wù)邏輯別離開來的根底設(shè)計模

17、式，它將數(shù)據(jù)處理、界面以及用戶的行為控制分為:Model(模型),View(視圖),Controller(控制器)。 Model:負責當前應(yīng)用的數(shù)據(jù)獲取與變更及相關(guān)的業(yè)務(wù)邏輯?？捎肑AVABEAN來表達; View:負責顯示信息。可以使用JSP、VELOCITY模板等技術(shù); Controller:負責收集轉(zhuǎn)化用戶的輸入。常用一個SERVLET來實現(xiàn); View和Controller都依賴于Model，但是Model既不依賴于View，也不依賴于Controller，這是別離的主要優(yōu)點之一，這樣Model可以單獨的建立和測試以便于代碼復用，View和Controller只需要Model提供數(shù)據(jù)，

18、它們不會知道、也不會關(guān)心數(shù)據(jù)是存儲在SQL Server還是Oracle數(shù)據(jù)庫中或者別的什么地方。 4、 WEB層框架Struts Struts是一個在JSP Model2根底上實現(xiàn)的MVC框架，其主要的設(shè)計理念是通過控制器將表現(xiàn)邏輯和業(yè)務(wù)邏輯解耦，以提高系統(tǒng)的可維護性、可擴展性及可重用性。Struts框架的體系構(gòu)造如下列圖所示: 下面就上圖所示的體系構(gòu)造圖分析Struts框架中的MVC組件。 , 視圖(view):視圖局部主要由JSP頁面組成，其中沒有流程邏輯、業(yè)務(wù)邏輯和模型信息，只有標記。Struts自身包含了一組標記庫(TagLib)，這也是Struts的精華之一，靈活運用它們可以簡化J

19、SP頁面的代碼，提高開發(fā)效率。 , 控制器(controller):Struts中的Controller主要是其自身提供的ActionServlet。ActionServlet接收所有來自客戶端的請求并根據(jù)配置文件(struts-config.*ml)中的定義將控制轉(zhuǎn)移到適當?shù)腁ction對象。 , 模型(model):Struts沒有定義具體Model層的實現(xiàn)，Model層通常是和業(yè)務(wù)邏輯嚴密相關(guān)的，有持續(xù)化的要求。目前在商業(yè)領(lǐng)域和開源世界，都有一些優(yōu)秀的工具可以為Model層的開發(fā)提供便利。 、業(yè)務(wù)邏輯層框架Spring 5Spring是一個解決了許多JavaEE開發(fā)中常見問題并能夠替代E

20、技術(shù)的強大的輕量級框架。這里所說的輕量級指的是Spring框架本身，而不是指Spring只能用于輕量級的應(yīng)用開發(fā)。Spring的輕盈表達在其框架本身的根底構(gòu)造以及對其他應(yīng)用工具的支持和裝配能力。與E這種龐然大物相比，Spring可使程序研發(fā)人員把各個技術(shù)層次之間的風險降低。 Spring框架的核心是控制翻轉(zhuǎn)IoC(Inversion of Control)/依賴注入DI(Dependence Injection)機制。IoC是指由容器中控制組件之間的關(guān)系(這里，容器是指為組件提供特定效勞和技術(shù)支持的一個標準化的運行時的環(huán)境)而非傳統(tǒng)實現(xiàn)中由程序代碼直接操控，這種將控制權(quán)由程序代碼到外部容器的轉(zhuǎn)

21、移，稱為翻轉(zhuǎn)。DI是對IoC更形象的解釋，即由容器在運行期間動態(tài)地將依賴關(guān)系(如構(gòu)造參數(shù)、構(gòu)造對象或接口)注入到組件之中。Spring采用設(shè)值注入(使用Setter方法實現(xiàn)依賴)和構(gòu)造子注入(在構(gòu)造方法中實現(xiàn)依賴)的機制，通過配置文件管理組建的協(xié)作對象，創(chuàng)立可以構(gòu)造組件的IoC容器。這樣，不需要編寫工廠模式、單例模式或者其他構(gòu)造的方法，就可以通過容器直接獲取所需的業(yè)務(wù)組件。Spring框架的構(gòu)造如下列圖所示。 Spring框架由七個定義明確的模塊組成，且每個模塊或組件都可以單獨存在，或者與其他一個或多個模塊聯(lián)合實現(xiàn)。Spring Core Container是一個用來管理業(yè)務(wù)組件的IoC容器，

22、是Spring應(yīng)用的核心;Spring DAO和Spring ORM不僅提供數(shù)據(jù)訪問的抽象模塊，還集成了對Hibernate、JDO和iBatis等流行的對象關(guān)系映射框架的支持模塊，并且提供了緩沖連接池、事務(wù)處理等重要的效勞功能，保證了系統(tǒng)的性能和數(shù)據(jù)的完整性;Sprnig Web模塊提供了Web應(yīng)用的一些抽象封裝，可以將Struts、Webwork等Web框架與Spring整合成為適用于自己的解決方案。 Spring框架可以成為企業(yè)級應(yīng)用程序一站式的解決方案，同時它也是模塊化的框架，允許開發(fā)人員自由地挑選適合自己應(yīng)用的模塊進展開發(fā)。Spring框架式是一個松耦合的框架，框架的局部耦合度被設(shè)計

23、為最小，在各個層次上具體選用哪個框架取決于開發(fā)者的需要。 6、持久層框架Hibernate O/R mapping技術(shù)是為了解決關(guān)系型數(shù)據(jù)庫和面向?qū)ο蟮某绦蛟O(shè)計之間不匹配的矛盾而產(chǎn)生的。Hibernate是目前最為流行的O/R mapping框架，它也是開源軟件,它在關(guān)系型數(shù)據(jù)庫和Java對象之間做了一個自動映射，使得程序員可以以非常簡單的方式實現(xiàn)對數(shù)據(jù)庫的操作，它不僅負責從Java類到數(shù)據(jù)庫表格(以及來自Java數(shù)據(jù)類型的SQL數(shù)據(jù)類型)的映射,而且還提供數(shù)據(jù)查詢和檢索能力，并能大大減少花在SQL和JDBC手工數(shù)據(jù)處理上的開發(fā)時間。Hibernate工作原理如下列圖所示: Hibernate

24、通過對JDBC的封裝，向程序員屏蔽了底層的數(shù)據(jù)庫操作，使程序員專注于OO程序的開發(fā)，有助于提高開發(fā)效率。程序員訪問數(shù)據(jù)庫所需要做的就是為持久化對象編制*ml映射文件。 底層數(shù)據(jù)庫的改變只需要簡單地更改初始化配置文件(hibernate.cfg.*ml或者perties)即可，不會對應(yīng)用程序產(chǎn)生影響。 Hibernate有自己的面向?qū)ο蟮牟樵冋Z言HQL，HQL功能強大，支持目前大局部主流的數(shù)據(jù)庫，如Oracle、DB2、MySQL、Microsoft SQL Server等，是目前應(yīng)用最廣泛的O/R映射工具。Hibernate為快速開發(fā)應(yīng)用程序提供了底層的支持。 (二)

25、、基于SSH框架的Web應(yīng)用架構(gòu)分析與設(shè)計 前面分析了基于JavaEE的SSH框架技術(shù)，現(xiàn)代的企業(yè)開發(fā)中，越來越多地引入了多層架構(gòu)設(shè)計模式。SSH就是其中之一，SSH架構(gòu)是當前主流的架構(gòu)，在很多領(lǐng)域，包括金融、電信工程，大型門戶均選擇該架構(gòu)作為業(yè)務(wù)支撐架構(gòu)，開發(fā)流程也已經(jīng)非常成熟。但是該構(gòu)造開發(fā)起來，依舊存在一些問題。分析這些問題，得先從SSH架構(gòu)的組成說起。 SSH為Struts+Spring+Hibernate的組成方式，Struts實現(xiàn)MVC，Spring負責架構(gòu)的結(jié)合，Hibernate進展數(shù)據(jù)的持久化。通常其分層開發(fā)的構(gòu)造圖如下: 這樣的構(gòu)造，系統(tǒng)從職責上分為四層:WEB層、業(yè)務(wù)邏輯

26、層、數(shù)據(jù)持久層和實體層。其中使用Struts作為系統(tǒng)的整體根底架構(gòu)，負責MVC的別離，在Struts框架的模型局部，利用Hibernate框架對持久層提供支持，業(yè)務(wù)層用Spring支持。具體做法是:用面向?qū)ο蟮姆治龇椒ǜ鶕?jù)需求提出一些模型，將這些模型實現(xiàn)為根本的Java對象，然后編寫根本的DAO接口，并給出Hibernate的DAO實現(xiàn)，采用Hibernate架構(gòu)實現(xiàn)的DAO類來實現(xiàn)Java類與數(shù)據(jù)庫之間的轉(zhuǎn)換和訪問，最后由Spring完成業(yè)務(wù)邏輯。 系統(tǒng)的根本業(yè)務(wù)流程是:在WEB表示層中，首先通過JSP頁面實現(xiàn)交互界面，負責傳送請求(Request)和接收響應(yīng)(Response)，然后Str

27、uts根據(jù)配置文件(struts-config.*ml)將ActionServlet接收到的Request委派給相應(yīng)的Action處理。在業(yè)務(wù)層中，管理效勞組件的Spring IoC容器負責向Action提供業(yè)務(wù)模型(Model)組件和該組件的協(xié)作對象數(shù)據(jù)處理(DAO)組件完成業(yè)務(wù)邏輯，并提供事務(wù)處理、緩沖池等容器組件以提升系統(tǒng)性能和保證數(shù)據(jù)的完整性。而在持久層中，則依賴于Hibernate的對象化映射和數(shù)據(jù)庫交互，處理DAO組件請求的數(shù)據(jù)，并返回處理結(jié)果。 采用上述開發(fā)模型，不僅實現(xiàn)了視圖、控制器與模型的徹底別離，而且還實現(xiàn)了業(yè)務(wù)邏輯層與持久層的別離。這樣無論前端如何變化，模型層只需很少的改

28、動，并且數(shù)據(jù)庫的變化也不會對前端有所影響，大大提高了系統(tǒng)的可復用性。而且由于不同層之間耦合度小，有利于團隊成員并行工作，大大提高了開發(fā)效率。 但是對于當前日益復雜化的WEB2.0的開發(fā)，卻存在不少問題，歸納起來主要有以下的缺乏: , DAO和效勞層容易出現(xiàn)職責不明，由于按照MVC邏輯，業(yè)務(wù)代碼應(yīng)該寫在Struts Action里，但是其事務(wù)的提供，卻是配置在Service層。為了一組在邏輯上完整的數(shù)據(jù)操作業(yè)務(wù)邏輯，需要涉及兩個層(Service、Action)來進展編寫，遇到判斷的情況下，為了保證完整的事務(wù)操作，則需要將業(yè)務(wù)代碼移到Service層完成，而通常習慣了在Struts Action

29、里調(diào)用屢次Service而產(chǎn)生多個事務(wù),但在出現(xiàn)E*ception導致出錯時,操作之前調(diào)用的Service事務(wù)的業(yè)務(wù)數(shù)據(jù)沒有被回滾。 , 當需要返回的數(shù)據(jù)供AJA*使用，操作JSON或*ML的大量使用時。開發(fā)起來會很費力，一段同樣的業(yè)務(wù)代碼，為了使用AJA*和*ML可能需要重新編寫一次，或者在同一個ACTION里通過標志來判斷，對分層構(gòu)造造成了比擬糟糕的破壞。如果設(shè)計得不好，為了使用JSON和*ML還得額外增加大量的配置，嚴重降低了開發(fā)效率。 因此，為了克制這些缺點，對于SSH架構(gòu)，進展了重新的分層，共享了業(yè)務(wù)代碼。簡化了開發(fā)、增強了與AJA*技術(shù)、*ML技術(shù)的結(jié)合。提供了一種更高效的開發(fā)模式

30、。 其開發(fā)的構(gòu)造圖如下: 這個架構(gòu)的優(yōu)點在于，由于業(yè)務(wù)代碼統(tǒng)一實現(xiàn)BusinessService接口，使得只需要相對固定的幾個Struts Action類調(diào)用Service層的方法，便可以完成工作。包括JSON格式輸出，*ML輸出及WebService輸出均調(diào)用Service層方法來完成功能。這樣便實現(xiàn)了業(yè)務(wù)代碼的別離，以及與前端框架的極大解耦。 二、技術(shù)解決方案 開發(fā)一款好的軟件產(chǎn)品，離不開一個好的開發(fā)過程。開發(fā)期間對過程的把控程度，往往會決定軟件產(chǎn)品的質(zhì)量好壞。因此，開發(fā)前期的方案流程是必不可少的。 本公司軟件系統(tǒng)的開發(fā)是按階段進展的，一般劃分為以下階段:項 目 可行性分析 可行性研究報告

31、 需求分析 軟件需求說明書 概要設(shè)計 概要設(shè)計說明書 詳細設(shè)計 數(shù)據(jù)庫設(shè)計說明書 編碼 詳細設(shè)計說明書 測試 測試方案 修改完善 測試分析報告 驗收 驗收報告 維護 用戶操作手冊 1、可行性分析 可行性分析的目的是明確系統(tǒng)的目的、功能和要求，了解目前所具備的開發(fā)環(huán)境和條件，分析的容有: 在技術(shù)能力上是否可以支持 在經(jīng)濟上效益如何 在法律上是否符合要求 與部門、企業(yè)的經(jīng)營和開展是否吻合 系統(tǒng)投入運行后的維護有無保障 可行性討論的目的是判定軟件系統(tǒng)的開發(fā)有無價值，分析和討論的容形成系統(tǒng)開發(fā)方案書，主要容有: (1) 開發(fā)的目的及所期待的效果 (2) 系統(tǒng)的根本設(shè)想，涉及的業(yè)務(wù)對象和圍 (3) 開發(fā)

32、進度表，開發(fā)組織構(gòu)造 (4) 開發(fā)、運行的費用 (5) 預(yù)期的系統(tǒng)效益 (6) 開發(fā)過程中可能遇到的問題及考前須知。 2、需求分析 需求分析是軟件系統(tǒng)開發(fā)中最重要的一個階段，直接決定著系統(tǒng)的開發(fā)質(zhì)量和成敗。因此必須要明確用戶的要求和應(yīng)用現(xiàn)場環(huán)境的特點，了解系統(tǒng)應(yīng)具有哪些功能、數(shù)據(jù)的流程和數(shù)據(jù)之間的聯(lián)系。 需求分析應(yīng)有用戶參加，到使用現(xiàn)場進展調(diào)研學習，軟件設(shè)計人員應(yīng)虛心向技術(shù)人員和使用人員請教，共同討論解決需求問題的方法，對調(diào)查結(jié)果進展分析，明確問題的所在。 需求分析階段的工作,可以分為四個方面:問題識別,分析與綜合,制訂規(guī)格說明,評審。 (一)、問題識別 從系統(tǒng)角度來理解軟件,確定對所開發(fā)系統(tǒng)

33、的綜合要求,并提出這些需求的實現(xiàn)條件,以及需求應(yīng)該到達的標準。這些需求包括:功能需求(做什么),性能需求(要到達什么指標),環(huán)境需求(如機型,操作系統(tǒng)等),可靠性需求(不發(fā)生故障的概率),平安需求,用戶界面需求,資源使用需求(軟件運行是所需的存,CPU等),軟件本錢消耗與開發(fā)進度需求,預(yù)先估計以后系統(tǒng)可能到達的目標。 (二)、分析與綜合 逐步細化所有的軟件功能,找出系統(tǒng)各元素間的聯(lián)系,接口特性和設(shè)計上的限制,分析他們是否滿足需求,剔除不合理局部,增加需要局部。最后,綜合成系統(tǒng)的解決方案,給出要開發(fā)的系統(tǒng)的詳細邏輯模型(做什么的模型)。 (三)、制訂規(guī)格說明書 即編制文檔,描述需求的文檔稱為軟件

34、需求規(guī)格說明書。 (四)、評審 對功能的正確性,完整性和清晰性,以及其它需求給予評價。評審通過才可進展下一階段的工作,否則重新進展需求分析。 需求分析的容最終會編寫成系統(tǒng)需求分析報告。 3.系統(tǒng)設(shè)計 (一)、設(shè)計原則和設(shè)計要求 描述對本軟件系統(tǒng)進展概要設(shè)計的原則，通常可以考慮以下幾方面的容: 1、命名規(guī)則; 2、模塊獨立性原則; 3、邊界設(shè)計原則; 4、數(shù)據(jù)庫設(shè)計規(guī)則; 5、必須的平安措施; 6、平安性和原則; 7、系統(tǒng)靈活性要求; 8、系統(tǒng)易操作性要求; 9、系統(tǒng)可維護性要求; (二)、系統(tǒng)邏輯設(shè)計 系統(tǒng)邏輯設(shè)計主要是根據(jù)軟件產(chǎn)品需求規(guī)格說明書和軟件產(chǎn)品數(shù)據(jù)字典建立系統(tǒng)的邏輯模型。此種模型暫

35、時與系統(tǒng)的物理因素(例如:計算機、數(shù)據(jù)庫管理系統(tǒng))無關(guān)。它是系統(tǒng)需求與物理實現(xiàn)的中間構(gòu)造，它的主要結(jié)果是建立:系統(tǒng)構(gòu)造圖、系統(tǒng)界面構(gòu)造圖、系統(tǒng)出錯處理、以及系統(tǒng)開發(fā)技術(shù)說明。 (三)、系統(tǒng)組織設(shè)計 系統(tǒng)組織設(shè)計通過系統(tǒng)組織表描述本系統(tǒng)由哪些子系統(tǒng)(模塊)組成，這些子系統(tǒng)與業(yè)務(wù)職能之間的關(guān)系，以及各個子系統(tǒng)的安裝地點。系統(tǒng)組織表的格式如下: 子系統(tǒng) 英文名稱 中文名稱 業(yè)務(wù)職能 安裝地點 備注 其中: 1、子系統(tǒng) 給出本系統(tǒng)中指定子系統(tǒng)的順序。如果本系統(tǒng)末劃分為多個子系統(tǒng)，僅由一個運行模塊組成;則本項容仍需要描述，但是本表容只有一行。 在一個系統(tǒng)中有可能安裝假設(shè)干個一樣的子系統(tǒng)，在這種情況下，應(yīng)

36、該視為一個子系統(tǒng)，并且對多個安裝地點分別進展描述。如果一樣的子系統(tǒng)通過系統(tǒng)設(shè)置，實現(xiàn)的業(yè)務(wù)職能具有明顯差異時，應(yīng)該采用多行進展分別描述，并且在備注中說明其差異所在。 2、子系統(tǒng)英文名稱 給出本子系統(tǒng)的英文名稱，該名稱是在應(yīng)用軟件中實際使用的可執(zhí)行文件名稱，必須能夠說明該子系統(tǒng)的特點。 假設(shè)本系統(tǒng)中只有一個子系統(tǒng)，則本項容仍需要描述，但是本表容只有一行。 3、子系統(tǒng)中文名稱 給出本子系統(tǒng)的中文名稱，該名稱必須能夠說明該子系統(tǒng)的特點。 假設(shè)本系統(tǒng)中只有一個子系統(tǒng)，則本項容仍需要描述，但是本表容只有一行。 4、業(yè)務(wù)職能 描述該子系統(tǒng)完成的核心業(yè)務(wù)。 5、安裝地點 描述該子系統(tǒng)實際安裝的部門、或者*個

37、具體地點。 6、備注 針對該子系統(tǒng)，需要說明的其它有關(guān)問題。 (四)、系統(tǒng)構(gòu)造設(shè)計 1、系統(tǒng)特性表 系統(tǒng)特性是系統(tǒng)中完成*項具體操作的根本單元，它由入口參數(shù)，出口參數(shù)以及處理過程三局部組成。系統(tǒng)特性可以具有操作界面，也可以沒有操作界面;可以被其它操作界面、或者系統(tǒng)特性調(diào)用，也可以調(diào)用其它操作界面、非操作界面、或者系統(tǒng)特性;但是不允許遞歸調(diào)用(調(diào)用自己)，包括間接遞歸調(diào)用。 當系統(tǒng)由多個子系統(tǒng)(模塊)組成時，每個子系統(tǒng)分別使用一系統(tǒng)特性表進展描述。系統(tǒng)特性表的格式如下: 子系統(tǒng): 子系統(tǒng)英文名稱: 子系統(tǒng)中文名稱: 特性 系統(tǒng)特征 系統(tǒng)特征 操作功能 調(diào)用對象 被調(diào)用對象 備注 英文名稱 中文名

38、稱 說明: 其中: (1)、子系統(tǒng) 含義同上。 (2)、子系統(tǒng)英文名稱 含義同上。 (3)、子系統(tǒng)中文名稱 含義同上。 (4)、特性 整個系統(tǒng)所有特性的統(tǒng)一。 (5)、系統(tǒng)特性英文名稱 系統(tǒng)特性的英文正式名稱，將來用于軟件開發(fā)中，必須符合命名規(guī)。 (6)、系統(tǒng)特性中文名稱 系統(tǒng)特性的中文正式名稱，來源于需求規(guī)格說明書中，系統(tǒng)特性一節(jié)中的有關(guān)描述。 (7)、操作功能 是指該特性實際完成的操作說明。 (8)、調(diào)用對象 是指調(diào)用該系統(tǒng)特性的系統(tǒng)對象，這里的系統(tǒng)對象可以是系統(tǒng)特性、也可以是操作界面。 (9)、被調(diào)用對象 是指被該系統(tǒng)特性調(diào)用的系統(tǒng)對象，這里的系統(tǒng)對象可以是系統(tǒng)特性、也可以是操作界面。

39、(10)、備注 描述與該系統(tǒng)特性有關(guān)的其它考前須知。 (11)、說明 描述與該系統(tǒng)特性表有關(guān)的其它考前須知。 (五)、系統(tǒng)接口設(shè)計 1、系統(tǒng)接口表 接口作為系統(tǒng)的一種輸入,輸出形式，分為網(wǎng)絡(luò)接口、數(shù)據(jù)庫接口、RS-232串行通485串行總線接口、并行I/O接口等等多種類型。 訊接口、IEEE當系統(tǒng)由多個子系統(tǒng)(模塊)組成時，每個子系統(tǒng)分別使用一系統(tǒng)接口表進展描述。系統(tǒng)接口表的格式如下: 子系統(tǒng) 子系統(tǒng)英文名稱 子系統(tǒng)中文名稱 接口 接口名稱 接口類型 接口性質(zhì) 接口速率 接口協(xié)議 備注 說明: 其中: (1)、子系統(tǒng) 含義同上。 (2)、子系統(tǒng)英文名稱 含義同上。 (3)、子系統(tǒng)中文名稱 含義

40、同上。 (4)、接口 整個系統(tǒng)所有接口的統(tǒng)一。 (5)、接口名稱 系統(tǒng)接口的正式名稱，必須符合通常習慣。 (6)、接口類型 指出該接口所傳輸?shù)臄?shù)據(jù)在該模塊中起到的作用。 (7)、接口性質(zhì) 指出該接口在通訊中起到的作用，這里的作用可以是:輸入、輸出、雙向。 (8)、接口速率 指出該接口的傳輸速率。如果該接口依賴于其它通訊方式，則傳輸速率將不高于它所依賴的其它通訊方式的速率。 (9)、接口協(xié)議 給出該接口實際使用的通訊協(xié)議。 10)、相關(guān)對象 (給出直接使用本接口的系統(tǒng)對象，這里的系統(tǒng)對象，可以是操作界面，也可以是系統(tǒng)特性。 (11)、備注 描述與該系統(tǒng)接口有關(guān)的其它考前須知。 (12)、說明 描

41、述與該系統(tǒng)接口表有關(guān)的其它考前須知。 (六)、系統(tǒng)完整性設(shè)計 描述系統(tǒng)對象(數(shù)據(jù)元、數(shù)據(jù)類)，所受到的邏輯約束關(guān)系。 當系統(tǒng)由多個子系統(tǒng)(模塊)組成時，每個子系統(tǒng)應(yīng)分別使用一系統(tǒng)完整性約束表進展描述。系統(tǒng)完整性約束表的格式如下: 子系統(tǒng) 子系統(tǒng)英文名稱 子系統(tǒng)中文名稱 約束 完整性名稱 相對對象名 約束表達式 備注 說明: 其中: (1)、子系統(tǒng) 含義同上。 (2)、子系統(tǒng)英文名稱 含義同上。 (3)、子系統(tǒng)中文名稱 含義同上。 (4)、約束 整個系統(tǒng)所有約束的統(tǒng)一。 (5)、完整性名稱 系統(tǒng)完整性約束的正式名稱，必須符合通常習慣。 6)、相對對象名 (完整性約束中的相關(guān)對象(數(shù)據(jù)元和數(shù)據(jù)類)

42、。 7)、約束表達式 (用一階邏輯表達式表達的約束方程式。 (8)、備注 描述與該系統(tǒng)完整性約束有關(guān)的其它考前須知。 (9)、說明 描述與該系統(tǒng)完整性約束表有關(guān)的其它考前須知。 系統(tǒng)設(shè)計具體可根據(jù)系統(tǒng)的規(guī)模分成概要設(shè)計和詳細設(shè)計兩個階段，概要設(shè)計包括: 劃分系統(tǒng)模塊 每個模塊的功能確定 用戶使用界面概要設(shè)計 輸入輸出數(shù)據(jù)的概要設(shè)計 報表概要設(shè)計 數(shù)據(jù)之間的聯(lián)系、流程分析 文件和數(shù)據(jù)庫表的邏輯設(shè)計 硬件、軟件開發(fā)平臺確實定 有規(guī)律數(shù)據(jù)的規(guī)化及數(shù)據(jù)惟一性要求。 系統(tǒng)的詳細設(shè)計是對系統(tǒng)的概要設(shè)計進一步具體化，其主要工作有: 文件和數(shù)據(jù)庫的物理設(shè)計 輸入輸出記錄的方案設(shè)計 對各子系統(tǒng)的處理方式和處理容

43、進展細化設(shè)計 編制程序設(shè)計任務(wù)書。 程序說明書通常包括程序規(guī)、功能說明、程序構(gòu)造圖，通常用HPIPO(Hierarchy Plus Input Process Output)圖描述。 4、編碼 根據(jù)程序設(shè)計任務(wù)書的要求，用計算機算法語言實現(xiàn)解題的步驟，主要工作包括: 模塊的理解和進一步劃分 以模塊為單位的邏輯設(shè)計，也就是模塊的流程圖的編制 編寫代碼，用程序設(shè)計語言編制程序 進展模塊功能的測試、單元測試。 程序質(zhì)量的要求包括: 滿足要求確實切功能 處理效率高 操作方便，用戶界面友好 程序代碼的可讀性好，函數(shù)、變量標識符合規(guī) 擴大性、維護性好。 降低程序的復雜性也是十分重要的，系統(tǒng)的復雜性由模塊間

44、的接口數(shù)來衡量，一般地講，n 個模塊的接口數(shù)的最大值為n(n-1)/2;假設(shè)是層次構(gòu)造，n 個模塊的接口數(shù)的最小值為n-1。為使復雜性最小，對模塊的劃分設(shè)計常常采用層次構(gòu)造。 要注意編制的程序或模塊應(yīng)容易理解、容易修改，模塊應(yīng)相互獨立，對*一模塊的修改應(yīng)對其他模塊的功能不產(chǎn)生影響，模塊間的聯(lián)系盡可能少。 5.系統(tǒng)測試 測試是為了發(fā)現(xiàn)程序中的錯誤，對于設(shè)計的軟件，出現(xiàn)錯誤是難免的。系統(tǒng)測試通常由經(jīng)歷豐富的設(shè)計人員設(shè)計測試方案和測試樣品，并寫出測試過程的詳細報告。系統(tǒng)測試是在單元測試的根底上進展的，包括: 測試方案的設(shè)計; 進展測試; 寫出測試報告; 用戶對測試結(jié)果進展評價。 具體測試方式如下:

45、1. 黑盒測試 黑盒測試也稱為功能測試,它著眼于程序的外部特征,而不考慮程序的部邏輯構(gòu)造。測試者把被測程序看成一個黑盒,不用關(guān)心程序的部構(gòu)造。黑盒測試是在程序接口處進展測試，它只檢查程序功能是否能正常使用，程序是否能接收輸入數(shù)據(jù)產(chǎn)生正確的輸出信息，并且保持外部信息(如數(shù)據(jù)庫或文件)的完整性。黑盒測試是基于用戶角度進展的測試。 2. 白盒測試 本公司系統(tǒng)軟件測試的主要方法之一，也稱構(gòu)造測試、邏輯驅(qū)動測試或基于程序本身的測試。測試者需要了解待測試程序代碼的部構(gòu)造、算法等信息，這是從程序設(shè)計者的角度對程序進展的測試。它的優(yōu)點是幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質(zhì)量，發(fā)現(xiàn)代碼中隱藏的問題。

46、3. 灰盒測試 可以理解為靜態(tài)的白盒測試或動態(tài)的黑盒測試，灰盒就是界于黑白之間, 對軟件部有所了解, 但不見得到了如指掌的程度, 卻可以結(jié)合這些了解做些比黑盒多點的測試。 4. 文檔測試 文檔測試涵蓋面很大，在軟件的各個版本中均有所使用。隨著軟件版本的變化，文檔測試的測試容也有所變化。在需求分析以及原型架構(gòu)階段，文檔測試主要目標是: Sitemap、動作分解列表、數(shù)據(jù)庫ER圖、UML用例圖、流程圖、需求文檔等文檔。 文檔測試主要檢查文檔的正確性、完整性和可理解性。正確性是指不要把軟件的功能和操作寫錯，也不允許文檔容前后矛盾。完整性是指文檔不可以漏掉關(guān)鍵性容。可理解性是指在文檔中描述的語言要簡明

47、易懂，不能讓別的開發(fā)人員拿到文檔時看不懂文檔的容。 5. 命名規(guī)測試 命名規(guī)測試用于測試工程中的文件命名、代碼以及版本號等書寫是否符合規(guī)。 6. 需求完整性測試 需求完整性測試主要存在于需求探索階段，在需求尚未完全明確之前對已收集到的需求做出整理性的、檢查遺漏性的測試，確認需否明確。另外，需求完整性測試也承當著一局部澄清需求的任務(wù)。 7. 完整性測試 在原型架構(gòu)階段，完整性的測試是非常有必要的。該項測試任務(wù)主要是檢查假頁面中各種是否完整，是否指向目標位置，屬于檢查性的測試。 8. 頁面完整性測試 頁面完整性測試主要存在于集成測試階段以及其后續(xù)其它階段中，測試頁面是否完整，頁面質(zhì)量是否達標，屬于

48、檢查性測試。 9. UI合理性測試 UI合理性測試也就是人機交互界面的合理性，UI合理性測試的容很多，具體測試容如下: o 提示、菜單、幫助的格式是否一致; o 提示、菜單、幫助中的術(shù)語是否一致; o 各個控件之間的對齊方式是否一致; o 輸入界面和輸出界面在外觀、布局、交互方式上是否一致; o 功能類似的相關(guān)界面在外觀、布局、交互方式上是否一致; o 同一層次的文字在同一種提示場合(一般情況、特殊字體、警告等)在文字大小、字體、顏色、對齊方式方面是否一致，字體大小 是否與界面的大小比例協(xié)調(diào); o 多個連續(xù)界面依次出現(xiàn)的情況下，界面的外觀、操作方式是否一致; o 系統(tǒng)是否拒絕客戶的錯誤輸入并做

49、出提示; o 系統(tǒng)是否在用戶完成操作時給出操作成功的提示; o 用戶界面是否存在空白空間，沒有空白空間的界面是雜亂無章的，易用性差; o 各個控件的間隔是否一致，垂直和水平方向上是否對齊; o 是否允許動作的可逆性，返回原有操做; 10. 數(shù)據(jù)和數(shù)據(jù)庫完整性測試 在開發(fā)階段開發(fā)人員隨時都有可能根據(jù)需要來修改數(shù)據(jù)庫，所以對數(shù)據(jù)和數(shù)據(jù)庫完整性測試在軟件工程的任何階段也是非常必要的。該項測試容主要是以數(shù)據(jù)庫表為單位，檢查數(shù)據(jù)庫表以及表中各字段命名是否符合命名規(guī)，表中字段是否完整，數(shù)據(jù)庫表中的字段描述是否正確包括字段的類型、長度、是否為空，數(shù)據(jù)庫表中的關(guān)系、索引、主鍵、約束是否正確。 11. 功能測試

50、 功能測試在軟件工程的任何階段中都是重要的。實現(xiàn)功能，滿足客戶需軟件本身最大的使命。功能測試在任何階段下根本上都作為測試工作的第一項出現(xiàn)。該項測試任務(wù)主要為了測試已實現(xiàn)的功能是否滿足需求，是否正確，是否有價值以及是否完整。在黑盒和白盒測試狀態(tài)下，該測試均會被使用。 功能測試中測試人員往往會忽略掉一些細節(jié)問題，比方:一個功能的實現(xiàn)必須要經(jīng)過6步操作才能完成，而且需要參加20條信息才能看得出測試結(jié)果，有的測試人員為了節(jié)省時間雖然做完了6步操作，但是沒有參加足量的信息,使得測試不全面,正是因為這樣而導致一些隱藏的BUG沒有被測試出來。所以說在功能測試中要按部就班的把所有要進展的測試功能每一步都執(zhí)行一

51、遍，應(yīng)該添加的數(shù)據(jù)都添加完整，以防止遺漏掉BUG沒有測試出來。 12. 壓力測試 壓力測試是為了發(fā)現(xiàn)在什么條件下您的應(yīng)用程序的性能會變得不可承受。這通過改變應(yīng)用程序的輸入以對應(yīng)用程序施加越來越大的負載并測量在這些不同的輸入時性能的改變來實現(xiàn)的。這種操作也稱為負載測試，但是負載測試通常描述一種特定類型的壓力測試增加用戶數(shù)量以對應(yīng)用程序進展壓力測試。 對應(yīng)用程序進展壓力測試最簡單的方法是手工改變輸入(客戶機數(shù)量、需求大小、請求的頻率、請求的混合程度等等)并描繪性能的變化。但是如果有許多輸入，或者需要在大的圍改變輸入，則你可以借助一個自動化的壓力測試工具來完成此測試。 13. 平安性測試 平安性測試

52、主要是測試系統(tǒng)在沒有授權(quán)的部或者外部用戶對系統(tǒng)進展攻擊或者惡意破壞時如何進展處理，是否仍能保證數(shù)據(jù)和頁面的平安。測試人員可以學習一些黑客技術(shù)，來對系統(tǒng)進展攻擊。 另外，對操作權(quán)限的測試也包含在平安性測試中。具體測試容如下: o 執(zhí)行添加、刪除、修改等動作中是否做過登錄檢測。 o 退出系統(tǒng)之后的操作是否可以完成。 o 所有插入表單操作中輸入特殊字符是否可以正常輸正常存儲，特殊字符為:#,%*()-+=、|;:,/，。 o 在帶有參數(shù)的回顯數(shù)據(jù)的動作中更改參數(shù)，把參數(shù)改為特殊字符并參加操作語句看是否出錯。 o 測試表單中有沒有做標簽檢測，標簽檢測是否完整。 o 在插入表單中參加特殊的HTML代碼，

53、例如:表單中的字本是否移動,。 14. 頁面腳本測試 頁面中時常使用到JavaScript腳本，為了降低頁面的出錯率，則必須對頁面腳本進展測試。其主要容包括:相關(guān)頁面中的腳本是否正常運行，JavaScript腳本是否有錯誤頁面。 15. 提示文本測試 提示文本測試從嚴格意義上來講應(yīng)該屬于UI合理性測試的一局部，該項測試主要針對各個頁面中使用到的大量提示文檔進展測試，主要包括:表達不明確的位置是否有提示文本、提示文本的彈出是否正常、提示信息含義是否明確易懂。 16. 瀏覽器測試 由于B/S構(gòu)造工程是基于瀏覽器運行的，所以需要對瀏覽器進展必要的測試。該測試任務(wù)主要是軟件對各種瀏覽器(IE5.5、I

54、E6.0、 FireFo*瀏覽器 )的支持是否正常，在IE瀏覽器中可以正常顯示的頁面在其它瀏覽器中是否可以正常顯示。 17. 安裝測試 在軟件工程的后期階段，會對做好的軟件進展打包把軟件做成安裝程序，以便用戶可以正確的安裝使用，所以需要對做好的安裝文件進展安裝功能方面的測試。該測試的主要任務(wù)是:檢查軟件是否能夠正常安裝使用、是否可以完全卸載此軟件的所有功能和頁面。 6、文檔資料 文檔包括開發(fā)過程中的所有技術(shù)資料以及用戶所需的文檔，軟件系統(tǒng)的文檔一般可分為系統(tǒng)文檔和用戶文檔兩類。 用戶文檔主要描述系統(tǒng)功能和使用方法，并不考慮這些功能是怎樣實現(xiàn)的，系統(tǒng)文檔描述系統(tǒng)設(shè)計、實現(xiàn)和測試等方面的容。文檔是

55、影響軟件可維護性、可用性的決定因素，有句話講，系統(tǒng)編程人員的每一紙片都要保存，所以文檔的編制是軟件開發(fā)過程中的一項重要工作。系統(tǒng)文檔包括: 開發(fā)軟件系統(tǒng)在方案 需求分析 設(shè)計 編制 調(diào)試 運行等階段的有關(guān)文檔。 在對軟件系統(tǒng)進展修改時，系統(tǒng)文檔應(yīng)同步更新，并注明修改者和修改日期，如有必要應(yīng)注明修改原因，應(yīng)切記過時的文檔是無用的文檔。 用戶文檔包括: 系統(tǒng)功能描述 安裝文檔，說明系統(tǒng)安裝步驟以及系統(tǒng)的硬件配置方法 用戶使用手冊，說明使用軟件系統(tǒng)方法和要求，疑難問題解答 參考手冊，描述可以使用的所有系統(tǒng)設(shè)施，解釋系統(tǒng)出錯信息的含義及解決途徑。 7、系統(tǒng)的運行與維護 系統(tǒng)只有投入運行后，才能進一步對

56、系統(tǒng)檢驗，發(fā)現(xiàn)潛在的問題，為了適應(yīng)環(huán)境的變化和用戶要求的改變，可能會對系統(tǒng)的功能、使用界面進展修改。要對每次發(fā)現(xiàn)的問題和修改容建立系統(tǒng)維護文檔，并使系統(tǒng)文檔資料同步更新。 12.4.4 效勞保證措施 本公司軟件質(zhì)量保證由各項任務(wù)構(gòu)成，這些任務(wù)的參與者有兩種人:軟件開發(fā)人員和質(zhì)量保證人員。前者負責技術(shù)工作，后者負責質(zhì)量保證的方案、監(jiān)視、記錄、分析及報告工作。軟件開發(fā)人員通過采用可靠的技術(shù)方法和措施，進展正式的技術(shù)評審，執(zhí)行方案周密的軟件測試來保證軟件產(chǎn)品的質(zhì)量。軟件質(zhì)量保證人員則輔助軟件開發(fā)組得到高質(zhì)量的最終產(chǎn)品。 我們的軟件質(zhì)量保證方案大體分為如下三大局部: 把軟件研制合理地劃分為假設(shè)干階段，

57、并針對每個階段的特點,制定出質(zhì)量評審、評測的要求和措施。 從軟件質(zhì)量的要求出發(fā),制定出相應(yīng)的技術(shù)和管理規(guī)，如軟件文檔規(guī)、軟件編程規(guī)、軟件測試規(guī)、軟件版本控制規(guī)等。 創(chuàng)立和積累公用模塊，向軟件工廠化方向開展。 1、軟件研制的階段劃分及其質(zhì)量控制 我們把軟件系統(tǒng)的研制劃分為8個階段，即總體需求分析、總體設(shè)計、各分系統(tǒng)的需求說明及概要設(shè)計、詳細設(shè)計(面向子系統(tǒng))、程序編制、自測試、組裝與驗收測試、試用和初步定型。 我們規(guī)定，總體需求分析及總體設(shè)計需經(jīng)有關(guān)領(lǐng)導及管理專家評審認定。分系統(tǒng)的需求說明、概要設(shè)計及詳細設(shè)計需經(jīng)總工程師組織的技術(shù)評審組評審。評審前，多數(shù)分系統(tǒng)的需求說明及概要設(shè)計需經(jīng)有代表性的用

58、戶審核認可，即分析和設(shè)計階段主要靠評審把關(guān)，編程和實施階段主要靠執(zhí)行規(guī)和測試把關(guān)。每次評審的結(jié)果都有相應(yīng)的記錄，并填寫相應(yīng)的表格。 2、軟件的文檔規(guī) 系統(tǒng)開發(fā)的文檔要:每個分系統(tǒng)必須有需求說明、概要設(shè)計，每個子系統(tǒng)必須有詳細設(shè)計和操作使用說明。需求說明、概要設(shè)計和詳細設(shè)計必須串行完成，而且規(guī)定，詳細設(shè)計未經(jīng)評審通過不能進入正規(guī)編程。不寫設(shè)計就進入編程，這是軟件開發(fā)人員常犯的毛病，在我們的系統(tǒng)開發(fā)中這是不允許的。 3、軟件編程規(guī) 開發(fā)中所有設(shè)計文件經(jīng)過認真的評審、推敲和認定后，軟件編程將是保證軟件質(zhì)量的一個重要環(huán)節(jié)。為保證這一環(huán)節(jié)的質(zhì)量，我們專門制定了編程的有關(guān)規(guī)。其中最主要的是界面規(guī)。 需要強

59、調(diào)的是，對界面的理解不應(yīng)只限于屏幕格式和操作方法，界面設(shè)計應(yīng)貫穿于軟件編制的全過程，我們的界面規(guī)分為兩大局部: 第一局部是設(shè)計原則，包括:一般原則、屏幕格式設(shè)計原則、輸入過程設(shè)計原則、信息顯示設(shè)計原則、提示信息設(shè)計原則、報表設(shè)計原則、菜單設(shè)計原則、操作方法原則。它重點解決操作的方便性和直接性、顯示和提示確實定性、輸入的準確性、輸入輸出的一致性，以保證對用戶習慣和心理的良好適應(yīng)性，給用戶一種愉快感，讓用戶產(chǎn)生一種喜愛感。 第二局部是屏幕格式設(shè)計，包括:屏幕、登錄屏幕、單記錄錄入窗口、多記錄錄入窗口、查詢列表窗口、 主/細數(shù)據(jù)錄入窗口、命令按鈕格式。它的主要目標是，力求使屏幕格式簡煉、實用、直觀、

60、醒目、風格一致，使操作使用方便。 軟件編程規(guī)更是一種設(shè)計和編程經(jīng)歷的總結(jié)，是對所用開發(fā)工具的深入認識和全面理解。這一規(guī)本身的質(zhì)量直接關(guān)系到全系統(tǒng)的編程效率和可移植性、軟件的可擴展性及可維護性、數(shù)據(jù)的可恢復性和系統(tǒng)的可靠性。特別是在客戶/效勞器模式下工作的系統(tǒng)，編程時對處理和數(shù)據(jù)的合理分布將直接影響到系統(tǒng)資源利用得是否充分、恰當，直接影響到整個系統(tǒng)的性價比。 它包括:對象和控制命名規(guī)、編程風格、數(shù)據(jù)校驗、環(huán)境配置與應(yīng)用的可移植性、事件驅(qū)動、面向?qū)ο蟆?shù)據(jù)庫訪問規(guī)、數(shù)據(jù)及處理分布、出錯處理、安裝及設(shè)置。實踐證明，這一規(guī)對保證程序質(zhì)量、提高軟件重用度,進而對提高編程效率、乃至提高系統(tǒng)的可靠性均起了重