淺談軟件工程項目的終檢測試

摘要：該文對軟件工程的終檢測試中的文檔測試、軟件安裝測試、功能測試、性能測試、安全性測試和兼容性測試中涉及到的內容、方法、流程、工具、手段和注意事項等做一簡要探討。

關鍵詞：終檢測試；壓力測試；強度測試；錯誤恢復測試

中圖分類號：TP311文獻標識碼：A 文章編號：1009-3044(2008)32-1107-02

A Discusson of the End Examination Test of Software Engineering

FANG Ming， ZHAN Sheng

(School of Computer， XI'an Shiyou University， Xi'an 710021， China)

Abstract: This article examines the content， the method， the flow， the tool， the method and the matters needing attention to the software engineering end which in the test in the documents test， the software installment test， the function test， the performance test， the secure test and the compatible test involve and so on makes a brief discussion.

Key words: the end examination test; strength test; intensity test; restores the test wrongly

1 引言

軟件測試是保證軟件質量的重要活動，是軟件項目實施的不可缺少的環節，軟件測試的直接目的是發現軟件中存在的缺陷。軟件測試要在軟件測試成本和軟件質量效益兩者間找到一個平衡點，單方面的追求都必然損害軟件測試存在的價值和意義。拿物理學家愛因斯坦的話說就是： Keep it simple but not too simple（保持簡單但是不要太簡單）。

終檢測試是在軟件項目在開發方交付使用，由開發方和甲方共同組織，目的是了解軟件的性能和軟件是否能滿足甲方要求的一種完整的測試。終檢測試包括軟件文檔和安裝測試、功能測試、性能測試。下面就對終檢測試的內容、方法、流程做一簡要探討。

2 文檔和安裝測試

為了保證軟件項目開發的成功，并且便于運行和維護，在開發工作的每一階段，都需要編制一定的文檔。記錄開發過程中的技術信息，便于協調以后的軟件開發、使用和修改；提供對軟件的有關運行、維護和培訓的信息，便于管理人員、開發人員、操作人員和用戶之間相互了解彼此的工作；向潛在用戶報導軟件的功能和性能，使他們能判定該軟件能否服務于自己的需要。

根據中華人民共和國國家標準《計算機軟件產品開發文件編制指南》（GB 8567-88），一個軟件項目的開發過程中，一般地說，應該產生十四種文檔。這十四種文檔是：《可行性研究報告》、《項目開發計劃》、《軟件需求說明書》、《數據要求說明書》、《概要設計說明書》、《詳細設計說明書》、《數據庫設計說明書》、《用戶手冊》、《操作手冊》、《模塊開發卷宗》、《測試計劃》、《測試分析報告》、《開發進度月報》、《項目開發總結報告》。文檔測試有四個內容：檢查文檔的數量是否完整，一般來說一個軟件項目都必須包括以上的十四個文檔（沒有數據庫的除外），以及甲方另外要求的文檔；檢查每個文檔的內容是否完整；檢查文檔是否真實有效，檢查《數據庫設計說明書》是否和數據庫一致，檢查《用戶手冊》和《操作手冊》是否能夠起到相應的作用，檢查《模塊開發卷宗》是否和程序源代碼一致；檢查文檔排版是否符合國標或者是行標。

軟件安裝測試包括以下三部分：源代碼測試：源代碼測試的目的是測試交付軟件和源代碼的一致性、測試軟件是否使用了除合同以外的中間件、測試源代碼的編碼是否滿足標準；軟件配置測試：按照《操作手冊》安裝軟件運行的環境并做相應的配置，檢測是否能夠按照《操作手冊》配置成功并檢測配置是否最佳。有些軟件為了本軟件的運行進行的配置使其它軟件運行的性能降低了，這在測試報告中應該提出；軟件安裝測試：按照《操作手冊》用代碼檢測中生成的安裝文件進行安裝，檢測是否能夠按照《操作手冊》安裝成功。

3 功能測試

功能測試包括以下幾個部分：界面測試、正確性測試、可用性測試、邊界條件測試、流程測試。

3.1 界面測試

測試人員進入模塊后，應該按照一定的順序進行檢查，一般的測試順序為檢查設計與實現的一致性——檢查程序界面外觀——驗證程序功能——檢查鍵盤操作——檢查系統權限。界面測試的標準按照《詳細設計說明書》上的執行；如果詳細設計上沒有參照甲方或者開發方的標準執行；如果雙方都沒有，檢測本軟件內是否統一。

3.2 正確性測試

檢測數據在程序的流轉過程中是否能夠按照設計準確的進行流轉、計算，必須做到以下組合來設計測試用例：

結合本頁面或者其他頁面，檢測傳遞出去的數據是否正確；接受進來的數據是否正確。可以針對文本域，按照其文本域的特性進行測試。比如傳入、傳出的狀態是否正確、數據是否有截斷等。結合數據庫或者其他存儲方式，檢測保存到數據庫或者其他存儲方式的數據是否正確，是否有截斷數據的情況發生，是否有由于數據庫字符集的原因導致存儲成亂碼的情況；從數據庫或者其他存儲方式讀取進來的數據是否正確、是否讀錯位置的情況。有計算或者是統計的按照《概要設計說明書》中提供的公式的所有分支都要進行測試，對于一些特殊數據要專門列出測試用例。這個測試最好用Robot、LoadRunner等自動化測試工具錄制好操作步驟，把輸入的數據設成變量從建立的測試試用的數據字典中去讀取數據來測試。

3.3 可用性測試

可以針對同一頁面（界面）的多個按鍵，對其按鍵的特性分別進行測試。然后組合他們測試。在組合的過程中要注意要覆蓋所有的按鍵組合，并對每組按鍵的先后順序也要做組合測試。

3.4 邊界條件測試

就是對每個文本接受框和程序分支數據的取值范圍都要確定下來。對在條件邊緣的數據都要例舉數據確定數據是否能夠準確的進行流轉和計算。這和正確性測試中的第三條有交叉之處。

3.5 流程測試

按照業務流程逐一設計流程測試案例，測試人員重點關注每一個業務的正確執行過程，為每一個正確的執行過程提供執行數據。

功能測試的這幾部分在編寫測試用例和執行測試的時候并不是完全分開的。

4 性能測試

性能測試包括以下幾個方面：壓力測試、強度測試、錯誤恢復測試、并發測試、大數據量的測試。

4.1 壓力測試

是模擬真實環境下的用戶活動，被度量的值包括吞吐量、穩定性和應用的響應。在驗收測試中，壓力測試需要估計出用戶數、每個用戶每天的對于某個功能的使用頻數，然后按照一定的原則在合同規定的使用環境下加載到軟件中運行一段時間，測出系統的一系列指標。終檢測試中在設計測試用例的時候是加載一系列的業務量，測出這一系列業務量所對應的指標，測試出系統的最大性能，并測出最大性能時的系統瓶頸，然后反算出可以支持的用戶數。一般來說軟件的核心功能的性能代表整個軟件性能。在壓力測試中收集的性能指標一般包括：CPU利用率、磁盤I/O限制、網絡帶寬、內存利用、磁盤大小，還有其它應用系統的指標，比如Web服務器的每秒執行請求數、最近的請求在隊列中等待的毫秒數，數據庫服務器的CPU 使用率、顯示在高速緩存中找到數據的命中率、每秒收的Transact-SQL 命令批數、每秒為數據庫啟動的事務數等等。以下是一般系統指標的瓶頸：

4.2 強度測試

用來檢測應用在擴展情況下的臨界點。強度測試檢查程序對異常情況的抵抗能力。強度測試總是迫使系統在異常的資源配置下運行。可以做以下方面的測試：當中斷的正常頻率為每秒一至兩個時，運行每秒產生十個中斷的測試用例；定量地增長數據輸入率，檢查輸入子功能的反映能力的測試用例；運行需要最大存儲空間（或其他資源）的測試用例；運行可能導致虛存操作系統崩潰或磁盤數據劇烈抖動的測試用例。

做強度測試可以發現以下兩方面的問題：

內存泄漏：一種極難檢測的現象，很難設計測試用例來檢測它們。使用簡單的功能測試，幾乎發現不了內存泄漏問題，因為在軟件完成之前測試沒對軟件進行足夠多的使用。內存泄漏通常要求操作要重復非常多的次數以使內存消耗達到能引起注意的程度。盡管與其它編程語言（如C/C++）相比，Java程序更難引入內存泄漏錯誤，但只要程序仍保持著對對象的引用，該對象仍有可能被實例化并且它占用的內存永遠不會被釋放。

并發與同步：強度測試在查找并發性問題上非常出眾，這是因為在任何一個測試生命周期中，它都應用了許多不同的代碼路徑和定時條件。一般的規則是，強度測試運行的時間越長，涉及并應用的代碼路徑組合和定時條件就越多。當然，這也的確使得這些問題很難再現（錯誤可以在5分鐘或5天后發生）。死鎖、線程泄漏以及任何一般的同步問題通常只能在壓力測試階段被檢測出來。這些類型的問題很難通過執行單元測試來發現。開發人員不會一直考慮他或她的代碼將與其他地方的代碼（在執行單元測試時這些代碼可能還沒寫出來）進行交互。

4.3 錯誤恢復測試

恢復測試主要檢查系統的容錯能力。當系統出錯時，能否在指定時間間隔內修正錯誤并重新啟動系統。恢復測試首先要采用各種辦法強迫系統失敗，然后驗證系統是否能盡快恢復。對于自動恢復需驗證重新初始化、檢查點、數據恢復和重新啟動等機制的正確性；對于人工干預的恢復系統，還需估測平均修復時間，確定其是否在可接受的范圍內。

4.4 并發測試

并發是同時執行多個操作的行為。換句話說，就是在同一時間執行多個測試，例如在同一個服務器上同時調用許多Web服務。這個原則不一定適用于所有的軟件（比如無狀態服務），但是多數軟件都具有某個并發行為或多線程行為元素，這一點只能通過執行多個代碼示例才能測出來。功能測試或單元測試幾乎不會與任何并發設計結合。壓力系統必須超越功能測試，要同時遍歷多條代碼路徑。至于怎么做到這一點取決于具體的軟件。例如，一個Web服務壓力測試需要一次模擬多個客戶機。Web服務（或者任何多線程代碼）通常會訪問多個線程實例間的一些共享數據。因額外方面的編程而增加的復雜性通常意味著代碼會具有許多因并發引起的錯誤。由于引入并發性意味著一個線程中的代碼有可能被其他線程中的代碼中斷，所以錯誤只在一個指令集以特定的順序（例

如以特定的定時條件）執行時才會被發現。把這個原則與重復原則結合在一起，您可以應用許多代碼路徑和定時條件。一般來說對軟件的并發測試至少應該包括以下三種情況的測試：寫入數據庫的并發量測試；讀取數據庫的并發量測試；同時寫入和讀取數據庫的并發量的測試。WEB服務器的最大并發數是404錯誤大于20%或者WEB服務死鎖。

大數據量測試是模擬系統在運行一段時間（比如一年）后由于數據庫的記錄增加、WEB服務器日志的增加導致系統指標的一些變化。大數據量測試是先估算出這一段時間內會產生的數據量，然后用LoadRunner等自動化測試工具加載數據，除了你對程序結構及數據結構完全清楚以外，在做大數據量測試的時候千萬不要為了節約測試時間而直接在數據庫中添加數據，因為直接添加數據庫記錄是按照理想化的思路添加，而程序設計并不一定是這樣做的。

5 安全性測試和兼容性測試

安全性測試包括系統安全性測試和軟件安全性測試。系統安全測試檢查系統對非法侵入的防范能力。系統安全設計的準則是，使非法侵入的代價超過被保護信息的價值。

安全性測試必須進行以下四方面：端口掃描：在客戶端和服務器端進行一次端口掃描，找出那些打開但并不需要的通訊端口；檢查用戶帳戶：看操作系統、任何數據庫以及程序自身；檢查目錄許可：在關閉了無用端口并禁用了多余的賬號后，仔細檢查一下程序所用到的數據庫和服務器目錄的權限設置；關上后門：程序員為了能夠方便、快捷的使用軟件，往往建立了一些直觀的快捷方式——也被叫做后門。

程序安全性測試：檢查軟件對非法侵入的防范能力。這由軟件的不同存在的測試方案不同。

兼容性測試：測試軟件在不同環境下的運行情況。必須在：不同操作系統、不同的典型應用軟件、不同的典型硬件環境這三個要素進行組合來測試用例。兼容性測試根據軟件需要推廣的情況來確定兼容性測試的方案。一些應用范圍廣的軟件需要測試各種環境下的全面功能，如果應用范圍不是很廣，那么可以在各種環境中進行抽點測試的方法進行。

安全性測試和兼容性測試完成的標志是完成安全性測試和兼容性測試的所有測試用例并完成安全性測試和兼容性測試報告。

6 結束語

軟件測試的目的僅僅是發現缺陷這么簡單嗎？如果回答是肯定的，那么類似的軟件缺陷在下一次新項目的軟件測試中還會發生。古語有“ 不知道歷史的人必然會重蹈覆轍 ” ，沒有對軟件測試結果進行認真的分析，我們就無法了解缺陷發生的原因和應對措施，結果是我們不得不耗費的大量的人力和物力來再次查找軟件缺陷。軟件測試是一個計算機發展中出現的一門嶄新的學科，雖然目前有很多的測試技術和測試方法，但還沒有完全形成一個統一的行業標準，有很多的測試方法很難在實踐工作中進行應用，很多測試工具也不能很好的與實際工作結合，所以說，在具體的測試活動中還需要根據軟件本身的特點，靈活的選擇測試方法和測試工具，實踐與理論相結合才能取得時間、資源等的合理投入和最大產品效益的獲得。

參考文獻：

[1] 計算機軟件產品開發文件編制指南[S].（GB 8567-88），1988.

[2] 飛思科技產品研發中心.使用軟件測試方法與應用[M].北京:電子工業出版社，2003.

[3] 王健，苗勇.軟件測試員培訓教材[M].北京:電子工業出版社，2003.

[4] Perry W E.Elfriede Dustin1Additon Software Testing[M].北京：清華大學出版社，2003.