软件开发测试驱动开发

软件开发测试驱动开发

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