测试需求分析流程
测试需求分析流程
- 根据产品需求提取系统的测试点
- 编写需求跟踪矩阵
- 根据测试点利用适当的测试用例设计方法设计测试用例
测试点提取思路
- 首先检查界面元素的显示是否正确
- 测试页面的基本功能。如果页面既有表单也有列表，则优先测试表单功能是否正常
- 针对表单在测试时，需要依据表单里面的每个字段依次进行测试。凡是用户可输入的输入域，都要使用等价类和边界值根据字段的约束进行考虑
- 如果多个字段之间有关联关系和制约关系，那么在测试完单个字段的等价类和边界值之后，应该继续使用判定表等测试方法进行组合的测试
- 表单测试完后，再测试列表的功能
- 当单个页面的内容都测试完毕后，再结合流程分析法（场景法）测试流程相关的内容
- 流程分析测试完后，最后再使用错误猜测法来确保没有遗漏的测试点
工作时，测试点提取有多少种方式
- 在word或excel记录测试点
- 在思维导图中记录测试点
在实际共工作时如果测试时间较短可能会直接使用测试点代替测试用例
建立需求跟踪矩阵
需求跟踪矩阵指的是根据产品需求和测试点以及测试用例，建立一个三者映射的列表。
需求跟踪矩阵的作用
建立产品需求、测试需求与测试用例之间的映射关系，方便进行用例需求覆盖率统计
如果需求发生变更，可以根据需求跟踪矩阵快速定位哪些测试用例需要更新
缺陷的定义
软件没有实现产品说明书所描述的功能
软件实现了产品说明书描述不应该有的功能
软件执行了产品说明书没讲的操作
软件没有实现产品说明书没讲但是应该实现的功能
从软件测试员的角度来看，软件难以理解、不易使用、运行缓慢，或者最终用户认为不对
掌握高质量缺陷报告的填写方法
一个完整的缺陷报告包含以下内容：
- 缺陷编号
- 用例编号
- 测试模块
- 预置条件
- BUG标题
- 测试步骤
- 预期结果
- 实际结果
- 缺陷状态
- 严重程度
- 优先级
- 重现率
- 测试日期
- 指派
- 环境
- 软件版本
- 截图
- 备注
描述缺陷管理流程或者生命周期，必须写清除两点
- 缺陷管理里面每一步是如何进行流转的，并且负责人是谁
- 缺陷管理每一步对应的缺陷的状态
缺陷的严重程度
严重性：顾名思义就是软件缺陷对软件质量的破坏程度，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响
致命：例如，软件的意外退出甚至操作系统的崩溃，造成数据丢失。
严重：例如，由于单功能失效导致多个相关功能均失效
一般：例如，软件的单个功能失效
提示：软件界面的细微缺陷，例如，某个控件没有对齐
了解软件缺陷管理的常用工具
了解缺陷冲突中一些常见的问题
如何处理不能重现的缺陷？
一定要提交到缺陷管理库！
1.一定要详细描述遇到缺陷的过程和相关环境配置如果有日志一定要附上相关的操作日志或系统运行日志
2.对于不可重现的缺陷要尽量描述清楚复现率是多少
3.对于不可重现的缺陷，当开发人员fixed以后，不能只在一个版本上去验证缺陷是否修复，必须在3个以上的版本上验证后都没有重现过，才能将缺陷关闭。
回归测试
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或者导致其他代码产生错误。回归测试可以发生在任何一个阶段，包括单元测试，集成测试和系统测试
目的：检查缺陷是否真的被修复以及有没有引入新的缺陷
回归测试流程
在测试策略制定阶段，制定回归测试策略
确定需要回归测试的版本Version，哪个版本上BUG被修改了就在哪个版本上回归
回归测试版本发布，按照回归测试策略执行回归测试
回归测试通过，关闭缺陷报告单
回归测试不通过缺陷报告单返回开发人员，开发人员重新修改问题，再提交测试人员回归测试
回归测试的策略
完全回归：
重新执行所有再前期测试阶段建立的测试用例，来确认问题修改的正确性和修改的扩散局部影响性
选择性回归：
即有选择地重新执行部分在前期测试阶段建立的测试用例，来测试被修改的程序
1.覆盖修改法：即针对被修改的部分，选取或重新构造测试用例验证没有错误再次发生的用例选择方法
2.周边覆盖法（最常用的方法）：该方法不但要包含覆盖修改法确定的用例，还需要分析修改的扩散影响，对哪些受到修改间接影响的部分选择测试用例验证它没有受到不良影响。该方法比覆盖修改法更充分一点。
3.指标达成法：这是一种类似于单元测试的方法，在重新执行测试前，先确定一个要达到的指标，如修改部分代码100%的覆盖、与修改有关的接口60%的覆盖等，基于这种要求选择一个最小的测试用例集合。
验收测试
再通过了内部系统测试之后，就可以开始验收测试
验收测试是以用户为主的测试，验收组应该由项目组成员、用户代表等组成
验收测试原则上在用户所在地进行，但如果用户同意也可以在公司内模拟用户环境进行
验收测试根据合同、《需求规格说明书》或《验收测试计划》对成品进行验收测试
对于产品型的项目，验收测试又分为α测试和β测试
α测试（内测）
α测试是由用户在开发环境下进行的测试，也可以是开发机构内部的用户在模拟实际操作环境下进行的测试
α测试时，软件在一个自然设置状态下使用。开发者坐在用户旁，随时记下错误情况和使用中的问题这是在受控的环境下进行的测试
α测试的目的主要是评价软件产品的FLURPS（功能、本地化、可用性、可靠性、性能和技术支持）
β测试（公测）：
β测试是由软件的多个用户在一个或多个用户的实际使用环境（生产环境）下进行的测试
与α测试不同的是，β测试时开发者通常不在测试现场。因而，β测试是在开发者无法控制的环境下进行的软件现场应用
目前在很多互联网公司也称为灰度测试
