测试管理精华
上一篇 / 下一篇 2008-03-03 18:25:36 / 天气: 晴朗 / 心情: 平静
整理:暗涧幽火 更新时间:2008-02-28 16:10:28
现在，测试工作在项目管理中越来越受到重视。但是在项目开发过程中，项目管理一般都是着重于开发人员的管理，很少对测试人员进行项目管理。测试是把握软件质量的最后一关，如果这一关没有做好，即使前面的工作如何好，往往会出现功亏一篑的情况。本文主要讲述在项目管理对测试管理的感受，希望达到抛砖引玉的效果。
一、项目管理概况
笔者参与的项目合同造价约九十多万元，工期约9个月，分为七八的子模块，通过迭代的方式进行开发。SQA、过程监控等独立于项目组，测试人员、代码编写人员属同一个项目组。主要测试人员在需求分析阶段介入项目中。在项目的组织结构如下：
在项目开发过程中，主要配备了一个项目经理，两名软件经理以及一名测试经理。其中，测试经理独立于软件经理，隶属于项目经理领导。这样设置的好处，既能在一定程度上保证测试的独立性，又不至于沟通成本、测试成本过大。众所周知，测试附属于开发，是难于保证软件的质量。但测试独立到何种程度则，比较难于把握。太独立，会导致测试人员与开发人员的沟通成本增加，沟通都是文档化，由于缺乏必要的口头沟通，会导致变更无法及时传递，测试与开发常产生冲突。成本增加了，软件质量反而下降了。
二、测试项目奖的确定及分配：
测试工作作为项目管理的一部分，不参与项目奖的分配是会导致测试人员心态的失衡，同样无法保证软件的质量。由于，不同的项目对测试技能、测试工作时间等的要求的不同，在这里就不探讨测试人员与开发人员项目奖的比例，主要还是探讨测试组中项目组在整个开发团队中确定方式和时间以及分配方式。
1、测试组项目奖的确定：
测试组项目奖的确定一般在子模块的需求分析结束后，根据形成的需求用例规约确定测试计划，测试用例的设计、执行、评估所要耗费的时间、人力资源、所需测试技能后，由测试经理与项目经理、软件经理协商测试组项目奖在整个子模块中项目奖的比例，同时确定上下浮动的比例以及约束条件。
2、测试经理项目奖的确定
现在通常的项目管理方式是，项目经理确定各个软件经理、测试经理所在项目奖的比例。然后由软件经理确认所带领的小组成员间项目奖的分配比例。因为软件经理、测试经理的份额的多少会影响每个每个项目组成员的比例。而现在的分配方式，在一定程序上是不民主，不公平的，很容易出现长官意志，或者是凭私人关系而得到较高份额的项目奖，恣生腐败现象。具体就测试经理而言，其工作表现，其下属、平级关系的软件经理以及上下级关系的项目经理都很清楚。因此，对测试经理项目奖在测试组中的比例由以下方式确定：
项目经理30％，软件经理30％，测试经理20％，测试小组占20％；
举例说，整个项目将有三万元，测试组项目奖占10％，即三千元。其中，项目经理认为测试经理应得30％，软件经理认为测试经理应得40％，测试经理认为自己应得50％，测试组成员认为测试经理应得30％。则测试经理能得到：3000*（30％*30％+40％*30％+50％*20％+30％*20％）＝3000*0.37＝1120元。
3、测试人员项目奖的确定；
80％根据测试时间、质量、经验值通过一定的转换后确定；10％测试用例设计及执行；10％由测试经理根据贡献确定；
（1）80％项目奖的计算方法，如下表
任务 | 人员一 | 人员二 | ||||||||
计划时间（A） | 完成时间（B） | 质量（C） | 经验系数(D) | 标准时间(E) | 计划时间 | 完成时间 | 质量 | 经验系数 | 标准时间 | |
任务一 | 10 | 8 | 1 | 1 | 8.8 | 10 | 8 | 0.8 | 0.8 | 5.63 |
任务二 | 10 | 12 | 0.9 | 1 | 9.72 | 10 | 12 | 0.9 | 0.8 | 7.78 |
任务三 | 10 | 8 | 1.1 | 1.1 | 10.65 | 10 | 8 | 1.1 | 1 | 9.68 |
任务四 | 10 | 12 | 1 | 1.1 | 11.88 | 10 | 12 | 1 | 1 | 10.8 |
小计 | 41.05 | 小计 | 33.88 | |||||||
合计 | 74.94 | 份额 | 54.8％ | 份额 | 45.22％ | |||||
说明：
1计划时间根据需求用例规约页数确定测试用例页数来确定计划时间，具体见附录一；
2完成时间已日志上记录为依据；
3质量有测试经理确定，范围为0.8到1.2之间；
4经验系数:有测试小组共同确定，在0.8到1.2之间；
5标准时间E＝A*(1-(A-B)*0.05)*C*D;
6每月评定一次
(2) 10％测试用例设计及执行；
主要是测试用例的设计、执行以及用例对质量的保证，模块的关联，业务的熟悉，严重级别为高的比较及数量，有效缺陷数量
（3）10％由测试经理根据贡献确定；
软件经理、项目经理以及用户对负责模块的反映；被开发人员拒绝修改，但用户反馈要修改的缺陷，使用测试工具对测试效率的提高或者对其他测试人员的帮助；
三、测试小组与开发小组的约定：
1、缺陷的管理；
测试人员与开发人员以TD作为交流的依据，因此必须测试人员与开发人员必须每天浏览TD上的缺陷记录，并根据优先级作为开发员修改的依据：
优先级 | 开发工程师（修复） | 测试工程师（回归测试） |
高 | 缺陷状态为Open后，正常情况应在2个工作天内修改完成；如特殊情况，要在备注中注明原因，但也应在3个工作天内完成； | 在开发修改完成后，正常情况应在1个工作天内完成；如特殊情况，要在备注中注明原因，但也应在2个工作天内完成； |
中 | 缺陷状态为Open后，正常情况应在5个工作天内修改完成；如特殊情况，要在备注中注明原因，但也应在8个工作天内完成； | 在开发修改完成后，正常情况应在2个工作天内完成；如特殊情况，要在备注中注明原因，但也应在5个工作天内完成； |
低 | 缺陷状态为Open后，正常情况应在10个工作天内修改完成；如特殊情况，要在备注中注明原因，但也应在12个工作天内完成； | 在开发修改完成后，正常情况应在5个工作天内完成；如特殊情况，要在备注中注明原因，但也应在7个工作天内完成； |
2、版本的管理：
模块开发初期，两周提交一次版本；
模块开发中期：一周提交一次版本；
模块开发后期：2到3天提交一次版本；
附件三：开发期的界定；
提交版本时必须提供本次版本中实现的需求，复杂操作必须提供简单说明，存在约束的功能必须说明，并确定下次提交版本的时间；
提交版本前，必须确保类文件在VSS上是最新的，已check in的，类文件必须是编译正常的文件；要明确jar包的目录，要引用的库文件；
数据库脚本需要更新时，必须明确提示，并尽可能提供不清空数据的替代方法；
3、需求变更及其他事项的处理：
当需求规约发生变更时，开发人员应及时用邮件通知相关的测试人员和测试经理，如需求变更多大时，应形成文档提交；
4、小组内部验收测试：
模块开发后期，已确定无需改动后，由测试小组所有成员以及咨询工程师参与测试，并由测试经理在咨询工程师的协助下提交模块质量级开发人员质量报告给技术经理和项目经理；
四、测试小组约定
1、测试时间：（单位为工作天/周）：
| 测试工程师 | 测试经理 | ||||||||||||||||||||||||||||||||||||||||||||||||||
开发初期 | 1 | 1 | ||||||||||||||||||||||||||||||||||||||||||||||||||
开发中期 | 3 | 2 | ||||||||||||||||||||||||||||||||||||||||||||||||||
TAG:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
