设计测试用例的一些心得
看到许多小伙伴在这里提供各种用例设计的资源，我也来凑个热闹，分享一些避免踩坑的心得。1、边界值检测：这是几乎所有的设计用例的文章都会说到的。但大部分文章只会强调测试用例条件的边界值，这里我们说一说除了条件之外的其它的边界值问题。众所周知任何变量都有一个最大值，通常情况下程序不会达到这个最大值边界，但如果你测试用例中有计数、统计、性能、累加、累乘等具有不断扩大趋势的变量时，就需要注意研发是否有对这类变量边界值的处理。或者某些存储累乘的结果的变量设计过小，在运行一段时间后会因为数据截断问题突然从大数跳变成一个小了许多的数。
2、用例颗粒度：许多人写测试用例总有这种感觉，某些用例按照测试因素拆开来一个个地写会显得过于简单，把多个测试因素混在一起单个用例又显得过于复杂。如一个在不同浏览器上检查页面是否正常需求，可以按照浏览器、屏幕长宽比、分辨率、操作系统等因素拆成上百项，但每一项测试用例就只有三步骤：
1)打开页面；
2)检查页面是否显示正常；
3)关闭页面；
如果合成一个用例，那么后面会加上：
4)采用不同的浏览器，循环前面各步；
5)采用不同的屏幕分辨率，循环前面各步；
6)采用...
一个用例包含成百上千个操作步骤，实际测试的人心态爆炸。
这种现象其实就是用例颗粒度选择不当，无法很好地平衡用例设计与执行导致。关于这点业界其实并没有什么一劳永逸的办法解决，大部分教材上只是拆分成单个测试步骤，但没有说明如何组成合适的测试用例。就个人经验来说，一个合适的测试用例操作步骤在5~9步范围内为佳，如果单个测试因素操作步骤过少，可以将多个易于操作的因素组合在一个用例中。
3、设计文档缺失：不是每个项目都有完善的文档可以参考，有时我们会遇到只有需求没有设计的项目需要给出测试方案和测试用例。对于这种情况，我们可以从两个方面来设计测试用例：一是客户的需求以及附带的隐性要求，这些是必须实现的；二是可以参考市面上有的类似产品或架构的设计，通过对方的参数指标来指导我们进行设计。同时对于项目中用到的各种标准、协议，我们也可以在官方网站上获取，用以指导我们的用例编写。
4、灵活的标准判定：对于有些标准或协议文档，需要在设计用例时灵活判定。比如BFD协议中对于被动模式以下说法
设备在被动模式下不会主动发起交互报文；
建议在双端被动模式下支持报文交互；
这就给相关的协议开发带来了困扰，在双端设备配置成被动模式下BDF到底是有交互还是没有交互报文？不同公司对此处的处理不一致，有些公司就默认双端被动时没有报文交互，另一些则在进入被动模式前优先用主动模式发一轮报文以激活交互。这两种处理方式都符合协议规定，只要公司内部一致即可。
5、综合测试：虽然我们通过拆分需求，将其转化成一个个的测试点。但这并不能保障产品或应用在复杂运行场景时的稳定性，因此，符合客户需求的场景测试是一定需要的，场景中模拟用户的真实应用场景可以极大降低产品交付后的故障与风险。 根据自己公司的业务来设计，必须包含主要功能主要流程；
页:
[1]
