Nghiên cứu và xây dựng công cụ kiểm thử ứng dụng web

Xuất phát từ thực tế đó và được sự gợi ý của giảng viên hướng dẫn, tôi lựa chọn đề tài luận văn “Nghiên cứu và xây dựng công cụ kiểm thử ứng dụng Web” với mong muốn mang lại cho người đọ

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC: TS VÕ ĐÌNH HIẾU

Hà Nội – 2014

LỜI CẢM ƠN

Luận văn Thạc sĩ này được thực hiện tại Đại học Công Nghệ - Đại học Quốc Gia Hà Nội dưới sự hướng dẫn của TS Võ Đình Hiếu Xin được gửi lời cảm ơn sâu sắc đến thầy về định hướng khoa học, liên tục quan tâm, tạo điều kiện thuận lợi trong suốt quá trình nghiên cứu hoàn thành luận văn này Tôi xin được gửi lời cảm ơn đến các thầy, cô trong Bộ môn Công nghệ phần mềm cũng như Khoa Công nghệ thông tin

đã mang lại cho tôi những kiến thức vô cùng quý giá và bổ ích trong quá trình theo học tại trường

Tôi cũng xin chân thành cảm ơn đến gia đình tôi, những sự quan tâm và động viên của bố, mẹ và em gái đã giúp tôi có thêm nghị lực, cố gắng để hoàn thành luận văn này

Cuối cùng, xin gửi lời cảm ơn chân thành nhất đến các bạn cùng học K19, các bạn đồng nghiệp đã giúp đỡ tôi trong suốt 2 năm học tập

Hà Nội, ngày 30 tháng 10 năm 2014

Đoàn Mạnh Đức

LỜI CAM ĐOAN

Tôi xin cam đoan luận văn “Nghiên cứu và xây dựng công cụ kiểm thử ứng dụng Web” là công trình nghiên cứu của cá nhân tôi dưới sự hướng dẫn của TS Võ Đình Hiếu, trung thực và không sao chép của tác giả khác Trong toàn bộ nội dung nghiên cứu của luận văn, các vấn đề được trình bày đều là những tìm hiểu và nghiên cứu của chính cá nhân tôi hoặc là được trích dẫn từ các nguồn tài liệu có ghi tham khảo rõ ràng, hợp pháp

Tôi xin chịu mọi trách nhiệm và mọi hình thức kỷ luật theo quy định cho lời cam đoan này

Hà Nội, ngày 30 tháng 10 năm 2014

Đoàn Mạnh Đức

MỤC LỤC

LỜI CẢM ƠN 1

LỜI CAM ĐOAN 2

MỤC LỤC 3

DANH SÁCH CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT 5

DANH MỤC CÁC BẢNG 6

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

LỜI GIỚI THIỆU 9

CHƯƠNG 1 TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM 11

1.1 Các khái niệm cơ bản 11

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

1.1.2 Mức kiểm thử 12

1.1.3 Kiểm thử tự động 18

1.1.4 Ứng dụng Web 19

1.2 Kỹ thuật kiểm thử tĩnh 20

1.2.1 Rà soát 20

1.2.2 Kiểm thử dòng dữ liệu tĩnh 21

1.3 Kỹ thuật kiểm thử động 23

1.3.1 Kiểm thử hàm 23

1.3.2 Kiểm thử dòng điều khiển 24

1.3.3 Kiểm thử dòng dữ liệu động 26

1.4 Các loại kiểm thử ứng dụng Web 29

CHƯƠNG 2 CÁC CÔNG CỤ KIỂM THỬ TỰ ĐỘNG CHO CÁC ỨNG DỤNG WEB 33 2.1 Công cụ kiểm thử tự động tĩnh 33

2.1.1 Công cụ kiểm thử ngôn ngữ lập trình phía máy chủ 33

2.1.2 Công cụ kiểm thử ngôn ngữ lập trình phía máy khách 35

2.2 Công cụ kiểm thử tự động động 37

2.2.1 Công cụ kiểm thử giao diện người dùng 37

2.2.2 Công cụ kiểm thử hàm 38

2.2.3 Công cụ kiểm thử khả năng chịu tải của ứng dụng Web 40

2.3 Thư viện hỗ trợ xây dựng công cụ kiểm thử tự động 41

CHƯƠNG 3 XÂY DỰNG CÔNG CỤ KIỂM THỬ TỰ ĐỘNG 44

3.1 Đặt vấn đề bài toán 44

3.2 Phân tích bài toán 45

3.3 Thỏa thuận khi sử dụng công cụ 50

3.4 Xây dựng công cụ 50

3.5 Ứng dụng công cụ vào thực tế 54

3.5.1 Ứng dụng vào form thành viên đăng nhập 54

3.5.2 Ứng dụng vào form đăng ký nhận bản tin 58

3.6 Đánh giá ưu nhược điểm của công cụ 60

CHƯƠNG 4 KẾT LUẬN 61

4.1 Tóm tắt kết quả làm được 61

4.2 Hạn chế 61

4.3 Hướng nghiên cứu 61

TÀI LIỆU THAM KHẢO 62

PHỤ LỤC 63

Phụ lục 1: Kết quả sau khi thực hiện kiểm thử form thành viên đăng nhập 63

Phụ lục 2: Kết quả sau khi thực hiện kiểm thử form đăng ký nhận bản tin 64

DANH SÁCH CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT

API Application Programming Interface, giao diện lập trình ứng dụng

C-S Client-Server, máy khách – máy chủ

CSS Cascading Style Sheets, là ngôn ngữ được dùng để miêu tả cách trình

bày các tài liệu viết bằng ngôn ngữ HTML và XHTML

HTML Hypertext Markup Language, ngôn ngữ đánh dấu tạo website

HTTP HyperText Transfer Protocol - Giao thức truyền tải siêu văn bản được

dùng để trao đổi giữa máy khách và máy chủ ứng dụng Web

HTTPS Hypertext Transfer Protocol Secure, là sự kết hợp giữa giao thức HTTP

và giao thức bảo mật SSL hay TLS cho phép trao đổi thông tin một cách bảo mật trên Internet

DANH MỤC CÁC BẢNG

Bảng 1.1 Các điều kiện con kết hợp trong câu lệnh điều kiện 26

Bảng 1.2 Một số lỗi thường gặp trên ứng dụng Web 32

Bảng 2.1 Minh họa một số quy ước về lập trình của Microsoft 34

Bảng 2.2 Hàm và từ khóa thường dùng của Selenium WebDriver 42

Bảng 3.1 Một số điều kiện đầu vào với input trong ứng dụng Web 47

Bảng 3.2 Một số dữ liệu đầu vào mẫu cho input ngày tháng Việt Nam 49

Bảng 3.3 Kết quả thực hiện kiểm thử bằng công cụ kiểm thử tự động với form đăng ký nhận bản tin 59

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

Hình 1.1 Mã nguồn minh họa Driver và Stub 13

Hình 1.2 Kiểm thử hồi quy được thực hiện tại các mức kiểm thử khác nhau 17

Hình 1.3 Các câu lệnh tuần tự có bất thường loại 1 22

Hình 1.4 Câu lệnh có bất thường loại 2 22

Hình 1.5 Sơ đồ chuyển trạng thái của một biến tương ứng với những bất thường về dòng dữ liệu 23

Hình 1.6 Các biểu tượng xây dựng đồ thị dòng điều khiển 25

Hình 1.7 Mã nguồn tính tổng các số từ 1 đến 9 25

Hình 1.8 Đồ thị dòng điều khiển của mã nguồn hình 1.9 25

Hình 1.9 Ví dụ mã nguồn hàm ReturnAverage 27

Hình 1.10 Đồ thị dòng dữ liệu minh họa hàm ReturnAverage 28

Hình 2.1 Giao diện Fxcop 33

Hình 2.2 Mã nguồn được phân tích bởi Fxcop 34

Hình 2.3 Kết quả phân tích từ Fxcop 35

Hình 2.4 Giao diện công cụ JSLint 36

Hình 2.5 Mã nguồn được phân tích bởi JSLint 36

Hình 2.6 Kết quả phân tích từ JSLint 36

Hình 2.7 Giao diện Browser Shots 38

Hình 2.8 Giao diện người dùng trên các trình duyệt khác nhau 38

Hình 2.9 Giao diện Selenium IDE 38

Hình 2.10 Các thao tác xử lý được Selenium IDE ghi lại 39

Hình 2.11 Mã HTML của ca kiểm thử được Selenium IDE lưu lại 40

Hình 2.12 Giao diện công cụ loader.io 41

Hình 2.13 Kết quả khi thực thi kiểm thử với loader.io 41

Hình 3.1 Form thêm người dùng trên ứng dụng Web 44

Hình 3.2 Minh họa hộp thông báo đăng nhập thành công 46

Hình 3.3 Minh họa dòng thông báo từ ứng dụng Web đến người dùng 46

Hình 3.4 Các dữ liệu mẫu sinh ra từ kỹ thuật kiểm thử giá trị biên mạnh 49

Hình 3.5 Giao diện công cụ kiểm thử tự động 50

Hình 3.6 Thêm ô textbox chứa input 51

Hình 3.7 Lựa chọn các điều kiện cần kiểm thử của input 51

Hình 3.8 Lỗi xuất hiện được thông báo cho kiểm thử viên 52

Hình 3.9 Kiểm tra tính hợp lệ của điều kiện của độ dài tối thiểu và tối đa 52

Hình 3.10 Thông báo không tìm thấy phần tử có id như đã nhập 53

Hình 3.11 Điều kiện và giá trị được sinh ra khi lựa chọn điều kiện cho input 53

Hình 3.12 Mã nguồn hàm ngẫu nhiên sinh ra chuỗi ký tự có độ dài là 53

tham số truyền vào 54

Hình 3.13 Kết quả sau khi thực hiện kiểm thử form 54

Hình 3.14 Giao diện form thành viên đăng nhập 55

Hình 3.15 Thông báo không được bỏ trống tên đăng nhập 55

Hình 3.16 Thông báo tên đăng nhập không được nhỏ hơn 6 ký tự 55

Hình 3.17 Thông báo sai tên đăng nhập hoặc mật khẩu 55

Hình 3.18 Lấy id của input 56

Hình 3.19 Điền thông tin form thành viên đăng nhập vào công cụ 56

Hình 3.20 Chọn điều kiện cho các input 57

Hình 3.21 Kết quả kiểm thử form thành viên đăng nhập 57

Hình 3.22 Giao diện form đăng ký nhận bản tin 58

Hình 3.23 Thông báo không được bỏ trống email 58

Hình 3.24 Thông báo nhập sai định dạng email 58

Hình 3.25 Điền thông tin form đăng ký nhận bản tin vào công cụ 59

Hình 3.26 Chọn điều kiện cho input email 59

LỜI GIỚI THIỆU

Với sự phát triển của Internet và công nghệ phần mềm, các ứng dụng Web đang dần thay thế các ứng dụng phần mềm truyền thống bởi tính tiện lợi của nó Đi kèm với thành công mà những ứng dụng Web mang lại cho nhà phát triển đó là những thách thức như phải đảm bảo và nâng cao chất lượng cho người dùng khi sử dụng dịch vụ Một trong những giải pháp để hoàn thành tốt công việc này đó là thực hiện kiểm thử phần mềm Kiểm thử là một công việc tốn nhiều thời gian và chi phí, thông thường thời gian dành cho việc kiểm thử chiếm đa số thời gian phát triển ứng dụng phần mềm Tuy nhiên, để thực hiện kiểm thử đòi hỏi kiểm thử viên phải kiên nhẫn và tỉ mỉ, chính những điều này dẫn tới sự cần thiết của kiểm thử tự động Kiểm thử tự động sẽ thực hiện tự động các ca kiểm thử theo một kịch bản cho sẵn hoặc tự nó sinh ra Những lợi ích của các công cụ kiểm thử tự động mang lại là rất lớn tuy nhiên các tài liệu về kiểm thử tự động được viết bằng tiếng Việt lại còn rất hạn chế Xuất phát từ thực tế đó và được sự gợi ý của giảng viên hướng dẫn, tôi lựa chọn đề tài luận văn “Nghiên cứu và xây dựng công cụ kiểm thử ứng dụng Web” với mong muốn mang lại cho người đọc một tài liệu hỗ trợ hữu ích trước khi quyết định sử dụng kiểm thử tự động cho ứng dụng Web của mình

Luận văn được cấu trúc thành bốn chương:

Chương một sẽ trình bày các tìm hiểu về kiểm thử phần mềm như các khái niệm cơ bản về kiểm thử, các mức kiểm thử, ca kiểm thử, các kỹ thuật kiểm thử tĩnh

và động Chương một cũng sẽ đưa ra khái niệm về ứng dụng Web, phân biệt ứng dụng Web với ứng dụng máy khách – máy chủ và các loại kiểm thử cần chú trọng cho ứng dụng Web

Chương hai sẽ giới thiệu các công cụ kiểm thử tự động phổ biến hiện nay dành cho ứng dụng Web, ngoài việc cung cấp thông tin và cách sử dụng từng công cụ, luận văn còn phân tích ưu nhược điểm của các công cụ giúp người đọc có một gợi ý trước khi lựa chọn công cụ phù hợp cho ứng dụng cần kiểm thử Xuất phát trên thực tế, mỗi ứng dụng Web đều có những yêu cầu đặc thù riêng biệt nên việc sử dụng các công cụ kiểm thử tự động đã có sẵn có thể không thỏa mãn hoặc phù hợp với việc kiểm thử các ứng dụng này Luận văn cũng giới thiệu một nền tảng hỗ trợ xây dựng công cụ kiểm thử tự động nhằm giúp người đọc có thể lựa chọn nền tảng giúp tự tạo công cụ kiểm thử cho phù hợp với nhu cầu của mình

Trong ứng dụng Web, việc kiểm tra tính hợp lệ của các dữ liệu đầu vào là rất quan trọng do dữ liệu đầu vào không chỉ yêu cầu phải đúng kiểu dữ liệu mà còn đòi

hỏi phải đúng định dạng của loại dữ liệu đó Do đó, ứng dụng Web cần phải có khả năng kiểm tra tính hợp lệ của dữ liệu đầu vào một cách hiệu quả thì các tiến trình xử lý tiếp theo mới được đảm bảo hoạt động tốt Một vấn đề nữa là hiện nay có rất nhiều công cụ hỗ trợ cho việc kiểm thử tự động ứng dụng Web, tuy nhiên hầu hết các công

cụ chỉ hỗ trợ cho việc thực thi tự động các ca kiểm thử còn việc thiết kế các ca kiểm thử lại rất hạn chế Chương ba sẽ trình bày về ý tưởng, phân tích và xây dựng công cụ kiểm thử tự động nhằm đánh giá khả năng kiểm tra tính hợp lệ dữ liệu đầu vào của ứng dụng Web Công cụ được đề xuất có khả năng tự sinh ca kiểm thử, thực thi và lưu lại kết quả kiểm thử Ngoài ra chương này cũng minh họa áp dụng công cụ trong thực tế

và đánh giá ưu nhược điểm của công cụ cùng hướng phát triển

Chương bốn sẽ đưa kết luận về các nội dung đạt được trong luận văn, các mặt hạn chế và hướng phát triển trong thời gian tới của luận văn

CHƯƠNG 1 TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM

1.1 Các khái niệm cơ bản

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

Kiểm thử phần mềm là công việc được thực hiện nhằm tìm ra lỗi, thiếu sót của phần mềm hoặc chứng minh phần mềm hoạt động đúng đắn Kiểm thử phần mềm có vai trò rất quan trọng trong việc cải thiện chất lượng phần mềm [4, tr.655-657] và làm giảm chi phí kiểm thử cũng như khắc phục lỗi

Kiểm thử phần mềm sử dụng quy trình kiểm chứng và thẩm định chất lượng phần mềm trong quá trình thực hiện việc kiểm thử Quy trình kiểm chứng sẽ đảm bảo rằng phần mềm khi được phát triển sẽ đúng với đặc tả của nó và quy trình thẩm định thì sẽ đảm bảo rằng phần mềm thỏa mãn được yêu cầu của người dùng cuối Quy trình kiểm chứng sẽ được thực hiện trước quy trình thẩm định do sản phẩm phần mềm cần đúng với đặc tả trước Nếu thực hiện quy trình thẩm định trước quy trình đặc tả, nếu xảy ra lỗi, rất khó có thể xác định lỗi này là do đặc tả sai hay do lập trình sai so với đặc

tả Tuy nhiên, thẩm định nếu được thực hiện quá muộn thì khi phát hiện ra lỗi hoặc thiếu sót sẽ kéo theo chi phí khắc phục lỗi tăng đồng thời khiến thời gian hoàn thiện phần mềm kéo dài Vì vậy, quy trình thẩm định nên được thực hiện sớm để góp phần làm giảm chi phí cũng như thời gian phát triển sản phẩm phần mềm Trong phương pháp phát triển phần mềm Agile [4, tr.58-64], khách hàng sẽ đóng vai trò là một thành viên của nhóm phát triển và thực hiện việc thẩm định sản phẩm phần mềm liên tục sau mỗi vòng lặp phát triển trong suốt quá trình thực hiện dự án phần mềm Chính điều này giúp cho việc phát triển phần mềm theo phương pháp Agile trở nên rất nhanh chóng và giảm được nhiều chi phí cho việc sửa lỗi do lỗi được phát hiện từ rất sớm

Trong kiểm thử phần mềm, các khái niệm như lỗi, sai, khuyết thiếu, thất bại đều

có nghĩa khá gần nhau nhưng trên thực tế cần phân biệt rõ các khái niệm này

 Lỗi: do lập trình viên phạm phải trong quá trình lập trình Khi lỗi được thực thi

Kiểm thử phần mềm có thể chia làm hai nhóm kỹ thuật chính là kỹ thuật kiểm thử tĩnh và kỹ thuật kiểm thử động Kiểm thử tĩnh là kỹ thuật không yêu cầu phải biên dịch và chạy mã nguồn chương trình để thực hiện việc kiểm thử phần mềm Kỹ thuật này kiểm thử chương trình bằng cách kiểm tra cú pháp, cấu trúc mã nguồn của chương trình hoặc rà soát các tài liệu liên quan như tài liệu đặc tả, tài liệu thiết kế để tìm ra lỗi Trong quy trình kiểm chứng và thẩm định chất lượng phần mềm thì kiểm thử tĩnh được sử dụng trong quy trình kiểm chứng Kiểm thử động là kỹ thuật chỉ được thực hiện khi mã nguồn chương trình phần mềm được biên dịch và chạy Mục đích chính của kỹ thuật kiểm thử động là thẩm định xem chương trình phần mềm có hoạt động đúng và đầy đủ các chức năng như những mong muốn của người sử dụng hay không,

do đó trong quy trình kiểm chứng và thẩm định chất lượng phần mềm thì kiểm thử động được sử dụng trong quy trình thẩm định

1.1.2 Mức kiểm thử

Một sản phẩm phần mềm từ khi bắt đầu phát triển đến khi hoàn thành và đưa đến tay người dùng cuối phải trải qua bốn mức kiểm thử đó là: Kiểm thử mức đơn vị, mức tích hợp, mức hệ thống và mức chấp nhận

Kiểm thử mức đơn vị

Kiểm thử mức đơn vị hay còn gọi là kiểm thử thành phần (module testing) là mức thấp nhất trong các mức độ kiểm thử Đơn vị ở đây có thể là một chức năng cụ thể, một hàm (function), một lớp trong lập trình hướng đối tượng hoặc một thành phần nhỏ đã hoàn thiện trong chương trình Thường thì các lập trình viên sẽ đảm nhận kiểm thử ở mức này để đảm bảo thời gian do việc phát hiện và sửa lỗi cần được thực hiện liên tục

Có thể áp dụng tất cả các kỹ thuật kiểm thử được nêu ở 1.2 và 1.3 để kiểm thử mức đơn vị

Đa số các lỗi của chương trình đều được phát hiện ở mức đơn vị, các lỗi về tích hợp chưa xuất hiện ở mức này Càng nhiều lỗi được tìm và sửa ở mức này sẽ càng giúp giảm lỗi ở những giai đoạn phát triển sau của chương trình Hiện nay, trong phương pháp phát triển phần mềm Agile có một kỹ thuật lập trình khá hiệu quả đó là phát triển dựa trên kiểm thử [4, tr.221-224] (TDD – Testing Driven Development), các lập trình viên sẽ thiết kế các ca kiểm thử trước khi lập trình và từ đó lập trình các chức năng để thỏa mãn các ca kiểm thử Việc xây dựng trước các ca kiểm thử sẽ giúp lập trình viên xác định được những thiếu sót hay lỗi có thể có nhằm hạn chế lỗi và rút ngắn thời gian thực hiện một cách hiệu quả

Do đơn vị là một thành phần nhỏ trong chương trình nên không thể hoạt động độc lập, để thực hiện kiểm thử động cần giả lập các Driver và Stub Driver sẽ đóng vai trò gọi thực thi đơn vị còn Stub đóng vai trò là các đơn vị có giao tiếp với đơn vị đang xét Xét một ví dụ cụ thể với đơn vị được kiểm thử là một hàm có tên TinhNghiemPTBac2 viết bằng ngôn ngữ lập trình C# có nhiệm vụ tính nghiệm của phương trình bậc hai một ẩn số Tham số đầu vào của hàm là các biến a, b, c kiểu số

thực và hàm này có gọi một hàm khác làm nhiệm vụ tính delta Driver trong ví dụ này

sẽ gán cứng ba tham số a, b, c sau đó gọi và truyền ba tham số này cho hàm TinhNghiemPTBac2 Stub ở đây là hàm tính delta có tên TinhDelta, có thể tính hoặc gán cứng giá trị trả về để kiểm tra xem hàm TinhNghiemPTBac2 hoạt động ra sao

public void TinhNghiemPTBac2(double a, double b, double c)

Kiểm thử mức đơn vị có ưu điểm là giúp người thực hiện dễ dàng xác định và sửa lỗi do phạm vi kiểm thử là rất nhỏ Việc phát hiện lỗi sớm sẽ giảm chi phí kiểm thử so với việc phát hiện lỗi muộn ở những giai đoạn phát triển sau Tuy nhiên kiểm thử mức đơn vị có một số nhược điểm như tốn nhiều thời gian để thực hiện, chưa phát hiện được các lỗi xảy ra khi tích hợp, ngoài ra Driver và Stub là giả lập chứ không phải chương trình hoàn chỉnh nên vẫn có thể có thiếu sót nhất định

Kiểm thử mức tích hợp

Sau khi một đơn vị chương trình hoàn thành việc kiểm thử mức đơn vị, đơn vị này sẽ được tích hợp với các đơn vị chương trình khác có liên quan để dần tạo nên chương trình tổng thể Các chức năng mà đơn vị chương trình cung cấp cũng như các tham số cần truyền để sử dụng sẽ được thông qua giao diện Các đơn vị khi được tích hợp sẽ làm việc với nhau thông qua các giao diện Các loại giao diện chủ yếu chia làm ba loại chính:

 Giao diện gọi hàm: một hàm trong đơn vị này sẽ gọi một hàm ở đơn vị khác

 Giao diện dùng chung bộ nhớ: cả 2 đơn vị sẽ cùng dung chung, chia sẻ một khối bộ nhớ Một ví dụ đơn giản là cả 2 đơn vị dùng chung một biến toàn cục

 Giao diện truyền bản tin: một đơn vị tạo và gửi một bản tin đến đơn vị khác Một ví dụ đơn giản về truyền bản tin là trong các ứng dụng Web, việc liên lạc giữa máy chủ và máy khách được truyền qua lại thông qua các bản tin HTTP/HTTPS

Kiểm thử mức tích hợp sẽ giúp tìm ra các thiếu sót, lỗi xuất hiện khi tích hợp nếu có Mặc dù ở mức kiểm thử đơn vị, một đơn vị cũng đã được kiểm tra giao tiếp với các đơn vị khác, cụ thể là các Stub và Driver giả lập, tuy nhiên dù có kiểm tra kỹ thì khi tích hợp với các đơn vị thực tế thì vẫn có thể xảy ra lỗi

Một số lỗi hay thiếu sót có thể xảy ra ở mức kiểm thử tích hợp [2]:

 Lỗi không đủ chức năng: lỗi này xuất hiện khi đơn vị cung cấp chức năng không như đơn vị sử dụng mong đợi

 Thay đổi tính năng: một đơn vị được sửa đổi nhưng các đơn vị sử dụng nó không được điều chỉnh theo nên chức năng của chương trình bị ảnh hưởng

 Sử dụng giao diện không đúng: đơn vị sử dụng không đúng giao diện của đơn

vị được gọi, có thể là do truyền sai kiểu dữ liệu

 Hiểu giao diện không đầy đủ: xảy ra khi đơn vị gọi hiểu nhầm hoặc không đầy

đủ giao diện của đơn vị được gọi Có thể ví dụ như trong lập trình hướng đối tượng, bằng việc nạp chồng phương thức, có thể có nhiều phương thức trùng tên nhưng khác nhau tham số đầu vào, việc truyền nhầm tham số có thể dẫn tới việc gọi sai phương thức dẫn tới sai kết quả trả về

 Không xử lý lỗi trả về: một đơn vị được gọi có thể trả về một mã lỗi nhưng đơn

vị gọi lại không kiểm tra lỗi mà coi đó là kết quả hoặc không biết sửa

 Lỗi xung đột tài nguyên: các đơn vị dùng chung bộ nhớ có thể bị xung đột khi

sử dụng Ví dụ: một đơn vị vừa ghi dữ liệu vào một biến toàn cục thì đơn vị khác lại ghi đè dữ liệu vào biến đó

 Các vấn đề về phi chức năng: ví dụ với các hệ thống thời gian thực, việc xử lý chậm có thể gây mất đồng bộ giữa các đơn vị

Một số chiến lược được áp dụng trong kiểm thử mức tích hợp:

 Tích hợp từng bước (incremental)

 Tích hợp từ trên xuống (top - down)

 Tích hợp từ dưới lên (bottom - up)

 Tích hợp kẹp (sandwich)

 Tích hợp tất cả cùng một thời điểm (big bang)

Kiểm thử mức hệ thống

Kiểm thử mức hệ thống có nhiệm vụ kiểm tra xem hệ thống hoặc chương trình sau khi

đã tích hợp đầy đủ các đơn vị có hoạt động đúng với tài liệu đặc tả yêu cầu hay không

Do hầu hết các lỗi, thiếu sót đã được kiểm tra và sửa chữa ở mức kiểm thử đơn vị và kiểm thử tích hợp nên ở mức kiểm thử hệ thống tuy vẫn kiểm tra lỗi nhưng tập trung nhiều vào đảm bảo chất lượng của chương trình hơn

Các loại kiểm thử được dùng trong mức kiểm thử hệ thống [6, tr.193-194]:

 Kiểm thử cơ bản (basic test): kiểm tra xem chương trình có thể cài đặt, gỡ bỏ được hay không, có cấu hình được không,

 Kiểm thử chức năng (Functionality test): kiểm tra tổng thể các chức năng mà chương trình cung cấp

 Kiểm thử khả năng chịu lỗi (Robustness test): chương trình có thể hoạt động nếu xảy ra lỗi hay không

 Kiểm thử tương thích (Interoperability test): chương trình có thể tương thích với các phần mềm khác trong cùng môi trường hoạt động hay không

 Kiểm thử hiệu năng (performance test): kiểm tra xem hiệu năng của chương trình có đảm bảo không Ví dụ: thời gian xử lý yêu cầu

 Kiểm thử khả năng mở rộng (Scalability test): kiểm tra giới hạn mà chương trình có thể mở rộng như chức năng, tài nguyên, lượng truy cập,

 Kiểm thử khả năng chịu tải (Stress test): kiểm tra giới hạn tối đa mà chương trình có thể xử lý khi có áp lực cao Ví dụ: nhiều người truy cập cùng lúc,

 Kiểm thử khả năng ổn định quá tải (Stability test): kiểm tra xem chương trình

có thể duy trì hoạt động trong một thời gian quá tải kéo dài hay không

 Kiểm thử độ tin cậy (Reliability test): kiểm tra xem chương trình có thể hoạt động trong một thời gian dài mà không có lỗi xảy ra

 Kiểm thử tài liệu hướng dẫn sử dụng (Documentation test): kiểm tra xem tài liệu hướng dẫn sử dụng cho người dùng cuối có chính xác và dễ dùng không

 Kiểm thử tính pháp lý (Regulatory test): kiểm tra tính pháp lý của chương trình

có phù hợp với quy định của chính phủ nước sở tại hay không

 Kiểm thử bảo mật (Security test): kiểm tra xem chương trình có đảm bảo khả năng bảo mật, an toàn thông tin trước sự xâm phạm có chủ ý từ bên ngoài hay bên trong không

 Kiểm thử khả năng phục hồi (Recovery test): kiểm tra xem chương trình có thể khôi phục hoạt động ổn định, khôi phục dữ liệu nếu bị tấn công hoặc mất dữ liệu hay không

Kiểm thử mức chấp nhận

Ở mức kiểm thử mức chấp nhận, người thực hiện việc kiểm tra chương trình chính là những người sẽ sử dụng trực tiếp chương trình phần mềm sau này hay còn gọi là người dùng cuối Người dùng cuối là những người hiểu hơn ai hết cái họ muốn ở sản phẩm như phần mềm có đáp ứng đầy đủ những chức năng mà họ cần hoặc có đúng với quy trình công việc mà họ vẫn làm hay không? giao diện chương trình có dễ sử dụng hay không? các thao tác sử dụng có quá phức tạp hay không? đây là những vấn đề mà các kiểm thử viên hay người phát triển không thể kiểm tra được chính xác Đây cũng là mức quyết định xem sản phẩm đã thực sự hoàn thiện để chuyển tới tay người dùng hay chưa Các thiếu sót, lỗi sẽ được ghi lại trong quá trình kiểm tra và chuyển tới đội ngũ phát triển để sửa chữa

Kiểm thử mức chấp nhận giúp đảm bảo chương trình phần mềm có thể làm hài lòng người sử dụng đem lại sự thống nhất về kỹ thuật giữa đội ngũ phát triển và khách hàng Tuy nhiên kiểm thử mức chấp nhận cũng có một số nhược điểm như tốn kém chi phí sửa chữa nếu phát sinh lỗi, thiếu sót, thay đổi Ngoài ra, người dùng thường sử dụng chương trình một cách cẩn thận, không cố tình tạo ra các vi phạm (nhập sai kiểu

dữ liệu, dùng sai quy cách) khiến lỗi chưa thể bị phát hiện trong quá trình kiểm tra

Kiểm thử hồi quy

Trong quá trình phát triển phần mềm, nếu có một sự thay đổi xảy ra như thay đổi yêu cầu chức năng, quy trình xử lý thì đòi hỏi cần phải thực hiện việc kiểm tra lại để đảm bảo rằng chương trình phần mềm vẫn hoạt động tốt, không phát sinh ra lỗi, kiểm thử hồi quy sẽ thực hiện việc này Kiểm thử hồi quy không phải là một mức kiểm thử giống như các mức đã nêu ở trên, nó có thể thực hiện lại các mức kiểm thử và sử dụng lại các ca kiểm thử đã được xây dựng Hình 1.2 minh họa việc thực hiện kiểm thử ở các mức lần lượt từ kiểm thử mức đơn vị đến kiểm thử mức chấp nhận và áp dụng kiểm thử hồi quy để thực hiện lại việc kiểm thử các mức kiểm thử đơn vị, tích hợp và

hệ thống

Hình 1.2 Kiểm thử hồi quy được thực hiện tại các mức kiểm thử khác nhau

Ưu điểm của kiểm thử hồi quy là đảm bảo các chức năng vẫn hoạt động tốt sau khi có sự thay đổi, chỉnh sửa, ngoài ra nó cũng giúp xác định được các lỗi phát sinh sau khi chương trình được thay đổi Tuy nhiên nhược điểm của kiểm thử hồi quy là chi phí và thời gian để thực hiện khá tốn kém

Ca kiểm thử

Ca kiểm thử là một tập các giá trị đầu vào và đầu ra mong đợi đối với mỗi hành vi cần kiểm thử của phần mềm Để thực hiện kiểm thử động thì cần phải thiết kế các ca kiểm thử hiệu quả có khả năng phát hiện nhiều lỗi nhất với thời gian, chi phí và công sức tối thiểu Có hai cách tiếp cận để thiết kế các ca kiểm thử, đó là kiểm thử hộp đen và kiểm thử hộp trắng

Kiểm thử hộp đen

Với cách tiếp cận hộp đen, có thể xem chương trình như một chiếc hộp màu đen khiến người sử dụng không thể nhìn được mã nguồn, cấu trúc, thuật toán bên trong đó cũng như cách thức nó hoạt động như thế nào Người thực hiện việc kiểm thử chỉ có thể thao tác với các chức năng mà chương trình cung cấp, đưa dữ liệu vào và nhận được

dữ liệu ra sau khi chương trình xử lý, tính toán Kiểm thử hộp đen đôi khi còn được gọi là kiểm thử chức năng hay kiểm thử về cách hoạt động

Kiểm thử hộp đen cũng chia làm kiểm thử hộp đen tĩnh và hộp đen động Kiểm thử hộp đen tĩnh chính là kiểm tra tài liệu đặc tả yêu cầu để xác định các chức năng mà chương trình cung cấp cũng như yêu cầu về đầu vào, đầu ra Kiểm thử hộp đen động chính là kiểm thử chức năng của chương trình đang chạy để kiểm tra xem có lỗi, thiếu sót chức năng và có đúng với đặc tả hay không

Phương pháp kiểm thử hộp đen có ưu điểm là không yêu cầu người thực việc kiểm thử phải biết lập trình hay tham gia vào quá trình viết mã nguồn cho chương trình, thậm chí người dùng cuối cũng có thể tham gia kiểm thử Phương pháp cũng không phụ thuộc vào cài đặt thuật toán, nếu có thay đổi trong mã nguồn vẫn có thể sử dụng lại ca kiểm thử cũ Phương pháp này cũng giúp loại bỏ những nhầm lẫn trong việc thống nhất kỹ thuật, chức năng mà chương trình cung cấp giữa người dùng cuối

và đội ngũ thực hiện do đưa ra chương trình trực quan và rất hiệu quả khi kiểm thử những chương trình lớn Tuy nhiên nhược điểm của phương pháp kiểm thử hộp đen là

Kiểm thử mức

đơn vị

Kiểm thử mức tích hợp

Kiểm thử mức

hệ thống

Kiểm thử mức chấp nhận Kiểm thử hồi quy

việc kiểm thử đầy đủ các trường hợp dữ liệu vào có thể có là không khả thi Phương cũng chỉ phát hiện ra các lỗi có thể quan sát được và nếu có lỗi thì không chỉ ra được nguyên nhân, vị trí gây ra lỗi Ngoài ra nếu không có tài liệu đặc tả chính xác thì rất khó để thiết kế ca kiểm thử chính xác

Kiểm thử hộp trắng

Kiểm thử hộp trắng là phương pháp kiểm thử dựa vào các cấu trúc, thuật toán bên trong của chương trình để xác định chương trình có thực hiện đúng không Để thực hiện kiểm thử hộp trắng đòi hỏi người thực hiện phải có kiến thức về lập trình và kiến trúc phần mềm đang được kiểm thử để có thể truy cập vào mã nguồn, cấu trúc thuật toán Một số tên gọi khác của kiểm thử hộp trắng là kiểm thử hộp thủy tinh, hộp trong suốt hay kiểm thử cấu trúc, phương pháp này thường được dùng ở mức kiểm thử đơn

vị

Kiểm thử hộp trắng cũng chia ra làm kiểm thử hộp trắng tĩnh và hộp trắng động Kiểm thử hộp trắng tĩnh chính là thực hiện các kỹ thuật rà soát còn kiểm thử hộp trắng động là sử dụng các kỹ thuật kiểm thử luồng điều khiển, kiểm thử luồng dữ liệu động và kiểm thử miền

Ưu điểm của phương pháp là đảm bảo tất cả câu lệnh trong chương trình đều được thực thi ít nhất một lần giúp tránh lỗi tiềm ẩn, tối ưu hóa mã nguồn Ngoài ra do người thực hiện việc kiểm thử hiểu về mã nguồn, cấu trúc thuật toán, kiến trúc của chương trình nên có thể kiểm thử một cách kỹ lưỡng chương trình Tuy nhiên phương pháp cũng có nhược điểm như đòi hỏi người thực hiện phải hiểu về mã nguồn, cấu trúc thuật toán, kiến trúc của chương trình Áp dụng phương pháp khiến tốn kém chi phí, nhân lực và thời gian khi thực hiện do yêu cầu kỹ thuật khá phức tạp Ngoài ra để kiểm thử tất cả các đường dẫn trong chương trình là việc không khả thi và nếu thay đổi cài đặt thuật toán trong mã nguồn thì phải thiết kế lại ca kiểm thử Một nhược điểm nữa của phương pháp là khi thực hiện không đảm bảo các chức năng của chương trình hoạt động đúng với tài liệu đặc tả

Nên lựa chọn cách tiếp cận hộp đen hay hộp trắng để thiết kế ca kiểm thử?

Mỗi cách tiếp cận đều có ưu và nhược điểm, khi thiết kế ca kiểm thử nên sử dụng kết hợp cả hai cách để đạt hiệu quả tốt nhất với mỗi ca kiểm thử

1.1.3 Kiểm thử tự động

Kiểm thử phần mềm là một công việc tốn nhiều thời gian và chi phí, thông thường thời gian dành cho việc kiểm thử chiếm hơn 50% tổng thời gian phát triển phần mềm Ngoài ra, để thực hiện kiểm thử đòi hỏi kiểm thử viên phải kiên nhẫn và tỉ mỉ, chính những điều này dẫn tới sự cần thiết của kiểm thử tự động Kiểm thử tự động sẽ thực hiện tự động các ca kiểm thử theo một kịch bản cho sẵn hoặc tự nó sinh ra Kiểm thử

tự động giúp rút ngắn thời gian, chi phí, nhân lực cho dự án phần mềm Một ưu điểm nữa là kiểm thử tự động cung cấp cho chúng ta khả năng để thực hiện kiểm thử hồi quy với các chức năng mà mã nguồn liên tục thay đổi Tuy nhiên đối với một số ca

kiểm thử phức tạp thì không thể sử dụng kiểm thử tự động mà vẫn cần phải thực hiện kiểm thử thủ công

1.1.4 Ứng dụng Web

Khái niệm ứng dụng Web

Ứng dụng Web là một phần mềm mà người dùng có thể tương tác thông qua trình duyệt Web Ứng dụng Web không đòi hỏi người dùng phải cài đặt trước khi sử dụng

và có thể tương tác trên bất kỳ hệ điều hành hoặc thiết bị nào miễn là môi trường đó có thể cài đặt và sử dụng một trình duyệt Web đủ tiêu chuẩn Ứng dụng Web được cài đặt trên máy chủ và giao tiếp với máy khách thông qua các bản tin HTTP, HTTPS

Sự khác biệt giữa Ứng dụng Web và Website

Về mặt hoạt động thì cả ứng dụng Web lẫn Website đều là các ứng dụng phần mềm được người dùng tương tác thông qua trình duyệt Web chính vì thế nên khái niệm ứng dụng Web và Website thường quy về chung làm một Tuy nhiên Website thiên về khuynh hướng chỉ truyền tải thông tin đến người dùng còn ứng dụng Web thiên về khuynh hướng tương tác qua lại giữa người dùng và ứng dụng Có thể ví dụ đơn giản

về Website như sau: Website tin tức cung cấp cho người dùng các thông tin nhưng họ chỉ có thể đọc chứ không thể chỉnh sửa Minh họa về ứng dụng Web có thể nói đến ứng dụng Google Docs cho phép người dùng tạo văn bản, chỉnh sửa và quản lý đem lại

sự tương tác như một phần mềm thực sự trên máy tính

Sự khác biệt giữa mô hình máy khách – máy chủ (C-S) truyền thống và Web

Ở phía máy khách thì mô hình C-S truyền thống đòi hỏi với mỗi hệ điều hành khác nhau thì phải thiết kế ứng dụng phù hợp với hệ điều hành đó và để sử dụng ứng dụng thì cần phải cài đặt, còn với mô hình Web thì do được sử dụng thông qua các trình duyệt Web nên chỉ cần được thiết kế cho phù hợp chuẩn chung (HTML, các thành phần khác như CSS, ngôn ngữ lập trình phía máy khách) mà các nhà cung cấp trình duyệt Web đã thỏa thuận

Trên lý thuyết thì chỉ cần nhà phát triển đáp ứng được các chuẩn mà nhà cung cấp trình duyệt Web đề ra thì các nội dung hiển thị trên các trình duyệt khác nhau sẽ là đồng nhất, tuy nhiên thực tế thì với những trình duyệt khác nhau, nội dung hiển thị có thể khác nhau đôi chút, các tính năng có thể chưa chắc hoạt động ổn định như mong muốn

Việc kiểm thử các tính năng được cung cấp của ứng dụng dựa theo các sự kiện (click chuột, nhấn phím, kết hợp giữa chuột và phím) là rất phức tạp do các sự kiện có thể được phối hợp, lồng ghép với nhau (ví dụ: single-click, double-click, tổ hợp các phím kết hợp lại) Tuy nhiên thì với các ứng dụng được sử dụng thông qua trình duyệt Web thì việc kiểm thử đơn giản hơn Lý do là các trình duyệt Web hầu hết nguyên bản chỉ có nhiệm vụ là hiển thị dữ liệu nên việc giao tiếp giữa người dùng và trình duyệt Web chỉ đơn giản là các sự kiện single-click, submit button hay mouse over-hover mặc

dù sau này dựa vào các Web Engine (Javascript, activeX) có thể hỗ trợ thêm một số sự

kiện phức tạp hơn như drap hay drop tuy nhiên vẫn bị giới hạn do có thể một số sự kiện (ví dụ phím tắt) được đặc tả dành riêng cho trình duyệt đang chạy ứng dụng Web

đó

Trong ứng dụng máy khách của mô hình C-S Web thì cũng có 2 loại là Client: Ở phía máy khách thì ứng dụng chỉ mang tính hiển thị, đưa yêu cầu còn xử lý, lưu trữ dữ liệu thì do máy chủ thực thi, các vấn đề không tương thích sẽ bị loại trừ khá nhiều, việc kiểm thử trên máy khách lúc này trở nên đơn giản; còn Thick-Client: ở phía máy khách thì ứng dụng ngoài hiển thị, đưa yêu cầu thì còn có khả năng xử lý một phần, phía máy chủ cũng sẽ xử lý phần còn lại và chứa dữ liệu (Ví dụ đơn giản: bẫy lỗi ngay trên máy khách) thì lúc này các vấn đề không tương thích sẽ dễ xảy ra

Thin-1.2 Kỹ thuật kiểm thử tĩnh

Kiểm thử tĩnh là kỹ thuật không yêu cầu phải biên dịch và chạy mã nguồn chương trình để thực hiện việc kiểm thử phần mềm Kỹ thuật này kiểm thử chương trình bằng cách kiểm tra cú pháp, cấu trúc mã nguồn của chương trình hoặc rà soát các tài liệu liên quan như tài liệu đặc tả, tài liệu thiết kế để tìm ra lỗi Trong quy trình kiểm chứng

và thẩm định chất lượng phần mềm thì kiểm thử tĩnh được sử dụng trong quy trình kiểm chứng

Mục đích chính của kỹ thuật kiểm thử tĩnh là giúp phát hiện, lường trước lỗi cũng như các thiếu sót, nhầm lẫn có thể có trong quá trình phát triển phần mềm một cách sớm nhất Điều này sẽ giúp giảm chi phí, thời gian và nhân lực để sửa chữa, khắc phục lỗi nếu xảy ra Việc thực hiện kiểm thử tĩnh có thể bằng tay (rà soát) hoặc tự động bằng máy (phân tích tĩnh)

Kỹ thuật kiểm thử tĩnh đòi hỏi người thực hiện phải có kiến thức và kinh nghiệm tốt Ngoải ra với những chương trình có độ phức tạp cao thì để thực hiện kỹ thuật này sẽ mất rất nhiều thời gian

1.2.1 Rà soát

Các kỹ thuật rà soát có thể chia ra làm các bước sau:

 Rà soát không chính thức (informal review): thực hiện bằng cách đọc các tài liệu liên quan và đưa ra các ghi chú, chưa cần phải phát hiện lỗi

 Phản biện chéo (peer review): việc rà soát được thực hiện bởi đội ngũ lập trình

dự án phần mềm, mọi người cùng tham gia thảo luận để đưa ra thống nhất chung về vấn đề kỹ thuật cho phù hợp với dự án Cả đội sẽ cùng nhau rà soát

mã nguồn, tìm lỗi và đưa ra cách giải quyết

 Thông qua (walkthrough): người viết các mã nguồn, tài liệu đặc tả, thiết kế, sẽ giải thích từng bước trước toàn đội dự án nhằm đạt được sự hiểu rõ, đồng thuận, sau đó nhận các phản hồi góp ý của thành viên trong đội dự án và đưa ra thay đổi hợp lý

 Thanh tra (inspection): các thành viên quan trọng trong đội dự án sẽ tham gia họp, một danh sách các vấn đề cần rà soát sẽ được lập và đưa ra để phát hiện lỗi

và sữa chữa Thanh tra khác thông qua ở chỗ người trình bày mã nguồn, tài liệu đặc tả, thiết kế không phải là người trực tiếp viết mà là một người khác, điều này khiến người trình bày phải thật sự hiểu về những gì sẽ giải thích

Vai trò của một số thành viên tham ra thực hiện kỹ thuật rà soát [6, tr.56-57]:

 Chủ tịch: người đóng vai trò chủ trì cuộc họp

 Tác giả: người viết mã nguồn, tài liệu đặc tả, thiết kế đồng thời thực hiện các thay đổi được đề xuất

 Người trình bày: người trình bày các tài liệu cần rà soát, có thể là tác giả nếu ở bước thông qua

 Rà soát viên: người thực hiện việc nghiên cứu tài liệu, mã nguồn và đưa ra các câu hỏi và đề xuất thay đổi

 Thư ký: người ghi chép lại các vấn đề được phát hiện trong cuộc họp

 Quan sát viên: những người chưa có kinh nghiệm về rà soát, tham gia cuộc họp

để học kinh nghiệm

1.2.2 Kiểm thử dòng dữ liệu tĩnh

Một đơn vị chương trình như một hàm, một module là một chuỗi các câu lệnh thực hiện tuần tự theo thứ tự khai báo biến, tính toán, gán giá trị, trả ra kết quả Khi một biến được khai báo thì cần phải được tính toán, gán giá trị và được tham chiếu trong một bước nào đó trong đơn vị chương trình, tuy nhiên trong quá trình lập trình, biến này có thể không được tham chiếu hoặc sử dụng không đúng gây ra lãng phí hoặc sai sót Từ vấn đề trên, một ý tưởng được đưa ra đó là có thể thực hiện kiểm thử theo dòng

dữ liệu Dòng dữ liệu là một loạt các thay đổi trạng thái của biến bắt đầu từ khai báo đến khi trả ra kết quả Một dòng dữ liệu sẽ gồm một tập các đường đi và với mỗi đường đi này sẽ được thiết kế một ca kiểm thử để kiểm tra tính đúng đắn của nó Kỹ thuật kiểm thử dòng dữ liệu chia làm hai loại là kiểm thử dòng dữ liệu tĩnh và kiểm thử dòng dữ liệu động Kỹ thuật kiểm thử dòng dữ liệu tĩnh không yêu cầu chạy chương trình và có thể phát hiện các vấn đề về khai báo, gán giá trị và tham chiếu biến

Các vấn đề bất thường về dòng dữ liệu theo [6, tr.113-114] được chia làm ba loại:

 Loại 1: Gán giá trị rồi lại gán tiếp giá trị Xem xét hai câu lệnh ở hình 1.3, có hai hàm f1 và f2 với 2 tham số lần lượt được truyền vào là y1 và y2 Có thể giải thích vấn đề này theo bốn tình huống sau:

o Câu lệnh thứ nhất dư thừa khi câu lệnh thứ hai được thực hiện

o Câu lệnh thứ nhất bị nhầm lẫn khi lập trình, câu lệnh đúng có thể là z = f1(y1)

o Câu lệnh thứ hai bị nhầm lẫn, câu lệnh đúng có thể là

Hình 1.3 Các câu lệnh tuần tự có bất thường loại 1

Chỉ người lập trình đoạn mã nguồn này mới có thể giải thích rõ được vấn đề thuộc tình huống nào trong bốn tình huống đã nêu Những vấn đề bất thường như này rất hay xảy ra nên cần phân tích mã nguồn để phát hiện

 Loại 2: Chưa gán giá trị nhưng được tham chiếu Xem xét câu lệnh ở hình 1.4, biến y2 chưa được gán giá trị đã được tham chiếu để tính toán Có thể giải thích

vấn đề này theo hai tình huống sau:

o Biến y2 bị quên gán giá trị

o Có sự nhầm lẫn khi tham chiếu biến y2, có thể biến đáng lẽ được tham chiếu là biến y3 đã được gán ở bước nào đó phía trên câu lệnh tính toán này

int x, y1 = 1, y2;

x = y1 + y2;

Hình 1.4 Câu lệnh có bất thường loại 2

 Loại 3: Đã được gán giá trị nhưng không được sử dụng

Huang [5] đã giới thiệu ý tưởng về trạng thái của biến trong chương trình tương ứng với những bất thường về dòng dữ liệu theo một sơ đồ chuyển trạng thái như hình 1.5

Hình 1.5 Sơ đồ chuyển trạng thái của một biến tương ứng với những bất thường về

dòng dữ liệu

Các trạng thái của biến gồm:

 U (Undefined): trạng thái chưa được gán giá trị

 D (Defined): trạng thái đã được gán giá trị nhưng chưa được tham chiếu

 R (Referenced): trạng thái đã được gán giá trị và đã được tham chiếu

 A (Abnormal): trạng thái bất thường

Việc sử dụng kỹ thuật kiểm thử dòng dữ liệu tĩnh rất hiệu quả trong việc phát hiện ra các bất thường về biến tuy nhiên vẫn cần kết hợp với kỹ thuật kiểm thử dòng

dữ liệu động để có thể phát hiện thêm các lỗi tiềm ẩn của chương trình

1.3 Kỹ thuật kiểm thử động

Kiểm thử động là kỹ thuật chỉ được thực hiện khi mã nguồn chương trình phần mềm được biên dịch và chạy Mục đích chính của kỹ thuật kiểm thử động là thẩm định xem chương trình phần mềm có hoạt động đúng và đầy đủ các chức năng như những mong muốn của người sử dụng hay không, do đó trong quy trình kiểm chứng và thẩm định chất lượng phần mềm thì kiểm thử động được sử dụng trong quy trình thẩm định

Kỹ thuật kiểm thử động chia làm hai loại là kiểm thử chức năng và kiểm thử phi chức năng Kiểm thử chức năng được thực hiện bằng cách sử dụng trực tiếp chức năng cần được kiểm thử, sau đó đưa dữ liệu đầu vào và nhận được dữ liệu đầu ra Dữ liệu đầu ra này sẽ được so sánh với dữ liệu đầu ra được ước lượng trước đó dựa theo

dữ liệu đầu vào và tài liệu đặc tả để tìm ra lỗi hoặc thiếu sót Kiểm thử phi chức năng bao gồm nhiều loại như kiểm thử hiệu năng hoạt động, độ tin cậy, khả năng bảo mật, khả năng tương thích, tính sẵn sàng

Kỹ thuật kiểm thử động có ưu điểm là thời gian và chi phí thực hiện thấp, có thể thực hiện được ở tất cả các mức kiểm thử Tuy nhiên nhược điểm của kỹ thuật là đòi hỏi phải biên dịch và chạy chương trình trước khi kiểm thử Khi có lỗi xảy ra, rất khó

để tìm ra nguyên nhân và vị trí mã nguồn gây ra lỗi Trong khuôn khổ luận văn, xin trình bày ba kỹ thuật kiểm thử động là kỹ thuật kiểm thử hàm, kiểm thử dòng điều khiển và kiểm thử dòng dữ liệu động

1.3.1 Kiểm thử hàm

Theo [1, tr.97], Kiểm thử hàm hay còn gọi là kiểm thử chức năng là các hoạt động kiểm tra chương trình dựa trên tài liệu đặc tả chức năng Kiểm thử hàm dựa trên quan niệm rằng bất kỳ chương trình nào cũng được coi là một hàm ánh xạ các giá trị từ miền dữ liệu đầu vào vào miền dữ liệu đầu ra của nó [1, tr.10] Với cách tiếp cận của kiểm thử hàm, để xác định các ca kiểm thử, thông tin duy nhất được dùng là đặc tả của phần mềm cần kiểm thử

Một hàm trong toán học được định nghĩa bởi cặp các tập (Xi, Yi) trong đó Xi là tập giá trị đầu vào và Yi là tập giá trị đầu ra Một chương trình P được xem là một hàm chuyển đổi tập giá trị đầu vào Xi thành tập giá trị đầu ra Yi, có thể viết là Yi = P(Xi) Xét một số ví dụ sau:

 Ví dụ 1.1: Y1 = √X1 Trong ví dụ này P là hàm căn bậc 2

 Ví dụ 1.2: Y2 = DoSomething(X2) Trong ví dụ này P là hàm DoSomething() nhận giá trị đầu vào X2 để tính toán và trả về kết quả cho Y2

 Ví dụ 1.3: Y3 = SortDesc(X3) Trong ví dụ này P là thuật toán sắp xếp mảng X3 theo giá trị giảm dần, đầu ra là mảng Y3 đã được sắp xếp

Thiết kế các ca kiểm thử cho việc kiểm thử hàm có thể dựa trên các kỹ thuật tại [6, tr.235-257]:

 Kiểm thử cặp

 Kiểm thử phân lớp tương đương

 Kiểm thử giá trị biên

 Bảng quyết định

 Kiểm thử ngẫu nhiên

 Đoán nhận lỗi

1.3.2 Kiểm thử dòng điều khiển

Hai dạng câu lệnh chính trong mã nguồn chương trình là câu lệnh gán và câu lệnh điều kiện Có thể nhận ra câu lệnh gán bằng biểu tượng dấu “=”, ví dụ như x = 2 * y, trong

đó x và y là các biến Các câu lệnh điều kiện là các câu lệnh như if(), for(), while(), switch(), , ví dụ như if(x > 2) thì sẽ kiểm tra xem biến x có lớn hơn 2 hay không Trong chương trình, nếu như câu lệnh điều kiện bị thiếu hoặc viết sai có thể dẫn tới việc một đoạn mã nào đó không được thực hiện gây ra lỗi hoặc thất bại Ý tưởng của kiểm thử dòng điều khiển chính là việc xây dựng một đồ thị dòng điều khiển và thiết

kế các ca kiểm thử dựa trên các đường đi của đồ thị đó Đồ thị dòng điều khiển là đồ thị có các đỉnh tương ứng với các câu lệnh hay nhóm các câu lệnh và các cạnh là các dòng điều khiển giữa các câu lệnh hay nhóm các câu lệnh

Để xây dựng đồ thị dòng điều khiển cần dựa trên các biểu tượng như hình 1.6 Hình chữ nhật đại diện cho câu lệnh gán hay nhóm câu lệnh gán, hình thoi đại diện cho câu lệnh điều kiện, hình tròn không chứa câu lệnh mà chỉ đại diện cho điểm hợp nhất các câu lệnh (thường dùng cho vòng lặp)

Hình 1.6 Các biểu tượng xây dựng đồ thị dòng điều khiển

Để minh họa rõ hơn về xây dựng đồ thị dòng điều khiển, xin xét ví dụ hình 1.7

và đồ thị dòng điều khiển của nó ở hình 1.8 Hình 1.7 minh họa mã nguồn của một đoạn mã tính tổng các số nguyên từ 1 đến 9

int i, n = 10, sum = 0;

for (i = 1; i < n; i++) {

Thực hiện các lệnh khác

Tiêu chí lựa chọn đường đi trong đồ thị dòng điều khiển để xây dựng ca kiểm thử

[6, tr.96-101]:

 Tất cả các đường đi Ví dụ hình 1.8 gồm hai đường 1-2-4 và 1-2-3-4

 Tất cả các câu lệnh được thực thi ít nhất một lần Ví dụ hình 1.8 là đường

Bảng 1.1 Các điều kiện con kết hợp trong câu lệnh điều kiện

STT x > 1 y < 2 if(x>1 && y<2)

 Chúng ta cần chắc chắn rằng một biến phải được gán đúng giá trị, tức là chúng

ta phải xác định được một đường đi của biến từ một điểm bắt đầu nơi nó được định nghĩa đến điểm mà biến đó được sử dụng Mỗi khi chưa có các ca kiểm thử để kiểm tra đường đi này, chúng ta không thể tự tin khẳng định là biến này

đã được gán giá trị đúng

 Ngay cả khi gán đúng giá trị cho biến thì các giá trị được sinh ra chưa chắc đã chính xác do tính toán hoặc các biểu thức điều kiện sai (biến được sử dụng sai)

Để tiến hành kiểm thử dòng dữ liệu động cần thực hiện theo các bước sau:

 Bước 1: Xây dựng đồ thị dòng dữ liệu

 Bước 2: Lựa chọn một hay nhiều tiêu chí kiểm thử dòng dữ liệu

 Bước 3: Xác định tập đường đi theo các tiêu chí đã chọn

 Bước 4: Lấy ra các biểu thức điều kiện từ tập đường đi, thực hiện giải các biểu thức điều kiện để có được các giá trị đầu vào cho các ca kiểm thử tương ứng với các đường đi này và tính toán giá trị đầu ra mong đợi của mỗi ca kiểm thử

Để xây dựng đồ thị dòng dữ liệu cần nắm rõ các định nghĩa và khái niệm tại [6, tr.116-121] Để minh họa rõ hơn về kiểm thử dòng dữ liệu động ta xét ví dụ hàm ReturnAverage hình 1.9 và đồ thị dòng dữ liệu động của ví dụ tại hình 1.10

public static double ReturnAverage(int[] value, int AS, int MIN, int MAX)

} if(tv > 0)

Hình 1.10 Đồ thị dòng dữ liệu minh họa hàm ReturnAverage

Các tiêu chí lựa chọn đường đi của kiểm thử dòng dữ liệu động ([1, tr.169-176],

[6, tr.121-124]) :

 All-defs: Mỗi một biến x và mỗi đỉnh i, giả sử x có một Global-def tại i, chọn

một Complete-path chứa một Def-clear-path từ đỉnh i tới

o đỉnh j sao cho tại j có chứa một Global-c-use của x hoặc

o cạnh (j; k) chứa một p-use của biến x

Ví dụ với biến “tv” thì Complete-path 1-2-3-4-5-6-3-7-9-10 thỏa mãn tiêu chí All-defs

 All-c-uses: Với mỗi một biến x và mỗi đỉnh i sao cho i là Global-def với biến x, chọn các Complete-path bao gồm các Def-clear-path từ đỉnh i tới tất cả các đỉnh

j sao cho j là Global-c-use của x

Ví dụ với biến “ti” thì có thể tìm được Complete-path có chứa Def-clear 2-3-4

là 1-2-3-4-5-6-3-7-8-10 thỏa mãn tiêu chí All-c-uses

 All-p-uses:Với mỗi một biến x và mỗi đỉnh i sao cho i là Global-def với biến x, chọn các Complete-path bao gồm các Def-clear-path từ đỉnh i tới tất cả các cạnh (j; k) sao cho có một p-use của x tại cạnh này

Ví dụ với biến “tv” ta có thể tìm được Complete-path có chứa Def-clear-path 3-7-8 là 1-2-3-7-8-10

2- All-p-uses / Some-c-uses: Tiêu chí này tương tự như tiêu chí All-p-uses ngoại trừ trường hợp khi có một định nghĩa của biến x mà không có một p-use của biến này Định nghĩa Some-c-uses như sau:

o Some-c-uses: Với mỗi một biến x và mỗi đỉnh i sao cho i là Global-def với biến x, chọn các Complete-path bao gồm các Def-clear path từ đỉnh i tới một

số đỉnh j sao cho j là Global c-use của x

Ví dụ để thỏa mãn tiêu chí All-p-uses/Some-c-uses với biến “i” có path 2-3-4-5-6, ta có thể chọn Complete-path 1-2-3-4-5-6-3-7-9-10

Def-clear- All-c-uses / Some-p-uses: tiêu chí này tương tự như tiêu chí All-c-uses ngoại trừ trường hợp khi có một định nghĩa của biến x mà không có một Global c-use của biến này Định nghĩa Some-p-uses như sau:

o Some-p-uses: Với mỗi một biến x và mỗi đỉnh i sao cho i là Global-def với biến x, chọn các Complete-path bao gồm các Def-clear path từ đỉnh i tới một

số cạnh (j; k) sao cho có một p-use của x tại cạnh này

Ví dụ với biến “AS” chỉ có một Global-def tại đỉnh 1, dễ thấy rằng không có Global-c-use của biến này Từ đỉnh 1, có p-use của “AS” tại các cạnh (3,7) có Def-clear-path-tương ứng với hai cạnh này là (1-2-3-7) Ta tìm được Complete-path chứa Def-clear-path (1-2-3-7) và thỏa mãn tiêu chí All-c-uses / Some-p-uses là 1-2-3-4-5-6-3-7-9-10

 All-uses: Tiêu chí này bao gồm các đường đi được sinh ra từ các tiêu chí uses và All-c-uses Điều này có nghĩa là với mỗi việc sử dụng (c-use hoặc p-use) của một biến thì có một đường đi từ định nghĩa của biến đó tới các sử dụng của nó

All-p- All-du-paths: Với mỗi một biến x và mỗi đỉnh i sao cho i là Global-def với biến

x, chọn các Complete-path chứa các tất cả các Du-path từ đỉnh i tới:

o tất cả các đỉnh j sao cho có một Global c-use của biến x tại j, và

o tất cả các cạnh (j; k) sao cho có một p-use của biến x tại (j; k)

1.4 Các loại kiểm thử ứng dụng Web

Ứng dụng Web về bản chất cũng là một phần mềm, chính vì vậy các loại kiểm thử áp dụng cho phần mềm cũng áp dụng cho ứng dụng Web Tuy nhiên có một số loại kiểm thử cần chú trọng hơn trong ứng dụng Web như kiểm thử giao diện người dùng, kiểm thử hiệu năng và kiểm thử an ninh, bảo mật

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

Đối với ứng dụng Web, giao diện người dùng được hiển thị thông qua các trình duyệt Web, trên lý thuyết thì chỉ cần nhà phát triển đáp ứng được các chuẩn mà nhà cung cấp trình duyệt Web đề ra thì các nội dung hiển thị trên các trình duyệt khác nhau sẽ là đồng nhất, tuy nhiên thực tế thì với những trình duyệt khác nhau, nội dung hiển thị có thể khác nhau đôi chút Kiểm thử giao diện người dùng giúp kiểm tra tính tương thích, nhất quán trên các trình duyệt Ngoài ra nó còn giúp đánh giá mức độ “quan tâm”

người dùng qua việc cung cấp các chỉ dẫn rõ ràng khi sử dụng Trong quá trình kiểm thử giao diện người dùng cũng nên chú trọng đến các khía cạnh như tính thẩm mỹ, sự hài hòa giữa các thành phần, tính tương tác [3, tr.216]

Trước khi bắt đầu thực hiện kiểm thử giao diện người dùng cho một ứng dụng,

để nắm được những tiêu chuẩn cần kiểm thử nên đặt ra hai câu hỏi:

 Ai là người dùng mà ứng dụng sẽ nhắm tới?

 Những tiếp cận thiết kế được sử dụng trong giao diện là gì?

Một ứng dụng Web thường có hai nhóm người dùng chính, một là nhóm người dùng phía máy chủ và nhóm người dùng phía máy khách Trên thực tế, nhóm người dùng phía máy chủ chính là các quản trị viên hệ thống, về mặt hiểu biết về kỹ thuật hay công nghệ thì họ thường tốt hơn nhóm người dùng phía máy khách chính vì thế nên việc kiểm thử giao diện người dùng cho hai nhóm này phải có những tiêu chuẩn khác nhau Để thiết lập những tiêu chuẩn này cần xem xét bốn yếu tố: kinh nghiệm sử dụng máy tính, kính nghiệm sử dụng Web, kiến thức chuyên môn trong các chức năng

mà ứng dụng Web cung cấp và kinh nghiệm sử dụng ứng dụng Web

Những tiếp cận thiết kế được sử dụng trong giao diện gồm ba loại:

 Tiếp cận thiết kế theo trải nghiệm người dùng trong thế giới thực, giúp người dùng dễ dàng hơn trong việc tiếp cận ứng dụng do nó gần giống với những gì

đã làm Một ví dụ minh họa là với những người làm việc văn phòng thì ứng dụng nên thiết kế giao diện giống như một bàn làm việc

 Tương tác người dùng Thiết kế cho phép người dùng tương tác với ứng dụng Web qua các liên kết hay input như textbox, button, radiobutton, checkbox hay combobox Các vấn đề cần xem xét khi kiểm thử loại tiếp cận này đó là:

o Đặt tên cho các thành phần input có chính xác không?

o Loại input được sử dụng có phù hợp với loại dữ liệu được nhập không?

o Bố trí thứ tự, vị trí các input có hợp lý không?

 Trình diễn dữ liệu Thiết kế cung cấp việc hiển thị thông tin cho người dùng quan sát qua các thành phần như bảng biểu, menu, dạng văn Các vấn đề cần xem xét khi kiểm thử loại tiếp cận này đó là:

o Lựa chọn kiểu hiển thị này có phù hợp với loại dữ liệu này không?

o Dữ liệu được hiển thị có đầy đủ, rõ ràng không?

o Xác định xem kiểu hiển thị dữ liệu này có thỏa mãn người dùng không?

Kiểm thử hiệu năng

Một trong những ưu điểm của ứng dụng Web là nó cho phép nhiều người dùng truy cập và sử dụng một hoặc nhiều chức năng khác nhau mà ứng dụng Web cung cấp trong cùng một thời điểm Với phần mềm thông thường thì ta có thể ước lượng được

số người dùng tối đa nhưng với ứng dụng Web thì rất khó ước lượng được Chính vì vậy cần phải kiểm thử hiệu năng của ứng dụng Web để đánh giá khả năng của nó trong các giai đoạn sử dụng bình thường và cao điểm có xảy ra vấn đề hay không Kiểm thử hiệu năng sẽ trả lời được các câu hỏi như ứng dụng có thể xử lý được tối đa bao nhiêu

yêu cầu trong một thời điểm?, nếu vượt quá khả năng xử lý tối đa thì ứng dụng sẽ xảy

ra vấn đề gì? Và ứng dụng có khả năng mở rộng được hay không?

Một trong những mục đích của việc kiểm thử hiệu năng đó là đảm bảo sự hài lòng của người sử dụng Một người bình thường khi sử dụng một ứng dụng Web ngoài những thỏa mãn yêu cầu về chức năng mà ứng dụng mang lại thì hai yếu tố quan trọng khác đó là tính đúng đắn và tính kịp thời Ví dụ đơn giản là một người khách hàng khi đến quán nước và yêu cầu gọi nước cam trong lúc quán rất đông khách Vì quán rất đông mà người phục vụ có hạn nên rất dễ xảy ra nhầm lẫn, tính đúng đắn thể hiện không tốt ở việc khách gọi nước cam mà phục vụ lại nhầm sang nước chanh và tính kịp thời thể hiện không tốt ở việc bắt khách đợi quá lâu mới có đồ uống Trong ứng dụng Web cũng vậy, nếu ở thời điểm ứng dụng có quá nhiều người dùng mà ứng dụng không đáp ứng được, đưa ra trả lời sai yêu cầu của người dùng hoặc thời gian xử lý quá lâu sẽ khiến người dùng không hài lòng Để kiểm thử hiệu năng cho ứng dụng Web có thể sử dụng công cụ hỗ trợ được đề xuất tại 2.2.3 của luận văn

Kiểm thử an ninh, bảo mật

Một trong những yếu tố khiến người sử dụng và nhà phát triển ứng dụng Web luôn trăn trở đó là khả năng an ninh và bảo mật của ứng dụng Tuy nhiên trên thực tế thì không ứng dụng Web nào có thể khẳng định hoàn toàn an toàn trước sự tấn công có chủ đích lẫn không chủ đích Đối với những ứng dụng Web phục vụ cho mục đích thương mại như ngân hàng hay bán hàng trực tuyến thì yếu tố bảo mật càng quan trọng, tuy nhiên nếu sử dụng các biện pháp bảo mật quá cứng rắn sẽ dẫn tới việc khó khăn khi sử dụng ứng dụng hoặc quá thô sơ thì lại dễ bị tổn thương [3, tr.416] Kiểm thử an ninh, bảo mật đối với ứng dụng Web là việc kiểm tra khả năng phòng thủ của ứng dụng trước sự tấn công, điều này đòi hỏi sự kết hợp giữa các kiến thức như lập trình, quản trị mạng, an ninh mạng, tuy nhiên hầu hết các kiểm thử viên đều không

có đầy đủ những kiến thức này nên việc kiểm thử an ninh, bảo mật thường được thực hiện bằng sự kết hợp của một đội ngũ chuyên gia

Theo [3, tr.412] thì các mối đe dọa chủ yếu đến an ninh, bảo mật của ứng dụng Web gồm:

 Tài nguyên mạng: sử dụng trái phép các tài nguyên mạng

Các mối đe dọa có thể đến từ các nguồn sau:

 Lỗi phần mềm hoặc phần cứng

 Lỗi do người dùng cố ý hoặc vô ý gây ra khi sử dụng

 Lỗi do tài nguyên, môi trường hệ thống gây ra như mất điện, cháy nổ,