基于用戶使用場景的產品測試
產品測試一般都是圍繞需求為主的產品需求設計說明書PRD文檔來展開測試的，針對每個功能點編寫測試用例，去驗證功能的正確性和完整性。這種方式在正常的開發上線進度下都不會有問題，相反是一種很好的驗證功能需求實現的方式。但在敏捷開發模式或者因為趕進度的原因，造成產品測試時間非常緊的情況下，用這種方式就會有點捉襟見肘。
以用戶為中心的產品設計已經逐漸的深入人心，產品主題功能要能滿足用戶的某種訴求或者解決用戶的某個痛點，也有說成是以用戶痛點為中心的產品設計。在這種大背景下，產品開發完成后，如果測試時間非常緊，在不能保證產品沒有問題但卻必須要按時上線的時候，就必須保證產品在用戶使用的場景下沒有問題，也就是說優先保證用戶使用產品的整個流程當中不會出現問題，這就是基于用戶使用場景的產品測試法。
在實際的測試過程當中，最常見的還是基于產品功能的測試，那基于用戶使用場景的產品測試兩者之間有什么區別呢？區別一是后者的測試范圍更小，忽略了一部分產品后臺功能的測試或隱性的功能測試，即只是測試了表面操作性的過程，沒有測試底層的功能；區別二是后者的測試是把產品功能轉化成實際用戶使用場景下來測試，這就要求測試人員要從普通用戶的操作角度出發，而不能受開發人員的影響，以一個初次使用產品的用戶角度，來驗證產品的功能是否可以在使用過程中提供正常的服務。
這里需要注意的一點是，在時間進度允許的情況下，還是要基于產品功能的測試，以求測試可以覆蓋到產品的方方面面，確保產品可以提供完善的服務。本文所闡述的基于用戶使用場景的產品測試都是建立在測試時間非常緊的前提下的，因為本身這種測試方法因為測試的不夠全面，有一定的風險性在里面，對產品而言不一定是好的，只是為了保證產品的發布時間，而采取的一種較為折中的測試方法。這種測試方法的使用需要有以下兩個要素，否則最好還是做全面的產品功能測試。
測試時間非常緊
其實這種場景非常的常見，項目進度安排了之后，往往因為需求分析的時間超長了，或者開發的時間延誤了，導致最后留給測試人員的時間非常少，這時如果必須保證項目上線進度的話，就無法完成全面的產品功能測試，只能優先測試用戶操作流程當中所需使用的各個產品的功能模塊的流程。有的時候也是因為測試資源的不足所導致的測試時間緊迫，測試人員在這些情況下可以考慮基于用戶使用場景的測試，但必須與項目經理或者主管領導說明清楚，是為了確保項目進度而采取的優先測試用戶使用產品流程的功能。
從傻瓜用戶的角度測試
基于這種方式的測試，測試人員就必須從用戶的角度出發，而不是從開發人員或者產品經理的角度。也即測試人員必須保持相對的純粹性，可以參加產品功能需求的review，但就不應該參加開發人員的系統設計review了，否則會受到開發人員實現方式的影響，而導致后續的測試不準確。應該是在保證理解產品功能需求的基礎上，盡量從普通用戶的使用場景出發，找出使用過程的問題，以便開發人員優先解決，這時候測試人員也不需要和開發人員去討論問題，只需告訴問題發生的場景即可，以便盡可能的不受外界信息的影響。
在上述兩個要素滿足的條件下，測試人員還要拋開自己的計算機專業素養，把自己當成一個大眾化的用戶，以使測試的結果更接近真實的使用場景。由于該種測試方法并未覆蓋產品的全部功能，會造成產品發布后有一定的風險性，既然知道有這樣的風險，就需要去盡量的避免或者降低相應的風險，這就需要整個產品團隊的配合，也需要測試人員自身有一套完整的測試體系。
開發人員的自測和Code Review
開發人員在開發完成之后，需要有一輪自測，以降低代碼風險和功能缺陷，減少后續測試驗證和改BUG的時間。自測的過程當中，需要與產品經理的需求相結合，以實現第一輪的功能驗證，一旦出現問題及時解決。開發人員也是最熟悉底層結構的人員，一些底層的功能問題可以在自測過程當中去發現解決，盡可能保證沒有大的問題遺留到測試階段。自測也是開發人員自身能力水平提升的一個很好的機會，提升代碼質量的同時，也是提高對自身編寫代碼責任度的一種方式。自測是需要基于開發人員自身的能力水平的，此外還可以借助團隊的配合，如敏捷開發模式當中就很強調開發團隊內部的Code Review，一個開發人員編寫的代碼，由另外兩個經驗較深的開發人員來共同把關，這樣也可以在很大程度上減少代碼缺陷，盡早的發現問題。
從用戶使用的角度去測試
基于用戶使用場景的測試不能保證產品沒有問題，但必須保證產品在用戶使用過程當中沒有問題，這就要求測試人員必須從用戶的角度出發，真正按用戶的操作流程去操作測試產品的功能。再就是把編寫測試用例的時間，留出來用于理解產品的功能需求，以便在測試的過程當中及時發現不滿足需求的功能點，因為這類功能點在測試的時候并不會出錯，但卻不是需求說明書中所設計的那樣，這就需要測試人員充分的理解需求。也不是說測試用例就不需要編寫了，而是在測試的過程當中，依賴測試工具去記錄測試的過程，后期再來整理這部分用例。因為這個測試階段結束了之后，后續還是要繼續驗證產品的整體功能的，包括底層的功能，這時可以一起編寫測試用例文檔。
從用戶的使用場景出發去測試需要測試人員對用戶使用產品的方式有一定的了解，比如說財務系統和普通的業務系統在操作的時候差異就比較大，原因是財務系統受國外成熟財務系統產品的影響比較大。這需要測試人員去更多的了解用戶的使用，當然這個過程也還是要基于產品自身的功能結構設計，不排除有一些需要培養用戶使用習慣的功能，這種功能就需要產品經理做一些特別的說明，以使測試人員理解產品設計的意圖，最好可以提供一份產品操作使用手冊。
前面也都提到了這種測試方式是存在風險的，這就要求在發布上線之后要繼續進行剩余功能的測試，而不是測試過程就終止了。在后續的測試過程當中，可以一并驗證之前遺留的問題，并在接下來的一個快速迭代中上線解決掉，這樣就可以將產品的功能風險降到最低，使產品提供穩定的服務。
基于用戶使用場景的測試目前應用的還不是很多，在創業型產品的快速迭代中，或者敏捷開發模式下的敏捷測試當中，會有一些應用。這種方式雖然有一定的缺陷，但卻是一種非常好的備選方案，可以在保證項目進度的情況下，也能保證用戶在使用產品的時候不出問題，使產品在用戶手上沒有問題，這也是發布產品的一個目的，符合產品發布的要求。
