为了让大家在使用Logiscope测试实际的项目时,能够有所依据和参考,进而提高该工具的使用效率,制定了本应用方案。
本应用方案描述了使用Audit和RuleChecker的过程,并给出了最后提交的测试报告的模版供参考。
通过Audit对软件进行质量监控,能确实的提高软件质量,但这项工作比较耗费时间和精力,所以如果决定要做,就要认真对待。如果匆忙、潦草的进行,会感觉既浪费时间,又没有明显的效果。
2.1 Audit的功能
Audit有两项功能——质量监控和程序分析。
2.1.1质量监控
对于Audit质量监控这项功能,现在还不能使其最充分的发挥作用。我们现在可以做的是:依照Audit自身提供的质量模型,对软件的质量进行监控。
2.1.2程序分析
除了进行质量监控外,Audit还可以提供程序的内部实现信息,包括每个函数(成员函数和非成员函数)的控制流程图、调用关系图,每个类的继承关系图、使用关系图。通过这些信息,可以帮助我们了解程序的内部实现。
Audit的这项功能,对于进行单元测试阶段的代码审查能发挥比较好的作用。可以先通过Audit定位那些较为复杂的函数、类,然后进行小组形式的代码人工走查,重点检查这一部分的代码,因为通常情况下这样的代码容易出现问题。
2.2实际应用
下面说一下Audit在实际中的应用。分三种不同的情况:
2.2.1对于跟踪全过程的项目
对于这样的项目,Audit可以发挥比较好的作用。工作阶段如下:
1 在项目初期,提出对该项目的质量要求,决定选用Audit作为检测工具。
2 在概要设计之前,对开发人员做软件质量方面的培训,告知对该项目的质量要求。
3 在编码的过程中,测试人员通过Audit来检验函数、类等模块是否达到质量要求。如果与质量要求相差较大,开发人员进行修改。
4 当组装成子系统时,给出子系统的质量报告,如果与质量要求相差较大,开发人员进行修改。
5 对于那些最后质量评价仍然很低的函数、类等模块,可对其进行小组形式的人工代码走查,确定这些代码的正确性。
6 在确认阶段,通过Audit来评价产品的质量,给出整个系统的质量报告。根据质量评价的结果、修改的难度,权衡是否需要进行修改。
严格的说,只有3、4才完全是测试人员的任务,在其他的阶段,我们只是参与者之一。但由于公司目前的情况,可能其中大部分的工作都要由我们来做。
下面给出在这个过程中,需要提交的测试报告的模板:
第3阶段需提交的测试报告的模板——《模块质量检测报告模板》;
第4阶段需提交的测试报告的模板——《模块质量检测报告模板》或《系统质量检测报告模板》。
第6阶段需提交的测试报告的模板——《系统质量检测报告模板》;
2.2.2对于只做最后的确认测试的项目
首先要说明的是,对于只做确认测试的项目,用Audit的意义不是很大,唯一的作用是通过Audit对系统做一下质量评价。但无论评价的结果是好是坏,进行修改的可能性已经不是很大了。
在这个过程中,需要提交的测试报告的模板——《系统质量检测报告模板》。
2.2.3对于进行维护的项目
如果是对原有项目进行维护:可以通过Audit来检测被维护软件的质量,估算出进行维护工作的难度,从而更好的计划维护工作。
对于那些质量已经得到保证的产品,可以通过Audit来监督项目的维护工作,使其质量不致后退。
2.3其他
在使用Audit对项目进行质量监控时,不要忘了为被测项目制作Audit质量模型文件(Logiscope.ref)。
3 关于RuleChecker的应用
RuleChecker应用过程:
1 在项目开始之初,要求开发人员、测试人员遵从《北京许继编码规范》中对编码的规范要求。
2 按编码规范要求,从RuleChecker 的编码规则/规范集中挑选出适和的规则/规范,编写RuleChecker规则文件(RuleChecker.cfg)和对应的Audit质量模型文件(Logiscope.ref)。
3 编写出RuleChecker可用规则列表,列出RuleChecker规则与《北京许继编码规范》中各条规范的对应关系。
4 在开发过程中,测试人员通过RuleChecker对代码进行编码规范的自动化检查,报告不符合规范的地方,开发人员进行修改。(报告格式请参见《编码规范检测报告模板》)
RuleChecker现在存在问题,用其他覆盖率统计工具代替。
5 结束
Logiscope的使用过程并不局限于此文档中描述的内容。大家在实际应用Logiscope的过程中,当有特殊的需要时,可对该使用方案进行裁剪。如果发现某些情况比较普遍,可以补充到该方案中。