ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ
TRẦN THỊ THÚY NHUNG
NGHIÊN CỨU KIỂM THỬ WEB SERVICE VÀ XÂY DỰNG
CÔNG CỤ HỖ TRỢ
LUẬN VĂN THẠC SỸ 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Ị THÚY NHUNG
NGHIÊN CỨU KIỂM THỬ WEB SERVICE VÀ XÂY DỰNG
CÔNG CỤ HỖ TRỢ
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Ỹ CÔNG NGHỆ THÔNG TIN
NGƢỜI HƢỚNG DẪN KHOA HỌC: TS NGUYỄN ĐỨC DŨNG
HÀ NỘI - 2014
LỜI CAM ĐOAN
Tôi xin cam đoan kết quả đạt được trong luận văn là sản phẩm nghiên cứu, tìm
hiểu của riêng cá nhân tôi. Trong toàn bộ nội dung của luận văn, những điều được
trình bày hoặc là của cá nhân tôi hoặc là được tổng hợp từ nhiều nguồn tài liệu. Tất cả
các tài liệu tham khảo đều có xuất xứ rõ ràng và được trích dẫn hợp pháp.
Tôi xin hoàn toàn chịu trách nhiệm và chịu mọi hình thức kỷ luật theo quy định
cho lời cam đoan của mình.
Hà Nội, ngày 30 tháng 10 năm 2014
Người cam đoan
Trần Thị Thúy Nhung
LỜI CẢM ƠN
Tôi xin chân thành cảm ơn TS. Nguyễn Đức Dũng là Phó viện trưởng – Viện hàn
lâm khoa học và công nghệ Việt nam đã tận tình giúp đỡ tôi về cả chuyên môn, nghiên
cứu và định hướng phát triển trong suốt quá trình làm luận văn. Tôi đã học hỏi được
rất nhiều khi nghiên cứu đề tài luận văn trên.
Tôi cũng xin gửi lời cám ơn tới các Thầy, Cô giáo của Khoa Công nghệ thông
tin, vì đã truyền dạy những kiến thức bổ ích, hiện đại về lĩnh vực Công nghệ phần
mềm tôi học tập. Tôi đã được học tập dưới một môi trường giáo dục tốt về ngành công
nghệ thông tin của cả nước.
Với bạn bè cùng khóa. Xin cám ơn vì đã cho tôi cơ hội trao đổi, chia sẻ kiến thức
và kinh nghiệm thực tế qua các môn học. Mọi người đã giúp tôi hiểu thêm những vấn
đề mà tôi không có điều kiện tìm hiểu, chỉ cho tôi những thứ tôi chưa làm được. Tôi có
thể tiếp thu được thêm nhiều vấn đề mới và biết được giá trị của việc không ngừng cố
gắng học tập, nghiên cứu.
Cuối cùng, với gia đình và đồng nghiệp, tôi xin gửi lời biết ơn sâu sắc vì gia đình
đã luôn ở bên và ủng hộ tôi trên con đường học tập vất vả, cảm ơn đồng nghiệp vì đã
tạo điều kiện để tôi có thể hoàn thành được hết khóa học. Tôi mong và hy vọng rằng
với những kiến thức học được thì tôi có thể áp dụng được nhiều hơn vào công việc
kiểm thử hiện tại của bản thân và đóng góp nhiều hơn các ý tưởng tốt để công việc
được tốt hơn.
Hà Nội, Tháng 10 - Năm 2014
Trần Thị Thúy Nhung
MỤC LỤC
BẢNG TỪ VIẾT TẮT .......................................................................................... 4
DANH MỤC HÌNH MINH HỌA ........................................................................ 5
DANH MỤC BẢNG BIỂU ................................................................................... 5
Chƣơng 1. TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM ................................ 9
1.1.Kiểm thử phần mềm ......................................................................................... 9
1.2.Phân loại kiểm thử ........................................................................................... 9
1.3.Các phương pháp kiểm thử ............................................................................... 9
1.3.1.Kiểm thử tĩnh ................................................................................................. 9
1.3.2.Kiểm thử động ................................................................................................ 9
1.4.Các kỹ thuật kiểm thử ..................................................................................... 10
1.4.1.Kiểm thử hộp trắng – White box testing ...................................................... 10
1.4.1.1.Kiểm thử đường dẫn cơ sở (Basic Path Testing) ...................................... 11
1.4.1.2.Kiểm thử cấu trúc điều khiển .................................................................... 12
1.4.2.Kiểm thử hộp đen – Black box testing ......................................................... 14
1.5.Quy trình kiểm thử phần mềm ........................................................................ 17
1.6.Kiểm thử tự động ............................................................................................ 18
1.7.Kết luận chương .............................................................................................. 19
Chƣơng 2. TỔNG QUAN VỀ CÔNG NGHỆ DỊCH VỤ WEB ...................... 20
2.1.Định nghĩa....................................................................................................... 20
2.1.1.Khái niệm ..................................................................................................... 20
2.1.2.Đặc điểm của dịch vụ Web .......................................................................... 20
2.1.3.Ưu điểm và hạn chế của dịch vụ Web ......................................................... 20
2.1.4.Ứng dụng của dịch vụ Web ......................................................................... 21
2.2.Kiến trúc chung của dịch vụ Web................................................................... 21
2.3.Các thành phần của dịch vụ web .................................................................... 23
2.3.1.XML – eXtensible Markup Language .......................................................... 23
2.3.2.WSDL – Web Service Description Language .............................................. 24
2.3.3.Universal Description, Discovery, and Integration (UDDI) ....................... 28
2.3.4.SOAP – Simple Object Access Protocol ...................................................... 29
2.4.Bảo mật dịch vụ web ...................................................................................... 29
2.5.Triển khai và tích hợp dịch vụ web ................................................................ 31
2.5.1.Triển khai dịch vụ web ................................................................................ 31
2.5.2.Tích hợp dịch vụ web .................................................................................. 32
1
2.6.Kiểm thử dịch vụ web ........................................................................................... 33
2.7.Kết luận chƣơng..................................................................................................... 36
Chƣơng 3. XÂY DỰNG CÔNG CỤ HỖ TRỢ KIỂM THỬ DỊCH VỤ WEB ....... 37
3.1.Mô tả và xây dựng bài toán ..................................................................................... 37
3.1.1.Mô tả bài toán ....................................................................................................... 37
3.1.2.Sơ đồ chức năng hệ thống .................................................................................... 40
3.1.3.Thiết kế cơ sở dữ liệu ........................................................................................... 42
3.2.Phân tích và đánh giá hệ thống ................................................................................ 44
3.2.1.Phân tích các chức năng của hệ thống .................................................................. 44
3.2.1.1.Xác định các Actor và Use Case ....................................................................... 44
3.2.1.2.Xây dựng biểu đồ Use Case của toàn hệ thống ................................................. 47
3.2.1.3.Đặc tả danh sách các Use Case.......................................................................... 47
3.2.1.3.1.Use Case Thêm mới thông tin Web service .................................................... 47
3.2.1.3.2.Use Case Chỉnh sửa thông tin Web service ................................................... 47
3.2.1.3.4.Use case xuất mẫu import testcase ................................................................. 48
3.2.1.3.5.Use case Thêm mới testcase ........................................................................... 49
3.2.1.3.6.Use case Chỉnh sửa Testcase ......................................................................... 50
3.2.1.3.7.Use case Xóa Testcase.................................................................................... 51
3.2.1.3.8.Use case Import Testcase ............................................................................... 52
3.2.1.3.9.Use case Thêm mới kiểu dữ liệu ..................................................................... 52
3.2.1.3.10.Use case Chỉnh sửa kiểu dữ liệu .................................................................. 53
3.2.1.3.11.Use case Xóa kiểu dữ liệu ............................................................................ 53
3.2.1.3.12.Use case tạo testcase tự động ....................................................................... 54
3.2.1.3.13.Use case Thực hiện kiểm thử ........................................................................ 55
3.2.1.3.14.Use case Xuất báo cáo ................................................................................. 55
3.2.2.Thiết kế một số giao diện của hệ thống ................................................................ 56
3.2.2.2.Giao diện chính của phần mềm ......................................................................... 56
3.2.2.3.Giao diện danh mục quản lý Web service ......................................................... 56
3.2.2.4.Giao diện danh mục quản lý testcase ................................................................ 57
3.2.2.5.Giao diện màn hình import testcase .................................................................. 57
3.2.2.6.Giao diện màn hình cấu hình kiểu dữ liệu ......................................................... 58
3.2.2.7.Giao diện màn hình tạo testcase tự động ........................................................... 58
3.2.3.Cài đặt, triển khai hệ thống................................................................................... 59
3.2.3.2.Mô hình triển khai hệ thống .............................................................................. 59
3.2.3.3.Phần mềm .......................................................................................................... 60
2
3.2.3.4.Phần cứng ................................................................................................. 60
3.2.4.Phân tích kết quả .......................................................................................... 60
3.2.4.1.Yêu cầu bài toán ....................................................................................... 60
3.2.4.2.Giải pháp thực hiện .................................................................................. 60
3.2.4.3.Triển khai thực hiện .................................................................................. 63
3.2.4.3.1.Xây dựng Web service............................................................................ 63
3.2.4.3.2.Lập kịch bản test .................................................................................... 68
3.2.4.3.3.Thực hiện test ......................................................................................... 69
3.2.4.4.Kết quả đạt được ....................................................................................... 69
3.2.4.5.Đánh giá kết quả ....................................................................................... 69
3.3.Kết luận ........................................................................................................... 74
KẾT LUẬN VÀ ĐỀ XUẤT ................................................................................ 75
DANH MỤC CÁC TÀI LIỆU THAM KHẢO ................................................. 76
3
BẢNG TỪ VIẾT TẮT
BVA
Boundary Value Analysis
MTTR
Mean Time To Repair
CSDL
Cơ sở dữ liệu
SOAP
Simple Object Access Protocol
WSDL
Dịch vụ Web Description Language
UDDI
Universal Description, Discovery, and Integration
HTTP
HyperText Transfer Protocol
TCP/IP
Transmission Control Protocol/Internet Protocol
SMTP
Simple Mail Transfer Protocol
FTP
File Transfer Protocol
XML
Extensible Markup Language
REST
Representational State Transfer
API
Application Programming Interface
RPC
Remote Procedure Call
SSL
Secure Sockets Layer
SQL
Structured Query Language
WS
Dịch vụ Web
4
DANH MỤC HÌNH MINH HỌA
Hình 1.1. Ví dụ chu trình điều khiển
Hình 1.2. Các kiểu vòng lặp
Hình 1.3. Giai đoạn kiểm thử trong xử lý phần mềm
Hình 1.4. Qui trình kiểm thử phần mềm
Hình 2.1. Kiến trúc chung của dịch vụ Web
Hình 2.2. Mô hình tương tác
Hình 2.3. Thành phần của WSDL
Hình 2.4. Một tài liệu WSDL
Hình 2.5. Cấu trúc tài liệu WSDL
Hình 2.6. Kiểu dữ liệu trong tài liệu WSDL
Hình 2.7. Messages trong tài liệu WSDL
Hình 2.8. Operations trong tài liệu WSDL
Hình 2.9. Port Type trong tài liệu WSDL
Hình 2.10. Bindings trong tài liệu WSDL
Hình 2.11. Service và port trong tài liệu WSDL
Hình 3.1. Mô tả kiểm thử WS qua SoapUI
Hình 3.2. Mô tả luồng xử lý công cụ tự động
Hình 3.3. Sơ đồ chức năng
Hình 3.4. Sơ đồ lớp
Hình 3.5. Use Case quản lý thông tin web service
Hình 3.6. Quản lý thông tin testcase
Hình 3.7. Quản lý thông tin kiểu dữ liệu
Hình 3.8. Use case thực hiện kiểm thử và xuất kết quả
Hình 3.9. Giao diện chính của phần mềm
Hình 3.10. Giao diện danh mục quản lý Web service
Hình 3.11. Giao diện danh mục quản lý testcase
Hình 3.12. Giao diện màn hình import testcase
Hình 3.13. Giao diện màn hình cấu hình kiểu dữ liệu
Hình 3.14. Giao diện màn hình tạo testcase tự động
Hình 3.15. Mô hình triển khai
5
DANH MỤC BẢNG BIỂU
Bảng 3.1. Danh sách các bảng trong cơ sở dữ liệu
Bảng 3.2. Các bước xử lý
Bảng 3.3. Bảng thiết kế CSDL cho WS
Bảng 3.4. Bảng thiết kế các trường hợp kiểm thử
6
MỞ ĐẦU
1. Đặt vấn đề, định hƣớng nghiên cứu
Hiện nay ngành công nghệ phần mềm đang rất phát triển ở nhiều lĩnh vực. Tuy
nhiên để đảm bảo được sản phầm phần mềm tin cậy thì ngoài việc thiết kế, lập trình
phải kể đến một khâu cực kỳ quan trọng đó là kiểm thử. Nếu như phát triển tạo ra
được một sản phẩm thì kiểm thử sẽ đảm bảo phần mềm đó hoạt động đúng theo thiết
kế. Vì vậy bước kiểm thử rất quan trọng trong vòng đời phát triển của một phần mềm.
Mặc dù vậy nhưng để kiểm thử thế nào để đảm bảo chất lượng, tiết kiệm chi phí và tối
ưu nhất nguồn lực thì vẫn đang là một bài toán khó cho các công ty phát triển phần
mềm. Một giải pháp hợp lý cho các vấn đề đặt ra ở trên đó là áp dụng các công cụ
kiểm thử tự động cho các phần mềm để tối ưu nguồn lực và đảm bảo chất lượng. Hiện
nay cũng có rất nhiều công cụ hỗ trợ việc này. Tuy nhiên ngoài giá thành cao và khả
năng năng áp dụng chưa rộng rãi do đặc thù các loại phần mềm khác nhau nên việc tạo
ra một công cụ hiệu quả cho các phần mềm thì vẫn đang là vấn đề cần được nghiên
cứu.
Luận văn được thực hiện dựa trên ý tưởng từ nhu cầu thực tế và kiến thức được
học. Từ đó đưa ra cách thực hiện và đánh giá. Luận văn được chia thành 5 phần:
Mở đầu
Ở chương này trình bày tổng quan về đề tài như : lý do chọn đề tài, mục tiêu, nội
dung của đề tài và công cụ cũng như môi trường để ứng dụng đề tài.
Chƣơng 1. Tổng quan về kiểm thử
Chương này trình bày khái niệm cơ bản về kiểm thử, các kỹ thuật kiểm thử và
công đoạn kiểm thử trong vòng đời phát triển của phần mềm
Chƣơng 2. Tổng quan về công nghệ Dịch vụ Web và kiểm thử Dịch vụ Web
Chương này trình bày khái quát về công nghệ dịch vụ Web, khái niệm, thành
phần, kiến trúc. Vai trò, ý nghĩa, mục đích sử dụng của Dịch vụ Web và một số tiêu
chí bổ sung khi kiểm thử dịch vụ Web
Chƣơng 3. Xây dựng công cụ hỗ trợ kiểm thử Dịch vụ Web
Trong chương này luận văn đưa ra bài toán kiểm thử, cách thức kiểm thử truyền
thống và đề xuất xây dựng một công cụ kiểm thử dịch vụ Web tự động. Từ đó đưa ra
bài toán và cách áp dụng cụ thể để đánh giá.
7
Kết luận và đề xuất
Chương này phân tích và đánh giá việc thực hiện đề tài, những đóng góp và
những hạn chế mà đề tài cần khắc phục để hoàn thiện, hướng phát triển của đề tài và
các ứng dụng của đề tài trong lý thuyết cũng như trong thực tiễn
2. Mục tiêu của đề tài
Mục tiêu của luận văn là tìm hiểu về kiến thức kiểm thử phần mềm, kiến thức về
công nghệ dịch vụ Web và kiểm thử dịch vụ Web.
Dựa trên mô hình lý thuyết ở trên để thực hiện phân tích và xây dựng công cụ hỗ
trợ kiểm thử cho một bài toán kiểm thử dịch vụ Web cụ thể.
3. Nội dung nghiên cứu
Đề tài nghiên cứu tổng quát về kiểm thử phần mềm: khái niệm, các kỹ thuật, đưa
ra nghiên cứu chi tiết về kiểm thử bảo mật và hiệu năng của dịch vụ Web. Đề tài còn
nghiên cứu tổng quát về dịch vụ Web: khái niệm, công nghệ. Từ những cơ sở lý thuyết
trên thì đề tài tiến hành đề xuất cài đặt công cụ hỗ trợ kiểm thử cho dịch vụ Web. Cụ
thể:
1.
Nêu một số khái niệm tổng quan về kiểm thử và dịch vụ Web
2.
Xây dựng công cụ hỗ trợ kiểm thử
-
Đề xuất bài toán
-
Phân tích và xây dựng thuật toán
-
Cài đặt minh họa
-
Đánh giá kết quả
3.
Kết luận những nội dung đã đạt được và hướng phát triển, các
ứng dụng của đề tài.
Học viên thực hiện
Trần Thị Thúy Nhung
8
Chƣơng 1. TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM
1.1.
Kiểm thử phần mềm
Kiểm thử phần mềm là quá trình phân tích phần mềm để phát hiện sự khác biệt
giữa kết quả của chương trình với đầu ra mong muốn để đánh giá các chức năng của
phần mềm. Kiểm thử phần mềm cần được thực hiện trong toàn bộ quá trình phát triển
của phần mềm. Kiểm thử phần mềm là rất quan trọng, là một phần bắt buộc của phần
mềm. Nó là một kỹ thuật để đánh giá chất lượng của phần mềm và cải thiện nó bằng
cách xác định các lỗi và các vấn đề [1].
1.2.
Phân loại kiểm thử
Ta phân loại kiểm thử dựa vào các yếu tố: Chiến lược kiểm thử, phương pháp
kiểm thử và kỹ thuật kiểm thử.
Dựa vào chiến lược kiểm thử ta có thể phân chia kiểm thử thành hai loại: kiểm thử thủ
công và kiểm thử tự động.
Theo phương pháp tiến hành kiểm thử ta chia kiểm thử làm hai loại: kiểm thử tĩnh và
kiểm thử động.
Dựa vào kỹ thuật kiểm thử ta có thể phân chia kiểm thử thành hai loại: kiểm thử hộp
đen, kiểm thử hộp trắng [1].
1.3.
Các phƣơng pháp kiểm thử
1.3.1. Kiểm thử tĩnh
Là phương pháp kiểm thử phần mềm thông qua việc sử dụng giấy, bút trên bàn
để kiểm tra logic, kiểm tra từng chi tiết ngay sau khi lập trình xong, chủ yếu kiểm tra
mã và xem xét các tài liệu đặc tả. Phân tích tĩnh có thể xem xét tất cả các kết quả có
thể phát sinh trong quá trình chạy chương trình. Tiêu chuẩn của kiểm thử tĩnh là tối ưu
hóa trình biên dịch.
1.3.2. Kiểm thử động
Là phương pháp thử phần mềm thông qua việc dùng máy chạy chương trình để
điều tra trạng thái từng động tác của chương trình. Đó là kiểm thử dựa trên các ca kiểm
thử xác định bằng sự thực hiện của đối tượng kiểm thử hay chạy các chương trình.
Kiểm thử động kiểm tra cách thức hoạt động động của mã lệnh, tức là kiểm tra sự
phản ứng vật lý từ hệ thống tới các biến luôn thay đổi theo thời gian. Trong kiểm thử
động, phần mềm phải thực sự được biên dịch và chạy. Kiểm thử động gồm các công
việc, nhập giá trị đầu vào và kiểm tra xem đầu ra có đúng kết quả mong muốn không.
9
Các phương pháp kiểm thử động gồm có kiểm thử đơn vị – Unit Test, Kiểm thử tích
hợp – Intergration Test, Kiểm thử hệ thống – System Test, và Kiểm thử chấp nhận sản
phẩm – Acceptance Test.
Bằng cách thực hiện kiểm thử tĩnh và kiểm thử động thì việc phát hiện lỗi sớm sẽ hạn
chế lỗi trong quá trình phát triển phần mềm. Trong thực tế thì việc kiểm thử tĩnh và
kiểm thử động được thực hiện liên tục và xen kẽ, Những người kiểm thử và các nhà
nghiên cứu cần loại bỏ ranh giới giữa tĩnh và động mà nên tạo ra một kiểm thử hỗn
hợp để có thể kết hợp thế mạnh của cả hai phương pháp tiếp cận. [1]
1.4.
Các kỹ thuật kiểm thử
Quá trình thiết kế trường hợp thử là quá trình xây dựng các phương pháp kiểm
thử có thể phát hiện lổi, sai sót khiếm khuyết của phần mềm để xây dựng một phần
mềm đạt tiêu chuẩn.
Thiết kê các trường hợp kiểm thử có vai trò:
-
Tạo ra các trường hợp kiểm thử tốt nhất có khả năng phát hiện ra lỗi, sai sót
của phần mềm một cách nhiều nhất.
-
Tạo ra các trường hợp kiểm thử có chi phí rẻ nhất đồng thời tốn ít thời gian
và công sức nhất.[2]
Ba trong số những chiến lược kiểm thử thông dụng nhất bao gồm: Kiểm thử hộp đen,
Kiểm thử hộp trắng, và Kiểm thử hộp xám. Ở đây ta tìm hiểu kỹ thuật kiểm thử hộp
trắng và kỹ thuật kiểm thử hộp đen.
1.4.1. Kiểm thử hộp trắng – White box testing
Kiểm thử hộp trắng hay còn gọi là kiểm thử hướng logic, cho phép kiểm tra cấu
trúc bên trong của phần mềm với mục đích đảm bảo rằng tất cả các câu lệnh và điều
kiện sẽ được thực hiện ít nhất một lần.
Hộp trắng đúng nghĩa phải gọi là hộp trong suốt . Chính vì vậy, kỹ thuật này còn có
một số tên khác là kiểm thử hộp thủy tinh (Glass-Box Testing) hay kiểm thử hộp trong
suốt (Clear-Box Testing). Người kiểm thử truy nhập vào mã nguồn chương trình để
kiểm tra và đây là cơ sở để hỗ trợ việc kiểm thử.
Nguyên tắc của kỹ thuật kiểm thử hộp trắng là:
-
Thực hiện mọi đường dẫn độc lập ít nhất một lần.
-
Thực hiện mọi điều kiện logic (if-then-else) trên các giá trị true và false của
chúng.
10
-
Thực hiện mọi vòng lặp (các vòng lặp for, while-do) tại các biên và trong
phạm vi hoạt động của chúng.
-
Thực hiện mọi cấu trúc dữ liệu bên trong để đảm bảo tính hợp lệ của chúng
Hình 1.1. Ví dụ chu trình điều khiển
Trong phương pháp kiểm thử hộp trắng, ta đi vào tìm hiểu các kỹ thuật kiểm thử hộp
trắng đó là:
-
Kiểm thử bao phủ chu trình cơ sở
-
Kiểm thử cấu trúc điều khiển
1.4.1.1.
Kiểm thử đường dẫn cơ sở (Basic Path Testing)
Kiểm thử đường dẫn cơ sở là một kỹ thuật kiểm thử hộp trắng do Tom McCabe
đề xuất, là việc thiết kế các trường hợp kiểm thử trên từng câu lệnh trong chương trình
được sẽ được thực hiện ít nhất một lần không quan tâm đến ảnh hưởng lên các đường
quyết định.
Phương pháp đường dẫn cơ sở cho phép người thiết kế trường hợp kiểm thử thực hiện
phép đo độ phức tạp logic của thiết kế thủ tục và sử dụng phép đo này như một chỉ dẫn
cho việc thiết kế một tập cơ sở các đường dẫn thực hiện. Những trường hợp kiểm thử
được suy diễn để thực hiện tập cơ sở. Các trường hợp kiểm thử đó được đảm bảo để
thực hiện mỗi lệnh trong chương trình ít nhất một lần trong quá trình kiểm thử.
Các bước tiến hành xây dựng một tập hợp kiểm thử như sau:
-
Dùng tài liệu thiết kế hay mã nguồn để vẽ thuật toán của chương trình hay
hàm
-
Xác định đồ thị V(G)
-
Từ đồ thị xác định tập đường độc lập tuyến tính lẫn nhau
-
Xây dựng trường hợp kiểm thử dựa trên tập đường xác định ở trên
11
1.4.1.2.
Kiểm thử cấu trúc điều khiển
Phương pháp kiểm thử đường dẫn cơ sở là phương pháp đơn giản và hiệu quả,
nhưng nó vẫn chưa đủ. Chúng ta sẽ xem xét các biến thể trên kiểm thử cấu trúc điều
khiển mà phủ kiểm thử mở rộng và hoàn thiện chất lượng của kỹ thuật kiểm thử hộp
trắng.
1.4.1.2.1. Kiểm thử điều kiện
Kiểm thử điều kiện là phương pháp thiết kế trường hợp kiểm thử dựa trên các
điều kiện logic của hàm hay module chương trình [1].
Các lỗi phát hiện được:
-
Lỗi do giá trị của biến
-
Lỗi do dấu ngoặc
-
Lỗi do phép toán quan hệ
-
Lỗi trong biểu thức toán học
Một số định nghĩa:
-
Điều kiện đơn: là một biến logic hoặc một biểu thức quan hệ, có thể có toán
tử NOT (!) đứng trước, ví dụ, NOT (a>b)
-
Biểu thức quan hệ: là một biểu thức có dạng E1 E2, trong đó E1, E2 là
các biểu thức số học và là toán tử quan hệ có thể là một trong các dạng
sau: <, <=, >, >=, = =, !=, ví dụ, a > b+1.
-
Điều kiện phức: gồm hai hay nhiều điều kiện đơn, toán tử logic AND (&&)
hoặc OR (||) hoặc NOT (!) và các dấu ngoặc đơn „(„ và „)‟, ví dụ, (a > b +
1) AND (a <= max).
Vì vậy, các thành phần trong một điều kiện có thể gồm phép toán logic, biến logic, cặp
dấu ngoặc logic (bao một điều kiện đơn hoặc phức), phép toán quan hệ, hoặc biểu thức
toán học. Mục đích của kiểm thử điều kiện là để xác định không chỉ các lỗi điều kiện
mà cả các lỗi khác trong chương trình. Có một số phương pháp kiểm thử điều kiện
được đề xuất:
Kiểm thử nhánh (Branch Testing): là phương pháp kiểm thử điều kiện đơn giản nhất.
Kiểm thử miền (Domain Testing): cần 3 hoặc 4 kiểm thử cho biểu thức quan hệ. Với
một biểu thức quan hệ có dạng E1 E2, cần có 3 kiểm thử được thiết kế cho E1=
= E2, E1 > E2, E1 < E2.
1.4.1.2.2. Kiểm thử luồng dữ liệu
Phương pháp kiểm thử luồng dữ liệu lựa chọn một số đườ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. Với kiểm
12
thử luồng dữ liệu mỗi câu lệnh trong chương trình được gán số hiệu lệnh duy nhất và
mỗi hàm không thay đổi tham số của nó và biến toàn cục. Cho một lệnh với S là số
hiệu câu lệnh. Ta định nghĩa [1]:
DEF(S) = là tập các biến được khai báo trong S.
USE(S) = là tập các biến được sử dụng trong S.
Một chiến lược kiểm thử luồng dữ liệu cơ bản là chiến lược mà mỗi chuỗi DU được
phủ ít nhất một lần. Chiến lược này được gọi là chiến lược kiểm thử DU. Kiểm thử
DU không đảm bảo phủ hết tất cả các nhánh của một chương trình. Tuy nhiên, một
nhánh không đảm bảo được phủ bởi kiểm thử DU chỉ trong rất ít tình huống như cấu
trúc if-then-else mà trong đó phần then không có một khai báo biến nào và có dạng
khuyết (không tồn tại phần else). Trong tình huống đó, nhánh else của lệnh if là không
cần thiết phải phủ bằng kiểm thử DU.
Chiến lược kiểm thử luồng dữ liệu là rất hữu ích cho việc lựa chọn các đường dẫn
kiểm thử của chương trình có chứa các lệnh if hoặc vòng lặp lồng nhau.
1.4.1.2.3. Kiểm thử vòng lặp
Vòng lặp là nền tảng cho hầu hết các thuật toán được cài đặt trong phần mềm.
Tuy nhiên, chúng ta thường ít quan tâm đến nó khi thực hiện việc kiểm thử phần mềm.
Kiểm thử vòng lặp là một kỹ thuật kiểm thử hộp trắng mà tập trung trên tính hợp lệ
của các cấu trúc lặp.[2]
Vòng lặp đơn
Vòng lặp
lồng nhau
Vòng
lặp nối nhau
Hình 1.2. Các kiểu vòng lặp
13
Vòng
lặp phi cấu
trúc
1.4.2. Kiểm thử hộp đen – Black box testing
Kỹ thuật kiểm thử hộp đen còn được gọi là kiểm thử hướng dữ liệu (data-driven)
hay là kiểm thử hướng vào/ra (input/output driven).
Trong kỹ thuật này, người kiểm thử xem phần mềm như là một hộp đen. Người kiểm
thử hoàn toàn không quan tâm cấu trúc và hành vi bên trong của phần mềm, chỉ cần
quan tâm đến việc tìm các hiện tượng mà phần mềm không thực hiện theo đúng đặc tả
của nó. Vì thế, dữ liệu kiểm thử sẽ xuất phát từ đặc tả.
Kiểm thử hộp đen cố gắng tìm các loại lỗi sau:
-
Các chức năng thiếu hoặc không đúng.
-
Các lỗi giao diện.
-
Các lỗi cấu trúc dữ liệu trong truy cập cơ sở dữ liệu bên ngoài.
-
Các lỗi thi hành.
-
Các lỗi khởi tạo hoặc kết thúc.
-
Và các lỗi khác…
Trong phương pháp kiểm thử hộp đen, ta đi vào tìm hiểu các kỹ thuật kiểm thử hộp
đen thường được sử dụng trong thực tế:
-
Phân vùng tương đương – Equivalence partitioning
-
Phân tích giá trị biên – Boundary value analysis
-
Kỹ thuật đồ thị nhân - quả - Cause-Effect Graph
-
Kiểm thử so sánh
-
Kiểm thử đoán lỗi – Error guesting testing
1.4.2.1.
Phân vùng tương đương
Như đã trình bày, chúng ta không thể kiểm tra tất cả các giá trị đầu vào của
chương trình. Vì thế, khi kiểm thử chương trình, 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ệ kiểm thử
một giá trị bất kỳ trong cùng lớp.
14
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. Vấn đề thứ hai được sử dụng để phát triển một tập các điều
kiện cần quan tâm phải được kiểm thử. Vấn đề thứ nhất được sử dụng để phát triển
một tập cực tiểu các trường hợp kiểm thử phủ các điều kiện trên.
Thiết kế trường hợp kiểm thử bằng phân hoạch tương đương được xử lý theo hai bước:
phân hoạch các miền đầu vào/ra thành các lớp tương đương, và thiết kế các trường hợp
kiểm thử đại diện cho mỗi lớp.
Phân tích giá trị biên (BVA – Boundary Value Analysis)
1.4.2.2.
Khi thực hiện việc kiểm thử phần mềm theo dữ liệu, chúng ta kiểm tra xem đầu
vào của người dùng, kết quả nhận được và kết quả tạm thời bên trong có được xử lý
chính xác hay không.
Các điều kiện biên là giá trị trực tiếp ở phía trên và dưới của các lớp tương đương đầu
vào và lớp tương đương đầu ra. Việc phân tích các giá trị biên khác với phân lớp tương
đương theo hai điểm:
-
Từ mỗi lớp tương đương, phân hoạch tương đương sẽ chọn phần tử bất kỳ
làm phần tử đại diện, trong khi việc phân tích giá trị biên sử dụng một
hoặc một số phần tử. Như vậy, mỗi biên của lớp tương đương chính là
đích kiểm thử.
-
Không chỉ chú ý tập trung vào những điều kiện đầu vào, các trường hợp
kiểm thử cũng được suy ra từ việc xem xét các kết quả ra (tức các lớp
tương đương đầu ra).
Rất khó có thể có thể liệt kê hết các hướng dẫn cụ thể cho các trường hợp. Tuy nhiên,
cũng có một số nguyên tắc phân tích giá trị biên như sau:
1. Nếu điều kiện đầu vào xác định một khoảng giá trị giữa a và b, các trường
hợp kiểm thử sẽ được thiết kế với giá trị a và b, và các giá trị cận trên và cận
dưới a và b.
2. Nếu một điều kiện đầu vào xác định một số các giá trị, các trường hợp kiểm
thử sẽ được phát triển để thực hiện tại các giá trị cực đại, cực tiểu. Các giá trị
cận trên và cận dưới, giá trị cực đại, cực tiểu cũng được kiểm thử.
3. Nguyên tắc 1 và 2 được áp dụng cho các điều kiện đầu ra.
15
4. Nếu cấu trúc dữ liệu chương trình bên trong được qui định các biên (chẳng
hạn, mảng được định nghĩa giới hạn 100 mục), tập trung thiết kế trường hợp
kiểm thử để thực thi cấu trúc dữ liệu tại biên của nó.
Ngoài ra, người kiểm thử có thể sử dụng sự xét đoán và sáng tạo của mình để tìm các
điều kiện biên.
Tóm lại, chúng ta phải kiểm thử mỗi biên của một lớp tương đương về tất cả các phía.
Một chương trình nếu vượt qua những trường hợp kiểm thử đó có thể vượt qua các
kiểm thử khác từ lớp đó.
Kỹ thuật đồ thị nhân - quả (Cause-Effect Graph)
1.4.2.3.
Đồ thị nhân - quả 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) 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:
1.4.2.4.
-
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 (các đầu vào) và các kết quả (các đầ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.
Kiểm thử so sánh
Có một số trường hợp (như điện tử máy bay, điều khiển thiết bị năng lượng hạt
nhân) trong đó độ tin cậy của phần mềm là tuyệt đối quan trọng, người ta thường gọi là
phần mềm tuyệt đối đúng. Trong các ứng dụng như vậy phần cứng và phần mềm
không cần thiết thường được sử dụng để tối thiểu khả năng lỗi. Khi phần mềm không
cần thiết được phát triển, các nhóm công nghệ phần mềm riêng biệt phát triển các
phiên bản độc lập của ứng dụng sử dụng cùng một đặc tả. Trong các trường hợp như
vậy, mỗi phiên bản có thể được kiểm thử với cùng dữ liệu kiểm thử để đảm bảo rằng
tất cả cung cấp đầu ra y như nhau. Sau đó tất cả các phiên bản được thực thi song song
với so sánh thời gian thực các kết quả để đảm bảo tính chắc chắn. Các phiên bản độc
16
- Xem thêm -