我的软件测试之旅：（2）转变——作为专职测试人员

　　后来我被直接派驻客户（诺基亚网络杭州3G研发中心，现诺基亚西门子网络杭州研发中心）现场，再后来被直接买下，成为了诺基亚的员工。也正是从派驻诺基亚那时起，我开始了自己作为专职测试人员的旅程。但编程这个活动一直都伴随着我，直到现在，这也是我从来都不认为开发、测试有着很清晰的界限的原因，欲知详情请继续往下看。51Testing软件测试网*m6tM#o5\vut/V#Z(U

ZU-Q^Yq_0　 　当时我们两家公司合作已经有一段时间，已经有数十位工程师在诺基亚干活，我们这一批人是专门为研发中心某个产品线的测试部门补充人力的。团队管理非常简 单，我们自己公司的事务由自己的外包经理或者叫协作者经理（Collaboration Manager）管理，当然，在我们这批人和经理之间还有小组长（Team Leader）。而从做事情做项目的角度呢，我们则直接由诺基亚的项目经理来负责管理，也即由他们来分配任务、确定时间表等各种事务。

　　该产品线的结构应该属于比较常见的一种，分为几个开发部门和一个测试部门，支持型的部门还有质量管理部 和产品管理部、项目集群（Program）管理部等等。使用的是自己独特的开发模式，类似于瀑布模型，也即分阶段、基于文档的开发模式。一个产品的开发会 被分割为多个项目集群，而后项目集群再分作多个项目，每一个项目又分割为多个子项目。通常一个子项目也即是某个或某些模块的开发任务，或者测试任务，测试 和开发是独立分开进行的子项目。测试项目要等待整体的开发完成之后才开始。51Testing软件测试网/w&G:nuNLE9k

cj`5Y%]f0　　刚到诺基亚时，我颇为感慨，果然是大公司啊，真是有风范，的 确很有人文关怀的感觉，我们所担心的事情都有人考虑到。当时，诺基亚的新员工都要先参加总长度两个月的入职培训，包括从诺基亚介绍、价值观等人事的部分， 也包括对产品线产品的介绍，以及开发模式的介绍，以及开发、测试具体流程的介绍，总之，非常的全面，凡是未来会用到的全都有涉及到。只要保留好课堂的材料 和自己的笔记，回头上手干活基本上没有任何问题。

　　机缘巧合，我还在参加培训就被小组长抽调过去先参与到测试项目的工作中 去了，也许是因为我看着比较顺眼吧……当时的我心中非常忐忑，不知道该如何干活，所幸有诺基亚的导师（Tutor）制度在，小组长给我安排了一位导师（在 此要非常感谢她的辅导，帮助我顺利地融入诺基亚的氛围，真的非常感谢！），她教给我作为一个测试人员所要做的各种事情，给我很多的相关资料可以自我学习，也手把手地指导我执行以及分析和写测试报告等等很多很多。总之，和她配合，我受益颇多，测试项目开始不久，我就差不多已经可以独立工作了。51Testing软件测试网'LX U'w[

　　我加入时导师已经在开始执行测试的阶段，于是我主要是要去理解测试计划、理解测试用例， 熟悉测试工作和被测产品，掌握测试执行的各种操作命令。测试部门的知识传承做得相当不错，所有的文档都有模板和介绍，很容易就上手，知道各个部分写的是什 么东西，以及如何使用。而且在测试用例中，不止包含测试步骤，通常也包括要执行的命令，和每个步骤的预期结果，以及最终的预期测试结果。测试报告也有模 板，只要按照模板的要求，将测试时的环境，被测对象的各种版本信息，执行的命令和返回的输出等等各种信息都记录下来就行。51Testing软件测试网$X{
H:ow7Md1b

2c&Tb`.m#{#BY0　　当我渐渐地熟 悉如何执行测试后，就开始对周遭事物有着各种好奇，成天都缠着导师问各种问题。一开始主要是在测试失败，或者得到一些不完全符合预期的输出时，不知道该算 是通过还是失败，就要去找导师请教。慢慢地就开始问很多关于，为什么要这么设计这个用例啊，到底要测试的是什么功能，之类的问题，而导师的回答总会附上一 句，“多看看功能需求说明书吧”。于是我就开始看功能需求说明书（Functional Requirement Specification），从中去理解我所测的对象所应该实现的功能。功能需求说明书也是有模板的，不过依然会出现不清楚或者难以理解的地方，这也是 让测试人员很头疼的地方，因为无法确定测试的对策。最好的解决办法就是去问文档的作者，只不过这份文档的作者通常就是其开发人员（或者开发人员所在领域的 专家），而他们通常都比较忙，忙着进行后续版本的开发（针对同一版本，测试总在开发完成后开始，所以测试开始时，开发人员都已经在做新功能的开发了）。51Testing软件测试网.Do.~'T w#|

4duIk!L!Fkd:`0　 　而我的幸运则在于，当时开发那个功能模块的开发人员人都很好，是公认的牛人，而且很健谈，很愿意和测试人员交流（基于开发项目的进度压力，这一点还是比 较难得的）。而且他的特点在于，除了开发自己负责的模块，他会花很多时间，多数是自己的业余时间，阅读其他模块的代码，而后是其他领域（Domain，技 术领域）。他后来的发展也非常快，因为他阅读的代码很多，所以开发起来也就速度很快，了解的多分析问题也就很快、对整体架构把握也好。而我则是从他身上了 解到很多该模块设计的原理，以及所要实现的功能，和服务的对象（其他模块），对我理解被测对象从而更好地有针对性地进行测试帮助非常大。51Testing软件测试网"p x7_m]

;E4~:]Vs:k0　　这一个模块的测试还有一个比较特殊的地方，它其实是支持型模块，为系统内其他模块提供调试、日志相 关的服务，所以测试中很必然地要针对各种情况下的记录、显示灯功能进行验证。如果直接借用现有模块来测试，会有一定的困难：首先是处于稳定性的考虑，其他 模块一般都是要等到我们测试完成了才会开始使用；其次，就算有一些模块在使用，也不大会专门为了测试而频繁地修改它的代码，编译，然后提供给我们用于测 试，除开开发人员工作繁忙，也还有编译和版本管理实践很花时间的原因。因此，我必须要自己开发一些测试应用程序（Test Application），这个程序里面，使用被测对象所提供的服务，并且要知道如何修改产品的启动列表，从而可以使这个测试应用程序可以在设定的时间点 其中以及打印相关的信息。51Testing软件测试网%q a.Ogc1C t

.o7~*yA}C.A*}0　　我们当时所使用的测试工具也是诺基亚内部的工具部门自己开发的，说实话，相当好用。由于我们的产品具有自己的一套人机交互界面，所以只能用自己 的工具来操作测试。这个测试工具自带的就有提供一个类C的脚本语言，可以很方便的写测试脚本，语言本身也很简单，上手不难，而且会写一点脚本对于测试 工作的辅助作用也很大。因而，从这个角度出发来看的话，我们并不存在完全手工的测试。51Testing软件测试网7EI$c"_&u

%Gj(b]2aR4x#a0　　做测试不可避免地肯定会发现软件的缺陷（Bug），发现缺陷之后需要将相关的信息记录下来，录入到缺陷追踪系统中去，开发人员会相应地收到通 知。看到这里大家脑海里恐怕会浮现出一幅景象：测试人员提交缺陷报告后，过了好久开发人员终于回复过来“缺乏信息，需要得到某某模块的输出”，测试人员又 吭哧吭哧地重现场景，再填好信息发过去，结果开发人员又要求别的信息，通常都要来回好几趟，才最后可能定位出问题根源，然后开发人员开始修改。当时我们的 流程中对于开发人员最后的回复有一些要求的，定位出问题根源后，需要给出描述，以及计划在哪一个版本中进行修复，有一个例外，就是如果这个问题是“正常 的”，不用改，那么通常会标识为“无需修订”（CNN，Correction Not Needed），打回给测试人员，结束当前的缺陷追踪流程。如果测试人员对此有异议，就好玩了，就开始打嘴仗，最后再和开发、测试的资深工程师（一般是相 关技术领域的技术专家和测试专家）一起讨论定夺。缺陷修复的速度主要受到测试开发双方人员沟通效率的影响，从发现缺陷并记录下来，到定位出问题根源制定修 复计划，通常以天数计算，而修复的过程，一般来说都是以小时计算，个别疑难问题稍微多花一些时间。51Testing软件测试网AIO8j5Uw2CM

　　有一次，我发现了一个错误，然后把现象记录下来，提交到缺陷追踪系统中，结果开发人员的回复是无法重现。于是我在测试环境中又再执行了好几次， 发现问题都能够很稳定的重现，于是就再通过系统把这个信息返回回去。幸得开发人员也是态度很积极的工程师，估摸着心里很好奇，就直接来找我，于是我就在座 位上给他重现，结果，居然没有重现成功！让人百思不得其解。长话短说，后来发现原因在于我之前执行的时候，都是用跑脚本的方式执行，而我们现场调试是手工 执行的方式，但这两种方式的差别在哪里呢？经过仔细地分析，我们发现和测试用例的步骤有关。测试用例是要在一个会话（Session）上监听消息（产生特 定消息是模块的功能之一），所以我们会先打开一个会话开启监听，然后再打开一个会话，再里面进行一些操作，然后回到之前的会话里去查看相应的消息是否有出 现。而手工和脚本的差别在于，手工的情况下，我们人眼看到操作结束，就返回到第一个会话去停止监听，而后检查监听到的消息。在脚本中，为了确保操作是成功 的，通常会等待一点时间，然后再切换到第一个会话执行后续的动作。但最大的区别在于，手工操作时，我们可以在测试工具中打开两个小窗口，监听和操作的会话 都是处于活动状态（Active）的，而在脚本中，则只有当前会话处于活动状态。

　　通过多次地现场协同重现缺陷场景，开发人员确定该问题不是被测的模块所引起的，还给了我一些建议，建议我找会话管理这一块的人来看看。后来发现 这正是问题所在，通过分析之前执行的测试日志记录，包括我们现场重现的情况，对方很快就确认原因是会话超时（Timeout），为了节约资源避免浪费，每 一个会话都有超时时间，超过这一时间没有任何动作的话，会话就会被关闭。而我的测试中，恰好离开第一个会话再回来，中间的间隔就超过了这个超时时长，导致 会话关闭，第一个会话中的监听无法得到要监听的内容，测试结果分析的时候得不到预期的结果，测试也就无法通过了。修复非常的简单，对于会话超时处理的地方 修改几行代码即可，但这个问题解决（Troubleshooting）的过程才是最艰难的地方，需要我们细心检查，发现任何可能的蛛丝马迹，甚至还要发挥 想象力，将不同线索联系起来，最终才定位出缺陷的根源。51Testing软件测试网"hj7QZ]2F |`

F+[(n+yC
w*V0　　正由于上述提到的缺陷管理时间中的沟通成本，我们一直在思索如何能够改进。一是从缺陷管理工具入手，加强它的功能，提高它的速度；二是从缺陷管 理流程的角度出发，尽量简化，提高它的可操作性；三则是从组织架构方面出发，思考是否可以改变现有开发模式，拉近开发、测试人员之间的距离，使得沟通无需 依赖工具也可以进行。51Testing软件测试网BM~ I@8KE

b%F6Bk6W0相关链接：

:@t!c ?s*RGP7L0我的软件测试之旅：（1）起点——作为软件开发人员51Testing软件测试网;~KE9iJ)~1]j n d.]