软件测试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)相对的,适用于时间紧,少文档的环境下。   我喜欢软件测试,喜欢复杂的软件测试,喜欢主动的进行测试,这正是情景驱动测试方法所适用的。


软件测试的艺术

                By Cheno     最近读了《软件测试的艺术》(The art of software testing),书是三十多年前(1979)写的,为了与时俱进,前几年(2004)被翻新了一下,增加了一些新的测试方法例如(eXtreme testing,Web testing),成为第二版。      书写的非常简洁,没有太多的冗余,结构非常清晰,内容非常全面,这可能是这本书成为经典软件测试书籍的主要原因;由于书是30年前写的,而且作者的拥有的主要的集成电路中的软件测试的背景,对真正的现代商业软件测试并未涉足太深(那时Microsoft和Oracle刚刚成立没有几年,还没有什么大型的应用软件产品),因此这本书忽视了用户在软件测试中所起的作用。总体来说,这是一本经典的书籍,可以放在书架中作为常阅参考书籍。      阅读这本书不需要太多的技术背景,任何人都能在读这本书中受益。第一章就是一个非常经典测试问题,用于检测你的测试技能,帮助你更好的理解测试用例(Test Case)。第二章给出了测试的定义以及一些好的原则,应该说这些原则在以后的软件测试发展中起着重要作用。例如“开发人员应该避免自己进行测试”,”测试是一个非常需要创造力和智力的任务”,这些原则都体现在微软建立测试组织的重要原则。第三章给出了细致的代码检查的具体步骤,甚至包括检查点的列表。第六章是我最喜欢的章节,它列出了系统测试中几乎所有的方面,可以作为设计系统级测试用例的重要参考。      作为一本经典的软件测试教材,却很少提到软件用户对于测试的影响,这也是此书最大的缺憾了。此书对软件测试活动的定义为“带着发现错误的目的,执行被测软件”,其实不然,软件的Bugs数量是不可预测的,最好的测试活动应该是最大程度满足用户对软件质量的要求。在第四章,软件测试用例设计中,也缺少对于用户需求的考虑,此书更多的是从数据流角度分析问题。对于Internet应用软件,虽然第二版增加的第九章提到了相关的内容,但是所设计的深度和可用性却是大大不如其它章节。      这本书像一本软件测试的一本字典,可以帮助着很多软件测试的初学者,也可以作为资深软件测试人员的参考手册。


谈谈软件测试的氛围

 By Cheno  软件测试项目是否成功很大程度取决于整个团队中对质量控制的理解,以及测试气氛的形成。一个合适的测试氛围帮组整个团队朝着解决问题的方向前进。不合适的软件测试氛围,会导致很多问题,例如过多的纠缠于指标(代码覆盖率,自动化率等),相互推托责任等。很多因素影响整个项目组的测试气氛。以下就是几个我觉得非常重要的。  1)测试组的组织结构不同的公司、项目都有不同的测试组织结构,有的扁平一些,有的不严格区分开发与测试人员。这些差异性对项目的测试都是有直接的影响。举例来说,微软比较典型的测试组织为SDET->Test Lead->Test Mgr->Test Director,然后PM/Dev/Test组织再统一汇报到一个大老板。(详见 HWTSaM)这种组织结构优点是,测试组织独立性较好,测试经验容易得到分享。另外也有一些组织,Test Lead/Dev Lead/PM Lead 直接汇报给Group Manager。这种结构的灵活性强,适合快节奏的项目,以及Agile的开发模式。  2)测试人员的不同背景(Diversity)测试不仅仅需要很多创新和新鲜的想法,同时也往往需要丰富的经验去开展有效的测试活动。所以,一个好的测试团队,我理解应该是多元化的背景。举例来说,当测试一个应用软件时,一个有美工背景的测试人员必定会关注软件的界面的美观和合理性。一个有安全背景的人,必定会更多考虑软件的可靠和安全。这些不同的背景的人,在一起才能更多程度提高测试的覆盖率。这些不同背景的测试人员可以相互学习,共同促进。  3) 管理人员的领导力和风格一个测试组的氛围,很大程度受到测试管理人员的影响。管理层处理质量问题的方式,也直接影响执行层的工作。质量管理大师朱兰曾经总结一个80/20规律,他认为80%的质量问题是由于管理人员管理不当造成的,而真正由于基础执行导致的质量问题只有20%。管理人员对软件质量的理解,以及传递给执行层的信息,都直接关系到测试的氛围。这里,我想强调的是,管理人员不仅仅包括测试的管理人员,还包括开发的管理人员以及项目经理等。Adam Goucher在他的博客中也提到了对质量影响最大的是项目经理,而非测试或则开发人员。 4) 对于共同目标的认可在实际当中,很多测试人员将质量作为唯一的目标,开发人员将完成功能/解决Bug作为唯一目标,项目经理将产品的新功能作为唯一目标。但是从另外一个角度来看,其实满足客户的需求才是三个领域(开发,测试,项目经理)共同的目标,因此三个领域如何快速合作、如何以共同目标为重也对测试的气氛也有很大影响。有时候,这个共同目标会和各个领域的目标有所冲突,因此如何快速有效解决这些冲突是非常需要智力的过程,同时也依赖很多经验。 其实,软件测试的氛围也受很多其他的因素影响,例如测试人员和开发人员的比例,沟通等等。这里列出的只是我直接想到的几点而已。希望大家都能享受一个好的测试气氛。


软件测试的常阅博客

BJ Rolison (I.M.Testy)   http://blogs.msdn.com/imtestyBJ是微软负责EE工作的Test Architecture,也是HWTSaM的作者。他的文章非常有条理,看起来也比较容易,其中的数据也非常丰富,是我喜欢的风格。 Alan Page  http://blogs.msdn.com/alanpa/  Alan是微软负责EE工作的Director,是HWTSaM的主要作者,他的博客是了解微软测试非常好的一个窗口。最近几年,他不限于测试技术的推广,他更多的考虑是测试管理,以及测试氛围/文化的形成,以及对于测试的影响。我很同意他的一句话“95%的UI自动化测试都是浪费时间”详情。他的博客文章比较随意,有时也不知道他在唠叨些什么,但不时却有很多精彩的观点。 Google Test Blog http://googletesting.blogspot.com这是Google官方的测试博客,信息量很少,除了每年一次的Google Automation Test Conference之外,文章较少。今年6月,James Whittaker离开微软,加入Google后,才到这里增加不少好文章。 James Bach的博客  http://www.satisfice.com/blog/  James是一个软件测试的资深人士,90年代曾在Apple和Boland公司做过测试管理工作,后来在其他一些公司负责测试流程和质量管理,2000年自己创办了satisfice测试咨询公司,提供软件质量保证相关的咨询和培训. 他和Cem Kaner撰写了很多Explorary Testing相关的文章和书籍,并且提出了Context-Driven-Testing,这些方法论很适合现在的Agile Testing的特点。 Adam Goucher的博客  http://adam.goucher.ca/ 一个多产高质的测试写作专家,基本上每个月都有10多篇关于测试的文章,有时候一天写了多篇,真是非常佩服他的写作能力。他的思想很有深度,对软件测试各个方面都有全面的理解,他阅读了几乎所有新出的测试书籍,并且些了与其相关的评论。这些评论通常非常尖锐。比如说,HWTSaM的评论,他的评论就比较中肯。对James Whittalkes的 Exploratory Testing评论 却是嗤之以鼻。  中文的博客,就看看 Cheno的博客吧 http://blogs.msdn.com/cheno


GUI自动化测试的反思

  参加过不同类型的GUI测试项目,其中包括Java SWING, Web Page, Flash, WinForm, Excel Addin等。总结起来,有以下几点值得反思的。 1)通常GUI自动化测试的ROI是非常低的。这些GUI项目大多都经常改变界面,甚至每几个月都需要更改界面,这使得自动化测试用例管理和维护变得非常复杂。GUI自动化最大的弊病在于:它发现Bug的可能性很小,在这些的GUI项目中,通过自动化用例发现的Bug屈指可数,99% 失败的用例都是由于环境或则测试用例本身的原因导致的,而不是发现任何产品Bug。当然,不同项目有不同的特性,Brain Marick有一篇全面关于评估是否自动化测试的文章,可以帮助作出决定。 Alan Page是微软的第一个测试架构师(Test Architect,2001),现在负责微软测试的EE工作。他最著名一句话就是“95%的GUI自动化测试工作都是浪费时间”,他本来写的99%,但是为了表示他并非反对GUI自动化测试,他把这个数字改成了95%。 2)GUI自动化测试可以提高测试人员的士气。有些测试人员不愿意单单做手工测试,他们需要一些挑战,自动化测试是最好的任务。对于自动化测试,测试人员总是可以根据自己的能力,完成自动测试用例的开发和部署。提高测试人员的士气,比这些自动化测试本身更加有意义。所以,在一定程度上引入自动化测试,是对项目组有好处的。 3) GUI自动化测试无法代替手动测试,无法模拟用户的行为。对于GUI测试,我相信手工测试仍然是最重要的测试方法,测试人员在测试GUI软件过程中,有不同操作方法和不同的次序,所有这些变化是一个巨大的组合,无法通过自动化测试完成,很多情况下,也没有必要通过自动化完成。测试人员在手工操作软件过程中,每一步骤都通过思考来验证当前状态的正确性,而这些复杂的思考无法简单快速的转成自动化用例的验证部分。 4) GUI自动化测试的进度往往是无法按时完成的。很多测试人员在制定GUI自动化测试的初期,往往过于乐观,希望通过自动化覆盖尽可能多的测试用例。但是,在项目执行的后期,他们发现需要忙于手工测试,另外产品也不稳定,无法顺利完成既定的自动化测试用例,总有很多客观的理由无法完成最初的计划。通常这个时候,他们会改变计划,减少自动化测试用例的数量,而将自动化测试用例仅仅用于基本测试(BVT,Build Verificaition Test)。这些计划的改变,某种意义来说,也是测试资源的浪费。 进行GUI自动化测试并非难事,但是如何利用自动化测试来进行高效的GUI测试工作是需要丰富的经验。