点击👆蓝字 关注我们
导语
本文旨在分享使用源代码静态检查工具的实践经验(如规则制定、报告解读),以及如何在组织中开展这类工具的推广应用。你将会了解这类工具的概念模型、规则的制定策略以及如何有效地使用。
本文讨论的概念范畴
自编程诞生以来,开发团队就在和缺陷(BUG)做斗争。一个个工具发明出来以期提前发现缺陷。从编译器内置的告警到独立的工具,各具特色。这类工具统称为 “静态/动态分析服务”(software static/dynamic analysis service,ISO/IEC 15940:2013)。
该服务有6项功能:从软件模块和(或)部件收集原始统计数据;计算软件模块、部件的复杂性测度;产生图形化表示交叉引用表;从软件模块和(或)部件的动态执行中收集原始统计数据;产生图形化表示执行行为的特性;按照预定义的模板或规则检查代码输出发现的结果(来源:GB/T 30972-2014)。
本文中主要关注其中的静态分析服务、测度、规则、报告,简称为检查工具、规则。
从软件测试的角度来看,代码评审以及使用静态分析工具发现缺陷是静态测试活动。是保障软件质量而必须做的。
为能做好静态测试,必须要制定合适的规则、规范,开展合理的推广应用,才能让检查工具发挥最大的价值。下面就从「规则的制定」、「工具与规则的应用」两大方面展开,同读者朋友分享我们最新的可落地实践。
有条不紊:制定代码检查规则的要点
先澄清一些概念。如图1,检查工具装载规则集,接着扫描源代码或编译产物,最后分析并输出执行报告。
图1-检查工具的概念模型(体现各种概念间的关系)
规则集由多个规则组成。一个规则可以定义为源代码中的某种检查点。如果工具在分析源代码时发现与某规则匹配,则向执行报告中添加一个议题(issue,也有称之为问题的),用以说明源代码中什么地方违反该规则。规则和议题是1对多关系。规则可以带参数,例如每一行所允许的最多字符数是可调整的。
规则有两个主要特征:分类(type)和优先级(priority或severity)。分类是指问题类型,例如可能的缺陷、安全风险、代码格式等。优先级则是重要程度,常见、5级或3级,例如:重要、一般、次要。
执行报告包含多项议题。每个议题同样会有分类分级参数(继承自规则)和其他属性,如引入时间、作者、在源文件中的位置、状态、处理措施等。
一、按照技术栈特征来制定规则集,不限于一