CISQ给你的代码来打分 原创

至顶网软件频道消息： 

白盒测试的全新解决思路

在这个软件定义的时来，谁来定义软件？作者从事测试工作也有近二十年的时间了，但也只能对着一个个“黑盒子”测试它的基础性能、应用处理，不是不想把这个“黑盒子”打开，看一下它的代码，而是不能。自打操作系统从DOS时代的十六位升级到32位，乃至现在的64位之后，软件编程就不再是一个人单打独斗就可以完成的了。十几人、二十人为实现一个功能编写几十万上百万行代码，这样的事情很常见。这么多行代码很难去一一进行审查。所以这么多年以来，测试还是围绕着这个“黑盒子”在打转。作为一个第三方的评测机构而言，黑盒测试已经可以满足对软件产品（即便有很多软件是打包在硬件之中）的评测需求。而对于厂商和实际使用软件的用户而言，依靠黑盒测试来查找软件中的BUG就远远不够了。如何对应用系统的安全性、稳定性和效率等质量问题一直是困扰企业的核心问题。代码在系统结构方面的质量问题是常规测试手段所难以发现的，如何衡量软件代码质量？是否有相关代码质量标准能够依循？

在12月12日举行的“测试改进软件架构与代码质量研讨会”上，开斯特（北京）软件技术有限公司（CAST）大中华地区总裁诸凡先生、以及CISQ董事长兼首席执行官Bill Curtis博士介绍的CISQ软件结构化质量评估维度和方法。为如何进行“白盒”测试，带来了一个全新思路。

功能点、路径、架构

开斯特（北京）软件技术有限公司（CAST）大中华地区总裁诸凡先生

从诸凡的介绍中我们可以了解，和传统白盒测试通过人工的方式查看源代码不同，CISQ所制订的代码质量标准是通过对整个软件结合上下文关系，理清应用从最前端输入到界面、到业务逻辑、到框架、到数据逻辑，直到最终的存储上的所有功能点。将这些层次连贯起来，来查看软件的上下文关系，从而了解系统每个交易是如何完成的，每个步骤的行进路径是什么，从系统层面上去对整个软件架构进行分析。

下面，诸凡先生通过一个CAST应用智能平台的分析实例具体向我们解释，CISQ代码质量标准是如何对代码中违规交互路径进行发现：在下面图片中是CAST应用智能平台分析得出的一个软件系统路径结构，绿色线条是软件架构所设计的路径，红色线条是CAST所发现的未按架构设计进行数据调用的异常路径。异常路径未必是有问题，这时会再参照相关国际标准，例如结构化的国际质量标准CISQ来查看哪些结构方法会存在什么样的潜在风险。

除了路径结构化问题外，CAST应用智能平台还可以对软件设计的潜在安全风险进行分析。诸凡用一个CAST分析的银行系统源代码继续向我们举例。

在上面的路径分析中，可以看到红线的输入数据，从用户输入到交易去访问更新数据库在整个路径上未进行数据检查，就直接对数据层的信息进行更改或调用。这里就存在着很大的信息安全风险，因为无法判定是否有非法安全信息从这条路径对数据库进行侵入。

如何用CISQ给代码打分

最后，诸凡先生介绍了CAST应用智能平台的工作原理。

首先是对源代码进行分析，CAST支持了50多种不同的编程技术，从JAVA、C、.NET到大型机的编程语言CAST均进行了支持。同时还支持12种数据库，例如Oracle、SQLServer等。明确编程语言和所采用数据库后，再加上一些编程团队的有关信息。将这些内容输入到分析器中，由分析器进行格式化整理并建立元模型。然后遵照CISQ软件行业标准，分析这些元模型的程序、数据调用关系，从而摸清所有程序的动作关系，进而分析出整个软件的程序逻辑架构。然后再根据分析出的架构、交易流程、交易方式，通过CISQ、OMG以及CWE等软件和安全行业标准，对软件进行判断分析。分析结果出来之后，根据所发现的结构化问题、安全性问题，转化成一个数据化的健康度分数，分门别类的进行打分度量。由此实现通过给代码打分而不是利用行代码数对软件进行评估的目的。