1.1 軟件測試的基本理論

軟件測試的基本理論是軟件測試的基礎。在本書的開始，我們先學習和回顧一下軟件測試的基本術語，這樣可便于更深入地探討軟件測試的其他知識。

1.1.1 軟件測試的定義

關于軟件測試的定義有很多，這里主要介紹以下幾個。

● 定義一：“軟件測試是為了證明程序有錯，通過運行程序發(fā)現其中存在的問題。”這個定義是在軟件測試的第一部權威書籍《軟件測試的藝術》中定義的，參見參考文獻【1】。

從這個定義中可以看出。

? 軟件測試可以證明軟件有錯。

這是顯而易見的。通過測試，可以發(fā)現軟件中的缺陷，這也證明了軟件中存在錯誤。

? 軟件測試不能證明軟件沒有錯。

沒有一個軟件是不存在缺陷的，通過軟件測試，我們可以找到軟件中的錯誤，但是不可以找到軟件中的所有錯誤。

● 定義二：“軟件測試是根據軟件開發(fā)各階段的規(guī)格說明和程序內部結構而精心設計的一批測試用例（即輸入數據及其預計輸出結果），并利用這些測試用例來執(zhí)行測試程序，以及發(fā)現錯誤的過程，即執(zhí)行軟件測試步驟。”

這個定義是目前比較流行的軟件測試定義。

● 定義三：“軟件測試是驗證軟件產品是否滿足用戶顯性或者隱性需求的活動。”

這個定義是基于質量的定義而延伸出來的。質量的定義為“滿足用戶顯性或者隱性需求的活動”，所以這個定義可以簡化為“軟件測試是驗證軟件產品是否滿足質量的活動”。另外，這里定義中的“隱性需求”是指用戶需求規(guī)格說明書中沒有寫出來的，如軟件的易用性、可靠性、可維護性、效率等。

● 定義四：“軟件測試包括驗證（Verification）和確認（Validation）兩種類型。”驗證是指后一步是否滿足前一步的需求，在軟件開發(fā)過程中可以理解為需求分析是否滿足用戶需求，設計是否滿足需求分析，開發(fā)是否滿足設計。而確認是指最終產品是否滿足用戶的最初需求，如圖1-1所示。

圖1-1 驗證與確認

1.1.2 軟件測試術語

1．冒煙測試（Smoking Testing）

在大部分軟件測試工作中，單元測試與集成測試是由開發(fā)工程師完成的，而系統測試是由軟件測試工程師完成的。為了提高軟件測試工程師測試的有效性，當軟件測試工程師拿到開發(fā)工程師提交的版本后，就需要進行一次冒煙測試。冒煙測試主要指測試軟件版本中的主要功能是否實現，速度很快，一般一到兩個小時即可完成。夸張地說，抽一根香煙的時間就可以完成測試。還有一個說法來源于硬件測試，一般硬件組裝完畢，上電后，如果電路出現冒煙故障，則不必進行更深入的測試。在軟件測試中，如果冒煙測試沒有通過，就需要返回給開發(fā)工程師重新修改后再測試。

2．回歸測試（Regression Testing）

圖1-2 修改部分與新功能對原有功能的影響

回歸測試又稱衰竭性測試。為了確保修改或增加的功能沒有給軟件其他未改變的（或者以前測試通過的）部分帶來影響，軟件測試工程師進行每輪測試時，需要對先前測試過的模塊再進行測試，這種測試稱為回歸測試。回歸測試最好使用自動化軟件測試工具來實現。關于回歸測試，如圖1-2所示。

3．白盒測試（White Box Testing）

白盒測試是通過分析組件/系統的內部結構進行的軟件測試。白盒測試用例分析方法包括語句覆蓋、分支覆蓋、條件覆蓋、條件/分支覆蓋和路徑覆蓋等技術。白盒測試也可以在系統測試中進行（關于白盒測試的方法，本篇2.6節(jié)會詳細介紹）。

4．黑盒測試（Black Box Testing）

黑盒測試是基于系統功能或非功能規(guī)格說明書來設計或者選擇測試用例的技術，它不涉及軟件內部結構。也就是說，測試工程師不需要了解程序內部是如何實現的，只需考慮輸出內容的特性對應輸入內容的要求。黑盒測試也可以基于代碼來實現，如通過輸入函數的參數和返回值來了解被測函數的功能是否得到實現。

案例1-1：函數級別黑盒測試。

函數float calcualteSimilty(String a, String b)，返回0.00～1.00小數點精度為兩位的浮點數。比較字符串a, b的相似程度，0.00表示一點不相似，1.00表示完全相似。可以用下面的測試用例來實現函數級別的黑盒測試，特別聲明，這里不需要了解函數內部是如何實現的，只關心函數輸入與輸出的對應關系。測試用例如下：

● calcualteSimilty("a", "a"); //1.00

● calcualteSimilty("a", "z"); //0.00

● calcualteSimilty("azza", "zaaz"); //0.00

● calcualteSimilty("", ""); //1.00

● calcualteSimilty(null, null); //1.00

● String s="this is a very long string, include 100 words…"calcualteSimilty(s, s); //1.00

● calcualteSimilty("中國人", "外國人"); //0.67

● calcualteSimilty("@", "@"); //1.00

● calcualteSimilty("", " "); //1.00

● …

圖1-3 單元測試

5．單元測試（Unit Testing）

單元測試又稱組件測試，是對單個軟件組件進行的軟件測試【與IEEE610一致】。單元測試一般采用軟件測試驅動與樁的技術。

案例1-2：單元測試。

對圖1-3的模塊B進行單元測試如下。

B模塊的代碼可能如下：

    int B (int a, int b){
        …
        int x= D (a);
        ….
        int y= E(b);
        ….
        return x+y;
    }

B的驅動函數是指通過頁面或者編譯器可以調用的函數，通常設置為主函數，即main()函數。

    main (){
        int a=3;
        int b=5;
        int c=B(a, b);
    }

StubD, StubE為B的樁函數。樁函數為模擬被測單元的調用模塊，由于測試的是模塊B，所以樁函數可以簡單地返回一個符合要求類型的變量。

    int  StubD(int x){
        return x+5；
    }
    int  StubE(int x){
        return x+6；
    }

這樣，B函數就可改為：

    int B (int a, int b){
        ….
        int x= StubD (a);
        ….
        int y= StunE(b);
        ….
        return x+y;
    }

這里，單元測試主要驗證模塊B的功能，在驗證過程中可以采用等價類、邊界值、錯誤輸入等方法來實現。

對于軟件測試樁，現在有許多新的技術，如圖1-4所示。

圖1-4 軟件測試樁

這些新技術的介紹不在本書的范疇中，有興趣的讀者可以自己查找相關的文獻。

6．集成測試（Integration Testing）

集成測試是一種暴露接口以及集成組件/系統間交互時存在缺陷的軟件測試方法。集成方法有自上而下測試法、自下而上測試法、自上而下和自下而上混合（又稱三明治）測試法3種。

案例1-3：集成測試。

下面來看一個程序架構，如圖1-5所示。

圖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集成。

● 三明治集成：

（1）模塊6與模塊7集成，模塊6與模塊8集成；

（2）模塊3與模塊5集成，模塊3與模塊6集成；

（3）模塊1與模塊2集成，模塊1與模塊3集成；

（4）模塊2與模塊4集成，模塊2與模塊5集成；

（5）模塊3與模塊5集成，模塊3與模塊6集成。

7．系統測試（System Testing）

系統測試是軟件測試的主要部分，是利用各種方法驗證軟件是否滿足產品顯性或者隱形需求的活動。

8．驗收測試（Accept Testing）

驗收測試一般由用戶/客戶或者運維人員進行確認是否可以接受一個系統的驗證性的軟件測試。可根據用戶需求、業(yè)務流程進行的正式的軟件測試，以確保系統符合所有驗收準則（與IEEE 610一致）。驗收測試可以分為Alpha測試和Beta測試。

（1）Alpha測試

Alpha測試是由潛在用戶或者獨立的軟件測試團隊在開發(fā)環(huán)境下或者模擬實際操作環(huán)境下進行的軟件測試，通常在開發(fā)組織外進行，是對現貨軟件（off-the-shelf software）進行內部驗收測試的一種方式。

（2）Beta測試

Beta測試是潛在現有用戶/客戶在開發(fā)組織外的場所，沒有開發(fā)工程師參與的情況下進行的軟件測試，檢驗軟件是否滿足客戶及業(yè)務需求。這種軟件測試經常是為了獲得市場反饋對現貨軟件進行外部驗收測試的一種形式。

9．靜態(tài)測試（Static Testing）

靜態(tài)測試是對組件/系統進行規(guī)格或實現級別的測試，但并不執(zhí)行這個軟件，如代碼評審或靜態(tài)代碼分析等。

10．動態(tài)測試（Dynamic Testing）

動態(tài)測試通過運行軟件的組件或系統來測試軟件。

更多的軟件測試術語，請參見參考文獻【33】。

1.1.3 軟件工程模型

討論軟件測試學，不得不涉及軟件工程模型，因為軟件測試學與軟件工程學的發(fā)展是依依相關、相輔相成的。根據目前比較先進的軟件測試理念，軟件測試應該貫穿于軟件工程的整個過程中。下面介紹幾種軟件工程模型。

圖1-6 瀑布模型

1．瀑布模型

圖1-6為瀑布模型。這個模型是最經典的軟件工程模型，包括“計劃”->“需求分析”->“設計”->“編碼”->“測試”->“運行維護”這幾個階段。

但是，這個模型存在比較嚴重的缺點。

（1）不可反復及不適用于需求變更比較頻繁的情況。由于瀑布模型從業(yè)務建模到運行維護一脈相承，不可以反復。而現代軟件項目中，需求變更是無處不在的：“唯一不變的是需求變更”。若運用這種模型，只要項目需求發(fā)生變化，就要把原有的設計打翻，重新進行系統分析，概要設計，詳細設計等。

（2）用戶很難在項目初期了解項目狀態(tài)：由于用戶在項目初期很難提出明確的需求，而利用瀑布模型只有到編碼結束，軟件測試工程師才可介入軟件測試，客戶才可以看到是否是他們需要的產品，在此之前這些產品他們不完全了解，有時需要補充，有時客戶也有可能推翻他們原本的需求，提出新的需求，這樣往往會給客戶方、開發(fā)方帶來很多麻煩。

2．迭代模型和螺旋模型

圖1-7為迭代模型。瀑布模型和迭代模型往往在概念上區(qū)別不明顯。事實上，這兩個模型在思想本質上是一致的。它將客戶的需求按照用戶的重要等級和模塊自身的等級進行安排，從最開始進行分析、設計、編碼、測試，然后再進入下一輪迭代。用戶只要在每一輪結束后，就可以看到產品的一些雛形，從而可以進行需求變更和提出下一輪建議。該模型初期開發(fā)工作比較少，用戶又可以及時提出下一輪更詳細的需求和變更，所以這樣的模型往往利于軟件公司產品的研發(fā)。這類模型有著名的RUP模型、快速開發(fā)模型以及現在比較流行的敏捷開發(fā)等，它們都遵循迭代的思想。

圖1-7 迭代模型

注：本書中擴展閱讀大部分來自于百度百科，請見參考文獻【21】。

1.1.4 軟件測試模型

1．V模型

圖1-8所示為V模型測試。

圖1-8 V模型測試

● 單元測試相對于編碼進行，這一步往往由開發(fā)工程師執(zhí)行。

● 集成測試相對于詳細設計，將模塊以由上到下、由下到上或混合方式進行逐步集成。測試軟件模塊與模塊、類與類之間的關聯性。

● 系統測試相對于概要設計，軟件測試工程師站在整體的立場上對系統進行全面的軟件測試工作。

● 驗收測試是用戶對產品進行的測試，一般分為Alpha測試和Beta測試。驗收測試往往由系統維護人員或者用戶來完成，需要完全站在用戶的立場上進行測試，測試環(huán)境也要盡可能與用戶的實際環(huán)境保持一致，大多數時候，需要到用戶現場去進行驗收測試工作。

2．W模型

圖1-9所示為W模型測試。W模型其實是V模型的變種，它提倡的主要思想是軟件前置測試理念（即軟件測試需要貫穿軟件研發(fā)的始終）。所以，W模型又稱雙V模型或前置模型。在需求、設計和編碼階段對產生的工件進行文檔評審，一個目的是提出自己的建議和意見，另外一個目的是盡可能理解產品的需求和實現方式。使用前置軟件測試法，Bug在軟件前期就可以發(fā)現，從而降低軟件開發(fā)的成本。

圖1-9 W模型測試

3．X模型

圖1-10為X模型測試。X模型將軟件系統分為若干模塊，對每個模塊進行單元測試、集成測試以及系統測試，然后統一對模塊進行集成測試。事實上，這里已經提出了“探索式軟件測試”的概念，在本書第3章會詳細介紹探索式測試。

圖1-10 X模型測試

1.1.5 軟件測試方法

軟件測試方法見表1-1。

表1-1 軟件測試方法

代碼評審中有一個部分是對編碼規(guī)范的檢查。另外，代碼評審可以通過人工的方式來實現，也可以借助代碼評審工具，如在本書第二篇7.1.1節(jié)“普通軟件測試工具推薦”提及的Checkstyle、Findbugs、PMD、Android Lint等工具。

    L_M_BV_32:=TBD.T_ENTIER_32S  ((1.0/C_M_LSB_BV) ＊ (G_M_INFO_DERRIVE());
    if L_M_BV_32 >32767 then
    P_M_DERIVE(T_ALG.E_BV) :=16#7FFF#;
    elseif L_M_BV_32 <-32767 then
    P_M_DERIVE(T_ALG.E_BV) :=16#8000#;
    else
    P_M_DERIVE(T_ALG.E_BV):=UC_16S_EN_16NS(TDB.T_ENTIER_16S(L_M_BV_32));
    end if;
    P_M_DERIVE(T_ALG.E_BH):=UC_16S_EN_16NS(TDB.T_ENTIER_16S(1.0/C_M_LSB_BH)＊G_M_INFO_DRIVER(T_ALG.E_GH)));

1.1.6 軟件測試步驟

圖1-11描述了軟件測試步驟，具體如下。

圖1-11 軟件測試步驟

（1）軟件測試計劃。

（2）軟件測試分析。

（3）軟件測試設計。

（4）軟件測試實施。

（5）軟件測試執(zhí)行。

（6）評估出口準則和報告。

（7）軟件測試結束活動。

具體內容讀者可以參見參考文獻【13】第二章進行更深入的學習。

1.1.7 軟件缺陷管理

1．缺陷管理流程

根據SEI TSP國際標準，缺陷管理流程可以定義如下。

研發(fā)計算機必須分為開發(fā)機、測試機和發(fā)布機。開發(fā)工作在開發(fā)機上進行，軟件測試工作（系統測試）在測試機上運行，最后產品驗收和運行在發(fā)布機上運行，發(fā)布機器可能在客戶處。

（1）每輪測試開始，開發(fā)部門提出本次測試重點，開發(fā)機上的版本同步到軟件測試機上（或通過配置管理工具實現同步）。

（2）軟件測試工程師進行冒煙軟件測試，如果冒煙測試沒有通過，則退回給開發(fā)部門，等待開發(fā)部門重新提交軟件測試任務，返回第（1）步。

（3）冒煙測試通過，測試工程師繼續(xù)執(zhí)行測試活動，包括傳統正規(guī)測試和基于經驗的測試，如探索式軟件測試等。發(fā)現Bug，記錄在缺陷管理工具中。

（4）開發(fā)工程師修改被確認的Bug（狀態(tài)為Assigned）。

（5）當軟件測試工程師認為軟件測試結束，大部分Bug都發(fā)現完畢，開發(fā)機上版本再一次同步到軟件測試機上。

（6）軟件測試工程師對Bug進行復測，如果問題仍舊存在，則標記為Reopen，否則標記為Closed。此時還要對以前測試過的功能進行回歸測試。

（7）開發(fā)工程師對于Reopen的缺陷進行修改。

（8）當一輪軟件測試達到出口標準，軟件測試機上的版本同步到發(fā)布機上，軟件測試任務完成；否則返回第（5）步。

在本書第三篇第13.9節(jié)“軟件缺陷管理流程”會給出更為詳細的描述。

2．缺陷嚴重等級

由于采用的缺陷管理工具不同，缺陷嚴重等級的級別也會有差異。

Blocker:（阻礙的）

? 阻礙開發(fā)和/或軟件測試工作，冒煙測試沒有通過，不能進行正常的軟件測試工作。

Critical:（緊急的）

? 系統無法測試，或者系統無法繼續(xù)操作，應用系統異常中止。

? 對操作系統造成嚴重影響，系統死機，被測程序掛起，不響應等情況。

? 造成重大安全隱患情況，如機密性數據的泄密。

? 功能沒有實現，無法進行某一功能操作，影響系統使用。

Major:（重大的）

? 功能基本上能實現，但在特定情況下導致功能失敗。

? 導致輸出的數據錯誤，如：數據內容出錯、格式錯誤、無法打開。

? 導致其他功能模塊無法正常執(zhí)行。

? 功能不完整或者功能實現不正確。

? 導致數據最終操作結果錯誤。

Normal:（普通的）

? 功能部分失敗，對整體功能的實現基本不造成影響。

Minor:（較小的）

? 鏈接錯誤、系統出錯提示或沒有捕獲系統出錯信息、數據的重要操作（增刪查改）沒有提示、出現頻率極低，會對功能實現造成非致命性的影響。

Trivial:（外觀的）

? 產品外觀上的問題或一些不影響使用的小毛病，如菜單或對話框中的文字拼寫或字體問題等。

Enhancement（改進的）

? 對系統產品的建議或意見。

3．缺陷修改優(yōu)先級

由于缺陷管理工具的差異，缺陷修改優(yōu)先級別也會有差異。

P5：嚴重級別比較高，影響軟件測試進行或者系統無法繼續(xù)操作。

P4：對系統操作有影響，但不需要馬上修改。

P3：頁面缺陷（不屬于定義的缺陷范圍）或者建議。

P2：準備在下一輪軟件測試前修改完畢。

P1：準備在下一版本中修改。

4．缺陷書寫規(guī)則

關于缺陷管理工具將在本書第二篇第10章“缺陷管理工具”進行詳細描述。

1.1.8 測試用例

1．測試用例格式

測試用例格式見表1-2。

表1-2 測試用例格式

● 編號：“Chinafi_”+***+“_”+XXX。

? Chinafi：固定的開始字符。

? ***：模塊名。

? XXX:3位0～9的數字。

● 前置條件：完成此項測試，需要達到的前提條件。如測試登錄，前置條件為注冊的基本功能必須實現。

● 說明：測試項目的描述。

● 項目編號：一個測試中可包括幾個項目，每個項目的編號。

● 測試步驟：完成測試的具體步驟描述。

● 期待結果：對于一些重要步驟的頁面期待的顯示結果，每一項最后一步的期待結果是必須書寫的。

● 概要說明：對于測試過程中的一些說明注解。

2．測試用例案例

案例1-4：測試用例的書寫。

環(huán)境：瀏覽器、Web服務器（Tomcat）、MySQL數據庫。

需求：一個表單信息，用于網站用戶注冊個人信息，主要包括姓名、登錄名、密碼（大于5個字符，必須包含數字和特殊字符）、確認密碼、Email信息、手機、地址，其中登錄名、密碼、確認密碼、Email信息是必填的，其他信息可以選填。請根據需求書寫測試用例（不考慮長度測試）。用戶注冊界面如圖1-12所示，用戶注冊測試用例見表1-3。

圖1-12 用戶注冊界面

表1-3 用戶注冊測試用例

續(xù)表

當然，要寫好測試用例，首先要學好如何進行測試設計，后續(xù)章節(jié)中會進行詳細介紹。

1.1.9 軟件測試類型

關于軟件測試類型，可以參照ISO 225000（替代ISO 9126）軟件質量模型，如圖1-13所示。

圖1-13 ISO225000（替代ISO 9126）軟件質量模型

1．功能測試

功能測試對測試對象側重于所有可直接追蹤到用例或業(yè)務功能和業(yè)務規(guī)則的軟件測試需求。這種軟件測試的目標是核實數據的接收、處理和檢索是否正確，以及業(yè)務規(guī)則的實施是否恰當。此類軟件測試可以通過黑盒測試技術或白盒測試技術來實現，該技術通過圖形用戶界面（GUI）或其他方式與應用程序進行交互，并對交互的輸出或結果進行分析，以此核實應用程序及其內部功能。

案例1-5：功能測試。

圖1-14所示是電子商務計價系統界面。隨著電子商務網站越來越多，某些商品在節(jié)假日可以打折，會員可以享受會員價，購買物品達到一定數量或金額后，也可以打折或者免運費。這些條件給計價系統的準確性帶來很復雜的功能，軟件測試工程師應該設計好各種測試用例，來檢測系統的功能。

圖1-14 電子商務計價系統界面

2．易用性測試（用戶體驗性測試）

易用性測試指的是在指定條件下使用時，軟件產品被理解、學習、使用和吸引用戶的能力。

● 這里的用戶包括。

（1）操作人員。

（2）最終用戶。

（3）受該軟件的使用影響或者依賴于該軟件的間接用戶。

● 易用性質量特性。

? 易理解性。

? 易學性。

? 易操作性。

? 吸引性。

● 易用性測試采取技術。

? 人工檢查 審查或者評審。

? 問卷調查 通過問卷調查方式得到用戶使用軟件的反饋。

? 驗證和確認 針對軟件產品的實現，進行驗證和確認。

? A/B軟件測試法。

案例1-6：易用性測試。

如圖1-15所示，對于安卓系統卸載APP軟件，必須進入設置界面，找到軟件，再單擊【卸載】按鈕才可以卸載；而蘋果系統只要在界面上長按APP軟件圖標3s，點左上角的叉，即可刪除。由此可見，蘋果系統的卸載APP的軟件易用性明顯優(yōu)于安卓系統。另外，現在我們給易用性測試起了一個更好聽的名字，叫“軟件用戶體驗性測試”。

圖1-15 安卓系統與蘋果系統的卸載APP功能

3．可靠性測試

可靠性測試的目的之一是對軟件成熟度在時間上的統計度量指標進行監(jiān)控，并將其與既定目標比較。可靠性對應3個指標，如圖1-16所示。

（1）平均失效間隔時間MTBF（這次失效到下次失效的時間）。

（2）平均修復時間MTTR（本次失效修復的時間）。

（3）平均失效前時間MTTF（修復完畢到下次失效的時間）。

圖1-16軟件可靠性

通過圖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測試）：通過增加負載（一般為并發(fā)用戶或數據庫容量）來評估組件或系統性能的軟件測試方法。

測試方法：以一定的負載作為起點，觀察系統吞吐率，不斷加大負載個數，直到吞吐率達到飽和，這時負載為該產品這個功能的最大負載。

（3）壓力測試：評估系統處于一定的負載下（最大負載乘以一定百分比），讓系統運行一段時間，觀察系統各項指標是否正常。

案例1-8：Web系統的性能測試。

在Web頁面對用戶登錄功能進行負載測試，獲取最大負載數，并以最大負載的80%，持續(xù)運行48小時進行壓力測試，觀察系統各項指標是否正常運行。

關于性能測試，本篇第5.1節(jié)將會詳細講解。

5．安全性測試

軟件安全性包括功能安全性和信息安全性，本節(jié)只考慮信息安全性。

信息安全性：指的是軟件產品保護信息和數據的能力，及未授權的人員或者系統不能閱讀或者修改這些信息和數據，而不拒絕授權人員或者系統對它們進行訪問。信息安全性測試的關注點：

● 對應用程序/數據進行未授權的復制；

● 未授權的訪問控制；

● 出入域溢出導致的緩存區(qū)溢出；

● 服務拒絕，阻止用戶與應用程序的交互；

● 在網絡上竊聽數據傳輸獲取敏感信息；

● 破解保護敏感信息的加密代碼；

● 邏輯炸彈/復活節(jié)彩蛋。

信息安全性分類：

● 與用戶接口相關；

● 與文件系統相關；

● 與操作系統相關；

● 與外部軟件相關。

信息安全性測試方法：

● 使用工具創(chuàng)建系統概況或網絡圖；

● 使用多種工具進行漏洞掃描；

● 獲得信息研制“攻擊方案”；

● 根據安全專家（白帽子黑客）的建議進行多種攻擊。

案例1-9：黑客侵入。

某公司開發(fā)一套網上答題系統，題目均為單項選擇題，可以選擇A、B、C、D中的任意一項，每一周評選最高得分者，可以在電視節(jié)目中參加一個益智類的欄目。為了防止網友對所有題選擇某個相同的答案（如對所有題都選擇D），或者有規(guī)律的選擇（如選題都是A、C、D、B、A、C、D、B…）在前端JavaScript程序里做了控制：如果連續(xù)5次選擇同一個答案或者有規(guī)律地選擇的答題者將被答題系統自動踢出。該程序經過嚴格測試后上線使用。可是，上線不到4周，發(fā)現每周最高得分者均為一個姓張的先生，查看其答案，竟然所有題目都答成B，這讓開發(fā)工程師感到很奇怪。兩周后，公司的開發(fā)經理在網站群聊中找到這位張先生，張先生告訴開發(fā)經理，系統在前端JavaScript做了控制，但是在后端JavaBean中沒進行控制，所以他自己寫了個程序繞過前端，這個程序是一個死循環(huán)，7×24小時一直發(fā)送答案B給后端系統。

案例1-10：XSS注入。

如果沒有對HTML特殊字符進行處理（HTML特殊字符見附錄A），在瀏覽頁面時會運行JavaScript代碼，如果輸入的JavaScript代碼具有惡意獲得用戶信息的功能，就會產生安全問題，如輸入：“ <script type="text/javascript">var sys = getBrowserInfo(); document.write (sys.browser + "的版本是：" + sys.ver); </script>”，頁面在顯示時就會把用戶當前的瀏覽器版本和型號都顯示出來。這樣，黑客就可以根據獲取的信息采取進一步攻擊。

案例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語句變?yōu)閟elect count(*) from user where name='Jerry' and password='2222' or 1=1; -- ', where語句后的條件永遠為真，所以判斷語句count(*)一定不為零。

6．相容性測試

相容性測試又稱兼容性測試，指的是軟件產品與一個或者多個規(guī)定的系統之間進行交互的能力。該項測試用于驗證軟件產品或者應用程序在各種指定的目標環(huán)境下是否可以正常工作，主要包括：

（1）硬件；

（2）軟件；

（3）中間件；

（4）操作系統；

（5）其他。

兼容性測試包括：輸入的兼容性、輸出的兼容性以及自適應性。

案例1-12：設備接口兼容性。

圖1-17 北向接口和南向接口

某些設備廠商生產出的產品需要被其他廠商調用，或者調用其他廠商的接口。在這些廠商中，北向接口與南向接口經常被提及。北向接口和南向接口如圖1-17所示。

● 北向接口：我的設備使用其他設備的功能，這個接口為北向接口。

● 南向接口：其他設備使用我的設備的功能，這個接口為南向接口。

可以看出，如果用單元測試做一個比喻，北向接口設備相當于驅動函數，而南向接口設備相當于樁函數。

案例1-13：屏幕分辨率測試。

屏幕分辨率測試屬于兼容性測試的范疇，要求測試在不同屏幕分辨率下。界面的美觀程度，可分為800×600、1024×768、1152×864、1280×768、1280×1024、1200×1600等，不同字號下的測試。

7．可移植性測試

可移植性測試通常和軟件移植到某個特定的運行環(huán)境中的難易程度相關，包括第一次建立或從現有環(huán)境移植到另一個環(huán)境。這種測試類型包括：

（1）可安裝性測試；

（2）適應性測試；

（3）可替換性測試。

案例1-14：網絡設備移植測試。

某軟件從網絡設備A移植到網絡設備B中，發(fā)生了錯誤。后經過排查，結論是網絡設備A的IP地址用的是用戶地址序列（高位在前，低位在后）。而網絡設備B的IP地址用的是網絡地址序列（低位在前，高位在后）。如IP地址是192.168.0.8，轉化為十六進制為C0.A8.00.08，在設備A上是用戶地址序列為C0A80008。在設備B上是網絡地址序列為0800A8C0。

故障轉移和恢復測試屬于可移植性測試范疇，它可確保軟件測試對象能成功完成故障轉移，并能從意外數據損失或數據完整性破壞的各種硬件、軟件或網絡故障中恢復。

● 故障轉移測試可確保對于必須持續(xù)運行的系統，一旦發(fā)生故障，備用系統就將不失時機地“頂替”發(fā)生故障的系統，以避免丟失任何數據或事務。

● 恢復測試是一種對抗型測試過程。在這種軟件測試中，將把應用程序或系統置于極端（或者是模擬的極端）的條件下，使其產生故障（如設備輸入/輸出（I/O）故障或無效的數據庫指針和關鍵字）。然后調用恢復進程，并監(jiān)測和檢查應用程序和系統，核實應用程序或系統以及數據已得到正確恢復。

安裝、卸載測試也屬于移植性測試，安裝測試有兩個檢查點。

（1）確保該軟件在正常情況和異常情況的不同條件下（如進行首次安裝、升級、完整的或自定義的安裝）都能進行安裝。異常情況包括磁盤空間不足、缺少目錄創(chuàng)建權限等。

（2）核實軟件在安裝后可立即正常運行。

卸載測試有4個檢查點：

（1）卸載是否正常、卸載后的軟件是否能夠運行；

（2）核實卸載軟件的數據與文件都刪除干凈；

（3）卸載后的軟件重新安裝是沒有問題的；

（4）卸載后的軟件不影響其他軟件的工作。

8．可維護性測試

可維護性測試指的是軟件產品可被修改的能力，包括糾正、改進或者軟件對環(huán)境、需求和功能規(guī)格說明變化的適應能力。

案例1-15：代碼可維護性測試。

某公司生產了ERP產品給A企業(yè)，3年后由于公司ERP流程發(fā)生變化，需要在原來基礎上進行更新，但是由于3年來近一半的開發(fā)工程師發(fā)生了變動，代碼注釋又不規(guī)范，給新功能開發(fā)帶來很大困難，這就產生了代碼可維護性的問題。為了解決這個問題，軟件工程師把代碼進行了如下優(yōu)化，如圖1-18所示。

圖1-18 代碼的可維護性

要做好代碼的可維護性，最好是在編碼后期做好嚴格的代碼審核（Code Review）工作。

案例1-16：產品的可測試性。

某B/S產品決定采用WebDriver進行測試，由于HTML代碼中的元素都沒有id、name或者class屬性，如：

    <input type="button" value="點擊">

如果采用手工測試，是沒有關系的，但是采用自動化測試，就帶來很大困難，于是把HTML代碼改為：

    <input type="button" value="點擊" name="click" id="my_click">

關于WebDriver的介紹參看本書第二篇第11.2節(jié)“Selenium和WebDriver工具入門”介紹。

在軟件測試工作中除了關注ISO 22500標準外，我們還經常用到以下測試方法。

9．數據和數據庫完整性測試

在項目名稱中，數據庫和數據庫進程應該作為一個子系統來進行軟件測試。測試這些子系統時，不應將測試對象的用戶界面用作數據的接口。對于數據庫管理系統（DBMS），需要進行深入研究，以確定可以支持以下測試的工具和技術。數據庫測試包括以下幾個方面。

● 數據庫設計測試。

● SQL代碼規(guī)范測試：可使用工具為SQL BPA。

● SQL語句效率測試。

● SQL語句兼容性測試：SQL語句標準FIPS 127-2，基于SQL-92標準。

10．本地化測試

本地化測試是指為各個地方開發(fā)產品的軟件測試，如英文版、中文版等，包括程序是否能夠正常運行，界面是否符合當地習俗，快捷鍵是否正常起作用等，特別要測試在A語言操作系統環(huán)境下運行B語言軟件（如在英文版的Windows操作系統下試圖運行中文版的程序），運行是否正常。

11．文字測試

文字測試主要測試文字是否拼寫正確、是否易懂、不存在二義性、沒有語法錯誤；文字與內容（包括圖片、文字）是否有出入等。

12．發(fā)布測試

主要在產品發(fā)布前對一些附帶產品，如說明書、廣告稿等進行軟件測試。發(fā)布測試在驗收測試中進行。

說明書測試

說明書測試主要為語言檢查、功能檢查、圖片檢查。

● 語言檢查：檢查說明書語言是否正確，用詞是否易于理解。

● 功能檢查：功能是否描述完全，或者描述了并沒有的功能等。

● 圖片檢查：檢查圖片是否正確。

宣傳材料測試

主要測試軟件產品中附帶的宣傳材料中的語言、描述功能、圖片。

產品說明書的測試

產品說明書是用戶（特別是一些新用戶）了解產品的一個有力工具。所以，軟件測試工程師應該對產品說明書中的每一條功能進行嚴格核實。除此之外，還應從用戶的角度思考，考慮是否將注意事項告訴了用戶，產品說明書是否便于閱讀，產品說明書的書寫邏輯是否合理以及說明書中章節(jié)的前后順序是否需要進行調整。

產品廣告

產品廣告往往是由市場人員為了推銷產品而書寫的，對于廣告中提及的功能，我們要與市場和銷售人員進行及時溝通，弄清楚每條語句是在哪個模塊的哪個功能點上實現的，然后在產品上具體操作一下，看是否是那么一回事。廣告具有一定的夸大性，這在所難免。但是，對于夸大過份的內容，軟件測試工程師有提出修改建議的責任。

1.1.10 軟件測試曲線

眾所周知軟件的Bug不可能為零，但一般隨著時間的推移，Bug數逼近于零。軟件測試曲線如圖1-19所示。

圖1-19 軟件測試曲線

這里，橫坐標是時間，縱坐標是還沒有發(fā)現的Bug數。項目開始前，Bug為無窮大，隨著時間的推移，Bug趨于零，但是不會等于零。

另外一條曲線的橫坐標是時間，縱坐標是已經發(fā)現的Bug數。項目開始前，Bug為零，隨著時間的推移，Bug趨于一個固定值，但是不會等于這個值。

一般來說，兩條曲線的交匯處為產品發(fā)布的最好時候，避免過度軟件測試，也避免軟件測試不夠。

1.1.11 軟件的殺蟲劑現象

由于每個軟件測試工程師的思路不同，測試的側重點也可能不同，所以，不同的測試工程師即使執(zhí)行相同的測試用例，發(fā)現的Bug也可能不同。例如，A測試某個模塊，第一天到第四天測到許多Bug，但是從第五天開始幾乎報不出Bug了。第七天換了B, B又測試出許多Bug，但不能簡單地說A的水平差，B的水平高。其實，這是由于A對這個模塊產生了抗藥性造成的，這就是軟件測試學中的殺蟲劑現象，可用圖1-20表示。

圖1-20 軟件測試的殺蟲劑現象

為避免殺蟲劑現象，建議每次進行輪流測試，最好安排不同的工程師進行不同模塊的測試工作。

案例1-17：根據軟件殺蟲劑現象進行測試計劃調整。

某軟件項目有測試員甲、乙、丙、丁4人，項目模塊為A、B、C、D、E、F、G七個模塊，測試周期為3周，為了避免軟件殺蟲劑現象，測試經理做了分工，見表1-4。這樣保證了每一個模塊至少有兩個人經過測試。

表1-4 工作任務的分工