看着下午随手提的单，又想起昨日上午的漏测分析，发觉自己写的测试用例真的很脆弱，禁不起推敲，也琢磨着，为何用例看似很多场景覆盖很全，但发现的问题却不多。虽说好的用例是能让新手看懂且发现问题，但是很无奈的是总是觉得自己写的没什么含量，记得老大曾经问过我“你的100个用例能发现多少问题”无言以对，低效率。

　　曾翻过其他厉害同事写的测试设计，测试分析的很透彻，用例也很详细，随之学着模仿，之后询问过测试我写的用例的同事，步骤还好，主要关注点也有，后台流程也包含，但是太多看的很头晕。好吧，过于简单和详细的用例都并非好事，如何对在步骤进行缩减的情况下保证质量，不过在此之前还是得对测试设计一块进行梳理下。

　　用例设计的前提，则是对需求以及方案的透彻分析，觉得这块看起来很简单，理解原始需求，看懂总体方案后就可以了，可是真的就这么简单么，常看他人说，要找出隐藏需求，这点对自己还是有些勉强，从原始需求中可以提炼的要点不是很多，将之列出，带着这些去阅读总体方案。其实自己更喜欢将功能点列出后就抛开，直接去看总体方案如何实现，对总体方案有个初步印象后，再去看待要实现的功能。

　　在进行具体分析的时候，作为解决方案的测试，不仅仅需要围绕了核心功能的实现，同时也得理解自己本身的设计理念，站在用户的角度上看待，分析理解这个功能给用户带来的影响是什么，对于用户的概念，不仅仅是终端用户，还有运营商管理员。对于功能实现一块，熟读总体方案之后，还需参考部件规格的实现，加深理解。在分析流程时，各部件的交互可以通过时序图描述，将相关接口以及主要参数整理出，可以作为关注点在用例上体现。功能实现也摸清的话，就可以开始测试设计了，首先作为一个新特性，其主要实现目的有哪些，测试难点在哪里，涵盖的用户范围以及其具有的操作权限，是否与其他流程存在交互过程等等，这些都要逐一列出，当然最好能考虑其生命周期，就像踏入迷宫，不同的选择，将会触发不同的结果，当然有了起点，肯定会有终点，此时就要考虑从对象的创建到其消亡的过程，这和入口出口在某些情况下有些的差异，前者是指一个过程，一定情况下可拆分后者流程。在分析的时候，最重要的就是列出测试关注点，这不仅需要把总体方案上提及的系统实现的内容转换为解决方案的测试点，还需要各个部件中的关注点归纳，再融合进去。

　　在将每个场景的流程理清之后，就可以开始测试用例的设计。对于这块，大的框架是功能特性，至于次层分解，可以以流程中的一个或者几个重要属性作为角标进行发散，比如接入的门户类型，用户类型等等。以不同的属性为角标，其侧重点也是不一致的，但是需要保障主要功能实现即可。在设计场景的时候，对于用户来说，不清楚内部如何实现，前台的数据的展示就尤为重要，当然后台数据的存储也是要与前台保持一致。其次，在理解测试要点同时，从端到端的场景考虑，保持流程的完整性，最好也需考虑一个流程的终端之后可能还会存在后续，就像是一个流程的终点或许是令一个流程的起点。当然，测试用例的设计的一切都是基于之前的测试分析阶段，自己所解读到的信息。在编写测试用例时，步骤清晰，预期结果以及检查点明确，最好还有后台流程实现，比如调用的接口，重要传参等等。

　　这个大概就是自己非常混乱的测试设计思路，欠缺的很多，只起到了一个最基础的引导作用，很多问题都是在测试的过程中发现的，还得继续努力。

版权声明：本文出自 forstkksk 的51Testing软件测试博客：http://www.51testing.com/?600991

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。