有讚的深度需求功能測試

轉自：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服務化的深刻推動，系統拓撲結構愈來愈複雜。咱們也在不斷提高測試小夥伴的測試能力及問題思考的能力。 
       咱們的平常測試，通常須要考慮需求功能測試、性能測試、異常測試、安全測試。

1、熟悉技術方案

       有贊如今沒有純粹的測試工程師，不管是經過閱讀技術方案文檔、或是跟開發 Face to Face 溝通技術方案。從中，測試同窗須要瞭解一下信息：

• 當前需求，涉及哪些應用的改動，或者個人業務須要改動哪些應用；
• 瞭解每一個應用在全站系統拓撲結構的節點位置；
• 個人應用，調用其餘應用接口，是強依賴仍是弱依賴；
• 個人應用，所提供的服務，是強依賴仍是弱依賴；
• 有些功能實現，是否有設計模式，仍是硬編碼；
• 新老系統的兼容性、App新老版本兼容、不一樣手機版本的兼容性；
• 技術方案中的Db變動方案、數據遷移方案、及T+1覈對方案；
• 是否使用緩存，及緩存數據如何保持一致的；
• 異常狀況下的健壯性，技術方案中是如何實現的；

2、測試方案設計

       在充分理解需求及技術方案後，從橫向角度，我通常把功能測試三個部分。

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 系統對象生命週期

       咱們在作測試方案設計，處理前面的三點，還會從對象生命週期考慮設計方案。

• 咱們須要知道，每一個系統對象存在多少個狀態，好比交易訂單(如上圖)。
• 每一個狀態間是否能夠正向扭轉，逆向扭轉，扭轉條件是什麼。
• 例如，待支付狀態，若是買單下單，不支付走了；這個單子不能一直是待支付，因此係統須要可以發現長期未支付，直接關閉；同時須要支持，買家關閉等。
• 關閉訂單時，系統能直接把單子關閉嗎？它有沒有可能已支付，只是支付回調尚未回來。
• 若是由於系統設計，支付未回調以前，被關閉了；回調回來後，系統該怎麼作，確保不會出現買家錢付了，單子被關閉了。
• 對象不一樣狀態的相關方有哪些，每一個相關方都有哪些權限或者系統提示文檔如何等。

       本次分享僅寫了咱們平常工做中在需求功能測試方面的一部分，不一樣的需求所須要考慮的點各不相同，本文只是不多一部分，留意待續。同時，您在閱讀過程當中，如認爲有待交流溝通。歡迎聯繫本人郵箱lvguoyong@youzan.com。

關於有贊及加入有贊

關於有贊 https://www.youzan.com/intro/about 加入咱們 https://job.youzan.com/

同時，您也能夠直接把簡歷投遞到 job@youzan.com   lvguoyong@youzan.com

 
如無特殊說明，本文版權歸 本文做者及有贊技術團隊 全部，採用 署名-非商業性使用 4.0 國際許可協議 進行許可。
轉載請註明：來自有贊技術團隊博客 http://tech.youzan.com/you-zan-de-shen-du-xu-qiu-gong-neng-ce-shi/

歡迎關注有贊技術團隊微信公衆帳號瞭解更多，保持聯繫