研发测试高级篇

高级篇"/>

研发测试高级篇

一、测试团队的弊病

 1、片面强调流程

           流程能解决一部分问题，不能解决所有问题，还是应该找到根本的解决方案。

目前越来越多的项目组，在业务比较成熟了以后，为了“减少”/"规避"上线后的故障，采用增加流程审批的方案：

各种修改的审批

各种review的增加

小到一行代码的改动，大到一两个月的项目，统统走相同的流程。结果造成流程也就变成了所谓的流程，大项目不能通过其控制风险，需要快步走的小项目处处束手束脚。

2、业务耦合严重

          上下游业务区分不明，导致经常发生故障(所以耦合十分紧密的业务，十分适合在一个团队以上进行；团队是否能cover整个业务，如果不是，还要对整个业务质量负责，显然是不合适的。

          比如，亲身经历过的一个业务，大致依赖关系： 数据仓库(团队A)-->数据筛选排序(团队B)-->用户下单(团队A)

测试依赖关系：数据仓库的N多个场景(团队A负责)-->数据排序的M多个场景(团队B负责)-->影响之后的下单显示(团队A负责)

团队B，不清楚数据仓库逻辑，导致常常找团队A造数据；

团队A，不清楚负责的数据如何展示，导致数据场景覆盖不全

结果：团队A数据仓库问题导致的故障，却要和团队B扯皮，为什么没有测试出来；

3、缺少上线前演练

        线上故障中有关配置修改错误导致的故障常常会发生，特别在广告搜索、策略算法业务中，大约 占比30%(实际项目中得出的数据)。大多数针对此问题