导图社区 软件系统测试知识点总结
- 12
- 举报
软件系统测试知识点总结
软件系统测试基础知识点总结，软件测试是使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
编辑于2024-01-12 16:00:06- 软件
- 基础知识
- 相似推荐
- 大纲
系统测试
概念
软件测试是使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
内容
MCP
Minimal Concept Principle（最小概念原则）
软件生命周期
计划
确定开发目标：开发一款小软件
完成项目可行性研究：能不能做，做出来是否有意义
对项目进度进行预估和安排：人，时间预算
制定实施计划
需求分析
分析整理项目需求项：需要开发的功能，详细的特性
根据整理出的需求项，编制需求规格说明书（SRS：Software Requirement Specification）
制作产品原型
设计
完成项目概要设计
完成详细设计
编码
根据概要设计说明书以及详细设计说明书，完成代码编写
测试
单元测试：程序最小单元（函数或一个类的代码）
集成：模块与模块之间接口进行测试
系统：对完成编译的系统整体进行测试的过程
验收：与客户一起完成测试
运行与维护
产品部署
运行维护
功能升级
性能提升
常见测试模型
传统瀑布模型
缺点：测试后置，开发完成后，修改成本巨大
V模型
特点：将测试过程细化，分为了单元测试、集成测试、系统测试和验收测试四个不同的阶段
缺点:测试后置，没有解决风险问题
W模型
优点
①测试的活动和开发同时进行
②测试对象不仅仅是程序，还包括需求和设计
③尽早发现软件缺陷可降低开发成本
缺点
无法支持灵活的版本迭代
敏捷开发模型
特点
敏捷开发与测试模型主要是为了适应现代互联网公司“短平快”的开发节奏而设计的一种开发和测试模型
内容
①迭代：每次迭代叫做一个sprint，每个sprint里面选出来要实现的需求会安排到sprint backlog里面，每个sprint一般是以一个月作为周期
② Product Owner：相当于是产品经理。整理出整个项目的所有需求，并且按照需求的优先级来将需求排列到Produce Backlog
③ Daily Meeting：每日会议，一般是站会形式。每个人发言一般不会超过1分钟，主要内容包括三点：昨天完成的工作、今天准备开展的工作、面临的风险和问题
④ sprint burndown：迭代燃尽图，记录剩余的工作量
⑤ sprint review meeting：迭代回顾会议，主要是去回顾在本轮迭代中存在的问题有哪些、如何改进等
⑥ scrum master：相当于组长，由他来统一管理组员
软件质量模型
定义
软件质量模型提供了从不同维度考量产品质量属性的依据
内容
功能性、可靠性、易用性、性能效率、兼容性、安全性、维护性、可移植性
可移植性和兼容性的区别：
可移植性是属于产品的内部质量，更关注代码在不同的平台上是否可以正确的安装和配置。
兼容性是属于产品的外部质量，更关注的是最终用户能感知到的不同的浏览器、不同分辨率、不同设备之间的正确的使用及显示。
测试方法
黑盒测试
指在不知道被测软件代码结构的基础上，根据产品需求规格、站在最终用户的角度来对软件的输入和输出进行测试的过程叫黑盒测试
白盒测试
指基于被测软件的代码和结构，对被测软件的代码和结构本身进行测试的过程叫白盒测试
灰盒测试
介于白盒和黑盒之间，一般来说灰盒是针对接口来进行测试，比如只知道函数的函数名、参数以及返回值，并不知道函数内部的实现结构
集成测试
单元经过测试，底层软件缺陷被找出并修复之后，就集成在一起，对模块的组合进行集成测试，较多涉及接口测试
确认测试
也叫冒烟测试，确认基本功能是否实现，一般不作为正式的测试环节
系统测试
系统所有功能的测试，模拟所有软件用户的操作
回归测试
对软件新版本测试时重复执行之前的测试用例
目的
①验证之前缺陷已修复
②确认修复缺陷没有引发新缺陷
验收测试： 供求双方以及第三方的测试，依据运行主题的不同可分为ɑ测试（内侧）、β测试（公测）、γ测试
项目相关的文档
开发阶段主要文档
需求规格说明书
概要设计
详细设计
测试阶段主要文档
测试计划和方案
测试用例
缺陷报告
测试报告
方法
测试流程
分析
需求评审（需求评审检查表）
需求从哪里来，如果没有需求怎么办？
需求评审怎么评？
测试需求分析
为啥要做测试需求分析？
测试需求分析流程
得到测试点
计划：测试计划和方案文档编写
测试设计的概念
用例编写
测试编号：TC TestCase
测试标题：用一句话来表述该条用例是测试哪个测试点的。
优先级：高中低。作用是在项目时间不够或者人员不充足的时候，我们可以优先测试重点的测试用例
预置条件：在执行该条用例时，系统必须预先达到的一个状态或者条件。可选，有就写，没有就不写
测试步骤：详细描述在测试这条用例时，需要进行哪些操作。
预期结果：来自于需求，要求我们达到的一个结果。
实际结果：实际操作系统之后得到的结果。
测试结果：pass/fail/NA pass 预期结果和实际结果相同。 fail 预期结果和实际结果不相同。N/A 指当前用例不适用或无法操作
设计：测试用例设计
测试用例设计方法
等价类法
输入域：所有用户可以输入内容的区域
等价类设计步骤
编写等价类表，为每个输入划分等价类，得到等价类表，为每个等价类规定一个唯一编号
设计一个测试用例，使其尽可能多的覆盖所有尚未覆盖的有效等价类。重复这一步骤，使得有效等价类均被被测试用例所覆盖
设计一个测试用例，使其只覆盖一个无效等价类。重复这一步骤使得所有无效等价类均被覆盖
等价类划分原则
如果输入条件规定了取值范围或值的个数，则可以确定一个有效等价类和两个无效等价类
要求输入年龄在18-25 岁之间，则 18-25 就是一个有效等价类，小于 18 和大于 25 就是两个无效等价类
要求一个函数有3 个参数，则 3 个参数就是一个有效等价类，大于 3 个和小于 3 个都是无效等价类
输入条件规定了输入值的集合，或是规定了必须如何的条件，则可以确定一个有效等价类和一个无效等价类
比如要求输入学历值，学历包含大专、本科、硕士、博士、博士后，那么学历中的这些值就是一个有效等价类，凡是不属于这个学历集合中的值就是一个无效等价类
在输入条件是一个布尔值的情况下，可确定一个有效等价类和一个无效等价类
比如要求输入性别为女，那么女就是一个有效等价类，男就是无效等价类。
如果我们确知，已经划分的等价类中各个元素在程序中的处理方式不同，则应该将此等价类进一步划分
在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（遵守规则）和若干个无效等价类（从不同角度违反规则）
要求输入的数据必须是一个正整数，那么正整数就是一个有效等价类，无效等价类可以是0 ，负数、小数
边界值法
定义
1.对程序的输入和输出边界进行测试的一种黑盒用例设计方法，常与等价类设计法结合使用，此时它的用例来自于等价类的边界。
2.边界值分析法的理论基础是假定大多数的错误是发生在各种输入条件的边界上，如果在边界附近的取值不会导致程序出错。那么其他的取值导致程序错误的可能性也很小。
3.边界值使用条件（重点：可度量）
输入条件明确了一个值的取值范围，或是规定了值的取值个数
输入条件明确了一个有序集合
相关概念
上点：边界上的点
离点：离边界最近的点
内点：取值域内的任意一点
每个点一定是一个不同的数字，不可能一个点既是上点又是离点
上点：范围中你看到的那两个点一定是上点
用例步骤
分析输入参数的类型：从测试规格中分析得到输入参数类型
等价类划分（可选）：对于输入等价类划分方法进行等价类的划分确定边界：运用域测试分析方法确定域范围的边界（上点、离点与内点）
形成测试项：选择这些上点、离点与内点或者这些点的组合形成测试项
分析原则
如果输入（输出）条件规定了取值范围，则应该以该范围的边界内的及边界附近的值作为测试用例
如果输入（输出）条件规定了值的个数，则用最大个数、最小个数，比最小个数少1，比最大个数多1的数作为测试用例
如果程序规格说明中提到的输入或输出是一个有序的集合，应该注意选取有序集合的第一个和最后一个元素作为测试用例
如果程序中使用了一个内部数据结构，则应该选择这个内部数据结构的边界上的值作为测试用例
使用场景：把输入条件分成多个不同的子条件，条件与条件之间相对独立，没有制约关系
判定表法
定义（是否）
判定表是分析和表达多种输入条件下系统执行不同动作的工具，它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。
条件桩
列出系统所有输入，列出的输入次序没有影响
条件项
列出针对它左列输入条件的取值，在所有可能情况下的真假值
动作桩
列出系统可能采取的操作，这些操作的排列顺序没有约束
动作项
列出在输入项的各种取值情况下应该采取的动作
设计步骤
确定规则的个数。如这里有3个条件，每个条件有两个取值，故应有2*2*2=8种规则
列出所有的条件桩和动作桩
填入条件项
填入动作桩和动作项
化简，合并相似规则
将每条规则转化为用例
流程分析法
定义
流程分析法（又名场景设计法）是将软件系统的某个流程看成路径，用路径分析的方法来设计测试用例。 根据流程的顺序依次进行组合，使得流程的各个分支都能走到。 这是从白盒测试中路径覆盖分析法中推广到黑盒测试中来的测试分析方法。
概念
基本流：指所有操作都正确的主流程
备选流：指部分操作不正确的流程分支
设计步骤
画出业务流程图
设置功能路径优先级
确定测试路径
选取测试数据
构造测试用例
例子：某嵌入式系统中，将待发送的数据打包为符合CA协议的帧格式后，便可写入发送缓冲区.，并自动发送。
1.进入发送子程序
2. 系统判断是否有空闲发送缓冲区，如果没有则返回，显示发送失败信息
3.如果有空闲缓冲区将数据包写入空闲发送缓冲区
4.系统判断是否写入成功，如果不成功则返回，显示发送失败信息
5. 如果写入成功，则启动发送命令
6.返回发送成功消息
错误猜想法
定义
错误猜测法就是根据经验猜想可能有什么问题并依此设计测试用例
错误测法只能作为测试设计的补充而不能单独用来设计测试用例.否则可能会造成测试的不充分
错误猜测不是瞎猜，不是没有根据和目的的猜测.它需要依据对系统薄弱地方的了解和对开发人员盲点的了解
例子
a = [3,5,8,9,2,4]
重复
[1,1,1,1,1,1,1]
非数字
[1,2,3,a,7,6,5]
列表为空
: [] [67]
顺序问题
[1,2,3,4,5,6] [6,5,4,3,2,1]
业务熟悉程度、编程经验的丰富度
测试用例设计总结
测试用例设计方法很多，我们不仅要知道每种方法怎么用，更需要清楚每种方法使用的场景。
等价类和边界值是任何其他测试设计方法的基石，必须首先考虑使用等价类和边界值进行用例设计。
当输入域与输入域之间有约束关系 ，必须使用 判定表来进行组合。
在考虑了所有测试用例设计方法后，最后还要使用错误猜测法进行补充，以免遗漏。
在测试某一个字段时，应保证其他字段的取值是一个正常值。
实现：编写测试用例、测试脚本等
测试点的分析和提取
做测试前思考的问题
你知道要测试的系统是干什么的吗？
你了解系统有哪些特点吗？
你知道系统有哪些功能吗？
你知道系统的业务流程是什么吗？
系统在这个版本上，哪些需要测试，哪些不需要测试？
系统对性能、安全性上有没有什么要求？
测试需求分析流程
1、根据产品需求提取系统的测试点
1.首先检查界面元素的显示是否正确
2.测试页面的基本功能。如果页面既有表单也有列表，则优先测试表单功能是否正常
3.针对表单在测试时，需要依据表单里面的每个字段依次进行测试。凡是用户可输入的输入域，都要使用等价类和边界值根据字段的约束来进行考虑
4.如果多个字段之间有关联关系和制约关系，那么在测试完单个字段的等价类和边界值之后，应该继续使用判定表等测试方法进行组合的测试
5.表单测试完后，再测试列表中的功能
6.当单个页面的内容都测试完毕后，再来结合流程分析法（场景法）测试流程相关的内容
7.流程分析测试完后，最后再使用错误猜测法来确保没有遗漏的测试点
8.例子
2.编写需求跟踪矩阵
需求跟踪矩阵指的是根据产品需求和测试点以及测试用例，建立一个三者映射的列表，这个表叫做需求跟踪矩阵
需求跟踪矩阵的作用
建立产品需求、测试需求与测试用例之间的映射关系，方便进行用例需求覆盖率统计
如果需求发生变更，可以根据需求跟踪矩阵快速定位哪些测试用例需要更新
3.根据测试点利用适当的测试用例设计方法设计测试用例
执行：搭建测试环境、执行测试脚本、缺陷报告
搭建测试环境
服务器环境搭建
JDK的安装
JDK的安装主要是为了提供 JAVA 的运行环境。（TOMCAT服务器是由 java 写的，所以要运行tomcat 必须先设置好 JAVA 运行环境）
JAVA_HOME:你安装 JDK 的路径
CLASS_PATH .;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar
在Path 环境变量中，添加 %JAVA_HOME%\jre\bin 和 %JAVA_HOME%\bin 这两个路径
TOMCAT的安装
tomcat作为主要的web服务器，负责处理客户端发送的所有请求
把tomcat压缩包解压到一个不含中文或特殊字符的路径下
CATALINA_HOME：你解压缩tomcat包的路径
在Path环境变量中，添加%CATALINA_HOME%\bin路径
通过双击bin目录下，startup.bat这个文件来启动tomcat
MYSQL数据库的安装
Mysql数据库主要用于管理系统数据
通过wampserver工具包安装mysql应用，并通过wampserver启动mysql和apache服务器
被测系统相关的设置
将被测系统的 war 包放置到 tomcat 指定的路径中
将数据库对应的 sql 文件导入到数据库中，并且修改 mysql 数据默认的密码
启动服务器，访问被测系统。地址是： http://localhost:8080/mms/login.html
环境变量
环境变量实际上是一种系统的设置，通过这些设置我们可以告诉电脑我们要运行的目标文件在什么位置
缺陷报告
缺陷的定义
软件没有实现产品的说明书所描述的功能
软件实现了产品说明书描述不应有的功能
软件执行了产品说明书没讲的操作
软件没有实现产品说明书没讲但应该实现的功能
从软件测试员的角度来看，软件难以理解、不易使用、运行缓慢，或者最终用户认为不对
缺陷管理
掌握软件缺陷的生命周期
掌握高质量缺陷报告的填写方法
一个完整的测试报告
缺陷编号
预置条件
缺陷标题
测试步骤
严重程度
优先级
重现率
缺陷状态
掌握软件缺陷的相关属性
缺陷严重程度
严重性
项名思义就是软件缺陷对软件质量的破场程度，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响
致命
例如，软件的意外退出甚至操作系统崩溃，造成数据丢失
严重
例如，由于单功能失效导致多个相关功能均失效
一般
例如，软件的单个功能失效
提示
软件界面的细微缺陷，例如，某个控件没有对齐，某个标点符号丢失等
缺陷状态分类
了解软件缺陷管理的常用工具
了解缺陷冲突中一些常见的问题
如何处理不能重现的缺陷？ 一定要提交到缺陷管理库！
1. 一定要详细描述遇到缺陷的过程和相关环境配置。如果有日志的话，一定要附上相关的操作日志或者系统运行日志。
2. 对于不可重现的缺陷，一定要尽量描述清楚复现率是多少。
3. 对于不可重现的缺陷，当开发人员将缺陷设置为fixed之后，在验证时，不能只在一个版本 上去验证缺陷是否修复，必须至少在3个以上的版本上验证后都没有重现过，才能将缺陷关闭。
执行测试的全流程
回归测试的目的：1. 检查缺陷是否真的被修复了。 2. 程序员在修复缺陷的过程中有没有引入新的缺陷。
回归测试和验收测试
回归测试
定义
修改代码后，重新进行测试
目的
检查缺陷是否真的被修复
程序员在修复缺陷中是否引入新的缺陷
流程
1、在测试策略制定阶段，制定回归测试策略
2、确定需要回归测试的版本 Version，哪个版本上bug被修改了就在哪个版本上回归
3、回归测试版本发布，按照回归测试策略执行回归测试
4、回归测试通过，关闭缺陷报告单
5、回归测试不通过，缺陷报告单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试
策略
完全回归
重新执行所有在前期测试阶段建立的测试用例，来确认问题修改的正确性和修改的扩散局部影响性
选择性回归
即有选择地重新执行部分在前期测试阶段建立的测试用例，来测试被修改的程序
方法
覆盖修改
针对被修改的部分，选取或重新构造测试用例验证没有错误再次发生的用例选择方法
周边影响
包含覆盖修改法确定的用例，还要分析修改的扩散影响，验证是否有其他部分被影响
指标达成
验收测试
定义
在通过了内部系统测试之后，就可以开始验收测试
验收测试是以用户为主的测试，验收组应该由项目组成员、用户代表等组成
验收测试原则上在用户所在地进行，但如经用户同意也可以在公司内模拟用户环境进行
验收测试根据合同、《需求规格说明书》或《验收测试计划》对成品进行验收测试
对于产品型的项目，验收测试一般又分为α测试（内测：在开发环境下进行）和β测试（公测：实际使用环境下测试）两种
生命周期测试方法对比
编写测试报告（每个公司都有模板）
目的
概述
被测对象
测试特性
测试结论
时间、地点、人员
环境
测试组网图
硬件环境
软件环境
总结评价
相关数据统计
软件测试
概念
软件测试是使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
内容
MCP
Minimal Concept Principle（最小概念原则）
软件生命周期
计划
需求分析
设计
编码
测试
运行与维护
常见测试模型
传统瀑布模型
V模型
W模型
敏捷开发模型
软件质量模型
测试方法
黑盒测试
白盒测试
灰盒测试
集成测试
确认测试
系统测试
回归测试
验收测试
项目相关的文档
开发阶段主要文档
需求规格说明书
概要设计
详细设计
测试阶段主要文档
测试计划和方案
测试用例
缺陷报告
测试报告
方法
测试流程
分析
计划：测试计划和方案文档编写
设计：测试用例设计
实现：编写测试用例、测试脚本等
执行：搭建测试环境、执行测试脚本、缺陷报告
执行测试的全流程
回归测试的目的：1. 检查缺陷是否真的被修复了。 2. 程序员在修复缺陷的过程中有没有引入新的缺陷。
回归测试和验收测试
回归测试
验收测试
生命周期测试方法对比
编写测试报告
软件生命周期
计划
确定开发目标：开发一款小软件
完成项目可行性研究：能不能做，做出来是否有意义
对项目进度进行预估和安排：人，时间预算
制定实施计划
需求分析
分析整理项目需求项：需要开发的功能，详细的特性
根据整理出的需求项，编制需求规格说明书（SRS：Software Requirement Specification）
制作产品原型
设计
完成项目概要设计
完成详细设计
编码
根据概要设计说明书以及详细设计说明书，完成代码编写
测试
单元测试：程序最小单元（函数或一个类的代码）
集成：模块与模块之间接口进行测试
系统：对完成编译的系统整体进行测试的过程
验收：与客户一起完成测试
运行与维护
产品部署
运行维护
功能升级
性能提升
常见测试模型
传统瀑布模型
缺点：测试后置，开发完成后，修改成本巨大
V模型
特点：将测试过程细化，分为了单元测试、集成测试、系统测试和验收测试四个不同的阶段
缺点:测试后置，没有解决风险问题
W模型
优点
①测试的活动和开发同时进行
②测试对象不仅仅是程序，还包括需求和设计
③尽早发现软件缺陷可降低开发成本
缺点
无法支持灵活的版本迭代
敏捷开发模型
特点
敏捷开发与测试模型主要是为了适应现代互联网公司“短平快”的开发节奏而设计的一种开发和测试模型
内容
①迭代：每次迭代叫做一个sprint，每个sprint里面选出来要实现的需求会安排到sprint backlog里面，每个sprint一般是以一个月作为周期
② Product Owner：相当于是产品经理。整理出整个项目的所有需求，并且按照需求的优先级来将需求排列到Produce Backlog
③ Daily Meeting：每日会议，一般是站会形式。每个人发言一般不会超过1分钟，主要内容包括三点：昨天完成的工作、今天准备开展的工作、面临的风险和问题
④ sprint burndown：迭代燃尽图，记录剩余的工作量
⑤ sprint review meeting：迭代回顾会议，主要是去回顾在本轮迭代中存在的问题有哪些、如何改进等
⑥ scrum master：相当于组长，由他来统一管理组员
软件质量模型
定义
软件质量模型提供了从不同维度考量产品质量属性的依据
内容
功能性、可靠性、易用性、性能效率、兼容性、安全性、维护性、可移植性
可移植性和兼容性的区别：
可移植性是属于产品的内部质量，更关注代码在不同的平台上是否可以正确的安装和配置。
兼容性是属于产品的外部质量，更关注的是最终用户能感知到的不同的浏览器、不同分辨率、不同设备之间的正确的使用及显示。
测试方法
黑盒测试
指在不知道被测软件代码结构的基础上，根据产品需求规格、站在最终用户的角度来对软件的输入和输出进行测试的过程叫黑盒测试
白盒测试
指基于被测软件的代码和结构，对被测软件的代码和结构本身进行测试的过程叫白盒测试
灰盒测试
介于白盒和黑盒之间，一般来说灰盒是针对接口来进行测试，比如只知道函数的函数名、参数以及返回值，并不知道函数内部的实现结构
集成测试
单元经过测试，底层软件缺陷被找出并修复之后，就集成在一起，对模块的组合进行集成测试，较多涉及接口测试
确认测试
也叫冒烟测试，确认基本功能是否实现，一般不作为正式的测试环节
系统测试
系统所有功能的测试，模拟所有软件用户的操作
回归测试
对软件新版本测试时重复执行之前的测试用例
目的
①验证之前缺陷已修复
②确认修复缺陷没有引发新缺陷
验收测试
供求双方以及第三方的测试，依据运行主题的不同可分为ɑ测试（内侧）、β测试（公测）、γ测试
测试流程
分析
需求评审（需求评审检查表）
需求从哪里来，如果没有需求怎么办？
需求评审怎么评？
测试需求分析
为啥要做测试需求分析？
测试需求分析流程
得到测试点
计划：测试计划和方案文档编写
测试设计的概念
用例编写
测试编号：TC TestCase
测试标题：用一句话来表述该条用例是测试哪个测试点的。
优先级：高中低。作用是在项目时间不够或者人员不充足的时候，我们可以优先测试重点的测试用例
预置条件：在执行该条用例时，系统必须预先达到的一个状态或者条件。可选，有就写，没有就不写
测试步骤：详细描述在测试这条用例时，需要进行哪些操作。
预期结果：来自于需求，要求我们达到的一个结果。
实际结果：实际操作系统之后得到的结果。
测试结果：pass/fail/NA pass 预期结果和实际结果相同。 fail 预期结果和实际结果不相同。N/A 指当前用例不适用或无法操作
设计：测试用例设计
测试用例设计方法
实现：编写测试用例、测试脚本等
测试点的提取及需求跟踪矩阵
执行：搭建测试环境、执行测试脚本、缺陷报告
搭建测试环境
缺陷报告
测试用例设计方法
等价类法
输入域：所有用户可以输入内容的区域
等价类设计步骤
编写等价类表，为每个输入划分等价类，得到等价类表，为每个等价类规定一个唯一编号
设计一个测试用例，使其尽可能多的覆盖所有尚未覆盖的有效等价类。重复这一步骤，使得有效等价类均被被测试用例所覆盖
设计一个测试用例，使其只覆盖一个无效等价类。重复这一步骤使得所有无效等价类均被覆盖
等价类划分原则
如果输入条件规定了取值范围或值的个数，则可以确定一个有效等价类和两个无效等价类
要求输入年龄在18-25 岁之间，则 18-25 就是一个有效等价类，小于 18 和大于 25 就是两个无效等价类
要求一个函数有3 个参数，则 3 个参数就是一个有效等价类，大于 3 个和小于 3 个都是无效等价类
输入条件规定了输入值的集合，或是规定了必须如何的条件，则可以确定一个有效等价类和一个无效等价类
比如要求输入学历值，学历包含大专、本科、硕士、博士、博士后，那么学历中的这些值就是一个有效等价类，凡是不属于这个学历集合中的值就是一个无效等价类
在输入条件是一个布尔值的情况下，可确定一个有效等价类和一个无效等价类
比如要求输入性别为女，那么女就是一个有效等价类，男就是无效等价类。
如果我们确知，已经划分的等价类中各个元素在程序中的处理方式不同，则应该将此等价类进一步划分
在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（遵守规则）和若干个无效等价类（从不同角度违反规则）
要求输入的数据必须是一个正整数，那么正整数就是一个有效等价类，无效等价类可以是0 ，负数、小数
边界值法
定义
1.对程序的输入和输出边界进行测试的一种黑盒用例设计方法，常与等价类设计法结合使用，此时它的用例来自于等价类的边界。
2.边界值分析法的理论基础是假定大多数的错误是发生在各种输入条件的边界上，如果在边界附近的取值不会导致程序出错。那么其他的取值导致程序错误的可能性也很小。
3.边界值使用条件（重点：可度量）
输入条件明确了一个值的取值范围，或是规定了值的取值个数
输入条件明确了一个有序集合
相关概念
上点：边界上的点
离点：离边界最近的点
内点：取值域内的任意一点
每个点一定是一个不同的数字，不可能一个点既是上点又是离点
上点：范围中你看到的那两个点一定是上点
用例步骤
分析输入参数的类型：从测试规格中分析得到输入参数类型
等价类划分（可选）：对于输入等价类划分方法进行等价类的划分确定边界：运用域测试分析方法确定域范围的边界（上点、离点与内点）
形成测试项：选择这些上点、离点与内点或者这些点的组合形成测试项
分析原则
如果输入（输出）条件规定了取值范围，则应该以该范围的边界内的及边界附近的值作为测试用例
如果输入（输出）条件规定了值的个数，则用最大个数、最小个数，比最小个数少1，比最大个数多1的数作为测试用例
如果程序规格说明中提到的输入或输出是一个有序的集合，应该注意选取有序集合的第一个和最后一个元素作为测试用例
如果程序中使用了一个内部数据结构，则应该选择这个内部数据结构的边界上的值作为测试用例
使用场景：把输入条件分成多个不同的子条件，条件与条件之间相对独立，没有制约关系
判定表法
定义（是否）
判定表是分析和表达多种输入条件下系统执行不同动作的工具，它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。
条件桩
列出系统所有输入，列出的输入次序没有影响
条件项
列出针对它左列输入条件的取值，在所有可能情况下的真假值
动作桩
列出系统可能采取的操作，这些操作的排列顺序没有约束
动作项
列出在输入项的各种取值情况下应该采取的动作
设计步骤
确定规则的个数。如这里有3个条件，每个条件有两个取值，故应有2*2*2=8种规则
列出所有的条件桩和动作桩
填入条件项
填入动作桩和动作项
化简，合并相似规则
将每条规则转化为用例
流程分析法
定义
流程分析法（又名场景设计法）是将软件系统的某个流程看成路径，用路径分析的方法来设计测试用例。 根据流程的顺序依次进行组合，使得流程的各个分支都能走到。 这是从白盒测试中路径覆盖分析法中推广到黑盒测试中来的测试分析方法。
概念
基本流：指所有操作都正确的主流程
备选流：指部分操作不正确的流程分支
设计步骤
画出业务流程图
设置功能路径优先级
确定测试路径
选取测试数据
构造测试用例
例子：某嵌入式系统中，将待发送的数据打包为符合CA协议的帧格式后，便可写入发送缓冲区.，并自动发送。
1.进入发送子程序
2. 系统判断是否有空闲发送缓冲区，如果没有则返回，显示发送失败信息
3.如果有空闲缓冲区将数据包写入空闲发送缓冲区
4.系统判断是否写入成功，如果不成功则返回，显示发送失败信息
5. 如果写入成功，则启动发送命令
6.返回发送成功消息
错误猜想法
定义
错误猜测法就是根据经验猜想可能有什么问题并依此设计测试用例
错误测法只能作为测试设计的补充而不能单独用来设计测试用例.否则可能会造成测试的不充分
错误猜测不是瞎猜，不是没有根据和目的的猜测.它需要依据对系统薄弱地方的了解和对开发人员盲点的了解
例子
a = [3,5,8,9,2,4]
重复
[1,1,1,1,1,1,1]
非数字
[1,2,3,a,7,6,5]
列表为空
: [] [67]
顺序问题
[1,2,3,4,5,6] [6,5,4,3,2,1]
业务熟悉程度、编程经验的丰富度
测试用例设计总结
测试用例设计方法很多，我们不仅要知道每种方法怎么用，更需要清楚每种方法使用的场景。
等价类和边界值是任何其他测试设计方法的基石，必须首先考虑使用等价类和边界值进行用例设计。
当输入域与输入域之间有约束关系 ，必须使用 判定表来进行组合。
在考虑了所有测试用例设计方法后，最后还要使用错误猜测法进行补充，以免遗漏。
在测试某一个字段时，应保证其他字段的取值是一个正常值。
测试点的分析和提取
做测试前思考的问题
你知道要测试的系统是干什么的吗？
你了解系统有哪些特点吗？
你知道系统有哪些功能吗？
你知道系统的业务流程是什么吗？
系统在这个版本上，哪些需要测试，哪些不需要测试？
系统对性能、安全性上有没有什么要求？
测试需求分析流程
1、根据产品需求提取系统的测试点
1.首先检查界面元素的显示是否正确
2.测试页面的基本功能。如果页面既有表单也有列表，则优先测试表单功能是否正常
3.针对表单在测试时，需要依据表单里面的每个字段依次进行测试。凡是用户可输入的输入域，都要使用等价类和边界值根据字段的约束来进行考虑
4.如果多个字段之间有关联关系和制约关系，那么在测试完单个字段的等价类和边界值之后，应该继续使用判定表等测试方法进行组合的测试
5.表单测试完后，再测试列表中的功能
6.当单个页面的内容都测试完毕后，再来结合流程分析法（场景法）测试流程相关的内容
7.流程分析测试完后，最后再使用错误猜测法来确保没有遗漏的测试点
8.例子
2.编写需求跟踪矩阵
需求跟踪矩阵指的是根据产品需求和测试点以及测试用例，建立一个三者映射的列表，这个表叫做需求跟踪矩阵
需求跟踪矩阵的作用
建立产品需求、测试需求与测试用例之间的映射关系，方便进行用例需求覆盖率统计
如果需求发生变更，可以根据需求跟踪矩阵快速定位哪些测试用例需要更新
3.根据测试点利用适当的测试用例设计方法设计测试用例
搭建测试环境
服务器环境搭建
JDK的安装
JDK的安装主要是为了提供 JAVA 的运行环境。（TOMCAT服务器是由 java 写的，所以要运行tomcat 必须先设置好 JAVA 运行环境）
JAVA_HOME:你安装 JDK 的路径
CLASS_PATH .;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar
在Path 环境变量中，添加 %JAVA_HOME%\jre\bin 和 %JAVA_HOME%\bin 这两个路径
TOMCAT的安装
tomcat作为主要的web服务器，负责处理客户端发送的所有请求
把tomcat压缩包解压到一个不含中文或特殊字符的路径下
CATALINA_HOME：你解压缩tomcat包的路径
在Path环境变量中，添加%CATALINA_HOME%\bin路径
通过双击bin目录下，startup.bat这个文件来启动tomcat
MYSQL数据库的安装
Mysql数据库主要用于管理系统数据
通过wampserver工具包安装mysql应用，并通过wampserver启动mysql和apache服务器
被测系统相关的设置
将被测系统的 war 包放置到 tomcat 指定的路径中
将数据库对应的 sql 文件导入到数据库中，并且修改 mysql 数据默认的密码
启动服务器，访问被测系统。地址是： http://localhost:8080/mms/login.html
环境变量
环境变量实际上是一种系统的设置，通过这些设置我们可以告诉电脑我们要运行的目标文件在什么位置
缺陷报告
缺陷的定义
软件没有实现产品的说明书所描述的功能
软件实现了产品说明书描述不应有的功能
软件执行了产品说明书没讲的操作
软件没有实现产品说明书没讲但应该实现的功能
从软件测试员的角度来看，软件难以理解、不易使用、运行缓慢，或者最终用户认为不对
缺陷管理
掌握软件缺陷的生命周期
掌握高质量缺陷报告的填写方法
一个完整的测试报告
缺陷编号
预置条件
缺陷标题
测试步骤
严重程度
优先级
重现率
缺陷状态
掌握软件缺陷的相关属性
缺陷严重程度
严重性
项名思义就是软件缺陷对软件质量的破场程度，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响
致命
例如，软件的意外退出甚至操作系统崩溃，造成数据丢失
严重
例如，由于单功能失效导致多个相关功能均失效
一般
例如，软件的单个功能失效
提示
软件界面的细微缺陷，例如，某个控件没有对齐，某个标点符号丢失等
缺陷状态分类
了解软件缺陷管理的常用工具
了解缺陷冲突中一些常见的问题
如何处理不能重现的缺陷？ 一定要提交到缺陷管理库！
1. 一定要详细描述遇到缺陷的过程和相关环境配置。如果有日志的话，一定要附上相关的操作日志或者系统运行日志。
2. 对于不可重现的缺陷，一定要尽量描述清楚复现率是多少。
3. 对于不可重现的缺陷，当开发人员将缺陷设置为fixed之后，在验证时，不能只在一个版本 上去验证缺陷是否修复，必须至少在3个以上的版本上验证后都没有重现过，才能将缺陷关闭。
回归测试和验收测试
回归测试
定义
修改代码后，重新进行测试
目的
检查缺陷是否真的被修复
程序员在修复缺陷中是否引入新的缺陷
流程
1、在测试策略制定阶段，制定回归测试策略
2、确定需要回归测试的版本 Version，哪个版本上bug被修改了就在哪个版本上回归
3、回归测试版本发布，按照回归测试策略执行回归测试
4、回归测试通过，关闭缺陷报告单
5、回归测试不通过，缺陷报告单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试
策略
完全回归
重新执行所有在前期测试阶段建立的测试用例，来确认问题修改的正确性和修改的扩散局部影响性
选择性回归
即有选择地重新执行部分在前期测试阶段建立的测试用例，来测试被修改的程序
方法
覆盖修改
针对被修改的部分，选取或重新构造测试用例验证没有错误再次发生的用例选择方法
周边影响
包含覆盖修改法确定的用例，还要分析修改的扩散影响，验证是否有其他部分被影响
指标达成
验收测试
定义
在通过了内部系统测试之后，就可以开始验收测试
验收测试是以用户为主的测试，验收组应该由项目组成员、用户代表等组成
验收测试原则上在用户所在地进行，但如经用户同意也可以在公司内模拟用户环境进行
验收测试根据合同、《需求规格说明书》或《验收测试计划》对成品进行验收测试
对于产品型的项目，验收测试一般又分为α测试（内测：在开发环境下进行）和β测试（公测：实际使用环境下测试）两种
生命周期测试方法对比