《 自动化测试最佳实践:来自全球的经典自动化测试案例解析》一一1.4 利用验收测试驱动开发,使用FitNesse测试GUI

简介: 本节书摘来自华章出版社《 自动化测试最佳实践:来自全球的经典自动化测试案例解析 》一 书中的第1章,第1. 4 节,作者:(英)Dorothy Graham Mark Fewster 著 ,更多章节内容可以访问云栖社区“华章计算机”公众号查看

1.4 利用验收测试驱动开发,使用FitNesse测试GUI
现在已经是我们自动化之旅的第8个月了,程序员已经建立了一个自动化单元测试的实用库。对于应用程序的核心区域我们已经进行了冒烟测试,覆盖微量代码的大约100个JUnit测试已经完成了。但是中间层还什么都没有,TDD此时变成了一个空壳。现在我们开始对自动化测试金字塔的中间层进行填充。
1.4.1 内存内测试
我们的金融理财产品有许多复杂的算法,这可以通过在内存中提供输入来进行测试。与单元测试相比,这种测试的级别要高很多,但我们还是不想通过GUI来进行测试,因为其速度慢、成本高。我们发现可以很迅速、方便地编写FitNesse夹具(fixture)来自动进行这类测试。在客户测试层次,我们开始用FitNesse测试来驱动新的用户故事的开发。这些测试使用夹具在内存中构建测试输入,并把这些输入发送到应用层代码,就如同产品在实际使用时进行的输入一样。然后夹具会返回代码的实际输出,并把它与FitNesse表中的期望结果进行对比。
测试人员和客户填写FitNesse测试用例,之后程序员用夹具来自动运行它们。这意味着我们需要交流!提高团队的交流能力是使用这种工具进行自动化测试的最大好处之一。我们测试人员与产品所有者和其他利益相关者坐在一起分析每个用户故事预期的和非预期的行为。我们将这些用户故事转化为FitNesse测试用例表,并与客户核对以保证当测试用例通过测试的时候能够满足客户的要求。我们与开发人员核对测试,以保证我们清楚需求并保证测试设计与代码设计兼容。开发人员编写夹具来自动运行测试。这一过程在单个用户故事的很多小的迭代中不断重复,直到开发和测试都完成。
1.4.2 使用数据库的测试
我们的应用是数据密集型应用,我们想自动运行更加端到端(end-to-end)的测试。我们也可以使用FitNesse在数据库中构建测试数据,并使用遗留代码在它上面运行,以此来测试遗留代码。
这种类型的测试脚本编写和维护都更加昂贵。作为FitNesse的初学者,我们犯了一些错误,如,不知道将测试组件模块化,而这可以通过FitNesse中现有的部件来完成。我们彻底违反了代码设计中的“不要重复自我”准则。例如,在几十个不同的测试页面中,有包含同样员工信息的表,如果又有一列新数据需要添加到员工信息表中,那么在每个测试页面中都要加进去,这很糟糕。等到我们知道如何正确去做的时候,又遇到了一个更难以处理的麻烦。
【经验教训】
在前期进行工具使用的培训,之后就可以避免因工具使用不熟练而造成的巨大的时间浪费。
我们将每个能想到的测试用例都进行了自动化,包括发生几率低、影响小的边缘测试用例,并把它们都放在自动回归测试套件(test suite)里面。上述过程花费的时间并不长,但是接下来,这个测试套件要花费大量时间和主机功率(machine power)来运行,维护成本也随之提高了。所以,我们要学会慎重选择测试用例,确保它们能提供充分的测试覆盖,并只将这些测试用例放在回归测试套件中。
【小窍门】
精化回归测试套件可以在保证收益的同时降低维护费用。
正如在产品应用代码中所做的那样,我们现在不断地重复访问和重构FitNesse测试用例,以保证我们所需要的测试覆盖,同时不会过多地延长反馈周期或者花费太多时间维护测试。
【真知灼见】
经常检查自动化测试用例以保证它们是有效的。
1.4.3 使用FitNesse测试的好处
我们的FitNesse测试提供了比GUI测试套件更快的反馈,尽管比JUnit测试要慢很多。FitNesse测试套件需要60 ~ 90分钟来运行,而JUnit测试的运行时间仅仅只需要不到8分钟。像GUI测试脚本那样,我们将FitNesse测试集成到构建过程中,并且在其中运行。一开始,我们只在晚上运行这种“完全构建”(full build),但这无法提供及时的反馈,并且如果测试失败的话,我们只有在第二个晚上才能知道问题是否修复了。我们投入了更多的硬件,这样我们就可以“连续地”运行单元级别上的所有测试的完全构建。如同运行单元级别测试的构建一样,这是为了使源代码控制每接收到一次检入就能运行。大概需要90分钟运行一次,所以经常同时测试几个新的检入。

相关文章
|
2月前
|
人工智能 自然语言处理 算法
AI智能混剪视频大模型开发方案:从文字到视频的自动化生成·优雅草卓伊凡
AI智能混剪视频大模型开发方案:从文字到视频的自动化生成·优雅草卓伊凡
157 0
AI智能混剪视频大模型开发方案:从文字到视频的自动化生成·优雅草卓伊凡
|
2月前
|
存储 人工智能 测试技术
HarmonyOS Next~HarmonyOS应用测试全流程解析:从一级类目上架到二级类目专项测试
本文深入解析HarmonyOS应用测试全流程,涵盖从一级类目通用测试到二级类目专项测试的技术方案。针对兼容性、性能、安全测试及分布式能力验证等关键环节,提供详细实践指导与代码示例。同时,结合典型案例分析常见问题及优化策略,帮助开发者满足华为严苛的质量标准,顺利上架应用。文章强调测试在开发中的核心地位,助力打造高品质HarmonyOS应用。
124 2
|
2月前
|
数据采集 机器学习/深度学习 人工智能
运维人的“福音”?AI 驱动的自动化网络监控到底香不香!
运维人的“福音”?AI 驱动的自动化网络监控到底香不香!
142 0
|
3月前
|
人工智能 自然语言处理 JavaScript
测试工程师要失业?Magnitude:开源AI Agent驱动的端到端测试框架,让Web测试更智能,自动完善测试用例!
Magnitude是一个基于视觉AI代理的开源端到端测试框架,通过自然语言构建测试用例,结合推理代理和视觉代理实现智能化的Web应用测试,支持本地运行和CI/CD集成。
386 15
测试工程师要失业?Magnitude:开源AI Agent驱动的端到端测试框架,让Web测试更智能,自动完善测试用例!
|
1月前
|
消息中间件 缓存 监控
性能测试怎么做?方法、流程与核心要点解析
本文系统阐述了性能测试的核心方法论、实施流程、问题定位优化及报告编写规范。涵盖五大测试类型(负载验证、极限压力、基准比对、持续稳定性、弹性扩展)与七项关键指标,详解各阶段任务如需求分析、场景设计和环境搭建,并提供常见瓶颈识别与优化实战案例。最后规范测试报告内容框架与数据可视化建议,为企业级实践提出建立基线库、自动化回归和全链路压测体系等建议,助力高效开展性能测试工作。
|
1月前
|
JavaScript 测试技术 Python
UI自动化测试中的元素等待机制解析
在UI自动化测试中,元素定位失败常因页面存在iframe或缺乏合理等待机制。本文解析三种等待策略及其应用场景:显式等待可精确控制单个元素等待条件,支持自定义轮询;隐式等待全局生效,适合简单页面加载;强制等待仅用于临时调试,正式脚本慎用。通过对比三者执行精度、资源消耗及适用场景,帮助选择最优策略,提升测试效率与稳定性。
|
3月前
|
人工智能 运维 API
无需配置开箱即用!MoLing:基于MCP开发的自动化办公服务,一键搞定文件与网页操作
MoLing是一款基于Go语言开发的跨平台办公自动化工具,通过操作系统API和浏览器自动化框架实现文件操作、命令执行及网页控制,无需额外依赖即可运行。
186 1
无需配置开箱即用!MoLing:基于MCP开发的自动化办公服务,一键搞定文件与网页操作
|
3月前
|
人工智能 Java 定位技术
Java 开发玩转 MCP:从 Claude 自动化到 Spring AI Alibaba 生态整合
本文详细讲解了Java开发者如何基于Spring AI Alibaba框架玩转MCP(Model Context Protocol),涵盖基础概念、快速体验、服务发布与调用等内容。重点包括将Spring应用发布为MCP Server(支持stdio与SSE模式)、开发MCP Client调用服务,以及在Spring AI Alibaba的OpenManus中使用MCP增强工具能力。通过实际示例,如天气查询与百度地图路线规划,展示了MCP在AI应用中的强大作用。最后总结了MCP对AI开发的意义及其在Spring AI中的实现价值。
1104 9
|
4月前
|
人工智能 API 开发者
HarmonyOS Next~鸿蒙应用框架开发实战:Ability Kit与Accessibility Kit深度解析
本书深入解析HarmonyOS应用框架开发,聚焦Ability Kit与Accessibility Kit两大核心组件。Ability Kit通过FA/PA双引擎架构实现跨设备协同,支持分布式能力开发;Accessibility Kit提供无障碍服务构建方案,优化用户体验。内容涵盖设计理念、实践案例、调试优化及未来演进方向,助力开发者打造高效、包容的分布式应用,体现HarmonyOS生态价值。
190 27

热门文章

最新文章

推荐镜像

更多
  • DNS