软件测试价值的转变

软件测试的历史应该从程序诞生的那一天就有了,随着软件的发展,特别是互联网应用对软件发布的影响, 软件测试的价值也在逐渐发生了很多变化。 软件测试从单纯的发现软件缺陷,发展到“软件质量度量”,“预防质量缺陷” 等更大的质量范畴。随着从单纯的“质量保证” ,发展到“开发效率的提升”。     首先,我们回顾一下软件测试的定义, 1979年Fred Mayer发布的测试经典 《软件测试的艺术》(The art of software testing ),它将软件测试定义为“带着发现错误的目的,执行被测软件”,简单的说就是通常人说的:软件测试就是找缺陷,找Bug。 1995年Stephen H.Hank 写过一本书(《软件质量工程的度量和模型》) metrics and models in software quality engineering,它用工程的方法引入软件质量度量和软件质量周期的管理,质量度量包括代码覆盖率,测试用例的覆盖率和执行情况,用户满意程度,运维的质量管理等等。 2007年 微软的几个资深测试人员写了一本书"The Practical Guide to Defect Prevention "(《质量缺陷预防实践指南》 讲的就是如何通过在软件过程,方法和技术上,预防软件缺陷的产生。 2008年 喜欢数据说话的Caper Jones 推出了 "Global Analysis of Productivity and Quality"《全面分析生产率和质量》, 从经济学,软件流程等的方面分析了生产率和软件质量之间的关系,其中也包括一些好的实践。 然后,我们再看一看软件公司的变化 微软:比尔 盖茨说过 “微软是一个测试公司”,可以说微软是非常重视软件测试的,在有些团队,软件测试人员数量超过开发人员。在光盘发布软件的时代,修复Bug的成本是非常高的。随着,Internet 应用的发展,应用软件有了更加快速的发布周期,服务器端修复Bug成本降低了很多,同时通过引入Testing In Production。微软也在引入一些变化,微软的开发人员有更多的责任,进行质量保证,包括单元测试,产品中缺陷的支持等,软件测试人员更加注重E2E的测试,测试框架,提高整个软件的开发效率等。 谷歌:谷歌的开发和测试人员的比例是10:1,同时测试人员属于Productivity的部门,测试团队大部分是由丰富经验的测试人员,能够在新项目刚开始的时候,帮助建立测试框架,将其他项目好的测试经验带到这个项目中,项目执行起来以后,开发人员来编写,执行测试用例,并且对产品的缺陷直接负责。


Testing In Production 在生产环境中进行测试 摘要

Testing In Production 的概念大约出现3年前,那时候Web Service正在风靡Internet,各种系统都走向更加可扩展的架构,这使得A/B Testing和后期的数据分析更加容易。同时,整个互联网应用对用户体验提出了更高的要求,对算法的精准性的要求更加严格。另外,软件开发的节奏明显加快,这使得测试无法在发布前做的非常完善。快节奏的软件发布,对测试有了更高的要求。 “先发布,后测试”成为一种加快发布节奏的一种必要的方法。 动物学家达尔文说过 ”世界上进化下来的动物,并不是那些最强大的动物,也不是那些最聪明的动物,而是那些最能够适应变化(Responsive to change)的动物”,例如说老鼠,人,蚂蚁等等。软件系统也一样,能够传承发扬的软件,能够快速适应变化化。 TiP的核心思想就是通过在生产环境里面测试,最小化产品风险,加快发布节奏。TiP通过暴露新代码给有限用户,减少缺陷可能带来的负面影响,通过在产品中暴露这些新代码,可以快速获得这些新代码的反馈,这些反馈来之于真实的用户,而不是少量的测试人员和有限的测试用例。另外,一旦发现新代码有严重的缺陷,那么TiP需要快速修复这些缺陷,通过发布新版本或则滚回到老版本。 那么这是不是对软件质量的一种妥协呢? 我觉得不是,相反在生产环境中测试可以更好的满足用户,它是传统发布前测试的一个积极的补充。例如,TiP可以帮我们提高测试覆盖率,找到一些平时无法测试到的场景。 我相信,所有的互联网软件都需要支持TiP,这是互联网软件的特性决定的:灵活的软件架构,快速的发布周期。 考虑一下几个问题可以帮助我们思考什么类型的软件最适合TiP方法。 用户体验和经济利益影响的程度 如果产品有问题,是否有能力快速检查产品中的问题,并且快速回退到没有问题的版本? 软件发布的频率? 进行TiP 所带来的成本和收益 这里有几个TiP的例子 1) 微软:在互联网的产品开发过程中,微软也大量利用了TiP的方法 a. 很多用户场景的改进,都是通过A/B测试获得最好的效果 b. 算法实验,在灵活的平台中进行算法的调优和筛选 2) Facebook : Facebook如何发布代码的 Link a. Facebook有多个级别的代码部署 (内部的,少量外部的,全部外部的等等..), b. 如果有问题出现,工程师马上修复问题;然后重新发布 c. Ops负责部署的实际过程,包括检测产品的健康状态(错误日志,CPU,内存,甚至包括用户的行为变化等) 3) Google: 非常善于做A/B测试 a. 谷歌在算法改进方面,就是利用在产品中的实验平台。一个搜索结果中可能包括多个算法的结果,另外不同的搜索可能触发不同的算法。最后通过用户的反馈,对算法进行评价和挑选。 一些参考资料: 人物: Seth Eliot 微软测试经理,Testing in Production的倡导者 Blog 参考文章: 1)…


VS 2010测试解读2-给测试用例做标签

在VS2008中,测试列表(Test List)的管理通常是通过*.vsmdi文件。在实际开发过程中,大家发现这个功能有很大的局限性。 1) *.VSmdi中的所有测试用例需要手工加入到列表 2)如果多人需要访问测试列表文件,其管理会变得很不方便 VS2010出来了,它通过测试分类(Test Category),很好的解决了这个问题。其原理也很简单,通过给每个测试用例,可以设置不同的标签,在运行用例时,可以通过过滤标签的属性来运行。其方法如下: 步骤一: 为每个测试用例设置测试分类属性(Test Category),在方法的属性中增加。 [TestCategory("Nightly"), TestCategory("Weekly"), TestMethod()] public void TestMethod1() { // // TODO: Add test logic here // } 步骤二: 通过测试分类,运行测试用例 1)从UI中,选择测试用例运行 2)通过命令行运行 mstest /testcontainer:MyTestprojectName.dll /category:"Nightly&Weekly" 在条件选择时候,可以使用&或则|作为操作条件;但是在VS2010中,只能用一种操作符号  


VS2010测试解读-读懂那些文件们

Visual Studio是我喜爱的一个开发IDE,从VS2003开始,到VS2005,再到VS2008,再到最新的VS2010。每一个版本的改进都是让人兴奋的,每一次使用新版本后,哪怕是Beta版,都不愿意再回到老版本。最新发布的VS2010有很多创新的功能,对测试提供了大力的支持。本文就一一解析这些新功能,让大家能够体会到VS2010的创新,具体的感受还要大家在使用过程中仔细感受。 VS2010是一个集成的开发环境(IDE),大部分的操作都能通过界面的操作完成,通常你不需要了解文件的细节。但是读懂这些文件,能帮助你更好的理解整个测试框架,以便使用一些高级的测试功能和做一些自定义的扩展。 首先我们来看看一个典型的解决方案,通常放啊 在这个解决方案里面,我们有以下一些重要的文件和项目: 1)应用程序项目(被测试的应用,开发人员负责) 2)测试项目(测试人员负责) 3)*.testsettings文件; 在VS 2010中,自动产生两个,一个是TraceAndTestImpact.testsettings用于调试的测试设置,另外一个本地缺省的测试设置。VS2008只有本地缺省设置。 多说两句*.testsettings,这是运行测试的环境参数和运行参数,包括以下内容: a) 用例运行前后执行的脚本 b) 是否启用数据分析(代码覆盖率,测试影响分析,模拟网络,录制视频,智能跟踪等等)很多功能都是VS2010独有的, c) 运行机器是本机还是远程机器 d) 测试超时时间等   VS2010 增强了测试监控功能,例如智能跟踪(IntelliTrace)和视频录制(Video Recoder),测试影响分析(Test Impact)等等 4)*.vsmdi文件,用于管理测试用例的列表(Test List). *.vsmdi文件是管理Test List的,在VS 2010中虽然支持,但是不推荐使用了。主要原因是*.vsmdi非常不灵活,很难集中维护。取而代之的是更加自然的测试分类(Test Category):通过给每个测试用例设置标签,运行的时候通过标签选择需要运行的测试用例。 为了兼容问题,VS2010 还是支持*.vsmdi。下面是*.vsmdi的一些基本格式。 其内容基本上包括一个树状内容的Test List 列表,各个节点通过ParentListID相连,其中包括一个特殊根节点。另外,在每个TestList中,一个TestLink代表一个测试用例,TestLink的ID是通过测试方法名,测试类名和包名等,通过MD5计算而得(而非任意值),我以前就写过一个程序,自动生成*.vsmdi文件。 运行测试 写好测试用例就可以运行,Ctrl F5,就这么简单,能够得到测试用例运行的结果。很容易在IDE看到,测试结果,那么如何读懂后面的文件呢? 一次测试运行结果的目录:   我们一步一步来解释。重要的文件有*.trx文件. 在多说两句,运行结果目录。其中有In, Out 和每个TestCase的详细结果。


虚拟化技术在软件测试的应用

1)什么是虚拟化 虚拟化技术很早就提出来了,但是真正走向市场是从2005年以后,那时候AMD和Intel公司都开始推出支持虚拟化技术的CPU。简单的说,虚拟机就像一个软件容器,可以安装操作系统和应用软件,像一台物理机一样运行,其有如下特点。 操作系统和软件无法辨别其主机是否是虚拟机。 多台虚拟机器像应用程序一样可以运行在主机上 2) 虚拟化技术的优势 2.1) 提高硬件的利用率       根据调查数据,通常测试实验室的硬件的使用率是很低的,平均只有10%,通过虚拟化技术可以使利用率提高到80%。 * IDC 的数据中心趋势调查,2007 年。  2.2) 低碳生活 降低数据中心的成本(省电/空间),能源成本降低 80%。大部分机器5-15%时间处于使用状态,而空闲状态耗电量为满负荷60%以上。  2.3) 高管理性 通过虚拟化技术,计算机的管理(虚拟机)的管理变得更加简单,创建、修改一个计算机的操作可以瞬间内完成。这种高管理型有助于推动基础设施服务化(Infrastructure as Service)的发展。目前,有很多云计算的基础设施都是大规模使用了虚拟技术。 大家可能对SaaS都比较熟悉,这里我解释一下IaaS和PaaS。 基础设施作为服务(IaaS):计算机资源通过服务的方式提供出来,包括处理能力,存储和网络能力等等。 平台作为服务(PaaS):平台和工具能通过平台或API方式提供出来,提供更加高层次服务,例如数据库存储服务,J2EE服务,.NET平台等。 3. 虚拟化给软件测试带来的好处 通过虚拟化技术,软件测试可以获得很多好处,以下就是一些例子; 3.1)测试实验室(Test Lab)的建立 空间 时间 电力 如图所示的一个例子:168 台式机,被12个服务器主机代替。省空间,省电,方便管理,大大降低了测试实验室建设的成本。 大部分的测试环境对测试机器的性能要求都不是很高(性能测试除外),那么对于这种情况,虚拟机是非常适合的解决方案。虚拟机可以用于测试实验室(Test Lab)的构建,支持自动化测试,也可以为远程的测试和开发人员提供机器服务。 举例来说,一个网站的测试,需要10个手工测试人员进行,那么我们可以创建10个虚拟计算机,那么只需要1-2个主机就行了,并且支持远程工作,那么这些手工测试人员可以在家里进行工作。 3.2) 软件快速部署和连续集成 虚拟机的管理是非常方便,这大大促进了快速部署(Fast Deployment)和连续集成(Continual Integration)。举例来说,在连续集成的时候,往往需要大量机器,并且快速恢复到某个系统的初始状态。虚拟化技术的高管理性能够很好满足这些需求,同时成本比物理机器要低很多。 3.3)测试用例失败后的调查 在测试用例失败后,通过保存机器状态,可以方便问题的调查。如果使用物理机器,这些机器就需要被占用,一直到问题调查完毕。而且,调查的状态具有不可恢复性。如果使用虚拟化技术,计算机状态可以被保持到到文件;在需要调查问题时,随时可以把虚拟机文件恢复到虚拟机进行调查;同时机器的状态可以随时保存,随时恢复,这给一些不容易重现的问题提供了有利的调查方法。 3.4)虚拟硬件的使用 虚拟化不仅仅可以模拟软件,也可以模拟硬件,包括网卡,光驱,USB接口等等。特别是USB接口的虚拟化,使得在很多USB设备驱动的测试提供了便利。另外一个例子是虚拟光驱,Vista开发出来后,安装以前的方法要制作DVD光盘来进行最后的验证。按照传统的做法,需要180张DVD光盘,需要花2个星期。而使用虚拟化解决方案,制作ISO 映像,只需要2天时间。 4 虚拟化过程中一些好的实践 4.1 仔细设计网络拓扑结构   对于一些对网络特别要求的实验室,需要仔细设计网络Top结构,特别是IP地址的数量…


天文历法改革与测试

过年了,聊一聊传统的中国天文历法,顺便说说测试。 中国古代很多聪明的人都是天文学家,他们有祖冲之,沈括,郭守敬等等,因为天文是一门魅惑的学科,蕴含着无数的简单的和复杂的规律。天文历法是天文学家可以直接将研究结果贡献社会的最好方式。让我们看看这些天文学家和他们的历法,最后总结一些其中关于测试的思考。 祖冲之,南北朝人,大家都知道他是著名数学家,将圆周率精确到小数点后7位,他的精度在1000年以后才有人打破。其实,他也是一位卓越的天文学家,他创建了《大明历》,将一年的精度误差缩小到50秒之内,并且在日历中引入岁差方法,大明历是历史上第二次历法改革。另外,据说指南车也是祖冲之发明的。 祖冲之 北宋的沈括是中国古代最博学的科学家,他”博学善文“,不仅仅文科很好(他是北宋的进士),而且他所著作的《梦溪笔谈》涉及到天文,数学,水利,生物,农学,医学等等。在天文方面,他积极推行平民出生的天文学家卫朴的《奉元历》(已经失传),据说此新历比旧历有很多的创新,而且对人民日常生活也一定的影响。,新历法只推行了18年,就因为反对派的阻挠而失败了。在梦溪笔谈中,沈括还提出了一个新历法,其内容和现在的阳历基本一样,一年分为12个月,每月30天或者31天,总共是366天,一年分为三季,孟,仲和季。另外他还是设备专家,对当时复杂的浑天仪做了改进,简化了其结构,提高了设备的可用性。 博学善文的沈括 另外一个是我非常敬佩的郭守敬,他是元朝天文学家,数学家和水利学家。北京的通惠河就是郭守敬主持修建的,现在还在造福北京的通州人民。他最大成就在天文学上,他制定了《授时历》,该历法定义的年与现代科学计算出来的年只相差26秒,是当时世界上最精确的历法。在修订新历法的4年过程中,他在全国东西南北建立了27个观测站,通过坚持不断的观察,终于制作出高水平的《授时历》。同时,他还根据《授时历》,执行了中国第四次天文历法改革,并且使得该历法沿用至以后700多年,现在所说的农历基本上就是《授时历》的延续。 郭守敬纪念馆,北京 话说这三人推行的天文历法改革,两次次成功,一次失败,这是为什么呢?我感觉新历失败的原因可能是”用户体验不好“,给人们生活带来太多的变化和冲击。另外,尝试穿越一下,如果你是这三种历法的测试人员,你会不会考虑如下的问题? 1)如何确保天文历法的精确性? 有些预测的数据,需要很多年,甚至数百年才能预测,如何验证新历法的准确性? 2)如何确保新历法对农业生产没有负面的影响?人们是否愿意接受新历法? 虽然,我们可以在小范围内做些调研,但是人们实际上无法预测一个社会现象真正带来的社会影响。


一个测试人员眼中的VS 2010

by cheno VS 2010是微软即将推出的最新开发工具套件,全球的正式发布时间将定于4月12日。在过去半年内,本人一直使用VS 2010,从Beta 1到Beta2,以及现在使用的RC版本,可以说是陪着VS 2010一起孕育,同时期待着它的正式发布。可以非常肯定的说,VS 2010对软件测试的支持力度,远远超过以前的任何VS 版本,并且在很多方面有革命性的改变。同时,作为一个集成的产品,对软件开发周期有了非常完整的支持。下面,我就从一个测试人员的角度,看看它提供了哪些实用的功能。 1)VS 2010的基本信息 VS 2010 主要分为3个版本,Professional版本,Premium版本和Ultimate版本。 Professional对于测试的支持非常有限,Premium支持除了性能测试之外的各种测试,Ultimate版本是一个全集。详细版本信息,请看这里.这里有个图可以做参考。 版本 测试工具 VS 2010 Ultimate -Preminum版所有功能 -负载测试(Load Test) -网络模拟器 -Test Agent, Test Controller VS 2010 Premium -Professional版所有功能 -ASP.NET Profiler -Coded UI Test -Test Data Generator VS 2010 Professional -单元测试(Unit Test) 2)Coded UI Test(可编程的界面测试) 它提供了QTP或WinRunner类似的功能。支持录制和回放功能来创建测试用例,内建软件对象模型(Object Modeling),录制的脚本可以为不同的.NET语言,例如VB,C#等。以下是简单的支持应用列表。 支持 应用 全部支持 -IE7, IE8…


软件测试2009

        By cheno 天仪变换,岁律更替之际,总结一下2009年我眼中的软件测试的热点,作为2009年年底总结博文。 1)软件测试会议 这里列出一些我经常关注的软侧测试会议,多为软件行业会议,这些会议的参与者多为软件公司的测试管理人员和一些提供软件测试咨询服务的测试达人。 STC2009 (Software Testing Conference, India 2009) : STC是QAI公司组织的软件测试专业会议,每年在印度召开,不少全世界的测试达人都会参加,包括Michael Bolton,Pradeep Soundararajan, Shrini Kulkarni 等。今年,会议还特别请来了微软公司的Tanuj Vohra,他是负责VSTS中所有测试工具的项目经理总监,之前他在IBM负责负责Rational Robot,Test Management and Rational Purify等测试工具。 STAR East 2009(Software Testing Analysis&Review):  STAR East也是测试达人常去的会议,今年会议James Bach(ET测试之父)和James Whittaker都去了,由于James Whiitaker最近出了一本关于探索性测试(Exploratory Software Testing)的书,但是没有得到James Bach的认可,他们还在博客上有一番激烈的讨论。明年的STAR East2010,微软公司负责测试优秀实践的Alan Pages将会作为嘉宾演讲。 GTAC2009 (Google Test Automation Conference,2009):这是Google每年一度的软件测试大会,今年是在瑞士的苏黎世张开,会议的重点的网络应用程序的测试,特别是性能测试,另外在测试工具方面也有很多热门的讨论。 2) 软件测试的热点 毫无疑问,Exploratory Testing 是这一年最热门的测试方法了,其概念在诸多的软件测试会议中被推广,同时出版了几本相关的书,例如《Exploratory Software testing》,目前来说,Exploratory Testing作为一种方法,有一部分的理论支持,但是如何结合实践(或者说如何更好的运用到实践当中,因为大家其实自觉不自觉都在使用者这种方法),却还在摸索当中。我觉得,随着这个概念的推广,更多的测试管理人员熟悉并且掌握了这种方法,这种方法会渐渐成为测试的一些基本理念。其实,Exploratory Testing的流行也反映了现代软件开发的变化性正在加剧,需要更多的考虑软件本身的变化性和项目进度的不可控性。 测试工具的集成和整合…


开发和测试人员的比例

 开发和测试人员的比例是项目管理中重要的一个部分,通常以下的因素会决定最后比例。这种比例没有统一、简单的结论:好或不好,更多的是整个团队的默契程度和最后产品是否成功。 1)公司的文化(Company Culture) 每个公司都有自己的文化,公司通常喜欢利用自己以往成功经验,来指导新项目的开发。例如,一个公司以前是按照3:1的比例进行配置,产品获得成功了,那么他们在下一版本,或则其他产品,也容易按照这个比例进行。因为,大家习惯了这种比例,包括测试人员和开发人员,这些员工习惯了在这种比例下的进行工作分工,当这种比例有重大变化的时候,在初期,开发和测试人员往往会不知所措,不知道如何界他们的工作责任。在微软,开发测试比例通常在1:1~ 3:1左右(Link),而在很多互联网公司,在创业的时候通常没有专职的测试人员,在公司成功之后,也会演习这种很高的开发测试比例,例如Google这种比例会达到7:1,甚至更高。 2) 软件产品性质和市场需求(Business Needs) 软件产品的性质也影响着这个比例。对于企业计费软件,工程控制软件,这些对于产品质量有严格的要求,测试人员比会多一些。对于一些UI集中的软件,比如网络游戏,测试人员的数量也相对较多。有些互联网企业,为了快速提供新功能,而开发一些对于一些原型性质的功能,有时候会标志为Beta,通常这些项目的测试人员通常较少。 3) 开发、测试团队的组成(Team) 在一个项目中,开发和测试人员的经验也会影响着比例的安排。总体来说,软件测试为了达到所需要的质量,需要做一系列的工作任务,有些任务需要开发人员做(例如设计和代码编写),有些需要测试人员做(例如测试计划),除了这些需要较多专业的背景的任务外,其他的很多任务(例如测试用例的实现,测试工具的编写..)实际上既可以由测试人员做,也可以由开发人员做。这种灵活的任务分配往往需要开发团队有较强的开发经验,否则会影响任务的完成。 在很多测试博客中也有开发/测试比例的讨论,例如 Google V.S Microsoft Dev Test Ratio(james_whittaker),  Test to Developer ratios(Alan Page)  


情景驱动的测试方法(Context-Driven School)

                               By  Cheno 情景驱动的测试方法是Cem Kaner和James Bach提出来的,指出了软件开发的复杂性以及不可预测性,因此在这情景下,测试人员需要积极发挥主观能动性,而不是墨守成规的遵守一些通用的规定和流程。总之,这是一种为以人为本的测试方法论,强调主观能动性,而不是固定的流程和方法。 情景驱动测试(Context-Driven School)的7个基本原则(http://www.context-driven-testing.com/) 1)任何实践的价值都依赖于情景(Context)2)好的实践只作用在特定的情景下,没有通用的最佳实践3)在任何项目的环境下,共同协作的人是最重要的部分4)项目的进展常常是不可预测的5)软件产品实际上是一个解决方案。如果问题没有被解决,产品也不可能工作6)好的软件测试是一个非常挑战性,需要智力的过程7)只有经历过项目整个过程,通过决策力和技能,我们才能在正确的时间做正确的事情来测试我们的产品 举个例子,考虑2个项目 1)个飞行控制软件,“正确行为”意味着高技术含量和数学科学。它必须服从FAA(联邦航空局)的规定。做或者不做任何事情在20年内都可能成为法律诉讼的证据。开发人员共同营造着一种谨慎,精确,可重复性和反复检查每个人工作的工作氛围。 2)另外一个项目是开发一个用于互联网上的字处理软件,“正确的行为”是引导微软Word的大量用户使用这款软件。没有航空法规的约束,但需要考虑软件发布时间:从现在起20个月,项目结束时,它可能成功,可能失败。开发人员不可能依照第一个项目的工作风格,因为这种风格将不利于项目的开展。 情景驱动的测试人员总是尽力选择自己的方式来测试不同软件,而不是总是应用所谓的“最佳实践”,不同的环境下,选择的实践活动总是不一样的。 情景驱动的测试方法与敏捷测试(Agile Testing)对比: 1) 敏捷测试强调单元测试的重要性,情景驱动的测试方法却强调在不同的环境下选择不同测试方法,包括如果开发人员的单元测试用例很多或则很少情况下。2) 敏捷开发强调迭代的软件开发周期,情景驱动的测试方法却适合不同类型的软件开发周期,当然,它不是很适合瀑布型模式。 情景驱动的测试方法与探索式测试(Exploratory Testing)方法对比: 1)探索式测试来源于手工测试方法,主要强调测试人员学习软件的过程。情景驱动的测试方法覆盖更多的内容。2) 探索式测试是和脚本化测试(Scripted Testing)相对的,适用于时间紧,少文档的环境下。   我喜欢软件测试,喜欢复杂的软件测试,喜欢主动的进行测试,这正是情景驱动测试方法所适用的。