Tải bản đầy đủ (.pdf) (56 trang)

Nghiên cứu tính khả kiểm thử của ứng dụng trên nền web

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 (1.92 MB, 56 trang )

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ

TRẦN THỊ THEN

NGHIÊN CỨU TÍNH KHẢ KIỂM THỬ
CỦA ỨNG DỤNG TRÊN NỀN WEB

LUẬN VĂN THẠC SỸ NGÀNH CÔNG NGHỆ THÔNG TIN

Hà Nội - 2014


ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ

TRẦN THỊ THEN

NGHIÊN CỨU TÍNH KHẢ KIỂM THỬ
CỦA ỨNG DỤNG TRÊN NỀN WEB

Ngành:
Công nghệ Thông tin
Chuyên ngành: Kỹ thuật Phần mềm
Mã số:

60480103

LUẬN VĂN THẠC SỸ NGÀNH CÔNG NGHỆ THÔNG TIN

NGƢỜI HƢỚNG DẪN KHOA HỌC: TS. Đặng Văn Hƣng



Hà Nội - 2014


i

LỜI CAM ĐOAN

Tôi xin cam đoan luận văn này là công trình nghiên cứu của cá nhân tôi,
dƣới sự hƣớng dẫn trực tiếp từ phía TS. Đặng Văn Hƣng. Các số liệu, nội dung
tham khảo đƣợc trích dẫn có nguồn gốc rõ ràng, tuân thủ tôn trọng quyền tác giả.
Kết quả cuối cùng đạt đƣợc của luận văn là thành quả của quá trình nghiên cứu của
bản thân, chƣa từng đƣợc công bố dƣới bất kỳ hình thức nào.
Tôi xin chịu trách nhiệm về nghiên cứu trong luận văn.
Tác giả

Trần Thị Then


ii

LỜI CẢM ƠN

Để hoàn thành đề tài luận văn này , bên ca ̣nh sƣ̣ chủ đô ̣ng cố gắ ng của bản
thân, tôi đã nhâ ̣n đƣơ ̣c sƣ̣ ủng hô ̣ và giúp đỡ nhiê ̣t tiǹ h tƣ̀ các tâ ̣p thể , cá nhân trong
và ngoài trƣờng.
Qua đây, cho phép tôi đƣơ ̣c bày tỏ lòng cảm ơn sâu sắ c tới thầ y giáo hƣớng
dẫn, TS. Đặng Văn Hƣng, giảng viên bộ môn Công nghệ phần mềm trƣờng Đại học
công nghê ̣ – Đa ̣i ho ̣c Quố c gia Hà Nô ̣i, ngƣời đã trƣ̣c tiế p đô ̣ng viên, đinh
̣ hƣớng và

hƣớng dẫn tâ ̣n tin
̀ h trong quá triǹ h ho ̣c tâ ̣p và hoàn thành đề tài luận văn này.
Đồng kính gửi lời cảm ơn đến tập thể các thầy , cô giáo trong trƣờng Đa ̣i ho ̣c
công nghê ̣ – Đa ̣i ho ̣c Quố c gia Hà Nô ̣i đã trau dồ i kiế n thƣ́c cho tôi , điề u đó là nề n
tảng quí báu góp phần to lớn trong quá triǹ h vâ ̣n du ̣ng vào hoàn thiê ̣n luâ ̣n văn.
Cuố i cùng, tôi xin đƣơ ̣c gƣ̉i lòng biế t ơn sâu sắ c đế n gia điǹ h , bạn bè, đồ ng
nghiê ̣p đã ta ̣o điề u kiê ̣n về vâ ̣t chấ t cũng nhƣ tinh thầ n , luôn sát cánh bên tôi , đô ̣ng
viên giúp tôi yên tâm học tập và kết thúc khóa học.
Xin chân thành cảm ơn!
Tác giả

Trần Thị Then


iii

MỤC LỤC
LỜI CAM ĐOAN ............................................................................................. i
LỜI CẢM ƠN .................................................................................................. ii
DANH MỤC CÁC KÝ HIỆU , THUẬT NGỮ, CHỮ VIẾT TẮT ................. v
DANH MỤC CÁC BẢNG ............................................................................. vi
DANH MỤC CÁC HÌNH VẼ ....................................................................... vii
PHẦN MỞ ĐẦU.............................................................................................. 1
Tính cấp thiết và mục tiêu của đề tài ............................................................ 1
Phƣơng pháp nghiên cƣ́u .............................................................................. 1
Bố cục của luận văn ...................................................................................... 2
CHƢƠNG 1. TỔNG QUAN ........................................................................... 3
1.1 Tầm quan trọng của tính khả kiểm thử ................................................ 3
1.2 Khái niệm tính khả kiểm thử................................................................ 4
1.3 Các khái niệm liên quan tính khả kiểm thử ......................................... 6

1.4 Một số yếu tố ảnh hƣớng đến tính khả kiểm thử ................................. 9
1.5 Một số độ đo tính khả kiểm thử ......................................................... 12
1.5.1 Độ đo cấu trúc và hành vi............................................................. 12
1.5.2 Độ đo luồng dữ liệu ...................................................................... 13
1.6 Kết chƣơng ......................................................................................... 14


iv
CHƢƠNG 2. KỸ THUẬT LÀM TĂNG TÍNH KHẢ KIỂM THỬ.............. 15
2.1 Tính khả kiểm thử của tài liệu đặc tả ................................................. 15
2.2 Tính khả kiểm thử của thiết kế kiến trúc ........................................... 18
2.3 Tính khả kiểm thử của thiết kế chi tiết............................................... 22
2.4 Kiểm thử xây dựng sẵn ...................................................................... 22
2.5 Khung và công cụ hỗ trợ kiểm thử..................................................... 23
2.6 Tổng kết.............................................................................................. 27
sCHƢƠNG 3. TÍNH KHẢ KIỂM THỬ CỦA ỨNG DỤNG TRÊN NỀN
WEB ......................................................................................................................... 28
3.1 Đặc trƣng chính của các ứng dụng trên nền web ............................... 28
3.2 Tính khả kiểm thử của các ứng dụng trên nền web ........................... 31
3.2.1 Khía cạnh là một phần mềm......................................................... 31
3.2.2 Tính khả kiểm thử cho phần máy chủ .......................................... 32
3.2.3 Tính khả kiểm thử cho phần trình duyệt ...................................... 35
KẾT LUẬN .................................................................................................... 44
TÀI LIỆU THAM KHẢO ............................................................................. 45


v

DANH MỤC CÁC KÝ HIỆU , THUẬT NGỮ, CHỮ VIẾT TẮT


STT

1

CHỮ VIẾT TẮT, THUẬT
NGỮ, KÝ HIỆU

Artifact

GIẢI NGHĨA
Khi phát triển một phần mềm chúng ta không chỉ
tạo ra phần chƣơng trình mà thƣờng tạo ra nhiều
sản phẩm trung gian khác nhƣ các tài liệu đặc tả
yêu cầu, tài liệu thiết kế, mã nguồn và chƣơng
trình phần mềm. Tiếng Anh dùng từ artifact để
chỉ chung các sản phẩm này

2

SOAP

Simple Object Access Protocol – Giao thức truy
cập đối tƣợng đơn giản

3

Use case

Ca sử dụng


4

SRS

Software Requirements Specification – Đặc tả
yêu cầu phần mềm

5

BDD

Behavior Driven Development – Phát triển
hƣớng hành vi

6

BIT

Built – in test – Kiểm thử xây dựng sẵn, đi kèm
với cài đặt phần mềm


vi

DANH MỤC CÁC BẢNG

Bảng 1 Kịch bản thuộc tính chất lƣợng dạng bảng ................................................. 19
Bảng 2 Một số công cụ và khung kiểm thử ............................................................ 26
Bảng 3 Url có ngữ nghĩa ......................................................................................... 33



vii

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

Hình 1 Ví dụ về một file log ..................................................................................... 8
Hình 2 Chạy javac ở chế độ thƣờng và chế độ verbose ............................................ 9
Hình 3 Sáu yếu tố ảnh hƣởng đến tính khả kiểm thử.............................................. 10
Hình 4 Một kịch bản thuộc tính chất lƣợng cho tính khả kiểm thử ........................ 18
Hình 5 Các chiến thuật khả kiểm thử ...................................................................... 20
Hình 6 Kiến trúc của mô-đun với mã tự kiểm tra [13] ........................................... 23
Hình 7 Công cụ hỗ trợ lấy thông tin về ứng dụng .................................................. 24
Hình 8 Kiến trúc chung của ứng dụng web............................................................. 29
Hình 9 Mô hình tổng quát của các ứng dụng trên nền web .................................... 31
Hình 10 Ví dụ url .................................................................................................... 33
Hình 11 Màn hình SOAP UI ................................................................................... 35
Hình 12 WebDriver ................................................................................................. 36
Hình 13 Ví dụ sử dụng Selenium với Java ............................................................. 36
Hình 14 Một đoạn mã HTML của trang web asp.net ............................................. 38
Hình 15 Một đoạn mã HTML của trang web ruby-lang ......................................... 39


viii


1

PHẦN MỞ ĐẦU

Tính cấp thiết và mục tiêu của đề tài

Sự phát triển và lan tỏa rộng rãi của Internet trên toàn cầu những năm gần
đây là cơ sở đánh dấu cho sự bùng nổ mạnh mẽ của các ứng dụng đƣợc viết trên
nền web. Các ứng dụng này có sự tăng mạnh về số lƣợng cũng nhƣ doanh thu.
Do đó để có sự canh tranh cao, các công ty phần mềm đang không ngừng tìm
cách cải tiến chất lƣợng ứng dụng, giảm chi phí, đồng thời đẩy nhanh tốc độ xây
dựng ứng dụng.
Làm việc trong một đơn vị xây dựng phần mềm trong gần năm năm, tôi
đã tham gia vào không ít dự án với vai trò là kỹ sƣ kiểm thử, trƣởng nhóm kiểm
thử và nhận thấy nỗ lực kiểm thử và sửa lỗi của các dự án quá lớn (chiếm tới
60-70% nỗ lực cả dự án). Và các nỗ lực này tập trung nhiều nhất ở hai giai đoạn
kiểm thử là kiểm thử chức năng và kiểm thử hồi quy.
Ngoài nỗ lực kiểm thử lớn, tác giả còn nhận thấy có nhiều lỗi tiềm ẩn mà
trong quá trình kiểm thử rất khó hoặc gần nhƣ không có khả năng tìm ra. Thông
qua đề tài này, tôi mong muốn tìm ra phƣơng pháp để việc kiểm thử dễ dàng
thực hiện hơn, tránh đƣợc các lỗi tiềm ẩn nhằm giảm bớt các thiệt hại do lỗi
không đƣợc phát hiện gây ra, đồng thời là cơ sở để giảm nỗ lực, chi phí cho việc
kiểm thử.

Phương pháp nghiên cứu
Để đề tài đạt đƣợc kết quả nhƣ mục tiêu đặt ra, trong luận văn tôi đã đề
xuất và áp dụng các phƣơng pháp nghiên cứu nhƣ sau:
- Nghiên cứu tài liệu: Nghiên cứu các khái niệm về tính khả kiểm thử và tập
trung vào các kỹ thuật làm tăng tính khả kiểm thử. Đây là mảng kiến thức
mà các nghiên cứu trên thế giới vẫn còn hạn chế, các khái niệm còn chƣa


2
có sự thống nhất do đó đòi hỏi nhiều kiến thức nền tảng để lựa chọn thông
tin cho phù hợp với mục tiêu đặt ra ban đầu.
- Phân tích và áp dụng: Qua việc phân tích các đặc thù của ứng dụng web

tôi đƣa ra một số chú ý để tăng tính khả kiểm thử cho lớp ứng dụng này.
Các đề xuất này đƣợc trao đổi với các đồng nghiệp để nhận đƣợc góp ý từ
đội phát triển phần mềm, gồm cả lập trình viên, kiểm thử viên.

Bố cục của luận văn
Phần còn lại của luận văn đƣợc trình bày theo các phần chính sau:
 Chƣơng 1: Tổng quan. Chƣơng này trình bày một số kiến thức cơ
sở về tính khả kiểm thử nhƣ các khái niệm, các yếu tố ảnh hƣởng
đến tính khả kiểm thử, lợi ích khi chúng ta chú ý đến tính khả kiểm
thử.
 Chƣơng 2: Kỹ thuật làm tăng tính khả kiểm thử. Chƣơng này
trình bày một số khái niệm về tính khả kiểm thử thông qua các độ
đo cấu trúc thiết kế và chƣơng trình. Chƣơng này cũng trình bày
một số kỹ thuật điển hình nhằm tăng tính khả kiểm thử của một hệ
thống phần mềm nói chung.
 Chƣơng 3: Tính khả kiểm thử của ứng dụng trên nền web.
Chƣơng này phân tích đặc điểm của ứng dụng web và đề xuất một
số điểm quan trọng cần chú ý để tăng tính khả kiểm thử của các
ứng dụng web nói chung.
 Kết luận: Tổng hợp các kết quả đạt đƣợc, tồn tại và hƣớng mở
rộng của đề tài.


3

CHƢƠNG 1. TỔNG QUAN

Trong chƣơng này, chúng ta sẽ xem xét các khái niệm cơ bản nhất khi nói
về tính khả kiểm thử [1]. Bao gồm các khái niệm, tầm quan trọng, các yếu tố tác
động đến tính khả kiểm thử. Mục tiêu là để cho ngƣời đọc có cái nhìn tổng quan

nhất về tính khả kiểm thử.

1.1 Tầm quan trọng của tính khả kiểm thử
Tính khả kiểm của phần mềm là một trong những khái niệm quan trọng
trong thiết kế và kiểm thử chƣơng trình và các thành phần phần mềm. Xây dựng
các chƣơng trình và các thành phần với tính khả kiểm thử cao luôn luôn làm
đơn giản hóa việc thực hiện kiểm thử, giảm chi phí kiểm thử và tăng chất lƣợng
phần mềm. Chi phí kiểm thử đang chiếm khoảng 50% chi phí sản xuất một phần
mềm. Tăng tính khả kiểm thử là điều kiện cần thiết để giảm tận gốc chi phí
kiểm thử phần mềm nói riêng và chi phí sản xuất phần mềm nói chung.
Một số chuyên gia kiểm thử và phát triển phần mềm đã chỉ ra tầm quan
trọng của tính khả kiểm thử và thiết kế, đặc biệt là đối với các hệ thống lớn:
 Trong quá trình phân tích thiết kế một hệ thống, chúng ta không
chỉ cần quan tâm đến tính khả thi (có thể xây dựng đƣợc) mà còn
phải chú ý đến tính khả kiểm thử của chúng.
 Bỏ qua việc thiết kế để có khả năng kiểm thử cao trong các hệ
thống lớn có thể làm giảm hiệu quả kiểm thử rất nhiều [2].
Tầm quan trọng của tính khả kiểm thử phần mềm đối với một hệ thống
phần mềm nào đó tỷ lệ thuận với:
 Kích thƣớc và độ phức tạp của hệ thống


4
 Các rủi ro đối với cuộc sống và kinh doanh nếu có lỗi không đƣợc
phát hiện
 Tần suất của các hoạt động kiểm thử
 Vòng đời của hệ thống (giả sử rằng kiểm thử hồi quy và bảo trì là
nhiệm vụ thƣờng xuyên)
Tính khả kiểm thử rất quan trọng đối với kiểm thử viên và lập trình viên
vì nó giúp họ kiểm soát đƣợc nỗ lực kiểm thử. Khách hàng cũng sẽ đƣợc lợi ích

nếu chất lƣợng sản phẩm cao hơn và tốc độ sửa lỗi nhanh hơn. Những tính chất
của tính khả kiểm thử nhƣ: xây dựng mã nguồn phục vụ kiểm thử tự động, báo
cáo lỗi tự động, và khả năng chuẩn đoán lỗi bên trong (built-in diagnostic) sẽ
cung cấp thông tin nhanh hơn, tốt hơn về nguyên nhân lỗi và do đó giúp đẩy
nhanh tiến độ sửa lỗi.
Sau khi đã ƣớc lƣợng, tính toán đƣợc tính khả kiểm thử của một hệ thống,
ta có thể đƣa ra các thông tin hữu ích cho kiểm thử viên, lập trình viên và quản
trị dự án nhằm mục đích:
 Tập trung vào các thành phần có tính khả kiểm thấp – xem xét mã
nguồn, phân tích hình thức, tiêu chuẩn kiểm thử cao hơn
 Thay đổi các thành phần có tính khả kiểm thấp để tăng tính khả
kiểm
 Tự tin hơn với các thành phần có tính khả kiểm cao
 Phân tích rủi ro đối với các thành phần có tính khả kiểm thấp để
xác định các rủi ro của hệ thống cũng nhƣ tìm ra nguyên nhân gốc

1.2 Khái niệm tính khả kiểm thử
Khi phát triển một phần mềm chúng ta không chỉ tạo ra phần chƣơng
trình mà thƣờng tạo ra nhiều sản phẩm trung gian khác nhƣ các tài liệu đặc tả
yêu cầu, tài liệu thiết kế, mã nguồn và chƣơng trình phần mềm. Tiếng Anh dùng
từ artifact để chỉ chung các sản phẩm này. Tính khả kiểm thử là các đặc tính của
các artifact mà các đặc tính này ảnh hƣởng đến sự dễ dàng đạt đƣợc các mục


5
tiêu kiểm thử. Nó đƣợc định nghĩa là “mức độ mà một artifact phần mềm tạo
điều kiện cho việc kiểm thử” [3].
Định nghĩa này cho ta thấy:
 Không chỉ mã nguồn hay bản chạy chƣơng trình ảnh hƣởng đến
kiểm thử mà là toàn bộ các artifact tạo ra trong quá trình phát triển

phần mềm đều có vài trò quan trọng.
 Liệu một artifact có tạo điều kiện cho việc kiểm thử hay không chỉ
có thể đƣợc xác định trong ngữ cảnh kiểm thử, ví dụ, với mục tiêu,
nguồn lực, kỹ thuật và công cụ kiểm thử.
Chúng ta xem một ví dụ để hiểu rõ hơn khái niệm tính khả kiểm thử này.
Một artifact mô tả một giao diện phần mềm sẽ hỗ trợ việc kiểm thử hộp đen và
nó không hỗ trợ kiểm thử hộp trắng vì giao diện không nêu cấu trúc của cài đặt
(implementation) của giao diện đó. Nếu mục tiêu kiểm thử không phải là đạt
đƣợc một mức độ bao phủ kiểm thử hộp trắng, ví dụ bao phủ 100% dòng lệnh,
thì mô tả giao diện không có ảnh hƣởng gì nhiều đến việc đạt mục tiêu.
Ngoài định nghĩa về tính khả kiểm thử trên có một số định nghĩa khác về
tính khả kiếm thử. Theo [4], tính khả kiểm thử là sự dễ dàng và chi phí tƣơng
đối để tìm ra lỗi phần mềm.
Theo thuật ngữ của IEEE [5], tính khả kiểm thử gồm:
 “mức độ dễ dàng thiết lập các tiêu chuẩn kiểm thử và thực thi kiểm
thử của một hệ thống hay một thành phần hệ thống để xác định
xem các tiêu chuẩn đó có đƣợc thỏa mãn không.”
 “mức độ cho phép thiết lập các tiêu chuẩn kiểm thử và thực thi
kiểm thử đối với một yêu cầu để xác định xem các tiêu chuẩn đó có
đƣợc thỏa mãn không”.
Theo chuẩn ISO về chất lƣợng sản phẩm phần mềm [6], tính khả kiểm
thử là tập các thuộc tính có liên quan đến nỗ lực cần thiết để thẩm định
(validate) một phần mềm đã sửa đổi.


6
Nhƣ vậy chúng ta có thể thấy, về cơ bản, tính khả kiểm thử đều đƣợc hiểu
là mức độ dễ dàng để thực hiện việc kiểm thử hay mức độ dễ dàng để tìm ra lỗi
của hệ thống phần mềm. Các việc kiểm thử không chỉ áp dụng cho chƣơng trình
phần mềm mà còn cả các sản phẩm trung gian nhƣ tài liệu yêu cầu, thiết kế, v.v.

Tuy nhiên, các định nghĩa vẫn có những chi tiết khác nhau về định nghĩa một hệ
thống thế nào là có tính khả kiểm thử cao. Trong chƣơng sau, chúng ta sẽ
nghiên cứu cụ thể hơn về một trong những cách để đo đạc một cách định lƣợng
tính khả kiểm thử của một hệ thống.

1.3 Các khái niệm liên quan tính khả kiểm thử
Khả năng kiểm soát và khả năng quan sát là hai khái niệm mấu chốt của
tính khả kiểm thử [4]. Để kiểm thử một thành phần, ta cần phải kiểm soát đƣợc
đầu vào và quan sát đƣợc đầu ra. Khả năng kiểm soát là khả năng điều khiển dễ
dàng đầu vào để chuyển phần mềm đến một trạng thái cụ thể nào đó. Còn khả
năng quan sát liên quan đến mức độ dễ dàng trong việc quan sát kết quả đầu ra
và các thay đổi về trạng thái của phần mềm. Nếu không có đƣợc hai khả năng
này, việc cải tiến khả năng kiểm thử hệ thống là rất khó thực hiện. Hay nói cách
khác, một thành phần của phần mềm đƣợc gọi là khả kiểm thử nếu nó có hai
thuộc tính này.
Khả năng kiểm soát là khả năng điều khiển các thành phần của phần
mềm đến các trạng thái mong muốn thông qua các giá trị đầu vào. Giá trị đầu
vào có thể là các biến của hàm/phƣơng thức, lấy từ tƣơng tác của ngƣời dùng
thông qua giao diện phần mềm hoặc các tƣơng tác bên trong/bên ngoài của ứng
dụng, đƣợc lƣu trữ, thao tác trong các biến và có khả năng thay đổi tùy vào
phạm vi của biến.
Trạng thái phần mềm là một tập các biến và các giá trị tƣơng ứng tại một
thời điểm nhất định. Trong một mô-đun hay một đơn vị chƣơng trình, có thể có
vô số các trạng thái này, tuy nhiên chỉ một tập nhỏ các kết hợp là có ý nghĩa và
đƣợc quan tâm. Ví dụ phần mềm thao tác trên tài khoản ngân hàng: khi chủ tài
khoản rút tiền, phần mềm sẽ đánh dấu trạng thái tài khoản đó là „đang hoạt
động‟ khi hoàn tất giao dịch. Nếu là thẻ tín dụng, sự thay đổi trạng thái tài


7

khoản chỉ đƣợc chủ thẻ để ý khi tài khoản không còn đủ tiền so với số tiền
khách rút. Tài khoản khi đó có thể đƣợc đánh dấu là rút quá (overdrawn). Khả
năng thao tác trên các đầu vào và quan sát trạng thái dễ dàng sẽ giúp đội phát
triển có thể tạo ra một bộ kiểm thử tự động hiệu quả.
Khả năng quan sát là khả năng nhìn đƣợc phản ứng của hệ thống đối
với các đầu vào và theo dõi đƣợc các thay đổi trạng thái của phần mềm. Thƣờng
thì ta có thể thấy đầu ra của hệ thống, tuy nhiên, có nhiều phản ứng hay trạng
thái trung gian có thể không đúng và ta thƣờng không nhìn thấy. Ba điều kiện
cần để một lỗi xuất hiện là: (1) chạy mã nguồn có lỗi; (2) mã nguồn lỗi đó dẫn
đến 1 trạng thái dữ liệu sai; (3) trạng thái sai này đƣợc nhìn thấy. Khả năng
quan sát là sự dễ dàng để của hệ thống giúp chúng ta xem đƣợc cả các trạng thái
trung gian mà bình thƣờng không quan sát đƣợc.
Thực hiện các phƣơng pháp để tăng khả năng quan sát các trạng thái sẽ
giúp phát hiện các lỗi tiềm ẩn của chƣơng trình. Khả năng quan sát do đó có liên
quan đến thể hiện của kết quả kiểm thử phần mềm. Có thể tăng cƣờng khả năng
quan sát của phần mềm bằng nhiều cách: ghi log, truy vết, chèn mã (code
instrumentation), thăm dò và chèn các câu lệnh in ra màn hình vào mã nguồn.
Ví dụ khi lập trình chúng ta ghi ra các file log một số cột mốc của hệ thống, nhƣ
bắt đầu một hàm, kết thúc một hàm, hoặc một sự kiện nào đó, thì khi xem lại
các file log này để giúp quan sát bên trong hệ thống thì chúng ta đã tăng khả
năng quan sát của phần mềm. Hình 1 là một ví dụ về log hệ thống cho thấy các
thông tin chi tiết về hoạt động của hệ điều hành.


8

Hình 1 Ví dụ về một file log

Một ví dụ khác về khả năng quan sát là một số phần mềm có chế độ chạy đặc
biệt (verbose mode) để in ra chi tiết quá trình chạy cho ngƣời sử dụng quan sát.

Ví dụ với chƣơng trình HelloWorld.java khi dịch ở chế độ thƣờng thì trên màn
hình không có thông báo gì nếu dịch thành công. Còn khi dịch với tham số verbose thì kết quả trên màn hình nhƣ trong Hình 1 (đã lƣợc bớt thông tin).


9

C:\Users\thentt>javac HelloWorld.java
C:\Users\thentt>javac -verbose HelloWorld.java
[parsing started RegularFileObject[HelloWorld.java]]
[parsing completed 26ms]
[search path for source files: .]
[search path for class files: C:\Program
Files\Java\jdk1.8.0_11\jre\lib\resources.jar,C:\Program
Files\Java\jdk1.8.0_11\jre\lib\rt.jar, ....]
[loading ZipFileIndexFileObject[C:\Program
Files\Java\jdk1.8.0_11\lib\ct.sym(METAINF/sym/rt.jar/java/lang/Object.class)]]...
[checking HelloWorld]
[loading ZipFileIndexFileObject[C:\Program
Files\Java\jdk1.8.0_11\lib\ct.sym(METAINF/sym/rt.jar/java/io/Flushable.class)]]...
[wrote RegularFileObject[HelloWorld.class]]
[total 280ms]

Hình 2 Chạy javac ở chế
độ thường
và chế độ verbose
Hình
1

Ở ví dụ này chúng ta có thể thấy khi chạy với tham số verbose, chƣơng
trình dịch in rất nhiều thông tin chi tiết từng bƣớc hoạt động bên trong của

chƣơng trình dịch, giúp ta quan sát đƣợc các thông tin.

1.4 Một số yếu tố ảnh hướng đến tính khả kiểm thử
Theo [4] có sáu yếu tố chính ảnh hƣởng đến tính khả kiểm thử của một
phần mềm. Sáu yếu tố tƣơng ứng với các bƣớc chính trong quy trình phát triển
phần mềm cơ bản gồm1:

1

/>

10

Hình 3 Sáu yếu tố ảnh hưởng đến tính khả kiểm thử

Yếu tố về tài liệu mô tả: Hành vi và kiến trúc phần mềm có thể đƣợc tài
liệu hóa dƣới dạng các đặc tả yêu cầu, cách nhìn kiến trúc, mô hình thiết kế chi
tiết và các giả thuật toán. Sự rõ ràng và ngắn gọn của tài liệu này có thể hỗ trợ
tính khả kiểm thử. Một số đặc điểm của tài liệu làm tăng khả năng kiểm thử bao
gồm: các yêu cầu đƣợc mô tả rõ ràng, không mơ hồ, có tính khả thi khi sinh ca
kiểm thử từ yêu cầu, thiết kế chi tiết triệt để, khả năng lƣu vết khi cài đặt và
phân chia chức năng một cách tách bạch.
Yếu tố về cài đặt: Phần mềm đƣợc cài đặt với nhiều ngôn ngữ lập trình
và mô hình khác nhau. Các tính năng có sẵn trong những ngôn ngữ và mô hình
này làm cho việc kiểm thử khó khăn hơn hay dễ dàng hơn phụ thuộc vào cách
chúng đƣợc sử dụng. Ví dụ, trong các hệ thống hƣớng đối tƣợng, thừa thế là
một đặc tính có thể gây khó khăn cho việc kiểm thử nếu cây thừa kế có nhiều
mức vì các lớp ở mức thấp hơn cần phải hoạt động giống với các lớp ở mức cao
hơn.
Yếu tố về kiểm thử kèm theo: Mã nguồn đƣợc viết thêm các lệnh để

kiểm tra tính chất của dữ liệu nhằm giảm bớt công việc kiểm thử. Nó giúp hệ
thống có khả năng tự kiểm tra và những kiểm tra này không là các tính năng
đƣợc mô tả trong đặc tả của phần mềm. Ví dụ, các lệnh assert trong các ngôn
ngữ lập trình hiện đại nhằm giúp viết các lệnh kiểm tra này dễ dàng hơn.


11
Ví dụ sau 2 thể hiện việc sử dụng lệnh assert để kiểm tra giá trị của biến
truyền vào nằm trong khoảng hợp lệ.
1.
2.
3.
4.
5.
6.
7.
8.

/**
Sets the refresh interval (which must correspond to a legal frame
rate).
*
@param interval refresh interval in milliseconds.
*/
private void setRefreshInterval(int interval) {
// Confirm adherence to precondition in nonpublic method
assert interval > 0 && interval <= 1000/MAX_REFRESH_RATE :
interval;

9. ... // Set the refresh interval

10. }

Yếu tố về bộ kiểm thử: Bộ kiểm thử là một tập các ca kiểm thử và các
bƣớc để thực hiện các ca kiểm thử đó. Bộ kiểm thử hƣớng dẫn cách để dự đoán
các kết quả kiểm thử, do đó nó giúp cho việc kiểm thử hệ thống dễ dàng hơn.
Bộ kiểm thử cũng đƣợc sử dụng lại mỗi khi kiểm thử hồi quy một hệ
thống. Nếu việc kiểm thử hồi quy này đƣợc thực hiện tự động một cách hiệu
quả thì rõ ràng nó giúp tiết kiệm các chi phí và nỗ lực kiểm thử. Bộ kiểm thử
nếu đƣợc tổ chức một cách khoa học và có khả năng mở rộng sẽ làm tăng hiệu
quả của công việc kiểm thử.
Yếu tố về công cụ kiểm thử: Có các công cụ thực thi các kịch bản kiểm
thử tự động, ghi lại các bƣớc thực thi, lƣu thông tin trạng thái và thông tin, sau
đó báo cáo kết quả kiểm thử làm cho việc kiểm thử dễ dàng hơn rất nhiều. Đặc
biệt là giảm bớt nỗ lực kiểm thử trong giai đoạn kiểm thử hồi quy.
Nếu hệ thống cho phép áp dụng dễ dàng các công cụ kiểm thử tự động và
thay đổi dễ dàng bộ kiểm thử khi chƣơng trình thay đổi thì rõ ràng nó có ảnh
hƣởng tích cực đến khả năng kiểm thử hệ thống.

2

/>

12
Yếu tố về quy trình kiểm thử: Nên có một cam kết đối với việc kiểm
thử phần mềm của đơn vị sản xuất phần mềm. Điều này phản ánh trong nguồn
lực liên quan đến kiểm thử nhƣ nhân sự thực hiện, chiến lƣợc kiểm thử hệ thống
và việc tích hợp công việc kiểm thử trong suốt quy trình phát triển.

1.5 Một số độ đo tính khả kiểm thử
Theo Binder [4] khả năng kiểm thử đƣợc đánh giá hay đo dựa trên các độ

đo của chƣơng trình phần mềm là độ phức tạp cấu trúc và hành vi, và độ phức
tạp luồng dữ liệu. Độ đo cấu trúc và hành vi thể hiện các thành phần phần mềm
trong hệ thống và quan hệ, tƣơng tác giữa chúng. Độ đo luồng dữ liệu mô tả sự
phức tạp của các đƣờng đi dữ liệu di chuyển trong hệ thống.
1.5.1 Độ đo cấu trúc và hành vi
Chúng ta biết rằng khi thiết kế một phần mềm chúng ta thƣờng thể hiện
bằng các mô hình, gồm các thành phần và liên kết giữa chúng (về cấu trúc),
cũng nhƣ tƣơng tác giữa các thành phần đó trong quá trình hoạt động của phần
mềm (về hành vi). Các mô hình cấu trúc và hành vi này cuối cùng sẽ đƣợc
chuyển sang bƣớc cài đặt chƣơng trình phần mềm. Các mô hình và chƣơng trình
đều có thể đƣợc sử dụng để phục vụ công việc kiểm thử nên chúng ảnh hƣởng
trực tiếp đến mức độ dễ dàng để thực hiện việc kiểm thử. Các tài liệu và mã
nguồn phần mềm này sẽ đƣợc phân tích để chọn ra các thuộc tính dùng làm độ
đo để đo lƣờng tính khả kiểm thử.
Ngôn ngữ mô hình hóa thống nhất UML là một ngôn ngữ mô hình hóa
phổ biến để mô tả cấu trúc và hành vi phần mềm. Qua nghiên cứu, ngƣời ta thấy
rằng, các mô hình lớp và mô hình trạng thái trong UML là hai mô hình chính
ảnh hƣớng đến tính khả kiểm thử nên chúng đƣợc tập trung phân tích khi nói
đến khả năng kiểm thử. Các mô hình này có thể gây khó khăn cho việc kiểm thử
do các tác động phụ phát sinh khi các đối tƣợng tƣơng tác với nhau.
Ví dụ, một đối tƣợng thay đổi trạng thái của một đối tƣợng khác qua
nhiều cách (đƣờng) khác nhau. Những khu vực này cần đƣợc chú ý để cải thiện


13
tính khả kiểm thử. Hình 2 mô tả một ví dụ của các tƣơng tác lớp có thể dẫn đến
các tƣơng tác đối tƣợng nhƣ vậy. Trong hình này một đối tƣợng của lớp C có
thể tƣơng tác ngầm với một đối tƣợng của lớp D, hoặc trực tiếp thông qua quan
hệ lớp hoặc gián tiếp thông qua phân cấp kế thừa các lớp A, A2 hoặc A21.


Hình 2 Tương tác lớp dẫn đến các tương tác đối tượng

Độ phức tạp của các tƣơng tác đƣợc mô hình hóa bởi biểu đồ lớp này có
thể là cơ sở để đo tính khả kiểm thửu của phần mềm. Ở mức mã nguồn chƣơng
trình, việc phân tích tĩnh mã nguồn cũng có thể cung cấp một thông tin về độ đo
tính khả kiểm thử.
Phân tích tĩnh mã nguồn cũng đƣợc sử dụng để dự đoán tính khả kiểm
của các lớp trong một hệ thống hƣớng đối tƣợng. Chẳng hạn, để phân tích mối
tƣơng quan giữa các thuộc tính hƣớng đối tƣợng với kích thƣớc bộ kiểm thử, có
thể sử dụng hai độ đo là độ đo về độ sâu của cây phân cấp, số dòng lệnh cho
mỗi lớp, và số con của một lớp và độ đo về số lƣợng ca kiểm thử. Hay nói khác
đi, hai độ đo này có thể trả lời câu hỏi các thuộc tính hƣớng đối tƣợng có ảnh
hƣởng gì đến số lƣợng và độ phức tạp của các ca kiểm thử.
1.5.2 Độ đo luồng dữ liệu
Độ đo luồng dữ liệu dựa vào luồng dữ liệu đi các thành phần của phần
mềm để đánh giá/đo tính khả kiểm thử. Các mô hình luồng dữ liệu cho thấy dữ
liệu trong hệ thống di chuyển theo các đƣờng nhƣ thế nào. Các độ đo luồng dữ
liệu có thể dựa trên việc phân tích các mô hình luồng dữ liệu hoặc mã nguồn


14
chƣơng trình. Các kỹ thuật phân tích luồng dữ liệu đã đƣợc sử dụng trong các
trình biên dịch để thực hiện phân tích tĩnh mã nguồn và xác định đƣờng đi dữ
liệu trong phần mềm.
Theo [7] một kỹ thuật đồ thị đƣợc gọi là đồ thị chuyển thông tin –
Information Transfer Graph (ITG) đƣợc sử dụng để phân tích luồng dữ liệu
trong các thành phần phần mềm. Một ITG đƣợc tạo ra suốt quá trình phân tích
một mô hình luồng dữ liệu. Một luồng đƣợc định nghĩa là sự chuyển động/sự
thay đổi của dữ liệu từ đầu vào, xuyên suốt một số các thành phần, đến một đầu
ra của hệ thống. Bài báo cũng đƣa ra nhiều độ đo khả kiểm thử.

Ví dụ tính khả kiểm thử của các cặp def-use (từ lúc biến đƣợc gán giá trị def, đến lúc giá trị của biến đƣợc sử dụng use) đƣợc đo bằng nghịch đảo của
tổng số cặp def-use trong chƣơng trình. Dễ thấy giá trị này càng cao có nghĩa
chƣơng trình càng dễ kiểm thử.

1.6 Kết chương
Chƣơng này tóm tắt khái quát một số độ đo của tính khả kiểm thử một
phần của phần mềm. Để giảm chi phí và tăng hiệu quả kiểm thử, việc đo đạc và
tăng tính khả kiểm thử cần đƣợc thực hiện càng sớm càng tốt để tránh phải thiết
kế lại hoặc cài đặt lại về sau. Điều này có nghĩa chúng ta phải chú ý tính khả
kiểm thử của tài liệu đặc tả đầu tiên, tiếp đó là phải chú ý đến tính khả kiểm thử
của thiết kế, rồi mới đến tính khả kiểm thử mã nguồn, v.v.
Ở mỗi giai đoạn của quá trình phát triển phầm mềm lại có nhiều độ đo
khác nhau nên việc chọn một độ đo phù hợp là việc cần phân tích, cân nhắc.
Một số độ đo phức tạp nhƣng phản ánh chính xác hơn tính khả kiểm thử, một số
độ đo lại đơn giản nhƣng đánh giá khá thô tính khả kiểm thử. Chúng ta cần chọn
độ đo cân bằng giữa nhu cầu khả kiểm thử của từng giai đoạn và công sức bỏ ra
để thực hiện việc tính toán, đo đạc các độ đo này.


15

CHƢƠNG 2. KỸ THUẬT LÀM TĂNG TÍNH KHẢ KIỂM THỬ

Chƣơng trƣớc đã nói về các độ đo đƣợc sử dụng để làm giảm công việc
kiểm thử phần mềm. Tuy nhiên, bản thân phép đo tính khả kiểm không làm cho
phần mềm có khả năng kiểm thử hơn mà là giúp đánh giá chất lƣợng của việc
phát triển để hƣớng tới việc nâng cao yếu tố chất lƣợng này, tức là nâng cao tính
khả kiểm thử. Trong chƣơng này, chúng ta sẽ xem xét một số kỹ thuật có thể
đƣợc sử dụng để cải tiến tính khả kiểm thử phần mềm dựa trên [4]. Độ đo tính
khả kiểm thử là một thƣớc đo giúp chúng ta biết đã cải tiến đƣợc bao nhiêu.

Thiết kế phần mềm là bƣớc xây dựng các tài liệu nhƣ đặc tả yêu cầu,
khung nhìn kiến trúc và các mô hình thiết kế chi tiết. Các tài liệu này cuối cùng
sẽ đƣợc dùng trong pha kiểm thử phần mềm vì nó mô tả các hành vi và đặc tính
mong muốn của phần mềm. Chất lƣợng của mỗi tài liệu này sẽ giúp cho bƣớc
cài đặt, bƣớc kiểm thử thực hiện ở giai đoạn sau thực hiện dễ dàng hơn. Tuy
nhiên, đối với mỗi tài liệu sẽ có sự tƣơng tác riêng đến khả năng kiểm thử mà ta
cần xem xét cụ thể, chi tiết.

2.1 Tính khả kiểm thử của tài liệu đặc tả
Một trong những giai đoạn đầu của thiết kế phần mềm là mô tả yêu cầu
kỹ thuật. Yêu cầu kỹ thuật mô tả các chức năng hệ thống phải thực hiện, các đặc
điểm đáng chú ý về và cần thiết của hệ thống, các ràng buộc về hoạt động của
hệ thống và quy trình phát triển phần mềm.
Chú ý là có hai mức độ yêu cầu là yêu cầu ngƣời dùng (user
requirements) và yêu cầu hệ thống (system requirements). Yêu cầu ngƣời dùng
mô tả rõ ràng về những gì hệ thống nên làm. Còn yêu cầu hệ thống mở rộng yêu
cầu ngƣời dùng, mô tả chức năng hệ thống một cách chi tiết và súc tích hơn, kỹ


×