黑盒基礎之用例執行篇

本文章轉載於搜狗測試

介入測試，一般從執行用例開始，初始啟航，面對執行任務，你是否會迷茫如何開始著手，如何反饋，如何溝通，下文是小編對用例執行進行的總結，拋磚引玉~

Ⅰ執行前需要了解的相關資訊

㈠任務的基本資訊

1.模組負責人：明確任務對應的功能負責人。

⑴執行任務過程中的溝通物件；

⑵任務執行情況和結果的反饋物件；

⑶除主負責人外，是否有第二負責人。

2.開始時間和結束時間：明確自己進入任務和完成任務的時間點

3.用例的條數和執行時間：瞭解用例的條數和執行時間，自我評估任務的時間是否合理，如果不合理需及時與負責人溝通解決。

㈡任務的職責

用例要求

用例路徑：明確要執行的用例。

執行用例篩選條件：明確執行用例的範圍，是全部執行，還是執行其中特定的部分

用例執行說明：用例執行時的特殊要求，需要遵循的基本原則，如：

⑴系統平臺要求，如在win8下執行全部case等

⑵其他軟體環境，如在Win7+IE10的環境中測試等

溝通要求

結果反饋：對於反饋結果和問題，有哪些特殊要求，如：

時間點要求：如每兩個小時反饋一次、有問題及時溝通等。

隨機測試要求

隨機測試的時間：確認是否有隨機測試的安排，以及隨機測試的時間，掌握隨機測試在任務中的比重，以便調控具體任務的時間。

隨機測試的方向：是否有隨機測試方向的說明，有沒有需要特別關注的內容。

㈢執行相關資訊

功能介紹

功能介紹：簡單瞭解被測功能相關的需求和實現，有助於測試執行，關注的內容如下：

需求文件

流程圖（需求流程或實現流程）

用例

工具說明

工具說明：瞭解測試執行過程中會用到的工具，及工具的使用方法。

測試資料

測試資料：獲取測試過程中用到的測試資料，或製作測試資料的方法。一般直接向功能負責人索取。

是否需要安排講解

確認講解的需求：簡單瞭解一下測試用例及其他相關資訊，根據具體情況，確認是否需要安排專門的講解。

如果功能比較複雜，無法通過單純的看需求或實現文件瞭解功能，需要跟相關負責人協調，申請安排專門的講解。

如果測試過程中涉及工具使用或伺服器搭建，單純的文件交接無法完全掌握方法的，需要跟相關負責人協調，申請安排專門的講解。

Ⅱ執行過程中的方法和注意事項

㈠執行過程中涉及的內容

執行用例

標註執行結果

彙報執行進度

溝通問題及check執行結果

提交/驗證bug

隨機測試

㈡執行用例

執行用例的要求

執行用例沒有遺漏。

用例執行正確，與用例執行的步驟一致，或充分滿足用例的測試目的。

用例執行速度滿足預期，達到功能負責人的標準。

用例執行的方法

標準用例和測試點型用例（word文件）的執行方法（建議）：

用不同的背景色或字型顏色標註已執行或未執行的用例，以提醒自己，避免執行遺漏。

用批註標註未執行的用例，後續通過審閱查詢，重新執行後刪除批註，避免執行遺漏。

對於看起來描述一樣的用例，應該反覆多看兩遍，可能只存在個別字的差別，如“能夠”和“不能”這樣的差別。

對於步驟和描述不明確的用例，應該標記出來，與功能負責人確認，明確後方可執行，不能私自臆測。

㈢標註執行結果

標註執行結果的要求

標註完整、無遺漏

標註清晰、明確、無歧義。

標註執行結果的方法

標準用例和測試點用例：（建議）

用pass和fail標註執行結果。

需要跟進的問題和疑問用批註寫明。

對於沒有明確預期或實際效果與預期不符的，需要標註實際結果。

實際操作與用例步驟不一致時，需要記錄實際操作的結果，並跟功能負責人確認實際操作的正確性。

用例中存在錯誤的地方，可用批註標明，並寫明需要功能負責人後續跟進，及需要修改的內容。

發現用例中未覆蓋的測試點，可用批註標明，並寫明需要功能負責人後續跟進。

發現的問題按照是否已經提交bug區分，提交過bug的在標註中新增上對應的bug編號；未提交bug的可以根據實際情況用“待提交”或“待確認”等字樣標明問題當前的狀態，並寫明對應的跟進人，以便對應人員後續跟進，如“待確認，需模組負責人跟產品確認——××”

㈣彙報進度

①定時彙報

彙報時機：根據功能負責人的要求彙報，如每兩個小時彙報一次，或每天下午5點彙報。

彙報物件：對應任務的負責人。

彙報方式：口頭溝通。如果功能負責人當時忙碌或不在，可以用其他方式彙報，如QQ留言，郵件等

彙報內容：

當前執行進度

預計完成時間點

任務是否會delay

執行過程中遇到哪些問題（包括確認測試結果、功能存在哪些問題、執行方法、阻塞問題等）

②主動彙報

彙報時機：隨時，條件如下：

發現嚴重問題或阻塞問題。

預計執行進度不符合預期，會導致任務delay。

彙報物件：對應任務的負責人。

彙報方式：口頭溝通。如果功能負責人當時忙碌或不在，可以用其他方式彙報，如QQ留言，郵件等

彙報內容：

發現的問題：發現的嚴重問題或阻塞問題現象。

影響範圍：阻塞多少內容無法執行。

進度delay的原因以及時間。

㈤溝通執行結果

主動與功能負責人溝通。遇到問題時需要有積極的態度，作為發起方主動與功能負責人溝通。

注意事項：

溝通時注意思路清晰，描述問題簡單詳盡。跟功能負責人溝通前，需要先把問題想清楚，準備好充分的資訊後再進行溝通，以免描述模糊不清導致溝通成本的增加。

溝通過的問題要備忘。已經溝通過的問題，需要自己進行備忘，不要在同一件事情上重複溝通，增加雙方的溝通成本，影響任務的正常進行。

注意溝通的頻率。在不影響整體執行進度的前提下，當問題（包括執行方法和待確認的bug）比較多的時候，可以跟功能負責人約定一個時間點，集中解決，不要頻繁的打擾功能負責人，以免干擾功能負責人的正常工作。

㈥提交/驗證bug

將發現的bug按照要求提交到bug管理系統，開發修改完畢後進行驗證

㈦隨機測試

按照功能負責人的要求對執行的功能進行隨機測試

Ⅲ執行結果反饋

郵件公示執行結果（建議）

郵件標題：【測試執行】XX版本XXX功能（日期）——執行完畢

收件人：功能負責人

正文：

Case執行結果概述：

測試版本：（測試執行過程中使用的版本號，XXX版~XXX版）

提交bug數：（本次提交bug的總數）

阻塞性bug數及編號：（阻塞性bug的總數及編號）

執行結果統計表格：

case總數

pass數

fail數

阻塞case數

用例未覆蓋的bug數

180

165

10

5

2

附件說明

測試執行結果文件：執行後的結果文件

測試執行資料：執行過程中用到的測試資料，沒有填“無”

測試執行結果標註特殊說明：

例如：批註中標註XXX的內容，請功能負責人更新case；批註中標註XX的內容，請功能負責人與產品後續確認等。

上線風險（有則寫，沒有填“無”）

列舉出沒有提交bug的風險，如

產品確認沒問題，但個人認為使用者體驗不好的。

隨機出現無法重現，或者只在個例機器上穩定重現的。

未充分測試點（有則寫，沒有填“無”）

測試不充分的內容，如

測試用例中包含，但因為條件等因素無法執行的。

由開發人員自行保證的

開發迴歸範圍較大，因時間或手段等迴歸不充分、無法覆蓋的。

Bug反覆出現，最終版本沒有關注的。

注意事項

當部分（少量）case被阻塞，導致測試任務無法完成，如阻塞時間較長（任務預期結束時間無法完成），那麼在其他case執行完畢後，仍然需要發出任務執行完畢的郵件，在郵件中說明剩餘的case數，以及被阻塞的case後續執行完的預期時間點，並在全部執行完畢後回覆說明。