我的测试经历（下）<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

感谢大家对《我的测试经历》的关注，因为比较长不方便更新，所以分成上下集撰写（《我的测试经历（上）》和《我的测试经历（下）》），如果有兴趣，十分欢迎大家继续关注《我的测试经历（下）》。

 

我的测试经历（四）

在入职八个月以后，我们结束了惬意的内部研发阶段，产品正式步入市场营销，由于我们以往缺忽略了市场调研的环节，导致产品与市场的需求严重脱轨。为了适合市场的需要，我们否定了以往60％的工作成果，这相当于带来了远远超过60％的返工工作量，很让我们措手不及，所以部门不得不投入全部的人力资源，从流程制定、产品需求确认、开发框架的采用、研发、测试等等所有的工作方案来了一次大换血。这次历时16个月的产品重组，令我们很多人从中得到了历练，使技术的成长有了飞跃性的突破。

先说说需求的制定吧。因为有了之前的教训，所以我们在制定新需求的时候格外慎重，由项目总监、产品经理、项目经理、架构师、需求分析师、测试设计师等参与需求讨论会，对产品功能特性进行评审，在产品需求确定工作完成之前这样的会议每天早晨都会召开一次，当有来自客户的反馈信息时即时召开。每确认一个功能点都会在PRD（Project Request Document）文档中增加一条相关功能点的名称及说明，PRD文档的作用相当于功能特性词典，它只记录功能点的简单信息，需求确认无误后才会形成SRS（需求分析）文档，详细系统的阐述软件产品的所有功能特性。确认需求的过程非常折磨人，有时候甚至会为了一个很不起眼的功能点，大家坐下来研究半天，还不见得能确认最终的版本。我们的产品确认需求的过程大概有八个月的时间，需求的确定工作完成大概20％的时候，软件测试设计小组并行开始软件测试设计的工作。

先看看附件中的流程图，虽然不是特别详细，只能大概描述出我们的测试工作流程。设计阶段包括：测试设计1和编码设计两项内容，在这个阶段软件的相关特性（或者是部分模块的特性）需求的细节已经明确，测试相关人员可以在这个阶段开始测试用例的设计工作，开发相关人员可以开始编码的设计工作。开发人员完成编码后，由开发人员自行完成或由白盒测试人员来完成单元测试工作。黑盒测试人员负责接下来的模块测试、集成测试、系统测试和回归测试，当软件达到即定标准的情况下回归测试结束，标志整个项目组已经完成代码编写和测试的工作，产品已经研发完成进入项目总结阶段。从下面的流程图可以看出黑盒测试工程师在软件的测试阶段担负了重要的职责，对软件的质量有相当重要的影响。
软件测试设计的工作包括软件功能特性分析、测试框架选取、测试方法制定、测试工具使用和测试用例形成等工作内容，其中形成测试用例是测试设计工作的最后一个环节。软件测试设计的工作由软件测试设计师来完成，虽然当时我只是一名软件测试工程师还没有资格完成这么重要的工作任务，但是因为前一个工作阶段我重新编写的测试用例反响很好，大家对我的测试设计水平很认同，所以领导破格允许我加入了软件测试设计团队，而且负责软件系统核心功能模块的测试设计任务。

了解需求的过程非常考验一个人的耐性。因为我们采用了需求的确认与测试设计是“并行”进行的方式，也就是说在软件测试设计的情况下没有任何有效的文档来帮助测试设计师，只能通过参与需求讨论会、会议记录和口头咨询的方式进行需求调查，而需求讨论会上确认的特性所描述的细节不够全面，我们采用的主要沟通方式是通过口头咨询，这种沟通方式的鄙端有很多，因为不同的人会对同一个功能点有不同的理解，所以在调查特性的时候我们往往不知道谁的描述才具有权威可以用作测试设计，另一方面在产品需求更改频繁的情况下，人为造成的灰色沟通（忽略了向测试人员告知需求已经变更的事情），使我们的需求分析工作进行异常艰难，正因为如此，我们每个测试设计师练就了高超的理解力和很强的主动沟通意识。呵呵！有点像武林高手。

测试设计工作的另一方面压力来自于工作周期不够长。会议上刚刚确认的需求，在会后马上就要拿出测试设计方案，而且设计的周期要比正常的周期短很多，举例来说某个功能模块的设计周期应为七个工作日，但由于项目时间紧急，我们会将公休日全部算作工作日，即便是这样设计周期也会更改为四天或者更短的时间，我们真的就是没日没夜的在工作；另一种情况就是预计设计周期为十天，在工作进行到第八天的时候需求突然变更，所有的努力付之一炬，但是测试用例的评审工作（由项目总监、项目经理、需求分析师、测试设计师参与）仍会如期进行。在这种情况下，软件测试设计师要快速的做出反应，就算测试用例没有完成，也要及时的拿出调整方案。领导认为我工作出色很大一部分得益于我对突发情况反应的迅速。每次评审之前我都会做充分的准备，如果需求没有突然改变所有已经完成的用例都具有评审价值，我会在事前给大家准备一份大纲，介绍本次所要评审的用例内容，涉及哪些功能点、采用了什么样的测试方法、哪种工具比较合适，在评审员阅读测试用例之前就已经对我的测试用例内容有所了解，所以他们可以针对重点问题直接提出意见，我根据他们的意见展示测试用例细节，讲述我的解决方法，然后再考虑其他问题，这么做能够节省不少的评审时间。还有另一种情况，就是因为需求的突然变更，部分用例失去了评审价值，这种情况下我会准备两分文档，一份是上述的用例大纲但是会标识出哪些功能点的需求有所变动、新需求是什么，一份是针对变更的需求做出的解决方案。这样做有三方面的好处，第一是评审员可以直观的了解到需要本次评审的内容节省评审时间，第二他们可以针对我对新需求所做的测试设计方案进行评估减少我的出错机率，第三评审员会了解到我并没有以变更了需求为借口放弃了对工作的努力。

为期六个月的测试设计工作结束的时候，领导对我的工作十分认可并且做出了很高的评价。在接下来的测试执行工作阶段，我荣兴的成为新入职员工的导师，之后我们成立了新的测试小组，由我担任组长。现在回想当时的高压工作状况真是百感交集，有辛苦，有委屈，有抓狂，也有泪水，不过更多的是技术上的收获，这种受益让我迅速的成长，所以就技术而言有时候吃亏也是福。在此期间我通过了“软件测试评测师”的考试，获得了我的第一个资格证书。在测试设计的过程中，我自己总结了测试用例设计的八个步骤：1.明确功能模块的每个特性及细节；2.制定出功能特性列表，分出一级模块、二级模块……等等，逐一将功能特性细化；3.总结各功能点类型，如基本功能、异常情况下的功能点等；4.编写测试用例描述；5.调查功能模块间的关联性；6.编写关联性测试用例描述；7.统计每个测试用例所需要的测试环境、工具、脚本等；8.选择测试用例模版，细化测试用例模版中各个属性。

1推荐一个适合这个阶段的资料《Effective Software Testing》或者称为《高效的软件测试－－50个方法提高软件测试技能.pdf》

 

我的测试经历（五）

自从担任小组的组长以后，我更多的关心人员选择和测试管理的事情。我觉得选拔测试执行人员应该考虑面试者具有如下的素质：专业技术方面：计算机相关专业并且专业技术优秀（就是动手能力强），计算机专业技术好的非专业人士也可在考虑范围内，因为非专业人士不见得比本专业的技术水平差；学习方面：学习意识强、自学能力强；性格方面：做事认真、有责任心，性格开朗能够与其他人很好沟通（但爱唠叨，上班的时候喜欢唠闲嗑的除外），团队意识强能够与他人很好合作不特立独行；工作认知方面：重视工作喜欢工作，能够付出辛苦。

测试管理1工作多而杂远没有测试执行有意思，但这并不代表这项工作是轻松的，小组负责人的职责艰巨：团队内的技术顾问，为成员提供技术解决方案，承担技术字典的职责；组织协调成员高效、高质完成工作任务；提供策略性问题的解决方案，看清团队的发展方向，推动团队的进步；人员交叠培养，根据成员的综合素质制定技术发展方向。这就要求小组的负责人具有过硬的技术水平，较高的组织协调能力，而且对于团队的整体发展具有一定的前瞻性。
我在刚刚负担起这项工作的时候，对于组织大家如何按期完成测试工作十分头疼，我们组的人员技术水平参差不齐，特别是一部分有些资历的老员工对于我这个负责人不太服气挑拨事情，真是每天都把我支得团团转，焦头烂额的还解决不好问题，所以第一轮测试我们的测试进度和测试质量是前所未有的差。这件事情让我很上火，为此我在网上也找了好多的资料，希望能够参照别人的解决方法来解决我所遇到的问题，后来一篇叫《鱼》2的文章，给了我很大的启示。我改变了工作方式，将工作地点搬到测试区域与大家一起感受测试带来的乐趣，更多的关心大家的生活情况，比如聊聊谁家的小孩，在哪照结婚照便宜又漂亮等等。大家与我的关系逐渐好转隔阂在慢慢消失，工作热情大大提高，有时候他们会针对我分配的工作任务提出自己的意见，合理的建议我都会第一时间采纳。我又根据每个人的情况制定了个人的学习计划，包括学习内容、相关资料的提供、学习期限、完成标准等，然后在规定的学习时间结束后，我会组织大家对他所学的东西进行考核评分，这样每个人都有机会充当学员和评委，新知识在不知不觉间就被大家所接受了。工作积极性提高的同时，我们的工作质量也得到了提高，经过几轮系统测试的历练，我们这个新组织起来的测试团队已经日趋成熟，大家都在工作中获得了收益。
一年多的时间转眼过去了，一半的小组成员已经担任过或正在担任新员工的导师，对于大家的进步，我也不得不去考虑自己的未来发展方向。相信很多从事技术方面的人来说，都难免有“卖血”的经历，就是在一段时间里技术水平停止不前，全靠着以往的经验和技术在支撑，可以说这一年以来我就是这样度过的，工作协调能力有所提高，但技术水平没有突破。所以我来到现在的这家企业，在这儿我完成了系统测试自动化的愿望，亲自搭建测试框架、完成对象库的建立、脚本的录制等等工作，真正的将这一技术应用起来了。另外我给自己制定了未来的职级发展方向“软件测试架构师”，如今我正朝着这个方向努力，希望在不久的以后能够在《我的软件测试经历》中与继续与大家分享我如何成为一名合格的“软件测试架构师”的技术成长感受。感谢大家的关注，《我的软件测试经历》全文完。

 

1推荐一篇测试团队建设方面的文章《浅谈软件测试团队的建设》

2 推荐一篇团队管理方面的文章《鱼》