End to end testing là gì năm 2024

Một học viên lớp DevOps nhắn tin cho tôi "Anh Cường, em không hiểu tại sao trong khoá học DevOps, mà bọn em phải lập trình kiểm thử là sao nhỉ. Em muốn được học về Kubernetes, AWS nhiều hơn". Rõ ràng là một câu hỏi rất thực dụng và đúng chất của một lập trình viên: rất thích công nghệ mới hot trend, và tránh công việc kiểm thử càng nhiều càng tốt.

Tuy nhiên kiểm thử tự động là một bước quan trọng trong cả quy trình CI/CD. Thử hình dùng mọi bước trong quy trình CI/CD đều được tự động, chạy rất nhanh, nhưng khi đến bước kiểm thử, phải mất vài ngày để kiểm tra chất lượng sản phẩm, toàn bộ quy trình sẽ bị ách tắc tại đây. Do đó để CI/CD vận hành đúng, cần có nhiều kịch bản kiểm thử tự động ở nhiều thành phần của sản phẩm để cải tiến chất lượng.

End to End Testing khác gì với Unit Testing

Ngày hôm nay, vận hành của một web site phức tạp hơn rất nhiều trước đây. Giao diện web sẽ kết nối tới một dịch vụ REST. Dịch vụ này có thể gọi tiếp đến nhiều dịch vụ REST hoặc gRPC phía sau. Nếu chỉ kiểm thử từng dịch vụ REST thì chưa đủ, và không đảm bảo giao diện hoạt động theo đúng ý người dùng. Do đó End to End Testing sẽ rất hữu ích đảm bảo trải nghiệm sử dụng được chức năng ứng dụng thay vì quá mất nhiều thời gian để viết unit test từng dịch vụ REST API. Tối ưu nhất là chúng ta viết đầy đủ Unit Test và End to End Test. Nhưng nếu do nguồn lực có hạn, thì nên ưu tiên viết End to End Test trước.

Là người triển khai hệ thống automation test chắc hẳn sẽ có lúc bạn thắc mắc rằng, liệu khi bạn thực thi một file test spec (test script) thì hệ thống sẽ tiến hành những trình tự như thế nào? Cũng như điểm bắt đầu và điểm kết thúc của quá trình kiểm thử là gì? Bài viết này sẽ giúp bạn hiểu chi tiết hơn về sự tương tác giữa các thành phần trong hệ thống, để từ đó các developer có thể dễ dàng trong việc tối ưu, cải thiện (debug, refactor...) và giúp hệ thống của mình để hoạt động tốt hơn.

Trong bài này sử dụng Address module | Cybozu Garoon (username: brown / password: brown) để làm ví dụ minh họa. Cybozu Garoon là một sản phẩm làm việc cộng tác. Nó là 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

Tổng quan về các thành phần

Trước tiên, để hiểu được quy trình hoạt động của hệ thống automation test, bạn cần hiểu được những thành phần nào sẽ liên quan từ lúc bắt đầu đến lúc kết thúc việc thực thi một test spec. Hãy đọc một test spec ví dụ dưới đây để hiểu rõ hơn

Ví dụ 01: adding-address-book.spec.js test spec với đầy đủ các thành phần trong automation test

import {AddingAddressBookFlow, AddingAddressEntryFlow, DeletingAddressBookFlow} from '
# e2e-core/address/test-flows';
import {AuthenticatingFlow} from '
# e2e-core/other/test-flows';
import {BookViewPage, BookListPage}  from '
# e2e-core/address/pages';
 // Test data
import testData from './address-book-shared.data';
describe('Shared Address Book', () => {
    it('should add Shared Address Book successfully', () => {
        // Test flow
        new AuthenticatingFlow(testData.adminCredential)
            .login()
            .verifyLoggedInSuccessfully();
        // Test flow
        new AddingAddressBookFlow(testData.sharedAddressBookInfo)
            .addBook()
            .verifyBookDetails();
    });
    it('should add Shared Address Entry successfully', () => {
        // Test flow
        new AuthenticatingFlow(testData.userCredential)
            .login()
            .verifyLoggedInSuccessfully();
        // Test flow
        new AddingAddressEntryFlow(testData.sharedAddressEntryInfo)
            .addAddressEntry()
            .verifyAddressEntryDetails();
    });
    after('should delete Address Book successfully', () => {
        // Test flow
        new AuthenticatingFlow(testData.adminCredential)
            .login()
            .verifyLoggedInSuccessfully();
        // Page object
        BookListPage
            .openPage()
            .clickOnBookLink(testData.sharedAddressBookInfo.bookName);
        // Page object
        BookViewPage
            .clickOnDeleteBookLink()
            .clickOnYesButton();
    });
});

Để thực thi được ví dụ trên, chúng ta cần 4 thành phần chính:

1. Page Object

   POM là mô hình giúp triển khai test code của test tự động với cách để chuyển thể phần tử (Web Elements) từ màn hình tính năng test sang test code, với cách tiếp cận lập trình OOP Ví dụ: clickOnAddButton() {//...}, inputNotesField(folderNotes) {//...},... Mô tả chuyên sâu về page object hãy truy cập ở đây

2. Test flow Là một kỹ thuật triển khai test code ở Cybozu mà trong đó test flow class bao gồm các test flow methods cho test spec sử dụng nó mà không quan tâm test flow methods được triển khai như thế nào. Kỹ thuật này giúp cho việc triển khai test spec được nhẹ nhàng hiệu quả. Mô tả chuyên sâu về test flow hãy truy cập ở đây
3. Test data Trong lĩnh vực kiểm thử phần mềm,

2 là những những liệu đã xác định cụ thể tham gia vào quá trình kiểm thử phần mềm. Nó nhằm xác định chương trình máy tính có phản hồi đúng với những gì mong đợi tương ứng với

2 cung cấp. Tùy vào góc nhìn, chúng ta có thể phân loại test data thành nhiều loại khác nhau. Ví dụ:

4 dùng cho positive/negative testing; hay input test data và expected test data... Mô tả chuyên sâu về test data hãy truy cập ở đây

4. Test spec Test spec: là nơi triển khai test code của các bước trong kịch bản test của một hay nhiều test case bằng một ngôn lập trình cụ thể - hay còn còn tên gọi khác là test script Đây cũng là thành phần đầu tiên giao tiếp với test runner, giúp developer hiểu được mục đích của test case, các bước mà test case thực hiện. Test spec: là nơi mô tả các kịch bản test, tùy vào test framework đang sử dụng mà test spec có một syntax riêng. Mô tả chuyên sâu về test spec hãy truy cập ở đây

Khi chúng ta dùng test runner thực thi một test spec (hay test script) thì chương trình sẽ xử lý theo flow bên dưới:

Mô tả

(1) Run command để thực thi test spec

Với webdriverio framework thì có thể run lệnh:

import testData from './address-book-shared.data';

5

(tham khảo: https://webdriver.io/docs/gettingstarted)

(2) Xử lý data

Bước này sẽ tương ứng với phần code sau trên ví dụ 01:

import testData from './address-book-shared.data';

(3) Test data

Data được khai báo, khởi tạo sẽ được lưu trữ vào bộ nhớ của máy tính và sẽ được sử dụng ở các quy trình tiếp theo như truyền vào test-flow, page object, hoặc kiểm chứng kết quả.

(4) Call test-flow

Thực thi một hoặc nhiều test flow của test spec.

(5) Call input test data

Đây là quá trình gọi test data từ bộ nhớ của hệ thống và truyền vào các tham số của test-flow hoặc page object.

(6) Call PageObjects

Thực thi một hoặc nhiều page object của test spec, page object có thể được gọi trực tiếp từ test spec hoặc từ test flow, tùy vào cách thiết kế chương trình của bạn.

(7) Thực thi các bước của test case trên UI

Ở bước này chương trình sẽ tương tác với web element để thực thi các tính năng của ứng dụng, đối với những bước cần nhập data và UI thì sẽ dùng input data ở bước 5. Ví dụ một số phương thức: input username, input password, click Login.

(8) Lấy giá trị trên UI sau khi ứng dụng thực thi

Để đảm bảo các tính năng của ứng dụng hoạt động đúng sau khi thực thi ở bước 7, chúng ta cần phải lấy được dữ liệu hiển thị thật sự lưu vào bộ nhớ và sử dụng cho việc so sánh ở bước 9.

Ví dụ: sau khi login vào hệ thống ở bước 7, thì bước này sẽ lấy tên hiển thị sau khi đăng nhập và lưu vào bộ nhớ.

(9) So sánh data

Bước này sẽ so sánh giá trị sau khi ứng dụng thực thi và giá trị người developer mong muốn. Nếu hai giá trị này giống nhau thì test case sẽ cho kết quả passed và ngược lại.

(10) Báo cáo kết quả test

Sau khi có kết quả passed/failed của tất cả các test cases trong test spec, hệ thống sẽ in ra danh sách báo cái kết quả của từng case, với thông tin và format tùy thuộc vào công cụ reporter mà hệ thống đang sử dụng, có thể là JUnit, Allure, Mocha...

Một số lưu ý

Trên đây là trình tự hoạt động từ lúc bắt đầu cho đến lúc kết thúc của một test spec. Bạn có thể cài đặt một môi trường để thực thi một test spec đơn giản và kiểm chứng lại những trình tự ở trên để hiểu một cách sâu sắc hơn.

E2E là gì trong kinh doanh?

E2E (End-to-end) là, “… một thuật ngữ được sử dụng để mô tả các sản phẩm hoặc giải pháp bao gồm mọi giai đoạn trong một quy trình cụ thể, thường không cần bất kỳ thứ gì được cung cấp bởi bên thứ ba.

Hệ thống end to end là gì?

End To End được hiểu là quá trình cung ứng sản phẩm từ đầu đến cuối. Nó mở ra một tầm nhìn bao quát, toàn diện trong việc quản lý nhà cung cấp, sản xuất và phân phối. Cụ thể, End To End là quá trình từ thiết kế sản phẩm, thu mua nguyên vật liệu, lên kế hoạch và sản xuất.

Kết nối end to end là gì?

End To End là thuật ngữ tiếng Anh dùng để chỉ một quy trình đầu cuối của các hệ thống hay phương pháp, dịch vụ nào đó. Chúng hầu như khép kín từ điểm đầu cho đến điểm kết thúc, loại bỏ càng nhiều giai đoạn trung gian càng tốt.

Quy trình đầu cuối là gì?

Qui trình đầu cuối (tiếng Anh: End-to-end) mô tả qui trình mà một hệ thống hoặc dịch vụ hoạt động từ đầu đến cuối và cung cấp một giải pháp chức năng hoàn chỉnh, thường là không cần sự trợ giúp từ bên thứ ba.