TDD团队中的测试人员(3)

发表于:2016-06-13来源:infoq作者:Maarten Folkers点击数: 标签:测试人员
TDD:具有扎实技术背景的测试人员 在QA的兴衰这一节的总结部分,我曾表示:在实现了对手工检查工作进行自动化的TDD环境中,对于缺乏技术知识的传统测

  TDD:具有扎实技术背景的测试人员

  在QA的兴衰这一节的总结部分,我曾表示:在实现了对手工检查工作进行自动化的TDD环境中,对于缺乏技术知识的传统测试人员的需求已经大大降低了。随后在对JUnit与TDD的介绍中,我们又看到开发者创建了大量的测试工具,而缺乏技术知识的测试人员将无法使用这些工具。

  我们现在可以负责任的说,在TDD环境中,我们需要一种新型的测试人员,他们需要具备更扎实的技术背景。至于他的日常活动包括哪些内容,要考虑到 TDD所实施的环境。对于敏捷测试来说,TDD实现了自动化金字塔(Cohn 2009)的底层,以及测试象限(testing quadrants)的第1象限(Marick 2003及Crispin 2009)。

  为了更清楚地了解其效果,让我们来考虑这个测试场景:某个表单的一个输入框可以接受一个整数,该数字必须在规定的边界之内,并且要进行后端的校验。我们在此处可以建立16种功能性的测试用例:{ x | boundary,boundary-1,boundary+1,decimal, locale,Z,0,null,“”,“ “,abc,UTF-8,2^31-1,2^31, -2^31,-2^31-1},但这些基本的单元测试只属于测试象限中的第1象限(通过面向技术的测试指导开发)。

  而在TDD实践中,以上测试用例将实现自动化,测试人员不应(参照上文)执行这些测试用例。一般来说,他应当对于该输入字段是否存在以及一个正面用例进行校验(测试象限2,通过面向业务的测试指导开发)。虽然可以通过某种录制与播放工具完成该任务,但这种方案缺乏可维护性。更有效的技术方案是(通过整洁的代码)编写Selenium Webdriver代码,并且让它能够在整个团队共用的IDE中执行。

  象限2中的其他测试技术包括用户故事的测试,而这些测试同样可以实现自动化。“ 作为InfoQ的用户,我希望能够登录系统,以下载某些特别的内容 ”这样的行为可以暴露为REST调用等方式,并通过自动化测试执行。对于在GUI层进行的这种简单测试,有人可能会选择使用外部工具(例如 SoapUi)。但更高效的做法是让这个测试能够在JUnit中作为集成测试(“LogInIT.java”)而运行。而其他(没有许可证的)团队成员可以直接运行与维护该测试,并且无需学习该工具的使用。

  当基本功能都实现了自动化检查后,我们就达到了第3象限(通过面向业务的测试来评价产品):团队已具备了开始进行探索性测试的先决条件。 David Heinemeier Hansson在上述对话表示,用户会以你始料未及的方式使用你的应用。这一点对于其他系统也成立,此时这种方式叫做突现行为(emergent behavior)。由于你不知道应该期望怎样的行为,因此此处可引入探索性测试(Hendrickson 2013)。

  探索性测试(ET)依赖于小型的迭代:执行测试、对应用进行学习并为此设计新的测试。这种测试方式最初是受到Test Heuristics Cheat sheet((Hendrickson 2006))这份非常容易获取的资料而启发的,但并不是说只需简单地执行其中的内容就代表你已经实现了探索性测试。探索性测试的真正价值在于它的迭代式特征以及对于知识的运用。

  举例来说:在Heuristics Cheat Sheet中提到,在web测试中可以“对url进行各种操作,(例如变更或删除某些参数)”。如果在没有准备的情况下直接尝试编写相关的脚本或直接执行是没有实用性的。如果要改善这方面的行为,我们可以首先用几个迭代的时间去学习该应用使用这些参数的方式,随后想出(设计)一个相关的测试,最后才开始测试(执行)。毫无疑问,如果能够正确地运用http协议方面的知识,对于该测试的设计将带来极大的便利。

  我在探索性测试中的常用做法是:在IDE中运行应用程序、对应用程序服务器的日志进行监控、打开数据库并对网络请求进行监控。这种方式显然能够看到一些在GUI中不会显示出来的错误。通过这种方式,我通常能够发现这些内容:大量的网络错误与请求、日志污染、非预期的持久行为、大量的/低效的数据库查询、安全性隐患以及使用性的错误等等。

  这并不是说一旦应用了TDD,所有的测试工作就会变得充满技术性,或是由工具所驱动。依然有一些非常重要的测试与人相关(Ambler 2003-2014),或是与UX的测试相关。这些测试所包含的技术性较少,但并不意味着就不需要了解深入的知识。

  以上内容表示,TDD让测试人员的角色发生了变化,而不再需要进行手工功能性测试(例如检查)。虽然他仍有大量的工作需要完成,但他所负责的功能性测试应该已经实现了自动化。而如果他能够掌握更多的技术、工具或其他方面的知识,那么他的手工(探索性)测试工作很可能会变得更为高效,只是这些知识往往并不容易掌握。

原文转自:http://www.infoq.com/cn/articles/testers-TDD-teams