软件测试理论

5.1.1 单元测试
概念
指对软件中的最小可测试单元进行检查和验证
应用场景
测试某个函数实现的功能是否正确
 
5.1.2 集成测试
概念
在单元测试的基础上, 将所有模块按照设计要求组装成子系统或系统，进行测试
原因
实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作
 
5.1.3 系统测试
概念
系统测试是将经过集成测试的软件，和 操作系统 / 硬件 看作一个整体，在实际运行环境下进行测试
举例
百度在浏览器和手机上都能打开, 那么根据不同环境, 我们都需要进行测试  
5.1.4 验收测试
概念
客户组织的基于最开始的需求进行的验证性测试，主要检验乙方（软件实施方）完成的系统是否满足甲 方（付款方）的业务需求
分类
α测试（内侧版本） β测试（公测版本） γ测试（待发布版本）
负责人（扩展）
客户（甲方） 委托第三方评测机构（中国软件测评中心） 乙方（软件实施方）
思考: 产品中的验收测试如何进行?
  5.2 按是否考虑代码逻辑划分
5.2.1 黑盒测试
概念
黑盒，顾名思义就是：把测试对象看作一个不能打开的黑盒子。测试时，测试人员完全不用考虑盒子里 面的逻辑结构和具体运作，只依据需求文档，检查程序的功能是否符合它的功能说明，检验输出结果对 不对
测试依据
需求文档
重点
以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。
分类
功能相关 功能测试: 检查产品功能是否满足需求 界面测试: （又称UI测试）, 检查页面元素是否符合UI设计, 页面是否美观 (测试界面各元素布 局是否合理, 整体风格是否一致)
易用性测试: 用户体验 专项测试, 如: 安装/ 卸载/ 升级测试, 网络专项测试 性能相关 性能测试: 模拟用户场景, 测试系统的各项性能指标, 查看是否满足需求 压力测试: 在高压 (高负载/ 资源少) 的情况下运行测试, 找出性能隐患 负载测试: 不断增加负载, 测试软件吞吐量上限, 以验证系统的负载能力
 
5.2.2 白盒测试
概念
与黑盒恰恰相反，这种方法是把测试对象看作一个打开的透明盒子。测试时，测试人员会利用程序内部 的逻辑结构及有关信息，通过在不同点检查程序状态，检验程序中的每条通路是否都能按预定要求进行 正确工作
测试依据
源代码
重点
必须检查程序的内部结构，从程序的逻辑着手，得出测试数据
 
5.2.3 灰盒测试
概念
介于黑盒测试与白盒测试之间, 只关注一部分代码逻辑
应用场景
常用于集成测试, 专项测试   5.3 按是否运行划分
5.3.1 静态测试
概念
静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序 的正确性。
测试对象
需求文档 各类设计文档 源程序做结构分析, 流程图分析, 代码走查
 
5.3.2 动态测试
概念
动态测试方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健 壮性等性能。
测试对象
代码/系统/软件
步骤
测试用例设计（需求分析） 执行测试用例 检查运行结果与预期结果
  5.4 按是否自动化划分
5.4.1 手工测试
手工的方式去执行测试
5.4.2 自动化测试
需要借助工具或代码去完成手工测试工作
  5.5 其他
5.5.1 冒烟测试
针对最基本的功能或者流程进行的测试
5.5.2 回归测试
概念
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
应用场景
bug回归 旧功能回归
回归原则
每一个版本都需要进行前一个版本的回归测试工作
需要轮次
取决于实际项目计划、开发计划、测试计划和项目本身规模与复杂度
缺点
工作量大
解决方案
自动化测试：自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
5.5.3 随机测试
需要一定的相关经验 测试一些重要功能 测试其他人 没有测试到的模块
5.5.4 探索性测试
测试思维技术 具体问题具体分析 测试设计与测试执行同时执行
  6 最佳实践流程-2
  7 测试用例 7.1 概述
概念
一个为了特定目的而设计，包含测试输入、执行条件、预期结果的文档
软件测试用例的作用
便于理清测试思路，确保需覆盖测试的功能点无遗漏 便于测试工作量的评估 便于提前准备测试数据 便于把控测试工作进度 便于回归测试 便于测试工作的组织，提高测试效率，降低测试交接成本
软件测试用例的8大要素 编号ID（唯一性） 项目/模块 标题（见名知意） 前置条件 外在环境（网络、系统服务正常与否） 本模块的前置模块 测试数据 测试步骤 预期结果 需求文档 优先级（在资源受限制（时间、人员）时，测试用例执行的先后顺序） 7.2 登录案例
  8 测试用例设计方法 8.1 总体介绍
应用场景
我们知道, 黑盒测试的测试用例是无法穷尽的, 我们需要科学的方法帮我们把无限变为有限
常见的8大测试用例设计方法
等价类（五星） 边界值（五星） 判定表（五星） 因果图（二星） 正交法（三星） 场景法（五星） 流程图（五星） 错误推测法（二星）
  8.2 等价类划分法（五星）
应用场景
有数据输入的地方就可以使用, 如: 输入框 为什么要用等价类划分法?
从大量数据中划分范围（等价类），然后从每个范围中挑选代表数据，这些代表数据要能反应这 个范围内数据的测试结果。
步骤

1. 需求分析 2. 划分等价类: 有效等价类 / 无效等价类 满足需求的输入范围为有效等价类, 反之为无效等价类
2. 设计测试用例
   举例
3. 需求分析: 输入条件 A: 6~10 位 B: 自然数 2. 划分等价类 有效等价类 (同时满足条件A和B) 无效等价类
   需求: QQ账号输入, 6~10位自然数
   不满足A: 不足6位的自然数 或 10位以上的自然数 不满足B: 非自然数 (比如带字母) 都不满足: 不足6位的非自然数 或 10位以上额非自然数 3. 设计测试用例 (demo只有格式)
     8.3 边界值（五星）
   应用场景
   与等价类划分法组合使用
   为什么要用边界值法?
   边界值法是等价类划分法的重要补充 大量程序错误往往容易发生在边界上
   步骤
4. 需求分析 2. 划分等价类 3. 确定边界值: 找出上点 / 内点 / 离点 4. 设计测试用例
   边界值
   上点：边界之上的点（比如两位数加法器的99） 内点：边界之内的点（比如两位数加法器的-99 举例
5. 需求分析: 略 2. 划分等价类: 略 3. 确定边界值
   位数

需求: QQ账号输入, 6~10位自然数

上点：6  10 内点：8  离点： 5  7  9  11 4. 设计测试用例
设计输入数据
有效等价类: 代表数据, 分别输入 6/ 7/ 8/ 9/ 10 位自然数 无效等价类: 代表数据, 分别输入 5/ 11 位自然数; 8位字母
练习
  8.4 判定表（五星）
应用场景
用于处理较复杂的业务逻辑, 能避免遗漏测试点 要求: (需同时满足)
输入项之间互相独立, 输入值只有2个取值 (或是和否) 输出项之间互相独立, 输出结果只有2个取值 (或是和否)
组成
条件桩：输入 条件项：输入值 动作桩：输出 动作项：输出值
步骤

1. 需求分析 2. 通过判定表法, 列表分析 3. 设计测试用例，每列数据对应一条测试用例
   举例
2. 需求分析 分析输入/ 输出, 查看是否符合判定表的应用场景
       1 2 3 4
   输入条件1 欠费? Y Y N N
   输入条件2 关机? Y N Y N
   结果1 允许主被叫       √
   结果2 不允许主被叫 √ √ √
3. 通过判定表, 分析

需求: 填写文章标题, 要求标题长度10~20

需求: 若用户欠费或者关机，则不允许主被叫
如何简化判定表? 3. 设计测试用例，每列数据对应一条测试用例
练习
https://www.cnblogs.com/feng0815/p/8794400.html
  8.5 因果图（二星）
应用场景
输入条件或输入条件的组合比较多，组合使用判定表与因果图。
为什么要用因果图?
借助图像手段去分析判定表
步骤
将数字标识输入和输出 画出因果图 将因果图转换为判定表 生成测试用例
举例 (了解)
说明:
恒等（-）：条件满足时，结果成立 非（~）：条件不满足时，结果成立；条件满足时，结果不成立 或（V）：只要有一个条件满足，结果就成立 与/且(^)：多个条件都需要满足时，结果才成立
  8.6 正交法（三星）
概念
#需求: 如果想对文件进行修改，    输入的第一列字符必须是A/B，第二列字符必须是一个数字，    如果第一列字符不正确，则给出信息L；    如果第二列字符不正确，则给出信息M。
是一种古希腊就有的实验设计方法, 基于数学概率学知识, 设计最经济的实验路径
应用场景
输入条件较多, 每个条件的取值的可能性也比较多时, 可以使用正交法
步骤
需求分析 采用正交法设计测试用例 (一般使用工具) 设计测试用例（一行就是一条测试用例）
举例
使用 allpairs 工具自动生成 其他示例了解地址: https://www.cnblogs.com/killmyday/archive/2011/05/30/2063557.html
  8.7 场景法（五星）
应用场景
用于各种测试阶段, 比如系统测试/ 验收测试阶段, 模拟用户操作场景 (测试多个功能组合)
步骤

1. 需求分析 2. 确定基本流与备选流设计测试场景

需求: 假设有一个用户筛选功能，有3个输入分别是体型、年龄段、性别，        体型有3个取值：胖、适中、瘦；        年龄段有3个取值：老人、青年、儿童；        性别有2个取值：男，女；

基本流: 模拟用户正常流程或操作的场景 备选流: 模拟用户错误操作或流程的场景 图解:
3. 一个场景就是一条测试用例
举例

1. 分析用户操作微信发红包可能遇到的情况 2. 分析场景如下: 场景1: 成功发红包 === 基本流 场景2: 余额不足 === 备选流1 场景3: 被删除好友 / 被拉黑 === 备选流2 场景4: 网络异常 === 备选流3 … 3. 编写测试用例
   练习
   使用场景法, 为例图设计测试用例   8.8 流程图法（五星）
   应用场景
   用流程图的方式去展现基于用户使用场景
   步骤
2. 需求分析 2. 绘制流程图
   常用符号
   开始或结束：椭圆 方向或路径：箭头

需求: 测试微信发红包的功能, 用场景法设计测试用例

处理或操作：长方形 判断：菱形 输入或输出：平行四边形
3. 设计测试用例（一条流程路径就是一条测试用例）
举例
  8.9 错误推断法（二星）
应用场景
测试人员使用经验或直觉去发现程序的错误
问题: 有经验的老鸟, 是如何使用此方法的?
举例
新开发的功能，与其相关的业务，或者数据，容易出现问题 分页功能，页码搜索 新功能的，异常场景 列表功能，为空时，是否报错 ？ 文本框，“空格 / 特殊字符”的处理
  8.10 测试用例设计方法总结
原则
具有输入功能，但输入之间没有组合关系==》推荐是等价类划分法
#需求: 根据生活中的ATM取款功能, 画出业务流程图
输入有边界如长度、类型==》用边界值法补充测试用例 多输入、多输出、输入与输入之间存在组合关系、输入与输出之间存在依赖和制约关系==》推荐 使用因果图和判定表 用最少的测试用例获得最大测试覆盖率时==》推荐使用正交法 多个功能的组合测试==》流程图与场景法 最后推荐使用错误推测法来进一步补充测试用例
  9 软件缺陷与缺陷管理
学习目标
掌握软件缺陷的定义 掌握缺陷报告的基本内容 掌握缺陷的跟踪过程（缺陷的生命周期） 掌握SVN的常用操作 了解JIRA的基本使用 9.1 软件缺陷概述
概念
软件缺陷就是软件的毛病, 它可能存在于功能/性能/易用性等各个方面, 包括已发现和未发现的
业内经常把缺陷称为 bug, 故事背景如下: 从电脑诞生之日起，就有了电脑BUG。第一个有记载的bug是美国海军的编程员格雷斯·霍波发现 的。
1945年9月9日，下午三点。霍波中尉正领着他的小组构造一个称为“马克二型”的计算机。这还不 是一个完全的电子计算机，它使用了大量的继电器。机房是一间第一次世界大战时建造的老建 筑。那是一个炎热的夏天，房间没有空调，所有窗户都敞开散热。
突然，马克二型死机了。技术人员试了很多办法，最后定位到第70号继电器出错。霍波观察这个 出错的继电器，发现一只飞蛾躺在中间，已经被继电器打死。她小心地用镊子将蛾子夹出来，用 透明胶布帖到“事件记录本”中，并注明 “第一个发现虫子的实例”
通俗的理解
业内标准:
软件未实现需求文档要求的功能 软件实现了需求文档未提到的功能 软件未实现需求文档虽未明确提及但应该实现的目标 软件难以理解 / 不易使用 / 运行缓慢或 (从测试人员角度看) 最终用户会认为不好 概括的说: 实际结果与预期结果不一致
思考
只有在测试阶段才去发现和解决 bug 吗?   9.2 缺陷产生的原因
需求原因: 文档错误 / 有疏漏等 编码原因: 设计有误 / 编码错误等 其他原因: 时间紧, 沟通理解有问题, 甚至如立项就是个错误等
缺陷的产生, 有没有测试的原因?
  9.3 缺陷的描述
应用场景
测试人员发现 bug 后, 应准确无误的描述 bug, 描述的内容应该具有规范性
要素
编号（ID）: 唯一性 模块 缺陷标题: 见名知意 / 让开发人员理解 / 唯一性 严重程度 严重: 主功能不可用、crash问题、闪退、不能启动 一般: 次要功能不可用，边界、异常未进行处理等 微小: 易用性问题、界面展示，小的性能问题等 建议 优先级 高: 阻塞性问题, 影响继续测试 中: 正常流程, 本次迭代上线修复即可 低: 可以延期到下个版本解决 复现步骤 预期结果 实际结果 缺陷类型: 代码错误 / 界面错误 / 兼容性错误 / 性能问题 / 安全问题 / 易用性问题 缺陷状态 新建 已指派 打开 修复（已解决）/  拒绝 /  延期 完成 / 再次打开
  9.4 缺陷报告
概念
一个记录缺陷的文档
组成
包括了缺陷描述的全部内容, 附加测试日期, 解决人员, 解决日期, 解决方案 和 文档本身的说明信息 等
Bug ID   测试日期  
测试人员   Bug 类型  
功能模块   环境 (系统/ 浏览器)  
严重程度   优先级  
Bug 标题      
步骤 / 结果      
解决者   解决日期  
解决方案      
注意事项
一个缺陷一个报告 尽量确保缺陷可以重现 简洁、准确、完整
  9.5 BugList
概念? 作用?
  9.6 缺陷的统计
应用场景
统计数据需要整理到测试报告中，方便项目相关负责人知悉当前测试版本的整体质量
作用
了解隐患
绩效考核
统计维度
按照缺陷的活动分布统计: 第几轮测试? 验收测试? 上线后? 按照缺陷的严重程度分布统计: 严重的多? 建议的多? 按照缺陷引入源分布: 需求引入? 编码引入? 按模块统计bug: 哪个模块? 按负责人统计bug: 哪个开发盛产bug? 按解决方案统计: 已解决? 不是bug? 无法重现? 设计如此? 不予解决? 外部原因? 图例:
  9.7 缺陷管理-禅道
9.7.1 总体介绍
背景
工作中, 测试人员需要用BugList/ Bug统计等形式去汇报工作, 那么是用手动的方式去管理吗?
当然不是, 我们可以借助工具帮我们管理Bug: 如BugFree/ Bugzilla/ Mantis/ Jira/ 禅道等
为什么选择禅道
其中 Jira/ 禅道属于项目管理工具 禅道是国产的
 
9.7.2 禅道安装
安装环境
双击提供的 phpStudy20161103.exe 进行安装, 好处是纯绿色解压
安装禅道

1. 解压提供的开源版压缩包到指定目录下, 如我的是: D:\phpStudy\WWW\zentaopms
   也可以从官网下载
2. 配置服务目录信息, 即去哪个项目下找服务 打开 httpd-conf, 配置 DocumentRoot  “D:\phpStudy\WWW\zentaopms” 3. 配置禅道的运行依赖 打开 php.ini, 删除 extension=php_openssl.dll 前的 “;” 4. 启动 phpStudy 5. 启动禅道的安装 浏览器输入 http://localhost/www/install.php 回车进行安装
   注意
   安装成功后, 会要求修改密码, 如果对于弱口令检查有意见, 可以登录后关闭该项检查
   后台 -> 安全 -> 进行修改
    
   9.7.3 禅道协同工作流
   https://www.zentao.net/book/zentaopmshelp/165.html  
   9.7.4 测试人员使用流程
   内容
   测试用例管理 Bug管理
   测试用例管理
3. 编写用例
4. 用例评审
5. 用例执行 Bug管理 1. 提交Bug
6. 回归测试 回归测试通过则关闭 bug 回归测试不通过则激活bug 已关闭的bug再次出现, 可重新激活
   测试 -> 用例 -> “+建用例”
   1.用例的评审功能，禅道里默认是关闭的, 可以由管理员到后台 -> 自定义 -> 用例 --评审流程 里开启 2.开启后, 新建的用例状态为[待评审] 3.用例评审是一个线下活动，线下开会评审用例后，由有权限的人员显示修改用例状态
   测试 -> Bug -> “+提Bug”
7. 导出 / 报表
     10 SVN 10.1 总体介绍
   概念
   SVN是Subversion的简称，是一个开源版本控制系统，用于多个人共同开发同一个项目时，实现资源共 享, 实现集中式管理
   管理对象
   需求、设计等文档 代码（源程序）
   集中式管理的工作流
   集中式代码管理的核心是服务器，所有开发者在开始新一天的工作前: 1. 必须从服务器获取代码 2. 然后开发 3. 最后解决冲突，提交
   所有的版本信息都放在服务器上。如果脱离了服务器，开发者基本上可以说是无法工作的
   补充概念
   服务器集中存放文档/ 代码的地方叫做仓库/ 版本库   10.2 服务端
   10.2.1 服务端安装
   测试 -> Bug -> 可以看到"+提Bug"旁有 导出 / 报表 功能
   下载
   官方地址: https://www.visualsvn.com/server/download/
   安装
8. 双击安装包, 一路默认即可 2. 有需要的可以更改部分路径, 如: 安装 / 仓库 / 备份路径
    
   10.2.2 添加用户
   右键 Users -> Create User…
   修改用户密码
   右键具体某用户 -> Set Password…  
   10.2.3 添加用户组
   右键 Group -> Create Group…
    
   10.2.4 创建仓库及获取地址
   创建仓库
   右键 Repositories -> Create New Repository…
   获取仓库地址
   右键 具体某仓库 -> Copy URL to Clipboard
    
   10.2.5 服务启动/停止/重启
     10.3 客户端
   10.3.1 客户端安装
   下载
   TortoiseSVN, 官方地址: https://tortoisesvn.net/downloads.html
   安装
9. 双击安装程序 2. 一路默认, 下图稍加注意, 选择是否安装命令行工具
   汉化
   TortoiseSVN, 官网下滑会找到 Language packs (语言包), 选择下载并安装即可
    
   10.3.2 客户端基本操作
   检出（checkout）
   将服务器上的最新的文档或程序代码拉取到本地客户端
   更新（update）
   从服务器更新文件操作
   添加（add） 客户端新增文件，需要先svn add添加到本地仓库；然后运行commit真正提交到服务器 删除（delete）
   先选中文件，然后右键选择delete，然后commit，填写相关日志信息 提交（commit）
   客户端文件内容已修改，需要将更新后的文件推送到服务器
   更新至版本（Update to revision）
   更新版本可以使本地副本更新到任意一个历史版本，方便用户详细查看某一版本的具体内容。 注意：只是在客户端临时恢复到以前的某个版本，服务器端文件内容不会发生改变