Luận văn ứng dụng Selenium trong kiểm thử phần mềm - ĐH Quốc gia HN

Luận văn thạc sĩ nghiên cứu ứng dụng Selenium trong kiểm thử tự động phần mềm. Trình bày BDD, Cucumber, Page Object Model, tích hợp TestLink và Jenkins.

• Tác giả: Dang Thi Phuong
• Trường học: Đại học Quốc gia Hà Nội - Viện Công nghệ Thông tin
• Chuyên ngành: Công nghệ thông tin
• Đề tài: Nghiên cứu ứng dụng Selenium kiểm thử tự động
• Loại tài liệu: Luận văn thạc sĩ
• Năm xuất bản: 2015
• Địa điểm: Hà Nội

Tóm tắt

I. Cách ứng dụng Selenium kiểm thử tự động hiệu quả trong phát triển phần mềm

Ứng dụng Selenium kiểm thử tự động đang trở thành tiêu chuẩn trong ngành phát triển phần mềm hiện đại. Selenium là một framework mã nguồn mở, miễn phí, hỗ trợ kiểm thử giao diện người dùng (UI) trên nhiều trình duyệt như Chrome, Firefox, Edge. Nhờ khả năng mô phỏng hành vi người dùng chính xác, Selenium giúp giảm thiểu lỗi thủ công, tăng tốc độ kiểm thử và đảm bảo chất lượng phần mềm. Theo nghiên cứu của Đại học Quốc gia Hà Nội (2015), việc tích hợp Selenium vào quy trình phát triển theo hướng Behavior-Driven Development (BDD) mang lại hiệu quả vượt trội, đặc biệt khi kết hợp với công cụ như Cucumber và mô hình Page Object Model (POM). Trong môi trường tích hợp liên tục (CI), Selenium cho phép chạy kiểm thử tự động sau mỗi lần commit mã nguồn, phát hiện sớm lỗi và giảm chi phí bảo trì. Các doanh nghiệp công nghệ hiện nay ưu tiên sử dụng Selenium vì tính linh hoạt, khả năng mở rộng và cộng đồng hỗ trợ mạnh mẽ. Tuy nhiên, để khai thác tối đa tiềm năng của Selenium, cần có chiến lược triển khai bài bản, bao gồm lựa chọn locator phù hợp, xây dựng framework kiểm thử bền vững và đào tạo đội ngũ kỹ sư kiểm thử chuyên sâu.

1.1. Selenium WebDriver là gì và vai trò cốt lõi trong kiểm thử tự động

Selenium WebDriver là thành phần trung tâm của hệ sinh thái Selenium, cho phép tương tác trực tiếp với trình duyệt qua giao diện lập trình ứng dụng (API). Khác với các công cụ kiểm thử cũ, WebDriver không dựa vào JavaScript injection mà điều khiển trình duyệt như một người dùng thực sự. Điều này giúp mô phỏng chính xác hành vi người dùng, từ click, nhập liệu đến điều hướng. Trong nghiên cứu năm 2015, WebDriver được xác định là thành phần không thể thiếu trong framework kiểm thử tự động, đặc biệt khi kết hợp với Cucumber để thực thi các kịch bản kiểm thử viết bằng ngôn ngữ Gherkin. WebDriver hỗ trợ nhiều ngôn ngữ lập trình như Java, Python, C#, giúp linh hoạt trong triển khai.

1.2. Các loại locator trong Selenium và cách lựa chọn tối ưu

Để thao tác với các phần tử web, Selenium cung cấp 7 loại locator: ID, Name, ClassName, TagName, LinkText, CSS Selector và XPath. Trong đó, ID và CSS Selector thường được ưu tiên vì tốc độ tìm kiếm nhanh và độ ổn định cao. XPath linh hoạt nhưng dễ gãy khi cấu trúc HTML thay đổi. Nghiên cứu chỉ ra rằng việc sử dụng CSS Selector kết hợp với mô hình Page Object giúp mã kiểm thử dễ bảo trì và ít phụ thuộc vào thay đổi giao diện. Việc lựa chọn locator phù hợp là yếu tố then chốt quyết định hiệu quả và độ bền của bộ kiểm thử tự động.

II. Thách thức khi triển khai Selenium kiểm thử tự động trong doanh nghiệp

Mặc dù Selenium kiểm thử tự động mang lại nhiều lợi ích, việc triển khai thực tế tại doanh nghiệp gặp không ít thách thức. Một trong những rào cản lớn nhất là thiếu kiến thức chuyên sâu về framework và kỹ năng lập trình của đội ngũ kiểm thử. Nhiều dự án thất bại do xây dựng script thiếu cấu trúc, dẫn đến mã nguồn rối, khó bảo trì. Ngoài ra, tính ổn định của test script cũng là vấn đề nan giải – các kịch bản thường thất bại do thời gian tải trang, popup bất ngờ hoặc thay đổi giao diện. Nghiên cứu của Đại học Quốc gia Hà Nội (2015) chỉ ra rằng hơn 60% dự án kiểm thử tự động ban đầu gặp khó khăn trong việc duy trì độ tin cậy của bộ test. Một thách thức khác là tích hợp với hệ thống CI/CD như Jenkins – đòi hỏi cấu hình phức tạp và quản lý báo cáo hiệu quả. Cuối cùng, việc thiếu quy trình rõ ràng để quản lý test case (ví dụ qua TestLink) khiến hiệu quả kiểm thử bị suy giảm đáng kể. Để vượt qua các rào cản này, cần có chiến lược tổng thể bao gồm đào tạo, chuẩn hóa framework và áp dụng mô hình thiết kế phù hợp.

2.1. Nguyên nhân khiến test script Selenium thất bại thường xuyên

Các test script Selenium thường thất bại do nhiều nguyên nhân: thiếu cơ chế chờ (wait) phù hợp, sử dụng XPath cứng, không xử lý popup hoặc iframe, và phụ thuộc vào dữ liệu động. Khi không áp dụng explicit wait, script có thể cố gắng tương tác với phần tử chưa tải xong, gây lỗi. Ngoài ra, việc không tách biệt logic kiểm thử khỏi chi tiết triển khai (vi phạm nguyên tắc Page Object Model) khiến script dễ gãy khi giao diện thay đổi. Nghiên cứu cho thấy các dự án áp dụng POM và cơ chế chờ thông minh giảm tới 70% tỷ lệ test thất bại ngẫu nhiên.

2.2. Khó khăn trong tích hợp Selenium với hệ thống CI CD

Việc tích hợp Selenium vào hệ thống tích hợp liên tục (CI) như Jenkins đòi hỏi cấu hình môi trường chạy test phù hợp, quản lý trình duyệt headless, và xử lý báo cáo sau mỗi lần chạy. Nhiều doanh nghiệp gặp khó trong việc chạy test song song trên nhiều máy hoặc xử lý lỗi khi test thất bại trong pipeline. Ngoài ra, việc thiếu báo cáo trực quan khiến việc phân tích nguyên nhân lỗi trở nên phức tạp. Giải pháp hiệu quả là sử dụng các thư viện như ExtentReports hoặc tích hợp với Serenity BDD để tạo báo cáo chi tiết, kèm hình ảnh và log lỗi.

III. Phương pháp xây dựng framework Selenium kiểm thử tự động bền vững

Xây dựng một framework Selenium kiểm thử tự động bền vững đòi hỏi tuân thủ các nguyên tắc thiết kế phần mềm hiện đại. Mô hình Page Object Model (POM) là nền tảng cốt lõi, giúp tách biệt logic giao diện khỏi kịch bản kiểm thử. Mỗi trang web được đại diện bởi một lớp riêng, chứa các phương thức thao tác với phần tử. Điều này giúp tái sử dụng mã, dễ bảo trì và giảm trùng lặp. Kết hợp POM với Behavior-Driven Development (BDD) thông qua Cucumber cho phép viết kịch bản kiểm thử bằng ngôn ngữ tự nhiên (Gherkin), giúp cả nhà phát triển, kiểm thử viên và khách hàng cùng hiểu rõ yêu cầu. Nghiên cứu năm 2015 đề xuất cấu trúc dự án gồm: thư mục features (chứa kịch bản Gherkin), step definitions (mã ánh xạ bước kiểm thử), và page objects (lớp đại diện trang). Ngoài ra, việc áp dụng mã hóa dữ liệu kiểm thử, sử dụng TestNG/JUnit để quản lý test suite, và tích hợp Jenkins để chạy tự động là những yếu tố then chốt đảm bảo framework hoạt động hiệu quả trong môi trường thực tế.

3.1. Ưu điểm và cách triển khai Page Object Model trong Selenium

Page Object Model (POM) là mô hình thiết kế giúp đóng gói các phần tử và hành động của một trang web vào một lớp riêng. Mỗi phần tử được định nghĩa một lần, và các phương thức thao tác (click, nhập liệu) được viết rõ ràng. Khi giao diện thay đổi, chỉ cần sửa một lớp thay vì toàn bộ script. Nghiên cứu chỉ ra rằng POM giúp giảm 40–60% thời gian bảo trì test script. Để triển khai hiệu quả, cần kết hợp với Factory Pattern hoặc Page Factory trong Selenium để khởi tạo phần tử một cách tối ưu.

3.2. Kết hợp Cucumber và Gherkin để viết kịch bản kiểm thử dễ hiểu

Cucumber cho phép viết kịch bản kiểm thử bằng ngôn ngữ Gherkin với cú pháp Given-When-Then. Ví dụ: 'Given người dùng ở trang đăng nhập, When nhập email và mật khẩu hợp lệ, Then hệ thống chuyển đến trang chủ'. Điều này giúp phi kỹ thuật như BA hoặc khách hàng có thể xác nhận tính đúng đắn của yêu cầu. Các bước này được ánh xạ sang mã Java/Python thông qua step definitions. Việc kết hợp này tạo ra tài liệu sống (living documentation), vừa là test case, vừa là đặc tả yêu cầu.

IV. Ứng dụng thực tiễn Selenium kiểm thử tự động tại doanh nghiệp Việt Nam

Tại nhiều doanh nghiệp công nghệ Việt Nam, Selenium kiểm thử tự động đã được áp dụng thành công trong các dự án web quy mô lớn. Một nghiên cứu điển hình từ luận văn thạc sĩ (2015) cho thấy việc triển khai framework Selenium + Cucumber + POM tại một công ty phần mềm giúp giảm 50% thời gian kiểm thử hồi quy và tăng độ phủ kiểm thử lên 85%. Hệ thống được tích hợp với TestLink để quản lý test case và Jenkins để chạy tự động sau mỗi commit. Báo cáo kết quả được xuất dưới dạng HTML và JSON, hỗ trợ phân tích nhanh. Đặc biệt, việc áp dụng kiểm thử theo kịch bản nghiệp vụ (business scenario) thay vì kiểm thử đơn vị giúp phát hiện lỗi liên quan đến luồng người dùng thực tế. Tuy nhiên, thành công chỉ đạt được khi có sự đầu tư ban đầu vào đào tạo, chuẩn hóa quy trình và xây dựng thư viện hỗ trợ dùng chung. Các doanh nghiệp cũng cần lưu ý đến việc duy trì bộ test – loại bỏ test lỗi thời, cập nhật test mới theo yêu cầu thay đổi.

4.1. Tích hợp Selenium với TestLink để quản lý test case hiệu quả

TestLink là hệ thống quản lý test case mã nguồn mở, hỗ trợ phân loại, gán phiên bản và theo dõi trạng thái test. Khi tích hợp với Selenium, mỗi test script có thể được liên kết với một test case trong TestLink thông qua ID. Sau khi chạy, kết quả (pass/fail) được đồng bộ ngược lên TestLink, giúp quản lý chất lượng phần mềm theo thời gian thực. Điều này đặc biệt hữu ích trong các dự án có yêu cầu tuân thủ quy trình kiểm thử nghiêm ngặt.

4.2. Đánh giá hiệu quả sau khi triển khai framework Selenium

Sau 6 tháng triển khai, doanh nghiệp trong nghiên cứu ghi nhận: thời gian kiểm thử hồi quy giảm từ 8 giờ xuống 2 giờ, số lỗi phát hiện sớm tăng 30%, và đội ngũ phát triển phản hồi nhanh hơn nhờ báo cáo tự động. Tuy nhiên, chi phí ban đầu cho xây dựng framework và đào tạo chiếm khoảng 20–30% tổng thời gian dự án. Dù vậy, ROI (lợi tức đầu tư) đạt dương sau 3–4 chu kỳ phát hành, chứng minh tính khả thi của Selenium kiểm thử tự động trong môi trường thực tế.

V. Tương lai của Selenium kiểm thử tự động và xu hướng phát triển

Tương lai của Selenium kiểm thử tự động gắn liền với sự phát triển của trí tuệ nhân tạo (AI) và học máy (ML) trong kiểm thử phần mềm. Các công cụ như Testim, Applitools đang tích hợp AI để tự động phát hiện thay đổi giao diện và điều chỉnh test script. Tuy nhiên, Selenium vẫn giữ vai trò nền tảng nhờ tính mở và khả năng tùy biến cao. Xu hướng tiếp theo là kiểm thử không code (codeless testing), nhưng các chuyên gia nhận định rằng Selenium sẽ tiếp tục là lựa chọn hàng đầu cho các dự án yêu cầu độ chính xác và kiểm soát cao. Ngoài ra, sự phát triển của Web Components, React, Angular đòi hỏi các kỹ thuật mới trong định vị phần tử và xử lý trạng thái bất đồng bộ. Việc kết hợp Selenium với Playwright hoặc Puppeteer cho các tình huống đặc thù cũng đang được nghiên cứu. Cuối cùng, kiểm thử trên thiết bị di động và trình duyệt headless sẽ ngày càng phổ biến, và Selenium đã hỗ trợ tốt qua Selenium Grid và Docker.

5.1. Selenium trong kỷ nguyên AI và kiểm thử thông minh

Mặc dù AI đang thay đổi cách tiếp cận kiểm thử, Selenium vẫn là công cụ cốt lõi để thực thi các hành động trên trình duyệt. Các framework AI thường sử dụng Selenium làm lớp điều khiển底层. Ví dụ, Applitools dùng Selenium để chụp ảnh màn hình, sau đó dùng AI so sánh sự khác biệt thị giác. Điều này mở ra hướng kiểm thử trực quan (visual testing), bổ sung cho kiểm thử chức năng truyền thống.

5.2. Hướng phát triển framework Selenium cho các ứng dụng hiện đại

Các ứng dụng web hiện đại (SPA – Single Page Application) sử dụng nhiều JavaScript bất đồng bộ, đòi hỏi kỹ thuật chờ thông minh và xử lý promise trong Selenium. Ngoài ra, việc container hóa framework bằng Docker giúp chạy test nhất quán trên mọi môi trường. Nghiên cứu khuyến nghị tích hợp Selenium Grid để chạy song song trên nhiều trình duyệt, kết hợp với Allure Reports để tạo báo cáo tương tác. Đây là xu hướng tất yếu cho các doanh nghiệp theo đuổi DevOps và Agile.

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

Chương 1: TÔNG QUAN VÉ BDD - CUCUMBER - SELENTUM - PAGE OBIECT3 1. Tổng quan về kiểm thử phần mềm.3 Ba điều luật khí áp» dung TDD. Các bước thực hiện trong, chủ trinh 'LDD. Quy trinh phat triénphần mễ truyền thống,.

Quy trình pÏ áL trién theo hưởng BDD 1. Ngôn ngữ Gherkin 1. Chay mét Cucumber Jurut. Sơ đồ workflow xứ cáo steps trang cucumber.

Câu tric dis an cai Cucumber 1.7, Các thư viên cân thiết dễ chạy CueumDor. Selenium WebDriver 1a gi 1. Téng quan vé déi trongUI (Locators). Xác định phần tứ Web theo Name.

Xác định phân tử Web theo LinkText - - 10 1. Xác định phân t Web theo TagName - 10 1. Xác định phân ti Web theo ClassNaine. Xác định phân tử Web thea CS§.

Xác định phân tử Web theo Xipath. Các thư viên cản thiết dễ chạy 3elcnrun WebDrivœr 12 1.4, Cae bam xử lý chung trong Selenium WebDriver. Page Object Model (POM). Tai suo phai ding POM.2, Page Object lá gi?.

Lợi ich của Page Object Chwong 2: HE THONG QUẢN LÝ TESTCASE— TESTLINK VÀ HỆ THONG TÍCH HỢP LIÊN TỤC 3. Hệ thống quan ly testcase - TestLink. Giới thiệu về TestLink 2. Lot ich cũa Testlark 2.

Các bude cai dat TestLinlk. Kết hợp TestLink va kiém thit tu ding. Hệ thống tích hợp liên tục (C1). SEA VÀ ĐÁNH GIÁ KÉT QUẢ.

Phân tích hoạt dộng kiểm thử tại công ty trước khí áp dụng, động. í và áp dụng kiểm thử tự động trong quá trình phát triể 3.1, Câu trúc dự án. Cầu trúc mã nguồn. Tich hop Jenkins 3.

Report kal qui chay lost 3. Damh gia ket qua. Những khé khan khi trién khai hé théng kiểm thử tự động trong công ty.5, Hướng phát triển tiến theo cửa framework. Ngôn ngữ Gherkin © Cucumber thie thi các feature file.

Các feature files chứa các đặc tả (step) thực thi, các step này được viết bằng ngôn ngữ Gherkin. © Gherkin 18 1 ng6n ngit ma Cucumber doc ngôn ngữ ấy chuyển thành test. Gherkin khá đễ hiểu, người đọc có thể hiểu kịch bản và hành động mà không cân biết chỉ tiết chúng được cai đất như thể nào Feature: [Title] (6 ta. cla feature |As a [Role] Vai tro của người đừng - II want [Some Action] ảnh động mả người ding mudn thee hién So that [Business Value] ighiép vy mong muon Scenario: [Title] lô tả mục đích của kịch bản kiểm thử - Given [Context] ién điều kiện đề thực hiện kịch bản kiêm.

And [Other Action] động đâu vào Then (I should see) [Outcomes] And [More Outcomes] ét qua mong muén 1. Chay mot Cucumber Junit test @AunWli th (CucumberwithSerenity.class) @CucumberOptions{ features={"src/test/resources/features/"}, g1ue=*org.scenariosteps", tags = { "GTest" }, feraat={*pretty",*junit: target/cucunber.xL" „"htmL:target* ,"json:target/cucumber.json"}) public class TestRunner {} 1.4 Chu trình Ma tadang lưới hànhplain~ vì ‘tone Việt tại các ctep Hình 1. Chương trình chạy test với Cucumber Mô tả lại hành vĩ đưới đang plain-text (sử dụng ngôn ngữ Gherhin) Đinh nghĩa céc step Chay test va xem test fail Viết code làm cho các step pass © Chey Jai tesl va xem rổ ững stop pass ©_ Lặp lại các bước đến khí toàn bộ các step pass 1. Sơ đỗ tworijTar xit hj ede steps trong cucumber (0 eects OY Read next Execute step ‘ster ( fem fC olin (| Scans ‘Stenane Hinh 1.

Workflow trong Cucumber 1. Cấu trúc tự ủn cài đặt Cucnmber Thang |. las oe, me. 111) Musiness [Booker ‘he hore pace [shan err ——.

tebọ lea [oán mộ mâyerte GTnh aia seca, rlPTE Sere panary thas The rrah nhang ] el em ee as be ye ae since wane AegaP sentig lg “Coms aera, Techuical Suppert Code, P ty oA Jetvoid labs oe cat theaa Trae £ ‘Waseca bre Sn Me nse Same In enerAM tot oso", lens: te, oat. Cau trie dye an cai dal Cucumber 1. Quy trink phát triển phẩn mêm truyền thống A traditional development process Hình 1. Quy trình phát triển truyền thông.

Quy trinh phat trién theo luring BDD The business analyst A BDD development process Hình 1. Quy trình phát triển BDD. Khái niệm © _ Cucumber là một công cụ kiểm thử tự động dựa trên việc thực thì các chức nãng được mô tả dướng đạng plain-text, mục đích là để hô trợ cho việc viết BDD. © Cucumber hé trg viet hành vi kiểm thử cho khoảng 60 ngôn ngữ khác nhau (Ngôn ngĩt Gherhin) © Các plain-text này có thể được đọc bởi mã nguồn được viết bằng nhiều ngôn ngữ như Java, Net, Python.

Khái niệm ®_ BDD là một quả trình phát triển phần mềm dựa trên kiểm thử hướng hành vi. BDD quy định rằng các đeveloper va product owner can hop tae va xác định hành vi của người sử đụng. BDD sinh ra hướng tới cắc feature test mà người thực hiện lả các Acceptance Tester. Write a failing feature test Refactor Hinh 1.

TDD két hgp vi BDD 1 ' Gombining Acceptance TOOT ' BOD and Developer TDD. 1 ' I 1 I [Pass,tionality Func Run the incomplete} developer tosts [Pass, Functionality, T complete] TPass, I Development stops}: 1 1 ' Acceptance TDD | Developer TOD Hinh 1. Work flow két hop TDD va BDD 1. Khái niệm ®_ BDD là một quả trình phát triển phần mềm dựa trên kiểm thử hướng hành vi.

BDD quy định rằng các đeveloper va product owner can hop tae va xác định hành vi của người sử đụng. BDD sinh ra hướng tới cắc feature test mà người thực hiện lả các Acceptance Tester. Write a failing feature test Refactor Hinh 1. TDD két hgp vi BDD 1 ' Gombining Acceptance TOOT ' BOD and Developer TDD.

1 ' I 1 I [Pass,tionality Func Run the incomplete} developer tosts [Pass, Functionality, T complete] TPass, I Development stops}: 1 1 ' Acceptance TDD | Developer TOD Hinh 1. Work flow két hop TDD va BDD 1. Các thu viện cẩn thiết đễ chạy Cucumber ®© _ Danh sách các thir vign Cucumber can cài đặt Cucumber - Java Ẩ Cucumber - Cucumber - Cucumber - Cucumber - TestNG Report Spring Hinh 1. Thu vién Cucumber can cai dat 1.

Selenium WebDriver Trong các phân trước, tôi đã trình bày khái niệm về TDD, BDD va viée sir dung Cucumber cho phat triển BDD. Công cụ Cucumber chỉ hỗ trợ cho kiểm thử viên và lập trình viên mô tả các hành vi của người đùng dưới dạng ngôn ngữ tự nhiên. Ngôn ngữ tự nhiên này giúp toàn thành viên trong đôi phát triển cũng như khách hàng có cái nhìn chung về hệ thông mà không cung cấp thư viên dé thao tác với các thành phân trên giao điện Web, Câu hỏi đặt ra là làm thể nào để có thể thao tác được với các thành. phan trên Web để tái hiện lại các hành vi của người đủng được mô tả bởi Cucumiber.

Selenium 'WebDriver sẽ lâm được điều đỏ. Đây là công cụ mã nguồn mớ, hoản toàn miễn phí và cung cấp đây đủ các thư viên thao tác trên ửng dụng Web. Framework kiểm thứ tự đông em xây đựng dưới đây cỏ thể thiếu Cucumber nhưng nhất định không thể thiểu Selenium WebDriver. Do đó, có thể nói Selenium WebDriver là thành phân cốt lõi chinh cita framework.1, Selenium WebDriver là gì © Selenium WebDriver là công cụ kiểm thử tự động các ứng đụng Web mm.

Tong quan về đối twgng UI (Locators) © Trong selenium, các phân tử trên web (WebElement) có vai trỏ rất quan trọng. Selenium hỗ trợ người đùng 7 cách để xac dinh cdc phan tir web nay (Locator) tay LegMarde(celemfTagNaemes) “-. » SID a} | = ly nenldelesilersrE | 1. Xác định phan Web theo ID 1.

Khái niệm ®_ BDD là một quả trình phát triển phần mềm dựa trên kiểm thử hướng hành vi. BDD quy định rằng các đeveloper va product owner can hop tae va xác định hành vi của người sử đụng. BDD sinh ra hướng tới cắc feature test mà người thực hiện lả các Acceptance Tester. Write a failing feature test Refactor Hinh 1.

TDD két hgp vi BDD 1 ' Gombining Acceptance TOOT ' BOD and Developer TDD. 1 ' I 1 I [Pass,tionality Func Run the incomplete} developer tosts [Pass, Functionality, T complete] TPass, I Development stops}: 1 1 ' Acceptance TDD | Developer TOD Hinh 1. Work flow két hop TDD va BDD 1. Ngôn ngữ Gherkin © Cucumber thie thi các feature file.

Các feature files chứa các đặc tả (step) thực thi, các step này được viết bằng ngôn ngữ Gherkin. © Gherkin 18 1 ng6n ngit ma Cucumber doc ngôn ngữ ấy chuyển thành test. Gherkin khá đễ hiểu, người đọc có thể hiểu kịch bản và hành động mà không cân biết chỉ tiết chúng được cai đất như thể nào Feature: [Title] (6 ta. cla feature |As a [Role] Vai tro của người đừng - II want [Some Action] ảnh động mả người ding mudn thee hién So that [Business Value] ighiép vy mong muon Scenario: [Title] lô tả mục đích của kịch bản kiểm thử - Given [Context] ién điều kiện đề thực hiện kịch bản kiêm.

And [Other Action] động đâu vào Then (I should see) [Outcomes] And [More Outcomes] ét qua mong muén 1. Chay mot Cucumber Junit test @AunWli th (CucumberwithSerenity.class) @CucumberOptions{ features={"src/test/resources/features/"}, g1ue=*org.scenariosteps", tags = { "GTest" }, feraat={*pretty",*junit: target/cucunber.xL" „"htmL:target* ,"json:target/cucumber.json"}) public class TestRunner {} 1.4 Chu trình Ma tadang lưới hànhplain~ vì ‘tone Việt tại các ctep Hình 1. Chương trình chạy test với Cucumber Mô tả lại hành vĩ đưới đang plain-text (sử dụng ngôn ngữ Gherhin) Đinh nghĩa céc step Chay test va xem test fail Viết code làm cho các step pass Chwong 1: TONG QUAN VE BDD- CUCUMBER- SELENIUM- PAGE OBJECT 1. Téng quan vé kiém thi phan mém © Kiém thir phan mém 1a mot giai đoạn trong quy trình phát triển phản mềm để đảm bảo độ tin cay và chất lượng của phần mêm.

© Cac mu tiêu chính của kiểm thử phẩn mém : 5 _ Phát hiện càng nhiêu lỗi càng tốt trong thời gian kiểm thử xác định trước. _ Chứng minh răng sản phẩm phần mem phủ hợp với các đặc tả yêu cầu của nó. ©_ Xác thực chất lượng kiểm thử phần mềm đã đủng chỉ phí và nỗ lực tôi thiểu. © Tao các kịch bản kiểm thử (testcase) chất lượng cao, thực hiện kiểm thử tạo ra các báo cáo van dé sing và hữu dụng.

TDD li gi? © Phat trién hudng kiém thit TDD (Test-Driven Development) 1a một phương pháp triển trong đỏ kết hợp phương pháp Phát triển kiếm thử trước (Test First Development) va phương pháp Điêu chỉnh lại mã nguén (Refactoring), Test Driven Development Hình 1. Chu trình TDD qua màu sắc (từ trang Lminus1. 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 khí nó làm một test bị fail trở nên pass. Không cho phép viết nhiêu hơn một mút test mà nêu chỉ cân 1 unit test cung đã đủ để fail.

Hãy chuyển sang viết code Rmction để pass test đó 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 test bi fail chuyển sang pass 1. Khái niệm ®_ BDD là một quả trình phát triển phần mềm dựa trên kiểm thử hướng hành vi. BDD quy định rằng các đeveloper va product owner can hop tae va xác định hành vi của người sử đụng.