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

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

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

從測試技術(shù)來(lái)說(shuō)，軟件測試架構師需具備的測試技術(shù)能力：

軟件產(chǎn)品質(zhì)量模型

測試類(lèi)型

測試方法

探索式測試

自動(dòng)化測試

1 軟件產(chǎn)品質(zhì)量六屬性

 

圖2　軟件產(chǎn)品質(zhì)量六屬性

1.1 功能性

表1　功能性子屬性

適合性：對Windows的計算器來(lái)說(shuō)，軟件產(chǎn)品為用戶(hù)提供的所有和“計算”相關(guān)的功能，就是適合性。

準確性：對Windows的計算器來(lái)說(shuō)，計算器本身計算結果的正確性是計算器軟件在準確性方面的一個(gè)表現

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

安全性：對Windows的計算器來(lái)說(shuō)，計算器不應該包含能夠被利用的安全漏洞和與“用戶(hù)權限”相關(guān)的內容，如“管理員和訪(fǎng)客都應該有相同的使用權限”等。

功能順從性：對Windows的計算器來(lái)說(shuō)，功能順從性可以理解為，作為一款計算器，計算規則（如平方運算、統計運算等）要和數學(xué)中的相關(guān)規則保持一致。

 

1.2 可靠性

下面3個(gè)層層遞進(jìn)的句子，可以幫助我們來(lái)理解用戶(hù)可靠性方面的要求：

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

第二層：設備出現故障了不要影響主要的功能和業(yè)務(wù)；

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

表2 可靠性子屬性

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

容錯性：對Windows的計算器來(lái)說(shuō)，容錯性可以理解為產(chǎn)品對用戶(hù)“錯誤輸入”的處理應對能力

可恢復性：對Windows的計算器來(lái)說(shuō)，可恢復性可以理解為計算器一旦出現了產(chǎn)品自身無(wú)法預期的異常（如無(wú)響應、重啟）后，能夠恢復。

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

 

1.3 可移植性

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

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

共存性：對Windows的計算器來(lái)說(shuō)，共存性可以理解為，計算器和其他軟件能夠同時(shí)在Windows中共存，不會(huì )存在資源（如CPU、內存等）爭搶方面的問(wèn)題。

易替換性：對Windows的計算器來(lái)說(shuō)，易替換性可以理解為，假設產(chǎn)品開(kāi)發(fā)了新的計算器，新的計算器能夠成功替換掉老的計算器。（注意，此時(shí)不是指通過(guò)“產(chǎn)品升級”的方式，而是可能存在“新”“舊”兩個(gè)計算器同時(shí)共存的情況。）

可移植性的依從性：對Windows的計算器來(lái)說(shuō)，可移植性的依從性可以理解為Windows產(chǎn)品在可移植性方面的一些約定。例如，計算器并不是針對某款特定的操作系統開(kāi)發(fā)的，需要支持Windows所有操作系統。

 

2 測試類(lèi)型

測試類(lèi)型指的是測試需要考慮的不同角度。我們可以借助軟件產(chǎn)品質(zhì)量模型（以下簡(jiǎn)稱(chēng)“質(zhì)量模型”）來(lái)快速定義、理解測試類(lèi)型。

圖3　質(zhì)量屬性和測試類(lèi)型的關(guān)系

表5　常見(jiàn)測試類(lèi)型及其與質(zhì)量屬性關(guān)系表

3 測試方法

3.1 產(chǎn)品測試車(chē)輪圖

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

圖4 產(chǎn)品測試車(chē)輪圖

圖4 描繪的質(zhì)量屬性的六大類(lèi)和測試類(lèi)型之間的關(guān)系，并沒(méi)有深入到各個(gè)質(zhì)量子屬性和各個(gè)子屬性對應的測試類(lèi)型中去（大家不妨自己動(dòng)手繪制一下“質(zhì)量子屬性”的車(chē)輪圖）。

從“車(chē)輪圖”中能夠分析出產(chǎn)品測試的兩個(gè)關(guān)鍵問(wèn)題：

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

二是如何確定測試“深度”的問(wèn)題。一般來(lái)說(shuō)，測試團隊使用的測試方法越多，對產(chǎn)品就測試得越深。

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

3.2 功能測試方法

功能測試方法有：

單運行正常值輸入法。

單運行邊界值輸入法。

多運行順序執行法。

多運行相互作用法。

定義：

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

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

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

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

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

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

圖6 功能與運行的關(guān)系

3.2.1單運行正常值輸入法　

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

3.2.2單運行邊界值輸入法

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

3.2.3多運行順序執行法

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

多運行順序執行法在和用戶(hù)的操作習慣相關(guān)的地方使用非常有效。

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

表6 多運行順序場(chǎng)景

序號 多運行場(chǎng)景 有關(guān)聯(lián)性 多運行順序

1 用戶(hù)先發(fā)送一封電子郵件后，再收到一封電子郵件 否 否

2 用戶(hù)收到一封電子郵件后，再接著(zhù)發(fā)送這封收到的電子郵件 是 是

3 用戶(hù)收到一封電子郵件后，再發(fā)送一封任意電子郵件 否 否

3.2.4多運行相互作用法

多運行相互作用法是指在功能測試時(shí)把多個(gè)存在相互關(guān)系的運行組合在一起進(jìn)行測試的方法，如圖7

圖7 多運行相互作用法

和多運行順序執行法強調多個(gè)運行之間的順序性不同，多運行相互作用法強調的是多個(gè)運行之間的關(guān)系性，這個(gè)關(guān)系可以是外在關(guān)系，如某個(gè)業(yè)務(wù)的順利進(jìn)行需要多個(gè)運行之間相互協(xié)作；也可以是內在關(guān)系，如這些運行會(huì )用相同的資源（如內存或其他硬件資源）。

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

3.3 可靠性測試方法

3.3.1 異常值輸入法

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

3.3.2 故障植入法

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

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

用戶(hù)的業(yè)務(wù)環(huán)境中，會(huì )有哪些故障、錯誤或問(wèn)題？列出這些場(chǎng)景，把系統放到這些場(chǎng)景中，運行正常的業(yè)務(wù)，分析此時(shí)系統的反應是否合理。

如果系統被部署在用戶(hù)的硬件環(huán)境中，考慮系統所需要的硬件資源，如CPU、內存、存儲空間等，在出現不足的情況下，系統的反應是否合理。還是以“用戶(hù)發(fā)送電子郵件”為例。網(wǎng)絡(luò )故障對用戶(hù)來(lái)說(shuō)是一個(gè)常見(jiàn)的故障，如斷網(wǎng)，網(wǎng)絡(luò )時(shí)斷時(shí)續、存在丟包。

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

如果系統是一個(gè)獨立的設備，考慮它的關(guān)鍵器件（如機框、單板、插卡、硬盤(pán)、芯片等）出現問(wèn)題時(shí)，系統的反應是否合理。

3.3.3 穩定性測試法

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

需要特別指出的是，穩定性測試法、壓力測試法和性能測試法是存在一定關(guān)系的，這個(gè)關(guān)系紐帶就是產(chǎn)品規格。

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

性能測試的目的就是測試產(chǎn)品真實(shí)規格是否和說(shuō)明書(shū)中承諾的需求規格一致。顯然，最后我們實(shí)測出來(lái)的性能值，就是系統真正能夠處理的最大容量或者能力。

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

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

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

“多字訣”的要義是，在測試中通過(guò)增加用戶(hù)對功能的操作數量，來(lái)測試系統的穩定性。

“并字訣”的要義是，在測試中讓多個(gè)用戶(hù)同時(shí)來(lái)操作這個(gè)功能，由此來(lái)測試系統是否依然穩定。有時(shí)我們也稱(chēng)這個(gè)測試為并發(fā)測試。

“復字訣”的要義是，在測試中讓一個(gè)或多個(gè)用戶(hù)，反復進(jìn)行新建、刷新、刪除、同步、備份之類(lèi)的操作，以此來(lái)測試系統是否穩定。

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

3.3.4 壓力測試法

壓力測試法是在一段時(shí)間內持續使用超過(guò)系統規格的負載進(jìn)行測試的一種可靠性測試方法。

盡管產(chǎn)品已經(jīng)聲明了規格，只承諾在規格范圍內才能提供穩定可靠的功能，不承諾在超過(guò)系統規格的情況下還能提供正確的功能，但壓力測試仍然是有意義的。一個(gè)重要的原因是，業(yè)務(wù)的突發(fā)現象——用戶(hù)的業(yè)務(wù)負載并不是平均的，可能在極短的時(shí)間里，出現超過(guò)負載的情況，但是平均下來(lái)，卻沒(méi)有超過(guò)規格，如圖9所示。

圖8 業(yè)務(wù)的突發(fā)現象

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

圖9 突發(fā)形態(tài)的負載模型

不建議用持續超過(guò)系統規格負載這樣的測試方法來(lái)挖掘產(chǎn)品的問(wèn)題。但是對測試來(lái)說(shuō)，使用持續超過(guò)規格的負載模型測試也并不是完全沒(méi)有意義，它是我們另外一種可靠性測試法——恢復測試法的組成部分

3.3.5 恢復測試法

恢復測試法是指使用持續超過(guò)規格的負載進(jìn)行了測試后，再將負載降到規格以?xún)鹊臏y試方法，如圖10

圖10 恢復測試法

持續進(jìn)行超過(guò)規格的負載測試時(shí)，允許規格內的業(yè)務(wù)不是100%正確。當負載降到規格值之內后，業(yè)務(wù)必須能夠恢復到100%的正確。

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

圖11 突發(fā)負載模式和持續負載模式對業(yè)務(wù)結果的期望

可見(jiàn)，兩個(gè)測試方法最大的差別，在于圖中“黑色”的部分。在使用突發(fā)負載模式進(jìn)行壓力測試時(shí)，圖中的黑色部分是不允許出現業(yè)務(wù)失敗的，而使用持續負載模式進(jìn)行恢復測試時(shí)，黑色部分允許出現業(yè)務(wù)失敗。

3.4 性能測試方法

性能測試的目的是測試產(chǎn)品真實(shí)規格是否和說(shuō)明書(shū)中承諾的需求規格一致，我們實(shí)測出來(lái)的性能值，就是系統真正能夠處理的最大容量或者能力。

一般來(lái)說(shuō)，產(chǎn)品的需求規格會(huì )給出性能期望值，測試者只需要確認產(chǎn)品能否達到規格即可。假如需求規格中對產(chǎn)品性能規格定義得很簡(jiǎn)單、很粗糙，我們可以按圖12進(jìn)行性能測試

圖12 測試流程

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

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

不同產(chǎn)品的性能規格可能會(huì )千差萬(wàn)別，但總的來(lái)說(shuō)，卻可以分為以下兩類(lèi)。

1）系統能夠正確處理新業(yè)務(wù)的最大能力

系統能夠正確處理新業(yè)務(wù)的最大能力，我們也稱(chēng)為“新建”。例如，系統每秒能夠允許多少新用戶(hù)上線(xiàn)登錄、系統每秒能夠主動(dòng)發(fā)起多少新的連接等。

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

2）系統能夠同時(shí)正確處理的最大業(yè)務(wù)能力

系統能夠同時(shí)正確處理的最大業(yè)務(wù)能力，我們也稱(chēng)為“并發(fā)”。例如，系統能夠支持的最大用戶(hù)同時(shí)在線(xiàn)數、系統能夠同時(shí)發(fā)起的最大連接數等。

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

圖13 新建和并發(fā)測試情況

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

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

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

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

表7　在樣本點(diǎn)能夠正確處理的最大郵件數

 

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

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

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

各個(gè)因素對性能的影響趨勢。通過(guò)挑選測試的樣本，通過(guò)數學(xué)中的“曲線(xiàn)擬合”技術(shù)，得到因素的影響曲線(xiàn)，我們可以通過(guò)曲線(xiàn)來(lái)分析這個(gè)下降趨勢是否合理。

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

很多時(shí)候，影響一個(gè)性能指標的因素并不是單一的，而可能會(huì )有多個(gè)。在這個(gè)步驟中僅測試單個(gè)因素對性能的影響即可，多個(gè)因素對性能的影響可以放在典型場(chǎng)景中，選擇典型的配置和業(yè)務(wù)來(lái)進(jìn)行性能測試。

第三步 以場(chǎng)景為單位來(lái)測試性能

最后我們以“場(chǎng)景”為單位，來(lái)測試這個(gè)場(chǎng)景中的典型配置、典型業(yè)務(wù)下的性能值。

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

3.5 易用性測試法

3.5.1 一致性測試法

一致性測試法在測試中關(guān)注的是產(chǎn)品的用戶(hù)界面：

風(fēng)格、布局、元素上是否一致、統一。

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

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

3.5.2 可用性測試法

可用性測試法的測試對象也是用戶(hù)界面，但在可用性測試中，我們關(guān)注的是產(chǎn)品提供的功能，對用戶(hù)來(lái)說(shuō)是否易于學(xué)習理解、易于使用，所以可用性測試需要和功能測試結合起來(lái)，以場(chǎng)景作為測試粒度，以用戶(hù)的視角進(jìn)行測試。

表9　可用性測試的關(guān)注點(diǎn)和標準

4 測試設計技術(shù)

 

表9　“用戶(hù)發(fā)送電子郵件”的測試點(diǎn)

4.1 測試點(diǎn)不等于測試用例

如果我們拿測試點(diǎn)來(lái)進(jìn)行測試，會(huì )發(fā)現很多讓我們不爽、困惑的問(wèn)題：

問(wèn)題1：這些測試點(diǎn)在內容上有重復，存在冗余。

例如，測試點(diǎn)1、測試點(diǎn)4都會(huì )測試到“正確發(fā)送郵件”。

問(wèn)題2：一些測試點(diǎn)的測試輸入不明確，不知道測試時(shí)要測試哪些。

例如，測試測試點(diǎn)1時(shí)，我們并不知道我們要測試哪些“正常的輸入數據”。存在類(lèi)似問(wèn)題的還有測試點(diǎn)5。

問(wèn)題3：總是在搭相似的環(huán)境，做類(lèi)似的操作。

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

問(wèn)題4：測試點(diǎn)描述得太粗，不知道是不是測對了。

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

4.2 四步測試設計法

把測試點(diǎn)加工為測試用例，就叫測試設計，在這個(gè)過(guò)程中使用的方法就叫測試設計方法。路徑分析法、判定表、正交分析法、等價(jià)類(lèi)、邊界值等都是常見(jiàn)的測試設計方法。

在測試分析中，我們對被測對象按照測試方法進(jìn)行思考，就能得到測試點(diǎn)，所以測試分析是一個(gè)“發(fā)現性”的過(guò)程，如圖14所示，而測試設計不同。

圖14 測試分析是一個(gè)“發(fā)現性”的過(guò)程

大家可以做這樣一個(gè)試驗，讓兩個(gè)測試者根據“車(chē)輪圖”來(lái)分析同一個(gè)測試對象，他們得到的測試點(diǎn)差異并不會(huì )太大，但是最后生成的測試用例卻會(huì )千差萬(wàn)別。這是因為，從測試點(diǎn)到測試設計，我們會(huì )加工測試點(diǎn)，對它們進(jìn)行組合、拆分，選擇測試數據，等等，這是個(gè)“創(chuàng )造性”的過(guò)程。

圖15 四步測試設計法的四個(gè)關(guān)鍵步驟

第一步：建模

其實(shí)，在這個(gè)步驟中，我們并不是要大家對每個(gè)測試點(diǎn)都原創(chuàng )出一些測試模型，而是根據測試點(diǎn)的特征，為測試點(diǎn)選擇一個(gè)適合后續測試設計的模型。也許我們稱(chēng)這個(gè)步驟為“選模”更為貼切。

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

類(lèi)型1：“流程”；

類(lèi)型2：“參數”；

類(lèi)型3：“數據”；

類(lèi)型4：“組合”。

對每一類(lèi)測試點(diǎn)，我們都給出了一些最適合的“建模”方法：

對“流程”類(lèi)，可以通過(guò)繪制“流程圖”來(lái)建立測試模型。

對“參數”類(lèi)，可以通過(guò)“輸入輸出表”來(lái)建立測試模型。

對“數據”類(lèi)，可以通過(guò)“等價(jià)類(lèi)分析表”來(lái)建立測試模型。

對“組合”類(lèi)，可以通過(guò)“因子表”來(lái)建立測試模型。

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

在這個(gè)步驟中，我們會(huì )對已經(jīng)建立好的測試模型，來(lái)設計一些基礎測試用例，覆蓋這個(gè)測試模型。

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

第三步：補充測試數據。

在這個(gè)步驟中，我們?yōu)榛A測試用例來(lái)確定測試輸入，補充測試數據，這時(shí)基礎測試用例就升級成真正的測試用例了。

第四步：擴展。

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

對測試點(diǎn)進(jìn)行分類(lèi)

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

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