我写的测试用例

第一篇：我写的测试用例

我写的测试用例,请各位指点

软件/项目名称版本号：V4.0

测试环境预计输出P4 1.7，512M 内存，Windows 2000 Server

测试用例IDTS-CGHT-001用例名称：采购合同单据管理

相关用例采购申请,库存基础资料,采购基础信息

参考文献产品规格说明书-采购系统；物流详细设计-采购；采购管理功能分析文档

功能目标1.测试采购合同或采购协议等重要单据的保存查询修改等功能

2.测试采购合同单据对供应商供货价格信息的影响；

3.测试采购合同单据中有效期管理的控制；

4.测试采购合同关联生成采购订单时对库存及自身数据的影响；

前提条件

输入控制

1录入合同编号编号;

1.1是否可以有任意输入法录入各汉字、数字、字母等合法字符，长度达到编号最大的字条长度，并可以正常保存；

1.2录入越出字段长度的单据编号，在达到最大长度后是否允许继续录入；如可以继续录入字符，在保存数据时应该提示单据编号超长；

1.3在单据编号为空的情况下保存单据，是否给予提示；

1.4录入相同的编号，保存是是否有提示信息，是否可以保存；

1.5重复2至4步操作，看是否有异常情况，在恢复了正常数据后能否正常保存单据；

1.6测试编码规则，查看编码规则各种状态对单据编号的影响；

1.6.1设置编码规则为前缀加年月日加流水号，在编码规则生效后新增单据，观察编码规则是否正确；

1.6.2设置编码规则为前缀加月加流水号，在编码规则生效后新增单据，观察单据的编号是否正确；

1.6.3重复前两步，新增两到三张单据，查的编码规则是否可以按预定的步长自动增加；

1.6.4在编码规则中设置一个较长的前缀，使整个编码规则长度超出单据编号的最大值。将编码规则设置为生效，然后新增单据，查看单据保存时是否提示编号超长；

1.6.5将编码规则里的流水号长度设置为一位数，新增十张以上的单据，查看当超出十条张单据后是否有错误提示；

1.6.6修改原有编码规则，如前缀，流水号长度，将年月日样子改为年月的组合方式等，新增单据，查看新的编码规则是否可正常使用；

1.6.7将已经新增的编码规则设置为失效，重新新增单据检查单据是否可以手工录入；

1.6.8在编码规则里设置一个帐套，使这个帐套名称跟当前操作帐套不一样，新增单据，查看编码规则是否可以正常显示；

1.6.9将编码规则里的帐套删除，使帐套名称一项为空值，保存编码规则，重新新增单据，查看编码规则是否可以正常使用；

2录入原始合同编号(可选项,可以不录入数据)；

2.1录入控制同意气编号的手工录入控制；

3选择合同类别、来源、付款方式、发票类型,测试数据字典对单据的影响；

3.1在数据字典中依次查询合同类别、来源、付款方式等列名，并分别为各数据字典增加数据字典项，然后新增单据查看在合同类别等项目的下拉列表框里是否有刚才新增的数据字典项目，保存单据。

3.2将已经使用过的数据字典项目删除，查看时是否有提示；

3.3修改数据字典项，查看单据中的相关字段是否也已经修改；

4选择提货方式,测试提货方式和送货地址间的联系；

4.1选择提货方式为“自提”，保存单据时是否允许送货地址为空值；

4.2选择提货方式为“自提”，录入送货地址时是否可以自动保存地址；

4.3选择提货方式为“发运”，不录入送货地址，保存单据时是否有提示信息；

4.4选择提货方式为“发运”，录入送货地址，保存单据，使用地址的通用查询功能查看刚才录入的地址是否已经保存；

4.5选择提货方式为“发运”，录入一个超长的地址，保存单据时是否有提示信息；

5录入合同有效期等相关日期，测试合同有效期管理的作用;

5.1录入一个小于当前日期的数字保存单据,查看当日期小于当前系统时间时,是否有相应在的提示；

5.2随意录入一位数字，移动光标，查看是否将数字自动转换为系统时间；

5.3录入一个大于系统时间的日期，保存单据；查看是否可以正常保存；

5.4查看是否可以录入非数字型的字符；

6选择币种及付款方式,签订机构等信息，测试通用查询功能；

6.1录入币种里的任意字符，回车键，查看币种的通用查询功能是否可以实现模糊查询，汇率是否显示正确。

6.2录入币种的全称，回车键，查看是否可以正常显示系统及汇率；

6.3录入一个不存在的币种，回车键查看通用查询的结果，是否显示空集；

6.4录入币种里的任意字符，回车键，不选择任何一个币种，直接点取消，查看是否可以正常退出通用查询；

7选择物料，录入定价、数量、税金等数据，测试单价数量，金额税率的相互转换；

7.1选择或录入物料代码，查看代码、名称、规格型号等的对照关系；

7.1.1录入物料代码，查看物料名称、规格型号是否与代码相对应；

7.1.2修改物料代码，查看物料名称等是否也随之更改；

7.1.3录入一不存在的代码，查看通用查询功能是否正常；

7.1.4多次重复代码的更找操作，查看在多次转的情况下查询功能是否正常；

7.2选择计量单位，查看换算系数是否正确；

7.3合同订购数量与计量单位的联合测试；

7.3.1选择辅助计量单位，录入数量，保存单据，查看数据表里是将数量转换为标准计量单位的数量保存；

7.3.2修改单据，查看单据中的数量是否依然按照辅助计量间接显示数量；

7.3.3选择标准单位，录入数量，保存单据后，查看数据库里的数量是否按原数据保存；

7.4录入单价，对手工录入单价和自动提取单价进行相关测试；

7.4.1手工录入单价，测试单价的相关控制；

7.4.1.1录入常规单价，查看是否可以正常保存单价；

7.4.1.2录入一负数，查看是否可以录入；

7.4.1.3录入一非数字字符，查看是否可以录入；

7.4.1.4录入一超长小数位数的数值，保存单据，查看后台是否按规定保存小数位数；

7.4.1.5录入一超长数值，查看超出数值最大值后保存单据是否有提示；

7.4.2从“供方供货价格”中自动提取单价；

7.4.2.1在“供方供货价格”中设置供应商的供货价格，新增合同，选择物料时，该物料的单价自动显示（合同供应商与供方供货价格里使用同一个供应商）；

7.4.2.2修改“供方供货价格”里物料的价格，重新新增合同，查看是否以新的价格显示；

7.4.2.3删除“供方供货价格”里的物料，新增合同，查看单价是否显示为零；

7.4.2.4将“供方供货价格”中的“修改”标记取消，新增合同，查看是否可以修改单价；

7.4.2.5选择另外一个供应商增加相同的物料和价格，新增合同时，依然选择原供应商，查看物料是否显示单价；

7.5税率的录入控制；

7.5.1录入一个合法税率，保存单据查看保存在数据表里的数据是否为小数格式；

7.5.2录入一个合法税率，查看在浏览页里里是否以百分数格式显示；

7.5.3录入一个大于100的数字，保存单据，查看是否有提示；

7.5.4录入一个超出指定位数的小数，保存单据，查看数据表里存储的数据是否按要求保留小数位数；

7.5.5录入非数字型数字，查看是否允许录入；

7.6查看金额计算是否正确，金额的计算公式为：单价*税率*数量=金额；

7.6.1修改单价，查看金额是否得新计算；

7.6.2修改税率，查看金额是否重新计算；

7.6.3修改金额，查看单价是否重新计算；

7.6.4修改数量，查看金额是否得新计算；

7.6.5录入零，查看单价是否得新计算；

7.6.6录入负数，查看是否允许录入；

7.6.7录入零，保存单据查看是否允许估存单据；

8根据合同生成采购订单；

8.1一个采购合同生成一个采购订单；

8.1.1选择不在合同有效期范围内的合同，查看是否可以生成采购订单；

8.1.2选择在合同有效期范围的合同，查看是否可以生成采购订单；如果生成了合同，检查后台数据表里采购合同与采购订单中的相关联字段的字段是否正确；

8.1.3修改由合同生成的采购订单，查看后台数据里采购合同与采购订单相关系的字段是否受到影响；

8.1.4由合同生成一个订单，修改订单中的数量使订单中的数量大于合同中的数量，保存单据，查看是否有提示；是否可以正常保存；

8.1.5删除由合同生成的订单，查看是否可以再次生成订单；

8.1.6删除由合同生成的订单，查看后台数据中合同和订单关联的字段是否清楚；

8.2一个合同生成多个订单；

8.2.1由合同生成订单，修改订单中的数量，使订单中的数量小于合同中的订货数量；然后再用同样的方法重新新增采购订单，查看过滤条件中是否可以选择相同的合同；检查采购合同和采购订单中相关系的字段，保存的值是否都正确；

8.2.2由合同生成两个或多个订单，使多个订单数量之合大于合同数量，查看最后一张订单是否能保存；保存时是否有提示信息；

8.2.3删除由合同生成的多个订单，在执行删除时分别检查全同与订单中关联的数量是否得到相应的修改；

8.2.4删除由合同生成的多个订单中的一个，查看合同与订单关联的数据是否也得到相应的修改；

8.2.5删除全部合同生成的订单，查看合同与订单相关联的数据得到了相应的修改；

8.2.6删除全部全同生成的订单，查看是否可以重新生成订单；

预计输出1.显示手工录入或是编码规则要求的单据编号；

2.在合同有效期内可以关联采购订单;有效期不得小于当前系统日期;单据中的日期类字段不得小于当前系统日期；

3.付款方式,签订机构部门等带有通用查询功能的项目,支持键盘方向键选择或手工录入回车键查询功能;禁止新增;

4.物料订价可以为零,但不得出现负数;

5.合同来源,合同类型等由数据字典中维护;

6.物料明细允许选择大类物料；

7.物料的含税单价来源于“供应商供货价格”中指定的价格，如果没有指定物料价格，则由用户手工录入；自动带入的单价可手工修改；

设计人设计日期

测试人员测试日期

负责人

修改意见

备注

第二篇：测试用例怎么写

怎么写测试用例我刚刚就业来到公司做软件测试我在学校没有太多的机会做测试，测试用例和测试报告应该怎么写。

● 测试用例编号

◇ 规则：编号具有唯一性、易识别性，由数字和字符组合成的字符串◇ 约定：

系统测试用例：产品编号-ST-系统测试项名-系统测试子项名-XXX

集成测试用例：产品编号-IT-集成测试项名-集成测试子项名-XXX单元测试用例：产品编号-UT-单元测试项名-单元测试子项名-XXX

● 测试项目

◇ 规则：当前测试用例所属测试大类、被测需求、被测模块、被测单元等◇ 约定：

系统测试用例测试项目：软件需求项 如：测试手机在没有SIM卡的情况下，可以拨打紧急电话

集成测试用例测试项目：集成后的模块名或接口名 如：测试模块A提供的文件接口

单元测试用例测试项目：被测试的函数名 如：测试函数int ReadFile(char *pszFileName)

● 测试标题

规则：测试用例的概括简单的描述用例的出发点、关注点，原则上不能重复。● 重要级别

规则

高：保证系统基本功能、核心业务、重要特性、实际使用频率高的测试用例；中：重要程度介于高和低之间的测试用例；

低：实际使用频率不高、对系统业务功能影响不大的模块或功能的测试用例。● 预置条件

规则：执行当前测试用例需要的前提条件，是后续步骤的先决条件● 输入

规则：用例执行过程中需要加工的外部信息，输入、文件、数据库等● 操作步骤

规则：执行当前测试用例需要经过的操作步骤，保证操作步骤的完整性。● 预期输出

规则：当前测试用例的预期输出结果，包括返回值的内容、界面的响应结果、输出结果的规则符合度等

第三篇：自动售货机测试用例

题目：有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下：若投入5角钱或1元钱的硬币，押下〖橙汁〗或〖啤酒〗的按钮，则相应的饮料就送出来。若售货机没有零钱找，则一个显示〖零钱找完〗的红灯亮，这时在投入1元硬币并押下按钮后，饮料不送出来而且1元硬币也退出来；若有零钱找，则显示〖零钱找完〗的红灯灭，在送出饮料的同时退还5角硬币。1.分析这一段说明，列出原因和结果 原因：

1.售货机有零钱找 2.投入1元硬币 3.投入5角硬币

4.押下橙汁按钮 5.押下啤酒按钮

结果：

21.售货机〖零钱找完〗灯亮

22.退还1元硬币

23.退还5角硬币

24.送出橙汁饮料 25.送出啤酒饮料 2.画出因果图

如图所示。所有原因结点列在左边，所有结果结点列在右边。建立中间结点，表示处理的中间状态。中间结点：

11.投入1元硬币且押下饮料按钮 12.押下〖橙汁〗或〖啤酒〗的按钮 13.应当找5角零钱并且售货机有零钱找 14.钱已付清

3.转换成判定表：

4.设计测试用例

1)在售货机有零钱找的情况下，投入1元硬币，押下橙汁按钮，找回5角硬币并送出橙汁饮料。

2)在售货机有零钱找的情况下，投入1元硬币，押下啤酒按钮，找回5角硬币并送出啤酒饮料。

3)在售货机有零钱找的情况下，投入1元硬币，系统不做任何处理。

4)在售货机有零钱找的情况下，投入5角硬币，押下橙汁按钮，送出橙汁饮料。5)在售货机有零钱找的情况下，投入5角硬币，押下啤酒按钮，送出啤酒饮料。6)在售货机有零钱找的情况下，投入5角硬币，系统不做任何处理。7)在售货机有零钱找的情况下，押下橙汁按钮，系统不做任何处理。8)在售货机有零钱找的情况下，押下啤酒按钮，系统不做任何处理。

9)在售货机没有零钱找的情况下，投入1元硬币，押下橙汁按钮，售货机“零钱找完”灯亮，并退还1元硬币。

10)在售货机没有零钱找的情况下，投入1元硬币，押下啤酒按钮，售货机“零钱找完”灯亮，并退还1元硬币。

11)在售货机没有零钱找的情况下，投入1元硬币，售货机“零钱找完”灯亮。

12)在售货机没有零钱找的情况下，投入5角硬币，押下橙汁按钮，售货机“零钱找完”灯亮，并送出橙汁饮料。

13)在售货机没有零钱找的情况下，投入5角硬币，押下啤酒按钮，售货机“零钱找完”灯亮，并送出啤酒饮料。

14)在售货机没有零钱找的情况下，投入5角硬币，售货机“零钱找完”灯亮。15)在售货机没有零钱找的情况下，押下橙汁按钮，售货机“零钱找完”灯亮。16)在售货机没有零钱找的情况下，押下啤酒按钮，售货机“零钱找完”灯亮。

第四篇：测试用例书写标准

测试用例书写标准

在编写测试用例过程中，需要参考和规范一些基本的测试用例编写标准，在ANSI/IEEE829-1983标准中列出了和测试设计相关的测试用例编写规范和模板。标准模板中主要元素如下。

 标识符（identification）：每个测试用例应该有一个唯一的标识符，它将成为所有和测试用例相关的文档/表格引用和参考的基本元素，这些文档/表格包括设计规格说明书、测试日志表、测试报告等。

 测试项（test item）：测试用例应该准确地描述所需要测试地项及其特征，测试项应该比测试设计说明书中所列出地特性描述更加具体，例如做windows计算器应用程序地窗口设计，测试对象是整个地应用程序用户界面，这样测试项就应该是应用程序地界面地特性要求，例如缩放测试、界面布局、菜单等。

 测试环境要求（test environment）：用来表征执行该测试用例需要地测试环境，一般来说，在整个的测试模块里面应该包含整个的测试环境的特殊要求，而单个测试用例的测试环境需要表征该测试用例所单独需要的特殊环境需求。

 输入标准（input criteria）：用来执行测试用例的输入需求。这些输入可能包括数据、文件，或者操作（例如鼠标的左键单击，鼠标的按键处理等），必要的时候，相关的数据库、文件也必须被罗列。

 输出标准（output criteria）：标识按照指定的环境和输入标准得到的期望输出结果。如果可能的话，尽量提供适当的系统规格说明书来证明期望的结果。

 测试用例之间的关联：用来标识该测试用例与其它的测试（或其它测试用例）之间的依赖关系，例如，用例A需要基于B的测试结果正确的基础上才能进行，此时需要在A的测试用例中表明对B的依赖性，从而保证测试用例的严谨性。

综上所述，如果使用一个数据库的表来表征测试用例的话，它应该有以下的格式：

例一：对Windows记事本程序进行测试，选取其中的一个测试项――文件菜单栏的测试 测试对象：记事本程序文件菜单栏（测试用例标识1000，下同），所包含的子测试用例描述如下：

|---------文件/新建（1001）

|---------文件/打开（1002）

|---------文件/保存（1003）

|---------文件/另存（1004）

|---------文件/页面设置（1005）

|---------文件/打印（1006）

|---------文件/退出（1007）

|---------菜单布局（1008）

|---------快捷键（1009）

选取其中的一个子测试用例――文件/退出（1007）作为例子，测试用例如下表所示：

通过这个例子了解了测试用例的组成方法。要组织成一个完整的良好测试用例，还需要更多的技巧，并要考虑一些常见的因素。

测试用例设计考虑因素

测试是不可能实现穷举测试的，因此试图用所有的测试用例来覆盖所有测试可能遇到的情形是不可能的，所以，在测试用例的编写、组织过程中，尽量考虑有代表性的典型的测试用例，来实现以点带面的穷举测试。这要求在测试用例设计中考虑一些基本因素：  测试用例必须具有代表性、典型性。

 测试用例设计时，要浓缩系统设计。

例二：常见的web登录页面，通过这个例子来阐述从功能规格说明书到具体测试用例编写的过程

A）用户登录的功能设计规格说明书（摘选）

―――――――――――――――――――――――――――――――――――――――

1． 用户登录

1．1满足基本页面布局（图示，略）

1．2当用户没有输入用户名和密码时，不立即弹出错误对话框，而是在页面上使用红色字体来提示，见2描述

1．3用户密码使用掩码号（*）来标识。

1．4*代表必选字段，将出现在输入文本框的后面。

2． 登录出现错误

当出现错误时，在页面的顶部会出现相应的错误提示。错误提示的内容见3。错误提示是高亮的红色字体实现。

3． 错误信息描述

3．1

3．2密码为空

3，3用户名/

（注：本例子中的页面图示，消息编号如WMSG001的描述均为给出。）

―――――――――――――――――――――――――――――――――――――――

B）通用安全性设计规格说明书（摘选）

―――――――――――――――――――――――――――――――――――――――

1． 安全性描述

1．1输入安全性：在用户登录或者信用卡验证过程中，如果三次输入不正确，页面将需要重新打开才能生效。

1．2密码：在所有的用户密码中，都必须使用掩码符号（*），数据在数据库中存储使用统一的加密和解密算法。

1．3Cookie：在信用卡信息验证，用户名输入时，Cookie都是被禁止的，当用户第一次输入后，浏览器将不再提供是否保存信息的提示，自动完成功能将被禁用。

1．4SSL校验：所有的站点访问时，都必须经过SSL校验。

2． 错误描述（略）

―――――――――――――――――――――――――――――――――――――――

C）测试用例

结合相关的规格说明书，理解和掌握测试用例设计的关键点，测试用例设计如下表所示。

 测试用例需要考虑到正确的输入，也需要考虑错误的或者异常的输入，以及需要分

析怎样使得这样的错误或者异常能够发生。

用户登录功能测试用例

完善的测试用例

 用户测试用例的设计，要多考虑用户实际使用场景。

第五篇：测试用例设计步骤

测试用例设计步骤

设计测试案例的时候，需要有清晰的测试思路，对要测试什么，按照什么顺序测试，覆盖哪些需求做到心中有数。测试用例编写者不仅要掌握软件测试的技术和流程，而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。测试用例设计一般包括以下几个步骤：

1、测试需求分析

从软件需求文档中，找出待测试软件/模块的需求，通过自己的分析、理解，整理成为测试需求，清楚被测试对象具有哪些功能。测试需求的特点是：包含软件需求，具有可测试性。测试需求应该在软件需求基础上进行归纳、分类或细分，方便测试用例设计。测试用例中的测试集与测试需求的关系是多对一的关系，即一个或多个测试用例集对应一个测试需求。

2、业务流程分析

软件测试，不单纯是基于功能的黑盒测试，还需要对软件的内部处理逻辑进行测试。为了不遗漏测试点，需要清楚的了解软件产品的业务流程。建议在做复杂的测试用例设计前，先画出软件的业务流程。如果设计文档中已经有业务流程设计，可以从测试角度对现有流程进行补充。如果无法从设计中得到业务流程，测试工程师应通过阅读设计文档，与开发人员交流，最终画出业务流程图。业务流程图可以帮助理解软件的处理逻辑和数据流向，从而指导测试用例的设计。

从业务流程上，应得到以下信息：

A、主流程是什么

B、条件备选流程是什么

C、数据流向是什么

D、关键的判断条件是什么

3、测试用例设计

完成了测试需求分析和软件流程分析后，开始着手设计测试用例。测试用例设计的类型包括功能测试，边界测试，异常测试，性能测试，压力测试等。在用例设计中，除了功能测试用例外，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题。

黑盒测试的测试用例设计方法有：等价类划分、边界值划分、因果图分析和错误猜测，白盒测试的测试用例设计方法有：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖。在这里主要讨论黑盒测试。在设计测试用例的时候可以使用软件测试用例设计方法，结合前面的需求分析和软件流程分析进行设计：

功能测试：测试某个功能是否满足需求的定义，功能是否正确，完备。

适合的技术：由业务需求和设计说明导出的功能测试、等价类划分

边界测试：对某个功能的边界情况进行测试。

适合的技术：边界值划分

异常测试：对某些功能来说，其边界情况无法简单的了解或某些操作不完全是正确的但又是

可能发生的，类似这样的情况需要书写相关的异常测试。

适合的技术：由业务需求和设计说明导出的特殊业务流程、错误猜测法、边界值

分析、内部边界值测试。

性能测试：检查系统是否满足在需求中所规定达到的性能，性能主要包括了解程序的内外部

性能因素。内部性能因素包括测试环境的配置，系统资源使用状况；外部因素包

括响应时间，吞吐量等。

适合的技术：业务需求和设计说明导出的测试

压力测试：压力测试又称强度测试，主要是检查系统运行环境在极限情况下软件运行的能力，比如说给一个相当大的负荷或网络流量给应用软件兼容测试：测试软件产品在不

同的平台，不同的工具，相同工具的不同版本下功能的兼容性。

4、测试用例评审

测试用例设计完成后，为了确认测试过程和方法是否正确，是否有遗漏的测试点，需要进行测试用例的评审。

测试用例评审一般是由测试leader安排，参加的人员包括：测试用例设计者、测试leader、项目经理、开发工程师、其它相关开发测试工程师。测试用例评审完毕，测试工程师根据评审结果，对测试用例进行修改，并记录修改日志。

5、测试用例更新完善

测试用例编写完成之后需要不断完善，软件产品新增功能或更新需求后，测试用例必须配套修改更新；在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。软件的版本升级更新，测试用例一般也应随之编制升级更新版本。测试用例是“活”的，在软件的生命周期中不断更新与完善。