Sử dụng selenium để kiểm thử phần mềm quản lý thông tin tuyển dụng cho công ty 2NF software, hà nội

Kiểm thử là một giai đoạn không thể thiếu trong quá trình tạo ra một sản phẩm phần mềm hoàn thiện nó giúp cho sản phẩm hoạt động đúng như mong đợi, việc thực hiện kiểm thử đòi hỏi người

LỜI CẢM ƠN

Để hoàn thành bài đồ án tốt nghiệp này, lời đầu tiên em xin gửi lời biết ơn chân thành và sâu sắc nhất đến cô giáo TS.Trần Thị Ngân đã tận tình hướng dẫn, truyền đạt những kinh nghiệm quý giá cho em trong suốt quá trình nghiên cứu và thực hiện đề tài

Em xin gửi lời cảm ơn đến các thầy cô giáo trong khoa Công nghệ thông tin cùng toàn thể các thầy cô giáo đã truyền đạt vốn kiến thức quý báu cho chúng em trong suốt quá trình học tập vừa qua Em đã được quý thầy cô cung cấp và truyền đạt tất cả kiến thức chuyên môn cần thiết và quý giá nhất Ngoài ra em còn được rèn luyện một tinh thần học tập và làm việc độc lập và sáng tạo Đây là nền tảng hết sức cần thiết để có thể thành công khi bắt tay vào nghề nghiệp trong tương lai

Đồ án tốt nghiệp là cơ hội để em có thể áp dụng, tổng kết lại những kiến thức

mà mình đã học Đồng thời, rút ra được những kinh nghiệm thực tế và quý giá trong suốt quá trình thực hiện đề tài Sau một thời gian em tập trung công sức cho đề tài

và làm việc tích cực, đặc biệt là nhờ sự chỉ đạo và hướng dẫn tận tình của cô

TS.Trần Thị Ngân cùng với các thầy cô trong trường Đại học Công nghệ thông tin

& Truyền thông - Đại học Thái Nguyên, đã giúp cho em hoàn thành đề tài một cách thuận lợi và gặt hái được những kết quả mong muốn Bên cạnh những kết quả khiêm tốn mà em đạt được, chắc chắn không tránh khỏi những thiếu sót khi thực hiện báo cáo của mình, kính mong thầy cô thông cảm Sự phê bình, góp ý của quý thầy cô sẽ là những bài học kinh nghiệm rất quý báu cho công việc thực tế của em sau này

Em cũng xin chân thành cảm ơn Ban lãnh đạo nhà trường và toàn thể các thầy cô giáo trong nhà trường đã tạo mọi điều kiện thuận lợi, cung cấp cơ sở vật chất, trang thiết bị cần thiết cho quá trình học tập của chúng em

Kính chúc quý thầy cô mạnh khoẻ, tiếp tục đạt được nhiều thắng lợi trong nghiên cứu khoa học và sự nghiệp trồng người

Em xin chân thành cảm ơn!

LỜI CAM ĐOAN

Em xin cam đoan rằng:

Số liệu và kết quả nghiên cứu trong đồ án này là hoàn toàn trung thực và chưa từng được sử dụng hoặc công bố trong bất kỳ công trình nào khác

Mọi sự giúp đỡ cho việc thực hiện đồ án này đã được cám ơn và các thông tin trích dẫn trong đồ án đều được ghi rõ nguồn gốc

Sinh viên

MỤC LỤC

LỜI CẢM ƠN 1

LỜI CAM ĐOAN 2

MỤC LỤC 2

DANH MỤC HÌNH ẢNH 5

LỜI MỞ ĐẦU 6

CHƯƠNG 1: TÌM HIỂU CHUNG VỀ KIỂM THỬ PHẦN MỀM 7

1.1 Định nghĩa kiểm thử phần mềm 7

1.2 Mục tiêu của kiểm thử phần mềm 7

1.2.1 Mục tiêu trực tiếp 7

1.2.2 Mục tiêu gián tiếp 8

1.3 Các nguyên tắc cơ bản của kiểm thử phần mềm 8

1.4 Quy trình kiểm thử phần mềm 9

1.4.1 Lập kế hoạch kiểm thử 9

1.4.2 Phân tích và thiết kế trường hợp kiểm thử 11

1.4.3 Thực hiện kiểm thử 12

1.4.4 Báo cáo kết quả test 13

1.5 Các kỹ thuật kiểm thử 13

1.5.1 Kiểm thử hộp đen- Black box testing 13

1.5.2 Kiểm thử hộp trắng-White box testing 14

1.5.3 Kiểm thử hộp xám- Gray box testing 15

1.6 Các cấp độ kiểm thử phần mềm 15

1.6.1 Kiểm thử đơn vị - Unit Testing 16

1.6.2 Kiểm thử tích hợ -Integration Test 16

1.6.3 Kiểm thử hệ thống- System Test 17

1.6.4 Kiểm thử chấp nhận- Acceptance Test 19

CHƯƠNG 2: TỔNG QUAN VỀ KIỂM THỬ TỰ ĐỘNG VÀ CÔNG CỤ KIỂM THỬ SELENIUM 21

2.1 Kiểm thử tự động 21

2.1.1 Tổng quan về kiểm thử tự động 21

2.1.2 Các bước tiến hành kiểm thử phần mềm tự động 23

2.1.3 Quy trình kiểm thử tự động 24

2.1.4 Kiến trúc của một bộ công cụ kiểm thử tự động 24

2.1.5 Công cụ kiểm thử tự động Selenium 26

2.2 Selenium IDE 27

2.2.1 Cài đặt Selenium IDE 27

2.2.2 Các icon của Selenium IDE 28

2.2.3 Các thao tác với Selenium 30

2.3 Selenium Remote Control (Selenium RC) 34

2.3.1 Máy chủ RC 35

2.3.2 Thư viện máy khách 35

2.4 Selenium webdriver 36

2.4.1 Selenium WebDriver là gì 36

2.4.2 Các hàm xử lý chung trong Selenium WebDriver 43

CHƯƠNG 3 KHẢO SÁT VÀ XÂY DỰNG QUY TRÌNH TEST PHẦN MỀM 47

3.1 Khảo sát phần mềm 47

3.1.1.Mục đích 47

3.1.2 Quy ước văn bản 47

3.1.3 Giới hạn người sử dụng 47

3.1.4 Phạm vi dự án 48

3.1.5 Tham khảo 48

3.1.6 Yêu cầu cụ thể 49

3.2 Phạm vi test 52

3.3 Quy trình test phần mềm 52

CHƯƠNG 4: XÂY DỰNG TESTCASE VÀ THỰC HIỆN KIỂM THỬ PHẦN MỀM 55

4.1 Trang đăng nhập 55

4.2 Module quản lý người dùng 60

4.3 Kết quả sử dụng selenium kiểm thử chức năng trên phần mềm quản lý thông tin tuyển dụng cho công ty 2NF- Software 76

4.3.1 Chức năng đăng nhập 76

4.3.2 Chức năng thêm mới người dùng 77

KẾT LUẬN 78

TÀI LIỆU THAM KHẢO 79

DANH MỤC HÌNH ẢNH

Hình 1.1 Quy trình kiểm thử 9

Hình 1.2 Sơ đồ kế hoạch kiểm thử 10

Hình 1.3: Sơ đồ các cấp độ kiểm thử .15

Hình 2.1: Mô hình chung của một bộ kiểm thử tự động 24

Hình 2.2: Giao diện cài đặt selenium 28

Hình 2.3: Giao diện sử dụng selenium 28

Hình 2.4: Giao diện chính của selenium .33

Hình 2.5: Giao diện Selenium RC 34

Hình 2.6: Các hệ điều hành ứng dụng selenium Webdriver 36

Hình 2.7: So sánh giữa Selenium WebDriver và các công cụ kiểm thử tự động khác 37 Hình 2.8: Tổng quan về đối tượng UI (Locators) 38

Hình 2.9: Xác định phần tử Web theo ID 38

Hình 2.10: Xác định phần tử Web theo Name 39

Hình 2.11: Xác định phần tử Web theo LinkText 39

Hình 2.12: Xác định phần tử Web theo TagName 40

Hình 2.13:Xác định phần tử Web theo ClassName 40

Hình 2.14: Xác định phần tử Web theo CSS .41

Hình 2.15: Ví dụ cấu trúc HTML của một trang web 41

Hình 2.16: Kịch bản kiểm thử đơn giản cho phép người dùng login 44

Hình 2.17: Cấu trúc POM 45

Hình 3.1 : Biểu đồ Use Case 50

Hình 3.2 : Quy trình kiểm thử 52

Hình 4.1: Giao diện trang đăng nhập 55

Hình 4.2:Giao diện module quản lý người dùng 60

Hình 4.3 : Giao diện màn hình login khi đăng nhập sai mật khẩu 76

Hình 4.4 : Kết quả khi thực hiện test 76

Hình 4.5 : Giao diện khi đăng nhập thành công 76

Hình 4.6 : Kết quả khi thực hiện test 77

Hình 4.7 : Giao diện thêm mới người dùng không thành công 77

Hình 4.8 : Kết quả khi thực hiện test 77

LỜI MỞ ĐẦU

Trong giai đoạn hiện nay công nghệ thông tin phát triển nhanh như vũ bão, hàng năm có rất nhiều sản phẩm phầm mềm ra đời đáp ứng nhu cầu của người sử dụng trên toàn thế giới Yêu cầu các sản phẩm phầm mềm ra đời đáp ứng được yêu cầu của khách hàng như giao diện thân thiện, dễ sử dụng bên cạnh đó các chức năng phải hoạt động đúng theo yêu cầu từ đó việc kiểm tra các sản phẩm phầm mềm cũng là một phần quan trọng trong quy trình phát triển phần mềm

Kiểm thử là một giai đoạn không thể thiếu trong quá trình tạo ra một sản phẩm phần mềm hoàn thiện nó giúp cho sản phẩm hoạt động đúng như mong đợi, việc thực hiện kiểm thử đòi hỏi người kiểm thử phải có kiến thức cũng như cách nhìn khách quan với sản phẩm đồng thời cũng tiêu tốn khá nhiều thời gian và công sức do vậy để giảm bớt thời gian và tiền bạc cũng như sự nhàm chán khi kiểm thử thủ công thì việc kiểm thử bằng công cụ tự động làm cho công việc trở nên nhẹ nhàng, rút ngắn được thời gian thực hiện

Có rất nhiều công cụ thực hiện việc kiểm thử tự động, trong đợt làm đồ án này em lựa chọn đề tài: “Sử dụng selenium để kiểm thử phần mềm quản lý thông tin tuyển dụng cho công ty 2NF - Software, Hà Nội” để có một cái nhìn tổng quát về công cụ này cũng như quá trình kiểm thử động

Trong khuôn khổ thực hiện và khả năng có hạn dó đó có những phần em thực hiện chưa được tốt em mong sự chỉ bảo của các thầy cô để bài làm của em được hoàn thiện hơn

Kiểm thử phần mềm là quá trình thực thi một chương trình với mục đích tìm lỗi.(Theo “The Art of Software Testing” – Nghệ thuật kiểm thử phần mềm)

Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần mềm trong đúng môi trường chúng dự định sẽ được triển khai nhằm cung cấp cho người có lợi ích liên quan những thông tin về chất lượng của sản phẩm hay dịch

vụ phần mềm ấy Mục đích của kiểm thử phần mềm là tìm ra các lỗi hay khiếm khuyết phần mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềm trong nhiều ngành khác nhau (Theo Bách khoa toàn thư mở Wikipedia)

Có thể định nghĩa một cách dễ hiểu như sau:

Kiểm thử phần mềm là quá trình thực thi một hệ thống phần mềm để xác định xem phần mềm có đúng với đặc tả không và môi trường hoạt động có đúng yêu cầu không

1.2 Mục tiêu của kiểm thử phần mềm

1.2.1 Mục tiêu trực tiếp

Phát hiện và xác định càng nhiều lỗi càng tốt ở các phần mềm được kiểm thử Tiến hành sửa lỗi ở các phần mềm được kiểm thử và kiểm thử lại cho đến khi đạt một mức độ chất lượng phần mềm chấp nhận được

Thực thi những trường hợp kiểm thử một cách hiệu quả trong một giới hạn ngân sách và lịch trình cho phép

1.2.2 Mục tiêu gián tiếp

Để biên dịch một tài liệu về các lỗi phần mềm thường gặp nhằm mục đích ngăn ngừa và sửa chữa lỗi

1.3 Các nguyên tắc cơ bản của kiểm thử phần mềm

Có bảy nguyên tắc cơ bản cần chú ý khi kiểm thử phần mềm, các nguyên tắc

chứng minh được sản phẩm phần mềm được phát triển hoàn toàn chính xác

Không thể kiểm thử vét cạn: Việc kiểm thử không thể thực hiện được cho

tất mọi trường hợp kiểm thử Do vậy thay vì kiểm thử mọi khía cạnh, ta phải tập trung vào kiểm thử những yếu tố quan trọng và nhiều rủi do

Kiểm thử sớm: Các hoạt động kiểm thử nên bắt đầu càng sớm càng tốt trong

vòng đời phát triển phần mềm, và nên tập trung và những mục tiêu kiểm thử nhất định

Phân cụm lỗi:Một số lượng nhỏ các mô-đun phần mềm có thể chứa hầu hết

các lỗi được phát hiện ra trong suốt quá trình kiểm thử hoặc tập trung hầu hết các

lỗi vận hành

Kiểm thử ngược: Nếu một phương pháp kiểm thử được lặp đi lặp lại nhiều

lần, các trường hợp kiểm thử giống nhau sẽ không phát hiện được triệt để lỗi mới

Để khắc phục điều này ta có thể sử dụng nguyên tắc "kiểm thử ngược", các trường hợp kiểm thử cần phải được xem xét và duyệt lại một cách đều đặn, và việc kiểm thử mới cần phải được viết lại để thực thi những phần khác của phần mềm hay hệ

thống để tìm ra những lỗi tiềm ẩn

Kiểm thử phụ thuộc vào ngữ cảnh: Việc kiểm thử được thực hiện trong những hoàn cảnh khác nhau thì khác nhau

Sai lầm về việc không có lỗi: Tìm kiếm và sửa lỗi không thể giúp được gì

nếu hệ thống không dùng được hoặc không đáp ứng được yêu cầu và sự mong đợi

của khách hàng

1.4 Quy trình kiểm thử phần mềm

Hình 1.1 Quy trình kiểm thử

Quy trình kiểm thử phần mềm gồm các bước sau:

- Lập kế hoạch kiểm thử(Test plan)

- Thiết kế các trường hợp kiểm thử(Testcase)

- Thực hiện kiểm thử và ghi nhận kết quả

- Kiểm tra, phân tích, đánh giá kết quả

- Lập báo cáo kiểm thử

1.4.1 Lập kế hoạch kiểm thử

Mục đích: Nhằm chỉ định và mô tả mục tiêu, phạm vi, tài nguyên, ràng

buộc, môi trường, các mạo hiểm, các phương pháp kiểm tra triển khai và thực hiện Kết quả của bước lập kế hoạch là bản tài liệu kế hoạch kiểm thử phần mềm, bao gồm nhiều chi tiết từ các loại kiểm tra, chiến lược kiểm tra, cho đến thời gian và phân định lực lượng kiểm tra viên.Bản kế hoạch kiểm tra đầu tiên được phát triển rất sớm trong chu trình phát triển phần mềm, ngay từ khi các yêu cầu đã tương đối đầy đủ, các chức năng và luồng dữ liệu chính đã được mô tả Bản kế hoạch này có thể được coi là bản kế hoạch chính (master test plan), trong đó tất cả các kế hoạch chi tiết cho mức kiểm tra và loại kiểm tra khác nhau đều được đề cập

Hình 1.2 Sơ đồ kế hoạch kiểm thử

- Tùy theo các đặc trưng và độ phức tạp của mỗi dự án, các kế hoạch kiểm tra chi tiết có thể được gom chung vào bản kế hoạch chính hoặc được phát triển riêng Sau khi bản kế hoạch chính được phát triển, các bản kế hoạch chi tiết lần lượt được thiết kế theo trình tự thời gian phát triển của dự án Quá trình phát triển các kế hoạch chi tiết kiểm tra không dừng lại tại một thời điểm, mà liên tục được cập nhật chỉnh sửa sao cho phù hợp đến tận cuối dự án

- Các bước lập kế hoạch:

 Xác định yêu cầu kiểm tra: chỉ định bộ phận, thành phần của phần mềm sẽ được kiểm tra, phạm vi hoặc giới hạn của việc kiểm tra Yêu cầu kiểm tra cũng được dùng để xác định nhu cầu nhân lực

 Khảo sát rủi ro: các rủi ro có khả năng xảy ra làm chậm hoặc cản trở quá trình cũng như chất lượng kiểm tra Ví dụ: kỹ năng và kinh nghiệm của kiểm tra viên quá yếu, không hiểu rõ yêu cầu

 Xác định chiến lược kiểm tra: chỉ định phương pháp tiếp cận để thực hiện việc kiểm tra trên phần mềm, chỉ định các kỹ thuật và công cụ (tool) hỗ trợ kiểm tra, chỉ định các phương pháp dùng để đánh giá chất lượng kiểm tra cũng như điều kiện

để xác định thời gian kiểm tra

 Xác định nhân lực, vật lực: kỹ năng, kinh nghiệm của kiểm tra viên; phần cứng, phần mềm, công cụ, thiết bị giả lập cần thiết cho việc kiểm tra

 Lập kế hoạch chi tiết: ước lượng thời gian, khối lượng công việc, xác định chi tiết các phần công việc, người thực hiện, thời gian tất cả các điểm mốc của quá trình kiểm tra

 Tổng hợp và tạo các bản kế hoạch kiểm tra kế hoạch chung và kế hoạch chi tiết

 Xem xét các kế hoạch kiểm tra: phải có sự tham gia của tất cả nhưng người

có liên quan, kể cả trưởng dự án và có thế cả khách hàng Việc xem xét nhằm bảo đảm các kế hoạch khả thi, cũng như để phát hiện ( và sửa chữa sau đó) các sai sót trong các bản kế hoạch

1.4.2 Phân tích và thiết kế trường hợp kiểm thử

Một trường hợp kiểm thử (Test Case-TC) là một tình huống kiểm tra, được thiết kế kiểm tra một đối tượng có thỏa mãn yêu cầu đặt ra hay không Một TC thường bao gồm 4 phần cơ bản:

 Điều kiện: đặc tả các điều kiện cần có để tiến hành kiểm tra

 Đầu vào: đặc tả đối tượng hay dữ liệu cần thiết, được sử dụng làm đầu vào

để thực hiện việc kiểm tra

 Kết quả mong chờ: kết quả mong đợi trả về đối tượng kiểm tra

 Kết quả thực: kết quả thực tế trả về từ đối tượng kiểm tra

Mục đích: nhằm chỉ định các TC và các bước kiểm tra chi tiết cho mỗi phiên

bản phần mềm Giai đoạn thiết kế test là hết sức quan trọng, nó đảm bảo tất cả các tình huống kiểm tra “quét” hết tất cả yêu cầu cần kiểm tra

Việc thiết kế test không phải chỉ làm một lần, nó sẽ được sửa chữa, cập nhật, thêm hoặc bớt xuyên suốt chu kỳ phát triển phần mềm, vào bất cứ lúc nào có sự thay đổi yêu cầu, hoặc sau khi phân tích thấy cần được sửa chữa hoặc bổ sung

Các bước thiết kế test bao gồm:

 Xác định và mô tả test case(TC): xác định các điều kiện cần thiết lập trước và trong lúc kiểm tra Mô tả mục đích, yêu cầu kiểm tra, đối tượng hoặc dữ liệu đầu vào,

mô tả các kết quả mong chờ sau khi kiểm tra, môi trường kiểm tra

 Mô tả các bước chi tiết để kiểm tra: thao tác này nhằm chi tiết hóa các bước của một TC, cũng như chỉ định các loại dữ liệu nào cần có để thực thi các TC, chúng bao gồm các loại dữ liệu trực tiếp, gián tiếp, trung gian, hệ thống…

 Xem xét và khảo sát độ bao phủ của việc kiểm tra: mô tả các chỉ số và cách thức xác định việc kiểm tra đã hoàn thành hay chưa? Bao nhiêu phần trăm phần mềm đã được kiểm tra? Để xác định điều này có hai phương pháp: căn cứ trên yêu cầu của phần mềm hoặc căn cứ trên số lượng code đã viết

 Xem xét TC và các bước kiểm tra: Việc xem xét cần có sự tham gia của tất

cả những người có liên quan, kể cả trưởng dự án nhằm đảm bảo các TC và dữ liệu yêu cầu là đủ và phản ánh đúng các yêu cầu cần kiểm tra, độ bao phủ đạt yêu cầu, cũng như để phát hiện (và sửa chữa) các sai sót

 Kỹ thuật dựa trên kinh nghiệm: tạo kiểm thử chủ yếu nhờ vào sự hiểu biết

về hệ thống, kinh nghiệm quá khứ, phương pháp phỏng đoán về lỗi Có thể dược hướng dẫn bởi danh sách các ý kiểm tra, việc phân loại lỗi, liệt kê các kiểu tấn công, các tiếp cận “săn” lỗi, tập các lý do kiểm thử

1.4.3 Thực hiện kiểm thử

Testers sẽ được bố trí công việc bởi Test Leader để thi hành kiểm thử

 Thi hành kiểm thử theo từng test case

 Thực hiện kiểm thử đặc biệt

 Thực hiện kịch bản kiểm thử mà không được định nghĩa trong testcase

 Kiểm thử lại các lỗi đã được sửa

 Tester sẽ tạo ra các báo cáo về lỗi trong suốt quá trình kiểm lỗi và theo dõi chúng cho đến khi được xử lý

 Ở công đoạn kiểm thử độ chấp thuận, khách hàng sẽ thi hành kiểm thử để kiểm định xem hệ thống phần mềm có thỏa mãn các nhu cầu người dùng không?

1.4.4 Báo cáo kết quả test

Test Manager hoặc Test Leader sẽ phân tích các lỗi trong hệ thống theo dõi các lỗi

 Tạo các báo cáo lỗi

 Đánh giá các kết quả kiểm thử, thống kê các yêu cầu thay đổi

 Tính và phân phối các thông tin đo lường hoạt động kiểm thử

 Tạo bảng tổng kết đánh giá hoạt động kiểm lỗi

 Xác định xem đã đạt tiêu chí thành công và hoàn thành kiểm thử chưa

1.5 Các kỹ thuật kiểm thử

1.5.1 Kiểm thử hộp đen- Black box testing

Một trong những chiến lược kiểm thử quan trọng là kiểm thử hộp đen, hướng

dữ liệu hay hướng vào/ra Kiểm thử hộp đen Xem chương trình như là một “hộp đen”, nó chỉ quan tâm tới đầu vào và đầu ra của hệ thống mà không quan tâm gì đến cấu trúc bên trong của chương trình Thay vào đó, tập trung vào tìm các trường hợp

mà chương trình không thực hiện theo các đặc tả của nó

Theo hướng tiếp cận này, dữ liệu kiểm thử được lấy từ các đặc tả

Các phương pháp kiểm thử hộp đen

- Phân lớp tương đương – Equivalence partitioning

- Phân tích giá trị biên – Boundary value analysis

- Kiểm thử mọi cặp – All-pairs testing

- Kiểm thử fuzz – Fuzz testing

- Kiểm thử dựa trên mô hình – Model-based testing

- Kiểm thử dấu vết – Traceability matriX

- Ma trận dấu vết – EXploratory testing

- Kiểu thử dựa trên đặc tả - Specification-base testing.Kiểm thử dựa trên đặc

tả tập trung vào kiểm tra tính thiết thực của phần mềm theo những yêu cầu thích hợp Do đó, kiểm thử viên nhập dữ liệu vào, và chỉ thấy dữ liệu ra từ đối tượng kiểm thử Mức kiểm thử này thường yêu cầu các ca kiểm thử triệt để được cung cấp cho kiểm thử viên mà khi đó có thể Xác minh là đối với dữ liệu đầu vào đã cho, gán giá trị đầu ra (hay cách thức hoạt động) có giống với giá trị mong muốn đã được

Xác định trong ca kiểm thử đó hay không Kiểm thử dựa trên đặc tả là cần thiết, nhưng không đủ để ngăn chặn những rủi ro chắc chắn

Ưu nhược điểm của kiểm thử hộp đen

Kiểm thử hộp đen không có mối liên quan nào tới mã lệnh, và kiểm thử viên chỉ cần đơn giản tâm niệm là: một mà lệnh phải có lỗi Sử dụng nguyên tắc “Hãy đòi hỏi và bạn sẽ được nhận”, những kiểm thử viên hộp đen tìm ra lỗi mà những lập trinh viên đã không tìm ra Nhưng, mặt khác người ta cũng nói kiểm thử hộp đen

“giống như là đi trong bóng tối mà không có đèn vậy”, bởi vì kiểm thử viên không biết các phần mềm được kiểm tra thực sự được thực hiện Xây dựng như thế nào Đó

là lý do mà có nhiều trường hợp mà một kiểm thử viên hộp đen viết rất nhiều ca kiểm thử để kiểm tra một thứ gì đó mà đáng lẽ có thể chỉ cần kiểm tra bằng một ca kiểm thử duy nhât, và/ hoặc một số phần của chương trình không được kiểm tra chút nào

Vì thế, kiểm thực hộp đen có ưu điểm của “một sự đánh giá khách quan”, mặt khác nó lại có nhược điểm của “thăm dò mù”

1.5.2 Kiểm thử hộp trắng-White box testing

Là một chiến lược kiểm thử khác, trái ngược hoàn toàn với kiểm thử hộp đen, kiểm thử hộp trắng hay kiểm thử hướng logic cho phép ta khảo sát cấu trúc bên trong của chương trình Chiến lược này Xuất phát từ dữ liệu kiểm thử bằng sự kiểm thử tính logic của chương trình Kiểm thử viên sẽ truy cập vào cấu trúc dữ liệu và giải thuật bên trong chương trình (cả mã lệnh thực hiện chúng)

Các phương pháp kiểm thử hộp trắng

- Kiểm thử giao diện lập trình ứng dụng – API testing (Application programming interface): là phương pháp kiểm thử của ứng dụng sử dụng các API công khai và riêng tư

- Bao phủ mã lệnh – Code coverage: tạo các kiểm tra để đáp ứng một số tiêu chuẩn để bao phủ mã lệnh

- Các phương pháp gán lỗi – Fault injection

- Các phương pháp kiểm thử hoán chuyển – Mutation testing methods

- Kiểm thử tĩnh – Static testing: kiểm thử hộp trắng bao gồm mọi kiểm thử tĩnh

Phương pháp kiểm thử hộp trắng cũng có thể được sử dụng để đánh giá sự hoàn thành của một bộ kiểm thử mà được tạo cùng với các phương pháp kiểm thử hộp đen Điều này cho phép các nhóm phần mềm khảo sát các phần của hệ thống ít khi được kiểm tra và đảm bảo rằng những điểm chức năng quan trọng nhất đã được kiểm tra

1.5.3 Kiểm thử hộp xám- Gray box testing

Kiểm thử hộp Xám đòi hỏi phải có sự truy cập tới cấu trúc dữ liệu và giải thuật bên trong cho những mục đích thiết kế các ca kiểm thử, nhưng là kiểm thử ở mức người sử dụng hay mức hộp đen Việc thao tác tới dữ liệu đầu vào và định dạng dữ liệu đầu ra là không rõ ràng, giống như một chiếc “hộp Xám”, bởi vì đầu vào và đầu ra là không rõ ràng là ở bên ngoài “hộp đen” mà chúng ta vẫn gọi về hệ thống được kiểm tra Sự khác biệt này đặc biệt quan trọn khi quản lý kiểm thử tích hợp – Intergartion testing giữa 2 modun mã lệnh được viết bởi hai chuyên viên thiết

kế khác nhau, trong ffos chỉ giao diện là được đưa ra để kiểm thử Kiểm thử hộp Xám có thể cũng bao gồm cả thiết kế đối chiếu để quyết định, ví dụ, giá trị biên hay thông báo lỗi

1.6 Các cấp độ kiểm thử phần mềm

Hình 1.3: Sơ đồ các cấp độ kiểm thử

1.6.1 Kiểm thử đơn vị - Unit Testing

Kiểm thử đơn vị là hoạt động kiểm thử nhỏ nhất Kiểm thử thực hiện trên các hàm hay thành phần riêng lẻ Cần hiểu biết về thiết kế chương trình và code Thực hiện bởi Lập trình viên (không phải kiểm thử viên)

Đơn vị:

Là thành phần nhỏ nhất của phần mềm có thể kiểm thử được Ví dụ: Các hàm, lớp, thủ tục, phương thức Đơn vị thường có kích thước nhỏ, chức năng hoạt động đơn giản, không gây nhiều khó khăn trong việc kiểm thử, ghi nhận và phân tích kết quả do đó nếu phát hiện lỗi việc tìm kiếm nguyên nhân và sửa lỗi cũng đơn giản và tốn ít chi phí hơn

rõ dữ liệu đầu vào, các bước thực hiện và dữ liệu đầu ra mong muốn Các Test case

và Test script này nên được giữ lại để tái sử dụng

1.6.2 Kiểm thử tích hợ -Integration Test

Integration test kết hợp các thành phần của một ứng dụng và kiểm tra như một ứng dụng đã hoàn thành Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻ thì Intgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng

Integration Test có 2 mục tiêu chính:

- Phát hiện lỗi giao tiếp xảy ra giữa các Unit

- Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (subsystem) và cuối cùng

là nguyên hệ thống hoàn chỉnh (system) chuẩn bị cho kiểm tra ở mức hệ thống (System Test)

Trong Unit Test, lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng

và cấu trúc nội tại của Unit Có một số phép kiểm tra đơn giản trên giao tiếp giữa Unit với các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến Unit thật sự được kiểm tra đầy đủ khi các Unit tích hợp với nhau trong khi thực hiện Integration Test

Trừ một số ít ngoại lệ, Integration Test chỉ nên thực hiện trên những Unit đã được kiểm tra cẩn thận trước đó bằng Unit Test, và tất cả các lỗi mức Unit đã được sửa chữa Một số người hiểu sai rằng Unit một khi đã qua giai đoạn Unit Test với các giao tiếp giả lập thì không cần phải thực hiện Integration Test nữa Thực tế việc tích hợp giữa các Unit dẫn đến những tình huống hoàn toàn khác

Một chiến lược cần quan tâm trong Integration Test là nên tích hợp dần từng Unit Một Unit tại một thời điểm được tích hợp vào một nhóm các Unit khác đã tích hợp trước đó và đã hoàn tất (passed) các đợt Integration Test trước đó Lúc này, ta chỉ cần kiểm tra giao tiếp của Unit mới thêm vào với hệ thống các Unit đã tích hợp trước đó, điều này làm cho số lượng kiểm tra sẽ giảm đi rất nhiều, sai sót sẽ giảm đáng kể

Có 4 loại kiểm tra trong Integration Test:

- Kiểm tra cấu trúc (structure): Tương tự White Box Test (kiểm tra nhằm bảo đảm các thành phần bên trong của một chương trình chạy đúng), chú trọng đến hoạt động của các thành phần cấu trúc nội tại của chương trình chẳng hạn các lệnh và

nhánh bên trong

- Kiểm tra chức năng (functional): Tương tự Black Box Test (kiểm tra chỉ chú trọng đến chức năng của chương trình, không quan tâm đến cấu trúc bên trong), chỉ khảo sát chức năng của chương trình theo yêu cầu kỹ thuật

- Kiểm tra hiệu năng (performance): Kiểm tra việc vận hành của hệ thống

- Kiểm tra khả năng chịu tải (stress): Kiểm tra các giới hạn của hệ thống

1.6.3 Kiểm thử hệ thống- System Test

Mục đích System Test là kiểm tra thiết kế và toàn bộ hệ thống (sau khi tích

hợp) có thỏa mãn yêu cầu đặt ra hay không

System Test bắt đầu khi tất cả các bộ phận của PM đã được tích hợp thành công Thông thường loại kiểm tra này tốn rất nhiều công sức và thời gian Trong

nhiều trường hợp, việc kiểm tra đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc

hệ thống nhúng Ở mức độ hệ thống, người kiểm tra cũng tìm kiếm các lỗi, nhưng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lượng của toàn hệ thống

Điểm khác nhau then chốt giữa Integration Test và System Test là System Test chú trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Test chú trọng

sự giao tiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau Thông thường ta phải thực hiện Unit Test và Integration Test để bảo đảm mọi Unit và sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện System Test

Sau khi hoàn thành Integration Test, một hệ thống PM đã được hình thành cùng với các thành phần đã được kiểm tra đầy đủ Tại thời điểm này, lập trình viên hoặc kiểm tra viên (tester) bắt đầu kiểm tra PM như một hệ thống hoàn chỉnh Việc lập kế hoạch cho System Test nên bắt đầu từ giai đoạn hình thành và phân tích các yêu cầu Phần sau ta sẽ nói rõ hơn về một quy trình System Test cơ bản và điển hình

System Test kiểm tra cả các hành vi chức năng của phần mềm lẫn các yêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật Mức kiểm tra này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với PM hoặc phần cứng bên ngoài, chẳng hạn các lỗi “tắc nghẽn” (deadlock) hoặc chiếm dụng bộ nhớ Sau giai đoạn System Test, PM thường đã sẵn sàng cho khách hàng hoặc người dùng cuối cùng kiểm tra để chấp nhận (Acceptance Test) hoặc dùng thử (Alpha/Beta Test)

Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, System Test thường được thực hiện bởi một nhóm kiểm tra viên hoàn toàn độc lập với nhóm phát triển dự án

Bản thân System Test lại gồm nhiều loại kiểm tra khác nhau phổ biến nhất gồm:

- Kiểm tra chức năng (Functional Test): bảo đảm các hành vi của hệ thống

thỏa mãn đúng yêu cầu thiết kế

- Kiểm tra khả năng vận hành (Performance Test): bảo đảm tối ưu việc

phân bổ tài nguyên hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian xử

lý hay đáp ứng câu truy vấn…

- Kiểm tra khả năng chịu tải (Stress Test hay Load Test): bảo đảm hệ

thống vận hành đúng dưới áp lực cao (ví dụ nhiều người truy xuất cùng lúc) Stress Test tập trung vào các trạng thái tới hạn, các “điểm chết”, các tình huống bất thường…

- Kiểm tra cấu hình (Configuration Test)

 Kiểm tra khả năng bảo mật (Security Test): bảo đảm tính toàn vẹn, bảo

mật của dữ liệu và của hệ thống

 Kiểm tra khả năng phục hồi (Recovery Test): bảo đảm hệ thống có khả

năng khôi phục trạng thái ổn định trước đó trong tình huống mất tài nguyên hoặc dữ liệu; đặc biệt quan trọng đối với các hệ thống giao dịch như ngân hàng trực tuyến

Nhìn từ quan điểm người dùng, các kiểm tra trên rất quan trọng: bảo đảm hệ thống đủ khả năng làm việc trong môi trường thực

Lưu ý không nhất thiết phải thực hiện tất cả các loại kiểm tra nêu trên Tùy yêu cầu và đặc trưng của từng hệ thống, tuỳ khả năng và thời gian cho phép của dự

án, khi lập kế hoạch, trưởng dự án sẽ quyết định áp dụng những loại kiểm tra nào

1.6.4 Kiểm thử chấp nhận- Acceptance Test

Kiểm thử chấp nhận là một cấp độ trong tiến trình kiểm thử phần mềm nhằm kiểm thử hệ thống về khả năng chấp nhận được

Mục tiêu của kiểm thử này là để đánh giá sự tuân thủ của hệ thống với các yêu cầu nghiệp vụ và thẩm định xem đã có thể chấp nhận để bàn giao chưa

Kiểm thử chấp nhận nhằm mục đích để chứng minh phần mềm thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm Kiểm thử chấp nhận được khách hàng thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện)

Kiểm thử chấp nhận thông thường sẽ thông qua hai loại kiểm thử gọi là kiểm thử Alpha – Alpha Test và kiểm thử Beta – Beta Test Với Alpha Test, người dùng kiểm thử phần mềm ngay tại nơi phát triển phần mềm, lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi, và lên kế hoạch sửa chữa Với Beta Test, phần mềm sẽ được gửi tới cho người dùng để kiểm thử ngay trong môi trường thực, lỗi hoặc phản hồi cũng

sẽ gửi ngược lại cho lập trình viên để sửa chữa Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vào quá trình phát triển phần mềm thì kết quả Acceptance Test sẽ sai lệch rất lớn, mặc dù phần mềm đã trải qua tất cả các kiểm thử trước đó Sự sai lệch này liên quan đến việc hiểu sai yêu cầu cũng như sự mong chờ của khách hàng Ví dụ đôi khi một phần mềm xuất sắc vượt qua các phép kiểm thử sau cùng vẫn thất vọng vì bố cục màn hình nghèo nàn, thao tác không tự nhiên, không theo tập quán sử dụng của khách hàng v.v…

Gắn liền với giai đoạn Acceptance Test thường là một nhóm những dịch vụ

và tài liệu đi kèm, phổ biến như hướng dẫn cài đặt, sử dụng v.v… Tất cả tài liệu đi kèm phải được cập nhật và kiểm thử chặt chẽ

CHƯƠNG 2:

TỔNG QUAN VỀ KIỂM THỬ TỰ ĐỘNG VÀ CÔNG CỤ KIỂM THỬ SELENIUM 2.1 Kiểm thử tự động

2.1.1 Tổng quan về kiểm thử tự động

Kiểm thử tự động là: Quá trình thực hiện một cách tự động các bước trong

một kịch bản kiểm thử hay sử dụng một công cụ kiểm thử tự động để thực thi các tescase thay cho con người được gọi là kiểm thử tự động

Ưu và nhược điểm của kiểm thử tự động

Ưu điểm:

Độ tin cậy cao: Nhờ sự ổn định vượt trội của công cụ kiểm thử tự động so với con người, đặc biệt trong trường hợp có quá nhiều test case cần được thực thi, nên độ tin cậy của kiểm thử tự động thường cao hơn so với kiểm thử thủ công

Khả năng lặp: Hãy cùng xét ví dụ sau: Trong một ngày thời tiết xấu chúng ta phải thực thi một test case với 50 bộ dữ liệu đầu vào khác nhau nếu thực thi cách thủ công, ngồi trước màn hình nhập dữ liệu, click click, check check … Trong 50 lần có lẽ bạn sẽ gục ngã sớm trên bàn làm việc của mình.Nhưng nếu bạn thực thi bằng kiểm thử tự động chỉ cần nhập dữ liệu vào script chạy và ngồi rung đùi cho tới khi nhận được báo cáo Với độ ổn định cao, chúng ta có thể tin tưởng vào kết quả thực thi của công cụ kiểm thử tự động

Cải thiện chất lượng: Kiểm thử phần mềm tự động sẽ làm giảm rủi ro về 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

Khả năng tái sử dụng: Với một bộ kiểm thử tự động, chúng ta có thể sử dụng cho nhiều phiên bản khác nhau, đây được gọi là sử dụng lại

Nhanh: Đây là điều không thể phủ nhận khi thực hiện kiểm thử một cách tự động, nếu cần năm phút để thực hiện một test case thủ công thì có thể chưa đầy 30s nếu thực hiện tự động,trong vòng năm phút đó bạn có thể thực hiện được hàng chục test case

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 công việc kiểm thử tự động trở nên hiệu quả

Nhược điểm:

Khó mở rộng, khó bảo trì: Trong cùng một dự án, để mở rộng phạm vi cho kiểm thử tự động là khó khăn hơn nhiều so với kiểm thử thủ công Số lượng công việc cần làm để mở rộng phạm vi cho kiểm thử tự động là nhiều hơn và khó khăn hơn kiểm thử thủ công Cũng vậy để cập nhật một test case thủ công chúng ta chỉ cần mở ra và gõ, rất đơn giản Nhưng kiểm thử tự động lại không đơn giản như vậy, cập nhật hay chỉnh sửa yêu cầu rất nhiều công debug, thay đổi dữ liệu đầu vào, cập nhật code mới

Khả năng bao phủ thấp: Chính lý do khó ứng dụng, khó mở rộng cũng như đòi hỏi quá nhiều kỹ năng lập trình nên độ bao phủ của kiểm thử tự động khá thấp

Vấn đề công cụ và nhân lực: Cho đến nay công cụ hỗ trợ kiểm thử tự động

đã có những bước phát triển mạnh mẽ chúng ta có nhiều công cụ tiêu biểu như Qick test pro, Selenium, Test Complete…Nhưng nhìn chung vẫn còn nhiều hạn chế Ngoài ra nguồn nhân lực đạt yêu cầu không đủ

Hoàn thành các công việc mà con người không thể làm được: Nếu chúng ta muốn thực thi load test, performance test, thì kiểm thử tự động là cách duy nhất

Khi nào nên kiểm thử tự động

- Những trường hợp kiểm thử cần thực hiện nhiều lần, thường xuyên phải thực hiện regression test, một số lượng testcase lớn cần thực hiện trong một thời gian ngắn

- Kiểm thử cần thực hiện ở nhiều môi trường khác nhau

- Những project có tính ổn định, đặc điểm kỹ thuật được xác định trước, test màn hình chức năng không thay đổi trong tương lai

- Những trường hợp kiểm thử xác nhận hoạt động cơ bản ( di chuyển giữa các màn hình )

- Kiểm tra sự kết hợp của nhiều giá trị đầu vào ở một bước nào đó

- Kiểm tra nhiều màn hình của dữ liệu đầu vào

- Mục đầu vào ở nhiều màn hình đăng ký

- Khi muốn thực thi performance test hoặc load test, kiểm thử tự động gần như là lựa chọn duy nhất

2.1.2 Các bước tiến hành kiểm thử phần mềm tự động

Bước 1: Phân tích khả năng áp dụng kiểm thử tự động

Trước khi xác định phương pháp kiểm thử ta cần xem xét kỹ khi nào nên sử dụng phương pháp nào cho hợp lý nhất Chúng ta không thể tự động hóa mọi việc trong kiểm thử Có những công việc mà chỉ có thực hiện thủ công, có những việc có thể thực hiện tự động Chẳng hạn có những công nghệ mới hay phần mềm mới mà các công cụ kiểm thử tự động chưa thể kiểm thử hoàn toàn hay chỉ một phần Tóm lại trước khi tiến hành kiểm thử ta cần phân tích khả năng nào nên áp dụng kiểm thử

tự động khả năng nào không, không nên lạm dụng việc kiểm thử tự động vì như vậy

sẽ không mang lại hiệu quả tốt

Bước 2: Lựa chọn công cụ kiểm thử tự động thích hợp

Sau khi xác định được sản phẩm hiện tại có thể kiểm thử tự động hay không, bước tiếp theo là xác định nên sử dụng công cụ kiểm thử tự động nào Công cụ nào

hỗ trợ kiểm thử tự động cho sản phẩm sử dụng, ưu điểm của từng công cụ, ngôn ngữ kịch bản nào mà công cụ kiểm thử sử dụng, nhân sự hiện tại có quen thuộc với công cụ đó hay không? Việc lựa chọn bộ công cụ để thực hiện cũng vô cùng quan trọng nó góp phần vào sự thành công của các ca kiểm thử bởi mỗi bộ công cụ lại có một số điểm mạnh, điểm yếu riêng

Bước 3: Xây dựng môi trường làm việc

Môi trường làm việc bao gồm các khái niệm, chu trình, thủ tục và môi trường mà kịch bản kiểm thử tự động được thiết kế ra Lưu trữ các kịch bản kiểm thử cũng như các mối quan hệ logic giữa các thành phần

Bước 4: Viết kịch bản kiểm thử, thực thi và phân tích kết quả

Dựa trên các kịch bản kiểm thử đã được tạo ra bằng kiểm thử thủ công, dựa vào ngôn ngữ kịch bản mà công cụ kiểm thử tự động hỗ trợ, chúng ta viết các đoạn

mã tương tác với sản phẩm phần mềm trên các môi trường và thực thi nó Sau khi thực thi các đoạn mã, chúng ta cần phân tích các kết quả đạt được và ghi lại các vấn

đề của sản phẩm, nếu có

2.1.3 Quy trình kiểm thử tự động

Quy trình kiểm thử phần mềm tự động được thực hiện thông qua bốn bước Bước 1: Viết kịch bản kiểm thử, dùng công cụ kiểm thử để ghi lại các thao tác lên phần mềm cần kiểm tra và tự động sinh các kịch bản kiểm thử

Bước 2: Chỉnh sửa để kịch bản kiểm thử thực hiện theo đúng yêu cầu đặt ra làm theo trường hợp kiểm thử cần thực hiện

Bước 3: Chạy kịch bản kiểm thử, giám sát hoạt động kiểm tra phần mềm kịch bản kiểm thử

Bước 4: kiểm tra kết quả thông báo sau khi thực hiện kiểm thử tự động Sau

đó bổ sung, chỉnh sửa những sai sót

2.1.4 Kiến trúc của một bộ công cụ kiểm thử tự động

Trong thực tế, có rất nhiều bộ công cụ hỗ trợ kiểm thử tự động được phát triển nhằm giải quyết các vấn đề khó khăn của quy trình kiểm thử Dưới đây là mô hình chung nhất của một bộ kiểm thử tự động Trong kiến trúc này, các công cụ kiểm thử được tích hợp trong một quy trình thống nhất nhằm hỗ trợ đầy đủ các hoạt động kiểm thử trong quy trình kiểm thử các sản phẩm phần mềm

Hình 2.1: Mô hình chung của một bộ kiểm thử tự động

Quản lý kiểm thử: Công cụ này cho phép quản lý việc thực hiện/ thực thi

các ca kiểm thử Nó giám sát việc thực hiện các kiểm thử ứng với bộ giá trị đầu vào, giá trị đầu ra mong đợi và giá trị đầu ra thực tế Junit là một điển hình trong công cụ này

Sinh các ca kiểm thử: Đây là một trong những công cụ quan trọng nhất của

các bộ kiểm thử tự động Tùy thuộc vào các kỹ thuật kiểm thử được áp dụng, các công cụ này sẽ sinh ra tập các ca kiểm thử (chưa gồm các giá trị đầu ra mong muốn) cho chương trình/đơn vị chương trình cần kiểm thử Các ca kiểm thử được sinh ra chỉ chứa giá trị đầu vào để thực hiện nó Các giá trị này có thể được lựa chọn trong

cơ sở dữ liệu hoặc được sinh ngẫu nhiên

So sánh kết quả kiểm thử: Công cụ này so sánh giá trị đầu ra thực tế và giá

trị đầu ra mong muốn của mỗi ca kiểm thử khi nó được thực hiện chương trình/ đơn

vị chương trình cần kiểm thử

Tạo báo cáo kiểm thử: Một trong những ưu điểm của các bộ công cụ kiểm

thử tự động là nó có cơ chế sinh báo cáo kiểm thử một các chính xác và nhất quán Dựa vào kết quả báo của công cụ so sánh kết quả kiểm thử, công cụ này sẽ tự động sinh ra báo cáo kết quả kiểm thử theo định dạng mong muốn của đơn vị phát triển

Phân tích động: Công cụ này cung cấp một cơ chế nhằm kiểm tra việc thực

hiện của các câu lệnh của chương trình cần kiểm thử nhằm phát hiện các lỗi và các câu lệnh hay đoạn lệnh không được thực hiện bởi một tập các ca kiểm thử cho trước Công cụ này cũng rất hiệu quả trong việc đánh giá tính hiệu quả của một bộ kiểm thử cho trước

Bộ mô phỏng: Có nhiều loại hình mô phỏng được cung cấp trong các bộ

kiểm thử tự động Mục đích của các công cụ này là mô phỏng quá trình thực hiện của chương trình cần kiểm thử Ví dụ, các công cụ mô phỏng giao diện người dùng cho phép thực hiện tự động các tương tác giữa người sử dụng và sản phẩm Selenium là một ví dụ về một công cụ mô phỏng giao diện người dùng cho các ứng dụng Web

2.1.5 Công cụ kiểm thử tự động Selenium

a Selenium là gì?

Selenium (thường được viết tắt là SE) là một phần mềm mã nguồn mở, được phát triển bởi Jason Huggins, sau đó được tiếp tục phát triển bởi nhóm ThoughtWorks vào năm 2004

Selenium là một bộ các công cụ hỗ trợ kiểm thử tự động các tính năng của ứng dụng web, bao gồm 4 phần: Selenium IDE, Selenium Remote Control (RC), Selenium Core và Selenium Grid

Selenium hỗ trợ kiểm thử trên hầu hết các trình duyệt web phổ biến hiện nay như Firefox, Internet Explorer, Googlechrome và hỗ trợ trên rất nhiều ngôn ngữ lập trình phổ biến như C#, Java, Python, PHP Không những vậy Selenium còn có thể kết hợp với một số công cụ kiểm thử khác như Junit, Bromien, Nunit

b Các thành phần của Selenium

Selenium gồm 4 thành phần chính, mỗi thành phần đều đóng một vai trò cụ thể trong việc hỗ trợ kiểm thử các ứng dụng Web Các thành phần đó là:

Selenium IDE:Là môi trường phát triển tích hợp cho việc xây dựng trường

hợp kiểm thử Selenium Nó hoạt động như một add-on của Firefox và cung cấp một giao diện dễ sử dụng để phát triển và chạy trường hợp kiểm thử Selenium-IDE có tính năng thu lại kịch bản kiểm thử để tái sử dụng Nó cũng có một menu ngữ cảnh tích hợp với trình duyệt Firefox, cho phép người dùng chọn từ một danh sách xác minh (verify) và khẳng định (assert) cho các yếu tố giao diện đã chọn Selenium-IDE cũng cung cấp các chức năng chỉnh sửa các trường hợp kiểm thử chính xác và

dễ kiểm soát hơn Mặc dù Selenium-IDE chi là một Firefox add-on,nhưng các test case tạo ra bằng Selenium-IDE vẫn có thể chạy trên các trình duyệt khác bằng cách

sử dụng Selenium-RC

Selenium Core: Công cụ này đã được tích hợp trong Selenium IDE

Selenium Core là một công cụ chạy các test script viết bằng Selenese Thế mạnh của công cụ này là có thể chạy test script trên hầu hết các trình duyệt, nhưng lại yêu cầu được cài đặt trên máy chủ của ứng dụng web cần kiểm tra Điều này là không thể khi nhân viên kiểm thử không có quyền truy cập đến máy chủ

Selenium RC (Remote Control): Selenium-RC cho phép các nhà phát triển

tự động hóa kiểm thử sử dụng một ngôn ngữ lập trình cho tính linh hoạt tối đa và

mở rộng trong việc phát triển logic thử nghiệm Ví dụ, nếu trình ứng dụng trả về một tập kết quả của việc kiểm thử, và nếu chương trình thử nghiệm tự động cần chạy thử nghiệm trên mỗi phần tử trong tập hợp kết quả, hỗ trợ lặp đi lặp lại các ngôn ngữ lập trình có thể được sử dụng để chuyển đổi thông qua việc tập hợp kết quả, kêu gọi lệnh Selenium chạy thử nghiệm trên mỗi mục

Selenium-RC cung cấp một API(Application Programming Interface) và thư viện cho mỗi ngôn ngữ được hỗ trợ: HTML, Java, C #, Perl, PHP, Python, và Ruby Khả năng sử dụng Selenium-RC với một ngôn ngữ lập trình bậc cao để phát triển các trường hợp thử nghiệm cũng cho phép thử nghiệm tự động được tích hợp với một dự án xây dựng môi trường tự động

Selenium Gird: Thực hiện phương pháp kiểm tra phần bố, phối hợp nhiều

kiết quả của RC để có thể thực thi trên nhiều trình duyệt web khác nhau cùng một thời điểm Nó cũng cho phép lưu lại kết quả kiểm tra

2.2 Selenium IDE

Selenium IDE là một add-on của Mozilla Firefox phiên bản 2.0 trở lên, ban đầu được phát triển bởi Shinya Kasatani theo hướng sử dụng Selenium Core mà không cần cài đặt Selenium vào máy chủ ứng dụng.Nó được xây dựng sử dụng Javscript do vậy mà nó có thể tương tác với DOM, sử dụng được những cách gọi JavaScript Selenium cho phép ghi lại những hành động trong luồng công việc cần kiểm tra bằng các chức năng Record và Playback

Selenium IDE cũng chứa một menu ngữ cảnh cho phép lựa chọn yếu tố giao diện người dùng từ các trình duyệt đang hiển thị trang và sau đó chọn từ một danh sách các lệnh Selenium và các thông số được xác định theo ngữ cảnh của phần giao diện người dùng lựa chọn

2.2.1 Cài đặt Selenium IDE

Bước 1: Vào trang http://seleniumhq.org/download để download Selenium IDE Bước 2: Click vào link download cho Selenium IDE Bạn sẽ nhận được tin nhắn

" Firefox prevented this site(seleniumhq.org) from asking you to install software on

your computer" (Firefox đã chặn phần mềm từ trang web (seleniumhq.org), bạn có chắc chắn muốn cài đặt trên máy tính của bạn không) Nếu thực hiện, click nút Allow

Bước 3: Một pop up xuất hiện như hình:

Hình 2.2: Giao diện cài đặt selenium

Bước 4: Firefox thực hiện đếm ngược, nút Cài đặt chuyển sang trạng thái active, có thế click được Selenium sẽ bắt đầu được cài đặt trong máy tính giống như 1 add-on của firefox

Bước 5: Tiến trình cài đặt hoàn thành, hệ thống hỏi bạn có muốn khởi động lại firefox không Click vào nút Restart Firefox sẽ đóng và mở lại

Bước 6: Kiểm tra lại phần add-on của firefox xem đã có Selenium chưa

2.2.2 Các icon của Selenium IDE

Hình 2.3: Giao diện sử dụng selenium

Base URL: Đây là nơi điền URL của ứng dụng eb được tiến hành kiểm thử Thanh trượt: Đây là thanh trượt nằm dưới nhãn trên màn hình Dùng để điều chỉnh tốc độ nhanh/chậm khi chạy test case

Nút : Chạy tất cả các test case

Nút : Chỉ chạy test case được chọn

Nút : Tạm dừng một test case đang chạy

Nút : Bỏ qua một test case khi nó đã bị tạm dừng

Nút : Nút thu được sử dụng để thu các test case qua những thao tác bạn tác động đến trang web cần kiểm thử

Textbox Command: Dòng lệnh

Text box Target: Kết quả mong đợi của dòng lệnh

Text box Value: Giá trị đầu vào của dòng lệnh

Khu vực phía dưới textbox Value sẽ hiển thị các log của Selenium trong khi các test case chạy Nếu có một test case bị thất bại Selenium IDE sẽ log một lỗi

Log: Hiển thị thông báo lỗi và các bước được thực thi trong quá trình chạy một test case tự động Ngay cả khi ta không chọn tab log, các thông tin này vẫn hiển thị Các thông tin này giúp ích cho nhân viên kiểm thử cũng như nhân viên lập trình trong quá trình tìm ra nguyên nhân lỗi đã phát hiện trong test case (nếu có)

Reference: Thẻ tham chiếu

UI-Element và Rollup: Tính năng nâng cao của Selenium IDE

Lưu ý:

 Các test case luôn luôn có điểm bắt đầu Trong ngữ cảnh của Selenium, điều này có nghĩa là mở một trang nào đó để bắt đầu luồng công việc

 Các test case có thể không cần dựa trên những test case khác để chạy

 Một test case chỉ nên dùng để kiểm thử một chức năng nhỏ xác định trong một thời gian xác định

2.2.3 Các thao tác với Selenium

Tiến hành các thao tác cần thực hiện khi đó những việc thực hiện trên trang

sẽ được ghi lại

Lưu lại kịch bản vừa thực hiện bằng cách nhấn tổ hợp phím Ctrl + S hoặc nút Save/ Save trên thanh công cụ

Thêm các lệnh khẳng định và xác nhận với menu ngữ cảnh

Các trường hợp kiểm kiểm thử các thuộc tính của một trang web sẽ đòi hỏi các lệnh xác minh (verify) và khẳng định (assert) các yếu tố trên giao diện Phần dưới đây sẽ trình bày cách thêm các lệnh này vào test case của chúng ta

Khi thu một test case với Selenium IDE, vào trình duyệt hiển thị website ta muốn thực hiện kiểm thử, trỏ truột phải vào bất cứ vị trí nào trên trang, ta sẽ thấy các lệnh xác minh và khẳng định như hình dưới Để sử dụng các lệnh này ta chỉ việc chọn lệnh xác minh hoặc khẳng định mong muốn Các lệnh này sẽ tự động hiển thị trong test case Selenium sẽ dự đoán các lệnh, các thông số cần có trên giao diện để

bổ xung các lệnh xác minh Khi chọn thông báo Show All Avaiable Commands, sẽ

có nhiều lệnh xác minh được gợi ý hơn

Các thao tác chỉnh sửa

Chèn lệnh:

Chèn vào bảng: Trong ô test case, click chuột trái tại vị trí muốn chèn lệnh Chuột phải và chọn Insert command Selenium IDE sẽ thêm một dòng trắng phía trước dòng được chọn Nhập lệnh vào ô command, kết quả mong muốn vào ô target, giá trị đầu vào vào ô value

Chèn vào mã nguồn: Chọn vị trí trong test case mà bạn muốn chèn lệnh Trong ô test case, chuột trái vào vị trí muốn chèn lệnh Vào tag HTML, cần tạo 3 dòng chứa lệnh bao gồm tham số đầu tiên (nếu lệnh yêu cầu có tham số), tham số thứ hai (nếu có) Lưu test case trước khi chọn lại table view

Chèn comment:

Các comment có thể được thêm vào cho test case dễ hiểu hơn Những comment được bỏ qua khi chạy test case Comment có thể được sử dụng để thêm vào các khoảng trống dọc (một hoặc nhiều dòng trắng) vào các test case của chúng ta, khi chúng ta tạo ra các comment trắng Một lệnh trắng sẽ tạo ra 1 lỗi khi thực thi còn một comment trắng thì không tạo ra lỗi khi thực thi Chèn vào bảng: Chọn vị trí trong test case muốn comment Click chuột phải và chọn

Insert Comment Sử dụng trường Command để nhập comment

Chèn vào mã nguồn:Chọn vị trí trong test case muốn chèn comment Thêm một comment có dạng HTML Ví dụ: <! Enter your comment here >

Chỉnh sửa comment hay lệnh:

Chỉnh sửa qua giao diện:Chọn dòng cần chỉnh sửa và chỉnh sửa nó bằng các trường Command, Target, và Value

Chỉnh sửa qua mã nguồn:Vào mã nguồn, chỉnh sửa trực tiếp vào dòng comment hay lệnh muốn chỉnh sửa

Mở và lưu lại một test case

Chọn tập tin/ Open hoặc Save Tuy nhiên Selenium có sự khác biệt giữa các test case và test suite.Để lưu lại các bước kiểm thử trên Selenium-IDE sau khi sử dụng, bạn có thể lưu lại một test case riêng lẻ, hay lưu nhiều test case dưới dạng một test suite Nếu các test case của test suite không được lưu Chương trình sẽ nhắc nhở ta lưu chúng trước khi lưu một test suite Khi mở một test case hoặc một test suite đã có, Selenium-IDE hiển thị các câu lệnh trong ô test case

Chạy các test case

Selenium IDE có nhiều lựa chọn để chạy test case Bạn có thể chạy một test case, dừng và chạy tiếp, chạy một dòng lệnh riêng lẻ, hay chạy một test suite

Chạy một test case: Chọn một test case sau đó click vào nút Run để chạy một test case

 Stop and Start: Nút Pause được dùng để tạm dừng một test case khi nó đang chạy Để tiếp tục chạy test case bị tạm dừng, click nút Resume

 Tạm dừng ở giữa: Bạn có thể chọn một điểm ở giữa test case để tạm dừng nó tại một câu lệnh đặc biệt Điều này có ích trong việc gỡ lỗi trong test case Để chọn một điểm dừng cho test case, chọn câu lệnh, chuột phải, chọn Set/Clear Start Point

 Bắt đầu từ giữa: Chúng ta cũng có thể bắt đầu chạy một test case từ một điểm xác định ở giữa test case, thao tác này cũng được sử dụng trong gỡ lỗi Để gán điểm bắt đầu, ta chọn câu lệnh làm điểm bắt đầu, chuột phải, chọn Set/Clear Start Point

 Chạy một câu lệnh đơn lẻ bất kỳ: Double-Click câu lệnh muốn chạy Việc này có ích khi viết một câu lệnh đơn lẻ

Một lệnh mô tả một thao tác phải làm Lệnh Selenium bao gồm ba yếu tố: Actions, accessors, assertion

Action: là các thao tác chung trên ứng dụng, ví dụ: “Click this link”, “Select

that option”

Nếu như thao tác thất bại sẽ có 1 lỗi, việc thực thi kiểm thử sẽ bị tạm dừng Một hành động sử dụng hậu tố “AndWait”, ví dụ “ClickAndWait” Selenium sử dụng hậu tố này trong trường hợp chờ một trang Web được tải

Accessor: Kiểm tra trạng thái của ứng dụng và lưu trữ kết quả vào các biến

Ví dụ: “storeTitle” Chúng có thể được sử dụng để sinh tự động các Assertion

Assertion: Giống như những Accessor, nhưng nó xác định trạng thái của

ứng dụng thích nghi với kết quả mong đợi

Assertion của Selenium có thể được chia thành 3 dạng: “assert”, ”verify”, ” aitFor” Ví dụ: “assertText”, “verifyText”, “ WaitForText” Khi“assert” thất bại, việc kiểm thử sẽ dừng lại Khi“verify” thất bại, việc kiểm thử vẫn tiếp tục nhưng sẽ hiển thị một lỗi Lệnh “ WaitFor” chờ một vài điều kiện được thực thi (có ích khi

kiểm thử các ứng dụng Ajax), nó sẽ thành công nếu điều kiện đúng nhưng sẽ thất bại và tạm dừng việc kiểm thử nếu các điều kiện không đúng

Cú pháp

Các lệnh Selenium rất đơn giản, nó bao gồm lệnh và 2 tham số Các tham số không nhất thiết phải có trong mọi trường hợp, nó phụ thuộc vào câu lệnh, trong một số trường hợp câu lệnh yêu cầu cả hai tham số, một số chỉ yêu cầu một tham số,

và cũng có những câu lệnh không cần có tham số áp Script

Hình 2.4: Giao diện chính của selenium

Phân loại tham số:

Locator: Tham số xác minh các yếu tố trên giao diện người dùng Text pattern: Tham số xác minh nội dung mong đợi của ứng dụng web

Selenium variable: Nhập văn bản trong một trường đầu vào để lựa chọn từ danh sách lựa chọn

Một số lệnh thường sử dụng trong Selenium

- Open: Mở một ứng dụng web sử dụng URL

- Click/clickAndWait: Thực thi click và đợi tải 1 trang web mới

- VerifyTitle/assertTitle: xác nhận một tiêu đề trang được mong đợi VerifyTextPresent: Xác nhận văn bản được mong đợi tại một vị trí nào đó trên trang

- VerifyElementPresent: Xác nhận một yếu tố được mong đợi trên giao diện người sử dụng, được định nghĩa bởi thẻ HTML

- VerifyText: Xác nhận văn bản được mong đợi và các thẻ HTML tương ứng

- VerifyTable: Xác nhận các nội dung được mong đợi của 1 bảng

- WaitForPageToLoad: Tạm dừng thực thi lệnh cho đến khi trang Web mong đợi đượctải thành công, được gọi tự động khi sử dụng lệnh clickAndWait

- WaitForElementPresent: Tạm dừng thực thi lệnh cho tới khi một yếu tố giao diện người dùng xuất hiện trên trang web (được đinh nghĩa bởi các thẻ HTML)

2.3 Selenium Remote Control (Selenium RC)

Selenium RC ban đầu được phát triển bởi Patrick Lightbody theo hướng kiểm tra các ứng dụng web trên các trình duyệt khác nhau mà không cần cài đặt Selenium Core trên Server Nó được phát triển để tương tác như một giao tiếp giữa ứng dụng cần kiểm kiểm tra và kịch bản bản kiểm thử Selenium Core được tích hợp với Selenium RC thay cho việc cài đặt trên máy chủ

Hình 2.5: Giao diện Selenium RC

Selenium RC là công cụ phục vụ cho các công việc kiểm thử đòi hỏi nhiều hơn việc thao tác với website trên giao diện Selenium RC sử dụng ngôn ngữ lập trình để kiểm thử các trường hợp phức tạp hơn mà Selenium IDE không hỗ trợ

Các thành phần của Selenium Remote Control

Máy chủ Selenium: Thực hiện phân tích và chạy các lệnh được gửi đến từ ứng dụng cần kiểm thử và các thao tác như HTTP proxy, phân tích và xác minh các thông điệp HTTP giữa trình duyệt và ứng dụng cần kiểm tra

Các thư viện máy khách: Cung cấp giao tiếp giữa ngôn ngữ lập trình và máy chủ Selenium RC

Máy chủ nhận các lệnh Selenese từ chương trình được kiểm thử sử dụng các

đề nghị HTTP GET/POST đơn giản Điều này có nghĩa là chúng ta có thể sử dụng mọi ngôn ngữ lập trình có khả năng gửi yêu cầu HTTP tới các kịch bản kiểm thử tự động trên trình duyệt

2.3.2 Thư viện máy khách

Các thư viện máy khách cung cấp giao diện hỗ trợ lập trình, cho phép chạy lệnh Selenium từ chương trình của chúng ta Các thư viện máy khách hỗ trợ cho các ngôn ngữ lập trình khác nhau thì khác nhau Giao diện lập trình (API) là một tập các chức năng chạy lệnh Selenium từ chương trình của chúng ta, trong mỗi giao diện có một chức năng lập trình hỗ trợ lệnh Selenium

Thư viện máy khách sử dụng lệnh Selenese và chuyển tới máy chủ Selenium

để xử lý các hoạt động cụ thể và kiểm tra ngược lại với các ứng dụng cần kiểm tra Thư viện máy khách cũng nhận kết quả của lệnh và chuyển trở lại chương trình của chúng ta Chương trình có thể nhận kết quả và lưu nó vào một biến chương trình và

thông báo trở lại thành công hay thất bại hoặc có thể thực thi các hành động trực tiếp nếu nó là các lỗi không được mong đợi

Để thực hiện kiểm thử một chương trình, ta cần viết một chương trình chạy một tập lệnh Selenese sử dụng thư viện khách API và nếu đã có một kịch bản kiểm thử được tạo bởi Selenium IDE, ta có thể sử dụng chức năng “Export the Selenium

RC Code” Selenium-IDE có thể biên dịch các lệnh Selenium của nó một các hàm gọi API của Drive khách

2.4 Selenium webdriver

2.4.1 Selenium WebDriver là gì

 Selenium WebDriver là công cụ kiểm thử tự động các ứng dụng Web

- Viết scripts với nhiều ngôn ngữ lập trình khác nhau (Java,.Net, Php, Python

Hình 2.7: So sánh giữa Selenium WebDriver và các công cụ kiểm thử tự động khác

Trên thị trường có khá nhiều công cụ kiểm thử Web khác nhau như QuyckTestPro, công cụ của IBM Tuy nhiên, các công cụ đó không miễn phí và có những tính năng hỗ trợ ít hơn so với Selenium Dựa vào bảng so sánh trên, ta có thể thấy Selenium là công cụ tuyệt vời để sử dụng

Tổng quan về đối tượng 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 dùng 7 cách để xác định các phần tử web này (Locator):

Hình 2.8: Tổng quan về đối tượng UI (Locators)

a Xác định phần tử Web theo ID

Hình 2.9: Xác định phần tử Web theo ID

b Xác định phần tử Web theo Name

Hình 2.10: Xác định phần tử Web theo Name

c Xác định phần tử Web theo LinkText

Hình 2.11: Xác định phần tử Web theo LinkText