测试@代码质量

测试@代码质量

题外话：之前看朋友社区中提到了《Google上海如何测试搜索产品》从中受益匪浅，在工具中排在第一的 Clearsilver Diff Tool有种似曾相识的感觉。
和腾讯提出的业务精准化测试非常相似。测试任务分配由代码的修改来决定。

两个release版本间的代码差异决定了本次版本引入的BUG数和新功能的BUG数（不包含已有功能的漏测BUG）。这样更利于测试资源的分配，关注修改部分的质量，而原有功能模块的质量通过自动化来做回归测试。

精准测试可以帮助我们将测试时间压缩，业务测试也将更加熟悉相应的代码，但是我们还应该关注些什么？

静态代码的质量是很重要的环节，很多隐藏在代码深处的BUG，特别是安全漏洞，我们需要静态代码检查，来带给我们更多的可预见性BUG。

之前遇到在这样的一个BUG

#define MAXUSER 1024
……
char message[MAXUSER]
……
init
main(int argc,char *argv[])
{
……
strcpy(message,*argv);
while(*++argv){
strcat(message,” “);
strcat(message,*argv);
}
}

这里乍看没有问题，并且在用户访问量稳定的时候不会出错，当新版上线用户量激增各种攻击增加的时候却出现了BUG。

strcpy等函数在C函数中不是安全的函数，在某些操作系统中无法自动动态分配缓冲区，导致缓冲区溢出。

另一个值得关注的地方是代码性能。很多应用在瞬时压测的时候表现很好，但是生产环境表现却每况愈下，一方面数据量持久化的读写分离没有考虑清晰，另一方面本身代码逻辑复杂度太高。

之前遇到这样一个例子，A,B,C三个部门跨部门合作，各部门提供service调用，结果A,B,C三部门的service都设计了数据的加密及解析，导致数据访问速度极慢，这个时候更需要专业的code review，将解复杂度排除在设计初期。

根据google 提出的 Test 2.0的方向和Jason的想法不谋而合，全民测试，代码及流程阶段级质量监控将会是测试的未来方向。

———EOF———

测试@代码质量(续)

Jason之前的测试@代码质量将代码质量的问题提了出来。很多朋友都问道静态检查相关的问题。在前Sonar Metrics解读中，Jason也提到了相关检查的Metric。

各种Metric都有了，但是标准是什么，很多公司包括现有的公司都以UT来和代码的静态检查作为check点，这些足够了吗，有没有标准可依？

总结sonar的评分插件和标准理论，Jason留下些Memory，做流程规范化的公司还是可以借鉴的

sonar的评分和软件组织可维护性指数(maintainability index,MI)的出发点基本一致，就是一种广泛使用的可维护性度量的方法。

这里仅以可维护性指数为例，

MI = 171 – 5.2*ln(aveV)-0.23*aveV(g’)-16.2*ln(aveLOC)+50*sin(2.4*PerCM^(1/2))

MI的复杂度aveV即Halstead(代码复杂度)，aveV(g’)即逻辑复杂度基本可以和sonar的评分一致，可以参考Sonar Metrics解读中的内容。

aveLOC代表代码行数。

PerCM代表平均注释行数百分比。

其他面向对象程序的度量也可以用参考Sonar Metrics解读中的一些Metrics。

这里还是要重点说一下，依赖程度的问题，这里sonar提供了离心耦合和向心耦合的检测，这个对于service mock成本的考虑还是很重要的。

更多的测试可以直接从代码的角度来发掘，代码的质量直接决定了BUG的多少和严重程度，所以向前一步，更加保证产品的质量。

———EOF———

作者：吴颖敏 |www.futurehandw.com

Email: wuyingminhui@gmail.com