Nghiên cứu và ứng dụng công cụ selenium webdriver trong kiểm thử tự động ứng dụng web

Các mô hình phát triển phần mềm  Mô hình tuyến tính/ Thác nước Water fall Là mô hình phát triển phần mềm cổ điển gồm có 05 pha: Phân tích, định nghĩa các yêu cầu, Thiết kế, Cài đặt và

LỜI CẢM ƠN

Em xin chân thành cảm ơn sự giúp đỡ nhiệt tình của thầy giáo - Tiến sĩ Nguyễn Văn Núi, người đã cung cấp cho em những kiến thức cơ bản về kiểm thử phần mềm cũng như định hướng cho em những phương pháp, công cụ kiểm thử và cung cấp tài liệu tham khảo, để em có thể hoàn thành tốt đề tài của mình

Em cũng xin gửi lời cảm ơn đến các thầy cô giáo, giảng viên trong Khoa Công Nghệ Thông Tin – Trường ĐH Công Nghệ Thông Tin và Truyền Thông Thái Nguyên – Đại học Thái Nguyên và các thầy cô đã giảng dạy em trong suốt quá trình em học tập tại trường

Con cũng xin gửi lời cảm ơn chân thành đến gia đình, bố mẹ và bạn bè đã luôn là nguồn động viên to lớn giúp đỡ con vượt qua những khó khăn trong suốt quá trình học tập Mặc dù đã cố gắng hoàn thiện đồ án với tất cả nỗ lực của bản thân, nhưng chắc không thể tránh khỏi những thiếu sót Kính mong quý thầy cô đóng góp ý kiến để em

có thể hoàn thiện kiến thức của bản thân!

Là sinh viên công nghệ thông tin, em rất tự hào về ngồi trường mà mình đang theo học, và tự hào về tất cả thầy cô của mình!

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

Thái Nguyên, tháng 5 năm 2017

Sinh viên

Nguyễn Thị Ngoan

LỜI CAM ĐOAN

Để hoàn thành đồ án tốt nghiệp đúng thời gian quy định và đáp ứng được yêu cầu

đề ra, em đã cố gắng tìm hiểu, học hỏi, tích lũy kiến thức đã học Em có tham khảo một số tài liệu đã nêu trong phần “Tài liệu tham khảo” nhưng không sao chép nội dung

MỤC LỤC

LỜI CẢM ƠN 1

LỜI CAM ĐOAN 2

MỤC LỤC 3

DANH MỤC HÌNH ẢNH 6

LỜI NÓI ĐẦU 7

CHƯƠNG 1: TỔNG QUAN VỀ PHẦN MỀM 8

1.1 Phần mềm là gì? 8

1.1.1 Khái niệm 8

1.1.2 Phân loại phần mềm 8

1.1.3 Vòng đời phát triển phần mềm (Software Development Life Cycle) 8

1.1.4 Các mô hình phát triển phần mềm 10

1.2 Kiểm thử phần mềm 15

1.2.1 Khái niệm kiểm thử phần mềm 15

1.2.2 Các mức kiểm thử 15

1.2.3 Các phương pháp kiểm thử 16

1.2.4 Các loại kiểm thử 18

1.3 Quy trình kiểm thử phần mềm (STLC) 20

1.4 Kế hoạch kiểm thử (test plan) 21

1.5 Thiết lập môi trường kiểm thử 22

1.5.1 Khái niệm môi trường kiểm thử 22

1.5.2 Thiết lập môi trường kiểm thử 22

1.6 Testcase, kỹ thuật thiết kế testcase 23

1.6.1 Khái niệm về testacase 23

1.6.2 Các kỹ thuật thiết kế testcase 23

1.7 Kiểm thử tự động 26

1.7.1 Kiểm thử tự động là gì? Quy trình kiểm thử tự động 26

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

1.7.3 Các trường hợp nên áp dụng kiểm thử tự động 27

CHƯƠNG 2: KIỂM THỬ ỨNG DỤNG WEB 29

2.1 Kiểm thử ứng dụng web 29

2.1.1 Khái quát 29

2.1.2 Đặc điểm về chất lượng của một ứng dụng Web 29

2.2 Công việc khi kiểm thử một ứng dụng web 30

2.2.1 Kiểm tra chức năng (hồi quy, tích hợp, kiểm tra khói) 31

2.2.2 Kiểm tra sự tương thích trình duyệt 32

2.2.3 Thử nghiệm tính năng 33

2.2.4 Kiểm tra bảo mật 33

2.2.5 Giám sát sản xuất 34

2.2.6 Kiểm tra khả năng sử dụng 34

2.3 Thiết kế testcase cho ứng dụng web 35

2.3.1 Quy trình thiết kế testcase cho ứng dụng web 35

2.3.2 Các Check list 35

2.4 Giới thiệu một số công cụ hỗ trợ kiểm thử ứng dụng web 37

2.4.1 Công cụ test bảo mật web 37

2.4.2 Công cụ test hiệu năng 38

CHƯƠNG 3: SỬ DỤNG CÔNG CỤ HỖ TRỢ TEST SELENIUM WEBDRIVER ĐỂ TEST ỨNG DỤNG WEB 39

3.1 Giới thiệu chung về Selenium, cách cài đặt và sử dụng Selenium 39

3.1.1 Giới thiệu chung về Selenium 39

3.1.2 Các đặc điểm của Selenium 39

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

3.2 Selenium IDE 43

3.2.1 Giới thiệu về Selenium IDE 43

3.2.2 Hướng dẫn cài đặt Selenium IDE 43

3.2.3 Các câu lệnh chính của Selenium IDE 45

3.2.4 Locator (Xác định đối tượng UI) 47

3.3 Selenium WebDriver 48

3.3.1 Giới thiệu về Selenium WebDirver 48

3.3.2 Cài đặt Selenium WebDriver 49

3.3.3 Các câu lệnh sử dụng trong Selenium WebDriver 57 3.3.4 Bài toán thử nghiệm tiến hành test Selenium WebDriver trên trang https://accounts.google.com/ 61 3.3.5 Kịch bản kiểm thử tự động 63 3.3.6 Sự khác nhau giữa kịch bản kiểm thử thử công và kịch bản kiểm thử tự động 65 KẾT LUẬN 67 TÀI LIỆU THAM KHẢO 68

DANH MỤC HÌNH ẢNH

Hình 1.1: Vòng đời phát triển phần mềm 9

Hình 1.2: Mô hình thác nước 10

Hình 1.3: Mô hình mẫu 11

Hình 1.4: Mô hình phát triển ứng dụng nhanh RAD 12

Hình 1.5: Mô hình tiến hóa 12

Hình 1.6: Mô hình chữ V 13

Hình 1.7: Mô hình Agile Scrum 14

Hình 1.8: Phương pháp kiểm thử hộp đen 16

Hình 1.9: Phương pháp kiểm thử hộp trắng 17

Hình 1.10: Phương pháp kiểm thử hộp xám 18

Hình 1.11: Quy trình kiểm thử phần mềm 20

Hình 1.12: Kỹ thuật phân vùng tương đương 24

Hình 1.13: Kỹ thuật phân tích giá trị biên 25

Hình 3.1: Cấu trúc của Selenium 39

Hình 3.2: Minh họa kiến trúc của WebDriver và Selenium RC 42

Hình 3.3: Thao tác mở Selenium IDE trên thanh công cụ 44

Hình 3.4: Giao diện chính của Selenium IDE 44

Hình 3.5: Cấu trúc của Selenium WebDriver 49

Hình 3.6: Download và cài đặt JDK 50

Hình 3.7: Download Eclipse IDE 50

Hình 3.8: Download Selenium Java Client Driver 51

Hình 3.9: Tạo một project mới 51

Hình 3.10: Đặt tên và chọn tạo phương thức 52

Hình 3.11: Tên Class trong Eclipse 52

Hình 3.12: Thêm Selenium Java Client Driver (.jar) vào trong project 53

Hình 3.13: Đăng nhập thành công trên Firefox 63

Hình 3.14: Đăng nhập thành công trên Chrome 64

Hình 3.15: Giao diện báo cáo kết quả kiểm thử thành công 64

Hình 3.16: Giao diện báo cáo kết quả kiểm thử thất bại 65

Hình 3.17: Bảng tóm tắt các trường hợp testcase đã chạy 65

LỜI NÓI ĐẦU

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

Các ứng dụng Web đã được phát triển và trở thành nền tảng kết nối thông tin thiết yếu trong doanh nghiệp, đóng vai trò quyết định trong thương mại điện tử, trao đổi thông tin Để có thể đạt được điều này, các úng dụng web cần phải có hiệu năng cao, đáng tin cậy…Việc đưa ra một ứng dụng web hoàn hảo cho người đang và sẽ sử dụng ứng dụng đã trở thành một thử thách chính trong vấn đề đảm bảo chất lượng Kiểm thử ứng dụng web đã vượt quá giới hạn của kiểm thử những hệ thống phần mềm truyền thống Như chúng ta đã biết, một ứng dụng web thường có rất nhiều nhóm người sử dụng với nền tảng khác nhau (hệ điều hành, trình duyệt, ) điều này dẫn tới việc kiểm thử ứng dụng web cần phải có những phương pháp đặc biệt khác với phần mềm truyền thống

Selenium WebDriver là một công cụ kiểm thử ứng dụng Web tiêu biểu Đây là

một công cụ mã nguồn mở, mạnh mẽ hỗ trợ trên nền Web, nhiều platform và các trình duyệt phổ biến Công cụ này được phát triển chủ yếu trong JavaScript và các công nghệ trình duyệt như HTML và các khung hình, và do đó hỗ trợ tất cả các trình duyệt chính trên các nền tảng Selenium WebDriver có lẽ là một trong những công cụ tốt nhất trên thị trường cho các ứng dụng Web Điều đáng lưu ý là kiểm thử phần mềm nói chung và kiểm thử Web nói riêng đều chưa được phổ biến ở Việt Nam Đây cũng

là lí do em chọn đề tài “Nghiên cứu và ứng dụng công cụ Selenium WebDriver trong kiểm thử tự động ứng dụng Web” với mong muốn giúp nhiều người hiểu rõ hơn về

kiểm thử ứng dụng Web cũng như cách sử dụng công cụ Selenium WebDriver vào công việc này

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

Đề tài giới thiệu về tổng quan phần mềm, các phương pháp kiểm thử và các công việc khi kiểm thử một ứng dụng Web

Đi sâu vào nghiên cứu tính năng của công cụ Selenium WebDriver, các thành phần của bộ công cụ

Đưa ra tài liệu hướng dẫn cài đặt, sử dụng một cách đơn giản và hiệu quả bộ công cụ đó

Ứng dụng kiến thức về kiểm thử phần mềm và các kiến thức về Selenium WebDriver để viết kịch bản cho một ứng dụng cụ thể

Một phần mềm thường gồm 03 phần:

• Chương trình máy tính: mã nguồn, mã máy

• Cấu trúc dữ liệu: cấu trúc làm việc (bộ nhớ trong), cấu trúc lưu trữ (bộ nhớ ngoài)

• Các tài liệu liên quan: tài liệu hướng dẫn sử dụng, tài liệu phát triển, tài liệu tham khảo kĩ thuật…

1.1.2 Phân loại phần mềm

Dựa vào môi trường thực thi, phần mềm được chia thành các loại như sau:

• Phần mềm ứng dụng giao diện hệ điều hành: (Windows Form, Windows Service)

• Phần mềm ứng dụng Web: (Website, Web Service, Web API….)

• Phần mềm ứng dụng Mobile App: (Android App, iOS App, Winphone App…)

• Phần mềm nhúng: (Ti vi, tủ lạnh, điều hòa….)

1.1.3 Vòng đời phát triển phần mềm (Software Development Life Cycle)

Vòng đời phát triển phần mềm là thời kì tính từ khi phần mềm được sinh (tạo) ra cho đến khi chết đi (từ lúc hình thành đáp ứng yêu cầu, vận hành, bảo dưỡng cho đến khi loại bỏ không dùng nữa)

Vòng đời của phần mềm được chia thành các pha chính: Phân tích, Thiết kế, chiết tạo, kiểm thử, bảo trì Được biểu diễn theo mô hình sau đây:

Hình 1.1: Vòng đời phát triển phần mềm

Pha xác định yêu cầu hệ thống: Mọi phần mềm đều được xây dựng, phát triển

trên tài liệu đặc tả (Software Requirement Specification) Dựa vào các đặc tả này của người dùng, bộ phận xây dựng phần mềm sẽ xác định yêu cầu hệ thống của hệ thống phần mềm sẽ xây dựng Xác định phần mềm thuộc loại nào: Windows Form, Web Form hay Mobile App

Pha xác định yêu cầu phần mềm: Sau khi xác định được loại của hệ thống sẽ

xây dựng, các kĩ sư phần mềm tiếp tục khảo sát các yêu cầu sử dụng của khách hàng qua đó xác định các yêu cầu của phần mềm mà khách hàng đang mong muốn xây dựng, đây chính là pha xác định xem phần mềm sẽ có chức năng gì và tương tác như thế nào?

Pha thiết kế căn bản: Hay còn gọi là thiết kế sơ bộ hệ thống, ở giai đoạn này

kiến trúc khung của phần mềm sẽ được thiết kế (sử dụng nền tảng nào, ngôn ngữ lập trình nào, áp dụng những công nghệ gì…)

Pha thiết kế chi tiết: Thiết kế chi tiết các chức năng mà chương trình sẽ có Xác

định nghiệp vụ cho từng chức năng sẽ xây dựng

Pha lập trình: Đây chính là pha hiện thực hóa phần mềm dựa vào các bản thiết

kế ở các pha trên Người lập trình cần phải sử dụng những công nghệ, ngôn ngữ lập trình cũng như những nền tảng đã được xác định để tiến hành lập trình thực hiện các nghiệp vụ đã được thiết kế

Pha kiểm thử: Sauk hi phần mềm đã được lập trình xong sẽ được chuyển sang

pha kiểm thử nhằm đảm bảo chương trình có đầy đủ các chức năng, nghiệp vụ mà khách hàng yêu cầu cũng như tất cả hoạt động tốt theo đúng mong muốn

Pha vận hành bảo trì: Đây là pha có thời gian dài nhất trong vòng đời của phần

mềm Sau khi phần mềm được thiết kế, lập trình và kiểm thử xong sẽ bàn giao cho khách hàng mang vào hoạt động thực tế Pha này sẽ kéo dài cho tới khi phần mềm không còn phù hợp nữa thì kết thúc

1.1.4 Các mô hình phát triển phần mềm

 Mô hình tuyến tính/ Thác nước (Water fall)

Là mô hình phát triển phần mềm cổ điển gồm có 05 pha: Phân tích, định nghĩa các yêu cầu, Thiết kế, Cài đặt và kiểm thử đơn vị, Tích hợp và kiểm thử hệ thống, vận hành và bảo trì được mô tả theo hình dưới đây:

Hình 1.2: Mô hình thác nước

Trong mô hình thác nước 5 pha trên phải được thực hiện một cách tuần tự, kết thúc pha trước rồi mới thực hiện pha tiếp theo Do đó, nhược điểm của mô hình thác nước là rất khó khăn trong việc thay đổi các pha đã được thực hiện Mô hình này chỉ

thích hợp khi các yêu cầu đã được tìm hiểu rõ ràng trong suốt quá trình thiết kế Tuy nhiên trong thực tế có rất ít các hệ thống nghiệp vụ có các yêu cầu ổn định

 Mô hình mẫu (Prototype)

Hình 1.3: Mô hình mẫu

Đây là mô hình thường áp dụng trong giai đoạn đầu của các dự án phức tạp nhằm làm rõ các yêu cầu cũng như cách thực hiện hóa các yêu cầu bằng cách tạo ra các mẫu (Prototype) Việc này không những giúp tinh chỉnh yêu cầu, mà đồng thời giúp cho đội phát triển hiểu hơn về những gì cần được phát triển Tiếp theo giai đoạn làm prototype này có thể là một chu trình thiết kế phần mềm nào đó sẽ được áp dụng

 Mô hình phát triển ứng dụng nhanh (RAD)

Là mô hình được giới thiệu bởi IBM vào những năm 1980 Phát triển phần mềm gia tăng, tăng dần từng bước với chu kì phát triển ngắn (60-90 ngày)

Hình 1.4: Mô hình phát triển ứng dụng nhanh RAD

Hạn chế của mô hình RAD:

• Cần nguồn nhân lực dồi dào để tạo nhóm cho các chức năng chính

• Cần phải có sự thỏa thuận chặt chẽ giữa các bên tham gia, thiếu trách nhiệm của bên nào dễ làm dự án đỗ vỡ

• RAD sẽ bất khả thi với những ứng dụng không thể module hóa hoặc đòi hỏi tính năng cao

 Mô hình tiến hóa

Hình 1.5: Mô hình tiến hóa

Phần lớn các hệ thống, phần mềm phức tạp đều tiến hóa theo thời gian: môi trường thay đổi, yêu cầu phát sinh thêm, hoàn thiện thêm chức năng, tính năng

Các mô hình tiến hóa (Evolutionary models) có tính lặp lại Kỹ sư phần mềm tạo

ra các phiên bản ngày càng hoàn thiện hơn, phức tạp hơn

 Mô hình chữ V (V- models)

V Models là tên viết tắt của Verification Software Development Model: Mô hình phát triển phần mềm xác minh, hay còn gọi là mô hình chữ V đó là mô hình gồm 5 giai đoạn chạy song song:

Hình 1.6: Mô hình chữ V

- Xác định yêu cầu (Requirement definition) và kiểm thử chấp nhận (acceptance testing): Sau khi đã có yêu cầu của khách hàng, ta thực hiện đồng thời việc phân tích yêu cầu và xây dựng bản kiểm thử cho người dùng (User Acceptance Testing) dựa trên các yêu cầu đó

- Thiết kế chức năng (Function system design) và kiểm thử hệ thống (System testing): Vừa thực hiện thiết kế các chức năng cho hệ thống, vừa thực hiện xây dựng các bản kiểm thử cho hệ thống (System testing)

- Thiết kế kiến trúc phần mềm (Architecture design) và kiểm thử tích hợp (Intergration testing): Thực hiện thiết kế kiến trúc các module và kỹ thuật của hệ thống, đồng thời xây dựng kịch bản test tích hợp

- Thiết kế các module và kiểm thử mức đơn vị

- Lập trình (Programming): Sau khi đã có thiết kế chi tiết thì tiến hành Coding

 Mô hình Agile Scum

Là một quy trình phát triển phần mềm theo mô hình linh hoạt (agile) giúp việc phát triển phần mềm trở nên nhanh chóng và dễ dàng

Scum chia dự án thành các vòng lặp phát triển gọi là các sprint Mỗi sprint thường mất 2-4 tuần (30 ngày) để hoàn thành => Rất phù hợp với những dự án có nhiều sự thay đổi và yêu cầu tốc độ cao

Mỗi sprint hoàn thành một số chức năng, mục đích nào đó trong toàn bộ hệ thống Các tác vụ trong sprint được chia ra thành các danh mục, các đội làm việc sẽ phát triển và đánh giá lại sao cho đạt được mục đích ban đầu đề ra

Thành phần chính quan trọng của scrum là các Role và các cuộc trao đổi đánh giá (Meeting)

• Product Owner: Là những người làm những công việc bắt đầu cho một dự

án, tạo ra các yêu cầu trong quá trình phát triển dự án Phân tích mục tiêu, giải phóng các kế hoạch

• Scrum Master: Là người đảm bảo các sprint được hoàn thành đúng mục đích,

bảo vệ đội làm việc và loại bỏ các trở ngại

• Đội làm việc ở Scrum: Thường từ 5-9 người, tùy theo yêu cầu dự án mà có

thể có nhiều đội, nhiều người tham gia Sẽ không có những lập trình viên, người thiết

kế hay kiểm thử viên như thường thấy ở các mô hình truyền thống Các đội sẽ tiến hành cài đặt các chức năng sao cho hiệu quả lớn nhất Tất cả các thành viên sẽ có ảnh hưởng như nhau đến sự thành công hoặc thất bại của toàn bộ hệ thống

1.2 Kiểm thử phần mềm

1.2.1 Khái niệm kiểm thử phần mềm

Kiểm thử phần mềm là một quy trình nhằm đảm bảo độ tin cậy và chất lượng của phần mềm Mục đích của kiểm thử phần mềm là chỉ ra rằng phần mềm thực hiện đúng các chức năng mà khách hàng mong muốn

Có 02 loại kiểm thử phần mềm:

• Kiểm thử phần mềm thủ công (Manual Testing)

• Kiểm thử tự động (Automation Testing)

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

• Phát hiện ra các nhiều lỗi (bug) càng tốt trong thời gian kiểm thử xác định trước

• Chứng minh rằng sản phẩm phần mềm phù hợp với các đặc tả yêu cầu của nó

• Tạo ra các testcase chất lượng nhằm tìm ra lỗi (nếu có) với chi phí thấp nhất

Ai là người kiểm thử?

Trong hầu hết các trường hợp, người kiểm thử (Tester) có thể là:

• Software Tester: Nhân viên kiểm thử phần mềm

• Software Developer: Nhân viên phát triển phần mềm

• Leader hoặc Manager của dự án

• Product Owner: Người sở hữu sản phẩm (Acceptance Testing)

• End-User: Người dùng cuối

Các vai trò trong kiểm thử phần mềm:

• Test Manager: Là người đứng đầu bộ phận kiểm thử, quản lý chung về các vấn

đề liên quan như quy trình làm việc, nhân sự…

• Test Leader: Là người trực tiếp tham gia vào quá trình kiểm thử dự án cùng với tester Test leader đảm nhiệm vai trò quản lý công việc của tester, thực hiện xác nhận các sản phẩm mà tester tạo ra cũng như báo cáo test manager khi có yêu cầu

• Tester /QC: Là người trực tiếp thực hiện quá trình kiểm thử, đảm bảo chất lượng của sản phẩm theo những nhiệm vụ được phân công

1.2.2 Các mức kiểm thử

Có 05 mức kiểm thử phần mềm cơ bản có thể áp dụng trong hầu hết các loại ứng dụng phần mềm:

1 Unit Test (Kiểm thử mức đơn vị lập trình): Là mức kiểm thử tập trung vào

việc xác minh trên các đơn vị nhỏ nhất của thiết kế phần mềm Sử dụng các mô tả thiết

kế thủ tục để phát hiện lỗi trong phạm vi Module/Function

2 Module/Fuction Test (Kiểm thử mức chức năng): Là mức kiểm thử tập trung

kiểm tra, xác minh xem một chức năng trong chương trình có hoạt động đúng như nó được thiết kế hay không?

3 Integration Test (Kiểm thử mức tích hợp): Là mức kiểm thử tập trung kiểm

tra, xác minh các thành phần trong phần mềm có tương tác được với nhau hay không,

có hoạt động phối hợp với nhau được hay không?

4 System Test (Kiểm thử mức hệ thống): Là mức kiểm thử nhằm đưa hệ thống

vào vận hành thử nghiệm tại các môi trường khác nhau nhằm tìm ra các lỗi về hệ thống, tính tương thích

5 Acceptance Test (Kiểm thử chấp nhận):Là mức kiểm thử được thực hiện ở

phía người sử dụng, đây được xem là kiểm thử chấp nhận sản phẩm

1.2.3 Các phương pháp kiểm thử

 Phương pháp kiểm thử hộp đen

Hay còn gọi là kiểm thử hướng dữ liệu Là phương pháp kiểm thử không quan tâm tới cấu trúc bên trong của phần mềm (cấu trúc dữ liệu, thuật toán, xử lý ) mà chỉ kiểm tra dữ liệu đầu vào, dữ liệu đầu ra ứng với các trường hợp trong đặc tả (Testcase)

Hình 1.8: Phương pháp kiểm thử hộp đen

Kiểm thử hộp đen không có “mối ràng buộc” nào với code và nhận thức của một tester rất đơn giản: một source code có nhiều lỗi =>Các tester sẽ tìm thấy được nhiều lỗi nơi mà Developer không tìm thấy

Quy trình kiểm thử hộp đen tổng quát:

• Phân tích đặc tả về các yêu cầu chức năng mà một thành phần phần mềm cần thực hiện

• Dùng các kĩ thuật xác định các testcase để định nghĩa ra các testcase Định nghĩa testcase là việc xác định 3 thông tin sau:

o Giá trị dữ liệu nhập vào thành phần phần mềm (hợp lệ hoặc không hợp lệ)

o Trạng thái của thành phần phần mềm cần có để thực hiện testcase

o Giá trị dữ liệu xuất ra mà thành phần phần mềm phải tạo được

• Kiểm thử các testcase đã định nghĩa

• So sánh kết quả thu được với kết quả kì vọng trong từng testcase, từ đó lập báo cáo về kết quả kiểm thử

 Phương pháp kiểm thử hộp trắng

Là phương pháp kiểm thử dựa vào giải thuật cụ thể, 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 hay không?

Hình 1.9: Phương pháp kiểm thử hộp trắng

Để thực hiện được phương pháp kiểm thử hộp trắng thì người kiểm thử 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ề giải thuật được dùng trong thành phần phần mềm để có thể thông hiểu được chi tiết về các đoạn code cần kiểm thử

 Phương pháp kiểm thử hộp xám

Là phương pháp kiểm thử kết hợp giữa phương pháp kiểm thử hộp đen và phương pháp kiểm thử hộp trắng Phương pháp kiểm thử hộp đen dùng để xác định nguồn gây ra lỗi còn phương pháp kiểm thử hộp trắng xác định xem lỗi đang gặp là lỗi gì

Hình 1.10: Phương pháp kiểm thử hộp xám

1.2.4 Các loại kiểm thử

 Kiểm thử cài đặt (Installing Testing)

Sau khi chương trình được lập trình xong, để đảm bảo tính toàn vẹn trong việc phân phối ứng dụng tới người sử dụng, chương trình cần được đóng gói thành các file cài đặt Kiểm thử cài đặt là loại kiểm thử kiểm tra xem quá trình cài đặt ứng dụng từ file đóng gói (package) có tốt không? Có làm được việc trên cấu hình phần cứng của khách hay không?

 Kiểm thử Smoke (Smoke Testing)

Đây là loại kiểm thử sơ lược hệ thống ngay sau khi cài đặt xem có xảy ra vấn đề

gì nghiêm trọng hay không? Loại kiểm thử này là kiểm thử sơ lược hệ thống, không đi sâu vào chi tiết các chức năng

 Kiểm thử chức năng (Function Testing)

Là hoạt động kiểm thử nhằm xác minh xem các chức năng, hoạt động của chương trình có hoạt động theo đúng như đặc tả được hay không? Phần lớn công việc của người tester thuộc loại kiểm thử này

 Kiểm thử hồi quy (Regression Testing)

Là loại kiểm thử tập trung vào việc tìm kiếm lỗi sau khi có một sự thay đổi lớn

đã xảy ra nhằm khám phá hồi quy phần mềm xem các lỗi cũ có xuất hiện hay không?

Để thực hiện điều này người tester cần thực hiện kiểu test lặp đi lặp lại các vấn đề gọi

là hồi quy

 Kiểm thử chấp nhận (Acceptance Testing)

Chấp nhận thử nghiệp được thực hiện bởi khách hàng, còn được gọi là User Acceptance Testing (UAT) Chấp nhận thử nghiệm có thể được thực hiện như một phần của quá trình bàn giao giữa bất kỳ hai giai đoạn phát triển

 Kiểm thử Alpha (Alpha Testing)

Đây là loại kiểm thử được áp dụng nhằm mục đích mô phỏng thực tế hoặc kiểm thử hoạt động của nhóm người dùng tiềm năng Đội phát triển sẽ tạo ra một phân bản (có thời gian hoạt động) và phân phối phiên bản này cho đông đảo người dùng (trong nội bộ công ty, tập đoàn) sử dụng nhằm tìm ra lỗi trong quá trình sử dụng Phiên bản phần mềm này được gọi là Alpha version

 Kiểm thử Beta (Beta Testing)

Cũng giống như Alpha Testing, nhưng loại test này được áp dụng ở mức độ cao hơn, rộng hơn Đội phát triển sẽ tạo ra phiên bản Beta của phần mềm, và phân phối sản phẩm này cho một nhóm có quy mô rộng lớn (một tỉnh, một quốc gia, một châu lục…) cùng sử dụng rộng rãi nhằm thu thập những đóng góp hoặc tìm ra lỗi

 Kiểm thử hiệu năng (Performace Testing)

Kiểm tra thời gian đáp ứng lại người dùng ứng với số lượng người dùng bất kì trong nhiều ngữ cảnh khác nhau của cùng một ứng dụng tại cùng một thời điểm

 Kiểm thử bảo mật (Security Testing)

Là quá trình xác định các lỗ hổng bảo mật trong ứng dụng bằng cách đánh giá hệ thống hoặc mạng với kỹ thuật độc hại khách nhau

 Kiểm thử tính khả dụng (Usability Testing)

Đây là loại kiểm thử các vấn đề phi chức năng liên quan tới tính tiện dụng, dễ sử dụng của ứng dụng

1.3 Quy trình kiểm thử phần mềm (STLC)

Software Testing Life Cycle đề cập đến một quy trình Test (Testing process) trong đó các bước cụ thể được thực hiện theo một trình tự nhất định để đảm bảo mục tiêu chất lượng được đáp ứng Trong quy trình kiêm thử phần mềm mỗi hoạt động được thực hiện một cách có kế hoạch và hệ thống Mỗi một giai đoạn có các mục tiêu khác nhau

Hình 1.11: Quy trình kiểm thử phần mềm

Requirement Analysis (giai đoạn tìm hiểu và phân tích yêu cầu): Đây là giai

đoạn tiếp cận dự án được thực hiện bởi toàn bộ team (project manager, developer, tester, QA…) cùng tham gia để phân tích các nghiệp vụ trong SRS thành các đơn vị chức năng của chương trình cần xây dựng

Test Planning (giai đoạn lập kế hoạch): Đây là giai đoạn được thực hiện bởi

Test Manager/ Test Leader, dựa vào các đặc tả SRS đã phân tích, phối hợp cùng project manager lập lên kế hoạch test cho dự án (Thời gian thực hiện, nhân lực, các phương pháp/kỹ thuật sẽ áp dụng, môi trường kiểm thử…)

Testcase Development (giai đoạn lập các trường hợp kiểm thử): Sau khi có test

plan, đội ngũ tester bắt đầu vào giai đoạn thiết kế các trường hợp kiểm thử cho các chức năng trong dự án, sau khi testcase được thiết kế xong sẽ được test leader, test manager phê duyệt để đưa vào giai đoạn thực hiện test sau này

Environment Setup (giai đoạn thiết lập môi trường kiểm thử): Sau khi hoàn

thành xong giai đoạn thiết kế các trường hợp kiểm thử, đội test sẽ tiếp tục chuẩn bị các môi trường kiểm thử (hệ điều hành, browser, thiết bị…) để sẵn sàng đưa sản phẩm vào thực hiện test sau khi hoàn thành xong

Test Execution (giai đoạn thực hiện test): Sau khi dự án hoàn thành được 70%

thì đội test bắt đầu đưa sản phẩm vào thực hiện test vòng 1(test sơ bộ, vừa test vừa thực hiện nghiệp vụ) Vòng 2 sẽ bắt đầu ngay sau khi sản phẩm hoàn thành 100% (Test hết tất cả các testcase đã thiết kế và tiến hành log bug vào hệ thống) Vòng 03 sẽ bắt đầu khi những bug mà tester tìm ra ở vòng test thứ 2 được xử lý hết và đội lập trình triển khai phiên bản mới

Chú ý: Số vòng test có thể nhiều hơn hoặc ít hơn tùy thuộc vào quy mô cũng như

yêu cầu của dự án

Test Cycle Closure (giai đoạn kết thúc): Sauk hi dự án thỏa mãn các tiêu chí về

chất lượng, test leader/test manager tiến hành xác minh, tổng kết quá trình test để sẵn sàng ra mắt cho khách hàng Đội test sẽ tiến hành lập báo cáo kiểm thử cho quản lý trực tiếp phục vụ cho việc làm tài liệu dự án gửi cho khách hàng Tiếp theo đó, đội test

có thể sẽ tiếp tục làm hướng dẫn sử dụng hoặc tài liệu triển khai phần mềm

1.4 Kế hoạch kiểm thử (test plan)

Là một bản tài liệu mô tả các mục tiêu, phạm vi, phương pháp tiếp cận và tập trung vào nỗ lực kiểm thử phần mềm

Quá trình chuẩn bị test plan là một cách hữu ích để suy nghĩ tới những nỗ lực cần thiết để xác định xem khả năng chấp nhận của một sản phẩm phần mềm Các tài liệu

sẽ giúp mọi người bên ngoài nhóm test hiểu được “tại sao” và “như thế nào” để chấp nhận sản phẩm

Các mục được bao gồm trong một Test Plan:

• Tài liệu tham khảo

• Lịch trình công việc (chi tiết cho từng người)

• Những yêu cầu về tài nguyên (Phần cứng, phần mềm, công cụ kiểm thử, môi trường kiểm thử, nhân sự, vai trò trách nhiệm, đào tạo…)

• Phạm vi kiểm thử (Những chức năng được kiểm thử, những chức năng không được kiểm thử)

• Chiến lược kiểm thử (chiến lược, các loại kiểm thử áp dụng)

• Điều kiện chấp nhận

• Các rủi ro có thể gặp phải của dự án

• Phân loại lỗi/ Quy trình xử lý lỗi

• Test deliverables

1.5 Thiết lập môi trường kiểm thử

1.5.1 Khái niệm môi trường kiểm thử

Môi trường kiểm thử là môi trường thực thi ứng dụng sao cho gần giống với người dùng nhất (Thông số phần cứng, phần mềm, hệ điều hành….)

Việc thiết lập môi trường kiểm thử giống với người dùng luôn là một thách thức rất lớn đối với một người kiểm thử do đó trong thực tế những nhân viên kiểm thử thường xây dựng một số môi trường mang tính đặc trưng chung để thực thi phần mềm thay vì phải xây dựng giả lập chính xác những gì mà người dùng sử dụng

Việc thiết lập môi trường giống với môi trường của người dùng thường được bắt buộc phải thực hiện khi có lỗi mà khách hàng gửi về và ảnh hưởng tới nghiệp vụ phần mềm Khi đó cần phải sử dụng mọi nguồn nhân lực để có thể tiến hành dựng được lỗi

=> Giúp lập trình viên xử lý

1.5.2 Thiết lập môi trường kiểm thử

Là quá trình xây dựng, thiết lập các cấu hình thiết bị, hệ điều hành giống với thiết

bị, hệ điều hành của người sử dụng với mục đích thực thi ứng dụng nhằm tìm ra lỗi hoặc tái hiện lại lỗi mà người dùng đã gặp phải

Việc người dùng sử dụng thiết bị như thế nào, luôn là ẩn số đối với những nhà phát triển phần mềm Vậy nên để trang bị những thiết bị phần cứng là một điều rất khó khăn Hơn nữa việc trang bị các thiết bị luôn đòi hỏi tiêu tốn một chi phí lớn Do đó,

để có thể thực hiện được điều này, người ta sử dụng các phần mềm hỗ trợ giả lập tạo môi trường thực thi phần mềm ví dụ như: Virtual Box, Virtual PC, VMWare…

1.6 Testcase, kỹ thuật thiết kế testcase

1.6.1 Khái niệm về testacase

Testcase trong kiểm thử phần mềm là một tập hợp các điều kiện được sử dụng để xác định xem một ứng dụng đang làm việc tốt hay không? Trường hợp kiểm thử có thể

là tích cực hay tiêu cực

Trường hợp kiểm thử tích cực được thiết kế để kiểm tra xem ứng dụng có hoạt động như cách mà nó được dự kiến sẽ hoạt động hay không? Trong khi các trường hợp kiểm thử tiêu cực được thiết kế để kiểm tra cách hệ thống phản ứng với chuỗi bất thường của các hành động hoặc giá trị bất ngờ

Một yêu cầu kiểm thử trong một ứng dụng phải có ít nhất hai trường hợp kiểm thử - một tích cực và một tiêu cực

1.6.2 Các kỹ thuật thiết kế testcase

 Kỹ thuật phân vùng tương đương (Equivalence Partitioning)

Là phương pháp chia các điều kiện đầu vào thành những vùng tương đương nhau Tất cả các giá trị trong một vùng tương đương sẽ cho một kết quả đầu ra giống nhau Vì vậy chúng ta có thể test một giá trị đại diện trong vùng tương đương

Hình 1.12: Kỹ thuật phân vùng tương đương

Thiết kế testcase bằng kỹ thuật phân vùng tương đương tiến hành theo 2 bước:

• Xác định các lớp tương đương

• Xác định các ca kiểm thử

Ưu điểm: Vì mỗi vùng tương đương ta chỉ cần test trên các phần tử đại diện nên

số lượng testcase được giảm đi khá nhiều nhờ đó mà thời gian thực hiện test cũng giảm đáng kể

Nhược điểm: Không phải với bất kì bài toán nào cũng đều có thể áp dụng kỹ thuật

này Có thể bị hack lỗi ở biên nếu chỉ chọn giá trị ở khoảng giữa của miền tương đương

 Kỹ thuật phân tích giá trị biên (Boundary – Value- Analysis)

Là trường hợp đặc biệt của phân vùng tương đương, dựa trên những phân vùng tương đương, tester sẽ xác định giá trị biên giữa những phân vùng này và lựa chọn testcase phù hợp Các Case chuẩn được lựa chọn dựa vào quy tắc sau:

• Giá trị biên nhỏ nhất -1

• Giá trị biên nhỏ nhất

• Giá trị biên lớn nhất

• Giá trị biên lớn nhất +1

Trong một số trường hợp muốn kiểm tra sâu hơn thì ta cũng có thể lựa chọn thêm

2 quy tắc: giá trị biên nhỏ nhất +1 và giá trị biên lớn nhất -1

Hình 1.13: Kỹ thuật phân tích giá trị biên

Ưu điểm: Thay vì phải test toàn bộ các giá trị trong từng vùng tương đương, kỹ thuật phân tích giá trị biên tập trung vào việc kiểm thử các giá trị biên của miền giá trị Inputs để thiết kế testcase do “lỗi thường tiềm ẩn tại các ngõ ngách và tập hợp tại biên” Tiết kiệm thời gian thiết kế testcase và thực hiện test

Nhược điểm: Phương pháp này chỉ hiệu quả trong trường hợp các đối số đầu vào (input variables) độc lập với nhau và một đối số đều nằm trong miền giá trị hữu hạn

 Kỹ thuật đoán lỗi (Error Guessing)

Phương pháp này không có quy trình cụ thể vì có tính trực giác cao và không thể

 Kỹ thuật bảng quyết định (Decision Table)

Là phương pháp chính xác và tối ưu để mô hình hóa các điều kiện logic phức tạp Điều kiện là các biểu thức rút ra từ việc rẽ nhánh trong chương trình, như lệnh if, while, switch…

Cấu trúc của bảng quyết định như sau:

Các điều kiện (nguyên nhân) Các giá trị của các trường hợp

Mối liên hệ giữa các điều kiện tương ứng với các kết quả sẽ cho biết hành động nào sẽ được thực hiện khi các điều kiện tương ứng thỏa mãn

Các bước để xây dựng bảng điều kiện – kết quả:

1 Xác định tất cả các điều kiện từ yêu cầu

2 Xác định tất cả các giá trị có thể có của các điều kiện

3 Xác định kết hợp giữa các điều kiện

4 Điền các kết hợp (rule) vào bảng

5 Loại bỏ các kết quả không cần thiết (Xung đột, hoặc dư thừa)

6 Điền các hành động vào bảng tương ứng với từng trường hợp

Bảng điều kiện – kết quả có nhiều loại, trong đó phổ biến và đơn giản nhất là bảng điều kiện – kết quả giới hạn (Limitted Entry Table) Với bảng điều kiện – kết quả kiểu này, điều kiện (condition) được thỏa mãn một cách đầy đủ và hành động (action) được thực hiện một cách trọn vẹn nhất

Các ký hiệu dùng để mô tả trong bảng quyết định:

Y: Điều kiện thỏa mãn

N: Điều kiện không thỏa mãn

-: Điều kiện hoặc hành động không áp dụng

X: Hành động được thực hiện

1.7 Kiểm thử tự động

1.7.1 Kiểm thử tự động là gì? Quy trình kiểm thử tự động

Kiểm thử tự động là quá trình xử lý một cách tự động các bước thực hiện các test case Kiểm thử tự động bằng một công cụ nhằm rút ngắn thời gian kiểm thử

Qui trình kiểm thử tự động gồm 4 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 ra test script

• Bước 2: Chỉnh sửa để kịch bản kiểm thử thực hiện kiểm tra 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 của 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

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

Các ưu điểm có thể kể đến của kiểm thử tự động là:

• Kiểm thử chính xác và có thể bao quát thông tin

• Theo dõi được chính xác kết quả từng giai đoạn và các báo cáo tổng hợp

• Cần ít nhân lực trong quá trình kiểm thử

• Chu kỳ kiểm thử diễn ra trong thời gian ngắn

• Hiệu năng của kiểm thử các lớp vượt xa tầm với của kiểm thử thủ công

Tuy nhiên không thể không kể đến các nhược điểm của kiểm thử tự động:

• Chi phí cao cho việc chuyển giao công nghệ và đào tạo nhân viên

• Tốn chi phí đầu tư lớn cho việc phát triển công cụ kiểm thử tự động

• Tốn chi phí và thời gian cho việc tạo các kịch bản kiểm thử và bảo trì các kịch bản kiểm thử

• Giai đoạn chuẩn bị kiểm thử yêu cầu nhiều nhân lực

• Khu vực kiểm thử tự động có thể không bao quát đầy đủ, không áp dụng được trong việc tìm lỗi mới của phần mềm

1.7.3 Các trường hợp nên áp dụng kiểm thử tự động

Không phải lúc nào cũng nên áp dụng kiểm thử tự động trong việc kiểm thử phần mềm, vì nhiều khi chi phí và thời gian cho việc kiểm thử tự động còn lớn hơn nhiều so với kiểm thử thủ công Dưới đây là một số trường hợp nên áp dụng phương pháp kiểm thử tự động để đạt được hiệu quả cao về thời gian, chi phí cũng như chất lượng

Trường hợp không đủ tài nguyên: Là khi số lượng trường hợp kiểm thử lặp lại

quá nhiều trên nhiều môi trường kiểm thử khác nhau, không có đủ nguồn nhân lực để kiểm thử thủ công trong một giới hạn thời gian nào đó

Trường hợp kiểm thử hồi qui: Trong quá trình phát triển phần mềm, nhóm lập

trình thường đưa ra nhiều phiên bản phần mềm liên tiếp để kiểm thử Thực tế cho thấy việc đưa ra các phiên bản phần mềm có thể là hàng ngày, mỗi phiên bản bao gồm những tính năng mới, hoặc tính năng cũ được sửa lỗi hay nâng cấp Việc bổ sung hoặc sửa lỗi mã chương trình cho những tính năng ở phiên bản mới có thể làm cho những tính năng khác đã kiểm tra tốt chạy sai mặc dù phần mã chương trình của nó không hề chỉnh sửa Để khắc phục điều này, đối với từng phiên bản, kiểm thử viên không chỉ kiểm tra chức năng mới hoặc được sửa, mà phải kiểm tra lại tất cả những tính năng đã

kiểm tra tốt trước đó Điều này khó khả thi về mặt thời gian nếu kiểm thử thủ công

Trường hợp kiểm thử khả năng vận hành phần mềm trong môi trường đặc biệt: Đây là kiểm thử nhằm đánh giá xem vận hành của phần mềm có thỏa mãn yêu

cầu đặt ra hay không Thông qua đó kiểm thử viên có thể xác định được các yếu tố về phần cứng, phần mềm ảnh hưởng đến khả năng vận hành của hệ thống Có thể liệt kê một số tình huống kiểm tra tiêu biểu thuộc loại này như sau:

 Đo tốc độ trung bình xử lý một yêu cầu của web server

 Thiết lập 1000 yêu cầu, đồng thời gửi đến web server để kiểm tra tình huống

1000 người dùng truy xuất web cùng lúc

 Xác định số yêu cầu tối đa được xử lý bởi web server hoặc xác định cấu hình máy thấp nhất mà tốc độ xử lý của phần mềm vẫn có thể hoạt động ở mức cho phép

CHƯƠNG 2: KIỂM THỬ ỨNG DỤNG WEB

2.1 Kiểm thử ứng dụng web

2.1.1 Khái quát

Các ứng dụng web đã được phát triển và trở thành một nền tảng kết nối thông tin thiết yếu trong nhiều doanh nghiệp Các ứng dụng web đóng vai trò quyết định của thương mại điện tử, trao đổi thông tin Để có thể đạt được điều này, các ứng dụng web cần phải có hiệu năng cao, đáng tin cậy Việc đưa ra một ứng dụng web hoàn hảo cho những người đã và sẽ sử dụng đã trở thành một thách thức chính trong đảm bảo chất lượng Kiểm thử là một trong những công việc quan trọng để đánh giá chất lượng của một sản phẩm và đương nhiên là các ứng dụng Web cũng phải là một ngoại lệ Các phương pháp kiểm thử thông thường là kỹ thuật tập trung vào đánh giá các chức năng yêu cầu của ứng dụng Tuy nhiên, không thể tập trung hết được vào các chức năng yêu cầu của ứng dụng Bởi có rất nhiều tính năng quan trọng cho người sử dụng ứng dụng như: tính hiệu năng, tính dễ sử dụng, độ tin cậy và tính bảo mật cần được xem xét Những yêu cầu và mong đợi của người sử dụng, những vấn đề về nền tảng và cấu hình, mô hình nghiệp vụ, sự phát triển và chi phí cho việc kiểm thử là những vấn đề thường hay gặp phải và xuyên suốt trong một chu trình của một ứng dụng Web Vì thế, cần thiết phải phát triển một chiến lược hiệu quả cho việc kiểm thử mà có thể bao quát được giới hạn tổng thể và rộng lớn của những yêu cầu, chức năng cho một ứng dụng Web qua đó có thể giúp cho việc cài đặt, hoàn thành ứng dụng cũng như tránh được các rủi ro có thể gặp

2.1.2 Đặc điểm về chất lượng của một ứng dụng Web

Người sử dụng không chỉ mong đợi chương trình của họ sẽ vận hành một cách ổn định, chính xác mà họ còn yêu cầu một số chức năng nào đó phải luôn sẵn sàng trên 24 giờ trong 1 ngày và 7 ngày trong tuần Hơn nữa, người sử dụng còn mong đợi chương trình ở những ưu điểm sau: tính dễ sử dụng, độ tin cậy, tốc độ, tương thích với các hệ thống khác nhau và tương thích với các phiên bản trong tương lai Còn với một ứng dụng Web, thì những yêu cầu về chất lượng bao gồm:

• Yêu cầu về chức năng: Sự hiện diện của các chức năng đáp ứng những yêu cầu được xác định Các yêu cầu cần có nữa là tính phù hợp, chính xác, khả năng tương tác, tuân thủ và bảo mật

• Yêu cầu về độ tin cậy: Khả năng của một ứng dụng để duy trì sự hiệu quả của

nó trong một điều kiện cụ thể và trong một thời gian xác định

• Yêu cầu về khả năng sử dụng: Tính dễ sử dụng và hiểu quả của một ứng dụng Vấn đề này có thể được thẩm định bởi một nhóm người dùng giả định

• Yêu cầu về hiệu quả: Tỉ lệ giữa mức độ hiểu quả của một ứng dụng và các tài nguyên mà nó sử dụng trong các điều kiện cụ thể

Các yêu cầu về chất lượng đóng vai trò thiết yếu khi thử nghiệm các ứng dụng Web Mặc dù nhìn chung thì chúng tương tự như những yêu cầu về chất lượng cho các

hệ thống phần mềm truyền thống Tuy nhiên chúng có thể có mức độ đòi hỏi cao hơn

về chiều sâu

Do ý nghĩa quan trọng của các đặc điểm về chất lượng và sự khác biệt ở cách mà chúng được kiểm thử, nhiều phương pháp để kiểm thử một ứng dụng Web tập trung vào một vài đặc điểm Tuy nhiên, tất cả các đặc điểm đều quan trọng đối với một ứng dụng Web Và công việc kiểm thử phải đảm bảo được những yêu cầu cài đặt thành công

2.2 Công việc khi kiểm thử một ứng dụng web

Kiểm thử là một hoạt động để đánh giá chất lượng của hoạt động sản phẩm phần mềm, quan trọng là tìm ra những hoạt động thiếu xót, khiếm khuyết Một vấn đề thường hay xảy ra trog quá trình phát triển ứng dụng Web đó là các yêu cầu thường không đầy đủ, tường minh và có thể thay đổi bất cứ lúc nào Thông thường chúng ta cần có cái nhìn khái quát về các chức năng cơ bản mà các ứng dụng Web sẽ có “Cái nhìn khái quát” này sẽ là tầm nhìn để thực hiện phát hành lần đầu ứng dụng

Phương pháp tiếp cận nhanh tập trung vào tính chất lặp và tiến hóa của một ứng dụng Web và vòng đời phát triển của chúng mà không hề có bất cứ một đoạn văn bản

cụ thể nào định nghĩa về phương pháp này Các mục tiêu, mối quan tâm, và mong đợi của các bên liên quan có thể hình thành cơ sở cho việc thực nghiệm

Để hỗ trợ cho những kiểm thử viên có cái nhìn sâu sắc và thấu đáo những mong đợi, kỳ vọng về chất lượng của một ứng dụng Web của người sử dụng thì những kiểm

thử viên này cần được tham gia càng sớm càng tốt vào công việc xác định và định nghĩa các yêu cầu theo phương pháp kĩ thuật sau:

2.2.1 Kiểm tra chức năng (hồi quy, tích hợp, kiểm tra khói)

Kiểm tra các trang Web cho chức năng chính xác, định dạng, tập tin cookie và xác nhận dữ liệu Chức năng thử nghiệm là lý tưởng để kiểm tra khói, kiểm tra hồi quy

và kiểm tra hội nhập

 Kiểm tra các liên kết

Liên kết bên trong một cấu trúc siêu văn bản mà điểm đến không tồn tại một nút (các trang web, hình ảnh ) gọi là liên kết hỏng thường xuyên xảy ra sai xót trong các ứng dụng Web Để kiểm tra tính chính xác của các trang liên kết (link kiểm tra), tất cả các liên kết được hệ thống theo sau bắt đầu trên một trang bắt đầu, và sau đó được nhóm trong một đồ thị liên kết (bản đồ trang web) Khi chạy một kiểm tra liên kết thường xuyên, người ta thường thấy các liên kết không chỉ là điểm đến không tồn tại trang, nhưng cũng có các trang không được interlinked với các trang khác và được gọi

là trang mồ côi Những trang mồ côi có thể đến thông qua một liên kết, nhưng không

có một liên kết đến cấu trúc siêu văn bản Để đơn giản cho người sử dụng, nó không xác định nơi để đi tới, để chúng rời bỏ trang Web

Ngoài ra, khi vượt qua các liên kết, người ta có thể tìm thấy dữ liệu bổ sung để cung cấp chỉ dẫn tiềm năng lỗi Ví dụ, độ sâu và bề rộng của các cơ cấu chuyển hướng, khoảng cách giữa hai trang liên quan, được đo bằng số lượng các trang liên kết hoặc lần tải của các trang

 Kiểm tra các hình thức Web trên trang

• Kiểm tra các lĩnh vực logic xác định cho từng lĩnh vực

• Kiểm tra các giá trị mặc định cho từng lĩnh vực

• Kiểm tra xem các lĩnh vực mật khẩu không hiển thị nội dung mật khẩu

• Kiểm tra giá trị đầu vào không hợp lệ cho từng lĩnh vực

• Xác nhận đáp ứng với mọi hình thức gửi

 Thử nghiệm quản lí phiên bản làm việc và cookie

• Kiểm tra các ứng dụng đăng nhập trong phiên bằng cách cho phép và vô hiệu hóa các tập tin cookie

• Cookie sử dụng tiêu cực bằng cách sử dụng một tên miền không khớp

• Kiểm tra xem phiên cookie thiết lập lại giữa các phiên trình duyệt

• Kiểm tra các bảo mật ứng dụng bằng cách xóa các tập tin cookie có chọn lọc trong khi kiểm tra hoạt động

 Xác nhận Cascading Style Sheet (CSS) tags

• Xác nhận các tag CSS 404 trả lại hoặc lỗi tải khác CSS

• Xác định trên HTML id, class và các thuộc tính tên không phù hợp với bất kì thẻ CSS nào

 Xác nhận thẻ JavaScript

• Xác nhận các tag script trả lại lỗi 404 hoặc lỗi tải khác

• Xác định id, tên trên thuộc tính không phù hợp với bất kì thẻ script nào

 Kiểm tra nội dung động

• Kiểm tra cơ sở dữ liệu thống nhất trong các hình thức Web cơ sở dữ liệu theo định hướng

• Kiểm tra chức năng tạo, chỉnh sửa, xóa, chỉnh sửa công việc

• Kiểm tra dữ liệu cung cấp dữ liệu chính xác

• Xác định kết nối cơ sở dữ liệu và các lỗi truy vấn

2.2.2 Kiểm tra sự tương thích trình duyệt

Sự khác biệt trong các trình duyệt Web, môi trường hoạt động và các thiết bị phần cứng ảnh hưởng đến các hoạt động chính xác của ứng dụng Web của bạn

 Trình duyệt tương thích

• Thử nghiệm ứng dụng Web của bạn cho chức năng chính xác trên một số trình duyệt như Firefox, IE, Chrome, Opera và Safari Lý tưởng nhất là ứng dụng Web của bạn xử lý sự khác biệt trình duyệt thanh lịch

• Kiểm tra chức năng ứng dụng với một loạt các cài đặt cấu hình bảo mật trình duyệt

• Kiểm tra chức năng ứng dung với các tính năng trình duyệt bật-tắt (javascript, cookies)

• Kiểm tra dựng hình trình duyệt của giao diện người dùng ứng dụng của bạn

• Kiểm tra các thiết lập bảo mật của trình duyệt cho tên miền chéo truy cập và hack

• Kiểm tra chức năng ứng dụng nhất quán trên nhiều phiên bản của một trình duyệt

 Môi trường hoạt động tương thích

• Kiểm tra ứng dụng giao diện người dùng vẽ trên hệ thông cửa sổ hệ điều hành

• Kiểm tra chức năng tích hợp máy tính để bàn, bao gồm kéo và thả tập tin lựa chọn

• Thử dụng ứng dụng web của bạn trên các hệ điều hành khác nhau bao gồm cả Window, Unix, Mac, Linux, và Solaris

• Kiểm tra phản ứng máy chủ để dưới dạng trình duyệt gửi yêu cầu

• Xác định thay đổi hoạt động trong một khoảng thời gian

• Thử nghiệm cho các chức năng mà ngừng làm việc ở các cấp độ cao hơn của người sử dụng tải

• Xác định các vấn đề về độ trễ mạng về chức năng ứng dụng Web

 Stress test

• Xác định cách thức ứng dụng đáp ứng theo mức độ tải

• Xác định các thành phần của ứng dụng web mà không theo mức độ tải

• Xác định các chức năng ứng dụng sau khi một vụ tai nạn hệ thống hoặc thành phần thất bại

• Xác định các hình thức và các liên kết hoạt động khác nhau theo mức độ tải

2.2.4 Kiểm tra bảo mật

• Bảo vệ dữ liệu ứng dụng Web và duy trì chức năng như thiết kế

• Kiểm tra các hoạt động mà không cần logging

• Kiểm tra xác thực cơ bản sử dụng tên giả và các thông tin mật khẩu

• Kiểm tra giấy chứng nhận X.509 an ninh an toàn trên các trang web

• Thử nghiệm cho các chức năng ứng dụng chính xác dựa trên các giá trị thuộc tính không hợp lệ URL

• Kiểm tra các chức năng ứng dụng với các lĩnh vực đầu vào không hợp lệ, bao gồm các lĩnh vực văn bản

• Kiểm tra bảo vệ máy chủ Web của các thư mục web không thể truy cập hoặc các tập tin

• Kiểm tra để xác nhận ứng dụng web vi phạm an ninh, bao gồm cả thông báo lỗi và vi phạm an ninh nỗ lực đang được đăng nhập

• Kiểm tra các lĩnh vực CAPTCHA cho các hình thức web và đăng nhập

• Kiểm tra các thiết lập bảo mật trình duyệt để di chuyển từ an toàn vào các trang web không an toàn

2.2.5 Giám sát sản xuất

• Vận hành thử nghiệm ứng dụng web theo định kì và lưu các bản ghi kiểm tra như là bằng chứng của hiệp định cấp Servlice (SLA) tuân thủ

• Định kì kiểm tra kinh nghiệm người dùng cuối cùng

• Cung cấp tự động mở rộng quy mô và hệ thống cân bằng tải với cuối số liệu kinh nghiệm người dùng

• Kiểm tra các chức năng ứng dụng đúng từ nhiều vị trí địa lí

2.2.6 Kiểm tra khả năng sử dụng

Việc thiết kế và khả năng trình bày của một ứng dụng có ảnh hưởng lớn đến thành công người dùng của bạn sẽ có trong việc sử dụng các ứng dụng Web

 Kiểm tra đối với danh mục chính

• Kiểm tra người sử dụng có kiểm soát rõ ràng và dễ di chuyển từ trang này sang trang

• Kiểm tra dòng chảy của một ứng dụng web bằng cách quan sát cách người sử dụng hoàn thành mục tiêu của họ

• Kiểm tra xem người dùng có thể tìm thấy hướng dẫn nên họ không trực giác biết làm thế nào để vận hành một chức năng

• Kiểm tra các đối tượng chuyển hướng chung xuất hiện trên tất cả các trang luôn

• Chức năng tìm kiếm thử nghiệm cho các chức năng ứng dụng thích hợp