用例模板一般分为2种 一种以excel的方式 1种是以word的方式来进行展示

定义

列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

1.4参考资料

列出要用到的参考资料，如：

a．本项目的经核准的计划任务书或合同、上级机关的批文；

b．属于本项目的其他已发表的文件；

c．本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件的

标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。

面试题：任意的测试用例都含有 用例编号 （项目名字—模块名字_用例编号）

                  所属模块

              执行条件

                测试输入（具体的执行步骤  ）

          预期结果

              实际结果

              用例是否通过

        测试人（执行测试用例的人）

          版本

        备注

在编写测试用例的时候是不需要填写实际结果的 在执行测试用例的时候填写结果

在编写测试用例的时候一定要注意到的测试用例的覆盖度

支付宝WAP支付平台测试方案

一、项目简介支付宝WAP

平台从总体上分为子模块，分别是登录、注册、账户管理、交易管理、缴

费中心和交易接口，系统结构图如下：

二、测试方案组成部分

根据我们对支付宝WAP平台设计方案的分析，认为本测试方案应该由三个部分组成，

即软件验证技术、软件确认技术和软件测试管理技术。它们内涵及相互之间的关系如下图所

示：

其中，软件验证技术着眼于排除软件开发文档中的错误。验证活动涉及的文档按开发流程主

要涉及需求规格说明、设计规格说明（包括概要设计规格说明、详细设计规格说明、数据库

设计规格说明）、编码规格说明、产品交付文档等壹系列书面材料。目前验证技术的实施在

很大程度上是依靠测试人员手工完成的。验证活动视实际需要有时仍会涉及到开发人员和目

标客户，需要得到他们必要的理解和支持。验证测试采用的主要测试手段有：面对面质询、

文档抽查、非正式会议、同行评审等等。

相对于软件验证技术，软件确认技术则主要着眼于排除程序代码中的错误。活动涉及的对象

主要是程序部件的代码或软件成品。在实施过程中，常常按被测代码的规模和测试所处的层

次将软件确认测试分为四个阶段，即：单元测试（也叫类测试）

、集成测试（也叫组装测试）系统测试和交付测试。确认测试基本上由软件测试人员对照相关开发文档运行程序独立完成的。必要时，也可让设计人员带领测试人员阅读程序代码共同发现其中的错误，（即所谓代码评审会）。我们认为，在单元测试(或类测试)阶段，应该有软件编码人员参和，这样能减轻测试人员阅读代码障碍。原则上，测试理论不提倡程序作者负责把关自己编写的程序的质量。在实际实施过程中，可视实际情况灵活处理。（如成对编程可能会较好的处理单元测试这个难题，上面提到的代码评审会也是为应对这个难题而想出的壹个好办法。），软件确认技术目前已经部分地实现了测试工具的自动化，市面上已有不少自动化工具能在测试人员的辅助下完成相应的测试工作（例如用于Java代码单元测试的Junit工具，又如用于GUI测试的RationalVisualTest工具，等）。软件验证技术和软件确认技术均属于测试技术层面的东西。然而对于工程质量的保证而言，光靠软件测试技术仍远远不够，仍需要技术管理层面上的东西。我们这里强调软件测试管理技术的目的正是为弥补这个不足。按照管理的对象不同，测试管理技术大致涵盖软件测试团队组织管理、软件测试计划管理、软件缺陷（错误）跟踪管理以及软件测试件管理四大部分。

下面，针对支付宝WAP平台项目对该测试方案做壹个详细的诠释。

三、在支付宝WAP平台测试过程采用的测试内容3.1在支付宝WAP平台采用测试验证技术我们将对支付宝WAP平台采用软件验证技术，主要包括需求规格说明验证、设计规格说明验证、代码验证以及交付验证。以下逐壹说明。需求规格说明验证的主要任务是保证用户的功能需求、业务需求、以及其他的壹些需求（如非功能性需求、约束性需求等等）都已经被分配到软件需求规格说明的各需求项中。设计规格说明验证相对需求规格说明验证而言，稍微复杂些，它包括3个部分的内容：即概要设计规格说明验证、详细设计规格说明验证以及数据库设计规格说明验证。其中概要设计规格说明验证的主要任务是确保软件需求规格说明中的需求项全部已经分配到了概要设计规格说明的各软件模块之中且且无多余物，详细设计规格说明验证的主要任务是确保概要设计规格说明中的模块已经全部分配到详细设计规格说明的各软件单元之中且且无多余物，数据库设计规格说明虽然从范畴上讲应该属于详细设计规格说明范畴，但我们认为应该把它独立出来实施验证活动。（数据库设计和软件设计毕竟有很多不同之处。）数据库设计规格说明验证的重点任务是验证数据库和外部应用程序的接口是否正确、数据操作实现界面是否清晰、数据库整体设计是否合理、数据表设计是否符合3NF要求（如违反范式要说明详细理由）以及数据表中的字段（键）和索引的设计是否高效合理等等。代码验证的内容包括：代码编写规范审查、代码审查和代码静态分析三个部分。代码编写规范审查主要是审核代码排版的格式以及注解的格式是否符合开发团队的相应规范；代码审查的任务主要是验证详细设计中的软件单元是否都已被代码覆盖且正确实现，且且代码中不含冗余物；代码静态分析技术主要任务是检查变量或标号的定义和使用、表达式运算以及程序的流程设计上是否存在缺陷或错误。做完代码验证以后，软件系统需要依次做单元测试、集成测试和系统测试，这部分内容属软件确认技术范畴，下面有专门的论述。软件系统在做完系统测试后，就面临着交付使用的问题，在系统正式移交给用户之前，仍需要做交付验证和交付测试。交付测试技术下文有专门的论述，不赘述，这里主要谈交付验证技术。交付验证包括安装验证和使用验证俩部分内容。其中，安装验证的主要任务是保证程序能按照用户手册的提示正确安装到目标机器上，使用验证的主要任务是确保程序能按照用户手册的提示的操作正确完成某项功能或事务处理。这俩部分工作通常是由测试人员完成的，用以核实相关安装和使用手册是否正确无误。

3.2在支付宝WAP平台中应用软件确认技术为了确保及时、尽早发现软件中存在的问题，我们将在支付宝WAP平台的测试过程使用的确认技术包括：单元测试技术、集成测试技术、系统测试技术和交付测试技术。单元测试：主要任务是验证详细设计规格说明中所划分出来的软件单元是否被程序编制人员用代码形式正确地实现了。这里软件单元可能是某个函数（或称方法）也可能是某个抽象数据类型（如类、数据结构或者模板）。单元测试在实际测试当中也常常被称为类测试（在面向对象的设计中）或白盒测试（白盒的意思是面向代码）。

测试人员输入设计好的测试用例，测试被测单元能否按照设计要求处理这些测试用例，对出现异常的测试用例，测试人员将做记载且反馈给软件开发团队。集成测试：对照软件概要设计规格说明，验证各软件单元组装后形成模块能否达到概要设计规格说明中模块的设计目标；在模块级集成工作完成之后，测试人员仍应测试各模块组装后形成的用户系统内部存在冲突，各模块能否正常工作。通常在做集成测试时先是从分系统内部的集成测试开始做起，做完以后再测试各分系统是否能集成为最终要实现的大系统。也有加入VIP免费专享

2计划

2.1软件说明

提供一份图表，并逐项说明被测软件的功能、输入和输出等质量指标，作为叙述测试计

划的提纲。

2.2测试内容

列出组装测试和确认测试中的每一项测试内容的名称标识符、这些测试的进度安排以及

这些测试的内容和目的，例如模块功能测试、接口正确性测试、数据文卷存取的测试、运行

时间的测试、设计约束和极限的测试等。

2.3测试1（标识符）

给出这项测试内容的参与单位及被测试的部位。

2.3.1进度安排

给出对这项测试的进度安排，包括进行测试的日期和工作内容（如熟悉环境。培训、准

备输入数据等）。

2.3.2条件

陈述本项测试工作对资源的要求，包括：

a．设备所用到的设备类型、数量和预定使用时间；

b．软件列出将被用来支持本项测试过程而本身又并不是被测软件的组成部分的软件，

如测试驱动程序、测试监控程序、仿真程序、桩模块等等；

c．人员列出在测试工作期间预期可由用户和开发任务组提供的工作人员的人数。技术

水平及有关的预备知识，包括一些特殊要求，如倒班操作和数据键入人员。

2.3.3测试资料

列出本项测试所需的资料，如：

a．有关本项任务的文件；

b．被测试程序及其所在的媒体；

c．测试的输入和输出举例；

d．有关控制此项测试的方法、过程的图表。

2.3.4测试培训

说明或引用资料说明为被测软件的使用提供培训的计划。规定培训的内容、受训的人员

及从事培训的工作人员。

2.4测试2（标识符）

用与本测试计划2.3条相类似的方式说明用于另一项及其后各项测试内容的测试工作计

划。

3测试设计说明

3.1测试1（标识符）

说明对第一项测试内容的测试设计考虑。

3.1.1控制

说明本测试的控制方式，如输入是人工、半自动或自动引入、控制操作的顺序以及结果

的记录方法。

3.1.2输入

说明本项测试中所使用的输入数据及选择这些输入数据的策略。

3.1.3输出

说明预期的输出数据，如测试结果及可能产生的中间结果或运行信息。

3.1.4过程

说明完成此项测试的一个个步骤和控制命令，包括测试的准备、初始化、中间步聚和运

行结束方式。

3.2测试2（标识符）

用与本测试计划3.l条相类似的方式说明第2项及其后各项测试工作的设计考虑。

4评价准则

4.1范围

说明所选择的测试用例能够接查的范围及其局限性。

4.2数据整理

陈述为了把测试数据加工成便于评价的适当形式，使得测试结果可以同，已知结果进行

比较而要用到的转换处理技术，如手工方式或自动方式；如果是用自动方式整理数据，还要

说明为进行处理而要用到的硬件、软件资源。

4.3尺度

说明用来判断测试工作是否能通过的评价尺度，如合理的输出结果的类型、测试输出结

果与预期输出之间的容许偏离范围、允许中断或停机的最大次数。

参加评审会的对用例4、评审内容

评审的内容有以下几个方面

1)用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。

2)优先极安排是否合理。

3)是否覆盖测试需求上的所有功能点。

4)用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确期待结果是否有明显的验证方法。

5)是否已经删除了冗余的用例。

6)是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在"保护"20%的功能实现。

7)是否从用户层面来设计用户使用场景和使用流程的测试用例。

8)是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。