<返回列表

新闻分类

资讯动态
软件开发测试驱动开发(TDD)是一种更改传统软件开发过程的开发方法,即先设计程序,然后执行编码和测试工作。 TDD采用一种小的增量开发方法:首先编写一个测试,然后编写实际的程序代码以通过该测试,然后再改进代码。这种方法的结果是可以在几秒钟内执行大量(通常是数千个)自动化测试。测试人员需要注意,这些高效的自动化单元测试消除了大多数手动测试的执行。结果,我们需要重新考虑是否有必要在TDD团队中保留测试人员的角色。从表面上看,无论是否采用TDD,“测试人员”在团队中都是至关重要的角色,但实际情况要复杂得多。现在让我们看看这些复杂性在何处显现:如果计划开始尝试TDD,那么建议您不要尝试将老式的QA和功能测试人员混在一起。如果您已经成功实现了TDD,那么拥有一支专门从事测试的团队成员仍然很有意义。能够成功实现TDD的测试人员与传统的功能测试人员之间的区别在于,前者具有更扎实的技术背景。 QA的兴衰在关于ldquo的话题中,TDD已死?肯特贝克(KB),马丁·福勒(MF)和戴维·海涅迈尔·汉森(DHH)对质量保证和测试进行了激烈的讨论。他们指出了专职测试人员历史的三个发展阶段:堆叠式QA:通常是指功能失调的QA部门,该部门充满了大量功能测试员。放弃质量检查:对让程序员负责测试以及在开发过程中放弃测试人员抱有过度自信。现状:仍然需要在项目中引入适当的质量保证(甚至功能)。现在,在1990年代流行的堆叠质量检查的做法似乎已经过时了,许多IT组织已经解散了其质量检查部门,并为各个敏捷团队分配了测试人员。但是,在许多敏捷团队中,这些测试人员正在继续其早期的手动测试任务。自20年前以来,许多组织仍在为功能失常的测试方法而苦苦挣扎。老式QA方法的功能失调是因为该方法依赖于大量的功能测试人员。这些测试人员是手动测试方面的专家,但对技术技能知之甚少。测试人员的专业水平决定了他们擅长于功能测试。但是,老式的质量检查部门更倾向于(同时出于商业利益)让这些测试人员执行“原型”并检查功能。 Ldquo,检查的主要特征是该测试可以完全自动化(Bach and Bolton 2013)。这意味着“检查”功能可以由程序员来完成。至于测试人员还是程序员应该执行功能,请检查一下,这种选择似乎很随意,但事实并非如此:无论是查找错误,隔离,报告,跟踪还是提出修复建议,测试人员都会花费更多时间(Kaner 2001)。 Ld“测试”的功能由测试人员手动检查,这使旧式质量检查效率很低。一旦团队开发了“ ldquo”,就不要测试您自己的代码,将其交给QA来执行此概念,并且测试工作将无法正常工作(在此对话中KB和DHH的观点)。这种方法的发展在一定程度上会导致效率的持续下降。随着更多测试人员的投入,错误的数量将继续增加。 (39,BetterTesting-WorseQuality39,Hendrickson,2001年)放弃QA是对手动测试此功能障碍的一种自然反应。敏捷团队中的测试人员之所以未将本文标题命名为“ ldquo”,是因为在某些情况下放弃QA的做法不可行。例如,尽管您的敏捷团队实施了Scrum框架,但它没有执行任何自动化部门。测试,或者团队正在为某些商用现货或技术(COTS)开发软件。如果团队中没有职能测试人员,则必须实施TDD做法或任何其他可以生成自动化单元测试的方法。大多数情况下,选择TDD意味着您必须改变程序员的技能和习惯,并且经常需要改变他们的态度和自我意识。达到不容易鉴于以上几点,TDD本身并不容易:ldquo,掌握传统代码,正确隔离单元测试和集成测试非常困难(Shore2007)。根据评估,当程序员改用TDD练习时,前几个月的生产率将大大下降。此外,练习TDD的新手经常需要训练他们的手几个星期甚至几个月(Larman,Vodde 2008)。根据我的经验,老式的程序员和测试人员之间经常共生。老派程序员不喜欢单元测试。只要项目中有测试人员,他们便会四处游荡。而且,老式测试人员不愿意学习技术知识,只要他们找到足够的错误供程序员使用,他们还选择处理事情。老派的程序员和测试人员希望避免进行任何更改。因此,我认为,如果程序员已经实施了TDD练习,那么在团队中放置一个功能测试人员是一个坏主意。我在多年的经验中已经观察到了这种反模式:如果您打算采用TDD或开发人员进行其他测试的做法,那么仅由于功能测试人员出现在团队中,它就会让您尝试将其浪费掉。因此,如果您打算实施TDD,我的建议是从团队中删除功能测试人员的角色!但是实际上,在实施TDD的过程中,仍然需要在团队中保留一定的质量保证。这些变化可能会让您感到惊讶。在上述有关TDD和质量检查的讨论中,David Heinemeier Hansson说:ldquo,也许您已经通过了所有测试,但是也许没有找到真正的问题。一旦进入实际的应用程序流程,用户将以您意想不到的方式使用您的应用程序。 FMartin Fowler非常同意David的观点,但是在同一对话中,KentBeck的措词似乎更为谨慎。但是他也同意,在质量保证方面,“事物发展”已经达到了另一个极端。如果您无法预见所有可能性,那么从外部获得一些反馈就非常有意义。测试TDD团队中的测试和团队组成。在以上讨论的后面,我们已经意识到,在TDD的实现中,除了在编程过程中创建的测试之外,执行某些其他形式的测试仍然有意义。敏捷测试的概念在《 ldquo》,《敏捷测试》(Crispin,Gregory 2009)等书中有详细描述。但是似乎仍然需要“ ldquo”来实现敏捷测试。测试人员,即专业从事测试的员工,似乎仍然对此表示怀疑。 Google仍然有数百名测试人员,而Facebook几乎没有测试人员职位。普通的普通公司有不同的考虑因素。他们必须确保员工具有开发和维护各种应用程序并确保有效分工的工具和概念知识。让我们实际分析一下在Java环境中引入测试人员的含义。 Java支持Java的TDD工具包括JUnit和某种模拟测试框架。普通开发人员可以掌握这些工具。但是,JUnit框架不仅支持在Java环境中TDD的应用,而且还代表了测试中的第二项创新:它不仅支持自动化的单元测试,而且还支持各种其他测试的自动化。 UnitJUnit当前还支持运行:通过JAX-RS进行的集成测试,自动接受测试,基于SeleniumWebdriver的UI测试以及支持各种数据集的参数化测试。这些测试可以与持续集成(CI)解决方案集成。除了这些测试工具之外,还出现了许多其他工具和框架。可以说,普通开发人员很难掌握普通现代化项目中使用的所有工具。概念知识是创建高质量应用程序的基础。为了实现较高的可维护性,开发人员需要了解代码的干净程度,并且掌握此知识需要多年的经验。如果我们想精通这一领域,那么我们可以学习设计模式,线程和性能的原理。准确,可维护和高性能的代码很重要,但是它们不能保证应用程序的可靠性。为了弥补这种不足,开发人员还需要了解安全性。要创建吸引用户的应用,开发人员需要取消站立UX。后来,为了设计一种有效的方法来保证上述特性,开发人员还需要熟悉测试知识。建部门的划分是建立IT部门时的另一个重要考虑因素。在团队的专业组成中,我们可以选择聘请来自各个领域的专家,例如由安全专家,UX设计人员和测试人员组成的团队,但这样就没有编码员了,结果是团队无法产生任何实际的东西。相反,我们也可以与通才组成整个团队,但这意味着除非他们都是天才,否则整个团队必须在学习上花费更多的时间。这样的团队也不会有很高的产出。因此,我们得出结论,有必要在开发团队中引入一些可专利性。我们不能指望每个开发人员不仅拥有所有工具,还拥有干净的代码,UX,安全性和测试方面的专家。另一方面,可以引入团队的专家人数应有所限制。由于我们必须引入一定程度的专业知识,因此设置测试专家更有意义:对于开发人员,如果他们让他们选择,那么大多数人将不会探索除单元测试之外的内容,甚至让很多人不愿意进行任何测试工作。这就是为什么许多开发人员不喜欢甚至讨厌测试的原因。如果您要在这种环境下转变为敏捷测试实践,则需要有一位对测试充满热情并愿意实施它的专家。与执行TDD相似,上述过程还需要其他人的指导,并向团队展示其工作结果。如果测试专家创建了服务的测试集并可以从IDE中执行它,那么程序员很可能会使用它。不仅如此,如果开发人员感到测试的用处,那么他们将开始扩展其功能并以可维护的方式实现它。一旦测试通过,程序员将愿意继续测试。但是以我的经验来看,仅程序员就无法感觉到测试的好处。 TDD:在质量检查的兴衰总结部分中具有扎实技术背景的测试人员,我已经说过,在使手动检查自动化的TDD环境中,对缺乏技术知识的传统测试人员的需求已大大减少。稍后在JUnit和TDD的介绍中,我们看到开发人员创建了许多测试工具,而缺乏技术知识的测试人员将无法使用这些工具。现在,我们可以负责任地说,在TDD环境中,我们需要一种新型的测试仪,并且他们需要具有更扎实的技术背景。至于他的日常活动包括什么,我们必须考虑实施TDD的环境。对于敏捷测试,TDD实现了自动化金字塔的底层(Cohn 2009)和测试象限的第一象限(Marick 2003和Crispin 2009)。为了更清楚地了解效果,让我们考虑以下测试方案:表单的输入框可以接受整数,数字必须在指定的范围内,并且需要后端验证。我们可以在此处建立16个功能测试用例:{x |边界,边界-1,边界+ 1,十进制,语言环境,Z,0,null,ldquo,,ldquo,ldquo ,, abc,UTF-8,2 ^ 31-1,2 ^ 31,-2 ^ 31,- 2 ^ 31-1},但这些基本单元测试仅属于测试象限的第一象限(通过面向技术的测试指南开发)。在TDD实践中,上述测试用例将被自动化,并且测试人员不应(见上文)执行这些测试用例。通常,他应该验证输入字段的存在和肯定的用例(测试象限2,通过面向业务的测试指导进行开发)。尽管可以用一些记录和回放工具来完成此任务,但是这种解决方案缺乏可维护性。一种更有效的技术解决方案是(通过干净的代码)编写SeleniumWebdriver代码,并使其在整个团队共享的IDE中可执行。象限2中的其他测试技术包括用户故事测试,并且这些测试也可以自动化。 ldquo,作为InfoQ的用户,我希望能够登录到系统以下载某些特殊内容。这种行为可以暴露为REST调用等,并通过自动测试执行。为了在GUI层进行此简单测试,可能有人会选择使用外部工具(例如SoapUi)。但是,使此测试作为JUnit中的集成测试(ldquo,LogInIT.java)运行会更加有效。其他(未经许可)团队成员可以直接运行和维护测试,而无需学习使用该工具。在自动检查了基本功能之后,我们到达了第三象限(通过面向业务的测试来评估产品):团队具有开始探索性测试的先决条件。 David Heinemeier Hansson在上述对话中说,用户将以您从未想到的方式使用您的应用程序。其他系统也是如此。这时,此方法称为紧急行为。由于您不知道会发生什么,因此可以在此处介绍探索性测试(Hendrickson,2013年)。探索性测试(ET)依赖于小的迭代:执行测试,学习应用程序并为此设计新的测试。该测试方法最初是由非常易于访问的材料TestHeuristicsCheatsheet((Hendrickson2006))启发而来的,但这并不意味着仅执行其中的内容就意味着您已经完成了探索性测试。探索性测试的真正价值在于它的迭代性质和知识的使用。例如:HeuristicsCheatSheet中提到的,在Web测试中,您可以对url执行各种操作(例如更改或删除某些参数)。尝试编写相关脚本或不做准备就直接执行它们是不切实际的。如果要改善这种行为,我们可以先进行几次迭代以了解应用程序如何使用这些参数,然后提出(设计)相关的测试,然后再开始测试(执行)。毫无疑问,如果可以正确使用http协议的知识,将为测试的设计带来极大的便利。探索性测试中的常见做法是在IDE中运行应用程序,监视应用程序服务器日志,打开数据库并监视网络请求。显然,您可以看到一些未在GUI中显示的错误。通过这种方式,我通常会发现这些问题:大量的网络错误和请求,日志污染,意外的持续行为,大量/效率低下的数据库查询,安全风险,可用性错误等等。这并不意味着一旦应用了TDD,所有测试工作都将变为技术性或由工具驱动。仍然存在一些与人类相关的非常重要的测试(Ambler 2003-2014)或与UX相关的测试。这些测试的技术性较低,但这并不意味着不需要深入的知识。以上表明,TDD改变了测试人员的角色,而无需进行手动功能测试(例如检查)。尽管他还有很多工作要做,但他负责的功能测试应该已经自动化。并且,如果他能够掌握更多的技术,工具或其他知识,则他的(探索性)测试工作可能会变得更有效率,但是这种知识通常并不容易掌握。那么,TDD团队中的测试人员应该掌握哪些技术知识?基本上,以下陈述是毫无疑问的:敏捷测试人员需要具备良好的技术知识,并了解如何与他人合作进行自动化测试并变得有经验。探索性测试人员(Crispin,Gregory,2009年)对TDD团队同样有意义。但是我相信对于已经开始实践TDD的敏捷团队和尚未开始实践TDD的敏捷团队,他们对工作的要求也有所不同。对于尚未开始TDD的团队,敏捷测试人员可能被迫使用开发人员未使用的某些测试工作,或执行大量手动测试。在TDD团队中,测试人员更有可能在IDE中工作。这时,此角色的技术要求变为:掌握至少一种编程语言(以便他们可以读写测试)。了解命令行和脚本知识(包括服务器和本地计算机)。有数据库经验(无需GUI即可检查持久性)。结束语本文引用了KentBeck,Martin Fowler和David Heinemeier Hansson之间的对话,这也是激发我写这篇文章的动机。如果您对测试感兴趣,则应听取有关ldquo的信息,并将代码扔给QA和ldquo。为了对此问题进行彻底的分析,我首先描述了老式的功能测试方法。结果不经过功能检查f思考。这种方法弊大于利。这不是我的想象,但是有很强的迹象表明,无论是否采用“敏捷”实践,许多组织仍在以这种方式进行测试。接下来,我指出了为什么不建议将TDD开发人员与老式功能测试人员结合使用。在团队中,我对在TDD团队中设置测试人员的角色持保留态度,并对其进行了修改,以包括一些对团队中的测试充满热情的成员。至于测试人员所需的技能,我认为在TDD流程中不需要进行老式的功能检查。 TDD团队中仍有测试人员的位置,但是他们的测试工作需要更多的专业技术知识。收获如果您是仍在进行手动检查的测试人员,则应考虑使用TDD或其他可以使手动检查自动化的解决方案。如果您还没有上面提到的技术知识,那么该是将您的知识水平提高到该水平并从测试工作中获得更多乐趣的时候了!本书“ MoreAgileTesting”(CrispinGregory2015)应该具有全面介绍的知识,因此我强烈推荐这本书给希望继续进行测试工作的读者。为了掌握这些知识,我建议您具有正规的学习知识,它可以使您更好地理解主题,并加快学习速度,同时也为您提供证明您具有该知识的机会。如果您是团队负责人或经理,并对测试问题感到沮丧,则可能应该考虑如何实施更高级的测试解决方案。您需要在团队中找到既可以实施解决方案,又热衷于测试的人员。实际上,程序员是测试人员吗? (ProgrammersasTesters?)JanetGregory在文章(Gregory2011)中表示,她倾向于认为测试人员应该具有技术背景,但是如果他们认为测试人员作为程序员的角色只是垫脚石,那么就不要雇用他们作为测试人员。这是可以理解的,如果测试人员不热衷于测试,他们将无法很好地实施测试象限或探索性测试。相反,如果测试人员没有必要的技能,那么他就无法自动化测试,并且即使在探索性测试中也无法完全有效。换句话说,技能和热情是实施敏捷测试所必需的。
扫描二维码关注我们
确 认