目錄

• 需求分析
• 需求評審
• 測試計劃
  • 為什麼要編寫測試計劃？
  • 什麼時間開始編寫測試計劃？
  • 由誰來編寫測試計劃？
  • 測試計劃的內容
• 測試用例
  • 測試用例的主要構成要素
  • 測試用例的顆粒度
  • 用例評審
  • 寫好測試用例的關鍵 /寫好用例要關注的維度
  • 怎樣保證覆蓋使用者需求？
  • 執行結果
  • 用例的整合
• 測試用例的設計方法
  • 等價類
    • 劃分等價類的方法
    • 設計測試用例
  • 邊界值
    • 基於邊界值分析方法選擇測試用例的原則
  • 判定表
    • 判定表的建立步驟:
  • 場景法
    • 步驟一：描述出基本流及各項備選流
    • 步驟二：根據基本流和各項備選流生成不同的場景。以下為部分場景。
    • 步驟三：生成測試用例
  • 錯誤推斷法
  • 測試方法選擇的綜合策略
    • 以下是各種測試方法選擇的綜合策略，可在實際應用中參考。
• 測試執行
  • 測試執行過程注意事項
• 缺陷的定義缺陷又名為BUG（臭蟲）
• 測試報告的主要內容

需求分析

在軟體專案的開發過程中，軟體需求規格說明書的編寫是必不可少的，他能夠使使用者和軟體開發者雙方對該軟體的初始規定有一個共同的理解，這是整個專案開發工作的基礎

提取測試點是通過對需求的細化和分解，形成可測試的內容。測試內容應全部覆蓋系統的業務流程，以及功能和非功能方面的需求。
非功能的需求，包括：使用者體驗，效能等其他需求，本課程先探討功能性的需求。

• 業務流程圖
  

• 註冊單個功能
  

在我們實際工作中，有些專案有需求文件，有些專案沒有需求文件。那不管有沒有需求文件，我們進行需求分析，目的都是一樣的，都是要提取出我們的測試點。

通常我們做需求分析，會先熟悉整個產品/需求本身，按層次/模組

說明：系統分解的層次是由系統的複雜程度決定的。複雜的需要三層到四層，比較簡單可能只有一層。系統分解的最終目的是將整個系統劃分為一個個獨立的功能點。分解的過程中要注意粒度的均勻性和邏輯的合理性，相關的功能要劃分到一個父節點下。將這個分解結果以樹的形式展現出來就是RTM(需求跟蹤矩陣)了。

如下給到一個例項，給一個新增使用者的功能，提取測試點

• 需求如下
  

• 需求分析的結果
  

需求評審

在需求分析之後，會進行一個需求評審的會議，整個專案的成員會聚集在一起討論一下各自對需求的理解，看看對需求的理解是否出現了不一致的地方，是否出現了遺漏的地方。

評審的內容：

1. 完整性審查：應保證測試需求能充分覆蓋軟體需求的各種特徵，重點關注功能要求、資料定義、介面定義、系統約束等方面，同時還應關注是否覆蓋開發人員遺漏的、系統隱含的需求；
2. 準確性審查：應保證所描述的內容能夠得到相關各方的一致理解，各項測試需求之間沒有矛盾和衝突，各項測試需求在詳盡程度上保持一致，每一項測試需求都可以作為測試用例設計的依據。

測試計劃

在評審完成之後，會完成一個測試計劃的編寫，安排一下測試的進度與內容。

為什麼要編寫測試計劃？

軟體測試是有計劃、有組織和有系統的軟體質量保證活動，而不是隨意地、鬆散地、雜亂地實施過程。為了規範軟體測試內容、方法和過程，在對軟體進行測試之前，必須建立測試計劃。

什麼時間開始編寫測試計劃？

需求分析後編寫測試計劃，在整個測試工作過程中，不斷修改

由誰來編寫測試計劃？

具有豐富經驗的專案測試負責人

測試計劃的內容

測試專案的背景、測試範圍和測試策略、測試環境、測試開始和結束條件、進度安排，測試組織，以及與測試有關的風險等方面的內容。

• 測試專案的背景
  對測試物件及其目標進行簡要說明，包括的資訊有：主要的功能和效能，測試物件的架構和專案的作用。通常，專案的背景可以從需求文件中獲取。

• 測試範圍
  簡要地列出本次測試的主要功能模組。
  

• 測試方式/策略:

  • 功能測試
  • 介面測試(UI測試)
  • 安全測試
  • 安裝測試
  • 相容性測試
  • 負載測試
  • 壓力測試

• 測試環境
  1、從軟體的編碼、測試到使用者實際使用，存在著：開發環境、測試環境和生產環境。

開發環境：開發環境是程式猿們專門用於開發的伺服器，配置可以比較隨意， 為了開發除錯方便，一般開啟全部錯誤報告。
測試環境：一般是克隆一份生產環境的配置，一個程式在測試環境工作不正常，那麼肯定不能把它釋出到生產機上。
生產環境：是指正式提供對外服務的，一般會關掉錯誤報告，開啟錯誤日誌。

2、“環境”，指的是被測試軟體所執行的軟體環境和硬體環境。

3、測試環境是測試人員為進行軟體測試而搭建的環境，根據不同的測試階段，測試環境可以分為冒煙測試環境，SIT測試環境，UAT測試環境等；根據不同的測試型別，測試環境可以分為功能測試環境，自動化測試環境，效能測試環境。

專案的mysql或者oracle用的什麼版本？修改oracle的配置檔名叫什麼？
參考答案：
mysql版本：5.7
oracle版本：11g
修改oracle的配置檔名叫:tnsnames.ora

2、linux用的是哪家的？具體什麼版本？
Linux是：CentOS
版本是：6.8

3、linux系統用的cpu什麼型號？記憶體多大的？
型號：英特爾 酷睿 i7
核數：6核
記憶體：32G
網路頻寬：100M

• 開始和結束條件

  • 啟動條件：
    軟體測試是在專案啟動、需求分析開始時隨之啟動

  • 結束條件(專案上線的條件)：
    需求覆蓋率、用例執行率、缺陷遺留率達到預定質量目標。

備註：每個公司流程不一樣，制定的質量標準也是不一樣的，不過大同小異。我以前工作過的專案組，標準是這樣的：測試用例對需求的覆蓋率達到100%；原則上，用例執行率要達到100%，但是如果時間緊，就執行優先順序高的，低級別的用例就在下個版本執行；致命、嚴重級別的缺陷必須當天解決，一般、輕微級別的缺陷，遺留率是30%以下。

• 進度安排
  進度安排，是指具體一個任務，要花多長時間完成，由誰負責。

• 測試組織
  指在專案組中有哪些測試人員，擔任什麼角色，職責是什麼。(如，測試角色有：測試經理，測試組長，其他測試人員，並列出他們的工作職責)

• 風險

1. 專案中的人員比例情況是怎樣的呢？（比如開發人員與測試人員）
   大概就是3:1 或者4:1這個比例

2. 不同型別及規模的專案大概會有多少測試人員呢？
   一個開發小組人數在5到10人之間最為合適，如果專案規模很大，可以採取層級式結構，配置若干個這樣的開發小組。

測試用例

測試用例是一份測試文件，它描述輸入、動作、和一個期望的結果，其目的是確定應用程式的某個特性是否正常的工作。
測試用例是軟體測試團隊的主要工作成果之一。
對測試用例的定義，業界沒有一個統一的說法，個人認為，測試用例，就是使用者對一個系統的使用場景的描述。

測試用例的主要構成要素

• 用例編號
  用例編號(ID)，顧名思義，就是為用例匯入用例管理系統(如：禪道)，或者與bug進行關聯時，方便應用。用例編號通常為 專案簡稱+模組簡稱+順序編號

• 用例標題
  就像人的名字一樣，給你書寫的用例起一個名稱。用例標題的書寫，沒有固定格式，原則是，讓別人看到標題，就能聯想到這個用例做了什麼事情。用例名稱儘量不要重複。通常用例標題包括 做什麼操作，期望結果是什麼

• 用例級別
  測試用例級別的劃分，一般是依據使用者使用該場景的頻率，和該功能對系統的影響程度來確定，比如，註冊功能，對於一個系統來說，使用者一輩子可能只註冊一次，但是，直接影響到使用者對系統的使用。
  根據公司不同，通常測試用例級別包含：
  1級(高)，影響很大，阻礙性的、流程性的用例。例如登陸功能，百度一下
  2級(高)，大的功能點，以及會阻礙少部分用例的執行。例如新增按鈕，如不能通過，很多功能都不可測試
  3級(中)，小的功能點，例如重新整理，重新整理功能等
  4級(低)，小的UI的問題，位置，大小，驗證，建議等等
  Ps：有些公司是，數字越高等級越高，有些則反過來。

• 預置條件
  完成一件事，需要具備什麼條件。

• 用例的測試步驟
  測試步驟，為了驗證某個功能，我們需要怎樣的操作才能看到這個功能。

• 預期結果
  測試用例期望結果，用例執行後要達到什麼結果。

測試用例的顆粒度

顆粒度，指的是粗細程度。粒度大，就是說一個用例所涵蓋的關注內容比較多，反之同理。
用例的顆粒度大，則總的用例數就少，用例看起來也簡潔。
用例的顆粒度小，則單條用例關注的測試點很集中，不容易遺漏，並且執行需要的時間比較好估計。

• 掌握一個度
  粒度該大該小，如何把握，其實不難。一是看你這個用例寫出來會不會測試好幾個小時都沒能測試完。二是看你這個用例會不會被另一個人執行的時候只執行了涵蓋了一部分的測試點而遺漏了另一部分。通常，一個用例測試一個場景即可。

用例評審

由於測試人員很可能對需求理解有誤，場景考慮不全等原因，導致測試用例無法全面覆蓋使用者需求，場景缺失等，所以，測試用例編寫完成後，都要經過嚴格的評審才能進行執行。
軟體測試用例評審人員，一般會有哪些人呢？由於不同專案的實際情況不一樣，參與評審的人員也會有所變動，但是，正常來說，都會有 測試人員，開發，還有產品經理(BA) 在場。

寫好測試用例的關鍵 /寫好用例要關注的維度

1. 覆蓋使用者的需求；
2. 從使用者使用場景出發，考慮使用者的各種正常和異常的使用場景；
3. 用例的顆粒大小要均勻。通常，一個測試用例對應一個場景；
4. 用例各個要素要齊全，步驟應該足夠詳細，容易被其它測試工程師讀懂，並能順利執行；
5. 做好用例評審，及時更新測試用例。

怎樣保證覆蓋使用者需求？

專案開始前，我們會先熟悉需求，畫好流程圖，保證整個流程都覆蓋全面，小組之間每個人都要根據各自的流程圖，各個功能點有哪些限制條件，來講解一下自己對測試點的理解，防止之後編寫測試用例時出現遺漏；用例編寫完之後，再進行用例的評審，看看測試點有沒有用遺漏，對需求理解有沒有錯誤，測試場景是否覆蓋完全。

執行結果

當用例還尚未被執行時，是No Test未執行狀態
當執行結果與預期結果相符時，是Pass通過狀態
當執行結果與預期結果不符時，是Fail失敗狀態
當因為軟體有缺陷而妨礙了用例步驟的執行，且該缺陷並不是我們的測試點，則用例是Block阻礙狀態。
當用例正在執行中，但是需要耗較多時間去觀察其結果，是Investigate觀察中狀態。

用例的整合

測試用例並不可能一開始就寫得很完美，可能也有寫錯的，可能也有遺漏的測試點，因此，做好測試用例評審很關鍵。
隨著軟體的版本不斷更新，軟體本身的需求和規格以及設計都可能在不斷地變更。
隨著測試的不斷開展，測試人員對產品的理解逐漸加深。
基於上訴，就使得我們完全有理由在測試用例執行的過程中，同時不斷地優化我們的測試用例，使得用例的質量越來越高。

測試用例的設計方法

在編寫測試用例時，掌握各種測試方法的使用場景，並能靈活使用。

等價類

是把所有可能的輸入資料,即程式的輸入域劃分成若干部分（子集）,然後從每一個子集中選取少數具有代表性的資料作為測試用例.該方法是一種重要的,常用的黑盒測試用例設計方法.

關於等價類的劃分，我們可以分為以下兩個等價類

• 有效等價類
  是指對於程式的規格說明來說是合理的,有意義的輸入資料構成的集合。利用有效等價類可檢驗程式是否實現了規格說明中所規定的功能和效能。
• 無效等價類
  與有效等價類的定義恰巧相反。無效等價類指對程式的規格說明是不合理的或無意義的輸入資料所構成的集合。對於具體的問題，無效等價類至少應有一個，也可能有多個。

設計測試用例時,要同時考慮這兩種等價類。因為,軟體不僅要能接收合理的資料，也要能經受意外的考驗。這樣的測試才能確保軟體具有更高的可靠性。

劃分等價類的方法

1. 在輸入條件規定了取值範圍或值的個數的情況下,則可以確立一個有效等價類和兩個無效等價類。

例如：規定了使用者名稱的長度為6-20個字元
那麼可以確定一個有效等價類和兩個無效等價類

2. 在輸入條件規定了輸入值的集合或者規定了“必須如何”的條件的情況下，可確立一個有效等價類和一個無效等價類。
   例如：“使用者名稱的第一字元必須是字母”，那麼，所有以字母開頭的集合構成有效等價類；以非字母開頭的集合構成無效等價類。

3. 在輸入條件是一個布林量的情況下,可確定一個有效等價類和一個無效等價類。
   布林量的取值：真 或 假（True or False）

4. 規定了輸入資料的一組值（假定n個）,並且程式要對每一個輸入值分別處理的情況下,可確立n個有效等價類和一個無效等價類。
   例：輸入條件說明學歷可為:專科、本科、碩士、博士四種之一，則分別取這四種這四個值作為四個有效等價類，另外把四種學歷之外的任何學歷作為無效等價類。

5. 在規定了輸入資料必須遵守的規則的情況下,可確立一個有效等價類（符合規則）和若干個無效等價類（從不同角度違反規則）。
   例如，某註冊框的使用者名稱規定為6位小寫字母。

設計測試用例

在確立了等價類後,可建立等價類表,列出所有劃分出的等價類輸入條件

然後從劃分出的等價類中按以下原則設計測試用例:

1. 設計有效場景的用例，每個用例應儘可能多地覆蓋尚未被覆蓋地有效等價類，重複這一步，直到所有的有效等價類都被覆蓋為止。
2. 設計異常場景的用例，每個用例應僅覆蓋一個尚未被覆蓋的無效等價類，重複這一步，直到所有的無效等價類都被覆蓋為止。

邊界值

邊界值分析方法是對等價類劃分方法的補充.

• 邊界值分析方法的考慮:
  大量的錯誤是發生在輸入或輸出範圍的邊界上，而不是發生在輸入輸出範圍的內部。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。

使用邊界值分析方法設計測試用例,首先應確定邊界情況。通常輸入和輸出等價類的邊界，就是應著重測試的邊界情況，應當選取正好等於，剛剛大於或剛剛小於邊界的值作為測試資料，而不是選取等價類中的典型值或任意值作為測試資料。

基於邊界值分析方法選擇測試用例的原則

1. 如果輸入條件規定了值的範圍,則應取剛達到這個範圍的邊界的值,以及剛剛超越這個範圍邊界的值作為測試輸入資料。

   • 比如：如果程式的規格說明中規定：“重量在10公斤至50公斤範圍內的郵件，其郵費計算公式為……”。作為測試用例，我們應取10及50，還應取9.99，10.01，49.99，50.01等。

2. 如果輸入條件規定了值的個數,則用最大個數,最小個數,比最小個數少一,比最大個數多一的數作為測試資料。

   • 比如，一個商品的標題長度限制為1到120個字元，那麼，我們要測試標題為空，為1個字串，120個字元，以及121個字元。

3. 如果程式的規格說明給出的輸入域或輸出域是有序集合,則應選取集合的第一個元素和最後一個元素作為測試用例。

邊界值分析法

編寫測試用例

判定表

判定表（Decision Table）是分析和表達多邏輯條件下執行不同操作的工具。

等價類劃分法和邊界值分析方法都是著重考慮輸入條件，但沒有考慮輸入條件的各種組合、輸入條件之間的相互制約關係。這樣雖然各種輸入條件可能出錯的情況已經測試到了，但多個輸入條件組合起來可能出錯的情況卻被忽視了。
如果在測試時必須考慮輸入條件的各種組合，則可能的組合數目將是天文數字，因此必須考慮採用一種適合於描述多種條件的組合、相應產生多個動作的形式來進行測試用例的設計。

判定表的建立步驟:

• 步驟一：標識輸入和輸出
  逐項分析測試子項的測試規格，找出其中所有的輸入和輸出並標識出來，其中要注意以下幾點：
  1、輸入需要包括外部訊息輸入、內部預置的使用者狀態、資料配置等所有對系統輸出有影響的因素；
  2、輸入和輸出項只涉及兩種取值的，可以只做為一個標識出來。如果輸入項涉及多種取值的，每個取值需要做為一個輸入標識出來；
  3、識別符號可以自己確定，但輸入與輸出需要獨立標識。

• 步驟二：構造判定表
  將標識的輸入填入條件樁部分，將標識的輸出填入動作樁部分。條件項部分的列數為2的n次方列，n為輸入數(即條件樁的個數)。並從最右列到最左列從“NN…N”到”YY…Y”填入條件項的所有組合。

• 步驟三：逐列分析條件項組合，填入其動作項
  分析每列的條件項取值情況，根據輸入和輸出邏輯關係，得到該列的輸出值為“Y”或“N”，填入該列動作項，得到一條規則。一條規則就是一條測試用例。

判定法，是用在不同的輸入組合，可能會產生不同的輸出這種情況，比如，一個有多個查詢條件的查詢功能，輸入不同的查詢條件組合，輸出的結果是不一樣的，這樣的功能就要用到判定表

場景法

場景法也叫流程分析法，是模擬使用者操作軟體時的場景，主要用於測試系統的業務流程。當我們拿到一個測試任務時，我們並不是先關注某個輸入框的等價類、邊界值是否滿足要求，而是關注它的主要功能和業務流程是否實現，這就需要使用場景法來進行測試。當業務流程測試沒有問題，就說明軟體的基本功能沒有問題，我們再重點從等價類、邊界值等方面對軟體的控制元件進行測試。
<br>

在冒煙測試時，就主要是使用流程分析法進行測試。

• 在測試一個軟體的時候，在場景法中，如果測試的流程是軟體功能按照最短的事件流實現的一條正確流程，那麼我們把這個流程稱為該軟體的基本流；而凡是出現故障或缺陷，或其他原因導致最終的目的不能被實現，或者實現的流程並非是最短的，那麼該流程就叫做備選流。這樣的話，備選流就可以是從基本流來的，或是由備選流中引出來的。

• 每個經過用例的可能路徑，可以確定不同的用例場景。從基本流開始，再將基本流和備選流結合起來，確定用例場景。

場景法設計步驟：

1. 根據說明，描述出程式的基本流及各項備選流；
2. 根據各種流程，生成正常和異常的測試場景；
3. 對每一個流程生成相應的測試用例。

步驟一：描述出基本流及各項備選流

基本事件流：

1. 使用者向ATM提款機中插入銀行卡，如果銀行卡是合法的，ATM提款機介面提示使用者輸入提款密碼；
2. 使用者輸入該銀行卡的密碼，ATM提款機與MainFrame傳遞密碼，檢驗密碼的正確性。如果輸入密碼正確，提示使用者輸入取錢金額，提示資訊為：“請輸入您的提款額度”；
3. 使用者輸入取錢金額，系統校驗金額正確，提示使用者確認，提示資訊為“您輸入的金額是xxx，請確認，謝謝！”，使用者按下確認鍵，確認需要提取的金額；
4. 系統同步銀行主機，點鈔票，輸出給使用者，並且減掉資料庫中該使用者帳戶中的存款金額。
5. 使用者提款，銀行卡自動退出，使用者取走現金，拔出銀行卡，ATM提款機介面恢復到初始狀態；

備選事件流(考慮可能失敗的地方)：

在基本事件流1中：

• 如果插入無效的銀行卡，那麼，在ATM提款機介面上提示使用者“您使用的銀行卡無效！”，3秒鐘後，自動退出該銀行卡。

在基本事件流2中

1. 如果使用者輸入的密碼錯誤，則提示使用者“您輸入的密碼無效，請重新輸入”；
2. 如果使用者連續3次輸入錯誤密碼，ATM提款機吞卡，並且ATM提款機的介面恢復到初始狀態。此時，其他提款人可以繼續使用其他的合法的銀行卡在ATM提款機上提取現金。
3. 使用者輸入錯誤的密碼後，也可以按“退出”鍵，則銀行卡自動退出。

在基本事件流3中：

1. 如果使用者輸入的單筆提款金額超過單筆提款上限，ATM提款機介面提示“您輸入的金額錯誤，單筆提款上限金額是1500RMB，請重新輸入”；
2. 如果使用者輸入的單筆金額，不是以100RMB為單位的，那麼提示使用者“您輸入的提款金額錯誤，請輸入以100為單位的金額”；
3. 如果使用者在24小時內提取的金額大於4500RMB，則ATM提款機提示使用者，“24小時內只能提取4500RMB，請重新輸入提款金額”輸入提取的金額超過了系統的設定的限制 ；
4. 如果使用者輸入正確的提款金額，ATM提款機提示使用者確認後，使用者取消提款，則ATM提款機自動退出該銀行卡；
5. 如果ATM提款機中餘額不足，則提示使用者，“抱歉，ATM提款機中餘額不足”，3秒鐘後，自動退出銀行卡。

在基本事件流4中

1. 如果使用者銀行戶頭中的存款小於提款金額，則提示使用者“抱歉，您的存款餘額不足！”，3秒鐘後，自動退出銀行卡；
2. 如果ATM提款機與MainFrame之間通訊超時10秒鐘，則本次操作取消，提示使用者“抱歉，連結超時，本次操作取消”，並且將銀行卡退出；

在基本事件流5中：

1. 如果使用者沒有取走現金，或者沒有拔出銀行卡，ATM提款機不做任何提示，直接恢復到介面的初始狀態；

步驟二：根據基本流和各項備選流生成不同的場景。以下為部分場景。

步驟三：生成測試用例

錯誤推斷法

• 在軟體測試中，人們可以靠經驗和直覺推測系統中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的例子，這就是錯誤推測法。
• 其基本想法是：根據以往的測試經驗和對系統內部知識的瞭解，列出系統中各種可能有的錯誤和容易發生錯誤的特殊情況，再根據它們來設計測試用例。隨著在產品測試的實踐中對產品的瞭解加深和測試經驗的豐富，使用錯誤推測法設計的測試用例往往非常有效，可以作為測試設計的一種補充手段，並且積累的經驗越豐富，方法使用效率越高。
• 錯誤猜測不是瞎猜，它需要依據對系統薄弱地方的瞭解和對開發人員盲點的瞭解。
• 在實施錯誤猜測法時，要注意的是，此方法只能作為測試用例設計的補充而不能單獨用來設計測試用例，否則可能會造成測試的不充分。也就是說，錯誤猜測法只是針對系統可能存在的薄弱環節的測試補充，而不是為了覆蓋而測試。

錯誤推測法，就是靠經驗，推測使用者可能會有哪些比較特殊的操作場景進行測試
> 比如測試付款這個功能，一般我們都會想到直接付款，但是有些使用者下單後，可能會一直不付款；退款中途，取消退款後，再次發起退款，我們之前就遇到過，取消退款後再發起退款，給使用者退了雙倍的錢；提交訂單時，如果網路差，頁面沒有及時跳轉，這個時候使用者可能會多次點選提交按鈕，我們之前也發現過這樣的bug，連續點了7次提交訂單按鈕，下了7個一模一樣的訂單。這些測試場景，就是用錯誤推測法設計出來的。

測試方法選擇的綜合策略

• 測試用例的設計方法不是單獨存在的，具體到每個測試專案裡都會用到多種方法，每種型別的軟體有各自的特點，每種測試用例設計的方法也有各自的特點，針對不同軟體如何利用這些黑盒方法是非常重要的。
• 在實際測試中，往往是綜合使用各種方法才能有效提高測試效率和測試覆蓋度，這就需要認真掌握這些方法的原理，積累更多的測試經驗，以有效提高測試水平。

以下是各種測試方法選擇的綜合策略，可在實際應用中參考。

1. 首先進行等價類劃分，包括輸入條件和輸出條件的等價劃分，將無限測試變成有限測試，這是減少工作量和提高測試效率最有效方法。
2. 在任何情況下都必須使用邊界值分析方法。經驗表明用這種方法設計出測試用例發現程式錯誤的能力最強。
3. 用錯誤推測法再追加一些測試用例。
4. 對照程式邏輯，檢查已設計出的測試用例的邏輯覆蓋程度。如果沒有達到要求的覆蓋標準，應當再補充足夠的測試用例。
5. 對於業務流清晰的系統，可以利用場景法貫穿整個測試案例過程，在案例中綜合使用各種測試方法。

測試執行

根據已有的測試用例，按照裡面的步驟一步一步的執行，檢視預期結果與實際結果是否一致。

測試執行過程注意事項

• 搭建測試環境事項
  測試用例執行過程前，成功搭建測試環境是第一步。一般來說，軟體產品提交測試後，開發人員應該提交一份被測試軟體產品的詳細安裝指導書。
  如果開發人員拒絕提供相關的安裝指導書，搭建測試中遇到問題的時候，測試人員可以要求開發人員協助，這時候，一定要把開發人員解決問題的方法記錄下來，避免同樣的問題再次請教開發人員，這樣會招致開發人員的反感，也降低了開發人員對測試人員的認可程度。

• 測試環境怎麼搭建的？

搭建環境前，開發都會給到我們一份系統釋出手冊，我們會根據這個手冊來搭建。比如，我這個xx系統，是搭建在Unix系統下的，web伺服器用的是Tomcat8，MySQL版本是5.7，程式是JAVA編寫的，首先我們向開發拿到編譯好的安裝包，然後用xshell遠端連線上Unix系統，把tomcat伺服器停掉，把程式包放到webapps目錄下，然後再啟動tomcat伺服器就可以了。

• 偶然性問題的處理

1. 在測試執行過程中，一旦系統出現異常資訊，我們第一時間要做的是截圖，儲存證據；
2. 確定是偶然性的bug之後，收集相關的日誌，連同截圖一起提單給開發定位；
3. 如果缺陷在當前版本無法復現，且缺陷的影響程度比較低，我們會跟蹤三個版本，如果後三個版本都無法復現，就可以關閉該缺陷；
4. 如果是很嚴重的Bug，除了要及時反饋給上級之外，最後還要寫到測試報告中，說明出現了什麼現象，但無法再現！

• 詳細記錄預期與實際的不一致
  如果不一致，要從多個角度多測試幾次，儘量詳細的定位軟體出錯的位置和原因，並測試出因為這個錯誤會不會導致更嚴重的錯誤出現，最後把詳細的輸入和實際的輸出，以及對問題的描述寫到測試報告中。
  因為在一個專案組中，專案的開發時間是有限的，如果我們測試時能把問題描述的詳細一些，那麼開發人員就會很容易的重現這個問題，也就能更快的解決問題，節省專案時間。

• 提交缺陷時與開發的關係處理

  1. 堅持原則；
  2. 對事不對人，拿證據說話；
  3. 尊重對方的勞動成果，平時和開發人員打好關係，不要把關係搞僵。

• 當我們認為某個地方是bug，但開發認為不是bug，怎麼處理？

1. 先跟開發溝通，確認系統的實際結果是不是和需求有不一致的地方；有些地方可能需求沒提及，但是使用者體檢不好，我們也可以認為是bug。
2. 如果開發以不影響使用者使用為理由，拒絕修改，我們可以和產品經理，測試經理等人員進行討論，確定是否要修改，如果大家都一致認為不用改，就不改。

• 及時更新測試用例
  測試執行過程中，應該注意及時更新測試用例：
  往往在測試執行過程中，才發現遺漏了一些測試用例，這時候應該及時的補充；
  有些測試用例在具體 的執行過程中根本無法操作，這時候應該刪除這部分用例；
  若干個冗餘的測試用例完全可以由某一個測試用例替代，那麼刪除冗餘的測試用例。
  總之，測試執行的過程中及時地更新測試用例是很好的習慣。不要打算在測試執行結束後，統一更新測試用例，如果這樣，往往會遺漏很多本應該更新的測試用例。

缺陷的定義缺陷又名為BUG（臭蟲）

1. 軟體實現的功能和需求不一致的功能
2. 軟體未實現需求和規格未明確提及但應該實現的內容
3. 軟體難以理解，不易使用，執行緩慢，或者終端使用者(估計會)認為不好。

• 產品在上線後用戶發現bug，這時測試人員應做哪些工作？

  1. 測試人員復現問題後，提交問題單進行跟蹤；
  2. 評估該問題的嚴重程度，以及修復問題時的影響範圍，迴歸測試需要測試哪些功能；
  3. 問題修復後，先在測試環境上回歸，通過後再在生產環境上打補丁，然後再進行迴歸測試；
  4. 總結經驗，分析問題發生的原因，避免下次出現同樣問題。

• 集結（二八定理）
  缺陷往往喜歡扎堆，一個模組已經發現的缺陷比別的模組多，通常不是代表這個模組已經把缺陷暴露完了，而是意味著這個模組還存在有同樣多的缺陷尚未被發現。這就是著名的二八定理：80%的缺陷出現在 20%的模組。

• 如何跟蹤缺陷/Bug的生命週期
  當發現缺陷後，我們要在禪道上提交問題單給開發，並每隔一段時間(間隔一個小時，或兩個小時都可以)去檢查缺陷是否被處理，如果沒及時處理，就要提示開發，讓開發及時修復問題，問題修復後，要及時進行迴歸測試，如果迴歸通過，就關閉缺陷，如果不通過，就返回給開發繼續修改。

• 缺陷的狀態
  啟用,確認,已解決,關閉

• 缺陷的等級
  致命，嚴重，一般，輕微

• 缺陷單應該包含這些要素
  缺陷標題，嚴重級別，問題所屬模組，復現步驟，預期結果，實際結果，有關的日誌和截圖。

測試報告的主要內容

1. 人力投入
2. 用例統計
3. 問題單分類統計
4. 遺留bug情況
5. 測試風險
6. 測試物件評估
7. 測試結論