在我的上一篇文章中，我讨论了正确测试互联网产品所需的非测试知识。接下来，我们将讨论如何设计互联网产品的测试策略。
在开始今天的话题之前，先想一下单独讲解互联网产品测试策略的原因。互联网产品测试策略与传统软件产品测试策略有何区别？
研发流程的不同决定了测试策略的不同
直接回答互联网产品和传统软件产品的测试策略有什么区别这个问题会有点让人困惑。如果是的话，你可以先按照知其所以然、知我所强调的原则来总结一下。这两款产品的研发最大的区别是什么？
那就是互联网产品的“速度”。
在本专栏的上一篇文章中，我们了解到互联网产品的发布周期通常以天甚至小时来衡量，而传统软件产品周期通常以月甚至年来衡量。
由于发布周期的显着差异，传统的软件产品测试策略必然不适合测试互联网产品。两种测试策略的测试执行时间和测试执行环境应该显着不同。
例如，对于一个功能自动化测试用例，运行一轮完整的回归测试需要12个小时，但这根本不是问题，因为发布周期很长，还有足够的时间用于测试。
不用说，一个完整的回归测试可能需要12 个小时才能运行，即使GUI 测试用例的数量可能需要几天的时间，就像我们在思科进行传统软件测试时一样。完整回归测试近3000轮，API测试用例近25000个，运行所有测试用例需要近60个小时。
然而，对于互联网产品来说，发布过程通常包括代码静态扫描、单元测试、编译、打包、上传、下载、部署、测试的整个过程。显然，留给测试执行的时间非常有限，传统软件测试执行时间往往超过10个小时，这对于测试互联网产品来说完全不现实。
通常，互联网产品不应允许完整的回归测试运行超过4 小时。
那么如何才能有效减少测试执行时间，同时保证测试质量和测试覆盖率呢？
首先，它引入了测试并发机制，允许使用包含大量测试执行节点的测试执行集群同时执行测试用例。
测试执行集群可以简单理解为一组专门用于并发执行测试用例的机器。典型的测试执行集群由一个主节点和多个子节点组成。其中，主节点用于将测试用例分发到各个子节点，每个子节点用于具体执行测试用例。
现在很多互联网公司正在成立。
以上关于#软件测试11的相关内容摘自网络，仅供参考。相关信息请参见官方公告。
原创文章，作者：CSDN，如若转载，请注明出处：https://www.sudun.com/ask/92738.html
