引言
1963年，在美國發(fā)生了這樣一件事：編程人員把一個FORTRAN程序的循環(huán)語句DO 5 I=1，3誤寫為DO 5 I=1.3。一點(diǎn)之差導(dǎo)致飛往火星的火箭爆炸，造成1000多萬美元的損失。這種情況的發(fā)生，迫使人們考慮在軟件投入使用之前必須進(jìn)行徹底的測試。今天，在軟件比較發(fā)達(dá)的國家，軟件測試已經(jīng)成為一個獨(dú)立的產(chǎn)業(yè)，軟件公司紛紛建立獨(dú)立的測試隊伍研究測試技術(shù)并開展測試工作。中國的軟件測試起步較晚，但隨著我國軟件產(chǎn)業(yè)的蓬勃發(fā)展以及人們對軟件質(zhì)量的重視，軟件測試正在成為一個新興的產(chǎn)業(yè)。近兩年來，國內(nèi)新成立專業(yè)性測試機(jī)構(gòu)10余家，一批批專業(yè)的軟件測試人員正涌現(xiàn)出來。每年國內(nèi)都有大量的測試技術(shù)交流會議舉辦，有大量的測試研究論文在專業(yè)刊物上發(fā)表。在測試技術(shù)發(fā)展的同時，測試過程的管理顯得猶為重要。一個成功的測試項目，離不開對測試過程科學(xué)的組織和監(jiān)控，過程管理已成為測試成功的重要保證。
1 測試過程概述
1．1 軟件測試過程概述
??? 軟件測試過程是一種抽象的模型，用于定義軟件測試的流程和方法。眾所周知，開發(fā)過程的質(zhì)量決定了軟件的質(zhì)量，同樣的，測試過程的質(zhì)量將直接影響測試結(jié)果的準(zhǔn)確性和有效性。軟件測試過程和軟件開發(fā)過程一樣，都遵循軟件工程原理，遵循管理學(xué)原理。
??? 隨著測試過程管理的發(fā)展，軟件測試專家通過實踐總結(jié)出了很多很好的測試過程模型。這些模型將測試活動進(jìn)行了抽象，并與開發(fā)活動有機(jī)的進(jìn)行了結(jié)合，是測試過程管理的重要參考依據(jù)。
1．2 軟件測試過程模型介紹
Ｖ模型
??? V模型最早是由Paul Rook在２０世紀(jì)８０年代后期提出的，旨在改進(jìn)軟件開發(fā)的效率和效果。Ｖ模型反映出了測試活動與分析設(shè)計活動的關(guān)系。在圖1-1中，從左到右描述了基本的開發(fā)過程和測試行為，非常明確的標(biāo)注了測試過程中存在的不同類型的測試，并且清楚的描述了這些測試階段和開發(fā)過程期間各階段的對應(yīng)關(guān)系。
?
圖1-1 軟件測試V模型
??? V模型指出，單元和集成測試應(yīng)檢測程序的執(zhí)行是否滿足軟件設(shè)計的要求；系統(tǒng)測試應(yīng)檢測系統(tǒng)功能、性能的質(zhì)量特性是否達(dá)到系統(tǒng)要求的指標(biāo)；驗收測試確定軟件的實現(xiàn)是否滿足用戶需要或合同的要求。
但V模型存在一定的局限性，它僅僅把測試作為在編碼之后的一個階段，是針對程序進(jìn)行的尋找錯誤的活動，而忽視了測試活動對需求分析、系統(tǒng)設(shè)計等活動的驗證和確認(rèn)的功能。
Ｗ模型
??? W模型由Evolutif公司公司提出，相對于V模型，W模型增加了軟件各開發(fā)階段中應(yīng)同步進(jìn)行的驗證和確認(rèn)活動。如圖1-2所示，W模型由兩個V字型模型組成，分別代表測試與開發(fā)過程，圖中明確表示出了測試與開發(fā)的并行關(guān)系。
??? W模型強(qiáng)調(diào)：測試伴隨著整個軟件開發(fā)周期，而且測試的對象不僅僅是程序，需求、設(shè)計等同樣要測試，也就是說，測試與開發(fā)是同步進(jìn)行的。W模型有利于盡早地全面的發(fā)現(xiàn)問題。例如，需求分析完成后，測試人員就應(yīng)該參與到對需求的驗證和確認(rèn)活動中，以盡早地找出缺陷所在。同時，對需求的測試也有利于及時了解項目難度和測試風(fēng)險，及早制定應(yīng)對措施，這將顯著減少總體測試時間，加快項目進(jìn)度。
??? 但W模型也存在局限性。在W模型中，需求、設(shè)計、編碼等活動被視為串行的，同時，測試和開發(fā)活動也保持著一種線性的前后關(guān)系，上一階段完全結(jié)束，才可正式開始下一個階段工作。這樣就無法支持迭代的開發(fā)模型。對于當(dāng)前軟件開發(fā)復(fù)雜多變的情況，W模型并不能解除測試管理面臨著困惑。
?
?
圖1-2 軟件測試W模型
Ｈ模型
??? V模型和W模型均存在一些不妥之處。如前所述，它們都把軟件的開發(fā)視為需求、設(shè)計、編碼等一系列串行的活動，而事實上，這些活動在大部分時間內(nèi)是可以交叉進(jìn)行的，所以，相應(yīng)的測試之間也不存在嚴(yán)格的次序關(guān)系。同時，各層次的測試（單元測試、集成測試、系統(tǒng)測試等）也存在反復(fù)觸發(fā)、迭代的關(guān)系。
為了解決以上問題，有專家提出了H模型。它將測試活動完全獨(dú)立出來，形成了一個完全獨(dú)立的流程，將測試準(zhǔn)備活動和測試執(zhí)行活動清晰地體現(xiàn)出來，如圖1-3所示。
?
??
圖1-3 軟件測試H模型
??? 這個示意圖僅僅演示了在整個生產(chǎn)周期中某個層次上的一次測試“微循環(huán)”。圖中標(biāo)注的其他流程可以是任意的開發(fā)流程。例如，設(shè)計流程或編碼流程。也就是說，只要測試條件成熟了，測試準(zhǔn)備活動完成了，測試執(zhí)行活動就可以（或者說需要）進(jìn)行了。
?
??? H模型揭示了一個原理：軟件測試是一個獨(dú)立的流程，貫穿產(chǎn)品整個生命周期，與其他流程并發(fā)地進(jìn)行。H模型指出軟件測試要盡早準(zhǔn)備，盡早執(zhí)行。不同的測試活動可以是按照某個次序先后進(jìn)行的，但也可能是反復(fù)的，只要某個測試達(dá)到準(zhǔn)備就緒點(diǎn)，測試執(zhí)行活動就可以開展。
其他模型
??? 除上述幾種常見模型外，業(yè)界還流傳著其他幾種模型，例如X模型、前置測試模型等。X模型提出針對單獨(dú)的程序片段進(jìn)行相互分離的編碼和測試，此后通過頻繁的交接，通過集成最終合成為可執(zhí)行的程序。前置測試模型體現(xiàn)了開發(fā)與測試的結(jié)合，要求對每一個交付內(nèi)容進(jìn)行測試。這些模型都針對其他模型的缺點(diǎn)提出了一些修正意見，但本身也可能存在一些不周到的地方。所以在測試過程管理中，正確選取過程模型是一個關(guān)鍵問題。
1．3 軟件測試過程模型選取策略
??? 前面介紹的測試過程模型中，V模型強(qiáng)調(diào)了在整個項目開發(fā)中需要經(jīng)歷的不同的測試級別，但忽視了測試的對象不應(yīng)該僅僅是程序。而W模型在這一點(diǎn)上進(jìn)行了補(bǔ)充，明確指出應(yīng)該對需求、設(shè)計進(jìn)行測試。但是V模型和W模型都沒有將一個完整的測試過程抽象出來，成為一個獨(dú)立的流程，這并不適合當(dāng)前軟件開發(fā)中廣泛應(yīng)用的迭代模型。H模型則明確指出測試的獨(dú)立性，也就是說只要測試條件成熟了，就可以開展測試。
??? 在實際測試工作中我們應(yīng)該盡可能地去應(yīng)用各模型中對項目有實用價值的方面，不能強(qiáng)行的為使用模型而使用模型。在測試實踐中，我們采用的方法是：以W模型作為框架，及早的、全面的開展測試。同時靈活運(yùn)用H模型獨(dú)立測試的思想，在達(dá)到恰當(dāng)?shù)木途w點(diǎn)時就應(yīng)該開展獨(dú)立的測試工作，同時將測試工作進(jìn)行迭代，最終保證完成測試目標(biāo)。
2 測試過程管理理念
??? 生命周期模型為我們提供了軟件測試的流程和方法，為測試過程管理提供了依據(jù)。但實際的測試工作是復(fù)雜而煩瑣的，可能不會有哪種模型完全適用于某項測試工作。所以，我們應(yīng)該從不同的模型中抽象出符合實際現(xiàn)狀的測試過程管理理念，依據(jù)這些理念來策劃測試過程，以不變應(yīng)萬變。當(dāng)然測試管理牽涉的范圍非常的廣泛，包括過程定義、人力資源管理、風(fēng)險管理等等，本節(jié)僅介紹幾條從過程模型中提煉出來的，對實際測試有指導(dǎo)意義的管理理念。
2．1 盡早測試
??? “盡早測試”是從W模型中抽象出來的理念。我們說測試并不是在代碼編寫完成之后才開展的工作，測試與開發(fā)是兩個相互依存的并行的過程，測試活動在開發(fā)活動的前期已經(jīng)開展。
??? “盡早測試”包含兩方面的含義：第一，測試人員早期參與軟件項目，及時開展測試的準(zhǔn)備工作，包括編寫測試計劃、制定測試方案以及準(zhǔn)備測試用例；第二，盡早的開展測試執(zhí)行工作，一旦代碼模塊完成就應(yīng)該及時開展單元測試，一旦代碼模塊被集成成為相對獨(dú)立的子系統(tǒng)，便可以開展集成測試，一旦有BUILD提交，便可以開展系統(tǒng)測試工作。
??? 由于及早的開展了測試準(zhǔn)備工作，測試人員能夠于早期了解測試的難度、預(yù)測測試的風(fēng)險，從而有效提高了測試效率，規(guī)避測試風(fēng)險。由于及早的開展測試執(zhí)行工作，測試人員盡早的發(fā)現(xiàn)軟件缺陷，大大降低了BUG修復(fù)成本。但是需要注意，“盡早測試”并非盲目的提前測試活動，測試活動開展的前提是達(dá)到必須的測試就緒點(diǎn)。
2．2 全面測試
??? 軟件是程序、數(shù)據(jù)和文檔的集合，那么對軟件進(jìn)行測試，就不僅僅是對程序的測試，還應(yīng)包括軟件“副產(chǎn)品”的“全面測試”，這是W模型中一個重要的思想。需求文檔、設(shè)計文檔作為軟件的階段性產(chǎn)品，直接影響到軟件的質(zhì)量。階段產(chǎn)品質(zhì)量是軟件質(zhì)量的量的積累，不能把握這些階段產(chǎn)品的質(zhì)量將導(dǎo)致最終軟件質(zhì)量的不可控。
??? “全面測試”包含兩層含義：第一，對軟件的所有產(chǎn)品進(jìn)行全面的測試，包括需求、設(shè)計文檔，代碼，用戶文檔等等。第二，軟件開發(fā)及測試人員（有時包括用戶）全面的參與到測試工作中，例如對需求的驗證和確認(rèn)活動，就需要開發(fā)、測試及用戶的全面參與，畢竟測試活動并不僅僅是保證軟件運(yùn)行正確，同時還要保證軟件滿足了用戶的需求。
??? “全面測試”有助于全方位把握軟件質(zhì)量，盡最大可能的排除造成軟件質(zhì)量問題的因素，從而保證軟件滿足質(zhì)量需求。
2．3 全過程測試
??? 在W模型中充分體現(xiàn)的另一個理念就是“全過程測試”。雙V字過程圖形象的表明了軟件開發(fā)與軟件測試的緊密結(jié)合，這就說明軟件開發(fā)和測試過程會彼此影響，這就要求測試人員對開發(fā)和測試的全過程進(jìn)行充分的關(guān)注。
??? “全過程測試”包含兩層含義：第一，測試人員要充分關(guān)注開發(fā)過程，對開發(fā)過程的各種變化及時做出響應(yīng)。例如開發(fā)進(jìn)度的調(diào)整可能會引起測試進(jìn)度及測試策略的調(diào)整，需求的變更會影響到測試的執(zhí)行等等。第二，測試人員要對測試的全過程進(jìn)行全程的跟蹤，例如建立完善的度量與分析機(jī)制，通過對自身過程的度量，及時了解過程信息，調(diào)整測試策略。
??? “全過程測試”有助于及時應(yīng)對項目變化，降低測試風(fēng)險。同時對測試過程的度量與分析也有助于把握測試過程，調(diào)整測試策略，便于測試過程的改進(jìn)。
2．4 獨(dú)立的、迭代的測試
??? 我們知道，軟件開發(fā)瀑布模型只是一種理想狀況。為適應(yīng)不同的需要，人們在軟件開發(fā)過程中摸索出了如螺旋、迭代等諸多模型，這些中需求、設(shè)計、編碼工作可能重疊并反復(fù)進(jìn)行的，這時的測試工作將也是迭代和反復(fù)的。如果不能將測試從開發(fā)中抽象出來進(jìn)行管理，勢必使測試管理陷入困境。
??? 軟件測試與軟件開發(fā)是緊密結(jié)合的，但并不代表測試是依附于開發(fā)的一個過程，測試活動是獨(dú)立的。這正是H模型所主導(dǎo)的思想?！蔼?dú)立的、迭代的測試”著重強(qiáng)調(diào)了測試的就緒點(diǎn)，也就是說，只要測試條件成熟，測試準(zhǔn)備活動完成，測試的執(zhí)行活動就可以開展。
??? 所以，我們在遵循盡早測試、全面測試、全過程測試?yán)砟畹耐瑫r，應(yīng)當(dāng)將測試過程從開發(fā)過程中適當(dāng)?shù)某橄蟪鰜恚鳛橐粋€獨(dú)立的過程進(jìn)行管理。時刻把握獨(dú)立的、迭代測試的理念，減小因開發(fā)模型的繁雜給測試管理工作帶來的不便。對于軟件過程中不同階段的產(chǎn)品和不同的測試類型，只要測試準(zhǔn)備工作就緒，就可以及時開展測試工作，把握產(chǎn)品質(zhì)量。
3 測試過程管理實踐
??? 本節(jié)以一個實際項目系統(tǒng)測試過程（不對單元測試和集成測試過程進(jìn)行分析）的幾個關(guān)鍵過程管理行為為例，來闡述上節(jié)中提出的測試?yán)砟?。在一個構(gòu)件化ERP項目中，由于前期需求不明確，開發(fā)周期相對較長，為了對項目進(jìn)行更好的跟蹤和管理，項目采用增量和迭代模型進(jìn)行開發(fā)。整個項目開發(fā)共分三個階段完成：第一階段實現(xiàn)進(jìn)銷存的簡單的功能和工作流；第二階段：實現(xiàn)固定資產(chǎn)管理、財務(wù)管理，并完善第一階段的進(jìn)銷存功能；第三階段：增加辦公自動化的管理（OA）。該項目每一階段工作是對上一階段成果的一次迭代完善，同時將新功能進(jìn)行了一次疊加。
3．1 策劃測試過程
??? 依據(jù)傳統(tǒng)的方法，將系統(tǒng)測試作為軟件開發(fā)的一個階段，系統(tǒng)測試執(zhí)行工作將在三個階段完成后開展，很明顯，這樣做不利于BUG的及時暴露。有些缺陷可能會埋藏至后期發(fā)現(xiàn)，這時的修復(fù)成本將大大提高。我們依據(jù)“獨(dú)立和迭代”的測試?yán)砟?，在本系統(tǒng)中，對測試過程進(jìn)行獨(dú)立的策劃，找出測試準(zhǔn)備就緒點(diǎn)，在就緒點(diǎn)及時開展測試。該系統(tǒng)的三個階段具有相對的獨(dú)立性，在每一階段完成所提交的階段產(chǎn)品具有相對的獨(dú)立性，可以作為系統(tǒng)測試準(zhǔn)備的就緒點(diǎn)。故而，在該系統(tǒng)開發(fā)過程中，系統(tǒng)測試組計劃開展三階段的系統(tǒng)測試，每個階段系統(tǒng)測試具有不同的側(cè)重點(diǎn)，目的在于更好的配合開發(fā)工作盡早發(fā)現(xiàn)軟件BUG，降低軟件成本。軟件開發(fā)與系統(tǒng)測試過程的關(guān)系如圖3-1所示。
??? 實踐證明，這種做法起到了預(yù)期的效果，與開發(fā)過程緊密結(jié)合而又相對獨(dú)立的測試過程，有效的于早期發(fā)現(xiàn)了許多系統(tǒng)缺陷，降低了開發(fā)成本，同時也使基于復(fù)雜開發(fā)模型的測試管理工作更加清晰明了。
??
3．2 把握需求
??? 在本系統(tǒng)開發(fā)過程中，需求的獲取和完善貫穿每個階段。對需求的把握很大程度上決定了軟件測試是否能夠成功。系統(tǒng)測試不僅僅確認(rèn)軟件是否正確實現(xiàn)功能，同時還要確認(rèn)軟件是否滿足用戶的需要。依據(jù)“盡早測試”和“全面測試”原則，在需求的獲取階段，測試人員參與到了對需求的討論之中。測試人員與開發(fā)人員及用戶一起討論需求的完善性與正確性，同時從可測試性角度為需求文檔提出建議。這些建議對開發(fā)人員來說，是從一個全新的思維角度提出的約束。同時，測試組結(jié)合前期對項目的把握，很容易制定出了完善的測試計劃和方案，將各階段產(chǎn)品的測試方法及進(jìn)度、人員安排進(jìn)行了策劃，使整個項目的進(jìn)展有條不紊。
實踐證明，測試人員早期參與需求的獲取和分析中，有助于加深測試人員對需求的把握和理解，同時也大大促進(jìn)需求文檔的質(zhì)量。在需求人員把握需求的同時，于早期制定項目計劃和方案，及早準(zhǔn)備測試活動，大大提高了測試效率。
3．3 變更控制
??? 變更控制體現(xiàn)的是“全過程測試”理念。在軟件開發(fā)過程中，變更往往是不可避免的，變更也是造成軟件風(fēng)險的重要因素。在本系統(tǒng)測試中，僅第一階段就發(fā)生了7次需求變更，調(diào)整了兩次進(jìn)度計劃。依據(jù)“全過程測試”理念，測試組密切關(guān)注開發(fā)過程，跟隨進(jìn)度計劃的變更調(diào)整測試策略，依據(jù)需求的變更及時補(bǔ)充和完善測試用例。由于充分的測試準(zhǔn)備工作，在測試執(zhí)行過程中，沒有廢棄一個測試用例，測試的進(jìn)度并沒有因為變更而受到過多影響。
3．4 度量與分析
??? 對測試過程的度量與分析同樣體現(xiàn)的“全過程測試”理念。對測試過程的度量有利于及時把握項目情況，對過程數(shù)據(jù)進(jìn)行分析，很容易發(fā)現(xiàn)優(yōu)勢劣勢，找出需要改進(jìn)的地方，及時調(diào)整測試策略。
??? 在ERP項目中，我們在測試過程中對不同階段的BUG數(shù)量進(jìn)行了度量，并分析測試執(zhí)行是否充分。如圖3-2所示，通過分析我們得出：相同時間間隔內(nèi)發(fā)現(xiàn)的BUG數(shù)量呈收斂狀態(tài)，測試是充分的。在BUG數(shù)量收斂的狀態(tài)下結(jié)束細(xì)測是恰當(dāng)?shù)摹?br />?
圖3-2 軟件開發(fā)與系統(tǒng)測試關(guān)系圖
??? 測試中，我們對不同功能點(diǎn)的測試數(shù)據(jù)覆蓋率和發(fā)現(xiàn)問題數(shù)進(jìn)行度量，以便分析測試用例的充分度與BUG發(fā)現(xiàn)率之間的關(guān)系。如表3-1所示，對類似模塊進(jìn)行對比發(fā)現(xiàn)：某一功能點(diǎn)上所覆蓋的測試數(shù)據(jù)組越多，BUG的用例發(fā)現(xiàn)率越高。如果再結(jié)合工作量、用例執(zhí)行時間等因素進(jìn)行統(tǒng)計分析，便可以找到適合實際情況的測試用例書寫粒度，從而幫助測試人員判斷測試成本和收益間的最佳平衡點(diǎn)。
表3-1 測試數(shù)據(jù)覆蓋率與BUG發(fā)現(xiàn)率對應(yīng)表
模塊名稱?功能點(diǎn)數(shù)?測試數(shù)據(jù)數(shù)?測試數(shù)據(jù)覆蓋率?BUG的用例發(fā)現(xiàn)率（）
模塊AA?6個?75組?12.5組/每功能點(diǎn)?40% （6/15）
模塊BB?30個?96組?3.3組/每功能點(diǎn)?17% （7/42）
模塊CC?15個?87組?5.1組/每功能點(diǎn)?18% （5/28）
模塊DD?16個?46組?2.8組/每功能點(diǎn)?23% （5/22）
…?…????????? …?…?...
注：通過統(tǒng)計可以得出測試數(shù)據(jù)與BUG發(fā)現(xiàn)率之間的關(guān)系，便于及時調(diào)整測試用例編寫策略。
??? 所有這些度量都是對測試全過程進(jìn)行跟蹤的結(jié)果，是及時調(diào)整測試策略的依據(jù)。對測試過程的度量與分析能有效的提高了測試效率，降低了測試風(fēng)險。同時，度量與分析也是軟件測試過程可持續(xù)改進(jìn)的基本。
4 測試過程可持續(xù)改進(jìn)
??? 測試技術(shù)發(fā)展到今天，已經(jīng)存在諸多可供參考的測試過程管理思想和理念。但信息技術(shù)發(fā)展一日千里，新技術(shù)不斷涌現(xiàn)，這就注定測試過程也需要不斷的改進(jìn)。我們提倡基于度量與分析的可持續(xù)過程改進(jìn)方法（本文不做詳細(xì)論述）。在這種方法中，對現(xiàn)狀的度量被制度化，并作為過程改進(jìn)的基礎(chǔ)。組織可以自定義需要度量的過程數(shù)據(jù)，將收集來的數(shù)據(jù)加以分析，以找出需要改進(jìn)的因素。在不斷的改進(jìn)中，同步的調(diào)整需要度量的過程數(shù)據(jù)，使度量與分析始終為了過程改進(jìn)服務(wù)，而過程改進(jìn)也包含對度量和分析的改進(jìn)。
??? 掌握了基于度量和分析的可持續(xù)過程改進(jìn)方法，測試過程管理將能夠不斷完善，測試活動將能夠始終處于優(yōu)化狀態(tài)。