軟件測試架構師的知識能力模型

測試架構師從事的并不是一項純測試技術的工作，而是一門需要結合產品、溝通協調、書面表達等綜合性的藝術，如圖1所示。

圖1　軟件測試架構師需具備的能力

從測試技術來說，軟件測試架構師需具備的測試技術能力：

軟件產品質量模型

測試類型

測試方法

探索式測試

自動化測試

1 軟件產品質量六屬性

 

圖2　軟件產品質量六屬性

1.1 功能性

表1　功能性子屬性

適合性：對Windows的計算器來說，軟件產品為用戶提供的所有和“計算”相關的功能，就是適合性。

準確性：對Windows的計算器來說，計算器本身計算結果的正確性是計算器軟件在準確性方面的一個表現

互操作性：對Windows的計算器來說，計算器中不同功能、特性之間是否能夠正確地相互配合是計算器在互操作性方面的一個表現；此外，對不同操作系統的支持，如對Windows 7不同版本（包括不同的補丁版本）的支持，對不同工作模式（如安全模式、帶網絡連接的安全模式）的支持也是互操作性的體現。

安全性：對Windows的計算器來說，計算器不應該包含能夠被利用的安全漏洞和與“用戶權限”相關的內容，如“管理員和訪客都應該有相同的使用權限”等。

功能順從性：對Windows的計算器來說，功能順從性可以理解為，作為一款計算器，計算規則（如平方運算、統計運算等）要和數學中的相關規則保持一致。

 

1.2 可靠性

下面3個層層遞進的句子，可以幫助我們來理解用戶可靠性方面的要求：

第一層：設備最好不要出故障；

第二層：設備出現故障了不要影響主要的功能和業務；

第三層：如果影響了主要功能和業務，系統可以盡快定位并恢復。

表2 可靠性子屬性

成熟性：對Windows的計算器來說，成熟性可以理解為產品的功能失效的概率。例如，計算器在持續運行一段時間后，就會出現計算方面錯誤。一般來說，這種錯誤都可以通過重啟軟件、重啟設備等方法恢復。

容錯性：對Windows的計算器來說，容錯性可以理解為產品對用戶“錯誤輸入”的處理應對能力

可恢復性：對Windows的計算器來說，可恢復性可以理解為計算器一旦出現了產品自身無法預期的異常（如無響應、重啟）后，能夠恢復。

可靠性順從性：對Windows的計算器來說，在可靠性順從性方面并沒有嚴格明確的標準，但是也會有一些潛在的約定，如計算器需要能夠識別出所有數學運算的異常輸入，并給出錯誤原因的提示。通信類產品在可靠性順從性方面就有比較嚴格的標準，如系統的故障率不能高于多少、故障恢復時間不能長于多少等。

 

1.3 可移植性

適應性：對Windows的計算器來說，適應性可以理解為，計算器在不同大小的顯示屏中，計算器的布局、大小、清晰度、按鍵的排列等是否都能正常地顯示。

可安裝性：對Windows的計算器來說，可安裝性可以理解為，計算器能否被順利安裝到不同的Windows操作系統上，并能正常運行。

共存性：對Windows的計算器來說，共存性可以理解為，計算器和其他軟件能夠同時在Windows中共存，不會存在資源（如CPU、內存等）爭搶方面的問題。

易替換性：對Windows的計算器來說，易替換性可以理解為，假設產品開發了新的計算器，新的計算器能夠成功替換掉老的計算器。（注意，此時不是指通過“產品升級”的方式，而是可能存在“新”“舊”兩個計算器同時共存的情況。）

可移植性的依從性：對Windows的計算器來說，可移植性的依從性可以理解為Windows產品在可移植性方面的一些約定。例如，計算器并不是針對某款特定的操作系統開發的，需要支持Windows所有操作系統。

 

2 測試類型

測試類型指的是測試需要考慮的不同角度。我們可以借助軟件產品質量模型（以下簡稱“質量模型”）來快速定義、理解測試類型。

圖3　質量屬性和測試類型的關系

表5　常見測試類型及其與質量屬性關系表

3 測試方法

3.1 產品測試車輪圖

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

圖4 產品測試車輪圖

圖4 描繪的質量屬性的六大類和測試類型之間的關系，并沒有深入到各個質量子屬性和各個子屬性對應的測試類型中去（大家不妨自己動手繪制一下“質量子屬性”的車輪圖）。

從“車輪圖”中能夠分析出產品測試的兩個關鍵問題：

一是如何保證測試驗證的“全面性”的問題。顯然，只要我們使用的測試方法能夠覆蓋六大質量屬性，我們的測試就不會出現大方向性的遺漏。

二是如何確定測試“深度”的問題。一般來說，測試團隊使用的測試方法越多，對產品就測試得越深。

這些都會影響測試的效果，影響測試對產品質量的評估。除此之外，“車輪圖”還能幫助我們評估測試團隊的能力。軟件測試人員能夠駕馭的測試方法越多，他的測試能力就越強。

3.2 功能測試方法

功能測試方法有：

單運行正常值輸入法。

單運行邊界值輸入法。

多運行順序執行法。

多運行相互作用法。

定義：

運行：在軟件測試中，測試人員模擬的用戶的“操作”或“行為”。

單運行：在軟件測試中，測試人員模擬的用戶的“一個操作”或“一個行為”。

多運行：在軟件測試中，測試人員模擬的用戶的“多個操作”或“多個行為”。

也就是說，“運行”是指從用戶的角度來看，有意義的操作或行為。從功能的層面來說，一個“運行”確定了“輸入”和“輸出”的一種可能的情況，如圖5所示。

圖5 功能層面的運行示意圖

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

圖6 功能與運行的關系

3.2.1單運行正常值輸入法　

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

3.2.2單運行邊界值輸入法

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

3.2.3多運行順序執行法

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

多運行順序執行法在和用戶的操作習慣相關的地方使用非常有效。

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

表6 多運行順序場景

序號 多運行場景 有關聯性 多運行順序

1 用戶先發送一封電子郵件后，再收到一封電子郵件 否 否

2 用戶收到一封電子郵件后，再接著發送這封收到的電子郵件 是 是

3 用戶收到一封電子郵件后，再發送一封任意電子郵件 否 否

3.2.4多運行相互作用法

多運行相互作用法是指在功能測試時把多個存在相互關系的運行組合在一起進行測試的方法，如圖7

圖7 多運行相互作用法

和多運行順序執行法強調多個運行之間的順序性不同，多運行相互作用法強調的是多個運行之間的關系性，這個關系可以是外在關系，如某個業務的順利進行需要多個運行之間相互協作；也可以是內在關系，如這些運行會用相同的資源（如內存或其他硬件資源）。

需要特別指出的是，都是“針對一個用戶”的操作場景，而不是“兩個不同的用戶同時發送郵件”或是“一個用戶發送郵件，一個用戶接收郵件”這樣的場景。事實上，前者屬于功能測試的范疇，而后者屬于可靠性測試的范疇。

3.3 可靠性測試方法

3.3.1 異常值輸入法

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

3.3.2 故障植入法

故障植入法是把系統放在有問題的環境中進行測試的一種可靠性測試法，主要能夠測試到的質量屬性是容錯性和成熟性。

和異常值輸入法不同，異常值輸入法是直接輸入一個系統認為是錯誤的、不支持的值；而故障植入法是把系統放在有問題的環境中，但是輸入依然是正常值。

用戶的業務環境中，會有哪些故障、錯誤或問題？列出這些場景，把系統放到這些場景中，運行正常的業務，分析此時系統的反應是否合理。

如果系統被部署在用戶的硬件環境中，考慮系統所需要的硬件資源，如CPU、內存、存儲空間等，在出現不足的情況下，系統的反應是否合理。還是以“用戶發送電子郵件”為例。網絡故障對用戶來說是一個常見的故障，如斷網，網絡時斷時續、存在丟包。

果系統被安裝在用戶的系統中，考慮系統在軟件沖突、驅動不正確等情況下，系統的反應是否合理。

如果系統是一個獨立的設備，考慮它的關鍵器件（如機框、單板、插卡、硬盤、芯片等）出現問題時，系統的反應是否合理。

3.3.3 穩定性測試法

穩定性測試法是在一段時間里，長時間大容量運行某種業務的一種可靠性測試法，它能夠非常有效地測試到系統的“成熟性”，是非常重要的一種可靠性測試法。

需要特別指出的是，穩定性測試法、壓力測試法和性能測試法是存在一定關系的，這個關系紐帶就是產品規格。

產品規格：產品承諾的能夠處理的最大容量或能力。例如，系統最多支持100個用戶并發登錄、系統最多支持建立100條安全策略都是產品規格。

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

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

壓力測試是在高于性能值的前提下進行測試的。雖然測試時負載超過了系統能夠處理的最大能力，但并不等于在這種情況下系統的功能都會失效，我們需要根據實際情況來分析系統的表現是否合理。例如，系統最多支持100個用戶并發登錄，但此時有110個用戶同時發起了登錄的操作，那么系統應該保證這110個用戶中有100個用戶能夠正常登錄，有10個用戶不能登錄才合理，而不是所有用戶都不能登錄。

現在讓我們再回到本節的主題——穩定性測試上（性能測試法、壓力測試法將在后文中陸續為大家介紹）。從方法的角度來說，穩定性測試法是所有測試方法中最為有趣的，可以總結為一個“四字訣”——多、并、復、異。

“多字訣”的要義是，在測試中通過增加用戶對功能的操作數量，來測試系統的穩定性。

“并字訣”的要義是，在測試中讓多個用戶同時來操作這個功能，由此來測試系統是否依然穩定。有時我們也稱這個測試為并發測試。

“復字訣”的要義是，在測試中讓一個或多個用戶，反復進行新建、刷新、刪除、同步、備份之類的操作，以此來測試系統是否穩定。

“異字訣”的要義是，在測試中讓一個或者多個用戶，反復進行異常操作，驗證系統是否能夠持續做出合理的反應。與異常輸入法和故障植入法相比，“異字訣”強調的是“持續”和“累積”。事實上，使用“異字訣”來測試往往還比較有效，這是因為，開發在編碼的時候，容易考慮正確情況下資源的申請和回收，忽視異常情況下資源的回收。

3.3.4 壓力測試法

壓力測試法是在一段時間內持續使用超過系統規格的負載進行測試的一種可靠性測試方法。

盡管產品已經聲明了規格，只承諾在規格范圍內才能提供穩定可靠的功能，不承諾在超過系統規格的情況下還能提供正確的功能，但壓力測試仍然是有意義的。一個重要的原因是，業務的突發現象——用戶的業務負載并不是平均的，可能在極短的時間里，出現超過負載的情況，但是平均下來，卻沒有超過規格，如圖9所示。

圖8 業務的突發現象

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

圖9 突發形態的負載模型

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

3.3.5 恢復測試法

恢復測試法是指使用持續超過規格的負載進行了測試后，再將負載降到規格以內的測試方法，如圖10

圖10 恢復測試法

持續進行超過規格的負載測試時，允許規格內的業務不是100%正確。當負載降到規格值之內后，業務必須能夠恢復到100%的正確。

為了加深大家對壓力測試法和恢復測試法的理解，我們不妨來對比一下兩個模型在不同負載下對“業務”結果的期望，如圖11所示。

圖11 突發負載模式和持續負載模式對業務結果的期望

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

3.4 性能測試方法

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

一般來說，產品的需求規格會給出性能期望值，測試者只需要確認產品能否達到規格即可。假如需求規格中對產品性能規格定義得很簡單、很粗糙，我們可以按圖12進行性能測試

圖12 測試流程

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

在進行性能測試時，我們可以先試著測試出系統最好的性能值。我們可以以性能規格中要求的性能值作為測試的項目，測試出這些指標在系統中的極限。

不同產品的性能規格可能會千差萬別，但總的來說，卻可以分為以下兩類。

1）系統能夠正確處理新業務的最大能力

系統能夠正確處理新業務的最大能力，我們也稱為“新建”。例如，系統每秒能夠允許多少新用戶上線登錄、系統每秒能夠主動發起多少新的連接等。

針對系統的新建能力進行性能測試，測試的是系統為一個新業務從分配資源到完成處理流程的速度。業務處理流程和資源的總量都會影響系統的新建能力。需要注意的是，系統不能只“建”不“拆”：已經完成或異常的業務需要被及時拆除，占用的資源要能夠被回收，用于新的業務。

2）系統能夠同時正確處理的最大業務能力

系統能夠同時正確處理的最大業務能力，我們也稱為“并發”。例如，系統能夠支持的最大用戶同時在線數、系統能夠同時發起的最大連接數等。

需要特別指出的是，“新建”和“并發”之間是存在關系的，如圖13所示。

圖13 新建和并發測試情況

注意：新建和并發這兩個指標會互相影響，比如最大并發能力是4000，測試的時候只“建”不“拆”，當每秒新建150條，到24秒時，并行數大于最大并發能力是4000，而導致新建數降低。

因此，我們在測試系統最好的性能值時，需要注意測試指標之間的內在關系，在測試一個指標的時候，別的指標不能對這個指標造成影響。

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

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

表7　在樣本點能夠正確處理的最大郵件數

 

表8 在不同過濾策略下能夠正確處理的最大郵件數

通過測試這些性能值，我們很容易得到：

哪些因素對系統性能的影響大，哪些因素對系統性能的影響不大。

各個因素對性能的影響趨勢。通過挑選測試的樣本，通過數學中的“曲線擬合”技術，得到因素的影響曲線，我們可以通過曲線來分析這個下降趨勢是否合理。

在各個因素下，性能的最壞值。分析這個最壞值是否合理，是否會成為系統的性能“瓶頸”。

很多時候，影響一個性能指標的因素并不是單一的，而可能會有多個。在這個步驟中僅測試單個因素對性能的影響即可，多個因素對性能的影響可以放在典型場景中，選擇典型的配置和業務來進行性能測試。

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

最后我們以“場景”為單位，來測試這個場景中的典型配置、典型業務下的性能值。

以“用戶發送郵件”為例，假設在這個場景下，典型的配置為“200條過濾策略”，郵件大小為1KB、10KB、2MB以1：2：1混合情況下，郵件系統每秒能夠接收并正確處理的最大郵件數。

3.5 易用性測試法

3.5.1 一致性測試法

一致性測試法在測試中關注的是產品的用戶界面：

風格、布局、元素上是否一致、統一。

布局的合理性、操作的合理性、提示等是否符合UI設計規范。

一致性測試法能夠測試到產品在易理解和易用性依從性方面的能力，但它并不關心產品功能是否正確，所以可以直接對產品的UI設計原型進行測試

3.5.2 可用性測試法

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

表9　可用性測試的關注點和標準

4 測試設計技術

 

表9　“用戶發送電子郵件”的測試點

4.1 測試點不等于測試用例

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

問題1：這些測試點在內容上有重復，存在冗余。

例如，測試點1、測試點4都會測試到“正確發送郵件”。

問題2：一些測試點的測試輸入不明確，不知道測試時要測試哪些。

例如，測試測試點1時，我們并不知道我們要測試哪些“正常的輸入數據”。存在類似問題的還有測試點5。

問題3：總是在搭相似的環境，做類似的操作。

有些測試點之間存在一定的執行順序，需要把這些測試點放在一起測試。例如，先執行測試點6，再緊接著執行測試點11，可以最大限度地利用之前的測試環境和測試結果。

問題4：測試點描述得太粗，不知道是不是測對了。

有些測試點寫得很粗，我們不知道測試目標是什么，或是該關注哪些地方。例如，測試點4，我們不知道將“用戶發送電子郵件”和“用戶接收的電子郵件”這兩個操作放在一起，它們的“交互點”在哪里？

4.2 四步測試設計法

把測試點加工為測試用例，就叫測試設計，在這個過程中使用的方法就叫測試設計方法。路徑分析法、判定表、正交分析法、等價類、邊界值等都是常見的測試設計方法。

在測試分析中，我們對被測對象按照測試方法進行思考，就能得到測試點，所以測試分析是一個“發現性”的過程，如圖14所示，而測試設計不同。

圖14 測試分析是一個“發現性”的過程

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

圖15 四步測試設計法的四個關鍵步驟

第一步：建模

其實，在這個步驟中，我們并不是要大家對每個測試點都原創出一些測試模型，而是根據測試點的特征，為測試點選擇一個適合后續測試設計的模型。也許我們稱這個步驟為“選模”更為貼切。

既然“選模”需要參考測試點的特征，研究測試點、分析特征的情況并對其進行歸類是必不可少的。目前我們將其分為四類：

類型1：“流程”；

類型2：“參數”；

類型3：“數據”；

類型4：“組合”。

對每一類測試點，我們都給出了一些最適合的“建模”方法：

對“流程”類，可以通過繪制“流程圖”來建立測試模型。

對“參數”類，可以通過“輸入輸出表”來建立測試模型。

對“數據”類，可以通過“等價類分析表”來建立測試模型。

對“組合”類，可以通過“因子表”來建立測試模型。

第二步：設計基礎測試用例。

在這個步驟中，我們會對已經建立好的測試模型，來設計一些基礎測試用例，覆蓋這個測試模型。

測試用例和基礎測試用例最大的差別在于，測試用例確定了測試條件（類似“在××情況下，進行××的測試”的描述）和測試數據（就是輸入的“參數值”或“數值”），而基礎測試用例只確定了測試條件。

第三步：補充測試數據。

在這個步驟中，我們為基礎測試用例來確定測試輸入，補充測試數據，這時基礎測試用例就升級成真正的測試用例了。

第四步：擴展。

模型不是銀彈，不能解決測試設計的所有問題。我們還需要根據經驗，特別是對系統哪些地方容易發生缺陷的認識，補充一些測試用例，增加系統的有效性。

對測試點進行分類

在使用四步測試方法之前，我們首先要對測試點進行分類。分類的依據，就是看測試點是否有“流程”類的特征、“參數”類的特征、“數據”類的特征、“組合”類的特征。

原文轉自：http://www.uml.org.cn/Test/202206094.asp