测试流程

需求分析

整体流程图：

需求提取 -> 需求分析 -> 需求评审 -> 更新后的测试需求文档

1. 需求提取：

分析依据（包括：需求矩阵、产品交互图、需求说明书）

客户价值

可以为客户带来哪些价值？

可以解决哪些问题？

根据以上问题定位功能是否合理

UI功能 - 展示功能

模块关联-历史模块

新功能模块关联

考虑是否关联？耦合部分是否需要支持？

客户使用场景-部署方式

网络特性

客户使用服务器常见外设

性能参数-性能要求

网卡最低速率

硬件支持

输出（提取最原始的测试需求）

2. 需求分析：

产出最初的需求文档

明确产品给客户带来的价值

明确产品支持和不支持的功能

明确产品各个功能的约束性

知道开发实现功能

知道测试分析和产出测试点

3.需求评审

产品经理组织开发人员与测试人员针对需求文档进行评审

4.测试需求文档

评审后的需求文档交给测试人员写测试用例，针对需求进行测试。

用例设计

1.测试需求分析

        从项目部拿到软件的需求规格说明书后，开始对项目的需求进行分析，通过自己的分析、理解，整理成为测试需求， 清楚分析出被测试对象具有哪些功能。 明确测试用例中的测试集用例与需求的关系，即一个或多个测试用例集对应一个测试需求。

2.业务流程分析：

        分析完需求后，明确每一个功能的业务处理流程，不同的功能点作业务的组合，以及项目的隐式需求。如遇复杂的测试用例设计前，先画出软件的业务流程。从业务流程上，应得到以下信息：

A、 主流程是什么?

B、 条件备选流程是什么?

C、 数据流向是什么?

D、 关键的判断条件是什么?

3.测试用例设计

        完成以上两步则可进行测试用例设计，功能测试用例，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题。设计测试用例的常见方法：1）等价类    2）边界值    3）因果图    4) 判定表    5) 状态迁移    6) 正交实验    7) 场景法    8) 错误推断

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

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

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

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

4）测试用例是否具有指导性，是否能灵活的指导软件测试工程师通过测试用例发现更多的缺陷，而不是限制他们的思维；

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

6）画出软件需求跟踪矩阵，验证测试用例是否完全覆盖了需求，验证测试用例的覆盖性；

7）测试用例是否完全遵守了软件需求的规定。这一点其实有一些难做到。考虑到时间/成本的关系，应该视具体情况而定。

5.测试用例更新完善

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

用例执行和回归

1. 执行优先级

建议用例级别执行顺序【bvt、leve1、leve2、leve3】

建议用例区域执行顺序【基本功能、高风险区域、复杂逻辑优先测试】

2. 用例执行状态

Not Complete：用例无效、用例错误、无测试环境等过程状态

Passed：执行通过

No Run：默认状态，未执行

N/A：无须执行，需填写备注，需处理；

Failed：执行失败，需填写BUGID

Blocked：被其他问题阻塞

Not Modify：由Failed状态而来，用例发现的bug不修改，bug为halt、Won't Fix

3. 自动化用例

覆盖全部bvt用例

大部分level1（基本的功能一定要覆盖）

bug回归标准

1. bug分类：

low【UI问题、体验问题】

medium【基本功能问题】

high【性能问题】

urge【宕机、无法使用、数据丢失、业务无法使用】

2. 模块质量分析

缺陷分析

用例质量分析

测试漏侧分析

需求变更分析

模块改动分析

发散测试分析

重点难点分析

开发人员评价

回归测试分析

测试报告

        根据测试情况写测试报告，对整个测试过程和版本的质量做一个评估。测试报告的内容可以总结为以下目录：

首页

引言（目的、背景、缩略语、参考文献）

测试概要(测试方法、范围、测试环境、工具)

测试结果与缺陷分析（功能、性能）

测试结论与建议（项目概况、测试时间 测试情况、结论性能汇总）

附录（缺陷统计）