這是軟件工程系列的第六篇文章，我想從軟件工程的角度來談談關於軟件測試的一些話題。
軟件工程的核心
軟件工程簡單來說就是多人蔘與、有計劃有步驟的構造一個符合質量標準的軟件產品的過程。參與人越多、產品越複雜、流程越繁瑣，最終構造的軟件產品就越可能出現問題。
軟件工程出現的初衷，就是爲了擺脫軟件質量危機，其核心內容是要用工程化的方法去規範軟件開發，讓軟件開發項目可以按時保質完成的同時且成本可控。
抽象歸納可以稱之爲一個核心三個方法，即：以軟件開發爲核心，對開發過程組織+對方法的運用+對工具的使用。
以工程方法，解決複雜性下軟件質量的不可控，所以質量是其最核心的部分。
軟件測試的本質
記得剛開始從事軟件測試工作時，那個時候測試的崗位很多企業的定位是QC，就是質量檢測和控制。
從軟件測試工程師的日常工作來說，絕大多數時間都是在分析需求寫case、發現bug、跟進bug解決和驗證。
近幾年的軟件測試崗位，開始逐漸變爲了QA，即質量保障。
看似只是一個名詞的變化，其實背後對應的是企業對軟件測試這個崗位有了更多的要求和期望。
當然也有同學會自嘲自己是點工、PageClienter等，面試造火箭入職擰螺絲的背後也存在很多無奈。
無論行業如何變化，軟件測試的本質還是和軟件質量息息相關的。
前面的文章聊過，質量保障需要“風險可識別+問題可追蹤+結果可驗證+數據可量化”，才能最大限度的實現其價值。
CKL老師也提到過“業務可驗收、研發可實現、測試可驗證、部署可交付”等類似理念，本質是在描述如何評估軟件質量。
那麼，質量保障應該如何理解？我們可以從軟件質量保障和交付生命週期的三個階段來做不同的定義。
需求設計質量
我們談軟件質量，不可避免要從它的源頭說起，而源頭就是需求和設計階段要做的事情。
這個階段包括原型圖、PRD文檔、交互設計、技術方案、測試用例等幾項重要產出物，當然他們有一定的前後依賴關係。
在需求設計階段，我個人認爲比較重要的有如下幾點：
- 需求評審（是否有遺漏、描述不清、存在邏輯漏洞等）；
- 設計評審（設計是否滿足需求要求、是否合理美觀友好）；
- 方案評審（方案實現難易程度、可測性、是否需要更多資源）；
- 用例評審（場景是否儘可能覆蓋、和技術方案實現是否吻合）；
爲什麼要做大量評審工作？因爲如果源頭存在問題，那麼研發過程和用戶使用質量就無從談起，方向錯了就全錯了。
評審的價值在於從用戶使用場景角度出發，通過評審提問，把需求逐步澄清並形成驗收條件，產、研、測三方共同確認，形成共識，以保證大家對需求的認知不發生偏差，爲後續團隊正確的做事提供有價值的指導。
研發過程質量
“軟件質量是構建出來的，不是測試出來的”。
測試的本質是驗證研發交付的產出物是否達到需求設計及預期的標準。並不能直接帶來質量的提升，只能通過種種手段多維度的去驗證是否達標，並通過流程規範、度量標準等去保障最終的交付物達標。
因此，我們常說的各種測試技術手段，都是驗證和保障交付質量的手段，而不是構建質量的手段。
當然，開發有自己的一套體系，比如編碼規範、單元測試覆蓋率等，這裏不做詳細描述，我們重點關注測試維度。
用戶使用質量
用戶使用質量，指的是軟件線上發佈後，我們對用戶使用過程進行追蹤並採集數據進行評估度量的過程。
軟件工程是將軟件研發過程進行科學管理以控制質量，通過流水線的形式進行交付上線。
而軟件測試則是通過一系列手段來驗證最終的交付產出物是否達到預期的質量標準。
那麼，誰該對軟件質量負責呢？
誰對軟件質量負責？
通過上文可以看出，軟件質量的構成主要由需求設計質量+研發過程質量+用戶使用質量三者決定。
換個角度來理解就是軟件質量=功能質量+代碼質量+過程質量。
功能質量用來評估軟件產品是否滿足用戶的預期需要，代碼質量很大程度上決定了最終交付質量的下限，過程質量則是整個研發交付過程是否足夠標準高效。
因爲影響質量的因素，除了需求和代碼，還有投入的成本、涉及的範圍以及時間。
既然軟件質量的構成和影響因素有多方面，那麼軟件質量也並不是獨獨由測試工程師負責。
有一點需要明確的是：在工作中一定要權責對等，而不是按照崗位名稱定責甩鍋。
按照軟件質量=功能質量+代碼質量+過程質量的公式，那麼應該由如下三種角色對軟件質量負責。
- 功能質量：軟件測試工程師；
- 代碼質量：軟件開發工程師；
- 過程質量：項目經理/項目負責人；
我一直有個觀點是技術本身不產生價值，需要藉由業務的商業價值來體現技術的價值，技術對業務提供支撐和服務。
所以無論是測試還是開發或者項目經理，其實本質利益是一致的。
權責分明，利益明確，保持一致的方向和質量保障理念，才能更好的交付高質量的軟件產品。