敏捷中的QA

说到QA,通常指的是质量保证(Quality Assurance)工程师,但我更喜欢定义敏捷中的QA为质量分析师(Quality Analyst),主要基于以下几个方面的原因:

  • 质量保证更偏向于工业说法,称参与软件测试的人员为质量分析师感觉更恰当;
  • 质量保证师更多的还是把测试当作软件质量的最后把关着、看门人,而敏捷中的QA更多的是建议提供者而非看门人,把QA称为质量分析师更能体现敏捷中团队对质量负责的原则;
  • 质量分析师更重视业务价值,关注业务价值的分析。

QA,质量分析师,显然与测试有关。敏捷中的QA,也就是与敏捷测试有关。敏捷测试就是在敏捷开发模式下对软件进行的测试,要求尽早测试、频繁测试,以及时提供反馈。敏捷测试要求团队对软件产品的质量负责,而不是某个带有QA头衔的特殊人员。敏捷中的QA可以是参与敏捷测试的所有团队人员,而并不一定是特定的专职的测试人员。

这听起来是不是有点特别?跟传统开发模式下的测试人员是不是有些不一样?别急,我们先来看看敏捷中的QA是如何进行日常工作的。

敏捷QA的日常活动

从迭代到发布,敏捷测试的生命周期各个阶段QA的活动主要有:测试分析,测试自动化策略分析、框架构建等,故事测试,迭代计划会议和客户演示,测试自动化的维护和执行等。如下图示:

1

QA通常不是仅仅工作在某个迭代,而是并行的同时工作在多个迭代:要对当前迭代的故事进行验收测试、探索性测试,和开发人员结对实现测试自动化;还要和业务人员结对分析下一个迭代的故事,编写验收标准和测试用例。

在单个迭代内部,伴随着故事生命周期,QA的活动有哪些呢?用户故事生命周期包括以下几个阶段:故事分析、故事计划、故事开发、故事验收、故事测试/探索性测试、系统测试和客户演示。QA参与故事的整个生命周期,在每个阶段都会发挥作用。

3

  • 故事分析阶段:需求澄清,业务场景和验收测试的确认
  • 故事计划阶段:拆分测试任务,在每个故事开发估算基础上考虑测试的时间和估算
  • 故事开发阶段:和开发人员结对实现自动化测试,和团队沟通发现的问题和缺陷
  • 故事验收阶段:开发人员开发完故事后,QA和业务分析人员要在开发机器上进行验收,以提供快速的反馈;同时还要对测试覆盖率(单元测试、组件集成测试、功能测试)进行确认和提出反馈
  • 故事测试/探索性测试阶段:执行自动化验收测试,执行探索性测试,强调会阻碍故事发布的因素,和团队就测试覆盖率进行沟通,为发现的缺陷添加自动化测试
  • 系统测试和客户演示阶段:执行端到端的系统测试,执行业务或集成的用户测试场景,和团队及客户就功能特性的质量和稳定性进行沟通,参与给客户演示功能和特性

正如前面提到的,在每个阶段,QA除了要独立进行测试,通常还需要跟不同的角色结对,包括业务分析人员、开发人员、以及客户。

4

  • QA与业务分析人员结对:通常在业务分析师分析用户故事的时候,QA要与业务分析人员结对编写验收标准。通过与业务分析人员结对,QA能够更好的理解领域知识,从而有利于定义合适的测试用例;QA从测试角度添加的验收测试用例可以帮助整个团队对产品功能性有更好的理解。
  • QA与开发人员结对:QA和开发人员分别能给团队带来不同的技能集,认识到这一点很重要。作为一个团队,最好通过平衡不同的技能集来获得共同的目标。这对于传统的瀑布式团队来说是一个很重要的心态改变。通常在实现测试自动化的时候,QA与开发人员结对是比较理想的方式。这样结对实现的自动化测试质量相对较高,有测试意识较强的QA参与能够保证自动化测试测得是真正需要测试的部分,而开发人员的编码能力有利于写出简洁可维护的自动化测试代码。另一方面,QA通过与开发人员结对,编码能力也会相应有所提高,而开发人员通过与QA结对,测试意识也会增强,更有利于编写质量较高的产品代码,更有利于形成全功能团队。
  • QA与客户结对:客户是业务领域专家,通过与客户结对,QA能够更好的从终端用户的角度理解系统,从而定义或者增加更多的端到端的测试用例;一旦QA理解了领域知识和终端用户的观点,其业务价值分析能力会有所提高,在团队需要的时候可以承担业务分析角色;在用户验收测试(UAT)阶段,QA通过与客户结对,帮助客户熟悉使用系统,在必要时可以帮助客户解决一些系统问题。

敏捷QA的这些日常活动,的确反映出敏捷QA的日常工作内容和方式都跟传统开发模式下的测试人员有很多不同。下面为大家来详细介绍一下两者的不同,以及敏捷测试对QA的要求有哪些。

敏捷QA与传统测试人员有何不同

我们分别从团队构成、测试阶段、工作方式、关注点、业务知识来源以及发布计划制定几个方面,来看看敏捷QA与传统测试人员有哪些不同:

传统测试人员 敏捷QA
单独的测试团队 多角色开发团队的一员
在开发流程后期才开始测试 测试贯穿于整个开发流中
通常是独立工作 QA和不同角色进行结对
被当作最后也是唯一的质量保证 关注并强调风险
缺乏与业务人员的直接沟通 和业务人员直接沟通
没有机会参与发布计划制定 参与发布计划的制定

从上表的对比可以看到,敏捷QA是特殊的,主要体现在:

  • 敏捷QA是提出建议者而非看门人,需要在参与的每个阶段提出自己的建议,而不是等到开发流程最后来对系统进行验证;不仅要验证开发设计是否满足需求,还要发现需求是否能真正体现业务价值,分析是否有不恰当或缺失的需求。比如说,敏捷QA在跟业务人员结对编写验收标准的时候发现故事分析过程中漏掉的需求,在跟开发人员结对过程中跟开发人员讨论某个测试放在哪层实现比较合理等。
  • 发现风险,并将风险与团队及客户沟通。QA参与整个开发流程,对系统整体的认识和把握可以说是团队里边最全面的,因此也更容易看到系统存在的风险。
  • 及时向团队提供关于产品质量的反馈,便于调整。在每个迭代结束时候,QA需要分析统计该迭代的缺陷,并结合自己通过测试对系统质量的了解,及时跟团队反馈,讨论分析质量下降的原因以尽快作出改进,或总结质量上升的经验,鼓励团队再接再厉。
  • 在制定产品和版本的发布计划的时候,QA可以根据自己对产品质量的了解,从测试人员独有的视角提出一些关键的建议。
  • QA通过参与开发流程的每个阶段,能够协助团队从内部提升质量,让质量融入到产品开发中来。比如:在故事验收阶段对测试覆盖率的确认。

这些特殊性对敏捷QA也提出了更高的要求,需要做到:

  • 具有丰富的产品知识和对用户业务目标的准确了解
  • 对不同系统和数据库所用到的技术知识的了解
  • 和不同角色以及客户进行有效沟通
  • 主动验证质量目标并及时说出自己的想法
  • 编写测试计划,列出需要执行的活动并进行估算
  • 自动化测试的能力和对测试工具的基本了解
  • 在团队内部进行知识分享,协助整个团队参与到测试活动中来
  • 持续提供并获取反馈

本文转载自:http://www.infoq.com/cn/articles/agility-of-qa

Share

软件缺陷的有效管理

“这次发布之前怎么这么多的缺陷,是不是需要分析一下啊?” 答案是肯定的,可是这个时候才想起要分析已经有点晚了,有可能这些缺陷很难分析了。这是发生过的一个真实场景,所记录的缺陷包含信息很有限,很难有效的做好分析!本文就来聊聊如何有效的管理和分析缺陷。

缺陷记录

曾经有个项目是在QC(Quality Center)里记录缺陷,需要填写很多必填属性字段,加上QC服务器在国外,访问速度非常的慢,每次记录缺陷成为了大家极其痛苦的一件事情。于是,很多时候,发现了缺陷也不愿意往QC里填,而是直接写个纸条简单记录下,验证完了它的生命周期就结束了,这样后面就没办法去很好的跟踪和分析了。(题外话:当时采用脚本稍微减轻了点痛苦。)

也有的项目对缺陷的格式和属性没有严格要求,记录的时候很简单也很自由,这样记录的缺陷由于很多必要信息的缺失,对后续的跟踪和分析也是极为不利。

还有一种情况就是记录缺陷时同样有一些属性要求填写,但是这些属性值可能不是那么有意义,导致存储的信息不仅没用,反而添加混乱,也是不利于跟踪和分析的。比如,其中的“根源(root cause)”属性的值如下图1所示,这些值根本就不是根源,这是一个没有意义的捣乱属性。

Screen+Shot+2015-06-18+at+9.26.37+AM

图1 某缺陷根源属性值

缺陷记录应该做到尽量简单,且包含必要的信息。

1. 标题:言简意赅,总结性的语句描述是什么缺陷

2. 详情:包括重现步骤、实际行为、期望结果等,根据具体情况确定其详细程度,必要时可以添加截图、日志信息等附加说明。

3. 重要属性:优先级、严重性、所属功能模块、平台(OS、浏览器、移动设备的不同型号等)、环境、根源等,这些属性对应的值需要根据不同项目的情况自己定义,其中“根源”是相当关键的一个属性,后面有示例可以参考该属性对应的值有哪些。

4. 其他:每个项目对应的还会有其他信息需要记录的,自行定义就好。

在敏捷开发环境中,测试人员可能随时在测试、随时都会发现缺陷,包括还在开发手里没有完成的功能。什么时候发现的缺陷需要记录呢?通常情况下,开发还没完成的用户故事(story),测试人员发现缺陷只需要告诉开发修了,在该故事验收的时候一起检查就好了,无需单独记录;在开发已经完成,交到测试人员手里正式测试的故事,再发现缺陷就需要记录来跟踪了;后续的所有阶段发现的缺陷都需要记录。

缺陷分析

比较推荐的一种缺陷分析方法是鱼骨图分析法,可以将跟缺陷相关的各个因素填写到鱼骨图里,对缺陷进行分析,如下图2示:

Screen+Shot+2015-06-19+at+2.51.24+PM

图2. 鱼骨图缺陷分析法

缺陷相关的各属性拿到了,就可以用表格、曲线图、饼图等统计各个属性对应的缺陷数量,分析缺陷的趋势和原因。下面是我在项目上做过的分析报告图:

Defect+trend

图3. 功能与环境对应缺陷数量统计表和缺陷根源比例图

Screen+Shot+2012-05-31+at+1.13.05+PM

图4. 缺陷根源统计表和比例图

Screen+Shot+2012-05-31+at+12.58.17+PM

图5. 缺陷迭代趋势分析图

分析完得到统计的结果就要采取对应的措施,从而防范更多的缺陷产生。比如:修缺陷(上面示例中的“bug fixing”)引入的新缺陷比较多,可以在修复缺陷后添加对应的自动化测试;浏览器兼容性问题相关的缺陷较多的话,可以在开发完成验收的时候在多种浏览器上验收,等等。

什么时候该进行缺陷的分析呢?通常,推荐每个迭代周期分析一次,并且跟以往各个迭代进行对比,进行趋势对比。当然,有时候可能一个迭代发现的缺陷非常少,分析的周期可以根据具体情况做出调整。

总结

缺陷记录是为更好的跟踪和分析缺陷做准备的,而缺陷分析是软件质量保证的重要环节,对于软件过程的改进,软件产品的发布来说具有十分重要的参考价值,建议各项目定期都要做做缺陷分析。

Share

今天你写了自动化测试吗

一艘货轮满载着货物从港口启航,向浩瀚的大海深处破水而去。海面平静,微微皱起波浪,从容而显得宽容。然而,货轮的步履却有些蹒跚,发动机“轰轰轰”地嘶吼着,不堪重负,却无法让船只游得更快,倒像是海水咬住了船底往下在拖曳。

“嘟——嘟——嘟”,突然警报声响起,甲板上变得喧闹起来,一个水手模样的年轻人声嘶力竭地呐喊:“船超重了,快快快……快卸货!”声音急迫,甚至能听到哭音。然后,又是一阵喧嚷,似乎是在争吵甚么,就看到一个胖胖的中年人冲了出来。看他那肥胖的体型,真难想到他的身手竟然如此敏捷,如海豹一般破开人群,两手挥舞,大声喊道:“怎么了?怎么了?”,他停下来,吼道:“我看哪个不长眼的家伙敢卸我的货!谁敢!”

船长走了过来,略带恭敬地对那中年人说道:“老板,你看,这船超载了,船身吃紧,已经发出超重警报了。倘若不减轻船的重量,这船开不了多久就得沉了啊!”

“他奶奶的,这船可真秀气啊!”中年人一边骂骂咧咧,却也知道形势紧迫,容不得自己不下决断。可是心里总存着侥幸心理,突然灵机一动,一把拉过船长,指着这艘货轮问道:“既然这船超重,那我问你,除了货物,这船上还有哪些东西占了船身的重量?”

船长一听,立刻明白老板心里的小九九,没好气地回道:“除了货物,占了这船重量的就还有人、淡水、食品,还有救生圈、救生衣、救生艇。老板你看那样不顺心,你就扔哪样吧!”

嘿,回到现实中来吧。回答问题:倘若你是老板,你会扔哪样呢?稍有理智的人,都不难做出正确的选择。——然而,为何在软件开发过程中,我却常常看到有人选择丢弃救生圈、救生衣、救生艇呢?哪怕它们的重量对于整艘船而言如同九牛一毛,却总有人存着侥幸,认为船就超了那么一点点,或许扔出几个救生圈,就能恢复重量到安全线;于是,货物得以幸存,可以避免不必要的损失了。

或许,我们没这么傻吧。那么,让我们想想。

假设将这航行比作是软件开发的过程,那么载货到达目的地,就是实现软件需求。只有交付了货物,才算是实现了价值。至于淡水、食品以及船只,就是开发的工具与环境,而救生圈、救生衣、救生艇,就是我们在开发过程中需要编写的自动化测试(单元测试、集成测试、验收测试等)。我们需要这些测试来随时检测开发功能是否有误,及时反馈,就像在航行过程中,若是有人溺水,可以用救生衣、救生圈挽回一条生命一般。

可一旦开发时间紧促,人手严重不足,进度压力山大时,我们想到了什么呢?对于我见过的多数软件团队而言,每当面临如此窘境时,首先想到的就是减少甚至不做自动化测试。有人认为自动化测试没有价值,浪费成本;有人认为自动化测试可以以后再补,先把功能完成再说;有人认为有了手动测试,就足以保障项目的质量……如此这般,自动化测试就这般被忽略了,沦落到随时可以抛弃的地位。

倘若软件开发就只有这一个阶段,没有需求变更,没有后续开发,没有软件维护。项目的代码库如树苗一般在阳光雨露下茁壮成长,没有大风狂吹,没有烈日暴晒,没有大雨倾盆,亦没有虫蚁啃啮,那自然由得它去。然而,现实世界哪有如此美好!

Michael Feather将没有自动化测试的代码称为“遗留代码”,温伯格在《咨询的奥秘》中则认为应该将“维护”工作视为“设计”工作。自动化测试是修改的基础,重构的保障,设计的规约,演化的文档。它的重要性怎么强调都不过分,然而很可惜,在很多软件项目开发中,它甚至不如“鸡肋”的地位,说放弃就放弃了,在决定当时,毫不觉得可惜。至于以后的以后,不远的未来,谁还顾得上!!?债欠下了,什么时候偿还呢?——不知道!到了催债的那天,再想办法还债吧。

鸵鸟心态害死人啊!

扪心自问,我们经历过维护的苦楚吗?体验过修改代码的烦恼吗?修复过不胜其扰的缺陷吗?答案若是肯定,那么,如果老天再给你一次机会,把选择自动化测试的权利放在你面前,作为“曾经沧海难为水”的你,你会怎么选?——所以,我想问问程序员们:今天,你写自动化测试了吗?

Share

为什么你的Angular代码很难测试

Angular推出有好几年的时候了, 跟其他的MV*框架相比, 它的双向绑定, 无须显式声明Model, 模块管理, 依赖注入等特点都给Web应用开发带来了极大的便利, 另外, 借助于它众多强大的原生directive, 我们几乎可以避免麻烦的DOM操作了, 除了这些, Angular还有一个很大的亮点, 那就是高度的可测试性.

今天的Web开发已经不同往日, 更多的交互与逻辑都需要在前端完成, 有时候, 前端的代码量甚至在后端之上. 怎么去保证如此多的前端逻辑不被破坏, 依赖于功能测试? 这显示不现实, 功能测试很耗时, 而且它的创建成本较高, 所以通常只用它来覆盖最基本的那部分逻辑, 另一方面, 功能测试是依赖于流程的, 如果你想验证购买页面上的某个前端逻辑, 那么你就不得不一路从产品详情页面老老实实点过来, 反馈时间太长了, 可能你要等一分多钟才知道某个功能出错了, 我们自然不想把宝贵的开发时间浪费在等待上.

我在过去一段比较长的时候里都在项目上使用Angular, 在感受到Angular带来的便利的同时, 也饱受了Angular测试的折磨, 因为我一直觉得Angular的单元测试很难写, 跟JUnit + Mockito比起来, Angular代码的单元测试真是感觉写起来不得心应手, 更别说用TDD的方式来驱动开发.

我一直在思考为什么Angular社区说Angular的测试性很高, 但是在项目上实现用起来却是另一番境地. 经过分析项目上的代码, 我觉得要想驱动测试开发Angular代码, 那么其实是对你的Angular代码提出了比较高的要求, 你要遵循Angular的风格来开发你的应用, 只有你了解了其中的思想, 你的测试写起来才会轻松.

如果你已经使用Angular有一段时间了, 但是还没有读过这篇文章, 那么我强烈推荐你去读一下: Thinking in Angular

先来看一看怎么样的Angular代码才是苗正根红的Angular代码.

避免使用任何的DOM操作

像DOM操作这样的脏活累活都应该交给Angular的原生directive去做, 我们的Angular代码应该只处理与DOM无关的业务逻辑. 来看一个简单的例子, 我们想创建一个简单的邮箱地址验证的directive, 它要实现的功能是, 当焦点从邮箱地址输入框移出的时候, 对输入框中的邮箱地址进行验证, 如果验证失败, 则向输入框添加一个样式表示输入的地址不合法, 比较糟糕的实现可能是这样的

<label for=”email”>Your email:</label>
<input id=”email” type=”text” ng-model=”email” validate-on-blur/>

angular.module(“TheNG”, [])
  .directive(“validateOnBlur”, function() {
    return {
      link: function(scope, element, attrs) {
        var validate = function(email) {
          return email.indexOf(‘@gmail.com’) !== -1;
        };
        element.on(‘blur’, function() {
          if (!validate(scope.email)) {
            element.addClass(‘error - box’);
          }
        });
      }
   };
});

上面的代码应该可以满足我们的要求(验证逻辑因为不是我们关注的重点, 所以并不完善), 而且这个directive实现起来也挺简单的, 但是现在让我们一起来分析一下为什么我们认为这种写法是比较糟糕的.

最简单的办法就是在你的directive里面去找所有与DOM操作相关的代码.

首先看到的就是on()这个事件监听器. 完全没有必要自己去监听发生在被directive修饰的元素上的事件, angular有一整套的原生directive来干这个事情, 这里正确的做法应该是使用ng-blur来处理blur事件.

下一个有问题的地方就是addClass(), angular除了提供了事件监听相关的directive外, 也提供了操作元素本身属性的directive, ng-class就可以用来替换addClass()方法.

按照这个思路修改后的代码:

<label for=”email”>Your email:</label>
<input id=”email” type=”text” ng-model=”email” ng-blur=”validate()” ng-class=”{‘error-box’: !isValid}” validate-on-blur/>

angular.module(“TheNG”, [])
  .directive(“validateOnBlur”, function () {
    return {
      link: function (scope, element, attrs) {
        scope.isValid = true;
        scope.validate = function () {
        scope.isValid = scope.email.indexOf(‘@gmail.com’) !== -1;
      };
    }
   };
  }
);

比较一下这两个版本的实现, 是不是修改后的版本更简短, 更容易理解一些. 在新的版本里面, 我们只处理了业务逻辑, 即判断一个邮箱地址是否合法, 至于何时触发验证, 验证失败或成功之后应该有怎样的样式, 我们都统统交给了angular原生directive去处理了.

从测试的角度来看, 如果想给第一个版本的实现写单元测试, 那么要准备和验证的东西都很多, 我们需要设法去触发对应元素的blur事件, 然后再验证这个元素上是否添加了error-box这个class, 根据我的经验, 有时候为了验证这些DOM更新, 你还不得不创建真实的DOM结构添加到DOM tree上去, 又增加了一部分工作量.

而版本二就简单多了, 只定义了一个Model值isValid来标识当前的邮箱地址是否合法, validate()方法会在每次失焦之后自动执行, 要为它添加单元测试, 则只需要调用一下它的validate()方法, 然后验证isValid的值就可以了. SO EASY!~

将所有第三方服务封装成Service

一个Web项目中总是无法避免地要使用一些第三方的服务, 这里讨论的主要是前端的一些第三方服务, 比如在线客服, 站点统计等, 这些代码都在我们的控制之外, 大多数时候下都是从服务提供商的服务器上下载下来的, 而我们需要在业务代码中调用这些代码.如果我们每次都是赤裸裸地以全局变量的形式来使用这些服务, 那么造成的问题就是这样的代码很难测试, 因为这些代码是不存在于我们的代码库中的, 而且内容应该也是不定时更新的, 大多数情况很多人会因为这些原因放弃到对这类操作的测试.假设我们现在需要在某些动作发生之后调用一个第三方服务, 这个第三方服务叫做serviceLoadedFromExternal, 它提供了一个API叫做makeServiceCall, 如果直接使用这个API, 那么在测试中很难去验证这个服务被执行了(因为在单元测试环境中这个服务根本不存在), 但是如果我们将这个服务包装成一个angular service, 那么就可以在测试中轻易地将它替换成一个mock对象, 然后验证这个mock对象上的方法被调用了就可以了.比较下面的两段代码:

  • 直接使用第三方服务
angular.module(“TheNG”, [])
  .controller(“AController”, function ($scope) {
    $scope.someAction = function () {
    // handle some logic here
    serviceLoadedFromExternal.makeServiceCall();
   };
});
  • 使用封装成service的第三方服务
angular.module(“TheNG”, [])
  .factory(“wrappedService”, function () {
    return {
      makeServiceCall: function () {
        serviceLoadedFromExternal.makeServiceCall();
      }
    };
 })
 .controller(“AController”, function ($scope, wrappedService) {
   $scope.someAction = function () {
   // handle some logic here
   wrappedService.makeServiceCall();
   };
 });

Angular是高度模块化的, 它希望通过这种模块的形式来解决JS代码管理上的混乱, 并且使用依赖注入来自动装配, 这一点与Spring IOC很像, 带来的好处就是你的依赖是可以随意替换的, 这就极大的增加了代码的可测试性.

尽量将Ajax请求放到service中去做

Angular中使用service来组织那些可被复用的逻辑, 除此之外, 我们也可以将service理解为是对应一个领域对象的操作的集合, 因此, 通常会将一组Ajax操作放在一个service中去统一管理.

当然了,你也可以通过向你的directive或是controller中注入$http, 但是我个人不喜欢这种做法. 首先, $http是一个比较初级的依赖, 与其实注入的业务服务不是一个抽象层级, 如果在你的业务代码中直接操作http请求, 给人的一种感觉就像是在Spring MVC的request method中直接使用HttpServeletRequest一样, 有点突兀, 另外会让整个方法失衡, 因为这些操作的抽象层次是不一样的. 其次就是给测试带来的麻烦, 我们不得不使用$httpBackend来模拟一个HTTP请求的发送.

我们应该设法让测试更简单,通过将Ajax请求封装到service中, 我们只需要让被mock的service返回我们期望的结果就可以了. 只有这样大家才会喜欢写测试, 甚至是做到测试驱动开发, 要去mock$http这样的东西, 显然是增加了测试的负担.

使用Promise处理Ajax的返回值, 而不是传递回调函数

Angular中所有的Ajax请求默认都返回一个Promise对象, 不建议将处理Ajax返回值的逻辑通过回调函数的形式传递给发送http请求的service, 而应该是在调用service的地方利用返回的promise对象来决定如何处理.

让我们通过下面的例子来感受一下:

angular.module(“TheNG”, [])
  .service(“deliveryService”, function ($http) {
    this.validateAddress = function (address, success, failure) {
      $http.post(‘/unknown’, address).then(success, failure);
    };
  })
  .controller(“DeliveryController”, function ($scope, deliveryService) {
     var acceptAddress = function () {
       console.log(‘address accepted’);
     };
     var rejectAddress = function () {
       console.log(‘address rejected’);
     };
     $scope.validateAddress = function () {
     deliveryService.validateAddress($scope.address, acceptAddress, rejectAddress);
   };
});

这里的处理办法是将快递地址验证失败或成功之后的处理函数都传给了deliveryService, 当验证结果从服务器端返回之后, 相应的处理函数会被执行. 这做写法其实是比较常见的, 但是问题出在哪里呢?

其实, 作为一个service的接口, validateAddress应该只接收一个待验证的地址, 验证完成之后返回一个验证结果就可以了, 本来应该是一个很干净的接口, 我们之所以丑陋把对应的处理函数也传进去, 原因就在于这是一个异步的请求, 所以需要在发请求的时候就将对处理函数绑定上去.

你应该已经猜到了第二个问题我会说一说对它的测试, 通常来说, 如果一个service创建成本较高或是存在外部依赖/请求的话, 我们会将这个service mock掉, 通过让mocked service直接返回我们想要的结果来让我们只关注被验证的业务逻辑.我们回头看一下上面的实现, 如果我们把deliveryService的validateAddress()方法mock掉, 那么我们根本没有办法去验证acceptAddress()和rejectAddress()里面的逻辑!

所以, 如果你的处理函数是传递给service中的API的话, 那么你的测试其实就已经跟这个API的实现绑定了, 你只有去创建一个真实的service并且让它发送HTTP请求, 你的处理函数才会被执行到.

经过这一番折腾, 你一定要说, 这测试比实现代码难写多了. 正确的打开方式应该是这样的: service的API只需要返回promise, 对应的处理函数的绑定在这个返回的promise上, 这样我们只需要mock那个service的接口让它返回一个我们期望的promise, 然后控制promise的结果让对应的处理函数被执行:

angular.module(“TheNG”, [])
  .service(“deliveryService”, function ($http) {
    this.validateAddress = function (address) {
      return $http.post(‘/unknown’, address);
    };
  })
  .controller(“DeliveryController”, function ($scope, deliveryService) {
     var acceptAddress = function () {
       console.log(‘address accepted’);
     };
     var rejectAddress = function () {
       console.log(‘address rejected’);
     };
     $scope.validateAddress = function () {
       deliveryService.validateAddress($scope.address).then(acceptAddress, rejectAddress);
     };
 });

本来打算接下来介绍一下Angular代码的单元测试的各种模式的, 写着写着篇幅有点多了, 期待下一篇吧.

Share

快速搭建IE测试环境(Virtualbox+ievms)

IE下的测试

作为一个有追求的程序员,应该尽可能的远离Windows系统。不论从专业开发者的角度,还是仅仅作为最终用户从使用体验上来说,Windows都可以算是垃圾中的战斗机:没有shell响应极慢(比如从开机到可用需要多久,再对比一下Mac下的体验)、大部分操作都强依赖于鼠标,没有对应的快捷键、各类病毒等等。

但是,作为一个职业的程序员,又很难绕开Windows这个猥琐而又事实上很现实的存在,毕竟Windows在非专业市场上的占有率还是不容小觑的。一般而言,开发人员可以很轻松的使用现代的操作系统,编辑器,开发工具完成实际的业务需求,这部分工作很可能占整个交付工作的40%,但是又不得不在多个浏览器(IE的各个版本)中花费另外的60%。

既然很难抛开,那么我们就需要想办法简化对其的使用,比如将Windows隔离为一个纯粹的测试环境(不安装任何其他的软件,并且一旦感染病毒之后可以快速恢复)。

  1. 将Windows安装到虚拟机中
  2. 使用工具将诸如下载镜像,安装系统,安装特定版本的IE等操作简化为一条命令
  3. 可以很容易的创建一个干净,纯粹,稳定的Windows环境

ievms正是这样一个工具,它提供安装了各种版本IE的Windows操作系统的镜像,支持IE6到IE11。默认的,用户可以安装从IE6到IE11的所有镜像,但是很可能你无须所有的环境,ievms也提供对应的参数来确保只下载某一个。

不过对于一个团队来讲,可以安装所有的镜像到团队的某台公共的机器上,供所有人来进行跨IE浏览器的各个版本的测试。

这些虚拟机镜像都是虚拟磁盘vmdk文件,因此你需要先安装VirtualBox)。

安装ievms

安装ievms非常容易,只需要下载一个脚本即可:

1
$ curl -s https://raw.githubusercontent.com/xdissent/ievms/master/ievms.sh -L

github会将该请求重定向,所以加上-L参数来跳转到实际的地址。下载之后,执行该脚本:

1
2
$ chmod +x ievms.sh
$ ./ievms.sh

默认的ievms会下载所有的虚拟机镜像,可以通过参数IEVMS_VERSIONS来选择特定版本的虚拟机:

1
$ ./ievms.sh IEVMS_VERSIONS="7 8 9"

当然,也可以将这些命令合并为一行命令:

1
$ curl -s https://raw.githubusercontent.com/xdissent/ievms/master/ievms.sh -L | IEVMS_VERSIONS="7 8 9" bash

用法

安装之后,一个新的虚拟机会被添加到VirtualBox中,只需要启动这个虚拟机即可:

image

另外,在这个虚拟机中,可以很方便的连接到宿主机。比如在宿主机上的12306端口运行了某个Web应用,那么通过地址:http://10.0.2.2:12306 来访问这个应用。

注意: 由于是整个虚拟磁盘的形式发布,因此这些镜像的体积都非常大,所有的镜像安装之后,会占用37G的空间,对于任何一个开发机来说,这个尺寸过于庞大,但是对于整个团队来说,应该还是可以接受的。

官方给出的尺寸列表如下:

1
2
3
4
5
6
7
8
$ du -ch *
 11G    IE10 - Win7-disk1.vmdk
 11G    IE11 - Win7-disk1.vmdk
1.5G    IE6 - WinXP-disk1.vmdk
1.6G    IE7 - WinXP-disk1.vmdk
1.6G    IE8 - WinXP-disk1.vmdk
 11G    IE9 - Win7-disk1.vmdk
 37G    total

 

Share