测试计划在测试人员工作的安排中起一个承上启下的作用。

是整个测试流程里面必不可少的一部分。

### 1、测试用例的好处
####A.任何测试人员都可以执行
可以给不是很熟悉该业务或者该模块的新同事直接去执行，而不需要去反复再同开发、产品对接，或者是猜测该条用例的意思或者意图。

####B.减少不必要的沟通成本、节省实际执行时间
一条步骤清晰的用例，完全可以照着一步步执行，预期结果清晰，则可以很容易地断定该条用例是否通过，前置条件清楚明白，则可以顺利执行。

####C.尽可能的减少重复劳动
在实际的工作中，我们会发现A同学写的用例交接给B同学之后，由于用例步骤不详细、前置不清晰等，导致无法理解、执行，然后会去重写该模块的用例，这就导致工作成本的增加。

####D.归档
为后续的迭代、回归，回溯或者交接等提供清晰的依据以及指导，测试用例是项目的财富，一点不比源代码重要。

### 2、测试的目的
测试目的，就指为了某个计划应该达到的预期目标进行一系列的检查工作。

### 3、什么是测试用例
是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。

其内容包括：
```
测试目标
测试环境
输入数据
测试步骤
预期结果
测试脚本
...
```
等等，最终形成文档。

简单地认为，测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。

### 4、如何制定测试目标
在编写测试用例之前，需要先清晰自己的测试目标，而测试目标又要从以下几个方面着手：
```
理解系统
及早介入
理解企业文化和过程
测试期望
吸取教训
工作量大小
解决方案的类型
技术选择
预算
时间表
分阶段的解决方案
```

### 5、测试项目简介
```
产品规格
产品名称
开发者
版本号
产品信息
产品的所属用户
开发该产品的背景
技术结构
测试用例中引用的文档或书籍
```

### 6、测试日常工作文档
```
测试用例
提供测试用例模板
确定测试用例编号规则
测试日志
提供测试日志模板
缺陷报告
提供缺陷报告模板（包括包含哪些内容）
缺陷跟踪系统还是电子文档
确定严重程度和优先级别
如何划分
测试总结
提供缺陷总结模板
```

### 7、测试策略
测试策略描述测试小组用于测试整体和每个阶段的方法。

确定测试策略要从模块，功能，整体，系统，版本，压力，性能，配置和安装等各个方面来考虑。

### 8、测试阶段进入、退出标准

进入标准：允许系统进入一个特定的测试阶段时所必须具备的条件

退出标准：规定测试何时结束的条件

### 9、确定测试内容
功能的测试：理论上测试要覆盖所有的功能项

UI的测试：对一些用户界面，菜单的结构还有窗体的设计是否合理等的测试

性能的测试：安全性、压力并发情况，响应时间均值等。

整体考虑：要考虑到数据从软件中的一个模块流到另一个模块的过程的正确性

结合之后，确定功能项优先级、风险、复杂度、客户需求来进行分阶段测试。

### 10、资源
需要提前申报测试资金、测试数据支撑等。

### 11、测试进度
```
安排测试进度的重要性
计划测试进度和人员安排要考虑
记录当前项目每项任务实际花费的人员和时间
考虑测试组织的测试成熟度
测试需求范围
测试工程师的技术水平
使用测试工具的熟练程度
商业知识
测试程序的范围
测试工作的启动
软件计划升级的版本个数
高风险的应用程序
里程碑时间的设置
```

### 12、测试人员的任务分配
按照测试组人员的技术水平、空闲状态，合理安排测试任务。

### 13、测试用例的内容

#### A、八个基本项
```
用例编号
测试项目
测试标题
重要级别
预置条件
输入
操作步骤
预期输出
```
#### B、在上面的基础上，还可以扩充到更详细的选项
（不同公司的测试用例内容不尽相同）：
```
用例编码
用例名称/标题
测试背景
前置条件
优先级
重要级
测试数据
测试步骤
预期结果
实际结果
测试人员
测试时间
备注
是否自动化
```

#### C、关于手工测试用例编写注意事项
测试用例不要上来就写

很多人可能都有这种习惯，习惯不管什么时候，拿到一个需求或者页面就开始着手写用例，把一些简单的用例直（hu）接(luan)写出来。

最后，简单的用例也没能写完整，条件动一句西一句的拼凑，交互流程也是错的，最后还不清楚需求点有没有遗漏，测出来的产品发到生产环境都有未触达的BUG。

1、应该熟悉并仔细阅读需求说明书，但是现在很多互联网公司都是敏捷测试，可能需求说明文档就没有传统测试那么详细，很多细节都需要主动去沟通和确认。

2、编写过程中需要仔细思考，产品的用户群是什么样的，到底用户想要的结果是什么，也就是用户思维（但如果产品没有用户思维，你就按原型的思路去思考）。

3、用例编写过后，需要给组内人员进行评审，一个人可能不能兼顾那么多点，但是组内人员大家一起讨论，会产生不一样的效果哦（很大概率会补齐测试用例，更加完善）。

#### D、编写测试用例的方式
在编写测试用例的过程中，虽然清楚需要侧重的点是什么，但还需要用例思维，我之前用过这三种方式进行编写：

1、传统的用例编写模式：

Excel 表格（或者是测试管理工具）中，输入用例内容条件进行栅格保存。

2、脑图思维方式编写：

在 Excel 表格中，从一级开始向外延伸，一级、二级、三级……八级这样去思考，比较不容易丢下测试重点，也利于大脑进行思考，掌握全局观念。

3、思维导图方式编写：

在 Xmind 中进行编写，这种方式其实和脑图思维比较像，都是依靠一个功能点或者中心点思维慢慢向外延伸进行编写用例，而且思维导图中还可以添加一些任务进度和优先级这种标志，比较方便测试人员进行标记记录。

已有0条评论

添加新评论☺

如果认为本文对您有所帮助请赞助本站

支付宝扫一扫赞助

已有0条评论

添加新评论☺