【我分享】软件测试管理精华
一、 项目管理概况笔者参与的项目合同造价约九十多万元，工期约9个月，分为七八的子模块，通过迭代的方式进行开发。SQA、过程监控等独立于项目组，测试人员、代码编写人员属同一个项目组。主要测试人员在需求分析阶段介入项目中。在项目的组织结构如下：
http://www.ltesting.net/uploads/2008/02/28591_200802031523531.jpg
在项目开发过程中，主要配备了一个项目经理，两名软件经理以及一名测试经理。其中，测试经理独立于软件经理，隶属于项目经理领导。这样设置的好处，既能在一定程度上保证测试的独立性，又不至于沟通成本、测试成本过大。众所周知，测试附属于开发，是难于保证软件的质量。但测试独立到何种程度则，比较难于把握。太独立，会导致测试人员与开发人员的沟通成本增加，沟通都是文档化，由于缺乏必要的口头沟通，会导致变更无法及时传递，测试与开发常产生冲突。成本增加了，软件质量反而下降了。
二、测试项目奖的确定及分配：
测试工作作为项目管理的一部分，不参与项目奖的分配是会导致测试人员心态的失衡，同样无法保证软件的质量。由于，不同的项目对测试技能、测试工作时间等的要求的不同，在这里就不探讨测试人员与开发人员项目奖的比例，主要还是探讨测试组中项目组在整个开发团队中确定方式和时间以及分配方式。
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)计划时间完成时间质量经验系数标准时间
任务一108118.81080.80.85.63
任务二10120.919.7210120.90.87.78
任务三1081.11.110.651081.119.68
任务四101211.111.8810121110.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、测试 http://www.csai.cn (单位为工作天/周)：
测试工程师测试经理
开发初期11
开发中期32
开发后期53
2、 会议：
项目例会后第二天召开小组会议，时间为1到2小时，包含内容为小组成员小结，新版本的对应的测试计划，测试用例及预期执行时间;
每月召开小组会议，确定小组成员的考核;2到4个小时
每个季度召开会议，确定项目奖的分配建议，包项目经理批准;
3、测试方式：
实行交叉测试和集中测试相结合的方式进行，主要进行黑盒测试，以手工测试为主，在项目后期进行简单的性能测试;
开发小组提交版本后，有专门负责相应模块的测试工程师进行初步测试，在开发小组提交新版本前的一到两天测试组所有成员进行集中测试，测试工程师必须提供测试用例的执行情况，模块的关联情况，简单演示，并以此作为考核的依据;
4、测试用例：
测试用例不但可以保证软件的质量，还会大大缩短，需求完成后的测试时间。因此，测试用例必须写，而且是在模块需求规约确定后，在开发第一次提交版本前完成。执行过程中，如有需求变更，测试用例规约也要更新;
五、 对开发人员的考核：
测试小组除了负责项目的质量外，还根据在测试过程中提出相应的数据，软件经理考核开发人员的依据。主要是在提出以下三方面的数据：
1、模块内部验收测试
并由测试经理在咨询工程师的协助下提交模块质量级开发人员质量报告给技术经理和项目经理;
2、 缺陷上严重级别、状态及优先级别的处理
类似缺陷出现的次数，拒绝修改缺陷而导致用户对软件质量的不满，或者用户要求修改等类似的内容。
3、 对测试的配合以及java类文件的编译;
附录一：计划时间的简单估计：
1、 计算需求文档的页数，得出系统测试用例的页数：
2、 需求页数：
系统测试用例页数 ≈1：1(含数据)由系统测试用例页数计算编写系统测试用例时间; 编写系统测试用例时间 ≈ 系统测试用例页数×1小时
3、 计算执行系统测试用例时间
编写系统用例用时：执行系统测试用时 ≈ 1：2*(执行次数);
如：需求有10页，则测试用例约有10页(含测试数据)，书写测试用例的时间为20小时;
执行用例三次的时间为10*2**3=60小时
附件二：优先级的定义
高：导致测试无法继续进行，必须立刻进行修复;对用户产生很大影响，必须优先解决。
中：对用户产生一定影响，可正常排队解决。
低：对用户产生轻微影响。
附件三：开发期的界定;
开发初期：子模块完成需求调研、分析，形成用例规约;
开发中期：子模块编码开始到编码完成主要的需求;
开发后期: 编码优化工作的开始; ...
页:
[1]
