我负责的是电子商务的后台系统,主要是安全与风险控制相关的。目前主要是集中在功能测试和一丁点的性能测试。对自己的评价是对功能测试已经比较有把握,心里有底,但是对于性能测试基本还处在未入门的状态,将是我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情况。
对于测试质量及用例质量的考量,可以考虑以下因素:每千行代码缺陷数,每百个用例缺陷数,每个用例对应代码行数。
对于测试效率而言,每天执行用例数,每天发现缺陷数这两个是需要考虑的。