第一篇：軟件測試技術-實驗報告內容格式

課程名稱：《軟件測試技術》

實驗名稱：《使用LoadRunner 進行性能測試》

實驗目標：

1、掌握LR的測試過程；

2、掌握LR中 Visual User Generator（以下簡稱VuGen）、Controller和Analysis三個組件的具體使用。

實驗要求：

采用LR 自帶的HP WEBTours應用程序，進行性能測試。

實驗過程：

1、錄制LR 自帶的HP WEBTours應用程序腳本，錄制內容包括自動進入到WEB TOURS 網站，進行登錄（已經注冊成功），登錄成功后，再定一張票，定票后，輸入信用卡信息，然后退出登錄，完成后，點擊停止錄制；（具體過程自己描述）

2、生成腳本；

（具體過程自己描述）

3、回放腳本；

（具體過程自己描述）

4、插入事件，分別在登錄前和登錄成功后、訂票前和訂票成功后四個位置插入一個事件；

（具體過程自己描述）

5、啟動Controller，配置場景，選擇場景類型為Goal—Oriented Scenario；（具體過程自己描述）

6、生成分析報告。

（具體過程自己描述）

參照《LoadRunner結果分析說明》文檔進行分析，了解系統瓶頸在什么地方，需要改進，實驗完成。

實驗心得：

要求不得少于200字。

第二篇：軟件測試實驗報告

軟件質量保證與測試

2016 ~ 2017學年

第二學期

學

院 計算機科學技術

專

業 軟件工程 學

號

140521221 姓

名 蒲鳳 指導教師王鵬

目錄

一、單元測試.......................................................1 1.1實驗目的......................................................1 1.2實驗環境......................................................1 1.3實驗原理......................................................1 1.4實驗內容......................................................1 1.4.1 C#單元測試................................................1 1.4.2 測試用例..................................................4 1.5實驗結果......................................................5 1.6實驗總結......................................................6 1.6.1插件安裝...................................................6 1.6.2心得體會...................................................6 1.6.3單元測試意義...............................................6

二、LOADRUNNER性能測試.............................................7 2.1實驗目的......................................................7 2.2實驗環境......................................................7 2.3實驗原理......................................................7 2.4實驗內容......................................................7 2.4.1 HP LoadRunner錄制腳本.....................................7 2.4.2 HP LoadRunner腳本測試場景設計及分析......................17 2.5實驗結果.....................................................33 2.6實驗分析.....................................................34 2.7實驗總結.....................................................34

三、反編譯........................................................36 3.1實驗目的.....................................................36 3.2實驗環境.....................................................36 3.3實驗原理.....................................................36 3.4實驗內容.....................................................36 3.4.1 Net Refelector反編譯.....................................36 3.5實驗結果.....................................................40 3.6實驗總結.....................................................41 3.6.1心得體會..................................................41

I 3.6.2 對軟件安全性的看法.......................................41

四、SQL注入.......................................................42 4.1實驗目的.....................................................42 4.2實驗環境.....................................................42 4.2實驗原理.....................................................42 4.3實驗內容.....................................................42 4.3.1 sql注入..................................................42 4.4實驗結果.....................................................52 4.5實驗總結.....................................................54 4.5.1心得體會..................................................54 4.5.2 SQL注入危害..............................................54

五、禪道項目管理的BUG管理模塊使用................................55 5.1實驗目的.....................................................55 5.2實驗環境.....................................................55 5.3實驗原理.....................................................55 5.4實驗內容.....................................................55 5.4.1禪道項目管理的bug管理模塊使用............................55 5.5實驗結果.....................................................67 5.6實驗總結.....................................................68

II

一、單元測試

1.1實驗目的

1.能夠使用編程工具進行單元測試。

2.檢查代碼實現是否符合設計，盡早發現設計和需求中存在的錯誤。3.發現在編碼過程中引入的錯誤，跟蹤需求和設計的實現是否一致。

1.2實驗環境

環境：vs2013

1.3實驗原理

主要采用白盒技術，檢查模塊控制結構的某些特殊路徑，期望覆蓋盡可能多的出錯點。

1.4實驗內容

1.4.1 C#單元測試

1.新建一個類庫項目，并為其中的類為BinaryTree.構建二叉樹并添加前序遍歷方法。如圖1-1所示。

圖1-1 2.創建單元測試。在方法名上右擊，然后單擊“Generate Unit Test”選項，打開對話框。如圖1-2所示。

圖1-2 3.選擇方法，為新建項目命名。如圖1-3所示。

圖1-3 4.然后在解決方案管理中就多了相應的BinaryTree Tests解決方案。如圖1-4所示。

圖1-4 打開測試菜單->窗口->測試資源管理器，如圖1-5所示。

圖1-5 5.在測試試圖，右鍵運行要測試的方法，在測試結果窗口中查看測試結果，運行測試之前。如圖1-6所示。

圖1-6 1.4.2測試用例

1.設置測試參數。如圖1-7，1-8所示。

圖1-7

圖1-8 2.運行之后。如圖1-9所示。

圖1-9 1.5實驗結果

經過測試，ResultEqualTest1，ResultEqualTest2均未通過測試，調整參數，重新測試,測試結果如下，如圖1-10所示。：

圖1-10 1.6實驗總結

1.6.1插件安裝

在vs2013進行單元測試之前，需要按照手動添加插件。選擇工具-擴展和更新，搜索并安裝Unit Test Generator。1.6.2心得體會

本次測試設計涉及預期測試需求，實驗結果符合預期。單元測試幫助開發人員編寫代碼，提升質量，減少bug；提升反饋速度，減少重復工作，提高開發效率；保證最后的代碼不會破壞之前的代碼功能，同時讓代碼維護更容易，有助于改進代碼質量和設計。1.6.3單元測試意義

單元測試集中注意力與程序的基本組成部分，首先保證每個單元測試通過，才能使下一步把單元組成部分組裝成部件并測試其正確性具有基礎。單元是整個軟件的構成基礎，只有保證零部件一樣，這個設備的質量才有基礎，單元的質量也是整個軟件質量的基礎。因此，單元測試的效果會直接影響到軟件的后期測試，最終在很大程度上影響到產品的質量。同時，單元規模較小，復雜性較低，因而發現錯誤后容易隔離和定位，有利于調試工作。

二、LoadRunner性能測試

2.1實驗目的

1.掌握LoadRunner的使用方法。2.能夠使用LoadRunner進行負載測試

3.學會用LoadRunner設計場景并嘗試，并分析測試結果。

2.2實驗環境

環境：HP LoadRunnner

2.3實驗原理

LoadRunner進行負載測試通常有五個階段組成：

計劃、腳本創建、場景定義、場景執行和結果分析。

(1)計劃負載測試：定義性能測試要求，例如并發用戶的數量、典型業務流程和所需相應時間。

(2)創建Vuser腳本：將最終用戶活動捕獲到自動腳本中。(3)定義場景:使用LoadRunnerControlller設置負載測試環境。(4)運行場景：通過LoadRunnerControlller驅動、管理和監控負載測試。(5)分析結果：使用LoadRunnerAnalysis創建圖和報告并評估性能。

2.4實驗內容

2.4.1HP LoadRunner錄制腳本

1.啟動服務。如圖2-1所示。

圖2-1 2.登錄自帶網站WebTours，并注冊。如圖2-2所示。

圖2-2 填寫注冊信息，如圖2-3，2-4所示。

圖2-3

圖2-4 注冊成功，如圖2-5所示。

圖2-5

3.打開Loadrunner，點擊新建腳本打開VuGen。如圖2-6所示。

圖2-6 新建腳本，如圖2-7所示。

圖2-7

4.新建腳本，選擇協議。如圖2-8所示。

圖2-8 5.選擇瀏覽器，設置所測web的地址。如圖2-9所示。

圖2-9 6.點擊左下角Options按鈕，進入錄制環境設置界面。如圖2-10，2-11所示。

圖2-10

圖2-11

7、模擬用戶操作開始錄制腳本。如圖2-12所示。

圖2-12 用戶操作如下，模擬用戶訂票。如圖2-13所示。

圖2-13 8.結束錄制，生成腳本。如圖2-14所示。

圖2-14 9.回放腳本，驗證腳本是否正確。如圖2-15所示。

圖2-15 回放結果，如圖2-16所示。

圖2-16 10.增加事務，并命名。如圖2-17所示。

圖2-17 給事務命名，如圖2-18所示。

圖2-18 查看事務，如圖2-19所示。

圖2-19 11.參數化。在腳本中找到需要參數化的值，例如登錄名和登錄密碼。如圖2-20所示。

圖2-20 2.4.2HP LoadRunner腳本測試場景設計及分析

1.導入腳本，打開controller。如圖2-21所示。

圖2-21 2.選擇文件路徑。如圖2-22所示。

圖2-22 3.進入初始界面。如圖2-23所示。

圖2-23 4.為了設置集合點，取消默認勾選框，添加腳本。如圖2-24所示。

圖2-24 5.確定，進入場景設置界面。如圖2-25所示。

圖2-25 6.設置場景，選擇初始化。如圖2-26所示。

圖2-26 7.打開運行時設置，設置迭代次數。如圖2-27所示。

圖2-27 8.設置迭代參數為2。如圖2-28所示。

圖2-28 9.點開Miscellaneous,設置Continueon error，使錯誤發生時可繼續執行。如圖2-29所示。

圖2-29 10.設計集合點。如圖2-30所示。

圖2-30 設置當所有虛擬用戶都到達集合點才釋放，模擬多用戶同時進行某一操作的情況。選中policy。如圖2-31所示。

圖2-31 11.設置policy。如圖2-32所示。

圖2-32 12.點擊運行，進入運行時監控界面。如圖2-33所示。

圖2-33 13.點擊運行場景。如圖2-34所示。

圖2-34 14.觀察運行結果。如圖2-35，2-36，2-37，2-38，2-39所示。

圖2-35

圖2-36

圖2-37

圖2-38

圖2-39 15.設置場景運行時Windows資源監控圖。如圖2-40所示。

圖2-40 點擊添加。如圖2-41，2-42所示。

圖2-41

圖2-42 運行時Windows資源監控圖截圖如下。如圖2-43所示。

圖2-43 16.打開分析器，形成分析結果。如圖2-44，2-45所示。

圖2-44

圖2-45 17.分析器自動形成分析結果。如圖2-46，2-47，2-48，2-49，2-50所示。

圖2-46

圖2-47 18.點開監控的圖表，根據需要合并圖表以便更好地分析。

圖2-48

圖2-49

圖2-50 19．添加Windows資源監控圖表。如圖2-51，2-52所示。

圖2-51

圖2-52 20.添加頁面分析結果圖表。如圖2-53所示。

圖2-53 21.生成測試報告。如圖2-54所示。

圖2-54 生成測試報告中。如圖2-55所示。

圖2-55 生成測試報告，如圖2-56所示。

圖2-56 2.5實驗結果

回放驗證。如圖2-57所示。

圖2-57

生成測試報告，點擊內容，如圖2-58所示。

圖2-58 2.6實驗分析

通過測試報告可以看出，最多能夠創建10個vuser，平均吞吐量是14320字節每分，平均每秒點擊數量約為10次。同時可以通過以下方式使被測系統所受壓力減輕,從如下方面進行綜合調解:將測試腳本中think time值加大并在控制臺中按比例實現,此處think time指在transaction外部的時間；Controller中Run-Time Setting的Pacing設置值加大；虛擬用戶登錄時使用遞增策略，間隔稍長。

2.7實驗總結

LoadRunner，是一種預測系統行為和性能的負載測試工具。通過以模擬上千萬用戶實施并發負載及實時性能監測的方式來確認和查找問題，LoadRunner能夠對整個企業架構進行測試。企業使用LoadRunner能最大限度地縮短測試時間，優化性能和加速應用系統的發布周期。LoadRunner可適用于各種體系架構的自動負載測試，能預測系統行為并評估系統性能。學會了使用LoadRunner錄制腳本。基本的流程是啟動服務器、注冊、錄制腳本及進行參數化設置。設計涉及場景的搭建和測試，通過Lordrunner進行腳本測試，同時能夠生成相應的圖表，直觀的反應了測試結果。Lordrunner作為專業的性能測試工具,通過模擬成千上萬的用戶對被測應用進行操作和請求,在實驗室環境中精確重現生產環境中任意可能出現的業務壓力,然后通過在測試過程中獲取的信息和數據來確認和查找軟件的性能問題,分析性能瓶頸。

三、反編譯

3.1實驗目的

1.學會如何使用反編譯工具對程序進行反編譯。2.能夠使用.NetRefelector進行反編譯。

3.2實驗環境

環境：.Net Refelector,VS2008 3.3實驗原理

反編譯的主要思想：將特定的機器代碼，即我們的“源程序”，先翻譯為低級的中間代碼，然后再根據特定的高級語言將中間代碼翻譯為高級程序。反編譯器也有前端和后端。前端是一個機器依賴的模塊，句法分析二進制程序、分析其指令的語義、并且生成該程序的低級中間表示法和每一子程序的控制流向圖。通用的反編譯機器是一個與語言和機器無關的模塊，分析低級中間代碼，將它轉換成對任何高級語言都可接受的高級表示法，并且分析控制流向圖的結構、把它們轉換成用高級控制結構表現的圖。最后，后端是一個目標語言依賴的模塊，生成目標語言代碼。反編譯的過程中要使用一些工具：把二進制程序裝入內存，對這一程序做句法分析或反匯編，以及反編譯或者分析該程序來生成高級語言程序。這個過程借助編譯器和庫的簽名來識別特定的編譯器和庫子程序。只要在二進制程序中識別出編譯器簽名，就不去反編譯這些編譯器啟動代碼(start-up)和庫子程序：對于前者，從最后的目標程序去掉啟動代碼的那些例程，反編譯器從主(main)程序入口點開始分析；對于后者，那些子程序用其庫函數名代替。

3.4實驗內容

3.4.1Net Refelector反編譯

1.啟動.NETRefelector(在所有程序中找到RedGate文件夾)找到安裝文件，點擊運行。如圖3-1所示。

圖3-1 2.選擇文件，打開可執行文件。如圖3-2所示。

圖3-2 選擇文件路徑。如圖3-3所示。

圖3-3

3.導入工程截圖如下。如圖3-4所示。

圖3-4 4.相關函數和類，如圖3-5所示。

圖3-5 5.選中工程，導出源碼。如圖3-6所示。

圖3-6 6.選擇導出文件路徑。如圖3-7所示。

圖3-7 7.選中反編譯程序，點擊運行。如圖3-8所示。

圖3-8 3.5實驗結果

反編譯成功，如圖3-9所示。

圖3-9

3.6實驗總結

3.6.1心得體會

本次實驗通過反編譯工具進行了反編譯，完成了從可執行文件到源碼的轉換，學會了如何使用.NET Refelector反編譯工具。3.6.2 對軟件安全性的看法

軟件安全（Software Security）就是使軟件在收到惡意攻擊的情形下依然能夠繼續正確運行及確保軟件被在授權范圍內合法使用的思想。軟件安全性分析任務包含于軟件生存周期的若干活動中，是針對軟件的安全性質量，作為這些活動的補充。軟件安全性分析作為開發中軟件的質量的重要保證，關系到軟件的獲取、供應、開發、運行和維護，已得到專業人士的高度重視。并且現在，軟件安全性分析任務的各項細節執行都寫入了國軍標，被安全相關軟件的需方、供方、開發者、維護者以及獨立的評價者使用。規范化將推進軟件安全性分析的進程，使更多的開發和評測單位遵循標準化文件，督促開發團隊采取相應的技術手段，以軟件測試作為輔助。同樣，軟件安全性分析標準也會在推進的過程中，得到不斷地發展。

四、SQL注入

4.1實驗目的

1.明白SQL注入原理。2.能夠進行簡單的SQL注入。

4.2實驗環境

環境：VS2013，SQL Server Management Studio 4.2實驗原理

SQL注入即是指web應用程序對用戶輸入數據的合法性沒有判斷，攻擊者可以在web應用程序中事先定義好的查詢語句的結尾上添加額外的SQL語句，以此來實現欺騙數據庫服務器執行非授權的任意查詢，從而進一步得到相應的數據信息。

4.3實驗內容

4.3.1 sql注入

1.點擊SQL SERVERR２。如圖4-1所示。

圖4-1 登陸數據庫，如圖4-2所示。

圖4-2 ２.創建數據庫SQLTEST。如圖4-3，4-4所示。

圖4-3

圖4-4 ３.創建表UserLogin。如圖4-5所示。

圖4-5 設置主鍵如下，如圖4-6所示。

圖4-6 設置成功，截圖如下。如圖4-7所示。

圖4-7 輸入表名。如圖4-8所示。

圖4-8 4.選中表，編輯前200行。如圖4-9所示。

圖4-9 5.編輯測試數據，如圖4-10所示。

圖4-10 6.打開VS2013，新建項目。如圖4-11所示。

圖4-11 選中Asp.net Web應用程序。如圖4-12所示。

第三篇：《軟件測試技術》課程總結報告

《軟件測試技術》課程總結報告

班級：姓名：學號：

一、課程概述

二、課程實訓項目

三、課程知識點總結

四、收獲和體會

第四篇：軟件測試技術面試總結

軟件測試就是為了發現程序中的錯誤而分析和執行程序的過程。——概念

+基本知識+軟件開發過程-定義-計劃-實現-穩定化-部署

+軟件開發模型(四種典型的模型)

+瀑布模型

-概述：包括計劃，需求分析，設計，編碼，測試，運行維護六個階段。六個階段自上而下、相互銜接，以固定的次序進行。

-特點：1.階段的順序性和依賴性；2.文檔驅動； 3.推遲實現的觀點；4.質量保證。-缺點：不適合需求模糊的系統

+原型模型-概述：先建立一個能夠反映用戶需求的原型系統，使得用戶和開發者可以對目標系統的概貌進行評價和判斷，然后對原型系統進行反復的擴充、改進、求精，最終建立符合用戶需求的目標系統。

-特點：1.快速開發工具；2.循環； 3.低成本。

-分類：按照對原型的處理方式，可以分為漸進型和拋棄型。

+增量模型

-概述：在增量模型中每個階段都生成軟件的一個可發布版本，階段交錯進行，版本逐漸完善。

-同原型模型的最大區別在于，在原型模型中每個階段發布一個原型而在增量模型中則完成一個正式版本。+螺旋模型

-概述：適用于大型軟件的開發，它將瀑布模型和快速原型模型結合起來，并加入了風險分析。

-特點：1.每個階段都包括制定計劃，風險分析，實施工程，評審四個階段；

2.開發過程迭代進行，每迭代一次螺旋線增一周，工程前進一個層次，系統生成一個新版本，投入新的時間成本，最終得到客戶滿意的版本。

-軟件測試從需求開始：現代的軟件測試將測試滲入到軟件開發的各個階段，即使瀑布模型，表面看測試工作是在測試階段開始的，事實上，在計劃、需求、設計階段，測試人員便已經開始了他們的工作，如：了解軟件需求，編寫測試計劃，搭建測試環境。

-測試用例

-三要素：前提條件和操作步驟、預期結果、實際結果。

-必須以需求為依據。

-軟件測試分類

-是否關注軟件結構和算法

-黑盒測試：基于軟件需求的測試方法。

-白盒測試：基于軟件內部設計和程序實現的測試方法。

-是否執行被測試軟件

-動態測試：在測試過程中執行被測試軟件的測試方法。

-靜態測試：------------不----------------------。

-基于不同的測試階段：

-單元測試：主要測試軟件的單元模塊，需要編寫額外的測試驅動程序，采用白盒測試的方法，一般由 開發人員完成。

-集成測試：將一些“構件”集成在一起時測試他們是否能正常運行，構件可以是程序模塊，也可以是

客戶機-服務器程序等，需要編寫測試仿真程序，采用白盒和黑盒相結合的方式，通常由 開發人員承擔。

-系統測試：測試軟件系統是否符合所有的需求，包括功能性測試和非功能性測試。一般由

獨立的測試

人員完成，通常采用黑盒測試方法。

-驗收測試：(α、β)與系統測試類似，但由客戶或最終用戶執行，測試軟件是否符合需求規格說明書。

-回歸測試：指在軟件開發過程中，每次錯誤被修正后或軟件的功能、環境發生變化后進行的測試。

-軟件測試的三個步驟：

-測試計劃：測試人員首先對需求進行分析，最終定義一個測試集合，通過刻畫和定義測試發現需求中的問題，然后根據軟件需求同測試主管制定并確認“測試計劃”。

-測試設計和開發：軟件測試人員根據軟件需求和軟件設計說明書完成測試用例的設計和必要的測試驅動 程序的開發。

-執行測試：需要做的工作包括搭建測試環境、運行測試、記錄測試結果、報告軟件缺陷、跟蹤軟件缺陷、分析測試結果，必要時進行回歸測試。

-測試工程師的能力要求：

+5C

-Controlled /kEn'trEuld/ 接受管理，有條理的-Competent /'kCmpitEnt/了解正確的測試技術

-Critical /'kritikEl/專注于發現問題

-Comprehensive /.kCmpri'hensiv/ 注意細節

-Considerate /kEn'sidErit/能夠和開發人員很好的交談

+職業素質-責任心-學習能力-懷疑精神-溝通能力-專注力-洞察力-團隊精神-注重積累 +制定測試計劃的五個步驟：-分析和測試軟件需求-定義測試策略

-定義測試環境

-定義測試管理

-編寫和審核測試計劃

如果在需求分析階段發現并結果問題需要花費$1，則在設計階段解決同樣的問題需花費$5，在編碼階段需$10，交付后解決同樣的問題需花費$200。——越早測試越好-在需求分析過程中測試人員需要進行如下工作：

1)理解需求，參與審核需求文檔；

2)理解項目的目標、限制，了解用戶的應用背景；

3)編寫測試計劃；

4)準備測試資源。

+需求測試

-需求測試測試的對象是主意而不是代碼，針對文檔進行測試。

+好的需求文檔的特征-具有清晰的格式和文檔結構-需求的內容正確-需求的內容完整-需求具有可行性需求的必要性

-對不同的需求優先等級進行定義-描述明確-可證性和可測試性-可修改性-可追蹤-需求文檔被及時更新

+需求測試內容

-需求文檔是否符合公司的格式要求

-是否正確

-要保證需求文檔中所描述的內容是真實可靠的-這是“真正的”需求嗎？描述的產品是否是要開發的產品？

-需求是否完備？第一個發布的版本是否需要更多的功能？列出的需求可以減少一部分？-需求是否兼容？需求有可能是矛盾的。

-需求是否可實現？如：需求設想的設備是否比實際運行的要快？需求要求的內存、I/0設備是否太多？

需求的輸入或輸出設備要求的分辨率是否要求過高？

-需求是否合理？在開發進度、開發費用、產品性能、可靠性和內存使用之間存在著平衡關系。

-需求是否可測？對于軟件測試人員來說判斷需求是否可測是這個過程中最重要的工作。+需求測試方法-復查review-走查walkthrough-審查inspection

+測試策略的內容

-確定測試范圍 軟件是無法被完全測試的-確定測試方法 不同的系統需要不同的測試方法

-定義測試標準 入口標準，暫停和繼續的標準，出口標準等

+軟件測試結束的標準

-基于測試用例的使用規則

1)構造測試用例（由相關人員進行評審）

2)執行測試用例中，當測試用例的不通過率達到20%則拒絕繼續測試，待開發人員修正軟件后再繼續。

3)當功能性測試用例通過率達到100%，非功能性測試用例通過率達到90%時，允許正常結束。

-基于“測試期缺陷密度”規則

--------------含義：對軟件測試一個CPU小時發現的缺陷數，比較適用于系統測試-基于“運行期缺陷密度”規則

--------------含義：把軟件運行一個CPU小時發現的缺陷數，比較適用于驗收測試注：一個階段的出口標準!=下一個階段的入口標準

系統測試結束的標準!=軟件的發布標準

發布標準!=軟件0缺陷

-選擇測試工具 是否需要，需要什么工具，怎么獲取

-降低軟件測試代價是企業普遍關注的問題，可通過

a.減少冗余和無價值的測試；

b.減少測試階段(萬般無奈下)

+測試環境

-基本內容：設備環境、軟件環境、數據環境

-需考慮的因素-計算機平臺-操作系統-瀏覽器-軟件支持平臺-外圍設備-網絡環境-其他專用設備

-搭建測試環境時的配置原則：-使用的頻度或范圍-實效的可能性-最大限度的模擬真實環境 +測試管理 由于測試工程中設計的人員、活動、工具是很多的，在制定測試計劃時需要對這些因素進行管理

-選擇缺陷管理工具和測試管理工具

-定義工作進度

-建立風險管理計劃

+可能遇到的風險

·由于設計、編碼階段出現大量質量問題，導致測試工作量時間增加

·開始測試時所需的硬件、軟件沒有準備好

·未能完成對測試人員的技術培訓

·測試時的人力資源安排不足

·測試過程中，發生了大量的需求變更

·測試過程中，項目的開發計劃被大幅度調整

·不能及時準備好測試所需的環境

·不能及時準備好測試數據

+風險管理的過程

·識別風險

·評估風險

·制定對策

·跟蹤風險

+測試設計與開發

+總體設計

-投入產出：測試設計的輸入是測試計劃，輸出是評審過的測試用例集合-定義設計目標遵循的原則

-清楚地說明沒項測試的目標

-使每項測試的目標單一，可以對應到規格說明書中的一項需求

-只說明測試應該完成什么工作，而不說明如何完成-流程：總體設計-開發測試用例-評審測試用例

I.定義設計目標

II.定義輸入說明

III.定義測試環境和配置

IV.測試設計文檔

V.開發測試用例

+測試用例

-概念：為特定目標開發的測試輸入、執行條件和預期結果的集合。

+好的測試用例：

-容易發現軟件的錯誤

-精確的重復某測試失敗的情景，可重復性

-清晰的定義一個或多個期望的結果

-沒有冗余

+測試用例的作用

-指導測試的實施

-作為編寫測試腳本的“設計規格說明書”

-評估測試標準的度量基準

-分析缺陷的標準

+白盒測試用例設計

+設計方法

+邏輯覆蓋法

-語句覆蓋

-判定覆蓋

-條件覆蓋

-判定-條件覆蓋

-條件組合覆蓋

-路經覆蓋

-基本路經法

+輔助模塊設計

-驅動模塊：相當于被測程序的主程序。接受測試數據，把這些數據傳給被測模塊然后輸出實際測試結果。

-樁模塊：用于調用被測模塊調用的子模塊。可以做少量的數據操作，不需要把子模塊的所有功能都帶進來，但不容許什么都不做。

+黑盒測試用例設計

-等價類劃分法

-邊界值法——“缺陷遺漏在角落里，聚集在邊界上。”

-因果圖法彌補等價類和邊界值法的不足

-錯誤推測法

-測試用例的管理可以通過配置管理工具cvs,vss,ClearCase等實現，以保證測試是可重復的。+常見錯誤分析

-用戶界面問題

·輸入無合法性檢查和值域檢查。

·界面信息不能及時更新，不能正確反映數據狀態，甚至對用戶產生誤導。

·表達不清或過于模糊的信息提示。

·要求用戶輸入多余的本來系統可以自己得到的數據。

·為了得到某個設置或對話框用戶必須做許多冗余的操作，如對話框嵌套太多。·不能記憶用戶的設置或操作習慣，使每次進入系統用戶都需重新操作一次初始環境。·不經用戶確認就對系統或數據進行了重大修改。

-形象類問題

·不符合用戶的操作習慣。如，快捷鍵定義不科學不實用，甚至無快捷鍵。

·不夠專業，缺乏基本知識。

·界面中英文混雜，甚至拼寫錯誤。

·說明書或幫助的排版格式不專業：中英文不對應，標點的半全角問題，沒有排版準則。·界面元素參差不齊，文字不能完全顯示。

－穩定性問題

·不可重現的死機，或不斷申請但不能完全釋放資源，使系統性能越來越低。

·主系統和子系統使用了相同的臨界資源而相互不知道。如：使用相同的類名或臨時文件名、使用同樣的數據庫字段名或登陸帳號。

·不能重現的錯誤，許多與代碼中的未初始化變量有關，有些與系統不檢查異常情況(網絡中斷、內存申請

不成功、長時間無響應等)有關。

-其他問題

·運行時不檢查內存、硬盤空間、數據庫等。

·無根據的假設用戶環境：硬件/網絡情況；有些動態庫；假設網絡隨時都是聯通的。·提供的版本帶病毒。

·提供錯誤的版本給測試組或測試用戶，或程序員與測試組使用不同版本。

·用戶現場開放和修改，又沒有記錄和保留。

·版本中部分內容或接口倒退，或出現版本管理混亂。

·有些選項永遠都是灰的，或有些在該變灰時沒變灰。

+測試用例的評審

-測試或測試組件完全針對的是需求中列出的功能嗎？

-測試組件是否覆蓋了所有的需求？

-有冗余的嗎？

-每個測試步驟都有清楚描述的預期結果嗎？

+優先級

+3級

優先級1：此測試用例必須執行-2：有時間就執行-3：可以不執行

+5級

1：此測試必須通過，否則產品發布存在危險2：在發布前必須執行3：時間允許就執行4：此測試可以在下一次發布或發布后短期內執行5：可以不測試

第五篇：《軟件分析與測試》實驗報告范例.doc

《軟件分析與測試》實驗一：白盒測試實驗報告

一、實驗目的1、通過簡單程序白盒測試，熟悉測試過程，對軟件測試行程初步了解，并養成良好的測試習慣。

2、熟練掌握如何運用基路徑測試方法進行測試用例設計，進行邏輯覆蓋率分析。

二、實驗內容<測試內容的描述>

……

三、實驗原理

白盒測試原理：分析程序的內部邏輯結構，選擇適當的覆蓋標準，設計測試用例，對主要路徑進行盡可能多的測試。白盒測試測試用例一般采用邏輯覆蓋法進行設計。

語句覆蓋：選擇足夠的測試用例，使得程序中每個語句至少都能被執行一次。

判定覆蓋：執行足夠的測試用例，使得程序中每個判定至少都獲得一次“真”值和“假”值。

條件覆蓋：執行足夠的測試用例，使得所有判定中的每個條件至少都獲得一次“真”值和“假”值。

判定/條件覆蓋：執行足夠的測試用例，使得判定中每個條件取到各種可能的值，并使每個判定取到各種可能的結果。

條件組合覆蓋：執行足夠的例子，使得每個判定中條件的各種可能組合都至少出現一次。

路徑覆蓋：路徑覆蓋是相當強的邏輯覆蓋，它保證程序中每條可能的路徑都至少執行一次。

四、實驗步驟：

1、測試程序源代碼

……

2、測試程序流程圖

……

3、測試用例設計

……<要求分別使用語句覆蓋、判定覆蓋、條件覆蓋、判定-條件覆蓋、條件組合測試、路徑覆蓋（及完全覆蓋）方法設計測試用例>

4、測試用例分析

……<比較各種設計方法，給出結論>

五、總結與體會

……

《軟件分析與測試》實驗二：黑盒測試實驗報告

一、實驗目的1、系統地學習和理解黑盒測試的基本概念、原理，掌握黑盒測試的基本技術和方法。

2、通過試驗和應用，要逐步提高和運用黑盒測試技術解決實際測試問題的能力。

二、實驗內容<測試內容的描述>

……

三、實驗原理

黑盒測試原理：不考慮程序的內部結構與特性，只根據程序功能或程序的外部特性設計測試用例。

等價分類法：根據程序的I/O特性，將程序的定義域劃分為有限個等價區段 —“等價類”，從等價類中選擇出的用例，具有“代表性”。應按照輸入條件（如輸入值的范圍，值的個數，值的集合，輸入條件必須如何）劃分為有效等價類和無效等價類。有效等價類，對于程序的規格說明是合理的、有意義的輸入數據構成的集合。無效等價類，對于程序的規格說明，是不合理的，是沒有意義的輸入數據構成的集合。

邊值分析法：選擇等價類的邊緣值作為測試用例，讓每個等價類的邊界都得到測試，選擇測試用例既考慮輸入亦考慮輸出。

決策表：在一些數據處理問題當中，某些操作的實施依賴于多個邏輯條件的組合，即：針對不同邏輯條件的組合值，分別執行不同的操作。最適合描述在多邏輯條件取值的組合所構成的復雜情況下，分別執行哪些不同的動作。

因果圖法：一些程序的功能可以用判定表（或稱決策表）的形式來表示，并根據輸入條件的組合情況規定相應的操作。它是一種利用圖解法分析輸入的各種組合情況，從而設計測試用例的方法，它適合于檢查程序輸入條件的各種組合情況。

四、實驗步驟：

1、測試用例設計

……<要求分別使用等價分類法、方法邊值分析法、因果圖法、決策表設計測試用例>

2、測試用例分析

……<比較各種設計方法，給出結論>

五、總結與體會

……

《軟件分析與測試》實驗三：測試自動化實驗報告

一、實驗目的1、系統地學習和理解測試自動化的基本概念，掌握測試自動化的基本技術和方法。

2、通過試驗和應用，要逐步提高和運用測試自動化工具解決實際測試問題的能力。

二、實驗內容<測試內容的描述>

……

三、實驗環境

在Eclipse集成開發環境中使用JUnit來作為自動化的功能測試工具。Eclipse本身集成了JUnit相關組件，并對JUnit的運行提供了無縫的支持。

JUnit是一個開放源代碼的Java測試框架，用于編寫和運行可重復的測試。他是用于單元測試框架體系xUnit的一個實例（用于java語言）。它包括以下特性：

1、用于測試期望結果的斷言（Assertion）

2、用于共享共同測試數據的測試工具

3、用于方便的組織和運行測試的測試套件

4、圖形和文本的測試運行器

Eclipse 是一個開放源代碼的、基于 Java 的可擴展開發平臺。就其本身而言，它只是一個框架和一組服務，用于通過插件組件構建開發環境。幸運的是，Eclipse 附帶了一個標準的插件集，包括 Java 開發工具（Java Development Tools，JDT）。

四、實驗步驟：

1、測試過程

……

2、測試分析

……

五、總結與體會

……

//注釋：

1、省略號為自定義部分,需要補充完整；

2、<>中內容為說明文字部分；

3、其他文字要求都寫入報告中（包括 注釋1中的內容）。