如何做一份關于軟件測試工作的規劃？(3)

　　l 凡是可以界說測試用例模板，這樣每個測試用例都有同樣的名目。就像測試用例的名目一樣，可以用差異的步伐來編寫測試用例。這些要領的主要區別是用例的具體水平。在極度的環境下，用例的每一步都具體列出，這樣的話，能擔保運行測試用例的人員在做同樣的工作，并且容易實現自動執行。但對付用例編寫人員來說，意味著復雜的事情量，他必需思量每一個步調。當成果產生變革時，維護這樣的測試用例長短常堅苦的。

　　十二、 系統宣布

　　l 表明如何輸入，辦理，從頭打開，封鎖和從頭即或一個缺陷。

　　A. 數據庫打點

　　2. 測試時間表

　　A. 系統視圖和方針

　　一、先容

　　l 是否有行業尺度可在測試中利用。

　　A. 培訓需求

　　提示和能力：

　　在系統投入利用的時候，最后應作的測試布置。

　　l 在機能測試中，有幾個指標需要留意，如 CPU 利用率內存利用率以及磁盤吞吐率等，這樣能確定系統的瓶頸在哪。是否能舉辦優化。

　　l 假如利用自動測試，區分那些內容無法利用自動測試，哪些部門可以擔保能自動測試。

　　l 測試系統多長時間更新一次(逐日，每周一次或多次，在什么時間，籌備好代碼)?

　　本節說明測試人員需要的各類范例的硬件以及這個測試團隊需要的硬件。

　　l 系統哪些部門的缺陷最會合。

　　l 有哪些大概的邏輯組合?

　　五、測試要領

　　l 在開拓進程和不變階段是否有過多的未處理懲罰缺陷，這大概說明開拓的資源不足，可能有其它問題。

　　l 哪些部門可以自動化?自動化水平有多高。

　　本節說明項目測試人員需要哪些培訓。

　　F. 集成測試計策

　　代碼完成時間

　　l 測試文檔生存的位置

　　這一節主要說明測試打算中重要的和大概有爭議的問題。本節的主要目標是將這些信息通報給那些大概不會通讀整個測試打算文檔的人員(好比司理或開拓項目標認真人)。

　　D. 不變階段測試

　　A. 里程碑技能

　　D. 不變階段測試

　　l 假如內容只是一些輔佐文件，用戶教誨部分會編寫和驗證這些內容。假如系統是以內容為主的，擁有上百萬的文字、千個鏈接以及不行勝數的圖片，在這種環境下需要利用由編輯、校對和測試人員構成的小組來認真內容測試。

　　l 確定主流的客戶端欣賞器版本。

　　里程碑技能將項目標運行分成差異的階段，在項目進程中提供查抄事情希望狀態的要領?？v然只有一個里程碑，也要在這里說明。在說明中，要列出通過和繼承往下走的尺度。

　　l 是否利用自動測試(好比超鏈接測試)。

　　測試打算編寫指南說明測試打算編寫的各個方面。文檔憑據綱要的形式組織。綱要的每個標題下有具體的說明：1. 說明該主題的重要性。 2. 提示和能力。

　　G. 內容測試

　　在測試進程中，可以適當思量利用自動測試計策。自動測試不是擔保產物質量的萬能藥，不能擔保發明軟件的缺陷。自動測試有它的優點和壞處，要充實思量系統特性、時間布置、測試人員的編程履歷和可以利用的自動化工具。

　　測試打算編寫指南

　　A. 培訓需求

　　本節的目標是說明打算中利用的根基的測試進程。

　　環繞軟件質量，有幾種差異的說法。第一個是質量是一種絕對的尺度，對所有的系統必需等同處理懲罰。事實上，質量是相對的并且是和產物相關的觀念。譬喻，多媒體產物的質量方針傾向于精細的暗示和適當的內容，而應用系統大概傾向于易用性、結實性和合用于差異的任務。質量方針大概是動態的。在項目舉辦進程中，會由于市場壓力、新的時機和成果改變而從頭設定質量方針。

　　B. 缺陷處理懲罰進程

　　提示和能力

　　l 缺陷標題、測試情況應如何填寫

　　A. 里程碑技能

　　E. 自動測試計策

　　當項目希望到差異階段時，是否需要更新這些法則。

　　二、配景

　　l 測試人員是否努力發明缺陷，可能過度努力。

　　B. 缺陷處理懲罰進程

　　另一種有關軟件質量的說法是，界說和權衡系統質量是測試部分一個部分的事。實際上，成立質量尺度是所有職能部分配合盡力的功效。測試、開拓、系統利用部分、用戶教誨、系統支撐必需為成立和維護系統的質量尺度做出本身的孝敬。每個部分必需對本身最相識的部門做出相應的質量界說。譬喻，測試和開拓部分對系統質量的權衡尺度主要是結實性和正確性。

　　l 為什么視圖對客戶是重要的?

　　列出項目參加人員的接洽方法包羅 E-mail 和電話。

　　l 與內容提供者確定“什么是內容的缺陷”。制止呈現恍惚的問題，好比“讀起來有點問題”可能“太文縐縐”。

　　這一節說明測試團隊的布局和項目測試人員的數量。

　　C. 軟件需求

　　l 哪些范例的缺陷最普遍。

　　本節說明測試人員需要利用的軟件。

　　l 確定需要幾多測試人員。

　　誰認真成立測試系統，如何保持測試系統和開拓系統之間的同步。

　　在代碼完成到系統最后刊行之前為系統不變階段。在系統不變階段需要對系統的各個部門舉辦最后的查抄?？梢猿闪⒁粋€查抄重點列表，挨項舉辦查抄。

　　I 兼容性測試

　　A. 系統視圖和方針

　　l 在測試中，是否實行代碼包圍，分支包圍和成果包圍。

　　測試打算在計策和要領的高度說明如何打算、組織和打點測試項目。測試打算包括足夠的信息使測試人員大白項目需要做什么是如何運作的。別的，清晰的文檔布局能使任何一個讀者在欣賞打算的前面幾頁后，就能對項目有一個或許的認識。測試打算只是測試的一個框架，許多細節需要跟開拓人員或其他人員相同，因此打算不包羅測試用例的細節和系統成果的具體信息。

　　l 是否有溝通的界面?

　　l 抉擇支持哪些版本的欣賞器。

原文轉自：http://www.rhawkinson.com/ceshi/1085.html