Nghiên cứu kỹ thuật kiểm thử hướng mô hình và đánh giá tính tiện dụng áp dụng vào phát triển phần mềm quản lý lưu trữ và số hóa tài liệu

Luận văn thạc sỹ Nguyễn Hải Dương – CB130387 Với mong muốn nâng cao chất lượng sản phẩm đầu ra mà vẫn đảm bảo chi phí chấp nhận được khi phát triển ứng dụng, đồng thời giảm thiểu tối đa

Trang 1

Luận văn thạc sỹ Nguyễn Hải Dương – CB130387

1

MỤC LỤC

LỜI CAM ĐOAN 3

LỜI CẢM ƠN 4

DANH MỤC CÁC TỪ VIẾT TẮT VÀ THUẬT NGỮ 5

DANH MỤC CÁC BẢNG 6

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

MỞ ĐẦU 8

CHƯƠNG 1 KIỂM THỬ HƯỚNG MÔ HÌNH CHO ỨNG DỤNG WEB 14

1.1 Tổng quan 14

1.1.1 Kiểm thử 15

1.1.2 Kiểm thử hướng mô hình 17

1.1.3 So sánh và đánh giá 18

1.2 Phương pháp đặc tả mô hình [1][5] 19

1.2.1 Ngôn ngữ mô hình hóa 20

1.2.2 Hệ thống chuyển đổi nhãn (Labelled Transition System - LTS) 20

1.2.3 Máy trạng thái hữu hạn (Finite State Machine – FSM) 21

1.2.4 Máy trạng thái mở rộng (Extended State Machine – ESM) 22

1.3 Công cụ kiểm thử hướng mô hình 23

1.3.1 Tổng quan 23

1.3.2 Spec Explorer 24

1.3.3 Selenium 27

1.4 Đề xuất quy trình kiểm thử hướng mô hình áp dụng kết hợp công cụ Spec Explorer và Selenium 28

1.5 Kết luận chương 32

CHƯƠNG 2 ĐÁNH GIÁ TÍNH TIỆN DỤNG CỦA ỨNG DỤNG WEB 34

2.1 Giới thiệu 34

2.2 Tiêu chuẩn quốc tế về đánh giá tính tiện dụng 34

2.3 Xây dựng phương pháp đánh giá tính tiện dụng [2] 36

2.3.1 Tích hợp Mô hình tính tiện dụng của web vào MDWD 37

2.3.2 Mô hình tính tiện dụng của web 39

2.4 Quy trình áp dụng vào phát triển ứng dụng web 48

2.4.1 Bước 1: Thiết lập các yêu cầu đánh giá 49

2.4.2 Bước 2: Thiết lập các Đặc tính kỹ thuật của việc Đánh giá 49

2.4.3 Bước 3: Thiết kế 50

2.4.4 Bước 4: Thực hiện các đánh giá: 51

2.4.5 Bước 5: Phân tích các thay đổi 51

Trang 2

2

CHƯƠNG 3 THỰC NGHIỆM ÁP DỤNG VÀO PHÁT TRIỂN ỨNG DỤNG WEB 53

3.1 Giới thiệu bài toán 54

3.1.1 Thông tin chung về dự án 54

3.1.2 Mô tả ứng dụng và môi trường phát triển 54

3.1.3 Tiêu chuẩn ứng dụng theo Công văn Số 283/VTLTNN-NVTW-Bộ Nội Vụ 57 3.1.4 Mô hình xây dựng ứng dụng Quản lý lưu trữ 59

3.2 Mục tiêu thực nghiệm 59

3.3 Áp dụng kiểm thử hướng mô hình 60

3.3.1 Áp dụng quy trình 60

3.3.2 Tóm lược kết quả 66

3.4 Đánh giá tính tiện dụng của web 66

3.4.1 Áp dụng quy trình 66

3.4.2 Tóm lược kết quả 73

KẾT LUẬN 76

A CÁC KẾT QUẢ ĐẠT ĐƯỢC TRONG ĐỀ TÀI 76

Các kết quả chính đạt được trong đề tài: 76

Những khó khăn và hướng giải quyết 78

B HƯỚNG PHÁT TRIỂN CỦA ĐỀ TÀI 80

TÀI LIỆU THAM KHẢO 82

Trang 3

3

LỜI CAM ĐOAN

Tác giả xin cam đoan: Luận văn "Nghiên cứu kỹ thuật kiểm thử hướng mô hình

và đánh giá tính tiện dụng áp dụng vào phát triển phần mềm Quản lý lưu trữ và Số hóa tài liệu" là do bản thân tác giả tự thực hiện dưới sự hướng dẫn của PGS.TS Huỳnh Quyết Thắng - Viện Công nghệ thông tin và Truyền thông - Đại học Bách khoa Hà Nội; các thông tin số liệu và kết quả trong Luận văn có nguồn gốc rõ ràng, nội dung của Luận văn chưa từng được công bố trong bất kỳ một công trình nghiên cứu nào ở trong nước

Hà Nội, tháng 9 năm 2016

Tác giả Luận văn

Nguyễn Hải Dương

Trang 4

em thực hiện luận văn này Em xin chân thành cảm ơn Thầy!

Em xin gửi lời cảm ơn đến quý Thầy Cô Viện Công nghệ Thông tin & Truyền thông, Trường Đại học Bách Khoa Hà Nội đã truyền dạy cho em những kiến thức quý báu trong quá trình em học tập tại trường

Tôi xin gửi lời cảm ơn đến gia đình và bạn bè đã động viên và giúp đỡ để tôi có thêm động lực hoàn thành được luận văn này

Trong quá trình thực hiện, cũng như trong quá trình làm báo cáo, do trình độ lý luận cũng như kinh nghiệm thực tiễn còn hạn chế nên không thể tránh khỏi những thiếu sót, tác giả rất mong nhận được những ý kiến đóng góp của quý Thầy, Cô và mọi người

để tác giả có thể hoàn thiện luận văn một cách tốt nhất

Xin chân thành cảm ơn!

Trang 5

5

DANH MỤC CÁC TỪ VIẾT TẮT VÀ THUẬT NGỮ

Từ viết tắt,

LTS Labelled Transition System Hệ thống chuyển đổi nhãn

FSM Finite State Machine Máy trạng thái hữu hạn

ESM Extended State Machine Máy trạng thái mở rộng

Developerment

Phát triển ứng dụng web theo hướng

mô hình WUEP Web Usability Evaluation

Process Quy trình đánh giá tính tiện dụng của ứng dụng web UML Unified Modeling Language Ngôn ngữ mô hình hóa thống nhất

Trang 6

6

DANH MỤC CÁC BẢNG

Bảng 1: Phân tích về khả năng nhận biết 39

Bảng 2: Phân tích về khả năng tìm hiểu 41

Bảng 3: Phân tích về Khả năng hoạt động 42

Bảng 4: Phân tích về tính bảo vệ người dùng khỏi lỗi 43

Bảng 5: Phân tích về khả năng truy cập 43

Bảng 6: Phân tích về tính thẩm mỹ của giao diện người dùng 44

Bảng 7: Phân tích về Sự tuân thủ 45

Bảng 8: Phân tích về hiệu quả trong sử dụng 45

Bảng 9: Phân tích về tối ưu trong sử dụng 46

Bảng 10: Phân tích về sự hài lòng trong sử dụng 46

Bảng 11: Phân tích về bảo hộ rủi ro và nội dung 47

Bảng 12: Ví dụ về một phương pháp kiểm tra đánh giá 70

Bảng 13: Kết quả đánh giá định tính thu được dựa trên đánh giá của người dùng 73

Bảng 14: Kết quả đánh giá định lượng thu được dựa trên đánh giá của người dùng 73

Trang 7

7

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

Hình 1: Quy trình áp dụng Spec Explorer [5] 26

Hình 2: Quy trình kiểm thử hướng mô hình 30

Hình 3: Tích hợp WUM vào MDWD 38

Hình 4: Toàn cảnh tiến trình WUEP [2] 48

Hình 5: Giao diện phần mềm 56

Hình 6: Sơ đồ cấu trúc Ứng dụng Quản lý lưu trữ tài liệu 59

Hình 7: Mô hình kiểm thử tự sinh cho chức năng tài khoản 62

Hình 8: Phần cấu hình các action chuyển trạng thái và trỏ file gen Test Script 63

Hình 9: Phần định nghĩa mô hình kiểm thử 63

Hình 10: Phần định nghĩa mô hình test case 63

Hình 11: Mô hình Test Case tự sinh bởi công cụ 63

Hình 12: Mô tả code Test Script tự sinh 64

Hình 13: Quá trình tạo Test Case bằng Selenium và FireFox 65

Hình 14: Giao diện Phần mềm 68

Hình 15: Mô tả ví dụ 2.2 71

Trang 8

Với mong muốn nâng cao chất lượng sản phẩm đầu ra mà vẫn đảm bảo chi phí chấp nhận được khi phát triển ứng dụng, đồng thời giảm thiểu tối đa chi phí trong giai đoạn bảo trì (thường chiếm đến 70% chi phí trong chu kỳ sống của phần mềm ứng dụng [6]), tác giả đã lựa chọn đề tài này như một hướng nghiên cứu cho việc đảm bảo chất lượng sản phẩm phần mềm, đặc biệt là với các ứng dụng web

2 Tính cấp thiết của đề tài

Phát triển ứng dụng theo “kiến trúc hướng mô hình – Model Driven Architecture (MDA)” đang là một hướng đi đầy tiềm năng cho việc phát triển ứng dụng phần mềm nhanh chóng, tiện lợi và chính xác theo một quy chuẩn nhất định Nhưng lĩnh vực này vẫn còn rất mới mẻ và tồn tại nhiều rủi ro vì nhiều nguyên nhân như: Hệ thống được mô hình hóa bởi người dùng chưa đủ độ chính xác và tin cậy, việc sinh code từ mô hình chưa đủ độ chính xác cần có nên muốn sử dụng được vẫn cần phải chỉnh sửa lại, …

Ngoài ra, do nhu cầu rất lớn của xã hội mà các hệ thống website từ nhỏ đến lớn

đã và đang phát triển nhanh chóng về số lượng Tuy nhiên cùng với trình độ của đội ngũ kỹ thuật viên, định hướng phát triển sản phẩm phần mềm; với áp lực kinh doanh,

Trang 9

9

giá thành sản phẩm, … mà chất lượng của đa số các hệ thống website ở Việt Nam mới chỉ dừng ở mức “chấp nhận được” Các khâu từ thiết kế chi tiết, đến kiểm thử, đánh giá tính tiện dụng của ứng dụng thường đều bị lược bớt và chỉ tập trung vào việc mã hóa phần mềm để nhanh chóng cho ra các bản mẫu có thể sử dụng được ngay

Trong tình hình này, việc “Kiểm thử và đánh giá tính tiện dụng của ứng dụng phát triển theo kiến trúc hướng mô hình” là rất cần thiết Bởi lẽ nó đóng vai trò đánh giá một cách chuẩn xác kết quả của việc phát triển ứng dụng theo “kiến trúc hướng mô hình”, từ đó sẽ giúp ích rất nhiều trong việc cải thiện chất lượng cũng như giảm thiểu tối đi chi phí bảo trì cho các sản phẩm phần mềm, nhất là với các ứng dụng web

3 Mục đích, đối tượng, phạm vi nghiên cứu

(i) Nghiên cứu các kỹ thuật kiểm thử và đánh giá tính tiện dụng của các ứng dụng được phát triển theo kiến trúc hướng mô hình

(ii) Nghiên cứu và xây dựng hệ thống Quản lý lưu trữ và số hóa tài liệu theo hướng mô hình, theo chuẩn được công bố trong công văn Số 283/VTLTNN – NVTW –

Bộ Nội Vụ

(iii) Thực hiện áp dụng các kỹ thuật kiểm thử và đánh giá tính tiện dụng đã nghiên cứu ở (i) vào đánh giá hệ thống Quản lý lưu trữ và số hóa tài liệu (ii)

4 Phương pháp nghiên cứu

Một quá trình nghiên cứu khoa học luôn luôn theo một quy trình nhất định từ: Khảo sát nhu cầu thực tế, Thu thập tài liệu, Lựa chọn phương pháp, Lựa chọn công nghệ, và cuối cùng là áp dụng lý thuyết vào thực tế Và luận văn này cũng sẽ đi theo quy trình đó

B1 Khảo sát nhu cầu thực tế:

Vấn đề về chất lượng của sản phẩm phần mềm đang được quan tâm ngày một nhiều do nó đang trở thành một yếu tố quyết định dẫn đến sự thành bại của một ứng dụng Nắm bắt được nhu cầu đó, tác giả đã quan tâm và bắt tay vào nghiên cứu các kỹ

Trang 10

10

thuật nhằm nâng cao chất lượng cho các phần mềm nhưng vẫn đảm bảo chi phí hợp lý Thêm nữa, cần phải làm sao để có thể tích hợp được các kỹ thuật này ngay trong quy trình phát triển ứng dụng (web) để có thể phát hiện sớm các sai sót, hỏng hóc, lỗi… trong các giai đoạn đầu tiên của quá trình phát triển Điều này sẽ rất có lợi cho việc cắt giảm hao phí (về cả kinh tế và công sức lao động) một cách tối đa cho nhà phát triển, đảm bảo đạt được yêu cầu đặt ra ban đầu là: “nâng cao chất lượng với chi phí hợp lý”

B2 Thu thập tài liệu:

Do đây là một lĩnh vực còn rất mới mẻ trên thế giới và đặc biệt là ở Việt Nam, nên việc thu thập tài liệu cũng như tìm kiếm các công nghệ phụ trợ còn khá khó khăn Tác giả đã cố gắng tìm kiếm các tài liệu liên quan và nghiên cứu sự phù hợp của nó với hướng đi trong luận văn này Thường thì các tài liệu trong lĩnh vực này còn khá tổng quan và trừu tượng, chưa có một tài liệu nào thực sự hoàn chỉnh và đầy đủ, chi tiết để

có thể sử dụng trực tiếp Kết quả của công trình nghiên cứu này là tổng hợp của rất nhiều các tài liệu liên quan khác nhau trong lĩnh vực còn rất mới mẻ này

- Đánh giá tính tiện dụng của ứng dụng – tập trung vào việc đánh giá sự tiện dụng của giao diện người dùng cuối, giúp nâng cao trải nghiệm người dùng

và đạt được sự thỏa mãn của họ

Mỗi hướng đi nêu ra ở trên lại thuộc một lĩnh vực nghiên cứu độc lập với nhau, các lý thuyết và phương pháp áp dụng đều là độc lập, gây rất nhiều khó khăn trong quá trình nghiên cứu Tuy nhiên sau một thời gian nỗ lực nghiên cứu và tìm tòi, tác giả

Trang 11

và số hóa tài liệu”

Tương ứng với B3 sẽ là 2 công nghệ cần được lựa chọn thích hợp cho từng hướng đi Với hướng đi: Kiểm thử hướng mô hình, tác giả lựa chọn được 2 công cụ thích hợp là: Spec Explorer và Selenium Hai công cụ hỗ trợ có thể áp dụng được lý thuyết kiểm thử hướng mô hình cho ứng dụng (web) Với hướng đi: Đánh giá tính tiện dụng của ứng dụng (web) thì hiện tại không có một công cụ nào có thể hỗ trợ cho lý thuyết đã nghiên cứu, thêm nữa, đặc thù của hướng nghiên cứu này phụ thuộc căn bản vào cảm giác chủ quan của người dùng Do đó, khối lượng thực nghiệm chính cho hướng này vẫn là thực hiện một cách thủ công, kết hợp với Javascript cho các tác vụ tính toán cần thiết, đồng thời lấy ý kiến phản hồi thực tế từ phía người dùng cuối

B5 Áp dụng lý thuyết vào thực tế:

Dựa trên một dự án thực tế nhận được thông qua hợp đồng với khách hàng là Chi cục văn thư lưu trữ Tỉnh Phú Thọ về ứng dụng “Quản lý lưu trữ và số hóa tài liệu”, tác giả đã áp dụng ngay những nghiên cứu có được trong đề tài này vào phát triển ứng dụng web theo yêu cầu trên

Xuất phát điểm từ những tìm hiểu và nghiên cứu của bản thân, cùng sự trợ giúp

từ nhiều phía, đặc biệt là sự trợ giúp nhiệt tình từ PGS TS Huỳnh Quyết Thắng, tác giả đã thực hiện đề tài này trong khoảng thời gian khá eo hẹp và cũng đã đạt được một

số kết quả nhất định

Nội dung chính của Luận văn cũng như các kết quả đạt được sau quá trình nghiên cứu sẽ được mô tả chi tiết hơn trong các phần tiếp theo đây

Trang 12

12

5 Bố cục của luận văn

CHƯƠNG 1 – KIỂM THỬ HƯỚNG MÔ HÌNH CHO ỨNG DỤNG WEB

Chương này giới thiệu tổng quan về kiểm thử, kiểm thử hướng mô hình, các công cụ sinh kiểm thử tự động, kiểm thử hướng mô hình như Spec Explorer, Selenium…, và đề xuất quy trình áp dụng kiểm thử hướng mô hình cho ứng dụng web

CHƯƠNG 2 – ĐÁNH GIÁ TÍNH TIỆN DỤNG CỦA ỨNG DỤNG WEB

Chương này giới thiệu về tính tiện dụng của web (Web usability), các tiêu chuẩn quốc tế về đánh giá tính tiện dụng của ứng dụng, đề xuất một mô hình tính tiện dụng của web (Web Usability Model - WUM) để có thể tích hợp được vào quy trình phát triển ứng dụng (web) theo hướng mô hình Sau đó đưa ra quy trình

cụ thể để áp dụng WUM này vào phát triển ứng dụng web theo hướng mô hình

CHƯƠNG 3 – THỰC NGHIỆM ÁP DỤNG VÀO PHÁT TRIỂN ỨNG DỤNG WEB

Chương này trình bày thực nghiệm khi áp dụng lý thuyết của Chương 1 và

Chương 2 vào thực tế phát triển một ứng dụng web theo hướng mô hình, cụ thể là ứng dụng web “Quản lý lưu trữ và số hóa tài liệu” theo chuẩn được hướng dẫn trong Công văn Số 283/VTLTNN – NVTW – Bộ Nội Vụ Chương này sẽ bao gồm

3 phần chính:

1 Giới thiệu về bài toán nghiệp vụ cần xử lý: thông tin về dự án, mô tả yêu cầu, các tiêu chuẩn cần được đảm bảo theo công văn hướng dẫn, đưa ra mô hình kiến trúc của ứng dụng

2 Áp dụng kiểm thử hướng mô hình: Áp dụng lý thuyết và các kỹ thuật kiểm thử hướng mô hình đã nói ở Chương 1 vào việc phát triển ứng dụng web

“Quản lý lưu trữ và số hóa tài liệu”

3 Áp dụng đánh giá tính tiện dụng: Áp dụng lý thuyết và các kỹ thuật đánh giá tính tiện dụng, cũng như mô hình WUM đã được để xuất ở Chương 2 vào việc phát triển ứng dụng web “Quản lý lưu trữ và số hóa tài liệu”

Trang 13

13

Trong phần 2 và 3 sẽ đưa ra cụ thể các kết quả thực nghiệm tương ứng khi áp dụng lý thuyết vào thực tế phát triển ứng dụng web “Quản lý lưu trữ và số hóa tài liệu”

Các phần dưới đây sẽ bắt đầu nội dung chính của cuốn luận văn này

Trang 14

14

CHƯƠNG 1 KIỂM THỬ HƯỚNG MÔ HÌNH CHO ỨNG DỤNG

WEB 1.1 Tổng quan

Ngày nay, có rất nhiều các ứng dụng phần mềm nói chung, cũng như các ứng dụng web nói riêng được phát triển một cách ồ ạt Vì nhiều lý do, như kinh phí đầu tư hạn hẹp, cố gắng giảm giá thành sản phẩm, đội ngũ phát triển phần mềm chưa thực sự chuyên nghiệp … mà vấn đề về đảm bảo chất lượng phần mềm trước và sau khi phát hành không (hoặc ít) được trú trọng, đặc biệt là ở Việt Nam Từ đó phát sinh rất nhiều vấn đề trong khi sử dụng những phần mềm này

Trên thế giới, vấn đề về đảm bảo chất lượng phần mềm đã và đang được quan tâm đầu tư một cách thích đáng Vì lợi ích của nó đem lại là không thể chối cãi, như:

- Đảm bảo chất lượng phần mềm, đồng thời đảm bảo trải nghiệm ổn định, thoải mái cho người dùng cuối

- Đảm bảo và nâng cao các tính chất quan trọng cần phải có khi phát triển phần mềm, đặc biệt là tính bảo mật

- Giảm thiểu tối đa chi phí cho bảo trì sản phẩm phần mềm (thường chiếm tới 70% chi phí trong qui trình phát triển phần mềm [6])

- Nâng cao vị thế và uy tín của nhà phát triển phần mềm, tạo điều kiện cho sự phát triển vững mạnh của chính nhà phát triển phần mềm

Ở Việt Nam hiện nay, ngoại trừ các công ty lớn có đội ngũ Tester – Kiểm thử riêng, hầu hết các công ty nhỏ đều hoạt động theo hình thức: “người thiết kế/mã hóa/cài đặt phần mềm tự kiểm thử” Do đó chất lượng phần mềm không được đảm bảo, gây ra nhiều sai sót trong quá trình thực thi tác vụ của phần mềm, làm giảm chất lượng phần mềm, giảm chất lượng sử dụng của người dùng cuối, không đảm bảo được các tính chất thiết yếu của phần mềm ứng dụng, nhất là tính bảo mật, đặt biệt với các ứng

Trang 15

1.1.1 Kiểm thử

Kiểm thử là một khía cạnh phát triển trong sự phát triển của phần mềm Kiểm thử có thể cung cấp cho nhà phát triển một cái nhìn độc lập về phần mềm (chủ yếu từ góc nhìn sử dụng) để từ đó đánh giá và thấu hiểu được những rủi ro trong quá trình triển khai phần mềm Trong kỹ thuật kiểm thử không chỉ giới hạn ở việc đi tìm các lỗi phần mềm (bao gồm các lỗi và các thiếu sót) mà còn là một quá trình phê chuẩn và xác minh một chương trình máy tính/ứng dụng/sản phẩm nhằm:

- Đáp ứng được mọi yêu cầu của bài toán cần xử lý (Tính hoàn thiện)

- Thực hiện công việc đúng như kỳ vọng (Tính chính xác)

- Có thể triển khai được với những đặc tính tương tự (Tính khả thi)

- Và đáp ứng được mọi nhu cầu của các bên liên quan

Tùy thuộc vào từng phương pháp, việc kiểm thử có thể được thực hiện bất cứ lúc nào trong quá trình phát triển phần mềm Do đó, mỗi một phương pháp kiểm thử bị chi phối theo một quy trình phát triển phần mềm nhất định

Trước tiên, chúng ta cần xem xét một vài khái niệm căn bản trong kiểm thử Có khá nhiều các định nghĩa về kiểm thử được nêu ra Dưới đây là một vài khái niệm kiểm thử cơ bản nhất:

(1) "Kiểm thử là một hoạt động kỹ thuật mà bao gồm việc xác định một hoặc nhiều đặc tính của một sản phẩm, quá trình hoặc dịch vụ nhất định theo một thủ tục quy định." – (Định nghĩa bởi ISO [15])

Trang 16

quy định, với mục đích đo một hoặc nhiều đặc điểm / đặc tính chất lượng

của các sản phẩm phần mềm bằng cách chứng minh sự sai lệch về tình trạng thực tế của các sản phẩm từ các yêu cầu trạng thái / đặc điểm kỹ thuật." –

(Định nghĩa bởi Tretmans [19])

Trong các định nghĩa trên, định nghĩa (3) là đầy đủ và chính xác nhất Vì kiểm thử không chỉ là việc tìm kiếm lỗi và xác định những đặc tính thuộc về phần mềm mà

nó còn so sánh và hiển thị độ lệch của những đặc tính này với các yêu cầu trạng thái hay các đặc điểm kỹ thuật đã đặt ra Do đó, tác giả sẽ sử dụng Định nghĩa (3) cho khái

niệm kiểm thử được nói đến trong suốt tài liệu này

Trong khái niệm kiểm thử đã được nêu ra ở trên, có một khái niệm cần xem xét

rõ ràng hơn, đó là khái niệm chất lượng Khái niệm này được định nghĩa là:

(4) “Toàn bộ các đặc tính của một thực thể mang khả năng bảo đảm các trạng thái hệ thống cũng như các mục tiêu cần thiết đã được nêu ra trong quá trình xác định yêu cầu phần mềm” – (Định nghĩa theo tiêu chuẩn ISO 9126-

1)

Theo định nghĩa (4) chất lượng là một tập hợp các đặc điểm quan trọng cho sản

phẩm Chất lượng phần mềm có thể được phân thành sáu đặc điểm nêu trong tiêu chuẩn ISO 9126-1:

- Chức năng - phù hợp, bảo mật, chính xác

- Độ tin cậy - độ trưởng thành, khả năng chịu lỗi, khả năng thu hồi

- Khả năng sử dụng - khả năng hoạt động, dễ hiểu, khả năng học hỏi, hấp dẫn

- Hiệu quả - hành vi thời gian, sử dụng nguồn lực

- Bảo trì - khả năng nghiên cứu, thay đổi, sự ổn định, khả năng kiểm thử

- Khả năng triển khai - khả năng thích ứng, khả năng cài đặt, khả năng thay thế

Trang 17

17

Kiểm thử phần mềm có thể triển khai bằng các cách sau:

(i) Kiểm thử thủ công: Linh động nhưng tốn kém Đây không phải là cách

được ưa thích để kiểm thử phần mềm

(ii) Kiểm thử tự động: Tức là tạo ra các kịch bản kiểm thử và thực hiện

chúng một cách tự động Chi phí cho kiểm thử tự động chỉ tốn kém 1 lần

ở bước xây dựng kịch bản kiểm thử và được sử dụng lại nhiều lần khi cần thiết Tuy nhiên, việc này vẫn đòi hỏi có đủ thời gian thích hợp Thêm nữa nhược điểm của cách này là khi các mã lệnh của chương trình bị thay đổi thì các kịch bản kiểm thử không còn tác dụng nữa

(iii) Kiểm thử hướng mô hình: Để khắc phục nhược điểm của 2 cách trên,

chúng ta có một cách khác là Kiểm thử hướng mô hình (sẽ được nói chi tiết hơn trong phần dưới đây)

1.1.2 Kiểm thử hướng mô hình

Có nhiều khái niệm khác nhau về kiểm thử hướng mô hình Nhưng nhìn chung

có thể hiểu kiểm thử hướng mô hình là một phương pháp kiểm thử mà các ca kiểm thử được sinh ra từ mô hình đặc tả hành vi của hệ thống đang được kiểm thử (System Under Test - SUT)[1] Mô hình này được biểu diễn bằng máy hữu hạn trạng thái, đặc tả đại số, biểu đồ trạng thái bằng UML,

Kiểm thử hướng mô hình là một công nghệ tương đối mới để kiểm thử phần mềm Một mô hình mô tả các hành vi mong muốn của SUT Nó là điểm quan trọng trong kiểm thử hướng mô hình Các hành vi mong muốn thường được quy định trong tài liệu kỹ thuật của SUT Kiểm thử hướng mô hình vượt qua ranh giới của kiểm tra tự động bởi vì nó tạo ra thuật toán định lượng cụ thể các trường hợp kiểm thử dựa trên mô

hình của hành vi mong muốn Một công cụ kiểm thử hướng mô hình (Chương 1 phần

1.3) tạo ra các trường hợp kiểm thử cụ thể dựa trên mô hình

Trang 18

18

Các SUT được kiểm thử thông qua cách tiếp cận hộp đen, nghĩa là chúng ta chỉ quan sát đầu ra của hệ thống với một đầu vào nhất định, mà không biết mã lệnh đằng sau nó Các đầu ra quan sát được từ SUT được so sánh với trạng thái đầu ra mong muốn của hệ thống đưa ra bởi các mô hình Ngược lại với kiểm thử hộp đen là kiểm thử hộp trắng, tức là các cấu trúc bên trong của hệ thống, các mã, là nền tảng của kiểm thử [18]

Để có thể tạo ra các trường hợp kiểm thử cho các SUT, một bộ chuyển đổi (Adapter) thường được tạo ra Adapter sẽ tạo ra đầu vào từ các công cụ kiểm thử hướng mô hình sao cho có thể sử dụng được cho các SUT, đồng thời, đầu ra quan sát được hình thành từ SUT cũng được chuyển đổi để có thể đọc được bởi các công cụ này

1.1.3 So sánh và đánh giá

Trong 2 phần trên chúng ta đã hiểu tổng quan về kiểm thử thường và kiểm thử hướng mô hình Trong phần này chúng ta cần so sánh để làm rõ đặc tính của từng loại kiểm thử, từ đó phân biệt được đâu là kiểm thử thường và đâu là kiểm thử hướng mô hình

Đầu tiên ta cần ngầm hiểu kiểm thử thường tức là tạo kiểm thử thủ công hoặc tạo kiểm thử tự động hướng mã nguồn (Code-based test generation) Còn kiểm thử hướng mô hình cũng là kiểm thử, nhưng khác nhau ở chỗ kiểm thử hướng mô hình sẽ không tập trung ngay vào việc sinh test case, hay các ca kiểm thử Công việc đầu tiên khi áp dụng kiểm thử hướng mô hình là xây dựng mô hình kiểm thử trực quan từ các yêu cầu hệ thống bằng cách sử dụng các ngôn ngữ mô hình hóa đã nói ở 1.1.2 Các mô hình này thường là trực quan và dễ hiểu cho việc mô tả các luồng xử lý và các bước chuyển trạng thái của hệ thống Từ các mô hình này cũng có thể phát hiện ngay được các lỗi cơ bản có thể nảy sinh trên hệ thống để kịp thời sửa chữa trước khi bắt tay vào

Trang 19

Tuy nhiên, dù là kiểm thử thường hay kiểm thử hướng mô hình cũng không thể xác định hoàn toàn được tất cả các lỗi bên trong phần mềm Thay vào đó, nó so sánh trạng thái và hành vi của sản phẩm với các nguyên tắc hay cơ chế để phát hiện vấn đề Mục đích chính của kiểm thử là phát hiện ra các lỗi phần mềm để từ đó khắc phục và sửa chữa Việc kiểm thử không thể khẳng định được rằng các chức năng của sản phẩm đúng trong mọi điều kiện, mà chỉ có thể khẳng định rằng nó không hoạt động đúng trong những điều kiện cụ thể Các thông tin thu được từ kiểm thử có thể được sử dụng

để điều chỉnh quá trình phát triển phần mềm

1.2 Phương pháp đặc tả mô hình [1][5]

Để áp dụng phương pháp kiểm thử hướng mô hình, chúng ta cần xây dựng mô hình đặc tả chính xác hành vi của hệ thống cần kiểm thử Mô hình này được đặc tả bằng một trong các phương pháp hình thức như: Hệ thống chuyển đổi trạng thái (Labelled Transition System – LTS), Máy trạng thái hữu hạn (Finite State Machine – FSM), Máy trạng thái mở rộng (Extended State Machine – ESM),.v.v

Trang 20

20

1.2.1 Ngôn ngữ mô hình hóa

Kiểm thử hướng mô hình cho ứng dụng (web) đòi hỏi phải sử dụng các mô hình Một mô hình đại diện cho hành vi đúng của hệ thống Các đặc điểm kỹ thuật của

hệ thống (tài liệu hướng dẫn về những gì hệ thống có khả năng làm được) chỉ rõ những

gì hệ thống có thể xử lý khi sử dụng một số yếu tố và những phản ứng của hệ thống

nên có khi sử dụng những yếu tố này Ví dụ, các đặc điểm kỹ thuật cho chúng ta biết

những gì sẽ xảy ra nếu người dùng nhấn vào một liên kết trong trình duyệt Hệ thống phải đáp ứng với các tập tin yêu cầu hoặc cần cung cấp một lỗi Tất cả các đặc điểm

kỹ thuật cho chúng ta biết những thứ cần thiết để kích hoạt các sự kiện và các đầu ra mong đợi của sự kiện đó Với những đầu vào và đầu ra này, chúng ta có thể làm ra một

mô hình của các đặc điểm kỹ thuật Với một mô hình, chúng ta có thể tạo ra thuật toán kiểm tra theo nhiều trường hợp nhằm xác định xem SUT có phản ứng phù hợp với mong đợi hay không

Một mô hình có thể được mô tả theo nhiều cách khác nhau Mỗi công cụ kiểm thử hướng mô hình sử dụng một mô hình khác nhau để tạo ra các trường hợp kiểm thử Phần dưới đây sẽ đưa ra một số ngôn ngữ mô hình hóa phổ biến nhất được sử dụng trong kiểm thử hướng mô hình

1.2.2 Hệ thống chuyển đổi nhãn (Labelled Transition System - LTS)

LTS bao gồm một tập các trạng thái (State) và một bộ chuyển tiếp giữa các trạng thái đó Trạng thái ban đầu được gọi là s0 Mỗi bước chuyển được dán nhãn (Label) của một hành động State đại diện cho các trạng thái của hệ thống và label đại diện cho các hành động nhìn thấy được của hệ thống Label được lấy từ một tập L toàn cục Về hình thức, một LTS được biểu diễn bởi bộ 4 ký tự như sau:

(S, s0, 𝐿, →) Trong đó:

Trang 21

21

- S là tập hợp các trạng thái không trống (non-empty state)

- L là tập hợp các nhãn đầu vào (Input label) Ngoài ra có một label đặc biệt tượng trưng cho một hành động nội bộ được gọi là 𝜏 ( 𝜏 ∉ L )

- → là các mối quan hệ chuyển tiếp, sử dụng khi có một sự chuyển trạng thái từ Sx sang Sy Nó Là tập con của các tập các trạng thái, các nhãn và các trạng thái đầu ra

→ ⊆ S × (𝐿 ∪ {𝜏}) × S, với 𝜏 ∉ 𝐿

1.2.3 Máy trạng thái hữu hạn (Finite State Machine – FSM)

FSM có một tập hợp hữu hạn các trạng thái Một FSM được biểu diễn bởi bộ 6

ký tự như sau:

(S, 𝐼, O, s0, 𝛿, 𝜆)Trong đó:

- S là một tập hữu hạn các trạng thái không trống (Finite non-empty state)

- s0 ∈ S là trạng thái ban đầu

- I là một tập hữu hạn các đầu vào không trống (Finite non-empty input)

- O là một tập hữu hạn các đầu ra không trống (Finite non-empty output)

và bao gồm thêm 1 đầu ra NULL được gọi là ∅

- 𝛿 là hàm chuyển đổi trạng thái, 𝛿: S × I → S

- 𝜆 là hàm đầu ra (Output function), 𝜆: S × I → O

Sự khác biệt chính giữa một LTS và một FSM là một FSM có nhãn đầu vào và đầu ra xác định trong khi một LTS có thể có đầu vào và đầu ra xảy ra theo một thứ tự ngẫu nhiên Hơn nữa, một LTS được phép có tập vô hạn của các trạng thái và một tập

Trang 22

22

vô hạn của nhãn, trong khi một FSM phải có một tập hợp hữu hạn các trạng thái và một

tập hữu hạn các nhãn đầu vào Một FSM đáp ứng trên một đầu vào I cho trước được

đưa ra trong một trạng thái S Điều này tạo ra một sự chuyển đổi trạng thái 𝛿(S,I) và một đầu ra 𝜆(S, I)

1.2.4 Máy trạng thái mở rộng (Extended State Machine – ESM)

ESM có điểm tương đồng với FSM nhưng được mở rộng với các biến Trong quá trình chuyển đổi từ trạng thái hiện hành sang trạng thái khác, các giá trị mới có thể được gán cho các biến này Sử dụng các biến này, chúng ta có thể trừu tượng hóa mô hình bằng cách giảm thiểu việc sử dụng các trạng thái Với việc sử dụng biến, chúng ta

có thể xây dựng các vị từ để đảm bảo cho quá trình chuyển đổi nhất định, tức là có thể cho phép (hoặc không cho phép) chuyển trạng thái khi giá trị của biến đạt một điều kiện nhất định Một ESM được biểu diễn như sau:

(S, S0, 𝐼, O, D, 𝛿r)Trong đó:

- S là một tập hữu hạn các trạng thái

- S0 ∈ S là trạng thái ban đầu

- I là một tập hữu hạn các đầu vào

- O là một tập hữu hạn các đầu ra (Cho đến đây, nó vẫn có định dạng của

một FSM)

- D là tập hợp các biến (Khác biệt chính của ESM với FSM)

- 𝛿r là quan hệ chuyển trạng thái

Ví dụ: (s, i, p, a, o, t) có thể được hiểu là “trong một trạng thái s với đầu vào i chịu sự tác động của điều kiện p, khi các biến đạt được điều kiện quy định trong p thì

có thể chuyển trạng thái từ s sang t thông qua hành động a, và cho đầu ra là o”

Trang 23

23

Như vậy, ta đã đi qua 3 ngôn ngữ mô hình hóa là: LTS, FSM và ESM Mỗi loại

có một ưu nhược điểm riêng Do sự phổ biến và linh động của FSM mà tác giả đã lựa chọn FSM làm phương pháp đặc tả mô hình cho phần kiểm thử hướng mô hình này Tương ứng với nó là công cụ Spec Explorer sẽ được nói đến trong phần 1.3

1.3 Công cụ kiểm thử hướng mô hình

1.3.1 Tổng quan

Về mặt bản chất, kiểm thử hướng mô hình là một dạng của kiểm thử tự động, cho phép ta có thể tự động hóa quá trình kiểm thử từ việc sinh ra ca kiểm thử cho đến việc tự động chạy ứng dụng và đưa ra kết quả kiểm thử khi chạy ứng dụng Tuy nhiên,

do đặc thù của từng loại ứng dụng mà muốn kiểm thử ứng dụng một cách tự động đòi hỏi phải xây dựng một bộ chuyển đổi (Adapter) để giúp cho việc giao tiếp giữa công cụ kiểm thử với ứng dụng thật

Hiện nay đã có rất nhiều các công cụ hỗ trợ kiểm thử tự động, nhưng các công

cụ này thường chỉ có thể sử dụng được khi đã có các bản mẫu ứng dụng (Prototype) Một hạn chế nữa của các công cụ kiểm thử tự động là chưa thực sự phát triển cho các ứng dụng web mà phần nhiều trong số đó đều chỉ tập trung cho việc kiểm thử các ứng dụng chạy trên desktop Ngoài ra cũng đã có những công cụ được phát triển để hỗ trợ cho kiểm thử hướng mô hình, nhưng hầu hết vẫn chưa đáp ứng được những yêu cầu của việc kiểm thử hướng mô hình Do đó, việc tìm kiếm một công cụ phù hợp cho việc kiểm thử tự động ứng dụng web nói chung, cũng như kiểm thử hướng mô hình cho phát triển ứng dụng web nói riêng là rất nan giải và khó khăn Hiện nay chưa thể tìm thấy một công cụ kiểm thử hướng mô hình nào đặc trưng cho việc phát triển ứng dụng web

Trong tình hình đó, tác giả đã tìm kiếm và xác định được 2 công cụ có thể sử dụng để hỗ trợ cho phần lý thuyết về kiểm thử hướng mô hình cho ứng dụng web đã

Trang 24

24

nói đến ở trên Đó là: Spec Explorer (công cụ kiểm thử hướng mô hình do Microsoft phát triển và có thể tích hợp vào Visual Studio như một thành phần chức năng) và Selenium (Công cụ kiểm thử tự động đặc trưng cho kiểm thử ứng dụng web hiện tại đang rất phổ biến và được sử dụng rộng rãi)

Mỗi công cụ sẽ được sử dụng với mục đích riêng tùy theo chức năng và ưu nhược điểm của chúng (sẽ được nói rõ hơn trong các phần giới thiệu công cụ dưới đây: 1.3.2 và 1.3.3) Trong đó:

- Spec Explorer sẽ được sử dụng để thiết kế mô hình kiểm thử là chính Ngoài ra có thể sử dụng nó để sinh các ca kiểm thử tự động để làm tài liệu tham khảo cho kiểm thử tự động về sau, do code kiểm thử được sinh không thích hợp để sử dụng ngay cho ứng dụng web, cũng như hạn chế trong việc xây dựng các bộ chuyển đổi (Adapter) đã nói đến ở trên) Dựa trên các mô hình này, chúng ta có thể sinh ngay các mô hình cho từng ca kiểm thử, từ đó đánh giá ngay được chất lượng của phần mềm và phát hiện sớm các thiếu sót dễ thấy của hệ thống

- Selenium sẽ được sử dụng để hiện thực hóa các ca kiểm thử dựa trên mô hình đã có ở trên Đồng thời có thể sử dụng để đánh giá ngược chất lượng của các mô hình này

Các phần dưới đây sẽ giới thiệu lần lượt về các công cụ Spec Explorer và Selenium, đồng thời chỉ ra ưu nhược điểm của chúng khi áp dụng vào kiểm thử hướng

mô hình trong phát triển ứng dụng web

1.3.2 Spec Explorer

Spec Explorer do Microsoft phát triển và được phát hành hoàn toàn miễn phí, có thể tích hợp trực tiếp vào Visual Studio như một thành phần chức năng Bộ công cụ này được xây dựng dựa trên ngôn ngữ lập trình C# và Cord Scripting Language giúp ta

có thể xây dựng mô hình, liên kết với phần thực thi (SUT) và sinh ra các ca kiểm thử

Trang 25

25

Ưu điểm của công cụ này là nó được phát triển trực tiếp cho kiểm thử hướng mô hình nên hỗ trợ khá tốt các bước trong qui trình kiểm thử hướng mô hình Từ việc mô hình hóa các yêu cầu kiểm thử, sinh ra mô hình kiểm thử, sinh các ca kiểm thử cũng như tạo Test Suite Nó được phát triển bởi chính Microsoft nên có thể tích hợp trực tiếp vào Visual Studio như một thành phần chức năng Do đó nó hỗ trợ rất tốt trong môi trường NET

Tuy nhiên, nhược điểm của công cụ này là code để mô hình hóa còn phức tạp, nhiều cấu trúc lệnh và toán tử còn chưa thật sự rõ ràng khiến người lập trình mới rất bỡ ngỡ khi tiếp xúc với nó Thêm nữa, việc sinh các Test Script cũng chưa thật sự hữu dụng, khi mà để giao tiếp với ứng dụng thật cần tạo ra một bộ Adapter tương ứng cho từng công nghệ, từng ngôn ngữ và từng môi trường khác nhau Việc này sẽ tiêu tốn rất nhiều tài nguyên và không thể đảm bảo chi phí cho việc phát triển phần mềm ứng dụng Chính vì thế quá trình tạo bộ chuyển đổi thường bị lược bỏ đi, tương đương với việc không thể sử dụng trực tiếp các Test Script để kiểm thử ứng dụng Thêm một hạn chế nữa của công cụ này là hiện tại nó chỉ hỗ trợ cho các phiên bản cũ của Visual Studio là bản 2010 và 2012 chứ chưa hỗ trợ cho phiên bản từ 2013 trở đi Do đó người

sử dụng sẽ phải cài đặt phiên bản Visual Studio tương ứng để có thể sử dụng được công cụ này, tương đương với việc sẽ phải chấp nhận mất đi rất nhiều hỗ trợ mới hữu ích từ các bản Visual Studio mới hơn

Do các hạn chế của công cụ này, cộng thêm đặc thù của ứng dụng web cũng như công nghệ sử dụng để xây dựng ứng dụng web, đặc thù về cấu trúc ứng dụng cũng như cách triển khai, sử dụng ứng dụng … hoàn toàn khác so với một phần mềm chạy trên

PC thông thường, nên việc tích hợp code còn nhiều vấn đề nan giải Ngoài ra, việc xây dựng được các bộ chuyển đổi này cũng phát sinh rất nhiều chi phí và hao tổn nhiều tài nguyên Vì vậy, trong giới hạn của luận văn này, tác giả sử dụng Spec Explorer chủ yếu cho việc mô hình hóa quy trình kiểm thử và sinh các mô hình kiểm thử cho các ca kiểm thử tự động về sau

Trang 26

26

Hình 1 thể hiện sơ đồ các bước thực hiện khi ta áp dụng kiểm thử hướng mô hình với Spec Explorer

Hình 1: Quy trình áp dụng Spec Explorer [5]

Bước xây dựng mô hình là bước khởi đầu và cũng là bước quan trọng nhất của kiểm thử hướng mô hình, thể hiện tính chất đặc trưng của phương pháp kiểm thử này

Mô hình là yếu tố quan trọng then chốt để từ đó ta có thể thực hiện các bước khác Việc xây dựng mô hình cho ta kết quả là một chương trình mô hình (Model program),

Đặc tả yêu cầu (1) Xây dựng Mô hình (C#)

mô hình(Thủ công)

(2) Thiết lập cấu hình kiểm thử(Thủ công)

(3) Generate

ca kiểm thửs(Tự động)

Cấu hình kiểm thử (Cord Scripting Language)

Ca kiểm thử

(4) Kiểm thử(Thủ công hoặc

tự động)

Sinh code kiểm thử (Tự động)

Xây dựng ứng dụng (implement)(Thủ công)

SUT

Trang 27

27

dựa trên một ngôn ngữ đặc tả mô hình (Model language) Việc xây dựng mô hình tập trung vào việc mô tả hệ thống một cách đơn giản, nhỏ gọn nhằm phục vụ cho việc phân tích và kiểm thử hệ thống

1.3.3 Selenium

Selenium là một phần mềm mã nguồn mở được phát triển bởi Jason Huggins, sau đó được tiếp tục bởi nhóm ThoughtWorks vào năm 2004 Đây là một công cụ kiểm thử tự động đặc trưng cho các ứng dụng web Phiên bản hoàn chỉnh mới nhất hiện tại

đã hỗ trợ được hầu hết các Trình duyệt web hiện nay như Chrome, IE, Safari, … và đặc biệt là FireFox Selenium cũng đã hỗ trợ hầu hết các Hệ điều hành phổ biến hiện nay như Windows, Linux, Mac… cũng như hỗ trợ các ngôn ngữ lập trình web phổ biến, ví dụ: C#, Java, Perl, PHP, Python, Ruby … Selenium đang được cộng đồng sử dụng đánh giá là công cụ kiểm thử tự động cho web tốt nhất hiện nay Đó cũng là lý do tác giả lựa chọn công cụ này để hỗ trợ cho phần thực nghiệm của đề tài này

Ưu điểm lớn nhất và thích hợp nhất của Selenium trong trường hợp cụ thể của luận văn này là nó chuyên hỗ trợ cho kiểm thử tự động ứng dụng web Ngoài ra như đã nói ở trên, Selenium hỗ trợ tốt cho hầu hết các môi trường, các hệ điều hành, các trình duyệt web và các ngôn ngữ lập trình web hiện nay Nó cũng có ưu điểm là trực quan,

dễ học, dễ sử dụng, dễ tiếp cận cho người mới; thêm nữa sau khi tạo được các ca kiểm thử, nó còn hỗ trợ sinh code tự động để cắm trực tiếp vào các loại ứng dụng cụ thể và chạy như code nội tại của ứng dụng Vì vậy nó được sử dụng ngày càng nhiều trong chuyên ngành kiểm thử phần mềm

Nhược điểm của phần mềm này (so với trường hợp cụ thể của luận văn này) chỉ

là nó không phải là một công cụ kiểm thử hướng mô hình Như đã trình bày ở trên, các công cụ kiểm thử tự động chỉ có thể áp dụng khi đã có các bản mẫu (Prototype) của ứng dụng Nó cũng không tự sinh mô hình kiểm thử cho người dùng Nếu người dùng

Trang 28

28

muốn sinh tự động mô hình kiểm thử thì phải sử dụng thêm một phần mềm thứ 3 hỗ trợ cho việc mô hình hóa quy trình kiểm thử từ test code của Selenium

Cũng do những nhược điểm này mà trong khuôn khổ của luận văn này, tác giả

sử dụng Selenium như một công cụ để hiện thực hóa các ca kiểm thử sinh ra từ Spec Explorer thay cho việc tạo các bộ Adapter vốn sẽ chiếm rất nhiều chi phí và tài nguyên khi phát triển Ngoài ra, Selenium cũng được sử dụng để đánh giá ngược chất lượng của các mô hình đã được sinh tự động từ Spec Explorer ở bước trên

1.4 Đề xuất quy trình kiểm thử hướng mô hình áp dụng kết hợp công cụ Spec Explorer và Selenium

Theo truyền thống, việc kiểm thử (nếu có) sẽ được thực hiện bởi một nhóm các Tester độc lập sau khi các chức năng được phát triển và trước khi nó được chuyển tới khách hàng Thực tế này gây ra tốn kém rất nhiều tài nguyên do các lỗi hệ thống không được ngăn chặn sớm mà chỉ được phát hiện khi gần như đã hoàn thành hệ thống Khi

đó việc tìm kiếm và sửa lỗi sẽ rất khó khăn do không có các hiện vật kết quả của từng giai đoạn phát triển mà phải lục tìm trong một mớ hỗn độn các mã nguồn

Kiểm thử hướng mô hình có thể khắc phục triệt để các hạn chế đó, do nó có thể tích hợp vào quá trình phát triển ứng dụng ngay từ những ngày đầu tiên, khi mới có yêu cầu cụ thể của bài toán Thêm nữa, nếu các quá trình phía trước còn bỏ sót lỗi thì khi phát hiện lỗi ở các quá trình tiếp theo sẽ rất dễ dàng để tìm kiếm và sửa ngay lỗi xảy ra (do có lưu lại toàn bộ các hiện vật trong quá trình phát triển) Đồng thời còn có thể phán đoán ngay các lỗi tiếp theo có thể xảy ra khi hệ thống có thay đổi Từ đó ngăn chặn được các lỗi ngay từ đầu và giảm thiểu tối đa hao phí tài nguyên cho việc phát triển cũng như bảo trì web

Tuy nhiên, Kiểm thử hướng mô hình không phải là một công cụ vạn năng cho quá trình kiểm thử Nó chỉ có thể áp dụng được khi đã có bản đặc tả chi tiết về hệ thống cần xây dựng Qua đó mới có thể xác định được các trạng thái và hành vi hệ

Trang 29

29

thống một cách đúng đắn để xây dựng được mô hình trực quan Do mấu chốt của kiểm thử hướng mô hình là việc xây dựng được các mô hình một cách đúng đắn và đầy đủ nhất có thể, nên kiểm thử hướng mô hình không thể thực hiện khi chưa xác định được các trạng thái và hành vi của hệ thống (hay cũng chính là khi chưa có đặc tả chi tiết, cụ thể về hệ thống)

Quá trình kiểm thử hướng mô hình được bắt đầu bằng việc xác định yêu cầu của

hệ thống từ đó xây dựng mô hình dựa vào các yêu cầu và chức năng của hệ thống Việc xây dựng mô hình cần phải dựa trên các yếu tố dữ liệu đầu vào và đầu ra Mô hình này được sử dụng để sinh đầu vào cho các ca kiểm thử Tiếp đến, chúng ta sẽ sinh giá trị đầu ra mong muốn ứng với mỗi bộ đầu vào Khi kết thúc bước này, chúng ta được các

ca kiểm thử Các kịch bản kiểm thử sẽ được thiết kế và thực thi nhằm phát hiện các lỗi/khiếm khuyết của sản phẩm bằng cách so sánh đầu ra thực tế với đầu ra mong đợi tương ứng của ca kiểm thử Từ các kết quả kiểm thử, chúng ta sẽ quyết định hành động tiếp theo như sửa đổi mô hình hoặc dừng kiểm thử

Trang 30

30

Hình 2: Quy trình kiểm thử hướng mô hình

Hình 2 mô tả các bước của quy trình kiểm thử hướng mô hình, trong đó:

Bước 1: Mô hình hóa mô hình kiểm thử bằng Spec Explorer

Bao gồm (1.1) Sinh mô hình và (1.2) Sinh các ca kiểm thử trong Hình 2

Ở bước này, từ bản đặc tả yêu cầu phần mềm, ta có thể xác định được

các tác vụ/chức năng cần có của hệ thống Qua đó xác định được các trạng thái/hành động/sự kiện phát sinh làm thay đổi trạng thái hệ thống Đó chính là

căn cứ để sinh mô hình kiểm thử (1.1 trong Hình 2) Ngoài ra bản đặc tả yêu cầu phần mềm cũng đóng vai trò làm đầu vào cho việc sinh các đầu ra mong muốn

của từng tác vụ/chức năng hệ thống Qua đó ta có thể đem so sánh ngay mô hình

có được ở 1.1 với các đầu ra mong muốn này để đánh giá mô hình ngay từ

Trang 31

31

những bước đầu tiên, nhằm phát hiện các lỗi ngay từ sớm để có biện pháp chỉnh sửa cho đúng, cũng như cắt giảm ngay các chi phí phát sinh về sau nếu gặp phải các lỗi này

Trong các tác vụ tiếp theo, Spec Explorer sẽ tự động sinh các ca kiểm thử

và các kịch bản kiểm thử (1.2 trong Hình 2)

Bước 2 Thực hiện các kịch bản kiểm thử bằng Selenium

Bao gồm (2) Thực hiện các kịch bản kiểm thử trong Hình 2

Ở bước này, để tránh việc hao tổn lớn đến tài nguyên phát triển phần mềm (bao gồm cả về kinh tế và nhân lực) cho việc tạo các Adapter chuyển đổi

Test Script tự sinh của Spec Explorer trong bước 1, ta sử dụng Selenium để thực

thi ra các ca kiểm thử/các kịch bản kiểm thử (2 trong Hình 2) một cách trực

quan, dễ dàng cũng như giảm các hao phí tài nguyên đến mức tối đa

Qua bước này ta có được báo cáo kiểm thử bằng việc ghi nhận đầu ra của

hệ thống với từng ca kiểm thử Báo cáo kiểm thử này được đem so sánh với cả

mô hình ở 1.1 và cả đầu ra mong muốn đã có ở trên Từ đó đánh giá kết quả thu

được khi thực hiện thực tế các ca kiểm thử/các kịch bản kiểm thử có được ở 1.2

Bước 3: Đánh giá chéo giữa mô hình và thực tế

Bao gồm (3) Đánh giá chéo trong Hình 2

Ở bước này, việc kiểm tra/đánh giá chéo giữa mô hình kiểm thử với thực

tế là rất cần thiết Qua đó có thể phát hiện các lỗi xảy ra trong hệ thống cũng như những tác vụ còn thiếu sót để có biện pháp xử lý kịp thời Sau khi quyết định các giải pháp giải quyết vấn đề cần cập nhật lại mô hình, sau đó đánh giá ngay lại các tác vụ liên quan trên mô hình xem có phát hiện thêm lỗi mới nào không Nếu không thì thực hiện lại bắt đầu từ bước 1.2 trong Hình 2

Bước 4: Tham khảo ý kiến của chuyên gia và người dùng cuối

Bao gồm (4) Tham khảo ý kiến chuyên gia/người dùng cuối trong Hình 2

Trang 32

32

Việc tham khảo kinh nghiệm kiểm thử của các chuyên gia là rất cần thiết Nhìn vào mô hình và các yêu cầu hệ thống, họ có thể phát hiện ngay các lỗi có thể xảy ra từ rất sớm, tránh được rất nhiều các hao phí tài nguyên cho việc phát triển phần mềm về sau

Ngoài ra, người dùng cuối cũng đóng vai trò rất quan trọng trong việc phản hồi ý kiến về các lỗi xảy ra trong quá trình chạy của hệ thống Đây cũng là đối tượng và là mục tiêu cuối cùng mà việc phát triển hệ thống cần hướng đến

để làm thỏa mãn nhu cầu của họ bằng việc nâng cao chất lượng phần mềm Các bước kiểm thử nói trên diễn ra trong quy trình phát triển ứng dụng (Web)

và có thể được thực hiện bởi các nhà phát triển bằng cách kiểm tra các mô hình ở các mức trừu tượng khác nhau, và nên được thực hiện lặp đi lặp lại cho đến khi các mô hình này đạt được các yêu cầu kiểm thử Điều này cho phép tích hợp các ca kiểm thử ngay từ giai đoạn đầu của quá trình phát triển Tuy nhiên, việc đánh giá khi sử dụng của ứng dụng web vẫn cần có sự tham gia của người dùng cuối Có thể coi quá trình sử dụng của người dùng cuối như bước kiểm thử cuối cùng cho việc phát triển ứng dụng Thông qua việc thu thập những phản hồi của người dùng cuối cũng có thể tạo ra một báo cáo đánh giá để cung cấp thông tin phản hồi ở giai đoạn nào đó của quá trình phát triển

1.5 Kết luận chương

Chương 1 đã trình bày được những vấn đề sau:

1 Tổng quan về kiểm thử và kiểm thử hướng mô hình: Phần này đưa ra những khái niệm về kiểm thử và kiểm thử hướng mô hình, khái niệm chất lượng sản phẩm phần mềm, khái niệm ngôn ngữ mô hình hóa và các ngôn ngữ mô hình hóa phổ biến nhất đang được sử dụng trong kiểm thử hướng mô hình

Trang 33

33

2 So sánh và phân biệt được giữa kiểm thử thường với kiểm thử hướng mô hình

Từ đó đưa ra được ưu điểm của kiểm thử hướng mô hình so với kiểm thử thường

3 Đưa ra các phương pháp đặc tả mô hình trong kiểm thử hướng mô hình (LTS, FSM, ESM)

4 Tổng quan về các công cụ kiểm thử tự động và kiểm thử hướng mô hình: Trong phần này có phân tích hiện trạng các công cụ có thể sử dụng trong kiểm thử hướng mô hình Từ việc phân tích ưu nhược điểm của các công cụ này, tác giả đã lựa chọn đi sâu và sử dụng kết hợp 2 công cụ: Spec Explorer & Selenium để đề xuất và áp dụng quy trình kiểm thử hướng mô hình trong phát triển ứng dụng web theo hướng mô hình Trong đó công cụ Spec Explorer tương ứng với phương pháp đặc tả mô hình bằng FSM đã nói đến trong phần 1.2 Phương pháp đặc tả mô hình

5 Đề xuất một quy trình áp dụng kiểm thử hướng mô hình kết hợp 2 công cụ đã nói ở trên Quy trình này sẽ được áp dụng vào thực nghiệm ở Chương 3 phần 3.3

Như vậy, Chương 1 giải quyết vấn đề về kiểm thử hướng mô hình (1 trong 2 vấn đề chính của luận văn này) nhằm cải tiến quy trình kiểm thử áp dụng cho việc phát triển ứng dụng (web) phát triển theo hướng mô hình

Trang 34

34

CHƯƠNG 2 ĐÁNH GIÁ TÍNH TIỆN DỤNG CỦA ỨNG DỤNG

WEB 2.1 Giới thiệu

Tính tiện dụng là một trong những yếu tố có liên quan đến chất lượng của các ứng dụng Web [20][17] Xác định phương pháp để đảm bảo tính tiện dụng từ đó trở thành một trong những mục tiêu của nghiên cứu Kỹ thuật xây dựng Web Các công ty cũng đang nghiên cứu và đầu tư vào đó do nhận thức được tầm quan trọng của việc áp dụng các phương pháp đánh giá tính tiện dụng trong quá trình phát triển, thẩm tra tính tiện dụng các ứng dụng Web trước và sau khi triển khai thực tế Một số nghiên cứu[17][4][3] đã chứng minh việc sử dụng các phương pháp này cho phép tiết kiệm rất nhiều chi phí (nhất là chi phí bảo trì cho ứng dụng), vì chúng làm giảm sự cần thiết phải thay đổi sau khi phân phối ứng dụng

Chương này chỉ ra sự cần thiết của việc nghiên cứu và áp dụng các phương pháp đánh giá tính tiện dụng trong quy trình phát triển ứng dụng (web) theo hướng mô hình, các tiêu chuẩn quốc tế về đánh giá tính tiện dụng, xây dựng phương pháp đánh giá tính tiện dụng, đề xuất một mô hình đánh giá tính tiện dụng của ứng dụng web, đưa ra quy trình áp dụng đánh giá tính tiện dụng web trong phát triển ứng dụng web theo hướng

mô hình Đây sẽ là cơ sở lý thuyết cho phần thực nghiệm về đánh giá tính tiện dụng của web (Chương 3 phần 3.4) về sau

2.2 Tiêu chuẩn quốc tế về đánh giá tính tiện dụng

Tính tiện dụng được hiểu như là một yếu tố quyết định đến chất lượng của hệ thống, nó là câu trả lời tổng quát nhất cho tất cả các trải nghiệm của người dùng với công nghệ Nó mô tả chất lượng của sản phẩm và hệ thống từ góc nhìn của người sử dụng chúng

Trang 35

35

ISO/IEC 9241 (1998)[10]định nghĩa tính tiện dụng: Phần mềm có thể sử dụng

khi nó cho phép người dùng thực hiện tác vụ một cách hiệu quả và hài lòng trong từng ngữ cảnh sử dụng cụ thể

Tổ chức tiêu chuẩn hóa quốc tế (ISO) đã phát triển các mô hình để phân loại và

đo lường tính tiện dụng của phần mềm Trong phần này sẽ trình bày về các tiêu chuẩn liên quan tới việc đánh giá tính tiện dụng và các phương pháp tiếp cận để đánh giá tính tiện dụng

ISO/IEC 9241 [10][11][9] là một bộ các tiêu chuẩn quốc tế liên quan đến các yêu cầu công thái học cho công việc văn phòng được tiến hành dựa trên các thiết bị đầu cuối để hiển thị hình ảnh Tiêu chuẩn này được chia làm 17 phần nhỏ Phần 1 và 2 trình bày tổng quan của loạt tiêu chuẩn và yêu cầu hướng dẫn Phần 3 đến phần 9 giải quyết các yêu cầu và hướng dẫn thiết kế phần cứng, trong đó có thể có những tác động tới phần mềm Cuối cùng, phần 10 tới phần 17 giải quyết các đặc tính phần mềm

Tiêu chuẩn ISO/IEC 9241 [10][11] trình bày các hướng dẫn về tính tiện dụng và được sử dụng để đánh giá tính tiện dụng theo ngữ cảnh sử dụng phần mềm Ngoài ra ISO/IEC 9241-11 còn bổ sung 1 phương pháp tiếp cận tính tiện dụng hướng tiến trình cho phép hệ thống tương tác có thể sử dụng thông qua tiến trình thiết kế lấy con người làm trung tâm

Các tiêu chuẩn ISO/IEC 9126 [8] là một tập hợp các tiêu chuẩn quốc tế về chất lượng phần mềm từ quan điểm sản phẩm Tiêu chuẩn quốc tế này phân chia chất lượng phần mềm thành sáu loại đặc tính: chức năng, độ tin cậy, tính tiện dụng, hiệu quả, bảo trì và tính di động Mục tiêu của ISO/IEC 9126 [8] là cung cấp một khuôn khổ cho việc đánh giá chất lượng phần mềm Phiên bản mới nhất (ISO/IEC 9126 2001) bao gồm quan điểm của người sử dụng và giới thiệu các khái niệm về chất lượng trong sử dụng như khả năng của sản phẩm phần mềm cho phép người sử dụng để đạt được các mục tiêu cụ thể của họ có hiệu quả, năng suất, sự hài lòng và an toàn Những đặc tính này

Trang 36

Sự tồn tại và ứng dụng của hai tiêu chuẩn ISO/IEC 9126 và ISO/IEC 14.598 đã thúc đẩy sự phát triển của ISO/IEC 25000 - tiêu chuẩn SquaRE [7] Mục tiêu của việc tạo ra các tiêu chuẩn này là để cung cấp một tập hợp các tiêu chuẩn hợp lý và có tổ chức hơn, phong phú với những đóng góp mới, nhưng cũng thống nhất & phù hợp với các tiêu chuẩn trước đó Do đó SQuaRE là sự kết hợp của 2 tiêu chuẩn: ISO/IEC 9126

và ISO/IEC 14.598

2.3 Xây dựng phương pháp đánh giá tính tiện dụng [2]

Trong phần này chúng ta xem xét đến việc ứng dụng một phương pháp đánh giá tính tiện dụng để cung cấp một quy trình chung trong việc đánh giá tính tiện dụng của ứng dụng Web được phát triển theo hướng mô hình (Model-driven Web Development - MDWD) Ta sử dụng Mô hình tính tiện dụng của web (Web Usability Model) làm đầu vào và chia nhỏ tính tiện dụng thành các đặc tính [3] Các bước như sau:

Bước 1: Đưa ra ý tưởng cốt lõi của việc tích hợp một Mô hình tính tiện dụng của web vào MDWD để đánh giá và cải thiện tính tiện dụng các ứng dụng Web

Trang 37

37

Bước 2: Mô tả các đặc tính trong đó các Mô hình tính tiện dụng của web được tạo ra Mô tả này được chia thành hai quan điểm theo tiêu chuẩn ISO/IEC 25000 SquaRE [7]: Chất lượng sản phẩm phần mềm và chất lượng trong sử dụng

Bước 3: Cuối cùng là đánh giá tính tiện dụng bằng cách chi tiết hóa tất cả các giai đoạn của nó và đưa ra kết quả theo mỗi tiêu chí và/hoặc theo các giai đoạn khác nhau

Các phần tiếp theo sau đây sẽ mô tả cách tích hợp Mô hình tính tiện dụng của web vào MDWD (2.3.1) và đưa ra chi tiết Mô hình tính tiện dụng của web (2.3.2) Các phần này được kế thừa (có chỉnh sửa đôi chút) từ tài liệu tham khảo [2]

2.3.1 Tích hợp Mô hình tính tiện dụng của web vào MDWD

Hình 1 cho thấy tính tiện dụng của một ứng dụng Web có thể được đánh giá ở một số giai đoạn trong MDWD Một mô hình tính tiện dụng của web có thể được áp dụng theo các mức trừu tượng sau: (1) Mô hình nền tảng độc lập Platform-Independent Models ( PIMs ); (2) Mô hình nền tảng cụ thể Platform-Specific Models ( PSMs ); (3)

Mô hình Mã Code Model ( CM ); (4) Người dùng tương tác User Interaction Một mô hình tính tiện dụng của web có thể có một bộ rất lớn các đặc tính đo lường, do đó cần phải có một quá trình lựa chọn trước những đặc tính tính tiện dụng được coi là có liên quan theo một số yếu tố như mục tiêu/loại của ứng dụng Web, đối tượng người dùng, v.v Một khía cạnh cần xem xét là đặc tính từ Mô hình tính tiện dụng của web có thể được đánh giá ở tất cả các cấp độ trừu tượng Các thông tin phản hồi thu được trong mỗi loại đánh giá có mục đích khác nhau tùy thuộc vào mức độ trừu tượng của mô hình

Ở cấp PIM có thể đánh giá các mô hình như: mô hình điều hướng, v.v Tập các đặc tính đo lường có thể được đánh giá ở mức độ này chủ yếu liên quan đến cách thông tin sẽ được truy cập bởi người dùng như thế nào và cách thông tin này sẽ được trình bày bởi các mô hình giao diện người dùng trừu tượng như thế nào ((1) trong Hình 3)

Trang 38

38

Ở cấp PSM nó có thể đánh giá các mô hình giao diện cụ thể Tập các đặc tính đo lường có thể được đánh giá ở mức độ rộng hơn vì nó bao gồm các đặc tính liên quan đến các thành phần phần mềm cụ thể mà không thể được xem xét ở mức PIM ((2) trong Hình 3)

trừu tượng khác nhau, và

nên được thực hiện lặp đi

lặp lại cho đến khi các mô

hình này đạt được các yêu cầu tiện dụng Điều này cho phép tích hợp các đánh giá tính tiện dụng trong giai đoạn đầu của quá trình phát triển Web Tuy nhiên, việc đánh giá khi sử dụng của ứng dụng Web cần sự tham gia của người dùng cuối Việc đánh giá này cũng sẽ tạo ra một báo cáo tính tiện dụng để cung cấp thông tin phản hồi ở giai đoạn nào đó của quá trình phát triển ((1), (2) và (3) trong Hình 3)

Hình 3: Tích hợp WUM vào MDWD

Trang 39

39

2.3.2 Mô hình tính tiện dụng của web

Mô hình tính tiện dụng của web được đề xuất dựa trên mô hình tính tiện dụng cho các sản phẩm phần mềm chung đề xuất của các tác giả Abrahão và Insfran, 2006 [3] Mô hình này đã được mở rộng và thích nghi với các sản phẩm Web theo định hướng phù hợp với các tiêu chuẩn SQuaRE ISO/IEC 25000 [7] Tuy nhiên, các đặc tính trong tiêu chuẩn này là rất chung chung và được xác định ở một mức độ trừu tượng cao Mô hình tính tiện dụng của web sẽ làm chi tiết các đặc tính này thành một tập hợp các tiêu chuẩn đánh giá tính tiện dụng

2.3.2.1 Mô hình tính tiện dụng của web theo quan điểm chất lượng sản phẩm

Tiêu chuẩn ISO/IEC 25010 SquaRE [7] chỉ ra tính tiện dụng của một sản phẩm phần mềm có thể chia nhỏ thành các đặc tính sau: (1) Khả năng nhận biết, (2) Khả năng tìm hiểu, (3) Khả năng hoạt động, (4) Bảo vệ người dùng khỏi lỗi, (5) Khả năng truy cập, (6) Tính thẩm mỹ trong giao diện người dùng, (7) Sự tuân thủ

(1) Khả năng nhận biết đề cập đến mức độ mà người dùng có thể nhận ra liệu

một ứng dụng Web có thích hợp cho nhu cầu của họ hay không Trong Mô hình tính tiện dụng của web, đặc tính này được phân chia như trong Bảng 1:

Bảng 1: Phân tích về khả năng nhận biết

1.1 Tính dễ

đọc

1.1.1 Sự phù hợp của Font về màu sắc, kích cỡ, chủng loại

Thích ứng của phông chữ (màu sắc, chủng loại, kích thước) với bối cảnh

1.1.2 Khả năng nhận biết text

Sự kết hợp màu sắc của văn bản và nền không nên quá khó đọc

1.1.3 Bố cục Vị trí của văn bản để có thể nhìn thấy trong mọi tình huống

1.2 Khả năng

đọc 1.2.1 Thông tin liên kết Mức độ mà các thông tin được trình bày trong các nhóm tập trung theo chủ đề

Trang 40

Các khái niệm luôn luôn sử dụng các đại diện tương

tự hoặc ký hiệu (ví dụ: dd/mm/yyyy) 1.3.2 Phép ẩn dụ thích

hợp Sử dụng phép ẩn dụ từ thế giới thực để giúp làm cho sự tương tác tự nhiên hơn 1.3.3 Sự chuẩn hóa toàn

cầu Sử dụng các yếu tố theo các tiêu chuẩn quốc tế

1.4 Giảm khối

lượng công

việc

1.4.1 Thao tác tối thiểu Tối giản các thao tác trên một tác vụ

1.4.2 Tự mô tả Các yếu tố được hiển thị càng súc tích càng tốt

1.4.3 Mức độ Phức tạp của Thông tin Giảm tối thiểu việc tìm hiểu các thông tin được cung cấp bởi ứng dụng Web

1.5.2 Tiến độ tác vụ rõ ràng

Cung cấp tình trạng hiện tại của các tác vụ được thực hiện bởi người sử dụng (ví dụ: Số tác vụ đã hoàn thành, chỉ số trạng thái …)

1.5.3 Bối cảnh người dùng rõ ràng

Cung cấp các nội dung mô tả về tình trạng hoạt động của ứng dụng Web (ví dụ: trạng thái Log, mức độ riêng tư …)

1.6 Khả năng

điều hướng

1.6.1 Hỗ trợ tìm kiếm nội

bộ Cung cấp các tính năng tìm kiếm nội dung để cung cấp đường dẫn điều hướng

1.6.2 Khả năng click Thể hiện rõ trạng thái có thể click của đối tượng (ví dụ chuyển icon bàn tay khi hover lên đối tượng …)

1.6.3 Kết nối liên thông Tạo ra các mối quan hệ giữa các nội dung được hiển

thị trên Web

1.6.4 Khả năng tiếp cận Dễ truy cập vào nội dung / tính năng

Định dạng
Số trang	92
Dung lượng	2,81 MB

Nghiên cứu kỹ thuật kiểm thử hướng mô hình và đánh giá tính tiện dụng áp dụng vào phát triển phần mềm quản lý lưu trữ và số hóa tài liệu

Thông tin chung về dự án

Áp dụng kiểm thử hƣớng mô hình