|
我负责三位 XXX 测试人员对 XXX
进行测试。测试规程主要是按协议的各个要求编写的,测试规程的通过准则是测试人员根据对协议的理解、对系统的理解编写的。三位测试人员根据测试规程进行分工,分别编写、测试不同的规程。测试的平台是测试部自已开发的专用
XXX 测试环境。
前一段时间,对 XXX 测试如何进行管理没有一个头绪,使得 XXX
测试计划一再推迟,并且对实际的进展、测试的质量都不太清楚。为了加强对 XXX
测试的管理,并争取做到量化,进行一些尝试,并取得一定的成功。现在每天可以看到实际的测试进展,并能发现每位测试人员的进度、质量,也可以看到 XXX
测试结果的情况。
以下是我近期对测试管理的经验。
做好每日汇报工作
每日汇报工作可以与项目、部门的一些具体要求结合起来。比如,项目要求每天的测试应当有一份测试日报。测试部要求测试规程、测试结果要入到测试中心。还要求故障及时提交,并导入
CQ 。
除此之外,为了做好统计工作,我在 CC 上建立了一个 execl
的汇总文件,输入了所有的测试规程、通过准则。每天,测试人员有新增加的测试规程、通过准则,要加到该文件中;每天的测试结果,要填到该文件中。要填的内容,如果是测试规程、通过准则,是与测试中心的是一致的。测试结果只是一个通过或不通过,加上一个当天日期。这是一个非常简单的填表,并不会增加太多的工作量。
采用 CC ,可以保证汇总文件的一致性,还可以检查测试人员填写的情况,可以提取不同版本的汇总文件。这充分利用了 CC 的优点。
以下是汇总文件中的一部分:
|
用例编号 |
测试名称 |
说明 |
编写者 |
更新日期 |
|
IT-DSP-F-001-001-001-010 |
小区建立成功测试 |
P-CCPCH 无帧分配, 2020M , 20dBm |
XXX |
10/01/2004 |
|
IT-DSP-F-001-001-001-011 |
小区建立成功测试(帧分配) |
与 010 不同在于 P-CCPCH 有帧分配 |
XXX |
10/01/2004 |
|
IT-DSP-F-001-001-001-012 |
小区建立成功测试(小区发射功率) |
与 010 不同 ,17dBm |
XXX |
10/01/2004 |
|
用例编号 |
测试名称 |
通过准则 |
已测 |
V0.5b 通过否 |
V1.00.010a 通过否 |
测试日期 |
测试人员 |
|
IT-DSP-F-001-001-001-010 |
小区建立成功测试 |
小区建立返回成功消息 |
2 |
通过 |
通过 |
04-10-1 |
XXX |
|
|
DwPCH码字正确 |
1 |
通过 |
通过 |
04-10-1 |
XXX |
|
|
DwPCH星座图正确 |
1 |
通过 |
通过 |
04-10-1 |
XXX |
|
|
DwPCH相位为连续的S1 |
1 |
通过 |
通过 |
04-10-1 |
XXX |
|
|
S1的周期与帧号模2对齐 |
1 |
通过 |
通过 |
04-10-1 |
XXX |
|
|
P-CCPCH、DwPCH功率相等 |
0 |
|
|
|
XXX |
|
|
收到 TS4、TS5、TS6的数据,收不到TS1、TS2、TS3的数据 |
1 |
通过 |
通过 |
04-10-1 |
XXX |
|
|
P-CCPCH midamble码正确,功率与数据部分相等 |
1 |
通过 |
通过 |
04-10-1 |
XXX |
|
|
各天线数据相同。 |
0 |
|
|
|
XXX |
|
IT-DSP-F-001-001-001-011 |
小区建立成功测试(帧分配) |
DwPCH相位分别为S1、S2,与帧分配一致,正确表明P-CCPCH的出现 |
0 |
|
|
|
XXX |
|
|
S1、S2的周期与帧号模2对齐。 |
0 |
|
|
|
XXX |
做好统计汇总工作
有了汇总文件的原始数据,我就可以做好统计汇总工作了。在汇总文件里,专门建了一个表,填写各项统计数据。如以下各个图表。从这些数据可清楚地看到当前测试的进展情况。
|
用例当前统计 |
|
用例数 = |
173 |
|
通过准则数 = |
289 |
|
通过准则测试覆盖率 = |
59.52% |
|
用例测试覆盖率 = |
42.20% |
|
已编写用例数 = |
76 |
|
|
|
测试人员当前统计 |
|
A要测试总数 = |
156 |
|
A要编用例数= |
85 |
|
B要测试总数 = |
106 |
|
B要编用例数= |
60 |
|
C要测试总数 = |
28 |
|
C要编用例数= |
28 |
|
A测试完成率 = |
44.23% |
|
A用例编写率= |
40.00% |
|
B测试完成率 = |
64.15% |
|
B用例编写率= |
53.33% |
|
C测试完成率 = |
32.14% |
|
C用例编写率= |
35.71% |
|
XXX测试结果统计 |
|
当前结果: |
|
|
|
|
0.5版本已测数= |
147 |
V1.00.010a 版本已测数 = |
70 |
|
0.5 版本缺陷数 = |
15 |
V1.00.010a 版本缺陷数 = |
11 |
|
0.5 版本缺陷率 = |
10.20% |
V1.00.010a 版本缺陷率 = |
15.71% |
|
最终结果: |
|
|
|
|
0.5 版本已测数 = |
147 |
|
|
|
0.5 版本缺陷数 = |
15 |
|
|
|
0.5 版本缺陷率 = |
10.20% |
|
|
|
历史统计数据 |
|
|
|
|
|
|
时间 |
通过准则测试覆盖率 |
用例测试覆盖率 |
通过准则数 |
用例数 |
已编写用例数 |
|
10月10日 |
46.98% |
38.01% |
215 |
171 |
22 |
|
10月11日 |
41.60% |
38.01% |
250 |
171 |
22 |
|
10月12日 |
57.44% |
40.46% |
289 |
173 |
71 |
|
10月13日 |
58.48% |
41.04% |
289 |
173 |
74 |
|
10月15日 |
59.17% |
41.62% |
289 |
173 |
75 |
|
10月18日 |
59.52% |
42.20% |
289 |
173 |
76 |
做好跟踪、检查、反馈工作
在已有统计数据的基础上,就是做好相应的管理工作了。
根据测试人员提交的测试日报,可以检查测试人员是否正确填写了每日汇报工作。因为每日汇报是统计的基础,必须保证数据的正确性。同时,可以检查当天的测试质量如何。
从各个测试人员的完成率,可以知道该测试人员这几天的工作情况。如果测试人员好几天各项完成率都没有改变,就需要过问一下,是由于其它工作安排影响了原计划的测试任务,还是其它原因。
从统计数据中,还可以发现测试的进展。比如,从用例的完成情况看,还不理想, 通过准则测试覆盖率只有
59%,用例测试覆盖率只有42%, 需要尽快地提高用例的完成情况。考虑到有些用例针对的特性,当前 XXX 版本计划不支持,这可以更改统计的算法进行完善。
从数据中,还可以看出 XXX 版本本身的质量,比如,当前 V1.00.010a 版本缺陷率约为 15% 。这可以进一步与 XXX
人员一起,分析这些缺陷的类型、原因。
效果和经验
在刚开始要求每日汇总时,数据不太准,变化也较大,这是由于测试人员正在把以前未汇总的数据输入造成的。很快,数据就会稳定。
由于统计数据中有明确的数据,比如完成率,测试人员很清楚,提高完成率就是需要达到的目标。因此会专注于测试的完成、积极地完成每日统计。由于数据的对比性,也可适当地给测试人员一定的压力,努力完成测试任务。
实行每日汇报之后,测试进展得到了加强, 通过准则测试覆盖率、用例测试覆盖率有稳步提高。
从统计数据的每天的进展中,可以得到测试进展的量化数据,为预估下一步的 XXX 测试进度提供了有力支持。 对于正常的测试人员,可以看到平均每天测试完成率增加
1%。
由于各个测试人员的起点不同,考核时不会用数据的绝对值进行对比,而应当用数据的增量进行对比。
要求每日汇报,不能太多增加测试人员的工作。这里的每日汇报,绝大部分内容都是已经准备好的,只需要填一个“通过”或“不通过”,以及当天的日期即可。这使得测试人员不会把它当作一个负担。相应的统计工作,是通过
execl 文件中的公式,由我来进行统计的,减少了对测试人员工作的干扰。
另外,以汇总文件为纲,可以把测试日报、测试中习、测试规程、测试用例、通过准则等众多的测试要素、工作要素有机地结合起来,避免了管理工作中散、乱的局面。通过对数据的统计分析,提高了管理水平。
|