功能測試點總結

控件測試

• 註冊表單控件
  • 用戶名文本編輯框
  • 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是否能夠開展。測試結論通常有經過、不經過兩種結果）
• 經過（測試到達測試目的，測試經過，進入下一個階段的工做）
• 不經過（須要重測：測試沒有達到測試目標，敏捷開發團隊需從新制定測試任務，從新開展測試活動。測試報告見《附錄》）