对于很多做软件测试的同学来说，工作后第一个接触的就是Web类产品，然后才是包括诸如移动端APP、PC端Client产品等。那么，我们今天就以Web类产品为例，讲一讲测试体系建设的一些内容，让大家通过测试体系建设，更好的掌握这类产品的测试。
UI自动化测试文章源自玩技e族-https://www.playezu.com/194549.html
一提到自动化测试，无论哪个平台，无论什么终端，我们首先想到的就是基于UI的功能自动化测试，对于Web类产品也不例外。文章源自玩技e族-https://www.playezu.com/194549.html
对于UI功能自动化测试的工具选择，大家常用的是selenium，通过多种方式实现对页面元素的识别定位，以此实现功能测试用例的执行，和对测试用例通过与否的判断，进而完成整个功能自动化测试用例的建设。因为是测试体系建设方法论类的文章，对如何使用工具、如何搭建环境这类问题在这里就不展开阐述。文章源自玩技e族-https://www.playezu.com/194549.html
Web类产品的特点就是迭代发布节奏快，更新容易，所以，对于这种UI功能自动化测试的建设，维护的成本也相对较大。特别是对于产品正在快速迭代期，每周都会有持续多个版本或功能特性的发布更新，这样的自动化测试脚本维护的成本就更大。文章源自玩技e族-https://www.playezu.com/194549.html
因此，我们在做自动化测试用例规划时，要注意用例的选择，选择的原则特别注意以下几个方面：文章源自玩技e族-https://www.playezu.com/194549.html
核心测试用例。包括核心功能，主干流程，基础界面，功能入口。只有这样的用例，发现的问题才更重要，优先级更高，更需要快速修复。其他非核心用例，则不具备这样的特征，在自动化测试的建设过程中，处于更靠后的位置。文章源自玩技e族-https://www.playezu.com/194549.html
UI界面稳定。对于用户界面稳定的理解，更多的是变化有规律，或者不那么频繁，这样的测试用例维护成本也较低，一旦发生变更，也能更快的完成用例的同步修改。文章源自玩技e族-https://www.playezu.com/194549.html
回归频率高。对于影响面大，需要高频次回归的用例，也是需要有限实现的。任何一个小的变更，都需要回归这样的用例，都需要走这样的检查时，这样的用例是需要有限安排上自动化测试的。只有这样，才能把回归这部分用例的人力进行有效的释放，提高测试团队的测试效率。文章源自玩技e族-https://www.playezu.com/194549.html
在这几个原则的指导下，我们就可以在UI功能自动化测试建设时做到有的放矢，用最短的时间、最少的资源，实现自动化建设的效用最大化。文章源自玩技e族-https://www.playezu.com/194549.html
在UI功能自动化实现后，我们不仅可以利用这套自动化测试体系实现日常功能测试的回归验证，还可以进行包括操作系统、浏览器、机型、分辨率等在内的兼容性测试。我们可以与开发团队共享测试资源，让他们利用我们的自动化测试框架，实现功能开发完成后相关功能的自测验证。另外，我们还可以接入持续集成，将我们的自动化测试实现接入，代码提交测试后即可完成功能的自动回归验证，实现第一时间的功能验证与问题发现。文章源自玩技e族-https://www.playezu.com/194549.html
接口自动化测试
相较于UI功能自动化高昂的维护成本，接口的自动化测试成本就会低一些。因此，也是测试资源不那么充足时开展自动化测试的一个更好的选项。
接口自动化测试，摆脱了UI界面经常变更的束缚，稳定性更高。测试方法也相对简单成熟，利用自动化测试复用率更高。低门槛的测试工具，也让新人容易上手，设计实现自动化测试用例也都更简单。当利用接口自动化实现对接口的监控时，也容易在第一时间发现问题。
通过以上，可以看到接口自动化测试的种种优势。那么，接口自动化测试在实现过程中还有哪些需要注意的呢？
首先，是接口库的积累建设，需要对项目的接口信息进行统一的维护和管理。接口有哪些参数，参数有哪些要求，返回值有哪些正常的返回，有哪些异常的返回，错误码分别代表什么含义等等，都需要有统一的管理。这样，在实现自动化测试用例时，才有理有据，有「法」可依。
其次，与开发工程师共同维护接口文档，做到信息的有效共享。除了管理好自己的接口库，还要与开发工程师做有效的沟通和联动，这样出现接口变更时，才能在第一时间对测试用例做调整，避免对问题的误判。
还有，在测试平台建设过程中还可以注意对测试环境的区分。在平台建设中，通过对环境的管理，实现一套接口测试平台在多个环境并行使用，可以大大提高测试平台的利用率。 与此同时，在有些时候，测试用例与测试数据的分离，也是一个很好的经验。这样，当环境发生变化，抑或是测试数据出现配置变化时，不需要对测试用例进行调整，即可实现用例的切换。
最后，接口自动化测试，也是可以接入持续集成的。这样，无论是在提交测试后，还是在接口发布后，都可以进行例行的检查，实现问题第一时间的发现与解决。
性能测试
Web类产品的性能测试，与APP类产品的性能测试会存在一些差异，但也有一些相类似的地方。
比如，在打开时间维度，就可以关注一个页面打开的时间消耗，可以通过工具查看在打开页面过程中各个阶段的时间消耗，并对此进行针对性的优化改进。比如优化资源的请求顺序，资源的合理优化，cookies的裁剪等。
对此，可参考雅虎给出的网站优化加载速度法则的相关文章，或其他专门介绍网页性能测试的文章，本文不做展开阐述。
补充说明
对于Web类产品，还有一种是需要特别留意的，就是小程序。我们所接触的包括微信小程序、支付宝小程序、百度小程序等，也都是Web类产品。
对于这类产品，在做UI自动化测试时，注意微信版本的兼容性测试，在做性能测试时，可以做APP的打开加载时间、资源消耗的测试。这些都是有别于传统Web类产品测试所需要注意的。
写在最后
总的来说，Web类产品相较于APP类产品的测试较为单一，关注点也相对简单，所以测试体系也没有APP类产品那么复杂。但通过Web类产品的测试，可以让我们对测试的基础理论掌握的更扎实，需要我们在工作中多反思多总结，好让自己更快的成长。
评论