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

MILY: 宋體; mso-bidi-font-size: 12.0pt">作為運營商的核心生產系統之一，BOSS系統的穩定性運行非常關鍵，其每次發生的重大故障都會引起運營商嚴重的經濟損失。而BOSS系統的穩定運行，與應用開發/集成商提供的應用軟件本身的穩定性密切相關。甚至可以不夸張地認為，目前國內BOSS系統的大部分穩定性問題，主要集中在BOSS應用軟件的不穩定上。

何謂系統的穩定性？無非就是這三方面：系統功能穩定，不要動輒操作失��；系統運行效率好，實時性高；系統運行平穩，不要動輒重啟甚至宕機。而要做到這三方面，不對應用軟件進行充分的測試,是無法保證的。

那么，為什么BOSS應用軟件的測試沒有做好？如何解決這個問題？

從運營商的角度理解，是開發/集成商沒有對軟件進行充分的測試，導致系統出現大量BUG，所以開發/集成商應該加強測試，從而提高自身軟件的質量。如果說開發/集成商要提高自身軟件的價值，必須首先提高自身軟件的質量。這是簡單、勿庸置疑的道理。

而從開發/集成商的角度來理解，是運營商的業務需求繁雜多變，開發周期短，難以進行充分的測試即被迫匆匆上線。而且目前BOSS軟件的報價一般僅考慮開發成本，無法考慮包括測試環境、測試工具等成本，要搭建這些測試環境、引入這些測試工具將消耗幾倍于現在的開發成本，所以無法也無力進行嚴格的軟件測試。要加強測試，提高質量，首先要運營商給予更大的成本空間，否則無法實現。

這是個典型的“雞”與“蛋”的問題，看起來是個死結，難以解開。本文的目的，就是從分析當前BOSS應用軟件測試方面存在的問題入手，立足于實際可操作的角度，對如何打開這個“死結”做出積極探討。

應用軟件不穩定問題總結

在BOSS的實際建設和維護過程中，關于應用軟件導致的系統不穩定（主機、存儲等設備，數據庫、中間件等系統軟件導致的不穩定，本文不作討論），可以大致歸結為以下幾種。

1.新上線系統的BUG過多，功能不穩定。某個新系統上線后，才發現應用軟件的BUG很多，營業員時不時的操作失敗，而又不是每次都操作失敗，讓人難以琢磨該系統的“性格”。

2.新上線業務功能導致原有正常業務功能出錯。這可以說是BOSS系統維護中最常發生的不穩定問題，實際上就是新功能開發時，只對新功能進行了測試，而沒有對原有功能的影響進行測試，導致上線前沒有發現問題，而倉促上線所致。

3.新上線業務越來越多，系統越來越慢，直至系統宕機。這屬于典型的性能、壓力的測試和分析不夠，并進而對系統支撐業務能力估算不足所致。

這三個問題，從另一個角度來看，可以理解為解決當前BOSS應用軟件測試問題的三個步驟。首先必須加強上線前開發/集成商的軟件測試，建立完整的測試流程和測試環境，這樣才能解決新上線系統BUG過多的問題；其次，在此基礎上，對每個新上線的業務功能，除了執行新功能本身的測試外，還通過建立豐富的測試用例庫來確保執行嚴格的功能回歸測試，才能確保新上線業務沒有對原有正常業務功能產生不良影響；最后，有了這些測試流程、測試環境、測試用例庫，才可以進行嚴格的性能測試和分析，為新業務上線對系統荷載造成的影響進行科學客觀的分析，從而準確地把握系統實際運行荷載的變化趨勢，并進而盡早發現系統支撐能力的“臨界點”，最終做到對系統宕機現象的“防患于未然”。

下面將對這三個步驟進行深入的剖析和闡述。

打開死結的三個步驟

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

關于“新上線的系統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系統的建設，建議也采用這種方法論來執行測試，從而通過盡可能早地開始軟件測試，來確保緊張進度壓力下的充分測試。

二、第二步：通過回歸測試確保新業務上線

所謂“新上線業務功能導致原有正常業務功能出錯”，實際上就是“回歸測試”做得不夠，或者說，回歸測試就是為了預防這種問題的發生才被提出來。

1．要做好的具體工作

嚴格來說，軟件開發/集成商正式發布的軟件，在經過大量的測試后，會形成一個針對該軟件的測試用例庫，其中的測試用例覆蓋了現有的全部軟件功能。而當增加一個新業務功能，針對該新業務功能本身，固然要做測試，但為了驗證該新業務功能的代碼或配置信息是否對原有功能產生消極影響，還必須經過完整的回歸測試。從實際操作的角度來看，開發/集成商和運營商需要這些具體工作。

1）開發/集成商建立完整的測試用例庫，并執行自動化的回歸測試。為了確保新業務上線，能對原有功能執行嚴格的回歸測試，必須能將回歸測試自動化，并且這種自動化是依賴于原有功能的完整測試用例庫的基礎之上。沒有完整、涵蓋原有軟件所有功能的測試用例庫，就不可能知道要執行哪些回歸測試；沒有對回歸測試自動化，不可能手工執行工作量如此巨大的回歸測試，也就不可能真正做到“嚴格”。

2)營商搭建完整的回歸測試環境，并執行必要的回歸確認測試。一般來說，運營商在新業務功能上線前，均會對新業務功能本身進行確認測試。但即使在開發/集成商做過嚴格的功能回歸測試后，運營商仍然還需要對其進行必要的回歸確認測試，尤其是針對相關聯的業務功能來說更加如此。實際上，回歸確認測試工作量往往數倍于新功能本身的確認測試，所以這部分工作不能忽視。

2．工作落實建議

第一個工作實際上是以第一步“加強上線前開發/集成商的軟件測試”的所有工作內容為基礎。沒有完整而務實的測試工作流程，就不可能有完整的測試用例庫；沒有自動化回歸測試工具，就無法錄制這些測試用例的自動化回歸測試腳本（開發/集成商自行編碼實現自動回歸測試，工作量一樣很大，不現實），也就不可能進行嚴格的回歸測試（對于BOSS這樣的大型應用軟件，回歸測試是不可能通過手工測試能夠做好的）。做不到第一步中的五點工作內容，“執行嚴格的回歸測試”將會成為一句空談。

第二個工作，一方面需要運營商提供設備、開發/集成商負責搭建并維護一套完整的測試環境。另一方面，作為客戶，運營商在安排新業務功能的確認測試工作量和工作時間時，要充分考慮到回歸確認測試。如果不承認這個必要的工作，往往不可避免會出現“新上線業務功能導致原有正常業務功能出錯”這樣的問題。

三、第三步：通過性能測試保證系統支撐能力

1．要做好的具體工作

之所以出現系統性能越來越差，越來越慢，直至某天系統開始宕機這樣的現象，完全是因為隨著系統新業務功能的不斷開通，以及系統支撐用戶量、數據量的增長，沒有量化地把握系統支撐能力變化趨勢，從而無法掌控系統支撐能力的發展所致。為此，需要做好以下這些工作。

1)對新上線業務功能執行量化的性能測試和分析。由于缺乏新上線業務功能對生產系統產生多大影響的量化性能測試和分析結果，所以無法把握新功能所消耗部分的系統資源所代表的設備成本。而通過對所有新上線業務功能的量化性能測試和分析，就可以做到心中有數，準確地掌控系統荷載情況的變化趨勢，從而及早地預測出系統支撐能力的“臨界點”。

2)及時對新業務發展或系統支撐能力做出調整。僅僅有了上述的工作基礎，仍然不能徹底解決問題，還需要將這些量化的數據作為決策的依據，是在系統支撐能力限制下有選擇的調整新業務的實現方式，還是及時、有計劃地擴充系統支撐能力，都是必須要執行的工作內容。

2．工作落實建議

對于第一項工作，在運營商提供完整測試環境和工具軟件的前提下，開發/集成商應當在運營商的明確要求下，認真落實執行這個工作要求，并定期向運營商提交量化的測試分析數據，以及針對業務實現方式或系統擴容的實際可行的調整建議。

在開發/集成商做好第一個工作內容的基礎上，運營商要做到的，就是及時關注這些測試分析數據和調整建議，并有計劃地安排和落實執行。只有這樣通過雙方的共同努力，才能確保應用系統的真正穩定可靠運行。

總結

總的來說，切實做好第一步工作，或者說解決好第一個問題，才是打開BOSS應用軟件測試死結的關鍵所在。沒有了第一步的落實執行，后兩步的工作缺乏基礎，就顯得空洞而不務實。而做好第一步的工作，關鍵是開發/集成商和運營商雙方面的努力：一方面開發/集成商要在管理上建立完整而實用的測試流程并確保執行，和培養合格的測試隊伍；另一方面運營商要在系統建設之初就充分考慮測試環境方案，以及要求開發/集成商引入并使用好相應的自動回歸和性能測試工具。

文章來源于領測軟件測試網 http://www.kjueaiud.com/