如何设计CaseFramework分析.docx

如何设计测试用例文档信息文档名称：如何设计测试用例文档版本：V1.0提交部门：测试部门适用人群：Dolphin INT-Shell Test team修订记录版本日期修订人内容概述V1.02015/1/28Qing Chen文档创建文档明细背景目前用例重构和新需求都需要设计测试用例，该活动由设计Case Framework和设计Detailed Test Case组成，在设计这两块时，大家出现了各种不同的问题也提出了很多疑惑，本文从这两方面讲解设计测试用例的基本方法和一些常见的错误，以作为设计测试用例时的基本指导，并规避一些常见错误。1.如何设计Case Framework（用例框架）1.2为什么要设计Case FrameworkCase Framework是通读并理解Spec后，设计详细测试用例前，设计的一套测试用例框架，用来引导后续设计详细测试用例，它有以下作用：便于理清用例逻辑设计思路，避免设计详细测试用例时思路不清晰导致重复更改便于设计用例之初完全覆盖Spec（规格）上的需求点便于执行者或新人快速了解模块逻辑结构1.4如何设计Case Framework1.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)拓展测试每种类型详细设计说明见《2.如何设计Detailed Test Case》根据对Feature（特征）的理解，组织用例的逻辑，编写测试用例框架：以Dolphin Browser为例，一般按用户操作习惯顺序编写：入口→功能的UI→功能正面验证→功能负面验证→…→升级→User Story→ETCase 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 dial右上角出现更新提醒2.1-3　首次启动2Hot Apps出现小红点缺失　Dolphin文件夹3内容，排序缺失　3Lab，Features，Blog，FAQ，Feedback，Updates缺失　添加speed dial0首页点击+2.2-1　　0Menu - Add speed dial(默认灰显)2.2-2　　2Gesture:Add to speed dial手势2.2-3　　1Add speed dial编辑框2.2-4　　0Name input box，添加后名字显示的长度2.2-5　　0Address input box2.2-6　　1Cancel button2.2-7　　0Add button2.2-8　　2Name和Address为空2.2-10　　2Gesture:添加重复speed dial2.2-9　　2添加相同名称或网址的speed dial缺失　　2添加相同名称和网址的speed dial2.2-9　长按speed dial0长按UI:横竖屏缺失　编辑speed dial1长按选项:Add to home screen2.3-1，2.3-2　　3重复添加桌面快捷方式缺失　　0长按选项:Remove2.3-3　　3长按Feedback:无法添加到主页缺失　　3无法删除speed dial:Hot Apps2.3-3　　0移动speed dial位置2.3-10　　0点击speed dial缺失　文件夹操作1创建文件夹2.3-4，2.3-5，2.3-6　　1文件夹预览缺失　　1编辑文件夹名称(默认值)2.3-7　　2修改为已存在文件夹名缺失　　1文件夹展开、收拢:横竖屏缺失　　1改变文件夹位置2.3-8　　1移动文件夹内speed dial:内部、移进、移出2.3-9　　2文件夹中speed dial长按操作:Add to home screen，remove缺失　　0清除文