前言
面試的時候，經常會臨場出題：給你一個xxx, 如何測試, 或者說如何寫測試用例？xxx可以是圓珠筆，水杯，電梯等生活中常見的場景。
那么給你一個支付的二維碼，如何寫測試用例呢？
二維碼掃碼支付
如下圖，給你這個個人收款的二維碼，如何測試？
首先要知道什么是二維碼？ 二維碼實際上就是一個 url 地址，當手機掃碼后，會根據二維碼上的黑和白(黑色的色素塊代表1，白色的色素塊代表0)區域解析成 url 地址。
然后再分析下使用場景，這里實際上涉及到一個收款方，一個支付方。收款方生成二維碼，支付方拿着手機去掃碼。
知道使用場景了，接着拆分功能點，從字面上"二維碼掃碼支付"， 這7個字可以拆分成3個關鍵字：二維碼，掃碼，支付
二維碼場景用例
針對二維碼寫用例，可以分：
1.生成的二維碼是不是能正確識別，支付方拿着手機能掃的出來
2.二維碼的准確性，掃碼后的功能對不對（本來是收款碼，要是生成付款碼，那就不對了）
3.二維碼的尺寸，清晰度
4.二維碼是否會變（一般收款碼不會變，付款碼會定時刷新）
掃碼場景
掃碼是支付方的使用場景了
1.網絡環境，無網絡的時候，二維碼還能不能掃
2.掃碼的時候，是能自己輸入金額，還是固定的支付金額（個人收款是用戶隨便輸入金額，生成的訂單掃碼是固定金額）
3.如果是商戶生成的固定的訂單，用戶是否可以串改金額？
4.如果是商戶生成的固定的訂單，用戶支付后，能不能重復支付？
5.多用戶同時掃碼支付場景，固定訂單，只能被支付一次
支付場景
關於支付場景就復雜了，雖然上面的是二維碼掃碼支付，其實核心功能在於支付，上面的各種掃碼姿勢都是停留在表面的點點點。
支付金額場景：
1.支付的金額是否可以為空，為0，負數
2.支付的金額最多幾位小數，一般是2位小數，精確到分
3.單筆最大金額
4.單日最大金額
支付方式：
1.支付方式：余額，余額寶，花唄，信用卡，銀行卡
2.支付順序，默認的支付順序是怎樣的（或者自己設置的支付順序）
3.當第一個支付余額不足的時候，是否能默認用第二順序的支付，依次類推
4.不同的支付方式，會有單筆限制，比如不同銀行卡會有不同額度
支付密碼：
當用戶選擇了支付方式，支付金額后，下一步就是輸入交易密碼
1.密碼支付，還是指紋支付，還是刷臉支付
2.密碼正確，交易成功
3.密碼錯誤，交易失敗
4.交易失敗后，是否能重新支付
5.用戶取消支付
6.用戶不支付，放着讓它過期超時
支付狀態：
支付之后，那么就會有支付狀態
1.支付失敗，訂單狀態
2.支付成功，訂單狀態
3.用戶取消支付，訂單狀態
4.支付超時，訂單狀態
對賬：
1.支付方支付成功后，錢是不是變少了
2.收款方收款后，是立即到賬，還是延遲到賬?
3.收款方如果沒網，對方支付成功后，下次聯網是否能看到收款記錄
4.當然支付寶還有語言播報：支付寶到賬xx元
退款：
支付方付款后，突然反悔了，那么此時就涉及到退款功能了
1.退款是原路返回，還是怎樣的？
2.立即到賬，還是人工處理？
3.退款時候有沒有扣手續費？
4.退款后，訂單狀態變更
手續費：
說到手續費，如果對方是花唄，信用卡，那么就涉及手續費的問題
1.對方花唄，信用卡付款，手續費扣比例對不對？
2.退款的時候，手續費會不會算你的？
紅包和券
1.如果支付方有平台紅包可以用，是否能抵扣平台紅包，收款方不受紅包影響
2.還有券的使用，滿減券，是否能疊加，還是固定商品使用券
3.涉及退款的時候，這些紅包和券是作廢，還是原路返回
安全與性能
安全和性能是最容易被忽略的，平常都是點點點的，拿着一個測試需求就想着怎么去點了，如果能回答安全和性能的方面是可以加分的。
支付安全性：
如果是一個固定金額的訂單，比如100元訂單，用戶在掃碼支付的時候，會從二維碼中解析出支付金額
此時如果我抓包后，篡改了金額，比如改成0.01元了，是否能支付成功呢？
一般這種訂單接口都會有sign簽名，防止用戶篡改請求參數
性能：
說到性能，必然會扯到高並發，多用戶同時調用支付接口並發，會不會有什么問題呢？
這里的並發，不是多個人掃一個二維碼，是整個系統比如支付寶用戶有xx億，在一分鍾內有1000w用戶在使用掃碼支付，測試整個系統的性能。
類似於給你一個xxx, 如何測試？這種問題不能停留在表面上，要有全局觀，把它當成一個小的項目去測試。
回答問題的思路從UI-功能-接口-業務-場景-安全-性能等方面回答。
那么問題來了：給你一塊磚頭如何寫測試用例呢？
