编写测试用例的目的，讨论！
最近，同事都为写测试用例发愁，从而引发了一个问题：为什么要写测试用例啊？对于功能测试用例，只是针对项目的需求，是不是很浪费的这样写来写去，既浪费时间又没有什么实际意义。对于这样的问题，我也茫然了。后看了很多资料，也没有弄明白个所以然。请各位高手大虾来给点迷津吧！！！ 问题点数：50、回复次数：16Top
1 楼scalene（南瓜汤）回复于 2003-11-04 18:46:01 得分 25
测试用例——体现软件的开发目标和可接受条件。对于测试驱动的开发模式来说，programmer认为测试用例是软件设计的一种实际体现。Top
2 楼rubyliu2004（liufulian）回复于 2003-11-05 08:30:09 得分 0
说的好！我再看看有没有其他的看法。然后，就给分！！！谢谢！Top
3 楼simman（mosen莫森）回复于 2003-11-05 08:52:28 得分 10
设计用例在于明确验证需求（功能）的输入数据和步骤，书面化便于重现BUG，另一方面用于回归测试。无论ISO9000还是CMM都要求做任何事情要有记录、书面文档。如果不设计用例，那是随机测试，很难度量是否做的完全。Top
4 楼rubyliu2004（liufulian）回复于 2003-11-05 09:13:42 得分 0
我们这里的程序员都认为测试用例不应该写的，因为我们公司的测试用例，不是测试驱动，我们还没有用自动化测试工具，还是有开发人员写的！这样的情况下，我们就不明确了，究竟写测试用例的目的是什么了！？
请给点迷津吧！！：）Top
5 楼futuredreams（鱼儿）回复于 2003-11-05 09:16:54 得分 5
对于开发和测试的沟通，一个是指明测试的方向，和文档的规范，bug可以接受的描述方法和用词，bug的分类，一个好的测试用例可以在开发和测试以及其他阅读此case的部门人员建起桥梁并传递很多信息。Top
6 楼scalene（南瓜汤）回复于 2003-11-05 11:49:30 得分 0
测试用例主要来自三个方面：
1.设计文档中的USE CASE。将设计文档中的Use Case按照步骤纪录下来，可以用于软件的可接受性测试。
2.按照界面功能区或者系统功能模块，按照用户可能的操作，分块或跨模块，形成系统的功能性测试（可能包括Normal-通常操作，Exceptional-异常操作，Boundary-边界测试）。
3.将曾经发生过的Bug纪录下来，形成测试用例，可以成为Regression Testing的一部分。
测试用例不一定要求自动化测试，但不应当由开发人员书写。
开发人员参与测试的主要方式应该是书写Unit Test。Top
7 楼rubyliu2004（liufulian）回复于 2003-11-06 08:42:28 得分 0
今天晚上之前给分！
再讨论一天！！
多谢！！！
不好意思：to scalene（南瓜汤）那个Regression Testing 是不是回归测试的意思啊？Top
8 楼ericzhangali（另一个空间）回复于 2003-11-06 10:12:46 得分 10
看了楼上几位的回答，似乎有些偏离楼主的问题。
俺不懂什么大道理，只能俗话俗说，谈谈体会。
设计编写测试用例是一件很费时间精力的事，所以QT总是不太愿意写的，而RD对这个东西也是排斥的，因为这个东西要挑他们的刺。
不知道楼主碰到的问题和俺这里是不是相仿，俺们这里一个接一个的项目，只是不同的客户，区别只在最上层的UI不同，下面的LIB层，API层，中间件层，两层驱动，HAL，OSAL层都一样。而case的来源很大部分是客户的SPEC，case大部分是从用户的角度，按操作的过程来写的。这样，换一个客户，虽然只是UI不同，但验证类似的功能可能操作过程完全不同。case要重写，工作量很大。
由此也萌生过和楼主及其同事一样的念头。
经认真考虑，结论是case肯定要写，变通办法是抽象出一些共同特性，对一类产品写一份公用的。
具体执行时根据情况确定是否需要生成一份针对性的文档。
Top
9 楼ericzhangali（另一个空间）回复于 2003-11-06 10:14:49 得分 0
其实际意义在于有一个执行的准则，有一个评估的标准。Top
10 楼scalene（南瓜汤）回复于 2003-11-06 18:55:02 得分 0
To ericzhangali(卖女孩的小火柴——五毛钱俩一块钱不卖):
我说的不是什么大道理，而是我们测试的实际做法。
不过我一向做产品比较多。产品中成熟的设计、结构比较多，和你说的情况可能有很大不同。
项目开发中比较完善的Unit Test, 系统的功能测试和回归测试可能比较困难一些，我觉得针对Use Case的测试可能会比较重要。
此外，在项目接近完成的阶段，对于已发现的Bug的回归测试可能比较实际一些。
Unit Test对于项目开发，尤其是Web应用，如果没有比较好的测试制度和测试习惯，可能会非常困难（Server端的测试相对容易一些，但客户端的测试，我还不知道有什么比较好的自动化测试工具）。
Case是否要写，以及写到什么深度，应该和项目的规模，测试人员的素质，都有比较大的关系。其实最大的开销应该是设计Case的过程。对于不太复杂的功能模块，将Case完成的过程（Unit Test, 功能测试，以及针对Use Case的测试）一般已经测试出了软件中现有80%以上的Bug。以后的回归测试则效果则一般仅仅会发现极少的Bug（对于模块划分比较清楚的系统，可能只需要在进行了重要改动时和之后才需要进行）。
对于某些程序，压力测试和性能测试也是非常重要的。
了解各种测试方式的效果，以及他们的代价，对于测试人员合理的制定测试计划，安排测试任务，应该说非常的重要。质量要求越高的产品，测试的重要性越大，要求测试流程应该越规范。
Top
11 楼scalene（南瓜汤）回复于 2003-11-06 19:39:02 得分 0
To ericzhangali(卖女孩的小火柴——五毛钱俩一块钱不卖):
补充两点：
一、对于不同的功能模块，其测试的重点往往是不同的，某些模块侧重UI，某些模块侧重性能和压力测试，某些模块侧重逻辑的正确性，...
二、对于你说的“区别只在最上层的UI不同，下面的LIB层，API层，中间件层，两层驱动，HAL，OSAL层都一样”的情况，如果是BS结构，实现自动化测试可能是比较容易的（某些情况）。可以把用户的操作看作是一系列的http请求和答复过程，采用HttpUnit之类的软件。录制过程时，在客户端按步骤操作，在服务器端纪录其请求url串和返回页面，验证返回页面正确性，记录在测试时需要验证的项。在自动化测试过程时，通过程序向服务器端顺序发送所纪录下的请求串，通过将接受的返回页面和记录下的返回页面比较，验证程序是否执行正确。
这种方法，测试程序应该是通用的；录制程序是在你的Server端程序上简单修改封装即可。
在界面发生较大变化的时候，则需要重新录制。Top
12 楼doudou536（小豆冰棍）回复于 2003-11-06 21:01:49 得分 0
老大，这个还用讨论一下吗？
做测试就是要覆盖软件的需求，为了这个目的
我们写测试用例！Top
13 楼rubyliu2004（liufulian）回复于 2003-11-07 08:43:50 得分 0
to ericzhangali(卖女孩的小火柴——五毛钱俩一块钱不卖):
呵呵，你说的和我这里还不是很一样。我们主要开发的是外包的，基本都是个性化的。
对不起，大家了，我昨天着急了。没有来得及散分，这里给大家道歉了！；）
Top
14 楼ericzhangali（另一个空间）回复于 2003-11-07 09:13:16 得分 0
南瓜汤 吐 了我两段， ：） 可看下来没觉得有多少话像是说给我听的。
尤其是第一段不明白，第二段好象有点针对性。
先说一下，我前面描述的不是什么BS结构的WEB项目。关于自动测试我用过Rational Robot，第二段里说的那些步骤和Robot好象没什么区别，类似的工具我只喜欢Rational的，虽然贵。
看下来，确实不知道我的哪些观点和南瓜汤不一样。 ：）
也吐楼主一下，我们的开发就是给客户定制个性化的需求，其个性化90%体现在UI上，所以，底下的东西我们做主了。不知道理解上是否有偏差。但不管是什么，再次回答你的问题，测试用例是肯定要设计的，否则没有执行的准则和评估的标准。
Top
15 楼scalene（南瓜汤）回复于 2003-11-07 10:42:01 得分 0
我的贴子只是对你提出的一些问题的一些回答，并不是想说明你的说法中有哪些错误。
第一个回贴是针对你所说的写case工作量很大的提法，我想应该是如何合理制定Test Plan的问题。针对不同项目、模块的特点，有很多可以选择的测试重点和测试手段。
并且我认为写Test Case需要花费大量精力是一个正常现象。因为这实际是你对于产品的需求和设计进行整理的过程。并且写Case的同时一般也会测试到产品的多数Feature。只有认真书写的Test Case才能持久生存下去。
第二个回贴是针对你们公司的一些特点，谈谈如果我来设计Test Plan我会把重点放在哪的问题。我假想你们是BS项目，因为这类项目更具有普遍性。也许对更多人有点用处。
另外，我想楼主所说的“主要开发的是外包的，基本都是个性化的”可能是指项目性质，和你所说的“UI的个性化”，差别应该还是很大的。Top
16 楼ericzhangali（另一个空间）回复于 2003-11-07 11:48:20 得分 0
我当然知道有差别，我只是觉得有共同点，我们不是在求同存异吗。
做外包，项目的性质可能都不一样，我们的项目性质都是一样的。
但相同的是，上一个和下一个有很大的区别，上一个的用例设计不便于应用到下一个，重复劳动比较多，这才会有异心，觉得写了好象没什么用。
我也假想楼主的问题，来了一个项目，学习，了解，熟悉，设计用例，花了几个月甚至更长的时间，比较完善了，也起到了相当的作用，抓出了不少bug，但以后的项目没有和这个相关或有类似的了，没有起到项目知识积累的作用，下一个项目，别的技术，别的结构等等，又要再开始上述步骤，是不是会觉得，这个东西花这么多时间，然后又扔在一边，心里不平衡呢。
但是我也说了，慎重考虑后的结论，只能是，方法上可以有变通，但用例是不可省略的。
看得出南瓜汤是很有测试管理经验的，愿交朋友吗？
ericzhangacer@sohu.com
Top
