测试用例

从错测试：

（1）引用/传递的字段是NULL

（2）引用/传递的字段是空值

（3）引用/传递的字段是空格

（4）引用/传递的字段达到最大长度

（5）引用/传递的字段超过限定的最大长度

（6）填写的参数值不符合字段类型

（7）输入特殊字符、ASCII字符等，程序不能报错

上述测试用例只是在对软件的“显式功能”进行测试，作为一名高质量的测试工程师，其他的非功能性需求即隐式功能性需求也是极其关键的。

显式需求与隐式需求
显式需求 显式功能性需求（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、需求掌握程度加深后，发现测试设计遗漏点，刷新用例。