6.6 故事分享:Rational中国敏捷测试工程师的一天

·主人公登场

我叫英才,IBM开发中心一名极其普通的测试工程师,2年前进入IBM,现在已经是资深的小band6(一般硕士毕业生进入IBM的级别)。我去年进入Rational团队,曾经做过FVT、GVT、自动化测试开发,如今正在做敏捷测试。

8:10,和女朋友道别后,我步行到离家仅仅100米的333路车站,像往常一样,一边发着微信向群里的朋友问候,一边查看着最新的微博,只要10分钟左右,这班车一定到站。我有些机械地顺着人群,依着不是很规矩的人流上了车,站在距离中门很近的位置,我喜欢这里,因为这里总是人少些。我将音乐开大些,慢慢享受这一路摇摇晃晃的旅程,我在心理准备着,因为这一天紧张的工作即将开始。

·开始一天的工作

8:55,我来到公司座位,顺手点开显示器,简单地扫了一眼满屏正在自动化运行的自动化测试任务,确认测试昨夜正常运转后,打开写测试报告的php页面,再次确认大部分的结果均已上传成功后,我锁定了屏幕,坐下来,打开了我的笔记本,等待它的启动。

9:00,用最大的水杯打上一大杯水,用小咖啡杯打上一杯公司的免费咖啡,坐在桌前,第一件事就是查看邮件,第一封邮件是RTC……第二封……第三封……

我喜欢做好每天的计划,这是Alex多次给我们介绍的时间管理方法之一,于是我在座位的白板上写下了几个简单的词汇,算是用来提醒吧。

·温顾而知新

9:10,我决定对近来Alex给我们讲的敏捷测试知识做个温习,因为我此时的头脑最好。因为初步进入敏捷项目,我还在寻找跟随步调和锻炼职业操守,我非常高兴Alex为我们团队准备了敏捷“测试手册”,这非常实用,让我看清敏捷测试的工作内容、时间切入点,Alex告诫我切勿等待,更加主动地、聪明地工作,多和其他职能的同事(比如开发人员、需求设计者)沟通。

·参加Scrum例会

9:30,Scrum团队的会议召开了,来自美国的Matt主要沟通了新近一轮讨论中需求和设计的最终方案的改版,Alvin这个天才的开发团队队长则告知他已经更新了这个迭代的代码原型,这简直太神速了,我在考虑这家伙一定在晚上开夜车了,不过我很难理解他为什么每天都这么精力充沛。轮到我了,我首先向大家介绍今天已经是第二个星期的第三个工作日了,我的测试用例和测试计划即将完成,我友善地提醒了团队负责人以及我的开发者同事们,下周也就是3天后就需要进行代码测试。我很窃喜,因为这次没有听到任何人的抱怨,他们似乎已经习惯了我这个小碎催。第二件事,我向团队汇报的是我的自动化测试版本经过了一夜的正常运转,现在大量的测试报告已经上传到了网上,开发团队昨天发布的最新版本已经经过了足够的验收测试和回归测试,这个版本可以作为新的里程碑继续进行增量型开发。当然,这是个很好的消息,我看到Alvin的一丝得意表情,自然是Alvin在团队的代码审查工作上取得了质的飞跃,不然不能有这么好的测试结果。这对于我来说更是个好消息,我可以用更多的精力集中思考新功能的测试方法和新性能指标的度量。

小提示:在Scrum会议中,测试人员需要规划测试活动和更新进度状态。如图6-8所示,测试活动,如测试策略、测试计划、测试环境的搭建、自动化开发等都可以在全团队的产品清单中登入,可以由自己更新进度,在Scrum会上尤其需要关注并主动提出测试进度如何能够顺利开展、所要完成当前工作的前提条件和所需帮助等。测试人员同时还要承诺,何时可以完成环境搭建、配置管理工作,或将要花费多少个小时完成新迭代的功能和非功能部分测试,或需要多频繁地做回归测试以确保已开发功能和稳定产品的增量开发。

00010.jpeg

图6-8 测试工作计入了产品清单

·透过仪表盘看团队

9:25,我从会议室回到了座位上。我很想知道为什么在今天的会议中团队负责人极少干涉,我很快打开了RTC客户端,访问了我们团队的Dashboard,就目前看来进度很好,不得不说这个Team的队长经验很丰富,知道在该说话的时候表达犀利,而不说话的时候也能感到他有只无形的手在掌控着一切,不对,这只手是在身后托着我们,让我们更快地向山顶攀登而去。

·团队讨论设计

10:00,我和Mat、Alvin像往常一样拨入会议,虽然我和Alvin在一个办公室,但是Alex建议我们各自通过电话拨入网络电话会议,通过视频和电话来沟通,因为只有这样,我们才不会在开会时耳语,不会让电话线那边的同事觉得无理。团队的网络会议录制开始后,我们接着上次的设计进行讨论。

我:“Mat,你说你需要在用户点击窗口的时候弹出一个浮动窗口,是吗?”

Mat:“是的,英才。”

我:“请问如何关闭这个浮动窗口?这个浮动的窗口相对于屏幕多大?或者有准确尺寸吗?这个窗口应该是固定的还是可以拖拽的?再有就是,如果出现内容较多,是否需要一个滚动条,这个你有考虑和设计吗?”

……

·做哪些测试

每每和需求、设计人员沟通的时候,永远都要考虑如何将业务需求尽可能准确地变成可以编程、可以测试的技术性需求,我们的经验是将提问的角度延伸至验证逻辑、多线程时用户可以接受的延迟时长或者安全隐患等。这可能会带来一系列的分析和再次融合统一,但这个讨论非常有意义。因为这个过程不但使团队对迭代将要开发的目标、验收指标达成一致认识,还可以大量减少由于需求不明确、需求模棱两可而产生假设理解,进而导致产品在迭代验收中失败的问题。这个过程我们称为静态测试,通常发生在迭代前半部,随之而来的是需求和业务流程的明晰和确定,测试策略、计划和测试用例的完成。最佳的实践是测试人员与团队代表们一起做1~2次的测试用例审阅,以达到大家对目标和细节的一致性,推动团队工作的有效进展。

经验表明,静态测试将减少产品在发布时期20%左右的质量缺陷,导致这些质量缺陷主要是因为需求不全、需求不清。静态测试的开展没有统一的执行步骤,测试人员需要带着原则和足够的想象力来测试这个还未构成的产品,逻辑型判断、缜密地捕获需求和设计中遗失的细节,这些都是静态测试中的重要品质。

静态测试需要测试切入点。如何全面测试?如何查漏补缺?第一步,我们从产品发展的趋势、从宏观的视角理解产品的定位、产品族的竞争力,了解产品当前版本的重要价值以及同类产品的差异。第二步,了解当前迭代所关注的最重要的功能指标、非功能指标(如性能指标)。第三步,进一步细化基于用户体验和行业惯例的用户操作流程,推测最有可能被用户挑战的组件或者操作流程,找出用户最有可能需要而还没有开发充分的操作流程,反复思考、假设如果用户操作出错,能否简单地返回出错前状态,还需要考虑多用户并发操作对数据造成修改冲突的可能性、竞争资源的可能性等。敏捷测试的系统层次结构如图6-9所示。总而言之,对产品长期战略和业务的熟悉可以帮助测试人员更好地理解团队的用例设计、视图、模块等,也能够通过对比分析,直接找出某些设计中的缺陷,提高设计的质量。项目的开发前期阶段,设计占有非常重要的比例,而设计是直接影响产品质量的环节,因而确保这一阶段的质量对提高产品的品质起决定性作用。针对开发出来的用例,设计者对用例的描述通常比较简单,缺乏完备性和缜密性。而开发和测试需要的是详细的设计,需要将用例定义得清晰、明确,例如边界条件、例外条件、数据的格式和其他性能指标的界定等。因此,测试人员应该帮助团队明确分析更多的细节。有原则,即宏观战略指导微观行为;有立场,即用户习惯与满意优于技术实现代价,并以此甄别需求和设计中的缺陷。

00028.jpeg

图6-9 敏捷测试的系统视角

这部分工作是测试团队与开发团队和设计团队合作最默契的阶段,交流非常频繁,正是通过积极的沟通和及时的修正,团队方向更加明确,更有凝聚力,更利于发挥团队的最佳战斗力。通常,这个阶段需要约1/4迭代周期的时间,这同时也说明了静态测试在敏捷测试类型中的重要性。

11:30,会议结束,我放下耳麦,很快地将几个重点细节记录在RTC的工作项里面,将本次会议录音的链接也发到了RTC管理的相关工作项下面。锁定电脑,和测试团队的同事去楼下食堂吃午餐。

·午休

13:00,回到工位,沏上一杯红茶,细细品品……开始更新测试用例和测试计划。

·编写测试用例

测试用例的撰写和传统测试基本没有差异,按照已有的模式撰写就好了。有些测试团队使用XML文件格式保存所有测试用例,主要原因是便于复用和版本控制,同时也因为XML元素可以很灵活地被查找和更新,而且在自动化测试中还可以通过程序抽取测试用例的模块信息形成自动化的测试报告、需求测试跟踪报告等。后来,这种方式被更加智能和强大的Rational Quality Manager(RQM)取代,RQM可以更好地和需求工具、工程配置管理工具集成,自动化生成报告、进度跟踪。

·使用QM管理测试

在QM的角色设定中,有测试管理者、测试领导者和测试人员三种,每种角色具有不同的工作职责和权限,对此,在敏捷团队的每次迭代中,测试人员实际上完成了三个乃至更多角色的工作,这个过程正是自我管理的体现,也是自我成长的需求。通常在RQM工具配置时,要赋予敏捷测试人员更全面的角色和更高的权限。RQM适用于敏捷、迭代、瀑布式开发模式的测试用例管理和进度跟踪,工具是方便我们工作的利器,决不可成为过程和方法的代言。图6-10为使用RQM管理敏捷测试各项工作的示意图。

00048.jpeg

图6-10 使用RQM管理敏捷测试各项工作

·自动化完成执行

16:00,自动化测试已经马不停蹄地工作了近20小时,开发团队的新代码即将检入(Check in)到代码流,新一轮的版本验证自动化测试即将开始,至此,所发现的昨日代码所带来的重要问题、关键路径问题已经在回归测试和版本验证测试的自动化测试系统上跑了一遍以上(为了避免因为电子系统受周遭化学、物理条件变化而产生的不稳定测试结果,我们设计了自我检测式脚本错误,以及在新环境跑相同任务脚本时的自动化纠错逻辑)。此时,我很快地检查了这个老版本所遇到的各类问题,通过自动化测试报告的日志链接点击进入查看错误的缘由。

如图6-11的测试报告中,第一列为测试日志的URL;第二列为关键平台和环境定义;第三列为测试版本的甄别编号;第四~六列标记测试任务的完成程度与结果(第六列以颜色标记执行状态);第七列为测试机对应的主机名,用于区分是哪个具体机器或者虚拟机运行了当前任务;第八、九列为测试脚本、测试任务的分类,例如数据源Teradata相关、或者informix10相关等;第十列为自动化测试脚本的状态标记,即正在运行、准备运行和完成运行等。

00067.jpeg

图6-11 可以实时监控的测试执行状态报告

小建议:自动化测试的成功率、测试脚本不依赖环境和机器的鲁棒性,这其实是有效自动化测试错误分析的基础,可以想像,如果自动化脚本换一个机器跑就会出错,测试人员的精力将大量投入到维护环境的工作中,这是非常没有价值的事情。所以,最佳的做法是:很好地设计自动化测试脚本,做好对物理环境或者操作系统环境的兼容;自动化测试执行引擎需要有好的逻辑判断,当脚本在当前版本上失败,而在之前版本成功时,测试引擎应该自动激发测试重新开始,以避免因为测试环境的偶发因素导致的错误测试;每一个平台的测试都需要准备多台测试机,以确保实在没有时间处理测试机的环境问题或者测试机本身出现明确故障时不至于耽误自动化测试进度。

·一天工作的回顾

17:45,也是即将下班的时间。因为今天是迭代的中期验收测试用例的日子,我非常清楚这个时机应该做两件事情:第一是确认开发团队从现在起就要发布代码,尽管或许不完整,及时发布代码是迭代质量工作得以完成的保障之一,也意味着我的正式测试执行期到来了;第二是测试用例需要团队的审阅和最终定稿,所以我利用最后的15分钟发送了会议邀请,邀请开发人员Dave和用户设计团队的Mat于明天10:00开会20分钟审阅测试用例,然后我做了RTC工作项的工作进度更新,就这样为我一天的工作画上句号。

小建议:敏捷测试、敏捷开发要有很好的时间观念,到了该发布的时间或者完成工作的时间就一定要尽最大努力完成,以确保团队的整体进度和他人的工作进度不受影响。我会建议工程师们都准备一个台历,在每个关键的日子的方块里标出要完成的工作;标出迭代起止日期,在大概1/2的时间点完成测试计划、用例、测试环境搭建,3/4的时间点完成60%的功能测试和关键的用户验收测试等。图6-12给出了工作台历的示意图。

00086.jpeg

图6-12 人手一份的计划和提醒利器——台历