时间过的真快，北京炎热的夏天开始了，在新公司工作已经有3个月了。

     有一天，和徒弟一起吃了顿饭，沟通了我们在新公司上班的感受，总觉的把我们的感受该记录下来，等那一天我们都老的时候，再回想我们的这次谈话，会有另一翻的回味。

     今天是周五，工作的环境空调坏了，非常的闷热，就要下班了，刚好写写blog放松心情。

                                                                 公司大小与测试是否规范无关

       这是我和徒弟分开后的第一次见面，大家都互相的想念和牵挂。饭还没有上，便各自聊起了在新公司的体会。

       徒弟在新的公司碰上了和我同样的现象：

1、同事都问到了这么个问题：你的上一个公司是？？？

      徒弟的同事会问这个问题，是因为它们从徒弟的一些工作风格、工作结果及思想，还有工作作风让它们感觉非常的正规，于是便想知道是哪个公司培养的，肯定是个大公司。

      我呢，有2个同事问了我这个问题，一个不知道是什么原因问的我，另一个同事也许是在我说出了如下的话问的我：

我把我做的每一个测试的东西当成是自己的一个宠物。

我的薪水是客户给我发的，只有我们的产品客户认可了，才会用公司的产品，公司才会挣钱。

2、和之前我们做事情相比，目标都不明确，具体表现：产品需求描述的不够明确和准确；工作的安排及要求不够清晰!

      提到这个我们彼此都笑了笑，大家在新的工作环境都不是很习惯，都在适应中。这就是在锻炼我们的适应能力；对于徒弟来说这点有些难度，毕竟她没有经历过。除此之外都很怀念我们以前的团队、工作氛围。

3、和之前我们做事情的工作量相比，工作效率都不高，具体表现：我们之前一个20个功能模块内的系统2个人配合1个星期就可以走1到2轮测试，而现在一个10个功能模块内的系统，3、4个人要测试2个星期甚至1个月。
      聊到这个现象我们又笑了笑。分析了一下原因：也许是我们之前的团队工作目标非常明确、工作计划制定的合理、工作执行非常努力。

      我们的领导21克 给我们的入职培训让我映像很深刻，他说过：我们是个创业中的公司，我们要像狼一样生存；我们是一个特种部队，目前公司不能提供给我们足够的人力资源，我们要想成功，每个人除了要做好自己的工作角色，还要可以互相监督和帮助，就比如我们在一起攻打一个山头，每个人拿着枪站在不同的角落，只要任何一个人松懈，其中的其它人就会有危险。

      又让我想起了，每次为了工作上的事情和21克发生争执时，21克给我的教导：以后在一起工作的时候，不要说你们，要说我们。测试和开发不要分你们、我们，我们是一个团队，只是分别担任不同的工作，但我们的目标都是一致的，只有我们的目的都是一致的，只有我们互相协助的，我们才能更快、更准确的完成我们的任务。

     写到这里好想有些文不对题了。嘿嘿。^_^

     每个公司都有不一样的管理模式、经营模式、用人模式，这样就会有不一样的结果。

      测试新手曾经问过我：去大公司做测试，肯定正规，这个是不一定的。公司大并不代表一定正规，公司小就不正规。测试的工作流程是否正规每个公司都有自己的规则，这个规则是领导定的，因此领导如果对测试不了解，那可想而知情况如何了，让我想起了袁林的MSN标题，好像是这么描述的：更深层的问题出现在管理当中。

      测试新手也曾经问过我这么个问题：黑盒测试没有技术含量，测试没有技术含量。每每想到这样的问题，就让我想起某位同行的一篇随笔：你为测试做了多少。

      黑盒测试有没有技术含量，主要还是看个人有没有去发现其中的宝贝，去领悟到做好黑盒测试有多难。一件事情，“做”和“做好”是不一样的；一件事情，因为“钱”去做和因为“喜欢”去做，结果是不一样。

      公司大也好，小也好，测试管理做的是否正规，最终取决于身在其中的每一个人。
     
很感恩老天爷让我从事了测试工作，让我从中学习到了、领悟到了很多美好的东西，这些东西可以在我老了以后留下美好的回忆。

编写背景：

     自从上次自己写的文章被转载没有说明出处，就打算停写 BLOG 半年， 7 月份再回到这里描述我测试工作上的一些感想。对于文章转载一事，我在公告栏中说的很清楚，允许转载，但请说明文章出处。

很感谢各位同行在 BLOG 上的留言，谢谢你们也喜欢我的 BLOG 。非常的感谢你们。

     也许是近一年半以来，工作上很开心也很有收获，老天爷也许是觉得我该再多一些磨难，让我再一次面对选择。所在的公司业务转型了，重心为：技术支持；我的好领导（我们团队的灵魂人物）在今天将辞职离开这个我们奋斗了 1 年多的团队，我的心情很伤感。在不久的时间里，我也将会离开这个团队，面对领导的离职、面对公司的转型、面对自己喜爱的测试职业、面对我的徒弟，思考了很多，大脑很累。累到我不得不到这里来述说，便有了这个随笔。

  很怀念过去一年多里，在这个团队工作开心的日子。

  公司虽然很小，虽然没有名气；

  我们做的项目不像大公司所说的工期是 1 年或 2 年，接的都是大型项目；

  我们都是所谓的小项目工期是 3 个月或 4 个月；

  但我们工作很认真、很负责、很严谨，力求完美和专业。

  在这个团队里工作很开心，很有成就感；

  团队的领导很重视软件质量，很重视测试；

  团队的管理很人性化，也很严格，这是我喜欢的一个工作环境和氛围。

  可惜这一切都即将消失，很是怀念和伤感阿！！！！！

   记得刚来时，管理和测试都不规范；经过 1 年多的奋斗，建立了测试组，并完善了测试工作流程；还带出了一个很好的徒弟；领导很认可我的工作；往回看，我们测试组的战绩很值得我们骄傲和自信。 ^_^ 。

   站在管理这个层次和角色上去看待测试这个职业，从中学习到了很多东西，开阔了思想。这一切将会成为我工作生涯中最美好的回忆。想一想，突然感觉，工作了这么几年，又回到了测试的原点。下一站将会如何，真是不知道，听老天爷安排吧！！！

   任何东西都不可能是十全十美的，只能是相对的；工作的道路也不可能是直直的，它也会有山坡，爬山的过程很辛苦、很辛苦，但爬到山顶看到下面的风景，感受爬的过程，是非常的开心；很可惜，老天爷总是不让人永远的停在这个山顶，总是催着你向前走。前方的道路如何，掌握在自己手中。祝福我的领导在将来的工作道路上能走的开心，也希望我能找到适合我的公司。

   今天写的随笔，思路比较乱，也许是今天的心情比较乱、也比较忧郁！！！！！

5 月份测试的一个项目由于需求变更频繁，修改新需求出了些小事故，一直很想记录这件事情，但由于 6 月份忙于找合租房子，就一直没有记录；如今回忆这个小事故，想记录记录，让我想起了收费系统；好快， 8 月份来了，今年的收费系统的性能能否经得住考验，心中有些牵挂。离开这个系统就快一年了，不知道它运行的好不好。

也许有的人认为用这个题目来形容测试工作有些夸张， ^_^ ，之所以会起这个题目，是因为我当时有这样的感觉。

回头看，事情是这样的，这个系统业务、功能不是很复杂（嘿嘿，对于我来说），但需求给的不够细（应该说用户不知道这个系统具体能帮他们实现什么，但是他们需要这样的系统来便于管理），等到系统做出来后，刚测试好，就马上要上线了。期待啊，这是大家的心血，加班那么多天赶出来的软件，就要开始用了，这是部门内所有成员的第一次合作成果。第一步的业务功能用的反馈效果还可以，用户提出的多是字面描述上的修改。第二步的业务功能在使用的前两周，用户突然提出了很多新需求，并且要求在短时间内修改好，不影响上线使用。

就这样在短时间内，在开发人员人力紧缺的情况下，解决这个新需求后的程序提交测试后，出现了很严重的问题。离上线的时间越来越近，开发人员、测试人员就像医生在手术室里抢救生命，过了用户的使用期，这个系统做的再好那也用不上了。终于在早上的凌晨，系统的严重问题都已经解决，可以顺利上线使用，身心很是疲惫，还好的是大家辛苦的付出，软件还是活过来了。

出现这样的现象，原因是：新需求的修改策略出现了失误，开发人员过分的修改了程序。这更一次提醒了我，工作一定要把握和认清楚自己的目的和范围，一定要做适用的工作计划；只有这样工作才是有效率的。对于领导安排的没有做过的高压力工作，可以接受，但是要提醒领导自己的能力和情况，不要对结果抱乐观，自己只能是全力以赴的去做。

做测试工作很累，因为要站在不同角色来思考和测试所开发的软件；站在技术支持人员的角色，就希望软件容易维护；站在用户角色，就希望功能使用简单、好用；站在测试人员的角色，就想知道这样的设计会出什么样的问题等等。除此之外还要想办法使用有效的方法快速测试软件。

做测试管理工作也很累，因为想要带好队伍，把队伍发展好、管理好；要做决策，要承担决策的风险；心里压力比较大。

其实干哪一行，想干好，都很累，为什么那么累了还一直充满热情的做下去，也许就是因为爱好，它能激发人本身所不知道的潜能。

编写背景：

工作所在的部门启用了新的绩效考核制度，也开始了我参与对测试人员的工作进行绩效考核这一管理活动，第一次的考核结果让我有很多的感想，因此今天把它记录下来，也许突然有一天回头看这一感想，又会是另外一份心情。

思考：给测试人员进行绩效考核的目的是什么？

经过思考，我总结的答案是：

1、  为了了解工作情况，如：工作进度、工作状态。

2、  对每个人的工作进行评比，夸奖好的，批评差的。这个看起来有点像在学校上学时候的考试。

思考：有了这样的绩效考核目的，要用什么样的方式、方法去实现呢？

怎么样的绩效考核方式是最有效的呢？

对于现在的我，在现在这个小公司要想做好这个绩效考核，真是要好好思考。

1、  不同的工种，不能用同一种考核方式。如：测试人员的考核方式就不能和开发人员的考核方式相同。

2、  不同工种的考核结果是没有可比性的。如：测试人员的考核结果和开发人员的考核结果进行对比是没有意义的。

以上这两点不知道我的领导是否认同，还需要等到下一次考核的时候和他沟通沟通。

这是工作以来，第一次站在一个管理角色去思考、去做绩效考核这个工作。这第一次的考核工作让我不知道用什么语言来描述我的感受。

考核的结果是：测试组整体的分数都比开发的低，从排名和等级划分上可以说是包尾了。从分数上看，我的第一感觉是：难受。第二感觉是：生气。在和领导进行一系列沟通后，在回家的路上一直在思考、分析着这个结果，问题出在那里呢？问题出在那里呢？？？？？冷静的思考后，自己安慰自己，原因应该是这些吧：

1、  这次开发人员和测试人员使用的工作考核方式是同一种考核方式。

2、  这次把开发人员的考核分数拿来和测试人员的进行排名对比。

很显然，一直这样下去，测试人员的工作即使在怎么努力、分数超过开发人员的机率会很低很低，这样的对比规则，对测试人员来说，很不公平。这样的对比规则，很没有意义。更让我郁闷的是，面对这样的现象，我想不到很好的解决方法，目前只能鼓励测试人员加强自己的综合能力，自己给自己争气，对我来说，在测试人员的管理工作上，无形中出现了一个困难，只能是乐观面对了。

唉，工作种类不一样，放在一起作对比，永远说不清。

测试人员的工作，开发能作么？开发人员能写好测试需求、测试计划、测试用例、测试分析报告文档么，先不说写好，先说会写么？开发人员知道怎么样去执行测试么？知道发现 bug 应该怎么有效正确的去描述么？怎么快速有效的发现程序的问题么？能把握好整个软件测试的质量和进度么？测试，说的简单，真正做好没有这么简单。就拿黑盒测试举例，测试项有：业务流程测试、功能测试、安全性测试、性能测试、数据测试、用户友好性测试、配测试、兼容性测试。这些测试项所使用的测试方法、测试点，都能想全了、想到重点了么，想到了还只是第一步，真正要去执行测试的时候，测试环境的搭建、测试用例的编写与执行、 bug 的描述以及错误等级的正确划分、 bug 的回归、用测试工具进行测试，对测试工具正确有效使用的把握，这些对开发人员来说，会做么，能做好么？测试工作也有很大的工作压力，面对一个不熟悉的软件，面对一个什么说明文档都没有的大软件，要在最短的时间内，最有效的完成测试，要保证产品在发布后，不出现严重的问题，想尽一切办法的发现严重问题。这种对软件质量上的责任压力是很重的，还有其它我就不举例了。

开发人员的工作，测试能作么？测试能看懂开发人员的代码么？测试能写代码测试开发人员的程序么？测试能明白理解开发人员是怎么开发的么？测试能明白开发人员所说的工作术语么？测试能看明白开发人员的开发成果么？开发人员的工作也有很大的压力，要在最短的时间内编写出质量高的代码，实现功能，还要进行一遍又一遍的调试，需求一变，又要修改代码，自测时，发现问题，要进行调试找原因和解决方法，容易么？不容易。测试人员发现的问题，还要去找原因要想最好的解决方法。容易么？不容易。

我很同情那些把测试和开发放在一起作对比行为的人，因为他们对这两个工作中的其中之一理解有所欠缺从而导致这样的结果。说了那么多，好像扯远了。

最后，我得出这么个结论：这样的绩效考核方式，对测试人员来说，起不到激励作用。如果碰到不能正确心态去理解的测试人员，反而会起反作用，很打击工作积极性。因此领导在问我意见的时候，在不适合的说话时间、说话场合我只能说“无所谓”，心不甘情不愿的无所谓！！！！！！！！！！！！！！

自从10月份换工作到现在，工作心情发生了很大的变化，工作总结都没有整理，原因之一是没有安静的心情，二是没有很完整的时间来写。本来不打算写这个工作总结了，但还是不自觉的敲起键盘来，也许是因为这个周末就要回家过年了，在回家之前，还是想写下一些东西，记录下一些东西，因此便有了这篇随笔。

我的2005年10到12月份个人工作总结

一、工作内容

2005年10月份：

第二周：整理武汉出差回来的文档，写出差总结报告。

第三周：完成二代身份证读卡器回归测试，编写最终的测试分析报告。

第四周：办理辞职交接手续，到新公司报到，了解新公司的国内酒店预订系统。

2005年11月份：

第一周：熟悉国内酒店预订系统，编写相应的测试需求文档。

第二周：编写国内酒店预订系统的测试计划，测试国内酒店预订系统，提交简单的缺陷报告。

第三周：回归测试国内酒店预订系统，提交简单的缺陷报告。

第四周：办理辞职交接手续，到新公司报到。

第五周：起草知识共享平台建设规划，参与审核项目开发部建设规范文档，bugzilla培训文档。

2005年12月份：

第一周：

1.         完成部门质量记录文件编写：项目申请、变更、完成单格式。

2.         修订bugzilla培训文档。

3.         编写部门软件测试规范文档。

第二周：

1.         完成《食品标签证书影像管理系统使用说明书》的修订。

2.         完成用VSS搭建知识共享平台，并归档相应内容文件。

3.         完成软件测试规范文档的编写，提交内审。

4.         组织相关文档的内审。

5.         参加公司相关培训

第三周：

1.         审核食品标签影像管理系统的质量文档并归档。

2.         根据评审意见，修订软件测试规范文档。

3.         管理部门质量记录文件。

4.         审核母婴频道的质量文档。

5.         数字认证服务系统测试准备。

第四周：

1.         食品标签证书影像管理系统文档归档，进入质量管理。

2.         母婴频道文档归档，进入质量管理。

3.         修订数字证书的测试需求。

4.         数字认证服务系统前台测试。

二、经验和教训

关于测试工作：

这四个月，测试的主要工作有：

1.         二代身份证读卡器的回归测试，编写测试报告。

2.         国内酒店预订系统的测试，编写部分测试文档。

3.         数字认证服务系统的测试。

这段时间的测试工作，还是停留在原先的基础上，没有很大的突破。这就是换工作付出的代价。

关于质量管理工作：

1.         用VSS搭建了知识共享平台，等待审核。

2.         编写了部门的软件测试规范，等待审核。

3.         编制了部门项目开发的质量记录文件：项目申请、变更、完成单，已经审核通过。

4.         编制了使用说明书编写格式，等待审核。

5.         编制了质量管理记录文件：知识共享平台接收文件确认表。已经审核通过。

6.         完成食品标签影像管理系统现有质量文档、文件归档。

7.         完成母婴频道系统质量文档、文件归档。

第一次做质量管理工作，可以说是一头雾水，在学习、实践、摸索中。

优点：很有工作激情。

缺点：

1、没有系统的学习过，没有很好的理解全流程测试理念，没有很好的实践经验，想做个真正适合公司目前阶段的质量管理，怎么去管理好，真是思考了1个多月还是没有进步，书到用时，方恨少啊！

2、数字认证系统的质量管理有问题，表现在：

Ø         需求没有确定的情况下进行开发和测试，导致后期测试中发现的问题很多。

Ø         开发没有按照开发规范进行开发。

作为质量管理的我，没有及时向技术负责人反应，没有向部门领导反应，没有很好的提醒开发人员，很是失职。应了那句古话“吃一欠，长一智”。

关于公司：

离开了工作快两年的公司，心里的感激多于抱怨，对身份和收费这两个系统的测试经历时时还会回忆和想念，对这两个系统还会有着牵挂，毕竟投入的工作热情和感情太多，成为了我测试工作生涯中一段美好的回忆。离开了，只能祝福公司将来会好起来。

离开了工作快一个月的公司，心里最多的是对它的抱歉，这就是有缘无份。

现在的公司，我非常的珍惜，因为找到了志同道合的开发团队。心中有太多的感叹，看哪天有心情好好总结一下和大家一起分享。

关于自己：

引用同事的一句话“冲动是魔鬼”。我这次就是冲动的辞职，心情在这四个月里发生着变化，到现在的平和。

这段时间的心情就像“我要飞得更高”那首歌所唱的一样。

写到这里，感觉这都不像总结了，有些分心了，就写到这吧。

   到新公司工作有1个半月了，在这里工作很有趣，每次做完的工作，部门内部负责人都会进行审核，指出其中的不足和问题，让我看到了自己的一些不良习惯，就在前几天，突然感悟到，在这里做工作就像学生写作业，因此就有了这篇随笔。

                      做工作就像学生写作业

    时间过的真是快，2006年来了。这段时间，虽然很忙，但过的很充实。2005年的最后一天，北京下雪了，在回去的公交车上，看着夜景，听着MP3中传来的歌声，回想2005过去的一年，回想着最近的工作，突然感觉到，现在做的每一项工作就像大学里写作业一样，对安排下来的工作，尽自己所能得去做。

    这次换工作，很担心自己担任不了新的工作岗位，现在想想自己的担心真是多余的。：）开始的前两个星期还不能适应从一个执行者转换到管理者的角色，在没来这里工作之前，我所做的测试工作成果，部门领导从来没有人进行审核，应该说是正确有效的审核。现在，做的工作都需要审核，这才发现自己工作上存在的问题，开始一点点改进，受益匪浅。

    领导审核工作，就像大学里老师改作业一样，每次都会发现问题，作业是不是认真做，作业做的是否正确，仔细审核就可以知道了。这是自己做测试以来，第一份和管理者角色最近的工作，现在既要带人，又要去执行工作。感觉和以前还真是不一样，当自己是一个管理角色时，就像一个老师，要给自己的学生安排合适的作业，要安排自己的时间去指导和审核作业，当一个老师真是不容易，光有理论，没有实践，还很难服人，只有实践，没有理论，又很难把工作质量往更高一层发展。没有好的沟通能力和表达能力，学生会听不懂你说什么，做一个管理者真是不容易，要很好的去把握时间+工作重点+有效的沟通+工作方法+责任。一个老师不能正确有效的批改作业，那么可以说这个老师不合格了，需要继续进修才行。

    相比之下，做一个执行者角色就像一个学生，轻松多了。只要认认真真的去做，不会不懂的时候，还可以请教老师，当然，能养成自学的能力那是最好的了，因为自学能力永远不会被淘汰。有更多属于自己的时间，承担的责任没有那么重。

    嘿嘿，我就在这两个角色中来回变化着，让我又体会到了测试工作中新的乐趣：

      1、作为老师，当学生在你的指导下取得进步，那是一种成就感。

      2、作为老师，在指导的过程中，学会了另一种知识，那是另一种收获。

      3、当老师和学生共同完成一项任务时，体会到了团队的力量。

    也许，正是因为体会到了工作中的乐趣，让我更加的喜欢自己的工作和职业，也许，就是因为喜欢，才会激发我心中的热情和激情。做测试两年了，我还是那么喜欢这个职业，2006已经向我走来，在这新的一年里，我能收获什么，真是让人期待！！！！！！！！！！

编写背景：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我的体会：

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

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

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

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

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

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