PAGEPAGEI軟件測試方法及應用分析摘要隨著計算機行業(yè)的快速發(fā)展、用戶要求的不斷提高和大數(shù)據(jù)等各種技術的不斷興起,軟件測試的領域受到了巨大的沖擊,系統(tǒng)也變得越來越復雜。如何在現(xiàn)階段數(shù)字經(jīng)濟新時代背景下面對軟件測試中所出現(xiàn)的問題,對軟件測試的產(chǎn)業(yè)發(fā)起了挑戰(zhàn),能促進軟件測試更好更快更全面地發(fā)展成為了我們應該重視的事情。本文分析了數(shù)字經(jīng)濟新時代背景下軟件測試發(fā)展面臨的困難和挑戰(zhàn)，并根據(jù)分析結果提出了一些測試意見和測試方法的改進，期望對軟件測試行業(yè)的發(fā)展能起到一定的作用。

SoftwaretestingmethodandapplicationanalysisAbstractAstherapiddevelopmentofthecomputerindustry,thecontinuousimprovementofuserrequirementsandtheriseofvarioustechnologiessuchasbigdata,thefieldofsoftwaretestinghasbeengreatlyimpactedandthesystemhasbecomemoreandmorecomplex.Howtofacetheproblemsinsoftwaretestingintheneweraofdigitaleconomyhaschallengedthesoftwaretestingindustry,andithasbecomesomethingweshouldpayattentiontotopromotethebetter,fasterandmorecomprehensivedevelopmentofsoftwaretesting.Thispaperanalyzesthedifficultiesandchallengesfacingthedevelopmentofsoftwaretestingintheneweraofdigitaleconomy,andputsforwardsomeSuggestionsandimprovementsoftestingmethodsbasedontheanalysisresults,hopingtoplayacertainroleinthedevelopmentofsoftwaretestingindustry.

目錄軟件測試方法及應用分析 II1.概述 11.1軟件測試的定義 11.2.1測試的目的 11.2.2基本要求 11.2.3測試用例 12.軟件測試的方法 22.1軟件測試的基本方法 22.1.1黑盒測試 22.1.2白盒測試 22.1.3單元測試的基本方法 32.1.4恢復測試 52.5.2安全測試 52.5.3強度測試 52.5.4性能測試 53.軟件測試的誤區(qū) 63.1誤區(qū)之一 63.2誤區(qū)之二 63.3誤區(qū)之三 73.4誤區(qū)之四 73.5誤區(qū)之五 74.軟件測試的流程 84.1測試流程說明 84.1.1需求階段 84.1.2測試計劃階段 84.1.3.測試準備階段 94.1.4測試執(zhí)行階段 94.1.5.測試結果分析階段 94.1.6.上線準備階段 94.1.7.上線后測試跟蹤階段 104.1.8.項目總結階段 104.2需求梳理 104.2.1需求梳理 104.3測試計劃 114.3.1測試工具選取 114.3.2測試人員分配 124.3.3測試環(huán)境梳理 124.3.4測試數(shù)據(jù)梳理 124.4測試準備 124.4.1構建代碼管理 124.4.2測試環(huán)境搭建 124.4.3測試數(shù)據(jù)腳本編寫 134.5測試用例編寫(功能測試框架) 134.5.1界面友好性測試 144.5.2功能測試 154.5.3業(yè)務流程測試(主要功能測試) 164.5.5容錯測試 174.5.6穩(wěn)定性測試 174.5.7常規(guī)性能測試 174.5.8易用性測試 184.5.9兼容性測試 184.6

測試執(zhí)行 184.6.1接口自動化測試 184.6.3傳統(tǒng)測試用例測試 194.6.4Bug跟蹤 194.7

測試結果分析 204.7.1結果收集 204.7.2結果分析 204.7.3測試分析報告 204.8上線準備 204.8.1版本發(fā)布 204.8.2數(shù)據(jù)準備 214.9上線測試跟蹤 214.9.1跟蹤測試 215.項目性能工具測試 215.1用Jmeter進行接口和性能測試 215.1.1ApacheJMeter介紹 215.1.2ApacheJMeter能做什么？ 225.1.3性能測試目標 225.1.4Jmeter元件 225.1.5JMeterhttp接口腳本 245.2用LoadRunner進行性能測試 345.2.1測試步驟與展示 351. 結束語 542. 參考文獻 55PAGE2PAGE21.概述1.1軟件測試的定義軟件測試是軟件生存周期中重要的步驟，也是保證軟件質(zhì)量的重要步驟。簡言之，軟件測試是對軟件需求分析、設計標準和軟件發(fā)布前的最終的分析。1983年IEEE軟件工程術語提出的軟件測試的定義是與手動或自動手段“測試執(zhí)行或測量一個軟件系統(tǒng)的滿足預定的需求，設計成表現(xiàn)出預期的結果和實際結果之間的差異。這一定義明確指出軟件測試的目的是驗證軟件系統(tǒng)是否滿足要求。 從用戶的立場上看，他們希望通過軟件測試暴露程序中存在的問題，因此軟件測試應該是“為找出錯誤的程序執(zhí)行過程”。換言之，軟件進行測試應根據(jù)軟件系統(tǒng)設計發(fā)展階段的需求規(guī)格說明和程序的內(nèi)部管理架構，精確設計出各功能分析模塊的測試用例（即數(shù)據(jù)的預期的輸入、輸出結果），并利用我們這些測試用例運行工作程序，從而研究發(fā)現(xiàn)應用程序的錯誤或缺陷。1.2軟件測試的目的、原則、基本要求1.2.1測試的目的

1.檢驗軟件的實現(xiàn)是否符合用戶的預期需求。2.盡可能找出程序中存在的缺陷和錯誤。1.2.2基本要求1.對軟件體系中總體設計思路和詳細設計過程的了解。2.對整個軟件系統(tǒng)的數(shù)據(jù)流程要十分清晰。1.2.3測試用例由編寫的測試數(shù)據(jù)與預期結果的組合。在未執(zhí)行測試前，得根據(jù)設計文檔里的功能要求編寫測試數(shù)據(jù)和步驟，以及相應的預期結果。這也是用例編寫的基本準則和有效測試覆蓋測試場景的最好途徑之一。1.2.4測試原則1.根據(jù)需求設計文檔得出預期輸出結果。2.全面復查測試后結果，對測試bug進行歸類、認真詳細的分析。3.對于達不到預期的輸入輸出數(shù)據(jù)，也考慮進去，從而編寫測試用例。4.站在用戶的角度去驗證每個功能的模塊，不要總依賴開發(fā)人員的技術，也不要誤認為軟件中不可能出現(xiàn)bug。只要你認為不合理的事情，所以即使是輸出正確的，也應該對此提出質(zhì)疑。5.功能模塊測試后，剩余的bug數(shù)與提出bug數(shù)成比例。對于一個模塊中提出的bug數(shù)量越多，越需要對其進行嚴格和徹底的測試。6.保存測試用例。。2.軟件測試的方法2.1軟件測試的基本方法軟件測試的方法和技術有很多種。從軟件測試技術的角度看，軟件測試技術分為靜態(tài)和動態(tài)測試。從軟件業(yè)務結構和系統(tǒng)內(nèi)部算法結構的層面看，也總結為白盒測試和黑盒測試。2.1.1黑盒測試黑盒測試也叫功能測試或數(shù)據(jù)驅動的測試,是成型的并具有一定操作性的產(chǎn)品，其必須通過測試來驗證其功能,具體到每個功能模塊是否符合用戶要求和是否能正常使用。假如一個測試系統(tǒng),把它比喻成一個完全不能打開黑盒子,當中也不考慮其內(nèi)部結構與特性。在測試界面,只根據(jù)設計文檔和需求說明書驗證是否能正常使用？預期的輸入和輸出結果是否正確？黑盒測試方法主要分為以下幾類：等價類的劃分法、邊界值分析法、因果圖法、錯誤推測法等，其作用用于軟件功能驗證性測試。黑盒測試側重于系統(tǒng)的外部結構，從而不去考慮內(nèi)部邏輯結構，以及對軟件接口和功能的測試。黑盒測試是一種窮舉輸入的測試，它的目的是盡可能的覆蓋所有功能場景作為輸入測試情況時，從而發(fā)現(xiàn)程序中隱藏的問題。但實際上有無窮無盡的測試場景。在這種情況下，測試人員不單單要測試驗證所有正確合法的輸入條件，還要測試驗證那些無效類且不合法的輸入條件。2.1.2白盒測試白盒測試也稱為邏輯驅動測試。它了解產(chǎn)品的內(nèi)部工作過程，并且可以使用測試來檢測產(chǎn)品的內(nèi)部邏輯是否按照規(guī)范正常執(zhí)行。根據(jù)程序的內(nèi)部結構測試過程，檢查程序中的每個項目。每個通道是否可以根據(jù)預定要求正確地工作，而不論其功能如何，白盒測試的主要方法包括邏輯驅動，基礎電路測試等，這些方法主要用于軟件驗證?！鞍缀小狈椒ㄈ媪私饬顺绦虻膬?nèi)部邏輯結構，并測試了所有邏輯路徑?！鞍缀小狈椒ㄊ窃敱M的路徑測試。使用此方案時，測試人員必須檢查程序的內(nèi)部結構，從檢查程序的邏輯開始，并獲取測試數(shù)據(jù)。整個程序中獨立路徑的數(shù)量是天文數(shù)字。但是，即使每條路徑都經(jīng)過測試，仍然可能會出現(xiàn)錯誤。首先，詳盡的路徑測試永遠不會發(fā)現(xiàn)程序違反了設計規(guī)范，也就是說，程序本身是錯誤的程序。其次，窮舉路徑測試由于缺少路徑而無法檢測程序中的錯誤。第三，詳盡的路徑測試可能找不到一些與數(shù)據(jù)相關的錯誤。2.1.3單元測試的基本方法單元測試針對軟件設計模塊的最小單元，單元測試的基礎是詳細的設計說明。單元測試需要為模塊內(nèi)的所有關鍵控制路徑設計測試用例，以便發(fā)現(xiàn)模塊內(nèi)的錯誤。單元測試主要使用白盒測試技術來允許并行測試系統(tǒng)中的多個模塊。單元測試任務單元測試任務包括：1模塊接口測試；2模塊內(nèi)局部數(shù)據(jù)結構測試；3模塊邊界值條件測試；4獨立執(zhí)行路徑測試；5模塊的每條錯誤場景路徑測試，僅當數(shù)據(jù)可以正確輸入輸出模塊時，測試才存有意義。測試數(shù)據(jù)接口的準確性應考慮以下主要因素：1.輸入的實際參數(shù)和形式參數(shù)的數(shù)目是否相同，屬性是否匹配。2.輸入的實際參數(shù)和形式參數(shù)的尺寸是否相同3.調(diào)用以及其他管理模塊時指定的實際工作參數(shù)數(shù)目是否與被調(diào)用功能模塊的正式參數(shù)數(shù)目相同。4.調(diào)用另一個模塊時指定的實際參數(shù)屬性是否與被調(diào)用模塊的正式參數(shù)屬性相匹配。5.調(diào)用其他模塊時指定的實際參數(shù)的尺寸是否與已調(diào)整模塊的形式參數(shù)的尺寸匹配。6.調(diào)用預定義函數(shù)時使用的參數(shù)的數(shù)量，屬性和順序是否正確？7.是否有與當前入口點無關的參數(shù)引用？8.只讀參數(shù)是否已更改。9.整個過程變量的定義在每個模塊中是否一致。10.是否將特定約束作為參數(shù)傳遞。如果模塊包含外部輸入和輸出，則還應考慮以下因素：1.文件屬性問題2.OPEN/CLOSE語句是否匹配3.格式說明是否與輸入和輸出語句匹配。4.緩沖區(qū)大小是否與記錄長度匹配。5.是否在使用前打開了文件。6.是否處理文件結尾。7.是否處理輸入/輸出錯誤。8.輸出信息中是否有文本錯誤。檢查本地進行數(shù)據(jù)結構設計是為了確保在程序執(zhí)行工作期間臨時存儲在模塊中的數(shù)據(jù)是完整且正確的。部分數(shù)據(jù)結構通常會導致錯誤。應仔細設計測試用例，以發(fā)現(xiàn)以下類型的錯誤：1.對不適當或不兼容類型的描述。2.變量沒有初始值。3.變量初始化或默認值不正確。4.變量名稱不正確（拼寫錯誤或被截斷）。5.發(fā)生溢出，下溢和地址異常。除了本地數(shù)據(jù)結構外，單元測試還應確定全局數(shù)據(jù)對模塊的影響。每個獨立的執(zhí)行路徑都應在模塊中進行測試。單元測試的基本任務是確保模塊中的每個語句至少執(zhí)行一次。此時，測試用例旨在發(fā)現(xiàn)由于計算不正確，比較不正確以及控制流程不正確而導致的錯誤。目前，基本的通過測試和循環(huán)測試是最常用和最有效的測試技術。計算中的常見錯誤是：1.誤解或使用了錯誤的操作員優(yōu)先級。2.混合操作。3.變量的初始值不正確。4.精度不足。5.表達式符號不正確。比較決策和控制流通常緊密相關，并且測試用例還應著重于發(fā)現(xiàn)下一個錯誤：1.比較不同數(shù)據(jù)類型的對象2.邏輯運算符或優(yōu)先級的濫用3.由于計算機精度顯示的顯示，導致兩個相差不大的值強制相等。4.比較操作或變量錯誤。5.循環(huán)結束條件可能不會顯示。6.當?shù)制鐣r，它不能結束。7.無意中更改了循環(huán)變量。一個好的設計應該能夠預期不同的錯誤情況并預設不同的錯誤處理路徑，錯誤處理路徑也應仔細測試，該測試應針對以下問題：1.輸出錯誤消息難以理解。2.記錄錯誤與實際發(fā)生不匹配。3.系統(tǒng)在程序定義的錯誤處理部分執(zhí)行之前進行了干預。4.異常處理不當。5.異常捕獲的提示不能精確定位。2.1.4恢復測試恢復測試主要檢查系統(tǒng)運行時的容錯能力。當系統(tǒng)中突然發(fā)生錯誤時，是否可以在指定的時間間隔內(nèi)自動更正錯誤？恢復測試必須首先使用各種方法強制系統(tǒng)故障，例如服務運行時突然斷電，突然手工關閉執(zhí)行系統(tǒng)，然后驗證系統(tǒng)重啟是否可以自行恢復？不會造成執(zhí)行系統(tǒng)內(nèi)的文件丟失，這好比數(shù)據(jù)庫的自動回滾操作，對于重啟執(zhí)行服務，后臺機制得重新驗證文件的一致性和完整性，例如模塊重新初始化，圖算法的初始化，檢查點機制（datarecovery)。還得去記錄恢復時長，保證其在一個正常的耗時范圍內(nèi)。2.5.2安全測試安全測試檢查系統(tǒng)防止非法入侵的能力。在安全測試中，測試人員假裝為非法侵入者，并使用各種方法試圖突破防線。2.5.3強度測試強度測試檢查程序對異常情況的抵抗力，測試始終會強制系統(tǒng)在異常資源分配下運行。2.5.4性能測試對于那些實時和嵌入式系統(tǒng)，即使軟件部分滿足功能要求，也可能無法滿足性能要求。盡管從單元測試來看，每個測試步驟都包括性能測試，但是只有在系統(tǒng)真正集成之后，它才能在實際環(huán)境中按需針對使用場景較高的模塊進行全方位的性能測試，其中就包括并發(fā)測試和穩(wěn)定性測試，系統(tǒng)性能測試就是要完成這一任務。性能測試通常需要其他軟件和硬件的配套支持，要不然會造成硬件上的瓶頸，從客觀因素降低系統(tǒng)的性能值，文章后面會著重介紹這部分。

3.軟件測試的誤區(qū)隨著互聯(lián)網(wǎng)產(chǎn)業(yè)規(guī)模的不斷擴大和軟件設計越來越復雜，市場上的產(chǎn)品質(zhì)量參差不齊，質(zhì)量高產(chǎn)品優(yōu)秀的例子少之又少。還有，軟件質(zhì)量和用戶體驗越來越得到重視，因此，軟件測試在項目中的地位越來越舉足輕重，把守著軟件質(zhì)量的最后的一到關卡。但現(xiàn)實是，軟件測試與軟件開發(fā)比較，目前國內(nèi)測試的地位并未得到根本上的重視，常見的開發(fā)測試配比都是6:1甚至10:1,。項目組人員仍存在對軟件測試的偏見，項目周期的緊張從而壓縮測試人員配比和測試時間，從而影響了測試活動的執(zhí)行。3.1誤區(qū)之一根據(jù)軟件開發(fā)流程思路，軟件項目會經(jīng)歷一下幾個階段：需求分析、概要設計、詳細設計、軟件編碼、軟件測試和軟件發(fā)布。所以人們通俗的認為軟件測試的開展是在編碼之后才能執(zhí)行。由于這種理解的偏差不了解軟件測試的周期。其實軟件測試從項目的初期開展就開始介入，例如需求評審和分析會，測試計劃的撰寫，測試用例設計及最終的測試執(zhí)行。因此，軟件測試貫穿軟件項目的整個生命周期。在軟件項目的每個階段，必須測試不同的功能和內(nèi)容，以確保每個階段的正確性。軟件測試的對象不僅是軟件代碼，而且還包括軟件需求文檔和設計文檔。軟件開發(fā)和軟件測試應該是交互式的。正如單元編碼則脫離不了單元測試，待單元測試通過后匯集而成的模塊則成為集成測試。如果還是保留項目編碼結束后才能介入測試，則在整個項目周期內(nèi)，留給測試人員的時間就會很緊迫，會導致測試覆蓋場景不完善，用例設計的效果和質(zhì)量都不高，并導致測試執(zhí)行效率大大降低從而導致產(chǎn)品的質(zhì)量存在問題。如果編碼結束后發(fā)現(xiàn)需求設計上與實現(xiàn)的不符，則將花費大量的時間成本去修復它。還有更嚴重的情況，就是當編碼結束后發(fā)現(xiàn)的是需求和設計的問題，嚴重的話有可能要去模塊重構，這對整個項目來說是災難的，會嚴重拖低項目的進度。3.2誤區(qū)之二產(chǎn)品上線后存在的問題，都會把鍋甩給軟件測試人員，質(zhì)疑他們?yōu)槭裁床荒軠y出問題來？這種偏見很容易使測試人員泄氣和不滿。軟件中的錯誤可能來自軟件項目的每個過程，正如測試環(huán)境和生產(chǎn)環(huán)境，由于代碼構件的差異，也會存在兩個環(huán)境的版本信息不一致，從而導致問題的出現(xiàn)。還有軟件測試只能盡自身最大的能力找出軟件中隱藏的缺陷，但不能保證系統(tǒng)軟件完全沒有一個錯誤，因為從窮舉的思維根本無法覆蓋所有的測試場景，從而無法找到所有的錯誤。所以得更多的從項目管理和項目運作過程尋找原因，從而進行改進。3.3誤區(qū)之三軟件測試并不困難，任何人都可以做到。大部分人認為測試人員只需要點下鼠標和鍵盤就行了，這是由于軟件測試的偏差和對測試技術和方法缺乏深入理解造成的。隨著軟件工程學科的完善和發(fā)展和市場上項目流程的優(yōu)化，軟件測試技術可以獨當一面了，并對于高端技術人才方面存在嚴重缺口，對市場需求有很大的沖擊。正如目前軟件測試技術更新迭代之快，衍生了很多新型的測試工具、測試框架、搭配著新的測試流程和新理念。并且有很多測試知識需要學習和沉淀。軟件測試也和軟件開發(fā)大同小異，主要圍繞著技術和團隊的管理，當然掌握這兩項技能需要積累大量的項目經(jīng)驗、不斷進取的學習精神和管理思維能力。3.4誤區(qū)之四開發(fā)人員對測試不重視，認為測試是單純是測試人員的事。但實際上在團隊里，開發(fā)和測試是相互補的存在，脫離了誰都不行。還有測試人員，開發(fā)人員和設計人員需要保持緊密的溝通確保對產(chǎn)品的認知上不出現(xiàn)任何偏差。其次開發(fā)人員應對自己的模塊負責，做好單元測試，測試人員可以在必要時根據(jù)自身測試經(jīng)驗幫助設計測試單元用例。在軟件周期內(nèi)，越早發(fā)現(xiàn)的bug，修復的時間成本就會越低。開發(fā)人員有時候會因為測試提多的bug而苦惱，認為測試人員有意而為之，但換個角度想，開發(fā)可以根據(jù)bug的修復分析軟件錯誤的類型，以找出錯誤的位置和原因，從而積累開發(fā)經(jīng)驗，避免碰到同類問題再次踩坑。3.4誤區(qū)之五當項目進度緊張時，從而壓縮測試的時間，而在時間充裕時，則進行更多的測試。這說明了對軟件測試存在很大的偏見和誤解，也是整個目前中小型企業(yè)管理混亂的通病，以為有產(chǎn)出了就能收到客戶的回款，誰不知由于產(chǎn)品質(zhì)量不過關反而弄巧成拙。對于項目實施中的任何問題，必須進行風險分析和準備相應的對策。不要因為前期需求調(diào)研拖延或編碼進度滯后而強制縮減測試執(zhí)行時間、測試的人員分配。由于縮短測試時間會帶來不完整的測試。因此，由于項目產(chǎn)品質(zhì)量嚴重下降導致系統(tǒng)的不穩(wěn)定性。例如系統(tǒng)的運維，客戶的善后，功能的變更通常會導致更大的浪費，導致客戶對整個系統(tǒng)的信心逐步消磨，所以解決的方案是加強對項目的管控，包括計劃、進度、產(chǎn)出。

4.軟件測試的流程隨著互聯(lián)網(wǎng)產(chǎn)業(yè)規(guī)模的不斷擴大和軟件設計的復雜性不斷增加，市場上的產(chǎn)品質(zhì)量參差不齊，質(zhì)量高產(chǎn)品優(yōu)秀的例子少之又少。還有，軟件質(zhì)量和用戶體驗越來越得到重視，因此，軟件測試在項目中的地位越來越舉足輕重，得指定完整的軟件測試流程圖，提高軟件測試軟件的質(zhì)量和效率4.1測試流程說明4.1.1需求階段測試人員了解項目需求及需求變更，包括設計文檔、業(yè)務結構及功能模塊劃分，根據(jù)需求設計梳理測試點。4.1.2測試計劃階段測試工具選取測試人員分配測試環(huán)境梳理測試數(shù)據(jù)梳理4.1.3.測試準備階段構建代碼管理測試環(huán)境搭建測試數(shù)據(jù)腳本編寫測試用例編寫(功能測試框架)界面友好性測試4.1.4測試執(zhí)行階段測試結果分析階段上線準備階段上線后測試跟蹤階段項目總結階段后面會詳細講解這部分4.2需求梳理4.2.1需求梳理根據(jù)需求文檔、需求四件套來對測試模塊功能點進行梳理，而且通過需求文檔能夠更加清楚項目的業(yè)務背景，業(yè)務架構，一般情況下，在項目中需求文檔有3種現(xiàn)狀：1. 有詳細的需求文檔：嚴謹且流程管理規(guī)范的項目研究團隊是有詳細的需求分析設計文檔的，身為測試技術人員的我們可以詳閱需求文檔來進行測試點的梳理工作，在需求評審階段對于需求中你認為功能不明確的地方可以找設計主要負責人或項目經(jīng)理進行有效溝通，對需求做到整體把握和詳盡的理解，利于提高我們通過測試更好的進行。。2.設計不明確或文檔不完善：對于我個人處理，如果和開發(fā)溝通后明確設計不合理或不明確，我們會共同去拉一個群找到設計人員去確認需求，如果因為設計人員回復不及時或沒有下文回應，那么就需要自己去面對面溝通，記錄疑問點并拋出問題去咨詢設計人員，測試人員切記不要含糊不清的進行測試，要不然后續(xù)吃虧的還是自己。3.沒有需求文檔：根據(jù)自身經(jīng)驗，覺得該功能設計效果和系統(tǒng)實現(xiàn)不合理，我會去大群里找到相應設計負責人問，協(xié)商溝通，說出自己的講解，督促設計人員規(guī)范流程，補全設計文檔及要求。4.3測試計劃4.3.1測試工具選取測試工具說明：圖中羅列了一些市面上常用的工具，包括UI、接口、性能等工具，可按需選用。4.3.2測試資源分配測試計劃制定后，測試經(jīng)理需要分配好測試單給相應的測試人員。例如：環(huán)境搭建負責人、模塊測試負責人、模塊測試用例編寫負責人、業(yè)務測試數(shù)據(jù)腳本負責人、執(zhí)行測試的負責人。由于測試資源的經(jīng)常，有可能每個測試人員負責一個或者多個功能模塊，但全能型選擇也大有人在，即一個人完成的編譯環(huán)境，準備測試數(shù)據(jù)，編寫測試用例，測試執(zhí)行的情況下錯誤收集分析。當然，這對測試工作人員的技能掌握一定程度較高才行，合理的資源進行分配能更好保證企業(yè)產(chǎn)品的輸出質(zhì)量。。4.3.3測試環(huán)境梳理及搭建根據(jù)項目的要求，執(zhí)行系統(tǒng)清單、服務器數(shù)量(應用服務、數(shù)據(jù)庫服務器)，制定測試環(huán)境搭建關系圖（分離部署系統(tǒng)、分布式服務器，整個系統(tǒng)部署的流程及每個應用、環(huán)境監(jiān)測工具、數(shù)據(jù)庫、輔助性測試工具等）。4.3.4測試數(shù)據(jù)梳理測試數(shù)據(jù)包括大量的內(nèi)容，包括測試制劑和所需的所有數(shù)據(jù)源，如測試執(zhí)行階段如：需求設計文檔、測試數(shù)據(jù)腳本、數(shù)據(jù)庫腳本、測試參數(shù)化文件測試賬號測試工具讓測試工作按預定計劃的進行，而不是項目提測后，缺哪樣補哪樣，嚴重降低工作效率4.4測試準備4.4.1構建代碼管理集中管理，開發(fā)人員代碼倉庫應與測試代碼倉庫進行分離，互補干擾影響，當開發(fā)提測給測試人員進行測試時，開發(fā)人員提交構建到測試階段，測試人員基于測試階段測試通過后把構建移動到體驗階段做系統(tǒng)測試，系統(tǒng)測試通過后移動到正式階段發(fā)布。4.4.2測試環(huán)境搭建參考4.3測試計劃的4.3.3測試環(huán)境梳理及搭建，按照預先計劃，以應用服務器部署策略，以建立一個測試環(huán)境，打造環(huán)境的未來保存的更清晰的概念也比較方便。市面上聽聞很多關于測試環(huán)境這塊的梳理和管理的工作，有的是專職運維人員來管理環(huán)境，但我接觸的大部分都是由測試團隊自個維護的，所以這對測試人員運維要求也是蠻高的，特別是windows基本及數(shù)據(jù)庫操作，包括數(shù)據(jù)庫的創(chuàng)建，備份與恢復等等。但前提是需要保證的是測試環(huán)境應當與開發(fā)環(huán)境相互獨立，也能更好的定位問題所在。這是我工作后發(fā)現(xiàn)的現(xiàn)象：開發(fā)人員在功能開發(fā)完成后質(zhì)量不保證，很多肉眼可見的bug，還會亂部署到開發(fā)環(huán)境，而因為開發(fā)環(huán)境沒人去統(tǒng)一的運維人員去管理,從而有可能環(huán)境里雜七雜八的報錯促使無法進行調(diào)試。甚至有的開發(fā)人員未經(jīng)自測直接部署在測試環(huán)境上，這樣帶來一個后果就是，測試環(huán)境會變得越來越不穩(wěn)定，時間一長，測試環(huán)境的數(shù)據(jù)會越來越亂，甚至還會造成測試環(huán)境的停擺，測試工作的滯后導致增加測試人員的工作量。4.4.3測試數(shù)據(jù)腳本編寫4.5測試用例編寫(功能測試框架)測試用例編寫不是隨心所欲，得根據(jù)對功能背景和實際場景的了解，并按照一定的邏輯思路去編寫，一般公司都會存在公共業(yè)務用例庫和用例模板，掌握基本知識點后對新手測試是很友好的，還有關于項目測試流程圖，當然隨著自己職業(yè)生涯的發(fā)展，應當積累一些工作經(jīng)驗，寫出復用性強的測試框架，讓項目可根據(jù)指定測試框架執(zhí)行測試，從而提升測試效率。4.5.1界面友好性測試1.風格、樣式、顏色是否協(xié)調(diào)2.界面布局是否整齊、協(xié)調(diào)（保證全部顯示出來的，盡量不要使用滾動條3.界面操作、標題描述是否恰當（描述有歧義、注意是否有錯別字）4.操作是否符合人們的常規(guī)習慣（有沒有把相似的功能的控件放在一起，方便操作）5.提示界面是否符合規(guī)范（不應該顯示英文的cancel、ok，應該顯示中文的確定等）6.界面中各個控件是否對齊7.日期控件是否可編輯8.日期控件的長度是否合理，以修改時可以把時間全部顯示出來為準9.查詢結果列表列寬是否合理、標簽描述是否合理10.查詢結果列表太寬沒有橫向滾動提示11.對于信息比較長的文本，文本框有沒有提供自動豎直滾動條12.數(shù)據(jù)錄入控件是否方便13.有沒有支持Tab鍵，鍵的順序要有條理，不亂跳14.有沒有提供相關的熱鍵15.控件的提示語描述是否正確16.模塊調(diào)用是否統(tǒng)一，相同的模塊是否調(diào)用同一個界面17.用滾動條移動頁面時，頁面的控件是否顯示正常18.日期的正確格式應該是XXXX-XX-XX或XXXX-XX-XXXX:XX:XX19.頁面是否有多余按鈕或標簽20.窗口標題或圖標是否與菜單欄的統(tǒng)一21.窗口的最大化、最小化是否能正確切換22.對于正常的功能，用戶可以不必閱讀用戶手冊就能使用23.執(zhí)行風險操作時，有確認、刪除等提示嗎24.操作順序是否合理25.正確性檢查：檢查頁面上的form,button,table,header,footer,提示信息，還有其他文字拼寫，句子的語法等是否正確。26. 進行異常操作時，提示報錯信息應明確，而不是報一大串代碼錯誤那種，無法識別錯誤。27.頁面分辨率檢查，在各種分辨率瀏覽系統(tǒng)檢查系統(tǒng)界面友好性。28.合理性檢查：做刪除,更新,新增,取消,回退等操作，是否做到友好提示？提示信息是否準確？能否正常觸發(fā)相應的功能？4.5.2功能測試1.使用所有默認值進行測試2.根據(jù)所有需求文檔、產(chǎn)品文檔中描述的內(nèi)容要進行場景覆蓋測試3.輸入判斷4.所有界面出現(xiàn)是和否的邏輯？5.異常處理6.敏感詞7.根據(jù)需求文檔的流程圖遍歷所有流程圖路徑8.根據(jù)程序內(nèi)容，遍歷ifelifelseswitch的邏輯點要遍歷9.界面各種控件測試字符型輸入框1.字符型輸入框：英文全角、英文半角、數(shù)字、空或者空格、特殊字符“~！@#￥%……&*？[]{}”特別要注意單引號和&符號。禁止直接輸入特殊字符時，使用“粘貼、拷貝”功能嘗試輸入。2.長度檢查：長度檢查：最小length、最大length、最小length-1、最大length+1、復制粘貼時，超出文本框也能正常粘貼進去。3.空格檢查：輸入的字符間有空格、字符前有空格、字符后有空格、字符前后有空格4.多行文本框輸入：允許輸入換行的回車符，顯示保存后可以保存輸入的格式，只輸入回車換行，并檢查是否能正確保存（如果是，則檢查保存結果；如果沒有，檢查是否有正常提示）數(shù)值型輸入框1.邊界值：最大值、最小值、最大值+1、最小值-12.位數(shù)：最小位數(shù)、最大位數(shù)、最小位數(shù)-1最大位數(shù)+1、輸入超長值、輸入整數(shù)3.異常值、特殊字符：不輸入任何值、空格、~!@#$%^&*()_+{}|[]\:"<>?;',./?;:'-=等特殊符號的組合4.5.3業(yè)務流程測試(主要功能測試)業(yè)務流程，數(shù)據(jù)通常涉及多個模塊，所以當業(yè)務流程測試，我們首先要保證各個模塊功能的正確性，然后是對各個模塊的測試，這往往容易出現(xiàn)問題的地方之間必要的數(shù)據(jù)傳輸，一定要測試用于測試不同的設計數(shù)據(jù)。涉及到增刪改的模塊，則需要以下案例制定測試用例：1.單項功能測試（增加、修改、查詢、刪除）2.增加——>增加——>增加（連續(xù)增加測試）3.增加——>刪除4.增加——>刪除——>增加（新增加的內(nèi)容與刪除內(nèi)容一致）5.增加——>修改——>刪除6.修改——>修改——>修改（連續(xù)修改測試）7.修改——>增加（新增加的內(nèi)容與修改前內(nèi)容一致）8.修改——>刪除9.修改——>刪除——>增加（新增加的內(nèi)容與刪除內(nèi)容一致）10.刪除——>刪除——>刪除（連續(xù)刪除測試）4.5.5容錯測試1.輸入系統(tǒng)不允許的數(shù)據(jù)作為輸入2.把某個相關模塊或者子系統(tǒng)停掉，驗證對當前系統(tǒng)的影響3.配置文件刪除或者配置錯誤4.數(shù)據(jù)庫注入錯誤數(shù)據(jù)4.5.6穩(wěn)定性測試1.系統(tǒng)不間斷運行（24h*7d），驗證內(nèi)存是否回收？內(nèi)存是否溢出、泄漏，磁盤容量不足，網(wǎng)絡波動，丟包或系統(tǒng)服務器資源是否存在泄露。2.如果項目急著上線，可以根據(jù)調(diào)研得出的實際性能場景跑一晚上或者利用周末的時間來跑。在強負載的情況下，一般數(shù)據(jù)連接數(shù)問題、內(nèi)存溢出和泄漏問題會體現(xiàn)的更加明顯。4.5.7常規(guī)性能測試1.壓力測試壓力測試安排在系統(tǒng)相對穩(wěn)定，且模塊變更不大后進行，在模擬客戶網(wǎng)絡環(huán)境、硬件環(huán)境等進行測試。系統(tǒng)運行性能反饋不是一個測試組或者整個項目人員就能反饋出來的。請求的數(shù)量和實際使用人事制度將能夠處理遠遠超出了這個范圍，因此，只有在網(wǎng)絡上，接受壓力測試的結果，以到達最準確的是最真實的。。進行壓力測試指的是極強的負載，大并發(fā)用戶數(shù)，大請求和數(shù)據(jù)量的手段去測試系統(tǒng)，看系統(tǒng)是否具備良好的容錯能力和故障恢復能力。黑客常常提到的ddos攻擊，就是大量錯誤的數(shù)據(jù)請求，執(zhí)行系統(tǒng)承受不了從而崩潰。壓力測試包括列表加載、登錄、數(shù)據(jù)庫壓測、導入及其他常用核心頁面等。4.5.8易用性測試1.系統(tǒng)界面的控件是否可以通過tab鍵操作，并且順序合理2.主要功能的入口和操作是否易于理解3.界面是否布局合理，功能是否易于查找和使用4.操作步驟5.操作習慣6.有足夠的提示信息，且信息文字描述準確4.5.9兼容性測試兼容性測試不僅是指在不同的操作系統(tǒng)或瀏覽器中，測試的某些功能，同時也考慮到兼容性，包括操作系統(tǒng)和兼容兼容應用軟件兼容的接口，還可以包括硬件兼容性。比如涉及到ajax、jquery、javascrip等技術的，都要考慮到不同瀏覽器下的兼容性問題。4.6

測試執(zhí)行4.6.1接口自動化測試目前市面上主流的接口測試工具有：jmeter、robotframework、httprunner、測試框架等。自動化測試的執(zhí)行可以版本上線后將上線版本的自動化測試的可手動觸發(fā)由jenkins自動觸發(fā)規(guī)則的任務，或用于自動構建工具來執(zhí)行，工具目的是要取代的一個部分off手工操作，減少了重復的工作，減少重復性工作，提升測試效率；正如我目前所用的python+httprunner+jenkins組合，版本發(fā)生迭代時，Jenkins通過定時任務去運行python+httprunner框架腳本，調(diào)整定時任務運行編寫好的接口腳本，并生成測試報告并通過郵件方式或者微信公眾號的方式接受測試接口異常警告等。這樣運維人員能在第一時間清楚目前版本質(zhì)量情況，有問題發(fā)生的話也能馬上進行響應處理。報告包含異常的接口，減少人工去一個個檢查的時間，更多的時間去處理異常和接口維護。通常項目上線后除非設計變更，要不然接口參數(shù)一般不會去進行改動。實際情況是增加接口數(shù)，或者針對一些接口進行一些小幅度修改，那樣的話接口腳本只需稍微調(diào)整就行，復用性及可維護性強。4.6.3傳統(tǒng)測試用例測試目前常用的用例的設計方式有：等價類劃分法場景法邊界值法正交分解法因果圖法錯誤推測法隨機測試等根據(jù)這些方法可以根據(jù)實際情況組合使用，根據(jù)需求設計文檔編寫測試用例，羅列測試要點，覆蓋功能測試點，提示測試效率和軟件質(zhì)量的把控。這里給出一個等價類劃分法結合邊界值方法的測試用例設計例子：這里給出一個日期控件的用例：年日月型在錄入框中錄入內(nèi)容為空，進行保存1．保存成功（允許保存空值）2．保存不成功，彈出提示信息，確定后，將焦點定位到當前錄入框（不允許保存空值）錄入YYYY（年份）的值在【1895，2100】區(qū)間內(nèi)1．系統(tǒng)識別為合法年份，允許進行下一步操作錄入YYYY（年份）的值不在【1895，2100】區(qū)間內(nèi)1．系統(tǒng)識別為非法年份，不允許進行下一步操作錄入MM（月份）的值在【1，12】區(qū)間1．系統(tǒng)識別為合法月份，允許進行下一步操作錄入MM（月份）的值不在【1，12】區(qū)間1．系統(tǒng)識別為非法月份，不允許進行下一步操作錄入年份為閏年的2月，錄入的日期為29允許進行保存錄入年份不是閏年的2月，錄入的日期為29不允許保存，提示相關信息錄入的年份、月份、日期中的任何一組數(shù)據(jù)，帶有小數(shù)位數(shù)。1．不允許進行保存（例如：2.07-01-02、2007-1.-10）或2．系統(tǒng)直接控制不允許錄入小數(shù)點的內(nèi)容錄入格式為非日期格式。1．系統(tǒng)識別為非法月份。不允許進行下一步操作；（如：2007-01-*1、200H-04-05、2007-0！-01）或2．系統(tǒng)直接控制不允許錄入字符內(nèi)容錄入格式為非日期格式。1．系統(tǒng)識別為非法月份。不允許用戶進行下一步操作；或系統(tǒng)可以直接控制不允許錄入字符內(nèi)容（如：2007-01-*1、200H-04-05、2007-0！-01）在整型錄入框中，使用上箭頭調(diào)整年份【如：基數(shù)=1】1．調(diào)整后的數(shù)據(jù)值=原值+1在整型錄入框中，使用下箭頭調(diào)整年份【如：基數(shù)=1】1．調(diào)整后的數(shù)據(jù)值=原值-1在整型錄入框中，使用上箭頭調(diào)整月份【如：基數(shù)=1】1．調(diào)整后的數(shù)據(jù)值=原值+1在整型錄入框中，使用下箭頭調(diào)整月份【如：調(diào)整基數(shù)為1】1．調(diào)整后的數(shù)據(jù)值=原值-1在整型錄入框中，使用上箭頭調(diào)整月份，使其調(diào)整到大于【最大值】1．調(diào)整數(shù)據(jù)到最大值后，在使用上箭頭調(diào)整時，系統(tǒng)不應該在做任何操作在整型錄入框中，使用下箭頭調(diào)整月份，使其調(diào)整到小于【最小值】1．調(diào)整數(shù)據(jù)到最小值后，在使用下箭頭調(diào)整時，系統(tǒng)不應該在做任何操作在整型錄入框中，使用上箭頭調(diào)整日份【如：調(diào)整基數(shù)為1】1．調(diào)整后的數(shù)據(jù)值=原值+1在整型錄入框中，使用下箭頭調(diào)整日份【如：調(diào)整基數(shù)為1】1．調(diào)整后的數(shù)據(jù)值=原值-1日月期型：日輸入[0日]程序應提示錯誤日輸入[1日]OK日輸入[32日]程序應提示錯誤月輸入[1、3、5、7、8、10、12月]、日輸入[31日]OK月輸入[4、6、9、11月]、日輸入[30日]OK月輸入[4、6、9、11月]、日輸入[31日]程序應提示錯誤輸入非閏年,月輸入[2月]、日輸入[28日]OK輸入非閏年,月輸入[2月]、日輸入[29日]程序應提示錯誤(閏年)月輸入[2月]、日輸入[29日]OK(閏年)月輸入[2月]、日輸入[30日]程序應提示錯誤月輸入[0月]程序應提示錯誤月輸入[1月]OK月輸入[12月]OK月輸入[13月]程序應提示錯誤時間型：時間型合法性檢查時輸入[30時]允許輸入30時制的項目“OK";

不允許輸入30時制的項目程序應提示錯誤時輸入[31時]程序應提示錯誤時輸入[00時]程序應提示錯誤30時制是否允許存在1點~5點？？分輸入[59分]OK分輸入[60分]程序應提示錯誤分輸入[00分]OK秒輸入[59秒]OK秒輸入[60秒]程序應提示錯誤秒輸入[00秒]OK異常值、特殊值輸入[空白(NULL)]或“~!@#$%^&*()_+-={}[]|\:;”’<>,./?;”等可能導致系統(tǒng)錯誤的字符程序應提示錯誤4.6.4Bug跟蹤測試人員必須記錄和跟蹤在測試過程中發(fā)現(xiàn)的問題，不要以為小bug口頭上對開發(fā)人員通知一下。因為bug的記錄有利于項目各負責人了解系統(tǒng)的真實的質(zhì)量情況。目前常用的bug管理工具：禪道、vteam等，從用例的執(zhí)行到bug記錄，通過測試人員指派給開發(fā)人員，bug的返工次數(shù)，只至bug的解決并關閉。貫穿整個bug的生命周期，當中都能實時看到并進行嚴格的管控，幫助項目經(jīng)理、產(chǎn)品經(jīng)理對當前系統(tǒng)情況有個清楚的認知，并根據(jù)實際情況進行產(chǎn)品優(yōu)化，質(zhì)量的把控。4.7

測試結果分析4.7.1結果收集測試腳本運行結果，測試用例報告、性能測試報告、數(shù)據(jù)庫性能和監(jiān)控報告、執(zhí)行系統(tǒng)服務器資源監(jiān)控報告、中間件日志報告等。譬如：1、測試用例：用例執(zhí)行pass或failed總數(shù)2、性能測試結果：堡壘機資源監(jiān)控結果（包括cpu資源、硬盤i/o，內(nèi)存使用等）。收集上述問題并進行匯集，根據(jù)實際情況按需排產(chǎn)解決；4.7.2結果分析匯總各模塊的測試結果，在bug管理軟件收集得到各迭代版本的bug總數(shù)，過濾出嚴重bug數(shù)，得出bug返工率等，找出bug集中在哪些模塊？通過組內(nèi)討論給出相關改進。通過性能測試結果逐步完善性能指標，與舊版本比較是否較于上次性能有所提升？4.7.3測試分析報告根據(jù)分析報告，制定系統(tǒng)的性能指標值，公布于項目組內(nèi)，提供項目上線后的風險評估，如果對項目技術架構和業(yè)務架構熟悉，還可以提供系統(tǒng)的改進計劃，提高軟件的質(zhì)量。4.8上線準備4.8.1版本發(fā)布經(jīng)過測試人員測試通過后和項目組的評估，可以進行發(fā)版發(fā)版內(nèi)容需給出：代碼包、數(shù)據(jù)庫等材料發(fā)布文檔：用戶手冊、部署手冊、實施手冊、測試報告文檔、版本說明4.8.2數(shù)據(jù)準備上線前測試跟蹤需要做好準備工作，避免上線后，影響工作效率如模塊數(shù)據(jù)準備回退版本方案測試腳本4.9上線測試跟蹤4.9.1跟蹤測試1.系統(tǒng)上線并功能穩(wěn)定后，可以開展接口自動化測試，保證系統(tǒng)間常用接口功能正常；2.每次迭代后要對常用的核心功能進行重點測試；3.做好bug的跟蹤記錄工作，根據(jù)優(yōu)先級進行排產(chǎn)，bug嚴重級別高需要開發(fā)修改后再進行一輪的復測。對于一般性bug，例如某個界面提示語問題，普通UI問題、錯別字問題，需做好優(yōu)化問題記錄4、測試人員需要積累項目的bug經(jīng)驗，或者參考同行的測試用例，提升自身的測試水平，改善缺陷預防體系，完善測試用例庫，進行組內(nèi)分享。5、bug問題做好標簽分類，納入公共用例庫，杜絕以后發(fā)生類似的問題，提高用戶體驗同時兼顧項目的實際情況。6、項目成功上線后，要對于項目整體的質(zhì)量做總結分析，產(chǎn)出總結報告。。。5.項目性能工具測試5.1用Jmeter進行接口和性能測試5.1.1ApacheJMeter介紹5.1.2JMeter能用來做什么？1）能夠對HTTP/FTP等協(xié)議進行接口和性能測試2）完全Swing的輕量級組件支持3）分布式壓力測試4）緩存和離線分析/回放測試結果5）提供測試數(shù)據(jù)分析6）各種報表數(shù)據(jù)圖形展示7）高可擴展性5.1.3性能測試目標基于系統(tǒng)業(yè)務量的要求，評估該系統(tǒng)的軟、硬配置能否滿足性能需求進行配置測試，找到相對合理的配置對系統(tǒng)進行定容定量，提供規(guī)劃參考（確定測試場景）驗證系統(tǒng)的穩(wěn)定性，驗證系統(tǒng)的容錯能力測試并找出系統(tǒng)可能存在的性能問題，分析系統(tǒng)瓶頸風險5.1.4Jmeter元件測試計劃：Jmeter性能測試工程計劃，屬于一個管理單元，本下是各種元件的組成元素，類似編譯器中的project取樣器：設置測試樣本，向服務器發(fā)送請求接受及記錄服務器的響應信息邏輯控制器：對元件進行執(zhí)行順序邏輯的控制，常用的邏輯控制器有18個，但大致分類兩類，控制測試計劃中sampler執(zhí)行節(jié)點的邏輯執(zhí)行順序，常用的就If控制器、循環(huán)控制器等。對sampler節(jié)點進行分組，便于測試結果的統(tǒng)計和運行控制，常見的有事務控制器、吞吐量控制器。配置元件（ConfigElement）：對靜態(tài)數(shù)據(jù)配置的支持。（如，HTTPCookieManager可以用于對HTTPRequestSampler的cookie進行管理）定時器：設置sampler的等待時間，和LR里“思考時間”如出一轍。常用的定時器SynchronizingTimer（與LR集合點作用相似）、常數(shù)固定定時器等。前置處理器：對請求發(fā)送前做一些特殊處理或者參數(shù)準備,例如參數(shù)化，數(shù)據(jù)庫JDBC連接等。后置處理器：一般用于提取請求發(fā)送后服務器返回值，類似于LR里的關聯(lián)，譬如說A請求輸出，它同時也作為B請求的輸入則屬于關聯(lián)。用戶登錄后獲取的token值就是一個很好的例子，我們需要吧token傳給服務器通過驗證。斷言：檢查響應數(shù)據(jù)與預期結果相吻合，斷言常用來于設置checkpoint，以確保響應得到的測試數(shù)據(jù)是否與預期一致。監(jiān)聽器：可視化展示測試結果的數(shù)據(jù)，常用的元件有：圖形結果、察看結果樹、聚合報告。

圖Jmeter5.0界面5.1.5JMeterhttp接口腳本一個基本的http接口腳本一般分九個步驟：（1）添加線程組，配置線程數(shù)（2）添加集合點（SynchronizingTimer）（3）添加HTTPCookie管理（4）添加HTTP信息頭管理器（5）添加http請求（6）在http請求中寫入接入url、路徑、請求方式和參數(shù)（7）添加察看結果樹（8）添加聚合報告（9）調(diào)用接口、查看返回值以下是詳細介紹：1）線程組：點擊“testplan”——>“add”-——>“Threads(Users)”——->選擇“Threadsgroups”并發(fā)場景：50Vuser并發(fā)進行活動報名，Ramp-Up時間設置0秒（立即生成50個線程數(shù)）線程組參數(shù)詳解線程數(shù)：一般指的是虛擬用戶數(shù)。Ramp-UpPeriod(inseconds)準備時長：在設定的時間內(nèi)建立線程數(shù)。其默認值為0，如果未填寫ramp-upperiod，JMeter會瞬間建立所有線程數(shù)。打個比方ramp-upperiod設置成S秒，Threads設置成N個，JMeter會每隔S/N秒建立一個線程數(shù)。如果線程數(shù)為100，準備時長為2，那么需要2秒鐘啟動50個線程，也就是1秒鐘啟動25個線程。循環(huán)次數(shù)：設定單個線程發(fā)送請求次數(shù)。如果線程數(shù)設置為9，循環(huán)次數(shù)為10，那么每個線程則會發(fā)送90次請求?？傉埱髷?shù)為90次。如果勾選了“foever”，那么我們所有工作線程會無休止的發(fā)送數(shù)據(jù)請求，直至通過手動進行停止使用腳本或軟件奔潰時停止。DelayThreadcreationuntilneeded：延遲線程的創(chuàng)建。調(diào)度器：設置線程組啟動延遲時間(s)和持續(xù)時間(s)(配置調(diào)度器時，需要勾選循環(huán)次數(shù)為永遠)2）集合點：右鍵點擊“testplan”>“add”>Timer>“SynchronizingTimer”通過添加SynchronizingTimer定時器來配置集合點。SynchronizingTimer作用僅于同一個JVM中的線程。NumberofSimulatedUserstoGroupby:集合點到達數(shù)，通俗來說就是用戶達到設定值就出發(fā)請求執(zhí)行。Timeoutinmilliseconds（單位：ms）：虛擬用戶超過這個值時但沒到集合點算超時，線程會一直等待。Ex：Timeoutinmilliseconds為0時，說明沒設置超時時間，線程會一直無限等待。同理，當線程進行數(shù)量已經(jīng)無法滿足小于“Number

of

Simultaneous

Users

to

Group

by“中設置的值，線程也會一直都是無限可能等待。3）HTTPCookie管理器如果接口需要權限認證，需要登錄用戶才可以做操作，則需要添加Cookie”,右鍵測試計劃——>“添加”——>“配置元件”——>“HTTPCookie管理器”；例如：對某一用戶進行請求，那么需要驗證用戶身份，這就需要用到Cookie管理器。Cookie中的“名稱(key)”為登錄的用戶名，如截圖中是“JSESSIONID”和Cookie中的“值(value)”可以從登錄接口獲取，也可以從瀏覽器RequestHeaders獲??；Ex：一個測試計劃內(nèi)最好只建立一個CookieManager，因為多個CookieManager的話Jmeter是無法識別并準確調(diào)用的。3．1）獲取Cookie方法打開待提取Cookie信息的網(wǎng)頁界面并登陸用戶，按下F12，打開網(wǎng)頁控制臺，找到Application一欄，在Storage選擇Cookies，選擇域名后找到JSESSIONID的值，將它放在Cookie管理器即可通過身份驗證； 圖Cookie管理器配置成功頁面圖Cookie管理器配置失敗頁面4）Http信息頭管理器用于配置頁面跳轉，設定請求頭所包含的信息并進行發(fā)送。HTTP信息頭中包含有“Content-Type””User-Agent"、“Pragma"、”Referer"等屬性。在傳參的時候，察看結束樹發(fā)現(xiàn)返回值異常，應該檢查一下Content-Type的值是否設置正確。5）JMeterhttp接口腳本（http請求）5.1）JMeterhttp接口腳本【_Random】函數(shù)【_Random】函數(shù)介紹作用：生成隨機數(shù)使用格式：${__Random(1,500,myResult_Random)}，其中第一個參數(shù)1，表示希望生成的數(shù)字最小的值，必填第二個參數(shù)500，表示希望生成的數(shù)字最大的值，必填第三個特征參數(shù)result，非必填項，腳本進行運行過程中生成的值會保存在這個指定變量里，myResult值在

[1,500]之間關系指的是一個包含1和500兩個不同數(shù)值。6）察看結果樹以下是浙交工模塊中活動報名請求結果：請求成功的在左側察看結果樹會提示綠色圖標，而請求失敗則會顯示紅色圖標；【取樣器結果】中可以查看響應頭、響應數(shù)據(jù)大小、時間，返回狀態(tài)碼等信息【request】顯示請求接口的url、請求參數(shù)、responseheader、Cookies等信息；【響應數(shù)據(jù)】查看接口的返回值7）聚合報告Label：接口請求名稱屬性Samples：測試的過程中向客戶端總共發(fā)出了多少個請求即總線程數(shù)，（如果模擬1個用戶，每個用戶迭代9次，這里就顯示9），samples數(shù)目指的就是這個。Average：指的是請求平均響應時間，計算公式是總運行時間除以對服務器的總請求數(shù)，得出對應圖形報表中的平均值結果。Median：響應時間中位數(shù)，50%用戶響應時間低于該值。90%Line：90%用戶響應時間低于該值。Min：請求后服務器返回最短響應時間。Max：請求后服務器返回最長響應時間。Error%：事務錯誤率，事務請求錯誤數(shù)量除于事務請求總數(shù)。Throughput：系統(tǒng)吞吐量（傳輸數(shù)據(jù)量綜合），也叫tps。指每秒完成的請求數(shù)，也能反映出服務器處理能力，當tps數(shù)值越高說明服務器處理能力越好KB/Sec（ms）：服務器接收到的數(shù)據(jù)量，即每秒請求的字節(jié)數(shù)。7.1）90%Line指標值大部分以為這是90%用戶平均響應時間，其實不是。官網(wǎng)是這么說的：“90%的用戶請求耗時不超過這個時間，而剩余的請求耗時至少在這個時間之上?！币簿褪钦f90%的用戶請求響應時間少于這個時間。7.2）90%Line意義它可以使我們的分析結果更加準確！因為在評估一次測試的結果時，僅僅有平均響應時間是不夠的，而是從多參數(shù)指標中去分析。譬如我舉個例子，一個接口有50個請求返回結果，其中Min響應為0.03秒，Max響應為100秒，Average事務響應為8.6秒，有沒有覺得Min和Max響應時間差距是不是有點高？計算出來的平均值是不是會存在偏差？如果我們根據(jù)每個請求統(tǒng)計響應時間，統(tǒng)計表明響應時間最大值出現(xiàn)的機率微乎其微。除開那1%用戶請求的響應時間，其余都是性能需求標準范圍內(nèi)。所以為了得出更精確的請求耗時，不僅得參考Average響應時間指標，還要加入90％、95％Line等其他性能指標來輔助統(tǒng)計，這樣的出來的結果才能更全面，更貼近實際場景。8）測試結果當我們作為用戶去使用一款軟件，我們最直觀的感知是系統(tǒng)的快慢，請求響應時間是否及時。因此把響應時間作為分析的重點。在處理過程中，可以把響應時間分為如下：呈現(xiàn)時間（瀏覽器解析）+數(shù)據(jù)傳輸時間（網(wǎng)絡瓶頸）+系統(tǒng)處理時間（數(shù)據(jù)庫+服務器）--系統(tǒng)瓶頸9）測試結果不難看出，在150虛擬用戶并發(fā)時，事務成功率有所下降，也許是事務請求出現(xiàn)了瓶頸，導致無法正常返回正常值而到了200用戶并發(fā)時，90％用戶響應呈現(xiàn)指數(shù)型上升，事務成功率也有所下降，所以該接口的瓶頸在150~200之間，得需通過測試人員和開發(fā)人員的排查，進一步確認瓶頸點出現(xiàn)在哪里。硬件上的性能瓶頸：通常指的是CPU，內(nèi)存，磁盤I

/

O區(qū)域的問題，分為服務器硬件瓶頸，網(wǎng)絡瓶頸（LAN上不能被認為是），服務器操作系統(tǒng)瓶頸（參數(shù)配置），中間件瓶頸（參數(shù)配置，數(shù)據(jù)庫，網(wǎng)絡服務器等），應用瓶頸（SQL查詢，數(shù)據(jù)庫設計，業(yè)務邏輯，算法等）。。應用軟件上的性能瓶頸：通常指web服務器、應用服務器和數(shù)據(jù)庫服務器等。例如：JDBC最小、最大連接的參數(shù)設置不合理；；Nginx限流配置，js、圖片壓縮參數(shù)、請求過濾等；應用程序上的性能瓶頸：一般指的是項目的開發(fā)人員研發(fā)的軟件程序。例如，1軟件內(nèi)部架構凌亂，底層代碼邏輯處理不規(guī)范（沒進行并行處理、查詢語句不規(guī)范且沒進行調(diào)優(yōu)、線程數(shù)請求不夠），從而導致上線后大批量用戶在訪問系統(tǒng)造成性能不足形成瓶頸。2、執(zhí)行系統(tǒng)的日志級別沒有調(diào)整，導致后臺一直打印輸出日志，一定程度上影響了系統(tǒng)性能；網(wǎng)絡設備上的性能瓶頸：行業(yè)內(nèi)通俗指的是通過交換機、動態(tài)系統(tǒng)負載均衡器等設備。動態(tài)負載均衡器：在動態(tài)負載平衡器上建立了動態(tài)負載分配機制。當發(fā)現(xiàn)某個應用服務器上的資源已達到限制時，動態(tài)負載平衡器會將后續(xù)的操作單元請求發(fā)送給其他負載較輕的應用服務器。

在測試中，發(fā)現(xiàn)動態(tài)負載均衡器沒有起到相應的作用，可以考慮網(wǎng)絡瓶頸。交換機：網(wǎng)絡的傳輸量，信息吞吐量，傳輸速度等，在進行并發(fā)操作時對網(wǎng)絡吞吐量要求高，特別是導入的并發(fā)執(zhí)行，1s內(nèi)會存在幾百兆的下載上傳的數(shù)據(jù)量，而交換機是百兆網(wǎng)口的情況下，會導致傳輸速率慢，從而不能正常模擬出系統(tǒng)真實的性能情況；

5.2用LoadRunner進行性能測試測試環(huán)境：表5-2-1測試服務器端配置

類型設備參數(shù)應用服務器硬件環(huán)境數(shù)量(臺)1CPU類型InterXeonE5-2630v4@2.20Ghz（4處理器）16核物理內(nèi)存(G)32G本地存儲1T網(wǎng)絡接口千兆網(wǎng)卡1000Mbp/s軟件環(huán)境操作系統(tǒng)及版本W(wǎng)indowServer2012R2Standard64bitJVM參數(shù)-Xms4096m–Xmx8096m服務名浙江交工綜管系統(tǒng)正式環(huán)境應用服務文件路徑D:\vproject\zjjg_rel表5-2-2數(shù)據(jù)庫服務器端配置數(shù)據(jù)庫服務器類型設備參數(shù)硬件環(huán)境數(shù)量（臺）1CPUInterXeonE5-2630v4@2.20Ghz（4處理器）16核物理內(nèi)存(GB)24G本地存儲1THBA卡（塊）0網(wǎng)絡接口千兆網(wǎng)卡1000Mbp/s軟件環(huán)境操作系統(tǒng)及版本W(wǎng)indowServer2012R2Standard64bit數(shù)據(jù)庫及版本Oracle11g表5-2-3客戶端服務器配置客戶端（1臺）硬件環(huán)境客戶端配置CPU：AMDRyzen54600U2.1Ghz內(nèi)存：16GB硬盤：1T其他：

軟件環(huán)境操作系統(tǒng)：Win1064bit瀏覽器：Chrome84測試工具：Loadrunner125.2.1測試步驟與展示Step1：代理服務器準備由于lr12錄制本質(zhì)上是通過捕獲請求然后轉化成相應請求代碼的，所以我們首先得捕獲請求，這里就用到Fiddler抓包工具，把它當做一個本機的代理服務器，通過端口指定并轉發(fā)到lr12進行捕獲在StartRecording設置界面點擊RecordingOptions，選擇Network—>PortMapping添加配置（如圖）注：trafficforwarding端口與fiddler監(jiān)聽端口保持一直Step2：錄制并發(fā)登錄腳本 1）啟動VirtualUserGenerator——>點擊左上角“File”——>選擇“NewScriptandSolution”,找到HTTP協(xié)議，進入主界面； 2）點擊圖中圓點錄制按鈕，然后再URLaddress輸入客戶端ip地址和存放腳本的文件路徑，點擊StartRecoding就能開始錄制了；3）錄制完腳本后，我們還要對腳本進行調(diào)優(yōu)和參數(shù)化的設置代碼如下：lr_rendezvous("login_rev");//集合點設置

lr_start_transaction("login");//登錄事務開始web_submit_data("module-operation!executeMultiOperation_13",

"Action=http://xx.xx.xx:1234/module-operation!executeMultiOperation?randomId=0.825345354521178&_request_validate_token_=53573",

"Method=POST",

"RecContentType=application/json",

"Referer=http://xx.xx.xx:1234/module-operation!executeOperation?componentCode=iems_login&windowCode=index",

"Snapshot=t47.inf",

"Mode=HTML",

ITEMDATA,

"Name=ajaxRequest",

"Value=true",

ENDITEM,

"Name=scopeId",

"Value=880ddac59bba8582ed71719f4be35a9e",

ENDITEM,

"Name=componentCode",

"Value=vbase_prdbizframe",

ENDITEM,

"Name=windowCode",

"Value=TR_BG_Action_FrameWindow",

ENDITEM,

"Name=token",

"Value="

"%5B%7B%22data%22%3A%7B%22operation%22%3A%22WinPerm%22%2C%22componentCode%22%3A%22vbase_prdbizframe%22%2C%22windowCode%22%3A%22TR_BG_Action_FrameWindow%22%2C%22moduleId%22%3A%22TR_BG_Action_FrameWindow%22%2C%22transaction_id%22%3Anull%7D%7D%2C%7B%22data%22%3A%7B%22operation%22%3A%22Permission%22%2C%22componentCode%22%3A%22vbase_prdbizframe%22%2C%22windowCode%22%3A%22TR_BG_Action_FrameWindow%22%2C%22moduleId%22%3A%22TR_BG_Action_FrameWindow%22%2C%22transaction_id%22%3Anull%2C%22isAllWidget%22%3Atrue"

"%7D%7D%5D",

ENDITEM,

EXTRARES,

"Url=/itop/vjs/combo/static/297e51fc73093aae01730e213707381d_f331e19a16ce73818c10a14f2b9514c6.js?vjsRequest=true&packageAliases=fB9,fBV,fBW,fBX,fCa,fCb,fCc,fCd,fCe,fCf,fCl,fCn,fUD,fsO,fsQ,fsR,fsS,fsW,fsX,fsY,fsZ&vjsNames=[{%22perty.vbase_prdbizframe.TR_BG_Action_FrameWindow%22:true}]&condition={%22domain%22:null,%22frameworkComponentCode%22:%22toone_mt_projectin_pc_ie%22,%22frameworkInstanceCode%22:%22main%22}",

"Referer=http://xx.xx.xx:1234/"

"module-operation!executeOperation?componentCode=iems_login&windowCode=index",

ENDITEM,

LAST);

web_submit_data("module-operation!executeMultiOperation_14",

"Action=http://xx.xx.xx:1234/module-operation!executeMultiOperation?randomId=0.8071438635468782&_request_validate_token_=32599",

"Method=POST",

"RecContentType=application/json",

"Referer=http://xx.xx.xx:1234/module-operation!executeOperation?componentCode=iems_login&windowCode=index",

"Snapshot=t48.inf",

"Mode=HTML",

ITEMDATA,

"Name=ajaxRequest",

"Value=true",

ENDITEM,

"Name=scopeId",

"Value=880ddac59bba8582ed71719f4be35a9e",

ENDITEM,

"Name=componentCode",

"Value=vbase_prdbizframe",

ENDITEM,

"Name=windowCode",

"Value=TR_BG_Action_FrameWindow",

ENDITEM,

"Name=token",

"Value=%5B%7B%22data%22%3A%7B%22operation%22%3A%22WaterMark%22%2C%22componentCode%22%3A%22vbase_prdbizframe%22%2C%22windowCode%22%3A%22TR_BG_Action_FrameWindow%22%2C%22moduleId%22%3A%22TR_BG_Action_FrameWindow%22%2C%22transaction_id%22%3Anull%7D%7D%5D",

ENDITEM,

LAST);

web_submit_data("module-operation!executeOperation_28",

"Action=http://xx.xx.xx:1234/module-operation!executeOperation?componentCode=vbase_prdbizframe&randomId=0.5555026771752045&_request_validate_token_=30245",

"Method=POST",

"RecContentType=application/json",

"Referer=http://xx.xx.xx:1234/module-operation!executeOperation?componentCode=iems_login&windowCode=index",

"Snapshot=t49.inf",

"Mode=HTML",

ITEMDATA,

"Name=ajaxRequest",

"Value=true",

ENDITEM,

"Name=operation",

"Value=Transaction",

ENDITEM,

"Name=scopeId",

"Value=880ddac59bba8582ed71719f4be35a9e",

ENDITEM,

"Name=transaction_id",

"Value=a9c27674b65e2{random}",

ENDITEM,

"Name=token",

"Value=%7B%22data%22%3A%7B%22transaction_id%22%3A%22a9c27674b65e2{random}%22%2C%22componentCode%22%3A%22vbase_prdbizframe%22%2C%22transaction_action%22%3A%22transaction_begin%22%7D%7D",

ENDITEM,

LAST);

web_submit_data("module-operation!executeOperation_29",

"Action=http://xx.xx.xx:1234/module-operation!executeOperation?componentCode=vbase_prdbizframe&windowCode=&randomId=0.8668021912773864&_request_validate_token_=387907",

"Method=POST",

"RecContentType=application/json",

"Referer=http://xx.xx.xx:1234/module-operation!executeOperation?componentCode=iems_login&windowCode=index",

"Snapshot=t50.inf",

"Mode=HTML",

ITEMDATA,

"Name=ajaxRequest",

"Value=true",

ENDITEM,

"Name=operation",

"Value=ExecuteRuleSet",

ENDITEM,

"Name=scopeId",

"Value=880ddac59bba8582ed71719f4be35a9e",

ENDITEM,

"Name=sourceWindow",

"Value=vbase_prdbizframe.TR_BG_Action_FrameWindow",

ENDITEM,

"Name=transaction_id",

"Value=a9c27674b65e2{random}",

ENDITEM,

"Na