軟件測試建設原則，是一個永遠說不完的話題，後續會以一個體系的形式更新。 ---Tynam 2021/01/08
軟件測試行業經過快速的發展，至今已經沉澱了許多門類，各式的應用。如果要研發一款產品，那麼測試是一項必不可少的工作。從最初的功能測試、到現在的自動化測試、性能測試、安全測試，以及近兩年萌芽的大數據測試、機器測試，發展迅速，不同的團隊應用的也各盡百色，其中的文檔、人員管理方式方法也姿態萬千。那麼對於不同項目，不同管理的測試安排其中肯定是有必然的聯繫，遵循着某種原則，這種必然聯繫到底是什麼呢，起止現在也沒有一個人真正闡述過。在此，筆者暫且稱之爲 “whyTest”。何謂 “whyTest”，根據名稱不難發現是爲什麼要這樣進行測試。簡單的對 “whyTest” 做以下幾點解釋：
- 目的：這樣進行測試的目的是什麼，遇到了什麼問題。
- 解決方案：使用怎麼的方案進行解決。
- 適用場景：在什麼情況下適用。
- 實現方式：以什麼樣的方式，藉助什麼工具來實現。
- 優缺點：這樣的實現方式有什麼好處，會帶來那麼影響。
- 注意事項：需要注意那些內容，是否有依賴存在。
在上面的幾條解釋中，不難發現，工程量最大的是在實現方式上，對於實現方式就需要講究一些行爲原則，核心是以最小的成本解決，那麼就需要考慮建設、複用、維護等方面的內容。因此在提出解決方案時就需要考慮實現後的獨立、拓展、依賴、複用、繼承。在此將之稱爲”測試建設原則“。
- 獨立：指進行的每一項工作看起來都是獨立存在的，每一項工作中的細節也都是獨立的。例如測試計劃，就是單純的工作安排，不會涉及具體的實現方案。
- 拓展：易於拓展，擴充。擴充的內容又必須和舊有的內容之前存在弱依賴或零依賴，對原有的或者後來的不造成影響，擁有自己獨立的位置。
- 依賴：弱依賴或零依賴可以使每一項內容都可以獨立展開。例如在執行測試用例時候的發現一個Bug，此bug需要和測試用例進行關聯，這兩者之間便產生了依賴關係。
- 複用：既有每項工作內部的複用，又有每項工作與每項工作之間的複用。
- 繼承：繼承指實現某項工作時先構思出抽象的結構，例如些測試用例，先約定測試用例使用什麼工具、有那些組成部分，在實現時必須遵守這些約定，由此生成的測試用例纔會整體劃一，便於閱讀。
爲了便於管理，工作充分開展，把控，可以將測試工作分爲橫向、縱向進行，如下圖。橫向表示測試流程，根據時間進行安排。縱向表示橫向中每一項具體工作的落實。給定具體任務、固定時間，不要強制怎麼實現，最終達到預期結果即可。要充分調動測試人員的積極性，允許在有限的範圍內進行自由發揮，每一位測試人員做自己擅長的事情。那麼關於有限的範圍，這個範圍該怎麼界定呢？
其實很簡單，就是用戶需求。筆者一直提倡，測試人員不是一個測試機器，是具有智慧的，具有思考的測試人員，測試人員做的工作不只是按照產品經理的要求來執行，更多的是考慮用戶是怎麼想的、怎麼使用的。有經驗的測試人員都會有這麼一個認識，測試計劃參照需求分析進行，設計方案參照測試計劃，測試設計參照測試方案，測試執行參照測試設計，測試評估參照需求分析、計劃、設計、執行。可以看到這樣的流程是下一個階段必然依賴上一個階段的工作，並且依賴的程度還比較深，假如有一個環節出錯，那麼後續的工作都會有問題。那麼我們返回最初的目的，需要做什麼，來源自什麼地方？毫無疑問，是用戶需求。所以具有思想的測試人員不單是按照產品經理的要求去執行工作，更需要理解用戶的需求。因此，測試人員應該是以用戶爲導向，需求爲基礎，開展測試工作，建立測試模型。
由此， 我們就需要對用戶的需求的進行分解 ，請注意，在這所說的用戶需求是用戶最初的要求，想法，而不是產品經理提取出來的。因爲產品經理提取出來的需求已經賦予了它一定的第三方想法，甚至參雜了設計方案。回到文章最初所說的WhyTest，將用戶的需求進行分解。
我們可以將用戶需求進行分解成解決的問題、在什麼場景中適用、怎麼解決、擁有什麼優缺點。在測試中每一階段的實現都依賴於需求，不依賴上一階段的產出。由此各階段的產物均是獨立的，下一個階段的實施參考上一階段的產出，但絕對不能是依賴，唯一依賴的是原始需求。意思是上一階段的產物修改後對下一階段的內容沒有影響，除非需求變更纔會影響內容的變更。
簡單的舉個示例,計劃階段最主要的產出的計劃說明書，計劃說明書一般包含的內容有：項目概述、項目的組織形式、測試對象、測試通過和失敗的標準、掛起和恢復的標準、測試任務安排、工作量、資源明細。使用 whyTest 對計劃階段進行說明：
- 目的：從宏觀上規劃測試活動的範圍、方法和資源配置。
- 解決方案：用文字描述、表格等樣式對項目測試進行宏觀說明。
- 適用場景：開發新需求時使用。
- 實現方式：使用 word工具實現。
- 優點：word 中編寫方便，樣式（文字、表格、圖片等）可多樣展示。
- 缺點：無版本追蹤，團隊成員不能同時編輯，成員拿到的版本不能確保是最新的版本。
- 注意事項：無。
參照測試建設原則對各項內容進行分析：
- 獨立原則：計劃中的各項內容（項目概述、項目的組織形式、測試對象、測試通過和失敗的標準、掛起和恢復的標準、測試任務安排、工作量、資源明細）互不干擾，獨立存在。
- 拓展原則：易於擴展，例如添加測試類型（功能測試、性能測試、API測試），則對其他的內容沒有任何影響，只需要在內容中再添加一項測試類型。
- 依賴原則：計劃說明書中的內容互相依賴性低，甚至零依賴。但也存在強依賴，例如測試對象強依賴需求，項目的組織形式強依賴公司項目的組織架構，要知道，擁有強依賴的，一般都是不會變動的。
- 繼承原則：先定義好測試計劃書的實現內容，例如本次需要實現項目概述、項目的組織形式、測試對象、測試通過和失敗的標準、掛起和恢復的標準、測試任務安排、工作量、資源明細的內容。那麼以後每次需求開發，都需要實現這些內容。在此可以簡單的理解爲模板。
總結
在測試階段中，每一階段的實現都可以根據 “whyTest” 進行，目的、解決方案、實現方式、優缺點、注意事項。每一階段中的內容實現，都可根據測試建設原則進行實施。測試建設原則是獨立原則、依賴原則、複用原則、繼承原則。實現過程中可以參考上一階段的產物，但是不能依賴。如果需要依賴，依賴對象應該是不容易變更的對象。
文章最初發布在測試窩：測試建設原則 (testwo.com)