前言

本篇主要就是记录一下怎么展开测试工作，但是这个肯定是最官方的。不是适合所有的工作环境，只能作为一个参考，让新人不至于一脸懵逼的就开始工作。

测试需求

什么是测试需求

测试需求的主要是用来指明被测对象中有什么需要测试。通过对对开发需求的细化和分解，形成可测试的内容。测试需求应全部覆盖已定义的业务流程，以及功能和非功能方面的需求

测试需求的特征

制定的测试需求项必须是可核实的，无法核实的需求不是测试需求。测试需求应指明满足需求的正常的前置条件，同时需指明不满足需求时的出错条件；

为什么需要测试需求

用来做开发测试用例的依据
保证测试的质量和进度
作为衡量测试覆盖率的指标

测试计划

什么是测试计划

测试计划就是描述所有要完成的测试工作，包括被测试项目的背景、目标、范围、方式、资源、进度安排、测试组织以及测试风险等方面。

测试计划的作用

为测试过程提供指导（测试目标、测试内容、测试方法、测试时间周期）
改善测试任务与测试过程的关系
提高测试的组织、规划和管理能力

制定测试计划

1.做好测试资料的搜集整理
2.明确测试目标，增强测试计划的实用性
3.坚持”5W”原则（不知道的话就往前翻一翻我的文章，或者请教度娘）
4.采用评审和更新机制，保证测试计划满足实际需求

测试计划的内容

每个公司的要求不一样，大同小异。不要上纲上线
1.测试项目简介
2.测试范围（不晓得啥是测试范围就往前翻一翻我的文章，或者度娘）
3.测试的方法（测试人员，测试工具，流程）
4.测试环境（软件，硬件等）
5.测试的开始条件和结束条件
6.测试时间安排
7.测试进度与跟踪
8.测试风险与解决
9.根据你公司要求做一个CRUD（不知道啥叫CRUD就去问你公司程序员）

测试方案

有的公司会做，有的不需要做，反正我公司是没有做，但是不需要做不是你不去了解的借口。

目的

明确要测什么、怎么测，达到什么样的质量标准

测试计划与测试方案的区别

测试计划主要是管理文件，强调的是“做什么”，需要确定组织架构，工作任务的分配，工作量的估计，人力物力资源的分配，进度的安排，风险的预估和规避，确定任务的通过标准。
测试方案主要是技术文件，强调“怎么做”，需要对测试需求做细化，明确测试框架的设计，测试数据和脚本的设计，测试用例的设计原则。

黑盒用例

黑盒测试也叫做功能测试（大部分时候你在做的），数据驱动测试（B格高的一个称呼）或基于规格说明书的测试，是一种从用户观点出发的测试。

常见错误分类

1.不正确或者遗漏的功能；
2.接口或者界面错误；
3.性能错误；
4.数据结构或者外部数据访问错误；
5.初始化或者终止条件错误等；
（以上如有不懂请面向百度测试）

黑盒测试用例设计技术

1.等价类划分法（超级重点）
2.边界值法（重点，是对等价类划分法的一个补充）
3.场景法（也叫流程分析法）
4.因果图法（组合情况的时候使用，但是大部分情况下我们都不画图的）
5.错误推测法（多干几年就会有对可能存在的错误的嗅觉了，靠经验判断）
6.正交实验设计方法（选择部分有代表性的点进行实验，可以百度）

这些是比较常用的用例设计方法。不要出现杠精吵着说没有列举全面这种 话啊。我又不是你father。啥都给你弄好了。

怎么选择测试方法

举一个我经常用的方法，而且也是大多数人都在用的一个方法
1.先进行等价类划分，包括输入条件和输出条件，将无限的测试变为有限的测试。这样可以减少工作量
2.在等价类划分的基础上添加边界值分析的方法。开发人员有时候会因为失误导致边界值没有判断的情况
3.根据你的经验判断哪里可能会有问题。追加一些针对的测试用例
4.检查设计出的测试用例是否达到要求的覆盖标准，如果没有，在补充足够的测试用例。
5.灵活使用测试用例方法设计测试用例。学会根据你们的业务情况变通。

测试用例的设计

测试用例是一份测试文档，它描述输入、工作和一个期望的结果，目的是确定应用程序的某个特性是否正常的工作

测试用例设计原则

1.用语简洁清晰，但不能过于简单，要描述清楚
2.用语无歧义，尽量少使用过长的句子，不要使用语气助词
3.用例的各个基本素要齐全，不能缺失
4.用例步骤详细，操作明确
5.用例设计要易于读懂，能被顺利执行

编写元素

用例编 、用例标题、用例级别、前提条件、操作步骤、预期结果、编写人、备注

粒度

粒度指的是粗细程度。粒度大，就是说一个用例所涵盖的关注内容比较多，粒度小，就是说一个用例所涵盖的关注内容比较少
用例的粒度大，总的用例数就少，用例看起来就比较简介
用例的粒度小，单条用例关注的测试点就很集中，不容易遗漏，并且执行需要的时间比较 估计

最后

把你的文档文件按照项目归类好，不要乱存乱放。注意维护你的测试文档，测试文档不是初期写完就结束了，是需要经常维护的。散会！