突然想写这篇文章是因为，前两天看到一篇文章【像用户一样测试】
然后想起事儿 ..
想到在2020年上海爆发疫情后，开始频繁使用买菜软件，在一个深夜从某团紧急挑选加购商品，看到提醒自己账户还有一张满减优惠券，挺高兴的。
临近下单想起来还有一些面包没加购，于是又退出购物车页，回去挑选，终于都选好了，一键确认订单时，发现优惠券没用上......
于是到优惠券页面，发现那张券还在【未使用】一栏，再研究发现是过期了，可是【已过期】一栏并没有它，放在以前我索性就不会下单了，无奈食材不好抢，只得气呼呼下单后睡了......
写到这儿，其实还在问自己究竟想写什么，我可能只是想到大学毕业半年刚从嵌入式开发转做测试时，我只是觉得我适合，为啥适合？因为我是一个细节控，抠到烦人的程度。
但是我刚做测试，我完全不知道一个东西应该怎么测，看了很多入门课程，面试时候产品经理问我用例怎么设计，我回答着记下来的官方答案，于是磕磕绊绊的测起来...
再后来，我开始带实习生，新人，给他们分享用例设计 测试点：
分析测试点之前，我们先来梳理一下测试思维。
总结来说，任何事物的测试思路都可以总结如下：
第一步：梳理产品的核心业务流程：明白这是个什么项目，实现了什么业务，以及是怎么实现的？
这个步骤一般是参考公司的需求文档来的，如果产品提供需求文档的同时提供了业务流程图，可以遵循流程图来梳理；
如果产品没有提供流程图，就需要测试人员根据需求的理解自己画出流程图，达到梳理业务的目的。
第二步：根据流程进行模块细分，然后针对每个功能模块进行详细的测试点设计和提取。
单个功能的测试点提取要覆盖以下几个方面：
正常功能验证：优先覆盖正常的业务流程和功能验证，这其实也是单个功能的冒烟测试。冒烟测试先行，如果不通过，可以直接停止测试等开发修复后继续测试。
异常功能验证：为了更加贴近用户的使用场景，我们也要验证各种异常的场景，故意操作导致出错，检查系统的反馈和提示，保证用户操作失误的情况能够得到系统的友好指示。
因为有很多地方的操作都有可能会导致系统异常和抛错，所以为了不漏测，我们需要找出所有可能导致异常的输入项和选项。所以就到了第三步：
第三步：针对具体功能，寻找每个输入项和步骤，从以下三个角度来分析测试点 。
长度，数据类型，必填项，重复需求的约束条件 + 隐形需求 、功能之间的交互 、这其中就需要用到一些用例的具体设计方法了，比如场景法，等价类法，边界值法，错误推测法等等
第四步：考虑非功能测试点，包括界面、易用性、兼容性、安全性、性能压力
举一个产品和生活中都很常见的例子：
【支付功能的测试点】
基于上面的测试思路，我们可以分析得出“支付功能”测试点如下：
一、梳理支付的业务流程如下：
点击支付---> 选择支付方式 ---> 确认金额---> 输入密码 ---> 成功支付
完成这个流程测试，也就是完成了项目的冒烟测试！然后需要测试针对流程中的每个阶段和步骤，具体分析可能导致异常的测试点，所以我们按阶段和输入项来进行划分如下：
1）点击支付，提交订单但是取消了，检查可以取消成功
2）选择支付方式：
正常：可以支持的支付方式有：信用卡，储蓄卡，网银支付，余额，第三方支付（微信，支付宝，京东、百度、聚合支付、组合支付），找人代付，验证是否支持并且可以正常选择并支付；
异常: 没有绑定任何的支付方式时，支付报错。
功能交互：支付时结合优惠券/折扣券/促销价抵扣进行相关的抵扣，验证规则正确，并且可以正常抵扣和支付。
3）确认支付金额：这个步骤可以用到等价类和边界值的用例设计方法
正常：正常金额里用边界值法去设计测试点：
最大支付金额（单日最大，单笔最大，余额最大） 最小支付金额
异常：同样也用边界值方法提取测试点：
超过支付方式单日最大消费金额/单笔最大/余额最大
异常金额支付：非数字、负数、0，小数点超过 2 位等
4）支付密码：
正常：可以支持的支付密码类型有：指纹，人脸识别，账号密码，动态获取验证码，手势，信用卡和支付码，小额免密等，确认自己的产品所支持的密码类型，确认可以验证并支付成功；
异常：输入错误的密码，检查有无提示信息且正确；超过密码错误上限，检查是否冻结等。
5）其他场景测试点：
a、多笔订单合并支付，是否可以成功；
b、重复点击支付按钮，是否会出现多次购买，并同步检查数据库的数据账目正确；
c、支付中断：
主动中断：可以继续支付并成功
被动中断：比如电话、低电量、闹钟，断网、切换后台、耳机插拔等，验证可以继续支付；
d、网络测试：
验证各种网络类型：2G、3G, 4G，5G，wifi 下都可以正常支付； 进行网络切换，支付功能正常； 弱网测试下支付功能正常：不会重复支付多次，APP 不会闪退 崩溃，而且页面提示友好；
e、使用 charles、fiddler 等抓包篡改价格：不允许抓包或者数据加密，篡改不成功
二、退款流程
正常：验证正常的退款流程，也就是退款的冒烟测试：
1、点击退款可以退款成功，并且检查交易状态是退款，退款金额可以到账；
2、结合优惠券等抵扣，可以退款实际支付金额；
3、同步检查数据库的数据和账目是正确的；
异常：提交错误退款（退款订单号不对），或者退款金额错误，都能够退款失败（此处一般会借助工具进行测试，比如进行接口测试）；
三、测试方法
那么以上的测试点在具体公司项目中要怎么进行测试呢？我们有不同的一些测试方法：
1） 小额支付：
需要让开发修改代码，不管支付多少钱，实际支付都是 1 分钱；不顾这种方法只能测试小额支付，就有可能会出现产品小额支付没问题，但是大额支付就错误的漏测情况；
2）申请测试金额：
这种方式一般会作为小额支付的一种补充，比如测试完小额支付后，再测试一些大额支付，这就需要跟公司申请测试基金，走报销流程；
四、非功能测试点
测试完以上的功能测试点之后，我们还需要验证一些非功能测试点，主要包括以下几个方面：
1）界面
验证界面的美观，排版和错别字等。
2）兼容性
BS：如果是 BS 架构的产品，需要测试跟浏览器的兼容性；所以就需要根据浏览器的内核，选择一些主流的浏览器进行测试；
CS：如果 CS 架构的产品，测试手机移动端的兼容，比如手机型号，系统版本和屏幕大小及分辨率等。
3）易用性
测试站在用户的角度考虑用户体验，使用是否方便等。
4）性能
比如考虑多用户支付，长时间运行等，关注产品的响应时间等，一般需要借助工具或者代码进行测试。
5）安全
验证敏感信息是否加密，是否可以篡改；通过一些工具进行安全扫描，检查是否有安全漏洞；或者采用一些其他的手段进行专门的安全测试。
用例设计阶段，用了很多方法设计完用例，但是，用例评审完，尤其项目提测后进入测试阶段，我发现很多时候，一边测一边添加新的用例，在实际测试时，完成正常功能和用例的case场景后，思维一发散、可能用例和bug就都来了......
我的开发tl有次聊天和我说，你怎么想到那么多场景特殊操作的，也给你带的同学说说
我就在想，我怎么开发的用例？
大概因为，我知道合作的开发常犯的错误；作为用户，我常假设我是不同的用户，高效的，注重页面的，价格敏感的，把控细节的，不拘小节的...我们在测试，可我们也是用户，产品经理，也是项目负责人，也是开发，是要对产品负责的任何人。
标签：思考,测试点,验证,用例,测试用例,测试,支付,退款 From： https://blog.csdn.net/weixin_40772077/article/details/136965526