2011-我负责的测试项目数据分析

我负责的是电子商务的后台系统，主要是安全与风险控制相关的。目前主要是集中在功能测试和一丁点的性能测试。对自己的评价是对功能测试已经比较有把握，心里有底，但是对于性能测试基本还处在未入门的状态，将是我2012年重点要加强的地方。

2011年我做过的项目情况描述：

项目	千行代码缺陷数	百个用例缺陷数	用例对应代码行数	负责代码行数	设计用例数	执行用例数	发现缺陷数
老树盘根	0.322	3.44	203	90086	387	841	29
标准化事件	0.236	2.3	185	55639	300	565	13
风险profile	0.333	4.12	259	45356	175	364	15
安全数据中心	1.428	11.05	158	16116	71	208	23

项目总体情况如下：

项目	总代码行数	总设计用例	总执行用例	总BUG情况	开发投入	测试人日
老树盘根	150144	737	1490	55	470	147
标准化事件	55639	300	565	13	97.5	26.5
风险profile	45356	175	364	15	66.7	17.1
安全数据中心	32233	204	640	35（约）	61.2	31.1

我负责的项目情况总结，总共测试代码行数90086+55639+45356+16116= 207197行代码。设计用例933个，执行用例1978个，发现缺陷80个。

2010年7月20日到12月31日，一共完成了18个升级包。一共提交了23个缺陷。（近卫军培训了一个多月，真正开始测试生涯的时间大概是9月，除最开始才学习安全线业务外，中间参与了CTUsofa2.0升级，其它时间基本上每个星期顶上两个升级包，对于任务的并行能力在这段时间得到了一个充分的锻炼！）

2011年1月1日到12月31日，一共完成了4个项目+21个升级包，一共提交了190个缺陷。4个项目占据了我全年的大部分时间，难以想象我还完成了21个升级包，真的是对自己感觉到惊讶！老土，你可以的。（缺陷是指有效缺陷，无效及scm、mvn变更类的都已经过滤掉。）

2011年的190个缺陷中，有54个缺陷是SIT的，136个缺陷是开发环境的。对于SIT的缺陷，有些是测试遗漏，这个我必须承认。还有一部分是考虑到性能的情况下修改日志或者其它，还有一部分是PD需求不明确导致的SIT的修改，最后一部分是线上案件紧急情况。在不考虑SIT的缺陷情况下，80个缺陷是项目中的，63个缺陷是升级包的，但是我投入在项目中的时间大约是8个月，投入在升级包中的时间只有4个月，因此相对而言，升级包中的缺陷更容易发现。

测试工作量评估，仅仅是我的直观感受，有啥好的观点大家也可以提出来啊，欢迎批判的观点。

衡量一个测试的工作量的话应该考虑①测试代码行数 ②用例数 ③缺陷数 ④缺陷比例分析 ⑤代码覆盖率 ⑥测试执行天数 ⑦上线后2周内的缺陷情况 ⑧上线后3个月内的缺陷情况

测试代码行数（绝对值）和用例数（绝对值）是用来评估测试工作量的。而缺陷数（绝对值）、缺陷比例分析（相对值）和代码覆盖率（相对值）是为了评估测试质量的，测试执行天数（绝对值）是为了评估测试效率的，上线后运行情况是为了评估测试遗漏情况。

对于代码覆盖率分析，要考虑以下情况：a.java文件的覆盖情况，可以使用EMMA这个覆盖率统计工具。b.数据库相关xml文件的覆盖情况，目前没有一个好的工具。c.前端vm、js等文件的覆盖情况，目前也没有好的工具。d.系统部署及框架相关文件的覆盖。f.系统引用第三方JAR包的覆盖情况。

对于缺陷比例分析，要考虑以下情况：a.测试阶段发现缺陷情况 b.业务模块发现缺陷情况 c.缺陷中严重程度比例d.代码各层次BUG比例情况e.测试方法发现BUG情况f.缺陷类型引发BUG情况。

对于测试质量及用例质量的考量，可以考虑以下因素：每千行代码缺陷数，每百个用例缺陷数，每个用例对应代码行数。

对于测试效率而言，每天执行用例数，每天发现缺陷数这两个是需要考虑的。