軟件測試信息管理系統的設計與實現

發布時間：2023-01-03 13:39

第一章緒論 1

1.1項目背景及意義 1

1.2國內外研究現狀 2

1.3本文研究內容 4

1.4本文組織結構 5

第二章系統技術路線 6

2.1軟件測試的一些基本概念 6

2.2敏捷開發中的軟件測試 7

2.3信息管理系統的技術支撐 9

2.4本章小結 11

第三章系統需求分析 12

3.1項目需求背景 12

3.2項目功能性需求分析 13

3.2.1測試需求管理功能分析 13

3.2.2測試計劃管理功能分析 14

3.2.3測試用例管理功能分析 14

3.2.4用例執行管理功能分析 14

3.2.5產品缺陷管理功能分析 15

3.3項目非功能性需求分析 15

3.3.1測試報告統計功能分析 15

3.3.2測試人員成就功能分析 16

3.3.3三方系統對接功能分析 16

3.3.4系統設置功能分析 16

3.4數據模型及系統其它需求 16

3.4.1測試系統數據模型 16

3.4.2測試系統其他需求 21

3.5本章小結 22

第四章系統詳細設計 23

4.1系統架構設計 23

4.2系統模塊綜合 25

4.2.1測試需求管理詳細設計 26

4.2.2測試計劃管理詳細設計 27

4.2.3測試用例管理詳細設計 28

4.2.4用例執行管理詳細設計 29

4.2.5產品缺陷管理詳細設計 30

4.2.6測試報告統計詳細設計 31

4.2.7測試人員成就詳細設計 32

4.2.8三方系統對接詳細設計 33

4.2.9系統設置詳細設計 34

4.3數據庫表詳細設計設計 35

4.4本章小結 42

第五章系統具體實現 43

5.1系統的開發環境簡介 43

5.2系統的總體技術實現 43

5.2.1系統的前端技術實現 43

5.2.2系統的后端技術實現 43

5.3系統的模塊具體實現 44

5.3.1系統設置具體實現 44

5.3.2測試需求管理具體實現 49

5.3.3測試計劃管理具體實現 51

5.3.4測試用例管理具體實現 53

5.3.5用例執行管理具體實現 56

5.3.6產品缺陷管理具體實現 59

5.3.7測試報告統計具體實現 62

5.3.8測試人員成就具體實現 64

5.3.9三方系統對接具體實現 67

5.4本章小結 69

第六章系統測試 70

6.1系統的測試環境簡介 70

6.2系統的測試類型 70

6.2.1單元測試 71

6.2.2組件測試 71

6.2.3功能測試 72

6.2.4冒煙測試 74

6.2.5集成測試 75

6.2.6性能測試 75

6.2.7穩定測試 76

6.2.8探索性測試 76

6.3 系統的測試結果 77

6.4 本章小結 78

第七章總結與展望 79

7.1總結全文 79

7.2展望后續工作 79

致謝 80

參考文獻 81

附錄 84

主要符號表

SOAP

SaaS

E-R圖

TDD

ATDD

GPL

API

POJO

WSDL

HTML5

JavaEE

CSS3

AR 簡單對象訪問協議

Software as a Service（軟件即服務）實體-聯系圖測試驅動開發驗收測試驅動開發通用公共授權應用程序編程接口簡單 Java 對象網絡服務描述語言極限編程第五代超文本標記語言 Java 企業版第三代層疊樣式表虛擬現實增強現實

第一章緒論

1.1 項目背景及意義

在對當前的軟件開發和軟件測試相關領域的工作進行調查，總結發現，軟件開發活動中，長期存在重開發輕測試，不注重測試管理。主要表現在［1］以下幾個方面：

其一，測試人員介入時間晚。軟件開發需求階段，只有項目管理者和產品研發人員參與需求分析，產品測試人員是在軟件開發階段才被包含進來；

其二，測試用例審閱流于形式。測試人員編寫的測試用例，在進行審閱時，沒有有效的回復，導致測試用例修改效果甚微，測試用例需求覆蓋不全；

其三，產品測試缺陷記錄反映不真實。測試人員對測試工具不熟悉，提交的產品缺陷，無法真實反應產品的問題級別。項目管理者隨意修改缺陷數以滿足產品發布需要；

其四，測試任務分配統計缺乏科學性。測試人員執行的任務（主測試任務和支援性任務），無法有效記錄。測試任務分配和測試任務統計沒有有效關聯，管理缺失；

其五，測試資源管理混亂。測試計劃、測試用例和測試工具沒有有效管理，新人和測試執行人員無法定位資源，導致測試效率低下；

其六，測試報告格式不規范。測試報告編寫效率低下，格式不統一，無法重復使用。

結合以上問題，期望設計出一款軟件測試［2］方面的專業管理軟件可以對測試的各階段相關信息進行合理的、有效的管理。從而使測試需求明確、測試用例編寫有效、測試資源保存得當、測試進度查詢便利、測試報告高效輸出、測試成果記錄科學。目前常用的對軟件進行測試的工具包括了 QC、Mantis、Bugzilla 和 Testlink等幾種，在這些軟件中，有部分是開源的，能夠免費使用的軟件，但也有部分是收費的，商業性的軟件。在這些測試工具中，都有著各自的特點，如 Mantis和Bugzilla工具能很好地對測試的缺陷進行管理，Testlink工具則擅長對試用例進行管理，而Redmine工具在測試項目的管理方面會顯得更加高效一點，QC 雖然全面，但太重量級和商業化。都無法完全滿足設計需要，為此，本著開源高效，著手設計一款通用類型的軟件測試管理軟件。

由于國家政策鼓勵發展軟件產業，所以軟件產業發展很快，軟件企業的數量迅速增長。但進一步分析這些企業的產品，普遍存在缺少核心技術和缺少高層次人才（如：軟件測試人才和軟件分析人才）。也就是是說為提高軟件質量［3］和研發速度，軟件測試環節必須加強，軟件測試在軟件開發中的地位越來越重要。特別是敏捷概念從國外引進國內后，開發模式的改變，更加需要一個快速響應的測試過程，但測試上的敏捷，卻不是簡單的縮短時間，這勢必要面臨著測試自動化，持續集成，從而能夠開發更多的軟件測試工具和技術來提高測試的效率，如建立質量的反饋系統、質量的檢查系統等，產品中的測試等一系列措施，而這一切的指向結果就是一個完整軟件測試信息管理系統，隨著中國信息化戰略的不斷深入，國內軟件市場前景是非常廣闊的。現在國外很多著名軟件企業已看好中國市場，紛紛表示要搶占中國市場。因此我們中國的軟件企業必須抓緊時機，積極參與國際競爭，盡可能多地占領國內市場份額。

1.2 國內外研究現狀

信息技術的革命最先發源與西方，很多軟件領域的標準，規范都是由西方制定，軟件的開發測試成熟度，相對于國內來說,更加完善和精細。軟件開發商和軟件應用商都十分重視軟件產品的質量［4］。從軟件的開發過程中，重視軟件的測試，到軟件的交付過程，嚴格把控軟件的質量。由此產生了大量不同的測試管理軟件。

從 2004 年出品的 TestLink 工具是根據 web 所建立的測試系統，其包括了對產品的管理、測試計劃的建立以及對測試的用例進行管理等。除此之外，在 TestLink工具中，還包含了統計模塊，能夠為用戶提供簡單的統計功能。TestLink 偏重測試用例管理。同時期的產品，如 Testtrack、Zephyr、IBM Rational Quality Manager、Enterprise Tester，有開源產品，也有商業化的產品，但本身均不包含缺陷管理功能，都是通過集成第三方產品實現。測試管理軟件的另一個功能就是對缺陷的跟蹤功能，目前已經有多種能夠完成對缺陷進行跟蹤的軟件，如 Bugzilla 和 Mantis 等。其中， Bugzilla 能夠對測試對象中的 Bug 進行跟蹤，包括報告 Bug 的位置、對Bug出現的記錄進行查詢，從而通過記錄來生成報表，并對Bug進行處理等一系列完善的缺陷跟蹤的管理體系。 Mantis 是基于角色和項目模塊為劃分的 BUG 跟蹤系統。其中 TestLink 可與 Mantis 或 bugzilla 進行集成。

2006 年出品的 Redmine 軟件是一款基于 web 開發的主要用于對項目進行管理的軟件，它利用的是ROR框架，能夠為客戶提供跨平臺的項目管理服務。除此之外， Redmine 還能夠與其它系統結合工作，從而對測試對象的 Bug 進行跟蹤，如與 Perforce、 SVN 和 CVS 等軟件共同工作。 Redmine 能夠通過完成項目而將各種資源進行搜集和整理，能夠實現多成員共同完成一個項目的服務，同時，系統匯總會以時間為線索，實現實時、動態地向各個參與項目的成員匯報當前的項目進度，但是， Redmine 最多允許 100 位成員參與，經過研究，發現在 100 名以內成員所參與的項目中， Redmine 能夠很好地完成任務。

到 2010 年微軟出品的 Microsoft Test Manager/Team Foundation Server，相比較 testlink 的輕量級，其包含測試的所有階段措施，如產品規劃，探索性測試，測試用例生成，手工執行，自動執行和持續部署，錯誤的創建和跟蹤，測試結果報告。但由于其是微軟公司 Visual Studio 的一部分，所以屬于商業產品，具有明顯的局限性。同時期的產品，如 HP Quality Center、Silk Central Test Manager> TestLodge、 TestRail 均提供全面解決方案，但由于是商業產品，只能免費有限使用。基于云和移動應用的廣泛發展，測試管理工具已經進軍移動和 SaaS 領域。目前市面上最佳的測試管理工具，如 qTest、 PractiTest 都已經做到一個完全的 SaaS 終端到終端的質量保證和敏捷友好測試管理工具。當然它們同樣不開源。

反觀國內，從2000年之前，沒有任何一家軟件公司專門設立軟件測試崗位，到 2003 年后，隨著國內軟件外包［5］公司的快速發展，測試服務機構猶如雨后春筍般不斷地涌現，而測試的技術也在不斷的進步，其能夠測試的領域和測試的種類也在不斷的增長著。隨著測試技術在各個領域中的應用，越來越多的人開始關注這種技術，在高校中也出現了測試技術專業及其相關的專業，這能夠為測試領域提供人才的保障。軟件測試管理工具的發展明顯落后于國外，目前市面上流行的軟件測試管理軟件，比如，國內的禪道工具，就是為了完成測試而開發的，禪道工具屬于免費的開源軟件，它能夠對產品的研發、測試等環節進行管理，利用目前主流的開發方法 Scrum 技術。同時，又在軟件中增加了對系統 Bug 的管理，以及測試用例的管理，發布管理和文檔管理等對軟件進行測試過程中需要管理的部分。禪道測試工具能夠囊括了測試過程中的核心流程，為用戶提供了集成化的測試工具，其內部集成的三十多個功能模塊，以及兩百多個功能節點，能夠全面地對項目各方面進行管理。能夠很好地解決由于過于復雜，上手慢，定制能力不足，不好用層級結構管理用例。Bugtags利用實時性好的問題上報方式，能夠提高問題上報的效率，從而提高對問題解決的效率。與此同時，Bugtags還能夠對過期、失效的信息進行管理，但是，這些功能的實現主要還是出于開發團隊的實際需要出發的。

更多的，比如騰訊優測、百度MTC、阿里云測、搜狗云測等，均屬于借力 “云”技術，發展起來的移動應用測試平臺，不具有普遍性和廣泛適用性。我國在軟件專業測試管理軟件研發方面明顯落后于同類型國外產品。

結合上面國外軟件測試管理軟件的發展情況，可以看出，目前的軟件測試管

理軟件存在，做的好的測試管理軟件，一定是商業公司非開源的，開源的測試管

理軟件，無法提供一個完整的軟件測試行業規范的開發流程的完全解決方案，需要配合其他開源管理軟件集成使用，而這必然會涉及到不同產品的更新換代落后，不同產品間整合的兼容性問題。

1.3 本文研究內容

軟件測試信息管理系統（簡稱：STIMS）正是分析目前已有的軟件測試管理工具，總結軟件測試相關的技術理念和經驗，從而能夠使工具很好地避免了以往的工具中存在的不足，通過加入現代化的信息技術，為軟件的測試提出完善的方案。它很好的詮釋管理、執行和成果這三者的關系。

STIMS 包括五大基本功能和四大輔助功能：

1）測試需求管理，對項目的需求分析文檔進行管理，把需求添加進去，可以方便分析測試用例對測試需求的覆蓋進行管理。其中，對軟件的測試需要對其中的功能進行測試，如增加、修改、刪除和查詢等功能。

2）測試計劃制定，為項目新添加一個測試計劃，必須要有測試計劃才能進行測試用例的添加和測試的執行。測試計劃制定主要實現的功能：測試計劃修改、刪除、增加、查詢。

3）測試用例管理，對項目的測試用例進行管理，把測試用例添加進去，方便測試的執行。其包含測試用例的增刪改查。

4）測試用例執行，執行測試用例，可以在工具上修改測試用例的執行狀態，方便管理。實現的主要功能有執行人員分配、執行工具分配、執行進度查詢、執行結果查詢。

5）產品缺陷管理，根據測試結果，記錄產品不同級別的缺陷，方便跟蹤問題狀態。其主要功能包括產品缺陷錄入、解決人員分配、產品缺陷查詢。

6）測試報告統計，按照一定的模板生成不同的測試報告，方便從不同角度和級別對產品需求的完成情況進行統計。軟件測試信息管理系統該模塊包括的主要功能有報告樣式管理、缺陷報告輸出、測試報告輸出、總體報告輸出。

7）測試人員成就，完整記錄測試人員的測試工作情況，如編寫測試計劃，測試用例，提交缺陷等一系列成就。功能主要包含成就樣式管理、個人成就輸出、團隊成就輸出。

8）三方系統對接，按照第三方系統生成測試人員工作數據，提高求職的職位契合度，增強工作在社交方面的正向作用。該模塊主要包括領英系統接口、微信系統接口、游戲系統接口。

9）系統設置，主要完成系統參數的管理、系統用戶管理以及用戶的權限管理。

1.4 本文組織結構第一章，緒論。介紹了論文的目的、意義及本文的工作內容。第二章，系統技術路線。介紹了系統依賴的關鍵技術和理論依據。第三章，系統需求分析。介紹了系統的實現目標，并詳細分析了業務流程和系統功能和非功能需求。

第四章，系統詳細設計。介紹了系統的架構，模塊，存儲，并詳細闡述了功能模塊和數據庫E-R關系。

第五章，系統具體實現。介紹了系統各模塊的開發情況，實現方法以及重要代碼。

第六章，系統測試。介紹了系統不同階段測試工作，以及測試環境和測試結果。

第七章，總結與展望。總結了本文的現階段工作情況，并對進一步的工作進行展望。

第二章系統技術路線

2.1軟件測試的一些基本概念

對軟件的測試是軟件開發中不可或缺的一步，它能夠通過預設的條件，在這些條件下運行，并對軟件的質量進行檢測，主要包括了檢測軟件程序是否存在錯誤、系統是否存在 Bug 等，此外，也對軟件的性能進行檢測，判斷其是否能夠滿足設計的要求等。對軟件所做的測試目的是為了找到開發的程序中是否有不正確邏輯而運行程序的活動。在對軟件的測試中，能夠選用的方法有很多，而對于軟件的測試，尤其是比較復雜的軟件的測試，不僅僅是開發過程中的一個環節，還是對以往技術提出挑戰的過程。測試工作的進行，無非是一個質疑和解惑的過程，這也是產品在不斷完善中所需要經歷的過程。盡管，在測試的環節中，大部分的流程都是相同的，基本都包括了回顧、檢查，但是，對產品的測試無外乎是保證產品在使用中的流暢程度和穩定性，因此，其中的穩定性能、實用性能和效率等，還是需要進行測試的主要指標。

在對軟件進行測試的方法中，常用的方法可分為白箱和黑箱兩種，其中，黑箱測試主要是對軟件的功能進行測試，而白箱測試是對軟件的結構進行測試，下文將對這兩種測試的方法進行介紹。

黑箱測試法，能夠用于對軟件的應用程序和功能模塊進行測試，但這種方法主要是測試軟件的表面層，不能夠對軟件的內部結構和內部的編碼進行操作。因此，軟件的測試人員能夠在不對軟件的內部結構進行檢測的情況下，實現軟件的測試功能，也無需懂得編程［6］語言等相關的知識。在操作中，軟件的測試人員需要清楚的認識軟件所要實現的功能，也就是在測試軟件工具中輸送一個已知輸出結果的命令，并對測試軟件輸出的結果與已知的結果進行對比，從而達到軟件測試的功能。在黑箱測試方法的安排中，能夠對測試的軟件的功能和應用進行測試，根據既定的測試要求和規格，自主實現高效的測試。目前，黑箱測試的方法常常廣泛的被用于集成的測試、接口的測試等對象功能實現的檢測。

白箱測試法是對系統的內部結構和運作流程進行測試的工具，因此又能夠稱為透明測試法。在使用白箱測試方法的時候，系統的操作界面是程序語言，也就是說，白箱測試的方法通過對編程語言進行檢驗，從而能夠從軟件的內部對其進行測試。軟件的測試人員需要對程序語言有一定的認識，通過在測試軟件中輸入相關的數據，從而對其輸出進行確定，然后白箱測試軟件將自動對軟件的內部結構進行測試。白箱測試的方法能夠對系統集成的每一個單元路徑的準確性測試，能夠發現很多存在系統結構內部的編程上的錯誤和 Bug 等問題。目前，白箱測試的方法主要用于軟件的單元測試和集成測試兩方面。

下圖所示的是 V 模型的測試流程， V 模型是瀑布模型中的一種。

圖 2-1 V 模型測試流程

在上圖中，能夠將軟件的測試分為不同的環節進行，并且根據不同的測試對象的關注點而出現不同的測試類型。

單元測試。對單元的測試是檢驗組成軟件的基本模塊開展的測試，檢驗的目的是為了對軟件基本組成，也就是基礎的單位進行檢查，能夠更加容易地發現軟件組成上的錯誤。

集成測試。集成測試的方式是將程序的功能模塊通過封裝的方式來集合起來，分別對集成后的功能模塊進行測試，尤其是功能模塊的接口，是集成測試中的一個重點測試的對象。

系統測試。系統的測試主要包含了對系統的功能、界面和性能等方面的測試，通過模擬用戶在軟件中的實際操作來對軟件進行完善的測試。

驗收測試。驗收測試是軟件開發流程的最后一個環節，由用戶對系統進行最后的測試和驗收，驗收測試同時也是對產品確認的一個環節。

2.2敏捷開發中的軟件測試

敏捷的開發過程是指在上世紀九十年代流行的一種軟件開發模式，它與傳統的瀑布式軟件的開發模式相比，有著更加靈活和輕便的優勢。在二十一世紀初期，有部分該軟件開發方式的支持者建立了敏捷聯盟。在敏捷聯盟中，從成立開始就提出了四條軟件開發的四條基本理念，也就是：人員的交流比工具更重要、產品成效比侃侃而談更重要、客戶［7］的配合比合同的要求更重要和跟隨實際變化比終于傳統更重要。

根據這四條理念，使敏捷開發中依照的是自己的開發流程，如下圖所示：

敏捷開發有個特殊的地方是任務的交替性很高，有重復的時間規律性，并且能夠快速地、連續地完成客戶所要求的變更請求。同樣的敏捷測試就是在持續修正產品質量的指標，正確的確立測試策略，確認客戶的有效變更要求能得以完滿實現和保證整個開發的過程安全的、按時的發布出客戶期望的最終產品。

敏捷測試與一般測試的區別（參見圖 2-3）

1.項目組中開發與測試活動同時進行，項目時間較快。

2.功能實現的提交頻率高，測試人員經常有壓迫感。

3.計劃任務劃分明確，工作完成效率高。

4.項目資源比較合理，測試不會出現重測的情況，增加工作量。

5.發現缺陷后需記錄，團隊中人員都很忙，有問題很容易被遺忘。

6.花時間、或難解決但是對產品影響不大的問題一般會放到下個迭代解決。

7.發現缺陷可以很快的修復，對相關的功能測試影響十分小。

8.版本發布比較頻繁，影響到測試的執行速度。

9.常常要與開發溝通。

10.團隊成員要了解版本的更新情況。

11.測試人員差不多要參與整個項目組的大小會議。

在運用敏捷活動的軟件進行測試的過程中，遵循的是敏捷開發的基本理念，敏捷活動的流程實際上也是思考了測試各個階段的開展，因此，敏捷活動的模式能夠為軟件的測試提供更多的便利。

2.3信息管理系統的技術支撐

做敏捷模式的開發，如何可以敏捷？我們更多依賴一系列完整的工具幫助我們快速起來。敏捷開發工具的合適以及挑選，對開發團隊起著重要的作用。

首先是服務器的結構，在選擇服務器的結構上，我們選用了 B/S 的結構，這種結構與傳統的 C/S 結構不同，用戶在進行訪問的過程中無需安裝任何瀏覽的插件，只需要使用用戶原本的瀏覽器就能夠對系統進行訪問。這種優勢能夠使用戶和開發者在不同的瀏覽器中進行操作。在選用服務器端的過程中，選用了高性能的計算機，并與大型的數據庫進行對接，能夠保證數據的正常調用。B/S結構能夠簡化了軟件開發的工作量，它是一種由Internet^發展而來的技術，但是，B/S 的結構對服務器的要求比較高。

Linux是一種自由和開放源代碼的類UNIX操作系統。目前運用領域最廣泛、使用人數最多的操作系統之一， linux 系統是上世紀九十年代初的產物，其核心發布后，在加上用戶空間的應用程序之后，成為Linux操作系統。

Ubuntu 是以桌面應用為主的 Linux 發行版， Ubuntu 由 Canonical 公司發布，他們提供商業支持。它是基于自由軟件，該名稱來源于小語種，其原意為“人性”，意指能夠為操作者帶來更具人性化的操作體驗。

Ubuntu計劃強調易用性和國際化，以便能為盡可能多的人所用。Ubuntu的所有發行版本都可以免費獲取。自 Ubuntu 12.04 LTS 版本起，針對普通用戶的版本和針對大客戶的版本都可以獲得長達 5 年的產品支持。

在SSH中，可分為表示、業務邏輯、數據持久和域模塊等四個層面。它能夠為開發人員提供架構清晰、便于開發，以及對后期維護流程簡化的系統框架。在 SSH中，采用Struts作為基礎的模塊，主要的職能是分離MV。9】，Struts能夠控制業務邏輯的跳轉，并結合 Hibernate 對系統的數據持久層提供幫助。在 SSH 中， Spring 作為框架的管理者，能夠對前面介紹的兩種框架進行管理，除此之外， Spring 還能夠實現分離的功能，能夠對系統的業務邏輯和數據持久層進行分離，這種分離不僅能夠減輕系統工作的負荷，還能夠提高系統的工作效率。

MariaDB 數據庫是 MySQL 的一個分支，主要由開源社區在維護，采用 GPL 授權許可。而開發這個分支主要原因是：甲骨文公司收購了開源的 MySQL 數據庫后，準備將MySQL封閉化，存在不開源的風險，因此原社區采用拉分支的方式從而避開這個風險。

MariaDB的最終目的是完全兼容現有的MySQL，不僅包括API，同時還有命令行，使得它能輕松替代MySQL。在存儲引擎方面，從10.0.9版本開始，使用 XtraDB （名稱代號為Aria）來代替原有MySQL的InnoDB。

Redis 利用 ANSI C 作為基礎語言，是一個能夠持續性工作的鍵值對存儲數據庫。根據網站 DB-Engines.com 月度排行榜的信息顯示， Redis 是使用最多的鍵值對內存數據庫。Redis是一個高性能的key-value數據庫。除此之外，Redis還支持二進制的數據輸入，以及多種數據類型的輸入。

Eclipse是常用的開源式的軟件開發平臺［10］。Eclipse是以Java語言為基礎的軟件，但也有通過其它方式進行開發的，如c語言，C++等。實際上，Eclipse工具是兼容性很強的工具，并通過引入大量的插件，從而成為了軟件開發的平臺，因此，開發商以 Eclipse 為框架開發自己的 IDE。

WebStorm 是 Jetbrains 公司的一款 JavaScript 集成開發工具。目前已經中國 JS開發者稱贊為“Web前端開發利器”、“最強大的HTML5編輯器”、“最智能的JS腳本IDE”等。由于與IntelliJ IDEA同源，它也具有IntelliJ IDEA強大的 JS 部分的功能。

Apache JMeter是純JAVA的桌面應用程序，主要開發用于測試客戶端/服務端結構的軟件（例如互聯網應用程序）。它可以用來測試靜態的和動態的［11］資源性能，例如：靜態文本文件，Java Servlet,CGI Scriptsjava Object，數據庫和FTP服務器等等。JMeter可用于模擬大數據量的負載來測試一臺服務器、網絡或者對象的健壯性或者分析不同的負載下系統的整體性能。

而且 JMeter 可以協助測試人員對所測的應用程序進行回歸測試。通過測試人員自定義的測試腳本和斷言來檢測應用程序返回的值是否如期待的。為了更高的靈活性，JMeter允許測試者定義正則表達式來創建這些斷言。.

Firebug 是一個自由及開放源代碼的 Mozilla 基金會火狐網頁瀏覽器擴展，是一個網絡頁面的開發工具，開發者可以使用它排錯、修改、刪除任何網站的 CSS、 HTML、DOM 與 JavaScript 的代碼。

Firebug也提供擴展的框架，例如：Yahoo!的網頁速度優化建議工具YSlow、 FireCookie、 FirePHP 等。

git是一個分布式版本資源控制的軟件。與CVS和Subversion 一類［12］的集中式的版本資源控制軟件不同，它采用了分散式版本資源庫的方法，不需要服務器端的軟件，就可以進行版本資源的控制，使得源代碼發布和交流變得十分便利。 git 的響應很快，這對于比如 Linux 內核類似的龐大項目來說顯得十分重要。 git 最為稱贊的是它的合并追蹤(merge tracing)功能。

Apache Maven 是一個軟件(特別是 Java 相關的軟件)項目管理和自動打包工具，由Apache軟件基金會提供。基于項目管理的模型(縮寫：POM)概念，Maven 使用一個中央信息片斷就能管理整個項目的編譯、打包和文檔等步驟。 Maven 項目使用項目管理模型(Project Object Model，POM)來設置。項目管理模型存儲在名為pom.xml的XML資源中。

2.4 本章小結

本章主要簡述了軟件測試的一些基本概念，并結合敏捷開發中軟件測試不同之處，介紹了各種不同開源工具，為后面軟件開發和測試提供理論和技術支持。

第三章系統需求分析

3.1 項目需求背景

對所開發的軟件進行檢驗，需要對軟件進行系統化的檢驗，從而能夠全面對軟件的質量進行檢驗。在軟件測試的過程中，涉及到對軟件的測試管理環節，而管理環節又包括了對測試流程所進行的環節和模塊的管理。目前，常用的測試管理方法有：傳統的筆紙記錄方法；程序處理方法和數據表處理方法。在一些規模大、復雜的軟件質量測試的工作中，有條件的用戶還會開發自己專用的軟件測試工具，從而能夠更好地對軟件的質量進行測試。一般而言，大部分的軟件質量測試工作都是通過建立電子數據表來完成。測試的管理是為了能夠保證軟件開發的團隊在測試的各個環節中能夠順利完成，這些工作不僅僅是一個獨立的個體，更重要的是關注其關聯性。從更高的操作層面來看，軟件的測試管理工作看上去很簡單，但在實踐中會存在著很多的問題，如測試團隊人力缺乏問題、資源問題，以及測試團隊并不是總在一個地方，需求方面的難題，與開發保持同步，報告正確信息。所以為了提高軟件的測試管理，大部分的測試管理工作都是在軟件開發前就已經進行規劃的，從而使軟件測試的過程更快更好地完成。使用基于需求的測試，協調遠程測試資源，定義并執行靈活的測試流程，調整并整合開發的剩余部分，溝通狀態，關注目標和結果，通過自動化來節約時間。在測試管理中對適當工作的使用工具以使其自動化將極大地提高其價值和收益。

同敏捷開發一樣，敏捷測試面臨著連續回歸過載的負擔，并且隨著需求的頻繁變化，返工率還可能會倍增，導致測試工作的反復進行。這時，我們需要一個可以整合一切測試資源，按照開發測試測試流程，能夠貫穿起來的一個管理平臺，通過它，能夠讓測試人員更加清晰的按照明確的需求文檔，制定詳盡的測試計劃；項目經理可以根據測試的需求，合理分配測試任資源（既包括人員的安排，軟硬件資源的調配），測試執行人員能夠按圖索驥的執行明確的測試用例；系統根據測試結果，匯總測試的缺陷情況，以及測試進度，所有流程和工具僅用于幫助敏捷團隊的工作生活更輕松，而不是使流程復雜化或過度轉型。敏捷測試人員也應該花更多的時間來實踐測試系統并尋找新的方法來運行，例如使用單線方案，探索性測試，軟件風險測試和錯誤檢查列表，而不是使用測試用例來覆蓋測試，創建和使用足夠多的與軟件測試或者開發有關的項目文件。敏捷測試人員可以盡全力通過與客戶的溝通來達到完成客戶所要求的測試任務。這是敏捷思維價值觀念中核心的一條。讓客戶滿意高于一切。敏捷思維重視客戶的需求并要求與客戶保持溝通，以實現對客戶需求的完全掌握。而不是通過僵硬的合同條款去框定客戶要求。

3.2項目功能性需求分析

圖 3-1 顯示了系統的功能模塊：

圖 3-1 系統模塊圖

為了滿足這樣一個良好的目標，現針對以下幾個系統需要實現的主要功能進行了分析：

3.2.1 測試需求管理功能分析

測試需求是整個測試過程的基礎，每個參與測試的人員都需要根據測試需求來分配接下來的工作。所以測試需求對于測試活動來說不可或缺。一般來說，大部分公司的測試需求，都是文檔管理，小一點的公司，會直接使用紙質面對面的溝通加以聊天軟件記錄；大一點的公司，會采用 office 辦公套件，如 word［13］， excel 來配合記錄測試需求計劃，并且使用 SVN 等版本管理工具進行管理。后者雖然比前者在追蹤記錄有效性方面有改進，但這兩種方式都需要人工進行維護，一旦有人沒有及時更新，就會造成執行人員獲得的測試需求信息不是最新，從而導致測試計劃的失誤。所以將測試需求［14］引入管理軟件，會避免版本的不一致，測試人員可以隨時登陸系統維護需求文檔，管理人員［15］可以隨時登陸系統查詢需求文檔，并且系統化的管理，還會為后期測試報告輸出時提供極大的便利。從而避免因為需求文檔的管理而對整個項目進度和結果產生不好的影響。

3.2.2 測試計劃管理功能分析

測試計劃是控制整個測試活動的依據。一個好的測試計劃可以完全滿足測試需求的各個需求點，合理安排測試人員和測試時間。然而目前的各大公司的測試計劃都是 PM （Project Manager 項目經理）一個人按照和客戶在會議上溝通的 DeadLine （交付時間）來制定和分配的。如果實際參與測試活動的人員未與會，勢必會造成在承諾交付時間上的理解差異。測試計劃的制定就會出問題，并且在任務分配方面，也會出現郵件或者口頭指定這種無法完全跟蹤的回溯性問題。一旦后期出現交付理解不一致的問題，再查出處會十分困難。將測試計劃整合進管理軟件，會明確該測試計劃來源于那個測試需求，即使參測人員未與會，也可以很好的清楚來龍去脈。并且會方便以后缺陷分析追本溯源。

3.2.3 測試用例管理功能分析

測試用例是測試活動的具體體現，是每個測試人員接觸最多也最依賴的指導測試來源。測試執行人員會根據測試用例編寫人員編寫的測試用例描述的具體測試場景來執行測試，然而測試用例的保存，大多數時候卻是用紙質文檔或者電子文檔來管理，這樣在更新文檔的內容時同樣會存在更新時效性的問題，測試用例會有TestCase Review meeting（測試用例檢視會）這樣的活動，如果在會后，檢視建議沒有及時正確的更新并反映在后續的測試用例文檔上面，就會產生遺漏。也就會發生需求改了，測試用例沒有更改，測試執行人員由于不是測試用例編寫人員，所以也無法發現需求漏測這樣測試活動錯誤。后期來彌補這個錯誤會耗費較大的精力。而將測試用例［16］合并到管理系統，會方便用例檢視人員，用例編寫人員，用例執行人員對用例的來源都是一處，并且打開系統就可以檢視和修改，即使各個人員不在一處，修改完成后就是最新的。從而提高協同效率，減少需求漏測這樣的錯誤。

3.2.4 用例執行管理功能分析

用例執行是測試活動中的關鍵一環，這會與測試的結果相掛鉤，從而影響測試的質量。在用例測試中，測試的人員會通過口頭或者郵件的形式收到測試用例執行的所需要的測試環境，有可能此時整個測試環境還沒有從上一個測試活動中釋放出來，測試管理人員（項目經理）沒有得到資源的有效信息，從而無法正確分配空閑的測試環境。對于測試進度的溝通也采用郵件或每日上下班的時間進行口頭溝通，比較好一點的會使用敏捷的 SprintBacklog （每日記錄）來同步。如果測試執行人員未及時更新或者請假，測試的執行情況無法讓項目經理及時了解。引入用例執行管理到管理系統，配合測試計劃和測試用例模塊，可以更好的了解測試的執行進度，測試人員每日的執行情況都會反映在測試管理系統的界面上。項目經理也可以清楚的測試資源的使用情況，做到合理分配。真正做到信息的即使傳遞性。

3.2.5 產品缺陷管理功能分析

沒有不存在缺陷的產品，對于測試人員來說，發現缺陷是測試工作［17］中的一個重要活動。圍繞缺陷的發現、修復、跟蹤也是測試活動中十分重要的環節。將產品缺陷和測試需求、測試計劃、測試用例等有機的結合起來，利于開發人員更好的了解缺陷產品的原因，該缺陷屬于哪個需求，是因為什么操作或前置條件產生的缺陷，加速了缺陷的修復過程，縮短了花費的時間。另一方面，對于測試管理人員來說，可以更有效清楚產品的缺陷情況，什么模塊產生的缺陷最多，什么樣的測試最有效發現缺陷。大大利于分配缺陷和控制缺陷的增長趨勢。

3.3項目非功能性需求分析

為了完善系統的主要功能，勢必會有其他非功能性的模塊，以下是具體的分析：

3.3.1 測試報告統計功能分析

一份良好的報告抵過萬千文字。測試活動的最好結果展示是一份圖文并茂的測試報告。目前大部分公司的測試報告都是由測試人員根據一定的測試報告模板，人工對整個系統的測試數據進行整合。整合的時間會根據測試活動的規模大小決定，少則一兩天，多則一周。紛繁的測試結果數據和煩人的紙質或電子文檔都會讓測試報告編寫人員焦頭爛額。而如果擁有測試報告統計這個功能，在測試需求明確，測試計劃制定，測試用例有效執行，這些活動完成后，系統就能按照想要的報告模板給出一份基本的和定制的測試報告，展現在屏幕上供大家閱覽，如果想歸檔還可以打印出來，整個過程會變得很輕松。測試人員可以更加關注測試的本質上面，而不是忙碌于管理者關注的測試報告這一環節上。

3.3.2 測試人員成就功能分析

一個測試活動完成后，除了測試報告的輸出［18］，更重要的一點，就是測試人員本身的自身成就。目前大多數一線測試人員，測試工作雖然被重視，但測試人員本身沒有受到重視，甚至覺得測試人員這個角色能被開發人員兼任。這其中一個重要的原因就是測試人員自身的產出沒有被記錄，因為軟件活動不是一兩個人可以做好的，而是一個團隊。這個原因也往往忽視了作為一份子的測試人員本身。測試人員成就模塊就是一個能在不影響整個測試活動的情況，像游戲中的成就系統一樣，可以關注每個測試人員本身，對其在整個測試活動中的貢獻都有所記錄。這樣大大增強了個人的自身成就感，也鼓舞了團隊士氣。對項目管理者更好的了解測試人員個體打開了一個直接的窗口。

3.3.3 三方系統對接功能分析

目前大多數管理系統都是某一公司或集團為了具體的問題所做的一個私有的，無法和其他第三方系統對接的內部管理系統。但軟件測試活動屬于一個流程化、規范化的活動。這個活動產生的一些公開的數據是可以作為優化和提高該系統的市場生存能力而存在的。為了增強自身在市場上的競爭性，管理系統引入第三方對接功能，可以更好利用成熟的通訊工具進行高效的溝通；可以利用知名度高的求職系統進行個人簡歷的展示；可以利用交互友好的游戲系統提高工作的輕松度。

3.3.4 系統設置功能分析

為了各個模塊能高效有機的整合在一起，需要一個獨立的功能對系統本身的各項基本參數做到可配置，系統人員做到可管理，系統權限做到可調節。而系統設置就是將這些功能良好的管理起來，從而使得整個軟件測試管理系統可以正常運轉。

3.4數據模型及系統其它需求

3.4.1 測試系統數據模型

圖 3-2-圖 3-10 為該系統的用例圖：

1)測試需求管理

圖 3-2 測試需求管理用例圖

該圖描述了測試需求的添加人員和測試需求具體功能的關系，使用者添加測試需求，并對測試需求進行修改，還可以按條件查詢添加的測試需求，對不再使用的測試需求可以進行刪除操作。

2）測試計劃制定

該圖描述了測試計劃的添加人員和測試計劃具體功能的關系，使用者添加測試計劃，并對測試計劃進行修改，還可以按條件查詢添加的測試計劃，對不再執行的測試計劃可以進行刪除操作。

3）測試用例管理

該圖描述了測試用例的添加人員和測試用例具體功能的關系，使用者添加測試用例，并對測試用例進行修改，還可以按條件查詢添加的測試用例，對不再執行的測試用例可以進行刪除操作。

4）測試用例執行

圖 3-5 測試用例執行用例圖

該圖描述了使用者與測試用例執行的必要條件和情況的關系，使用者針對具

體測試計劃，對測試人員和測試工具進行分配，并在測試過程中查詢測試進度，

以及測試完成后查詢測試的結果。

5）產品缺陷管理

該圖描述了使用者與產品缺陷功能的關系，使用者錄入測試用例發現的產品缺陷，并指定具體的開發人員修復相應的產品缺陷。使用查詢功能可以查詢當前產品的缺陷列表。

6）測試報告統計

該圖描述了使用者和測試報告統計模塊的關系。使用者使用指定的報告樣式，

可以輸出缺陷報告、測試報告和總體報告。

7）測試人員成就

該圖描述了使用者和測試成就模塊的關系。使用者使用指定的成就樣式，可以輸出個人成就和團隊成就。

8）三方系統對接

該圖描述了使用者和三方對接模塊的關系。使用者可以使用預先按照規范定義好的領英、微信、游戲這三方的不同接口，分別調用具體的接口 API 和不同系統集成。

9)系統設置

該圖描述了使用者和系統配置模塊的關系。使用者可以配置系統本身的不同參數，也可以管理系統的基礎用戶數據，包括用戶信息和權限信息。

3.4.2 測試系統其他需求

除了上述的對系統的測試之外，在實際的操作中，還需要對系統的安全性能進行測試，在系統的安全測試中，需要對多個層面進行測試，以及結合各種的測試方法來完成。一般而言，對系統的安全性測試，需要對其功能方面的安全性、數據方面的安全性等進行考慮，這些方面的考慮需要根據實際的使用來進行設計。在系統的訪問過程中，是相對獨立的過程，服務端會根據客戶端所發送的請求進行數據的調用和反饋等。在對系統的安全性考慮方面，最基礎的就是對訪問系統用戶的權限進行分配，不同的用戶系統分配不同的權限，而權限的設置也能夠在一定的程度上保證了系統的安全性，這也是需要充分的考慮來完成的。

對軟件性能的測試，能夠使得衡量一個軟件系統性能的常見指標響應時間

(Response time)，吞吐量(Throughput)，資源使用率(Resource utilization), 點擊數(Hits per second)，并發用戶數(Concurrent users),而系統出現故障到自動恢復所經過的時間等，都能夠作為系統性能測試的重要的指標。

計算機硬件的選擇取決于數據的處理方式和要運行的軟件。對于數據處理是集中式的，則采用單主機多終端模式，以大型或高性能小型機為主機，使系統具

有較好的性能。對于一定規模的企業，如果其管理應用是分布式的，則所選計算機系統的計算模式也應是分布式的。一般來說，計算機機型選擇主要考慮應用軟件對計算機處理能力的要求，在硬件選擇時應選擇技術上成熟可靠的系統機型。

虛擬化技術是當今企業熱門技術之一，虛擬化產品允許一個平臺同時運行多個操作系統。它可以根據虛擬化程度以及虛擬機監控［19］層的實現層次進行不同的分類，允許多個操作系統相互不影響的運行，有效提高了硬件的利用率和安全性。

開源產品具有花費很少（如果有的話），許可費用，易于管理，連續，實時改進，公司獨立，實踐的探索。充分利用開源軟件的長處，使用開源開發工具和開源社區的產品，自由［20］高效的搭建起一個高可用性，高伸縮性，高安全性的軟件測試信息管理系統。

3.5 本章小結

本章主要對系統的需求進行了背景分析和需求細化，進一步闡述清楚了系統的模塊劃分，以及功能性模塊和非功能性模塊的定義。

第四章系統詳細設計

4.1 系統架構設計

項目使用基于MVC設計思想的SSH框架［21 ］集合。MVC的結構主要是包含了系統的模型、視圖和控制器三方面，因此，能夠將系統的結構分為三個層面。

1）第一層，系統的視圖層面，是用戶進行操作的平臺，也是系統的“外殼”，直接面向用戶。

2）第二層，系統的控制層面，該層面能夠保證系統的正常運作，作為用戶界面和數據核心的過渡層，完成命令的調用和反饋等功能。

3）第三層，系統的數據層，數據層是系統的核心所在，也是系統開發的基礎，為系統的運行提供了數據支持。

圖 4-1 SSH 架構圖

SSH結構在上文也進行了介紹，其中：

Struts 主要負責 Web 層的設計：

Struts 能夠控制業務邏輯的跳轉，并結合 Hibernate 對系統的數據持久層提供

幫助。通過接受到的數據，經過Action的處理后，為ActionServlet的加載提供了

基礎條件。

Spring 主要負責業務層的管理：

Spring 作為框架的管理者，能夠對 Hibernate 和 Struts 進行管理，除此之外， Spring 還能夠實現分離的功能，能夠對系統的業務邏輯和數據持久層進行分離，這種分離不僅能夠減輕系統工作的負荷，還能夠提高系統的工作效率。

Hibernate 主要負責系統的持久層：

在Hibernate中，定義了 hbm.xml文件和PO，這兩個文件都是與系統數據庫里相應的表格相對應的，在軟件中實現對數據庫調用的功能。

在 SSH 中，其關系和數據調用如下圖所示：

1）系統運行平臺。本系統為企業級應用系統。運行在基于開源Linux［22］發行版本 Ubuntu14.04 LTS 的 X86_64 服務器上，可以確保提供高可靠性，高穩定性，高性能的服務器運行平臺。

2）程序架構模式。本系統具有較強的協同分布式［23］交互性。為了便于一個項目的不同地區的項目組可以協調一致的工作，采用了基于 B/S 架構的軟件產品設計，可以確保易于維護和擴展，降低對客戶端的要求。

3）應用服務器。應用服務器是提供服務的平臺，運行著JAVA企業級組件。選用 Jetty 作為服務器實現，是因為該服務器具有比較好的引擎模塊，除此之外，它的框架也比較簡單，便于日后的維護和拓展工作的開展。作為一個標準的 Servlet 引擎，它支持標準的 Servlet 規范和 Java EE 的規范。

4）數據庫服務器。 MariaDB 數據庫是 MySQL 數據庫中的一個分支，也是在 MySQL 6.0的基礎上開發的，它與MySQL一樣，都屬于免費開源的數據庫服務器。選用 MariaDB 作為數據服務器，相比 MySQL 擁有更多的功能、更快、更穩定、 BUG 修復更快。

5）集成開發環境。Eclipse［24］是一個功能強大的開發環境，能夠為插件提供統一的、集成化的開發環境，除此之外，在Eclipse中的Maven還是一個能夠構建項目的工具，便于對項目的生命周期進行管理［25］。 Git 的快照記錄和近乎本地化操作，為敏捷［26］高效地處理項目提供了可能性。

綜上所述，系統采用的軟件配置表如表 4-1 所示：

表 4-1 系統軟件配置

服務器操作系統 Ubuntu 14.04 LTS

應用服務器 Jetty

數據庫服務器 MariaDB

集成開發環境 Eclipse

運行平臺 IE， Firefox， Chrome

開發技術 SSH, Git, Maven 等

其軟件配置方案如圖 4-3 所示。

圖 4-3 系統架構圖

4.2 系統模塊綜合

該系統基于JAVA EE的軟件測試信息管理系統，根據需求分析和主要業務流程，該系統是一個對測試的各階段相關信息進行合理的、有效的管理綜合平臺。其中總共設計了九個子模塊。包括對測試需求的管理、計劃制訂和用例管理、以及測試用例執行模塊，產品缺陷管理模塊，測試報告統計模塊，測試人員成就模塊，三方系統對接模塊，系統設置模塊。各子模塊自身實現高度聚合，模塊之間基于RESTful[27]協議API訪問，大大降低了耦合度，有利于系統的維護和升級，增加的系統的可擴展性。

表4-2說明了各大模塊所需要具備的基本功能：

表 4-2 系統模塊功能

系統模塊功能

測試需求管理增加

修改

續表 4-2 系統模塊功能

刪除

查詢

測試計劃管理增加

修改

刪除

查詢

測試用例管理增加

修改

刪除

查詢

用例執行管理人員分配

工具分配

進度查詢

結果查詢

產品缺陷管理缺陷錄入

缺陷指定

缺陷查詢

測試報告統計報告樣式管理

缺陷報告輸出

測試報告輸出

總體報告輸出

測試人員成就成就樣式管理

個人成就輸出

團隊成就輸出

三方系統對接領英系統接口

微信系統接口

游戲系統接口

系統配置系統參數配置

系統用戶管理

用戶權限管理

4.2.1 測試需求管理詳細設計

在對軟件的需求管理測試的過程中，最主要的是對軟件質量實際需求的測試方面的要求。該模塊會涉及到新舊測試需求的管理，對于舊的紙質化測試需求需要進行無紙化錄入，對于舊的電子化測試需求需要考慮支持導入功能，目前由于時間有限，暫不在第一版中提供此功能，均會通過測試人員錄入管理系統。錄入系統的測試需求信息方便查閱，不需要人工維護文檔的版本和存放位置。添加和刪除舊的測試需求信息也可以輕松在Web界面完成。軟件測試信息管理系統的測試需求管理的功能主要包括測試需求增加、修改、刪除和查詢。

1）測試需求增加。管理員選擇添加需求，打開一個空白測試需求表單供管理員填寫。填寫完畢后，點擊“提交”，系統顯示處理頁面，檢查各項輸入信息無誤后，寫入數據庫中。

2）測試需求修改。管理員選擇修改需求，系統從數據庫中讀取用戶添加進系統的軟件測試需求，并展現給用戶。修改完畢后，點擊“提交”，系統校驗輸入信息無誤后保存。

3）測試需求刪除。管理員選擇刪除需求，勾選完畢后，點擊“提交”，系統會向操作者提出進一步的提示，提示操作者是否確認對需求進行刪除，當操作者再次點擊刪除后，系統會對操作者給予“成功刪除”的信息提示。

4）測試需求查詢。在該環節中，管理員調用查詢的需求，并輸入需要查詢的內容，然后點擊查詢按鈕，數據庫執行 select 查詢命令，即可檢索出符合條件的測試需求進行顯示。下圖為測試需求實體E-R圖

測試需求

廠

圖 4-4 測試需求實體圖

4.2.2 測試計劃管理詳細設計

測試計劃制定，為項目新添加一個測試計劃，必須要有測試計劃才能進行測試用例的添加和測試的執行。該模塊包含錄入已有的紙質或excel[28]版本的測試計劃，錄入成功后，方便后期測試計劃的更改，無須再維護原有的測試計劃資料。錄入成功的測試計劃信息，可以方便測試計劃制定者和項目管理者在Web界面上查詢到，又可以方便對測試計劃的修改和刪除，無須擔心所得到的版本不是最新的。測試計劃制定主要實現的功能：測試計劃修改、刪除、增加、查詢。

1）測試計劃增加。管理員選擇添加計劃，打開一個空白測試計劃表單供管理員填寫，管理員填寫完測試計劃后，選擇已有測試需求選項關聯，點擊“提交”，系統顯示處理頁面，檢查各項輸入信息無誤后，寫入數據庫中。

2）測試計劃修改。管理員選擇修改計劃，系統從數據庫中讀取用戶添加進系統的軟件測試計劃，并展現給用戶。修改完畢后，點擊“提交”，系統校驗輸入信息無誤后保存。

3）測試計劃刪除。管理員通過選擇需要刪除的計劃，然后勾選刪除按鈕，勾選完畢后，點擊“提交”，系統會向操作者提出進一步的提示，提示操作者是否確認對需求進行刪除，當操作者再次點擊刪除后，系統會對操作者給予“成功刪除 ” 的信息提示。

4）測試計劃查詢。在該環節中，管理員調用查詢的需求，并輸入需要查詢的內容，然后點擊查詢按鈕，數據庫執行 select 查詢命令，即可檢索出符合條件的測試計劃進行顯示。下圖為測試計劃實體E-R圖

4.2.3 測試用例管理詳細設計

測試用例管理，對項目的測試用例進行管理。該模塊包含對原有紙質和電子版本的測試用例進行錄入，第一次錄入會相對比較耗時，一旦錄入第一個用例成功后，后續的錄入可以復制修改。特別是可以縮短修改大量重復前置條件方面。對錄入成功的測試用例可以批量選擇，查看具體的測試用例不需要去大量用例里面肉眼比對，只需要輸入指定用例的關鍵字即可進行模糊查找。大大方便了測試用例的編寫人員和執行人員，提高了工作效率。其主要包含測試用例的增刪改查。

1）測試用例增加。管理員選擇添加用例，打開一個空白測試用例表單供管理員填寫，管理員填寫完測試用例后，選擇已有測試計劃選項關聯，點擊“提交”，系統顯示處理頁面，檢查各項輸入信息無誤后，寫入數據庫中。

2）測試用例修改。管理員選擇修改用例，系統從數據庫中讀取用戶添加進系統的軟件測試用例，并展現給用戶。修改完畢后，點擊“提交”，系統校驗輸入信息無誤后保存。

3）測試用例刪除。管理員選擇刪除用例，勾選完畢后，點擊“提交”，系統會向操作者提出進一步的提示，提示操作者是否確認對需求進行刪除，當操作者再次點擊刪除后，系統會對操作者給予“成功刪除”的信息提示。

4）測試用例查詢。在該環節中，管理員調用查詢的需求，并輸入需要查詢的

內容，然后點擊查詢按鈕，數據庫執行 select 查詢命令，即可檢索出符合條件的

4.2.4 用例執行管理詳細設計

測試用例執行，根據設計好的測試用例，進行人工執行測試。該模塊將先前通過郵件和口頭分配的信息，進行了綜合管理，用Web界面的方式展示測試執行人員任務分配情況和測試環境［29］資源可用情況。有效避免了信息的不一致，導致地資源競爭。并可以根據測試用例執行的情況，展示出整個測試計劃的執行進度。讓項目管理人員直觀地了解測試總體情況。相對于以往的信息不對等和溝通的滯后性，使用關鍵字查詢就可以在管理系統中查詢到所需要的信息。其實現的主要功能有執行人員分配、執行工具分配、執行進度查詢、執行結果查詢。

1）執行人員分配。當新的測試集被創建時，需要分配人員測試，可以選擇添加更多的測試人員，并在選定測試人員后，在數據庫中會自動記錄測試計劃編號和對應的測試人員。當測試集測試完畢后，所有人可以通過測試報告輸出界面查看測試結果，也可以通過個人成就輸出界面查看指定測試人員的測試任務成果。

2）執行工具分配。當新的測試集被創建時，需要分配測試資源（軟硬件），可選的測試資源是系統用戶管理界面添加的測試資源。測試資源指定后，數據庫會自動記錄測試計劃編號和對應的測試資源。當測試集測試完畢后，所有人可以通過測試報告輸出界面和總體報告輸出界面查看執行工具使用頻繁度，一般以紅色或紫色字體在報告中突出顯示。

3）執行進度查詢。系統按照測試計劃分類，在單一頁面上展示每個測試計劃的執行情況，以進度條輔以百分比顯示，需要具體查看個測試用例執行進度情況，點擊進度條，即可展開各用例完成情況。

4）執行結果查詢。管理員選擇查詢結果，輸入要查詢的測試計劃關鍵字，點擊“查詢”，數據庫執行 select 查詢命令，即可檢索出符合條件的測試計劃進行顯示。顯示結果以顏色區分成功失敗，紅色表示失敗，綠色表示成功。點擊查詢結果，即可展開子用例執行結果。下圖為用例執行實體E-R圖

4.2.5 產品缺陷管理詳細設計

產品缺陷管理，根據測試結果，記錄產品不同級別的缺陷，方便跟蹤問題狀態。該模塊會對之前使用的其他系統的缺陷信息，進行人工錄入，后期會添加自動導入功能，對錄入的缺陷信息關聯上測試用例和測試人員，方便后期測試報告的輸出。項目管理者可以方便的在界面上選擇空余開發人員解決出現的產品缺陷，避免了口頭或郵件的信息不一致和時效滯后性。其主要功能包括產品缺陷錄入、解決人員分配、產品缺陷查詢。

1）產品缺陷錄入。測試人員選擇添加缺陷，打開一個空白缺陷錄入表單供測試人員填寫，測試人員填寫完缺陷描述后，選擇已有測試用例選項關聯，點擊

“提交”，系統顯示處理頁面，檢查各項輸入信息無誤后，寫入數據庫中。

2）解決人員分配。當新的缺陷被創建時，需要分配人員解決，可選的開發人員是系統用戶管理界面添加的開發人員。開發人員指定后，數據庫會自動記錄缺陷編號和對應的開發人員。當缺陷解決后，所有人可以通過測試報告輸出界面查看測試結果，也可以通過個人成就輸出界面查看指定開發人員的解決任務成果。

3）產品缺陷查詢。所有人可以選擇查詢結果，輸入要查詢的產品缺陷關鍵字，點擊“查詢”，數據庫執行 select 查詢命令，即可檢索出符合條件的產品缺陷進行顯示。下圖為產品缺陷實體E-R圖

4.2.6 測試報告統計詳細設計

測試報告統計，是生成測試報告，方便從不同角度和級別對產品需求的完成情況進行統計。該模塊使用系統已有的測試活動數據，可以輕松生成默認的簡單版本的測試報告，提高了報告的時效性，降低了報告數據搜集的難度。對于不同的報告閱讀者，還可以選擇不同的樣式，來輸出信息量不同的測試報告。其包括的主要功能有報告樣式管理、缺陷報告輸出、測試報告輸出、總體報告輸出。

1）報告樣式管理。管理員選擇添加報告樣式，打開一個空白樣式錄入表單供管理員填寫，管理員勾選要輸出的報告信息選項，本地修改并上傳 CSS 樣式文件，點擊“提交”，系統顯示處理頁面，檢查各項輸入信息無誤后，寫入數據庫中。

2）缺陷報告輸出。所有人選擇查詢缺陷報告，輸入要查詢的測試計劃關鍵字，點擊“查詢”，數據庫執行 select 查詢命令，即可檢索出符合條件的測試計劃的缺陷報告進行顯示。指定樣式后，即可顯示或打印。

3）測試報告輸出。所有人選擇查詢測試報告，輸入要查詢的測試計劃關鍵字，點擊“查詢”，數據庫執行 select 查詢命令，即可檢索出符合條件的測試計劃的測試報告進行顯示。指定樣式后，即可顯示或打印。

4）總體報告輸出。所有人選擇查詢總體報告，輸入要查詢的測試計劃關鍵字，點擊“查詢”，數據庫執行 select 查詢命令，即可檢索出符合條件的測試計劃的總體報告進行顯示。指定樣式后，即可顯示或打印。下圖為測試報告實體E-R圖

4.2.7 測試人員成就詳細設計

測試人員成就，完整記錄測試人員的測試工作情況，如編寫測試計劃，測試用例，提交缺陷等一系列成就。該模塊可以有效利用已有的測試活動數據，例如用例執行模塊、缺陷管理模塊等這些模塊的數據，按照測試人員個人或團隊為單位，生成一個測試人員用例執行情況，缺陷提交情況的詳單。從而讓管理這更加了解一個測試團隊的每個人的工作情況。生成的圖表還可以根據選擇不同的需要變換樣式。其功能主要包含成就樣式管理、個人成就輸出、團隊成就輸出。

1）成就樣式管理。管理員選擇添加報告樣式，打開一個空白樣式錄入表單供管理員填寫，管理員勾選要輸出的報告信息選項，本地修改并上傳 CSS 樣式文件，點擊“提交”，系統顯示處理頁面，檢查各項輸入信息無誤后，寫入數據庫中。

2）個人成就輸出。所有人選擇查詢個人成就，輸入要查詢的人員關鍵字，點擊“查詢”，數據庫執行 select 查詢命令，即可檢索出符合條件的測試計劃的人員成就進行顯示。指定樣式后，即可顯示或打印。

3）團隊成就輸出。所有人選擇查詢團隊成就，輸入要查詢的測試計劃關鍵字，點擊“查詢”，數據庫執行 select 查詢命令，即可檢索出符合條件的測試計劃的團隊成就進行顯示。指定樣式后，即可顯示或打印。下圖為人員成就實體E-R圖

4.2.8 三方系統對接詳細設計

三方系統對接，按照第三方系統生成測試人員工作數據，提高求職的職位契合度，增強工作在社交方面的正向作用。其主要是根據和第三方系統約定好的協議，生成相應的 Provisioning 用戶數據。由于領英的提供了較完備的 Restful 接口，選擇領英可以降低系統非功能性修改程度。微信同樣也提供了第三方登陸的標準接口，方便本系統的集成。游戲接口主要選擇行業標準協議 SOAP 接口，為產品二次開發做準備。其主要包括領英系統接口、微信系統接口、游戲系統接口。

1）領英系統接口。系統提供了滿足Restful規范的領英第三方接口，測試或開放人員自身可以選擇授信領英，讀取該系統成就管理信息，展示在領英界面，使得職業信息實時化。

2）微信系統接口。系統提供了滿足聯合登錄的微信第三方接口，測試或開放人員自身可以選擇使用微信賬戶登錄本系統，使得人員信息管理便捷。

3）游戲系統接口。系統開放了人員成就信息接口，提供充分的人員信息，為 3D 化，游戲化測試信息管理系統提供了基礎數據，同時也可以接入已有的滿足 Restful協議，SOAP協議的游戲。下圖為三方系統實體E-R圖

4.2.9 系統設置詳細設計

系統設置，該模塊主要是對本系統基本參數、日志管理、用戶訪問權限、以及用戶基本信息的管理。其主要包含系統參數管理、用戶管理以及權限管理。

1）系統參數管理。系統參數主要是跟全局業務配置相關的數據。系統日志設置了系統所有操作記錄路徑。用戶希望使用其它數據庫來作為系統的數據庫時，可以通過系統數據庫配置功能，將系統運行需要表和數據初始化到生產庫或者將添加的表和字段升級到已有生產庫中。再連接初始化或者升級后的生產庫來使用系統。口令加密類配置，可以按照配置好的加密算法進行加密，在數據庫中存儲加密后的密碼，這里的口令加密是不可逆的，在加密后不進行解密

2）系統用戶管理。管理員為系統默認用戶，管理員添加使用該系統的不同角色，開發人員、測試和管理的人員，其中，管理人員擁有最高的權力，能夠對系統的所有人員進行管理，并刪除不再使用該系統的人員。

3）用戶權限管理。管理員輸入具體用戶名，查詢出所需用戶，對用戶權限進行相應勾選，如開發人員不應有修改用例和修改缺陷的為“已驗證”的權限。下圖為系統設置實體E-R圖

下圖為軟件測試信息管理系統的系統E-R圖

圖4-13軟件測試信息管理系統E-R圖

4.3數據庫表詳細設計設計

本系統選用MariaDB作為關系型數據庫[30], —方面避免了 Mysql數據庫非開源的不可維護性，另一方面又可以利用新增的功能，便捷高效的實現數據存儲。比如支持更多的存儲引擎，像Aria、XtraDB等、速度提升、引入了基于表的多線程［31 ］并行復制技術、引入了線程池thread pool技術、在處理內部的臨時表時，用 Aria引擎代替了 MylSAM引擎。為了實現本系統的設計，除系統配置模塊，每個模塊設計一個數據庫表，其內容能夠包括測試的需求管理、計劃管理、用例管理等，以及產品缺陷管理表，測試報告統計表，測試人員成就表，三方系統對接表，用戶信息表，用戶權限表，系統配置表。

軟件測試信息管理系統是一個 B/S 結構的重服務端系統，瀏覽器端只需通過網絡［32］良好地解析服務器傳輸的信息，數據存儲系統也就成了重中之重了。每個功能模塊都需要訪問數據庫讀取和寫入該模塊相關的信息，不同的數據庫表之間相互的聯系就構成了整個測試信息管理系統的數據結構。所有涉及的信息和種類都會在該數據結構下統一的管理。因此，在下文的內容中，主要對系統中搭建的各個模塊進行詳細的介紹。

1）測試需求管理表：是對系統測試所需要的各種需求進行記錄，包括了每一層面的需求和上下層面的需求，該表通常會以樹狀的［33］結構來呈現，并能夠與其他的功能模塊相連接。

主鍵：需求編號，用來唯一標識需求

需求描述：用來簡要描述需求具體內容需求版本：用來跟蹤需求修改版本需求級別：用來區分需求之間的從屬關系，例如1.1.1為1.1的一個子需求補充注釋：擴展字段

表 4-3 測試需求管理表

字段描述類型（長度）主鍵否空允許

t reqNo 需求編號 int(4) 是否

t reqDesc 需求描述 varchar(500) 否否

t reqVersion 需求版本 varchar(10) 否否

t reqLevel 需求級別 varchar(100) 否否

t reqComments 額外描述 varchar(200) 否是

2）測試計劃管理表：記錄測試計劃的執行時間，以及測試類型。主鍵：測試計劃編號，用來唯一標識測試計劃計劃描述：用來簡要描述測試計劃計劃開始時間：用來標識測試計劃預計開始時間計劃結束時間：用來標識測試計劃預計結束時間補充注釋：擴展字段

表 4-4 測試計劃管理表

字段描述類型（長度）主鍵否空允許

t planNo 計劃編號 int(4) 是否

t planDesc 計劃描述 varchar(500) 否否

t planStartTime 開始時間 timestamp 否否

t planEndTime 結束時間 timestamp 否否

t planComments 額外描述 varchar(200) 否是

3）測試用例管理表：記錄測試用例的添加，修改，更新和刪除等信息。并給

出一些統計數據

主鍵：用例編號，用來唯一標識用例外鍵：一個或多個測試需求，外鍵標識用例描述：用來簡要描述用例場景用例創建時間：標識用例的創建時間用例創建者：標識用例的創建者

用例等級：按T1，T2，T3區分，數字越大優先級越低

補充注釋：擴展字段

表 4-5 測試用例管理表

字段描述類型（長度）主鍵否空允許

t caseNo 用例編號 int(4) 是否

t caseDesc 用例描述 varchar(500) 否否

t caseCreateTime 創建時間 timestamp 否否

t caseCreator 創建人 varchar(20) 否否

t caseComments 額外描述 varchar(200) 否是

t caseLevel 用例級別 varchar(5) 否否

t caseReq 需求關聯 int(4) 外鍵否

4）用例執行管理表：記錄測試環節中的進度和任務的執行情況，能夠對測試

的內容、用例等信息進行記錄，便于操作人員的跟蹤和觀察。

主鍵：測試任務編號，用來唯一標識測試任務外鍵一：一個或多個測試計劃外鍵二：一個或多個測試用例執行描述：用來簡要描述測試執行的內容執行開始時間：記錄測試用例執行預計開始時間執行結束時間：記錄測試用例執行預計結束時間測試結果：按 PASS 或 FAIL 區分

補充注釋：擴展字段

表 4-6 用例執行管理表

字段描述類型（長度）主鍵否空允許

t runNo 執行編號 int(4) 是否

t runDesc 執行描述 varchar(500) 否否

t runStartTime 開始時間 timestamp 否否

t runEndTime 結束時間 timestamp 否否

t runComments 額外描述 varchar(200) 否是

t runResult 執行結果 varchar(10) 否否

t runPlan 計劃關聯 int(4) 外鍵否

t runCase 用例關聯 int(4) 外鍵否

5）產品缺陷管理表：記錄測試用例執行過程中，發現的產品缺陷信息。主要

包括缺陷狀態，提交時間，處理時間，解決時間，提交人員，解決人員等。

主鍵：缺陷編號，用來唯一標識產品缺陷外鍵：測試用例編號，觸發缺陷的測試用例缺陷描述：詳細描述缺陷的觸發情況缺陷創建時間：記錄缺陷創建的時間缺陷創建者：記錄缺陷提交人

缺陷狀態：按 “ Submitted ”，“ Assigned "，‘' Solved ”，“Verified ”， “Closed ”區分

缺陷類型：按 “Requirement "‘“Design”，“ Implement ”，“Not a Fault” 區分

補充注釋：擴展字段

表 4-7 產品缺陷管理表

字段描述類型（長度）主鍵否空允許

t defectNo 缺陷編號 int(4) 是否

t defectDesc 缺陷描述 varchar(500) 否否

t defectCreateTime 創建時間 timestamp 否否

t defectCreator 提交人 varchar(20) 否否

t defectComments 額外描述 varchar(200) 否是

t defectCase 用例關聯 int(4) 外鍵否

t defectStatus 缺陷狀態 varchar(50) 否否

t defectType 缺陷類型 varchar(50) 否否

6）測試報告統計表：匯總統計測試用例執行情況，缺陷提交記錄，對應需求覆蓋度，小結出測試計劃完成情況。

主鍵：報告編號，用來唯一標識測試報告

外鍵一：測試任務編號，關聯任務外鍵二：一個或多個缺陷編號，相關的產品缺陷集合外鍵三：一個或多個需求編號，涉及的一個或多個需求報告描述：簡要描述測試報告內容

報告時間：記錄測試報告生成時間

報告人：記錄測試報告提交人

報告式樣：報告按指定的式樣格式輸出

補充注釋：擴展字段

表 4-8 測試報告統計表

字段描述類型（長度）主鍵否空允許

t reportNo 報告編號 int(4) 是否

t reportDesc 報告描述 varchar(500) 否否

t reportTime 報告時間 timestamp 否否

t reporter 報告人 varchar(20) 否否

t reportComments 額外描述 varchar(200) 否是

t reportPlan 計劃關聯 int(4) 外鍵否

t reportDefect 缺陷關聯 int(4) 外鍵否

t reportReq 需求關聯 int(4) 外鍵否

t reportStyle 報告樣式 varchar(10) 否否

7）測試人員成就表：總結參與測試的人員任務達成情況，其中包含用例執行

情況，缺陷提交情況。主鍵：成就編號，用來唯一標識達成成就外鍵一：用戶編號，一個或多個測試參與人員外鍵二：缺陷編號，提交的缺陷信息外鍵三：用例編號，執行的測試用例信息成就描述：簡要描述測試成就的內容成就樣式：成就按指定的式樣格式輸出補充注釋：擴展字段

表 4-9 測試人員成就表

字段描述類型（長度）主鍵否空允許

t achieveNo 成就編號 int(4) 是否

t achieveDesc 成就描述 varchar(500) 否否

t achieveStyle 成就式樣 varchar(10) 否否

t achieveComments 額外描述 varchar(200) 否是

t achieveUser 人員關聯 int(4) 外鍵否

t achieveDefect 缺陷關聯 int(4) 外鍵否

t achieveCase 用例關聯 int(4) 外鍵否

8）三方系統對接表：描述系統對外提供的接口，其中包括接口類型，接口地

址，接口描述。

主鍵：接口編號，用來唯一標識三方接口

接口類型：按RESTful和SOAP區分

接口地址：符合標準的包含默認連接信息的地址接口描述：簡要描述接口使用方與功能補充注釋：擴展字段

表 4-10 三方系統對接表

字段描述類型（長度）主鍵否空允許

t interfaceNo 接口編號 int(4) 是否

t interfaceDesc 接口描述 varchar(500) 否否

t interfaceType 接口類型 varchar(50) 否否

t interfaceUri 接口地址 varchar(100) 否否

t interfaceComments 額外描述 varchar(200) 否是

9）用戶信息表：記錄系統增加，修改，刪除的用戶信息，其中包含用戶名稱，

用戶角色，用戶描述

主鍵：用戶編號，用來唯一標識用戶信息外鍵：一個或多個用戶權限編號，描述用戶系統訪問權限用戶名稱：記錄系統使用者的登錄姓名用戶密碼：記錄系統使用者的登錄密碼

用戶角色：按“ Developer”，“ Tester”，“ Manager” 用戶描述：簡要描述用戶

補充注釋：擴展字段

表 4-11 用戶信息表

字段描述類型（長度）主鍵否空允許

t userNo 用戶編號 int(4) 是否

t userName 用戶名稱 varchar(50) 否否

t userPassword 用戶密碼 varchar(100) 否否

t userRole 用戶角色 varchar(20) 否否

t userDesc 用戶描述 varchar(500) 否否

t userComments 額外描述 varchar(200) 否是

t userPermit 用戶權限關聯 varchar(20) 外鍵否

10）用戶權限表：定義用戶不同權限，其中包含權限類型，權限描述

主鍵：權限編號，用來唯一標識權限信息

權限類型：按“ Writable "‘“Readable"

權限描述：簡要描述權限類型

補充注釋：擴展字段

表 4-11 用戶權限表

字段描述類型（長度）主鍵否空允許

t permitNo 權限編號 int(4) 是否

t permitDesc 權限描述 varchar(500) 否否

t permitType 權限類型 varchar(50) 否否

t permitComments 額外描述 varchar(200) 否是

11 ）系統配置表：定義系統自定義配置，其中包含配置名稱，配置描述主鍵：配置編號，用來唯一標識系統配置配置名稱：系統配置的簡稱

配置描述：簡要描述系統配置的用途補充注釋：擴展字段

表 4-12 系統配置表

字段描述類型（長度）主鍵否空允許

t sysConfigNo 系統配置編號 int(4) 是否

t sysConfigDesc 系統配置描述 varchar(500) 否否

t sysConfigComments 額外描述 varchar(200) 否是

依據以上各模塊數據庫表的設計，現繪制出數據庫表之間的實體關系圖，如

圖 4-15

圖 4-14 數據庫表 E-R 圖

4.4 本章小結

本章主要對系統的各大模塊進行了詳細的設計與介紹。結合主流技術，詳細描述了系統使用的架構、技術，并根據設計需求，細節化了各個模塊的具體功能定義。由此進行數據庫表結構的設計，接下來的章節會基于本章的設計細節詳述產品實現的部分。

第五章系統具體實現

5.1 系統的開發環境簡介

開發主機：高性能PC機一臺

操作系統： windows 10 的 64 位版本

開發語言： Java， html5， SQL

客戶端： IE11/Firefox58/Chrome64

應用軟件： JDK， Eclipse， WebStorm

服務端： JavaEE Server

數據庫： MariaDB

5.2 系統的總體技術實現

5.2.1 系統的前端技術實現

該系統前端采用 JQuery+HTML5 編寫測試管理系統的頁面，一方面借鑒成熟開源社區成果，縮短開發周期；另一方面減少后期的維護成本和增加系統的生命周期。JQuery非常輕巧，其占用的存儲單元不足30KB，并能夠對其進行進一步的壓縮，將其縮小至18KB。Jquery有著很好的兼容性，能夠為開發者提供大多數的選擇器。在 Jquery 中對事件處理的機制相當可靠。除此之外， Jquery 還能夠實現封裝的功能，令操作者能夠專心進行開發，不用考慮客戶端瀏覽器的兼容問題。 Jquery 也能夠對數據庫實現兼容，使開發者不必在開展項目前建立瀏覽器兼容庫。 JQuery 目前已經有超過幾百種官方插件支持，文檔非常豐富，如此強大的 JQuery 配合能夠跨平臺和簡化語法并增加組件的HTML5，能讓開發更容易些。

5.2.2 系統的后端技術實現

該系統后端目前采用Jetty服務器+MariaDB數據庫，配合Redis[34吶存數據庫, 在確保數據訪問的正確性和穩定性的前提下，提高數據的訪問速度。選擇 Jetty，主要是出于管理系統發展的長遠考慮。 Jetty 更加容易定制成其中的一部分。 Tomcat 太大太復雜，很多特性根本不需要。 Tomcat 用在小型的項目中絕對是不錯的，性能很好，可如果你的并發訪問用戶超過 50 了，其性能和穩定性就沒有 Jetty好了。Jetty運行于模塊化的架構之上，如HTTP和JMX等模塊。Jetty能夠作為一個獨立的引擎，從而為 web 提供服務，而它也能夠與其它 web 實現集成的功能，因此，它在實際工作中能夠提供 HTTP 和 AJP 協議的服務。正式由于這個特性，初期可以提高測試管理系統的開發效率，只需要知道 Handler 的配置規則，按照產品需求進行擴展和裁剪，而不需要過多了解這個容器本身的運轉原理。隨著后期的功能增多，仍然可以按照責任鏈模式的規則，配置自己的處理單元，和原有的模塊集成使用。同樣的，為了提高消息處理的速度，使用 Redis 作為前置數據庫，在高并發需求時，優先訪問內存數據庫里面的內容，在閑時進行內存和實體數據庫的信息同步。這可以大大提高整體系統的訪問友好性。對那些訪問量大的信息存放在 Redis 里面，比如用戶信息、測試用例、執行進度、缺陷信息。利用Redis能支持超過100K+每秒的讀寫頻率，可以減少對實體數據庫的訪問次數。

5.3系統的模塊具體實現

5.3.1 系統設置具體實現

用戶通過登錄模塊進入系統，并選擇相應模塊進行操作，如果用戶已經注冊或錄入，只需要輸入用戶名和密碼即可。該模塊使用Ajax的異步訪問機制，會對用戶輸入登陸信息和后臺Redis讀取的信息進行合法性校驗。

系統登錄分為Login。、Logout()這2個action，它們將會用到實體model的 POJO對象將內存數據固化到數據庫里。以下為登陸功能的主要實現：

Login()方法接收到前端來自HttpRequest傳來的parameters參數，使用 Parameter 的類定義好的 PASSWORD 和 USER_ID 類型，獲得傳入的 user_id 和 password。并對傳入的參數進行基本的非空校驗。如果對象為空，即拋出 Exception錯誤提示：必要的參數缺失。如果內容為空，即跑出傳入參數不合法。

Logout()方法接收到來自HttpRequest傳來的parameters參數，使用Parameter 的類定義好的 IS_LOG_OUT、 USER_ID 和 REDIRECT_URI 類型，獲得傳入的 user_id、 islogOut 和 redirectURI 信息。并對傳入的參數進行基本的校驗。如果對象為空，即拋出Exception錯誤提示：必要的參數缺失。如果內容為空，即拋出傳入參數不合法。如果檢查 isLogOut 為真，即表示需要登出，將調用 chekLogOutUserId()方法對需要登出的userId進行資源回收和其他相關工作。

if (userId == null) {

throw new CommonException(CommonError.REQUIRED_PARAMETER_MISSING, new String[] { userId });

}

if (Utils.isBlank(userId)) {

throw new

CommonException(CommonError.REQUIRED_PARAMETER_INVALID, new String[] { userId });

}

if (password == null) {

throw new CommonException(CommonError.REQUIRED_PARAMETER_MISSING, new String[] { Parameter.PASSWORD });

}

if (Utils.isBlank(password)) {

throw new CommonException(CommonError.ACCOUNT_LOGIN_FAILURE, Parameter.PASSWORD);

} 以上代碼主要是對登錄的用戶輸入的用戶名和密碼在數據庫中進行比對，當用戶所輸入的信息通過比對是錯誤時。系統會反饋相應的信息。用戶也可以求助系統管理員進行密碼的重置服務。用戶登出系統時，會釋放用戶會話信息。

圖 5-1 系統登錄界面

該界面展示了系統登錄的界面，用戶在登錄時，只需要輸入有效的登錄信息就能夠完成登錄操作，若忘記了這些信息，也能夠在系統反饋的信息中點擊尋求幫助的按鈕，聯系管理員找回。

用于登錄涉及的用戶信息屬于系統配置模塊，為了更好的講解實現，和系統登錄放在一起。用戶信息和權限主要分為 addUser()、deleteUser()、updateUser()、 queryUser()、addAuthorizaion()、deleteAuthorizaion () 、updateAuthorizaion () 、 queryAuthorizaion ()這 8 個 action,他們會按照 POJO 對象 User 和 Authorization 將內存數據儲存到數據庫里。系統管理員使用addUser()錄入使用該系統的項目人員信息。項目人員按照從事的項目事務不同，又分為項目/測試經理，開發人員，測試人員。系統管理員按照Group的定義來區分不同人員擁有的權限，項目/測試經理具有查閱的權利，開發人員具有查閱用例和修改提交的產品缺陷的權利，測試人員具有整個測試流程涉及過程的添加和修改的權利。系統管理員在用戶管理界面上勾選帶有單選框的 checekbox 控件對不同用戶角色給予對應權限。系統管理員可以使用addAuthorization()分配不同人員對應的權限，以便訪問系統不同資源。由于系統管理員這個角色的特殊性，該用戶為內置賬戶，無法刪除和修改，由后臺腳本錄入。

圖 5-3 新增用戶界面

addUser()方法將形參傳入的用戶基本數據userId、userRole、userDesc、 userComments、 userPermit 進行本地變量賦值，對 isEncryptionDB 進行判斷，如果為True，即表示對存入數據庫的密碼進行默認加密處理；如果為False,即用指定的算法對密碼進行加密。在保存用戶數據之前，對擁有相同 userId 的數據進行刪除，最后調用 dbPlugin 插件進行基本的 SQL 操作。

addAuthorization()方法將 AuthorizationRequest 和 client 傳入的 redirectUri、 scopes、 type 等這些數據使用通用 Util 的校驗方法 validate 進行基本校驗，分別確保 authorization 的 scope、 type 數據的正確。

if (isEncryptionDB) { userPassword = Utils.encrypt(userId + "_password");

} else { userPassword = Utils.encryptWithAlgorithm(userId + "_password",Constants.DEFAULT_ALGORITHM);

}

SqlRequest sqlRequest = new SqlRequest("delete from USER_INFO where t_userNo = '" + userId + "'");

dbPlugin.send(sqlRequest); dbPlugin.receive(new SqlResult());

以上代碼主要是對添加用戶的密碼是否加密，并選擇系統默認加密方式還是指定加密方式，并且刪除系統已有的用戶信息，為新添加做準備。

系統參數的設置，主要是對初始化的系統數據庫、日志、告警等的配置更新，包括數據庫地址、日志級別、告警級別等。

圖 5-5 參數配置界面

updateConfiguration()方法通過形參module指定的配置文件字段，如果配置字段開頭為TIS，即使用默認的tis_service_definition.xml作為配置文件加載，否則使用用戶自定義路徑和文件名加載配置文件。如果配置文件不對，結束加載過程并記錄 debug 日志，以便調試。對 xml 文件的解析使用 Jdom 的解析，解析過程會使用try ...catch塊進行捕獲，并使用定義的errorCode進行表示。

圖 5-6 系統配置流程圖

5.3.2 測試需求管理具體實現

測試的需求規劃是測試開展的必要條件，因此，在測試開展的前期，我們應該正確地知道所開發軟件的功能實現和需求的規格等信息，并將這些整體的需求拆分為多個零散的需求。為了更好體現需求的自上而下性，采用文件夾整理的方式來添加和管理測試需求。

測試需求的 action 主要分為 addRequirement() 、 deleteRequirement() 、 updateRequirement()、queryRequirement()這 4 個。

sqlRequest = new SqlRequest(

"insert into REQ_INFO(t_reqNo,t_reqDesc,t_reqVersion,t_reqLevel,t_reqComments)value s('" + reqId + "','" + reqDesc + "','" + reqVersion + "','" + reqLevel + "','" + reqComments + ")");

dbPlugin.send(sqlRequest); dbPlugin.receive(new SqlResult());

圖 5-8 需求查詢界面

addRequirement() 方法將形參傳入的用戶基本數據 reqId 、 reqDesc 、 reqComments、 reqLevel 進行本地變量賦值，對 isEncryptionDB 進行判斷，如果為 True,即表示對存入數據庫的密碼進行默認加密處理；如果為False,即用指定的算法對密碼進行加密。在保存用戶數據之前，對擁有相同reqId的數據進行刪除，最后調用 dbPlugin 插件進行基本的 SQL 操作。

操作人員能夠點擊界面中的測試需求按鈕，從而形成新的產品測試需求說明書，簡要描述標題，內容。完成編輯后，點擊需求創建的按鈕，在系統中形成具

體的測試所需目錄。具體測試需求項目包括：需求標題、需求狀態、需求類型、覆蓋用例數。此處的覆蓋用例數是為了便于對測試結果的調用，因此，在結果的反饋中，需要對需求和用例的匹配程度進行統計。

5.3.3 測試計劃管理具體實現

測試的計劃能夠為測試流程提供指導，在完整的測試計劃中，應該包含了測試的時間和計劃的版本等信息。測試人員能夠點擊系統界面中的測試計劃按鈕，進入到計劃的創建界面中，在測試計劃創建的內容中，包含了該計劃的標題和相關內容。測試人員選擇該測試計劃下面的版本管理，點擊創建的按鈕，然后創建一個新版本的計劃。測試計劃的 action 主要分為 addPlan() 、deletePlan() 、 updatePlan()、queryPlan()、configureVersion() 。

SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

TimeZone.setDefault(TimeZone.getTimeZone("UTC"));

String startTimeString = "unix_timestamp('" + sdf.format(now()) + "', 'yyyy-mm-dd hh24:mi:ss:ff')";

String endTimeString = "unix_timestamp('" + sdf.format(now() + 31536000) + "', 'yyyy-mm-dd hh24:mi:ss:ff')";

addPlan()方法將形參傳入的用戶基本數據planld、planDesc、planComments 進行本地變量賦值，使用 SimpleDateFormat 獲取當前時區的時間，保存為計劃開始時間。在保存用戶數據之前，對擁有相同 planId 的數據進行刪除，最后調用 dbPlugin 插件進行基本的 SQL 操作。

Utils.responseType(planVersion.getResponseType(), true);

Utils.type(planVersion.getType(), client.getAccess()); Utils.type(CommonConstants.CODE, client.getTypes());

Scopes(validateData(planVersion.getScopes(), client), client);

configureVersion()代碼中包含了兩個 POJO 對象：TestPlan 和 TestPlanVersion。 TestPlan用來保存測試計劃的基本信息，TestPlanVersion用來保存測試計劃的版本。使用addPlan()將新的測試計劃添加并保存為TestPlan，使用configureVersion。來添加不同的測試計劃的版本。系統會將 POJO 對象的信息序列化到數據庫保存。

圖 5-12 測試計劃流程圖

5.3.4 測試用例管理具體實現

測試用例的管理包含兩層，分為新建測試用例套、創建測試用例。在實際操作中，能夠將測試所用的用例與相關的產品功能模塊相結合，通過用例對功能進行測試。在使用測試用例的過程中，能夠通過搜索功能，從大量的用例中找到適合的用例，也能夠通過復制將用例放在項目中。測試用例的 action 主要有

addTestSuite() 、 deleteTestSuite() 、 updateTestSuite() 、 queryTestSuite() 、

addTestCase() 、 deleteTestCase() 、 updateTestCase() 、 queryTestCase() 。以 addTestSuite()和addTestCase()為例，其他修改，刪除和添加類似。

for(List case: suites){

Integer caseId = case.getCaseId();

String userName = caseId + "_caseCreator";

SqlRequest sqlRequest = new SqlRequest("delete from CASE_INFO

where t_caseNo = '" + caseId + "'"); dbPlugin.send(sqlRequest); dbPlugin.receive(new SqlResult());

SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

TimeZone.setDefault(TimeZone.getTimeZone("UTC"));

String createTimeString = "unix_timestamp('" + sdf.format(now()) + "', 'yyyy-mm-dd hh24:mi:ss:ff')";

圖 5-13 新增用例界面

addTestSuite()方法將形參傳入的suites進行提取，獲得每個testcase，并對傳入的caseDesc和caseComments進行本地賦值。使用SimpleDateFormat獲取當前的系統時間，并保存為testcase創建時間。在保存用戶數據之前，對擁有相同caseId 的數據進行刪除，最后調用dbPlugin插件進行基本的SQL操作。

addTestCase() 方法將形參傳入的用戶基本數據 caseId 、 caseDesc 、 caseComments、 caseLevel、 caseCover 進行本地變量賦值，使用 SimpleDateFormat 獲取當前的系統時間，并保存為testcase創建時間。在保存用戶數據之前，對擁有相同caseId的數據進行刪除，最后調用dbPlugin插件進行基本的SQL操作。

測試人員能夠在界面上點擊測試用例的按鈕，然后進入到測試用例編輯的界面，通過創建組件來創建新的用例套。用例的內容應該包含了測試所用測試套的名稱、測試套描述信息，關鍵字。測試人員選擇已經創建的測試用例套，然后創建測試用例。

測試的用例和需求之間有個覆蓋關系，測試人員在創建測試用例時，點擊主頁“測試需求”的模塊中點擊關聯產品的按鈕，然后在關聯的頁面上進行操作，編輯完成后，點擊“保存”即可關聯。

圖 5-15 測試用例流程圖

5.3.5 用例執行管理具體實現

測試用例設計后，需要由測試執行人員，按照設計好的測試場景進行執行。執行測試用例包括執行人，執行開始時間，執行結束時間等。根據測試用例執行的結果，匯總出系統的測試正確率，如果有缺陷，需要記錄到產品缺陷模塊中，并指定相應的開發人員進行修復。測試用例執行包括 assignTester() 、 assignTestTool()、queryTestCaseProgress()、queryTestCaseResult()這 4 個 actiono if (tester == null) {

String errorInfo = "can not create tester."; logger.error(errorInfo);

throw new CommonException(CommonError.INTERNAL_SERVER_ERROR, errorInfo);

}

ServiceHelper.postCreateTester(tester);

} else {

tester = updateTester(tester, createTester);

if (tester == null) {

logger.error("Update tester in DB fails due to bad request."); throw new CommonException(CommonError.INVALID_USER, "Update user fails.");

}

M軟件測試

信息 2018^：

系銃設置測試需求管理測試計劃管理測試用例管揑嚴品缺陷管餐測試報告筑計測試人員成就三方系貌對接

H 用戶：admin 賢角包醐體:用勵讓＞艙廠配

可用躺履： Peter R

■執確果痢勰簾求： □k 戶誨□»罔 E^wsfflpsesion Ltemsssn □■劇s® 出用戶 $啓荷

冏開始時問：

冏碗間：

就 It

圖 5-17 工具分配界面

鐵iS置測述需求曽麗I

圖 5-18 進度查詢界面

圖 5-19 結果查詢界面

assignTester()方法將傳入的tester基本信息進行校驗，如果tester對象為空，則拋出不合法用戶錯誤，并記錄更新teser到數據庫失敗的信息。如果對象不為空, 則設置Fields和Extention信息，并調用updateTester ()方法對傳入的tester用戶進行 POJO 實體化存儲。

queryTestCaseResult()方法將傳入的 caseId 的查詢 caseCreateTime，并對查詢出的結果進行Long類型轉換，同時查詢出caseCreator，并將查詢結果保存在Map 組成的以 caseCreator 為 Key， caseCreateTime 為 Value 的結果返回。

點擊主頁“測試用例套”模塊下的“分配測試用例”鏈接。能夠在當前的測試計劃設計中安排一個測試人員，或者是在測試用例的界面中，從出現的人員下拉列表中選擇合適的測試執行人員，點擊確認即可完成測試任務指定工作。

該界面展示了人員分配功能的使用，選擇下拉列表中的可用測試人員，指定需要測試的需求項，可以一個或者多個，并設置好計劃開始和結束的時間。

5.3.6 產品缺陷管理具體實現

測試的目的正是為了提前發現產品的問題，并在產品發布之前解決。一個缺陷的產生一般是從缺陷發現，提交缺陷，重現缺陷，修復缺陷，驗證缺陷，解決缺陷。所以缺陷管理的頁面需要包含以下幾個主要的要素：

1.缺陷的概述

2.缺陷的描述，包含觸發條件和步驟

3.缺陷的嚴重程度

4.缺陷的提交人員

5.缺陷的提交時間

6.缺陷版本

7.缺陷的解決人員

當測試人員在缺陷管理界面提交一個產品的缺陷時，一定會涉及以上 7 個要素。產品缺陷管理的 action 主要包含：deffectCreate()、deffectAssign()、 defectQuery()。

String userName = defect.getDefectCreator();

String defectComments = defect.getDefectComments();

String defectStatus = defect.getDefectStatus();

String defectType = defect.getDefectType(); for(List case:cases){

String caseId = case.getCaseId();

圖 5-21 新增缺陷界面

圖 5-22 缺陷查詢界面

defectCreate()方法將形參傳入的基本數據對象defect進行提取賦值，使用 SimpleDateFormat獲取當前的系統時間，并保存為defectcase創建時間。在保存用戶數據之前，對擁有相同defectId的數據進行刪除，最后調用dbPlugin插件進行基本的 SQL 操作。

用戶提交的一個缺陷保存在DefectObject這個對象里面，多個DefectObject會存儲在List里面，以界面列表的方式展示出來。其中調用defectAssign()方法去指定修復缺陷的開發人員。為了確保有好的產品交互，代碼［35］會進行異常處理，使用try...catch異常塊進行捕獲，并輸出友好的錯誤提示信息，如“指定人不存在”。

圖 5-23 產品缺陷流程圖

5.3.7 測試報告統計具體實現

測試結束后，系統會根據測試結果 success 和 fail 的情況，對用例進行不同類型和程度的統計。為操作者提供直觀的數據，操作者通過對數據進行檢查后，能夠點擊測試報告的按鈕。跳轉到測試結果顯示的頁面中。測試報告統計的 action 主要有 defectReport()> testcaseReport()、overallReport()、configureReportStyle()這 4 個。

Report Report = new Report();

Report.setReportType(Common.DEFAULT_REPORT_STYLE);

Report.setTypeSpace(Common.PUBLIC);

List<Group> group = new ArrayList<FKGroup>();

List<Id> idList = new ArrayList<Id>();

// reportNo

if ((reportNo != null) && !reportNo.equals("")) {

Id idreportNo = new Id(); idreportNo.setName(Common.DEFECT_REPORT); idreportNo.setValue(reportNo);

idList.add(idreportNo);

圖 5-27 總體報告界面

testcaseReport()方法將形參傳入的reportNo和reporter進行校驗，如果不為空, 就對reportNo和reporter進行賦值，并將賦值成功的結果保存在group里面，并使用 Collection 的內置方法 sor(t )對結果集進行排序，將排序完成并設置好的 Report 對象返回。

通過SQL查詢測試報告表，過濾出測試用例執行結果fail和success的，統計后存放在一個結果集中，通過forward()傳遞到前段展示層，由前端按指定的樣式顯示出來，configureReportStyle()的方法會調用系統配置模塊默認的指定樣式，重新 rendering 出來。

圖 5-28 測試報告流程圖

5.3.8 測試人員成就具體實現

系統測試用例執行的結果，以及發現和修復的產品缺陷記錄都可以作為開發和測試人員的工作輸出。測試人員設計了多少用例，覆蓋了多少測試需求，執行了多少用例，發現了多少產品缺陷；開發人員解決了多少產品缺陷。測試/開發人員的執行用例和解決用例所發現缺陷的時間比例等。這些一方面可以更好綜合評價一個測試/開發人員的勞動成果。另一方面也可以更好展示測試/開發人員。測試人員成就的 action 主要有 personalAchievement() 、 teamAchievement() 、

configureAchievementStyle()這 3 個。

String lineString = null;

while (null != (lineString = bufferedReader.readLine())) { builder.append(lineString);

builder.append(", Name: " + userName);

builder.append(", Result: " + reports.get(0).getResult(userName));

}

bufferedReader.close();

樣式舘：

樣栽件：

厳 Sg

personalAchievement()方法將定義好的 tis_achieve_definition.xml 進行 xml 解析, 并將傳入的 userName 賦值到 report 中，作為 report 中的 creator 。使用 BufferedReader對寫入過程緩沖，并將緩沖結果作為FilelnputStream的輸入值。生成的結果會toString()返回。

通過 SQL 語句查詢測試人員成就表，獲取指定 userName 的測試/開發人員，測試任務執行的情況，獲取一個HashMap的以用戶為Key，執行結果List為Value 的鍵值對。再調用configureAchievementStyle()方法，設置指定的樣式，默認為表格，傳遞處理結果到前端html5的頁面展示出來。

圖 5-32 人員成就流程圖

5.3.9 三方系統對接具體實現三方系統對接是按照標準協議，提供了不同外部系統可訪問的接口，從而便于和其他系統集成，提供數據支持。目前系統支持的外部接口協議是 Restful 和

SOAP。以后會進一步擴展。三方系統對接的action方法有provisionWechat()、 provisionLinkedIn()、provision3DGame() 。

if (null != userId) { reqBody.put("userId", userId);

} if (null != extensions) { for (String key : extensions.keySet()) { reqBody.put(key.getRetrieveTestCaseResult(), extensions.get(key));

}

String reqBodyJsonStr = convertToJsonString(reqBody); PostRequest request = new PostRequest(); request.setHeadParameter(reqHeadMap); request.setContent(reqBodyJsonStr); request.setUri(provisionLinkedInUrl);

return request;

圖 5-33 領英接口界面

圖 5-34 微信接口界面

圖 5-35 游戲接口界面

provsionLinkedln()方法將形參傳入的 trusted作為 HttpRequest 中 header 的 token, 將userId作為請求id放在requestBody中，并將requestBody轉換成Json對象。并將uri設置為provisionLinkedlnUrl,將封裝好的request作為HttpRequest對象返回。

使用retrieveTestCaseResult()獲取測試用例的執行結果，獲取執行時間和執行量；使用retrieveDefectsResult()獲取提交的缺陷數量，存放到一個POJO對象里。使用 HTTP 協議或 SOAP 協議傳輸。由于開發是基于標準協議開發，只需定義出 WSDL文件即可。

圖 5-36 三方接口流程圖

5.4 本章小結

本章主要介紹了系統開發使用的軟硬件平臺。詳細描述了系統各個模塊根據需求設計的具體實現工作和部分重要代碼。基本上實現了該軟件測試信息管理系統的設計意圖。系統本身實現了一個完整串起整個測試流程所設計的工作，集用例管理和缺陷管理于一身。合理運用工作數據展現測試/開發人員履歷，并適當增加了產品的市場競爭性。

第六章系統測試

軟件開發的過程中，同步在進行著測試工作，把每一個模塊作為一個目標，每個模塊都會單元測試、容器測試、功能測試、冒煙測試。繼而把每個模塊組裝起來做集成、一體的測試。在測試的過程中，通過本系統能夠真正做到實用性、高效性。

6.1 系統的測試環境簡介

測試環境的搭建均使用現有的資源，服務器為因特爾志強處理器的臺式機，客戶機為因特爾酷睿i5系列處理器的筆記本。臺式機使用Linux系統安裝了 Redis 和MariaDB的數據庫以及開發的JavaEE測試信息管理系統。筆記本作為發起請求的客戶端，使用 windows10 系統，安裝了三大主流瀏覽器 IE11、Firefox58、 Chrome64,并安裝了適用于性能測試和穩定測試的Jmeter［36］相關應用。主要的環境配置如下表 6-1 測試環境圖所示［37］。

表 6-1 測試環境配置

機器角色資源類型資源

客戶機硬件 Corei5, 8gb, 500GB, 10/100m

軟件 Win10, Jmeter, Wireshark etc.

服務器硬件 XeonE3, 16gb, 6T, 100/1000m

操作系統 Ubuntu

應用服務器 Jetty

數據庫 MariaDB, Redis

運行環境 Jre

6.2 系統的測試類型

測試工作由于依托在當前的開發系統上,和開發同步進行著測試工作,確保了問題的早發現、早解決。大部分的缺陷都在功能測試這一階段即可得到解決。避免后期陷于缺陷修復,而無法正常開展系統級別的性能測試和穩定測試,大大提高了產品發布的時效性和可接受性。具體來說,測試的環節主要對軟件的性能、功能、穩定性、集成和單元等方面的測試,除此之外,還會添加探索性［38］測試以最大限度發揮測試人員的主觀能動性,積極發現測試用例未發現或未較難覆蓋到的測試點。

6.2.1 單元測試

單元測試［39］主要是開發人員在功能代碼完畢后，使用stub、mock或fake等測試馬甲程序,對單個基類(超類)、抽象類、或者派生類(子類)中的方法進行正確性驗證的測試工作。一般而言，在系統開發的過程中，程序人員在編寫程序時，會將各個功能模塊的程序語言分別進行封裝，并在編寫完一個模塊的語言后，會對其功能進行檢驗，當該模塊能夠實現功能后，才進行下一個模塊程序語言的編寫。這種方式能夠避免程序出現錯誤，良好的單元測試用例可以做成構建自動化的一部分。

@Test

public void testLogOutFailedByInvalidUserIdParameter() {

localLogOutRequestParameters.remove("user_id"); localLogOutRequestParameters.put("user_id", "peter"); try {

logOutService.logOut(localLogOutRequestParameters, httpHeaderWithCookie);

fail("should throw exception");

} catch (CommonException e) { assertEquals(CommonErrorEnum.PARAMETER_INVALID, e.getErrorCode());

assertEquals("Invalid value of parameter: user_id.", e.getError().getErrorDescription());

}

verifythrowsError();

}

testLogOutFailedByInvalidUserIdParameter()測試方法，使用 Junit 組件，測測試了當user_id不對的時，登出時請求資源關閉拋錯，并報不合法的參數。

6.2.2 組件測試

組件測試是對特定模塊的測試。它可以與系統的其余部分隔離開來。假如正在測試一個叫做 X， Y 和 Z 三個模塊的應用程序，并且認為每個模塊都依賴于上面。如Y取決于X，Z取決于Y。現在如果開發人員開發了 Y模塊，并且作為測試人員要測試它，那么需要使用Stub和driver作為模塊X和Z。基于這個例子，將很容易編寫測試用例。

@Test

public void testLogInFailedWithPasswordEmpty() throws Exception { requestParams.remove(ParameterConstants.PASSWORD); requestParams.put(ParameterConstants.PASSWORD, "");

String errorCode = "login_failure";

String errorDesc = "The username or password is not correct."; errorExtendInfo.clear();

errorExtendInfo.put(ParameterConstants.ERROR_REASON,

ErrorMsgConstants.ERR_REASON_EMPTY_PASSWORD);

postJsonBodyAndCheckErrorResponse(Status.BAD_REQUEST, errorCode, errorDesc, errorExtendInfo);

LogTestEntry logEntry = getLogEntry(TYPE_POST); checkFailureLog(logEntry, errorCode, errorDesc); checkLogLogInRequest(logEntry, NORMAL_CLIENT_ID, TEST_USER_ID, null, null);

checkFailureLogInLog(errorCode, NORMAL_CLIENT_ID, "");

}

testLogInFailedWithPasswordEmpty()方法是在登陸時，輸入錯誤的密碼信息, 系統提示登陸失敗，用戶名或者密碼不對。同時將登陸錯誤的信息記錄到日志里面。

6.2.3 功能測試

通過對軟件功能的測試，從而保證所開發的軟件能夠實現預先設計的功能，

也能夠滿足用戶的需求。一般而言，在傳統的開發中，對功能的測試是需要長時間的琢磨，這種測試方法的效率十分低。在 XP Stories 中，能夠為用戶提供一個與開發人員直接交流和溝通的平臺，并在溝通中完成功能的測試。在單元測試的過程中，盡管對每一個單元單獨和互相聯系上進行了測試，能夠排除了大部分的錯誤，但這對軟件的測試來說，還是不夠完善的。因此，功能的測試能夠將單元進行封裝和集成，從而在用戶的層面上對軟件功能的體驗進行判斷。系統包含功能較多，無法一一列舉。現列舉登錄和測試用例查詢功能用例和相關測試及結果作為舉例說明。表 6-2 為登錄和測試用例查詢功能測試點：

表 6-2 登錄和用例查詢測試點

功能模塊用例名前置條件測試步驟測試結果

登錄登錄成功 1.系統服務已啟動；

2.預設置測試

用戶。 1. 輸入正確測試用戶名和正確密碼登錄成功，進入

系統主界面

登錄失敗 1.系統服務已啟動；

2.預設置測試

用戶 1.輸入錯誤測試用戶名或錯誤密碼登錄失敗，提示

用戶名或密碼錯

誤信息

測試用例查詢用例結果存在 1.系統服務已啟動；

2.預設置測試用例數據。 1.輸入預設置的存在的測試用例關鍵字；

2.點擊查詢按鈕系統顯示和關鍵

字匹配的查詢結

果

用例結果不存在 1.系統服務已啟動；

2.預設置測試用例數據。 1.輸入不存在的測試用例關鍵字

2.點擊查詢按鈕提示用例不存在

提示信息

// 5. re-login using linked testUser

ui.open(UrlNormal);

assertTrue("no login page show up.", needLogin()); boolean loginSuccess2 = login(desc, password); assertTrue("login failed using linked testUser", loginSuccess2);

int sessionCount2 = countSessionNumForUser(userId, dbPlugin); Assert.assertEquals("no new session", 1, sessionCount2);

testLogIn()方法在本地 mock 了 userid、password、role、permit 的基本測試數據。調用mock方法提供的ui()方法，模擬用戶訪問系統，并創建用戶，生成相應的訪問session,并對登陸后的結果進行Assert,如果滿足期望的結果，則測試成功。

圖 6-1 是手動測試登錄失敗的測試結果。測試人員在系統登錄界面，輸入錯誤的“用戶名”或“密碼”，點擊“登錄”，系統登錄校驗失敗，界面會提示錯誤信息“用戶名/密碼錯誤，請重新輸入”。

圖6-2是手動測試用例查詢執行信息的測試結果。測試人員在測試用例查詢管理界面，輸入錯誤的查詢關鍵字信息，點擊“查詢”，系統后臺查詢不到信息，界面會提示結果信息“無結果”。

6.2.4 冒煙測試

Smok Test的概念最早源于制造業，用于測試管道。這是一種比較基礎和直觀的測試方法。在對軟件測試的過程中，冒煙測試的方法能夠在對軟件的代碼進行正式的測試之前，先消除一部分的錯誤，能夠減少在后期測試環節的工作負擔。目前，常用的軟件測試中的冒煙測試主要分為三種：

1.形成集成測試之前的版本

2.形成集成測試之后的版本

3.后期缺陷修復測試的版本該系統所用的是第一種，即為了形成一個能順利進行集成測試的預版本。

附錄中是 smoke 的 jmeter 腳本代碼，其表示的是設置測試的 Traffic_IP,Traffic_Port,并對HTTP請求的頭文件參數進行設置，默認使用的是 HTTP 請求。

6.2.5 集成測試

軟件集成的測試是軟件開發［40］環節中重要的測試環節，其能夠對軟件的接口、單元之間的連接的正確性進行檢測。在集成測試中，按照一開始所制定的測試計劃，將模塊之間的連接和單元之間的進行檢測，同時，也會模擬運行軟件，從而對軟件的構成進行整體的分析，對其運行中的頻率和穩定性進行檢測。在集成測試的方式選擇中，能夠選擇自上而下和自下而上兩種方式，這兩種方式的選擇是根據軟件的各個模塊部分所進行的，能夠全面地對軟件的每一個組成進行測試。

附錄中是集成測試的 jmeter 腳本代碼，其表示的是設置測試的 Traf!ic_IP,Traffic_Port, /tis/report/delete/ReportTestl234567/peter。并對 HTTP 請求的頭文件參數進行設置，默認使用的是 HTTP 請求。

6.2.6 性能測試

對系統性能的測試是判斷系統整體質量的一個過程，一般而言，在對系統性能的測試中，會通過加壓的方式來對其工作的效率和穩定性進行測試。因此，系統性能的［41］測試根據其方法的不同能分為對系統的承受壓力的測試、穩定性的測試等。除此之外，對系統所應用的領域［42］的測試方式包括了性能調試和能力的檢驗等。一般會對系統的應用領域結合多種方式進行測試，具體如下表所示。

表 6-3 測試類型

功能檢驗測試計劃優化性能錯誤部位基準比對

基準測試

負載測試

壓力測試

并發測試

穩定性測試

附錄中性能測試的 jmeter 腳本代碼，其表示的是設置測試的 hostname,port, username,password。并對 PT 的 PASSRATE 進行定義，如果 passrate<PASSRATE， PT測試的結果不達標，反之滿足測試要求。默認使用的是HTTP請求。

著重關注響應時間，吞吐量，并發數，資源利用率這幾個指標。

6.2.7 穩定測試

對軟件穩定性的測試主要是通過使軟件跑一段時間，一般為連續一周的運作或半個月的運作，并對軟件連續運作中的表現進行記錄，從而到達檢測軟件運行穩定性能的測試。穩定性測試是用來驗證產品在一定的負載下能否長時間的穩定運行，其主要目的是驗證能力，并在能力的驗證過程中找到系統不穩定的因素并進行分析解決。

附錄中穩定測試的 jmeter 腳本代碼，其表示的是設置測試的 TC01_Login_jmeter_success， TC01_Login_jmeter_fail, DURATION 進行定義，如果 TC01_Login_jmeter_success+ TC01_Login_jmeter_fail/ DURATION 結果為 TPS。默認使用的是 HTTP 請求。

6.2.8 探索性測試

探索性測試［43］是軟件測試中的一個環節，它能夠在對軟件進行測試的過程中，探索更多測試的方法，從而為測試的環節提供更多的方案選擇。在軟件測試的過程中，軟件的測試人員會按照既定的測試計劃來進行操作，而探索性測試的存在會對計劃進行動態的修正，從而能夠進一步保證軟件測試工作的順利開展。探索性的測試方法，能夠令測試者在測試的過程中不斷的學習新的方法，與測試計劃是一種相輔相成的關系。

try:

run_cmd("service proxy restart")

except Exception, e:

try:

logger.info('Try to activate balance')

run_cmd("service proxy restart")

except Exception, e:

logger.error('Fail to restart /etc/proxy')

raise

logger.info('Make sure balance is running')

try:

status, output = run_cmd("service proxy status")

if not re.search('running', output, re.IGNORE):

raise RunCommandError('/etc/proxy not running.')

except Exception, e:

logger.error('/etc/proxy not running.')

logger.info('Finish deploying balance')

setup_balance(self)方法是使用python的語言寫的測試linux環境下，通過讀取

/etc/proxy/proxy.cfg加載不同proxy，并對proxy的開啟和關閉，主要用來對系統流量測試的。

6.3 系統的測試結果

系統在邊開發邊測試的情況下，缺陷的發現都及時得到了開發人員的修改，確保了產品的質量。在整個測試過程中共發現缺陷四百多個，嚴重級別的錯誤五十多個，中等級別的錯誤一百多個，其他都是輕微級別的錯誤。嚴重和中等的錯誤基本全部修改，其他錯誤由于時間關系無法全部修改完成，但總體上可以確保不會對系統產生功能性影響，基本功能均可正常使用。使用Jmeter+nagios[44]進行了系統的性能測試和穩定性測試，對產品的并發訪問量，訪問延遲時間均進行了記錄和繪制。

如圖 6-3 為 TPS (Transaction Per Second)的數據繪制圖：

Lhi Transactions Per Second

Elapsed Time (granularity:! min)

圖 6-3 TPS 數據圖

如圖6-4為Latency的數據繪制圖：

圖 6-4 Latency 數據圖

該測試選取了測試用例查詢場景，使用 Jmeter 工具，設置了35個線程數，模擬 1000 個 sessions 同時訪問系統。從圖上的數據可以看出，系統的并發數基本維持在 1300，響應時間也可以保持在 12。當請求繼續增加時系統反應會變慢，響應時間也就相繼增加了，圖中所示為經過調優后，系統當前的合適 TPS 與 Latency 關系。基本上滿足了系統對性能的要求。界面方面的測試確保了客戶端瀏覽器的兼容，滿足三大主流訪問瀏覽器的適配性，

6.4 本章小結

整個系統經過完整的測試后基本功能均已實現。系統實現了軟件測試信息管理需求定義的九大相關功能，符合了產品使用方面的性能和穩定性要求，可以在接下來的實際生產和工作中高效的提高工作效率，大大降低了數據整合，流程調度，圓滿實現了軟件測試流程的全程跟蹤管理。

第七章總結與展望

7.1 總結全文

該論文的起源來自本人工作中，對軟件測試理論的深刻認識，并對目前項目中使用的測試管理軟件的不足。結合國內外現有軟件測試管理方面的軟件進行了詳細的研究和分析，長達數月之久后，寫下了這篇關于國內軟件測試信息管理系統的論文。該系統遵循軟件測試流程，極好的整合了測試不同活動，可以用于項目管理者觀察項目進度，產品測試者管理測試用例，產品開發人員分析產品缺陷。簡要介紹系統如下：

系統基于JavaEE，充分使用Struts+Spring+Hibernate的分層設計思想，極大的加速了開發過程，也方便了后續的維護工作。系統使用Redis+MariaDB［45］的內存數據庫+關系數據庫的方式，提高了產品的并發訪問量，降低了系統對客戶端的響應時間。界面方面基于HTML5［46］的前端技術也為后續的二次開發工作提供了良好的技術基礎。整個系統的開發過程采用敏捷［47］開發模式，測試和開發同步進行。每一次小的迭代都是一個成品的產生。縮短了系統的交付風險。整個系統的開發過程也是驗證軟件測試流程的過程，開發系統的同時也在使用系統驗證自身。這要是本系統開發的初衷，縮短信息的交流和整合時間。使得測試工作不再是一項枯燥而乏味的事情，相反，測試工作變得更有趣，更貼近每個具體的測試活動的參與者。

7.2 展望后續工作

在長達一年的系統開發和測試工作中，深化了我對軟件測試的認識。該系統總體上達到了設計的既定目標，同時仍然存在一些不足的地方，比如系統未考慮虛擬化問題，目前大多數商業級別的產品都是部署在基于Docker［48］技術的“云［49］端”，一方面方便產品開發和部署，另一方面也大大解決了硬件資源的不足。系統也沒有大量運用HTML5的最新技術，比如硬件加速加持，CSS3，3D視覺特性, 這些都可以支持系統本身做成具有 3D 屬性的管理系統。當前正興的物聯網技術和VR,AR技術均可以作為后續系統優化和二次開發的技術支持和方向指示。在論文完成后的剩余時間，會深入研究系統的可擴展性，更好的升級該系統［50］，以便將來有機會將本系統投入實際使用。

致謝

伴隨著論文的即將完成，我也要再次告別兩年的校園生活，告別自己的求學生涯。值此離別之際，心中充滿萬分感激。

首先，我要衷心地感謝我的導師高原老師，本論文是在他的悉心指導下完成的。高原老師在論文的撰寫過程中，非常耐心地對我的論文進展情況，總體設計等方面給予了細心的指導。高老師總是在第一時間會及時回復我的疑問，在論文完成后，高老師非常細心地檢查了我的論文并將論文中的不足之處一一指出，并耐心地指導我該如何修改。是高老師的責任感和耐心幫助我完成了此篇論文。

其次，我要感謝公司項目組的各位同事對我的幫助，是他們在最初的選題和搜集意見的過程中，獻計獻策，使我對軟件測試有了更深的了解。同時也感謝我的企業方導師董向軍，在我撰文過程中，對我提出的問題，認真解答，耐心討論。使我對問題理解更加深刻，進一步對問題有了深度認識。

此外，還要感謝我的家人，特別是我的父母。感謝他們對我再次求學的無私支持，使我可以放心大膽的毫無顧慮的完成此篇論文，在此向我親愛的父母致以崇高敬意。

最后，對百忙之中為我評閱論文的專家，學者和老師們表示深深的謝意，對參考文獻的作者們致以衷心的感謝。

參考文獻

[1]丁智勇.項目質量管理過程中的軟件測試問題J].科技創新導報，2009,（02）:175-176

[2]Glenford J.Myers，Tom Badgett， Corey Sandler.軟件測試的藝術（原書第 3 版）[M].（張曉明，黃琳譯）.北京：機械工業出版社， 2012,2-5

[3]張妍，傅秀芬.基于多優化目標的軟件測試用例約簡方法研究[J].計算機應用研究， 2016,33（04）:1111-1112

[4]Sami Torniainen.Improving Effectiveness Of Regression Testing Of Telecommunications System Software[D].Finland：Helsinki University Of Technology， 2008,8-9

[5]Leonard Richardson， Mike Amundsen.RESTful Web APIs[M].（趙震一，李哲譯）.北京：電子工業出版社， 2014,18-20

[6]Martin Fowler.重構改善既有代碼的設計[M].（熊節譯）.北京：人民郵電出版社，2010,89-90

[7]肖麗瓊.軟件測試之魂[M].北京：電子工業出版社，2013,272-273

[8]Randal E.Bryant，David R.O Hallaren.深入理解計算機系統（原書第2版）[M].（龔奕利，雷迎春譯）.北京：機械工業出版社， 2011,14-15

[9]林信良.Spring2.0技術手冊[M].北京：電子工業出版社，2007,253-254

[10]鄒輝.軟件自動化測試開發[M].北京：電子工業出版社，2017,176-199

[11]嚴千均.編程導論[M].北京：清華大學出版社，2013,19-21

[12]S Cash， V Jain， L Jiang， A Karve.Managed infrastructure with IBM Cloud OpenStack Services [J].Ibm Journal of Research & Development， 2016,60（02）:1-12

[13]李濤.3種常用國產辦公軟件與微軟Office軟件的測試對比J].電力信息與通信技術， 2007,5（09）:89-91

[14]Victor Lofgren.Developing and implementing a quality management system in a startup company[D].Sweden： Chalmers University Of Technology， 2012,54-55

[15]袁明磊，付賢政.軟件測試管理系統設計[D].安徽：安徽國防科技職業學院，2013,77-78

[16]葉言苓，崔彥軍.軟件測試管理的研究與應用[J].計算機應用與軟件，2003,20（09）:17-18

[17]何玉潔，牛蓓，金穎，方美琪.軟件質量保證一測試管理[C].信息系統協會中分會第一屆學術年會, 北京, 2005, 207-208

[18]Mark Kevitt.Best Software Test&Quality Assurance Practices in the project Life-cycle[D].Ireland： Dubin City University， 2008,77-78

[19]葛一鳴.實戰Java虛擬機[M].北京：電子工業出版社，2015,139-147

[20]鳥哥.鳥哥的Linux私房菜基礎學習篇[M].北京：人民郵電出版社，2010,42-43

[21]吳翰清.白帽子講Web安全[M].北京：電子工業出版社，2014,280-281

[22]Daniel P. Bovet，Marco Cesati.深入理解Linux內核[M].（陳莉君，張瓊聲，張宏偉譯）.北京：中國電力出版社， 2007,13-14

[23]Joakim Verona.DevOps實踐[M].（高清華，馬博文譯）.北京：電子工業出版社，2016,1-7

[24]孫鑫.Servlet/JSP深入了解[M].北京：電子工業出版社，2008,541-542

[25]蔡為東.贏在測試2-中國軟件測試專家訪談錄[M].北京：電子工業出版社，2013,158-159

[26]Mike Cohn.敏捷軟件開發實踐估算與計劃[M].（金明譯）.北京：清華大學出版社，2016,17-21

[27]Steve Souders.高性能網站建設指南[M].（劉彥博譯）.北京：電子工業出版社，2010,103-105

[28]沈建苗.微軟OFFICE2013：新外觀，新價位[J].微電腦世界，2013,（03）:30-32

[29]Parawee Pleehajinda.Database centric software test management framework for test metrics [D].Thailand： Technische Universitat Chemnitz， 2015,47-49

[30]李榮國，王見.MySQL數據庫在自動測試系統中的應用[J].計算機應用， 2011,31（02）:169-170

[31]蘇清偉，高磊，楊坤.一種醫療器械維修信息管理軟件的開發[J].中國醫療設備， 2016,31（08）:80-81

[32]楊佳琪，陳思言，高志輝，鄧勝利.國外個人信息管理研究綜述[J].數字圖書館論壇， 2016,（145）:65-66

[33]Guillermo Rauch. 了不起的 Node.js[M].（Goddy Zhao 譯）.北京：電子工業出版社， 2014,273-276

[34]黃建宏.Redis設計與實現[M].北京：機械工業出版社，2015,1-5

[35]左程云.程序員代碼面試指南[M].北京：電子工業出版社，2015,258-259

[36]蟲師.Web接口開發與自動化測試[M].北京：電子工業出版社，2017,205-221

[37]Chris Sanders.Wireshark數據包分析實戰[M].（諸葛建偉，陳霖，許偉林譯）.北京：人民郵電出版社， 2013,39-40

[38]James Whittaker.探索式軟件測試[M].（方敏，張勝，鐘頌東，郭艷春譯）.北京：清華大學出版社， 2010,16-20

[39]James Whittaker，Jason Arbon，Jeff Carollo.Google 軟件測試之道[M].（黃利，李中杰，薛明譯）.北京：人民郵電出版社， 2013,104-109

[40]林信良.Java學習筆記JDK8[M].北京：清華大學出版社，2015,40-43

[41]Kai Hwang， Geoffrey C. Fox， Jack J. Dongarra.云計算與分布式系統從并行處理到物聯網 [M].（武永衛，秦中元，李振宇，鈕艷譯）.北京：機械工業出版社，2015,188-191