软件测试中的稳定性测试

什么是稳定性测试?
稳定性测试 是一种非功能性软件测试,用于测量软件应用程序长期持续运行的效率和能力。稳定性测试的目的是通过充分发挥其使用范围来检查软件应用程序是否在任何时间点因正常使用而崩溃或失败。
稳定性测试是为了检查已开发产品的效率,超出正常运行能力,通常是断点。与检查正常情况下的系统行为相比,稳定性测试更注重产品在重负载下的错误处理、软件可靠性、稳健性和可扩展性。
稳定性测试评估稳定性问题。此测试主要是为了最大限度地强调软件组件。它是一种非功能性技术。

稳定性测试也称为负载或 耐久性测试.
如果测试系统未经过稳定性测试,则存在风险
对于引入大量用户且需要连续运行数月而无需重新启动的被测应用程序,可能会出现许多问题:
可能面临的错误,
- 系统变慢
- 系统遇到功能问题
- 系统表现出有线行为
- 系统彻底崩溃
在软件工程中, 稳定性测试 通常涉及与重度用户(虚拟)一起测试系统并测量性能参数以验证系统是否能够支持预期的负载。
为什么要做稳定性测试
这种测试有助于用户了解系统在现实生活中的工作方式。
因此,稳定性测试可以让你检查,
- 对被测系统的稳定性充满信心。
- 确保您的系统可以处理大型程序。
- 监控系统的有效性。
- 测试压力下的系统稳定性。
它在产品开发中发挥着重要作用,因为它用于确定被测软件产品发布前的局限性,或者产品上线或生产前需要进一步改进的领域。
稳定性测试技术的一个非常常见的例子是
On线 S跳ping Portals:稳定性测试将检查网站在以下情况下的表现:
- 高峰时段输入的数据量很大
- 特定时间的点击次数
- 同时出现页面加载问题
- 系统行为
- 系统的响应能力和其他许多方面都 稳定性测试
另一个例子
A 中央处理器 测试是一种流行的稳定性测试形式 性能测试 技术。此测试检查处理器的稳定性,并在处理器的工作负载增加时监控其性能。
如何进行稳定性测试
- 为了确定测试的范围和目标,我们必须确保应用服务器在负载测试执行期间不会崩溃。
- 要确定业务问题,请根据最终用户的角度验证系统性能和负载。
- 分配不同的职责和角色,如创建测试计划, 测试用例 设计、测试用例评审、测试执行等。
- 确保在规定时间内交付测试成果
- 确保正确 负载测试 工具和经验团队也同样存在。
- 衡量测试涉及的风险和成本。这将确定每次执行在 CPU 利用率和内存方面的成本。
- 确定 缺陷 trac国王、报告以及他们正确的地图ping 符合要求。
CPU 性能稳定性测试用例
- 验证系统的上限。
- 系统如何崩溃或恢复。
- 每个请求完成的交易总数。
- 交易响应是否保持稳定或随着时间的推移而增加。
- 系统在重负载下如何运行。
- 重载下它的响应和行为。
稳定性测试报告
在测试执行期间会收集并测量一些统计数据;分析这些数字以生成报告并识别可能的性能问题。
测试中收集的统计数据示例如下:
- 交易响应时间:测试期间执行事务的平均时间。此统计数据将评估服务器的性能是否在系统定义的可接受的最小和最大事务性能时间段内。此信息将评估 Web 服务器处理请求并发送到应用程序服务器所花费的时间,在大多数情况下,应用程序服务器将向数据库服务器发出请求。
- 每秒点击次数: 用户对服务器的点击次数。这些统计数据有助于确定用户相对于点击次数产生的负载数量。
- 速率: 测试期间 Web 服务器上的吞吐量,以字节为单位。吞吐量是指用户在任何给定时间从服务器接收的数据量。此统计数据有助于评估用户产生的负载量。
- 每秒交易数: 这是测试期间执行的已完成事务(成功和失败)的总数。此统计信息有助于检查系统上的实际事务负载。
- CPU: 测试期间 CPU 的利用率百分比。
- 记忆: 测试期间的内存使用情况。
- 磁盘: 测试期间所用的磁盘空间的利用率。
稳定性测试基础知识
稳定性测试 属于性能测试——一种用于检查软件的某些质量属性(如稳定性、可靠性和可用性)的技术。
此测试用于确定系统或子系统在特定工作负载下的运行速度。
性能测试有很多种类型,稳定性测试是其中之一。
- 压力测试: 它是一种超出系统容量检查系统稳健性的测试类型。
- 尖峰测试: 它用于通过立即增加系统负载来检查系统的行为。目的是检查系统在什么时候会出现性能问题,或者系统会通过。
- 可扩展性测试: 它用于检查系统的功能。系统在需求增长、规模变化和容量变化时将如何有效运行。
- 容量测试: 它是一种非功能性测试技术,其中被测软件会受到大量数据的影响,并相应地检查和验证系统的行为。
- 负载或稳定性测试:(上面已经讨论过)
稳定性测试工具
性能测试的一些工具如下:
此测试如何融入性能测试系列
性能测试是一个统称。以下列出的各种测试方法仅在施加的载荷形式和保持时间上有所不同,因此它们经常被混淆。
| 测试类型 | 负载模式 | 它解答的问题 |
|---|---|---|
| 负载测试 | 预计峰值负荷,持续时间短 | 在正常高峰交通流量下,该系统能否达到其目标? |
| 压力测试 | 超出负荷直至失效 | 它会在哪里出现故障?故障发生时是否体面? |
| 尖峰测试 | 突然的极端激增,然后是撤退 | 它能否在交通冲击后幸存并恢复? |
| 耐力测试 | 正常负荷持续数小时 | 性能会随着时间推移而下降吗? |
| 浸泡测试 | 长时间持续负荷 | 是否存在内存泄漏或资源耗尽? |
| 稳定性测试 | 不同条件下的负载变化 | 随着环境变化,系统是否仍能保持可靠性? |
| 容量测试 | 普通用户,数据量非常大 | 随着数据库的增长,它能否应对? |
耐久性测试和浸泡测试经常被视为同义词。 通常来说,耐久性测试和负载测试都是长时间持续高负载运行的测试。如果团队确实区分这两者,耐久性测试侧重于响应时间是否会逐渐延长,而负载测试则侧重于内存、文件句柄和连接池等资源消耗。运行其中一项测试通常就能提供这两项测试的结果。
测试期间需要收集的关键指标
性能测试的质量取决于测试过程中记录的数据。请在服务器端和客户端分别记录这六项数据,然后将其与基准数据进行比较,而不是仅凭直觉判断。
| 米制 | 它告诉你什么 | 警告牌 |
|---|---|---|
| 平均响应时间 | 典型用户体验 | 任何向上的漂移都会影响跑步路线。 |
| 第 95 百分位响应时间 | 最慢用户的体验 | 远高于平均水平,意味着不稳定 |
| 生产能力 | 每秒处理的请求数 | 负载保持不变时发生坠落 |
| 错误率 | 失败或超时请求的占比 | 任何超过约定阈值的涨幅 |
| CPU 和内存使用情况 | 服务器资源余量 | 攀登而永不复返的记忆 |
| 数据库连接和线程 | 泳池耗尽 | 数量持续增长,却未释放 |
请将平均值和百分位数一起阅读。 平均延迟 800 毫秒,第 95 百分位数为 900 毫秒,表明系统运行稳定。如果平均延迟 800 毫秒,第 95 百分位数为 9 秒,则意味着每 20 个用户中就有 1 个用户体验不佳,而平均值掩盖了这一问题。
注意形状,而不仅仅是数值。 在任何长时间运行的测试中,资源消耗曲线平稳表示测试通过,而资源消耗曲线上升则表示测试存在泄漏,即使在测试结束时绝对值仍然在限制范围内。
