功能点：能够单独完成的某个具体业务流程。 一般在软件测试工作流程中的需求分析阶段，要根据需求说明书或者原型图提取功能点，功能点是和需求点相对应的。

例如：每个软件都有注册登录，注册、登录就是两个功能点。登录模块还可以细化成登录功能，忘记密码功能，记住用户名功能。

1、单个模块的测试用例

测试类型	功能测试	模块名称	XXXXX系统用户登入
用例描述	该用例用来测试在登入界面，用户能否正常登入，如果出错，是否能给出出错信息
前置条件	存在正确的用户名和密码；登入页面正常加载，错误信息提示正确（数据库有用户信息test/12345Test）
编号	测试项	操作步骤	数据	期望结果
1	界面检查	1、界面装载 2、检查界面的标题 3、检查文本框默认的焦点 4、检查tab键的正常使用	1、登入界面的URL：CCCCCCC	1、界面正常装载 2、界面标题显示为“X” 3、焦点在用户名文本框 4、能通过tab控制
2	用户登录	1、输入没有区分大小写的用户民 2、输入没有区分大小写的密码 3、按回车键	1、用户名：Test 2、密码：Testjk 3、N/A	1、N/A 2、N/A 3、区分大小写，显示出错信息“用户名或者密码错误”并清空输入框，不能正常登入
		1、输入正确的用户民 2、输入错误的密码 3、按回车键	1、用户名：test 2、密码：Testjkfg 3、N/A	1、N/A 2、N/A 3、显示出错信息“用户名或者密码错误”并清空输入框，不能正常登入
			1、用户名：test 2、密码：$%#(在密码中输入特殊字符) 3、N/A	1、N/A 2、N/A 3、提示信息用户名或者密码中存在特殊符号，并清空输入框，不能正常登入
		1、输入错误的用户民 2、输入正确的密码 3、按回车键	1、用户名：testjkjkz 2、密码：12345Test 3、N/A	1、N/A 2、N/A 3、区分大小写，显示出错信息“用户名或者密码错误”并清空输入框，不能正常登入
			1、用户民：$%#(在用户名中输入特殊字符) 2、密码：12345Test 3、N/A	1、N/A 2、N/A 3、提示信息用户名或者密码中存在特殊符号，并清空输入框，不能正常登入
		1、输入错误的用户民 2、输入错误的密码 3、按回车键	1、用户民：test2 2、密码：125testT 3、N/A	1、N/A 2、N/A 3、“用户名或者密码错误”
		1、直接单击登录，不输入任何东西	1、N/A	出现请输入用户名、密码的提示框
3	用户重置或取消	1、输入用户民 2、输入密码 3、单击重置或取消	1、用户民：test 2、密码：12345Test 3、N/A	1、N/A 2、N/A 3、清空用户民和密码输入框

2、模块间的测试用例

测试类型	功能测试	模块名称	XXXXX系统搜索功能测试
用例描述	该用例用于测试在用户登录后能否正常搜索到后台已经删除的结果
前置条件	管理员正常删除某用户资料，用户（名：test1，密码：test1aaa）正常登录，有搜索权限
编号	测试项	操作步骤	数据	期望结果
1	以管理员登录后台管理系统	输入正确的用户名和密码	用户名：admin 密码：admin	登录管理系统
2	从资料中删除某员工资料	删除资料	用户A	用户A从数据库中删除
3	用户登录submit	输入正确的用户名和密码	用户名：test1 密码：test1aaa 直接回车登录	正确登录，装入对应的系统页面
4	用户搜索用户A	在搜索框中输入用户A，单击搜索	输入 用户A用户名	提示用户：“没有符合条件的产品”

总结：做 功能测试需要充分理解实际的商业需求和流程，进而定义完备而准确的功能测试场景和测试用例，真正做到黑河测试。功能测试需要具有深度和广度，要熟悉测试相 关的技能，工具和流程，也需要在深度上理解产品、功能测试策略。要知道功能测试的目的就是找到缺陷，想方设法的让软件无法运行，让软件出错。

 ● 测试用例编号
 ◇ 规则：编号具有唯一性、易识别性，由数字和字符组合成的字符串
 ◇ 约定：
 系统测试用例：产品编号-ST-系统测试项名-系统测试子项名-XXX
 集成测试用例：产品编号-IT-集成测试项名-集成测试子项名-XXX
 单元测试用例：产品编号-UT-单元测试项名-单元测试子项名-XXX
 ● 测试项目
 ◇ 规则：当前测试用例所属测试大类、被测需求、被测模块、被测单元等
 ◇ 约定：
 系统测试用例测试项目：软件需求项 如：测试手机在没有SIM卡的情况下，可以拨打紧急电话
 集成测试用例测试项目：集成后的模块名或接口名 如：测试模块A提供的文件接口
 单元测试用例测试项目：被测试的函数名 如：测试函数int ReadFile(char *pszFileName)
 ● 测试标题
 规则：测试用例的概括简单的描述用例的出发点、关注点，原则上不能重复。
 ● 重要级别
 规则
 高：保证系统基本功能、核心业务、重要特性、实际使用频率高的测试用例；
 中：重要程度介于高和低之间的测试用例；
 低：实际使用频率不高、对系统业务功能影响不大的模块或功能的测试用例。
 ● 预置条件
 规则：执行当前测试用例需要的前提条件，是后续步骤的先决条件
 ● 输入
 规则：用例执行过程中需要加工的外部信息，输入、文件、数据库等
 ● 操作步骤
 规则：执行当前测试用例需要经过的操作步骤，保证操作步骤的完整性。
 ● 预期输出
 规则：当前测试用例的预期输出结果，包括返值的、界面的响应结果、输出结果的规则符合度等

测试分析报告
1 引言
1.1编写目的
说明这份测试分析报告的具体编写目的，指出预期的阅读范围。
1.2背景
说明：
a. 被测试软件系统的名称；
b. 该软件的任务提出者、开发者、用户及安装此软件的计算中心，指出测试环境与实际运行环境   之间可能存在的差异以及这些差异对测试结果的影响。
1.3定义
列出本文件中用到的专问术语的定义和外文首字母组词的原词组。
1.4参考资料
列出要用到的参考资料，如：
a． 本项目的经核准的计划任务书或合同、上级机关的批文；
b． 属于本项目的其他已发表的文件；
c． 本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2测试概要
用表格的形式列出每一项测试的标识符及其测试内容，并指明实际进行的测试工作内容与测试计划中预先设计的内容之间的差别，说明作出这种改变的原因。
3测试结果及发现
3.1测试1（标识符）
把本项测试中实际得到的动态输出（包括内部生成数据输出）结果同对于动态输出的要求进行比较，陈述其中的各项发现。
3.2测试2（标识符）
用类似本报告3.1条的方式给出第   2项及其后各项测试内容的测试结果和发现。
4对软件功能的结论
4.1功能1（标识符）
4.1.1能力
简述该项功能，说明为满足此项功能而设计的软件能力以及经过一项或多项测试已证实的能力。
4.1.2限制
说明测试数据值的范围（包括动态数据和静态数据），列出就这项功能而言，测试期间在该软件中查出的缺陷、局限性。
4.2功能2（标识符）
用类似本报告4.l的方式给出第2项及其后各项功能的测试结论。
．．．．．．
5分析摘要
5.1能力
陈述经测试证实了的本软件的能力。如果所进行的测试是为了验证一项或几项特定性能要求的实现，应提供这方面的测试结果与要求之间的比较，并确定测试环境与实际运行环境之间可能存在的差异   对能力的测试所带来的影响。
5.2缺陷和限制
陈述经测试证实的软件缺陷和限制，说明每项缺陷和限制对软件性能的影响，并说明全部测得的性能缺陷的累积影响和总影响。
5.3建议
对每项缺陷提出改进建议，如：
a． 各项修改可采用的修改方法；
b． 各项修改的紧迫程度；
c． 各项修改预计的工作量；
d． 各项修改的负责人。
5.4评价
说明该项软件的开发是否已达到预定目标，能否交付使用。
6测试资源消耗
总结测试工作的资源消耗数据，如工作人员的水平级别数量、机时消耗等。

测试用例是测试设计的一个产出物，它直接体现测试设计的思想，一份漂亮的测试用例不仅仅是设计思路的优秀体现，更是便于流转和执行，具有可读性、传递性。

首先，我们要一份测试用例例模板，模板可以将测试用例的结构形式固定化、标准化，对编写者启引导作用，保证一份测试用例数据完整。

其次，测试用例的目标、可读、简洁是从各个属性所填的内容散发出来的。

1、用例编号

用例编号就是测试用例文档中一个代号，需全局唯一，我们可以通过代号快速找到测试用例。

用例编号的书写，建议是项目名_模块名_001，我们可以通过编号快速知道一个项目有多少用例，项目中一个模块有多少用例。

2、用例标题

目的:概述测试用例的主要内容，明确用例意图

在做用例评审时，通过浏览一个模块的用例标题，能快速判断有没有遗漏功能;通过浏览一个功能用例标题，能快速判断出有没有遗漏正常或异常case。

一个测试用例的好坏，一半体现在测试用例标题上。

一个好用例的标题，书写方式有三种：

一：一句完整的话(不超过30个汉字)

二：功能简报形式

例：电影详情页-返回

例：栏目-发布

例：电影-添加

三：按条件/状态

例：发起转码-无源媒体文件

例：发起转码-有源媒体文件

例：鉴权-已订购产品已过期

例：鉴权-已订购产品未过期

例：鉴权-未订购产品

3、预置条件

预置条件-测试用例能执行的前提条件。可以是到达某一状态，也可以是一些配置。

书写要求：一个简洁的结果。

用户已成功登陆

自动审核的开关已关

不需要写是怎么登陆的/如何将开关关掉的。

4、测试步骤

测试步骤是指如何执行用例，先做什么后做什么，是有顺序的概念在的。

步骤和用例的目标需要是一致的，任意一个偏离目标整个case就是无意义的。

书写要求：可执行的操作，功能用例步骤不大于7，流程用例步骤随业务而定-这里不做限制。

(1) 采集电影[check1]

(2) 预处理电影[check2]

(3) 审核电影[check3]

(4) 发布电影[check4]

5、预期结果

预期结果是和测试步骤一一对应的，有几个检查点，就需要有几个结果。

预期结果需要是可检查的，可从三个方面进行校验：

一：界面(结果会直接显示在界面上的)

二：数据库(有些数据只会存于数据库中)

三：磁盘(文件数据需具体到磁盘上看是否存在，数据是否正确)

书写要求：和测试步骤中check点一一对应，检查点>=1个

6、测试数据

测试数据：测试时使用到的数据。

书写要求：可用电影。

不用写到实际数据，在测试添加电影功能时，不需要写具体电影、导演、演员、宣传图片。

具体的数据-可以在数据准备时做好，如符合规格的图片(海报、图标、剧照)，符合码率的媒体文件(正片和预览片)。

最后，测试用例整体是有逻辑的-需要有用例设计的魂

编写测试用例的两个途径

1)先有用例设计，从整个产品/项目出发，先确定测试范围、测试目标，再细化范围到具体对象->具体功能，确定设计用例技术和测试方法，再来编写用例。

2) 测试执行后-通过Bug反推 修改补充用例。

两者相结合才会产出一份漂亮且有效的测试用例，理论->实践->理论过程。

附上编写测试用例常见问题

1、用例标题意图不明确

2、用例中引用其他用例

3、用例中包含过多的细节

4、用例中出现笼统的词

反复、多次

确定反复的具体次数

确定一个反复的范围

长时间

确定长时间的具体时间

确定一个长时间的范围

大量

确定具体的数据量

从需求/规格中中参照值

5、用例中步骤不可执行

6、用例中期望结果不可验证

1.单个字段的规则控制，比如登录时，用户名的规则

2.多个字段之间的关联性(约束)，比如登录时，用户名、密码的关系

3.完整界面的同一合法性

4.业务流程覆盖，比如购买商品从注册到收货全程

5.前后台数据一致性，比如页面内输入的数据，进入后台数据后是否正确

6.上下游数据一致性，比如主页产品的价格，点击跳转后内页面的价格