控制元件測試
- 登錄檔單控制元件
- 使用者名稱文字編輯框
- email文字編輯框
- 密碼文字編輯框
- 確認密碼
- 文字編輯框
- 核取方塊
- 註冊按鈕
- 頁面元素
- 編輯框
- 按鈕
- 圖片/音訊/視訊
- 下拉選單
- 單選按鈕
- 核取方塊
- Flash外掛
編輯框
- 預設焦點
- 輸入長度
- 輸入內容型別（字母、漢字、特殊符號、指令碼程式碼等）
- 輸入格式限制
- 能否貼上輸入
- 能否刪除文字等因素
- 注：測試用例設計方法有等價類、邊界值等
- 隱性需求：是否重名
按鈕
- 預設焦點
- 按鈕檢視
- 按鈕功能
- 指令碼觸發等方面
- HTML中的按鈕屬性：Button、Submit、Reset(判斷其實現方式是否正確，是否能夠觸發相關操作)
<input type="button" value="彈出視窗" onclick="window.open('/test.html'','_blank')">
複製程式碼- Submit是Button最常用的型別，當需要表單資料提交至伺服器時，可利用Submit按鈕，可利用Submit按鈕，自動提交資料資訊。需注意的是，如果程式碼中增加了輸入驗證類的JS指令碼，提交資料時可能出現重複提交資料的缺陷。
input name="Submit" type="submit" vulue="" class="us_Submit_reg">
Reset
複製程式碼- 當頁面資料資訊輸入錯誤或需重新填寫時，可使用Button的“Reset”屬性。測試工程師測試此類按鈕時需關注reset功能是否實現，並且游標位於第一個必填項。
- 除了Button型別需驗證外，還需驗證Button文字描述及UI設計
圖片測試
- 圖片測試包括圖片內容、大小、顯示、Alt屬性、連結等幾個方面內容。
- 圖片內容應該準確表述當前需表述的主題
- 圖片容量大小關乎頁面響應效能，因此應適當降低圖片容量大小，選擇更便於網路傳輸的圖片格式，如：jpg、png等
- 圖片容量大小外，尺寸大小也應當考慮，不能造成整體介面顯示變形，有任何違和感
- 圖片的顯示清晰度、協調性，如果因系統設計了圖片壓縮功能，導致圖片顯示不清晰，則需提出缺陷。
Alt屬性
音訊
- 自動播放功能是否實現
- 音訊檔案是否正確
- 播放外掛能否正常啟動
- 不允許使用者下載音訊檔案，需進行音訊連結安全性測試
視訊
- 與音訊類似
- 播放控制元件
- 播放外掛
- 連結安全性
- 視訊的壓縮格式
- 資料緩衝情況
下拉選單
- 下拉選單在多元化的資料資訊展示傳輸過程中經常被用到，在測試過程中需關注其列表值是否正確，是否有重複，選中後是否正確傳遞、是否可以多選等方面
- 某些下拉選單中的資料來源於其他功能，測試時需要考慮功能間的耦合及先後邏輯關係（例:該類別下存在商品，是否允許刪除，是否有提示）
單選按鈕
- 實現多選一功能
- 單選按鈕是否有預設設定以及選中後能否儲存資料
核取方塊
- 當需要選中多個資料時，需使用核取方塊
- 多選功能是否能夠實現
- 批量設定
- 批量刪除
- 能否提交請求
- 觸發應該觸發的指令碼程式碼
Flash外掛
- 或其他應用程式外掛與使用者進行互動
- 需考慮單獨功能的實現情況
- 以及其與應用系統的介面能否正確傳遞引數，保證業務流程的正確性
- 單個邏輯功能測試時，需考慮的因素較多，因為無法確切模擬終端使用者的業務活動，僅能儘可能地模擬它們，降低系統釋出後出錯的可能性
連結測試
- 對頁面連結功能，測試工程師需要考慮其連結文字描述正確性、連結地址跳轉正確性、連結觸發指令碼正確性、是否存在404錯誤等
- 如小型Web系統，連結較少，人工測試即可，如果被測試物件包含很多連結，則可利用Xenu連結測試工具進行
- Xenu是測試工程師應用較多的連結測試工具，小巧、便捷。可以對本地網頁檔案測試連結，也可以輸入任何公網網站進行測試。測試完成後自動生成測試報告，如果連結存在錯誤，Xenu用紅色顯示。
快取測試
- 根據Web系統體系架構不同，在系統開發過程中可能採用Cookie、Session、Cache等方法來優化、處理資料資訊
- Cookie
- 當使用者訪問一個Web系統後，伺服器為了在下一次使用者訪問時，判斷該使用者是否為合法使用者、是否需要重新登入，或者希望客戶端記錄某些資料資訊時，可設計Cookie以某種具體的資料格式記錄在客戶端硬碟中
- 通常情況下，Cookie可記錄使用者登入狀態，伺服器可保留使用者資訊，在下一次訪問時可顯示該使用者上一次訪問時間，對於購物類網站，也可以利用Cookie實現購物車功能
- 進行Cookie測試時需關注Cookie資訊的正確性（伺服器給出資訊格式），當使用者主動刪除Cookie資訊後，再次訪問時，驗證能否無須重新登入。電子商務類網站可新增商品資訊後刪除Cookie，重新整理後檢視購物車中商品能否成功清除。
- Session
- Session為會話，在web系統中表示一個訪問者從發出第一訪問者從發出第一個請求到最後離開服務，這個過程維持的通訊對話時間。
- 當然，Session除了表示時間外，還可能根據實際的應用範圍包含使用者資訊和伺服器資訊。
- 當某個使用者訪問Web系統時，伺服器將在伺服器端為該使用者生成一個Session,並將相關資料記錄在記憶體或檔案中，某個週期後，如果使用者未做任何操作，則伺服器將釋放該Session。為了識別每個用會話，伺服器生成Sessionid來標識
- 從安全性角度考慮，使用者使用軟體系統進行操作時，除了需提供正確的賬號資訊外，還可能需要提供正確的Sessionid,伺服器將會對賬號及Sessionid進行驗證。以QQ郵箱為例，使用者登入成功後，伺服器將會產生一個sid來保證該使用者的安全性。如果登入郵箱後，瀏覽器記錄了該連結，關閉瀏覽器後重新開啟該連結時，因為伺服器端分配的sid已經變更，伺服器將拒絕該訪問，需重新登入，以此來保證安全性。
- Cache
- Web系統將使用者或系統經常訪問或使用的資料資訊存放在客戶端Cache（快取）或伺服器端Cache中，以此來提高響應速度。與Cookie和Session不同，Cache是伺服器提供的響應資料，為了提高響應速度，存放在客戶端或伺服器端。
- 使用者發出請求後，首先根據請求的內容從本地讀取，如果本地存在所需的資料，則直接載入，減輕伺服器的壓力，若本地不存在相關資料，則從伺服器的Cache中查詢，若還不存在，則進行進一步的請求響應操作。
- 很多時候，伺服器用Cache提高訪問速度，優化系統效能。在web系統前端效能測試時，需關注Cache對測試結果的影響。
- 當網頁訪問以後，客戶端將儲存相關的資料資訊，再次訪問時，瀏覽器首先判斷本地是否有待請求的資料，如果有，則直接讀取，不再從伺服器獲取。
指令碼功能
使用者進行相應的輸入操作後，能否觸發輸入合法性判斷的JavaScript指令碼
檔案上傳下載
- 業務系統中可能會使用一些檔案上傳下載的控制元件
- 測試時需要考慮檔案上傳格式、上傳內容、上傳後能否正常開啟、上傳過程中如果出現異常是否有資訊提示。
- 對於檔案下載則需考慮下載的檔案能否正確開啟使用、下載過程中能否中斷、中斷後可否續傳、下載儲存的檔名是否正確等。
- 此類控制元件會使用比較成熟的功能元件，因此測試難度相對較小
- 如果上傳完成後存在預覽功能，測試預覽是否實現，並且預覽的圖片是否清晰，軟體系統如果對上傳的圖片進行壓縮，測試需要保證壓縮後的照片清晰可用，如果碰到App將圖片壓縮後清晰度不夠，導致無法通過系統驗證，需重試很多次才符合，這樣的實際對使用者來說是極其糟糕的。
表格測試
- 資料顯示
- 使用者與系統的互動資訊，很多時候通過資料形式記錄在資料庫中，通過邏輯程式碼處理，以表格形式展示相關資訊，使用者增加、修改、刪除以及查詢資料的最終結果都體現在表格上，因此驗證資料顯示的正確性是表格測試的核心
- 資料顯示主要涉及標題欄、資料內容、字元編碼、列寬等幾方面
- 標題欄應該與產品需求/DEMO設計相同，字型設計一致，排序需遵從使用者習慣確定，如果系統有增強資料的功能，則標題欄的內容、順序應與增加介面的佈局相同
- 現在的系統（管理資訊系統Management Information System）
- 顯示順序是否一致。
- 資料內容
- 表格顯示格式確定後，需驗證資料內容是否正確，如果“名稱”與內容不相符，則為很嚴重的缺陷，檢查資料，尤其是通過欄位名稱跳轉到新頁面的資料資訊，可開啟該商品的詳細資訊，在測試過程中需仔細校對資料正確性。
- 字元編碼一般跟程式程式碼有關，可能由於瀏覽器編碼設定錯誤，導致亂碼。
- 例：由於FireFox瀏覽器編碼改為簡體中文，導致資料顯示亂碼，將瀏覽器重新設定為Unicode格式後顯示正常，測試工程師在執行測試時，需確認是由於瀏覽器編碼原因導致亂碼錯誤，還是因為程式程式碼字符集設計錯誤導致亂碼。
- 例：有時候亂碼錯誤可能是因為資料匯入資料庫時造成的錯誤，以Mysql資料庫偽列，執行SQL匯入時，如果不進行匹配的字符集設定，可能導致亂碼，這種情況一般是環境搭建問題，與程式程式碼無關，設定好資料庫字符集格式即可。
- （瀏覽器問題導致亂碼不提交缺陷）
- （如果資料庫顯示是正確的而瀏覽器顯示是亂碼）
- （往資料庫到資料時產生的錯誤則是環境搭建問題）
- 列寬
- 列寬設定不合理將會導致表格介面顯示錯亂，或者當前列表資料內容較多時，會導致頁面被撐開，從而導致介面顯示錯誤，這種情況下，需測試系統是否具有自適應功能，當資料超過介面定義的邊界時自動擷取或收縮，如果沒有自適應功能，則具體情況具體分析，但必須保證介面顯示美觀
- 自動擷取，顯示固定列寬，解決介面被撐開、顯示錯亂的現象
- 單行容納20個漢字，但在19個漢字換行，第二行僅有1個字，（1）建議加大列寬，（2）UI美化（僅建議）
- 翻頁
- 翻頁功能是絕大多數表格應該用到的功能，通常有第一頁、最後一頁、上一頁、下一頁、跳轉到第幾頁等，這類功能測試根據字面意思測試即可，跳轉功能這可能根據文字編輯框的測試方法進行，輸入非數字、輸入單引號等
- 有些翻頁功能設計時，次頁顯示的第一條資料是前一頁的最後一條資料，設計如此，並非缺陷，測試工程師在測試時應當與開發工程師確認。
- 附加功能
- 表格中有時候會提示檢視、增加、修改、刪除資料以及設定每頁顯示多少條資料的功能，測試工程師應當逐個測試，以確保每項功能正確。
- 檢視資料
- 不同的設計方法，提供了不同的功能，有些表格通過記錄名稱開啟資料詳細資訊，有些則通過功能按鈕開啟資料詳細資訊，無論哪種，需確保資料資訊的正確性，這類測試如有條件，可連線資料庫通過SQL語句直接查詢相關資料，與介面資料資訊進行對比測試。
- 增加資料
- 測試增加資料功能時，點選‘增加’按鈕，如果是彈出視窗，則表格資料資訊不應當重新整理，在新的介面中新增相關資料，新增完成返回時，介面應當全部或區域性重新整理，顯示新增加的資料。
- 如果新增加的資料未能出現在列表中，首先應當確認該資料是否應該顯示在當前頁面，如果是，再檢查是否是因為瀏覽器快取問題導致頁面重新整理錯誤，最後驗證資料庫是否存入成功資料。
- 修改資料
- 很多產品在設計修改功能時，要求將原來的資料讀取出來，這點與根據產品設計確定。如果需讀出原資料，測試工程師需確認原資料讀取是否正確，其他測試方法與增加資料類似。
- 修改資料時，有些欄位是不可重新編輯的，如系統自動生成的id號，或者分配的流水號，貸款申請單號等，如果進入修改頁面，這些資料處於可編輯狀態，無論是否能真正編輯，應提交缺陷。
- 修改資料時的必填項設定應該與增加資料設定一致
- 修改資料具有一定的破壞性，因此資料修改操作在提交時應該給予資訊提示，提示資訊應與產品需求一致
- 修改資料需考慮資料鎖定問題，即資料被其他使用者或操作開啟時，該資料不可編輯（修改或刪除），以保證資料的一致性與安全性。
- 刪除資料
- 刪除資料最具破環性，在執行刪除資料操作前，系統應當給與提示，如有必要可進行二次確認，如果使用者放棄刪除操作，則列表不應當重新整理，如果使用者確認執行刪除操作，刪除操作完成後，列表進行重新整理，已刪除的資訊不應當出現。
- 刪除資料與修改資料一樣，同樣需考慮資料鎖定問題，使用者在開啟某條記錄時，其他使用者或操作不可進行修改或刪除操作。常用的一個測試方法是具有許可權的兩個使用者同時開啟某條記錄，A使用者先執行刪除操作，B使用者再執行修改操作，驗證被測物件的處理方式。
- 已商城為列:後臺管理分別利用兩個瀏覽器登入後，選擇某個商品類別進行修改及刪除操作。先刪除類別，再進行修改，商城提示修改i成功，但返回列表時，該類別並不存在，這種情況測試工程師應當提出缺陷，因為使用者在實際應用過程中可能會出現類似衝突的問題，系統應當給與合理的處理與提示。
- 設定每頁顯示條數
- 與跳轉功能一樣，需測試合法輸入與非法輸入的情況，其他根據需求定。
查詢測試
- 查詢功能極大的方便了使用者根據條件檢索所需的資料，通過不同條件的組合，得到不同價值的資料。
- 條件組合
- 查詢通常至少包括2個以上的查詢條件，包括商品分類、商品品牌、商品型別、供貨商型別、商品狀態、關鍵字等
- 設計測試用例方法（正交實驗法）
《軟體測試技術基礎教程--理論、方法與工具》
- 需單獨測試，即“商品類別”與“商品品牌”應當聯動，“商品類別”發生變化後，“商品品牌”中的資料應當變化
- 結果顯示
- 查詢結果顯示與表格測試一樣，根據查詢出來的結果判斷查詢是否正確。
- 測試過程中需考慮條件與條件間的邏輯關係，不同的系統對模糊查詢的界定不同，需進一步確認
經驗積累
- 功能設計
- 資訊提示
- 系統互動
- 容錯處理
- 資料邊界
- 使用者使用習慣或約定俗成的規則
- 功能冗餘（功能越多出錯率越高）
- 功能誇大（結合系統DEMO、宣傳頁、使用者手冊及使用者需求進行多重驗證，以判斷是否存在誇大現象
- 功能過度（任何系統設計，越簡潔越好）
- 功能無用（為了實現功能而實現功能）
- 功能錯誤
- 功能缺失（要實現確未實現的功能）
- 提示錯誤（提示無法指導當前的操作）
- 提示費解（使用者不能根據提示資訊找出錯誤位置及錯誤原因）
- 提示冗餘
- 選單錯亂（相同類別的選單應該在同一目錄，查詢與替換功能應該在一起）
- 不可退出（一些指令碼錯誤出現後，無論確定還是取消，都無法退出當前狀態，只能強制關閉程式
- 無限等待（載入預告時間，長時間給與一個大概的時間預告）
- 多重游標（）
- 輸入限定（系統應當對超限輸入做出明確的禁止）
- 輸出限定（小數點保留幾位，是否應該有個規則說明，多餘的資訊則以摺疊方式展示或過濾掉）
- 錯誤恢復（異常的故障出現，系統能否恢復到故障前的狀態，也是系統健壯性的重要表現。
- 異常呼叫（系統與系統間的呼叫，更要保證資料及邏輯的正確性）
- 軟體邊界
- 硬體邊界（記憶體使用率已經99%了，系統還能執行嗎？磁碟已經沒有空間了，還需要寫日誌怎麼辦？）
- 時間邊界（系統等待過程中，是否可以給其傳送命令，還有1秒結束安裝了，能否取消？還有1秒完成解除安裝了，能否取消？系統要求15秒內給予響應，否則託管，在15秒剛到時做出響應是否取消退管可能性）
- 空間邊界（系統規定了控制元件的應用空間，如果把控制元件拖到區域外呢？是否存在“兔死”區域，是否有越界可能）
流程測試
- 管理資訊系統（填寫資訊-->提交-->人工稽核-->髮卡）
- 大多數業務系統
- 使用者管理
- 許可權管理
- 工作流管理
- 基礎資料維護
- 理解業務結構，根據使用者需求有優先順序制定合理的測試計劃與策略
- 從使用者期望軟體完成其所需的業務流程，其他功能則是輔助流程的，因此流程測試是日常測試工作中非常重要的內容
- 流程測試是測試工程師將被測物件的各個功能通過業務流程貫穿起來執行，模擬真實使用者實際的工作流程，從而驗證流程的正確性。
- 流程需求分析、流程測試設計、流程測試執行
- 業務流程，一般可能由多個功能、多種角色、多種許可權組合而成，過程中涉及較多的測試點，進行流程時，需分析業務流程涉及哪些具體的功能、角色及許可權
- 角色
- 涉及幾種角色，每種角色對應的許可權不同，從使用者角色考慮流程的合理性，而不僅僅關注系統實現
- 許可權
- 不同角色對應不同的許可權，通過流程測試，可發現許可權設計方面的缺陷，例：部門領導應該具有審批普通員工的請假單許可權，但不應當具有審批公司領導請假單的許可權。測試流程前需確保許可權功能的正確性
- 路徑
- 流程包含的分支路徑。分支路徑說明了業務流程的複雜度。
- 基本流
- 基本流從流程開始直至流程結束，中間無任何異常分支，往往表述一個正向的業務流程，也是也是優先順序較高的流程，簡單而言，即流程中所有功能都輸入軟體系統可接受的資料，從而完成整個業務流程。例：普通員工提交請假單->部門領導->同意->人事記錄請假資訊。
- 備選流
- 儘管在流程流轉過程中出現了異常，但仍然能回到基本流主線，最終完成使用者期望的業務行為，這樣的流程稱為備選流。
- 異常流
- 異常流是在備選流的基礎上，違反系統約束最終導致使用者期望結果未能達成的路徑。同樣以訂單支付為例，系統呼叫支付介面，使用者密碼輸入錯誤超過3次，導致支付行為鎖定，無法完成後續業務，這樣的處理路勁，理解為異常流。
- 確保對使用者期望實現的業務清晰
- 判定條件、邊界資料、異常處理以及是否符合實際使用者應用場景（人工稽核）
- 涉及較大量的數量，可利用一些資料生成工具來制找測試資料
- 敏捷測試中以一個Sprint為節點，通常Sprint中包括的使用者故事具有較強的耦合度，根據業務流程從而開展測試活動
- 當產品功能逐步整合後，進行冒煙測試時，應當以基本流作為冒煙測試用例執行，驗證被測物件是否具備可測性。冒煙測試通過後在進行正式測試。
安全測試（AppScan/Appium）
- 工具進行掃描安全測試
- 下載掃描工具（NBSI）（fidder/charles）
- 口令測試（使用者名稱密碼不正確）
- 授權驗證（未登入是否可以瀏覽、未授權是否可以使用功能、許可權重疊是否能正確分配）
- 有許可權可見無許可權不可見（都可見，但無許可權不可用，不可修改）（都可見但，無許可權為灰色）
- 有無提示再，根據設計進一步確認
日誌檔案
- 記錄管理員操作和其他人的操作
- 驗證日誌管理功能是否實現，其他角色的使用者即使賦予了日誌管理許可權，但也只能檢視admin使用者的操作日誌。
Session和Cookie
SQL隱碼攻擊
- 遮蔽法
- 跨站點指令碼攻擊(AppScan掃描)
平臺相容性
- 作業系統、瀏覽器及顯示螢幕解析度的型號、規格越來越多，B/S與C/S結構一樣，以驗證被測物件能否在不同的作業系統、瀏覽器及解析度正常工作
- Web相容性測試一般分為平臺、解析度、瀏覽器（Windows、Linux、MacOS）
- 平臺相容性
解析度相容性(市場解析度情況或根據需求來)在相應解析度下走下冒煙（各功能實現是否正常）
瀏覽器相容性
- 用不同瀏覽器檢視顯示是否正常（如：FireFox/Chrome/IE/360/QQ/Safari等）
- 不同瀏覽器對Java、Javascript、ActiveX甚至HTML支援都不相同。
- IE8一下版本對HTML5的支援不好，而IE8又是Windows 7系統預設瀏覽器，測試Windows 7+IE8組合
- Web系統在互動過程中可能以彈出頁面形式進行，如果瀏覽器開啟了廣告過濾功能，則可驗證瀏覽器是否能夠正確識別該彈出網頁，避免出現誤攔截。
前端效能測試
資源數量
- 在伺服器傳輸過程中，如果資原始檔太多，同樣會降低網路的傳輸速度，因此堅決杜絕無效資原始檔在伺服器與客戶端之間傳輸。
- 測試時需確認每一個資源是否確實需要，並杜絕在過程中出現404錯誤的訪問問題。
- 利用HttpWatch錄製客戶端與伺服器端的互動過程，生成彙總圖。
本地快取
- 大型業務系統中，通常會將動態的業務響應轉化成靜態檔案傳輸至客戶端並寫入快取，當使用者再次訪問時，可根據，可根據實際情況從本地Cache檔案讀取，以此加快訪問感受，減輕伺服器壓力。測試工程師可通過測試工具檢測本地快取設定對訪問速度的影響。
請求數量
- 儘量減少HTTP請求（Make Fewer HTTP Request）
- 減少HTTP請求數量帶來的顯而易見的好處是：減少DNS請求所耗費的時間、減少伺服器壓力、減少HTTP請求頭。
介面測試（badboy.exe）
- 內部介面（介面文件）
- 測試用例（格式csv格式）
- jemter 匯入
讀取測試用例
- 替換引數
- 正規表示式測試器（RegexTest）
- 請求結果
系統外部介面
- 支付介面
- 快遞介面
測試執行規範
- 整合測試先保功能點後包流程
- 迴歸是先保流程後各功能點
缺陷跟蹤處理（禪道）
- 嚴重程度
- BUG狀態
- 缺陷型別
- 所屬模組
- 不合理
- 不清晰
- 未能實現
- 設計錯誤
- 有無校驗
確認迴歸測試
- 開發工程師修復缺陷後，應將對應的測試用例再次執行，以確認缺陷是否真正成功修復，這個確認過程，稱為確認測試。
- 迴歸測試是對已被測試的程式在修復缺陷後再次進行用例執行，以確認缺陷修復活動沒有引發新的缺陷或導致缺陷被遮蔽。
- 這些缺陷可能存在於被測試的軟體中，也可能在與之不相關的其他軟體元件中。
- 當軟體發生變更或者應用軟體的環境發生變化時，需要進行迴歸測試。
- 實際測試實施過程中，確認測試和迴歸測試可以並行實施。
- 迴歸測試可以在所有的測試級別上進行，同時適用於功能測試、非功能測試和結構測試。如果迴歸測試套件需執行多次，並且變更較少時，可考慮迴歸測試實現自動化，以提高效率。
- 對於任何一個專案前三輪測試版本迭代過程中，都建議使用迴歸測試策略。將所有測試用例全部迴歸。當被測物件是升級或者維護性的版本時，可採用選擇性迴歸策略實施。
- 確認缺陷是否修復
- 測試工程師提交的缺陷，經過開發工程師處理，如果確實是缺陷，並且已經修復，則測試工程師需在下一個版本上確認缺陷是否已經修復完成，這個過程一般稱為缺陷校驗。
- 對於狀態是“拒絕”的缺陷，測試工程師應當確認開發工程師拒絕的理由是否成立，如果不成立，則需新啟用缺陷，如果拒絕理由成立，則關閉缺陷。
- 執行用例迴歸測試
- 校驗缺陷活動完成後，測試工程師根據測試任務分配進行執行用例活動，重新開展測試活動。
- 補充：選擇性迴歸測試
- 目標達成發
- 周邊影響法（覆蓋率按相應要求來）
缺陷報告
- 版本Bug數量
- 模組Bug數量
- Bug嚴重度（優先順序）
- Bug型別
- Bug狀態
- 當前版本缺陷的處理情況
- 敏捷測試報告（用例執行情況、缺陷分佈、遺留缺陷情況、版本質量評價等）
- 完整測試報告
- 版本概述（描述當前測試版本的基本資訊，如包括的需求、涉及的模組等）
- 團隊成員（描述當前Sprint開發團隊成員資訊）
- 進度回顧（描述當前Sprint測試進度情況，從第一個版本開始到最後一個版本）
- 測試環境（描述當前Sprint測試時所用的測試環境資訊，包括硬體與軟體環境）
- 測試過程（對測試工程師在敏捷開發團隊的工作流程、內容進行概要描述及總結，可結合測試任務分配進行闡述。）
- 用例執行（描述當前Sprint共有多少用例，每個版本執行用例數量及執行結果情況）
- 缺陷分析（描述最後一輪版本測試缺陷資料資訊，如版本Bug數量、模組Bug數量、Bug嚴重度、Bug型別、Bug狀態等，可利用禪道直接生成相關圖表）
- 遺留問題（列出當前Sprint測試遺留問題，便於敏捷開發團隊做質量評估）
- 測試結論（給出明確測試結論，便於產品團隊及其利益相關者決定後續工作計劃及下一個Sprint是否可以開展。測試結論一般有通過、不通過兩種結果）
- 通過（測試到達測試目的，測試通過，進入下一個階段的工作）
- 不通過（需要重測：測試沒有達到測試目標，敏捷開發團隊需重新制定測試任務，重新開展測試活動。測試報告見《附錄》）