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

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

PHẠM THỊ HẢI YẾN

XÂY DỰNG ỨNG DỤNG KIỂM THỬ PHẦN MỀM TỰ ĐỘNG

SỬ DỤNG SELENIUM VÀ WEBDRIVER

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

HÀ NỘI - 2020

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

PHẠM THỊ HẢI YẾN

XÂY DỰNG ỨNG DỤNG KIỂM THỬ PHẦN MỀM TỰ ĐỘNG

SỬ DỤNG SELENIUM VÀ WEBDRIVER

Ngành: Khoa học máy tính

Chuyên ngành: Khoa học máy tính

Mã số: 08480101.01

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌ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.........................................................................1 2

1.2. Phát triển hướ ng ki ể m th ử TDD (Test Driven Development)............................1 3

1.2.1. Khái ni ệ m .....................................................................................................1 3

1.2.2. Các cấp độ TDD...........................................................................................1 6

1.2.3. Các lỗi thườ ng g ặp khi áp dụ ng TD D ..........................................................1 6

1.3. Phát triển hướng hành vi BDD (Behaviour Driven Development)....................1 6

1.3.1. Khái niệ m .....................................................................................................1 6

1.3.2. Quy trình phát triể n ph ầ n m ề m truy ề n th ố ng...............................................1 8

1.3.3. Quy trình phát triển theo hướ ng BDD .........................................................1 8

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 ..................................................................2 0

2.1.1. Khái niệ m .....................................................................................................2 0

2.1.2. Ngôn ngữ Gherkin........................................................................................2 0

2.1.3. Cách chạ y m ộ t Cucumber Junit test.............................................................2 2

2.1.4. Chu trình .......................................................................................................2 3

2.1.5. Sơ đồ chu trình làm việ c x ử lý các bướ c trong cucumber ...........................2 7

2.1.6. C ấu trúc dự án cài đặ t Cucumbe r .................................................................2 8

2.1.7. Các thư việ n s ử d ụng để ch ạ y Cucumber.....................................................2 8

2.2. Selenium WebDriver ..............................................................................................2 9

2.2.1. Khá i ni ệ m .....................................................................................................2 9

2.2.2. Gi ớ i thi ệ u v ề đối tượ ng UI (Locators) .........................................................3 1

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 LinkTex t ................................................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 WebDrive r ...................................3 6

2.2.4. Các hàm xử lý chung trong Selenium WebDrive r .......................................3 6

2.3. Gi ớ i thi ệ u m ẫ u thi ế t k ế (Design pattern)..............................................................3 8

2.3.1. Khái niệ m......................................................................................................3 8

2.3.2. Phân loạ i m ẫ u thi ế t k ế (Design Pattern ).......................................................3 9

2.4. Mô hình thiế t k ế Page Object Model (POM) .......................................................4 1

2.4.1. Lý do chọn mô hình thiế t k ế Page Object Model (POM )............................4 1

2.4.2. Mô hình thiế t k ế Page Object Model (POM) là gì ?.....................................4 3

2.4.3. Ưu điể m c ủa mô hình thiế t k ế Page Object Model (POM)..........................4 3

2.4.4. Ví dụ .............................................................................................................4 4

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)..............................................................................4 8

3.1.1. Khái niệ m .....................................................................................................4 8

3.1.2. Áp dụ ng h ệ th ống tích hợp liên tụ c ..............................................................5 0

3.1.3. L ợi ích củ a vi ệc tích hợp liên tụ c .................................................................5 0

3.1.4. Jenkins..........................................................................................................5 2

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.................................................................................................................................5 4

4.1.1. T ổ ng quan v ề công ty, sả n ph ẩm, môi trườ ng ki ể m th ử ..............................5 4

4.1.2. Quy trình kiể m th ử trước đây tạ i VIVAS ....................................................5 5

4.2. Cài đặt và áp dụ ng ki ể m th ử t ự động vào các dự án củ a VIVA S ......................5 8

4.2.1. C ấu trúc dự án ..............................................................................................5 8

4.2.2. C ấu trúc mã nguồ n .......................................................................................6 0

4.2.3. Tích hợ p Jenkins ..........................................................................................6 4

4.2.4. Báo cáo kế t qu ả ch ạ y ki ể m th ử .....................................................................6 5

4.3. Đánh giá kế t qu ả sau khi áp dụ ng ki ể m th ử t ự động vào dự án củ a VIVAS....6 7

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 http://agiledata.org/essays/tdd.html)....15

Hình 1.3. TDD kế t h ợ p v ớ i BD D ...................................................................................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 sa i ......................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 Nam e ..............................................................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 Mode l .......................................................................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 Jenkin s ......................................................................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 report s ...............................................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 ự độ n g .............................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 v i ..................................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ự độ n g ............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

Automation Test

Business Analyst

Behavior Driven

Development

Tiếng Việt

Kiểm thử tự động

Viết tắt

AT

1

2

3

Nhân viên phân tích nghiệp vụ

Phát triển hướng hành vi

BA

BDD

4

5

6

7

8

9

Continuous Integration

Developer

Tích hợp liên tục

Lập trình viên

CI

Maintenance

Bảo hành, bảo trì

Kiểm thử thủ công

Mô hình Page Object

Tái cấu trúc

Manual Test

Page Object Model

Refactor

POM

10 Regression Test

11 Software Testing

12 Test case

Kiểm thử hồi quy

Kiểm thử phần mềm

Trường hợp kiểm thử

Phát triển hướng kiểm thử

Kiểm thử viên

13 Test Driven Development

14 Tester

TDD

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 http://agiledata.org/essays/tdd.html )

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 http://agiledata.org/essays/tdd.html )

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 http://agiledata.org/essays/tdd.html )

(Từ trang BDD in action (Behavior-Driven Development for the whole software

lifecycle) - John Ferguson Smart (Foreword by Dan North))

Trong quy trình phát triển truyền thống, việc phân tích các yêu cầu (requirements)

thường được tiến hành bởi chuyên viên phân tích nghiệp vụ (BA) một cách chuyên hóa

và khi đến giai đoạn xây dựng (implementing phase) thì đa phần các lập trình viên tiếp

xúc với các yêu cầu phần mềm dưới dạng các bản thiết kế. Họ chỉ quan tâm đến đầu vào,

đầu ra (Input, Output) của tính năng mình xây dựng mà thiếu đi cái nhìn thực tiễn từ góc

nhìn người dùng (end-users). Một hệ quả tất yếu là lỗi phần mềm đến từ việc sản phẩm

ko tiện dụng với người dùng.

1.3.3. Quy trình phát triển theo hướng BDD