● 如果项目需要，还可以在此阶段研究一下自动测试工具，包括一些准备外包测试的工作。根据产品的成熟度调整测试策略开发测试一盘棋。测试经理应该有大局观，保持测试策略总与开发的进展相一致，保证终的软件成果佳（而不是测试部发现Bug数多）。在这个XXX5.2 Workflow项目过程中，我们合理制定了不同阶段的测试策略，收到了很好的效果。

　　产品开发期同情的测试

　　要忍！要在这个能够发现大批Bug的黄金时段学会做减法。现实而言，这个阶段的产品，大多难以满足系统测试的条件。如果进行穷兵黩武式的测试，无疑会加重开发人员的焦虑心情，甚至对测试产生逆反心理。另一方面，测试工作不应停滞，特别是不少测试人员对产品的了解还流于皮毛，抓紧时间进行“测试练兵”非常有必要。因此，“产品开发期”的测试切忌生硬。其实，此时程序人员也知道产品还不成熟，所以要告诉测试执行人员：

　　● 这个阶段不要提交界面简单错误和易用性方面的Bug（可以先记录下来到项目末期提交），否则会使开发人员质疑测试人员只会发现简单的Bug。

　　● 换位思考，了解此时开发人员关心的是功能是否能正确运行，多对基本功能进行测试。
　产品成熟期积极的测试

　　随着产品的不断成熟，主要功能的实现已经趋于完善，关键路径的测试已经不成问题。此时的程序员们，压力已经大大减轻，他们的工作重点也从“构建”转移到了“修复Bug”，这个阶段程序人员对于Bug的接受程度是高的，对Bug的修复和反馈也非常积极。于是，此时的测试工作应对整个产品的细节和所有路径进行覆盖测试，保证测试的全面性，层层深入地测试产品值得测试的各个部分，尽可能多的发现并报告Bug。

　　产品稳定期多样的测试

　　在这个阶段，可以尽情的向开发人员报告产品易用性和界面的Bug；可以充分发挥每个测试人员的想象力，根据以往的测试经验来搭建测试场景，构造测试数据；可以通过不同业务场景的不同操作，通过特殊的测试数据，以及相对复杂的集群测试环境来进行多样化测试。为什么？因为此时必须测试得更加深入，才能发现更深层次的Bug，于是多样性的测试、探索式的测试必不可少。产品发布期谨慎的测试在临近产品发布的日子，包括测试在那的很多工作都变得谨慎起来：代码的提交权限受到了控制，只保留开发经理一个入口；测试的重点更加具有防御性，要仔细测试每个变更，还可以组织“结对测试”来增加测试的保障。测试经理应知人善任为了保证测试工作的质量，首当其冲地是应该有专业的测试团队。在很多小的软件项目中，往往没有专门的测试团队。这样一来，到了代码基本完成之时，只能从客户支持部门或研发部门抽调一些人手临时拼凑出“测试团队”进行几周的测试工作，测试质量难以保证。我们则会尽早规划测试团队的人员结构，完善测试团队的配置。每个测试人员的特点和强项常常不尽相同，例如，擅长测试数据质量的测试员，未必能胜任系统环境配置复杂的测试任务。总之，对测试经经理而言，做到知人善任非常重要。同时，在项目测试过程中及时进行调整有时也很必要。此次测试的工作流系统，要求测试人员不仅应掌握一定的工作流业务知识，还需要有较强的逻辑思维能力。而在此项目测试过程中，笔者发现一位测试人员对功能的细节过分关注，而对整个工作流程总是理解不到位。显然，其设计出的测试用例不能适应工作流测试的要求。于是，立即进行人员分工和测试任务的调整，保证了测试工作顺利进行。坚持立场，规范流程我们公司有严格的测试流程，所有提交测试的软件版本，在提交之前，都要完成必需的冒烟测试（Smoking Test）。冒烟测试是一种测试包，其目标是检查版本的基本功能。这个测试包是由测试人员根据测试用例中级别为“基本”的测试用例抽取出来的，如果该版本没有通过冒烟测试，则可以说明该版本不太稳定，不值得提交测试人员进行系统测试。有的公司冒烟测试是由测试人员手工或者自动测试。在我们这个项目中，为了保证每个可测试版本的冒烟测试质量，是由开发人员负责完成的。他们知道，如果程序不能通过冒烟测试，测试小组会拒绝该版本。因此，他们会填写一份提交测试申请表来申请进行系统测试。在这份表格中，不仅会明确版本号，修改或新增的功能详细说明，还会给测试人员提供此版本的测试重点，以及可能会影响到的功能。这些内容对测试人员都是至关重要和大有裨益的。

　　在项目测试过程中，我们也出现过打回某个版本的情况，拒绝测试。总结起来，基本上有以下几种情况：

　　● 由于任务查询的技术难度比较大，开发进度已经延期了5天，测试人员正在焦急的等待这部分的功能测试。可是，新提交的可测试版本中，这个功能根本不能使用，如果进一步测试是浪费时间，我们立即打回了这个测试版本。

　　● 新增了代办的功能，可是以往的代理功能中的增加代理人功能却不能正常使用，而增加代理人功能又是代办功能的基础，也是说，在这个版本中，及时代办功能完全能够测试，可离开了增加代理人功能，代办测试是没有意义的。

　　● 在回归测试阶段，可测试版本的提交是比较频繁的。开发人员一旦解决了一部分bug会提交一个可测试版本，如果此时测试人员并不急需更换版本，并且得知另一个版本会在几个小时之后会完成，我们可以不测试这个版本。为了能更好的完成冒烟测试这个关键阶段，测试人员积极与开发人员配合：

　　● 负责提供冒烟测试案例。

　　● 如果测试人员处于版本等待阶段，主动和开发人员一起做冒烟测试。开展有效测试，提高测试效率有效的测试用例是软件测试成功的关键，有助于提高测试效率和测试覆盖率。在这个工作流软件测试项目中，我们从测试模型（Test Model）入手，结合丰富的测试经验和专业知识，从繁多的测试用例中挑选出有效的用例，用尽可能少的测试输入，覆盖尽可能多的软件需求。主要采用了状态机模型和组合模型，并结合了正交设计技术和组合覆盖技术，完成了对整个系统的测试设计。知己知彼，合力制胜提供服务使测试人员有机会赢得程序员的信任，同时也有机会展示自己的才能。同时，带来的回报是得到了开发人员对我们的帮助。