测试基础培训..pptVIP

* * * * * * * * * * * * * 缺陷等级定义 致命性错误： 导致系统无法运行，崩溃，异常退出，死机，服务停止，数据库混乱等，包括但不限于以下情况: 由于程序所引起的死机，非法退出 死循环 数据库发生死锁 数据库设计未达到第三范式的要求或需求规格说明的格式水平 功能错误 与数据库连错错误 数据通讯错误 严重性错误： 使系统不稳定，破坏数据，功能未实现，功能出现缺陷导致其它功能及模块出现缺陷，包括但不限于以下情况： 因错误操作迫使程序中断 程序接口错误 数据库的表，业务规则，缺省值未加完整性约束条件 导致其它功能及模块出现缺陷 主要功能未实现 程序问题导致系统不稳定 错误导致后续流程或操作无法继续 显示内容错误且容易误导用户精心错误处理 告警性错误： 功能已实现，存在不影响主要功能使用的小缺陷，包括但不限于： 操作界面错误（包括数据窗口内列名定义，含义是否一致） 打印内容，格式错误 简单的输入限制未放在前台进行控制 删除操作未给出提示 数据库表中有过多的空字段 * 建议性错误： 功能使用不方便，不合理，界面不友好或风格不统一情况: 界面不规范 辅助说明描述不清楚 输入输出不规范 长操作未给用户提示 提示窗口文字未采用行业术语 可输入区域和只读区域没有明显的区分标志 缺陷跟踪过程（一） * 缺陷跟踪用户组和角色的对应关系： 提交组：所有用户 开发组：开发人员 审核组：测试协调人、系统负责人 测试组：测试人员 缺陷跟踪过程（二） * SIT测试缺陷跟踪过程如下图所示： 缺陷跟踪过程（三） * 提交组成员提交所发现的缺陷，缺陷状态为“等待审核” 审核组成员分析审核缺陷，根据缺陷情况做不同操作： 确实是缺陷的，做缺陷分配操作，分配主修复人、分配时间、规模、紧急程度等内容，缺陷状态变为“等待开发” 因缺陷提供信息不足等原因导致无法确定的，做延迟处理操作，输入延迟时间和延迟理由，缺陷状态变为“延迟开发” 认为不是缺陷的，输入驳回时间和驳回理由，做驳回问题操作，缺陷状态变为“驳回” 缺陷跟踪过程（三） * 对于“驳回”状态缺陷，提交组可： 仍然认为是缺陷的，补充信息后做重新提交，返回“等待审核“状态 确认不是缺陷的，做问题存档，到“缺陷存档”状态 对于“延迟开发”状态缺陷，提交组补充信息后做立即开发操作，返回“等待审核”状态 对于“等待开发”状态缺陷，开发组可： 不认可分配内容的，输入驳回时间和驳回理由，做拒绝受理操作，缺陷状态变为“等待审核” 认可分配的，修复缺陷完成后，输入开发时间和修复方案，做开发完毕操作，进入“等待检测”状态 缺陷跟踪过程（三） * 测试组对“等待检测”的缺陷进行回归测试： 测试通过的，填写测试范围、测试时间、验证版本、测试结果、测试人、测试描述等内容，做测试通过操作，状态变为“关闭” 测试不通过的，填写测试范围、测试时间、验证版本、测试结果、测试人、测试描述等内容，做测试未通过操作，状态变为“等待审核” * SIT测试总结阶段 测试实践 * 需求变更与沟通 * 养成良好的习惯，在QC里不随意删除需求和测试用例。设置需求变更文件夹，记录跟业务开发确认的需求跟踪记录。 如果需求分析或用例编写过程中遇到问题，及时跟开发、业务沟通，如问题解决不了，交给PM处理 需求变更与沟通 * 尽量有书面沟通尽量，比如邮件确认记录 测试人员明确测试职责（是测试软件如何而不是根据自己分析该如何去实现） * 评审方式 测试内部交叉评审 与开发团队共同评审 业务、开发、测试三方都参与的评审 缺陷处理 * 如果缺陷积压应及时找开发项目经理沟通解决 对存在疑问的bug及时展开bug讨论大会，促使开发业务达成一致，测试人员根据处理结果验证缺陷 测试过程发现bug占比 * 实际项目中举例分析 开发人员应注意问题 * 修改一个缺陷可能会导致其他模块出现问题，所以，修改一个缺陷应该考虑是不是会引起其他缺陷的产生 * 谢 谢 SRS：《需求说明书》 * 软件测试按测试阶段划分 单元测试-集成测试-系统测试-验收（用户）测试 Sit（系统集成测试）-Uat（用户测试）-回归测试（可能出现在任何测试阶段） * 单元测试属白盒测试 单元测试就是对软件基本组成单元进行测试，单元测试的对象是函数或一个类的方法 单元测试的目的是发现各模块内部可能存在的各种错误， 其关注的重点是：单元接口，局部数据结构，边界条件，独立路径，出错处理 单元测试的过程：单元测试计划阶段、单元测试设计阶段、单元测试实现阶段、单元测试执行阶段 * 集成测