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

组件 -> 模块 -> 端到端

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

        Jest 是由 Facebook 发布的，是一个基于 Jasmine 的开源 JavaScript 单元测试框架，是目前主流的 JavaScript 单元测试方案。

        完成单元测试后，往往还会基于被测控件构建专用的测试页面，在页面层面再次验证控件相关的功能和状态。这部分测试工作也需要采用自动化的形式实现，具体的做法是：

•         先构建一个空页面，并加入被测控件，由此可以构建出一个包含被测控件的测试页面，这个页面往往被称为 Dummy Page；
•         从黑盒的角度出发，在这个测试页面上通过手工和自动化的方式操作被测控件，并验证其功能的正确性。

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

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

•         首先，把用户管理模块中涉及到的所有页面，比如登录页面、用户注册页面等，按照页面对象模型的要求写成 Page 类；
•         然后，利用这些 Page 类封装业务流程脚本，比如用户登录流程，用户注册流程等；
•         最后，在 GUI 测试用例脚本中，调用封装好的业务流程脚本构成该模块的 GUI 测试用例。

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

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

•         一部分是，通过探索式测试的方法手工执行测试，目标是尽可能多地发现新问题；
•         另一部分是，通过 GUI 自动化测试执行基本业务功能的回归测试，保证网站核心业务相关的所有功能的正确性。

脚本管理

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

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