规范软件测试流程

测试计划　　做任何事情都会有输入输出，对于测试过程我们可以把输入理解为测试计划、测试环境准备、测试工具的选择等等，输出可以理解为测试结果。测试用例设计即可以理解为以测试计划为输入的输出，也可以理解为以测试结果为输出的输入，在这里咬文嚼字没有任何意义。所有的这些书籍和过程文档无外乎告诉我们一个道理，做测试需要做好准备工作，把做一件事需要做的准备工作做好，明确做这件事的目的，最终达成目的并验证结果是我们要做的事情。这要求我们有一个完善的“测试计划书”。
输入：测试目的，测试计划，测试用例设计书，测试环境
输出：测试结果报告书，BUG票，BUG分析，追加测试用例
测试计划的编写工作应该从以下几个方面考虑问题：
1、要充分考虑测试计划的实用性，即，测试计划与实际之间的接近程度和可操作性。　　编写测试计划的目的在于充分考虑执行测试时的各种资源，包括测试内容、测试标准、时间资源、人力资源等等，准确地说是要分析执行时所能够调用的一切资源以及受各种条件限制，可能受到的各种影响。说的再明确一点就是要“计划”“如何”去做“测试工作”，而不是“如何编写测试计划”。
2、要坚持“5W1H”的原则，明确测试内容与过程。
◇ 明确测试的范围和内容（WHAT）；
◇ 明确测试的目的（WHY）；
◇ 明确测试的开始和结束日期（WHEN）；
◇ 明确给出测试文档和软件册存放位置（WHERE）；
◇ 明确测试人员的任务分配（WHO）；
◇ 明确指出测试的方法和测试工具（HOW）。
测试用例
为什么说测试用例重要？
测试用例的重要性是毋庸置疑的，它是软件测试全部过程的核心，是测试执行环节的基本依据。
测试用例主要设计方法
● 错误推测法
● 场景法
● 等价类划分法
● 边界值分析法
● 判定表法
● 因果图法
● 状态迁徙图法
● 流程分析法
● 正交分析法
● 正交实验法
如果是自己做的设计，自己PG，其实错误推测法，场景法，流程分析法收效会明显得多。因为熟悉流程，所以对可能存在问题的地方也是一目了然，不过这些对经验的要求又太高。
改进测试用例执行过程
● 项目的测试负责人和测试工程师参与软件需求调研，以测试角度分析需求的可测性，可构思将来对其测试的方法、原则等；更重要的是，对不可测或难以测试性问题要及时与客户或项目经理协调解决。
● 全面了解系统需求，从客户角度考虑软件测试需要达到的验证状态，即何些功能点需重点测试、何些无需，以便将来制定测试计划。
● 有健全且严格的体制保证测试执行者严格按照测试用例执行测试。
● 如有对测试用例认识模糊或内容遗漏的地方，可暂做记录待后期解决，或经测试负责人与项目其他管理人员同意方可更新用例库。
● 测试负责人每日负责跟踪本测试子周期或阶段的测试用例执行情况，以及每日提交的缺陷报告，根据执行进展状态以及缺陷数量或严重等级与项目高层或其他人员展开交流，商议解决途径，并确定或调整未来时间的测试任务。
● 测试执行者负责执行自己区域的测试用例，还要负责跟踪该区域软件缺陷的修改进展，根据其状态不断验证软件功能点。
● 通过缺陷管理工具来管理软件缺陷；这样的集成工具都提供了清晰的报告模版及强大的追踪功能，测试团队的每一成员按照自己的角色和权限访问缺陷管理工具，并不断跟踪软件缺陷的状态。
测试过程
测试的过程应该为五个阶段，分别是发现问题、问题解析、解决方案、执行、验收。
发现问题
这个步骤最重要的就是发现(Discover)问题，详述(Discribe)问题,并且正确而详细地记录(Document)下来。在进入下一步骤前，我们测试人员应该问问自已以下这些问题：
对于问题是否已经有简明的描述。这一部分我们经常会犯的错误有2点：
● 过分熟悉流程的测试人员，这是由于目前我们的测试人员和开发人员没有独立，会直接把问题解析写在问题描述中，虽然当时方便了问题解析对问题的解决节约了时间，但是当日后发生类似问题时由于没有恰当的问题描述导致问题解析无法比对，反而浪费了人力。
● 是问题描述过于含糊。如“XXXX-XX-XX发现系统死机”，这样的描述对问题解析者来说无疑大海捞针，问题记录者应详尽的描述问题发生的背景，场合，以用记录描述可以再现为要求描述问题，根据问题描述可以在实验室环境再现问题。
严格比对测试输出，避免错过问题。
经常会有问题明明PT甚至MT阶段就能发现却遗留到了ST阶段。这是由于我们在测试过程中没有认真比对结果造成的，协议栈测试最重要的测试成果物就是LOG，是否对LOG中每一个接口，每一个参数进行了确认。如果时间紧迫不可能对每一个参数进行检查，最起码是否对我们关心的参数，对关键流程进行了检查。有时候很多问题时仔细看LOG就能发现的。所以，
● 严格比对测试结果是否为测试用例的期望。
● 对关键流程和关键参数进行检查。
● 测试一定要经过回归验证。
问题解析
Explore the conditions：探究原因，为问题提供明确的定义与定位。
这个步骤的主要任务：是广泛搜集相关数据，尽量了解系统的每一个方面，避免深入分析时，漏了某个关键的现象而误入歧途；重点：是探索(Explore)，寻找证据(Evidence),建立(Establish)整个问题的来龙去脉的假设。有2点特别重要：
● 分析问题的时候一定要全面，进行水平展开，将类似问题一网打尽。
● 一定要分析问题的影响。因为一个很小的改动会系统都可能造成难以估量的影响。
解决方案
Track down possible approaches：提供可能的解决方案。
这个步骤的主要任务：深入分析数据间的关联性，并对整个问题的前因后果提出假设，最后拟定出相应的策略(计划)。如果前一个步骤做得不够详实，在这个步骤我们可能就会误判，导致努力了半天，但就是找不到瓶颈点。
对于一个问题可能有多个解决方案，有的实施简单，有的影响小，有的准确性高。这时就有选择和取舍。在问题解决时一定要把所有可能的方案都找出来，不要图简单，因为最简单的不见得是最合适的方案。
取舍的原则：
1. 正确性。不管哪种方案一定是要能解决问题的。如果不能将问题彻底解决不管多简单都不是好的方案。
2. 影响性。一定要选择影响最小的方案。
3. 实施性。当测试紧张时也可选择用临时方案替代，然后再仔细研究应对。因为有些问题的解决并不是一天两天能对应完的，这时就需要一个临时的替代方案。当然做好版本管理非常重要。
4. 及时修正。执行方案时，仍然要注意系统的反应。因为新的证据可能证明你先前的判断错误，因而要修正策略，甚至是退回到上一步以重新拟定计划。
验收
● 确认解决方案成功与否。
● 解决的方式是否有边际效应，造成其他的问题。
● 是否真正根除了问题，还是仅表象地头痛医头，脚痛医脚建立问题的假设时，很容易将问题特殊化，仅局部地解决该现象。
● 建立持续跟踪的计划。当无法确定已经根除问题，那可能就要拟定持续跟踪的计划。决定是否要持续观查某些计数器，跟踪某些现象是否还会发生，若发生了要如何解决等等。
测试用例检查单
1. 是否涵盖了需求文档上的每个功能点
2. 是否涵盖了需求文档上的每条业务规则说明
3. 是否覆盖了输入条件的各种有意义组合
4. 是否覆盖了业务操作的基本路径和异常路径
5. 是否考虑了重要表单字段的数据合法性检查
6. 是否考虑了其他的测试类型（对某个功能很重要，但未在需求文档中提及的，如安全测试、周期性测试和故障恢复等方面）
7. 是否考虑了对其他模块/功能的影响
8. 是否使用了项目组的标准用例模板
9. 用例是否覆盖了测试设计中定义的所有场景
10.用例编号是否统一、规范
11.用例名称是否简洁、明了
12.目的字段是否准确地描述了对应场景的测试输入的特征（不同数据，操作，配置等）
13.前提条件字段的条目是否充分、准确，操作上是否不依赖于同组之外的其他用例
14.对应的需求编号字段是否填写正确
15.用例粒度、预估出的执行时间是否适当
16.同组用例中，仅数据不同的，是否实现了测试步骤的重用
17.某个功能点的第一个用例是否是基本流的
18.操作步骤的描述，是否清晰、易懂
19.操作步骤是否充分和必要，并具有可操作性
20.测试用例的检查点是否明确、充分和可操作
21.单个用例步骤或检查点中是否不再存在分支
22.测试数据的特征描述是否准确，有条件的情况下，是否给出了一个当前环境下的可用参考值
23.文字、语法是否准确；布局、格式是否统一