zoukankan      html  css  js  c++  java
  • 19 | 真实的战场:如何在大型项目中设计GUI自动化测试策略

    大型全球化电商网站的前端模块划分

    先了解大型全球化电商网站的前端模块划分,有助于设计GUI测试。

    前端架构按照不同的业务模块来划分,比如用户管理模块、商户订单管理模块、商户商品管理模块等。

    各前端模块都会使用项目自己封装的组件库,比如自定义开发的列表组件、登录组件、信用卡组件等。(模块组件库

    把自定义开发的所有组件都放在一个“公共组件库”中,为前端模块提供依赖。

    从代码库(Repository)的角度来看,各个前端模块都有各自独立的代码库,除此之外还会有一个公共组件的代码库。(模块组件代码库,公共组件代码库

    大型全球化电商网站的 GUI 自动化测试策略设计

    对大型网站来讲,GUI 自动化测试往往应该做得比较轻量级,GUI 测试通常只覆盖最核心且直接影响主营业务流程的 端到端(E2E )场景。

    前端组件 JavaScript 单元测试

    要从前端组件的级别来保证质量,也就是需要对那些自定义开发的组件进行完整全面的测试。

    最常用的方案是:基于 Jest 开展单元测试,并考量 JavaScript 的代码覆盖率指标。

    空页面(Dummy Page)测试

    完成单元测试后,往往还会基于被测控件构建专用的测试页面,在页面层面再次验证控件相关的功能和状态。

    • 先构建一个空页面,并加入被测控件,由此可以构建出一个包含被测控件的测试页面,这个页面往往被称为 Dummy Page;

    • 从黑盒的角度出发,在这个测试页面上通过手工和自动化的方式操作被测控件,并验证其功能的正确性。

    前端模块页面对象测试

    每一个前端模块,都会构建自己的页面对象库,并且在此基础上封装开发自己的业务流程脚本。这些业务流程的脚本,可以组装成每个前端模块的测试用例。

    以用户管理模块为例,测试用例的组装过程如下:

    • 首先,把用户管理模块中涉及到的所有页面,比如登录页面、用户注册页面等,按照页面对象模型的要求写成 Page 类;

    • 然后,利用这些 Page 类封装业务流程脚本,比如用户登录流程,用户注册流程等;

    • 最后,在 GUI 测试用例脚本中,调用封装好的业务流程脚本构成该模块的 GUI 测试用例。

    在这个阶段,测试用例需要完整覆盖该模块的所有业务逻辑以及相关的功能测试点,但是并不会实现所有测试用例的自动化。

    自动化测试用例的原则,通常是:优先选取业务关键路径以及 Happy Path 作为自动化测试的范围。在资源充裕的情况下,我们希望这个阶段的自动化率可以达到 70%-80%。

    前文提到过“GUI 的自动化测试往往只覆盖最核心且直接影响主营业务流程的 E2E 场景“,并且”GUI 测试遵循“手工测试为主,自动化为辅”的策略,而这里又建议说理想的自动化率应该达到 70%~80%,是不是有点前后矛盾的感觉。

    这里 70%-80% 的 GUI 自动化覆盖率是针对模块级别的要求;而“自动化测试为辅,手工为主,以及只覆盖核心业务场景”针对的是系统级别的 E2E 测试。

    端到端(E2E)测试

    组合各个前端模块,并站在终端用户的视角,以黑盒的方式使用网站的端到端(E2E)测试。

    • 一部分是,通过探索式测试的方法手工执行测试,目标是尽可能多地发现新问题;

    • 另一部分是,通过 GUI 自动化测试执行基本业务功能的回归测试,保证网站核心业务相关的所有功能的正确性。

    谁来开发这部分端到端的 GUI 自动化测试用例?

    成立一个专门的测试团队,负责这种系统级别的 GUI 测试。这样的团队,往往被称为 E2E 测试团队。

    E2E 团队不会从无到有地开发这部分 GUI 自动化测试的脚本,而是应该尽可能地利用各个模块已有的页面对象和业务流程脚本,组装端到端的 GUI 测试。

    大型全球化电商网站的 GUI 自动化测试脚本管理

    为了能够在端到端的 GUI 自动化测试中,复用各个模块的页面对象和业务流程脚本,必须考虑 GUI 自动化测试脚本应该如何组织

    将各个模块的页面对象和业务流程脚本放在各自的代码库中,并引入页面对象和业务流程脚本的版本管理机制,通常采用页面对象和业务流程脚本的版本号和开发版本号保持一致的方案。

    比如模块 A 的版本号是 V1.0.0,那么对应的页面对象库和业务流程脚本的版本号也应该是 V1.0.0。

    在端到端的 GUI 自动化测试脚本中,引用各个模块正确的页面对象和业务流程脚本的版本号,测试用例代码就可以直接调用模块的页面对象和业务流程脚本了。

    具体在测试项目中,模块版本的依赖往往是用 POM 来配置。

    下图展示了一个典型测试项目的 POM 文件中的版本依赖关系,其中引用了两个模块,appcommon 模块对应的就是上文提到的“公共组件库”,而 app.buy 对应的就是具体依赖的前端模块。

    总结

    首先,要从前端组件的级别来保证质量,也就是需要对那些自定义开发的组件进行完整全面的测试。通常前端组件会基于 Jest 做比较严格的单元测试。

    其次,每一个前端模块,都会构建自己的页面对象库,并且在此基础上封装开发自己的业务流程脚本。这些业务流程的脚本,可以组装成每个前端模块的测试用例。

    最后,把各个前端模块组合在一起之后,站在终端用户的视角以黑盒的方式使用网站的端到端的测试。端到端的测试应该尽可能多地重用各个模块的页面对象库和业务流程脚本来完成。

    而为了能够在端到端的 GUI 自动化测试中,复用各个模块的页面对象和业务流程脚本,我建议的方案是:对各个前端业务模块的页面对象库和业务流程脚本,实施版本化管理机制。


    来源于 极客时间 茹炳晟 软件测试52讲

  • 相关阅读:
    java如何计算对象的大小
    java多线程实现主线程等待子线程执行完问题
    再次理解多线程线程安全问题(理解java内存模型后)
    关于局部变量在循环里的生存法则
    【CSS3】transform-origin原点旋转
    面向对象编程(本章小结)
    引入在线编程和编译站点
    关于获取素数 一个小程序
    C++ I/O
    HDU2571
  • 原文地址:https://www.cnblogs.com/Uni-Hoang/p/13296592.html
Copyright © 2011-2022 走看看