一、背景
业务侧层出不穷的需求,要求我们快速迭代,但这一切的基石是系统的稳定性。
二、共识与固有观念
2.1 共识
我们接到一个新需求后,首先须理解业务,然后与需求方明确业务,这占据整个开发周期中较大耗时。
通常在这个阶段,产品经理会形成需求文档,但往往由于系统功能太多,文档篇幅太长,我们不会一一确认,导致需求文档不具备执行约束。
因此我提倡,在开发阶段使用测试先行策略,也就是由开发人员根据需求文档,提前写出测试用例,明确验收标准。
这样保证,
- 开发的功能和需求是对齐的
- 方便验收
- 写测试用例的过程中,可以提出各种边界情况,方便编码时提前处理。
2.2 固有观念
我们都知道测试很重要,但为什么一直没做?我认为与以下几个固有观念有关:
2.2.1 浪费时间
侥幸和kpi让我们产生错误观念:
- 完成需求才是正经事
- 系统发生错误的概率很低
但实际上并不矛盾,写测试用例一方面能帮助我们梳理业务逻辑,另一方面能增加验收和变更的底气。
因此我建议在KPI中,对测试耗费的工时,做鼓励。
2.2.2 复杂业务不方便测试
多系统项目,确实存在这个问题。
我的想法是,可以对模块进行分别处理,不一味追求全自动化测试,对于投入产出比不高的模块,进行手动测试。
三、问题&方案&最佳实践
接下来我根据以往线上事故案例,提炼发生的原因,并给出我的解决方案。先来分析造成事故的时机。
3.1 出现事故的环节
- 上线前,常规需求未全部覆盖
- 上线前,边界情况未测试完备
- 访问暴涨或异常代码,导致线上性能瓶颈
- 线上错误不可知,导致错误积累
- 变更时,影响到既有逻辑
我们应该相信每个开发人员都希望自己的代码是完善的,强调责任感通常无法避免问题。
针对这五个环节要求,我们可以采用不同的方式来应对。
3.2 具体措施
-
常规需求的测试覆盖
-
边界情况的完备测试
-
硬件性能监控
-
及时预警
-
变更前的回归测试