zoukankan      html  css  js  c++  java
  • 性能测试基础---文档编写

    ·性能测试文档的编写:
    一般来说,性能测试过程中,文档主要是两个:
    ·计划&方案
    ·性能测试报告

    ·计划&方案:
    ·计划:定义什么人什么时候完成什么工作
    ·方案:工具具体怎么完成。

    一般来说,性能测试的计划和方案的编写和普通的测试计划方案是没有太大的区别。
    通常包含以下要点:
    ·概述
    ·项目背景
    ·测试目的
    ·测试内容
    ·测试人员
    ·计划安排
    ·测试工具
    ·测试环境
    ·测试方案
    ·测试用例
    ·输入文档
    ·输出文档
    ·测试风险
    ·名词解释

    ·概述:
    通常用来简要的描述本次性能测试活动相关的信息。
    一般来说,主要包含要做什么事,希望解决什么问题,文档的受众等。

    ·项目背景:
    一般来说,直接从项目计划文档中复制即可,最多做一下性能方向的细化。

    ·测试目的:
    一般来说,通常就是用来描述本次测试的目的。
    一般来说,测试目的有两个:
    ·检测:交付或者上线之前,没有暴露性能问题之前,都是以检测。

    ·分析定位调优:通常来说就是系统已经知道存在性能问题。
    PS:很多时候,则是两个目的都有。

    ·测试内容:
    通常就是用来对被测系统的业务内容进行分析,标注业务的功能和性能优先级,最终将业务分为待测和不测业务。
    将业务分解之后,接下来一般是需要针对不同的业务,拟定性能需求(响应时间和TPS)
    PS:如果是给客户,响应时间是越大越好。如果是内部测试,响应时间是越小越好。

    ·测试人员:
    这里是用来描述整个性能过程中的干系人及其工作职责。
    常见的有:
    ·项目经理(测试经理):负责资源调度、人员协调
    ·性能测试人员:负责性能测试活动,包含但是不限于:
    计划、方案的编写、测试环境的搭建、测试数据的准备、脚本开发、场景设计和执行、资源监控、数据分析、定位瓶颈、提出调优建议(直接调优)。
    ·IT运维:一般提供环境相关的支持,包括硬件资源的分配、系统和软件的安装、网络的配置、资源监控等。

    ·DBA:一般是提供数据库相关的支持,包括数据结构的分析、监控等。

    ·开发对接人员:一般是提供技术支持。

    ·架构设计人员:一般是提供技术支持,通常是全局性的架构层面的技术支撑。

    PS:严格来说,应该都要有备选人员。


    ·计划安排
    一般来说可以考虑以类似于甘特图的方式来描述,也可以直接用二维表格来实现。
    主要是要包含性能测试过程中所有可以量化的工作的时间节点及相关责任人。

    任务 完成时间 责任人
    需求调研和分析 xxxx-xxxx XXX


    ·测试工具
    不是简单的就是说使用XX工具。
    这里要对测试工具进行可行性分析,可行性分析通常包含以下几点:
    ·功能的可行性:工具本身能否胜任测试需求。
    ·成本:
    ·技术的可行性:
    ·工具的学习使用成本。
    ·培训成本。


    ·测试环境:
    通常来说,就要包含客户端(压力机)和服务器端的软硬件信息,以及测试环境的整体网络拓扑结构图。
    ·图
    ·表:一般可以按下列方式编写:
    编号 用途 IP地址 硬件配置 操作系统及相关软件
    1 压力机 192.168.1.100 CPU型号/主频 os类型、JDK1.8,jmeter4.0,其他测试过程中需要用到的工具
    内存大小
    磁盘大小
    2 服务器 192.168.1.200 CPU型号/主频
    内存大小
    磁盘大小

    PS:凡是可能对性能造成影响的软件都要描述。

    ·测试方案:
    又可以叫测试策略,描述针对测试需求,所设计的性能测试策略,通常就会包含不同类型的性能测试:
    ·负载测试:
    ·压力测试:
    ·容量测试:
    ·基准测试:
    ·并发测试:
    ·配置测试:

    ·测试用例:
    在性能测试中,测试用例通常是分为两部分:脚本和场景
    ·脚本:
    通常就是根据测试内容来生成。
    通常一个业务至少要有一个脚本,可能会有多个脚本。
    一般,一个脚本描述中包含以下信息:
    ·脚本编号、脚本名称(概要)、业务流程、作用(用于哪些测试)。
    同时会标注:参数化、事务、检查点、思考时间、集合点。

    ·场景:
    一般都是以二维表的方式来设计:
    场景编号or名称:登录1
    场景目的:测试10个在线用户情况下,登录业务的各项性能指标是否符合需求。
    运行脚本:登录1
    场景设计:
    用户数:10个
    启动方式:每隔5s启动一个用户
    持续时间:6分钟
    退出方式:每隔5s退出一个用户
    思考时间策略:1~5s
    集合点:无
    联机负载:无
    IP欺骗:无
    资源监控:这里主要标注需要监控的资源对象有哪些
    比如说,监控XX服务器的CPU、内存、带宽和磁盘使用情况等。

    一般来说,根据负载模型,通常一个业务脚本的执行场景都会有三个。

    ·输入文档:
    项目计划书、需求文档、概要设计、详细设计、测试计划等。
    ·输出文档:
    测试脚本、测试计划&方案、测试数据等
    ·测试风险:
    所谓风险就是有可能导致工作无法按时按质完成的因素。
    常见的风险来源于:人力、物力相关方面。
    人力:辞职、生病、其它优先级更好的工作等。
    物力:硬件、
    技术层面:

    PS:识别风险之后,要给出风险的解决方案。

    ·名词解释:


    ·性能测试报告:
    一般来说,报告都是属于活动结束的产出物,它彰显了对于该工作的完成程度。
    因此对于性能测试报告而言,必须符合以下几点:
    ·内容充实
    ·注意排版
    ·条目清晰(一般不要超过三级)
    ·虎头虎尾。


    ·性能测试报告一般根据性能测试目的的不同可以分为两种类型(也有可能混合):
    ·陈述性报告:对应的测试目的是检测系统的性能是否符合需求。
    ·描述活动、结果、结论即可。

    ·分析型报告:对应的测试目的是分析、定位和调优。
    不能只是简单的罗列数据,必须要对数据进行加工处理,描述分析原理和分析思路。
    包括数据的整理(变成信息)、结论以及解决方案等。


    不论是陈述性报告还是分析型的报告,内容整体是差不多的。
    ·概述
    ·项目背景
    ·测试目的
    ·测试内容
    ·测试人员
    ·计划安排
    ·测试工具
    ·测试环境
    ·测试方案
    ·测试用例
    ·测试结果:
    对应测试场景。
    可以给表格,也可以给图。
    表格可以参考LR的概要报告中的事务概要信息。

    通常该处会以表格的方式展现原始数据,然后以图的方式来展示分析思路。并且辅以相应的文字来描述分析过程和结论等。

    ·测试总结:
    ·性能测试的结论
    包含但是不限于活动本身的结论、相应的解决方案、活动过程中做得好和不好的地方。

    ·输入文档
    ·输出文档
    ·测试风险
    ·名词解释

  • 相关阅读:
    extjs grid renderer用法
    EventListenerList举例
    SQL语句的执行原理
    WPF操作邮箱,发送邮件
    wpf中DataGrid行色变换
    JS获取浏览器和荧屏分辨率
    将数据库的二进制字节转换成图片
    字符串操作类
    ios推送基于YII第三方组件的类库
    数组操作类
  • 原文地址:https://www.cnblogs.com/wendy-0901/p/11724770.html
Copyright © 2011-2022 走看看