結語 跟 前言相呼應

從 服務整合商 >> >> >> 轉變 服務提供商。

適度對外管理也是測試團隊應當掌握的技巧之一。

 以下先說說讀者我的心得

「適度的 對外管理 也是測試團隊應當掌握的技巧之一」這個精神，可以說是貫穿全部的測試。從 Bridge 的角度轉為 Lead 的角色，讓測試的掌握度大大提升。

 街口支付的測試流程

街口支付的業務同質性、一致性比較高些，因此可以利用具『 規模 』的優勢，前後跨一步搭建測試環境來提升測試的全面性。而一般專案、產品的使用情境多半是多元化，較缺乏規模經濟的優勢來進行多跨一步的系統整合環境的建置，但基本測試仍然不可或缺。

 基本測試

而自己使用過的 API 基本測試，是使用 Postman 以及 Postman 的 command mode，newman 來進行 「手動回歸測試」，類似這樣的指令，

                              newman run testScript.json --delay-request 40000

 資料穩定性處理

資料穩定性除了可透過 Mock、Mockoon 等工具進行切割界定外，也可透過資料備份和還原至特定狀態來實現乾淨的測試環境。而對於龐大複雜的系統，若資料切割不易，不方便透過還原或匯入特定來源資料確保資料穩定性，此時便需借助外部工具進行測試。而對於輕量型資料處理，備份還原資料方式，則可省略工具安裝以及相關測試語法的學習。

以上是讀者我個人的一點心得分享

 ☆ 以下羅列《軟體測試實務第二冊》
第五章的部分重點 ☆

 街口的標準測試流程

• 手動回歸測試 (手動回歸測試也很讚，沒有一定要自動化測試的迷思)
• 自動化測試(累計 超過 8000 條測試案例)
• 封閉測試(正式機上鎖定對象可用新功能)

 主要影響測試的一些精神

• 需求分析應從驗證測試擴展至情境模擬規劃，讓測試人員提早參與需求討論並設計合適的測試案例。
• 擬定測試計畫並確保測試情境完整性：理解 業務需求、系統架構、確認影響範圍、思考測試限制、選擇測試方法論、界定測試邊界。

 整合測試

 在進行重大變更時，主要使用公司內部人員作為白名單，以控制封閉測試的訪問權限。這些白名單成員將率先在正式環境中使用新功能，並驗證第三方服務是否已按時上線到正式環境。此操作用於執行相關驗收測試。 並依照測試結果來判定是要灰度發布還是全量發布。

 串接第三方測試實例

隔行如隔山，支付的業務大約有：轉帳、掃碼支付、點餐外送、商城票券、機關繳費、授權扣款、售票平台等，推動機關綁定通知(綁定識別號)，與機關交互資料的正確性與異常處理，帳單付款確認及機關同步繳費狀態。驗證代收金流的正確性。短短的一年五個月的期間，進行了 14 家的路邊停車費服務處理的測試。

串接第三方的問題

第三方服務串接種類很多有：支付、繳費、轉帳、售票等等，而第三方服務的穩定性，是街口團隊非常需要關注的議題。

• 模擬第三方並解耦強依賴：不可用、不穩定的測試環境。
• 透過 Mockoon 的 GUI 建立 Mock 3rd-Party Server。
• 在銀行收單這個部分，以 銀行串接規格書「JKO Bank」模擬銀行服務(JKO Mock Service)，並開發跟銀行相同的功能，如：銀行綁定網頁、帳戶交易功能、用戶綁定狀態查詢、用戶交易狀態查詢、加解簽驗證及交易紀錄檔案交換。

如是上述兩處，提供了串接問題查找的穩定性，並且可以明確的知道問題點在哪裡。並搭配線上監控，加強穩定性。

 街口支付的銀行介接規範

 街口支付在後端銀行方面，制定了「銀行介接規範」，並建立了「JKO虛擬銀行」，用於模擬銀行業務。這個虛擬銀行的運作功不可沒，它不僅可以幫助街口快速發現新合作對象在介接上的問題，還可以為新參與街口服務的單位提供「可用的 API 規範和測試」。