產品測試車輪圖

測試型別，即測試要從哪些角度去測試產品，確定了測試的思路。接下來我們要討論的就是怎麼做的問題了，即具體的測試方法。

圖描繪的質量屬性的六大類和測試型別之間的關係，並沒有深入到各個質量子屬性和各個子屬性對應的測試型別中去

從“車輪圖”中能夠分析出產品測試的兩個關鍵問題：
一是如何保證測試驗證的“全面性”的問題。
顯然，只要我們使用的測試方法能夠覆蓋六大質量屬性，我們的測試就不會出現大方向性的遺漏。
二是如何確定測試“深度”的問題。
一般來說，測試團隊使用的測試方法越多，對產品就測試得越深。
這些都會影響測試的效果，影響測試對產品質量的評估。
除此之外，“車輪圖”還能幫助我們評估測試團隊的能力。
軟體測試人員能夠駕馭的測試方法越多，他的測試能力就越強。

功能測試方法

單執行正常值輸入法。
單執行邊界值輸入法。
多執行順序執行法。
多執行相互作用法。
PS:在軟體測試中，測試人員模擬的使用者的“操作”或“行為”。

單執行：在軟體測試中，測試人員模擬的使用者的“一個操作”或“一個行為”。
多執行：在軟體測試中，測試人員模擬的使用者的“多個操作”或“多個行為”。
也就是說，“執行”是指從使用者的角度來看，有意義的操作或行為。
從功能的層面來說，一個“執行”確定了“輸入”和“輸出”的一種可能的情況，如圖所示。

有時候，我們會從設計的角度來劃分功能，不能為使用者提供一個完整的、有意義的行為
eg:
“使用者和郵件伺服器建立了一個新的連線”
“郵件伺服器刪掉了和使用者的連線”
這種細粒度的功能即使確定了輸入和輸出，都不算作“執行”。
這時，可以將多個功能組合起來，直到這個功能能夠為使用者提供完整的、有意義的行為為止，如圖所示。

單執行正常值輸入法

就是測試時輸入的“A1”和“A2”是系統允許的“正常值”的測試方法。

單執行邊界值輸入法

就是測試時輸入的“A1”和“A2”是系統的“邊界值”的測試方法。

多執行順序執行法

將多個“單執行”操作放在一起考慮，得到的結果就是“多執行”操作。
使用多執行順序執行法進行測試時，分析各個執行之間的順序性，是使用該方法的關鍵。
多執行順序執行法在和使用者的操作習慣相關的地方使用非常有效。

此外，多執行順序執行法也比較適合使用在功能的配置測試上。

多執行相互作用法

多執行相互作用法是指在功能測試時把多個存在相互關係的執行組合在一起進行測試的方法
和多執行順序執行法強調多個執行之間的順序性不同，多執行相互作用法強調的是多個執行之間的關係性，這個關係可以是外在關係，如某個業務的順利進行需要多個執行之間相互協作；也可以是內在關係，如這些執行會用相同的資源（如記憶體或其他硬體資源）。
需要特別指出的是，都是“針對一個使用者”的操作場景，而不是“兩個不同的使用者同時傳送郵 件”或是“一個使用者傳送郵件，一個使用者接收郵件”這樣的場景。事實上，前者屬於功能測試的範疇，而後者屬於可靠性測試的範疇。

可靠性測試方法

異常值輸入法

異常值輸入法是一種使用系統不允許使用者輸入的數值（即異常值）作為測試輸入的可靠性測試方法。

故障植入法

故障植入法是把系統放在有問題的環境中進行測試的一種可靠性測試法，主要能夠測試到的質量屬性是容錯性和成熟性。
和異常值輸入法不同，異常值輸入法是直接輸入一個系統認為是錯誤的、不支援的值；而故障植入法是把系統放在有問題的環境中，但是輸入依然是正常值。

使用者的業務環境中，會有哪些故障、錯誤或問題？列出這些場景，把系統放到這些場景中，執行正常的業務，分析此時系統的反應是否合理。
如果系統被部署在使用者的硬體環境中，考慮系統所需要的硬體資源，如CPU、記憶體、儲存空間等，在出現不足的情況下，系統的反應是否合理。還是以“使用者傳送電子郵件”為例。網路故障對使用者來說是一個常見的故障，如斷網，網路時斷時續、存在丟包。
果系統被安裝在使用者的系統中，考慮系統在軟體衝突、驅動不正確等情況下，系統的反應是否合理。
如果系統是一個獨立的裝置，考慮它的關鍵器件（如機框、單板、插卡、硬碟、晶片等）出現問題時，系統的反應是否合理。

穩定性測試法

穩定性測試法是在一段時間裡，長時間大容量執行某種業務的一種可靠性測試法，它能夠非常有效地測試到系統的“成熟性”，是非常重要的一種可靠性測試法。
需要特別指出的是，穩定性測試法、壓力測試法和效能測試法是存在一定關係的，這個關係紐帶就是產品規格。
產品規格：產品承諾的能夠處理的最大容量或能力。例如，系統最多支援100個使用者併發登入、系統最多支援建立100條安全策略都是產品規格。

效能測試的目的就是測試產品真實規格是否和說明書中承諾的需求規格一致。顯然，最後我們實測出來的效能值，就是系統真正能夠處理的最大容量或者能力。

穩定性測試是在低於效能值的前提下測試的。事實上，使用者在使用系統時，也不會時時刻刻讓系統在極限的狀態執行，在測試時，我們可以控制測試中的負載量，使其和使用者的實際使用情況儘量接近，使得測試能夠更為準確，更有價值。

壓力測試是在高於效能值的前提下進行測試的。雖然測試時負載超過了系統能夠處理的最大能力，但並不等於在這種情況下系統的功能都會失效，我們需要根據實際情況來分析系統的表現是否合理。
例如，系統最多支援100個使用者併發登入，但此時有110個使用者同時發起了登入的操作，那麼系統應該保證這110個使用者中有100個使用者能夠正常登入， 有10個使用者不能登入才合理，而不是所有使用者都不能登入。
現在讓我們再回到穩定性測試上（。從方法的角度來說，穩定性測試法是所有測試方法中最為有趣的，可以總結為一個“四字訣”——多、並、復、異。

“多字訣”的要義是，在測試中通過增加使用者對功能的運算元量，來測試系統的穩定性。
“並字訣”的要義是，在測試中讓多個使用者同時來操作這個功能，由此來測試系統是否依然穩定。有時我們也稱這個測試為併發測試。 “復字訣”的要義是，在測試中讓一個或多個使用者，反覆進行新建、重新整理、刪除、同步、備份之類的操作，以此來測試系統是否穩定。
“異字訣”的要義是，在測試中讓一個或者多個使用者，反覆進行異常操作，驗證系統是否能夠持續做出合理的反應。與異常輸入法和故障植入法相比，“異字訣”強調的是“持續”和“累積”。事實上，使用“異字訣”來測試往往還比較有效，這是因為，開發在編碼的時候，容易考慮正確情況下資源的申請和回收，忽視異常情況下資源的回收。

壓力測試法

壓力測試法是在一段時間內持續使用超過系統規格的負載進行測試的一種可靠性測試方法。
儘管產品已經聲明瞭規格，只承諾在規格範圍內才能提供穩定可靠的功能，不承諾在超過系統規格的情況下還能提供正確的功能，但壓力測試仍然是有意義的。一個重要的原因是，業務的突發現象——使用者的業務負載並不是平均的，可能在極短的時間裡，出現超過負載的情況，但是平均下來，卻沒有超過規格。

我們希望系統在突發的情況下不會像紙牌屋那樣脆弱，而是有切實的應對措施，如不處理超過系統規格的負載、記錄日誌供使用者分析突發原因等。不會因為突發情況導致宕機、反覆重啟等致命問題，這才是我們進行壓力測試的真正目的。為了達到這個測試目標，我們在進行壓力測試時，需要使用突發形態的負載模型

不建議用持續超過系統規格負載這樣的測試方法來挖掘產品的問題。但是對測試來說，使用持續超過規格的負載模型測試也並不是完全沒有意義，它是我們另外一種可靠性測試法—— 恢復測試法的組成部分
恢復測試法
恢復測試法是指使用持續超過規格的負載進行了測試後，再將負載降到規格以內的測試方法，如圖

持續進行超過規格的負載測試時，允許規格內的業務不是100%正確。當負載降到規格值之內後，業務必須能夠恢復到100%的正確。
為了加深大家對壓力測試法和恢復測試法的理解，我們不妨來對比一下兩個模型在不同負載下對“業務”結果的期望，如圖所示

可見，兩個測試方法最大的差別，在於圖中“黑色”的部分。在使用突發負載模式進行壓力測試時，圖中的黑色部分是不允許出現業務失敗的，而使用持續負載模式進行恢復測試時，黑色部分允許出現業務失敗。

效能測試方法

效能測試的目的是測試產品真實規格是否和說明書中承諾的需求規格一致，我們實測出來的效能值，就是系統真正能夠處理的最大容量或者能力。
一般來說，產品的需求規格會給出效能期望值，測試者只需要確認產品能否達到規格即可。假如需求規格中對產品效能規格定義得很簡單、很粗糙，我們可以按圖進行效能測試

第一步 測試出系統最好的效能值

在進行效能測試時，我們可以先試著測試出系統最好的效能值。
我們可以以效能規格中要求的效能值作為測試的專案，測試出這些指標在系統中的極限。
不同產品的效能規格可能會千差萬別，但總的來說，卻可以分為以下兩類。
1）系統能夠正確處理新業務的最大能力,我們也稱為“新建”。
例如，系統每秒能夠允許多少新使用者上線登入、系統每秒能夠主動發起多少新的連線等。
針對系統的新建能力進行效能測試，測試的是系統為一個新業務從分配資源到完成處理流程的速度。
業務處理流程和資源的總量都會影響系統的新建能力。
需要注意的是，系統不能 只“建”不“拆”：已經完成或異常的業務需要被及時拆除，佔用的資源要能夠被回收，用於新的業務。
2）系統能夠同時正確處理的最大業務能力，我們也稱為“併發”。
例如，系統能夠支援的最大使用者同時線上數、系統能夠同時發起的最大連線數等。
需要特別指出的是，“新建”和“併發”之間是存在關係的，如圖所示。

注意：新建和併發這兩個指標會互相影響，比如最大併發能力是4000，測試的時候
只“建”不“拆”，當每秒新建150條，到24秒時，並行數大於最大併發能力是4000，而導致新建數降低。
因此，我們在測試系統最好的效能值時，需要注意測試指標之間的內在關係，在測試一個指標的時候，別的指標不能對這個指標造成影響。

第二步 分析會影響效能值的各種因素，測試它們對效能的影響

配置”和“業務”都會對效能指標產生影響。
試想一下，配置了1條使用者策略和配置了1000條使用者策略的效能應該是不同的；系統接收1位元組大小的郵件和接收10M大小的郵件測試出來的效能值也是不同的。在這個步驟中，我們要分析出系統中的哪些因素對效能有影響（效能下
降），然後進行測試，分析效能下降是否符合預期，最壞的情況是否還算合理。

通過測試這些效能值，我們很容易得到：
哪些因素對系統性能的影響大，哪些因素對系統性能的影響不大。
各個因素對效能的影響趨勢。通過挑選測試的樣本，通過數學中的“曲線擬合”技術，得到因素的影響曲線，我們可以通過曲線來分析這個下降趨勢是否合理。
在各個因素下，效能的最壞值。分析這個最壞值是否合理，是否會成為系統的效能“瓶頸”。
很多時候，影響一個性能指標的因素並不是單一的，而可能會有多個。在這個步驟中僅測試單個因素對效能的影響即可，多個因素對效能的影響可以放在典型場景中，選擇典型的配置和業務來進行效能測試。

第三步 以場景為單位來測試效能

最後我們以“場景”為單位，來測試這個場景中的典型配置、典型業務下的效能值。
以“使用者傳送郵件”為例，假設在這個場景下，典型的配置為“200條過濾策略”，郵件大小為1KB、10KB、2MB以1：2：1混合情況下，郵件系統每秒能夠接收並正確處理的最大郵件數。

一致性測試法

一致性測試法在測試中關注的是產品的使用者介面：

風格、佈局、元素上是否一致、統一。
佈局的合理性、操作的合理性、提示等是否符合UI設計規範。
一致性測試法能夠測試到產品在易理解和易用性依從性方面的能力，但它並不關心產品功能是否正確，所以可以直接對產品的UI設計原型進行測試

可用性測試法

可用性測試法的測試物件也是使用者介面，但在可用性測試中，我們關注的是產品提供的功 能，對使用者來說是否易於學習理解、易於使用，所以可用性測試需要和功能測試結合起來， 以場景作為測試粒度，以使用者的視角進行測試。

可移植性測試

可移植性測試是確定軟體元件或應用程式可以從一個硬體、軟體或其他操作或使用環境中有效和有效地轉移到另一個系統的容易或困難程度的過程。
測試結果, 由系統的各自的需要定義,通常以適應軟體的費用到新的環境與重建的費用相比。

可維護性測試

可維護性被定義為可以輕鬆地對軟體系統進行更改。這些變化可能需要糾正故障, 適應新的要求, 增加新的功能, 刪除現有的功能或糾正錯誤或缺陷發生時, 可以完善, 適應或行動為降低進一步的維護成本而採取的措施。
可維護性測試與維護測試不同, 它是測試已修改的軟體。
可維護性可以是靜態測試形式, 即通過檢查和檢查進行, 或者是動態形式, 即測量執行維護活動所需的工作量。

一些補充

測試點不等於測試用例

如果我們拿測試點來進行測試，會發現很多讓我們不爽、困惑的問題：

問題1：這些測試點在內容上有重複，存在冗餘。
例如，測試點1、測試點4都會測試到“正確傳送郵件”。

問題2：一些測試點的測試輸入不明確，不知道測試時要測試哪些。
例如，測試測試點1時，我們並不知道我們要測試哪些“正常的輸入資料”。存在類似問題的還有測試點5。
問題3：總是在搭相似的環境，做類似的操作。
有些測試點之間存在一定的執行順序，需要把這些測試點放在一起測試。例如，先執行測試點6，再緊接著執行測試點11，可以最大限度地利用之前的測試環境和測試結果。

問題4：測試點描述得太粗，不知道是不是測對了。
有些測試點寫得很粗，我們不知道測試目標是什麼，或是該關注哪些地方。例如，測試點4，我們不知道將“使用者傳送電子郵件”和“使用者接收的電子郵件”這兩個操作放在一起，它們的“互動點”在哪裡？

四步測試設計法

把測試點加工為測試用例，就叫測試設計，在這個過程中使用的方法就叫測試設計方法。
路徑分析法、判定表、正交分析法、等價類、邊界值等都是常見的測試設計方法。
在測試分析中，我們對被測物件按照測試方法進行思考，就能得到測試點，所以測試分析是一個“發現性”的過程，如圖所示，而測試設計不同。

讓兩個測試者根據“車輪圖”來分析同一個測試物件，他們得到的測試點差異並不會太大，但是最後生成的測試用例卻會千差萬別。
這是因為，從測試點到測試設計，我們會加工測試點， 對它們進行組合、拆分，選擇測試資料，等等，這是個“創造性”的過程。

第一步：建模
其實，在這個步驟中，我們並不是要大家對每個測試點都原創出一些測試模型，而是根據測試點的特徵，為測試點選擇一個適合後續測試設計的模型。也許我們稱這個步驟為“選模”更為貼切。
既然“選模”需要參考測試點的特徵，研究測試點、分析特徵的情況並對其進行歸類是必不可少的。目前我們將其分為四類：

型別1：“流程”；型別2：“引數”； 型別3：“資料”； 型別4：“組合”。
對每一類測試點，我們都給出了一些最適合的“建模”方法：

對“流程”類，可以通過繪製“流程圖”來建立測試模型。 對“引數”類，可以通過“輸入輸出表”來建立測試模型。 對“資料”類，可以通過“等價類分析表”來建立測試模型。對“組合”類，可以通過“因子表”來建立測試模型。

第二步：設計基礎測試用例。
在這個步驟中，我們會對已經建立好的測試模型，來設計一些基礎測試用例，覆蓋這個測試模型。
測試用例和基礎測試用例最大的差別在於，測試用例確定了測試條件（類似“在××情況下，進行××的測試”的描述）和測試資料（就是輸入的“引數值”或“數值”），而基礎測試用例只確定了測試條件。
第三步：補充測試資料。
在這個步驟中，我們為基礎測試用例來確定測試輸入，補充測試資料，這時基礎測試用例就升級成真正的測試用例了。
第四步：擴充套件。
模型不是銀彈，不能解決測試設計的所有問題。我們還需要根據經驗，特別是對系統哪些地方容易發生缺陷的認識，補充一些測試用例，增加系統的有效性。
對測試點進行分類
在使用四步測試方法之前，我們首先要對測試點進行分類。分類的依據，就是看測試點是否有“流程”類的特徵、“引數”類的特徵、“資料”類的特徵、“組合”類的特徵。