軟件測試體系方案

本博客引自：https://blog.csdn.net/wuxiaobingandbob/article/details/8598471

從事軟件測試這么久，知道流程，但是一直沒有形成理論體系，今天上午空閑時，瀏覽到作者的博客，看到此文，深感作者的基礎之扎實。

引用一下他的這篇文章，一方面是傳播讓更多的人看到，學習一下。另一方面，方便自己以后回顧閱讀。

在此，感謝作者。

1.    引言

1.1    目標

軟件產品在發布前，如果能夠經過全面的測試過程，可以有效控制軟件缺陷最后遺留給用戶，從而減少軟件質量事故發生的概率，減少返工修復成本，增加用戶對產品的信賴程度，提高產品在市場上的競爭力，這已經是不爭的事實。因此軟件測試過程應該與整個軟件開發過程是平行進行的，測試計划應該在需求分析階段就已經開始制定了，隨后的工作則會伴隨着軟件開發的過程逐步展開。

本文檔編寫的目的是希望能建立起全程軟件測試理念，形式測試體系貫穿整個軟件生命周期，軟件測試是發現軟件缺陷的主要手段，但不是唯一的手段，軟件的缺陷是伴隨需求就已經誕生，所以，軟件測試應該從需求階段就開始介入，通過多種方法，多個手段來預防缺陷和發現缺陷。學者Hetzel認為“軟件測試是對軟件建立信心的一種積極行為”，想一想，如果軟件發布前，沒有做測試或測試不充分，客戶憑啥相信我們的軟件已經達到他期望的需求。所以，在軟件開發過程中，測試工作很有必要。

1.2    背景

目前的測試主要還是依賴於開發人員自測或測試人員非流程化測試，這是有一些不妥或需要改進的地方:第一是開發人員和專職測試人員可能關注點不同，思考問題的側重點不同，導致開發人員測試出結果不能覆蓋全面；第二開發人員更多的喜歡並樂於研究一些代碼上的東西，讓開發人員頻繁的做測試會產生抵觸情緒，通常會沒有耐心去深入測試下去，或許可能發現不了深入的系統問題；另外測試人員如果沒有建立起測試流程化理念，會導致測試的隨意性和盲目性，對軟件的質量也無法做充分的肯定和把控，缺乏流程化測試，也不利於技術的積累和傳遞。

1.3    術語和定義

      黑盒測試  基於軟件需求，而不是基於軟件內部設計和程序實現的測試方式。

      白盒測試  基於軟件內部設計和程序實現的測試方式，重點關注程序代碼邏輯方面。

      灰盒測試  灰盒測試是介於白盒測試與黑盒測試之間的一種測試模模式，重點關注模塊接口。

單元測試  主要測試軟件模塊的源代碼。一般由開發人員而非獨立測試人員來執行，因為測試者需要懂得該單元的設計與程序實現，測試者可能需要編寫額外的測試驅動程序。

集成測試   將一些“構件”集成一起時，測試它們能否正常運行。這里“構件”可以是程序模塊、客戶機－服務器程序等等。

系統測試  測試軟件系統是否符合所有需求，包括功能性需求與非功能性需求。功能性需求可分系統測試又可為功能測試、性能測試、易用性測試等。一般由獨立測試人員執行，通常采用黑盒測試方式或灰盒子測試方法。

功能測試  測試軟件的功能是否符合功能性需求，測試是據軟件需求規格說明書。

性能測試  測試軟件在各種狀況下的性能，如在正常或最大負載下的狀況。

易用性測試  測試軟件是否易用，主觀性比較強。一般要根據很多用戶的測試反饋信息，才能評價易用性。

冒煙測試  是指在將代碼更改簽入到產品的源樹中之前對這些更改進行驗證的過程。在檢查了代碼后，冒煙測試是確定和修復軟件缺陷的最經濟有效的方法。冒煙測試設計用於確認代碼中的更改會按預期運行，且不會破壞整個版本的穩定性,冒煙測試通常由測試人員或開發人員完成。

回歸測試  指錯誤被修正后或軟件在功能、環境發生變化后進行的重新測試，回歸測試的重點是保證修改后的bug都得以解決，回歸測試的困難在於不好評估或判斷修改的bug是否會引起其它問題發生，從而來確定哪些內容應當被重新測試。

  缺陷（bug） 軟件工程中明確規定和定義軟件缺陷是指：1.軟件沒有達到產品說明書表明的功能；2.軟件出現了產品說明書中不一致的表現；3.軟件功能超出產品說明書的范圍；4.軟件沒有達到用戶期望的目標(雖然產品說明書中沒有要求)；5.測試員或用戶認為軟件的易用性差。滿足一項以上就可定義為軟件存在缺陷。

2.    測試體系完善

2.1    項目啟動

1.  項目情況

a.       由公司的市場部或產品部下達項目開發任務后，確定了項目情況后，項目的主要角色PM對項目應該有清楚的認識，應該盡快制定並拿出《項目計划書.mpp》，項目計划書中應該明確指定項目的時間進度表，並對每一個里程碑標注，對項目中涉及的開發任務、測試任務應該有對應的所屬人負責。

b.      項目計划書准備好后，項目經理PM應該以郵件方式通知項目所屬中的每一個人和關注項目的直接領導等人員，召開項目kick off啟動會議，會議上應該重點介紹項目需求來源、項目周期、重點階段里程碑、人員分工等情況，並重點對任務所屬人員做點名回應，保證已經知悉並願意承擔其分配的任務。

c.       項目的計划是一個動態的過程，會隨着需求的變化和人員的調整有可能會出現變動，項目經理在制定項目計划時應該給一定的時間，保持項目平穩進行。

2.  測試職責

a.  良好的開端對項目的成敗有重要影響，要做好測試項目的工作，就不能忽視項目啟動的一些情況，測試人員應該首選關注以下情況：

b.  弄清項目背景，抓住項目的要素。

c.  深刻認識項目需求，評估以前是否有一定知識儲備，弄清項目開發團隊成員，便於后期的溝通交流。

d.  分析和弄清測試工作量是否可以保證項目的高質量發布，在項目啟動會議上應該和項目負責人做充分徹底的交流。

e.  項目啟動后，目前的測試資源是否能滿足測試需要，如果不滿足，需求在項目啟動后，多長時間能到位。

3.  職能流程

 

2.2    測試計划

1.  測試人員

a.   測試計划是一個過程，而不僅僅是一個文檔，制定測試計划的目的有利於測試范圍、測試時間和測試資源的調配和充分利用。測試計划是整個項目開發計划的一個組成部分，是對項目計划的分解和提煉。

b.   測試計划中應該明確規定項目在整個開發周期內各個階段的測試任務，並確定測試任務的所屬測試人員，在整個測試項目，除非特殊情況，一般規定測試人員應該做到專職專用，保證測試的連貫性和高效率。

c.   測試計划中測試測試風險應該加以標注和說明，比如人員的變動、測試人員對項目的熟悉程度、需求的頻繁變動等等不可控因素加以說明。

d.   測試計划中應該對階段測試任務有明確的工作量，一方面是對個項目的工作量的分解，同時能起到對測試人員在測試過程中做到自我管理的作用。

2.  職能流程

 

2.3    需求分析

1.  開發人員

a.  需求編寫是將軟件產品需求以結構化、共享的可管理的形式編寫成文檔的過程，需求分析和編寫需求文檔的過程關乎后續諸多操作，這是至關重要的一個過程，有道是“魔刀不誤砍柴工”，由此引申到軟件工程上，需求階段應該花一些力氣和時間，為后面的編碼、測試打下良好的基礎。

b.  需求的分層主要分為業務需求、用戶需求、功能需求，開發人員不光要重點關注功能需求的實現，同時也要關注下業務需求和用戶需求。

c.  需求的獲得是多方面的，不能局限於項目合同和行業規范，也應該關注用戶或潛在用戶的訴求感受、用戶使用產品情景分析等內容，確保需求的來源多方面。

d.  開發人員應在需求分析完成后，完成《概要設計文檔》、《詳細設計文檔》文檔，這作為整個項目開發階段的重要參考文檔，需求的確立是一個漸進和不斷迭代的過程，不可控因素較多，所以，在需求的設計上，應有足夠的可調控余地。

2.  測試人員

a.  在一個全新的項目中，對需求的了解程度通常要求是測試人員應該高於開發人員，這樣，我們測試人員才能在測試過程中對業務方面不會有漏洞和瑕疵，以基礎知識為內力，以測試方法和測試理論為核心力，以業務知識為動力，從而出色的完成項目整體測試過程。

b.  在開發人員編寫需求文檔的時間，測試人員如果沒有其他項目的測試任務時，應該也緊跟項目，學習涉及的行業規范、需求來源文檔。

c.  測試人員在需求分析后，應該配合開發人員完成《原型設計書》，一方面可以通過編寫文檔的方式更直接熟悉項目，同時也為后續測試文檔的設計、測試的執行打下良好的基礎。

3.  職能流程

 

2.4    測試設計

1.  開發人員

a.       測試設計是環境是整個測試執行的重要環節，良好的測試設計可以看做是基石，只有基石牢固才有可能使測試任務和測試質量高效而優質，有作為開發人員也應該配合和關注測試設計這一環節，可能不是義務，但至少應該做到協助。

b.      有可能測試人員在使用自動化測試工具過程中用到腳本，而測試人員在編寫腳本的時候，可以請教開發人員，開發人員應該在不影響自己工作前提下，可以積極協助解決，畢竟在代碼的編寫和熟練程度上，開發人員應該優於測試測試人員，這是不爭的事實。

c.       有一些項目在測試過程中，可能會用到第三方平台，而第三方可能需要寫模擬程序來協助測試我們的項目，這個模擬程度就需要開發人員來提供，目的是更好的配合完成我們項目的測試工作。

d.      在測試設計過程中，可能有需求的變動或功能的增刪，作為開發人員應該有義務將變更或增加的地方update到設計文檔中，並告知測試人員按新的設計文檔來編寫測試文檔。

2.  測試人員

a.       測試設計階段是測試人員大顯身手的階段，應該拿出自己的所有能力，確保認真和高度重視，測試設計相當於承上啟下的階段，既是檢驗我們對整體項目需求的熟悉程度，又是考驗我們對整個測試項目的計划把握和測試方法應用的檢驗，所以，有必要投入100%的精力去對待。

b.      測試設計階段應該考慮的文檔有《測試方案》、《測試用例》、測試工具等，其中測試用例是整個測試設計的重中之重，測試用例應該充分考慮需求的覆蓋程度和用例的設計方法，采用多種設計方法、多種測試組合類型做到全覆蓋項目需求。

c.       測試文檔編寫后，應該通知相關人員做評審，只有評審通過的測試文檔才能作為測試執行的依據，評審文檔應提前1~2天發送，給評審成員足夠的時候閱讀，並反饋提出的問題，在評審過程中，對問題做記錄並更新測試文檔，一般測試文檔最多評審兩次，所以，在編寫過程中，測試人員應該自我嚴格把控文檔質量，避免評審時因一些瑣碎問題浪費大家的時間。

d.      測試方案和測試用例的關系是相互聯系而又獨立存在，在設計時應該考慮，測試方案中應該明確指定要測試項目的功能點需求，可以不考慮具體測試過程的測試方法，看做作是僅僅對測試內容功能按層次有條理的羅列，而測試用例則是對測試方案的延伸和擴展，測試用例中應該對每一個功能測試點做擴容和放大，保證每個功能從不同測試角度來測試，每一條測試用例只有一個輸入和輸出，意義完全明確，不帶任意性，保證測試人員執行測試用例的可測試性，沒有通過測試用例的功能就意味着需要提交bug，每一個bug和測試用例的ID也是存在唯一對應關系的。

3.  職能流程

 

2.5    測試執行

1.  開發人員

a.       測試人員在測試過程中，對測試出來不能確定的問題可能會和開發人員做進一步確認，作為開發人員應該和測試人員積極溝通配合。

b.      開發人員對給分配解決的bug，在解決bug后，應該在bug中描述問題出現的原因，一方面有利用自己的技術水平體現，另外也是在項目最后結項的時候統計bug，作為度量和改進軟件開發體系，優化流程標准的重要參考依據。

c.       開發人員在測試執行過程中對分配給自己的bug，自認為不是bug的問題，可以告知項目經理，由項目經理再和測試溝通做狀態轉換，避免對一個bug雙方用推拉的方式來處理，或直接將bug置為No bug，應該通過良好的方式處理和對待測試人員發現的問題，它既是測試人員的工作成果，更重要的是一定保證這個發現的問題不能放任和丟棄。

2.  測試人員

a.  測試人員在測試之前首先應該獨立完成測試環境的部署，部署需要依據《部署文檔》，有的時候部署文檔時由測試人員在部署好測試環境后再來完成，不管如何，需要保證測試環境部署后的正確和干凈。

b.  測試人員在測試過程中，應該主要以《測試用例》為規范和指導思想，測試過程中對出現問題的問題應該第一時間提交到bug系統中，並分配給相應的開發人員。

c.  測試過程中，對發現的bug應該能復現，在提交bug時，在復現步驟中能描述清楚，便於開發人員在解決問題的時候參考，對於偶然的bug或時出現概率很小的bug應該在提交bug的時候附上圖片、日志等信息，便於開發人員更好的定位問題和解決問題。

d.  測試人員在測試完每一輪時，都應該對測試版本和環境做保存，在下一輪版本測試時在版本的配置文件，安裝部署都應該是從版本樹上全新取到的，避免和禁止用上一個版本的測試環境僅替換和更新修改的包，這樣從測試的意義來說，並不是一次全新意義的測試過程。

e.  測試人員在測試過程中應該積極調動主動能動性，在發現問題時，不但可以發現，還能深刻思考和學習問題出現的本質，學習開發人員解決問題的思路，想想，這個問題為啥會出現，到底問題由何引起的呢？這一些的問題思考，不但能協助開發人員快速解決問題提供幫助，同時對自己的技能提高有很大的幫助。

f.  測試過程中測試人員不但能通過測試用例發現問題，同時，利用一定時間，做一些ad-hoc（隨機的測試）、易用性的測試，這些問題主觀色彩比較大，可以不記錄為bug，可以當一些個人建議提交給項目經理，供參看和討論。

3.  職能流程

 

2.6    測試記錄

1.  測試人員

a.       測試記錄主要包括記錄測試結果和測試過程，測試結果是指針對測試發現的bug能詳實地記錄在bug缺陷庫中，並且對缺陷的描述能做到言語簡單明了，當包含的必要復現信息要全；測試過程是指在測試過程中發現的bug復現概率很小，或者有的無法復現等信息都要有測試記錄。另一個方面是在測試過程中可能發現測試用例有點地方寫的不全刪或有的bug並不能通過測試用例來發現，需要進一步細化和完善測試用例，這也需要做記錄，目的是在更好的把測試用例做到全覆蓋。

b.      測試記錄還應該記錄在測試過程中，這些測試可能不作為版本發布的需要，比如測試人員的一些想法、測試過程中遇到的困惑、測試和開發之間對問題處理的想法、對項目功能的體驗想法等等，這些都可以作為一個自我心得體會記錄下來，在測試完成后，作為一種共享，大家一起來分享和討論，這樣對自己是一種成長，推動組織在流程的建設中可以更好的完善。

2.  職能流程

 

2.7    缺陷跟蹤

1.  開發人員

a.       bug的整個生命周期離不開開發人員的參於，當項目經理分配給屬於自己的bug時，首先應該快速響應，並將bug狀態置為Open，當發現分配的bug不屬於自己來解決時，也不要有其它想法，直接將該問題Forward回去並注明原因即可，保持和項目經理口頭溝通。

b.   對bug 解決后，首先應該自己測試，保證測試沒有問題后再提交到版本上，避免未經自測就直接提交，導致解決bug的時間周期延長。

c.  開發人員在解決bug的過程中，有可能出現按描述的步驟根本復現不了該bug，這種情況完全有可能，因為bug的出現不但是操作的問題，還涉及測試環境、輸入數據、數據的累積等原因，所以，遇到不能復現的問題，應該和測試人員積極溝通，不要將bug直接就No bug。

2.  測試人員

a.  測試人員在提交bug后，應該對該bug全程跟蹤，bug從提交到Closed整個生命周期的各個階段,測試人員一定要實事求是、嚴謹細致的認真對待。

b.  測試人員在提交bug中，應該明確標明bug的嚴重級別程度、優先解決順序、測試步驟、預期結果、實際結果、項目版本、bug出現的概率等重要屬性，便於bug的解決優先級和項目的總結統計。

c.  在驗證bug時，發現bug已經解決，應該在不bugd的note中注明bug解決的當前版本，如果驗證問題還存在，需要將bug狀態重新置為reopen，並和解決bug的開發人員做主動積極溝通。

d.  在測試中，可能會發現有些bug出現的概率很小，復現的機會也非常小，但又確實存在，對這類bug應該先記錄整理下來，並告知項目負責人，申請做長時間觀察測試時間，因為這類bug可以需要長時間的測試才能復現，一旦復現應該將測試數據、日志、抓圖等信息都保存下來。

3.  職能流程

  

2.8    測試結束

1.  測試人員

a.  測試結束后，首先需要將最后測試的版本發送到FTP服務器上，同時告訴項目經理，將版本控制工具上的版本流做lock操作，將版本流凍結，禁止操作人員隨意提交代碼到項目上。

b.  測試完成后，需要將測試的情況整理成報告，發送給參與項目的全部人員和相關領導，報告中應該重點體現測試的信息，比如測試輪數、發現的bug總數量、遺留bug的處理意見、性能指標等必要參考信息。

c.  測試結束后，對測試文檔也要做整理並歸檔提交到服務器做備份保存，比如在測試過程中發現測試用例的不完善，測試過程中需求的微調等都需要同步到測試文檔中有體現。

d.  測試結束是代表一個階段的結束，應該給參與測試人員幾天自由支配的時間，調節下狀態。

2.  職能流程

 

2.9    測試總結

1.  測試人員

a.       一個項目測試完成后，應該就近抽半天時間大家一起座下來做個測試總結，總結時間不能和項目結束時間相差太久，因為剛測試完項目大家一定有很多想法，時間一長，很可能就會遺忘，而且時間長了，大家可能又有新的測試任務，所以，測試總結應該盡快完成。

b.      沒有總結，就不能認識自我，就不知成功在哪里，失敗和不足在哪里。只有經過思考，才能提高的更快，進步的更大。所以說，總結很有必要，在總結上，大家可以各抒己見，發表自己在測試中的困惑和困難，同時也應該分享自己在測試項目中一些經驗。

c.       總結過程中，可以適當邀請項目負責人和開發人員代表，聽聽他們對我們測試的一些建議和看法，這樣也有利於以后更好的配合工作，測試其實就是一種服務，測試應該懷着這樣的心態去測試。

d.      總結完成后，應該形成文檔化並保存下來，作為測試體系改進和完善的重要內容，同時也可以為部門、公司的流程體系建設完善提供一些參考信息。

2.  職能流程

 

3.    測試管理規划

3.1    測試人員

a.       測試任務：根據測試計划確定當前項目的測試人員，對測試人員做充分的溝通了解，涉及和所負責的有關項目評審會議都應參加，對制定的測試計划能確保測試人員知悉並能保持跟進狀態。對重點項目和緊急項目，要求測試人員在經驗和人員數量有適當傾斜，保證按時、高質量完成任務。

b.      測試溝通：測試中作為測試人員應該做到積極和有效的溝通，對不懂和不明白的問題，提倡自己通過多種方式嘗試解決至少3次，如果還不能解決，再請教其它同事，如果還未解決，可以繼續請求技術總監、總工等等，相信問題一定能夠解決。在測試過程中，對reject的 bug，應該和開發就問題討論，始終堅持“就是論事”原則，問題得不到解決，應該申請直接和跨級領導評估問題再做處理，不管結果如何，大家還是為了一個目標在一起。

c.       培訓學習：作為一名軟件測試人員，要學習和掌握的知識很多，在有限的生命中，我們不可能把所有的知識都學到手，但至少應該多學習和目前工作聯系比較密切的知識，橫向分如計算機知識、業務知識、行業知識、邊緣知識等，縱向分如計划基礎理論知識、測試技能理論、產品知識、行業規范等等。而且提倡學習后做分享，這樣對自己成長或是自己心態都有好處。

3.2    測試環境

a.       獨立：測試環境應該和開發環境、演示環境保持獨立，測試環境就是給測試人員專門分配的，測試環境的獨立性不但可以確保測試工作的有序進行，而且能保證測試出來的結果有實際的參考價值。

b.      干凈：測試環境應該時刻保持干凈，注意反病毒軟件的安裝和升級，不能有病毒侵入，這樣在測試的效率和測試結果上才能有保障，測試出的數據才有一定的意義。

c.       備份：一個項目需要測試很多版本，在測試環境下部署的版本，每一次測試完成后，應該做備份，這樣既是復現問題的證據，也是測試環境保持干凈性的體現。

3.3    測試資源

a.   人力資源：所有測試資源中，無疑最重要是人，所有的測試工作是由人來完成的，只要人在測試過程中，始終體現出積極、專業、認真的精神態度，才有可能把事情做好。

b.  測試版本：測試人員的測試對象是項目，而項目是以版本樹的形式出現的，所以，測試人員每測試一個版本都應該當成寶貴的成果資源來看待，尤其是最后測試完成的版本，作為測試的終結發布版本，一定要認真對待，通常情況下，推薦應該建立FTP服務器，將項目測試完成的版本由測試人員發布到FTP上的文件下，在運維演示、客戶升級等需要時應該從FTP上獲取版本，FTP作為唯一的出口，避免未經測試或測試不夠充分的版本通過私下關系交流。

c.   測試文檔：測試文檔從測試計划、方案、用例、報告、用戶手冊等諸多文檔中，都應該保存下來，作為一種資源管理起來，對后續的項目升級、新人的學習等都有非常重要的意義。

d.   測試工具：測試工具的研究和推廣使用是一個漫長而且艱苦的事情，一旦在測試過程中能夠使用起來並對測試項目有幫助的工具，就應該積極推廣，同時，對工具的使用手冊，使用情況，安裝部署等以文檔化的形式備份下來，后期能夠減少新接觸工具人員的學習成本，有利於工具的推廣使用。

e.   其它資源：其它資源包括測試人員的個人總結心得、第三方測試資源、第三方測試人員聯系方式等等都應該也以文檔化的方式記錄下來，作為一種資產備份下來。

4.    測試工具使用

 

功能描述	工具名稱	使用階段	獲取方式	使用情況
測試計划定制	MS  Project 2010	計划階段	試用版本	熟悉
原型圖設計	MS  Visio 2010	需求階段	破解版本	熟悉
測試方案編寫	MS  Word 2007	設計階段	破解版本	熟悉
測試用例編寫
測試文檔評審	MS  Excel 2007	評審階段	破解版本	熟悉
測試文檔管理	SVN 、CC	測試階段	開源、商業	熟悉
性能測試工具	Jme ter、LR		開源、商業	熟悉、了解
生成測試數據	TestDataBuilder、 Dbmonster		開源、開源	熟悉、了解
缺陷管理工具	Mantis、JIRA、CQ		開源、開源、商業	熟悉、了解、熟悉
自動化測試	Seleniu、Watir		開源、開源	了解、了解
	Robot		商業	了解
測試報告	MS  Word 2007	結束階段	破解版本	熟悉
測試總結

備注：對上表格“使用情況”一列中標注的熟悉、了解的說明：

      熟悉：指以前的工作中使用頻繁或使用過，對該工具有一定的技能儲備。

      了解：指在以前工作使用很少用或在工作之余研究過該工具，可能還未在項目中實際使用過。

5.    測試規范建立

1．  軟件測試方法指南：對測試人員在進行各類測試時進行規范化的要求，通過規范的制定，可以                                   有效統一測試人員的測試行為，避免不同的人在做同類測試時出現測試效果上的很大偏差。

2．  測試計划規范：包括測試計划的模板以及對測試計划的要求，測試進度和時間安排根據什么來   制定。

3．  測試用例測試規范：包括測試用例的模板以及測試用例的測試要求。

4．  缺陷提交規范：用於規范測試人員的bug錄入過程要求，包括bug的錄入格式要求，bug提交的要素包括哪些，bug的描述需要注意的地方等。

5．  測試報告規范：包括測試報告模板及對測試報告的要求。限定和指明測試報告應該包括哪些內容。

6．  測試工具使用規范：指出測試人員在測試階段應該使用哪些測試工具，工具的獲取途徑和使用細則。

7．  其他規范：缺陷的分類規范、測試人員的測試流程規范、測試人員的培訓制度規定等。