工作了40天，终于完成了项目的开发，在测试方向有点感受，分享一下。

　　项目背景：

　　项目背景基本是一个调度系统，用户在web页面做相关的参数输入，之后通过rpccall到server，server再进行相关调度，发送命令给各个client，而client再和分配在各台机器的agent进行通讯完成最后的操作。整个项目4个人完成，2个同事做web相关的开发，我做client和agent相关的开发，另外一个同事做调度流程的开发，可以说是一个经典的前中后协作开发。

　　1、测试的目的和意义

　　首先非常明确，在前中后集成阶段之前，测试的最终目的必然是为了隔离异常。因此任何时候都需要从这个基点出发，这样才能迅速有效的定位出问题。

　　集成测试阶段的目的我的理解是为了看系统是否符合需求的应用场景，因此无论是手动还是自动测试的基本测试case一定是要符合应用场景的，尤其是主要的用户场景。

　　集成测试之后的测试主要包括稳定性测试（测试大量请求下系统的状况），longhaultest（对于一个长请求下系统的状况），failover测试（对于系统recover后的表现），复杂场景的测试。（集成测试中几个基本场景的交错测试）

　　2、测试的计划

　　之前了解各种测试名词，探索性测试，mokey测试，单元测试，系统测试，集成测试，冒烟测试等等，但是具体是什么阶段用什么测试方法倒是不甚清楚，这次整体观察了一下。

　　a、第一阶段，在各自模块开发中，对于自己所开发代码每个关键feature都需要由UT来覆盖，因为在后续的开发中经常会出现feature的refine或者是新feature的加入，所以有效的测试case的回归，可以有效的保护好已经完成的代码，如果某天发现了测试casefail，那么就能隔离出是新进入代码的问题，而当新feature要进入svn的时候，对之前的UT的回归也是发现问题的有效手段。只有如此，才能了解到目前代码的整体情况，不是有位前辈说过，测试的是唯一能够让项目管理者了解目前项目的进度的指标，我的理解测试也是帮助开发人员了解自己新开发代码对已有代码影响的唯一方法。写UT的时候我们明确了一个观念，我们不要求UT的覆盖率，但是要求了UT所覆盖的关键路径。

　　b、第二阶段，在自己模块开发中，我们做了2件事情。1件是写桩，1件是写驱动器，为集成测试做装备。桩是自己模块对外部调用者的镜像，驱动器是自己模块对外部调用者的假设。在集成之前，我写了驱动器，按照之前定义的接口，用驱动器来调用我写的client，来观察我所写的client和agent的运行情况，同时驱动器模拟了各种异常参数的调用方式，用来做异常处理。注明一下，这里的驱动器其实很简单，就是一个main函数，里面调用了我的模块对外提供的服务。

　　桩的做法就是利用抽象工厂方法，写了一套mock的client，每个mock的client对外提供了我真实client返回值一样的内容，这是为了2个目的。一个是为了在真实驱动下做性能测试的时候，为了隔离是我的模块出了问题还是驱动器模块出了问题做的准备，即如果真实驱动器在我的mock的client下依旧性能表现不佳则说明问题出在真实驱动器调，但是如果在mock下性能表现很好，那问题必然出现在client端。

　　c、进入了集成测试后，由于驱动器和mock的作用，我们首先调通了真实前端，真实中端和mock后端，以及mock前端，真实中端和真实后端的测试。之后前中后端联调。在集成测试中，作为测试人员需要理解每个场景的转化，脑子里面需要有一个系统状态转换图和一个流程图，理解了系统的阶段变化不光有利于系统测试而且对之后的failover测试和复杂场景的系统测试也很有帮助。

　　d、基本的前中后端两两的集成测试完毕后，开始进入了系统测试。系统测试就是基于最初系统定义的用户的基本使用场景，做的正确性验证。这个阶段做的很简单，就是不断的在前端点击然后去验证数据库的状态变化，去看后端的调度是否有异常，看看预期的输入是否有预期的输出。这样将最终的20多个基本场景都测试ok。

　　e、系统测试之后我们当时以为万事大吉了。结果在一次意外的测试中发现了server挂掉了以后系统数据库的调度状态异常，然后就紧急做了failover测试，所谓的failover测试的意义就是在serverdown掉后recover后系统的状态是否能够根据遗留下来的现场环境重新进入到正常的运行逻辑。我们的遗留现场就是serverdown掉后数据库的状态，此时各个task都运行到一个中间状态，需要在server重启后分别处理这些运行task的后续运行情况（该终止的终止，该设置过期的设置过期）。

　　f、failover测试后，我们开始做稳定性测试和longhaul测试。因为我们是一个调度系统，但是确没有那么多的后端机器，因此我们按照上线的规模，利用mock的client，开始发送大量的request，来测试调度算法的效率。并且同时运行了多个长时间的task来验证系统的稳定性。

　　g、最后review了一下整体的测试状态。发现我们大部分的测试都是基于一个初始状态来做的测试，即数据库为空的状态，而并没有做过基于历史数据做的测试。因此在之后我们在数据库中用mock的前端发了很多请求，在数据库中建立了很多数据，然后再发送请求，用于验证复杂场景的测试。所以说复杂场景简单的说就是先运行一个或若干个场景（即那些提前准备好的数据），然后再运行若干个场景后系统的状态，这些场景有可能是异常场景也有可能是基本场景，所以说复杂场景的组合是非常难测的，因为覆盖率可能是N*N*N....的组合。但是这样的场景往往是能发现问题的，比如在我们的系统中就发现了因为之前的场景在使用完毕后没有释放掉基本的资源导致之后的场景无法使用。也发现了因为之前的场景损坏了资源导致了级联反应......

　　3、测试人员和开发人员的看世界的角度

　　因为我本身是系统的开发人员也是系统的测试人员，所以非常强烈的感受到了这两种角色的世界观的不同。

　　开发人员更多的是从代码的角度来看问题，当遇到一个新场景的时候或者需要增加新feature的时候，脑子里面立刻是代码流程的运行，是什么数据push到什么容器里面，在某个地方来开线程等。

　　而测试人员的脑子里面完全没有代码的概念，取代的是两张图，1张就做系统流程图，1张就做状态转换图，这两张图前者来自于需求，告诉了测试人员外部需要什么，后者是系统在不同的阶段应该是什么的状态，告诉了测试人员系统能够提供什么。这两张图是需要不断迭代的，最初可能只是一个初步的概念，之后需要不断分解，最后越来越细从而最终控制系统的走向，对开发人员应该加什么feature，必须删除什么feature，都必须有严格的要求，因为开发人员是自己想需求，而测试人员才是真正接触需求的人，必须强力控制，必须态度坚决。