JMeter初级应用-搭建基本测试环境

这篇是安装完成后,进行一个简单的测试环境搭建,主要是方便大家了解大概流程与框架~

首先了解一下测试计划的基本概念♥

gainian1

测试计划是使用JMeter进行测试的起点,它是其他JMeter测试元件的容器。

名词解释:

  • 名称:为当前的测试计划取一个有意义的名字,以便区分于其他计划。
  • 注释对测试计划的注释。
  • 用户定义的变量:用户可以自己定义变量,在用到此变量的时候直接用${变量名}引用即可。

例:变量名=url,值=http://www.jianjiexuan.com,在需要http://www.jianjiex.com时直接用${url}即可。

  • Add directory or jar to classpath:向类路径即%JMETER-HOME%\lib中添加目录及jar包。

1、添加线程组,设置线程组参数

​线程组:代表一定数量的并发用户,它可以用来模拟并发用户发送请求。线程组是为模拟并发负载而设计。

jmeter1

名词解释:

  • 名称:为线程组起的名字,以便区分。
  • 线程数:虚拟用户数。设置发送请求的用户数目,即并发数。
  • Ramp-Up Period(in seconds)线程间的时间间隔,单位为s。即所有线程在多少时间内启动。如有8个线程,Ramp-Up = 4秒,那么线程的启动时间间隔为4/8=0.5秒(一秒启动2个线程),这样的好处是:一开始不会对服务器有太大的负载。如果Ramp-Up = 0秒,表示同时并发请求。
  • 循环次数:每个线程发送请求的次数。如果线程数为20,循环次数为100,那么每个线程发送100次请求。总请求数为20*100=2000。如果勾选了“永远”,那么所有线程会一直发送请求,直到选择停止运行脚本。循环次数不能为0,会一直加压导致崩溃。
  • 调度器:可以设置启动时间和结束时间

2、选中线程组右击添加smapler取样器-HTTP请求
jmeter2  

配置请求参数,最基本是填写web服务器ip及端口号、协议以及路径

jmeter3

名词解释:

  • 名称:HTTP请求的名字,本属性用于标识一个取样器,建议使用一个有意义的名称。
  • 注释:对于测试没有任何作用,仅用户记录用户可读的注释信息。
  • 服务器名称或IP:HTTP请求发送的目标服务器名称或IP地址。
  • 端口号:目标服务器的端口号,默认值为80 。
  • 协议:向目标服务器发送HTTP请求时的协议,可以是http或者是https,默认值为http 。
  • 方法:发送HTTP请求的方法,可用方法包括GET、POST、HEAD、PUT、OPTIONS、TRACE、DELETE等。
  • Content encoding:内容的编码方式,默认值为iso8859
  • 路径:目标URL路径(不包括服务器地址和端口)
  • 自动重定向:如果选中该选项,当发送HTTP请求后得到的响应是302/301时,JMeter自动重定向到新的页面。
  • Use keep Alive:当该选项被选中时,jmeter和目标服务器之间使用 Keep-Alive方式进行HTTP通信,默认选中。
  • Use multipart/from-data for HTTP POST:当发送HTTP POST请求时,使用Use multipart/from-data方法发送,默认不选中。
  • 同请求一起发送参数:在请求中发送URL参数,对于带参数的URL,jmeter提供了一个简单的对参数化的方法。用户可以将URL中所有参数设置在本表中,表中的每一行是一个参数值对(对应RUL中的名称1=值1)。
  • 同请求一起发送文件:在请求中发送文件,通常HTTP文件上传行为可以通过这种方式模拟。
  • 从HTML文件获取所有有内含的资源:当该选项被选中时,jmeter在发出HTTP请求并获得响应的HTML文件内容后,还对该HTML进行Parse并获取HTML中包含的所有资源(图片、flash等),默认不选中,如果用户只希望获取页面中的特定资源,可以在下方的Embedded URLs must match文本框中填入需要下载的特定资源表达式,这样,只有能匹配指定正则表达式的URL指向资源会被下载。(新版中则在Advanced中查看)
  • 用作监视器:此取样器被当成监视器,在Monitor Results Listener中可以直接看到基于该取样器的图形化统计信息。默认为不选中。
  • Save response as MD5 hash:选中该项,在执行时仅记录服务端响应数据的MD5值,而不记录完整的响应数据。在需要进行数据量非常大的测试时,建议选中该项以减少取样器记录响应数据的开销。

3、选中线程组右击添加监听器

添加:一般添加图形结果、聚合报告、用表格察看结果、察看结果树,结果可以保存,.jtl文件可以提供多种格式的编写。

我们可以在右侧点击“Configure”进行一些设置,如图所示,除了默认的,我们一般还选择“Save Field Name,Save Assertion Failure Message”

fenxi1

ps:如果需要保存详细的响应结果,需要选择“Save Response Data(xml)”,然后重新命名为xml格式,用浏览器打开就行

   聚合报告对应名词解释:jmeter4

jmeter中的响应时间都是以ms为单位

4、执行前保存测试计划

5、选择线程组,点击运行

♦Jmeter使用过程中其他注意事项

◊在真正生产环境下尽量不要使用消耗时间与内存的部分组件,如Lisener(监听器)要越少越好。

通常所有web测试都要支持Cookie,一般放在线程组一级,可添加配置元件→HTTP Cookie ManagerHTTP Cookie管理器)

◊为了符合实际情况,http请求中Advanced下面的从HTML文件获取所有内含的资源必须勾选(解析所有的嵌入资源)

♥一些快捷键的使用

〉停止(Ctrl+。):立即停止所有线程,有可能报错。

〉关闭(Ctrl+,):要求线程在当前工作完成后停止,这项操作不会中断任何采样器的工作。(建议使用)

〉关闭(非GUI):shutdown

〉停止(非GUI):stoptestnow

〉清理(Ctrl+e):清理测试结果

〉运行(Ctrl+r):运行测试计划

Charles对https进行抓包

一、对https进行抓包(Windows-pc端)

1、电脑端安装SSL证书

https_SSL

https_SSL2

2、进行相关配置

 选择SSl Proxying Settings,勾选Enable SSl Proxying,点击Add,输入要抓取的网站的地址及端口(默认是443),如果是抓取任意网站的数据则在host中填写“*”即可

https_SSL3

3、选择Windows Proxy模式

https_SSL4

4、打开浏览器,进行访问即可

二、对https进行抓包(手机端)

→iOS端抓取https

1、完成上述的1、2点

2、连上无线网,在手机上设置代理地址

3、手机端安装证书,使用Safari直接打开下面地址进行安装

  地址:http://www.charlesproxy.com/getssl

  安装好后可在【设置-通用-描述文件】中查看

→Android端抓取https

1、完成上述的1、2点

2、连上无线网,在手机上设置代理地址

3、手机端安装证书,使用安卓自带浏览器直接打开下面地址进行安装

  地址:http://www.charlesproxy.com/getssl

  安装好后可在【设置-安全】中查看

系统性能关注点

1、【页面/客户端的响应时间】

    响应时间直接影响最终用户的使用体验,从而在很大程度上影响用户忠诚度。是客户发出请求到得到响应的整个过程的时间。

2、【服务器的吞吐量】
    常用的是系统每小时能处理的业务量。例如,最高每小时能接受的网站浏览次数,或者一个电子商务网站每小时能下多少个订单。

3、【最大并发用户数】
    这里的“最大”其实并不是真正的最大,而是在响应时间合理的情况下,能承受的并发用户数。也就是系统最多能承受多少用户同时访问且用户感觉不到页面响应变慢。

4、【能否能稳定的长期运行】
    任何客户都不希望自己的系统动不动就宕机,这会对最终用户造成非常不好的印象,从而给客户的业务带来大的损失。应用服务系统是否能长期稳定运行除了跟服务器的硬件有关系之外,与软件本身也有很大的关系。可利用7*24方式去进行测试。

5、【最大数据规模】
    能保证正常访问的最大容忍数据规模。

6、【服务器后台操作是否会影响前台性能】

7、【什么情况下会导致系统崩溃】

It’s delicious

持续更新ing

1、第一次尝试做pizza,海鲜大虾,芝士放好多,很好吃。

2016-03-01 172315

2、抹茶蜜豆卷,配一杯香醇豆浆,甜而不腻,如春风中的甜腻气息萦绕在舌尖。

food

   

测试用例评审检查单及如何评审

测试用例评审检查单
序号 主要检查项 是否通过
1 《需求规格说明书》是否评审?  
2 是否按照测试计划时间完成用例编写?  
3 需求新增和变更是否进行了对应的调整?  
4 用例是否按照公司定义的模板进行编写?  
5 测试用例是否覆盖了《需求规格说明书》?  
6 用例编号是否和需求进行对应?  
7 非功能测试需求或不可测试需求是否在用例中列出并说明?  
8 用例设计是否包含了正面、反面的用例?  
9 每个测试用例是否清楚的填写了测试目的、步骤、预期结果?  
10 步骤/输入数据部分是否清晰,是否具备可操作性?  
11 测试用例是否包含测试数据及数据的生成办法或者输入的相关描述?  
12 测试用例是否包含边界值、等价类分析、因果图、错误推测、等测试用例设计方法?是否针对需求不同部分设计使用不同设计方法?  
13 重点需求用例设计至少要有三种设计方法?  
14 每个测试用例是否都阐述预期结果和评估该结果的方法?  
15 需要进行打印、表格、导入、导出、接口是否存在打印位置、表格名称、指定数据库表名或文件位置;表格和数据格式是否有说明或附件?  
16 用例覆盖率是否达到相应质量指标?  
17 用例预期缺陷率是否达到相应质量指标?  

那么如何进行测试用例的评审呢?

测试用例评审标准

1、首先要清楚内部评审的定义,是测试组内部的评审,还是项目组内部的评审。评审的定义不同,内容也不会相同。

 如果是测试组内部的评审,应该着重于:

  • 测试用例本身的描述是否清晰,是否存在二义性;
  • 是否考虑到测试用例的执行效率。测试设计的冗余性,造成了效率的低下;
  • 是否覆盖了所有的软件需求;
  • 是否完全遵守了软件需求的规定。这并不一定的,因为即使再严格的评审,也会出现错误,应具体情况具体对待。

 如果是项目组内部的评审,也就需要评审委员会来做了,角度不同,评审的标准也不同。比如:

  • 收集客户需求的人员注重你的业务逻辑是否正确;
  • 分析软件需求规格的人注重你的用例是否跟规格要求一致;
  • 开发负责人会注重你的用例中对程序的要求是否合理。

测试用例评审步骤

 测试用例的评审能够使用例的结构更清晰,覆盖的用户场景更全面;对于测试工程师来说也是一个快速提高用例设计能力的过程。

  1、需要评审的原因

  测试用例是软件测试的准则,但它并不是一经编制完成就成为准则。由于用例开发人员的设计经验和对需求理解的深度各不相同,所以用例的质量难免会有不同程度的差异。

  2、进行评审的时机

  一般会有两个时间点。第一,是在用例的初步设计完成之后进行评审;第二是在整个详细用例全部完成之后进行二次评审。如果项目时间比较紧张,尽可能保证对用例设计进行评审,提前发现其中的不足之处。

  3、参与评审人员

  这里会分为多个级别进行评审。

  • 部门评审,测试部门全体成员参与的评审。
  • 公司评审,这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。
  • 客户评审,包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见。

  4、评审内容

  评审的内容有以下几个方面(可使用检查单):

  • 用例设计的结构安排是否清晰、合理,是否利于高效对需求进行覆盖。
  • 优先极安排是否合理。
  • 是否覆盖测试需求上的所有功能点。
  • 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确;期待结果是否有明显的验证方法
  • 是否已经删除了冗余的用例。
  • 是否包含充分的负面测试用例。充分的定义,如果在这里使用2&8法则,那就是4倍于正面用例的数量,毕竟一个健壮的软件,其中80%的代码都是在“保护”20%的功能实现。
  • 是否从用户层面来设计用户使用场景和使用流程的测试用例。
  • 是否简洁,复用性强。例如,可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。

  5、评审的方式

  • 召开评审会议。与会者在设计人员讲解之后给出意见和建议,同时进行详细的评审记录。
  • 通用邮件与相关人员沟通
  • 通用即时通信工具直接与相关人员交流

  方式只是手段,得到其它人员对于用例的反馈信息才是目的。

  无论采用那种方式,都应该在沟通之前把用例设计的相关文档发送给对方进行前期的学习和了解,以节省沟通成本。

  6、评审结束标准

  在评审活动中会收集到用例的反馈信息,在此基础上进行用例更新,直到通过评审。

设计测试用例方法

设计测试用例一般有8个方法,分别是等价类划分、边界值、场景法、因果图、判定表、正交排列表、状态转换图、测试大纲法等

一、等价类划分及边界值

首先这两个设计测试用例的方法一般是一起的,等价类划分即将所有合理的、有意义的或不合理的、无意义的数据分为有效等价类和无效等价类,运用有限的测试用例去覆盖无穷的数据输入,而边界值则是对等价类划分的补充。

设计测试用例的步骤:

  • 划分等价类
  • 细化等价类划分
  • 建立等价类表
  • 根据等价类表划分编写测试用例

其中,当我们熟练了之后,2、3步骤可以忽略

我们以实际例子说明。

需求:

年龄输入框:1-99整数,可以为空

分析步骤:

1、划分等价类

1)有效等价类

①1-99整数;

②为空;

2)无效等价类

①<1的整数;

②>99的整数;

③小数;

④特殊字符;

2、细分等价类(加入边界值)(可省略)

1)有效等价类

①1-99整数,如1(边界),2(边界),55,98(边界)、99(边界)

②为空,空格

2)无效等价类

①<1的整数,如0(边界),-1,-100

②>99的整数,如100(边界),999,无穷大

③小数,如0.1,10.55,小数点后多位

④特殊字符,如!、@、*、%或组合)……&等

3、建立等价类表(可省略)

将输入的数据和预期结果以表格展示出来,下图示例

年龄
编号 输入数据 预期结果
1 1 通过
2 2 通过

4、根据等价类表划分编写测试用例

二、场景法

现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。

设计测试用例的步骤:

  • 根据说明(流程图),描述出程序的基本流及各项备选流
  • 根据基本流和各项备选流生成不同的场景
  • 对每一个场景生成相应的测试用例

举例,下面是一个简单登录的流程图

liuchengtu1、根据说明(流程图),描述出程序的基本流及各项备选流

基本流:

基本流1:输入正确的用户名

基本流2:输入正确的密码

基本流3:点击“登录”按钮,程序能正常登录

备选流:

备选流1:不输入用户名和密码

备选流2:输入正确的用户名,错误的密码

备选流3:密码为空

备选流4:用户名为空

备选流5:输入错误的用户名,正确的密码

备选流6:输入错误的用户名,错误的密码

2、根据基本流和各项备选流生成不同的场景(部分举例)

场景描述 基本流 备选流
场景1:输入正确的用户名及密码点击登录,成功登录 基本流  
场景2:用户名、密码为空点击登录程序给与提示 基本流 备选流1

 V表示Valid,有效的,I表示Invalid,无效的。

编号 场景 用户名 密码 预期结果
1 场景1:成功登录 V V 提示登录成功
2 场景2:用户名、密码为空,登录失败 I I 给与错误提示

3、对每一个场景生成相应的测试用例

  用例描述中详细写出测试数据。

三、因果图、判定表

因果图是一种利用图解法分析输入与输出的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况。因果图和判定表一般是同时使用的。

设计测试用例的步骤:

  • 找出所有输入条件并编号,即“原因”
  • 找出所有输出条件并编号,即“结果”
  • 明确输入与输出之间的关系(制约关系和组合关系)
  • 根据因果图,写出判定表
  • 根据判定表写出测试用例

举例:

需求:›有一个饮料自动售货机(处理单价为5角钱硬币)的控制处理软件,它的软件规格说明如下:

  • 若投入5角钱的硬币,按下“橙汁”或“啤酒”的按钮,则相应的饮料就送出来。若投入1元钱的硬币,同样也是按“橙汁”或“啤酒”的按钮,则自动售货机在送出相应饮料的同时退回5角钱的硬币。
  • 不能同时投两个硬币,不能一次同时购买2瓶及以上饮品。

1、找出所有输入条件并编号

  • 投入1元硬币(1)
  • 投入5角硬币(2)
  • 按下“橙汁”按钮(3)
  • 按下“啤酒”按钮(4)

2、找出所有输出条件并编号 

  • 退还5角(a)
  • 送出“橙汁”饮料(b)
  • 送出“啤酒”饮料(c)
  • 错误提示(d)
  • 退还1元(e)

3、明确输入与输出之间的关系(图省略)

如1、2为互斥,3、4为互斥;ab、ac、ad、de可以组合,bcd可以单独出现;ae、bc、bd、cd、be、ce互斥

图示例:13组合输出ab

yinguotu

›4、根据因果图,写出判定表

 1表示选择输入条件及造成的输出结果,以列来看

  1 2 3 4 5 6 7 8
输入 1 投币1元 1 1     1      
2 投币5角     1 1   1    
3 按下橙汁 1   1       1  
4 按下啤酒   1   1       1
 
输出 a 退回5角 1 1       1    
b 送出橙汁 1   1          
c 送出啤酒   1   1        
d 错误提示         1 1 1 1
e 退还1元         1      

5、根据判定表写出测试用例

退还1元硬币,提示错误

用例编号 用例操作 预期结果
1 投入1元硬币,按下“橙汁”按钮 送出橙汁,退还5角硬币
2 投入1元硬币,按下“啤酒”按钮 送出啤酒,退还5角硬币
3 投入5角硬币,按下“橙汁”按钮 送出橙汁
4 投入5角硬币,按下“啤酒”按钮 送出啤酒
5 投入1元硬币 退还1元硬币,提示错误
6 投入5角硬币 退还5角硬币,提示错误
7 按下“橙汁”按钮 提示未投币
8 按下“啤酒”按钮 提示未投币

四、正交排列表

常用正交表下载:http://pan.baidu.com/s/1bpMCjBT

通过已有的正交排列参考表将要测试的因素代入进去,可以已最少的用例覆盖最多的可能

举例:测试一个字符属性设置功能(选项),测试过程中需要考虑4个方面问题。

  • 字符类型:中文、英文、特殊符号
  • 字符属性:字型字号、普通效果、特殊效果
  • 字符位置:单元格、排版框、区域
  • 操作系统:Windows98、 Windows2000、Linux

因为是4个因素,每个因素里还有3个可能,所以我们可以参考L9(34)正交排列这个排列

序号  A  B  C  D
1 1 1 1 1
2 1 2 2 2
3 1 3 3 3
4 2 1 2 3
5 2 2 3 1
6 2 3 1 2
7 3 1 3 2
8 3 2 1 3
9 3 3 2 1

其中ABCD对应的是四个因素,而123分别对应每个因素中的三个选项,变更后为测试用例组合:

测试用例编号  字符类型  字符属性  字符位置  操作系统
1 中文 字型字号 单元格 Windows98
2 中文 普通效果 排版框 Windows2K
3 中文 特殊效果 区域 Linux
4 英语 字型字号 排版框 Linux
5 英语 普通效果 区域 Windows98
6 英语 特殊效果 单元格 Windows2K
7 特殊符号 字型字号 区域 Windows2K
8 特殊符号 普通效果 单元格 Linux
9 特殊符号 特殊效果 排版框 Windows98

五、状态转换图

设计测试用例的方法:

  • 找出程序的所有输入动作,并进行编号
  • 找出程序的所有状态
  • 找出什么动作会导致什么状态发生,画出状态转换图
  • 把相关联的动作和状态联系起来,设计测试用例

举例:某程序登录框,需输入账户和密码,提供关闭和登录按钮

1、找出程序的所有输入动作,并进行编号:

  • ip1→输入账号;
  • ip2→输入密码;
  • ip3→点击“登录”按钮;
  • ip4→点击“关闭”按钮。

2、找出程序的所有状态:

  • 启动状态
  • 账号已输入
  • 密码已输入
  • 账号已输入、密码已输入
  • 错误提示状态
  • 登录成功
  • 退出

3、找出什么动作会导致什么状态发生,画出状态转换图

如图所示:

zhuangtai4、把相关联的动作和状态联系起来,设计测试用例

把相关联的动作和状态联系起来,设计测试用例,为了减少测试用例数量,一条测试用例最好沿着状态转换图的一条路径编写完,如上图,大概有11条路径。

六、测试大纲法

测试大纲法适用于跳转页面较多的界面用例设计,如安装。

设计测试用例的方法:

  • 找出所有的窗口以及每个窗口的输入动作(注意先后顺序)
  • 找到各个窗口之间的联系,并据此编写测试用例

1、大纲是一种着眼于需求的方法,为了列出各种测试条件,就将需求转换为大纲的形式。

2、在根和每个叶节点之间存在唯一的路径,每条路径定义了一个特定的输入条件集合,用于定义测试用例。

如图示例,下图为各个界面所展示的可点击的操作(只是模拟,没有实际数据,哈哈),而一条路径就可以为我们定义一条测试用例。

cesdagang

 

那些记忆中的风景

持续更新中ing

1、她现在已经不在了,因为我并没有照顾好她,这是第一次拿起相机,也是唯一一次为她留的纪念。

IMG_0113

2、春寒料峭,梅花山中却出现一抹翠绿,娇小窈窕,实在惹人怜爱。

IMG_1922

3、待到山花烂漫时,她在丛中笑

IMG_1878

4、虽然渺小,却能夺人心魄。就像我们,宇宙中的一个微点,却能万般灿烂。

IMG_1660

5、她叫丽娜莲,美丽端庄,却在枝头透露出些许抚媚,像多喝了点美酒的姑娘脸庞

IMG_4294

6、轻肌弱骨散幽葩,更将金蕊泛流霞。杯中窥花。

juhua

7、杂草中顽强的长出一株不知名的小花,带着独有的倔强,迎接属于她的阳光。

xiaohua

8、日照人面红,风吹百合香。

2015-10-04 151844

9、然而就只是背影,在家乡的渲染下,也散发出点点温馨

2015-10-03 215857

10、南京夫子庙元宵灯会的一景,下面漆黑一片的其实是拥挤的人群

2015-03-05-191020

11、一个神奇而伟大的海洋生物,即可入药,雄性还具有育儿袋——海马

img_1638

Bug严重程度分级

我在测试过程中,一般把bug严重程度分为四个等级,在最后验收符合0,0,2,5收敛准则即可,即严重程度紧急、严重的bug数为0,严重程度一般的bug数小于等于2个,严重程度低的bug数最多只有5个。

一、Bug严重程度——紧急

  • 造成系统崩溃、死机、死循环的问题
  • 数据库数据丢失,与数据库连接错误
  • 主要功能、基本模块缺失
  • 阻塞测试执行的问题且不可逾越

        这些问题在测试中很少出现,一旦出现,需终止当前版本的测试

二、Bug严重程度——严重

  • 主要功能部分缺失
  • 用户数据丢失
  • ­一级菜单不能使用但不影响其他功能测试
  • ­功能实现与需求严重不符
  • ­由于Bug的存在使产品其它部分不能测试
  • ­由于计算方法问题,使数据错误
  • ­由于设计原因,造成前后不一致,但问题可恢复
  • ­容错性方面存在不足
  • ­由于精度问题造成数据不一致
  • 程序接口错误

        该等级问题出现,若不影响其他功能测试情况下可继续进行该版本的测试。

三、Bug严重程度——一般(普通)

  • ­功能没有完全实现,但不影响使用
  • ­功能存在缺陷但不会影响系统稳定性

       该等级问题在实际测试中存在最多,合理安排解决bug。

四、Bug严重程度——低 

  • 界面问题
  • 性能优化问题
  • 建议问题

        此问题在测试初期较多,优先程度较低,在测试后前出现较少,应及时处理。

另附一个标准化分为5个等级的图表。

缺陷种类 缺陷级别 详细说明
功能缺陷 Urgent
(V级)
1.操作系统无法正常使用,死机,出现致命错误
2.数据丢失
3.被测试系统频繁崩溃,程序出错,使功能不能继续使用
4.性能与需求不一致
5.系统资源引发性能问题
6.系统配置引发错误
7.安全性问题
Very High
(IV级)
1.功能与需求不一致,或功能未实现
2.功能有错误,影响使用
3.数据传输有错误
4.安装与卸载问题
High
(III级)
1.功能有错误,但不影响使用
2.界面错误
3.边界条件出错
Medium
(II级)
1.界面设计不规范
2.消息、提示不准确
3.交互不友好
需求缺陷 Low
(I级)
1.软件设计有问题
2.文档不完整或不准确
3.需求冻结后,描述不清楚的地方

测试类型

下面主要举例一些测试的分类及测试策略,在实际开展测试中可有所删减

1、功能测试:最主要的一种测试类型,对提供给用户的功能进行验证测试。主要针对功能错误或遗漏、界面问题、性能错误(软件本身的性能,处理性能;与性能测试进行区分)、数据及访问错误,初始化及终止错误。

2、性能测试:检查系统是否满足在需求中所规定达到的性能,性能主要包括了解程序的内外部性能因素。内部性能因素包括测试环境的配置,系统资源使用状况;外部因素包括响应时间,吞吐量等。又可包含负载测试、压力测试、稳定性测试。性能主要考虑的指标:并发用户数UV、每秒事务数TPS、系统响应时间、设备性能等

3、负载测试:在我们的测试过程中,来逐步增加负载,并且记录下被测系统相应的性能表现,最终确定出系统在正常指标范围下的最大负载。

4、压力测试:压力测试又称强度测试,主要是检查系统运行环境在极限情况下软件运行的能力,比如说给一个相当大的负荷或网络流量给应用软件。

5、稳定性测试:一般是以稍大于正常业务量的一个负载,对系统进行持续的长时间的测试。比如说24*5,即连续5天对系统施加压力,以确定系统在长时间压力下的稳定性如何。

6、安全测试:对软件产品进行测试以确保其符合产品安全需求和质量标准,我们提到安全测试一般还有一个相提并论的概念,即渗透测试。

7、渗透测试:通过模拟对软件系统的恶意攻击行为来评估系统安全性的一种测试。

8、兼容性测试:对软件产品在软件本身的兼容性、不同平台下的兼容性、软件对运行设备的兼容性、软件互操作性(如微信)、浏览器的兼容性等方面进行测试。

9、文档测试:针对软件产品的交付品,配套的文档类部件的测试。检查内部/外部文档的清晰性和准确性,对外部文档而言,还必须考虑文档的简单明了,相关的技术术语是否解释清晰等方面的检查。如用户手册、使用说明、用户帮助文档等。关注的点主要是完整性、正确性、一致性、易理解性、易浏览性。

10、易用性测试:从使用的合理性和方便程度对系统及软件进行相关的测试和检查,在不影响程序主体和耗费时间太长的前提下,建议多从用户的使用角度来考虑,用户是否感觉方便,注重用户的体验

11、本地化测试:针对软件的本地化版本实施的针对性测试,主要包括语言、书写习惯、时区、日期格式、货币、当地风俗、法律法规,政治敏感内容等。

12、多语言测试:对不同的语言平台,环境下,包括界面,语法,基本功能方面的测试。

13、部署测试:也称安装测试,主要验证系统部署过程,并确保软件经过安装测试后可以正常使用。主要测试内容:在不同环境下的部署验证;参照部署文档执行,过程的合理、正确性;基础测试数据。

14、无障碍测试:也称可访问性测试,是指软件需要提供便于特殊人群使用的功能,包括视障、听障、老年人、身体残疾用户等。

15、正常测试:测试某个功能是否满足需求的定义,功能是否正确,完备。

16、边界测试:对某个功能的边界情况进行测试。

17、异常测试:对某些功能来说,其边界情况无法简单的了解或某些操作不完全是正确的但又是可能发生的,类似这样的情况需要书写相关的异常测试。

18、接口测试:在模块组装测试中,很多问题出现在接口部分。单个模块的功能实现了,但组装在一起,就无法正常工作。接口测试要包括两部分的测试:(1)根据设计文档,构造测试数据,验证接口是否正确;(2)将接口关联的模块组装在一起进行联调测试。接口测试可以同时检查设计文档的正确性。

19、界面测试:主要为了测试基于UI界面的测试。

20、启动/停止测试:检查系统,启动,停止,监控,维护等相关的功能是否正常