敏捷开发 测试前移_测试驱动开发 测试前移 - CSDN
  • 在回答“究竟什么是敏捷测试”之前,我先问一个问题:你了解敏捷开发吗? 如果不了解,那先需要去了解敏捷,例如看看我之前写过的一篇文章Scrum不再是Scrum,Scrum还是Scrum,可以有助于理解敏捷。理解敏捷,更重要...

     

    7年前(2013 年),在 InfoQ 发表了相同标题的文章,但这篇文章是全新而作。在回答“究竟什么是敏捷测试”之前,我先问一个问题:你了解敏捷开发吗?

    如果不了解,那先需要去了解敏捷,例如看看我之前写过的一篇文章 Scrum不再是Scrum,Scrum还是Scrum,可以有助于理解敏捷。理解敏捷,更重要的是去agilemanifesto.org仔细阅读著名的敏捷宣言和 12 项敏捷开发原则。

    带着思考,来听听我下面给你讲的案例,在听的过程中,你可以去审视这个案例,来判断哪些符合敏捷价值观,哪些又违反了敏捷开发原则,最后我们一起来分析案例,并回答“究竟什么是敏捷测试”。

     

    *** 从传统测试转型到敏捷测试的案例 ***

    这个案例来自一家国内的公司,这家公司的产品主要是基于 Android 系统的智能终端。故事发生在 6 年前,即 2013 年,这家公司的软件研发部门在这一年开始了一系列面向敏捷测试的尝试

     

    先给大家介绍一下案例背景,公司的软件研发部门下属有四个开发部门和一个庞大的测试部门,其中,一个负责各种研发工具开发的部门也隶属于测试部门。开发人员和测试人员比例几乎是 1:1,开发部门的职责是按照负责的功能模块划分的,而测试部门负责软件系统级别的所有测试,包括功能测试、性能测试、安全性测试、可靠性测试、兼容性测试等。当时采用的是传统的瀑布式开发模式,即 V 模型,代码编写和产品测试被明确地分成了两个阶段。

     

    1. 持续集成的尝试

    这里所用到的工具包括:分布式的代码版本控制工具 Git + 代码审查工具 Gerrit + 持续集成工具 Jenkins + 自研的基于 Monkey Runner 的自动化测试框架。基于 Git + Gerrit + Jenkins,开发部门已经实现了代码的自动构建。

    希望达到的目标是代码提交后完成自动构建、自动部署和自动化测试,并且自动生成测试报告。在实施过程中,工具链没有问题,自动构建和自动部署也没有问题,问题就出在自动化测试上。

    一个产品的手工测试用例大概是 1000 个,但是能转化为自动化脚本并且放在集成环境里执行的用例,在很长时间内只有 100 多个,只实现了版本验证,即我们通常所说的“冒烟测试”。这意味着,当开发人员提交代码,触发的自动化测试达到的覆盖率非常有限,即使这个集成环境能够支持持续验证,所有人都觉得很鸡肋。

     

    1. 测试前移和组织架构的尝试

    当时对测试前移的定义是在软件编码阶段就进行测试,而不是等到开发结束以后才开始测试。简单的说就是边开发边测试,期望通过这个缩短产品开发周期

     

    (1)第一阶段

    开发部门按照 Scrum Team 进行划分,按照 3:1 的比例招聘了测试工程师。一开始没想明白他们到底需要什么样的测试人员,所以招来的基本上都是手工测试,看不懂代码的居多。

     

    他们在 Scrum Team 里的主要工作包括:手工测试;一遍遍按照开发的要求复现 bug;给开发人员打杂,比如给终端更新一个新版本、找找开发想要验证的硬件型号,等等。而在项目早期,产品硬件不到位或者软件集成到一起不工作时,手工测试则没法进行。

     

    (2)第二阶段

    领导们本来希望通过敏捷模式可以减少测试人员的数量,但事与愿违,测试部门专门负责系统测试的人员并没有减少,反而在开发部门内部又多了几十名测试。原因在于两拨人马用的测试方式都差不多,人多了,无非体现在报的 bug 多了,测试部门看重的是需求的覆盖率,人自然减不下来。

     

    所以,在一次改组中,领导宣布所有的测试人员都转到测试部门,要求测试部门减掉相应数量的测试外包。Scrum Team 可以向测试部门要求按 3:1 的比例配备测试人员。测试部门能够了解 Scrum Team 的测试范围,减少了重复测试。改组之后,人数倒是减下来了,但是仍然以手工测试为主,因为组织架构的变更,开发和测试经常因为谁对开发阶段的测试说了算而争论不休,开发和测试变得更加泾渭分明,关系更紧张了。

     

     

    (3)第三阶段

    经过一段时间的运行,觉得这样不行,不符合敏捷团队的特征,又决定把负责开发阶段测试的人员转到开发部门。良好的转变是:每个 Scrum Team 开始由一名资深测试工程师担任 Test Owner,负责制定测试策略和测试计划,以及协调开发测试与系统测试之间的安排。开发部门也开始对开发阶段的测试工程师进行开发能力的培养。

     

    1. 单元测试的尝试

    一开始单元测试的覆盖率几乎是 0,开发人员只管写代码和修复测试人员提交的缺陷。由于持续集成和测试前移的不成功,大家认为开发部门应该要求开发人员做单元测试,以代码覆盖率衡量单元测试的结果。开发也答应做,但是整整一年未见成效,原因是:忙,没有单元测试的经验和技能

     

    1. 测试能力更新的尝试

    测试部门意识到自动化的重要性,但是部门只有 5% 的工程师负责自动化测试。经过层层申请,公司同意采取末位淘汰制替换 10% 的手工测试工程师。通过内部转岗、外部招聘,以及员工培训的多种方式,在一年之后自动化测试工程师的比例终于达到了 25%。团队开始搭建统一的自动化测试框架。自动化测试在 API 和 UI 测试的覆盖率终于看到明显提高,但是在整体需求覆盖率上也没有超过 30%,而且单元测试的缺失依然是硬伤,没有开发人员的参与,测试总在 UI 层折腾,当然是事倍功半。

     

    从这个例子可以看出,这家公司的研发部门从传统测试转型到敏捷测试的过程中,并不清楚什么是真正的敏捷测试,而是摸着石头过河,不断尝试,每走一步都很艰难,而且走了不少弯路,最后还没有达到敏捷测试的彼岸,更不用说,产品的质量和测试的效率得到显著的提升。

     

     

    *** 什么是敏捷测试?***

    那究竟什么是敏捷测试呢?可以肯定的是,“敏捷测试”既不是一种测试方法,也不是一种测试方式,而是为了适应敏捷开发而特别设计的一套完整的软件测试解决方案。这个解决方案应该能够支持持续交付,涵盖所需的、正确的价值观、思维方式、测试流程、一系列优秀的测试实践和更合适的测试环境、自动化测试框架和工具。敏捷测试可以采用目前已有的各种测试方式、方法,以及传统测试相比侧重有所不同,但主要的差别还是价值观、测试思维方式、流程和实践等。

    敏捷测试应该具有“敏捷宣言”所倡导的价值观,为此我们可以按照“敏捷宣言”的格式,写出如下的“敏捷测试宣言”:

     

    敏捷测试强调“与开发协作”、“自动化测试”、“客户思维”和“动态的测试策略调整”更具有价值。

    那我们回过头来,再看看上面的案例,至少第 1、2 条,他们没做到:测试人员没有得到足够的重视和尊重,开发和测试协作不够,而是:

    • 有一段时间还存在独立的测试部门,“开发和测试变得更加泾渭分明,关系更紧张了”

    • “没有开发人员的参与,测试总在 UI 层折腾,当然是事倍功半”

    • “触发的自动化测试达到的覆盖率非常有限”

    • ……

    在转型初期,没有加强相关测试人员的培训,甚至都不知道敏捷模式对测试人员的要求,招进来的测试人员不合格。在执行过程中,缺乏测试策略,没有强调从客户的需求出发和动态地调整测试策略。

    敏捷开发还有 12 项原则,上面案例中的团队有没有一条一条地、针对性地去对照着做?虽然敏捷开发 12 项原则似乎没有谈到测试,但测试是整个软件研发的一部分,自然也要遵守这些原则,适应敏捷开发的基本要求,例如:

    • 如何支撑或协助“持续不断地、尽早交付有价值的软件”?

    • 如何拥抱变化——“欣然面对需求变化,即使在开发后期也一样”

    • ……

    只有遵守这些原则,才能获得顺应敏捷开发的正确姿势,也只有采用敏捷开发的优秀实践,如测试驱动开发,并和开发紧密协作,测试才不会成为敏捷开发的“绊脚石”。

    基于敏捷开发的 12 项原则,我制定了下列 8 项敏捷测试原则:

     

    这些原则,在《高效敏捷测试》专栏的后续内容都有详细讲解。

     

    参考:

    展开全文
  • 测试驱动开发 测试前移 如果您需要软件并且需要快速,那么测试驱动开发(TDD)可能是解决方案。 TDD致力于快速将软件从计算机推向市场,是当今顶级软件开发和软件测试公司正在使用的最有效方法之一。 什么是测试...

    测试驱动开发 测试前移


    如果您需要软件并且需要快速,那么测试驱动开发(TDD)可能是解决方案。 TDD致力于快速将软件从计算机推向市场,是当今顶级软件开发和软件测试公司正在使用的最有效方法之一。

    什么是测试驱动开发?

    敏捷性和速度是增强测试驱动的开发运动的两个概念。 但是什么是TDD,流程如何运作?

    测试驱动的开发是一个软件开发过程,其重点是在开发人员编写实际代码之前为软件测试编写测试 目的是使开发人员专注于代码的用途并确保其功能。

    测试驱动开发

    运作方式如下:

    1. 每个测试驱动的开发周期都始于编写测试以查看软件是否可以运行。 该测试基于软件的功能,要求和规格。
    2. 接下来,开发人员运行测试以确保其适当性和有效性。 在此阶段,测试应该失败,这意味着它可以工作并且不会显示出假阳性结果。
    3. 一旦建立了足够的测试,开发人员便会继续编写代码。 在此阶段,代码可能还不够完善,但必须通过测试才能继续前进。 这就是为什么此测试阶段必不可少的原因。
    4. 一旦一段代码通过测试,就可以进行重构。 这是代码清理阶段,其中删除重复项,正确命名所有代码元素(对象,类,模块,变量,方法等),并添加所有必需的新功能。
    5. 完成此过程后,开发人员可以重新启动该周期以进行编码改进,添加新功能或修复任何编码错误。

    简而言之,测试驱动的开发关注于代码是否完成了应做的工作。 如果有效,请转到下一个阶段,否则请重写。 概念就是这么简单。

    TDD是如何发明的?

    现代TDD的原型是在1960年代发明的。 该技术的“重新发现”归功于一位肯特·贝克(Kent Beck)的美国软件工程师。 贝克还是敏捷软件开发的创始人之一,也是《 敏捷宣言》的签署人。

    早在2002年,贝克(Beck)就在他的《测试驱动开发:范例》一书中向世界介绍了TDD的概念。

    虽然一般来说不是一个新主意,但是Beck声称TDD是“有效的干净代码”,着眼于模型的简单性和消除了传统软件开发方法附带的代码不起作用的担忧。

    TDD与传统测试之间的差异

    让我们比较一下。

    传统测试 测试驱动的开发
    最后测试的方法,其中开发人员创建代码,但保留测试直到开发过程结束。 一种测试优先的方法,其中开发人员或测试自动化工程师首先创建测试,然后开发人员编写代码来满足测试的要求。
    专注于代码正确性,但可能无法检测到所有编码缺陷。 然后,测试将进行重构,直到代码通过测试为止;直到代码满足功能为止,然后继续进行测试,并减少系统中的错误数量。
    线性过程。
    (设计代码测试)
    循环过程。
    (测试代码重构)

    测试驱动开发的好处

    测试驱动开发的支持者可以在快速开发代码时提高其速度,敏捷性和功能。 但是,这些并不是唯一的优点。 开发系统还:

    • 保持代码简单,有用且切合实际,使所有相关人员的过程变得更加轻松。
    • 有助于查明由于严格测试而导致的错误和其他代码缺陷,因此开发人员可以准确地知道问题出在哪里。 这样可以减少(但不会否定)最终测试时间。
    • 允许开发人员查看实际的代码,采用用户的观点并对最终用户产生同情。 因此,代码可以更好地反映用户的需求。
    • 巩固项目的目的和目标,从抽象的想法到精确的目标,鼓励开发人员专注于他们真正需要做的事情。

    测试驱动开发的缺点

    测试驱动开发


    但是,使用测试驱动的开发方法存在一些缺点。 让我们来看看:

    • 尽管声称TDD比传统编码过程快,但最初该过程可能很慢。 但是,随着时间的流逝, 生产率显着提高
    • 开发人员可能过于专注于一两个编码问题,而看不到全局。 在尝试修复错误时,这一点尤其重要。
    • 开发足够的初始测试(尤其是对于创新软件)存在一些问题,因为测试开发人员应该几乎完全知道他们想要从代码中获得什么。
    • 这种方法不允许在初始设计中进行很多更改,否则,这将增加TDD流程的执行时间。

    您应该在软件开发中使用测试驱动的方法吗?

    与所有业务决策一样,选择采用测试驱动的开发方法是特定于公司的决策。 如果您正在考虑使用测试驱动的方法,则应首先确保TDD适合您的业务。

    首先,这将取决于您团队的需求和经验。 由于TDD是一种快节奏的敏捷方法,因此您需要确保它们已准备好应对挑战。 另外,您可以求助于质量保证咨询以帮助您采用这种方法。

    也就是说,测试驱动的开发可能是将您的产品尽快从代码行转换为可用于市场的产品的绝佳方法。

    翻译自: https://www.javacodegeeks.com/2019/03/essentials-test-driven-development.html

    测试驱动开发 测试前移

    展开全文
  • 测试驱动开发 测试前移 敏捷从业人员谈论测试驱动开发 (TDD),所以许多关心代码质量和可操作性的开发人员也是如此。 我曾几何时,不久前设法阅读了有关TDD的文章。 据我了解,TDD的关键是: 编写测试,但失败 ...

    测试驱动开发 测试前移

    敏捷从业人员谈论测试驱动开发 (TDD),所以许多关心代码质量和可操作性的开发人员也是如此。 我曾几何时,不久前设法阅读了有关TDD的文章。 据我了解,TDD的关键是:
    1. 编写测试,但失败
    2. 代码,使测试成功
    3. 自动化测试
    4. 重构代码以提高质量
    5. 重复

    很容易理解。 恼火的开发人员大喊:“开发人员在编写测试吗? 您如何期望我们开发和测试并及时完成功能?”。 毕竟,所有开发人员都不想做无聊的测试工作。 我从事开发人员大约两年了,在最初的日子里,有时我会做出这种React。 但是随着时间的流逝,我已经开始理解软件开发的症结所在。 这次我想到尝试TDD。

    我的工作涉及使用Java EE Web框架通过UI在db中连接数据库中的数据,这是典型的Web应用程序工作。

    让我解释一下在采用TDD之前的测试策略:

    1. 编写完整的代码,包括-PLSQL过程,调用PLSQL过程的Java代码,用于UI绑定的Java代码以及JSP页面本身。
    2. 手动测试db层和UI层代码的功能。 它涉及导航到页面,然后测试各种操作。 在这种情况下,UI问题和后端代码问题都会出现。
    3. 正如我将进一步研究UI一样,我将在代码中发现一些bug,否则编写一个selenium测试以自动测试一些用例。

    通过上述3个步骤,我花了很多时间-

    1. 等待后端代码编译,然后重新启动服务器以使UI反映更改。 即使它只是一个简单的1词/ 1语句更改,我也不得不等待大约5分钟,有时甚至是8分钟。 当我等待重新启动时,我会失去对其他任务的关注,因此需要一段时间才能回到主要任务。
    2. 尝试调试并找出异常/错误是由于UI代码问题还是后端代码问题引起的。
    3. 等待页面加载并浏览页面到正确的页面。

    好的,那是史前时代。 现在正走向现代。 我以为我无法完成TDD的工作,这是因为我编写了后端和UI代码耦合不良的代码。 我想不出一种方法来独立测试我的后端代码,然后转到UI代码,然后通过Selenium测试对其进行测试。 抛开这些概念,我试了一下。 我知道我与实际的TDD距离不是很近,但是感觉有点接近。

    1. 我对如何实现逻辑,创建基本实现并使其成功编译有一个很明确的想法。
    2. 创建了一些数据填充测试,以获取用于测试的数据类型。
    3. 创建了JUnits以测试基本功能。 主要是通过Java API正确执行PLSQL过程。
    4. 更新了JUnits以添加更多测试以测试所需的实际功能,并更新了代码以实现这些功能。
    5. 重构代码以消除难闻的气味,然后运行JUnits以确保没有任何损坏。

    我感到兴奋的原因,以及我认为这是双赢的策略:

    • 与API的创建者相比,我开始更多地考虑API的用户。 这使我无法添加可以解决问题但难以测试的黑客。 与以前编写的代码相比,这极大​​地改善了代码结构。
    • 没有服务器重新启动,每次重新启动都不会浪费〜8分钟,也不会浪费浏览页面的时间。 我只需要编辑代码,运行Junit并查看测试即可确定命运。 这对于我编写的后端代码更有用。
    • 我专注于代码测试周期,因此不会失去重点。
    • 我看到测试显示绿色栏表示成就感。
    • 创建具有良好单元测试的代码以测试后端功能的可能性,这也有助于更轻松地重构代码。

    现在,我只需要为UI和后端编写粘合代码,并通过Selenium测试来测试粘合代码。

    任何人开始使用TDD时都有类似的经历吗?

    参考: 我在测试驱动开发中的第一步-我们的JCG合作伙伴 Mohamed Sanaulla在“ 体验无限”博客上提出的双赢策略


    翻译自: https://www.javacodegeeks.com/2012/05/test-driven-development-win-win.html

    测试驱动开发 测试前移

    展开全文
  • 测试驱动开发 测试前移 在我以前的测试驱动开发(TDD)和突变测试系列中 ,我演示了在构建解决方案时依靠示例的好处。 这就引出一个问题:“依靠例子”是什么意思? 在该系列中,我描述了构建解决方案以确定白天...

    测试驱动开发 测试前移

    在我以前的测试驱动开发(TDD)和突变测试系列中 ,我演示了在构建解决方案时依靠示例的好处。 这就引出一个问题:“依靠例子”是什么意思?

    在该系列中,我描述了构建解决方案以确定白天还是晚上时的期望之一。 我提供了一个示例,其中列出了我认为属于白天类别的特定时段。 我创建了一个名为dayHourDateTime变量,并给它指定了2019年8月8日,7小时0分钟0秒的特定值。

    我的逻辑(或推理方式)是:“当通知系统时间是2019年8月8日上午7点时,我希望系统将执行必要的计算并返回值Daylight 。”

    有了这样一个特定的示例,创建单元测试( Given7amReturnDaylight )非常容易。 然后,我运行测试并观察我的单元测试失败,这为我提供了修复此早期失败的机会。

    迭代就是解决方案

    TDD(以及代理,敏捷性)的一个非常重要的方面是,除非您进行迭代,否则不可能获得可接受的解决方案。 TDD是基于无休止的迭代过程的专业学科。 重要的是要注意,它要求每次迭代必须以微故障开始。 这种微故障只有一个目的:立即征求反馈。 即时的反馈确保我们能够Swift缩小寻求解决方案与获得解决方案之间的差距。

    冲洗,重复,直到我们完全消除差距并提供完全符合期望的解决方案为止(但请记住,期望也必须是微观期望)。

    为什么微?

    这种方法通常感觉很雄心勃勃。 在TDD(和敏捷)中,最好选择一个微小的,几乎是微不足道的挑战,然后通过先失败然后进行迭代直到我们解决这个微不足道的挑战来进行TDD歌舞。 习惯了更丰富,更精通的工程和解决问题的人往往会觉得这样的练习低于他们的能力水平。

    敏捷哲学的基石之一是将问题空间缩小到多个最小的可能表面积。 正如罗伯特·C·马丁(Robert C. Martin)所说:

    “敏捷是关于小型编程团队做小事情的小问题的一个小主意”

    但是,如何制造一系列令人印象深刻的行人,微小的,几乎微不足道的微型胜利,才能使我们达到大规模的解决方案呢?

    在这里,复杂而精巧的系统思维开始发挥作用。 在构建系统时,总是存在以可怕的“整体”结束的风险。 整体是基于紧密耦合原理构建的系统。 整体的任何部分都高度依赖于同一整体的许多其他部分。 这种布置使得整料非常脆弱,不可靠并且难以操作,维护,故障排除和固定。

    避免此陷阱的唯一方法是最小化或更好地完全消除耦合。 与其投入大量的精力来构建将要组装到系统中的精致零件,不如花些谦虚的步伐来构建微型零件。 这些微型零件本身仅具有很小的能力,并且由于这种布置,将不依赖于其他组件。 这将最小化甚至消除任何耦合。

    构建有用的,精致的系统所需的最终结果是由一组通用的,完全独立的组件组成。 每个组件越通用,结果系统将越强大,更具弹性和灵活性。 同样,拥有通用组件的集合使它们能够通过重新配置这些组件而重新用于构建全新的系统。

    考虑由乐高积木制成的玩具城堡。 如果我们从城堡中挑出几乎所有街区并单独进行检查,那么我们将无法在该街区找到任何东西来指定它是用于建造城堡的乐高积木。 积木本身具有足够的通用性,因此适合建造其他设备,例如玩具车,玩具飞机,玩具船等。这就是拥有通用组件的力量。

    TDD是提供通用,独立和自主组件的可靠实践,可以安全地组装大型复杂系统。 与敏捷一样,TDD专注于微活动。 而且由于敏捷基于称为“整个团队”的基本原则,因此在说明业务示例时,此处说明的谦虚方法也很重要。 如果用于构建组件的示例不适当,则将很难满足期望。 因此,期望必须谦虚,这使得得到的例子同样谦虚。

    例如,如果整个团队的成员(请求者)为开发人员提供了期望,并且示例显示为:

    “在处理订单时,请确保对忠实客户的订单或超过一定货币价值的订单或两者都给予适当的折扣。”

    开发人员应认识到此示例过于宏大。 这不是一个卑鄙的期望。 如果可以的话,它还不够细微。 开发人员在编写示例时应始终努力引导请求者更加具体和微观。 矛盾的是,示例越具体,所得到的解决方案就越通用。

    一个更好,更有效的期望和示例将是:

    “订单金额大于$ 100.00的折扣为$ 18.00。”

    要么:

    “已经下三笔订单的客户所下的订单大于$ 100.00的折扣为$ 25.00。”

    这样的微型示例可以轻松地将其转变为自动化的微型期望(阅读:单元测试)。 这样的期望会使我们失败,然后我们会反复努力,直到我们交付解决方案为止。这个解决方案是一个强大的通用组件,知道如何根据整个团队提供的微观示例来计算折扣。

    编写质量单元测试

    仅仅编写单元测试而不关心它们的质量是一个愚蠢的事情。 粗暴地编写单元测试将导致code肿,紧密耦合的代码。 这样的代码易碎,难以推理,而且通常几乎无法修复。

    我们需要为编写质量单元测试制定一些基本规则。 这些基本规则将帮助我们在构建健壮,可靠的解决方案方面Swift取得进展。 最简单的方法是以首字母缩略词FIRST的形式引入助记符,它表示单元测试必须是:

    • F =快速
    • =独立
    • R =可重复
    • S =自验证
    • T =彻底

    快速

    由于单元测试描述了一个微型示例,因此应该期望从实现的代码中进行非常简单的处理。 这意味着每个单元测试都应该非常快地运行。

    独立

    由于单元测试描述了一个微型示例,因此应该描述一个非常简单的过程,该过程不依赖于任何其他单元测试。

    可重复的

    由于单元测试不依赖于任何其他单元测试,因此它必须是完全可重复的。 这意味着每次运行某个单元测试时,它都会产生与上一次运行相同的结果。 单元测试的运行次数和运行顺序都不会影响预期的输出。

    自我验证

    运行单元测试时,测试结果应立即可见。 不应期望开发人员接触其他信息源,以了解其单元测试是失败还是通过。

    彻底

    单元测试应描述微型示例中定义的所有期望。

    结构良好的单元测试

    单元测试是代码。 与任何其他代码一样,单元测试也需要结构良好。 提供草率的,混乱的单元测试是不可接受的。 适用于管理干净的实现代码的规则的所有原理均以相同的力应用于单元测试。

    一种久经考验且久经考验的方法,用于编写可靠的质量代码,是基于称为SOLID的纯净代码原则。 该首字母缩写词可以帮助我们记住五个非常重要的原则:

    • S =单一责任原则
    • O =开闭原理
    • L = Liskov替代原理
    • I =接口隔离原理
    • D =依赖反转原理

    单一责任原则

    每个组件必须仅负责执行一个操作。 这个模因说明了这一原理

    Sign illustrating single-responsibility principle

    抽化粪池的操作必须与注入游泳池分开进行。

    应用于单元测试时,该原理可确保每个单元测试都可以验证一个(也只有一个)预期。 从技术角度来看,这意味着每个单元测试必须有一个且只有一个Assert语句。

    开闭原则

    该原则指出,组件应为扩展打开,但应为任何修改关闭。

    Open-closed principle

    应用于单元测试时,该原理确保我们不会在该单元测试中对现有的单元测试进行任何更改。 相反,我们必须编写一个全新的单元测试来实现更改。

    里斯科夫替代原则

    该原理为确定哪种抽​​象级别适合该解决方案提供了指导。

    Liskov substitution principle

    应用于单元测试时,该原理指导我们避免与依赖于底层计算环境(例如数据库,磁盘,网络等)的依赖项紧密耦合。

    接口隔离原理

    这个原则提醒我们不要夸大API。 当子系统需要协作来完成任务时,它们应该通过接口进行通信。 但是,这些接口一定不要过分膨胀。 如果需要一项新功能,请不要将其添加到已定义的接口中; 而是设计一个全新的界面。

    Interface segregation principle

    应用于单元测试时,消除界面上的膨胀可帮助我们制定更具体的单元测试,从而产生更多通用的组件。

    依赖倒置原则

    该原则指出,我们应该控制我们的依赖关系,而不是控制我们的依赖关系。 如果需要使用另一个组件的服务,而不是负责实例化我们正在构建的组件中的该组件,则必须将其注入到我们的组件中。

    Dependency inversion principle

    应用于单元测试时,该原理有助于将意图与实现分开。 我们必须努力仅注入那些已经足够抽象的依赖项。 该方法对于确保单元测试不与集成测试混在一起很重要。

    测试测试

    最后,即使我们设法制作出符合FIRST原则的结构良好的单元测试,也不能保证我们提供了可靠的解决方案。 TDD最佳实践在构建组件/服务时依赖于事件的正确顺序; 我们总是且总是希望提供对我们期望的描述(在微型示例中提供)。 只有在单元测试中描述了这些期望之后,我们才能继续编写实现代码。 但是,在编写实现代码时,经常会发生两种不良的副作用:

    1. 已实现的代码使单元测试能够通过,但是使用不必要的复杂逻辑以复杂的方式编写它们
    2. 在编写单元测试之后,已实施的代码会被标记

    在第一种情况下,即使所有单元测试均通过,突变测试仍会发现某些突变体仍然存活。 正如我在“ 变异测试”示例中所解释的那样:从脆弱的TDD演变而来 ,这是非常不希望的情况,因为这意味着解决方案不必要地复杂,因此无法维护。

    在第二种情况下,保证所有单元测试都可以通过,但是代码库中很大一部分可能由未在任何地方描述的已实现代码组成。 这意味着我们正在处理神秘的代码。 在最佳情况下,我们可以将该神秘代码视为沉木,然后安全地将其删除。 但是很可能,删除此未描述的,已实现的代码将导致严重的损坏。 而且这种破损表明我们的解决方案设计不良。

    结论

    TDD最佳实践源于久经考验的方法(称为极限编程) (简称XP)。 XP的基石之一是基于三个C

    1. 卡:一张小卡简要说明意图(例如,“查看客户请求”)。
    2. 对话:这张卡成为对话的门票。 整个团队聚在一起讨论“审查客户需求”。 那是什么意思? 我们是否有足够的信息/知识以这种增量方式交付“查看客户请求”功能? 如果没有,我们如何进一步分割这张卡?
    3. 具体的确认示例:包括插入的所有特定值(例如,具体名称,数字值,特定日期,以及与用例有关的其他信息),以及所有期望作为处理输出的值。

    从此类微型示例开始,我们编写了单元测试。 我们观察单元测试失败,然后使它们通过。 同时,我们遵守并尊重最佳软件工程实践: FIRST原则, SOLID原则和突变测试准则(即杀死所有幸存的突变体)。

    这样可以确保我们的组件和服务以内置的可靠质量交付。质量的衡量标准是什么? 简单—变更的成本 如果交付的代码更改成本很高,则质量很差。 高质量的代码结构如此之好,以至于更改既简单又便宜,并且不会招致任何更改管理风险。

    翻译自: https://opensource.com/article/19/10/test-driven-development-best-practices

    测试驱动开发 测试前移

    展开全文
  • 最近CTO组建了一个敏捷开发团队,团队人员包括 PM、设计、开发、测试角色,主要由PM来主导团队走向,因为以前并没有参加过敏捷开发的经验,对敏捷开发做了简单理解后,参考了前人的一些意见,总结出在 敏捷开发模式...
    最近CTO组建了一个敏捷开发团队,团队人员包括  PM、设计、开发、测试角色,主要由PM来主导团队走向,因为以前并没有参加过敏捷开发的经验,对敏捷开发做了简单理解后,参考了前人的一些意见,总结出在
    敏捷开发模式下如何更好的进行测试
     
    首先:意识的转变:
    意识需要从发现Bug转变为预防Bug出现,
    从越多发现Bug转变为越早发现Bug
    测试人员应该及时跟上开发和需求人员的脚步,及时地更新测试用例,并提醒大家需求的变更是不是超过了限度,该控制控制了
     
    测试前期:1.全程参与需求讨论,最早在需求讨论阶段,帮助需求和开发对需求有正确和共同的认识,例如主导更多的用户场景、异常等讨论
         2.测试的用例同样有优先级,针对性编写用例(重点)
         3.对每个迭代所要达到的目标烂熟于心, 说测试是贯彻开发始终的
     
     
     
    测试中: 1.与开发沟通上又直接交流、灵活应对变化,质量控制,什么bug是重要的,什么是可以后期去做,分清bug优先级
                 2.引入能帮助测试更简便的测试工具和方法,如自动化测试,可以帮助测试人员有更多的时间去探索性测试
     
    测试产出:测试用例、测试报告
     
    scrum
    测试团队的主要职责是尽早给出质量反馈,做到风险前移:
    1) 最早在需求讨论阶段,帮助需求和开发对需求有正确和共同的认识,例如主导更多的用户场景、异常等讨论
    2) 用于测试的用例同样有优先级,最高的优先级是“用户使用最多”以及“最容易发生bug”的场景交集
    3) 缩短测试时间,更多使用自动化,例如Cucumber、Fitness、Selenium等的使用
    4) 测试工作的过程和结果可视化(最后有产出结果),方便团队内的沟通
    另外,测试团队需要有一线工作的意识:测试人员需要参加计划、估算、执行、回顾等与产品交付相关的任何环节
     
     
     
    下面是百度、知乎下的各前辈的知识,十分感谢各位大神的经验。
    敏捷开发、测试相关链接(全英文。。。。):http://www.methodsandtools.com/archive/archive.php?id=88、http://www.ambysoft.com/essays/agileTesting.html
    知乎相关链接:https://www.zhihu.com/question/19624692
    目的一定要清晰:
    测试人员也需要对每个迭代所要达到的目标烂熟于心, 说测试是贯彻开发始终的
     
     

    敏捷测试关键成功要素

    1.使用团队整体参与的方法

    2.采用敏捷测试思维(直接交流、灵活应对变化、鼓励尝试新技术方法尝试最简单的方法来满足测试需要。)

    3.自动化回归测试(自动化冒烟测试、自动化单元测试)

    4.提供并获取反馈。

    5.构建核心实践的基础(持续集成、测试环境、管理技术债务、增量工作、编码和测试同一过程)

    6.与客户合作

    7.保持大局观

    敏捷过程中,测试的主要职责应该是对每次迭代的产出物做验证,确保产出物满足产品设计需求,质量合格。
     
    1. .需求的把握。测试要对不断变化的需求都能把握住,以PO(product ower)的标准来要求自己,敏捷的要旨是小步快跑,保证每一步都是对的,这样在团队中就需要有人来保证我们做出来的东西是没有偏离需求的,这个角色只有测试胜任;
     
    2.团队节奏的控制。不知道大家有没有做过敏捷项目,迭代不断的出现延迟,问题单越来越多,大家疲于根据计划加班。这个时候我们可不可以把下个迭代要做的事情暂时先停下来,留一个迭代或者半个迭代来解决问题,重新读下代码,找出那些异味的代码(smelly code)重写一下。找找我们流程中的问题并改进。这个事情也是由测试人员来提出比较合适;


    3.质量控制。
    这当然是测试的传统的工作,找出问题,让开发人员来解决。对于一个tester来说,质量控制Quality Control比质量保证Quality Assurence更重要。在敏捷阶段,不是说发现的所有问题都需要马上让开发人员去改,因为或许这个bug对应的需求还不明确,或许下轮的重构就能自动解决问题,或许当前这个迭代使用的技术解决这个问题代价太大... 总之,这里是比较灵活的,也是比较考验测试人员的经验的,什么问题应该马上解决,什么问题可以讨论。
     
     
    4.测试尽可能去参与集成测试的,只是这个过程对测试来说比较痛苦,需要了解代码,有一定的编码能力。
     
    5.测试产出
    文档,测试分析,问题单,测试需求分析等等。。。 这个也是和产品的形态有关,如果是轻量级的产品完全不需要做很多事情,或者很多事情可以合并来做,产出一份文档或者结果就可以。
     
    6.关于自动化测试
    第一,在敏捷里面测试有一个很重要的产出就是自动化测试有了自动化测试之后测试人员有更多的时间去做探索性的测试并且自动化测试能够给予团队一个很好的反馈你改动了代码之后是否对系统有影响都能及时的反馈出来第二,测试团队对需求的影响测试人员在设计测试用例时就会对用户的场景和预期的行为有一个描述,就会出现一些产品人员考虑不到的情况,这样便可以更加完善需求,提升产品的体验和质量。


     
     
    用例:用例一定要全
     
    1,文档要全,而且要保证质量,不过测试用例例外,看情况而来。
    测试人员应该着眼于关键点,一个全面的测试用例也常常被证明40%以上的用例是徒劳的。根据经验能够判断出哪里是潜在bug、缺陷和主要数据流关键点,针对这些地方写测试用例,方便管理也能够判断数据流阶段性的正确。还有就是TDD在开发过程中的保证,前期的需求讨论,测试人员参与程度应比开发人员更高,而系统架构确定、软件架构确定,都是由开发和测试共同决定,并在开发过程中出现需求变动,也保持软件架构的相对稳定,因为软件架构的改动对于测试人员来讲不单单是改动,很可能是重新来过。
     
    2,这个不管是不是敏捷的,前期都尽量挖掘客户的需求,不留下任何潜在的需求。开发过程中的需求变动,根据经验来说,还没有遇上过需求不变的。这个其实是很无奈的,这是由客户方不够专业引起的,这也确实没有办法,只能是期望变动不是翻天覆地的。
     
    3,开发过程差不多,或者说一样也可以,但敏捷方法对人员上的控制有一些建议,来使人员工作效率更高,交流成本更低。在这方面来讲,敏捷对于人的性格也有要求,不是每个人都适合参加敏捷开发,在搞人这方面上,敏捷只是提出了一些建议,最佳实践还是得根据公司人员和公司内部结构的实际情况来定了。
     
     

    转载于:https://www.cnblogs.com/YouxiYouxi/p/8041985.html

    展开全文
  • 测试驱动开发 测试前移 重要要点 公认的是,我们创建的任何软件都必须经过测试以确保其满足功能要求,但是我们还必须测试非功能性要求,例如安全性,可用性以及(至关重要的)可维护性。 测试驱动开发(TDD)...
  • 从我目前面试的经验看,不管是社招还是校招,有不少人选择测试的原因都是测试门槛低,不会的能很快学会,稍微好点的是因为够不上开发的标准,所以才选择做测试。 在这样的大环境下,导致很多测试人,自己都觉得测试...
  • ThoughtWorks的敏捷测试

    2020-03-13 17:05:03
    我的同事肖然在 《ThoughtWorks的敏捷开发》一文中介绍了ThoughtWorks敏捷开发的全貌,并在其中简单介绍了ThoughtWorks是怎么做质量内建和敏捷测试的。我作为一名加入ThoughtWorks已经7年的QA,想更为详细的介绍一下...
  • 敏捷”在互联网和软件开发领域从涓涓细流逐渐演变为行业潮流,往小了说是改进了开发方法,往大了说是革了瀑布流式的命——把产品开发引向了快速迭代、小步快跑的路线上。我们使用 tapd 写 feature,流转、跟踪任务...
  • 敏捷开发 vs 传统开发

    2020-01-14 17:26:26
    说起敏捷开发,并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。 ...
  • 敏捷开发的流程

    2015-08-31 20:27:22
    随着带的团队做的事情越来越多, 发布的产品也越来越多, 关于软件开发的流程的思考也越来越多.前段时间的高效虚拟自适应团队是在历经困难后磨练出来的方法的总结, 在此基础上,又经过几个版本发布的洗礼,对之前的认识...
  • 根据在线统计数据门户网站Statista数据显示,2018年,超过90%的软件开发采用敏捷开发(Agile Development)方式。那么究竟什么是敏捷开发,它又具有怎样的特点和优势呢? 本期极客专访中,哥白尼有幸采访到了李小波...
  • 转载本文需注明出处:微信公众号EAWorld,违者必究。 引言: 随着敏捷软件研发过程的引入,敏捷测试也开始成为研发团队的重点关注对象...随着普元研发管理体系(iPALM)的不断演进,敏捷开发过程加速了产品...
  • 曾经开过专栏的朋友告诉我:写专栏非常累,要脱一层皮。是啊,每周三篇,差不多两天一篇全新的文章,持之以恒,整整四个月。... 许多测试同学对敏捷测试感到迷茫,有这方面的实际需求; 测试成了...
  • 敏捷测试中的Web测试优秀实践 发表于:2017-8-07 14:51 作者:黄勇 来源:博客 字体:大 中 小 | 上一篇 | 下一篇 | 打印 |我... 说到Web测试的优秀实践,不得不提到敏捷开发流程。不同于瀑布流程,测
  • 本文介绍企业在敏捷和DevOps的逐步转型过程中,测试如何应对挑战,有的放矢进行测试,建立适合产品自身发展阶段、产品特点的敏捷测试能力。 敏捷和DevOps 敏捷和DevOps转型始终是被业务目标和客户需求驱动的。市场...
  • 它是一种软件测试风格,强调测试人员的自由与责任的测试方法,为了持续优化其工作的价值,将测试相关学习、测试设计、测试执行和测试结果分析作为相互支持的活动,在整个项目过程中并行地执行。 探索性测试敏捷中...
  • 很多做测试的朋友问过这样一个问题:“现在敏捷开发模式中,自动化测试那么流行,而且连开发人员都开始做测试了,是不是以后就没有测试人员了?”其实我在这里可以肯定的告诉大家现实并不是这样的。首先我们需要讨论...
  • 本次特别邀请到一淘网测试架构师 @公直_黄利 ,诺基亚敏捷及精益教练 @徐毅-Kaveri 和百度高级测试工程师杨进,请他们谈下各自对QA和测试的理解,内容涉及如何衡量软件测试的有效性,探索式测试敏捷测试,开源对...
  • 测试驱动开发感悟

    2015-05-03 23:34:29
    我们在开发过程中为了保证质量,从中引进了软件测试。它在整个的过程中起到的作用不言而预,但是它也存在一些问题:  1、在软件测试中要保证软件的高质量就必须增加项目的成本,从而需要增加测试人员,延长项目时间...
1 2 3 4 5 ... 20
收藏数 498
精华内容 199
关键字:

敏捷开发 测试前移