<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:media="http://search.yahoo.com/mrss/">
  <channel>
    <title>Visual Testing · Nhân Tài Đức</title>
    <link>https://jared.lynskey.co.nz/vi/tags/visual-testing/</link>
    <description>Những câu chuyện ngắn về kỹ thuật phần mềm và lãnh đạo đội ngũ kỹ sư — performance review, tuyển dụng và mở rộng team, CI/CD, giám sát DevOps và AI agent. Viết từ Seoul.</description>
    <generator>Hugo</generator>
    <language>vi</language>
    <copyright>© 2026 Nhân Tài Đức</copyright>
    <lastBuildDate>Wed, 28 Oct 2026 00:00:00 +1300</lastBuildDate>
    <atom:link href="https://jared.lynskey.co.nz/vi/tags/visual-testing/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Kiểm thử hồi quy giao diện (visual regression testing) với Playwright cho đội nhỏ</title>
      <link>https://jared.lynskey.co.nz/vi/posts/2024/2024-06-09-playwright-tests/</link>
      <guid isPermaLink="true">https://jared.lynskey.co.nz/vi/posts/2024/2024-06-09-playwright-tests/</guid>
      <pubDate>Sun, 09 Jun 2024 00:30:03 +0000</pubDate>
      <dc:creator>Jared Lynskey</dc:creator>
      <category>Visual Testing</category>
      <category>Small Teams</category>
      <category>UI Testing</category>
      <category>Playwright</category>
      <description>Kiểm thử hồi quy giao diện (visual regression testing) bằng Playwright: vì sao so sánh ảnh chụp màn hình lại là loại kiểm thử mang lại nhiều giá trị nhất cho đội nhỏ của tôi.</description>
      <content:encoded><![CDATA[<p>Bạn đẩy lên một thay đổi CSS chỉ có đúng một dòng, thế rồi một cái nút ở tận trang khác lặng lẽ vỡ giao diện. Không bài kiểm thử nào báo lỗi, khâu rà soát mã (code review) cũng không phát hiện ra, và một tuần sau bạn mới biết chuyện qua phản hồi của người dùng. Đội nhỏ nào cũng từng dính phải lỗi kiểu này.</p>
<p>Theo sách vở thì câu trả lời là viết thêm kiểm thử đơn vị (unit test). Tôi đang quản lý một đội lập trình nhỏ, và nói thật là viết kiểm thử đơn vị cho từng thành phần (component) và từng trạng thái bố cục là thứ xa xỉ mà chúng tôi không kham nổi. Thay vào đó, chúng tôi dựa vào kiểm thử trực quan (visual testing): chụp màn hình các trang, so với những ảnh chuẩn (baseline) đã biết chắc là đúng, rồi đánh dấu bản dựng nếu có pixel nào xê dịch ở chỗ lẽ ra không được xê dịch. Xét trên công sức bỏ ra, tôi chưa thử cách nào khác mà hiệu quả được như vậy.</p>

<h2 class="relative group">Vì sao ảnh chụp màn hình đáng đồng tiền bát gạo
    <div id="vì-sao-ảnh-chụp-màn-hình-đáng-đồng-tiền-bát-gạo" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#v%c3%ac-sao-%e1%ba%a3nh-ch%e1%bb%a5p-m%c3%a0n-h%c3%acnh-%c4%91%c3%a1ng-%c4%91%e1%bb%93ng-ti%e1%bb%81n-b%c3%a1t-g%e1%ba%a1o" aria-label="Cọc dấu">#</a>
    </span>
    
</h2>
<p>Cái hay nằm ở chỗ có rất nhiều thứ bạn không cần phải viết. Bài kiểm thử trực quan không kiểm tra từng phần tử riêng lẻ mà đánh giá cả trang như một tổng thể. Bố cục bị xô lệch, màu sắc bị đổi, giao diện bị vỡ trên màn hình có kích thước khác, các phần tử đè lên nhau: đó chính là những lỗi hay lọt qua khâu rà soát mã, mà viết kiểm thử đơn vị để bao phủ thì cực kỳ khổ sở. Với kiểm thử trực quan, tất cả đều hiện ra thành một bản so sánh khác biệt (diff) ngay trong pull request (PR).</p>
<p>Chi phí bảo trì cũng gần như bằng không. Bạn chỉ cần đặt ảnh chuẩn một lần, sau đó bài kiểm thử chạy trên mọi PR và lần nào cũng cho ra cùng một kết quả. Giao diện thay đổi có chủ đích? Cập nhật ảnh chuẩn rồi làm tiếp. Thay đổi ngoài ý muốn? Bản so sánh đã nằm sẵn trong PR, không ai phải bấm lòng vòng qua nửa trang web mới tìm ra.</p>

<h2 class="relative group">Kiểm thử trực quan không thay thế kiểm thử đơn vị
    <div id="kiểm-thử-trực-quan-không-thay-thế-kiểm-thử-đơn-vị" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#ki%e1%bb%83m-th%e1%bb%ad-tr%e1%bb%b1c-quan-kh%c3%b4ng-thay-th%e1%ba%bf-ki%e1%bb%83m-th%e1%bb%ad-%c4%91%c6%a1n-v%e1%bb%8b" aria-label="Cọc dấu">#</a>
    </span>
    
</h2>
<p>Kiểm thử đơn vị kiểm tra logic, còn ảnh chụp màn hình kiểm tra giao diện. Về lâu dài thì bạn sẽ cần cả hai. Nhưng nếu đội bạn nhỏ và phải chọn nơi để dồn những giờ làm việc đầu tiên, thì tính trên mỗi giờ thiết lập, kiểm thử trực quan cho độ bao phủ nhiều hơn bất cứ thứ gì khác. Nguyên tắc của tôi là: kiểm thử đơn vị dành cho phần logic nghiệp vụ (business logic) mà nếu hỏng thì hậu quả thật sự nghiêm trọng, còn lại cứ để kiểm thử trực quan lo.</p>
<p>Toàn bộ hệ thống chỉ có vậy: ảnh chuẩn, bản so sánh trên mỗi PR, và thỉnh thoảng bấm xác nhận &ldquo;ừ, chỗ đó là cố ý&rdquo;. Vậy mà số lỗi nó bắt được nhiều hơn hẳn những gì tôi dám kỳ vọng.</p>

<h2 class="relative group">Thông tin thêm và các liên kết hữu ích
    <div id="thông-tin-thêm-và-các-liên-kết-hữu-ích" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#th%c3%b4ng-tin-th%c3%aam-v%c3%a0-c%c3%a1c-li%c3%aan-k%e1%ba%bft-h%e1%bb%afu-%c3%adch" aria-label="Cọc dấu">#</a>
    </span>
    
</h2>

<h3 class="relative group">Kiểm thử trực quan với Playwright
    <div id="kiểm-thử-trực-quan-với-playwright" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#ki%e1%bb%83m-th%e1%bb%ad-tr%e1%bb%b1c-quan-v%e1%bb%9bi-playwright" aria-label="Cọc dấu">#</a>
    </span>
    
</h3>
<p>Tài liệu về kiểm thử bằng ảnh chụp (snapshot testing) của Playwright: cách chụp cả trang hoặc từng phần tử, so sánh với ảnh chuẩn, và cập nhật ảnh chuẩn khi giao diện được thay đổi có chủ đích.
<a href="https://playwright.dev/docs/test-snapshots"  target="_blank" rel="noreferrer">Kiểm thử trực quan với Playwright</a></p>

<h3 class="relative group">Các thực hành tốt khi kiểm thử với Playwright
    <div id="các-thực-hành-tốt-khi-kiểm-thử-với-playwright" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#c%c3%a1c-th%e1%bb%b1c-h%c3%a0nh-t%e1%bb%91t-khi-ki%e1%bb%83m-th%e1%bb%ad-v%e1%bb%9bi-playwright" aria-label="Cọc dấu">#</a>
    </span>
    
</h3>
<p>Lời khuyên của Playwright cho các bài kiểm thử có đụng tới cơ sở dữ liệu: tách riêng dữ liệu kiểm thử, dọn dẹp sau khi chạy xong, và giữ các bài kiểm thử độc lập với nhau để cả bộ kiểm thử luôn đáng tin cậy.
<a href="https://playwright.dev/docs/best-practices#testing-with-a-database"  target="_blank" rel="noreferrer">Các thực hành tốt khi kiểm thử với Playwright</a></p>
]]></content:encoded>
      <media:content url="https://jared.lynskey.co.nz/en/posts/2024/2024-06-09-playwright-tests/featured.jpg" medium="image" type="image/jpeg" />
    </item>
  </channel>
</rss>
