軟體測試流程 之我見

【摘要】 軟體測試從哪裡開始到哪裡結束？中間要經過哪些環節以及各環節要注意哪些事項。本文就有關問題結合個人實際工作經驗進行闡述，鑒於每個環節都可以做為一個專題來進行探討，所以受篇幅和時間限制，本文對有關問題未做深入剖析，只做一個宏觀上的介紹。

【關鍵詞】測試流程、需求分析、測試案例、測試計劃、缺陷管理

 

一、概述

 

一般而言，軟體測試從項目確立時就開始了，前後要經過以下一些主要環節：

需求分析→測試計劃→測試設計→測試環境搭建→測試執行→測試記錄→缺陷管理→軟體評估→RTM.

 

在進行有關問題闡述前，我們先明確下分工，一般而言，需求分析、測試案例編寫、測試環境搭建、測試執行等屬於測試開發人員工作範疇，而測試執行以及缺陷提交等屬於普通測試人員的工作範疇，測試負責人負責整個測試各個環節的跟蹤、實施、管理等。

說明：

1．以上流程各環節並未包含軟體測試過程的全部，如根據實際情況還可以實施一些測試計劃評審、用例評審，測試培訓等。在軟體正式發行後，當遇到一些嚴重問題時，還需要進行一些後續維護測試等。

 

2．以上各環節並不是獨立沒聯絡的，實際工作千變萬化，各環節一些交織、重疊在所難免，比如編寫測試案例的同時就可以進行測試環境的搭建工作，當然也可能由於一些需求不清楚而重新進行需求分析等。這就和我們國家提出建設有中國特色的社會主義國家一樣，只所以有中國特色，那是因為國情不一樣。所以在實際測試過程中也要做到具體問題具體分析，具體解決。

 

二、測試流程

    

需求分析 

 

需求分析（Requirment Analyzing）應該說是軟體測試的一個重要環節，測試開發人員對這一環節的理解程度如何將直接影響到接下來有關測試工作的開展。

可能有些人認為測試需求分析無關緊要，這種想法是很不對的。需求分析不但重要，而且至關重要！

 

一般而言，需求分析包括軟體功能需求分析、測試環境需求分析、測試資源需求分析等。

 

其中最基本的是軟體功能需求分析，測一款軟體首先要知道軟體能實現哪些功能以及是怎樣實現的。比如一款Smartphone包括VoIP、Wi-Fi以及Bluetooth等功能。那我們就應該知道軟體是怎樣來實現這些功能的，為了實現這些功能需要哪些測試裝置以及如何搭建相應測試環境等，否則測試就無從談起！

 

既然談了需求分析，那麼我們根據什麼來分析呢？總不能憑空設想吧。

 

總得說來，做測試需求分析的依據有軟體需求文檔、軟體規格書以及開發人員的設計文檔等，相信管理一些規範的公司在軟體開發過程中都有這些文檔。

 

測試計劃

  

測試計劃（Test Plan）一般由測試負責人來編寫。

 

   測試計劃的依據主要是項目開發計劃和測試需求分析結果而制定。測試計劃一般包括以下一些方面：

 

1．  測試背景

1. a.       軟體項目介紹；
2. b.       項目涉及人員（如軟硬體項目負責人等）介紹以及相應連絡方式等。

2．  測試依據

1. a.       軟體需求文檔；
2. b.       軟體規格書；
3. c.       軟體設計文檔；
4. d.       其他，如參考產品等。

3．  測試資源

1. a.       測試裝置需求；
2. b.       測試人員需求；
3. c.       測試環境需求；
4. d.       其他。

4．  測試策略

1. a.       採取測試方法；
2. b.       搭建哪些測試環境；
3. c.       採取哪些測試載入器以測試管理工具；
4. d.       對測試人員進行培訓等。

5．  測試議程

1. a.       測試需求分析；
2. b.       測試案例編寫；
3. c.       測試實施，根據專案計劃，測試分成哪些測試階段（如單元測試、整合測試、系統測試階段，α、β測試階段等），每個階段的工作重點以及投入資源等。

6．  其他。

 

測試計劃還要包括測試計劃編寫的日期、作者等資訊，計劃越詳細越好了。

計劃趕不上變化，一份計劃做的再好，當實際實施的時候就會發現往往很難按照原有計劃開展。如在軟體開發過程中資源匱乏、人員流動等都會對測試造成一定的影響。所以，這些就要求測試負責人能夠從宏觀上來調控了。在變化面前能夠做到應對自如、處亂不驚那是最好不過了。

 

測試設計

 

測試設計主要包括測試案例編寫和測試情境設計兩方面。

 

一份好的測試案例對測試有很好的指導作用，能夠發現很多軟體問題。關於測試案例編寫，請參見前面寫的《也談測試案例》一文，裡面有詳細闡述。

 

測試情境設計主要也就是測試環境問題了。

 

測試環境搭建

 

不同軟體產品對測試環境有著不同的要求。如C/S及B/S架構相關的軟體產品，那麼對不同作業系統，如Windows系列、unix、linux甚至蘋果OS等，這些測試環境都是必須的。而對於一些嵌入式軟體，如手機軟體，如果我們想測試一下有關功能模組的耗電情況，手機待機時間等，那麼我們可能就需要搭建相應的電流測試環境了。當然測試中對於如行動電話通訊等環境都有所要求。

 

測試環境很重要，符合要求的測試環境能夠協助我們準確的測出軟體問題，並且做出正確的判斷。

 

為了測試一款軟體，我們可能根據不同的需求點要使用很多不同的測試環境。有些測試環境我們是可以搭建的，有些環境我們無法搭建或者搭建成本很高。不管如何，我們的目標是測試軟體問題，保證軟體品質。測試環境問題，還是根據具體產品以及開發人員的實際情況而採取最經濟的方式吧。

 

測試執行

   　

測試執行過程又可以分為以下階段：

 

單元測試→整合測試→系統測試→出廠測試，其中每個階段還有迴歸測試等。

 

從測試的角度而言，測試執行包括一個量和度的問題。也就是測試範圍和測試程度的問題。 比如一個版本需要測試哪些方面？每個方面要測試到什麼程度？

 

從管理的角度而言，在有限的時間內，在人員有限甚至短缺的情況下，要考慮如何分工，如何合理地利用資源來開展測試。當然還要考慮以下問題：

1．  當測試人員測試的執行不到位、敷衍了事時該如何解決？

2．  測試效率問題，怎樣提高測試效率？

3．  根據版本的不同特點是只做驗證測試還是採取煙霧測試 (Smoke Test)亦或是系統全面測試？

4．  當測試過程中遇到一些偶然性隨機問題該怎樣處理？

5．  當版本中出現很多新問題時該怎樣對待？測試停止標準？

6．  ……

總之，測試執行過程中會遇到很多複雜的問題，還是那句話，具體問題具體解決！本文不做過多闡述。

 

測試記錄

 

缺陷記錄總的說來包括兩方面：由誰提交和缺陷描述。

 

一般而言，缺陷都是誰測試誰提交，當然有些公司可能為了保證所提交缺陷的品質，還會在提交前進行缺陷評估，以確保所提交的缺陷的準確性。

 

在缺陷的描述上，至少要包括以下一些方面內容：

序號

標題

預置條件

操作步驟

預期結果

實際結果

注釋

嚴重程度

機率

版本

測試者

測試日期

 

以上是描述一個bug時通常所要描述的內容，當然在實際提交bug時可以根據實際情況進行補充，如附片、log檔案等。

 

另外，一個版本軟體測試完畢，還要根據測試情況出份測試報告，這也是所要經過的一個環節。

 

缺陷管理

 

缺陷管理方面，很多公司都採取缺陷管理工具來進行管理，常見缺陷管理工具有Test Director、Bugfree等。

 

是一個bug從提出到close所經過的一些流程，其他比如keep No action\keep spec等一些狀態流程都未包含在內，在此僅做示範說明。

  

 

 

  

註：軟體缺陷和bug兩者在含義上有著細微差別，本文統稱缺陷。

 

軟體評估

 

這裡評估指軟體經過一輪又一輪測試後，確認軟體無重大問題或者問題很少的情況下，對準備發給客戶的軟體進行評估，以確定是否能夠發行給客戶或投放市場。

軟體評估小組一般由項目負責人、行銷人員、部門經理等組成，也可能是由客戶指定的第三方人員組成。

 

測試總結

 

每個版本有每個版本的測試總結，每個階段有每個階段的測試總結，當項目完成RTM後，一般要對整個項目做個回顧總結，看有哪些做的不足的地方，有哪些經驗可以對今後的測試工作做借鑒使用，等等。測試總結無嚴格格式、字數限制。應該說，測試總結還是很總要的。

 

測試維護

 

   由於測試的不完全性，當軟體正式release後，客戶在使用過程中，難免遇到一些問題，有的甚至是嚴重性的問題，這就需要修改有關問題，修改後需要再次對軟體進行測試、評估、發行。

　　本文轉自http://www.cnblogs.com/itest/archive/2007/05/25/759215.html以後看時方便，希望能給像我這樣的初學者帶來協助！