性能测试常见风险以及消减措施

性能测试过程中会遇到各种各样的风险，常见风险以及消减措施有哪些？

一： 时间

一）时间相关风险

时间相关风险不仅限于最终用户满意度,尽管这是大多数人首先想到的。时间也是某些与业务和数据相关的风险因素。性能测试可以解决的最常见的时间相关风险包括:

1. 应用程序是否够快以满足最终用户?

2.业务是否能够在数据过时之前处理和利用应用程序收集的数据?(例如,月末报告应在月底最后一天营业后24小时内完成,但应用程序需要48小时来处理数据。)

3. 应用程序是否能够向其用户呈现最新的信息(例如,股票报价)?

4. Web服务是否在抛出错误之前响应了最大预期响应时间?

二）缓解时间相关风险的策略

以下策略在缓解速度相关风险方面很有价值:

1.确保您的性能要求和目标代表您的用户的需求和愿望,而不是其他人的需求和愿望。

2.将您的速度测量结果与以前的版本和竞争对手的应用程序进行比较。

3.设计可以在正常和预期峰值时段复制实际工作负载的负载测试。

4.在实际生产期间与业务操作中使用的类似数据类型、分布和体量进行性能测试(例如,产品数量、待定订单状态的订单数量、用户基数的大小)。您可以在负载测试执行之前允许数据在数据库和文件服务器中累积,或者额外创建数据量。

5.使用性能测试结果帮助利益相关者做出明智的架构和业务决策。

6.在系统处于预期最大负载时,征求代表用户对系统满意度的反馈。

7. 在您的性能测试中包括时间关键事物。

8. 确保至少有一些性能测试是在定期系统进程执行时进行的(例如,下载定义更新或每周备份期间)。

9. 在各种条件、负载级别和场景组合下测量速度。(用户重视稳定的速度。)

10. 验证在您的性能测试期间显示和保存了所有正确的数据。(例如,用户更新信息,但确认屏幕仍显示旧信息,因为事务尚未完成写入数据库。)

二：可扩展性

一）扩展性相关风险

扩展性风险不仅涉及应用程序可以支持的用户数量,还涉及应用程序可以包含和处理的数据量,以及识别应用程序何时接近容量的能力。性能测试可以解决的常见扩展性风险包括:

1. 应用程序是否可以为 所有 用户基数提供一致和可接受的响应时间?

2. 应用程序是否可以存储在应用程序生命周期内收集的所有数据?

3. 是否有警告迹象表明应用程序即将达到最大容量?

4. 在高强度使用下,应用程序是否仍然安全?

5. 在高强度使用下,功能是否会受到损害?

6. 应用程序是否能够承受意外的峰值负载?

二）缓解扩展性相关风险的策略

以下策略在缓解扩展性相关风险方面很有价值:

1. 比较在各种负载下测量的速度。(请记住,最终用户不知道或不在乎其他人在同一时间使用应用程序的人数。)

2. 设计可以在正常和预期峰值时段复制实际工作负载的负载测试。

3. 在实际生产期间与业务操作中使用的类似数据类型、分布和体量进行性能测试(例如,产品数量、待定订单状态的订单数量、用户基数的大小)。您可以在负载测试执行之前允许数据在数据库和文件服务器中累积,或者额外创建数据量。

4. 使用性能测试结果帮助利益相关者做出明智的架构和业务决策。

5. 与更有意义的性能测试合作,这些测试映射到现实世界的要求。

6. 当您找到扩展性限制时,逐渐减少负载并重新测试,以帮助您识别可作为您及时采取对策的可靠指标的指标。

7.通过检查在各种负载下创建的数据库条目或验证对特定用户请求的响应返回的内容来验证应用程序的功能准确性。

8.进行超出预期峰值负载的性能测试,并通过让代表性用户和利益相关者在性能测试期间和之后手动访问应用程序来观察行为。

三： 稳定性

一）稳定性相关风险

稳定性是一个总括术语,涵盖可靠性、正常运行时间和恢复性等方面。尽管稳定性风险通常通过高负载、耐久性和压力测试得到解决,但稳定性问题有时也会在最基本的性能测试中检测到。性能测试可以解决的一些常见稳定性风险包括:

1. 应用程序是否可以长时间运行而不会数据损坏、减速或服务器需要重启?

2. 如果应用程序意外关闭,部分完成的事务会发生什么?

3.当应用程序在计划内或计划外停机后重新上线时,用户是否仍然能够看到/做他们期望的一切?

4. 当应用程序在非计划停机后重新上线时,它是否在正确的点上恢复?特别是,它是否不会尝试恢复已取消的事务?

5. 错误或重复的功能错误组合会导致系统崩溃吗?

6.是否有任何事务会导致系统范围的副作用?

负载平衡环境的一条腿是否可以关闭而仍然为用户提供不间断的服务?

7.系统是否可以在不关闭的情况下打补丁或更新?

二）缓解稳定性相关风险的策略

以下策略在缓解稳定性相关风险方面很有价值:

1. 为现实的耐久性测试留出时间。

2. 使用关键场景进行压力测试。使用关键性能指标(网络、磁盘、处理器、内存)和业务指标(丢失的订单数量、用户登录失败等)。

3. 与实际生产环境中的类似业务操作一起进行压力测试(例如,产品数量、待定订单状态的订单数量、用户基数的大小)。您可以在压力测试执行之前允许数据在数据库和文件服务器中累积,或者额外创建数据量。这将允许您复制关键错误,例如数据库或应用程序死锁以及其他压力故障模式。

4. 在测试期间关闭一台服务器,并观察剩余系统的功能、性能和数据完整性行为。

5.在系统重新启动之前和之后立即执行相同的测试。比较结果。您可以对服务或进程的循环使用相同的方法。

6. 在您的性能测试方案中包括错误或异常案例(例如,用户试图使用不正确的凭据登录)。

7. 在性能测试期间打补丁系统。

8. 在性能测试期间强制备份。

行动吧，在路上总比一直观望的要好，未来的你肯定会感 谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，请及时加入扣群： 320231853，里面有各种软件测试+开发资料和技术可以一起交流学习哦。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

​

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！