基于产品的测试管理—用友软件测试流程
作者: 来源: 文字大小:[大][中][小]
众所周知，软件研发周期包括以下几个主要阶段：需求分析、设计、编码、测试、实施、维护。由这个模型产生的问题是：测试阶段何时介入？
在用友软件，测试人员是从需求阶段开始介入的。在需求和设计人员完成了产品定义，并形成需求文档后，会由各个产品模块（这里的产品模块指ERP产品里的各个子产品的细化，例如销售、采购、总账、生产制造、固定资产等）的测试负责人参与需求评审。同时参加评审的人员还有开发人员。在这个评审的过程中，各方面人员可以尽早的发现产品定义和需求阶段的问题。测试人员参与评审，目的在于，利用测试人员对业务以及用户应用场景的了解，发现需求中不合理的地方。
在这个过程中，对参与评审的测试人员对于产品应用场景有相当程度的了解，因此，一般多为有业务背景、有测试经验的人员或QA来完成。
测试人员在需求阶段介入，可以及早的发现问题，使产品的后续研发过程可以更顺利的完成，以保证最终产品的有效性。
同样，在产品设计阶段，也需要有经验的开发和测试人员参与设计文档的评审。开发人员从产品实现的角度，对设计方案的可行性进行评估；而测试人员则从用户的角度，对设计方案的实施性提出看法。这样，可以最大限度的保证最终产品的可用性。而需求人员在这个过程中的作用，则仅仅是检查设计文档是否遵循产品定义和需求分析文档。
以上两个阶段，是在测试阶段以外，测试人员介入最多的两个阶段。并且我个人认为，测试人员在这两个阶段是起了很大的作用的，因为毕竟在整个研发团队中，只有测试人员是最了解用户应用场景的，也是唯一对用户负责的一个角色。
在编码阶段，测试人员是基本不参与的。这个阶段的单元测试，就交由开发人员自己来完成。这里所说的单元测试是完全基于方法的白盒单元测试，与后面所提到的基于UI的单元测试是有所区别的。之所以这样做的原因是因为，在国内，白盒测试还没有真正的发展起来，而对白盒测试人员要求比较高，受对测试人员的投入所限，专门的白盒测试在像用友这样的国内企业中，很难实现。因此，真正意义上的白盒单元测试，在用友，简化成了由开发人员自行完成的类调试阶段。
而在编码阶段，测试人员开始进入编写测试用例的工作。在此期间，也是一些普通测试人员熟悉产品，了解需求的过程。
真正的大规模的测试阶段，开始于能够实现独立功能的单元模块开发完成时。此时，测试人员开始进行基于UI层的单元功能测试。依据需求文档和测试用例，检查各单元模块内部的主要的基本功能。并依照《UI规范》文档进行UI测试。当然，单元测试阶段是远远不够的，这就是我们后面要谈到的测试阶段。测试工作由此开始，一直持续到产品发版。
在产品发版后的实施和维护阶段，测试人员参与也很少。在实施初期，会有少量的测试人员协助实施人员进行产品的实施工作，以及对用户的培训工作。而在维护阶段，则有专门的部门来完成，测试人员基本上就不再参与了。
以上就是用友产品研发过程的一个概要。下面我们来谈谈这其中的最重要的一部分：测试阶段。
用友内部的测试主要分为以下几个阶段：单元测试、联调测试、集成测试、用户测试、顾问测试。在不同的测试阶段，测试小组所关注的对象和问题有所不同。
单元测试：这里所说的单元测试，是完全基于UI的黑盒功能测试。是指对于产品的基本单元内，功能及UI的测试。其目的是保证基于UI的最小功能单元的所有功能的正确实现以及各单元间接口功能是否实现。在此阶段，测试人员关注的是单元内部的功能及UI可用性测试。对于单元间接口，只关注接口是否正确挂接，是否能正确驱动。而至于接口间的数据传递以及运算逻辑是否正确，则是联调阶段关注的问题。
单元测试的过程是先由开发人员提交单元测试提交单，交给对应的测试人员，测试人员在规定时间内，依据单元通过标准，对该模块是否通过单元测试（在用友，这个过程也被称作：单元验收）给出结论。若通过，则说明该模块的基本功能已实现，并达到发版标准，可以进入联调测试。若不通过，则打回开发人员进行修改bug，并进行再次提交。
在用友的测试管理过程中，对于单元提交有着很行之有效的约束机制。如果某单元模块提交单元，两次被打回，则一周之内不允许再次提交，并对开发人员进行相应的考核扣分（会影响当季的奖金）。以此来保证开发人员提交到测试人员手中的代码质量，也避免测试驱动开发过程中带来的开发过分依赖测试人员的负面影响。
当某个流程中的所有或者主要的单元模块都通过单元验收后，该流程就可以提交进入联调测试阶段。
联调测试：从名字上来讲，这是一个用友公司根据自身产品特点，而创建的一个过程。它是在单元测试和集成测试之间的一个过程。其主要对象是单产品内各单元模块集成在一起，保证各个单产品的全部功能实现和性能的稳定。
一套ERP系统很庞大，集成测试的工作量会非常大。如何能够在有限的时间内，实现产品质量的最大保证，是ERP产品能否拥有市场的关键。为了保证集成测试的顺利进行，用友公司特别设计了这个联调测试阶段。实际上就是单产品内的集成测试。这样可以有效的保证每个单产品提交到集成阶段以后的质量。
测试人员在联调测试阶段，主要关注各单元之间的接口实现，数据传递，算法逻辑等。而对于单元内部的功能，UI则放在次要关注。这个阶段的任务和目标是，确保单产品集成功能的实现， 能够本达到发布标准。
在联调测试阶段，除了功能测试之外，性能测试也会占有一定的比例。
当所有的单产品集成达到发布标准后，就可以进入全产品的集成测试阶段。
集成测试：和所有的集成测试一样，用友所定义的集成测试也是在产品发布最后阶段进行的系统集成。包括各种环境的布署，对不同操作系统的支持，对多语的支持等。这个阶段除了手工的功能测试之外，还会进行一定比例的自动化测试和大规模的性能测试。
集成测试阶段所关注的问题是各单产品之间的接口实现，数据传递，业务处理，算法逻辑，以及系统整体性能，用户体验等。在这个阶段还要大量进行的就是并发互斥的测试。
上述三个阶段是主要的测试阶段，根据产品的进度会有部分重叠。
此外，在集成测试阶段后期，会开展一定规模的顾问测试以及用户测试。即找一些行业顾问和真实用户，对产品做一个整体测试。以扩大测试的覆盖度。
以上就是用友公司自己的一套行之有效的软件测试管理流程。最后再简要的介绍一下针对这个流程而设计的组织架构。
用友的三大产品本部隶属于研发中心。研发中心下面，划分为U8、NC、U9三大产品本部、测试中心、开发管理部、人机工程部以及其他研发部门。
以一个产品本部为例，本部下面并列的是各单产品开发部、分析设计部、支持部门（开发工具维护、网络布署管理、日常事务处理等职能部门）。上述三类部门是隶属于产品本部的。除此之外，还有三个独立的第三方部门：测试部、开发管理部和人机工程部。 这三个部门是与产品本部在同一个行政级别上的。这里所说的测试部，就来自于上文提到的测试中心。
在每个产品本部内，测试人员分为两部分，一部分是在各开发部内部的测试小组，他们直接对各开发部负责，隶属于各个开发部。这部分测试人员的主要工作职责是进行单元测试和联调测试工作。并最终把单产品提交进集成测试，协助测试部进行集成测试。
第二部分是测试部。他们来自于测试中心，独立于产品本部。其部门经理在组织机构图中是与产品本部处于同一层级。针对三大产品，分为三个部门：测试一部、二部和三部。测试部的主要任务是进行产品发布前的集成验收测试，组织实施性能测试、并发测试、用户测试等。
最终产品是否可以发布，是由测试中心、行业专家、用户、QA、本部经理共同评审后得出的。