测试用例
从错测试:
(1)引用/传递的字段是NULL
(2)引用/传递的字段是空值
(3)引用/传递的字段是空格
(4)引用/传递的字段达到最大长度
(5)引用/传递的字段超过限定的最大长度
(6)填写的参数值不符合字段类型
(7)输入特殊字符、ASCII字符等,程序不能报错
![](https://img2020.cnblogs.com/blog/2212728/202012/2212728-20201230105854747-312306330.png)
上述测试用例只是在对软件的“显式功能”进行测试,作为一名高质量的测试工程师,其他的非功能性需求即隐式功能性需求也是极其关键的。
显式需求与隐式需求
显式需求 显式功能性需求(Functional requirement)的含义从字面上就可以很好地理解,指的是软件本身需要实现的具体功能, 比如“正常用户使用正确的用户名和密码可以成功登录”、“非注册用户无法登录”等,这都是属于典型的显式功能性需求描述。
隐式需求 从软件测试的维度来看,非功能性需求主要涉及安全性、性能以及兼容性三大方面。
安全性测试用例
用户密码在网络传输过程中是否加密;
密码是否具有有效期,密码有效期到期后,是否提示需要修改密码;
不登录的情况下,在浏览器中直接输入登录后的URL地址,验证是否会重新定向到用户登录界面;
密码输入框是否不支持复制和粘贴;
密码输入框内输入的密码是否都可以在页面源码模式下被查看;
用户名和密码的输入框中分别输入典型的“SQL注入攻击”字符串,验证系统的返回页面;
用户名和密码的输入框中分别输入典型的“XSS跨站脚本攻击”字符串,验证系统行为是否被篡改;
连续多次登录失败情况下,系统是否会阻止后续的尝试以应对暴力破解;
不同页面同时登录是否有一端被踢、本终端被踢下线后点击登录能否再次登录;
密码输入是否有最大次数限制,超过最大次数限制后,是否采取强制手段限制登录或对账号暂时冻结处理;
异地登录校验、更换设备登录校验、登录信息异常的情况
是否可以使用登录的API发送登录请求,并绕开验证码校验;
是否可用抓包工具抓到的请求包直接登录;
截取到的token等信息,是否可以再其它终端直接使用,绕开登录;
token过期时间校验;
性能测试用例
单用户登录的响应时间是否小于3秒;
单用户登录时,后台请求数量是否过多;
高并发场景下用户登录的响应时间是否小于5秒;
高并发场景下服务端的监控指标是否符合预期;
高集合点并发场景下,是否存在资源死锁和不合理的资源等待;
长时间大量用户连续登录和登出,服务器端是否存在内存泄漏。
弱网延迟或切换网络或断网时登陆是否正常
兼容性测试用例
不同浏览器下,验证登录页面的显示以及功能正确性;
相同浏览器的不同版本下,验证登录页面的显示以及功能正确性;
不同移动设备终端的不同浏览器下,验证登录页面的显示以及功能正确性;
不同分辨率的界面下,验证登录页面的显示以及功能正确性;
移动端横屏竖屏切换时显示是否正常;
是否涉及第三方账号登录,能否正常调起不同版本第三方应用;
一般来说,测试用例很难穷尽,因此我们在编写测试用例的过程中需要从“场景”出发,有效的利用等价类、边界值的方法,尽可能多的对测试点进行覆盖。
测试用例的用途和目的 执行测试,发现缺陷 重复执行测试,重现缺陷 管理测试过程 回归测试,验证缺陷是否修复 使测试更加方便的执行 提高测试效率 节省执行测试的时间 使测试更能按照时间计划进行 使测试过程更方便管理 如何多方面考虑测试一个系统: 【web页面的测试点的考虑】: 基于整个页面: 1、填写区域是否为空的检查: A、只填写一处 B、填写部分、空白部分 C、填写剩一处 D、填写所有。 2、针对单个填写框: A、考虑长度(最长、最短) B、考虑字符(数字、字母、特殊字符、组合) C、考虑全角半角 3、测试点1和测试2的组合。 4、存在关联的不同单元格之间的测试点的考虑: 如单张发票金额不能大于累计发票金额。设计用例时就要考虑验证这点。 5、考虑不同功能模块的入口,如正票开具,可以从菜单选择,也可以直接点击正票开具的按钮。不同入口出口的组合要遍历验证。 【存在关联业务的测试点的考虑】: 重点关注在当前业务走通的情况下,对其他相关联页面的影响。主要考虑如下几个方面: 1、当前业务正常走通,其他相关模块是否能正常显示对应数据。 2、当前业务执行过程中出现异常情况,对自身及子他模块数据的影响是否正常。 3、考虑积累作用:长时间,重复操作本模块,是否会对其他模块的数据处理造成影响,相关模块数据处理是否正常。 4、几个模块共同作用,都发生数据变更,查看彼此间的影响是否正常,数据处理是否正确。 常用测试设计方法: 整体把握: 【测试类型分析法】 单个功能点: 【测试类型分析法】【测试场景分析法】【模块关联】【等价类边界值分析法】 单个界面: 【测试类型分析法】【模块关联】【表间关联】 【等价类边界值分析法】【不同出入口遍历】 单个输入框、选择框等: 【表间关联】【等价类边界值分析法】 测试类型分析法: 【测试类型分析法】: 即将一个功能点按照不同的测试类型进行划分,针对每一个测试类型都进行测试点设计的分析方法。 举例说明: 思维导图设计格式的原则: 1、整体把握: 使用【测试类型分析法】建立第一级目录。 2、单类型测试点: A、首先以小的功能模块进行分级。 B、小的功能模块里面按照“***执行成功”,“***执行失败”,“***关联性测试”,“异常情况测试”等若干模块。 C、举例:“***执行成功”里面再分“一次执行成功”,“多次执行成功(考虑重复执行同一记录,不同记录)”。 3、最后一级描述规则: 【测试点】+【简洁扼要的测试步骤】+隔断符号+【预期结果】,如: “校验客户名称长度:点击进入客户信息新增界面,输入客户名称允许输入的最大长度,其他信息符合规则,点击保存。---对应客户信息能够正常保存,显示正常。” 4、严格控制思维导图横向层级: 为了思维导图转化用例时的方便,横向分级不宜过多。 5、最后一级测试描述颗粒度: 一个用例永远只关注一个测试点。比如关注一个输入框的输入内容的时候,就不考虑长度,不考虑其他单元框对他的影响。 测试思维导图设计步骤_1: 用例级别定义说明: Level1:最常用操作、主成功场景,门槛用例 Level2: 异常场景、失败场景 Level3:不太常用操作或者不太常用的比如边界值、冷僻输入的检查、不停点击按钮等类似的操作的对应用例。 Level4:操作方法比较复杂、测试环境比较生僻,且执行起来有较大难度的对应用例。 一般Level1:Level2:Level3:Level4的用例设计比例约为3:5:1.5:0.5,或者3:5.5:1:0.5 用例执行结果标注说明: Pass:按照测试用例的操作步骤执行,实际执行结果与预期结果一致。 Fail:按照测试用例的操作步骤执行,实际执行结果与预期结果不一致。出现界面显示异常、处理异常、死机、功能失效等异常情况。 Block:由于测试环境或者其他外部条件的限制,导致用例无法执行。或者用例不适用,需要更新用例的情况。 Unavailable:软件对应功能未实现,导致对应用例无法执行的情况。 investgest :不确定测试结果的对错,还需要再确认的情况 用例设计原则说明: 1、单个功能的用例设计条数需要考虑其重要程度、重要性高的功能,用例设计就相对完善、相对丰富些,重要性比较低的功能,用例设计的力度就小一些。 2、Level1级别的用例多考虑正常流,少考虑异常流。 3、单条用例执行的步骤和预期结果的条数要控制,步骤太多的话,容易引起测试遗漏。 4、一个用例只有一个测试点。 测试用例更新及维护: 用例维护的方式: 1、根据刷新后的需求说明书,更新用例。 2、根据提交给测试的软件版本的具体实现,刷新用例。 3、根据非pass用例的执行结果,进行分析后,刷新用例。 4、对每个版本发现的问题进行分析,找到测试设计遗漏点,刷新用例。 5、软件功能转测试后,出现变更,追加或删除,刷新用例。 6、需求掌握程度加深后,发现测试设计遗漏点,刷新用例。