用例设计心得
目前很多新加入测试行业的朋友在刚接触测试的时候十分茫然， 经理的三言两语就安排了我们的工作性质“**啊，你去**这个项目组帮着测试下，”“**，你来测下这个系统，有问题就和我说，”……这种情况很多很常见，对于一个新人来讲，怎么测呢？测试这个行业我一直觉得是易学难精，某种角度来讲，测试比开发还要难，比开发还需要动脑子，相信大多数人都看过玄幻小说，在这里我做一个比喻，我们把BUG和开发任务比作对手，整个团队比作自己，那么开发人员就是杀敌的利剑，开发人员所掌握的技术，就是这把剑的长度和锋锐度，那么我们测试人员呢？测试人员则担任了眼睛的任务，要通过我们来寻找对手的破绽，从而一招胜敌，这里除了找出缺陷同时还有一个工作，给缺陷定位，我们测试员掌握的技术，就代表了大脑运作的速度，代表了眼神的犀利，很多新人朋友知道自己要去找BUG但是常常忘记了给BUG进行一个定位，其实定位是很重要的，就好比你发现对手的破绽在两眼之间，你却告诉你手中的利剑，对手的头上有破绽，试问，假若你直接将BUG定位在两眼之间，哪个更有效率呢？再来谈一下测试人员应该掌握的技术，就我个人来看，测试最核心的技术还是测试用例的设计，不论是纯手工测试，自动化测试，黑盒测试，白盒测试，功能测试还是性能测试都离不开测试用例的设计，至于更牛的测试专家他们所掌握的诸如开发测试工具这样的技术，仔细想想，也只是为了更方便的设计和实现测试用例。
只要接触过测试的人不难发现，其实用例不难，大家或多或少都接触过用例，可真正明白用例的用途的还是在少数，以下我将用例的设计分为4个阶段当然只是给新人朋友的一点建议，与我以前发过得一片新人朋友看的博文是同样效果的，只是给新人朋友指引一条测试的道路，所谓条条道路通罗马，也希望更多的朋友能够分享自己的一些心得和体会。
第一个阶段，茫然在这个阶段的朋友多半是第一次接触到测试用例，虽然用例的格式都有，但总是自己设计不出来或者设计出来的用例效果很差，其实用例的格式并不重要，有时候可以根据你自己的实际项目，所采用的设计方法，思维模式而改变，如果你感到无处下手，那么你应该去看一看有哪些用例的设计方法，同时仔细的分析下你现在的状态和手上的系统比较适合什么方法。 第二阶段，用例过多，覆盖面积虽然达到但是工作量太大这个阶段的朋友，你们已经掌握了一种或2种基础的用例方法，比较常见的诸如场景法，等价类划分法，边界值法，你会发现，像是场景法一条比较复杂的业务流程能够分出10多20条备选流，而场景法和等价类结合确实能够实现一个较为客观的覆盖面积，但是你会发现要达到这个效果所需要用的测试用例实在太多，这就照成了工作量增大，无意义的用例和重复的用例也会直接造成你的工作有百分之20甚至更多是无效的，这个时候你就应该尝试去了解一下高级的用例设计方法了，比如因果图判断。
第三阶段，用例大瘦身，覆盖面积依然可观这个阶段，其实你在用例的方向已经颇为厉害了，至少掌握了三种用例设计方法的你，已经能在短时间内对一个一般的系统做出一个较为完整的测试用例了，通过2种基础的用例设计方法，将整个系统所有功能点都包括起来，再通过因果图判断，将重复的测试功能点排除掉，可以说你现在设计的测试用例已经是优秀的用例了，完全能够达到使用尽可能少得用例覆盖尽可能多的面积，那么这个时候你应该继续提高自己的能力，可以尝试着将用例进行复合，进行复合用例的设计了，难度颇高哦。
第四阶段，这个阶段实际上你已经是达人了，我也就不在达人面前献丑了，只是借助这个阶段，提醒一下新人朋友，不要认为自己的技术已经很好了，要知道第一阶段巅峰的人是比不上第二阶段初级的，你觉得自己很优秀了，只是因为你不知道在你之上还有很多层面是你没接触到得，千万不要止步不前。 其实测试这个行业，要做好很不容易，常常看见很多人做了4，5年还是觉得自己还是什么都不知道一样。从这也能看出测试的难度，国内的测试还不够成熟，最直接的体现就是测试的易学，还有和开发工资的对比，为什么测试易学而我却说测试很难呢，因为所谓的易学的测试，甚至不需要去学，有些公司直接就是让你东点一下西点一下，看看报不报错，这不算测试，至少在我看来真的不算入行，测试难学，难就难在测试是纯思维上得职业，我们不需要一直敲代码，不需要一直去设计系统，但是我们必须要在思维上模拟很多场景，模拟很多操作，我们的工作实际上核心部分都是在脑子里进行的，是不能通过肢体来表达的，你在思考新增人员的操作时，如果你直接就操作了，那么抱歉，你还不合格，如果想到什么就做什么，你的测试效果会很差，因为这一个节点可能的情况你还没考虑清楚就充充开始操作，造成结果不外乎两点，一是大面积遗漏，二是工作量增加。有经验的测试员，会在脑子里将所有可能的情况都考虑到最后形成文档，再依照文档来进行测试，这份文档也就是测试用例，能够保证覆盖面就又不让我们过多的重复操作，更能让开发或经理清楚的了解到这个系统哪些地方已经测了哪些地方已经遗忘了。我们从最初做测试的时候应该就会了解到，不存在百分百测试，也不存在2个人设计的用例百分百相同，这个时候用例文档的好处就体现出来了，即使开发人员在看了你的文档后也有可能提出一些你没有考虑到的地方，毕竟这些系统的核心还是开发人员自己开发出来的，同时开发也是人，开发考虑的角度也代表着一部分用户的角度。即使你所在的项目组，公司不重视用例，但是如果你想在测试这个行业有所成就，那你就要注意这些地方，我在上一篇博文里也提到过，公司不给你安排，并不代表不允许你做，不要等着公司给你安排任务，学到的技术学到的经验都是你自己的，能力提高的也是你自己，相应的，能力提高了，工作量减少是必然的，同样的一个项目，别人要用1周测完，而你只需要1天，多余的4天，就是你自己努力的奖励。
期待同行参与讨论，我始终相信，分享自己的心得能让自己收获更多，一人一年的工作经验，虽然不能让你直接拥有5年10年的这样累加，但是也能让你的一年工作经验比别人的一年经验充实5倍，10倍。 很受用:victory: 很受用:victory: 总结的不错，谢谢开心果 测试这个行业我一直觉得是易学难精，某种角度来讲，测试比开发还要难，比开发还需要动脑子……
非常赞同这个观点，以上所学深有感触，值得学习；
虽然经历过，都想到了，但没有及时总结分享出来，这一点后期我也把自己的一些感觉分享给大家参考，一起指正。 很受用 学习了 楼主讲的其中很多都是自己曾经遇到的，顶啦！ 楼主讲的其中很多都是自己曾经遇到的，顶啦！ 受用！ 有感触 顶啦 版主这个写的很好，第一读 测试人员写用例的心得啊~~ :handshake 是不是自己懂开发了才能写出好的测试用例呢？ 看后很受用，呵呵！ 学到了。:lol 学习了 顶楼主
页:
[1]
