惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
酷 壳 – CoolShell
酷 壳 – CoolShell
博客园_首页
Engineering at Meta
Engineering at Meta
量子位
A
About on SuperTechFans
阮一峰的网络日志
阮一峰的网络日志
Recent Announcements
Recent Announcements
博客园 - 司徒正美
V
Visual Studio Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
The GitHub Blog
The GitHub Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
F
Fortinet All Blogs
Martin Fowler
Martin Fowler
腾讯CDC
Jina AI
Jina AI
C
Check Point Blog
H
Help Net Security
罗磊的独立博客
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
V
V2EX
爱范儿
爱范儿
I
InfoQ

博客园 - ZhuQue

软件测试报告在高新技术企业(高企)认定报告中具有重要作用 windows下监控mongoDB数据库 什么是性能测试服务,以及进行哪些测试? 软件测试报告与测试计划的关系探讨 软件测试报告中的关键指标解读 软件测试报告这样写,项目结题一路绿灯! 软件项目产品质量验收标准及验收方法 什么情况下软件测试报告使用CNAS/CMA标识?哪种情况软件测试报告要加盖CMA印章 XMind2020思维导图软件下载地址 网站后台SMTP协议发送邮件,提示“SMTP Error: Could not connect to SMTP host。” python3.4版本32位环境安装pyinstaller 中标麒麟3.2版本对应RedHat linux 6版本 多线程上下文切换与高并发 对k8s中pod的理解 InfluxDB数据库管理工具InfluxDBStudio使用 eclipse代码中添加图片后页面不显示图片,提示“Whitelabel Error Page” 给登录模块添加密码明文、密文切换功能(即睁眼、闭眼功能) maven项目中@Override的问题,提示“[51,17] 方法不会覆盖或实现超类型的方法‘ centos系统systemctl restart network启动失败,提示“code=exited status=1”
软件测试中如何进行全面测试
ZhuQue · 2024-10-22 · via 博客园 - ZhuQue

在当今数字化时代,确保软件系统或应用程序在各种条件下都能表现出色至关重要。全面测试(也有人成为“穷举测试”)作为一种软件测试方法,旨在探索系统的所有行为,以验证其在特定工作负载下的响应性、可扩展性、速度和稳定性。尽管理论上理想,但在实际测试环境中,由于时间和资源的限制,实施全面测试往往不可行。

在软件测试领域,质与量的平衡至关重要。一个优秀的软件测试人员总是追求最高质量,但过度追求可能导致不必要的资源消耗。为了避免这种情况,了解“全面测试”的概念显得尤为重要。我们@软件测试机构旨在帮助专业人士建立标准和方法,制定全面的软件测试计划。

普遍的建议有抱负的测试人员应该使用所有已知的方法来测试每一个可见的功能。从软件质量保证的角度来看,这种方法并非错误,尤其是对于那些对安全性要求极高的程序,如核电站或航天器的软件。然而,在商业测试盛行的时代,特别是在有特定预算限制的情况下,这种方法可能导致资源的浪费。通过无限扩大测试范围和测试数量,质量保证工程师可能会无限延长测试时间。在这种情况下,软件测试人员可能会面对一个包含数十万项的检查清单,每一项看起来都非常重要,但测试时间却保持不变。

测试数量

软件测试的冗余往往源于这样的思考:“我能在这个项目上执行一些特定类型的测试吗?”大多数情况下,答案是肯定的。但在扩展测试领域、添加新的工具和技术之前,值得深思的是:任何测试,无论多么微不足道,都是获取有关项目或检查功能数据的机会。通过执行新的测试,QA可能会对软件有新的认识,或者这些行动可能不会产生任何结果。

为了更清晰地说明这一点,让我们分析一个现实生活中可能遇到的例子。在面试中,候选人被要求提出测试标准WordPress网站的方法(这是一个没有错误答案的问题)。像大多数面试者一样,候选人会展示他们知道许多技术和软件验证方法。因此,他们可能会无意中添加不必要的测试。

例如,负载测试。为什么这些测试是过度的?很简单——获得的结果将毫无用处,因为我们只获得了测试服务器的流量限制信息。这不会告诉我们任何关于网站在生产环境中的行为。我们还没有讨论可能由其他项目托管的禁用服务器引起的问题。

概率和不确定性

概率和不确定性是导致测试总时间显著增加的常见原因。这些类别意味着什么?

不确定性是任何测试人员在任何项目(新的和旧的)上可能面临的一切。我们是否测试了我们应该测试的一切?有任何功能存在错误吗?如果不处理这种不确定性,那么检查软件的时间将稳步增长。因此,应该始终以不同的方式看待项目:在不同的测试环境中、不同的分辨率下,或基于其他输入数据。

概率是发生错误的可能性。缺陷存在并将永远存在,但它们只在固定时被发现。这意味着,在发现缺陷之前,不能确定它根本不存在。这表明,如果测试人员执行任何检查,它自动增加了发现错误的机会。换句话说,测试就像钓鱼:撒下的网和竿越多,捕获东西的机会就越高。同样,向岸边撒网是不合理的,那里没有机会捕鱼,就像进行不必要的检查一样。

同样,测试的基本原则被违反了,即缺陷的积累。这是一个流行的80/20规则:80%的缺陷基于20%的功能单元。这意味着需要在正确的地方寻找错误。

测试时间

最初,上述所有内容可能看起来与软件测试的本质的初始解释相去甚远。但在其他方面,测试是一种特殊活动,其本质在于减少宝贵时间的损失,因此,预算也减少了。由于缺陷,客户失去了他的时间,并且由于程序员需要一些时间来修复发现的错误,所以财务也受到了损失。因此,增加验证时间,其成本自动增加。在最极端的情况下,测试的成本将增加,如果客户发现了错误,开发者花费的时间编辑错误也将增加。

在这种情况下,测试过程变得完全没有意义。质量保证顾问面临一个明显的矛盾:从测试的角度来看,需要增加检查次数;从商业角度来看,需要减少它们;但同时,不应丢失软件的整体质量。

解决这种情况的方法是全面测试,它总是基于过程的一个基本原则:检查取决于上下文。如果我们有巨大的预算和大量时间,我们测试一切。如果预算很小,我们只检查基本功能。

我们该怎么办?

在这种情况下,我们如何确定什么不能被测试,什么需要通过剩余原则进行检查?当你可以与项目经理讨论和同意测试方法时,这是很好的。但在现实生活中,通常测试人员被要求检查一切,以便无处发现错误。这表明,测试经理将负责编写标准,QA将根据这些标准制定测试操作列表。在制定这些标准时,你可以考虑给定项目的要求、逻辑和对特定功能的访问频率。

要求:我们总是需要为项目的功能制定你的要求清单。有时,它们被称为“隐含要求”,即在文档中不存在但根据实践和逻辑引入的要求。

项目逻辑:每个项目都是个体。它有其目的、功能和目标。如果你理解了目标,你可以很容易地确定需要一些关注的基本功能和辅助功能,然后根据剩余原则测试它们。

用户对功能访问的数量:如果用户倾向于使用特定的浏览器、操作系统或系统平台;那么它们应该首先被测试。如果这是一个正在进行的项目,你很可能会拥有有用的统计数据。如果这是一个新项目,你将不得不考虑关于设备、系统和浏览器普及率的一般想法。

如果我们使用这些原则,我们可以轻松地为任何项目制定测试计划,包括其验证的所有时间段。全面测试方法(像任何其他方法一样)并不意味着你找到了所有的错误。但另一方面,它将确保满足所有要求,基本功能和项目最需要的部分表现良好。