Nghiên cứu về kiểm thử mô hình ứng dụng Web

Ví dụ một vài ca kiểm thử bị bỏ qua hoặc gặp phải lỗi người kiểm thử không thể biết được các hoạt động được thực hiện để ghi lại những vấn đề và lỗi đó, ngoài ra việc kiểm thử thủ công c

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

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

NGUYỄN VIỆT ANH

NGHIÊN CỨU VỀ KIỂM THỬ

MÔ HÌNH ỨNG DỤNG WEB

LUẬN VĂN THẠC SĨ

Hà nội - 2012

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

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

NGUYỄN VIỆT ANH

NGHIÊN CỨU VỀ KIỂM THỬ

MỤC LỤC

LỜI CẢM ƠN i

LỜI CAM ĐOAN iv

MỤC LỤC v

DANH SÁCH BẢNG BIỂU vii

DANH MỤC CÁC HÌNH VẼ viii

BẢNG KÝ HIỆU CÁC CHỮ VIẾT TẮT x

CHƯƠNG 1 ĐẶT VẤN ĐỀ 1

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

1.2 Mục đích và nội dung nghiên cứu 2

1.3 Cấu trúc của luận văn 2

CHƯƠNG 2 CƠ SỞ LÝ THUYẾT 3

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

2.1.1 Khái niệm kiểm thử 3

2.1.2 Vòng đời và quy trình kiểm của việc kiểm thử 3

2.1.3 Kiểm thử hộp trắng 4

2.1.4 Kiểm thử hộp đen 8

2.1.5 Kiểm thử tích hợp 10

2.2 Kiểm thử mô hình ứng dụng Web 12

2.2.1 Ứng dụng Web là gì? 12

2.2.2 Các thành phần của ứng dựng Web 12

2.2.3 So sánh kiểm thử Web và kiểm thử truyền thống 13

2.2.4 Các kiểm thử cho ứng dụng Web 15

CHƯƠNG 3 BÀI TOÁN VÀ GIẢI PHÁP 30

3.1 Mô tả yêu cầu bài toán 30

3.2 Giải pháp giải quyết bài toán 30

3.2.1 Đầu vào cho ứng dụng kiểm thử 32

3.2.2 WebDriver 33

3.2.3 Giải pháp ghi lại kết quả đầu ra 35

CHƯƠNG 4 THỰC NGHIỆM 38

4.1 Cài đặt môi trường kiểm thử 38

4.2 Xây dựng chương trình kiểm thử tự động đăng nhập ứng dụng Web 39

4.3 Các bước thực hiện kiểm thử tự động 43

4.4 Kết quả thực nghiệm 45

4.5 Ý nghĩa chương trình kiểm thử tự động 48

CHƯƠNG 5 KẾT LUẬN 49

TÀI LIỆU THAM KHẢO 50

PHỤC LỤC 51

Phụ lục A Chương trình kiểm thử đăng nhập tự động ứng dụng Web 51

Phụ lục B Trường hợp kiểm thử đăng bài viết mới 54

Phụ lục C Trường hợp kiểm thử với Ẩn/Hiện bài viết 56

Phụ lục D Một số hàm API khác 57

DANH SÁCH BẢNG BIỂU

Bảng 2.1 Đánh giá yêu tố người dùng 16

Bảng 3.2: Lựa chọn phương pháp kiểm thử 20

Bảng 4.2 Môi trường thực nghiệm 38

Bảng 4.3 Chương trình hỗ trợ kiểm thử 38

Bảng 4.4 Môi trường WebDriver 39

DANH MỤC CÁC HÌNH VẼ

Hình 2.1 Vòng đời kiểm thử[3] 3

Hình 2.2 Sơ đồ khối chu trình điều khiển 5

Hình 2.3 Đồ thị thuật toán (a), Đồ thị luồng(b) 6

Hình 2.4 Độ phức tạp Cyclomatic 7

Hình 2.5 Kiểm thử hộp đen 9

Hình 2.6 Kiểm thử Top-Down 11

Hình 2.7 Kiểm thử tích hợp dưới lên 11

Hình 2.8 Hệ thống ứng dụng Web 3 tầng 12

Hình 2.9 Mô hình ứng dụng cho Hệ thống máy tính 14

Hình 2.10 Các hệ thống Client – Server 14

Hình 2.12 Tính nhất quán trong phương pháp thiết kế 16

Hình 2.13 Ứng dụng hiển thị trên IE 7 17

Hình 2.14 Ứng dụng hiển thị trên IE 8 17

Hình 2.15 Các lớp ODBC 22

Hình 2.16 Tường lửa 25

Hình 2.17 Thời gian chấp nhận được của ứng dụng 27

Hình 2.18 Sự mất mát trong kinh doanh do thời gian đáp ứng gây ra 27

Hình 2.19 Mô hình thành phần giao tác nguồn tài nguyên 28

Hình 2.20 So sánh trên trình duyệt IE và thiết bị di động 29

Hình 3.1 Mô hình giải quyết bài toán 31

Hình 3.2 Quá trình thực thi 31

Hình 3.3: Kiểm thử chức năng tạo bài viết 32

Hình 3.4: Tệp tin mô tả kiểm thử việc đăng bài viết tự động 32

Hình 3.5: Mô hình hóa trực quan các trường hợp kiểm thử 33

Hình 3.6: Định vị By Id 34

Hình 3.7: Định vị Name 34

Hình 3.8: Định vị By Xpath 34

Hình 4.1 Giao diện trang chủ 39

Hình 4.2 Giao diện đăng nhập 39

Hình 4.3 Màn hình đăng nhập thành công 40

Hình 4.4 Bảng trạng thái tương ứng 40

Hình 4.5 Mô hình trạng thái trực quan 40

Hình 4.6 Mô tả quy trình với trường hợp không nhập User và Pass 41

Hình 4.7 Mô tả quy trình với trường hợp không nhập User và không nhập Pass 42

Hình 4.8 Mô tả quy trình với trường hợp không nhập Pass và không nhập User 42

Hình 4.9 Mô tả quy trình với trường hợp nhập User và Pass 43

Hình 4.10 Mô tả quy trình với trường hợp không nhập Pass và nhập User 43

Hình 4.11 Quy trình ghi kết quả ra tệp tin XML 44

Hình 4.12 Quy trình ghi kết quả ra tệp tin Excel 44

Hình 4.13 Quy trình ghi xử lý việc kiểm thử ứng dụng Web 45

Hình 4.14 Kết quả ghi ra kiểm thử Login ghi ra tệp tin Excel 46

Hình 4.15 Trường hợp đăng nhập thành công 47

Hình 4.16 Trường hợp đăng nhập không thành công 47

V&V Kiểm chứng và xác nhận V&V(Verification and Validation)BVA Phân tích giá trị biên(Boundary Value Analysis)

DLL Thư viện liên kết động(Dynamic link library)

XML Ngôn ngữ đánh dấu mở rộng(Extensible Markup Language)

CHƯƠNG 1 ĐẶT VẤN ĐỀ 1.1 Lý do chọn đề tài

Những năm gần đầy công nghệ thông tin đã và đang đạt được những bước phát triển tích cực, cùng với sự phát triển mạnh mẽ của cơ sở hạ tầng đặc biệt là hệ thống mạng Internet Những ứng dụng Web phổ biến nhờ vào sự có mặt bất cứ nơi đâu của một chương trình Khả năng cập nhật và bảo trì ứng dụng Web mà không phải phân phối và cài đặt phần mềm trên hàng ngàn máy tính là lý do chính cho sự phổ biến của

nó Chính nhờ vào sự phổ biến trên mà các ứng dụng Web giờ đây không chỉ là những ứng dụng đơn giản nữa, mà việc xây dựng các ứng dụng Web đã trở nên phức tạp hơn rất nhiều Các ứng dụng Web được dùng để thực hiện bán hàng trực tuyến, đấu giá trực tuyến, quản trị quan hệ khách hàng,

Tuy nhiên để triển khai được các ứng dụng Web thì có rất nhiều vấn đề sẽ phát sinh và ảnh hưởng trực tiếp đến các ứng dụng Web như: Tính bảo mật, hiệu suất, các thành phần của ứng dụng Web, giao diện, chức năng, khả năng tương thích của ứng dụng Web với trình duyệt và hệ điều hành,…

Vậy để đảm bảo chất lượng các ứng dụng Web hoạt động tốt và không có bất

kỳ vấn đề nào khi vận hành, thì cần phải đảm bảo tất cả các vấn đề trên đều được giải quyết một cách triệt để Muốn làm được điều đó ta phải thực hiện “Kiểm thử ứng dụng web”, đó cũng là các bước chính đảm bảo cho toàn bộ ứng dụng web hoạt động tốt hay không Và sau khi thực hiện các kiểm thử chúng ta có thể tìm ra những vấn đề phát sinh lỗi để có thể giải quyết trước khi đưa ứng dụng web vào sử dụng thực tế

Hầu hết công việc kiểm thử đều thực hiện một cách thủ công, vì vậy việc kiểm thử thủ công sẽ chỉ có thể tin cậy được khi ứng dụng web nhỏ và không có nhiều chức năng, còn khi ứng dụng Web trở nên phức tạp hơn có rất nhiều chức năng thì việc kiểm thử thủ công trên không còn đáng tin cậy và khả thi nữa Ví dụ một vài ca kiểm thử bị bỏ qua hoặc gặp phải lỗi người kiểm thử không thể biết được các hoạt động được thực hiện để ghi lại những vấn đề và lỗi đó, ngoài ra việc kiểm thử thủ công có thể tẻ nhạt và tốn thời gian (do thực hiện công việc lặp đi lặp lại, các chức năng có thể giống nhau) Chính vì vậy cần phải có một mô hình hoạt động một cách tự động để khắc phục những vấn đề gặp phải của kiểm thử thủ công Tuy nhiên trong thực tế để xây dựng một mô hình kiểm thử tự động không phải là công việc dễ dàng mà ngược lại nó rất khó khăn và luôn tiềm ẩn lỗi Mặc dù mô hình hệ thống đã có sẵn và hoàn chỉnh tuy nhiên không dám khẳng định rằng hoàn toàn đúng đắn vì các ứng dụng web luôn được thay đổi thêm bớt các hành vi hoạt động Ngoài ra còn một khó khăn nữa là khi thực hiện việc kiểm thử mà bên xây dựng ứng dụng và bên kiểm thử không phải là một nơi phát triển thì khi đó chúng ta không thể có mã nguồn và tài liệu thiết kế đầy

đủ thì việc kiểm thử cũng vô cùng khó khăn

Vì vậy, việc tìm hiểu nghiên cứu xây dựng mô hình ứng dụng web tự động không chỉ có ý nghĩa trong việc xây dựng một công cụ kiểm thử tự động mà còn mang

tính thực tế cao Do vậy, mà tôi đã quyết định chọn đề tài: “Nghiên cứu kiểm thử mô hình cho ứng dụng Web” để nghiên cứu

1.2 Mục đích và nội dung nghiên cứu

Trong nội dung của bài luận văn tôi tập trung vào việc nghiên cứu về kỹ thuật kiểm thử Và dựa trên những kiến thức về kỹ thuật kiểm thử sẽ tìm hiểu về kiểm thử ứng dụng Web Cuối cùng là xây dựng công cụ thực hiện việc kiểm thử tự động ứng dụng Web dựa trên công cụ mã nguồn mở Selenium và WebDriver

1.3 Cấu trúc của luận văn

Các phần còn lại của luận văn có cấu trúc như sau:

Chương 2 giới thiệu về khái niệm kiểm thử và các kỹ thuật kiểm thử thông thường, và cụ thể là kiểm thử hộp trắng, và kiểm thử hộp đen Dựa trên các kỹ thuật kiểm thử sẽ tập trung tìm hiểu về ứng dụng Web, thành phần ứng dụng Web và các kiểm thử đối với ứng dụng Web như: kiểm thử giao diện, kiểm thử chức năng, kiểm thử cơ sở dữ liệu, kiểm thử hiệu năng và kiểm thử với các thiết bị di động

Chương 3 yêu cầu bài toán về việc xây dựng công cụ kiểm thử tự động các ứng dụng Web Thông qua việc thực hiện trường hợp kiểm thử đăng nhập vào ứng dụng Web Công cụ kiểm thử tự động sẽ thực hiện việc đọc các trường hợp đầu vào từ tệp tin Excel, sau khi thực hiện việc kiểm thử chương trình ghi kết quả quá trình kiểm thử

ra tệp tin Excel, XML và chụp ảnh màn hình để xem việc kiểm thử là thành công hay thất bại Và để xây dựng công cụ trên giải pháp đưa ra đó là sử dụng các hàm API

được cung cấp bởi công cụ Selenium và WebDriver

Chương 4 thực hiện cài đặt ứng dụng Web và xây dựng các hàm API để thực

hiện việc kiểm thử, sau khi thực hiện chương trình đưa ra những kết quả đạt được trong quá trình xây dựng công cụ kiểm thử ứng dụng Web tự động

Chương 5 là Kết luận, hướng nghiên cứu

CHƯƠNG 2 CƠ SỞ LÝ THUYẾT 2.1 Các kỹ thuật kiểm thử

2.1.1 Khái niệm kiểm thử

Có rất nhiều các khái niệm khác nhau về thế nào là kiểm thử, tuy nhiên có một khái niệm về kiểm thử của (Glen Myers) được cho là tổng quát nhất: “Việc kiểm thử là

quá trình thực thi một chương trình với mục đích là tìm ra lỗi.” [5]

Nếu hiểu theo nghĩa mục đích của (Paul Jorgensen) thì việc thực hiện kiểm thử hiển nhiên là việc tìm lỗi (error), sai sót (fault), hỏng hóc (failure) Vì vậy kiểm thử là một cách chạy các ứng dụng theo các trường hợp kiểm thử với mục tiêu: Tìm ra sai sót

và giải thích sự hoạt động

2.1.2 Vòng đời và quy trình kiểm của việc kiểm thử

Mục đích chính của việc kiểm thử đó là thiết kết một chuỗi các trường hợp kiểm thử mà có khả năng phát hiện được lỗi cao Và để cho việc kiểm thử đạt được kết quả tốt nhất thì cần phải có sự chuẩn bị về kế hoạch kiểm thử, trải qua các công đoạn khác nhau đồng thời phải có những biện pháp để khắc phục khi phát hiện ra lỗi

Vòng đời của việc kiểm thử thông thường sẽ trải qua đó là: “Mô tả yêu cầu”,

“Phân tích thiết kế”, “Lập trình”, “Kiểm thử”, “Ban giao sản phẩm”

Mô hình của một đời kiểm thử:

Hình 2.1 Vòng đời kiểm thử[3]

Từ hình vẽ trên có thể thấy rằng lỗi có thể xảy ra ở từ các giai đoạn, “Mô tả yêu cầu”, “Phân tích thiết kế”, “Lập trình” Và việc chuyển từ giai đoạn này sang giai

cùng đến giai đoạn kiểm thử chúng ta sẽ phát hiện ra những sai sót và cụ thể là kết quả thu được không như mong đợi

2.1.3 Kiểm thử hộp trắng

Kiểm thử hộp trắng (White-Box Testing) hay còn gọi là kiểm thử logic, cho phép kiểm tra cấu trúc bên trúc bên trong của ứng dụng với mục đích đảm bảo rằng tất

cả các câu lệnh và điều kiện sẽ được thực thi ít nhất một lần

Kiểm thử hộp trắng đúng nghĩa là kiểm thử hộp trong suốt, vì vậy mà kiểm thử hộp trắng còn được gọi bằng một số tên khác đó là kiểm thử hộp thủy tinh (Glass-Box Testing) hay kiểm thử trong suốt (Clear-Box Testing) Người kiểm thử truy cập vào

mã nguồn chương trình để kiểm tra và lấy nó làm cơ sở cho việc kiểm thử Và việc kiểm thử này dựa trên quá trình thực hiện xây dựng chương trình ứng dụng

Kiểm thử hộp trắng còn là phương pháp kiểm thử dựa vào cấu trúc/mã lệnh của chương trình Phương pháp này cho phép kiểm thử một chương trình (một phần chương trình, hay một hệ thống, một phần của hệ thống) đáp ứng tất cả các giá trị đầu vào bao gồm cả các giá trị không đúng hay không theo dự kiến của chương trình

Khi nói đến vần đề kiểm thử hộp trắng cần quan tâm đến vấn đề đường dẫn lệnh trong kỹ thuật hay phương pháp này Nếu phải thực hiện tất cả các đường dẫn của

đồ thị điều khiển trong chương trình thông quan việc chạy tất cả các trường hợp kiểm thử thì có thể nói rằng chương trình đã được kiểm thử một cách triệt để Tuy nhiên, điều đó là không thể thực hiện được vì số đường dẫn logic khác nhau trong một chương trình là rất lớn

Ngoài những điều kiện không khả thi trên, chương trình còn có thể có rất nhiều lỗi

do các nguyên nhân khác gây ra.Và đây chính là nhược điểm của phương pháp kỹ thuật kiểm thử hộp trắng

- Việc kiểm thử bằng kỹ thuật hộp trắng không thể đảm bảo rằng chương trình đã tuân theo đặc tả

- Một chương trình bị sai do thiếu đường dẫn, việc kiểm thử hộp trắng không thể biết được sự thiếu sót này

- Việc kiểm thử bằng kỹ thuật hộp trắng không thể phát hiện được lỗi do dữ liệu gây ra

Như vậy nếu chỉ dùng kỹ thuật kiểm thử hộp trắng đế thực hiện việc kiểm thử

là không đủ để phát hiện các lỗi Vì vậy để thiết kế các trường hợp kiểm thử để cho việc kiểm thử triệt để thì cần phải kết hợp với kiểm thử hộp đen (Black-Box Testing)

Hình 2.2 Sơ đồ khối chu trình điều khiển

a) Kiểm thử theo đường dẫn

Kiểm thử đường dẫn (Basic Path Testing) là một kỹ thuật kiểm thử hộp trắng Phương pháp kiểm thử theo đường dẫn cho phép người thiết kế trường hợp kiểm thử thực hiện phép đo độ phức tạp logic của thiết kế thủ tục và sử dụng phép đo này như một chỉ dẫn cho việc thiết kế một tập cơ sở các đường dẫn thực hiện Các trường hợp kiểm thử đó được đảm bảo để thực hiện mỗi lệnh trong chương trình ít nhất một lần trong quá trình kiểm thử

Đồ thị luồng

Trong thực tế phương pháp kiểm thử đường dẫn có thể được dùng mà không cần đồ thị luồng (Flow Graph) Tuy nhiên, đồ thị luồng là một công cụ hữu ích để hiểu được luồng điều khiển và minh họa phương pháp tiếp cận Trong phần này sẽ trình bày những thành phân cơ bản cấu thành nên đồ thị luồng, và mỗi cấu trúc điều khiển tương

ứng có một ký hiệu đồ thị luồng tương ứng

Biểu diễn điều kiện phức trong đồ thị luồng

Điều kiện phức trong câu lệnh điều kiện được biểu diễn gồm một hoặc nhiều phép toán logic (AND, OR, NOT) và khi gặp phải điều kiện phức này cần phải được chia thành các điều kiện đơn trong thực hiện kiểm thử đường dẫn cơ sở Mỗi đỉnh chứa

điều kiện gọi là đỉnh điều kiện và đặc trưng bởi hai hoặc nhiều cạnh bắt nguồn từ nó

Ngoài ra từ đồ thi thuật toán chuẩn đổi sang đồ thị luồng, ở trong ví dụ sau đấy

từ đồ thị thuật toán 2.6 (a) sẽ được chuyển thành đồ thị lường 2.6 (b)[3]

Hình 2.3 Đồ thị thuật toán (a), Đồ thị luồng(b)

Độ phức tạp cyclomatic

Độ phức tạp Cyclomatic được gọi là thước đo của chương trình ứng dụng, cung cấp phép đo định lượng độ phức tạp của chương trình Khi được sử dụng trong ngữ cảnh của phương pháp kiểm thử đường dẫn cơ sở, giá trị được xác định độ phức tạp Cyclomatic cho phép số lượng đường dẫn độc lập trong một tập cơ sở của chương trình và cung cấp một giới hạn trên số lượng kiểm thử bắt buộc để đảm bảo rằng tất cả các câu lệnh đều được thực hiện ít nhất một lần

Vậy đường dẫn độc lập ở đây được hiểu là bất kỳ đường đường dẫn nào đi từ đầu đến cuối chương trình và xác định một tập hợp có thêm các lệnh mới hay một điều kiện (chưa xuất hiện trong đường dẫn trước đó)

Chúng ta có thể dễ dàng xác định được các đường dẫn động lập cho đồ thị luồng trong hình 2.6 (b):

1-2-3-4-5-10-1-2-Nếu các trường hợp kiểm thử được thiết kế để thực hiện những đường dẫn này thì mọi lệnh trong chương trình sẽ được đảm bảo thực hiện ít nhất một lần và mọi điều kiện sẽ được thực hiện cả hai trường hợp đúng (true) và sai (false) Tuy nhiên, tập cơ

sở đường dẫn không phải là duy nhất Vì trong thực tế, một số các tập cơ sở khác nhau

có thể suy diễn cho việc thiết kế một thủ tục được đưa ra

Và theo một số nghiên cứu đã chỉ ra rằng độ phực tạp Cyclomatic càng cao thì

xác suất lỗi càng cao [3]

Hình 2.4 Độ phức tạp Cyclomatic

Một số đặc điểm của độ phức tạp Cyclomatic:

- Là số đường dẫn độc lập trong tập các đường dẫn cơ bản của chương trình

- Giá trị này được xem như cận trên của số lần kiểm thử cần được thực hiện để đảm bảo tất cả các câu lệnh được thực hiện ít nhất một lần

Chính vì vậy việc tính toán độ phức tạp Cyclomatic rất quan trọng sẽ giúp cho chúng ta biết có bao nhiêu đường dẫn cần tìm Giả sử có đồ thị G, độ phức tạp Cyclomatic V(G) sẽ được tính theo 3 cách sau đây:

1 V(G) = R, R là số vùng của đồ thị luồng

2 V(G) = P + 1, P là số đỉnh điều kiện có trong đồ thị luồng G

3 V(G) = E – N + 2, E là số cạnh của đồ thị, N là số đỉnh của đồ thị

Để hiểu rõ hơn về độ phức tạp của đồ thị luồng, quay lại hình vẽ 2.6 (b) chúng

ta thực hiện tính độ phức tạp Cyclomatic như sau:

1 V(G) = 4, Có 4 vùng

2 V(G) = 3 + 1 = 4, có 3 đỉnh điều kiện

3 V(G) = 11 – 9 + 2 = 4, Có 11 cạnh, 9 đỉnh

Vậy độ phức tạp trong độ thì luồng hình 2.6 (b) là 4

b) Kiểm thử cấu trúc điều khiển

Ở trên chúng ta đã hiểu được kiểm thử đường dẫn cơ sở là phương pháp đơn giản và hiệu quả Tuy nhiên nếu chỉ sử dụng kiểm thử đường dẫn cơ sở thì chưa đủ được vì vậy chúng ta cần xem xét các biến thể trên kiểm thử cấu trúc điều khiển mà có khả năng phủ kiểm thử mở rộng và hoàn thiện chất lượng của kỹ thuật kiểm thử hộp trắng

Kiểm thử điều kiện (Condition Testing): là phương pháp thiết kế trường hợp

kiểm thử thực thi các điều kiện logic trên 2 giá trị true và false

Kiểm thử luồng điểu khiển (Control Flow Testing): là một phương pháp kiểm

thử của kiểm thử hộp trắng tạo ra một bộ giá trị bao phủ toàn bộ những trường hợp có thể xảy ra với các thành phần của một chương trình Kiểm thử luồng điều khiển bao gồm:

- Phương thức (Method)

- Cậu lệnh (Statement)

- Nhánh (Branch)

- Điều kiện (Condition)

Kiểm thử luồng dữ liệu: Phương pháp kiểm thử luồng dữ liệu (Data Flow

Testing) lựa chọn các đường dẫn kiểm thử của chương trình dựa vào vị trí khai báo và

sử dụng các biến trong chương trình Với kiểm thử luồng dữ liệu mỗi câu lệnh được gán một số hiệu duy nhất và mỗi hàm khi thực hiện không thay đổi tham số và biến

toàn cục

Kiểm thử vòng lặp: Vòng lặp là cấu trúc cơ bản của cho hầu hết các giải thuật,

tuy nhiên chúng ta thường ít quan tâm đến nó khi thực hiện kiểm thử ứng dụng Kiểm thử vòng lặp (Loop Testing) là một kỹ thuật của kiểm thử hộp trắng được dùng để

kiểm thử tính hợp lệ của cấu trúc lặp

2.1.4 Kiểm thử hộp đen

Kiểm thử hộp đen (Black – Box Testing) hay còn gọi là kiểm thử chức năng,

việc thực hiện kiểm thử này không cần quan tâm đến thiết kế và mã nguồn chương trình Kiểm thử hộp đen chỉ quan tâm đến các chức năng của ứng dụng đã được đề ra

Vì vậy kiểm thử loại này chỉ cần dựa vào bản mô tả chức năng của chương trình, xem chương trình có thực sự cung cấp đúng chức năng đã mô tả trong bản chức năng hay không?

Ngoài ra kiểm thử hộp đen còn được hiểu là kiểm thử hướng dữ liệu (data – driven) hay kiểm thử hướng vào ra (input/output driven) Và với khái niệm này thì người kiểm thử coi ứng dụng như một chiếc hộp đen, có nghĩa là không quan tâm đến cấu trúc và hoạt động bên trong của chương trình Kiểm thử hộp đen cho phép các kỹ thuật viên kiểm thử xây dựng các nhóm dữ liệu đầu vào mà sẽ thực thi đầy đủ các yêu cầu chức năng của chương trình

Tuy nhiên, kiểm thử hộp đen không phải là một kỹ thuật thay thế cho kỹ thuật kiểm thử hộp trắng mà là một phương pháp bổ sung giúp phát hiện các loại lỗi khác nhau của phương pháp kiểm thử hộp trắng

Kiểm thử hộp đen thực hiện các trường hợp kiểm thử để cố gắng tìm ra các loại lỗi sau:

- Thiếu hoặc sai chức năng

- Lỗi cấu trúc dữ liệu hay dữ liệu bên ngoài

- Lỗi giao diện

- Lỗi bắt đầu hay kết thúc chương trình

- Lỗi thực thi chương trình

Khác với kiểm thử hộp trắng thường được thực thi rất sớm để phát hiện lỗi, còn với kiểm thử hộp đen thường thực thi sau cùng vì nó không quan tâm đến cấu trúc điều khiển mà chỉ tập trung vào miền thông tin Nếu như mong muốn sử dụng phương pháp này để tìm ra tất cả các lỗi trong chương trình thì điểu kiện bắt buộc là phải kiểm thử tất cả các giá trị đầu vào, bởi vì nếu chỉ kiểm thử một giá trị đầu vào thôi thì không dám đảm bảo chương trình có lỗi hay không Tuy nhiên, điều này trong thực tế là không thể thực hiện được

Hình 2.5 Kiểm thử hộp đen

a) Phân chia tương đương

Như trình bày ở trên về kiểm thử hộp đen, muốn thực hiện kiểm thử tất cả đầu vào là điều không thể thực hiện được Chính vì vậy mà cần phải thực hiện việc phân chia (nếu có thể) các lớp đầu vào để tạo ra một tập hợp các đầu vào nếu có thể Phân chia tương đương sẽ bao gồm hai tính chất:

- Mỗi trường hợp kiểm thử nên gồm nhiều điều kiện đầu vào khác nhau có thể để

giảm thiểu tổng số các trường hợp kiểm thử

- Nên cố gắng phân chia miền đầu vào của một chương trình thành một số xác định các lớp tương đương sao cho có thể giả định hợp lý rằng việc kiểm thử một giá trị đại diện của mỗi lớp là tương đương với việc kiểm thử một giá trị

bất kỳ của lớp đó

b) Phân tích giá trị biên (BVA – Boundary Value Analysis)

Các điều kiện biên là tình trạng trực tiếp ở phía trên và dưới của các lớp tương đương đầu vào và lớp tương đương đầu ra Việc phân tích giá trị biên khác với phương pháp phân chia tương đương ở hai điểm:

- Từ mỗi lớp tương đương, phân chia tương đương sẽ chọn phân tử bất kỳ làm phần tử đại diện, trong khi phân tich giá trị biên sử dụng một hoặc một số phần

tử Như vậy mỗi biên của lớp tương đương là đích của kiểm thử

- Không chú ý tập trung vào những điều kiện đầu vào, các trường hợp kiểm thử cũng được suy ra từ việc xem xét các kết quả ra (tức là các lớp tương đương đầu ra)

c) Kỹ thuật đồ thị nhân quả

Đồ thị nhân quả (Cause – Effect Graph) là một phương pháp giúp cho việc thiết

kế các trường hợp kiểm thử trên cơ sở đưa ra mô tả súc tích các điều kiện logic và các hành vi kèm theo

Đồ thị nhân qua sử dụng mô hình các quan hệ logic giữa nguyên nhân và kết quả cho thành phần chương trình Mỗi nguyên nhân được biểu diễn như một điều kiện (đúng hoặc sai) của một đầu vào, hoặc kết hợp với đầu vào Mỗi kết quả được biểu diễn như một biểu thức Bool biểu diễn kết quả tương ứng cho những thành phần vừa thực hiện

Đồ thị nhân – quả đƣợc tạo ra nhƣ sau:

- Tất cả nguyên nhân (các đầu vào) và các kết quả (các đầu ra) được liệt kê dựa trên đặc tả và được định danh cho mỗi nhân quả

- Các quan hệ giữa các nguyên nhân (đầu vào) và kết quả (đầu ra) được biểu diễn trong đồ thị làm rõ ràng các quan hệ logic

- Từ đồ thị nhân quả ta tạo ra bảng quyết định nguyên nhân và kết quả Và các dữ liệu kiểm thử được sinh ra trong các qui tắc của bảng này

2.1.5 Kiểm thử tích hợp

Chúng ta thường tự đặt ra câu hỏi là khi mọi module đã được kiểm thử đơn vị xong, nếu tất cả chúng đều làm việc tốt riêng biệt thì tại sao chúng ta lại hoài nghi khi kết hợp các module riêng biệt đó với nhau? Vậy vấn đề ở chỗ là khi chúng ta thực hiện gắn chúng với nhau và làm giao diện cho chúng, thì từ đây dữ liệu có thể mất qua giao diện, một module có thể gặp vần đề sẽ ảnh hưởng đến module khác, các chức năng con khi kết hợp lại không tạo ra một chính năng chính như mong muốn

Kiểm thử tích hợp là một kỹ thuật hệ thống xây dựng cấu trúc chương trình trong khi đồng thời tiến hành các kiểm thử để phát hiện lỗi liên kết với giao tiếp Mục đích là lấy các module đã được kiểm thử đơn vị xong và xây dựng nên một chương trình được quy định bởi thiết kế

a) Kiểm thử tích hợp từ trên xuống

Kiểm thử tích hợp trên xuống (Top-Down) là tiếp cận tằng dần tới việc xây dựng cấu trúc chương trình Các module được tích hợp bằng cách đi dần xuống qua các cấp bậc điều khiển, bắt đầu với module chính Các module phụ thuộc vào module chính sẽ được tổ hợp dẫn vào trong cấu trúc theo chiều sâu trước hoặc chiều rộng trước

Hình 2.6 Kiểm thử Top-Down

b) Kiểm thử tích hợp từ dưới lên

Kiểm thử tích hợp dưới lên (Bottom-Up) bắt đầu xây dựng và kiểm thử với các module nguyên tử (tức là các module ở mức thấp nhất trong chương trình) Chiến lược kiểm thử dưới lên được thực hiện qua các bước sau:

1 Các module ở mức thấp được kết hợp thành các nhóm (cluster)

2 Bộ điều khiển (chương trình điểu khiển cho việc kiểm thử) được viết để phối hợp các trường hợp kiểm thử đầu vào và đầu ra

2.2 Kiểm thử mô hình ứng dụng Web

2.2.2 Các thành phần của ứng dựng Web

Nếu chúng ta hiểu được các thành phần bên trong của một ứng dụng Web và sự giao tiếp của các thành phần đó hoạt động với nhau như thế nào thì sẽ giúp cho việc kiểm tử của chúng ta tốt hơn rất nhiều Thông thường chúng ta hiểu được kiến trúc của một ứng dụng Web thông qua việc đọc mã nguồn Và một cách khác nữa là phân tích

sự giao tiếp giữa các thành phần Tuy nhiên, chúng ta vẫn cần phải nắm được kiến trúc của ứng dụng Web ở mức độ thành phần để có thể biết được các loại lỗi cần tìm và các câu hỏi đặt ra

Hệ thống Client – Server: trên Web được nhóm thành ba tầng liên quan đến nhau: (1) các thành phần dịch vụ phía người dùng, (2) các thành phần dịch vụ xử lý, (3) các thành phần dịch vụ dữ liệu [5]

Hình 2.8 Hệ thống ứng dụng Web 3 tầng

Các thành phần phần mềm: Mỗi thành phần trong một hệ thống ứng dụng web

thì cung cấp một chức năng hay một nhóm các chức năng cụ thể có liên quan đến

nhau Thành phần phần mềm là ứng dụng tích hợp và các thành phần của hãng thứ ba, thành phần dịch vụ, hệ điều hành, và các dịch vụ ứng dụng (như trình chủ Web, cơ sở

dữ liệu SQL)

Các thành phần của hãng thứ ba: Ứng dụng Web được chia làm các thành phần

nhỏ hơn được gọi Unit hay Module Và các thành phần này bao gồm hai định dạng là

mã nguồn, nhị phân (như trong một DLL hay tệp lưu trữ JAR) Ngoài ra các thành phần của bên thứ ba còn gồm có: thành phần Java, điều khiển ActiveX,…

Thư viện liên kết động (DLL – dynamic link library): Khi chúng ta hiểu được

DLL và các lỗi tiềm tàng chúng ta sẽ thiết kế được trường hợp kiểm thử phù hợp

Trình chủ cơ sở dữ liệu: Được coi như những kho cơ sở dữ liệu phục vụ cho

trình chủ Web Các ứng dụng Web sử dụng trình chủ cơ sở dữ liệu quan hệ

Ngôn ngữ đánh dấu: HTML là ngôn ngữ đánh dấu chuẩn được sử dụng để tạo

ra các trang Web Còn XML định dạng dữ liệu chuẩn cho phép các hệ thống hỗ trợ XML có thể trao đổi với các hệ thống khác

2.2.3 So sánh kiểm thử Web và kiểm thử truyền thống

Khi thực hiện kiểm thử các ứng dụng Web chúng ta cần quan tâm đến các phương pháp phân tích và kiểm thử lỗi mới Giả sử như chúng ta đã nắm được hết các

kỹ thuật kiểm thử thông thường, vấn đề đặt ra lúc này là áp dụng các phương pháp hay

kỹ thuật đó vào việc kiểm thử ứng dụng Web Và để thực hiện điều này một cách hiệu quả thì bạn cần hiểu được sự khác nhau giữa kiểm thử ứng dụng Web và kiểm thử truyền thống thông thường

Hình 2.9 Mô hình ứng dụng cho Hệ thống máy tính

Đối với các hệ thống Client-Server, dựa trên hệ thống Web thì sẽ có các vấn đề khác so với hệ thống máy tính thông thường Ở đây để hoạt động được hệ thống Client-Server cần phải có một hệ thống mạng và ít nhất là hai máy tính, một máy đóng vai trò là Client (máy tính khách) còn một máy đóng vai trò là Server (máy tính chủ) Trong mô hình này máy Client sẽ gửi yêu cầu đến máy chủ để máy chủ Server xử lý sau đó sẽ trả lại kết quả được định dạng và hiển thị trong trình duyệt của trình khách

hiển thị thông tin dưới dạng ngôn ngữ đánh dấu (HTML) và nội dung động như Ajax, Flash, ngôn ngữ đánh dấu mở rộng XML, CSS và các tính năng bảo mật

c) Các ứng dụng phía Server

Các ứng dụng được phát triển phía trình chủ khác với ứng dụng trên trình khách

ở hai điểm chính sau: Thứ nhất là, các ứng dụng trên trình chủ là các chương trình không có giao diện để người dùng cuối của hệ thống tương tác, người dùng cuối chỉ tương tác với các ứng dụng phía trình khách Thứ hai, các ứng dụng trên trình chủ được thực thi liên tục, nghĩa là khi các ứng dụng trên trình chủ được khởi động thì nó luôn thường trực để cung cấp dịch vụ cho các ứng dụng phía trình khách Còn ở phía trình khách muốn một ứng dụng hoạt động thì người dùng phải tương tác với ứng dụng

đó thông qua giao diện

2.2.4 Các kiểm thử cho ứng dụng Web

Như các mục đã phân tích ở trên thì chúng ta đã nắm được thế nào là một ứng dụng Web, các thành phần của một ứng dụng Web là gì, và đã có sự so sánh giữa kiểm thử thông thường và kiểm thử ứng dụng Web Vấn đề đặt ra lúc này là để kiểm thử một ứng dụng Web chúng ta cần quan đến những vấn đề gì?

a) Kiểm thử Giao diện người dùng

Vấn đề đầu tiên trong kiểm thử ứng dụng Web chúng ta cần xem xét đến đó là

“Kiểm thử Giao diện người dùng” Khi xây dựng một giao diện ứng dụng Web chúng

ta phải quan tâm đến tư tưởng của người thiết kế xem mục tiêu thiết kế giao diện đó áp dụng cho lĩnh vực gì, và tư tưởng của người phát triển xem sử dụng công nghệ gì để xây dựng giao diện

Kiểm thử thiết kế giao diện người dùng

Kiểm thử giao diện người dùng là cách để đưa ra đánh giá mức độ một thiết kế

có thỏa mãn yêu cầu người dùng hay không? Giao diện có tính dễ sử dụng, và ở đây vấn đề nhìn và cảm nhận được xem xét kiểm thử một cách hết sức cẩn thận Khi thực hiện kiểm thử thiết kế giao diện người dùng cần chú ý đến khả năng phù hợp về thiết

kế, chỉ ra được các vùng thiết kế có thể dẫn người dùng đến trạng thái lỗi và chỉ được

ra cái mà người dùng mong đợi

Người dùng ứng dụng: Thực hiện thiết kế luôn chú trọng đến phần đông người

sử dụng tuy nhiên cũng cần phải biết được nhu cầu và đặc điểm của người dùng ứng dụng Web đó là một yếu tố quan trọng để đánh giá thiết kế giao diện cho ứng dụng đó Kiểm thử giao diện người dùng thì luôn có hai đối tượng cần quan tâm: 1 – người dùng phía trình chủ, 2 – người dùng phía trình khách

Ở đây chúng ta có thể sử dụng một mẫu để thu thập đánh giá được những yếu tố liên quan đến người sử dụng:

Thuộc tính Mức độ kinh nghiệm

0 – không có, 1- thấp, 2 – trung bình, 3 - cao

Bảng 2.1 Đánh giá yêu tố người dùng

Xem xét và xây dựng thiết kế: Ở phần trên chúng ta đã hiểu được các yêu tố liên

quan đến người dùng, ở mục này cần phải thiết kế cho ứng dụng Vì mỗi người dùng khác nhau và ứng dụng khác nhau yêu cầu được thiết kế khác nhau

Mặc dù có rất nhiều phương pháp thiết kế được sử dụng, người kiểm thử ở đây không phải là đánh giá xem phương pháp nào tốt nhất Tuy vậy, chúng ta cũng không nên bỏ qua các lỗi thiết kế, và công việc của chúng ta là chỉ ra sự không nhất quán của

sự cài đặt giao diện

Hình 2.11 Tính nhất quán trong phương pháp thiết kế

- Tương tác của người dùng: Khi người dùng sử dụng ứng dụng sẽ có rất nhiều

loại thao tác dữ liệu như quan bàn phím, chuột Các phương pháp thao tác dữ liệu được tạo ra thông qua điều khiển giao diện màn hình, như cắt và dán, kéo

thả

Kiểm thử thực thi giao diện người dùng

Kiểm thử thực thi giao diện là chúng ta thực hiện việc kiểm thử xem xét xem các chức năng giao diện người dùng có hoạt động đúng đắn không? Một điều khiển khi hoạt động độc lập thì có thể đúng đắn, nhưng khi được kết hợp lại thì hoạt động của nó không còn đúng nữa khi đó sẽ ảnh hưởng đến các chức năng ở bên trong Trong thực thế thì kiểm thử thiết kế giao diện người dùng được kết hợp với kiểm thử chức năng Thực chất thì ranh giới giữa tính nhất quán của thiết kế và chức năng của thiết

kế không phải lúc nào cũng rõ ràng

Kiểm thử thực thi giao diện người dùng sẽ bao gồm các phần từ giao diện cần phải được kiểm thử:

- Font (kiểu chữ): Chữ có dễ đọc không? Nên để chữ nghiêng, đậm hay có chân

- Màu sắc: Có thích hợp với với màu nền,

- Đường viền (Boder): Có thể được sử dụng bao quanh các điều khiển như các đường viền quanh các nút(button)

- Hình ảnh (Image): Kiểm tra hình ảnh có làm tăng thời gian tải không?

Chúng ta có thể thấy được lỗi giao diện gặp phải ở hai phiên bản khác nhau của một trình duyệt cụ thể là trình duyệt IE (Internet Explorer)

Có một số phương pháp giúp cho việc kiểm thử chức năng:

Kiểm thử đơn giản chấp nhận được: Mục tiêu của kiểm thử này là kiểm tra

hành vi thích hợp của các điều khiển giao diện(text box, radio, button,…) Kiểm thử mọi sự tồn tại của các điều khiển giao diện trên môi trang, mỗi cửa sổ, hay mỗi hội thoại Kiểm tra các trạng thái mặc định(được phép chỉnh sửa, hay không được phép

chỉnh sửa), kiểm thử thao tác bàn phím như kiểm thử thứ tự tab, kiểm tra cách hàng vi của phím tắt(Ctrl + A, Ctrl + X,…)và các phím truy cập như Ctrl + O Để hiểu rõ hơn kiểm thử đơn giản chấp nhận trong môi trường ứng dụng Web chúng ta có thể thấy qua các vấn đề sau:

- Các liên kết, như liên kết nội dung

- Các điều khiển cơ bản như: Nút Back (quay lại), Forward (Tiếp tục), phóng to

và thu nhỏ, các điều khiển giao diện, và kiểm thử tải nội dung

- Kiểm tra các nút lệnh hành động như thêm, xóa, sửa, cập nhật, tạo hồ sơ người dùng, như tài khoản, email, và kiểm thử dữ liệu đầu vào

- Các chức năng đăng nhập/đăng xuất (login/logout), email thông báo, tìm kiếm, hoặc giải quyết các trường hợp quên mật khẩu

Kiểm thử chức năng hướng tác vụ: Kiểm tra xem ứng dụng có thể thực hiện các

công việc hữu ích một cách đúng đắn hay không Kiểm thử hướng tác vụ là kiểm thử rất tích cực bằng cách kiểm tra chức năng của chương trình bằng cách so sánh xem các chức năng đó có phù hợp hay đúng đắn với đặc tả ứng dụng, đặc tả yêu cầu không Nếu không đúng với đặc tả yêu cầu hay mong đợi của người dùng chúng ta thực hiện báo lỗi

Kiểm thử hướng tác vụ thực hiện kiểm thử theo danh sách các chức năng được liệt kê, và để có được danh sách các chức năng này thì việc phân tích đặc tả yêu cầu cần phải được làm rất kỹ lưỡng Kiểm thử sẽ xác định được có chức năng nào không được mô tả rõ hay không có trong đặc tả hay không Ngoài ra yếu tố thực tế cũng sẽ được ghi nhận cho các chức năng, vì dụ như chắc năng thanh toán cần phải thực hiện nhanh trong vòng hai giây thì cũng phải được ghi thêm vào danh sách chức năng kiểm thử

Khi chúng ta có được một danh sách các chức năng kiểm thử, thì tương ứng với mỗi chức năng đó chúng ta có thể thiết kế một trường hợp kiểm thử đáp ứng thỏa mãn của chức năng đó

Kiểm thử lỗi ép buộc: Đúng như ý nghĩa của từ, ép buộc lỗi là cố ý tạo ra những

điều kiện lỗi của ứng dụng Và điều kiễn lỗi này không được phát hiện hoặc là bị xử lý sai Khi xác định được điều kiện lỗi này thì chúng ta sẽ xử lý các điều kiện lỗi hợp lý hơn đồng nghĩa với việc là hệ thống phục hồi nhanh hơn, thành công hơn Có thể lấy

ví dụ khi chúng ta điền thông tin đăng ký một ứng dụng nào đó, giả sử trường Name không cho nhập ký tự không phải là ký tự thì sẽ phát sinh một trường hợp lỗi đó là khi

ta nhập „123456789‟ và chọn nút Submit để gửi dữ liệu đi Tuy nhiên phải luôn nhớ rằng bất kỳ điều kiện hợp lệ nào cũng có một điều kiện không hợp lệ

Chúng ta có thể tạo ra một danh sách các điều kiện lỗi như sau:

- Phỏng vấn các lập trình viên

- Thu thập danh sách các thông điệp từ các lập trình viên

- Thu thập thông tin từ đặc tả

Người dùng khi sử dụng ứng dụng sẽ thực hiện một số hành động sẽ khiến hệ thống hay ứng dụng rơi vào trạng thái bị lỗi Điều này có thể thực hiện bằng nhiều cách khác nhau, như nhập đầu vào không hợp lệ, ngắt kết lỗi mạng,…Khi này lỗi phải cần được phát hiện Lỗi có thể xuất hiện ở bất kỳ thành phần nào trong chuỗi giao tiếp thực hiện yêu cầu Và khi phát hiện lỗi thì lỗi đó cần phải được xử lý, các ứng dụng khi gặp lỗi sẽ trả về một mã lỗi hay một thông điệp lỗi Và thông thường người dùng hay gặp khi ứng dụng gặp phải lỗi đó là thông điệp được hiển thị để thông báo lỗi Điều này có thể được thực thi phía trình khách(nếu hành vi đó không đúng), và có thể thực hiện ở trình chủ sau khi người dùng gửi yêu cầu đến trình chủ

Quy trình xử lý lỗi có thể được hiểu rõ hơn như sau: Người dùng sử dụng ứng dụng nhập vào một yêu cầu và yêu cầu được gửi đến trình chủ Web, trình chủ Web nhận được yêu cầu và chuyển đến trình chủ cơ sở dữ liệu Nếu trình chủ cơ sở dữ liệu phát hiện ra một lỗi nào đó sẽ trả lại cho trình chủ một mã lỗi, và trình chủ có nhiệm

vụ chuyển mã lỗi này gửi lại phía trình chủ dưới dạng thông điệp Khi đã hiểu được quy trình bắt lỗi chúng ta cần xem xét một số vấn đề sau:

- Một điều kiện lỗi có thể xuất hiện ở bất kỳ thành phần nào

- Các điều kiện lỗi phải được chuyển từ mã lỗi sang thông điệp dễ hiểu để người dùng có thể biết được lỗi gì xảy ra

- Kiểm thử ép buộc lỗi, là đặt ứng dụng vào một điều kiện lỗi nó được như lý ở hai mức, mức đầu tiền sẽ đảm bảo rằng một thông điệp lỗi được trình khách tiếp nhận, mức thứ hai kiểm tra thông điệp lỗi có đúng không, có nghĩa là thông điệp sẽ mô tả lỗi để người dùng biết cách xử lý lỗi đó

Sau khi phát hiện ra lỗi, chúng ta cần phải kiểm tra xem điều kiện lỗi có được

xử lý một cách đúng đắn hay không, nhưng điều này không đơn giản vì trong hầu hết các chương trình chúng ta không thể biết được điều kiện lỗi đó sẽ sinh ra kết quả gì Vì vậy giải pháp giúp cho các kiểm thử viên kiểm soát được việc này là ghi nhận các hành động được thực hiện và thứ tự, như thế khi lỗi xuất hiện có thể được xem xét và

xử lý nhanh hơn

Để ghi nhận lại lỗi thì có rất nhiều cách, cách hay được sử dụng nhất là các kiểm thử viên tạo ra kiểm thử điều kiện lỗi sơ bộ được thu thập từ các lập trình viên hoặc có thể dự đoán phụ thuộc vào kinh nghiệm của người kiểm thử

Kiểm thử điều kiện biên: Cũng tương tự như kiểm thử ép buộc lỗi, trong đó các

biên của mỗi biến được thực hiện kiểm thử

Ví dụ: Nhập ký tự vào textbox yêu cầu giới hạn ký tự từ 2-8

0 Kiểm thử biên, hay kiểm thử lỗi bắt buộc?

1 hoặc < 2 Kiểm thử biên hay kiểm thử ép buộc lỗi?

9 hoặc > 8 Kiểm thử biên hay kiểm thử ép buộc lỗi?

bộ não của hệ thống Client – Server Thực hiện kiểm thử trình chủ sẽ phức tạp hơn rất nhiều so với các kiểm thử khác Bởi vì các kiểm thử khác bạn có thể tận dụng giao diện của trình khách Còn trình chủ không tận dụng được giao diện của trình khách

Kết nối

Khi thực hiện kiểm thử hệ thống ứng dụng Web có hai yếu tố làm cho việc kiểm thử thất bại đó là: (1) Các hành động không đến được đích, (2) Hoạt động đến được đích nhưng không đúng yêu cầu Và hoạt động hay giao tác không đến được đích(trình chủ) thì cũng sẽ có hai yếu tố cần được quan tâm: (1) Do việc kết nối, (2) Đích hay trình chủ có vấn đề

Trạng thái duy trì

Trạng thái (state) là quan hệ giữa trình chủ và trình khách trong đó các thông tin được cung cấp từ các giao tác trước được lưu trữ sẵn cho trình chủ Hiện này phổ biến nhất được sử dụng đó là Cookies, ID của phiên làm việc (Session ID), hoặc địa chỉ IP,

và cả đăng nhập (login) của người dùng để thiết lập trạng thái cho ứng dụng đó Ví dụ, khi bạn truy cập vào một trang Web thông tin về chứng khoán, email, việc đầu tiên của bạn là đăng nhập vào hệ thống đó bằng tài khoản của bạn Khi bạn đăng nhập thành công sẽ thiết lập trạng thái cho phiên làm việc đó Các vấn đề liên quan đến trạng thái bao gồm:

- Thông tin bị mất: Các thông tin này bao gồm dữ liệu được cung cấp trong một

màn hình hay một phiên làm việc trước đó

- Dữ liệu trùng nhau: Ứng dụng sinh ra dữ liệu thế nào để xác định giao tác là

duy nhất?

- Trình khách bị mất: Trình khách sau khi gửi yêu cầu sẽ đợi trình chủ trong bao

lâu?

- Toàn vẹn dữ liệu: Điều này thể hiện được khi bạn thực hiện gửi một yêu cầu từ

trình khách và khi đang thực hiện thì bị mất kết nối, lúc này dữ liệu sẽ xảy ra vấn đề gì?

Nguồn tài nguyên

Nguồn tài nguyên (resouce) là những gì ứng dụng sử dụng để thực thi một câu lệnh Các nguồn tài nguyên bao gồm: RAM, đĩa cứng, băng thông, kết nối,…để thực hiện các công việc

Sao lưu và phục hồi

Dữ liệu trên máy chủ thường được sao lưu theo một lịch trình đã được thiết lập trước Việc sao lưu dữ liệu của hệ thống tại một thời điểm nhất định phục vụ cho việc phục hồi hệ thống trở lại trạng thái lúc sao lưu Trong các ứng dụng Web việc sao lưu trình chủ Web hay cơ sở dữ liệu và phục hồi tại thời điểm là rất quan trọng Thực hiện việc kiểm tra sao lưu phục hồi cần phải kiểm tra các vấn đề:

- Các hướng dẫn cài đặt và hướng dẫn hoạt động liên quan đến tiến trình sao lưu

và khôi phục, như tên người và thư mục cần được sao lưu

- Trong hệ thống hoạt động liên tục thì việc phục hồi lại thời điểm sao lưu được thực hiện có thể không có ý nghĩa

d) Kiểm thử Cơ sở dữ liệu

Tất cả các ứng dụng Web truy cập cơ sở dữ liệu đều yêu cầu trình chủ cơ sở dữ liệu, để có thể thiết kế các trường hợp kiểm thử cơ sở dữ liệu và phân tích các lỗi liên quan đến cơ sở dữ liệu, các kiểm thử viên cần hiểu được các khái niệm liên quan đến

cơ sở dữ liệu, cách các thành phần của trình chủ Web giao tiếp với các thành phần cơ

sở dữ liệu

Có hai phương pháp phổ biến để đáp ứng được yêu cầu người dùng đó là:(1) xử

lý giao dịch trực tuyến, (2) xử lý phân tích trực tuyến Xử lý giao dịch trực tuyến là xử

lý hướng giao dịch, mục đích là hỗ trợ người dùng cần truy cập hệ thống để thực hiện việc mua bán hoặc các loại giao dịch khác

Mối quan hệ giữa cơ sở dữ liệu

Cơ sở dữ liệu quan hệ tổ chức dữ liệu vào trong các bảng, từng dòng dữ liệu bản ghi (record) và các trường (field) Cung cấp cho việc lưu trữ và truy cập dữ liệu dựa trên yêu cầu phía trình khách Các dịch vụ cơ bản bao gồm: thêm, xóa, sửa, lọc và sắp xếp các bảng và dòng dữ liệu Trình chủ cơ sở dữ liệu bao gồm hai thành phần:

- Ngôn ngữ truy vấn có cấu trúc (SQL – Structured Query Language): Cung cấp các câu lệnh truy vấn được sử dụng để ghi, đọc và thao tác dữ liệu trong các định dạng bảng

- Dữ liệu vật lý: Được lưu trữ trong các hệ thống quan trị cơ sở dữ liệu cung cấp các sơ đồ truy cập lưu trữ hiệu quả

Mối quan hệ giữa trình khách và SQL

Các ứng dụng phía trình khách có thể được xây dựng từ một trong nhiều ngôn ngữ lập trình khác nhau Hiện này chúng ta hay sử dụng ODBC(Open Database Connectivity) được sử dụng để truy cập dữ liệu trong một môi trường không đồng nhất gồm các hệ quản trị cơ sở dữ liệu quan hệ và phi quan hệ ODBC như là một giao thức truyền dữ liệu được sử dụng để di chuyển dữ liệu giữa các ứng dụng Web và cá trình chủ cơ sở dữ liệu Hình 2.19[5] mô tả mối quan hệ trình khách và SQL

Hình 2.14 Các lớp ODBC

Các phương pháp kiểm thử Cơ sở dữ liệu

Kiểm thử cơ sở dữ liệu và việc thực hiện kiểm thử dữ liệu hiện tại và tính toàn vẹn của cơ sở dữ liệu, nhằm đảm bảo dữ liệu không bị lỗi và các sơ đồ dữ liệu là đúng đắn Kiểm thử cơ sở dữ liệu thường sử dụng Script SQL để kiểm thử, không phải tất cả

cơ sở dữ liệu là cơ sở dữ liệu SQL Nhưng hầu hết đều hỗ trợ SQL, cũng như hầu hết

là các ứng dụng Web

Các thao tác cài đặt cơ sở dữ liệu bao gồm các hoạt động:

- Kết nối trình chủ cơ sở dữ liệu

- Tạo cơ sở dữ liệu mới

- Tạo các bảng, các trường, giá trị mặc định

- Biên dịch các thủ tục lưu trữ và các trigger

Sử dụng phương pháp kiểm thử hộp trắng trong kiểm thử cơ sở dữ liệu:

Kiểm tra mã nguồn: Để xác định lỗi ở mã nguồn cách hiệu quả nhất là thực thi

kiểm thử mã nguồn Phương pháp này không chỉ hữu ích cho việc kiểm thử cơ sở dữ liệu mà còn phù hợp cho việc kiểm thử ngôn ngữ lập trình Thực hiện kiểm thử mã nguồn theo từng dòng một Việc thực hiện kiểm thử sẽ đưa ra xem câu lệnh có hiệu quả, dư thừa, không phù hợp, hay mã nguồn vẫn chưa được tối ưu nhất

- Kiểm thử hộp đen có thể có được hiểu biết mã nguồn hoạt động bên trong như thế nào Sẽ giúp cho việc thiết kế các ca kiểm thử

- Luôn đặt ra các câu hỏi nếu thì sao, nếu dữ liệu truyền vào tham số không hợp

lệ thì sao? Nhiều câu hỏi càng làm cho việc phát hiện lỗi nhiêu hơn và đưa ra các xử lý lỗi nhanh hơn

e) Kiểm thử bảo mật

Đối một ứng dụng Web thì bảo mật là một vấn đề sống còn với ứng dụng đó, vì nếu bảo mật không tốt sẽ làm mất thông tin quan trọng, thậm chí còn mất cả quyền kiểm soát hệ thống ứng dụng Web đó Vậy mà kiểm thử bảo mật vẫn thường là hoạt động kiểm thử ít được tìm hiểu nhất Trong khi đó không có một ứng dụng Web nào dám khẳng định là không có lỗi, mà đã có lỗi sẽ sinh ra lỗ hổng để tấn công vào hệ thống ứng dụng Web Hơn nữa, một công cụ bảo mật mới được phát hành thì lại có nhiều công cụ khác ra đời nhằm mục đích phá hoại Chính vì vậy là việc bảo mật luôn luôn phải được xem xét, cải thiện và nâng cao

Có nhiều các mối de dọa chúng ta cần phải quan tâm đặc biệt:

- Toàn vẹn dữ liệu: Luôn đảm bảo dữ liệu của các giao tác không bị dửa đổi hay

bị lỗi Nếu có sự thay đổi cần phải được kiểm thử ngay và kết luận nó hợp lệ

- Tính tin cậy: Đảm bảo việc truy cập trái phép sẽ bị ngăn chặn

- Bảo mật quyền sử dụng riêng tư của người dùng: Các ứng dụng Web có các

thông báo về riêng tư nhằm định nghĩa thông tin cho người sử dụng

- Khả năng sử dụng: Khả năng sử dụng dữ liệu được như mong đợi

- Bảo vệ hệ thống mạng: Bảo đảm rằng mọi sự sử dụng trái phép hệ thống mạng

sẽ bị năng chặn

Sự tấn công hay truy cập trái phép đều có chiến lược thực hiện cụ thể:

Trong các ứng dụng Web hay hệ thống mạng, lỗ hổng bảo mật là sự lỏng lẻo của phần cứng và phần mềm mà cho phép người sử dụng trái phép có thể truy cập vào không cần đi qua các con đường được cho phép Kẻ tấn công sử dụng các kỹ thuật khác nhau để bẻ gãy được các bảo mật của ứng dụng Web nhằm khai thác các lỗ hổng

và xâm nhập vào ứng dụng chiếm quyền kiểm soát ứng dụng, chiến lược thường được

sử dụng nhiều nhất đó là: Thu thập thông tin -> Quét mạng -> Thực hiện tấn công

Thu thập thông tin: Thông thường để thực hiện tấn công vào một ứng dụng

Website việc đầu tiên là chép toàn bộ Website, xem mã nguồn công cộng của trang sẽ biết được tên đường dẫn cùng với những chú thích của mã nguồn sẽ xác định được liên kết đến hệ thống đích

Các giải pháp cho việc bảo mật ứng dụng Web

Khi đã phân tích được các chiến lược tấn công, chúng ta có thể lập ra chiến lược để bảo vệ các ứng dụng khỏi sự tấn công đe dọa Để xây dựng được một chiến lược hiệu quả chúng ta cần phải hiểu được kẻ tấn công làm gì và làm như thế nào Khi

đó chúng ta sẽ đặt ra các cơ chế phát hiện tấn công sao cho có thể phản ứng kịp thời với sự tấn công Các giải pháp cho việc bảo mật bao gồm rất nhiều, có thể sử dụng một hoặc kết hợp nhiều giải pháp cùng một lúc

Xác thực và phân quyền sử dụng người dùng:

Xác thực là cho phép hệ thống biết được người sử dụng đó có quyền truy cập vào hệ thống không Phân quyền sử dụng là cho biết rằng người sử dụng sẽ được thực thi những công việc gì trong hệ thống Sử dụng Mật khẩu là cách thông thường trong việc xác nhận Tuy nhiên có những nhược điểm khi sử dụng mật khẩu:

- Đặt mật khẩu quá dễ đoán được

- Người sử dụng thường quên mật khẩu, do đó các ứng dụng phải cung cấp một mẫu cho phép cấp lại mật khẩu cho người dùng

- Mật khẩu có thể bị đánh cắp và bị lộ

Một số công nghệ bảo mật phổ biến cho ứng dụng Web:

- IPSec (IP Security): Hoạt động ở lớp mạng IP và thường được cài đặt trong các thiết bị định tuyến Router và Swicth

- SSL (Secure Sockets Layer): SSL hoạt động ở lớp phiên (session layer) và được

hỗ trợ phổ biến bởi các trình duyệt và trình chủ thương mại Web SSL cung cấp:

o Giao tiếp khách – chủ sử dụng mã hóa

o Toàn vẹn dữ liệu đối với giao tiếp khách – chủ bởi việc kiểm tra nội dung các thông điệp được trao đổi, nhằm đảm bảo các thông được không

bị sửa đổi trong quá trình truyền đi

o SSL phải được thực hiện ở cả phía trình chủ và trình khách Nếu ứng dụng cần được kiểm thử sẽ hỗ trợ HTTPS, thì các chứng chỉ sẽ được yêu cầu phía trình chủ, sẽ phải cài đặt giao tiếp HTTPS trên cả phía trình khách và trình chủ

Tường lửa được sử dụng để bảo vệ các mạng riêng đối với Internet, ngăn cản việc sử dụng trái phép truy cập các thông tin bảo mật, sử dụng nguồn tài nguyên mạng

và phá hoại Tường lửa được kết hợp giữa phần cứng và phần mềm, chúng sử dụng các thiết bị định tuyết, trình chủ và phần mềm để ngăn chặn sự khái thác từ Internet

Hình 2.15 Tường lửa

Các lỗ hổng và tấn công phổ biến

Lỗ hổng chính là điểm yếu trong thiết kế và cài đặt hệ thống thông tin và bảo mật Nguyên nhân dẫn đễn lỗ hổng do phần cứng, phần mềm, hệ thống mã hóa, các giao thức và thủ tục liên quan đến bảo mật và lỗi do người sử dụng gây ra Các lỗ hổng

sẽ làm cho hệ thống không được an toàn, vì kẻ tấn công sẽ tập trung vào việc khai thác các lỗ hổng để tấn công ứng dụng Tuy nhiên, chúng ta cũng luôn cải tiến và nâng cấp các cơ chế để ngăn cản sự truy cập dữ liệu bất hợp pháp Có rất nhiều các lỗ hổng do thiết kế, lập trình, do các chương trình nguy hiểm, tấn công dịch vụ từ chối, phá mật khẩu, sự rò rỉ thông tin, bắt các gõ bàn phím, tìm kiếm trong thùng rác, tấn công vào mạng…

Tràn vùng đệm (buffer overflow):Sử dụng các đoạn mã thực hiện phá hoại trên

máy tính một cách trái phép Mã nguồn này có thể được nhúng vào mã nguồn chương trình, mã nguồn kiểm thử hay mã nguồn của bên thứ ba

Tấn công từ chối dịch vụ (DoS – Denial of Service Attack): Là thực hiện tấn

công trình chủ với số lượng yêu cầu lớn hay các thông điệp email mà trình chủ không thể xử lý bất kỳ yêu cầu mà nó nhận được Để làm được điều này chúng cài đặt một phần mềm trên trình chủ và sau đó kích hoạt các tác tử và khi đó toàn bộ băng thông của các trình chủ được mở ra trên trình chủ đích

Thực hiện kiểm thử bảo mật

Ở phần trên đã trình bày những kỹ thuật hay những chiến lược của kẻ tấn công

có thể sử dụng để tấn công vào ứng dụng Web của bạn Vậy để đưa ra được các phương pháp kiểm thử hiệu quả nhất chúng ta giá sử những kẻ tấn công đều có kỹ năng, thời gian, cơ hội, các đối tượng có thể là tổ chức tình báo, hay những đưa trẻ