功能测试步骤

1.了解业务背景

任务开展前首先熟悉测试对象的业务背景，掌握业务有关的背景知识，这类业务是怎么产生的，操作业务的人员需要进行什么操作，用户使用的时候要进行何种操作等等——换位思考分析业务

2.需求分析

1、把用户需求转化为功能需求

2、把握此次测试的范围及工作量

3、更深入的了解被测对象——流程和功能

4、明确其功能对应的输入、处理和输出

5、把隐式需求转换为明确的需求

2.1 功能分析

业务功能：与用户实际业务直接相关的功能或者细节

辅助功能：辅助完成业务功能的一些功能或者细节（如搜索查询模块）

权限需求：在执行功能的过程中，根据不同的权限能进行不同的处理，展示不同的数据

易用性需求：产品中必须提供，便于功能操作的一些细节（如快捷键操作）

编辑约束：在功能执行时，编辑的过程中对一些输入的数据进行条件约束（如只能输入数字）

2.2 场景分析

从需求的角度出发，分析功能内部和功能直接场景的组合（基本流，备选流）

列出功能的主要业务流程与备选流，使用笛卡尔乘积方法进行条件的组合（每一种场景都可能调用不同的外部模块）

考虑系统内部各个场景之间的：形成内部业务流程，需要分析每个场景之间的约束关系，执行条件，组织出各种业务流程图

最后根据经验分析，常用的或者规定的业务流程，各个业务流程分支的遍布，明确规定不可以使用的业务流程，其他异常或者不符合规定的操作

3.测试点设计

写用例的之前一般是先写测试点，然后再写测试用例，也可以这么理解，测试点就是精简版的测试用例。编写测试点时标题可做测试用例的标题。

（在测试点设计的时候，需要思考如下几点：

测试操作的难度：

       测试操作包括环境、配置、执行等因素，在测试点设计时，尽量减小操作的难度。

重要性及优先级：

       测试点一定要区分重要性及优先级，以便在实际项目测试中进行选择。重要性部门建议突出内部测试、外部验收、线上问题等标签，便于管理和分类更新。）

3.1  以功能点为主编写测试点（点）
点阶段是项目测试前期执行中的最小单元，这个阶段测试点的设计及执行有几个要求：

3.1.1    测试点设计要简单、独立、明确、减少与其他测试件的交叉

3.1.2    测试点设计的范围局限于单个模块内部

3.1.3    测试点的设计以功能模块为主，性能指标，可靠性，可用性 等暂不涉及

3.1.4    测试点的设计以正向测试为主，异常测试及复杂场景及交互暂不考虑

3.1.5    测试点的设计优先简单，执行难度小，功能最核心的部分，今早暴露问题

3.1.6   具体依照项目资源合理安排，重点是模块内部的基本功能测试

3.2   以功能面为主编写测试点（面）
面阶段是项目测试中期执行中的单元，这个阶段测试点的设计及执行有几个特点：

3.2.1    测试点的设计变复杂，考虑单模块内的异常和复杂场景

3.2.2    测试点设计不仅包括单模块内的复杂设计要求，还应有模块间的交互

3.2.3    测试点以功能验证为主，单模块及模块间的性能指标、可靠性等可以设计

3.2.4    测试点以正向测验为主，异常测试及复杂场景模拟为辅

3.2.5    编写测试点的优先策略：优先最核心的，必要的性能和异常场景，今早暴露问题

3.2.6    重点是模块内部的高级功能和模块间的交互

3.3   以“体”为主；系统、性能和异常模拟（体）
3.3.1    测试点设计要复杂些，考虑被测系统多模块（全模块）内部的功能、性能、稳定性、可靠性、安全性等指标

3.3.2    测试点的设计范围不仅包括不仅包括被测系统多模块（全模块）级别的测试，还包括系统与外界环境的兼容性等

3.3.3    测试点设计以被测系统多模块/全模块的正向测验，功能性能全部通过之后是异常测试及复杂场景模拟

4、测试用例设计
       编写测试用例之前我们需要对项目的需求有清晰的了解，对要测试什么，按照什么顺序测试，覆盖哪些需求做到心中有数，作为测试用例的编写者不仅了解要有常见的测试用例编写方法，同时需要了解被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构。

功能测试用例，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题。

设计测试用例的常见方法：1）等价类    2）边界值    3）因果图    4) 判定表    5) 状态迁移    6) 正交实验    7) 场景法    8) 错误推断（注意：编写测试用例时，我们尽可能取的不应该是有效等价类而应该是无效等价类）

4.1    编写完成后自我检查以及部门内部评审：

4.1.1 测试用例本身描述是否清晰，语言准确，是否存在二义性

4.1.2 测试用例内容是否完整，是否清晰的包含输入和预期输出的结果，测试步骤是否清晰

4.1.3 测试用例中使用的数据是否恰当，准确

4.1.4 测试用例是否具有指导性，是否能灵活的知道测试工程师执行用例从而发现bug，而不是限制思维

4.1.5 是否考虑到用例的执行效率，对于不断重复的执行步骤，是否保证了验证点相同；或者测试用例的编写是否存在冗余性等。这些都会导致执行用例效率低下。

4.1.6 用例是否完全覆盖了需求，验证测试用例的覆盖性（用到 Requirement Tracking Matrix）

4.2  测试用例更新完善

       测试用例编写完成之后需要不断完善，如遇需求更改或功能新增时，测试用例必须配套修改更新，同时在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善;在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。

5、测试用例执行
首先搭建测试环境，准备好测试数据，进行冒烟测试，通过之后按照测试用例进入正式测试，有效的测试执行可以将测试用例发挥最大的价值。因此，测试用例规范执行有助于更好的发现代码中存在的缺陷。根据个人测试工作经验，好的测试执行应该包含如下内容：

5.1 测试执行中评估测试执行时间不足，需及时上报风险，满足质量优先，进度其次原则。

5.2 测试用例按优先级顺序执行，通常是基本、详细和异常顺序执行

5.3  未执行用例，或者标志位删除的用例或者无效的用例，需注明原因

5.4  执行过程中有疑问的用例，需找设计人员沟通

5.5  测试执行需要对用例描述的检查点逐一检查，避免遗漏

5.6  重视不宜重现的缺陷场景，可能是一个bug

5.7  执行过程中发现有前期设计缺陷遗漏用例需要补充到用例文档并执行

5.8  建议测试人员交叉执行重复的测试用例，避免可能的缺陷一直遗漏

5.9  测试结束，将最终测试用例文档上传到归档目录，实现用例重用。