0.執行任務
測試執行是執行所有或部分選定的測試用例，並對結果進行分析的過程。測試執行活動是整個測試過程的核心環節，所有測試分析，測試設計，測試計劃的結果將在測試執行中得到最終的檢驗。
1.測試啓動評估：根據測試方案和待測試對象評估此次測試是否達到啓動的條件。不同的測試目的其測試啓動評估的條件不盡相同,要根據實際情況進行設置，啓動條件一般會在測試計劃中定義。
2.指定測試用例：根據測試的階段、任務，選擇執行全部或部分測試用例。
3.測試用例分配：將測試用例分配給測試工程師。
4.執行測試：執行測試用例，記錄原始數據，及時報告發現的缺陷。
5.狀態監控：根據測試執行情況以及缺陷情況，監控測試執行的進度以及遇到的問題，並及時解決測試中阻礙執行進度的相關問題。
6.及時彙報：及時向管理層彙報測試的進度、發現的主要問題等。
測試方案和待測試產品是測試執行的主要輸入。核心部分是一個閉環，要根據對測試狀態的監控及時調整測試策略更新測試方案：
重點關注以下三個任務：測試啓動評估、測試用例分配、測試用例執行
爲了確保測試順利開展，工作量比較大的項目在測試正式啓動之前要對能否啓動測試進行評估，這是因爲：在產品級測試過程中，測試組爲了準備一個版本的測試，將投入很大的成本，包括測試環境、測試人力資源等，這種投入將隨着產品特性的增加，測試環境的複雜化而不斷膨脹；測試啓動評估的目的不在於評估開發人員的工作績效，而是在於控制版本在轉測試時的質量，儘量減少前期不成熟的版本對測試資源的浪費；通過犧牲短期的內部控制成本（轉測試評估和預測試），可以較好地避免後期浪費大量測試投入的風險。
1.評估內容
1.評估被測對象的完成程度以及質量能否達到測試啓動的標準
2.根據給定的版本測試時間及測試用例分配結果，結合測試執行能力，評估本輪測試需達到的覆蓋度。
3.根據覆蓋度確定本輪應發現缺陷的階段目標。
4.評估各特性用例分配情況是否合理，是否存在極不均衡現象，是否存在過度測試？是否存在部分特性無法完成測試？
5.評估測試執行計劃中時間安排的合理性。
實際在開展測試評估時往往沒有那麼順利，可能會遇到各種各樣的問題：比如評估時的預測試投入不能太大；測試人員可能在預測試中急於投入深層次測試，指望這些問題能夠把版本打回開發組；有時即使測試啓動評估結果很差，迫於各方面壓力仍然轉入測試，結果在測試過程中被各類問題困擾，沒能按照既定的測試策略做好測試覆蓋。
識別此次要執行的測試用例的集合：要執行的測試用例一般包括兩部分，需要測試的新增特性的用例和需要回歸的特性用例。測試的執行往往並不是一次性完成的，一個測試往往包含很多次各種規模的執行，每次執行需要根據本次測試的具體情況識別出要執行的測試用例集合，其中需要回歸的特性用例主要是可能受到新特性影響的特性的用例。
考慮特性之間的交互關係：各個特性之間可能存在組合、依賴關係，由於這些關係的存在，不同特性的用例在執行時可能可以合併、合作。
考慮測試用例的優先級：考慮被測試用例的優先級，優先安排執行優先級高的測試用例；考慮時間進度，平衡測試進度和測試執行質量。
測試用例的執行中要關注測試執行的質量。測試執行的主要目標是儘可能地發現產品的缺陷，而不是達到測試計劃完成率，如果過於關注測試計劃完成率，而不重視測試執行的質量，會導致雖然已經完成測試但是仍然不能確保產品質量，即使再進行補救，增加重複測試，不但加大了測試冗餘度，還會造成整體測試進度的延遲，更嚴重的是會遺留掉很多本來應該發現的缺陷。因此測試用例執行過程中除了關注測試進度還要全方位觀察測試用例執行結果、加強測試過程的記錄、及時確認發現問題、及時更新測試用例、處理好與開發的關係促進缺陷的解決。
在測試過程中不僅關注測試用例的執行結果，還要注意在測試用例執行過程中出現的各類異常現象，如來自告警、日誌、維護系統的異常信息。儘早提交缺陷報告，發現缺陷之後要及時儘早提交缺陷報告，最好是發現之後立即提交，避免在測試結束後才集中提交缺陷報告，確保開發方掌握軟件質量情況並能及時解決缺陷，特別是一些可能阻礙測試的缺陷更要第一時間反饋給開發方。避免機械的執行用例，在測試執行中要多思考，如果發現測試用例不合理要及時補充或修改。
關注點：軟件是否有缺陷 ；填寫軟件缺陷報告 ；確定造成這些缺陷的原因 ；需求、設計是否有缺陷 ；測試環境和測試部件是否有缺陷 ；測試用例設計是否不合理
2.執行監控
測試執行過程中要及時分析測試數據，全方位監控各項指標。
（0）目的
記錄和管理測試用例的執行狀態；根據當前的執行狀態，判定測試用例的質量和執行效率；根據已發現缺陷的分佈，判定結束測試的條件是否成熟；根據缺陷的數量、種類等信息評估被測軟件的質量；根據缺陷的分佈、修復缺陷的時間、迴歸測試發現的缺陷數量等評估開發過程的質量；根據計劃完成情況、發現缺陷情況等信息評估測試工程師的表現
1.進度監控和控制：監控測試執行的進度與預期的偏差，及時分析原因並進行計劃調整
2.用例質量監控：測試用例的有效性，能否發現關鍵問題等。
3.測試覆蓋度監控：測試是否全面。
4.執行效率監控：測試執行的效率
5.研發質量監控：被測產品的質量如何。
測試用例執行的進度 = 已執行的數目/總數目；此數據只表明執行進度，不表示測試的成功率、爲了得到更精確的進度數據，可計算測試步驟數
缺陷的存活時間 =缺陷從open到closed的時間：表明修改缺陷的效率
缺陷的趨勢分析 --- 按照測試執行的時間順序(以月、周、天爲時間單位)，發現的缺陷數量的分佈：如果越來越少，趨近於0，則考慮結束測試執行，相反，則說明存在以下的問題：1.代碼修改引發新的缺陷 2.前一版本的測試存在覆蓋率的問題，新的測試發現了原先未發現的缺陷 3.必須先修改某些缺陷後才能繼續測試，然後才發現其他的缺陷
缺陷分佈密度 =某項需求的總缺陷數/該項需求的測試用例總數，需要考慮缺陷的優先級和嚴重程度，如果過多的缺陷集中在某項需求上，可能表明以下問題：該項功能需求是否過於複雜？該項的需求設計、實現是否有問題？分配給該項的開發資源是否不足？
缺陷修改質量 = 每次修改後發現的缺陷數量（包括重現的缺陷和由修改所引起的新缺陷）：評價開發部門修復缺陷的質量；l如果修改某項功能後，此數值較高，測試部門應當及時通知開發部門
全方位觀察測試用例執行結果、加強測試過程的記錄、及時確認發現問題、及時更新測試用例、處理好與開發的關係(溝通問題)
3.執行結束
測試執行的結束：1.測試達到預期目的後，按計劃結束 2.受到時間進度、資源的限制，測試被迫結束
在測試計劃中明確說明測試結束的條件：Good-Enough原則？結束條件的判定是在質量和成本之間的折衷。一般在測試方案中會明確定義測試結束的條件。測試結束條件的判定是在質量和成本之間的折中。測試執行的結束有兩種情況：一種是測試達到預期目的後，按計劃結束；另一種是受到時間進度、資源的限制，測試被迫結束。
測試已經達到了覆蓋率的要求：不同的測試要從不同的方面來評估覆蓋率，比如：單元測試：從語句覆蓋，代碼覆蓋方面來評估，例如達到100%語句覆蓋。集成測試，從API、API/參數組合來評估。系統測試：從功能、用例、用例場景(Scenario)來評估，例如達到90%用例場景覆蓋。
指定的時間段內沒有發現新的缺陷：比如某企業規定測試結束的條件是測試用例執行完畢，連續三天的測試中沒有發現嚴重程度爲高或以上的缺陷。
基於成本的考慮而結束測試：測試執行到一定階段時，查找未發現的缺陷的成本逐漸增大，如果超過了潛在缺陷所引起的代價，則可以停止測試；此條件不適用於要求高可靠性的軟件，如武器、醫學設備、財務軟件等。
項目組達成一致後可以結束測試：基於技術、資金、開銷等各種因素，項目組（包括管理層、開發、測試、市場銷售）意見一致，認爲可以停止測試。
因時間進度、資源的限制必須結束：此條件一般是爲了按計劃儘快發佈軟件，搶佔市場，這種結束條件存在很大的風險，比如可能存在潛在的嚴重缺陷或者已知的缺陷可能還未修改。
