黑盒測試是以用戶的角度，從輸入數(shù)據(jù)與輸出數(shù)據(jù)的對應(yīng)關(guān)系出發(fā)進行測試的。很明顯，如果外部特性本身有問題或規(guī)格說明的規(guī)定有誤，用黑盒測試方法是發(fā)現(xiàn)不了的。
在需求收集/分析階段，需求人員會對用戶的需求進行詳細(xì)的分析，形成產(chǎn)品說明書/需求說明文檔，做得更好的可以細(xì)化到用例圖，活動圖等UML圖。舉一個例子，下面就是一個游戲人物信息系統(tǒng)的用例圖。
從圖中可以了解這個系統(tǒng)的基本功能，以及各個功能之間的組成。然后可以在測試計劃書中結(jié)合產(chǎn)品說明書對此系統(tǒng)功能塊的測試目標(biāo)進行詳細(xì)的描述，從而保證系統(tǒng)重要功能塊的覆蓋面，后面有經(jīng)驗的案例設(shè)計人員會通過測試計劃書設(shè)計出合理的案例對功能進行測試。這時我們測試人員還可以起到另一個作用，對需求進行評審，比如丟棄物品功能，大家有不同的見解，這時可以讓需求人員進一步確認(rèn)用戶是否需要對丟棄物品功能的需求進行修改。不同系統(tǒng)的產(chǎn)品說明書與用例圖總是不同的，不過在測試人員的眼中，它可是用來確定產(chǎn)品是否可以滿足用戶需求的主要標(biāo)準(zhǔn)，我們可以將它提取出來，寫成測試規(guī)程，測試規(guī)程可以對應(yīng)一個或多個測試用例。這里主要描述產(chǎn)品需要達(dá)到的功能，性能要求，穩(wěn)定性要求。基本要求就是讓測試在早期的需求分析階段就介入項目，對需求有一個整體的把握，有助于確定后期測試的目標(biāo)。當(dāng)然，更高要求是對需求進行評審/測試，論證需求是否可以滿足用戶的要求，從而降低需求帶來的風(fēng)險。
● 同類需求的一致規(guī)范性。在同一個項目中，一些細(xì)節(jié)需要開發(fā)人員統(tǒng)一處理，比如：退出正在編輯的界面，是否彈出提示框；標(biāo)點符號是用中文半角還是全角；錯誤提示是彈出窗口還是顯示在原界面；錯誤提示語與圖標(biāo)風(fēng)格是否統(tǒng)一等等。測試人員（或需求人員）最好能整理出一個列表，通過評審與開發(fā)人員達(dá)成一致，這樣在后期測試時會避免很多不必要的麻煩，也為產(chǎn)品風(fēng)格的統(tǒng)一性鋪好了路基。
2.2測試策略/方案/計劃
測試策略
測試策略要解決的問題是根據(jù)測試需求、資源配備及工程環(huán)境，因地制宜剪裁測試工作，形成測試工作的測試流程。對于一個小項目做大測試是得不償失的，同樣，對一個大項目做小測試也是不負(fù)責(zé)任的。通常，對于工作量小于5個人月的普通商用軟件，重點應(yīng)該抓系統(tǒng)測試（包括功能測試、性能測試及GUI測試等）及驗收測試，而不宜鋪排開來，面面俱到。而對于一個工作量接近30個人月的中型商用軟件而言，一般應(yīng)該認(rèn)真完成需求驗證、設(shè)計驗證、單元測試、集成測試、系統(tǒng)測試及驗收測試，而不宜只關(guān)注系統(tǒng)測試。但這并不絕對，針對產(chǎn)品的測試流程設(shè)計還需要從用戶的實際需求出發(fā)，比如，用戶希望軟件有好的人機交互界面，這時，就應(yīng)該考慮采用快速原型生成工具來進行用戶界面設(shè)計的測試； 又如用戶希望軟件有較好的健壯性，這時，就應(yīng)該考慮進行相應(yīng)的負(fù)載測試/可恢復(fù)性測試等性能測試內(nèi)容。
一個好的測試策略設(shè)計應(yīng)能清楚地回答下列問題：是否在測試成本與測試預(yù)期效果之間達(dá)到了最佳平衡？是否在測試需求與測試活動安排之間達(dá)到了最佳平衡？策略設(shè)計形成的技術(shù)路線是否在工程實際與企業(yè)質(zhì)量承諾之間達(dá)到了最佳平衡？策略設(shè)計形成的技術(shù)路線是否具有可行性？有無設(shè)計依據(jù)？
測試方案
測試方案是對測試策略設(shè)計形成的技術(shù)路線的進一步細(xì)化。如某一技術(shù)路線規(guī)定了某小型軟件項目測試工作要重點圍繞“功能測試與驗收測試”展開。那么測試方案設(shè)計階段就必須具體定義哪些功能需要被測試到，以及如何去測試，哪些部分需要做驗收，以及采用什么形式做。
測試方案的設(shè)計除了要明確定義各個測試活動的對象、執(zhí)行人員、測試進度、放行標(biāo)準(zhǔn)等一系列屬性外，還要充分考慮到成本與技術(shù)可行性。一個好的測試方案總是遵循以下設(shè)計原則：測試成本與測試工作產(chǎn)生的效益處于最佳比值； 各具體測試活動描述清晰，目標(biāo)明確，內(nèi)容完備； 測試手段是可行的； 測試產(chǎn)生的結(jié)果是可以用于指導(dǎo)產(chǎn)品質(zhì)量改進的。
測試計劃
測試計劃是將測試方案具體安排到項目的各個周期中，確定在項目各個周期中具體實施的測試工作。
所以，最終的測試計劃可能包括以下40點：
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
標(biāo)題 | 軟件標(biāo)識 | 目錄 | 文檔的目的和閱讀人群 | 測試對象描述 | 軟件產(chǎn)品概述 | 相關(guān)文檔列表 | 有關(guān)的標(biāo)準(zhǔn)/法規(guī) | 可追溯的需求 | 有關(guān)的命名約定和標(biāo)識約定 |
項目相關(guān)部門和成員/聯(lián)系信息/職責(zé) | 測試項目組和人員/聯(lián)系信息/職責(zé) | 假設(shè)和依賴 | 項目風(fēng)險分析 | 測試優(yōu)先級和重點 | 范圍和測試限制 | 測試過程描述 | 采用的測試方法描述 | 測試環(huán)境描述 | 測試環(huán)境有效性分析 |
測試環(huán)境建立/配置 | 軟件移植性 | 軟件配置管理過程 | 測試數(shù)據(jù)建立需求 | 系統(tǒng)和錯誤日志描述 /工具 | 缺陷管理/輔助工具 | 自動化測試描述 | 測試工具描述 | 測試腳本/測試代碼維護過程和版本控制 | 跟蹤/解決的工具和流程 |
項目測試度量標(biāo)準(zhǔn) | 報告需求/測試交付產(chǎn)品 | 軟件入口/出口標(biāo)準(zhǔn) | 測試周期/標(biāo)準(zhǔn) | 測試暫停/重啟標(biāo)準(zhǔn) | 人員分配 | 人員培訓(xùn) | 測試地點/場所 | 測試項目組之外可用的資源 | 與所有權(quán)相關(guān)的級別/分類/安全/許可 |
此階段的難點和重點：
● 測試周期時間點的確定：
△ 實際測試總比你預(yù)想的要花更多的時間，遇到更多的麻煩，所以要盡量爭取足夠的測試時間。還要盡可能考慮到測試過程中的風(fēng)險，比如測試環(huán)境的問題、部署失敗的問題、開發(fā)延期的問題、人員變動的問題等等。盡量避免不加思索的說這個東西我一星期肯定可以測完。
△ 多參考軟件開發(fā)管理類文檔，在測試的時間進度安排上與開發(fā)保持同步，如果是整機測試，還需要考慮硬件開發(fā)團隊的進度計劃。
● 測試資源的配置：
△ 最常見的就是角色安排多，測試人員少。解決這一問題的根本途徑是招募測試人才，建設(shè)高效測試團隊。然而，遠(yuǎn)水解不了近渴。那么，就需要考慮一下變通之策：外包和外協(xié)都是不錯的處理辦法。
△ 不同部門之間配置專門的接口人負(fù)責(zé)項目信息的快速有效傳遞，減少人多口雜或信息不流通引起的項目風(fēng)險。
△ 建議適當(dāng)考慮自動測試工具，某些工具的確能減少工作壓力。
△ 了解測試團隊各成員的專業(yè)技能與興趣也是很重要的，避免無人擔(dān)當(dāng)相應(yīng)角色。
● 測試標(biāo)準(zhǔn)的設(shè)定：
△ 測試標(biāo)準(zhǔn)以用戶需求和功能技術(shù)規(guī)范文檔為基礎(chǔ)，根據(jù)項目不同的實際情況設(shè)定不同的標(biāo)準(zhǔn)，切不可一成不變。
△ 盡量提高測試?yán)щy部分的標(biāo)準(zhǔn)：如自動化測試工具開發(fā)/環(huán)境搭建的標(biāo)準(zhǔn)，集成測試的執(zhí)行規(guī)范，性能測試的執(zhí)行手冊等等。高要求才能出好產(chǎn)品，往往最困難的部分，就是項目成敗的關(guān)鍵。同時，也是整個測試團隊需要提升和學(xué)習(xí)的重點技術(shù)。
2.3 測試環(huán)境搭建
測試環(huán)境（test environment）是指測試運行其上的軟件和硬件環(huán)境的描述，以及任何其它與被測軟件交互的軟件，包括驅(qū)動和樁。測試環(huán)境是指為了完成軟件測試工作所必需的計算機硬件、軟件、網(wǎng)絡(luò)設(shè)備、歷史數(shù)據(jù)的總稱。毫無疑問，穩(wěn)定和可控的測試環(huán)境，可以使測試人員花費較少的時間就完成測試用例的執(zhí)行，也無需為測試用例、測試過程的維護花費額外的時間，并且可以保證每一個被提交的缺陷都可以在任何時候被準(zhǔn)確的重現(xiàn)。
簡單的說，經(jīng)過良好規(guī)劃和管理的測試環(huán)境，可以盡可能的減少環(huán)境的變動對測試工作的不利影響，并可以對測試工作的效率和質(zhì)量的提高產(chǎn)生積極的作用。
一般來說，按照測試計劃的要求按部就班就可以完成測試工作所需要的軟件/硬件/操作系統(tǒng)/數(shù)據(jù)配置/接口等環(huán)境的搭建。
此階段的難點和重點：
● 測試環(huán)境的搭建需要從實際出發(fā)：
△ 根據(jù)項目的實際需求組成恰當(dāng)?shù)臏y試環(huán)境，不同的質(zhì)量標(biāo)準(zhǔn)/行業(yè)應(yīng)用/公司狀態(tài)都可能搭建出不同測試環(huán)境。搭建環(huán)境之前，需要先列出測試計劃中的各種環(huán)境需求，然后針對每一個需求進行分析，哪些是目前已有的，哪些是需要請其他部門幫助協(xié)調(diào)的，然后逐一完成。針對于不能完成的部分，列出對項目的風(fēng)險以及是否還有其他補救措施等等。
● 測試環(huán)境不是一成不變的：
△ 項目實際執(zhí)行過程中，測試環(huán)境是經(jīng)常變化，比如測試軟件版本更新、測試人員流失等等，需要隨時跟蹤和改進，盡量將可控的資源進行分類整理。可控資源包括：測試環(huán)境配置手冊、測試硬件信息、環(huán)境變更記錄等等。目的是盡量將測試環(huán)境進行備份，方便出現(xiàn)未知問題時快速的還原。
2.4 測試規(guī)程/用例設(shè)計
測試規(guī)程（test procedure）是一個提供詳細(xì)的測試用例執(zhí)行指令的文檔。測試規(guī)程應(yīng)該更注重測試的流程、方法等比較泛的內(nèi)容，以方便我們對測試用列的編寫有一個整體的概念和把握。不同的公司規(guī)范、要求和詳盡程度可能不同。
測試用例（test case）對一項特定的軟件產(chǎn)品進行測試任務(wù)的描述，體現(xiàn)測試方案、方法、技術(shù)和策略。內(nèi)容包括測試目標(biāo)、測試環(huán)境、輸入數(shù)據(jù)、測試步驟、預(yù)期結(jié)果、測試腳本等，并形成文檔。
測試規(guī)程與測試用例的區(qū)別：理想化的測試用例確實需要很多測試數(shù)據(jù)集合，但是現(xiàn)實中對某一軟件進行測試時，由于涉及的面太廣，無法一一列舉出所有數(shù)據(jù)，所以要根據(jù)公司的規(guī)范來做相應(yīng)的調(diào)整。所以，測試規(guī)程的文檔編輯量較輕，但是只適合熟練的測試人員執(zhí)行，而測試用例的執(zhí)行者可以使任何人。
測試用例的設(shè)計：
測試用例可以分為基本事件、備選事件和異常事件。
● 設(shè)計基本事件的用例：參照用例規(guī)約（或設(shè)計規(guī)格說明書），根據(jù)關(guān)聯(lián)的功能、操作按路徑分析法設(shè)計測試用例。而對孤立的功能則直接按功能設(shè)計測試用例。基本事件的測試用例應(yīng)包含所有需要實現(xiàn)的需求功能，覆蓋率達(dá)100%。
● 設(shè)計備選事件和異常事件的用例：采用的基本方法仍然是等價類劃分、邊界值、因果圖等，根據(jù)軟件的不同性質(zhì)和測試的不同目標(biāo)靈活運用，至于最終設(shè)計的測試用例是否能暴露更多的隱藏缺陷，全憑用例設(shè)計人員的豐富經(jīng)驗和精心設(shè)計了。例如，測試一個手機終端的電話本模塊。測試人員需要考慮，將相同的號碼A存儲到不同聯(lián)系人名B和C 中，號碼A呼入和呼出時，顯示的聯(lián)系人名應(yīng)該是B還是C呢。類似這樣的備選事件，往往在需求階段描述的并不詳盡，需要測試人員及早提出并與項目組達(dá)成一致。
測試用例在軟件測試中的作用 ：
● 指導(dǎo)測試的實施
● 規(guī)劃測試數(shù)據(jù)的準(zhǔn)備
● 編寫測試腳本的“設(shè)計規(guī)格說明書”
● 評估測試結(jié)果的度量基準(zhǔn)
● 分析缺陷的標(biāo)準(zhǔn)
此階段的難點和重點：
測試用例設(shè)計的幾大基本點
● 使用合理的語言
– 測試人員該做什么，系統(tǒng)輸出什么應(yīng)該寫得很清楚明白，也就是說首先要分清楚測試用例的輸入和預(yù)期輸出
– 一種最好的避免含義混淆的方法是在操作步驟中采用動詞+名詞的結(jié)構(gòu)，動詞總是測試人員要做得事情，名詞總是測試人員操作的對象、事物
– 將同一個事物命名為同一個名稱，不管這個事物是否通過不同的方式出現(xiàn)
● 測試用例的易測性
– 簡潔性
簡潔性的衡量方法就是執(zhí)行測試花費時間的長短以及在測試過程中是否能保持整個測試的純凈
– 正確性
正確性意味著測試人員根據(jù)測試用例進行的測試獲得的測試結(jié)果（通過或不通過）是正確的
● 控制測試用例的長度
– 在Step-by-step用例中一個比較好的長度是不多于15步：
△ 執(zhí)行每個測試用例花費更少的時間
△ 測試人員很少犯錯誤、丟失步驟或需要幫助
△ 測試經(jīng)理能夠準(zhǔn)確地估計測試的時間
△ 測試結(jié)果更容易跟蹤
● 控制測試用例的操作時間
– 對于Matrix用例，一個好的測試用例的長度的衡量標(biāo)準(zhǔn)是是否能再20分鐘內(nèi)測試完畢
● 測試用例依賴關(guān)系的利弊
– 具有依賴關(guān)系的測試用例是一些需要依靠先前的測試用例執(zhí)行的結(jié)果來執(zhí)行的用例
– 考慮是否真的需要其他的測試的結(jié)果作為數(shù)據(jù)輸入，如果是，那么測試必需是累積的。應(yīng)盡量避免這種情況
– 保持測試用例依賴關(guān)系的正確性和一致性
– 以一種合理的順序來安排測試用例的順序
測試用例設(shè)計的五大誤區(qū)
● 過分追求“能發(fā)現(xiàn)到目前為止沒有發(fā)現(xiàn)的缺陷的用例是好的用例”
實際測試中，很多人一心想要設(shè)計出發(fā)現(xiàn)“難于發(fā)現(xiàn)的缺陷”而陷入盲區(qū)，忘記了測試的真實目的所在。測試只 需要保證兩點就能達(dá)到測試目的：1）、程序做了它應(yīng)該做的事情 ；2）、程序沒有做它不該做的事情。在做好這兩點基礎(chǔ)上，才談得上改進測試用例，使其“發(fā)現(xiàn)沒有的缺陷“。
● 過分抬高測試用例設(shè)計標(biāo)準(zhǔn)，達(dá)到“使一個沒有接觸過系統(tǒng)的人員也能進行測試“的程度
不知道有沒有公司真正做到這點，能夠?qū)⒚總€測試用例都寫得如此詳細(xì)。之前看了微軟關(guān)于一個工具的GUI 測試用例，它分了幾部分，第一部分是一些啟動/進入模塊的case，感覺確實很詳細(xì)，基本達(dá)到能認(rèn)識英文就能操作的層次。然后在后期關(guān)于具體功能測試時，依然出現(xiàn)前置條件（測試環(huán)境）不充分的問題，比如在某一部分的Case中，測試環(huán)境中要求將文件A 先拷貝到指定目錄下，然后在進行Test Step。在這部分的第一個 Case中有這關(guān)測試環(huán)境環(huán)境的搭建，但是后面幾個Case就沒有了（如果只做后面幾個Case的話，按照Step來操作直接就Fail了）…微軟尚且如此，偶相信其他公司也不會高明到哪里去。
測試的目的是盡可能發(fā)現(xiàn)程序中存在的缺陷。每個公司實際情況不同，每個項目的實際情況也不同，所以需要因地制宜，根據(jù)實際情況制定測試用例的設(shè)計標(biāo)準(zhǔn)。如果項目周期短，工作量大，甚至可以考慮使用測試規(guī)程來代替測試用例指導(dǎo)實際的測試執(zhí)行。
● 測試用例沒有包含實際的數(shù)據(jù)
先看一個例子，某測試人員需要檢查編輯框內(nèi)是否不允許輸入英文，他設(shè)計的測試步驟為“輸入任意英文字符”。大家覺得是否很熟悉？
測試用例是“一組輸入、執(zhí)行條件、預(yù)期結(jié)果”、毫無疑問地應(yīng)該包括清晰的輸入數(shù)據(jù)和預(yù)期輸出，沒有測試數(shù)據(jù)的用例最多只具有指導(dǎo)性的意義，不具有可執(zhí)行 性。當(dāng)然，測試用例中包含輸入數(shù)據(jù)會帶來維護、與測試環(huán)境同步之類的問題，這就有回到測試用例的設(shè)計標(biāo)準(zhǔn)上了，還是那句話：根據(jù)實際情況選擇適合自己團隊的規(guī)范標(biāo)準(zhǔn)。
● 需求/設(shè)計變更，而測試用例確沒有修改
看似明顯的錯誤，卻是在在執(zhí)行階段經(jīng)常出現(xiàn)的老毛病。往往在軟件需求和設(shè)計已經(jīng)變更了多次，測試人員覺得這些問題自己知道就行，測試用例沒有任何修改。結(jié)果導(dǎo)致新加入的測試人員在執(zhí)行測試用例不知所措，也使測試用例間接變成一堆廢紙。
● 測試用例中預(yù)期輸出過于簡單
很多測試用例中，“預(yù)期輸出”僅簡單描述為應(yīng)用程序的直觀反映，其實，“預(yù)期輸出”還需要更深一層的描述。例如，對一個存儲系統(tǒng)， 輸入存儲數(shù)據(jù)，點擊確定，預(yù)期輸出為“系統(tǒng)提示成功”。這樣的用例完整嗎呢？系統(tǒng)提示成功就表示數(shù)據(jù)成功存儲了？顯然，還需要去相應(yīng)界面查看數(shù)據(jù)是否更新。