1、Postman接口測試之:Postman實現接口請求(1)

課程實例使用的url地址匯總：

開源接口部分：  https://api.apiopen.top/api.html

1、獲取時間get接口 http://poetry.apiopen.top/getTime

2、網易新聞post接口 https://api.apiopen.top/getWangYiNews

3、百度ip接口 https://sp1.baidu.com/8aQDcjqpAAV3otqbppnN2DJv/api.php?query=12.12.12.12&co=&resource_id=5809&t=1636461955537&ie=utf8&oe=gbk&cb=op_aladdin_callback&format=json&tn=baidu&cb=jQuery110206769724197850711_1636461449011&_=1636461449013

電商項目部分： 電商網站： http://www.testingedu.com.cn:8000/

4、電商登錄接口：http://www.testingedu.com.cn:8000/index.php?m=Home&c=User&a=do_login&t=0.9806405470978172

5、文件上傳接口 ：http://www.testingedu.com.cn:8000/index.php/home/Uploadify/imageUp/savepath/head_pic/pictitle/banner/dir/images.html

自動化平臺項目：平臺網站： http://39.108.55.18/mypro/#/login

6、平臺登錄接口：http://39.108.55.18/mypro/api/user/login

Token接口項目：Token項目網站： http://www.testingedu.com.cn:8081/inter/

7、Token項目 SOAP接口：http://www.testingedu.com.cn:8081/inter/SOAP?wsdl

1、 Postman 安裝之后， 可以進行一下更新。

使用的時候最好可以注冊一個賬號。

先創建一個workspace，用于管理接下來使用過程中產生的內容。

2、接口測試的基本流程： 本質就是抄。

1、了解接口信息 ： 由開發提供接口文檔， 或者通過抓包來獲取接口報文信息。

2、 設計測試用例

3、 執行測試用例： 用postman等工具執行。 請求發包。

4、驗證返回結果。

3、 HTTP協議接口報文： 理解成寄快遞。

接口報文分為請求和返回，格式其實是相同的。

請求

請求四要素： http方法 、url地址、請求頭 、請求體。

請求行： http方法（郵寄方式） url（地址） http協議版本

請求頭： 鍵值對格式 ，鍵：值 用換行分割的方式。 （快遞單）

除了特殊指定的要填的請求頭以外，注意 post請求 需要關注content-Type請求頭，表示的是請求體的編輯格式。（快遞的運輸方式 常溫/冷凍）

常見的content-Type類型：

application/x-www-form-urlencoded: url編碼格式： 鍵=值&鍵=值

application/json: json格式字符串： {"鍵":值,"鍵":值}

postman選 raw格式之后，下拉欄選擇json

注意：復制json格式的請求體的時候，如果從瀏覽器開發者工具中復制，記得確認鍵必須帶雙引號。最好view source 之后再復制。

multipart/form-data： 用于進行文本和文件的混合傳遞。 完成文件上傳。

選擇posmtna中的 form-data進行參數填寫。

注意： Name空格中，可以選擇下拉 file或者text。

文件用file上傳，文本用text上傳。

text/xml: 用xml格式來進行傳遞。 <鍵>值</鍵>

選擇 body中的 raw格式 ，下拉欄用xml進行填寫：

注意：content-type postman會默認使用 application/xml，需要自己確認，到底是text/xml還是application/xml，如果不對，進行修改，最后是直接去掉原有的，加一個新的content-type頭。

請求體 ： 請求頭之后空一行 ，之后的就是請求體。 （寄的東西）

返回

返回行：http協議版本 HTTP狀態碼（物流狀態） 狀態碼描述

返回頭： 鍵值對格式 ，鍵：值 用換行分割的方式。 （快遞單）

返回體 ：返回頭之后空一行，就是返回體 （對方寄回的東西）

返回：重點驗證返回體。

4、http協議抓包：

使用瀏覽器開發者工具抓包：

在網頁上右鍵檢查，或者按下F12，打開開發者工具，切換到network 界面。

注意：記得勾選 preserve log。

請求體中：request payload （json格式、xml格式和普通文本） 和form data （文件和x-www-form-urlencoded格式）

使用 fiddler /charles 等http抓包工具抓包：

在fiddler菜單右側，用inspector 選項進行查看，選raw（原始）格式能夠直觀看到報文格式。

http是一個簡單的請求-響應協議，它通常運行在TCP之上。它指定了客戶端可能發送給服務器什么樣的消息以及得到什么樣的響應。

http協議是基于url地址的資源請求協議

5、用postman發送報文請求：

1、http 方法 和 url 進行填寫。 注意 url中最后帶上的空格也會有影響，所以千萬注意。

2、請求頭一般先不做過多關注，先用默認的，除非有明確的說明需要設置某個請求頭。

3、請求體在postman 請求欄的body中進行設置。選擇相應的content-type格式進行編輯，可以自動設置，不用自己設置 請求頭中的 content-type。

6、unicode編碼： \u 4位16進制數，用于表示某個特殊的字符。

例如：\u7f8e\u56fd\u963f\u62c9\u65af\u52a0

7、get和post的核心區別：

get方法，通常不帶請求體。

而post方法可以攜帶請求體。

END

2、誰能給我說說關于POS機器的客戶體驗測試的用例怎么寫!謝謝啊!

LZ這個問題有點大，建議分四步自行解決：1.先找一個ATM的用例組或用例設計思路（這個在網上應該能找到）2.增加嵌入式通訊設備中數據傳輸用例組（比如手機打電話/發短信的用例，這個在網上也能找到）3.增加嵌入式設備(準確說是手持設備)特殊用例組（如電源、三防……這個現成的比較少，盡量找吧）4.最終，篩選3組數據，最終生成POS機用例組。

3、為什么中國的POS機不采用像美國那樣的一體化設計?

最早國內的 POS 終端，只支持磁卡形態的銀行卡，對于 IC 卡形態的銀行卡在硬件上就不支持。歐美國家在1994年推出 EMV 規范第一版，統一了國際三家最大發卡行組織 (EuroPay, MasterCard, Visa) 的 IC 銀行卡標準后，即開始著手針對當時的 POS 終端進行 EMV 改造，使其可以支持 IC 卡的讀卡。到 2005 年前后，歐美國家的 POS 終端已經基本支持 IC 卡讀取。而此時我國的 POS 機一方面還不支持 IC 卡讀取，另一方面售價仍舊高昂，單臺 POS 機的價格可能在 5000 元上下，如果采用整機更換的形式，從成本上來說是不可接受的。但是如果因此就放棄效仿歐美國家對終端實施 EMV 改造，則由于磁卡詐騙造成的經濟損失將會越來越大。因此遇到兩難的情況，就總得需要一個兩頭兼顧的解決辦法——現在國內的分體式 POS，其實并非是什么陳舊的思路，或者習慣問題——其實它就是針對該情況給出的一種改造方案。 如果大家觀察一下就會發現，分體式 POS 的密碼鍵盤上，是帶有磁卡刷卡器以及用于讀取 IC 卡的 IC 卡卡槽的——是的，為了能夠實現 POS 終端對 IC 卡讀卡的升級改造，廠家將 IC 卡的讀卡功能集成到了密碼鍵盤上。該密碼鍵盤還將磁卡讀卡、NFC（非接觸式）卡片的讀卡、電子簽名等功能同樣集成在了密碼鍵盤上。因此無需對 POS 終端主機進行改造，即可將其升級為帶有 IC 卡讀卡、NFC（非接觸卡）讀卡、電子簽名等高級功能的新型終端。POS 終端的主機只需要專注完成非讀卡的部分，以及與銀行后臺的通訊即可。當然和歐美國家一步到位的 POS 機相比較，上述方案顯然是一種妥協的辦法，但是在當年幾十萬部 POS 終端需要進行升級的情況下，無論誰都沒有更好的選擇。目前國內的 POS 機廠家新開發的產品，則已經集成了上述所有功能，基本不需要再外接分體式的密碼鍵盤了。但是在實際使用中，POS 主機放在柜員面前，密碼鍵盤放在顧客面前，結賬時不需要將手持的 POS 機傳來遞去，還是很方便的。

國內幾大POS機廠商早就有設計這個配置了，這幾年新一代的POS機也都升級了屏幕，原先STN屏都改TFT了，電阻屏也是可以選配增加的，客戶有需求就能加上這個功能。以前銀聯一家獨大，現在第三方百家爭鳴啦。 也要順便扯扯電阻屏的一些特性：電阻屏用于電子簽名，一個是筆跡還原度高于一般電容屏（普通電容筆那么粗一個頭怎么簽怎么別扭），一是成本上遠低于電磁屏。但是電阻屏有個缺點是致命的，就是點劃壽命低，常規電阻屏工藝20萬次壽命的屏已經是極限了（早期帶手寫功能的物流POS或PDA設備，用得狠的不用幾個月時間屏幕就花的媽都不認識了）。在電容屏肆虐的今天，電阻屏已經好久沒有技術發展了。目前需要有低成本長壽命的新技術來支持電子簽名應用啊。

銀聯點頭默許電子簽名（小票）也是近兩年的事情。一臺POS機的使用壽命差不多2~3年，在支持電子簽名之前、已鋪向市場的舊式POS并不支持電子簽名，如果要求全部設備支持電子簽名，無論是追加支持的外設還是將舊式POS升級換代，成本代價都不小，收單行業可是薄利行業。紙質小票還是電子小票，地位需要得到監管單位認可，也就是說電子小票在爭議差錯解決中要有認可的地位，如果監管部門不認可，就算你布了電子簽名POS又有何用。借記卡、貸記卡走的都是銀聯通道，借貸不分離的前提下，沒有區別。電子簽名并非每個人都喜歡，而且需要維護，出于多種因素考慮，不會強推電子簽名。

4、測試POS參數

99之后也要輸入簽到密碼啊，這個很關鍵，你如果連99都不知道，那么接下來的密碼你肯定也不清楚了，不同的銀行和企業，這個密碼都不一樣，密碼這步你得問清楚，否則接下來是無論如何進行不了的

5、測試用例:水杯、電梯、發紅包、朋友圈點贊、支付的測試用例等等

1.杯子容量

2.杯子形狀

3.杯子材質

4.杯子耐熱性

5.杯子抗摔性

1.杯子能否裝100攝氏度開水（耐熱性）

2.杯子能保溫多久

3.杯子能否裝0度冰水或做冰塊（耐寒性）

4.杯蓋擰緊到何種程度，水不會倒出來

5.杯子裝滿水幾天后會滲發水分

1.杯子設計的高度和大小

2.飲水機的杯架的高度和寬度

3.杯子倒滿開水后是否容易燙手

4.杯子是否有防滑紋理

1.裝入不同的液體會不會產生化學反應

2.裝入熱水會不會變形和產生異味

3.倒入多少度的熱水，手不會被燙傷

1.除了裝水，還能否裝雪碧、酒、果汁、茶水、咖啡等其他液體

用戶體驗度：

1.紙杯是否符合市場行業標準尺寸

2.是否符合市場杯套使用的標準尺寸

3.杯子是否可以摞起來

4.摞起來的杯子是否容易拿下來

1.杯子的實際大小是否與設計一致

2.杯子的有多重

3.杯子的顏色形狀是否與設計一致

4.杯子整體外觀是否美觀耐看

5.杯子的圖案是否符合常理常規

1.測試電梯能否實現正常的上升和下降功能。

2.電梯的按鈕是否都可以使用

3.電梯內分樓層鍵是否正常

4.電梯內開關門鍵是否正常

5.電梯內的報警鍵是否正常使用

6.電梯外的上下鍵是否正常

1.測試電梯負載單人時的運行情況

2.多人時的運行情況

3.一定人數下較長時間的運作

4.更長時間運作時的運行情況

5.不斷增加人數導致電梯報警

1.電梯的按鈕的設計符合一般人的習慣嗎

2.電梯是否有地毯、夏天是否有空調、通風條件、照明條件、手機信號是否通暢

1.美觀程度

2.光滑程度

3.形狀

4.質感

1.電梯是否有扶手，是否有專針對殘疾人的扶手等等

2.樓層按鍵高度（小孩和一些身高矮的用戶會按鍵不方便）

1.電梯的整體和其他設備的兼容性，與大樓的兼容，與海地隧道的兼容等等

2.不同類型的電壓是否兼容

1.下墜時是否有制動裝置

2.暴力破壞電梯時是否報警，超重是否報警

3.停電情況下電梯是否有應急電源裝置

1.在紅包錢數，和紅包個數的輸入框中只能輸入數字

2.紅包里最多和最少可以輸入的錢數  200  0.01

3.拼手氣紅包最多可以發多少個紅包  100

3.1超過最大拼手氣紅包的個數是否有提醒

4.當紅包錢數超過最大范圍是不是有對應的提示

5.當發送的紅包個數超過最大范圍是不是有提示

6.當余額不足時，紅包發送失敗

7.在紅包描述里是否可以輸入漢字，英文，符號，表情，純數字，漢字英語符號，

7.1是否可以輸入它們的混合搭配

8.輸入紅包錢數是不是只能輸入數字

9.紅包描述里許多能有多少個字符  10個

10.紅包描述，金額，紅包個數框里是否支持復制粘貼操作

12.紅包描述里的表情可以刪除

13.發送的紅包別人是否可以領取

13.1發的紅包自己可不可以領取  2人

14. 24小時內沒有領取的紅包是否可以退回到原來的賬戶

14.1  超過24小時沒有領取的紅包，是否還可以領取

15.用戶是否可以多次搶一個紅包

16.發紅包的人是否還可以搶紅包  多人

17.紅包的金額里的小數位數是否有限制

18.可以按返回鍵，取消發紅包

19. 斷網時，無法搶紅包

20.可不可以自己選擇支付方式

21.余額不足時，會不會自動匹配支付方式

22.在發紅包界面能否看到以前的收發紅包的記錄

23.紅包記錄里的信息與實際收發紅包記錄是否匹配

24.支付時可以密碼支付也可以指紋支付

25.如果直接輸入小數點，那么小數點之前應該有個0

26.支付成功后，退回聊天界面

27.發紅包金額和收到的紅包金額應該匹配

28.是否可以連續多次發紅包

29.輸入錢數為0，"塞錢進紅包"置灰

1.弱網時搶紅包，發紅包時間

2.不同網速時搶紅包，發紅包的時間

3.發紅包和收紅包成功后的跳轉時間

4.收發紅包的耗電量

5.退款到賬的時間

1.紅包描述，可以通過語音輸入

2.可以指紋支付也可以密碼支付

1.發紅包界面沒有錯別字

2.搶完紅包界面沒有錯別字

3.發紅包和收紅包界面排版合理，

4.發紅包和收到紅包界面顏色搭配合理

1.蘋果，安卓是否都可以發送紅包

2.電腦端可以搶微信紅包

1.對方微信號異地登錄，是否會有提醒  2人

2.紅包被領取以后，發送紅包人的金額會減少，收紅包金額會增加

3.發送紅包失敗，余額和銀行卡里的錢數不會少

4.紅包發送成功，是否會收到微信支付的通知

1.是否在發紅包時沒網

2.網絡卡動是否發紅包失敗

1.給某個好友點贊，點贊數+1，點贊欄顯示具體點贊人的名字 ，該用戶手動點贊回饋

2.點完贊后，共同好友在點贊區能看到該人是不是點贊了，非共同好友看不到

3.兩個頭像一樣的人點贊，能否正確顯示

4.點完贊后，在點擊點變成點贊取消

5.取消點贊--不通知用戶

6.點贊后，通知用戶，取消，在點贊，此時不通知用戶

7.多個用戶同時對其點贊，點贊數正常

8.最多能點多少個贊--邊界值測試

9.可以從點擊點贊區頭像，進入相應人的主頁查看

10.點贊是否按照時間順序排序

11.點贊后是否能夠正常評論

1.大量用戶并發點贊時，該接口的響應時間，最大承受的qps

2.大量用戶并發點贊時，此時界面進行點贊，點贊功能是否正常

1.不同手機型號，點贊功能，顯示功能是否正常

2.耗電量，耗流量關注

1.點贊是否讓別人盜用自己個人信息

2.點贊是否有金錢上的交易

1.是否有點贊功能

2.點贊或未點贊是否能評論

1.弱網情況下，點贊能否實時更新

2.點贊時，有短信或者電話進來，能否顯示點贊情況

1、金額的最小值 ：如0.01  

2、無實際支付意義的金額：如0元訂單

3、支付金額錯誤：格式錯誤 、數字錯誤（支付金額為負數）

3、超大金額 ：設置的最高金額上限。（如微信紅包單個最大值為200等）

4、余額小于實際需要支付的金額

5、銀行卡或其他設置當日消費金額或者是單筆消費金額超限

關于支付會設計到很多第三方接口的相關的事件。比如：支付寶 、微信、網銀系統 、手機銀行、POS機的終端服務  甚至是 掃碼槍 等硬件設備也是有關系的。

1、指紋支付

2、免密支付

3、賬號+密碼支付

4、動態獲取支付驗證碼支付

5、銀行卡號+密碼綁定支付

6、信用卡可能會設計到支付碼等

如今的支付方式多樣化、快捷支付和銀行卡支付之間的差異性。信用卡和普通儲蓄卡之間的差異處。等都是需要考慮的。

1、如何處理退款

2、支付時出現斷網  

3、支付失敗之后 如何補單和退單

4、支付金額不足的情況下 ，充值后 是否可以繼續支付

5、持續點擊 是否會出現多次扣款

6、如果發生多次扣款，如何退款到支付賬號

五、產品后臺處理上

成功訂單的賬務處理、失敗訂單的賬務處理、退款訂單的賬務處理、差錯賬處理等等。

轉載請帶上網址：http://yadikedp.com/posjithree/211745.html