[开发测试]2021-09-29

怎样检查软件质量t?
1、项目的规模。这里可以理解为，项目的规模越大，通常合作的人越多、需要考虑的逻辑越多/越复杂；项目的规模越小，相比之下，开发人员需要考虑的逻辑也比较容易把控。因而，规模较大的项目的提测质量，通常比小规模项目的提测质量要差一些。



2、开发同学的自身项目经验。日常的项目跟进中，对于类似的一些需求，通常经验丰富的开发同学的提测质量会好很多。

3、涉及业务的复杂程度。如果一个业务涉及的模块较多，关联的第三方业务较多，那么无疑这个业务修改时，出问题的概率也会越大。

4、开发周期的长短。开发周期通常需要技术团队来评估，但如果为了赶项目，而压缩开发周期时，通常会给提测质量留下隐患。

上面的因素会直接或间接影响提测质量，但由于这些因素属于客观因素，每个团队、项目都会有所不同，且不太受人为因素的影响，因而这些因素不是本文讨论的重点。那有哪些事情是可以提前做的，来确保提测质量呢？

二、确保提测质量该如何做?

确保提测质量的目标是在提测时，确保项目达到一定的质量水平。因而，抛开那些影响提测质量的客观因素外，我们需要做些事情，来确保提测时的质量水平，让提测质量尽可能逼近上线质量。

1、明确项目流程。这里的项目流程，不仅仅是提测流程，也包括需求评审、测试用例评审、技术评审、风险分析等等，确保项目有任何实现风险、提测风险时，能快速周知到项目成员，方便大家一起齐心协力解决，而不是一个问题的block，直接阻塞的项目的顺利进行。

2、合理的需求评审。这里的需求评审的目标，是力求项目各个角色成员对需求的理解一致、对需求的风险点、影响范围等理解无歧义。避免技术实现与需求不符的情况发生。



详细的用例评审。这里的用例评审，是为了确保场景覆盖，以及再次确认项目各个角色成员对各个需求点理解一致

3、技术评审。QA同学与开发同学一起技术评审，可以提前预防/发现技术设计、技术实现方面的问题

4、静态代码扫描。确保代码的实现规范符合团队要求，保证代码的长期可维护性适时的人工Code Review。这里可以针对代码实现逻辑、规范做具体检查，提前发现问题，也可以使用工具，如sonar等。

5、明确的冒烟用例。冒烟用例是提测前，需要开发同学必须自测通过的用例。冒烟用例最好自动化进行验收，避免因为开发同学执行的问题，导致测试执行不彻底

6、公认的提测流水线。提测时，可以将静态代码扫描、自动化冒烟测试、自动化主流程回归测试进行集成，让开发同学提测前进行自检。

7、QA提前介入测试。QA提前测试本质上已经进行测试了，但由于尚未正式/全面进行测试阶段，因而一定程度上，也可以确保提测质量