我的测试经历（三）

　　刚开始的一个月就是按照现成的测试用例去执行，但是慢慢的我发现，原有的测试用例不太适用于当前的测试任务，一是测试用例覆盖率1较低，如果完全按照测试用例来执行，会有很多遗漏的功能点走不到；二是执行流程不好，比如功能点1执行完毕以后，执行功能点2会节省测试时间，而且从功能特性的角度来讲流程更顺畅，但是原有的用例却没有按照这个顺序来编写；三是用例中关于操作步骤和期望结果的描述不明确，不易于理解或是容易产生误解。根据上述三个问题，我决定从一个较小的功能模块着手重新设计测试用例2。我先是整理出了该模块的功能特性，然后做了一个类似连线的表格，这样就明确了各功能点之间的关联，对于确定功能点测试顺序有很大帮助，接下来就是确认测试用例的分类了，我将测试用例大概分成如下四类：基本功能测试用例，异常情况测试用例，关联性测试用例和压力测试用例。基本功能测试用例，顾名思义，就是指测试某一具体模块的常用功能，用以验证功能的完整性、可用性、可执行性；异常情况测试用例，是指在网络、数据库连接异常等突发状态下软件的稳定性；关联性测试用例，是验证有功能关联关系的各个模块之间，执行测试后的运行结果；压力测试，用于验证大数据量的情况下软件的稳定性。

　　测试用例刚刚完成，我们就进行了交差测试，新接手的测试人员说新用例比以前的老用例易于理解操作起来很方便，而且功能点含盖得很全面，在周例会上他讲了自己的看法，并且把新的测试用例拿给大家评审，最后得到了大家的首肯“可以应用到系统测试执行当中”。这次的成功，为我以后的工作得到认可奠定了坚实的基础。接下来我对核心模块的测试用例进行了修改，仍沿续以往的风格，但采用了不同的思路，因为第一次的成功，测试负责人对修改测试用例的工作很重视，每完成一个模块都会召集大家进行评审，经过三次评审以后，大家对我的用例编写水平给予了充分的肯定，在测试管理工具上给我分配了修改测试用例的权限。我，在软件测试工作师的道路上又前进了一步。

　　说一下当时我们的工作情况，我们项目组做的产品处于研发阶段，一直没有面向市场营销，虽然部门内部制定了相关的时间表，但时间点执行并不是十分严格，工作用时相对比较宽欲。就测试这方面来讲，我们黑盒测试人员只负责系统测试，每一版本的测试分为接收测试（0.5-1工作日）、系统测试（12工作日）、发散测试（3工作日）三个阶段。接收测试阶段，验证产品功能的完整性，评估产品质量是否达到系统测试标准，如果已达标则进入系统测试阶段，否则返回给开发人员修改；系统测试阶段，全面的执行各个子模块的测试用例，检查各个功能点；发散测试阶段（我们也戏称为发疯测试），不考虑测试用例，进行测试用例外的各种尝试。我有很多灵感都是来自于发散测试阶段，因为没有了测试用例的约束，想象的空间得到充分发挥，很多意想不到的思路就产生了。持续一段时间只执行某项固定的工作，很容易使人产生倦怠的情绪让工作失去原有的生气，测试工作尤其如此，所以我觉得测试人员应该随时抱着一颗好奇心，发掘新奇的东西，这样才会找出更多的问题。

　　在工作的同时，我也跟开发人员学到了不少的东西，他们教我一些浏览代码的技巧，当然也要求测试人员有一定的编程功底。在我对代码就比较熟悉以后，偶尔会帮助开发人员定位BUG或是提供一些修改意见。记得有一次，我发现了一个能够导致整个软件系统死锁无法操作的BUG，开发人员用了两个多小时修改了很多次，问题还是没有解决，情绪有些急躁，后来我跟他一起看了那段代码，我发现是一个变量的返回值写错了，纠正了这个小小的错误，上述看似很严重的问题就解决了。

　　部门领导为了提高大家的测试技术，特别组织了一次为期一个月的培训，包括沟通技巧、黑盒测试技术3、性能测试、自动化测试工具四门课程。

　　其中沟通技巧这门课是同时面向测试人员与开发人员的，讲述了互相矛盾、互相对立的两个不同职位的人员应该采用什么样的沟通手段，很高兴的是讲师非常同意我“测试人员与开发人员是朋友”的观点，向他人微笑得到的回报同样也是微笑，与“予人玫瑰手有余香”是同样的道理，因为不论是开发还是测试，都是团队的成员，那么只有朋友才会一心一意为着共同的利益和目标努力。这次培训也让我第一次明白团队的确切含义，一个团队小到可以说具有相同工作性质的团体，比如一个项目组中的测试组可以叫一个团队；有共同前进目标的团体，比如一个部门也可以称为团队；再或者有共同经济利益的团体，比如一个公司。不同规模的团体有着不同的利益，小利益服从大利益才会获得更多的经济效益，所以那些一味把小团队的地位放在首位，不去考虑大团队的利益的人，最终会被团队所淘汰。

　　另外两门课程都是面向测试的专业技术培训，不是很系统，但知识面却很广。我比较感兴趣的是黑盒测试技术和自动化测试工具这两门课。关于黑盒测试技术，因为讲师并不善长此项，所以培训的内容基本都是照本宣科，理论与实践完全脱轨，并且远不及网络上的资料来得全面，对于工作没有什么实质性的帮助。自动化测试技术的课讲得很生动，主要介绍QTP（QuickTest Professional）4和LR（LoadRunner）的使用，只可惜，因为我们的产品性质和质量的原因，一直没有机会在实践中系统的应用。

　　我的测试经历（四）

　　在入职八个月以后，我们结束了惬意的内部研发阶段，产品正式步入市场营销，由于我们以往缺忽略了市场调研的环节，导致产品与市场的需求严重脱轨。为了适合市场的需要，我们否定了以往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》