pos機測試用例設(shè)計方案

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

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

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

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

2、網(wǎng)易新聞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

電商項目部分： 電商網(wǎng)站： 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

自動化平臺項目：平臺網(wǎng)站： http://39.108.55.18/mypro/#/login

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

Token接口項目：Token項目網(wǎng)站： http://www.testingedu.com.cn:8081/inter/

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

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

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

先創(chuàng)建一個workspace，用于管理接下來使用過程中產(chǎn)生的內(nèi)容。

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

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

2、 設(shè)計測試用例

3、 執(zhí)行測試用例： 用postman等工具執(zhí)行。 請求發(fā)包。

4、驗證返回結(jié)果。

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

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

請求

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

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

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

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

常見的content-Type類型：

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

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

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

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

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

選擇posmtna中的 form-data進行參數(shù)填寫。

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

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

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

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

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

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

返回

返回行：http協(xié)議版本 HTTP狀態(tài)碼（物流狀態(tài)） 狀態(tài)碼描述

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

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

返回：重點驗證返回體。

4、http協(xié)議抓包：

使用瀏覽器開發(fā)者工具抓包：

在網(wǎng)頁上右鍵檢查，或者按下F12，打開開發(fā)者工具，切換到network 界面。

注意：記得勾選 preserve log。

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

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

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

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

http協(xié)議是基于url地址的資源請求協(xié)議

5、用postman發(fā)送報文請求：

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

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

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

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

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

7、get和post的核心區(qū)別：

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

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

END

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

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

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

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

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

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

4、測試POS參數(shù)

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

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

1.杯子容量

2.杯子形狀

3.杯子材質(zhì)

4.杯子耐熱性

5.杯子抗摔性

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

2.杯子能保溫多久

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

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

5.杯子裝滿水幾天后會滲發(fā)水分

1.杯子設(shè)計的高度和大小

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

3.杯子倒?jié)M開水后是否容易燙手

4.杯子是否有防滑紋理

1.裝入不同的液體會不會產(chǎn)生化學反應(yīng)

2.裝入熱水會不會變形和產(chǎn)生異味

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

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

用戶體驗度：

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

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

3.杯子是否可以摞起來

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

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

2.杯子的有多重

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

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

5.杯子的圖案是否符合常理常規(guī)

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

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

3.電梯內(nèi)分樓層鍵是否正常

4.電梯內(nèi)開關(guān)門鍵是否正常

5.電梯內(nèi)的報警鍵是否正常使用

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

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

2.多人時的運行情況

3.一定人數(shù)下較長時間的運作

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

5.不斷增加人數(shù)導(dǎo)致電梯報警

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

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

1.美觀程度

2.光滑程度

3.形狀

4.質(zhì)感

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

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

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

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

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

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

3.停電情況下電梯是否有應(yīng)急電源裝置

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

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

3.拼手氣紅包最多可以發(fā)多少個紅包  100

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

4.當紅包錢數(shù)超過最大范圍是不是有對應(yīng)的提示

5.當發(fā)送的紅包個數(shù)超過最大范圍是不是有提示

6.當余額不足時，紅包發(fā)送失敗

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

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

8.輸入紅包錢數(shù)是不是只能輸入數(shù)字

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

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

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

13.發(fā)送的紅包別人是否可以領(lǐng)取

13.1發(fā)的紅包自己可不可以領(lǐng)取  2人

14. 24小時內(nèi)沒有領(lǐng)取的紅包是否可以退回到原來的賬戶

14.1  超過24小時沒有領(lǐng)取的紅包，是否還可以領(lǐng)取

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

16.發(fā)紅包的人是否還可以搶紅包  多人

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

18.可以按返回鍵，取消發(fā)紅包

19. 斷網(wǎng)時，無法搶紅包

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

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

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

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

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

25.如果直接輸入小數(shù)點，那么小數(shù)點之前應(yīng)該有個0

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

27.發(fā)紅包金額和收到的紅包金額應(yīng)該匹配

28.是否可以連續(xù)多次發(fā)紅包

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

1.弱網(wǎng)時搶紅包，發(fā)紅包時間

2.不同網(wǎng)速時搶紅包，發(fā)紅包的時間

3.發(fā)紅包和收紅包成功后的跳轉(zhuǎn)時間

4.收發(fā)紅包的耗電量

5.退款到賬的時間

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

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

1.發(fā)紅包界面沒有錯別字

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

3.發(fā)紅包和收紅包界面排版合理，

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

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

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

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

2.紅包被領(lǐng)取以后，發(fā)送紅包人的金額會減少，收紅包金額會增加

3.發(fā)送紅包失敗，余額和銀行卡里的錢數(shù)不會少

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

1.是否在發(fā)紅包時沒網(wǎng)

2.網(wǎng)絡(luò)卡動是否發(fā)紅包失敗

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

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

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

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

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

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

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

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

9.可以從點擊點贊區(qū)頭像，進入相應(yīng)人的主頁查看

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

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

1.大量用戶并發(fā)點贊時，該接口的響應(yīng)時間，最大承受的qps

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

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

2.耗電量，耗流量關(guān)注

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

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

1.是否有點贊功能

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

1.弱網(wǎng)情況下，點贊能否實時更新

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

1、金額的最小值 ：如0.01  

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

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

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

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

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

關(guān)于支付會設(shè)計到很多第三方接口的相關(guān)的事件。比如：支付寶 、微信、網(wǎng)銀系統(tǒng) 、手機銀行、POS機的終端服務(wù)  甚至是 掃碼槍 等硬件設(shè)備也是有關(guān)系的。

1、指紋支付

2、免密支付

3、賬號+密碼支付

4、動態(tài)獲取支付驗證碼支付

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

6、信用卡可能會設(shè)計到支付碼等

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

1、如何處理退款

2、支付時出現(xiàn)斷網(wǎng)  

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

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

5、持續(xù)點擊 是否會出現(xiàn)多次扣款

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

五、產(chǎn)品后臺處理上

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

轉(zhuǎn)載請帶上網(wǎng)址：http://www.752p.com/posjithree/211745.html