朋友，您还记得小时候听过的《三只小猪》的故事吗?面对大灰狼的来袭，只有建造了坚固的房屋(基础设施)的第三只小猪，才能逃过一劫。现如今，面对各种高速发展的持续集成与交付要求，我们同样需要构建好具有自动化特征的基础环境，以便快速地开展各种高性能的测试。
下面，我们来看看如何通过目标、技术和团队的准备，在快速增长的环境中，实现敏捷地高性能测试与发布。文章源自玩技e族-https://www.playezu.com/203736.html
定义高性能测试文章源自玩技e族-https://www.playezu.com/203736.html
从理论上说，那些具有高增长特征的初创企业最渴望高性能的测试。它们通常具有如下的“敏捷”特征：文章源自玩技e族-https://www.playezu.com/203736.html
- 混乱状态–需要适应瞬息万变的内、外部环境。
- 更少的用时–所有问题都需要得到全员的重视，并需要得到及时的解决。
- 更少的资源–由于现有资源有限，因此需要善于向外部“借势”，以促进当前项目的集成与交付。
- 市场压力–需要了解和评估外部风险，以迅速调整内部策略。
- 奖励–善于发现点滴改进，及时反馈并鼓励整个团队。
为何要进行高性能测试?文章源自玩技e族-https://www.playezu.com/203736.html
纵观整个行业，应用业务技术在过去十年中发生了如下巨大的变化：文章源自玩技e族-https://www.playezu.com/203736.html
- 使用范围–当前的应用服务往往可以运行在多个平台(Web应用端、或移动设备)上，而非某个专有的应用程序、或单个浏览器上。
- 发布频率-我们经常按需且频繁地发布应用程序。
- 流程–我们已经从瀑布式的开发方式，转变成为了持续交付。
- 框架-过去的单栈本地部署(singe-stack on-premise)软件模式，已经转变成为如今使用开源、基于云端的开发与交付模式。
总之，我们沿用了十年的“最后再进行测试”的模式，已经不再行之有效。我们正在建立一种新的测试模式。文章源自玩技e族-https://www.playezu.com/203736.html
如何实现高性能测试文章源自玩技e族-https://www.playezu.com/203736.html
为了满足快速增长的环境需求，软件团队需要尽早了解现有的情况，以着手解决各种矛盾和问题。例如：您既可以使用思维导图将情况可视化，也可以通过划分短期和长期目标，让功能性团队专注于测试，让框架团队专注于系统的长期架构。文章源自玩技e族-https://www.playezu.com/203736.html
另一个值得关注的目标是：如何通过测试左移，尽早地发现缺陷。为此，我们需要了解现有的工具和需要添置的工具，软件质量的行业标准，本团队当前在构建自动化架构方面的实力，以及如何通过AI和机器学习(ML)的支持来提高效率。文章源自玩技e族-https://www.playezu.com/203736.html
建立团队
接下来，我们来讨论如何建立一支高性能测试的团队。
过去我们依靠的是专职的质检(QA)服务团队。如今，我们需要配备了集成Pod的真正敏捷团队。质量工程师作为他们的团队资源，在整个开发和交付过程中提供协助。在团队中，我们需要有人熟悉行为驱动设计(behavior-driven design)和测试驱动设计(test-driven design)，有人会选择并使用自动化工具，有人需要考虑可测试性设计(design-for-testability)。
由于测试自动化的大部分会涉及到框架，因此我们需要熟悉构建代码的技能集，通过自动识别元素定位符(self-identifies element locators)，来构建用于自动化控件的钩子(hooks)，进而确保每次构建的一致性和实现自动化的可重复性。
测试自动化
过去，我们需要从单个供应商那里购买一整套测试工具。如今，开源的解决方案为自动化提供了丰富的资源。开源的方式不但可以降低维护的成本，而且能够让您更快、更容易地交付出具有可扩展性的软件产品。作为开源工具的“衍生品”，用户社区往往能够提供某些工具的最佳实践，以及各种宝贵的课程可供学习。
通常，我们可以在软件部署过程中的如下方面实现自动化：
- 断言行为(Assertions on Action)
- 初始化和清理
- 数据建模与模拟
- 配置
- 各种安全建模的抽象
- 包和帮助
- API的使用情况
- 各项面向未来的功能
- 本地和云端设置
- 速度
- 各种调试功能
- 跨浏览器
- 模拟器与真实设备
- 内置的报告与插件
行业标准
如今，对于自动化测试，业界基本上形成了如下四种类型的标准：
- 质量–至少要能够通过全部测试的90%。
- 运行时间–所有测试的平均运行时间应控制在两分钟之内。
- 平台覆盖率–平均覆盖五个关键性的被测平台。
- 并发性–在使用高峰期，测试至少要占用75%的可用运能。
生产环境的测试
您是否考虑过将测试移至生产环境(Shift Right)?我们提出该方法的原因有如下四个方面：
- 功能标记–在生产环境中进行测试，可以采集到真实的数据，以用于测试。
- 流量分配–我们可以逐步引入新的功能，并在不影响整个客户群体验的情况下，针对被测案例，跟进获取到的部分目标用户的实时数据。
- 内部测试(Dog Fooding) –采用CDN之类的快速部署功能，将内部用户引导到新的功能服务上。
- 净减少–通过减少额外的开销，使应用程序可以使用真实的数据集进行测试，并且能在不影响整个客户群的情况下快速定位问题。
总之，生产环境中的测试，可以让累计的大型发布，变成一组组基于通用代码的小型迭代。由于有不同职能的人员参与测试，因此也确保了客户群不会因为大幅度升级而感到不适。
人工智能(AI)/机器学习(ML)
AI/ML工具的使用不但能够提高整个团队的工作效率，而且还能够满足高性能测试环境的质量需求。其中，Applitools就是一个被AI赋能了的测试工具。它通过自动化视觉AI，来开展各种回归式的视觉测试，自动验证页面的提交，进而帮助企业以更低的成本，更快地发布软件项目。例如：某个医药网站有着上百个介绍药物适应症和注意事项的页面。为了确保这些页面一致性，我们可以使用Applitools去进行验证。它可以在不到12分钟的时间内完成完整的视觉回归，并运行350个测试案例，其中包括2500项检查。而我们如果采用手动验证的话，则需要六个小时以上。
ReportPortal.io
作为一个统一的自动化测试平台，ReportPortal.io可以实现报告的收集，分析，可视化，以及集成多种测试框架，其中包括：TestNG和Selenium等。在实际应用中， Reportportal.io能够显示一天中不同时段的测试运行方式，发现其中的错误，进而帮助团队实现无缝的发布和改善其统计的信息。同时，Reportportal.io中任何失败的测试用例，都可以被作为测试结果日志，直接链接到Reportportal.io的用户界面中。
此外，我们可以配合使用行为驱动设计(BDD)，来描述被测功能的所需行为，进而满足客户所需的高性能和高可用性。
设立质量目标
我们在快速增长的环境中，需要事先设立软件的质量目标，以满足用户和运行环境的需求。其中包括：
- 有分布式质量检查小组，提供7*24的质量检查支持。
- 有专门从事测试的SDET(软件测试开发人员)团队。
- 有一个能够简化任何POC(为观点提供证据)的即插即用式强大框架。
- 一个使用Travis(自动化集成部署服务)测试的稳定管道。
- 通过完全自动化将回归的时间减少90%。
建立团队和技术栈
当然，为了实现上述目的，我们需要雇用一个具有开发素养和测试素养的团队，也就是说，他们应当同时具备编程和测试自动化的相关能力。同时，我们在技术栈方面的投入包括如下方面：
- Python和Selenium WebDriver。
- BDD。
- 能够在云端运行的Browserstack。
- 针对视觉回归的Applitools。
- Jenkins、Travis和Google Drone for CI。
- Jira和TestRail的相关文档。
在此基础上，我们可以确定CI/CD的四项成功标准：
- 速度与并行化(parallelization)。
- BDD易于调试与阅读。
- 在CI/CD中实现跨浏览器、跨设备的覆盖。
- 实现视觉验证。
为CI/CD测试设定QA期望
在CI/CD的环境中，测试和构建往往并非同步进行的。因此，我们需要事先设定好构建与测试的频率。您可以借鉴如下公司的设定标准：
- 质量检查人员每小时针对最新的版本运行73次测试，以检查目标站点是否能正常运行。
- 任何新的构建都需要在6种跨浏览器上试运行，并确保涉及到所有的关键性业务路径。
- 除部分测试外，每晚例行执行300个回归测试。
当然，上述只是某些个案，您可以根据自身企业和项目的特点，不断地进行增加和完善。
结论
俗话说：“工欲善其事，必先利其器”。正如我们开头提到的《三只小猪》的故事那样，要想在高速增长的公司内部，让质量工程师能够迅速地开展成功有效的高性能测试，我们需要对自动化、团队人员、AI/机器学习、乃至基础架构，事先进行有针对性的投资、改造和完善。
【原标题】Acing High-Performance Tests for CI/CD (作者: Michael Battat )
评论