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