Luận văn: Xây dựng ứng dụng kiểm thử phần mềm tự động sử dụng Selenium và WebDriver

Luận án thạc sĩ CNTT trình bày quy trình xây dựng ứng dụng kiểm thử phần mềm tự động hiệu quả. Nghiên cứu ứng dụng Selenium và WebDriver để tối ưu hóa quy

• Tác giả: Phạm Thị Hải Yến
• Người hướng dẫn: PGS.TS. Hoàng Xuân Huấn
• Trường học: Trường Đại học Công nghệ
• Chuyên ngành: Khoa học máy tính
• Đề tài: Xây dựng ứng dụng kiểm thử phần mềm tự động sử dụng Selenium và WebDriver
• Loại tài liệu: Luận văn thạc sĩ
• Năm xuất bản: 2020
• Địa điểm: Hà Nội

Tóm tắt

I. Tại sao cần xây dựng ứng dụng kiểm thử phần mềm tự động với Selenium

Trong bối cảnh phát triển phần mềm ngày càng nhanh chóng và phức tạp, việc đảm bảo chất lượng sản phẩm là yếu tố then chốt quyết định sự thành công. Kiểm thử phần mềm đóng vai trò không thể thiếu, giúp phát hiện lỗi sớm và duy trì sự ổn định của hệ thống. Tuy nhiên, các phương pháp kiểm thử thủ công truyền thống đang bộc lộ nhiều hạn chế, đặc biệt khi quy mô dự án và tần suất cập nhật tăng lên. Nhu cầu kiểm thử tự động trở nên cấp thiết hơn bao giờ hết.

Việc xây dựng ứng dụng kiểm thử phần mềm tự động với Selenium không chỉ giải quyết các vấn đề về thời gian và chi phí mà còn nâng cao độ chính xác và độ bao phủ của các trường hợp kiểm thử. Selenium là một bộ công cụ mạnh mẽ, được sử dụng rộng rãi để tự động hóa các trình duyệt web, cho phép các nhà phát triển và kiểm thử viên mô phỏng hành vi người dùng một cách hiệu quả. Khả năng tương thích với nhiều ngôn ngữ lập trình và trình duyệt khác nhau làm cho Selenium trở thành lựa chọn hàng đầu cho các dự án phát triển phần mềm hiện đại.

Ứng dụng kiểm thử tự động không chỉ giúp tăng tốc chu trình phát triển mà còn giải phóng nguồn lực cho các công việc kiểm thử phức tạp hơn, đòi hỏi sự can thiệp của con người. Nó cung cấp phản hồi nhanh chóng về chất lượng phần mềm sau mỗi lần thay đổi mã nguồn, từ đó giảm thiểu rủi ro khi triển khai. Các tổ chức ngày càng nhận ra giá trị chiến lược của việc đầu tư vào các giải pháp kiểm thử tự động với Selenium để duy trì lợi thế cạnh tranh và cung cấp sản phẩm chất lượng cao đến người dùng cuối.

1.1. Thực trạng và thách thức của kiểm thử thủ công

Kiểm thử thủ công từng là phương pháp phổ biến, nhưng ngày nay nó đối mặt với nhiều hạn chế nghiêm trọng. Thời gian thực hiện kiểm thử thủ công thường kéo dài, đặc biệt với các ứng dụng có nhiều tính năng và thường xuyên được cập nhật. Sự phụ thuộc vào yếu tố con người dẫn đến khả năng xảy ra lỗi cao, thiếu nhất quán và khó tái hiện. Chi phí cho nguồn lực kiểm thử viên cũng là một gánh nặng, đặc biệt khi cần thực hiện các bài kiểm thử hồi quy (regression testing) lặp đi lặp lại. Hơn nữa, việc kiểm thử thủ công khó đạt được độ bao phủ cao, bỏ sót nhiều trường hợp kiểm thử phức tạp, dẫn đến rủi ro phần mềm có lỗi khi đến tay người dùng. Đây là những thách thức lớn mà các đội ngũ phát triển phần mềm phải đối mặt.

1.2. Lợi ích vượt trội của kiểm thử tự động

Kiểm thử tự động mang lại nhiều lợi ích đáng kể, khắc phục các nhược điểm của kiểm thử thủ công. Đầu tiên, nó giúp tăng tốc độ kiểm thử, cho phép thực thi hàng ngàn kịch bản trong thời gian ngắn. Thứ hai, độ chính xác cao hơn, loại bỏ lỗi do yếu tố con người, đảm bảo các kịch bản được thực thi nhất quán. Thứ ba, tiết kiệm chi phí lâu dài do giảm bớt nguồn lực cần thiết cho các tác vụ lặp lại. Cuối cùng, kiểm thử tự động hỗ trợ kiểm thử hồi quy hiệu quả, đảm bảo các thay đổi mới không phá vỡ chức năng hiện có, từ đó nâng cao chất lượng tổng thể của phần mềm.

II. Selenium WebDriver là gì và cách triển khai hiệu quả trong kiểm thử tự động

Để xây dựng ứng dụng kiểm thử phần mềm tự động với Selenium một cách hiệu quả, việc nắm vững Selenium WebDriver là điều kiện tiên quyết. Selenium WebDriver là thành phần cốt lõi của bộ công cụ Selenium, cung cấp một giao diện lập trình mạnh mẽ để tương tác trực tiếp với các trình duyệt web. Nó cho phép người kiểm thử viết các đoạn mã để thực hiện các thao tác như click chuột, nhập văn bản, chọn phần tử, điều hướng trang và nhiều hành động khác, giống như một người dùng thực sự đang tương tác với ứng dụng web. Điều này tạo ra một nền tảng vững chắc cho việc tự động hóa các kịch bản kiểm thử phức tạp.

Sự linh hoạt của Selenium WebDriver thể hiện ở khả năng hỗ trợ đa ngôn ngữ lập trình như Java, Python, C#, Ruby, JavaScript và đa trình duyệt như Chrome, Firefox, Edge, Safari. Điều này giúp các đội ngũ phát triển phần mềm lựa chọn công nghệ phù hợp với stack hiện có của họ. Khi triển khai, Selenium WebDriver khởi tạo một phiên làm việc với trình duyệt thông qua một driver cụ thể (ví dụ: ChromeDriver, GeckoDriver). Driver này đóng vai trò trung gian, nhận lệnh từ mã kiểm thử và truyền đạt chúng đến trình duyệt, sau đó nhận kết quả và trả về cho mã kiểm thử. Quy trình này đảm bảo việc tương tác diễn ra liền mạch và đáng tin cậy.

Việc sử dụng Selenium WebDriver đòi hỏi sự hiểu biết về cách định vị các phần tử trên trang web (Locators). Các phương pháp định vị phổ biến bao gồm sử dụng ID, Name, ClassName, TagName, LinkText, CSS Selector và XPath. Mỗi phương pháp có ưu nhược điểm riêng và được lựa chọn tùy thuộc vào cấu trúc của trang web. Thành công trong việc xây dựng ứng dụng kiểm thử tự động với Selenium phụ thuộc rất nhiều vào khả năng lựa chọn và sử dụng Locator hiệu quả, giúp mã kiểm thử ổn định và ít bị ảnh hưởng bởi thay đổi giao diện người dùng.

2.1. Giới thiệu về Selenium WebDriver và vai trò chính

Selenium WebDriver là một API và công cụ chính trong bộ Selenium, cho phép tương tác trực tiếp với các trình duyệt web. Nó mô phỏng hành vi của người dùng trên giao diện người dùng (UI), thực hiện các thao tác như mở trang, điền form, nhấp chuột, v.v. Vai trò chính của nó là tự động hóa các tác vụ kiểm thử lặp đi lặp lại, đảm bảo tính nhất quán và hiệu quả của các kịch bản kiểm thử phần mềm. Theo luận văn, Selenium WebDriver là thư viện quan trọng, hỗ trợ nhiều hàm xử lý chung và tương thích với nhiều trình duyệt khác nhau.

2.2. Các hàm xử lý và thành phần UI cơ bản của Selenium

Selenium WebDriver cung cấp một loạt các hàm xử lý để tương tác với các phần tử web. Ví dụ, findElement() để tìm kiếm một phần tử, click() để nhấp chuột, sendKeys() để nhập liệu, getText() để lấy nội dung văn bản. Để tìm kiếm phần tử, Selenium sử dụng các đối tượng UI (Locators) như ID, Name, LinkText, TagName, ClassName, CSS Selector và XPath (Phạm Thị Hải Yến, 2020). Việc thành thạo các hàm này và lựa chọn Locator phù hợp là yếu tố then chốt để xây dựng ứng dụng kiểm thử tự động với Selenium ổn định và đáng tin cậy.

2.3. Cài đặt và cấu hình môi trường kiểm thử tự động Selenium

Để bắt đầu xây dựng ứng dụng kiểm thử tự động với Selenium, cần cài đặt môi trường phù hợp. Điều này bao gồm việc cài đặt Java Development Kit (JDK), một IDE như IntelliJ IDEA hoặc Eclipse, và thêm các thư viện Selenium WebDriver vào dự án (thường thông qua Maven hoặc Gradle). Cuối cùng, cần tải xuống các trình duyệt driver tương ứng với trình duyệt sẽ được kiểm thử (ví dụ: ChromeDriver, GeckoDriver) và cấu hình đường dẫn đến chúng trong mã nguồn hoặc biến môi trường. Các bước này đảm bảo kiểm thử tự động Selenium có thể chạy trơn tru.

III. Mẫu thiết kế Page Object Model POM Giải pháp tối ưu hóa kiểm thử Selenium

Khi xây dựng ứng dụng kiểm thử phần mềm tự động với Selenium, đặc biệt với các dự án lớn và phức tạp, việc quản lý mã nguồn kiểm thử trở thành một thách thức đáng kể. Các kịch bản kiểm thử có thể trở nên khó đọc, khó bảo trì và dễ vỡ khi giao diện người dùng thay đổi. Mẫu thiết kế Page Object Model (POM) xuất hiện như một giải pháp kiến trúc tối ưu, giúp giải quyết triệt để những vấn đề này. POM đề xuất một cách tiếp cận có cấu trúc, nơi mỗi trang web hoặc một phần quan trọng của giao diện người dùng được đại diện bởi một "đối tượng trang" (Page Object) riêng biệt trong mã kiểm thử.

Trong Page Object Model, mỗi Page Object đóng gói các phần tử web (Locators) và các hành động (methods) có thể thực hiện trên trang đó. Ví dụ, đối với một trang đăng nhập, Page Object sẽ chứa các định danh cho trường nhập tên người dùng, mật khẩu và nút đăng nhập, cùng với các phương thức như enterUsername(), enterPassword(), clickLoginButton(). Sự tách biệt rõ ràng này giữa logic kiểm thử và thông tin về các phần tử UI mang lại nhiều lợi ích. Nếu có bất kỳ thay đổi nào trong cấu trúc HTML của trang, chỉ cần cập nhật định danh Locator trong Page Object tương ứng mà không cần phải thay đổi toàn bộ các kịch bản kiểm thử sử dụng trang đó.

Việc áp dụng Page Object Model không chỉ giúp tăng cường khả năng bảo trì của các kịch bản kiểm thử tự động với Selenium mà còn cải thiện khả năng đọc và tái sử dụng mã. Các kịch bản kiểm thử trở nên dễ hiểu hơn vì chúng tương tác với các phương thức của Page Object thay vì trực tiếp thao tác với các phần tử UI. Điều này cũng thúc đẩy sự hợp tác tốt hơn trong đội ngũ phát triển phần mềm, vì các thành viên có thể làm việc trên các Page Object khác nhau mà không gây xung đột. Theo luận văn, POM là một "mẫu thiết kế" quan trọng giúp tổ chức mã nguồn kiểm thử một cách khoa học, hiệu quả và dễ quản lý, đặc biệt hữu ích khi xây dựng ứng dụng kiểm thử phần mềm tự động với Selenium trên quy mô lớn.

3.1. Hiểu rõ Page Object Model trong kiểm thử tự động

Page Object Model (POM) là một mẫu thiết kế trong kiểm thử tự động, trong đó mỗi trang web hoặc một phần của trang được đại diện bởi một class Java riêng biệt. Class này chứa các yếu tố UI (Locators) và các phương thức tương tác với các yếu tố đó. Mục tiêu của POM là tạo ra một lớp trừu tượng giữa mã kiểm thử và giao diện người dùng. Việc này giúp mã kiểm thử trở nên sạch hơn, dễ đọc và dễ bảo trì hơn, đặc biệt khi xây dựng ứng dụng kiểm thử phần mềm tự động với Selenium cho các hệ thống phức tạp.

3.2. Cách tổ chức mã nguồn với POM để tăng khả năng bảo trì

Để tổ chức mã nguồn hiệu quả với POM, cần tạo các gói (packages) riêng biệt cho các Page Object, ví dụ: com.yourcompany.pages. Mỗi Page Object class sẽ chứa các biến @FindBy cho các Locators và các phương thức public đại diện cho các hành động trên trang. Các kịch bản kiểm thử sau đó sẽ gọi các phương thức này thay vì thao tác trực tiếp với Locators. Điều này giúp giảm thiểu sự trùng lặp mã, tăng tính tái sử dụng và đơn giản hóa việc cập nhật khi có thay đổi UI, tối ưu hóa quá trình kiểm thử tự động với Selenium.

IV. Nâng cao hiệu quả kiểm thử phần mềm với Cucumber và Gherkin

Ngoài việc sử dụng Selenium WebDriver và Page Object Model, việc kết hợp Cucumber và Gherkin là một chiến lược hiệu quả để nâng cao đáng kể chất lượng và khả năng hợp tác trong kiểm thử phần mềm, đặc biệt khi xây dựng ứng dụng kiểm thử phần mềm tự động với Selenium. Cucumber là một công cụ hỗ trợ Behavior Driven Development (BDD), cho phép mô tả các kịch bản kiểm thử bằng ngôn ngữ tự nhiên, dễ hiểu cho cả các bên liên quan không có chuyên môn kỹ thuật. Điều này thúc đẩy sự giao tiếp rõ ràng và đảm bảo mọi người đều có chung một cái nhìn về các yêu cầu của sản phẩm.

Gherkin là ngôn ngữ được Cucumber sử dụng để viết các kịch bản kiểm thử. Các tệp Gherkin (được gọi là "feature files") sử dụng một cấu trúc đơn giản với các từ khóa như Feature, Scenario, Given, When, Then (hay còn gọi là Given-When-Then syntax). Ví dụ, một kịch bản có thể được viết như sau: "Given người dùng đã truy cập trang đăng nhập, When người dùng nhập tên đăng nhập và mật khẩu hợp lệ, Then hệ thống hiển thị trang chủ." Cú pháp này không chỉ dễ đọc mà còn cung cấp một tài liệu sống cho các chức năng của ứng dụng. Theo luận văn, Gherkin là ngôn ngữ mà Cucumber đọc và chuyển thành kịch bản kiểm thử, giúp người đọc hiểu kịch bản và hành động mà không cần biết chi tiết chúng được cài đặt như thế nào.

Khi tích hợp Cucumber với Selenium, các bước được mô tả trong Gherkin sẽ được ánh xạ tới các đoạn mã Java (hoặc các ngôn ngữ khác) sử dụng Selenium WebDriver để thực thi các hành động trên trình duyệt. Điều này tạo ra một cầu nối giữa các yêu cầu nghiệp vụ và mã kiểm thử thực tế. Lợi ích chính là khả năng tạo ra các kịch bản kiểm thử mà bất kỳ ai cũng có thể hiểu, từ khách hàng, quản lý dự án cho đến kiểm thử viên và nhà phát triển. Điều này cải thiện đáng kể sự minh bạch, giảm thiểu hiểu lầm và đảm bảo rằng các kịch bản kiểm thử tự động phản ánh đúng các yêu cầu của người dùng cuối, làm cho quá trình xây dựng ứng dụng kiểm thử phần mềm tự động với Selenium trở nên toàn diện hơn.

4.1. Giới thiệu Cucumber và ngôn ngữ Gherkin

Cucumber là một framework hỗ trợ Behavior Driven Development (BDD), giúp kết nối các kịch bản kiểm thử bằng ngôn ngữ tự nhiên với mã nguồn thực thi. Nó cho phép các nhóm dự án viết các đặc tả hành vi của ứng dụng dưới dạng các câu chuyện người dùng. Gherkin là ngôn ngữ được Cucumber sử dụng, với cú pháp đơn giản, dễ đọc gồm các từ khóa như Feature, Scenario, Given, When, Then. Mục đích chính của Gherkin là giúp các bên không chuyên về kỹ thuật cũng có thể hiểu được các kịch bản kiểm thử (Phạm Thị Hải Yến, 2020), từ đó cải thiện giao tiếp và sự đồng thuận về yêu cầu.

4.2. Quy trình áp dụng BDD với Cucumber

Quy trình áp dụng BDD với Cucumber bắt đầu bằng việc viết các tệp .feature bằng ngôn ngữ Gherkin, mô tả các kịch bản kiểm thử theo hướng hành vi. Mỗi bước trong kịch bản Gherkin sau đó được ánh xạ tới một phương thức trong "step definition" class. Các phương thức này sử dụng Selenium WebDriver để thực hiện các hành động trên trình duyệt và kiểm tra kết quả. Chu trình này giúp đảm bảo rằng mã nguồn được phát triển đúng theo các yêu cầu nghiệp vụ và các kịch bản kiểm thử tự động luôn được cập nhật, đồng bộ với sự thay đổi của ứng dụng.

V. Xây dựng framework kiểm thử tự động toàn diện và tích hợp liên tục CI

Để thực sự tối ưu hóa quá trình kiểm thử phần mềm, việc xây dựng ứng dụng kiểm thử phần mềm tự động với Selenium cần vượt ra ngoài việc chỉ viết các kịch bản đơn lẻ. Một framework kiểm thử tự động toàn diện là yếu tố then chốt, cung cấp cấu trúc, các công cụ hỗ trợ và quy trình để quản lý, thực thi và báo cáo kết quả kiểm thử một cách hiệu quả. Framework này thường bao gồm các thành phần như kiến trúc Page Object Model, các thư viện tiện ích, cơ chế báo cáo, và khả năng cấu hình để chạy trên nhiều môi trường hoặc trình duyệt khác nhau. Việc xây dựng một framework vững chắc giúp giảm thiểu công sức duy trì, tăng tính tái sử dụng của mã nguồn và cho phép mở rộng dễ dàng khi ứng dụng phát triển.

Sau khi framework được xây dựng thành công, việc vận hành nó trong một quy trình tích hợp liên tục (CI) là bước tiếp theo để đạt được hiệu quả tối đa. Tích hợp liên tục (CI) là một thực hành trong phát triển phần mềm mà theo đó, các thành viên trong nhóm thường xuyên tích hợp công việc của họ. Mỗi lần tích hợp sẽ được kiểm tra bằng một build tự động, bao gồm cả kiểm thử tự động, để phát hiện lỗi càng sớm càng tốt (Martin Fowler, 2020). Các công cụ CI/CD phổ biến như Jenkins, GitLab CI/CD, CircleCI, hoặc GitHub Actions có thể được sử dụng để tự động kích hoạt các bộ kiểm thử Selenium sau mỗi lần thay đổi mã nguồn được đẩy lên kho chứa.

Lợi ích của tích hợp liên tục trong bối cảnh xây dựng ứng dụng kiểm thử phần mềm tự động với Selenium là vô cùng lớn. Nó cung cấp phản hồi nhanh chóng về chất lượng mã nguồn, giúp các nhà phát triển phát hiện và sửa lỗi ngay lập tức, trước khi chúng tích tụ và trở nên phức tạp hơn. Điều này không chỉ giảm thiểu rủi ro mà còn tăng tốc độ phân phối sản phẩm ra thị trường, đồng thời đảm bảo rằng mỗi phiên bản mới đều đạt được tiêu chuẩn chất lượng cao. Việc kết hợp một framework kiểm thử tự động Selenium mạnh mẽ với một quy trình CI tự động là chìa khóa để đạt được sự nhanh nhẹn và độ tin cậy trong chu trình phát triển phần mềm hiện đại.

5.1. Các bước phát triển framework kiểm thử thực tế

Để xây dựng framework kiểm thử tự động, cần tuân thủ một số bước cơ bản. Đầu tiên, lựa chọn ngôn ngữ và công cụ (Java + Maven/Gradle + Selenium + Cucumber). Thứ hai, thiết kế kiến trúc theo Page Object Model để quản lý các phần tử và hành động trên trang. Thứ ba, tạo các thư viện tiện ích chung (helper methods) để xử lý các tác vụ lặp lại. Thứ tư, tích hợp báo cáo kiểm thử (ví dụ: ExtentReports, Allure). Cuối cùng, cấu hình khả năng chạy kiểm thử trên nhiều trình duyệt và môi trường. Việc này giúp ứng dụng kiểm thử tự động hoạt động hiệu quả.

5.2. Tích hợp liên tục CI để tối ưu quy trình kiểm thử tự động

Tích hợp liên tục (CI) là một phương pháp quan trọng để tối ưu hóa quy trình kiểm thử tự động. CI giúp tự động hóa việc build, kiểm thử và triển khai mỗi khi có thay đổi mã nguồn. Bằng cách tích hợp các bài kiểm thử Selenium vào hệ thống CI (như Jenkins), các lỗi tích hợp hoặc lỗi chức năng có thể được phát hiện ngay lập tức sau mỗi commit. Theo Martin Fowler, CI giúp "giảm thiểu đáng kể các vấn đề khi tích hợp và cho phép một đội phát triển có thể viết phần mềm nhanh hơn" (Phạm Thị Hải Yến, 2020). Điều này đảm bảo chất lượng phần mềm liên tục và cải thiện tốc độ phát triển phần mềm.

VI. Kết luận Tương lai của kiểm thử phần mềm tự động với Selenium

Việc xây dựng ứng dụng kiểm thử phần mềm tự động với Selenium đã trở thành một chuẩn mực trong ngành phát triển phần mềm hiện đại. Qua bài viết, nhận thấy rõ ràng những lợi ích vượt trội mà kiểm thử tự động mang lại, từ việc tăng tốc độ, độ chính xác, khả năng bảo trì cho đến việc thúc đẩy sự hợp tác và minh bạch trong quy trình phát triển. Selenium WebDriver, cùng với các mẫu thiết kế như Page Object Model và sự hỗ trợ từ các framework BDD như Cucumber và Gherkin, đã tạo nên một bộ công cụ mạnh mẽ, linh hoạt và toàn diện để giải quyết các thách thức của kiểm thử phần mềm ngày nay.

Nhìn về tương lai, vai trò của kiểm thử tự động với Selenium sẽ tiếp tục được củng cố và mở rộng. Với sự phát triển của các công nghệ như AI và Machine Learning, có tiềm năng rất lớn để tích hợp các khả năng này vào các framework kiểm thử, giúp chúng trở nên thông minh hơn trong việc tạo kịch bản, tự phục hồi lỗi và tối ưu hóa quá trình kiểm thử. Các hệ thống tích hợp liên tục (CI) và triển khai liên tục (CD) sẽ ngày càng trở nên tinh vi hơn, cho phép các đội ngũ phát triển phần mềm đưa sản phẩm ra thị trường nhanh hơn với chất lượng cao hơn.

Mặc dù có nhiều công cụ kiểm thử tự động mới xuất hiện, Selenium vẫn giữ vững vị thế là một trong những lựa chọn hàng đầu nhờ vào cộng đồng lớn mạnh, khả năng mở rộng cao và sự hỗ trợ liên tục. Để duy trì sự cạnh tranh, các chuyên gia kiểm thử phần mềm cần không ngừng học hỏi, cập nhật kiến thức về các công nghệ mới và phương pháp tốt nhất trong việc xây dựng ứng dụng kiểm thử tự động với Selenium. Sự đầu tư vào kiểm thử tự động không chỉ là đầu tư vào chất lượng sản phẩm mà còn là đầu tư vào hiệu quả hoạt động và sự thành công lâu dài của doanh nghiệp.

6.1. Tổng kết những lợi ích và tiềm năng

Việc xây dựng ứng dụng kiểm thử phần mềm tự động với Selenium mang lại lợi ích lớn về tốc độ, độ chính xác, khả năng bảo trì và tiết kiệm chi phí. Nó cho phép các đội ngũ phát triển phần mềm phản ứng nhanh hơn với các thay đổi, đảm bảo chất lượng liên tục và giảm thiểu rủi ro. Tiềm năng của Selenium tiếp tục mở rộng với các tích hợp AI, Machine Learning và các công cụ CI/CD tiên tiến, giúp nâng cao hiệu quả và sự thông minh của quy trình kiểm thử tự động trong tương lai.

6.2. Hướng phát triển và thách thức tiếp theo

Hướng phát triển của kiểm thử tự động với Selenium bao gồm việc tích hợp sâu hơn với AI để tự động tạo và sửa chữa kịch bản, nâng cao khả năng kiểm thử không người can thiệp. Thách thức lớn nhất là duy trì sự ổn định của các kịch bản kiểm thử trước sự thay đổi nhanh chóng của giao diện người dùng và công nghệ web. Việc liên tục cập nhật kiến thức, áp dụng các mẫu thiết kế tốt như Page Object Model và tối ưu hóa tích hợp liên tục sẽ là chìa khóa để vượt qua những thách thức này, đảm bảo kiểm thử phần mềm luôn hiệu quả.

Nội dung chính

Tổng quan nghiên cứu

Theo Viện Tiêu chuẩn và Công nghệ Quốc gia Hoa Kỳ, các lỗi phần mềm gây tổn thất hàng tỷ USD mỗi năm cho nền kinh tế, trong đó hơn 33% chi phí có thể được phòng tránh nếu các quy trình kiểm thử được triển khai hiệu quả ngay từ giai đoạn đầu. Trong các dự án phát triển phần mềm hiện đại, chi phí dành cho hoạt động kiểm định chất lượng thường chiếm trên 50% tổng ngân sách dự án. Tuy nhiên, phương pháp kiểm thử thủ công truyền thống đang bộc lộ nhiều hạn chế nghiêm trọng như tiêu tốn nguồn nhân lực, thời gian kéo dài và dễ phát sinh sai sót do yếu tố con người, đặc biệt là khi thực hiện kiểm thử hồi quy lặp đi lặp lại qua nhiều phiên bản phát hành.

Luận văn thạc sĩ chuyên ngành Khoa học máy tính của tác giả Phạm Thị Hải Yến, dưới sự hướng dẫn khoa học của Phó Giáo sư Tiến sĩ Hoàng Xuân Huấn tại Trường Đại học Công nghệ – Đại học Quốc gia Hà Nội năm 2020, tập trung giải quyết bài toán nâng cao hiệu năng kiểm thử phần mềm thông qua việc nghiên cứu và xây dựng framework kiểm thử tự động hóa toàn diện. Mục tiêu trọng tâm của đề tài là ứng dụng bộ công cụ Selenium WebDriver kết hợp công cụ Cucumber và tích hợp hệ thống kiểm thử tự động vào quy trình Tích hợp liên tục thông qua máy chủ Jenkins.

Phạm vi nghiên cứu được triển khai thực nghiệm trực tiếp trên hệ thống dịch vụ thực tế tại Công ty Cổ phần Dịch vụ Công nghệ Thông tin VIVAS ở Hà Nội trong giai đoạn 2019-2020. Nghiên cứu mang ý nghĩa thực tiễn sâu sắc khi giúp rút ngắn thời gian thực thi một kịch bản kiểm thử từ 5 phút xuống chỉ còn 30 giây, cắt giảm hơn 85% thời gian kiểm thử hồi quy trên đa trình duyệt, đồng thời nâng cao độ tin cậy và chuẩn hóa quy trình phát triển phần mềm cho doanh nghiệp.

Cơ sở lý thuyết và phương pháp nghiên cứu

Khung lý thuyết áp dụng

Nghiên cứu xây dựng trên nền tảng kết hợp hai phương pháp phát triển phần mềm tiên tiến: Phát triển hướng kiểm thử và Phát triển hướng hành vi. Quy trình Phát triển hướng kiểm thử vận hành theo chu trình ba bước chặt chẽ gồm Đỏ, Xanh lá và Tái cấu trúc, tuân thủ 3 điều luật cơ bản nhằm đảm bảo mã nguồn chỉ được viết vừa đủ để vượt qua các bài kiểm thử định trước. Phương pháp Phát triển hướng hành vi đóng vai trò mở rộng, sử dụng ngôn ngữ Gherkin với các từ khóa chuẩn mực như Given, When, Then để đặc tả hành vi hệ thống bằng ngôn ngữ tự nhiên, giúp thu hẹp khoảng cách giao tiếp giữa lập trình viên, chuyên viên kiểm thử và chuyên viên phân tích nghiệp vụ.

Về kiến trúc tự động hóa, tác giả áp dụng mô hình thiết kế Page Object Model làm cấu trúc lõi cho framework. Mô hình này phân tách rành mạch giữa kho lưu trữ phần tử giao diện và các phương thức thực thi hành động, tạo nên tính đóng gói cao và khả năng tái sử dụng tối đa. Nghiên cứu khai thác 5 khái niệm kỹ thuật trọng tâm:

• Bộ định vị phần tử giao diện với 7 cơ chế nhận diện phần tử web bao gồm ID, Name, LinkText, TagName, ClassName, CSS Selector và XPath.
• Trình điều khiển tự động hóa Selenium WebDriver hỗ trợ tương tác trực tiếp trên 5 trình duyệt phổ biến như Chrome, Firefox, Safari, Opera và Internet Explorer.
• Ngôn ngữ đặc tả hành vi Gherkin và công cụ phân tích cú pháp Cucumber.
• Kiểm thử hồi quy tự động nhằm xác minh tính ổn định của hệ thống sau các đợt cập nhật tính năng.
• Hệ thống Tích hợp liên tục thông qua công cụ tự động hóa Jenkins quản lý quy trình build mã nguồn và thực thi kịch bản kiểm thử tự động.

Phương pháp nghiên cứu

Nghiên cứu sử dụng nguồn dữ liệu thực nghiệm gồm 120 kịch bản kiểm thử hồi quy thực tế từ các dịch vụ phần mềm đang vận hành tại Công ty VIVAS. Phương pháp chọn mẫu là chọn mẫu phi xác suất có chủ đích, ưu tiên lựa chọn các phân hệ chức năng trọng yếu có tần suất thay đổi mã nguồn cao như module đăng nhập, tra cứu dữ liệu và đăng ký dịch vụ.

Phương pháp phân tích dữ liệu kết hợp giữa phân tích định lượng và đánh giá hiệu năng so sánh đối đầu. Tác giả tiến hành đo lường chính xác các biến số: thời gian thực thi từng kịch bản, tổng thời gian kiểm thử toàn bộ hệ thống, mức độ tiêu hao nhân lực và tỷ lệ phát hiện lỗi giữa phương pháp kiểm thử thủ công và kiểm thử tự động. Lý do lựa chọn phương pháp này là vì nó cung cấp bằng chứng thực nghiệm rõ ràng, có khả năng lượng hóa chính xác hiệu quả đầu tư công nghệ trong chu kỳ 12 tháng triển khai dự án từ năm 2019 đến năm 2020. Toàn bộ mã nguồn kiểm thử được quản lý tập trung trên GitHub và liên kết trực tiếp với máy chủ Jenkins CI.

Kết quả nghiên cứu và thảo luận

Những phát hiện chính

Quá trình thực nghiệm đối sánh giữa kiểm thử thủ công và framework tự động hóa tại Công ty VIVAS mang lại các kết quả định lượng cụ thể:

Thứ nhất, tốc độ thực thi kịch bản kiểm thử được tối ưu hóa vượt bậc. Đối với một kịch bản kiểm thử đơn lẻ trên một trình duyệt, phương pháp thủ công tiêu tốn trung bình 300 giây (5 phút), trong khi kịch bản tự động hóa sử dụng Selenium WebDriver chỉ mất 30 giây để hoàn thành, giúp giảm tới 90% thời gian thực hiện.

Thứ hai, hiệu năng kiểm thử đa trình duyệt thể hiện ưu thế áp đảo. Khi tiến hành kiểm thử một kịch bản đồng thời trên 3 trình duyệt phổ biến gồm Google Chrome, Mozilla Firefox và Microsoft Edge, kiểm thử thủ công yêu cầu 900 giây (15 phút) thao tác lặp lại của kỹ sư kiểm thử. Ngược lại, hệ thống tự động hóa hoàn tất toàn bộ quy trình chỉ trong 90 giây, tiết kiệm chính xác 90% tổng thời gian thực thi.

Thứ ba, tỷ lệ bao phủ kiểm thử tự động hóa đạt trên 80% tổng số kịch bản kiểm thử hồi quy của dự án thí điểm. Việc này giúp doanh nghiệp giải phóng khoảng 50% khối lượng công việc thủ công nhàm chán cho đội ngũ kiểm thử viên, cho phép nhân sự tập trung vào các kịch bản kiểm thử thăm dò phức tạp.

Thứ tư, hệ thống tích hợp liên tục Jenkins CI rút ngắn thời gian phản hồi vòng lặp phát triển. Máy chủ CI tự động kích hoạt toàn bộ test suite sau mỗi lệnh commit mã nguồn lên GitHub, trả về báo cáo kết quả chi tiết trong vòng chưa đầy 2 phút, giúp phát hiện lỗi xung đột mã nguồn sớm hơn 70% so với chu trình kiểm thử thủ công hàng tuần.

Thảo luận kết quả

Nguyên nhân chính dẫn đến sự bứt phá về hiệu năng là nhờ việc ứng dụng kiến trúc Page Object Model kết hợp Cucumber BDD. Khi giao diện ứng dụng thay đổi, đội ngũ phát triển chỉ cần cập nhật định vị phần tử tại một lớp giao diện duy nhất thay vì phải chỉnh sửa hàng loạt kịch bản riêng lẻ, giúp giảm 70% thời gian bảo trì mã kiểm thử.

So với các giải pháp kiểm thử thương mại trên thị trường như QuickTest Professional (QTP) hay các công cụ trả phí của IBM, Selenium WebDriver khẳng định sự vượt trội nhờ bản quyền mã nguồn mở hoàn toàn miễn phí, hỗ trợ đa dạng 6 ngôn ngữ lập trình và khả năng tùy biến linh hoạt mà không phát sinh chi phí bản quyền hàng năm cho doanh nghiệp.

Dữ liệu nghiên cứu được trực quan hóa thông qua hệ thống biểu đồ cột đối sánh thời gian thực thi giữa kiểm thử thủ công và tự động, biểu đồ tròn thể hiện tỷ lệ phần trăm tự động hóa test case, cùng các bảng tổng hợp theo dõi chỉ số build từ Extent Reports và TestNG Report được nhúng trực tiếp trên giao diện quản trị của Jenkins CI.

Đề xuất và khuyến nghị

Từ kết quả thực nghiệm đạt được, nghiên cứu đưa ra 4 khuyến nghị hành động chiến lược dành cho các tổ chức công nghệ:

Thứ nhất, chuẩn hóa cấu trúc dự án kiểm thử theo mô hình Page Object Model. Các doanh nghiệp phần mềm cần áp dụng triệt để mô hình Page Object Model nhằm phân tách rõ ràng giữa giao diện, luồng xử lý và dữ liệu kiểm thử. Mục tiêu giảm ít nhất 60% tình trạng trùng lặp mã nguồn kiểm thử trong vòng 3 tháng đầu triển khai, do nhóm kỹ sư kiểm thử tự động chủ trì thực hiện.

Thứ hai, mở rộng thực thi kiểm thử song song trên hạ tầng đám mây. Doanh nghiệp cần tích hợp Selenium Grid hoặc hạ tầng Docker vào hệ thống Jenkins CI hiện tại để nâng công suất chạy đồng thời 500 kịch bản kiểm thử, rút ngắn thời gian phản hồi toàn bộ hệ thống xuống dưới 10 phút. Thời gian hoàn thành trong quý 2, do bộ phận DevOps phối hợp cùng Trưởng nhóm Đảm bảo Chất lượng triển khai.

Thứ ba, thiết lập chương trình đào tạo chuyển đổi kỹ năng kiểm thử. Tổ chức các khóa đào tạo nội bộ kéo dài 40 giờ về cú pháp Gherkin, tư duy BDD và kỹ năng lập trình Java căn bản cho 100% chuyên viên kiểm thử thủ công trong thời hạn 6 tháng, nhằm xây dựng đội ngũ kỹ sư kiểm thử chất lượng cao. Đơn vị phụ trách là Phòng Nhân sự phối hợp cùng các Chuyên gia Kiểm thử tự động.

Thứ tư, tự động hóa quy trình kích hoạt kiểm thử đêm. Thiết lập lịch trình chạy tự động 100% bộ kịch bản kiểm thử hồi quy vào khung giờ 0h00 hàng ngày thông qua Jenkins cron job, hướng tới mục tiêu phát hiện và xử lý 95% lỗi hồi quy trước mỗi phiên bản phát hành chính thức. Đơn vị thực thi là Đội ngũ Vận hành Hệ thống và Trưởng dự án phần mềm.

Đối tượng nên tham khảo luận văn

Tài liệu luận văn mang lại giá trị thực tiễn và học thuật cho 4 nhóm đối tượng chính:

Nhóm chuyên viên kiểm thử phần mềm: Cung cấp tài liệu hướng dẫn kỹ thuật chi tiết từ việc thiết lập thư viện Maven, viết kịch bản Gherkin, cấu hình WebDriver đến xử lý 7 loại locator, giúp các kiểm thử viên thủ công chuyển đổi thành công sang kỹ sư kiểm thử tự động trong vòng 3 đến 6 tháng.

Nhóm trưởng nhóm Đảm bảo Chất lượng và Quản lý Dự án: Cung cấp khung đo lường hiệu quả đầu tư công nghệ rõ ràng với các chỉ số định lượng về việc tiết kiệm 50% nguồn lực và cắt giảm 90% thời gian kiểm thử hồi quy, làm căn cứ vững chắc để xây dựng đề án tự động hóa quy trình kiểm thử cho doanh nghiệp.

Nhóm kỹ sư phát triển phần mềm và Chuyên viên DevOps: Cung cấp mô hình kết hợp hoàn chỉnh giữa TDD, BDD và luồng tự động hóa CI/CD qua Jenkins, hỗ trợ thiết lập cơ chế kiểm soát chất lượng mã nguồn tự động ngay trên nhánh phát triển của Git.

Nhóm giảng viên, học viên cao học và sinh viên ngành Công nghệ Thông tin: Đóng vai trò là tài liệu tham khảo học thuật chuẩn mực với 74 tài liệu trích dẫn chuyên sâu, hệ thống hóa toàn diện các mẫu thiết kế phần mềm và phương pháp luận kiểm thử tự động hóa hiện đại.

Câu hỏi thường gặp

Tại sao nên kết hợp Cucumber với Selenium WebDriver thay vì chỉ dùng Selenium thuần?

Cucumber đóng vai trò như một cầu nối ngôn ngữ tự nhiên thông qua cú pháp Gherkin, cho phép tất cả các bên như khách hàng, phân tích nghiệp vụ và lập trình viên đều hiểu rõ kịch bản kiểm định. Trong khi đó, Selenium WebDriver trực tiếp thực thi thao tác kỹ thuật trên trình duyệt. Sự kết hợp này giúp tăng tính minh bạch của tài liệu kiểm thử và giảm 40% hiểu lầm về mặt nghiệp vụ so với việc chỉ viết mã kiểm thử thuần túy bằng ngôn ngữ lập trình.

Mô hình Page Object Model giải quyết bài toán bảo trì mã nguồn như thế nào?

Trong kiểm thử tự động, giao diện người dùng thường xuyên thay đổi khiến các locator bị sai lệch. Mô hình Page Object Model cô lập các phần tử giao diện của mỗi trang web vào một lớp Java độc lập. Khi giao diện thay đổi, kỹ sư chỉ cần cập nhật locator tại đúng một vị trí duy nhất trong Page UI thay vì phải rà soát hàng trăm kịch bản kiểm thử, giúp giảm tới 70% thời gian bảo trì hệ thống.

Trong 7 cơ chế định vị phần tử của Selenium, cơ chế nào mang lại độ ổn định cao nhất?

Định vị bằng ID là phương thức tối ưu và nhanh nhất do tính chất duy nhất của thuộc tính này trên cây cấu trúc DOM. Trường hợp phần tử không có thuộc tính ID, định vị bằng Name hoặc CSS Selector là các lựa chọn ưu tiên tiếp theo. XPath tuy có khả năng điều hướng linh hoạt nhưng có tốc độ xử lý chậm hơn và dễ bị gãy nếu cấu trúc trang web thay đổi, do đó nên ưu tiên sử dụng XPath tương đối thay cho XPath tuyệt đối.

Chi phí đầu tư ban đầu cho kiểm thử tự động có thực sự hiệu quả không?

Mặc dù giai đoạn thiết lập ban đầu đòi hỏi chi phí về thời gian và công sức xây dựng framework cao hơn kiểm thử thủ công, nhưng kiểm thử tự động mang lại điểm hòa vốn rất nhanh. Ngay từ lần chạy kiểm thử hồi quy thứ 3 trên hệ thống thực tế, chi phí vận hành bắt đầu giảm mạnh. Tốc độ thực thi nhanh gấp 10 lần giúp doanh nghiệp tiết kiệm hàng trăm giờ lao động trong mỗi chu kỳ phát hành sản phẩm.

Vai trò cốt lõi của Jenkins trong hệ thống kiểm thử tự động là gì?

Jenkins đóng vai trò là trung tâm điều phối tự động trong quy trình Tích hợp liên tục. Thay vì con người phải kích hoạt kịch bản bằng tay, Jenkins tự động lắng nghe các sự kiện thay đổi mã nguồn trên kho lưu trữ, tự động biên dịch, khởi chạy bộ kiểm thử Selenium và xuất báo cáo kết quả trực quan đến hộp thư của đội ngũ phát triển chỉ trong vòng 2 phút, đảm bảo chất lượng phần mềm được kiểm soát 24/7.

Kết luận

• Luận văn xây dựng thành công framework kiểm thử tự động hóa hoàn chỉnh dựa trên sự kết hợp giữa Selenium WebDriver, Cucumber BDD và mô hình thiết kế Page Object Model.
• Thực nghiệm tại Công ty VIVAS chứng minh framework giúp rút ngắn 90% thời gian thực thi kiểm thử và đạt tỷ lệ bao phủ hơn 80% các kịch bản kiểm thử hồi quy định kỳ.
• Tích hợp thành công hệ thống kiểm thử tự động vào máy chủ Jenkins CI, thiết lập chu trình phản hồi chất lượng mã nguồn tự động chỉ trong vòng 2 phút sau khi build.
• Đóng góp bộ tài liệu thực hành và phương pháp luận chuẩn xác cho các doanh nghiệp công nghệ muốn chuyển đổi từ kiểm thử thủ công sang tự động hóa hiệu quả.
• Kế hoạch phát triển trong 6 tháng tiếp theo tập trung vào việc mở rộng kiểm thử song song đa luồng với Selenium Grid và ứng dụng kiểm thử tự động trên nền tảng ứng dụng di động.

Độc giả quan tâm đến việc tối ưu hóa quy trình kiểm thử phần mềm và xây dựng hệ thống CI/CD có thể tham khảo toàn văn luận văn thạc sĩ của tác giả Phạm Thị Hải Yến tại Thư viện Trường Đại học Công nghệ – Đại học Quốc gia Hà Nội để tiếp cận toàn bộ mã nguồn và cấu hình kỹ thuật chi tiết.

Trích đoạn nội dung tài liệu

CHƯƠNG 1: GIỚI THIỆU VỀ KIỂM THỬ PHẦN MỀM Một nghiên cứu được tiến hành bởi NIST trong những năm gần đây cho biết rằng các lỗi phần mềm gây tổn thất cho nền kinh tế Mỹ một con số đáng kể, hơn một phần ba chi phí này có thể tránh được nếu việc kiểm thử phần mềm được thực hiện tốt hơn. Người ta thường tin rằng, một kiếm khuyết nếu được tìm ra sớm hơn thì chi phí để sửa chữa nó sẽ rẻ hơn. Do vậy kiểm thử phần mềm là hoạt động vô cùng quan trọng trong chu trình phát triển phần mềm ở các công ty công nghệ hiện nay. Giới thiệu về kiểm thử phần mềm Kiểm thử phần mềm là quá trình thực thi 1 chương trình với mục đích tìm ra lỗi.

Kiểm thử phần mềm đảm bảo phần mềm đáp ứng chính xác, đầy đủ và đúng theo yêu cầu của khách hàng, yêu cầu của sản phẩm đã đặt ra. Kiểm thử có thể cung cấp cho doanh nghiệp một quan điểm, một cách nhìn độc lập về phần mềm để từ đó cho phép đánh giá và thấu hiểu được những rủi ro trong quá trình triển khai phần mềm [1]. Các mục tiêu chính của kiểm thử phần mềm:  Trong thời gian xác định trước, kiểm thử viên tìm được càng nhiều lỗi càng tốt.  Đảm bảo rằng phần mềm cuối cùng phù hợp với các yêu cầu đặc tả của nó.

 Đo lường chất lượng của sản phẩm và dự án.  Viết kịch bản kiểm thử (testcase) chất lượng cao, thực hiện kiểm thử hiệu quả và đưa ra các báo cáo chính xác. Kiểm thử tự động là thực hiện kiểm thử phần mềm bằng một chương trình đặc biệt với rất ít hoặc không có sự tương tác của con người, giúp kiểm thử viên không phải lặp đi lặp lại các bước nhàm chán. Trong kiểm thử tự động, có các Testscript được viết sẵn và chạy tự động để so sánh kết quả thực tế với kết quả mong đợi.

Kiểm thử tự động hoạt động rất hiệu quả khi cần thực hiện các kiểm tra lặp lại và hồi quy để đảm bảo rằng một ứng dụng hoạt động chính xác sau khi có thay đổi mới. Các TestScript chạy với sự trợ giúp của các công cụ, tập lệnh và phần mềm để thực hiện các hành động được xác định trước được viết trong kịch bản kiểm thử. Trong một số dự án, kiểm thử phần mềm chiếm khoảng trên 50% tổng giá phát triển phần mềm. Do đó một trong các mục tiêu của kiểm thử là tự động hóa kiểm thử, nhờ đó mà giảm thiểu chi phí rất nhiều, tối thiểu hóa các lỗi do người gây ra, đặc biệt giúp việc kiểm thử hồi qui dễ dàng và nhanh chóng hơn.

Ưu điểm của kiểm thử tự động a. Tính hiệu quả trong công việc: Ưu điểm lớn nhất của kiểm thử tự động là thay thế con người lặp đi lặp lại đúng quy tắc các bước kiểm thử nhàm chán, tránh được hao phí về mặt thời gian. Độ tin cậy: Dù lặp đi lặp lại nhiều lần vẫn cho ra kết quả giống nhau do vậy độ ổn định cao, tránh được rủi ro có thể phát sinh. Cải thiện chất lượng: Kiểm thử tự động làm giảm rủi ro về mặt chất lượng sản phẩm, việc kiểm thử được thực hiện một cách nhanh chóng.

Có thể tái sử dụng các trường hợp kiểm thử. Tốc độ xử lý cực nhanh: Nếu mất 5 phút để kiểm thử thủ công thì chỉ cần mất 30s nếu sử dụng kiểm thử tự động. Chi phí thấp: Việc rút ngắn thời gian và tiết kiệm nhân lực giúp cho việc kiểm thử tự động trở nên hiệu quả. Nhược điểm của kiểm thử tự động a.

Ban đầu thì chi phí cho kiểm thử tự động sẽ cao hơn kiểm thử thủ công b. Để kiểm thử tự động thực hiện được thì vẫn cần con người phải bỏ thời gian, công sức và tiền bạc,. Mất chi phí cho các công cụ tự động hóa như bản quyền, bảo trì, tìm hiểu, training. Khó mở rộng hơn nhiều so với kiểm thử thủ công e.

Yêu cầu những người có trình độ chuyên môn cao mới thực hiện được f. Số lượng công việc phải làm để mở rộng cho kiểm thử tự động sẽ nhiều và khó hơn so với kiểm thử thủ công. Phát triển hướng kiểm thử TDD (Test Driven Development) 1. Khái niệm Phát triển hướng kiểm thử TDD (Test Driven Development) là một phương thức làm việc, hay một quy trình viết mã hiện đại.

Lập trình viên sẽ thực hiện thông qua các bước nhỏ và tiến độ được đảm bảo liên tục bằng cách viết và chạy các bài kiểm thử tự động. Quá trình lập trình trong TDD cực kỳ chú trọng vào các bước liên tục sau: a. Viết 1 kịch bản kiểm thử cho hàm mới. Đảm bảo rằng kiểm thử sẽ bị sai.

Chuyển qua lập trình sơ khai nhất cho hàm đó để kiểm thử có thể đúng c. Tối ưu hóa đoạn mã nguồn của hàm vừa viết sao cho đảm bảo kiểm thử vẫn đúng và tối ưu nhất cho việc lập trình kế tiếp d. Lặp lại cho các hàm khác từ bước 1. Thực tế, nên sử dụng UnitTestFramework cho TDD (như JUnit trong Java), chúng ta có thể có được môi trường hiệu quả vì các kiểm thử được thông báo rõ ràng thông qua màu sắc:  Đỏ: kiểm thử sai, chuyển sang viết chức năng cho kiểm thử đúng  Xanh lá: viết một kiểm thử mới hoặc tối ưu mã nguồn đã viết trong màu đỏ.

Phát triển hướng kiểm thử TDD (Test-Driven Development) là kết hợp phương pháp Phát triển kiểm thử trước (Test First Development) và phương pháp Điều chỉnh lại mã nguồn (Refactoring). Mục tiêu quan trọng nhất của TDD là nghĩ về thiết kế trước khi viết mã nguồn cho chức năng. Một quan điểm khác lại cho rằng TDD là một kỹ thuật lập trình. Nhưng nhìn chung, mục tiêu của TDD là viết mã nguồn sáng sủa, rõ ràng và có thể chạy được.

Chu trình TDD qua màu sắc (từ trang 1minus1.com) Ba điều luật khi áp dụng TDD  Không cho phép viết bất kỳ một mã chương trình nào cho tới khi nó làm một kiểm thử bị sai trở nên đúng.  Không cho phép viết nhiều hơn một kiểm thử đơn vị mà nếu chỉ cần 1 kiểm thử đơn vị cũng đã đủ để sai. Hãy chuyển sang lập trình chức năng để làm đúng kiểm thử đó trước.  Không cho phép viết nhiều hơn 1 mã chương trình mà nó đã đủ làm một kiểm thử bị sai chuyển sang đúng.

Các bước thực hiện trong chu trình TDD 15 Hình 1. Các bước thực hiện TDD Từ trang http://agiledata.org/essays/tdd. Các cấp độ TDD Mức chấp nhận (Acceptance TDD (ATDD)): với ATDD thì bạn viết một kiểm thử chấp nhận đơn hoặc một đặc tả hành vi (behavioral specification) tùy theo cách gọi của bạn; mà kiểm thử đó chỉ cần đủ cho các mã chương trình sản phẩm thực hiện (đúng hoặc sai) được kiểm thử đó. Mức chấp nhận (Acceptance TDD) còn được gọi là Behavior Driven Development (BDD).

Mức lập trình (Lập trình viên TDD): với mức này bạn cần viết một kiểm thử lập trình đơn (single lập trình viên test) đôi khi được gọi là kiểm thử đơn vị mà kiểm thử đó chỉ cần đủ cho các mã chương trình sản phẩm thực hiện (đúng hoặc sai) được kiểm thử đó. Mức lập trình (Lập trình viên TDD) thông thường được gọi là TDD.Vậy nên, thực chất BDD là 1 loại TDD, và người ta thường gọi Lập trình viên TDD là TDD. Các lỗi thường gặp khi áp dụng TDD ● Không quan tâm đến các kịch bản kiểm thử bị sai ● Quên đi thao tác tối ưu sau khi viết mã nguồn cho kịch bản kiểm thử đúng ● Thực hiện tối ưu mã nguồn trong lúc viết mã nguồn cho kiểm thử đúng ● Đặt tên các kịch bản kiểm thử khó hiểu và tối nghĩa ● Không bắt đầu từ các kiểm thử đơn giản nhất và không theo các bước nhỏ. ● Chỉ chạy mỗi kịch bản kiểm thử đang bị sai hiện tại ● Viết một kịch bản kiểm thử với kịch bản quá phức tạp 1.

Phát triển hướng hành vi BDD (Behaviour Driven Development) 1. Khái niệm Phát triển hướng hành vi Behaviour Driven Development (BDD) là một quá trình phát triển phần mềm có nguồn gốc từ Test Driven Development (TDD). BDD sử dụng các ví dụ để minh họa hành vi của hệ thống được viết bằng ngôn ngữ dễ đọc và dễ hiểu đối với tất cả mọi người tham gia vào quá trình phát triển Thay vì chờ đợi sản phẩm hoàn thành và kiểm thử, đội ngũ phát triển tham gia vào quá trình xây dựng mã nguồn với vai trò phân tích và xây dựng hệ thống kịch bản kiểm thử dưới góc độ ngôn ngữ tự nhiên dễ hiểu từ các yêu cầu (requirement). Đồng thời, họ giúp đỡ lập trình viên trong việc giải thích và đưa ra các phương án xây dựng mã nguồn mang tính thực tiễn với người dùng ngay trước khi bắt tay xây dựng.

Người lập trình viên liên hệ mật thiết với người kiểm thử viên và xây dựng mã nguồn với những phương án mà kiểm thử viên cung cấp theo mô hình TDD. TDD kết hợp với BDD Hình 1. Chu trình làm việc kết hợp TDD và BDD (Từ trang http://agiledata.org/essays/tdd. Quy trình phát triển phần mềm truyền thống Hình 1.

Quy trình phát triển truyền thống (Từ trang http://agiledata.org/essays/tdd.html) (Từ trang BDD in action (Behavior-Driven Development for the whole software lifecycle) - John Ferguson Smart (Foreword by Dan North)) Trong quy trình phát triển truyền thống, việc phân tích các yêu cầu (requirements) thường được tiến hành bởi chuyên viên phân tích nghiệp vụ (BA) một cách chuyên hóa và khi đến giai đoạn xây dựng (implementing phase) thì đa phần các lập trình viên tiếp xúc với các yêu cầu phần mềm dưới dạng các bản thiết kế. Họ chỉ quan tâm đến đầu vào, đầu ra (Input, Output) của tính năng mình xây dựng mà thiếu đi cái nhìn thực tiễn từ góc nhìn người dùng (end-users). Một hệ quả tất yếu là lỗi phần mềm đến từ việc sản phẩm ko tiện dụng với người dùng. Quy trình phát triển theo hướng BDD 19 Hình 1.

Quy trình phát triển BDD (Từ trang http://agiledata.org/essays/tdd.html) (Từ trang BDD in action (Behavior-Driven Development for the whole software lifecycle) - John Ferguson Smart (Foreword by Dan North)) Việc ứng dụng BDD góp phần làm gần khoảng cách giữa đội ngũ thiết kế phần mềm và sản phẩm thực tiễn, tối ưu quy trình. Cụ thể như sau:  Thông qua kịch bản kiểm thử, lập trình viên có cái nhìn trực quan về sản phẩm ngay trước khi xây dựng mã nguồn. Sản phẩm họ tạo ra chính xác và gần gũi người dùng hơn.  Phần mã nguồn được thêm vào chỉ vừa đủ để chạy thành công kịch bản kiểm thử, hạn chế dư thừa và qua đó hạn chế khả năng xảy ra lỗi trên những phần dư thừa.