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