在測試任何應用之前應該瞭解的20個軟件測試小竅門
寫這篇文章我希望所有的測試人員都能閱讀這些軟件測試良好的實用內容，仔細閱讀所有條目並嘗試將他們運用到每天的測試工作中。如果不能理解某個條目，可以到我們論壇裏留言詢問更多的解釋。當然你也可以通過親身經歷學習到所有這些測試的實用內容，但爲什麼不在犯錯之前就來學習這些呢？ 以下就是我在經歷中學到的最好的一些測試實用技巧：
1）學會徹底的分析測試結果。不要忽視了測試結果，最終的測試結果或許是“pass”或“fail”，但診斷導致“fail”的原因會引導你發現這個問題的解決方案。一個不僅僅記錄了bugs而且提供瞭解決方案的測試人員是難能可貴的。
2）學會在每次測試任何應用時將測試覆蓋最大化。雖然100%的覆蓋或許是不可能的但你應該試着去接近它。
3）爲保證最大化的測試覆蓋需要將應用分割成更小的功能模塊。在這樣的單元模塊上編寫用例，如果可能的話講這些模塊分割成更小的部分。 舉個例子：我們假設你將你的網站應用分割成了許多模塊，“接收用戶信息”是其中之一。你可以將用戶信息填寫頁面分割成更小的部分來編寫測試用例：比如叫界面測試、安全測試、用戶表單的功能測試等等。在輸入框裏測試所有的字符類型、字符長度、無效性測試和有效性測試。寫出所有這樣的測試用例以增大測試覆蓋率。
4）當寫用例的時候，首先要考慮怎麼實現目標功能也就是尋找需求上的有效條件，然後再爲無效條件編寫用例。這樣就能覆蓋在應用測試過程中出現的常規和非常規操作。
5）積極思考。要抱着找缺陷的目的去測試，不能一開始就想着應用中沒有任何問題。如果你測試的目的就是在找缺陷你就會很自然的發現一些微妙的缺陷。
6）在需求分析和設計階段編寫用例，這樣你就能保證所有的需求都是可以進行測試的。
7）讓開發在編碼之前就能看到你的用例。不要想着等程序發佈時測試可以去提報很多缺陷而讓你的用例一直在你自己手裏。要讓開發完整的分析你的用例去開發有質量的程序。這樣就能節省返工的時間。
8）如果可能話要明確和組織你用來做迴歸測試的用例，這會保障手工迴歸測試能夠快速有效的進行。
9）對臨界應答時間有要求的應用需要對其進行完全地性能測試。性能測試是許多應用測試的重要組成部分。由於缺乏測試所需的大量數據，性能測試在人工測試中多半會被測試人員忽略掉，所以需要找到測試應用性能方法。如果不能手工添加測試數據，最好寫一些基本的腳本來添加性能測試所需的數據，或讓開發人員幫你寫出來。
10）程序員不應測試他們自己的代碼。像我們之前討論過的，開發人員應該對應用做了充分的基本的單元測試後才能給測試人員發佈應用新版本。測試人員不能爲了進行測試去催促開發人員快點發布新版。要讓他們支配好自己的時間。從領導到項目經理都會知道模塊什麼時候發佈以及能夠預估處相應的測試時間。這是敏捷項目的一個典型情形。
11）進行超出需求範圍的測試。對應用進行超出需求要求的測試。
12）做迴歸測試時要運用之前的缺陷概覽圖（缺陷概覽圖---不同模塊缺陷發現數目與時間的關係圖）。這種明瞭的圖表可以很好的預測應用哪些部分最容易出問題。
13）記錄下測試過程遇到的術語和概念。在測試應用時也一直開着一個文檔，在裏面記錄測試進度和測試狀況。在準備最後的測試報告時就可以利用文檔裏記錄的這些內容。這個好習慣會能幫助你提供完整明瞭的測試報告和應用發佈細節。
14）測試人員或開發人員會對應用代碼進行多次修改來適應測試。這是開發或測試過程中必要的一步來避免事務有效執行，比如在銀行項目中。要記錄下來爲適應測試而修改了代碼的地方，並且在最終發佈的時候確保已經將這些修改的地方從最終客戶端的源文件裏都改正了。
15）讓開發人員遠離測試環境。這是在發佈或部署文件中檢查配置修改是否遺漏的必要步驟。有時開發人員做了一些系統或應用的配置修改，但是卻忘了部署。如果開發人員沒有權限訪問測試環境，他們就不會不小心修改了測試環境，而且那些遺漏的地方可以在相應的地方找到。
16）讓測試人員在軟件需求分析和設計階段參與進來是很有用的。這樣測試人員可以對軟件有可靠的認識來保障較好的測試覆蓋率。如果沒有讓你參與這個研發週期，你要請求你的領導或經理允許你的測試團隊參與所有的決策議程。
17）測試團隊應該與其他團隊及他們所在組織機構分享最佳測試實踐、經驗。
18）增加與開發人員的交流來知道更多關於產品的知識。只要有可能就進行面對面溝通來迅速解決問題和避免誤解。並且把你對需求的理解或解決了某些問題，確保同樣也通過書面形式如電子郵件進行溝通。不要任何事都靠語言交流。
19）不要把時間全放在高優先級的任務上。分析所有任務相關的風險，把你的測試任務按優先級先後排好然後做出相應的計劃。
20）編寫清晰、描述性強、明瞭的缺陷報告。不要只提供缺陷現象，也要提供缺陷帶來的影響以及所有可能的解決方法。
不要忘了測試是一份有創造性和挑戰性的工作。它最終取決於你的技能和經驗，你會如何應對這個挑戰。
