测试基础~

1. 软件测试的定义:软件测试是使用人工或自动的手段来运行或测定某个软件系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别.

软件生命周期

单元测试： 对程序的最小单元进行测试的过程，最小单元指函数或者是一个类的代码。
集成测试： 对模块与模块之间调用的接口进行的测试叫集成测试。
系统测试： 对完成编译的系统整体进行测试的过程。
验收测试： 交付给客户或者最终用户时，和客户一起完成的测试。

常见测试模型：
 传统的瀑布模型: 最大的问题是测试工作后置，导致整个项目开发完成之后如果发现比较重要的问题，修改的成本是非常巨大的。

 V模型: V字型模型主要的特点是将测试过程细化，分为了单元测试、集成测试、系统测试和验收测试四个不同的阶段，但是仍然是测试后置，没有解决风险问题。

 W模型: W模型将测试和开发过程分离出来，对整个项目过程中的需求文档、设计文档同样要进行测试，将测试工作前置，大大降低整个项目的质量风险。


 敏捷测试模型: 敏捷模型主要的特点就是为了适应现代互联网公司的“短频快”的开发节奏而设计的一种测试和开发的模型。

迭代：每次迭代叫做一个sprint，每个sprint里面选出来要实现的需求会安排到sprint backlog里面。每个sprint一般是以一个月作为一个周期。

Product Owner：相当于是产品经理。整理出整个项目的所有需求，并且按照需求的优先级来将需求排列到product backlog。

daily meeting：每日会议，一般是站会形式（stand up meeting）。每个人发言一般不会超过1分钟，主要开发内容包括三点：昨天你做了什么，今天准备做什么，有什么风险和问题。

sprint burndown：迭代燃尽图，记录剩余的工作量有多少。

sprint review meeting：迭代回顾会议。主要是去回顾在本轮迭代中存在的问题有哪些，后面如何改进。

软件质量模型：
质量模型是基于ISO25000和国标GB/T25000制定的可用于测量产品质量的模型，该模型提 供了从不同维度考量产品质量属性的依据。
质量模型规定的各种不同质量属性和不同的测试类型之间具有映射关系，所以可以用不同 的测试类型来测试不同的质量属性。

可移植性和兼容性的区别： 可移植性是属于产品的内部质量，更关注代码在不同的平台上是否可以正确的安装和配置。兼容性是属于产品的外部质量，更关注的是最终用户能感知到的不同的浏览器、不同分辨率、不同设备之间的正确的使用及显示。

软件测试分类：

黑盒测试：指在不知道被测软件代码结构的基础上，根据产品需求规格、站在最终用户的角度来对软件的输入和输出进行测试的过程叫黑盒测试。

白盒测试：指基于被测软件的代码和结构，对被测软件的代码和结构本身进行测试的过程叫白盒测试。

灰盒测试：介于白盒和黑盒之间，一般来说灰盒是针对接口来进行测试，比如只知道函数的函数名、参数以及返回值，并不知道函数内部的实现结构。

项目相关文档：

测试流程

分析：需求评审、测试需求分析，得到测试点
计划：测试计划和方案文档编写
设计：测试用例设计
实现：编写测试用例、测试脚本等
执行：搭建测试环境、执行测试脚本、报告缺陷

需求来源：

1. 合同型项目(外包,有甲方乙方)
    用户业务需求产品需求
2. 产品型项目(没有明确的用户)
    协议/标准/规范
    继承性需求
    竞品分析

需求评审检查表

测试需求分析流程

1. 根据产品需求提取系统的测试点
2. 编写需求跟踪矩阵
3. 根据测试点利用适当的测试用例设计方法设计测试用例

测试设计的概念:将测试点转换为测试用例的过程
测试用例的概念:一种用来说明具体如何进行测试操作并验证结果的文档

常用的测试用例设计方法

1. 等价类
输入域：所有用户可以输入内容的区域。
等价类划分原则：
① 如果输入条件规定了取值范围或值的个数，则可以确定一个有效等价类和两个无效等价类
②输入条件规定了输入值的集合，或是规定了必须如何的条件，则可以确定一个有效等价类和一个无效等价类
③在输入条件是一个布尔值的情况下，可确定一个有效等价类和一个无效等价类
④如果我们确知，已经划分的等价类中各个元素在程序中的处理方式不同，则应该将此等价类进一步划分。
⑤在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（遵守规则）和若干个无效等价类（从不同角度违反规则）

等价类设计步骤:
 编写等价类表，为每个输入划分等价类，得到等价类表，为每个等价类规定一个唯一编号
 设计一个测试用例，使其尽可能多的覆盖所有尚未覆盖的有效等价类。重复这一步骤,使得有效等价类均被测试用例所覆盖
 设计一个测试用例，使其只覆盖一个无效等价类。重复这一步骤使得所有无效等价类均被覆盖

2. 边界值
上点：范围中你看到的那两个点一定是上点。 每个点一定是一个不同的数字，不可能一个点既是上点又是离点。
离点:离边界最近的点

边界值法分析原则：
如果输入(输出）条件规定了取值范围，则应该以该范围的边界内的及边界附近的值作为测试用例。
如果输入(输出）条件规定了值的个数，则用最大个数、最小个数，比最小个数少1，比最大个数多1的数作为测试用例。
如果程序规格说明中提到的输入或输出是一个有序的集合，应该注意选取有序集合的第一个和最后一个元素作为测试用例。
如果程序中使用了一个内部数据结构，则应该选择这个内部数据结构的边界上的值作为测试用例。

3. 判定表
条件桩、条件项、动作桩、动作项

4. 流程分析法(场景分析法)
基本流：指所有操作都正确的主流程
备选流：指部分操作不正确的流程分支。


5. 错误猜测法(探索性测试)
•错误猜测法就是根据经验猜想可能有什么问题并依此设计测试用例
•错误猜测法只能作为测试设计的补充而不能单独用来设计测试用例，否则可能会造成测试的不充分
•错误猜测不是瞎猜,不是没有根据和目的的猜测.它需要依据对系统薄弱地方的了解和对开发人员盲点的了解

测试用例设计总结

•测试用例设计方法很多，我们不仅要知道每种方法怎么用，更需要清楚每种方法使用的场景。
•等价类和边界值是任何其他测试设计方法的基石，必须首先考虑使用等价类和边界值进行用例设计。
•当输入域与输入域之间有约束关系，必须使用判定表来进行组合。
•在考虑了所有测试用例设计方法后，最后还要使用错误猜测法进行补充，以免遗漏•在测试某一个字段时，应保证其他字段的取值是一个正常值。
测试需求分析流程

1. 根据产品需求提取系统的测试点
2. 编写需求跟踪矩阵
3. 根据测试点利用适当的测试用例设计方法设计测试用例

测试点提取
思路:

1. 首先检查界面元素的显示是否正确
2. 测试页面的基本功能。如果页面既有表单（既有输入域又有提交按钮的页面，都叫表单页面）也有列表，则优先测试表单功能是否正常。
3. 针对表单在测试时，需要依据表单里面的每个字段依次进行测试。凡是用户可输入的输 入域，都要使用等价类和边界值根据字段的约束来进行考虑。
4. 如果多个字段之间有关联关系和制约关系，那么在测试完单个字段的等价类和边界值之 后，应该继续使用判定表等测试方法进行组合的测试。
5. 表单测试完后，再测试列表中的功能。
6. 当单个页面的内容都测试完毕后，再来结合流程分析法（场景法）测试流程相关的内容。
7. 流程分析测试完后，最后再使用错误猜测法来确保没有遗漏的测试点。

需求跟踪矩阵:需求跟踪矩阵指的是根据产品需求和测试点以及测试用例，建立一个三者映射的列表，这个表叫做需求跟踪矩阵。

作用:
建立产品需求、测试需求与测试用例之间的映射关系，方便进行用例需求覆盖率统计；如果需求发生变更，可以根据需求跟踪矩阵快速定位哪些测试用例需要更新

关于缺陷

•软件没有实现产品的说明书所描述的功能
•软件实现了产品说明书描述不应有的功能
•软件执行了产品说明书没讲的操作
•软件没有实现产品说明书没讲但应该实现的功能
•从软件测试员的角度来看，软件难以理解、不易使用、运行缓慢，或者最终用户认为不对

缺陷管理
1. 掌握软件缺陷的生命周期


2. 掌握高质量缺陷报告的填写方法

一般包含字段:
缺陷编号 预置条件 缺陷标题 测试步骤 严重程度 优先级 重现率 缺陷状态

严重性:顾名思义就是软件缺陷对软件质量的破坏程度，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。

致命:例如，软件的意外退出甚至操作系统崩溃，造成数据丢失
严重:例如，由于单功能失效导致多个相关功能均失效
一般:例如，软件的单个功能失效
提示:软件界面的细微缺陷，例如某个控件没有对齐，某个标点符号丢失等

如何处理不能重现的缺陷？
一定要提交到缺陷管理库！！！！

1. 一定要详细描述遇到缺陷的过程和相关环境配置。如果有日志的话，一定要附上相关的操作日志或者系统运行日志。
2. 对于不可重现的缺陷，一定要尽量描述清楚复现率是多少。
3. 对于不可重现的缺陷，当开发人员将缺陷设置为fixed之后，在验证时，不能只在一个版本上去验证缺陷是否修复，必须至少在3个以上的版本上验证后都没有重现过，才能将缺陷关闭。

回归测试: 回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。回归测试可以发生在任何阶段,包括单元测试、集成测试和系统测试。
目的：

1. 检查缺陷是否真的被修复了。
2. 程序员在修复缺陷的过程中有没有引入新的缺陷。