- 涉及调用其它内部、外部服务的,尤其是异步调用、MQ通知等,有时还要考虑调用返回超时或错误时候的处理(如果有此逻辑的话),(所以我们要搞清楚逻辑调用关系和系统架构)
- 触发批处理程序调用的
- 定时任务要考虑到
- 有缓存时的数据一致性
- 分库分表的数据一致性
- 重要服务的主备切换场景
- 分页的处理,翻页以及相关的边界
- 系统功能升级对老用户、老数据的处理,以及升级时处于中间状态的用户,如订单系统升级时,正处于购买流程中的用户场景
- 状态改变时要考虑全面,比如删除1条内容时,涉及总页数变换、总条目数变换、分类条目数变换、平均数等统计数字的变换……
- log信息不容忽视,多一个观测维度终不是坏事
- 跨技术团队的服务要多加注意
- 跨产品团队的需求应该多推敲一下
- 越是构造起来比较复杂,测起来头疼的点,往往越容易出问题
- 搞清楚每一处逻辑,越是开发描述不清楚的地方越要追问到底
- 越是着急上线各方催的紧的时候,越要稳住(这时候代码的质量往往会水准下降,测试有时是需要揣摩各方的心理的^_^)
- 设计测试用例、测试点时需要我们在两个角色间切换:站在用户的角度,会有哪几类用户来使用,用户会怎么用;站在开发者的角度,开发会去怎么实现,各个服务会分哪些逻辑分支
- 涉及多个系统时,上线顺序理清楚
- 评审会时,要想到我们怎么去测,考虑测试环境、测试数据,提出我们的可测试性需求
- 测试透明,让开发、产品明白我们测过的范围,哪些没有测到,尽量避免“测了主流程”这样含糊的说法