Test data: Một trong bốn thành phần quan trọng tạo nên test automation (Cập nhật 2026)

Last updated on January 16th, 2026 at 03:12 pm

Dữ liệu thử nghiệm (test data) quan trọng trong kiểm thử tự động (automation testing) cũng như kiểm thử thủ công (manual testing). Với việc cân nhắc kiểu dữ liệu ngay từ đầu cho test data: dữ liệu động hay dữ liệu tĩnh sẽ giúp test code rõ ràng, dễ dàng mở rộng và maintain về sau.

Cybozu Vietnam sử dụng framework WebdriverIO để thực hiện việc tự động hóa. Về tổng thể triển khai chúng ta sẽ đi qua 4 thành phần: test spec, test flow, page object và test data. Trong bài viết này chúng ta tìm hiểu về test data, sử dụng đồng thời dạng JSON object và Entity data model.

Nội dung trong bài này được viết dựa trên sản phẩm Garoon: phần mềm hỗ trợ làm việc nhóm, một trong các sản phẩm chủ lực của tập đoàn Cybozu. Bạn có thể thử trải nghiệm online để biết thêm về sản phẩm.

Test data là gì?

Để hiểu rõ về test data là gì, chúng ta sẽ cùng xem kịch bản test “Thêm một cuộc hẹn (appointment) vào lịch (schedule)“ thuộc module Schedule dưới đây:

[step 1] Login vào sản phẩm Garoon của Cybozu.

Tại step này bạn cần chuẩn bị test data là tài khoản sử dụng để login vào Garoon. Cụ thể ở đây là:

• login name: “brown”
• password: “brown”

→ Như vậy đến đây ta có thể hình dung rằng test data là hai giá trị dùng để đăng nhập Garoon, “cụ thể” và “xác định trước”

[step 2] Truy cập vào module Schedule, click thêm appointment.

Tại step này bạn cần chuẩn bị test data là thông tin về appointment mà bạn muốn thêm vào. Cụ thể ở đây là:

• Start-time: “Sat, April 17, 2021 8:00 AM”
• End-time: “Sat, April 17, 2021 9:00 AM”
• Subject: “Training automation“
• Attendees: “Foster Brown, Sheldon Ricky“
• Facilities: “Reception Room“
• Notes: “This is an important meeting“

Sau khi điền test data, click Add button để hoàn thành việc thêm mới appointment.

[step 3] Tại màn hình Appointment details, bạn cần xác thực (verify) lại appointment được thêm vào thông tin đúng hay không?

Tại step này bạn cần chuẩn bị data để verify. Cụ thể ở đây là:

• Start-time: “Sat, April 17, 2021 8:00 AM”
• End-time: “Sat, April 17, 2021 9:00 AM”
• Subject: “Training automation“
• Attendees: “Foster Brown, Sheldon Ricky“
• Facilities: “Reception Room“
• Notes: “This is an important meeting“

Trong trường hợp của test case này, data cho bước verify này giống với dữ liệu để thêm appointment ở step 2.

Trên đây là một kịch bản test mà chúng tôi đã thực hiện automation tại Cybozu.

Test data chính là các giá trị đã được xác định cụ thể sử dụng trong test case, như: “brown“, “Sat, April 17, 2021 8:00 AM”, “Training automation“…

Bạn có thể thấy test data xuất hiện xuyên suốt quá trình thực hiện test: từ bước chuẩn bị đến bước verify.

Thử đặt bạn trong tình huống cần hiện thực automation cho kịch bản này, bạn sẽ bố trí các test data này như thế nào trong source code?

Tại đây, chúng tôi trình bày cách mà test data được triển khai tại Cybozu:

Công thức

Test data = Data-credential(*1) + Data-test-case(*2) [+ Data-system-settings(*3)] [+ Data-initialization(4*)]

Mô tả

*1: Data-credential là các dữ liệu về user account dùng để login vào sản phẩm test (Product under test).

*2: Data-test-case là các dữ liệu sử dụng trong từng bước thực hiện test case

*3: Data-system-settings. Đối với đặc thù của sản phẩm Garoon của Cybozu, đôi khi chúng tôi cần thay đổi những system setting trước khi chạy test case. Đây là những data phục vụ cho hành động này.

*4: Data-initialization. Data này không chỉ sử dụng ở một hoặc một vài test case, mà nó có thể dùng tất cả những test case có nhu cầu. Nó được khởi tạo tập trung trước khi tất cả test case được khởi chạy. Ví dụ: facility, attendees…. là những dữ liệu có thể sử dụng ở tất cả test case thuộc về Schedule module.

Tóm lại, tùy thuộc vào đặc thù của sản phẩm chúng ta thực hiện automation testing mà test data có thể được tổ chức theo những cách khác nhau. Việc tổ chức data tốt sẽ giúp cho việc thực thi kịch bản test diễn ra mạch lạc hơn.

Các loại cấu trúc của test data

Hiện tại, Cybozu sử dụng 2 loại cấu trúc dữ liệu để khởi tạo data:

JSON objects

Chúng ta dễ dàng khởi tạo data bằng cách truyền vào các cặp {"key": "value"}. Ví dụ dưới đây là data cho test case thêm vào Schedule một appointment bên trên:

Copy

{
  "Start-time": "Sat, April 17, 2021 8:00 AM",
  "End-time": "Sat, April 17, 2021 9:00 AM",
  "Subject": "Training automation",
  "Attendees": "Foster Brown, Sheldon Ricky",
  "Facilities": "Receiption Room",
  "Notes": "This is important meeting"
}

Như bạn đã thấy ở trên thì cách tạo data bằng JSON objects thực sự đơn giản. Bạn tạo ra bộ test data nhanh chóng và trực quan.

Tuy nhiên, với cách tạo data như thế này bạn dễ gặp phải tình trạng thiếu nhất quán trong source code. Ví dụ: hai người trong team thực hiện hai test case khác nhau đều liên quan đến appointment lần lượt là test case 1 và test case 2, hãy cùng xem test data họ chuẩn bị cho 2 test case như sau:

JSON objects: mô hình dữ liệu linh động cao dẫn đến nhiều biến thể Chúng ta có thể khai báo JSON object không nghiêm ngặt, không quy chuẩn. Như ví dụ trên, bạn có thể thấy giá trị "key" ở hai file test data này khác nhau mặc dù mục đích trong chương trình là như nhau: Subject–Title, Attendees–Participant, Facilities–Room.

Cả hai JSON object này đều đáp ứng được việc khởi tạo test data cho test case và chương trình vẫn hoạt động bình thường trên cả hai tập giá trị. Tuy nhiên qua ví dụ này bạn có thể thấy sẽ có rất nhiều biến thể cho các giá trị key được sinh ra và dẫn đến những người tham gia vào project sau đó sẽ không biết nên sử dụng tập { "key": "value" } nào cho chính xác. Từ đó sẽ có những đoạn code xử lý riêng cho từng key khác nhau.

JSON objects: test data tái sử dụng không cao { “key”:"value" } lưu trữ dữ liệu tĩnh. Chúng ta sẽ cần liên tục đổi mới giá trị của JSON objects cho mỗi lần chạy nếu hệ thống không cho phép trùng dữ liệu trên sản phẩm test.

Ví dụ: Để sử dụng một cơ sở vật chất (facility) cho đăng ký một cuộc hẹn (appointment), chúng ta sẽ khởi tạo trước dữ liệu về facility trong hệ thống như sau:

Copy

{
  "name": "Soon Dong meeting room",
  "code": "SD-FAC",
  "note": "meeting room for 14 members"
}

Ở lần chạy đầu tiên, facility được tạo ra thành công. Tuy nhiên khi sử dụng JSON objects này để chạy lần thứ hai, hệ thống sẽ báo lỗi vì Garoon không cho phép thêm vào hai facility trùng mã "code": "SD-FAC".

Để giải quyết những điểm trừ này của JSON object, bạn có thể viết thêm source code xử lý cho việc tạo trùng "code" hoặc sử dụng một dạng cấu trúc khác để quy định test data, nghiêm ngặt và ràng buộc hơn đó là Entity data model.

Entity data model (EDM)

Copy

import {APPOINTMENT_TYPE} from "../ConstantItems";

export default class AppointmentBase {
...
    set startDay(value) {
        this._startDay = value;
    }

    get startDay() {
        return this._startDay;
    }

    set startMonth(value) {
        this._startMonth = value;
    }

    get startMonth() {
        return this._startMonth;
    }

    set startYear(value) {
        this._startYear = value;
    }

    get startYear() {
        return this._startYear;
    }
    ...
}

Đây là một ví dụ về EDM. Data được khởi tạo sẽ có các key cố định: startDay, startMonth, startYear… Nhờ vậy mà source code giữ được tính nhất quán. Để hiểu rõ hơn cơ chế tạo data từ EDM, bạn có thể tìm hiểu thêm qua bài viết về Data Generator.

Tuy nhiên EDM cũng có những hạn chế nhất định khi sử dụng: phức tạp hơn JSON objects và tốn kém thời gian ban đầu để triển khai.

Do đó, tùy theo từng trường hợp cụ thể bạn hãy lựa chọn JSON objects hay EDM để sử dụng cho thích hợp nhất.

Ví dụ cụ thể

Trong bài viết về Test spec, phần ví dụ cụ thể có đề cập đến test spec dành cho test case thêm mới một appointment. Test spec đó sử dụng những test data nào? Chúng ta cùng xem file test data dưới đây để biết thêm chi tiết:

acceptance/src/schedule/test-specs/added-new-appoiment/added-new-appointment.data.js

Copy

import DateTimeGenerator from "#e2e-core/src/shared/DateTimeGenerator";
import RegularAppointment from "#e2e-core/schedule/models/RegularAppointment";

const account = { username: "user1", password: "user1" };

const currentDate = new DateTimeGenerator().adjustDateTime({day: 0});
let currentHours = new Date().getHours();
const appointment = new RegularAppointment();

appointment.subject = `Cybozu automation testing workshop ${(new Date()).toString()}`;

appointment.startMonth = currentDate.getMonth();
appointment.startDay = currentDate.getDay();
appointment.startYear = currentDate.getYear();
appointment.startHour = (currentHours + 1).toString(); // e.g: 17
appointment.startMinute = '00'; // to emulate the end-user behavior

appointment.endMonth = currentDate.getMonth();
appointment.endDay = currentDate.getDay();
appointment.endYear = currentDate.getYear();
appointment.endHour = (currentHours + 2).toString();
appointment.endMinute = '00';

appointment.attendees = []; // ["user1","user2"];
appointment.facilities = [];
appointment.attachments = [];
appointment.visibility = 'Public';

appointment.notes = 'Please join the AWS on time';

const testData = { appointment, account };

export { testData as default }

File test data gồm khá nhiều thông tin để khai báo những data cần thiết. Bạn có thể nhận thấy test data được export ra gồm 2 thông tin chính:

const testData = { appointment, account };

account: *user account (*data *1), sử dụng để login vào hệ thống

appointment: *test data của test case (*data *2), cụ thể tại đây là những data dùng để tạo appointment

Hi vọng thông qua ví dụ cụ thể này các bạn đã hình dung rõ nét hơn về test data.

Một vài lưu ý

• JSON object thích hợp cho trường hợp cần khởi tạo data nhanh chóng, không có nhu cầu sử dụng lại. EDM phù hợp cho việc tạo data phức tạp thường xuyên sử dụng lại trong nhiều test case.
• Test data cho mỗi test case nên được làm sạch sau khi test case kết thúc để tránh việc đụng độ dữ liệu cho những lần chạy sau. Việc này sẽ giúp tăng tính ổn định cho chương trình của bạn.Copyafter('Remove test data', () => { new DeletingAppointment( testData.appointment ).deleteAppointmentOnDetailsPage(); });
• Test data dành cho test case chỉ nên tạo ra trước thời điểm test case được chạy, phục vụ cho quá trình chạy test case đó. Không nên tạo sẵn tất cả test data cho các test case.
• Trước khi chạy chương trình test, để đảm bảo tính ổn định testing site nên là một site “sạch”, không có các data rác.

Xu hướng hiện nay trong Test Data & Test Automation (2025–2026)

Trong những năm gần đây, Test Data không còn là một phần phụ trợ đơn thuần trong kiểm thử phần mềm, mà đã trở thành yếu tố chiến lược quyết định độ ổn định và hiệu quả của test automation — đặc biệt khi các hệ thống phức tạp hơn, microservices và DevOps/CI-CD trở thành tiêu chuẩn.

1. Tự tạo và quản lý Test Data ngay trong kịch bản test

Ở những dự án lớn, việc hardcode dữ liệu cố định trong các test case thường gây ra lỗi không ổn định khi môi trường test bị thay đổi bởi các team khác. Do đó, các nhóm QA hiện nay đang theo xu hướng:

• Tạo dữ liệu ngay trong runtime thông qua API hoặc workflow setup của chính ứng dụng trước khi test chạy.
• Tag hoặc namespace test data để dễ theo dõi và làm sạch sau khi test hoàn tất.
• Tear-down tự động test data sau mỗi lần chạy để tránh rác dữ liệu và giữ môi trường predictable cho các lần chạy sau.
  Các kỹ thuật này đều nhằm mục đích tối ưu việc kiểm soát dữ liệu–input và tránh các lỗi do dữ liệu cũ gây ra trong pipeline CI/CD.

Mindset mới:

“Tổ chức test nên tự kiểm soát dữ liệu của mình, thay vì phụ thuộc vào dữ liệu tồn tại trong môi trường chia sẻ.”

2. Test Data trở thành một phần của pipeline CI/CD

Trong môi trường DevOps – CI/CD, test automation thường được tích hợp trực tiếp vào pipeline triển khai. Điều này đòi hỏi:

• Test Data phải được khởi tạo & dọn dẹp tự động như một bước riêng trong workflow (setup & teardown).
• Test script không được phụ thuộc vào dữ liệu có sẵn trong môi trường test – điều này làm flaky test (test thất bại ngẫu nhiên) xuất hiện thường xuyên.
• Một số tổ chức sử dụng framework helper hoặc script DB để seed dữ liệu trước khi test chạy và rollback sau khi test xong.

Yếu tố này giúp cho test automation trở nên nhất quán và đáng tin cậy hơn khi chạy liên tục trong pipeline tự độ

3. Sinh dữ liệu động và tránh xung đột trong môi trường chia sẻ

Một vấn đề phổ biến khi nhiều team cùng sử dụng một môi trường test là xung đột dữ liệu — khiến test thất bại không vì bug nhưng vì dữ liệu bị thay đổi bởi test khác hoặc deploy mới.

Xu hướng xử lý hiện nay bao gồm:

• Sinh dữ liệu động với UUID/Timestamp để giảm trùng lặp và xung đột giữa các test.
• Phân vùng dữ liệu theo namespace/test flag để dễ dọn dẹp và tách biệt dữ liệu của từng test.
• Một số team thậm chí tạo môi trường “owned” test riêng để automation không bị ảnh hưởng dữ liệu bởi nhóm khác.
  Những chiến lược này giúp test chạy ổn định hơn và giảm chi phí duy trì môi trường test chung.

4. Test Data thống nhất theo lifecycle test

Theo thực hành phổ biến trong cộng đồng QA automation, mỗi test nên tuân theo quy trình tạo–kiểm tra–dọn dẹp dữ liệu rõ ràng:

• Setup – tạo dữ liệu cần thiết cho test case (qua API/DB/fixtures).
• Exercise – chạy các bước kiểm thử.
• Assertion – kiểm tra kết quả mong đợi.
• Teardown – dọn dẹp dữ liệu đã tạo.

Việc coi lifecycle dữ liệu là một phần của chính test giúp test dễ tái lặp, giảm rủi ro “dữ liệu bị rác” và giúp báo cáo lỗi chính xác hơn khi test thất bại.

5. Test Data cho loại test mới & data-heavy systems

Với sự gia tăng của:

• Microservices
• Hệ thống event-driven
• Database phức tạp (NoSQL/Polyglot)

Test data không chỉ dùng để kiểm thử chức năng đơn lẻ nữa mà cần thiết kế để:

• Thử nghiệm cả data consistency giữa nhiều service
• Đánh giá performance và stress với dữ liệu lớn
• Kiểm tra tính nhất quán sau khi chạy workflow dài

Điều này dẫn tới việc test data management được coi là kỹ năng riêng trong nhiều team QA chuyên sâu.

Lời kết

Tính ổn định của chương trình test bị ảnh hưởng bởi nhiều yếu tố, trong đó có test data. Khi bạn làm việc đủ lâu với automation, bạn sẽ gặp phải một số test case lâu lâu mới fail một lần hay chỉ fail khi chạy chế độ song song. Một trong những yếu tố gây ra vấn đề này có thể là test data, hay cân nhắc xem liệu có sự đụng độ data nào xảy ra không khi gặp phải những tình huống này nhé.

Nói đến đây, các bạn có thể thấy được test data có vai trò như thế nào trong chương trình test rồi đó. Hãy luôn nhớ dọn dẹp data, một công việc đơn giản nhưng lại giúp chương trình test ổn định hơn rất nhiều.

INDA Academy tự hào là đơn vị tiên phong trong việc đào tạo phân tích dữ liệu và AI chuyên sâu, đặc biệt cho khối ngành Ngân hàng – Tài chính – Bảo hiểm tại Việt Nam. Sau hơn 12 năm “thực chiến” cùng những dòng chảy dữ liệu khổng lồ, chúng tôi đã xây dựng nên một hệ sinh thái đào tạo toàn diện, giúp hàng nghìn học viên chuyển mình từ người mới bắt đầu trở thành những chuyên gia lành nghề, sẵn sàng đáp ứng tiêu chuẩn khắt khe của các doanh nghiệp lớn.

Điểm khác biệt lớn nhất tại INDA chính là triết lý đào tạo dựa trên các dự án thực tế (Project-based) và lộ trình cá nhân hóa nhờ ứng dụng AI. Chúng tôi không chỉ dạy bạn cách sử dụng công cụ, mà còn truyền tải tư duy khai phá giá trị từ dữ liệu để đưa ra quyết định kinh doanh chính xác.

Tìm hiểu thêm về các khóa học TẠI ĐÂY:
Lộ trình đào tạo Data Engineer
Lộ trình đào tạo Data Analyst
Lộ trình đào tạo Tester
Khóa học Data Engineer nâng cao – Thực chiến 5 dự án doanh nghiệp
Khóa học Data Analyst nâng cao – Thực chiến 5 dự án doanh nghiệp

Tham khảo thêm về Test Data:

Test Data là gì? Hướng dẫn thiết kế Test Data

Test Data cần biết những gì?