最佳軟體測驗基礎入門教程2基礎

基礎

本章解釋了軟體測驗的基本概念，這些概念將在后面的章節中得到應用，介紹了軟體測驗的七個基本原則，本章的大部分內容都是用來解釋測驗程序的細節和它所涉及的各種活動，最后，我們將討論測驗中涉及的心理問題，以及如何避免或解決這些問題，

2.1概念和動機

• 質量要求

工業生產的產品通常會被抽查，以確保它們滿足計劃的要求并執行所需的任務，不同的產品有不同的質量要求，如果最終產品有缺陷或瑕疵，就必須修改生產程序或設計來補救，

• 軟體是無形的

檢查產品的一部分或成品是很棘手的，因為產品本身實際上并不是有形的，這使得 "親手 "測驗不可能，目測檢查是有限的，只能通過對開發檔案的仔細檢查來進行，

• 有問題的軟體很嚴重

不可靠的軟體或根本不能執行所需的任務的軟體會產生很大的問題，糟糕的軟體會花費時間和金錢，并會毀掉聲譽，它甚至可以危及人的生命--例如，當部分自主車輛中的 "自動駕駛 "軟體做出錯誤的反應或反應過晚，

• 測驗有助于評估軟體質量

因此，檢查軟體產品的質量，以盡量減少故障或崩潰的風險是極其重要的，測驗可以監控軟體質量，并通過在開發階段揭示故障來降低風險，因此，軟體測驗是一項重要的但也是非常復雜的任務，

VSR-II系統的每個版本在交付和推出之前都必須進行適當的測驗，這樣做的目的是為了在故障造成任何損害之前識別和補救故障，例如，如果系統以錯誤的方式執行訂單，會給客戶、經銷商和制造商帶來嚴重的財務問題，同時也會損害制造商的形象，像這樣未被發現的故障會增加軟體運行中的風險，

• 測驗采取抽查的方式

測驗物件被輸入涵蓋各種測驗案例的測驗資料，然后被執行，接下來的評估是檢查測驗物件是否滿足其計劃的要求，

• 測驗不僅僅是在計算機上執行測驗

測驗所涉及的不僅僅是執行一系列的測驗用例，測驗程序涉及一系列獨立的活動，而執行測驗和檢查結果只是其中的兩項，其他測驗活動包括測驗計劃，測驗分析，以及測驗用例的設計和實施，其他活動包括撰寫測驗進度和結果的報告，以及風險分析，根據產品生命周期的不同階段，測驗活動的組織方式也不同，測驗活動和檔案通常在客戶和供應商之間有合同規定，或基于公司自己的內部準則，在第2.3節和第6.3節中，對軟體測驗中涉及的各個活動進行了詳細描述，

• 靜態和動態測驗

除了在計算機上進行的動態測驗（見第5章），需求規格、usercase和源代碼等檔案也需要在開發程序中盡早測驗，這些被稱為靜態測驗（見第4章），檔案中的錯誤越早被發現和補救，對未來的開發程序就越有利，因為你將不再使用有缺陷的源材料，

• 驗證和確認（Verification and validation）

測驗不僅僅是檢查系統是否滿足其需求、用戶故事或其他規范；它也是為了確保產品在真實世界的環境中滿足用戶的愿望和期望，換句話說，就是檢查是否可以按照預期使用該系統，并確保它實作了計劃中的目的，因此，測驗也包括驗證，

• 沒有一個大型系統是沒有錯誤的

目前，不存在無故障的軟體系統，對于超過一定復雜程度的系統或有大量代碼的系統，這種情況不太可能改變，許多故障是由于在代碼開發程序中未能識別或測驗例外情況造成的--比如未能考慮到閏年，或者在時間或資源分配方面沒有考慮到限制，

• 通過測驗無法避免故障的發生

除了非常小的程式之外，即使你進行的每一次測驗的結果都是零缺陷，你也不能保證額外的測驗不會發現以前沒有發現的故障，通過測驗來證明完全沒有缺陷是不可能的，

2.1.1缺陷和故障術語

• 作為測驗起點的測驗基礎

只有當你事先定義了在這種情況下到底應該發生什么時，才能將這種情況歸類為故障，為了做出這樣的定義，你需要知道你所測驗的（子）系統的需求以及其他附加資訊，在這種情況下，我們談論的是測驗的基礎，它是決定特定功能是否有問題的基礎，

• 什么算作是缺陷（defect）？

缺陷被定義為未能滿足預定的要求，或實際行為（在運行時或測驗時）與預期行為（如規范、需求或用戶故事中定義的）之間的差異，換句話說，什么時候系統的行為不符合其實際需求？

與物理系統不同，軟體系統不會因為年齡或磨損而失效，的缺陷從軟體編碼的那一刻起就存在，但只有在系統運行時才會顯現出來，

• 故障（Faults）導致失敗

系統故障是由故障引起的，只有在測驗期間或運行時才會被測驗人員或用戶發現，例如，當系統產生錯誤的輸出或崩潰時，我們需要區分故障的影響和它的原因，系統故障是由軟體中的故障引起的，由此產生的狀況被認為是一種缺陷，"bug"一詞也被用來描述由編碼錯誤導致的缺陷，如代碼中錯誤的編程或遺忘的指令，

• 缺陷掩蓋

故障有可能被程式中其他部分的其他故障所掩蓋，在這種情況下，有問題的故障只有在其他故障被糾正后才會變得明顯，
并非所有的故障都會導致系統失敗，有些失敗對所有的用戶來說從未發生過，或發生過一次，或不斷發生，

• 人會出錯:錯誤的發生有各種原因，一些典型的（根本）原因是：
  • 所有的人都會犯錯!
  • 時間壓力在軟體專案中經常出現，是錯誤的經常性來源，
  • 手頭的任務、系統結構、系統設計或源代碼的復雜性，
  • 專案參與者之間的誤解--通常表現為對需求或其他檔案的不同解釋，
  • 對內部和外部介面的系統互動有關的誤解，大型系統通常有大量的介面，
  • 技術的復雜性，或在專案中引入的專案參與者以前不知道的新技術，
  • 專案參與者沒有足夠的經驗或沒有適當的培訓，

人為錯誤導致部分代碼出現故障，然后導致某種可見的系統故障，理想情況下，這種故障在測驗中被發現，靜態測驗可以直接檢測源代碼中的故障，

系統故障也可以由環境問題引起，如輻射和磁性，或由物理污染引起的硬體和韌體故障，我們在這里將不討論這些型別的故障，

• 假陽性和假陰性結果

并非每個意外的測驗結果都等同于失敗，通常情況下，即使潛在的故障（或其原因）不是測驗物件的一部分，測驗也會顯示失敗，這樣的結果被稱為 "假陽性"，也可能出現相反的結果--即測驗應該揭示故障的存在，但故障并沒有發生，這種型別的結果被稱為 "假陰性"，在評估你的測驗結果時，你必須牢記這兩種情況，你的結果也可以是 "正確的陽性"（通過測驗發現故障）或 "正確的陰性"（通過測驗確認預期行為），關于這些情況的更多細節，見第6.4.1節，

• 從錯誤中學習

如果通過測驗發現了故障和導致故障的錯誤或失誤，那么值得仔細研究一下原因，以便學習如何避免在將來犯同樣（或類似）的錯誤或失誤，你通過這種方式獲得的知識可以幫助你優化你的流程，減少或防止更多故障的發生，

案例研究： 模糊的需求是導致軟體故障的原因之一

客戶可以使用VSR EasyFinance模塊來計算各種車輛融資方案，系統使用的利率存盤在一個表中，盡管購買涉及促銷和特別優惠的車輛可能會有不同的利率，
VSR-II要包括以下的額外要求：
REQ：如果客戶同意并通過在線信用檢查，EasyFinance模塊會從一個特殊的獎勵利率表中應用一個利率，
不幸的是，這項要求的作者忘記澄清，對于作為特別優惠的一部分出售的車輛，不允許降低利率，這導致這種特殊情況在第一個版本中沒有被測驗，反過來，這意味著客戶在網上得到了低利率，但在開具賬單時卻被收取了較高的利率，導致了投訴，

2.1.2測驗術語

• 測驗不是除錯

為了補救一個軟體故障，必須對其進行定位，首先，我們只知道故障的影響，但不知道它在代碼中的位置，尋找和糾正故障的程序被稱為除錯，是開發人員的責任，除錯常常與測驗相混淆，盡管這是兩項截然不同的任務，除錯指出了軟體的故障，而測驗則是用來揭示故障造成的影響，

• 確認性測驗（Confirmation testing）

糾正一個故障可以提高產品的質量（假設糾正不會引起額外的、新的故障），用于檢查故障是否已成功補救的測驗被稱為確認測驗，測驗人員通常負責確認測驗，而開發人員更可能負責組件測驗（和除錯），然而，這些角色在敏捷開發環境或其他軟體生命周期模型中可以改變，
不幸的是，在現實世界中，故障修正常常導致新故障的產生，而這些故障只有在使用全新的輸入場景時才會被發現，這種不可預知的副作用使測驗更加棘手，一旦故障被糾正，你需要重復之前的測驗，以確保目標故障已經被補救，你還需要撰寫新的測驗，檢查糾正程序中不需要的副作用，

• 測驗的目標：靜態和動態測驗是為了實作各種目標：

  • 對與需求、規范、用戶故事、程式設計和代碼有關的作業產品進行定性評價
  • 證明所有的具體要求已經完全實作，測驗物件的功能符合用戶和其他利益相關者的預期
  • 提供資訊，使利益相關者能夠對測驗物件的質量做出可靠的估計，從而對提供的質量產生信心
  • 通過對軟體故障的識別和糾正，可以降低與質量有關的風險水平，系統將包含更少的未被發現的故障，
  • 分析程式及其檔案，以避免不必要的故障，并記錄和補救已知的故障
  • 分析和執行程式，以便重現已知的故障
  • 接收有關測驗物件的資訊，以便決定有關的組件是否可以投入到與其他組件的集成中去
  • 證明測驗物件遵守和/或符合必要的合同、法律和監管要求及標準，

• 目標取決于背景

測驗目標可以根據環境的不同而不同，此外，他們可以根據你使用的開發模式（敏捷或其他）和你正在執行的測驗級別而變化，即組件、集成、系統或驗收測驗（見3.4節），

當你測驗組件時，你的主要目標應該是揭示盡可能多的故障，并盡快識別（即除錯）和補救基本故障，另一個主要目標可以是選擇實作最大程度的代碼覆寫的測驗（見2.3.1節），

驗收測驗的一個目標是確認系統可以按計劃運行和使用，從而滿足其所有的功能和非功能要求，另一個目的是提供資訊，使利益相關者能夠評估風險，并就是否上線做出明智的決定，

題外話：不同型別測驗的命名方案

不同型別的測驗所使用的各種名稱可能會令人困惑，為了理解測驗的命名，區分以下的命名類別是很有用的：

• 測驗目標
  測驗型別的命名是基于測驗目標的（例如，"負載測驗"），

• 測驗方法/技術
  例如，"狀態轉換測驗"，如5.1.3節中所述

• 測驗物件
  例如，"GUI測驗 "或 "資料庫測驗"

• 測驗級別
  例如，"系統測驗"

• 測驗人員
  例如，"開發人員測驗"，"用戶測驗"

• 測驗范圍
  例如，"部分回歸測驗"，

正如你所看到的，并非所有這些術語都定義了獨特的測驗型別，相反，不同的名稱突出了測驗的不同方面，這些方面在特定的環境下或在特定的測驗目標方面是重要的或重點的，

2.1.3測驗工件(Artifact)和它們之間的關系

前面的章節已經描述了一些測驗工件的型別，下面幾節提供了執行動態測驗所需的工件型別的概述，

• 測驗基礎

測驗基礎是測驗程序的基石，如前所述，測驗基礎包括所有幫助我們決定測驗期間是否發生故障的檔案，換句話說，測驗基礎定義了測驗物件的預期行為，常識和專業知識也可以被看作是測驗基礎的一部分，可以用來達成決定，在大多數情況下，需求檔案，規范，或用戶故事，作為測驗基礎，

• 測驗用例和測驗運行

測驗基礎被用來定義測驗案例，當測驗物件被輸入適當的測驗資料并在計算機上執行時，測驗運行就發生了，測驗運行的結果被檢查，團隊決定是否發生了故障，即測驗物件的預期行為和實際行為之間是否有差異，通常，為了運行一個測驗案例，必須滿足某些先決條件--例如，相應的資料庫和資料，

• 測驗條件

測驗條件是從測驗基礎中推斷出來的，以追求特定的測驗目標（見上文），測驗條件可以使用一個或多個測驗來檢查，可以是功能，事務，質量屬性，或一個組件或系統的結構元素，在我們的案例研究中，VSR-II系統的測驗條件的例子是車輛配置的排列組合（見5.1.5節），用戶界面的外觀和感覺，或系統的回應時間，

• 測驗專案

同樣的道理，一個測驗物件很少能作為一個完整的物件來測驗，通常情況下，我們需要確定單獨的專案，然后使用單獨的測驗用例進行測驗，例如，VSR-II的價格計算測驗條件的測驗專案是calculate_price()方法（見5.1.1節），相應的測驗用例是使用適當的測驗技術指定的（見第5章），

• 測驗套件（suite）和測驗執行時間表(schedules)

測驗用例通常被組合在測驗套件中，在一個測驗周期內執行，測驗周期的時間是在測驗執行計劃中定義的，

• 測驗腳本(Test scripts)

測驗套件是使用腳本自動完成的，它包含了測驗序列和所有為測驗創造必要的前提條件所需的行動，并在測驗完成后進行清理，如果你手動執行測驗，同樣的資訊必須提供給手動測驗人員，

• 測驗日志(Test logs)

測驗運行被記錄下來，并記錄在測驗總結報告中，

• 測驗計劃

對于每個測驗物件，你需要創建一個測驗計劃，定義進行測驗所需的一切（見第6.2.1節），這包括你對測驗物件和測驗技術的選擇，測驗目標和報告方案的定義，以及所有測驗相關活動的協調，
下圖顯示了所涉及的各種工件之間的關系，定義測驗程序中涉及的各個活動（見第2.3節）有助于明確每個工件的創建時間，
影像

2.1.4測驗作業

• 測驗作業取決于專案（環境），

測驗占據了開發作業的很大一部分，即使只考慮到所有可設想的測驗的一部分，或者更準確地說，所有可設想的測驗案例，很難說你應該花多少精力去測驗，因為這在很大程度上取決于手頭專案的性質，

測驗的重要性，以及測驗所需的作業量，通常由測驗人員和開發人員的比例來說明，在實踐中，可以發現以下比例：從每10個開發人員有一個測驗到每個開發人員有三個測驗，在現實世界中，測驗作業和預算有很大的不同，

案例研究： 測驗作業和車輛變體

VSR-II使潛在客戶能夠在電腦螢屏上配置自己的車輛，特定車型的額外配置以及選項和預配置車型的可能組合都受制于一套復雜的規則，舊的VSR系統允許客戶選擇實際上無法交付的組合，作為VSR-II質量保證/測驗規劃要求的結果，功能適用性/DreamCar=高（見下文），客戶不應該再選擇不可交付的組合，
負責DreamCar模塊的產品負責人想知道需要多少測驗作業來盡可能全面地測驗模塊的這個方面，為了做到這一點，他對可用的車輛配置選項的最大數量進行了估計，結果如下：
有10種車型，每種車型有5種不同的發動機選項；有10種帶夏季或冬季輪胎的輪輞；有10種顏色，每種顏色有亞光、光亮或珍珠效果選項；有5種不同的娛樂系統，這些選項導致了10×5×10×2×10×3×5=150.000種不同的變體，因此每秒鐘測驗一種變體將總共需要1.7天，
再加上50個額外的選項（每個選項都可以選擇或不選擇），總共產生150.000×250=168.884.986.026.393.600.000個變體，
產品擁有者憑直覺知道，他不需要對每個可能的組合進行測驗，而是要對定義哪些選項組合是不可交付的規則進行測驗，然而，可能的軟體故障會產生這樣的風險：DreamCar模塊錯誤地將一些配置歸類為可交付的（或允許的組合為不可交付的），
這里需要多少測驗作業，它能有效地花費多少錢？產品負責人決定向QA/測驗負責人征求意見，這個問題的可能的解決方案是使用配對測驗，

• 題外話：什么時候增加測驗作業是合理的？

大量的測驗作業是可以承受的，也是合理的嗎？Jerry Weinberg對這個問題的回答是："與什么相比？" ，這個回答指出了使用一個有缺陷的軟體系統的風險，風險是由某種情況出現的可能性和出現時的預期成本計算出來的，在測驗程序中沒有被發現的潛在故障會在以后產生巨大的成本，

例子： 失敗的成本

2016年3月，一系列的軟體故障摧毀了耗資數億美元建造的太空望遠鏡Hitomi，衛星的軟體錯誤地認為它的旋轉速度太慢，并試圖使用反措施進行補償，然后，來自冗余控制系統的信號被錯誤地解釋，旋轉速度不斷增加，直到離心力過大，Hitomi解體，
2018年和2019年，兩架波音737 MAX 8飛機墜毀，原因是飛機的MCAS飛行控制軟體存在設計缺陷，這里也是，軟體--被不正確的傳感器資訊誤導--產生了致命的對策，
測驗作業必須與測驗所能達到的結果保持合理的比例，"只要發現和補救故障的成本低于系統運行時發生的相應故障所產生的成本，測驗就有經濟意義 ，因此，合理的測驗作業總是取決于故障所涉及的風險程度，以及對這所帶來的危險的評估，被摧毀的太空望遠鏡Hitomi的價格可以支付大量的測驗費用，

-案例研究： 發生故障時的風險和損失

DreamCar模塊持續更新并顯示當前配置的價格，已注冊的客戶通過驗證的ID可以在線訂購車輛，
一旦客戶點擊訂購按鈕并輸入他們的PIN碼，車輛就會被訂購并承諾購買，一旦過了法定的撤銷期限，所選擇的配置就會自動傳遞給生產管理系統，啟動建造程序，
由于在線購買程序具有約束力，如果系統計算并顯示錯誤的價格，客戶有權堅持支付該價格，這意味著計算錯誤的價格可能導致制造商以過低的價格出售成千上萬的汽車，根據計算錯誤的程度，這可能導致數百萬美元的損失，讓每個采購訂單都進行人工檢查是不可能的，因為VSR-II系統的全部意義在于，車輛可以完全自動在線訂購，

• 根據風險因素確定測驗的徹底性和范圍

具有高風險的系統或系統部件必須比那些在發生故障時不會造成重大損失的系統或系統部件進行更廣泛的測驗，必須對單個系統部件甚至單個故障模式進行風險評估，如果系統或子系統出現故障的風險很高，那么測驗需要比不太重要的（子）系統更多的努力，這些程式是通過生產安全關鍵系統的國際標準規定的，例如，機載系統和設備認證標準規定了航空系統的復雜測驗程式，

雖然不存在實質性的風險，但電腦游戲如果保存分數不正確，會給其制造商帶來巨大的損失，因為這種故障會影響公眾對游戲及其母公司其他產品的接受程度，并可能導致銷售損失和公司的聲譽受損，

2.1.5 盡早應用測驗技能確保成功

• 測驗是任何成功故事中的重要因素

在軟體專案中，開始準備測驗永遠不會太早，下面的例子說明了讓具有適當測驗知識的測驗人員參與軟體開發生命周期中的個別活動的好處：

• 開發人員和測驗人員在整個開發程序中的緊密合作
  • 如果測驗人員參與檢查需求（例如，使用審查，詳見第4.2節）或完善用戶故事，他們可以利用他們的專業知識，在作業產品中很早就發現并糾正模糊性和錯誤，識別和糾正有缺陷的需求，可以減少產生不適當的或不可測驗的功能的風險，
  • 測驗人員和系統設計人員在設計階段的密切合作有助于所有參與人員更好地理解系統的設計和相應的測驗，這種認識的提高可以減少產 生基本結構性錯誤的風險，并且更容易設計出適當的測驗--例如，在集成測驗中測驗介面（見3.4.2節），
  • 在編碼階段一起作業的開發人員和測驗人員，對代碼本身和它所需要的測驗有更好的理解，這就減少了產生錯誤的代碼和設計不適當的測驗的風險（見6.4.1節的假陰性），
  • 如果測驗人員在發布前對軟體進行驗證和確認，他們肯定會發現并補救其他未被發現的故障，這就增加了產品滿足其要求和滿足其所有利益相關者的概率，

除了這些例子之外，實作之前定義的測驗目標也將有助于成功的軟體開發和維護，

2.1.6 測驗的基本原則

前面幾節提到了軟體測驗，而下面一節則總結了一般測驗的基本原則，這些是經過幾十年的測驗經驗形成的準則，

• 原則#1：測驗顯示缺陷的存在，而不是缺陷的不存在

測驗確定了缺陷的存在，并揭示了導致這些缺陷的故障，根據所做的努力和所涉及的測驗的徹底性，測驗減少了在測驗物件中未被發現的缺陷的概率，然而，測驗并不能使我們證明測驗物件不包含故障，即使在測驗程序中沒有失敗，這也不能證明沒有故障或整體正確性，

• 原則#2：詳盡的測驗是不可能的
  除了極其簡單或微不足道的測驗物件，不可能設計和執行一個完整的測驗套件，涵蓋所有可能的輸入資料組合及其前提條件，測驗始終是樣品，分配給它們的努力取決于它們所涵蓋的風險和分配給它們的優先級，

• 原則#3：早期測驗可以節省時間和金錢
  動態和靜態測驗活動應該在系統的生命周期內盡早定義和開始，術語 "左移 "意味著早期測驗，早期測驗可以在開發程序的早期階段揭示故障，在軟體方面，這有助于避免（或至少減少）在開發生命周期后期對故障進行越來越昂貴的修復，

• 原則#4：缺陷聚集在一起

一般來說，缺陷不會均勻地分布在整個系統中，大多數缺陷通常可以在少數模塊中發現，這種（估計的或觀察到的）聚類效應可以用來幫助分析風險，然后，可以將測驗作業集中在系統中最相關的部分（也見上述原則2），

• 原則之五：抗藥性

隨著時間的推移，測驗變得不那么有效，就像昆蟲對殺蟲劑產生抗藥性一樣，如果你在一個不變的系統上重復測驗，他們不會發現任何新的失敗，為了使你的測驗保持有效，你需要定期檢查你的測驗用例，如果有必要，修改它們或添加新的用例，這可以確保你測驗以前未檢查的組件和以前未測驗的輸入資料，從而揭示這些產生的任何故障，殺蟲劑悖論也可以產生積極的影響，例如，如果自動回歸測驗顯示出低數量的故障，這可能不是軟體質量高的結果，而是由于使用中的（可能是過時的）測驗案例的無效性，

• 原則#6：測驗是依賴于環境的

測驗需要適應所提出的目的和有關系統的周圍環境，沒有兩個系統能以同樣的方式進行有效測驗，測驗的徹底性、退出標準和其他引數需要根據系統的作業環境進行獨特的定義，一個嵌入式系統需要不同的測驗，例如，一個電子商務系統，敏捷專案的測驗與基于順序生命周期模型的專案的測驗將有很大不同，

• 原則7：不存在錯誤是一種謬論

即使你全面地測驗了所有的需求，并且糾正了所有發現的錯誤，仍然有可能開發出難以使用的系統，不能滿足用戶的期望，或者與其他類似的系統（或同一系統的早期版本）相比，質量很差，原型設計和系統用戶的早期參與是用來避免這個問題的預防措施，

2.2軟體質量

軟體測驗的作用是識別和補救故障，提高軟體質量，測驗案例的選擇應該反映系統設計的后續真實世界的使用情況，測驗所驗證的質量應該等同于用戶體驗的質量，
然而，軟體質量不僅僅是糾正測驗中發現的故障，
ISO 25010： 使用質量模型和產品質量模型

2.2.1根據ISO 25010的軟體質量

根據ISO 25010標準[ISO 25010]，軟體質量可以從兩個主要方面進行分類：使用質量模型和產品質量模型，

使用中的質量模型包括以下五個特征：

• 有效性
• 效率
• 滿意度
• 低風險
• 周境覆寫

產品質量模型包括八個特征：

• 功能適用性
• 性能效率
• 兼容性
• 易用性
• 可靠性
• 安全性
• 可維護性
• 可移植性

產品質量模型與之前的ISO 9126標準有最大的相似之處，資料質量模型的細節可以在ISO 25012標準中找到，
為了有效地判斷一個軟體系統的質量，所有這些特性和質量標準都需要在測驗程序中加以考慮，測驗物件的每個特征所要達到的質量水平必須事先在質量要求中定義，這些要求和標準的滿足情況必須通過適當的測驗來檢查，

質量模型25010_20130729_完整版.docx: https://url97.ctfile.com/f/18113597-854695755-a34349 (訪問密碼: 2274)

ISO 25010將上面列出的13個質量特性細分為總共40個子特性，詳細介紹使用中的質量和產品質量模型的所有40個子特征，超出了本文的范圍，一些比較重要的特征總結如下：

• 功能適合性（Functional suitability）

功能完整性（Functional Completeness）：軟體產品實作的功能達到所有指定任務和用戶目標的程度，功能集是否涵蓋所有指定的任務和用戶目標？
功能正確性（Functional Correctness）：軟體產品提供具有所需精度的正確或者相符的結果的程度，產品/系統是否以要求的準確度提供正確的結果？
功能適當性（Functional Appropriateness）：軟體產品促進完成指定任務和目標的程度，可用的功能在多大程度上完成了所需的任務和指定的目標？

適當的測驗可以用來檢查指定和隱含的要求是否反映在可用的功能中，從而回答上面提出的問題，
功能通常被描述為特定的輸入/輸出行為和/或特定的系統對特定輸入的反應，測驗的目的是為了證明每個所需的功能已經以這樣的方式實作，即指定的輸入/輸出行為或系統行為得到遵守，

• 可靠性（Reliability）

成熟度（Maturity）：軟體系統、產品或組件在正常運行下滿足可靠性要求的程度，在正常作業條件下，一個系統、產品或部件在多大程度上提供所需的可靠性？
可用性（Availability）：軟體系統或產品在使用時可操作和可訪問的程度，系統、產品或部件是否總是可以使用，以及在需要時是否容易獲得？
容錯性（Fault tolerance）：盡管存在硬體或軟體故障，但軟體系統、產品或組件仍然按照預期運行的程度，盡管存在已知的硬體或軟體故障，系統、產品或組件的功能如何？
易恢復性（Recoverability）：當發生中斷或故障時，軟體產品或系統能夠恢復直接受影響的資料并重新建立系統所需狀態的程度，在系統或產品發生故障或崩潰后，需要多長時間才能恢復特定資料和正常服務？

• 滿意度

使用中的質量模型的滿意度是指在特定情況下使用產品或系統時，用戶需求被滿足的程度，這個質量特征有四個子特征：
有用性：用戶滿意程度是他們認為達成務實的目標，包括使用結果和使用影響，用戶對感知到的實用目標的實作有多高興，包括使用該系統的結果和后果？
信任：用戶或其他利益相關者對一個產品或系統的行為為目的信心程度，用戶（或其他利益相關者）對產品或系統的行為是否符合預期有多確定？
有趣：用戶從滿足他們的個人需求中獲得樂趣的程度，當用戶使用該系統來滿足他/她的個人要求時，他/她能體驗到多少樂趣？
舒適：用戶對身體舒適的滿意程度，用戶覺得這個系統有多舒適--也包括身體健康方面？

使用質量模型的大多數特征都有很強的個人因素，只有在特殊情況下才能客觀地看待和精確地評價，為了測驗這種質量特性，你需要參考多個用戶（或用戶組），以便獲得可用的測驗結果，

一個軟體系統不可能在同等程度上滿足所有的質量特性，滿足一個特性往往意味著不能滿足另一個特性，一個高效的軟體系統并不容易移植，因為它的開發者會設計它來利用它所運行的平臺的特定屬性，

• 確定質量特征的優先次序

因此，有必要對這些特性進行優先排序，由此產生的優先級也將作為每個特性的測驗徹底性的準則，

案例研究： 將ISO 25010應用于VSR-II

VSR-II的測驗/QA負責人向專案指導委員會建議使用ISO 25010中描述的產品質量模型，委員會同意并要求測驗/QA負責人準備一份概念檔案，說明如何在VSR-II專案中應用該標準，草案的核心是一個矩陣，說明每個質量屬性與每個產品組件的相關性，以及應用哪些解釋，矩陣的初始草案看起來像這樣：

這些風險分類要解釋，并由每個質量特性的測驗/質量保證負責人進行論證，例如：

• 功能適用性/所有模塊

每個模塊都為大量的用戶服務，并處理大量的資料，所以功能故障有可能產生相當大的成本，因此，該要求對所有模塊都被歸類為 "高"，

• 兼容性/連接的汽車
  沒有要求，因為這個模塊要從頭開始建立，

• 可用性/事實書
  沒有要求，因為這是一個后端模塊，API已經存在，

• 可移植性/DreamCar
  這個特性被歸類為 "低"，因為正在使用的框架涵蓋了它，不需要應用額外的措施，

哪些檢查和測驗是需要的，將在每個模塊的質量保證/測驗計劃中確定，這種頂層分類可以用來建立基本引數--例如，自動化的持續集成測驗（見3.2節）對 "高 "特性是必需的，單輪驗收測驗對 "中 "特性是足夠的，而關于團隊如何處理問題的書面設計指南對 "低 "特性是足夠的，QA/測驗負責人肯定要與各團隊進行多輪評估，以便就這些高級別的規則達成一致，

2.2.2 質量管理和質量保證

• 質量管理

質量管理（QM Quality management）包括所有用于控制質量的組織活動和措施，質量管理通常負責確定質量政策、質量目標、質量規劃、質量保證和質量改進，這使得質量管理成為一項核心管理活動，質量管理在航空、汽車和醫療保健等行業是強制性的，

• ISO 9000

ISO 9000系列的質量管理標準[ISO 9000]被廣泛使用，ISO/IEC 90003軟體工程標準[ISO 90003]規定了如何將ISO 9001[ISO 9001]的一般準則應用于計算機軟體，

• 質量保證

質量保證（QA Quality assurance）通常集中在一些措施上，這些措施旨在確保指定的程式得到應用，定義的程序得到遵守，假設一個公司堅持其預定的流程，它將滿足所需的質量特性，從而達到指定的質量水平，在這種情況下，結果通常會顯示出質量的提高，這反過來有助于避免作業產品和相應檔案的失敗，

• QA和測驗

術語 "質量保證 "在提到測驗程序時經常被使用，甚至作為測驗的同義詞，QA和測驗程序密切相關，但絕對不一樣，QA產生對質量要求的滿足的信心，這可以通過測驗來實作，有效的QA還包括分析各種缺陷的原因，并用于識別（測驗）和補救（除錯）它們，其結果在被稱為 "回顧 "的會議上進行討論，并可用于改進相關流程，因此，測驗的作用是證明所要求的質量水平已經達到，

測驗活動是整個軟體開發和維護程序的一部分，由于QA是為了確保這些程序被正確實施和執行，QA也支持有效的測驗，下一節將更詳細地描述測驗程序本身，

2.3 測驗程序

• 開發模型

第3章介紹了不同型別的軟體開發生命周期模型（也更簡單地稱為 "開發模型"），這些都是為了幫助新的或持續的軟體專案的結構化、規劃和管理，為了進行結構良好的測驗，你通常需要的不僅僅是對構成開發模型的活動的描述，除了在整個開發程序中對測驗進行定位外，你還需要一個詳細的專門的測驗時間表，換句話說，被稱為 "測驗 "的開發任務的內容需要被分解成更小、更容易管理的步驟，
測驗包括一連串的單獨活動

有許多廣泛使用的、經過驗證的測驗活動，測驗程序將由這些種類的活動組成，你需要根據指定的（或繼承的）專案情況，組建合適的測驗程序，你選擇的具體測驗活動，以及你如何（和何時）實施它們，將取決于許多因素，并且通常基于公司或專案特定的測驗策略（見6.2節），如果你忽略了某些測驗活動，你將增加測驗程序不能達到其目標的可能性，

• 主要活動

測驗程序一般包括以下活動：

• 測驗計劃
• 測驗監測和控制
• 測驗分析
• 測驗設計
• 測驗實施
• 測驗執行
• 測驗完成

這些活動中的每一項都包括多個單獨的任務，它們產生各自的產出，并根據手頭的專案在性質上有所不同，

• 迭代測驗

即使測驗程序中涉及的各個任務是按邏輯順序定義的，在實踐中，它們可以（也可能）重疊，有時也會同時進行，即使你打算按照預定的順序進行測驗活動，順序開發模式（例如，"瀑布 "模式）也會導致個別活動或部分活動的重疊、組合、并發或取消，
調整這些活動以適應系統和專案背景（見下文）通常是必要的，無論你使用哪種開發模式，

軟體通常是以小的迭代步驟開發的--例如，敏捷開發方法使用連續的構建和測驗迭代，因此，相應的測驗活動也需要連續和迭代地進行，
下面的章節概述了各個測驗步驟和它們的輸出，測驗管理負責監測和執行這些活動中的大部分，在第6章中詳細描述（見第6.2和6.3節），

2.3.1測驗計劃

如果沒有一個計劃，像測驗這樣廣泛的任務的結構化處理將無法進行，測驗計劃在軟體專案開始時就直接開始，像任何計劃一樣，有必要定期審查你的測驗計劃，并更新或調整它以適應不斷變化的情況和專案引數，因此，測驗計劃是重復的活動，在整個產品生命周期中進行，如果有必要的話，可以進行調整，

• 測驗計劃：規劃內容

規劃測驗時的主要任務是根據你選擇的測驗策略創建測驗計劃，這個測驗計劃定義了測驗物件、質量特征和測驗目標，以及你計劃用來驗證它們的測驗活動，因此，測驗計劃描述了你的測驗技術，所需的資源，以及執行相應測驗活動所需的時間，

• 覆寫率標準

你已經進行了充分的測驗，這一點由計劃的覆寫率決定，也是測驗計劃的一部分，這種標準通常被稱為 "完成標準 "或 "退出標準"，或者在敏捷專案中被稱為 "完成定義"，如果為每個測驗級別或型別定義了覆寫標準，你可以客觀地評估你所進行的測驗是否可以被視為足夠，覆寫標準也可以用來監測和控制測驗，它們還可以驗證你何時達到了你的測驗目標，

測驗計劃還包含測驗基礎的資訊，它是你所有測驗考慮的基石，測驗計劃還需要包括有關測驗基礎和測驗活動結果之間的可追溯性資訊，例如，這可以幫助你確定哪些測驗基礎的變化修改了哪些測驗活動，從而使你能夠適應或增強它們，

測驗計劃還定義了哪些測驗要在哪個測驗級別進行（見3.4節），為每個測驗級別起草一個單獨的測驗計劃通常是有意義的，你可以用一個主測驗計劃將這些計劃匯總到一起，

• 測驗計劃：日程安排(Schedule）

測驗計劃包含了測驗程序中涉及的所有活動、任務和/或事件的清單，這個串列包括每個活動的計劃開始和結束時間，活動之間的相互依存關系在測驗時間表中指出，

該計劃還定義了關鍵活動的最后期限，以支持其在專案期間的實際執行，測驗時間表可以是測驗計劃的一部分，

2.3.2測驗監控和控制

• 確保可追溯性

監測和控制包括不斷觀察當前測驗活動與計劃活動的比較，報告任何差異，以及在變化的情況下執行實作計劃目標所需的活動，計劃的更新也必須以變化的情況為基礎，

• 退出標準是否得到滿足？

測驗監測和控制活動是以每項活動或任務的退出標準為基礎的，對某一特定測驗級別的測驗退出標準是否已經實作的評價可以包括
a.根據可用的測驗結果和日志，達到測驗計劃中定義的覆寫程度，如果預定的標準得到滿足，活動就可以終止了，
b.根據測驗結果和日志，確定所需的組件或系統質量，如果所要求的質量已經達到，測驗活動就可以結束，
c.如果風險評估是測驗計劃的一部分，你需要證明你有足夠的風險覆寫，這也可以用測驗結果和日志來確定，

• 執行額外的測驗或承擔風險？

如果你所進行的測驗沒有達到要求的退出標準，你需要設計和執行額外的測驗，反之需要澄清情況并評估隨之而來的風險，

• 進度和完成報告

利益相關者希望收到定期的測驗進度報告，與整體計劃相比，當前的測驗進度，除了與原計劃的任何偏差，這些報告還應該包含有關任何過早終止的測驗（見上文）或未完成計劃的退出標準的資訊，在達到專案里程碑時，應提供測驗總結報告，
所有的測驗報告都應包含與接受者相關的細節，并包括進度報告以及測驗結果，報告還應該回答或預先回答管理問題，如（預期）結束時間，計劃與實際使用的資源，以及涉及的測驗作業量，
進度監測可以基于團隊成員的報告，也可以基于自動化工具提供的數字和分析，

2.3.3測驗分析

• 我們需要測驗 "什么"？

測驗分析包括確定到底需要測驗什么，為此，要檢查測驗基礎，看要使用的檔案是否足夠詳細，是否包含可測驗的功能，以便得出測驗條件，測驗條件需要被檢查的程度是由可衡量的定義的覆寫標準決定的，
以下檔案和資料可以用來分析測驗基礎和計劃的測驗水平：

• 分析測驗的基礎

規定了計劃中的功能性和非功能性的系統或組件行為的要求，需求規格包括技術需求、功能需求、系統需求、用戶故事、史詩1、用例和類似的作業產品或檔案，例如，如果需求沒有足夠精確地指定預測的結果和/或系統行為，那么測驗用例就不能簡單地匯出，必須進行重做，

• 分析檔案

引起特定組件或系統結構的設計或實作資料、系統或軟體架構檔案、設計規范、呼叫圖、模型圖（例如，UML或物體關系圖）、介面規范以及類似的材料都可以用來作為測驗基礎，例如，你需要分析介面如何容易被處理（介面開放性），以及測驗物件如何容易被劃分為較小的子單元，以便分別測驗這些，你需要在開發階段考慮這些方面，測驗物件也需要相應的設計和編碼，

• 檢查測驗物件

你需要調查各個組件或系統本身，包括代碼庫、資料庫元資料、資料庫查詢和其他介面，例如，你需要檢查代碼的結構是否良好，是否容易理解，所要求的代碼覆寫率（見5.1節）是否容易實作和驗證，

• 風險分析

涵蓋系統或其組成部分的功能、非功能和結構方面的風險分析報告也需要進行調查，如果潛在的軟體故障造成了嚴重的風險，測驗也需要相應的徹底，對于不屬于關鍵任務的軟體，可以不那么正式地進行測驗，

• 潛在的檔案錯誤

整個測驗程序的基石是測驗基礎，如果測驗基礎包含缺陷，你就不能制定 "正確的 "測驗條件，也就不能起草 "適當的 "測驗案例，因此，你也需要分析測驗基礎的缺陷，檢查它是否包含歧義，或者在功能描述中是否有空白或遺漏，你需要檢查檔案中的不一致、不精確、矛盾，以及重復和/或多余的段落，你發現的任何缺陷或差異都應立即糾正，

從測驗基礎上發現和消除缺陷是非常重要的，特別是在檔案還沒有被審查的情況下（見4.3節），行為驅動開發（BDD）和驗收測驗驅動開發（ATDD）等開發方法，在編碼開始前使用驗收標準和用戶故事來創建測驗條件和測驗案例，這種方法使得在開發程序的更早階段識別和補救缺陷更加簡單，

• 確定測驗的優先次序

一旦測驗條件被識別和定義，你需要對它們進行優先排序，這可以確保最重要的和高風險的測驗條件被首先測驗，在現實世界中，時間的限制往往使得不可能執行所有計劃的測驗，

• 可追溯性很重要

在計劃階段，你需要確保在測驗基礎和測驗活動的結果之間有明確的雙向可追溯性（見上文），這種可追溯性必須精確定義哪個測驗條件檢查哪個需求，反之亦然，
這是確保你以后能確定哪些需求需要被測驗的徹底性的唯一方法，并且取決于測驗條件--使用哪些測驗案例，

• 選擇測驗技術

在分析階段考慮使用哪種測驗技術（即黑盒，白盒，基于經驗，見第5章）是很有用的，每種技術都有自己的系統，可以減少忽視測驗條件的可能性，并幫助精確定義這些條件，例如，使用等價磁區（或 "等價類"）測驗（見第5.1.1節）確保整個輸入域被用于創建測驗用例，這可以防止你在需求定義中忘記或忽略了負面的輸入，然后，你可以定義你的測驗條件來涵蓋負的輸入資料，
如果你使用基于經驗的測驗技術（見第 5.3 節），你可以使用分析期間定義的測驗條件作為你的測驗章程的目標，測驗章程是一種 "任務"，與傳統的測驗目標一起，為額外的測驗提供潛在的想法，如果測驗目標可以追溯到測驗基礎，你可以評估所實作的覆寫率（例如，對于你的需求），甚至當你使用基于經驗的技術，

2.3.4 測驗設計

如何測驗和使用哪些測驗用例

當設計測驗時，你要確定如何進行測驗，在設計階段，測驗條件被用來創建測驗用例（或測驗用例的序列），在這里，你通常會使用第五章中詳述的測驗技術之一，

• 抽象和具體的測驗用例

抽象的（或 "高層次的"）測驗用例不包括具體的輸入值或預期結果，并使用邏輯運算子描述，這種案例的優點是，它們可以在多個測驗周期中使用，并使用不同的資料，但仍然可以充分記錄每個案例的范圍，具體的（或 "低級"）測驗案例使用具體的輸入資料和預期結果值，
當你開始設計一個測驗時，你可以使用抽象的以及具體的測驗用例，因為只有具體的測驗用例可以在計算機上執行，抽象的測驗用例必須要有真實的輸入和輸出值來充實，為了利用抽象測驗用例的優勢（見上文），你也可以從具體用例中匯出抽象測驗用例，

• 測驗用例涉及的不僅僅是測驗資料

每個測驗用例都必須定義先決條件，測驗也需要明確的約束條件，必須遵守，此外，你需要事先確定你期望測驗產生什么結果或行為，除了輸出資料，結果包括對全域（持久）資料和狀態的任何變化，以及對測驗用例執行的任何其他反應，

• 測驗神諭（oracle）

你需要使用足夠的資源來預測測驗結果，例如，規范可以作為神諭，有兩種基本方法：

a.測驗人員根據測驗基礎中定義的測驗物件的要求和規格，從輸入值中得出預期輸出值，
b.如果逆函式存在，你可以執行逆函式并將其輸出與原始測驗案例的輸入值進行比較，例如，這種技術可以在測驗加密和解密演算法時使用，

下面的例子說明了抽象和具體測驗用例之間的區別，
案例研究： 抽象和具體的測驗用例

一家經銷商可以讓其銷售人員選擇折扣，以適用于車輛的價格，對于低于15,000美元的價格，沒有折扣，對于價格在20,000美元以下的，適合5%的折扣，如果價格低于25,000美元，可以有7%的折扣，如果價格高于25,000美元，則應采用8.5%的折扣，
通過以上文字，我們可以得出價格和折扣之間的關系如下：
價格<15,000
折扣=0%，
15.000 ≤ 價格 ≤ 20,000
折扣＝5%，
20.000 < 價格 < 25,000
折扣=7
價格≥25,000
折扣=8.5

文本本身顯然提供了解釋的可能性，換句話說，文本可能會被誤解，而從文本中得出的數學公式是明確的，
基于這些公式，我們可以定義以下測驗案例：

為了執行這些測驗，抽象的案例必須轉換為具體的案例--也就是說，我們必須應用具體的輸入值（見表2-3），這里不包括例外條件和邊界案例，

這里顯示的數值只是為了說明抽象和具體測驗案例之間的區別，我們沒有使用特定的測驗技術來設計這些測驗，所顯示的案例也不是為了詳盡地測驗折扣組件，例如，沒有一個測驗用例涵蓋錯誤的輸入（如負數的價格），你會在第5章中找到更多關于使用特定測驗技術系統地創建測驗案例的細節，

除了指定抽象和具體的測驗用例外，測驗設計還包括對你的測驗用例進行優先排序，并提供適當的測驗基礎設施：

• 優先級和可追溯性

測驗分析已經對測驗條件進行了優先排序，這些相同的優先級可以用于你的測驗用例（或測驗用例集）并進行微調，這樣，你可以在一組測驗中為個別測驗分配不同的優先級，這些測驗是為了驗證一個測驗條件，高優先級的測驗首先被執行，
同樣的原則也適用于測驗條件的可追溯性，它可以被分解為涵蓋單個測驗案例或案例集，

• 測驗基礎設施和環境

必須對所需的測驗基礎設施進行評估和實施，測驗基礎設施包括測驗所需的所有組織元素，這些包括測驗環境、測驗工具和適當配備的作業站，為了在計算機上運行測驗物件并驗證指定的測驗案例（見下文），需要一個測驗環境，這個環境包括硬體、任何必要的模擬設備和軟體工具，以及其他支持材料，為了避免測驗時的延誤，在測驗開始前，測驗基礎設施應該建立和運行（和測驗），
在測驗分析之后，測驗設計階段可以發現測驗基礎的進一步缺陷，同樣地，在分析階段定義的測驗條件可以在設計階段進行微調，

2.3.5測驗實施

• 一切準備就緒，可以開始測驗了嗎？

測驗實施的任務是所有必要活動的最后準備，以便在下一步可以執行測驗用例，測驗設計和測驗實施活動通常是結合在一起的，

• 鞏固測驗基礎設施

實施程序中的主要任務之一是創建和整合所有的測驗軟體，特別注意測驗基礎設施的細節，測驗框架必須安裝在測驗環境中，檢查環境是極其重要的，因為測驗環境的故障會導致系統故障，為了確保測驗沒有延遲或障礙，你還需要檢查所有額外的工具（如服務虛擬化、模擬器和其他基礎設施元素）是否到位和作業，

• 鞏固你的測驗案例

為了確保你的具體測驗案例可以在沒有進一步改變或修正的情況下使用，所有的測驗資料必須正確地轉移到測驗環境，抽象的測驗案例必須要有具體的測驗資料，
除了確定你的測驗用例，你還需要定義測驗程式本身--即，計劃的測驗必須被放入邏輯序列，這是根據你定義的優先級進行的（見6.2節），

• 測驗套件，測驗程式，測驗腳本

為了保持測驗周期的有效性，并保留一個邏輯結構，測驗用例被分組為測驗套件，測驗套件由多個測驗組成，根據計劃的執行順序分組，順序的規劃使一個測驗用例的后置條件成為下一測驗用例的前提條件，這簡化了測驗程式，因為它省去了每個測驗用例的專用前條件和后條件的需要，一個測驗套件還包括執行完成后所需的清理活動，
與手工測驗相比，使用腳本自動測驗程式可以節省大量的時間，
計劃執行測驗用例、測驗套件和測驗程式的最有效方法是在測驗執行計劃中定義的（見第6.3.1節），
你的測驗用例與需求和/或測驗條件的可追溯性需要被檢查，如果有必要，需要更新，在檢查可追溯性時，測驗套件和程式也必須被考慮在內，

2.3.6 測驗執行

• 完備性檢查

首先檢查你要測驗的所有組件和相應的測驗軟體是否可用是很有意義的，這包括在測驗環境中安裝測驗物件，并檢查它是否可以啟動和運行，如果這個檢查沒有發現任何障礙，就可以開始測驗，

測驗的執行應該從檢查測驗物件的主要功能開始（見5.1.6節的其他技術旁注中的 "煙霧測驗 "部分），如果這發現了故障或與預期結果的偏差，你需要在繼續測驗之前補救相應的缺陷，

• 沒有日志的測驗是沒有價值的

測驗執行程序--不管是手動的還是根據測驗執行計劃自動進行的--都必須精確和完整地記錄下來，你需要記錄每一個測驗結果（即，通過，失敗，阻塞），以便那些沒有直接參與測驗程序的人（例如，客戶）可以理解，日志還有助于驗證整個測驗策略（見6.2節）是否按計劃執行，日志應該顯示哪些部分被測驗了，什么時候，由誰來測驗，測驗的強度如何，結果如何，如果計劃中的測驗用例或測驗序列由于任何原因被遺漏，這也需要被記錄下來，

• 明確性和可重復性的重要性

除了測驗物件（或測驗專案），還有一大堆檔案和其他資訊參與測驗的執行，這些包括：測驗框架、輸入資料、日志等等，與測驗用例或測驗運行有關的資料和其他資訊必須得到管理，以便以后可以使用相同的資料和約束條件輕松地重復測驗，使用的工具的ID和/或版本號應該由配置管理來注意和記錄（見6.5節），

• 真的有失敗嗎？

如果預期結果和實際結果之間存在差異，評估測驗日志將幫助你決定這是否真的是由于失敗造成的，如果你確實發現了故障，在你開始尋找其原因之前，請確保你將其記錄下來，可能有必要指定和執行補充測驗用例，你也應該報告這個缺陷，關于測驗記錄的更多內容，請參見第6.4.1節；關于缺陷報告的更多內容，請參見第6.3.4節；關于缺陷管理的一般討論，請參見第6.4節，

• 重新測驗

一旦BUG修復，你需要檢查相應的故障是否也被解決了，并且糾正程序沒有引起新的故障，你可能需要指定新的測驗用例來驗證修改后的代碼，

你需要仔細檢查一個故障是否真的是由測驗物件引起的，對測驗人員的聲譽來說，沒有什么比報告的故障實際上是一個有缺陷的測驗用例更糟糕的了，同時，你必須注意不要對這種情況過度警惕，你不能害怕報告潛在的失敗，即使你不確定其原因，這兩種情況對專案都是不利的，

• 單獨的故障糾正是不實際的

理想情況下，你將單獨糾正故障，并重新測驗，以確保你的糾正不會無意中相互影響，然而，這種方法在現實世界中根本不實用，如果測驗是由獨立的測驗人員而不是開發人員執行的，那么單獨的修正就不可能了，向開發者報告每個錯誤，并在重新測驗之前等待這些錯誤被糾正，這不是合理的努力，通常的做法是糾正一系列的故障，然后建立一個新版本的軟體進行測驗，

除了記錄預期和實際結果之間的差異外，你還需要評估覆寫率，如果有必要，還要記錄測驗的運行時間，有專門的工具可用于這些任務（見第7章），

• 追蹤性在這里也很重要

到目前為止，雙向跟蹤是所有測驗活動的一個重要部分，我們已經看過了，在這里，你也需要檢查可追溯性，如果有必要，更新系統，使測驗基礎和測驗條件、案例、測驗運行和結果之間的關系是最新的，一旦測驗序列完成，你可以使用其內置的可追溯性來評估測驗基礎中的每一個專案是否已經被相應的測驗程序所覆寫，

• 測驗目標實作了嗎？

這樣，你可以檢查哪些需求已經通過了計劃和執行的測驗，哪些需求由于測驗失敗或測驗程序中登記的失敗而不能被驗證，你可能會發現，一些需求還沒有被驗證，因為相應的測驗還沒有被執行，這類資訊使你能夠驗證計劃的覆寫標準是否已經完成，因此測驗是否可以被視為成功完成，

有效的覆寫標準和可追溯性使你能夠記錄你的測驗結果，使它們對專案的所有利益相關者來說都是容易理解的，

其他常見的退出標準在6.3.1節中討論，

2.3.7測驗完成

• 測驗完成的正確時間

測驗完成是測驗程序中的最后一項活動，包括整理已完成的測驗活動所收集的所有資料，以評估測驗經驗，并鞏固測驗軟體及其相關材料，測驗完成的正確時刻根據你使用的開發模式而不同，它可以是：
系統上線時；測驗專案的結束（或中止）；敏捷專案迭代的完成（例如，作為回顧或審查會議的一部分）；某一特定測驗級別的測驗活動的完成；維護版本的測驗活動的完成；

在完成時間，你還需要確保所有計劃的活動已經完成，并且缺陷報告是完整的，open的或未解決的故障（即未解決的與現有需求的偏差）仍然是open的，并延續到下一個迭代或發布，在敏捷環境中，這種未解決的案例被歸類為新的產品積壓專案，以納入下一個迭代中，

對測驗結果的評估所產生的變更請求和修改需求也是類似的處理方式，

• 測驗總結報告

測驗總結報告（見第6.3.4節）匯總了你所有的測驗活動和結果，并包括對你所進行的測驗與你預定的退出標準進行的總體評價，總結報告會分發給所有利益相關者，

• 歸檔測驗件

軟體系統一般會被長期使用，在這期間會出現在測驗中沒有發現的故障，在其生命周期中，系統也會受到其用戶（或客戶）的變更要求，這兩種情況都意味著系統必須被重新編程，修改后的代碼必須被重新測驗，如果你原來使用的測驗軟體（測驗用例、日志、基礎設施、工具等）仍然可用，并且可以移交給維護部門，那么這種維護所涉及的很大一部分測驗作業是可以避免的，這意味著，在進行系統維護時，只需對現有的測驗軟體進行調整，而不是從頭開始設定，測驗軟體也可以在類似的專案中使用，并從中獲利，對于一些行業，法律要求提供測驗證明，而這只有在所有的測驗軟體被適當歸檔時才能提供，

測驗后保存測驗軟體是非常費力的，所以測驗人員經常捕捉測驗環境的影像或使用Docker免費軟體來創建容器--一個容易運輸和可重復使用的檔案，包含所有的相關資源，可以作為一個獨立的測驗環境安裝和運行，

• 從經驗中學習

你在測驗時收集的經驗可以在未來的專案中進行分析和使用，你的計劃和你實際進行的活動之間的偏差和尋找其原因一樣有趣，你應該利用你的發現來釋放你的改進潛力，并對你在未來的迭代、發布和專案中進行的活動進行修改，這些變化有助于整個測驗程序的成熟，

2.3.8 可追溯性

• 測驗基礎和測驗結果之間的可追溯性

當我們談論測驗活動時，我們經常提到可追溯性的重要性，下面的章節總結了測驗基礎和測驗結果之間的可追溯性，并詳細介紹了有效追溯的其他優點，
可追溯性對于跨越整個測驗程序的有效測驗監測和控制至關重要，它建立了測驗基礎中每個專案和各種測驗結果之間的關系，可追溯性幫助你評估你實作的覆寫程度--例如，檢查是否所有的需求都被至少一個測驗案例所覆寫，這樣的可追溯性資料有助于你控制測驗程序的整體進度，
除了檢查覆寫率之外，有效的可追溯性還支持以下幾個方面：
可追溯性有助于評估變化的影響，通過分析需求的哪些變化影響哪些測驗條件、測驗運行、測驗用例和測驗專案

• 更高的、抽象的層次

可追溯性使你能夠將你的結果提升到一個 "更高 "的抽象水平，從而使測驗程序更容易被非專業人員所理解，只考慮已執行的測驗用例并不能提供關于測驗程序有多徹底或廣泛的資訊，只有當你包括可追溯性資訊時，輸出才會對所有相關的利益相關者群體變得可理解，這也有助于實作抽象的IT管理標準，

同樣的論點也適用于測驗進度和測驗總結報告--也就是說，有效的可追溯性使它們更容易理解，測驗基礎中每個專案的狀態都應該包括在報告中，對于每個單獨的需求，可以做以下的一個陳述：
測驗通過了；測驗失敗，出現故障；計劃中的測驗還沒有執行，

可追溯性也使我們能夠使所有利益相關者理解測驗的技術方面，以公司目標為尺度，它使他們能夠評估產品質量、程式能力和專案進展，

• 基于工具的支持

為了最好地利用可追溯性的優勢，一些公司建立專門的管理系統，以自動提供可追溯性資料的方式組織測驗結果，有各種測驗管理工具可以使用，這些工具本身就實作了可追溯性，

2.3.9 背景關系對測驗程序的影響

• 測驗程序的背景

以下是影響組織內測驗程序的一些因素（也見6.2.5節）：

測驗活動的選擇和使用取決于你使用的軟體開發生命周期模型，大多數敏捷模型并不包括測驗及其相關活動的詳細指導，
根據選擇和實施的系統結構，系統可能被劃分為子系統，這影響到測驗級別（組件、集成、系統和驗收測驗--見第3.4節）和用于匯出或選擇測驗用例的相應技術（見第5章的測驗技術），
測驗型別也影響著測驗程序，測驗型別是一組測驗活動，旨在測驗組件或系統的相互關聯的質量特性，測驗型別通常集中在單一的質量特性上，例如，負載測驗（見第3.5節），
在產品或專案存在重大風險的情況下，測驗程序需要設計成通過測驗用例來解決最大數量的風險，從而使風險最小化（見6.2.4節），
軟體系統的使用環境也會對測驗程序產生影響，例如，專門用于公司內部度假計劃的軟體，與為控制客戶的工業設施而建立的定制系統相比，要接受更徹底的測驗，
公司準則和最佳實踐也會對測驗程序和規則產生影響，這里的好處是，影響程序的因素不需要為每個專案進行討論和重新定義，要求的內部和外部標準具有相同的效果，

• 操作上的限制

操作上的限制也會影響測驗程序的結構和實施，這種限制包括：
預算和其他資源（例如，專業人員），這些資源通常在測驗方面是短缺的
最后期限延長，留給測驗的時間比計劃的少

要測驗的系統的復雜性，復雜的系統是不容易測驗的! 測驗程序的設計必須反映系統的復雜性，
合同和法規要求，這些對測驗程序的范圍有直接的影響，因此對所涉及的個別活動也有影響，

2.4 人類心理學對測驗的影響

• 人性本善

每個人都會犯錯，但沒有人喜歡承認錯誤！軟體測驗的主要目的是揭示與規范和/或客戶要求的偏差，所有發現的失敗都必須傳達給開發人員，下面的章節將討論如何處理可能導致的心理問題，
軟體開發通常被看作是一種建設性的活動，而測驗產品和檢查檔案則更多地被看作是破壞性的，這種觀點常常導致參與專案的人對他們的作業有非常不同的態度，然而，這種假設是完全沒有道理的，因為根據[Myers 12, p. 13, 軟體測驗原則#10]： "測驗是一項極具創造性和智力挑戰的任務"，此外，測驗對專案的成功和最終產品的質量起著重要作用（見2.1節），

• 披露錯誤

發現的故障必須傳達給有問題的檔案或源代碼的作者，管理層也需要知道哪些（或至少有多少）缺陷是通過測驗發現的，這種溝通方式對分析師、產品所有者、設計師、開發人員和測驗人員之間的關系有好處，但也會對這些重要的溝通渠道產生負面影響，承認（或證明）錯誤不是一件容易的事情，需要有很大的敏感性，

發現故障可以被理解為對產品或其作者的批評，并且可以作為靜態或動態測驗的結果，這種情況的例子有：
討論需求檔案的評審會議；討論用戶故事的會議，并對其進行微調；在動態測驗執行期間；始終考慮到確認偏差

"確認偏差 "是一個心理學術語，描述了以證實或加強你先前的個人信念或假設的方式搜索、解釋、贊成和回憶資訊的傾向，這種傾向在軟體故障的交流中起著重要作用，軟體開發者通常認為他們的代碼是沒有錯誤的，確認性偏見使他們很難承認他們的作業可能有缺陷，其他認知上的先入為主，也會使相關人員在理解或接受軟體測驗的結果方面感到棘手，

• 認識到的缺陷是一件積極的事情

另一個徹底的人類特征是傾向于 "射殺 "帶來壞訊息的信使，測驗結果常常被看作是壞訊息，盡管事實往往相反：公認的缺陷可以被補救，測驗物件的質量可以得到改善，公開的軟體故障實際上是一件積極的事情！"！

• 需要的軟技能

為了避免（或至少減少）這種沖突的可能性，測驗人員和測驗經理需要發展良好的軟技能，只有這樣，參與的每個人都能有效地討論故障、失敗、測驗結果、測驗進展和風險，相互尊重總是能創造一個積極的作業環境，并在所有參與專案的人之間產生良好的關系，

• 積極溝通的例子

爭論或簡單的 "吵鬧 "對作業場所的合作絕非好事，為了確保作業的友好進展，提醒每個人他們的共同目標和他們所追求的高質量產品往往是有幫助的，
正如已經提到的，你永遠無法重復發現一個缺陷并糾正它是一件積極的事情，其他積極的方面有：
錯誤識別可以幫助開發人員改善他們的作業，因此也可以改善他們的結果，很多開發人員沒有意識到，測驗結果可以幫助他們磨練自己的技能，
發現并改正的錯誤最好向管理層提出，作為節省時間和金錢的手段，并作為減少產品質量差的風險的方法，
保持檔案的中立性和事實性

檔案風格在溝通中也起到了一定的作用，測驗結果和其他發現需要被中立地記錄下來，并應堅持以事實說話，如果一個檔案有缺陷，不要批評它的作者，總是寫客觀的、基于事實的缺陷報告和審查結果，
始終考慮對方的觀點，這樣可以更容易理解為什么有人也許對你寫的或說的東西有負面的反應，

一般來說，誤解和交頭接耳從來不會產生建設性的溝通，如果你發現自己處于這種情況（或預計會出現這種情況），一定要問你說的話是如何被理解的，并確認實際說的是什么，這在兩個方向都適用，
2.1.2節列出了典型的測驗目標，明確的目標也有明顯的心理作用，人們通常喜歡將自己的行為與明確定義的目標相一致，除了測驗目標外，你可以把自己定位在團隊目標、管理目標或其他利益相關者的目標上，重要的是，測驗人員要盡可能公正地追求和堅持這些目標，

2.4.1 測驗人員和開發人員如何思考

• 不同的思維方式

由于他們追求的目標非常不同，開發人員和測驗人員的思維方式通常也很不同，開發人員設計和生產產品，而測驗人員驗證和確認產品，以發現錯誤和故障，通過結合這兩種不同的思維方式來提高產品質量是可能的，
假設和首選的決策技術反映在大多數人的思考方式中，除了好奇心，測驗人員的心態通常會包括健康的職業悲觀主義水平，并結合對測驗物件的批判性看法，對細節的興趣和與每個人積極溝通的意愿是對測驗人員有用的其他特征，測驗人員通過多年的實踐經驗發展他們的軟技能，
開發者的主要興趣是設計和實作問題的解決方案，所以他不會熱衷于考慮解決方案的哪些方面有缺陷或錯誤，盡管開發人員的心態的某些方面與測驗人員相似，但上述的確認偏見總是使開發人員更難認識到他們自己作業中的錯誤（參見6.1.1節），

題外話

開發人員可以改變他的心態并測驗自己的軟體嗎？這個問題沒有簡單的答案，既開發又測驗產品的人需要對自己的作業有罕見的批判性距離，畢竟，誰會喜歡調查和確認自己的錯誤呢？一般來說，開發人員喜歡在自己的代碼中盡可能少地發現錯誤，

• 開發測驗

開發者測驗"（見第3.4.1節）的最大弱點是，每個測驗自己代碼的開發者總是以過于樂觀的態度看待自己的作業，他極有可能忽略有意義的測驗案例，或者因為他對編程比對測驗更感興趣，所以他的測驗不夠徹底，
對自己的錯誤視而不見

如果開發者誤解了任務，設計了一個有根本缺陷的程式，那么他根本不會想到合適的測驗用例，也不會發現這個缺陷，減少這種常見的 "對自己的錯誤視而不見 "的方法是結對作業，讓每個開發人員測驗對方的作業（見6.1節，模型1），
另一方面，對自己的測驗物件的內部知識可以成為一種優勢，因為你不需要花時間去了解代碼，由管理層來決定何時了解自己作業的優勢超過對自己的錯誤視而不見所造成的劣勢，這個決定是基于測驗物件的重要性和如果失敗所涉及的風險程度，
為了設計有意義的測驗用例，測驗人員必須了解測驗物件的情況，這需要時間，另一方面，測驗人員擁有開發人員必須學習的專業技能，以便有效地進行測驗--這是一個學習程序，通常沒有多余的時間，
開發人員需要測驗技能，測驗人員需要開發技能，

如果開發人員和測驗人員都能掌握一些對方的技能，這對他們之間的合作和理解是有很大幫助的，開發人員應該總是知道一些測驗的基本知識，測驗人員應該總是有一些開發經驗，

參考資料

• 本文涉及的python測驗開發庫 謝謝點贊！ https://github.com/china-testing/python_cn_resouce
• python精品書籍下載 https://github.com/china-testing/python_cn_resouce/blob/main/python_good_books.md
• 英文原版下載：Software Testing Foundations, 5th - 2021.pdf (訪問密碼: 訂閱號pythontesting 發送 密碼) https://url97.ctfile.com/f/18113597-853966551-6ed72c

2.5 總結

• 測驗術語只有松散的定義，類似的術語經常被用來表示不同的東西--這是經常發生誤解的原因，這就是為什么術語的一致使用是認證測驗員課程的一個重要部分，本書末尾的詞匯表提供了所有最重要術語的概述，
• 測驗占據了專案開發資源的很大一部分，確切地說，需要多少測驗作業取決于手頭的專案型別，
• 測驗程序--從計劃和準備步驟開始--需要盡早開始，以便在專案中產生最大的測驗效益，
• 始終遵循七個基本測驗原則，
• 認識和觀察測驗、質量保證和質量管理之間的聯系和界限是很重要的，
• 測驗程序包括測驗計劃、監測和控制、分析、設計、實施、執行和完成，這些活動可以重疊，可以按順序或平行進行，整個測驗程序必須適應手頭的專案，
• 各個測驗活動的結果之間的雙向可追溯性，確保你可以對測驗程序的結果做出有意義的陳述，并對對系統進行修改所需的努力做出合理的估計，可追溯性對于有效的測驗監測和控制也是至關重要的，
• 在一個組織內，所有影響測驗的許多因素都必須被考慮，
  人們會犯錯，但通常不愿意承認！這就是為什么心理問題在測驗中發揮著重要作用！這就是為什么心理問題在整個測驗程序中起著重要作用，
  測驗人員和開發人員的心態是非常不同的，但兩者都可以通過相互學習而受益，

標籤：其他

上一篇：流媒體協議之nginx-rtmp服務部署20230510

下一篇：返回列表