1.什么是測試

（找出軟件中存在的bug，提高產品的質量，提升用戶的體驗）軟件測試就是利用測試工具按照測試方案和流程對產品進行功能和性能測試，甚至根據需要編寫不同的測試工具，設計和維護測試系統，對測試方案可能出現的問題進行分析和評估。執行測試用例后，需要跟蹤故障，以確保開發的產品適合需求。

2.測試流程

一、**測試需求分析階段：**閱讀需求，理解需求，主要就是對業務的學習，分析需求點。

參與需求評審會議

二、測試計劃階段：主要任務是編寫測試計劃，參考軟件需求規格說明書、項目總體計劃，內容包括測試范圍(來自需求文檔)、進度的安排，人力物力的分配，整體測試策略的制定，和風險的評估與規避措施有一個制定，一般有測試負責人編寫，當然我們也會參與相關的評審工作。

三、測試設計階段：主要任務是編寫測試用例，會參考需求文檔(原型圖)、概要設計、詳細設計等文檔，有不明確的也會及時和開發、產品經理溝通。用例編寫完成后會進行評審。

四、**測試執行階段：**首先搭建測試環境，執行預測(冒煙)，以判定當前版本可測與否，如果預測通過，正式進入系統測試，遇到問題提交Bug到缺陷管理平臺，并對bug進行跟蹤，直到被測軟件達到測試需求要求，沒有重大bug，測試結束。

五、**測試評估階段：**出測試報告，對整個測試的過程和版本質量做一個詳細的評估。確認是否可以上線。

3.測試方法有哪些

1、按是否查看程序內部結構分為：
（1）黑盒測試（black-box testing）：只關心輸入和輸出的結果
（2）白盒測試（white-box testing）：去研究里面的源代碼和程序結構
2、按是否運行程序分為：
（1）靜態測試（static testing）：是指不實際運行被測軟件，而只是靜態地檢查程序代碼、界面或文檔可能存在的錯誤的過程。
靜態測試包括：
對于代碼測試，主要是測試代碼是否符合相應的標準和規范。
對于界面測試，主要測試軟件的實際界面與需求中的說明是否相符。
對于文檔測試，主要測試用戶手冊和需求說明是否真正符合用戶的實際需求。
（5）動態測試（dynamic testing），是指實際運行被測程序，輸入相應的測試數據，檢查輸出結果和預期結果是否相符的過程
3、按階段劃分：
（1）單元測試（unit testing），是指對軟件中的最小可測試單元進行檢查和驗證。
樁模塊（stud）是指模擬被測模塊所調用的模塊，驅動模塊（driver）是指模擬被測模塊的上級模塊，驅動模塊用來接收測試數據，啟動被測模塊并輸出結果。
（2）集成測試（integration testing），是單元測試的下一階段，是指將通過測試的單元模塊組裝成系統或子系統，再進行測試，重點測試不同模塊的接口部門。
集成測試就是用來檢查各個單元模塊結合到一起能否協同配合，正常運行。
（3）系統測試（system testing），指的是將整個軟件系統看做一個整體進行測試，包括對功能、性能，以及軟件所運行的軟硬件環境進行測試。
系統測試的主要依據是《系統需求規格說明書》文檔。
（4）驗收測試（acceptance testing），指的是在系統測試的后期，以用戶測試為主，或有測試人員等質量保障人員共同參與的測試，它也是軟件正式交給用戶使用的最后一道工序。
驗收測試又分為a測試和beta測試，其中a測試指的是由用戶、 測試人員、開發人員等共同參與的內部測試，而beta測試指的是內測后的公測，即完全交給最終用戶測試。

4、黑盒測試分為功能測試和性能測試：

1)功能測試（function testing），是黑盒測試的一方面，它檢查實際軟件的功能是否符合用戶的需求。
包括邏輯功能測試（logic function testing）
界面測試（UI testing）UI=User Interface
易用性測試（usability testing）：是指從軟件使用的合理性和方便性等角度對軟件系統進行檢查，來發現軟件中不方便用戶使用的地方。
兼容性測試（compatibility testing）：包括硬件兼容性測試和軟件兼容性測試
2)性能測試（performance testing）
軟件的性能主要有時間性能和空間性能兩種
時間性能：主要指軟件的一個具體事務的響應時間（respond time）。
空間性能：主要指軟件運行時所消耗的系統資源。
軟件性能測試分為：
一般性能測試：指的是讓被測系統在正常的軟硬件環境下運行，不向其施加任何壓力的性能測試。
穩定性測試也叫可靠性測試（reliability testing）：是指連續運行被測系統檢查系統運行時的穩定程度。
負載測試（load testing）：是指讓被測系統在其能忍受的壓力的極限范圍之內連續運行，來測試系統的穩定性。
壓力測試（stress testing）：是指持續不斷的給被測系統增加壓力，直到將被測系統壓垮為止，用來測試系統所能承受的最大壓力。(Validate the system or software can allowed the biggest stress.)
5、其他測試類型：
回歸測試（regression testing）是指對軟件的新的版本測試時，重復執行上一個版本測試時的用例。(When a new build or release is deployed, repeat all the test cases which has executed in the last build or release.)
冒煙測試（smoke testing），是指在對一個新版本進行大規模的測試之前，先驗證一下軟件的基本功能是否實現，是否具備可測性。(validate the major function is deployed or not in software of system when a new build or release is implement.)
隨機測試（random testing），是指測試中所有的輸入數據都是隨機生成的，其目的是模擬用戶的真實操作，并發現一些邊緣性的錯誤。(means or all the test data is random, to validate the some edge bugs.)

4.測試用例編寫方法（另一個參考鏈接 幾個常用設計測試用例的方法總結 - 簡書 (jianshu.com)）（黑盒測試方法）

一、等價類、邊界值

等價類分為：

有效等價類–在取值范圍內

無效等價類—在取值范圍外

邊界值：錯誤更可能出現在輸入的附近趨勢 +1和-1，用此邊界值需考慮三點：上點，離點，內點 一般會選擇6個數據進行測試

總結：編寫測試用例需要從各方面考慮并根據我們測試用例方法來編寫，測試用例的設計都是循序漸進的過程并不能一步到位。

二、因果圖

• 1、什么是因果圖;通過畫圖的方式進行表達輸入條件和輸出結果之間的關系
• 2、因果圖的核心：

? 1.因–原因–輸入條件 果–結果—輸出結果 2.確定原因，根據用戶的需求來確定原因，因為這些原因會導致一些結果和影響 3.我們測試人員就要理解被測系統的判斷邏輯過程 4.通常因果圖是判定表的一個前置過程

? 5.一般 a.輸入與輸出的關系 b.輸入與輸入的關系

• 3、因果圖的基本符號

? 恒等 a=b 當輸入條件發生時，結果一定會出現

? 非 a!=b 當輸入條件發生時，結果不發生

? 或 a v b 當輸入條件有一個為真的，輸出結果就為真

? 與 a ^ b 當輸入條件有一個為假的，輸出結果就為假

• 4、因果圖的約條件

? 互斥（異）：如果選擇只能選擇一個，但可以不選

? 包含（或）：至少選擇一個，可以多選但不能不選

? 唯一： 必須選擇一個，唯一與互斥的區別：唯一必須選擇一個，互斥可以選一個也可以都不選

因果圖設計測試用例步驟

• 找出所有輸入條件
• 明確所有輸出結果
• 明確所有輸入條件之間的制約關系與組合關系 a.哪些條件可以組合 b.哪些條件不可以組合
• 找出什么樣的輸入條件會產生哪些輸出結果
• 明確輸出結果之間的相互制約關系
• 根據因果圖寫判定表
• 根據判定表設計測試用例

**小結：**1、因果圖主要考慮控件之間條件的組合關系

? 2、控件過多，組合量大的情況下不宜使用因果圖法

三、判定表

• 前言： 判定表建立在因果圖的基礎上
• 定義： a.分析和表述若干輸入條件下，被測對象針對這些輸入條件做出的響應工具，判定表屬 于工具，是由開發設計方式方法延伸到測試領域 b.遇到復雜的業務邏輯可以使用該表理 清業務邏輯
• 重要概念： a.條件------條件樁------需求說明書定義被測對象的所有輸入條件 條件項------針對 條件樁所有可能輸入數據的真假值 b.動作----動作樁----針對條件對象可能采取的所有操作 動作項-----針對動作樁被測對象響應的可能取值結果 規則：動作項和條件項組合在一起，形成業務邏輯處理規則
• **判定表應用步驟：**a.理解需求確定條件樁和動作樁 條件樁=輸入條件 動作樁=輸出結果 動作項=結果的狀態 b.設計優化我們的判定表 c.填寫動作項 也就是業務邏輯 d.根據我們的判定表輸出結果的表現，進行判定表的合并（選操作） e.抽取測試用例：判定表給出的只是規則，不像邊界值，等價類可以直接給出測 試用例 f.編寫測試用例
• **小結：**a.判定表的優缺點 優點：能夠將復雜的問題按照各種可能的情況列舉出來，簡明并避免遺漏，能夠通過正式計算出測試用例的條數 缺點：輸入條件之間限制條件不好表達，解決方案，挑些備注，描述限制關系 當輸入次數過多，規則以2的你n次方劇增時，判定表就會龐大，這是還會造成邏輯缺失，業務混亂，所以需細致分析，盡可能劃分多個需求項 b.電商項目使用居多 c.因果圖、判定表 適合測試控件的組合情況，而且適合測試組合數量比較少的情況 常見控件有（按鈕、單選按鈕、復選框、下拉框） d.判定表的特點：輸入條件的順序無關緊要 輸出結果順序無關緊要 先測哪種組合，后測哪種組合無關緊要 每種組合互相獨立
• 判定表的計算公式：條件有7種 結果狀態有2種 則條件數為27

四、正交排列表

**A.定義：**一種特制的表一般正交表記為LnMk

? n代表行數 也就是需求側臥時組合的行數

? k代表列數 表述控件的個數（因素的個數或因子的個數）

? M 每個控件包含的取值個數（各因子的水平數即各因素的狀態數）

? L 正交表的代號

B.因子：所有參與試驗影響結果的條件

C. 影響實驗結果因子的取值或輸入

? 特點：分布均勻，整齊可比

? L9（34）表示 有4個因子 每個因子有3個取值 9是需求測試組合的個數 n=k*（m-1）+1 n為序號

D.小結：正交表中的因子，判定表種的條件樁

? 優 點：可以把最優的部分篩選出來

? 缺點：經常遺漏一些測試

五、場景法

A.定義：模擬用戶操作軟件的場景 常用于冒煙測試

B.核心概念：

a.基本流-–按照正確的業務流程來實現的僅有一條操作路徑

b.備選流—導致流程出現錯誤的操作流程（模擬錯誤的操作流程）

基本流：

1、開始→插入銀行卡→卡合法→提示輸入密碼→用戶輸入密碼或取消→密碼正確→提示輸入金→用戶輸入金→用戶確認→輸入100單位金額→余額足夠→不超過取款限額→輸出超屏給用戶，退卡→用戶取走現金，取走銀行卡→界面回復初始狀態

備選流：

2、開始→輸入銀行卡→卡不合法→提示error1，退卡

3、開始→輸入銀行卡→卡合法→提示輸入密碼→用戶輸入密碼或取消→取消→退卡

4、開始→輸入銀行卡→卡合法→提示輸入密碼→用戶輸入密碼或取消→密碼不正確→輸入錯誤3次→吞卡

5、開始→輸入銀行卡→卡合法→提示輸入密碼→用戶輸入密碼或取消→密碼不正確→輸入錯誤不超過3次→輸入正確→提示輸入金額→用戶輸入金額→用戶確認→輸入100單位金額→余額足夠→提示error3，退卡

6、開始→輸入銀行卡→卡合法→提示輸入密碼→用戶輸入密碼或取消→密碼不正確→輸入錯誤不超過3次→輸入正確→提示輸入金額→用戶輸入金額→用戶確認→輸入100單位金額→提示error2→輸入金額→確認金額→輸入100單位金額→提示error3，退卡

7、開始→輸入銀行卡→卡合法→提示輸入密碼→用戶輸入密碼或取消→密碼不正確→輸入錯誤不超過3次→輸入正確→提示輸入金額→用戶輸入金額→用戶確認→輸入100單位金額→余額足夠→不超過取款限額→提示error4，退卡

8、開始→輸入銀行卡→卡合法→提示輸入密碼→用戶輸入密碼或取消→密碼不正確→輸入錯誤不超過3次→重新輸入正確→提示輸入金額→用戶輸入金額→用戶確認→輸入100單位金額→提示error2→輸入金額→確認金額→輸入100單位金額→不超過取款限額→提示error4，退卡

9、開始→輸入銀行卡→卡合法→提示輸入密碼→用戶輸入密碼或取消→密碼不正確→輸入錯誤不超過3次→重新輸入正確→提示輸入金額→用戶輸入金額→用戶確認→輸入100單位金額→提示error2→輸入金額→確認金額→輸入100單位金額→不超過取款限額→輸出鈔票，退卡→用戶取走現金，取走銀行卡→界面恢復初始狀態

10、開始→輸入銀行卡→卡合法→提示輸入密碼→用戶輸入密碼或取消→密碼正確→→提示輸入金額→用戶輸入金額→用戶確認→輸入100單位金額→提示error2→輸入金額→確認金額→輸入100單位金額→提示error3，退卡

11、開始→輸入銀行卡→卡合法→提示輸入密碼→用戶輸入密碼或取消→輸入正確→提示輸入金額→用戶輸入金額→用戶確認→輸入100單位金額→余額足夠→不超過取款限額→提示error4，退卡

12、開始→輸入銀行卡→卡合法→提示輸入密碼→用戶輸入密碼或取消→輸入正確→提示輸入金額→用戶輸入金額→用戶確認→輸入100單位金額→提示error2→輸入金額→確認金額→輸入100單位金額→不超過取款限額→提示error4，退卡

13、開始→輸入銀行卡→卡合法→提示輸入密碼→用戶輸入密碼或取消→輸入正確→提示輸入金額→用戶輸入金額→用戶確認→輸入100單位金額→提示error2→輸入金額→確認金額→輸入100單位金額→不超過取款限額→輸出鈔票，退卡→用戶取走現金，取走銀行卡→界面恢復初始狀態

六、狀態轉換圖

**A.定義：**關注被側對象的狀態變化，在需求規格中是否有不可到達的狀態和非法狀態

B.狀態：在被測對象待定輸入的條件下能不能保持響應形式

C.方法流程：a、分析需求劃狀態節點 b、畫狀態樹 c、寫測試用例

D.小結：先寫主要操作 為減少測試用例數量 沿著狀態轉換圖一條路徑

七、大綱法

A.定義：檢查窗口與窗口之間的聯系 每一個窗口有對歌動作，為了弄清楚窗口之間的關系，或說動作之間 的聯系，可以使用測試大綱法

**B.步驟：**a、找所有窗口以及每個窗口的輸入動作，注意先后順序

? b、找到各個窗口之間的關系，并依據此編寫測試用例

適用于軟件安裝程序測試，檢查界面測試要點以及窗口之間的變化

QQ五筆輸入法

1、點擊取消，若不下載，則點“是” 否則點“否”

2、搜索qq五筆輸入法，下載安裝包 點擊下一步

3、閱讀協議后，點擊上一步，返回2步驟

4、點擊取消，則步驟1

5、點擊我接受，

6、點擊瀏覽，選擇安裝目錄

7、選擇上一步，返回步驟5

8、點擊取消，則執行步驟1

9、點擊“安裝”

安裝頁面，等待安裝

10、無法點擊“上一步”和“取消”

11、默認，系統初始值，點擊“下一步

12、安裝完成，點擊“完成”

測試用例：

1、下載→取消→是

2、下載→取消→否→返回下載

3、下載→下一步→取消→是

4、下載→下一步→取消→否→返回上一步

5、下載→下一步→返回上一步

6、下載→下一步→我接受→取消→是

7、下載→下一步→我接受→取消→否→返回人接受

8、下載→下一步→我接受→瀏覽→儲存目錄選擇

9、下載→下一步→我接受→上一步→返回我接受

10、下載→下一步→我接受→安裝→下一步→完成

八、錯誤推斷法

A.定義：基于經驗和直覺推斷程序中所有可能存在的各種錯誤，從而出針對性設計測試用例

三點要素：經驗，知識，直覺

九、測試方法總結

十、白盒測試及其基本方法

1. 概述

   白盒測試也稱結構測試或邏輯驅動測試，它是按照程序內部的結構測試程序，通過測試來檢測產品內部動作是否按照設計規格說明書的規定正常進行，檢驗程序中的每條通路是否都能按預定要求正確工作。 這一方法是把測試對象看作一個打開的盒子，測試人員依據程序內部邏輯結構相關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試，通過在不同點檢查程序的狀態，確定實際的狀態是否與預期的狀態一致。

2. 基本方法

強度由低到高:語句覆蓋、判定覆蓋、條件覆蓋、判定條件覆蓋、條件組合覆蓋、路徑覆蓋。

（1）語句覆蓋：就是設計若干個測試用例，運行被測程序，使得每一可執行語句至少執行一次。

（2）判定覆蓋：使設計的測試用例保證程序中每個判斷的每個取值分支至少經歷一次。

（3）條件覆蓋：條件覆蓋是指選擇足夠的測試用例，使得運行這些測試用例時，判定中每個條件的所有可能結果至少出現一次，但未必能覆蓋全部分支

（4）判定條件覆蓋：判定-條件覆蓋就是設計足夠的測試用例，使得判斷中每個條件的所有可能取值至少執行一次，同時每個判斷的所有可能判斷結果至少執行，即要求各個判斷的所有可能的條件取值組合至少執行一次。

（5）條件組合覆蓋：在白盒測試法中，選擇足夠的測試用例，使所有判定中各條件判斷結果的所有組合至少出現一次，滿足這種覆蓋標準成為條件組合覆蓋。

（6）路徑覆蓋：是每條可能執行到的路徑至少執行一次。

補充：（1）語句覆蓋在所有的測試方法中是一種最弱的覆蓋。

（2）判定覆蓋和條件覆蓋比語句覆蓋強，滿足判定/條件覆蓋標準的測試用例一定也滿足判定覆蓋、條件覆蓋和語句覆蓋（3）路徑覆蓋也是一種比較強的覆蓋，但未必考慮判定條件結果的組合，并不能代替條件覆蓋和條件組合覆蓋。

3. 優缺點
   /1. 優點
   a.迫使測試人員去仔細思考軟件的實現
   b.可以檢測代碼中的每條分支和路徑
   c.揭示隱藏在代碼中的錯誤
   d.對代碼的測試比較徹底
   e.最優化
   /2. 缺點
   a.代價昂貴
   b.無法檢測代碼中遺漏的路徑和數據敏感性錯誤
   c.不驗證規格的正確性