最近做了一个关于医疗方面的项目，测试阶段有幸担任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可以减少一半左右，可见需求的重要性。

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