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

TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP HÀ NỘIKHOA 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

1.1.5.1 Kiểm thử hộp đen (Black box testing) 9 1.1.5.2 Kiểm thử hộp trắng (White box testing) 10

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 20 2.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ết hợp phát triển với đủ thử nghiệm và đảm bảo chất lượng trước khi tung ra sản phẩ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ệc thự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ững tì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ều lỗ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ử Selenium IDE 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ản kiể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 website taingheviet.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 website taingheviet.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 2 chươ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ào kiể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ỏi nhữ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ẾT1.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 đích tì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í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ử phần mềm cũng cung cấp mục tiêu, cái nhìn độc lập về phần mề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ần mề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ìn thấ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ểm thử được tiến hành sau khi các yêu cầu được xác định và việc lập trình được hoàn tất nhưng trong Agile thì việc kiểm thử được tiến hành liên tục trong suốt quá 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ị chi phố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ông qua 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ẩm phầ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ức nào Vì thế, nhiều tác giả đã mô tả việc kiểm thử phần mềm là một quy trình kiể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ềmNguyê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 được cà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 độ ưu tiê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ợp kiểm thử sao cho có độ bao phủ nhiều nhất và giảm thiểu rủi ro sót lỗi khi đến tay 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ớm cà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ớm khi đó í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ăng chí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ếm lỗ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 ta phả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ới kiể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ềm1.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ềm không được sử dụng thực sự Thường thì nó không kiểm thử chi tiết mà chủ yếu kiể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ểm tra cú pháp của code/ hoặc review code (kiểm tra xem code có được viết đúng tiêu chuẩn code Đây là loại kiểm thử có thể được sử dụng bởi DEV (những ngườ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ên dị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ình phá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ần mềm đang được kiểm thử) để kiểm soát việc thực hiện các bài kiểm tra và so sá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óa mộ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 Trong kiểm thử động, phần mềm phải thực sự được biên dịch và chạy Kiểm thử động thự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 tra xem 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ềm1.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ật này người kiểm thử xem phần mềm như là một hộp đen Người kiểm thử hoàn toàn không quan tâm đến cấu trúc, hành vi bên trong phần mềm Người kiểm thử 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ắng phả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ật giải được dùng trong phần mềm để có thể thông hiểu chi tiết về đoạn code cần kiể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ần mề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ột lớ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ều kiệ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ợp giữa phương pháp kiểm thử Black Box và White Box Trong kiểm thử hộp đen tester 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ương trì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ương trì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ột phầ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ủa chương trình với mục đích là để thiết kế các trường hợp kiểm thử, nhưng khi thự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ức khác nhau của kiểm thử, tuy nhiên nó chủ yếu được sử dụng trong kiểm thử tích hợ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ư Selenium WebDriver Điều này có nghĩa là việc thêm các tính năng tùy chỉnh hoặc kịch bản phức tạp hơ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ập trung vào kiểm thử trên trình duyệ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, bao gồ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 websitetaingheviet.com

2.1 Mô tả bài toán2.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

● Lập lịch crawl

● Đánh giá sản phẩm

2.2 Mô tả chương trình

2.2.1 Tổng quan về chương trình

Xây dựng một chương trình kiểm tra một số chức năng của website taingheviet.com và sử dụng công cụ kiểm thử là Selenium để kiểm thử Kiểm tra chương trình ứng dụng đúng hay sai.

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

Tiêu chuẩn dừng

Tất cả các testcase đã được thiết kế đều được thực thi Tất cả các lỗi tìm thấy đều được ghi nhận lý do rõ ràng để có thể giúp cho developer khắc phục.

Chịu trách nhiệm kiểm thử

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

Tiêu chuẩn dừng

Tất cả các testcase đã được thiết kế đều được thực thi Tất cả các lỗi tìm thấy đều được ghi nhận lý do rõ ràng để có thể giúp cho developer khắc phục.

Chịu trách nhiệm kiểm thử

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 hình trang chủ

2 Bỏ trống trường Username, Password đúng

Đăng nhập không thành công Hiển thị message: Vui lòng điền vào ô này

3 Username đúng, Bỏ

Đăng nhập không thành công Hiển thị message: Vui lòng điền vào ô này

Password đúng

Đăng nhập không thành công Hiển thị message: Tên đăng nhập hoặc tài khoản không tồn tại.

Password sai

Đăng nhập không thành công Hiển thị message: Mật khẩu sai vui lòng thử lại.

Bảng 2.4: Bảng thiết kế checklist màn hình đăng nhập

c) Bảng test case:

24