【IT168 评论】最近做了一个关于医疗方面的项目，测试阶段有幸担任Leader，对软件测试有了进一步的了解，在此分享一下个人的体会。

　　先说需求设计阶段，我们testing team是从项目kick-off阶段就介入的，与客户和开发组共同参与的需求的讨论，最后由我们testing team完成需求文档的编写，然后是通过了内部评审和外部评审。在这个阶段我们对需求的了解，确认工作是经过一个个激烈讨论的会议达成的，会议的重要性不言而喻，因为我们介入这个项目的时候不管开发和测试对系统业务流程的了解全部为零，通过客户对我们的KT(Knowledge Transfer)，开发和测试在需求的理解上达成一致，然后开发先给出开发计划，随后测试根据开发提供的开发计划制定测试计划，这个测试计划要在开发计划出来以后的两天内完成。这样我们测试和开发的工作基本做到并行进行。在这里我想说一下关于开发或者测试计划，当时开发提供的计划是只出一个Build，然后开发出最终版本以后我们测试组进行测试，但是客户不同意，客户当时Challenge开发组的leader，因为我们开发和测试是两个不同的外包公司，客户要分别支付我们effort，客户质问开发的，用三个月时间进行开发的话，那么这三个月测试组干什么?难道让测试的领钱吃干饭吗?开发的提出说，因为这个项目比较大，但是客户要求的时间却是非常的紧，如果中间出一个Build的话，要花费几天的时间去准备，比较浪费时间。对我们测试来说，如果进行这种方式的测试，在测试阶段我们的压力会特别大，时间比较段，工作量比较大，项目风险比较大。最后三方协调后决定是第一个月底由开发提供一个build，然后第二个build就是最终版本。这样虽然开发的浪费几天时间在build 1的发布上，但是对整个开发测试流程的掌控会更好，风险会降低很多。然后我们测试组出了一个和开发并行的测试计划。在build 1发布之前的二十多天时间里，我们不断的开会，确认需求，然后产出了需求文档和测试用例。关于需求文档和测试用例，我觉得我们的分工比较好，首先由三个老员工带三个新员工，分成三个组，然后三个组根据开发提供的系统的draft，每个人分配了七个模块，各司其职，各组完成各组的需求和测试用例文档，完成以后，交叉评审，然后在进行组外评审。

　　在此要说的是，整个项目Build 1进行完以后，我们对Defect进行分析以后发现，在需求阶段，如果对需求进行更好的确认和管理的话，我们后期的Defect可以减少一半左右，可见需求的重要性。

　　记得我最早接触软件测试的时候，一位老员工给我们进行了十天的软件工程培训，那时候他就特别提醒我们要重视需求，因为在软件开发测试过程中，需求是主线，所有的开发测试过程都是围绕需求这条基线进行的。

　　我们完成了需求文档和测试用例的编写工作之后，马上就进入到Build 1的测试阶段，这个阶段我们ST Team的任务是三轮ST测试(Round 1，Round 2，Round 3)加上兼容性测试。另外有SQA Team的安全测试和PT Team的性能测试和我们同步进行，最后产出各个Team的阶段报告，ST Team的阶段测试报告由我负责编制。

　　这里只说我们ST的测试内容，因为我们每天的工作内容早就在测试计划中安排好了，我们Round 1的测试时间是5天，Round 2三天，Round3一天，每个Round中间有一天的开发组的修复时间，而其实我们随时提交的Bug开发都可能随时修复，这里安排的一天时间是为了避免开发因其他事务没有来得及修改Open的Bug。我们用的缺陷管理工具是自己开发的一个工具，和QC相当类似，但是对我们这个项目来说更方便一些，其实缺陷管理工具大致都一样的，只要合适我们都可以拿来用。在提交Bug的过程中，我的经验是对于那些有争议的Bug，最好是提上去，如果开发确认不是Bug的话，最坏的结果是Closed掉了，但是如果是个Bug测试没有提上去的话，这就是测试组的失职了。还有就是关于Bug的描述，这里的Condition一定要描述清楚，在几月几日那个版本，什么环境下，一定要描述清楚，这样便于开发和测试追溯Bug，减少沟通的麻烦。在兼容性测试阶段，我们的测试目标是在遨游，火狐，IE7三种浏览器的两种分辨率下进行兼容性测试，根据最终用户可能选择的环境，分辨率的选择是800by600，1280by1024.六种情况我们用了5天时间，因为在ST阶段我们用的都是IE71280by1024一种环境，剩下五种环境我们用5天时间测试。

　　兼容性测试结束，有两天时间进行测试的阶段总结，对于我来说，之前每天给客户提交的测试报告就派上了大用场，我们的Daily Report是我们发挥主观能动性开发出来了，个人感觉非常全面，不但包括每天出现的Bug总数，而且还细化到各个模块发现几个Bug，这些Bug的严重级别，还有Case的执行情况，Case的通过率等等，最后还要有Bug总数趋势图，各个Bug严重级别分布图等。这些实时的测试数据是测试阶段报告的精华，有了这些，能够帮助测试人员更好的分析系统。最后我们ST的测试阶段报告受到了客户的表扬，得到了领导的认可，我认为在测试的执行阶段，最关键的还是执行力，尽可能翔实的记录我们每天的测试数据，以文档的形式表现出来，就一定能够实现我们测试的价值。