软件测试基础—测试流程

一、引入

软件测试流程是软件测试工程师从事软件测试活动中的主要步骤、其中所要处理的活动、产出的文档等管理

一般公司的测试流程为：

• 签订合同（项目书）
• 市场人员、产品经理获取用户需求（电话沟通、当面沟通、问卷等）
• 用户需求评审（产品经理给大家分享用户想要的内容），开发、产品、测试、相关的负责人参加

• 测试需求分析：测试团队的主要工作内容
• 测试计划、测试大纲（测试方法与策略）
• 测试设计、开发：做测试用例（case、testcase、案例）
• 测试执行：手段（手工、自动化执行）、输出（测试执行记录、缺陷报告等）
• 回归测试：方式（部分回归、全量回归）、解决的问题（bug被修复了吗？ 是否引入了新的bug？）
• 测试总结报告：GJB438B—>GB—>行业标准—>企业标准（最标准最精细）
• 持续改进（pdca戴明环），形成经验和教训形成和经验池

二、测试需求分析阶段

软件需求=功能性需求+非功能性需求（性能、易用、可靠等）

1、软件需求的分类

• 业务需求：从业务场景、业务流程方面定义的内容，一般是由产品经理提供的，以user  story的形式给出
• 系统需求：用户所需要的所有的功能和非功能性需求的集合，一般是由开发团队提供，在业务基础上进行细化
  • 功能性：开发要实现的用户所需要的功能，注册功能、登录功能、查询功能、加购功能、下单功能、支付功能等
    • 注册功能：用户名、密码、邮箱等
      • 用户名：用户名是由数字、字母、下划线组成，长度在4—26位之间
      • 邮箱：符号邮箱格式xx@域名.com；邮箱名必须20位以内等
      • 密码：只能是数字，必须是6位
  • 非功能性：8大质量特性中，除了功能性的，都是非功能的
    • 性能需求：
      • xx功能的响应时间不能高于500ms
      • 系统运行过程中，cpu使用率不能高于80%
      • tps必须达到2000
    • 兼容性需求：
      • 支持Windows和macos和Linux系统平台
      • 支持edge（Windows最新版，ie已经被淘汰了）、Firefox、chrome、Safari、opera

2、测试需求（测试需求规格说明书、测试需求跟踪矩阵）

测试需求是在软件测试的需求分析阶段，通过各种手段、渠道获取软件的业务需求、系统需求，进行软件的可测性分析形成的文档，是后续软件测试过程的参考依据之一

简言之：将可以获取到支持文档，汇总成测试需求规格说明书（测试需求跟踪矩阵：每一条需求来自哪一个上层文档）

3、测试需求分析

• 分析测试范围：不是所有的需求都需要在当前版本中进行测试，要根据模块的核心程度确定要测试的范围
• 可测性分析：某个需求在当前版本中是否具备可测性
• 明确测试的类型、阶段：
  • 阶段：基本就是确认、系统和验收测试，在互联网企业中，测试人员直接参与单元测试和集成测试的较少
  • 类型：功能性测试、非功能性测试
• 优先级划分：识别哪个需求要优先测试、哪些需求可以滞后测试、哪些可以正常排队

4、需求评审

测试需求规格说明书是作为后续测试工作的指导性文档，就需要进行配置管理，形成基线文档（标准）

通过专家评审的文档（先评审、修改、提交批准），形成基线，加入三库管理（产品库、受控库、开发库）

评审的类型：

• 相互评审、交叉评审：最不正规的，测试团队内随时可以搞定
• 轮查、走查
• 小组评审
• 审查：最正规，一般要要求外部专家

5、测试管理工具

ALM：惠普软件测试三剑客（uft，loadrunner），测试管理+缺陷的工具

禅道：国产工具，开源免费，开发和测试都可以用，测试管理+缺陷工具

testlink：是测试管理工具，但是不能管理缺陷

三、测试计划阶段（熟悉文档）解决5w1h

1、什么是测试计划

测试计划就是规定软件测试项目的范围、方法、资源（人力+物力）、进度、风险等要素的文档

2、测试计划的内容

1）测试概述：该文档编写的目的、读者、项目的描述、专业术语：SRS、PRD、缺陷严重等级

2）测试范围：测试的模块、测试的类型、优先级等；测试策略和测试方法

3）测试资源：

硬件资源（各种服务器要求、客户机）

软件资源（操作系统、浏览器、基础语言环境等）

网络资源（百兆网、千兆网、专线网）

被测系统资源（测试对象、测试对象版本写清楚）

人力资源：

• 项目经理：管着开发和测试
• 测试经理/测试组长：负责测试团队、工作的管理
• 测试工程师（初级、中级、高级；性能测试、自动化测试、功能测试）：做项目
• scm：软件配置管理人员：管项目过程中的资源（源代码、开发文档、测试文档、基线文档等）
• SQA：软件质量保证人员：监督测试经理是否按照规范来开展项目实施、项目的产出物是否符合标准规范

4）进度计划：关于时间控制的要素，可以使用表格法、甘特图法、网络图法来管理进度

• 表格法表示进度安排

• 甘特图

四、测试用例设计和方法（重点）

1、测试用例

是由测试设计人员来写（1年以上测试工程师），具备测试分析（需求分析方法）能力、测试用例（模版）的开发能力

测试用例是设计出来的，而不是写出来的

1）测试用例的概念

测试用例是为了达到更好的测试效果，而设计的少量的测试场景（业务步骤）及数据（测试点）的集合，包括测试的前提条件、测试步骤、测试数据、测试的预期结果、评审结果等要素的文档

测试用例的体现形式：

可以是word文档中的一个表格，适合打印留档

可以是Excel文档，方便使用

可以在一些测试管理工具中的编写，更容易管理

还可以用思维导图编写，时间不够用的情况

3）测试用例设计应具备的原则

• 有效性
• 可复用性
• 易管理性
• 易维护性
• 易评估性

4）测试用例的要素（重点）

核心要素+其他要素

• 测试用例标题：用一句话表达清楚该条用例要实现的效果，你希望通过这条用例证明什么
  • 能够将案例关联在一起的功能验证
  • 能否将案例关联在一起的功能验证
  • 验证xxx功能是否实现
  • xxx功能正确性验证
• 前提条件：为实现该条用例的预期的结果而做的准备（环境、数据等），可以节省步骤
  • 使用VIP10的账号登录电商系统
• 测试步骤：怎么点点点，就怎么写，以第一人称的方式去写
  • 测试步骤不宜太多，10个步骤就有点多了（可以提取通用的步骤放在前提条件中）
• 测试数据：
  • 数据驱动的用例：步骤一样、数据不同、结果不同
  • 行为/场景驱动的用例：同一个功能，不同的步骤，结果不同
• 预期结果：一般从测试需求规格说明书（SRS、PRD）获取预期结果
  • 先写现象，再写结论
• 作者
• 编写时间
• 评审结论：该用例合理不，能用不
• 用例编号：文档管理的是会加编号，便于检索
• 用例描述

2、黑盒测试技术

在不清楚系统的内部实现逻辑的情况下，通过需求文档来分析输入和输出，验证功能正确性的技术就是黑盒测试

黑盒测试方法：

• 等价类法
• 边界值法
• 因果图、真假值法
• 场景法

• 探索性测试法
• 正交实验法
• 大纲法等

2）黑盒测试的作用

• 功能实现不正确、不一致
• 功能遗漏
• 界面显示错误、布局不合理
• 数据库的外部访问信息错误
• 输入输出不一致错误
• 验证性能问题
• 内存泄漏问题（动态测试、静态测试可以检测内存泄漏问题）

3、等价类思想

等价类就是根据需求，把输入条件（输入域）划分为若干个范围，从这些范围中提取某几个值、某个值代表整个范围内的其他值的用法

案例：给一个1~1000之间整数的文本框，你该怎么选择数据？

选择0、500、1005三个数据，就可以实现上述需求的100%覆盖了

有效等价类：符合需求要求的范围的数据的集合就是有效等价类

无效等价类：不符合需求要求范围的数据的集合就是无效等价类

1）等价类案例

• 数据范围：1个有效等价类、2个无效等价类，需要3个值
• 输入是布尔值：1个有效、一个无效，需要两个值
• 离散量：n个离散量，n个有效等价类、一个无效，需要n+1个值
• 集合：整数集合，1个有效等价类、一个无效等价类（非整数：小数、字母、汉字、特殊符号、为空等）

2）等价类划分的步骤

案例：一个登录系统，有经办、复审两种角色，机构名称（是否有这个机构）、用户名（有没有）及密码（匹配、不匹配、6位）信息，点击登录按钮即可

Step1：根据需求划分等价类

有经办、复审两种角色：有效等价类是经办或者复审；无效等价类：空

机构名称（是否有这个机构）：有效等价类是存在这个机构；无效等价类是不存在

用户名（有么有）：有效等价类是有该用户名；无效就是不存在

密码（匹配、不匹配）：有效：和用户名匹配，6位；无效：不匹配、4位、空

Step2：划分等价类表（对每个等价类指定编号，用于覆盖）

Step3：设计测试用例的数据

• 设计一组数据，尽可能多的覆盖有效等价类
• 设计一组数据，覆盖一条无效等价类，其他的需求都选择有效等价类
• 设计足够多的数据，完成对所有等价类的覆盖

Step4：设计测试用例

测试用例=步骤+数据

4、边界值法

实际工作中发现，大量的缺陷是分布在边界值位置的，所以要使用边界值法设计用例

边界值法是等价类划分思想的一种补充，只不过是在边界位置处等价类值

简单做法：比边界位置数据大一点、小一点以及正好边界值

1）取值特点

输入范围：[1.0，3.0]

• 1.0、3.0属于有效等价类中的边界值
• 0.9、3.1分别属于两个无效等价类中的边界值

输入范围：（1.0，3.0）

• 1.1、2.9属于有效等价类中的边界值
• 1.0、3.0属于无效等价类中的边界值

输入规定了值的个数：可以输入数据记录的条数为1~255个，取最大、最小个数，比最小小一个、比最大大一个

5、因果图

在考虑输入数据的不同取值的时候，使用等价类和边界值法

在考虑输入条件和条件之间、条件与结果之间制约关系的时候，可以采用因果图法

1）原因（输入）和结果（输出）之间的制约关系

• 恒等：有条件A就能得到结果B
• 非：有条件A一定没有结果B；没有条件A就可以有结果B
• 或：条件A1和条件A2只要有一个，就可以得到结果B
• 与：条件A1和条件A2同时满足，才可以得到结果B

2）原因之间的约束关系

• E 互斥，两个条件之间用虚线连接，两个条件只能有一个存在，可以同时不存在
• I 或约束，多个条件中至少有一个存在，不能全不存在
• O 唯一约束，必须有一个存在，两个之间不能同时存在

3）案例

找出原因（输入）

• 第一列是A——c1
• 第一列是B——c2
• 第二列是数字——c3

再找出结果（输出）

• 文件修改——e1
• 输出信息L——e2
• 输出信息M——e3

画出因果图：

A3：修改文件

B3：修改文件

AD：输出M

BD：输出M

CD：输出L、M

C2：输出M

6、场景法

场景法是模拟用户使用系统行为的一种测试方法，通过事件触发某个动作的发生，从而更改不同的执行结果

• 场景法是不设置用例上线的，是考察测试能力的地方，越多、越详细越好，是事件触发
• 相比等价类、边界值、因果图、判定表是可以评估测试用例的数量的，评估覆盖率的，是数据触发的

场景法的两个概念：

• 基本流：用黑颜色的实线箭头表示，是业务正常走通的流程
• 备选流：用各种颜色表示，从基本流的起点开始，和基本流至少有一个节点是不同的

1）场景法的测试步骤

• 根据需求分析基本流和备选流
• 基本流和备选流组合形成业务场景
• 根据场景对应的基本流和备选流选择测试数据
• 根据测试数据形成场景测试用例

2）案例

模拟淘宝购物流程，通过场景法设计对应的测试用例

Step01：分析基本流和备选流

• 基本流：登录—查询商品—加入购物车—下单—支付—完成购物
• 备选流1：未登录
• 备选流2：查询不到商品
• 备选流3：库存不足
• 备选流4：账户余额不足
• 备选流5：账户黑户（特定商品不能买）
• 备选流6：缺少收货地址
• 备选流7：删除了购物车商品
• 备选流8：取消支付
• 备选流9：取消支付后继续支付
• 备选流10：取消之后，取消订单
• 备选流11：未发货、退款
• 备选流12：已发货、退款
• 备选流13：合并支付
• 备选流14：支付余额不足，更换支付方式
• 备选流15：缺少地址，跳转添加

Step2：组合形成场景

• 正常购物场景用例：基本流
• 未登录购物场景：基本流+备选流1
• 查无商品场景：基本流+备选流2
• 加购物车不足场景：基本流+备选流3
• 下单库存不足场景：基本流+备选流3
• 支付余额不足场景：基本流+备选流4
• 支付余额不足后更换支付方式场景：基本流+备选流4+备选流14
• 支付余额不足后取消支付场景：基本流+备选流4+备选流8
• 账户被限制场景:基本力+备选流5
• 缺少收货地址场景：基本流+备选流6
• 跳转添加收货地址场景：基本流+备选流6+备选流15+基本流
• 删除购物车商品场景：基本流+备选流7
• 删除后重新添加商品场景：基本流+备选流7+基本流
• ……

Step3：根据场景设置数据

Step4：设计测试用例（模版中步骤+数据）

7、猜错法

是基于经验的一种测试方法，在某个行业、类型的测试项目中时间比较长，就清楚哪些地方容易出现问题bug

设计用例的时候就有针对性，比如：

• 一般会验证数据：0、45度、90度、180度、空、null、none等数据
• 设置头像：10M大小图片、GIF图片、把视频后缀改为png
• 先关权限，使用的时候再开启
• 先开权限，使用的时候关闭
• 权限设置询问，使用的时候禁用
• 安全性：sql注入的语法，1’；1 or 1==1#;暴利破解（登录错误多次没任何限制）

8、探索性测试

测试工程师是在不断的学习、测试并探索的过程，随着对系统的不断深入学习，可以反馈到测试过程中，以发现从浅层到深的bug

testin中的bug探索测试：先用软件，用着用着就熟了，不断提出bug的过程

9、测试设计方法的选择

在用例设计的测试策略和方法的选择

• 对于明确的输入需求，优先采用等价类思想，同时特别关注边界值
• 对于输入的条件有明显的制约关系的时候，选择因果图、判定表方法
• 对于业务流程比较清晰的需求，一定要采用场景法进行设计
• 对于参数配置（开关状态），采用正交实验法设计，可以节约大量的测试用例，但是不影响覆盖率
• 使用猜错法，补充测试用例
• 探索性测试方法，主要用于找bug，然后补充用例

10、补充：正交实验法

五、测试执行阶段

在部署完成测试环境后（开发提交被测版本，并完成部署以后），通过手工、自动化的方式，对上个阶段设计的测试用例进行执行的过程（点点点，写脚本并执行脚本），如果执行的实际结果和预期结果不一致，则需要提交缺陷报告，如果执行实际结果和预期一致，则该测试用例通过

1、部署测试环境

• 由开发提供源码，咱们自己在测试环境部署，并完成后续测试（现在并不常见）
  • 前端系统需要安装nodejs，使用npm进行安装，并启动服务
  • 后端系统，需要安装jdk，并启动对应的服务
  • 前后端、以及数据之间，做好配置（专门的配置文件）
• 公司有持续集成系统，可以统一完成环境部署（最常见）
  • 开发完成一个版本的代码编写，使用git合并代码到gitee上对应版本
  • 使用持续集成工具Jenkins，创建一个工程任务，实现对代码的部署（设计运行搭建环境的脚本）
  • 只要gitee 代码有变更（更新、增加、删除等），自动触发Jenkins点任务执行
  • 自动下载最新代码，完成环境搭建
  • 集成邮件发送功能，自动给测试人员发生被测系统的URL地址
  • 测试人员拿到URL地址就可以开始测试

2、测试执行的方式

• 手工测试
  • 俗称的点点点，具备初级测试工程师的能力（非绝对，如果业务能力强，一样是中级）
  • 业务测试是核心，要对所处的行业流程熟悉，可以发现更深层次的bug
  • 发现缺陷的能力更强一点，一般首轮的确认、系统测试基本都是手工执行
• 自动化测试
  • 稍微高级一点，手工的用例可以自动化执行了
  • 在手工测试完成至少一轮以后才能做
  • 自动化测试的核心是提升软件测试执行效率

3、缺陷的要素

预期结果和实际结果不一致则需提交缺陷报告；一致则测试通过

1）定义

软件功能和需求规格说明书要求不一致的问题称之为缺陷

• 做了不该做的事
• 没做该做的事情
• 没做没要求但是应该做的事
• 做了但是体验不好

2）缺陷要素（重点）

以文字、文档的形式将发现的缺陷现象体现出来，输出缺陷报告

• 缺陷的标题：用简洁的语音来描述问题、缺陷的现象，比如：手机号码文本框未进行数据有效性验证
• 缺陷的描述：要比标题详细一点，但是比重现步骤简洁一点
• 重现步骤：直接把对应的测试用例步骤搬过来即可，便于开发使用进行复现

• 预期结果和实际结果不一致的描述

• 缺陷的类型：设计缺陷、程序（功能）缺陷、UI缺陷、文档缺陷
• 缺陷的严重等级：缺陷对系统的损害程度的高低（参考测试计划中的定义，需要重点掌握）
  • 致命级bug：s1
    • 主要、核心功能完全丧失
    • 用户数据丢失、核心数据计算错误
    • 系统崩溃、黑屏、蓝屏、闪退、挂起、死机、重启等
    • 危及人生安全的问题
  • 严重级bug：s2
    • 主要功能部分丧失、非主要功能丧失
    • 非核心数据计算错误
    • 系统异常闪退、但是能够恢复现场、数据还在、没有丢失
    • 系统的服务受到了严重影响
  • 缺陷级bug：s3
    • 最常见的、功能性的bug
    • 数据有效性未验证（手机号码10位但是没有提示信息）
    • 非主要的功能实现不合理、不正确
  • 瑕疵级bug：s4
    • 交互界面问题
    • 有错别字、布局不合理
    • 提交信息不准确等
  • 建议级bug：s5
    • 不是必备，做产品的项目中需要这种bug
    • 你作为一个普通用户的角度使用体验不好
    • 竞品有更好的解决方案
• 缺陷的优先级：缺陷被开发修复的优先程度
  • 立即修复：p1
  • 优先修复：p2
  • 正常排队：p3
  • 延迟修复：p4
• 缺陷的原因：一般是由开发填写，造成这个缺陷的原因是什么
• 缺陷的修改影响范围：开发改了代码之后，哪些模块可能受到影响
• 附件：一定要提的一个要求，可以是图片（功能、UI类bug，需要在图片上标注问题位置和原因）、视频（功能性bug，不能百分百复习的bug，把复现bug的过程录制下来）、日志文件（软件闪退现象需要提供日志文件）等辅助资料

4、缺陷生命周期管理

1）缺陷从被发现、提交、后续的修改、回归验证，到最后的缺陷关闭的整个过程，称之为缺陷的生命周期

2）缺陷在各阶段的状态

• 新建状态：由测试工程师，在Excel、禅道测试管理工具中提交了一个新的缺陷
• 激活或打开：需要做验证，验证通过后可以指派给开发
• 拒绝：开发认为不是bug
• 修复：开发认可bug并在新版本中进行缺陷的修复
• 关闭：修复的缺陷，通过回归验证后，没问题就关闭了，谁提的谁来关
• 重新打开：修改过的缺陷，没有通过回归验证，重现打开，再次让开发修改
• 推迟：当前版本不具备修复条件，下一个版本再改
• 保留：一般是由于外部原因导致不能改，需要其他手段解决
• 不能重现：针对的是不能100%复现的bug
• 设计如此：开发依据的是系统需求和设计文档
• 重复bug：众测中非常常见

5、缺陷报告

缺陷报告不能有主观、攻击性的评价，不做评价

1）缺陷报告的标准 -5c

• 准确：不管缺陷的标题还是描述，都要准确的表达缺陷的根本现象，不能有二义性、有歧义
• 清晰：描述清晰、易于理解
• 简洁：能用一句话说明白，不要用两句
• 完整：缺陷的要素不能丢，要按照要求，核心要素都要写完整
• 一致：所有的缺陷使用相同的模版和要素

2）测试管理工具

• bugfree：免费、测试用例、缺陷均可管理
• 禅道：国产、开源、免费的，是开发整个阶段的管理，测试管理只是其中一部分功能
• Alm：原惠普的一个测试过程管理工具（商用）
• jira：国外的，商用软件，需要花钱买license的

6、禅道工具的使用

六、测试总结阶段

对整个项目阶段进行复盘，检查项目过程数据是否符合准出标准，则将汇总的数据形成输出测试总结报告并输出，测试总结报告是需要经过评审的

1、测试总结报告

1）测试报告的目的

• 通过对测试结果的分析，得到对软件质量的评价
• 分析测试的过程，产品，资源，信息，评估测试执行情况和测试计划准出标准是否符合
• 分析系统存在的缺陷，为修复和预防bug提供建议
• 对遗留的缺陷进行跟踪
• 对当次测试结果评价，是否达到交付、上线的标准
• 该文档是要通过评审，形成基线

2）测试过程数据分析

测试需求覆盖率分析：要求100%

测试执行率：不一定是100%，能够执行的用例数/总的用例数

缺陷按照严重等级、优先级、类型、所属模块进行数据的汇总

针对每个缺陷分析形成图表，针对每一张图表要有分析和结论

遗留缺陷要形成跟踪表，每一条bug都要标明缺陷的状态、跟踪记录和处理结果

3）测试结论

这个结论决定了该项目是否能正常上线、交付

2、测试报告评审

• 小组评审：内部先沟通一遍报告内容
• 审查：需要邀请相关的负责人（测试专家）、要有会议主持人、书记员等角色
• 最终需要全体与会人员同意表决，测试报告通过评审
• 形成评审的结论

3、持续改进

对整个测试过程中的经验教训的总结，形成经验池，也可以做部门、团队内的分享，持续改进

pdca质量环：

• Plan
• Do
• Check
• Action