軟體測試的重要性及其對軟體質量的好壞的預意是非常重要的。下面這段話引自Deutsch［DEU79］：性及其對軟體質量的好壞的預意是非常重要的。下面這段話引自Deutsch[DEU79]： 　　軟體系統的開發包括一系列生產活動，其中由人帶來的錯誤因素非常多。錯誤可能出現在程式的最初…，其時目標可能是錯誤的或描述不完整，也可能在後期的設計和開發階段…，因為人們不能完好無缺地工作和交流，軟體開發過程中必須伴有質量保證活動。 　　軟體測試是軟體質量保證的關鍵元素，代表了規約、設計和編碼的最終檢查。 　　軟體作為系統元素的可見性不斷增加軟體故障帶來的代價太高使得人們注重於規劃良好的徹底測試，軟體開發組織將30％—40%的專案精力花在測試上並不為怪。另一方面，人命悠關的軟體(如飛行控制和核反應堆)測試所花的時間往往是其他軟體工程活動時間之和的三到五倍。 　　本章討論軟體測試基礎和設計軟體測試用例的技術。軟體測試基礎定義了軟體測試的目標，測試用例的設計討論符合整體目標的測試用例建立技術。 　　1.1軟體測試基礎 測試為軟體工程師帶來了很有趣的意外。在軟體過程的早期，軟體工程師試圖由抽象概念到具體實現來建立軟體，現在來了測試，工程師建立測試用例試圖“摧毀”已經建立的軟體。事實上，在軟體工程過程中，測試可以看成(至少心理上)摧毀性的而不是建設性的。 　　軟體開發者就其本性而言是建設者，測試要求開發者放棄剛開發的軟體是正確的觀念，並克服發現錯誤時的心理矛盾。Beizers［BEI90］如下描述了這種情況： 　　如果我們真正擅長程式設計，就應當不會有錯誤，但這只是一個神話。如果我們真的很認真，如果每個人都使用結構化方法，自頂向下設計而且使用決策表，如果程式是用SQUISH寫的，如果我們有合適的銀彈，就不會有錯誤了，這樣，神話就不存在。因為我們並不擅長所做的事，所以有錯誤，如果不擅長，就應當感到內疚。因此，測試和測試用例設計是對失誤的承認，它注入了一針內疚劑。測試的枯燥是對我們錯誤的處罰，為什麼處罰？為了人？為什麼內疚？為了沒能達到人類的完美境界？為了沒有區別另一個程式設計師所想的和所說的？為了沒有心靈感應？為了沒有解決人類四千年來尚未解決的相互通訊問題？ 　　測試真的應當注入內疚感？測試真的是摧毀性的？這些問題的回答是“不！”，然而，測試的目標可能和我們所期待的不同。 　　1.1.1測試目標 　　Glen Myers［MYE79］在他的軟體測試著作中陳述了一系列關於測試目標的規則：歡饈? 　　1.測試是一個為了尋找錯誤而執行程式的過程。 　　2.一個好的測試用例是指很可能找到迄今為止尚未發現的錯誤的用例。 　　3.一個成功的測試是指揭示了迄今為止尚未發現的錯誤的測試。 　　上述目標蘊含了一個觀點上的戲劇性變化，他們轉向通常的觀點，即一個成功的測試是指沒有找到錯誤的測試。我們的目標是設計這樣的測試，它們能夠系統地揭示不同型別的錯誤，並且耗費最少時間與最小工作量。 　　如果成功構造了測試(根據上述目標)，則能夠在軟體中揭示錯誤。測試的第二個好處在於它證實了軟體依據規約所具有的功能及其效能需求，此外，構造測試時的資料收集提供了軟體可靠性以及軟體整體質量的一些資訊。但是，有一件事測試無法完成： 　　測試無法說明錯誤不存在，它只能表示軟體錯誤已經出現。 　　在構造測試時必須牢記這一點。 　　1.1.2測試原則 　　在設計有效的測試用例之前，軟體工程師必須理解軟體測試的基本原則。Davie［DAV95］提出了一組①測試原則： 　　·所有的測試都應追溯到使用者需求。正如我們所知，軟體測試的目標在於揭示錯誤。而最嚴重的錯誤(從使用者角度來看)是那些導致程式無法滿足需求的錯誤。 　　·應該在測試工作真正開始的前較長時間內就進行測試計劃。測試計劃可以在需求模型一完成就開始，詳細的測試用例定義可以在設計模型被確定後立即開始，因此，所有測試可以在任何程式碼被產生前進行計劃和設計。 　　· Pareto原則應用於軟體測試。簡單而言， Pareto原則暗示著測試發現的錯誤中的80％很可能起源於程式模組中的20％。當然，問題在於如何孤立這些有疑點的模組並進行徹底的測試。 　　·測試應從“小規模”開始，逐步轉向“大規模”。最初的測試通常把焦點放在單個程式模組上，進一步測試的焦點則轉向在整合的模組簇中尋找錯誤，最後在整個系統中尋找錯誤。 　　·窮舉測試是不可能的。甚至一個大小適度的程式，其路徑排列的數量也非常大，因此，在測試中不可能執行路徑的每一種組合，然而，充分覆蓋程式邏輯，並確保程式設計中使用的所有條件是有可能的。 　　·為了達到最佳效果，應該由獨立的第三方來構造測試。“最佳效果”指最可能發現錯誤的測試(測試的主要目標)。由於本章中已經介紹過、並將進一步討論的那些原因，建立系統的軟體工程師並不是構造軟體測試的最佳人選。 　　1.1.3可測試性 　　在理想的情況下，軟體工程師在設計計算機程式、系統或產品時應該考慮可測試性，這就使得負責測試的人能夠更容易地設計有效的測試用例，但是，什麼是“可測試性”呢？ JamesBach②這樣描述可測試性： 　　軟體可測試性就是一個計算機程式能夠被測試的容易程度。因為測試是如此的困難，因此，需要知道做些什麼才能理順測試過程。有時，程式設計師願意去做對測試過程有幫助的事，而一個包括可能的設計點、特性等等的檢查表對他們是很有用的。 　　肯定存在可用於在很多方面測度可測試性的度量，有時，可測試性被用來表示一個特定測試集覆蓋產品的充分程度。在軍方還用它來表示工具被檢驗和修復的容易程度。這兩種意義都略不同於“軟體可測試性”。下面的檢查表提供了一組可測試軟體的特徵： 　　可操作性。“執行得越好，被測試的效率越高。” 　　·產品在功能階段的演化(允許同時的開發和測試)。 　　可觀察性。“你所看見的就是你所測試的。” 　　·每個輸入有唯一的輸出。 　　·系統狀態和變數可見，或在執行中可查詢。 　　·過去的系統狀態和變數可見，或在執行中可查詢(例如：事務日誌)。·所有影響輸出的因素都可見。 　　·容易識別錯誤輸出。 　　·通過自測機制自動偵測內部錯誤。 　　·自動報告內部錯誤。 　　·可獲取原始碼。 　　可控制性。“對軟體的控制越好，測試越能夠被自動執行與優化。”·所有可能的輸出都產生於某種輸入組合。 　　·通過某種輸入組合，所有的程式碼都可能被執行。 　　·測試工程師可直接控制軟體和硬體的狀態及變數。 　　·輸入和輸出格式保持一致且有結構。 　　·能夠便利地對測試進行說明、自動化和再生。 　　可分解性。“通過控制測試範圍，能夠更快地分解問題，執行更靈巧的再測試。”·軟體系統由獨立模組構成。 　　·能夠獨立測試各軟體模組。 　　簡單性。“需要測試的內容越少，測試的速度越快。” 　　·功能簡單性(例如：特性集是滿足需求所需的最小集合)。 　　·結構簡單性(例如：將體系結構模組化以限制錯誤的繁殖)。 　　·程式碼簡單性(例如：採用程式碼標準為檢查和維護提供方便)。 　　穩定性。“改變越少，對測試的破壞越小。” 　　·軟體的變化是不經常的。 　　·軟體的變化是可控制的。 　　·軟體的變化不影響已有的測試。 　　·軟體失效後能得到良好恢復。 　　易理解性。“得到的資訊越多，進行的測試越靈巧。” 　　·設計能夠被很好地理解。 　　·內部、外部和共享構件之間的依賴效能夠被很好地理解。 　　·設計的改變被通知。 　　·可隨時獲取技術文件。 　　·技術文件組織合理。 　　·技術文件明確詳細。 　　·技術文件精確性穩定。 　　軟體工程師可運用James Bach提出的這些屬性來開發可測試的軟體配置(即程式、資料和文件)。 　　但是關於測試本身呢？ Kaner， Falk和Nguyen［KAN93］給出了“好”測試的一些屬性：文1.一個好的測試發現錯誤的可能性很高。為了達到這個目標，測試者必須理解軟體，並嘗試設想軟體如何才能失敗，理想，被探測的錯誤類別，例如，在GUI(圖形使用者介面)中有一種潛在的錯誤，即錯誤識別滑鼠位置。應該設計一個測試集來驗證滑鼠位置識別的錯誤。 　　2.一個好的測試並不冗餘。測試的時間和資源是有限的，沒有必要構造一個與其他測試用途完全相同的測試，每一個測試都應該有不同的用途(哪怕是細微的差異)。例如，軟體SafeHome①中有一個模組被用來識別使用者密碼以決定是否啟動系統，為了測試密碼輸入的錯誤，測試者設計了一系列的輸入密碼測試。在不同的測試中輸入有效與無效密碼(四個數字)，然而，每一個有效/無效密碼將檢測一種不同錯誤模式，例如，一個將8080作為有效密碼的系統將不會接受非法密碼1234，如果接收1234，將產生錯誤，另一個測試輸入1235，與1234的測試意圖相同，因此是冗餘的，然而，非法輸入8081或8180就有些細微的差異，即對與有效密碼相近但並不相同的密碼該進行測試。 　　3.一個好的測試應該是“最佳品種” ［KAN93］。在一組目的相似的測試中，時間和資源的限制可能隻影響其某個子集的執行，此時，應該使用最可能找到所有錯誤的測試。 　　4.一個好的測試既不會太簡單，也不會太複雜。雖然有時會將一組測試組合到一個測試用例中，其副作用可能遮蔽錯誤，通常，每一個測試應該獨立執行。 　　1.2 測試用例設計　　軟體和其他工程產品的測試設計與產品本身的設計一樣具有挑戰性，然而由於已經討論過的一些原因，軟體工程師經常將測試作為一種事後的措施，開發一些“感覺上正確”但是缺乏完整保證的測試用例。再回頭看看測試目標，我們必須設計出最可能發現最多數量的錯誤、並耗費最少時間和最小代價的測試。 　　在過去的20年，出現了大量的測試用例設計方法，為開發人員進行測試提供了系統的方法。更重要的是，方法提供了一種有助於確保完全測試的機制，並提供了揭示軟體錯誤的最高可能性。 　　能夠採用以下兩種方法之一對任何工程化產品(以及大多數其他東西)進行測試：(1)若瞭解產品的特定功能，則構造測試，以證實各功能完全可執行，同時在各功能中尋找錯誤；(2)若瞭解產品的內部構造，則構造測試，以確保“所有齒輪吻合”，即內部操作依據規約執行，而且所有的內部構件被充分利用。第一種測試方法被稱為黑盒測試，第二種則被稱為白盒測試。 　　如果考慮計算機軟體，黑盒測試指在軟體介面上進行的測試，雖然設計黑盒測試是為了發現錯誤，它們卻被用來證實軟體功能的可操作性；證實能很好地接收輸入，並正確地產生輸出；以及證實對外部資訊完整性(例如：資料檔案)的保持。黑盒測試檢驗系統的一些基本特徵，很少涉及軟體的內部邏輯結構。 　　軟體的白盒測試依賴對程式細節的嚴密檢驗，提供運用特定條件和/與迴圈集的測試用例，對軟體的邏輯路徑進行測試，在不同的點檢驗“程式的狀態”以判定預期狀態或待驗證狀態與真實狀態是否相符。 　　一眼看去，可能認為全面的白盒測試將產生“百分之百正確的程式”，需要我們做的只是定義所有的邏輯路徑、開發相應的測試用例，並評估結果，簡而言之，詳盡地生成用例以測試程式邏輯。不幸的是，窮舉測試帶來了必然的計算問題，即使是很小的程式，可能的邏輯路徑數量也非常大，例如，考慮 100行C語言程式，在一些基本的資料宣告之後，程式包含兩個巢狀迴圈，根據輸入的條件分別執行1到20次，在內部迴圈中，需要四個if-then-else結構，該程式中大約有1014條可能路徑！ 　　為了正確表達這個數值，我們假設開發了一個有魔力的測試處理器(“有魔力”是因為不存在這樣的處理器)進行窮舉測試。該處理器能在一毫秒內開發一個測試用例、進行執行並評估結果，如果每天執行24小時，每年執行365天，則需要3170年的時間來測試這個程式。不可否認，這將導致大多數開發進度表的混亂，對大型軟體系統不可能進行窮舉測試。 　　然而，白盒測試不應該被拋棄，可選擇有限數量的重要邏輯路徑進行測試，檢測重要資料結構的有效性，可以綜合黑盒測試和白盒測試的屬性提供一種方法，以驗證軟體介面，並有選擇地保證軟體內部工作的正確性。 　　1.3白盒測試　　白盒測試，有時稱為玻璃盒測試，是一種測試用例設計方法，它使用程式設計的控制結構匯出測試用例。使用白盒測試方法，軟體工程師能夠產生測試用例(1)保證一個模組中的所有獨立路徑至少被使用一次；(2)對所有邏輯值均需測試true和 false；(3)在上下邊界及可操作範圍內執行所有迴圈；(4)檢查內部資料結構以確保其有效性。 　　此時可能會提出一個合理的問題：“我們應該更注重於保證程式需求的實現，為什麼要花費時間和精力來擔心(和測試)邏輯細節？”換一種說法，我們為什麼不將所有精力用於黑盒測試呢？答案在於軟體自身的缺陷 　　·邏輯錯誤和不正確假設與一條程式路徑被執行的可能性成反比。當我們設計和實現主流之外的功能、條件或控制時，錯誤往往開始出現在我們的工作中。日常處理往往被很好地瞭解(和很好地細查)，而“特殊情況”的處理則難於發現。 　　·我們經常相信某邏輯路徑不可能被執行，而事實上，它可能在正常的基礎上被執行。程式的邏輯流有時是違反直覺的，這意味著我們關於控制流和資料流的一些無意識的假設可能導致設計錯誤，只有路徑測試才能發現這些錯誤。 　　·印刷上的錯誤是隨機的。當一個程式被翻譯為程式設計語言原始碼時，有可能產生某些列印錯誤，很多將被語法檢查機制發現，但是，其他的會在測試開始時才會被發現。列印錯誤出現在主流上和不明顯的邏輯路徑上的可能性是一樣的。 　　上述任何一條原因都是該進行白盒測試的論據，黑盒測試，不管它多麼全面，都可能忽略前面提到的某些型別的錯誤。正如Beizer所說［BEI90］：“錯誤潛伏在角落裡，聚集在邊界上”。白盒測試更可能發現它們。 　　1.4基本路徑測試 　　基本路徑測試是Tom McCabe［MCC76］首先提出的一種白盒測試技術，基本路徑測試方法上”。允許測試用例設計者匯出一個過程設計的邏輯複雜性測度，並使用該測度作為指南來定義執行路徑的基本集。從該基本集匯出的測試用例保證對程式中的每一條語句至少執行一次。 　　1.4.1流圖符號 　　在介紹基本路徑方法之前，必須先介紹一種簡單的控制流表示方法，即流圖或程式圖①。流圖使用圖1-1中的符號描述邏輯控制流，每一種結構化構成元素有一個相應的流圖符號。 　　為了說明流圖的用法，我們採用圖1-2中的過程設計表示法，此處，流程圖用來描述程式控制結構。圖 1-2b將流程圖對映到一個相應的流圖(假設流程圖的菱形決定框中不包含複合條件)。在圖1-2b中，每一個圓，稱為流圖的節點，代表一個或多個語句。一個處理方框序列和一個菱形決測框可被對映為一個節點，流圖中的箭頭，稱為邊或連線，代表控制流，類似於流程圖中的箭頭。一條邊必須終止於一個節點，即使該節點並不代表任何語句(例如：參見if-else-then結構的符號)。由邊和節點限定的範圍稱為區域。計算區域時應包括圖外部的範圍①。 　　任何過程設計表示法都可被翻譯成流圖，圖 1-3顯示了一個程式設計語言(PDL，ProgramDesign Language)片段及其對應的流圖，注意，對PDL語句進行了編號，並將相應的編號用於流圖中。 　　程式設計遇到複合條件時，生成的流圖變得更為複雜。當條件語句中用到一個或多個布林運算子(邏輯OR，AND，NAND，NOR)時，就出現了複合條件。圖1-4中，將一個PDL片段翻譯為流圖，注意，為語句IF a OR b中的每一個a和b建立了一個獨立的節點，包含條件的節點被稱為判定節點，從每一個判定節點發出兩條或多條邊。 　　1.4.2環形複雜性 　　環形複雜性是一種為程式邏輯複雜性提供定量測度的軟體度量，將該度量用於基本路徑方法，計算所得的值定義了程式基本集的獨立路徑數量，併為我們提供了確保所有語句至少執行一次的測試數量的上界。 　　獨立路徑是指程式中至少引進一個新的處理語句集合或一個新條件的任一路徑。採用流圖的術語，即獨立路徑必須至少包含一條在定義路徑之前不曾用到的邊。例如，圖1-2b中所示流圖的一個獨立路徑集合為： 　　路徑1：1-11 　　路徑2：1-2-3-4-5-10-1-11 　　路徑3：1-2-3-6-8-9-10-1-11 　　路徑4：1-2-3-6-7-9-10-1-11 　　注意，每一條新的路徑都包含了一條新邊。路徑1-2-3-4-5-10-1-2-3-6-8-9-10-1-11不是獨立路徑，意味它只是已有路徑的簡單合併，並未包含任何新邊。 　　上面定義的路徑1，2，3和4包含了圖 1-2b所示流圖的一個基本集，簡而言之，如果能將測試設計為強迫執行這些路徑(基本集)，那麼程式中的每一條語句將至少被執行一次，每一個條件執行時都將分別取true和false。應該注意到基本集並不唯一，實際上，給定的過程設計可派生出任意數量的不同基本集。 　　如何才能知道需要尋找多少條路徑呢？對環形複雜性的計算提供了這個問題的答案。環形複雜性以圖論為基礎，為我們提供了非常有用的軟體度量。可用如下三種方法之一來計算複雜性： 　　1.流圖中區域的數量對應於環形的複雜性。 　　2.給定流圖G的環形複雜性——V(G)，定義為V(G)=E-N+2，E是流圖中邊的數量，N是流圖節點數量。 　　3.給定流圖G的環形複雜性——V(G)，也可定義為V(G)=P+1，P是流圖G中判定節點的數量。 　　再回到圖1-2b。可採用上述任意一種演算法來計算環形複雜性。 　　1.流圖有4個區域。 　　2.V(G)=11條邊-9個節點+2=4。 　　3.V(G)=3個判定節點+1=4。 　　因此，圖1-2b的環形複雜性是4。 　　更重要的是，V(G)的值提供了組成基本集的獨立路徑的上界，並由此得出覆蓋所有程式語句所需的測試設計數量的上界。 　　1.4.3匯出測試用例 　　基本路徑測試方法可用於過程設計或原始碼生產。本節中，我們將基本路徑測試表示為一系列步驟，圖1-5中PDL所描述的過程“求平均值”將被用於闡明測試用例設計方法中的各個步驟。注意，“求平均值”雖然是一個非常簡單的演算法，但是仍然包含了複合條件和迴圈。 　　1.以設計或程式碼為基礎，畫出相應的流圖。 　　2.確定結果流圖的環形複雜性。可採用上一節中的任意一種演算法來計算環形複雜性——V(G)。應該注意到，計算V(G)並不一定要畫出流圖，計算PDL中的所有條件語句數量(過程求平均值中複合條件語句計數為2)，然後加1即可得到環形複雜性。在圖1-6中， 　　V(G)=6個區域 　　V(G)=18條邊-14個節點+2=6。 　　V(G)=5個判定節點+1=6。 　　3.確定線性獨立的路徑的一個基本集。V(G)的值提供了程式控制結構中線性獨立的路徑的數量，在過程求平均值中，我們指定六條路徑： 　　路徑1：1-2-10-11-13 　　路徑2：1-2-10-12-13 　　路徑3：1-2-3-10-11-13 　　路徑4：1-2-3-4-5-8-9-2-…… 　　路徑5：1-2-3-4-5-6-8-9-2-…… 　　路徑6：1-2-3-4-5-6-7-8-9-2-…… 　　路徑4、5和6後面的省略號(……)表示可加上控制結構其餘部分的任意路徑。通常在匯出測試用例時，識別判定節點是很有必要的。本例中，節點2、3、5、6和10是判定節點。 　　4.準備測試用例，強制執行基本集中每條路徑。測試人員可選擇資料以便在測試每條路徑時適當設定判定節點的條件。滿足上述基本集的測試用例如下： 　　路徑1測試用例： 　　value(k)=有效輸入，其中k＜i 　　value(i)=-999，其中2≤i≤100 　　期望結果：基於k的正確平均值和總數 　　注意：路徑1無法獨立測試，必須作為路徑4、5和6測試的一部分。 　　路徑2測試用例： 　　value(1)=-999 　　期望結果：求平均值=-999；其他按初值彙總 　　路徑3測試用例： 　　試圖處理101或更大的值 　　前100個數值應該有效 　　期望結果：與測試用例1相同 　　路徑4測試用例： 　　value(i)=有效輸入，其中i＜100 　　value(k)＜最小值，其中k＜i 　　期望結果：基於k的正確平均值和總數 　　路徑5測試用例： 　　value(i)=有效輸入，其中i＜100 　　value(k)＞最大值，其中k≥i 　　期望結果：基於k的正確平均值和總數 　　路徑6測試用例： 　　value(i)=有效輸入，其中i＜100 　　期望結果：基於k的正確平均值和總數 　　執行每個測試用例，並和期望值比較，一旦完成所有測試用例，測試者可以確定在程式中的所有語句至少被執行一次。 　　重要的是要注意，某些獨立路徑(如，例子中的路徑1)不能以獨立的方式被測試，即，穿越路徑所需的資料組合不能形成程式的正常流，在這種情況下，這些路徑必須作為另一個路徑測試的一部分來進行測試。 　　1.4.4 圖矩陣 　　匯出流圖和決定基本測試路徑的過程均需要機械化，為了開發輔助基本路徑測試的軟體工具，稱為圖矩陣(graph matrix)的資料結構很有用。 　　圖矩陣是一個正方形矩陣，其大小(即列數和行數)等於流圖的節點數。每列和每行都對應於標識的節點，矩陣項對應於節點間的連線(邊)，圖1-7顯示了一個簡單的流圖及其對應的圖矩陣［BEI90］。 　　該圖中，流圖的節點以數字標識，邊以字母標識，矩陣中的字母項對應於節點間的連線，例如，邊b連線節點3和節點4。 　　這裡，圖矩陣只是流圖的表格表示，然而，對每個矩陣項加入連線權值(link weight)，圖矩陣就可以用於在測試中評估程式的控制結構，連線權值為控制流提供了另外的資訊。最簡單情況下，連線權值是 1(存在連線)或0(不存在連線)，但是，連線權值可以賦予更有趣的屬性： 　　·執行連線(邊)的概率。 　　·穿越連線的處理時間。 　　·穿越連線時所需的記憶體。 　　·穿越連線時所需的資源。 　　舉例來說，我們用最簡單的權值(0或1)來標識連線，圖1-7所示的圖矩陣重畫為圖1-8。字母替換為1，表示存在邊(為清晰起見，沒有畫出0)，這種形式的圖矩陣稱為連線矩陣(linkmatrix)。圖1-8中，含兩個或兩個以上項的行表示判定節點，所以，右邊所示的算術計算就提供了另一種環形複雜性計算(參1.4.2節)的方法。 　　Beizer［BEI90］提供了可用於圖矩陣的其他數學演算法的處理，利用這些技術，設計測試用例的分析就可以自動化或部分自動化。 　　1.5 控制結構測試　　1.4節所述的基本路徑測試技術是控制結構測試技術之一。儘管基本路徑測試簡單高效，但是，其本身並不充分。本節討論控制結構測試的其他變種，這些測試覆蓋並提高了白盒測試的質量。 　　1.5.1 條件測試 　　條件測試是檢查程式模組中所包含邏輯條件的測試用例設計方法。一個簡單條件是一個布林變數或一個可能帶有NOT(“┓”)操作符的關係表示式。關係表示式的形式如： 　　E1＜關係操作符＞E2 　　其中E1和E2是算術表示式，而＜關係操作符＞是下列之一：“＜”，“≤”，“=”，“≠”(“┓=”)，“＞”，或“≥”。複雜條件由簡單條件、布林操作符和括弧組成。我們假定可用於複雜條件的布林運算元包括OR“|”，AND“＆”和NOT“┓”，不含關係表示式的條件稱為布林表示式。 　　所以條件的成分型別包括布林操作符、布林變數、布林括弧(括住簡單或複雜條件)、關係操作符或算術表示式。 　　如果條件不正確，則至少有一個條件成分不正確，這樣，條件的錯誤型別如下： 　　·布林操作符錯誤(遺漏布林操作符，布林操作符多餘或布林操作符不正確)。 　　·布林變數錯誤。 　　·布林括弧錯誤。 　　·關係操作符錯誤。 　　·算術表示式錯誤。 　　條件測試方法注重於測試程式中的條件。本節後面討論的條件測試策略主要有兩個優點，首先，測度條件測試的覆蓋率是簡單的，其次，程式的條件測試覆蓋率為產生另外的程式測試提供了指導。 　　條件測試的目的是測試程式條件的錯誤和程式的其他錯誤。如果程式P的測試集能夠有效地檢測P中的條件錯誤，則該測試集可能也會有效地檢測P中的其他錯誤，此外，如果測試策略對檢測條件錯誤有效，則它也可能有效地檢測程式錯誤。 　　已經提出了幾個條件測試策略。分支測試可能是最簡單的條件測試策略，對於複合條件C，C的真分支和假分支以及C中的每個簡單條件都需要至少執行一次［MYE97］。 　　域測試(Domain testing)［WHI80］要求從有理表示式中匯出三個或四個測試，有理表示式的形式如： 　　E1＜關係操作符＞E2 　　需要三個測試分別用於計算E1的值是大於、等於或小於E2的值［HOW82］。如果＜關係操作符＞錯誤，而E1和E2正確，則這三個測試能夠發現關係運算元的錯誤。為了發現E1和E2的錯誤，計算E1小於或大於E2的測試應使兩個值間的差別儘可能小。 　　有n個變數的布林表示式需要2n個可能的測(n＞0)。這種策略可以發現布林操作符、變數和括弧的錯誤，但是隻有在n很小時實用。 　　也可以派生出敏感布林表示式錯誤的測試［FOS84，TAI87］。對於有n個布林變數(n＞0)的單布林表示式(每個布林變數只出現一次)，可以很容易地產生測試數小於2n的測試集，該測試集能夠發現多個布林操作符錯誤和其他錯誤。 　　Tai［TAI89］建議在上述技術之上建立條件測試策略，稱為BRO(branch and relational試集operator)的測試保證能發現布林變數和關係操作符只出現一次而且沒有公共變數的條件中的分支和條件操作符錯誤。 　　BRO策略利用條件C的條件約束。有n個簡單條件的條件C的條件約束定義為(D1，D2，…，Dn)，其中Di(0＜i≤n)表示條件C中第i個簡單條件的輸出約束。如果C的執行過程中C的每個簡單條件的輸出都滿足D中對應的約束，則稱條件C的條件約束D由C的執行所覆蓋。 　　對於布林變數B，B輸出的約束說明B必須是真(t)或假(f)。類似地，對於關係表示式，符號＜、=、＞用於指定表示式輸出的約束。 　　作為簡單的例子，考慮條件 　　C1∶B1＆B2 　　其中B1和B2是布林變數。C1的條件約束式如(D1，D2)，其中D1和D2是“t”或“f”，值(t，f)是C1的條件約束，由使B1為真B2為假的測試所覆蓋。BRO測試策略要求約束集｛(t，t)，(f，t)，(t，f)｝由C1的執行所覆蓋，如果C1由於布林運算元的錯誤而不正確，至少有一個約束強制C1失敗。 　　作為第二個例子，考慮 　　C2∶B1＆(E3=E4) 　　其中B1是布林表示式，而E3和E4是算術表示式。C2的條件約束形式如(D1，D2)，其中D1是“t”或“f”，D2是＜，=或＞。除了C2的第二個簡單條件是關係表示式以外，C2和C1相同，所以可以修改C1的約束集｛(t，t)，(f，t)，(t，f)｝，得到C2的約束集，注意(E3=E4)的“t”意味著“=”，而(E3=E4)的“f”意味著“＞”或“＜”。分別用(t，=)和(f，=)替換(t，t)和(f，t)，並用(t，＜＼＜＞)和(t，＞)替換(t，f)，就得到C2的約束集｛(t，=)，(f，=)，(t，＜)，(t，＞)｝。上述條件約束集的覆蓋率將保證檢測C2的布林和關係運算元的錯誤。 　　作為第三個例子，考慮 　　C3∶(E1＞E2)＆(E3=E4) 　　其中E1、E2、E3和E4是算術表示式。C3的條件約束形式如(D1，D2)，其中D1和D2是＜、=或＞。除了C3的第一個簡單條件是關係表示式以外，C3和C2相同，所以可以修改C2的約束集得到C3的約束集，結果為 　　｛(＞，=)，(=，=)，(＜，=)，(＞，＞)，(＞，＜)｝ 　　上述條件約束集能夠保證檢測C3的關係操作符的錯誤。 　　1.5.2 資料流測試 　　資料流測試方法按照程式中的變數定義和使用的位置來選擇程式的測試路徑。已經有不少關於資料流測試策略的研究。 　　為了說明資料流測試方法，假設程式的每條語句都賦予了獨特的語句號，而且每個函式都不改變其引數和全域性變數。對於語句號為S的語句， 　　DEF(S)=｛X｜語句S包含X的定義｝ 　　USE(S)=｛X｜語句S包含X的使用｝ 　　如果語句S是if或迴圈語句，它的DEF集為空，而USE集取決於S的條件。如果存在從S到S′的路徑，並且該路徑不含X的其他定義，則稱變數X在語句S處的定義在語句S′仍有效。 　　變數X的定義—使用鏈(或稱DU鏈)形式如［X，S，S′］，其中S和S′是語句號，X在DEF(S)和USE(S′)中，而且語句S定義的X在語句S′有效。 　　一種簡單的資料流測試策略是要求覆蓋每個DU鏈至少一次。我們將這種策略稱為DU測試策略。已經證明DU測試並不能保證覆蓋程式的所有分支，但是，DU測試不覆蓋某個分支僅僅在於如下之類的情況：if-then-else中的then沒有定義變數，而且不存在else部分。這種情況下，if語句的else分支並不需要由DU測試覆蓋。 　　資料流測試策略可用於為包含巢狀if和迴圈語句的程式選擇測試路徑，為此，考慮使用DU測試為如下的PDL選擇測試路徑： 　　proc x 　　B1； 　　do while C1 　　if C2 　　then 　　if C4 　　then B4； 　　else B5； 　　endif； 　　else 　　if C3 　　then B2； 　　else B3； 　　endif； 　　endif； 　　enddo； 　　B6； 　　end proc； 　　為了用DU測試選擇控制流圖的測試路徑，需要知道PDL條件或塊中的變數定義和使用。假設變數X定義在塊B1，B2，B3，B4和B5的最後一條語句之中，並在塊B2，B3，B4，B5和B6的第一條語句中使用。DU測試策略要求執行從每個B(0＜i≤5)到Bj(0＜j≤6)的最短路徑(這樣的測試也覆蓋了條件C1，C2，C3和C4中的變數使用)。儘管有25條X的DU鏈，只需5條路徑覆蓋這些DU鏈。原因在於可用5條從Bi(0＜i≤5)到B6的路徑覆蓋X的鏈，而這5條鏈包含迴圈的迭代就可以覆蓋其他的DU鏈。 　　注意如果要用分支測試策略為上述的PDL選擇測試路徑，並不需要另外的資訊。為了選擇BRO測試的路徑，只需知道每個條件和塊的結構。(選擇程式的路徑之後，需要決定該路徑是否實用於該程式，即是否存在執行該路徑的至少一個輸入)。 　　由於變數的定義和使用，程式中的語句都彼此相關，所以資料流測試方法能夠有效地發現錯誤，但是，資料流測試的覆蓋率測度和路徑選擇比條件測試更為困難。 　　1.5.3迴圈測試 　　迴圈是大多數軟體實現演算法的重要部分，但是，在軟體測試時卻很少注意它們。 　　迴圈測試是一種白盒測試技術，注重於迴圈構造的有效性。有四種迴圈［BEI90］：簡單迴圈，串接迴圈，巢狀迴圈和不規則迴圈(如圖1-9所示)。 　　簡單迴圈。下列測試集應當用於簡單迴圈，其中n是允許通過迴圈的最大次數。 　　1.整個跳過迴圈。 　　2.只有一次通過迴圈。 　　3.兩次通過迴圈。 　　4.m次通過迴圈，其中m＜n。 　　5.n-1，n，n+1次通過迴圈。 　　巢狀迴圈。如果要將簡單迴圈的測試方法用於巢狀迴圈，可能的測試數就會隨巢狀層數成幾何級增加，這會導致不實際的測試數目，Beizer［BEI90］提出了一種減少測試數的方法：* 　　1.從最內層迴圈開始，將其他迴圈設定為最小值。 　　2.對最內層迴圈使用簡單迴圈測試，而使外層迴圈的迭代引數(即迴圈計數)最小，併為範圍外或排除的值增加其他測試。 　　3.由內向外構造下一個迴圈的測試，但其他的外層迴圈為最小值，並使其他的巢狀迴圈為“典型”值。 　　4.繼續直到測試完所有的迴圈。 　　串接迴圈。如果串接迴圈的迴圈都彼此獨立，可以使用巢狀迴圈的策略測試串接迴圈。但是，如果兩個迴圈串接起來，而第一個迴圈的迴圈計數是第二個迴圈的初始值，則這兩個迴圈並不是獨立的。如果迴圈不獨立，則推薦使用巢狀迴圈的方法進行測試。 　　不規則迴圈。儘可能的情況下，要將這類迴圈重新設計為結構化的程式結構。 　　1.6黑盒測試 　　黑盒測試注重於測試軟體的功能性需求，也即黑盒測試使軟體工程師派生出執行程式所有功能需求的輸入條件。黑盒測試並不是白盒測試的替代品，而是用於輔助白盒測試發現其他型別的錯誤。 　　黑盒測試試圖發現以下型別的錯誤：(1)功能不對或遺漏，(2)介面錯誤，(3)資料結構或外部資料庫訪問錯誤，(4)效能錯誤和(5)初始化和終止錯誤。 　　白盒測試在測試的早期執行，而黑盒測試主要用於測試的後期。黑盒測試故意不考慮控制結構，而是注意資訊域。測試用於回答以下問題： 　　·如何測試功能的有效性？ 　　·何種型別的輸入會產生好的測試用例？ 　　·系統是否對特定的輸入值尤其敏感？ 　　·如何分隔資料類的邊界？ 　　·系統能夠承受何種資料率和資料量？ 　　·特定型別的資料組合會對系統產生何種影響？ 　　運用黑盒測試，可以匯出滿足以下標準的測試用例集［MYE79］：(1)所設計的測試用例能夠減少達到合理測試所需的附加測試用例數，和(2)所設計的測試用例能夠告知某些型別錯誤的存在或不存在，而不是僅僅與特定測試相關的錯誤。 　　1.6.1 基於圖的測試方法 　　黑盒測試①的第一步是理解軟體所表示的物件②及其關係，然後，第二步是定義一組保證“所有物件與其他物件都具有所期望的關係”［BEI95］的測試序列，換而言之，軟體測試首先是建立物件及其關係圖，然後匯出測試序列以檢查物件及其關係，並發現錯誤。 　　為了完成這些步驟，軟體工程師首先建立一個圖，節點代表物件，連線代表物件間的關係，節點權值描述節點的屬性(如特定的資料值或狀態行為)，連線權值描述連線的特點①。 　　圖的符號表示如圖1-10a所示。節點表示為圓，而連線有幾種，有向連線(有箭頭表示)表明關係只在一個方向上存在。雙向連線，也稱為對稱連線，表示關係適於兩個方向。如果節點間有幾種聯絡，就使用並行邊。 　　舉一個簡單的例子，考慮部分字處理應用程式圖，如圖1-10b所示： 　　物件＃1=新建檔案選單選擇 　　物件＃2=文件視窗 　　物件＃3=文件文字 　　如圖所示，選擇選單“新建檔案”產生一個文件視窗，文件視窗的節點權值提供視窗產生時所期望的屬性集，連線權值表明視窗必須在1.0秒之內產生，一條無向邊在“選擇選單新建檔案”和“文件文字”之間建立對稱聯絡，並行連線表明“文件視窗”和“文件文字”間的聯絡，事實上，要產生測試用例還需要更加詳細的圖。軟體工程師遍歷圖，並覆蓋所顯示的聯絡就可以匯出測試用例，這些用例用於發現聯絡之間的錯誤。 　　Beizer［BEI95］描述了幾個使用圖的行為測試方法： 　事務流建模。節點代表事務的步數(如使用聯機服務預訂航空機票的步數)，連線代表步驟之間的連線關係(如flighgt.information.input後跟validation/availabilty.processing)。資料流圖可用於輔助產生這種圖。 　　有限狀態建模。節點代表不同使用者可見的軟體狀態(如訂票人員處理訂票時的各個螢幕)，而連線代表狀態之間的轉換(如order-information在inventory-availability-look-up時驗證並後跟customer-billing-information-input)。狀態變遷圖可用於輔助產生這種圖。 　　資料流建模。節點是資料物件，而連線是將資料物件轉換為其他物件時發生的變換。例如，節點FICA.tzx.withheld(FTW)由gross.wagess(GW)利用關係FTW=0.062×GW計算而來。 　　時間建模。節點是程式物件，而連線是物件間的順序連線。連線權值用於指定程式執行時所需的執行時間。 　　基於圖的測試方法的詳細討論超出了本書的範圍。但是，大致瞭解一下基於圖的測試還是值得的。 　　基於圖的測試開始定義節點和節點權值，也即標識物件及其屬性，資料模型可以作為起始點，但是要注意很多節點是程式物件(不在資料模型中時顯表示出來)，為了標識圖的起點和終點，可以定義入點和出點。 　　標識節點以後，就可以建立連線及其權值，連線一般應當命名，但是當代表程式物件間控制流的連線時除外。 　　很多情況下，圖模型可能有迴圈(如圖的路徑含有環)，迴圈測試也可用於行為(黑盒)測試，圖可用於標識需要測試的迴圈。 　　分別研究每個關係，以匯出測試用例。研究順序關係的傳遞性可以發現關係在物件間傳播的影響。舉例說明，有三個物件X，Y和Z。考慮如下關係： 　　計算Y需要X 　　計算Z需要Y 　　所以，X和Z之間有傳遞性： 　　計算Z需要X 　　基於這種傳遞性，測試Z的計算時要考慮X和Y的各種值。 　　關係(圖連線)的對稱性也是設計測試用例的重要考慮，如果關係是雙向(對稱)的，就要測試這種性質。很多應用程式的UNDO功能［BEI95］實現了有限的對稱性，應該徹底測試並標識鴕饉械囊斐＃床荒蓯褂肬NDO的地方)。最後，圖的每個節點都應當有到自己的關係，本質上是“空操作”迴圈，自反性也應當進行測試。 　　開始設計測試用例時，第一個目標是節點的覆蓋度，這意味著測試不應當遺漏某個節點，而且節點的權值是正確的。 　　接著，考慮連線的覆蓋率，基於屬性測試每個關係，例如，測試對稱關係以表明它的確是雙向的，測試傳遞關係以表明存在傳遞性，測試自反關係以表明存在空操作。指明連線權值時，要設計測試以展示權值是否有效，最後，加入迴圈測試(參見1.5.3節)。 　　1.6.2 等價劃分 　　等價劃分是一種黑盒測試方法，將程式的輸入域劃分為資料類，以便匯出測試用例。理想的測試用例是獨自發現一類錯誤(如字元資料的處理不正確)。等價劃分試圖定義一個測試用例以發現各類錯誤，從而減少必須開發的測試用例數。 　　等價劃分的測試用例設計基於輸入條件的等價類評估。使用前面章節介紹的概念，如果物件由具有對稱性、傳遞性或自反性的關係連線，就存在等價類［BEI95］。等價類表示輸入條件的一組有效或無效的狀態。典型地，輸入條件通常是一個特定的數值，一個數值域，一組相關值或一個布林條件。可按照如下指南定義等價類： 　　1.如果輸入條件代表一個範圍，可以定義一個有效等價類和兩個無效等價類。 　　2.如果輸入條件需要特定的值，可以定義一個有效等價類和兩個無效等價類。 　　3.如果輸入條件代表集合的某個元素，可以定義一個有效等價類和一個無效等價類。 　　4.如果輸入條件是布林式，可以定義一個有效等價類和一個無效等價類。 　　作為例子，考慮自動銀行應用軟體所維護的資料，使用者可以用自己的微機撥號到銀行，提供六位數的密碼，並遵循一序列鍵盤命令以觸發各種銀行功能。銀行應用程式的軟體可以接受如下格式的資料： 　　區號——空或三位數字。 　　字首——三位數字，但不是0和1開始。 　　字尾——四位數字。 　　密碼——六位字母或數字。 　　命令——“檢查”，“存款”，“付款”等。 　　與銀行應用程式各種資料元素相關的輸入條件可以表示為： 　　區號：輸入條件，布林——區號存在與否。 　　輸入條件，範圍——定義在200和999之間的數值，少數例外。 　　字首：輸入條件，範圍——大於200不含0的數值。 　　字尾：輸入條件，值——四位數字。 　　密碼：輸入條件，布林——密碼存在與否。 　　輸入條件，值——六位字串。 　　命令：輸入條件，集合——包含上述命令。 　　利用上述匯出等價類的指南，就可以為每個輸入域的資料項開發並執行測試用例，測試用例的選擇最好是每次執行最多的等價類屬性。 　　1.6.3邊界值分析 　　由於某些未被完全知道的原因，輸入域的邊界比中間更加容易發生錯誤，為此，可用的邊界值分析(boundary value analysis，BVA)可作為一種測試技術。邊界值分析選擇一組測試用例檢查邊界值。 　　邊界值分析是一種補充等價劃分的測試用例設計技術。BVA不是選擇等價類的任意元素，而是選擇等價類邊界的測試用例，BVA不僅注重於輸入條件，而且也從輸出域匯出測試用例［MYE79］。 　　BVA的指南類似於等價劃分： 　　1.如果輸入條件代表以a和b為邊界的範圍，測試用例應當包含a、b、略大於a和略小於b的值。 　　2.如果輸入條件代表一組值，測試用例應當執行其中的最大值和最小值，還應當測試略大於最小值的值和略小於最大值的值。 　　3.指南1和2也適用於輸出條件，例如，工程分析程式要求輸出溫度和壓強的對照表，測試用例應當能夠建立包含最大值和最小值的項。 　　4.如果程式資料結構有預定義的邊界(如陣列有100項)，要測試其邊界的資料項。 　　大多數軟體工程師會在某種程度上自發地執行BVA，利用上述指南，邊界測試會更加完整，從而更可能發現錯誤。 　　1.6.4 比較測試 　　有些情況下(如航空電子裝置、核電廠控制)，軟體的可靠性絕對重要，此時，需要冗餘的硬體和軟體，以減小錯誤的可能性。開發冗餘軟體時，另外的軟體工程師隊伍利用相同的需求開發應用程式的另外版本，這樣，可用相同的測試資料引進測試以產生相同的輸出，接著，並行執行所有版本並進行實時結果比較以保證一致性。 　　利用從冗餘系統中學到的經驗，研究者建議對關鍵應用程式開發不同的軟體版本，即便最後只使用一個版本，不同的版本成了稱為比較測試或背靠背測試的黑盒測試技術的基礎。 　　同樣的需求有不同的實現時，利用其他黑盒技術(如等價分割)設計的測試用例可以作為另一個版本的輸入，如果每個版本的輸出相同，就可以假定所有的實現都正確，如果輸出不同，就要調查各個版本，以發現錯誤所在。大多數情況下，可用自動化工具進行輸出比較。 　　比較測試並不能夠保證無錯，如果需求本身有錯，所有的版本都可能反映錯誤，另外，如果各個版本產生相同但卻錯誤的結構，條件測試也無法發現錯誤。 　　　　1.7 針對專門環境和應用的測試 　　隨著計算機軟體變得更為複雜，對特殊測試方法的需求也增加了。1.5和1.6兩節所討論的白盒和黑盒測試方法可以用於所有的環境、體系結構和應用程式，但是有時還是需要專門的指南和方法。本節討論用於軟體工程師常見的特定環境、體系結構和應用程式的測試指南。 　　1.7.1 GUI測試 　　圖形使用者介面(GUI)對軟體工程師提出了有趣的挑戰，因為GUI開發環境有可複用的構件，開發使用者介面更加省時而且更加精確，同時，GUI的複雜性也增加了，從而增加了設計和執行測試用例的難度。 　　因為現代GUI有相同的觀感，已經有一序列標準的測試。下列問題可以作為常見GUI測試的指南： 　　對於視窗： 　　·視窗能否基於相關的輸入或選單命令適當地開啟？ 　　·視窗能否改變大小、移動和滾動？ 　　·視窗中的資料內容能否用滑鼠、功能鍵、方向箭頭和鍵盤訪問？ 　　·當被覆蓋並重呼叫後，視窗能否正確地再生？ 　　·需要時能否使用所有視窗相關的功能？ 　　·所有視窗相關的功能是可操作的嗎？ 　　·是否有相關的下拉式選單、工具條、滾動條、對話方塊、按鈕、圖示和其他控制可為視窗可用，並適當地顯示？ 　　·顯示多個視窗時，視窗的名稱是否被適當地表示？ 　　·活動視窗是否被適當地加亮？ 　　·如果使用多工，是否所有的視窗被實時更新？ 　　·多次或不正確按滑鼠是否會導致無法預料的副作用？ 　　·視窗的聲音和顏色提示和視窗的操作順序是否符合需求？ 　　·視窗是否正確地關閉？ 　　對於下拉式選單和滑鼠操作： 　　·選單條是否顯示在合適的語境中？ 　　·應用程式的選單條是否顯示系統相關的特性(如時鐘顯示)？ 　　·下拉式操作能正確工作嗎？ 　　·選單、調色盤和工具條是否工作正確？ 　　·是否適當地列出了所有的選單功能和下拉式子功能？ 　　·是否可以通過滑鼠訪問所有的選單功能？ 　　·文字字型、大小和格式是否正確？ 　　·是否能夠用其他的文字命令啟用每個選單功能？ 　　·選單功能是否隨當前的視窗操作加亮或變灰？ 　　·選單功能是否正確執行？ 　　·選單功能的名字是否具有自解釋性？ 　　·選單項是否有幫助，是否語境相關？ 　·在整個互動式語境中，是否可以識別滑鼠操作？ 　　·如果要求多次點選滑鼠，是否能夠在語境中正確識別？ 　　·如果滑鼠有多個按鈕，是否能夠在語境中正確識別？ 　　·游標、處理指示器和識別指標是否隨操作恰當地改變？ 　　對於資料項： 　　·字母數字資料項是否能夠正確回顯，並輸入到系統中？ 　　·圖形模式的資料項(如滑動條)是否正常工作？ 　　·是否能夠識別非法資料？ 　　·資料輸入訊息是否可理解？ 　　除了上述智慧以外，有限狀態建模圖(參見1.6.1節)也可以用於匯出GUI相關的資料和程式物件的測試集。 　　因為GUI操作相關的排列數很大，所以應當用自動化工具進行測試。近幾年來市場上已有不少的GUI測試工具，關於詳細情況。 　　1.7.2 客戶/伺服器體系結構的測試 　　客戶/伺服器體系(C/S)結構對軟體測試人員提出了很大挑戰。客戶/伺服器的分散式特性、事務處理相關的效能、不同硬體平臺存在的可能性、網路通訊的複雜性、由中心(或分散式)資料庫為多個客戶服務和伺服器的協調需求一起使得C/S體系結構及其軟體的測試更為困難。事實上，最近的工業研究表明開發C/S環境時顯著增加了測試時間和成本。有關客戶/伺服器測試的詳細資訊。 　　1.7.3 測試文件和幫助設施 　　術語“軟體測試”造成一種假象，即測試用例是為程式及其操縱的資料準備的。回憶一下本書第一章所講的軟體定義，要注意到測試必須擴充套件到軟體的第三個元素——文件①。 　　文件錯誤會同資料和程式碼錯誤一樣給程式帶來災難性後果。沒有什麼比精確地按照使用者指南，但得到的結果卻不符合文件的描述更令人氣惱的了。為此，文件測試也是每個軟體測試中有意義的一部分。 　　文件測試可以分為兩個步驟。第一步為正式的技術複審，檢查文件的編輯錯誤；第二步是活性測試(live testing)，結合實際程式的使用而使用文件。 　　活性測試可使用類似於1.6節所述的黑盒測試方法，基於圖的測試可用於描述程式的使用。等價劃分和邊界值分析可以定義輸入型別及其相關的互動，然後就可以按照文件跟蹤程式的使用： 　　·文件是否精確描述瞭如何使用各種使用模式？ 　　·互動順序的描述是否精確？ 　　·例子是否精確？ 　　·術語、選單描述和系統響應是否與實際程式一致？ 　　·是否能夠很方便地在文件中定位指南？ 　　·是否能夠很方便地使用文件排除錯誤？ 　　·文件的內容和索引是否精確完整？ 　　·文件的設計(佈局、縮排和圖形)是否便於資訊的理解？ 　　·顯示給使用者的錯誤資訊是否有更詳細的文件解釋？ 　　·如果使用超級連結，超級連結是否精確完整？ 　　回答這些問題最可行的方法是讓第三個組(如選擇使用者)按照程式的使用測試文件。標出所有錯誤和模糊的地方，以便重寫。 　　1.7.4 實時系統測試 　　很多實時系統的時間依賴性和非同步性給測試帶來新的困難——時間。測試用例的設計者考慮的不僅是白盒和黑盒測試用例，而且包括事件處理(如中斷處理)，資料的時間安排以及處理資料的任務(程序)的併發性。很多情況下，提供的測試資料有時使得實時系統在某狀態下可以正常執行，而同樣的資料在系統處於不同狀態時有時又會導致錯誤。 　　例如，控制影印機的實時軟體在機器影印時接收操作員的中斷(如操作員按某些鍵如“reset”或“darken”)不會產生錯誤，但是如果在夾紙時，按同樣的鍵就會產生一個診斷程式碼，指明夾紙的位置資訊將被丟失。 　　另外，實時系統的軟體和硬體之間的密切關係也會導致測試問題，軟體測試必須考慮硬體故障對軟體處理的影響，這種故障很難實時模擬。 　　實時系統的綜合性測試用例設計方法還有待進一步發展，但是，仍然已有了大致的四步策略： 　　任務測試 測試實時系統的第一步是獨立地測試各個任務。也即對每個任務設計白盒和黑盒測試用例，並在測試時執行每個任務。任務測試能夠發現邏輯和功能錯誤，但是不能發現時間和行為錯誤。 　　行為測試 利用CASE工具建立的軟體模型，就可能模擬實時系統，並按照外部事件的序列檢查其行為，這些分析活動可作為建立實時系統時設計測試用例的基礎。使用類似於等價劃分的技術，可以對事件(如中斷、控制訊號和資料)分類測試，例如，影印機的事件可能是使用者中斷(如重置計數)、機器中斷(如卡紙)、系統中斷(如缺粉)和故障模式(如過熱)。每種事件都可以獨立測試，並且檢查可執行系統的行為以檢測是否有與事件處理相關的繼發性錯誤。對系統模型(在分析活動時開發)的行為和可執行軟體進行符合性比較，看是否一致。測試每種事件以後，以隨機順序和隨機頻率將事件傳給系統，檢查系統行為看是否有行為錯誤。 　　任務間測試 在隔離了任務內部和系統行為錯誤以後，測試就要轉向時間相關的錯誤。用不同的資料率和處理負載來測試與其他任務通訊的非同步任務，看任務間的同步是否會產生錯誤。另外，測試通過訊息佇列和資料儲存進行通訊的任務，以發現這些資料儲存區域大小方面的錯誤。 　　系統測試 整合軟體和硬體，並進行大範圍的系統測試，以發現軟體/硬體介面間的錯誤。 　　很多實時系統處理中斷，所以，測試布林事件的處理尤其重要。利用狀態變遷圖和控制規約，測試者可開發一系列可能的中斷及其將發生的處理，設計測試用例以驗證如下的系統特性： 　　·是否能夠正確賦予和處理中斷的優先權？ 　　·每個中斷的處理是否正確？ 　　·中斷處理的效能(如處理時間)是否符合需求？ 　　·關鍵時刻有大量中斷時，是否會導致功能和效能上的問題？ 　　另外，也測試應當作為中斷處理一部分的傳輸資訊的全域性資料區域，以評估潛在的副作用。