“测试用例”设计的理想与现实（待补充）

周末分享的主题是测试用例的设计思路。

关于测试用例，之前没有用心整理过，可能是因为公司比较小，对测试用例没有太多要求。于是造成了对测试用例除了简单的几句话，就说不出太多了。

首先说明当前工作中测试用例的现状，

即我是怎么设计测试用例的。说来惭愧，没有想过什么正交测试法，这次听分享，才想起来，工作中最多的是对系统的业务逻辑上的测试。业务逻辑上是否通顺，是否正常流转。其次，是页面的显示，当一个字段，比如企业名称过长时，显示是否会自动换行且显示与下一行不重叠。

关于业务逻辑的设计思路是这样的：先从小功能开始，简单的流程，正向的流程，然后是复杂的流程，反向的流程。我之前有过一次教训：测试一个评标的功能，从开始简单到后面越来越复杂，开发也一路去修改，到最后没测试一般流程，结果导致了中标方并不是最高分的那家企业。这也让我明白，客户经常使用的流程应该是占比重更高。最后也应该回归一遍来确认。因为“高精尖”的流程，客户其实很少会用到。

在工作过程中需求是会变化的，相对应的测试的指南--测试用例，势必也要进行相应调整。

测试用例设计的理想状态：完美的使用那些方法来满足当前需要

最后，测试用例的设计上可以达到用尽量少的测试用例数来覆盖最大范围的需求。

测试用例的设计方法：等价类划分法和边界值法，这两类方法一般会结合来使用。

在数据的设计上还要注意特殊字符，比如英文的单引号双引号，空格

1，在测试时是否按照测试用例执行？

首先是按照测试用例执行，然后留有部分时间做自由测试，自由测试的时候会发现很多交互的地方存在问题，这时候需要新增用例。用例用来发现系统中的缺陷，而这个过程也会帮助完善猜测是用例。

2，测试用例的详细程度

有时间就细化到每个操作细小的步骤，没时间就列出测试用例点

3，等价类划分，实际是把输入数据分为若干类，每一类取一个值即可（代表这一类）

4，边界值：不仅考虑输入，还可以考虑输出（eg（这个例子没看大懂。。）一个文本框类型是varchar（50），当输入边界值长度为49字符时，提交后列表页面显示被撑破了，ppt 14/49）。另，边界值不是从每一类中挑一个作代表，而是每个等价类的每个边界值都作为测试条件。

5，正交试验设计法

这个方法又称为组合试验法，利用场景来设计测试用例时，输入条件的场景非常庞大，以至于测试用例数目十分惊人，若舍弃一部分又怕测试用例覆盖度不够，这时可以利用正交试验设计方法。

21:49和21:55处没有听太懂

后面对正交试验设计法进行补充

6，错误推测法

错误推测法，依靠测试的直觉和经验进行测试