《軟件測試》第四章 檢查產品說明書

• • 4.0 前言
  • 4.1 開始測試
  • • 4.1.1 黑盒測試和白盒測試
    • 4.1.2 靜態測試和動態測試
    • 4.1.3 靜態黑盒測試——測試產品說明書
  • 4.2 對產品說明書進行高級審查
  • • 4.2.1 假設自己是客戶
    • 4.2.2 研究現有的標準和規范
    • 4.2.3 審查和測試類似軟件
  • 4.3 產品說明書的低層次測試技術
  • • 4.3.1 產品說明書屬性檢查清單
    • 4.3.2 產品說明書用語檢查清單

4.0 前言

本章將講述如何測試產品說明書，以便在編寫軟件之前找出缺陷。
本章重點包括：

• 什么是黑盒測試和白盒測試
• 靜態測試和動態測試有何區別
• 審查產品說明書有哪些高級技術
• 在詳細審查產品說明書時應注意哪些特殊的問題

4.1 開始測試

回顧第二章中所講的4種開發模式：大爆炸模式、邊寫邊改模式、瀑布模式和螺旋模式。除了大爆炸模式之外，每一種模式中開發小組都要根據需求文檔編寫一份產品說明書，用以定義軟件是什么樣子的。

產品說明書通常是利用文字和圖形描述產品的書面文檔。

為什么不干脆讓程序員按自己的想法編寫程序呢？問題是這樣做不知道最終會得到什么樣的產品。程序員對于產品外觀、功能和使用方法的見解可能與測試員想的完全不一樣。確保最終產品符合客戶要求以及正確計劃測試投入的唯一方法是在產品說明書中完整描述產品。

編寫產品說明書的另一個好處是軟件測試員可以將其作為測試項目的書面材料，據此可以在編寫代碼之前找出軟件缺陷。

4.1.1 黑盒測試和白盒測試

上圖說明了這兩種方式的差別。在黑盒測試中，軟件測試員只需知道軟件要做什么——而無法看到盒子里的軟件是如何運行的。只要進行一些輸入，就能得到某種輸出結果。他不知道軟件如何運行、為什么會這樣，只知道程序做了什么。

在白盒測試中，軟件測試員可以訪問程序員的代碼，并通過檢查代碼的線索來協助測試——可以看到盒子里面。測試員根據代碼檢查結果判斷可能出錯的數目，并據此定制測試。

4.1.2 靜態測試和動態測試

靜態測試是指測試不運行的部分——只是檢查和審核；動態測試是指通常意義上的測試——使用和運行軟件。以檢查二手車為例：踢一下輪胎、看看車漆、打開引擎蓋檢查都屬于靜態測試技術，發動汽車、聽聽發動機聲音、上路行駛都屬于動態測試技術。

4.1.3 靜態黑盒測試——測試產品說明書

測試產品說明書屬于靜態黑盒測試。產品說明書是書面文檔，而不是可執行程序，因此是靜態的。它是利用各種資源而獲得的數據（諸如易用性研究、焦點人群、銷售收入等）建立的。不必了解怎樣和為什么要獲取這些信息，以及獲取的具體途徑，只需知道它們最終構成產品說明書就可以了。軟件測試員可以利用書面文檔進行靜態黑盒測試，認真查找其中的缺陷。

如果項目沒有產品說明書怎么辦？這表明開發小組采用了大爆炸模式或者松散的邊寫邊改模式。對于測試者而言，這是一種困難的情況。軟件測試員的任務是盡早找出缺陷——最理想的是在軟件代碼編寫之前——但是如果產品沒有說明書，這顯然是不可能的。盡管產品說明書沒有寫，然而總會有人知道產品是什么樣的。這個人可能是開發人員、項目經理或銷售人員。走路、談話和產品說明書一樣都使用同樣的技術來評估“大腦中”的說明書，就好像它們寫在紙上一樣。記下收集到的信息并反復斟酌就可以得到更詳細的資料。對開發小組說：“這是我準備測試和提交缺陷的內容?！彼麄兒芸炀蜁a充不少細節。

4.2 對產品說明書進行高級審查

測試產品說明書的第一步不是馬上鉆進去找缺陷，而是站在一個高度上進行審查。審查產品說明書是為了找出根本性的問題、疏忽或遺漏之處。也許這更像是研究而不是測試，但是研究的本質是為了更好地了解軟件該做什么。如果能夠更好地理解產品說明書后的諸多為什么和怎么做，就可以更好地進行細節檢查。

4.2.1 假設自己是客戶

當軟件測試員第一次接到需要審查的產品說明書時，最容易做的事情是把自己當客戶。研究一下客戶會是什么人；和市場人員或銷售人員聊一下，了解他們對最終用戶的認識；如果產品是一個內部使用的軟件項目，找到使用它的人談一談。

了解客戶所想是很重要的。請記住，質量的定義是“滿足客戶要求”，軟件測試員必須了解并測試軟件是否符合那些要求。熟悉軟件應用領域的相關知識有很大的幫助。

另一方面，假設什么知識也沒有。如果審查產品說明書的某一部分時不理解，不要假設它是對的而把它放過去。最終還得利用這個產品設計書來設計軟件測試，因此，仍免不了要去了解它。最好現在就搞懂。如果如愿以償地發現了缺陷（你會的），則更好。

在假設自己是客戶時不要忘記了軟件的安全性。客戶也許會假設軟件時安全的，但軟件測試員不能假定程序員會正確處理安全問題。這方面必須詳細說明。

4.2.2 研究現有的標準和規范

標準和規范的差別在于程度不同，標準比規范更嚴格。如果小組認為很重要，則標準應該嚴格遵守；規范是可選的，但應該遵守。小組將標準作為規范也不罕見，前提是只要每個人都清楚就行。

下面是一些可以考慮作為標準和規范的例子。但這并不是明確規定的，對具體軟件是否適用需經研究。

公司慣用語和約定。如果軟件是為某公司定制的，就應該采用該公司職員常用的術語和約定。

行業要求。醫藥、工業和金融行業的應用軟件有其必須嚴格遵守的標準

政府標準。政府——特別是軍隊系統有嚴格的標準。

圖形用戶界面（GUI）。如果軟件運行在Microsoft Windows或Apple Macintosh操作系統下，關于軟件外觀和用戶的感受具有公開的標準。

安全標準。軟件及其界面和協議可能需要滿足一定的安全標準或級別。也許還需要進行獨立的認證，以確保其滿足必要的標準。

軟件測試員的任務不是定義軟件要符合何種標準和規范，這是項目經理或者編寫產品說明書的人的任務。軟件測試員要做的是觀察，“檢查”采用的標準是否正確、有無遺漏。在對軟件進行確認和驗收時，還要注意是否與標準和規范相抵觸，把標準和規范視為產品說明書的一部分。

4.2.3 審查和測試類似軟件

了解軟件最終結果的最佳方法就是研究類似軟件。項目經理或者產品說明書編寫人可能已經做了這項工作，因此很容易得到他在研究時使用的產品。

在審查競爭產品時要注意的問題包括：

• 規模。軟件的功能強大還是單一？代碼多還是少？這些差別與測試有關嗎？
• 復雜性。軟件簡單還是復雜？這會影響測試嗎？
• 測試性。是否有足夠的資源、時間和經驗來測試軟件？
• 質量和可靠性。軟件是否完全滿足質量要求？可靠性高還是低？
• 安全性。競爭對手軟件的安全性（不管是宣稱還是實際的）和自身的比較起來如何？

記住要閱讀關于競爭對手軟件的評價方面的聯機或印刷的文章。這對安全方面的問題特別有幫助，因為軟件測試員偶然使用軟件不一定能發現安全方面的缺陷。然而在出版物中，這些問題會特別引起關注。

動手實踐是無可替代的，因此拿到類似軟件就要盡量試，使用它、瘋狂試驗、追根問底，這些都是為仔細審查產品說明書積累大量的經驗。

4.3 產品說明書的低層次測試技術

完成產品設計書的高級審查之后，就可以很好地了解產品以及影響其設計的外部因素。有了這些信息，就可以在更低層次測試產品說明書了。

4.3.1 產品說明書屬性檢查清單

經過深思熟慮，可稱為“一字不漏”的優秀產品說明書應具有8個重要的屬性：

• 完整。是否有遺漏和丟失？完全嗎？單獨使用時是否包含所有內容？
• 準確。既定解決方案正確嗎？目標定義明確嗎？有沒有錯誤？
• 精確、不含糊、清晰。描述是否一清二楚？是否有單獨的解釋？容易看懂和理解嗎？
• 一致。產品功能描述是否自相矛盾，與其他功能有無沖突？
• 貼切。產品功能的陳述是否必要？有沒有多余的信息？功能是否符合原來的客戶要求？
• 合理。在規定的預算和進度下，以現有人力、工具和資源能否實現？
• 代碼無關。產品說明書是否堅持定義產品，而不是定義其軟件設計、架構和代碼？
• 可測試性。功能能否測試？給測試員提供的建立驗證操作的信息是否足夠？

在測試產品說明書、閱讀文字、檢查圖表時，要仔細對照上述清單，看看它們是否具有這些屬性。如果不具備，那就是發現了需要指出的缺陷。

4.3.2 產品說明書用語檢查清單

在審查產品說明書時，作為前一個清單的補充，還有一個問題用語檢查清單。問題用語通常表明功能沒有仔細考慮——可能歸結于前文所述的某一屬性。從產品說明書找出這樣的用語，仔細審查它們在上下文中是怎樣使用的。產品說明書后面可能會闡明或掩飾，也可能含糊其辭——無論是哪一種情況，都可視為軟件缺陷。

• 總是、每一種、所有、沒有、從不。如果看到此類絕對或肯定的描述，需要確認是這樣的。軟件測試員要考慮違反這些情況的用例。
• 當然、因此、明顯、顯然、必然。這些話意圖說服你接受假定情況，不要中了圈套。
• 某些、有時、常常、通常、慣常、經常、大多、幾乎。這些話太過模糊?！坝袝r”發生作用的功能無法測試。
• 等等、諸如此類、以此類推、例如。以這樣的詞結束的功能清單無法測試。功能清單要絕對或者解釋明確，以免讓人對功能清單內容產生迷惑。
• 良好、迅速、廉價、高效、小、穩定。這些是無法量化的用語，它們無法測試。如果說明書中出現這些用語，必須進一步準確定義其含義。
• 處理、進行、拒絕、跳過、排除。這些用語可能會隱藏大量需要說明的功能。
• 如果…那么…（沒有否則），找出“如果…那么…”而缺少配套的“否則”結構的陳述。想一想“如果”沒有發生會怎么樣。

總結

以上是生活随笔為你收集整理的《软件测试》第四章 检查产品说明书的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。