一、用例标准

黑盒测试关注输入和输出，并不关注内部逻辑，那么用例编写时输入就是我们的条件，即测试场景，输出则为期望的结果。

完整的用例应该是：在某某条件下，怎么做，得到什么结果。

一个用例应该描述一种情况，并且是可执行的，避免描述多个情况。有些时候我们会编写出一些很难执行，或者无法执行的用例。

二、用例选择

1、等价类划分

一个等价类或者等价划分是指测试相同目标或者暴露相同软件缺陷的一组测试用例。等价类的划分，除了考虑一些数据层面的，还要结合实际的实现方案，比如说两个不同页面使用的是相同的后端接口，那么用例只需要覆盖一次后端接口的场景，而不需要两个页面都包含。

在寻找等价划分时，考虑把软件具有相似输入、输出、操作的分在一组。这些组就是等价划分。

2、数据测试

a、边界条件

边界条件指软件运行在计划操作界限的边界的情况，如果要选择在等价划分中包含哪些数据，就根据边界来选择。

编写用例时要有意识得整理被测系统的边界，准确得找出边界条件，这将有利于后续等价类的划分以及提高找到问题的概率.

b、测试边界

提出边界条件时，一定要测试以下这些数据：

• 临近边界的有效数据
• 最后一个可能有效的数据
• 刚超过边界的无效数据

c、次边界条件

指用户无感知，但软件内部存在的边界情况。这个往往是后端的逻辑，很多时候功能测试前端操作都没有问题，但是如果绕过前端，直接向后端请求，很可能没有做校验，从而出现问题.

此外还需要特别考虑：

默认、空白、空值、零值和无

非法、错误、不正确、垃圾数据

3、状态测试

如果一个功能包含明显的状态扭转的实体（这个需要有意识主动识别），需要测试软件的逻辑流程。

状态转换图：梳理被测实体的状态转换逻辑，从而组织用例；状态扭转前置条件包含合法状态、非法状态

及时实体没有明显的状态，也需要考虑失败状态测试，比如：

竞争条件和时序错乱：1、并发问题 2、跳过限制，试图直接扭转实体状态

重复、压迫和负重：1、重复执行相同操作，如幂等性 2、压迫，限制执行条件，如网络异常，外部异常 3、重负，加大处理量，如提供大量任务

三、用例组织

必须花费一定时间进行用例的组织，因为这将更有利于用例的编写、分享、执行；

1、基于产品原型

a、描述

这种方式基本是按照产品原型，页面进行用例编写和组织

b、优劣势

优势：编写简单，直接按原型组织用例；分工简单

劣势：场景容易遗漏；用例组织容易混乱

c、适用场景

几乎所有场景，复杂或单页面功能都适合，这个应该也是大部分测试采用的方式

2、基于角色行为

a、描述

从业务包含的角色出发，梳理角色的行为

b、优劣势

优势：能很好地展示用户的行为，以及可以覆盖用户的使用场景；用例按角色独立编写，多人测试时可各自编写

劣势：角色交互时存在用例重复的情况

c、适用场景

业务流程包含明显的角色及其行为

3、基于业务场景

a、描述

梳理所有业务场景，关联所有用户行为和系统功能

b、优劣势

优势：用例结构清晰，容易覆盖到核心及非核心业务流程；用例重合性低

劣势：用例分工不明确，不利于多人合作编写；场景容易梳理不全

c、适用场景

单一的功能；接口类需求

4、基于实体状态扭转

a、描述

通过描述一个实体的完整生命周期或状态，对涉及的用户行为、操作和系统功能进行编写

b、优劣势

优势：状态扭转可穷举，易于用例划分和编写；始终关注在实体上，清晰各种状态

劣势：用例组织上存在不连贯的情况，可能不利于执行；用例编写上分工可能不明确，存在用例重复

c、适用场景

有明显状态扭转的业务功能，并且主要是围绕实体进行操作

*使用思维导图来组织测试用例，清晰的结构，更容易表达测试意图和执行流程；合理的脑图层次结构需要将测试场景进行归纳，通过不同分支表达不同测试场景 *以上用例的组织方式并不是互斥的，可以相互组合，体现不同的侧重点。

五、用例优先级

…

六、特殊用例（非功能性用例）

如果说功能性用例能保证功能的正常使用，那么非功能性用例能让功能更加稳定和好用。

1、安全性

越权

包含水平权限校验、垂直权限校验

敏感信息

展示层、传输层、存储层的信息安全

常见安全漏洞

包含但不局限于：sql注入、xss、未校验的重定向、csrf

2、兼容性

多端实现

不同的展示层，比如wap、pc、app这些端是否都需要实现，如果不是，修改一个端，是否会影响到其他端

浏览器兼容

客户端兼容

3、性能

是否会产生慢查询

是否有多余io

是否可以添加缓存，添加是否合理

4、关联性

改动是否会影响到相关的其他功能

5、体验性

交互是否合理

文案是否会引起疑惑

页面跳转是否合理

5、数据准确性

数据是否符合预期

这是目前想到的一些大概的东西，具体的内容以后再补充吧~