本節書摘來自異步社群《軟體測試技術實戰：設計、工具及管理》一書中的第1章，第1.1節軟體測試的基本理論，作者顧翔，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。
第1篇 軟體測試設計技術
軟體測試技術實戰：設計、工具及管理
如何把使用者的需求轉換為軟體測試設計，這是軟體測試工程師的工作重心所在。本書第一篇通過6個章節來講述一下如何進行軟體測試設計。
本篇共分以下幾個章節。
第1章，軟體測試的基本知識：首先講解一些軟體測試的基本知識，如果你對軟體測試的基本概念已經非常熟悉了，那麼就可以簡單浏覽，甚至跳過本章的内容。
第2章，傳統的軟體測試的設計方法：本章主要介紹軟體測試中最經典的5個黑盒測試方法（等價類/邊界值、決策表、狀态轉換圖、決策樹和正交測試法）和7個白盒測試（語句、分支、條件、判定/條件、mc/dc、路徑和控制流覆寫）方法。
第3章，探索式軟體測試設計方法，本章主要介紹基于經驗測試法中目前最流行的探索式軟體測試方法。
第4章，基于風險的軟體測試。本章主要介紹基于風險的軟體測試方法以及風險級别的确定和調整。
第5章，專項軟體測試設計。本章主要介紹性能測試和嵌入式軟體的測試方法。
第6章，雲計算、大資料的軟體測試方法：本章主要簡單介紹基于雲的産品、大資料産品應該如何測試以及應注意的事項。
第1章 軟體測試的基本知識
本章主要介紹軟體測試的基本知識，共分3節。通過本章，可以學到。
軟體測試的基本理論。
軟體測試的7條基本原則。
“驗證”與“确認”的差別。
學習本章可能比較枯燥，裡面有許多關于軟體測試的名詞定義，但是這是軟體測試的基礎，如果你是軟體測試的菜鳥，可能有許多地方看不懂，沒有關系，千萬不要緊張，你可以先浏覽一下，看完這本書的其他章節再回過頭來重新閱讀，可能會有更深入的體會。另外，我也盡可能結合一些案例來介紹這些概念。
1.1 軟體測試的基本理論
軟體測試的基本理論是軟體測試的基礎。在本書的開始，我們先學習和回顧一下軟體測試的基本術語，這樣可便于更深入地探讨軟體測試的其他知識。
1.1.1 軟體測試的定義
關于軟體測試的定義有很多，這裡主要介紹以下幾個。
定義一：“軟體測試是為了證明程式有錯，通過運作程式發現其中存在的問題。”這個定義是在軟體測試的第一部權威書籍《軟體測試的藝術》中定義的，參見參考文獻【1】。
從這個定義中可以看出。
軟體測試可以證明軟體有錯。
這是顯而易見的。通過測試，可以發現軟體中的缺陷，這也證明了軟體中存在錯誤。
軟體測試不能證明軟體沒有錯。
沒有一個軟體是不存在缺陷的，通過軟體測試，我們可以找到軟體中的錯誤，但是不可以找到軟體中的所有錯誤。
定義二：“軟體測試是根據軟體開發各階段的規格說明和程式内部結構而精心設計的一批測試用例（即輸入資料及其預計輸出結果），并利用這些測試用例來執行測試程式，以及發現錯誤的過程，即執行軟體測試步驟。”
這個定義是目前比較流行的軟體測試定義。
定義三：“軟體測試是驗證軟體産品是否滿足使用者顯性或者隐性需求的活動。”
這個定義是基于品質的定義而延伸出來的。品質的定義為“滿足使用者顯性或者隐性需求的活動”，是以這個定義可以簡化為“軟體測試是驗證軟體産品是否滿足品質的活動”。另外，這裡定義中的“隐性需求”是指使用者需求規格說明書中沒有寫出來的，如軟體的易用性、可靠性、可維護性、效率等。
定義四：“軟體測試包括驗證（verification）和确認（validation）兩種類型。”驗證是指後一步是否滿足前一步的需求，在軟體開發過程中可以了解為需求分析是否滿足使用者需求，設計是否滿足需求分析，開發是否滿足設計。而确認是指最終産品是否滿足使用者的最初需求，如圖1-1所示。
1.1.2 軟體測試術語
1．冒煙測試（smoking testing）
在大部分軟體測試工作中，單元測試與內建測試是由開發工程師完成的，而系統測試是由軟體測試工程師完成的。為了提高軟體測試工程師測試的有效性，當軟體測試工程師拿到開發工程師送出的版本後，就需要進行一次冒煙測試。冒煙測試主要指測試軟體版本中的主要功能是否實作，速度很快，一般一到兩個小時即可完成。誇張地說，抽一根香煙的時間就可以完成測試。還有一個說法來源于硬體測試，一般硬體組裝完畢，上電後，如果電路出現冒煙故障，則不必進行更深入的測試。在軟體測試中，如果冒煙測試沒有通過，就需要傳回給開發工程師重新修改後再測試。
2．回歸測試（regression testing）
回歸測試又稱衰竭性測試。為了確定修改或增加的功能沒有給軟體其他未改變的（或者以前測試通過的）部分帶來影響，軟體測試工程師進行每輪測試時，需要對先前測試過的子產品再進行測試，這種測試稱為回歸測試。回歸測試最好使用自動化軟體測試工具來實作。關于回歸測試，如圖1-2所示。
3．白盒測試（white box testing）
白盒測試是通過分析元件/系統的内部結構進行的軟體測試。白盒測試用例分析方法包括語句覆寫、分支覆寫、條件覆寫、條件/分支覆寫和路徑覆寫等技術。白盒測試也可以在系統測試中進行（關于白盒測試的方法，本篇2.6節會詳細介紹）。
4．黑盒測試（black box testing）
黑盒測試是基于系統功能或非功能規格說明書來設計或者選擇測試用例的技術，它不涉及軟體内部結構。也就是說，測試工程師不需要了解程式内部是如何實作的，隻需考慮輸出内容的特性對應輸入内容的要求。黑盒測試也可以基于代碼來實作，如通過輸入函數的參數和傳回值來了解被測函數的功能是否得到實作。
案例1-1：函數級别黑盒測試。
函數float calcualtesimilty(string a, string b)，傳回0.00～1.00小數點精度為兩位的浮點數。比較字元串a，b的相似程度，0.00表示一點不相似，1.00表示完全相似。可以用下面的測試用例來實作函數級别的黑盒測試，特别聲明，這裡不需要了解函數内部是如何實作的，隻關心函數輸入與輸出的對應關系。測試用例如下：
5．單元測試（unit testing）
單元測試又稱元件測試，是對單個軟體元件進行的軟體測試【與ieee610一緻】。單元測試一般采用軟體測試驅動與樁的技術。
案例1-2：單元測試。
對圖1-3的子產品b進行單元測試如下。
b子產品的代碼可能如下：
b的驅動函數是指通過頁面或者編譯器可以調用的函數，通常設定為主函數，即main()函數。
stubd，stube為b的樁函數。樁函數為模拟被測單元的調用子產品，由于測試的是子產品b，是以樁函數可以簡單地傳回一個符合要求類型的變量。
這裡，單元測試主要驗證子產品b的功能，在驗證過程中可以采用等價類、邊界值、錯誤輸入等方法來實作。
對于軟體測試樁，現在有許多新的技術，如圖1-4所示。
這些新技術的介紹不在本書的範疇中，有興趣的讀者可以自己查找相關的文獻。
6．內建測試（integration testing）
內建測試是一種暴露接口以及內建元件/系統間互動時存在缺陷的軟體測試方法。內建方法有自上而下測試法、自下而上測試法、自上而下和自下而上混合（又稱三明治）測試法3種。
案例1-3：內建測試。
下面來看一個程式架構，如圖1-5所示。
可以采取如下方法對此進行內建測試。
自下而上內建：
（1）子產品6與子產品7內建，子產品6與子產品8內建；
（2）子產品3與子產品5內建，子產品3與子產品6內建；
（3）子產品2與子產品4內建，子產品2與子產品5內建；
（4）子產品1與子產品2內建，子產品1與子產品3內建。
自上而下內建：
（1）子產品1與子產品2內建，子產品1與子產品3內建；
（2）子產品2與子產品4內建，子產品2與子產品5內建；
（3）子產品3與子產品5內建，子產品3與子產品6內建；
（4）子產品6與子產品7內建，子產品6與子產品8內建。
三明治內建：
（3）子產品1與子產品2內建，子產品1與子產品3內建；
（4）子產品2與子產品4內建，子產品2與子產品5內建；
（5）子產品3與子產品5內建，子產品3與子產品6內建。
7．系統測試（system testing）
系統測試是軟體測試的主要部分，是利用各種方法驗證軟體是否滿足産品顯性或者隐形需求的活動。
8．驗收測試（accept testing）
驗收測試一般由使用者/客戶或者運維人員進行确認是否可以接受一個系統的驗證性的軟體測試。可根據使用者需求、業務流程進行的正式的軟體測試，以確定系統符合所有驗收準則（與ieee 610一緻）。驗收測試可以分為alpha測試和beta測試。
（1）alpha測試
alpha測試是由潛在使用者或者獨立的軟體測試團隊在開發環境下或者模拟實際操作環境下進行的軟體測試，通常在開發組織外進行，是對現貨軟體（off-the-shelf software）進行内部驗收測試的一種方式。
（2）beta測試
beta測試是潛在現有使用者/客戶在開發組織外的場所，沒有開發工程師參與的情況下進行的軟體測試，檢驗軟體是否滿足客戶及業務需求。這種軟體測試經常是為了獲得市場回報對現貨軟體進行外部驗收測試的一種形式。
9．靜态測試（static testing）
靜态測試是對元件/系統進行規格或實作級别的測試，但并不執行這個軟體，如代碼評審或靜态代碼分析等。
10．動态測試（dynamic testing）
動态測試通過運作軟體的元件或系統來測試軟體。
更多的軟體測試術語，請參見參考文獻【33】。
1.1.3 軟體工程模型
讨論軟體測試學，不得不涉及軟體工程模型，因為軟體測試學與軟體工程學的發展是依依相關、相輔相成的。根據目前比較先進的軟體測試理念，軟體測試應該貫穿于軟體工程的整個過程中。下面介紹幾種軟體工程模型。
1．瀑布模型
圖1-6為瀑布模型。這個模型是最經典的軟體工程模型，包括“計劃”->“需求分析”->“設計”->“編碼”->“測試”->“運作維護”這幾個階段。
但是，這個模型存在比較嚴重的缺點。
（1）不可反複及不适用于需求變更比較頻繁的情況。由于瀑布模型從業務模組化到運作維護一脈相承，不可以反複。而現代軟體項目中，需求變更是無處不在的：“唯一不變的是需求變更”。若運用這種模型，隻要項目需求發生變化，就要把原有的設計打翻，重新進行系統分析，概要設計，詳細設計等。
（2）使用者很難在項目初期了解項目狀态：由于使用者在項目初期很難提出明确的需求，而利用瀑布模型隻有到編碼結束，軟體測試工程師才可介入軟體測試，客戶才可以看到是否是他們需要的産品，在此之前這些産品他們不完全了解，有時需要補充，有時客戶也有可能推翻他們原本的需求，提出新的需求，這樣往往會給客戶方、開發方帶來很多麻煩。
2．疊代模型和螺旋模型
圖1-7為疊代模型。瀑布模型和疊代模型往往在概念上差別不明顯。事實上，這兩個模型在思想本質上是一緻的。它将客戶的需求按照使用者的重要等級和子產品自身的等級進行安排，從最開始進行分析、設計、編碼、測試，然後再進入下一輪疊代。使用者隻要在每一輪結束後，就可以看到産品的一些雛形，進而可以進行需求變更和提出下一輪建議。該模型初期開發工作比較少，使用者又可以及時提出下一輪更詳細的需求和變更，是以這樣的模型往往利于軟體公司産品的研發。這類模型有著名的rup模型、快速開發模型以及現在比較流行的靈活開發等，它們都遵循疊代的思想。
擴充閱讀：增量開發與疊代開發
注：本書中擴充閱讀大部分來自于百度百科，請見參考文獻【21】。
1.1.4 軟體測試模型
1．v模型
圖1-8所示為v模型測試。
單元測試相對于編碼進行，這一步往往由開發工程師執行。
內建測試相對于詳細設計，将子產品以由上到下、由下到上或混合方式進行逐漸內建。測試軟體子產品與子產品、類與類之間的關聯性。
系統測試相對于概要設計，軟體測試工程師站在整體的立場上對系統進行全面的軟體測試工作。
驗收測試是使用者對産品進行的測試，一般分為alpha測試和beta測試。驗收測試往往由系統維護人員或者使用者來完成，需要完全站在使用者的立場上進行測試，測試環境也要盡可能與使用者的實際環境保持一緻，大多數時候，需要到使用者現場去進行驗收測試工作。
2．w模型
圖1-9所示為w模型測試。w模型其實是v模型的變種，它提倡的主要思想是軟體前置測試理念（即軟體測試需要貫穿軟體研發的始終）。是以，w模型又稱雙v模型或前置模型。在需求、設計和編碼階段對産生的工件進行文檔評審，一個目的是提出自己的建議和意見，另外一個目的是盡可能了解産品的需求和實作方式。使用前置軟體測試法，bug在軟體前期就可以發現，進而降低軟體開發的成本。
3．x模型
圖1-10為x模型測試。x模型将軟體系統分為若幹子產品，對每個子產品進行單元測試、內建測試以及系統測試，然後統一對子產品進行內建測試。事實上，這裡已經提出了“探索式軟體測試”的概念，在本書第3章會詳細介紹探索式測試。
1.1.5 軟體測試方法
軟體測試方法見表1-1。
代碼評審中有一個部分是對編碼規範的檢查。另外，代碼評審可以通過人工的方式來實作，也可以借助代碼評審工具，如在本書第二篇7.1.1節“普通軟體測試工具推薦”提及的checkstyle、findbugs、pmd、android lint等工具。
擴充閱讀：阿麗亞娜五型運載火箭的爆炸-代碼靜态測試的重要性
程式員在程式設計的時候必須定義程式用到的變量，以及這些變量所需的計算機記憶體，這些記憶體用比特位來定義，如int16、int32、double、float等。
一個16位的整數變量可以代表-32.768到32.767中間的值。而一個64位的整數變量可以代表-9.223.372.036.854.775.808到9.223.372.036.854.775.807中間的值。
1996年6月4日上午9時33分59秒，随着5、4、3、2、1、0的倒計時，阿麗亞娜五型運載火箭的首次發射點火後，火箭開始偏離路線，最終被逼引爆自毀，整個過程隻有短短的30s。阿麗亞娜五型運載火箭是基于前一代四型火箭開發的。在四型火箭系統中，對一個水準速率的測量值使用了16位的變量及記憶體，因為在四型火箭系統中反複驗證過，這一值不會超過16位的變量，而五型火箭的開發工程師簡單複制了這部分程式，而沒有對新火箭進行數值的驗證，結果發生了緻命的數值溢出。發射後這個64位帶小數點的變量被轉換成16位不帶小數點的變量，引發了一系列的錯誤，進而影響了火箭上所有的計算機和硬體，癱瘓了整個系統，因而不得不選擇自毀。
阿麗亞娜五型載火箭使用ada語言開發，出問題的代碼如下：
在這個代碼中導緻最終問題的是最後一句。在這一段語句中共有7個變量運算符出現了問題，僅有4個做了異常處理的保護，而其他3個沒有進行。但是這也是由于運作的機器sri計算機中設定最大負荷目标值為80%，如果要進行異常處理，計算機的cpu要處理的代碼會增多。
教訓：軟體設計和code review的重要性。另外阿麗亞娜五型運載火箭在倒計時階段、飛行階段以及進入軌道階段都未經過測試驗證。
1.1.6 軟體測試步驟
圖1-11描述了軟體測試步驟，具體如下。
（1）軟體測試計劃。
（2）軟體測試分析。
（3）軟體測試設計。
（4）軟體測試實施。
（5）軟體測試執行。
（6）評估出口準則和報告。
（7）軟體測試結束活動。
具體内容讀者可以參見參考文獻【13】第二章進行更深入的學習。
1.1.7 軟體缺陷管理
1．缺陷管理流程
根據sei tsp國際标準，缺陷管理流程可以定義如下。
研發計算機必須分為開發機、測試機和釋出機。開發工作在開發機上進行，軟體測試工作（系統測試）在測試機上運作，最後産品驗收和運作在釋出機上運作，釋出機器可能在客戶處。
（1）每輪測試開始，開發部門提出本次測試重點，開發機上的版本同步到軟體測試機上（或通過配置管理工具實作同步）。
（2）軟體測試工程師進行冒煙軟體測試，如果冒煙測試沒有通過，則退回給開發部門，等待開發部門重新送出軟體測試任務，傳回第（1）步。
（3）冒煙測試通過，測試工程師繼續執行測試活動，包括傳統正規測試和基于經驗的測試，如探索式軟體測試等。發現bug，記錄在缺陷管理工具中。
（4）開發工程師修改被确認的bug（狀态為assigned）。
（5）當軟體測試工程師認為軟體測試結束，大部分bug都發現完畢，開發機上版本再一次同步到軟體測試機上。
（6）軟體測試工程師對bug進行複測，如果問題仍舊存在，則标記為reopen，否則标記為closed。此時還要對以前測試過的功能進行回歸測試。
（7）開發工程師對于reopen的缺陷進行修改。
（8）當一輪軟體測試達到出口标準，軟體測試機上的版本同步到釋出機上，軟體測試任務完成；否則傳回第（5）步。
在本書第三篇第13.9節“軟體缺陷管理流程”會給出更為詳細的描述。
2．缺陷嚴重等級
由于采用的缺陷管理工具不同，缺陷嚴重等級的級别也會有差異。
blocker：（阻礙的）
阻礙開發和/或軟體測試工作，冒煙測試沒有通過，不能進行正常的軟體測試工作。
critical：（緊急的）
系統無法測試，或者系統無法繼續操作，應用系統異常中止。
對作業系統造成嚴重影響，系統當機，被測程式挂起，不響應等情況。
造成重大安全隐患情況，如機密性資料的洩密。
功能沒有實作，無法進行某一功能操作，影響系統使用。
major：（重大的）
功能基本上能實作，但在特定情況下導緻功能失敗。
導緻輸出的資料錯誤，如：資料内容出錯、格式錯誤、無法打開。
導緻其他功能子產品無法正常執行。
功能不完整或者功能實作不正确。
導緻資料最終操作結果錯誤。
normal：（普通的）
功能部分失敗，對整體功能的實作基本不造成影響。
minor：（較小的）
連結錯誤、系統出錯提示或沒有捕獲系統出錯資訊、資料的重要操作（增删查改）沒有提示、出現頻率極低，會對功能實作造成非緻命性的影響。
trivial：（外觀的）
産品外觀上的問題或一些不影響使用的小毛病，如菜單或對話框中的文字拼寫或字型問題等。
enhancement（改進的）
對系統産品的建議或意見。
3．缺陷修改優先級
由于缺陷管理工具的差異，缺陷修改優先級别也會有差異。
p5：嚴重級别比較高，影響軟體測試進行或者系統無法繼續操作。
p4：對系統操作有影響，但不需要馬上修改。
p3：頁面缺陷（不屬于定義的缺陷範圍）或者建議。
p2：準備在下一輪軟體測試前修改完畢。
p1：準備在下一版本中修改。
4．缺陷書寫規則
缺陷編号：【一般缺陷管理工具自動生成】
缺陷簡要描述：【一句話描述】
發現者：【一般從下拉框中選擇】
修改者：【一般從下拉框中選擇】
最早發現所在版本号：【一般從下拉框中選擇】
最早發現日期：【一般由日期框選擇】
最早修改日期：【一般由日期框選擇】
缺陷目前所在子產品：【一般從下拉框中選擇】
缺陷目前狀态：【一般系統自動生成】
缺陷發現時系統環境：【文本框輸入或者下拉框選擇】
缺陷重制步驟：【由缺陷發現者填寫】
實際得到結果：【由缺陷發現者填寫】
期望得到結果：【由缺陷發現者填寫】
修複描述：【由缺陷修複者填寫】
相關檔案：【由缺陷發現者填寫】
延遲/不修改/修複/回退原因說明：【由缺陷負責人填寫】
曆史資訊：【由缺陷管理系統自動生成，包括狀态遷移，所經過的人，各階段描述等資訊】
附件：【由缺陷發現者上傳檔案】
關于缺陷管理工具将在本書第二篇第10章“缺陷管理工具”進行較長的描述。
擴充閱讀：世界上第一個bug
1947年9月9日下午3點45分，grace murray hopper在她的記錄本上記下了第一個計算機bug——在harvard mark ii計算機裡找到的一隻飛蛾，她把飛蛾貼在日記本上，并寫道“first actual case of bug being found”。這個發現奠定了bug這個詞在計算機世界的地位，變成無數程式員的噩夢。從那以後，bug這個詞在計算機世界表示計算機程式中的錯誤或者疏漏，它們會使程式計算出莫名其妙的結果，甚至引起程式的崩潰。grace murray hopper是曆史上最早一批程式員，而且還是個女程式員。
hopper的記錄連同那隻飛蛾現在存在美國曆史博物館。
1.1.8 測試用例
1．測試用例格式
測試用例格式見表1-2。
編号：“chinafi_”+*+“_”+xxx。
chinafi：固定的開始字元。
*：子產品名。
xxx：3位0～9的數字。
前置條件：完成此項測試，需要達到的前提條件。如測試登入，前置條件為注冊的基本功能必須實作。
說明：測試項目的描述。
項目編号：一個測試中可包括幾個項目，每個項目的編号。
測試步驟：完成測試的具體步驟描述。
期待結果：對于一些重要步驟的頁面期待的顯示結果，每一項最後一步的期待結果是必須書寫的。
概要說明：對于測試過程中的一些說明注解。
2．測試用例案例
案例1-4：測試用例的書寫。
環境：浏覽器、web伺服器（tomcat）、mysql資料庫。
需求：一個表單資訊，用于網站使用者注冊個人資訊，主要包括姓名、登入名、密碼（大于5個字元，必須包含數字和特殊字元）、确認密碼、email資訊、手機、位址，其中登入名、密碼、确認密碼、email資訊是必填的，其他資訊可以選填。請根據需求 書寫測試用例（不考慮長度測試）。使用者注冊界面如圖1-12所示，使用者注冊測試用例見表1-3。
當然，要寫好測試用例，首先要學好如何進行測試設計，後續章節中會進行詳細介紹。
1.1.9 軟體測試類型
關于軟體測試類型，可以參照iso 225000（替代iso 9126）軟體品質模型，如圖1-13所示。
1．功能測試
功能測試對測試對象側重于所有可直接追蹤到用例或業務功能和業務規則的軟體測試需求。這種軟體測試的目标是核實資料的接收、處理和檢索是否正确，以及業務規則的實施是否恰當。此類軟體測試可以通過黑盒測試技術或白盒測試技術來實作，該技術通過圖形使用者界面（gui）或其他方式與應用程式進行互動，并對互動的輸出或結果進行分析，以此核實應用程式及其内部功能。
案例1-5：功能測試。
圖1-14所示是電子商務計價系統界面。随着電子商務網站越來越多，某些商品在節假日可以打折，會員可以享受會員價，購買物品達到一定數量或金額後，也可以打折或者免運費。這些條件給計價系統的準确性帶來很複雜的功能，軟體測試工程師應該設計好各種測試用例，來檢測系統的功能。
2．易用性測試（使用者體驗性測試）
易用性測試指的是在指定條件下使用時，軟體産品被了解、學習、使用和吸引使用者的能力。
這裡的使用者包括。
（1）操作人員。
（2）最終使用者。
（3）受該軟體的使用影響或者依賴于該軟體的間接使用者。
易用性品質特性。
易了解性。
易學性。
易操作性。
吸引性。
易用性測試采取技術。
人工檢查 審查或者評審。
問卷調查 通過問卷調查方式得到使用者使用軟體的回報。
驗證和确認 針對軟體産品的實作，進行驗證和确認。
a/b軟體測試法。
案例1-6：易用性測試。
如圖1-15所示，對于安卓系統解除安裝app軟體，必須進入設定界面，找到軟體，再單擊【解除安裝】按鈕才可以解除安裝；而蘋果系統隻要在界面上長按app軟體圖示3s，點左上角的叉，即可删除。由此可見，蘋果系統的解除安裝app的軟體易用性明顯優于安卓系統。另外，現在我們給易用性測試起了一個更好聽的名字，叫“軟體使用者體驗性測試”。
3．可靠性測試
可靠性測試的目的之一是對軟體成熟度在時間上的統計度量名額進行監控，并将其與既定目标比較。可靠性對應3個名額，如圖1-16所示。
（1）平均失效間隔時間mtbf（這次失效到下次失效的時間）。
（2）平均修複時間mttr（本次失效修複的時間）。
（3）平均失效前時間mttf（修複完畢到下次失效的時間）。
通過圖1-16所示，可以看出：mtbf＝mttr＋mttf。
另外，可靠性失效名額的一般公式：可靠性失效名額=mttr/mtbf×100%
案例1-7：電信系統軟體的可靠性。
在電信領域，可靠性失效名額要達到著名的5個9，即99.999%，也就是說一年中允許裝置故障的時間為：365×（1−99.999%）天=8760×（1−99.999%）小時=525600×（1−99.999%）分鐘=5.256分鐘。
4．性能測試
性能測試的類型比較多，這裡主要考慮以下3種類型。
（1）基本性能測試：正常情況下軟體的響應速度。
（2）負載測試（load測試）：通過增加負載（一般為并發使用者或資料庫容量）來評估元件或系統性能的軟體測試方法。
測試方法：以一定的負載作為起點，觀察系統吞吐率，不斷加大負載個數，直到吞吐率達到飽和，這時負載為該産品這個功能的最大負載。
（3）壓力測試：評估系統處于一定的負載下（最大負載乘以一定百分比），讓系統運作一段時間，觀察系統各項名額是否正常。
案例1-8：web系統的性能測試。
在web頁面對使用者登入功能進行負載測試，擷取最大負載數，并以最大負載的80%，持續運作48小時進行壓力測試，觀察系統各項名額是否正常運作。
關于性能測試，本篇第5.1節将會詳細講解。
5．安全性測試
軟體安全性包括功能安全性和資訊安全性，本節隻考慮資訊安全性。
資訊安全性：指的是軟體産品保護資訊和資料的能力，及未授權的人員或者系統不能閱讀或者修改這些資訊和資料，而不拒絕授權人員或者系統對它們進行通路。資訊安全性測試的關注點：
對應用程式/資料進行未授權的複制；
未授權的通路控制；
出入域溢出導緻的緩存區溢出；
服務拒絕，阻止使用者與應用程式的互動；
在網絡上竊聽資料傳輸擷取敏感資訊；
破解保護敏感資訊的加密代碼；
邏輯炸彈/複活節彩蛋。
資訊安全性分類：
與使用者接口相關；
與檔案系統相關；
與作業系統相關；
與外部軟體相關。
資訊安全性測試方法：
使用工具建立系統概況或網絡圖；
使用多種工具進行漏洞掃描；
獲得資訊研制“攻擊方案”；
根據安全專家（白帽子黑客）的建議進行多種攻擊。
案例1-9：黑客侵入。
某公司開發一套網上答題系統，題目均為單項選擇題，可以選擇a、b、c、d中的任意一項，每一周評選最高得分者，可以在電視節目中參加一個益智類的欄目。為了防止網友對所有題選擇某個相同的答案（如對所有題都選擇d），或者有規律的選擇（如選題都是a、c、d、b、a、c、d、b…）在前端javascript程式裡做了控制：如果連續5次選擇同一個答案或者有規律地選擇的答題者将被答題系統自動踢出。該程式經過嚴格測試後上線使用。可是，上線不到4周，發現每周最高得分者均為一個姓張的先生，檢視其答案，竟然所有題目都答成b，這讓開發工程師感到很奇怪。兩周後，公司的開發經理在網站群聊中找到這位張先生，張先生告訴開發經理，系統在前端javascript做了控制，但是在後端javabean中沒進行控制，是以他自己寫了個程式繞過前端，這個程式是一個死循環，7×24小時一直發送答案b給後端系統。
案例1-10：xss注入。
如果沒有對html特殊字元進行處理（html特殊字元見附錄a），在浏覽頁面時會運作javascript代碼，如果輸入的javascript代碼具有惡意獲得使用者資訊的功能，就會産生安全問題，如輸入：“ ”，頁面在顯示時就會把使用者目前的浏覽器版本和型号都顯示出來。這樣，黑客就可以根據擷取的資訊采取進一步攻擊。
案例1-11：sql注入。
sql注入比xss注入更加危險。下面的例子可以造成使用者不注冊就能登入系統：下面是登入系統的sql語句：select count() from user where name='$name' and password='$password'。上面是使用者登入的sql語句，如果count()不為零，使用者即可進入系統。$name，$password為使用者在界面中輸入的值，這裡作為一個變量存儲。$name可以任意輸入，如輸入“jerry”，$password輸入類似于“2222' or 1=1;-- '”，由于這樣sql語句變為select count() from user where name='jerry' and password='2222' or 1=1;-- '，where語句後的條件永遠為真，是以判斷語句count()一定不為零。
6．相容性測試
相容性測試又稱相容性測試，指的是軟體産品與一個或者多個規定的系統之間進行互動的能力。該項測試用于驗證軟體産品或者應用程式在各種指定的目标環境下是否可以正常工作，主要包括：
（1）硬體；
（2）軟體；
（3）中間件；
（4）作業系統；
（5）其他。
相容性測試包括：輸入的相容性、輸出的相容性以及自适應性。
案例1-12：裝置接口相容性。
某些裝置廠商生産出的産品需要被其他廠商調用，或者調用其他廠商的接口。在這些廠商中，北向接口與南向接口經常被提及。北向接口和南向接口如圖1-17所示。
北向接口：我的裝置使用其他裝置的功能，這個接口為北向接口。
南向接口：其他裝置使用我的裝置的功能，這個接口為南向接口。
可以看出，如果用單元測試做一個比喻，北向接口裝置相當于驅動函數，而南向接口裝置相當于樁函數。
案例1-13：螢幕分辨率測試。
螢幕分辨率測試屬于相容性測試的範疇，要求測試在不同螢幕分辨率下。界面的美觀程度，可分為800×600、1024×768、1152×864、1280×768、1280×1024、1200×1600等，不同字号下的測試。
7．可移植性測試
可移植性測試通常和軟體移植到某個特定的運作環境中的難易程度相關，包括第一次建立或從現有環境移植到另一個環境。這種測試類型包括：
（1）可安裝性測試；
（2）适應性測試；
（3）可替換性測試。
案例1-14：網絡裝置移植測試。
某軟體從網絡裝置a移植到網絡裝置b中，發生了錯誤。後經過排查，結論是網絡裝置a的ip位址用的是使用者位址序列（高位在前，低位在後）。而網絡裝置b的ip位址用的是網絡位址序列（低位在前，高位在後）。如ip位址是192.168.0.8，轉化為十六進制為c0.a8.00.08，在裝置a上是使用者位址序列為c0a80008。在裝置b上是網絡位址序列為0800a8c0。
故障轉移和恢複測試屬于可移植性測試範疇，它可確定軟體測試對象能成功完成故障轉移，并能從意外資料損失或資料完整性破壞的各種硬體、軟體或網絡故障中恢複。
故障轉移測試可確定對于必須持續運作的系統，一旦發生故障，備用系統就将不失時機地“頂替”發生故障的系統，以避免丢失任何資料或事務。
恢複測試是一種對抗型測試過程。在這種軟體測試中，将把應用程式或系統置于極端（或者是模拟的極端）的條件下，使其産生故障（如裝置輸入/輸出 （i/o）故障或無效的資料庫指針和關鍵字）。然後調用恢複程序，并監測和檢查應用程式和系統，核實應用程式或系統以及資料已得到正确恢複。
安裝、解除安裝測試也屬于移植性測試，安裝測試有兩個檢查點。
（1）確定該軟體在正常情況和異常情況的不同條件下（如進行首次安裝、更新、完整的或自定義的安裝）都能進行安裝。異常情況包括磁盤空間不足、缺少目錄建立權限等。
（2）核實軟體在安裝後可立即正常運作。
解除安裝測試有4個檢查點：
（1）解除安裝是否正常、解除安裝後的軟體是否能夠運作；
（2）核實解除安裝軟體的資料與檔案都删除幹淨；
（3）解除安裝後的軟體重新安裝是沒有問題的；
（4）解除安裝後的軟體不影響其他軟體的工作。
8．可維護性測試
可維護性測試指的是軟體産品可被修改的能力，包括糾正、改進或者軟體對環境、需求和功能規格說明變化的适應能力。
案例1-15：代碼可維護性測試。
某公司生産了erp産品給a企業，3年後由于公司erp流程發生變化，需要在原來基礎上進行更新，但是由于3年來近一半的開發工程師發生了變動，代碼注釋又不規範，給新功能開發帶來很大困難，這就産生了代碼可維護性的問題。為了解決這個問題，軟體工程師把代碼進行了如下優化，如圖1-18所示。
要做好代碼的可維護性，最好是在編碼後期做好嚴格的代碼稽核（code review）工作。
案例1-16：産品的可測試性。
某b/s産品決定采用webdriver進行測試，由于html代碼中的元素都沒有id、name或者class屬性，如：
如果采用手工測試，是沒有關系的，但是采用自動化測試，就帶來很大困難，于是把html代碼改為：
關于webdriver的介紹參看本書第二篇第11.2節“selenium和webdriver工具入門”介紹。
在軟體測試工作中除了關注iso 22500标準外，我們還經常用到以下測試方法。
9．資料和資料庫完整性測試
在項目名稱中，資料庫和資料庫程序應該作為一個子系統來進行軟體測試。測試這些子系統時，不應将測試對象的使用者界面用作資料的接口。對于資料庫管理系統（dbms），需要進行深入研究，以确定可以支援以下測試的工具和技術。資料庫測試包括以下幾個方面。
資料庫設計測試。
sql代碼規範測試：可使用工具為sql bpa。
sql語句效率測試。
sql語句相容性測試：sql語句标準fips 127-2，基于sql-92标準。
擴充閱讀：fips标準和sql-92标準
1．fips标準
fips（federal information processing standards）即（美國）聯邦資訊處理标準。它是準許技術與标準國家協會 （national institute of standards and technology），為聯邦計算機系統制定标準和指南。
2．sql-92标準
sql-92，是資料庫的一個ansi/iso标準。
sql92标準有4個層次
入門級
這是大多數開發商符合的級别。這一級隻是對前一個标準sql89稍做修改。所有資料庫開發商都不會有更高的級别，實際上，美國國家标準和技術協會nist（national institute of standards and technology，這是一家專門檢驗sql合規性的機構）除了驗證入門級外，甚至不做其他的驗證。oracle 7.0于1993年通過了nist的sql92入門級合規性驗證，那時我也是小組中的一個成員。如果一個資料庫符合入門級，它的特性集則是oracle 7.0的一個功能子集。
過渡級
這一級在特性集方面大緻介于入門級和中間級之間。
中間級
這一級增加了許多特性，包括（以下所列并不完整）：
動态sql；
級聯delete以保證引用完整性；
date和time資料類型；
域；
變長字元串；
case表達式；
資料類型之間的cast函數。
完備級
增加了以下特性（同樣，這個清單也不完整）：
連接配接管理；
bit串資料類型；
可延遲的完整性限制；
from子句中的導出表；
check子句中的子查詢；
臨時表。
入門級标準不包括諸如外聯結（outer join）和新的内聯結（inner join）文法等特性。過渡級則指定了外聯結文法和内聯結文法。中間級增加了更多的特性，當然，完備級就是sql-92全部。有關sql-92的大部分書都沒有差別這些級别，這就會帶來混淆。這些書隻是說明了一個完整實作sql-92的理論資料庫會是什麼樣子。是以無論你拿起哪一本書，都無法将書中所學直接應用到任何sql-92資料庫上。關鍵是，sql-92最多隻達到入門級，如果你使用了中間級或更進階裡的特性，就存在無法“移植”應用的風險。
10．本地化測試
本地化測試是指為各個地方開發産品的軟體測試，如英文版、中文版等，包括程式是否能夠正常運作，界面是否符合當地習俗，快捷鍵是否正常起作用等，特别要測試在a語言作業系統環境下運作b語言軟體（如在英文版的windows作業系統下試圖運作中文版的程式），運作是否正常。
11．文字測試
文字測試主要測試文字是否拼寫正确、是否易懂、不存在二義性、沒有文法錯誤；文字與内容（包括圖檔、文字）是否有出入等。
12．釋出測試
主要在産品釋出前對一些附帶産品，如說明書、廣告稿等進行軟體測試。釋出測試在驗收測試中進行。
說明書測試
說明書測試主要為語言檢查、功能檢查、圖檔檢查。
語言檢查：檢查說明書語言是否正确，用詞是否易于了解。
功能檢查：功能是否描述完全，或者描述了并沒有的功能等。
圖檔檢查：檢查圖檔是否正确。
宣傳材料測試
主要測試軟體産品中附帶的宣傳材料中的語言、描述功能、圖檔。
産品說明書的測試
産品說明書是使用者（特别是一些新使用者）了解産品的一個有力工具。是以，軟體測試工程師應該對産品說明書中的每一條功能進行嚴格核實。除此之外，還應從使用者的角度思考，考慮是否将注意事項告訴了使用者，産品說明書是否便于閱讀，産品說明書的書寫邏輯是否合理以及說明書中章節的前後順序是否需要進行調整。
産品廣告
産品廣告往往是由市場人員為了推銷産品而書寫的，對于廣告中提及的功能，我們要與市場和銷售人員進行及時溝通，弄清楚每條語句是在哪個子產品的哪個功能點上實作的，然後在産品上具體操作一下，看是否是那麼一回事。廣告具有一定的誇大性，這在所難免。但是，對于誇大過份的内容，軟體測試工程師有提出修改建議的責任。
1.1.10 軟體測試曲線
衆所周知軟體的bug不可能為零，但一般随着時間的推移，bug數逼近于零。軟體測試曲線如圖1-19所示。
這裡，橫坐标是時間，縱坐标是還沒有發現的bug數。項目開始前，bug為無窮大，随着時間的推移，bug趨于零，但是不會等于零。
另外一條曲線的橫坐标是時間，縱坐标是已經發現的bug數。項目開始前，bug為零，随着時間的推移，bug趨于一個固定值，但是不會等于這個值。
一般來說，兩條曲線的交彙處為産品釋出的最好時候，避免過度軟體測試，也避免軟體測試不夠。
1.1.11 軟體的殺蟲劑現象
由于每個軟體測試工程師的思路不同，測試的側重點也可能不同，是以，不同的測試工程師即使執行相同的測試用例，發現的bug也可能不同。例如，a測試某個子產品，第一天到第四天測到許多bug，但是從第五天開始幾乎報不出bug了。第七天換了b，b又測試出許多bug，但不能簡單地說a的水準差，b的水準高。其實，這是由于a對這個子產品産生了抗藥性造成的，這就是軟體測試學中的殺蟲劑現象，可用圖1-20表示。
為避免殺蟲劑現象，建議每次進行輪流測試，最好安排不同的工程師進行不同子產品的測試工作。
案例1-17：根據軟體殺蟲劑現象進行測試計劃調整。
某軟體項目有測試員甲、乙、丙、丁4人，項目子產品為a、b、c、d、e、f、g七個子產品，測試周期為3周，為了避免軟體殺蟲劑現象，測試經理做了分工，見表1-4。這樣保證了每一個子產品至少有兩個人經過測試。