軟件測試用例的設計-提高測試覆蓋率 軟件測試
說(shuō)到測試用例的設計，我想每個(gè)有過(guò)測試經(jīng)歷的測試工程師都會(huì )認為很簡(jiǎn)單，不就是：按需求或概要設計，得到軟件功能劃分圖，然后據此按每個(gè)功能，采用等價(jià)類(lèi)劃分、臨界值、因果圖等方法來(lái)設計用例就行了。
但事實(shí)上撇開(kāi)測試數據的設計不談，僅就測試項來(lái)說(shuō)，我們發(fā)現，對同一個(gè)項目，有經(jīng)驗的測試人員，在寫(xiě)用例或測試時(shí)總會(huì )有更多的測試考慮點(diǎn)，從而發(fā)現更多的問(wèn)題;而有些測試人員測試用例的撰寫(xiě)卻只有那么三板斧，表面看好象已經(jīng)把頁(yè)面所有信息的測試都考慮到了，實(shí)際上卻還是遺漏了大量測試覆蓋點(diǎn)，導致其測試出來(lái)的程序總是比較脆弱。
究其原因，我覺(jué)得還是測試用例的撰寫(xiě)水平不到位，更確切地說(shuō)是測試用例的覆蓋度太低。說(shuō)實(shí)話(huà)我認為系統測試用例真正做到100%覆蓋是很難的。難道說(shuō)按設計中的功能劃分，每個(gè)功能都寫(xiě)到了這個(gè)用例就覆蓋完整了?錯，這還遠遠不夠。因為我們知道還有大量的內部處理、轉換、業(yè)務(wù)邏輯、相互影響的關(guān)系等都是需求或設計中所不會(huì )點(diǎn)明的。而這些一方面需要靠測試人員對項目本身的了解，另一方面要靠測試人員的經(jīng)驗，來(lái)一一找到這些隱藏點(diǎn)并予以測試，才能真正地保證我們的測試覆蓋度。
所以本文拋開(kāi)具體的測試數據設計方法，主要從測試覆蓋度的角度來(lái)介紹用例設計時(shí)，如何才能考慮地更周全，如何才能將隱藏的測試項一一找出，從而使我們的測試更全面更完整。
想法雖然美好，可是畢竟每個(gè)測試的項目都是各不相同，針對不同項目我們的經(jīng)驗也會(huì )告訴給我們不同的想法，這些想法通常很感性，很難用嚴密的邏輯理論來(lái)把它升華。因此本文的內容仍是很簡(jiǎn)陋且不成熟，只是希望能以本文為磚，引起大家的思考，一起來(lái)補充完善，以使我們的測試用例設計水平不斷提高。
測試用例的切面設計
所謂測試切面設計，其實(shí)就是測試用例大項的劃分。測試用例劃分的經(jīng)典方法是瀑布模型，也就是從上到下，逐漸細分，大模塊包括小模塊，小模塊包括更小的模塊。但僅僅如此是不夠的，我們還要從更多的角度切入系統，從不同的角度把系統切分成一塊一塊的，來(lái)進(jìn)行測試，從而確保測試大項的完整性。
1、功能點(diǎn)切面
這是最常見(jiàn)的切面，通常我們認為頁(yè)面上的一個(gè)按鈕就是一個(gè)功能點(diǎn)。然后我們可以根據功能的復雜程度，按每個(gè)功能;或一個(gè)功能點(diǎn)分多頁(yè);或多個(gè)功能點(diǎn)合成一頁(yè)來(lái)進(jìn)行用例的撰寫(xiě)。
2、特定切面
除此以外，還有一種特定切面的劃分方法，也是用例撰寫(xiě)時(shí)經(jīng)常會(huì )用到的。所謂的特定切面，就是忽略掉表面上的功能點(diǎn)，而關(guān)注測試對象的某一個(gè)面。比如我們的內部管理系統提供了銷(xiāo)售錄入導入、注冊錄入導入等功能，從菜單劃分上對應了七八個(gè)功能點(diǎn)。但這些功能處理后臺有個(gè)共同的處理項就是授權記錄的生成，這時(shí)我們就可以把“授權記錄生成”單獨拿出來(lái)做一個(gè)測試項，而在其它測試項中涉及這一部分的用例就不必再一一撰寫(xiě)。此外象一些界面共通的操作用例單獨寫(xiě)成一頁(yè)，也是一種特定切面。所以如果說(shuō)將用例按功能點(diǎn)劃分是一種縱向劃分法，那么特定切面就是從橫向的角度分析所得到的切面。在普通功能點(diǎn)劃分上再根據實(shí)際情況設計特定切面，可以使我們的用例閱讀性、理解性、操作性更強。
3、隱含切面
這類(lèi)用例是最容易被忽略的。它往往不是明顯的某個(gè)功能項，可能是功能項后臺的隱含處理，也可能是多個(gè)功能項之間的關(guān)聯(lián)處理，甚至可能是在某種特定情形下的處理。這都需要測試人員通過(guò)對軟件的學(xué)習了解，來(lái)進(jìn)行挖掘。
(1)、后臺功能
常見(jiàn)的如一些定時(shí)自動(dòng)啟動(dòng)的服務(wù);以及某種特定情況下自動(dòng)執行的操作等。它們在界面上往往是不體現的，但許多在需求設計中還是會(huì )提到，也有一些比較細小的功能可能會(huì )被忽略，就需要測試人員根據對項目的了解程度來(lái)進(jìn)行挖掘。所以說(shuō)一個(gè)熟悉項目的和一個(gè)不熟悉的測試人員，寫(xiě)出來(lái)的用例就完全是兩個(gè)層次的。
(2)、完整業(yè)務(wù)流程的測試
我們都知道測試用例的設計是從點(diǎn)、線(xiàn)、面三個(gè)層次去考慮的。完整的一個(gè)功能項是線(xiàn)，其中的某個(gè)按鈕是點(diǎn)，多個(gè)相關(guān)功能結合成完整業(yè)務(wù)流就是面。從實(shí)際來(lái)看這類(lèi)用例往往被我們忽略。
事實(shí)上目前公司的軟件本來(lái)都是業(yè)務(wù)型應用軟件，將各種功能從業(yè)務(wù)流中切割出來(lái)單獨寫(xiě)用例，肯定也會(huì )有涉及到整體流程的情況。若不加以區分，將細節與全局攪在一起，不僅思路混亂，也容易考慮不周。因此在系統測試階段，建議用例設計要有分有合，針對具體功能的就只圍著(zhù)這個(gè)功能轉：而在業(yè)務(wù)流程測試項中，再完全從整體的業(yè)務(wù)流角度出發(fā)去考慮用例，這樣不僅不容易產(chǎn)生疏漏，用例閱讀與執行也更清楚。
(3)、某種特定情況下的系統運行
這類(lèi)用例的設計往往與系統實(shí)際業(yè)務(wù)情況密不可分。比如財務(wù)軟件，通常需要在月尾一天、月頭一天、年尾一天、年頭一天，對所有相關(guān)功能中的日期處理進(jìn)行測試;又比如WIN 2000環(huán)境開(kāi)發(fā)測試的系統，要測試在98、XP、2003等操作系統下是否能運行自如;再有如存在大量動(dòng)態(tài)圖片視頻等的網(wǎng)頁(yè)，在普通網(wǎng)速下的展現速度等等�？傊褪且M可能從實(shí)際應用的角度出發(fā)考慮，來(lái)進(jìn)行測試補充。
(4)、其它相關(guān)系統
即指在當前項目中直接使用的其它成果，包括公司自有的系統模塊、組件、函數;以及購買(mǎi)或免費得到的一些功能組件。對這些內容需要預先與開(kāi)發(fā)組長(cháng)等討論清楚，是否需要測試。若時(shí)間緊張或其它原因決定不測的，應在測試計劃中說(shuō)明。若需要測試的，則具體可根據實(shí)際情況來(lái)設計，可以是通過(guò)系統某個(gè)功能的測試來(lái)涉及，此時(shí)就不需要單獨劃分測試項;若相對比較獨立的，也可以通過(guò)單獨的測試項來(lái)對其專(zhuān)門(mén)進(jìn)行測試。
(5)、除功能測試外的其它測試類(lèi)型
包括可靠性、安全性、恢復性、配置安裝測試等等，這些測試類(lèi)型都是一個(gè)單獨的測試項。
所謂好的開(kāi)始是成功的一半，保證測試項劃分的完整、合理、正確，會(huì )直接影響到本次測試的成效。通常建議該階段工作要花1-2天的時(shí)間來(lái)考慮，并要在測試過(guò)程中隨著(zhù)對軟件的深入了解，不斷進(jìn)行調整補充�？汕f(wàn)不要認為把分析設計中的功能模型圖搬搬過(guò)來(lái)就可以了。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
