軟體測試體系方案

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．  其他規範：缺陷的分類規範、測試人員的測試流程規範、測試人員的教育訓練制度規定等。