基于BDD的敏捷项目测试实践
基于敏捷开发流程的测试用例设计
基于敏捷开发流程的测试用例设计敏捷开发流程是一种迭代和增量的软件开发方法，它强调在开发过程中持续交付可用软件的能力。
在敏捷开发中，测试用例设计是一个重要的环节，它能够确保开发出的软件具备高质量和稳定性。
本文将介绍基于敏捷开发流程的测试用例设计的重要性、方法和步骤。
我们要了解为什么在敏捷开发中需要测试用例设计。
敏捷开发的目标是快速交付可用软件，并根据用户和市场的反馈进行快速迭代。
测试用例设计可以确保软件在每个迭代周期中的质量，并及早发现和修复潜在的问题。
它帮助开发团队验证软件是否按照预期的规范进行开发，并且可以验证软件是否满足用户需求。
下面，我们将介绍一种基于敏捷开发流程的测试用例设计方法——行为驱动开发（BDD）。
BDD是一种以用户故事和行为为基础的软件开发方法，它强调开发团队与业务方之间的紧密合作。
BDD的核心是用自然语言描述用户需求和行为，并将其转化为可执行的测试用例。
BDD的测试用例设计过程包括以下几个步骤：1. 确定用户故事和行为：开发团队与业务方一起讨论和定义用户故事和行为，确保开发团队对需求有充分的理解。
2. 编写用户故事和行为的描述：用简洁明了的自然语言描述用户故事和行为，确保测试用例易于理解和执行。
3. 根据用户故事和行为编写测试用例：将用户故事和行为转化为可执行的测试用例，包括输入、预期输出和执行过程。
4. 执行测试用例并生成测试报告：执行编写的测试用例，记录测试结果，并生成测试报告。
测试报告可以帮助开发团队评估软件的质量和稳定性。
5. 根据测试结果进行迭代：根据测试结果和用户反馈，开发团队可以优化软件的功能和性能，并更新相应的测试用例。
基于敏捷开发流程的测试用例设计还可以采用其他方法，例如验收测试驱动开发（ATDD）和测试驱动开发（TDD）。
这些方法都强调开发团队与业务方的紧密合作，并将需求和行为转化为可执行的测试用例。
总结起来，基于敏捷开发流程的测试用例设计是确保软件质量和稳定性的重要环节。
Kiwi和BDD的测试思想技术分享
Kiwi和BDD的测试思想技术分享XCTest是基于OCUnit的传统测试框架，在书写性和可读性上都不太好。
在测试用例太多的时候，由于各个测试方法是割裂的，想在某个很长的测试文件中找到特定的某个测试并搞明白这个测试是在做什么并不是很容易的事情。
所有的测试都是由断言完成的，而很多时候断言的意义并不是特别的明确，对于项目交付或者新的开发人员加入时，往往要花上很大成本来进行理解或者转换。
另外，每一个测试的描述都被写在断言之后，夹杂在代码之中，难以寻找。
使用XCTest 测试另外一个问题是难以进行mock或者stub，而这在测试中是非常重要的一部分(关于mock测试的问题，我会在下一篇中继续深入)。
行为驱动开发(BDD)正是为了解决上述问题而生的，作为第二代敏捷方法，BDD提倡的是通过将测试语句转换为类似自然语言的描述，开发人员可以使用更符合大众语言的习惯来书写测试，这样不论在项目交接/交付，或者之后自己修改时，都可以顺利很多。
如果说作为开发者的我们日常工作是写代码，那么BDD 其实就是在讲故事。
一个典型的BDD的测试用例包活完整的三段式上下文，测试大多可以翻译为Given..When..Then的格式，读起来轻松惬意。
BDD在其他语言中也已经有一些框架，包括最早的Java的JBehave和赫赫有名的Ruby的RSpec 和Cucumber。
而在objc社区中BDD框架也正在欣欣向荣地发展，得益于objc 的语法本来就非常接近自然语言，再加上C语言宏的威力，我们是有可能写出漂亮优美的测试的。
在objc中，现在比较流行的BDD框架有cedar，specta和Kiwi。
其中个人比较喜欢Kiwi，使用Kiwi写出的测试看起来大概会是这个样子的：describe(@"Team", ^{context(@"when newly created", ^{it(@"should have a name", ^{id team = [Team team];[[ should] equal:@"Black Hawks"];});it(@"should have 11 players", ^{id team = [Team team];[[[team should] have:11] players];});});});我们很容易根据上下文将其提取为Given..When..Then的三段式自然语言Given a team, when newly created, it should have a name, and should have 11 players很简单啊有木有!在这样的语法下，是不是写测试的兴趣都被激发出来了呢。
敏捷测试实践心得体会
随着互联网和软件行业的快速发展，敏捷开发逐渐成为主流的开发模式。
敏捷测试作为敏捷开发的重要组成部分，其核心理念是以用户需求为导向，快速响应变化，提高软件质量。
在我国，敏捷测试也日益受到重视，本文将结合个人实践，谈谈敏捷测试的心得体会。
一、敏捷测试的核心价值观1. 用户至上：敏捷测试始终关注用户需求，确保软件满足用户期望，提高用户满意度。
2. 快速响应：敏捷测试强调快速迭代，及时发现问题，降低风险。
3. 透明沟通：敏捷测试要求团队成员之间保持良好的沟通，确保信息畅通。
4. 自我组织：敏捷测试鼓励团队成员自主组织工作，发挥团队潜能。
5. 不断学习：敏捷测试要求团队成员具备持续学习的能力，适应不断变化的技术和需求。
二、敏捷测试实践心得1. 理解敏捷理念：要成为一名优秀的敏捷测试人员，首先要深入理解敏捷理念，掌握敏捷开发的基本原则和方法。
在实际工作中，要时刻关注用户需求，以用户为中心，快速响应变化。
2. 搭建敏捷团队：敏捷测试的成功离不开一个高效的团队。
在搭建敏捷团队时，要注重团队成员的多样性，包括开发、测试、产品经理等角色，确保团队具备全面的能力。
3. 制定敏捷测试计划：敏捷测试计划应具备灵活性，能够根据项目需求的变化进行调整。
在制定测试计划时，要充分考虑测试范围、测试方法、测试周期等因素。
4. 采用自动化测试：自动化测试是敏捷测试的重要手段，可以提高测试效率，降低人力成本。
在实际工作中，要掌握自动化测试工具，如Selenium、JMeter等，提高测试覆盖率。
5. 关注质量：敏捷测试的核心目标是提高软件质量，确保软件满足用户需求。
在实际工作中，要关注测试过程中的质量，及时发现并解决缺陷。
6. 持续学习：敏捷测试技术不断更新，测试人员要具备持续学习的能力，跟上技术发展的步伐。
可以通过参加培训、阅读书籍、交流经验等方式，提高自己的专业素养。
7. 跨部门协作：敏捷测试需要与其他部门紧密协作，如开发、产品、运维等。
bdd ui 自动化测试方案flybirds
BDD UI 自动化测试方案 - Flybirds1. 背景BDD (行为驱动开发) 是一种敏捷软件开发方法，它通过描述软件系统的行为来促进团队之间的交流和理解。
而 UI 自动化测试是一种用于验证用户界面是否正常工作的测试方法。
结合 BDD 和 UI 自动化测试，可以更好地确保软件系统的质量和稳定性。
2. flybirds 的 BDD UI 自动化测试方案flybirds 是一家专注于软件测试和质量保障的公司，我们致力于为客户提供高质量的测试方案和服务。
在 BDD UI 自动化测试方面，我们经过多年的实践和探索，总结出了一套成熟的方案。
3. 技术选择在 BDD UI 自动化测试方案中，我们选择使用 Cucumber 和Selenium 这两个成熟的工具。
Cucumber 是一个支持 BDD 的测试框架，它通过 Gherkin 语言描述测试用例；Selenium 是一个用于自动化测试的工具，可以模拟用户在浏览器中的操作。
4. 测试用例设计在 BDD UI 自动化测试方案中，测试用例的设计是至关重要的。
我们遵循 Given-When-Then 的模式，明确描述测试场景、操作和预期结果。
这样的设计不仅可以帮助团队更好地理解和交流，还可以提高测试用例的可维护性和可扩展性。
5. 自动化脚本编写在 BDD UI 自动化测试方案中，我们将测试用例翻译成 Cucumber 的特性文件，并编写对应的自动化脚本。
这些脚本可以通过 Selenium 执行，模拟用户在浏览器中的操作，并验证预期结果是否符合预期。
6. 集成持续集成在 BDD UI 自动化测试方案中，我们将自动化测试脚本与持续集成工具集成，如 Jenkins、Travis CI 等。
这样可以在每次代码提交后自动触发测试，并及时反馈测试结果，确保代码质量。
7. 结果输出与报告在 BDD UI 自动化测试方案中，我们会生成详细的测试结果和报告，包括测试覆盖率、通过率、失败率等指标。
使用Cucumber进行BDD的自动化测试
使用Cucumber进行BDD的自动化测试自动化测试是现代软件开发中不可或缺的一环，它可以大大提高测试效率和准确性。
而行为驱动开发（BDD）则是一种基于需求和业务规范的开发方法，有助于软件团队更好地理解和满足客户需求。
Cucumber作为一种BDD工具，可以帮助开发人员和测试人员更好地沟通，提高开发质量和产品稳定性。
本文将介绍如何使用Cucumber进行BDD的自动化测试。
一、Cucumber简介Cucumber是一个开源的BDD工具，它支持多种开发语言，如Java、Ruby等。
Cucumber以自然语言的方式描述系统的行为，并自动生成可执行的测试代码。
开发人员可以通过Cucumber提供的关键字和语法规则编写测试用例，然后通过运行Cucumber测试框架执行这些测试用例。
Cucumber通过解析Gherkin语法文件来生成可执行代码，Gherkin语法是一种类似于自然语言的DSL（领域特定语言），它能够清晰地表达出需求和测试场景。
二、设置Cucumber环境在开始使用Cucumber进行自动化测试之前，我们需要安装并设置Cucumber的开发环境。
首先，我们需要安装Java Development Kit （JDK），然后根据项目需要选择对应的Cucumber版本，并在项目中添加相关的依赖库。
接下来，我们需要创建一个Cucumber项目，并编写Cucumber的配置文件。
在配置文件中，我们可以设置Cucumber的一些参数，如测试报告的输出路径、测试数据的路径等。
最后，我们需要创建一个Cucumber的运行类，用于执行Cucumber测试。
三、编写Cucumber测试用例在使用Cucumber进行自动化测试时，我们需要编写一些关键字和语法规则来描述测试场景和预期结果。
通常情况下，Cucumber测试用例由三个部分组成：Feature、Scenario和Step。
Feature用于描述一个被测试系统的功能或需求，它由一组相关的Scenario组成。
自动化测试cucumber使用实例
自动化测试cucumber使用实例自动化测试是软件开发中的一个重要环节，它可以提高测试效率、减少人为错误，并且可以节省时间和人力成本。
在自动化测试中，Cucumber是一个被广泛使用的测试工具，它使用简单、易于理解，并且能够实现行为驱动开发（BDD）的测试方法。
Cucumber的使用示例可以如下所述：我们需要安装Cucumber的相关软件包。
通过命令行或终端输入相应的命令，即可完成安装过程。
安装完成后，我们可以开始编写测试脚本。
假设我们要测试一个登录功能，首先我们需要创建一个.feature文件，这个文件用于描述测试场景和测试用例。
在.feature文件中，我们可以使用Gherkin语言来编写测试用例的描述，例如：```Feature: 用户登录用户可以通过用户名和密码进行登录Scenario: 正常登录Given 用户打开登录页面When 用户输入正确的用户名和密码And 用户点击登录按钮Then 用户成功登录系统Scenario: 用户名错误Given 用户打开登录页面When 用户输入错误的用户名And 用户输入正确的密码And 用户点击登录按钮Then 用户收到用户名错误的提示信息Scenario: 密码错误Given 用户打开登录页面When 用户输入正确的用户名And 用户输入错误的密码And 用户点击登录按钮Then 用户收到密码错误的提示信息```接下来，我们需要创建一个步骤定义文件，用于实现测试用例中的每个步骤。
在Cucumber中，步骤定义文件使用Ruby或Java等编程语言编写。
例如，在Ruby中，我们可以创建一个.steps文件，其中包含以下内容：```rubyGiven(/^用户打开登录页面$/) do# 打开登录页面的代码逻辑endWhen(/^用户输入正确的用户名和密码$/) do# 输入正确的用户名和密码的代码逻辑endAnd(/^用户点击登录按钮$/) do# 点击登录按钮的代码逻辑endThen(/^用户成功登录系统$/) do# 验证用户成功登录系统的代码逻辑endWhen(/^用户输入错误的用户名$/) do# 输入错误的用户名的代码逻辑endAnd(/^用户输入正确的密码$/) do# 输入正确的密码的代码逻辑endThen(/^用户收到用户名错误的提示信息$/) do # 验证用户收到用户名错误提示信息的代码逻辑endWhen(/^用户输入正确的用户名$/) do# 输入正确的用户名的代码逻辑endAnd(/^用户输入错误的密码$/) do# 输入错误的密码的代码逻辑endThen(/^用户收到密码错误的提示信息$/) do# 验证用户收到密码错误提示信息的代码逻辑end```在步骤定义文件中，我们根据测试用例中的每个步骤编写对应的代码逻辑。
常见的敏捷实践
常见的敏捷实践1 回顾回顾是最重要的⼀个实践，原因是它能让团队学习，改进和调整其过程。
回顾可以帮助团队从之前的产品开发⼯作及其过程中学习。
《敏捷宣⾔》背后的原则之⼀是：“团队要定期反省如何能够做到更加有效，并相应地调整团队的⾏为。
”许多团队使⽤迭代，尤其是为期两周的迭代，因为迭代在最后会提⽰进⾏演⽰和回顾。
不过，团队回顾并不需要迭代。
团队成员可以决定在这些关键时刻进⾏回顾：当团队完成⼀个发布或者加⼊⼀些功能是时。
这不⼀定是⼀个巨⼤的增量。
他可以是任何发布，⽆论它有多⼩。
⾃上次回顾以来，⼜过了⼏周时间。
当团队出现问题时，以及团队协作完成⼯作不顺畅时。
当团队达到任何其他⾥程碑时。
团队可以通过分配⾜够的时间学习收益，⽆论是在项⽬中间回顾，还是在项⽬结束时回顾。
团队需要了解他们的⼯作产品和⼯作过程。
例如，有些团队在完成⼯作时遇到困难。
团队可以计划⽤充⾜的时间组织回顾，以此收集数据、处理数据，再决定之后要尝试的实验做法。
⾸要的是，回顾并不是责备；回顾是让团队从以前的⼯作中学习并作出⼩的改进。
回顾针对定性的（⼈的感觉）和定量的（衡量指标）数据，然后利⽤这些数据找到根源，设计对策，并制定⾏动计划。
项⽬团队可以采取许多⾏动事项来消除障碍。
考虑限制⾏动事项的数量，是团队在即将进⾏的迭代或⼯作期间有能⼒改进。
尝试⼀次改进太多的事情却没有完成其中任何⼀件，⽐计划完成较少的事情并成功全部完成要糟糕的多。
然后，在时间允许的情况下，团队可以进⾏列表中的下⼀个改进。
团队选择改进时，要决定如何衡量结果。
然后，在下⼀段时间内要衡量结果，以验证每个改进成功与否。
来⾃团队的⼀位促进者引导团队通过⼀个活动对所有改进事项的重要性进⾏排序。
完成对改进事项的排序后，团队为下⼀次迭代选择合适的数量（或者在流程基础上增加⼯作）。
2 待办事项列表编制待办事项列表是所有⼯作的有序列表，它以故事形式呈现给团队。
⼯作开始之前，不需要为整个项⽬创建所有的故事，只需要了解第⼀个发布的主要内容正确即可，然后就可以为下⼀个迭代开发⾜够的项⽬。
个人实践环 组织实践环 tdd
个人实践环组织实践环tdd
TDD即测试驱动开发（Test-Driven Development），是敏捷开发中的一项核心实践和技术，也是一种设计方法，核心思想是测试在先，编码在后。
与传统的编码方式相比，TDD在软件开发时可以明确需求的细节，减轻思维负担，得到快速的反馈。
大致流程为：
编写测试，运行测试
编写可以运行的程序，运行测试
编写可以通过测试的程序，运行测试
重构代码，运行测试
基准测试
重构（Refactoring）即通过调整程序代码，不改变系统的外部功能，只对内部的结构进行重新的整理，来改善软件性能，改进软件设计，发现与填补代码缺陷，并提高软件的可扩展性和可维护性。
测试（Testing）即测定某个软件的过程，目的是发现软件中的错误、检测软件是否符合需求、评估软件性能，以保证编写出的软件系统的质量。
基准测试
基准测试（Benchmarking）是指通过合理、科学的方式，测量和评估软件的性能的活动，在软硬件环境变化前后进行测试，可以有效评估其对性能的影响。
简而言之，TDD 流程包括三个环节：
在写代码之前，先写测试用例；然后执行测试结果，此时因为一行业务代码都没写，结果当然是全部用例都不通过（红色）；
根据测试用例，开始写业务代码，此时测试结果逐渐从红色转为绿色；
等到用例全部通过之后，就是考虑重构事宜的时间节点了。
前期为了赶项目进度，可能不会考虑内部质量（即代码质量，不会思考 SOLID 原则和设计模式等）；但在合适的时机（比如空闲时或者下个迭代功能开始之前）务必做重构，这个时间点因为有“绿码”保障，对重构自然也是信心十足。
上述环节要想完美地运作，核心是要做好任务分解和模块拆分。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
项目业务挑战
▪ 客户有很大的决心希望使用新IT技术来对他们的 原有系统进行转型
▪ 非常紧的项目进度，但对质量要求高
▪ 需要从传统的瀑布开发模式转到敏捷Scrum的开 发模式
利用新IT技术 转型
敏捷 Scru m开 发模 式
进度紧， 质量高
项目组织架构图
Scrum Team 1
香港 On Site 2人
进度风险
• 项目上线周期短，给 测试的时间不多
质量风险
• 系统涉及到会员账户 等相关信息，对质量 要求比较高
管理风险
• 敏捷Scrum + BDD开 发模式，测试人员需 要在敏捷环境下进行 工作，与传统模式相 比有较大差距
02 章节 PART 项 目 实 施 过 程
测试解决思路
测试难点
周期短 质量高 BDD模式 敏捷Scrum 微服务、容器 云计算
- 荣获9项《福布斯旅游指南》五星荣耀连续三 年冠绝全澳门
- 坐拥全澳门最多家米其林星级食府
- 为了增加用户体验，减少运维成本，客户香港 总部希望用最新的IT技术和开发方法对其现有 的博彩管理系统“GEMS”系统进行升级改造
- GEMS系统改造项目从2016年中开始酝酿，并 且在2017年1月正式启动
确保在新IT技术环境下的项目交付质量，减少不良质量成本，节省项 目费用
遵从Scrum开发模式实践，开发人员和测试人员紧密合作，互相配合， 加快整个项目的交付速度
学习、探索式测试
判断自动化可行性
可行性？
停止
设计开发自动化测试脚本 执行自动化回归测试
自动化回 归用例库
下个Sprint执行
持续集成场景
开发自测
1. 开发人员写完代码在本 机运行SonarQube 进行代 码检查
2. 开发人员运行自动化jUnit 单元测试
3. 当测试通过后，开发 人员推送到Git的Sprint 代码分支进行合并
配置管理
环境配置
全局参数
数据管理
数据库
文件存储
异常管理
日志信息
结果截图
Selenium API
公共API
RestAssured API
Appium API
业务API
资源文件 feature
Sprint 1
Sprint 2
Sprint 3
Sprint...
Cucumber
Sprint n
Selenium Web应用
基于BDD的 敏捷项目测试实践
目录
Contens
01、项目背景痛点 02、项目实施过程 03、项目收益价值
01 章节 PART 项 目 背 景 痛 点
客户背景与目标
客户背景 客户目标
- 是一家于亚洲发展、拥有和经营娱乐场博彩及娱 乐度假村业务的公司
- 2006年12月成功在美国纳斯达克证券市场上市
行
为
敏
驱
服
服
务
务
服
服
服
务
务
务
捷
动
开
容器
发
技术
Mongo DB
亚马逊云AWS
Scrum
架构技术：
• 微服务 • 容器 • 云计算
开发技术：
• Angular JS • Restful API • Mongo DB
开发模式和实践：
• BDD行为驱动开发 • 敏捷Scrum
为测试带来的困难
技术风险
• 测试人员对云计算、 微服务等新的技术经 验不足
易读性：Cucumber是BDD（行为驱动开发）的 自动化框架，它是站在业务的层面，脚本是我们 所熟知的自然语言（中/英文），是一段描述，使 得脚本很容易看懂
易扩展性：框架目前集成了WEB和API自动化测 试功能，根据项目需要能快速集成IOS和Android 的手机端自动化测试
易维护性：脚本运行时会记录日志信息，执行失 败会截图，能快速定位到问题所在，使得脚本的 维护更加容易
自
动
化
测
试
框
架
Cucumber
Selenium自动化 测试
API接口测试
被测系统 应用层 服务层 数据库层
基于Cucumber二次开发的自动化测试框架
持续 集成
二次 开发
框架 驱动
层 应用 类型
Jenkins
Cucumber Report Plugin
元素管理
基础API （通用元素）
PageObject （特殊元素）
• 通过与开发单元测试、 配置管理，构建管理、 项目管理等领域集成， 实现持续集成，加快 交付速度
2. 持续集成
• 分层自动化，实 现从API到UI层自 动化测试；
• 采用BDD的 Cucumber自动 化测试框架
1. 自动化测试
自动化测试解决方案
基 于
使用Gherkin语法
描写的
的
Feature/Scenario
测试用例如何编写（例子）
Feature/Scenario
Cucumber自动化测试框架 Script/Code
一个Sprint里面的自动化测试流程
Sprint计划会
BA/SME SM 开发人员 测试人员
本次Sprint的User Story
本次Sprint结束
开发人员 测试人员 测试开发工程师
开发构建及单元测试
持续集成
4. Jenkins 开始自 动构建
5. Jenkins运行 SonarQube 进行代 码质量扫描
10. 通过Rally反馈Bug给 开发人员
9. 测试人员进行探索式测 试
8. Jenkins 通过Cucumber 启动Selenium进行自动化 UI测试
7. 部署完成后Jenkins 通过 Cucumber启动API自动化测 试
6. 服务应用通过Docker 被 Jenkins 部署到测试环境
持续集成过程
Jenkins配置
运行失败的日志记录和截图
每日自动触发 测试
自动化测试报告
03 章节 PART 项 目 收 益 价 值
项目收益
成果收益
全栈式的自动化测试框架集成Jenkins覆盖了从单元测试，API测试到 UI测试的全过程。API自动化测试覆盖率达到80%，UI自动化测试覆盖 率达到65%
Hale Waihona Puke Rest Assured API应用
Appium Mobile应用
框架特性
稳定性：对Selenium进行二次封装，使得脚本 稳定性大大增强
效率性：对界面元素进行封装，特殊的元素通过 Page Object调用，通用的元素通过传递参数就 可直接定位，无需通过浏览器获取XPATH值，使 得编写脚本的效率大大提高
Scrum Team 2
2人
Scrum Team 3
2人
Scrum Team 4
2人
Scrum Team 5
2人
示例：
BA
开发人员
广州 Off Site 5人 5人 5人 5人 5人
1人 1人 1人 2人 1人 1人
功能测试人员
测试开发工程师
项目技术架构示意图
前端Angular JS
API
微服务架构