工程测试经验总结说明：以下工程测试经验是我在原来公司工作中的实际经验，拿出来和大家一起沟通。我信任之前的工程测试工作中有不少可以改良的地方，还希望大家多多沟通。 工程测试经验 ——Judy Shen 本文是对我近几年测试工作经验的总结，并以简报的方式在研发中心内进行分享及沟通。 1 测试团队介绍 在介绍我们之前工程测试工作之前，需要首先介绍一下之前我所在团队的组织架构及测试人员在工程中的工作。 我们的测试团队属于质量改良中心下的测试部，它和研发团队属于两个不同的中心。测试团队有 6 个人，从图一可以看出来，一个人可以参加多个处于不同阶段的工程测试工作。图一 测试团队组织架构 参加工程的测试人员以测试组的形式进入工程，测试组和需求组、开发组并列。每个测试组有一个测试组长负责工程测试工作。工程经理不直接面对测试组成员，而是通过测试组长进行任务安排、协调、沟通。测试部经理知情测试人员的工程测试工作，工程测试组的工作汇报均需要抄送给测试部经理。如图二所示：图二 工程组织架构〔旧〕 上面说到的是旧的测试人员工作模式，在去年年底，为了有效利用公司测试人员资源，我们开始了测试外包的尝试。这里的测试外包模式是指，测试组不进入工程，而是由工程组将测试工作以一个工程的方式分包给测试部，由测试部根据工程组提供的信息，进行方案、执行测试，并根据工程要求提交测试成果给工程组。 这个模式还在探究中，如图三所示，测试部经理直接负责工程的测试工作，测试组的工作情况抄送给工程经理。这种模式需要进行独立核算，包括本钱估算、预算、结算等。但是这种模式的整体思路还不是很成熟，从这个组织架构上大家也可以看出来，很多东西还没有理顺，所以一直都处于尝试过程中。后面提到的内容，假如没有特别说明，都是在旧的模式下进行的。图三 工程组织架构〔测试外包方式〕 我想不可否认，大家都认为测试人员应该是测试技术上的专家，但是，测试人员是否需要熟悉并擅长一定的业务呢？不管答案是什么都没有关系，但是我认为一个好的测试人员不仅是测试专家，他同时也是业务专家。有一些测试人员，因为系统的业务知识很复杂，就一头扎进去，几乎全力去学习业务知识，测试技术的学习和讨论没有跟上，结果不是设计出大量冗余的测试用例，就是很多方面没考虑到，面对客户的不当请求，也没有底气说测试应该怎么做，弄得做起工程来辛苦异常，个个苦不堪言！ 有着样的说法：“软件测试人员要...
