黑盒測試與測試用例設計測試用例綜述3.2

等價類設計方法3.3

邊界值設計方法3.4

因果圖設計法目錄CONTENTS3.5正交試驗設計方法3.13.1測試用例綜述測試用例現在沒有標準的定義，比較常見的說法是：為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或核實是否滿足某個特定需求。測試用例將軟件測試的行為活動做了一個科學化的組織歸納，以便能夠把軟件測試的行為轉化為可管理的模式。同時，測試用例也是將測試具體量化的方法之一；對于不同類別的軟件，測試用例也是不同的。對于一個測試過程來說，測試用例起到了很重要的作用，它構成了設計和制定測試過程的基礎。而從某種角度來說，測試的“深度”與測試用例的數量成比例，判斷測試是否完全的一個主要評測方法是基于需求的覆蓋。測試用例設計的最基本要求是覆蓋住所要測試的功能。然而這個要求并不像看上去那么簡單。測試中要能夠是測試用例達到切實覆蓋全面的要求，需要對被測試產品功能全面了解、明確測試范圍（特別是要明確哪些是不需要測試的）、具備基本的測試技術（如：等價類劃分等）等。但是由于成本因素的介入，決定了工程中設計好的測試用例原則不只有“覆蓋住所要測試的功能”這一條，下面幾條常見的測試用例設計原則。3.1.1測試用例設計原則1）測試用例最小化原則2）測試用例替代產品文檔功能原則4）測試結果分析和調試最簡單化原則3）單次投入成本和多次投入成本原則3.1.1測試用例設計原則0102使用一個覆蓋三個子功能點的測試用例Test_F1_F2_F3。使用三個單獨的測試用例，分別覆蓋三個子功能，Test_F1，Test_F2，Test_F3。1）測試用例最小化原則這條原則是最重要的，同時也是最難達到、最易忽略的。它對其他幾條原則都有著或多或少的影響。在測試過程中有一個功能FUNC需要被測試，它含有三個子功能：F1，F2與F3，以兩種方法來設計測試用例：(b)測試結果對產品缺陷的指向性更強C）測試用例間的耦合度最低，因此彼此間的干擾也最低。(a)測試用例的覆蓋邊界更清晰1）測試用例最小化原則對于規模較小的工程來說，方法1更為適宜；但對于規模較大或者質量要求較高的項目，方法2顯得更為合適，因為它具有以下的優點：對于測試用例來說，它忠實反映了產品功能，否則的話測試用例就會執行失敗。以往大家只是就把測試用例當作測試用例而已，其實對測試用例的理解應該再上升到另一個高度，它應該是能夠扮演產品描述文檔的功能。這就要求編寫的測試用例足夠詳細、測試用例的組織要有調理、分主次，單靠Word、Excel或者

OneNote這樣通用的工具是遠遠無法完成的，需要更多專用的測試用例管理工具來輔助。此外，對于自動化測試用例而言，無論是API還是UI級別的，代碼在編寫上都應該有別于產品代碼編寫風格：可讀性和描述性應該是重點考慮的內容。在測試代碼中，當然可以引入面向對象、設計模式等優秀的設計思想，但是一定要適度使用，往往面向過程的編碼方式更利于組織、閱讀和描述。2）測試用例替代產品文檔功能原則3）單次投入成本和多次投入成本原則例如，第一條原則：單個用例覆蓋最小化原則，就是一個很好的例子，測試FUNC功能的3個功能點F1，F2和F3，從表面上看用Test_F1_F2_F3這一個用例在設計和自動化實現時最簡單的，但它在反復執行階段會帶來很多的問題。這樣的用例的失敗分析相對復雜，對于測試人員需要確認到底是哪一個功能點造成了測試失敗；首先步驟多的手工測試用例增加了手工執行的不確定性，步驟多的自動化用例增加了其自動執行的失敗可能性，特別是那些基于UI自動化技術的用例；.再者自動化用例的調試更為復

雜，如果是F3功能點的問題，程序仍需要不斷地走過F1和F2，然后才能到達F3，這增加了調試時間和復雜度；其次將不相關功能點耦合到一起，降低了盡早發現產品回歸缺陷的可能性，這是測試工作的大忌。最后3）單次投入成本和多次投入成本原則成本永遠是任何項目進行決策時所要考慮的首要因素，軟件項目中的開發需要考慮成本，測試工作同樣如此0

。3）單次投入成本和多次投入成本原則綜上所述，Test_F1_F2_F3這樣的設計，減少地僅是一次性設計和自動化的投入，增加地卻是需要多次投入的測試執行的負擔和風險，所以需要決策時（事實上這種決策是經常發生的，尤其是在設計測試用例時）選擇Test_F1_F2_F3還是Test_F1、Test_F2和Test_F3，務必要考慮投入的代價。4）測試結果分析和調試最簡單化原則這條原則是實際上是第三條原則的擴展和延續。在編寫自動化測試代碼時，要重點考慮如何使得測試結果分析和測試調更簡單，包括：用例日志、調試輔助信息輸出等。往往在測試項目中，測試用例的編寫人和最終的執行者是不同的團隊的成員，甚至有些測試的執行工作被采用外包的方式交給第三的團隊去進行。因為測試用例的執行屬于多次投入，測試人員要經常地去分析測試結果、調試測試用例，在這部分活動上的投入是相當可觀的。而這時，測試框架提功能的一些輔助API等就可以幫助很好實現這個原則。例如，Coded

UI

Test就提供了類似的API，來輔助基于Coded

UI框架實現的自動化測試用例，使它有更好的調試體驗。測試理論為日常的測試工作指明了前進的方向，但在實際工程中還需要我們不斷地“活化”這些理論，使理論和實踐更好地契合在一起。測試用例更新完善測試用例評審測試用例設計業務流程分析測試需求分析.3.1.2測試用例設計步驟一個完整的軟件測試流程包括許多內容，該部分從測試用例的編寫開始，介紹測試用例編寫的一般步驟，以使編寫的測試用例最大程度上滿足需求，又不產生重復而冗余的負擔。首先我們從理論上來了解測試用例編寫的一般步驟：0102030405end01測試需求分析這一步需要測試人員從軟件需求文檔中，找出測試軟件、測試模塊的需求，并進行分析后整合出測試需求，清楚被測對象具有哪些功能。測試需求的特點是：包含軟件需求，具有可測試性。在軟件需求的基礎上，測試需求應該進行進一步的歸納和分類，以便設計出合理的測試用例。測試用例中的測試集與測試需求的關系是多對一的關系，即一個或多個的測試用例集對應一個測試需求。主流程是什么條件備選流程是什么數據流向是什么關鍵的判斷條件是什么.02業務流程分析軟件測試不僅要從功能的角度進行測試，也要從軟件的內部結構入手進行邏輯測試。為了完整地進行測試活動，需要對軟件產品的業務流程有較高的熟悉度。因此在設計一些復雜的測試用例之前，可以先整理出軟件的業務流程，它可以幫助理解軟件的邏輯處理和數據流向，從而指導測試用例的設計。從業務流程上，應得到這些信息。（1）確定測試套件（2）對每一個測試套件，確定一個或多個基本流程和可選流程測試套件是功能上的劃分，是相似測試場景的組合，而非技術劃（3）針對每一個測試場景，確定一到多個測試用例（4）增加測試數據，完成測試用例分。如果技術設計中各模塊耦合度較高，可能功能上不相干的模塊由于代碼重用的原因會在修復缺陷時互相引致錯誤；而實際上回歸測試的出現即是為了避免這種情況。但是做功能測試劃分模塊時，還是要從用戶的角度出發，按照用戶場景劃分測試的“模塊”。（1）（2）（3）測試數據是測試用例中很重要的內容，一個用例可能對應多套測試數據，測試工程師根據某種測試技術，將盡可能的設計較少的測試數據完成“足夠”的測試。（4）03測試用例設計設計測試用例的關鍵點：可以借助Scenario

Matrix來清晰地對可能出現的場景進行排

列組合。值得注意的是，一方面Use

Case或PRD文檔中的描述

很有可能并沒有完整的寫盡所有的場景，測試人員盡可能地挖

掘測試場景，既有可能是出于測試本身的需要，也可能是基于

開發團隊的工作；另一方面，在復雜系統中，測試場景不可能

覆蓋所有可能的場景，這便需要測試人員采用一定的測試策略，對系統進行“足夠（adequate）”的測試，而不是完全的測試。這仍然可以借助Matrix來清晰地規劃測試用例，每一個測試用例都有其對應的預置條件、輸入和期望結果。測試用例分為PositiveTestCase和NegativeTestCase兩種，分別用來測試產品是否完成應當完成的工作和不執行不應當完成的操作。04測試用例評審測試用例設計完成后，為了確保測試過程和方法的正確性，以及是否有遺漏的測試點，需要進行測試用例的評審。評審活動一般由測試主管來主導，參與的人員有測試用例設計者、測試主管、項目經理、開發工程師、其它相關開發測試工程師。測試用例評審完畢，測試工程師根據評審結果，對測試用例進行修改，并記錄修改日志。05測試用例更新完善測試用例完成后并不是這一階段的終止，而