pos机测试用例设计方案

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://www.pos-diy.com/posjithree/211745.html