功能测试-测试流程与用例

上一篇我们理解了软件的生命周期和不同的软件开发模型，这一篇我们开始逐步挖掘在整个生命周期或者开发模型中的测试过程

测试流程

所谓测试流程就是软件开发过程中的测试过程。因开发模型或公司组织形式的不同，可能有不同的测试流程，但总体上分为几大部分：需求阶段、开发阶段、测试阶段、上线（维护）阶段

• 需求阶段（最重要的是搞清楚：测什么，即测试内容、测试范围）

  • 不同的项目组采用的开发模式不同，对需求的关注度不同，测试的参与度就完全不同

  • 以敏捷开发模式为例，敏捷的核心是协作和迭代，就需要不同的角色在快速迭代中高效协作

  • PO完成需求的萃取、需求的描述、需求的拆分、需求的优先级排序、版本计划等

  • 测试根据排期的需求，参与需求澄清活动（会议），在会议上根据自己的理解和经验提出自己的疑惑或者指出需求不明晰的点，并得到回应

  • 测试根据澄清后（修改后）的需求，提取测试重点，根据测试重点，参与编写自动化用例场景

  • 参与自动化用例评审，根据开发进度的要求，标识必须完成的自动化用例（理想情况是完成100%）

  • 测试根据版本计划编写版本测试计划

  • 参与版本的迭代计划和版本任务的评估

• 开发阶段（最重要的是编写用例）

  • 根据已评估好的任务，根据优先级依次领取任务，可以是一个开发任务对应一个测试任务

  • 测试在开发的初期需要去完成场景化（手工）用例的编写，主要是覆盖自动化缺失的部分

  • 测试主持场景化（手工）用例的评审，如果有安全性相关的用例，还得考虑安全测试的用例

  • 开发接口调试通过后，测试参与编写自动化用例，并根据断言，反馈缺陷

  • 当然也可以先写好测试和断言，通过执行测试来反馈业务代码的正确性

  • 一个业务功能完成自动化验证后，也可以进行手工测试其他场景

  • 版本所有的功能开发完成后，部署测试环境，进行冒烟测试（手工，自动化都可以）

• 测试阶段（最重要的是执行用例，提交缺陷）

  • 冒烟测试通过后，根据提测申请邮件，正式进行轮次测试

  • 根据已评审通过的用例，执行测试用例，更多的是关注复杂场景下、异常情况下的程序反应

  • 发现缺陷，详细描述缺陷发生过程，最好是图文并茂，以方便重现

  • 跟进缺陷的修复进度，并了解缺陷修改影响的范围

  • 重新部署测试系统，回归缺陷，并根据影响范围进行回归测试（手工+自动化）

  • 进行探索性测试

  • 测试结束，编写测试报告，发送测试通过的邮件

  • 统计各阶段发现的缺陷、测试周期、自动化、手工用例等

  • 根据统计结果生成图表，对比之前的版本，看趋势变化

  • 重点分析重复用例（自动化与手工一样的用例）发现的缺陷，逐步提升自动化用例的质量

  • 补充有价值（高频调用）的手工测试用例场景进自动化用例中，不断丰富测试场景

• 上线（维护）阶段（最重要的是分析痛点，挖掘新需求）

  • 准备上线测试用例（选取上线测试用例），在更新应用后，手工或自动化执行

  • 根据日志、监控、用户反馈等多渠道了解版本运行情况

  • 建立生产缺陷用例集（库），定期统计每个版本上线后的缺陷情况

  • 定期进行总结和分析，结合多方收集到的信息，提取痛点，转化为需求，进行优化

测试用例

测试用例是测试的基础，也是测试思维、测试技能直接的体现。现在从测试用例的要素说起

• 测试用例所属的项目

  • 测试用例服务于某个特定的对象，为了方便管理和查询，一般都会把用例归属于某一个项目组

• 测试用例的类型

  • 用例的类型有多种分法。如果是平台（集成）型的用例管理系统，用例类型可能分为：功能、自动化、性能、安全等

  • 如果只是单纯的用例管理系统，可能分为冒烟、接口、手工等

• 测试用例的优先级

  • 优先级一般是根据用例的重要程度和用例的执行顺序来确定的，越重要的用例优先级越高，每个项目基本上都会定义高、中、低或者P0、P1、P2或者更细分的级别

• 测试用例编号

  • 一般是系统自动生成，或者手工进行编号

  • 这一串编号一般都会包含项目组+项目类型+xx+随机数或者自增序列

• 测试用例名称（标题）

  • 用例场景的简要描述，体现用例的测试重点和测试结果

  • 一般都会有一些统一的前缀，方便管理和查找

• 测试用例的前置（提）条件

  • 场景或者流程性用例一般都会有很多前置条件，必须在满足某一些前提条件下，才能出现某个现象或者某种结果

  • 或者很多个性化的配置和开关甚至开关、配置组合才能测到某一种场景

• 测试用例的步骤

  • 用例的核心就是用例步骤，详细描述用例的执行过程和期望结果

  • 体现业务的熟悉程度和场景的复杂性

• 测试用例的预期结果

  • 预期结果就是对需求的进一步细化和验证；与预期结果不符，可能就是缺陷

• 测试用例编写人员

  • 当测试团队比较大时，方便分工和管理，当然也是方便统计个人工作产出

• 测试用例编写时间

  • 一般是系统自动生成，主要是方便后期查看用例变更（修改）历史

• 测试用例的备注

  • 用于特殊说明或区分手工或自动化执行

以上是一条测试用例必不可少的要素，因项目或公司的不同，可能还会其他额外的字段，说完了用例的要素，现在说说测试用例的设计方法

用的比较多的是等价类、边界值、错误推测、场景、功能图法了

详细说明见测试方法:
 

测试用例评审

使用不同的测试方法编写完了用例，就需要相互看看用例是否有缺失，这个过程就是测试用例内部评审（同行评审或者叫交叉评审），但正式的评审需要参与的角色就很多了。比如测试人员（负责人）、开发代表（负责人）、业务代表（负责人）、甚至产品经理等

正式用例评审过程一般如下：

• 约人（邀请各方代表）

  • 各方代表可能都不在同一个地方工作，就需要提前预约、协调好时间，确定关键人物一定能按时参会

• 定时间和会议室

  • 得到肯定答复后，就需要提取预约会议室、投影仪或其他通讯设备、提取准备好用例

• 正式评审

  • 提前几分钟进入会议室调试好设备、保证会议能准时开始

  • 提醒参会人员准时参会

  • 按照顺序简述需求、并开始讲述设计思路和用例概况，如有必要，每一条用例都展示一遍

  • 接受会议人员的提问或提出自己的疑问

  • 记录有问题的用例或缺失的场景

• 修改提出的问题

  • 会议结束后，根据记录情况，修改或新增用例，保障用例

  • 发送修改后的用例给参会人员，当然也可以只发送给提出问题的人员

  • 用例无问题后，发送用例评审通过邮件，并附上会议记录需要修改的问题

说完了用例，接下来就是说缺陷了