Mô hình hóa và kiểm thử máy rút tiền ATM bằng kỹ thuật sinh ca kiểm thử từ máy trạng thái hữu hạn (FSM FINITE state machines testing)
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.46 MB, 88 trang )
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ
NGUYỄN THỊ MINH THÚY
MÔ HÌNH HÓA VÀ KIỂM THỬ MÁY RÚT TIỀN ATM BẰNG KỸ THUẬT
SINH CA KIỂM THỬ TỪ MÁY TRẠNG THÁI HỮU HẠN
(FSM – FINITE STATE MACHINES TESTING)
LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN
HÀ NỘI, 2015
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ
NGUYỄN THỊ MINH THÚY
MÔ HÌNH HÓA VÀ KIỂM THỬ MÁY RÚT TIỀN ATM BẰNG KỸ THUẬT
SINH CA KIỂM THỬ TỪ MÁY TRẠNG THÁI HỮU HẠN
(FSM – FINITE STATE MACHINES TESTING)
Nghành
: Công nghệ thông tin
Chuyên nghành : Kỹ thuật phần mềm
Mã số
: 60 48 01 03
LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN
NGƢỜI HƢỚNG DẪN KHOA HỌC: TS. ĐẶNG VĂN HƢNG
HÀ NỘI, 2015
LỜI CẢM ƠN
Đầu tiên tôi xin được bày tỏ sự trân trọng và lòng biết ơn sâu sắc và gửi lời
cảm ơn đặc biệt nhất tới TS. Đặng Văn Hưng, giảng viên Bộ môn Công nghệ phần
mềm – Khoa Công nghệ thông tin – Trường Đại học Công nghệ - ĐHQGHN. Trong
thời gian học và nhận đề tài, thầy đã định hướng đề tài, cung cấp cho tôi những kiến
thức, những tài liệu, để thực hiện đề tài luận văn cao học này, từ những ý tưởng trong
đề cương nghiên cứu, phương pháp nghiên cứu, phương pháp giải quyết vấn đề trong
luận văn cao học. Thầy đã dành nhiều thời gian quý giá và tận tình chỉ bảo, hướng
dẫn tôi trong suốt quá trình triển khai, việc nghiên cứu cho đến những lần kiểm tra
cuối cùng để hoàn thành đề tài: “Mô hình hóa và kiểm thử máy rút tiền ATM bằng kỹ
thuật sinh ca kiểm thử từ FSM”.
Tôi xin bày tỏ lòng biết ơn chân thành và sâu sắc tới Trường Đại học Công
nghệ - ĐHQGHN, phòng đào tạo sau đại học đã tạo điều kiện cho tôi được học tập và
hoàn thiện quá trình học tập được đào tạo tại nhà trường.
Tôi xin chân thành cảm ơn tới GS, TS là các Thầy, Cô giáo trong bộ môn Kỹ
thuật phần mềm, Khoa công nghệ thông tin, những người đã trực tiếp giảng dạy và
truyền đạt giúp tôi mở rộng những kiến thức khoa học về công nghệ thông tin nói
chung và Kỹ thuật phần mềm nói riêng. Các thầy đã giúp tôi hiểu thấu đáo hơn lĩnh
vực mà tôi nghiên cứu để có thể vận dụng các kiến thức đó trong thực tế và công việc
của mình. Đó là những kiến thức quý báu và rất có ích với tôi trong giai đoạn hiện tại
và trong tương lai.
Tôi xin gửi lời cảm ơn đến gia đình, bạn bè những người đã luôn động viên khuyến
khích tôi trong suốt quá trình học tập cũng như thực hiện đề tài luận văn của mình.
Tôi xin chân thành cảm ơn!
Tác giả
Nguyễn Thị Minh Thúy
1
LỜI CAM ĐOAN
Tôi xin cam đoan rằng, nội dung trình bày trong luận văn này là do tôi tự
nghiên cứu tìm hiểu dựa trên các tài liệu và tôi trình bày theo ý hiểu của bản thân dưới
sự hướng dẫn trực tiếp của Thầy TS. Đặng Văn Hưng. Các nội dung nghiên cứu, tìm
hiểu và kết quả trong đề tài này là hoàn toàn trung thực.
Luận văn này của tôi chưa từng được ai công bố trong bất cứ công trình nào.
Trong quá trình thực hiện luận văn này tôi đã tham khảo đến các tài liệu của
một số tác giả, tôi đã ghi rõ tên tài liệu, nguồn gốc tài liệu, tên tác giả và tôi đã liệt kê
trong mục “TÀI LIỆU THAM KHẢO” ở cuối luận văn.
Hà nội, tháng 11 năm 2015
Tác giả
Nguyễn Thị Minh Thúy
2
MỤC LỤC
LỜI CẢM ƠN ................................................................................................................1
LỜI CAM ĐOAN ..........................................................................................................2
MỤC LỤC ......................................................................................................................3
BẢNG CHỮ VIẾT TẮT VÀ THUẬT NGỮ ............................................................... 5
DANH MỤC HÌNH VẼ.................................................................................................6
DANH MỤC BẢNG ......................................................................................................6
MỞ ĐẦU ......................................................................................................................... 7
1.
Đặt vấn đề ...........................................................................................................7
2.
Mục tiêu và nhiệm vụ nghiên cứu ....................................................................7
3.
Đối tƣợng và phạm vi nghiên cứu ....................................................................7
4.
Phƣơng pháp nghiên cứu ..................................................................................8
5.
Ý nghĩa khoa học và thực tiễn của luận văn. ..................................................8
6.
Bố cục luận văn. .................................................................................................9
NỘI DUNG ...................................................................................................................10
Chƣơng 1. TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM .......................................10
1.1. Kiểm thử phần mềm là gì? ............................................................................10
1.2. Chất lƣợng và độ tin cậy của phần mềm. ....................................................10
1.3. Vai trò của kiểm thử phần mềm. ..................................................................11
1.4. Các thuật ngữ trong kiểm thử phần mềm. ..................................................12
1.5. Ca kiểm thử (test case) là gì? ........................................................................13
1.6. Trƣờng hợp (Use case) kiểm thử trong phần mềm là gì? .......................... 14
1.7. Các mức kiểm thử phần mềm. ......................................................................16
1.8. Kỹ thuật kiểm thử tĩnh và tiến trình kiểm thử. ..........................................23
Chƣơng 2. MÔ HÌNH MÁY TRẠNG THÁI HỮU HẠN VÀ KỸ THUẬT SINH
CA KIỂM THỬ TỪ FSM ........................................................................................... 30
2.1. Giới thiệu về mô hình hóa. ...............................................................................30
3
2.2. Mô hình định hƣớng trạng thái. ......................................................................32
2.3. Máy trạng thái hữu hạn. ..................................................................................34
2.4. Một số cách biểu diễn cho FSM.......................................................................37
2.5. Kiểm thử dựa trên mô hình. ............................................................................39
2.6. Thuận lợi và khó khăn của kiểm thử dựa trên mô hình. .............................. 43
2.7. Kiểm thử với trạng thái kiểm chứng. ............................................................. 44
2.7.1. Chuỗi vào – ra duy nhất (Unique Input - Output sequence). ...................46
2.7.2. Chuỗi phân biệt (Distinguishing sequence) ..............................................48
2.7.3. Chuỗi đặc trưng (Characterizing sequence) .............................................50
2.8. Độ bao phủ mô hình máy hữu hạn trạng thái. ..............................................51
2.8.1. Một số đặc trưng của máy hữu hạn trạng thái. ........................................51
2.8.2. Độ bao phủ của máy hữu hạn trạng thái. .................................................51
a.
Độ bao phủ trạng thái (State coverage). .................................................53
b.
Độ bao phủ chuyển trạng thái (transition coverage). ............................. 55
2.9. Kỹ thuật sinh ca kiểm thử................................................................................57
2.9.1. Sinh cây kiểm thử và tìm tập bao phủ chuyển trạng thái. ........................ 57
2.9.2. Sinh ca kiểm thử dựa trên hành vi chuyển đổi trạng thái của FSM. ......58
Chƣơng 3. KIỂM THỬ HỆ THỐNG ATM DỰA TRÊN MÔ HÌNH FSM. ..........61
3.1. Mô tả hệ thống ATM. ....................................................................................... 61
3.2. Đặc tả của ATM từ mô hình FSM. .................................................................61
3.2.1. Đặc tả yêu cầu hệ thống. ............................................................................61
3.2.2. Xây dựng mô hình FSM của ATM. ........................................................... 63
3.3. Thuận lợi và khó khăn của máy rút tiền ATM bằng kỹ thuật sinh ca kiểm
thử từ FSM. ..............................................................................................................84
KẾT LUẬN ..................................................................................................................85
TÀI LIỆU THAM KHẢO........................................................................................... 86
4
BẢNG CHỮ VIẾT TẮT VÀ THUẬT NGỮ
Tên đầy đủ
Viết tắt
ATM
Automated Teller Machine
FSM
Finite State Machines
CFG
Control Flow Graph
PV
Path Vector
IV
Initial Vector
B
State Block
VER
State Verification
RI
Reset sequence
UIO
Unique Input Output sequence
DS
Distinguishing sequence
W
Characterizing sequence
Seq
Sequence
5
DANH MỤC HÌNH VẼ
Hình 1.1. Qui trình phát triển và các mức kiểm thử trong mô hình chữ V. ..................17
Hình 2.1. Hình ảnh của hệ thống phần mềm. ................................................................ 33
Hình 2.2. Tương tác giữa hệ thống và môi trường mô hình hóa như FSM. ..................34
Hình 2.3. Mô hình chuyển trạng thái của FSM. ............................................................ 35
Hình 2.4. Mô hình nhận dạng mã PIN của ATM. ......................................................... 36
Hình 2.5. FSM của ATM biểu diễn bằng đồ thị. ........................................................... 38
Hình 2.6. Quy trình kiểm thử dựa trên mô hình. ........................................................... 40
Hình 2.7. Mô hình kiểm thử với việc kiểm chứng trạng thái. .......................................45
Hình 2.8. FSM quá trình chuyển đổi trạng thái cho ATM. ...........................................53
Hình 2.9. Một đường đi bao phủ tất cả các trạng thái của FSM ATM.......................... 54
Hình 3. 1. Mô hình hoạt động giao dịch hệ thống ATM. .............................................. 61
Hình 3. 2. Mô hình FSM chuyển đổi trạng thái của ATM. ...........................................66
Hình 3. 3. Cây kiểm thử của máy trạng thái hữu hạn ATM. .........................................83
DANH MỤC BẢNG
Bảng 1. 1. Mô tả nhập mã PIN của ATM. .....................................................................15
Bảng 2. 1. Biểu diễn FSM bằng dạng bảng. ..................................................................39
Bảng 3. 1. Bảng biểu diễn trạng thái FSM của ATM. ...................................................65
Bảng 3. 2. Bảng gán nhãn cho các trạng thái. ............................................................... 67
Bảng 3. 3. Bảng gán nhãn cho kết quả đầu vào/ đầu ra cho hệ thống ATM. ................68
Bảng 3. 4. Bảng gán nhãn cho quá trình chuyển đổi. ....................................................69
Bảng 3. 5. Thông tin chi tiết của quá trình chuyển đổi cho hệ thống ATM. .................71
Bảng 3. 6. Dãy chuyển đổi bao phủ tất cả các trạng thái trong hình 3.2 ....................... 72
Bảng 3. 7. Dãy chuyển đổi bao phủ tất cả các trạng thái chuyển đổi trong hình 3.2. ...74
Bảng 3. 8. Chuỗi vào – ra duy nhất cho mỗi trạng thái của ATM. ............................... 76
Bảng 3. 9. Các chuỗi kiểm thử cho mỗi trạng thái chuyển tiếp của ATM. ...................82
6
MỞ ĐẦU
1. Đặt vấn đề
Trong xã hội ngày nay phần mềm đóng vai trò rất quan trọng và có độ phức tạp
gia tăng. Vì thế con người ngày càng phụ thuộc chặt chẽ vào các sản phẩm phần mềm
và do vậy đòi hỏi về chất lượng của sản phẩm phần mềm ngày càng cao, tức là các
phần mềm phải được sản xuất với giá thành thấp, dễ dùng, an toàn và có độ tin cậy
cao. Do đó việc kiểm thử là một phần trọng yếu của quá trình phát triển và đảm bảo
chất lượng phần mềm.
Hiện nay việc kiểm thử phần mềm đang sử dụng một đặc tả hình thức đóng vai
trò như các mô hình ngữ nghĩa chẳng hạn như máy trạng thái hữu hạn, biểu đồ chuyển
trạng thái. Các mô hình đặc tả này được sử dụng làm mục đích để chứng minh tính
đúng đắn của hành vi đặc tả hệ thống phần mềm hay các đối tượng và cũng được dùng
để sinh các ca kiểm thử. Việc sinh ca kiểm thử từ đặc tả máy trạng thái hữu hạn (FSM
- Finite State Machines) được áp dụng trong lĩnh vực kiểm thử các hệ thống phần
mềm cho các hệ phản vệ (reactive system). Máy rút tiền ATM là một hệ phản vệ thông
dụng và đòi hỏi tính đúng đắn, độ tin cậy cao. Đặc tả trực quan nhất của máy ATM là
máy trạng thái hữu hạn, vì thế để kiểm thử máy ATM tôi sử dụng kỹ thuật sinh
ca kiểm thử từ máy trạng thái hữu hạn, trong luận văn này tôi chọn đề tài “Mô hình
hóa và kiểm thử máy rút tiền ATM bằng kỹ thuật sinh ca kiểm thử từ máy trạng
thái hữu hạn (FSM-Finite State Machines Testing)”.
2. Mục tiêu và nhiệm vụ nghiên cứu
Luận văn này đề cập các vấn đề về kiểm thử máy trạng thái hữu hạn (Finite
State Machines Testing) và ứng dụng kiểm thử máy rút tiền ATM. Sau khi mô hình
hóa máy ATM bằng một máy trạng thái hữu hạn, luận văn cũng nghiên cứu các
phương pháp sinh ca kiểm thử từ máy trạng thái (FSM) đồng thời đưa ra những nhận
xét, đánh giá khi áp dụng vào mô hình của máy ATM.
3. Đối tƣợng và phạm vi nghiên cứu
Đối tƣợng nghiên cứu:
Nghiên cứu cơ sở lý thuyết về kiểm thử mô hình máy trạng thái.
Nghiên cứu về kỹ thuật mô hình hóa phần mềm phản vệ bằng máy hữu
hạn trạng thái hữu hạn (FSM).
Phạm vi nghiên cứu:
7
Cơ sở lý thuyết về kiểm thử mô hình phần mềm cho hệ thống máy rút
tiền tự động.
Giới thiệu kỹ thuật sinh ca kiểm thử, phân tích để lựa chọn kiểm thử để
xác minh mô hình.
Nghiên cứu máy trạng thái hữu hạn FSM và đưa ra phương pháp tìm
chuỗi kiểm thử trạng thái.
Kiểm thử dựa trên mô hình FSM.
Thử nghiệm kiểm thử mô hình cho hệ thống máy rút tiền tự động ATM.
4. Phƣơng pháp nghiên cứu
Đọc tài liệu, lựa chọn nội dung phù hợp từ tài liệu tham khảo và nhiều bài báo
khoa học có liên quan mật thiết về đề tài nghiên cứu.
Phân tích, xác định trọng tâm và xây dựng cơ sở lý luận về vấn đề nghiên cứu
và trên cơ sở đó thực hiện giải quyết vấn đề thông qua việc thiết kế bộ kiểm thử
máy rút tiền ATM bằng kỹ thuật sinh ca kiểm thử từ máy trạng thái hữu hạn.
Nghiên cứu, tìm hiểu các kỹ thuật, chiến lược kiểm thử phần mềm.
Đưa ra tài liệu kế hoạch kiểm thử và đặc tả kiểm thử, xây dựng chương trình
thực thi kiểm thử.
Đánh giá và rút ra bài học kinh nghiệm thực tiễn.
5. Ý nghĩa khoa học và thực tiễn của luận văn.
Ý nghĩa khoa học: Đứng trước sự gia tăng mức độ phức tạp của phần mềm,
việc trực quan hoá, mô hình hóa và kiểm thử phần mềm ngày càng trở nên chính yếu
trong cách tiếp cận xem xét về một hệ thống. Mô hình hóa là một dạng thức trừu tượng
của một hệ thống, được hình thành để hiểu hệ thống trước khi xây dựng hoặc thay đổi
hệ thống đó. Mô hình hóa cung cấp một phương tiện để quan niệm hóa vấn đề và giúp
chúng ta có thể trao đổi các ý tưởng trong một hình thức cụ thể, không mơ hồ. Kiểm
thử phần mềm là quá trình thực thi một chương trình với mục đích tìm lỗi, còn là quá
trình khảo sát hệ thống hay phần mềm dưới những điều kiện xác định, để quan sát và
ghi lại kết quả, và đánh giá một khía cạnh nào đó của hệ thống. Mục đích chính của đề
tài là trình bày phương pháp mô hình hóa bằng FSM của ATM và sinh ca kiểm thử từ
đặc tả máy trạng thái FSM (Finite State Machines Testing) của ATM. Việc mô hình
hóa bằng FSM là làm sáng tỏ vấn đề để có thể đưa ra được các lỗi hoặc các thiếu sót
của hệ thống từ việc tiếp cận trực quan đồ họa hơn là các dạng trình bày như văn bản,
đoạn mã,…
Ý nghĩa thực tiễn: Luận văn trình bày phương pháp kiểm thử dựa trên mô hình
máy hữu hạn trạng thái và dùng khái niệm mô phỏng như là một tiêu chí để đánh giá
8
sự cài đặt đúng đắn của hệ thống so với đặc tả. Luận văn đi sâu nghiên cứu về độ bao
phủ của mô hình máy hữu hạn trạng thái, và từ đó đưa ra phương pháp sinh ca kiểm
thử để kiểm thử xem hệ thống cài đặt có mô phỏng bản đặc tả phần mềm dựa trên mô
hình máy hữu hạn trạng thái hay không. Hướng phát triển tiếp theo của luận văn là tìm
cách cải tiến phương pháp sinh ca kiểm thử sao cho số ca kiểm thử là ít nhất nhưng độ
bao phủ là lớn nhất có thể. Đồng thời, sẽ xây dựng một chương trình sinh ca kiểm thử
dựa trên phương pháp đã được cải tiến.
6. Bố cục luận văn.
A. MỞ ĐẦU
B. NỘI DUNG
Chƣơng 1: Trình bày kiến thức cơ bản về kiểm thử phần mềm.
Chƣơng 2: Nghiên cứu về mô hình máy trạng thái hữu hạn và trình bày các
phương pháp về kỹ thuật sinh ca kiểm thử từ máy trạng thái hữu hạn(FSM-Finite State
Machines). Để mô tả máy rút tiền ATM bằng kỹ thuật sinh ca kiểm thử từ máy trạng
thái hữu hạn.
Chƣơng 3: Đặc tả và xây dựng mô hình kiểm thử phần mềm máy hữu hạn trạng
thái ATM. Tìm hiểu và đề xuất quy trình kiểm thử máy rút tiền ATM sử dụng máy
trạng thái hữu hạn, sau đó áp dụng các kỹ thuật kiểm thử này vào kiểm thử mô hình
phần mềm giả lập máy rút tiền tự động ATM sử dụng trạng thái máy hữu hạn.
C. KẾT LUẬN
Đưa ra những nhận xét, đánh giá khi áp dụng vào mô hình của máy ATM và
định hướng khóa luận trong tương lai.
9
NỘI DUNG
Chƣơng 1. TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM
Kiểm thử phần mềm là quá trình thực thi một hệ thống phần mềm để xác định
xem phần mềm đó có đúng với đặc tả không và thực hiện trong môi trường như mong
đợi hay không. Kiểm thử có thể cung cấp cho doanh nghiệp một quan điểm, một cách
nhìn độc lập về phần mềm mà từ đó cho phép đánh giá và thấu hiểu được những rủi ro
trong quá trình triển khai phần mềm. Bên cạch đó các kỹ thuật kiểm thử không chỉ giới
hạn ở việc thực hiện một chương trình hoặc ứng dụng với mục đích đi tìm các lỗi phần
mềm. Để đáp ứng được mọi yêu cầu hướng dẫn khi thiết kế, phát triển phần mềm và
thực hiện công việc đúng như kỳ vọng 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. Và việc kiểm thử phần mềm là một quá trình
nỗ lực để đưa ra những đánh giá này. Mục tiêu của kiểm thử là với lý do hoặc mục
đích cho việc thiết kế và thực hiện kiểm thử. Bởi vậy ở chương này, tôi xin giới thiệu
sơ lược về tổng quan của kiểm thử phần mềm và các kỹ thuật kiểm thử phần mềm.
1.1. Kiểm thử phần mềm là gì?
Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần dưới
những điều kiện xác định, quan sát và ghi lại các kết quả, và đánh giá một khía cạnh
nào đó của hệ thống hay thành phần đó1.
Kiểm thử phần mềm là quá trình thực thi một chương trình với mục đích tìm lỗi2.
Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần
mềm trong đúng môi trường chúng dự định sẽ được triển khai nhằm cung cấp cho
người có lợi ích liên quan những thông tin về chất lượng của sản phẩm hay dịch vụ
phần mềm ấy. Mục đích của kiểm thử phần mềm là tìm ra các lỗi hay khiếm khuyết
phần mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềm trong nhiều ngành
khác nhau3.
Có thể định nghĩa một cách dễ hiểu như sau: Kiểm thử phần mềm là một tiến
trình hay một tập hợp các tiến trình được thiết kế để đảm bảo mã hóa máy tính thực
hiện theo cái mà chúng đã được thiết kế để làm, và không thực hiện bất cứ thứ gì
không mong muốn. Đây là một pha quan trọng trong quá trình phát triển hệ thống,
giúp cho người xây dựng hệ thống và khách hàng thấy được hệ thống mới đã đáp ứng
yêu cầu đặt ra hay chưa?
1.2. Chất lƣợng và độ tin cậy của phần mềm.
a. Chất lƣợng của phần mềm.
10
Chất lượng của một sản phẩm phần mềm là sự đáp ứng các yêu cầu về chức
năng, sự hoàn thiện và các chuẩn đã được đặc tả, cùng các đặc trưng mong chờ từ mọi
sản phẩm phần mềm chuyên nghiệp. Chất lượng phần mềm đặc trưng cho “độ tốt, độ
tuyệt hảo” của phần mềm và dưới đây là năm quan điểm của chất lượng phần mềm:
+ Quan điểm theo cảm tính: Là chất lượng phần mềm như có thể là cái gì đó.
+ Quan điểm người dùng về chất lượng phần mềm như: tính chính xác, tính
đúng đắn (hành vi đúng như đặc tả), tính hiệu quả (tiết kiệm thời gian và tiền bạc), độ
tin cậy, tính khả kiểm thử (kiểm thử được và dễ), dễ học, dễ sử dụng, dễ bảo trì ...
+ Quan điểm của nhà sản xuất: Là chất lượng phần mềm phải phù hợp với các
đặc tả của nó.
+ Quan điểm về sản phẩm: Chất lượng sản phẩm được xem như gắn liền với các
đặc tính vốn có của sản phẩm. Thì phương pháp xây dựng sản phẩm phải tốt.
+ Quan điểm về giá trị: Chất lượng, theo quan điểm này phụ thuộc vào khách
hàng đưa ra số tiền sẵn sàng trả giá cho phần mềm đó.
Các yếu tố về mặt nhân tố chất lượng đó là hành vi đặc trưng của hệ thống phần
mềm như tính có cấu trúc, tính đơn thể, độ tin cậy, hiệu quả và tính khả kiểm thử, ...
Còn các yếu tố về mặt chất lượng là những yếu tố chất lượng liên quan đến chất lượng
phần mềm như tính đơn thể là một thuộc tính (attributes) của chất lượng phần mềm
được chia các mã code thành những đoạn riêng lẻ. Tuy nhiên người kiểm thử hay
nhầm lẫn giữa độ tin cậy với chất lượng của phần mềm. Khi kiểm thử đạt tới mức phần
mềm chạy ổn định thì người kiểm thử thường cho rằng phần mềm đã đạt được chất
lượng cao.
b. Độ tin cậy của phần mềm.
Độ tin cậy chỉ là một yếu tố để đánh giá chất lượng phầm mềm. Độ tin cậy của
phần mềm là xác suất để phần mềm chạy không có thất bại trong một khoảng thời gian
nhất định. Nó được xem là một yếu tố quan trọng của chất lượng phần mềm. Ngoài ra,
thời gian trung bình cho việc khắc phục một sự cố cũng là một thông số quan trọng
trong việc đánh giá độ tin.
1.3. Vai trò của kiểm thử phần mềm.
Kiểm thử phần mềm đóng vai trò quan trọng trong việc đánh giá và thu được
chất lượng cao của sản phẩm phần mềm trong quá trình phát triển. Thông qua chu
trình “kiểm thử - tìm lỗi - sửa lỗi”, ta hy vọng chất lượng của sản phẩm phần mềm sẽ
được cải tiến. Mặt khác, thông qua việc tiến hành kiểm thử mức hệ thống trước khi
cho lưu hành sản phẩm, ta biết được sản phẩm của ta tốt ở mức nào. Vì thế, nhiều tác
11
giả đã mô tả việc kiểm thử phần mềm là một quy trình kiểm chứng để đánh giá và tăng
cường chất lượng của sản phẩm phần mềm. Quy trình này gồm hai công việc chính là
phân tích tĩnh và phân tích động.
Phân tích tĩnh: Việc phân tích tĩnh được tiến hành dựa trên việc khảo sát các
tài liệu được xây dựng trong quá trình phát triển sản phẩm như tài liệu đặc tả nhu cầu
người dùng, mô hình phần mềm, hồ sơ thiết kế và mã nguồn phần mềm. Các phương
pháp phân tích tĩnh truyền thống bao gồm việc khảo sát đặc tả và mã nguồn cùng các
tài liệu thiết kế. Người ta cũng có thể dùng các kỹ thuật phân tích hình thức như kiểm
chứng mô hình (model checking) và chứng minh định lý (theorem proving) để chứng
minh tính đúng đắn của thiết kế và mã nguồn. Vì vậy mà công việc này không kiểm tra
đến việc thực thi chương trình mà chỉ duyệt, lý giải về tất cả các hành vi có thể của
chương trình khi được thực thi. Tối ưu hóa các chương trình dịch là các ví dụ về phân
tích tĩnh.
Phân tích động: Phân tích động liên quan đến việc thực thi chương trình để
phát hiện những thất bại có thể có của chương trình, hoặc quan sát các tính chất về
hành vi và hiệu quả (performance). Vì gần như không thể thực thi chương trình trên tất
cả các dữ liệu đầu vào có thể, ta chỉ có thể chọn một tập con các dữ liệu đầu vào để
thực thi, gọi là các “ca kiểm thử”.
Bằng cách thực hiện phân tích tĩnh và động, người kiểm thử muốn phát hiện
nhiều lỗi nhất, để chúng có thể được sửa ở giai đoạn sớm nhất trong quá trình phát
triển phần mềm. Phân tích tĩnh và động là hai kỹ thuật bổ sung cho nhau và cần được
làm lặp đi lặp lại nhiều trong quá trình kiểm thử.
1.4. Các thuật ngữ trong kiểm thử phần mềm.
Lỗi (Error): Là các lỗi do con người gây ra.
Sai (Fault): Sai là kết quả của lỗi, hay nói khác đi, lỗi sẽ dẫn đến sai. Cũng có
thể nói sai là một biểu diễn của lỗi dưới dạng một biểu thức như: Chương
trình, văn bản, sơ đồ dòng dữ liệu, biểu đồ lớp,… Sai có thể khó bị phát hiện.
Đôi khi nhà thiết kế mắc lỗi bỏ sót trong quá trình thiết kế thì sẽ dẫn đến sai.
Thất bại (Failure): Xảy ra khi xuất hiện một lỗi được thực thi (khi thực thi
chương trình tại các nơi bị sai thì sẽ xảy ra trạng thái thất bại).
Sự cố (Incident): Là những kết quả do thất bại đem đến. Sự cố là các triệu
chứng liên kết với một thất bại và báo hiệu cho người dùng biết sự xuất hiện
của thất bại.
12
Gỡ lỗi (Debugging): Quá trình tìm, phân tích và loại bỏ những nguyên nhân
gây thất bại trong phần mềm.
Yêu cầu (Requirment): Một điều kiện cần thiết để người phát triển giải quyết
một vấn đề hoặc đạt được mục tiêu phải được đáp ứng để đáp ứng một hợp
đồng, tiêu chuẩn, đặc điểm kỹ thuật.
Đánh giá (Review): Đánh giá tình trạng sản phẩm hoặc dự án để xác định sự
khác biệt từ kết quả dự định và đề nghị cải tiến. Bao gồm đánh giá quản lý,
đánh giá thông tin, đánh giá kỹ thuật, kiểm tra inspection và walkthrough.
Trƣờng hợp kiểm thử (Test case): Trường hợp kiểm thử được liên kết tương
ứng với hoạt động của chương trình. Một trường hợp kiểm thử bao gồm một
tập các giá trị đầu vào và một danh sách các kết quả đầu ra mong muốn.
Thẩm định (Validation): Là quá trình để đảm bảo rằng sản phẩm đáp ứng
được yêu cầu của người dùng (khách hàng).
Kiểm chứng (Verification): Kiểm chứng là quá trình để đảm bảo rằng một
sản phẩm phần mềm thỏa mãn đặc tả của nó.
Máy hữu hạn trạng thái (FSMs - Finite State Machines): Là một dạng mô
hình đa trạng thái, gồm 3 thành phần chính: các trạng thái, các cung chuyển
trạng thái, các sự kiện (Event) hoặc hành động (Action).
Máy rút tiền tự động (ATM - Automated Teller Machine): Là một thiết bị
ngân hàng giao dịch tự động với khách hàng, thực hiện việc nhận dạng khách
hàng thông qua thẻ ATM ( thẻ ghi nợ, thẻ tín dụng) hay các thiết bị tương
thích, và giúp khách hàng kiểm tra tài khoản, rút tiền mặt, chuyển khoản,
thanh toán tiền hàng hóa dịch vụ4.
1.5. Ca kiểm thử (test case) là gì?
Test case là mô tả một dữ liệu đầu vào (input), hành động (action) hoặc sự kiện
(event) và một kết quả mong đợi (expected response), để xác định một chức năng của
ứng dụng phần mềm hoạt động đúng hay không. Một test case có thể có các phần đặc
thù khác nhau như mã test case, tên test case, mục tiêu test, các điều kiện test, các yêu
cầu data input, các bước thực hiện và các kết quả mong đợi. Do vậy, quá trình phát
triển test case có thể giúp tìm ra lỗi trong các yêu cầu hoặc thiết kế của ứng dụng, vì nó
đòi hỏi người kiểm thử phải tư duy hoàn toàn thông qua các hoạt động của ứng dụng.
Vì vậy, việc chuẩn bị test case sớm nhất có thể trong quy trình phát triển phần mềm là
rất hữu ích. Nói chung, test case là một tình huống kiểm tra, được thiết kế để kiểm tra
một đối tượng thỏa mãn yêu cầu đặt ra hay không và gồm 3 bước cơ bản như sau:
13
Mô tả: Đặc tả các điều kiện cần tiến hành kiểm tra.
Nhập: Đặc tả đối tượng hoặc dữ liệu cần thiết, được sử dụng làm đầu vào
để thực hiện kiểm tra.
Kết quả mong đợi: Là kết quả trả về từ đối tượng được kiểm tra.
1.6. Trƣờng hợp (Use case) kiểm thử trong phần mềm là gì?
Sử dụng trường hợp kiểm thử là một kỹ thuật giúp chúng ta xác định được các
trường hợp kiểm thử đó thực hiện toàn bộ hệ thống trên một giao dịch theo từng giao
dịch từ đầu đến cuối.
Một trường hợp sử dụng là một mô tả chi tiết cụ thể của hệ thống được xác
định bởi một tác nhân (một người sử dụng của hệ thống). Mỗi trường hợp sử
dụng được mô tả tương tác với các tác nhân đã có trong hệ thống để đạt được
một nhiệm vụ cụ thể như: sản xuất cái gì có giá trị cho người sử dụng,..
Nói chung tác nhân là người trong hệ thống nhưng cũng có thể là các hệ
thống khác.
Trường hợp sử dụng là một chuỗi các bước mô tả sự tương tác giữa các tác
nhân và hệ thống. Sử dụng các trường hợp được quy định tại các điều kiện của
tác nhân, không hệ thống, mô tả những gì các tác nhân làm và những gì các tác
nhân nhìn thấy hơn là những gì đầu vào hệ thống mong muốn và những gì kết
quả đầu ra của hệ thống.
Họ thường sử dụng ngôn ngữ và các điều kiện của người giao dịch chứ không
phải là thuật ngữ kỹ thuật, đặc biệt là khi các tác nhân là một người giao dịch
của hệ thống.
Trường hợp thử nghiệm chủ yếu là ở cấp hệ thống kiểm tra và chấp nhận.
Trường hợp sử dụng có thể khám phá các khiếm khuyết được tạo ra bởi sự
tương tác không chính xác giữa các thành phần.
Trường hợp sử dụng mô tả quá trình hoạt động của một hệ thống dựa trên
nhiều khả năng của nó. Điều này làm cho các trường hợp kiểm thử từ trường
hợp sử dụng đặc biệt tốt cho việc tìm kiếm các khiếm khuyết trong việc sử
dụng thực tế của hệ thống (tức là những khuyết tật mà người sử dụng có nhiều
khả năng đi qua khi lần đầu tiên sử dụng hệ thống).
Mỗi trường hợp sử dụng thường có một xu hướng chính hoặc có thể là kịch
bản và đôi khi thêm các nhánh khác bao gồm: ví dụ, trường hợp đặc biệt hoặc
điều kiện ngoại lệ.
14
Mỗi trường hợp sử dụng phải xác định bất kỳ điều kiện quyết định mà cần
phải được đáp ứng cho các trường hợp sử dụng để làm việc.
Trường hợp sử dụng cũng phải xác định điều kiện đó là những kết quả quan
sát và mô tả một trạng thái cuối cùng của hệ thống sau khi các trường hợp sử
dụng đã được thực hiện thành công.
Ví dụ: Về việc nhập mã PIN vào hệ thống ATM sau cho thấy kịch bản thành
công và không thành công. Trong sơ đồ này, là sự tương tác giữa A (Actor –tác nhân
trong trường hợp này là con người) và S (System – hệ thống). Từ bước 1 đến bước 5 là
các kịch bản thành công, cho ta thấy rằng thẻ và PIN cả hai đã xác nhận và cho phép
tác nhân để truy cập vào tài khoản. Nhưng trong phần mở rộng (Extensions) có ba
trường hợp khác nhau là 2a, 4a, 4b được thể hiện trong biểu đồ dưới đây.
Bước
Main Success Scenario
Mô tả
1
A: Inserts card
2
S: Validates card and asks for PIN
3
A: Enters PIN
4
S: Validates PIN
5
S: Allows access to account
2a
Card not valid
A: Actor
S: System
S: Display message and reject card
4a
PIN not valid
Extensions (Mở rộng)
S: Display message and ask for retry (twice)
4b
PIN invalid 3 times
S: eat card and exit
Bảng 1. 1. Mô tả nhập mã PIN của ATM.
Đối với trường hợp sử dụng thử nghiệm, tôi sẽ đưa ra một bài kiểm tra của các
kịch bản thành công và là một thử nghiệm cho mỗi lần mở rộng. Trong ví dụ này,
chúng ta có thể cho phần mở rộng 4b một sự ưu tiên cao hơn 4a từ một góc nhìn. Yêu
cầu hệ thống cũng có thể được quy định như một tập hợp các trường hợp sử dụng.
Cách tiếp cận này có thể làm cho nó dễ dàng hơn để liên quan đến người sử dụng trong
các yêu cầu thu thập và xác định qui trình hoạt động của hệ thống.
15
1.7. Các mức kiểm thử phần mềm.
Trong thực tế, kiểm thử phần mềm có nhiều mức khác nhau và có mối quan hệ
chặt chẽ với các giai đoạn phát triển trong một dự án phát triển phần mềm. Có bốn
mức kiểm thử phần mềm cơ bản: Unit test (kiểm thử đơn vị); Integration test (kiểm thử
tích hợp); System test (kiểm thử hệ thống); Acceptance test (kiểm thử chấp nhận).
Trong đó chỉ có ba loại kiểm thử đầu tiên được thực hiện bởi các nhóm phát triển
trong đơn vị sản xuất phần mềm, còn kiểm thử chấp nhận được thực hiện bởi khách
hàng. Bốn loại kiểm thử trên kết hợp với nhau tạo thành mô hình chữ V.
Ƣu điểm.
- Đơn giản dễ sử dụng.
- Có hoạt động, kế hoạch cụ thể cho quá trình test.
- Tiết kiệm được thời gian, và có cơ hội thành công cao hơn waterfall.
- Chủ động trong việc phát hiện bug, sớm tìm ra bug ngay từ những bước đầu.
Nhƣợc điểm.
- Độ linh hoạt ít và còn tồn tại sự cứng nhắc. Nó thể hiện ở chỗ cứ sau mỗi step
thì lại phải có một - công đoạn test, nếu yêu cầu dự án không quá phức tạp và
dễ hiểu, thì việc thực hiện nhiều công đoạn test như vậy là tốn thời gian.
- Giống với waterfall, sản phẩm của dự án chỉ được xuất hiện khi tất cả các bước
được hoàn thành xong, không có nguyên mẫu ngay từ ban đầu. Không đáp ứng
được yêu cầu dịch vụ vừa phát triển, song song với vừa bán sản phẩm.
- Nếu có sự thay đổi về kỹ thuật ở nửa chừng, thì sẽ phải quay lại các bước đầu
tiên, thực hiện lại, update lại tài liệu.
Áp dụng cho những dự án nhƣ thế nào?
- Dự án có kích thước nhỏ, và trung bình, các yêu cầu dự án là rõ ràng, cố định.
- Khi team phát triển có đội ngũ kỹ thuật tốt, có nguồn tài nguyên phong phú, sẵn
có để đảm bảo được yêu cầu, đọc nhanh, test nhanh và coding nhanh.
- Nếu khách hàng có sự tự tin cao trong yêu cầu thiết kế (nghĩa là ít thay đổi, ít
dao động) thì mô hình chữ V (V model) là lựa chọn cần thiết.
16
Hình 1.1. Qui trình phát triển và các mức kiểm thử trong mô hình chữ V.
Giai đoạn phát triển:
Xác định yêu cầu và đặc tả (Requirement & Specification): Xác định yêu cầu
cần thiết mà hệ thống đòi hỏi, đưa ra bản đặc tả.
Phân tích hệ thống (System Analysis): Phân tích các yêu cầu mà hệ thống cần
có và đưa ra giải pháp tích hợp các yêu cầu đó vào hệ thống.
Thiết kế chi tiết (Detailed Design): Chi tiết hóa các bước thực hiện xây dựng hệ
thống về cả giao diện và nội dung.
Phát triển (Development): Thực hiện việc viết code.
Giai đoạn kiểm thử:
a. Kiểm thử đơn vị (Unit test).
Cơ sở kiểm thử :
- Các yêu cầu thành phần.
- Thiết kế chi tiết, Code.
Đối tƣợng kiểm thử:
- Các thành phần.
17
- Chương trình.
- Chuyển đổi dữ liệu, thay đổi chương trình.
- Mô hình cơ sở dữ liệu.
Để hiểu rõ về kiểm thử đơn vị, thì ta phải hiểu rõ: thế nào là một đơn vị phần
mềm? Một đơn vị là một thành phần, phần mềm nhỏ nhất mà ta có thể kiểm thử được
như: các hàm (Function), các thủ tục (Procedure), các lớp (Class), hoặc các phương
thức (Method) đề có thể được xem là đơn vị. Vì đơn vị được chọn để kiểm thử thường
có kích thước nhỏ và chức năng hoạt động đơn giản, dễ tổ chức, kiểm tra, ghi nhận và
phân tích kết quả nhận được. Một đơn vị chương trình là một đoạn mã nguồn như hàm
hoặc phương thức của một lớp, có thể được gọi từ ngoài và cũng có thể gọi đến các
đơn vị chương trình khác. Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục
lỗi đối với một đơn vị tương đối dễ dàng. Một nguyên lý đúc kết từ thực tiễn là: thời
gian tốn kém cho kiểm thử đơn vị sẽ được bù đắp bằng việc tiết kệm rất nhiều thời
gian và chi phí cho việc kiểm thử và sửa lỗi ở các mức kiểm thử sau đó.
Kiểm thử đơn vị là việc kiểm thử các đơn vị chương trình một cách cô lập.
Kiểm thử đơn vị tập trung vào việc xác minh trên đơn vị nhỏ nhất của thiết kế
phần mềm. Tuy nhiên, kiểm thử đơn vị đòi hỏi kiểm thử viên có kiến thức về thiết kế
và hiểu được mã của chương trình. Mục đích của kiểm thử đơn vị là bảo đảm thông tin
được xử lý và xuất ra là chính xác, với dữ liệu nhập và chức năng của đơn vị. Các mức
kiểm thử nhằm phát hiện các lỗi trong các phạm vi của module bao gồm: giao diện
module; cấu trúc dữ liệu cục bộ; điều kiện biên; đường dẫn độc lập; đường dẫn xử lý
lỗi. Do đó kiểm thử đơn vị đòi hỏi tất cả các nhánh bên trong đơn vị đều phải được
kiểm thử để phát hiện nhánh phát sinh lỗi. Mỗi nhánh thường là một chuỗi các lệnh
được thực thi trong một đơn vị như: chuỗi các lệnh sau điều kiện If và nằm giữa
Then… Else là một nhánh.
Kiểm thử đơn vị thường được xem như một phần phụ cho các bước mã hóa sau
khi mã nguồn được phát triển, được duyệt lại và được kiểm tra đúng cú pháp thì bắt
đầu thiết kế các trường hợp kiểm thử đơn vị. Kiểm thử đơn vị thường được làm bởi
chính tác giả (lập trình viên) của chương trình và có thể tiến hành theo hai giai đoạn:
kiểm thử đơn vị tĩnh (static unit testing) và kiểm thử đơn vị động (dynamic unit
testing).
Kiểm thử đơn vị tĩnh là việc kiểm tra tính đúng đắn của code (mã lệnh), thuật
toán hay tài liệu, được thực hiện qua các bước: chuẩn bị kịch bản, nhân lực
chuẩn bị câu hỏi; yêu cầu thay đổi kiểm tra, đánh giá; mã nguồn tác giả
mã nguồn sửa những vấn đề thay đổi xác minh lại kết thúc.
18
Kiểm thử đơn vị động là việc khảo sát đơn vị dựa vào việc tiến hành, gồm các
bước:
1) Đơn vị được tách ra khỏi môi trường;
2) Môi trường được làm giả bằng cách tạo ra các Test driver và Stub. Test
driver là chương trình được viết nhằm gọi đến đơn vị đang được thử. Còn
Stub là một đơn vị giả lập để đơn vị gọi đến nhằm quan sát dòng điều
khiển và giao diện của đơn vị đang được thử.
3) Dịch và tiến hành. Quan sát để xác định hành vi có đúng không. Nếu
không đúng như chờ đợi thì đơn vị có lỗi.
b. Kiểm thử tích hợp (Integration test).
Cơ sở kiểm thử :
- Thiết kế hệ thống và phần mềm, kiến trúc.
- Luồng công việc và các trường hợp sử dụng.
Đối tƣợng kiểm thử:
- Các hệ thống con, cơ sở dữ liệu.
- Cơ sở hạ tầng, giao diện.
- Cấu hình hệ thống và cấu hình dữ liệu.
Kiểm thử tích hợp nhằm đảm bảo hệ thống làm việc ổn định trong môi trường
thí nghiệm để sẵn sàng cho việc đưa vào môi trường thực sự bằng cách đặt các đơn vị
với nhau theo phương pháp tăng dần. Kiểm thử tích hợp có 2 mục đích chính: phát
hiện lỗi giao tiếp xảy ra giữa các đơn vị; Tích hợp các đơn vị đơn lẻ thành các hệ
thống nhỏ (subsystem) và cuối cùng là một hệ thống hoàn chỉnh (system) chuẩn bị cho
kiểm tra hệ thống. Kiểm thử tích hợp chỉ nên thực hiện trên những đơn vị đã được
kiểm tra cẩn thận trước đó bằng Unit test và tất cả các lỗi mức đơn vị đã được sửa
chữa. Trong kiểm thử tích hợp gồm:
Kiểm thử cấu trúc: Nhằm bảo đảm các thành phần bên trong của một
chương trình chạy đúng.
Kiểm thử chức năng: Nhằm chú trọng đến chức năng của chương trình,
không quan tâm đến cấu trúc bên trong, chỉ khảo sát chức năng của chương
trình theo yêu cầu kĩ thuật.
Kiểm thử hiệu năng: Kiểm tra việc vận hành của hệ thống.
Kiểm thử khả năng chịu tải: Kiểm tra các giới hạn của hệ thống.
19
Tóm lại, kiểm thử tích hợp kiểm tra các giao diện giữa các thành phần, tương
tác với các phần khác nhau của một hệ thống như là hệ điều hành, hệ thống file, phần
cứng và các giao diện giữa các hệ thống. Có nhiều hơn một mức độ kiểm thử tích hợp
và nó có thể thực hiện trên các đối tượng của các quy mô khác nhau như sau:
o Kiểm thử tích hợp thành phần, kiểm tra sự tương tác giữa các thành phần
phần mềm và được thực hiện sau kiểm thử thành phần.
o Kiểm thử tích hợp hệ thống, kiểm tra sự tương tác giữa các hệ thống khác
nhau hoặc giữa phần cứng và phần mềm. Được thực hiện sau kiểm thử hệ
thống.
o Kiểm thử tích hợp dựa trên kiến trúc hệ thống ( như là top-down và bottomup), các nhiệm vụ chức năng, trình tự xử lý giao dịch hoặc một vài khía cạnh
của hệ thống hoặc các phần mềm. Để dễ dàng sữa lỗi và phát hiện lỗi sớm
phương pháp kiểm thử tích hợp thường được dùng là “big bang”.
o Kiểm thử tích hợp có thể bao gồm kiểm thử phi chức năng (như kiểm thử
hiệu suất).
o Tester sẽ là người thực hiện kiểm thử tích hợp. Cả hai phương pháp tiếp cận
chức năng ( functional) và cấu trúc (structural) sẽ được sử dụng.
o Kiểm thử tích hợp được lên kế hoạch trước khi các thành phần và hệ thống
được xây dựng.
c. Kiểm thử hệ thống (System test).
Cơ sở kiểm thử:
- Yêu cầu đặc tả của phần mềm và hệ thống, các trường hợp sử dụng.
- Đặc tả chức năng, báo cáo phân tích rủi ro.
Đối tƣợng kiểm thử:
- Hệ thống, người sử dụng, hướng dẫn hoạt động.
- Cấu hình hệ thống và cấu hình dữ liệu.
Mục đích của kiểm thử hệ thống là kiểm tra thiết kế toàn bộ hệ thống có thỏa
mãn yêu cầu đặt ra hay không?
Kiểm tra hệ thống thực tế là một tập các kiểm thử khác nhau với mục đích cơ
bản là thực hiện đầy đủ hệ thống dựa trên máy tính. Mặc dù mỗi kiểm thử có một mục
đích khác nhau, nhưng tất cả các công việc đều nhằm kiểm tra tất cả các thành phần hệ
thống được tích hợp một cách hợp lý và thực hiện đúng các chức năng đã xác định.
20
Kiểm thử hệ thống được bắt đầu khi tất cả các bộ phận của phần mềm đã được
tích hợp thành công. Kiểm thử hệ thống kiểm tra 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 cũng như độ tin cậy, tính tiện lợi khi sử dụng và thường
được thực hiện bởi một nhóm kiểm tra viên hoàn toàn độc lập với nhóm phát triển dự
án. Với mục đích nhằm đảm bảo rằng việc cài đặt tuân thủ đầy đủ các yêu cầu được
đặc tả của người dùng. Kiểm thử hệ thống có liên quan với các hành vi của cả hệ
thống/sản phẩm.
Trong kiểm thử hệ thống, môi trường kiểm thử phải tưng ứng với các mục tiêu
hoặc môi trường sản xuất để giảm thiểu các rủi ro của các sự cố môi trường không
được tìm thấy trong kiểm thử.
Kiểm thử hệ thống bao gồm các kiểm tra dựa trên các rủi ro hoặc yêu cầu đặc
tả, quy trình nghiệp vụ, các trường hợp sửa dụng, các mô hình hành vi của hệ thống,
tương tác với các hệ điều hành và tài nguyên hệ thống.
Kiểm thử hệ thống kiểm tra các yêu cầu chức năng và phi chức năng và các đặc
tính chất lượng dữ liệu. Kiểm thử chức năng sử dụng kỹ thuật kiểm thử hộp đen. Kiểm
thử phi chức năng sử dụng các kỹ thuật kiểm thử hộp trắng. Một đội kiểm thử độc lập
thường thực hiện kiểm thử hệ thống. Kiểm thử hệ thống gồm có các loại sau:
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ử khả năng vận hành: Bảo đảm việc phân bố tài nguyên hệ thống…
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.
Kiểm thử cấu hình.
Kiểm thử khả năng bảo mật: Bảo đảm tính toàn vẹn, bảo mật của dữ liệu.
Kiểm thử tính 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 của dữ liệu.
d. Kiểm thử chấp nhận (Acceptance test).
Kiểm thử chấp nhận được thực thi bởi chính các khách hàng nhằm đảm bảo
rằng sản phẩm phần mềm làm việc đúng như họ mong đợi. Mục đích của kiểm thử
chấp nhận là để chứng minh phần mềm thỏa mãn tất cả các yêu cầu của khách hàng và
khách hàng chấp nhận sản phẩm.
Kiểm thử chấp nhận dựa vào:
Các yêu cầu người dùng (User requirements);
21
Các yêu cầu hệ thống (System requirements);
Các trường hợp sử dụng (Use cases);
Các qui trình xử lý công việc (Business processes);
Các báo cáo phân tích rủi ro (Risk analysis reports);
Các mục tiêu kiểm tra chung:
Kiểm tra các qui trình xử lý công việc trên hệ thống đã được tích hợp đầy
đủ nhất;
Các qui trình hoạt động và bảo trì;
Các thủ tục người dùng (ví dụ: phân quyền dựa trên user login);
Các form (ví dụ, các màn hình nhập liệu);
Các Report (ví dụ các bản báo cáo như phiếu thu để in, báo cáo doanh
thu…);
Kiểm thử chấp nhận có thể xảy ra vào một vài thời điểm khác nhau trong qui
trình sản xuất phần mềm như:
Một sản phẩm phần mềm COTS có thể được thực hiện Acceptance testing
khi nó được cài đặt hoặc tích hợp.
Việc thực hiện Acceptance testing để test tính tiện dụng của một thành phần
(component) có thể được hoàn thành trong lúc thực hiện component test.
Việc thực hiện Acceptance testing để test việc cải tiến chức năng mới có thể
được thực hiện trước lúc thực hiện System test.
Có hai loại kiểm thử chấp nhận: kiểm thử chấp nhận người dùng, được tiến
hành bởi người dùng, và kiểm thử chấp nhận doanh nghiệp, được tiến hành bởi nhà
sản xuất ra sản phẩm phần mềm.
Tóm lại kiểm thử chấp nhận là hoạt động thẩm định (Validation) và do người sử
dụng, khách hàng kiểm tra. Họ xem hệ thống phần mềm có đáp ứng đúng như mong
muốn của họ không, không cần tài liệu đặc tả. Chúng ta cần kiểm thử chấp nhận vì đặc
tả có thể đã có khiếm khuyết hoặc người khách hàng và phát triển cùng đọc một tài
liệu nhưng hiểu không hoàn toàn. Quyết định này, có thể dựa vào các số đo của sản
phẩm hoặc quy trình. Các số đo của sản phẩm thường được suy ra từ kết quả kiểm thử
thống kê. Số đo quy trình thường dựa trên kinh nghiệm của người đánh giá so với sản
phẩm trước đó. Các số đo này đánh giá mức độ tin cậy của phần mềm để quyết định
triển khai cho người dùng cuối. Gắn liền với giai đoạn kiểm thử chấp nhận thường là
22
một nhóm những dịch vụ và tài liệu đi kèm, được phổ biến như hướng dẫn cài đặt, sử
dụng,…Tất cả tài liệu đi kèm phải được cập nhật và kiểm thử chặt chẽ.
1.8. Kỹ thuật kiểm thử tĩnh và tiến trình kiểm thử5.
Kỹ thuật kiểm thử tĩnh dựa trên việc kiểm tra thủ công (reviews) và phân tích
tĩnh tự động ( static analysis) của mã( code) hoặc tài liệu dự án mà không thực thi mã
chương trình.
Đánh giá (reviews) là một cách kiểm thử sản phẩm công việc phần mềm ( bao
gồm cả code) được thực hiện trước kiểm thử động. Các lỗi được phát hiện trong quá
trình review sớm trong chu trình vòng đời ( ví dụ các lỗi được tìm thấy trong đặc tả) rẻ
hơn nhiều so với các lỗi được phát hiện bằng cách chạy kiểm thử thi hành các mã.
Một đánh giá(review) được thực hiện như thế nào :
- Đánh giá thủ công (Review manually) và dùng công cụ hỗ trợ (Automated
Analysis by Tool).
Đối tượng đánh giá (pecifications) bao gồm:
- Thiết kế thông số kỹ thuật (design specifications) và mã(Code).
- Kế hoạch kiểm thử (test plans) và kỹ thuật kiểm thử( test specifications).
- Các trường hợp kiểm thử( test cases).
- Các kịch bản kiểm thử ( test scripts).
- Hướng dẫn sử dụng( user guides) và các trang web (web pages).
Lợi ích của đánh giá (review):
- Sớm phát hiện lỗi và điều chỉnh và cải thiện năng suất phát triển.
- Giảm khoảng thời gian phát triển và giảm chi phí và thời gian kiểm thử.
Loại khiếm khuyết trong đánh giá (reviews) bao gồm:
- Độ lệch tiêu chuẩn (deviations from standards).
- Khiếm khuyết trong yêu cầu ( requirement defects) và khiếm khuyết trong
thiết kế ( design defects).
- Không đủ khả năng bảo trì code (insufficient maintainability) và chi tiết
kỹ thuật giao diện không chính xác (incorrect interface specifications).
Đánh giá có thể tìm các thiếu sót mà không có khả năng tìm thấy trong kiểm
thử động. Ví dụ như thiếu sót trong yêu cầu kỹ thuật.
23
