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
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (2.81 MB, 92 trang )
Luận văn thạc sỹ
Nguyễn Hải Dương – CB130387
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
2.2
2.3
Giới thiệu........................................................................................................... 34
Tiêu chuẩn quốc tế về đánh giá tính tiện dụng. ............................................ 34
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
1
Luận văn thạc sỹ
2.5
Nguyễn Hải Dương – CB130387
Kết luận chƣơng ............................................................................................... 51
CHƢƠNG 3. THỰC NGHIỆM ÁP DỤNG VÀO PHÁT TRIỂN ỨNG
DỤNG WEB ........................................................................................................ 53
3.1
3.2
3.3
3.4
3.5
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
Mục tiêu thực nghiệm ...................................................................................... 59
Á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
Đá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 chƣơng ............................................................................................... 74
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
2
Luận văn thạc sỹ
Nguyễn Hải Dương – CB130387
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
3
Luận văn thạc sỹ
Nguyễn Hải Dương – CB130387
LỜI CẢM ƠN
Trong suốt thời gian thực hiện luận văn, tác giả đã nhận được rất nhiều sự quan
tâm, giúp đỡ của quý Thầy Cô, gia đình và bạn bè.
Với lòng biết ơn sâu sắc, em xin kính gửi Thầy giáo. PGS. TS Huỳnh Quyết
Thắng lời cảm ơn chân thành nhất. Thầy đã giúp đỡ em rất nhiều từ việc nhận là người
hướng dẫn luận văn cho em, đến việc tận tình chỉ bảo, giúp đỡ em trong suốt quá trình
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!
4
Luận văn thạc sỹ
Nguyễn Hải Dương – CB130387
DANH MỤC CÁC TỪ VIẾT TẮT VÀ THUẬT NGỮ
Từ viết tắt,
thuật ngữ
SUT
LTS
FSM
ESM
MDWD
WUEP
UML
Từ viết đầy đủ
Ý nghĩa
System Under Test
Labelled Transition System
Finite State Machine
Extended State Machine
Model-Driven Web
Developerment
Web Usability Evaluation
Process
Unified Modeling Language
Hệ thống được kiểm thử
Hệ thống chuyển đổi nhãn
Máy trạng thái hữu hạn
Máy trạng thái mở rộng
Phát triển ứng dụng web theo hướng
mô hình
Quy trình đánh giá tính tiện dụng của
ứng dụng web
Ngôn ngữ mô hình hóa thống nhất
5
Luận văn thạc sỹ
Nguyễn Hải Dương – CB130387
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
6
Luận văn thạc sỹ
Nguyễn Hải Dương – CB130387
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
7
Luận văn thạc sỹ
Nguyễn Hải Dương – CB130387
MỞ ĐẦU
1. Lý do chọn đề tài.
Ngày nay, các sản phẩm phần mềm nói chung và các ứng dụng web nói riêng
đang ngày càng được sử dụng rộng rãi và chứng tỏ vai trò to lớn của chúng trong mọi
hoạt động thực tế. Từ việc kinh doanh bán hàng online, thanh toán các hóa đơn mua
bán, trao đổi thông tin qua mạng internet, … đến việc quản lý dữ liệu theo các bài toán
nghiệp vụ khác nhau… Tuy nhiên, chất lượng của các sản phẩm này chưa thực sự được
đảm bảo, gây ra hao phí rất lớn trong quá trình phát triển phần mềm, nhất là trong giai
đoạn bảo trì.
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,
8
Luận văn thạc sỹ
Nguyễn Hải Dương – CB130387
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ỹ
9
Luận văn thạc sỹ
Nguyễn Hải Dương – CB130387
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.
B3. Lựa chọn phƣơng pháp:
Sau khi tìm hiểu và nghiên cứu các tài liệu đã thu thập được ở B2. tác giả đã lựa
chọn được 2 hướng đi cụ thể là:
-
Kiểm thử hướng mô hình – trợ giúp cho việc kiểm thử ứng dụng một cách tự
động, nhanh chóng, chính xác, trực quan và dễ dàng hơn nhiều so với cách
thủ công truyền thống
-
Đá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ả
10
Luận văn thạc sỹ
Nguyễn Hải Dương – CB130387
cũng đã chọn được các phương pháp thích hợp với từng hướng đi cụ thể, cho phép hiện
thực hóa hướng nghiên cứu này.
B4. Lựa chọn công nghệ:
Đầu tiên, để hiện thực hóa hướng đi của mình, tác giả đã lựa chọn công nghệ
ASP.NET và ngôn ngữ lập trình C# cho việc phát triển ứng dụng web “Quản lý lưu trữ
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.
11
Luận văn thạc sỹ
Nguyễn Hải Dương – CB130387
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”.
12
Luận văn thạc sỹ
Nguyễn Hải Dương – CB130387
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.
13
Luận văn thạc sỹ
Nguyễn Hải Dương – CB130387
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
14
Luận văn thạc sỹ
Nguyễn Hải Dương – CB130387
dụng web thì lại càng dễ bị tấn công bởi các nguy cơ thường trực trên mạng Internet
như Hacker, Virut, … Hay chỉ đơn giản là những người dùng cuối có kiến thức hạn chế
về tin học.
Vì vậy, trong thực trạng phát triển như hiện nay, các ứng dụng nói chung và các
ứng dụng web nói riêng cần được thiết kế và phát triển sao cho đảm bảo chất lượng
một cách tốt nhất, mang lại lợi ích cho cả nhà phát triển cũng như người dùng cuối.
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]).
15
Luận văn thạc sỹ
Nguyễn Hải Dương – CB130387
(2) "Kiểm thử là quá trình thực hiện một chương trình với mục đích tìm kiếm
lỗi." – (Định nghĩa bởi Myers [16]).
(3) "Kiểm thử phần mềm là một quá trình kỹ thuật thực hiện bằng cách thực thi /
kiểm tra một sản phẩm, trong một môi trường có kiểm soát, theo một thủ tục
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 91261)
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ế
16
Luận văn thạc sỹ
Nguyễn Hải Dương – CB130387
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.
17
Luận văn thạc sỹ
Nguyễn Hải Dương – CB130387
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
18
Luận văn thạc sỹ
Nguyễn Hải Dương – CB130387
làm các bước tiếp theo trong quy trình phát triển ứng dụng. Ngăn chặn sớm các lỗi cơ
bản của hệ thống mà thường rất dễ mắc phải/bỏ qua nếu sử dụng kiểm thử thường.
Thêm nữa, một nhược điểm chung của kiểm thử thường là cần có một lượng chi
phí cao cho việc tạo ra, thực hiện và duy trì các bộ kiểm thử. Cộng thêm việc không có
cách nào để truy xuất từ yêu cầu ra ca kiểm thử, dẫn đến hệ quả là với mỗi một thay
đổi yêu cầu ta đều cần kiểm tra lại các bộ kiểm thử một cách thủ công, dẫn đến hao phí
lớn. Đối với kiểm thử hướng mô hình, việc tạo ra mô hình kiểm thử ban đầu cũng tiêu
tốn một lượng chi phí lớn, nhưng đổi lại, chi phí cho việc duy trì kiểm thử trong kiểm
thử hướng mô hình lại thấp hơn rất nhiều, do: Mô hình kiểm thử được tạo ra một cách
thích hợp chỉ lần đầu và sau đó toàn bộ bộ kiểm thử sẽ được sinh ra một cách tự động.
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..
19
Luận văn thạc sỹ
Nguyễn Hải Dương – CB130387
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 đó:
20
Luận văn thạc sỹ
Nguyễn Hải Dương – CB130387
-
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
21
Luận văn thạc sỹ
Nguyễn Hải Dương – CB130387
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”.
22
Luận văn thạc sỹ
Nguyễn Hải Dương – CB130387
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 đã
23
Luận văn thạc sỹ
Nguyễn Hải Dương – CB130387
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ử.
24
Luận văn thạc sỹ
Nguyễn Hải Dương – CB130387
Ư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.
25
