轉自：https://tech.youzan.com/you-zan-de-shen-du-xu-qiu-gong-neng-ce-shi/?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io
序：在《有贊.測驗團隊介紹(一)》曾經提到過，我們在測驗需求專案時，會把需求逐級拆解，直到最小粒度，然后，各業務線的測驗小伙伴把任務領走進行細化，同時，確定一位主測分來主導復雜專案的測驗作業，
在面試程序中，很多小伙伴也會說，我們會根據需求所描述的功能，進行測驗，那作為一位應聘者，如何才能把自己之前作業的能力展示給你的面試官呢，
隨著有贊SOA服務化的深入推進，系統拓撲結構越來越復雜，我們也在不斷提升測驗小伙伴的測驗能力及問題思考的能力，
我們的日常測驗，一般需要考慮需求功能測驗、性能測驗、例外測驗、安全測驗，
一、熟悉技術方案
有贊現在沒有純粹的測驗工程師，不論是通過閱讀技術方案檔案、或是跟開發 Face to Face 溝通技術方案，從中，測驗同學需要了解一下資訊：
- 當前需求，涉及哪些應用的改動，或者我的業務需要改動哪些應用；
- 了解每個應用在全站系統拓撲結構的節點位置；
- 我的應用，呼叫其他應用介面，是強依賴還是弱依賴；
- 我的應用，所提供的服務，是強依賴還是弱依賴；
- 有些功能實作，是否有設計模式，還是硬編碼；
- 新老系統的兼容性、App新老版本兼容、不同手機版本的兼容性；
- 技術方案中的Db變更方案、資料遷移方案、及T+1核對方案；
- 是否使用快取，及快取資料如何保持一致的；
- 例外情況下的健壯性，技術方案中是如何實作的；
二、測驗方案設計
在充分理解需求及技術方案后，從橫向角度，我一般把功能測驗三個部分，
2.1 人機互動
最基本的人與設備間互動，例如小程式設定、在微信上打開有贊商品下單，
2.1.1 前端測驗部分
人機互動測驗，有很大作業在頁面測驗，頁面測驗用例要寫得盡可能詳盡，否則，測驗時，可能會有遺漏，特別是需要開發自測的用例場景，我們結合有贊前端框架及業務，撰寫《功能測驗.頁面測驗.基本篇》，
在實際作業，還需要有實際策略，現在微信小程式將注冊開放給了開發者，在有贊也可以直接注冊小程式，其中可以設定類目,這是類目怎么測，
按照微信的要求，不同類目要求提交的證書各不相同，有些類目，可以選擇證書型別(如圖)，有些類目是固定證書，證書也有單個和多個的要求，設計測驗方案時，我們深入的開發確定，類目資訊是前端硬編碼，還是存在有贊后端，或者是從微信端直接讀取，
- 若是硬編碼，需要逐個測驗小程式200+類目的證書是否正確，
- 若是存在有贊后臺，前端通過設計模式實作，我們只需要驗證設計模式無誤，在check后端配置資料正確即可，
- 若是實時讀取微信，前端通過設計模式實作，我們只需要驗證設計模式無誤，
- 對于讀取有贊后臺，風險是微信修改了類目證件要求，兩方資料如何保持一致，
- 對于實時讀取微信，若微信訪問失敗，系統提示文案如何確定；也要問下自己，微信的所有類目，我都要支持嗎，我的資質是否允許，
2.1.2 后臺測驗部分
以大家比較熟悉的交易下單扣庫存為例，我們買了某件商品，系統后臺就需要扣減商品庫存或者鎖定庫存，
正常交易，我們買幾件商品，從對應的庫存中，扣掉幾件就可以了，早期，因為是兩個系統，兩個事務，測驗需要考慮如何保證事務的一致性，我們需要考慮：
- 正常正向交易場景，是否能夠正常扣減正確，
- 正常正向交易場景，商品扣減失敗，交易創建失敗，商品需要回補，
- 當商品扣減成功后，因為交易例外，回補前，商家編輯了庫存，如何回補，
- 交易呼叫庫存中心扣減超時了，這時前端會提醒用戶系統例外，請重試；對于超時，庫存中心并無感知，它有可能已經把庫存給扣減成功了，那么，方案中交易是如何告知庫存中心，這時一般采用異步訊息，
- 下單程序中，出現請重試，交易系統是新建一個交易單還是復用交易單，
- 如果復用交易單，對于庫存回補，異步回補庫存訊息到達可能會在本次扣減成功后到達，系統如何確保不會錯誤回補，
- 交易作為訊息的推送者，如果訊息推送失敗，是否會重試；即要求訊息不能丟失，又要確保回補不會因為訊息生產者重試，導致多次回補，
所以，有贊測驗小伙伴，需要對需求、系統實作方案非常了解，掌握系統拓撲結構，掌握自己Owner的業務及其周邊業務，
2.2 任務
不管是在傳統行業還是互聯網行業，總是會存在任務或者是腳本，有輪詢從存盤介質獲取資料處理，也有接受訊息中心處理的任務，
舉個業務場景，在有贊系統購買會員卡，商家會創建一個會員卡商品，用戶購買該商品，然后系統把會員卡發放到買家的賬戶里，交易下單與發放會員卡，通過訊息中心將業務連接在一起，會員中心系統監聽交易支付成功訊息，然后放卡，
我們考慮哪些內容：
- 正常正向業務，我買了某張會員卡商品，我是不是得到這張會員卡，
- 會員中心接收到訊息中心推送的訊息后，是先存盤，再處理，直接消費掉訊息，或者是直接處理，處理成功再消費訊息，
- 對于先存盤，再處理，相當于需要在啟動一個任務，消費落地在本地的資料，
- 對于直接處理，處理失敗，需要拋會一個例外或者false；讓訊息中心重新推送，
- 存在重新推送，那么，執行任務是否符合冪等，
- 該Topic訊息失敗重試，是否會有降級策略；例如ABC三個訊息，A處理失敗，A就不能立即重發，等待5秒，把時間片流程BC；沒失敗一次時間片+5秒，
- 訊息重試N次，會被拋棄，一旦拋棄，是否可能出現資損；就該場景，我買了會員卡，是必須發到用戶手里，所以需要有T+1核對，
- T+1核對，有業務方或者資料中心，交易日第二天，將會員卡商品的交易明細與會員卡中心發卡明細做核對，對差異資料進行補全或做其他方面的處理，
- 會員中心作為事件處理方，如果需要多系統協作，需要做到冪等及事務一致性，或者實作斷點續傳能力；
我們采用盡可能完備的測驗質量規范，盡可能的提高系統的穩定性與可靠性，
2.3 系統回呼
系統回呼，也是系統弱依賴的一種表現形式，A系統需要B系統，但是B系統又不能立刻給出成功與否的答復，就會采用回呼來實作，例如第三方支付、保險公司出單、購買理財產品交易， 這種場景，依賴方發送Request，執行方會回復說請求已收到，待執行方處理完成后，回復給說執行成功或者失敗，就好比我在微信上跟某A說，你幫我辦件事，他說好的；某A處理完成后，微信上跟我說，我處理完了，處理結果是這樣的，
- 我們需要跟執行方確定雙方系統冪等驗證的條件，
- 如果涉及跨防火墻通訊，需要考慮驗證資訊傳輸的正確性及合法性，
- 對于回呼后，如果存在復雜的業務處理，是不是先存盤回呼結果，再處理，
- 對于某些特殊業務，還需要有T+1核對，保證雙方系統的一致性，
- 需要關注對方系統的性能，是否能夠支撐相關業務的能力，
- 同時，考慮其他特殊場景，舉個例子，交易下單支付后，請求第三方支付，可能支付成功了，但是一直沒有回呼，這時交易超時關閉訂單，這時回呼了，這時系統如何處理，
2.4 系統物件生命周期
我們在做測驗方案設計，處理前面的三點，還會從物件生命周期考慮設計方案，
- 我們需要知道，每個系統物件存在多少個狀態，比如交易訂單(如上圖)，
- 每個狀態間是否可以正向扭轉，逆向扭轉，扭轉條件是什么，
- 例如，待支付狀態，如果買單下單，不支付走了；這個單子不能一直是待支付，所以系統需要能夠發現長期未支付，直接關閉；同時需要支持，買家關閉等，
- 關閉訂單時，系統能直接把單子關閉嗎？它有沒有可能已支付，只是支付回呼還沒有回來，
- 如果因為系統設計，支付未回呼之前，被關閉了；回呼回來后，系統該怎么做，確保不會出現買家錢付了，單子被關閉了，
- 物件不同狀態的相關方有哪些，每個相關方都有哪些權限或者系統提示檔案如何等，
本次分享僅寫了我們日常作業中在需求功能測驗方面的一部分，不同的需求所需要考慮的點各不相同，本文只是很少一部分，留意待續，同時，您在閱讀程序中，如認為有待交流溝通，歡迎聯系本人郵箱[email protected]，
關于有贊及加入有贊
關于有贊 https://www.youzan.com/intro/about 加入我們 https://job.youzan.com/
同時，您也可以直接把簡歷投遞到 [email protected] [email protected]
如無特殊說明，本文著作權歸 本文作者及有贊技術團隊 所有，采用 署名-非商業性使用 4.0 國際許可協議 進行許可，
轉載請注明：來自有贊技術團隊博客 http://tech.youzan.com/you-zan-de-shen-du-xu-qiu-gong-neng-ce-shi/
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/247309.html
標籤：其他