为了让大家在使用
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的过程中,当有特殊的需要时,可对该使用方案进行裁剪。如果发现某些情况比较普遍,可以补充到该方案中。