推进开发改进提测质量的一点心得和思考

不知道各位测试同学是否被开发同学的提测质量困扰过？在经历了一个版本800多个bug，原计划一个月测完，结果测了2个半月的痛苦经历之后，对提测质量的把控进行了一定的思考。

影响提测质量的原因有哪些？

1. 需求不够完善
2. 项目复杂度高
3. 涉及多开发的协调问题
4. 开发人员经验不足
5. 开发周期紧张
6. 开发人员自测不充分

能够改进提测质量的手段有哪些？

1. 完善的项目流程和过程管理
2. 充分的需求评审和开发设计评审
3. 充分的开发时间
4. 经验丰富且高素质的开发同学

梦想总是要有的，万一实现了呢？

但多数情况是：理想如此丰满，现实却很骨感。对于新项目、新产品，基本上是时间紧、任务重、无流程、缺规范。以上条件能剩下什么？即使最后一点，也无法保证每个开发同学都能达标。

那么要保证开发的提测质量，还能剩下什么方法？只有一条：通过开发自测来保证。

而通过开发自测来保证提测质量这件事情，在我看来主要有两个关键因素：1.覆盖度；2.执行力。

覆盖度

跟确保产品质量依赖测试覆盖度一样，开发提测质量与自测case的覆盖度紧密相关的。但用户提测的自测case肯定不等同于正式测试的测试用例，那么该如何定义自测case呢？

• 自测case应该由测试同学提供。 开发同学提测后的接收方是测试同学，提测质量直接影响测试同学开展工作，因此自测case理应由测试同学给出。
• 自测case的标准如何？
  1. 要保证该模块需求中要求的功能是否正确实现。
  2. 要保证该模块主要功能逻辑、主流程主路径能否正常运行。
  3. 要保证和该模块耦合度较高的模块，没有明显异常。
  4. 要保证自测case通过后，不会有大块的测试用例无法执行。（例如某个逻辑有30条测试用例需要执行，那么这个逻辑的生效性验证就需要加入自测case；如果某个逻辑只有2~3条测试用例需要执行，那么这个逻辑的生效性验证就可以考虑不用加入自测case）
  5. 可以考虑在自测case中，增加一些测试认为容易出现bug的路径。这个事情需要依赖测试经验的积累。
• 规定开发同学自测的环境、测试方法、版本等内容。让开发同学自测时满足测试同学的预期，避免产生不必要的问题。可能出现的场景例如：
  1. 开发自测时使用的是本地环境。
  2. 开发自测只对自己的接口测试，而不是整个真实的环境串联起来测试。
  3. 开发使用debug版本自测而不是release版本自测。
  4. 自测case的执行要保证通过提测的版本进行，不能使用接口测试。必须得带着前后端一起测试。整体测试。
• 针对质量较差的开发，可以增加自测case的数量级。如果某些开发同学的提测质量一直不高或者bug较多，可以在给他的自测case中多增加一些内容。但这么做之前需要跟开发同学或开发leader达成共识，这个过程中可以通过以下方式作为说服对方的辅助手段：
  1. 开发同学提测质量低的实际案例。
  2. 开发同学负责的模块bug数量多的案例。

执行力

即开发同学自测时的执行力。这点，我们其实没办法保证，测试同学控制不了，也管理不了开发的行为。但这不意味着我们什么都不能做。可以用采用以下几种辅助方式：

• 通过提供自测case的格式，约束开发同学的行为。比如在自测case中，加入明确的测试结果一项，让开发回复时必须填写是否通过。
• 通过邮件公示的方式，约束开发同学的执行力。开发的提测邮件中必须@开发leader、@项目负责人或@老板。
• 针对提测质量较差的开发同学或新加入的开发同学，在其提测后增加测试验收环节，确保开发同学自测到位。这过程发现实际效果与开发自测的反馈结果存在差异，需要及时反馈，当然需要@上一条中的那些能够管控开发同学的负责人。
• 如果提测时涉及多名开发同学（如需要前后端交互），那么需要约定好主负责人，自测由该主负责人进行，避免提测出现问题时各种扯皮。

除上述两方面外，我们还可以通过引入其他方验证（如产品、交互、设计）的流程，然后再提交到测试环节，这样能够很有效的提升提测质量。

虽然有上述心得的总结，但仍有一种情况是目前无法有效解决的，即：提测质量无法达到预期（甚至很差），但上线时间固定，因此无法按流程将提测打回，让开发同学进行二次开发然后重新提测。这种情况下，仍然在大量的占用测试时间，压缩测试工期。希望有好方法的同学们能够分享自己的解决方案。