测试用例自动生成技术的意义

传统的 UI自动化测试技术的缺点

自动化测试最大的挑战就是需求的变化,而自动化脚本本身就需要修改、扩展、debug,去适应新的功能,如果投入产出比太低,那么自动化测试也失去了其价值和意义。另外自动化仍然属于黑盒范围,无法对白盒覆盖等技术有有效的提升。

测试左移后单元测试(程序级自动化)面临的问题

编写单元测试用例耗时长 传统程序级测试用例的编写会耗费开发人员大量的工时,比如TDD测试驱动开发里面的单元测试无法有效实施,导致所有测试几乎全部依赖于系统级黑盒测试。程序级测试用例的开发成本是功能实现代码本身时间至少为1:1,绝大部分企业选择放弃开发程序级测试,而采用系统级测试方法。

需求变更、持续投入大 需求发生变化导致程序实现发生变化后,程序集用例也需要发生变化,和自动化面临的问题一样,单元测试本身的可维护性问题导致投入是持续的而不是一次性的,会打消其企业应用的热情。

适应性不全面 很多单元在未组装成系统的时候切入,如果需要进行测试需要进行大量的mock操作或者桩模拟,这个过程会造成单元测试的不精确性。

测试数据准备过程长 程序集测试数据量很大,全部需要用户来进行准备无法全自动从前序系统测试过程中拿到。

编写单元测试的一般流程

① 首先编写被测函数的驱动函数,驱动函数主要功能为针对被测函数进行赋值

② 构造被测函数的所有参数值

③ 构造被测函数中使用的全局变量,并赋值

④ 获取对被测函数的返回值

⑤ 校验,判断是否针对输入得到预期输出