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

C: PGS.TS. HOÀNG XUÂN HUẤN HÀ NỘI - 2020 1 LỜI CAM ĐOAN Tôi xin cam đoan kết quả đạt được trong luận văn là sản phẩm của cá nhân tôi, thực hiện dưới sự hướng dẫn của PGS. TS Hoàng Xuân Huấn. Trong toàn bộ nội dung của luận văn, những điều được trình bày hoặc là của cá nhân hoặc là được tổng hợp từ nhiều nguồn tài liệu. Tất cả các tài liệu tham khảo đều có xuất xứ rõ ràng và được trích dẫn đúng quy định. Tôi xin hoàn toàn chịu trách nhiệm và chịu mọi hình thức kỷ luật theo quy định cho lời cam đoan của mình. Hà Nội, ngày . tháng ... năm 2020 Học viên Phạm Thị Hải Yến 2 LỜI CẢM ƠN Để hoàn thành luận văn này tôi xin chân thành gửi lời cảm ơn đến PGS. TS. Hoàng Xuân Huấn cùng các thầy cô trong khoa Công nghệ thông tin – Đại học Quốc Gia Hà Nội đã đóng góp ý kiến, nhận xét, quan tâm chỉ bảo và tạo cho tôi những điều kiện tốt nhất từ khi bắt đầu cho tới khi hoàn thành luận văn của mình. Đồng thời, tôi cũng xin gửi lời cảm ơn đến gia đình, bạn bè và đồng nghiệp đã luôn quan tâm, chia sẻ, động viên và tạo mọi điều kiện để tôi có thể hoàn thành tốt mọi công việc trong quá trình thực hiện luận văn. Mặc dù đã rất cố gắng trong quá trình thực hiện nhưng luận văn không thể tránh khỏi những thiếu sót, tôi rất mong nhận được sự góp ý của các thầy cô và bạn bè. Học viên Phạm Thị Hải Yến 3 MỤC LỤC LỜI CAM ĐOAN .......................................................................................................... 1 LỜI CẢM ƠN ................................................................................................................ 2 MỤC LỤC ...................................................................................................................... 3 DANH MỤC HÌNH VẼ ................................................................................................. 6 DANH MỤC BẢNG BIỂU ........................................................................................... 8 DANH MỤC CÁC KÝ HIỆU, CHỮ VIẾT TẮT VÀ CÁC THUẬT NGỮ .............. 9 LỜI MỞ ĐẦU .............................................................................................................. 10 CHƯƠNG 1: GIỚI THIỆU VỀ KIỂM THỬ PHẦN MỀM .................................... 12 1.1. Giới thiệu về kiểm thử phần mềm ......................................................................... 12 1.2. Phát triển hướng kiểm thử TDD (Test Driven Development) ............................ 13 1.2.1. Khái niệm ..................................................................................................... 13 1.2.2. Các cấp độ TDD ........................................................................................... 16 1.2.3. Các lỗi thường gặp khi áp dụng TDD .......................................................... 16 1.3. Phát triển hướng hành vi BDD (Behaviour Driven Development) .................... 16 1.3.1. Khái niệm ..................................................................................................... 16 1.3.2. Quy trình phát triển phần mềm truyền thống ............................................... 18 1.3.3. Quy trình phát triển theo hướng BDD ......................................................... 18 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) ......................................................... 20 2.1. Công cụ kiểm thử tự động Cucumber .................................................................. 20 2.1.1. Khái niệm ..................................................................................................... 20 2.1.2. Ngôn ngữ Gherkin ........................................................................................ 20 2.1.3. Cách chạy một Cucumber Junit test ............................................................. 22 2.1.4. Chu trình ....................................................................................................... 23 2.1.5. Sơ đồ chu trình làm việc xử lý các bước trong cucumber ........................... 27 2.1.6. Cấu trúc dự án cài đặt Cucumber ................................................................. 28 2.1.7. Các thư viện sử dụng để chạy Cucumber..................................................... 28 2.2. Selenium WebDriver .............................................................................................. 29 2.2.1. Khái niệm ..................................................................................................... 29 2.2.2. Giới thiệu về đối tượng UI (Locators) ......................................................... 31 2.2.2.1. Xác định phần tử Web theo ID .......................................................... 31 2.2.2.2. Xác định phần tử Web theo Name ..................................................... 32 4 2.2.2.3. Xác định phần tử Web theo LinkText ................................................ 32 2.2.2.4.Xác định phần tử Web theo TagName ............................................... 33 2.2.2.5. Xác định phần tử Web theo ClassName ............................................ 33 2.2.2.6. Xác định phần tử Web theo CSS ....................................................... 34 2.2.2.7. Xác định phần tử Web theo Xpath .................................................... 34 2.2.3. Các thư viện sử dụng để chạy Selenium WebDriver ................................... 36 2.2.4. Các hàm xử lý chung trong Selenium WebDriver ....................................... 36 2.3. Giới thiệu mẫu thiết kế (Design pattern) .............................................................. 38 2.3.1. Khái niệm...................................................................................................... 38 2.3.2. Phân loại mẫu thiết kế (Design Pattern) ....................................................... 39 2.4. Mô hình thiết kế Page Object Model (POM) ....................................................... 41 2.4.1. Lý do chọn mô hình thiết kế Page Object Model (POM) ............................ 41 2.4.2. Mô hình thiết kế Page Object Model (POM) là gì? ..................................... 43 2.4.3. Ưu điểm của mô hình thiết kế Page Object Model (POM) .......................... 43 2.4.4. Ví dụ ............................................................................................................. 44 CHƯƠNG 3: HỆ THỐNG TÍCH HỢP LIÊN TỤC ................................................. 48 3.1. Hệ thống tích hợp liên tục (CI) .............................................................................. 48 3.1.1. Khái niệm ..................................................................................................... 48 3.1.2. Áp dụng hệ thống tích hợp liên tục .............................................................. 50 3.1.3. Lợi ích của việc tích hợp liên tục ................................................................. 50 3.1.4. Jenkins .......................................................................................................... 52 CHƯƠNG 4: THỰC NGHIỆM KIỂM THỬ TỰ ĐỘNG TẠI CÔNG TY VIVAS VÀ ĐÁNH GIÁ KẾT QUẢ ............................................................................................... 54 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 ................................................................................................................................. 54 4.1.1. Tổng quan về công ty, sản phẩm, môi trường kiểm thử .............................. 54 4.1.2. Quy trình kiểm thử trước đây tại VIVAS .................................................... 55 4.2. Cài đặt và áp dụng kiểm thử tự động vào các dự án của VIVAS ...................... 58 4.2.1. Cấu trúc dự án .............................................................................................. 58 4.2.2. Cấu trúc mã nguồn ....................................................................................... 60 4.2.3. Tích hợp Jenkins .......................................................................................... 64 4.2.4. Báo cáo kết quả chạy kiểm thử ..................................................................... 65 4.3. Đánh giá kết quả sau khi áp dụng kiểm thử tự động vào dự án của VIVAS .... 67 5 4.3.1. Tiết kiệm thời gian ........................................................................................ 68 4.3.2. Tiết kiệm nguồn nhân lực ............................................................................. 70 4.4. Những khó khăn khi triển khai hệ thống kiểm thử tự động trong công ty VIVAS 71 4.5. Hướng phát triển tiếp theo của framework ......................................................... 72 KẾT LUẬN .................................................................................................................. 73 TÀI LIỆU THAM KHẢO ........................................................................................... 74 6 DANH MỤC HÌNH VẼ Hình 1.1. Chu trình TDD qua màu sắc (từ trang 1minus1.com) .................................. 14 Hình 1.2. Các bước thực hiện TDD Từ trang .... 15 Hình 1.3. TDD kết hợp với BDD ................................................................................... 17 Hình 1.4. Chu trình làm việc kết hợp TDD và BDD ..................................................... 17 Hình 1.5. Quy trình phát triển truyền thống .................................................................. 18 Hình 1.6. Quy trình phát triển BDD .............................................................................. 19 Hình 2.1. Mã nguồn viết bằng ngôn ngữ Gherkin ......................................................... 21 Hình 2.2. Mã nguồn viết bằng ngôn ngữ Gherkin ......................................................... 21 Hình 2.3. Mã nguồn để chạy Cucumber ........................................................................ 22 Hình 2.4. Chương trình chạy kiểm thử với Cucumber .................................................. 23 Hình 2.5. Mã nguồn viết bằng ngôn ngữ Gherkin ......................................................... 24 Hình 2.6. Mã nguồn thực thi các bước trong kịch bản kiểm thử................................... 24 Hình 2.7. Kết quả chạy kịch bản kiểm thử và log khi có trường hợp sai ...................... 25 Hình 2.8. Mã nguồn thực thi các bước trong kịch bản kiểm thử................................... 25 Hình 2.9. Kết quả chạy các kịch bản kiểm thử đã đúng ................................................ 26 Hình 2.10. Chu trình làm việc trong Cucumber ............................................................ 27 Hình 2.11. Cấu trúc dự án cài đặt Cucumber ............................................................... 28 Hình 2.12. Thư viện Cucumber cần cài đặt ................................................................... 28 Hình 2.13. Sử dụng Maven để cài đặt các thư viện ....................................................... 29 Hình 2.14. Các hệ điều hành phổ biến .......................................................................... 30 Hình 2.15. 7 cách xác định phần tử Web ...................................................................... 31 Hình 2.16. Xác định phần tử Web bằng ID ................................................................... 32 Hình 2.17. Xác định phần tử Web bằng Name .............................................................. 32 Hình 2.18. Xác định phần tử Web bằng Linktext .......................................................... 33 Hình 2.19. Xác định phần tử Web bằng Tagname ........................................................ 33 Hình 2.20. Xác định phần tử Web bằng Classname ...................................................... 33 Hình 2.21. Xác định phần tử Web bằng CSS ................................................................. 34 Hình 2.22. Ví dụ minh họa cách xác định phần tử ........................................................ 34 Hình 2.23. Thư viện cần thiết để chạy Selenium WebDriver ........................................ 36 Hình 2.24. Sử dụng Maven để cài đặt các thư viện ....................................................... 36 Hình 2.25. Mã nguồn minh họa cho Selenium Webdriver ............................................ 38 Hình 2.26. Mã nguồn ví dụ cho việc chỉ sử dụng Selenium Webdriver ........................ 42 7 Hình 2.27. Cấu trúc POM ............................................................................................. 43 Hình 2.28. Cấu trúc Page Object Model ....................................................................... 44 Hình 2.29. Mã nguồn trang Đăng nhập ........................................................................ 45 Hình 2.30. Mã nguồn trong PageObjects và PageUIs của trang Đăng nhập .............. 46 Hình 2.31. Mã nguồn chạy nhiều trình duyệt ................................................................ 47 Hình 3.1. Vòng đời CI cơ bản ....................................................................................... 48 Hình 3.2. Quá trình tích hợp liên tục CI ....................................................................... 49 Hình 3.3. Hệ thống tích hợp liên tục ............................................................................. 49 Hình 3.4. 10 hệ thống CI sử dụng với GitHub .............................................................. 52 Hình 3.5. Giao diện Jenkins .......................................................................................... 53 Hình 4.1. Quy trình kiểm thử trước đây tại VIVAS ....................................................... 56 Hình 4.2. Cấu trúc dự án thực tế ................................................................................... 58 Hình 4.3. Quản lý mã nguồn bằng Github .................................................................... 59 Hình 4.4. Cấu trúc mã nguồn cài đặt thực tế ................................................................ 60 Hình 4.5. Cấu hình thông số cho Jenkins ...................................................................... 65 Hình 4.6. Báo cáo kết quả kiểm thử trên Jenkins .......................................................... 65 Hình 4.7. Biểu đồ kết quả kiểm thử trên Jenkins ........................................................... 65 Hình 4.8. Biểu đồ kết quả kiểm thử trên Jenkins ........................................................... 66 Hình 4.9. Báo cáo kết quả kiểm thử trên Extent reports ............................................... 66 Hình 4.10. Báo cáo kết quả kiểm thử trên TestNG report ............................................. 67 Hình 4.11. Biểu đồ thống kê tỷ lệ thực hiện được kiểm thử tự động ............................. 68 Hình 4.12. Biểu đồ so sánh thời gian thực thi giữa kiểm thử thủ công và tự động trên một trình duyệt ...................................................................................................................... 69 Hình 4.13. Biểu đồ so sánh thời gian thực thi giữa kiểm thử thủ công và tự động trên ba trình duyệt ...................................................................................................................... 70 Hình 4.14. Bảng so sánh nguồn lực thực hiện kiểm thử thủ công và tự động .............. 71 8 DANH MỤC BẢNG BIỂU Bảng 2.1. Bảng chú thích lệnh trong thư mục chạy Cucumber ..................................... 23 Bảng 2.2. Bảng so sánh Selenium WebDriver và các công cụ khác ............................. 30 Bảng 2.3. Bảng phân loại Xpath ................................................................................... 35 Bảng 2.4. Một số cú pháp trong Xpath .......................................................................... 35 Bảng 2.5. Xác định phần tử sử dụng Webdriver ........................................................... 37 Bảng 2.6. Các hàm hay sử dụng trong Selenium Webdriver ........................................ 37 Bảng 2.7. 5 mẫu thiết kế trong mẫu thiết kế kiến tạo .................................................... 39 Bảng 2.8. Những mẫu thiết kế thuộc nhóm mẫu thiết kế kiến trúc ................................ 39 Bảng 2.9. Những mẫu thiết kế thuộc nhóm mẫu thiết kế hành vi .................................. 40 Bảng 4.1. Bảng thống kê số kịch bản kiểm thử của một vài dịch vụ tại Vivas .............. 57 Bảng 4.2. Bảng thống kế số kịch bản kiểm thử đã áp dụng thực tế kiểm thử tự động .. 67 Bảng 4.3. Bảng thống kê thời gian thực thi của kiểm thử thủ công và tự động ............ 68 9 DANH MỤC CÁC KÝ HIỆU, CHỮ VIẾT TẮT VÀ CÁC THUẬT NGỮ STT Tiếng Anh Tiếng Việt Viết tắt 1 Automation Test Kiểm thử tự động AT 2 Business Analyst Nhân viên phân tích nghiệp vụ BA 3 Behavior Driven Development Phát triển hướng hành vi BDD 4 Continuous Integration Tích hợp liên tục CI 5 Developer Lập trình viên 6 Maintenance Bảo hành, bảo trì 7 Manual Test Kiểm thử thủ công 8 Page Object Model Mô hình Page Object POM 9 Refactor Tái cấu trúc 10 Regression Test Kiểm thử hồi quy 11 Software Testing Kiểm thử phần mềm 12 Test case Trường hợp kiểm thử 13 Test Driven Development Phát triển hướng kiểm thử TDD 14 Tester Kiểm thử viên 15 Test script Kịch bản kiểm thử 10 LỜI MỞ ĐẦU Trong nhiều năm qua, tự động hóa được ứng dụng ở rất nhiều lĩnh vực nhằm giảm thời gian, nhân lực và sai sót. Ngành công nghệ thông tin mà cụ thể là phát triển phần mềm cũng không ngoại lệ. Một sản phẩm công nghệ thông tin hay phần mềm có chất lượng không thể thiếu hoạt động kiểm thử phần mềm, trong khi đó hoạt động này lại tiêu tốn và chiếm tỷ trọng khá lớn công sức và thời gian trong một dự án. Do vậy, nhu cầu tự động hoá kiểm thử phần mềm cũng được đặt ra. Việc áp dụng kiểm thử tự động hợp lý sẽ mang lại thành công cho hoạt động kiểm thử phần mềm cũng như nâng cao chất lượng của sản phẩm phần mềm. Kiểm thử tự động giúp giảm bớt công sức thực hiện, tăng độ tin cậy và rèn luyện kỹ năng lập trình cho kiểm thử viên. Selenium là bộ kiểm thử tự động miễn phí (mã nguồn mở) dành cho các ứng dụng web trên các trình duyệt và nền tảng khác nhau. Với selenium cùng một số công cụ hỗ trợ khác như Cucumber, Jenkins, Maven, kiểm thử viên có thể phát triển thành các framework hỗ trợ cho viết các kịch bản kiểm thử và chạy các kịch bản này một cách tự động, giảm nguồn lực, tăng độ tin cậy và nhàm chán của công việc kiểm thử. Ngoài ra, hiện nay, nhu cầu kiểm thử tự động khá cao nhưng nhân lực trong ngành này không nhiều, đặc biệt là ở Hà Nội. Các công ty muốn áp dụng kiểm thử tự động trong quá trình phát triển dự án nhưng việc hiểu biết về kiểm thử tự động khá là mơ hồ và chưa xây dựng được một framework chuẩn áp dụng cho dự án tại công ty mình. Dựa vào những lý do trên cùng với những kinh nghiệm 4 năm tôi có được trong lĩnh vực kiểm thử. Tôi muốn xây dựng một framework kiểm thử tự động hỗ trợ các kiểm thử viên. Đó là lý do tôi chọn đề tài “Xây dựng ứng dụng kiểm thử phần mềm tự động sử dụng selenium và webdriver” Đề tài tìm hiểu cơ sở lý thuyết và kinh nghiệm thực tế về kiểm thử cũng như xây dựng ứng dụng kiểm thử phần mềm tự động để giảm nhân lực kiểm thử và đảm bảo chất lượng phần mềm hơn với công việc kiểm thử bằng tay. Mục tiêu chính của đề tài bao gồm:  Đưa ra những khái niệm cơ bản về quy trình phát triển hiện nay cũng như việc áp dụng kiểm thử tự động trong quy trình phát triển phần mềm (TDD, BDD)  Đưa ra những khái niệm cơ bản về các công cụ cần thiết như: Cucumber, Selenium, Jenkins  Đưa ra một framework nhỏ (kết hợp Cucumber và Selenium) và cách chạy các kịch bản kiểm thử này bằng Jenkins. Ngoài phần mở đầu, kết luận và phụ lục phần còn lại của luận văn được chia làm 4 chương, cụ thể như sau:  Chương 1 giới thiệu về kiểm thử phần mềm 11  Chương 2 giới thiệu về công cụ kiểm thử tự động và các loại mô hình thiết kế và phân tích lý do chọn cũng như ưu nhược điểm của mô hình Page Object Model (POM)  Chương 3 giới thiệu về hệ thống tích hợp liên tục và giới thiệu công cụ Jenkins được sử dụng trong dự án thí điểm.  Chương 4 giới thiệu về công ty VIVAS và đánh giá hiệu quả của kiểm thử tự động khi áp dụng vào dự án của công ty VIVAS. 12 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. 1.1. 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. b. Độ 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. 13 c. 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ử. d. 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. e. 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, ... 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. d. 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. 1.2. Phát triển hướng kiểm thử TDD (Test Driven Development) 1.2.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. b. 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. 14 Hình 1.1. 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.2. Các bước thực hiện TDD Từ trang 16 1.2.2. 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. 1.2.3. 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.3. Phát triển hướng hành vi BDD (Behaviour Driven Development) 1.3.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. 17 Hình 1.3. TDD kết hợp với BDD Hình 1.4. Chu trình làm việc kết hợp TDD và BDD (Từ trang 18 1.3.2. Quy trình phát triển phần mềm truyền thống Hình 1.5. Quy trình phát triển truyền thống (Từ trang (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. 1.3.3. Quy trình phát triển theo hướng BDD 19 Hình 1.6. Quy trình phát triển BDD (Từ trang (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.  Bảo đảm mã nguồn luôn phản ánh đúng và vừ