测试入门秘籍<<独孤九剑>>之破剑式-软件测试流程

测试入门秘籍<<独孤九剑>>之破剑式-软件测试流程

破解普天下各门各派剑法。

软件测试环境搭建原则

搭建测试环境前

确定测试目的

• 功能测试，稳定性测试，还是性能测试， 测试目的不同，搭建测试环境时应该注意的点也不同
• 功能测试：不需要大量的数据，需要覆盖率高，测试数据要求尽量真实。
• 性能测试：可能需要大量存量数据或者与实际硬件环境尽可能相似的硬件配置
• 测试的软件环境尽可能的模拟真实环境
• 尽可能的模拟用户使用环境，选用合适的操纵系统和软件平台
• 了解符合测试软件运行的最低要求以及用户使用的硬件配置
• 了解用户常用的软件，避免所有配置所有操作系统下都要进行测试，没有侧重点，浪费时间
• 产品化的测试则需要考虑兼容性的方案

营造独立的测试环境

• 不同的项目、不同的公司会对测试环境的独立性有不同的要求
• 测试过程中尽量保证测试环境独立，不会受到其他测试人员以及项目研发人员的影响

构建可复用的测试环境

• 通过备份或数据隔离的方式
• 重复运用一套测试环境进行多版本多时段的测试

搭建测试环境过程分析

• 线下搭建
• 独立测试服务器或虚拟机
• 测试环境配置
• 测试项目导入

测试环境配置

线下模式

• 配置java环境（下载jdk并配置环境变量）
• 下载并安装中间件（tomcat、jetty或其他）
• 安装数据库并导入初始化脚本

Docker模式

• 构建属于自己的image
• 一键deploy
• 依赖第三方平台

测试环境的建设落地

考虑点：用途、使用成本、维护成本
基本架构：
研发环境：用于研发自测、集成测试
测试环境：用于日常单系统或两两微服务之间测试，可同事集成自动化测试回归
联测环境：完备环境，用于大型联测
外联环境（如果有需求）：稳定版本环境，用于外部商户联调
灰度/沙箱环境：用于生产数据测试，仿真测试

软件测试的过程

简单的测试过程

测试过程划分

• 在逻辑上，测试活动是按顺序进行的
• 在实际测试过程中，这些活动是可以重叠或同时进行的

测试策划概述

• 进行测试需求分析
• 确定需要测试的内容或质量特征
• 确定测试的充分性要求
• 提出测试的基本方法
  

测试策划中想要做的几件事情

• 确定测试的资源（人力和软硬件）和技术需求
• 进行风险分析与评估
• 根据上述分析结果制定测试计划
• 根据测试计划开展相应的测试控制活动

需求测试

需求分析

• 过往的软件生命周期中，需求分析阶段是没有测试人员参与的
• 但随着软件过程的优化，测试人员的加入对需求分析阶段有了更大的作用
• 测试工程师从参与需求分析，对需求了解很深刻，减少与开发人员的交互，节省时间
• 早期确定测试用例的编写思路，为测试打好了基础
• 可以获取一些测试数据，为测试用例设计提供帮助
• 可以发现需求不合理的地方，降低测试成本

需求测试的作用

• 测试需求的分析用来确定整个测试工作，明确测试对象以及测试工作的范围和作用，并作为测试覆盖的基础
• 被确定的测试需求项必须是可以核实的，测试需求必须有一个可观察、可评测的结果
• 如果无法核实的需求就不是测试需求
• 测试需求分析还包括与客户的交流以澄清某些混淆
• 明确哪些需求更重要
• 确保风险承担者尽早地对项目达成共识
• 并对将来的产品有个清晰的认识
• 测试需求是制定计划的基本依据
• 测试需求是设计测试用例的指导
• 确定了要测什么，测哪些方面才能有效设计用例

需求验证

• 第一步： 审查需求文档
• 对需求文档以及相关模型进行仔细检查
• 另外在需求开发期间所做的非正式评审也是有所裨益的
• 第二步：以需求为依据编写测试用例
• 编写简单用户手册
• 在需求开发早期即可起草一份浅显易懂的用户手册，用以描述出所有对用户可见的功能并用它作为需求规格说明的参考并辅助需求分析
• 第三步：确定合格的标准
• 让用户描述什么样的产品才能算满足他们的要求和适合他们的使用
• 将确认合格的测试建立在使用情景描述或使用实例的基础之上

余额宝测试实战

需求规格说明书检查列表

序号	检查项	检查结果	说明
1	用户覆盖了用户提出的所有需求项	是【】否【】NA【】
2	用词是否清晰，语义是否存在有歧义的地方	是【】否【】NA【】
3	是否清楚的描述了软件需要做什么以及不做什么	是【】否【】NA【】
4	是否描述了软件的目标环境，包括软硬件环境	是【】否【】NA【】
5	是否对需求项进行了合理的编号	是【】否【】NA【】
6	需求项是否前后一致、彼此不冲突	是【】否【】NA【】
7	是否清楚的说明了系统的每个输入、输出格式、以及输入与输出之间的对应关系	是【】否【】NA【】
8	是否清晰的描述了软件系统的性能要求	是【】否【】NA【】
9	需求的优先级是否合理分配	是【】否【】NA【】
10	是否描述了各种约束条件	是【】否【】NA【】

需求测试实战

• 以支付宝上新增余额宝业务为例分析
• 原始需求
• 早在2012年左右，支付宝虽然很快被大众接受，但是却面临着一种比较普遍的现象：支付宝账户余额内总有一笔闲置资金，虽然不同账户资金数额有多有少，但总的来说，这笔躺在账户什么做不了的闲置资金数额还是比较庞大的，对于支付宝发展而言非常不利
• 于是产生了这样一个需求，与基金公司合作推出货币基金产品，同时用户购买货币基金后、可直接通过货币基金金额进行支付购买商品或服务
• 审查需求文档->简单看下文档需求
• 需求分析过程中我们会将上面的流程分为：货币基金购买、提现、消费、资产管理、交易查询几部分
• 可以通过需求规格说明书检查列表进行检查

测试策略（测试计划的一部分）

测试前的思考

• 你知道要测试的系统是干什么吗？
• 你了解系统有些什么特点吗？
• 系统有些什么功能？
• 系统哪些部分需要测试？哪些不需要测试？
• 系统对性能有什么要求？
• 系统对安全性有什么要求？

测试策略是什么？

• 测试策略是描述测试项目和测试任务之间的关系
• 它用来说明要测什么、如何测、如何协调测试资源和测试时间等
• 测试策略制定的是否合理高效会对测试项目的进度产生很大的影响
• 如何制定一个好的测试策略并且能防止遗漏呢？
• 一个好的测试策略又包含哪些方面呢？

测试策略要素

测试发布计划->测试范围->测试资源->测试环境->测试方法->用例设计方法->文档管理->风险管理->上线跟踪验证

测试发布计划

• 罗列测试项目本身重要的里程碑
• 每个里程碑都需要有明确的结束时间
• 这个时间可以指导我们后续的测试
• 如果测试时间安排不足，我们就可以在后续的测试范围中挑选优先级比较高的特性来执行测试
• 这样可以最大限度的保证产品的质量

测试范围（按优先级排列）

• 分为In Scope 和 Out Of Scope
• 需要说明哪些模块是在测试范围中的，哪些是本阶段测试不考虑的
• 对于在测试范围中的模块，需要给出优先级
• 以便响应测试时间不足的情况
• 对于不在测试范围中的模块，需要给出原因

测试资源

• 测试资源
• 测试资源在测试策略中也是很重要的一环，它分为人力和工具两部分
• 人力资源主要说明参与测试的人员，当然也可以包括很多的角色，如专业测试人员、客户、产品经理等
• 工具主要是指可能用到其他软件

测试环境

• 测试环境主要包括推荐环境解决方案，操作系统要求，软硬件要求
• 对于推荐解决方案，需要称述的是对测试项目对其他软件的依赖
• 比如测试项目对java有依赖，推荐版本可能就是1.7

测试方法

• 测试方法的罗列主要是为了说明针对测试项目我们要开展哪些类型的测试
• 功能测试是必须的，非功能测试是可选的

文档管理

• 对于一个完整的产品来说，文档是很重要的一环
• 它一般包括安装、升级文档、用户指南等
• 文档不单单是一个文件
• 它需要经过完整的测试才能发布给客户
• 差的文档很可能会误导用户，从而使他们对项目失去信心

风险管理

• 风险管理模块需要罗列出来现在已知的可能会出现不确定性的因素
• 这些因素可能来自技术，资源或者其他方面的

测试计划与测试方案

测试策略

• 侧重需求分析，评估风险，定义测试范围
• 确定测似乎方法，制定测试启动、停止、完成标准和条件

测试计划

• 制定项目测试过程中的测试重点
• 各个阶段的任务分配以及时间进度安排
• 并提出对各项任务的评估，风险分析，可以包括测试策略

测试方案

• 侧重测试的方、测试环境的规划
• 测试工具的选择，测试用例的设计方法、测试代码的设计方案

测试策略VS测试计划VS测试方案

• 实际实施过程中，往往存在这样类似的方式：
• 测试方案=测试计划+用例设计方案+工具选择+自动化/性能测试具体方案
• 测试计划=测试策略+测试任务分配+时间进度安排

测试方案列表

• 1.需求说明

  • 1.1需求汇总
  • 1.2需求变更

• 2.总体计划安排和负责人

  • 2.1测试计划进度表

• 3.测试方案

  • 3.1 测试重点
  • 3.2联测方案
  • 3.3测试策略方法
  • 3.4测试工具平台

• 4.环境搭建部署以及数据准备

  • 4.1环境拓扑
  • 4.2应用部署
  • 4.3数据准备

• 5.测试执行计划

  • 5.1测试计划
  • 5.2正向用例
  • 5.3反向用例
  • 用例评审

• 6.测试工单

  • 6.1冒烟工单
  • 6.2单测工单
  • 6.3联测工单
  • 6.4预发布验证工单
  • 6.5灰度验证工单
  • 6.6线上验证工单

• 7.测试限制以及无法测试功能列表

• 8.测试情况日汇总&风险点、待确认列表

  • 8.1每日测试情况以及风险点

货币基金消费测试方案分析过程

1. 分析需求：当前测试包含需求项（需求文档或wiki链接等）
2. 测试计划（里程碑）以及负责人：整理当前项目各模块测试负责人：整理当前项目各模块测试负责人、任务分配以及测试时间安排
3. 测试范围、测试重点：那些point需要测试，重点放在什么地方，优先级安排
4. 测试策略以及工具：是否需要进行自动化、性能、安全测试？使用那些工具
5. 测试用例设计方法：使用什么样的黑盒测试方法进行设计（等价类？边界值？因果图？等等）
6. 测试环境：测试环境是什么？需要哪些服务器、数据库？配置如何
7. 联调测试：是否需要与第三方或其他部门联调？何时展开？联调包括哪些功能？例如基金公司？
8. 测试限制：在测试环境中哪些内容无法测试？比如消费到账
9. 测试风险：在测试计划测试过程中由于时间安排、测试限制、优先级分布可能带来的测试风险考量

测试评审

测试方案评审

• 目前，开发有需求说明会、设计评审会、代码复审会等各种会议
• 但多是站在开发的角度，从需求和代码层面进行复审和风险规避
• 在测试环节和测试阶段缺少以测试为主体的评审机制和沟通机制

如果不进行测试方案的评审：

• 仅从文档、沟通获取信息，可能会造成信息不对称，认识片面，理解错误或不深入等问题
• 缺少同行交叉评审和开发评审机制，无法充分发挥集体智慧，个人的思维难以突破，可能会出现测试遗漏的情况

评审的目的

• 呈现测试的工作
• 与开发达成共识
• 不同的思维方式碰撞出火花，借鉴别人的思考方式
• 培养这样的行为模式：愿意为团队或他人出谋划策
• 发挥团队协作，最大限度发挥个人的经验，特长，实现技能互补

评审重点

• 采用的测试方法
• 等价类划分的依据
• 测试数据的选取和准备方法
• 流程测试的路径组合
• 数据比对选取的对象和数据检查点
• 是否需要模拟数据以及模拟数据的方法
• 基于风险的测试取舍

测试过程划分