打開BOSS應用軟件測試的死結[2]

　　打開BOSS應用軟件測試的死結[2]  軟件測試

　　打開死結的三個步驟

　　一、第一步：加強上線前開發/集成商的軟件測試

　　關于“新上線的系統BUG過多，功能不穩定”這一點，毋庸置疑就是開發/集成商對新開發的應用軟件，沒有在系統上線前做足夠充分的測試，從而沒有在上線前發現并解決足夠的BUG。如何解決這個問題，在當前現實市場條件下，則需要開發/集成商、運營商雙方面的努力。

　　1.要做好具體工作

　　為了做好軟件測試，開發/集成商需要做好這些具體的工作內容。

　　1)建立真正完整而務實的測試工作流程。在“玩”測試這個“游戲”之前，首先要確定如何測試的游戲規則。其內容包括：測試工作分為幾個階段;這些階段的工作內容分別如何與開發對應;在各個階段，測試人員如何與開發人員交互;測試發現的BUG如何落實解決;測試的爭議如何解決;測試環境如何維護;測試的軟件版本如何獲取;測試版本和開發版本之間又如何交互演進;軟件發布的標準如何依賴測試結果等。

　　2)組建技術、業務均合格并掌握測試方法論的獨立測試隊伍。設計出一個完整、務實、適應于本企業內部環境和文化的測試流程，只需要依賴企業內部少數熟悉公司內部環境的人才就可實現。而建立合格的測試技術隊伍，則需要一個團隊的努力，甚至涉及到軟件企業文化的改變。這是軟件企業當前最難解決的問題。目前的現狀，無論是高校還是社會，普遍沒有形成有效的軟件測試人員的培養經驗，甚至連起碼的認識都欠缺。

　　3)引入適當的測試工具軟件。一方面，即使針對正在研發中的軟件，由于在開發過程中不斷引入的變更(發現錯誤進行的變更，業務需求變化引起的變更等)，對于已經測試通過的功能，也需要在每次修改代碼后進行回歸測試，只有這樣才能保證即使在代碼不斷修改的情況下，軟件發布時相應的功能測試仍然是通過的。而這種回歸測試的工作量非常之巨，以至于如果完全人工來做，是不可能實際做到的。另一方面，對于像內存泄漏、Core Dump、性能壓力等方面測試，如果全部采用人工進行，也將變得非常困難和低效。為此，開發/集成商需要引入相應的自動化測試(包括自動回歸、模擬壓力、代碼分析等)工具，才能真正做好測試。

　　4)搭建完整的測試環境。沒有開發環境就沒法開發。同樣，沒有測試環境就無法測試。測試環境之于開發環境的區別，一方面是測試環境下不會修改任何代碼，而是測試人員利用開發人員提交到源代碼版本服務器的代碼，編譯而形成可執行軟件，進而進行測繪;另一方面，測試環境下要始終維護著狀態一致的業務數據，只有這樣才能保證測試用例的完整運行(一般來說，每個測試用例運行完成后，它要保證下次該用例在同樣的測試數據上仍然能夠運行成功，否則無法執行自動的回歸測試)。

　　5)工程進度緊張的情況下確保測試的完整性。由于實際的市場壓力，現有大部分BOSS系統建設的進度壓力都非常大，這直接導致軟件測試的進度壓力也非常大，甚至變得不現實。必須考慮如何結合實際情況，確保在非常緊張的進度壓力下，仍然能夠開展充分的測試。

　　2.工作落實建議

　　第一、二項工作，是開發/集成商無法推卸的責任，而且也是其應該能夠解決的問題。至于如何解決，則需要依靠開發/集成商自身在管理上的努力。但一般來說，建立完整務實的測試流程，和組建技術、業務均合格并掌握測試方法論的獨立測試隊伍，少則1年、多則2、3年才能真正實現。

　　第三個引入測試工具軟件的工作，存在這樣的落實難點：限于當前國內應用軟件的現實價格平，開發/集成商一般無力承擔這些測試工具的昂貴代價(根據一般的BOSS軟件開發隊伍規模，其至少三、四十人以上，需要購買的測試工具license價格動輒上百萬美元。而目前BOSS應用軟件的總體價格，不過才幾十萬美元。)，如Mercury的WinRunner/ LoadRunner/ TestDirector系列等，或IBM的Rational系列工具等。實際上，直至今日，甚至很多開發/集成商連開發工具都是依賴運營商去購買的。比較現實的建議，還是通過運營商采購、開發/集成商使用的方式來解決這個矛盾。當然，具體采用哪些工具，采用什么樣的測試工作流程，這是需要開發/集成商來提出方案，并由運營商認可的。

　　第四個搭建測試環境的工作，與測試工具軟件類似，相對于目前應用軟件的現實價格，這些設備和軟件的價格都太昂貴，開發/集成商目前根本無力承擔購買和維護一套這樣的完整環境的代價。因為測試環境涉及到UNIX主機、存儲、網絡等昂貴的硬件設備，而且開發/集成商要開發運行于各種主流UNIX主機平臺的應用軟件，還必須擁有各種主流的主機臺，才能真正解決問題。這個問題，同樣只有通過運營商來解決。建議可以在設計BOSS系統方案時就考慮到這部分設備的提供，這樣，就可以讓開發/集成商的開發測試依賴于運營商提供的測試環境。

　　根據以往的BOSS系統建設經驗，一方面往往在系統建設方案中對測試環境所需要的設備、系統軟件的考慮不足，另一方面也沒有嚴格區分開發環境和測試環境的區別。為了做好這個工作，建議運營商和開發/集成商在系統方案設計之初，就充分考慮這部分投入。一般來說，相對運行環境，只需要考慮一個按比例縮小的、具有典型代表意義的測試環境方案即可。

　　事實上，關于第三、四兩個問題的實際解決，目前國內已經不乏這樣的成功操作案例。

　　最后一個關于測試進度壓力的問題，我們稍微研究即可發現：一般來說，由于測試主要側重于“黑盒”測試，而“黑盒”測試必須依賴于軟件集成成功的基礎上，為此就造成了測試往往都是在開發結束后才開始，而這時往往都快要到系統上線時間了，這就導致了測試進度被壓縮再壓縮、測試內容被簡化再簡化的情況出現。那么，是否有什么方法可以讓測試進度盡可能提前?近幾年發展起來的極限編程理論中，有一個現成的方法可以解決該問題——持續集成。而這個方法，在微軟等著名軟件公司其實很早就有了很長時間、針對大型軟件項目的成功運用經驗(在微軟它被稱為“每日編譯”)。對于BOSS系統的建設，建議也采用這種方法論來執行測試，從而通過盡可能早地開始軟件測試，來確保緊張進度壓力下的充分測試。

原文轉自：http://www.kjueaiud.com