《测试驱动数据库开发》—第1章1.3节什么是障碍

简介:

本节书摘来自异步社区《测试驱动数据库开发》一书中的第1章1.3节什么是障碍,作者【美】Max Guernsey, III,更多章节内容可以访问云栖社区“异步社区”公众号查看。

1.3 什么是障碍
测试驱动数据库开发
那么,真正的问题是什么呢?是什么真正阻碍了测试驱动数据库开发的实现?从根本上讲,上面这个问题的答案就是数据库—单独的服务器和数据库实例,即持久化解决方案的运行平台。与一个用于创建一组最终能够被装载到任何特定会话的应用程序的二进制文件的设计相比,一个单独的数据库更像是一个包含 JVM 和一个应用程序的特定会话的进程。

开发人员需要摆脱不良的做法,转向构建不再绑定任何特定数据库实例的数据库设计。

1.3.1 数据库就是对象
数据库就是对象,从面向对象编程的程序员的角度看,它们是长期存在的对象,即便如此,它们仍然是对象。现如今,许多人对待数据库的方式类似于软件开发早期计算机程序员针对计算机本身编程,而不是针对那些能够运行在计算机上的程序编程。

除了一些遗留系统,上述开发应用程序代码的方式因为一些原因而像渡渡鸟1那样绝迹了。最明显的原因是现代计算机环境的复杂性要求能随时随地新增或移除硬件。另一个原因是很多应用程序不得不运行在多种多样的硬件上,或者运行在物理上与开发软件的程序员分离的环境中。

1.3.2 TDD适用于类,不适用于对象
对于数据库领域中的 TDD 来说,其最大的障碍存在于测试的内在本质中。测试天生就是在对象之上进行操作的。当一个人运行手工测试时,他把大量的对象作为接口并与之打交道,包括正使用的应用程序的一个实例和与之交互的大量业务逻辑对象的实例,这些实例根据它们的输入和/或输入产生的结果来作出决定。

其他产业并不是像上面描述的那样做测试。生产需要长期使用的绝对关键产品的公司,如为替换受损髋关节而生产人工髋关节的公司,是需要测试从生产线下来的每一件产品的。而生产那些不是长期使用或不大可能因为产品失效而造成严重人身伤害的产品的公司,如生产铅笔的公司就通过测试产品在统计学领域的显著部分来近似做到测试他们生产的每一件产品。

为什么软件开发人员能够不用测试每一件产品,而仅仅测试他们所做的一些实例呢?

在软件产业,能够像这样做测试可能是因为同一个类的两个对象能做出完全相同的行为。你能用一个类产生任意数量的对象,所有这些对象都具有完全相同的行为。

软件开发者进行开发的这一独特特性,允许一个类的任一实例能作为该类其他每一个实例的模板。这意味着,仅仅对一个对象进行测试就能获得这些对象的类的情况,并能获得该类已经和即将创建的所有对象的情况。

然而,如果开发人员所处的情况与上述情况不同该怎么办?如果一个类的每一个实例都是通过手工或者通过在另一台计算机上的一个不可靠的过程组装成的,那该怎么办?在这种情况下,测试一个对象就不能获得另一个对象的情况。开发者必须测试所构建系统的有统计学代表性的一个子集,而需要做的测试数量将与可以接受的风险数量相匹配。

这就是在数据库世界中开发者所面临的处境。开发者开发了一个设计,很少能有一个容易的方法来将该设计的变化引入到新的或现存的数据库实例中。更多的时候,开发者会在某类数据库的所有各种重要的实例上手工调节设计的变化,这等同于在每一台需要作出更新的计算机上手工修改和检查汇编代码(或者是一些非常初级的源代码),然后在那台计算机上重新编译二进制代码。

当开发者以上述方式开发时,就近乎于需要测试所创建的每一个产品实例。然而,在软件产业,测试通常需要对所测试的对象大动干戈,而开发者不能让产品实例上的实时数据遭受测试带来的那种危险。一些数据库实例,特别是生产数据库,根本就无法进行测试。

1.3.3 我们需要数据库的类
如果开发者需要了解一个数据库的情况,但是不允许对其进行测试,就需要找到一种方法,通过测试一个代理来了解那个数据库是正常工作的。正如本书已经提到的,在应用程序开发世界中允许我们做此事的机制就是类。

因此,测试驱动数据库开发的基础就是建立数据库的类,而不是建立特定数据库的实例。定义的类负责构建和更新测试实例。在从测试实例中获得足够多的反馈来验证对一个类所做的变化之后,接下来该类就以更新测试实例完全相同的方式来更新生产数据库。

相对于那些开发者不想运行任何测试的产品实例来说,通过这种方式可以确保测试实例是个良好的模板。在本书的整个内容中,读者将看到同样的过程不仅允许检查对数据库的修改做了什么,还能检查修改是如何被引入的。当开发者想要把一个数据库的修改发布到任何一个生产环境中时,你完全有信心相信上述修改“是能够工作”的。

1渡渡鸟,或作嘟嘟鸟(Dodo),又称毛里求斯渡渡鸟、愚鸠、孤鸽,是仅产于印度洋毛里求斯岛上一种不会飞的鸟。在被人类发现后仅仅200年的时间里,这种鸟便由于人类的捕杀和人类活动的影响彻底绝灭,堪称是除恐龙之外最著名的已灭绝动物之一。引自百度百科。—译者注
本文仅用于学习和交流目的,不代表异步社区观点。非商业转载请注明作译者、出处,并保留本文的原始链接。

相关文章
|
5月前
|
人工智能 自然语言处理 测试技术
从人工到AI驱动:天猫测试全流程自动化变革实践
天猫技术质量团队探索AI在测试全流程的落地应用,覆盖需求解析、用例生成、数据构造、执行验证等核心环节。通过AI+自然语言驱动,实现测试自动化、可溯化与可管理化,在用例生成、数据构造和执行校验中显著提效,推动测试体系从人工迈向AI全流程自动化,提升效率40%以上,用例覆盖超70%,并构建行业级知识资产沉淀平台。
从人工到AI驱动:天猫测试全流程自动化变革实践
|
8月前
|
数据采集 人工智能 监控
人工智能驱动的软件工程:测试左移的崛起价值
本文探讨了人工智能驱动下测试左移理念在软件工程中的重要性,分析测试工程师在需求评估、AI代码生成及遗留系统优化中的关键作用,揭示AI带来的挑战与机遇,并指出测试工程师需提升技能、关注合规与可维护性,以在AI时代保障软件质量。
433 89
|
11月前
|
人工智能 自然语言处理 JavaScript
测试工程师要失业?Magnitude:开源AI Agent驱动的端到端测试框架,让Web测试更智能,自动完善测试用例!
Magnitude是一个基于视觉AI代理的开源端到端测试框架,通过自然语言构建测试用例,结合推理代理和视觉代理实现智能化的Web应用测试,支持本地运行和CI/CD集成。
1496 15
测试工程师要失业?Magnitude:开源AI Agent驱动的端到端测试框架,让Web测试更智能,自动完善测试用例!
|
数据采集 人工智能 自然语言处理
Midscene.js:AI 驱动的 UI 自动化测试框架,支持自然语言交互,生成可视化报告
Midscene.js 是一款基于 AI 技术的 UI 自动化测试框架,通过自然语言交互简化测试流程,支持动作执行、数据查询和页面断言,提供可视化报告,适用于多种应用场景。
3698 1
Midscene.js:AI 驱动的 UI 自动化测试框架,支持自然语言交互,生成可视化报告
|
机器学习/深度学习 人工智能 自然语言处理
智能化软件测试:AI驱动的自动化测试策略与实践####
本文深入探讨了人工智能(AI)在软件测试领域的创新应用,通过分析AI技术如何优化测试流程、提升测试效率及质量,阐述了智能化软件测试的核心价值。文章首先概述了传统软件测试面临的挑战,随后详细介绍了AI驱动的自动化测试工具与框架,包括自然语言处理(NLP)、机器学习(ML)算法在缺陷预测、测试用例生成及自动化回归测试中的应用实例。最后,文章展望了智能化软件测试的未来发展趋势,强调了持续学习与适应能力对于保持测试策略有效性的重要性。 ####
|
机器学习/深度学习 数据采集 人工智能
探索AI驱动的自动化测试新纪元###
本文旨在探讨人工智能如何革新软件测试领域,通过AI技术提升测试效率、精准度和覆盖范围。在智能算法的支持下,自动化测试不再局限于简单的脚本回放,而是能够模拟复杂场景、预测潜在缺陷,并实现自我学习与优化。我们正步入一个测试更加主动、灵活且高效的新时代,本文将深入剖析这一变革的核心驱动力及其对未来软件开发的影响。 ###
|
存储 测试技术 数据库
数据驱动测试和关键词驱动测试的区别
数据驱动测试 数据驱动测试或 DDT 也被称为参数化测试。
359 1
|
数据可视化 前端开发 测试技术
接口测试新选择:Postman替代方案全解析
在软件开发中,接口测试工具至关重要。Postman长期占据主导地位,但随着国产工具的崛起,越来越多开发者转向更适合中国市场的替代方案——Apifox。它不仅支持中英文切换、完全免费不限人数,还具备强大的可视化操作、自动生成文档和API调试功能,极大简化了开发流程。
|
9月前
|
Java 测试技术 容器
Jmeter工具使用:HTTP接口性能测试实战
希望这篇文章能够帮助你初步理解如何使用JMeter进行HTTP接口性能测试,有兴趣的话,你可以研究更多关于JMeter的内容。记住,只有理解并掌握了这些工具,你才能充分利用它们发挥其应有的价值。+
1268 23
|
11月前
|
SQL 安全 测试技术
2025接口测试全攻略:高并发、安全防护与六大工具实战指南
本文探讨高并发稳定性验证、安全防护实战及六大工具(Postman、RunnerGo、Apipost、JMeter、SoapUI、Fiddler)选型指南,助力构建未来接口测试体系。接口测试旨在验证数据传输、参数合法性、错误处理能力及性能安全性,其重要性体现在早期发现问题、保障系统稳定和支撑持续集成。常用方法包括功能、性能、安全性及兼容性测试,典型场景涵盖前后端分离开发、第三方服务集成与数据一致性检查。选择合适的工具需综合考虑需求与团队协作等因素。
1659 24