总结编写测试用例的方法

  做测试几年多了，随便写一下平常是怎么写测试用例的，也算是总结下以往的方法吧！大家就随便看看，希望可以给你提供多个方向，觉得不适合也没关系，每个人都可以总结自己的方法。
  曾有那么几次，我拿到需求文档后就觉得头疼，几十页的需求文档，把一个从无到有的系统描述出来，我是挺佩服产品经理的，居然可以写这么多内容，真是厉害。可是产品经理是厉害了，当我接到需求之后，让我按照这个需求文档写全部的用例，这时我就头疼了。需求内容太多，无从下手呀！以我之前编写用例的习惯，想到那里写到哪里，自己也没把握能够很好完成这项任务呀。领导可能也知道整个系统下来，用例不会少，然后他就说：“你需要尽可能用最少的用例，覆盖所有的需求点。”领导发话了，那就只能上咯！
  在开始写用例前，我们拿着需求文档查看需要实现什么功能，做什么样的系统，这个时候我们需要明确整个系统或者需求主要都实现了什么功能，整个流程是怎么走的。这就是很多人说的系统主要的功能，或者说是主要的流程。而你需要的是把这个主要的流程整个串联起来，形成一个闭环，或者从开始到结束形成一条非常明确的路线。这时你就可以针对这个主要的流程进行用例的编写了。这些用例的优先级都应该比其他部分的用例的优先级要高，也更重要。很多时候，给你的测试时间是不够的，你必须要保证这个主要的流程测试通过。举个例子，若你需要测试的是一个商城的下订单需求，这时你主要的流程就是下单，商品价格计算正确情况下完成整个操作，并得到预期地结果。至于下单商品地类别，标题文案等内容，优先级都应该排在下单之后。若是要整理需求的主要流程，推荐下使用思维导图来构建，你会非常清晰直观地看到整个流程该如何往下走。
  当完成了主流程的测试用例后，我们就需要深入到主流程的各个环节，对每一个环节，每一个功能点进行用例的编写了，这一部分可以尽量写得仔细一点，根据常用的编写用例的方法，以及自己的经验判断下，那些方面需要特别注意，那些情况是开发经常性忽略或者疏忽的，这些都是隐藏问题。简单地说就是使用发散性思维方式去编写各个功能点，当不同地参数或条件出现时，会出现怎样突发情况。尽可能地详细，概括尽可能多地情景。
  若是系统的主要流程以及与主流程各个环节都已经编写用例完成了，那我就需要换一个角度去思考剩下的内容怎么写了。最后剩下的就是系统与系统之间，模块与模块之间的联调，这部分用例不会很多，但是很容易被人遗忘，总觉得自己已经写完了系统的所有测试用例了。联调方面的用例其实不会很多，应该说写出来的数量都会比较少，可是若忘记了这部分内容，出现问题后往往会付出更多的时间与精力去解决它。很多时候系统设计开发过程中，由于需求会不断发生变化，模块或系统可能会出现比往常更多的输出类型，而下游的模块或系统却没有处理这种输出的逻辑，这就很容易发生错误。
  对于上述所描述的设计编写用例的方法，我自己是这么概括的，系统主要的流程用例已经有了，那就完成了一半的内容了，再从小的地方深入了解各个细节，然后再从大的方向去分析模块与模块之间，模块与系统之间是否存在不兼容的情况。这样分析下来就觉得自己的用例基本可以覆盖绝大部分场景了（自我感觉）。其实测试的过程中，很多时候你会发现时间不够，这个时候你就需要分配好测试时间了。怎么才可以在有限的时间内实现测试工作价值的最大化。
  方法总是适合自己的才是最好的，而适合自己的方法总是需要自己去设计，去尝试，去调整，去归纳。