性能测试的过程模型

来源:互联网 发布:同轴电缆传输网络结构 编辑:程序博客网 时间:2024/04/30 09:07

软件性能测试过程详解与案例分析(段念 编著) 学习笔记八

性能测试的过程模型 

PTGM模型是基于自动化测试生命周期方法ATLM(Automated Test Life-Cycle Methodology)和TMap模型,按照ATLM的描述方法对性能测试过程进行建模,PTGM模型是一个结构化的过程模型,见上图;

 

1.测试前期准备

在前期准备阶段,至少要完成两个方面的工作:保证系统稳定和建立合适的测试团队。性能测试一般是软件系统已经开发或是部署完成之后的测试,要求被测对象至少具有一定的稳定性,在功能上基本满足了需求。对一个很不稳定或是还处于“半成品”状态的软件系统进行性能测试,没有太大的意义。

具体来说,测试前期准备包含以下的活动:

(1)系统基础功能验证

该活动类似于系统测试阶段,每个迭代过程中的BVT(Build Verification Test)测试,对性能测试而言,这个活动的主要目的是确保当前需要进行性能测试的应用系统已经具备了进行性能测试的条件;

如果性能测试本身属于验收测试的一部分,只需要把性能测试安排在功能验收测试完成之后即可;如果性能测试不在验收测试阶段进行,则必须保证在性能测试之前进行至少一次系统的功能覆盖测试。

(2)组建测试团队

该活动的目标是建立一个可以进行性能测试的团队。在测试前期准备阶段,需要根据项目的大致情况,确定人员需要的技能,从而从组织中或是通过招聘挑选合适的人员组成测试组。

(3)测试工具需求确认

该活动确定测试工具应该具有的功能特性;在这个活动中,需要根据对被测系统的了解和对测试过程的初步规划,给出测试工具应该具备的功能列表;从以下几方面考虑被测系统和测试工具的适应性:操作系统环境、应用服务器环境、数据库环境、应用使用的协议、网络环境、测试管理支持。

(4)性能预备测试(可选活动)

所谓预备测试,是在正式的测试之前,通过简单的探索性测试或是其他方法,对系统的性能表现进行初步的了解。因为这种预备测试是非正式性的,仅用来对被测系统的性能建立一个初步印象,所以方法上也比较随意,用人工操作和秒表随机抽查部分操作的性能表现即可。

 

2.测试工具引入

性能测试工具在性能测试项目中发挥着不可替代的作用;对性能测试来说,为项目测试选择合适的工具,确定测试工具的使用范围,规定和规范测试工具的使用,都不是一件容易的事情。

测试工具引入阶段包含下列活动:

(1)工具选择

选择的方法是圈定几种可用的工具,为每个工具进行一个功能符合度的评估,选择符合度最高的工具;如果所有的工具都无法达到所要求的功能符合度,则可以考虑通过创建方式自行构建测试中使用的工具;

(2)工具应用技能培训

该活动为项目组的相关参与者进行测试工具的应用技能培训,以使测试活动参与者能够具备测试需要的技能;

该活动需要达到一定的目标,最好能够在活动开始前确定各种角色人员的详细技能标准,并据此给出培训是否达到预定目标的评判准则。培训活动不一定需要组织内部的人员执行完成,可以通过工具的经销商培训或是外部服务等方式完成。

(3)确定工具应用过程

除了工具的应用技能培训外,测试工具引入过程中的另一个重要活动是确定工具的应用过程;

测试工具引入过程中最容易导致的失败就是团队不能达到对测试工具应用范围的一致认可和测试工具应用局限性的一致确认。由于工具经销商常用的夸大和模糊宣传手段,测试工具常常会给不了解的人带来一种“工具无所不能”的印象。如果不能达到这种一致的认识,很容易因测试工具应用的范围发生争执甚至是推诿。

该活动需要确定性能测试工具在测试中的具体应用范围,工具使用过程中的问题解决方法等内容。具体来说,哪些工作使用工具完成?测试工具在使用过程中的问题由谁来解决?测试工具的脚本如何管理?这些问题都应该在这个活动中完成。

 

3.测试计划

测试计划阶段用于生成指导整个测试执行的计划;该阶段主要完成测试目标的确定、测试时间的拟定。建议这个阶段的工作分解为如下活动:

(1)性能测试领域分析

性能测试的应用领域分为“能力验证”、“规划能力”、“性能调优”、“发现缺陷”四个领域,在性能测试计划阶段,首先要执行的活动是根据希望本次性能测试达到的目的,分析出性能测试的应用领域;

测试的目的是明确验证系统在固定条件下的性能能力的,属于“能力验证”领域,该领域常见于对特定环境下部署系统的性能验证测试;测试的目的是了解系统性能能力的可扩展性和系统在非特定环境下的性能能力,属于“规划能力”领域,该领域常见于应用性能可扩展性的测试;测试的目的是通过测试(发现问题)— 调优(调整)— 测试(验证调优效果)的方法提高系统性能能力,属于“性能调优”领域;测试的目的是通过性能测试手段,发现应用的缺陷,属于“发现缺陷”领域。

(2)用户活动剖析与业务建模

用户活动剖析与业务建模活动用来寻找用户的关键性能关注点。用户对系统性能的关注往往集中在少数几个业务活动上,在确定性能目标之前,需要先把用户的这些关注点找出来,从而确定最贴近用户要求的性能目标;

用户活动剖析的方法大体上分为两种:系统日志分析和用户调查分析;系统日志分析是指通过应用系统的日志了解用户的活动,分析出用户最关注、最常用的业务功能,以及达到业务功能的操作路径;用户调查分析是在不具备系统日志分析条件(例如,该系统尚未交付用户运行实际的业务)时采用的一种估算方法,可以通过用户调查问卷、同类型系统对比的方法获取用户最关注、最常用的业务功能等内容;

经过用户活动分析之后,最终形成的结果类似于以下的描述:

用户最关心的业务之一是A业务,该业务具有平均每天3000次的业务发生率,业务发生时间集中在9:00~18:00的时间段内,业务发生的峰值为每小时1000次。A业务的操作路径如下所示:

  ①用户单击“发布公告”链接;

  ②用户在出现的页面中填写公告内容;

  ③用户单击“提交”按钮进行提交。

业务建模是对业务系统的行为及其实现方式和方法的建模,一般采用流程图的方式描述出各进程之间的交互关系和数据流向。对复杂的业务系统来说,业务建模可以将业务系统清晰地呈现出来,为性能测试提供最直观的指导。

(3)确定性能目标

性能测试目标根据性能测试需求和用户活动分析结果来确定,确定性能测试目标的一般步骤是首先从需求和设计中分析出性能测试需求,结合用户活动剖析与业务建模的结果,最终确定性能测试的目标。

性能测试需求的来源可以是多方面的,例如,需求文档、用户备忘录或是用户的邮件中都可能体现出用户对性能的要求。确定性能目标首先要做的就是从这些文档中获取性能需求。

(4)制定测试时间计划

该活动给出性能测试的各个活动起止时间,为性能测试的执行给出时间上的估算。具体方法是根据性能测试活动,为每个活动阶段给出可能的时间估算,最终形成时间上的计划。具体的时间估算方法有很多,例如类比分析方法等。

 

4.测试设计与开发

性能测试的设计与开发阶段包括测试环境设计、测试场景设计、测试用例设计、脚本和辅助工具开发活动。

(1)测试环境设计

测试环境设计是测试设计中不可缺少的环节。性能测试的结果与测试环境之间的关联性非常大,无论是哪种领域内的性能测试,都必须首先确定测试的环境;

在这里所说的测试环境设计包括系统的软/硬件环境、数据环境设计、环境的维护方法。其中,数据环境设计是非常关键但又是最容易被忽视的问题,设想一下,系统运行在一个已有50 000条数据的数据库和一个几乎为空的数据库环境下,其执行查询、插入和删除操作的响应时间显然是不同的;

(2)测试场景设计

测试场景设计活动用于设计测试活动需要使用的场景。在“确定测试目标”活动中,描述了如何确定测试目标,以及测试目标的一般描述,这个活动需要更详细地将测试目标转化为能够在测试执行中使用的内容。

测试场景模拟的一般是实际业务运行的剖面,其包括业务、业务比例、测试指标的目标以及需要在测试过程中进行监控的性能计数器。

下图为某个测试场景的内容

场景名称

场景业务及用户比例分配

测试指标

性能计数器

用户登录

登录业务:100%用户

总用户数200人

响应时间

(<5S)

服务器CPU Usage

服务器内存 Usage

标准日常工作

入账业务:40%用户

查询业务:30%用户

统计业务:30%用户

总用户数200人

响应时间

(入账<6S)

(查询<5S)

(统计<10S)

服务器CPU Usage

服务器内存Usage

。。。

。。。

。。。

。。。

场景可被看作是用户实际运行环境的“剖面”,也就是说,场景体现的是用户实际运行环境中的具有代表性的业务使用情况。用户场景一般由用户在某一个时间段内的所有业务使用状况组成。

上表中描述的测试场景考虑了两种具有代表性的用户业务使用情况:一种是“用户登录”场景,该场景发生在用户每天上班之后的半小时内,此时的用户行为是“全部用户执行登录操作”;另一种是“标准日常工作“场景,该场景用于描述用户的日常工作,在这个场景中,用户执行3种不同的业务,“入账”业务执行用户占40%,“查询”和“统计”业务的执行用户占30%。

(3)测试用例设计

在设计完成测试场景之后,为了能够把场景通过测试工具体现出来,并能用测试工具顺利进行测试执行,因此有必要针对每个测试场景规划出相应的工具部署、应用部署、测试方法和步骤,这个过程就是测试用例设计活动。

测试用例是对测试场景的进一步细化,细化内容包括场景中涉及业务的操作序列描述、场景需要的环境部署等内容。

(4)脚本和辅助工具开发

脚本和辅助工具的开发是测试执行之前的最后步骤,测试脚本是对业务操作的体现,一个脚本一般就是一个业务的过程描述。

除脚本外,测试辅助工具也需要在本活动中进行开发。如在测试中充当“桩模块”或是“驱动模块”的测试辅助工具,有时候还需要提供辅助进行服务器性能监控的脚本作为测试辅助工具。

测试脚本的开发通常基于“录制”,依靠工具提供的录制功能,可以将需要性能测试关注的业务在工具的录制下操作一遍,然后基于该录制后的脚本,对其进行修改和调试,确保其可以在性能测试中顺利使用。最常用的脚本修改和调试技巧是“参数化”、“关联”和“日志输出”。

 

5.测试执行和管理

测试和执行过程用于建立合适的测试环境,部署测试脚本和测试场景,执行测试并记录测试结果。

(1)建立测试环境

该活动用于搭建需要的测试环境,在设计完成用例之后就会开始该活动,该活动是一个持续性的活动,在测试过程中,可能会根据测试需求进行环境上的调整。

建立测试环境活动需要多个团队角色的参与,环境由测试设计人员设计完成,建立测试环境的活动由测试实施人员按照设计的要求组织建立,团队中的支持角色负责协助测试实施人员。

建立测试环境一般包括硬件、软件系统环境的搭建,数据库环境建立,应用系统的部署,系统设置参数的调整,以及数据环境准备几个方面的工作内容。

(2)部署测试脚本和测试场景

在建立合适的测试环境之后,接下来的工作是部署测试脚本和测试场景。部署测试脚本和测试场景活动通过测试工具本身提供的功能来实现;

对脚本和场景的部署需要熟悉测试工具的人员来完成,在过程模型中,该活动由测试实施人员进行。在场景部署完成后,一般需要一个确认步骤,在该步骤中,测试设计人员确认场景部署与预期的设计一致。

部署活动最终需要保证场景与设计的一致性,保证需要监控的计数器都已经部署好了相应的监控手段。

(3)执行测试和记录结果

准备好环境和部署好测试脚本以及场景后,就可以执行测试并记录测试结果了。在测试工具的协助下,测试执行是非常简单的操作,一般只需要使用菜单或是按钮就可以完成;记录测试结果也可以依靠测试工具完成,通过测试工具的监控模块,可以获取并记录需要关注的性能计数器的值。

在测试工具本身不提供对需要关注的性能计数器进行监控的功能时,可以用一些操作系统的工具,自行编制部分脚本解决这个问题,一般地方法是用脚本调用操作系统提供的工具,在脚本实现中将各性能计数器值分析出来并按照一定格式记录在本地文件中。

 

6.测试分析

测试分析过程用于对测试结果进行分析,根据测试的目的和目标给出测试结论。

性能测试的挑战性在很大程度上体现在对测试结果的分析上,可以说,每次性能测试结果的分析都需要测试分析人员具有相当程度的对软件性能、软件架构和各种性能指标的了解。

性能测试的分析需要借助各种图表,一般地性能测试工具都提供了报表模块来生成不同的图表,报表模块同时还允许用户通过叠加、关联等方式处理和生成新的图表。如果是采用自己编写的脚本获取性能计数器的值,则可以通过Excel等数据处理软件生成图表。

 

性能分析的通用方法之一是“拐点分析”的方法。“拐点分析”方法是一种利用性能计数器曲线图上的拐点进行性能分析的方法,该方法的基本思想是基于这个事实:性能产生瓶颈是由于某个资源的使用达到了极限,此时的表现是随着压力增大系统性能表现急剧下降,因此,只要关注性能表现上的“拐点”,获得“拐点”附近的资源使用情况,就能够定位出系统的性能瓶颈。“拐点分析”的方法在确定引起系统瓶颈的系统资源方面能发挥一定作用,但由于其只能定位到资源上的制约,而不能直接定位到引起制约的原因,因此。该方法还必须配合其他方法使用,才能最终确定真正引起性能瓶颈的最根本原因。可用于进行“拐点分析”的图标包括“负载—响应时间曲线”、“负载—吞吐量曲线”等。

原创粉丝点击