自动化测试分层思想所倡导的是对系统进行分层,针对不同层次选择合适的自动化类型进行测试的一种测试策略,同时自动化测试分层思想也与测试阶段(单元测试、集成测试、系统测试)具备相关性。项目的自动化测试覆盖程度取决于各分层自动化测试分层策略设计的合理性、全面性。
通常指的是API接口自动化测试,在分层自动化测试的应用中,接口自动化是最常见的自动化解决方案。
同时,结合数据驱动测试框架、关键字驱动测试框架可以满足大部分测试场景,包含含有复杂业务逻辑的功能的覆盖(B接口依赖A接口返回),同时降低测试代码的冗余。特别是在前后端分离的产品架构设计中,可以对功能点进行有效的覆盖,至于页面显示、页面元素布局、展示的验证可以通过手工测试或者其他工具覆盖。
UI-页面自动化测试
UI层是与用户进行交互的,用户通过与UI层交互使用系统功能。测试人员的大部分测试工作(黑盒测试)也集中在这一层。根据个人实践经验,大部分场景下都不推荐UI自动化,难以做到高效的维护,投入产出比不可控。关于UI自动化的三点建议如下:
优先考虑底层自动化覆盖,尽量不进行UI自动化覆盖。
优先考虑核心功能的自动化覆盖,降低非核心功能的自动化覆盖。
着重考虑自动化的可扩展性、易维护性设计。
首先,是否开展自动化,通常需要同时满足以下条件:
软件需求变动不频繁(超过10%的变动是频繁变动,同时10%并不是一个固定值,根据其维护、扩展成本适当调整阈值)
项目周期足够长
自动化测试用例可重复使用
同时,自动化测试的是否易于扩展、易于维护对其可持续性而言非常重要。
一方面,自动化测试的局限性体现在上述其开展的必要条件,如果在不满足其必要条件的背景下,开展自动化会发现自动化并不会提高测试效率,甚至可能加大了测试成本。
另一方面,UI自动化与接口自动化本身的局限性,UI自动化较接口自动化而言其具备覆盖率高的优势(接口测试无法覆盖页面元素、格式、数据),接口自动化较UI自动化而言具备高扩展、易维护、问题修复成本低的优势。
自动化测试的直接目的是围绕产品质量提高测试效率,其根本目的(效率转化)无外乎以下几点:
真正的实现项目人力投入的缩减
做更多更有意义的测试,比如更深入的需求分析、测试设计或者对测试左移、右移的投入;
适应开发模式的转变,比如类敏捷、devops、testops模式下的频繁迭代、持续部署、质量运营等。
请登录之后再进行评论