目录
前言
前面的文章介绍过如何设计自动化测试case,有同学在后台问到:业务比较复杂,有很多串行并行甚至组合的业务场景,执行case时经常遇到由于前后依赖导致的case失败问题,该如何处理?
当业务复杂度和工作量上来之后,在具体的实践中这是个避不开的问题。那如何解决这个问题?我建议可以通过按照业务和场景区分用例集合的方式来解决。
业务量和复杂度增长现状是什么?
以我的亲身经历而言,当业务爆发式增长时,测试团队会面临如下几点变化和调整:
对比项 |
业务增长前 |
业务增长后 |
团队组织架构 |
大团队 |
大团队小team,按照业务域划分不同小团队 |
团队协作方式 |
互相协作,沟通成本低 |
跨team协作频次变高,构成成本高 |
团队技术栈构成 |
比较单一,学习和迁移成本低 |
技术栈多样,学习和迁移成本高 |
测试case覆盖率 |
只覆盖核心场景,保证主流程正向流程 |
PO/P1/P2场景,正向逆向场景都覆盖 |
测试人员职责划分 |
每个人都熟悉整体业务流程和场景 |
每个人只熟悉岗位职责 |