下面是我3年前在公司做的一个项目测试经验的交流，主要介绍自己以前是如何在项目中做测试的。过了3年，有些东西可能不一定适用，贴出来仅供参考了。

在介绍我们之前项目测试工作之前，需要首先介绍一下之前我所在团队的组织架构及测试人员在项目中的工作。

我们的测试团队属于质量改进中心下的测试部，它和研发团队属于两个不同的中心。测试团队6个人，从这个组织架构图中可以看出来，一个人可以参与多个处于不同阶段的项目测试工作。

参与项目的测试人员以测试组的形式进入项目，测试组和需求组、开发组并列。每个测试组有一个测试组长负责项目测试工作。项目经理不直接面对测试组成员，而是通过测试组长进行任务安排、协调、沟通。测试部经理知情测试人员的项目测试工作，项目测试组的工作汇报均需要抄送给测试部经理。

上面说到的是旧的测试人员工作模式，在去年年底，为了有效利用公司测试人员资源，我们开始了测试外包的尝试。这里的测试外包模式是指，测试组不进入项目，而是由项目组将测试工作以一个项目的方式分包给测试部，由测试部根据项目组提供的信息，进行计划、执行测试，并按照项目要求提交测试成果给项目组。这个模式还在探索中。如图所示，测试部经理直接负责项目的测试工作，测试组的工作情况抄送给项目经理。这种模式需要进行独立核算，包括成本估算、预算、结算等。但是这种模式整体的思路还不是很成熟，从这个组织架构上大家也可以看出来，很多东西还没有理顺，所以一直都处于尝试过程中。后面我们交流的内容，如果没有特殊说明，都是在旧的模式下进行的。

我想不可否认，大家都认为测试人员应该是测试技术上的专家，但是，测试人员是否需要熟悉并擅长一定的业务呢？不管答案是什么都没有关系，但是我认为一个好的测试人员不仅是测试专家，他同时也是业务专家。有着样的说法：“软件测试人员要两条腿走路，左腿是测试技术，右腿是业务知识。只有两条腿的健壮差不多，走路才稳当。”出于这种思想的考虑，在原来的测试团队，我们每个人都有两个学习、研究方向，一个是技术方向，一个是业务方向。但这在工作开展上有些困难。如果公司认为测试人员应该绝大部分时间用在项目测试工作上，那么测试团队既要研究测试技术，又要学习业务知识，是比较难的。在我们以前的测试团队的工作中，有一部分工作时间是用来进行部门建设的，公司允许部门建设工作占整个团队工作量的30%。部门建设工作中包括前面说到的技术研究、业务学习，还有就是部门搭建所需要进行的一些工作。将部门建设工作分开，主要是用于统计部门成本和测试成本用的。

前面说到了测试人员是以测试组身份进入项目开展测试工作的，但不是每个成员上去都从事同样的工作。在进入项目组工作时，每个测试人员所充当的角色是不同的，项目的测试角色划分为以下四种。在实际工作中因为测试人员数量有限，所以经常是一个人担任多个角色。

了解了原来测试团队的分工之后，下面介绍一下测试团队的工作内容。测试团队承接的工作中，测试技术研究，属于提高团队工作技能的工作，在整个部门范围内进行，这里属于部门建设工作；对于项目中的测试人员有可能需要进行，如果项目采用新的测试技术或者测试工具，那么就需要项目测试组成员研究测试技术了，这部分属于项目测试工作。培训指把内部研究的成果在团队内使用，在适当的时机在公司内传播。我们测试团队在2004年进行了21次内部培训，7次公司级培训。因为每个人各有研究重点，所以我们每个人都是团队内部培训的讲师。

说到测试工程师的工作内容，那么就涉及到测试工程师该做的和不该做的。当然这和公司对测试人员定位有关，这里仅指以前的组织。要说该做的，那么我们需要先明确为什么我们要测试？这是因为存在“系统错误很多、系统不是客户想要的东西、系统实现没有遵照系统需求”等这样的背景。在这样的背景下，产生了测试，但是又因为开发人员自己测试自己的东西，难免测试不全面，所以产生了测试工程师这个角色。因此，测试人员他该做的，就是测试软件产品和用户需求不一致的地方，并尽可能多的发现缺陷，能够向PM汇报软件质量状态。但是在实际工作中，测试人员经常主动或被动的去做了一些不该做的事情。例如说，测试人员认为自己或者测试能够保证软件的质量，以及有意识或无意识的接受了决定软件是否发布的这个权利。

为什么测试无法保证软件的质量，是因为项目的质量，需要项目组的所有成员共同努力，才能达到质量保证的目的。单纯靠测试工程师的力量，是无法实现软件质量保证的目的。

为什么测试人员不适合承担决定软件是否发布的权利，是因为软件的发布，是需要项目组各个小组负责人等相关人一起对系统现在的缺陷、质量状况进行评估后，由PM（或者与会者）作出是否发布的决定。在这个过程中，测试工程师可以提供测试数据、系统当前质量状态报告给与会者参考。

当然，我知道这两点会有很多人不认同，但是没有关系的。我接触的同行中对两点经常有争论。但是，有一些质量大师等权威人士还是全部或部分赞同这两个观点的，如：菲利普.克劳士比曾在他的书中提到软件质量的保证需要全员努力，需要过程的控制的，而不是某个英雄可以保证软件质量的等。（《质量免费》、《质量无惑》）

做了背景介绍后，下面我介绍之前项目如何开展测试工作的。

因为测试过程是整个测试工作的一个纲要，所以首先得从测试过程讲起。

测试过程，我们包括四个环节：测试计划、测试设计、测试执行、测试分析。

测试计划主要是进行描述测试需求、分析制定测试计划工作。在制定测试计划时，经常有人认为测试计划是在整个项目计划制定之后才开始进行测试计划的，事实上并不是这样的。测试计划和项目计划是互相影响的。举个例子。假设项目有进行性能测试的需求，但是测试工具又需要学习，那么我们在测试计划中就需要预留这部分的时间，还有，测试用例的评审，也需要预留时间。或者，如果某部分比较复杂，可能测试需要的时间会较多，或者需要测试的次数会比较多，那么可能要求开发组先安排这个核心模块的开发，这样需要调整开发计划的顺序。所以，测试计划和项目计划是互相影响的。在测试计划环节还包括测试需求的描述，主要是确认需求是可测试的，并将需求细化为具体的可测试点，保证测试设计时可以根据测试需求编写测试用例，而避免遗漏测试点。我们的测试需求需要得到业务分析人员的评审，测试计划要得到pm的审批认可。

测试计划和测试需求例子如图。

对于测试计划，还需要说明的是，在具体的每个测试阶段工作计划中，我们需要定义本阶段测试需要进行的次数。每一轮测试是一个完整的测试周期，按照这里介绍的测试过程进行。通常我们是一天一轮测试，最多是两天一轮测试。通过这种方式，减少了测试和开发之间的空挡时间，即测试等开发，开发等测试。

例子如图所示。肯定会有人疑问，如果一个系统很庞大的话，怎么能在一两天内完成测试呢？是的，如果系统比较大的话，确实没法在一两天内完成一次所有测试点的全面测试，有可能需要一周或更长的时间，但是这样的话，就出现了测试、开发互相等待的情况了。所以，在我们制定的测试阶段计划时，需要指明本次测试的测试重点，测试范围。我可以这一轮测试进行A、B模块基本功能测试，第二轮测试进行C、D模块基本功能测试，第三轮测试，进行主要业务流程测试，第四轮测试，关注负面测试。在我之前的实践中，发现这种方法还是比较有效的。可能大家也注意到了，这个例子是另一个项目的。没错，在今天提到的移动的这个项目中我们没有按照这种策略进行测试，弄得当时我们测试小组工作很累，很被动，经常是开发说测试我们就要马上开始测试，而缺乏计划。实施这种方法后，测试的计划性就比较强，测试不用总是被打扰。

测试设计，主要是根据需求、设计文档进行的测试用例设计工作。(如何从需求导出测试用例)设计测试用例，是整个测试过程中很重要的一部分工作，关系到测试执行效果。但是在刚开始时，系统没有界面，所以我们只能根据系统用例搭建测试用例的初步框架，能写多少写多少。随着对系统的理解深入，加上后面也开发了系统原型，我们就可以不断完善测试用例。即使是在测试阶段，我们仍不断修改测试用例。测试用例我们分为两种，一种是内部测试用例，项目组内部使用；一种是验收测试用例，偏重于业务，供客户使用。两种测试用例的例子如图。

从图中大家也可以感觉到项目组内部使用的测试用例在维护上比较不方便。因为我们的需求并没有做到很细，加上需求本身就是变化的，所以我们的测试需求经常修改，一旦测试需求新增、修改、删除时，测试用例要相应进行调整。这就造成了1)定位测试用例比较不方便，2)测试用例编号修改不方便，3)阅读、执行测试用例不方便。所以，2004年底开始准备团队自己开发一个测试用例管理系统。

在测试执行阶段，主要进行测试的执行工作。如果项目有需要编写或录制测试脚本的话，那么也在这个阶段进行。测试执行结果是在原有测试用例的副本上编写实际执行结果而形成。在我们公司，它是把这个活动单独为“测试实施”环节。

在测试执行结束后，我们开始对测试执行结果进行测试分析并编写测试报告。测试报告的编写上，主要的内容在于对投入的资源、测试结果、缺陷进行分析，并对整体测试情况进行总结分析。对于资源的分析，包括各个测试任务投入的人力情况、实际工作量与计划工作量的对比，并进行分析。测试结果分析，可以通过对测试需求的覆盖情况、测试用例的覆盖情况及测试用例执行结果情况进行统计，并进行分析。缺陷分析，可以通过对严重性、优先级、模块缺陷数、缺陷修复情况等方面进行统计，并分析。例如，对系统缺陷进行统计后，发现存在比较多的可用性问题，如修改操作员所属的组后，无法登录系统等。整体情况的总结可以从测试充分性、软件质量情况、测试活动情况、经验教训等方面进行总结。

注：本测试过程对于每个阶段的测试活动、每一轮测试活动、测试团队承接的各种测试类型均适用。

也就是说，每一轮测试之前，测试组leader需要准备测试计划，确定测试执行重点、目标、测试内容等，选取测试用例，并按照预先选取的测试用例执行测试，测试执行结束，需要进行测试汇报。

因为测试经验教训是很重要的，所以我们团队有专人负责对每个项目测试报告中的经验教训进行汇总，目的让后面项目测试工作可以吸取前面项目测试的经验，避免犯前面项目测试工作同样的错误。

在测试过程中有个很重要的内容是：测试准则。

在实际执行中，我们不难碰到以下类似情况：提交测试的系统经常在测试执行初期，就出现页面访问失败或者正常功能失效的情况；测试人员不知道提交测试的版本改了什么内容或者新增了什么功能，改了哪些缺陷，导致经常碰到开发人员说测试人员提交的某些缺陷所对应的功能不属于本版本集成内容等等。存在这些情况的很大一部分的原因是因为在项目策划阶段时，测试组未就测试准则和项目组达成一致意见，或者已经达成一致，但是并没有严格执行。我们今天要讲的测试准则，主要是针对前者，后者属于管理层面问题，不在我们的考虑范围内。

设置测试准时需要注重实用性。测试准则，通常包括测试进入、暂停、恢复、退出准则。这些测试准则的例子如幻灯片所示。只要是导致暂停测试的问题不存在后，就可以恢复测试。恢复测试时，一般是需要把前面测试内容重新进行测试，所以暂停测试时需要很慎重。

在幻灯片显示的集成测试的退出准则中写到“完成已提交测试内容所能完成的测试”，这里的“所能完成的测试”是指，在当前版本所能进行的测试内容，如在系统刚集成时，可进行界面测试，基本模块的基本功能的测试。

上面的测试准则的例子，也不是很恰当及规范，至少缺少了数据度量部分，这里只是拿出来和大家一起交流。这部分内容我一直认为是很重要的，如果做的不好，测试组的负担会很重。

需要注意的一点是：测试准则，是在制定测试计划时沟通确定的，它需要和相关人沟通，且得到pm审批通过的。

测试准则是死的，实际处理方式是活的。在实际测试过程中碰到同样的问题，是否继续测试，或者需要暂停测试，处理方式不是一成不变的，这是需要根据项目所处阶段来具体情况具体分析的。

下面举个例子，这个例子是经常性的一种情况。假设在测试过程中，我们发现了一个阻塞性错误（流程无法继续往下走等类似情况），是否继续进行测试呢？

在项目初期，进行单个或多个模块的测试时：因为可以执行界面测试及熟悉系统，我们可以接受该版本，继续进行测试。这就属于已提交测试内容所能完成的测试。在项目测试初期，要求不可过于严格。

系统测试：基本流程必须走通。如果基本业务流程（主干）不能走通，则需要根据实际情况来灵活处理。（是否暂停测试或继续测试？）如果是整个流程的初始节点失效，没有这个节点的数据，后面所有节点均无法进行，那么这种情况下就只能暂停测试。如果说是分支流程出现阻塞，那么可以考虑继续测试，然后在测试报告中说明该分支未测试。此时不暂停测试，主要是考虑重新集成一个版本的性价比，也就是是否值得重新集成。

发布前的确认测试：一旦有阻塞性缺陷，马上停止测试。

上面说的是测试过程。下面简单介绍一下我们实际的测试工作。

我们的测试组一般是在项目启动时进入项目组的。在项目立项时，项目经理会向测试部经理申请测试资源。经过评估衡量后，测试部经理会安排一个测试人员作为项目测试组长。当项目启动时，测试组长进入项目，开始了解项目用户需求，起草项目测试计划。在到了一定阶段，例如测试设计阶段，测试部经理会根据项目规模，项目在公司的重要性以及团队其他人员工作负荷情况，安排其他人进入项目组。一般来说，我们一个项目是2~3名测试人员。在项目进入维护阶段时，则是一个测试人员跟进项目。

测试组长根据项目情况及项目阶段计划，定义项目本阶段测试次数。项目经理参考测试组长提供的测试次数建议，以及项目开发的情况，和项目组各个小组负责人沟通后，定义了系统本阶段版本集成时间。在我们的项目里，有一个开发人员兼职做集成人员。在指定的版本集成时间之前的一段时间，各个开发人员将他们的程序提交配置库，由集成人员进行集成（不同语言有不同的集成方式）。集成后，集成人员会简单的进行自测，验证是否集成成功。如果集成成功，就在服务器上给该版本程序打上标签。如果集成不成功，那么返工给相应开发人员修改并重新集成，如此反复直至集成成功。集成成功后，集成人员会提交一份集成说明给测试组长。集成说明内容包括：集成版本路径、版本标签、修改内容、新增内容等。测试组长则根据预先准备好的测试计划开始测试。在开始测试时测试组长会通知项目组测试开始，不允许更新测试环境。测试结束后，也会通知项目组测试结束。

在正常情况下，开发组是预定的集成日期的当天晚上集成，测试组第二天开始测试。如果遇到特殊情况需要当天集成当天测试的话，我们的开发人员会等到测试组通知测试结束后，才能离岗。

如果在完成计划的测试次数后，系统质量仍不稳定或没有达到预期目标的话，那么测试组长将和PM沟通，相应增加测试次数。

关于测试用例的执行，我不知道公司现在是采用怎样的一种方式的。在我原来的团队中，测试用例的主要作用是保证系统功能的测试覆盖率，避免某些功能因为测试周期长而导致测试遗漏。但是我们也采用经验法、试探法、转换思维的方式进行测试，所以，我们一般使用测试用例执行3~4次测试。这可能和我们的测试用例设计能力有关。

我们是采用公司自主开发的缺陷管理系统进行缺陷管理的，使用excel、word进行其他测试工件的编写的。

在缺陷管理上，整体流程基本类似，但是在缺陷分配上，我们测试人员是直接分配给项目缺陷分配专员，一般是业务分析员担任，由他经过分析后进行缺陷的再分配。对于不修改的缺陷，测试人员需要进行确认，如果不认同可以向相关人员提出自己的意见。在系统阶段确认测试前的2~3天，测试组长会将系统未解决的缺陷清单给项目经理确认，并要求pm提供缺陷应对方案。该文档在系统发布时是作为其中的一份附件。

整个的项目测试基本上是这样的一个情况，大家有没有什么其他我没有提到或者说的不清楚的地方需要大家进一步探讨的吗？

其实这就是个标准的测试人员思维过程，有时候想想很简单，一旦深入到业务发现要累死了。

身边很多测试人员，因为系统的业务知识很复杂，就一头扎进去，几乎全力去学习业务知识，测试技术的学习和研究没有跟上，结果不是设计出大量冗余的测试用例，就是很多方面没考虑到，面对客户的不当请求，也没有底气说测试应该怎么做，弄得做起项目来辛苦异常，个个苦不堪言！