情景驱动的测试方法(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作为唯一目标,项目经理将产品的新功能作为唯一目标。但是从另外一个角度来看,其实满足客户的需求才是三个领域(开发,测试,项目经理)共同的目标,因此三个领域如何快速合作、如何以共同目标为重也对测试的气氛也有很大影响。有时候,这个共同目标会和各个领域的目标有所冲突,因此如何快速有效解决这些冲突是非常需要智力的过程,同时也依赖很多经验。 其实,软件测试的氛围也受很多其他的因素影响,例如测试人员和开发人员的比例,沟通等等。这里列出的只是我直接想到的几点而已。希望大家都能享受一个好的测试气氛。