分开这个问题，我想问楼主一下：TX是什么意思啊？
嘿嘿
见谅，偶见识少 ：）
TX=同学（Tong Xue）:d 我晕.............................................
py就是朋友了~~~~~~~
汗一下~~~~~~~~ 原帖由 冰河 于 2005-11-14 16:14 发表
我晕.............................................
py就是朋友了~~~~~~~
汗一下~~~~~~~~
PY偶倒是没听说呢！嘻嘻。。。。:p LZ(楼主)TX(同学)需要好好理解测试用例sdlkfj5
1个需求产生N个测试用例 本人觉的用例还是要写的啊！不是直接从需求中拷贝过来的，初期的测试用例可以是这样的，但是随着软件的完成，用例也应该逐步的完善。 测试用例的设计是整个软件测试工作的核心，测试用例反映队被测对象的质量要求，决定队测试对象的质量评估！ 测试用例是必不可少的文档，没有测试用例，测试过程中会失去测试方向，导致测试覆盖率低，影响项目质量。 科学的测试用例会很好的帮助测试的进行
测试用例与需求分析的文档区别应该说是相当大的sdlkfj2
需求分析一般只有正常的流通
而测试用例则需要有错误的流通
如果你知道边界值分析法，等价类划分法就用该知道测试用例与需求分析文档的区别了sdlkfj2 测试用例不仅要识别需求场景形成具体的case
并且有case的执行步骤
case的期望结果
需求也许只涵盖了场景
但却没告诉你验证方法
和基于验证方法的结果判断
另外还有一个很重要的问题
测试设计应该是最经济的测试实施的方案。
难道有100种排列组合
你直接按需求去测试
你挑哪20种组合具有代表性呢？ 测试用例要覆盖需求的正常事件,异常事件,还有需求中没有涉及到的潜在但隐含着的事件.
测试用例是必不可少的,如果真的如LZ所说的那样, 那要么是你们的需求做的非常细致, 要么是对测试用例存在理解上的偏差.
对于测试人员来说,不是取消用例的设计,而是要提高用例设计的水平,提高测试用例的质量. 大家都说得很好，学习了sdlkfj2 如果没有测试用例做回归测试比较困难 原帖由 白菜叶子 于 2007-1-31 17:17 发表
如果没有测试用例做回归测试比较困难
如果用例是你自己写的，那是因为你比较清楚该测试些什么?做回归测试的时候也许你就记得不太清楚了.我的意思是不光是做回归测试比较困难,要是有人员变动,接手人员也无法很快进入测试. 还可以让客户来写测试用例，来取代需求。这也是一种精益开发方法中的一点。
回复 #1 yy903 的帖子
其实这是由于测试工作分配不合理才造成你的误解.如果测试人员是由一个项目开始跟到结束,可能测试用例需要不大,但如果要在测试过程中插进新人手,在他学习业务的过程中,可以由测试用例进行测试并结合来学习.这也是用例的存在原因.
特别是没有参与需求,而需求文档不能面面俱到,很多功能点都会漏掉.在回归在最容易发现这点. 原帖由 ccc11yyy 于 2007-2-1 17:44 发表 http://bbs.51testing.com/images/common/back.gif
还可以让客户来写测试用例，来取代需求。这也是一种精益开发方法中的一点。
有多少客户懂测试。。。
写测试用例不只是对需求上的，另外总要考虑其他方面的吧，比方些异常 都说单元测试可以查出80%的BUG，可为啥还有人提出取消测试用例呢？
测试用例
1：以前每接一个项目，都会先写测试用例。发现写测试用例的好处就是对整个项目有个了解。但是每次写完测试用例后，由于测试时间很紧，所以就基本上没有按照已经写好的测试用例来执行测试了。到了执行测试的时候，都是想到哪就测到哪，这样发现BUG的速度还快得多。此时发现测试用例就是一堆没有用的废纸了。2：因为需求变得快，基本上是初步写完测试用例，以后就不会再对其进行维护了。但是如果遇到版本更新很快的项目且又没有测试用例时，则会在每次发布给客户版本之前的测试又是很不全面，软件质量就差了很多。所以现在的做法是，先写个大概的测试用例，就当是了解整个项目的测试需求了，当执行测试完后，利用空闲时间好好的整理，维护好测试用例，等到下一次版本更新的时候，就可以用整理好的测试用例了。 我公司的需求天天变更。。。。 学习了．
