综述:
MBT技术之前比较热,国内有些公司也在做,例如“华为”之前一直想搞,直到近2年才认真的考虑彻底来用此方法来彻底代替传统的用例设计,和自动化脚本的自动生成。主要原因还是在于领导的决心,以及技术的储备。MBT需要大量的基础框架支撑,以及外围强大的工具支持。这也是为什么小公司很难玩这个的原因。
本系列文章从一个小案例来解释,小公司怎么玩起MBT(流程图建模+自动化用例生成)
测试对象:
测试一个web窗口页面。窗口包含名字,描述,选项,确定,取消
功能说明:
可以窗口新建一个条目,可以输入正常值,异常值,异常值输入会被提示错误,新建可能成功,可能由于异常输入不成功,也可能输入过程中取消等。
测试分析:
需要确保上述功能的参数和逻辑的测试覆盖。传统的测试设计是:正常值遍历、边界值遍历、覆盖各种参数组合、提交、取消,可能需要输出几十、上百的cases,关键是可能还覆盖不全面。其实目标就是抽象为一句话:输入值覆盖以及逻辑覆盖( 本 例案不考虑界面的易用性、美观等) 。
MBT覆盖技术则另辟蹊径,从高层次建模角度,使得测试能在建模之后自动遍历,并持续进行,且维护优化方便。MBT极大的可能覆盖更多的路径组合和参数条件组合,且更容易发现测试中的“黑天鹅”。
测试用例,自动化脚本:
全部无需做任何写作,实现对此web对象的1000次自主遍历
补充说明:
实际上测试,不需要便利这么多分支,毕竟大家心里是有谱,本例举这个例子,只是为了介绍方法,另外谁知道,这些空间有没有bug,随机输入,随机顺序会不会出问题呢,毕竟测试覆盖越趋近100%,“质量”就回趋近最好。