如何设计CaseFramework介绍.docx

如何设计测试用例 文档信息 文档名称：如何设计测试用例 文档版本：V1.0 提交部门：测试部门 适用人群：Dolphin INT-Shell Test team 修订记录 版本日期修订人内容概述V1.02015/1/28Qing Chen文档创建目录  TOC \o 1-3 \h \z \u  HYPERLINK \l _Toc413657456 文档信息  PAGEREF _Toc413657456 \h 1  HYPERLINK \l _Toc413657457 修订记录  PAGEREF _Toc413657457 \h 1  HYPERLINK \l _Toc413657458 文档明细  PAGEREF _Toc413657458 \h 1  HYPERLINK \l _Toc413657459 背景  PAGEREF _Toc413657459 \h 2  HYPERLINK \l _Toc413657460 1. 如何设计Case Framework  PAGEREF _Toc413657460 \h 2  HYPERLINK \l _Toc413657461 1.2为什么要设计Case Framework  PAGEREF _Toc413657461 \h 2  HYPERLINK \l _Toc413657462 1.4如何设计Case Framework  PAGEREF _Toc413657462 \h 2  HYPERLINK \l _Toc413657463 2.如何设计Detailed Test Case（TBD）  PAGEREF _Toc413657463 \h 6  文档明细 背景 目前用例重构和新需求都需要设计测试用例，该活动由设计Case Framework和设计Detailed Test Case组成，在设计这两块时，大家出现了各种不同的问题也提出了很多疑惑，本文从这两方面讲解设计测试用例的基本方法和一些常见的错误，以作为设计测试用例时的基本指导，并规避一些常见错误。 1. 如何设计Case Framework（用例框架） 1.2为什么要设计Case Framework Case Framework是通读并理解Spec后，设计详细测试用例前，设计的一套测试用例框架，用来引导后续设计详细测试用例，它有以下作用： 便于理清用例逻辑设计思路，避免设计详细测试用例时思路不清晰导致重复更改 便于设计用例之初完全覆盖Spec（规格）上的需求点 便于执行者或新人快速了解模块逻辑结构 1.4如何设计Case Framework 1.4.1设计Case Framework步骤： 通读并理解Spec上所有需求点 若Spec上无需求点标注或标注缺失、错误，及时告知相应PM（产??经理）进行修改 若对Spec上内容有异议或无法理解，需向PM/Dev确认，切忌将模糊不清的内容 写入用例 划分测试该功能的测试类型，基本类型如下： BFT(Basic Functional Test) 基本功能测试 IAT(Interaction Test) 交互测试 BOT(Boundary Test) 边界值测试 ROT(Robustness Test) 稳定性测试 OTA(Over the Air) 升级测试 User Story： 场景测试 ET(Exploratory Test) 拓展测试 每种类型详细设计说明见 HYPERLINK \l _2.如何设计Detailed_Test_Case（TBD） 《2.如何设计Detailed Test Case》 根据对Feature（特征）的理解，组织用例的逻辑，编写测试用例框架： 以Dolphin Browser为例，一般按用户操作习惯顺序编写： 入口→功能的UI→功能正面验证→功能负面验证→…→升级→User Story→ET Case Framework设计完毕后，检查： 是否覆盖Spec上所有需求点 逻辑是否有条理、清晰 1.4.1实例： 模块：《Speed Dial》 Test TypeMain ComponentPriority Check PointTraceability BFT预置数据(运营配置，无需设计case)0根据地区语言信息和版本信息配置预制的speed dial2.1-1　1针对特定的speed dial设置无Add to home screen或Remove操作2.1-2　1设置speed di