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

一、背景

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

二、共识与固有观念

2.1 共识

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

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

这样保证，

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

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. 变更前的回归测试