软件开发测试驱动的开发

软件开发测试驱动的开发

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