编写好的黑盒测试用例实例

ghl5502

谁有编写好的黑盒测试用例，请给我传过一份来好吗？
我的邮箱是；ghl5502@sohu.com
我现在是一个新手，今天开始编写测试用例，怎么都写不了，请问谁有已经已经做过项目的黑盒编写实例，给我传来一份，我好有个参考。照猫画虎嘛，也算有个参照了，不胜感激！！！

[ 本帖最后由 楠族开心果 于 2010-5-24 17:11 编辑 ]

fivi2008

彼此,同为新手，如果你收到了给我一分,多多交流.

ghl5502

我现在正在发愁呢，写不出来呀

testing

给出一个简单的需求，我写出一个测试用例，供您参考，如何？

testing

开发人员提供的需求就是这个样子的吗？这比用户手册还简单。严格的说，这不是需求，应该算是产品规格，而且是很粗的产品规格。

ghl5502

其实开发人员没有任何资料给我，现在就知道这些了，没有其他办法了

ghl5502

不知高手有没有其他办法

testing

稍后smartbaby会发一个测试用例上来。

smartbaby

正好前阵子，应某斑竹的要求，写了一个用例
今天就抛上来，欢迎扔砖头～～多提意见！！
把拔牙的痛给掩饰掉～～^_^

ghl5502

多谢，到时候我写好了，还要请版主指教了，谢谢

smartbaby

开发的需求和测试的需求在某种条件下是一致的，但是通常情况下会有些许的不同～
在我给出的用例中可以明确的看到这个区别～
非常简单的开发需求，有时候隐藏着很多的测试需求。关键是看分析的程度和深度！

ghl5502

多谢，到时候我写好了，还要请版主指教了，谢谢

smartbaby

^_^，不用客气～～
我当初写这个用例也满仓卒的，难免存在很多不足之处，今天正好拿出来献丑，给大家讨论讨论。
欢迎对这个用例多提意见，大家一起进步！

archonwang

例子测试已经比较详细了，具体还有一些地方需要商榷，如：最好能制定三方共识（开发人员可以接受，用户可以简单掌握，测试人员可以通过）。这对测试工作的开展有较好的辅助作用。
请大家指正。

greenhouse

谢谢斑竹提供得测试用例。您的测试用例确实很详细。我也是一个测试新手，我也写过一些测试用例，不过主要是通过需求说明书写的，并且模板格式也是单位提供的。我单位的模板中没有场景、条件这一项只有执行子项这种说法。但是对于UI风格的测试一般都没有，这难道在需求中也规定了吗？您写的测试用例是根据需求写的吗？怎么能够这么详细，可是我看单位的需求根本就不能详细到这样的程度？

ghl5502

是啊，版主可以告诉我们具体的编写过程，或者是你的需求分析吗？不知道版主是怎么做到把测试用例写的这样详细的，谢谢版主。

greenhouse

斑竹，我看了您的测试用例。
（1）又有一个问题。测试用例上面没有用例编号、功能模块、测试项、用例描述、用例设计者、环境准备这些项。难道这些项不需要在测试用例中体现出来吗？
（2）并且第18到23这六个用例是否可以合并呢？您这样设计是否有些过于繁琐
（3）24和25这两个用例中的字节数是什么概念？是一个汉字相当于两个字母或 数字吗？
（4）我们单位设计测试用例的编号是一个基本的功能项是×，当它的子项时用×.×（×代表数字）如1
1．1．        并且容错输入单独标识出来。这样是不是会清晰些呢？并且我们给用户的测试用例只有正确的输入，这样也便于给用户时的测试用例的整理。

（5）
您的用例中有的谈的数据库时，说明“所填信息保存到相应的数据库表中”。我们作系统测试，根本不接触到数据库。只知道界面提供：提交成功的提示信息。那么我有怎能说数据写到数据库了呢？难道我们必须到数据库中去查吗？
不知道我提出的这些意见有没有道理？请赐教！

[ Last edited by greenhouse on 2004-8-18 at 09:28 ]

daoyu1981

结合自己的实际做修改吧!笨!
谢啦斑竹

smartbaby

不好意思啊，最近拔牙，比较痛苦，今天才看到各位的讨论～我就对每个人的问题一一解答好了～

smartbaby

archonwang
最好能制定三方共识（开发人员可以接受，用户可以简单掌握，测试人员可以通过）。这对测试工作的开展有较好的辅助作用。
对这个问题，我们是可以通过测试用例编写时与需求设计人员的沟通，测试用例编写后与需求设计人员、开发人员的评审来确定的。因此不会有开发人员不认同、需求（用户）不接受的情况发生。