test case 怎样才能做好了？？
hi大家好，我是新手，对于Test case 一点都不了解，而我们老大又要我弄这一项目，所以我想请各位高手教教我，让我向各位学习学习？？？谢谢，大家帮帮忙吧～～～～～～～～｀｀
回复 1# 的帖子
自我顶一下吧～～～～～～～(*^__^*) 嘻嘻……:loveliness: 先了解项目咯，然后再编写测试用例咯 不会吧，只有两步 首选的应该是从需求入手，如果你们项目的需求做的足够好的话。如果需求不行，就从系统入手。
1、列出全部的功能点和业务逻辑，比如：
a.申请的增加功能
b.申请的修改功能
c.申请的删除功能
d.申请的上报功能
A.已经上报的申请不能删除
2、拿着功能点和业务逻辑去找需求负责人评审，保证你整理的功能点也业务逻辑能够覆盖整个系统
3、将功能点和业务逻辑转化为case
4、进一步熟悉系统和测试过程中会发现新的思路，补充道用例中 上面说的方法不能保证你的 case 有多好，只能保证你的 case 比较全面，覆盖了系统。
我想 case 要做好，是一个慢慢积累的过程，测得东西多了，打开一个页面，你就有感觉，觉得哪里容易有问题；还要不断思考，你用2个小时去执行，执行完了，你静静地去看你执行过的页面，看看还有哪里你没考虑到；深入了解业务逻辑，功能测试还是对业务的了解，了解的越多，你想到操作业务的可能性越多，你的用例设计的越有深度。 哦哦，谢谢你的建议～～～～～～～～～thank you 当需求下来就可以写测试用例了，测试最好是根据测试用例来进行 需求来 小弟想來大大的老闆應該是要請大大做自動測試的test case吧…
坊間有書可以參考哦… 根据需求来挖掘测试点，可以用到以下几种用例的设计方法。流程分析，等价类，判定表，状态迁移等等。。。。~另外如果没有需求的话。你可以通过和开发交流，以及看看产品说明书等种种方法知道软件的一些业务知识和其功能 你公司有其他项目的测试用例可以参考吗？
另外测试用例是需要设计的，
一般一条测试用例包含如下内容：
测试用例编号测试项目测试标题重要级别预置条件输入操作步骤预期输出
设计测试用例的方法为：
等价类，边界值，判定表，因果图，流程分析法，正交实验法....
在需求分析阶段就可以进行系统测试的计划和系统测试用例的设计了
在概要设计阶段就可以进行集成测试的计划和集成测试用例的设计了
在详细设计阶段就可以进行单元测试的计划和单元测试用例的设计了
编码完成后，执行单元测试用例，到集成测试用例到系统测试用例。 TestCase的用法
TestCase类在整个JUnit框架中处于核心的地位。你可以在junit.framework包中发现TestCase这个类。在JUnit开发人员当中，甚至是在一些高级的程序员当中，都有一个疑惑，那就是测试用例（test case）和TestCase类之间的关系。事实上，这是个命名冲突问题。“测试用例”（test case）这个术语通常指的是单个的测试，通过编码来校验某个特定的行为。那么，将多个测试用例都收集到一个类中，这个类是TestCase的子类，而且每一个测试用例都被实现为TestCase类中的一个方法，这的确有些奇怪。既然这个类包含了多个测试用例（test case），那为什么把它叫成“TestCase”而不是叫做“测试集”之类的名字呢？
在这里我们给出最好的解释：虽然在编写测试的时候，你需要创建一个“TestCase”的子类，并把每个测试用例都实现为这个新类的方法；但是在运行的时候，每个测试用例都会被当作TestClass子类的一个实例来运行。使用面向对象的术语来说，每个测试用例都是一个TestCase的对象，因此，这个名字还是合适的。不过，一个TestCase包含了很多的测试，这的确引起了术语的疑惑。这也是为什么我们如此小心地区分一个测试用例（test case）和TestCase这个类：前者是单个的测试，而后者则包含了多个测试，每个测试都用不同的方法来实现。为了更清楚的区分这两个概念，我们不会再（尽量做到不再）使用测试用例（test case）这个术语。要么就用测试（test）这个词，要么就用”TestCase”这个类名。在这本书的后面，我们还会把这个“TestCase”类称为“固定器
页:
[1]
