Nghiên cứu công cụ kiểm thử IBM Rational Funtional Tester V7.0
Ứng dụng kiểm thử phần mềm tại trung tâm phát triển phần mềm Đại Học Duy Tân
MỤC LỤC
MỤC LỤC 1
DANH MỤC CÁC HÌNH VẼ 3
DANH MỤC CÁC KÍ HIỆU VÀ TỪ VIẾT TẮT 4
MỞ ĐẦU 5
1. Lý do chọn đề tài 5
2. Mục tiêu 6
3. Phạm vi nghiên cứu 6
4. Bố cục của đề tài 6
CHƯƠNG I. CƠ SỞ LÝ THUYẾT 8
I. TỔNG QUAN VỀ QUÁ TRÌNH KIỂM THỬ 8
I.1 Một số định nghĩa về quá trình kiểm thử phần mềm 8
I.2 Những khái niệm liên quan đến kiểm thử 9
I.3 Mô hình khái niệm của quá trình kiểm thử 10
I.4 Mục tiêu của kiểm thử 10
I.5 Vai trò 10
II. NHỮNG VẤN ĐỀ LIÊN QUAN ĐẾN KIỂM THỬ 11
II.1 Vòng đời kiểm thử 11
II.2 Tiến trình kiểm thử 11
II.3 Những thành phần của một kế hoạch kiểm thử 12
II.4 Những điểm cần tập trung kiểm thử trước nhất nếu không có đủ thời gian 12
II.5 Các chỉ tiêu đánh giá kiểm thử 13
III. MỘT SỐ LOẠI KIỂM THỬ THÔNG DỤNG 13
1.Mô hình phát triển chữ V 13
2 Kiểm thử unit 14
2.1 Tiến trình kiểm thử Unit 15
2.2 Kế hoạch kiểm thử unit 16
2.3 Kiểm thử hộp đen 16
2.4 Kiểm thử hộp trắng 16

số tài khoản của khách hàng và ta cũng kiểm tra được Khách hàng nào giao dịch với
công ty nhiều nhất để có thể thưởng cho khách hàng 44
3. Chức năng cập nhật 46
4.Chức năng xuất hàng 47
IV.2 THỰC HIỆN KIỂM THỬ VỚI CÔNG CỤ IBM RFT 49
Chức năng Login 49
2. Chức năng tra cứu 50
3. Chức năng cập nhật 55
4.Chức năng xuất hàng 59
5. Viết báo cáo 62
KẾT LUẬN 63
NHỮNG VẤN ĐỀ ĐẠT ĐƯỢC 63
ƯU ĐIỂM VÀ NHƯỢC ĐIỂM CỦA CÔNG CỤ 63
HƯỚNG PHÁT TRIỂN 65
PHỤ LỤC A 66
HƯỚNG DẤN CÀI ĐẶT IBM RATIONAL FUTIONAL TESTER 66
PHỤ LỤC B 83
THỰC HIỆN QUÁ TRÌNH KIỂM THỬ VỚI RATIONAL FUNTIONAL TESTER 83
SVTH: Đặng Thị Kiều Oanh- MSSV:0057
Trang 2
Nghiên cứu công cụ kiểm thử IBM Rational Funtional Tester V7.0
Ứng dụng kiểm thử phần mềm tại trung tâm phát triển phần mềm Đại Học Duy Tân
DANH MỤC CÁC HÌNH VẼ
H I.1: Mô hình khái niệm của quá trình kiểm thử

15
H II.1 The Software Development

14
H II.2 Quá trình bắt lỗi

phần mềm, đảm bảo rằng phần mềm tạo ra có chạy đúng với yêu cầu của khách
hàng hay không, có xảy ra những sai sót mà nó khác với bảng phân tích thiết kế
ban đầu không. Vì vây, năm 2006 IBM cho ra đời sản phẩm The 2007
developerWorks Software Evaluation Kit (SEK) for Windows, đây là một trong số
nhiều phần mềm dùng cho việc kiểm thử. SEK bao gồm 6 Tool và em lựa chọn
công cụ Rational Funtional Tester V7.0 để nghiên cứu cho đồ án tốt nghiệp. Đây
là công cụ kiểm thử chức năng của phần mềm, một dụng cụ kiểm thử hồi quy tiên
tiến, được tự động hóa cho Tester và người phát triển GUI.
Bất kỳ một tổ chức nào cũng có một sự tin cậy của riêng mình vào việc
phát triển của những trình ứng dụng để phục vụ cho những việc cần thiết như đáp
ứng được những chức năng của khách hàng đưa ra, để cho khách hàng tỏ ra hài
lòng về chất lượng của những trình ứng dụng và những đòi hỏi về những chức
năng, điều kiện được đáp ứng đầy đủ, và không xảy ra sự tuỳ tiện trong sản phẩm.
Một thành phần chủ yếu cho sự thành công này là tính hiệu quả, quy trình kiểm tra
phải có tính kỷ luật tiến tới sự xác minh của những trình ứng dụng đã hoàn thành,
quá trình kiểm tra phải có tính kỷ kuật để xem xét những trình ứng dụng đã hoàn
thành đến mức độ nào, đó là sự phù hợp thích đáng hay là vượt ra khỏi những
mong đợi trong đề án. Lịch trình làm việc không đúng, thường xuyên thay đổi
những vấn đề chung của trình ứng dụng. IBM Rational Funtional Tester được xây
dựng dựa trên những vấn đề này.
Sau khi nghiên cứu một số tài liệu liên quan, được sự đồng ý của Khoa
Công Nghệ Thông Tin – Đại Học Duy Tân Đà Nẵng, em đã thực hiện đề tài khóa
luận tốt nghiệp mang tên: “Nghiên cứu công cụ kiểm thử IBM Rational
SVTH: Đặng Thị Kiều Oanh- MSSV:0057
Trang 5
Nghiên cứu công cụ kiểm thử IBM Rational Funtional Tester V7.0
Ứng dụng kiểm thử phần mềm tại trung tâm phát triển phần mềm Đại Học Duy Tân
Funtional Tester V7.0- Ứng dụng kiểm thử phần mềm tại trung tâm phát triển
phần mềm Đại Học Duy Tân.”
2. Mục tiêu

người dùng có thể thực hiện một cách đơn giản.
Chương IV. Thực hiện kiểm thử trên một phần mềm có sẳn.
Trong chương này em tiến hành kiểm thử trên một phần mềm có sẳn để
khẳng định và chỉ ra những vấn đề mà em đã nêu ở chương III.
Kết thúc luận văn là phần kết luận về những vấn đề đạt được và hướng phát
triển của khóa luận và danh mục các tài liệu tham khảo
SVTH: Đặng Thị Kiều Oanh- MSSV:0057
Trang 7
Nghiên cứu công cụ kiểm thử IBM Rational Funtional Tester V7.0
Ứng dụng kiểm thử phần mềm tại trung tâm phát triển phần mềm Đại Học Duy Tân
CHƯƠNG I. CƠ SỞ LÝ THUYẾT
I. TỔNG QUAN VỀ QUÁ TRÌNH KIỂM THỬ
I.1 Một số định nghĩa về quá trình kiểm thử phần mềm
Kiểm thử là việc kiểm tra kết quả thực hiện của chương trình máy tính xem
có đúng với các mục tiêu đã đặt ra với nó không thông qua việc thực hiện ở một số
mẫu thử.
Kiểm thử là việc tìm ra những lỗi trong bản thân phần mềm, việc kiểm thử
này trong phần mềm sẽ biểu thị ra những thiếu sót mà ta có thể nhận thấy trong
hành vi của phần mềm, và tìm ra những phần không tuân theo quy định và đi lệch
ra khỏi những yêu cầu của phần mềm.
Theo một số nhà nghiên cứu thì kiểm thử phần mềm được định nghĩa như
sau:
• Dijkstra: Kiểm thử sẽ hiện thị những lỗi hiện có, nhưng không
hiển thị lỗi chưa thấy.
• Beizer:
Định luật 1: Mọi phương pháp bạn sử dụng để ngăn ngừa
hoặc tìm thấy lỗi bỏ đi một phần lỗi rắc rối, cái mà những phương
thức cần.
Định luật 2: Phần mềm phức tạp lớn hơn những giới hạn khả
năng quản lý.

 Kiểm thử viên(tester): Người thực hiện kiểm thử.
 Ca kiểm thử(test case):Tập dữ liệu kiểm thử, điều kiện kiểm thử,
để đưa ra kết quả mong đợi.
SVTH: Đặng Thị Kiều Oanh- MSSV:0057
Trang 9
Sai sót Lỗi Hỏng hóc
Nghiên cứu công cụ kiểm thử IBM Rational Funtional Tester V7.0
Ứng dụng kiểm thử phần mềm tại trung tâm phát triển phần mềm Đại Học Duy Tân
I.3 Mô hình khái niệm của quá trình kiểm thử
H I. 1: Mô hình khái niệm của quá trình kiểm thử
I.4 Mục tiêu của kiểm thử
Việc kiểm thử nhằm thực hiện hai mục tiêu:
• Bằng việc kiểm thử sẽ tìm ra được những lỗi trong phần mềm
(Myers,1979)và thiết lập chất lượng của phần mềm(Hetzel,1988)
• Việc kiểm thử thành công khi bạn tìm được ít nhất một lỗi, và
đưa ra sự đánh giá với độ tin cậy lớn.
I.5 Vai trò
• Testing để tìm ra lỗi, ghi nhận các thông tin về lỗi, nhưng không
sữa lỗi.
• Testing giúp kiểm định phần mềm, đảm bảo rằng phần mềm “đủ
tốt” với độ rủi ro “thấp nhất” có thể.
SVTH: Đặng Thị Kiều Oanh- MSSV:0057
Trang 10
Nghiên cứu công cụ kiểm thử IBM Rational Funtional Tester V7.0
Ứng dụng kiểm thử phần mềm tại trung tâm phát triển phần mềm Đại Học Duy Tân
II. NHỮNG VẤN ĐỀ LIÊN QUAN ĐẾN KIỂM THỬ
II.1 Vòng đời kiểm thử
Vòng đời của kiểm thử bắt đầu từ việc lập kế hoạch kiểm thử. Sau đó là ghi
ra các ý tưởng các trường hợp kiểm thử. Từ các trường hợp kiểm thử này đưa ra
tất cả các trường hợp kiểm thử và các kịch bản kiểm thử. Sử dụng các thủ tục hay

vi Test cho phù hợp với trình độ người Test, thời gian, chi phí.
Khi đưa ra phạm vi rồi thì làm tốt phạm vi đó thì coi như đạt yêu
cầu theo kế hoạch Test đưa ra.
 Các công việc cần thực hiện là đầu ra của kế hoạch kiểm thử:
o Nghiên cứu tài liêu dự án(phân tích, thiết kế), tìm hiểu
công cụ Test cho kiểu Test đã đặt ra.
o Thiết kế Test Case theo phạm vi Test.
o Thực hiện kiểm tra phần mềm theo nội dung Test Case
o Báo lỗi khi phát hiện được
o Viết báo cáo kết quả Test sau khi thực hiện xong
II.4 Những điểm cần tập trung kiểm thử trước nhất nếu không
có đủ thời gian.
 Những chức năng quan trọng nhất(mục đích) của dự án
 Những chức năng được người dùng xem nhiều nhất
 Những chức năng có thể ảnh hưởng nhiều nhất đến độ án toàn
 Những chức năng có thể ảnh hưởng nhiều nhất đến tài chính
SVTH: Đặng Thị Kiều Oanh- MSSV:0057
Trang 12
Nghiên cứu công cụ kiểm thử IBM Rational Funtional Tester V7.0
Ứng dụng kiểm thử phần mềm tại trung tâm phát triển phần mềm Đại Học Duy Tân
 Những phần quan trọng nhất đối với người dùng
 Những phần có thể kiểm thử sớm nhất trong chu trình phát triển
ứng dụng
 Những phần có Code phức tạp nhất
 Những phần được Code vội vả hoặc áp lực nhất
 Những phần tương tự hoặc liên quan những dự án trước và đã
gây lỗi
 Những phần tương tự hoặc liên quan những dự án trước và tốn
nhiều chi phí bảo trì
 Những phần mà yêu cầu và thiết kế không rõ ràng

2 Kiểm thử unit
Kiểm thử unit ứng dụng ở mức môđun. Thường là được thực hiện bởi nhà
phát triển trước khi các môđun được tích hợp với các mô đun khác .
SVTH: Đặng Thị Kiều Oanh- MSSV:0057
Trang 14
Nghiên cứu công cụ kiểm thử IBM Rational Funtional Tester V7.0
Ứng dụng kiểm thử phần mềm tại trung tâm phát triển phần mềm Đại Học Duy Tân
Kiểm thử unit là mức thấp nhất trong tiến trình kiểm thử, thường là áp dụng
phương pháp kiểm thử hộp trắng .
Kết quả của kiểm thử Unit thường tìm ra khoảng 20% lỗi trong tất cả cá lỗi
của dự án.
2.1 Tiến trình kiểm thử Unit
2.1.1 Kế hoạch kiểm thử Unit
Lập kế hoạch cho kiểm thử khác nhau (như kiểm thử hệ thống, kiểm
thử tích hợp). Quyết định xem đặc điểm nào cần phải kiểm thử. Các hướng tiếp
cận để kiểm thử unit
 Phương thức phân tích kiểm thử.
 Kĩ thuật kiểm thử (hộp đen hay hộp trắng).
 Các công cụ dùng trong kiểm thử.
2.1.2 Thiết kế kiểm thử
 Tạo các trường hợp kiểm thử
 Thiết kế các thủ tục kiểm thử:
• Thủ tục làm thế nào để thực thi một trường hợp kiểm
thử
• Một thủ tục có thể áp dụng cho một vài trường hợp
kiểm thử khác
 Triển khai chương trình kiểm thử:
• Kiểm thử gốc(stub): Kiểm thử lần lượt từ gốc của chương
trình, sau khi xong thì tiếp tục kiểm thử Stub tiếp theo ở bên
dưới.

• Các kĩ thuật thường dùng:
 Lược đồ nguyên nhân kết quả.
 Phân đoạn tương đương.
 Phân tích giá trị biên.
2.4 Kiểm thử hộp trắng
 Thực hiện bên trong chương trình.
SVTH: Đặng Thị Kiều Oanh- MSSV:0057
Trang 16
Nghiên cứu công cụ kiểm thử IBM Rational Funtional Tester V7.0
Ứng dụng kiểm thử phần mềm tại trung tâm phát triển phần mềm Đại Học Duy Tân
 Sử dụng các đặc tả chi tiết.
 Bao gồm các thứ sau:.
Các chỉ dẫn bao quát.
Bao quát toàn bộ các câu lệnh điều kiện đơn.
Các điều kiện, đa điều kiện.
Kiểm thử hộp trắng là một thiết kế kiểm thử sử dụng cấu trúc của thiết
kế chi tiêt. Sử dụng thiết kế chi tiết người sử dụng có thể đảm bảo rằng:
 Bảo đảm rằng tất cả các đường dẫn độc lập ở bên trong môđun đều
được thử tối thiểu một lần.
 Thử nghiệm tất các các trường hợp lôgic trong các câu lệnh điều
kiện.
 Thực hiện tất cá các vòng lặp tới giá trị biên của chúng.
 Thử nghiệm tất cả các giá trị biên bên trong đảm bảo chúng hợp lệ.
2.4.1 KIểm thử nhánh cơ bản (Basis Path Testing)
Là một cách kiểm thử hộp trắng. Trường hợp kiểm thử bắt
nguồn từ các đặc tả yêu cầu độc lập. Một tập các trường hợp kiểm
thử có thể được phát sinh bởi các tập kiểm thử cơ bản.
Đây là một cái tên đến từ thực tế rằng các kiểm thử nầy đều
kiểm thử từ tất cả các hướng có thể thông qua chương trình.
Tóm tắt Basis Path Testing

Confirm that actual results match expected results
So sánh kết quả giữa thực tế và lí thuyết
 Thực hiện đi bộ qua chương trình
Hiệu quả của kiểm thử nhánh cơ bản ( Basis Path Testing )
Hiệu quả
 Bao phủ hầu hết toàn bộ các vấn đề.
 Sẽ phát hiện ra hầu hết các lỗi.
 Hầu hết các loại lỗi.
 Là một phương tiện hay để xem lại toàn bộ mã nguồn và đi bộ
qua giải thuật.
 Có thể ứng dụng cho các mức lôgic cao hơn hay các đoạn mã giả.
Hiệu lực
 Là một qui trình xác định tốt.
 Hiệu quả trong việc sử dụng tài nguyên máy và thời gian thiết kế.
 Phát sinh đơn giản và dễ thực thi các trường hợp kiểm thử.
 Giá cả thì chấp nhận được trong thương mại.

2.5 Các trường hợp kiểm thử và dữ liệu kiểm thử
 Kiểm tra các toán tử ở mức giá trị thông thường.
 Kiểm tra với các giá trị giới hạn.
 Kiểm tra ngoài vùng giá trị.
 Kiểm tra các lỗi ở trong vòng lặp.
 Kiểm tra các kết thúc không bình thường trong vòng lặp.
 Kiểm tra các kết thúc không bình thường trong đệ quy.
 Kiểm tra tất các các cấu trúc dữ liệu được truy nhập bởi hàm.
 Kiểm tra tất cả các loại file được truy nhập bởi hàm thành viên.
 Kiểm tra tất cả các lỗi điều kiện.
 Kiểm tra tính hiệu quả của kiểm thử nếu thấy cần thiết.
 Đảm bảo rằng mọi câu lệnh đều được thực hiện.
SVTH: Đặng Thị Kiều Oanh- MSSV:0057

SVTH: Đặng Thị Kiều Oanh- MSSV:0057
Trang 20
Nghiên cứu công cụ kiểm thử IBM Rational Funtional Tester V7.0
Ứng dụng kiểm thử phần mềm tại trung tâm phát triển phần mềm Đại Học Duy Tân
Kiểm thử hệ thống bao gồm các phương pháp luận sau:
1. Kiểm thử tích hợp Top-Down.
2. Kiểm thử tích hợp Bottom-up.
3. Kiểm thử Sandwich.
1. Kiểm thử tích hợp Top-Down

 Hàm Main là nút gốc còn tất cả cá môđun ở bên dưới là các gốc
con(bới vì sau khi kiểm thử xong nút gốc này thì tất cả cá nút gốc
con sẽ được kiểm thử). Nút gốc sẽ được thay thế bằng các môđun
cụ thể, phụ thuộc vào hướng kiểm thử tích hợp được lựa chọn.
Cứ tiếp tục quá trình như vậy cho đến khi nào kết thúc chương
trình thì thôi.
 Thuận tiện
 Không cần có driver kiểm thử.
 Lỗi giao diện được phát hiện sớm.
Bất tiện
 Cần gốc (stubs).
 Làm chậm tiến trình kiểm thử.
 Lỗi ở trong các môđun ở mức thấp khó tìm ra.
Chú thích
 Chương trình làm việc đầu tiên nâng lên tinh thần.
 Rất khó để có thế duy trì thuần top-down trong thực tế.
Tích hợp Bottom-Up
 Mô đun ở mức thấp nhất sẽ được kiểm thử đầu tiên
 Mỗi một driver được viết để theo dõi các đầu vào và đầu ra
 Kiểm thử từng khối

 Kế hoạch kiểm thử kết thúc
3.2.4 Các lời bình về kiểm thử môđun
SVTH: Đặng Thị Kiều Oanh- MSSV:0057
Trang 22
Nghiên cứu công cụ kiểm thử IBM Rational Funtional Tester V7.0
Ứng dụng kiểm thử phần mềm tại trung tâm phát triển phần mềm Đại Học Duy Tân
 Đúng với các yêu cầu phần mềm
 Có mức điều khiển cao
 Có phức tạp hay ẩn chứa lỗi hay không
 Có các yêu cầu hiệu năng xác định hay không
Các bình luận nên càng sớm càng tốt
3.2.5 Đề nghị phương pháp luận kiểm thử tích hợp
 Lựa chọn một nhóm các môđun không quá phức tạp để kiểm thử.
 Kết nối các nhóm môđun vào chương trình.
 Kiểm thử tích hợp trên bộ khung của hệ thống.
 Thử nghiệm tất cả các môđun.
 Thử nghiệm tất cả các lựa chọn của chương trình với các tiện ích
của nó.
 Thực thi kiểm thử trên bộ khung của chương trình.
 Nạp kiểm thử.
 Kiểm thử hiệu năng của chương trình.
 Cố gắng phá vỡ bộ khung.
 Lặp lại bốn bước trên nhiều lầm nếu thấy cần thiết để xây dựng
một mức hoàn chỉnh.
4 Kiểm thử hệ thống
Mỗi lần kiểm thử thủ tục hỗ trợ kiểm thử hệ thống được thực hiện, đội kiểm
thử so sánh kết quả mong đợi của mỗi kiểm thử thủ tục với kết quả thực tế. Nếu
kết quả thực tế khác so với kết quả mong đợi, sự khác nhau này phải được xem xét
lại kỹ hơn.
Kiểm thử hệ thống thường thực hiện sau tất cả các môđun, kiểm thử tích

Một lỗi trong phần mềm là một cái gì đó mà gây ra cho phần mềm
chạy theo cách mà nó không nhất quán với những yêu cầu hay sự cần thiết
của khách hàng hay những chuẩn liên quan. Để có phần mềm chất lượng
cao, sản phẩm cuối cùng nên có vài lỗi có thể.
SVTH: Đặng Thị Kiều Oanh- MSSV:0057
Trang 24
Nghiên cứu công cụ kiểm thử IBM Rational Funtional Tester V7.0
Ứng dụng kiểm thử phần mềm tại trung tâm phát triển phần mềm Đại Học Duy Tân
• Một lỗi được tìm thấy và phải được ghi lại trong DMS bởi một nhân
viên. Lỗi được vào trong DMS với trạng thái “Error” và thông tin
khác.
• Lãnh đạo dự án phải xem lại dữ liệu của một lỗi (như là dạng lỗi,
nguồn gốc,tính nguy hại, ), sửa nó và giao cho người sửa lỗi. Thông
thường thành viên được giao là tác giả của văn bản hay đoạn mã
nguồn mà lỗi được tìm thấy trong đó. Trạng thái của lỗi được thay đổi
thành “Assigned”.
• Sau khi sửa lỗi, tác giả đổi trạng thái lỗi thành “Pending”
• Người kiểm thử kiểm thử lại lỗi chưa giải quyết và cập nhật trạng thái
thành “Tested” nếu lỗi được sửa một cách hài lòng, hay thành “Error”.
• Nếu một lỗi với trạng thái “Error” có thể được chấp nhận mà không có
một hành động hiệu chỉnh nào, lãnh đạo dự án cần đổi trạng thái thành
“Accepted”.
Vòng đời của lỗi được mô hình hoá trong flowchart sau đây:
SVTH: Đặng Thị Kiều Oanh- MSSV:0057
Trang 25