測試用例
測試用例的重要性是毋庸置疑的，它是軟件測試全部過程的核心，是測試執行環節的基本依據。
生產管理系統中的功能測試用例直接使用需求規格說明書和軟件功能點及對每個功能點進行操作上的細化、生產管理系統界面原型圖，對工作流的測試用例還包含流程圖和權限配置信息。
壓力測試用例的選擇可在實施現場定義，使用LoadRunner等測試工具在現場錄製測試腳本，選擇用例時應該消除客戶端執行腳本的影響因素。
性能測試用例主要選擇那些交互多、數據量大的功能，比如圖形交互操作，記錄自動生成等。
測試分類
系統測試應該由若干個不同測試組成，目的是充分運行系統，驗證系統各部件是否都能正常工作並完成所賦予的任務。測試分爲以下幾類。
1. 功能測試
功能測試用來測試系統的單個功能，這裏的功能定義爲當用戶在界面上點擊功能菜單的某一菜單項時，系統給出的交互界面所包含的一組操作的集合。最簡單的單一功能表現爲一個瀏覽器編輯表單。
功能測試的測試用例可以使用生產管理系統界面原型圖，再結合檢查對應的數據庫記錄的方式。
功能測試測試是爲了保證系統提供的單個功能項的正確性，比如一次設備臺帳登記。在此基礎上在聯合其他相關的功能進行組合測試。
2. 組合功能測試（集成測試）
單一功能測試只能保證最小範圍內的基本功能的正確性，而不能保證當這些基本功能聯合在一起實現一個完整應用是的正確性。組合功能測試就是建立在單一功能測試的基礎上，測試邏輯相關的一組單一功能組成一個完整應用的實際效果。
聯合功能測試的測試用例由數據模型的關聯關係、相關的流程圖、生產管理系統界面原型圖組成，對於工作流的測試，必須同時測試操作權限。
3. 壓力測試
壓力測試是指模擬巨大的工作負荷以查看應用程序在峯值使用情況下如何執行操作。壓力測試應該是較短時間的、模擬巨大的工作負荷的、使應用程序的使用達到峯值的測試。壓力測試是用來測試應用服務器併發能力的測試。
測試時使應用程序的使用達到峯值，如果超過這個界限則應用程序會崩潰或錯誤率激增，這個峯值是針對某一時刻來說的，也是針對某個臨界的壓力來說的，轉變爲場景設置中的說法就是能夠支持的最大併發用戶數。
壓力測試需要在特定的硬件環境下進行，系統安裝後，使用LoadRunner等測試工具。
4. 性能測試
對有些數據量大，操作複雜的功能，軟件部分即使滿足功能要求，也未必能夠滿足性能要求，雖然從單元測試起，每一測試步驟都包含性能測試，但只有當系統真正集成之後，在真實環境中才能全面、可靠地測試運行性能。系統性能測試是爲了完成這一任務。性能測試有時與壓力測試相結合，經常需要其他軟硬件的配套支持。
測試結論和bug管理
1) 測試結論
測試結論要客觀，用數據說話，儘量不要添加個人主管臆測，不帶個人感覺或感情色彩，從多種角度考慮。
2) 使用bug管理系統或bug工具管理bug
爲了使bug的管理系統化和規範化，便於查閱和更新，採用BugFree等專門管理Bug的工具來管理bug。
3) 確定bug的等級
按照CMM5中定義的規範，BUG一般分致命、嚴重、一般和提示。致命是嚴重影響產品的BUG，比如操作手冊的錯誤，需求的錯誤等。嚴重是產品中使功能無法實現的BUG，比如某個功能無法運行，GUI長時間僵死沒有響應。一般是某個BUG的發生，隻影響了一個功能，而其他功能可以正常運行。提示就是一些 GUI的問題，或者友好性的問題。
將bug劃分爲不同的等級後，對致命和嚴重的bug需要立即處理，對一般和提示bug再細分爲不同的優先級，按優先級的順序分別進行處理。
4) bug編寫技巧
爲了提交準確簡潔的、徹底校訂的、精心構思的、高質量的技術文檔，請參考以下的技巧：
組織Structure：測試人員應該採用深思熟慮的，小心謹慎的方法執行測試，並且做詳盡的記錄。這樣可以促使他們對測試下的系統有很好的認識。當錯誤發生的時候，一個有組織的測試人員能夠知道最早出現問題的地方。
重現Reproduce：測試人員在編寫bug report之前必須在檢查問題是否可重現。如果錯誤不可再重現，仍然應該寫下來，但是必須說明問題的偶然性。一個好的處理原則就是在編寫bug report之前反覆嘗試3次。
隔離Isolate：在嘗試編寫bug report之前，必須試着隔離錯誤。可以採用改變一些變量的方法，如系統的配置，它可能可以改變錯誤的症狀。這些信息可以爲開發人員着手調試提供思路。
歸納Generalize：在測試人員發現了一個已隔離的，可重現的問題後，應該對問題進行歸納。同一個問題是否出現在其他的模塊或其他的地方？同一個故障是否有更加嚴重的問題？
對比Compare： 如果測試人員以前曾經驗證過現在出錯的測試用例，那麼他就應該檢查以前的測試結果以檢查相同的條件是否通過以前的測試。如果是的話，那麼這個問題就象是一個迴歸的錯誤。注意由於同一測試條件有可能出現在多個測試用例中，這個步驟就不僅僅只是檢查一個測試用例在以前的多個結果。
總結Summarize：在bug report的第一行寫上錯誤的總結是非常關鍵的。測試人員要花些時間思考已發現的錯誤對客戶有何影響。這不僅僅要求測試人員編寫的報告要能夠吸引讀者，使和管理層的溝通清晰，還要能夠幫助設置錯誤修復的優先級別。
精簡Condense：在bug report的初稿完成後，測試人員應該反覆閱讀它，集中剔除那些沒有關係的步驟或詞語。隱含的或模糊的說明和那些由於對沒有任何關係的細節或者那些在重現錯誤過程中不需要的步驟而消磨報告歡迎程度的無窮嘮叨都不是bug report的目標。
消除歧義Disambiguate：測試人員在精簡空話的同時或其之後隨即應該再仔細檢查報告是否有會產生誤解的地方。測試人員應該儘量避免使用模糊的，會產生歧義的和主觀的詞語。目標是使用能夠表述事實，清楚的，不會產生爭執的詞語。
中立Neutralize：作爲壞消息的傳遞人，和善地提交消息是一個挑戰。如同所有的錯誤總結一樣，獨立的bug report在措辭方面應該保持公正。攻擊開發人員，指責潛在的錯誤，企圖詼諧或使用挖苦將引起開發人員的憎惡，並且使注意力從“提高產品質量”這個大的目標上轉移開了。謹慎的測試人員只用Bug report來描述事實。
檢查Review：一旦測試人員感覺bug report是他能夠編寫的最好版本，他應該將報告再給一個或多個同行進行檢查。他的同事們也應該給出一些建議，爲了澄清問題不斷地提問，如果適當的話，甚至可以挑戰“錯誤成災”的結論。在允許的時間裏，測試小組應該儘可能提交最好的bug report。
一個Bug有7種解法：
By Design - 就是這麼設計的，無效的Bug
Duplicate - 這個問題別人已經發現了，重複的Bug
External - 是個外部因素(比如瀏覽器、操作系統、其他第3方軟件)造成的問題
Fixed - 問題被修理掉了。Tester要儘可能找到這種Bug
Not Repro - 無法復現你這個問題，無效的Bug
Postponed - 是個問題，但是目前不必修理了，推遲到以後再解
Won't Fix - 是個問題，但是不值得修理了，不管它吧
