最近總有人詢問測試計劃的編寫方法和步驟，如何合理的設(shè)計測試計劃是每個測試經(jīng)理 的責任，測試中需要關(guān)注的要素太多了，既有技術(shù)方面的考慮，也有管理方面的考慮，如何 才能設(shè)計出實用的測試計劃呢？我根據(jù)自己的經(jīng)驗，理出一份軟件測試計劃編寫指南，希望對大家有所啟示，并同大家交流測試中的心得和方法。
1 前言
1.1 軟件測試的目的
軟件測試的目的決定了如何去組織測試。如果測試的目的是為了盡可能多地找出錯誤， 那么測試就應(yīng)該直接針對軟件比較復(fù)雜的部分或是以前出錯比較多的位置。如果測試目的是 為了給最終用戶提供具有一定可信度的質(zhì)量評價，那么測試就應(yīng)該直接針對在實際應(yīng)用中會經(jīng)常用到的商業(yè)假設(shè)。
不同的軟件項目會有不同的測試目的；相同的軟件項目，不同的時期也可能有不同測試 目的，可能是測試不同區(qū)域或是對同一區(qū)域的不同層次的測試。
軟件測試：
①、軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程；
②、測試是為了證明程序有錯，而不是證明程序無錯誤。
③、一個好的測試用例是在于它能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤；
④、一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。
這種觀點可以提醒人們測試要以查找錯誤為中心，而不是為了演示軟件的正確功能。但是僅憑字面意思理解這一觀點可能會產(chǎn)生誤導(dǎo)，認為發(fā)現(xiàn)錯誤是軟件測試的唯一目，查找不出錯誤的測試就是沒有價值的，事實并非如此。
首先，測試并不僅僅是為了要找出錯誤。通過分析錯誤產(chǎn)生的原因和錯誤的分布特征，可以幫助項目管理者發(fā)現(xiàn)當前所采用的軟件過程的缺陷，以便改進。同時，這種分析也能幫助我們設(shè)計出有針對性地檢測方法，改善測試的有效性。
其次，沒有發(fā)現(xiàn)錯誤的測試也是有價值的，完整的測試是評定軟件質(zhì)量的一種方法。
對于測試數(shù)據(jù)的動態(tài)積累可以給項目管理者展示出當前項目的實時狀態(tài)，為科學(xué)的決策提供有力的保障，并且為今后的培訓(xùn)，考評，工作的檢查等提供強有力的數(shù)據(jù)基礎(chǔ)。
1.2 軟件測試的復(fù)雜性和經(jīng)濟性
人們常常以為，開發(fā)一個程序是困難的，測試一個程序則比較容易。這其實是誤解。設(shè)計測試用例是一項細致并需要高度技巧的工作，稍有不慎就會顧此失彼，發(fā)生不應(yīng)有的疏漏。不論是黑盒測試方法還是白盒測試方法，由于測試情況數(shù)量巨大，都不可能進行徹底的測試。所謂徹底測試，就是讓被測程序在一切可能的輸入情況下全部執(zhí)行一遍。通常也稱這種測試為“窮舉測試”。 “黑盒”法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使用， 才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測試。 “白盒”法是窮舉路徑測試，貫穿程序的獨立路徑數(shù)是天文數(shù)字，但即使每條路徑都測試了仍然可能有錯誤。第一，窮舉路徑測試決不能查出程序違反了設(shè)計規(guī)范，即程序本身是個錯誤的程序。第二，窮舉路徑測試不可能查出程序中因遺漏路徑而出錯。第三，窮舉路徑測試可能發(fā)現(xiàn)不了一些與數(shù)據(jù)相關(guān)的錯誤。所以說：“程序測試只能證明錯誤的存在，但不能證明錯誤不存在”。
在實際測試中，窮舉測試工作量太大，實踐上行不通，這就注定了一切實際測試都是不徹底的。當然就不能夠保證被測試程序中不存在遺留的錯誤。軟件工程的總目標是充分利用有限的人力和物力資源，高效率、高質(zhì)量地完成測試。為了降低測試成本，選擇測試用例應(yīng)注意遵守“經(jīng)濟性”的原則。第一，要根據(jù)程序的重要性和一旦發(fā)生故障將造成的損失來確定它的測試等級；第二，要認真研究測試策略，以便能使用盡可能少的測試用例，發(fā)現(xiàn)盡可能多的程序錯誤。掌握好測試量是至關(guān)重要的，一位有經(jīng)驗的軟件開發(fā)管理人員在談到軟件測試時曾這樣說過：“不充分的測試是愚蠢的，而過度的測試是一種罪孽”。測試不足意味著讓用戶承擔隱藏錯誤帶來的危險，過度測試則會浪費許多寶貴的資源。
測試是軟件生存期中費用消耗最大的環(huán)節(jié)。測試費用除了測試的直接消耗外，還包括其它的相關(guān)費用。能夠決定需要做多少次測試的主要影響因素如下：
①、系統(tǒng)的目的
系統(tǒng)目的的差別在很大程度上影響所需要進行的測試的數(shù)量。那些可能產(chǎn)生嚴重后果的系統(tǒng)必須要進行更多的測試。
②、潛在的用戶數(shù)量
一個系統(tǒng)的潛在用戶數(shù)量也在很大程度上影響了測試必要性的程度。這主要是由于用戶團體在經(jīng)濟方面的影響。
③、信息的價值
在考慮測試的必要性時，還需要將系統(tǒng)中所包含的信息的價值考慮在內(nèi)，一個支持許多家大銀行或眾多證券交易所的客戶機/服務(wù)器系統(tǒng)中含有經(jīng)濟價值非常高的內(nèi)容。很顯然這一系統(tǒng)需要比一個支持鞋店的系統(tǒng)要進行更多的測試。這兩個系統(tǒng)的用戶都希望得到高質(zhì)量、無錯誤的系統(tǒng)，但是前一種系統(tǒng)的影響比后一種要大得多。因此我們應(yīng)該從經(jīng)濟方面考慮，投入與經(jīng)濟價值相對應(yīng)的時間和金錢去進行測試。
④、開發(fā)機構(gòu)
一個沒有標準和缺少經(jīng)驗的開發(fā)機構(gòu)很可能開發(fā)出充滿錯誤的系統(tǒng)。在一個建立了標準和有很多經(jīng)驗的開發(fā)機構(gòu)中開發(fā)出來的系統(tǒng)中的錯誤不會很多，因此，對于不同的開發(fā)機構(gòu)來說，所需要的測試的必要性也就截然的不同。 然而，那些需要進行大幅度改善的機構(gòu)反而不大可能認識到自身的弱點。那些需要更加嚴格的測試過程的機構(gòu)往往是最不可能進行這一活動的，在許多情況下，機構(gòu)的管理部門并不能真正地理解開發(fā)一個高質(zhì)量的系統(tǒng)的好處。
⑤、測試的時機
測試量會隨時間的推移發(fā)生改變。在一個競爭很激烈的市場里，爭取時間可能是制勝的關(guān)鍵，開始可能不會在測試上花多少時間，但幾年后如果市場分配格局已經(jīng)建立起來了，那么產(chǎn)品的質(zhì)量就變得更重要了，測試量就要加大。測試量應(yīng)該針對合適的目標進行調(diào)整。
1.3 文檔介紹
1.3.1 本文檔的受眾
測試計劃編寫指南有兩類潛在的受眾。首先，測試經(jīng)理使用它作為指導(dǎo)方針編寫測試計劃。測試計劃編寫完成后，將作為整個團隊（包括開發(fā)人員和測試人員）溝通的基礎(chǔ)。
1.3.2 文檔更新
測試項目開始時，應(yīng)該完成測試計劃的大部分內(nèi)容。項目開始后，由于測試情況有變化，可能導(dǎo)致測試計劃文檔變化。如果文檔有明顯的變化，必須在文檔中添加變更歷史來記載這些變化。
1.3.3 文檔目的
測試計劃在策略和方法的高度說明如何計劃、組織和管理測試項目。測試計劃包含足夠的信息使測試人員明白項目需要做什么是如何運作的。另外，清晰的文檔結(jié)構(gòu)能使任何一個讀者在瀏覽計劃的前面幾頁后，就能對項目有一個大概的認識。測試計劃只是測試的一個框架，很多細節(jié)需要跟開發(fā)人員或其他人員溝通，因此計劃不包括測試用例的細節(jié)和系統(tǒng)功能的詳細信息。
本文檔描述出了整個開發(fā)過程中測試工作的流程，不同的測試時期可以根據(jù)需要對本文檔的一部分進行充實（如：單元測試階段等），但是在結(jié)項后，本文檔規(guī)定的各個時期的測試計劃均需完整，以備檢查。對于項目類產(chǎn)品，可根據(jù)實際情況參照執(zhí)行。
1.4 測試工作流程
測試工作從產(chǎn)品立項后開始介入，貫穿于軟件產(chǎn)品的整個生命周期。初期測試經(jīng)理參與項目的需求評審，并以需求設(shè)計為標準設(shè)計系統(tǒng)測試的測試用例。當開發(fā)進入詳細設(shè)計階段時，測試經(jīng)理根據(jù)測試的需要同開發(fā)經(jīng)理討論技術(shù)的實現(xiàn)方式，在允許的范圍內(nèi)，盡量使用方便今后測試工作開展的實現(xiàn)方式。同時此階段測試經(jīng)理開始設(shè)計集成測試的測試用例。詳細設(shè)計評審?fù)ㄟ^后，開發(fā)人員開始進入編碼階段，同時，測試經(jīng)理應(yīng)同開發(fā)經(jīng)理協(xié)調(diào)好進度，按照模塊開發(fā)的時間規(guī)劃，測試經(jīng)理開始根據(jù)模塊的接口規(guī)范設(shè)計灰盒測試用例，盡量保證模塊級的測試可以同開發(fā)進度協(xié)調(diào)進行。編碼完成后，測試人員協(xié)助開發(fā)人員進行集成測試，測試經(jīng)理使用前期已經(jīng)完成的集成測試方案對產(chǎn)品進行測試。集成測試完成后，由測試經(jīng)理對集成測試的效果進行評估，對于合格的產(chǎn)品填寫系統(tǒng)測試申請報告，向測試部正式申請進入系統(tǒng)測試階段。系統(tǒng)測試完成后，由測試經(jīng)理向測試部申請軟件發(fā)行。當相關(guān)的產(chǎn)品化工作正式完成后，由測試部開據(jù)質(zhì)量合格證書，產(chǎn)品正式發(fā)行。
以上概要的介紹了測試方法和測試原則，以及公司對于產(chǎn)品類項目的測試流程，以下將具體的給出各個測試階段，相關(guān)測試計劃的文檔要求，文檔中將給出關(guān)鍵的考察點，計劃編制的技巧與說明，以便在書寫測試計劃的時候有章可循。
2 引言
2.1 編寫目的
闡明編寫測試計劃的目的并指明讀者對象。
2.2 項目背景
說明項目的來源、委托單位及主管部門。
2.3 定義
列出測試 計劃中所用到的專門術(shù)語的定義和縮寫詞的原意。
2.4 參考資料
列出有關(guān)資料的作者、標題、編號、發(fā)表日期、出版單位或資料來源，可包括：項目的計劃任務(wù)書、合同或批文；項目開發(fā)計劃；需求規(guī)格說明書；概要設(shè)計說明書；詳細設(shè)計說明書；用戶操作手冊；本測試計劃中引用的其他資料、采用的軟件開發(fā)標準或規(guī)范。
2.5 文檔摘要
主要說明測試計劃中重要的和可能有爭議的問題。本節(jié)的主要目的是將這些信息傳遞給那些可能不會通讀整個測試計劃文檔的人員（比如經(jīng)理或開發(fā)項目的負責人）。
提示和技巧：
在寫這一節(jié)時，考慮一下你的計劃在那些地方可能會引起反對。這個計劃跟以前的計劃相比，有什么不同的地方。測試項目與系統(tǒng)開發(fā)計劃的關(guān)系等。
使用列表的格式，可以將問題按重要程度羅列出來，然后在后面的章節(jié)中再對這些問題進行詳細說明，這樣就能讓對這些問題有重要影響的人員知道問題的所在。
2.6 文檔歷史和變更
[作者] – [日期] – [文檔的當前狀態(tài)，上版本以來所作的主要變化]
3 管理
3.1 系統(tǒng)視圖和目標
系統(tǒng)視圖對測試人員了解自己需要做什么是非常重要的。測試項目負責人應(yīng)積極與系統(tǒng)設(shè)計人員或開發(fā)人員溝通，以取得相關(guān)資料。系統(tǒng)目標是幫助實現(xiàn)系統(tǒng)視圖的重要指標。系統(tǒng)視圖和目標對實現(xiàn)整個項目計劃來說是至關(guān)重要的。測試人員必須知道系統(tǒng)是做什么并且?guī)椭椖繉崿F(xiàn)這種目標。在計劃中包括系統(tǒng)視圖和目標后，要確保所有的測試人員都知道項目和系統(tǒng)的目標。
通常情況下視圖和項目計劃都是模糊的。模糊的目標必須通過成員的努力轉(zhuǎn)換成可衡量和實現(xiàn)的東西。沒有固定的視圖和目標，你將無法完成部分任務(wù)。而且，你會發(fā)現(xiàn)很難將對產(chǎn)品的認識向別人轉(zhuǎn)述。
提示和技巧：
為什么視圖對客戶是重要的？
你如何向客戶表達這種視圖？
你將做什么來保證你是在向?qū)崿F(xiàn)視圖的方向前進?
在你回答這些問題之后，你就可以將視圖轉(zhuǎn)換成測試導(dǎo)向的目標？
整個系統(tǒng)的總體運行框架什么？各個部分的運行目標是什么？
3.2 運行環(huán)境
需測試的軟，硬件環(huán)境，有無特殊的要求。如有些設(shè)備是有使用時限的需注明，如果測試環(huán)境不能滿足測試要求，如何解決等？
3.3 資源需求
3.3.1 培訓(xùn)需求
本節(jié)說明項目測試人員需要哪些培訓(xùn)。
提示和技巧：
對于新手需要先介紹測試系統(tǒng)，如果測試人員比較熟悉該系統(tǒng)，則需要說明新系統(tǒng)的功能。
是否進行自動測試。
測試人員要不要培訓(xùn)以編寫自動化腳本。
3.3.2 硬件需求
本節(jié)說明測試人員需要的各種類型的硬件以及這個測試團隊需要的硬件。
3.3.3 軟件需求
本節(jié)說明測試人員需要使用的軟件。
3.3.4 辦公空間需求
本節(jié)說明需要多少辦公空間。
3.4 風(fēng)險分析
目前存在那些不確定因素，包括可預(yù)計的和不可預(yù)計的。系統(tǒng)開發(fā)和測試過程中，會有各種可能導(dǎo)致系統(tǒng)發(fā)布延遲，在計劃中需要預(yù)先估計這些風(fēng)險，并且提出相應(yīng)的對付辦法。
3.5 測試團隊結(jié)構(gòu)
這一節(jié)說明測試團隊的結(jié)構(gòu)和項目測試人員的數(shù)量。
提示和技巧：
查看開發(fā)計劃確定那些功能需要最多資源。
在各個測試階段確定需要多少測試人員，各需掌握那些技巧。
多少人做自動測試，是哪些人。
列出項目參與人員的聯(lián)系方式包括 E-mail 和電話。
3.6 相關(guān)信息保存的位置
測試服務(wù)器的相關(guān)信息；
測試文檔保存的位置；
測試工具保存的位置；
測試中需要使用的軟硬件的存放地點；
Bug如何記錄，存放的位置。
3.7 測試時間安排
包括主要時間點的安排，如各個測試階段的開始，截至日期，產(chǎn)品預(yù)計發(fā)布日期等。
3.8 缺陷處理
測試過程中可衡量的是發(fā)現(xiàn)的缺陷的狀況。因此缺陷的報告和管理必須寫成書面文檔。
3.8.1 Bug 數(shù)據(jù)庫管理
提示和技巧：
誰負責創(chuàng)建數(shù)據(jù)庫？
誰有權(quán)限增加數(shù)據(jù)庫的賬號？
誰有權(quán)使用哪類賬號？
數(shù)據(jù)庫使用過程中出了問題和誰聯(lián)系？
誰負責數(shù)據(jù)庫備份？
多長時間備份一次？
由誰使用數(shù)據(jù)庫？
缺陷管理應(yīng)該與開發(fā)部門的負責人一起討論。
3.8.2 缺陷處理過程
提示和技巧：
解釋缺陷報告和分配過程。
缺陷標題、測試環(huán)境應(yīng)如何填寫。
解釋如何輸入，解決，重新打開，關(guān)閉和重新即或一個缺陷。
讓測試人員清楚一個缺陷從擊活到解決的全過程。
缺陷必須指定由誰負責解決。
定義優(yōu)先級、嚴重級別等。
在項目結(jié)束時，如何解決這些缺陷。
如果有Bug管理工具，只需遵照工具的流程執(zhí)行。
3.9.測試過程控制
在測試過程中，通過對缺陷數(shù)據(jù)庫進行分析可以確定測試的狀態(tài)。另外，通過讓測試人員填寫測試工作周報，可以對項目進展狀況進行反饋。
3.9.1 缺陷數(shù)據(jù)分析
提示和技巧：
在開發(fā)過程和穩(wěn)定階段是否有過多的未處理缺陷，這可能說明開發(fā)的資源不夠，或者有其它問題。
如何確定項目中是否有過多的缺陷。
測試人員是否積極發(fā)現(xiàn)缺陷，或者過分積極。
在每個時間點上，系統(tǒng)是否穩(wěn)定。
系統(tǒng)哪些部分的缺陷最集中。
在系統(tǒng)發(fā)行時修復(fù)了多少缺陷。
哪些類型的缺陷最普遍。
3.9.2 測試工作周報
提示和技巧：
周報中應(yīng)包括哪些信息。
如何填寫工作周報。
誰負責查看工作周報。
以上詳細的描述了，測試過程中可能遇到的或者必須提前安排的工作內(nèi)容，有一些項是要在工作過程中陸續(xù)充實的，有一些是需要提前給出解決辦法的，在制定計劃過程中，請依據(jù)實際情況進行書寫。
4 測試計劃
4.1 整體測試策略
本節(jié)的目的是說明計劃中使用的基本的測試過程。
提示和技巧：
是否使用里程碑技術(shù)和在測試過程中驗證每個模塊？或者是什么都不做，只是普通的測試而已。
測試人員是否在項目開發(fā)初期就開始工作？或者測試人員只在系統(tǒng)開發(fā)完后，才開始測試。
是否明顯的界定出單元，集成，系統(tǒng)，驗收測試階段？
自動測試工作是否進行？
對于像壓力，性能，兼容性等的測試項目，放到那一個測試區(qū)間內(nèi)，有什么質(zhì)量要求？
4.2 測試范圍
通常說明什么是要測試的，什么是不要測試的是非常重要的。明確規(guī)定這些問題后，測試人員對該做什么有一個清晰的認識。
提示和技巧：
需要特別測試那些部分？
那些部分不需要測試，為什么？
測試人員是否需要測試內(nèi)容以及相關(guān)部分？
是否要驗證每個模塊的穩(wěn)定性？
是否有理論上應(yīng)該測試的，但是測試環(huán)境無法進行測試的內(nèi)容？
對于產(chǎn)品附帶的文檔，測試人員是否需要檢查？
4.3 質(zhì)量目標
圍繞軟件質(zhì)量，有幾種不同的說法。第一個是質(zhì)量是一種絕對的標準，對所有的系統(tǒng)必須等同處理。事實上，質(zhì)量是相對的而且是和產(chǎn)品相關(guān)的概念。例如，多媒體產(chǎn)品的質(zhì)量目標傾向于精美的表示和適當?shù)膬?nèi)容，而應(yīng)用系統(tǒng)可能傾向于易用性、健壯性和適用于不同的任務(wù)。質(zhì)量目標可能是動態(tài)的。在項目進行過程中，會由于市場壓力、新的機會和功能改變而重新設(shè)定質(zhì)量目標。
另一種有關(guān)軟件質(zhì)量的說法是，定義和衡量系統(tǒng)質(zhì)量是測試部門一個部門的事。實際上，建立質(zhì)量標準是所有職能部門共同努力的結(jié)果。測試、開發(fā)、系統(tǒng)使用部門、用戶教育、系統(tǒng)支撐必須為建立和維護系統(tǒng)的質(zhì)量標準做出自己的貢獻。每個部門必須對自己最了解的部分做出相應(yīng)的質(zhì)量定義。例如，測試和開發(fā)部門對系統(tǒng)質(zhì)量的衡量標準主要是健壯性和正確性。用戶部門可能對易用性方面比較熟悉。
最后，質(zhì)量不僅是衡量系統(tǒng)的功能或性能是否正常。對系統(tǒng)來說，在開發(fā)過程中盡早建立全面的質(zhì)量標準與系統(tǒng)的及時發(fā)布是一樣重要的。質(zhì)量目標是一個強有力的工具，應(yīng)該在系統(tǒng)開發(fā)過程中盡早建立。一個定義準確的質(zhì)量目標在以后的產(chǎn)品開發(fā)過程中幫助決策。例如，系統(tǒng)是否能夠正式發(fā)行？在代碼完成后，應(yīng)該修復(fù)那些缺陷？在系統(tǒng)完成后那種類型的測試是最合適的。
提示：
質(zhì)量目標應(yīng)該是一個確實可行的軟件質(zhì)量描述，在確定之前應(yīng)該同相關(guān)人員達成一致的意見，不要等到發(fā)貨的時候才發(fā)現(xiàn)大家對其的理解有分歧，這時測試人員會非常被動，在達成一致意見后，當開發(fā)人員和測試人員有分歧時，可以使用質(zhì)量目標作為衡量的標準。
4.4 測試計劃
一般情況下測試活動大致分成四個部分：單元測試，集成測試，系統(tǒng)測試，驗收測試。下面具體介紹一下測試計劃的書寫方法，工作過程中可以依據(jù)實際情況進行刪減和補充。
4.4.1 單元測試
單元測試是代碼一級的測試，主要依賴于開發(fā)人員進行。
單元測試的對象是軟件設(shè)計的最小單位——模塊。單元測試的依據(jù)是詳細設(shè)計描述，單元測試應(yīng)對模塊內(nèi)所有重要的控制路徑設(shè)計測試用例，以便發(fā)現(xiàn)模塊內(nèi)部的錯誤。單元測試多采用白盒測試技術(shù)，系統(tǒng)內(nèi)多個模塊可以并行地進行測試。
一、單元測試任務(wù)
單元測試任務(wù)包括：
（1）模塊接口測試；
（2）模塊局部數(shù)據(jù)結(jié)構(gòu)測試；
（3）模塊邊界條件測試；
（4）模塊中所有獨立執(zhí)行通路測試；
（5）模塊的各條錯誤處理通路測試。
模塊接口測試是單元測試的基礎(chǔ)。只有在數(shù)據(jù)能正確流入、流出模塊的前提下，其他測試才有意義。測試接口正確與否應(yīng)該考慮下列因素：
（1）輸入的實際參數(shù)與形式參數(shù)的個數(shù)是否相同；
（2）輸入的實際參數(shù)與形式參數(shù)的屬性是否匹配；
（3）輸入的實際參數(shù)與形式參數(shù)的量綱是否一致；
（4）調(diào)用其他模塊時所給實際參數(shù)的個數(shù)是否與被調(diào)模塊的形參個數(shù)相同；
（5）調(diào)用其他模塊時所給實際參數(shù)的屬性是否與被調(diào)模塊的形參屬性匹配；
（6）調(diào)用其他模塊時所給實際參數(shù)的量綱是否與被調(diào)模塊的形參量綱一致；
（7）調(diào)用預(yù)定義函數(shù)時所用參數(shù)的個數(shù)、屬性和次序是否正確；
（8）是否存在與當前入口點無關(guān)的參數(shù)引用；
（9）是否修改了只讀型參數(shù)；
（10）對全程變量的定義各模塊是否一致；
（11）是否把某些約束作為參數(shù)傳遞。
如果模塊內(nèi)包括外部輸入輸出，還應(yīng)該考慮下列因素：
（1）文件屬性是否正確；
（2）OPEN/CLOSE語句是否正確；
（3）格式說明與輸入輸出語句是否匹配；
（4）緩沖區(qū)大小與記錄長度是否匹配；
（5）文件使用前是否已經(jīng)打開；
（6）是否處理了文件尾；
（7）是否處理了輸入/輸出錯誤；
（8）輸出信息中是否有文字性錯誤；
檢查局部數(shù)據(jù)結(jié)構(gòu)是為了保證臨時存儲在模塊內(nèi)的數(shù)據(jù)在程序執(zhí)行過程中完整、正確。局部數(shù)據(jù)結(jié)構(gòu)往往是錯誤的根源，應(yīng)仔細設(shè)計測試用例，力求發(fā)現(xiàn)下面幾類錯誤：
（1）不合適或不相容的類型說明；
（2）變量無初值；
（3）變量初始化或省缺值有錯；
（4）不正確的變量名（拼錯或不正確地截斷）；
（5）出現(xiàn)上溢、下溢和地址異常。
在模塊中應(yīng)對每一條獨立執(zhí)行路徑進行測試，單元測試的基本任務(wù)是保證模塊中每條語句至少執(zhí)行一次。此時設(shè)計測試用例是為了發(fā)現(xiàn)因錯誤計算、不正確的比較和不適當?shù)目刂屏髟斐傻腻e誤。此時基本路徑測試和循環(huán)測試是最常用且最有效的測試技術(shù)。計算中常見的錯誤包括：
（1）誤解或用錯了算符優(yōu)先級；
（2）混合類型運算；
（3）變量初值錯；
（4）精度不夠；
（5）表達式符號錯。
比較判斷與控制流常常緊密相關(guān)，測試用例還應(yīng)致力于發(fā)現(xiàn)下列錯誤：
（1）不同數(shù)據(jù)類型的對象之間進行比較；
（2）錯誤地使用邏輯運算符或優(yōu)先級；
（3）因計算機表示的局限性，期望理論上相等而實際上不相等的兩個量相等；
（4）比較運算或變量出錯；
（5）循環(huán)終止條件或不可能出現(xiàn)；
（6）迭代發(fā)散時不能退出；
（7）錯誤地修改了循環(huán)變量。
一個好的設(shè)計應(yīng)能預(yù)見各種出錯條件，并預(yù)設(shè)各種出錯處理通路，出錯處理通路同樣需要認真測試，測試應(yīng)著重檢查下列問題：
（1）輸出的出錯信息難以理解；
（2）記錄的錯誤與實際遇到的錯誤不相符；
（3）在程序自定義的出錯處理段運行之前，系統(tǒng)已介入；
（4）異常處理不當；
（5）錯誤陳述中未能提供足夠的定位出錯信息。
邊界條件測試是單元測試中最后，也是最重要的一項任務(wù)。眾的周知，軟件經(jīng)常在邊界上失效，采用邊界值分析技術(shù)，針對邊界值及其左、右設(shè)計測試用例，很有可能發(fā)現(xiàn)新的錯誤。
二、單元測試過程
一般認為單元測試應(yīng)緊接在編碼之后，當源程序編制完成并通過復(fù)審和編譯檢查，便可開始單元測試。測試用例的設(shè)計應(yīng)與復(fù)審工作相結(jié)合，根據(jù)設(shè)計信息選取測試數(shù)據(jù)，將增大發(fā)現(xiàn)上述各類錯誤的可能性。在確定測試用例的同時，應(yīng)給出期望結(jié)果。
應(yīng)為測試模塊開發(fā)一個驅(qū)動模塊（driver）和（或）若干個樁模塊（stub）,下圖顯示了一般單元測試的環(huán)境。驅(qū)動模塊在大多數(shù)場合稱為“主程序”，它接收測試數(shù)據(jù)并將這些數(shù)據(jù)傳遞到被測試模塊，被測試模塊被調(diào)用后，“主程序”打印“進入-退出”消息。
驅(qū)動模塊和樁模塊是測試使用的軟件，而不是軟件產(chǎn)品的組成部分，但它需要一定的開發(fā)費用。若驅(qū)動和樁模塊比較簡單，實際開銷相對低些。遺憾的是，僅用簡單的驅(qū)動模塊和樁模塊不能完成某些模塊的測試任務(wù)，這些模塊的單元測試只能采用下面討論的集成測試方法。
提高模塊的內(nèi)聚度可簡化單元測試，如果每個模塊只能完成一個，所需測試用例數(shù)目將顯著減少，模塊中的錯誤也更容易發(fā)現(xiàn)。單元測試計劃的編寫應(yīng)該含蓋上述的內(nèi)容，單形式不限，對于測試的數(shù)據(jù)應(yīng)該有效的予以保留，為今后進行數(shù)據(jù)分析作準備。
4.4.2 集成測試
集成測試針對的是各個相關(guān)模塊的組合測試，最終的目標是將整個系統(tǒng)正確的組合成功，沒有明顯的模塊之間的匹配問題。
時常有這樣的情況發(fā)生，每個模塊都能單獨工作，但這些模塊集成在一起之后卻不能正常工作。主要原因是，模塊相互調(diào)用時接口會引入許多新問題。例如，數(shù)據(jù)經(jīng)過接口可能丟失；一個模塊對另一模塊可能造成不應(yīng)有的影響；幾個子功能組合起來不能實現(xiàn)主功能；誤差不斷積累達到不可接受的程度；全局數(shù)據(jù)結(jié)構(gòu)出現(xiàn)錯誤，等等。集成測試是組裝軟件的系統(tǒng)測試技術(shù)，按設(shè)計要求把通過單元測試的各個模塊組裝在一起之后，進行集成測試以便發(fā)現(xiàn)與接口有關(guān)的各種錯誤。
某設(shè)計人員習(xí)慣于把所有模塊按設(shè)計要求一次全部組裝起來，然后進行整體測試，這稱為非增量式集成。這種方法容易出現(xiàn)混亂。因為測試時可能發(fā)現(xiàn)一大堆錯誤，為每個錯誤定位和糾正非常困難，并且在改正一個錯誤的同時又可能引入新的錯誤，新舊錯誤混雜，更難斷定出錯的原因和位置。與之相反的是增量式集成方法，程序一段一段地擴展，測試的范圍一步一步地增大，錯誤易于定位和糾正，界面的測試亦可做到完全徹底。下面討論兩種增量式集成方法。
一、自頂向下集成
自頂向下集成是構(gòu)造程序結(jié)構(gòu)的一種增量式方式，它從主控模塊開始，按照軟件的控制層次結(jié)構(gòu)，以深度優(yōu)先或廣度優(yōu)先的策略，逐步把各個模塊集成在一起。深度優(yōu)先策略首先是把主控制路徑上的模塊集成在一起，至于選擇哪一條路徑作為主控制路徑，這多少帶有隨意性，一般根據(jù)問題的特性確定。以下圖為例，若選擇了最左一條路徑，首先將模塊 M1，M2，M5 和 M8 集成在一起，再將 M6 集成起來，然后考慮中間和右邊的路徑。廣度優(yōu)先策略則不然，它沿控制層次結(jié)構(gòu)水平地向下移動。仍以下圖為例，它首先把M2、M3 和M4 與主控模塊集成在一起，再將M5和M6 和其他模塊集資集成起來。
自頂向下集成測試的具體步驟為：
（1） 以主控模塊作為測試驅(qū)動模塊，把對主控模塊進行單元測試時引入的所有樁模塊用實際模塊替代；
（2）依據(jù)所選的集成策略（深度優(yōu)先或廣度優(yōu)先），每次只替代一個樁模塊；
（3）每集成一個模塊立即測試一遍；
（4）只有每組測試完成后，才著手替換下一個樁模塊；
（5）為避免引入新錯誤，須不斷地進行回歸測試（即全部或部分地重復(fù)已做過的測試）。
從第二步開始，循環(huán)執(zhí)行上述步驟，直至整個程序結(jié)構(gòu)構(gòu)造完畢。
自頂向下集成的優(yōu)點在于能盡早地對程序的主要控制和決策機制進行檢驗，因此較早地發(fā)現(xiàn)錯誤。缺點是在測試較高層模塊時，低層處理采用樁模塊替代，不能反映真實情況，重要數(shù)據(jù)不能及時回送到上層模塊，因此測試并不充分。解決這個問題有幾種辦法，第一種是把某些測試推遲到用真實模塊替代樁模塊之后進行，第二種是開發(fā)能模擬真實模塊的樁模塊；第三種是自底向上集成模塊。第一種方法又回退為非增量式的集成方法，使錯誤難于定位和糾正，并且失去了在組裝模塊時進行一些特定測試的可能性；第二種方法無疑要大大增加開銷；第三種方法比較切實可行，下面專門討論。
二、自底向上集成
自底向上測試是從“原子”模塊（即軟件結(jié)構(gòu)最低層的模塊）開始組裝測試，因測試到較高層模塊時，所需的下層模塊功能均已具備，所以不再需要樁模塊。
自底向上集成測試的步驟分為：
（1）把低層模塊組織成實現(xiàn)某個子功能的模塊群（cluster）;
（2）開發(fā)一個測試驅(qū)動模塊，控制測試數(shù)據(jù)的輸入和測試結(jié)果的輸出；
（3）對每個模塊群進行測試；
（4）刪除測試使用的驅(qū)動模塊，用較高層模塊把模塊群組織成為完成更大功能的新模塊群。
從第一步開始循環(huán)執(zhí)行上述各步驟，直至整個程序構(gòu)造完畢。
自底向上集成方法不用樁模塊，測試用例的設(shè)計亦相對簡單，但缺點是程序最后一個模塊加入時才具有整體形象。它與自頂向集成測試方法優(yōu)缺點正好相反。因此，在測試軟件系統(tǒng)時，應(yīng)根據(jù)軟件的特點和工程的進度，選用適當?shù)臏y試策略，有時混和使用兩種策略更為有效，上層模塊用自頂向下的方法，下層模塊用自底向上的方法。
此外，在集成測試中尤其要注意關(guān)鍵模塊，所謂關(guān)鍵模塊一般都具有下述一或多個特征： ①對應(yīng)幾條需求；②具有高層控制功能；③復(fù)雜、易出錯；④有特殊的性能要求。關(guān)鍵模塊應(yīng)盡早測試，并反復(fù)進行回歸測試。
以上介紹了一些進行集成測試的具體方案，不同的項目，測試經(jīng)理可以根據(jù)實際情況選擇。但是在實施之前，必須給出實施的步驟和時間規(guī)劃。
4.4.3 系統(tǒng)測試
系統(tǒng)測試應(yīng)該由若干個不同測試組成，目的是充分運行系統(tǒng)，驗證系統(tǒng)各部件是否都能正常工作并完成所賦予的任務(wù)。下面簡單介紹幾類系統(tǒng)測試。
（1）驗證測試
以前期的用戶需求規(guī)格說明書的內(nèi)容為依據(jù)，驗證系統(tǒng)是否正確無誤的實現(xiàn)了需求中的全部內(nèi)容。
（2）強度測試
強度測試檢查程序?qū)Ξ惓Ｇ闆r的抵抗能力。強度測試總是迫使系統(tǒng)在異常的資源配置下運行，驗證系統(tǒng)的健壯性是否可靠。
（3）性能測試
對于那些實時系統(tǒng)，軟件部分即使?jié)M足功能要求，也未必能夠滿足性能要求，雖然從單元測試起，每一測試步驟都包含性能測試，但只有當系統(tǒng)真正集成之后，在真實環(huán)境中才能全面、可靠地測試運行性能系統(tǒng)性能測試是為了完成這一任務(wù)。性能測試有時與強度測試相結(jié)合，經(jīng)常需要其他軟硬件的配套支持。
編輯評論意見 （田俊國）
測試和過程控制是構(gòu)筑軟件質(zhì)量的兩個重要環(huán)節(jié)，也是軟件工程化的重要標志。然而，我國大多數(shù)中小型軟件企業(yè)，對軟件測試的重視還很不夠, 媒體上介紹軟件測試的文章也很少。因此，很多軟件工程師對測試知之甚少，甚至對測試心存偏見，不少人認為測試工程師比開發(fā)工程師低一個檔次。而這一點在國外正好相反，在美國，沒有三年以上軟件開發(fā)經(jīng)驗的人是不能做測試工程師的。
本文比較系統(tǒng)地介紹了軟件測試的方方面面，有技術(shù)也有方法；有理論也有作者的實戰(zhàn)體會；更可貴的是專業(yè)的測試理念貫穿全文，比如： 測試的目的是找錯誤，但不僅僅局限于找錯誤；測試是在軟件開發(fā)過程的末尾進行的，但測試人員卻要從需求分析階段就介入項目組… …
文章深入淺出，通俗易懂， 的確是一篇不可多得的軟件測試知識普及性文章。相信軟件開發(fā)同行們會從中大受裨益，參加軟件專業(yè)資格水平考試的朋友們更是不可不讀。
編輯評論意見 （胡志華）
當我還是一名程序員的時候，我也曾為測試而焦頭爛額，我也曾對測試員刁難和不顧；當我作為測試員的角色時，也因無從下手而懊惱，面對測試計劃也表示懷疑和不解；我也曾制定測試計劃、編寫測試用例，主持或參與對軟件或網(wǎng)站的驗收。相信我所遭遇的艱難，您也曾遭遇或者您也許會遭遇，在這個時候，我們都需要交流和學(xué)習(xí)，也許閱讀這篇文章就是一個選擇啊。
本文雖然旨在論述測試計劃的編寫，但是對于測試的其他方面也做了詳細的介紹，例如測試的一些基本概念，測試的幾種類型，測試過程的控制等。
聯(lián)系客服
