视频采访剪辑:微软研发团队的私有云应用之道 (二)

3. 物理服务器增加而维护人员并未增加   原视频地址:http://v.csdn.hudong.com/s/article.html?arcid=302330   谭茂:背后的话,这1,500台服务器,加上上边的几千个虚拟机,维护人员是什么样的变化? 刘擎:维护人员我们其实没有人数的变化,最早的时候,其实是三位在上海,北京这边业务还没开始,事实上从09年开始在北京增加了新的团队,我们增加了1位工程师在北京。那么人数的增加,从服务器相当于增长了2.5倍,人数没有增加。   谭茂:像这1,500台服务器,按照业界标准它大概需要多少人管理? 刘擎:这个各个地方都不太一样,我举个美国的微软内部的一个指标。我们其实还没有达到微软内部的指标,微软内部的指标是数据中心是1,000台服务器配备一位工程师。这是微软数据中心的标准。   4. 传统物理服务器如何无缝迁移   原视频地址:http://v.csdn.hudong.com/s/article.html?arcid=302331   谭茂:还想回到技术这一块来聊,其实我们也想了解,包括现在很多客户他们也想去建私有云,但他们比较为难的一点,就说他们做传统的物理的服务器怎么去无缝的迁移到私有云上,这块你们有没有一些经验? 刘擎:这块其实我们和传统的工业碰到相同的问题,在我们做迁移的时候,我们第一步想解决的问题,就是你刚才提到的问题,就是我们怎么把现有应用往虚拟化去迁。在微软的System Center产品里面,就设置了一个P2V功能,就是指从是为了把一些早期的服务和应用,从物理机迁移到虚拟机时,通过这个功能话,基本上在10到20分钟左右,就可以把一个运行在硬件层面上的Windows、Linux以及应用,转到虚拟机当中。可以保留所有的设置,可以保留所有的团队关系,所有的应用的设置,包括存储、数据库。 其实当初我们还用了一个方法,就是说在我们把物理机的资源迁到虚拟机以后,我们把物理机重新安装,就是我们把它叫做Reprepare,重新放回到资源库来,让它变成虚拟化可用的资源。原来它干一件事情,现在它干三件事情。这样的话,我们就可以最大化。   谭茂:还有一点,其实我们知道在云里边是用了微软相当多的微软的一些技术,一些产品在里面,其实过去的数据中心都会有些管理工具,一些程序,将来这种,特别是基于平台的这种服务器,管理可能是个大的麻烦。微软在管理中,因为微软自己也有本身的产品。这块? 刘擎:这个其实也是我们全体工程师,就说一步步走过来说碰到的最多问题。我们最开始在看,我们各家厂商的意见,有惠普、戴尔、联想、浪潮的服务器,每家有自己的管理工具,像惠普有Insight manager和Dell 的OpenManage,同时我们还要管理实验室的交换机和存储。这时候就像你刚刚提到的,我们怎么去管理这么多的系统,我们看了挺多的开源管理工具和商用管理工具。最后我们看下来,还是使用微软的System Center最方便。 我们可以和思科的设备,我们可以和戴尔的OpenManage,可以和惠普的Ingisht Manager,可以和联想的管理工具,可以全部整合在一起,我们通过一个平台看到思科的交换机里面的CPU的负载是什么情况,可以看到戴尔服务器的功耗,风扇的速度、CPU内存,可以在一个平台可以看到所有的信息。并且每个设备的健康状态,都会通过email实时地反馈,我们可以在第一时间主动的去做相应的行动。   谭茂:像这种管理,它是通过跟思科标准,开发的人员自己是根据这个接口去做的? 刘擎:这个没有,因为所有的厂商都遵循共同标准,比方说思科是遵循SNMP网络管理标准,戴尔有自己专门设计的符合微软COM标准的套件。那你把这些套件,这是一个自由下载的软件包,实际上是描述它的硬件。它们都是免费下载的。通过这些,就可以监控这些服务器,一直到硬件这个层面。包括比方说内存的插槽出现了错误,硬盘可能马上要损坏,第几个硬盘,第几个内存,都可以把这些进行实时报告。     5. 微软虚拟化的安全和性能 原视频地址:http://v.csdn.hudong.com/s/article.html?arcid=302332   谭茂:其实虚拟化,可能大家现在不容易接受,他们仍然对他们的一些安全是有质疑的,在虚拟化的安全? 刘擎:的确很多用户除了在安全化虚拟上有很多的疑问,我们包括实际测试,还有微软内部,其实微软的虚拟化它的产品目标,因为我们设计每个产品都有产品的目标,比如这个产品要解决什么样的问题。所以我们会从我们产品设计的目标和我们实现的目标,我们可以看到基本上在98%的转化效率以上,这样的话,基本可以说做到了1:1这样一个转化效率,你可以理解成一个虚拟机它的性能和实体机是完全一致的,在CPU转换上。内存就肯定原来就是那么多,而在磁盘效率上它是根据运行虚拟机,你只要达到I/O的最大值,就是安全的。刚才你提到安全这一块,实际上这个和业界的虚拟化上,实际上有些标准,你怎么去做虚拟机的分块。   谭茂:98%的转化效率,是基于Windows平台之上? 刘擎:实际上所有的东西,它CPU转换效率,下面在执行的时候,不管是Windows还是Linux。它实际作为一个假的CPU,所以虚拟化有一个假的CPU,你的那个虚拟机是在这个假的CPU上。转换效率是把那个虚拟机pass掉。   谭茂:现在整个系统,你们也在做一些调优,优化? 刘擎:我们日常工作中,第一个是不停的往里加新的机器,因为我们有很多项目会进来,同时我们会把一些资源做淘汰。实际上我们日常的管理工作就是在这个平台上维护。 还有一块,就是我们在这个平台的自服务门户上加新的东西,我们在做比方说我一级的管理,我这个管理在上海,但我们现在已经有一些美国的,北京的一些数据中心的服务器加到上海这边来。这样的话,我就可以一个平台上管理微软本身。因为我们这个项目的要求,异地同时工作,但至少他需要两个人工作在同一个平台上,我们就需要把它整合到一起。   谭茂:另外还有一个我们比较关心的是在这种战略当中,因为基于虚拟化的自动化,管理服务化,这是虚拟化最核心的工作。其实这块的话,您也谈到一点,微软也做了很多工作在自动化管理这一块,具体谈一下。 刘擎:虚拟化实际上在真正的对生产力提供影响,让虚拟化技术,让这个云技术变得像电、水这样更方便的使用,你肯定得需要一些配套设施,比如你必须有大楼的强弱电布线,然后才能够送到用户。实际上虚拟化技术把计算能力也是以这种形式出现的,首先你看我们工程师需要什么,他需要几个虚拟机,我们怎么能更快地通过服务门库这样一个简单的方式,然后选择。在我们的库里面提前准备好几千个虚拟机的模板,用户需要的话,就是根据他的选择,就像点菜一样,是要一个中式的,西式的,湘菜还是粤菜,他测试中需要选择什么,我们把这些都准备好,这就是料。他可以直接去选择,需要通过我们自动化的机制,那么他选择他的那个菜,直接就可以变成他要用的东西。 所以我们会为用户去选拔,虚拟化技术,自动化整合在一起,为内部客户们服务。   谭茂:目前你们通过什么来实现的? 刘擎:通过VMM的SDK,它会有一个基于Power shell的自动化脚本。我们首先会理解用户需求,他可能会需要三个机器,我们把这个共同需求抽象出来,因为我们和很多团队谈,他们有一些共同的需求,把这些共同需求抽象出来,我们作为一个服务包,然后这下面是通过VMM的自动化脚本,可以把很多东西都自动化。这样的话,用户用起来就不需要重复自动化的工作,这也解决了我之前所提到的一个问题,就是团队和团队之间会重复。我们现在把这个重复全部抽象起来,变成一个层次的东西,我们把它叫Virtualization Infrastructure…

0

视频采访剪辑:微软研发团队的私有云应用之道 (一)

    不久前,我们中国团队的研发工程实验室经理刘擎先生接受了CSDN云计算频道负责人谭茂先生的视频采访,在CSDN的帮助下,我们选取了11个视频片段和相关的文字速记与大家在此分享。   1. 微软私有云环境介绍 原视频地址:http://v.csdn.hudong.com/s/article.html?arcid=302328 谭茂:各位网友大家好,今天我非常高兴请到了微软亚太研发集团,服务器与开发工具事业部研发工程实验室的经理刘擎先生,他主要负责STB 中国团队内部私有云。我们知道业界其实大家对于云计算这块也是关注了很久,那么微软的云计算也是大家,包括很多客户所关心的一些东西。 首先想请刘先生,您能简单介绍一下,您在上海的一些主要工作。 刘擎:大家好,我在上海,在2007年加入STB中国团队。负责服务器与工具开发事业部在上海的研发工程实验室管理。主要负责向微软的开发、测试和产品经营的团队提供实验室服务。其中包括Test和Build,就是产品构建,还有产品的性能,产品设计。 我们在上海实验室主要的工作包括管理一个1,500多台服务器的实验室,同时在上面我们从2007年开始去构建微软一个私有云。那么这个私有云会基于微软的平台,就是System Center的产品,其中包括有微软虚拟化服务管理系统,然后有服务器管理,还有管理客户端,包括微软的数据库管理,这四块帮助我们管理整个微软在上海1,500多台服务器。 下面我们会用到微软的Opalis,这是一个微软的IT流程自动化的管理工具。 谭茂:您刚才也是介绍了对微软整个实验室的介绍,我们还想了解一下更细节一点的,它现在有没有一个比较明确的一些数字? 刘擎:在我们上海的话,我们会把上海实验室其中有1,500台服务器中,有400台是性能比较不错的服务器,构建了一个私有云,这个会有412台物理机器,同时运行5,000多台虚拟机,这样一个能力,400台到5,000台。其中这5,000台基本总有3,000多台是处于激活的状态。在整个管理平台上,我们把团队的资源就是按照分组的方式,大概有超过13到15个产品组,我们会把他们分配到不同的组里面,每个用户会在自己的组里面分配他的虚拟机资源。       2. 微软私有云的创新 原视频地址:http://v.csdn.hudong.com/s/article.html?arcid=302329 谭茂:和传统的数据中心相比的话,你觉得微软目前的私有云最大的一个区别或者说有创意的地方在哪? 刘擎:对我们来说,最大的一个优势在于微软平台和Windows兼容性非常好,我们用了Hyper-V,它实际上是基于微软的虚拟化平台的一个管理工具,它对我们的第一个优势就是说它兼容性好。其次就是说它可以很方便地把我们对数据中心,对服务器的管理,变成了一个对资源的管理。我觉得这是一个很大的云对我们的优势。因为讲云的话,最能够体现出云的优势就是自服务,资源化,这两块就是说能够通过这个软件,完全是看到了物理器这一块,对用户来说,他是看到了资源,而不是一台一台服务器。 在我们的内部设置的一个用户的自主网站,他可以很清楚看到,他有多少CPU,有多少虚拟机,有多少内存可用。对于他计划他能用的预算,他就可以有一个很好的安排,我现在资源可能是40%,明年他就不要升级。如果说他90%,他明年就要升级。 同时对我来说,团队之间的调度。其实在云里面,刚才我讲了资源池。 还有一块就是资源利用率的最大化,原先的话,每个团队把自己的资源放在一个实验室里面,相互之间没有一个很好的共享平台,在有了这个虚拟化管理,他可以很容易地去共享团队资源。就类似这个项目A,他有自己忙的时候,繁忙阶段。在另外一个团队繁忙,他没有更多的机器的时候,他除了购买新的机器的时候。现在有个选择,可以从别的团队调一部分资源过来,因为所有的机器都是虚拟化的话,他不会相互干扰。 第二个,他可以很容易地把他的虚拟机迁移到他的服务器上做负载,这样的话,就变成完全像用电一样,在以前我小时候有电的调度,我父母单位里面会有调电这种说法,就说周三他必须要休息,因为他工业用电调给民用电去使用。现在我们在一个微软团队内部,就可以实现这种调度,很容易把物理机的资源从这个团队调到另外一个团队,就是要鼠标移动一下就行了。 谭茂:这个硬件利用现在有一个没有新的? 刘擎:我们从2007、2008、2009年就慢慢在做,首先我们机器的利用率是一步一步在往上提高。当初我们在看的时候,可能和业界的标准比较像,从12%到14%-15%的利用率。现在的话,我们基本上把这翻了八倍,到今年我们2011年5月份,数字已经到八倍。可以看到每台机器可以跑八倍。这是一个平均值。 谭茂:我们注意到业界,国内目前来说还没有特别成熟的私有云案例,很多也是处于这种创新跟市场研发,从您的技术角度来讲的话,您觉得这种研发到应用,就是生产率这一块目前主要的瓶颈是在哪方面会比较多? 刘擎:其实我是这样看这个问题的。那么当我接受这份工作,我在看我们团队,实际上我就在一个研究问题,微软研发团队它的工作的瓶颈在什么地方,什么问题需要去解决的。其实从去年接手工作,花半年时间在调研内部的流程,资源,内部的工程师的工作习惯,内部工程师在使用这个系统的时候,会有哪些地方是好的,哪些地方是不好的。我们在设计这个虚拟云的时候,目标就是解决最优先的三个问题。实际上我觉得比较理想一个方案去解决一些业界问题,就是说你先理解你现在的企业,你现在碰到什么样的问题,哪些是需要最先解决的问题。 我们当初其实谈到了,一个是说团队之间的资源的共享。然后团队与团队之间有很多的重复劳动,因为微软软件开发它不同的项目实际上是有挺多的情况,他会做相同的工作。举一个简单的例子,他们在做测试的时候,是要先把Windows部署到一个环境中,然后构建一个网络环境,跑没有发布的产品。实际上建立这个Windows环境,构建一个网络环境,其实不同的团队都要做相同的事情,所以原先的做法,就说每个团队有自己一套自动化、脚本,团队A写了一遍,团队B写了一遍,团队C也写了一遍。这是一个问题。 第二个问题,我们看到在我们问题表里边,就是说工程师对于部署完所花的时间非常有意见,因为你部署完这个东西,比如Windows装完至少要20分钟,再安装所有的最新的补丁至少要40分钟,这样的话,整套完成时间至少要一个小时。如果说物理机在做这个测试的时候,你如果做一个AD,通过服务器,没有两个半小时是完不成的。一天八个小时,你准备一套花两个半小时,就是你一天最多只能做四套。现在我们虚拟化技术可以并行去做,我们可以看到每一个虚拟器,从开始部署到结束只需要20分钟左右时间。你从两个半小时缩减到30分钟,那这样的话,他至少可以做八倍的事情。这是一个提升。这就是我们去评估我们私有云怎么去提高生产利用率这块。而且可以并行的。 谭茂:这在过去也是不可想象,从生产效率而言,应该是大大提高。 刘擎:对。

0

用Visual Studio实践敏捷测试(四) 下

测试运行的实现       测试运行可以通过Team Foundation Server提供的生成功能来实现。在Team Explorer的生成菜单中选择创建新的生成定义(Build Definition),通过指定不同的触发器(Trigger)就能使其分别适应于封闭签入、滚动生成或定期测试运行的需要,如图一所示。 图一 触发器       在生成默认值选项卡中指定生成控制器(Build Controller),在生成控制器接到生成请求的时候会在生成代理(Build Agent)池(即在该控制器上注册的所有生成代理)中选择一个来执行生成任务。 图二 生成默认值       而在流程选项卡中可以指定需要生成的对象、运行的测试用例等具体内容,如图三所示。这里需要特别指出的是在指定运行的测试时,还可以指定测试配置文件,在该配置文件中可以将测试执行方法(Test execution method)设置为远程执行(Remote execution)并选择一个测试控制器(Test Controller)。这样测试控制器就能将测试分配到器上注册过的不同测试代理(Test Agent)上运行了。 图三 流程       关于如何创建和配置生成控制器、生成代理、测试控制器、测试代理,感兴趣的读者可以查阅msdn上有关的信息,在此我就不再赘述了。       通过这些设置,就可以配置出不同的生成,以满足开发过程中各种不同的测试运行需要。 小结       在本系列的最后一篇中,我们讨论了各种不同的生成和测试运行的目的、作用以及如何选择运行的测试用例。各种不同层次的测试运行相结合,才能最大限度的发挥测试用例的作用,在兼顾“敏捷”的同时,保障产品的质量。另外,我们还简单介绍了Team Foundation Server提供的生成服务,以及如何通过生成服务来实现测试运行。         至此,我和大家分享了整个敏捷开发的测试流程、我们的开发团队的如何利用Visual Studio作为辅助工具实现敏捷测试以及我们在实践中积累的经验教训。希望这个系列能抛砖引玉,为大家实现自己的敏捷测试提供一些参考资料。 🙂 林俊彦 软件测试开发工程师 本文收录于《程序员》10月刊。

0

用Visual Studio实践敏捷测试(四) 上

     在上一篇中我们介绍了如何编写自动化的测试用例,在拥有了一定数量的自动化测试之后,随之而来一个很自然的问题就是如何有效地利用这些测试更好地在敏捷开发的过程中保证产品的质量。在这一篇中我们就来讨论一下基于不同目的的各种生成(Build)和测试运行(Test Run)以及如何实现这些运行。   封闭签入(Gated Check-in)      在本文的第一篇中我们曾经提到过在敏捷软件开发过程中每一个Sprint结束时团队都应该有一个可以运行和演示的版本。这对团队成员来说是一个艰巨的任务。因为一方面必须在有限的时间内完成用户故事的开发,提供相对完整的用户体验,这就要求开发人员“敏捷”迅速的签入代码;而从另一个角度来说,频繁而迅速的签入显然会对生成的稳定性带来极大的挑战。尤其是当团队成员以用户故事而不是产品部件来分工时,签入与签入之间常常会有重叠的部分。在这种情况下,如何才能保证各项签入在集成到产品中后,产品还能正常工作呢?封闭签入就是一种比较严格的实时保护产品功能的方法。        所谓封闭签入是指在签入代码之前,先尝试生成文件,如果生成失败则拒绝签入,只有在生成成功的情况下代码才会被签入代码控制系统中去。这里的生成,可以是单纯的编译生成,也可以在此基础上再运行一些指定的自动化测试以验证生成的质量。使用这种方法的优点是能很好地确保了指定的用户场景(即指定的测试用例集所覆盖的用户场景)不会被破坏,而缺点就是拖延了时间甚至可能造成阻塞——签入必须等待生成完成、测试用例运行结束,而且签入还可能被拒绝,一个签入可能要反复多次提交,更糟糕的是在几次提交之间其他团队成员可能也提交了签入请求,这又进一步延长了一次签入所需的时间。        为了使封闭签入不至于成为开发流程中的瓶颈,我们必须在生成测试覆盖和生成时间二者之间找到一个平衡点,即在保证每次签入能在较短的时间内(通常我们认为<10分钟是比较理想的范围,10~15分钟是可以接受的范围)将结果返回的前提条件下选择适当的测试用例以达到所期待的用户场景覆盖。很显然,为了满足上述要求,测试用例的运行时间及其覆盖的内容是选择测试的主要依据,而另外一条不可忽视的选择标准是测试的稳定性——运行不稳定的测试用例显然不适合用于在短时间内决定签入是否符合要求。以下列出几条我们选择封闭签入测试集的原则供大家参考: 从基础用户场景入手:我们不可能在封闭签入中保证所有已有的功能不被破坏,在时间有限的情况下,只能丢卒保车,只关注那些基础的、核心的用户场景,围绕这些场景选择测试。对于其他功能场景的验证保护将由我们稍后介绍的其他一些测试运行来完成。 单元测试是封闭签入测试集的主力:开发人员编写的单元测试通常是直接与产品部件接口对话,运行稳定且速度快,是封闭测试的首选。特别是在我们的开发团队中,对于开发人员签入的功能严格规定了必须同时签入相应的单元测试,这使得单元测试对产品功能的覆盖率相当高,使其更能胜任封闭签入测试的职责。 在单元测试基础上补充部分验收测试:单元测试虽然以运行速度快且稳定两大优势占据了封闭签入测试的主要部分,但是单元测试所针对的还是独立的产品部件或是方法,保证产品各部件正常运作不代表各部件集成起来之后仍正常工作。所以为了确保产品的端到端用户体验,我们有必要从测试人员编写的验收测试中抽取部分核心场景的测试来完善整体用户场景的测试覆盖。 尽量不要在封闭签入测试集中引入UI测试:UI测试不可避免的与运行速度慢和不稳定联系在一起,与封闭签入的需求几乎正好相反。但我们也不能一概而论,直接规定不允许在封闭签入测试集中添加UI测试。比如特定的UI测试能提供别的测试无法达到的产品覆盖,且该测试覆盖到的用户场景十分重要,在这种情况下也可以考虑将该测试添加进测试集,当然前提条件是,该测试足够稳定且运行时间不能过长。      在我们的实践过程中,基本上就是采用了单元测试+核心非UI验收测试这样的组合。另外,我们还在部署测试运行方面利用了Visual Studio提供的测试代理(Test Agent)功能实现测试的分布式运行,大大缓解了运行时间和测试覆盖之间的矛盾,为更全面的用户场景覆盖提供了可能。我将在本文稍后对测试代理再做介绍。   滚动生成(Rolling Build)      滚动生成是另一种实时的保护产品已有功能的方法。与封闭签入拦截签入并插入验证的做法不同,滚动生成并不监控代码的签入,而是采取了相对宽松的方式——允许随时直接签入代码,在代码签入之后再进行相应的验证。滚动生成自动对当前时刻已签入的产品代码重复执行生成文件和运行指定测试操作,每一次的滚动事实上验证的对象是从上一次滚动开始时刻到当前时刻之间的所有签入。当某一次的滚动生成失败时,在此期间签入代码的团队成员应该负责尽快找出并修复错误,或者在错误无法迅速修复的情况下撤回导致问题的签入。也就是说滚动生成并不会直接影响团队成员的正常开发工作,但是要求大家在确实出现问题时暂停手头的其他工作及时将产品代码恢复至一个合理的状态。        对滚动生成测试集的选择标准相对于封闭测试要宽松一些,因为滚动生成并不要求签入的个人等待其结果,所以没有太大的运行时间压力。我们对滚动生成的期望一般是1个小时左右滚动一次。在实践中我们囊括了几乎所有验收测试,对各项功能都有一定程度的覆盖,在滚动生成保持通过的状态的情况下,我们对产品代码的实时质量还是有相当的信心的。另外,为了规避不稳定的测试用例带来的不必要的结果分析时间,我们还引入了再次运行失败的测试的策略,只有2次运行都失败的情况下,滚动生成的结果才会被认为是失败。        与封闭签入相比,滚动生成的主要优势包括: 滚动生成不阻碍签入,不影响正常的开发节奏,不会造成瓶颈 滚动生成每一次运行针对多个签入,测试的效率更高 滚动生成不要求很短时间内出结果,换句话说,可以允许执行更多的测试用例        而滚动生成也有其不足之处: 滚动生成并不能保证产品“随时”都处在可正确运行基本功能的状态 滚动生成不能及时将签入的质量反馈给团队,例如在某一次滚动刚开始后发生的签入几乎需要2次滚动的时间才能确认是否达到了签入的要求 滚动生成在出错时需要分析多个签入以找出问题所在,花费了额外的时间        在实践过程中,通常封闭签入或是滚动生成中的一个就可以满足团队对于产品功能保护的需要了,开发团队可以根据实际情况选择其中之一。不过有时也可以将二者结合起来同时使用。同时使用的好处是分工更加明确,封闭签入就只运行单元测试等少量最核心的测试,甚至可以不运行测试只生成文件,尽可能减少额外的等待时间;而滚动生成则负责完成对基本用户场景的完整覆盖。   定期测试运行      前面介绍的两种生成+测试运行都是用于功能的实时保护的,都对运行时间上有较严格的要求,所以测试用例中大量的功能测试通常是不会在这些测试运行中被执行的。完整的测试集通常只在定期测试运行中使用。这里的定期可以是每天一次、每周一次或是两周一次等等,可以根据团队具体需要以及完整测试集运行所需的时间来确定。        我们的产品开发使用的是三层的分支结构的源代码树,平时的改动都在功能分支(Feature Branch)上进行,每一个Sprint或一个里程碑做一次和产品单元分支(Product Unit Branch)的集成,从产品单元分支到产品主干(Main…

0

用Visual Studio实践敏捷测试(三)下

自动化测试的实现       编写自动化测试也许对很多测试人员来说比较陌生。所幸的是Visual Studio中为实现自动化测试提供了一系列的工具,单元测试(Unit Test)、编码UI测试(Coded UI Test)、压力测试(Stress Test)、网页性能测试(Web Performance Test)、数据库单元测试(Database Unit Test)等等,让实现自动化测试变得轻松。这里我想着重介绍2种最基本的,也是在我们的产品开发中最常用的测试:单元测试和编码UI测试。 1. 单元测试       单元测试是Visual Studio中最基本、应用最广泛的一种测试。通常开发人员可以选择为一个方法或是一个部件创建单元测试,来保证其逻辑正确。       要在Visual Studio中创建单元测试,可以在源代码的上下文菜单中选择“创建单元测试”,并在弹出的窗口中选择需要为其创建单元测试的方法(如图一、图二所示)。这样Visual Studio就会自动创建出一系列单元测试的代码框架,以及针对private/internal等无法直接调用的方法的访问器(Accessor),用户只需修改或添加具体测试逻辑即可。访问器会随着源代码的每一次编译自动更新,为用户节省了不少麻烦。当然,用户也可以使用单元测试向导创建,或是直接添加一个单元测试(测试->新建测试)文件再自行添加逻辑代码。 图一 创建单元测试 图二 创建单元测试对话框       单元测试通常以[TestClass]属性来表示一个测试类,在测试类中使用5种不同的属性标示方法:[ClassInitialize]、[TestInitialize]、[TestMethod]、[TestCleanup]、[ClassCleanup]。一个测试类中可包含多个测试方法(Test Method),但是仅可以有一个类初始化方法(Class Initialize)、一个测试初始化方法(Test Initialize)、一个测试清理方法(Test Method)、一个类清理方法(Class Cleanup)。在测试运行时,类的初始化会被首先调用,然后在运行每一个测试方法之前运行测试初始化,之后运行测试清理,在测试方法运行结束后,类清理方法将被运行。除测试方法外,其他的辅助方法都不是必须的。大家可以根据实际需要来安排代码逻辑。       成功编译后,所有测试方法都会在测试视图(Test View)窗口中列出,在该窗口中还可以对测试方法进行过滤、查询和排序,选择一个或多个测试方法后,可以运行或调试测试用例。测试的结果(是否通过)会显示在测试结果(Test Result)窗口中,双击任意一条测试结果都会打开具体的测试结果日志以获取更详细的信息,如图三所示。单元测试还可以通过直接在测试方法代码中右键选择“运行测试”,或是在命令行中直接执行mstest命令来运行。 图三 测试视图和测试结果       此外,单元测试工具不仅可以用作单元测试的目的,也可以作为一种载体,来实现验收测试或是功能测试。我们在实践中大量利用了Visual Studio对单元测试的管理、运行、日志等功能,通过在测试代码中实现验收测试、功能测试的具体逻辑来完成各种不同类型的测试。 2. 编码UI测试       虽然单元测试框架适用于各种不同的测试,不过其本身却没有提供太多对测试代码实现上的支持。对于自动化测试中常常令人无从下手的UI操作的自动化,Visual Studio 2010中添加了一种新的测试类型——编码UI测试,以帮助用户克服这一难题。编码UI测试是一种能轻松上手,迅速创建出UI测试的框架。       一种最简单的创建UI测试的方法是直接从手动测试入手。如果此前我们曾在Test Manager中创建了测试用例,并曾在手动执行时录制过其测试步骤,那么我们就可以直接将录制的步骤转化为编码UI测试的代码。在Visual Studio中选择创建一个编码UI测试后,会跳出一个对话框询问用户是使用已有的操作录制还是重新录制,选择第二项“Use an existing action recording(使用现有操作录制)”后即可通过查询测试用例工作项将相应的测试转化为自动化测试代码(见图四)。…

0

用Visual Studio实践敏捷测试(三)上

    在上一篇中,我们讨论了敏捷开发流程中的一些由手动执行的测试任务。手动测试是需要人工完成的测试,被广泛应用于各类产品的各种测试任务中,而与之相对应还有自动化测试,即通过程序自动运行完成测试任务。自动化测试能帮助开发团队节省测试运行的人工、提高开发效率。接下来在本篇中,我想和大家讨论一下敏捷开发中手动测试和自动化测试之间的关系以及如何实现和利用自动化测试。   手动测试的特点     由于手动测试依赖于人工操作,很自然的存在着不确定性,每一次的操作都可能或多或少有一些不同。这种不确定性既是手动测试的优点,也为其带来了一定的局限性。从优点的角度来说,手动测试更加灵活多变,可能在不经意间就采用了一种全新的操作序列,或者将产品带入一个意料之外的状态。这有助于深入测试产品功能的细节,覆盖那些常规思路无法到达的用户场景。而从另一个角度来看,手动测试的不确定性也使得其测试覆盖的内容无法预料,在需要保障测试的覆盖面时,就显得有些不足了。此外,手动测试也不适应于大规模、大数据量、长时间或者是多平台的测试,人工完成这样大的工作量是困难且没有必要的。 手动测试的这些特点就导致其适用于那些允许灵活甚至是要求灵活的小规模的测试任务,比如伙伴测试就是个很好的例子——测试内容不那么死板,期望测试执行人有一些创造性。   自动化测试     自动化测试充分利用了计算机“任劳任怨”执行人类给它的指示的特点,用程序实现需要的测试,此后该测试就可以被多次自动执行。在测试会被大量运行的前提下,这不仅能节省重复人工劳动,更重要的是提供了一种迅速而准确的保证测试覆盖的方法。特别是在敏捷开发紧张的节奏下,自动化测试的这些特质能起到十分显著的加快开发进程的作用。       那么什么样的测试需要自动化呢?       最显然的是诸如压力测试等需要大量操作的测试场景。比如我们常常要求产品能承受连续8个小时以上的各种操作,这样大强度的压力测试并不适合人由工完成,显然自动化测试能更好的完成该项任务。 接下来是那些核心的功能和主要的用户场景,这些是产品最需要保护的部分,所以我们希望能在代码改变的情况下及时地运行相关的测试,以保证它们不被破坏。在敏捷开发高速运转、频繁签入的状态下,自动化这些测试以便能将其在封闭签入(Gated check-in)等测试运行中迅速自动执行、及时发现问题,能在很大程度上保证产品开发流程的顺利进行。同时,将这些重要的测试自动化也能避免手动测试的“偷工减料”问题,计算机总是会忠实的执行每一个测试步骤的。       此外还有一些从其本身特性而言不适合手动执行的特殊类型的测试,比如模糊测试(Fuzzing Test)要求大量生成随机数据一一对产品试验,也是自动化测试能大展身手的地方。   自动化测试的度     在这里我想提醒大家的是测试的自动化的程度并不是越高越好。在我的开发团队中,我们曾经将测试计划中高达95%以上的测试都自动化。这样的带来的显著优势是自动的测试运行提供了很好的覆盖率,从而保证了各项功能都能保持正确工作。但是,也带来了一些问题:首先,编写自动化测试程序需要大量的时间,很多时候让程序自动操作执行产品功能特别是产品UI是件很困难的事情,需要大量的时间和精力来实现测试程序本身。其次,当产品功能变化时,修改测试还要花费额外的成本,不像手动测试那样随时都可以更改。另外,自动化测试还有一个容易被忽视却十分重要的问题——远离了用户体验。当测试被“傻瓜式”自动执行时,我们根本无法得知其相对应的用户场景的使用感。举个简单的例子,再不方便使用的功能如果只写一次程序我们多半是可以忍受的,但是如果要手动执行,恐怕三五次就会让人受不了了。所以把握手动测试和自动化测试的比例是颇值得研究的一个话题。       在意识到过量的自动化测试会使其从辅助开发的工具变为团队的负担和障碍之后,我们调整了自动化测试的策略,采取了一种渐进式添加自动化测试的方案。在产品生命周期的前期,功能快速的被添加且行为随时可能改变,此时对测试的需求偏向于尽可能迅速完成对新功能的测试,自动化测试所需的建立测试框架以及在功能改变时修改代码的代价在此时显得过于昂贵了,所以我们更倾向于做较多手动测试,只实现少量简单而核心的自动化测试。而随着产品功能的不断添加和趋于稳定,不再有大量的新功能需要测试,而更多的需要用于保护已有功能不被破坏的自动化测试,此时可以陆续添加测试计划中那些之前没有时间自动化的测试用例。在产品生命周期的末期,特别是产品将有多个版本时,准备全面的自动化测试覆盖以保护产品功能不被破坏则成为主要的测试任务之一。       林俊彦 软件测试开发工程师       本文精简版收录于《程序员》9月刊。

0

应用Visual Studio 2010 辅助敏捷测试 (三)

四、早测试和经常测试——封闭签入和滚动生成     敏捷开发中最可怕的事情莫过于在迭代最后一两天进行测试,结果发现了严重功能缺陷或者回归缺陷,导致不能按计划发布给用户试用。要想彻底解决这样的问题,一方面要在迭代开发阶段测试人员就要参与进来,从客户的角度出发对功能需求和设计文档进行文档测试,即文档评审。测试人员和开发还有项目经理一起从源头上保障将要实现的功能是用户想要的。另一方面就是要在迭代的早期就开始就开始测试,特别前几个迭代已经实现好的自动化测试用例,尽早的执行它们可以有效地避免回归问题的出现。在TFS 2010 上专门提供封闭签入(Gated Check-in)、滚动生成(Rolling Builds)和持续集成(Continuous Integration)等功能,帮助敏捷团队实现早测试和经常测试。这其中封闭签入和滚动生成是对敏捷团队比较实用的功能。     封闭签入是TFS 2010 提供的一种新的代码签入方式,在配置这项功能后,当用户要签入任何代码时,系统会先将用户本地要签入的代码打包成一个搁置集(shelve-set),然后提交到服务器端,TFS 生成(Build)服务先从TFS 源代码控制器中同步项目的最新代码,再将提交的代码与之进行自动合并,然后进行编译,如果编译成功,则执行配置的自动化测试用例,如果测试用例全部通过则代码会被自动签入到代码库中,否则返回错误信息给用户,代码是不会进入到代码库。表面上看是与产品测试没有直接关系,但实际上它和测试以及最终产品质量的密不可分。因为代码签入是整个开发过程中发生最为频繁的操作,每次签入代码的质量直接影响着日常的开发活动。对于绝大多数的开发团队来说,check in 代码前不仅要保证编译通过,同时还要最大限度的保证新代码不会破坏已有的功能,也就是要执行测试用例去验证。Gated Check-in 中提到的“Build 成功”,实际上包含两部分内容:编译成功和测试用例执行成功,有了它作为保护代码库的第一道屏障,就可以保证它在任何适合都是可编译,并且达到一定质量标准的。     滚动生成是在VS 2008 种就有的功能,当TFS 检测到在它所监控的范围内有任何新的代码变化被签入后,它就启动对最新的代码库进行生成验证,该验证包括编译和运行指定的自动化测试用例。之所以称之为“滚动”,因为它是在一个生成验证操作完成后再去探测有没有新的签入发生,对这期间发生的所有新签入进行新的生成验证。这里需要再强调一下滚动生成的重要意义:它看似只是一个自动生成代码的功能,但实际上起着协调整个开发团队、时刻监控代码库质量、以及尽早暴露产品问题的作用。因为滚动生成时刻都在不停的运转着,对于任何代码签入它都保持着警觉,会去自动验证编译是否成功,自动化测试用例是否都能通过。它就像一个不知疲倦的“代码守护者”一样监控着代码库,第一时间发现其中的任何问题,将问题通知给整个团队,从而避免了问题的积累和拖延。这非常符合敏捷开发中“今日问题今日解决,不要拖到以后”的原则,它帮你最早的发现问题、报告问题,开发团队则应该建立制度要及时响应滚动生成所报告的问题,把它作为Priority 为0 或1 的高优先级问题去对待和解决。     封闭签入和滚动生成都是来保护代码库的正确性和产品质量,它们是否在功能上重复反而让我们不敏捷了呢?其实两者并不重复,只是各有侧重,将它们搭配使用才会发挥其最大效能。 封闭签入是在代码进入代码库之前进行验证,签入提交者一般希望竟快知道结果,以便决定下一步的工作,所以封闭签入的时间(编译和运行测试用例)不要太长(10-20 分钟)。这也就决定了我们加入的测试用例不能太多,只添加那些高优先级的测试用例,保证主要的用户故事不被破坏。滚动生成是在代码签入后在后台执行的,由于不存在着与用户的交互等待,所以它执行时间可以更长(几个小时),可以为它加入更多的测试用例,从而全面验证代码库的质量,一旦有任何问题它可以及时通知团队进行修复,这种验证是在几个小时或者每天都在发生的,保证了敏捷对频繁测试的。 五、完整的自动化测试解决方案——实验室管理     在谈到软件自动化测试的时候,很多人会误以为实现了自动化测试用例就是自动化测试,其实不然,自动化测试仅是测试自动化的一个重要步骤,绝对不等同于自动化测试。一个完整的自动化测试应该包括:构建、部署、执行测试用例、分析测试结果并作出结论。在前面的自动测试的收益公式中,我们可以看到减少自动测试的维护成本,是提高自动测试收益的重要因素之一。VS 2010 的实验室管理(Lab Management)与测试用例管理、生成管理、源代码控制、工作项管理等功能相结合,为自动化测试提供了这样一个完整的解决方案,目标就是要降低了自动测试的运营和非维护成本,下面这张图展示了实验室环境的系统构架图。       实验室管理功能充分利用了微软的虚拟化技术,包括:Hyper-V 和 System Center Virtual Machine Manager (SCVMM),快速创建干净的虚拟测试环境并进行产品生成和部署,然后执行指定的测试用例集,将结果以报表的形式呈现出来,方便对此产品质量进行分析,如下图所示:     同时,利用虚拟技术的环境快照功能,对于那些难于复现或者环境相关的Bug,利用虚拟环境的快照技术,可以为开发人员准确的复现Bug 出现的环境,从而能够快速的进行诊断和及时修复。 总结     Visual Studio 2010…

0

应用Visual Studio 2010 辅助敏捷测试 (一)

    敏捷软件开发是近些年来比较热门的话题,《敏捷宣言》四条主要精神和十二条基本准则概括了敏捷开发的基本思想。围绕着这些基本概念和思想,产生了一系列的轻量级方法,如:极限编程、测试驱动开发、Scrum、特性驱动开发等。虽然具体名称、过程和侧重点不尽相同,但是相对于非敏捷的开发方法而言,它们都更强调面对面的沟通、团队不同角色之间的紧密协作、频繁交付新的可用的软件版本、紧凑而自我组织型的团队等。敏捷开发只是提供了一个思想和方法论,而要在实际的工程中正确运用它,并真正显现出它的优点和产生实际的效果,这对于每个团队而言一开始都是一个挑战,尤其是对那些那些习惯了传统瀑布模式的团队。     敏捷是整个团队的敏捷,不只是团队中某个角色或者某个阶段的敏捷,开发、测试和项目经理等所有角色都要敏捷起来。敏捷方法的采用对团队每个成员都提出了新的挑战,尤其是测试人员。之所以这样说,是因为相对于传统的瀑布模型,敏捷开发所要求的频繁交付,给测试所留出的时间更为紧迫,要求测试人员更早的介入和更及时地完成测试任务。如何在这么短的时间内完成测试的计划和实施呢?如何有效地避免回归问题的出现?手工测试人员如何能更好的融入到敏捷团队?等等问题接踵而至,这都需要需要测试人员不断的思考和尝试。     无论是哪种开发模式,软件的开发过程都可以归结为:人、工具和过程这三个因素,三者的有机结合才能更高效的完成任务。有人会说:《敏捷宣言》四条主旨精神的第一条就是“个体和交互重于过程和工具”,工具还有那么重要吗?回答是肯定的,工具很重要,这条主旨所提到的是“重于”而不是不要。为了支持敏捷开发,Visual Studio 2010(以下简称为VS 2010)应用程序生命周期管理中引入了 MSF for Agile Software Development v5.0 过程模板,用于辅助敏捷团队在实际工程中进行敏捷实践,它支持Scrum 敏捷开发过程框架。本文将从工具角度出发, 介绍Visual Studio 2010 如何帮助测试人员更胜任敏捷项目中的测试工作。对于工具与人的关系而言,好的工具应该是将人从重复和机械的劳动中解脱出来,让人有更多的精力和时间花在有创造性地劳动上,而由工具去完成将繁琐和冗余的事务性操作;而对于工具和过程的关系,工具是过程能够得到确实落实和准确执行的基石,很多时候我们总是依赖于人去执行某个过程或者流程要求,但人的执行往往带有一定不稳定性和主观性,而工具则可以帮助我们准确客观的执行。 一、团队有效协作的基石——Team Foundation Server     敏捷开发强调人与人之间的有效沟通和紧密的团队协作。对于测试团队和测试人员而言,首先应该需要考虑的是:如何让测试工作更有效的集成整个敏捷开发的活动中去?而不是将测试工作仅作为一个“附件”或者可有可无的副产品。当然,这会受到团队组织形式和开发过程的限制,例如:采用功能小组模型的团队,所有角色成员(PM、开发人员、测试人员)隶属于同一个功能团队,客观上其沟通就更为方便;而对于采用纵向按职能划分团队的公司而言,测试和开发在隶属关系上是分开的,相对在沟通上障碍就会更多些。无论是哪种组织形式,好的工具能帮助促进和统一各个角色间的信息互通和共享,而不是要让他们彼此之间更为孤立、工作在各自的一亩三分地(Silo)中。Team Foundation Server 2010(以下简称为TFS 2010)就是这样的工具,作为整个团队协作的核心,它统一了团队不同角色信息、实现了信息之间的有效互联互通、彼此之间的共享和关联,例如:TFS 2010 定义6 种默认的工作项类型,如下图所示。       其中,Test Case 和 Shared Steps 是2010 专门为测试新加入的。不要小看这些工作项,它们之间有着丰富的关联关系,这种关系背后所代表是角色之间的关系。对于测试而言,它将测试和团队紧密的结合在一起。例如:Test Case 工作项用来详细定义和管理测试用例,它还可以和User Story 相关联,也就是将测试和用户需求进行了关联,用户可以从需求追溯到覆盖的它的测试用例,这背后体现的是测试人员和需求人员/PM 的协作;Test Case 还可以与Bug关联,通过这种关联可以挖掘出哪些 Bug 被测试用例覆盖,哪些还没有,这种关联体现了测试人员与开发人员的写作,如果是自动化测试用例,则体现了手工测试人员和自动化工程师的协作 ;Bug 还可以可以和签入集(Change-set)关联,可以找到为了修复Bug,开发人员修改过哪些产品代码,这体现了测试人员和开发的关联。      …

0

用Visual Studio实践敏捷测试(二)下

Bug的生命周期       无论采用何种测试形式、执行何种测试任务,都会产生一系列的Bug。而开发团队需要一个健全的Bug管理的机制。一般来说,一个Bug的生命周期大致要经过如下几个过程:  图4 Bug的生命周期     这里大多数的阶段都比较易懂,需要解释一下的可能就是Triage过程。Bug在创建出来以后,首先要经过Triage小组讨论决定是否需要修复。Triage小组一般由项目管理、开发和测试三方的代表组成。对于每一个Bug,小组快速的根据重现步骤、结果等信息,估计其严重程度、可能的原因、修复的代价和风险,以决定是否要修复这个Bug。如果Bug中提供的信息量不足以判断,Triage小组会将其发还给创建者要求补充更多的信息。如果Triage小组无法在短时间内对Bug的成因、修复等做出估计,那么就会将Bug指派给一个相关的开发/测试人员进行调查,并要求他将调查结果附上之后,重新提交Triage。     另外,如果一个Bug被拒绝修复,但是创建者却坚持己见的话,可以进一步在Bug中添加理由:对用户影响、可能的严重后果等,然后重新提交Triage。类似的,如果一个Bug被批准修复,但是被指派修复的人员认为没有必要修复、修复难度/代价太大时,也可以将理由附上,要求Triage小组重新裁定。     Triage会的频率在整个产品开发过程中是不相同的。在产品开发的开始阶段,团队的主要活动就是开发新功能,此时可能数天甚至数周才能签入一个功能,Triage会一周一次就足够了,保证本周在大扫除中所发现的Bug都会被及时处理。而当产品逐渐进入开发周期的末尾时,团队主要的活动就是修复Bug,此时就最好能每天Triage,迅速对Bug做出反应,以便能更好的管理项目的进度。     除了Triage会的频率会随着产品开发而改变外,Triage的标准也会随之调整。在新功能刚签入的时候,可能很小的问题或者改进建议都会被批准,以帮助更好的完善该功能。而当功能相对稳定时,就要开始考虑修复的代价/风险以及为用户带来的价值之间的平衡点了。到产品周期的末尾阶段,此时Triage的标准将会非常严格,只有对用户影响非常大,且修复的代价/风险都比较小的Bug才会被批准修复了。     Triage的意义在于在较短的时间内,项目管理/开发/测试三方都对团队现有的Bug有整体的了解,并提供各自的意见,快速的剔除重复的、不值得修复的问题,且保证了整个团队对Bug是否需要修复有一个统一的标准。 Bug的管理     我们的团队采用TFS的作为Bug的管理工具。团队成员可以轻松在Visual Studio或是Test Manager界面中创建、查询、修改Bug。值得一提的是,TFS提供的默认的Bug模板并不一定能满足团队的需要。这里就可以用到TFS提供的修改工作项定义的功能(导出工作项定义->修改->导入工作项定义),将Bug改造为合适的样子。在我们的团队中使用的Bug模板就是我们自己定制的。     这里我想和大家分享几个我们在实践中得出的有助于Bug管理的域: 1. 子状态(Sub Status)     Bug的状态一般就只有Active、Resolved和Closed三种,但这并不足以表示针对该Bug的具体工作的执行状态。所以我们添加了一个子状态域,它包括以下几种子状态: Investigating:正在调查问题原因 Working on Solution:正在修复问题 Fix Available:修复已经准备好了 Testing fix:正在测试修复 Blocked:暂时无法修复或验证修复(比如有另一个Bug导致无法修复该Bug) 2. 回归(Regression)     这个域表示该Bug是否是一个回归Bug,即之前经验证的正确行为在后来的某个时刻无法正确执行了。在相同的优先级和严重程度的情况下,回归Bug会得到比新Bug更多的关注。因为我们不希望在修改代码的时候,破坏其他的功能。 3. Triage     这个域是为了记录Triage结果而专门设立的。Bug创建时通常把Triage状态设为“提交(Submit)”。在Triage小组开会讨论后,会根据处理意见将其分别标注为“同意(Approved)”、“更多信息(More Info)”“调查(Investigate)”、“拒绝(Rejected)”。Triage状态在Bug的整个生命周期中还可能不断变化。比如,一个Bug被拒绝后,创建者还是认为应该被修复,可以将Triage状态改回Submit,然后补充更多的理由或信息;这样Triage小组就会重新讨论并决定对该Bug的处理意见。再比如,一个Bug被修复后,测试人员认为修复后的结果仍然不理想,也可以将Triage状态改回Submit,说明修复之后的行为和理想中的行为分别是怎样的,以及他认为现在的行为不够理想的理由;Triage小组会根据更新过的行为重新讨论是否值得再次修复。 4. 测试用例状态(TC Status)     对于任何一个Bug,作为测试人员都应该问的问题是:这个Bug已经被我们的测试计划覆盖了么?如果没有,值得我们为它添加一个新的测试用例或是修改已有的测试用例么?这就是“测试用例状态”域的作用。在创建Bug或是Triage的时候应该标注该域为以下几种可能: Exists:测试用例已存在 Needed:需要添加测试用例 Need Update:需要修改已有的测试用例…

0

用Visual Studio实践敏捷测试(二)上

    本文的第一部分(上、下)着重介绍了测试人员在敏捷开发过程中,需要完成的一些测试准备工作。对于读者来说,这些工作项可能会比较陌生,但在敏捷开发中却对保证开发的质量和速度起到了很重要的作用。在这一部分中,我们将进入大家较为熟悉的实际测试阶段,为大家介绍测试任务的执行以及Bug的管理。     在整个敏捷软件开发流程中,存在着各种测试任务。比如,伙伴测试(Buddy Test)、常规的测试运行(Test Run)、Bug的验证、Bug大扫除(Bug Bash)、Dogfooding等等。但是,无论具体任务如何变化,测试总是以3种形式存在的:执行测试用例、Ad-hoc测试和实际使用产品。这里我重点介绍两种重要却不太常见的测试任务,以囊括解释这3种形式的测试是如何进行的。 伙伴测试     在开发人员第一次签入某个功能(或者签入重大的修复)之前,为保证构造的稳定性,往往会先将代码通过Team Foundation Server(TFS)的搁置集(shelveset)发给相关的测试人员做伙伴测试。伙伴测试常常是测试人员同某一新功能的第一次亲密接触,是实际测试的开端。同时,它也是一种非正式的手动测试,因为这些代码尚未签入,测试人员发现的问题并不构成bug,他们也不会将其记录到Bug数据库中。     在伙伴测试中,测试人员需要关注以下几点: 功能:开发人员新实现的(或是改动过的)行为是否如预期的那样工作 边界:开发人员实现(或改动过)的行为是否完整,是否忽略了某些特殊情况 回归:那些原先能正常工作的功能是否被新的改动破坏,是否产生回归错误     那么,如何入手来做伙伴测试呢?这里就需要我们前面提到过的2种不同形式的测试: 1. 执行测试计划     在伙伴测试时,执行一次制定好的测试计划是一个好主意。在真正接触到产品功能前制定好的测试计划,可以提示测试人员各处细节,使得伙伴测试更全面;同时测试计划也有助于保持测试人员的客观性。这将很好的覆盖到功能测试,也能照顾到大部分的边界测试。     通过在Test Manager中切换至的Test标签(如图1所示),我们就可以在Test Runner工具中执行测试计划中的测试用例。 图1 测试标签     图2所显示的是Test Runner在运行测试时的样子。左边是Test Runner界面,这里会依次列出选择运行的测试用例的测试步骤(如果测试用例带有多组数据,则该测试用例会被列出多次,每次显示不同的数据)。右边的部分相当于普通的桌面,你可以在这里执行Test Runner中列出的测试步骤,并在Test Runner中标注每个测试步骤是否执行成功、记录执行结果、或是截取运行时的屏幕截图,也可以直接创建Bug。测试步骤、运行的结果、运行时的环境等各种信息,不但会被添加进运行结果报告中,还可以被直接添加到Bug中。同时Test Runner还支持将手动执行的测试步骤“录制”下来,这样下次运行同一个测试用例时,就不用手工操作了,可以让Test Runner自动执行。 图2 Test Runner     2. Ad-hoc测试     既定的测试计划并不足以覆盖测试人员在伙伴测试中所有关注的重点。于是我们需要引进一个新的机制——Ad-hoc测试。Ad-hoc测试一种比较随机的、自由的手动测试,有时我们也称其为“玩自己的产品”。它不需要事前详细的计划,也不需要全面的覆盖。它可以只是随意的试用某个功能,也可以是用各种数据“折磨”某个功能。它可以是专注于一个功能,也可以是随意的在几个功能间切换。大多数时候Ad-hoc测试就是灵光一现的“如果我在这一步这样做会怎样呢?”而这恰恰是最容易发现bug的一种测试。因为写成文档的测试计划往往都是比较主要的用户场景,开发人员也会偏重于保证这些场景能够正确工作。而Ad-hoc这种随机的测试却往往能深入到一些意想不到的地方,找出隐藏的问题。     不过从伙伴测试的关注点出发,在这里我们做Ad-hoc测试时可以有一些重点:开发人员关于其改动的意见、测试人员基于以往的经验容易出错的地方以及与改动相关的主要的用户场景。这样Ad-hoc测试就能帮助测试人员覆盖一部分边界情况,以及回归测试。     Ad-hoc测试可以发生在开发周期的任何时间。几个常见的场合包括新功能签入后团队成员的试用、每周一次团队成员的Bug大扫除等。     做Ad-hoc测试也可以利用之前我们介绍的Test Runner工具。首先,在你的测试计划中添加一个Ad-hoc测试专用的测试用例,执行它之后就可以利用同样利用Test Runner来来记录包括操作步骤在内各种信息了。使用这种方式的最大好处就是避免了在随机测试中测试步骤难以记录下来的问题。     Test…

0