测试小札

你不知道的用例编写方法

作为一名测试人员，总会有需要进行用例编写的时候，在进行用例编写时都遇到过什么问题呢？

　　小编询问了一些测试人员，结合自己遇到的问题，总结了一些，一般会有以下几个方面的问题：

　　1）  不知如何着手进行，千头万绪，不知如何理

　　2）  用例覆盖度不高，不知该如何提高

　　3）  培训机构学来的知识不知道如何使用

　　4）  用例结构不清晰，容易遗漏，且维护麻烦

　　这些问题都是作为一名测试人员，在工作中会遇到的实际问题，解决的方法千千万，搜狗输入法的测试团队是如何解决的呢？下面我们一起来看一下~

　　搜狗输入法团队的用例编写可以用两个字来概括：拆、找，主要步骤如下：

　　1）  将测试对象进行拆分，直到拆分为原子对象

　　2）  分析原子对象，找出该对象所有的检查点

　　3）  分析检查点，找出会影响该检查点的所有因素

　　这种方法产出的用例，分为4级：对象→原子对象→检查点→影响因素

　　下面我们来详细分析看一下~

　　首先，拿到一个功能的需求文档后，将这个功能当作一个大的测试对象，分析需求文档，根据自己的理解进行拆块，将一个大需求拆解开来，分成小块，即将大的测试对象拆分为一个个小的子测试对象。

　　一个榴莲，无处下嘴，怎么办呢？我想大家的反应应该都是一样的：鄙视的瞧着小编说，把榴莲打开，分成一块一块的，不就可以了吗？这么简单的问题还要问，╭∩╮(︶︿︶)╭∩╮。其实小编觉得，一个完整的需求就是整个的榴莲，都需要将之进行拆解，然后才能进行下一步的动作。

　　测试对象拆分为子测试对象后，如果还是觉得太大，不好分析，就继续进行拆分，拆分为原子测试对象。分析一个简单的原子测试对象，你会觉得，原来真的这么简单啊，:-D

　　什么是原子测试对象呢？字面上来看，就是无法再继续拆分的测试对象，再进行拆分的话，就不是一个完整的对象了。

　　其次，拆分为原子测试对象后，分析原子测试对象，找出该原子对象的所有检查点，这一步就完成了。

　　有人会问了，什么是检查点呢？小编理解检查点就是被测试对象的某一个属性。如被测对象是按钮，我们要检查的不是按钮本身，而是按钮的某一属性，如按钮的显示状态，按钮的位置，按钮的颜色等

　　然后，再分析检查点，找出所有会影响该检查点的因素。如检查点是按钮的显示状态，什么会影响按钮的状态呢？鼠标hover，鼠标点击，初始状态，当前窗口是否是焦点窗口等

　　分析到这里，这个功能就被我们分析完了，剩下的就是整理，用例的骨架——大纲就完成了，剩下的就是体力活，给用例增加血肉——用例内容

　　小编写到这里，忽然觉得写用例跟画画很像呢，先分大块，再分小块，然后画架构，最后填色成形~

测试用例设计策略

一方面：

　　1、先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，这是减少工作量和提高测试效率最有效的方法。

　　2、在任何情况下，都必须使用边界值分析法。经验表明，用这种方法设计出的测试用例发现程序错误的的能力最强。

　　3、可以使用错误推测法追加一些测试用例，这需要依靠测试工程师的智慧和经验。

　　4、对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当再补充足够的测试用例。

　　5、如果程序的功能说明中含有输入条件的组合情况，则一开始就可以选用因果图法和判定表驱动法。

　　6、对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果。

　　7、利用功能图法，我们可以通过不同时期条件的有效性设计不同的测试数据。

　　8、对于业务流清晰的系统，可以利用场景法贯穿整个测试案例设计过程，在案例中综合使用各种测试方法。

　　另一方面：

　　1、站在用户的角度,优先使用场景法

　　2、任何情况下都必须使用边界值分析,因为它发现程序错误的能力最强

　　3、用等价类划分方法减少用例数

　　4、使用错误推测法追加测试用例

　　5、多条件组合输入,建议使用正交实验法或决策表

　　6、复杂的业务流程,可以结合业务流程图和状态转移法设计用例

　　7、检查程序逻辑,可以使用逻辑覆盖法

　　8、探索性测试