基于新信息技術(shù)的軟件測試技術(shù) 課件 蘇秀芝 第6-10章 測試報告和測試評測-測試管理工具TestLink

第6章測試報告和測試評測6.1軟件缺陷6.2分離再現(xiàn)軟件缺陷6.3正確面對軟件缺陷6.4軟件缺陷生命周期及處理技巧6.5報告軟件缺陷6.6軟件缺陷的跟蹤管理6.7測試總結(jié)報告6.8測試的評測6.9質(zhì)量評測

6.1軟件缺陷

6.1.1軟件缺陷簡介軟件缺陷(Defect)常常又被叫做Bug。所謂軟件缺陷，簡單說就是存在于軟件(文檔、數(shù)據(jù)、程序)之中的那些不希望或不可接受的偏差，會導(dǎo)致軟件產(chǎn)生質(zhì)量問題。

只要符合下面5個規(guī)則中的一條，就叫做軟件缺陷：

(1)軟件沒有實現(xiàn)產(chǎn)品規(guī)格說明中所要求的功能；

(2)出現(xiàn)了產(chǎn)品規(guī)格說明中指明不應(yīng)該出現(xiàn)的錯誤；

(3)軟件實現(xiàn)了產(chǎn)品規(guī)格說明中沒有提到的功能模塊；

(4)軟件沒有實現(xiàn)產(chǎn)品規(guī)格說明中沒有明確提及但應(yīng)該實現(xiàn)的目標；

(5)軟件難以理解，不容易使用，運行緩慢，或從測試員的角度看，最終用戶會認為不好。

例如，計算器(圖6.1)在測試中有如下問題，就認為存在缺陷。圖6.1計算器

①計算器的產(chǎn)品規(guī)格說明應(yīng)能準確無誤地進行加、減、乘、除運算。如果按下加法鍵，沒什么反應(yīng)，就是第一種類型的缺陷；若計算結(jié)果出錯，也是第(1)種類型的缺陷。

②產(chǎn)品規(guī)格說明書還可能規(guī)定計算器不會死機，或者停止反應(yīng)。如果隨意敲鍵盤，則計算器停止接受輸入，這就是第(2)種類型的缺陷。

③如果使用計算器進行測試，發(fā)現(xiàn)除了加、減、乘、除之外還可以求平方根，但是產(chǎn)品規(guī)格說明中沒有提及這一功能模塊，這是第(3)種類型的缺陷。

④在測試計算器時若發(fā)現(xiàn)電池沒電會導(dǎo)致計算不正確，而產(chǎn)品說明書中是假定電池一直都有電的，則這就是第(4)種類型的錯誤。

⑤軟件測試員如果發(fā)現(xiàn)某些地方不對，比如測試員覺得按鍵太小、“=”鍵布置的位置不好按、在亮光下看不清顯示屏等，無論什么原因，都要認定為缺陷。

6.1.2軟件缺陷產(chǎn)生的原因

從軟件本身、團隊工作和技術(shù)問題等角度分析，造成軟件缺陷的主要因素有：

(1)需求不清晰，導(dǎo)致設(shè)計目標偏離客戶的需求，從而引起功能或產(chǎn)品特征上的缺陷。

(2)系統(tǒng)結(jié)構(gòu)非常復(fù)雜，而又無法設(shè)計成一個很好的層次結(jié)構(gòu)或組件結(jié)構(gòu)，結(jié)果導(dǎo)致意想不到的問題或系統(tǒng)維護、擴充上的困難；即使設(shè)計成良好的面向?qū)ο蟮南到y(tǒng)，由于對象、類太多，很難完成對各種對象、類相互作用的組合測試，而隱藏著一些參數(shù)傳遞、方法調(diào)用、對象狀態(tài)變化等方面問題。

(3)對程序邏輯路徑或數(shù)據(jù)范圍的邊界考慮不夠周全，漏掉某些邊界條件，造成容量或邊界錯誤。

(4)對一些實時應(yīng)用，要進行精心設(shè)計和技術(shù)處理，保證精確的時間同步，否則容易引起時間上不協(xié)調(diào)、不一致性帶來的問題。

(5)沒有考慮系統(tǒng)崩潰后的自我恢復(fù)或數(shù)據(jù)的異地備份、災(zāi)難性恢復(fù)等問題，從而存在系統(tǒng)安全性、可靠性的隱患。

(6)系統(tǒng)運行環(huán)境復(fù)雜，不僅用戶使用的計算機環(huán)境千變?nèi)f化，包括用戶的各種操作方式或各種不同的輸入數(shù)據(jù)，容易引起一些特定用戶環(huán)境下的問題；在系統(tǒng)實際應(yīng)用中，數(shù)據(jù)量很大，從而會引起強度或負載問題。

(7)由于通信端口多、存取和加密手段的矛盾性等，會造成系統(tǒng)的安全性或適用性等問題。

(8)新技術(shù)的采用，可能涉及技術(shù)或系統(tǒng)兼容的問題，事先沒有考慮到。

6.1.3軟件的有效簡述規(guī)則

軟件缺陷簡述是軟件缺陷報告的基礎(chǔ)部分，也是測試人員就一個軟件問題與開發(fā)小組交流的最初且最好的機會。準確報告軟件缺陷是非常重要的，因為：

(1)清晰準確的軟件缺陷簡述可以減少軟件缺陷從開發(fā)人員處返回的次數(shù)；

(2)可提高軟件缺陷修復(fù)的速度，使每一個小組能夠有效地工作；

(3)可提高測試人員的信任度，得到開發(fā)人員對清晰的軟件缺陷簡述的有效響應(yīng)；

(4)加強開發(fā)人員、測試人員和管理人員的協(xié)同工作，讓他們可以更好地工作。

在多年實踐的基礎(chǔ)上，我們積累了較多的軟件缺陷的有效簡述規(guī)則，主要有：

1．單一準確

2．可以再現(xiàn)

3．完整統(tǒng)一

4．短小簡練

5．特定條件

6．補充完善

7．不做評價

6.1.4軟件缺陷的屬性

軟件缺陷的屬性包括缺陷標識、缺陷類型、缺陷嚴重程度、缺陷優(yōu)先級、缺陷狀態(tài)、缺陷起源、缺陷來源、缺陷根源。

(1)缺陷標識：標記某個缺陷的唯一的標識，可以使用數(shù)字序號表示。

(2)缺陷類型：根據(jù)缺陷的自然屬性劃分缺陷種類，具體類型見表6-1。

(3)缺陷嚴重程度：因缺陷引起的故障對軟件產(chǎn)品的影響程度，具體等級見表6-2。

(4)缺陷優(yōu)先級：缺陷必須被修復(fù)的緊急程度，見表6-3。

(5)缺陷狀態(tài)：缺陷通過一個跟蹤修復(fù)過程的進展情況，具體狀態(tài)見表6-4。

(6)缺陷起源：缺陷引起的故障或事件第一次被檢測到的階段，具體起源見表6-5。

(7)缺陷來源：缺陷所在的地方，如文檔、代碼等，具體來源見表6-6。

(8)缺陷根源：造成上述錯誤的根本因素，以尋求軟件開發(fā)流程的改進、管理水平的提高，具體根源見表6-7。

通常情況下，對于影響用戶使用或者影響產(chǎn)品美觀的軟件缺陷，附上圖片比較直觀，例如：

(1)當(dāng)產(chǎn)品中有一段文字沒有顯示完全，為了明確標識這段文字的位置，測試人員必須貼上圖片。

(2)在測試外國語言版本的時候，當(dāng)發(fā)現(xiàn)產(chǎn)品中有一段文字沒有翻譯，測試人員需要貼上圖片標識沒有翻譯的文字。

(3)在測試外國語言版本的時候，當(dāng)發(fā)現(xiàn)產(chǎn)品中有一段外國文字顯示亂字符，測試人員必須貼上圖片標識亂字符的外國文字。

(4)對于產(chǎn)品中的語法錯誤、標點符號使用不當(dāng)?shù)溶浖毕?，測試人員貼上圖片告訴開發(fā)人員缺陷在什么地方。

(5)在產(chǎn)品中運用錯誤的公司標志和沒有顯示圖片的重要等軟件缺陷，也需要附上圖片。

測試人員需要注意的是，有必要在圖片上用顏色標注缺陷的位置，給開發(fā)人員一目了然的效果，使得軟件缺陷盡快修復(fù)。

軟件缺陷的分離和再現(xiàn)考驗的是測試人員專業(yè)技能，測試人員要想有效報告軟件缺陷，就要對軟件缺陷以明顯、通用和再現(xiàn)的形式進行簡述。測試人員應(yīng)該設(shè)法找出縮小問題范圍的具體步驟。對測試人員有利的情況是，若建立起絕對相同的輸入條件，軟件缺陷就會再次出現(xiàn)，不存在隨機的軟件缺陷。

6.2分離再現(xiàn)軟件缺陷

軟件缺陷分離和再現(xiàn)的方法主要有：

(1)確保所有的步驟都被記錄。

(2)特定條件和時間。

(3)壓力和負荷、內(nèi)存和數(shù)據(jù)溢出相關(guān)的邊界條件。

(4)考慮資源依賴性，包括內(nèi)存、網(wǎng)絡(luò)和硬件共享的相互作用等。

(5)不能忽視硬件。

6.3正確面對軟件缺陷

1．并不是測試人員發(fā)現(xiàn)的每個缺陷都是必須修復(fù)的測試是為了發(fā)現(xiàn)程序錯誤，而不能保證程序沒有錯誤。不管測試計劃和執(zhí)行多么努力，也不是所有缺陷發(fā)現(xiàn)了就能修復(fù)。有些軟件缺陷可能會完全被忽略，還有一些可能推遲到后續(xù)版本中修復(fù)。

有些軟件缺陷不被修復(fù)的原因如下：

1)沒有足夠的時間

2)不算真正的軟件缺陷

3)修復(fù)的風(fēng)險太大

4)不值得修復(fù)

2．發(fā)現(xiàn)缺陷的數(shù)量說明不了軟件的質(zhì)量

軟件中不可能沒有缺陷，發(fā)現(xiàn)了很多缺陷對于測試工作來說，是很正常的事。缺陷的數(shù)量大，只能說明測試的方法很好，思路很全面，測試工作卓有成效。但以此來否認軟件的質(zhì)量，還是不具客觀性的。

反過來，如果在測試過程中發(fā)現(xiàn)的缺陷較少，但這些缺陷都集中表現(xiàn)為功能沒有實現(xiàn)、性能未達標、經(jīng)常引起死機或系統(tǒng)崩潰等現(xiàn)象，而且，大多數(shù)用戶在使用過程中都會發(fā)現(xiàn)這樣的問題，那么這樣的軟件就不能隨便發(fā)布。

6.4軟件缺陷生命周期及處理技巧6.4.1軟件缺陷生命周期概述生命周期是指一個物種從誕生到消亡所經(jīng)歷的不同的生命階段，軟件缺陷生命周期則指的是一個軟件缺陷被發(fā)現(xiàn)、報告到這個缺陷被修復(fù)、驗證直至最后關(guān)閉的完整過程。在整個軟件缺陷生命周期中，通常是以改變軟件缺陷的狀態(tài)來體現(xiàn)不同的生命階段。因此，對于一個軟件測試人員來講，需要關(guān)注軟件缺陷在生命周期中的狀態(tài)變化，來跟蹤項目進度和軟件質(zhì)量。一個簡單、優(yōu)化的軟件缺陷生命周期如圖6.2所示。圖6.2一個簡單、優(yōu)化的軟件缺陷生命周期

(1)發(fā)現(xiàn)—打開：測試人員找到軟件缺陷并將軟件缺陷提交給開發(fā)人員。

(2)打開—修復(fù)：開發(fā)人員再現(xiàn)、修復(fù)缺陷，然后提交給測試人員去驗證。

(3)修復(fù)—關(guān)閉：測試人員驗證修復(fù)過的軟件，關(guān)閉已不存在的缺陷。

在實際工作中，軟件缺陷的生命周期不可能像如上那么簡單，需要考慮其他各種情況，下面給出了一個復(fù)雜的軟件缺陷生命周期的例子，如圖6.3所示。

圖6.3一個復(fù)雜的軟件缺陷生命周期

綜上所述，軟件缺陷在生命周期中經(jīng)歷了數(shù)次的審閱和狀態(tài)變化，最終測試人員關(guān)閉軟件缺陷來結(jié)束軟件缺陷的生命周期。軟件缺陷生命周期中的不同階段是測試人員、開發(fā)人員和管理人員一起參與、協(xié)同測試的過程。軟件缺陷一旦發(fā)現(xiàn)，便進入測試人員、開發(fā)人員、管理人員的嚴密監(jiān)控之中，直至軟件缺陷生命周期終結(jié)，這樣即可保證在較短的時間內(nèi)高效率地關(guān)閉所有的缺陷，縮短軟件測試的進程，提高軟件質(zhì)量，同時減少開發(fā)、測試和維護成本。

6.4.2軟件缺陷處理技巧

以下列出處理軟件缺陷的基本技巧：

(1)審閱。

(2)拒絕。

(3)完善。

(4)分配。

(5)測試。

(6)重新打開。

(7)關(guān)閉。

(8)暫緩。

6.5報告軟件缺陷

一份軟件缺陷報告詳細信息見表6-8。

軟件缺陷的詳細簡述，如上所述，由三部分組成：操作/重現(xiàn)步驟、期望結(jié)果、實際結(jié)果，有必要再做進一步的討論：

(1)“步驟”提供了如何重復(fù)當(dāng)前缺陷的準確簡述，應(yīng)簡明而完備、清楚而準確。這些信息對開發(fā)人員是關(guān)鍵的，視為修復(fù)缺陷的向?qū)?，開發(fā)人員有時抱怨糟糕的缺陷報告，往往集中在這里。

(2)“期望結(jié)果”與測試用例標準或設(shè)計規(guī)格說明書或用戶需求等一致，達到軟件預(yù)期的功能。測試人員站在用戶的角度要對它進行簡述，它提供了驗證缺陷的依據(jù)。

(3)“實際結(jié)果”是測試人員收集的結(jié)果和信息，以確認缺陷確實是一個問題，并標識那些影響到缺陷表現(xiàn)的要素。

6.5.1報告軟件缺陷的基本原則

報告軟件缺陷的基本原則如下：

1．盡快報告軟件缺陷

軟件缺陷發(fā)現(xiàn)得越早，留下的修復(fù)時間就越多。

2．有效地簡述軟件缺陷

軟件缺陷的基本簡述是軟件缺陷報告中測試人員對問題陳述的一部分，并且是軟件缺陷報告的基礎(chǔ)部分。

3．每一個報告只針對一個軟件缺陷

如果在一個報告中有多個軟件缺陷，最容易出現(xiàn)的結(jié)果是，只有第一個軟件缺陷受到注意和修復(fù)，而其他軟件缺陷往往被忘記或者忽視。軟件缺陷應(yīng)該分別報告，而不是堆在一起。這說起來容易，但是做起來不那么簡單。

4．在報告軟件缺陷時不做任何評價

在軟件測試過程中，測試人員是在尋找程序錯誤，所以測試人員和程序員之間容易形成對立關(guān)系。軟件缺陷報告可能以軟件測試人員工作“成績報告單”的形式由程序員或開發(fā)小組其他人審查，因此軟件缺陷報告中不應(yīng)該帶有傾向性以及個人的觀點。

5．補充和完善軟件缺陷報告

從發(fā)現(xiàn)Bug那一刻起，測試人員的責(zé)任就是保證它被正確地報告，并且得到應(yīng)有的重視，繼續(xù)監(jiān)視其修復(fù)的全過程。

以上概括了報告測試錯誤的規(guī)范要求，測試人員應(yīng)該牢記這些關(guān)于報告軟件缺陷的原則。這些原則幾乎可以運用到任何交流活動中，盡管有時難以做到，然而，如果希望有效地報告軟件缺陷，并使其得以修復(fù)，這些是測試人員要遵循的基本原則。

6.5.2IEEE軟件缺陷報告模板

ANS/IEEE829—1998標準定義了一個稱為軟件缺陷報告的文檔，用于報告“在測試期間發(fā)生的任何異常事件”，簡言之，就是用于登記軟件缺陷，如圖6.4所示。

圖6.4軟件缺陷報告模板

一份優(yōu)秀的缺陷報告記錄下最少的重復(fù)步驟，不僅包括了期望結(jié)果，實際結(jié)果和必要的附件，還提供必要的數(shù)據(jù)、測試環(huán)境或條件，以及簡單的分析，如圖6.5所示。圖6.5優(yōu)秀的缺陷報告

而一份含糊而不完整的缺陷報告，缺少重建步驟，并且沒有期望結(jié)果、實際結(jié)果和必要的圖片，如圖6.6所示。圖6.6含糊而不完整的缺陷報告

一份散漫的缺陷報告(無關(guān)的重建步驟，以及對開發(fā)人員理解這個錯誤毫無幫助的結(jié)果信息)如圖6.7所示。圖6.7散漫的缺陷報告

6.6軟件缺陷的跟蹤管理

1．建立軟件缺陷跟蹤系統(tǒng)的優(yōu)點實踐中需要軟件缺陷跟蹤系統(tǒng)，以便簡述報告所發(fā)現(xiàn)的缺陷，處理軟件缺陷屬性，跟蹤軟件缺陷的整個生命周期和生成軟件缺陷跟蹤圖表等。建立一套軟件缺陷跟蹤系統(tǒng)的優(yōu)點概括起來有以下幾點：(1)軟件缺陷跟蹤系統(tǒng)擁有軟件缺陷跟蹤數(shù)據(jù)庫，它不僅可使軟件缺陷的簡述清楚，還提供統(tǒng)一的、標準化報告，使所有人的理解一致。

(2)缺陷跟蹤數(shù)據(jù)庫允許自動連續(xù)的軟件缺陷編號，還提供了大量供分析和統(tǒng)計的選項，這是手工方法無法實現(xiàn)的。

(3)基于缺陷跟蹤數(shù)據(jù)庫，可快速生成滿足各種查詢條件的、所必要的缺陷報表、曲線圖等，開發(fā)小組乃至公司的每一個人都可以隨時掌握軟件產(chǎn)品質(zhì)量的整體狀況或測試/開發(fā)的進度。

(4)缺陷跟蹤數(shù)據(jù)庫提供了軟件缺陷屬性并允許開發(fā)小組根據(jù)項目的相對和絕對重要性來修復(fù)缺陷。

(5)可以在軟件缺陷的生命周期中管理缺陷，從最初的報告到最后的解決；確保了每一個缺陷不會被忽略，同時，它還可以使注意力保持在那些必須盡快修復(fù)的重要缺陷上。

(6)當(dāng)缺陷在它的生命周期中變化時，開發(fā)人員、測試人員以及管理人員將熟悉新的軟件缺陷信息。一個設(shè)計良好的軟件缺陷跟蹤系統(tǒng)可以獲取歷史記錄，并在檢查缺陷的狀態(tài)時參考歷史記錄。

(7)在軟件缺陷跟蹤數(shù)據(jù)庫中關(guān)閉每一份缺陷報告，都可以被記錄下來。當(dāng)產(chǎn)品送出去時，每一份未關(guān)閉的缺陷報告都提供了預(yù)先警告的有效技術(shù)支持，并且證明測試人員找到特殊領(lǐng)域突然出現(xiàn)的事件中的軟件缺陷。

2．缺陷跟蹤系統(tǒng)的概述

一個缺陷跟蹤系統(tǒng)需要實現(xiàn)如下幾部分的功能：

(1)缺陷的上報，當(dāng)問題被發(fā)現(xiàn)后，可以通過系統(tǒng)進行提交、保留，方便跟蹤。

(2)缺陷錄入系統(tǒng)后，項目經(jīng)理應(yīng)該可以通過缺陷跟蹤系統(tǒng)進行瀏覽，定期獲得最新的缺陷問題報告。

(3)項目經(jīng)理將缺陷問題報告通過缺陷跟蹤系統(tǒng)轉(zhuǎn)交給程序員，程序員可以通過缺陷跟蹤系統(tǒng)知道自己負責(zé)修正的缺陷問題報告。

(4)缺陷問題的修正處理，當(dāng)程序員修復(fù)問題后，可以通過跟蹤系統(tǒng)，通知項目經(jīng)理問題已修復(fù)。

(5)對于無法根據(jù)缺陷報告重現(xiàn)的問題，也可以通過跟蹤系統(tǒng)，向項目經(jīng)理及測試人員要求更多更詳細的信息，并將缺陷問題返回至項目經(jīng)理重新處理。

(6)問題暫緩及申訴過程處理，對于缺陷報告提到的問題，如在當(dāng)前版本無法實現(xiàn)或者缺陷與需求有沖突的時候，可以將問題置為“暫緩處理”或“提出申訴”。

(7)對于優(yōu)先等級較低的缺陷問題，可能不能被及時處理掉，但必須可以被查詢。

(8)缺陷跟蹤系統(tǒng)可以提供跟蹤項目的狀態(tài)報告。

3．目前主流的缺陷跟蹤系統(tǒng)

1)?TestDirector

在工業(yè)級軟件項目領(lǐng)域，由于Mercury是測試軟件領(lǐng)域的老大(比較有名的如LoadRunner、WinRunner等)，因此它的TD也成了缺陷跟蹤系統(tǒng)的標桿產(chǎn)品。其也是最早通過Web方式來進行管理的缺陷跟蹤軟件。

2)?TestTrackPro

Seapine公司也是主要做項目管理軟件的，TestTrackPro同其同門配置管理產(chǎn)品SurroundSCM可以完美結(jié)合并實現(xiàn)完整的代碼級管理。其主要架構(gòu)為Client/Server，同時提供了CGI的Web訪問接口，不過其高昂的價格也會讓很多公司望而卻步。

3)?DevTrack

TechExcel可以說是CRM系統(tǒng)以及HelpDesk系統(tǒng)的老大，它的產(chǎn)品在很多大公司(如Oracle、IBM等)里都有應(yīng)用，最新發(fā)布的DevTrack功能也確實強大，在其項目配置的部分可以提供用戶對各級項目相關(guān)人員的UI進行配置，同時也提供了最大的靈活度給客戶，可視化自定義跟蹤流程可以實現(xiàn)任何復(fù)雜的配置處理。

4)?JIRA

JIRA是目前比較流行的基于Java架構(gòu)的缺陷跟蹤系統(tǒng)，由于Atlassian公司對很多開源項目實行免費，提供缺陷跟蹤服務(wù)，因此在開源領(lǐng)域，其認知度比其他的產(chǎn)品要高得多，而且易用性也好一些。

5)?Mantis

Mantis是一個基于PHP技術(shù)的輕量級的缺陷跟蹤系統(tǒng)，其功能與前面提及的JIRA系統(tǒng)類似，都是以Web操作的形式提供項目管理及缺陷跟蹤服務(wù)。在功能上可能沒有JIRA那么專業(yè)，界面也沒有JIRA漂亮，但在實用性上足以滿足中小型項目的管理及跟蹤。更重要的是其開源，不需要負擔(dān)任何費用。

6.7測試總結(jié)報告

測試總結(jié)報告的目的是總結(jié)測試活動的結(jié)果，并根據(jù)這些結(jié)果對測試進行評價。這種報告是測試人員對測試工作進行總結(jié)，并識別出軟件的局限性和發(fā)生失效的可能性。測試總結(jié)報告是測試計劃的擴展，起著對測試計劃“封閉回路”的作用。在測試執(zhí)行階段的末期，應(yīng)該為每個測試計劃準備一份相應(yīng)的測試總結(jié)報告，如圖6.8所示。

圖6.8測試總結(jié)報告

(1)測試總結(jié)報告標識符。報告標識符是標識報告的唯一ID，用來方便測試總結(jié)報告的管理、定位和引用。

(2)概述。該部分內(nèi)容概要說明發(fā)生了哪些測試活動，包括軟件的版本發(fā)布及環(huán)境等。這部分內(nèi)容通常還包括測試計劃、測試設(shè)計規(guī)格說明、測試用例提供的參考信息等。

(3)差異。該部分內(nèi)容是報告與設(shè)計說明書，以及與測試計劃、測試設(shè)計或測試規(guī)程的差異，并指出每個差異的原因。

(4)綜合評估。該部分內(nèi)容是根據(jù)本報告中所展示的測試結(jié)果，提供對該軟件的總體評估；標識在測試中檢測到的任何遺留的缺陷、限制或約束，可用問題/變更報告提供缺陷信息；對每一遺留缺陷、限制或約束，應(yīng)描述。

(5)結(jié)果總結(jié)。該部分內(nèi)容是列出所有問題及其解決情況，列出未解決的問題。

(6)評價。該部分內(nèi)容是提供每一個測試項目的評價，包含局限性評價，還要包含風(fēng)險分析。

(7)建議。該部分內(nèi)容是對被測試軟件的設(shè)計、操作或測試提供改進建議，應(yīng)討論每個建議及其對軟件的影響。如果沒有改進建議，本條應(yīng)陳述為“無”。

(8)活動總結(jié)。該部分內(nèi)容是總結(jié)主要的測試活動和事件。

(9)審批。這一部分列出對這個報告享有審批權(quán)的所有人員的姓名和職務(wù)，應(yīng)留出用于署名和填寫日期的空間。

6.8測?試?的?評?測

測試的評測主要方法包括覆蓋評測和質(zhì)量評測。覆蓋評測是對測試完全程度的評測，它建立在測試覆蓋基礎(chǔ)上。測試覆蓋是由測試需求和測試用例的覆蓋或已執(zhí)行代碼的覆蓋表示的。最常用的覆蓋評測是基于需求的測試覆蓋和基于代碼的測試覆蓋，分別是指針對需求(基于需求的)或代碼的設(shè)計/實施標準(基于代碼的)而言的完全程度評測。

1．基于需求的測試覆蓋

基于需求的測試覆蓋在測試過程中要評測多次，并在測試過程中，每一個測試階段結(jié)束時給出測試覆蓋的度量。例如，計劃的測試覆蓋、已實施的測試覆蓋、已執(zhí)行成功的測試覆蓋等。

基于需求的測試覆蓋率通過以下公式計算：

其中：T是用測試過程或測試用例表示的已計劃(Plan)、已實施(Input)或已執(zhí)行成功(Success)的測試需求數(shù)；RfT是測試需求的總數(shù)。

在執(zhí)行測試過程中，經(jīng)常使用兩個測試覆蓋度量指標，一個是確定已執(zhí)行(Ti)的測試覆蓋率，另一個是確定成功(Ts)的測試覆蓋率，即執(zhí)行時未出現(xiàn)失敗的測試覆蓋率。

可將Ts與已定義的成功標準對比，可用于預(yù)測剩余測試工作量。

2．基于代碼的測試覆蓋

基于代碼的測試覆蓋評測是測試過程中已經(jīng)執(zhí)行的代碼數(shù)，與之相對應(yīng)的是將要執(zhí)行測試的剩余代碼數(shù)。

基于代碼的測試覆蓋率通過以下公式計算：

其中：Ie是用代碼語句、代碼分支、代碼路徑、數(shù)據(jù)狀態(tài)判定點或數(shù)據(jù)元素名表示的已執(zhí)行(Execute)代碼數(shù)；TIic是代碼的總數(shù)。

6.9質(zhì)量評測

質(zhì)量評測是對測試對象的可靠性、穩(wěn)定性以及性能的評測。質(zhì)量建立在對測試結(jié)果的評估和對測試過程中確定的缺陷及缺陷修復(fù)的分析基礎(chǔ)上。常用的測試有效性度量是圍繞缺陷分析來構(gòu)造的。缺陷分析就是分析缺陷在與缺陷相關(guān)聯(lián)的一個或者多個參數(shù)值上的分布。缺陷分析提供了一個軟件可靠性指標，這些分析為揭示軟件可靠性的缺陷趨勢或缺陷分布提供了判斷依據(jù)。

對于缺陷分析，常用的主要缺陷參數(shù)有以下4個。

(1)狀態(tài)：缺陷的當(dāng)前狀態(tài)(打開的、正在修復(fù)的或關(guān)閉的等)。

(2)優(yōu)先級：修復(fù)缺陷的重要程度和應(yīng)該何時修復(fù)。

(3)嚴重性：軟件缺陷的惡劣程度，反映其對產(chǎn)品和用戶的影響等。

(4)起源：導(dǎo)致缺陷的原因及其位置，或排除該缺陷需要修復(fù)的構(gòu)件。

1．缺陷發(fā)現(xiàn)率

缺陷發(fā)現(xiàn)率是將發(fā)現(xiàn)的缺陷數(shù)量作為時間的函數(shù)來評測，即創(chuàng)建缺陷趨勢圖，如圖6.9所示。圖6.9缺陷發(fā)現(xiàn)率

2．缺陷潛伏期

缺陷潛伏期通常也稱為階段潛伏期，是一種特殊類型的缺陷分布度量。

在實際測試工作中，發(fā)現(xiàn)缺陷的時間越晚，這個缺陷所帶來的損害就越大，修復(fù)這個缺陷所耗費的成本就越多。所以，在一項有效的測試工作中，發(fā)現(xiàn)缺陷的時間往往會比一項低效的測試工作要早。表6-9顯示了一個項目的缺陷潛伏期的度量。在一個實際項目中，可能需要對這個度量進行適當(dāng)?shù)恼{(diào)整，以反映特定的軟件開發(fā)生命周期的各個階段、各個測試等級的數(shù)量和名稱。

3．缺陷密度

軟件缺陷密度是一種以平均值估算法來計算出軟件缺陷分布的密度值。程序代碼通常是以千行為單位的，軟件缺陷密度是用下面公式計算的：

4．缺陷探測率

缺陷探測率是另一個衡量測試工作效率的軟件質(zhì)量成本的指標。第7章測試項目管理7.1測試項目管理概述7.2測試文檔7.3軟件測試計劃7.4測試的組織與人員管理7.5軟件測試過程管理7.6軟件測試風(fēng)險管理7.7軟件測試成本管理7.8軟件測試配置管理

7.1測試項目管理概述

7.1.1測試項目與測試項目管理1．測試項目測試項目是在一定的組織機構(gòu)內(nèi)，利用有限的人力和財力等資源，在指定的環(huán)境和要求下，對特定軟件完成特定測試目標的階段性任務(wù)。該任務(wù)應(yīng)滿足一定質(zhì)量、數(shù)量和技術(shù)指標等要求。

測試項目一般具有如下一些基本特性：

1)獨特性

2)組織性

3)生命周期

4)資源消耗特性

5)目標沖突性

6)結(jié)果的不確定因素

2．測試項目管理

測試項目管理就是以測試項目為管理對象，通過一個臨時性的專門的測試組織，運用專門的軟件測試知識、技能、工具和方法，對測試項目進行計劃、組織、執(zhí)行和控制，并在時間成本、軟件測試質(zhì)量等方面進行分析和管理。測試項目管理貫穿整個測試項目的生命周期。

測試項目管理有以下基本特征：

(1)系統(tǒng)工程的思想貫穿測試項目管理的全過程。

(2)測試項目管理的組織有一定的特殊性。項目管理的一個最為明顯的特征即是其組織的特殊性。其特殊性表現(xiàn)在以下幾個方面：

①有了“項目組織”的概念，項目管理的突出特點是以項目本身作為一個組織單元，圍繞項目來組織資源；

②項目管理的組織是臨時性的，由于項目是一次性的，而項目的組織是為項目的建設(shè)服務(wù)的，項目終結(jié)了，其組織的使命也就完成了；

③項目管理的組織是柔性的，所謂柔性即是可變的。項目的組織打破了傳統(tǒng)的固定建制的組織形式，而是根據(jù)項目生命周期各個階段的具體需要適時地調(diào)整組織的配置，以保障組織的高效、經(jīng)濟運行。

(3)測試項目管理的要點是創(chuàng)造和保持一個使測試工作順利進行的環(huán)境，使置身于這個環(huán)境中的人員能協(xié)調(diào)工作以完成預(yù)定的目標。

(4)測試項目管理的方法、工具和技術(shù)手段具有先進性。

7.1.2測試項目的范圍管理

測試項目的范圍管理就是界定項目所必須包含且只需包含的全部工作，并對其他的測試項目管理工作起指導(dǎo)作用，以確保測試工作順利完成。

測試項目的范圍管理從過程上來講，主要包括啟動、范圍計劃、范圍定義、范圍核實、范圍的變更與控制等內(nèi)容。范圍管理的首要任務(wù)是界定項目包含且只包含所有需要完成的工作，“包含且只包含”的意義至少有以下三個方面：一是有足夠多的工作必須做；二是不必要的工作不做；三是所做的工作都是為了實現(xiàn)項目(或項目一部分)的目標。在進行項目范圍管理時，應(yīng)當(dāng)注意三點，即搞清需求、準確界定范圍、變更控制要嚴。

工作分解結(jié)構(gòu)跟因數(shù)分解是一個原理，就是把一個項目按一定的原則分解，項目分解成任務(wù)，任務(wù)再分解成一項項工作，再把一項項工作分配到每個人的日常活動中，直到分解不下去為止，即：項目→任務(wù)→工作→日?；顒?。工作分解結(jié)構(gòu)以可交付成果為導(dǎo)向，對項目要素進行分組，它歸納和定義了項目的整個工作范圍，每下降一層代表對項目工作的更詳細定義。WBS總是處于計劃過程的中心，也是制訂進度計劃、資源需求、成本預(yù)算、風(fēng)險管理計劃和采購計劃等的重要基礎(chǔ)。

7.2測試文檔

測試文檔(TestingDocumentation)是對要執(zhí)行的軟件測試及測試的結(jié)果進行簡述、定義、規(guī)定和報告的任何書面或圖示信息。測試過程實施所必備的核心文檔是測試計劃、測試用例(大綱)和軟件測試報告。

7.2.1測試文檔的作用

從以下幾個方面可以說明測試文檔的重要作用。

(1)促進項目組成員之間的交流溝通。

(2)便于對測試項目的管理。

(3)決定測試的有效性。

(4)檢驗測試資源。

(5)明確任務(wù)的風(fēng)險。

(6)評價測試結(jié)果。

(7)驗證需求的正確性。

7.2.2主要軟件測試文檔

1．軟件測試文檔

IEEE829－1998給出了軟件測試主要文檔的類型，如圖7.1所示。圖7.1軟件測試文檔模板

2．軟件測試計劃文檔

軟件測試計劃主要對軟件測試項目、所需要進行的測試工作、測試人員所應(yīng)該負責(zé)的測試工作、測試過程、測試所需的時間和資源，以及測試風(fēng)險等做出預(yù)先的計劃和安排，如圖7.2所示。

圖7.2軟件測試計劃文檔模板

3．測試設(shè)計規(guī)格說明文檔

測試設(shè)計規(guī)格說明用于每個測試等級，以指定測試集的體系結(jié)構(gòu)和覆蓋跟蹤，如圖7.3所示。圖7.3軟件測試設(shè)計規(guī)格說明文檔模板

4．軟件測試用例規(guī)格說明文檔

軟件測試用例規(guī)格說明用于簡述測試用例，如圖7.4所示。圖7.4軟件測試用例規(guī)格說明文檔模板

5．測試規(guī)程

測試規(guī)程用于指定執(zhí)行一個測試用例集的步驟。

6．測試日志

測試日志是測試過程監(jiān)控、測試結(jié)果和軟件質(zhì)量評估的基礎(chǔ)，同時也是數(shù)據(jù)分析和過程改進的重要依據(jù)，如圖7.5所示。圖7.5測試日志模板

7．軟件缺陷報告

軟件缺陷報告用來簡述出現(xiàn)在測試過程或軟件中的異常情況，這些異常情況可能存在于需求、設(shè)計、代碼、文檔或測試用例中，如圖7.6所示。

圖7.6軟件缺陷報告模板

8．測試總結(jié)報告

測試總結(jié)報告用于報告某個測試完成情況，如圖7.7所示。圖7.7測試總結(jié)報告模板

7.3軟件測試計劃

7.3.1制訂測試計劃的目的 制訂測試計劃的目的如下：1．使軟件測試工作進行更順利軟件測試計劃明確地將要進行的軟件測試采用的模式、方法、步驟以及可能遇到的問題與風(fēng)險等內(nèi)容都做了考慮和計劃，這樣會使測試執(zhí)行、測試分析和撰寫測試報告的準備工作更加有效，使軟件測試工作進行得更順利。

2．促進項目參加人員彼此的溝通

測試過程必須有相應(yīng)的條件才能進行。如果程序員只是編寫代碼，而不說明它干什么、如何工作、何時完成，測試人員就很難執(zhí)行測試任務(wù)。

3．及早發(fā)現(xiàn)和修正軟件規(guī)格說明書的問題

在編寫軟件測試計劃的初期，首先要了解軟件各個部分的規(guī)格及要求，這樣就需要仔細地閱讀、了解規(guī)格說明書。

4．使軟件測試工作更易于管理

制訂測試計劃的另一個目的，就是要對整個軟件測試工作采取系統(tǒng)化的方式來進行，這樣會使軟件測試工作更易于管理。測試計劃包含兩種主要的管理方式，一是工作分解結(jié)構(gòu)，二是監(jiān)督和控制。

7.3.2制訂測試計劃的原則

1．制訂測試計劃應(yīng)盡早開始

2．保持測試計劃的靈活性

3．保持測試計劃簡潔和易讀

4．盡量爭取多渠道評審測試計劃

5．計算測試計劃的投入

7.3.3制訂測試計劃時面對的問題

1．與開發(fā)者意見不一致

2．缺乏測試工具

3．培訓(xùn)不夠

4．管理部門缺乏對測試工作的理解和支持

5．缺乏用戶的參與

6．測試時間不足

7．過分依賴測試人員

8．測試人員處于進退兩難的狀態(tài)

9．不得不說“不”

7.3.4制訂測試計劃

1．測試計劃標識符

2．簡要介紹

測試計劃的簡要介紹部分主要是對測試軟件基本情況的介紹和對測試范圍的概括性簡述。

3．測試項目

測試項目包括所測試軟件的名稱及版本，需要列出所有測試單項、外部條件對測試特性的影響和軟件缺陷報告的機制等，具體要點如下：

(1)功能測試。

(2)設(shè)計測試。

(3)整體測試。

IEEE標準中指出，可以參考下面的文檔來完成測試項目：

(1)需求規(guī)格說明；

(2)用戶指南；

(3)操作指南；

(4)安裝指南。

總的來說，測試需要分析軟件的每一部分，明確其是否需要測試，并說明理由。

4．測試對象

測試計劃的這一部分需要列出待測的單項功能及功能組合。這部分內(nèi)容與測試項目不同。

5．不需要測試的對象

測試計劃的這一部分需要列出不測試的單項功能及組合功能，并說明不予測試的理由。

6．測試方法(策略)

這部分內(nèi)容是測試計劃的核心所在，需要給出有關(guān)測試方法的概述以及每個階段的測試方法。

7．測試項通過/失敗的標準

這部分需要給出“測試項目”中簡述的每一個測試項通過或失敗的標準。正如每個測試用例都需要一個預(yù)期的結(jié)果一樣，每個測試項目也同樣都需要一個預(yù)期的結(jié)果。

隨著測試等級的不同和測試組織的不同，所采用的確切標準也會不同，下面是一些常見指標：

(1)通過的測試用例占所有測試用例的比例。

(2)缺陷的數(shù)量、嚴重程度和分布情況。

(3)測試用例覆蓋情況。

(4)文檔的完整性。

(5)是否達到性能標準。

8．中斷測試和恢復(fù)測試的判斷準則

常用的判斷測試中斷的標準如下：

(1)關(guān)鍵路徑存在未完成任務(wù)；

(2)大量的缺陷；

(3)嚴重的缺陷；

(4)測試環(huán)境不完整；

(5)資源短缺。

9．測試完成所提交的材料

測試完成所提交的材料主要包含測試工作中開發(fā)設(shè)計的所有文檔、工具等。例如，測試計劃、測試設(shè)計規(guī)格說明、測試用例、測試日志、測試數(shù)據(jù)、自定義工具、測試缺陷報告和測試總結(jié)報告等。

10．測試任務(wù)

測試計劃中這一部分需要給出測試前的準備工作以及測試工作所需完成的一系列任務(wù)。

11．測試所需的資源

測試所需的資源如下：

(1)人員；

(2)設(shè)備特性；

(3)辦公或?qū)嶒灴臻g；

(4)軟件；

(5)其他資源，如U盤、通信設(shè)備、參考書等；

(6)特殊測試工具。

12．測試人員的工作職責(zé)

測試人員的工作職責(zé)明確指出了測試任務(wù)和測試人員的工作責(zé)任。有時測試需要定義的任務(wù)類型不容易分清。復(fù)雜的任務(wù)可能有多個執(zhí)行者，或者由多人共同負責(zé)。

13．人員安排與培訓(xùn)需求

人員安排與培訓(xùn)需求是指明確測試人員具體負責(zé)軟件測試的哪些部分、哪些可測試性能，以及他們需要掌握的技能等。

14．進度表

測試進度是圍繞著包含在項目計劃中的主要事件(如文檔、模塊的交付日期，接口的可用性等)來構(gòu)造的。

作為測試計劃的一部分，完成測試進度計劃安排，可以為項目管理員提供信息，以便更好地安排整個項目的進度。

15．潛在的問題和風(fēng)險

軟件測試人員要明確地指出計劃過程中的風(fēng)險，并與測試管理員和項目管理員交換意見。這些風(fēng)險應(yīng)該在測試計劃中明確指出，在進度中予以考慮。

16．審批

審批人應(yīng)該是有權(quán)宣布已經(jīng)為轉(zhuǎn)入下一個階段做好準備的某個人或某幾個人。

審批人除了在適當(dāng)?shù)奈恢煤炇鹱约旱拿趾腿掌谕猓€應(yīng)該簽署表明他們態(tài)度的評審意見。

7.3.5如何做好測試計劃

1．明確測試的目標，增強測試計劃的實用性

當(dāng)今任何商業(yè)軟件都包含了豐富的功能，因此，軟件測試的內(nèi)容千頭萬緒，如何在紛亂的測試內(nèi)容之間提煉測試的目標，是制訂軟件測試計劃時首先需要明確的問題。測試目標必須是明確的、可以量化和度量的，而不是模棱兩可的宏觀簡述。另外，測試目標應(yīng)該相對集中，避免羅列出一系列目標，從而輕重不分或平均用力。

2．堅持“5W1H”規(guī)則

明確內(nèi)容與過程“What(做什么)”“Why(為什么做)”“When(何時做)”“Where(在哪里)”“Who(誰來做)”“How(如何做)”。

(1)?Why——指為什么要進行這些測試；

(2)?What——測試哪些方面，即不同階段的工作內(nèi)容；

(3)?When——測試不同階段的起止時間；

(4)?Where——相應(yīng)文檔、缺陷的存放位置，測試環(huán)境等；

(5)?Who——項目有關(guān)人員的組成，即安排哪些測試人員進行測試；

(6)?How——如何去做，即使用哪些測試工具以及測試方法進行測試。

3．采用評審和更新機制，保證測試計劃滿足實際需求

測試計劃制訂完成后，如果沒有經(jīng)過評審，直接發(fā)送給測試團隊，測試計劃內(nèi)容可能不準確或遺漏測試內(nèi)容，或者軟件需求變更引起測試范圍增減，而測試計劃的內(nèi)容沒有及時更新，誤導(dǎo)測試執(zhí)行人員。

4．分別制訂測試計劃與測試詳細規(guī)格、測試用例

編寫軟件測試計劃要避免一種不良傾向，即測試計劃的“大而全”，無所不包，篇幅冗長，長篇大論，重點不突出，既浪費寫作時間，也浪費測試人員的閱讀時間。“大而全”的一個常見表現(xiàn)就是測試計劃文檔包含詳細的測試技術(shù)指標、測試步驟和測試用例。

5．測試階段的劃分

就通常軟件項目而言，基本上采用“瀑布型”開發(fā)方式，這種開發(fā)方式下，各個項目主要活動比較清晰，易于操作。整個項目生命周期為“需求－設(shè)計－編碼－測試－發(fā)布－實施－維護”。

6．系統(tǒng)測試階段日程安排

劃分階段清楚了，隨之而來的問題是測試執(zhí)行需要的時間長短。標準的工程方法或CMM方式是對工作量進行估算，然后得出具體的估算值。但是這種方法過于復(fù)雜，可以另辟專題討論。一個可操作的簡單方法是：根據(jù)測試執(zhí)行上一階段的活動時間進行換算，為上一階段活動時間的1.1～1.5倍。

經(jīng)驗評估方法如下：

(1)計算需求文檔的頁數(shù)，得出系統(tǒng)測試用例的頁數(shù)：

需求頁數(shù)∶系統(tǒng)測試用例頁數(shù)?≈?1∶1

(2)由系統(tǒng)測試用例頁數(shù)計算編寫系統(tǒng)測試用例時間：

編寫系統(tǒng)測試用例時間?≈?系統(tǒng)測試用例頁數(shù)?×?1小時

(3)計算執(zhí)行系統(tǒng)測試用例時間：

編寫系統(tǒng)用例時間∶執(zhí)行系統(tǒng)測試用時?≈?1∶2

(4)計算回歸測試包含的時間：

系統(tǒng)測試時間∶回歸測試用時?≈?2∶1

7．變更控制

測試計劃改變了已往根據(jù)任務(wù)進行測試的方式，因此，為使測試計劃得到貫徹和落實，測試組人員必須及時跟蹤軟件開發(fā)的過程，對產(chǎn)品提交測試做準備。測試計劃的目的，本身就是強調(diào)按規(guī)劃的測試戰(zhàn)略進行測試，淘汰以往以任務(wù)為主的臨時性。在這種情況下，測試計劃中強調(diào)對變更的控制顯得尤為重要。

變更來源于以下幾個方面：

(1)項目計劃的變更。

(2)需求的變更。

(3)測試產(chǎn)品版本的變更。

(4)測試資源的變更。

測試階段的風(fēng)險主要是由上述變更所造成的不確定性，有效地應(yīng)對這些變更就能降低風(fēng)險發(fā)生的概率。要想計劃本身不成為空談和空白無用的紙質(zhì)文檔，對不確定因素的預(yù)見和事先防范必須做到心中有數(shù)。

7.4測試的組織與人員管理7.4.1測試的組織與人員管理概述測試項目成功完成的關(guān)鍵因素之一就是要有高素質(zhì)的軟件測試人員，并將他們有效地組織起來，分工合作，形成一支精干的隊伍，使他們發(fā)揮出最大的工作效率。測試的組織與人員管理是測試項目不可缺少的管理職能，將會直接影響軟件測試工作的效率和軟件產(chǎn)品的質(zhì)量。在管理人員的經(jīng)驗中，常常有這樣的情況：如果問題是屬于技術(shù)方面的，應(yīng)對的方法是多研究，尋找解決方案；如果問題出現(xiàn)在“人”的議題上，則幾乎沒有標準答案可以提供。

測試的組織與人員管理的任務(wù)是：

(1)為測試項目選擇合適的組織結(jié)構(gòu)模式。

(2)確定項目組內(nèi)部的組織形式。

(3)合理配備人員，明確分工和責(zé)任。

(4)對項目成員的思想、心理和行為進行有效的管理，充分發(fā)揮他們的主觀能動性，密切配合實現(xiàn)項目的目標。

測試的組織與人員管理應(yīng)注意的原則是：

(1)盡快落實責(zé)任。

(2)減少接口

(3)責(zé)任明確、均衡。

7.4.2軟件測試對組織結(jié)構(gòu)和人員的要求

1．對組織結(jié)構(gòu)的要求

軟件測試是由組織和人員進行的測試工作，具體的組織結(jié)構(gòu)如圖7.8所示。圖7.8組織結(jié)構(gòu)圖

測試工作的有關(guān)人員結(jié)構(gòu)如圖7.9所示。圖7.9測試工作的有關(guān)人員結(jié)構(gòu)圖

2．對人員的要求

1)合理地組織人員

軟件測試人員最好具有軟件開發(fā)經(jīng)驗，理解軟件工程的知識。軟件測試過程中，必須要合理地組織人員。將軟件測試的人員分成三部分：一部分為上機測試人員(測試執(zhí)行者)；一部分為測試結(jié)果檢查核對人員(測試工具軟件開發(fā)工程師)；還有一部分是測試數(shù)據(jù)制作人員(高級軟件測試工程師)。這三部分人員應(yīng)該緊密配合，互相協(xié)調(diào)，保證軟件測試工作的順利進行。

(1)上機測試人員。上機測試人員負責(zé)理解產(chǎn)品的功能要求，然后根據(jù)測試規(guī)范和測試案例對其進行測試，檢查軟件有沒有錯誤，確定軟件是否具有穩(wěn)定性，承擔(dān)最低級的執(zhí)行角色。

(2)測試結(jié)果檢查核對人員。測試結(jié)果檢查核對人員負責(zé)編寫測試工具代碼，并利用測試工具對軟件進行測試，或者開發(fā)測試工具為軟件測試工程師服務(wù)。

(3)測試數(shù)據(jù)制作人員。測試數(shù)據(jù)制作人員要具備編寫程序的能力。

(4)測試經(jīng)理。測試經(jīng)理主要負責(zé)測試內(nèi)部管理以及與其他外部人員、客戶的交流等，測試經(jīng)理需要具備項目經(jīng)理所具備的知識和技能。

(5)測試文檔審核師。測試文檔審核師主要負責(zé)前置測試，包括對在需求期與設(shè)計期間產(chǎn)生的文檔(如“需求規(guī)格說明書”“概要設(shè)計書”“詳細設(shè)計書”等)進行審核。審核時需要書寫審核報告。當(dāng)文檔確定后，需要整理文檔報告，并且反映給測試工程師。

(6)測試工程師。測試工程師主要根據(jù)需求期與設(shè)計期間產(chǎn)生的文檔設(shè)計制作測試數(shù)據(jù)和各個測試階段的測試用例。

(7)操作人員。操作人員(測試人員、測試專員)的主要工作就是執(zhí)行測試工程師提供的測試用例，從而發(fā)現(xiàn)Bug。

2)軟件測試人員需要的知識

軟件測試不是一個可以很快入門的行業(yè)，它的門檻高，需要的知識多，具有編程經(jīng)驗的程序員不一定是一名優(yōu)秀的測試工程師。軟件測試人員需要的知識結(jié)構(gòu)如下：

(1)懂得計算機的基本理論，又有一定的開發(fā)經(jīng)驗。

(2)了解軟件開發(fā)的基本過程和特征，對軟件有良好的理解能力，掌握軟件測試相關(guān)理論及技術(shù)。

(3)有軟件業(yè)務(wù)經(jīng)驗。

(4)能夠根據(jù)測試計劃和方案進行軟件測試，針對軟件需求開發(fā)測試模型，制定測試方案，安排測試計劃，搭建測試環(huán)境，進行基本測試，設(shè)計簡單的測試用例。

(5)能夠規(guī)劃設(shè)計環(huán)境，編制測試大綱并設(shè)計測試用例，對軟件進行全面測試工作。

(6)能夠編制測試計劃，評審測試方案，規(guī)范測試流程及測試文檔，分析測試結(jié)果，管理測試項目。

(7)會操作軟件測試工具。

3)軟件測試人員需要的素質(zhì)

(1)溝通能力。在溝通交流時，要注意以下幾點：

①設(shè)身處地為客戶著想，從他們的角度去測試系統(tǒng)。

②考慮問題要全面，結(jié)合客戶的需求、業(yè)務(wù)的流程和系統(tǒng)的構(gòu)架等多方面考慮問題。

③提出問題時不要將其復(fù)雜化。

(2)技術(shù)能力。測試人員應(yīng)該在開發(fā)人員研究的基礎(chǔ)上，更好地理解新技術(shù)，讀懂程序。

(3)自信心。開發(fā)者經(jīng)常會指出測試者的錯誤，測試者必須對自己的觀點有足夠的自信心。

(4)洞察力。一個好的測試工程師會持有“測試是為了破壞”的觀點，具有捕獲用戶觀點的能力，強烈追求高質(zhì)量的意識，對細節(jié)的關(guān)注能力，對高風(fēng)險區(qū)的判斷能力，以便將有限的測試聚焦于重點環(huán)節(jié)。

(5)探索精神。軟件測試員不會害怕進入陌生環(huán)境，他們喜歡將新軟件安裝在自己的機器上，觀察結(jié)果。

(6)不懈努力。軟件測試員總是不停地嘗試。他們可能會碰到“轉(zhuǎn)瞬即逝”或難以重建的軟件缺陷。他們不會心存僥幸，而是盡一切可能去尋找缺陷。

(7)創(chuàng)造性。測試顯而易見的結(jié)果，那不是軟件測試員的工作。他們的工作是采取富有創(chuàng)意甚至超常的手段來尋找缺陷。

(8)追求完美。軟件測試員力求完美，但是知道某些目標無法企及時，他們不會去苛求，而是盡力接近目標。

(9)判斷準確。軟件測試員要決定測試內(nèi)容、測試時間，以及所看到的問題是否是真正的缺陷。

(10)老練穩(wěn)重和說服力。軟件測試員不害怕壞消息。他們必須告訴程序員，你的程序有問題。優(yōu)秀的軟件測試知道怎樣老練地處理這些問題，怎樣和不夠冷靜的程序員合作。

軟件測試員找出的軟件缺陷有時會被認為不重要、不用修復(fù)，這時要善于表達觀點，表明軟件缺陷必須修復(fù)，并通過實際演示來證明自己的觀點。

7.5軟件測試過程管理

7.5.1測試項目的跟蹤與監(jiān)控項目跟蹤是以項目計劃為基線，跟蹤項目實際進展。項目跟蹤要回答的問題如下：(1)目前在哪里？(2)要到達哪里？(3)如何到達那里？(4)是不是在走向那里？

7.5.2測試項目的過程管理

軟件測試過程管理主要集中在軟件測試項目啟動、測試計劃制訂、測試用例設(shè)計、測試執(zhí)行、測試結(jié)果審查和分析，以及如何開發(fā)或使用測試過程管理工具，概括起來包括如下基本內(nèi)容：

1．測試項目啟動

首先要確定項目組長，只有把項目組長確定下來，就可以組建整個測試小組，并可以和開發(fā)等部門開展工作。

2．制訂測試計劃

確定測試范圍、測試策略和測試方法，以及對風(fēng)險、日程表、資源等進行分析和估計。

3．測試設(shè)計和測試開發(fā)

制訂測試的技術(shù)方案，設(shè)計測試用例，選擇測試工具，寫測試腳本等。

4．測試實施和執(zhí)行

建立或設(shè)置相關(guān)的測試環(huán)境，準備測試數(shù)據(jù)，執(zhí)行測試用例，對發(fā)現(xiàn)的軟件缺陷進行報告、分析、跟蹤等。

5．測試結(jié)果的審查和分析

當(dāng)測試執(zhí)行結(jié)束后，對測試結(jié)果要進行整體或綜合分析，以確定軟件產(chǎn)品質(zhì)量的當(dāng)前狀態(tài)，為產(chǎn)品的改進或發(fā)布提供數(shù)據(jù)和依據(jù)。

7.6軟件測試風(fēng)險管理

1．風(fēng)險的基本概念風(fēng)險可定義為“傷害、損壞或損失的可能性；一種危險的可能，或一種冒險事件”。風(fēng)險涉及一個事件發(fā)生的可能性，涉及該事件產(chǎn)生的不良后果或影響。軟件風(fēng)險是指開發(fā)不成功引起損失的可能性，這種不成功事件會導(dǎo)致公司商業(yè)上的失敗。在軟件測試中，不可能對系統(tǒng)的所有方面進行測試，會存在用戶發(fā)現(xiàn)缺陷的可能性，稱為測試風(fēng)險。

2．軟件風(fēng)險分類

不同類型的測試項目有不同的風(fēng)險。相同類型的項目，測試風(fēng)險也各不相同，取決于測試環(huán)境、客戶、項目團隊、采用的技術(shù)和工具等。根據(jù)風(fēng)險出現(xiàn)的情況可分為可避免的風(fēng)險和不可避免的風(fēng)險兩種。

在軟件測試過程中經(jīng)常會遇到的風(fēng)險主要有以下7類。

(1)時間進度風(fēng)險：用戶需求發(fā)生重大變更及設(shè)計計劃的大幅調(diào)整給測試帶來風(fēng)險，導(dǎo)致測試時間、資金投入增加。

(2)對產(chǎn)品認識的風(fēng)險：對產(chǎn)品質(zhì)量需求或產(chǎn)品特性理解不準確，造成測試范圍分析誤差，出現(xiàn)測試盲區(qū)或驗證標準錯誤。

(3)質(zhì)量目標風(fēng)險：質(zhì)量標準不是很清晰，如適用性測試、易用性測試等。

(4)人員風(fēng)險：測試開始后，相關(guān)測試人員因故不能及時到位。

(5)測試環(huán)境的依賴性風(fēng)險：特定測試環(huán)境不到位，包括真實環(huán)境及仿真環(huán)境。

(6)測試充分性風(fēng)險：測試用例設(shè)計不到位，忽視了部分邊界條件、深層次的邏輯、用戶場景等；部分軟件缺陷不易重現(xiàn)以及回歸測試一般不運行全部測試用例，有選擇性地執(zhí)行。

(7)工具風(fēng)險：能否及時準備相關(guān)測試工具，測試人員對新工具無法熟練運用等情況也時有發(fā)生。

3．軟件風(fēng)險分析

在開發(fā)新的軟件系統(tǒng)過程中，由于存在許多不確定因素，軟件開發(fā)失敗的風(fēng)險是客觀存在的。因此，風(fēng)險分析對于軟件項目管理是決定性的。風(fēng)險分析實際上就是貫穿在軟件工程過程中的一系列風(fēng)險管理步驟，其中包括風(fēng)險識別、風(fēng)險估計、風(fēng)險管理策略、風(fēng)險解決和風(fēng)險監(jiān)督等。

風(fēng)險分析包括兩個部分。

(1)發(fā)生的可能性：發(fā)生問題的可能性有多大。

(2)影響嚴重性：如果問題發(fā)生了，會有什么后果。

通常風(fēng)險分析采用兩種方法，即表格分析法和矩陣分析法。通用的風(fēng)險分析表包括以下幾項內(nèi)容：

(1)風(fēng)險標識(ID)：表示風(fēng)險事件的唯一標識；

(2)風(fēng)險問題：問題發(fā)生現(xiàn)象的簡要描述；

(3)發(fā)生的可能性：可能性值從1(低)～10(高)；

(4)影響的嚴重性：嚴重性值從1(低)～10(高)；

(5)風(fēng)險預(yù)測值：發(fā)生可能性和影響嚴重性的乘積；

(6)風(fēng)險優(yōu)先級：風(fēng)險預(yù)測值從高到低的排序。

4．軟件測試風(fēng)險

軟件測試風(fēng)險是軟件測試過程出現(xiàn)的或潛在的問題，造成的原因主要是測試計劃的不充分、測試方法有誤或測試過程的偏離，造成測試的補充以及結(jié)果不準確。

軟件測試項目存在著風(fēng)險，在測試項目管理中，預(yù)先重視風(fēng)險評估，并對可能出現(xiàn)的風(fēng)險有所防范，就可以最大限度地減少風(fēng)險的發(fā)生或降低風(fēng)險所帶來的損失。風(fēng)險的管理基本的內(nèi)容有兩項：風(fēng)險評估和風(fēng)險控制。

1)風(fēng)險評估

風(fēng)險評估是在風(fēng)險識別的基礎(chǔ)上，對識別出來的風(fēng)險進行評估，主要從下面四個方面入手：

(1)風(fēng)險概率分析，即對風(fēng)險發(fā)生的可能性設(shè)置一個尺度，如很高、較高、中等、較低、很低等；

(2)簡述風(fēng)險并預(yù)測風(fēng)險發(fā)生后，對軟件產(chǎn)品和測試結(jié)果可能產(chǎn)生的影響或造成的損失等；

(3)確定風(fēng)險評估的正確性，要對每個風(fēng)險的表現(xiàn)、范圍、時間做出盡量準確的判斷；

(4)根據(jù)損失(影響)和風(fēng)險概率的乘積，來確定風(fēng)險的優(yōu)先級別，制定風(fēng)險應(yīng)對措施。

2)風(fēng)險控制

風(fēng)險控制建立在風(fēng)險評估的結(jié)果上，主要工作原則有：

(1)針對有些可以避免的風(fēng)險，例如測試用例執(zhí)行率未達到100%，可以通過制定測試規(guī)范，要求測試人員嚴格按照測試用例執(zhí)行測試，并記錄用例執(zhí)行情況，來避免該類風(fēng)險；

(2)有些不可避免的風(fēng)險，采取措施降低風(fēng)險，尤其是等級較高的風(fēng)險，將其轉(zhuǎn)化為不會引起嚴重后果的等級較低的風(fēng)險；

(3)凡事預(yù)則立，事先做好風(fēng)險管理計劃，當(dāng)風(fēng)險成為現(xiàn)實時，可以更好地避免、轉(zhuǎn)移或降低風(fēng)險；

(4)對風(fēng)險的處理制定應(yīng)急、高效的解決方案。

要想做好風(fēng)險管理工作，就必須徹底改變測試項目的管理方式，建立防患于未然的管理意識，并結(jié)合具體的實踐工作不斷地分析遇到的風(fēng)險，總結(jié)各種風(fēng)險的應(yīng)對措施，指導(dǎo)實踐，降低產(chǎn)品質(zhì)量風(fēng)險。

7.7軟件測試成本管理

7.7.1軟件測試成本管理概述軟件測試項目成本管理就是根據(jù)企業(yè)的情況和軟件測試項目的具體要求，利用公司的資源，在保證軟件測試項目的進度、質(zhì)量達到客戶滿意的情況下，對軟件測試項目成本進行有效的組織、實施、控制、跟蹤、分析和考核等一系列管理活動，最大限度地降低軟件測試項目的成本，提高項目利潤。

7.7.2軟件測試成本管理中的基本概念

1．測試費用有效性

風(fēng)險承受的確定，從經(jīng)濟學(xué)的角度考慮就是確定需要完成多少測試，以及進行什么類型的測試；確定軟件存在的缺陷是否可以接受，如果可以，能承受多少。測試的策略不再主要由軟件人員和測試人員來確定，而是由商業(yè)的經(jīng)濟利益來決定的。

2．測試成本控制

成本控制是項目管理中的一個重點，所有的人都在關(guān)心項目成本。一個美國項目管理教授曾幽默地說：“世界上的人都戴著放大鏡在看錢，尤其是美國人?！辈挥嬈鋽?shù)的項目由于資金問題遭到挫折或夭折，迫使人們不敢有絲毫大意。

測試工作的主要目標是使測試產(chǎn)能最大化，也就是要使通過測試找出錯誤的能力最大化，而檢測次數(shù)最小化。

測試的成本控制目標是使測試開發(fā)成本、測試實施成本和測試維護成本最小化。

在軟件產(chǎn)品測試過程中，測試實施成本主要包括測試準備成本、測試執(zhí)行成本和測試結(jié)束成本。

3．質(zhì)量成本

企業(yè)為了獲取利潤，需花費大量的資金進行測試。在質(zhì)量方面的投資會產(chǎn)生利潤。測試是一種帶有風(fēng)險性的管理活動，可以使企業(yè)減少因為軟件產(chǎn)品質(zhì)量低劣而花費的不必要的成本。

1)質(zhì)量成本要素

質(zhì)量成本要素主要包括一致性成本和非一致性成本。一致性成本是指用于保證軟件質(zhì)量的支出，包括預(yù)防成本和測試預(yù)算，如測試計劃、測試開發(fā)、測試實施費用。非一致性成本是由出現(xiàn)的軟件錯誤和測試過程故障(如延期、劣質(zhì)的發(fā)布)引起的。追加測試時間和資金就是一種由于內(nèi)部故障引起的非一致性成本。非一致性成本還包括外部故障(軟件遺留錯誤影響客戶)引起部分。一般情況下，外部故障非一致性成本要大于一致性成本與內(nèi)部故障非一致性成本之和。

2)質(zhì)量成本計算

質(zhì)量成本計算公式如下：

4．缺陷探測率

缺陷探測率是另一個衡量測試工作效率的軟件質(zhì)量成本的指標。

7.7.3軟件測試項目成本管理的基本原則和措施

1．軟件測試項目成本的控制原則

1)堅持成本最低化原則

軟件測試項目成本控制的根本目的在于，通過成本管理的各種手段，不斷降低軟件測試項目成本，以達到可實現(xiàn)的最低的目標成本要求。

2)堅持全面成本控制原則

全面成本管理是整個測試團隊、全體測試人員和測試全過程的管理，亦稱“三全”管理。

3)堅持動態(tài)控制原則

軟件測試項目是一次性的，成本控制應(yīng)強調(diào)項目的中間控制，即動態(tài)控制。

4)堅持項目目標管理原則

目標管理的內(nèi)容包括：①目標的設(shè)定和分解；②目標的責(zé)任到位和執(zhí)行；③檢查目標的執(zhí)行結(jié)果；④評價目標和修正目標；⑤形成目標管理的計劃、實施、處理循環(huán)。

5)堅持責(zé)、權(quán)、利相結(jié)合的原則

在軟件測試施工過程中，軟件測試項目負責(zé)人和測試人員在肩負成本控制責(zé)任的同時，享有成本控制的權(quán)力，同時要對成本控制中的業(yè)績進行定期的檢查和考評，實行有獎有罰。只有做到責(zé)、權(quán)、利相結(jié)合的成本控制，才能收到預(yù)期的效果。

2．軟件測試項目成本控制措施

1)組織措施

軟件測試項目負責(zé)人是項目成本管理的第一責(zé)任人，全面組織軟件測試項目的成本管理工作，應(yīng)及時掌握和分析盈虧狀況，并迅速采取有效措施；負責(zé)技術(shù)工作的測試人員應(yīng)在保證質(zhì)量、按期完成任務(wù)的前提下盡量采取先進技術(shù)，以降低工程成本；負責(zé)財務(wù)工作的人員應(yīng)及時分析項目的財務(wù)收支情況，合理調(diào)度、控制資金。

2)技術(shù)措施

技術(shù)措施包括三個方面：

一是制訂先進的經(jīng)濟合理的測試方案，以達到縮短工期、提高質(zhì)量、降低成本的目的；

二是在軟件測試過程中努力尋求各種降低消耗、提高工效的新工藝、新技術(shù)來降低成本；

三是嚴把質(zhì)量關(guān)，杜絕返工現(xiàn)象。

3)經(jīng)濟措施

經(jīng)濟措施包括三個方面：

一是人工費控制管理；

二是材料費控制管理；

三是軟件測試工具費控制管理。

7.8軟件測試配置管理

一般來說，軟件測試配置管理包括5個最基本的活動。

1．配置標識一般認為，軟件生命周期各個階段活動的產(chǎn)物經(jīng)審批后即可稱為軟件配置項。軟件配置項包括：(1)與合同、過程、計劃和產(chǎn)品有關(guān)的文檔和資料；(2)源代碼、目標代碼和可執(zhí)行代碼；(3)相關(guān)產(chǎn)品，包括軟件工具、庫內(nèi)的可重用軟件、外購軟件及顧客提供的軟件等。

2．版本控制

在項目開發(fā)過程中，絕大部分的配置項都要經(jīng)過多次修改才能最終確定下來。對配置項的任何修改都將產(chǎn)生新的版本。由于我們不能保證新版本一定比老版本“好”，所以不能拋棄老版本。版本控制的目的是按照一定的規(guī)則保存配置項的所有版本，避免發(fā)生版本丟失或混淆的現(xiàn)象，并且可以快速準確地查找到配置項的任何版本。

3．變更控制

變更控制的目的并不是控制變更的發(fā)生，而是對變更進行管理，確保變更有序進行。對于軟件開發(fā)項目來說，發(fā)生變更的環(huán)節(jié)比較多，因此變更控制顯得格外重要。

項目中引起變更的因素有兩個：一是來自外部的變更要求，如客戶要求修改工作范圍和需求等；二是開發(fā)過程內(nèi)部的變更要求，如為解決測試中發(fā)現(xiàn)的一些錯誤而修改源碼甚至設(shè)計。比較而言，最難處理的是來自外部的需求變更，因為IT項目需求變更的概率大，引發(fā)的工作量也大。

4．配置狀態(tài)報告

配置狀態(tài)報告是用于記載軟件配置管理活動信息和軟件基線內(nèi)容的標準報告，其目的是及時、準確地給出軟件配置項的當(dāng)前狀態(tài)，使受影響的組和個人可以使用它，同時報告軟件開發(fā)活動的進展狀況。通過不斷的記錄狀態(tài)報告可以更好地進行統(tǒng)計分析，便于更好地控制配置項，更準確地報告開發(fā)進展狀況。

5．配置審計

配置審計是指在配置標識、配置控制、配置狀態(tài)記錄的基礎(chǔ)上對所有配置項的功能及內(nèi)容進行審查，以保證軟件配置項的可跟蹤性。

其主要任務(wù)是：

(1)檢查配置項是否完備，特別是關(guān)鍵的配置項是否遺漏；

(2)檢查所有配置項的基線是否存在，基線產(chǎn)生的條件是否齊全；

(3)檢查每份技術(shù)文檔作為某個配置項版本的簡述是否精確，是否與相關(guān)版本一致；

(4)檢查每項已批準的更改是否都已實現(xiàn)；

(5)檢查每項配置項更改是否按配置更改規(guī)程或有關(guān)標準進行；

(6)檢查每個配置管理人員的責(zé)任是否明確，是否盡到了應(yīng)盡的責(zé)任；

(7)檢查配置信息安全是否受到破壞，評估安全保護機制的有效性。第8章軟件自動化測試概述8.1軟件自動化測試的產(chǎn)生8.2軟件自動化測試的概念8.3軟件自動化測試的意義8.4開展自動化測試的方8.5軟件自動化測試的原理和方法8.6軟件自動化測試工具

8.1軟件自動化測試的產(chǎn)生

隨著計算機日益廣泛的應(yīng)用，計算機軟件越來越龐大和復(fù)雜，軟件測試的工作量也越來越大。隨著人們對軟件測試工作的重視，大量的軟件自動化測試工具不斷涌現(xiàn)出來，自動化測試能夠滿足軟件公司想在最短的進度內(nèi)充分測試其軟件的需求，一些軟件公司在這方面的投入，會對整個開發(fā)工作的質(zhì)量、成本和周期帶來非常明顯的效果。

8.2軟件自動化測試的概念

軟件自動化測試是一項讓計算機代替測試人員進行軟件測試的技術(shù)，是指編寫軟件去測試其他軟件。自動化測試的目標是對被測試系統(tǒng)進行自動測試?？偟膩碚f，自動化測試的目標是通過較少的開銷，得到更徹底的測試，并提高產(chǎn)品的質(zhì)量。

軟件自動化測試有如下特點：

(1)可以對程序的新版本自動執(zhí)行回歸測試；

(2)可以執(zhí)行一些手工測試困難或不可能進行的測試；

(3)可以更好地利用資源；

(4)測試具有一致性和可重復(fù)性；

(5)可以更快地將軟件推向市場；

(6)可以增加軟件信任度。

8.3軟件自動化測試的意義

軟件自動化測試就是一項讓計算機代替測試人員進行軟件測試的技術(shù)，相對于手工測試而言，自動化測試主要是通過所開發(fā)的軟件測試工具、腳本等來實現(xiàn)的，具有良好的可操作性、可重復(fù)性和高效率等特點。為了更好地理解自動化測試的意義，需要從三個方面考慮：一是手工測試的局限性；二是軟件自動化測試所帶來的好處；三是自動化測試的局限性。

1．手工測試的局限性

手工測試是不可替代的，因為人具有很強的判斷能力。

(1)通過手工測試無法做到覆蓋所有代碼路徑。

(2)簡單的功能性測試用例在每一輪測試中都不能少，而且具有一定的機械性、重復(fù)性，工作量往往較大。

(3)許多與時序、死鎖、資源沖突、多線程等有關(guān)的錯誤，通過手工測試很難捕捉到。

(4)進行系統(tǒng)負載、性能測試，需要模擬大量數(shù)據(jù)或大量并發(fā)用戶等各種應(yīng)用場合時，很難通過手工測試來進行。

(5)進行系統(tǒng)可靠性測試時，需要模擬系統(tǒng)運行10年、數(shù)十年，以驗證系統(tǒng)能否穩(wěn)定運行，這也是手工測試無法模擬的。

(6)如果有大量的測試用例，需要在短時間內(nèi)(如1天)完成，手工測試幾乎不可能做到。

(7)難以做到回歸測試。

2．軟件自動化測試所帶來的好處

自動化測試有很強的優(yōu)勢，即借助計算機的計算能力可以重復(fù)、不知疲倦地運行。

使用測試工具的目的就是要提高軟件測試的效率和軟件測試的質(zhì)量。通常，自動化測試的好處有：產(chǎn)生可靠的系統(tǒng)；改進測試工作質(zhì)量；減少測試工作量并加快測試進度。

1)產(chǎn)生可靠的系統(tǒng)

測試工作的主要目標一是找出缺陷，從而減少應(yīng)用中的錯誤；二是確保系統(tǒng)的性能滿足用戶的期望。

通過使用自動化測試可獲得的效果歸納如下：

(1)需求定義的改進；

(2)性能測試的改進；

(3)負載/壓力測試的改進；

(4)高質(zhì)量測量與測試最佳化；

(5)改進與開發(fā)組人員之間的關(guān)系；

(6)改進系統(tǒng)開發(fā)生命周期。

2)改進測試工作質(zhì)量

通過使用自動化測試工具，可增加測試的深度與廣度，改進測試工作質(zhì)量。其具體好處可歸納如下：

(1)改進多平臺兼容性測試；

(2)改進軟件兼容性測試；

(3)改進普通測試執(zhí)行；

(4)使測試集中于高級測試問題；

(5)可執(zhí)行手工測試無法完成的測試；

(6)可重現(xiàn)軟件缺陷；

(7)測試無需用戶干預(yù)。

3)減少測試工作量并加快測試進度

善于使用測試工具來進行測試，其節(jié)省時間并加快測試工作進度是毋庸置疑的，這也是自動化測試的主要優(yōu)點。

3．自動化測試的局限性

1)自動化測試不能取代手工測試

自動化測試絕不能代替手工測試，下列情況不適合于自動化測試：

(1)周期短并且一次性的項目。

(2)進度非常緊張的項目。

(3)使用了很多第三方或自定義控件的項目。(4)軟件不穩(wěn)定，如軟件升級版本時，用戶界面和功能頻繁變化，此時自動化測試相應(yīng)部分修改的開銷較大。

(5)結(jié)果很容易通過人驗證的測試。

(6)涉及物理交互的測試，如在讀卡機上劃卡，斷開設(shè)備的物理連接、開關(guān)電源等。

2)手工測試比自動測試發(fā)現(xiàn)的故障要多

自動化測試主要是進行重復(fù)測試。一般情況下，自動化測試進行的工作是以前進行過的，因此被測試軟件在自動化測試中暴露的故障要少得多。

自動化測試主要用于回歸測試，進行正確性驗證測試，而不是故障發(fā)現(xiàn)測試。據(jù)經(jīng)驗數(shù)據(jù)統(tǒng)計，自動化測試只能發(fā)現(xiàn)約15%的故障，而手工測試可以發(fā)現(xiàn)約85%的故障。

3)自動化測試不能提高測試的有效性

自動化測試僅用于提高測試的效率，即減少測試的開銷和時間。

4)自動化測試不具有想象力

(1)自動化測試是通過測試軟件進行的，測試過程只是按照運行機制執(zhí)行。手工測試時可以直接判斷測試結(jié)果的正確性，而自動化測試在許多情況下的測試結(jié)果還需要人工干預(yù)判斷。

(2)手工測試可以處理意外事件，如網(wǎng)絡(luò)連接中斷，此時必須重新建立連接。手工測試時可以及時處理該意外，而自動化測試時該意外事件一般都會導(dǎo)致測試的中止。

8.4開展自動化測試的方法

1．選取合適的測試項目來開展自動化測試自動化測試只有在多次運行后，才能體現(xiàn)出自動化的優(yōu)勢，只有不斷地運行自動化測試才能有效預(yù)防缺陷、減輕測試人員手工的回歸測試的工作量。如果一個項目是短期的并且是一次性的項目，則不適合開展自動化測試。

2．自動化測試介入的時機

過早的自動化測試會帶來維護成本的增加，因為早期的程序界面一般不夠穩(wěn)定，處于頻繁更改的狀態(tài)，這時候進行自動化測試往往得不償失，疲于應(yīng)付“動蕩”的界面。

自動化測試不應(yīng)該在界面尚未穩(wěn)定的時候開始，但是，并不意味著不需要計劃和準備工作。在項目初期，就要考慮工具的選擇問題。

3．自動化測試工程師的基本素質(zhì)和技能要求

自動化測試工程師應(yīng)該具備一定的自動化測試基礎(chǔ)，包括自動化測試工具的基礎(chǔ)、自動化測試腳本的開發(fā)基礎(chǔ)知識等；還需要了解各種測試腳本的編寫、設(shè)計方法，知道在什么時候選取怎樣的測試腳本開發(fā)方式和如何維護測試腳本；需要具備一定的編程技巧，熟悉某些測試腳本語言的基本語法和使用方法。

4．自動化測試的成本

成功開展自動化測試必須考慮自動化測試的成本問題。成本包括測試人員、測試設(shè)備、測試工具等。

8.5軟件自動化測試的原理和方法

1．代碼分析代碼分析類似于高級編譯系統(tǒng)，一般針對不同的高級語言構(gòu)造分析工具，在工具中定義類、對象、函數(shù)、變量等的定義規(guī)則、語法規(guī)則；在分析時對代碼進行語法掃描，找出不符合編碼規(guī)范的地方；根據(jù)某種質(zhì)量模型評價代碼質(zhì)量，生成系統(tǒng)的調(diào)用關(guān)系圖等。

2．捕獲和回放

代碼分析是一種白盒測試的自動化方法，捕獲和回放則是一種黑盒測試的自動化方法。

捕獲是將用戶每一步操作都記錄下來。這種記錄的方式有兩種：程序用戶界面的像素坐標或程序顯示對象(窗口、按鈕、滾動條等)的位置，以及相對應(yīng)的操作、狀態(tài)變化或是屬性變化。所有的記錄轉(zhuǎn)換為一種腳本語言所描述的過程，以模擬用戶的操作。

3．腳本技術(shù)

腳本是一個特定測試的一系列指令，這些指令可以被自動化測試工具執(zhí)行。腳本可以通過錄制測試的操作產(chǎn)生，然后再做修改，這樣可以減少腳本編程的工作量。當(dāng)然，也可以直接用腳本語言編寫腳本。

腳本的產(chǎn)生有兩種方式：一種是通過錄制測試的操作產(chǎn)生；另一種是直接用腳本語言編寫。

腳本技術(shù)可以分為以下幾類：

(1)線性腳本：是錄制手工執(zhí)行的測試用例得到的腳本。

(2)結(jié)構(gòu)化腳本：類似于結(jié)構(gòu)化程序設(shè)計，具有各種邏輯結(jié)構(gòu)(順序、分支、循環(huán))，而且具有函數(shù)調(diào)用功能。

(3)共享腳本：是指某個腳本可被多個測試用例使用，即腳本語言允許一個腳本調(diào)用另一個腳本。

(4)數(shù)據(jù)驅(qū)動腳本：是指將測試輸入存儲在獨立的數(shù)據(jù)文件中。

(5)關(guān)鍵字驅(qū)動腳本：是數(shù)據(jù)驅(qū)動腳本的邏輯擴展。

4．虛擬用戶技術(shù)

虛擬用戶技術(shù)通過模擬真實用戶的行為來對被測程序(ApplicationUnderTest，AUT)施加負載，以測量AUT的性能指標值，如事務(wù)的響應(yīng)時間、服務(wù)器的吞吐量等。

虛擬用戶技術(shù)以真實用戶的“商務(wù)處理”(用戶為完成一個商業(yè)業(yè)務(wù)而執(zhí)行的一系列操作)作為負載的基本組成單位，用“虛擬用戶”(模擬用戶行為的測試腳本)來模擬真實用戶。

8.6軟件自動化測試工具

8.6.1測試工具分類1．按照測試方法分類1)白盒測試工具白盒測試工具一般是針對代碼進行測試，常用的白盒測試工具集有Parasoft和Compuware,見表8-1和表8-2。測試中發(fā)現(xiàn)的缺陷可以定位到代碼級，根據(jù)測試工具原理的不同，又可以分為靜態(tài)測試工具和動態(tài)測試工具。

(1)靜態(tài)測試工具：直接對代碼進行分析，不需要運行代碼，