软件测试的六大原则
本指南介绍了任何软件测试人员和质量保证专业人员都应了解的七个基本的软件测试原则。
软件测试的六大原则
- 穷举测试是不可能的
- 尽早测试
- 缺陷聚集
- 杀虫剂悖论
- 测试依赖于上下文
- 没有错误的谬误
背景
进行软件测试时,必须在不偏离目标的情况下获得最佳测试结果。但我们如何知道自己是否使用了最佳的研究策略呢?为此,我们必须遵守某些基本的研究标准。
考虑以下情况:我们将文件从文件夹 A 传输到文件夹 B。考虑我们可以测试此操作的多种方法。
除了标准示例外,您还可以设置以下条件进行测试:
- 尝试传输正在打开的文件。
- 我们没有将文件粘贴到文件夹 B 的必要安全权限。
- 文件夹 B 位于共享磁盘上,并且其存储空间已满。
- 文件夹 B 也包含同名文件,等等。
- 如果您有 15 个输入字段需要比较,每个字段有 5 个可能的值,则需要测试的总变体数量为 5^15。
如果您测试了每种可能的组合,项目的处理时间和费用将激增。因此,我们需要一些概念和技术来增强研究,同时优化工作量。
以下是六大原则:
1. 穷举测试是不可能的
是的!没有必要进行穷举测试。相反,我们需要根据应用程序的风险评估进行尽可能少的测试。
最重要的是,如何计算这种潜在的风险?让我们做一个实验来解决这个问题。
您认为哪项活动最有可能导致您的操作系统崩溃?
我希望你们都能猜对,那就是同时打开十个单独的应用程序。
因此,如果您正在测试此操作系统,您会注意到在多任务活动中更容易检测到错误,并且必须仔细测试这些错误,这使我们想到了下一个概念:缺陷聚集。
2. 缺陷聚集
根据缺陷聚集原则,发现的大多数缺陷都集中在少数几个单元中。帕累托原则应用于软件测试:大约 80% 的问题在 20% 的单元中被发现。
这些有问题的模块可以通过实践来识别。但是,这种策略有一些缺点。
如果反复进行相同的实验,相同的测试用例最终将无法检测到新的缺陷。
3. 杀虫剂悖论
在农业中重复使用相同的杀虫剂组合来杀死昆虫,会导致昆虫随着时间的推移获得杀虫剂抗性,从而使杀虫剂对昆虫无效。软件测试也是如此。如果执行相同的重复检查序列,则该过程将无法有效检测新的缺陷。
为了解决这个问题,必须定期测试和更新测试用例,并加入新的和不同的测试用例来发现新的缺陷。
测试人员不能仅仅依赖于当前的测试方法。他们必须不断努力改进现有技术,以提高研究效率。然而,即使在研究中付出了所有努力,也不能说最终结果是完全无错误的。为了强调这一点,让我们重点介绍灾难性的 Windows 98 公开发布计划。在发布活动中,演示者向公众演示操作系统时,操作系统崩溃了。您认为像微软这样的公司不会仔细检查其操作系统,并且会为了让其操作系统在公开发布期间失败而危及其声誉吗?
4. 没有错误的谬误
测试哲学认为 - 测试讨论的是缺陷的存在,而不是缺陷的缺乏。也就是说,软件测试降低了软件中存在未发现缺陷的可能性,但即使没有发现缺陷,这也不能证明 100% 的准确性。
但是,如果您非常努力地工作,并小心谨慎地确保技术产品没有错误呢?而程序未能满足客户的需求和期望。
这使我们想到了我们的下一个理论,它指出没有错误是很重要的。
5. 尽早测试
应该在软件开发生命周期的早期开始测试,以便尽早发现规范或设计阶段的任何缺陷。在测试的早期阶段修复缺陷的成本也更低。但是,从何时开始测试呢?建议您在指定规范后立即开始寻找错误。
6. 测试依赖于上下文
测试依赖于上下文,这意味着测试电子商务平台可能与测试商业应用程序不同。所有构建的软件都不相同。根据应用程序的形式,您可以使用特定的方法、方法论、方法和测试形式。例如,在零售店中测试 POS 设备与测试 ATM 机不同。
误区:“原则只是指导方针。它们实际上无法实现。”
这是完全错误的。测试原则将帮助您制定成功的测试策略并编写能够捕获错误的测试用例。但是,掌握测试概念就像第一次学习驾驶一样。
当您第一次开始学习驾驶时,您会密切注意所有事情,例如换挡、转速、离合器操作等等。但是,随着练习,您只需要专注于驾驶,其余的都会自然而然地发生。以至于您还在与车里的其他人交谈。
测试原则也是如此。经验丰富的测试人员已经将这些原则内化到他们毫不费力地采用它们的程度。
软件测试中的 V 模型
**V 模型**是一个高度组织的 SDLC 模型,除了每个生产阶段外,还包括一个测试阶段。V 模型是瀑布模型的演变,其中研究是在每个阶段与设计和开发同时进行的。它被称为**验证或确认模型。**
关键词
- **SDLC:**SDLC 是软件开发生命周期的缩写。它是程序员为了设计和创建高质量应用程序而执行的一系列任务。
- **STLC:**STLC 是软件测试生命周期的缩写。它包含测试人员系统地执行的一套工作,以验证软件产品。
- **瀑布模型:**瀑布模型是一个顺序模型,它将软件开发操作划分为不同的阶段。每个阶段都旨在用于特定操作。在瀑布模型中,测试过程仅在满足系统的规范后才开始。
理解 V 模型的示例
假设您已承担为客户开发定制应用程序的任务。无论您的技术经验如何,您都会采取以下一系列步骤来完成任务。
软件开发生命周期的不同阶段 | 执行的活动 |
---|---|
收集阶段 | 尽可能多地从客户那里收集有关所需程序的详细信息和配置的输入。这仅仅是规范收集点。 |
设计阶段 | 规划编程语言(例如 Java、PHP、.NET)和数据库(例如 Oracle、MySQL 等),这些语言和数据库适合该项目,以及某些高级功能和架构。 |
构建阶段 | 在概念阶段之后是构建阶段,这只不过是简单地编写软件代码。 |
测试阶段 | 之后,您验证应用程序以确保它符合客户的要求。 |
部署阶段 | 在适当的环境中安装程序。 |
维护阶段 | 程序运行后,您可能需要根据客户的输入修改代码。 |
这就是所谓的软件开发生命周期的瀑布方法。
瀑布模型的问题
如您所见,**该模型中的测试仅在安装完成后才开始。**
但是,如果您正在处理一个具有动态结构的大型项目,则有可能在收集过程中忽略重要信息。在这两种情况下,客户都可能获得完全错误的产品,您可能必须重新开始任务。相反,如果您正确地说明了规范但在测试设计中犯了重大错误,您可能必须重新开始工作。为了修复应用程序创建和设计中的缺陷,您将不得不重建整个软件。
数千个项目评估表明,**在规范和构建过程中引入的缺陷占总错误数量的一半以上。**
此外,**修复缺陷的成本在开发生命周期中会增加。在生命周期中越早发现缺陷,修复它的成本就越低。**俗话说,“及时一针,省去九针”。
解决方案——V 模型
为了解决这个问题,引入了**V 模型**测试,其中**开发生命周期的每个步骤都对应一个测试阶段。**
这张图是为了向您展示为什么它被称为“V 模型”。
- 模型的左侧显示“软件开发生命周期”——**SDLC**
- 模型的右侧显示“软件测试生命周期”——**STLC**
- 整个结构/流程图看起来像一个 V,因此得名**“V 模型”**。
除了V模型之外,还存在迭代开发模型。在这种模型中,开发工作分阶段进行,每一步都会为程序添加新的功能。每个过程都包含其自身的一系列实现和测试练习。
快速应用开发(RAD)和敏捷开发是迭代开发生命周期的两个很好的例子。
结论
软件开发生命周期有多种模型。为项目选择的开发模型取决于项目的具体目标和优先级。
- 测试不是一项独立的动作;它必须根据项目的增长方式进行调整。
- 在任何模型中,测试都可以在所有阶段进行,从需求收集阶段到维护阶段。