Đề Tài Nghiên Cứu Và Ứng Dụng Công Cụ Selenium Ide Vào Kiểm Thử Website Taingheviet Com.pdf

1.1.3 Các nguyên tắc cơ bản của kiểm thử phần mềm 61.1.4.2 Dynamic testing Kiểm thử động 9 CHƯƠNG 2 Ứng dụng công cụ Selenium IDE vào website taingheviet.com 19... - Áp dụng Selenium IDE

TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP HÀ NỘI

KHOA CÔNG NGHỆ THÔNG TIN

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

1.1.4.2 Dynamic testing (Kiểm thử động) 9

CHƯƠNG 2 Ứng dụng công cụ Selenium IDE vào website taingheviet.com 19

2.2.2 Môi trường test 202.3 Chiến lược kiểm thử ứng dụng cho website taingheviet.com 20

2

LỜI MỞ ĐẦU

1 Lý do chọn đề tài

Hiện nay, dưới sự cạnh tranh gay gắt trên thị trường công nghệ giúp kếthợp phát triển với đủ thử nghiệm và đảm bảo chất lượng trước khi tung ra sảnphẩm Không có sản phẩm nào hoàn hảo 100%, xác suất gặp rủi ro hoặc lỗi làluôn có, điều này đúng với cả những nhà sản xuất chuyên nghiệp Do đó, việcthực hiện những cuộc thử nghiệm chất lượng sản phẩm thông qua giả lập nhữngtình huống xấu là rất cần thiết Để quá trình kiểm thử có thể tìm ra được nhiềulỗi và các khiếm khuyết thì chúng ta phải có hiểu biết về kiểm thử và công cụ

mà ta sử dụng để kiểm thử

2 Mục tiêu nghiên cứu

Trong bài tập lớn này, chúng em sẽ tìm hiểu về công cụ kiểm thử SeleniumIDE và ứng dụng thực tiễn

- Tìm hiểu các tính năng của Selenium và cách sử dụng chúng

- Đánh giá khả năng của Selenium IDE trong việc tạo và chạy các kịch bảnkiểm thử tự động

- So sánh Selenium IDE với các công cụ kiểm thử khác và xác định những

ưu điểm và hạn chế của công cụ này

- Áp dụng Selenium IDE vào việc kiểm thử thực tế trên websitetaingheviet.com và đánh giá hiệu quả của công cụ trong việc phát hiện các lỗi

4 Kết quả mong muốn đạt được của đề tài

- Hiểu được các tính năng của Selenium và cách sử dụng chúng

3

- So sánh Selenium IDE với các công cụ kiểm thử khác và xác định những

ưu điểm và hạn chế của công cụ này

- Áp dụng công cụ Selenium IDE vào việc kiểm thử thực tế trên websitetaingheviet.com và đánh giá hiệu quả của công cụ trong việc phát hiện các lỗi

5 Cấu trúc của báo cáo

Ngoài phần Mở đầu, phần Kết luận, cấu trúc báo cáo BTL còn gồm 2chương:

- Nội dung Chương 1 trình bày về cơ sở lý thuyết về kiểm thử phần mềm

và

khái quát về công cụ Selenium IDE

- Nội dung Chương 2 trình bày về cách áp dụng công cụ Selenium IDE vàokiểm thử website taingheviet.com

Trong quá trình hoàn thành bài tập lớn chúng em sẽ không tránh khỏinhững sai sót, rất mong sự thông cảm và đóng góp ý kiến bổ sung của các thầy

cô giáo và của tất cả các bạn sinh viên

Chúng em chân thành cảm ơn và tiếp thu

4

DANH MỤC HÌNH VẼ, ĐỒ THỊ

Hình 1.1: Minh hoạ kiểm thử hộp đen 10

Hình 1.5: Quy trình lập kế hoạch kiểm thử 13

Hình 1.8: Mô tả các phần mềm của Selenium 17

Hình 2.21: Kết quả chạy TC4 32

6

CHƯƠNG 1: CƠ SỞ LÝ THUYẾT 1.1 Kiểm thử phần mềm

1.1.1 Kiểm thử phần mềm là gì

Kiểm thử phần mềm là quá trình thực thi một chương trình với mục đíchtìm ra lỗi Kiểm thử phần mềm đảm bảo sản phẩm phần mềm đáp ứng chínhxá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ử phần mềm cũng cung cấp mục tiêu, cái nhìn độc lập về phầnmềm, điều này cho phép việc đánh giá và hiểu rõ các rủi ro khi thực thi phầnmềm Kiểm thử phần mềm tạo điều kiện cho bạn tận dụng tối đa tư duy đánh giá

và sáng tạo để bạn có thể phát hiện ra những điểm mà người khác chưa nhìnthấy

Tùy thuộc vào từng phương pháp, việc kiểm thử có thể được thực hiện bất

cứ lúc nào trong quá trình phát triển phần mềm Theo truyền thống thì việc kiểmthử được tiến hành sau khi các yêu cầu được xác định và việc lập trình đượchoàn tất nhưng trong Agile thì việc kiểm thử được tiến hành liên tục trong suốtquá trình xây dựng phần mềm Như vậy, mỗi một phương pháp kiểm thử bị chiphối theo một quy trình phát triển phần mềm nhất định

1.1.2 Vai trò của kiểm thử phần mềm

Kiểm thử phần mềm đóng vai trò quan trọng trong việc đánh giá và thuđược chất lượng cao của sản phẩm phần mềm trong quá trình phát triển Thôngqua chu trình “kiểm thử – tìm lỗi – sửa lỗi”, ta hy vọng chất lượng của sản phẩmphần mềm sẽ được cải tiến Mặt khác, thông qua việc tiến hành kiểm thử mức hệthống trước khi cho lưu hành sản phẩm, ta biết được sản phẩm của ta tốt ở mứcnào Vì thế, nhiều tác giả đã mô tả việc kiểm thử phần mềm là một quy trìnhkiểm chứng để đánh giá và tăng cường chất lượng của sản phẩm phần mềm

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

Nguyên tắc 1: Kiểm thử luôn có lỗi

7

Kiểm thử có thể cho thấy rằng phần mềm đang có lỗi, nhưng không thểchứng minh rằng một phần mềm không có lỗi.

Kiểm thử làm giảm xác suất lỗi tiềm ẩn trong phần mềm, ngay cả khi đãkiểm thử nghiêm ngặt phần mềm vẫn có thể còn lỗi Vì vậy, cần phải tìm đượccàng nhiều lỗi càng tốt

Nguyên tắc 2: Kiểm thử toàn bộ là không thể

Kiểm thử với tất cả các kết hợp đầu vào và đầu ra, với tất cả các kịch bản làkhông thể trừ khi kiểm thử chỉ bao gồm một số ít trường hợp thì có thể kiểm thửtoàn bộ

Thay vì kiểm thử toàn bộ, việc phân tích rủi ro và dựa trên sự mức độ ưutiên người kiểm thử có thể tập trung việc kiểm thử vào một số điểm cần thiết, cónguy cơ lỗi cao hơn Nghĩa là phải lên kế hoạch kiểm thử, thiết kế trường hợpkiểm thử sao cho có độ bao phủ nhiều nhất và giảm thiểu rủi ro sót lỗi khi đếntay người dùng

Nguyên tắc 3: Kiểm thử càng sớm càng tốt

Để tìm được lỗi sớm, các hoạt động kiểm thử nên được bắt đầu càng sớmcàng tốt trong quy trình phát triển (vòng đời phát triển) phần mềm hoặc hệthống, và nên tập trung vào các hoạt động/mục tiêu đã xác định trước

Các hoạt động kiểm thử được bắt đầu càng sớm thì sẽ phát hiện ra lỗi sớmkhi đó ít tốn công để tìm lỗi và sửa chữa

Nguyên tắc 4: Sự tập trung của lỗi

Thông thường, lỗi tập trung vào những module, thành phần chức năngchính của hệ thống Nếu xác định được điều này bạn sẽ tập trung vào tìm kiếmlỗi quanh khu vực được xác định Nó được coi là một trong những cách hiệu quảnhất để thực hiện kiểm tra hiệu quả

Nguyên tắc 5: Nghịch lý thuốc trừ sâu

Nếu bạn sử dụng cùng một tập hợp các trường hợp kiểm thử liên tục, sau

đó một thời gian các trường hợp kiểm thử không tìm thấy lỗi nào mới Hiệu quảcủa các trường hợp kiểm thử bắt đầu giảm xuống sau một số lần thực hiện, vì

8

vậy luôn luôn chúng ta phải luôn xem xét và sửa đổi các trường hợp kiểm thửtrên một khoảng thời gian thường xuyên.

Nguyên tắc 6: Kiểm thử phụ thuộc vào ngữ cảnh

Theo nguyên tắc này thì việc kiểm thử phụ thuộc vào ngữ cảnh và chúng taphải tiếp cận kiểm thử theo nhiều ngữ cảnh khác nhau Nếu bạn đang kiểm thửứng dụng web và ứng dụng di động bằng cách sử dụng chiến lược kiểm thửgiống nhau, thì đó là sai Chiến lược để kiểm thử ứng dụng web sẽ khác vớikiểm thử ứng dụng cho thiết bị di động của Android

Nguyên tắc 7: Không có lỗi – sai lầm

Việc không tìm thấy lỗi trên sản phẩm không đồng nghĩa với việc sản phẩm

đã sẵn sàng để tung ra thị trường Việc không tìm thấy lỗi cũng có thể là do bộtrường hợp kiểm thử được tạo ra chỉ nhằm kiểm tra những tính năng được làmđúng theo yêu cầu thay vì nhằm tìm kiếm lỗi mới

1.1.4 Phân loại kiểm thử phần mềm

1.1.4.1 Static testing (Kiểm thử tĩnh)

Kiểm thử tĩnh là một hình thức của kiểm thử phần mềm mà phần mềmkhông được sử dụng thực sự Thường thì nó không kiểm thử chi tiết mà chủ yếukiểm tra tính đúng đắn của code (mã lệnh), thuật toán hay tài liệu Chủ yếu kiểmtra cú pháp của code/ hoặc review code (kiểm tra xem code có được viết đúngtiêu chuẩn code Đây là loại kiểm thử có thể được sử dụng bởi DEV (nhữngngười lập trình), làm việc một cách độc lập Các kỹ thuật review code, kiểm tra

và walkthroughs cũng được sử dụng trong test tĩnh này Kiểm thử tĩnh liên quanđến việc xem xét các yêu cầu và các tài liệu thiết kế chi tiết

Kiểm thử tĩnh cũng có thể được tự động hóa Nó sẽ thực hiện kiểm tra toàn

bộ bao gồm các chương trình được phân tích bởi một trình thông dịch hoặc biêndịch mà xác nhận tính hợp lệ về cú pháp của chương trình

9

Các kỹ thuật kiểm thử tĩnh giúp nâng cao chất lượng phần mềm bằng cách

hỗ trợ các nhà phát triển nhận ra và sửa chữa các sai sót của họ trong quá trìnhphát triển phần mềm

1.1.4.2 Dynamic testing (Kiểm thử động)

Kiểm thử tự động là việc sử dụng phần mềm đặc biệt (tách biệt với phầnmềm đang được kiểm thử) để kiểm soát việc thực hiện các bài kiểm tra và sosánh kết quả thực tế với kết quả dự đoán Kiểm thử tự động có thể tự động hóamột số nhiệm vụ lặp đi lặp lại nhưng cần thiết trong một quá trình kiểm thử đãđược chính thức hóa, hay là các kiểm thử bổ sung nhưng sẽ khó thực hiện thủcông Kiểm thử động kiểm tra cách thức hoạt động của mã lệnh, tức là kiểm tra

sự phản ứng vật lý từ hệ thống tới các biến luôn thay đổi theo thời gian Trongkiểm thử động, phần mềm phải thực sự được biên dịch và chạy Kiểm thử độngthực sự bao gồm: làm việc với phần mềm, nhập các giá trị đầu vào và kiểm traxem liệu đầu ra có như mong muốn hay không

Các phương pháp kiểm thử động gồm có: Unit test (Kiểm thử đơn vị),Integration Tests (Kiểm thử tích hợp), System Tests (Kiểm thử hệ thống) vàAcceptance Tests (Kiểm thử chấp nhận)

1.1.5 Các kỹ thuật kiểm thử phần mềm

1.1.5.1 Kiểm thử hộp đen (Black box testing)

Kiểm thử hộp đen hay còn gọi là kiểm thử hướng dữ liệu Trong kỹ thuậtnày người kiểm thử xem phần mềm như là một hộp đen Người kiểm thử hoàntoàn không quan tâm đến cấu trúc, hành vi bên trong phần mềm Người kiểmthử chỉ quan tâm đến việc tìm ra các lỗi mà phần mềm không xử lý theo đúngđặc tả của nó Vì thế dữ liệu kiểm thử xuất phát từ đặc tả

10

Hình 1.1: Minh hoạ kiểm thử hộp đen

- Một số loại kiểm thử hộp đen hay dùng

Kiểm thử phân vùng tương đương

Kiểm thử phân tích giá trị biên

Kiểm thử dựa vào đồ thị nguyên nhân – kết quả

Sử dụng bảng quyết định

1.1.5.2 Kiểm thử hộp trắng (White box testing)

Kiểm thử hộp trắng còn gọi là kiểm thử cấu trúc Dựa vào thuật giải cụ thể,vào cấu trúc dữ liệu bên trong của đơn vị phần mềm cần kiểm thử để xác địnhđơn vị phần mềm đó có thực hiện đúng không Do đó người kiểm thử hộp trắngphải có kỹ năng, kiến thức nhất định về ngôn ngữ lập trình được dùng, về thuậtgiải được dùng trong phần mềm để có thể thông hiểu chi tiết về đoạn code cầnkiểm thử

Hình 1.2: Minh hoạ kiểm thử hộp trắng

11

Kiểm thử hộp trắng thường tốn rất nhiều thời gian và công sức nếu phầnmềm quá lớn (thí dụ trong kiểm thử tích hợp hay kiểm thử chức năng) Do đó kỹthuật này chủ yếu được dùng để kiểm thử đơn vị, kiểm thử từng tác vụ của mộtlớp chức năng.

- Các kỹ thuật kiểm thử hộp trắng:

Kiểm thử đường dẫn cơ sở

Kiểm thử cấu trúc điều khiển bao gồm các kĩ thuật: kiểm thử điềukiện và kiểm thử vòng lặp

1.1.5.3 Kiểm thử hộp xám

Kiểm thử hộp xám là một phương pháp kiểm thử phần mềm được kết hợpgiữa phương pháp kiểm thử Black Box và White Box Trong kiểm thử hộp đentester kiểm thử các hạng mục mà không cần biết cấu trúc bên trong của chươngtrình, còn kiểm thử hộp trắng thì tester biết được cấu trúc bên trong của chươngtrình Trong kiểm thử hộp xám, cấu trúc bên trong sản phẩm chỉ được biết mộtphần Tester có thể truy cập vào cấu trúc dữ liệu bên trong và thuật toán củachương trình với mục đích là để thiết kế các trường hợp kiểm thử, nhưng khithực hiện kiểm thử thì test như người dùng cuối hoặc là ở mức hộp đen

Hình 1.3: Minh hoạ kiểm thử hộp xám

Mặc dù phương pháp kiểm thử hộp xám có thể được dùng trong các mứckhác nhau của kiểm thử, tuy nhiên nó chủ yếu được sử dụng trong kiểm thử tíchhợp

12

- Tương thích đa trình duyệt:

Selenium IDE tương thích với

nhiều trình duyệt phổ biến như

Chrome, Firefox, Safari, và

Edge, cho phép kiểm tra ứng

dụng trên nhiều nền tảng

khả năng mở rộng linh hoạt nhưcác công cụ tự động hóa thửnghiệm khác như SeleniumWebDriver Điều này có nghĩa

là việc thêm các tính năng tùychỉnh hoặc kịch bản phức tạphơn có thể khó khăn hơn

- Giới hạn đối với các ứng dụng diđộng: Selenium IDE chủ yếu tậptrung vào kiểm thử trên trìnhduyệt web và có hạn chế khi sửdụng cho kiểm thử ứng dụng diđộng

1.2.3 Tiêu chí lựa chọn Selenium IDE

- Tìm hiểu về các concepts của tự động hóa kiểm thử và Selenium, baogồm:

● Command type: open, clickAndWait, assert, verify, …

● Locators: như ID, name, xpath, css selector, …

● Thực thi các đoạn mã Javascript thông qua run script

● Exporting test cases theo nhiều format khác nhau

- Để tạo ra các kịch bản test mà không cần kiến thức về lập trình

- Tạo ra các test cases hoặc test suites đơn giản, sau đó có thể export và sửdụng bằng Selenium WebDriver tool

- Để kiểm tra một ứng dụng web mà chỉ yêu cầu test trên Edge và Chrome

19

CHƯƠNG 2 Ứng dụng công cụ Selenium IDE vào website

taingheviet.com 2.1 Mô tả bài toán

2.1.1 Mục đích

✔ Lên kế hoạch cho việc test Website taingheviet.com

✔ Xác định thông tin cơ bản về dự án và các thành phần chức năng được kiểm thử và không được kiểm thử

✔ Liệt kê những yêu cầu kiểm thử

✔ Nêu ra những phương pháp, chiến lược kiểm thử nên sử dụng

✔ Liệt kê những kết quả, tài liệu có được sau khi thực hiện kiểm thử

● Thanh toán

● Tìm kiếm bài viết

● Like và chia sẻ sản phẩm

● Cấu hình crawl một trang tin

● Cấu hình sinh url

2.2.2 Môi trường test

tra xác theo đặc tả yêu cầu

Kỹ thuật Thực thi tất cả các trường hợp có thể có cho mỗi nhóm

chức năng, sử dụng dữ liệu hợp lệ và không hợp lệ để xác định:

- Kết quả mong đợi khi dữ liệu hợp lệ được sử dụng

- Cảnh báo phù hợp hiện ra khi dữ liệu không hợp lệ được sử dụng

Test Designer /Tester

Cách kiểm thử Kiểm thử bằng tay thủ công, tuần tự theo các bước được

định nghĩa trong testcase

Kiểm thử tự động với công cụ Selenium Webdriver

Xử lý ngoại lệ Liệt kê tất cả các vấn đề liên quan phát sinh trong quá

Kỹ thuật Giao diện đảm bảo theo design đặc tả cung cấp

Test Designer / Tester

Cách kiểm thử Kiểm thử bằng tay thủ công, tuần tự theo các bước được

định nghĩa trong testcase

Xử lý ngoại lệ Liệt kê tất cả các vấn đề liên quan phát sinh trong quá

trình thực thi kiểm thử

Bảng 2.2: Kiểm thử giao diện

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

2.3.1.1 Kiểm thử chức năng Đăng nhập

a) Giao diện đăng nhập

Hình 2.3: Màn hình đăng nhập

b) Thiết kế Test case

Đối với form Đăng nhập của website taingheviet.com, yêu cầu bài toán như sau:

23

● Gồm 2 trường: Username or Email, Password

● Username viết liền không dấu, không chứa ký tự đặc biệt…

● Password có độ dài tối thiểu 4 ký tự

● Trường hợp hợp lệ sẽ chuyển tới màn hình chính của taingheviet

● Trường hợp không nhập Username or Email sẽ hiển thị cảnh báo sau: Username or Email is required

● Trường hợp không nhập Password sẽ hiển thị cảnh báo sau: Password is required

● Trường hợp Username or Email and Password không hợp lệ sẽ hiển thị cảnh báo sau: Tài khoản hoặc mật khẩu không tồn tại

1 Username hợp lệ Login thành công Tự động chuyển tới màn

Testcase Username PassWord Target Active

Hình 2.10: Kết quả TC5

2.1.2.1 Kiểm thử chức năng Liên hệ

a) Giao diện Liên hệ

Hình 2.11: Màn hình Liên hệ

b) Thiết kế test case

o Mô tả điều kiện

− Các trường không được để trống ngoại trừ trường Tiêu đề

− Trường email theo định dạng a@b.c

o Áp dụng phương pháp phân vùng tương đương

Bảng phân vùng tương đương

27

Đầu vào Vùng hợp

lệ

Kí hiệu

Email không đúngđịnh dạng

Bảng 2.12: Bảng thiết kế checklist màn hình liên hệ

c) Bảng test case Liên hệ

1 Họ và tên Nguyen Nghia Liên hệ thành công H1, H2,

TCs Đầu vào Đầu ra Bao phủ

Hình 2.17: Kết quả chạy TC2

− TC3:

a Chạy:

31

Hình 2.18: Kết quả chạy TC3

b Kết quả:

Hình 2.19: Kết quả chạy TC3

32