测试分析分享.pptVIP

测试分析编写分享 分享人： 培训内容与培训目的 内容: 分享编写测试分析的心得 以项目的角度列出测试分析逐级的模板 目的: 测试分析的编写规范化且能够为大家今后的测试分析编写起到一个引航的作用 为什么要写测试分析? 测试分析是了解测试需求的必要产物 测试分析可以保障测试用例的完整;不遗漏 测试分析在TC评审时作为主要展示品 测试分析是其他人了解测试需求的主要途径 测试分析与测试用例 测试用例: 包含需要执行的具体测试步骤以及具体的测试数据 测试分析: 对测试需求、风险的整理，包含划分测试用例的原因以及所有测试用例的概述等 目前测试分析存在的问题 写的过粗或过细 直接拷贝需求文档,没有自己的思路 没有按照规定的测试分析模板来写 如何解决 测试分析的必要性要深入人心 测试分析要求测试人员对需求文档转换成测试需求的思考及整理 整理出一份简洁而有效的测试分析模板;在编写测试分析时按照模板的规范来写. 测试分析前的准备工作 1.了解项目、理解需求文档 2.分析需求文档 3.了解涉及到的数据表以及数据流 4.将自己的分析有条理的写出来 如何分析需求文档 1.了解项目主要实现功能和实现后的结果 2.分析功能入口和角色权限 3.分析业务流程 4.根据自己对业务的熟悉程度分析需求中的遗漏点和不合理 结构划分 如何划分项目的测试分析结构？ 词性：（名词、动词、形容词） --项目 --模块 --子模块 --功能 1.逐级按照文件夹从外到内 2.分析当前功能属于何种类型 3.参考测试模板将测试需求套入 4.及时提炼模板用例 怎样系统的来写测试分析？ 功能测试分析分类： 表单提交型：页面元素的检查 条件组合型：按照条件排列组合 查询型：根据需求自己写SQL语句 脚本测试型：运行脚本后的检查 页面检查型：数据准备 表单提交型: 页面元素检查（不做任何操作时的检查，即刚打开页面时的检查） 单个页面控件检查（包括各种类型输入框的异常情况和正常检查） 页面控件组合的功能矩阵（可选，按需求定） 检查后台情况（提交后的检查） 相关业务模块影响点的检查 条件组合型： 公共部分提炼到最前面 矩阵尽量精炼 业务复杂时尽量分成多个矩阵（个人功力） 查询型： 页面元素检查（不做任何操作时的检查刚打开页面时的检查） 单个页面控件检查（包括各种异常情况和正常检查） 查询条件的功能矩阵 单条件：一句话 组合条件：默认：全条件、无条件 特殊：按需求 查询结果的检查（SQL比对等） 翻页、排序、链接、计算值、按钮控制检查等。 脚本测试型： 考虑数据来源的条件（各种逻辑） 对各条件逐条分析（指where条件） 考虑脚本实现方式与时间范围 脚本运行后，源数据与目标数据的比对。 外部接口功能检查（如邮件、短信等） 日志检查（包括前台与后台） 页面检查型： 进入页面后各元素检查 数据库中数据对应页面元素显示 （正向、反向） 相关功能的检测 QA Time 对于培训内容中的疑问点: 在写测试分析中遇到的难点: … * * 测试分析就是将不同条件下执行某操作后得到不同结果的分析过程；最简单的就是分别列出条件；操作以及结果；之后进行排列组合 * * 模版测试分析，可分为页面元素的校验，如：email框；数据库值的校验；某单独的功能的校验，如：分页。 业务模块测试分析，按名词划分，比如：offer、product、company、商铺、会员等 功能模块测试分析，按动词来划分各个业务功能，相同的动作归结为一个模块。 划分的文件夹可以按照 主谓宾形式：当主角实现的功能不一致的情况下可首先按照主语来划分； 当不同的主角实现的功能一致，结果也一致的情况下可以首先按照宾语，再按照谓语划分。 * 1.页面布局及元素类型相关： 对于页面的检查要明确页面包括哪些元素，是否覆盖了需求，有无冗余，各元素的类型，比如列表、文本框，按钮等等 2.入口相关： 一个页面的访问往往会存在多个入口，每一个入口的前置条件都有可能不同，因此必须列出所有可到达的路径及其条件。 3.用户访问操作权限相关：需要考虑 通过页面元素的直接屏蔽使无权限的用户不可见， 无操作权限用户使用时提示没有权限， 没有权限的用户操作内容显示为不可用状态。 4.具体输入输出项的检查： 对于输入项，应明确有无初始值、默认值设置，若输入项有输入控制，应该确认对应的异常处理机制。 对于输出项（返回项），要明确具体有哪些输出，其次需要明确是返回当前页面的操作，还是新窗口。若为前者，就需要考虑输出后是否影响输出前的操作；若为后者，还需考虑是否能从该页面返回原窗口等 5．数据库层的校验： 业务流和数据流是密不可