Luận Văn: Xây Dựng Ứng Dụng Kiểm Thử Phần Mềm Tự Động với Selenium & Webdriver

Tài liệu nghiên cứu 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, tổng hợp lý thuyết và thực hành, cung cấp kiến thức chuyên sâu về kỹ thuật.

• Tác giả: Phạm Thị Hải Yến
• Người hướng dẫn: PGS. Hoàng Xuân Huấn
• 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: Công Nghệ Thông Tin
• Đề 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

Mục lục chi tiết

• LỜI CAM ĐOAN
• LỜI CẢM ƠN
• MỤC LỤC
• DANH MỤC HÌNH VẼ
• DANH MỤC BẢNG BIỂU
• DANH MỤC CÁC KÝ HIỆU, CHỮ VIẾT TẮT VÀ CÁC THUẬT NGỮ
• MỞ ĐẦU
• 1. CHƯƠNG 1: GIỚI THIỆU VỀ KIỂM THỬ PHẦN MỀM
• 1.1. Giới thiệu về kiểm thử phần mềm
• 1.2. Phát triển hướng kiểm thử TDD (Test Driven Development)
• 1.3. Các lỗi thường gặp khi áp dụng TDD
• 1.4. Phát triển hướng hành vi BDD (Behaviour Driven Development)
• 1.5. Quy trình phát triển phần mềm truyền thống
• 1.6. Quy trình phát triển theo hướng BDD
• 2. CHƯƠNG 2: GIỚI THIỆU VỀ CÔNG CỤ KIỂM THỬ TỰ ĐỘNG VÀ MÔ HÌNH THIẾT KẾ PAGE OBJECT MODEL (POM)
• 2.1. Công cụ kiểm thử tự động Cucumber
• 2.2. Ngôn ngữ Gherkin
• 2.3. Cách chạy một Cucumber JUnit test
• 2.4. Sơ đồ chu trình làm việc xử lý các bước trong cucumber
• 2.5. Cấu trúc dự án cài đặt Cucumber
• 2.6. Các thư viện sử dụng để chạy Cucumber
• 2.7. Giới thiệu về Locator trong UT (Locators)
• 2.8. Xác định phần tử Web theo ID
• 2.9. Xác định phần tử Web theo Name
• 2.10. Xác định phần tử Web theo Link text
• 2.11. Xác định phần tử Web theo TagName
• 2.12. Xác định phần tử Web theo ClassName
• 2.13. Xác định phần tử Web theo CSS
• 2.14. Xác định phần tử Web theo Xpath
• 2.15. Các thư viện sử dụng để chạy Selenium WebDriver
• 2.16. Các hàm xử lý chung trong Selenium WebDriver
• 2.17. Giới thiệu mẫu thiết kế (Design pattern)
• 2.18. Phân loại mẫu thiết kế (Design Pattern)
• 2.19. Mô hình thiết kế Page Object Model (POM)
• 2.20. Lý do chọn mô hình thiết kế Page Object Model (POM)
• 2.21. Mô hình thiết kế Page Object Model (POM) là gì?
• 2.22. Ưu điểm của mô hình thiết kế Page Object Model (POM)
• 2.23. Ví dụ
• 3. CHƯƠNG 3: HỆ THỐNG TÍCH HỢP LIÊN TỤC
• 3.1. Hệ thống tích hợp liên tục (CI/CD)
• 3.2. Áp dụng hệ thống tích hợp liên tục
• 3.3. Lợi ích của việc tích hợp liên tục
• 3.4. Jenkins
• 4. CHƯƠNG 4: THỰC NGHIỆM KIỂM THỬ TỰ ĐỘNG TẠI CÔNG TY VIVAS VÀ ĐÁNH GIÁ KẾT QUẢ
• 4.1. Phân tích hoạt động kiểm thử tại công ty trước khi áp dụng kiểm thử tự động
• 4.2. Tổng quan về công ty, sản phẩm, môi trường kiểm thử
• 4.3. Quy trình kiểm thử trước đây tại VIVAS
• 4.4. Cài đặt và áp dụng kiểm thử tự động vào các dự án của VIVAS
• 4.5. Cấu trúc mã nguồn
• 4.6. Tích hợp Jenkins
• 4.7. Báo cáo kết quả chạy kiểm thử
• 4.8. Đánh giá kết quả sau khi áp dụng kiểm thử tự động vào dự án của VIVAS
• 4.9. Tiết kiệm thời gian
• 4.10. Tiết kiệm nguồn nhân lực
• 4.11. Những khó khăn khi triển khai hệ thống kiểm thử tự động trong công ty VIVAS
• 4.12. Hướng phát triển tiếp theo của framework
• TÀI LIỆU THAM KHẢO

Tóm tắt

I. Toàn cảnh về 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 hiện đại, kiểm thử phần mềm tự động đóng vai trò then chốt để đảm bảo chất lượng sản phẩm và tối ưu hóa quy trình. Theo một nghiên cứu của NIST, lỗi phần mềm gây thiệt hại kinh tế đáng kể, và một phần ba trong số đó có thể được ngăn chặn nếu kiểm thử được thực hiện tốt hơn. Hoạt động kiểm thử có thể chiếm tới 50% tổng chi phí phát triển, do đó, tự động hóa là một giải pháp tất yếu. Kiểm thử phần mềm tự động với Selenium & WebDriver nổi lên như một phương pháp hiệu quả, giúp giảm thiểu sức người, tăng độ tin cậy và rút ngắn thời gian đưa sản phẩm ra thị trường. Selenium là một bộ công cụ mã nguồn mở mạnh mẽ, chuyên dụng cho việc tự động hóa các ứng dụng web trên nhiều trình duyệt và nền tảng khác nhau. Các thành phần chính của nó bao gồm Selenium IDE, WebDriver, và Selenium Grid, mỗi thành phần phục vụ một mục đích riêng trong quy trình automation testing. 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" đã chỉ rõ, việc áp dụng hợp lý các công cụ này không chỉ giúp viết và chạy các test script một cách tự động mà còn cải thiện kỹ năng lập trình cho kiểm thử viên. Hơn nữa, việc kết hợp các phương pháp phát triển hiện đại như Phát triển hướng kiểm thử (TDD) và Phát triển hướng hành vi (BDD) với Selenium tạo ra một quy trình làm việc chặt chẽ, nơi các test case được định nghĩa rõ ràng từ yêu cầu nghiệp vụ, giúp sản phẩm cuối cùng bám sát mong đợi của người dùng và giảm thiểu lỗi phát sinh trong quá trình triển khai.

1.1. Khái niệm cốt lõi về Automation Testing và lợi ích

Automation Testing (Kiểm thử tự động) là quá trình sử dụng các công cụ và chương trình đặc biệt để thực thi các test case đã được viết sẵn, so sánh kết quả thực tế với kết quả mong đợi mà không cần hoặc cần rất ít sự can thiệp của con người. Mục tiêu chính là tự động hóa các tác vụ lặp đi lặp lại và tốn thời gian, đặc biệt là trong kiểm thử hồi quy (regression testing). Các ưu điểm chính của phương pháp này bao gồm: Tăng hiệu quả công việc bằng cách thay thế các bước thủ công nhàm chán; Tăng độ tin cậy do các test script thực thi nhất quán; Cải thiện chất lượng sản phẩm thông qua việc phát hiện lỗi sớm và nhanh chóng; Tốc độ xử lý vượt trội và giảm chi phí vận hành trong dài hạn. Tuy nhiên, chi phí ban đầu cho việc xây dựng framework và đào tạo nhân sự có thể cao hơn so với kiểm thử thủ công.

1.2. So sánh hai phương pháp TDD và BDD trong kiểm thử

Phát triển hướng kiểm thử (Test-Driven Development - TDD) và Phát triển hướng hành vi (Behavior-Driven Development - BDD) là hai phương pháp luận quan trọng trong quy trình phát triển phần mềm hiện đại. TDD tập trung vào việc viết các bài kiểm thử đơn vị (unit test) thất bại trước, sau đó mới viết mã nguồn tối thiểu để các bài kiểm thử đó thành công, và cuối cùng là tái cấu trúc mã nguồn. Quy trình này đảm bảo mã nguồn luôn được kiểm chứng. BDD, một nhánh của TDD, lại tập trung vào hành vi của hệ thống từ góc độ người dùng. Nó sử dụng ngôn ngữ tự nhiên (ví dụ Gherkin trong Cucumber) để mô tả các kịch bản, giúp các bên liên quan như BA, Tester và Developer có chung một cách hiểu về yêu cầu. Như luận văn đã đề cập, "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".

II. Vượt qua thách thức kiểm thử thủ công với Selenium

Kiểm thử thủ công, mặc dù vẫn cần thiết trong một số trường hợp, nhưng bộc lộ nhiều hạn chế khi đối mặt với các dự án phần mềm quy mô lớn và phức tạp. Quá trình này đòi hỏi nguồn nhân lực đáng kể, tốn nhiều thời gian và dễ xảy ra sai sót do yếu tố con người, đặc biệt khi phải lặp lại các test case cho mỗi lần thay đổi mã nguồn. Việc thực hiện kiểm thử hồi quy bằng tay trở thành một gánh nặng, làm chậm chu kỳ phát hành sản phẩm. Hơn nữa, việc kiểm thử trên nhiều môi trường khác nhau, hay còn gọi là kiểm thử đa trình duyệt, là một công việc cực kỳ tốn công sức nếu thực hiện thủ công. Kiểm thử phần mềm tự động với Selenium & WebDriver được sinh ra để giải quyết chính những thách thức này. Bằng cách tự động hóa các thao tác trên trình duyệt tự động, Selenium cho phép thực thi hàng trăm test case một cách nhanh chóng, chính xác và nhất quán. Luận văn đã chứng minh qua thực nghiệm tại công ty VIVAS rằng việc áp dụng tự động hóa giúp "tiết kiệm thời gian" và "tiết kiệm nguồn nhân lực" một cách rõ rệt. Các test script có thể được tái sử dụng, chạy song song trên nhiều trình duyệt, và tích hợp vào quy trình CI/CD để cung cấp phản hồi tức thì cho đội ngũ phát triển, từ đó nâng cao chất lượng sản phẩm một cách bền vững.

2.1. Phân tích các nhược điểm của quy trình thủ công

Quy trình kiểm thử thủ công tồn tại nhiều nhược điểm cố hữu. Thứ nhất, nó tiêu tốn rất nhiều thời gian và nhân lực, đặc biệt với các kịch bản kiểm thử phức tạp và các chu trình kiểm thử hồi quy. Thứ hai, rủi ro sai sót do con người là rất cao; sự mệt mỏi và nhàm chán khi lặp đi lặp lại một công việc có thể dẫn đến việc bỏ qua các lỗi quan trọng. Thứ ba, khả năng mở rộng bị hạn chế. Việc thực hiện kiểm thử đa trình duyệt và đa nền tảng đồng thời là gần như không thể với phương pháp thủ công. Cuối cùng, việc tạo báo cáo kiểm thử chi tiết và nhất quán cũng là một thách thức, gây khó khăn cho việc theo dõi và đánh giá chất lượng.

2.2. Lợi ích về chi phí và thời gian khi áp dụng Selenium

Áp dụng Selenium mang lại lợi ích kinh tế rõ rệt. Mặc dù có chi phí đầu tư ban đầu, lợi tức đầu tư (ROI) trong dài hạn là rất lớn. Luận văn chỉ ra, qua "Biểu đồ so sánh thời gian thực thi giữa kiểm thử thủ công và tự động", thời gian cho một kịch bản có thể giảm từ vài phút xuống còn vài giây. Điều này cho phép các chu kỳ kiểm thử diễn ra thường xuyên hơn, giúp phát hiện lỗi sớm hơn, từ đó giảm chi phí sửa lỗi. Về nhân lực, thay vì cần một đội ngũ lớn để thực hiện các bài kiểm thử lặp đi lặp lại, các kỹ sư có thể tập trung vào việc phát triển các test script phức tạp hơn và thực hiện kiểm thử thăm dò, nơi tư duy con người thực sự cần thiết. Khả năng tái sử dụng kịch bản giúp tiết kiệm công sức đáng kể trong suốt vòng đời dự án.

III. Hướng dẫn Kiểm thử tự động với Selenium WebDriver

Selenium WebDriver là thành phần cốt lõi và mạnh mẽ nhất trong bộ công cụ Selenium, được xem là trái tim của mọi test framework hiện đại. Nó cung cấp một tập hợp các API để tương tác với trình duyệt một cách tự động, mô phỏng chính xác các hành động của người dùng như nhấp chuột, nhập liệu, và điều hướng trang. Không giống Selenium IDE chỉ là một công cụ ghi và phát lại đơn giản, WebDriver cho phép viết các test script phức tạp và linh hoạt bằng nhiều ngôn ngữ lập trình phổ biến như Java, Python, C#. Để bắt đầu, cần thiết lập môi trường bằng cách cài đặt thư viện Selenium và các trình điều khiển trình duyệt tương ứng như ChromeDriver cho Google Chrome hay GeckoDriver cho Firefox. Một trong những kỹ năng cơ bản nhất khi làm việc với WebDriver là xác định các phần tử web (web element) trên trang. Công cụ này cung cấp nhiều chiến lược định vị (locator) khác nhau, từ các thuộc tính đơn giản như ID, Name, ClassName cho đến các phương thức mạnh mẽ hơn như CSS Selector và XPath. Việc lựa chọn đúng locator không chỉ đảm bảo kịch bản hoạt động ổn định mà còn ảnh hưởng đến tốc độ và hiệu suất thực thi. Ngoài ra, việc xử lý các tình huống động như chờ một phần tử xuất hiện (explicit wait) hay xử lý các cửa sổ cảnh báo (xử lý alert) là những kỹ năng nâng cao bắt buộc phải nắm vững để xây dựng các bài automation testing đáng tin cậy.

3.1. Thiết lập môi trường với WebDriver và ChromeDriver

Để bắt đầu, cần chuẩn bị môi trường phát triển. Quá trình này bao gồm: Cài đặt một ngôn ngữ lập trình được hỗ trợ (ví dụ: Java và JDK). Cài đặt một IDE (Môi trường phát triển tích hợp) như Eclipse hoặc IntelliJ. Sử dụng một công cụ quản lý dự án và build như Maven hoặc Gradle để quản lý các thư viện phụ thuộc. Thêm thư viện Selenium WebDriver vào dự án thông qua file cấu hình (pom.xml cho Maven). Bước quan trọng cuối cùng là tải xuống ChromeDriver (hoặc GeckoDriver cho Firefox) phiên bản tương thích với trình duyệt đã cài đặt trên máy. Driver này hoạt động như một cầu nối, nhận lệnh từ test script và thực thi chúng trên trình duyệt tự động.

3.2. Kỹ thuật định vị Web Element bằng XPath và CSS Selector

Định vị chính xác một web element là nền tảng của mọi kịch bản tự động. Selenium cung cấp nhiều loại locator. Trong khi ID và Name là nhanh và đơn giản nhất, chúng không phải lúc nào cũng tồn tại hoặc duy nhất. XPath và CSS Selector là hai chiến lược định vị mạnh mẽ và linh hoạt nhất. XPath sử dụng cú pháp biểu thức để điều hướng qua các phần tử trong cấu trúc DOM của trang, cho phép xác định các phần tử dựa trên mối quan hệ phức tạp. CSS Selector, mặt khác, sử dụng cú pháp của CSS để chọn các phần tử, thường có hiệu suất nhanh hơn XPath và được nhiều chuyên gia ưu tiên sử dụng khi có thể. Nắm vững cả hai kỹ thuật này là điều cần thiết để xử lý các ứng dụng web phức tạp.

3.3. Xử lý các tình huống động với Explicit Wait và Implicit Wait

Các ứng dụng web hiện đại thường có nội dung được tải động bằng AJAX. Điều này tạo ra thách thức về đồng bộ hóa: kịch bản có thể cố gắng tương tác với một phần tử trước khi nó xuất hiện trên trang, gây ra lỗi. Selenium cung cấp hai cơ chế chờ chính để giải quyết vấn đề này. Implicit Wait là một cài đặt toàn cục, yêu cầu WebDriver đợi một khoảng thời gian nhất định trước khi báo lỗi không tìm thấy phần tử. Explicit Wait linh hoạt hơn, cho phép chờ một điều kiện cụ thể xảy ra (ví dụ: phần tử có thể nhấp được, phần tử hiển thị) trước khi tiếp tục thực thi. Sử dụng explicit wait được coi là phương pháp tốt nhất vì nó giúp kịch bản ổn định và hiệu quả hơn, tránh việc phải dùng các lệnh chờ cứng (Thread.sleep) không đáng tin cậy.

IV. Bí quyết tối ưu Test Script bằng Page Object Model POM

Khi số lượng test case tăng lên, việc bảo trì mã nguồn kiểm thử trở nên phức tạp và tốn thời gian. Nếu giao diện người dùng thay đổi, các lập trình viên phải cập nhật lại locator ở nhiều nơi trong bộ mã nguồn, dẫn đến rủi ro và thiếu hiệu quả. Để giải quyết vấn đề này, cộng đồng kiểm thử đã phát triển một mẫu thiết kế phổ biến gọi là Page Object Model (POM). Đây là một phương pháp cấu trúc mã nguồn một cách thông minh, giúp tách biệt logic của test script khỏi các chi tiết về giao diện người dùng. Theo luận văn, POM là "một mẫu thiết kế để tạo kho lưu trữ đối tượng (Object Repository) cho các phần tử giao diện web". Trong mô hình này, mỗi trang của ứng dụng web tương ứng với một lớp (Class) trong mã nguồn. Lớp này chứa tất cả các web element của trang đó và các phương thức để tương tác với chúng. Các test case sẽ không trực tiếp gọi các lệnh WebDriver như findElement mà thay vào đó sẽ gọi các phương thức có ý nghĩa nghiệp vụ từ các lớp Page Object, ví dụ như loginPage.performLogin(user, pass). Cách tiếp cận này mang lại nhiều ưu điểm vượt trội: mã nguồn dễ đọc hơn, dễ bảo trì hơn và có khả năng tái sử dụng cao. Khi một phần tử trên giao diện thay đổi, chỉ cần cập nhật ở một nơi duy nhất là lớp Page Object tương ứng, tất cả các test case sử dụng nó sẽ tự động được cập nhật. Đây là nền tảng để xây dựng một test framework bền vững và có thể mở rộng.

4.1. Giới thiệu về mẫu thiết kế Page Object Model POM

Page Object Model (POM) không phải là một framework mà là một mẫu thiết kế (Design Pattern). Nguyên tắc cốt lõi của nó là sự phân tách trách nhiệm. Logic kiểm thử (ví dụ: các bước trong một test case) được giữ trong các lớp kiểm thử. Chi tiết về giao diện người dùng (ví dụ: các locator và các phương thức tương tác) được gói gọn trong các lớp Page Object. Mỗi lớp Page Object đại diện cho một trang hoặc một thành phần quan trọng trên giao diện. Điều này giúp mã nguồn trở nên có tổ chức, rõ ràng và tuân theo nguyên tắc DRY (Don't Repeat Yourself).

4.2. Ưu điểm vượt trội của POM trong việc bảo trì mã nguồn

Lợi ích lớn nhất của POM là khả năng bảo trì. Khi giao diện người dùng (UI) thay đổi, chỉ cần cập nhật lớp Page Object liên quan mà không cần động đến logic của các test case. Điều này giúp giảm đáng kể thời gian và công sức bảo trì. Hơn nữa, nó tăng cường khả năng tái sử dụng mã nguồn. Các phương thức trong Page Object (ví dụ: login(), searchForItem()) có thể được gọi từ nhiều kịch bản kiểm thử khác nhau. Mã nguồn cũng trở nên dễ đọc và dễ hiểu hơn đối với các thành viên mới, vì tên các phương thức mô tả rõ ràng hành động của người dùng thay vì các lệnh kỹ thuật của Selenium.

V. Tích hợp CI CD với Jenkins cho kiểm thử phần mềm tự động

Việc xây dựng một test framework mạnh mẽ với Selenium và POM là bước đầu tiên. Để phát huy tối đa hiệu quả của automation testing, cần phải tích hợp nó vào một quy trình phát triển liên tục. Đây là lúc hệ thống Tích hợp liên tục/Triển khai liên tục (CI/CD) phát huy vai trò. Jenkins là một trong những công cụ CI/CD mã nguồn mở phổ biến nhất, cho phép tự động hóa toàn bộ quy trình từ lúc lập trình viên đẩy mã nguồn lên kho chứa (như Git) cho đến việc build, kiểm thử và triển khai ứng dụng. Tích hợp bộ kiểm thử phần mềm tự động với Selenium & WebDriver vào Jenkins mang lại một vòng lặp phản hồi nhanh chóng. Mỗi khi có một thay đổi trong mã nguồn, Jenkins có thể tự động kích hoạt một job để build ứng dụng và sau đó chạy toàn bộ bộ kịch bản kiểm thử hồi quy. Kết quả sẽ được gửi lại ngay lập tức cho đội ngũ phát triển. Điều này giúp phát hiện lỗi ngay tại thời điểm chúng được tạo ra, khi chi phí sửa chữa còn thấp. Hơn nữa, Jenkins cung cấp khả năng tạo ra các báo cáo kiểm thử trực quan, theo dõi lịch sử các lần chạy và xu hướng chất lượng của dự án theo thời gian. Việc kết hợp Selenium với các công cụ như Selenium Grid còn cho phép Jenkins thực thi kiểm thử song song trên nhiều trình duyệt và hệ điều hành, giúp giảm đáng kể thời gian chạy toàn bộ bộ kiểm thử.

5.1. Khái niệm về Tích hợp liên tục CI và vai trò của Jenkins

Tích hợp liên tục (Continuous Integration - CI) là một thực hành phát triển phần mềm nơi các lập trình viên thường xuyên tích hợp mã nguồn của họ vào một kho chứa chung. Mỗi lần tích hợp sẽ được tự động xác minh bằng một quy trình build và kiểm thử tự động. 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". Jenkins là một máy chủ tự động hóa, đóng vai trò trung tâm trong quy trình CI, điều phối các tác vụ như lấy mã nguồn, biên dịch, chạy kiểm thử đơn vị và kiểm thử giao diện tự động.

5.2. Cách cấu hình Jenkins để tự động chạy các Test Script

Cấu hình một job Jenkins để chạy các test script Selenium thường bao gồm các bước sau: Cài đặt các plugin cần thiết (ví dụ: Git plugin, Maven Integration plugin). Tạo một job mới và cấu hình nguồn mã nguồn để trỏ đến kho lưu trữ Git. Thiết lập trình kích hoạt (trigger), ví dụ như chạy job mỗi khi có một commit mới vào nhánh chính. Trong phần Build, cấu hình lệnh để thực thi bộ kiểm thử (ví dụ: mvn clean test). Cuối cùng, cấu hình các hành động sau khi build (Post-build Actions) để xuất bản báo cáo kiểm thử (ví dụ: TestNG reports, Extent Reports) và gửi thông báo kết quả qua email hoặc các kênh liên lạc khác.

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

CHƯƠNG 1: GIOL THIEU VE KIEM THU PHAN MEM 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 phan ba chỉ 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 1a thường tin rằng, một kiếm khuyết nêu được tim ra sóm hơn thủ chỉ 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 phan 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 thị Ï 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ể cang cấp cho doanh: nghiệp một quan diễm, một cach nhin độc lập về phan mém dé tir dé cho phép danh gia và thầu Tiêu được T4 ing rdi ro trong quá trình triển khai phần mềm El Các mục tiêu chinh của kiếm thử phản mềm: v“_ '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. ¥ Dam bdo ring 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. kịch bản kiểm thử (Iestcasc) chất lượng cao, thực hiển kiểm thử hiệu qua dư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é phin mém bang một chương trình dặ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 Testscripl đượ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 ting dung 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à phan 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ố đự án, kiểm thử phân mẻm chiếm khoảng trên 50% tổng gia phát triển phần mẻm. 12o dó một trong các mục tiêu của kiểm thử là tự động hóa kiểm thứ, nhờ do ma giảm thiểu chủ 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àng và nhanh chóng hơn. Uu điểm của kiểm thử tự động.

Tinh 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ể cơn nguờ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 phi vé mit thai giarL b. BS tin ey: Dil lip di lip lai nhiéu lin van cho va kél. qua giéng nhau do vay dé én định cao, tránh được rủi ro có thê phat sinh. Céi thién chất lượng: Kiểm thử tự dộng làm giảm rui ro vé mat chat lugng sin phẩm, việc kiểm thử dượ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ý eve nhanh: Nếu mắt 5 phút để kiểm thử thủ công ủ chỉ cần muật 30s TIỂU.

dụng m lờ tự động, e. Chi phi thap: V rút ngắn thời gian và tiết kiệm rhhân lực giúp cho việc kiểm thử tự động trở nên hiệu quả điểm của kiểm thứ tự động. Ban đầu thì clú phú cho kiểm thử tự động sẽ cao hơn kiểm thữ thủ sông b. Để kiểm thử tự động tưực hiện được thì vẫn cần cơn người phải bộ thời gian, công, sức và tiến bạc, Mắt chỉ phí cho các công cụ tự động hóa như bản quyén, bao tri, tim hiéu, training.

mo Khó mở rộng hơn nhiều so với kiểm thử thủ công Yêu cầu những người có trinh độ chuyên môn cao mới thực hiện được mũ 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ử LDD (Tcst Driven Development} 1. Khải niệm Phát triển hưởng kiểm thứ LDI) (Test Driven 13evelopment) lả một phượng thức làm việc, hay một quy trình viết mã hiện dại. Lập trình viên sẽ thực hiện thông qua các tước nhỏ và tiễn độ dược dâm bão liên tục bằng cách viết và chay 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 ] kịch bản kiểm thử cho ham 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ổ uu hoa đoạn mất nguồn của li vừa viết sao cho đâm bảo kiểm thử vẫu ding và tỗi ru nhật cho việc lập trình kế tiếp d Lap lai cho các hàm khác từ bước 1.

Thực tế, nên sử đựng InitTestFramework cho TDD (nhu 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 râu sắc: © Bo: 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 dã viết trong màu đồ. Phát triển huéng kié thir ‘DD (Test-Driven Development) 1a kết hợp phương, pháp Phát triển kiểm thử trước (Test First Development) va phuong phap Điều chỉnh lại ma 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 'T12D là một kỹ thuật lập trình. Nhưng nhịn chung, muc tiêu của TDD là v ã nguồn sang sila, rố rằng và có | 1001212 WRITE A TEST TEST FAILS Test Driven Development 'WRITE CODE TO MAKE ST PASS (490) 22 CS150/23/ Hinh 1.

Chu trinh TDD qua màu sắc (từ trang Iminus1.com) Ba diéu luat khi ap dung TDD © Khéng cho phép viet bat ky 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 | | Create/add a new test.

Does the test fail? Hinh 1. Cac bude thire hign TDD Tie trang hitp://agiledata.org/essays/tdd. Các cấp dp TDD Mức chấp nhận (Acceptance TDD (ATDĐ)): 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 vị (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 DD) con duge goi la Behavior Driven Development (BDD).

Mức lập trình (Lập trình viên †): với mức này bạn cân viết một kiểm thứ lập trình đơn (single lap trinh vid 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 123. 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 dị thao tác tối ưu sau khi viết mã nguồn cho kịch bán kiểm thử dù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ử dơn giản nhất và không theo các bước nhỏ & Chỉchay mỗi kịch bản kiểm thử dang bi 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 13. Phát triển hướng hành vi BDD (Behaviour Driven Development) 1. Khải niệm Phat trién hướng hành vị Behayiour Driven Development (B12D) 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ụ để mình họa hành ví của hệ thông dược viết bằng ngôn ngữ để đọc và đễ 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ử, đột ngũ phát triển tham gia vào quả trình xây dựng rnã nguồn với vai trò phân tích và xây dung hệ thống kịch bản kiểm thử dưới góc độ ngôn ngít tự nhiên dễ hiểu từ các yêu cầu (requirement).

Dang thai, ho giúp đỡ lập hình viên trong việc giải thích và đưa m các phương án xây dựng mã nguồn mang tỉnh thực tiễn với người đảng ngay trước khi bắt tay xây đự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 đựng mã nguồn với những phương án. ma kiém thử viên cưng cấp theo mé hinh TDD. Write a failing feature test [Pass, Functionality developer tests, omen IPass, Functionality completo} m Development stops} iỊ 1 Acceptance TDD { Developer TDD Hình 1.

Chu trình làm việc kết hợp TDD và BDD (Tir trang http://agiledata.org/essays/tdd htm!) 18 1. Quy trình phat trién phần mềm truyền thống et AO oe._ ạco_— QO ` @ dạ $ A traditional development process Hình 1. Quy trình phát triển truyền thông (Tir trang http://agiledata org/essays/tdd html) (Tu 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 tich cac yéu cau (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à khí đến giai đoạn xây dumg (implementing phase) thi da 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 đạ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 nhin 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 ding. Quy trình phát triển theo luướng BDD. BA the developer and the tester elaborate the The developer requirements together A @ ; “ye fed, ( 6 Cốc ng 5 , J» lð ee eae ‘rT ‘The automated tester œ +~ Leon: The development process is applying BOD 19 Hinh 1.

Quy trình phát triển BDD (Tit trang http://agiledata.org/essays/tdd htm!