后端测试场景三:如果通过断言发现报文异常,通过关键字调用后端的日志查询接口,定位错误上下文;这即不需要伪造 request 也不需要篡改 response,设置断言后劫持实现。
数据测试场景四:配置 DML 模板,以请求的参数作为查询条件获取预期结果,以响应的关键内容作为实际结果,进行数据层的校验(待实践探索阶段);即不需要伪造 request 也不需要篡改 response,劫持实现。
请仔细看,这两条需要修改 request 和 response 吗?
#29 楼 @ycwdaaaa 不对,文中有写的,我再补一刀吧
前端测试场景一:用常规手段造数据(后端传过来作用于前端)以达到边界值、等价划分类的场景代价很大,通过篡改接口返回的数据,就能很轻松的达到目的;这个是需要篡改 response 的。
后端测试场景二:如果前端做了校验和屏蔽(前端传过去作用于后端),要校验后端服务或接口对边界值、等价划分类的的处理,通过篡改请求参数,也能达到目的;这是需要伪造 request 的。
后端测试场景三:如果通过断言发现报文异常,通过关键字调用后端的日志查询接口,定位错误上下文;这即不需要伪造 request 也不需要篡改 response,设置断言后劫持实现。
数据测试场景四:配置 DML 模板,以请求的参数作为查询条件获取预期结果,以响应的关键内容作为实际结果,进行数据层的校验(待实践探索阶段);即不需要伪造 request 也不需要篡改 response,劫持实现。
安全测试场景五:通过伪造请求头信息,篡改请求参数,校验后端的防守指数等。需要伪造 request 的。
#115 楼 @huangejuan 你是 windows 上跑?我只在 mac 上测试过,windows 上跑可能需要自己修改
#115 楼 @huangejuan appium 启动命令没有替换掉 port 和 udid,遍历时间只有 3 分钟,建议延长
#8 楼 @seveniruby 嗯,有时间把实现原理补充下
这个痛点大概都经历过,质量是个系统性的问题,测试部门只是这个系统的最后环节,往往成为背黑锅的。提高质量的策略就是全民皆兵,这个是制度设计的问题了,好的管理制度可以迫使每个环节每个角色都会很自觉的注重质量问题,也只有这样才可以最大限度的消灭 bug
#12 楼 @huangxiaojiao 这个是自己写的
案例如果有逻辑判断、循环等控制,会生成相应的 json 配置吗