为什么要写测试用例

paopaotang

模拟面试的时候，老师问我为什么要写测试用例。我很茫然的回答了一些似沾边但又不是很准确的原因：使用最有效的测试用例，以保证测试质量。使用例文档化，便于某些缺陷重现。
也不知道这样说对不对，还有没有要补充的？

limengyun326

那就补充一条吧
设计测试用例和执行测试用例的人员并非一定为同一人
写用例也是为了让执行人员能知道如何去测试

baizhudan

防止漏测，更有效的估算测试时间和完成度。情况紧急的时候有选择的测试。

v_v

为什么要写测试用例。。。
我想也就是测试用例的设计目的了。个人理解测试用例就是用来帮你理顺测试思路、有效的组织测试执行过程、达到用尽可能少的时间和成本,去发现尽可能多的bug,使测试尽可能完善,达到一种高效率的测试。  sdlkfj5 sdlkfj5

yqx

为了更好的管理，更好的标准执行，后期的跟踪，以后版本回归测试的依据

namedxf

我想测试用例也是具体化测试的对象，测试的方法，组织测试的进程吧

leixiao

我感觉写测试用例，最主要是为 了知道测试执行。

leixiao

不好意思，写错了，应该是指导测试执行

wangxiu836

还想到一个就是减少风险吧,如果测试人员A测一个模块,如果他有事情或者跳槽的话,如果没有这些文档化的东西,别人都不知道测了什么,应该从何处下手再去测.这个也算是吧sdlkfj5

yinfeng920

我想是为了提高工作效率吧，如果一个软件测试执行的人不止一个的话有用例就能按照步骤来做防止重复劳动吧

1001

1.  你测试时总感觉思维很混乱，或者总感觉有些功能没有测到，而一些功能已经测过好几遍了，这样测试用例能够帮你理清头绪，进行比较系统的测试，不会有太多的重复，也不会让你的测试工作产生遗漏；
2. 在测试时间紧迫的情况下，你不知道要测什么，或者要先测试那些功能，测试用例这个时候就可以帮你分清重点，因为测试用例写完后一定要标重要程度和优先级，以防止在紧急的情况下有重点的工作。
3.   你积极的工作状态不能持续，这个时候测试用例又帮你一个大忙，因为测试用例上面操作步骤和预期结果都已经写好了，你根本不用思考，只需要照着上面做就行了。
4.  测试用例是你工作的见证，也是你每次测试以后向上级汇报的依据，有了测试用例，我知道我这次测试了那些功能，还有那些功能没有测到，对上级是一个交代，也做到了自己心中有数。
5.测试用例可以记录你的灵感。如果灵感突发，有一个新颖的测试思路，你可以写成测试用例，或许这个测试用例就是挽救整个软件的重大功臣。
6. 测试用例有助于不断的改进工作。因为通过测试用例，可以知道哪些测试用例测出Bug的机率比较大，还有那些测试用例需要改进，对我们以后工作的改进提供了依据。
7.将测试用例作为测试数据整理保存下来,可用于交流和数据共享.

泡泡糖

测试是讲究步骤的,思路的.不可能是盲目地想到什么就测什么,所以我们需要规范地写做用例
对自身而言,写用例能够帮助自己理清思路,把大脑思考的过程,也就是你想怎么测试的一个过程,具体的写下来;
对别人来说,在阅读你写的用例时,至少了解了你的测试思路,测试的方向是什么,测试的目的是什么,面对这些用例并能更好地进行思考和补充,防止类似的测试重复做或者某些方面没未考虑到等等这些情况发生.
对公司来说,写用例也是你工作的一个见证,也是对上级的交代,对交接时候同事的交代,所以必须做到规范的文档化.
对于客户来说,则能向他们保证经过用例测试过的地方不会出错.
以上这些只是规范地把用例写下来的好处吧.
  当然啦,用例本身就是为了拿来测试软件的,但是经历有限,不可能把所有的数据都输进去测,只能考虑各种可能出错的情况来进行有目的性的,针对性的测试,而每一种情况也只能选代表性的数据,因此才有了用例,为了保证对软件测试的覆盖率,为了保证测试用例的有效执行,从而保证软件的质量.

getfly

是你测试执行的依据，而且还能知道什么时候测试要结束

47119986

设计用例在于明确验证需求（功能）的输入数据和步骤，书面化便于重现BUG，另一方面用于回归测试。无论ISO9000还是CMM都要求做任何事情要有记录、书面文档。如果不设计用例，那是随机测试，很难度量是否做的完全。

冰淇淋

写测试用例，是按照测试流程规范进行，有测试用例可以使测试执行思路清楚，有轻重缓急之分，有利于缺陷重现查找，有利于测试统计和总结。

linlinxu

Why do we write Test Cases?

Writing Test Cases as almost the only widely accepted and QC-specific idea/technique are object of my wonder since I started in testing field. Now after almost 10 years I have at last some understanding about it. Today I could say that I am advocate of exploratory testing, but I was actually even before I learned the term and idea. And still writing TC makes sense in a lot of cases, it is just wrong to believe that it is the silver bullet in any context.

Last year I compared Test Cases with shield and testing itself with a sword . I still believe Test Case creating could have two purposes/goals:
1) Test Cases are supposed part of the deliverable to the customer. TC goal credibility in this case. Typically UAT (acceptance) level.
2) Test Cases are for team internal use only. Typically System level testing. Testing efficiency should the goal in this case. The idea is to write test cases based on design while code is incomplete, so that we could test product quickly once the code is ready.
With moving to more agile development the second case begin to fail. I’ve seen this happening in my company and posts about this happening in other companies as well. It appears this ends up in one of the following ways:
a) TC are used internally, but the goal is credibility, not efficiency. It also means that TC are dramatically reworked during test execution
b) Exploratory type testing take place, only specific regression TC are written during exploratory testing or afterwards
c) Exploratory type testing take place, no TC written
I will not investigate further type a) as it is simple evidence of weak test manager – he was unable to convince management that this is ineffective usage or this resources. There are also sometime test cases created only to have something to report test progress against. Like we have 80% of test cases written and 70% of them pass. I have already attacked this approach and will in future as much as possible. This is most typical mistake to measure quality in number of defects open and test progress in numbers of test cases, I suggest everyone to read James Bach to learn why.
Cases b) and c) are both OK and depend on either we will need reusable test cases. To be true I believe that regression tests cases written and automated test scripts written have a lot in common. I would even say there are three levels:
I Pure exploratory testing
II Executing the test case written
III Executing automated test script
The design time increases from up (I suppose 0 for exploratory tests) to down, while test execution time decreases. However the scope of defects to be found also decreases, because automated tests for example will only validate what you scripted to validate, that means you should forecast what the defects may appear. While during manual testing you may see the indirect evidence of some defect. More over, the more detailed test case is, the more times one tester have executed it already (and as a result runs it faster now), the less probably he will find those indirect validation problems.

So much theory, now a little bit of practice. What I do in new project is following:
First of all I find any UI automation for the first release of product to be useless. This may be different for one-release projects, but I don’t have experience with those. Of course unit tests like JUnit executing specific API functions makes sense and are ideally created by developers, but sometimes testers may help with that.
Next I don't write ANY tests cases any more during testing cycle. I only update Test Plan that at the end of release has a very detailed "features tested" list with some hints and notes about features not working and bug IDs. Just after the release I do create test cases document details on how to invoke each feature, what input is expected by the feature etc. It is little bit like documentation, but have different goal/approach: goal is to make regression test execution as fast as possible – e.g. I attach data to be imported as much as possible to reduce data preparation time and I don’t care to describe why I use exactly such data – have no time; I explain in details how to do perform the most trivial use case, tester (unless newbie) may add details such as error handling using brains.

I try to use Testing Dashboard as replacement for formal test report with test cases executed/passed/failed/no executed. Sometimes I just communicate progress informally as my “gut-feeling”, and this is actually what PM wants to know, not the numbers of test cases.

yu_xiulan

排除测试时的随意性呀

Roseli

对前人的分析我试着总结了一下,又加以补充,不知是否完善,大家共享一下吧.

1、        测试用例指导测试执行，是软件测试必须遵守的准则，保证软件测试质量。
2、        测试用例可以帮助测试人员理清思路，以免出现漏测，也不会有太多的重复。
3、        测试用例必须标明重要级别，这样可以根据重要程度和优先级，分清轻重缓急，在紧急的情况下有重点工作。
4、        测试用例文档化，便于某些缺陷重现，同时也是各版本的回归测试的基础。
5、        测试用例规程，使得前一个用例执行完之后，系统的状态恰好是后一用例执行所需要的前置状态，以提高效率。
6、        测试用例具有复用性，具有业务逻辑的用例之间可以调用。
7、        分析总结特定测试用例测出Bug的机率，对于工作的改进提供了依据。

aileen2008

测试用例让公司的流程规范下来，一般公司写测试用例的和执行的不是一个人，都是交互式执行的，有了测试用例可以更好的进行交流。测试用例的写作有的不是一天就可以写好的，有了测试用例可以让人可以更好的继续前面的工作，也可以时时看到以前写的测试用例，发现一些不足，进行改进。如果有的公司人员更换比较频繁，那有了文档的话，也有助于后面的人开展以前的工作。
    测试用例的编写还有助于做回归测试。

[ 本帖最后由 aileen2008 于 2007-10-22 13:36 编辑 ]

january

（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。