高效测试案例设计课件.pptxVIP

关志勇 前言 前半部 测试用例设计5板斧 第一板斧需求细分 第二板斧产品实现逻辑 第三板斧产品应用场景 第四板斧测试角度 第五板斧产品实现技术 设计手段 测试列表设计思想及应用 技术理解文档模板思想及应用 后半部 完善补充设计测试案例 ;本次培训的目的：介绍设计测试案例的思路 本次培训介绍的设计测试案例的思路基于黑盒测试方法实现 不管黑猫白猫，逮到耗子是好猫，本次培训介绍的设计测试案例思路不是否定现有黑盒测试方法，其中的思路也借鉴了白盒测试的一些方法 本次培训介绍的设计测试案例的思路在网络通信产品、网络安全产品、应用客户端产品、网站产品应用;功能需求逐级细分最终形成功能点 测试人员最初依据需求文档编写测试case，不同的公司功能需求文档描述细程度不一样，功能从层次划分的角度来看存在大小之分，可以采用树形分层的设计思路，层层剥离，最终形成不能往下细分、没有歧义的功能点 ;高效测试案例设计_第一板斧_举例 ;功能点的定义：影响功能点的预期结果只有一个因素/条件 ，如果存在多个因素/条件并会导致不同的结果 ，这个功能还不是功能点，需要继续往下细分 功能点分的很细有必要吗？从测试覆盖度来说是越细越好，但是很多情况下会根据项目的时间资源、人力资源来综合分析，具体问题具体分析;知己知彼方能百战不殆！ 需求文档的内容是黑盒层面的内容，当我们完全站在黑盒外面设计测试案例，相对产品而然测试案例的覆盖度和精准度不好评估，如果我们能掌握产品黑盒内部的逻辑结构，再用黑盒的测试手法执行case去覆盖产品的功能，相对于完全依据需求来设计的case来说多了一层保证 ;在介绍流程图分析法之前先抛出几个问题： 开发需要为测试提供什么支持帮助，概要设计文档、详细设计文档是否应该提供给测试？ 这些文档对测试工作有作用吗？ 测试工程师从这些文档吸取什么？ ;高效测试案例设计_第二板斧逻辑流程图的模型举例;高效测试案例设计_第二板斧;高效测试案例设计_第二板斧;使用自然语言把概要设计、详细设计当中的内容用业务流/功能描述的形式展现， 表现形式不局限刚才列举的几种模型 概要设计和详细设计会有很多计算机专业术语，在设计逻辑流程图时需要 把这些计算机术语（如变量名、函数名、类名、对象名）翻译后（转为动作名称、功能名称、业务名、数据流名称等）用自然语言表达出来 ;FAQ：1、看不懂概要设计和详细设计怎么办： 和开发沟通，理解后及时写成逻辑流程图 2、所有的逻辑流程图都需要让相对应的开发人员审核，如果有错误及时修正 3、当功能实现异常复杂，可以根据实际情况把一个复杂的实现逻辑分解成几个流程图如下图： ;续上;FAQ： 存在复杂调用关系的模块间的流程图可以单独使用流程图描述模块之间复杂的调用关系，忽略模块内部的处理流程，按照流程图设计测试case去覆盖模块间的调用关系 逻辑流程图每一链接都必须加上唯一的标号标记（英文、数字等都可以） 逻辑流程图后续需要用文字对整个逻辑流程图进行描述解释，便于理解 ;高效测试案例设计_第二板斧;在设计逻辑流程图时，需要定义所负责模块的重要程度级别和模块内部路径的重要程度级别(比方从出现故障的影响程度大小和使用的频繁程度判断)，当项目时间紧张或者人力资源不足时就可以根据这些情况选取最重要或者最适合的case去测试 逻辑流程图体现着开发人员的设计实现思路，通过逻辑流程图设计case的主要思想是用黑盒的测试方法把开发的设计思路覆盖，保证产品的设计可以在真实的环境当中得到验证;从产品/功能的应用场景去设计case 相对开发人员而言测试人员就是开发人员所开发产品/功能的用户；在公司，测试人员就代表用户，测试人员的思维要贴近用户，要站在用户的立场上去检验产品 应用场景是黑盒测试相对白盒测试的一大优势是真实应用和模拟应用（如桩）的区别;我们的产品会被各种不同的用户使用，不同的用户对我们的产品的影响体现为：不同的配置（产品的具体配置）、不同的操作行为、不同的运行环境（如硬件环境、软件环境、网络环境、负载等）、不同的要求、不同的区域、不同的使用习惯等 ;从测试角度的方向设计测试case 前面三板斧覆盖了需求、开发设计和客户应用场景，到现在为止设计测试case的思路基本都围绕着产品，这时候需要把设计思路做一个转变，把思路从产品身上暂时抽出来，从测试的角度去设计case;什么是测试角度？ 测试角度是否等同于测试类型？ 测试角度为什么说测试角度是集体智慧的结晶？ ;用举例来说明测试角度： 测试类型属于测试角度是测试角度的子集，测试类型是测试同行经验的结晶。 列举一些测试类型：界面测试、边界测试、安装/卸载测试、易用性测试