敏捷: 谈谈UI自动化对于研发过程的应用

对于测试而言,常见的UI自动化场景是为了减少手工回归测试的范围和缩减成本开支.

对于敏捷过程, UI自动化是为了补全单元测试的不足而产生的.

简单而言:

　　在开发初期, 需要进行冒烟测试. 因此需要图形化的,用户界面的测试.

　　且对于单元测试而言, 覆盖更多的业务方面的测试是心有余力不足的. 尤其是对于测试维度而言, 单元测试就是single的. 但是对于业务而言, 业务本身就不可能是单维度的. 在处理多个场景时, 很难在单元层面进行完整模拟. 而且完整模拟一个业务流程, 已经不是单元测试了

 

很少有测试关注为什么会出现这么多测试工具和方法, 而是简单谈论方法论的使用和实际意义.

对于我而言, 我认为这种思考是有所欠缺的. 每个方法背后的痛点, 往往都是由于考虑问题不够深刻而产生的.

当然有很多公理证明了, 在软件开发中存在一些没有办法解决的取舍. 软件开发就是在和时间以及人员做斗争.

 

就UI自动化的痛点来说.

我认为常见的必然是以下两种情况之一或之和:

　　1. 缺乏文档

　　2. 遗留系统

从测试角度出发, 本质上来看, 没有文档, 没有在开发过程中考虑到之后的测试问题. 就是源于团队本身就是非敏捷的. 

而对于UI自动化人员而言, 就是在处理一个遗留系统.

 

为什么要对自己的系统没有信心呢? 因为一个遗留系统的特点就是:该系统是不置信的.

研发角度有很多处理遗留系统的方案, 都不能高效的解决问题. 但是至少可以一层层的剥离里面的内容:

　　1. 用新的可测模块进行替代测试

　　2. 基于UI层编写界面冒烟测试

　　3. 通过设计好的数据,形成的标准测试集, 对于功能进行测试

 

对于[3]而言, 似乎又回到了数据的问题上面. 对于数据而言. 标准的业务化数据是不实用的, 或者说, 使用业务数据进行开发, 会让我们没有信心.

因为业务上会有一些不允许的场景, 但是在编码时, 我们却需要覆盖这些不允许的场景.

如果你觉得不是这样, 那么请问: 你对业务有信心吗? 还是你觉得产品给你提的都是易解决的新需求?

诚然不能做过度设计, 但是对于单元代码, 进行多边界场景的测试是合理且必要的. 否则代码就是自己的弃婴.(已经抛弃了N多孩子的我...)