转：编写测试用例方法心得体会！

李丽君

软件测试工作者

广东籍贯的海南人，在北京发展

联系方式：

邮箱：

llj2003hbdd@163.com

来源：http://www.blogjava.net/lijun_li/archive/2005/10/16/15639.html

编写背景：

一直以来都不太想把技术方面的文章写出来给大家看，一个是怕写作功底不好误导哪些刚入门的测试同行，自己的表达能力有限，另一方面怕有的同行拿出去炒作，再者测试网站论坛上关于测试用例的资料已经实在是多。但是看到同行纷纷都在问我测试用例的问题，都很想知道我写测试用例的心得体会。我就抱着试试看的心态写写吧，希望测试的老前辈看见了，可以给我多提提建议。

　　　　　　　　　　编写测试用例方法心得体会

在我的个人邮箱和MSN上，通常同行都问我类似下面这样的问题：

１、一个测试用例要写到什么程度才比较好?

２、刚开始做测试的时候，你是怎么学习写测试用例的？

３、你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？

对于测试用例，而我目前正在思考的问题是：怎么写出对公司有价值的测试用例，对公司来说，怎么测试才是最有价值的测试？

下面先来分析第一个问题吧：一个测试用例要写到什么程度才比较好？

这个问题，没有定语，没有说是在什么样的一个情况下，因此我这里只能就我工作中碰到的情况说说了。说起来比较长阿，大家要有耐心看才行哈。^_^

在我测试工作中，碰上的测试类型我自己划分成这么４种：项目的测试，产品的测试，产品个性化的测试，第三方验收测试。项目的测试指的是我所测试的软件是一个项目，是某一个具体用户使用的。产品的测试指的是我所测试的软件是一个通用产品，是供很多用户使用的。产品个性化测试指的是我所测试的软件是某一用户在使用产品时，提出了特殊的功能，针对这些新功能，对产品针对用户进行了个别修改。第三方验收测试大家都应该很熟悉了，这里就不需要做解释了。

对项目、产品的测试，测试的时候通常要考虑这个项目的周期和测试资源。我所在的公司，通常项目开发时间都很短４到５个月，然而测试通常都是在开发即将结束的时候才真正介入。测试就是１个人负责。因此时间和人力资源对测试来说是完成测试工作的一个风险。为此在这种情况下，我都是先熟悉系统的业务，把握重点业务和功能后，参考需求，把测试需求、测试计划和测试大纲给制定好。由于时间关系，测试用例都是先写重点的业务，也就是集成测试的测试用例。另外测试用例是根据测试大纲来的。通常都是先挑最重要的测试项和风险大的业务功能编写测试用例。由于测试用例是本人执行，所以测试用例可以写的简单些，但是一定要开发人员能够看明白。可惜我所在的公司，都没有人来看我的测试用例。测试用例对我来说是用来提示我不要忘记了要测试哪些项。一些很有价值的ｂｕｇ通常不是在写测试用例的时候发现的，而是在测试软件的过程中，我在家睡觉前的思考和回家的路上思考出来的。这就是手动测试的魅力，有些软件的缺陷是在你使用软件的一瞬间和思考的一刹那突然发现的。所以要我回答测试用例要写到什么程度才比较好，我觉的只要你所写的测试用例在你的公司能够顺利的执行，不影响你的测试执行工作就可以了。因为测试用例写的太详细，你要花费时间和人力成本，这样出来的测试用例是最好的也是最贵的，一旦需求变更，也需要修改，这时你会发现这种详细的测试用例是最不挣钱的。测试用例写的太粗，别人看不懂，不能执行，那你要花费你的时间去解释，这就加大了测试的工作量。这也不是好的方法。

第二个问题，刚开始做测试的时候，你是怎么学习写测试用例的？

我之所以选择测试这个工作是因为：我毕业后，在第一家公司做技术支持，产品的问题很多，导致技术支持工作很辛苦、很累。为了让用户买到的产品的质量是好的，我选择了做测试，到了现在的公司。我刚做测试的时候，对测试一无所知，什么测试流程阿、文档阿都不知道，公司的测试和管理也不规范。对测试，大家都认为不就是拿个鼠标点来点去，谁都可以来做。为此，我经常上网查测试的资料，看看自己到底适合不适合做测试，测试到底是什么样的一个职业，怎么去规划自己的个人发展。其实要做好测试，真是不容易。不喜欢，真是不能做这个职业。

现在想想自己刚开始写测试用例的时候，真是好笑。就像小孩子学习写字一样。先是在网上狂搜索了一把测试用例的模板，综合了几个，就形成了。我之所以不用公司原有的测试用例模板，是因为太不适用了。还好，公司没有严格要求必须要那个模板，只要适用就行。模板找好了，可是写就费劲了。对于刚做测试的新人，看似简单的一个填表工作，要写好真是不简单。一开始写的比较不自然，有些生搬硬套，而且还很慢。没有办法，那时候没有人指导我，全靠自己自学和领悟，所以那段日子很苦阿！多写几次后，就知道和领悟了，测试用例要根据测试大纲来写，测试大纲要根据测试计划来写。测试大纲更多的是把握住测试项的方向，而测试用例是指导怎么去执行测试。还好，我有编程的经验，所以对我熟悉软件帮了一个很大的忙。熟悉了软件的业务才能去写测试用例，才能更好的去测试。这也是我一点一点的领悟出来的。说了这么多，不知道这样的回答是否是回答了这个问题。

最后一个问题了，我尽量少写些，文字太多了大家看的也累，我写的也累。嘿嘿。^_^

你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？

我的体会：

１、测试用例要根据测试大纲来编写

２、测试用例也要分测试项进行归类，这样比较好分析和阅读。如：业务流程测试、安装测试、功能测试、用户友好性测试、兼容性测试、性能测试、安全性测试等等。

３、编写测试用例要考虑各种情况，精力主要集中在软件的主要业务流程和风险高的地方。能分出测试优先级别就最好了。

４、熟悉系统，对编写测试用例很有帮助。

５、即使对测试很熟悉了，在时间非常紧的时候，编写测试用例还是很有必要和好处的。

今天就想到那么些了，以后想到了在补充上了。我把我用的模板给你们粘贴一份上来，只能给你们做些参考，具体还是要看对你所在的公司适用不适用。测试项的归类我就不列举了，因为每个公司的都不太一样。

项目/软件		程序版本		功能模块名		编制人
用例编号		编制时间		相关的用例
功能特性
测试目的
预置条件
测试项	操作描述	测试数据	期望结果	测试结果
测试人员		开发人员

posted on 2005-10-16 15:08 lijun 阅读(3331) 评论(26) 编辑 收藏 所属分类: 我的测试工作历程

评论:

# re: 编写测试用例方法心得体会！ SpiderMan Posted @ 2005-10-26 09:37

总结的非常好。非常赞同您的观点。

用例应该结合实际情况来设计，各个公司的开发流程、产品或项目特点不同，对用例的编写有很大的影响；另外，开发流程的不规范和各种资源的不充分，对用例设计也有较大制约，需要采取合适的策略。

从整个测试过程的角度来说，设计用例是一个步骤，不是孤立的，编写用例前更需要对需求的充分理解、对测试对象的详细分析，在此基础上，实际上编写用例更多时候可以采用一种简化的用例编写方式，仅描述其所属功能、简要标题或测试点、测试类型、预期结果、需要关注的地方，对于测试目的、具体的操作步骤 就可以简化了。从这种角度来说，更加侧重关注于 测试用例对需求的覆盖、关注各种测试类型都被设计的充分性。

呵呵，也许这是一种比较偷懒的做法，但是有时会比较有效。 回复 更多评论

# SpiderMan 你说的很对阿！ 李丽君 Posted @ 2005-11-02 18:12

to SpiderMan ：

很开心看到你的留言，希望以后有时间能多多交流经验！：） 回复 更多评论

# re: 编写测试用例方法心得体会！ goldfeng Posted @ 2005-11-07 13:52

看了你的文章，收获挺大啊。

我正开始从事测试行业， 已经做了三年的开发了。现在什么测试大纲啊、计划啊、案例啊，可能都是由我先做模板出来了。而且手下没人，呵呵。

觉得这个工作要做好蛮难的，希望以后多交流。

MSN/Email：smartgoldfeng@sina.com 回复 更多评论

# re: 看了你的文章，收获挺大啊！ 李丽君 Posted @ 2005-11-14 18:03

to goldfeng:

很开心，我的文章会对你有用。

希望你会喜欢测试这个职业，祝愿你在测试这个职业有好的发展。

有什么问题，都可以提出来，发到我的这个邮箱：llj2003hbdd@163.com。

有机会多多交流。 回复 更多评论

# re: 编写测试用例方法心得体会！ juzi Posted @ 2005-11-24 10:10

你好！

很感谢你的文章！

我今年毕业，刚来这家小公司做测试，才一个月，没什么经验，只有一个感觉，就是无从下手。也是每天在网上找测试之类的文章、到测试论坛看，但还是觉得很空！呵呵，今天看到你说的觉得有一点“亮光”了，不过大纲之类的还不知道怎么写，只是有一个概念。我想这需要在实际中锻炼才会知道吧！

我记下了你的邮箱和MSN，希望我们多交流，呵呵！

祝工作顺利！

回复 更多评论

# re: 编写测试用例方法心得体会！ 李丽君 Posted @ 2005-12-13 09:03

to juzi：

嘿嘿，好好加油，有空多交流！ 回复 更多评论

# re: 编写测试用例方法心得体会！ 二月 Posted @ 2006-02-08 14:09

我想请问一下，测试文档如何写？

我也是刚从事这一行业的，到现在我还不知道无从下手。 回复 更多评论

# re: 编写测试用例方法心得体会！ yang Posted @ 2006-02-13 15:17

不好意思，想请问一下，有关于安全测试和压力测试之类的文档模版吗

用户希望我们开发小组提供这些测试报告，但公司和网上都找不到这类资源

能否提供相关的文档经验和建议呢 回复 更多评论

# re: 测试文档如何写？ 李丽君 Posted @ 2006-02-14 13:20

to 二月：

具体的我已经给你回复过了，好好加油，祝你好运阿！:)

to yang:

你的问题我也已经给你回复过了,好好加油,也祝你好运啊,别忘了我去上海,你要请吃饭哈.:) 回复 更多评论

# re: 编写测试用例方法心得体会！ yushui213 Posted @ 2006-03-06 17:00

我是个刚想做点测试方面的工作，很高兴看到您的文章

给了我不少的提示，谢谢啊

回复 更多评论

# re: 编写测试用例方法心得体会！ cty Posted @ 2006-03-08 16:53

我今年毕业，刚来这家小公司做测试，根本就不知道何为测试，经过十五天的理论学习，只懂了个大概。今日误入此处，深得丽君心得体会，庆幸，庆幸，祖上有德得遇善人点拨，否则不知道要走多少冤枉路。不过我做事没条理，不像你写文章条理都很清楚的。是不是女孩子做事比较仔细耶，我们测试组都是女孩子，就我一个男的，做不好我怕会很难堪的。还有刚到公司没几天领导就开会，重点提到的是要是在客户那里发现一级bug就扣两百快，怕怕，测试我都还没真入行就谈这个，我都有点想退却。不过看了你的成长过程，到给了我不少鼓励，我要借鉴你成功的经验前进，肯定不错的。写到这里我回头一看好象写的又没条理，晕，不管了。提交。等等，除了上面的两个联系方式最好再弄个qq 很感谢你，希望有时间以后能够多多指导小弟 回复 更多评论

# re: 给了我不少的提示！ 李丽君 Posted @ 2006-03-17 09:09

to yushui213:

欢迎你加入测试这个行业，希望你会喜欢上测试！祝你好运。 回复 更多评论

# re: 是不是女孩子做事比较仔细！ 李丽君 Posted @ 2006-03-17 09:19

to cty:

很高兴我的文章能给你带来那么大的帮助。

看了你的留言，想对你说些话。

1、测试工作需要理论结合实际，需要根据具体情况进行分析。

2、做事要想清楚了，要有清晰的思维，如果没有，自己学习培养自己这个能力。

3、测试工作没有性别区分，是否能做好测试工作和个人能力、性格、心态有关。

4、每个人都不是不会犯错误，都不是全能，要用正确的心态看待自己的弱点。

5、关于你们公司的管理体制，只要你认可或可以忍受，就一定要用积极的心态去 做测试。

6、祝愿你的测试工作顺利，并从中找到乐趣和收获。 回复 更多评论

# re: 编写测试用例方法心得体会！ 测试用例要根据测试大纲来写，测试大纲要根据测试计划来写？？ Posted @ 2006-04-03 14:49

”测试用例要根据测试大纲来写，测试大纲要根据测试计划来写“，不清楚这里的测试大纲是什么意思？是测试需求吗？如果是的话，至少要参考“软件需求”，而以测试计划为依据是不够的。 回复 更多评论

# re: 编写测试用例方法心得体会！ taotao Posted @ 2006-04-07 15:11

看了之后，感觉很有 共鸣，有时间一起探讨一下。msn：taotao1225@hotmail.com 回复 更多评论

# re: 不清楚这里的测试大纲是什么意思？ 李丽君 Posted @ 2006-04-18 13:20

to 这位没有留下称呼的阅读者:

在你的留言中,你问我"不清楚这里的测试大纲是什么意思？"

我这里说的"测试大纲"是对测试计划中测试项的进一步详细描述,不是软件需求.当碰到一个很复杂的软件测试时,我需要编写测试大纲指导我去正确有效的编写测试用例.

你说的很正确,测试是要参考"软件需求"的,只有先把测试的对象(主要目标方向)把握住了,也就是把需求实现的验证测试做好了,在进行下一步的功能测试才是有意义的,虽然功能实现的没有问题,但是不满足用户需求.从开发的开始就出现了问题. 回复 更多评论

# re: 编写测试用例方法心得体会！ morose Posted @ 2006-05-09 16:26

我很同意你的说法，总结得太好了。我也是新加入到这行的。现在感觉海星不是很难，我有过oracle数据库的经验。

回复 更多评论

# re: 编写测试用例方法心得体会！ 李丽君 Posted @ 2006-06-02 16:39

to morose:

祝你好运！ 回复 更多评论

# re: 编写测试用例方法心得体会！ leader Posted @ 2006-10-17 23:40

受益匪浅呀！很高兴在这里认识这么多测试同仁！有机会多交流！ 回复 更多评论

# re: 编写测试用例方法心得体会！ leader Posted @ 2006-10-17 23:41

MSN:lidetao@hotmail.com 回复 更多评论

# re: 编写测试用例方法心得体会！ leader Posted @ 2006-10-17 23:42

不好意思，灌水了！应该是

MSN:lidetao2008@hotmail.com

想交个朋友的加我！ 回复 更多评论

# re: 有机会多交流！ 李丽君 Posted @ 2006-11-06 12:06

to leader:

你好，希望你也喜欢测试这个职业，祝你好运！！！！ 回复 更多评论

# re: 编写测试用例方法心得体会！ ShaLongBus Posted @ 2006-12-29 21:07

写地不错，一起加油！

个人觉地，编写测试用例，最难地是测试数据的构造，是测试设计的核心。

你这个模板可以再加几项，会比较完整：

1. 优先级:测试用例的优先级

2. 测试执行日期，什么时候执行过該用例？

3. Pass/Fail:测试用例执行时，有没有通过?

4. 用例版本，标志用例修订次数

回复 更多评论

# re: 编写测试用例方法心得体会！ Leo[匿名] Posted @ 2007-01-01 23:32

总结地很不错,条理也很清楚

测试用例的编写有2个原则很重要:

1. 能够被后面的项目尽可能多的重复利用

2. 让测试人员看了用例后知道测试的基本步骤,Expected Result和重要的Check Point

所以一般测试用例只需要写出一个测试项70%的内容即可,还有30%就需要考验测试人员的水平了,就象你写到的有时候凭灵光一现的想法发现软件的bug是测试最具魅力的地方,而这又是可遇而不可求的,一个没有想像力的人是做不好测试的

另外为了最大限度的节约人力成本的支出,将很多共性的内容写到一些特定文档里,在测试条例里引用这些文档也是个不错的方法

其实测试条例不光内容的编写很重要,它的测试编号也很有讲究,当你的测试库达到一定规模的时候,怎样通过测试编号来迅速找到你要的测试用例也是体现效率的一个标准,这在一开始规划的时候就要想好

最后因为看到你的文章被人盗用了,很理解你的感受和想法,但是希望你不要太受影响,以后还能够在这个论坛继续看到你的文章,让大家继续分享你的测试人生,加油啊! 回复 更多评论

# re: 编写测试用例方法心得体会！ worm Posted @ 2008-01-03 09:25

不错啊，写太长也没关系啊，只要写的精，就可以了 回复 更多评论

# re: 编写测试用例方法心得体会！ wangyaling Posted @ 2008-03-28 11:21

收益受益 回复 更多评论