性能测试用例设计

歪小Y_02

性能测试在软件质量保证中起着重要的作用，它包括的测试内容丰富多样。同一个系统，不同的测试设计及测试过程会导致不同的结果，也会有不同的解读。合理的测试规划与设计是至关重要的。本文重点介绍如何结合用户实际业务特点制定有效的性能测试用例。
　　一、系统业务特点和用户行为分析

　　用户行为反映了用户对系统的使用模式和应用背景，在性能测试之前，我们首先需要分析用户的使用习惯，确定系统的典型业务及发生时间。分析用户行为是设计性能测试用例的第一步。

　　1、系统使用高峰时段分析

　　对于很多大型系统，都有业务集中开展使用的情况出现，即系统使用的高峰。这类系统使用高峰可能出现在一天、一月、一年中的某个时间点上或时间段上。例如在同一天内，大多数系统的使用情况都会随着时间发生变化，对于这一类系统不同的业务高峰对应的时间也不同。例如对于新浪、网易等门户网站，在周一到周五早上刚一上班时，可能邮件系统用户比较多，而上班前或者中午休息时间则浏览新闻的用户较多；而对于一般的OA系统则早上阅读公告的较多，其他时间可能很多人没有使用系统或者仅有少量的秘书或领导在起草和审批公文。电信缴费系统很可能在月末会出现集中交费的情况。计生委的特别扶助等个案信息上报一般集中在每年的某个月份进行。

　　确定系统使用高峰时段，有利于我们进一步确定系统在高峰时段的性能需求，比如高峰时段的并发用户支持需求，高峰时期的业务响应时间需求等。

　　2、系统高峰期业务应用分析

　　在系统不同的高峰期，同一系统可能会处于不同的业务模式，因此需要对系统高峰期的业务应用进行分析。其目标是为了通过分析高峰期的应用来确定高峰期的业务应用模型是单一业务类型还是混合业务类型，这对于后期的测试用例执行策略的设计至关重要。例如很多电子商务系统在早上8点到10点以浏览模式为主，10点到下午3点以定购模式为主，而在下午3点以后可能以混合模式为主。因此需要分析哪些业务应用是典型的即压力较大的业务，进而对这些业务应用单独进行测试，这样做可以有效的对系统瓶颈进行隔离定位。

　　二、系统性能指标分析

　　合理的设计不可能是凭空想象，而是要基于系统的业务需求及用户使用习惯。在性能测试中，最重要的两个指标是确定系统需要承受的并发用户数量，及在一定的用户规模下系统能够提供的应用响应时间。

　　下面重点介绍一下如何对并发用户数量和平均事务响应时间这两个性能指标进行设计：

　　1、并发用户数量设计

　　并发用户数设计必须以系统真实使用中可能出现的最大用户数为基础进行核算。下面介绍根据系统的最大使用人数或者最大在线人数来评估最大用户数的方法。

　　a）极限法

　　对于系统已经投产或者目标用户群体不确定的门户网站，可以通过分析日志，也可以使用系统已经注册的用户数量做为系统最大用户数，然后按照经验公式来估算最大并发用户数。

　　b）用户趋势分析

　　对软件生存周期内的用户未来走势进行分析，预测系统可能达到的最大用户数，从而估计系统的最大并发用户数，这种方法多用于系统用户数目逐渐增加的情况。

　　c）经验评估法

　　按照经验来评估系统可能的最大并发用户数，这种方法多用于系统的使用用户数目相对稳定且比较明确的系统。

　　并发用户数的设计基本是按照系统最大用户数的百分比来设计的，对于某一特定用例，需要注意并发用户设计的最大值一般不会超过前面计算的系统实际使用的最大用户数的30% ，除非是为了测试系统能支持的最大并发用户数量。

　　2、事务平均响应时间

　　响应时间就是用户感受软件系统为其服务所耗费的时间，这与计算机性能、网络速度和带宽等等有关。设计事务平均响应时间指标也是性能测试用例设计的重要内容。

　　目前关于事务平均响应时间指标设计基本可参考以下2种方式：

　　对于在需求分析和设计阶段已经明确提出响应时间性能指标要求的系统，如要求”系统响应时间不得超过20秒”，平均响应时间确定应以需求为准。

　　对于没有明确性能需求的系统，事务平均响应时间应以用户使用感受或者需求方指定为准。一般来讲有3秒以内用户会认为响应时间较快；5秒以内用户认为可以接受，超过8秒，一般用户会认为响应太慢。当然响应时间的长短还和业务类型紧密相关，提交类业务操作对响应时间要求一般而言比统计类的业务操作要求更高。

　　其他性能指标的设计可以采取事务平均响应时间指标相同的设计方式来进行。

三、性能测试执行策略分析
　　性能测试执行策略需要注意两点：一是选择典型的业务进行测试，尤其要选择并发用户数目较大的业务；二是要覆盖全面，即设计出的用例要覆盖到系统高峰期的主要业务。在性能测试执行过程中，明确每个业务的参与者人数、比例和具体行为是非常重要的，这些都是性能测试用例设计的基础。下面重点介绍一下如何制定单业务测试、混合业务测试和疲劳强度测试的具体执行策略。

　　1、单业务测试

　　性能测试不可能对所有功能都进行测试，所以需要抽象一些特定的独立业务来进行用例的设计。独立业务实际是指一些核心业务模块对应的业务，这些模块通常具有功能比较复杂，使用比较频繁，属于核心业务等特点。针对这类独立业务进行的性能测试称之为单业务性能测试。

　　用户并发能力测试是单业务性能测试的重点，用户并发能力测试是指模拟一定数量的用户同时使用某一核心模块的相同或者不同的功能，并且持续一段时间，考察系统能够支持指定的用户规模。

　　2、混合业务测试

　　在系统真实应用中，通常不会存在所有用户只使用一个或者几个核心业务模块的情况，即一个应用系统的每个功能模块都可能被使用到；所以性能测试既要模拟多用户的相同操作，又要模拟多用户的不同操作。

　　混合业务性能测试是最接近用户实际使用情况的测试，也是性能测试的一个必要内容。在混合业务测试中，通常需要按照用户的实际使用人数比例来模拟各个模块的组合并发情况。混合业务测试的突出特点是根据用户使用系统的情况分成不同的用户组进行并发，每组的用户比例要根据实际情况来匹配，通常会取各个相关模块最大的并发用户数目进行组合。

　　以下为一个混合测试用例实例：


3、疲劳强度测试

　　疲劳强度测试是指在系统正常运行的情况下，以一定的负载压力来长时间运行系统的测试。疲劳强度测试的主要特点是长时间对目标测试系统加压，目的是测试系统的稳定性，持续时间一般在1小时以上；疲劳强度测试属于用户并发测试的延续，因此核心内容仍然是核心模块用户并发和组合模块用户并发，在编写测试用例时需要编写不同参数或者负载条件下的多个测试用例，可以参考混合业务并发性能测试用例的设计内容，通常修改相应的场景参数就可实现所需要的测试用例。

总结

　　本文重点讨论了如何结合用户实际业务特点制定有效的性能测试用例，通过分析用户实际业务特点来设计性能测试，可以使性能测试用例更接近用户实际使用情况，更容易发现系统瓶颈。这种方法抓住了性能测试的关键点，做到有的放矢，大大降低了测试成本。

qqq911

感谢分享

Miss_love

感谢分享