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