Flint
自动化测试
测试在效率上的困境即使是正确性验证，在很多场景下依靠动态测试手段是非常昂贵，但仅仅依靠静态分析又没办法保证动态执行时的正确性。为了和自动化代码生成的速度相匹配，自动化的测试设计到执行就成了一个急需解决的问题。很坦诚的讲，虽然自动化测试从20世纪70年代最初提出自动化测试的概念到90年代逐渐走向成熟，已经发展了超过50年，但是直到现在绝大多数公司的强业务属性的测试团队依然是大量依赖人工，业务部门的测试开发比依然需要维持在1:5，测试人效的中位数在中国的互联网大厂中过去多年都保持在1:3。可见从效率角度讲，当前普遍使用的自动化测试手段在需求迭代中的效果并不明显。软件测试两个最基础的概念是随机和覆盖，所有的软件测试方法都要讲是基于什么覆盖指标，下面分别从常用的两种不同覆盖维度的自动化测试方法进行阐述：面相技术指标的，基本上绝大多数的自动化测试用例生成的方法都是技术维度的，原因是技术指标是脱离于业务语义的更具备通用性同时也很容易计算出分母的数值，比如接口覆盖、行覆盖、分支覆盖等。这种类型的方法有两个最大的挑战，在效率上，当前人在设计测试用例的时候是基于需求文档设计的场景用例，虽然最终在执行的时候会天然映射到技术对象上，但当前绝大多数公司没有场景和这些技术对象的对应关系。还有一个问题是，预期输出也是来自于业务需求的，因此一个接口或者一个函数应该返回什么是正确的难以得知，也就是学术界所说的神谕问题。虽然可以使用上一次的返回结果作为oracle，但是当代码变动以后，在整个调用路径上会产生难以预测的影响，通过增量需求识别出哪些用例结果应该变化哪些不应该变化在实践中也需要投入大量的成本，所以往往当前这种方法生成的测试用例效果最好的是重构后的回归测试。面相需求文档的，也就是日常大家说的场景自动化，这种测试虽然可以规避上述问题，但是由于一个场景需要调用多个服务和中间件，测试环境的不稳定、测试数据的变更以及不合理的自动化架构会直接带来维护成本的高涨从而难以长时间的持续性的维护。再有在测试有复杂交互的场景时，即使在一开始设计了测试用例，在执行过程中通常也会根据一定的操作习惯和历史经验做额外的扩展，这也是探索性测试的底层逻辑。因此如果要找到一条可以匹配代码生成速度的测试方法，则需要从根本上解决上述两个维度的问题。
发布于 上海
4
3
10
未登录
友善发言
评论
加载中
