测试用例编号        MONEY01_ST_GETEXCHANGERATE_GERCONSISTENCY_001
测试项目                        测试同一种兑换的获取汇率的值
测试标题                        同一种兑换的获取汇率的值是否一致
重要级别                        高
预置条件                        在外汇金额文本框输入数字
输入                        1. 在外汇金额文本框输入数字1
执行步骤                        1.在外汇金额文本框输入数字1
                                2.选择日元单选按钮
                                3.按计算按钮
                                4.在获取汇率文本框处得到一个汇率
                                5.按获取汇率按钮
                                6.选择日元汇率单选按钮
                                7.在获取汇率文本框又得到一个汇率
预期输出        这两次所得到的获取汇率值应都与SRS中要求的一致

引用:

原帖由 pang 于 2005-9-17 15:43 发表
我们公司就我一个人测试，测试用例我自己写，执行我自己执行，测试报告也是我自己搞定，其实我都很不确定，我写的到底是对的还是错的，迷茫啊～没有人教我，只能自己摸索了……

ME TOO,

偶也是一个人摸索啊,至今还没写过测试用例,就算写了,也是为自己服务....

真的假的

我认为是没有必要的，但是我们项目开发是，开发经理就是要我们做这些

步骤应该还是要详细点好sdlkfj2

sdlkfj5 应该需要写，如果步骤重复可以写参考用例XXX

haodongxi

都不拿 自己的出来看看哦~~~

学习学习~~~

学习

我认为是不是每一个都要很详细的，对复杂的就要写详细了，不然都不知道是怎么得出这个错识的结果！
学习当中。请多多指教

测试用例作为测试执行的指导，我认为在项目时间允许的情况下，应该尽量详细，
1、在测试执行者并非用例设计者，或者测试执行者对项目不是很熟悉的情况下，用例对操作步骤的描述就是测试执行的指南。每个人的思维模式不一定一样，含糊描述不清的用例就像需求不明确一样，会产生歧义，在测试过程中可能会出现各种问题，同样的用例不同的人执行可能会有不同的结果。
2、项目结束后，测试用例作为软件开发周期中的中间产品存档。当项目升级或者有类似项目的时候，可能用例设计者一下子也难以理解当时的用例，增加了用例复用难度。
  好的用例应该能让非测试人员一看就能明白，这样测试执行对测试人员水平的依赖性也会减少，测试点也更明确。针对不同类型的项目，每个公司都应该制定相应实用的用例规范。
一点建议：当用例需要输入大量数据时，可以考虑将测试数据单独设计，在用例中对数据进行引用。

谢谢72楼的，这个我清楚了，上次经理也是这样说我，写得自己看明白的是没有用的，
要让大家一看就能明白，就可以了

测试用例1要让执行的人照章执行,2要利于做回归测试,所以需要详细,清楚的才好.

我的感觉是，测试用例不需要写得那么详细，给出的理由有下面这几点：
1.会花费太多的时间，测试是个有计划的事情，一般编写测用例都有时间的限定，要知道随便一个项目都有200-300个用例，步骤就更不用说了，如果你每一步都描述得那么详细，就不用做其他的事情了，光写用例就够了（如果你只负责写用例，不管其他的除外）；
2.做不到详细，对于按哪个按钮之类的应该少出现在用例中，你想想看，在编写用例的时候我们都不知道他到底是给出的是按钮还是下拉或者响应操作，除非在需求中有说明会给出哪急个按钮，一般来说，写出“XX模块下的XX界面下的XX操作”就行了，你如果要详细写的话，就该是“用户登入系统页面，点击XX模块，进入了XX界面，在界面下点击XX按钮”，但这样的话，真实在测的时候，有时候你会找不到XX按钮在哪里的，因为它不一定是按钮形式存在的；
3.测试人员的学历水平，我们要知道，做软件测试这行的肯定不会是小学生，“XX模块下的XX界面下的XX操作”，这样的描述对于我们来说是很清楚的，因此根本就用不着细化到点什么按钮之类；
4.实际环境，如同网上关于输入三个数值成什么三角形的用例，可以做出将近100种，但是我们真正都要去输入一遍吗？肯定不会的，我们主要是把容易出错的那几种测试，而其他的需要测试的成本太大，就没必要去一一去测的，还有就是就我对我们公司的用例来看，对于这些都不会出现实际要输入的数字，而是说输入超出范围的数字，这样有利于用例的使用，因为有很多用例是可以使用在其他项目的，如果你出现了真实的数字，就没可移植性了。
  我的想法是这样，用例的编写是看实际情况而定的，个人看法~呵呵