快速迭代中,如何保证稳定可用

黄鹏宇 106 2023-10-18

一、背景

业务侧层出不穷的需求,要求我们快速迭代,但这一切的基石是系统的稳定性。

二、共识与固有观念

2.1 共识

我们接到一个新需求后,首先须理解业务,然后与需求方明确业务,这占据整个开发周期中较大耗时。
通常在这个阶段,产品经理会形成需求文档,但往往由于系统功能太多,文档篇幅太长,我们不会一一确认,导致需求文档不具备执行约束
image-1697594247636

因此我提倡,在开发阶段使用测试先行策略,也就是由开发人员根据需求文档,提前写出测试用例,明确验收标准
image-1697594314032

这样保证,

  1. 开发的功能和需求是对齐的
  2. 方便验收
  3. 写测试用例的过程中,可以提出各种边界情况,方便编码时提前处理。

image-1697591745902

2.2 固有观念

我们都知道测试很重要,但为什么一直没做?我认为与以下几个固有观念有关:

2.2.1 浪费时间

侥幸和kpi让我们产生错误观念:

  1. 完成需求才是正经事
  2. 系统发生错误的概率很低

但实际上并不矛盾,写测试用例一方面能帮助我们梳理业务逻辑,另一方面能增加验收和变更的底气。
因此我建议在KPI中,对测试耗费的工时,做鼓励。

2.2.2 复杂业务不方便测试

多系统项目,确实存在这个问题。
我的想法是,可以对模块进行分别处理,不一味追求全自动化测试,对于投入产出比不高的模块,进行手动测试。

三、问题&方案&最佳实践

接下来我根据以往线上事故案例,提炼发生的原因,并给出我的解决方案。先来分析造成事故的时机。

3.1 出现事故的环节

  1. 上线前,常规需求未全部覆盖
  2. 上线前,边界情况未测试完备
  3. 访问暴涨或异常代码,导致线上性能瓶颈
  4. 线上错误不可知,导致错误积累
  5. 变更时,影响到既有逻辑

我们应该相信每个开发人员都希望自己的代码是完善的,强调责任感通常无法避免问题。
针对这五个环节要求,我们可以采用不同的方式来应对。

3.2 具体措施

  1. 常规需求的测试覆盖

  2. 边界情况的完备测试

  3. 硬件性能监控

  4. 及时预警

  5. 变更前的回归测试