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

njalic

软件/项目名称                版本号：        V4.0
测试环境预计输出        P4 1.7，512M 内存，Windows 2000 Server
测试用例ID        TS-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.        物料的含税单价来源于“供应商供货价格”中指定的价格，如果没有指定物料价格，则由用户手工录入；自动带入的单价可手工修改；
               
                       
设计人                设计日期       
测试人员                测试日期       
负责人                       
修改意见       
备注

ww0221542

这个我个人觉得只能算是test case outline，具体到测试用例因该把每一个outline转换成一个或多个（如果描述得比较笼统）测试用例。针对每一个测试用例，详细描述运行逻辑及过程，然后给出具体的测试用输入数据，然后是具体的预期输出数据（数据库中的输出数据）。

njalic

Originally posted by Superman-xuyong at 2005-7-30 05:48 PM:
我发现国内公司的测试写得比较简单，笼统。相对来说国外（特别是日本），就非常详细具体了，可以说面面俱到

能举个例子吗？在那里可以找到相关的用例参考一下呢？

Superman-xuyong

我发现国内公司的测试写得比较简单，笼统。相对来说国外（特别是日本），就非常详细具体了，可以说面面俱到

njalic

多谢各位前辈的指导,文章已经下裁, 努力学习中, 希望下次能拿出一个合格的测试用例来答谢各位的精心指教.

jackei

ok ^_^

jacckljl

呵呵！！我写了很多哦！！
你注意查收。

jackei

jacckljl，你可以点击上面的“邮件”按钮来联系我。^_^

jacckljl

to jackie:
    看了你几篇文章和留言，非常欣赏！！我现在正在做测试计划和用例，很多问题想向你请教，能把你的E-mail告诉我吗？？

jackei

如果有兴趣，也可以下载下面的几篇文章，或许有些帮助。

http://www.cnblogs.com/jackei/archive/2005/03/03/112201.html

jackei

01.每个测试用例应当有一个明确的测试目的；
02.要做好测试类型的区分，对于基于业务的功能测试和针对具体实现相关的UI测试应当在设计测试用例时区分开；
03.功能测试的关注点应当是某个对用户有实际意义的业务，也就是一个“有效功能”。

        有效功能是指在被测应用所涉及的实际业务中，当用户在原始状态下进行工作时，整个业务流程中对用户来说，具有实际意义那些功能。当我们把这个功能单独从计算机软件还原到用户的原始手工状态时，它的完成可以作为用户实际业务的一个阶段性结束的标志，而不是一旦从这个业务流程中独立出来就失去了意义。而该业务完成后，可以为其他用户或业务提供所需要的信息。
为了方便理解，我们可以先看一下下面的例子。
拿我们常见的财务软件来说，当填写一张会计凭证时，通常是需要填写会计科目，在使用计算机完成工作时，我们可以利用软件的功能，从很多备选科目中选择一个自己需要的科目，或者通过科目代码来输入科目。这项功能很有可能会作为一个特性要求出现在软件需求规格说明书中，那么这个科目的选择或输入是不是一个有效功能呢？让我们试着用上面规则来衡量一下。
首先，这个功能所实现的操作在用户手工业务处理过程中是存在的，不同的是这项功能是在用户填写凭证时，在自己的大脑中完成的。那么这项功能的完成对于用户来说意味着什么呢？我们从上面的描述中可以看到，用户希望软件提供的是可以添加一张完整的凭证这样的功能，而不仅仅是方便填写会计科目。填写会计科目只是用户在添加凭证时的一个步骤，单独把这个功能提取出来对用户来说没有任何实际意义。对于业务流程下游的用户，需要的也不仅仅只是一个会计科目的信息，而是一张包含了会计科目以及其他会计信息的完整的会计凭证，否则就无法进行下面的工作。这样看来，这个功能并不是一个有效的功能，我们可以把它最为需要测试的特性在测试需求中进行描述，却不应该作为一个单独的测试用例出现在我们的测试用例集中。而我们在测试用例中真正关注的，应该是添加会计凭证这个具有实际意义的功能。
另外，对于那些相互之间存在数据或状态的依赖性的业务（有效功能），同样要注意将它们剥离到不同的测试用例中。在剥离的过程中，要分清这些业务之间的相互依赖是否只是对数据或状态的依赖，如果是这样，那么可以简单的把上下游业务之间的关系理解为输入、输出的关系：下游业务只是根据上游业务不同的输出做出不同的反应。这样在每个测试用例的开始，把不同的输入作为不同前置条件来描述就可以了。当然，下游业务对不同输入的不同反应是应该放在不同的测试用例中进行描述的。

songfun

这样子吧，你可以这样理解，一个用例应当尽可能的类似于一个事务（就是一个“原子”）。
你的用例应当循着唯一的出口去执行，如果碰到第二个出口，那么这属于另一件事，可作为备选事件来设计另一条用例。

我知道有些行业的业务相当复杂，涉及整个流转，但是从你的用例设计思路来看，还有很大余地去分解。

另外，提一点，你的用例设计没做好很大原因在于你根本没做 测试需求！
你的用例实际上是对测试需求的“详细设计”。

你不如拟一个 测试需求文档，让大家帮拟看看！

njalic

请问songfun版主 :一个用例就测一样东西? 这个如何理解? 例如像物流系统这样复杂的应用程序,如何把每个业务流中的用例进行合现的分解呢?有分解的标准吗? 我的理解是,将具有相同功能的操作合成一个测试用例.然后再将这些用例合成一个综合的用例.

如在物流系统里采购合同,采购购合同作用只是一张普通的单据,系统只提供查询修改,删除等普通功能,与其他单据的业务联系只是根据合同自动生成一个采购订单.

分解方式如下:
1 将单据中来源于数据字典和通用查询是功能的项目分解成独立的测试用例.遇到这类需要选择的数据,可提示调用相关的测试用例;

2 将具有相同的录入控制项目独立编写测试用例,遇到该类的数据录入调用相关的用例.例如文本型,日期型,数值型数据的录入控制;

3 合同的测试用例(1) (2)分别突出两个功能,A 单据中数量金额的计算方法(涉及税率币种汇率,计量单位等)  B 由合同自动生成采购订单的控制;

4 分别编写合同的修改,删除测试用例,强调在执行修改删除等操作时对采购订单的影响及后台数据的控制.

我会把分解后的测试用例再次上传,请各位继续指教.

[ Last edited by njalic on 2005-5-18 at 12:17 ]

songfun

这个用例写的比较失败。

用例设计的原则是：一个用例就测一个东西。
不要全写在一起，建议到 用例版 看看一些模板。
http://bbs.51testing.com/viewthread.php?tid=11963&fpage=1

jackei

测试用例设计时，对于每个测试用例，应当有一个明确的测试目的或者目标，这个目标也应该尽量不要过于复杂，如果在一个测试用例中验证过多的内容，就容易变得失去重点，并且过于庞大。
建议楼主考虑一下先把测试用例区分成不同的部分，有的针对需求中定义的功能，有的针对UI，有的针对业务流程，有的针对某个具体的特性。这样会让测试用例看起来思路更清晰，而且多人同时执行起来也比较方便。

takiro

楼主写的不是测试用例 而是某一功能点的测试用例集
就象TESTING所说的 对于某一功能点的测试 要将各种测试输入分开。。
而且你的步骤并不清楚。。
如：提示输出信息。。 那输出信息是什么？都未写清楚 明白。
而且在设计测试用例时最好也能考虑一个功能流（业务流）的测试。
因为对于单个的功能点测试不一定有问题 但对于某一个业务流进行测试的时候问题就会突现出来。

testing

这个测试用例太庞大了，建议拆解开，并且用例的没有步骤描述的并不清楚，并且测试用例的输入、操作步骤和预期输出混在一起，如果测试用例设计和执行由不同的人员完成，该测试用例不一定能够很好的指导测试。