【专访】：揭秘自动化测试利器：Playwright 专访之旅
前言在软件测试领域，自动化测试正发挥着日益重要的作用。本次专访聚焦自动化测试，尤其是热门的 Playwright 工具。我们将与专家深入探讨自动化测试工具的选择因素、持续集成中的经验、应对项目需求变更的策略、Playwright 的优势与难题，以及自动化测试的推广、新人建议和未来发展趋势等关键问题，为广大测试从业者带来宝贵的见解和启示。1. 在选择自动化测试工具时，您主要考虑哪些因素？a)易用性：工具应该易于上手，从而减少团队成员学习和后续自动化测试用例的维护成本。
b)集成能力：工具应该能够与其他开发和测试工具(如Jenkins、缺陷跟踪系统等)集成。
c)支持的测试类型：根据项目需求，工具支持的不同类型的测试，如UI测试、接口测试、性能测试等。
d)社区和文档：活跃的社区和详尽的文档可以帮助我们快速解决在工具使用过程中遇到的问题。
e)成本：工具的许可费用。
static/image/hrline/3.gif
2. 对于持续集成和持续部署中的自动化测试，您有哪些经验和建议？在我的QA职业生涯中先后在不同的团队里落地了接口和UI的分层自动化测试。对CI(持续集成)/CD(持续部署)的流水线中实施自动化测试，我有以下几点建议：a)选择合适的自动化测试工具：根据项目需求和团队技术背景选择合适的工具至关重要。工具应支持多种测试场景，且易于与其他系统集成。b)测试用例的设计：设计可维护，模块化且可扩展的自动化测试架构，采用页面对象模式(PageObject Model)、模块化设计和数据驱动方法提高测试代码的可读性和复用性。c)团队协作和沟通：CI/CD的实施要求团队成员之间有更高的沟通和协作，代码库和自动化测试用例的维护需要团队共同努力。d)持续学习和改进：CI/CD是一个不断发展的领域，团队需要持续学习和改进其CI/CD实践，关注行业内的最新趋势和技术，以便将新的最佳实践引入团队中。
static/image/hrline/3.gif
3. 当项目需求频繁变更时，如何保证自动化测试的有效性？a)选择合适的业务场景：并不是所有的业务都适合自动化测试，选择主干且不易频繁变动的部分业务使用自动化测试用例进行覆盖。b)自动化测试用例的模块化设计：将测试脚本拆分成独立的模块，每个模块负责一个具体的功能。这样当需求变更时，只需调整受影响的模块，而不必重写整个脚本，从而提高脚本的复用性和灵活性。c)建立变更管理流程：确立清晰的变更控制流程，包括变更的影响评估以及变更实施和验证的步骤。
d)评估变更的影响：变更实施后，需要持续评估这些变更对整体测试进度的影响，并及时调整测试策略。
持续集成：将自动化测试脚本集成到持续集成/持续部署流程中，确保及时发现变更导致的问题。
static/image/hrline/3.gif
4. 您是如何接触到自动化测试领域，尤其是Playwright 的呢？是什么契机让您决定深入研究它？我接触自动化测试是机会的偶然也是测试工程师技能发展的必然，第一次接触自动化测试是2015年宁波银行的浏览器兼容性自动化测试项目。在之后的这些年里自动化测试技能更是成为了测试工程师发展路上必备的技能之一。至于深入研究Playwright，则是因为实际工作中的需要了。在使用Selenium WebDriver的这些年里，其执行速度慢、驱动和浏览器版本的一致性以及断言困难一直是困扰我们QA团队的难题。时至2024年，我再次深入对比各个开源的UI自动化测试工具时发现Playwright完美地解决了Selenium这么多年悬而未决的技术难点，进而决定从Selenium完全转向了Playwright。
5. 在您看来，Playwright 相比其他自动化测试工具的突出优势有哪些？a)跨浏览器支持：Playwright支持所有主流浏览器，包括Chromium、WebKit和Firefox，并且无需额外安装驱动程序。
b)自动等待：Playwright的操作会等待元素准备就绪，提高了测试的可靠性并简化了测试脚本的编写 。
c)并行执行：Playwright支持并行测试，可以在单个浏览器实例中创建多个浏览器上下文，实现隔离的同时提高效率。
d)简洁的API：Playwright API的设计简洁直观，易于学习和使用，使得编写和维护测试脚本更加高效 。
static/image/hrline/3.gif
6. 在使用 Playwright 进行自动化测试的过程中，您遇到过哪些比较棘手的技术难题？又是如何解决的呢？a) 元素定位问题：页面元素可能会因为异步加载、页面结构变化等原因导致难以定位。可以通过Playwright提供的多种定位策略(如locator()，filter()等)来解决这个问题。实例1：详情页关闭的页面元素在UI自动化用例执行过程中不稳定，不能保证必定成功。
解决方案：判断详情页关闭的元素是否可见，若可见则点击它，否则执行其他动作。
示例代码：<font size="5"># 关闭详情页
def close_detail(self):
is_close_visible = self.page.locator('//div[@class="title__close-btn"]').is_visible()
if is_close_visible:
self.click_by_locator('//div[@class="title__close-btn"]')
else:
pass</font>
实例2：断言详情页的文本信息，但文本组件xpath路径很长，难维护。
解决方案：使用Playwright提供的filter()函数缩小元素的定位范围。
示例代码：<font size="5"># 预收详情获取预收余额并断言
def assert_adjust_pre_fund_count(self, customer_name, expect_key):
self.go("FUND_ADVANCE_COLLECTION")
self.search_on_list(customer_name)
self.click_button("查看")
self.new_on_detail("校正")
count_text = (self.page.locator('//div[@class="sub-title"]/span').filter(has_text="预收款余额")
.locator("//em").inner_text())
with soft_assertions():
assert_that(str(count_text)).contains(self.adjust_result)</font>
实例3：页面中有有class属性相同的多个组件，难以逐个区分。
解决方案：使用Playwright提供的locator()函数定位一组元素，再根据索引值区分具体的元素。
示例代码：<font size="5"># 合同编辑页，获取可添加金额
def get_fund_on_order_update_page(self, fund_type):
fund_element_list = self.page.locator('//div[@class="memo-text_block"]').locator("visible=true")
if str(fund_type) == "应收":
return fund_element_list.nth(0).locator("//span").inner_text()
elif str(fund_type) == "回款":
return fund_element_list.nth(1).locator("//span").inner_text()
elif str(fund_type) == "预收":
return fund_element_list.nth(2).locator("//span").inner_text()
else:
pass</font>
b) 测试脚本维护：随着产品的迭代，测试脚本必然需要持续性地维护。可以通过模块化和参数化测试脚本、使用Page Object模式等方法来提高脚本的可维护性。我在开发UI自动化用例的过程中，深感Page Object模式落地必要性和重要性。以我资深所在团队为例，我们的UI自动化代码结构如下图所示。
左侧Base包里封装了基础操作；test_fund_manage目录下是具体的测试用例。在产品迭代的过程中，若是需要增加新的UI自动化用例来覆盖业务场景，大多数时候我们直接在用例层(即test_fund_manage)添加用例就行；如果需要维护底层的共用方法，则需要我们先修改Base包下封装的函数文件后再同步更新到用例层。在使用PO(PageObject)模式的情况下，给我们维护UI自动化用例节省了时间。
static/image/hrline/3.gif
7. 能否分享一个您在实际项目中成功运用Playwright 进行自动化测试的案例？具体取得了哪些显著的成果？
上图是我所在团队目前维护的UI自动化用例的执行结果，从图里可以看出在产品迭代的过程中执行结果并不稳定，就结果来分析，最大的因素是因为我的团队最近2个季度进行了大量的UI改造！作为UI自动化用例的维护者，这段时间是非常具有挑战性的，可能我们维护UI自动化用例的速度还赶不上UI的变化速度。这就客观地要求我们对UI的自动化用例要精心设计，UI自动化用例所覆盖的业务场景尽量是主干和核心的业务。最后，我所在的团队在拥抱Playwright之后，明显感觉有到的收益是持续集成的结果反馈速度的提升和自动化用例的维护难度的降低。以我所在的QA团队为例，我们对自己的核心产品销帮帮CRM落地了接口和UI的自动化测试，今年在自动化测试实施过程中发现的bug如下：
在2024年，分层自动化(接口+UI)用例共计发现了48个bug，在拥抱Playwright之后，我们可以更加快速的得到UI自动化用例的执行结果反馈了。
static/image/hrline/3.gif
8. 在团队中，如何推广自动化测试并提高团队成员的自动化测试意识？a)明确自动化测试的价值：强调自动化测试在减少重复性工作、确保软件质量方面的重要性。展示自动化测试如何帮助团队更快地响应需求变更和市场变化。b)技能培训：不定期举办自动化测试相关的培训，帮助团队成员了解自动化测试的基础知识和最佳实践。
c)持续改进：定期收集团队成员对自动化测试的反馈，并根据反馈进行改进，不断调整和优化自动化测试策略。
d)以身作则：作为测试Leader，亲自参与自动化测试的实施，为团队树立榜样。展示如何有效地使用自动化测试来提高工作效率和软件质量。
static/image/hrline/3.gif
9. 对于刚进入自动化测试领域的人，您有什么建议？a)稳固基础：熟悉一门编程语言(如Python、Java)，熟练掌握自动化测试用例的设计。
b)理解自动化测试的适用性：了解自动化测试最适合的场景，比如回归测试、压力测试。
需要认识到自动化测试不是万能的，有些测试场景更适合手动进行。
c)持续学习和实践：自动化测试领域不断发展，持续学习新的技术和工具是非常重要的。通过实际项目实践来提高技能，参与开源项目或个人项目也是很好的学习方式。
自动化测试是一个长期学习和实践的过程，不断积累经验，逐步提高自己的技能和效率。
static/image/hrline/3.gif
10. 您认为未来自动化测试的发展趋势是什么？a)人工智能和自动化测试技术的融合：AI技术的应用将使得自动化测试更加智能，能够自动生成测试用例、智能识别缺陷、预测潜在的故障点，从而提高测试效率和准确性。b)自动化用例的自愈技术：自愈技术能够发现测试脚本执行中的非预期错误，并在无需人工干预的情况下自行更改，从而将自身恢复到更好的运行状态。这种技术可以减少测试失败率并提升测试稳定性。例如，利用AI技术，测试脚本可以“学习”和“适应”用户环境的变化，实现自我修复。
c)低代码/无代码测试自动化：融合了AI的新兴工具的出现使得非专业开发人员也能够参与到自动化测试中，降低了自动化门槛，使得更多的人可以参与到自动化测试的实施中来。
嘉宾果照连接：点击查看>>> 感谢分享，找时间深入学习下 感谢分享 :handshake:handshake 进来看帅哥，顺便学习下
页:
[1]
