我们当时所使用的测试工具也是诺基亚内部的工具部门自己开发的，说实话，相当好用。由于我们的产品具有自己的一套人机交互界面，所以只能用自己的工具来操作测试。这个测试工具自带的就有提供一个类C的脚本语言，可以很方便的写测试脚本，语言本身也很简单，上手不难，而且会写一点脚本对于测试 工作的辅助作用也很大。因而，从这个角度出发来看的话，我们并不存在完全手工的测试。
做测试不可避免地肯定会发现软件的缺陷（Bug），发现缺陷之后需要将相关的信息记录下来，录入到缺陷追踪系统中去，开发人员会相应地收到通知。看到这里大家脑海里恐怕会浮现出一幅景象：测试人员提交缺陷报告后，过了好久开发人员终于回复过来“缺乏信息，需要得到某某模块的输出”，测试人员又吭哧吭哧地重现场景，再填好信息发过去，结果开发人员又要求别的信息，通常都要来回好几趟，才最后可能定位出问题根源，然后开发人员开始修改。当时我们的流程中对于开发人员最后的回复有一些要求的，定位出问题根源后，需要给出描述，以及计划在哪一个版本中进行修复，有一个例外，就是如果这个问题是“正常的”，不用改，那么通常会标识为“无需修订”（CNN，Correction Not Needed），打回给测试人员，结束当前的缺陷追踪流程。如果测试人员对此有异议，就好玩了，就开始打嘴仗，最后再和开发、测试的资深工程师（一般是相关技术领域的技术专家和测试专家）一起讨论定夺。缺陷修复的速度主要受到测试开发双方人员沟通效率的影响，从发现缺陷并记录下来，到定位出问题根源制定修复计划，通常以天数计算，而修复的过程，一般来说都是以小时计算，个别疑难问题稍微多花一些时间。
有一次，我发现了一个错误，然后把现象记录下来，提交到缺陷追踪系统中，结果开发人员的回复是无法重现。于是我在测试环境中又再执行了好几次，发现问题都能够很稳定的重现，于是就再通过系统把这个信息返回回去。幸得开发人员也是态度很积极的工程师，估摸着心里很好奇，就直接来找我，于是我就在座位上给他重现，结果，居然没有重现成功！让人百思不得其解。长话短说，后来发现原因在于我之前执行的时候，都是用跑脚本的方式执行，而我们现场调试是手工执行的方式，但这两种方式的差别在哪里呢？经过仔细地分析，我们发现和测试用例的步骤有关。测试用例是要在一个会话（Session）上监听消息（产生特定消息是模块的功能之一），所以我们会先打开一个会话开启监听，然后再打开一个会话，再里面进行一些操作，然后回到之前的会话里去查看相应的消息是否有出现。而手工和脚本的差别在于，手工的情况下，我们人眼看到操作结束，就返回到第一个会话去停止监听，而后检查监听到的消息。在脚本中，为了确保操作是成功的，通常会等待一点时间，然后再切换到第一个会话执行后续的动作。但最大的区别在于，手工操作时，我们可以在测试工具中打开两个小窗口，监听和操作的会话都是处于活动状态（Active）的，而在脚本中，则只有当前会话处于活动状态。
通过多次地现场协同重现缺陷场景，开发人员确定该问题不是被测的模块所引起的，还给了我一些建议，建议我找会话管理这一块的人来看看。后来发现这正是问题所在，通过分析之前执行的测试日志记录，包括我们现场重现的情况，对方很快就确认原因是会话超时（Timeout），为了节约资源避免浪费，每一个会话都有超时时间，超过这一时间没有任何动作的话，会话就会被关闭。而我的测试中，恰好离开第一个会话再回来，中间的间隔就超过了这个超时时长，导致会话关闭，第一个会话中的监听无法得到要监听的内容，测试结果分析的时候得不到预期的结果，测试也就无法通过了。修复非常的简单，对于会话超时处理的地方修改几行代码即可，但这个问题解决（Troubleshooting）的过程才是最艰难的地方，需要我们细心检查，发现任何可能的蛛丝马迹，甚至还要发挥想象力，将不同线索联系起来，最终才定位出缺陷的根源。
正由于上述提到的缺陷管理时间中的沟通成本，我们一直在思索如何能够改进。一是从缺陷管理工具入手，加强它的功能，提高它的速度；二是从缺陷管理流程的角度出发，尽量简化，提高它的可操作性；三则是从组织架构方面出发，思考是否可以改变现有开发模式，拉近开发、测试人员之间的距离，使得沟通无需依赖工具也可以进行。
相关链接：
