本文来自牛鹭学院学员：谭玉琴
测试计划在我们测试人员工作的安排中起一个承上启下的作用。是整个测试流程里面必不可少的一部分。既然这么重要，那必须要赶紧小本本记起来。
一.测试计划的内容
1.测试目的
这里的目的是指测试计划文档要到达的目的
2.制定测试目标要从以下方面着手：
理解系统及早介入理解企业文化和过程测试期望吸取教训工作量大小解决方案的类型技术选择预算时间表分阶段的解决方案3.测试项目简介
产品规格产品名称制造商和产品版本号的说明产品信息产品的用户开发该产品的背景技术结构介绍产品的主要功能，可以借助图表的格式表述4.测试参考文档：
测试计划中引用的文档或书籍
5.测试提交文档：
测试用例提供测试用例模板确定测试用例编号规则测试日志提供测试日志模板缺陷报告提供缺陷报告模板（包括包含哪些内容）缺陷跟踪系统还是电子文档确定严重程度和优先级别如何划分测试总结提供缺陷总结模板6.术语定义
定义了开发产品或测试过程中常用术语的含义
7.测试策略
测试策略描述测试小组用于测试整体和每个阶段的方法。
确定测试策略要从模块，功能，整体，系统，版本，压力，性能，配置和安装等各个方面来考虑。
8.测试阶段进入、退出标准
进入标准：允许系统进入一个特定的测试阶段时所必须具备的条件
退出标准：规定测试何时结束的条件
9.确定测试内容
功能的测试理论上测试要覆盖所有的功能项设计的测试对一些用户界面，菜单的结构还有窗体的设计是否合理等的测试整体考虑：要考虑到数据从软件中的一个模块流到另一个模块的过程的正确性确定功能项优先级、风险、复杂度、客户需求10.资源
人力资源系统资源
11.测试进度
安排测试进度的重要性计划测试进度和人员安排要考虑记录当前项目每项任务实际花费的人员和时间考虑测试组织的测试成熟度测试需求范围测试工程师的技术水平使用测试工具的熟练程度商业知识测试程序的范围测试工作的启动软件计划升级的版本个数高风险的应用程序里程碑时间的设置12.测试人员的任务分配
13.风险和问题
市场的压力测试时间不够，主要是功能冻结后的系统测试的时间可能不够测试资源是否能及时到位（设备和人员）测试人员的培训开发进度的变化需求或设计的变更测试人员的基础培训开发组的版本控制测试计划的内容小结、测试目的、测试项目简介、测试参考文档、测试提交文档、术语和定义、测试策略、确定测试内容、资源、测试进度测试人员的任务分配风险和问题
二、测试用例
1、用例编号
用例编号就是测试用例文档中一个代号，需全局唯一，我们可以通过代号快速找到测试用例。
用例编号的书写，建议是项目名_模块名_，我们可以通过编号快速知道一个项目有多少用例，项目中一个模块有多少用例。
2、用例标题
目的:概述测试用例的主要内容，明确用例意图
在做用例评审时，通过浏览一个模块的用例标题，能快速判断有没有遗漏功能；通过浏览一个功能用例标题，能快速判断出有没有遗漏正常或异常。
一个测试用例的好坏，一半体现在测试用例标题上。
一个好用例的标题，书写方式有三种：
① 一句完整的话（不超过30个汉字）
② 功能简报形式
例：电影详情页-返回
例：栏目-发布
例：电影-添加
③ 按条件/状态
例：发起转码-无源媒体文件
例：发起转码-有源媒体文件
例：鉴权-已订购产品已过期
例：鉴权-已订购产品未过期
例：鉴权-未订购产品
3、前置条件
前置条件-测试用例能执行的前提条件。可以是到达某一状态，也可以是一些配置。
书写要求：一个简洁的结果。
列：用户已成功登陆、自动审核的开关已关。不需要写是怎么登陆的/如何将开关关掉的。
4、测试步骤
测试步骤是指如何执行用例，先做什么后做什么，是有顺序的概念在的。
步骤和用例的目标需要是一致的，任意一个偏离目标整个case就是无意义的。
书写要求：可执行的操作，功能用例步骤不大于7，流程用例步骤随业务而定-这里不做限制。
例：
(1)采集电影[check1]
(2)预处理电影[check2]
(3)审核电影[check3]
(4)发布电影[check4]
5、预期结果
预期结果是和测试步骤一一对应的，有几个检查点，就需要有几个结果。
预期结果需要是可检查的，可从三个方面进行校验：
界面（结果会直接显示在界面上的）数据库（有些数据只会存于数据库中）磁盘（文件数据需具体到磁盘上看是否存在，数据是否正确）书写要求：和测试步骤中check点一一对应，检查点=1个
6、测试数据
测试数据：测试时使用到的数据。书写要求：可用电影。不用写到实际数据，在测试添加电影功能时，不需要写具体电影、导演、演员、宣传图片。具体的数据-可以在数据准备时做好，如符合规格的图片（海报、图标、剧照），符合码率的媒体文件（正片和预览片）。最后，测试用例整体是有逻辑的-需要有用例设计的魂
编写测试用例的两个途径
1)先有用例设计，从整个产品/项目出发，先确定测试范围、测试目标，再细化范围到具体对象-具体功能，确定设计用例技术和测试方法，再来编写用例。
2)测试执行后-通过Bug反推修改补充用例。
两者相结合才会产出一份漂亮且有效的测试用例，理论-实践-理论过程。
附上编写测试用例常见问题
用例标题意图不明确用例中引用其他用例用例中包含过多的细节用例中出现笼统的词反复、多次：确定反复的具体次数、确定一个反复的范围长时间：确定长时间的具体时间、确定一个长时间的范围
模板是套的，仅供参考。具体情况还是要根据整个测试的具体环境来编写。有些东西写的越多bug越多，不要不懂装懂。写一长串，却讲解不出来。这时又不得不提一下我们在工作中要具备的沟通能力了。
说到测试用例的编写，其实简单点来说，就是某个功能实现的流程。类似于使用说明书，最后需要验证跟着步骤流程，是否达到预期效果，功能是否实现，是bug的一个寻找记录阶段。
可以用禅道，进行编写，管理测试用例。
选择测试用例执行，如果执行结果与预期结果不相符，可提交bug。
————————————————
转载请注明：http://www.0431gb208.com/sjszlfa/6417.html
