开发才是质量的创造者

最近参与两周测试的工作，和测试的伙伴学习，了解测试的流程，看看有什么可以改进的地方。除了流程方面的东西，我想从开发的角度讲讲，如何才能做的更好。希望以后在和测试沟通的过程中，能少一些阻碍，多一点顺畅。

开发即测试

• 质量不是被测试出来的
• 开发人员对自己的代码负责
• 比专职的测试人员更适合测试
• You build it, you beak it, your fix it.
• 质量是开发过程的问题，而不是测试问题
• 责任在开发，而不是测试

质量肯定不是被测试出来的，而是开发者对代码的质量负责。由于开发对自己的代码非常熟悉，对代码的业务逻辑熟悉，对代码可能抛出的异常熟悉，因此还有谁比实际写代码的人更适合做测试呢？你自己写的代码，你自己找到漏洞，然后修复它。

测试不是独立隔离的活动，它本身就是开发过程的一部分。在我们日常开发的过程中，就应该时刻测试。如果某个产品出了问题，第一个跳出来的肯定是导致这个问题发生的开发人员，而不是遗漏这个bug的测试人员。如果有质量问题的话，大家一般会说开发写的真烂，而不是测试测的真烂。代码质量就是编程人员的声誉。

提升开发质量的工具

• 基本功能测试
• 代码评审
• 静态代码分析（IDE、SonarLint、FindBugs）
• 单元测试
• 基础性能测试（页面响应速度、SQL执行、接口响应时长）
• 持续集成

实际开发中，有很多工具可以帮助我们避免一些问题。

正常情况下，大家都会把基本功能测通，然后提交代码。不正常的情况下，就不会测试，直接提交了。哪些不正常的情况呢？最常见的应该就是改动很少的情况。有时候只是添加或者修改一个字段，或者只是多了条件判断之类的修改。非常有信心，肯定不会有问题，再加上测试需要造数据，可能还需要启动多个服务，就懒得测试了。然后提交，后来一测试，就发现了问题。

代码评审很重要。通过代码评审，可以避免一些明显的逻辑错误，可以更加规范代码，提高代码质量。我们工作很大一部分就是编程，而代码评审就是拿代码沟通，相互学习的绝佳途径。

代码评审还可以指导新人，对不熟悉项目代码结构的新人有很大的帮助，而且也能帮助他们熟悉一些业务逻辑。

哪些代码最需要评审呢？

第一人写的新模块，因为之后要是有相同的模块，可能直接就复制这个模块，然后再修改。因此，需要仔细评审新模块的代码结构、规范、功能，甚至是日志。

刚入职的新人开发的功能，需要评审。因为他们对业务或者代码结构还不熟悉，可能在开发过程中忽略一些要注意的点。通过这个评审，也可以增加新人对代码和业务的熟悉度。

核心的逻辑需要评审。有些业务逻辑比较复杂，或者设计到线程安全的问题。可能自己心里都没谱，那就需要拿出来让大家一起看看啦。

而且很多时候，给大家讲自己代码的过程中，很可能自己就发现可以优化的地方。在开发过程中，需要有优化的地方，但自己懒得修改，比如说刚开始写了一个很长的方法，懒得拆分。在代码评审的时候，就不好意思了。

开发这么多工具，又要自己保证代码的质量，那是不是就不需要测试了？肯定不是这样啦，我们就来看看测试的必要性。

测试的必要性

• 开发总会有疏忽和失误
• 开发和测试的侧重点不同
• 开发和测试的范围不同
• 未经测试也不可能开发出有质量的软件

首先，开发总会有疏忽和失误，而这些疏忽和失误，就需要测试去发现和弥补。另外，我们开发的大部分精力在代码质量的提升和测试覆盖率的增加上面。而测试应该花费大量时间在模拟用户的使用场景和自动化脚本的编写上。在用户模拟的场景上面，他们会考虑更多更全面。

而且他们测试的范围，比开发更广。可能在开发的过程中，我们只是测试自己的开发的某个模块，而他们测试是整个软件的所有模块，甚至是多个组件，多个系统之间的联合测试。还有安全测试，防攻击测试，边缘测试等。

在他们范围更广，深度更深的测试下，才能保证整个系统的稳定运行。所以说，未经测试也不可能开发出有质量的软件。

既然需要有测试，接下来就来看看测试的构成。

测试构成

• Test Strategy：比如说应该怎么完成测试任务，需要进行哪些测试，是否需要进行压测，安全性测试等等，测试着重点等
• Testing Plan：制定测试计划，包括测试时间，测试需要的人员，测试用例，测试报告需要多久才能完成
• Test Cases：测试用例
• Test Data（数据的有效性，影响测试结果的有效性，如果有关联，更难造数据）
• Test Environment

上面的每个方面，都有很多相关的软件帮助完成任务。

对开发的要求

• 充分的自测

最后，谈一下开发如何做，才能让测试流程更加顺畅？

再次重申，警惕小的修改。万一bug进入测试阶段，就比较耗时耗力了，因为要经过测试，然后提交给开发，然后开发再去复现，去 debug，然后去解决，提交后测试再次进行测试。

Leaving obvious bugs in the code isn’t going to do your reputation any good either. “A developer who doesn’t find the obvious defects is never going to shine,” continued Markov. “Developers need to produce working software that’s easy to use. No one wants developers that only do pure coding. What helped me to develop my career was the fact that I always invested more time in designing, reviewing, and testing my code than in actually writing it.”

• 文档是沟通的基础

文档是开发和测试沟通的基础，好的文档，可以方便沟通，也方便交给其他人维护。要不然的话，只能是一遍遍地口头阐述，增加沟通成本。我觉得这一点也是最不容易做好的：

1. 因为站在开发的角度写文档，可能有些地方很理所当然，然后就没有在文档里面体现。造成文档不够详细，许多过程需要脑补；
2. 文档更新不及时，或者直接从其他地方复制过来的数据，造成不一致；
3. 文档也可以有一定的深度。比如说需要做什么步骤，最好顺带解释一下，更方便测试理解业务。

• 日志是定位的必要

然后是日志。日志既不能打印的很详细，要不然会泄漏系统或者用户的一些信息，又不能打印的太简单，要方便定位排查问题。

平常开发的时候，我们直接代码 debug 排查错误，往往忽略了日志的重要性。其实，我们可以这样试试看，就是直接看自己写的日志，能不能找到问题。

测试在测的过程中，除了看软件运行是否正常，数据库是否正常，然后就是看日志对不对了。

另外，在现场部署的时候，日志也是非常重要的排查问题的手段。我之前曾经去过好几次现场部署软件，有问题的时候，有时候也不太清楚涉及数据库的哪些表或者涉及哪些字段，要想定位问题，首先就是看日志。要是看到日志只有个异常的栈信息，或者就是简单提示"业务逻辑运行异常”，那真是相当无语。

• 配置文件简单明了

最后再来说说配置文件。目前我们开发的程序，基本上都有配置文件。有些配置文件可能有几百个配置项。

首先，配置项的作用有注释么？这些配置项可以配置哪些内容有提示么？我觉得配置项要是太多的话，直接整理一个文档说明每个配置项也很有必要。

另外，看到有几百行的配置文件也是非常恐怖的，有些配置甚至很少变动。这个时候就要克制住什么都想写到配置文件的冲动。更多的配置，意味着容易犯更多的错误。

或者，如果配置太多的话，是否可以考虑将配置文件分类，这种场景下使用 A 配置，那种场景下使用 B 配置。

试想，如果他们看文档很费劲，需要和开发沟通多次才弄明白。部署的时候，很费劲，那么多配置文件，也不知道修改哪一个？不知道设置哪些值？

出现问题了，本来可能是数据源的问题，可是日志不清晰啊，看不出来什么问题。然后又丢给开发。然后开发看了下日志，找不到问题，然后默默地去debug，最终发现数据源有问题。

这整个过程中，不仅是测试耗时耗力，开发也需要配合，中断当前的开发任务。

我想我们可以达到这样的境界。

测试有哪点不清晰的地方，我们直接说看啥啥文档。

测试发现一些明显的问题时，我们可以对自己的代码质量有把握，说不可能啊，是不是你数据源有问题。

测试发现一些比较潜在的问题时，我们可以通过日志快速定位到问题。

总之，我们处于测试的上游，只有我们做的好，他们的工作才能做的更好。

参考

1. 5 key software testing steps every engineer should perform
2. How To Get Started With Software Testing