全面系统学测试 从小白入门到实战就业（实战）

『慕课网 imooc』
『全面系统学测试 从小白入门到实战就业（实战）』

第一章 课程介绍

你眼中的测试工程师是什么样的？

• 刻板印象

• 点点点
• 简单
• 没技术
• 工资低
• 能力差
• 没意思

为什么要讲这门课？

我们该怎样胜任一份软件测试工作呢？

打造属于测试小白的一站式学习路线

• 软件工程基础
• 软件测试方法
• 京东实战演练
• 移动测试进阶
• 微信红包实战
• 白盒测试
• 自动化测试
• 性能测试
• 面试经验

夯实基础的第一步

• 软件基础知识（迈入软件测试的大门第一步）

• 软件基础知识
• 软件生命周期
• 软件开发模型
• 软件开发文档
• 软件测试基础
• 软件测试模型
• 测试组织架构
• 软件工程标准

• 功能测试阶段

• 测试设计
  • 边界值分析法
  • 等价类设计法
  • 判定表设计
  • 因果图分析
  • 正交实验法
  • 场景法
• 测试执行
  • 用例执行
  • 缺陷管理
  • 缺陷跟踪分析
  • 易用性测试
  • 兼容性测试
  • …

知行合一的实践

• 微信红包全程实战
• 京东网站实战

微信红包全程实战

• 需求阶段

• 微信红包诞生记
• 红包项目管理流程
• 高效进行微信红包需求分析和需求评审

• 计划阶段

• 拆分红包功能模块
• 知己知彼，设计测试计划
• 用例设计准备：理解设计文档

• 设计阶段

• 用例设计方法之纲要
• “好友红包”用例设计实战
• “群红包”用例设计实战

• 执行阶段

• 冒烟测试与代码走查
• 让“用例”照进现实
• 做“优秀”测试人，出“美丽”缺陷单
• 面对开发，我们何去何从

• 总结上线阶段

• “完成测试”要大声说出 – 测试总结阶段
• 行百里者半九十 – 项目上线

• 后续迭代

• 从需求到迭代
• “面对面红包”的用例设计行
• 迭代关键事之回归验证

测试技能深化

• 白盒测试
• 自动化测试
• 安全测试
• 手机测试
• 性能测试
• 云测平台

面试秘籍

• 简历美化
• 笔试题目实战
• BAT面试风格
• 常见问题剖析

适合人群

• 0基础人群
• 软件测试初学者、刚刚从事软件测试行业新手
• 在校大学生、应届毕业准备从事软件测试行业
• 准备转行进入软件测试行业的小伙伴
• 对测试行业感兴趣的所有朋友

课程收获

• 就业

• 面试初中级测试工程师，独立完成软件测试规划到执行，成功掌握各项软件测试技能，成为合格的测试工程师

• 技能

• 全方位认识学习白盒、自动化、性能、安全等高级测试技术，为前途打下良好基础

• 经验

• 全程热门项目（微信、京东等）辅助学习

• 面试

• 真实一线互联网面经，提高面试技能，增加成功概率

四个学习理由

• 竞争小
• 门槛低
• 前景好
• 薪资高

第二章 【了解阶段：软件测试行业前景】软件测试的发展与职业规划

软件测试的发展–测试基础

软件测试的起源和发展

• 早期 -> “调试”
• 1957年 -> 为了确信自己的产品
• 20世纪70年代 -> Glenford Myers 《软件测试艺术》
• 20世纪80年代早期 -> 软件质量、Bill Hetzel 《软件测试完全指南》
• 20世纪90年代 -> 测试工具盛行
• 2002年 -> Rick和Stefan《系统的软件测试》

软件测试面临的挑战

• 软件规模越来越大，功能越来越复杂，如何进行充分而有效的测试成为难题。
• 门槛低既是优势，也是不足。更多的测试人员在点点点的盲人摸象中摸索。
• 软件技术的迅速发展要求测试人员的水平越来越高，在具备功能测试的基础上提出了更高的要求。

国内外测试现状

• 国内

• 起步较晚
• 从业人员少
• 规模小
• 发展迅速

• 国外

• 软件测试在软件公司中占有重要地位
• 软件测试理论研究蓬勃发展
• 软件市场繁荣

软件测试发展与职业生涯规划

• 软件测试

• 技术方向
  • 黑盒测试
  • 白盒测试
  • 自动化测试
  • 性能测试
  • 安全测试
  • 测试架构
• 管理方向
  • 测试经理
  • 项目经理
  • SCRUM MASTER
• 业务方向
  • 测试专家
  • 需求
  • 产品经理
  • 金融等行业精英

软件测试之“独孤九剑” –每个阶段测试人员的职责

课程介绍

• 基于国内知名IT企业软件测试用人需求。
• 对软件测试人才核心技能培养的特点进行科学的梳理。
• 软件测试工程师应掌握多种测试场景下的多种软件测试技术。

• 独创性的总结出软件测试之“独孤九剑”

• 第一式 总决式-软件测试基础知识
  • “总决式”是独孤九剑心法总纲，而对于测试工程师而言，万变不离其宗，最重要的就是夯实基础。
  • 这一部分让大家了解测试流程、掌握测试各阶段所需的知识及技能，了解软件生存周期各阶段测试人员的指责。
• 第二式 破剑式-软件测试流程
  • 测试流程是每个测试团队的核心，一个完善的流程才能造就一支高效的团队。
  • 如同“破剑式”要破解普天下各门派剑法，我们在这里也要学习破解软件测试的流程及测试策略、计划、方案的编写与评审过程。
• 第三式 破刀式-软件测试设计
  • “破刀式”讲究以轻御重，我们在开始测试伊始，并非要一步到位直接攻其核心，上手测试。
  • 而是需要先从设计入手，这部分我们主要学习常用的测试需求分析、黑盒测试用例设计方法以及常用测试技术应用等。
• 第四式 破枪式-测试执行管理
  • 在这里，我们主要学习测试用例的执行、测试的缺陷管理、跟踪及测试总结，熟悉各种测试文档的撰写。
• 第五式 破鞭式-功能测试项目实践
  • 这一部分我们将前面讲解的测试方法串联起来。
  • 通过一个实战项目，将所学的测试理论知识应用于真实的测试项目中。
• 第六式 破索式-测试技术深化
  • 抵御了常见的武器，现在的测试领域也需要我们掌握更多的技能。
  • 这里我们将学习从自动化、性能、安全以及白盒测试方面的测试手段和方法，对软件测试技术进行进一步深化。
• 第七式 破掌式-手机APP测试
  • 对于现代人来说，最常出现在掌上的自然是手机了
  • 手机APP作为现在比较流行的测试方向，我们将在这部分学习APP测试与WEB测试的不同点，常见的测试点，弱网、兼容性测试模式，并初步介绍APP自动化测试实现方法。
• 第八式 破箭式-测试总结
  • “破箭”，这里指的是暗器。
  • 对于我们测试人员来说，测试任务我们已经完美完成了，为了防止有人说“NO”，咱们没有做好，我们需要对测试过程进行一个总结，有产出才是整个测试的结束。
• 第九式 破气式-面试秘籍
  • 前面我们学习的都是“外功”，最后我们还要学习“内功”
  • 对于破气有云：神而明之，存乎一心。在测试总，最终我们要把自己的能力展现给面试官。

第三章 【入门阶段：迈入软件测试大门】从软件工程到软件测试

• 软件的十大特性–必须掌握

总决式-软件测试工程师基础知识

PART1 软件

软件的概念

• 错误观点：“软件就是程序，软件开发就是编程序”
• 正确观点：软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合

• 程序是按事先设计的功能和性能要求执行的指令序列
• 数据是使程序能正常操纵信息的数据结构
• 文档是与程序开发，维护和使用有关的图文材料

软件十大特性

• 形态特性：软件是无形的、不可见的逻辑实体。度量常规产品的几何尺寸、物理性质和化学成分对它却是毫无意义的

• 智能特性：软件是复杂的智力产品，它的开发凝聚了人们的大量脑力劳动，它本身也体现了知识实践经验和人类的智慧，具有一定的智能。它可以帮助我们解决复杂的计算、分析、判断和决策问题

• 开发特性：尽管已经有了一些工具（也是软件）来辅助软件开发工作，但到目前为止尚未实现自动化。软件开发中仍然包含了相当份量的个体劳动，使得这一大规模知识型工作充满了个人行为和个人因素

• 质量特性：软件是由人编写的，由于其开发特性存在，所以不存在完全没有缺陷的软件

• 生产特性：与硬件或传统的制造业产品的生产完全不同，软件一旦设计开发出来，如果需要提供多个用户，他的复制十分简单，其成本也极为有限

• 管理特性：由于上面的特性存在，所以软件过程中的管理显得更为重要，相比传统行业，也更为独特

• 环境特性：软件的开发和运行都离不开相关的计算机系统环境，包括支持它的开发和运行的相关硬件和软件。软件对于计算机系统的环境有着不可摆脱的依赖性

• 维护特性：软件投入使用以后需要进行维护，但这种维护与传统产业产品的维护概念有着很大差别，维护体现在升级、优化、功能更新等方面。甚至可以全盘重构

• 废弃特性：与硬件不同，软件并不是由于被“用坏”而被废弃的

• 应用特性：软件的应用极为广泛，如今它已渗入国民经济和国防的各个领域，现已成为信息产业、先进制造业和现代服务业的核心，占据了无可取代的地位

软件的分类

• 系统软件

  系统软件是负责管理计算机系统中各种独立的硬件，使得它们可以协调工作。

• 服务性程序：如诊断程序、排错程序、练习程序等
• 语言程序：如汇编程序、编译程序、解释程序
• 操作系统
• 数据库管理系统

• 应用软件

  应用软件是为了某种特定的用途被开发的软件。它可以是一个特定的程序，比如一个图像浏览器。也可以是一组功能联系紧密，可以互相协作的程序的集合

PART2 软件生命周期

基本概念

• 软件的生命周期，又称为软件的生存周期。它是按开发软件的规模和复杂程度，从时间上把软件开发的整个过程（从计划开发开始到软件报废为止的整个历史阶段）进行分解，形成相对独立的几个阶段。
• 每个阶段又分解几个具体的任务，然后按规定顺序依次完成各阶段的任务并规定一套标准的文档作为各个阶段的开发成果，最后生产出高质量的软件。

软件的一生

问题定义 -> 可行性研究 -> 需求分析 -> 概要设计 -> 详细设计 -> 编码和单元测试 -> 综合测试 -> 软件维护

实战介绍一个项目的生命周期

余额宝的诞生

• 问题定义：普惠金融与互联网金融的融合
• 可行性研究：T+0是否可以实现；是否合规
• 需求分析：细分story
• 概要设计：流程设计、架构设计、基础架构等
• 详细设计：接口设计
• 编码和单元测试
• 综合测试
• 软件维护：再次循环

软件开发模型

由于项目、需求的模式不同，所以在软件生命周期过程中选择的软件开发模型也会有所不同，在历史上，软件开发模型经历了“边做边改”、瀑布、原型、螺旋、敏捷等模型的变更。

• 瀑布模型

• 计划 -> 需求分析 -> 设计 -> 编码 -> 测试 -> 运行维护
• 特点：
  • 软件开发的各项活动严格按照线性方式进行
  • 当前活动接受上一项活动的工作结果
  • 当前活动的工作结果需要进行验证
• 缺点：
  • 由于开发模型是线性的，增加了开发的风险
  • 早期的错误可能要等到开发后期的阶段才能发现

• 原型模型

• 客户与开发公司紧密联系，开发周期长。开发会受到需求变更的影响
• 特点：
  • 实现客户与系统的交互
  • 进一步细化待开发软件需求
  • 开发人员可以确定客户的真正需求是什么

• 螺旋模型

• 制定计划 -> 风险分析 -> 实施工程（需求确认、软件需求、软件产品设计、设计确认与认证、详细设计、开发、测试） -> 客户评估
• 特点：
  • 螺旋模型是将瀑布模型与快速原型模型结合起来
  • 强调了其他模型所忽视的风险分析
  • 每一次螺旋包括4个步骤：制定计划、风险分析、实施工程、客户评估
• 缺点：
  • 强调风险分析，但要求许多客户接受并相信这种分析，是不太容易实现的

• 敏捷模型

• 敏捷开发是一种以人为核心、迭代、循序渐进的开发方法
• 特点：
  • 短周期开发
  • 增量开发
  • 由程序员和测试人员编写的自动化测试来监控开发进度
  • 通过口头沟通、测试和源代码来交流系统的结构和意图
  • 编写代码之前先写测试代码，也叫做测试先行
• 缺点：
  • 团队的组建较难，人员素质要求较高
  • 对测试员要求完全掌握各种脚本语言编程，能执行单元测试、自动化测试

PART3 软件开发文档

• 需求分析文档
• 概要设计文档
• 详细设计文档
• 测试设计文档
• 测试用例
• 测试报告

阿里系开发模型的变迁史

开发模型的变迁

• 最早期：边做边改 ->
• 稳定期：瀑布式 ->
• 发展期：敏捷 ->
• 创新期：DEVOPS

BAT测试猿/媛 项目的一生

项目进程

• 编程阶段：单元（白盒）- 测试参与
• 编程完成 - 开发联调（集成测试）- 开发为主
• 提测 - 冒烟测试（自动化为主，手工为辅）- 测试执行
• 测试阶段 - 系统测试（黑盒功能测试为主，自动化/接口测试为辅，根据项目进行性能、安全测试）
• 验收阶段 - 验收测试 - 测试配合用户或需求

PART4 软件测试

软件测试概念

• 经典定义：

• 软件测试（Software Testing），在规定的条件下对程序进行操作，以发现程序错误，衡量软件在质量，并对其是否能满足设计要求进行评估的过程

• 标准定义：

• 软件测试是使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别

• 软件测试目的：

• 软件测试目的在于发现问题，检查系统是否满足需求

软件测试方法和分类

按生命周期划分

• 单元测试
• 冒烟测试
• 集成测试
• 系统测试
• 验收测试

按测试方法划分

• 白盒测试

• 静态分析
• 动态分析
  • 逻辑覆盖测试
    • 语句覆盖
    • 判定覆盖
    • 条件覆盖
    • 路径覆盖
  • 插桩测试

• 黑盒测试

• 功能测试
  • 界面测试
  • 冒烟测试
  • 回归测试
  • 业务测试
  • 兼容性测试
  • 易用性测试
• 自动化测试
  • WEB自动化测试
  • 接口自动化测试
• 性能测试
  • 性能测试
  • 负载测试
  • 压力测试
  • 容量测试
  • 并发测试
  • 持久性测试
• 安全测试
  • 手动测试
  • 自动化审计

• 灰盒测试

其他

• 随机测试
• 探索性测试
• α（音译：阿尔法）测试
• β（音译：贝塔）测试

生命周期各测试方法对比

流程/测试	单元测试	集成测试	冒烟测试	系统测试	验收测试
测试阶段	编码后	单元测试完成后	提测后	冒烟测试通过后	发布前
测试对象	最小模块	模块间的接口	整个系统	整个系统	整个系统
测试人员	白盒测试或开发	白盒测试或开发	黑盒测试	黑盒测试	最终用户或需求方
测试依据	代码、注释、详细设计文档	单元测试模块、概要设计文档	冒烟测试用例	需求说明文档、测试方案、测试用例	用户需求、验收标准
测试方法	白盒测试	黑盒与白盒结合	黑盒测试（手工或与自动化结合）	黑盒测试	黑盒测试

PART5 软件测试常用术语

C/S:

C指的是客户端（Client），S指的是服务器端（Server），这种软件是基于局域网或互联网的，需要一台服务器来安装服务器端软件，每台客户端都需要安装客户端软件。比如我们经常用的QQ和各种网络游戏就术语C/S结构的软件。

B/S:

B指的是浏览器（Browser），S指的事服务器（Server），这种软件同样是基于局域网或互联网的，它与C/S结构软件的区别就是于，不需要安装客户端（Client），只需要有浏览器，就可以直接使用。比如搜狐、新浪等门户网站及163邮箱都属于B/S结构的软件。B/S结构软件是现在的主流，与C/S结构软件相比，便于升级和维护，是测试的重点。

缺陷【Bug/Defect】：

软件的Bug指的是软件中（包括程序和文档）不符合用户需求的问题

测试环境

软件测试环境就是软件运行的平台，包括软件、硬件和网络的集合。用一个等式来表示：测试环境=软件 + 硬件 + 网络

测试用例【Test Case】

在测试执行之前设计的一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。

用一个等式来简单表示：测试用例=输入 + 输出 + 测试环境
其中，
“输入”包括测试数据和操作步骤
“输出”指的是期望结果
“测试环境”指的是系统环境设置

冒烟测试【Smoke Testing】

在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性

α测试：

验收测试的一种，指的是由用户、测试人员、开发人员等共同参与的内部测试

β测试：

验收测试的一种，指的是内测后的公测，即完全交给最终用户测试

PART6 软件测试常见模型

V模型

V模型是我们熟知的瀑布模型的一种改进，瀑布模型将软件生命周期划分为计划、分析、设计、编码、测试和维护六个阶段，由于早期的错误可能要等到开发后期的测试阶段才能发现，所以可能带来严重的后果。

V模型就是在这点改进了瀑布模型，在软件开发的生存期，开发活动和测试活动几乎同时开始，这两个并行的动态过程就会极大的减少Bug和Error出现的几率。

W模型

一些高性能高风险的系统、互联网软件，或一个系统难以被具体模块化的时候，就比较难做成V模式所需的各种构件，需要更强调迭代的开发模型或者敏捷开发模型。

W模型从V模型演化过来，实际上开发是V，测试是并行的V；相对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动，W明确表示出了测试与开发的并行关系。测试与开发是同步并行的，有利于尽早的全面发现问题。

其他模型-H模型

真正的测试级别之间不存在严格的次序关系，各阶段间可以反复触发、迭代、增量

为了解决V模型和W模型存在的问题，有专家提出了H模型。它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来

其他模型-X模型

PART7 软件测试覆盖率

覆盖率是用来度量测试完整性的一个手段，同时也是测试技术有效性的一个度量

覆盖率= （至少被执行一次的item数）/ item的总数

####特点

• 通过覆盖率数据，可以检测我们的测试是否充分
• 分析出测试的弱点在哪方面
• 指导我们设计能够增加覆盖率的测试用例，有效提高测试质量，但是测试用例设计不能一味追求覆盖率，因为测试成本随覆盖率的增加而增加。

测试覆盖率对于黑盒测试来说，主要指两个方面：

• 需求覆盖

• 定义
  • 它表示在测试中，有哪些函数被测试到了，其被测试到的频率有多大，这些函数在系统所有函数中占的比例有多大。通过设计一定的测试用例，要求每个需求点都被测试到。
• 计算公式
  • 需求覆盖=（被验证到的需求数量）/（总的需求总数）

• 用例覆盖

• 定义：
  • 主要体现在我们每轮测试验证通过的用例数在总用例中的比重
• 计算公式：
  • 用例覆盖=（验证通过的用例数量）/（总的用例总数）

测试覆盖率的实际运用

• 简单的测试覆盖率：本次测试执行的用例数/所有用例数

• 上述覆盖率统计建立在认为总用例数编写全面，一般对于大型系统测试要求覆盖率100%
• 覆盖率的审核：抽样验收

• 基于产品的测试覆盖率：已测试需求点/设计所有需求数

• 以产品、需求维度统计，无论大型项目或是小需求迭代都要求覆盖率达到100%
• 覆盖率的审核：抽样验收

• 基于白盒的测试覆盖率：大多工具判断语句覆盖，即单元测试代码覆盖代码行/总代码行

• 更多考察研发人员；更多时候要求覆盖率达到80%+
• 缺陷：
  • 覆盖率数据只能代表测试过哪些代码，不能代表是否测试好这些代码；容易遗漏逻辑、判断等场景

• 基于自动化的测试覆盖率：自动化覆盖的测试场景（测试用例）/ 所有测试场景（用例）

• 80/20原则，比如用户80%的时间在使用20%的功能，20%的功能就可以支撑起用户最关键的业务场景，自动化测试的用例选择更着重于这20%的核心功能
• 用途：
  • 自动化测试更着重于回归验证，没必要追求过高的覆盖率，而要考虑用例设计

测试覆盖率的最终意义

• 应用最多的地方在测试停止标准
• 单纯讨论测试覆盖率，在瀑布式开发模型中并不重要，但在螺旋式、敏捷开发模型中，由于不断迭代累加，很难确定哪些模块在开发过程中没有给予足够的测试
• 在短迭代、DevOps中，更强调用单元测试覆盖率来评估不断增加的代码数量

PART8 测试团队组织架构

金字塔管理模式

• 测试总监

• 产品线测试 经理/主管（不同的产品线，可以有多个）
  • 测试组长
    • 测试人员
    • 测试人员

矩阵化管理模式

• 项目经理（管理所有经理以下的，主要项目进展）
• 研发经理

• 研发人员N+

• 测试经理

• 测试人员N+

PART9 软件测试人员

软件测试人员需要的知识体系

• 软件测试基础知识
• 软件测试流程
• 测试用例设计方法
• 兼容性测试/易用性测试
• 缺陷管理
• 测试工具使用
• 测试文档编写
• …

软件测试人员具备的素质

• 踏实细心
• 积极主动
• 好奇心，怀疑一切
• 良好交流能力
• 自我提高和总结能力
• 责任感
• …

软件测试的原则

• 所有的测试都应追溯到用户需求

• “产品缺陷的80%以上是在产品开发过程中的需求定义阶段引入的，如果需求得到了准确的验证，则可以消除80%的返工问题，节省总项目投入费用的45%”

• 尽早启动测试工作

• 修改一个错误的相对成本，越往后才发现错误才修改需要更多的时间去修改

• Pareto法则应用于软件测试

• Pareto（帕累托）法则是由意大利经济学家帕累托提出的，又称为28效率法则
• 测试中的Pareto法则是说一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的缺陷，而系统测试又能找出其余缺陷中的80%，最后4%的缺陷可能只有在用户的大范围、长时间使用后才会暴露出来

• 穷尽测试是不可能的

• 由于很少有机会对一个应用软件进行所有可能的测试，对大多数软件开发项目来说，利用风险分析是适当的。这需要判断技能、常识、感受和经验。如果有正当理由，也可采用正式的方法

• 杀虫剂怪事

• 软件测试越多，其对测试的免疫力越强的现象
• 为了克服杀虫剂怪事，软件测试员必须不断编写不同的、新的测试程序，对程序的不同部分进行测试，以找出更多软件缺陷

• 前进两步，后退一步

• 测试中的一个基本问题是 ———— 缺陷修复总会以（20-50）%的几率引入新的缺陷
• 每次修复之后，必须重新运行先前所有的测试用例，从而确保系统不会以隐蔽的方式被破坏

• 三心二意

• 细心、信心、耐心
• 团队合作的沟通意识、时刻保持怀疑的态度且有缺陷预防意识

PART10 软件工程标准

• 国内通用的软件工程标准主要有ISO9000及CMM

• ISO9000系列标准是ISO国际标准化组织TC/176技术委员会制定的所有国际标准，其核心标准是质量保证标准（ISO9001/2/3）和质量管理标准（ISO9004）
• CMM（Capability Maturity Model）即软件能力成熟度模型，是向软件组织提供如何增加对其开发和维护软件过程的控制能力

ISO9000

• ISO9000系列标准的基本思想，最主要的有两条：

• 控制的思想，即对产品形成的全过程————从采购原材料、加工制造到最终产品的销售、售后服务进行控制
• 预防的思想，通过对产品形成的全过程进行控制以及建立并有效运行自我完善机制达到预防不合格，从根本上减少或消除不合格产品

CMM

• CMM准确来说不是标准，知识对过程能力的评估结果
• CMM对软件企业的评估从初始级开始，共分为5级，一级一级的改进，一级一级的向上提高。等级的上升过程是一个“动态渐进”的过程
• CMM是专为软件呢开发组织设计的，侧重于软件开发和改进进程，在产品的设计和开发的细节做了较多要求

软件测试规范

• 测试系统主要由下面6个相互关联、相互作用的过程组成

• 测试规划
• 测试设计
• 测试实施
• 配置管理
• 资源管理
• 测试管理

• 软件测试过程中一般会从以下几个方面入手来规范过程，并在每个子过程明确角色、职责、活动描述及所需资料

• 角色的确定
• 进入的准则
• 输入项
• 活动过程
• 输出项
• 验证与确认
• 退出的准则

第四章 【熟悉阶段：软件测试流程】规范的软件测试流程

软件测试环境搭建原则–测试环境必知必会

PART1 软件测试环境搭建原则

搭建测试环境前

• 确定测试目的

• 功能测试，稳定性测试，还是性能测试，测试目的不同，搭建测试环境时应注意的点不同。
• 功能测试：不需要大量的数据，需要覆盖率高，测试数据要求尽量真实。
• 性能测试：可能需要大量存量数据或者与实际硬件环境尽可能相似的硬件配置。

• 测试的软件环境尽可能的模拟真实环境

• 尽可能的模拟用户使用环境，选用合适的操作系统和软件平台。
• 了解符合测试软件运行的最低要求及用户使用的硬件配置。
• 了解用户常用的软件，避免所有配置所有操作系统下都要进行测试，没有侧重点，浪费时间。
• 产品化的测试则需要考虑兼容性的方案。

• 营造独立的测试环境

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

• 构建可复用的测试环境

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

搭建测试环境过程分析

• 线下搭建

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

测试环境配置

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

Docker模式

• 构建属于自己的image
• 一键deploy

依赖第三方平台

• 如：蚂蚁金融云等

浅谈测试环境的建设落地

• 环境建设思路

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

PART2 测试过程

简单的测试过程

• 测试管理过程

• <输入> [项目计划] [需求规格说明书]
• <项目经理> [开始] [提交项目计划需求规格说明书] ->
• <测试人员> -> [制定测试计划] -> [设计测试用例] -> [执行测试] -> [提交测试发现的问题] -> （修改问题）-> [所有问题已修复] -> [结束]
• <项目组成员> 提交测试 -> [修改问题] -> (问题修复)
• <输出> [测试计划] [测试用例] [缺陷跟踪记录]

测试过程划分

• 策划（需求&计划）-> 设计 -> 执行 -> 评估 -> 总结

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

PART3 测试策划

测试策划过程

• 测试策划 -> 测试需求 -> 测试计划 -> 测试控制

• 进行测试需求的分析
• 确定需要测试的内容或质量特征
• 明确测试的充分性要求
• 提出测试的基本方法
• 确定测试的资源和技术需求
• 进行风险分析与评估
• 根据上述分析结果制定测试计划
• 根据测试计划开展相应的测试控制活动

PART3-1 需求测试

需求分析

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

需求测试的作用

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

需求验证

• 审查需求文档

• 对需求文档及相关模型进行仔细检查
• 另外在需求开发期间所做的非正式评审也是有所脾益的

• 以需求为依据编写测试用例

• 编写用户手册
• 在需求开发早期即可起草一份浅显易懂的用户手册，用以描述出所有对用户可见的功能并用它作为需求规格说明的参考并辅助需求分析

• 确定合格的标准

• 让用户描述什么样的产品才算满足他们的要求和适合他们的使用
• 将确认合格的测试建立在使用情景描述或使用实例的基础之上

需求规格说明书检查列表

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

• 是【】否【】NA（无需）【】

需求测试实战

• 以支付宝上新增余额宝业务为例分析

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

PART3-2 测试策略

测试前的思考

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

测试策略是什么

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

测试策略要素

• 测试安排发布计划 ->

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

• 测试范围 ->

• 测试范围（按优先级排列）
• 分为In Scope（测试范围内）和Out Of Scope（测试范围外）
• 需要说明哪些模块是在测试范围中的，哪些是本阶段测试不考虑的
• 对于在测试范围中的模块，需要给出优先级
• 对于不在测试范围中的模块，需要给出原因（为什么在本测试阶段不考虑测）

• 测试资源 ->

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

• 测试环境 ->

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

• 测试方法 ->

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

• 用例设计方法 ->
• 文档管理 ->

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

• 风险管理 ->

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

• 上线跟踪验证

PART3-3 测试计划与测试方案

测试策略

• 测试策略：侧重需求分析，评估风险，定义测试范围

• 确定测试方法，制定测试启动、停止、完成标准的条件

测试计划

• 测试计划：制定项目测试过程中的测试重点

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

测试方案

• 测试方案：侧重测试的方法，测试环境的规划

• 测试工具的设计和选择，测试用例的设计方法，测试代码的设计方案

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

• 实际实施过程中，往往存在这样类似的方式：

• 测试方案 = 测试计划 + 用例设计方案 + 工具选择 + 自动化/性能测试具体方案
• 测试计划 = 测试策略 + 测试任务分配 + 时间进度安排

测试方案列表

1. 需求说明

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

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

• 2.1 测试计划进度表

3. 测试方案

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

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

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

5. 测试执行计划

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

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. 测试风险：在测试或计划测试过程中由于时间安排、测试限制、优先级分布可能带来的测试风险考量

PART3-4 测试方案评审

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

• 容易造成以下几方面的问题：

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

评审目的

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

评审重点

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

测试过程划分

• 策划（需求&计划）->
• 设计 ->
• 执行 ->
• 评估 ->
• 总结

第五章 【核心阶段1：软件测试设计】软件测试核心之用例设计

破刀式 - 软件测试设计

PART1 测试设计与测试用例

测试设计

• 测试设计是将概括的测试目标转化为具体的测试条件和测试用例的一系列活动

测试分析和设计的主要任务

• 评审测试依据（需求，系统架构、设计和接口说明）
• 评估测试依据和测试对象的可靠性
• 通过对测试项、规格说明、测试对象行为和结构的分析，识别测试条件并确定优先级
• 设计测试用例，并确定优先级
• 确定测试条件和测试用例所需的必要的测试数据

确定测试条件

• 依据在测试策略或测试计划中确定的测试技术
• 通过对测试依据和测试目标的分析，可以确定需要测试的内容，获得测试条件
• 需求 -> 测试内容

测试用例

• 测试用例是通过使用在测试计划中确定的测试技术，对于已确定的测试条件进行逐步推敲，精炼而设计出来的重点说明如何具体操作产生何种结果的文档。
• 测试用例应该具有可重复性、可验证性和需求可追踪性。

测试用例设计包括以下关键点

• 前提条件，如项目或局部测试环境的需求，及其交付计划
• 测试步骤
• 测试数据
• 预期结果

测试用例案例

Excel格式测试用例设计模板（简单Demo）

• 序号
• 模块名称
• 测试子项
• 用例名称（测试意图）
• 用例级别
• 预置条件
• 测试步骤
• 预期结果
• 测试结果
• 缺陷编号
• 备注

测试用例常用设计方法

• 等价类划分法
• 边界值法
• 因果图设计法
• 判定表设计法
• 正交实验法

PART2 等价类划分法

测试一个两位数的加法计算器

• 测试需求：

• 测试两个参数的值相加后的结果是否正确
• 其中：输入的数值在-99到99之间大于99或小于-99的输入应被拒绝，并显示错误信息
• 如果我们对第一个参数的值分别取从-99到99的199个数，第二个参数的值分别取从-99到99的199个数，我们不可能对两位数相加的所有情况进行穷举测试。
• 如果不能进行穷举测试，能否放心的认为所有的参数组合都是确定的呢？

• 等价类划分的办法是把程序的输入域划分若干部分
• 然后从每个部分中选取少数代表性数据当做测试用例
• 每一类的代表性数据在测试中的作用等价于这一类中的其他值
• 也就是说，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能发现同样的错误。
• 反之，如果某一类中的一个例子没有发现错误，则这一类中的其他例子也不会查出错误。

等价类划分原则

• 如果输入条件规定了取值的范围或值的个数，则可确定一个有效等价类和两个无效等价类
• 如果一个输入条件说明了一个“必须成立”的情况，则可划分一个有效等价类和一个无效等价类
• 如果输入条件规定了输入数据的一组可能的值，而且程序是用不同的方式处理每一种值，则可为每一种值划分一个有效等价类，并划分一个无效等价类
• 如果我们确知，已划分的某等价类中的各元素（例子）在程序中的处理方式是不同的，则应据此将此等价类进一步划分成更小的等价类
• 在确立了等价类之后，建立等价类表，列出所有划分出的等价类

基于等价类划分的用例设计

• 明确测试对象，非测试对象保证正确
• 为每个等价类规定一个唯一的编号
• 设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例所覆盖
• 设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有无效等价类均被覆盖

等价类划分实战

• STEP1：根据测试需求可以分为三个等价类：

• 一个有效数据的等价类，两个无效数据等价类
• 有效数据等价类就是：由那些对程序的规格说明有意义的、合理的输入数据所构成的集合
• 无效数据等价类就是：那些对程序的规格说明不合理的或无意义的输入数据所构成的集合

• STEP2：建立等价类表

• 在实际工作中，我们通常在确立了等价类以后，把程序中所有的等价类建立等价类表，以便在编写测试用例的时候有所依据

|序号|功能项|有效等价类|编号|无效等价类|编号
|:–:|:–:|:–:|:–:|:–:|
|1|两位数加法|-99<=加数取值<=99|2|加数取值<-99,加数取值>99|1,3|

• STEP3：确定测试用例

• 为等价类表中的每一个等价类分配一个唯一的编号
• 设计一个新的测试用例，使它能够尽量覆盖尚未覆盖的有效等价类
• 重复这一步骤，从而使所有有效等价类均被测试用例所覆盖
• 上步类似，设计一个新的测试用例，使它只覆盖一个无效等价类
• 重复这一步骤，从而使所有无效等价类均被测试用例所覆盖

测试用例编号	输入数值	所属等价类	预期输出
1	-50+25	2	正确输出：-26
2	-130	1	错误信息
3	125	3	错误信息

• STEP4：细化等价类划分

• 在测试“-99<=数值<=99”的这个等价类区间的时候
• 我们会发现如10+40，-20+30和-30+(-30)这类的正数相加，正数负数相加，负数相加也是不同的等价区间
• 因此我们可以使用更加的等价类划分（算法进制不同）
• 根据以上等价类划分的结果，得出下表的等价类表（推荐这种）

序号	功能项	有效等价类	编号	无效等价类	编号
1	两位数加法	-99<=加数取值<=0，0<=加数取值<=99	2，3	加数取值<-99，加数取值>99	1，4

• STEP5：完善测试用例

• 根据上面划分的4个等价类，我们至少需要有5个测试用例

测试用例编号	输入数值	所属等价类	预期输出
1	50+2	3	正确输出：52
2	-63+(-20)	2	正确输出：-83
3	-30+10	2，3	正确输出：-20
4	-130	1	错误信息
5	125	4	错误信息

• 个人总结

• 可以更加细化
• 比如添加一些英文字母或者特殊字符会如何，是不是也要测试下呢

等价类的特点

• 测试相同的内容
• 如果等价类中的一个测试能够捕获一个缺陷，那么选择该等价类的其他测试也能捕获该缺陷；相反，如果不能捕获到缺陷，其他测试也不会
• 如果正确的划分等价类，可以大大降低测试用例的数量，测试会准确有效
• 如果错误的将两个不同的等价类当作一个等价类，那就回遗漏一种测试情况
• 相反的，把同一个等价类看作了两个不同的等价类，那么测试会是冗余的

等价类划分要注意的问题

• 不但要考虑有效等价类，也要考虑无效等价类
• 仔细划分，审查划分
• 过于粗略可能会漏掉软件缺陷
• 组织评审

等价类用例设计练习

#####余额宝提现

• 测试需求：余额宝提现到银行卡增加新规则：快速到账（2小时）日限额1w元
• 超过1w元只能选择普通到账
• 按照等价类划分法设计测试用例
• 设计用例

|序号|功能项|有效等价类|编号|无效等价类|编号
|:–:|:–:|:–:|:–:|:–:|:–:|:–:
|1|余额宝快速提现|0<=取现金额<=10000|2|取现金额<0|1
|1||||取现金额>10000|3|
|2|余额宝普通提现|0<=取现金额<=（余额宝总余额）10000|5|取现金额<0|4
|2||||取现金额>100000|6

• 细致分析需求，日限额1w，所有要区分两个场景

|序号|功能项|有效等价类|编号|无效等价类|编号
|:–:|:–:|:–:|:–:|:–:|:–:|:–:
|1|余额宝快速提现（第一次）|0<取现金额<=10000|2|取现金额<=0|1
|||||取现金额>10000|3
|2|余额宝快速提现（第n次）|0<取现金额<=10000-已提现金额|8|取现金额<=0|7
|||||取现金额>10000-已提现金额|9
|3|余额宝普通提现|0<取现金额<=（余额宝总余额）10000|5|取现金额<=0|4
|||||取现金额>100000|6

经典等价类划分面试题

• 问题：根据下面给出的规格说明，利用等价类划分的方法，给出足够的测试用例
• “一个程序读入3个整数，把这三个数值看做一个三角形的3条边的长度值”
• 这个程序要打印出信息，说明这个三角形是不等边的、是等腰的、还是等边的

PART3 边界值法

两位数加法器

场景：两位数加法器 -90 + 98 出现错误提示

为什么错了？

• 根据前面的等价类方法，我们按照测试用例表给出的测试用例进行了测试，没有发现问题
• 那么为什么现在输入参数-99和98后，程序提示输入的数据有误了呢？
• 而-99是合理的输入数据，以-99做为输入数据应该是有效等价类中的数据
• 是不是等价类划分方法有问题呢？

边界值分析法

• 边界值分析法是一种补充等价划分的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价类边界的测试用例。
• 实践证明，在设计测试用例时，对边界附近的处理必给予足够的重视，为检验边界附近的处理专门设计测试用例，常常取得良好的测试效果。
• 边界值分析法不仅重视输入条件边界，而且也从输出域导出测试用例

边界值设计的原则

• 如果输入条件规定了取值范围，应以该范围的边界内及刚刚超范围的边界外的值作为测试用例
• 如以a和b为边界，测试用例应当包含a和b及略大于a和略小于b的值

边界值设计用例

• 我们继续用计算器的例子，根据边界值分析的方法来看看如何对边界值进行测试

• -99 -> (-100 | -98)
• 99 -> (98 | 100)

• 由于允许输入的数值在-99到99之间，所以我们可以把-99和99看作两个边界值。我们测试的时候可以取紧邻边界值的数值和边界值本身作为输入

测试用例编号	输入数值	被测边界	预期输出
1	-100	-99	错误信息
2	-99 + (-99)	-99	正确输出：-198
3	-98 + (-98)	-99	正确输出：-196
4	98+98	99	正确输出：196
5	99+99	99	正确输出：198
6	100	99	错误信息

边界值用例设计练习

• 同样的测试需求：余额宝提现到银行卡增加新规则：快速到账（2小时）日限额1w元

序号	功能项	输入数值	被测边界	预期输出
1	余额宝快速提现（第一次）	0，-1，1	0	…
		10000，9999，10001	10000	…
2	余额宝快速提现（第n次，假设已提现金额5000）	0，-1，1	0	…
		5000，4999，5001	10000-已提现金额=5000	…
3	余额宝普通提现	0，-1，1	0	…
		9999999	最大金额	…

PART4 因果图&判定表法

因果图法

• 等价类划分法和边界值分析方法都是着重考虑输入条件
• 而不考虑输入条件的各种组合、输入条件之间的相互制约关系
• 如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字
• 因此必须考虑采用一种适合于描述多种条件的组合、产生多个相应动作的测试方法，这就需要利用因果图（逻辑模型）

因果图-判定表

• 因果图法基于这样的思想：一些程序的功能可以用决策表的形式来表示，并根据输入条件的组合情况规定相应的操作。
• 因此，可以考虑为决策表中的每一列设计一个测试用例，以便测试程序在输入条件的某种组合下的输出是否正确
• 概括地说，因果图方法就是从程序规格说明书的描述中找出因（输入条件）和果（输出结果或程序状态的改变）
• 将因果图转换为判定表，为决策表中的每一列设计一个测试用例
• 这种方法考虑到了输入情况的各种组合以及各个输入情况之间的相互制约关系

判定表

• 判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的工具
• 在程序设计发展的初期，判定表就已被当作编写程序的辅助工具
• 因为它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确

|-|-|1|2|3|4|5|6|7|8
|:–:|:–:|:–:|:–:|:–:|:–:|:–:|:–:|:–:
|问题|你觉得疲倦吗？|Y|Y|Y|Y|N|N|N|N
||你对内容感兴趣吗？|Y|Y|N|N|Y|Y|N|N
||书中内容使你糊涂吗？|Y|N|Y|N|Y|N|Y|N
|建议|请回到本章开头重读|x||||x|||
||继续读下去||x||||x||
||跳到下一章去读|||||||x|x
|*|停止阅读，请休息|||x|x||||
“读书指南”判定表

• 判定表通常由四个部分组成：

• 条件桩（Condition Stub）：列出了问题的所有条件，通常认为列出得条件的次序无关紧要。
• 动作桩（Action Stub）：列出了问题规定可能采取的操作，这些操作的排列顺序没有约束。
• 条件项（Condition Entry）：列出针对它左列条件的取值，在所有可能情况下的真假值。
• 动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。

设计步骤

1. 分析软件规格说明中哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。
2. 分析软件规格说明中语义的内容，找出原因与结果之间、原因与原因之间对应的关系，根据这些关系画出因果图。
3. 由于语法或环境的限制，有些原因与原因之间、原因与结果之间的组合情况不可能出现。为表明这些特定的情况，在因果图上使用一些记号表明约束或限制条件
4. 把因果图转换为判定表
5. 根据判定表中的每一列设计测试用例

实战

• 使用因果图 + 判定表设计测试用例

分析输入条件和输出条件

• 输入1：

• 条件1：0<=X<=99
• 条件2：-99<=X<0
• 条件3：X<-99
• 条件4：X>99

• 输入2：

• 条件1：0<=X<=99
• 条件2：-99<=X<0
• 条件3：X<-99
• 条件4：X>99

• 输出：

• 正确计算
• 错误提示

分析条件互诉

• 输入

• 输入1：1、2、3、4互诉
• 输入2：1、2、3、4互诉

• 输出

• 输出结果正确和错误互诉

分析、简化并画出判定表

输入1
条件1	T	T	-	-	-	-	-	-
条件2	-	-	T	T	-	-	-	-
条件3	-	-	-	-	T	-	-	-
条件4	-	-	-	-	-	T	-	-
输入2
条件1	T	-	T	-	-	-	-	-
条件2	-	T	-	T	-	-	-	-
条件3	-	-	-	-	-	-	T	-
条件4	-	-	-	-	-	-	-	T
输出
正确计算	X	X	X	X
错误提示					X	X	X	X

得到测试用例

测试用例编号	输入数值	预期输出
1	98+98	正确输出：196
2	99+(-99)	正确输出：0
3	-98+(50)	正确输出：-48
4	-34+(-45)	正确输出：-79
5	-100	错误信息
6	100	错误信息
7	20+(-123)	错误信息
8	20+(123)	错误信息

因果图法用例设计练习

• 同理我们将同一测试需求用因果图设计：
• 余额宝提现到银行卡增加新规则：快速到账（2小时）日限额1w元，超过1w元只能选择普通到账。
• 按照y因果图法设计测试用例

分析输入条件和输出条件

• 输入

• 输入1：
  • a1：快速提现
  • a2：普通提现
• 输入2：
  • a1：0 < X <= 10000
  • a2：X <= 0
  • a3: X > 10000

• 输出

• B1 提现成功
• B2 提现失败

分析、简化并画出判定表

输入
a1	T	T	T	F	F	F
a2	F	F	F	T	T	T
输入2
a1	T	F	F	T	F	F
a2	F	T	F	F	T	F
a3	F	F	T	F	F	T
输出
b1	X			X		X
b2		X	X		X

经典因果图-判定表面试题

• 问题

• 某厂工资发放

• 描述、分析：

• 工资分为年薪制a1，月薪制a2；
• 错误程度分为普通a3，严重a4；

• 工资为a1的员工犯普通错误的扣工资2%（b1），犯严重错误扣工资6%（b2）；
• 工资为a2的员工犯普通错误的扣工资4%（b3），犯严重错误扣工资8%（b4）；
• 其中，a1和a2为互诉；b1、b2和b3、b4是互诉；a3和a4可以同时具备

PART5 正交实验法

• 正交实验法设计法（Orthogonal experimental design），是从大量的的实验点中挑选出适量的、有代表性的点，应用依据伽罗卡瓦理论导出的“正交表”，合理的安排实验的一种科学的实验设计方法
• 指标：通常把判断实验结果优劣的标准叫做实验的指标
• 因子（因素Factor）：所有影响实验指标的条件
• 因子的状态（水平Level）：而影响实验因子的，叫做因子的状态（因子变量的取值）

正交实验法设计步骤

• 提取功能说明，构造因子——转态表

  -	因子1	因子2	…	因子n
  状态1
  状态2
  …
  状态m

• 加权筛选，生成因素分析表

• 计算各因子和状态的权值，删去一部分权值较小，即重要性较小的因子或状态，使最后生成的测试用例集缩减到允许范围。

• 利用正交表构造测试数据集

• 如果各个因子的状态树是不统一的，几乎不可能出现均匀的情况，必须首先用逻辑命令来组合各因子的状态，作出布尔图
• 根据布尔图得到相应阶数的正交表
• 依照因果图上根节点到叶子节点的顺序逐步替换正交表的中间节点，得到最终的正交表

• 利用正交表每行数据构造测试用例

• 正交表
  • 正交表的表示形式：Ln（t∧c）其中：L为正交表的代号，n为行数（实验次数），t为水平数，c为列数（因素数）
• 例如：L4（2∧3），它表示需做4次实验，最多可观察3个因素，每个因素均为2水平

-	1	2	3
1	1	1	1
2	1	2	2
3	2	1	2
4	2	2	1

• 123为实验
• 1234为因素
• 12为水平 正确、错误

• 一个正交表中也可以各列的水平数不相等，我们称它为混合型正交表，如L8（2∧4 4∧1）。

• 此表的5列中，有1列为4水平，4列为2水平。
• 根据正交表的数据结构看出，正交表是一个n行c列的表，其中第j列由数码1，2，…tj组成，这些数码均各出现n/t次
• 第二列的数码个数为2，t=2，即由1、2组成，各数码均出现2次

-	1	2	3	4	5
1	1	1	1	1	1
2	1	1	2	2	3
3	1	2	1	2	2
4	1	1	2	1	4
5	2	1	1	2	4
6	2	1	2	1	2
7	2	2	1	1	3
8	2	2	2	2	1

如何查找正交表

1. 【推荐】Techniacal Support（support.sas.com）
2. 查Dr.GenichiTaguchi设计的正交表 orthogonal Arrays（Taguchi Designs）
3. 数理统计、实验设计等方面的书及附录中，关注点：因素数和对应的水平数组成的矩阵。

正交实验法例子

• 我们现在要测试支付宝web网站，该站点有大量的服务器和操作系统，并且有许多具有各种插件的浏览器需要考虑：

• WEB浏览器：IE11、chrome、FireFox
• 插件：无、Flash、支付宝插件
• 应用服务器：IIS、Apache、Jetty
• 操作系统：Windows2000、Windows NT、Linux、windows各种版本等等

• 提取系统功能说明中的因子

• WEB浏览器
• 插件
• 应用服务器
• 操作系统

• 分析各因子的状态

• 插件：1=None、2=Flash、3=支付宝插件
• WEB浏览器：1=IE11、2=chrome、3=FireFox
• 应用服务器：1=IIS、2=Apache、3=Jetty
• 操作系统：1=Windows2000、2=Windows NT、3=Linux

• 选择正交表

• 正交表水平数为3，因素数为4。选择L9（3∧4）

-	1	2	3	4
1	1	1	1	1
2	1	2	2	2
3	1	3	3	3
4	2	1	2	3
5	2	2	3	1
6	2	3	1	2
7	3	1	3	2
8	3	2	1	3
9	3	3	2	1

• 将因子、状态映射到上面正交表中

-	WEB浏览器	插件	应用服务器	操作系统
1	IE11	None	IIS	Windwos 2000
2	IE11	Flash	Apache	Windows NT
3	IE11	支付宝插件	Jetty	Linux
4	chrome	None	Apache	Linux
5	chrome	Flash	Jetty	Windows 2000
6	chrome	支付宝插件	IIS	Windows NT
7	FireFox	None	Jetty	Windows NT
8	FireFox	Flash	IIS	Linux
9	FireFox	支付宝插件	Apache	Windows 2000

PART6 测试场景设计

场景法原理

• 现在的软件几乎都是用事件触发来控制流程的。事件触发时的情景形成了场景，而同一事件不同的触发顺序和处理结果就形成了事件流。
• 这种在软件设计方面的思想可以引入到软件测试中，可以生动地描绘出事件触发时的情景，有利于设计测试用例，同时使测试用例更容易理解和执行

场景法基础设计

• 开始用例（基本流） -> 备选流（1、2、3、4）-> 结束用例
• 经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。
• 备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；
• 也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。
• 每个经过用例的可能路径，可以确定不同的用例场景。

• 从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：

• 场景1 基本流
• 场景2 基本流 备选流1
• 场景3 基本流 备选流1 备选流2
• 场景4 基本流 备选流3
• 场景5 基本流 备选流3 备选流1
• 场景6 基本流 备选流3 备选流1 备选流2
• 场景7 基本流 备选流4
• 场景8 基本流 备选流3 备选流4

场景法设计步骤

• 根据说明，描述出程序的基本流及各项备选流
• 根据基本流和各项备选流生成不同的场景
• 对每一个场景生成相应的测试用例
• 对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据值

场景法设计例子

• 以淘宝网为例，我们都在淘宝上买过东西，整个购买过程为：

• 用户登录到网站后，进行商品的选择，当选后自己心仪的商品后进行购买，这时把所需商品放进购物车，等进行结账的时候，用户需要登录自己注册的账号，登录成功后，进行结账并生成订单，整个购物过程结束。

• 通过以上的描述，从中确定哪是基本流，哪些是备选流

基本流	用户登录到网站，商品的选择，把所需商品放进购物车，等进行结账的时候，登录自己的账号，登录成功后，生成订单
备选流1	账号不存在
备选流2	账号错误
备选流3	密码错误
备选流4	无选购商品
备选流x	退出系统

• 根据基本流和备选流来确定场景

场景	基本流	-
1-购物成功	基本流	-
2-账号不存在	基本流	备选流1
3-账号错误	基本流	备选流2
4-密码错误	基本流	备选流3
5-无选购商品	基本流	备选流4

实际测试中用例设计的综合运用

测试用例综合设计

• 测试用例项划分

• 测试用例划分的经典方法是瀑布模型，从上到下，逐渐细分，大模块包括小模块，小模块包括更小的模块。
• 要从更多的角度切入系统，把系统切分成一块一块的，来进行测试，从而确保测试大项的完整性

• 切面设计

• 功能点切面：最常见的切面，通常认为页面上的一个按钮就是一个功能点。根据功能的复杂程度，按每个功能进行用例的撰写。
• 隐含切面：完整业务流程的测试；从需求、业务角度进行编写

• 功能点用例设计

• 任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强
• 必要时用等价类划分方法补充一些测试用例
• 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法
• 如果程序业务复杂度比较高，则适当使用场景法补充一部分测试用例

举例：比如共享单车充值

• 边界值考虑充值金额：0元，1元，负数，非金额参数，多位小数（小数后位3位），银行卡限额
• 由于充值时可以选择不同的银行、支付渠道，所以针对支付宝、微信、通联、银联、银行直连等渠道分别设计测试用例
• 考虑异常场景，如充值失败、银行卡余额不足、银行返回超时等
• 如果场景中还包含更复杂的业务场景，如满减、满赠、增加抽奖次数等，还需要结合场景法进行测试

第六章 【核心阶段2：执行测试用例】测试执行的艺术

破枪式-测试执行管理

PART1 测试执行过程

• 项目提测 ->
• 冒烟测试（未通过->退回上一步）通过 ->
• 系统测试
• 用例执行 (失败 -> 提出缺陷 -> 研发修改 -> 回归用例执行) 通过 ->
• 测试通过

测试执行阶段的主要任务

• 确定测试用例的优先级
• 开发测试规程并确定优先级，创建测试数据，同时也可以准备测试用具和设计自动化测试脚本
• 根据测试规程创建测试套件，以提高测试执行的效率
• 确认已经正确搭建了测试环境
• 根据计划的执行顺序，通过手工或使用测试工具来执行测试规程
• 记录测试执行的结果，以及被测软件、测试工具和测试件的标识和版本
• 将实际结果和预期结果进行比较
• 对实际结果和预期结果之间的差异，作为事件上报，并且进行分析以确定引起差异的原因
• 缺陷修正后，重新进行测试活动

PART2 测试准入准出

测试准入标准

• 开发编码结束，并在开发环境已完成单元测试（开发自测、单元测试）
• 需求上规定的功能均已实现；如没有完全实现，请提供测试范围（冒烟测试）
• 已完成集成测试，被测系统的基本流程可以走通，界面上的功能均实现，经过代码评审并符合软件编码规范（测试内容、要求、范围明确）
• 开发提交最新版本代码，以此为基线，提交并通知测试组进行测试（开始测试）
• 兼容性测试要求明确
• 安全测试和性能测试范围和要求

测试暂停、停止

• 测试人员先进行冒烟测试，若发现重大缺陷或bug过多时、或者流程卡壳导致基本流程无法走通，测试无法正常进行，可以暂停测试并返回开发
• 被测项目需调整而暂停的，测试也相应暂停
• 存在其他优先级更高的任务时，可以向领导申请暂停测试
• 被测系统经过系统测试，达到系统准出标准，可以停止测试（测试结束）

测试准出标准

序号	准出标准	是	否	日期
1	被测项目满足需求原型的要求？
2	所有测试用例都已经通过评审？
3	所有测试用例都已成功执行？
4	测试覆盖率是否达到100%？
5	所有发现的缺陷都记录在缺陷管理系统？
6	一二级错误修复率达到100%？
7	三四级错误修复率达到95%？
8	所有遗留问题都已有解决方案？
9	性能指标是否达到要求？
10	兼容性测试（IE8,Chrome,火狐）是否满足？
11	安全性测试是否达到要求？
12	产出系统测试总结报告？

PART3 缺陷管理

软件缺陷

• 缺陷是一种泛称，它可以指功能的错误，也可以指性能低下，易用性差等
• 并不是所有的测试人员都能提交被开发认可的缺陷，可不是测试员在任何时候都能提交被开发认可的缺陷

什么是软件缺陷

• 软件未达到产品说明书标明的功能（需求上的遗漏）
• 软件出现了产品说明书指明不会出现的错误
• 软件功能超出产品说明书指明范围
• 软件未达到产品说明书虽未指出但应达到的目标
• 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好

缺陷产生的原因

• 沟通交流不够
• 需求不断变化
• 软件的复杂性
• 软硬件支持不完善
• 工期短，任务大
• 程序设计错误
• 文档不完善

发现缺陷

• 用户体验不够好
• 界面上有明显的错误信息
• 功能不完备，没有按照需求说明编写代码，致使某些功能缺失
• 功能不完善，不能正常运行或者运行的过程中出现程序崩溃、停止运行的情况
• 逻辑不正确，与需求说明书、测试用例不符
• 模块之间的交互性不好，与其他的模块做集成测试时遇到问题
• 程序的性能不够好，不能承载压力考验

PART3-2 缺陷报告

BUG重现

• 不要想当然地接受任何假设，要做好记录
• 查找时间依赖和竞争条件的问题
• 边界条件软件缺陷、内存泄漏和数据溢出等白盒问题可能会慢慢自己显露出来
• 状态缺陷仅在特定软件状态中显露出来
• 考虑资源依赖性和内存、网络、软件共享的相互作用

无法重现的BUG

• 首先，应当对这样的缺陷进行详细的记录，并尽快提交给开发人员
• 其次，对于寻找难以再现的缺陷要合理地安排时间，要考虑到测试项目的整体进度，对一时难以再现的缺陷可以暂时搁置，以保证项目的正常进度
• 最后在测试过程中对未再现缺陷予以关注

缺陷报告

• 缺陷报告是对缺陷进行记录、分类和跟踪的文档
• 软件测试人员的任务之一就是书写良好的软件缺陷报告
• 提供准确、完整、简洁、一致的缺陷报告是体现软件测试的专业性、高质量的主要评价指标
• 通常，缺陷报告的直接读者是软件开发人员和质量管理人员，除此之外，来自市场和技术支持等部门的人也可能需要查看缺陷情况

缺陷报告包含信息

• 易于搜索软件测试报告的缺陷。
• 报告的软件缺陷进行了必要的隔离，报告的缺陷信息具体、准确。
• 软件开发人员希望获得缺陷的本质特征和复现步骤。
• 市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度。

缺陷报告的写作准则（5C）

• Correct（准确）：每个组成部分的描述准确，不会引起误解
• Clear（清晰）：每个组成部分的描述清晰，易于理解
• Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容
• Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息
• Consistent（一致）：按照一致的格式书写全部缺陷报告

缺陷报告的组织架构

• 缺陷的标题
• 缺陷的基本信息
• 测试的软件和硬件环境
• 测试的软件版本
• 缺陷的类型
• 缺陷的严重程度
• 缺陷的处理优先级
• 复现缺陷的操作步骤
• 缺陷（执行某个流程中）的实际结果描述
• 期望的正确结果描述
• 注释文字和截取的缺陷图像

缺陷标题

• 尽量按缺陷发生的原因与结果的方式书写（“执行完A后，发生B，”或者“发生B，当A执行完后”）
• 避免使用模糊不清的词语，例如“功能中断”、“功能不正确”、“行为不起作用”等。应该使用具体文字说明如何中断，如何不正确，或如何不起作用
• 为了方便搜索和查询，请使用关键字
• 为了便于他人理解，避免使术语、俚语或过分具体的测试细节

缺陷报告案例

原始描述	错误原因	改进的标题
英文单词的连字符不管用	描述太笼统。什么时候不起作用？	在行末尾换行时，不能根据英文单词长度设置连字符。
段落调整出现错误状态	描述太笼统。不正确的行为是什么？	选定两个单词，启动单词“字间距”自动调整后间隔排版错误。
警告：该命令产生了错误的结果。	没有包含原因与结果信息。描述内容太长。	更新头像图像保存到服务器时，警告：“错误”。
在鼠标点击执行每一个拷贝或复制的编辑功能之后，响应时间很长	没有指明原因与结果，包含了过分详细的细节信息。	拷贝和复制功能执行效率低。
插入的引号成为特殊符号。	信息没有充分隔离。所有的引号都如此吗？什么类型的引号。	在文档中插入一个智能引号成为不可识别的字符串。

复现步骤

• 复现步骤包含如何使别人能够很容易的复现该缺陷的完整步骤。为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的
• 但是实际软件测试过程中，总是存在一些不良的缺陷报告，主要的问题在于多余步骤、可读性差、难以理解、缺失步骤等
• 提供测试的预备步骤和信息
• 简单地一步一步地引导复现该缺陷
• 每一个步骤尽量只记录一个操作
• 每一个步骤前使用数字对步骤编号
• 尽量使用短语和短句，避免复杂句型和句式
• 复现的操作步骤要完整、准确、简短
• 没有缺漏任何操作步骤
• 每个步骤都是准确无误
• 没有任何多余的步骤
• 将常见步骤合并为较少步骤
• 只记录各个操作步骤是什么，不需要包括每个步骤的执行结果

缺陷报告注意事项

• 缺陷报告已经向读者包含完整、准确、必要的信息了吗？
• 一个缺陷报告中是否只报告了一种缺陷？
• 读者是否能容易的搜索该缺陷？
• 步骤是否可以完全复现而且表达清楚吗？
• 是否包含了复现该缺陷需要的环境变量或测试所用的数据文件？
• 缺陷的标题是按照原因与结果的方式书写的吗？
• 实际结果和期望结果是否描述不够清楚而容易引起歧义吗？

PART3-3 缺陷报告的原则

• 组织Structure：测试人员应该采用深思熟虑的，小心谨慎的方法执行测试，并且做详尽的记录。这样可以促使他们对待测试系统有很好的认识。当错误发生的时候，一个有组织的测试人员能够知道最早出现问题的地方。
• 重现Reproduce：测试人员在编写缺陷报告之前必须在检查问题是否可重现。如果错误不可再重现，仍然应该写下来，但是必须说明问题的偶然性。一个好的处理原则就是在编写缺陷报告之前反复尝试3次。
• 隔离Isolate：在尝试编写缺陷报告之前，必须试着隔离错误。可以采用改变一些变量的方法，如系统的配置，它可能可以改变错误的症状。这些信息可以为开发人员着手调试提供思路。
• 归纳Generalize：发现了一个已隔离的，可重现的问题后，应该对问题进行归纳。同一个问题是否出现在其他的模块或其他的地方？同一个故障是否有更加严重的问题？
• 对比Compare：如果测试人员以前曾经验证过现在出错的测试用例，那么他就应该检查以前的测试结果以检查相同的条件以前的测试是否通过。如果是的话，那么这个问题就像是一个回归的错误。注意由于同一测试条件有可能出现在多个测试用例中，这个步骤就不仅仅只是检查一个测试用例在以前的多个结果。
• 总结Summarize：在缺陷报告的第一行写上错误的总结是非常关键的。测试人员要花些时间思考已发现的错误对客户有何影响。这不仅仅要求测试人员编写的报告要能够吸引读者，使和管理层的沟通清晰，还要能够帮助设置错误修复的优先级别。
• 精简Condense：在缺陷报告的初稿完成后，测试人员应该反复阅读它，集中剔除那些没有关系的步骤或词语。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤而消磨报告欢迎程度的无穷唠叨都不是缺陷报告的目标。
• 消除歧义Disambiguate：测试人员在精简空话的同时或其之后随即应该再仔细检查报告是否有会产生误解的地方。测试人员应该尽量避免使用模糊的，会产生歧义的和主观的词语。目标是使用能够表述事实，清楚的，不会产生争执的词语。
• 中立Neutralize：作为坏消息的传递人，和善地提交消息是一个挑战。如同所有的错误总结一样，独立的缺陷报告在措辞方面应该保持公正。攻击开发人员，指责潜在的错误，企图诙谐或使用挖苦将引起开发人员的憎恶，并且使注意力从“提高产品质量”这个大的目标上转移开了。
• 检查Review：一旦测试人员感觉缺陷报告是他能够编写的最好版本，他应该将报告再给一个或多个同行进行检查。在允许的时间里，测试小组应该尽可能提交最好的缺陷报告。

PART4 缺陷跟踪

缺陷生命周期

缺陷状态迁移图

步骤	人员	任务	缺陷状态
1	测试人员	提交缺陷	New
2	测试负责人	分配缺陷
3	项目或开发负责人	分配缺陷
4	开发人员	验证缺陷-是缺陷	Open
-	-	验证缺陷-不是缺陷	Declined
-	开发人员	对Open的缺陷再次确认，若可复现，则修正并记录缺陷产生原因和修正方法	Fixed
-	-	对Open的缺陷再次确认，若不可重现	Need More Info
5	测试人员	对Declined的缺陷进行验证-不是缺陷	Closed
6	评审委员会（由开发经理-测试经理-项目经理-市场人员等组成）	对延期解决和分歧缺陷进行评审、分析、讨论和仲裁
7	测试人员	对Fixed的缺陷在新软件版本Build验证缺陷是否修复，若已经修复	Closed
-	-	对Fixed的缺陷在新软件版本Build验证缺陷是否修复，若没有修复	Open

缺陷跟踪管理系统

• 早期的缺陷跟踪大都是以缺陷记录单的形式完成，现在还有很多项目还用此方法，但是随着用户对软件功能需求的不断增加，软件算法和复杂度都发生了很多变化，随之而来的是软件缺陷的增长，这给缺陷跟踪带来很大挑战
• 于是，缺陷跟踪管理系统应运而生
• 在软件行业发展历程中，曾经或者正在被大量使用的缺陷管理系统包括JIRA、BUGZILLA、QC、禅道等。
• 而目前，出了部分大型IT公司拥有自研的缺陷管理系统外，很多公司应用禅道来进行缺陷跟踪甚至是项目管理。

PART5 禅道项目管理系统

禅道简介

• 禅道是一款基于Scrum思想并集产品管理、项目管理、测试管理于一体，同时还包含了事务管理、组织管理等诸多功能的项目管理软件

用户角色

• 系统管理员（Admin）：系统管理员主要负责添加用户，分配权限
• 产品人员（product owner）：产品人员主要负责产品管理
• 项目经理（Project Manager）：通过项目，协调产品人员，开发人员，测试人员完成产品
• 开发人员（developer）：开发人员负责产品的研发
• 测试人员（QA）：测试人员保证产品的质量

最简使用

• 只使用禅道来进行产品管理
• 使用禅道来进行项目任务管理
• 只使用禅道来做bug管理
• 个人使用禅道来做事务跟踪管理

项目模式基本流程

1. 产品经理创建产品
2. 产品经理创建需求
3. 项目经理创建项目
4. 项目经理确定项目要做的需求
5. 项目经理分解任务，指派到人
6. 测试人员测试，提交bug