摘要：本文對于常用的
軟件開發模式和
測試模式進行比較后，著重介紹了針對新型的開發模式——
敏捷開發的測試模式，并對于這種測試模式的優缺點進行分析及本測試模式在實際項目中的運用，并介紹了
自動化測試管理工具TD（
Test Director）和自動化
功能測試工具
QTP（Quick Test Professional）在新型測試模式中的應用。
關鍵字：敏捷開發；測試模式；TD；QTP；
（一）前言
敏捷開發是一個迭代的、增量的、需求頻繁變更的過程，客戶每周都希望看到新變化，而這些變化最直觀體現給客戶的就是產品功能的增減，這種非常短的循環，使終端客戶可以及時、快速地看到他們花錢構建的軟件是一個什么樣的結果。因此直接做成可以工作的軟件比大量的描述性文檔更有效。
正因為敏捷開發的特殊性，敏捷開發的測試無法像傳統測試那樣：項目初期根據詳細的需求文檔、設計文檔來設計測試用例。因為最初的需求只是一個雛形，甚至連界面也沒定，做成什么樣子，有什么樣的功能開發也不能確定，只能一步步的與客戶確認和修改才能定下來；因此用例設計只 能通過產品寫用例；即先根據簡單的需求寫出用例的框架，然后拿到產品后，一邊添加測試用例一邊進行測試。同時敏捷開發的測試模式與傳統測試模式不同的還有 一個方面，那就是包括PM、開發人員等也都會一起投入測試。提高系統質量是個Team work，在開發過程中每個成員都有責任提交高質量的軟件交付物（需求、代碼、設計文檔...），尤其我們團隊的“敏捷開發”的項目中，我們還面臨人員缺 乏、項目多而分散的背景，更加需要整個團隊都必須積極投入到測試過程中，PM、DEV、測試都需要積極參與測試和項目的質量保證工作。
（二）介紹新型的測試模式
圖1 敏捷開發測試模式
從圖1 不同的環中表示不同的敏捷實踐，外環主要是開發的角度，內環為測試的角度。
測試計劃和用例：在測試初期，主要是審核用戶需求（FRD）定義的完整性、嚴密性和功能設計的可測性，然后根據用戶需求設計測試計劃。測試計劃主要說明，（1）測試資源：在測試過程中需要的軟件（包括操作系統，補丁版本，數據庫版本，被測軟件版本，還有諸如打印機、掃描儀等外部信息）和人力資源；（2）測試內容：測試的功能點，測試的類型（功能測試，性能測試， 安全性測試，壓力測試等）測試的方法，哪些可以自動化測試，哪些需要手動測試。如果是后期，主要是設計測試用例，包括性能測試用例，功能測試用例以及界面 測試用例。同時完成配置庫的配置，平臺的搭建等內容，如一些管理工具（CQ，TestDirector，SVN）以及用戶分配等。這個階段主要輸出：測試 計劃和測試用例。
更新測試：如果是在迭代（發布不同版本）過程中，客戶可以根據上次所提供的產品做出一些新的合理的變更，這時我們需要根據變更來更新測試用例。準備在下一個版本中進行測試，也是新版本測試的重點。
執行測試：這時的測試主要分為兩大類：接口測試和功能測試。接口測試推薦開發人員在提交代碼前直接運行自動單元測試腳 本來驗證。功能測試：新功能代碼提交后，由測試人員單獨執行，首先會驗證需求文檔中的基本功能，一旦出現問題，那就說明開發人員的實現違反了最初客戶定義 的需求，應及時向開發說明問題，并且和客戶溝通，確認開發和測試理解是否一致。之后再進行其它全面的功能測試，那么測試人員要及時與開發人員溝通。同時提 交缺陷并且跟蹤。這個階段輸出的制品是：本版新的測試用例的執行，缺陷記錄。
自動化測試：主要用于回歸測試階段。在發布周期中，隨著功能的不完添加與完善，回歸測試的任務也就越來越重，同時也是必不可少的。
（三）新型測試模式在實際項目的運用 實際參與測試的敏捷開發項目是Webpos。該項目就是采用的敏捷開發的模式：接受客戶頻繁的需求變更來適應變化；經常性地交付可以工作的軟件，交付的間隔一般為一周。這就要求測試組在短期內迅速的對應新增或者變更的需求進行驗證測試。我們采用的測試流程如圖2：
敏捷開發web項目測試流程
圖2 測試流程
在WebPos 項目的測試中，貫穿全部測試的主要是新增功能測試和回歸測試。測試執行的一開始可以是針對部分功能的，之后可以逐步擴展。接著開始采用迭代的過程完成測試 任務，即將測試任務劃分為多個周期，一開始可以做些關鍵的功能性測試，可以對代碼中的可復用部分（組件，構件）做完整的測試。接著的迭代周期可以做邊緣化 的功能測試和其他測試，最后的幾個迭代應該用于回歸測試，和關鍵的性能和穩定性測試。特別是回歸測試尤為重要，最好的方式就是采用自動化測試工具來提高測 試效率。因此我們引入了測試管理工具TestDirector 和自動化測試工具Quick Test Professional（QTP）。這樣在每次發布版本時，TD 上面可以建立一個新的測試集。如圖3 所示。
圖3 TD 測試集
導入自動化測試腳本，運行完畢后對回歸測試結果進行分析。自動化測試結果如果出現錯誤，一般是兩個原因：一是程序本 身就存在缺陷，二是由于測試腳本錯誤的原因。測試人員可以通過錯誤結果分析出錯的原因：程序本身的問題就提交給開發人員進行修改；若是測試腳本的問題，則 由測試人員自己修正測試腳本。執行完畢后，可以將執行結果導出保存為回歸測試記錄。
利用QTP進行自動化測試：開發人員完成本版新增功能或者需求變更的編碼工作，遺留版本的缺陷修改后，會給客戶提交一個相對比較完善的版本。這時測 試人員需要對功能進行測試。對于新增的功能，由于測試時間的緊迫，一般是以小時來計算的，無法在短時間內添加新增功能的自動化測試腳本，所以當時采用手工 測試，等功能穩定后再添加自動化測試用例的方式；同時對于一直穩定的功能，進行回歸測試。如圖4，建立功能測試流。
圖4 功能測試流
自動化測試用例也是通過TestDirector 來管理，可分模塊和功能來管理，不同的測試人員也可以隨時添加和更新測試用例的腳本。在執行測試階段中，測試人員需要對已有的測試用例進行及時的維護。通 常以下兩種情況下要新增一些測試用例：一是對于當初測試設計不周全的領域，二是對于外部的Bug（比如從客戶報告來的），沒有被現有測試用例所覆蓋。當產 品的功能設計出現更改時和現有的功能需求同步。如下圖5：
圖5 自動化測試用例
測試結果的分析同回歸測試結果分析。
在每一次提交版本后，把開發人員和顧客代表包括進來，不要只是測試員自己做測試，開發也和測試人員一起測試新的版本。計劃在每個迭代中探索產品，尋找bug、遺漏的問題和改進的機會。
（四）新型測試模式在敏捷開發中的優點
1、可以快速對應頻繁的變更。
由于敏捷式開發持續地改進設計，以便于每次迭代結束生成的系統都具有最適合于那次迭代中需求的設計。那頻繁的變更和版本的發布，只能通過自動化測試來保證已經確認的功能，而新功能和需求的測試成相應版本的重點。
2、自動化測試，減小人力或者重復勞動。
純粹的自動化功能測試，而不是手工測試。即使測試用例有上千個，自動化測試也可以每天可以回歸幾十次。而手工測試如果要回歸，將花費大量的人力和重復勞動。
也許，測試最重要的好處就是它對于構架和設計的影響。為了使一個模塊或者應用程序具有可測試性，必須對它進行解耦合。越是具有可測試性，耦合關系就越弱。全面的考慮驗收測試和單元測試的行為對于軟件的結構具有深遠的正面的影響。
（五）新型測試模式的不足
1、頻繁的變更，對自動化測試架構提出了更高的要求。
由于自動化功能測試是基本UI 的測試，如果是頻繁的變更，不便于自動化腳本的維護。那么這就對代碼的架構提出更高的要求，怎么樣讓自動測試腳本快速對應變更？開發人員在設計初期就應該 考慮到測試先行的問題，就應該有不同于普通的系統架構方面的權衡，而不是在進行迭代后，使用自動化測試工具出現很多問題之后，才發現架構的問題，這時的人 力、物力的浪費都是很巨大的，在Webpos 項目中，就是因為沒有考慮到這個問題，導致自動化測試腳本在每次版本變更后對應起來非常困難，甚至在項目中期因為可擴展性差的問題而重新進行架構設計，造 成了大量的人力成本的浪費。
2、如果太多依賴客戶，影響我們在客戶心中的信譽度。
由于敏捷開發中頻繁變更的需求都是從客戶那里獲取的，所以對于一些建議性方面的bug 是否該提，測試人員的立場非常尷尬。因為開發人員不愿意為了這些建議性的問題來增加工作量，特別是這些問題客戶可能并未提出。時間久了就會對測試人員產生 抱怨。這樣，測試人員的積極性也會被降低甚至從此不再關注此類問題；但是對于客戶來說，遇到此類問題就可能會抱怨為何測試人員沒能及早發現而遺留到最終用 戶手上。
3、由于自動化測試，對測試人員提出了更高的要求。
敏捷開發的測試人員不但要熟悉開發語言、自動化測試工具，能夠編寫自動化測試腳本或者用工具錄制，而且要參與項目和系統的需求分析和架構設計 中。但是對于目前實際的項目，測試人員只是被要求進行驗收測試，并沒有被要求更多的思考需求的可實現性，也沒有將自身作為第一用戶參與項目和系統的需求分 析，設計和開發。當然這也是很多敏捷開發項目中測試人員甚至開發人員都無法達到的水平。這也是我們今后努力的方向。
（六）改進
無論是傳統開發的測試模式，還是新型開發的測試模式，目的都是為了保證產品質量，達到客戶滿意。對于目前實際項目來說，目前仍舊需要持續改進的就是：
1、系統架構的設計應該充分考慮測試的需求和可測試性。
2、測試人員加強主流測試工具的學習，提高測試水平，并且積極的參與到項目討論及客戶交流中去。
希望能通過我們的持續改進，使我們的團隊充滿激情和活力，能夠適應更大的變化，做出更高質量的軟件。