最佳軟體測驗基礎入門教程3軟體開發生命周期的測驗

軟體開發生命周期的測驗

本章簡要介紹了軟體開發專案中常用的生命周期模型，并解釋了測驗在每個模型中扮演的角色，它討論了各種測驗級別和測驗型別之間的區別，并解釋了這些在開發程序中的應用位置和方式，

大多數軟體開發專案是按照事先選擇的軟體開發生命周期模型來計劃和執行的，這種模型也被稱為軟體開發程序模型，或者更簡潔地稱為開發模型，
這樣的模型將專案劃分為獨立的部分、階段或迭代，并將由此產生的任務和活動安排在相應的邏輯順序中，此外，該模型通常描述了每項任務所分配的角色，以及專案的哪位參與者負責每項任務，在各個階段要使用的開發方法通常也會被詳細描述，
每個開發模型都有自己的測驗概念，這些概念在意義和范圍上可能有很大的不同，下面幾節將從測驗人員的角度詳細介紹流行的開發模式，

• 生命周期模型的型別

目前使用的兩種基本的開發模式是順序式和迭代式/增量式，下面的章節包括對這兩種型別的討論，

3.1 順序式開發模型

順序式開發模型將開發程序中涉及的活動以線性方式安排，這里的假設是，當開發模型的所有階段都完成后，產品及其特征集的開發就完成了，這個模型沒有考慮到各階段或產品迭代之間的重疊，以這種方式運行的專案的計劃交付日期可能在未來幾個月甚至幾年，

3.1.1 瀑布模型

每個開發階段只有在前一個階段完成后才能開始，然而，該模型可以在相鄰的階段之間產生反饋回路，要求在前一個階段進行修改，圖3-1顯示了羅伊斯的原始模型中所包含的階段：

這個模型的主要缺點是，它把測驗作為一個單一的活動捆綁在專案的最后，測驗只有在所有其他開發活動完成后才進行，因此被看作是一種 "最終檢查"，類似于檢查出廠的貨物，在這種情況下，測驗并不被看作是在整個開發程序中進行的活動，

3.1.2 V型模型

V模型是瀑布模型的延伸 [ISO/IEC 12207]），這個模型的出現對開發程序中的測驗方式產生了巨大而持久的影響，每個測驗人員和每個開發人員都應該學習V模型，了解它是如何整合測驗程序的，即使專案是基于不同的開發模式，這里說明的原則仍然可以應用，
其基本思想是，開發和測驗是具有同等價值的相應活動，在圖中，它們由 "V "的兩個分支來說明：

• 我們是否正確的建立了系統？

驗證(Verification)包括檢查測驗物件是否完全和正確地履行了它的規格，換句話說，測驗物件（即相應開發階段的輸出）被檢查是否按照其規格（相應階段的輸入）"正確 "開發，

• 我們是否建立了正確的系統？

確認(Validation)包括檢查測驗物件在其預期的環境中是否真正可用，換句話說，測驗人員檢查測驗物件是否真正解決了分配給它的問題，以及它是否適合其預期用途，
實際上，每個測驗都包括這兩個方面，盡管驗證的份額隨著每個抽象層次的增加而增加，組件測驗主要側重于驗證，而驗收測驗則主要是確認，

• V型模式的特點

• 開發和測驗活動分別進行（用左邊和右邊的分支表示），但對專案的成功同樣重要，

• 有助于直觀地了解測驗的驗證/確認方面，

• 區分了協作測驗的層次，即每個層次都是針對其相應的開發層次進行測驗，

• 盡早測驗的原則

V型模型給人的印象是測驗在開發程序的后期開始，在實施之后，這是不對的! 在模型的右側分支的測驗級別代表了測驗執行的不同階段，測驗準備（計劃、分析和設計）必須在左側分支的相應開發步驟中開始，

3.2迭代和增量開發模型

• 迭代開發

迭代開發的基本思想是，開發團隊可以利用他們從以前的開發階段獲得的經驗，以及現實世界和客戶對早期系統版本的反饋，在未來的迭代中改進該產品，這種改進可以采取故障修正或改變、擴展或增加特定功能的形式，所有這些方案的主要目標是一步一步地改進產品，以便越來越準確地滿足客戶的期望，

• 增量開發

增量開發背后的理念是按預先計劃的階段開發產品，每完成一個階段就提供一個功能更全面的產品版本（增量），增量的大小可以有很大的不同--例如，從改變一個簡單的網頁布局到增加一個具有額外功能的完整新模塊，增量開發的主要目的是盡量縮短上市時間--即發布一個簡單的產品版本（或一個功能的簡單版本），以盡快為客戶提供一個產品或功能的作業版本，然后，根據客戶的反應和愿望，不斷地提供進一步的改進，

• 迭代-增量式開發

在實踐中，這兩種方法論的邊界是模糊的，它們通常被稱為迭代-增量開發，兩者的一個決定性特征是，每個產品的發布都能使你從客戶和/或終端用戶那里獲得定期的、早期的反饋，這減少了開發一個不符合客戶期望的系統的風險，
迭代-遞增組合模型的例子有：螺旋模型、快速應用開發（RAD）、Rational統一流程（RUP）和進化開發，

• 敏捷軟體開發

所有形式的敏捷軟體開發都是迭代-遞增的開發模式，最著名的敏捷模型是： 極限編程（XP），看板，以及Scrum，近年來，Scrum已經成為其中最流行的一種，并得到了極大的普及，

• 根據迭代的節奏進行測驗

創建新的增量/版本的速度因模式不同而不同，非敏捷的迭代增量專案傾向于預見六個月到一年的發布周期，有時甚至更長，相反，敏捷模式試圖將發布周期減少到每季度、每月、甚至每周的節奏，
在這里，測驗必須適應這樣短的發布周期，例如，這意味著每個組件都需要可重復使用的測驗用例，這些測驗用例可以很容易地在每個新的增量中立即重復，如果不滿足這個條件，你就有可能減少系統的可靠性，從增量到增量，
每個增量還需要新的測驗用例，涵蓋任何額外的功能，這意味著你需要維護和執行的測驗用例的數量（在每個版本）隨著時間的推移而增加，發布周期越短，所有的測驗用例在所有分配的發布時間框架內得到滿意的執行仍然很關鍵，但變得更加困難，因此，在使你的測驗適應敏捷開發時，測驗自動化是一個重要工具，

• 持續集成和持續部署

一旦你建立了可靠的自動化測驗環境，你就可以把它用于每一個新的構建，當組件被修改時，它會被集成到之前的完整構建中，然后再進行一次新的自動化測驗運行，任何出現的故障都應該在短期內修復，這樣一來，專案總是有一個完全集成和測驗的系統在其測驗環境中運行，這種方法被稱為 "持續集成"（CI），
這種方法可以用 "持續部署"（CD）來加強： 如果測驗運行（在CI期間）是無故障的，經過測驗的系統會自動復制到生產環境中，并安裝在那里，從而以準備運行的狀態部署，

• 持續交付=持續測驗

將CI和CD結合起來的結果是叫做 "持續交付 "的程序，只有當你有基本自動化的測驗環境，使你能夠進行 "持續測驗 "時，這些技術才能成功應用，

3.3 專案和產品背景下的軟體開發

對開發和測驗的計劃和可追溯性的要求因環境不同而不同，生命周期模型對特定產品的開發是否合適，也取決于其開發和使用的背景，以下基于專案和產品的因素在決定使用哪種模式時起著作用：

• 公司的業務重點、專案目標和風險狀況，例如，如果進入市場的時間是主要要求，
• 正在開發的產品的型別，一個小的（也許是部門內部的）系統的開發程序沒有大型專案的要求那么高，我們的VSR-II案例研究專案，這樣的大型產品往往是使用多種模型開發的，
• 產品使用的市場條件和技識訓境，例如，為物聯網（IoT）使用而開發的產品系列可以由多種型別的物件（設備、服務、平臺等）組成，每一種物件都使用特定的、合適的生命周期模型來開發，由于物聯網物件被長期大量使用，如果它們的操作使用（分發、更新、退役等）被反映在生命周期模型中的特定階段或任務目錄中，那是有意義的，這使得開發這種系統的新版本特別具有挑戰性，
• 產品風險，例如，在設計和實施車輛制動系統時涉及的安全方面，
• 組織和文化方面，例如，國際團隊內部溝通產生的困難會使迭代或敏捷開發更加困難，

案例研究： VSR-II專案中的混合開發模式

VSR-II專案的目標之一是使其 "盡可能的敏捷"，所以DreamCar模塊和所有基于瀏覽器的前端組件和子系統都是在敏捷Scrum環境下開發的，然而，由于它們是安全關鍵型的，ConnectedCar組件將使用傳統的V型模式開發，
原型開發也是專案早期的一個選擇，一旦實驗階段完成，你可以在專案的其余部分改用漸進式方法，

• 定制

開發模型可以而且應該被調整和定制，以便在特定的專案中使用，這種適應程序被稱為 "定制"，

定制可以涉及結合測驗層次或某些測驗活動，并特別組織它們以適應手頭的專案，例如，當把現成的商業軟體集成到更大的系統中時，集成測驗階段的互操作性測驗（例如，當與現有的基礎設施或系統集成時）可以由客戶而不是供應商進行，驗收測驗（功能和非功能的操作和客戶驗收測驗）也是如此，更多細節見3.4和3.5節，

然后，量身定制的開發模型包括對所有專案參與者具有約束力的所需活動、時間尺度和目標的看法，任何詳細的計劃（時間表、人員配置和基礎設施分配）都可以利用并建立在定制的開發模型上，

• 好的測驗的屬性

無論你選擇哪種生命周期模型，你的定制應該支持良好和有效的測驗，你的測驗方法應該包括以下屬性：

• 測驗及其相關活動盡可能早地包括在生命周期中--例如，起草測驗用例和建立測驗環境（見上文早期測驗的原則），
• 每一個開發活動，都有相應的測驗活動計劃和執行，
• 測驗活動被專門計劃和管理，以適應它們所屬的測驗級別的目標，
• 測驗分析和測驗設計在相應的開發階段開始，
• 一旦作業產品（需求、用戶故事、設計檔案、代碼等）存在，測驗人員就會參與討論，完善它們，測驗人員應該盡早并持續地參與這個完善的程序，

3.4測驗級別

軟體系統通常是由許多子系統組成的，而這些子系統又是由多個組件組成的，通常被稱為單元或模塊，由此產生的系統結構也被稱為系統的 "軟體結構 "或 "架構"，設計能完美支持系統要求的架構是軟體開發程序中的關鍵部分，

在測驗程序中，系統必須在其結構的每個層面上進行檢查和測驗，從最基本的組件一直到完整的集成系統，與架構的某一層次有關的測驗活動被稱為測驗 "層次"，每個測驗層次都是測驗程序的一個實體，
以下各節將詳細說明各個測驗層次在不同的測驗物件、測驗目標、測驗技術和責任/角色方面的區別，

3.4.1組件測驗

• 術語

組件測驗包括系統地檢查系統結構中的最低層組件，根據用于創建這些組件的編程語言，這些組件有不同的名稱，如 "單元"、"模塊 "或（在面向物件編程的情況下）"類"，因此，相應的測驗被稱為 "模塊測驗"、"單元測驗 "或 "類測驗"，
組件和組件測驗

無論使用哪種編程語言，所產生的軟體構件是 "組件"，相應的測驗被稱為 "組件測驗"，

• 測驗基礎

組件的具體要求和組件的設計（即規格）要被參考以形成測驗基礎，為了設計白盒測驗或評估代碼覆寫率，你必須分析組件的源代碼并將其作為額外的測驗基礎，然而，為了判斷組件對測驗用例的反應是否正確，你必須參考設計或需求檔案，

• 測驗物件

如上所述，模塊、單元或類是典型的測驗物件，然而，像shell腳本、資料庫腳本、資料轉換和遷移程式、資料庫內容和組態檔也都可以成為測驗物件，

• 組件測驗驗證了組件的內部功能

組件測驗通常只測驗與系統其他部分隔離的組件，這種隔離的作用是在測驗中排除外部的影響，它還簡化了測驗用例的設計和自動化，因為它們的范圍很窄，

組件可以由多個構建塊組成，重要的一點是，組件測驗只需要檢查有關組件的內部功能，而不是與外部組件的互動，后者是集成測驗的主題，組件測驗物件通常是 "從程式員的硬碟中獲得的"，這使得這一層次的測驗與開發作業緊密相連，因此，組件測驗人員需要足夠的編程技能來正確地完成他們的作業，

案例研究： 測驗calculate_price類

根據其規格，VSR-II DreamCar模塊計算車輛價格的方法如下：
我們從清單價格（baseprice）減去經銷商折扣（discount）開始，然后再加上特別版的加價（specialprice）和任何額外的附加物的價格（extraprice），
如果增加了三個或更多不包括在特別版中的額外費用（額外費用），這些額外費用將獲得10%的折扣，對于五個或更多的額外費用，折扣增加到15%，
經銷商折扣是從清單價格中減去的，而配件折扣只適用于額外的東西，這兩種折扣不能同時使用，最后的價格是用以下C++方法計算的：

為了測驗這個計算，測驗人員通過呼叫calculate_price()方法和提供適當的測驗資料來使用相應的類介面，然后，測驗人員記錄組件對這個呼叫的反應--即讀取并記錄方法呼叫所回傳的值，
這段代碼是有錯誤的：計算≥5的折扣的代碼永遠無法到達，這個編碼錯誤可以作為例子來解釋第五章詳述的白盒分析，
要做到這一點，你需要 "測驗驅動"，測驗驅動是一個獨立的程式，它進行所需的介面呼叫，并記錄測驗物件的反應（也見第5章），
對于calculate_price()測驗物件，簡單的測驗驅動可以是這樣的：

我們例子中的測驗驅動非常簡單，例如，可以擴展到記錄測驗資料和帶有時間戳的結果，或者從外部資料表中輸入測驗資料，

• 開發者測驗

要寫測驗驅動，你需要編程技巧，你還必須研究和理解測驗物件的代碼（或者至少是它的介面的代碼），以便編程正確呼叫測驗物件的測驗驅動，換句話說，你必須掌握相關的編程語言，你需要獲得適當的編程工具，這就是為什么組件測驗通常是由組件的開發者自己進行的，這樣的測驗通常被稱為 "開發者測驗"，盡管 "組件測驗 "才是真正的意思，開發者測驗自己的代碼的缺點將在第2.4節討論，

• 測驗與除錯

組件測驗經常與除錯相混淆，然而，除錯涉及消除缺陷，而測驗涉及系統地檢查系統的故障（見2.1.2節），

使用單元測驗框架（比如pytest、unittest、junit等）大大減少了測驗驅動編程的作業量，并在整個專案中創建一致的組件測驗架構，使用標準化的測驗驅動也使團隊中不熟悉各個組件或測驗環境的其他成員更容易進行組件測驗，這些型別的測驗驅動可以通過命令列界面控制，并提供處理測驗資料的機制，以及記錄和評估測驗結果，因為所有的測驗資料和日志都是相同的結構，所以有可能在多個（或所有）被測組件中評估結果，

• 組件測驗目標

組件測驗級別的特點是不僅有測驗物件的型別和測驗環境，而且有非常具體的測驗目標，

• 測驗功能

組件測驗最重要的任務是檢查測驗物件是否完全正確地實作了其規范中定義的功能（這種測驗也被稱為 "功能測驗 "或 "功能性測驗"），在這種情況下，功能等同于測驗物件的輸入/輸出行為，為了檢查實作的完整性和正確性，該組件要接受一系列的測驗案例，每個案例都涵蓋了輸入和輸出資料的特定組合，

案例研究： 測驗VSR-II的價格計算

這種測驗輸入/輸出資料的組合在上例中的測驗案例中得到了很好的說明，每個測驗用例都輸入了特定的價格和特定數量的額外費用，然后測驗用例檢查測驗物件是否計算出正確的總價格，
例如，測驗用例#2檢查 "五個或更多額外專案的折扣"，當測驗用例#2被執行時，測驗物件輸出一個不正確的總價格，測驗用例#2產生了一個故障，表明測驗物件沒有滿足其對這個輸入資料組合的指定要求，
組件測驗揭示的典型故障是錯誤的計算或缺失（或選擇不當）的程式路徑（例如，被忽略或錯誤解釋的特殊情況），

• 穩健性測驗

軟體組件必須與多個相鄰的組件進行互動和交換資料，不能保證該組件不會被錯誤地訪問和使用（即違背其規范），在這種情況下，被錯誤處理的組件不應該簡單地停止作業并使系統崩潰，而是應該做出 "合理 "和穩健的反應，因此，測驗穩健性是組件測驗的另一個重要方面，這個程序與普通的功能測驗非常相似，但是用無效的輸入資料而不是有效的資料為被測組件服務，這樣的測驗案例也被稱為 "負面測驗"，并假設組件將產生合適的例外處理作為輸出，如果沒有內置足夠的例外處理，組件可能會產生運行時錯誤，如除以零或空指標訪問，導致系統崩潰，

案例研究： 負面測驗

對于我們之前使用的價格計算的例子，負測驗將涉及到用負的輸入值或錯誤的資料型別（例如，char而不是int）7進行測驗：

// testcase 20
price = calculate_price(-1000.00,0.00,0.00,0,0);
test_ok = test_ok && (ERR_CODE == INVALID_PRICE);

...

// testcase 30
price = calculate_price("abc",0.00,0.00,0,0);
test_ok = test_ok && (ERR_CODE == INVALID_ARGUMENT);

各種有趣的事情出現了：
因為可能的 "壞 "輸入值的數量幾乎是無限的，設計 "負面測驗 "比設計 "正面測驗 "容易得多，
為了評估由測驗物件產生的例外處理，測驗驅動必須被擴展，
測驗物件中的例外處理（在我們的例子中評估ERR_CODE）需要額外的功能，在實踐中，你經常會發現一半的源代碼（有時甚至更多）是用來處理例外的，健壯性是有代價的，
除了功能和健壯性，組件測驗還可以用來檢查組件的其他屬性，這些屬性會影響其質量，并且只能在更高的測驗級別上使用大量的額外作業來測驗（如果有的話），例如，非功能屬性 "效率 "和 "可維護性 "，

• 效率的測驗

效率屬性表明一個組件與可用的計算資源的互動是多么的經濟，這包括諸如記憶體使用、處理器使用、或執行功能或演算法所需的時間等方面，與其他大多數測驗目標不同，測驗物件的效率可以使用合適的測驗標準進行精確評估，如記憶體的千位元組或以毫秒計算的回應時間，效率測驗很少對系統中的所有組件進行測驗，它通常只限于那些在需求目錄或組件規范中定義了某些效率要求的組件，例如，如果在嵌入式系統中可用的硬體資源有限，或者對于必須保證預定的回應時間限制的實時系統，

• 測驗可維護性

可維護性包含了所有影響增強或擴展程式的容易程度（或困難程度）的屬性，這里的關鍵因素是開發人員（團隊）需要花費多少精力來掌握現有的程式和它的背景，這對于需要修改他多年前編程的系統的開發者和一個從同事那里接手代碼的人來說，同樣有效，
需要測驗的可維護性的主要方面是代碼結構、模塊化、代碼注釋、檔案的可理解性和最新性等等，

案例分析： 難以維護的代碼

示例的calculate_price()代碼包含許多可維護性問題，例如，完全沒有代碼注釋，數字常量沒有被宣告，而是硬編碼的，例如，如果需要修改這樣的常量，就不清楚在系統中是否需要修改，以及在哪里需要修改，這就迫使開發者要花大力氣去弄清楚，

像可維護性這樣的屬性當然不能用動態測驗來檢查（見第五章），相反，你需要用靜態測驗和審查會議來分析系統的規范和代碼庫（見第4.3節），然而，由于你要檢查單個組件的屬性，這種分析必須在組件測驗的范圍內進行，

• 測驗策略

如前所述，組件測驗是高度面向開發的，測驗人員通常可以訪問源代碼，支持組件測驗中面向白盒的測驗技術，在這里，測驗人員可以使用組件的內部結構、方法和變數的現有知識來設計測驗用例（見5.2節），

• 白盒測驗

在測驗執行程序中，源代碼的可用性也是一個優勢，因為你可以使用適當的除錯工具（見第7.1.4節）來觀察測驗程序中變數的行為，看看組件的功能是否正常，除錯器還可以讓你操作組件的內部狀態，所以在測驗健壯性時，你可以故意啟動例外，

案例研究： 將代碼作為測驗基礎

calculate_price()代碼包括以下值得測驗的陳述句：

滿足條件（discount > addon_discount）的額外測驗案例很容易從代碼中推匯出來，但是價格計算規范沒有包含相關的資訊，相應的功能也不是需求的一部分，代碼審查可以發現這樣的缺陷，使你能夠檢查代碼是否正確，規范是否需要改變，或者是否需要修改代碼以適應規范，

然而，在許多實際情況下，組件測驗 "只 "作為黑盒測驗進行--換句話說，測驗用例不是基于組件的內部結構，軟體系統通常由成百上千個單獨的構件組成，所以分析代碼只對選定的組件真正實用，

在集成程序中，單個組件越來越多地被組合成更大的單元，這些集成單元可能已經大到無法徹底檢查其代碼，組件測驗是在單個組件上進行還是在更大的單元（由多個組件組成）上進行，這是一個重要的決定，必須作為集成和測驗計劃程序的一部分，

• 測驗優先

"測驗優先 "是最先進的組件測驗方法（而且也越來越多地在更高的測驗級別上），這個想法是首先設計和自動化你的測驗用例，第二步是對實作組件的代碼進行編程，這種方法具有很強的迭代性：你用你已經設計好的測驗用例測驗你的代碼，然后你以小的步驟擴展和改進你的產品代碼，不斷重復，直到代碼滿足你的測驗，這個程序被稱為 "測驗優先編程"，或 "測驗驅動開發"（通常縮寫為TDD]），如果你使用基礎良好的測驗設計技術系統地得出你的測驗用例（見第5章），這種方法會產生更多的好處--例如，負面的測驗也會在你開始編程之前被起草，團隊被迫澄清這些案例的預期產品行為，

3.4.2 集成測驗

• 術語

集成測驗是繼組件測驗之后的又一個層次，集成測驗假定交給這個層次的測驗物件已經經過了組件測驗，并且任何組件內部的缺陷都已經盡可能地被糾正，

• 集成

開發人員、測驗人員和專門的集成團隊然后將這些組件組合成更大的單元，這個程序被稱為 "集成"，

• 集成測驗

一旦組裝完成，你必須測驗集成的組件是否能正確地相互作用，這個程序被稱為 "集成測驗"，其目的是為了找到集成組件之間的介面和互動的故障，

• 測驗基礎

在這個層面上，所有描述軟體結構和軟體系統設計的檔案，特別是介面規范、作業流程和順序圖，以及用例圖，都要作為測驗基礎來參考，
你可能會問自己，既然所有的組件都已經單獨測驗過了，為什么還要進行集成測驗？我們的案例研究說明了必須要解決的各種

案例研究： VSR-II DreamCar模塊的集成測驗

VSR-II DreamCar模塊是由一些基本組件組成的，

這些組件之一是CarConfig類，它負責確保車輛配置（基本型號、特別版、額外的附加物等）是允許的，并負責計算結果的價格，該類包括calculate_price（）和check_config（）方法，該類使用CarDB類從資料庫中讀取所需的車型選項和價格資料，
前端使用get_config()讀取當前的車輛配置，并將結果呈現給終端用戶，以便在圖形用戶界面上進一步調整，對當前配置的修改使用update_config()回傳到后端，然后check_config()檢查配置是否被允許，并適當地重新計算價格，
盡管組件測驗顯示CarConfig和CarDB類中沒有故障，但它們之間的互動仍然可能是錯誤的，例如，你可能會發現check_config()無法處理資料庫提供的某些額外內容，或者check_config()請求CarDB從資料庫中提取的資料，但卻以不合適的格式回傳給check_config()，

前端和后端之間的互動也可能有問題，例如，如果前端沒有正確顯示邏輯上允許的配置，用戶就會認為這是BUG，也可能是因為update_config()被不適當地呼叫--例如，前臺沒有單獨顯示每個變化，而只是將完整的重新配置作為資料集發送到update_config()，它可以處理這種資料，但可能因此而執行得太慢，

然而，隨著DreamCar模塊的集成，VSR-II專案的集成測驗才剛剛開始，構成VSR-II其他模塊的組件（見第2章，圖2-1）也必須被集成，然后模塊本身才能被集成到整個系統中： DreamCar必須與ContractBase連接，而ContractBase又與JustInTime（訂購）、NoRisk（保險）和EasyFinance（車輛融資）子系統連接，最后的集成步驟之一包括將VSR-II連接到外部的FactoryPPS生產計劃系統（見第1章，圖1-1），

• 集成測驗是關鍵

正如上面的例子所說明的，組件測驗不能保證組件之間的介面是無故障的，這就是集成測驗層面對整個測驗程序的關鍵所在，潛在的介面故障必須在那里被發現，并隔離其原因，

• 系統集成測驗

上面的例子還表明，在集成和整合測驗程序中，還必須涵蓋與外部系統環境的介面，當與外部軟體（或硬體）系統的介面被測驗時，這個程序通常被稱為 "大集成測驗 "或 "系統集成測驗"，
系統集成測驗只有在系統測驗完成后才能進行，在這種情況下，風險在于開發團隊只能測驗有關界面的 "他們的一半"，而 "另一半 "是外部開發的，因此隨時可能發生意外的變化，即使系統測驗通過了，這也不能保證外部介面總是按照預期的那樣作業，

• 不同層次的集成

這意味著有多個級別的集成測驗，涵蓋不同規模的測驗物件（內部組件或子系統之間的介面，或整個系統與外部系統之間的介面，如網路服務，或硬體與軟體之間的介面），例如，如果業務流程要以由多個系統組成的跨介面作業流的形式進行測驗，那么要隔離導致故障的介面或組件就會非常困難，

• 集成測驗物件是由多個組件組成的

集成程序將各個組件組裝起來，產生更大的單元，理想情況下，每個集成步驟之后都會有集成測驗，這樣構建的每個模塊都可以作為進一步集成到更大單元的基礎，因此，集成測驗物件可以由反復集成的單元（或子系統）組成，

• 第三方系統和買入組件

在實踐中，現在的軟體系統很少從零開始建立，而是由現有系統（例如，資料庫、網路、新硬體等）的擴展、修改或組合而成的，許多系統組件是在公開市場上購買的標準化產品（如DreamCar資料庫），組件測驗通常不包括這類現有的或標準化的物件，而集成測驗則必須涵蓋這些組件以及它們與系統其他部分的互動，

最重要的集成測驗物件是連接兩個或多個組件的介面，此外，集成測驗也可以涵蓋配置程式和檔案，根據系統的結構，對資料庫或其他基礎設施組件的訪問也可以是（系統）集成測驗程序的一部分，

• 測驗環境

集成測驗還需要測驗驅動程式為測驗物件提供資料，并收集和記錄結果，因為測驗物件是復合單元，沒有與外界的介面，而這些介面不是由它們的組件部分提供的，所以重新使用為單個組件測驗創建的測驗驅動是有意義的，
如果組件測驗階段組織得很好，你就可以獲得所有組件的通用測驗驅動，或者至少是一組按照統一架構設計的測驗驅動，如果是這樣的話，測驗人員可以調整并使用這些現有的測驗驅動來進行集成測驗，而不需要額外的努力，
糟糕的組件測驗程序也許只能提供一些合適的驅動，這些驅動有不同的操作結構，這種情況的缺點是，測驗團隊現在不得不投入大量的時間和精力在專案的后期階段創建或改進測驗環境，從而浪費了寶貴的集成測驗時間，

• 監測器

因為通過測驗驅動介面的介面呼叫和資料流量需要被測驗，集成測驗經常使用 "監視器 "作為額外的診斷工具，監視器是一個程式，它對組件之間的資料移動進行檢查，并記錄它所看到的情況，商業軟體可用于監測標準資料流量，如網路協議，而你將不得不開發定制的監視器，用于專案特定的組件介面，

• 測驗目標

集成測驗的目的顯然是為了找到介面故障，如果兩個組件的介面格式不匹配，所需的檔案丟失，或者開發者編程的組件不符合規定的劃分，那么在第一次嘗試集成時就已經出現問題了，這樣的故障通常會在早期通過失敗的編譯或構建運行被發現，
難以發現的問題是運行時在組件之間的資料交換（即通信）程序中發生的故障，檢測這種故障需要進行動態測驗，可以區分以下基本型別的通信故障：
組件傳輸沒有資料、語法錯誤的資料或錯誤編碼的資料，接收組件無法處理，從而導致例外或崩潰，根本原因是功能組件錯誤，不兼容的介面格式，或協議錯誤，
通信是正常的，但由于某個組件的功能故障或對規范的誤解，所涉及的組件對傳輸的資料有不同的解釋，
資料傳輸正確，但在錯誤的時刻（定時或超時問題）或間隔時間太短（導致吞吐量、容量或負載問題），

案例研究： VSR-II的集成錯誤

在VSR-II的集成測驗中，可能會出現上述型別的以下故障：
在DreamCar GUI中選擇的額外內容沒有移交給check_config()，從而產生不正確的價格和訂單資料，
在DreamCar模塊中，車輛的顏色是由代碼表示的（例如，442表示金屬藍），然而，生產計劃系統（FactoryPPS，見第一章，圖1-1）對一些代碼的解釋不同（這里，442表示珍珠效果的紅色），這種差異意味著，從VSR-II的角度來看，正確的訂單可能導致錯誤的產品被制造和交付，
主機系統會確認轉移的訂單，在某些情況下，檢查可交付性需要很長時間，以至于VSR-II認為存在資料傳輸錯誤并取消了連接，其結果是，客戶無法訂購他花了很多時間配置的車輛，

因為故障只發生在軟體單元之間的互動程序中，這些型別的故障都不能在組件測驗中發現，
除了功能測驗外，集成測驗也可以涉及非功能測驗，這在組件介面的非功能屬性被歸類為系統相關或有風險的情況下很有用（如性能、負載下的行為或與容量相關的行為），

• 組件測驗有必要嗎？

有沒有可能完全不進行組件測驗，而直接用集成測驗開始測驗程序？是的，這是可能的，而且不幸的是，這也是常見的做法，然而，這種方法有潛在的嚴重缺陷：

這種測驗所揭示的大多數故障都是由單個組件內部的功能故障引起的，換句話說，實際上是在不適合的環境中執行的組件測驗，使訪問單個組件變得復雜，
因為不容易接觸到每個單獨的組件，有些故障不會被激起，因此不可能發現，
如果發生了故障或崩潰，就很難或不可能定位到導致故障的組件，
不進行組件測驗，只是以故障發現率低和診斷作業增加為代價，節省了精力，將組件測驗與集成測驗結合起來要有效得多，

• 集成策略

為了最大限度地提高測驗效率，應該以什么樣的順序集成組件？測驗效率是用測驗成本（人員、工具等）和有用性（發現故障的數量和嚴重程度）之間的關系來衡量的，對于特定的測驗層次來說，測驗經理負責為手頭的專案選擇和實施最佳的測驗和集成策略，

• 組件在不同的時間準備好

單個組件的完成時間可能相隔數周或數月，專案經理和測驗經理不會想等到所有相關的組件都準備好后再進行一次集成，
處理這種情況的一個簡單的臨時策略是按照組件完成的（隨機）順序來集成，這包括檢查新到的組件是否應該與已經存在的組件或子系統集成，如果這個檢查是成功的，新的組件可以被集成并進行集成測驗，

案例研究： VSR-II專案的集成策略

VSR-II的中央ContractBase模塊的作業比原來想象的要復雜，該模塊的完成被推遲了幾個星期，為了避免浪費時間，專案經理決定開始測驗DreamCar和NoRisk模塊，
這兩個模塊沒有相互介面，但通過ContractBase交換資料，為了計算適當的保險費，NoRisk需要車輛型別和其他引數，
必須撰寫樁，作為ContractBase的臨時占位符使用，這個樁從DreamCar接收簡單的車輛配置，確定車輛的型別代碼并將其傳遞給NoRisk，樁還可以輸入其他各種與保險有關的客戶資訊，然后，NoRisk計算出保費，在視窗中顯示出來供檢查，并將其記錄為測驗結果，因此，樁暫時填補了不完整的ContractBase模塊留下的空白，

這個例子強調，盡管它可能節省時間，但過早地開始集成測驗會增加創建樁的作業量，
測驗管理必須選擇一種測驗策略，優化節省的時間和維護測驗環境所增加的作業量之間的關系，

• 影響集成的制約因素

哪種策略是最好的（即最經濟和最節省時間），取決于每個專案必須分析的約束條件：
系統結構決定了系統所包含的組件的數量和型別以及它們之間的依賴關系，
專案進度表定義了各個組件的完成時間、集成和測驗時間，
整體的測驗計劃定義了系統的哪些方面要進行徹底的測驗，以及在哪個測驗級別，

• 商定集成策略

測驗經理必須研究這些約束條件，并利用它們來制定適合當前專案的集成策略，因為各個組件的交付時間是關鍵，在專案計劃階段與專案經理協商，以確保組件的交付順序和時間能夠支持測驗，是一個好主意，

• 基本策略

測驗經理可以將以下基本的集成策略作為規劃的指導：
自上而下的集成：
測驗從呼叫其他組件的主要組件開始，但除了作業系統外，自己并不被呼叫，附屬組件被存根所取代，然后，較低系統層的組件逐漸被集成，而上面的（已經測驗過的）層則作為測驗驅動，
好處是：
因為已經測驗過的組件構成了運行時環境的大部分，你只需要基本的測驗驅動，或者根本不需要測驗驅動，
缺點是：
尚未集成的附屬組件必須由樁來代替，這可能涉及到很多額外的作業，

自下而上的集成
測驗從不呼叫任何其他組件的基本組件開始（除了作業系統的功能），較大的單元是由經過測驗的組件逐步建立的，然后再進行集成測驗，

• 好處是：
  不需要樁，
• 缺點是：
  高層組件必須使用測驗驅動進行模擬，

臨時性的集成
組件按照它們完成的（隨機）順序被集成（見上文），

• 好處是：
  節省時間，因為每個組件都盡可能早地被集成到環境中，
• 缺點是：
  需要存根和測驗驅動，

骨架集成
骨架框架（"骨干"）被創建，各個組件被陸續集成到其中，持續集成（CI）（見第3.1節）是這種策略的一個現代版本，其中骨干是由現有的組件組成的，新的測驗組件被添加到其中，

• 好處是：
  組件可以以任何順序被集成，
• 缺點是：
  一個骨干或CI環境必須被創建和維護，這可能涉及到很多額外的作業，

純粹的自上而下和自下而上的集成只能應用于有嚴格層次結構的系統，這在現實世界中是很少見的，在實踐中，大多數專案都依賴于上面詳述的策略的自定義混合，

• 避免大爆炸!

必須避免任何非遞增式的整合（也被稱為 "大爆炸"），這種方法不涉及真正的戰略，團隊只是簡單地等待，直到所有的組件都準備好了，集成意味著簡單地把它們一下子扔到一起，在最壞的情況下，上游組件的測驗也被跳過，其缺點是顯而易見的：
等待 "大爆炸 "的時間是不小心浪費的測驗時間，測驗總是涉及到時間壓力，所以不要浪費任何一個測驗日，
所有的故障都是一次性發生的，很難（或者根本不可能）讓系統完全運行，缺陷的定位和糾正是復雜和耗時的，

3.4.3 系統測驗

• 術語

一旦集成測驗完成，下一個就是系統測驗，這個層次的測驗是檢查完整的、集成的系統是否真正滿足了其指定的要求，在這里，你可能也會問自己，為什么在成功的組件和集成測驗之后，這個步驟是必要的，原因是：

• 系統測驗的原因

低級別的測驗從軟體制造商的角度檢查技術規范，相反，系統測驗是從客戶和最終用戶的角度來看待系統，系統測驗人員檢查指定的要求是否已經完全和適當地實作，
許多功能和系統屬性來自于系統組件的相互作用，因此只能在整個系統層面進行觀察和測驗，

案例研究： VSR-II系統測驗

對于銷售方的利益相關者來說，VSR-II系統最重要的任務是使訂購車輛盡可能簡單，訂購程序幾乎使用了系統的所有模塊：在DreamCar中進行配置；使用EasyFinance和NoRisk進行融資和保險；通過JustInTime傳輸訂單；在ContractBase中保存文書，只有當所有這些組件都能正常作業時，系統才能真正實作其預期的目的，而系統測驗可以驗證是否如此，

• 測驗基礎

測驗基礎包括在系統層面上描述測驗物件的所有檔案和其他資訊，這些可以是系統和軟體的要求，規格，風險分析（如果有的話），用戶手冊，等等，

• 測驗物件和測驗環境

一旦集成測驗完成，你將面對一個完整的、可以運行的系統，系統測驗在盡可能類似于系統生產環境的環境中檢查完成的系統，所有的硬體、軟體、驅動程式、網路、第三方系統和其他將成為其作業環境一部分的組件都需要安裝在系統測驗環境中，而不是存根和測驗驅動程式，

除了檢查用戶、培訓和系統檔案外，系統測驗還檢查配置設定，并應通過提供負載/性能測驗結果來支持系統優化（見3.5.2節），

• 系統測驗需要自己的測驗環境

為了節省時間和金錢，系統測驗通常在生產環境本身進行，而不是在單獨的系統測驗環境中進行，這是個壞主意，有各種原因：
系統測驗肯定會暴露出故障！這些故障可能會產生高度的負面影響！這些故障會對客戶的生產環境產生非常不利的影響，客戶現場的崩潰和資料丟失可能是昂貴的，應該不惜一切代價避免，
測驗人員對影響客戶生產環境的配置和引數的控制有限，如果你在客戶系統的其他部分運行時進行測驗，這會巧妙地改變你的結果，使你進行的測驗極難重現（見3.6.3節），

• 系統測驗作業經常被低估

由于它需要復雜的測驗環境，系統測驗所涉及的作業常常被低估，經驗表明，通常在系統測驗開始時，只有一半所需的測驗和質量保證作業已經完成，

• 測驗目標

如前所述，系統測驗的目標是驗證完成的系統是否滿足指定的（功能和非功能）要求以及滿足的程度（見3.5.1和3.5.2節），系統測驗可以識別由于錯誤的、不完整的或不一致的實作需求而造成的缺陷和不足，它還應該識別未記錄的或被遺忘的需求，

• 資料質量

在依賴資料庫或其他大量資料的系統中，資料質量是重要因素，可能需要作為系統測驗程序的一部分來考慮，資料本身成為 "測驗物件"，它們需要適當地檢查一致性、完整性和最新性，

題外話：系統測驗問題

在太多的專案中，對需求的澄清和記錄要么是零散的，要么是完全忽視的，這使得測驗人員很難知道系統實際上是如何作業的，并且加倍難以可靠地揭示故障，

模糊的需求

在沒有需求的地方，任何系統行為都是被允許的，或者系統行為根本無法被評估，用戶（或內部/外部客戶）當然會對 "他的 "系統的期望有想法，需求確實存在，但只是在參與專案的一些人的頭腦中，然后，測驗人員被賦予了一項艱巨的任務，即整理關于系統計劃行為的所有相關資訊，處理這種情況的方法之一是使用探索性測驗（見5.3節），

錯過的決定

在收集這些資訊的程序中，測驗人員會發現各個參與者對需要建立的東西有著非常不同的想法和態度，為了避免這種情況，專案需求需要被寫下來，然后由所有相關的參與者同意并批準，
換句話說，除了收集需求，系統測驗還必須強制執行澄清和決策程序，這些程序本應在很久以前就完成，而現在卻做得太晚，這種資訊收集需要時間，而且成本極高，保證會延遲產品的交付，

一些專案失敗

如果需求沒有被記錄下來，開發人員就不會有明確的目標，所產生的系統滿足客戶隱含需求的概率確實很低，在這種情況下，沒有人期望會產生一個可用的產品，系統測驗往往只能 "證明 "專案的失敗，

減少早期反饋的風險

迭代和敏捷專案也需要清楚地制定和書寫需求，同樣，總有一些需求是不完整的，不正確的溝通，或者干脆被忽略的風險，然而，在這種情況下，每個迭代都提供了檢查給定需求滿足情況的機會，從而減少專案失敗的風險，
如果需求沒有得到充分的滿足，你可以利用下一次迭代來改善事情，你最終可能需要比原來計劃的更多的迭代來確保達到特定的功能水平，這樣一來，就相當于一個產品遲遲不能交付，但可以使用，而不是一個完全失敗的專案，

3.4.4驗收測驗

到目前為止，我們所看到的測驗型別都是由軟體制造商和/或開發團隊在軟體交付給客戶之前進行的，
在系統啟動之前（特別是在定制軟體的情況下），它要經過額外的 "驗收測驗"，這種測驗是從客戶/終端用戶的角度進行的，是客戶直接參與或實際負責的唯一測驗，
驗收測驗的典型變體是：
用戶驗收測驗
系統操作者的驗收
合同和法規驗收測驗
現場測驗（即α和β測驗）
驗收測驗也可以在較低的層次上進行，通常分布在多個測驗層次上：
現成的軟體可以在集成或安裝時進行驗收測驗
組件的用戶友好性可以作為組件測驗程序的一部分進行驗收測驗
新功能的驗收可以在系統測驗前使用原型來檢查，

• 驗收測驗需要多全面？

驗收測驗的范圍是基于風險的，并且是高度可變的，在定制軟體的情況下，風險水平很高，因此全面的驗收測驗是必不可少的，在光譜的另一端，如果你正在安裝現成的軟體，只需安裝軟體包并測驗幾個典型的使用場景就足夠了，但是，如果軟體包訪問了其他系統的介面，那么這些獨立系統之間的互動也必須進行測驗，

• 測驗基礎

測驗基礎包括所有從用戶角度描述測驗物件的檔案--例如，用戶和系統要求，用例，業務流程，風險分析，使用系統的流程描述，表格，加上報告和系統維護和管理流程的描述，如果測驗是基于法律或其他正式法規，通常被稱為法規驗收測驗，

• 合同性驗收測驗

在定制軟體的情況下，客戶將（與制造商合作）進行合同性驗收測驗，根據測驗結果和開發合同規定的準則是否得到滿足，客戶將決定是否接受交付的產品，該合同也可以是兩個公司內部部門之間的（不太正式的）協議，作為聯合專案開發產品，

• 驗收測驗標準

開發合同中詳細說明的驗收標準將作為測驗標準，所以這些標準必須被清楚明確地定義，如果相關的話，任何法律規定、監管標準或安全條例都是驗收標準的一部分，
在實踐中，軟體制造商通常應該在內部系統測驗中使用適當的測驗案例檢查這些驗收標準，然后，驗收測驗可以通過重復這些系統測驗的子集來完成，向客戶證明合同要求已經得到滿足，
我們的提示

因為制造商有可能誤解合同約定的驗收標準，所以客戶必須設計自己的驗收測驗案例（或者至少對起草的案例進行嚴格的審查），

• 客戶現場的驗收測驗

與在軟體制造商的測驗環境中進行的系統測驗不同，驗收測驗是在客戶自己的驗收測驗環境中進行，這兩種環境之間的差異可能導致無故障的系統測驗案例在驗收測驗中失敗，安裝和配置程式是驗收測驗的一部分，通常被稱為運行驗收測驗，驗收測驗的環境必須盡可能地與系統要使用的生產環境相似，然而，要避免在生產環境中進行驗收測驗，因為這有可能會破壞關鍵的生產程序，
你可以使用你用于系統測驗的相同方法來得出合適的驗收測驗和測驗標準，如果你正在測驗管理性的IT系統，你還需要測驗在一個典型的時間段和/或計費期發生的業務案例（例如，每月的計費周期），

• 用戶驗收測驗

驗收測驗的另一種是用戶驗收，如果客戶實際上不是最終用戶，這種測驗就特別重要，

案例研究： 不同的用戶群和使用情況

在VSR-II的案例中，客戶是汽車制造商，但最終用戶是經銷商的作業人員和客戶，他們在經銷商處或網上使用DreamCar模塊來配置車輛，公司總部的作業人員也使用該系統--例如，更新價格表，

• 考慮到所有的用戶群

不同的用戶群一般會對新系統有不同的期望，如果用戶群拒絕該系統--例如，因為他們認為該系統 "不方便"，這可能意味著整個實施被拒絕，即使該系統按照其功能規格運行，因此，針對每個用戶群進行驗收測驗是很重要的，這樣的測驗通常是由客戶組織的，客戶可以根據既定的業務流程和用戶場景來選擇最合適的測驗案例，
我們的提示 盡早向終端用戶展示樣機

如果在驗收測驗階段出現了嚴重的問題，那么除了系統的表面現象外，通常已經來不及改變什么了，為了避免這種災難，在開發程序中盡早讓選定的最終用戶評估產品原型是一個好主意，

• 系統操作員的驗收測驗

系統運營商的驗收測驗確保系統管理員對系統在現有IT環境中的整合方式感到滿意，這些測驗包括備份和恢復程式、系統關閉后的重新啟動、用戶管理、以及資料處理和安全的各個方面，

• 現場測驗

如果一個產品注定要在多個不同的生產環境中運行，對于制造商來說，建立系統測驗環境來反映每個終端用戶的情況是非常昂貴和不現實的，在這種情況下，制造商將在系統測驗之后進行現場測驗，旨在識別（如果可能的話，糾正）來自未知或部分未知環境的影響系統的因素，現場測驗對于開發商業的、現成的軟體產品的制造商特別有用，

• "典型客戶 "測驗

在這種情況下，制造商將穩定的、預先發布的軟體交付給代表市場或產品典型目標環境的選定客戶，
這些客戶然后執行制造商規定的測驗，或者只是在真實世界的條件下測驗軟體，然后，他們以評論和缺陷報告的形式向制造商提供反饋，制造商可以利用這些反饋對產品進行適當的調整，

• α和β測驗

這種測驗被稱為 "α "或 "β "測驗，阿爾法測驗是在開發者的測驗環境中由角色在開發組織之外的人進行的，而貝塔測驗是在客戶現場進行的，

現場測驗不能取代制造商的內部系統測驗（盡管有些制造商認為它應該），只有在系統測驗證明軟體足夠穩定的情況下，你才應該發布軟體進行現場測驗，

• 敏捷專案中的驗收測驗

上面提到的所有驗收測驗的變體都與迭代和/或敏捷開發程序有關，
迭代和敏捷開發的指導原則之一是盡快收集客戶的反饋，這正是驗收測驗的內容，因此，你應該在每個迭代中包括一些驗收測驗，也許是通過用戶調查，在產品演示中，或者與你的客戶/用戶一起進行實踐測驗，因此，驗收測驗的內容和重點可能會在各個迭代中發生變化，與其說是對最終產品版本的結論性接受，不如說是用反饋來指導下一個版本中可以或必須改進的地方，
你進行的驗收測驗的型別和范圍也取決于你正在進行的迭代的 "型別"，你需要區分產生內部版本的迭代和產生外部生產性使用的版本，例如，測驗團隊不需要為一個純粹的內部版本進行合同驗收測驗，

參考資料

• 本文涉及的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

3.5測驗型別

前面幾節詳細介紹了軟體開發程序中需要涵蓋的測驗層次，這些測驗的重點和目標因級別不同而不同，所以不同型別的測驗必須以不同的徹底程度進行，我們對以下基本型別進行區分：

• 功能性和非功能性測驗
• 基于需求和結構的測驗

3.5.1功能測驗

功能測驗包括所有的測驗技術和方法，用于測驗測驗物件的可觀察的輸入/輸出行為，功能測驗案例是使用5.1節中描述的 "黑箱 "技術建立的，功能要求是計劃系統行為的測驗基礎，

功能要求和功能適用性

功能需求13規定了系統或系統組件的預期行為--換句話說，它們描述了系統（或組件）被設計來完成的 "內容"，而實作它們是一個正常運行的系統的基本前提條件，一個組件是否以及如何滿足其功能要求被稱為其 "功能適用性"，這是ISO 25010標準[ISO 25010]中定義的質量特性之一（見第2.2節），
下面的例子列出了VSR-II系統中價格計算的一些功能要求（也見3.4.1節）：
案例研究： VSR-II DreamCar模塊的功能要求

R 100:
用戶可以從當前目錄中選擇一個車型進行配置
R 101:
將顯示所選模型的可交付的額外內容，客戶可以選擇其中任何一項添加到配置中，
R 102:
當前配置的價格（型號加額外費用）將根據當前的價格表計算并實時顯示，
R 103:
對于當前選定的車輛，將只顯示屬于可交付配置的額外費用，當前配置的不可交付的額外費用將被灰色顯示，
功能測驗案例

檢查功能屬性的測驗需要對每個功能需求至少有一個測驗用例，驗證R102 "計算總價"（見上文）的合適測驗可能是這樣的：
案例研究： 基于需求的功能測驗用例

T 102.1:
選擇一個汽車型號；顯示根據銷售手冊的價格
T 102.2:
選擇了額外的東西；車輛的價格被這個額外的東西的價格所增加
T 102.3:
取消選擇某項額外費用；車輛價格按該額外費用的價格降低
T 102.4:
選擇了三個額外的專案；這些專案根據規格進行折扣，

通常情況下，需要一個以上的測驗用例來測驗一個功能需求，在我們的例子中，需求102包括一系列的價格計算變體，需要由適當的測驗用例（102.1-102.4）來覆寫，這些案例可以使用其他黑盒技術進行微調和增加，如等價分割（見5.1.1節），
重要的是，一旦預定義的測驗用例（或測驗規范中定義的子集）被運行而沒有發現任何故障，功能就被認為是正確實作的，
功能測驗發生在每一個測驗層面，對于組件和集成測驗，測驗基礎包括組件的技術規范，每個組件的介面（API）的規范，或白盒資訊（見3.5.3節），對于系統和驗收測驗，測驗基礎是由功能系統要求組成的（如上面的例子所示），

• 基于Use-case和業務流程的測驗

如果一個軟體系統被設計成自動化或支持特定的業務流程（如上面的例子），用例或基于業務流程的測驗技術也是合適的（見5.1.6節），
案例研究： 測驗一個業務流程

VSR-II在銷售程序中為經銷商提供支持，可能發生的情況如下：
客戶選擇感興趣的可用型號
客戶查看設備和價格選項，并相應配置車輛
銷售人員建議各種融資方案
客戶做出決定并下訂單

• 業務流程分析

業務流程分析通常是作為需求分析的一部分進行的，它顯示了哪些業務流程是相關的，它們發生的頻率如何，在什么情況下發生，哪些人、公司和外部系統參與其中，等等，這些資訊形成了測驗基礎，然后用來創建模擬典型業務事件的測驗場景，這些測驗場景根據這些事件的典型頻率和相關性進行優先排序，同時也根據相應流程的風險系數進行排序，
基于需求的測驗集中在單個系統功能上（例如，傳輸訂單），而基于業務流程的測驗則使用測驗序列來檢查連續的程式（例如，由車輛配置、同意購買和傳輸訂單組成的銷售），
除了我們的樣品VSR-II系統的基本選擇、配置、購買功能外，用戶接受度也是基于系統的用戶友好程度，用戶友好性（或可用性）的評判標準是：系統使用起來有多容易，它 "回答 "的速度有多快，以及它所提供的輸出有多清晰，換句話說，除了功能標準之外，我們還必須測驗和驗證系統的非功能屬性，

3.5.2非功能測驗

非功能需求描述了系統的功能行為的屬性--即一個系統或組件應該如何 "好 "地完成它的功能，它的實作強烈影響著客戶/用戶的滿意度，因此也影響著系統的受歡迎程度，根據[ISO 25010]，這種特性包括用戶滿意度和效率（見2.2節），從制造商的角度來看，靈活性和可移植性是產品可維護性的重要方面，因為這些有助于降低維護成本，
以下的非功能系統特性應該被涵蓋，并通過相應的測驗來檢查（通常在系統測驗程序中）：

• 負載
  測量系統在不斷增加的負載下的行為（例如，平行用戶的數量，交易的數量），
• 性能
  測量特定用例的處理速度和回應時間，通常與不斷增加的負載相結合
• 資料量
  觀察取決于資料量的系統行為（例如，在處理非常大的檔案時），
• 壓力
  觀察過載情況下的系統行為
• (資料)安全
  對抗未經授權的系統和/或資料訪問
• 穩定性/可靠性
  在持續使用的情況下（例如，通過測量特定用戶組態檔中每小時的系統故障數量），
• 穩健性

當受到用戶錯誤、編程錯誤、硬體故障和類似情況時，測驗例外處理和重啟/恢復行為，

• 兼容性/資料轉換
  測驗與現有系統的兼容性，特別是在資料匯入/匯出時
• 不同的配置
  例如，使用不同的作業系統版本、語言或硬體平臺
• 可用性
  測驗易學性和易用性，包括不同用戶群的輸出的可理解性（另見驗收測驗，3.4.4節），
• 系統檔案與系統行為的一致性
  例如，用戶手冊與GUI，或配置描述與實際行為，
• 可維護性
  開發檔案的可理解性和最新性，模塊化結構等

，
非功能需求往往是不完整的或含糊的措辭，諸如以下的屬性： "系統需要易于使用 "或 "快速回應"，以其目前的形式是無法測驗的，

測驗人員應該參與需求檔案的審查，并確保所有列出的（非）功能需求的措辭是可衡量的，因此是可測驗的，
此外，許多非功能需求表面上是如此明顯，以至于沒有人想到要提及或指定它們，這種 "假定需求 "15 往往是高度相關的，系統必須擁有相應的隱含屬性，

案例研究： 假設的需求與指定的需求

原始的VSR系統被設計為運行在一個著名的市場領導者提供的作業系統上，其外觀和感覺與作業系統的風格和慣例基本一致，
VSR-II中新的、現代的用戶界面是基于瀏覽器的，市場部與一家網頁設計公司合作，創建了全面的風格指南，規定了VSR-II的界面在整個系統中的外觀，
可用性測驗使用檢查表（見5.3節，基于檢查表的測驗），以確保每個模塊的用戶界面符合風格指南中規定的規格，這些測驗顯示，一些規定的顯示和界面元素在移動設備上難以閱讀，雖然沒有制定明確的 "易讀 "要求，但決定修改風格指南的相應部分，使界面的所有元素都能滿足良好的可讀性這一假設要求，

題外話：用功能測驗來測驗非功能屬性

使用現有的功能測驗來驗證非功能屬性往往是權宜之計，非功能測驗通常是黑盒測驗，可以被看作是一種綁在功能測驗上的 "背包"，這類測驗的一個優雅的一般方法是如下：
從功能測驗中選擇的場景代表了整個系統所提供的功能的橫截面，非功能維度必須在相應的測驗場景中可見，并在測驗運行中被測量，如果測量值低于預定的閾值，測驗就被歸類為通過，實際上，功能測驗方案是確定你要測驗的非功能系統特性的測量程式，

3.5.3基于需求的測驗和基于結構的測驗

基于需求的測驗是一種黑箱技術，其中測驗用例的設計是基于需求的，它也被稱為基于規格的測驗，因為它使用軟體的外部可觀察行為的規格作為其測驗基礎，這種規范可以采取各種形式--例如，用例或用戶故事，相應的測驗技術將在第5.1節中描述，這些規范和由此產生的測驗用例可以與相關軟體元素的功能或非功能特性有關，

基于需求的測驗大多發生在系統和驗收測驗期間，如果組件或集成測驗來自技術規范或需求，這些也可以歸類為基于需求的測驗，

基于結構的測驗（結構測驗，白盒技術）使用軟體的內部結構/架構作為其測驗基礎，它分析諸如組件內的控制流或程式或選單結構的呼叫層次等內容，軟體的抽象模型中的結構也可以作為一個起點，目標是在測驗程序中盡可能多地覆寫觀察到的結構元素，這需要設計足夠多的測驗用例，這些測驗用例也可以基于你所調查的軟體元素的功能或非功能屬性，
結構測驗主要是在組件和集成測驗中進行，有時也作為更高的測驗級別的附加測驗（例如，為選單結構提供覆寫），這些技術將在以下文章中詳細討論，

3.6測驗新的產品版本

到目前為止，我們只是簡單地假設，當軟體開發專案通過驗收測驗并交付產品后就結束了，然而，現實中的情況卻截然不同，最初的交付只標志著軟體產品生命周期的開始，許多軟體產品會被使用數年甚至數十年，并且在其生命周期內通常會被多次修改、擴展或維修，請看我們下面的案例研究部分，了解一個例子：
案例研究： 評估VSR-II的熱線票據

VSR-II已經取代了原來的VSR系統，并且已經運行了一段時間，為了找到新系統的潛在弱點，終端用戶支持團隊分析了系統上線后頭幾個月收到的查詢，這里有一些例子：
有幾個經銷商一直在一個未經批準的平臺上運行系統，使用的是傳統的作業系統，系統的瀏覽器無法顯示用戶界面的某些元素，系統在訪問主機系統時有時會崩潰，
一些客戶說，他們發現在舊的VSR系統中選擇額外的東西很復雜，特別是在比較各種設備包的價格時，因此，VSR-II使客戶能夠保存各種配置，并在做出改變后呼叫這些配置，然而，有些客戶希望得到更多的便利，希望能夠比較不同的車輛型號加設備包，
因為在對保險模塊編程時忽略了相應的計算規則，一些很少要求的保險費率無法計算，類似的問題在VSR中已經知道了，
在極少數情況下，訂單確認在等待15分鐘后仍未到達工廠電腦，然而，為了避免浪費網路容量，VSR-II最遲會在15分鐘后切斷連接，這意味著經銷商必須重復訂單，并在以后單獨向客戶發送確認，由于對訂單確認的不必要的等待，這引起了客戶的不滿，
問題#1基本上是經銷商的問題，然而，制造商可以修改系統，以防止經銷商不得不進行昂貴的硬體更新，
問題2總是會出現，不管原來的系統要求有多全面，新的系統帶來了新的用戶體驗，而由此產生的客戶偏好只有在系統運行一段時間后才會顯現出來，
問題3可能是在系統測驗中發現的，盡管測驗是一種抽查，并不能保證沒有缺陷，而只是有一定的概率發現現有故障，好的測驗經理會檢查哪些測驗是必要的，以發現這個疏忽，并相應地修改測驗計劃，
問題#4被發現，并使用一個補丁進行了補救，VSR-II不再丟失訂單資料，而是自動多次重復訂單程序，然而，這仍然不能防止客戶在訂單確認需要一段時間時的等待，真正的解決方案將涉及修改公司主機上的批處理系統--這個解決方案超出了VSR-II的職權范圍，因此在短期內無法補救，

這四個例子代表了隨著時間推移而出現的典型問題，即使是在最成熟的系統中：
系統在新的、不可預見的、非計劃的條件下被使用
客戶提出了新的、未預見到的要求
需要有涵蓋罕見（因此被忽視）的特殊情況的功能
問題不斷發展，只是零星出現，或在系統運行較長時間后出現，這類問題往往是由外部因素引起的，

3.6.1 軟體維護測驗

每個軟體系統在其生命周期內都需要進行修改和調整，這個程序通常被稱為 "軟體維護"，
軟體是不會磨損的，與硬體的維護不同，也與物理工業產品不同，軟體維護的目的不是為了保持運行能力或修復使用程序中造成的損壞，軟體維護的目的是：

• 糾正產品中無意中出現的故障

• 改善產品的質量特性

• 使產品適應變化了的操作條件（例如，當一個新的作業系統、一個新的資料庫或一個新的通信協議被實施時）
  相應的測驗程序被稱為維護測驗，
  軟體產品的變化可以由錯誤修復引發，也可以由作為 "正常 "維護和持續發展的一部分的有計劃的功能修改/擴展引發，

• 測驗新版本

在這兩種情況下，結果都是一個新的產品版本，新版本與早期版本基本相同，但對現有功能進行了一些修改，也有一些全新的功能，

測驗程序是如何對這些變化做出反應的？每個測驗層的所有測驗都必須在每個版本中重復進行嗎？還是只測驗那些直接受變化影響的元素就足夠了？下面的章節將討論這些問題，

• 維護測驗

在軟體維護的情況下（見上文），基本的測驗策略（也稱為確認測驗）包括重復所有在上一版本中發現故障的測驗案例，這些測驗用例必須通過，以便將相應的故障歸類為已糾正，
如果以前的測驗用例沒有發現的故障已經被修復（例如，因為來自于熱線單），你需要起草新的測驗用例來驗證新發現的故障是否真的已經被糾正，
糾正以前未發現的故障往往會改變附近程式元素的（正確）行為，這可能是故意的，也可能是意外的，這就需要額外的測驗用例，這些測驗用例要么是修改過的，要么是新的，以驗證這些改變是否達到預期效果，你還需要重復現有的測驗用例，驗證被修改的元素的 "其余部分 "保持不變，仍然正常運行，

• 熱修復Hotfix

有些軟體故障會對系統的完整性造成直接威脅，因此需要及時關注，在這種情況下，緊急的 "熱修復 "比深思熟慮的長期解決方案更方便，專注于最重要的確認測驗有助于快速提供熱修復，但你還是需要盡快進行全面測驗（如上所述），
如果專案經理提前計劃好維護性發布，并將其納入整個測驗計劃，那么維護性測驗總是更簡單、更成功，在處理遺留系統時，你往往只能獲得過時的規范（或者根本沒有規范），這使得維護和維護測驗更加困難，適當的計劃使這方面的測驗更容易，
不能把維護作為跳過測驗的借口，如果你因為 "反正未來的版本會糾正缺陷 "而跳過測驗，你還沒有正確理解軟體缺陷可能導致的成本和風險，

• 影響分析

確認測驗本身，或在修改附近的新測驗其實是不夠的，表面上簡單的區域修改可能會在系統的其他部分（通常是遙遠的）造成意想不到的、有時是災難性的后果和副作用，有多少測驗用例和哪些型別的測驗用例是必要的，以減少這種風險，必須通過對你所做的修改的潛在影響的高度具體的 "影響分析 "來確定，

• 修改后的維護測驗

當軟體被修改以適應改變的操作條件時，你需要運行測驗以確保系統操作者接受修改后的系統，這是因為非功能系統屬性的各個方面（如性能、資源要求或安裝前提條件）在客戶的環境中可能（在修改后）表現得不同，
如果修改涉及到資料轉換或遷移，你還需要測驗資料的完整性和真實性，除了這些因素外，測驗修改后的系統的總體策略與測驗維護后的系統是一樣的（見上文），

3.6.2 在發布版本后進行測驗

除了故障修正所需的維護外，專案管理部門還將計劃對系統進行擴展和其他改變，以保持其競爭力并擴大客戶群，大多數系統都要進行持續開發--例如，建立產品的改進版本，這樣的版本通常與預定的維護作業相協調，例如，這些可能是每季度的維護版本和每年的 "真正 "功能更新，

案例研究： VSR-II發展規劃

VSR-II第二版的開發計劃包括以下變化：
ConnectedCar通信軟體要進行擴展，以確保與最新車型系列中內置的新一代物聯網傳感器兼容，
第1版中沒有及時準備好的各種功能擴展將在第2版中交付，
安裝基礎將被擴展到包括該公司在世界各地的經銷商，這需要對更多的國家進行本地化作業，包括系統選單和手冊的翻譯，
變更#1是由外部資源和系統的計劃變更導致的，變更#2是從一開始就計劃好的功能，但由于時間限制還沒有實施，變更#3是一套擴展功能的一部分，是預先計劃的市場擴張所需要的，

這些變化都不是因為故障糾正或不可預見的客戶要求，而是VSR-II正常的迭代/增量產品開發程序的一部分，
這樣的版本開發后的測驗遵循兩個主要目標：
檢查每一個新的或擴展的功能是否按預期運行
檢查先前存在的功能是否（無意中）受到損害，
為了實作目標1，你需要開發和執行新的測驗案例，目標#2需要適當的回歸測驗（見下面3.6.3節），
退役前的測驗

當系統要永久退役時，會出現一個有趣的情況，在這里，你需要在退役前檢查系統資料是否可以或必須被歸檔或轉移到后續系統，

3.6.3 回歸測驗

對程式進行修改后重復測驗的程序被稱為 "回歸測驗"，
回歸測驗利用現有的測驗用例來檢查所做的修改是否產生了新的故障，是否有無意的副作用，換句話說，其目的是確保修改后的系統中未被改變的部分仍然像修改前那樣作業，
最簡單的方法是在新版本的程式上執行現有的測驗，

• 回歸測驗和測驗自動化

為了使現有的測驗案例對回歸測驗有用，它們必須是可重復的，這意味著手動測驗用例必須有足夠的檔案，用于回歸測驗的測驗用例將被定期和經常使用，因此注定要進行測驗自動化，回歸測驗案例的自動化是非常有用的（見第7.2節），因為它確保了精確的可重復性，同時降低了每個測驗重復的成本，

• 回歸測驗的范圍

哪些現有的測驗應該被用來確保成功的回歸測驗？
因為我們要檢查現有的功能是否被（無意中）破壞了，我們基本上需要重新運行所有涵蓋這個預先存在的功能的測驗，
如果很少（或沒有）自動化測驗，因此你必須手動執行回歸測驗，你將不得不選擇手動測驗中最小的子集，為了選擇合適的測驗用例，你必須仔細分析測驗規范，看看哪些測驗用例與哪些原有的功能有關，哪些與新的、修改的功能有關，
如果你有自動化測驗用例，最簡單的策略是簡單地對新產品版本重新執行所有的測驗用例：
回傳 "通過 "結果的測驗用例表明組件/功能沒有改變，這可能是因為沒有進行所需的改變，或者是因為 "舊 "的測驗用例沒有足夠精確地制定，以涵蓋修改后的功能，在這兩種情況下，相應的測驗用例需要被修改，以確保它們對新功能的反應，
回傳 "失敗 "結果的測驗用例表示修改的功能：
如果這包括那些沒有被標記為改變的功能，那么失敗是有理由的，因為它表明--與計劃相反--相應的功能已經被改變，因為這種無意的修改被 "舊 "測驗用例所揭示，所以不需要進一步修改，
對于需要改變的功能，測驗用例也需要調整，使其涵蓋新的功能，
所有這些的結果是一套回歸測驗，驗證計劃中的功能改變，涵蓋全新功能的測驗用例還不是這個套件的一部分，必須單獨開發，

• 完全回歸測驗與部分回歸測驗

在實踐中，運行所有現有測驗的完整回歸測驗通常成本太高，花費時間太多，特別是當（如上所述）涉及手動測驗時，
因此，我們正在尋找一些標準，以幫助我們決定哪些遺留的測驗用例可以被忽略而不損失太多資訊，在測驗環境下，這需要在最小化成本和接受商業風險之間做出妥協，以下是選擇測驗用例的常見策略：
只重復在測驗計劃中被賦予高優先級的測驗，
撇開功能測驗的特殊情況，
將測驗限制在某些特定的配置上（例如，只測驗英語版本，只測驗特定的作業系統，以及類似的），
將測驗限制在特定的組件或測驗級別，
這里列出的規則主要適用于系統測驗，在較低的測驗級別，回歸測驗的標準可以基于設計檔案（如類的層次結構）或白盒資訊，

3.7總結

• 軟體開發生命周期模型以章節、階段或迭代的方式構造軟體開發程序，兩種基本的模型型別是 "順序的 "和 "迭代/遞增的"，

• 順序開發模式的特點是開發活動以線性（即順序）方式進行，

• 迭代/增量模式產生定期的擴展和/或改進的產品發布，使客戶和系統的用戶能夠及時反饋，這種方法縮短了產品上市的時間，也降低了開發出的產品不能滿足客戶期望的風險，所有的敏捷開發方法都被歸類為迭代/遞增式的，

• V模型是一個重要的順序開發模型，它定義了組件、集成、系統和驗收測驗級別，它區分了驗證和確認，并提供了良好的測驗實踐原則，可以應用于任何開發模式：

• 越早發現缺陷，糾正它的成本就越低，因此，V型模型要求在每個開發階段結束時進行驗證程式（如審查），這有助于防止后續缺陷的擴散，

• 組件測驗檢查單一的軟體組件，集成測驗檢查這些組件的協作情況，功能和非功能的系統測驗從用戶的角度檢查整個系統，在驗收測驗中，客戶檢查產品在合同方面的驗收情況，以及用戶和操作人員的驗收情況，如果系統要安裝在多個環境中，現場測驗提供了一個額外的機會，通過運行產品的預發布版本來獲得系統的經驗，

• 在產品的整個生命周期中，維護和增量開發不斷創造出新的軟體產品版本，每個新版本都要進行測驗，這種回歸測驗的范圍取決于相應的風險分析的結果，

標籤：其他

上一篇：百度飛槳(PaddlePaddle) - PP-OCRv3 文字檢測識別系統 Paddle Inference 模型推理

下一篇：返回列表