Nghiên cứu và đề xuất các phương pháp kiểm thử giao diện phần mềm

4
MỤC LỤC
LỜI CAM ĐOAN ...........................................................................................................
DANH MỤC CÁC BẢNG ..............................................................................................
DANH MỤC CÁC HÌNH VẼ .........................................................................................
CHƢƠNG I – TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM ......................................
1.1. Các khái niệm cơ bản..........................................................................................
1.1.1. Lỗi phần mềm ..............................................................................................
1.2.2. Chi phí cho việc sửa lỗi ................................................................................
1.1.3. Kiểm thử phần mềm .....................................................................................
1.2. Tiến trình kiểm thử phần mềm ...........................................................................
1.2.1. Kiểm thử đơn vị ...........................................................................................
1.2.2. Kiểm thử tích hợp.........................................................................................
1.2.3. Kiểm thử hệ thống ........................................................................................
1.2.4. Kiểm thử hồi quy..........................................................................................
1.2.5. Kiểm thử chấp nhận .....................................................................................
1.3. Các phƣơng pháp kiểm thử phần mềm ...............................................................
1.3.1. Kiểm thử hộp trắng ......................................................................................
1.3.2. Kiểm thử hộp đen – Black box testing .........................................................
1.3.3. Kiểm thử hộp xám ........................................................................................
1.4. Các kỹ thuật kiểm thử cơ bản .............................................................................
1.4.1. Kiểm thử luồng điều khiển ...........................................................................
1.4.2. Kiểm thử luồng dữ liệu ................................................................................
1.4.3. Kỹ thuật phân lớp tƣơng đƣơng ...................................................................
1.4.4. Kỹ thuật phân tích giá trị biên ......................................................................
1.4.5. Kỹ thuật đồ thị - nhân quả ............................................................................
1.5. Kiểm thử tự động ................................................................................................
1.5.1. Kiến trúc kiểm thử tự động ..........................................................................
1.5.2. Ƣu và nhƣợc điểm của kiểm thử tự động .....................................................
1.5.2. Lựa chọn công cụ kiểm thử tự động ............................................................

5
CHƢƠNG II – GIAO DIỆN VÀ CÁC VẤN ĐỀ CẦN QUAN TÂM .........................

2.1.Khái niệm giao diện ngƣời dùng .............................

2.2.Tại sao cần thiết kế giao diện ...................................

2.3.Các dạng giao tiếp ngƣời dùng - máy tính ...............
2.3.1. Giao tiếp dòng lệnh ......................................................................................
2.3.2. Giao tiếp bảng chọn .....................................................................................
2.3.3. Giao tiếp bằng ngôn ngữ tự nhiên ................................................................
2.3.4. Giao tiếp dạng hỏi đáp truy vấn ...................................................................
2.3.5. Giao tiếp dạng form-fill ...............................................................................
2.3.6. Giao tiếp dạng WIMP ..................................................................................

2.4.Tính tiện lợi của hệ thống tƣơng tác .........................

2.5.Nguyên lý thiết kế hệ thống có tính tiện lợi .............
2.5.1. Sự rõ ràng .....................................................................................................
2.5.2. Sự phản hồi ...................................................................................................
2.5.3. Tính ràng buộc .............................................................................................
2.5.4. Tính ánh xạ ...................................................................................................
2.5.5. Tính nhất quán ..............................................................................................
2.5.6. Tính gợi ý .....................................................................................................

2.6.Các lỗi giao diện ngƣời dùng ....................................
2.6.1. Lỗi chức năng ...............................................................................................
2.6.2. Lỗi giao tiếp truyền thông ............................................................................
2.6.3. Lỗi cấu trúc lệnh ...........................................................................................

2.6.4. Thiếu lệnh .....................................................................................................
2.6.5. Lỗi thi hành ..................................................................................................
2.6.6. Đầu ra ...........................................................................................................
CHƢƠNG 3 – KIỂM THỬ GIAO DIỆN PHẦN MỀM ...............................................

3.1.Khái niệm kiểm thử giao diện phần mềm ................

3.2.Kiểm thử nhƣ thế nào ..............................................
3.2.1. Nguyên tắc chung khi kiểm thử giao diện phần mềm ..................................
3.3.2. Chiến lƣợc kiểm thử giao diện .....................................................................


6

3.3.Danh mục kiểm thử giao diện ..................................
3.3.1. Kiểm thử sự tuân thủ chuẩn Windows .........................................................
3.3.2. Danh mục kiểm tra sự hợp thức hóa màn hình ............................................
3.3.3. Các hoạt động chuẩn ....................................................................................

3.4.Kiểm thử giao diện tự động ......................................
3.4.1. Tạo kế hoạch kiểm thử giao diện cho công cụ kiểm thử giao diện tự động 63
3.4.2. Sử dụng công cụ kiểm thử giao diện tự động ..............................................
3.4.3. Mƣời điều cần nhớ khi kiểm thử giao diện tự động .....................................
3.4.4. Các thủ thuật khi kiểm thử giao diện tự động ..............................................
3.4.5. Một số vấn đề thƣờng gặp với kiểm thử tự động .........................................

3.5.Đánh giá mức độ hài lòng ngƣời dùng ....................
CHƢƠNG 4 – KIỂM THỬ GIAO DIỆN THEO PHÂN LOẠI PHẦN MỀM.............

4.1.Phân loại phần mềm..................................................

4.2.Kiểm thử giao diện phần mềm nghiệp vụ ................

4.3.Kiểm thử giao diện đối với phần mềm nhúng ..........
4.3.1. Hệ thống nhúng và các đặc điểm cơ bản ......................................................
4.3.2. Kiểm thử giao diện hệ thống nhúng .............................................................
4.4.Kiểm thử giao diện đối với các ứng dụng Windows

4.5.Kiểm thử giao diện với các ứng dụng Web .............
4.5.1. Ứng dụng Web (Web Application) ..............................................................
4.5.2. Kiểm thử ứng dụng Web ..............................................................................
4.5.3. Các công cụ kiểm thử giao diện tự động ......................................................
CHƢƠNG 5 – ÁP DỤNG CÁC KỸ THUẬT KIỂM THỬ TRONG KIỂM THỬ
GIAO DIỆN ỨNG DỤNG “PHẦN MỀM QUẢN LÝ BÁN HÀNG” .........................
5.1.Giới thiệu ứng dụng “Phần mềm quản lý bán hàng”
5.1.1. Thành phần và chức năng ............................................................................
5.1.2. Mô-đun tiến hành kiểm thử giao diện ..........................................................

5.2.Lựa chọn phƣơng pháp và kỹ thuật kiểm thử ...........
5.2.1. Kiểm thử giao diện màn hình chính .............................................................


7
5.2.2. Kiểm thử giao diện màn hình “Phiếu nhập hàng”
5.3. Tiến hành kiểm thử giao diện ứng dụng .............................................................
KẾT LUẬN .................................................................................................................
TÀI LIỆU THAM KHẢO ...........................................................................................


8

DANH MỤC CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT
Thứ tự
1
2
3

4

5
6
7

8


9
DANH MỤC CÁC BẢNG
Bảng 3.1 - Các mức kiểm thử và các loại kiểm thử giao diện phù hợp
Bảng 5.1- Danh sách các ca kiểm thử với màn hình chính
Bảng 5.2 - Danh sách các ca kiểm thử với màn hình “Phiếu nhập hàng”
DANH MỤC CÁC HÌNH VẼ
Hình 1.1 - Chi phí sửa lỗi theo thời gian ......................................................................
Hình 1.2 – Các giai đoạn phát triển và kiểm thử trong mô hình chữ V ........................
Hình 1.3 – Kiểm thử hồi quy tại các mức kiểm thử phần mềm khác ............................
Hình 1.4 – Kiểm thử hộp trắng ......................................................................................
Hình 1.5 – Kiểm thử hộp đen ........................................................................................
Hình 1.6 – Chu trình sinh dữ liệu đầu vào kiểm thử cho kiểm thử luồng điều khiển ..
Hình 1.7 – Các ký hiệu trong CFG ................................................................................
Hình 1.8 – Các thành phần của một kiến trúc KTTĐ ....................................................
Hình 2.1 – Mô hình cấu trúc UI ...................................................................................

Hình 2.2 – Mô hình giao tiếp dòng lệnh trong window ................................................
Hình 2.3 – Mô hình giao tiếp Menu ..............................................................................
Hình 2.4 – Giao tiếp form-fill ........................................................................................
Hình 2.5 – Bảng tính .....................................................................................................
Hình 2.6 - Mô hình sự chấp nhận đƣợc của hệ thống ...................................................
Hình 2.7 – Ví dụ về tính ràng buộc ...............................................................................
Hình 2.8 – Tính gợi ý trong window ............................................................................
Hình 3.1 – Ứng dụng thỏa mãn sự đồng bộ Caption .....................................................
Bảng 3.2 – Một số phím tắt và chức năng của chúng....................................................
Bảng 4.1 - So sánh giữa các ứng dụng Desktop, Client Server và Web .......................
Hình 4.1 – Các thành phần giao diện của QTP .............................................................
Hình 4.2 – Tạo Group trong AppPerfect .......................................................................
Hình 4.3 – Hỗ trợ thành phần Validation trong AppPerfect .........................................
Hình 4.4 – Định nghĩa tham số trong AppPerfect .........................................................
Hình 4.5 – Phân tích kết quả kiểm thử với AppPerfect Test .........................................
Hình 4.6 – Lập lịch kiểm thử .........................................................................................
Hình 5.1 – Mô-đun Hệ Thống .......................................................................................
Hình 5.2 – Mô-đun Danh Mục ......................................................................................
Hình 5.3 – Mô-đun Chức Năng .....................................................................................
Hình 5.4 – Mô-đun Trợ Giúp ........................................................................................
Hình 5.5 – Cấu trúc giao diện phần mềm Quản lý bán hàng ........................................


10

MỞ ĐẦU
Trong thởi đại công nghệ số hiện nay, ta có thể bắt gặp các sản phẩm công nghệ
ở tất cả các lĩnh vực: quân sự, y khoa, văn hóa nghệ thuật, đời sống xã hội,… Sự bùng
nổ của công nghệ thông tin và sự ra đời của Internet tác động to lớn tới bộ mặt xã hội.
Nhu cầu trao đổi thông tin ngày càng tăng, việc sử dụng máy tính không đơn thuần là

ngƣời dùng thực thi chức năng chuyên biệt nào đó trong một lĩnh vực cụ thể, mà có
thể sử dụng trong tất cả các lĩnh vực, các ngành nghề, với những mục đích khác nhau:
làm việc, nghiên cứu, học tập, giải trí, trao đổi thông tin,... Và ngƣời dùng cũng không
đơn thuần là một nhóm chuyên gia với trình độ nhất định, mà họ có thể là bất kỳ ai với
bất kỳ công việc, bất cứ trình độ, ở bất kỳ lứa tuổi nào... Để có thể đáp ứng thị trƣờng
rộng lớn, cực kỳ đa dạng đó, sản phẩm công nghệ thông tin nói chung cũng nhƣ công
nghệ phần mềm nói riêng, phải đảm bảo chất lƣợng tốt đồng thời cả chức năng hệ
thống lẫn giao diện ngƣời dùng. Giao tiếp và chức năng là hai mặt tƣơng hỗ và bổ
sung cho nhau. Phần mềm có chức năng tốt đến đâu, mà giao diện tồi cũng sẽ gây khó
khăn cho ngƣời dùng, làm giảm hiệu quả chức năng hệ thống. Ngƣợc lại, với giao tiếp
đƣợc thiết kế tốt, ngƣời dùng có thể dễ dàng sử dụng phần mềm và phát huy tối đa
hiệu quả chức năng hệ thống.
Kiểm thử là một trong những giai đoạn của quá trình phát triển phần mềm.
Trƣớc khi sản phẩm đƣợc phát hành tất cả các chức năng cũng nhƣ giao diện của
phần mềm đều cần qua kiểm thử. Giao diện tuy đƣợc thiết kế tốt nhƣng cũng không
thể tránh khỏi các sai sót. Kiểm thử giao diện hiệu quả sẽ phát hiện ra đƣợc các sai sót
này, tránh các lỗi về giao diện khi phát hành sản phẩm. Kiểm thử giao diện đứng dƣới
vai trò của ngƣời sử dụng, sẽ giúp phần mềm có sự thích ứng phù hợp hơn với thị hiếu
và nhu cầu của ngƣời dùng. Chính vì lẽ đó, kiểm thử giao diện phần mềm là việc hết
sức cần thiết, cần nghiên cứu về kiểm thử giao diện để tìm ra phƣơng pháp kiểm thử
hiệu quả phù hợp với ứng dụng phần mềm.
Luận văn trình bày lý thuyết về giao diện phần mềm, lý thuyết kiểm thử phần
mềm, đi sâu vào kiểm thử giao diện phần mềm với phƣơng pháp nghiên cứu theo
hƣớng từ khái quát tới chi tiết, lần lƣợt tìm hiểu các khái niệm, các phƣơng pháp, các
công cụ kiểm thử giao diện,... Trên cơ sở đó, sẽ có đánh giá khách quan về việc lựa
chọn phƣơng pháp hay công cụ kiểm thử giao diện phù hợp đối với ứng dụng đƣợc
nghiên cứu.
Kết quả nghiên cứu có thể làm tài liệu tham khảo về kiểm thử phần mềm, đồng
thời hỗ trợ kiểm thử viên cũng nhƣ các nhà phát triển phần mềm có cơ sở để lựa chọn
phƣơng pháp hay công cụ kiểm thử giao diện phù hợp để kiểm thử ứng dụng đƣợc

xây dựng.


11
Luận văn bao gồm năm chƣơng. Chƣơng 1 trình bày các lý thuyết tổng quan về
kiểm thử phần mềm: các khái niệm cơ bản, tiến trình kiểm thử phần mềm, các phƣơng
pháp, kỹ thuật kiểm thử phần mềm. Chƣơng 2 trình bày các kiến thức về giao diện và
các vấn đề cần lƣu ý khi thiết kế và kiểm thử giao diện phần mềm. Chƣơng 3 tập
trung vào kiểm thử giao diện phần mềm, nêu các hƣớng giải quyết và các vấn đề cần
kiểm thử giao diện. Chƣơng 4 cũng nói về kiểm thử giao diện nhƣng đi sâu vào từng
loại ứng dụng phần mềm. Chƣơng 5 đƣa ra ví dụ áp dụng các kiến thức đã đƣợc nêu
trong bốn chƣơng đầu để kiểm thử giao diện phần mềm “Quản lý bán hàng”.


12
CHƢƠNG I – TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM
1.1. Các khái niệm cơ bản
1.1.1. Lỗi phần mềm



Khái niệm

Có rất nhiều định nghĩa khác nhau về lỗi phần mềm (bug), nhƣng nhìn chung,
có thể phát biểu một cách tổng quát: “Lỗi phần mềm là sự không đồng nhất giữa
chương trình với đặc tả của nó”. Cụ thể là:


Phần mềm không thực hiện đúng những gì đã nêu trong đặc tả.

 Phần mềm thực hiện những hành vi mà đặc tả đã nêu không đƣợc thực
hiện.


Phần mềm thực hiện những hành vi không đƣợc nêu trong đặc tả.

 Phần mềm không thực hiện các yêu cầu không đƣợc nêu trong đặc tả,
nhƣng nên thực hiện nó.


Phần mềm khó hiểu, khó sử dụng,...

 Các dạng lỗi phần mềm
 Sai sót (Error): Error là một trạng thái của hệ thống, là một sự nhầm lẫn
hay sự hiểu sai trong quá trình phát triển phần mềm của ngƣời phát triển. Error
có thể gây nên hỏng hóc hệ thống nếu không có các hành động khắc phục.
 Lỗi (Fault / Defect): xuất hiện trong phần mềm nhƣ là kết quả của error
gây ra.
 Hỏng hóc (Failure): Failure đƣợc coi là xảy ra khi các hành vi bên ngoài
hệ thống không thực hiện đúng nhƣ đặc tả hệ thống đã đƣợc quy định trƣớc.
Nó là kết quả của một lỗi xuất hiện làm cho hệ thống không thể hoạt động hoặc
hoạt
động nhƣng cho kết quả không nhƣ mong đợi.
1.2.2. Chi phí cho việc sửa lỗi
Vòng đời phát triển phần mềm (chu trình phát triển phần mềm) đƣợc chia làm
nhiều giai đoạn. Bao gồm:


Lập kế hoạch



Thiết kế




Mã hóa và viết tài liệu



Kiểm thử và sửa lỗi


13


Phát hành và bảo trì

Theo thống kê bảo trì là phần chi phí chính của phần mềm và kiểm thử là hoạt
động chi phí đắt thứ hai, ƣớc tính khoảng 40% (15/33) chi phí trong quá trình phát
triển ban đầu của sản phẩm phần mềm [6].
Kiểm thử cũng là phần chi phí chính của giai đoạn bảo trì do phải tiến hành
kiểm thử lại những thay đổi trong quá trình sửa lỗi và đáp ứng yêu cầu ngƣời dùng.
Kiểm thử và sửa lỗi có thể đƣợc thực hiện tại bất kỳ giai đoạn nào của vòng đời phần
mềm. Tuy nhiên chi phí cho việc tìm và sửa lỗi tăng một cách đáng kể trong quá trình
phát triển. Trong tài liệu “Software Engineering” của Boehm (1976), có trích dẫn kết
quả nghiên cứu của IBM, GTE và TRW, tổng kết rằng lỗi đƣợc phát hiện càng muộn
thì chi phí cho việc sữa lỗi càng lớn [6]. Chi phí tăng theo hàm mũ nhƣ Hình 1.1:

Hình 1.1 - Chi phí sửa lỗi theo thời gian
Nhƣ vậy, có thể thể thấy kiểm thử là một khâu rất quan trọng trong quá trình
phát triển phần mềm, kiểm thử càng sớm, càng chặt chẽ thì sẽ càng giảm đƣợc những
chi phí phát sinh không đáng có cho việc sửa lỗi.
1.1.3. Kiểm thử phần mềm
Kiểm thử phần mềm là quá trình thực thi hệ thống phần mềm để xác định xem
phần mềm có thực hiện đúng với đặc tả hay không và thực hiện trong môi trƣờng
mong đợi hay không.

 Xác minh: Chỉ ra sản phẩm có đáp ứng đƣợc các đặc tả yêu cầu hay
không. Đƣợc thực hiện mỗi khi kết thúc một pha trong quy trình sản xuất, nó
giúp quyết định xem sản phẩm có đáp ứng các yêu cầu tại thời điểm kiểm tra,
trƣớc khi bắt đầu pha kế tiếp.

 Thẩm định: Chỉ ra sản phẩm có đáp ứng đƣợc yêu cầu ngƣời sử dụng hay
không. Thực hiện khi kết thúc quá trình sản xuất, nhằm đảm bảo sản phẩm đã
đƣợc sản xuất là đúng nhƣ mong đợi.


14
1.2. Tiến trình kiểm thử phần mềm
Kiểm thử đƣợc thực thi ở các mức khác nhau bao gồm cả hệ thống hoàn chỉnh
hay các phần của hệ thống trong suốt chu trình phát triển phần mềm. Một hệ thống
phần mềm phải trải qua bốn giai đoạn kiểm thử trƣớc khi nó đƣợc triển khai. Bốn giai
đoạn đó đƣợc biết nhƣ là bốn mức kiểm thử: unit, integration, system và acceptance.
Các giai đoạn kiểm thử tƣơng ứng với các giai đoạn khác nhau trong tiến trình phát
triển phần mềm và đƣợc khái quát hóa qua mô hình chữ V – Hình 1.2 [7].

Hình 1.2 – Các giai đoạn phát triển và kiểm thử trong mô hình chữ V
Trong đó:



Các yêu cầu: đƣa ra các yêu cầu về sản phẩm



Đặc tả chức năng: xây dựng phần mềm để đáp ứng với đề nghị.



Thiết kế mức cao: kiến trúc hệ thống ở mức tổng thể.

 Thiết kế mức thấp (mức chi tiết): chi tiết các đặc tả của các mô-đun trong
kiến trúc.


Lập trình: mã hóa các mô-đun.

1.2.1. Kiểm thử đơn vị
Kiểm t hử đơn vị là mức thấp nhất của kiểm thử trong mô hình chữ V. Giai đoạn
này đƣợc thực hiện bởi các lập trình viên. Họ chia nhỏ và kiểm thử từng đơn vị
chƣơng trình, nhƣ các thủ tục, các hàm, các phƣơng thức, hay các lớp. Mục đích của


15
kiểm thử đơn vị là bảo đảm thông tin đƣợc xử lý và xuất là chính xác, trong mối
tƣơng quan với dữ liệu nhập và chức năng của đơn vị đó. Điều này thƣờng đòi hỏi tất
cả các nhánh bên trong đơn vị, từng mô-đun đều phải đƣợc kiểm tra để phát hiện
nhánh phát sinh lỗi. Một nhánh thƣờng là một chuỗi các lệnh đƣợc thực thi trong một
đơn vị. Thực tiễn đã chỉ ra rằng, việc phát hiện sớm các lỗi ở mức kiểm thử đơn vị sẽ

giảm đƣợc rất nhiều chi phí cho kiểm thử ở các mức sau đó.
1.2.2. Kiểm thử tích hợp
Sau khi kết thúc quá trình kiểm thử đơn vị, các mô-đun đƣợc tích hợp lại tạo
thành hệ thống con có cấu trúc lớn hơn, đồng thời cần tiến hành kiểm thử tích hợp.
Kiểm thử tích hợp đƣợc thực thi với sự kết hợp của cả lập trình viên và các kỹ sƣ
kiểm thử tích hợp. Kết quả khi kết thúc giai đoạn kiểm thử tích hợp là dựng nên một
hệ thống ổn định, hợp lý, có thể chịu đƣợc những rung động ở mức kiểm thử hệ thống.
Mục tiêu chính của kiểm thử tích hợp đó là:


Phát hiện lỗi tƣơng tác giữa các đơn vị

 Tích hợp các đơn vị thành hệ thống con và hệ thống hoàn chỉnh để chuẩn bị
cho kiểm thử ở mức hệ thống.
Các kỹ thuật kiểm thử áp dụng ở mức kiểm thử tích hợp:


Kiểm thử cấu trúc: kiểm thử cấu trúc mã nguồn hệ thống.

 Kiểm thử chức năng: kiểm thử sự đáp ứng tốt các chức năng đặc tả của hệ
thống.


Kiểm thử hiệu năng: Kiểm thử việc vận hành của hệ thống.

 Kiểm thử khả năng chịu tải: Kiểm thử hoạt động của hệ thống dƣới áp lực
về tải hay điều kiện môi trƣờng.
Để tích hợp các mô-đun của hệ thống, tùy từng hệ thống mà kiểm thử viên lựa
chọn chiến lƣợc tích hợp phù hợp. Có ba kiểu chiến lƣợc phổ biến nhất, đó là: Tích
hợp từ trên xuống (Top – Down), tích hợp từ dƣới lên (Bottom – Up), và chiến lƣợc

BigBang.
1.2.3. Kiểm thử hệ thống
Kiểm thử hệ thống là một giai đoạn quyết định trong tiến trình phát triển phần
mềm, bởi vì cần thiết phải lên lịch chặt chẽ ngày phát hành, cần phát hiện hầu hết các
lỗi, và kiểm tra việc gỡ lỗi đang thực hiện, đảm bảo không phát sinh lỗi mới. Kiểm thử
hệ thống bao gồm các hoạt động khác nhau: lập kế hoạch kiểm thử, thiết kế bộ kiểm


16
thử, chuẩn bị môi trƣờng kiểm thử, thực thi kiểm thử theo một chiến lƣợc rõ ràng, và
kiểm tra quá trình thực thi kiểm thử.
Sau khi hoàn thành kiểm thử tích hợp, một hệ thống phần mềm đã đƣợc hình
thành cùng với các thành phần đã đƣợc kiểm tra đầy đủ. Tại thời điểm này, lập trình
viên hoặc kiểm thử viên bắt đầu kiểm thử phần mềm nhƣ một hệ thống hoàn chỉnh.
Việc lập kế hoạch cho kiểm thử hệ thống nên bắt đầu từ giai đoạn hình thành và phân
tích các yêu cầu.
Kiểm thử hệ thống kiểm tra cả các hành vi chức năng của phần mềm lẫn các
yêu cầu về chất lƣợng nhƣ độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật.
Mức kiểm thử này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với phần mềm
hoặc phần cứng bên ngoài, chẳng hạn các lỗi "tắc nghẽn" (deadlock) hoặc chiếm dụng
bộ nhớ. Sau giai đoạn này, phần mềm thƣờng đã sẵn sàng cho khách hàng hay ngƣời
dùng cuối cùng kiểm thử chấp nhận sản phẩm (Acceptance Test) hoặc dùng thử
(Alpha/Beta Test).
Các kỹ thuật kiểm thử áp dụng cho kiểm thử hệ thống:
 Kiểm thử chức năng: Bảo đảm các hành vi của hệ thống thỏa mãn đúng
yêu cầu thiết kế.
 Kiểm thử hiệu năng: Bảo đảm tối ƣu việc phân bổ tài nguyên hệ thống (ví
dụ bộ nhớ) nhằm đạt các chỉ tiêu nhƣ thời gian xử lý hay đáp ứng các truy vấn.
 Kiểm thử khả năng chịu tải: Bảo đảm hệ thống vận hành đúng dƣới áp
lực cao (ví dụ nhiều ngƣời truy xuất cùng lúc). Kiểm thử tập trung vào các

trạng thái tới hạn, các "điểm chết", các tình huống bất thƣờng nhƣ đang giao
dịch thì ngắt kết nối (xuất hiện nhiều trong kiểm tra thiết bị nhƣ POS, ATM...).
 Kiểm thử cấu hình: Quá trình kiểm thử hệ thống với mỗi cấu hình của
phần mềm và phần cứng đƣợc hỗ trợ.
 Kiểm thử bảo mật: Bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ
thống.
 Kiểm thử khả năng phục hồi: Bảo đảm hệ thống có khả năng khôi phục
trạng thái ổn định trƣớc đó trong tình huống mất tài nguyên hoặc dữ liệu; nó
đặc biệt quan trọng đối với các hệ thống giao dịch nhƣ ngân hàng trực tuyến...
1.2.4. Kiểm thử hồi quy
Kiểm thử hồi quy là một mức khác của kiểm thử mà đƣợc thực hiện trong suốt
quá trình phát triển hệ thống. Mỗi khi một thành phần nào đó của hệ thống có sự thay
đổi, cần tiến hành kiểm thử hồi quy. Mục đích chính trong kiểm thử hồi quy đó là đảm


17
bảo không phát sinh lỗi mới trong các thành phần không có sự thay đổi. Rõ ràng kiểm
thử hồi quy không phải một mức kiểm thử riêng biệt trong tiến trình kiểm thử. Mối
quan hệ giữa nó với các mức kiểm thử khác trong mô hình chữ V đƣợc thể hiện qua
Hình 1.3 [7].

Hình 1.3 – Kiểm thử hồi quy tại các mức kiểm thử phần mềm khác
1.2.5. Kiểm thử chấp nhận
Sau khí quá trình kiểm thử hệ thống kết thúc, phần mềm đƣợc phân phát tới
khách hàng. Khách hang sẽ tiến hành một loạt các kiểm thử của họ, thƣờng đƣợc biết
đến là kiểm thử chấp nhận. Yếu tố quan trọng nhất trong kiểm thử chấp nhận chính là
mức độ hài lòng của ngƣời dùng với hệ thống.
1.3. Các phƣơng pháp kiểm thử phần mềm
1.3.1. Kiểm thử hộp trắng
Kiểm thử hộp trắng, còn biết tới nhƣ kiểm thử cấu trúc hay kiểm thử hƣớng

logic, cho phép kiểm tra tất cả cấu trúc bên trong của phần mềm với mục đích đảm bảo
tất cả các câu lệnh và các điều kiện sẽ đƣợc thực hiện ít nhất một lần. Kiểm thử viên
truy nhập vào mã nguồn chƣơng trình và lấy đó làm cơ sở kiểm thử, họ hoàn toàn nắm
đƣợc cấu trúc lệnh bên trong của hệ thống (Hình 1.4). Trong kiểm thử hộp trắng, tập
trung vào kiểm thử luồng điều khiển và kiểm thử luồng dữ liệu.

Hình 1.4 – Kiểm thử hộp trắng
Các kỹ thuật kiểm thử:


Kiểm thử luồng điều khiển


18



o

Kiểm thử bao phủ dòng lệnh

o

Kiểm thử bao phủ nhánh

o

Kiểm thử bao phủ quyết định

o

Kiểm thử đƣờng cơ sở

o

Kiểm thử điều kiện

o

Kiểm thử lặp

Kiểm thử luồng dữ liệu

Kiểm thử luồng dữ liệu là phƣơng pháp lựa chọn đƣờng dẫn kiểm thử của
chƣơng trình dựa vào vị trí khai báo và sử dụng các biến trong chƣơng trình.
Ƣu, nhƣợc điểm:
Kiểm thử hộp trắng chỉ dựa trên mã nguồn chƣơng trình để kiểm thử, do đó tiết
kiệm đƣợc thời gian và chi phí cài đặt phần mềm. Đây là phƣơng pháp kiểm thử đơn
giản nhất, và cũng sớm phát hiện ra lỗi của chƣơng trình ngay trong cấu trúc dòng
lệnh. Nó giúp hạn chế các lỗi tiềm ẩn sẽ phát sinh khi cài đặt và sử dụng chƣơng trình.
Nhƣợc điểm chính của kiểm thử hộp trắng là không thể phát hiện hết các lỗi
phát sinh khi chạy chƣơng trình. Kiểm thử hộp trắng thiếu tính khách quan, kiểm thử
viên cũng là ngƣời lập trình mà không đứng trên vai trò ngƣời sử dụng.
1.3.2. Kiểm thử hộp đen – Black box testing
Kiểm thử hộp đen còn đƣợc biết tới với các tên gọi khác nhƣ kiểm thử chức năng
(function testing), kiểm thử hƣớng dữ liệu (data driven) hay kiểm thử hƣớng vào ra
(input/output driven). Trong kỹ thuật này, kiểm thử viên coi phần mềm nhƣ một hộp đen,
hoàn toàn không quan tâm tới cấu trúc và hành vi bên trong hệ thống – Hình 1.5. Với bộ
dữ liệu đầu vào, họ chỉ quan tâm đầu ra sẽ là gì, có đúng nhƣ đặc tả hay không. Kiểm thử
hộp đen tập trung vào các yêu cầu chức năng của hệ thống. Kiểm thử hộp đen không thay

thế kiểm thử hộp trắng, nó kết hợp với kỹ thuật kiểm thử hộp trắng, bổ sung các khả năng
phát hiện các lớp lỗi khác với các phƣơng pháp kiểm thử khác.


19
Hình 1.5 – Kiểm thử hộp đen
Kiểm thử hộp đen cố gắng phát hiện các loại lỗi sau:


Các chức năng thiếu hoặc không đúng với đặc tả.



Các lỗi truy cập cơ sở dữ liệu bên ngoài.



Các lỗi giao diện.



Các lỗi thi hành.



Các lỗi khi khởi tạo hoặc kết thúc.



…

Các kỹ thuật kiểm thử hộp đen


Phân lớp tƣơng đƣơng



Phân tích giá trị biên



Kiểm thử mọi cặp



Lập bảng quyết định



Dự đoán lỗi



Kiểm thử fuzz



Kiểm thử dựa trên mô hình



Ma trận dấu vết



Kiểm thử thăm dò



Kiểm thử dựa trên đặc tả

Ƣu, nhƣợc điểm:
Kiểm thử hộp đen hoàn toàn không quan tâm và không liên quan tới mã lệnh. Với
quan điểm chƣơng trình luôn luôn có lỗi và đƣa ra yêu cầu chƣơng trình phải đáp ứng
đƣợc, kiểm thử viên hộp đen tìm ra những lỗi mà các lập trình viên không nhận ra.

Mặt khác kiểm thử viên không biết các phần mềm thực sự đƣợc xây dựng nhƣ
thế nào, do đó có thể kiểm thử viên hộp đen viết rất nhiều ca kiểm thử để kiểm tra một
thứ gì đó mà đáng lẽ có thể chỉ cần kiểm tra bằng một ca kiểm thử duy nhất, trong khi
đó một số phần của chƣơng trình lại bị bỏ sót không đƣợc kiểm thử.


20
Do vậy, kiểm thử hộp đen có ƣu điểm của “một sự đánh giá khách quan”, mặt
khác nó lại có nhƣợc điểm của “thăm dò mù”.
1.3.3. Kiểm thử hộp xám
Kiểm thử hộp xám đòi hỏi phải có sự truy cập tới cấu trúc dữ liệu và giải thuật
bên trong cho những mục đích thiết kế các ca kiểm thử, nhƣng là kiểm thử ở mức
ngƣời sử dụng hay mức hộp đen. Việc thao tác tới dữ liệu đầu vào và định dạng dữ

liệu đầu ra là không rõ ràng, giống nhƣ một chiếc “hộp xám”, bởi vì đầu vào và đầu ra
rõ ràng là ở bên ngoài “hộp đen” mà chúng ta vẫn gọi về hệ thống đƣợc kiểm tra. Sự
khác biệt này đặc biệt quan trọng khi quản lý kiểm thử tích hợp giữa 2 mô-đun mã
lệnh đƣợc viết bởi hai chuyên viên thiết kế khác nhau, trong đó chỉ giao diện là đƣợc
đƣa ra để kiểm thử. Kiểm thử hộp xám có thể cũng bao gồm cả thiết kế đối chiếu để
quyết định, ví dụ, giá trị biên hay thông báo lỗi.
1.4. Các kỹ thuật kiểm thử cơ bản
1.4.1. Kiểm thử luồng điều khiển
Có hai loại câu lệnh cơ bản trong một đơn vị chƣơng trình, đó là: lệnh chỉ định
(assignment statement) và lệnh điều kiện (condition statement). Lệnh chỉ định là
những lệnh đƣợc biểu diễn bằng ký tự chỉ định “ = ”. Ví dụ nhƣ: x = 2 *y, trong đó x,
y đều là biến. Lệnh điều kiện là các lệnh có chứa các lệnh điều khiển, nhƣ if(), lặp
for(), lặp while(), goto. Trƣờng hợp không có lệnh điều khiển, các lệnh chƣơng trình
đƣợc thực hiện theo trình tự mà nó xuất hiện. Sự thành công khi thi hành một lệnh
chƣơng trình bắt nguồn từ luồng điều khiển của đơn vị đó.
Đồ thị luồng điều khiển (control flow graph - CFG) là đồ thị có hƣớng, biểu
diễn một chƣơng trình, với:


Đỉnh: biểu diễn một lệnh tuần tự hay một khối lệnh.



Cung: biểu diễn các nhánh rẽ của lệnh điều kiện

 Một đỉnh vào và một đỉnh ra đƣợc thêm vào để biểu diễn điểm vào và ra
của chƣơng trình.
Lộ trình trong CFG là đƣờng đi xuất phát từ đỉnh vào, đi qua các đỉnh và cung
trong đồ thị và kết thúc ở đỉnh ra. Chu trình tạo dữ liệu đầu vào kiểm thử cho kiểm thử
luồng điều khiển đƣợc mô tả trong lƣu đồ dƣới đây – Hình 1.6.

21

Hình 1.6 – Chu trình sinh dữ liệu đầu vào kiểm thử cho kiểm thử luồng điều khiển
 Lựa chọn đƣờng đi: đƣờng đi đƣợc lựa chọn từ CFG phải thỏa mãn tiêu
chuẩn lựa chọn đƣờng và dựa trên cấu trúc của CFG.
 Sinh dữ liệu đầu vào kiểm thử: Có hai loại đƣờng đi trong kiểm thử luồng
điều khiển:



o

Đƣờng đi đƣợc (feasible path)

o

Đƣờng không đi đƣợc (infeasible path)

Các ký hiệu trong CFG – Hình 1.7

Hình 1.7 – Các ký hiệu trong CFG
Tiêu chuẩn lựa chọn đƣờng đi (Path selection criteria)


22

Phủ tất cả các đƣờng: tất cả các đƣờng đi (bao gồm cả các đƣờng đi
đƣợc và không đi đƣợc) đều đƣợc lựa chọn.


Phủ lệnh: Lựa chọn các đƣờng đi sao cho tất cả các lệnh đƣợc chạy
ít nhất một lần.

Phủ nhánh: Lựa chọn các đƣờng đi sao cho tất cả các nhánh của
CFG đƣợc chạy ít nhất một lần.

Phủ mệnh đề: Tổng hợp tất cả các khả năng đánh giá True/Fail của
tất cả các đối tƣợng (biểu thức).
Mỗi tiêu chuẩn chọn đƣờng đều có ƣu và nhƣợc điểm riêng của nó. Tùy từng
trƣờng hợp mà lựa chọn tiêu chuẩn chọn đƣờng cho phù hợp với cấu trúc của CFG.
1.4.2. Kiểm thử luồng dữ liệu
Ít nhất một nửa mã nguồn chƣơng trình bao gồm các lệnh khai báo dữ liệu, nhƣ
là: định nghĩa cấu trúc dữ liệu, các đối tƣợng riêng, giá trị mặc định ban đầu và các
thuộc tính. Lỗi dữ liệu là lỗi phổ biến nhất trong các lỗi mã nguồn, do đó kiểm thử
luồng dữ liệu là kỹ thuật không thể thiếu trong kiểm thử cấu trúc.
Một đơn vị chƣơng trình chấp nhận đầu vào, thực hiện tính toán, gán giá trị mới
cho biến, và trả về kết quả. Phƣơng pháp kiểm thử luồng dữ liệu chọn lựa một số
đƣờng diễn tiến của chƣơng trình dựa vào việc cấp phát, định nghĩa, và sử dụng
những biến trong chƣơng trình.
Có hai mức kiểm thử luồng dữ liệu:
 Kiểm thử luồng dữ liệu tĩnh: kỹ thuật này tập xác định lỗi tiềm năng,
trung thƣờng đƣợc biết đến nhƣ luồng dữ liệu bất Ba loại tình huống bất
thƣờng. thƣờng khi sử dụng biến:
o

Loại 1: Đã đƣợc khai báo nhƣng sau đó lại đƣợc khai báo lại

o

Loại 2: Không đƣợc khai báo nhƣng lại đƣợc tham chiếu tới

o

Loại 3: Đƣợc khai báo nhƣng không đƣợc tham chiếu

 Kiểm thử luồng dữ liệu động: liên quan tới việc thực thi chƣơng trình thực
tế.
Kỹ thuật này tƣơng tự nhƣ kiểm thử luồng điều khiển: Cần xác định đƣờng đi
để thi hành, và đƣờng đi đƣợc lựa chọn dựa trên tiêu chuẩn kiểm thử luồng dữ
liệu. Các bƣớc cơ bản:
o

Vẽ đồ thị luồng dữ liệu (Data flow graph - DFG)

o

Chọn một hay nhiều tiêu chuẩn kiểm thử luồng dữ liệu


23
o

Xác định đƣờng đi trong DFG đáp ứng tiêu chuẩn đã chọn

o

Rút ra các biểu thức vị từ từ các path đƣợc lựa chọn

o

Giải các biểu thức vị từ thu đƣợc đầu vào kiểm thử

1.4.3. Kỹ thuật phân lớp tương đương
Việc kiểm thử tất cả các đầu vào của chƣơng trình là không thể. Vì thế, khi
kiểm thử chƣơng trình nên giới hạn một tập con tất cả các trƣờng hợp đầu vào có thể
có. Một tập con nhƣ vậy cần có hai tính chất:
 Mỗi trƣờng hợp kiểm thử nên gồm nhiều điều kiện đầu vào khác nhau có
thể để giảm thiểu tổng số các trƣờng hợp cần thiết.
 Nên cố gắng phân hoạch các miền đầu vào của một chƣơng trình thành một
số xác định các lớp tƣơng đƣơng, sao cho có thể giả định hợp lý rằng việc kiểm
thử một giá trị đại diện của mỗi lớp là tƣơng đƣơng với việc kiểm thử một giá
trị bất kỳ trong cùng lớp.
Hai vấn đề xem xét ở trên tạo thành một phƣơng pháp của kỹ thuật hộp đen và
gọi là phân hoạch tƣơng đƣơng.
Các bƣớc thực hiện trong kỹ thuật phân lớp tƣơng đƣơng – gồm ba bƣớc:
 Đối với mỗi dữ liệu vào, xác định các lớp tƣơng đƣơng từ miền dữ liệu
vào.


Chọn dữ liệu đại diện cho mỗi lớp tƣơng đƣơng



Kết hợp các dữ liệu thử bởi tích Đề-các để tạo ra bộ dữ liệu kiểm thử

Nguyên tắc phân hoạch lớp tƣơng đƣơng:


Nếu dữ liệu vào thuộc một

khoảng, xây dựng: o Một lớp các giá trị
lớn hơn
o Một lớp các giá trị nhỏ hơn
o “n” lớp các giá trị hợp lệ



Nếu dữ liệu là tập hợp các giá

trị, xây dựng: o Một lớp với tập rỗng


o Một lớp quá nhiều các giá trị
o “n” lớp hợp lệ


24


Nếu dữ liệu là điều kiện ràng buộc, xây dựng:
o

Một lớp với điều kiện ràng buộc đƣợc thỏa mãn

o

Một lớp với ràng buộc không đƣợc thỏa mãn

1.4.4. Kỹ thuật phân tích giá trị biên

Lỗi phần mềm thƣờng xuất hiện gần các giá trị biên của miền dữ liệu đầu vào,
do đó tập trung phân tích các giá trị biên của miền dữ liệu để xây dựng dữ liệu kiểm
thử.
Nguyên tắc kiểm thử dữ liệu vào gồm:


Giá trị nhỏ nhất



Giá trị gần kề lớn hơn giá trị nhỏ nhất



Giá trị bình thƣờng



Giá trị gần kề nhỏ hơn giá trị lớn nhất



Giá trị lớn nhất

Nguyên tắc chọn dữ liệu kiểm thử:


Nếu dữ liệu vào thuộc một

khoảng, chọn: o Hai giá trị biên

o


Bốn giá trị test = giá trị biên ± sai số nhỏ nhất

Nếu dữ liệu vào thuộc danh sách các giá trị, chọn:
o Bốn giá trị test gồm: phần tử đầu tiên, phần tử thứ hai, phần tử kề
cuối và phần tử cuối



Nếu dữ liệu vào là điều kiện ràng buộc số giá trị, chọn:
o Số giá trị tối thiểu, số giá trị tối đa và một số các giá trị không hợp
lệ.



Tự vận dụng khả năng và thực tế để chọn các giá trị biên cần kiểm thử

1.4.5. Kỹ thuật đồ thị - nhân quả
Đồ thị nhân - quả là một phƣơng pháp thiết kế trƣờng hợp kiểm thử trên cơ sở
đƣa ra một sự mô tả xúc tích các điều kiện logic và các hành vi kèm theo. Phƣơng
pháp này sử dụng mô hình các quan hệ logic giữa nguyên nhân và kết quả cho thành
phần phần mềm. Mỗi nguyên nhân đƣợc biểu diễn nhƣ một điều kiện (đúng hoặc sai)


25
của một đầu vào, hoặc kết hợp các đầu vào. Mỗi kết quả đƣợc biểu diễn nhƣ là một
biểu thức Bool biểu diễn một kết quả tƣơng ứng cho những thành phần vừa thực hiện.
Đồ thị nhân - quả đƣợc tạo nhƣ sau:

 Tất cả các nguyên nhân (các đầu vào) và các kết quả (các đầu ra) đƣợc liệt
kê dựa trên đặc tả và đƣợc định danh cho mỗi nhân – quả.
 Các quan hệ giữa các nguyên nhân (đầu vào) và các kết quả (đầu ra) đƣợc
biểu diễn trong đồ thị để làm rõ ràng các quan hệ logic.
 Từ đồ thị tạo ra bảng quyết định biểu diễn các quan hệ giữa nguyên nhân
và kết quả. Dữ liệu kiểm thử đƣợc sinh ra dựa trên các qui tắc trong các bảng
này.
1.5. Kiểm thử tự động
Kiểm thử tự động (KTTĐ) là quá trình mà các bƣớc kiểm thử lặp đi lặp lại
đƣợc thực hiện bởi các công cụ kiểm thử phần mềm nhƣ Winrunner, Load runner,
QTP,…, sử dụng đầu vào của các test case và dự đoán kết quả đầu ra dƣới môi trƣờng
đƣợc kiểm soát. KTTĐ thƣờng đƣợc áp dụng trong kiểm thử hồi quy. Kiểm thử hồi
quy đƣợc tiến hành lặp lại mỗi khi hệ thống có các sự thay đổi lớn, nó tìm ra các lỗi
phát sinh khi hệ thống có những sự thay đổi hay trong quá trình khắc phục các lỗi khác
của hệ thống.
Tự động hóa kiểm thử có thể thay thế kiểm thử thủ công hay không?
Kiểm thử thủ công là quá trình mà chức năng của ứng dụng đƣợc kiểm thử dƣới
các môi trƣờng khác nhau và các điều kiện cho nó đƣợc chỉ định chức năng, giao diện,
tính dễ sử dụng, hiệu năng, khả năng bảo mật,… bởi kiểm thử viên, với các đầu vào đƣợc
yêu cầu từ nhóm phát triển ứng dụng và các tài liệu ứng dụng có tính chất khác nhau.
Kiểm thử thủ công vừa có ƣu điểm vừa có nhƣợc điểm. Kiểm thử đặc biệt (Ad hoc
testing) có thể thực hiện bằng kiểm thử thủ công, nó hầu nhƣ luôn cần thiết nhƣ chức
năng của ứng dụng và đƣợc hiểu rõ hơn bởi một kiểm thử viên. Thực tế cho thấy, ad hoc
testing phát hiện ra nhiều lỗi hơn KTTĐ. Nhƣợc điểm của kiểm thử thủ công là phải chạy
lại nhiều lần một kiểm thử khi xây dựng phức tạp gây mệt mỏi đối với mọi nỗ lực của
kiểm thử viên, và rất dễ xảy ra các lỗi slipping không đƣợc chú ý.

Một trong những ƣu điểm khi so sánh kiểm thử tự động với kiểm thử thủ công
đó là các công cụ kiểm thử sẽ không cảm thấy mệt mỏi trong quá trình kiểm thử lặp đi
lặp lại nhƣ con ngƣời. Tuy nhiên KTTĐ là một quy trình tốn kém hơn khi so sánh với

kiểm thử thủ công. KTTĐ yêu cầu hiểu biết về công việc với các công cụ kiểm thử.
Xây dựng các ca kiểm thử và kiểm thử các framework tốn nhiều thời gian hơn kiểm
thử thủ công. Trƣờng hợp ứng dụng lớn, đƣợc phát triển trên nhiều nền tảng hay đa


26
ngôn ngữ ngƣời dùng và cần lặp lại nhiều lần quá trình kiểm thử thì sẽ hiệu quả hơn
nếu áp dụng KTTĐ.
KTTĐ không hoàn toàn thay thế kiểm thử thủ công, mục đích của KTTĐ là
giảm các hoạt động kiểm thử thủ công và các hoạt động kiểm thử dƣ thừa bằng cách
sử dụng một giải pháp có hệ thống để đạt đƣợc một phạm vi và độ bao phủ các trƣờng
hợp kiểm thử tốt hơn, giảm chi phí và thời gian kiểm thử trong suốt vòng đời phần
mềm. Qua đó nâng cao chất lƣợng, tăng độ tin cậy, tăng hiệu quả của quá trình kiểm
thử, giải phóng các kỹ sƣ kiểm thử phần mềm khỏi việc thực hiện các công việc lặp lại
nhàm chán.
1.5.1. Kiến trúc kiểm thử tự động
Kiến trúc tự động hóa kiểm thử, hay một framework, bao gồm các công cụ
kiểm thử, thiết bị, các kịch bản kiểm thử, tiền điều kiện, và ngƣời điều khiển để hệ
thống tự động kiểm thử có tác dụng và hiệu quả. Tạo và duy trì một framework KTTĐ
là chìa khóa cho thành công của các dự án KTTĐ trong mỗi tổ chức. Sự thi hành một
framework tự động thông thƣờng bao gồm các nhóm KTTĐ: nhóm kiểm thử phát triển
(Development Test Group), nhóm kiểm thử hiệu năng (Performance Test Group), nhóm
kiểm thử khả năng mở rộng (Scalability Test Group), nhóm kiểm thử tự động
(Automation Test Group), nhóm kiểm thử khả năng chống đỡ (Sustaining Test Group).
Mỗi framework KTTĐ bao gồm 6 thành phần nhƣ trong Hình 1.8 dƣới đây:

Hình 1.8 – Các thành phần của một kiến trúc KTTĐ
Hệ thống đƣợc kiểm thử (System to be tested): Đây là thành phần đầu tiên của
một kiến trúc tự động. Các hệ thống con của hệ thống đƣợc kiểm thử phải vững chắc
ổn định. Nếu không, tự động hóa kiểm thử sẽ không có hiệu quả. Tất cả các hệ thống