以前在這里看到一篇文章說，要積累各個常用模塊的測試點，然后到需要測試的時候就根據這些測試點設計測試用例，我覺得這是一個好方法，就決定總結一下。我的實際經驗不多，根據我在論壇中學到的零散的東西和自己的想象，總結出以下幾點，歡迎各位繼續補充。
1、登陸
2、添加
3、查詢
4、刪除
1、登陸
① 用戶名和密碼都符合要求（格式上的要求）
② 用戶名和密碼都不符合要求（格式上的要求）
③ 用戶名符合要求，密碼不符合要求（格式上的要求）
④ 密碼符合要求，用戶名不符合要求（格式上的要求）
⑤ 用戶名或密碼為空
⑥ 數據庫中不存在的用戶名，不存在的密碼
⑦ 數據庫中存在的用戶名，錯誤的密碼
⑧ 數據庫中不存在的用戶名，存在的密碼
⑨ 輸入的數據前存在空格
⑩ 輸入正確的用戶名密碼以后按[enter]是否能登陸
2、添加
① 要添加的數據項均合理，檢查數據庫中是否添加了相應的數據
② 留出一個必填數據為空
③ 按照邊界值等價類設計測試用例的原則設計其他輸入項的測試用例
④ 不符合要求的地方要有錯誤提示
⑤ 是否支持table鍵
⑥ 按enter是否能保存
⑦ 若提示不能保存，也要察看數據庫里是否多了一條數據
3、刪除
① 刪除一個數據庫中存在的數據，然后查看數據庫中是否刪除
② 刪除一個數據庫中并不存在的數據，看書否有錯誤提示，并且數據庫中沒有數據被刪除
③ 輸入一個格式錯誤的數據，看是否有錯誤提示，并且數據庫中沒有數據被刪除。
④ 輸入的正確數據前加空格，看是否能正確刪除數據
⑤ 什么也不輸入
⑥ 是否指出table鍵
⑦ 是否支持enter鍵
4、查詢
精確查詢：
① 輸入的查詢條件為數據庫中存在的數據，看是否能正確地查出相應得數據
② 輸入正確的查詢條件以前加上空格，看是否能正確地查出相應的數據
③ 輸入格式或范圍不符合要求的數據，看是否有錯誤提示
④ 輸入數據庫中不存在的數據
⑤ 不輸入任何數據
⑥ 是否支持table鍵
⑦ 是否支持enter鍵
模糊查詢：
在精確查詢的基礎上加上以下一點
① 輸入一些字符，看是否能查出數據庫中所有的相關信息
設計功能和界面測試用例
1.1 文本框、按鈕等控件測試
1.1.1 文本框的測試
如何對文本框進行測試
a，輸入正常的字母或數字。
b，輸入已存在的文件的名稱；
c，輸入超長字符。例如在“名稱”框中輸入超過允許邊界個數的字符，假設最多255個字符，嘗試輸入 256個字符，檢查程序能否正確處理；
d，輸入默認值，空白，空格；
e，若只允許輸入字母，嘗試輸入數字；反之；嘗試輸入字母；
f，利用復制，粘貼等操作強制輸入程序不允許的輸入數據；
g，輸入特殊字符集，例如，NUL及\n等；
h，輸入超過文本框長度的字符或文本，檢查所輸入的內容是否正常顯示；
i，輸入不符合格式的數據，檢查程序是否正常校驗，如，程序要求輸入年月日格式為yy/mm/dd，實際輸入yyyy/mm/dd，程序應該給出錯誤提示
在測試過程中所用到的測試方法：
1，輸入非法數據；
2，輸入默認值；
3，輸入特殊字符集；
4，輸入使緩沖區溢出的數據；
5，輸入相同的文件名；
命令按鈕控件的測試
測試方法：
a，點擊按鈕正確響應操作。如，單擊確定，正確執行操作；單擊取消，退出窗口；
b，對非法的輸入或操作給出足夠的提示說明，如，輸入月工作天數為32時，單擊”確定“后系統應提示：天數不能大于31；
c，對可能造成數據無法恢復的操作必須給出確認信息，給用戶放棄選擇的機會；
單選按鈕控件的測試
測試方法：
a，一組單選按鈕不能同時選中，只能選中一個。
b，逐一執行每個單選按鈕的功能。分別選擇了“男”“女”后，保存到數據庫的數據應該相應的分別為“男”“女”；
c，一組執行同一功能的單選按鈕在初始狀態時必須有一個被默認選中，不能同時為空；
控件文本框的測試
測試方法：
a，直接輸入數字或用上下箭頭控制，如，在“數目”中直接輸入10，或者單擊向上的箭頭，使數目變為10；
b，利用上下箭頭控制數字的自動循環，如，當最多數字為253時，單擊向上箭頭，數目自動變為1；反之亦適用；
c，直接輸入超邊界值，系統應該提示重新輸入；
d，輸入默認值，空白。如，“插入”數目為默認值，點擊“確定”；或，刪除默認值，使內容為空，單擊“確定”進行測試；
e，輸入字符。此時系統應提示輸入有誤。
組合列表框的測試
測試方法：
a，條目內容正確，其詳細條目內容可以根據需求說明確定；
b，逐一執行列表框中每個條目的功能；
c，檢查能否向組合列表框輸入數據；
復選框的測試
測試方法：
a，多個復選框可以被同時選中；
b，多個復選框可以被部分選中；
c，多個復選框可以都不被選中；
d，逐一執行每個復選框的功能；
列表框控件的測試
測試方法：
a，條目內容正確；同組合列表框類似，根據需求說明書確定列表的各項內容正確，沒有丟失或錯誤；
b，列表框的內容較多時要使用滾動條；
c，列表框允許多選時，要分別檢查shift選中條目，按ctrl選中條目和直接用鼠標選中多項條目的情況；
滾動條控件的測試
要注意一下幾點：
a，滾動條的長度根據顯示信息的長度或寬度及時變換，這樣有利于用戶了解顯示信息的位置和百分比，如，word中瀏覽100頁文檔，瀏覽到50頁時，滾動條位置應處于中間；
b，拖動滾動條，檢查屏幕刷新情況，并查看是否有亂碼；
c，單擊滾動條；
d，用滾輪控制滾動條；
e，滾動條的上下按鈕。
各種控件在窗體中混和使用時的測試
a，控件間的相互作用；
b，tab鍵的順序，一般是從上到下，從左到右；
c，熱鍵的使用，逐一測試；
d，enter鍵和esc鍵的使用；
在測試中，應遵循由簡入繁的原則，先進行單個控件功能的測試，確保實現無誤后，再進行多個控件的的功能組合的測試。
ps：密碼輸入框測試時要特別注意進行字母大寫輸入的測試。
查找替換操作
測試本功能有通過測試和失敗測試兩種情況
通過測試：
1，輸入內容直接查找，或查找全部
2，在組合框中尋找已經查找過的內容，再次查找并確認文檔的內容正確，如，已經查找過"測試用例"，再次進入不用重新輸入查找內容，直接在文檔中搜尋就可以。
失敗測試：
1，輸入過長或過短的查詢字符串.如，假設查詢的字符串長度為1到255，那么輸入0，1，2，256，255和254進行測試；
2，輸入特殊字符集，如，在word中.^g代表圖片，^代表分欄符，可以輸入這類特殊字符測試；
替換測試大體相同。
關于編輯操作窗口的功能測試的用例：
1，關閉查找替換窗口.不執行任何操作，直接退出；
2，附件和選項測試.假如，設定"精確搜尋"，"向后"搜索等附件選項等等來測試；
3，控件間的相互作用.如，搜尋內容為空時，按鈕"搜尋全部"，"搜尋"，"全部替換"，"替換"都為灰色。
4，熱鍵， Tab鍵.回車鍵的使用。
插入操作
1，插入文件
測試的情況
a，插入文件；
b，插入圖像；
c，在文檔中插入文檔本身；
d，移除插入的源文件；
e，更換插入的源文件的內容；
2，鏈接文件
測試方法：
a，插入鏈接文件；
b，在文檔中鏈接文檔本身；
c，移除插入的源文件；
d，更換插入的源文件的內容。
3，插入對象
要測試的內容
a，插入程序允許的對象，如，在word中插入excel工作表；
b，修改所插入對象的內容.插入的對象仍能正確顯示；
c，卸載生成插入對象的程序，如，在word中插入excel工作表后卸載excel，工作表仍正常使用。
編輯操作
編輯操作包括剪切，復制，粘貼操作。
測試剪切操作的方法
a，對文本，文本框，圖文框進行剪切；
b，剪切圖像
c，文本圖像混合剪切
復制操作方法與剪切類似。
測試時，主要是對粘貼操作的測試，方法是：
a，粘貼剪切的文本，文本框及圖文框；
b，粘貼所剪切的圖像；
c，剪切后，在不同的程序中粘貼；
d，多次粘貼同一內容，如，剪切后，在程序中連續粘貼3次；
e，利用粘貼操作強制輸入程序所不允許輸入的數據。
界面測試用例的設計方法
1，窗體
測試窗體的方法：
a，窗體大小，大小要合適，控件布局合理；
b，移動窗體.快速或慢速移動窗體，背景及窗體本身刷新必須正確；
c，縮放窗體，窗體上的控件應隨窗體的大小變化而變化；
d，顯示分辨率.必須在不同的分辨率的情況下測試程序的顯示是否正常；
進行測試時還要注意狀態欄是否顯示正確；工具欄的圖標執行操作是否有效，是否與菜單懶中圖標顯示一致；錯誤信息內容是否正確，無錯別字，且明確等等；
2，控件
測試方法：
a，窗體或控件的字體和大小要一致；
b，注意全角，半角混合
c，無中英文混合
菜單
進行測試時要注意
a，選擇菜單是否可以正常工作，并與實際執行內容一致；
b，是否有錯別字：
c，快捷鍵是否重復；
d，熱鍵是否重復；
e，快捷鍵與熱鍵操作是否有效
f，是否存在中英文混合
g，菜單要與語境相關，如，不同權限的用戶登陸一個應用程序，不同級別的用戶可以看到不同級別的菜單并使用不同級別的功能；
h，鼠標右鍵快捷菜單
特殊屬性
1，安裝界面應有公司介紹或產品介紹，有公司的圖標
2，主界面及大多數界面最好有公司圖標
3，選擇"幫助"->"關于"命令，應 看見相關版權和產品信息
實際中經常用到的幾個用例
login
1、鏈接地址是否正確。
2、產生輸入/輸出錯誤時，系統是否進行檢測并處理.
3、密碼輸入框是否按掩碼的方式顯示。
menu：
1、各模塊鏈接地址是否正確。
2、鼠標無規則點擊時是否會產生無法預料的結果。
browse：
1、瀏覽信息是否存在文字書寫錯誤和語法錯誤。
2、瀏覽信息是否和數據庫中對應的字段及信息相一致。
3、瀏覽頁面中的鏈接按鈕是否可以正確鏈接并顯示。
4、其他功能按鈕按下后，數據是否按既定規約處理。
add，modify：
1、產生輸入/輸出錯誤時，系統是否進行檢測并處理。
2、列表框是否能夠進行選擇。
3、單選組內是否有且只有一個單選鈕可選。
4、多選組內是否能夠進行多數據項選擇。
5、多項列表框是否能夠進行多數據項選擇。
6、控件是否存在默認輸入值，若存在，默認值是否得到顯示和提交。
7、Cancel之類的按鈕按下后，控件中的數據是否清空復原或按既定規約處理。
8、Submit之類的按鈕按下后，數據是否得到提交或按既定規約處理。
9、其他頁面按鈕按下后，數據是否按既定規約處理。
10、異常信息表述是否正確。
search：
1、輸入信息中是否存在和代碼中的字符產生沖突的字符，系統是否進行檢測并處理。
2、異常信息表述是否正確。
3、查詢的結果是否正確。
4、列表框是否能夠進行選擇。
5、單選組內是否有且只有一個單選鈕可選。
6、多選組內是否能夠進行多數據項選擇。
7、多項列表框是否能夠進行多數據項選擇。
8、Submit之類的按鈕按下后，數據是否得到提交或按既定規約處理。
Statistic：
1、產生的文件和數據表的計算結果是否正確。
2、圖表結果數據顯示是否正確。
3、瀏覽頁面中的鏈接按鈕是否可以正確鏈接并顯示。
4、其他功能按鈕按下后，數據是否按既定規約處理。
5、產生輸入/輸出錯誤時，系統是否進行檢測并處理。
6、列表框是否能夠進行選擇。
7、單選組內是否有且只有一個單選鈕可選。
8、多選組內是否能夠進行多數據項選擇。
9、多項列表框是否能夠進行多數據項選擇。
從網上搜索測試用例的評審，也能搜出好多，我這里把自己能想到的或是借鑒于他人的都在這里進行總結和歸納。
測試用例的設計很重要，無論你采用的是敏捷測試還是傳統的開發模式，測試用例都應該要文檔化，并且根據項目的schedule，把握好粒度。而QA lead要根據項目的實際情況，先定好模板，制定好測試用例的編寫規范。測試用例設計出來，質量如何？這就需要對測試用例進行評審，這個過程非常重要，對測試人員的能力提高，測試效率的提高都有很好的作用。如果公司流程沒有這個硬性要求，項目再忙，也要抽出一定時間，召集相關人員開個哪怕是非正式的評審會議，大家一起討論用例并給出意見和建議，及時發現問題，并完善測試用例的設計。
何時進行用例的評審，一般情況下是在用例的初步設計完成之后進行評審，如果需要或時間允許，在整個詳細用例全部完成之后還會進行二次評審，三次評審等。
大體分文三個級別的評審：
a）部門評審，測試部門全體員工參與的評審。
b）公司評審，這里包括了項目經理，需求分析人員，架構設計人員，開發人員和測試人員。
c）客戶評審，包括了客戶方的開發人員和測試人員。
測試用例的評審檢查單（Checklist for Test cases）：
1）Has the correct template been used？（是否使用了正確的模板？）
2）Have all the scenarios specified in the requirement –explicit， implicit， nonfunctional and been converted into test conditions？（是否覆蓋了需求規格說明，包括內在需求和外在和非功能需求？）
3）Have the related areas that include possibly be affected by the implementation of the requirement been identified and included in the test cases？（case是否對需求變更的部分進行對應的調整和增加？）
4）Have the following details been filled up correctly？ Requirement references， test procedure， expected result， priority， author’s name， date created…（測試用例是否正確填寫了測試對應的需求，測試步驟，預期結果，優先級，作者姓名，創建日期等..）
5）Has the test date set， if required been generated appropriate？ （測試用例是否包含測試數據，測試數據的生成是否正確？）
6）Have the required negative scenario between identified in the test conditions？ （是否包含了負面測試用例？）
7）Have the testing techniques—equivalence partitioning， boundary value analysis be used？ （是否使用了等價類劃分和邊界值分析的測試方法？）
8）Have the steps been correctly given in appropriate sequence for each test scenario？ （測試步驟是否被闡述清楚？）
9）Have the expected result been identified correctly？ （預期結果是否表達正確？）
● Expected results should respond to the user actions given in each step/action.（每個步驟都應給出相應的測試結果）
● Ensure that too many things are not included to be verified under one expected output.（給出一個預期結果的驗證步驟不要太多）
● Ensure that separate cases are written for multiple verifications of the application’s behavior. （每條case最好驗證一個問題）
● Vague statements like “Appropriate message/value/screen” etc. should not be part of expected result. Every detail should be clearly spelt out. （預期結果中不要使用模糊的語言）
1、引言
測試設計遵循與軟件設計相同的工程原則。好的軟件設計包含幾個對測試設計進行精心描述的階段。這些階段是：
● 測試策略
● 測試計劃
● 測試描述
● 測試過程
上述四個測試設計階段適用于從單元測試到系統測試各個層面的測試。
測試設計由軟件設計說明所驅動。單元測試用于驗證模塊單元實現了模塊設計中定義的規格。一個完整的單元測試說明應該包含正面測試（Positive Testing）和負面的測試（Negative Testing）。正面測試驗證程序應該執行的工作，負面測試驗證程序不應該執行的工作。
設計富有創造性的測試用例是測試設計的關鍵。本文檔介紹了測試說明的一般設計過程，描述了一些結構化程序設計單元測試中采用的用例設計技術，同時也增加了面向對象編程中對類進行單元測試所采用的測試用例設計技術，這些可作為軟件測試人員的參考閱讀資料。
2、設計單元測試說明
一旦模塊單元設計完畢，下一個開發階段就是設計單元測試。值得注意的是，如果在書寫代碼之前設計測試，測試設計就會顯得更加靈活。一旦代碼完成，對軟件的測試可能會傾向于測試該段代碼在做什么（這根本不是真正的測試），而不是測試其應該做什么。單元測試說明實際上由一系列單元測試用例組成，每個測試用例應該包含4 個關鍵元素：
被測單元模塊初始狀態聲明，即測試用例的開始狀態（僅適用于被測單元維持了調用間狀態的情況）；
被測單元的輸入，包含由被測單元讀入的任何外部數據值；
該測試用例實際測試的代碼，用被測單元的功能和測試用例設計中使用的分析來說明，如：單元中哪一個決策條件被測試；
測試用例的期望輸出結果，測試用例的期望輸出結果總是應該在測試進行之前在測試說明中定義。
以下描述進行測試用例設計，書寫測試說明的7步通用過程。
2.1 測試用例設計步驟
2.1.1 步驟1：首先使被測單元運行
任何單元測試說明的第一個測試用例應該是以一種可能的簡單方法執行被測單元。看到被測單元第一個測試用例的運行成功可以增強人的自信心。如果不能正確執行，最好選擇一個盡可能簡單的輸入對被測單元進行測試/調試。
這個階段適合的技術有：
● 模塊設計導出的測試
● 對等區間劃分
2.1.2 步驟2：正面測試(Positive Testing)
正面測試的測試用例用于驗證被測單元能夠執行應該完成的工作。測試設計者應該查閱相關的設計說明；每個測試用例應該測試模塊設計說明中一項或多項陳述。如果涉及多個設計說明，最好使測試用例的序列對應一個模塊單元的主設計說明。
適合的技術：
● 設計說明導出的測試
● 對等區間劃分
● 狀態轉換測試
2.1.3 步驟3：負面測試(Negative Testing)
負面測試用于驗證軟件不執行其不應該完成的工作。這一步驟主要依賴于錯誤猜測，需要依靠測試設計者的經驗判斷可能出現問題的位置。
適合的技術有：
● 錯誤猜測
● 邊界值分析
● 內部邊界值測試
● 狀態轉換測試
2.1.4 步驟4：設計需求中其它測試特性用例設計
如果需要，應該針對性能、余量、安全需要、保密需求等設計測試用例。
在有安全保密需求的情況下，重視安全保密分析和驗證是方便的。針對安全保密問題的測試用例應該在測試說明中進行標注。同時應該加入更多的測試用例測試所有的保密和安全冒險問題。
適合的技術：設計說明導出的測試
2.1.5 步驟5：覆蓋率測試用例設計
應該或已有測試用例所達到的代碼覆蓋率。應該增加更多的測試用例到單元測試說明中以達到特定測試的覆蓋率目標。一旦覆蓋測試設計好，就可以構造測試過程和執行測試。覆蓋率測試一般要求語句覆蓋率和判斷覆蓋率。
適合的技術：
● 分支測試
● 條件測試
● 數據定義－使用測試
● 狀態轉換測試
2.1.6 步驟6：測試執行
使用上述5個步驟設計的測試說明在大多少情況下可以實現一個比較完整的單元測試。
到這一步，就可以使用測試說明構造實際的測試過程和用于執行測試的測試過程。該測試過程可能是特定測試工具的一個測試腳本。
測試過程的執行可以查出模塊單元的錯誤，然后進行修復和重新測試。在測試過程中的動態分析可以產生代碼覆蓋率測量值，以指示覆蓋目標已經達到。因此需要在測試設計說明中需要增加一個完善代碼覆蓋率的步驟。
2.1.7 步驟7：完善代碼覆蓋
由于模塊單元的設計文檔規范不一，測試設計中可能引入人為的錯誤，測試執行后，復雜的決策條件、循環和分支的覆蓋率目標可能并沒有達到，這時需要進行分析找出原因，導致一些重要執行路徑沒有被覆蓋的可能原因有：
不可行路徑或條件——應該標注測試說明證明該路徑或條件沒有測試的原因。
不可到達或冗余代碼——正確處理方法是刪除這種代碼。這種分析容易出錯，特別是使用防衛式程序設計技術（Defensive Programming Techniques）時，如有疑義，這些防衛性程序代碼就不要刪除。
測試用例不足——應該重新提煉測試用例，設計更多的測試用例添加到測試說明中以覆蓋沒有執行過的路徑
理想情況下，覆蓋完善階段應該在不閱讀實際代碼的情況下進行。然而，實際上，為達到覆蓋率目標，看一下實際代碼也是需要的。覆蓋完善步驟的重要程度相對小一些。最有效的測試來自于分析和說明，而不是來自于試驗，依賴覆蓋完善步驟補充一份不好的測試設計。
適合的技術：
● 分支測試
● 條件測試
● 設計定義——試驗測試
● 狀態轉換測試
2.2 用例設計的一般原則
注意到前面產生測試說明步驟可以用下面的方法完成：
通常應該避免依賴先前測試用例的輸出，測試用例的執行序列早期發現的錯誤可能導致其他的錯誤而減少測試執行時實際測試的代碼量；
測試用例設計過程中，包括作為試驗執行這些測試用例時，常常可以在軟件構建前就發現BUG。還有可能在測試設計階段比測試執行階段發現更多的BUG。
在整個單元測試設計中，主要的輸入應該是被測單元的設計文檔。在某些情況下，
需要將試驗實際代碼作為測試設計過程的輸入，測試設計者必須意識到不是在測試代碼本身。從代碼構建出來的測試說明只能證明代碼執行代碼完成的工作，而不是代碼應該完成的工作。
3、測試用例設計技術
廣義地分為兩類：
黑盒測試：使用單元接口和功能描述，不需了解被測單元的內部結構
白盒測試：使用被測單元內部如何工作的信息
灰盒測試：借助于源代碼和測試工具等手段，通過黑盒和白盒測試相結合的方法進行測試的技術。
測試設計最重要的因素是經驗和常識。測試設計者不應該讓某種測試技術阻礙經驗和常識的運用。
白盒測試用例設計：使用程序設計的控制結構導出測試用例。
采用白盒測試的目的主要是:保證一個模塊中的所有獨立路徑至少被執行一次；對所有的邏輯值均需要測試真、假兩個分支；在上下邊界及可操作范圍內運行所有循環；檢查內部數據結構以確保其有效性。
黑盒測試用例設計：使用詳細設計導出測試用例。
采用黑盒測試的目的主要是：檢查功能是否實現或遺漏；檢查人機界戶是否錯誤；數據結構或外部數據庫訪問錯誤；性能等其它特性要求是否滿足；初始化盒終止錯誤。
目前國內出版的軟件測試方面的書，深入講解編寫軟件測試用例方法的很少，而且大多數方法都是很理論的描述。另外，最大的問題是把測試用例的確定輸入數據的方法說成是測試用例的設計方法。
例如，關于測試用例設計方法，最常用的說法是：等價類，邊界值，因果圖等。實際上這些只是軟件測試用例設計中如何確定測試輸入數據，對于對話框中的數據控件輸入值有效。如果把確定輸入數據的方法，描述成測試用例的方法，那么，這樣設計出來的測使用例就很有局限性。
實際上，編寫測試用例包括兩個方面：第一是編寫測試用例輸入數據，第二是編寫測試用例實體（即包含測試目標，測試步驟，測試期望結果）。
為此，有必要把編寫測試用例的工作分解成兩個階段：第一階段稱為“測試用例設計”，第二階段稱為“測試用例實現”。第一階段的任務是如何確定測試用例的組織結構（模塊化、階段化），模塊化即把被測軟件分解成各個模塊，每個模塊組織成測試用例組。階段化即按照軟件開發的不同階段分別編寫軟件測試用例，例如單元測試用例、系統測試用例、驗收測試用例等。
編寫軟件測試用例的過程如圖所示。
如下觀點，只代表我個人觀點，如有偏差，還望各位同行提出相應觀點和意見。
如果網友看過我以前寫過的文章，就能理解我如是如何理解定義測試的。
誰是測試團隊中的核心技術人員
我個人認為對于公司測試團隊中最重要的人是設計優秀測試策略和設計優秀ROI（ROI：投入產出比）測試方案的測試工程師，當然自動化測試腳本開發工程師和測試工具開發者對于測試部也是非常重要和不可或缺的。
為什么我認為測試部最重要的人是測試策略和測試用例的設計者？
首先從相關人才的來源來分析：
自動化測試開發工程師：可以由只畢業3－4個月或才進入項目1－2個月的工程師就能從事。測試工具開發：甚至不需要對測試了解多少也能從事。而設計測試策略和好的測試方案設計者則需要至少2－3年的相關業務黑盒測試經驗的工程師，才有可能做好。
其次從相關人才發揮的作用分析：
測試策略的制定就好似公司的市場部要制定大的市場戰略。例如：這個測試方案的定位是什么？這輪測試的目的是什么？有多少資源可以進行測試？應集中資源先對哪些重要又緊急的功能進行測試？如何區分重要或緊急的功能？如何安排緊急而不重要的功能與重要而不緊急功能的測試順序？等等......
測試方案的設計：就好似公司的銷售部針對每個具體的客戶制定具體的銷售計劃和銷售方案。例如：對于這個case我們的目標期望是什么？如何達到這個目標？是否還有更好的方法來達到這個目標？如何利用現有的有限資源取得最大化的結果？這個case的ROI是否高效？而測試工具的開發和自動化測試腳本的開發則類似于公司中的研發部，提供必須的高效武器與公司市場部，銷售部一起攻城拔寨。
如何成為一個合格優秀的測試策略的設計者呢。我的觀點是：
1：一切測試策略的目的是什么？是為了滿足公司市場銷售策略。因此我們應該設法保證測試策略既能按期完成研發計劃，又能不影響銷售的產品質量。
2：將有限的資源先用到緊急又重要的測試任務中，再評估其他任務的優先級。但一定要以市場銷售計劃為依據。一個脫離市場銷售的測試策略是一個誤國誤民的策略。
3：測試策略不是測試計劃。我的看法是：以市場銷售計劃為依據，先制定測試策略，再按任務的優先級和資源情況來制定測試計劃。現在常有不少朋友誤認為測試計劃就是測試策略，測試策略就是schedule
時間表；計劃表；一覽表，這種觀點我個人并不認同。
4：測試策略不是一個人設計出來的。它一定是先聽取了市場人員的意見和要求，再結合研發的要求得出的一個平衡取舍的產物。
5：好的測試策略設計者是一個以公司利益為第一位，而不只局限在測試部門利益的員工。辦公事政治玩多了，設計的測試策略有可能就是一個對公司利益有害的策略。
6：一定要最大化的接近客戶的真實應用來定義重要的模塊功能，而不簡單依據模塊的復雜度來定義。
7：能知己知彼。對自己的測試資源有多少，要有準確清晰的認識才能知道量體裁衣。而不要打腫臉撐胖子，最后實施時，卻完成不了測試策略。
接下來，如何成為一個合格優秀的測試用例設計者。我的觀點是：
好的測試用例至少要滿足如下要求：（這里只討論功能測試用例的要求）
1：粒度一定要細，對功能需求中的每個小點，每個數據都要覆蓋到。并盡量多的想到更多的測試方法來對被測試項進行拷打。
2：測試方法不能過度測試。大家容易想到測試不充分對公司有害，但往往會忘記過度測試對公司也是有害的，這點在我的測試經歷中感受非常深刻。例如：因為你的過度測試，浪費了你的有效測試時間，這個時間原本是可以拿來發現更多真正有意義對銷售有影響的bug。因為你的過度測試發現的bug，開發人員有時必須為這些意義不大的bug花時間來修改，浪費了修改其他更有意義bug的時間，影響了項目的進度，影響了產品的銷售計劃。說不定公司甚至因為你的幾個過度測試，延遲了1個月推出產品，導致公司在這1個月中損失1億的訂單。而這些都是真正有可能發生的。所以，要避免在不漏測的前提，走向另一個極端－過度測試。
3：你的測試用例是否容易轉化為自動化測試。如果你在進行測試用例設計時，根本沒有把將來進行自動化測試的開發做為一個考慮因素。那么，你的測試用例永遠只能用手工進行回歸測試，將大大浪費公司的資源并影響產品發布時間。如果回歸測試的手工執行是你自己來做的話，那么以后你的苦日子可就長了。
4：測試用例應該考慮執行時資源和時間的安排。例如：千萬不要出現有的test case執行完一遍只需要1小時，有的test case執行完一遍卻需要20個小時。為了便于測試管理和計劃安排，應設法讓測試用例未來執行的時間保持在一個參考值左右。假設一個標準test case的執行時間為4小時，那么設計的test case應盡量保持在3－5小時內。這樣非常容易量化并管理測試用例執行者的工作，更有利于測試計劃的安排，測試策略的制定，研發計劃的按時執行。
5：理想狀態下，最好你的測試用例也要有好的易讀性。例如：test case的執行者拿到你的case后能在半小時或1個小時左右就能讀懂并執行。否則，如果執行者還需要4－5個小時才能讀懂或不能完全讀懂你的測試方法和測試步驟。那公司將會為這樣的測試用例付出非常大的成本代價，甚至會影響測試計劃的執行和產品的研發計劃。
總結：對于部分迷茫的測試工程師，如果你希望在測試領域發展而不是在代碼開發領域發展，就不要誤認為只有代碼才是高手，只有代碼才是好的測試工程師。要做一個對公司有最大價值的測試工程師，就應該盡量往成為一個好的測試策略設計者和測試用例設計者成長和發展，但這一切工作又很依賴一個很基礎的因素——工作的責任心，只有把公司的大局發展放入自己的心中，才能真正做好工作的取舍，設計出有價值的測試策略和測試用例。
新本本，新系統，還是得把武器給裝配好。
下面圖文記錄win7系統下的jdk的安裝和配置。
1、下載jdk
地址：http://java.sun.com/javase/downloads/index.jsp
作為開發者，下載JDK，點擊
；
選擇windows平臺，點擊下載
，需要登錄一下，就可以下載了。（沒有用戶名的，注冊下就行，免費的，而且以后經常用得到）。
2、安裝JDK
安裝很簡單了，和安裝其他軟件沒啥區別，路徑如果不需要自己特殊設置的話，就可以一路默認。需要知道安裝的路徑，配置的時候是需要用到的，安裝后
我這的安裝路徑是E:/Java/jdk1.6.0_20
3、環境變量的設置
win7界面相比xp做了一點小的修改，不過不影響操作
這里需要設置JAVA_HOME、CLASSPATH、Path三個環境變量。
a)、右擊“計算機”，點擊“屬性”
點擊彈出界面的左部分的“高級系統設置”
選擇“高級”選項卡，點擊下部的“環境變量”
在“系統變量”中，設置3屬性JAVA_HOME、CLASSPATH、Path（不區分大小寫）,若已存在則點擊“編輯”，不存在則點擊“新建”；
b)、JAVA_HOME指明JDK安裝路徑，就是剛才安裝時所選擇的路徑E:/Java/jdk1.6.0_20，此路徑下包括lib，bin，jre等文件夾（此變量最好設置，因為以后運行tomcat，eclipse等都需要依*此變量）；
c)、Path使得系統可以在任何路徑下識別java命令，這里，要注意下，path應該是本來就存在的，就不要新建了，找到path，點擊“編輯”；在值的最前面加上下面的語句即可。如果覆蓋了path變量，將導致的cmd下有些基本的命令會找不到。
%JAVA_HOME%/bin;%JAVA_HOME%/jre/bin;
d)、CLASSPATH為java加載類(class or lib)路徑，只有類在classpath中，java命令才能識別，設為：
.;%JAVA_HOME%/lib/dt.jar;%JAVA_HOME%/lib/tools.jar (要加.表示當前路徑)
%JAVA_HOME%就是引用前面指定的JAVA_HOME；
4、檢驗安裝配置是否正確
點擊“開始”，鍵入“cmd”；
，enter
運行“java -version”、“java”、“javac”三個命令，看輸出是否類似上圖。。出現畫面，安裝配置ok了。
下面就可以開始java之旅。
學習交流>^<歡迎拍磚
Win7下配置Tomcat
Tomcat=C:\tomcat
配置好之后，進入Tomcat文件夾，雙擊C:\tomcat\bin\startup.bat，運行Tomcat，然后，打開IE，鍵入：http://127.0.0.1:8080/
如果出現：
則此時，Win7下配置Tomcat配置成功。
看了幾篇關于用例級別如何設定的文章， 總結總結吧。
根據二八原則或者稱數據統計，前20%的用例可以發現80%的重要BUG。
當設計測試用例時，分配優先級非常不容易，且這個優先級也不是固定不變的。
一般，我們會假設發現的bug的嚴重程度和bug對應的測試用例的優先級是平行的。
1、最高（又稱Build Verification tests）也叫冒煙測試用例，一組你運行以確定這個build版本是否可測的測試用例。
2、高：這種用例運行，能發現重要的錯誤，或者它能夠保證軟件的功能是穩定的。俗稱大的基本功能的測試用例
3、中：檢查功能的一些細節，包括邊界，配置測試
4、低：較少執行的測試用例，并不代表它不重要，而是說不是經常被運行。例如壓力測試錯誤信息等。
用例級別設置的流程：
1、如果沒有很多的時間來確定優先級，那么可以先大致的進行劃分：
把所有功能性驗證的用例標注為高
把邊界值或錯誤能力的用例標注為中
把非功能性和易用性的標注為低
2、提升和降級
針對1描述的所有高級別的功能性用例劃分為重要和不十分重要兩種，然后重要的保持高，不十分重要的降級為中。同理，對應中級別的用例，重要的進行升級，不十分重要的保持中。對應低級別的，重要的升級，不十分重要的保持。
3、確定BVTs
BVT (Build Verification Test)
BVT是在所有開發工程師都已經檢入自己的代碼，項目組編譯生成當天的版本之后進行，主要目的是驗證最新生成的軟件版本在功能上是否完整，主要的軟件特 性是否正確。如無大的問題，就可以進行相應的功能測試。BVT優點是時間短，驗證了軟件的基本功能。缺點是該種測試的覆蓋率很低。因為運行時間短，不可能 把所有的情況都測試到。
將高優先級的用例劃分為嚴重和重要， 嚴重的將升級為bvts
經過這個流程后，大致會控制bvt10% 高為25% 中55% 低10%
具體還要結合具體的項目和質量目標確定。
倘若從文檔的角度，用例的級別首先要繼承需求點的優先級級別，整理的測試需求進行優先級定義，然后對需求對應的測試用例進行優先級定義；
因為在根據客戶需求和產品需求說明書提取測試需求時，在所有的需求中，有客戶急需使用的部分，有客戶頻繁使用的部分，有系統絕對不能出現錯誤的部分，這些都是高級別的需求點。
所以要考慮四點：
1、測試需求的級別
2、測試用例導致的錯誤的級別
3、測試用例對應的場景使用的概率（頻率）
4、測試用例發現問題的概率
所以在實際測試中，若用例發現的bug頻率很高，我們就應該適當地調節它的級別。
又比如一個定義級別很高的用例，發現在實際測試中出現錯誤的觸發條件是否罕見，所以就適當降低，或者客戶需求產生了變化，對某個需求要求很低了，所以也適當降低。
因此，
1、建議將涉及到業務流程的用例，整理到一個專區，定義為P4
2、每一個需求的主測試用例定義為P4
3、每一個需求的輔助測試用例定義為P4或P3
4、級別為高的需求點的完善性測試用例，建議性 易用性等，定義為P3 P2
5、級別非高的需求點的主測試用例為P3 或P2
6、級別非高的需求點的輔助用例完善用例 建議用例易用性用例為P2 P1
測試工程師有一樣很重要的工作就編寫測試用例。 測試用例是對需求的另一種描述，它能引導大家進一步加深對系統的理解和對特性的全面關注，從而幫助產品和開發重新審核需求的合理性和一致性，所以應該是測 試工程師最重要的一項產出。一般的測試用例分為輸入，行為，和期望結果三個部分。這三個部分通常的測試用例都能滿足，但是怎樣的測試用例才能算上優秀的測 試用例呢？基于以往之測試經驗，我總結了優秀測試用例的幾個特點。
1、正確性：毫無疑問，測試用例 必須是需求的正確描述。但是我們往往忘記了多想一步：這是用戶正確需要的嗎？我曾經有個一個失敗的testcase，當一個條件輸入異常的時候系統返回 -1給前端接口，然后前端返回錯誤信息，這是當時對異常的處理需求，可是如果多想一步，當一個條件異常的時候難道我們不能返回滿足部分條件的結果給用戶 嗎？讓用戶的體驗更加良好嗎？
2、完整性：就測試用例本身而言，是無窮盡的，只要是鍵盤的任意組合都可以算作測試用例。而一個優秀的測試工程師就是從無窮中找到最能保證質量，最能發現bug的測試用例出來，發現無窮的最小集，通常功能測試用 例的找尋方法有等價類和邊界值是最簡單的方法，建議結合使用，先劃分等價類，再把等價類中的邊界值找出來。我見過很多在=和>=之間徘徊的bug。 正交法出來的用例一般太多，所以需要測試工程師在正交法的結果中再做組合，建議結合錯誤定位法減少用例的執行。狀態圖在數據統計，結算中的使用概率最高。 每個狀態和流程都需要一一考慮正常和異常的分支，正常的流程一個靠譜的開發能自己保證，但是異常的分支很少有開發考慮清楚，這就是體現測試工程師價值的地 方了。但是完整性絕不僅僅是功能測試，除了功能測試之外，常見的還有性能測試，安全測試，兼容性測試，安裝友好測試，地域語言測試和用戶體驗測試（usability）。
3、輸入具體：對于這三個部分我們都希望它是固定的，具體的，比如輸入框的輸入，我們可以寫成具體“諾基亞”，但是不要寫“正確的輸入”，或者“中文的輸入”，這些都會導致測試用例的不確定性。模糊的輸入應該在具體輸入的上一級結構，作為測試的思路和分類使用。
4、用詞無歧義：很多詞在不同場景會有不同的含義，比如價格一詞在不同的表中就代表不同的價格，甚至在同一表中也有原始價格和賣出價格，所以應該盡量具體的描述關鍵詞的具體信息，如果能貼上專用的id和原始表中的item會對避免歧義有很大的幫助。
5、用例細化：輸入的一種組合，或者一條流程線對應一個測試用例，盡量不要在一個用例中融和多種情況，在自動化測試的腳本中為了提高效率我們會在一個自動化腳本中融入各種情況的輸入，然后一個動作，所有的輸出一次生成，針對這種情況，建議在腳本中對各種輸入對應的案例一一備注說明，運行失敗的時候也方便新人定位問題。
6、判斷點準確無歧義：我經常看到這樣的檢查點：“結果正確”，“速度合理”，這些檢查點對其他人沒有絲毫的幫助。所以應該盡量做出讓機器也能識別的檢查點，比如輸出“8”，或者“rt<30m”。
7、合理區分優先級：在Bugfree中有4個級別的優先級，從1到4，1表示最重要的測試用例，4表示最不重要的測試用例。不同的缺陷管理平臺對優先級的定義會有不同，但是都會有優先級的概念。在時間緊張的情況下，優先級的作用會特別大，我們會優先執行比較重要，對系統功能，用戶體驗影響大的測試用例，將級別比較低的測試用例留在后期或者指派給一些新人來執行。
加分點：
1、用例自動化：有自動化腳本的地址能夠一一對應，對于淘寶的bugfree就已經和自動化框架mmt打通，通過測試用例可以直接鏈接到腳本，方便對用例的理解。
2、記錄每輪的測試結果：對于有些功能的測試用例，結果只是簡單的pass我們不需要記錄，但是對于性能測試這些結果不確定的測試用例，如果能保留每次測試的結果對于之后的測試是很有幫助的。對于fail的部分用例，如果能和bug產生一一對應關系對之后的回歸也產生很大的便利。
3、對檢查點進行邏輯說明：很多用例有了結果的檢查點，但是為什么是這個結果，對于新人來說必須重新翻看需求或者設計文檔才能理解。尤其對于算法的測試，理解需求和邏輯是一個比較痛苦的過程，如果能夠對每個結果進行一些備注和邏輯上的說明，會和方便自己今后以及新人對用例的理解。
以上是對測試用例特性的一些總結，真正編寫測試用例的時候，mm圖由上到下的樹形結構會對測試用例的結構和思路提供很大的幫助，在測試用例評審的時候也 方便展示和說明，所以強烈推薦作為附件上傳。而且對系統越加深入的了解越能寫出完善的測試用例，很多開發錯誤的理解測試工程師只需要知道需求就可以了，不 需要對程序有代碼級別的了解，但是無數的實踐證明測試工程師越了解系統的設計，編碼的邏輯越能發現潛在的bug和風險。Unit test通 常由開發完成比較高效，但是Integration Test開始就必須有測試工程師開始真正介入，這期間能發現很多潛在的問題，如果把風險全部留到System Test的階段風險是很大的，大量case的回歸和問題的定位都會變得更加復雜，成本更加的巨大。所以在時間允許的情況下毫無疑問是前期的測試越完善整體 效率越高。