Luận văn sinh mã kiểm thử tự động theo kịch bản BDD - ĐH Công nghệ

Nghiên cứu phương pháp sinh mã kiểm thử tự động từ kịch bản kiểm thử hướng hành vi BDD, tối ưu hóa quy trình đảm bảo chất lượng phần mềm.

• Tác giả: Nguyễn Thị Hồng Nhung
• Người hướng dẫn: PGS.TS. Trương Anh Hoàng
• Trường học: Trường Đại học Công nghệ, Đại học Quốc gia Hà Nội
• Chuyên ngành: Kỹ thuật phần mềm
• Đề tài: Nghiên cứu sinh mã kiểm thử tự động dựa trên kịch bản kiểm thử hướng hành vi
• Loại tài liệu: Luận văn thạc sĩ
• Năm xuất bản: 2018
• Địa điểm: Hà Nội

Tóm tắt

I. Tổng quan về sinh mã kiểm thử tự động theo kịch bản hướng hành vi

Kiểm thử phần mềm là giai đoạn tiêu tốn nhiều thời gian và nhân lực kỹ thuật. Kiểm thử hướng hành vi (Behavior-Driven Development - BDD) giải quyết bài toán giao tiếp giữa các bên liên quan. Phương pháp này mô tả chức năng phần mềm dưới dạng ngôn ngữ tự nhiên có cấu trúc. Các kịch bản hành vi phản ánh chính xác nghiệp vụ thực tế từ góc nhìn người dùng cuối. Việc sinh mã kiểm thử tự động dựa trên kịch bản hành vi là bước tiến quan trọng trong kỹ thuật phần mềm. Công nghệ này chuyển đổi các câu lệnh đặc tả thành mã lệnh lập trình tương ứng. Hệ thống tự động phân tích cú pháp và khởi tạo các khung mã nguồn cần thiết. Kỹ sư kiểm thử không cần viết lại toàn bộ mã kiểm thử từ đầu. Quy trình phát triển phần mềm trở nên linh hoạt và minh bạch hơn. Mã kiểm thử sinh ra có khả năng thực thi trực tiếp trên các môi trường thử nghiệm. Điều này giúp phát hiện lỗi phần mềm sớm và giảm thiểu chi phí sửa lỗi.

1.1. Khái niệm và vai trò của kiểm thử hướng hành vi

Kiểm thử hướng hành vi (BDD) là phương pháp mở rộng từ phát triển hướng kiểm thử (TDD). Trọng tâm của BDD là hành vi người dùng và mục tiêu nghiệp vụ. Phương pháp tạo ra cầu nối liên lạc thống nhất giữa khách hàng, lập trình viên và kiểm thử viên. Tất cả thành viên đều hiểu rõ yêu cầu chức năng thông qua tài liệu chung. Kịch bản BDD đóng vai trò như một đặc tả yêu cầu sống của hệ thống phần mềm. Tài liệu này vừa có tính diễn giải cho con người vừa có khả năng thực thi tự động. Do đó, BDD nâng cao độ chính xác của các ca kiểm thử chấp nhận và giảm thiểu sai sót phát sinh.

1.2. Cấu trúc kịch bản kiểm thử bằng ngôn ngữ Gherkin

Ngôn ngữ Gherkin cung cấp cú pháp đơn giản để viết kịch bản kiểm thử hướng hành vi. Cấu trúc cơ bản của một kịch bản gồm các mệnh đề Given, When và Then. Mệnh đề Given mô tả ngữ cảnh hoặc điều kiện tiên quyết của hệ thống. Mệnh đề When xác định hành động cụ thể do người dùng thực hiện. Mệnh đề Then biểu diễn kết quả mong đợi sau khi thực thi hành động. Ngoài ra, các từ khóa And hoặc But giúp bổ sung các điều kiện phụ trợ một cách rõ ràng. Tài liệu Gherkin lưu trữ dưới định dạng tệp tính năng (feature file). Cấu trúc chặt chẽ này tạo tiền đề vững chắc cho việc phân tích cú pháp và tự động sinh mã kiểm thử.

II. Thách thức trong sinh mã kiểm thử tự động cho kịch bản hành vi

Quá trình chuyển đổi từ yêu cầu văn bản sang mã kiểm thử tự động gặp nhiều rào cản kỹ thuật. Việc lập trình mã kiểm thử thủ công đòi hỏi chuyên môn cao và tiêu tốn nhiều công sức. Khi yêu cầu phần mềm thay đổi liên tục, việc cập nhật mã nguồn kiểm thử dễ dẫn đến sai sót. Khoảng cách ngữ nghĩa giữa ngôn ngữ tự nhiên và mã lệnh máy tính là một thách thức lớn. Ngôn ngữ tự nhiên thường chứa đựng tính mơ hồ và thiếu tính chặt chẽ của logic lập trình. Các công cụ kiểm thử truyền thống khó phân tích chính xác ý định người dùng nếu không có cấu trúc chuẩn. Thêm vào đó, việc duy trì tính đồng bộ giữa tài liệu đặc tả và bộ mã kiểm thử tốn nhiều tài nguyên của dự án. Nếu thiếu quy trình sinh mã tự động, sự sai lệch giữa kịch bản và mã thực thi sẽ gia tăng. Điều này làm giảm độ tin cậy của toàn bộ hệ thống kiểm thử chấp nhận.

2.1. Hạn chế của phương pháp viết mã kiểm thử thủ công

Phương pháp viết mã kiểm thử thủ công tồn tại nhiều hạn chế cố hữu trong các dự án quy mô lớn. Kỹ sư phải tự viết từng hàm kiểm thử và ánh xạ từng thành phần giao diện. Quá trình này lặp đi lặp lại nhiều lần gây lãng phí thời gian và nhân lực. Tỷ lệ xảy ra lỗi do con người trong quá trình lập trình kiểm thử tương đối cao. Khi giao diện hoặc luồng nghiệp vụ thay đổi, việc sửa chữa mã nguồn tốn rất nhiều công sức. Kiểm thử viên khó bắt kịp tốc độ phát triển liên tục của các bản phát hành mới. Sự chậm trễ này cản trở tiến độ kiểm thử hồi quy và làm tăng nguy cơ lọt lỗi sản phẩm.

2.2. Khoảng cách ngữ nghĩa giữa đặc tả và mã kiểm thử

Đặc tả kịch bản hành vi được diễn đạt bằng ngôn ngữ tự nhiên có cấu trúc. Ngược lại, mã kiểm thử yêu cầu các chỉ lệnh lập trình chính xác và tường minh. Việc phân tích cú pháp để hiểu đúng ngữ nghĩa của từng mệnh đề hành vi đòi hỏi thuật toán xử lý phức tạp. Nếu các bước kịch bản viết không theo chuẩn, công cụ tự động sẽ không thể nhận diện hành động. Sự không đồng nhất về từ vựng giữa các tài liệu đặc tả gây khó khăn cho việc ánh xạ hàm. Ngoài ra, việc xử lý các tham số đầu vào và định danh phần tử giao diện trong văn bản tự nhiên vẫn là một thách thức kỹ thuật lớn.

III. Phương pháp sinh mã kiểm thử tự động từ kịch bản kiểm thử BDD

Phương pháp sinh mã tự động kết hợp xử lý ngôn ngữ tự nhiên và các khung kiểm thử tiêu chuẩn. Quá trình bắt đầu bằng việc đọc và phân tích tệp tính năng Gherkin. Công cụ tự động bóc tách các mệnh đề Given, When, Then thành các cấu trúc dữ liệu trung gian. Mỗi mệnh đề được đối sánh mẫu văn bản để tự động tạo ra khung phương thức tương ứng. Công cụ Cucumber đóng vai trò phân giải các bước kịch bản thành các chú thích (annotations) như @Given, @When, @Then. Tiếp theo, hệ thống tích hợp Selenium WebDriver để thực hiện các thao tác trình duyệt cụ thể như gửi dữ liệu hoặc nhấp chuột. Thư viện kiểm thử được tự động khởi tạo qua các hook cấu hình @Before và @After. Kỹ thuật xử lý ngôn ngữ tự nhiên (NLP) hỗ trợ trích xuất thực thể và hành vi chính xác từ văn bản. Sự kết hợp này tạo nên chu trình sinh mã hoàn chỉnh, chính xác và có khả năng chạy tự động.

3.1. Quy trình ánh xạ kịch bản Given When Then sang mã nguồn

Quy trình ánh xạ kịch bản chuyển đổi các câu lệnh văn bản thành các phương thức Java tương ứng. Bộ phân tích cú pháp quét từng dòng lệnh trong tệp kịch bản Gherkin. Các biểu thức chính quy (Regex) được áp dụng để trích xuất các tham số động từ chuỗi văn bản. Hệ thống tự động tạo ra các phương thức tương ứng với chú thích @Given, @When, @Then hoặc @And. Phần thân phương thức được chèn các đoạn mã gọi lệnh phù hợp với ngữ cảnh hành vi. Ví dụ, câu lệnh nhập tên người dùng sẽ sinh ra mã gửi chuỗi ký tự vào ô văn bản. Cơ chế này đảm bảo mã nguồn sinh ra luôn tuân thủ cấu trúc chuẩn của khung kiểm thử.

3.2. Tích hợp Cucumber và Selenium WebDriver để thực thi

Cucumber đóng vai trò liên kết giữa kịch bản tự nhiên và các đoạn mã định nghĩa bước thực hiện. Tuy nhiên, Cucumber không trực tiếp điều khiển giao diện web. Do đó, hệ thống tích hợp Selenium WebDriver để tương tác với trình duyệt như Chrome hoặc Firefox. Các hàm điều khiển như driver.get(), sendKeys() và click() được gọi tự động trong thân hàm kiểm thử. Hook @Before được cấu hình để khởi tạo trình duyệt và nạp đường dẫn ứng dụng trước khi chạy ca thử nghiệm. Hook @After chịu trách nhiệm đóng phiên làm việc và giải phóng tài nguyên sau khi kết thúc. Sự kết hợp này cho phép chạy kiểm thử tự động toàn diện trên nền tảng web.

IV. Đánh giá hiệu quả và ứng dụng sinh mã kiểm thử tự động BDD

Sinh mã kiểm thử tự động từ kịch bản hướng hành vi mang lại giá trị thực tiễn to lớn. Giải pháp này giúp rút ngắn đáng kể chu kỳ phát triển và phát hành phần mềm. Độ phủ kiểm thử tăng cao nhờ việc tự động hóa các kịch bản kiểm thử chấp nhận phức tạp. Sự phối hợp giữa nhóm kỹ thuật và các bên liên quan trở nên chặt chẽ và nhất quán hơn. Đội ngũ kiểm thử giảm tải được khối lượng công việc thủ công đơn điệu để tập trung vào các trường hợp kiểm thử chuyên sâu. Trong thực tế, phương pháp này dễ dàng tích hợp vào đường ống phân phối và tích hợp liên tục (CI/CD). Việc phát hiện lỗi ngay từ giai đoạn phát triển giúp doanh nghiệp tiết kiệm tối đa ngân sách bảo trì. Đây là định hướng phát triển tất yếu nhằm nâng cao năng suất và chất lượng trong kỹ nghệ phần mềm hiện đại.

4.1. Tối ưu hóa chi phí và nâng cao chất lượng phần mềm

Tự động sinh mã kiểm thử giúp cắt giảm mạnh mẽ chi phí vận hành dự án phần mềm. Các kỹ sư không còn mất nhiều ngày để thiết lập các ca kiểm thử hồi quy cơ bản. Thời gian phát hiện khiếm khuyết được đẩy lên sớm ngay trong chu trình phát triển. Điều này giảm bớt chi phí sửa lỗi so với giai đoạn kiểm thử xuất xưởng. Chất lượng phần mềm được bảo đảm nhờ việc thực thi kiểm thử liên tục và ổn định. Tài liệu kiểm thử bằng ngôn ngữ tự nhiên cũng trở thành tài liệu nghiệp vụ chuẩn xác cho toàn bộ tổ chức. Nhờ đó, hiệu suất làm việc của toàn bộ đội ngũ phát triển phần mềm được nâng cao rõ rệt.

4.2. Hướng phát triển công cụ tự động hóa kiểm thử tương lai

Nghiên cứu sinh mã tự động tiếp tục mở rộng với sự hỗ trợ của trí tuệ nhân tạo và xử lý ngôn ngữ tự nhiên nâng cao. Các công cụ tương lai có khả năng tự động phân tích các kịch bản viết bằng ngôn ngữ tự nhiên không cần tuân thủ nghiêm ngặt cú pháp Gherkin. Mô hình học sâu hỗ trợ suy luận ngữ cảnh và tự động định vị các phần tử giao diện phức tạp. Khả năng tự sửa lỗi mã kiểm thử khi giao diện thay đổi cũng là một hướng đi triển vọng. Việc tối ưu hóa các thuật toán sinh mã sẽ mang lại trải nghiệm kiểm thử mượt mà hơn. Công nghệ này sẽ trở thành tiêu chuẩn cốt lõi trong quy trình kỹ nghệ phần mềm thông minh.

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

MỞ ĐẦU Ứng dụng tự động hoá trong nhiều lĩnh vực ngày càng phát triển. Trong lĩnh vực làm phần mềm càng lúc lại càng được tự động hóa nhiều hơn. Kiểm thử là một trong những giai đoạn làm phần mềm, làm sao để tự động và đơn giản hóa quá trình kiểm thử đang là một vấn đề được quan tâm. Luận văn tập trung nghiên cứu về kiểm thử động hướng hành vi.

Từ việc nghiên cứu sinh mã kiểm thử tự động của các công cụ kiểm thử tự động, luận văn áp dụng ứng dụng công cụ vào kiểm thử và tìm hiểu phương pháp xây dựng công cụ kiểm thử tự động trong kiểm thử hướng hành vi.1 Khái quát vấn đề Kiểm thử phần mềm theo hướng kiểm thử hướng hành vi (BDD – Behavior Driven Testing) [2] là một khái niệm mở rộng của TDD (Test Driven Development). TDD là khái niệm kiểm thử theo hướng kiểm thử từng phần, viết ca kiểm thử [12] trước rồi lập trình sau. Trong kiểm thử hướng hành vi dựa trên yêu cầu của người sử dụng chúng ta xây dựng các ca kiểm thử. Một trong những điểm yếu khi lập trình phần mềm là rất khó để đáp ứng được đúng yêu cầu của người sử dụng, có nhiều nguyên nhân, trong đó có nguyên nhân là người lập trình không hiểu được yêu cầu người dùng.

Vì vậy nếu sử dụng được trực tiếp ngôn ngữ của người sử dụng vào các ca kiểm thử thì sẽ có được một phần mềm đúng với yêu cầu người sử dụng mà không lãng phí nhiều tài nguyên. Đồng thời kiểm thử tự động với mã kiểm thử hướng hành vi sẽ giúp tiết kiệm nguồn nhân lực kiểm thử, giảm thiểu tối đa chi phí làm phần mềm, sản phẩm. Qua tìm hiểu một số công cụ kiểm thử tự động trong kiểm thử hướng hành vi hiện nay sinh phương thức kiểm thử nhưng không sinh thân hàm kiểm thử. Ví dụ với công cụ kiểm thử tự động Cucumber, Từ kịch bản kiểm thử ngôn ngữ tự nhiên: Feature: search Wikipedia Scenario: direct search article Given Enter search term 'Cucumber' When Do search Then Single result is shown for 'Cucumber' 2 Thông qua công cụ kiểm thử tự động, các phương thức được sinh ra như sau: @Given ("^Enter search term 'Cucumber'$") public void enter_search_term_Cucumber() throws Throwable { // Write code here that turns the phrase above into concrete actions } @When("^Do search$") public void do_search() throws Throwable { // Write code here that turns the phrase above into concrete actions } @Then("^Single result is shown for 'Cucumber'$") public void single_result_is_shown_for_Cucumber() throws Throwable { // Write code here that turns the phrase above into concrete actions } Tuy nhiên, công cụ tự động hiện tại không sinh được thân hàm do vậy cần đưa phương án để sinh thân các phương thức để tự động kiểm thử với kịch bản kiểm thử BDD đã có.2 Giải pháp Giải pháp luận văn đưa ra là nghiên cứu sinh các mã kiểm thử tự động từ kịch bản kiểm thử hướng hành vi.

Đồng thời sử dụng framework Cucumber kết hợp tích hợp các công cụ để kiểm thử tự động trong kiểm thử hướng hành vi dựa trên viết mã kịch bản kiểm thử bằng ngôn ngữ tự nhiên có cấu trúc. Từ việc 3 nghiên cứu quy trình xử lý ngôn ngữ tự nhiên dựa trên NLP ( Natural Language 4 Processing) luận văn cũng đưa ra và phân tích tự động hóa trong kiểm thử hướng hành vi. Với một từ điển các ca kiểm thử trên ngôn ngữ tự nhiên, từ dữ liệu đó có một hành vi tương ứng khi đọc đến ca kiểm thử hành vi đối với phần mềm đang xây dựng. Khi đó, mỗi lúc gọi đến kịch bản kiểm thử sẽ dẫn đến hành vi xử lý trong phần mềm tương ứng khác nhau.

Luận văn đề xuất phương án xây dựng một bộ dữ liệu bao gồm các ca kiểm thử dưới dạng ngôn ngữ tự nhiên và các ca kiểm thử tự động sinh tương ứng. Từ dữ liệu đó, áp dụng ứng dụng NLP và công cụ kiểm thử tự động hướng hành vi để khi gọi đến ca kiểm thử, các kịch bản tự động sinh ra các bước kiểm thử hướng hành vi tương ứng. Tuy nhiên khối lượng dữ liệu là lớn, do vậy trong luận văn chỉ đưa ra phương pháp và sử dụng công cụ tự động trong kiểm thử hướng hành vi để sinh phương thức là các hàm mà chưa tự động hoá được hoàn toàn sinh các thân hàm kiểm thử. Từ việc chạy công cụ kiểm thử tự động trong kiểm thử dựa trên kịch bản BDD ta có thể thấy được quy trình tự động, cũng như phương pháp phát triển, cải tiến công cụ kiểm thử tự động hiện có.3 Bố cục luận văn Phần còn lại của luận văn gồm các nội dung chính như sau: Chương 2 Đưa ra các kiến thức nền tảng về quy trình phần mềm, một số khái niệm về tự động hóa trong kiểm thử đồng thời cũng giới thiệu một số công cụ tự động trong kiểm thử tự động BDD, các ứng dụng có thể của xử lý ngôn ngữ tự nhiên trong kiểm thử phát triển phần mềm.

Chương 3 Giới thiệu khái quát, ưu, nhược điểm, cách hoạt động của một số công cụ kiểm thử tự động thường dùng trong kiểm thử hướng hành vi. Đồng thời đưa ra một số ví dụ kiểm thử với các công cụ đưa ra để rút ra kết luận và so sánh giữa các công cụ kiểm thử tự động trong kiểm thử hướng hành vi. Chương 4 Cài đặt và chạy thực nghiệm Framework kiểm thử tự động với BDD và đưa ra quy trình, viết cơ sở dữ liệu chạy cho công cụ. Dựa trên tìm hiểu các kiến thức và công cụ tự động trong kiểm thử, luận văn phân tích và đưa ra phương pháp sinh mã kiểm thử tự động dựa trên quy trình xử lý ngôn ngữ tự nhiên.

5 Tự động sinh mã kiểm thử cho phần mềm thực thi Yêu cầu của người dùng Thực thi kiểm thử dựa trên BDD phần mềm Hình 1-1 Tiến trình sinh mã kiểm thử tự động dựa trên kịch bản BDD Chương cuối cùng sẽ là các kết luận và hướng phát triển. 6 CHƯƠNG 2: MỘT SỐ KIẾN THỨC NỀN TẢNG 2. Phát triển phần mềm dựa trên phương pháp Agile Trong nhiều thế kỉ qua, có nhiều quy trình phần mềm được ứng dụng trong các doanh nghiệp, tổ chức làm phần mềm như quy trình thác nước, quy trình xoắn ốc một cách thành công. Tuy nhiên với nhiều yêu cầu phức tạp trong nhu cầu làm phần mềm ngày nay quy trình luôn được đổi mới và lặp đi lặp lại.

Agile [11] là phương pháp phát triển phần mềm theo hướng linh hoạt, chia quy trình là các pha nhỏ để phát triển phần mềm. Quy trình Agile có các đặc điểm sau: ● Các công việc trong tiến trình làm phần mềm được chia và kết hợp lại từ các giai đoạn làm phần mềm khác nhau. ● Phần mềm được triển khai dựa trên tài liệu hướng dẫn. ● Khách hàng được đàm phán thông qua hợp đồng.

● Phản hồi thay đổi theo kế hoạch một cách nhanh chóng, linh hoạt. Agile là sự kết hợp của sự đa dạng các quy trình làm phần mềm truyền thống khác nhau như: Scrum, RUP…Với tiến trình Agile phần mềm được phát triển một cách linh hoạt, tạo ra một sự kết hợp giữa các phương pháp phát triển một cách chặt chẽ. Quy trình Agile đã kết hợp nhiều phương thức phát triển tiên tiến như: Test Driven Development (TDD- phát triển phần mềm kiểm thử), Behavior Driven Development (BDD- Phát triển theo hướng hành vi),… ❏ Kiểm thử phần mềm trong quy trình Agile Quy trình Agile là mô hình phát triển linh hoạt, phát triển dựa trên quy trình lặp. Đặc điểm của quy trình này là: dự án được chia thành các mảng, module nhỏ để dễ sử dụng và nhanh chóng thay đổi khi yêu cầu khách hàng thay đổi, các phần nhỏ sẽ được kiểm thử ngay trong khi làm dự án mà không cần đợi đến khi kết thúc dự án.

Trong quy trình phát triển phần mềm theo tiến trình Agile sản phẩm được xây dựng tốt ngay từ đầu, sau đó nhận các phản hồi của khách hàng và cải tiến lại sao cho đúng yêu cầu. Kiểm thử phần mềm trong quy trình phát triển phần mềm Agile không phải là một giai đoạn của dự án nữa mà là một phần của dự án ngay từ đầu. Để đạt được chất lượng phần mềm tốt với bất kì quy trình phát triển phần mềm nào, 7 kiểm 8 thử luôn là một giai đoạn tốn kém và mất nhiều chi phí, nhân công. Đặc biệt là trong quy trình Agile với sự linh hoạt và chia nhỏ các module phát triển, nhân công cho kiểm thử càng gia tăng, chất lượng phần mềm càng khó kiểm soát và tốn nhiều kinh phí.

Chính vì vậy, kiểm thử được đánh giá là khá mất thời gian và công sức của cả nhóm phát triển phần mềm Tự động hóa kiểm thử là một việc làm giúp cải thiện chất lượng phần mềm mà không mất nhiều thời gian, qua mỗi lần thay đổi yêu cầu của người dùng dự án lại được xây dựng lại do đó kiểm thử cần chính xác và đảm bảo nhanh chóng kịp. Trong quy trình Agile, chu trình thực hiện các ca kiểm thử bị dồn lại khá nhiều thời gian dành cho kiểm thử hồi quy là khá ít, ứng dụng kiểm thử tự động trong quy trình Agile là một việc làm thiết yếu. Phát triển phần mềm hướng kiểm thử (TDD) Test - Driven development - TDD là phát triển phần mềm theo hướng kiểm thử. Người lập trình sẽ viết một đoạn một đoạn mã để kiểm thử mã thực thi của chương trình, sau đó viết mã chương trình.

Từ kết quả của mã kiểm thử để cải thiện, thay đổi lại code của chương trình. Trong quy trình phát triển phần mềm theo hướng kiểm thử từng phần, có nhiều quy trình sẽ được lặp đi lặp lại, các yêu cầu được xác định rõ hơn làm cho phần mềm đáp ứng được yêu cầu khách hàng một cách đầy đủ, rõ ràng hơn. Test Refactor code Hình 2-1. Quy trình TDD Trong quy trình TDD, phần mềm được phát triển theo hướng kiểm phát triển kiểm thử trước, sau đó từ kết quả kiểm thử người phát triển điều chỉnh lại mã nguồn sao cho đúng với yêu cầu nghiệp vụ của dự án.

Các ưu điểm của phát triển phần mềm hướng kiểm thử [12] là: 9 - Khả năng kiểm thử: khả năng kiểm thử của hệ thống được cải thiện thông qua hoạt động viết ca kiểm thử trước, khiến cho các lập trình viên khi lập trình sẽ phải nghĩ về việc làm sao để chương trình đáp ứng được đúng ca kiểm thử và yêu cầu đã thiết kế. Do vậy làm giảm tối thiểu việc kiểm thử cho hệ thống.