全国服务热线:
0592-5794349
当前位置:首页> 新闻中心

软件开发测试驱动程序开发

* 来源: * 作者: * 发表时间: 2019-11-19 12:57:01 * 浏览: 2
软件开发测试驱动开发(TDD)是一种开发方法,它通过首先设计程序,然后进行编码和测试来改变传统的软件开发过程。 TDD采用较小的增量方法进行开发:首先编写测试,然后编写实际的程序代码以通过测试,然后改进代码。这种方法的结果是可以在几秒钟内执行大量(通常多达数千个)自动测试。测试人员需要意识到,这些高效的自动化单元测试消除了大多数手动测试的执行。因此,我们需要重新考虑是否有必要继续保留TDD团队中测试人员的角色。从表面上看,无论是否使用TDD,测试人员都是团队不可或缺的一部分,但实际情况要复杂得多。现在,让我们看看这些复杂性在哪里得到体现:如果您计划开始尝试TDD,那么建议您不要尝试将团队中的旧质量检查人员和功能测试人员相匹配。如果您已经成功实施了TDD,那么有一个专门从事测试的团队成员就很有意义。 TDD团队中成功的测试人员与传统的功能测试人员之间的区别在于,前者具有更扎实的技术背景。 QA的兴衰在关于ldquo的讨论中,TDD已死,KentBeck(KB),Martin Fowler(MF)和David Heinemeier Hansson(DHH)对QA和测试进行了激烈的讨论。他们指出了全职测试人员历史上的三个发展阶段:堆积式质量检查:通常是指功能失调的质量检查部门,那里充斥着大量的功能测试员。放弃质量检查:对让程序员负责测试的责任以及在开发过程中放弃测试人员的信心太大。现状:仍然需要在项目中引入适当的质量保证(甚至功能)。流行于1990年代的QA的做法现在似乎已经过时了,许多IT组织已经解散了他们的QA部门,并将测试人员分配给各个敏捷团队。但是,在许多敏捷团队中,这些测试人员将继续其早期的手动测试任务。许多组织仍在遭受20年前功能失调的测试方法的折磨。老式的质量检查方法功能不佳,因为它依赖于大量的功能测试人员。这些测试人员都是手动测试方面的专家,但对技术技能知之甚少。测试人员的专业性决定了他们擅长于测试功能。但是,老式的质量检查部门(也出于商业利益)更倾向于让这些测试人员检查其功能。 “检查的主要特征是该测试是全自动的(Bach and Bolton 2013)。这意味着“检查”功能可以由程序员来完成。至于测试人员还是程序员应该执行该功能,请检查一下,这个选择似乎是任意的,但事实并非如此:测试人员将花费更多的时间来查找错误,隔离,报告,跟踪或提出修复建议。 (Kaner 2001)。手动测试仪“”,对功能的检查使旧的QA变得非常低效。一旦团队开发了“ ldquo”,就不要测试您自己的代码并将其扔给QA来执行此操作,并且测试将无法正常工作(在此对话中KB和DHH的观点)。当这种方法发展到一定程度时,它将导致效率的持续下降。随着更多测试人员的投入,错误的数量将增加。 (39,BetterTesting-WorseQuality39,Hendrickson,2001年)放弃QA是对手动测试此功能障碍的一种自然反应。之所以没有将本文标题命名为“ ldquo”,是敏捷团队中的测试人员,因为在某些情况下放弃QA是不可行的,例如您的敏捷团队实现了Scrum框架,但没有执行任何自动化单元测试,或团队正在为某些商用现货或技术(COTS)进行软件开发。如果团队中没有功能测试人员,则必须实施TDD实践或任何其他可以生成自动化单元测试的方法。在大多数情况下,选择TDD意味着您必须更改程序员的技能和习惯,并且经常需要更改他们的态度和自我意识。要达到这些点并不容易,并且TDD本身也不能得到推广:“ ldquo,很难掌握传统代码,适当隔离单元测试,并集成测试(Shore2007)。根据评估,当程序员转向TDD实践时,在最初的几个月中生产率将急剧下降。不仅如此,TDD的新手通常还必须动手培训数周甚至数月(Larman,Vodde2008)。以我的经验,老式的程序员和测试人员之间经常共生。老派程序员不喜欢单元测试,只要项目中有测试人员,他们就会设法摆脱它。老派的测试人员不愿意学习技术知识。只要他们找到足够的bug供程序员使用,他们还选择处理它们。老派的程序员和测试人员希望避免进行任何更改。因此,我认为,如果程序员已经开始实施TDD做法,那么在团队中放置一个功能测试人员是一个坏主意。我已经在多年的经验中观察到了这种反模式:如果您打算采用TDD或其他经过开发人员测试的实践,那么仅仅因为团队中有功能测试人员,这会使您付出很多努力。因此,如果您打算实施TDD,我的建议是从团队中删除功能测试人员的角色!但是实际上,在实施TDD的过程中,仍然需要在团队中保留一定的QA,这是因为某些更改可能是意料之外的。在上述有关TDD和质量检查的讨论中,David Heinemeier Hansson说:ldquo,也许您已经通过了所有测试,但也许没有找到真正的问题。在实际的申请过程中,用户将以您意想不到的方式使用您的应用。马丁·福勒(Martin Fowler)同意戴维(David)的观点,但在同一次谈话中,肯特贝克(KentBeck)的措辞更为谨慎。但他也同意,就质量保证而言,事物的发展趋向于另一极端。如果您无法预见所有可能性,那么从外部获得一些反馈就非常有意义。 TDD团队中的测试和团队组成经过上述对话,我们已经意识到,在TDD的实现中,除了在编程过程中创建的测试之外,执行其他形式的测试仍然有意义。敏捷测试的概念在《 ldquo》,《敏捷测试》(Crispin,Gregory 2009)等书中有详细描述。但是,是否仍然有必要实施敏捷测试,即测试人员,即专门从事测试的员工,人们似乎在争论这一点。 Google仍然有数百名测试人员,而Facebook几乎没有测试人员职位。普通公司有不同的考虑因素,它们必须确保员工拥有开发和维护应用程序并确保有效分工的工具和概念。让我们实际分析一下将测试人员引入Java环境的含义。启用Java的TDD工具包括JUnit和普通开发人员可以掌握的某种模拟测试框架。但是,JUnit框架不仅支持在Java环境中使用TDD,而且还展示了测试的第二项创新:它不仅支持自动化的单元测试,而且还可以自动化其他各种测试。 JUnit当前支持运行:通过JAX-RS进行集成测试,自动验收测试,基于SeleniumWebdriver的UI测试以及支持各种数据集的参数测试。这些测试可以与持续集成(CI)解决方案集成。除了这些测试工具之外,还出现了许多其他工具和框架。可以说,对于一般的开发人员来说,要掌握一个普通现代化项目中使用的所有工具非常困难。概念知识是创建高质量应用程序的基础。为了获得高度的可维护性,开发人员需要了解代码的简洁性,并且掌握这些知识需要多年的经验。如果我们想精通这一领域的知识,我们还可以学习设计模式,线程和性能的原理。准确,可维护和高性能的代码很重要,但是它们不能保证应用程序是可信赖的。为了弥补这种不足,开发人员还需要了解安全性。为了创建吸引用户的应用程序,开发人员需要了解UX。后来,为了设计一种有效的方法来确保上述特征,开发人员还需要熟悉测试知识。设置IT部门时,工作分工是要考虑的另一个重要方面。在团队的专业组成中,我们可以选择各个领域的专家团队,例如安全专家,UX设计人员和测试人员,但没有编码器职位。结果是团队无法产生任何实际的成果。相反,我们也可以由多面手组成整个团队,但这意味着除非他们是天才,否则整个团队必须花大量的时间进行学习。这样的团队不会有很高的产出。因此,我们的结论是,有必要在开发团队中引入一些可专利性。我们不能期望每个开发人员不仅精通所有工具,而且精通干净的代码,UX,安全性和测试方面的专家。另一方面,团队中引入的专家人数也应受到限制。由于我们必须引入一定程度的专业知识,因此设置测试专家更有意义:对于开发人员而言,如果允许他们选择,大多数人将不会在单元测试之外探索内容,甚至很多人都不愿意完全不做任何测试工作。这就是为什么许多开发人员不喜欢甚至讨厌测试的原因。如果要在这种环境下尝试敏捷测试实践,则需要组建一个对测试充满热情并愿意实施的专家。与实施TDD相似,上述过程还需要其他人的指导,并向团队展示其工作结果。如果测试专家为服务创建测试集并可以从IDE中执行它,则程序员可能会使用它。不仅如此,如果开发人员感到测试的用处,他们将开始扩展其功能并以可维护的方式实施它们。一旦测试通过,程序员将愿意继续测试。但是以我的经验来看,仅程序员一个人就无法感受到测试的好处。 TDD:具有扎实的技术背景的测试人员在QA兴衰的摘要部分中,我曾说过,在实现手动检查自动化的TDD环境中,对缺乏技术知识的传统测试人员的需求已大大增加。减少。后来,在JUnit和TDD的引入中,我们看到开发人员创建了许多测试工具,而缺乏技术知识的测试人员将无法使用这些工具。现在,我们可以负责任地说,在TDD环境中,我们需要一种新型的测试仪,该测试仪需要更扎实的技术背景。至于他的日常活动中所包括的内容,有必要考虑实施TDD的环境。对于敏捷测试,TDD实现了自动金字塔的底层(Cohn 2009)和测试象限的第一象限(Marick 2003和Crispin 2009)。为了更清楚地了解效果,让我们考虑一下这种测试场景:表单的输入框可以接受必须在指定边界内的整数,并由后端进行验证。在这里,我们可以创建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中执行。象限2中的其他测试技术包括用户故事的测试,该测试也可以自动化。 “作为InfoQ的用户,我希望能够登录系统以下载一些特殊内容。这种行为可以暴露为REST调用,并可以通过自动测试执行。为了在GUI级别进行此简单测试,可能有人会选择使用外部工具(例如SoapUi)。但是,将此测试作为JUnit中的集成测试(ldquo,LogInIT.java)运行会更有效。其他(未经许可)团队成员可以直接运行和维护测试ut必须学习该工具。当基本功能实现自动化时,我们到达了第三象限(通过面向业务的测试来评估产品):团队具有开始探索性测试的先决条件。 DavidHeinemeierHansson在上述对话中说,用户将以您意想不到的方式使用您的应用。对于其他系统也是如此,在这种情况下,此方法称为紧急行为。由于您不知道应该预期的行为,因此可以在此处进行探索性测试(Hendrickson,2013年)。探索性测试(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中工作。此时,该角色的技术要求变为:掌握至少一种编程语言(以便您可以读写测试)。了解命令行和脚本(服务器和本地计算机)。有数据库经验(用于检查没有GUI的持久性)。结论本文引用了KentBeck,Martin Fowler和David Heinemeier Hansson之间的对话,这正是促使我写这篇文章的原因。如果您对测试感兴趣,则应该听他们的“代码”,将代码扔给质量检查和“质量检查”,老式的质量检查方法不像质量检查和其他视图那样坦率直接。为了对此问题进行彻底的分析,我首先描述了一种老式的功能测试方法,该方法导致功能检查不加思索,并且这种方法造成的损害大于其价值。这不是我的错,但有充分的迹象表明,仍然有许多组织以这种方式进行测试,无论它们是否采用dquo,敏捷实践。接下来,我指出了为什么不建议将TDD开发人员与“老式”功能测试器结合使用。在团队组成部分中,我对在TDD团队中设置测试员的角色并保留其修改以包括一些对团队中的测试充满热情的成员持保留态度。至于测试人员所需的技能,我认为在TDD流程中不需要进行老式的功能检查。 TDD团队中仍然有测试人员的位置,但是他们的测试需要更专业的技术知识。收获如果您是仍在进行手动检查的测试人员,则应考虑使用TDD或其他可自动执行手动检查的解决方案。如果您不具备上述技术知识,那么该是将您的知识提高到这一水平并从测试中获得更多乐趣的时候了!详细描述了《 MoreAgileTesting》(CrispinGregory2015)一书,我强烈建议这本书给希望继续进行测试工作的读者。为了掌握这些知识,我建议您具有正规的学习知识,它可以使您更好地理解主题,并加快学习速度,同时也使您有机会证明自己拥有这些知识。如果您是团队负责人或经理,并对测试问题感到沮丧,则可能应该考虑如何实施更高级的测试解决方案。您需要在团队中找到一个可以在对测试充满热情的同时实现解决方案的人员。其实,程序员的测试人员? JanetGregory(Gregory2011)表示,她希望测试人员具有技术背景,但如果他们仅使用测试人员的程序员身份,则可以。垫脚石,然后不要雇用他们作为测试人员。这是可以理解的。如果测试人员不热衷于测试,他们将无法实现测试象限或探索性测试。相反,如果测试人员没有必要的技能,他将无法使测试自动化,并且即使在探索性测试中也不会完全有效。换句话说,技能和热情是实施敏捷测试所必需的。