Element Template & tái sử dụng locator

1. Giảm trùng lặp locator

Để giảm trùng lặp locator (địa chỉ định vị phần tử) và tối ưu hóa khả năng bảo trì trên LLQ QA Platform, bạn cần áp dụng kết hợp các chiến lược sau dựa trên các tính năng cốt lõi của hệ thống:

1.1 Sử dụng Element Repository làm kho lưu trữ trung tâm

Đây là giải pháp quan trọng nhất. Thay vì viết locator (XPath) trực tiếp trong từng Test Script (hardcode), bạn phải lưu trữ chúng vào Element Repository.

Tái sử dụng: Element Repository là kho dùng chung cho toàn bộ dự án. Một phần tử được lưu tại đây có thể được gọi ra và sử dụng trong hàng trăm kịch bản kiểm thử khác nhau.

Cập nhật một nơi (Single Source of Truth): Khi thuộc tính của phần tử trên giao diện thay đổi, bạn chỉ cần cập nhật XPath trong Repository một lần duy nhất. Hệ thống sẽ tự động đồng bộ thay đổi đó đến tất cả các kịch bản đang tham chiếu tới phần tử này.

Cách thực hiện: Trong lúc cấu hình Test Script, tại khối Locator, luôn chọn kiểu dữ liệu là Repository Element thay vì nhập trực tiếp giá trị vào.

1.2 Sử dụng chế độ "Insert Update Healing" trong Smart Locator

Khi sử dụng công cụ Smart Locator để quét và thêm phần tử mới, việc chọn đúng chế độ lưu trữ sẽ giúp tránh tạo ra các phần tử trùng lặp.

Cơ chế: Tại trường Locator type trong màn hình Smart Locator, hãy chọn Insert Update Healing (hoặc Update Healing).

Tác dụng

• Hệ thống sẽ kiểm tra xem element đó đã tồn tại trong kho chưa.
• Nếu đã có, nó sẽ cập nhật lại thông tin thuộc tính và XPath mới (nếu có thay đổi) thay vì tạo ra một element mới trùng lặp.
• Nếu chưa có, nó sẽ lưu bổ sung element mới vào Repository.

1.3 Tận dụng Shared Steps (Bước chia sẻ)

Việc trùng lặp không chỉ xảy ra ở cấp độ Locator riêng lẻ mà còn ở các nhóm hành động (như chuỗi thao tác Login, Logout).

• Nguyên lý: Gom nhóm các bước kiểm thử thường xuyên lặp lại (ví dụ: Điền Username -> Điền Password -> Click Login) thành một Shared Step.
• Lợi ích: Bạn chỉ cần định nghĩa locator cho các phần tử này một lần trong Shared Step. Các kịch bản khác chỉ cần gọi lại Shared Step đó thông qua keyword Action Call. Điều này giảm thiểu việc nhiều người cùng khai báo locator cho cùng một nhóm chức năng.

1.4 Tổ chức Kho phần tử (Repository Structure) khoa học

Việc tổ chức kho lưu trữ lộn xộn sẽ khiến Tester khó tìm kiếm element đã có, dẫn đến việc tạo mới (duplicate) không cần thiết.

• Phân cấp theo màn hình/chức năng: Cấu trúc kho nên phản ánh luồng trải nghiệm người dùng, phân chia thư mục theo từng màn hình hoặc chức năng cụ thể.
• Kho chung (Common Repository): Tạo riêng một thư mục cho các phần tử dùng chung xuất hiện trên nhiều màn hình (ví dụ: nút Popup, Header, Footer, nút Confirm) để dễ dàng tái sử dụng.
• Đặt tên gợi nhớ: Đặt tên Element theo chức năng hoặc tên hiển thị trên giao diện (ví dụ: btn_login, txt_username) để dễ dàng tìm kiếm qua thanh Search khi cấu hình.

1.5 Chuẩn hóa bằng Element Template & Project Type

Sử dụng Element Template được định nghĩa trong Project Type giúp chuẩn hóa cách định vị phần tử ngay từ đầu.

Khi mọi thành viên trong team đều dùng chung một bộ Template (ví dụ: cùng một công thức sinh XPath cho Button), các locator sinh ra sẽ có cấu trúc giống nhau, giúp hệ thống dễ dàng nhận diện sự trùng lặp khi quét và hợp nhất dữ liệu.

2 Dễ maintain khi UI thay đổi

Để đảm bảo việc bảo trì (maintain) dễ dàng và hiệu quả khi giao diện người dùng (UI) thay đổi, LLQ QA Platform cung cấp các cơ chế và công cụ chuyên biệt giúp bạn chỉ cần cập nhật dữ liệu tại một nơi duy nhất thay vì sửa đổi hàng loạt kịch bản.

Dưới đây là các phương pháp chính để tối ưu hóa khả năng bảo trì:

2.1 Sử dụng Element Repository (Kho lưu trữ phần tử tập trung)

Đây là nguyên tắc quan trọng nhất. Thay vì viết cứng (hardcode) XPath trong từng dòng lệnh của kịch bản kiểm thử (Test Script), bạn lưu trữ các phần tử này vào Element Repository.

• Cơ chế: Kịch bản kiểm thử chỉ tham chiếu đến tên của phần tử trong kho (Ví dụ: Login_Page/Btn_Login).
• Lợi ích bảo trì: Khi UI thay đổi (ví dụ: nút Đăng nhập đổi ID hoặc Xpath), bạn chỉ cần vào Element Repository, tìm phần tử đó và cập nhật lại XPath mới. Ngay lập tức, tất cả các Test Script, Test Case đang sử dụng phần tử này sẽ tự động nhận diện thông tin mới mà không cần bạn phải mở từng kịch bản ra sửa.

2.2 Sử dụng tính năng "Update Healing" của Smart Locator

Khi giao diện thay đổi hàng loạt hoặc bạn không muốn sửa thủ công từng phần tử trong kho, bạn có thể dùng công cụ Smart Locator với chế độ Update Healing.

Cách hoạt động:

1.Mở Smart Locator và quét lại màn hình đã thay đổi giao diện.

2.Chọn chế độ Update Healing (hoặc Insert Update Healing).

3. Hệ thống sẽ tự động so khớp các phần tử đã có trong kho. Nếu phát hiện thay đổi về thuộc tính hoặc XPath, nó sẽ tự động cập nhật lại thông tin mới nhất cho phần tử đó mà không tạo ra phần tử trùng lặp.

• Lợi ích: Giúp cập nhật hàng loạt phần tử cực nhanh khi có sự thay đổi lớn về giao diện (ví dụ: dev đổi toàn bộ cấu trúc đặt tên ID).

2.3 Tận dụng Shared Steps (Bước chia sẻ)

Nếu sự thay đổi UI không chỉ nằm ở thuộc tính phần tử mà thay đổi cả luồng thao tác (ví dụ: Luồng Login cũ chỉ cần User/Pass, luồng mới yêu cầu thêm bước nhập Captcha), việc sử dụng Shared Steps là giải pháp tối ưu.

• Cách hoạt động: Bạn đóng gói các bước thực hiện chung (như Đăng nhập, Thanh toán) thành một Shared Step. Các kịch bản kiểm thử khác sẽ gọi lại Shared Step này thông qua keyword Action Call.
• Lợi ích: Khi luồng nghiệp vụ thay đổi, bạn chỉ cần mở Shared Step đó ra và sửa lại các bước (thêm/bớt hành động). Tất cả hàng trăm Test Case đang gọi đến Shared Step này sẽ tự động chạy theo luồng mới.

2.4 Chuẩn hóa bằng Element Template

Việc định nghĩa Element Template ngay từ đầu giúp việc bảo trì dễ dàng hơn khi cấu trúc code HTML/XML của ứng dụng thay đổi.

• Cách hoạt động: Template quy định công thức tìm kiếm (ví dụ: luôn tìm Button theo text hoặc id).
• Lợi ích: Nếu đội phát triển thay đổi quy tắc đặt tên ID trên toàn bộ ứng dụng, bạn chỉ cần cập nhật lại logic trong Template và dùng Smart Locator quét lại, hệ thống sẽ sinh ra các XPath mới chuẩn xác theo quy tắc mới.
• Tóm lại: Để dễ bảo trì khi UI thay đổi, chiến lược tốt nhất là: Lưu phần tử vào Repository + Dùng Shared Steps cho các luồng chung + Dùng Smart Locator (Update Healing) để cập nhật nhanh.

3. Cấu trúc Element Template

Dựa trên tài liệu hướng dẫn, cấu trúc của một Element Template trong LLQ QA Platform được chia thành hai phần chính: Thông tin chung (Metadata) và Cấu hình công thức (Config). Trong đó, phần Config là cốt lõi để hệ thống tự động nhận diện và tạo XPath. Nhấn Apps chọn Setting

Nhấn setting test chọn template mong muốn

Dưới đây là chi tiết cấu trúc:

3.1 Phần Cấu hình Công thức (Config)

Đây là phần quan trọng nhất, bao gồm 4 thành phần giúp hệ thống hiểu cách tìm kiếm, hiển thị và đặt tên cho phần tử:

Element path list (Danh sách XPath mẫu):

Là danh sách các mẫu XPath của element trên giao diện.

Hệ thống dùng thông tin này làm mẫu "đầu vào" để nhận diện xem một phần tử trên màn hình có khớp với loại template này hay không.

Result xpath list (Công thức tạo XPath kết quả):

Cấu hình công thức để hệ thống tự động sinh ra XPath định danh cho các element tìm được.

Cấu trúc của một công thức bao gồm 3 phần nhỏ:

• Tên công thức: Thường đặt theo thuộc tính sử dụng (ví dụ: by_text, by_id).
• XPath gốc (Root XPath): Phần cố định của XPath sẽ không thay đổi.
• Thuộc tính (Attributes): Các thông tin biến động (như name, type, value) được lấy từ element thực tế để điền vào công thức.

Result attribute list (Danh sách thuộc tính hiển thị):

Định nghĩa các thuộc tính sẽ được hiển thị ra cho người dùng thấy khi hệ thống tìm thấy element (ví dụ: hiển thị vị trí position, hiển thị text, id...).

Giúp người dùng kiểm tra nhanh thông tin element khi quét bằng Smart Locator.

• Test Element attribute list (Quy tắc đặt tên tự động):

Cấu hình các thuộc tính được sử dụng để tự động đặt tên cho element khi lưu vào kho (Repository) qua Smart Locator.

Ví dụ: Có thể cấu hình để tên element là sự kết hợp giữa name và class của phần tử đó.

3.2 Phần Thông tin chung (Metadata)

Đây là các thông tin định danh và phân loại template:

• Project Type: Dự án chứa template (Ví dụ: Dự án Web, Dự án Mobile).
• Element Group: Nhóm của template (Ví dụ: Nhóm Button, Nhóm Input) để hỗ trợ tìm kiếm nhanh hơn.
• Platform: Nền tảng áp dụng (Web, Android, iOS, Windows, API, JDBC...).
• Code: Mã định danh duy nhất (không thể sửa sau khi tạo).
• Name: Tên gợi nhớ của Template (Ví dụ: vcb_button_web).
• Status: Trạng thái hoạt động (Active/Inactive).

Việc cấu hình đúng cấu trúc này cho phép công cụ Smart Locator quét hàng loạt phần tử trên màn hình và tự động sinh ra XPath chính xác theo chuẩn dự án mà không cần làm thủ công.

4 pdate UI (Chỉ sửa một chỗ)

Để đạt được mục tiêu "Update UI (chỉ sửa một chỗ)", nguyên tắc cốt lõi trên LLQ QA Platform là không được viết trực tiếp (hardcode) XPath vào kịch bản kiểm thử. Thay vào đó, bạn bắt buộc phải sử dụng Element Repository (Kho lưu trữ phần tử).

Dưới đây là cơ chế và quy trình thực hiện cụ thể dựa trên tài liệu:

4.1 Cơ chế hoạt động: Tại sao chỉ cần sửa một chỗ?

Khi bạn lưu trữ các phần tử (nút bấm, ô nhập liệu...) vào Element Repository, kho này đóng vai trò là nguồn dữ liệu trung tâm duy nhất.

• Tham chiếu: Các kịch bản kiểm thử (Test Script) sẽ không chứa XPath thực tế, mà chỉ chứa "đường dẫn tham chiếu" đến phần tử trong kho (Ví dụ: Login_Page/Btn_Login).
• Tự động đồng bộ: Khi giao diện (UI) thay đổi làm sai lệch XPath, bạn chỉ cần cập nhật lại thông tin phần tử trong Repository một lần duy nhất. Hệ thống sẽ tự động áp dụng thông tin mới này cho hàng trăm kịch bản kiểm thử đang sử dụng phần tử đó mà không cần bạn phải mở từng kịch bản ra sửa.

4.2 Quy trình thực hiện để đảm bảo "Sửa 1 chỗ"

Bước 1: Lưu trữ Element vào Kho (Repository). Thay vì dùng ngay, bạn phải đưa element vào kho trước. Cách nhanh nhất là dùng Smart Locator kết hợp với Element Template:

1.     Sử dụng Smart Locator để quét màn hình.

2.     Chọn Project Type và Element Template để hệ thống tự nhận diện và sinh XPath chuẩn.

3.     Lưu các phần tử này vào một thư mục trong Element Repository (Ví dụ: Màn hình Đăng nhập).

Bước 2: Sử dụng "Repository Element" trong Kịch bản (Quan trọng nhất). Đây là bước quyết định việc bảo trì dễ hay khó. Khi cấu hình các bước trong Test Script (ví dụ: keyword Click hoặc Send Keys):

1.     Tại khối Locator, chọn kiểu dữ liệu Repository Element, hệ thống hiển thị button Element Repository.

2. Chọn phần tử từ danh sách đã lưu trong kho

Bước 3: Cập nhật khi UI thay đổi

Khi ứng dụng cập nhật giao diện (ví dụ: Dev đổi ID của nút "Lưu" hoặc thay đổi cấu trúc HTML):

1.     Truy cập vào Element Repository.