基于工作流的Web軟件測試技術(shù)研究與應(yīng)用

基于工作流的Web軟件測試技術(shù)研究與應(yīng)用目錄第一章緒論 21.1選題依據(jù)及研究意義 21.2國內(nèi)外研究現(xiàn)狀 21.3論文研究內(nèi)容 31.4論文篇章結(jié)構(gòu) 3第二章軟件測試技術(shù) 42.1軟件測試的作用和意義 42.2軟件測試的流程 42.3本章小結(jié) 5第三章工作流技術(shù) 63.1工作流的定義 63.2工作流框架的選擇 63.3工作流的建模 83.4本章小結(jié) 9第四章工作流技術(shù)在軟件測試中的實踐應(yīng)用 104.1需求分析 104.2基于工作流的模型設(shè)計 114.2.1易請假流程設(shè)計 114.2.2易報修流程設(shè)計 124.2.3外出報備流程設(shè)計 144.2.4易防疫流程設(shè)計 154.3測試流程設(shè)計 164.3.1性能測試工具選擇 164.3.2性能測試 164.3.3壓力測試 184.3.4自動化測試 214.4本章小結(jié) 23第五章總結(jié)與展望 245.1總結(jié) 245.2展望 24參考文獻 24致謝 26摘要：基于工作流的Web軟件測試技術(shù)主要是將工作流技術(shù)應(yīng)用到Web應(yīng)用系統(tǒng)的測試過程中，以提高測試效率，保證測試一致性，減輕測試人員的工作負擔(dān)。在Web應(yīng)用軟件的測試中，通過工作流技術(shù)對測試流程及各操作步驟之間的業(yè)務(wù)規(guī)則進行抽象和概括，基于協(xié)同工作的方式來實現(xiàn)測試業(yè)務(wù)和流程的自動化，提高測試用例、測試腳本、測試數(shù)據(jù)的使用效率。具體內(nèi)容包括：對Web系統(tǒng)基于BPMN（BusinessProcessModelAndNotation）建立工作流模型，研究測試流程及方法，比如進行相關(guān)的功能測試、性能測試、自動化測試等，并對比選取合適的工具，結(jié)合工作流模型設(shè)計測試方案并進行實現(xiàn)。關(guān)鍵詞:軟件測試；工作流；Web第一章緒論1.1選題依據(jù)及研究意義隨著軟件的復(fù)雜性和規(guī)模的不斷增大，人們對軟件質(zhì)量的要求也越來越高，測試需求增大，軟件測試技術(shù)逐漸成為人們關(guān)注的焦點。同時，互聯(lián)網(wǎng)的普及使Web軟件快速發(fā)展，用戶對其質(zhì)量的要求也越來越高。工作流技術(shù)是一種有效的管理和協(xié)調(diào)工作流程的方法，可以提高軟件測試的效率和質(zhì)量?；诠ぷ髁鞯腤eb軟件測試技術(shù)研究與應(yīng)用，可以有效地將工作流技術(shù)和軟件測試技術(shù)相結(jié)合，提高軟件測試的效率和質(zhì)量。在Web軟件測試中，工作流技術(shù)的應(yīng)用可以幫助測試人員更好的管理測試流程、自動化測試用例、測試報告生成、提高測試覆蓋率等。通過工作流技術(shù)有助于發(fā)現(xiàn)Web軟件中的錯誤和缺陷，從而提高軟件的質(zhì)量和可靠性。在Web軟件中使用BPMN業(yè)務(wù)流程模型和標(biāo)記法對測試流程進行實踐應(yīng)用。1.2國內(nèi)外研究現(xiàn)狀在現(xiàn)代軟件開發(fā)的過程中，軟件測試是一個不可或缺的環(huán)節(jié)，是保障軟件質(zhì)量的重要工作[1]。在國外一些成熟和大型的軟件企業(yè)中，軟件測試和軟件開發(fā)的人員比例已經(jīng)達到了3:5[2]。在軟件測試技術(shù)上，國外有著大量的測試工具，比如MercuryInteractive公司在WinRunner[3][4]測試工具針對黑盒測試可檢測系統(tǒng)功能是否正常運行。開源的WebInject[5]測試工具可對Web服務(wù)進行測試并產(chǎn)生測試報告。上海澤眾軟件公司AutoRunner[12]測試工具可對Web和windows應(yīng)用進行測試。TaobaoMobileTestSystem測試框架可對網(wǎng)頁進行測試，MobileTestingCenter框架可進行性能測試[13]。然而，在軟件測試過程中，依然存在一些問題，例如提測時間不足、引入新的功能可能影響原有的功能，所以需要進行集成測試和版本回歸測試。同時，也可能會出現(xiàn)用例遺漏，測試覆蓋率不足等問題。工作流技術(shù)起源于20世紀70年代中期辦公自動化領(lǐng)域的研究，1993年8月，第一個工作流技術(shù)標(biāo)準(zhǔn)化的工業(yè)組織——工作流管理聯(lián)盟（WorkflowManagementCoalition，簡稱WFMC）成立[11]。隨著工作流技術(shù)的不斷發(fā)展，逐漸產(chǎn)生了兩種工作流分支，包括科學(xué)型工作流和業(yè)務(wù)型工作流。比較熱門的業(yè)務(wù)型工作流系統(tǒng)包括Osworkflow、jbpmn和activiti[6]。工作流技術(shù)由于能對流程可視化、處理復(fù)雜業(yè)務(wù)流程等特點，在軟件測試的過程、資源和缺陷管理中應(yīng)用廣泛。工作流可解決在多個參與者之間利用計算機按某種預(yù)定規(guī)則實現(xiàn)自動傳遞文檔、信息或任務(wù)，以達到任務(wù)目標(biāo)，可實現(xiàn)部分業(yè)務(wù)過程在計算機支持下的全自動或半自動化[8]。測試負責(zé)人通過工作流引擎進行任務(wù)分配，測試人員依據(jù)分配的任務(wù)進行測試策劃、測試設(shè)計、測試執(zhí)行并對測試過程中產(chǎn)生的缺陷進行跟蹤。在軟件測試過程中引入工作流技術(shù)是當(dāng)前研究的一個熱點，工作流的定義和重要性得到了廣泛的認可。1.3論文研究內(nèi)容本文通過研究軟件測試的作用、意義、流程，以及工作流技術(shù)的定義、框架、建模，在性能、壓力、自動化測試中，基于工作流和軟件測試結(jié)合的方法來提升Web軟件在測試過程中的效率和質(zhì)量，并通過易班學(xué)生服務(wù)平臺進行了相關(guān)實踐，取得了良好的進展。1.4論文篇章結(jié)構(gòu)第一章為研究內(nèi)容的背景介紹，包括選題、意義、目前及國內(nèi)外的研究現(xiàn)狀。第二章為軟件測試技術(shù)的研究，主要研究軟件測試的作用、意義、并結(jié)合Web系統(tǒng)研究了軟件需求分析、編寫測試計劃、設(shè)計測試用例、測試執(zhí)行、缺陷管理、回歸測試、編寫測試報告等軟件測試流程。第三章為工作流技術(shù)的研究，主要研究工作流的概念、工作流框架的選擇以及BPMN模型。第四章為研究工作流在Web軟件中的建模過程，以易班學(xué)生服務(wù)平臺為例，基于工作流技術(shù)對其進行性能、壓力、自動化測試。第五章為論文總結(jié)和對未來的展望。第二章軟件測試技術(shù)2.1軟件測試的作用和意義軟件測試的主要作用是保證軟件的質(zhì)量和性能，以及滿足用戶的需求。通過測試，可以發(fā)現(xiàn)并修復(fù)軟件中存在的缺陷，從而提高軟件的穩(wěn)定性和可用性。軟件測試可以幫助開發(fā)人員識別和修復(fù)問題，減少因問題導(dǎo)致的返工和維護成本。此外，盡早的發(fā)現(xiàn)和解決問題可以使軟件快速上線，降低開發(fā)成本。同時，軟件測試在業(yè)務(wù)風(fēng)險、界面優(yōu)化、改善用戶體驗等方面也具有一席之地。軟件測試是軟件開發(fā)過程中的重要組成部分，在保證軟件質(zhì)量和提高用戶滿意度方面起著至關(guān)重要的作用。2.2軟件測試的流程結(jié)合Web軟件的特點，可以將其測試過程按如下流程劃分：首先，對Web系統(tǒng)進行需求分析，確定測試的對象、工作范圍和測試的重點，包括軟件需求、概要設(shè)計、詳細設(shè)計等。在業(yè)務(wù)功能的完整性和性能指標(biāo)、兼容等方面需重點關(guān)注。測試計劃通常由測試主管或者高級測試工程師編寫，它規(guī)定了測試的目標(biāo)、策略、方法和資源等。Web系統(tǒng)的測試目標(biāo)主要包括提高軟件的質(zhì)量、保證軟件的安全、提升用戶體驗等，常用策略包括明確產(chǎn)品目標(biāo)、風(fēng)險分析、評估質(zhì)量等。在測試方法上，主要有白盒、黑盒、靜態(tài)以及動態(tài)測試。測試人員根據(jù)需求文檔和測試計劃來設(shè)計測試用例并執(zhí)行，如果出現(xiàn)的結(jié)果與預(yù)期結(jié)果不符，則在缺陷管理工具上提交bug單，同時反饋給相關(guān)的開發(fā)人員進行修復(fù)。在缺陷被修復(fù)后，測試人員需要重新進行測試以確保修復(fù)，驗證通過后關(guān)閉bug單。在進行完一輪測試后，可能會出現(xiàn)新的問題或者舊的問題再次出現(xiàn)，這時就需要進行回歸測試，確保之前的功能沒有受到影響。測試結(jié)束后，測試人員編寫測試報告，總結(jié)測試結(jié)果，包括哪些功能正常，哪些功能存在問題，以及如何改進等。2.3本章小結(jié)本章主要介紹軟件測試的作用和意義，并結(jié)合Web系統(tǒng)研究了軟件需求分析、編寫測試計劃、設(shè)計測試用例、測試執(zhí)行、缺陷管理、回歸測試、編寫測試報告等軟件測試流程，明確測試方法和路線。第三章工作流技術(shù)3.1工作流的定義工作流是一種計算機支持的協(xié)同工作的模型，用于描述工作流程及其各操作步驟之間業(yè)務(wù)規(guī)則的抽象和概括。工作流可解決在多個參與者之間利用計算機按某種預(yù)定規(guī)則實現(xiàn)自動傳遞文檔、信息或任務(wù)，以達到任務(wù)目標(biāo)，可實現(xiàn)部分業(yè)務(wù)過程在計算機支持下的全自動或半自動化[8]。通過將工作分解成定義良好的任務(wù)或角色，按照一定的規(guī)則和過程來執(zhí)行這些任務(wù)并對其進行監(jiān)控，達到提高工作效率、更好的控制過程、增強對客戶的服務(wù)、有效管理業(yè)務(wù)流程等目的。工作流本身就是一個工程設(shè)計思路，在具體場景下，它也是一種實現(xiàn)業(yè)務(wù)的方式。首先，工作流是一種設(shè)計模式，也可以理解成一種思維方式。其次，它不涉及任何具體的編碼，所有的業(yè)務(wù)代碼仍然需要手動完成，而只是使用工作流來規(guī)劃和編排代碼的運行方式。工作流主要解決多個參與者按照某種已經(jīng)規(guī)劃好的規(guī)則來實現(xiàn)自動傳遞信息或任務(wù)，整個過程定義了任務(wù)的順序和觸發(fā)的條件，可以由一個或多個軟件、一個或多個與軟件系統(tǒng)協(xié)作完成。拿垂直服務(wù)舉例，審批就是通過工作流引擎直接實現(xiàn)業(yè)務(wù)。工作流的應(yīng)用場景也相當(dāng)廣泛，在行政管理、人事管理、客戶管理、財務(wù)等方面均有涉及。3.2工作流框架的選擇目前市面上主流的基于Java語言的開源工作流框架主要有jBPM、Activiti、Flowable、Camunda等。jBPM不支持擴展節(jié)點，功能較少，接口難以滿足日常工作的需要。Activiti同樣不支持擴展節(jié)點，維護不及時，功能缺少，但其優(yōu)點是社區(qū)用戶多，遇到問題容易找到解決方案，且支持SpringCloud。Flowable支持擴展節(jié)點，功能完善，性能穩(wěn)定性很好，但其缺點是開源版維護不及時、部分功能閉源、僅支持從開始節(jié)點運轉(zhuǎn)實例。Camunda基于activiti5，壓力測試驗證了CamundaBPMN引擎性能更好且穩(wěn)定。除了BPMN，Camunda還支持CMMN（案例管理）和DMN（決策自動化）。Camunda不僅配備了引擎，還配備了非常強大的建模、任務(wù)管理、操作監(jiān)控和用戶管理工具。結(jié)合其提供獨立的Modeler設(shè)計器、優(yōu)秀的用戶體驗以及出色的表單管理能力，選擇Camunda作為建?？蚣?。3.3工作流的建?；贑amunda框架，對Web系統(tǒng)進行建模的設(shè)計如下圖：工作流的建模主要有任務(wù)（Task）、參與者（Participant）、子流程（Subprocess）、門路（Gateway）、事件（Event）、會簽、或簽以及表單（form）。其中任務(wù)又分為發(fā)送任務(wù)（sendtask）、接收任務(wù)（receivetask）、用戶任務(wù)（usertask）、手動任務(wù)（manualtask）、業(yè)務(wù)規(guī)則任務(wù)（businessruletask）、服務(wù)任務(wù)（servicetask）以及腳本任務(wù)（scripttask）。發(fā)送任務(wù)指向外部Participant發(fā)送消息，接收任務(wù)即等待外部Participant消息，一旦接收到外部消息該任務(wù)就標(biāo)記為完成狀態(tài)。用戶任務(wù)和手動任務(wù)均需要人工操作，不同的是用戶任務(wù)需要指定執(zhí)行的用戶或角色，并提供相應(yīng)的輸入（表單），才能繼續(xù)執(zhí)行，而手動任務(wù)完成與否不影響流程引擎的繼續(xù)。業(yè)務(wù)規(guī)則任務(wù)用DMN決策模型標(biāo)記，服務(wù)任務(wù)通過Web服務(wù)來自動完成，腳本任務(wù)則是通過引擎可識別的腳本語言來進行自動化操作。參與者又分泳道（Lane）、泳池（Pool）和泳道圖（SwimlaneDiagram）。泳道是由相同的角色執(zhí)行的任務(wù)放在一起。而泳池則是組合模式，多名角色和任務(wù)共同完成，由泳道組合而成泳池。泳道圖展示同一任務(wù)流程上的不同進程，明確各個環(huán)節(jié)。子流程分為嵌套子流程（EmbeddedSubprocess）和事件子流程（EventSubprocess）。子流程由父流程調(diào)用，事件觸發(fā)后才能調(diào)用事件子流程。門路包含排它門路（Exclusive(XOR)）、并行門路（Parallel(AND)）、包含門路（Inclusive(OR)）和事件門路（Event-based）。其中排它門路和包含門路可以設(shè)置判斷條件，并行門路和事件門路不可設(shè)置判斷條件。排他門路用于多選一，并行門路用于多條路徑共同執(zhí)行，包含門路用于執(zhí)行部分路徑，事件門路用于由事件觸發(fā)執(zhí)行路徑。事件有開始事件（StartEvent）、結(jié)束事件（EndEvent）、中間事件（IntermediateEvent）、消息事件（MessageEvent)、定時事件（TimerEvent)、信號事件（SignalEvent）以及條件事件（ConditionalEvent）。開始事件和結(jié)束事件在項目部署里必須定義，中間事件為拋出事件，消息事件可以出現(xiàn)在流程的任何位置。定時事件可用作開始事件、中間事件、邊界事件，同時作為邊界事件支持中斷和非中斷。信號事件通過廣播通知所有關(guān)注此事件的流程。相關(guān)變量滿足條件時，條件事件觸發(fā)。會簽指多人需要全部審批通過后才能進入下一節(jié)點，或簽則是雖然有多人負責(zé)審批，但只要其中一人同意即可。表單可以嵌入到用戶任務(wù)中，后續(xù)可以在審批中填入相應(yīng)數(shù)據(jù)以流轉(zhuǎn)到相應(yīng)節(jié)點，它又分為外置表單和內(nèi)置表單。外置表單是自己創(chuàng)建表單生成HTML文件，然后讓用戶任務(wù)引用，內(nèi)置表單則是Camunda自己提供的數(shù)字、日期、文本、多選、下拉、單選、圖片、iFrame、按鈕等，并可以轉(zhuǎn)換為JSON格式數(shù)據(jù)。3.4本章小結(jié)本章介紹了工作流的定義、框架以及建模，分析了jBPM、Activiti、Flowable、Camunda等工作流框架，基于其特點及優(yōu)勢，選擇了Camunda框架作為研究對象，并按照標(biāo)準(zhǔn)化、可視化的原則，貫徹每個步驟都有明確任務(wù)和責(zé)任人的思想，對Web系統(tǒng)進行分析，設(shè)計并實現(xiàn)了針對Web系統(tǒng)的BPMN模型。第四章工作流技術(shù)在軟件測試中的實踐應(yīng)用4.1需求分析易班學(xué)生服務(wù)平臺是一款為教育量身定制的開放型智能應(yīng)用，是高校教育教學(xué)、生活服務(wù)、文化娛樂的綜合性互動社區(qū)。<dependencies>

<dependency>

<groupId>org.camunda.bpm</groupId>

<dependencies>

<dependency>

<groupId>org.camunda.bpm</groupId>

<artifactId>camunda-external-task-client</artifactId>

<version>${camunda.external-task-client.version}</version>

</dependency>

<dependency>

<groupId>org.slf4j</groupId>

<artifactId>slf4j-simple</artifactId>

<version>1.7.36</version>

</dependency>

<dependency>

<groupId>javax.xml.bind</groupId>

<artifactId>jaxb-api</artifactId>

<version>2.3.1</version>

</dependency>

</dependencies>

ExternalTaskClientclient=ExternalTaskClient.create()

.baseUrl("http://localhost:8080/engine-rest")

ExternalTaskClientclient=ExternalTaskClient.create()

.baseUrl("http://localhost:8080/engine-rest")

.asyncResponseTimeout(10000)

.build();

4.2基于工作流的模型設(shè)計4.2.1易請假流程設(shè)計首先學(xué)生在易班發(fā)起請假流程，填寫相應(yīng)信息并提交后進入輔導(dǎo)員請假審批。設(shè)置userName學(xué)生姓名，studentNum學(xué)生學(xué)號，leave請假去向，和approved是否通過。如圖1易請假流程圖所示。圖1易請假流程圖部署成功后，填寫姓名、學(xué)號、請假去向，如圖2請假信息圖。進入CamundaCockpit查看，流程進行到人工審批，如圖3請假審批圖。圖2請假信息圖圖3請假審批圖4.2.2易報修流程設(shè)計學(xué)生在易班發(fā)起報修，通過DMN設(shè)置分類為水電時自動審批通過，派人維修，修理好后結(jié)束報修，實現(xiàn)流程自動化。非水電類的報修進入人工審批，設(shè)置userName學(xué)生姓名，phone電話號碼，address地址，type分類，approved是否通過，審批通過后派人維修，不通過則退單。如圖4易報修流程圖。圖4易報修流程圖報修審批決策中設(shè)置分類為水電時，為true自動執(zhí)行。如圖5報修審批決策圖。圖5報修審批決策圖可以看到分類為水電時，網(wǎng)關(guān)通過，進入下一步。如圖6報修信息-水電圖，圖7報修審批-維修圖。圖6報修信息-水電圖圖7報修審批-維修圖分類不為水電時，執(zhí)行人工審核。如圖8報修信息-非水電圖，圖9報修審批-審核圖。圖8報修信息-非水電圖圖9報修審批-審核圖4.2.3外出報備流程設(shè)計學(xué)生在易班發(fā)起外出報備，設(shè)置time時間，phone電話，address目的地，approved是否通過，進入輔導(dǎo)員審批。學(xué)生憑通過信息外出，拒絕外出時學(xué)生不可出校。如圖10外出報備流程圖。圖10外出報備流程圖可以看到進入審批流程。如圖11外出報備信息圖，圖12外出報備審批圖。圖11外出報備信息圖圖12外出報備審批圖4.2.4易防疫流程設(shè)計學(xué)生登錄易班點擊易防疫，進入健康打卡頁面，在設(shè)計流程時，設(shè)置填寫體溫為服務(wù)任務(wù)，無需工作人員操作。學(xué)生填寫體溫后提交，彈出提示框，顯示打卡成功，流程結(jié)束。如圖13易防疫流程圖。圖13易防疫流程圖4.3測試流程設(shè)計4.3.1性能測試工具選擇選擇性能測試工具時，需要考慮其并發(fā)能力、資源監(jiān)控、是否開源、是否支持錄制、是否支持分布式、社區(qū)活躍度、是否便于腳本維護、易用性、可擴展性、壓測平臺編碼量等。根據(jù)以上因素，對常用的測試工具分析如下：LoadRunner：這是一款商業(yè)級性能測試工具，適用于各種體系架構(gòu)，不僅能預(yù)測行為還能進行優(yōu)化。支持多種協(xié)議，為系統(tǒng)負載打造真實環(huán)境。但其收費貴，操作較繁瑣，不容易上手。Gatling：這是一款開源的性能測試工具，基于Scala語言開發(fā)，但其本身只支持HTTP，其他協(xié)議需要擴展。KylinTOP：這是一款國產(chǎn)基于AI軟件自動化的測試工具，在性能、壓力、可靠性測試上都有不俗的表現(xiàn)，并且可對接口、UI、APP進行監(jiān)控。但其用例維護成本高，版本迭代快，對人員能力要求至少掌握一門腳本語言。JMeter：這是一款開源的性能測試工具，它同樣支持多種協(xié)議，并且具有良好的可擴展性和靈活性。JMeter的社區(qū)非?；钴S，可以很容易地找到教程和解決問題的方法。經(jīng)過對比，JMeter在基于工作流的測試中具有多協(xié)議支持、強大的并發(fā)測試能力、豐富的測試結(jié)果展示、高度的可擴展性等優(yōu)勢，本文選用JMeter工具做性能測試和壓力測試。4.3.2性能測試JMeter的工作原理是在工具內(nèi)設(shè)置線程，即用戶操作，與被測系統(tǒng)服務(wù)端通過HTTP接口互相連接，最終結(jié)果展示在界面控制臺。以易請假線程組為例，錄制從登錄到首頁，再從首頁進入易請假頁面，點擊普通請假或離校請假，執(zhí)行并查看結(jié)果樹，可以看到請求發(fā)送成功。圖14性能測試圖如圖14性能測試圖，每條HTTP請求的取樣器結(jié)果都有很多數(shù)值信息，主要關(guān)注點如下：ConnectTime：JMeter和被測系統(tǒng)建立TCP連接的時間，包括3路握手時間，如果連接復(fù)用，值為0。lantency：從發(fā)出請求前到接收完第一個響應(yīng)的時間。loadtime：從發(fā)出請求前到接收完所有響應(yīng)的時間，如果是長消息，往往時長>=lantency，因為有多個響應(yīng)。Headerssizeinbytes:響應(yīng)消息頭大小。Bodysizeinbytes：響應(yīng)消息體大小。Sizeinbytes：整個消息大小=Headerssizeinbytes+Bodysizeinbytes。4.3.3壓力測試JMeter做壓力測試，以易防疫的健康打卡為例，線程數(shù)設(shè)置240個，即用戶的數(shù)量。Ramp-Up時間設(shè)置120秒，一秒鐘兩個用戶，運行兩分鐘。如圖15壓力測試圖。圖15壓力測試圖用命令生成測試報告并查看，可以看到HTTP請求發(fā)送成功。如圖16應(yīng)用程序性能指標(biāo)圖。Apdex：應(yīng)用程序性能指標(biāo)（0~1），1表示所有用戶請求均滿意，反之0則表示均不滿意。Tolerationthreshold：可接受（容忍或滿意）閾值，即用戶可接受的響應(yīng)時間。Frustrationthreshold：不可接受（失?。╅撝?，即用戶不可接受響應(yīng)時間。Laber：采樣器名稱。圖16應(yīng)用程序性能指標(biāo)圖Label：Sample采樣器名稱。Samples：總共發(fā)送請求數(shù)(線程數(shù)*循環(huán)次數(shù))。FALL：失敗次數(shù)。Error%：請求失敗率。Average：平均響應(yīng)時間。Min：最小響應(yīng)時間。Max：最大響應(yīng)時間。90%Line：90%線，90%用戶響應(yīng)不超過該時間。95%Line：95%線，95%用戶響應(yīng)不超過該時間。99%Line：99%線，99%用戶響應(yīng)不超過該時間。Throughput：吞吐量，一般情況下可看做每秒完成請求數(shù)(和QPS類似)。Received：每秒從服務(wù)器端接收到的數(shù)據(jù)量。Sent：每秒從客戶端發(fā)送的請求的數(shù)量。其中Average平均響應(yīng)時間是需要重點關(guān)注的一項指標(biāo)，如圖17statistics圖，百分之九十用戶響應(yīng)時間不超過三百五十毫秒，百分之九十九用戶響應(yīng)時間不超過一千五百毫秒。其中，api（數(shù)據(jù)庫）平均響應(yīng)時間較長，希望改進。圖17statistics圖ResponseTimesOverTime，即響應(yīng)時間隨時間變化趨勢。由于應(yīng)用需要初始化建立連接以及CPU、內(nèi)存等分配都會消耗資源，隨著系統(tǒng)趨于穩(wěn)定，響應(yīng)時間也會趨于穩(wěn)定。如圖18響應(yīng)時間曲線圖。圖18響應(yīng)時間曲線圖ActiveThreadsOverTime，即活動線程時間變化曲線圖，隨著時間變化，每個時間節(jié)點上的活動線程數(shù)。其變化趨勢即并發(fā)用戶數(shù)趨勢，相當(dāng)于我們模擬的并發(fā)用戶發(fā)出請求隨著時間變化的趨勢。如圖19活動線程曲線圖，可以看出設(shè)置的240個總線程數(shù)和120秒顯示在這段時間內(nèi)平均穩(wěn)定在20個用戶。圖19活動線程曲線圖ResponseTimePercentiles，即響應(yīng)時間百分比，通過壓測數(shù)據(jù)中所有響應(yīng)時間統(tǒng)計分析所展示。如圖20響應(yīng)時間百分比圖，登錄的上坡趨勢明顯，不太穩(wěn)定。圖20響應(yīng)時間百分比圖4.3.4自動化測試自動化測試是指利用工具模擬人為操作，自動執(zhí)行測試用例，并生成測試結(jié)果的過程。這是一種高效的測試方法，幫助測試人員快速發(fā)現(xiàn)軟件中的缺陷。它的主要目標(biāo)是提高測試的效率，減少傳統(tǒng)測試的成本和時間。自動化測試多應(yīng)用于重復(fù)耗時、覆蓋面廣、需要快速反饋等情況，在集成和接口中也應(yīng)用廣泛。好處是它們可以提高測試效率，降低成本，并允許測試人員專注于更具挑戰(zhàn)性和創(chuàng)造性的測試。例如，對于大量的API測試，自動化測試可以解放開發(fā)人員的雙手，大大提高測試效率。driver=webdriver.Firefox()

driver.get('https://yiban.turbosnail.cc/notice/frontend/web/student_login.html')

#最大化瀏覽器窗口

driver=webdriver.Firefox()

driver.get('https://yiban.turbosnail.cc/notice/frontend/web/student_login.html')

#最大化瀏覽器窗口

driver.maximize_window()

#學(xué)號

driver.find_element(By.ID,'studentNum').send_keys('2022022037')

#姓名

driver.find_element(By.ID,'userName').send_keys('劉星雨')

#學(xué)院

collegeSelect=Select(driver.find_element(By.ID,'collegeSelect'))

collegeSelect.select_by_value('網(wǎng)絡(luò)工程學(xué)院')

#班級

classSelect=Select(driver.find_element(By.ID,'classSelect'))

classSelect.select_by_value('22科學(xué)與技術(shù)1（專升本）')

#確認登錄

driver.find_element(By.ID,'submitBtn').click()效果如下：右擊該視頻，點擊對象-顯示，播放結(jié)束后，點擊左下角結(jié)束放映或按兩次esc鍵。#滾動頁面

#滾動頁面

time.sleep(1)

driver.execute_script('window.scrollTo(0,document.body.scrollHeight);')

#點擊報修

baoxiu=driver.find_element(By.XPATH,'/html/body/div[7]/a[2]/div/div/p[1]')

baoxiu.click()

time.sleep(1)

#添加

driver.find_element(By.XPATH,'/html/body/a/i').click()

time.sleep(1)

#返回

driver.find_element(By.XPATH,'/html/body/header/div/a/i').click()

time.sleep(1)

#返回主界面

driver.find_element(By.XPATH,'/html/body/header/div/a/i').click()4.4本章小結(jié)本章內(nèi)容主要圍繞工作流與軟件測試結(jié)合，并對被測系統(tǒng)進行JMeter性能測試分析、壓力測試、Python+Selenium框架實現(xiàn)自動化測試。在軟件測試中應(yīng)用工作流技術(shù)明顯提升了效率和質(zhì)量。在性能方面，被測系統(tǒng)的api（數(shù)據(jù)庫）平均響應(yīng)較長，仍需要進行優(yōu)化。在壓測方面，多并發(fā)數(shù)據(jù)一旦過大會直接壓崩，穩(wěn)定性需要提高。在自動化測試方面，部分功能加載時間較長，影響用戶體驗，后續(xù)開發(fā)人員仍需要進行完善。第五章總結(jié)與展望5.1總結(jié)通過研究主流的開源工作流引擎和軟件測試技術(shù)，選取了Camunda作為本文的工作流框架對Web軟件進行建模，選用JMeter工具對被測系統(tǒng)進行性能測試分析和壓力測試，結(jié)合工作流技術(shù)進行系統(tǒng)化的軟件測試，可以有效提升測試過程的效率和質(zhì)量。通過對易班學(xué)生服務(wù)平臺的測試，將工作流技術(shù)應(yīng)用到軟件測試中，達到了更加高效檢測缺陷的預(yù)期效果，流程可視化的特點使整個測試流程清晰明了，工作流與軟件測試結(jié)合提高了測試的效率。在本次研究過程中，也出現(xiàn)了一些小問題，比如對性能測試工