Cải tiến và ứng dụng công cụ kiểm thử ranorex trong các dự án phần mềm
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 (29.45 MB, 103 trang )
ĐẠI HỌC ĐÀ NẴNG
TRƯỜNG ĐẠI HỌC BÁCH KHOA
LÊ THỊ KIM CHUNG
LÊ THỊ KIM CHUNG
CẢI TIẾN VÀ ỨNG DỤNG CÔNG CỤ KIỂM THỬ
*
RANOREX TRONG CÁC DỰ ÁN PHẦN MỀM
KHOA HỌC MÁY TÍNH
LUẬN VĂN THẠC SĨ KHOA HỌC
CHUYÊN NGÀNH KHOA HỌC MÁY TÍNH
*
KHÓA K32
Đà Nẵng - 2017
ĐẠI HỌC ĐÀ NẴNG
TRƯỜNG ĐẠI HỌC BÁCH KHOA
--------------------------------
LÊ THỊ KIM CHUNG
CẢI TIẾN VÀ ỨNG DỤNG CÔNG CỤ KIỂM THỬ RANOREX
TRONG CÁC DỰ ÁN PHẦN MỀM
Chuyên ngành: Khoa học máy tính
Mã số: 60.48.01.01
LUẬN VĂN THẠC SĨ KỸ THUẬT
Người hướng dẫn khoa học:
PGS. TS. Nguyễn Thanh Bình
ĐÀ NẴNG - 2017
i
LỜI CAM ĐOAN
Tôi xin cam đoan:
- Luận văn này là công trình nghiên cứu thực sự của cá nhân, được thực hiện
dưới sự hướng dẫn khoa học của PGS. TS. Nguyễn Thanh Bình.
- Mọi tham khảo dùng trong luận văn đều được trích dẫn rõ ràng tên tác giả,
thời gian.
- Những sao chép không hợp lệ, vi phạm quy chế đào tạo, hay gian trá, tôi xin
chịu hoàn toàn trách nhiệm.
Đà Nẵng, tháng 11 năm 2017
Tác giả
LÊ THỊ KIM CHUNG
ii
LỜI CẢM ƠN
Tôi xin chân thành cảm ơn các Thầy cô trong khoa Công nghệ thông tin nói
riêng cũng như các Thầy cô giảng dạy trong trường Đại học Đà Nẵng nói chung đã
truyền đạt những kiến thức quý báu, hướng dẫn tận tình cho tôi trong những năm học
tập và nghiên cứu tại trường.
Đặc biệt, tôi xin chân thành cảm ơn Thầy Nguyễn Thanh Bình, trưởng khoa
Khoa Công nghệ thông tin, trường Đại học Bách Khoa Đà Nẵng đã tận tình hướng
dẫn, động viên và giúp đỡ tôi trong suốt thời gian nghiên cứu và thực hiện luận văn.
Và để có được kết quả này, tôi rất biết ơn gia đình đã động viên, khích lệ, cũng
như hỗ trợ, tạo điều kiện thuận lợi nhất trong suốt quá trình học tập và thực hiện luận
văn này.
Tôi xin chân thành cảm ơn.
Đà Nẵng, tháng 11 năm 2017
Tác giả
LÊ THỊ KIM CHUNG
iii
MỤC LỤC
LỜI CAM ĐOAN ............................................................................................................ I
LỜI CẢM ƠN ................................................................................................................. II
MỤC LỤC .....................................................................................................................III
DANH MỤC CÁC KÝ HIỆU, CHỮ VIẾT TẮT ........................................................ VI
DANH MỤC HÌNH ẢNH .......................................................................................... VIII
DANH MỤC BẢNG .................................................................................................... IX
MỞ ĐẦU .........................................................................................................................1
1. LÝ DO CHỌN ĐỀ TÀI ...............................................................................................1
2. MỤC ĐÍCH VÀ Ý NGHĨA ĐỀ TÀI ...........................................................................2
3. MỤC TIÊU VÀ NHIỆM VỤ ......................................................................................2
4. ĐỐI TƯỢNG VÀ PHẠM VI NGHIÊN CỨU ............................................................3
5. PHƯƠNG PHÁP NGHIÊN CỨU ...............................................................................3
6. PHƯƠNG TIỆN, CÔNG CỤ TRIỂN KHAI ..............................................................3
7. BỐ CỤC CỦA LUẬN VĂN .......................................................................................3
CHƯƠNG 1: CƠ SỞ LÝ THUYẾT .............................................................................5
1.1. LỖI PHẦN MỀM .....................................................................................................6
1.1.1.
Các nguyên nhân gây lỗi phần mềm ..................................................................5
1.2. CHI PHÍ SỬA LỖI ...................................................................................................6
1.2.1.
Qui trình xử lý lỗi phần mềm .............................................................................6
1.3. KIỂM THỬ PHẦN MỀM ........................................................................................7
1.3.1.
Khái niệm ...........................................................................................................7
1.3.2.
Kỹ thuật kiểm thử phần mềm.............................................................................7
1.3.2.1.
Kỹ thuật kiểm thử hộp đen .............................................................................8
1.3.2.2.
Kỹ thuật kiểm thử hộp trắng .........................................................................10
1.3.3.
Các giai đoạn kiểm thử phần mềm ..................................................................12
1.3.3.1.
Kiểm thử đơn vị ............................................................................................12
1.3.3.2.
Kiểm thử tích hợp .........................................................................................13
1.3.3.3.
Kiểm thử hệ thống ........................................................................................15
1.3.3.4.
Kiểm thử chấp nhận ......................................................................................15
1.4. TỔNG KẾT ............................................................................................................16
iv
CHƯƠNG 2: KIỂM THỬ TỰ ĐỘNG VÀ CÁC CÔNG CỤ KIỂM THỬ TỰ
ĐỘNG ...........................................................................................................................17
2.1. KHÁI QUÁT VỀ KIỂM THỬ TỰ ĐỘNG ............................................................17
2.1.1.
Kiểm thử tự động .............................................................................................17
2.1.2.
Quy trình kiểm thử tự động..............................................................................19
2.1.3.
So sánh kiểm thử thủ công và kiểm thử tự động .............................................19
2.2. CÁC LOẠI KIỂM THỬ TỰ ĐỘNG......................................................................20
2.2.1.
Kiểm thử tự động dựa trên dữ liệu (data-driven) .............................................20
2.2.2.
Kiểm thử tự động dựa trên từ khóa ..................................................................22
2.3 CÁC CÔNG CỤ KIỂM THỬ TỰ ĐỘNG ..............................................................24
2.3.1.Selenium ...............................................................................................................24
2.3.2.HP Quick Test Pro (QTP) hoặc HPE Unified Functional Testing (UFT) ............25
2.3.3. Ranorex ................................................................................................................26
2.4 TỔNG KẾT .............................................................................................................28
CHƯƠNG 3: KIỂM THỬ TỰ ĐỘNG VỚI RANOREXVÀ ĐỀ XUẤT GIẢI
PHÁP CẢI TIẾN .........................................................................................................29
3.1. CÔNG CỤ KIỂM THỬ RANOREX .....................................................................29
3.1.1.Đặc điểm Ranorex ................................................................................................29
3.1.2.Giới thiệu Ranorex ...............................................................................................30
3.1.3.Ưu và nhược điểm của Ranorex ...........................................................................33
3.2. ĐỀ XUẤT GIẢI PHÁP CẢI TIẾN ........................................................................34
3.2.1.Đề xuất giải pháp ..................................................................................................34
3.2.2.Giới thiệu các công cụ hỗ trợ ...............................................................................36
3.2.2.1 TortoiseGit .........................................................................................................37
3.2.2.2 Jira .....................................................................................................................38
3.3. CHI TIẾT GIẢI PHÁP CẢI TIẾN .........................................................................38
3.3.1 Xây dựng qui trình tổng thể tích hợp TortoiseGit và Jira vào Ranorex ...............38
3.3.1.1 Tích hợp TortoiseGit vào Ranorex ....................................................................40
3.3.1.2 Tích hợp Jira vào Ranorex.................................................................................41
3.4. THỬ NGHIỆM .......................................................................................................43
3.4.1 Ứng dụng công cụ Ranorex để kiểm thử phần mềm KeePass .............................43
v
3.4.2 Ứng dụng công cụ Ranorex để kiểm thử phần mềm Bán vé máy bay .................59
3.5. PHÂN TÍCH HIỆU QUẢ CẢI TIẾN .....................................................................60
3.5.1. So sánh độ hiệu quả so với kiểm thử bằng tay ....................................................60
3.5.2. So sánh độ hiệu quả khi tích hợp Ranorex với TortoiseGit và Jira .....................61
3.6.TỔNG KẾT .............................................................................................................61
KẾT LUẬN ..................................................................................................................62
1. Kết quả đạt được ........................................................................................................62
2. Hạn chế ......................................................................................................................62
3. Hướng phát triển ........................................................................................................62
TÀI LIỆU THAM KHẢO
PHỤ LỤC
vi
CẢI TIẾN VÀ ỨNG DỤNG CÔNG CỤ KIỂM THỬ RANOREX
TRONG CÁC DỰ ÁN PHẦN MỀM
Học viên: Lê Thị Kim Chung
Chuyên ngành: Khoa học máy tính
Mã số: ………Khóa: K32
Trường Đại học Bách khoa - ĐHĐN
Tóm tắt – Sự yêu cầu nghiêm ngặt về chất lượng phần mềm làm gia tăng nhu cầu về kiểm
thử phần mềm. Việc kéo dài thời gian thực hiện kiểm thử hoặc thuê thêm kiểm thử viên không phải
là phương pháp lâu dài và hiệu quả, thay vào đó cần phải tăng năng suất cũng như giảm số lượng
nhân lực một cách hiệu quả. Một giải pháp tối ưu cho vấn đề này là kiểm thử tự động. Luận văn
thạc sĩ này xin giới thiệu về kiểm thử tự động, công cụ kiểm thử tự động Ranorex, và các công cụ
hỗ trợ kiểm thử tự động khác. Đồng thời phân tích những hạn chế của công cụ và một số phương
pháp cải tiến kỹ thuật kiểm thử tự động dùng công cụ Ranorex. Từ đó, đề xuất một quy trình kiểm
thử tự động mới. Kết quả của luận văn có thể được sử dụng như tài liệu nghiên cứu cho các bạn sinh
viên cũng như áp dụng vào các quy trình kiểm thử của các công ty phát triển phần mềm. Tác giả đã
tóm tắt các kết quả đạt được và đưa ra các hướng phát triển tiếp theo.
Từ khóa – Kiểm thử tự động hướng dữ liệu; kiểm thử tự động hướng từ khóa; Ranorex;
Tortoise Git; Jira.
IMPROVING AND APPLYING RANOREX AUTOMATION TESTING
TOOL FOR SOFTWARE TESTING
Abstract - The growing importance and stringent quality requirements of software systems
are increasing demand for efficient software testing. Hiring more test engineers or lengthening the
testing time are not viable long-term solutions, rather there is a need to decrease the amount of
resources needed. One attractive solution to this problem is test automation. This master’s thesis
presents the automation testing, an automation tool is Ranorex and tools to support automation
testing process, its limitations and some methods for improvement are also analyzed. Then, a new
process for applying automation testing is proposed. This approach can be applied for students and
to testing processes of software development companies. The achieved results are summarized and
perspective of the work is provided.
Key words – Data driven; Keyword driven; Ranorex; TortoiseGit; Jira
vii
DANH MỤC CÁC KÝ HIỆU, CHỮ VIẾT TẮT
MTM
Microsoft Test Manager
API
Application Programming Interface
UT
Unit Testing
IT
Integration Testing
ST
System Testing
AT
Acceptance Testing
UAT
User Acceptance Testing
OAT
Operational Acceptance Testing
CSV
Comma-Separated Values
SCM
Software Configuration Management
QTP
Quick Test Professional
LINQ
Language Integrated Query
viii
DANH MỤC HÌNH ẢNH
Số hiệu
hình
Tên hình
Trang
1.1
Chi phí cho việc sửa lỗi phần mềm
6
1.2
Các trạng thái của lỗi
6
1.3
Lược đồ của chương trình
11
1.4
Kiểm thử tích hợp từ trên xuống
13
1.5
Kiểm thử tích hợp từ dưới lên
14
1.6
Kiểm thử tích hợp Big Bang
14
2.1
Các mức kiểm thử tự động
17
2.2
Kéo và thả từ khóa được định nghĩa
22
2.3
Tham chiếu đến tệp DLL của thư viện
23
2.4
Sử dụng một từ khóa đã định nghĩa
23
3.1
Khung nhìn chính của Ranorex Studio
30
3.2
Mô hình cải tiến tổng thể
35
3.3
Quy trình tích hợp chi tiết
39
3.4
Quy trình tích hợp TortoiseGit vào Ranorex
40
3.5
Quy trình tích hợp Jira vào Ranorex
41
3.6
Màn hình thực hiện kiểm thử (Add Entry)
44
3.7
Màn hình chính chứa các kịch bản thử sau khi được tạo
47
3.8
Kịch bản kiểm thử cho ca kiểm thử Add Entry 002
52
3.9
Kịch bản kiểm thử cho ca kiểm thử Add Entry 003
52
3.10
Kịch bản kiểm thử cho ca kiểm thử Add Entry 004
53
3.11
Chức năng tìm kiếm chuyến bay
58
3.12
So sánh thời gian thực thi
59
ix
DANH MỤC BẢNG
Số hiệu
Tên bảng
bảng
Trang
1.1
Giải thích trạng thái lỗi
6
1.2
Phân vùng tương đương
8
1.3
Giá trị biên
8
1.4
Qui tắc bảng quyết định
9
1.5
Ví dụ bảng quyết định
9
2.1
Các bước thực hiện kiểm thử tự động
19
2.2
So sánh kiểm thử thủ công và kiểm thử tự động
20
2.3
So sánh công cụ QTP, Selenium và Ranorex
27
3.2
Các thành phần của một dự án Ranorex
30
3.3
Các các đoạn mã tiêu chuẩn
42
3.4
Tài liệu mô tả yêu cầu
44
3.5
Ca kiểm thử
45
3.6
3.7
Cách tạo kịch bản theo hướng tiếp cận Kiểm thử tự động dựa
trên dữ liệu
Cách tạo kịch bản theo hướng tiếp cận Kiểm thử tự động dựa
trên từ khóa
49
52
1
MỞ ĐẦU
1. Lý do chọn đề tài
Phần mềm hiện nay được sử dụng rộng rãi trong đời sống, công việc, nhiều lĩnh
vực khoa học, kinh tế và xã hội. Vì vậy, việc đảm bảo rằng phần mềm đáp ứng mong
muốn của người sử dụng là rất quan trọng. Kiểm thử phần mềm là một trong những
hoạt động cơ bản nhằm đảm bảo chất lượng phần mềm [11].
Chi phí kiểm thử rất lớn, chiếm khoảng 40% tổng chi phí cho một dự án phát
triển phần mềm. Nhiều nghiên cứu về các kĩ thuật, giải pháp và quy trình nhằm giảm
chi phí và thời gian kiểm thử. Trong đó, kiểm thử tự động được xem là một trong
những giải pháp hiệu quả [10]. Ngoài ra, nhờ độ ổn định cao kiểm thử tự động có thể
thực thi các ca kiểm thử với độ chính xác cao hơn. Giải phóng con người khỏi các
công việc lặp đi lặp lại nhàm chán và không cần thiết. Đặc biệt, với sự giúp đỡ của
công cụ kiểm thử tự động, các công việc trước đây con người không thể thực hiện
được như: Load test, Performance test đã được giải quyết.
Hiện nay có nhiều công cụ được phát triển nhằm giúp cho các kĩ sư tự động hóa
quy trình kiểm thử phổ biến như: QuickTest Professional, Win Runner, Jtest,
Ranorex… Trong số đó, Ranorex khá tốt và mạnh, bao gồm nhiều chức năng điển hình
của một công cụ kiểm thử tự động. Nó có thể thực thi kiểm thử chức năng và phi chức
năng trên môi trường Win và Web. Kiểm thử mobile trên các hệ điều hành Android,
iOS. Cho phép người sử dụng viết mã nguồn dựa trên ngôn ngữ C# và VB.Net.
Trong kiểm thử tự động, một thử thách đặt ra đối với các kiểm thử viên chính là
việc quản lý phiên bản của kịch bản kiểm thử, tương ứng với phiên bản của phần mềm,
cũng như quản lý, tổng hợp mã nguồn khi thực hiện làm việc nhóm. Các khó khăn này
được giải quyết thông qua bộ đôi công cụ TortoiseGit và GitHud. Bên cạnh đó, kết quả
của việc kiểm thử chính là phát hiện ra các lỗi sai trong phần mềm. Vậy các lỗi sai đó
được quản lý như thế nào? Tất nhiên sẽ có một công cụ hữu hiệu để làm việc này, mà
điển hình là Jira. Ta thấy công cụ thực hiện kiểm thử tự động, công cụ quản lý mã
nguồn, công cụ quản lý lỗi, các công cụ này có mối quan hệ qua lại, thường xuyên
được sử dụng. Tuy nhiên nó lại là 3 công cụ riêng biệt, không có sự liên kết về quy
trình, tốn nhiều thời gian nếu sử dụng riêng.
2
Nhằm mục đích nâng cao khả năng sử dụng đối với công cụ Ranorex, tối ưu
hóa quy trình tự động và về mặt thời gian, tôi đề xuất chọn đề tài luận văn cao học:
“Cải tiến và ứng dụng công cụ kiểm thử Ranorex trong các dự án phần mềm”
2. Mục đích và ý nghĩa đề tài
Mục đích
Ý nghĩa khoa học
- Tìm hiểu và vận dụng tốt các tính năng của công cụ kiểm thử tự động
Ranorex.
- Nghiên cứu công cụ hỗ trợ kiểm thử tự động TortoiseGit, Jira
- Đề xuất phương án tích hợp TortoiseGit, Jira vào Ranorex để tối ưu quy trình
kiểm thử tự động.
- Kết quả có thể làm tài liệu tham khảo cho các kiểm thử viên, các đơn vị phát
triển phần mềm, hoặc các học viên – sinh viên trong việc nghiên cứu kiểm thử phần
mềm tự động.
Ý nghĩa thực tiễn
Tích hợp các công cụ hỗ trợ trong việc kiểm thử tự động vào công cụ Ranorex.
Thiết kế bộ kịch bản kiểm thử và thực thi kiểm thử tự động cho phần mềm cụ
thể.
3. Mục tiêu và nhiệm vụ
Mục tiêu
Mục tiêu chính của đề tài là cải tiến công cụ Ranorex và viết bộ kịch bản kiểm
thử để thực hiện kiểm thử cho phần mềm cụ thể. Để thoả mãn mục tiêu này thì cần đạt
được những mục tiêu cụ thể sau:
- Nắm vững cách sử dụng công cụ TortoiseGit, Jira
- Nghiên cứu và xây dựng bộ kịch bản kiểm thử bằng công cụ Ranorex.
- Cải tiến công cụ Ranorex.
Nhiệm vụ
Để đạt được những mục tiêu trên thì nhiệm vụ đặt ra của đề tài là:
- Nghiên cứu về kiểm thử tự động
- Nghiên cứu về ngôn ngữ lập trình C#
3
- Công cụ TortoiseGit
- Phần mềm Jira
- Cải tiến và ứng dụng công cụ Ranorex để thiết kế kịch bản kiểm thử cho phần
mềm cụ thể.
- Đánh giá kết quả theo yêu cầu của đề tài.
4. Đối tượng và phạm vi nghiên cứu
Trong khuôn khổ của luận văn thuộc loại nghiên cứu và ứng dụng, tôi chỉ giới
hạn nghiên cứu các vấn đề sau:
Kiểm thử tự động.
Công cụ TortoiseGit
Phần mềm Jira
Công cụ Ranorex.
5. Phương pháp nghiên cứu
Phương pháp lý thuyết
Tiến hành thu thập và nghiên cứu các tài liệu có liên quan đến đề tài.
Nghiên cứu lý thuyết kiểm thử phần mềm nói chung và kỹ thuật kiểm thử tự
động nói riêng.
Cải tiến cộng cụ và cách thiết kế các kịch bản kiểm thử trong Ranorex.
Phương pháp thực nghiệm
Nghiên cứu và khai thác công cụ phần mềm Ranorex.
Cài đặt chương trình phần mềm cụ thể để thực hiện viết kịch bản kiểm thử.
Kiểm tra, thử nghiệm, nhận xét và đánh giá kết quả.
6. Phương tiện, công cụ triển khai
Môi trường Microsoft Visual C#.
Công cụ TortoiseGit
Phần mềm Jira
Phần mềm KeePass
Công cụ Ranorex.
7. Bố cục của luận văn
Luận văn được trình bày gồm những phần chính như sau:
4
Chương 1. Cơ sở lý thuyết
Chương này đã giới thiệu tổng quan về lỗi phần mềm, kiểm thử phần mềm, các
giai đoạn kiểm thử. Trong đó có nêu ra các kỹ thuật kiểm thử phần mềm, cũng như ưu
và nhược điểm của từng loại kỹ thuật.
Chương 2. Kiểm thử tự động và công cụ hỗ trợ
Các vấn đề về kiểm thử tự động, ưu điểm và nhược điểm của nó được giới thiệu
trong chương này. Cùng với đó là sự khác nhau của 2 cách tiếp cận: kiểm thử tự động
dựa trên dữ liệu và kiểm thử tự động dựa trên từ khóa. Một phần quan trọng là giới
thiệu về 2 công cụ kiểm thử tự động khá phổ biến hiện nay. Một công cụ mã nguồn mở
là Selenium, và một công cụ thương mại là QTP.
Chương 3. Kiểm thử tự động với Ranorex và đề xuất giải pháp cải tiến
Chi tiết về công cụ kiểm thử tự động Ranorex sẽ được giới thiệu, cùng với các
ưu điểm cũng như hạn chế. Việc kiểm thử có nhiều công việc khác nhau, đễ hỗ trợ cho
kiểm thử viên, đã có rất nhiều công cụ ra đời. Chương này sẽ tìm hiểu về các công cụ
hỗ trợ kiểm thử tự động và cách tích hợp chúng vào Ranorex.
Kết luận và hướng phát triển
5
CHƯƠNG 1: CƠ SỞ LÝ THUYẾT
Chương này giới thiệu các khái niệm về lỗi phần mềm, các kĩ thuật và giai đoạn
kiểm thử phần mềm. Từ đó cung cấp cái nhìn tổng quan về việc kiểm thử phần mềm.
1.1. LỖI PHẦN MỀM
Định nghĩa lỗi phần mềm: Có rất nhiều định nghĩa về lỗi phần mềm nhưng có
thể hiểu và phát biểu một cách đơn giản thì "Lỗi phần mềm là sự không khớp giữa
chương trình và đặc tả của nó"[4].
Dựa vào định nghĩa, ta có thể phân loại lỗi phần mềm thành 3 dạng:
Lỗi sai: Sản phẩm phần mềm được xây dựng khác với đặc tả.
Lỗi thiếu: Các yêu cầu của sản phẩm phần mềm đã có trong đặc tả nhưng lại
không có trong sản phẩm thực tế.
Lỗi thừa: Sản phẩm thực tế có những tính năng không có trong tài liệu đặc tả.
Ngoài lỗi về việc không khớp giữa chương trình và đặc tả thì còn có các lỗi
không phải chức năng như:
Màu sắc, vị trí bố trí trên màn hình không thuận tiện cho người sử dụng.
Các lỗi hiệu năng như khi thực hiện tìm kiếm hoặc đăng ký dữ liệu... thời gian
chờ quá lâu.
Lỗi về chịu tải như chương trình chỉ có thể chịu tải được 100 lượt người truy
cập cùng lúc, nếu vượt quá thì chương trình không hoạt động được.
1.1.1. Các nguyên nhân gây lỗi phần mềm
Lỗi phần mềm có thể đến từ nhiều nguyên nhân khác nhau, trong đó có cả các
nguyên nhân chủ quan và các nguyên nhân khách quan: Các lỗi lập trình và lỗi do tài
liệu yêu cầu.
Ngoài 2 nguyên nhân trên còn có các nguyên nhân khác:
Các lỗi trong giao tiếp giữa khách hàng và nhà phát triển
Sai lệch có chủ ý với các yêu cầu phần mềm
Không tuân thủ theo các tài liệu hướng dẫn và tiêu chuẩn lập trình
Thiếu sót trong quá trình kiểm thử
6
1.2. CHI PHÍ SỬA LỖI
Việc kiểm thử và sửa lỗi phần mềm có thể thực hiện trong bất cứ giai đoạn nào
của vòng đời phần mềm. Tuy nhiên công việc này nên được thực hiện càng sớm càng
tốt vì càng về giai đoạn sau của vòng đời phần mềm, chi phí cho việc tìm và sửa lỗi
càng tăng, đặc biệt là đến giai đoạn đã triển khai phần mềm thì chi phí cho sửa lỗi sẽ
trở nên rất lớn và ảnh hưởng trực tiếp đến uy tín của tổ chức phát triển phần mềm.
Theo tài liệu của Boehm, chi phí cho việc tìm và sửa lỗi phần mềm sẽ tăng theo
hàm mũ trong biểu đồ hình 1.1[1]:
Hình 1.1 Chi phí cho việc sửa lỗi phần mềm
1.2.1. Qui trình xử lý lỗi phần mềm
Trước khi giới thiệu về qui trình xử lý lỗi phần mềm, hình 1.2 sẽ trình bày về các
trạng thái có thể có của lỗi [18].
Hình 1.2 Các trạng thái của lỗi
7
Trong đó có các trạng thái lỗi như bảng 1.1:
Bảng 1.1 Giải thích trạng thái lỗi
Mới
Lỗi mới tạo, chưa được lưu
Mở
Lỗi mới tạo, sau khi được lưu
Đã chỉ định
Lỗi đã được gán cho nhân viên phát triển
Đã sửa
Lỗi đã được sửa xong bởi nhân viên phát triển
Không chấp nhận
Lỗi sau khi tạo, được xác định là không phải lỗi
Hoãn lại
Lỗi không thuộc phạm vi của dự án, hoặc sẽ được xử lý trong
một giai đoạn khác của dự án
Mở lại
Lỗi được xử lý, nhưng sau khi kiểm tra lại thì vẫn chưa đúng.
Đã xác nhận
Lỗi đã được sửa, và kiểm tra lại đúng.
Đóng
Trạng thái đóng. Lỗi đã được sửa và kiểm tra lại thành công.
1.3. KIỂM THỬ PHẦN MỀM
1.3.1. Khái niệ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. Mục đích của kiểm thử phần mềm là tìm ra lỗi chưa được phát hiện, tìm
một cách sớm nhất và bảo đảm rằng lỗi sẽ được sửa.
Mục tiêu của kiểm thử phần mềm là thiết kế tài liệu kiểm thử một cách có hệ
thống và thực hiện nó sao cho có hiệu quả, nhưng phải tiết kiệm được thời gian, công
sức và chi phí.
1.3.2. Kỹ thuật kiểm thử phần mềm
Mục tiêu của kiểm thử là phải thiết kế các ca kiểm thử có khả năng cao nhất
trong việc phát hiện nhiều lỗi với thời gian và công sức tối thiểu.
Có thể chia các kỹ thuật kiểm thử thành hai loại:
Kỹ thuật kiểm thử hộp đen: Hay còn gọi là kỹ thuật kiểm thử chức năng.
Kỹ thuật kiểm thử hộp trắng: Hay còn gọi là kỹ thuật kiểm thử cấu trúc.
8
1.3.2.1. Kỹ thuật kiểm thử hộp đen
Trong kỹ thuật này, người kiểm thử xem phần mềm như là một hộp đen hoàn
toàn không quan tâm đến cấu trúc và hành vi bên trong của chương trình, chỉ cần quan
tâm đến việc tìm các hiện tượng mà phần mềm không xử lý theo đúng đặc tả của nó.
Các kỹ thuật kiểm thử hộp đen:
Phân vùng tương đương
Xem xét về miền giá trị của dữ liệu đầu vào để chia thành các phạm vi tương
đương. Bao gồm cả miền dữ liệu không đúng.
Ví dụ: Tạo một thẻ ATM giới hạn từ 1.000.000 đến 50.000.000.
Các phân vùng tương đương có được:
Bảng 1.2 Phân vùng tương đương
Giá trị nhỏ hơn 1.000.000
Không hợp lệ
Giá trị giữa
1.000.000 và 50.000.000
Hợp lệ
Giá trị lớn hơn
50.000.000
Không hợp lệ
Phân tích giá trị biên
Chọn 1 hoặc nhiều phần tử tại mỗi biên của lớp tương đương. Suy dẫn các ca
kiểm thử từ giá trị biên.
Bảng 1.3 Giá trị biên
Cận dưới
+/-1
Tại biên
Cận trên
999.999, 1.000.001
1.000.000, 50.000.000
+/-1
49.999.999, 50.000.001
Bảng quyết định
Một yếu điểm của phân tích giá trị biên và phân lớp tương đương là chúng
không khảo sát sự kết hợp của các trường hợp đầu vào. Việc kiểm tra sự kết hợp đầu
vào không phải là một nhiệm vụ đơn giản bởi vì nếu phân lớp tương đương các trạng
thái đầu vào, thì số lượng sự kết hợp thường là rất lớn. Nếu chúng ta không có cách
lựa chọn có hệ thống một tập con các trạng thái đầu vào, có lẽ kết quả là một tập tùy
hứng các điều kiện, điều này có thể dẫn tới việc kiểm thử không có hiệu quả.
Các quy tắc trong bảng quyết định được mô tả như sau:
9
Bảng 1.4 Qui tắc bảng quyết định
Tên bảng: Cho biết tên logic
Qui tắc
Tên bảng
... n Qui tắc: Đánh số để phân biệt các qui tắc quyết
1
2
Điều kiện 1
Y
Y
Y định logic
Điều kiện 2
Y
-
Y Các dòng điều kiện: Mỗi dòng bao gồm các điều
Điều kiện 3
Y
-
N kiện để tạo quyết định cho chương trình
...
...
... Y: True
Điều kiện n
-
-
Y N: False
Hành động 1
X
X
X - : Không có quyết định được tạo ra
Hành động 2
-
X
X Các hành động: Mỗi dòng chỉ định có các xử lý
Hành động 3
X
-
X được thực hiện hoặc không
...
...
...
... X: Xử lý được thực hiện
Hành động n
...
...
X - : Không có xử lý được thực hiện
...
Ví dụ: Để tính thuế thu nhập, người ta có mô tả sau:
Người vô gia cư nộp 4% thuế thu nhập
Người có nhà ở nộp thuế như sau:
Tổng thu nhập <= 9.000.000. Thuế 4%
Tổng thu nhập >9.000.000. Thuế 6%
Ta có bảng quyết định như sau:
Bảng 1.5 Ví dụ bảng quyết định
& kết quả
Nguyên nhân
Trường hợp kiểm thử
1
2
3
4
1. Người có nhà ở
Y
Y
N
-
2. Có tổng thu nhập <= 9.000.000
N
Y
-
Y
3. Có tổng thu nhập > 9.000.000
Y
N
-
-
Nộp thuế 4%
-
X
X
X
Nộp thuế 6%
X
-
-
-
Đoán lỗi
Chủ yếu dựa vào kinh nghiệm, trực giác của kiểm thử viên, họ sử dụng kinh
nghiệm trong quá khứ, trong các dự án đã trải qua để tìm lỗi. Đoán lỗi không có quy
10
tắc, nó chỉ sử dụng các kỹ năng kiểm thử trước đó, có thể nghĩ đến các tình huống mà
phần mềm có thể bị bỏ qua.
1.3.2.2. Kỹ thuật kiểm thử hộp trắng
Là một chiến lược kiểm thử khác, trái ngược hoàn toàn với kiểm thử hộp đen,
kiểm thử hộp trắng cho phép khảo sát cấu trúc bên trong của phần mềm với mục đích
bảo đảm 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. Người
kiểm thử truy nhập vào mã nguồn chương trình và có thể kiểm tra nó, lấy đó làm cơ sở
để hỗ trợ việc kiểm thử.
Kiểm thử hộp trắng có nhiều kỹ thuật kiểm thử, nhưng luận văn sẽ lựa chọn
phân tích kĩ thuật đường cơ sở
Đường cơ sở hay còn gọi là đường diễn tiến của chương trình là tập hợp lệnh
được thực thi có thứ tự trong chương trình.
Các bước thực hiện:
Bước 1: Vẽ lược đồ của một chương trình hoặc hàm
Bước 2: Xác định độ phức tạp của lược đồ V(G)
Bước 3: Xác định tập đường cơ sở
Bước 4: Kiểm tra số đường cơ sở phải nhỏ hơn hoặc bằng độ phức tạp của lược đồ
V(G)
Bước 5: Xây dựng những ca kiểm thử dựa trên tập đường xác định ở bước trên
Độ phức tạp của lược đồ: Ký hiệu V(G)
Là số đo phần mềm cung cấp độ phức tạp về logic của một chương trình
Độ phức tạp được xác định theo 3 cách:
-
Số miền của lược đồ
-
Số nút xác nhận điều kiện + 1 (V(G) = P +1)
-
Số cạnh – Số nút + 2 (V(G) = E – N + 2)
Ví dụ kiểm thử cho đoạn code
void foo (float y, float *a, int n)
{
float x =y *n;
if (x>0.01)
z=tan(x);
11
else
z=cos(x);
for (int i = 0; i< MAX; ++i)
{
a[i] = a[i]*z;
[i];
}
}
Bước 1: Vẽ lược đồ, ta được kết quả:
Hình 1.3 Lược đồ của chương trình
Bước 2: Xác định độ phức tạp
Độ phức tạp = Số nút xác nhận điều kiện + 1 (V(G) = P +1)
= 2 + 1 (Nút 1 và nút 6 nhận điều kiện)
=3
Bước 3: Xác định số đường độc lập
Có tất cả 3 đường:
Đường 1
1-3-4-5-7
Đường 2
1-2-4-5-7
Đường 3
1-2-4-5-6-7
12
Bước 4: Kiểm tra: Ta thấy số đường cơ sở là 3, bằng độ phức tạp của lược đồ
V(G) =3
Bước 5: Tạo dữ liệu kiểm thử: Dựa vào đường cơ sở, ta tạo dữ liệu thử sao cho
mỗi đường cơ sở có một bộ dữ liệu tương ứng.
Qua ví dụ trên ta thấy: Kiểm thử hộp trắng có thể không đầy đủ vì kiểm thử hết
các lệnh không có nghĩa là chúng ta đã kiểm thử hết các trường hợp có thể xảy ra.
Ngoài ra chúng ta không thể kiểm thử hết các đường đi đối với các vòng lặp lớn.
1.3.3. Các giai đoạn kiểm thử phần mềm
Khi kiểm thử một sản phẩm phần mềm, chúng ta không chỉ kiểm thử một lần,
khi mà nó đã được hoàn thành. Các thành phần của phần mềm đều phải được kiểm thử
trước, sau đó trong suốt quá trình tích hợp các thành phần cũng phải được kiểm thử
cho đến khi đạt được sản phẩm cuối cùng [12].
Theo quá trình phát triển của phần mềm sẽ có 4 giai đoạn kiểm thử:
+ Kiểm thử đơn vị
+ Kiểm thử tích hợp
+ Kiểm thử hệ thống
+ Kiểm thử chấp nhận [10]
1.3.3.1. Kiểm thử đơn vị
Kiểm thử đơn vị là việc tìm kiếm các lỗi và kiểm chứng rằng chức năng của các
đoạn mã, chương trình, các lớp... của phần mềm đã được kiểm thử một cách riêng biệt.
Nó có thể được thực hiện độc lập, riêng biệt so với các thành phần khác của chương
trình, phụ thuộc vào ngữ cảnh của hệ thống và quá trình sản xuất phần mềm. Kiểm tra
đơn vị có thể bao gồm kiểm thử chức năng và phi chức năng, chẳng hạn như vị trí các
đối tượng trên màn hình, lỗi chính tả, hoặc kiểm tra mức chịu tải. Các ca kiểm thử sẽ
được viết dựa vào tài liệu mô tả chi tiết của thành phần, thiết kế phần mềm.
Trong thực tế, kiểm thử đơn vị thường do lập trình viên thực hiện. Nhiều lỗi
thông thường sẽ được sửa lỗi ngay khi họ phát hiện được, mà không cần theo dõi quản
lý các lỗi này.
13
1.3.3.2. Kiểm thử tích hợp
Trong khi kiểm thử đơn vị kiểm tra các thành phần và đơn vị riêng lẻ, thì kiểm
thử tích hợp kết hợp chúng lại với nhau và kiểm tra sự giao tiếp, tương tác giữa các
phần trong hệ thống. Có thể có nhiều hơn 1 mức kiểm thử tích hợp và có thể có kết
quả khác nhau dựa trên độ lớn của các mục tiêu kiểm thử khác nhau:
Kiểm thử tích hợp thành phần: Kiểm tra các tương tác giữa các thành phầncủa
phần mềm với các thành phần khác, được tiến hành sau khi thực hiện kiểm thử đơn vị.
Kiểm thử tích hợp hệ thống: Kiểm tra các 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 và có thể được tiến hành sau khi thực hiện
Kiểm thử hệ thống.
Tíchhợp từ trên xuống:
Xây dựng khung của hệ thống và đưa các thành phần cấp thấp vào trong nó.
Các đoạn mã kiểm thử chính được dùng như một bộ phận điều khiển kiểm thử và các
phần giả lập được thay thế vào cho tất cả các đoạn mã chưa được hoàn thành, phụ
thuộc trực tiếp vào các điều khiển chính. Khi hoàn thành từng tập các kiểm thử, các
phần giả lập được thay thế bằng các đoạn mã thực.
Hình 1.4 Kiểm thử tích hợp từ trên xuống
Ưu điểm:
-
Phát hiện sớm các lỗi thiết kế.
-
Có phiên bản hoạt động sớm.
Nhược điểm:
-
Khó có thể mô phỏng được các đoạn mã cấp thấp.
-
Mất thời gian tạo các phần giả lập
14
Tích hợp từ dưới lên:
Là quá trình tích hợp và kiểm thử các đoạn mã ở cấp thấp trước. Các đoạn mã
cấp thấp được tổ hợp vào các chùm thực hiện một chức năng cho phần mềm riêng
biệt.
Hình 1.5 Kiểm thử tích hợp từ dưới lên
Ưu điểm:
-
Tránh phải tạo các phần giả lập phức tạp hay tạo các kết quả nhân tạo.
Nhược điểm:
-
Phát hiện chậm các lỗi thiết kế
-
Chậm có phiên bản thực hiện được của hệ thống.
Tích hợp Big bang:
Một loại kiểm thử tích hợp có cách thực hiện là sử dụng các thành phần phần
mềm, phần cứng hoặc cả hai đều được kết hợp tất cả vào thành một khối hoặc một hệ
thống bao gồm toàn bộ tất cả các phần. Nếu tích hợp 20 chức năng lại với nhau và lỗi
xảy ra thì thời gian điều tra, sửa lỗi, thực hiện kiểm tra lại, chi phí sẽ lớn gấp nhiều lần
so với tích hợp tăng dần.
Hình 1.6 Kiểm thử tích hợp Big Bang
