hogwarts
(霍格沃兹测试学院官方)
1
前提
- 最重要的一个前提：任务被拆解前，需求是明确的。
- 什么样的需求是明确的需求呢？这是一个不小的问题。有一个很好的验证方法：这个需求是否可以写出来代入数据和步骤的测试用例。强烈推荐《实例化需求》这种实践方式，这是一个大话题，需要单独来说。
- 确保工作量是可完成的，而不是 overload 的。对于团队生产力的估算能力，提高的最好的方法就是不断的总结上一个迭代产出了什么。
- 越忙的时候，越要保证这两个前提，因为它本质上可以帮助你提升效率。
分工 & 步骤
- 拆解的时候一定考虑可测性。在初期，QA 一定要与开发就可测性达成统一认知。
- 任务分解后，除了开发，需要并行开展的工作是：测试案例编写。最好的实践方法是《实例化需求》方法，骨架的验收测试用例在开发前就作为需求 Ready 了。
- 如果没有采取《实例化需求》，则应该马上开始发起测试案例编写工作，保证在 " 提测 " 之前，骨架测试案例是具备的。
- 案例应该分级，如 P0，P1，P2。P0 是冒烟测试，P1 覆盖最核心，一定要保证的功能。P2. 是优先级略低的案例。
- 开发应该充分利用上条提到的测试案例，最低要求是 P0 一定要全部通过，一个比较理想的状态是 P1 全部通过。
- 案例自动化能够同期开发是最好的。在 “提测” 的时候，所有测试案例都是自动化案例的话，测试执行就会变得非常快，通常一日内可以搞定，提测的轮次会大幅度减少，大概率会一轮过，因为在自动化案例开发和调试的同时，就已经在做测试了。而 QA 可以花时间来做更多的异常情况的思考和探索性测试，发现隐藏的很深的问题。
技术上的难点
- 如果是主干开发的分支策略，feature 之间的解耦是至关重要的。feature 开关是开发中必不可少的东西。
- 任何一个新 feature，在开发完成前， 默认是关闭的 。这样可以保证合入代码不影响他人的工作，不影响主干的发布能力。
- feature 开关不能解决所有问题，但如果设计很好，feature 开关可以解决绝大部分问题。仍然有其它方法可以解决 feature 开关解决不了的问题，如代理层，如抽象分支（branch by abstraction）等。
- 同期自动化建设是非常难的事情。可以逐步实现，对应的 tips 如下：
- 自动化一定是分层的， 测试金字塔 的理论是这么多年来，测试界被极少被证实了的极为正确的理论之一。
- 单元测试作为最底层，一定要做到同期建设，这是最基本的要求。如果达不到这个要求，则很难在并行开发的模式下快起来。
- 单元测试说着容易，但是全研发级别变为标准十分的难。特别在国内的大环境下，转型需要非常多的努力。
- 接口层面的自动化建设，应该有完备的工具链来大幅度缩减实施时间。接口自动化最花时间的三样东西：1. mock 的编写。2. 入参的编写。3.assert 的编写。
- 目前来看，录制回放类工具是最能提效的，它可以大幅度降低这三部分的成本。并且可以把开发调试阶段的成果记录下来变成自动化用例。很可惜的是，市面上完备的通用工具很少，只在大厂有相对成熟的应用。举个例子，在 Java 的 Server 端技术栈，目前开源的 JVM-sandbox-repeater 是一个不错的脚手架，可以在它的基础上做二次开发（大量的二次开发）实现。
- 在有好工具支撑的基础上，接口自动化案例的建设，QA 和开发的良好协作是基础。没有好的协作，有工具也不行。
- 端到端的自动化案例也推荐录制回放工具，分层 mock，各司其职，并且保证稳定性。
为了保证代码质量， CR 是重中之重 ，必须做好。
- CI 流水线也需要比较完善。一个明显的检查点是：1. 是否有有效的静态代码和单元测试卡点。2. 接口自动化是不是也放到标准 CI 流程里面去了。
收益
- 真正做到了，系统测试会非常快（一天内）。
- 基本上具备了每天发版的能力(这可以看成一个比较高的目标) 。