如何做保證測試工作有價值和意義

前言：

1. 這個需求無法測試，那麼是否有過疑問什麼樣的需求無法測試的。
2. 這個功能無法測試，開發研發的功能為什麼會無法測試
3. 這個bug測試不出來的，到底是漏測了還是測試方法不對？難道真的測不出來嗎？

以上問題大家可能都遇到過，或是心理暗暗疑問，或是幹脆擱置不測，或是幹脆甩鍋産品整理好需求有問題或是研發能力不足，代碼品質差，我能有什麼辦法呢？那麼如何高效的保證自己經手的需求（或功能）的價值和意義呢？

正文：

對于問題發現越早，返工成本越小；那麼在早期需求階段，代碼未研發（或隻有一部分代碼不足形成完成功能）時，如何開展測試工作，順便解答上面的問題。

1. 基于業務需求的确認-（保證需求研發價值）

不論技術需求或是業務需求，都有一個目的，為了解決什麼問題，提出了什麼樣的需求。即 what與how的關系。

在這個階段，測試不會要去質疑what（這個是産品經理的工作，不要越庖代俎；除非你有足夠的理由時可以發表自己的看法）而是待What确認以後，去驗證How，也就是從測試的角度出發，提供最佳的方案，最少的資源，解決掉這個問題。保證需求的價值，在某種程度上保證測試工作的價值

2. 基于研發代碼的測試-（單元測試,保證已研發的代碼的）

這部分工作一般是交給研發的，那麼我們可以做的就是監控此過程，比如單元測試的覆寫率是否達到門檻值；可以研發單元測試平台等

3. 基于需求規格說明書的測試 （産品功能測試）]

基于“需求規格說明書”進行測試

日常工作中，我們拿到的需求描述并不能滿足我們完成這項工作。而大多數測試在設計案例或是測試執行時在需求提測或測試執行時才發現這個問題。

那麼在沒有需求規格說明書時，我們必須擷取哪些資訊才能保證自己的測試工作順利。

必要的[需求說明書]的“輸入”内容；展示測試工作“輸出”

輸入

詳情資訊- 如何寫好需求分析：需求規格說明書

以下主要列舉經常忽略的的輸入資訊

1. 需求限制條件
    限制軟體開發的條件，軟體使用的場景和硬體要求
2. 需求隻描述正向的功能
隻注明滿足條件如何處理，卻沒有明确不滿足條件時應當如何。

3. 需求文檔的背景或前提
- 時間：預計發版時間，最晚發版時間

4. 需求沒有細緻到充分指導實作（或存在多種實作解讀）

5. 了解使用者的使用場景
使用者的業務能力，使用者群體，使用者使用此功能是否與其他功能同時使用等等

6. 命名标準和定義（專業名詞的定義）
 比如催收系統中提前結清和賬務系統的提前結清，含義完全不同
 
7. 産品的範圍

* 工作的上下文範圍（對外系統的接口人）
上下文範圍圖用來表示将要開發的系統、産品與其它系統之間的關系，以确定系統邊界。
* 工作切分
一個事件清單，确定系統要響應的所有業務事件。清單包括：事件名稱；輸入和輸出
* 産品邊界
你可以使用用例圖(use-case)來确定了使用者與産品之間的邊界。

           

輸出：

- 觀感驗證： UI設計，把自己當做使用者
- 易用性驗證：即新系統使用者的技能屬性和業務熟練度
- 新問題：設計帶來的新問題（遺留問題，推廣時的備用使用方法等等）
- 功能驗證：對産品必須執行的動作的描述。
- 業務資訊驗證：軟體不論是操作還是資料的轉變都是為了資訊的記錄和傳遞。
- 性能驗證：使用時間點，使用頻率，使用人數，确定需要的TPS
- 安全性測試
- 精度要求：對産品産生的結果期望的精度進行量化描述。
- 可靠性和可用性需求
- 容量需求
- 可維護性和可移植性需求
- 待定的功能點，或是暫無業務含義，隻是為了未來擴充，或是預留接口；
           

畫外音：有的同學可能說了，有的需求上面的有的根本就沒有的，但是我想說，有沒有是一回事，但是根本不考慮是另一回事

4. 基于軟體設計圖（時序圖）的測試（保證邏輯無誤）

此類針對技術需求或架構調整的需求，架構設計圖必不可少。而架構設計圖是業務需求的補充說明。

那麼在研發開始時，需要提供軟體設計圖（程式時序圖）讓團隊成員（包含測試人員）都了解後續研發的邏輯結構，并對其進行提前評審，檢視是否保證邏輯的無二義性，并且滿足需求的業務邏輯。

測試需要提供研發提測的标準，冒煙測試通過，或單元測試覆寫率達到多少，

這樣可以保證測試工作開展的順利。

5. 基于資料庫設計的測試（資料流向測試）

資料流即資訊流的流轉；資料的狀态必然是有一個初始态和終态

了解資料庫的模式，表與表之間的關聯，在執行案例時，觀察表與表資料流向是否符合預期。