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

  影响提测质量的原因有哪些?
  需求不够完善
  项目复杂度高
  涉及多开发的协调问题
  开发人员经验不足
  开发周期紧张
  开发人员自测不充分
  能够改进提测质量的手段有哪些?
  完善的项目流程和过程管理
  充分的需求评审和开发设计评审
  充分的开发时间
  经验丰富且高素质的开发同学
  梦想总是要有的,万一实现了呢?
  但多数情况是:理想如此丰满,现实却很骨感。对于新项目、新产品,基本上是时间紧、任务重、无流程、缺规范。以上条件能剩下什么?即使最后一点,也无法保证每个开发同学都能达标。
  那么要保证开发的提测质量,还能剩下什么方法?只有一条:通过开发自测来保证。
  而通过开发自测来保证提测质量这件事情,在我看来主要有两个关键因素:1.覆盖度;2.执行力。
  覆盖度
  跟确保产品质量依赖测试覆盖度一样,开发提测质量与自测case的覆盖度紧密相关的。但用户提测的自测case肯定不等同于正式测试的测试用例,那么该如何定义自测case呢?
  自测case应该由测试同学提供。
  开发同学提测后的接收方是测试同学,提测质量直接影响测试同学开展工作,因此自测case理应由测试同学给出。
  自测case的标准如何?
  要保证该模块需求中要求的功能是否正确实现。
  要保证该模块主要功能逻辑、主流程主路径能否正常运行。
  要保证和该模块耦合度较高的模块,没有明显异常。
  要保证自测case通过后,不会有大块的测试用例无法执行。(例如某个逻辑有30条测试用例需要执行,那么这个逻辑的生效性验证就需要加入自测case;如果某个逻辑只有2~3条测试用例需要执行,那么这个逻辑的生效性验证就可以考虑不用加入自测case)
  可以考虑在自测case中,增加一些测试认为容易出现bug的路径。这个事情需要依赖测试经验的积累。
  规定开发同学自测的环境、测试方法、版本等内容。让开发同学自测时满足测试同学的预期,避免产生不必要的问题。可能出现的场景例如:
  开发自测时使用的是本地环境。
  开发自测只对自己的接口测试,而不是整个真实的环境串联起来测试。
  开发使用debug版本自测而不是release版本自测。
  自测case的执行要保证通过提测的版本进行,不能使用接口测试。必须得带着前后端一起测试。整体测试。
  针对质量较差的开发,可以增加自测case的数量级。如果某些开发同学的提测质量一直不高或者bug较多,可以在给他的自测case中多增加一些内容。但这么做之前需要跟开发同学或开发leader达成共识,这个过程中可以通过以下方式作为说服对方的辅助手段:
  开发同学提测质量低的实际案例。
  开发同学负责的模块bug数量多的案例。
  执行力
  即开发同学自测时的执行力。这点,我们其实没办法保证,测试同学控制不了,也管理不了开发的行为。但这不意味着我们什么都不能做。可以用采用以下几种辅助方式:
  通过提供自测case的格式,约束开发同学的行为。比如在自测case中,加入明确的测试结果一项,让开发回复时必须填写是否通过。
  通过邮件公示的方式,约束开发同学的执行力。开发的提测邮件中必须@开发leader、@项目负责人或@老板。
  针对提测质量较差的开发同学或新加入的开发同学,在其提测后增加测试验收环节,确保开发同学自测到位。这过程发现实际效果与开发自测的反馈结果存在差异,需要及时反馈,当然需要@上一条中的那些能够管控开发同学的负责人。
  如果提测时涉及多名开发同学(如需要前后端交互),那么需要约定好主负责人,自测由该主负责人进行,避免提测出现问题时各种扯皮。
  除上述两方面外,我们还可以通过引入其他方验证(如产品、交互、设计)的流程,然后再提交到测试环节,这样能够很有效的提升提测质量。
  虽然有上述心得的总结,但仍有一种情况是目前无法有效解决的,即:提测质量无法达到预期(甚至很差),但上线时间固定,因此无法按流程将提测打回,让开发同学进行二次开发然后重新提测。这种情况下,仍然在大量的占用测试时间,压缩测试工期。希望有好方法的同学们能够分享自己的解决方案。