上篇我们说到如何从Github上clone出一个JBehave项目，既是为了学习JBehava，也是为了熟悉下Github。 从clone下来的项目看来，基本没什么问题，稍微捋一捋就可以运行，但是就clone下来的代码来看，自己还是遇到一个问题（不知道是代码问题，还是我自己的操作有问题），就是没有办法运行（后面会详说）。 正如上篇所说，构建一个JBehave的应用的5大步骤： Write story Map steps to Java Configure Stories Run Stories View R
本文要阐述的主要有两点，一是介绍自动化测试框架JBehave，二是介绍如何在Github上拉项目，编译成myeclipse环境中的项目，并最终导入Myeclipse中运行。 JBehave是何物？ JBehave是基于BDD框架的开源自动化测试框架。提供Web集成的BDD层扩展。 JBehave特征： JBehave是纯Java实现，可以利用Java丰富的API为己所用； 具有基于文本的story，可以对其进行定义并执行，比较灵活和易扩展； 基于注解（Annotation）的运行配置信息，指定story
几十年来，Java一直是开发应用程序服务器端的首选编程语言。尽管JUnit一直在与开发人员一起帮助他们进行自动化的单元测试，但随着时间的推移和测试行业的发展，特别是伴随着自动化测试的兴起，已经开发了许多基于Java的开源框架，它们在验证和业务逻辑方面与JUnit有所不同。在这里，我将讨论用于使用Selenium WebDriver执行测试自动化的顶级Java测试框架，还将重点介绍这些顶级Java测试框架的优缺点和独到之处。
行为驱动开发（BDD）似乎非常容易。测试以易于阅读的格式编写，允许产品所有者，业务赞助商和开发人员提供反馈。这些测试是团队的有效文档，因此不需要任何要求。这些工具易于使用，可让自动化测试套件。每次测试运行都会生成报告，以记录每个步骤并向您显示测试失败的地方。
大多数测试人员更喜欢Java，因为它具有平台独立性和易于构建任何东西的易用性——从简单的应用程序到复杂的移动应用程序、网站等等。
ScalaTest几乎已经成为Scala语言默认的测试框架，而在JVM平台下，无论是否使用Scala进行开发，我认为仍有尝试ScalaTest的必要。这主要源于它提供了多种表达力超强的测试风格，能够满足各种层次的需求包括单元测试、BDD、验收测试、数据驱动测试。正如ScalaTest的创建者Bill Venners所说： A guiding design principle of ScalaTest is that different people on a team should be able look
Java Code review 一些原则的原因探讨 标签（空格分隔）： 工作笔记 ---- Java Code Review清单 下面列出自己不理解的部分和大家探讨^-^ 整洁性 清单项目 分类 确定应用了代码格式化 格式 使用异常而不是返回码 异常 不要返回Null 异常 安全 清单项目 分类 备注 避免对于一些不寻常行为的过分日志 拒绝服务(Denial of Service) 在任何情况下都释放资源(流，连接等等) 拒绝服务(Denial of Service) 把从不可信对象得到的输出作为输
前言： 已经数月没有来社区了，写博客贵在坚持，一旦松懈了，断掉了，就很难再拾起来。但是每每看到自己博客里的博文的浏览量每天都在增加，都在无形当中给了我继续写博客的动力。最近这两天有听到Jbehave这个名词，上网查了一通，原来是和测试相关的，之前一直做开发，没有做过真正意义上的测试，对于测试的理解更是少之又少。通过这两天的查阅，现将自己的一些理解以及常见概念罗列出来。 正文： Behavior Driven Development，行为驱动开发是一种敏捷软件开发的技术，它鼓励软件项目中的开发者、QA
今日洞见 文章作者来自ThoughtWorks：毛超。 本文所有内容，包括文字、图片和音视频资料，版权均属ThoughtWorks公司所有，任何媒体、网站或个人未经本网协议授权不得转载、链接、转贴或以其他方式复制发布/发表。已经本网协议授权的媒体、网站，在使用时必须注明"内容来源：ThoughtWorks洞见"，并指定原文链接，违者本网将依法追究责任。 1 引言 在Ruby社区中，测试和BDD一直是一个被热议的话题，不管是单元测试，集成测试和功能测试，你总能找到能帮助你的工具，Cucumber就是被广泛
敏捷QA对职业发展的担忧 最近和组内的QA聊起以后的职业发展，发现一个有意思的事情，有说想转BA的，有说想转开发的，有说想转型作PM的，还有想以后往咨询方向发展的。很少有说想在团队里面继续作QA的。Q
第4章 测试策略的实现 4.1 引言 戴明14条之一就是：“停止依赖于大批量检查来保证质量的做法。改进过程，从一开始就将质量内嵌于产品之中。”[9YhQXz]测试是跨职能部门的活动，是整个团队的责任，应该从项目一开始就一直做测试 质量内嵌是指从多个层次（单元、组件和验收）上写自动化测试，并将其作为部署流水线的一部分来执行，即每次应用程序的代码、配置或环境以及运行时所需软件发生变化时，都要执行一次 质量内嵌还意味着，你要不断地改进自动化测试策略 这些测试不仅仅对系统进行功能测试。容量、安全性及其他非功能测试也
整洁的代码 清单项目 分类 使用可以表达实际意图(Intention-Revealing)的名称 有意义的名称 每一个概念只用一个词 有意义的名称 使用方案/问题领域名称 有意义的名称 类应该是比较小的! 类 函数应该是比较小的! 函数 只做一件事 函数 DRY(Don’t Repeat Yourself)原则，(拒绝重复) 函数 用代码来解释自己的做法(译者注：即代码注释) 注释 确定应用了代码格式化 格式 使用异常而不是返回码 异常 不要返回Null 异常 *参考自:http://tech
现在开发软件都讲敏捷开发，何为敏捷开发？敏捷开发是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于"非敏捷"，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。但是现在敏捷开发又好几种方案，如：TDD、BDD、DDD 与 ATDD。
前段时间介绍了Mock基本知识以及市面上常见的Mock工具（Mock工具介绍），今天重点介绍小编在测试过程中使用的Mock工具-Moco。
三. 选择缓解风险的技术 一旦识别出迁移过程中可能存在的风险，我们就可以有的放矢地选择相关技术，制订降低风险的解决方案。 寻找丢失的知识 只有体验过去，才能谋划未来。如果缺乏对遗留系统的足够认识，这
下面的Test Pyramid摘自Martin Fowler的 文章，越高层次产生的用户价值会更高且更慢，越低层次的产生的价值更低且更快，你所写的任何一行单元测试代码对于你的用户来说都是不可见的，他能感知到的只能通过UI来体现。可以看出我们需要很多的单元测试来保证我们的代码质量，这对开发人员来说是有巨大价值的，它能够帮开发人员快速发现且定位问题。
简介 移动APP的UI自动化测试长久以来一直是一个难点，难点在于UI的”变”, 变化导致自动化用例的大量维护。从分层测试的角度，自动化测试应该逐层进行。最大量实现自动化测试的应该是单元测试，最容易实现也最容易在早期发现问题；其次是接口级测试，以验证逻辑为目的进行自动化，由于接口的相对稳定，自动化测试成本相对也可以接受；自动化成本最大的便是UI级自动化测试，然而UI界面是直接反馈给用户的效果展示，适度的尤其是BVT级的自动化测试也是非常必要的。本文通过分析几种自动化框架的异同，使测试人员在选择自动化框架时有所
如果将mock单独翻译过来，其意义为 “虚假、虚设”，因此在软件开发领域，我们也可以将其理解成 “虚假数据”，或者 “真实数据的替身”。
几天前，我发表了文章《Twitter的问题说明再好的软件也会腐化》，文中提到避免软件腐化的三种有效手段，其中之一是持续测试。
作者：赵丽娜 简介 移动 APP 的 UI 自动化测试长久以来一直是一个难点，难点在于UI的”变”, 变化导致自动化用例的大量维护。 从分层测试的角度，自动化测试应该逐层进行。 最大量实现自动化测试的
简介 移动APP的UI自动化测试长久以来一直是一个难点，难点在于UI的”变”, 变化导致自动化用例的大量维护。从分层测试的角度，自动化测试应该逐层进行。最大量实现自动化测试的应该是单元测试，最容易实现也最容易在早期发现问题；其次是接口级测试，以验证逻辑为目的进行自动化，由于接口的相对稳定，自动化测试成本相对也可以接受；自动化成本最大的便是UI级自动化测试，然而UI界面是直接反馈给用户的效果展示，适度的尤其是BVT级的自动化测试也是非常必要的。本文通过分析几种自动化框架的异同，使测试人员在选
mock测试就是在测试过程中，对于某些不容易构造或者不容易获取的对象，用一个虚拟的对象来创建以便测试的测试方法。 在具体的测试过程中，我们经常会碰到需要模拟数据或者接口的情况，因为环境问题或者系统复杂度的问题，我们需要使用 Mock 方式进行数据的模拟。
作为一个自动化测试工具，这些已经足够了。然而，Cucumber的首页清楚地写着“making BDD fun”，即让行为驱动开发充满欢乐。行为驱动开发（BDD）是什么？Cucumber的开发者为什么又要给它扣上这个帽子呢？
相信大部分的人都听说过 BDD，即：行为驱动开发，但并未涉及到它的使用方和项目实战。
BDD，行为驱动开发是 敏捷软件开发 的一种技术，鼓励软件项目的所有成员之间的相互协助
一、摘要 自动化测试可以快速自动完成大量测试用例，节约巨大的人工测试成本；同时它需要拥有专业开发技能的人才能完成开发，且需要大量时间进行维护（在需求经常变化的情况下），所以大部分具有很好开发技能的人员不是很愿意编写自动化用例。但由于软件规模的高速增长，人力资源的逐步稀缺，自动化测试已是势在必行。 对于自动化测试首先需要保证其功能是对客户有价值的和正确可用的。而这一切的基础就是用例要能测试客户的需求，期望，最好能让客户参与到测试用例的开发过程中来或让客户评审测试用例，因此出现了ATDD、BDD等各种理论方法来
测试驱动开发（TDD）相信大家已经很熟悉了，而行为驱动开发（BDD）其实是TDD的一种演化。那什么是BDD，为什么要使用BDD， BDD下的自动化测试该如何做呢？本文将通过简单的例子，向大家展示如何使用Cucumber 描述需求，编写、执行测试用例，并输出测试报告。
一个框架定义了一个 规则，或者说我们可以以系统的方式来达到预期的效果逐步最佳做法。因此，上述测试自动化框架涉及最佳实践，以实现我们的自动化项目的目标。
自动化测试一直是敏捷开发和敏捷测试的重要基石，也是DevOps和CI/CD必不可少的组成部分。由于不同项目的测试需求不同，以及各种不同的限制，导致需要的自动化测试框架和工具也不同。比如很多金融和能源类的企业就倾向于选择收费的企业级自动化测试框架或者工具，而新型互联网企业则倾向于开源免费的自动化测试框架或者工具，或者基于它们进行二次定制开发，或者重新开发适合自己的自动化测试框架、工具或者平台。 我之前写过一篇文章——《自动化测试框架Cucumber和RobotFramework的实战对比》仅仅针对两种自动化测
软件行业正迈向自主、快速、高效的未来。为了跟上这个高速前进的生态系统的步伐，必须加快应用程序的交付时间，但不能以牺牲质量为代价。快速实现质量是必要的，因此质量保证得到了很多关注。为了满足卓越的质量和更快的上市时间的需求，自动化测试将被优先考虑。对于微型、小型和中型企业(SMEs)来说，自动化自身的测试过程是非常必要的，而最关键的方面是选择正确的自动化测试框架。
在上一篇文章中我们花比较大的篇幅介绍了敏捷业务实践中的计划游戏，在这篇文章中我们将介绍介绍生命之环中外围剩下的三个业务实践。
当我们面对一个遗留系统时，常见的问题是没有测试。正如Michael Feathers在Working Effectively with Legacy Code一书中对“遗留代码”的定义。他将其简单归纳为“没有测试的代码”。真是太贴切了！正是因为没有测试，使得我们对遗留代码的任何重构都有些战战兢兢，甚至成为开发人员抵制重构的借口。从收益与成本的比例来看，对于这样的系统，我一贯认为不要盲目进行重构。因为重构的真正适用场景其实是发生在开发期间，而非维护期间。当然，提升自己的重构能力，尤其学会运用IDE提供的自动重构工具，可以在一定程度上保障重构的质量。然而，安全的做法，还是需要为其编写测试。
测试覆盖率和代码覆盖率是衡量代码有效性的最流行方法。这些术语有时会同时出现，因为它们的基本原理相同。但是它们并不是那么一致。很多时候，测试团队和开发团队对这两个术语的使用感到困惑。下面详细讨论代码覆盖率和测试覆盖率之间的区别的原因。
今天我们来谈一谈TDD 和 BDD 两项实践。我们先来说说 TDD，也就是测试驱动开发（Test Drvien Development）。
前言 新技术层出不穷。过去十年时间里，我们经历了许多激动人心的新技术，包括那些新的框架、语言、平台、编程模型等等。这些新技术极大地改善了开发人员的工作环境，缩短了产品和项目的面世时间。然而作为在软件行业第一线工作多年的从业者，我们却不得不面对一个现实，那就是当初采用新技术的乐趣随着项目周期的增长而迅速减少。无论当初的选择多么光鲜，半年、一年之后，只要这个项目依然活跃，业务在扩张——越来越多的功能需要加入，一些公共的问题就会逐渐显露出来。构建过慢，完成新功能让你痛不欲生，团队成员无法很快融入，文档无法及时更新
新技术层出不穷。过去十年时间里，我们经历了许多激动人心的新技术，包括那些新的框架、语言、平台、编程模型等等。这些新技术极大地改善了开发人员的工作环境，缩短了产品和项目的面世时间。然而作为在软件行业第一线工作多年的从业者，我们却不得不面对一个现实，那就是当初采用新技术的乐趣随着项目周期的增长而迅速减少。无论当初的选择多么光鲜，半年、一年之后，只要这个项目依然活跃，业务在扩张——越来越多的功能需要加入，一些公共的问题就会逐渐显露出来。构建过慢，完成新功能让你痛不欲生，团队成员无法很快融入，文档无法及时更新等等。
在实际研发与测试工作中，单元测试是代码走向高质量的必经之路，也是效能优化实践的重要一环。单元是应用的最小可测试部件。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类、超类、抽象类等中的方法。单元测试就是软件开发中对最小单位进行正确性检验的测试工作。
在如今快节奏的软件交付环境下，自动化验收测试是很有必要的。高质量的自动化验收测试能够减少手动测试和bug修复所耗费的时间，从而帮助我们更快地交付有价值的特性。将其与行为驱动开发（Behaviour-Driven Development）方式相结合的话，自动化验收测试还能指导和校验开发工作的开展，帮助团队聚焦于特性的构建，并确保这些特性是真正重要和可运行的。
A curated list of awesome Java frameworks, libraries and software.
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
