簡單的說，測試
策略的意思就是說「你如何測試目標產品或應用程式？」。你要在測試策略中很明確的提出你進行測試時所使用的方法和步驟。
我看到過很多公司嚴格地按照一些測試策略模板來寫。但是，其實不用模板，你也可以並且更高效地寫測試策略。下面是一些簡單的寫測試策略的技巧，
1）在測試策略中要包括產品的背景資訊。在測試策略文件的第一段回答- stakeholder（專案利益相關者）為什麼要開發這個產品？回答這個問題會幫助你更好更快地理解專案，並為所做的事情優先順序排序。
2）測試環境，它應該包括你在那個作業系統
平台上做測試，系統是基於那些補丁和安全更新。例如，乙個測試環境可能必須包含window xp sp2
3）列出你將要測試的所有重要特徵。如果你認為有些特徵不屬於本次發布的一部分，那麼就標註「不會被測試的特徵」。
4）寫下在此專案測試中將應用到的測試方法。清楚的列出你將以那些型別的測試作為測試引導。例如：功能測試
，使用者互動介面測試，整合測試，壓力測試
，安全測試
等等。
5）回答以下問題：你如何進行功能測試？手動還是自動化？測試工具是什麼？你將執行在測試管理
工具中的所有測試用例嗎？
6）用什麼作為測試錯誤報告跟蹤工具？當測試人員發現乙個新的bug之後，流程應該是什麼？
7）測試進入和結束的標準分別是什麼？
8）如何去跟蹤測試進度？什麼度量可以用來記錄測試結束？
9）任務分布 – 定義每個組員的角色和職責，包括測試組長，測試員，專案經理等。測試戰略將由開發人員review，確保測試的覆蓋率全面且沒有重疊處。測試經理和部門經理都要同意測試策略之後，測試工作
才能展開。測試小組的劃分及分工。
10）有哪些風險會阻礙測試的完成？例如，**的依賴性，測試工具的侷限性等等。要提前想到風險發生的解決辦法。
11）測試日程表- 每個測試計畫都應該包含乙個預估時間來估計完成測試所需要的時間。這需要幾個階段：一，測試人員必須至少完成一次的執行全部用例。二，如果乙個錯誤被測試 人員發現，開發人員將修復此錯誤。測試員重新測試此用例，直到其功能正確為止。最後，但很重要的一點是測試員必須對修改過的地方執行回歸測試以保證開發人 員在修復乙個錯誤的時候沒有引入另外的**錯誤。測試日程表要包含每個測試部分涉及的測試人員。時間往往很難估計，因為測試中有很多不確定性的事情發生。 其中乙個比較好的辦法是參照前乙個發布來估計。
12）回歸測試的方法- 乙個錯誤被修復後，必須要保證產品功能按用例標準執行。回歸測試是為了在修復乙個問題時不引入另外的錯誤。因此相關的測試用例要在被執行一次，從而確保沒有特殊的東西被引進。在這個階段，就要定義回歸測試的方法。有的公司講相關模組的單元測試
用例全部遍歷一遍，從而確保產品的質量。
弄清楚這些問題，你就可以寫乙個詳細的測試策略出來了。
專題 如何寫測試 HBase
最近做spark streaming任務時用到了hbase做中間狀態查詢和儲存，順手寫了一些測試，小小總結了一下各部分測試的寫法。話說這裡為什麼不用redis呢？redis作為kv儲存系統還是太簡單了，hbase可以讓你少操很多很多心，這裡就不跑題了。2.csdn上的翻譯 使用常用工具測試hbase...
如何寫測試用例
1 了解軟體的原始需求 測試目的 在編寫乙個軟體或者模組的測試用例時候，一定要明白這個功能的原始需求，也就是軟體的使用者 客戶 的需求。理解原始需求後，編寫的測試用例才更有目的性。2 熟悉軟體的功能需求 測試點 這個功能需求是指軟體的細化需求點，這個一般在需求文件裡面都會體現。這裡要做的是把需求穩定...
測試計畫應如何寫
良好的測試計畫應包括 1 目標。必須定義每個測試階段的目標 2 結束準則。必須制定準則以規定每個階段何時可以結束。3 進度。每個階段都須有時間表。應支出何時設計 編寫和執行測試用例。4 責任。對於每乙個階段，應該確定誰來設計 編寫和驗證測試用例，誰來修改發現的軟體錯誤。5 測試用例庫及標準。在大型專...