本文主要记录自己在读到 TesterHome 中一些文章的感悟和理解。
俗话说好记性不如烂笔头、吾日三省吾身；
一是可以把好的文章、技术、理论记录下来方便自己日后再次查阅学习
二是在读到这些文章，自己要在多想下碰到这样的问题，以我现在的能力，我会怎么去处理。大佬们是怎么去处理的，我和他们的差距在哪里。然后给自己列一个处理建议。

总归来讲：记、反思、做、

1.读关于功能测试人的价值感悟

正文是提出一个需求，针对该需求进行用例设计。
产品需求：
【假设】微信支持余额支付时，不足的部分可以信用卡补充一起支付，但针对使用余额支付的部分给予 3% 的优惠（直接用于本次支付中）
看到这个问题，我的思路是这样的
1·功能性
2·性能性
3·安全性
4·易用性
5·兼容性
从上述的大纲里，去找对应的测试点。
1·功能：
使用场景法： 支付成功、支付失败

• 余额充足当前金额,不使用优惠
• 余额不足时，使用信用卡叠加支付，
  • 考虑是否有绑定信用卡
  • 信用卡的额度不够当前支付
  • 信用卡扣费失败，这个可以根据第三方的异常返回码做 调用异常场景设计
  • 信用卡扣费失败、余额扣费，涉及到多方的数据一致性。事物操作；同时也要考虑在实现时的扣费顺序问题
  • 是否支持多张信用卡联合扣费
  • 余额扣费 3% 优惠的验证，是否是按 3% 进行减免
  • 余额扣费有没有前提条件，比如需要余额大于 1 元？等一些隐性的业务需求，或当前不明确的业务需求；
  • 优惠有没有次数限制？用户级别每日？

2.性能：

• 高并发下接口响应成功率、接口耗时、数据正确性、组件的资源占用、
• 我方是否有熔断、降级等策略

3.安全：

• 调用请求是否有 鉴权判断。是否是密文，
• 是否有风控能力、能识别异常支付、非法支付、危险支付

4.易用
无

5.兼容：
不同微信版本、新老信用卡有没有兼容性的问题

这个自己 10 来分钟想到的。
在看文中的 15 楼、21 楼大佬的回答。自己的想法就有点捉襟见肘了。
反思下不足的地方：
1·行业背景。面对支付、金融类的产品，没有相关行业背景是很难说出关键点了，这个没办法 ---经验问题
2·测试思想或意思。要有发散型思维、能跳进功能里扣细节，也能跳出功能考虑全局，上下游。但其实个人认为，真要面对该需求，肯定是扣细节，上下游的比如退款，是另一个节点，或另一个流程的事了。但在面试中，是要发散的。在日常中其实应该把相关的能力进行串联。
3·套路问题。个人认为很多事情是套路、模板式的。一些问题的回答模板 + 经验的回答，估计就是高分答案。模板要找出适合自己的、符合自己设计思路的、正确行业模板、最近在看一个有关测试策略的书，待看完领悟后，在补充该内容
改进：
1·补充测试知识。
2·多想想。多问个还有啥？对与不对，先让自己的思想开发下，不然长期的重复工作，类似的项目执行，思维真的很固化，像井底的娃。。。