请求异常测试

1.请求参数异常

在接口信息介绍中说过，创建用户使用的3个参数，都是有一定的规则限制，不是输入任意值都是成功创建用户的

1.1添加请求

1）添加一个HTTP请求，放到简单控制器下面，并修改名称中“创建用户失败_参数异常”
2）设置HTTP请求（参照创建用户请求），请求参数设置为不能成功创建用户的参数，比如用户名为 a (用户名要求是4到20的字母数字组合)，结果如下

（这里还处于脚本调试阶段，所以我会暂时先禁用掉循环控制器中成功创建用户的请求）
3）试运行脚本
可以看到，当创建用户时，name设置a，是不能创建用户的，并且系统返回了对应的错误信息

4）添加断言
与创建用户成功一样，这里同样会加3个断言，分别用来验证请求响应码，请求响应信息，数据库内容

• 参数异常，请求响应码应该是400
  

  • 响应信息
    
  • 按名称查找用户
    （简单来说，直接从创建用户的请求中复制过来的，但修改了参数值为当前请求用到的值：a）
    
  • 判断数据库中的用户信息
    参数异常，创建用户失败，数据库中不应该查询到该用户的信息
    
    5）试运行脚本
    
    why? 结果是红色的，但断言什么的没有错。
    前面介绍jmeter常用组件》响应断言时应该说过，jmeter会将响应码不是2XX,3XX的请求默认为失败，而这里，请求响应码是400，如果想要400设置为期待值，需要在响应断言中选中“Ignore Status”
    Ok，修改第一个响应断言如下（有2个响应断言，但只要修改一个就好，原因回去组件介绍中找啦）
    
    重新运行脚本，结果成功
    

1.2 参数化

就像创建用户成功一样，创建用户失败也会需要测试不同的数据集合，同样也会用到参数化
（过程神马的与创建用户成功是一样的，所以下面只给出完成版本的截图了）

• createuser_fail.csv
  不同的参数错误，请求返回的信息是不一样的，所以在这里设置最终会更加方便
  
• 最终运行结果
  从“察看结果树”中，可以看到jmter发送了8个创建用户的请求，分别对应createuser_fail.csv的8行测试数据，并且最终断言结果通过
  

2. 用户名不能重复

创建用户接口中说过，name是不可重复的。
要测试用户名重复这种情况，必须先要知道在数据库已经存在的一个用户。我们可以事先准备一个用户，然后再次使用这个用户名来测试创建用户。或者，看下脚本，之前我们已经测试过成功创建用户的情况，现在只需要取出其中一个用户来进行测试也一样能行吧。。
下面基于这种考虑，修改脚本

2.1 添加仅一次控制器

在成功创建用户的循环控制器下，添加一个仅一次控制器

2.2 添加HTTP请求

在仅一次控制器添加一个HTTP请求：创建用户失败_用户名重复，用来测试用户名重复的情况
name 使用变量获取，与创建用户请求取同样的值，因为jmeter按顺序执行请求，当第一次创建用户成功后，第二次就是用户名重复了

注意：这有个前提，就是前面创建用户的请求必须成功，不然到第二次创建用户失败_用户名重复请求中，用户名就不是重复的了，如果有必要的话，可以再增加一个如果（if）控制器来判断前面的请求创建用户用户是否成功。我是直接去查询数据库看是否已经有重复用户

2.3 添加断言

同样会有3个断言

• 响应码：409
  
• 响应信息
  
• 数据库信息判断
• 在这里，需要先做一个判断，看看数据库中是否已经有重名的用户。
  添加一个前置处理器> JDBC PreProcessor，在请求发送之前用来查询数据库数据
  
  请求发送后查询数据库数据
  
  BeanShell断言
  

2.4 试运行脚本

从结果中可以查看到，第一个创建用户请求使用的用户名与第二个创建用户失败用户名重复的请求使用的用户名是相同的，都是“xiaoming”，结果第一个创建用户的请求成功创建了xiaoming的用户，但第二个创建用户失败用户名重复的请求，返回了Name已经存在的错误信息

3. 用户没有权限

只有ADMIN用户有权限去创建用户。为了测试这种情况，需要分别使用ADMIN用户与NORMAL用户登录，再去发送请求创建用户。
回去看脚本，之前登录的用户使用的是固定的ADMIN用户，所以在这里在添加一个使用NORMAL用户登录的测试就可以了
一个简单的方法是复制当前使用ADMIN用户登录的线程组，修改下登录用户名，创建用户的请求就可以完成测试
或者从另一个角度考虑，给jmeter提供2个用户，使用逻辑控制器的如果（if）控制器去判断用户属于哪个角色，再去确定他应该走哪个测试流程，也是同样完成权限控制的测试的。（更智能一点吗……）
下面的例子是按第二种方法设计的

3.1 添加CSV Data Set Config

首先要明白线程组也是配合CSV Data Set Config可以循环执行的。所以我们可以添加一个CSV Data Set Config来读取用户名与密码

loginuser.csv:

3.2 设置线程组循环次数为2

3.3 修改登录请求

前面的脚本是使用固定用户登录的，用户名、密码必须修改为对应的变量名

3.4 添加2个如果（If）控制器

1）在脚本的简单控制下，添加如果（If）控制器，如果登录用户的角色为ADMIN，将脚本原来的测试创建用户成功与失败的部分拉到这个分支下

2）如果登录用户的角色为NORMAL，则是新增的用户没有权限创建用户的测试

3.5 创建无权限创建用户测试请求

注意请求参数要合法（包括用户名不要重复），排除掉因为参数错误引起的请求错误。

3.6 添加断言

用户没有权限时，响应码应该是403，返回信息是{“errorMsg”:”不允许访问”}，并在数据库中查询，不应该存在该名字的用户

3.7 试运行脚本

从图中可以看到，登录的用户为normal，而他的角色是NORMAL

当登录用户的角色为NORMAL时，创建用户失败，返回不允许访问的错误信息

4 用户未登录不能创建用户

只要服务器没有接收到user session，都会认为用户未登录。在本例子中，user session是存放在cookie中，所以只要让创建用户的请求位于jmeter的HTTP Cookie 管理器作用域外，就可模拟用户未登录的场景。比如将前面的脚本全部归放到一个简单控制器下，再新起一个简单控制器来测试用户未登录场景，或者也可以新建一个线程组来测试用户未登录场景
这里使用新建一个线程组的方式来测试用户未登录的场景
先分析下接口行为，用户未登录的情况下，直接发送创建用户请求，系统会重定向到登录页面

4.1 添加一个线程组

并将原来的线程组重命名为用户已登录测试，用以区分新增的未登录测试线程组

4.2添加创建用户请求

注意请求参数要合法

4.3 添加断言

未登录的情况下发送创建用户请求，系统会重定向到登录页，这在jmeter表现为会产生2个对应的子请求。

• 响应断言判断重定向后的URL
  
• BeanShell断言判断重定向信息
  

4.4试运行脚本

察看结果树中，可以清楚看到未登录情况下被重定向到了登录页
（注，这里我没有再做数据库数据判断，如果需要的话，与前面用户没有权限的验证过程是一样的，未登录情况下应该不能创建新用户）