2.2 静态测试
静态测试指不运行被测程序本身，而通过分析或检查源程序的语法、结构、过程、接口等检查程序的正确性。静态测试中的被测对象是各种与软件相关的有必要进行测试的产物，这些被测对象包括了软件需求规约、软件设计说明书、源程序的结构、流程图、符号等。静态测试从这些被测对象中找错。静态测试可以手工进行，充分发挥人的思维优势，并且不需要特别的条件，容易展开，但是对测试人员的要求较高，至少要求测试人员具备编程经验。
静态测试主要包括各阶段的评审、代码检查、程序分析、软件质量度量等，用于对被测程序进行特性分析。其中，评审通常由人执行；代码检查、程序分析、软件质量度量等既可人工完成，也可使用工具完成，但工具的作用和效果相对更好一些。
从上面可以了解到代码检查是静态测试中的关键步骤之一。代码检查包括代码走查、桌面检查、代码审查等，主要检查代码和设计的一致性，代码的规范性、可读性，代码的逻辑表达的正确性，代码结构的合理性等方面通过代码检查，我们可以发现违背程序编写标准的问题，程序中不安全、不明确和模糊的部分，找出程序中不可移植的部分、违背程序编程风格的问题。代码审查包括变量审查、命名和类型审查、程序逻辑审查、程序语法审查和程序结构审查等内容。
代码检查不需要任何自动化服务就可以通过代码扫描完成。整个过程都按照预定义的规则完成，只须针对不同的编程语言设计好不同的规则即可。如果能在一个工具中完成代码检查，那么测试人员可以完全不参与，这是一个完全自动化的流程。这也导致了通过代码扫描完成的代码检查工作只是对代码预定规则的检查，并不能保障其编写逻辑符合预期设计。如果预定规则不合理，那么代码扫描结果的偏差会很大。
从上述内容可以看出，代码扫描既有优越性也有弊端。如果使用好的开放性工具完成代码扫描，通过修订并选取合适的规则是可以达到质量保障的预期的。可用的代码扫描工具并不多，如果站在平台化、服务化的角度，并且兼顾CI流水线的需求，比较重要的工具就是SonarQube。
很多测试工程师遇见过以下情况：项目开发时间紧张，交付压力大，为了不延期交付，项目在排期过程中总将各个里程碑时间定义好，确定何时提测，何时执行用户验收测试，何时验收，如果没有按约定完成，就要有一定的惩罚措施。
而到了约定好的提测时间，开发工程师为了能够完成其里程碑，即使自测并不完善，也会提测，当测试工程师部署好测试环境并开始测试时，会发现没有一个业务流程很顺畅，只能重新修复版本，但是开发工程师顺利完成了自己的里程碑。很多时候，我们对这种事情敢怒不敢言，怕引起团队的矛盾，影响项目进度。
这种情况下，我们可以利用SonarQube完成代码扫描，这是一个有效提高提测代码质量的方法。SonarQube是按照设计好的代码规范来检查被测系统的源代码的规则符合性的。SonarQube引入流程如图2-3所示。
图2-3 SonarQube引入流程
首先，与团队的技术负责人、架构师一起确定团队需要遵从的代码规范，这一般由技术负责人主导，但是很多时候测试工程师会作为技术落地推广的主力参与。这里大部分团队会选择一些开源规范（如P3C规范）作为起点，然后在工程实践中不断修正和完善，注重维护一套符合本公司要求的代码规范。
团队一旦确定SonarQube的测试报告没有缺陷、没有漏洞，就可以确认提测规范了。
最后，约定惩罚措施。设计规范很容易，让人遵守规范就很难。为了落实提测规范，要对不遵守规范的人进行惩罚，并加入每一位开发工程师的KPI中，从而约束大家都按照约定完成代码扫描。
