pos机软件测试用例（pos机产品测试）

pos机软件测试用例（pos机产品测试）

本文目录

• pos机软件测试用例(pos机软件测试用例是什么)

• 测试用例：水杯、电梯、发红包、朋友圈点赞、支付的测试用例等等

• 智能pos机测试用例(刷卡功能测试用例)

• 集成测试用例和系统测试用例的区别

POS机软件测试用例

1.支付功能测试用例

在支付功能测试中，需要对以下方面进行测试：

• 支持的支付方式：测试各种支付方式，包括现金、刷卡、二维码等。
• 交易金额：测试不同金额的交易，包括小额和大额交易。
• 退款流程：测试在退款流程中是否能够正确处理退款请求，并将金额返还给用户。
• 异常情况处理：测试在出现异常情况时，如网络连接中断等，系统是否能够及时恢复并保障交易安全。

2.商品管理功能测试用例

商品管理是POS机的核心功能之一。下面是几个关键点：

• 商品录入：测试是否能够正确地录入商品信息，并保证商品信息的准确性。
• 库存管理：对于每一个录入的商品，需要进行库存管理。在进行销售时，需要能够正确地判断库存数量并进行相应的操作。
• 价格调整：支持多种价格策略，并且能够按照需求灵活调整价格。

3.会员管理功能测试用例

会员管理是POS机的另一个重要功能，也需要进行全面的测试：

• 会员卡录入：测试是否能够正确地录入会员卡信息，并保证信息的安全性。
• 积分管理：支持积分兑换和赠送等功能，并且能够准确地计算积分余额。
• 优惠券管理：支持多种优惠券类型，并且能够按照需求灵活使用和调整。

4.报表统计功能测试用例

报表统计是POS机提供给用户的一项非常实用的服务，下面是几个关键点：

• 销售报表：生成详细的销售报表，包括商品、时间、数量等方面。并且支持数据导出和打印。
• 库存报表：生成库存清单，并对商品进行分类统计，以便于进一步加强库存管理。
• 会员报表：生成会员消费情况和积分变化情况等相关信息，并为用户提供更好的服务。

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、如果发生多次扣款，如何退款到支付账号

五、产品后台处理上

成功订单的账务处理、失败订单的账务处理、退款订单的账务处理、差错账处理等等。

智能POS机测试用例

智能POS机是一种集支付、结算、管理等功能于一身的终端设备，为了保证其稳定性和用户体验，需要进行多方面测试。以下是智能POS机测试用例的详细说明：

一般的小系统区分不是很大的 1.计划和用例编制的先后顺序 从V模型来讲，在需求阶段就要制定系统测试计划和用例，HLD的时候做集成测试计划和用例，有些公司的具体实践不一样，但是顺 序肯定是先做系统测试计划用例，再做集成 2.用例的粒度 系统测试用例相对很接近用户接受测试用例 集成测试用例比系统测试用例更详细，而且对于接口部分要重点写，毕竟要集成各个模块或者子系统 3.执行测试的顺序 先执行集成测试，待集成测试出的问题修复之后，（配置管理，基线化），再做系统测试。 4.用例的数量 系统测试的用例数量一般比集成测试的用例数量少，具体的数量要根据各个公司的性能基线来确定，一般写不到这个数量的测试用例还通不过审计 系统测试这个称呼往往被用于压力测试、容量测试、性能测试、安全测试等方面。 而集成测试这个称呼往往被用于细节化的功能测试的超集——从用户需求来设计和组织较大颗粒度的功能测试。 系统测试最主要的就是功能测试，测试软件《需求规格说明书》中提到的功能是否有遗漏，是否正确的实现。做系统测试要严格按照《需求规格说明书》，以它为标准。测试方法一般都使用黑盒测试法； 集成测试在系统测试之前，单元测试完成之后系统集成的时候进行测试。集成测试主要是针对程序内部结构进行测试，特别是对程序之间的接口进行测试。集成测试对测试人员的编写脚本能力要求比较高。测试方法一般选用黑盒测试和白盒测试相结合。集成测试：是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的借口是否正确。它根据集成测试计划 ，一边将模块或其他年间单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各个组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。也可以理解为在软件设计单元、功能模块组装、集成为系统时，对应用系统的各个部件（软件单元、功能模块接口、链接等）进行的联合测试，以决定他们能否在一起共同工作，部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。 系统测试：系统测试是基于软件需求说明书的黑盒测试，是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确，并非一项简单的任务，被称为测试的“先知者问题”。因此，系统测试应该按照测试计划进行，其输入、输出和其他的动态运行行为应该与软件规约进行对比。软件系统测试的方法很多，主要有功能测试，性能测试，随机测试等。通俗的讲，一个产品从研发到出厂的工程中，测试分为三个阶段：单元测试、集成测试、系统测试； 单元测试：一个模块的功能及常规错误测试； 集成测试：完成单元测试后，各模块联调测试；集中在各模块的接口是否一致、各模块间的数据流和控制硫是否按照设计实现其功能、以及结果的正确性验证等等；可以使整个产品的集成测试，也可以使大模块的集成测试； 系统测试：针对整个产品的全面测试，既包含各模块的验证性测试（验证前两个阶段测试的正确性）和功能性（产品提交个用户的功能）测试，又包括对整个产品的健壮性、安全性、可维护性及各种性能参数的测试