测试方法介绍.pptVIP

测试方法介绍 目录 测试过程 什么是Bug？ 不符合产品说明书 实现了说明书未提及的功能---多做 未实现说明书要求的功能—少做 实现了说明书指明不该有的错误---错做 未实现说明书虽未明确提及但应该实现的目标---可用性 软件难以理解、不易使用、运行速度慢---易用性 Bug的分析 Bug的分析，尤其是外网bug分析十分重要 需求缺陷？ 需求变更？ 架构设计缺陷？ Bug修改引发？ 测试设计不全？ 历史bug？ 时间不够？ 测试工作的目标 目标 尽可能早而全面的找出Bug，并确保其得以正确的处理。 用途 找出Bug 避免Bug 评估质量 提高研发效率 …… 测试工作的原则 原则1 － 全程测试原则(测试活动应该贯穿整个软件生命周期) 原则2 － 不完全原则(穷尽测试是不可能的) 原则3 － 缺陷聚集原则(80-20理论) 原则4 － 免疫性原则 (杀虫剂悖论，测试用例需要经常的评审和修改) 原则5 － 不存在缺陷的谬论(测试的目的是为了证明软件有错) 测试需要明智的选择 测试的价值---bug 多？ 问题1：如何让质量和进度达到双赢？ 问题2：时间紧迫，要写测试文档么？ 问题3：自动化测试 or 手工测试？ 不要为了自动化而自动化！ 自动化决定因素： 项目的周期---长、短 需求变更的频率---变化快、功能稳定 脚本维护成本---高、低 投入产出率 问题4：漏测只是TE的原因么？ 漏测要具体分析，以下列举常见的top问题： 产品设计的缺陷---需求评审、需求质量改进 开发质量不高，bug经常反弹---编码规范、提测规范、千行代码缺陷率 测试设计缺陷---测试用例的深度、广度不够、同行评审、用例缺陷率 测试覆盖面小---不同测试方法的全面覆盖 测试效率低下---自动化测试、测试工具、接口测试等 发布策略不佳---灰度发布、外网监控、运维团队 版本节奏、项目进度不合理---迭代规划、人力配比、项目管理、团队建设 流程拖沓、团队配合度低---QA流程、规范、模版、报告的改进 PS：质量不是靠测试单方面保证，而是需要研发流程中各个角色一起承担， 测试人员也不能仅仅关注测试质量，还要去思考整个研发过程中的问题， 推动各个角色去改进。 测试用例设计方法 边界值分析法 等价类划分法 判定表方法 逻辑图方法 错误推测法 探索性测试 其他方法 测试用例设计原则 测试用例的可读性 测试用例设计原则 测试用例的重用性 测试用例设计原则 问题：测试用例的粒度如何把握？ 需要考虑以下因素： 产品的稳定性（新产品？需求变更的频率？） 需求文档的精确程度和详细程度（没有需求文档如何测试？） 产品形态的不同（CS\BS产品的区别） 团队成员的成熟度（产品素养、开发素养、测试素养） 团队的稳定性（人员流动） 自动化的需要（测试效率提升） 结论：粗、细没有定律，关键是选择适合自己团队的。 边界值分析法 正常值： 边界值：At, below, above 次边界：特殊字符、日期的特殊值（闰年） 默认值、空白、空值、零和Null 非法数据 练习-边界值 等价类划分 把软件具有相似输入、相似输出、相似操作的分在一个组 最常用的划分方法： -有效(valid) 等价类 -无效(invalid)等价类 划分等价类的标准： -完备性，划分为互不相交的一组子集，而子集的并是整个集合 -互斥性，子集互不相交，保证一种形式的无冗余性 练习-等价类划分 判定表方法 判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。 最常用的使用方法： 1) 确定规则的个数 2) 列出所有的条件桩和动作桩 3) 填入条件项和动作项 4) 简化.合并相似规则（相同动作） 判定表的优、缺点： -优点：它能把复杂的问题按各种可能的情况一一简明易于理解，也可避免遗漏。 -缺点：不能表达重复执行的动作，例如循环结构。 练习-判定表 1)确定规则数 这里有2个条件，每个条件2个取值，规则数=2*2=4 2)列出所有的条件桩和动作桩 3) 填入条件项和动作项 4) 简化.合并相似规则 逻辑图方法 作用：帮助我们理解待测系统的功能逻辑，提高用例覆盖的深度、广度，以便于设计正确的测试用例。 错误推测法 探索性测试 测试用例设计准则 什么是C/S模式 客户端Client/服务器Server结构 一般使用大型数据库系统 表示层或者用户界面使用的, 放在client端 业务逻辑一般分布在Server端和C