从一个影响500w用户的bug到公司测试中所面临问题的思考

鉴于公司近期出现了多起技术事故，如：针对由于需要解决一个业务提出的新需求，则在数据表中增加了一个字段，进而导致新需求程序OK，但老业务的程序出现问题，进而影响到了所有的IM通讯消息。

 

公司管理层认为是一个小的疏忽导致的重大问题，进而推理到技术总监监管不力，只着眼于大的方面，而没有落实在细节上。实际上这种认识是远远不够的，也是不正确的。

 

从我个人的理解上主要有三方面的问题：

1、对现有工程的理解不深入，不了解每个工程细节，即当修改了少量代码后，没有考虑到对调用方的影响；即使在数据表中添加一个stat=0/1，则之前对外提供的接口中都需要添加where stat=0/1的条件，否则必然出问题

 

2、测试不利，即在调整完工程代码后，没有经过详尽的测试就上线了。在工程素养好的公司中，首先要开发工程师来做100%单元测试，即单元测试100%没有问题后，才能进入联调测试，联调测试100%没有问题后，才能上线。而在这件事中，失误有三：1、测试部门没有介入，2、开发部门单元测试的缺失，3、没有联调测试 — 最终导致了重大技术事故

 

3、管理人员的职责缺失，没有盯好项目的开发 + 实施。本质原因是项目开发时间紧张，没有足够时间测试，进而导致项目未经测试就上线，也是测试意识的缺失导致的，而技术负责人测试意识的加强才是我们需要做的

 

小结一下：工程思想中所包含的重要一项是将影响到的调用方考虑完善，而考虑不完善则容易出现问题，尤其是作为账户，IM，订单等通用服务。测试不做到100%，即使是互联网这种高速迭代的公司也要做到。管理人员的测试意识是规避此类问题的钥匙，做到double check，怀疑工程师的开发质量，自己测试一下，用一用，就可以避免此类问题的重复出现。

 

PS：一般的测试流程为：

1、单元测试 — 需要工程师自己做，主要流程包括写测试用例和编写测试代码；

2、联调测试 — 需要开发方和调用方一起做；

3、性能测试 — 可以由开发方和调用方一起做或者由测试部门做，一般需要准备测试数据，测试环境和测试用的脚本；之前2、3步测试最好在公司的仿真环境下完成；

4、（工程上线后的）线上测试 — 由测试部门和开发部门一起做，即模仿一个用户的使用流程（a test case），来测试左右调用方的功能可用，进而验证线上的服务正常。

 

目前在公司内有一个矛盾点，则是业务集团对于需求上线速度的狂热要求和工程本身对于时间要求的冲突。在处理这种冲突的过程中，技术人员往往处于弱势，这就需要技术人员要对公司业务有比较深入的理解，同时当业务需求和工程质量有冲突时做出理性的判断和最优的解决方案。

 

以下就谈下我对当业务需求和工程质量相冲突时如何处理？

1、优先需要将业务需求进行优先级划分：1、能给公司带来大量收款的项目；2、能给公司带来大量流量的项目，3、能提升用户体验的。当然这其中还要区分所带来的收入多少，流量多少按照高低来排优先级。

2、针对1，2一定要安排单元测试，联调测试和性能测试（性能测试如果项目实在比较紧急，可以放在产品上线后夜里测试），主要的原因是在保证了单元测试，联调测试后，主流程不会出现大问题，最多是for循环，if…else…过滤器可能由于设计不合理，进而导致在大流量冲击下会出现问题。但新产品上线后由于一般网站不会存在巨大流量的冲击，且从产品上我们可以通过在管理端设计一个开关来控制；

3、当开发时间较少的情况下，需要及时和测试部取得沟通，及早安排测试计划。针对开发时间已到，并且还没有完成测试的情况下，可以申请1–2天完成用例和测试，以保障项目质量；

4、产品经理要对产品质量负责，即产品经理要对上线前的质量负责，并且需要测试产品主流程。必要时需要将运营，编辑，客服等拉过来一起测试。

5、针对3：能提升用户体验的需求，可以由产品经理和开发工程师一同解决测试，保障主流程不出问题。

 

祝近安，吕思勉

 

2019-8-26