黑马软件测试第二篇_功能测试
软件质量模型
应用场景：提供对于软件产品从测试角度思考的一种思路
定义：实际实现的产品和需求描述是否相一致，相一致程度高说明质量满足需求（好）
如何评判软件的质量？
功能：软件产品是否具备某种能力 某手机是否支持5G
性能：软件产品对于时间和空间的占用程度高低 速度快、占用空间小
兼容性：软件兼容其他类型的软硬件的能力 著名的"3Q"大战
易用性：在一定用户群的基础上，软件是否好用、容易理解 遵循专业性，例如：财务系统软件（账单、流水等）
可靠性：软件是否具备持续无故障运行的能力
安全性：软件运行过程中对于数据的传输和存储是否安全 属于专项测试，要求较高
可移植性：软件产品从一个环境移植到另一个环境中正常运行的能力
可维护性：软件出现故障后，自我修复/恢复的能力
软件的生命周期
软件生命周期：软件从无到有到消亡的过程
软件生命周期也叫软件开发过程模型、软件生命周期模型
瀑布模型
描述软件生成到消亡的过程模型图
该模型目前实际工作中已不常用，但是该模型是其他新型模型的鼻祖
瀑布模型的优点
每个阶段比较清楚，并且有对应的文档产生
当前一个阶段完成后，才开始后面的阶段（一次性的）
瀑布模型的缺点
发现问题的时机比较晚，失去提前纠错的机会
测试介入比较晚
适用场景
适用于需求不易发生变化的大项目
敏捷开发模型
能够适用需求的变化，并且能够给出快速的响应
小步快跑
ACP
软件测试模型
V模型
作用：主要描述测试、开发之间的对应关系
V模型优点
每个阶段比较清楚，测试过程由底层（代码）测试到高层（应用）测试过程
V模型缺点
不适用于需求的变更，发现问题的时机比较晚
W模型
作用：将测试过程更加细化说明，对应测试、开发之间的关系更加清楚
W模型优点
测试介入时间早，能够及时发现问题，降低修复成本
测试伴随整个软件生产周期，除了测试软件之外，还需要验证文档
W模型缺点
该模型应用起来复杂度高（具备计算机技能、业务能力、管理能力、测试素质）
测试用例
目的：
方便测试验证（将需求大量描述拆分为小的测试点）
体现测试人员的思路，测试设计的全面性（后续测试直接可以使用）
测试的量化体现，能够反应测试进度
定义
测试用例，也叫Test Case，为了特定的目的而设计的一组测试输入，执行条件和预期结果构成的文档。
构成要素
规范的测试用例应该包含哪些内容？
注意：实际工作中，如果企业中有自己的用例模板，则用自己公司的即可，核心内容基本一致
测试用例设计方法
等价类划分法
等价类定义
在批量的测试数据中，选取具有共同特征的数据子集作为测试的输入
等价类的分类
有效等价类：满足需求的测试数据
无效等价类：不满足需求的测试数据
等价类划分法设计用例步骤
案例：如何测试两个两位数整数之间的和（即-99到99之间数据求和）没有问题？
明确需求
1.测试目的 eg ： 验证两位数整数是否能够正常求和
2.测试条件 eg : 不超过两位数 整数、字母、中文、特殊符号、空格、空
长度 类型（来源于键盘输入） 规则
3.划分等价类
有效等价类：满足需求的所有条件 eg : -10 , 30
无效等价类：不满足（只要不满其中一个条件即可）需求的所有输入数据 eg ：包含字母、中文、符号、空格、空
4.提取数据编写用例 通过测试用模板按照要求填写内容
等价类适用场景
针对有批量数据输入的测试场景，无法穷举测试时适用
常见代表：输入框（下拉框、选择框、下拉列表等）
编写用例注意事项
单模块测试中，用例标题具有唯一性
必要步骤尽可能清楚
预期结果尽量描述测试结论性的语句及现象（如果有具体现象最好描述）
用例编号和测试项目简称对应设置
边界值分析法
引入的场景：开发人员常常在边界的位置容易出现问题，此时需要针对边界位置再测试
常在河边走，哪有不湿鞋
边界范围的确定
根据需求，将数据类型和边界确定，直接可以获取对应的边界范围值
上点：刚好等于边界的值 （取值不考虑开闭区间）
离点：刚好小于/大于边界上的值 （取值类型看需求）
内点：边界范围内的任何取值 （取中间的值）
边界值分析法设计用例步骤
明确需求
测试目的
测试条件
长度
类型
规则
划分等价类
有效等价类
无效等价类
确认边界范围值
确定边界范围值之后，结合等价类进行合并补充
上点
离点（可以优化）
内点（可以和有效等价类的取值合并）
提取数据编写用例
按照用例模板编写内容即可
离点优化
目的：减少用例数量，由7条数据变5条数据
注意事项：非必须，可以不用优化
离点优化：离点的选取和上点取值相反的取值点即可
边界值适用场景
对于等价类划分法的完善和补充
针对有边界范围的批量数据的输入类测试（重点关注边界）
典型代表：输入框（有边界范围区间）
判定表法
判定表引入
判定表：是一种以表格形式表达多条件逻辑判断的工具
判定表构成
条件桩：列表需求中所有条件，次序无关
灰色区域
动作桩：列出需求中条件可能采取的操作（动作），可能存在多个，次序无所谓
绿色区域
条件项：所有条件对应取值（一般取真假值）的全组合
黄色区域
动作项：上述条件项对用操作结果（通过条件项得到的结果）
蓝色区域
根据表计算测试用例
如果条件的取值只有两个，那么每种条件的组合数量为2的n次方
规则：每种条件项和动作项对应的一列就是一条规则，也叫一条测试用例
判定表设计用例步骤
明确需求
测试目的
测试条件：根据需求列出
画出判定表
列出条件桩和动作桩（根据需求来分析提取）
在条件桩前面加判定词，根据条件数量进行组合得到所有取值（条件项）
根据每种条件的组合得到动作项
优化合并相同的条件
按照规则编写用例
按照测试用例模板编写即可
判定表的适用场景
针对需求中有多个条件，并且条件和条件之间有组合关系，条件和结果之间有制约（因果）关系的场景
常见词汇：如果…那么…；若…则…
局限性：条件个数不易过多（不超过4个）
注意：超过4个条件的不常见，如果出现超过4个以上条件的，可以使用因果图（网络查询）
场景法
也叫流程图法，通过流程图的描述用户的使用场景过程，验证整个产品的业务（用户使用过程）是否正常
用户：用户使用更加关注整个系统的应用
测试：测试不仅仅要关注单功能测试，还需要关注系统之间组合测试
适用场景
一般在测试的后期，对于整个系统的模块功能进行全部的组合测试
测试的依据：业务流程图
案例：ATM取款
通过测试角度去思考画出流程图
产品设计层面细化
通过流程图识别路径，方便后续编写流程的测试用例
问题
1.实际工作中业务流程图一般有谁来画？
一般是由产品/开发的设计人员
如果在熟悉需求的基础上，测试可以画出流程图（从用户使用角度去画）
如何画业务流程图【补充】
画图工具：
Microsoft Visio
在线软件画（ https://www.processon.com/ ）
Excel
椭圆：表示流程的开始/结束
长方形：流程的处理或者操作
菱形：表示流程节点的判断（一般两种结果）
平行四边形：表示流程流转过程中数据的输入/输出
箭头线：表示流程的走向（箭头线上可以添加标记）
错误推测法
错误推测法介绍
要求：有实际项目测试经验的人使用
定义：通过直觉（经验）或者智慧推测系统可能出现问题的地方进行再次测试
错误推测法适用场景
1.时间紧迫：通过以往类似项目的经验，提取当前项目中核心模块（出现问题较多）进行验证测试
2.时间宽裕：在基础测试的基础上，将原有模块（存在问题较多）进行再次细化测试
问题
上述两种场景是否需要测试用例？
场景1：需要提取核心模块（按照用例的优先级）用例进行测试
通过xmind思维导图先整理个大概的测试点
找有相关项目经验的测试人员去测试
通过自动化的技术或者找能够提升测试效率的技术去实现测试
场景2：需要将原有用例细化完善后，按照用例依次测试即可
软件的缺陷
缺陷的定义
判断的依据：用户需求说明书 ----> 编写测试用例
软件在使用（运行）过程中存在的任何问题（如：错误、异常、失效等），都叫软件的缺陷，简称bug
缺陷的判定标准
如何确定一个问题是不是缺陷？
软件未实现需求（规格）说明书中明确要求的功能 —— 没有做
eg : 手机是否支持5G功能
软件出现了需求（规格）说明书中指明不应该出现的错误 —— 做错了
eg : 登录失败应该有错误提示，但是没有提示
软件实现的功能超出需求（规格）说明书指明的范围 —— 做多了
eg : 实现计算的软件出现聊天互动等功能
软件未实现需求（规格）说明书中虽未明确指明但应该实现的要求 —— 没做完
eg ：软件的产品对于金额默认保留两位有效数据，但是没有保留（需求中未写）
软件难以理解，不易使用，运行缓慢，用户体验不好 —— 不完美
eg ：使用过卡顿，响应速度慢、界面不好看等
问题1
面试官：如果你发现了一个问题认为是bug，开发不认为是一个bug如何处理？
首先确认是否是因为开发和测试的环境因素导致问题不一致
其次，如果部分环境因素，可根据需求说明书确认实际产品和需求是否一致
再者，需求不清楚的通过找产品确认，需求设计是否有问题，然后再和开发对接确认
【扩展】缺陷的级别
违反上述标准的1、2、3条件，基本上属于高严重级的bug
违反上述标准的4、5条件，基本属于中低级别的bug
缺陷产生原因阶段
为什么需要分析缺陷的原因？
能帮助测试领导确定产品出现质量问题的具体阶段，方便后续软件产品质量的优化
能够帮助测试人员积累经验
需求阶段：需求描述不易理解，有歧义、错误等
设计阶段： 设计文档存在错误或者缺陷
编码阶段：代码出现错误（语法、单词、标点符号等）
运行系统：软硬件系统本身故障导致软件缺陷
故障解决阶段：对于系统不熟悉修复问题时引入新bug
缺陷的生命周期
问题2
您认为上述生命周期的阶段中，哪个阶段出现问题的比例最高？
需求阶段，出现问题比例较高
需求阶段文档编写不完善、需求容易发现变化等都是造成bug的根本原因
缺陷报告的核心内容
缺陷报告的其他要素
缺陷的编号：能够唯一的表示一个缺陷
缺陷的状态：描述缺陷生命周期的过程
新建（new）: 表示缺陷的产生
打开（open）：表示开发确认通过
拒绝（rejected）：表示开发确认不通过
进行中（inprogress）：表示开发正在修复缺陷
已修复（fixed）：表示开发已经修复完成
延迟修复（delay/postpone）：表示开发延迟修复
测试通过（closed）：表示测试通过，已关闭
测试不通过（reopen/open）：表示测试不通过，重新打开
缺陷的所属模块：类似于用例的所属项目，描述缺陷产生的模块范围
缺陷的优先级：告诉开发当前缺陷修改的先后次序 （ P1）priority
urgent priority : 最高优先级
veryhigh priority : 次高优先级
high priority : 高优先级
medium priority ： 中优先级
low priority：低优先级
缺陷的严重级：告诉产品当前缺陷对于整个产品的破坏程度（和优先级一一对应） （S1）serious
critical ：致命的破坏
major ：高的破坏性
medium ： 中等破坏
minor：低等破坏
tiny ： 微小的破坏
缺陷的类型：描述缺陷主要产生问题的原因
功能问题
UI问题
兼容性问题
易用性问题
架构问题
安全问题
问题3
作为测试人员，一般什么时候提交缺陷报告？能否可以直接口头传达不写缺陷报告？
执行测试用例，并且失败的时候，就立即停止执行马上提交bug
不能，防止忘记之后无法保留证据
缺陷的管理
缺陷的跟踪流程
作用：描述开发和测试在公司中对于缺陷的跟踪管理过程
问题4
开发能否直接关闭缺陷？
不能，因为存留证据，即使报错了，开发只能拒绝，不能关闭
编写缺陷报告规范
可复现：确保当前发现的bug能够复现
唯一性：确保一个缺陷报告中上报一个问题
eg：登录测试失败了，在数据库对应表中发现当前的账号密码信息是明文的
此时描述的是两个问题，可以分开报bug
规范性：遵循公司规定的报bug的要求
eg : 客服人员发现的bug，需要在标题中单独标记
【客服】正确的账号登录过程中出现的失败的结果
注意事项
确保上报的bug是准确的
描述尽可能简洁易懂具体
不能使用感情色彩的词语
不能使用模棱两可的词汇
不能使用人称代词
面试题
在实际测试中如果出现不可复现的bug怎么办？
经过多次复现后，还是没有出现，此时在本地记录当前的问题
回顾当时操作的流程及测试环境的配置要求，确认是否由于操作失误或者环境临时故障引起
请开发协助（自己）查找当前测试模块是否有对应的日志信息（日志的位置可以问开发）
再考虑更换一套环境查看是否能够复现上述问题
在后续的版本中测试，此时需要关注当时测试该功能时是否还出现上述的问题
在后续版本还出现过，需要开发协助打印日志进行分析定位，同时测试需要提交bug
项目管理工具——禅道
在实际工作中管理实际项目的工具，协调不同部门不同角色的人员完成最后的目标
禅道介绍
禅道，英文名zentao
国产软件，部分版本开源免费
特点
三权分立
产品部门
开发部门
测试部门
四角协同
产品经理
项目经理
开发团队
测试团队
运维人员
测试使用禅道功能
管理测试用例
编写测试用例
将需求文档直接转换为可测试的功能点的过程
评审测试用例
查看已经编写好的用例是否有错误、遗漏、不正确的地方进行评估的过程
执行测试用例
按照次序执行对应评审后的用例并记录结果的过程
管理缺陷报告
提交缺陷
跟踪缺陷
验证缺陷
其他项目管理工具
JIRA（澳大利亚收费软件，作用类似于禅道）
Testlink
QC
bugzilla
禅道的使用
主界面介绍
测试部门入口
编写用例入口
创建单条用例
创建批量用例
评审用例
执行用例
管理缺陷
模板对应【直接提bug】
测试执行转bug
跟踪验证缺陷
web手工项目
Web项目环境介绍项目环境
搭建思路
作用：对应任何项目，实现测试环境的搭建需要哪些关键准备
项目的组织架构
知道一个系统如何运行的过程
web项目的组织架构图–软件层面
作用：通过硬件及软件系统层面介绍服务器环境的构成
服务器组件构成
web服务器作用：主要对于客户端页面请求进行数据存储转发处理过程
数据库服务器作用：项目中的大批量数据进行存储管理
PHP项目：对于被测软件系统的业务逻辑的判断处理
组件说明【补充】
常见web服务器：
Apache ：稳定性比较好，对于PHP项目的支持非常好
Nginx：并发性（性能）比较好，常常和其他web服务器一起结合使用
Tomcat：针对于java项目进行的web服务器的部署
IIS：针对于Windows Server系统的web服务器的部署
Apache和Nginx区别
Apache的稳定性较好，对于PHP项目的支持非常稳定
Nginx的并发性比较好，对于性能要求较高项目中
在实际工作中可以配合一起使用
针对于PHP项目可以按照上述组合进行服务搭建
上述同等位置的组件可以用同类型的组件进行替换
数据库软件：MySQL、Oracle
web服务器常见的有：Apache、Nginx、Tomcat
web项目环境安装
web环境介绍总结
熟悉tpshop项目
熟悉项目的标准
作用：
一般进入公司需要干的第一件事（知道干什么，以及怎么干）
面试时简历项目的介绍
清楚项目中核心模块（单个模块能干什么）
清楚项目中的业务逻辑（用户如何使用）
熟悉项目的步骤
项目是给谁用的？
服务的用户/对象
项目的组织架构图（包含的模块）是什么？
Xmind整理项目的构成页面
项目的业务逻辑是什么？
用户如何使用当前的软件系统
项目的核心模块有哪些？
项目中的最重要的模块有哪些
熟悉项目的依据
文档：需求文档、设计文档、用户手册、测试用例等
环境：测试环境、生成环境
人员：测试人员、产品、开发等
案例：tpshop项目
本地虚拟机tpshop商城地址：
前台：http://虚拟机IP
后台：http://虚拟机IP/admin
管理员账号：admin
管理员密码：123456
项目给谁用的
普通的前端用户（注册会员用户、游客用户）
后台的管理人员（超级管理员、客服等）
项目的组织架构图（模块）
子系统
前端
从上到下、从左到右
单功能的页面级别即可
后端
按照菜单级别划分（一级、二级）
单功能的页面级别即可
注意事项：
不要求画出所有页面
不要求每个页面的所有信息都画出
推荐用XMind画图整理，参见课堂资料tpshop组织架构图
项目的核心业务
正在进行中的项目：通过测试环境已经完成的需求熟悉，可结合需求文档
刚开始的新项目：通过产品的需求文档和产品的讲解熟悉，可结合UI设计文档/原型图
前台购买流程
注册登录–搜索商品–选择商品–下单支付（货到付款）
后台收款后–前端进入我的订单详情–查看订单状态–确认收货–评价完成
后台发货流程
后台订单管理–确认订单–发货确认–收款
商品退换货流程
前台发送售后申请
后台进行退换货审核–审核通过–原路退款
前端用户查看个人账户余额
项目的核心模块
根据项目的业务流程的熟悉及项目的组织架构，标记出与业务相关（最重要）的核心模块
项目的技术栈（了解）
LAMP ： linux（CentOS7） + Apache + MySQL + PHP
熟悉项目总结
项目的测试流程
作用：有序有效开展测试工作的基本步骤
面试问题：你们公司是怎么做软件产品的测试的？
需求评审
参与评审目的
理解一致
查漏补缺
给出建议，指导执行
评审形式
以会议的方式评审，下面部门的人必须到场
注意事项：
邮件形式：适用于跨国项目
需求文档一般在开会前至少2小时发送给对应参会人员
产品人员
开发人员
测试人员
测试人员在需求评审中职责
理解需求
找出错误及遗漏的地方
给出合理建议
banner图后台修改位置
修改完配置之后需要“更新缓存”
测试计划与方案
测试计划
测试的目标和范围
达到什么样的要求？
测试多少？
测试的角色和职责
需要什么样的人干什么样的事？
eg : 手工测试人员3人 自动化测试人员2人
测试的进度和资源分配
需要多少时间，以及需要什么的测试设备？
eg : 需要几个月，测试电脑、手机等
测试风险预估与应对措施
可能存在的风险，以及如何应对？
eg : 关键人物请假、离职
测试的准入和准出
具体什么时候开始，什么时候结束
问题
一般项目中，测试计划谁负责编写？
一般是公司测试部门的领导
测试老员工
测试方案
测试计划与方案的对比
区别
测试计划是管理型文档，描述“测试什么，谁来测试？”
测试方案是技术型文档，描述“怎么测？”
联系
实际项目中测试计划与方案可以合并为一个文档
一般有测试负责人（组长）编写制定
功能测试设计
面试官问：如何进行具体的测试设计？
测试点：将大块的需求整理拆分成可以直接测试的具体功能点过程
测试设计的步骤
轮播图案例
轮播图作用：热点商品的动态展示（核心位置的广告宣传）
设计用例
设计用例（熟悉需求没有疑问、拆分测试点、确定测试方法）
编写用例
根据模板编写具体的用例
后台处理
用例编写demo
评审用例demo
评估编写的测试用例是否正确
是否有遗漏——根据需求说明书
是否有错误，不理解
能否指导测试人员按照步骤执行
执行用例及缺陷跟踪
执行用例结果
执行用例的补充
过程中的问题
1.轮播图中，用到了后台的设置，那么后台的操作与这儿轮播图的测试之间的关系？
确定测试的范围——前端的轮播图功能
后台的配置和操作应用都是为前台做服务的（要求后台的服务功能都正常）
2.在设计测试用例之前，如果对于需求中的部分描述不够清楚怎么办？
直接问产品
问一下测试老员工
购物车测试
购物车作用：将我们临时相中商品添加到购物车，方便最后下单结算
注意：
需求拆分过程中只要确保能覆盖需求，所见及所测（包含当前功能的）即可
在实际工作中，测试评审一般评审测试点
熟悉需求——需求文档
拆分测试点——参见xmind购物车模块资料
编写用例——参见Excel购物车模块文档
评审用例
执行用例
缺陷提交
购物车测试执行后台修改（库存）
会员管理
作用：管理会员用户的地方（前台注册的普通用户）
增加、修改、删除、其他操作
顶部区域
熟悉需求
能看懂、能理解、是否有疑问
按照分配子任务开始拆分测试点
存在的疑问
拆分测试点
最基本要求：
确保覆盖需要
所见及所测
递进要求：
站在用户使用角度思考
编写测试用例
评审测试用例
执行测试用例
成功
失败——提bug
编写bug时注意标题和实际结果对应
添加会员
熟悉需求
测试目的：确定通过后台管理员添加的账号信息能否成功
拆分测试点
编写用例
会员列表
熟悉需求
作用：将前后台已经注册会员以列表的形式进行管理
拆分测试点
要求1：覆盖需求
要求2：所见及所测
编写测试用例
执行用例