软件测试
软件及测试相关知识
- 软件测试的定义
软件：
（应用软件和系统软件）控制计算机硬件工作的工具
基本组成：
页面客户端→代码服务器→数据服务器（请求、响应）
产生过程：
需求产生→需求文档→设计效果图→产品开发→产品测试→部署上线
需求方（客户、用户） 产品经理→产品经理→UI设计师→研发人员→测试人员→研发人员
软件测试：
使用技术手段验证软件是否满足使用需求
目的：
减少软件缺陷（bug），保障软件质量
测试的主流技术：
1.功能测试–验证程序的功能是否满足需求
2.自动化测试–使用代码或工具代替手工，对项目进行测试
3.接口测试–使用代码或工具对服务端提供的接口进行测试
4.性能测试–模拟多人使用软件，查找服务器缺陷
功能测试+接口测试
功能测试+性能测试
功能测试+web自动化
- 7种测试分类的区别
按测试阶段划分
1.单元测试：
针对程序源代码进行测试
2.集成测试：
又称接口测试，针对模块之间访问地址进行测试
3.系统测试：
对整个系统进行测试包括功能、兼容、文档等测试
4.验收测试：
主要分为公测、内侧，使用不同人群来发掘项目缺陷 比如游戏内测版
按代码可见度划分
1.黑盒测试：
源代码不可见，UI功能可见–功能测试
2.灰盒测试：
部分源代码可见，功能不可见–接口测试
3.白盒测试：
全部代码可见，UI功能不可见
- 质量模型的重点5项
质量模型–衡量一个优秀软件的维度
（功能性+性能+兼容性+易用性+安全）+可靠性+可维护性+可移植性
案例：
需求：
1、开发一款网络游戏（要求：10个主功能）
2、游戏支持web（浏览器）端、APP端
3、游戏上线后预计每日，20w用户玩家在线
功能性：
10个功能、功能详情
测试：
功能数量为10个
功能正确实现
错误处理情况
性能性：
预估每日在线人数20w
测试：
服务器每秒处理请求数
服务器硬件配置是否满足
兼容性：
浏览器（谷歌、ie、火狐、欧朋、苹果）
操作系统（win系统、其他）
手机（分辨率、品牌、系统、网络、其他）
易用性：
简洁 友好 流畅 美观
可靠性：
无响应（出现无响应） 卡顿（响应时间慢） 死机（系统崩溃）
安全：
加密
可移植性：
数据可移动
可维护性：
核心代码需要有说明 该独立就独立
- 测试流程的6个步骤
1.需求评审
确保各部门需求理解一致
2.计划编写
测什么、谁来测、怎么测
3.用例设计
验证项目是否符合需求的操作文档
4.用例执行
项目模块开发完成开始执行用例文档实施测试
5.缺陷管理
对缺陷进行管理的过程
6.测试报告
实施测试结果文档
- 测试模板的8个要素
用例：
用户使用的案例
例子（手机）：
1、是否能开机：打开手机按下电源键3秒钟，看是否能开机
2、验证内存：打开手机设置查看内存是否为64G
3、验证屏幕：打开手机在白屏背景下检查屏幕是否有黑色点
4、检查运行速度：打开手机下载吃鸡游戏，是否运行流畅
测试用例：
是为测试项目而设计的执行文档
作用：
防止漏测
实施测试标准
用例设计编写格式
用例编号-用例标题-项目/模块-优先级-前置条件-测试步骤-测试数据-预期结果
用例编号：项目_模块_编号
用例标题：预期结果（测试点）
模块/项目：所属项目或模块
优先级：表示用例的重要程度或者影响力P0~P4（P0最高）核心–使用频率
前置条件：要执行此条用例，有哪些前置操作
测试步骤：描述操作步骤
测试数据：操作的数据，没有的话可以为空
预期结果：期望达到的结果
案例
需求：QQ登录(4条)
1、账号为空
2、账号未注册
3、密码为空
4、密码错误
如何进行测试
1.对穷举场景设计测试点
等价类划分法
说明：
在所有测试数据中，具有某种共同特征的数据集合进行划分
分类：
有效等价类：满足需求的数据集合
无效等价类：不满足需求的数据集合
步骤：
1、明确需求
2、确定有效和无效等价类
3、提取数据编写测试用例
适用场景：
针对：需要有大量数据测试输入，但是没法穷举测试的地方（输入框、下拉列表、单选复选框）
典型代表：页面的输入框类测试
案例：
验证QQ账号的合法性
要求：6~10位自然数
案例：
验证某城市电话号码正确性
要求：
1.区号：空或者三位数字
2.前缀码：非0且非1开头的三位数字
3.后缀码：四位数字
测试用例见Excel表
（完整和用例应该是等价类和边界值一块写）
思考案例：
需求：判断输入的数据是否小于-99或者大于99，如果小于-99或大于99给出错误提示（不包含-99和99）
伪代码：
如果 a>= -99 or a<= 99:print("输入的参数值必须大于-99同时小于99")
伪代码错误，因为包含了-99和99
2.对限定边界规则设计测试点
边界范围节点
上点：边界上的点（正好等于）、离点：距离上点最近的点（刚好大于、刚好小于）、内点：范围内的点（区间范围内的数据）
步骤：
1.明确需求
2.确定的该有效和无效等价类
3.确定边界范围值
4.提取数据编写测试用例
提示：
有关范围限制，最多7条用例（暂时未优化）
边界值能解决位数限制问题，但不能解决类型问题
练习
需求：通过边界值法验证标题长度的合法性
要求：标题长度大于0，小于等于30个字符
案例优化：
结论：7个优化为5个
上点：必选（不考虑区间开闭）
离点：开内闭外（考虑开闭区间，开区间选择内部离点，闭区间选择外部离点）
内点：必选（建议选择）
3.对多条件依赖关系设计测试点
判定表法
定义：
是一种以表格形式表达多条件逻辑判断的工具
组成：
条件桩：列出问题中的所有条件，列出条件的次序无关紧要
动作桩：列出问题中可能采取的操作，操作的排列顺序没有约束
条件项：类出调价对应的取值，所有可能情况下的真假值
动作项：列出条件项的、各种取值情况下应该采取的动作结果
规则：
判定表中贯穿条件项和动作项的一列就是一条规则
假设有n个条件，每个条件的取值有两个（0，1），全组合有2的n次方种规则
步骤：
1、明确需求
2、画出判定表
1）、类出条件桩和动作桩
2）、填写条件项，对条件进行全组合
3）、根据条件项的组合去欸的那个动作项
4）、简化、合并相似规则（有相同的动作）
3、根据规则编写测试用例
使用场景：
有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖（制约）关系
判定表一般适用于条件组合数量较少的情况（比如4个条件以下）
如果超过4个，采用正交法
案例
验证“若用户欠费或者关机，则不允许主被叫”功能的测试
说明：
等价类边界值分析法主要关注单个输入类条件的测试
并未考虑输入条件之间的各种组合、输入条件与输出结果之间有相互制约关系的测试
练习
订购单检查
规则：
1）、如果金额大于500元，又未过期，则发出批准单和提货单；
2）、如果金额大于500元，但过期了，则不发出批准单和提货单；
3）、如果金额小于等于500元，则不论是否过期都发出批准单和提货单；
4）、在过期的情况下不论金额大小，还需要发出通知单；
练习
文件修改规则
规则：
1）、输入的第一列字符必须是A或B
2）、第二列字符必须是一个数字
3）、如果第一列字符不正确，则给出信息L
4）、如果第二列字符不正确，则给出信息M
5）、如果两列字符输入正确，则修改文件成功
4.对项目业务设计测试点
场景法
定义：模拟用户操作软件时的场景，主要用于测试系统的业务流程
流程图：使用标准图形和箭头来表达程序或业务的走向
http://processon.com/
流程图练习
登录、搜索商品、添加购物车、去结算、支付，如果支付成功，则提示下单成功，否则提示支付失败。
ATM取款流程
6条用例
1、开始→验证银行卡不成功→结束
2、开始→验证银行卡成功→密码错误3次→结束
3、开始→验证银行卡成功→密码验证成功→账户余额不足→结束
4、开始→验证银行卡成功→密码验证成功→账户余额验证成功→取款金额不正确→结束
5、开始→验证银行卡成功→密码验证成功→账户余额验证成功→取款金额正确→ATM机余额不足→结束
6、开始→验证银行卡成功→密码验证成功→账户余额验证成功→取款金额正确→ATM机余额充足→取款成功→ 结束
错误推荐法
定义：通过经验推测系统可能出现的问题应用场景：
当项目用例都执行完毕，且bug修复完成，离产品上线还有一段时间，在这段时间可以使用错误推荐法复测主要业务或测试未覆盖的功能
1、时间紧任务重，根据之前项目类似经验找出易出错的模块重点测试
2、实践宽裕通过该方法列出之前出现问题较多的模块再次测试
测试不通过如何处理
提示：用例执行不通过为缺陷，需要进行缺陷管理
缺陷介绍
定义：软件在使用过程中存在的任何问题都叫软件的缺陷，简称bug
判定标准：
1、少功能–软件未实现需求（规格）说明书中明确要求的功能
2、功能错误–软件出现了需求（规格）说明书中指明不应该出现的错误
3、多功能–软件实现的功能超出需求（规格）说明书指明的范围
4、隐形功能错误–软件未实现需求（规格）说明书中虽未指明但应实现的要求
5、不易使用–软件难以理解，不易使用，运行缓慢，用户体验不好（均为缺陷，软件测试人员专业角度）
产生原因
1、需求阶段
需求秒速不易理解，有歧义、错误等
2、设计阶段
设计文档存在错误或者缺陷
3、编码阶段
代码错误
4、运行阶段
软硬件系统本身故障导致软件缺陷
软件缺陷的生命周期
需求规格→说明→设计→编码→（注入bug）测试<发现bug>（清楚bug）→故障分类→故障隔离→故障解决
项目缺陷的管理流程
软件缺陷的核心内容：
标题 预置条件 复现步骤 预期结果 实际结果 必要附件
使用Excel对缺陷进行管理
使用工具管理缺陷
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
