冒烟测试后，在进行详细测试时，状态不好。
在测试岗位上，有时感觉枯燥，可能在这个阶段的重复测试，会带来这样的feel
1、在测试用例下功夫：
①让用例层次分明，用例结构更加清晰
②让每个用例都独一无二，简洁（愿意看）、功能不重复（愿意测）
2、端正心态：
①发现bug未修复未发版前，也是有必要继续测试的（在未阻塞的前提下），发现更多问题
②按思维导图测试也是可以的，在测试阶段，不建议停下来等版本，从以往bug的趋势图看，前期不给力会给后期修复bug和集成测试造成压力，版本上线匆忙，质量不稳定。
图一，看看用例编写的：
测试时的记录，还要清晰。
笔记的方式、清晰地记录，能帮助梳理思路，
1、在这篇博文中(https://blog.csdn.net/fanjialiang2401/article/details/80115245)，等价类、判定表等的表格方式，还蛮清晰的
测试质疑的态度：对于这个bug是否需要修复，从测试角度考虑：‘有入口就要有结果’（bug：jjw用户从wap跳APP看直播时，无法统计到直播的看课记录（暂无该使用场景））
1、后来询问了产品，这个bug需要修复。
寻找测试态度
在这个版本上，测试过程中态度还不算太好
要结合思维导图，来测试相关模块的功能。
对已知bug，再次测试，再次验证可能会影响的相关功能。
探索性测试
支付在弱网环境，及异常情况下的测试
模拟的环节：服务器外网通信较慢时，等待支付方验证收据的有效性时超时，图二，就是这类现象，当几分钟后再次查看该订单，订单状态已显示：已完成
IOS内购支付成功，鹿币未充值成功，先采用埋点方式，跟踪在哪丢了事务？，图三，是内购支付，购买虚拟产品
1.正常流程能支付
2.支付完成查看埋点的地方，日志是否记录成功
压力点：批量新建card（5000）；批量激活card（10个人*100个商品），批量生成订单会对服务器产生压力；