測試工作看起來比較簡單，但是實際上並不是如此容易，它所涉及的內容是很多，而且還要充分地認識到它前期的工作和後期的工作。其中前期的工作就是非常仔細的測試設計和圍繞測試設計所選擇的恰與其分的測試用例。另外這裡的所說的後期工作就是如何對問題進行分析判斷問題在各個部分中存在和分佈的情況，這是一件不容易的事情。這需要充分的測試實戰經驗和能夠合理地、有序地對問題進行分析。這需要有充分的資料資源。基於以上情況，我將綜合五年來我在測試工作上經驗和行動。根據測試部數以百計的測試文件。較系統地綜合歸納測試的工作。

總述

前期的測試文件的設計主要集中在測試大綱的編寫、測試設計（包括測試方法的挑選）的編寫，然後根據測試設計的要求從測試用例庫中精心地挑選具有典型的用例。

對測試前期的文件設計的要求就是能夠根據產品總體設計和產品詳細設計中得到要測試的東西，因為軟體測試的路子千千萬萬條，首先絕對不能保證面面俱到，另外在測試中重複性的路徑測試過多。所以即要保證通過測試設計做到能夠抓住重點，而且還要保證撒出的網的比較大。因此在前期工作中建立的測試大綱和測試設計看起來的就是很重要的，可以說它是指明瞭方向。

（它們二者之間的關係將在圖1）。

測試大綱和測試設計建立出來後，只能說前期測試工作的骨頭架子已經打起來。下面就是要求填血肉的了，這就是在測試設計上選擇能夠適應的測試用例。我認為在前期文件編寫中測試設計的編輯是最耗時間和精力的。誠然編寫一個很好的測試設計是很不容易的，但是難度之二就是選擇測試用例。為了緩解工作壓力，我希望能夠建立一個比較充實的測試用例庫，庫中可以進行有效分類地儲存。當要對一個產品的某一部分使用一種測試方法，可以很容易尋找到相應的測試用例。

圖1

後期的文件的編寫將重點集中在對資料的處理和統計，如將對測試過程中所發現的問題進行系統的整理和統計（主要是通過各種資料統計圖表進行分析）。另外還要對本次測試中的測試用例進行統計和入庫處理。這一點是非常關鍵，因為在後期的文件編寫就是要通過進行資料的各種統計來找出測試中的教訓和經驗。

另外後期的文件的編寫工作還可以很好地支援測試各項的工作順利地開展。

如測試用例庫的建立可以很好地支援的測試的前期文件的編寫，並且將給測試人員給予極其大的幫助。測試問題庫的建立和使用，不僅可以給測試人員極大的幫助，而且它也成為了測試用例庫的很好的素材，並且將有助於開發人員的工作（即可以起到跟蹤問題的效果）。

測試問題庫和測試用例庫的建立和使用。關鍵就是在於這兩個庫的資料一定要詳實。將每一種情況的都要做到分類量化。便於進行各種資料統計。

資料統計中，常用的方法主要就是表格，典型的分析表格就是柏拉圖。另外現在比較的重要的圖表分析方法就是問題分析趨勢圖。建立問題分析趨勢圖對於監管測試工作是一個非常好的方法。做到這一點不是一件非常容易的事情。對監管人要有很好的要求。

後期文件的管理和控制參照圖2

圖2 測試前期的文件——測試大綱

測試大綱可以說一份指導性的檔案。它所起到的作用可以說有以下兩種作用。首先保證在測試中所要測試的面基本上可以起到完全覆蓋的作用。其二是大綱中的內容不僅是首先要求填寫的，有一部分是要求使用者（即為測試者）自行填寫的。

測試大綱的建立和使用是從1998年開始的，經過多年的使用後，發現原先希望它能夠起到的作用的並沒有達到。2001年，測試部著手對測試大綱進行仔細地修改。

後來發現，在建立了測試規範後，測試大綱的作用逐漸明朗起來了。將它和具體的測試設計分家和結合。完成了測試大綱作為總綱地位的確定。

對於測試大綱的設計要求來說，要求不一定很詳細。要求的就是面面俱到，對於每一個面做到點到為止。保證當使用測試大綱時，不會出現遺漏的現象。

新版的測試大綱在設計上和思想的考慮，比以前的測試大綱有了突破。

1、標準化處理：標準化的處理，是對測試文件建立和管理的基本要求。測試大綱的每一條測試路徑都要求進行標準管理。

2、加入測試方法：在測試大綱中加入測試方法的描述，即在測試某一部分時，也要主要地說明它的測試方法。

3、權值的加入：在測試大綱中每一條測試路徑後面都要求加入必要的權值。而且要求在加權值時要對各種引數都要有要求，必須在進行一次主要的測試時，要都要修改權值。而且最好是兩次。頭一次是預期值，第二次是測試完後的實際權值。這樣可以進行合理地比較。現在看起來這是極其重要的（加權值的方法非常重要。在下面將較完整的描述。

測試大綱應該是一種常新常換的檔案，如在權值的設定上，每一次執行系統程式或應用程式，所對應的權值都會發生相應的變化。

測試大綱在設計上應該注重在簡潔性、實用性。能夠方便測試人員使用。內容結構如下：

圖3 測試前期的文件——測試設計

測試前期中最重要的文件就是測試設計，這裡先簡單地說明為什麼要在黑盒測試中考慮到做到測試設計。首先將測試操作分為兩部分，這兩種方法都是相對極端的。第一種方法就是測試憑著自我感覺進行。進行這種測試時不需要打腹稿，想到哪裡就測試到哪裡。第二種方法就是測試的每一步驟都要設定下來並加以文字說明，如象記錄到開啟一個記錄，然後游標定位到某一個欄位，輸入一個位元組。

可以說這兩種方法都存在各自的誤區，第1種方法可以說盲目性太大，並且重複性和遺漏性也比較高。第2種方法在測試設計上又過於僵硬和死板，操作起來沒有更好地變通性。

所以基於以上兩種情況，測試設計就出現了。可以說它是在考慮了上述兩種情況之後，所考慮的一種變通和調節。我們要從測試設計中體現一種思想，這種思想就是在進行功能測試中，我們即要追求測試深度的漸進，還要考慮到測試廣度的延伸覆蓋的程度。

需要自動化，效能測試等免費資料的加我QQ：1784335504免費領取哦

從另一個方面來說，測試設計的編寫實際上使對測試大綱中某一部分的放大。可以說測試大綱的前期的全部編寫可以由測試主管或者測試專案負責人來進行。而測試設計可以分配給各個測試人員來編寫，誰來負責一部分就由誰編寫相關的測試設計。

對編寫測試設計的要求是比較高，主要要求如下：

1、要求在編寫相關的測試設計，要具有一定深度和較大的面。一定的深度的意思就是要切中要害。通過仔細地研究各種技術檔案和被測軟體，對自己認為可能會出現問題的地方做到更深一層的思考和判斷。較大的面就是所鋪開的網儘可能的大。不要存在遺漏，這樣做也可以避免重複性操作的產生。

2、對所瞭解的測試方法也要有要求，測試大綱中的測試方法只是相當於一個概念性的。而在測試設計中所要求的測試方法就要比較具體。比如在時鐘測試中，在走時的精確度的測試，可能就要標註上要用的方法就是比較法。各種的測試方法有很多種，在黑盒測試中主要的測試方法就有：等價類、邊界值、正交法和判定表這樣的方法。

3、在測試設計中對於除了正常的功能測試還需要進行那些特殊的測試，如強度測試、迴歸測試和安全測試等都必須加以標註。

好的測試設計，可以幫助測試人員理清整個測試的脈絡。並且可以很有效地

查詢到測試。這是一份非常重要的文件，它也和測試大綱一樣，為了更高地尋找和發現到錯誤，並且在每一次測試中進行修改。

在測試設計中也要求分清測試專案中哪些是重點，這是貫穿到整個測試。測試設計中的深度的意思也是針對該點。沒有重點就不能談到深度的要求。測試設計經過多次地修改，每一次都能夠確定相關的重點。測試設計中的重點需要進行二次評審。第一次是在進行實測前的確定重點。第二次確定重點是要在實測後重新劃分。第一次的確定主要靠的是經驗。

在測試設計中確定各種測試方法，具體到什麼地方使用什麼樣的測試方法，這是極其關鍵的。在這一點上需要測試人員的經驗的培養。

現在以一份較好的測試設計加以說明：

測試設計上的編寫實際上就是讓測試人員在測試前理清一遍自己的測試思路。這是非常關鍵的。所以對於測試設計上來說，就要求進行必要的測試設計方面的評審工作。

測試前期的工作文件——測試設計和測試用例庫的結合

測試部自2001年4月份就強調測試用例的編寫，在目前並沒有很好的系統地對測試用例進行研究的情況。目前就是將測試用例全部記錄下來。在測試用例比較多的時候，就必須將它象測試問題庫一樣建立起來測試用例庫。測試用例庫的具體建立和操作在這裡不做過多的說明。

這裡想說的就是將測試用例庫中的測試用例和測試設計建立相關聯的方法。讓我們來看看測試用例吧，找出它們之間的規律。看起來針對一個產品的測試用例有成千上萬條。但是通過採取測試方法或者測試範圍找規律，只有最多不超過一百處具有較相同規律的測試用例。

再看看測試設計，固然編好測試設計，需要的是測試人員的經驗。但是如果有一個強大的資料資料庫的支援。就可以為建立一個高效率的測試設計節省了很多時間。而且可以保證你所編寫的測試設計非常精闢。

比如在選擇需要進行安全性測試的情況（即要通過各種正常、異常的操作突破密碼的防範）。在測試設計中編寫到這一部分時，就可以調出以前對安全性測試的資料。可能就會有十幾種供你選擇。

測試的強大資料庫——測試問題庫和測試用例庫

測試工作中我們會記錄下大量的資料資料。其中寶貴的資料是很多的。我們自己有一個習慣，就是喜歡有書面記錄下成績。當然這是很重要的。但是經過我多年的工作下來。我已經越來越不喜歡用書面記錄下記錄。因為這些內容如果沒有專人來管理。很容易會成為壓箱底的東西。

你的資料需要得到靈活的運用。這就需要靠這些手段來完成。因此我建立了測試問題庫這一方式來儲存資料資料。

測試問題庫在許多的高科技開發公司都已經存在。有很多已經實現了自動入庫的方式（即當你出一份測試問題報告，測試問題報告中的資訊就已經編寫到庫中了）。

我強調的是在目前要求測試問題庫中的資訊可以包括很多，並且要記錄下來有價值的內容。因為測試問題庫建立起來，第一不僅要交給測試人員使用，還要幫助開發人員跟蹤問題和修改問題。第二是一個完善的測試問題庫還可以為建立問題分佈柏拉圖和問題分佈分析趨勢圖都有很多的幫助。

從下圖中可以看出，測試問題庫中包含的資訊是比較多的。通過庫可以瞭解到被測軟體的一些基本資訊資料。有描述的比較完善的問題過程、問題現象和問題分析的內容。同時為了便於跟蹤記錄，有兩個欄位就是為了跟蹤問題的發展（特別是對未被改正的問題）。

測試人員通過使用測試問題庫，可以非常方便地查詢問題，另外可以自己在編寫測試文件過程中確定重點的方向。

另外測試問題庫的確立和使用，還有更為深遠的意義。測試問題庫的建立實際上為建立動態地對測試問題的控制和管理打下了良好的基礎。

同樣，為了配合測試工作的順利高效的進行，我們要求建立第二個資料資料庫，這就是測試用例庫。關於測試用例庫的重要性的介紹中，前面在簡要介紹測試前期的文件和後期的文件作用已經通過圖表描述了。

這裡說測試問題庫的建立是對測試結果的儲存和使用。而測試用例的建立就是對測試過程的儲存和使用。

這兩個資料庫極其關鍵和重要，我從事測試工作多年，比較遺憾的事情就是一直在研究對測試工作如何進行有效率的控制，而不是人為地控制。其實現在才發現通過測試問題庫和測試用例庫的使用就是可以進行有效的控制。

測試後期的工作文件——資料統計圖表

在介紹測試兩個巨大的資料庫的內容時，已經提到可以通過圖表描述，那麼這裡有兩種圖表加以介紹。

一種的圖表中就是柏拉圖的方法。柏拉圖的內容可以通過一個具體的例子來進行說明。

問題分析的柏拉圖的內容是由兩個座標組成的，一個是以柱狀圖說明在哪些軟體模組的問題分步數目。第二個是以線狀圖來表示出在總的問題量每一個模組所佔有的問題的百分比的分佈。

通過問題分佈的柏拉圖可以很容易看出哪些問題是很容易出現問題的地方。柏拉圖的作用：第一可以便於可以根據柏拉圖進行問題資料統計分析。另外如果正在分階段地進行對一個大系統的測試。通過柏拉圖還可以進行分階段的問題技術分析。通過每一個階段的柏拉圖來找出這個大系統的問題分佈的一般規律。通過柏拉圖來分析出高風險的問題區域。這一點是非常關鍵的。對於在測試大綱中設定權值有非常大的作用。

問題分析的第二中圖表的分析就是使用缺陷分析圖表。這是一種非常管用的分析圖表。它是用來記錄在測試過程中的問題的變化（也稱‘開啟/關閉’圖表[開啟的意思就是尋找發現問題，而關閉的意思就是修改問題]）。

在一個測試過程，關於發現和修改問題都有一定的規律。

這是一個p5v6.80問題趨勢圖，我們可以把這個圖的變化趨勢分為三個階段（上升階段、中間階段和平緩（結尾）階段）。上升階段就是指剛剛測試產品時，在該階段會發現大量的問題。累計問題數目趨勢線會上升很快，甚至非常陡，這是非常棒的。第2個階段就是中間階段。這個階段就象我們上山一樣。有陡然上升的階段，也有平緩的階段。造成這種情況的是存在著很多我們在測試中不可預知的東西，屬於測試穩定階段。

第3階段在經歷了累計問題數目階段和測試穩定階段。被測試的軟體基本上趨於穩定。在正常狀態下該問題的曲線應該平緩。所說的就是接近直線。當然可能達到這一階段的時間是可以預計的，或者是不可很好地預計。但是我們可以通過該分析圖的下面兩條線做出判斷。一條線是真實地記錄了每一天發現的問題個數，第二條線則就是描述了對這些問題的哪些問題進行了改正。

因為我們知道對問題的改正實際上就增加產生問題的新的隱患。所以每次改正問題後直接的就是在上圖中的趨勢線出現波動。我們希望的每一次改動問題都不會讓趨勢圖發現很大的波動影響。第二就是在到了第3階段時下面的兩條線都可以逐漸接近橫軸。並且沒有什麼樣大的變化。

我們看出在問題分析我們靈活地運用柏拉圖和缺陷分析圖表分析被測模組的高風險性和在測試過程考察被測的效果。總之一句話，我們通過問題分析，可以更好地保證軟體的可靠性。這一點至關重要。

測試後期的工作文件——測試報告和未改問題集

測試報告是組成測試後期工作文件的最重要的技術文件。測試報告主要有五個部分組成：1）測試條件建立的描述；2）柏拉圖的畫制；3）根據柏拉圖進行問題分析，指明高風險區；4）列出未改問題集；5）總體分析評價。

關於第2部分和第3部分在前面已經做了介紹。下面我先說明第1部分和第5部分內容。至於第4部分內容我將單獨說明。

第1部分——測試條件建立的描述：在軟體測試中，建立一個良好的測試環境。所有在測試中涉及到的條件（包括工具、機器配置、編譯環境）以及在相關的企業標準中所涉及到的內容（如指環境測試、強度測試和電氣測試）。一個好的測試環境，可以排除掉一些不存在的問題。也為尋找和修改問題提供了便利。我們認為測試環境應該儘可能和開發除錯中的環境相類似，甚至相同。

特別如果在測試中測試到專門的情況時，如功耗測試或者靈敏度測試時，在建立測試環境時應該由開發人員確認。其實在建立測試環境時，應該由專業人士認可。

正是由於建立一個良好的、完整的和準確的測試環境是那麼重要。那麼我們在編寫測試報告時就應該將一個你所建立的一個較完整的測試環境系統說明清楚。包括上述所說明的內容（詳細的內容可以參照國家軟體文件設計標準）。在特定的情況。如在描述測試電氣特性的時候，可以將接線圖繪製出來。我們希望能夠重點注意一下建立測試環境上，並且能夠較詳細地說明出來。因為上面也說過。出現問題的地方在建立錯誤的測試環境會有很大關係。關於建立一個測試環境的事情。在後面將詳細總結。

第5部分——總體分析評價：請千萬不要忽視掉總體分析評價的內容，當你的測試報告快要寫完的地方，並且感覺很累的時候。希望你能夠在寫總體分析評價時能夠休息一下大腦。想一想在經過一個時間不短的測試後，如何能夠對最終的產品給出一個令人信服的結論。因為總體分析評價的內容可能是在開評估會時就有可能關心的。

現在我們應該認為總體分析評價是最客觀的。最好不要存在什麼主觀的意念。那麼如何才能使總體分析評價具有很強的客觀性和準確性。我想有應該有兩點應該注意就是：

（i） 實事求是，不能夠就人論事。把你自己的主觀感覺強加在總體分析評價中，特別你自己的喜怒哀樂。當然你也不能受外界因素的影響，力求做到按照既定的原則處理。

（ii） 在要求總體分析評價的客觀性中，我想如何要一個總體分析評價客觀性，最好的辦法就是收集和整理各種客觀實際的資料資料。關於收集和整理的客觀資料資料。我們已經在介紹資料統計分析中說明了一些。但是我們還有很多方法可以來運用。關於這一點的詳細介紹我將在《對各種測試資料的靈活統計分析》一文詳細論述。下面我只蜻蜓點水的說明一下。

需要自動化，效能測試等免費資料的加我QQ：1784335504免費領取哦