小A所在的项目组，每个项目版本都bug数都在400-500之间，每次项目测试期间都要给验证Bug单独安排2-3天的时间进行Bug验证。Bug多的问题一直存在，终于在4.6.0版本发布后问题爆发了，项目上线后线上版本出现了十几个问题，后期针对问题又紧急发布了一个新版本修复问题。

针对情景中小A遇到的问题，你所在的项目组是否也存在此问题呢？如果有同样的问题，你就需要特别注意啦！小编与公司其他项目组的同事沟通后，发现很多项目组每个版本的Bug数在100以内。为什么bug数差距这么大呢？

行业内有一句话：质量不是被测试出来的。为了提高项目质量，我们就要从源头抓起，开发是项目的建造者，如何让开发提测的版本质量本身提高，我们就要建立一个标准衡量开发的代码质量。小编使用的标准是千行代码率，今天带你一起探索此方法。

一、评估目的

1.从开发角度分析每个人员的技术水平；

2.建立量化标准，从源头评估代码质量，做到质量控制前移；

3.根据分析出现的问题制定改进计划。

二、统计指标

1. Bug数

最直接反映开发人员代码质量就是其所写的代码产生了多少个Bug。另外Bug的严重性不一样，对用户的影响也是不一样的。所以我们不仅要统计开发人员名下的Bug总数，还要统计其在不同严重性程度的Bug数量。 统计Bug数量的时候需要注意将一些不属于开发原因的Bug排除在外，如需求建议、需求补充、不是问题的Bug、重复的Bug。

2.代码行数

小编使用的工具是StatSVN，这个工具使用很便捷。但是在统计之前一定要了解清楚自己所在项目的代码结构。比如说开发写的代码文件格式都有哪些，这些不同格式的文件中具体包含是哪些方面的代码，哪些代码是不需要统计的。以小编项目组为例：开发写的以.h结尾的头文件、单元测试代码、第三方提供的SDK代码，这些代码有些不对功能产生影响，有些不是自己项目组开发写的代码，所以都不进行统计。

3.计算公式

千行代码Bug率 =Bug数量/ (代码行数/1000)

度量的标准：千行代码Bug率数值越小质量越好。

三、如何使用工具

1. 环境搭建

1）机器 安装Java的运行环境（Java Runtime Environment），JDK的版本需要到1.6，在1.4的时候会报类似“Repositories:org.xml.sax.SAXParseException: 缺少文件根组件”的错误

2）解压压缩包，到一个目录，如c:\statsvn； StatSVN的主页： http://www.statsvn.org/

2.命令统计代码

1）从SVN服务器中获取统计项目版本的最新所有代码，Windows系统使用SVN客户端可以直接checkout

2）在存放代码目录下生成SVN日志log命令：

svn log - v --xml > 日志名XXX.log

3）统计代码行数

cmd中在statsvn jar包所在目录执行命令:

java -jar ../statsvn.jar ../nova/日志名XXX.log ../nova  -charset utf-8 -disable-twitter-button -title Nova  -include **/*.cpp:**/*.h -exclude **/sqlite3/*.*

Note说明：

java -jar ../statsvn.jar // 执行statsvn.jar，后面是它的参数

参数1：../nova/日志名XXX.log //调用上面生成的SVN日志

参数2：../nova //最新版本所在的目录

参数3：-charset GB2312 //生成的HTML所用的字符集

参数4：-disable-twitter-button //关闭twitter连接，可能statsvn的开发者是一个twitter爱好者，statsvn默认在项目和开发人员的名字后加个twitter连接按钮，方便互动。这在中国行不通，大家都懂的...所以让twitter连接按钮不显示。

参数5：-title标题名 //这个设置在HTML页面中显示的项目标题

参数6：-include**/*.cpp:**/*.h //表示统计的文件类型，默认情况下statsvn统计指定目录下的所有文件（包括一些开发环境自动生成的文件等，这个参数可以设置指定统计具体文件，例子中的表示只统计项目目录下得CPP与H文件。

参数7：-exclude**/sqlite3/*.* //表示不统计的内容，例子中的参数表示不统计项目文件夹中sqlite3的内容(因为sqlite3的内容是调用别人写的程序，统计进去没有意义~）

4）查看统计结果：在生成的html结果目录下查找index.html文件。此文件是所有结果的总目录表。点击Developers就可以看到每个开发人员提交的代码数量。

四、StatSVN的优缺点

StatSVN会把当前SVN库的状态用图片和图表的方式展现出来，可以按不同分类分别展开，功能强大。

StatSVN统计的是所有代码行，包括注释和空行，但一般度量要求是有效代码行，在分析时需要注意这一点。

StatSVN不考虑修改的代码行数，只考虑与上一版本相比新增(+)与删除(-)的代码行数。

五、如何更精准评价开发代码质量

通过上面的方法我们已经得到了每个开发人员的千行代码Bug率。但是为了更精准的评估开发质量还需要其他指标进行辅助参考。这些数据包括Bug易发现性、Bug的反复次数、 连带Bug数量、负责的功能复杂性等方面综合分析。这样得出的结论才能更符合实际情况。

（1）什么是SVN

（2）怎样从SVN服务器中获取统计项目版本的最新所有代码？

（3）什么是 twitter ？

（4） Bug易发现性、Bug的反复次数、 连带Bug数量、负责的功能复杂性 怎么统计？

参考文件：http://blog.csdn.net/honghailiang888/article/details/51451584

测试工程师，本质上就是产品的 质量 检查员。我们把 开发 做好的产品拿过来进行检测，从而发现问题，进而解决问题。作为测试，我们应该是比产品更懂技术，比 开发 更懂产品。测试人员，对于产品的业务逻辑，可能会比产品同学还要更为明白。这样来说，测试对于产品 质量 的把控尤为重要。 　　在测试中，从底层的白盒测试，再到UI层的黑盒测试；从相关的接口测试，再到产品的性能测试。从不同的角度来对产品进行测试，检... 我们先来看看几个概念 　　维护：是指修改bug、修改捞的 代码 、添加新的 代码 之类的工作； 代码 易维护：指不破坏原有 代码 设计、不引入新的 bug 的情况下，能够快速地修改或者添加 代码 ； 代码 不易维护：指修改或者添加 代码 需要冒着极大的引入新 bug 的风险，并且需要花费很长的时间才能完成。 　　我们可以从侧面上给出一个比较直观但又比较准确的感受。 　　如果 bug 容易修复、修 圈复杂度(Cyclomatic complexity)是一种 代码 复杂度的衡量标准，在1976年由Thomas J. McCabe, Sr. 提出。在软件测试的概念里，圈复杂度用来衡量一个模块判定结构的复杂程度，数量上表现为线性无关的路径条数，即合理的预防错误所需测试的最少路径条数。 代码 的复杂度是 评估 一个项目的重要标准之一。较低的复杂度既能减少项目的维护成本，又能避免一些不可控问题的出现。然而在日常的 开发 中却没有一个明确的标准去衡量 代码 结构的复杂程度，大家只能凭着经验去 评估 代码 结构的复杂程度，比如， 代码 的程度、结构分支的多寡等等。当前 代码 的复杂度到底是个什么水平？什么时候就需要我们去优化 代码 结构、降低复杂度？这些问题我们不得而知。因此，我们需要一个明确的标准去衡量 代码 的... 作者：Pranjal Datta编译：ronghuaiyang导读有很多资料解释了SSIM背后的理论，但很少有资源深入研究细节，本文就是试图填补这一空白的谦虚尝试。最近，在实现一篇深度估计论文时，我遇到了术语结构相似性指数(SSIM)。SSIM作为度量两个给定图像之间相似度的度量指标。由于这项技术从2004年就开始了，有很多资料解释了SSIM背后的理论，但很少有资源深入研究细节，这对于基于梯度的实... 本文来自云+社区专栏，作者腾讯移动品质中心TMQ 提到“ 质量 ”二字时，我们的第一反应往往是“有多少BUG？”“性能好不好？“这样的问题。我们对软件产品或服务的 质量 定义看其能不能满足用户的需求，包括功能、性能和体验等维度的指标，我们可以通过各种类型的检测手段来给出其 质量 高低的度量。但是，如果直接拿出一段源 代码 放在我们面前，问这段 代码 的质...