web 性能测试用例设计以及总结 -凯发app官网

基于用户的测试多在用户现场进行，为了测试目的而进行的测试多在开发环境即开发团队的内部进行。为了测试目的而设计的测试用例场景主要根据测试设计人员的经验来进行，但是仍要参考用户的实际场景，用户实际使用场景是设计所有测试用例的依据。文章源自玩技e族-https://www.playezu.com/17589.html

性能测试用例设计首先要分析出用户现实中的典型场景，然后参照典型场景进行设计。文章源自玩技e族-https://www.playezu.com/17589.html

文章源自玩技e族-https://www.playezu.com/17589.html

1. 确定用户使用系统情况的方法文章源自玩技e族-https://www.playezu.com/17589.html

确定用户对系统的使用情况是设计用例具体数据的基础，后面并发用户数据设计，疲劳强度设计以及各种场景设计都要依赖对用户使用系统情况的分析，分析用户使用情况经常采用现场调查和分析系统日志两种方法：文章源自玩技e族-https://www.playezu.com/17589.html

用户现场调查：通过和用户进行沟通，可以确定用户的人员组成情况，这类方法适用于用户群体固定且目标测试系统没有投产前的情况。文章源自玩技e族-https://www.playezu.com/17589.html

分析系统日志：当用户比较分散，现场调查比较困难时，可以采用对系统日志进行分析的方法，作为对用户现场调查的补充。文章源自玩技e族-https://www.playezu.com/17589.html

2. 并发用户数量设计文章源自玩技e族-https://www.playezu.com/17589.html

设计并发用户数量前，首先要了解确定系统最大并发用户数量的方法可，以根据系统的最大使用人数或者最大在线数量来评估最大并发用户数量的方法：文章源自玩技e族-https://www.playezu.com/17589.html

极限法：取最大在线用户数作为最大并发数，这种方法适用于系统已经投产目标用户群体不确定的门户网站，可以通过分析日志来进行测试，也可以使用系统已经注册的用户数量作为系统的用户数量，按照经验公式来估算最大用户数量。文章源自玩技e族-https://www.playezu.com/17589.html

用户趋势分析：对软件生存周期内的用户未来走势进行分析，预测系统可能达到的最大使用用户数目，从而估算系统的最大并发用户数目，这种方法多用于用户数目逐渐增多的情况。文章源自玩技e族-https://www.playezu.com/17589.html

经验评估法：多用于系统的使用用户数目相对稳定而且比较明确的系统。文章源自玩技e族-https://www.playezu.com/17589.html

并发用户数量的设计基本是按照最大并发用户的数量的百分比来设计的，对于某一特定的用例，需要注意：文章源自玩技e族-https://www.playezu.com/17589.html

一、按照各类用户同时递增的方式来设计用户数量，是为了按照由浅入深的方法来发现系统的瓶颈；文章源自玩技e族-https://www.playezu.com/17589.html

二、并发用户的最大值一般不会超过前面计算的最大并发用户数量的 20% ，除非是为了测试系统能支持的最大并发用户数量；文章源自玩技e族-https://www.playezu.com/17589.html

三、设计用户数量时要考虑成本，因为每组用户数都意味着至少执行一次测试；文章源自玩技e族-https://www.playezu.com/17589.html

文章源自玩技e族-https://www.playezu.com/17589.html

3. 系统不同时间段场景的设计文章源自玩技e族-https://www.playezu.com/17589.html

不同时间段的场景更接近用户使用情况，它也是设计核心模块和组合模块并发性能测试用例的基础，不同时间段场景分析的数据主要是前面的需求分析和日志分析结果。文章源自玩技e族-https://www.playezu.com/17589.html

不同时间段场景的设计基本原则有两个：一是选择典型的场景进行测试，尤其要选择场景中并发用户数目较大的场景；二是要覆盖全面，设计出的用例要覆盖到压力可能较大的时间段，用户场景的设计一般与后面的业务模式结合起来进行。文章源自玩技e族-https://www.playezu.com/17589.html

4. 业务模式的设计文章源自玩技e族-https://www.playezu.com/17589.html

业务模式的设计是不同时间段场景设计的特例，也是设计核心模块和组合模块并发性能测试用例的基础，设计业务模式的目的是专注于某些功能模块的组合，按时间段来设计场景通常会涉及很多模块，如果系统存在的由应用软件引起的瓶颈则很难定位，所以才抽象一些特定的业务模式来进行用例的设计。文章源自玩技e族-https://www.playezu.com/17589.html

按照业务模式和时间段的场景来设计性能测试用例时，会涉及到如何设计每个模块并发用户数目的问题，通常会取各个相关模块在24小时内最大的并发用户数目进行组合。文章源自玩技e族-https://www.playezu.com/17589.html

5. 大数据量测试用例的设计文章源自玩技e族-https://www.playezu.com/17589.html

历史数据相关的大数据量测试设计与并发用户的测试设计很类似，首先要确定系统数据的最长迁移周期，确定了系统的最大数据量后，接下来选择一些前面的核心模块或者组合模块的并发用户测试用例作为其主要内容即可。文章源自玩技e族-https://www.playezu.com/17589.html

运行时大数据量测试主要根据模拟系统运行时可能产生的大数据量来进行测试，这类测试用例通常根据实际情况去分析设计。文章源自玩技e族-https://www.playezu.com/17589.html

6. 一些特定测试用例的设计文章源自玩技e族-https://www.playezu.com/17589.html

疲劳强度测试，最大用户测试，容量测试等一些特殊的测试用例设计，根据用户的需求进行，这类用例的相关要求通常十分明确。文章源自玩技e族-https://www.playezu.com/17589.html

性能测试用例最重要的是注意用例间的关系，孤立的设计各类用例只能增加测试成本，浪费人力。性能测试用例设计人员应该追求设计既能覆盖性能测试需求，又能以较低的成本来执行测试用例。文章源自玩技e族-https://www.playezu.com/17589.html

文章源自玩技e族-https://www.playezu.com/17589.html

 文章源自玩技e族-https://www.playezu.com/17589.html

1. 测试用例可用性总结文章源自玩技e族-https://www.playezu.com/17589.html

对于一个比较完善的性能测试项目，经常会有一些测试用例不能执行，因此测试完成后应该分析哪些用例不能执行以及不能执行的原因，这样可以为下次测试打好基础。文章源自玩技e族-https://www.playezu.com/17589.html

2. 用例执行效果分析文章源自玩技e族-https://www.playezu.com/17589.html

通过对用例执行效果进行分析，可以为升级或者开发新的性能测试用例提供有利的参考，不是所有的用例都能导致系统瓶颈的出现，因此应该分析哪些用例能够发现系统问题，那些用例执行时没有太大效果。文章源自玩技e族-https://www.playezu.com/17589.html

分析那些设计好的用例不但有助于以后设计用例，还可以为再次执行提供参考，当下次测试进度压力较大时可以先执行重要的用例，跳过那些尝试性的，不容易发现问题的用例。文章源自玩技e族-https://www.playezu.com/17589.html

3. 用例执行时间分析文章源自玩技e族-https://www.playezu.com/17589.html

分析用例的执行时间是为下次规划性能测试提供参考，由于很多用例执行时间不是特别确定，导致性能测试计划也具有一定的不确定性，通过分析用例的执行时间可以为以后的制定测试计划提供参考。文章源自玩技e族-https://www.playezu.com/17589.html

总之，性能测试用例的设计是需要通过不断分析总结才能做好，不但要分析性能测试用例的可用性、执行效果、执行时间，还应该分析用例的设计方法、设计思路等。文章源自玩技e族-https://www.playezu.com/17589.html