引用:

原帖由 肚皮 于 2004-12-12 22:57 发表

其实我也想把自己工作中的东西拿出来，让大家批评指正，这样自己才会提高，但是我们做的东西是保密的，我也签了保密协议，绝不能漏出工作中的东西，无奈。

完全可以不写透漏你所测试的软件信息啊，自己按照你所测的用例格式给大家编写一个不就可以了？比如你测试QQ的某个小功能：登陆。。。。等等，给大家展示一个格式而已嘛

学习中................

我们公司也是只有我这只小菜是测试人员,还有一个更菜的.

我觉得要看公司是否有这方面的规定了，大公司的话应该有一些标准，应该具体到什么程度。
一般情况的话，应该是越具体越好了，你也不知道谁会执行你的用例，要是执行的人老是跑来问你关于case的问题，你也要烦死的！如果自己执行的话，嘿嘿，自己懂就行了。

根据需要而定吧

新的测试理念应该是:测试用例是按需求来写,而且是与应用程序的开发同步进行的,就是说你写用例的时候还没应用程序.这就是做QA的挑战,等到应用程序开发完了,你再去测用例,如果用例写的不详细,你测的时候就要再次思考.

需要，因为步骤是告诉测试执行人员该怎么做测试！

测试用例执行人员可以看懂并照用例设计者的原意步骤来进行操作测试就可以了

个人感觉，要写但不能十分详细，要详细到恰到好处，就是要根据看测试报告的人的眼光来定。如果审查报告的人是外行，那就得写的详详细细的，好让他感觉到测试人员的价值；如果审查报告的人是内行，那就简明扼要的，让他感觉测试人员的能力。
这年头，啥都是假的，就自己是真的。
唉……

顶一下，新手上路，多多指教，sdlkfj2 偶觉得还是要写一点的吧，至少要包括输入和预期的输出吧，要不怎么知道测试正确与否呢？sdlkfj5

1、验证一个软件系统在一定程度上是可用的
2、找出软件中存在的错误
3、尽量地预防或减少软件系统中可能存在的错误

要吧

学习啦！！

sdlkfj2 我只是来混水

sdlkfj2 我也是刚开始写测试用例的 发表一下个人看法
我认为 根据系统的需求和功能说明 列出所有可能会出错的数据的输入或操作步骤， 是必须的
一一列出 比较好吧  这也更方便 错误重现
比较相信的一句话：软件的错误 无处不在 ！ ：）

测试用例写要把软件功能所涉及的功能都需要写上，虽然有些功能可能用户会用不到。但我们不是 用户。作为测试人员就必须将需求说明书中所叙述的功能都得写上。
    至于数据就不用写了，那个不属于测试用例得范畴，属于你测试的前期准备。只要写个大概的等价分类就可以了！！

sdlkfj2   第一次写用例很详细的，但是后面感觉内容实在是多，如何穷举呢？所以也就点到为止，重要的还是要有各种各样场景分析及数据准备。

我顶15楼的dionysus

虽然刚从开发转到测试领域,但是我觉得,还是有个统一的规范比较好
一会看看CMMI里有米有测试这块的域

我认为还是写的详细点好

软件测试用例需要有：
测试用例编号，测试项目，测试标题，重要级别，预置条件        ，输入，执行步骤，预期输出，这几项。并且针对每一项都是有具体要求的。
测试用例编号
规则：测试用例编号，是由字符和数字组合成的字符串，用例编号应具有唯一性，易识别性。
约定：系统测试用例
  产品编号_ST_系统测试项名_系统测试子项名_***
集成测试用例
  产品编号_IT_集成测试项名_集成测试子项名_***
单元测试用例
  产品编号_UT_单元测试项名_单元测试子项名_***
测试用例项目：
规则
当前测试用例所属测试大类，被测需求，被测模块，被测单元等。
约定
系统测试用例测试项目：软件需求项
集成测试用例测试项目：集成后的模块名或接口名
单元测试用例测试项目：被测函数名
测试用例标题：
规则用例的简单描述，需要用概括的语言描述该用例的出发点和关注点，原则上每个用例 的标题不能重复。
测试用例重要级别：
规则
高：保证系统基本功能，重要特性，实际使用频率比较高的用例
中：重要程度介于高和低之间的测试用例
低：实际使用频率不高，对系统业务功能影响不大的模块或功能的测试用例
测试用例与设置条件：
规则
执行当前测试用例需要的前提条件，如果这些条件不满足，则后面的测试步骤无法进行或者无法得到预期结果。
测试用例输入：
规则
用例执行过程中需要加工的外部信息。根据软件测试用例的具体情况，有手工输入，文件，数据库记录等
测试用例操作步骤：
规则
执行当前测试用例需要经过的操作步骤，需要明确的给出每一个步骤地描述，测试用例执行人员 可以根据该操作步骤完成测试用例执行
测试用例预期结果
规则
当前测试用例的预期输出结果，包括返回值的内容，界面的响应结果，输出结果的规则符合度等


测试用例编号