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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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