S#aS模式的信息管理軟件自動化測試系統的設計與實現

發布時間：2023-07-25 10:04

第一章緒論 1

1.1研究背景 1

1.2研究現狀 2

1.3研究內容 3

1.4論文結構 5

第二章相關技術和理論介紹 7

2.1SaaS相關技術理論 7

2.1.1SaaS模式特點 7

2.1.2SSM 框架 9

2.1.3RBAC權限訪問控制 11

2.1.4定時器 Quartz 12

2.2自動化測試技術相關理論 13

2.2.1自動化測試概念與應用條件 13

2.2.2自動化測試框架發展 15

第三章SaaS模式的信息管理軟件自動化測試系統的分析與設計. 17

3.1系統需求分析 ...17

3.2系統整體架構設計 19

3.2.1系統網絡架構圖 19

3.2.2系統業務架構圖 21

3.3系統功能模塊設計 24

3.3.1創建測試設計 24

3.3.2用例模板設計 26

3.3.3測試執行方案設計 27

3.3.4測試系統存儲設計 28

3.3.5響應式前端頁面設計 30

3.3.6測試報告模塊設計 31

第四章SaaS模式的信息管理軟件自動化測試系統的實現 32

4.1系統整體架構實現 32

4.2系統功能模塊實現 36

4.2.1租戶用戶管理的實現 36

4.2.2創建流程的實現 39

4.2.3測試模板的實現 42

4.2.4測試流程的實現 45

4.2.5測試方案的實現 48

4.2.6測試報告的實現 49

4.2.7響應式前端實現 51

第五章SaaS模式的信息管理軟件自動化測試系統的展示與驗證 53

5.1測試環境 53

5.2系統驗證 53

5.2.1登錄界面 53

5.2.2測試列表頁 54

5.2.3創建測試計劃 54

5.2.4添加測試單元 56

5.2.5模板創建測試 57

5.2.6測試報告 58

5.2.7響應式前端 60

5.2.8性能測試 61

5.2.9 Selenium 工作上匕較 63

第六章總結與展望 65

6.1主要工作總結 65

6.2問題與展望 65

參考文獻 67

致謝 70

第一章緒論

本章緒論從四個方面概述了論文的要點：首先，簡要地介紹了本課題的研究背景；其次，介紹了在SaaS (軟件即服務)信息管理軟件自動化測試相關領域現階段的發展現狀以及己取得的研究成果；再次，闡述了本文要重點分析、探討的問題和主要完成的工作；最后，對本文各章節的組織結構進行了簡要概括。

1.1研究背景

隨著互聯網技術的發展，云計算產生了三個流行的代表應用，其中之一就是SaaS (Software as a Service)⑴。SaaS服務模式的產生是為了解決當前傳統信息服務模式所存在的問題，可以從技術角度降低實施成本、簡單開發周期以及解決后期維護麻煩的問題[%原因就在于SaaS的服務特點是其擁有多租戶和多用戶、按需購買配置、按需購買服務、可以隨意擴展以及避免了使用者手動部署和更新的繁瑣。SaaS意味著多租戶之間虛擬孤立，共同使用一套系統但是分別是一個單獨的實例，互相保持數據安全而不受其他租戶干擾[3][4]o由于 SaaS模式的出現，計算機軟件技術的發展從傳統的軟件交付向如今的服務交付開始轉變。曾經人們關注的是計算機軟件，如今人們關注的是技術提供商可以為使用者解決什么樣的問題。它的影響范圍廣泛，當然也包含了本課題所研究的信息管理軟件以及自動化測試系統的應用。

信息管理軟件是一個經過多年發展的應用，如今信息管理軟件已經分化為多種具體的應用，例如客戶關系管理軟件(CRM-Customer Relationship Management),人力資源軟件(HR-Human Resource Software),辦公自動化軟件(OA-Office Automation),企業資源計劃軟件(ERP-Enterprise Resource Planning)等岡。正如之前所說SaaS模式所帶來的人們對服務的關注更甚于軟件，信息管理軟件也發生了同樣的轉變。當用戶使用采用了 SaaS模式的信息管理軟件時，用戶的購買對象不再是軟件以及各類服務器，而是通過一臺簡單的終端就可以按需租用。從更深層的角度來看，企業主的支出從過去的大量開銷削減到極低，這包含減少了大量投資與硬件、軟件、維護運行和人員的花費。可以說對于企業主而言，這是低投入、零風險、零周期的模式向。企業主投入的是較低的租賃服務費用，享受的硬件性能來自于云計算服務商的網絡機房，享受的軟件運行服務來自于云服務提供商，同時還可以享用后期的軟件版本更新迭代。例如國外的某傳媒藝術教育學校就采用了此模式，將傳統教學資源置于網絡上，學生們可以第一時間學習到新技術、新方法等。如此看來，基于 SaaS的信息管理軟件模式帶來了巨大的營運效益模式。

自動化測試可以顯著地提升軟件質量［7冏，因此受到了軟件公司的重視。在自動化測試的發展過程中，其與SaaS模式結合也可以產生很多改進。軟件的測試過程中包含很多不定的因素，例如測試的成本、測試的人力需求、測試所涉及到的資源調度以及所需時間等內容。對開發商來說，測試所耗費的時間和資源最終都會疊加到軟件的開發成本上，這是十分不劃算的事情。此外在搭建測試平臺本身的過程中也會耗費一定的人力成本、時間成本和金錢成本，更何況測試平臺還需要根據不同的生產環境而改變〔91。因此SaaS模式可以顯著地提升自動化測試系統的使用便捷性和減少使用成本［i°］,甚至還可以提升系統性能。這說明SaaS模式的自動化測試系統存在很大的研究空間。

1.2研究現狀

自動化測試具有效率高和可替代重復勞動的特點，國內外大量的軟件開發商都在這個領域不斷耕耘。自動化測試在國外的研究起步較早。美國的IEEE 和ACM等組織對軟件測試制定了規范［⑴，而國外的知名大學例如卡內基梅隆大學等，也對軟件測試展開了許多研究工作"I。ZhuH研究觀點把軟件測試看作是一個測試人員對軟件屬性的推理歸納過程〔⑷。D Spinellis的研究觀點把軟件測試的最佳實踐包括單元測試、測試驅動開發、使用測試金字塔、測試自動化、持續集成、測試覆蓋分析、A/B測試，以及采用適當的度量標準〔"I。在安全性測試方面，S Krishnaveni研究觀點是SQL注入和跨腳本攻擊是目前云應用程序最嚴重的安全漏洞I⑸。公司方面，國外的許多知名廠商都在努力開發自動化測試軟件，例如微軟、谷歌、甲骨文等等。他們的研究目的是整合企業內部軟件的自動化測試流程，以及產生一系列自動化測試工具肌］。目前流行的自動化測試工具主要是用于WEB測試的QTP和Selenium,性能測試的 LoadRunner和Jmeter、接口測試的SoapUI和Postman等。國內方面的自動化測試發展較為緩慢，不過也產生了一些研究成果。錢樂秋教授（復旦大學）提出了基于擴展有限的狀態機測試中自動選取測試輸入數據的研究，以便于測試人員進行手工測試數據選擇〔切。國內軟件公司也在逐步發展自動化測試，以百度 MTC為首的公司將大量精力投入在了移動端APP的測試上［罔。

測試軟件方面經過多年發展，但是還是存在一定的不足。QTP測試軟件廣泛地應用于功能測試和回歸測試，甚至被認為是業界的最佳解決方案。它支持兩種測試用例編寫方式，一是以VBScript編寫腳本，這對測試人員的腳本編寫能力有較高要求；二是以錄制方式創建，但是隨之而來的問題就是，測試數據與測試用例高度耦合，創建效率不高。當采用模擬錄制時，軟件記錄點擊坐標點，當坐標發生改變時測試失效。除此之外，QTP等軟件的使用維護成本較高，不僅需要購買測試工具還需要不小的運行空間，對測試人員的培訓投入也是一筆開銷HIRO］。Selenium也是一種流行的Web軟件測試工具，它是作為一個瀏覽器的插件，模擬用戶的點擊操作來測試，主要是為了測試瀏覽器的兼容性。該測試插件支持多種開發語言編寫測試腳本，例如Java等。顯然其測試用例的創建也不夠高效。

無論是流行的HP公司的QTP軟件還是開源軟件Selenium都存在一些問題，也是本課題期望解決的問題：

一、測試成本高。

現有的自動化測試軟件相較于SaaS模式的自動化測試軟件成本顯著提高。若使用QTP類PC客戶端的產品，則需要測試人員下載安裝以及配置各種運行環境。若使用Selenium類瀏覽器插件產品，則需要測試人員在不同版本的瀏覽器中配置使用。測試人員還需要購買高性能的硬件設施，以及維護數據中心和服務器的穩定運行。相反，SaaS模式解決了上述所有問題。

二、缺乏對某些軟件產品的定制。

現有的測試軟件并非可以做到以不變應萬變。現有的自動化測試軟件需要通過編程語言或錄制來編寫復雜的測試用例，這種方法是不能適用于所有的軟件產品的。本文期望針對于信息管理軟件進行優化，提供常用功能測試模板，從而方便創建測試用例等流程。

基于上述問題，可以看出自動化測試系統在SaaS模式方面和針對性產品方面還存在很大的研究空間。

1.3研究內容

本課題來源于某商用IT公司的SaaS平臺的信息管理軟件項目，該項目的測試人員希望解決繁瑣重復的測試需求，而測試人員認為直接采用第三方軟件解決問題并不是很合適。

本課題的研究是為了實現基于SaaS模式的信息管理軟件的自動化測試系統。當下信息管理軟件多種多樣，本課題分析常用的信息管理軟件模塊抽取共性問題，以客戶管理系統為案例，在現有基礎平臺上提出新的測試架構。首先，本系統以SaaS模式呈現給客戶解決了下載維護測試軟件和搭載測試環境等基礎環境問題；作為一個云計算服務模式，提供租戶用戶管理功能，保證信息存儲的安全可靠性；其次針對于信息管理軟件常用模塊，提供了常用測試模板以及隨機測試數據字符庫，從而簡化和加快測試的創建流程；此外采用友好的交互界面，盡可能地減少用戶腳本編寫，盡可能采用圖形化操作；同時系統前端頁面采用當下流行的響應式設計，測試人員在PC端和移動端使用，都可以獲得良好的匹配；系統對于每一類測試將提供測試報告查看和記錄能力。

在研究內容中，本課題將重心放置在系統的需求分析與設計和系統的實現部分。在需求分析之前，本課題對前期涉及到的相關科研成果、技術框架等技術理論進行研究和總結，以便為下一步的分析與設計工作做基礎鋪墊，同時也為系統的實現部分做技術儲備。在基于系統的需求分析、系統的整體框架設計、系統的具體功能模塊設計基礎之上，本課題對SaaS模式的信息管理軟件自動化測試系統進行代碼編寫。在系統的開發過程中，本課題注重采用前期調研的相關開源框架和開源技術，采用已經驗證過的可行性技術，從而確保在創新的同時系統可以兼顧可靠性、穩定性和魯棒性等。最后，在系統完成實現后，本課題以截圖的方式呈現了使用流程和其涉及到的頁面截圖。

本課題最終完成的研究內容有：

1、根據相關論文和技術框架，分析現有的信息管理軟件特點以及自動化測試系統的發展，結合SaaS模式的服務特點，同時采用流行的MVC設計模式以及高效的 Java Web 開源框架 SSM ( Spring-SpringMVC-MyBatis), 設計并實現SaaS模式的信息管理軟件的自動化測試系統架構。

2、基于SaaS模式的多租戶多用戶的特點，設計并實現租戶用戶管理以及基于角色權限控制的模塊。

3、在對比傳統的自動化測試系統創建用例的方法之后，提出適用于SaaS模式的信息管理軟件自動化測試用例創建方法，實現圖形化的用例輸入模塊。

4、根據相關論文分析信息管理軟件的特點，抽取出信息管理軟件的常用功能模塊，結合測試系統的目的，設計并實現信息管理軟件專用的測試模板。

5、根據MyBatis框架特性，設計本系統的各類數據庫存儲結構，并實現 SaaS模式的信息管理軟件的數據持久層開發。

6、為了實現自動化測試系統定時執行的目的，基于定時器Quartz框架的特

點，提供兩種自動化測試執行方案，提升測試系統對資源的利用率。

7、針對測試的種類不同，結合信息管理軟件特點，提供測試報告功能。

8、為了滿足測試人員移動辦公等多終端辦公需求，基于當下流行的響應式開源框架Bootstrap,實現前端頁面的自適應布局。

1.4論文結構

本文按章節共分為六個部分，按以下結構進行組織：

第一章，緒論。本章從四個方面來闡述，分別是研究背景、研究現狀、研究內容、論文結構。研究背景介紹了本課題的產生原因以及當前的研究環境；研究現狀對背景中的必要性進行了進一步的解析，分析了當前的研究現有狀況；研究內容部分更詳細地描述了本課題的來源、本課題的研究目的以及本課題的研究產出內容，其中包含了 SaaS模式的信息管理軟件自動化測試系統的架構和功能模塊等內容；最后，論文結構部分對本課題全文的結構和內容進行了整體概述。

第二章，相關技術和理論介紹。本章對本課題涉及到的相關理論技術進行了簡要的介紹，從而幫助讀者閱讀本文章。本課題的主要技術理論包括兩部分，SaaS軟件即服務的相關理論和自動化測試技術的理論。

第三章，SaaS模式的信息管理軟件自動化測試系統的分析與設計。在結合用戶需求和系統功能特點的基礎上，詳述本課題對SaaS模式的信息管理軟件自動化測試系統的分析與設計，從系統需求分析入手，根據需求進行系統整體架構設計，然后再進行系統功能模塊設計。在系統需求部分，考慮到SaaS模式的特點，分別從三個用戶角色角度出發進行需求分析。在系統整體框架設計部分，以MVC設計模式出發，設計了基于SSM (Spring-SpringMVC-MyBatis) 框架的系統實現架構。最后設計了多個系統功能模塊，包含創建測試的設計、用例模板的設計、測試執行方案的設計、測試系統存儲的設計、響應式前端頁面的設計以及測試報告模塊的設計。整章從需求分析到系統設計，從整體架構設計到具體功能模塊設計，展示了一個SaaS模式的信息管理軟件自動化測試系統的可行的設計方案。

第四章，SaaS模式的信息管理軟件自動化測試系統的實現。本章承接第四章的內容，基于某商用SaaS平臺，對本課題設計的SaaS模式的信息管理軟件自動化測試系統進行原型實現，分為兩個部分：系統架構實現和系統功能模塊實現。系統架構實現部分闡述了基于SSM框架從Maven組建到詳細代碼注解的全過程。系統功能模塊實現部分詳細闡述了系統的七個具體實現部分。

第五章，SaaS模式的信息管理軟件自動化測試系統的展示與驗證。本章通過展示應用截圖，從實際應用效果展現了本課題的工作成果，展示主要從測試人員登錄、創建測試、執行測試以及查看報表的全部過程。

第六章，總結和展望。本章首先對論文的主要工作進行了總結，然后對研究過程中的問題、不足和可能的解決之道進行了闡述，并對下一步可以進行的研究工作進行了展望。

第二章相關技術和理論介紹

本章介紹了本課題所涉及到的相關技術和理論。在本課題的前期研究過程中，接觸到了大量優秀的科研論文成果、開源技術框架等，在此只選取最終應用到本系統設計實現過程中使用到的最核心的技術理論，作為系統需求分析和設計實現的技術理論基礎。本章首先介紹了 SaaS系統相關的技術理論以及自動化測試技術的相關概念。

2.1 SaaS相關技術理論

2.1.1 SaaS模式特點

SaaS的意思是軟件即服務，是在互聯網發展過程中演變岀的新型軟件應用模式，它替代了傳統軟件分發，而是采取通過網絡建立服務連接的形式提供給使用者0］〔22〕。SaaS的服務提供商職責包含搭建云計算硬件平臺，需要保證硬件計算性能等能力，還需要提供軟件服務。硬件與軟件的維護升級也需要服務提供商來解決。企業主無需購買任何硬件軟件，只要按照需求租賃使用即可，通過終端就可以獲取服務⑴1。SaaS服務模式如圖2-1所示。

圖2-1 SaaS服務模式

傳統的軟件使用者會在企業內部部署數據庫系統和災備系統等，所有的用戶數據、業務數據等敏感信息都掌握在企業自己手中。然而，SaaS的租賃模式就意味著擁有多個租戶即企業同時使用同一套軟硬件。這需要服務提供商保證企業數據的安全性，例如提供數據隔離、數據訪問控制等Bl。軟件架構存在一種服務模式就是多租戶，每一個租戶所得到的的軟件服務都是來自于同一個實例0］。在 SaaS平臺的服務設計過程中，由于多租戶的存在，需要著重考慮多租戶間的數據存儲方案。這表現在兩個方面，一方面數據的共享意味著更小的存儲空間開銷，這可以同時給服務商和企業主降低成本；另一方面，如何保證在盡可能的共享情況下又要保證數據的隔離性是一個值得探討的安全性問題。在多租戶的技術實現過程中，需要有一個全面的安全考量思路。首先，商業數據是一個企業的命脈，服務提供商無論是通過對數據庫的分割還是對數據表的分割，亦或是通過字段的隔離，都需要十分慎重。對于特定的隱私數據，服務提供商還需要提供加密解密的能力，確保即使數據庫被盜取，用戶信息依然可以保證安全性，當然這會建立在消耗一定系統運算能力的基礎上。其次，在系統層面上，雖然多個租戶使用的是同一套系統，但是利用計算機虛擬技術可以將服務器劃分為多個虛擬主機，從而實現租戶運行環境和運行數據的隔離［26】。

SaaS模式在商業環境中擁有很多優勢。從服務提供商來說，軟件變成了服務，服務的發布流程完全依靠互聯網來完成，省去了曾經的大量物流成本。以租賃形式的收費方式替代了原有的軟件售賣方式，服務提供商可以獲取源源不斷的資金流，而不是僅僅做一錘子買賣。當用戶提出更多的需求時，服務提供商還可以提供按需服務，根據新的需求來開發新的產品，從而獲得更高的利潤。在推銷模式上，由于互聯網的便捷性和按需租賃的特點，軟件試用也變得更加簡單，用戶可以在體驗過產品的優點之后再決定。從開發人員角度來講，SaaS模式的出現使得開發人員可以將更多精力放在業務邏輯開發上，而不是針對每一套系統特定開發，這極大地提升了開發效率。由于軟件依靠互聯網來分發，當遇到系統問題時，研發人員可以對此作出快速地反應，隨時可以修復問題重新上線，從而提升用戶體驗。

從企業主的角度來講，SaaS同樣擁有非常巨大的優勢：

第一，使用成本低。傳統軟件從硬件平臺搭建，到軟件開發，到軟硬件的后期維護升級都需要花費大量成本，同時企業內部需要對軟硬件雇傭許多計算機專業人才來保證系統的可靠運行。當軟件需要更新升級時，企業內部的技術工人數量往往比服務提供商的人數少，因此時間成本也就更高。所以無論是人工成本還是時間成本，都比SaaS模式的服務消費要高出不少。SaaS由于采取按時間收費或者是按資源占用來收取費用，這種租賃方式保證了企業的按需租用，對于不需要的功能可以完全不支出費用。企業也無需雇傭任何技術人員，只需要讓企業員工專注于業務能力即可。除此之外，租賃費用還包含了軟件的升級維護費用，硬件的維護費用，這不僅僅是降低了成本，同時由于服務提供商往往擁有更專業的軟件人才和更高性能的硬件設備，SaaS模式還可以提供更好的系統性能。在中小企業中，由于對成本更加敏感，這種服務模式將更受歡迎。

第二，按需租用。一個系統的使用資源占用擁有峰值和低谷，從企業安全的角度講，為了保證系統的持續可靠使用，系統的資源量需要滿足峰值的使用需要。這也就意味著，系統的很多資源都因為峰值的存在而產生大量浪費，例如對于電商企業來講，并不是每時每刻都可以保持促銷期間的訪問量。企業主在購置軟硬件產品時因此付出了更多的成本，這是他們絕對不希望看到的。然而SaaS服務提供商可以準備許多高性能的設備資源，將設備資源拆分成許多小單元，租售給多個租戶。租戶可以靈活定制需求，在需要高訪問量時提升資源占用，在其他時間縮小租用數量。

第三，部署方便。企業主購買SaaS服務一般通過終端瀏覽器就可以直接訪問到資源，不需要像傳統軟件模式一樣，部署配置各種環境，這避免了許多網絡配置、運行環境配置等復雜問題，企業主可以將精力著重放置在業務上。

第四，免維護升級。SaaS系統的運行過程中難免會出現軟件問題或者硬件問題，這些問題的解決責任將由服務提供商來解決，這可以極大地減輕企業主的維護成本。企業主的操作僅限于訪問網頁來使用資源，十分簡單。當企業主的使用過程中遇到問題或者是期望有新的服務時，只需要將問題告知給SaaS服務商，由服務商來解決所有的維護升級問題。企業主使用到的SaaS服務永遠是最新版本，隨著服務提供商在供應側的更新，全網的服務都可以聯動。

第五，隨時隨地訪問。傳統的軟件是部署在公司內部的特定環境中，而SaaS 的服務是搭建在云計算服務之上，用戶可以通過任何連接互聯網的終端來訪問它。隨著互聯網時代向移動互聯網的轉變，移動辦公也越來越受到人們的重視，SaaS 的隨時隨地訪問特性可以保證移動終端訪問的可行性以及拓展性。

第六，安全與災備。眾所周知，數據安全一直是軟件技術提供商所努力的方向，當災難發生時，數據備份就顯得十分重要。傳統做法是企業主自己做數據備份，這需要消耗大量的人力物力，成本是顯而易見的。然而作為SaaS服務提供商，完全可以投入大量的成本去建設信息安全防護體系，將成本均攤在每一個租戶身上，從而降低單個用戶的安全成本。

2.1.2 SSM 框架

SSM框架是Spring框架、SpringMVC框架和MyBatis框架的合稱，它替代了 SSH框架(Struts2+Spring+Hibemate)的地位，成為了當下大多企業Java Web項目的開發框架，適用于各類企業級應用系統的搭建〔27〕。

企業應用程序的開發過程中擁有各種復雜交錯的模塊，Spring作為一個開發框架擁有分層架構，是為了解決企業開發過程中的復雜性問題，可以將一個交錯復雜的系統拆分成多種模塊，協同運行。Spring框架由七個各司其職的模塊組合而成，其結構如下圖2-2所示，整體構建在核心容器Spring Core之上，核心模塊的作用是支持各類工具和創建并管理各種Beano Spring擁有輕量級的特點，在代碼的開發過程中Spring框架并不會占用太多資源，代碼可以通過注解的方式以及XML配置文件的方式融合在系統中，避免了對原代碼的侵入。 Spring最大的核心特點是兩個方面，IOC和AOP。IOC是控制反轉，意思就是將對象創建的責任反轉，由原有的工廠模式轉交給框架來負責。AOP是面向切面編程，意思是在不修改源代碼的情況下，可以通過預編譯模式以及在系統運行期間動態添加代理實現部分功能。

圖2-2 Spring架構圖

SpringMVC是上圖中Spring Web的部分，也是Spring Framework的產品之一。由于SpringMVC是Spring的其中一部分，因此二者的配合十分容易。 SpringMVC的核心思想是體檢MVC設計模式，通過將視圖模型、控制器以及數據模型的分離，從而讓整個系統的編寫更容易實現。SpringMVC的使用過程中也大量參照了 Spring的非侵入性特點，可以通過各種注解來實現控制器等組件的識別，搭配Spring的控制反轉，提升了代碼編寫過程中的便捷性也提升了代碼自身的可讀性。

MyBatis是一個持久層框架，它可以幫助代碼開發者實現數據庫的增刪改查動作。它的起源是apache的iBatis開源項目，提供了 SQL Maps和Data Access Objects (DAO)。MyBatis的特點和其他持久層框架一樣，將SQL語句和原代碼分離，從而當業務邏輯發生改變時或者數據庫發生改變時，并不會產生相互影響。MyBaits對數據庫的操作用Mapper映射文件將接口和Java的

POJOs （Plain Old Java Objects,普通的Java對象）映射成數據庫中的記錄以及 Spring的配置實現，從而替代了原始的手動參數操作。

2.1.3 RBAC權限訪問控制

在權限訪問控制領域有多種訪問控制機制，例如自主訪問控制、強制訪問控制等。當下最流行的訪問控制模型是基于角色的權限訪問控制模型即RBAC （Role-Based Access Control）o RBAC的業務邏輯是權限本身與用戶之間隔離，將權限賦予到不同的角色上，當用戶期望擁有某種權限時需要成為對應的角色來擁有。在一個業務邏輯系統中，根據不同使用者的身份不同設計出不同的角色，這種對應關系和現實社會中的身份認證有許多異曲同工之妙，因此也最容易被人所理解，也被最廣泛地使用。此外，角色的設計并不是一成不變的，在系統的使用過程中隨著業務邏輯的變化，角色與權限的關系也可以隨之更改，從而不斷地迭代，適應更新穎的需求。在RBAC中角色的概念十分重要，它是用戶與權限之間的連接橋【絢。用戶是一個操作執行的實體，而權限是一個資源使用的把控者，角色是在這二者之間加了一層代理，且這二者只可與角色進行關聯，三者之間是多對多的關系。這種設計理念可以簡化權限管理，由于在一個現實社會組織中會以一定的工作職責來劃分，用戶作為一個行為的執行者是以相應的角色來執行對應的權限，這十分容易理解。現實中有時候一個企業組織內部經常會做人事調動，當用戶的職責發生改變時，無需像過去一樣重新設置用戶的每條權限，而是直接修改其對應的角色即可，這提高了系統修改的效率。當企業組織內新增人員時，也無需為這個新人員設置各類權限，只需要為其賦予一個角色即可。當部門中產生了新的工作職責時，此時才需要新增一個角色與之對應，減少一個工作職責時也是如此。

在基于角色的權限訪問控制中遵循著幾個設計原則。首先是最小權限原則，對于一個角色來說，系統應當為其分配能完成其職責工作的最小權限集合，從而保證這一角色不會超出其權限范圍對系統安全性造成威脅。其次是責任分離原則，這一原則的意思是在一個系統中難免會存在較為敏感的任務，在執行這一任務時應當由兩個相互獨立互斥的角色來執行。再次是數據抽象可以通過權限的抽象來體現，系統的讀寫操作執行權限，可以通過RBAC的配置來得以實現。

RBAC認為，授權實際上是who, what和how三者之間的關系，也就是誰對于如何操作。Who是用戶或主體的許可（如委托人，用戶，團體，角色，演員等）；what是對象或資源（資源，類）；How是具體的，權限（特權，正面和負面授權）。簡而言之，我們授權角色并將適當的角色應用于用戶，以便用戶可以執行相應的權利。通過中間角色的角色，權限管理更加靈活：角色權限可以靈活改變，用戶角色可以隨不同場所而改變。這套RBAC幾乎可以應用到所有的權限管理模塊。

2.1.4 定時器 Quartz

在云服務平臺的實際應用場景中，企業經常會用到一些重復性的周期操作或者是定時執行某些動作，例如每天凌晨更新數據庫表格，每一個時間段統計系統數據使用情況等。這些動作的完成都需要依賴定時器來完成。在Java語言的開發中，Java給開發人員提供了 java.util工具類，里面包含Timer和 TimerTask來實現這些周期性任務。雖然開發者通過這些包裝類已經節省了一定的開發時間，但是在具體的使用過程中還需要調用大量的編碼以及需要配置很多參數，在代碼的編寫中伸縮性較弱。因此開源框架Quartz的出現使開發者真正脫離出繁瑣的定時任務編寫。OpenSymphony開源組織在任務調度領域中開發了這個定時框架，它的使用不僅可以在Java程序中單獨使用，也可以在企業級應用項目J2EE和J2SE中和其他框架搭配使用。Quartz的并行量非常大，它可以創建并且運行10個、100個，甚至于好幾萬個復雜的任務調度程序Job。 Job是指具體的任務執行，它可以做成標準的Java組件也可以做成EJBso

從規模上來講，Quartz定時器框架與其他眾多開源框架一樣，擁有大約 300個Java類以及接口，拆分到了十二個代碼包之中。與其他框架例如Apache Struts框架的325個Java類和接口數量差不多，它們被拆分到了 11個代碼包之中。當然規模代表著一個框架的代碼數據量大小，但是規模越高并不意味著框架質量就越高，一個框架的判斷標準應當是這個框架可以實現多少量的功能和實現的功能特性來評判。Quartz框架擁有讓各類任務定時執行的功能，無論是表單讀寫能力還是定時操作等問題都可以通過簡單的編寫來實現。Quartz定時器的調度形式非常簡單，即使是初級開發人員也可以很快掌握其調用模式。在這個框架中有個一個核心類叫做org.quartz.Job,它包含了一個Job接口類。Job 接口類中只有一個方法，就是execute方法public void execute

(JobExecutionContext context) throws JobExecutionExceptiono Job 接口類的作用就是具體執行需要定時的操作，例如用戶新建了一個定時刷新報表的功能，那么這個功能就需要將一些邏輯添加到excute方法之中。在定時作業的執行流程中，開發人員不僅僅需要在Job中描述需要執行的任務，還需要在時間調度表中配置其未來的執行時間或者說是其觸發條件。Job擁有一個時間調度表用來實現這個功能，在時間調度表中系統框架可以得知這項任務的剩余時間是多少，從而定時啟動。當系統框架通過時間調度表發現了當前應當執行的作業的時候，Quartz框架會尋找之前描述完成的Job實現類來依次執行所必須的實現操作。在整個執行過程中，調度器或者其他組件不會被通知任何信息，框架的時間調度表會完成一次執行的任務。除了定時任務，在生活中還遇到很多周期性執行的任務，它們在時間調度表中也可以實現周期性能力，Quartz框架會在到期時重復調用這項任務。

調度器是整個Quartz定時器框架中的核心，相當于在一個系統之中 Controller部分。在整個Quartz運行環境之中，是調度器負責整體的運轉邏輯。當然調度器本身并不是去執行所有的實現操作，而是依賴框架之中各個組件之間的相互配合，它只作為指揮官的角色。為了保證框架的伸縮性，一個框架之中將運行成百上千個同時運行的作業，也就意味著Quartz之中包含了大量線程和線程之間的管理作用。其實正是多個線程的存在，才保證了 Quartz可以同時執行多個作業的可能性，在框架的啟動之初，框架會初始化worker線程，依靠這個線程來完成預定的定時任務作業。

對于一個定時框架來講，監聽組件是其觸發執行的重要部分。在Quartz框架之中也是如此，它包含了作業監聽組件、調度器監聽組件以及觸發器組件等。在開發人員配置作業的時候，可以將觸發器監聽設定為全局從而全面監聽，也可以對某一個特定作業進行監聽。監聽的作用就是通過監聽器自動判斷該作業是否達到了預設的執行標準，當達到了以后系統將自動調用資源來執行開發人員期望執行的事情。舉個例子，當開發人員期望在用戶做完購買動作以后向用戶反饋訂單詳情郵件，那么開發人員可以將這個觸發邏輯編寫到該作業項目中順序執行，同時也可以通過JobListener來監聽執行。寫入監聽執行的好處就是被執行項目與觸發條件是松耦合狀態，這樣二者之間并不互相干擾，在程序框架上更有優勢。

2.2自動化測試技術相關理論

2.2.1自動化測試概念與應用條件

自動化測試的意思是利用計算機測試系統來替代手動測試的工作，按照預設的測試數據自動運行測試腳本，對軟件進行自動化測試的技術【29］。在過去的手動測試過程里，當測試數據設計完成并審核通過后，測試人員會按照測試數據依次輸入到系統中，然后依次對比測試的結果，通過手動的比較來判斷系統的合格與否，在這一過程中存在大量的重復的可替代性的工作。當項目工期緊急時，很有可能由于重復性工作過于龐大而影響項目的進度或者是遺漏了部分重要的測試目標。因此，自動化測試技術的出現是為了解決這個問題。自動化測試技術可以節約測試的人力和時間成本，還可以保證測試的覆蓋率，也可以確保測試的一致性㈤〕。計算機系統替代了手動操作，避免了手動測試過程中容易出現的操作失誤，在系統效率提升的同時還可以保證正確率的提升。在一個大型的企業開發項目中，自動化測試技術是必不可少的，它節省了開發人員對測試過程耗費的精力，降低了測試人員的技術使用門檻，從而加快測試效率，推動研發進度向前。但是自動化測試并不是盲目地進行，而是需要在整個軟件項目開發過程中充分的評估前提下進行，否則會致事倍功半，浪費許多系統資源，做許多無用功。因此在設計自動化測試系統前，需要先確定自動化測試系統的使用范圍。下面分別闡述了幾點自動化測試技術使用的適用方面。

第一是系統設計變化頻率低，設計的變化具有提前規劃性。從軟件開發角度講，通常一個軟件系統的規劃應當是提前預判的且不可經常變更，這樣才可以維護一個較為穩定的測試腳本來有效地測試該系統，從而降低測試腳本多次修改的成本。如果一個系統規劃經常發生變化，對于原先系統的功能模塊測試腳本無法適用于新產生的系統模塊，則測試人員需要重新編寫測試腳本而開發人員也需要進行對應的調試。這個過程會增加系統的整體人力和時間成本開銷。在這種情況下，自動化測試技術就并不適用，因為單單維護自動化測試系統的研發程度可能已經超過了其所能帶來的便捷性。此時更適合的測試手段可能是純手工測試，或者是通過自動化測試和手動測試結合的方式。這樣可以保證測試成本的降低同時提升測試質量。

第二是項目周期時間長，擁有充足的測試資源。自動化測試系統本身也是一個軟件系統，它的實現過程和其他系統一樣也需要一定的開發周期，其過程包含了從需求分析到設計實現以及后期驗證的全部步驟，也包含了硬件資源和人力時間成本等。如果一個項目的周期過于緊促，則此時再分配時間給自動化測試系統則得不償失，自動化測試技術也就不適用于這種情況。因此采用一個適用于自動化測試系統的項目需要擁有一個較長的項目周期，還需要有額外的人力和系統資源投入其中。

第三是被測試的模塊需要重復驗證。一個測試腳本的編寫需要消耗一定的人力物力，倘若一個腳本僅僅使用一次或次數不多，那么會造成大量的資源浪費。自動化測試系統的重要意義就在于一個測試腳本可以多次使用，從整體開銷來看，才能降低成本。因此自動化測試技術的使用需要判斷在一個系統中是否存在重復測試的可能性。

第四是，回歸測試的必要性和測試功能點數量。回歸測試的意思是當系統的舊代碼有過修改后，需要對原先的功能進行測試以確保沒有新的錯誤被引入到系統之中。自動化測試技術在回歸測試中有很大的發揮空間。較多的回歸測試和較多的測試目標，在利用自動化測試技術后，可以有效地降低測試成本。

2.2.2自動化測試框架發展

自動化測試框架經過多年的研究發展，經歷了三個發展階段，分別是簡單的錄制回放階段，數據驅動的自動化測試階段以及關鍵詞驅動的自動化測試階段[31][32]。

在簡單的錄制回訪階段，是依靠某些錄制工具來記錄測試人員的操作流程和數據，通過系統對過去保存的測試回放來達到測試的目的。這種錄制回訪的測試可以完成一定程度上的自動化，但是存在一個較大缺陷就是一個測試腳本與其數據時綁定在一起的，當測試人員期望根據一個測試創建出更多測試或者修改這個測試時需要付出很高的成本。即使是測試系統的任何細微變化，都需要測試人員重寫編寫測試腳本，腳本使用率低。

在數據驅動的自動化測試技術中，測試系統的整體架構邏輯基本不發生變化，測試人員針對不同的測試目標編寫不同的測試數據。測試系統通過數據文件將測試數據錄用進系統之中，將數據與腳本結合，進行測試。這種測試模式是在上一個模式上將數據與腳本分離，從而提高數據的利用率，但是對業務邏輯的依賴較高，受系統界面的影響較大。

在關鍵字驅動的自動化測試技術中，對數據驅動的測試進行了改進，從而提升測試系統的可用性。關鍵字測試系統采用了面向對象的思想，它按照關鍵字來拆分測試邏輯。被操作對象（Item）、操作（Operation）和值（value）是關鍵字驅動測試系統的三個重要類，將業務邏輯封裝成不同的關鍵字。其面向對象的特性使得測試數據與腳本分離，將測試系統的內部對象與界面的元素分離，將具體實現細節與測試的描述分離。

根據上述描述可以發現，軟件自動化測試系統的腳本模型也經歷著一個由低到高的階段發展流程卩3】。從最開始由錄制回訪記錄的線性執行腳本，到具有判斷邏輯結構如循環、順序、分支的結構化腳本，到一個測試用例可以被多次利用、可以被其他腳本調用的共享腳本；到數據驅動的、測試數據與執行結構分離的、通過讀入的數據文件來驅動的腳本；到最終的關鍵字腳本。腳本的晉升方向是盡可能地^^分，從而提高每一項的利用率。在目前的大多數測試系統中，基本都處于第三個階段，也就是數據驅動的階段，并逐漸向第四階段關鍵字驅動而演變。隨著計算機測試技術的進步，部分測試服務商可以有效地支持關鍵字驅動的自動化測試框架。

自動化測試框架和腳本的研發也遵循著軟件工程思想的發展，是一脈相承的。這個演變的軟件開發思想模式是指從原先的機器導向到流程導向，從低層次到高層次、從面向對象到服務導向，是一個不斷從具體詳細到邏輯抽象的逐步上升的過程。在這個過程中復用的力度逐漸增加。自動化測試框架的設計思想也在追求者軟件開發中的松耦合思想，也在追求模塊化開發思想，以及追求框架的層次化。

第三章SaaS模式的信息管理軟件自動化測試系統的分析

與設計

本章對SaaS模式的系統管理軟件自動化測試系統進行需求分析以及系統架構和功能模塊設計。

3.1系統需求分析

本系統的目的是針對某商用信息管理軟件平臺實現自動化測試系統，功能主要是面向測試的三個過程，包含創建測試、執行測試以及查看報告。不同的角色在系統中使用權限不同，其中主要包含三種角色：超級管理員、租戶管理員、測試人員。不同角色在測試系統中的權限對應關系如下表3-1所示。

表3-1角色權限對應表

角色權限

超級管理員（超級管理員擁有租戶管理員的所有權限）創建租戶管理員

刪除租戶管理員

租戶管理員（租戶管理員擁有測試人員的所有權限）創建測試人員

刪除測試人員

刪除測試

測試人員創建測試及測試單元

修改測試

查看測試詳情

執行測試

查看測試報告

自動化測試系統主要滿足測試人員創建測試、執行測試和查看測試結果等

需求：

1.租戶管理和用戶管理的需求。本系統基于SaaS模式，即意味著可以為多租戶多用戶提供服務。因此系統需要超級管理員的角色來管理多個租戶，同時需要租戶管理員角色來管理多個普通用戶。

2.測試人員對基于SaaS的便捷辦公的需求。本自動化測試系統選擇基于 SaaS模式展現，降低了測試人員對系統的安裝與維護開銷，把軟件以服務形式在云端提供。

3.測試人員對跨平臺多終端辦公的需求。基于響應式的前端頁面設計，頁面可以自動根據用戶使用的屏幕尺寸和系統平臺進行自動調整。無論用戶是在PC端還是移動端，都可以獲得良好的使用體驗。因此測試人員可以在多種平臺上使用本系統。

4.測試人員對低門檻的測試用例設計的需求。本測試系統拋棄了傳統的腳本編程模式，以圖標和文本框等友好UI界面，降低了測試人員的技術門檻。此外，本系統對常用的測試場景抽象出幾個常用的測試模板，通過基于模板的前端頁面掃描組件，系統自動生成測試用例，極大地提升工作效率同時降低使用門檻。

5.測試人員對測試方案選擇的需求。本系統采用兩種執行方案，一是立即執行，面向于急迫的測試需求；二是定時執行，面向于常規測試需求。因為測試會消耗大量系統資源，當白天系統正常運作時會對正常用戶造成阻塞，利用定時執行測試方案，充分利用夜間人員休息和系統閑時資源。

6.測試人員對分析報表的需求。對于測試的成功與否，細化到每一個輸入框的測試成功與否，本系統提供分析報表。

基于以上需求分析，不同角色對應的用例圖如所示。

圖3-1超級管理員用例圖

3.2系統整體架構設計

3.2.1系統網絡架構圖

在這種模式下，測試請求是直接從本地發往被測試主機的。現有的傳統架構存在以下幾方面問題：

1、部署成本高。其實QTP軟件的安裝流程并不復雜，一般的測試人員可以輕松搞定。但是以其第十一個版本為例，它的安裝包大小為3.61G, 下載安裝的過程需要消耗不少時間。測試人員需要在每一個測試主機上安裝測試軟件，鑒于當下許多中小企業主工作場所不穩定，每一次更換測試主機都需要重新配置。

2、維護成本高。這種模式的測試軟件是部署在測試人員本地的，在使用過程中若測試系統發生任何問題都需要測試人員自己解決，這就產生了許多維護成本。

3、性能存在瓶頸。傳統的測試性能取決于測試主機的性能，單機性能的瓶頸是顯而易見的。如果期望依賴單機性能來提升，不僅僅成本高，其天花板也較低。以作者所在網絡公司為例，公司所配備的電腦在使用一段

時間后容易產生卡頓和容量不足等問題。當在本機使用測試軟件時，測試軟件的運行效率已經被電腦性能所限制。同時在測試過程中是無法同時進行其他工作的。

為了解決上述的問題，本體將服務架構建立在SaaS模式之上，其結構可以如下圖3-5所示。

圖3-5 SaaS模式的測試系統網絡架構圖

在這種模式下，一個測試的執行流程如下：

1、測試人員通過各類終端請求測試云服務。

2、測試人員通過瀏覽器終端與測試云服務交互，包含登錄系統、創建測試、執行測試等。

3、測試云服務商開始對被測試主機執行測試。

4、測試云服務商測試完成后，在服務器生成測試報告。

5、測試人員通過瀏覽器完成測試報告的查看。結束整個測試。

通過對建立SaaS模式的自動化測試系統架構，可以具有產生如下優點：第一是測試軟件無需安裝，企業主按需租用。測試人員無需再像傳統測試軟件一樣安裝配置，SaaS模式的測試軟件是運行在云端服務器，企業主按需租用即可。這樣可以避免上文中提到的下載和安裝所消耗的時間，降低使用門檻。這樣還可以減少企業主隊測試軟件的維護開銷，這包含硬件開銷和軟件開銷。企業技術人員可以將精力更多地投入到軟件開發上去，這也為企業節省了大量信息技術運維人員的資金投入。客戶可以根據自己的需求，選擇更高效、

更快的服務，也可以根據自己的需求降低，使其適用于不同層次的客戶。從企業的角度來看，每月租賃可以用來減少一次性資本投資。

第二是SaaS模式的系統可以隨時隨地遷移使用。鑒于一些規模較小的公司難免會遇到公司轉移或者是業務人員異地辦公等，SaaS模式的系統既然在云端存放，則避免了在遷移過程中的重復安裝和數據轉移。

第三是運行環境不受單機性能限制，高性能及穩定。以亞馬遜AWS云服務為首的各類云服務提供商，為客戶們提供了高效穩定的服務。其計算性能由海量集群計算為基礎，可以有效地提升過往單機計算能力。同時由于多個計算終端的增加和多個存儲結點的加入，當一個服務端點故障宕機時，其他替補結點可以繼續提供服務，保證SaaS模式服務的穩定性。

3.2.2系統業務架構圖

本系統可以分為前臺模塊和后臺模塊兩個部分，前臺模塊是與用戶有直接交互的租戶用戶管理模塊、創建模塊、測試報告模塊等，后臺模塊是數據存儲模塊、測試執行模塊等，如下圖3-6所示。

SaaS模式的信息管理軟件自動化測試系統

前臺模塊

圖3-6系統業務模塊劃分

在設計本系統的業務架構之前，首先從設計模式出發，本系統符合MVC

(Model + View + Controller)三層設計模式。本系統可以根據這個模式分為三個部分，數據模型部分、業務邏輯部分以及視圖界面部分，將這個單個部分分離開來編寫代碼。這樣做的好處是三者之間盡可能減少相互影響，當用戶交互界面升級的時候不需要對業務代碼做改動，當底層數據庫遷移的時候也只會影響數據模型部分，不對其他地方做改變。如此的分層結構可以減少代碼的改動數量。M是指Model模型，模型是MVC設計模式的三個部件中處理任務最多的。M的存在意義是為了增加模型的重用性，當一個模型被建立了以后可以填充不同的數據從而應用于不同的視圖界面，減少了每次的代碼開發，模型是中立的。V是指視圖層，是用戶看到的系統真實直觀的界面，包含網頁以及移動客戶端在內。視圖層獨立出來可以讓其被前端人員開發，后端人員著重于其他部件的開發，只要二者溝通好接口即可。C是指控制器，它是系統的核心業務邏輯，通過調用數據建立的模型填入到視圖之中，來完成用戶提出的要求，而控制器本身并不做處理。控制器的職責是接收請求，調用模型來處理請求，代用視圖來返回結果。

使用人員通過View層與系統進行交互，包括測試人員的登錄、測試人員創建測試、執行測試和查看測試報告等；Model層為數據存儲層，該層負責存儲管理所有測試列表和數據等；其中View和Model層并沒有直接數據通信，而是通過Controller層統一管理。Controller層為自動化測試系統的核心，負責具體的業務邏輯實現，主要的關鍵功能包含了接收View層的數據、控制Model 層的數據存儲、測試流程之中所有的業務邏輯管理.

用戶請求

當下流行兩種MVC模式的Java Web開源框架，分別是SSH (Struts2 + Spring + Hibernate)和 SSM (SpringMVC + Spring + Mybatis) o SSH 通常指的是Struts2做控制器(controller), spring管理各層的組件，hibernate負責持久化層。SSM則指的是SpringMVC做控制器(controller), Spring管理各層的組件，MyBatis負責持久化層。具體如下表3-2所示。

表3-2 SSH和SSM對比表

頁面層(View) JSP JSP

控制器層(Controller) Struts2 SpringMVC

業務層(Service) Java Java

持久層(DAO) Hibernate MyBatis

數據庫層(DB) MySQL/Oracle MySQL/Oracle

組件管理層(Bean) Spring Spring

在SSM和SSH框架中，對應MVC的框架分別是SpringMVC以及

Struts2o他們的職責都是轉發用戶發來的request,區別在于轉發request的方式。Struts2的轉發方式是根據一個Action類來轉發，當從前端接收到一個 request的時候，Struts2負責將其轉發到對應的Aciton類。由于是根據類來攔截的，因此類內部可以數據共享。SpringMVC的轉發是針對類中的方法的。一個請求會對應一個方法。通用的做法是使用requestMapping來配置一個關鍵字來找到請求的方法。方法級別的數據請求是不共享的。在攔截器方面也有一定的差異，Struts2使用的是interceptor組件而SpringMVC使用的是Spring的AOP 特性。此外由于SpringMVC是由Spring的一個模塊衍生而來，它的項目管理和安全性均優于Struts2,與Spring框架的配合也比較簡單。通過使用@ ResponseBody關鍵字可以將方法的返回值自動轉換為JSON數據格式，提升了軟件開發速度。

在持久層兩個框架分別使用的是Hibernate和MyBatiso Hibernate的最大優點是其面向對象的思想，與Java語言搭配起來使用非常容易。在代碼開發人員使用Hibernate的時候不需要編寫任何SQL語句，而是通過映射文件以及包裝類來完成。它的缺點就在于由于不能更改SQL語句，那么在條件查詢和連表查詢等無法進行任何優化，有時候會顯得框架過于龐大。MyBatis恰好彌補了這個缺點，它的SQL語句完全是通過手動編寫，可以隨編寫人員的意圖任意改變，從而具有很高的靈活性和可優化維護的優點。

經過上面的對比，從輕量化和易用性上考慮，本系統采用SSM框架，更適合敏捷開發。

3.3系統功能模塊設計

3.3.1創建測試設計

基于對測試人員的需求分析，本系統需向測試人員提供創建測試的功能。通過對信息管理軟件模塊研究，通常在測試中會涉及到測試時間、測試地址、和測試數據等內容。

為了使測試結構更為清晰，本系統的測試結構可分為兩層，第一層為測試，第二層為測試單元以及輸入輸出組合。一個測試中可包含多個測試單元，而一個測試單元可以包含多個輸入輸出組合。其中第一層測試包含例如測試人員、測試地址、創建時間等共同屬性，第二層包含例如測試子鏈接、測試輸入、測試預期輸出等具體內容。其結構可如下表3-3所示。

表3-3測試結構表

通過以上表格分析，測試人員可以完整地創建一個測試計劃。創建測試計劃的流程與表格結構類似，首先測試人員需在系統中新建一個測試計劃，并填寫測試地址、種類和方案等。其次測試人員可以在該計劃下添加多個測試單元，每一個測試單元可以針對同一功能的不同測試條件，也可以是不同功能的集合體。例如用戶可以創建一個表單測試計劃，而計劃中的測試單元可以是分別測試幾個不同的表單，也可以針對同一個表單測試不同的數據輸入。在執行測試之前，測試人員可以向測試計劃下添加若干個測試單元。此外，執行測試和生成測試報告將以測試計劃為最小單位，即執行測試時將執行所有該計劃下

的單元，生成報告時將生成該計劃下的所有單元。本系統的創建測試流程設計圖如下圖3-8所示。

創建測試計劃

圖3-8創建測試流程設計圖

但是針對于信息管理軟件的分析，通常會面對幾類測試，例如注冊登錄測試、表單測試等，然而這些測試的數據輸入通常較為類似，因此可以通過模板化來提升測試創建效率。因此在創建測試的過程中，測試人員可以選擇是通用的功能性測試，還是注冊登錄測試，還是鏈接測試，還是搜索測試。當選擇完測試種類后，本系統將對不同的測試種類提前設置不同的測試數據，以供測試人員選擇。對于通用的功能性測試，測試人員需手動輸入測試字段以及對應的測試字段數值，本系統對提供隨機生成數據功能，幫助測試人員提升輸入速

通過對測試結構分層以及對測試流程的設計，測試人員可以方便地創建一個測試計劃。在創建測試的過程中，測試人員是在視圖層與本系統進行交互，因此本系統提供友好的交互頁面，從而幫助測試人員更便捷地創建測試以及后續其他操作。關于本系統的前端交互頁面實現效果將在下一章中截圖展示。

3.3.2用例模板設計

本信息管理軟件自動化測試系統提供抽取了三類最常用的測試設計成測試模板：

登錄測試：登錄測試可以分為三個方面，分別是正確登錄的可用性、錯誤登錄的可控性以及特殊輸入的可靠性。首先是正確登錄階段，此時需要測試人員提前提供正確的用戶名和密碼，系統將測試正確的輸入組合是否可以通過登錄驗證，以驗證系統的可用性。其次是測試人員提供錯誤的用戶名或者密碼，系統將測試錯誤的輸入組合是否可以被阻攔，以驗證系統的可控性。最后是系統通過內置的特殊字符庫，產生隨機字母（包含大小寫字母、中文等）、隨機數字（包含阿拉伯數字等）、隨機字母數字組合以及隨機特殊字符（包含逗號、下劃線、問號等），通過查看系統的返回值以驗證系統的可靠性。若系統直接報錯，則認為該系統可靠性不足。

搜索測試：搜索測試可以分為三個方面，分別是正確搜索是否可以出現正確結果，空白搜索是否可以出現所有結果以及特殊輸入的可靠性。首先是正確搜索階段，此時需要測試人員提供正常的搜索字段以及預期的正確輸出，系統將測試在特定搜索字段下是否可以產生預期的結果，從而測試搜索功能的可用性。其次是搜索功能關聯到大量的數據庫，此時的安全性是尤為重要的。在此需要測試在特殊字符的輸入情況，系統的搜索組件是否可以正確過濾掉危險信息。

鏈接測試：此時的鏈接測試可以分為兩個方面，一是鏈接的可達性，二是鏈接頁面的網頁結構。鏈接測試較上兩個測試簡單，沒有過多的輸入參數，只需要提供測試地址。系統根據測試地址請求頁面，并將接收到的頁面進行結點分析，并組建成樹形結構，存儲在數據庫中。

通過對信息管理軟件常用模塊的分析，本系統在此基礎上對信息管理軟件的自動化測試做了優化，即針對三類常用模塊提供專用測試模板。當測試人員創建測試計劃時，可以在測試種類選擇功能測試以外的三種：登錄測試、搜索測試以及鏈接測試。這樣做的目的是為了減少測試人員的測試用例編寫，系統可以提前在數據庫中內置特定的測試數據，測試人員只需做出正確的測試種類選擇，以及補充一些必要信息即可完成特定測試創建。

用例模板的使用流程是在創建測試中選擇特定的測試種類，則再添加測試單元時會跳轉到對應的創建模板，其流程如下圖3-9所示。

3.3.3測試執行方案設計

在分析現有的測試場景時發現，系統測試將消耗大量的系統性能，甚至于影響正常的系統使用。本系統為了解決此問題，提供了定時執行測試的功能，從而提升系統整體使用效率。本系統提供兩種測試執行方案，一為立即執行，二為定時執行。通常來講，當測試人員創建完測試后就可以直接執行測試，進而生成測試報告，測試流程結束。對于系統性能有限，測試人員或者開發人員期望可以提升系統利用率時，系統可以定制測試時間，利用午休或夜晚時間執行，進而生成報告完成測試。

本系統采用市面上常用的開源調度框架Quartz,使用的目的是期望當測試人員創建一項定時任務時，Quartz可以自動密切關注其剩余執行時間，且可以在規定時間準確執行。

執行方案的使用流程圖如下圖3-10所示。

調用Quartz定時執

行

圖3?10測試執行方案設計圖

3.3.4測試系統存儲設計

信息管理軟件測試系統的存儲設計主要包含：對租戶用戶的數據存儲、對測試計劃的儲存、對測試單元的儲存以及各類測試數據和測試結果報告的存儲。在系統整體架構中提到，本系統使用MyBatis作為持久層框架。MyBatis 具有簡單易用和靈活小巧的特點，在代碼編寫過程中它不會對代碼本身產生侵入影響，搭配Spring框架依賴注解即可完成所有持久層操作。最重要的一點是 Mybatis在使用過程中可以將所有的SQL語句集中在對應的mapper文件中，使業務邏輯與數據訪問邏輯區分開來，也十分便于管理。

根據業務邏輯的設計，本小節設計了系統的數據庫ER圖。由于ER圖過于龐大，為了清晰展示拆分成了兩個圖。圖3-11展示了用戶測試層級的ER圖，圖3-12展示了和測試數據層級的ER圖。二者之間的關聯是通過testing測試單元完成，所有的測試數據關聯在測試單元表上。詳細的表結構會在第四章實現章節以表格形式呈現。

圖3-11用戶測試層級數據庫ER圖

圖3-12測試數據層級數據庫ER圖

測試系統的存儲流程基本可以分為三個層次，分別是API接口層、數據處理層和基礎支撐層。

（1）接口層：開發人員通過接口層與存儲模塊進行交互，這其中包含數據增加接口、數據刪除接口、數據修改接口、數據查詢接口和獲取配置接口。當框架接收到接口層的請求時，就會繼續深入向數據處理層執行工作。

（2）數據處理層：數據處理層是數據存儲的核心層，它分為四個部分：參數映射（參數映射配置、參數映射解析、參數類型解析）、SQL解析（SQL獲取、SQL解析、動態SQL）、SQL執行和結果映射（結果映射配置、結果類型轉換、結果數據拷貝）。在開發人員編寫的mapper文件中，將詳細描述開發人員期望執行的SQL操作，而這些操作在這個層次被具體執行。數據處理層可根據調用請求完成一次數據庫操作。

（3）基礎支撐層：基礎支撐層負責最基礎的功能支撐，包括連接管理、事務管理、配置加載和緩存處理，這些都是共用的東西，將他們抽取出來作為最基礎的組件。為上層的數據處理層提供最基礎的支撐。

3.3.5響應式前端頁面設計

隨著智能移動終端逐漸發展壯大成為了互聯網的重要組成部分，從測試人員的真實測試需求出發，很多情況下測試人員需要在移動端查看測試結果報告，例如是在外出辦公情況下臨時查看測試數據。

本系統采用響應式的前端頁面設計目的是為了滿足各類測試情況查看需求，為使用人員提供更好的服務體驗，整合從桌面終端到移動智能終端的各類尺寸和分辨率，確保本系統的前端頁面可以根據用戶使用條件和設備環境進行自適應調整。響應式前端的實現依賴于多個方面，首先是彈性化網格布局，除了滿足測試人員多終端條件下的使用以外，采用響應式前端頁面設計還可以減少開發人員針對不同設備的版本設計量、開發量以及測試量，極高地提升設備可用性和可靠性。

頁面的設計和開發應根據用戶行為和設備環境（系統平臺，屏幕大小，屏幕方向等）進行響應和調整。具體實踐包括彈性網格和布局，圖片，CSS媒體查詢的使用等多個方面。無論用戶使用的是筆記本還是iPad,頁面應該能夠自動切換分辨率，圖片大小和相關的腳本功能，以適應不同的設備；換句話說，頁面應該能夠自動響應用戶的設備環境。響應式網頁設計是一個網站可以兼容多個終端，而不是為每個終端制作一個特定的版本。因此，不需要為即將到來的新設備進行特殊的版本設計和開發。

本系統分析市面上常用的響應式框架，選用最流行的Bootstrap開源框架。 Bootstrap是一個用于快速開發Web應用程序和網站的前端框架，它是基于 HTML、CSS、JAVASCRIPT的，并且在此基礎上重寫了多種結構組件。 Bootstrap可支持多種瀏覽器和設備，具體支持信息如下表3-4所示。

表3-4 Bootstrap瀏覽器和設備支持表

盪:違：蠡邀i

Android YES YES 不適用不適用

iOS YES 不適用不適用不適用 YES

Mac OS X YES YES 不適用 YES YES

Windows YES YES YES YES 不適用

3.3.6測試報告模塊設計

測試報告的意義在于把測試的過程和結果在文檔中呈現，從而幫助測試人員發現系統的問題和缺陷，同時為軟件驗收打下基礎。

首先基于通用的功能測試設計，本系統測試報告需要展示五個部分內容。一是測試計劃基礎信息。其中應當包括測試的創建人員、測試的種類、測試的創建時間、測試的主地址以及測試的執行時間等信息。二是測試單元信息。這個部分應當包含測試單元的名稱、測試單元的子地址、測試單元的輸入、測試單元的預期輸出以及測試單元的實際輸出。另外，通過對比這個單元的預期輸出與實際輸出的正確與否，給出測試是否通過的結果信息。

本系統還有基于用例模板設計的另外三種測試報告模式，它們是在通用功能測試模板基礎上進行的部分改動。鏈接測試的報告在通用功能測試模板基礎上新增了鏈接網頁的樹形結構，從而幫助測試人員測試該網頁信息。搜索測試除了包含測試計劃的基礎信息以外，包含了搜索功能的可用性測試，即輸入正確的參數測試是否有對應的返回結果。此外還需要測試搜索功能對于隨機字符和特殊字符的過濾保護防止SQL注入的功能。登錄測試模板需要提供測試計劃基礎信息以外，在正確的信息輸入下是否可以正常登錄，以及在錯誤的信息輸入下是否可以成功阻攔。此外需要展示登錄功能對特殊字符的過濾能力。

第四章SaaS模式的信息管理軟件自動化測試系統的實現

在上一章中針對SaaS模式的信息管理軟件自動化測試系統進行了系統需求分析、系統架構設計和系統功能模塊設計。本章以某商用SaaS平臺為基礎，對上一章的分析與設計進行實現。本章主要描述了 SaaS模式的信息管理軟件自動化測試系統的兩個方面，一是系統架構實現，二是系統功能模塊實現。其中系統功能模塊包含租戶用戶管理模塊、創建測試流程模塊、測試模板模塊、執行測試流程模塊、測試方案實現模塊、測試報告模塊以及響應式前端實現。

4.1系統整體架構實現

本課題對SaaS模式的信息管理軟件自動化測試系統的框架設計是自頂向下的，在實現時也是遵循這個過程，即先搭建好測試系統的整體框架，按設計預留好規范的接口，然后再根據設計專注于每一個具體功能模塊的實現。

本課題在基于SSM框架，即使用到了 SpringSpringMVC以及Mybatis框架采用了典型的視圖層、控制層、服務層和數據層四層架構。

視圖層。視圖層的作用是對數據進行展現，并與用戶進行交互，如展現登錄頁面，創建測試用例界面，設定執行方案頁面等。視圖層需要保證頁面的合理布局，因此本系統在視圖層應用了響應式前端設計，詳細信息在具體功能模塊實現闡述。

控制層。控制層是系統架構中的大腦核心，它負責解析用戶請求，根據請求以及配置文件調用對應的方法，從而進行自動化測試系統各模塊的業務邏輯控制。控制層的具體功能實現需要依賴它調用服務層的相應服務以及系統中相應的Model來處理和響應用戶請求，如控制創建用例，從現有的模板中調用創建等。本系統的控制層基于SpringMVC框架實現，遵循了 MVC設計模式。

服務層。服務層是業務邏輯的真實實現層面，它提供系統核心服務以支撐自動化測試的各項功能，例如具體創建流程，加載預存儲的測試模板，定時執行測試方案，保存測試數據，生成測試報表等。

數據層。與數據源連接，用于實現數據的持久化，例如用戶信息，測試計劃、測試單元以及測試數據等。本系統在數據層基于Mybatis框架，通過 mapper配置文件實現映射sql查詢，避免了對業務代碼的侵入式污染。這可以幫助實現敏捷開發。

下圖4-1展示了自動化測試系統的框架的實現層次以及其中的部分接口：

數據庫

圖4-1系統框架實現層次圖

根據系統框架層次圖，系統的響應邏輯是自頂向下的，其流程如下:

1、用戶發出請求到視圖層。

2、視圖層根據請求的關鍵字，通過RequeatMapping尋找對應的處理 Controller o

3、 Controller調用Service層對應的服務。在調用過程中使用Spring來注入響應的Service類。

4、 Service層實現具體的業務邏輯。數據的存儲通過調用DAO層完成。

5、 DAO層僅編寫接口文件，具體SQL通過下層的配置文件描述實現。

6、配置文件描述字段-屬性對應關系、SQL操作等，完成數據庫增刪改查。

7、最后從底向上逐層返回數據給用戶。

為了方便框架使用和管理，本系統采用Maven來構建和管理項目框架。在 pom.xml文件中輸入一小段配置信息即可引入Spring框架、SpringMVC框架、 Mybatis框架以及一些必要組件。主要組件的版本號在<properties>中列岀。引入方式如下偽代碼所示。

<dependency 依賴〉

<version> 引入版本號 </version>

</dependency 依賴〉

Maven可以自己維護一個依賴關系庫，通過包名稱、內容名稱和引入版本號來管理。在本系統中引入了大量的依賴關系，其關系可以如下圖4-2所示。由于本系統依賴關系過多，此處只展示了 Spring核心關系依賴。

圖4-2 Maven包依賴關系圖

在使用Maven引入各類框架組件之后，Spring框架可以將各個框架組合起來。Spring的特點就是IOC依賴控制反轉，對象的依賴關系是通過Spring框架

來實現，極大地解決了編碼過度耦合的問題。Spring的關鍵字@人皿（冋說<1的意思顧名思義就是自動注入。當一個類中需要某個對象時，不是使用一個new語句，而是通過依賴注入來產生需要的對象。如此一來當新建對象的語句發生變化時，也不用修改代碼，減少了代碼的修改成本。其偽代碼如下所示。

@Autowired

private Service 類類名；

其注入的流程如下圖4-3所示。

圖4?3 Spring自動掃描流程圖

Spring的自動掃描需要依賴如下配置，在Spring.xml文件中插入如下偽代碼可以實現對在“根目錄”下的添加“注解”的類進行掃描注入。

<context:component-scan base-package="根目錄"〉 <context:include-filtertype="annotation" expression="org.springfi*amework.stereotype.注解"/>

</context:component-scan>

SpringMVC中的控制器Controller負責分發DispatcherServlet的請求，當用戶的請求到達Controller層之后會轉交到Service層來處理，然后將其封裝成一個Model,然后再把該Model返回給對應的View進行展示。在SpringMVC 中提供了一個非常簡便的定義Controller的方法，無需繼承特定的類或實現特定的接口，只需使用@<30血01應標記一個類是Controller ,然后使用 @RequestMapping和@1^41^1卩318111等_些注解用以定義URL請求和 Controller方法之間的映射，這樣的Controller就能被外界訪問到。此外 Controller 不會直接依賴于 HttpServletRequest 和 HttpServletResponse 等 HttpServlet對象，它們可以通過Controller的方法參數靈活的獲取到。 Controller注解示例偽代碼如下所示：

@注解類型

@RequestMapping（"/包路徑"）

@RequestMapping的作用是映射請求的地址對照，它可以標記一個類也可以標記一個方法。當標記一個類的時候，它的作用是將整個類的響應路徑帶上其涵蓋的標簽。如果是標記在一個方法上的時候，則表示這個標簽只針對這個方法路徑。

在持久層采用MyBatis框架進行持久化操作。其執行過程如下，首先是 mybatis-config.xml,此文件作為mybatis的全局配置文件，配置了 mybatis的運行環境等信息，包括數據源、事務管理和數據庫環境配置等。mapper.xm 1文件即 sql映射文件，文件中配置了操作數據庫的sql語句。此文件需要在mybatis- config.xml中加載。通過mybatis環境等配置信息構造SqlSessionFactory即會話工廠.由會話工廠創建sqlSession即會話，操作數據庫需要通過sqlSession進行。mybatis底層自定義了 Executor執行器接口操作數據庫，Executor接口有兩個實現，一個是基本執行器、一個是緩存執行器。Mapped Statement也是 mybatis 一個底層封裝對象，它包裝了 mybatis配置信息及sql映射信息等。 mapper.xml文件中一個sql對應一個Mapped Statement對象，sql的id即是 Mapped statement的id。Mapped Statement對sql執行輸入參數進行定義，包括 HashMap、基本類型、pojo, Executor 通過 Mapped Statement 在執行 sql 前將輸入的java對象映射至旳1中，輸入參數映射就是jdbc編程中對 preparedStatement設置參數。Mapped Statement對sql執行輸出結果進行定義，包括 HashMap、基本類型、pojo, Executor 通過 Mapped Statement 在執行 sql 后將輸出結果映射至java對象中，輸出結果映射過程相當于jdbc編程中對結果的解析處理過程。

4.2系統功能模塊實現

4.2.1租戶用戶管理的實現

本課題是基于SaaS模式實現的自動化測試系統，需要面對多租戶多用戶使用的情況，因此租戶用戶管理是一個重要的模塊。租戶用戶管理主要分為三個方面，一是權限管理，二是用戶管理，三是登錄等具體功能實現。

1.權限管理

本系統采用基于角色的權限訪問控制，用戶通過關聯為不同的角色從而被賦予不同的權限。在第三章系統需求分析中，結合本系統的功能特點設計了三種角色以及每個角色所對應的權限。在代碼實現階段，依靠role角色表來管理系統所有角色。角色表結構如下表4-1所示。

表4-1 role角色表

id INT(ll) 自增序號，主鍵。

name VARCHAR(24) 角色名稱

description VARCHAR(24) 角色描述

在常規的角色權限控制中會采用一張權限表來管理所有權限，由「本系統的角色較少，且角色之間的權限差距也僅在于一兩個功能，因此本系統在前端判斷角色，若角色不擁有此權限，則直接隱藏該功能。例如普通測試人員沒有

刪除測試的權限，而其他兩個角色可以刪除，那么在前端的刪除權限判斷片段。其判斷流程圖可以用如下圖4-4流程圖展示。

此處使用到JSP的<c:i£>判斷語法。其語法格式如下所示:

<c:if test="<boolean>" var="<string>" scope="<string>"> 執行的語句；

</c:i£>

對于語法中的標簽意思如下表4-2所示。

表4-2權限判斷參數表

2.用戶管理

本系統中所有的用戶數據均維護在一張user表中，主要包含用戶名、密碼和角色信息。其中，鑒于角色較少且為了簡化用戶與角色的關聯，在用戶表中直接存儲用戶的角色信息，用數字整形表示。用戶表結構如下表4-3所示。

表4-3 user用戶表

(■■■■■■■■■■■■■■■I

二字段：「粋汕匚「， . \「說明； ’

id INT(ll) 自增序號，主鍵。

company VARCHAR(24) 公司名

username VARCHAR(24) 登錄名

password VARCAHR(24) 密碼

role INT(ll) 角色編號，0表示超級管理員，1表示租戶管理員，2表示普通測試人員。

3.登錄及Session管理

登錄及Seesion管理是用戶管理中的重點，這是實現權限管理的基礎，其業務邏輯流程圖可以如下圖所示。

如上圖所示，本系統的每次操作都會經過登錄攔截器。系統會判斷是否進入的是登錄頁面，如果是則放行。如果不是，貝0判斷session中是否有該用戶的信息，如果沒有則攔截并且跳轉到登錄界面。

在本系統的所有操作中，例如創建測試等都需要建立在用戶已經登錄的情況下。因此，為了本系統可以在session中維護已登錄用戶列表，需要在Spring 中配置攔截器，配置的偽代碼如下所示。

<mvc:interceptor>

<mvc:mapping path=,7**"/>

</mvc:interceptor>

在系統登錄頁面中，如果用戶登錄成功，則系統會把用戶信息放置于 session之中，以便于之后使用。Seesion的放置是通過如下偽代碼實現。

httpSession.setAttribute（"Session 名字"，Session 內容）；

在Http中會自動維護一張Session表，當用戶登錄以后可以把用戶名、權限等內容放置在Session中，從而在之后的使用中提取出來判斷。

配置中表示進入系統的任何一個頁面都會先經過登錄攔截器，在攔截器中在攔截器中中有三個方法：

preHandler :這個方法的作用是在進入Handler之前進行操作，適用于登錄校驗。如果用戶沒有登錄，則此時會返回false,不再繼續向下進行。如果已經登錄，則返回true,不攔截。

postHandler :這個方法是在進入Handler且在返回ModelAndView之前運行，適用于在返回數據之前的操作。

afterHandler :這個方法是在執行完Handler之后執行，適用于做日志等功

能。

4.2.2創建流程的實現

根據第三章對創建測試流程的設計，本小節對創建測試的具體流程編碼。當點擊創建測試按鈕后，SpringMVC接收請求后會在第一時間記錄當前創建時間且創建時間不可改動，然后調取創建頁面發送給用戶，然后完成創建。其詳

細流程圖可以如下圖4-6所示。

圖4-6創建測試流程圖

如上圖所示。當用戶創建測試時首先需要點擊創建按鈕，Controller會通過關鍵字配置RequestMapping找到對應的方法，返回創建頁面。用戶在創建頁面中填寫測試計劃信息，并保存到數據庫中。測試包含兩個層級，第一層為測試

計劃，第二層為測試單元。在測試單元創建的時候，其他步驟與第一層類似，知識多了一個模板選擇和Map格式組裝。

一個用戶可以創建多個測試，測試與用戶的關聯通過在測試表中增加 user_id進行關聯。測試計劃與測試單元為一對多關聯，在設計表結構時，為了結構清晰，將在測試單元中包含測試計劃的編號為外鍵。測試計劃的表結構如下表44所示。

表4?4 test測試計劃表結構

字段數據類型說明

id INT(ll) 自增序號，主鍵。

userid INT(ll) 創建者編號，外鍵。

name VARCHAR(24) 測試計劃名稱

createtime DATETIME 測試計劃創建時間

excuted TINYINT(l) 測試計劃是否己經執行，未執行為0,執

行完畢為1 =

excutetime DATETIME 執行時間

is_excute_now TINYINT(l) 是否立即執行，默認為是1,定時執行為0

url VARCHAR(1024) 是否已經執行

testtype INT(ll) 測試種類。0為功能性測試，1為鏈接測試，2為搜索測試，3為登錄測試。

測試單元的表結構如下表4?5所示。

表4-5 testing測試單元表結構

字段 •忑；.“：g蹲絢釁鑿勰倔濫綬嚓瀚

數據類型說明

id INT(ll) 自增序號，主鍵。

test_id INT(ll) 測試編號，外鍵。

url VARCHAR(1024) 測試主IP地址。

testing_name VARCHAR(64) 測試單元名稱。

result TINYINT(l) 測試單元執行完畢后寫入結果，0表示正確，1表示錯誤。

測試單元輸入表結構如下表4-6所示。

表4-6 testing input測試輸入表結構

字段數據類型說明

inputid INT(ll) 測試輸入編號，主鍵。

testingid INT(ll) 測試單元編號，外鍵。

input key VARCHAR(ll) 測試輸入map的key。

inputvalue VARCHAR(ll) 測試輸入map的value o

inputtype INT(ll) 測試輸入類型，0為手動輸入，1為隨機字母，2為隨機數字，3為隨機字母和數字，4為隨機特殊字符。

本系統的測試對象是信息管理軟件，為了提升系統的便捷性，在測試數據輸入頁面，本系統向用戶提供快捷勾選按鈕：隨機數字、隨機字母、隨機數字字母組合和隨機特殊字符，用戶只需勾選按鈕而無需再手動輸入結果。其實現方式是提前在數據庫中存儲上述字符，當用戶勾選對應按鈕時，input_type字段也會做相應的設置。當input_type不為0時，系統會依據input_type在隨機輸入表中提取所有該類型的字符，并隨機選擇出本次測試輸入結果。其運行流程如下圖4-7所示。

圖4-7隨機生成測試數據流程圖

數據庫中的測試隨機輸入表結構如下表4-7所示。

表4-9 testing_output測試輸出表結構

字段數據類型說明

Outputid INT(ll) 測試輸岀編號，主鍵。

Testingid INT(ll) 測試單元編號，外鍵。

Outputkey VARCHAR(ll) 測試輸出map的key值

Outputvalue VARCHAR(ll) 測試輸出map的value

值

423測試模板的實現

根據第三章對用例模板的設計，本系統提供針對信息管理軟件的三種快速測試模板，分別是鏈接測試、搜索測試和登錄測試。

在上一小節可以看到，當測試人員創建測試時，測試有一個屬性為testType 字段。在此測試人員可以選擇其創建的測試屬于哪一類，不同的測試類別測試輸入的產生方式亦不同。

「用戶選擇\

test_type != 0 /

判斷 test_type〉

圖4-8測試模板生成用例流程圖

當testType等于1時為鏈接測試。鏈接測試時為了測試頁面結構，并形成樹形結構，此時只需要測試地址一個參數而不需要其他數據，因此這一類測試不包含測試單元。鏈接測試在創建時需要在測試計劃層級選擇鏈接測試種類，即可直接完成創建。測試結果也與上一節的testing output有所不同，針對鏈接測試新建了數據庫表test link result,其結構如下表4-10所示。

表4-10 test link result鏈接測試結果表結構

一：八

id INT(ll) 鏈接測試結果編號，主鍵。

testid INT(ll) 測試計劃編號，外鍵。

result TEXT 鏈接測試結果。

鏈接測試的關鍵在于對得到的頁面進行DOM解析，從而在測試系統構建樹形結構。在此本系統使用了 jQuery提供的zTree插件，zTree的特點是性能優異、配置靈活且擁有多種靈活的配置和多種功能組合。專門適合項目開發，尤其是樹狀菜單、樹狀數據的Web顯示、權限管理等等。

當testType為2時為搜索測試。搜索測試基于第三章的設計，分為幾個步驟。首先測試特定輸入是否有對應的輸出，即需要一個表來保存特定的輸入輸出。搜索測試的輸入結構與通用結構屬于有少許差異，增加一個搜索輸入表格，其輸入表結構如下表4-11所示，輸出表結構如下表4-12所示。

表4-11 testing_search_input搜索測試輸入表結構

字段數據類型 ; 說明

id INT(ll) 搜索測試輸入編號，主鍵。

testingid INT(ll) 測試單元編號，外鍵。

searchquestion VARCHAR(45) 正確搜索的輸入

searchanswer VARCHAR(45) 正確搜索的輸出

表4-12 testing_search_output搜索測試輸出表結構

〕數據類型說明

id INT(ll) 搜索測試輸入編號，主鍵。

testingid INT(ll) 測試單元編號，外鍵。

searchtest TINYINT(l) 正確搜索的測試結果。0表示

「通過，「1表示未通過。

lettertest TINYINT ⑴ 隨機字母的測試結果。0表示通過，1表示未通過。

numbertest TINYINT(l) 隨機數字的測試結果。0表示通過，1表示未通過。

letternumbertest TINYINT(l) 隨機字母和數字的測試結果。0 表示通過，1表示未通過。

specialsymboltest TINYINT ⑴ 隨機特殊字符的測試結果。0 表示通過，1表示未通過。

記錄完特定的輸入輸出后，搜索測試還需要測試隨機字母、隨機數字、隨機字母數字的組合以及特殊字符，此段的實現方式和創建測試流程中的測試單元采用相同的邏輯。

登錄測試基于第三章的設計，分別測試登錄測試的可用性、對于錯誤登錄是否可以阻攔以及可否滿足對特殊字符的注入攻擊過濾。登錄測試新增了登錄測試輸入表，其結構如下表4-13所示，輸出入下表4-14所示。

表4-13 testing login input登錄測試輸入表結構

11鑿iiiii鈞瘞琴「譽奏童套：「

SBB■暮■汙'「「1111嚴 I〕［IB1

id INT(ll) 登錄測試輸入編號，主鍵。

testingid INT(ll) 測試單元編號，外鍵。

correctusername VARCHAR(45) 正確登錄名

correctpassword VARCHAR(45) 正確密碼

wrong_username VARCHAR(45) 錯誤登錄名

wrong_password VARCHAR(45) 錯誤密碼

表4-14 testing_login_output登錄測試輸出表結構

id INT(ll) 搜索測試輸入編號，主鍵。

testingid INT(ll) 測試單元編號，外鍵。

correctlogintest TINYINT(l) 正確登錄的測試結果。0表示通過，1表示未通過。

wronglogintest TINYINT(l) 錯誤登錄的測試結果。0表示通過，1表示未通過。

letter_test TINYINT(l) 隨機字母的測試結果。0表示通過，1表示未通過。

numbertest TINYINT(l) 隨機數字的測試結果。0表示通過，1表示未通過。

letternumbertest TINYINT(l) 隨機字母和數字的測試結果。0 表示通過，1表示未通過。

specialsymboltest TINYINT(l) 隨機特殊字符的測試結果。0 表示通過，1表示未通過。

在測試完登錄測試的正確輸入與錯誤輸入的判斷能力后，系統會測試對隨機數字、隨機字母、隨機數字字母組合以及特殊字符的過濾能力，這個與創建測試中的測試單元創建流程相同，因此不做重復展示。

4.2.4測試流程的實現

執行測試模塊包含了從創建測試結束后，系統從數據庫中讀取組裝測試數據，發送測試數據，接收測試結果，到測試結果寫回的全部過程。下面將依次介紹實現流程。

測試執行的整體流程如下圖4-9所示。

當用戶點擊執彳亍按鈕時，前端頁面會向后臺發送testRun請求以及對應的測試編號。定時的測試系統不需要前端觸發，后端自動執行。SpringMVC在捕捉到該請求時會調用對應的執行測試服務，進而依次執行每個測試單元。

測試執行觸發后，在Service層，系統需要從數據庫中組裝所有的測試參數。在本系統中，主要包含四種測試類型，分別是功能測試、鏈接測試、搜索測試和登錄測試，其中后三種的測試是建立在第一種的測試上。在此將詳細介紹第一種測試執行流程，后三種只是在參數產生和結果展示上存在部分差異，其數據結構可在上一小節中查看。在測試參數組裝中，第一步，系統會根據測試編號查找其下所有測試單元形成數組。

由于測試單元的參數傳輸是以Map的格式傳輸，因此參數組裝的第二步是從數據庫中將該測試單元下的所有測試輸入組成Map格式。具體的代碼流程是首先以測試單元編號抽取所有的Testinginput,后遍歷Testinginput數組組成鍵值對。

測試數據組裝后，系統將向被測試主機發送測試請求并接收測試結果。本系統的通信傳輸采用Spring REST服務來實現。更簡潔的講，REST就是將資源

的狀態以最適合客戶端或服務端的形式從服務器轉移到客戶端(或者反過來)。在REST中，資源通過URL進行識別和定位。REST中會有行為，它們是通過 HTTP方法定義的。具體來講，也就是GET、POST、PUT、DELETE. PATCH 以及其他的HTTP方法構成了 REST中的動作。Spring支持多種方式來創建 REST資源:控制器可以處理所有的HTTP方法，包含四個主要的REST方法： GET\PUT\DELETE\POST\PATCH；借助@PathVariable 注解，控制器能夠處理參數化的URL(將變量輸入作為URL的一部分)；借助Spring的視圖和視圖解析器，資源能夠以多種方式進行表述，包括將模型數據渲染為XML、JSON、 Atom以及RSS的View實現；借助@ResponseBody注解和各種 HttpMethodConverter實現，能夠替換基于視圖的渲染方式。

本系統采用借助RestTemplate來使用REST資源。其偽代碼為

private Map<String, Object> testingRun(String targeturl,Map<String, Object> params) {

Map<String, Object> result = restTemplate.postForObject(url, params, Map.class)；

}

其發送請求及接受的時序圖可以如下圖4-10所示。

updateOutputResultf}

updateTesting()

圖4-10測試流程執行時序圖

在上面的偽代碼中，url表示請求地址即資源，params表示測試數據即從測試系統向被測試主機發送的參數，Map.class表示測試返回的結果格式。當獲取完測試結果后，系統會將測試結果轉化為map格式寫回數據庫。

圖4-11數據發送與接收流程圖

執行測試的最后一步是將預期輸出結果與真實測試結果進行比較，若相同表示和預期一致，測試結果正確，若不同則測試結果錯誤，測試人員可以仔細排查問題。測試結果的比較是按照map的格式對比。

一個測試計劃中包含多個測試單元，在一個測試單元結束后會依次執行后面所有的測試單元。當所有的測試單元都執行完畢，測試計劃的excuted屬性被置為true,此時測試人員才可以查看測試報告。

此外為了實現回歸測試，系統對每一個執行完畢的測試都提供重新測試的功能。也就是說系統保留了該測試計劃的所有參數，當測試人員對被測試系統進行修改時，可以進行回歸測試。

4.2.5測試方案的實現

本系統向測試人員提供了兩種測試執行方案，即立即執行和定時執行。立即執行方案在測試人員點擊執行按鈕后即可觸發執行，在上一小節有詳細的描述。本小節實現基于Quartz框架的定時任務執行。

時間字段的配置需要Cron表達式，其格式如下表4-15所示。

表4-15 Cron時間表達式參數表

字段允許值允許的特殊字符

秒 0-59 ,-*/

分 0-59 .-*/

小時 0-23 ，-*/

月內日期 1-31 7/LWC

月 1-12 或

者 JAN-DEC ,-*/

周內日期 1-7 或者 SUN-

SAT ?/LC#

年（可選）留空,1970-

2099 ，-*/

在本系統中將Spring與Quartz整合實現定時任務。首先在Maven的Pom 文件中需要將Quartz的包引入到工程之中。Spring文件中需要配置Quartz的相關參數Bean映射。Quartz的執行流程可以用圖4-12表示。

圖4-12 Quartz框架執行流程圖

在配置好以后需要實現Quartz框架中的四個內容：Job、JobDetaih Trigger 以及Schedulero Job對應一個執行內容，定時執行方法需要實現excute方法。在創建定時執行時，需要創建JobDetail和Trigger分別負責任務執行和觸發器。Scheduler代表一個調度容器，一個調度容器中可以注冊多個JobDetail和 Triggero通過數據來設定Trigger,也就是在運行時設置觸發器。

4.2.6測試報告的實現

根據第三章的測試報告模塊設計，本系統在測試計劃完成后向測試人員提供查看測試報告的功能。本系統包含四類測試，測試種類的不同，其測試報告的結構也有部分差異。在此先介紹最通用的功能測試報告。功能測試報告的存儲沒有建立單獨的數據庫表，而是從前幾個小節的測試輸入、測試預期輸出和測試實際輸出等表格組裝而成。

測試報告的生成流程圖如下圖4-13所示。

圖4-13測試報告生成流程圖

當用戶點擊查看報告按鈕后，前端會向后端發送testReport請求，根據 testjd查詢所有該測試計劃下的測試單元。

此時的testing列表組裝完畢，接下來需要向其中填充測試數據。因此第二步是根據testing_id查詢所有該測試單元下的測試輸入、測試輸出、測試預期輸出。在填充這些數據之前，由于它們在數據庫中存儲的格式為單條存儲，而在報告頁面展示時需要map格式，因此在進行填充之前需要對其做數據結構轉換。可以看出，此時需要調用三個組裝函數：getInputMap()、getOutputMap()、 getExpectedMap(),三個函數的結構較為類似，以其中的getOutputMap()為例。

為了詳細的展示測試結果,在此定義了測試輸出結果類TestingOutputResult. class TestingOutputResult

{

private String key; 〃測試字段值

private String expectedOutput; 〃測試預期輸出結果

private String output; 〃測試實際輸出結果

private Boolean result; 〃測試結果正確與否

}

TestingOutputResult類的目的是將上一步中的預期輸出ExpectedOuputMap 與實際輸出OutputMap組合在一起，讓測試人員可以清楚地看到在某個字段值下的輸出結果對比。

至此，測試報告所需的內容已經組裝個完畢，SpringMVC框架將所有的數據返回給前端頁面進行展示。

4.2.7響應式前端實現

根據第三章對響應式前端頁面的設計，本系統需要滿足針對不同設備的尺寸以及分辨率自動適應。本系統的響應式前端頁面基于來自twitter的開源前端框架Bootstrap,它基于HTML、CSS和JAVASCRIPT,提前包裝了布局網格、各類組件和插件等。

首先Bootstrap的使用需要在頁面<head>部分引入CDN服務文件，包含 Bootstrap核心代碼和jQuery等。引入的數據源可以來源于下面：

<!—引入 Bootstrap —>

<link

href="http://cdn.static.runoob.com/libs/bootstrap/3.3.7/css/bootstrap.min.css" rel=" stylesheet">

<!-jQuery 文件。務必在 bootstrap.min.js 之前引入-->

<script

src="http://cdn.static.runoob.com/libs^query/2.1. l/jquery.min.js"></script>

<!-最新的 Bootstrap 核心 JavaScript 文件-->

在本系統的前端開發中，表格布局采用了 Bootstrap提供的響應式流式網格系統，示例圖如下圖4-14所示。該框架會根據屏幕的尺寸自動將屏幕分為12 列。將需要排版的內容防止在container中，框架會獲得適當的對齊

（alignment）和內邊距（padding）。在創建測試的前端代碼中，將前端展示內容放置在container中，在class中設置需要的列數（此時為2和10）,則框架會根據比例自動調整大小排列。

除了該框架提供的自適應排版，它還提供了大量可搭配的自適應組件，如按鈕、表單、導航組件等。本系統前端頁面的開發中也大量使用了 Bootstrap所提供的樣式。

第五章SaaS模式的信息管理軟件自動化測試系統的展示

與驗證

5.1測試環境

實驗環境如下，硬件環境如表5-1所示，軟件環境如表5-2所示:

表5-1實驗硬件環境

楓器名稱詳細配置

Jetty服務器 ThinkPad 筆記本 i5-4200M 8G 內存 500G 硬盤

測試主機 ThinkPad 筆記本 i5-4200M 8G 內存 500G

硬盤

網站主機 ThinkPad 筆記本 i5-4200M 8G 內存 500G

硬盤

表5-2實驗軟件環境

軟件名稱版本信息

Windows Windows 10專業版

Jetty Jetty 8.1.9.v20130131

Java Java 1.8

Maven Maven 4.0.0

Spring Spring 4.3.8.RELEASE

SpringMVC Spring 4.3.&RELEASE

MyBatis MyBatis 3.4.1

Dbcp2 Dbcp2 2.1.1

MySQL MySQL 5.7.12

5.2系統驗證

5.2.1登錄界面

進入本系統的第一個界面是登錄界面。如下圖5-1所示。在此處輸入公司名：1；用戶名：admin；密碼：1,點擊登錄即可進入系統，進入到5.2.2的測試列表頁面。

Autolest Project 1 - -Olii

公司名 *

窯碼 1

•S?

圖5-1登錄頁面截圖

由于本系統配置有登錄攔截器，當用戶使用本系統時，系統會檢查session 中是否包含該用戶以檢查登錄與否。當沒有登錄時，登錄攔截器會將頁面重定位到登錄頁面。

5.2.2測試列表頁

當用戶成功登錄后，會進入到測試系統主頁面即測試列表頁。本頁將列出當前系統的所有測試，包含測試的編號、創建人員、測試名稱、測試類型、測試狀態以及可執行的操作。列表頁如下圖5-2所示。

AutaTest Project Al® Gsupped 山2 -

測試名稱測適狀態: ■ Q游

測試？SW 創建者ID 測試名稱測試類型測試狀態樣作

2 功席試 false 罰:汎；中訂

2 2 it tn®

3 2 測試功能渕試 false 禱祀？俸戲：洋惓

4 2 asc? 功能;8｛試

5 2 cesh> 功ii蕩試 ta«e 遙新徂疔rm

S 2 ceshi20-!70e0? true 篁勢陽活，査膏桜皆

7 2 功能滾試 true

圖5-2測試列表頁截圖

由于本系統存在權限控制，當普通測試人員登錄時前端頁面會判斷其不具有刪除權限，因此登錄后雖然可以看到所有列表，但是在操作欄沒有刪除按鈕。普通人員的測試界面如下圖5-3所示。

I AutoTsst Project 伶主頁 + 鈉遨憲iS O Sfipport:

測試名稱測試狀態: 讖:澎' Q嵯

測試編呂創if考Q 測試名你測試類單測試畑

1 2 ，功物試 fese •5-.< '？洋段

2 2 true 蘇-丸墳：直養誓宗

3 2 faee

4 2 :ee

5 2 Ceaftl 功能殛 t^us

圖5-3普通測試人員測試列表截圖

5.2.3創建測試計劃

在本系統中，測試人員可以點擊左上方的創建測試開啟創建測試計劃，點擊后進入新建測試計劃頁面，如下圖5-4所示。

窗建人員 acri*

當甫時冋 S3S0KO9 CSJ Q /

測試名稱 i CS$ffi2O<?125t»

測試種類

測試幀 i f：^p.>：-,27 O.a.1.SQ91

執行方案

執行時問上"：廠

圖5-4創建測試計劃頁面截圖

在本頁面中，測試系統自動填充創建人員和測試創建時間。測試人員需要填寫測試名稱、測試種類、測試地址和選定執行方案。在此處選擇的是功能測試，測試地址設定為:127.0.0.1:8091,立即執行。

其中當測試人員選擇不同測試種類時，會觸發不同的創建模板，如下圖5?5 所示。功能測試的詳細添加在524節添加測試單元中展示，鏈接測試、搜索測試和登錄測試的頁面在5.2.5節模板創建測試中展示。

圖5-5測試種類選擇截圖

本頁面還可以選定測試的執行時間，若選定按鈕定時執行，則可通過下面的時間插件寫入執行時間。如下圖5-6所示。

圖5-6測試時間選擇控件截圖

5.2.4添加測試單元

在上一步添加完測試計劃后，就可以通過添加測試單元實現具體數據的填充。基于第四章的實現，測試單元為二級類目，從屬于測試計劃。測試單元對應測試詳情信息，如測試單元名稱、測試單元URL、輸入數據以及預期輸出數據。添加測試單元頁面如下圖5-7所示。

Autolest Project 舎壬煮

測試單元名稱

測試單元URL

字段值手端i；

+加更務更試褊入預期$li字段」：：？ •

•亍段值

+ ；£啓多■腌試輸小

丁宅歸?E

圖5-7添加測試單元頁面截圖

此處測試某系統的登錄功能，輸入數據表格如下表5-3所示。

輸入后的效果圖如下圖5-8所示。

圖5-8測試單元數據圖

此外，在輸入測試數據時，針對信息管理軟件提供的快速輸入，可以通過下拉列表來選擇。測試數據隨機輸入方式如下圖5-9所示。

5.2.5模板創建測試

為了快速地創建測試，本系統提供三種特定類型的測試，分別是鏈接測試、搜索測試和登錄測試。

在鏈接測試中，由于輸入參數只有測試地址url,因此不具有測試單元，而是直接使用測試計劃中的地址，如圖5-10所示。

n«p ；” 2? 3 x 309：

拯行方案 *立盹行

執行時間 <-：■：

圖5-10鏈接測試創建截圖

在搜索測試中，當點擊添加測試單元時，會進入專用創建頁面。本頁面中，測試人員需要填寫測試單元名稱和測試單元URL。其次要填寫正確的搜索字段以及預期輸出字段值，以驗證搜索功能的可用性。最后勾選期望測試的特殊輸入情況，以驗證系統的可靠性。搜索測試創建截圖如下圖5-11所示。

測試單元名稱

圖5-11搜索測試創建截圖

在登錄測試中，當點擊添加測試單元時，會進入專用創建頁面。本頁面中，測試人員需要填寫測試單元名稱和測試單元URL。其次要填寫正確的登錄用戶名和密碼，以驗證當正確輸入時登錄功能的可用性；要填寫錯誤的用戶名和密碼，以驗證在錯誤輸入下可以有效阻攔。最后是勾選隨機輸入，從而驗證登錄功能對sql注入的防范作用。登錄測試的創建截圖如下圖5-12所示。

測試單元名稱登錄洌試

測試單元URL xesh^Ggin

圖5-12登錄測試創建截圖

5.2.6測試報告

測試完成后，測試人員可以查看測試結果報表。

對于通用的功能測試，其測試結果報表形式如下5-13和圖5-14所示。圖中包含兩部分內容。上面為測試計劃的基礎信息，包括測試計劃名稱、創建人員、創建時間和執行時間等。下面為該測試計劃下所有的測試單元信息，包含每一條測試單元名稱、測試輸入、測試預期輸出以及測試實際輸出等。

測試單元名稱 1

測試單元子接 -ceshkiogin

測試字段測試輸入

password con

username cbh

返回字段測試預期倫出測試實際輸出測試結果

code 0 0 true

圖5-14測試報告測試單元部分截圖

對于鏈接測試，其上半部分與功能測試的模式相同，區別在于測試結果的樹形結構，如下圖5-15所示。

auro 1 est project w 土區

創建時間 Tnu NOV 30 00:00 00 CSFT 2917

拗亍方案立即執行

測試地址 http;//127.0 0.1 ;8091/iogin

測試結果日“ fir <html>請登錄 Toggle navigatio...

$?vhead>番登錄

白=<body>Toggle navigation Au...

2 & <div>Togg!e navigation Au... 田“ ■ <div>Toggle navigation Au... E M <form>公司名用戶名密碼登錄曰恰<(Kv>公司名

.clabe卜公司名

:田-? <div> 曰宦<div>用戶名

■ <label>用戶名

i 由"■ <dtv> 白& vdiv>密碼 | Pii <label>S^ 曰.<div> 白整<div>§錄 0 ? <div>§錄

圖5-15鏈接測試報告截圖

對于搜索測試，其結果頁面如下圖5-16所示。前半部分測試的是特定的輸入與輸出，后半部分為系統隨機生成的測試數據。

測試單元名稱際期

測試孚元子璉接 -searcnlest

正確拴素隨機字母隨機數字隨機字母和數字隨機特殊字符

true true true : true true

圖5-16搜索測試結果頁截圖

對于登錄測試。其結果頁面如下圖5?17所示。前半部分為正確登錄驗證和錯誤登錄驗證，后半部分為系統隨機生成的測試數據。

;iogtn

正確登錄名正確密碼測試結果

test true

錯誤登錄名錯誤密碼測試結果

test 3S0? 細se

隨機字母隨機數字屢機字母和數字陸機特殊字符

true true true 鏟ue

圖5-17登錄測試結果頁截圖

本系統的前端頁面采用了 Bootstrap開源框架來實現屏幕的自適應，此處用手機登錄示例來展示網格系統的自動流式布局。如下圖5-18所示。

••ooo 中國聯通守 10:34 ◎ V 94%

Autolest Project

JU細洽-Q殳德

潴試名稱滋試類型溉試垃態

? fafee 於眾/奔改/洋燃/攜行，忝

1S 功砌試 true 蟹贛攜行/酬第告/窺聲

邈試功能遼1試 false 念按，‘唸姦/詳橫/按紓馮

ascf 功能懣試 true 離場瞬，裁遴馥告

cesbi 功刪試 true 嚎贛塊行廠逡攣羯卷/稔徐

ceshi2Oi709C7 功能測試 tnue 幾範執行/燮轡按告/夥錚

cesht2Ol /U9UB 功刪試 true 塗鬆統找/霖緻撥吿/離住

201709l<? 旳能測試 true 瑟黔割技/蜜鑽強吿/鑒絲

ceshi 功翊試 fafee 社e，縷藪/詳麟/挾紓碌

中文筋試功録測試 false 疹撈,鏗改/譯悔/拱行

功能測試 false 謬攙/蒔救/淳槓/拱行

功繼瀏試 fcrise 添您/褥這/報/強紓f鑿

功能測試 false 空壽，‘滲違/洋儀/塊行，臉

r?jOJi£ false 添於/瑟茲，溜覆/攜行/it

test 確接測試 true 惡孰銳公/逮巒報咎/魏絲

楷縈測試 true 護熱痰衣/囊嗓報告

鎧接測試 faise 螳孜/注暢/誘逹/W

〈二 □ O

5-18 Bootstrap自適應布局

5.2.8性能測試

在本系統的開始執行和結束執行之間計算了毫秒差值，從而計算一次測試調用需要的時間情況。下圖5-19為IDEA終端輸出的時間值。

信息 Mapped URL path L/**j onto handler oj

開始執行測試，測試名稱：槌接

執行測試完畢，測試名稱：槌接

十二月 23, 2017 9 50: 58 上午 oxg. spiringf ian»

1 言.息， Closing oxg spx ingf iame»ork. c oat ext si

******* 11；4 **：+：* 木家 *

平均響應時間：1174.0

Process finislied -ith exit code 0

圖5-19 IDEA測試時間值圖

統計了 100次測試時間，其圖標如下圖5-20測試執行時間所示。縱坐標為執行時間，單位為毫秒。橫坐標為測試的組數。

圖5?20測試執行時間圖

此外還測試了系統的QPS (TPS)=并發數/平均響應時間。當并發量為5的時候，系統的平均響應時間如下圖5-21所示。廠：簽. 」

pxivat* static flaal iat SIZX =斗：

3g ■ i

)

麗n TestCcnVo： erlest tesiRt nlevt

ViB話乓：瓷吞*亠 ” 』嗽!織恤ipn劃卵咽世則』毆側! 畫畫亟加刪 "、1 test passed '「Gw

碎 TestControllerTest:‘宀執•行測1壇畢，測過名稱：桶接

駕 testRunTest ««*««««1295*******

9 2*******

**»**$*1391*******

*******1392***4：”*

平均響應時間：1372.4

Pxoctss finished with exit code 0

» : . .、

0: Messages 龜 Java Enterprise i/ 91 Version Control 妙 Spring ® Terminal - , 4: Run .• 5: Debug TOGO

圖5-21系統10并發量平均響應時間圖

之后測試了并發量更多的情況，匯總為下圖5-22系統QPS圖。縱坐標為

QPSo橫坐標為并發數。可以看出約在并發量為800時達到QPS最高，約 91.986.

QPS

圖5-22系統QPS性能圖

5.2.9 Selenium 工作比較

此處以傳統測試軟件Selenium為示例，它是一個可以運行在火狐瀏覽器的插件形式的測試軟件。主要是用來測試Web項目。此處實驗使用Selenium錄制功能打開Firefox瀏覽器中默認頁面的某一個書簽，但是重放時會產生定位不準

確的問題。如下圖5-23所示，瀏覽器會卡在7/div[@id='grid']/ol/li[2]/a/span"S 一步上，原因是定位問題。

圖5-23 Selenium測試示例截圖

Selenium還可以釆用Java、C#和Python等多種語言輸入，其示例圖如圖

5-23所示，這種用例輸入方式對測試人員的編程水平有較高要求。

圖5-24 Selenium Java測試用例生成圖

通過測試用例的生成可以體現，本系統在測試用例的輸入上對信息管理軟件進行了改進。同時Selenium是基于瀏覽器的插件測試，其性能瓶頸非常受限于測試主機的單機性能，而本系統采用SaaS模式，性能的可擴展性較好。說明了本系統的創新性和可行性。

第六章總結與展望

本章對本課題完成的工作進行總結，同時對存在的問題和未來的展望也進行總結。

6.1主要工作總結

信息管理軟件是當下企業中經常使用的軟件之一，對于云服務開發商來說在軟件的開發測試直接決定了軟件的服務質量。隨著信息管理軟件逐漸應用 SaaS模式，針對其的自動化測試系統也在逐漸采用SaaS模式。本課題基于商用企業對于SaaS模式信息管理軟件的測試需求出發，調研了相關論文和開源框架后，設計并實現了 SaaS模式的信息管理軟件自動化測試系統，并結合在某商用IT公司的SaaS平臺，測試完成并投入使用。

本文首先分析了本課題的研究背景和研究現狀來說明本課題存在可研究的空間，并介紹了課題的研究內容及行文結構。然后本文對課題涉及到的相關技術理論進行了額介紹，接著對信息管理軟件和自動化測試發展做了闡述。在這基礎上，進行需求分析，并涉及了 SaaS模式的信息管理軟件自動化測試系統的架構和具體功能模塊。最后在某商用SaaS平臺上了進行了開發實現，并展示了效果。

本課題的主要研究成果如下所示：

第一，設計并實現SaaS模式的信息管理軟件自動化測試系統架構。本課題基于SaaS模式的特點，分析信息管理軟件的特征，結合自動化測試系統的目的，設計并實現了系統的整體架構以及其七個組件包括租戶用戶管理模塊、測試用例創建模塊、測試模板模塊、測試執行模塊、測試方案模塊、測試報告模塊以及響應式前端組件。

第二，分析信息管理軟件，抽象出三類信息管理軟件測試用例模板。本課題基于分析市面上常見的信息管理軟件輸入輸出特點，抽象出包含登錄測試、搜索測試和鏈接測試在內的三類模板，從而加快測試用例的創建速度。

第三，實現響應式前端設計。根據商用SaaS模式測試的實際需求，滿足測試人員移動辦公的可能性，本系統的全部前端頁面采用開源Bootstrap開源框架，實現系統界面可以根據不同的終端設備屏幕尺寸和分辨率自適應調整。

6.2問題與展望本課題設計并實現的SaaS模式信息管理軟件自動化測試系統應用在了實際的商用SaaS平臺上，驗證了其可行性。但是在實際的使用過程中，不可避免遇到了一些問題，非常值得進一步探討，作為下一步的研究方向。

第一，多租戶數據安全：SaaS模式的系統特點使用戶數據安全是一個重要問題。本系統的數據分離是使用的同庫同表，根據字段進行分離。下一步的研究思路是通過動態多數據源配置，徹底從數據庫層面分離租戶間數據，徹底保證數據隔離。此外，在數據加密上的安全性和加密后的系統性能損失，也是數據安全的研究方向。

第二，系統性能優化。由于本系統的研發環境是某商用的SaaS平臺，其用戶量是有限的。隨著使用客戶量逐漸增加，系統的下一步改進方向是對架構的性能優化，以及負載均衡等方向。

參考文獻

[1]Cusumano, Michael. Cloud computing and SaaS as new computing platforms [J]. Communications of the Acm? 2010, 53(4):27-29.

[2]Linthicum D S. A Guide to Cloud-Enabling Your Software[J]. IEEE Cloud Computing, 2016,3(2):20-23.

[3]Tang C, Liu J. Selecting a trusted cloud service provider for your SaaS programlJ]. Computers & Security, 2015, 50(C):60-73.

[4]Xin S, Guo Q, Wang J, et al. Information Masking Theory for Data Protection in Future Cloud-based Energy Management^]. IEEE Transactions on Smart Grid, 2017, PP(99):1-1.

[5]李揚.基建項目管理信息系統的設計與實現[D]?南開大學,2015.

[6卩ones S. Cloud computing procurement and implementation[J]. International Journal of Information Management, 2015, 35(6):712-716.

[7]Hariguna T, Lai M T? Chen S C. An Empirical Study on the Impact of Information System Quality on Software as a Service[J]. Global Business & Management Research, 2016.

[8]蘇麗裕.網盤自動化測試系統的設計與實現[D]?北京郵電大學,2015.

[9]Hansbauer G. Auton^ited testing in the cloud: Test infrastructure management with SaaS[C]// IEEE Eighth International Conference on Software Testing. Verification and Validation Workshops. IEEE, 2015:1-3.

[10]Chaves D S A, Correa L R, Vieira Dias LA, et al. A Case Study Using Testing Technique for Software as a Service (SaaS)[C]// International Conference on Information Technology - New Generations. IEEE, 2015:761-762.

[1 l]Groce A, Havelxmd K, Smith M. From scripts to specifications: the evolution of a flight software testing efifort[J]. Engineering Geology, 2015, 193(10):118-131 ?

[12]Program Chair-Budnik C, Program Chair-Fraser G, Program Chair-Lonetti F. Proceedings of the 11th International Workshop on Automation of Software Test[C]// International Workshop on Automation of Software Test. ACM, 2016.

[13]Zhu H? A Formal Interpretation of Software Testing as Inductive Inference [J]. Software Testing Verification & Reliability, 2015, 6(1):3-31.

[14]Spinellis D. State-of-the-Art Software Testing[J]. IEEE Software, 2017, 34(5):4- 6.

[15]Krishnaveni S, Prabakaran S, Sivamohan S. Automated Vulnerability Detection and Prediction by Security Testing for Cloud SAAS[J]. Indian Journal of Science & Technology, 2016, 9(S1).

[16]Siddiqui T, Ahmad R. A review on software testing approaches for cloud applications ☆[•!]. Perspectives in Science, 2016, 8(C):689-691.

[17]高獅.基于云計算和CDN的軟件自動化測試系統[D].復旦大學,2014.

[18]陳曄，張立華.大話APP測試2.0:移動互聯網產品測試實錄[M].清華大學出版社,2016.

[19]歐潔.基于QTP的軟件自動化測試框架的設計及應用[D].中國科學院大學，

2014.

[20]李玉，尉雙梅，汪添生，等.基于QTP的企業級應用軟件自動化測試方法卩]. 計算機系統應用,2016, 25(6):219-224.

[21]劉超凡.面向SaaS平臺的快速部署系統的設計與實現[D].北京郵電大學,

2015.

[22]Rachana Desale, Purva Kolhatkar, Anju More, Piyush Katira, Vishal Kokane Prof.S.M. Jaybhaye.Software as a Service (SaaS) for Management information system using multiple tenants[J] .International Journal of Engineering Research and Applications,2013,3(3).

[23]張峰.云計算應用服務模式探討[J].信息技術與信息化,2012,(2):81- 83.DOI: 10.3969/j .issn. 1672-9528.2012.02.21.

[24]田淵.系統管理SaaS服務平臺的設計與實現[D].北京大學,2012.

[25]胡遵華，范冰冰，胡遵程.一種基于云的SaaS分布式多租戶數據庫研究卩]. 計算機應用與軟件,2015(9):59-61.

[26]林闖，蘇文博，盂坤，等.云計算安全:架構、機制與模型評價卩].計算機學報, 2013,36(9):1765-1784.

[27]王磊.開放式網絡實驗平臺管理系統的設計與實現[D].北京郵電大學,2015.

[28]Ferraiolo D, Kuhn R, Sandhu R. RBAC Standard Rationale: Comments on "A Critique of the ANSI Standard on Role-Based Access Control "[J], IEEE Security & Privacy, 2015, 5(6):51-53.

[29]Makki M, Landuyt D V, Joosen W. Automated workflow regression testing for multi-tenant SaaS: integrated support in self-service configuration dashboard[C]// International Workshop on Automating Test Case Design, Selection, and Evaluation. ACM, 2016:70-73.

[30]Bohme M, Paul S. A Probabilistic Analysis of the Efficiency of Automated Software Testing[J]? IEEE Transactions on Software Engineering, 2016,42(4):345- 360.

卩1］鄧璐娟，李金萌，董東曉.自動化測試框架技術及應用［J］.計算機測量與控制，2016,24(9):86-88.

［32］姬婷.基于物聯網網頁控制平臺的自動化測試系統研究與設計［D］.北京郵電大學.2014.

［33］牛昊媛.面向SaaS產品的自動化測試系統的設計與實現［D］.哈爾濱工業大學,2010.

【本文地址：http://www.bzhlmm.com//guanlilei/gongshangguanli/xixinguanli/8980.html】

上一篇：購房信息管理系統的設計與實現

下一篇：沒有了

相關標簽:

最熱期刊