软件测试管理实战验补充.pdfVIP

软件测试管理实战经验

最近做了一个关于医疗方面的项目，测试阶段有幸担任Leader，对软件

测试有了进一步的了解，在此一下个人的体会。

先说需求设计阶段，我们testingteam是从项目kick-off阶段就介入

的，与客户和开发组共同参与的需求的讨论，最后由我们testingteam完成需

求文档的编写，然后是通过了评审和外部评审。在这个阶段我们对需求的

了解，确认工作是经过一个个激烈讨论的会议达成的，会议的重要性不言而

喻，因为我们介入这个项目的时候不管开发和测试对系统业务流程的了解全部

为零，通过客户对我们的KT(KnowledgeTransfer)，开发和测试在需求的理解

上达成一致，然后开发先给出开发，随后测试根据开发提供的开发制

定测试，这个测试要在开发出来以后的两天内完成。这样我们测

试和开发的工作基本做到并行进行。在这里说一下关于开发或者测试计

划，当时开发提供的是只出一个Build，然后开发出最终版本以后我们测

试组进试，但是客户不同意，客户当时Challenge开发组的leader，因为

我们开发和测试是两个不同的外包公司，客户要分别支付我们effort，客户质

问开发的，用三个月时间进行开发的话，那么这三个月测试组干什么?难道让测

试的领钱吃干饭吗?开发的提出说，因为这个项目比较大，但是客户要求的时间

却是非常的紧，如果中间出一个Build的话，要花费几天的时间去准备，比较

决定是第一个月底由开发提供一个build，然后第二个build就是最终版本。

这样虽然开发的浪费几天时间在build1的发布上，但是对整个开发测试流程

的掌控会更好，风险会降低很多。然后我们测试组出了一个和开发并行的测试

。在build1发布之前的二十多天时间里，我们不断的开会，确认需求，

然后产出了需求文档和测试用例。关于需求文档和测试用例，我觉得我们的分

工比较好，首先由三个老员工带三个新员工，分成三个组，然后三个组根据开

发提供的系统的draft，每个人分配了七个模块，各司其职，各组完成各组的

需求和测试用例文档，完成以后，交叉评审，然后在进行组外评审。

在此要说的是，整个项目Build1进行完以后，我们对Defect进行分析以

后发现，在需求阶段，如果对需求进行更好的确认和管理的话，我们后期的

Defect可以减少一半左右，可见需求的重要性。

记得我最早接触软件测试的时候，一位老员工给我们进行了十天的软件工

程培训，那时候他就特别提醒我们要重视需求，因为在软件开发测试过程中，

需求是主线，所有的开发测试过程都是围绕需求这条基线进行的。

我们完成了需求文档和测试用例的编写工作，马上就进入到Build1

的测试阶段，这个阶段我们STTeam的任务是三轮ST测试(Round1，Round

2，Round3)加上兼容性测试。另外有SQATeam的安全测试和PTTeam的性能

测试和我们同步进行，最后产出各个Team的阶段报告，STTeam的阶段测试报

告由我负责编制。

这里只说我们ST的测试内容，因为我们每天的工作内容早就在测试中

安排好了，我们Round1的测试时间是5天，Round2三天，Round3一天，每

个Round中间有一天的开发组的修复时间，而其实我们随时提交的Bug开发都

可能随时修复，这里安排的一天时间是为了避免开发因其他事务没有来得及修

改Open的Bug。我们用的管理工具是自己开发的一个工具，和QC相当类

似，但是对我们这个