RuleChecker 预定义了50 个的编程规则：名称约定(如：局部变量用小写等);表示约定(如：每行一条指令); 限制(如：不能用GOTO 语句，不能修改循环体中的计数器等)。用户可以从这些规则中选择，也可以用Tcl 、脚本和编程语言定义新的规则。此外，还提供50 个面向安全-关键系统的编程规则。
Audit 以ISO9126 模型作为质量评价模型的基础。质量评价模型描述了从Halstend 、McCabe 的度量方法学和VERILOG 引入的质量方法学中的质量因素(可维护性、可重用性、等)和质量准则(可测试性、可读性、等)。
工程项目领导或质量管理人员可以根据准则、应用软件的生存周期、合同需求等，挑选并采纳适用于项目需求的质量模型。
验证、评审和改进代码
RuleChecker 用所选的规则对源代码进行验证。指出所有不符合编程规则的代码，并提出改进源代码的解释和建议。RulrChecker 通过文本编辑器直接访问源代码并指出需要纠正的位置。
Audit 将被评价的软件与规定的质量模型进行比较，用图形形式显示软件质量的级别，因此，质量人员可以把精力集中到需要修改的代码部分。对度量元素和质量模型不一致的地方作出解释并提出纠正的方法。
2)LOGISCOPE 用于测试阶段
定义测试准则
LOGISCOPE 推荐对指令(IB)、逻辑路径(DDP)和调用路径(PPP)的覆盖测试。此外对安全-关键软件还提供了MC/DC 的覆盖测试。
测试的有效性
TestChecker 产生每个测试的测试覆盖信息和累计信息。用直方图显示覆盖比率，并根据测试运行情况实时在线更改。随时显示新的测试所反映的测试覆盖情况。
TestChecker 允许所有的测试运行依据其有效性进行管理。用户可以减少那些用于非回归测试的测试。
测试的优化
在测试阶段的第一步，执行的测试是功能性(黑箱)测试。其目的是检查所期望的功能是否已实现。在测试初期，覆盖率会迅速增加。象样的测试工作一般能达到70%的覆盖率。但是，要提高此比率是十分困难的。主要是由于测试用例覆盖了相同的测试路径。这时，需要对测试策略做一些改变。执行结构化(白箱)测试，即，要检测没有执行过的逻辑路径，定义新的测试用例覆盖这些路径。
在执行测试期间，当测试策略改变时，综合的运用TestChecker 检测关键因素以提高效率。将TestChecker与Audit 配合使用能够帮助用户分析未测试的代码。
用户可以显示所关心的代码，并通过对执行未覆盖的路径的观察得到有关的信息。信息以图形(控制流图)和文本(伪代码和源文件)的形式提交，并在其间建立导航关联。
文章来源于领测软件测试网 https://www.ltesting.net/
