Bài Giảng Kiểm Thử Phần Mềm ( Combo Full Slides 6 Chương )

BÀI GIẢNG
KIỂM THỬ PHẦN MỀM

1


NỘI DUNG BÀI GIẢNG
 Chương
 Chương
 Chương
 Chương
 Chương
 Chương

@ ISR-CMU 2010

1
2
3
4
5
6

Giới thiệu về kiểm thử phần mềm
Kiểm thử hộp đen
Kiểm thử hộp trắng
Các quá trình kiểm thử
JUnit
KIỂM THỬ ỨNG DỤNG DI ĐỘNG

2

Kiểm thử phần mềm
Giới thiệu về kiểm thử
phần mềm

3


Mục tiêu môn học
 Các khái niệm, định nghĩa về kiểm thử và chất
lượng phần mềm
 Các mức độ kiểm thử phần mềm
 Các kĩ thuật, tiến trình kiểm thử
 Hiểu và tạo được các trường hợp kiểm thử cho
các chương trình đơn giản
 Quản lí chất lượng phần mềm

@ ISR-CMU 2010

4


Kiến thức cần thiết
 Ngơn ngữ (nói , hiểu, viết): tiếng việt, tiếng anh
 Cơ bản của IT
 Kĩ năng lập trình (debug và kiểm tra lỗi)
 Cơ bản của SE, quy trình phát triển phần mềm
 Ngơn ngữ mơ tả lơgic ( phản ứng) : tiến trình algebra,
state machines, petri nets.

 Toán học:
 Logic, tập hợp
 Thống kê.

@ ISR-CMU 2010

5


Tài liệu tham khảo
 Ian Sommerville: “Software Engineering”, 7th
Ed., 2004.
 Roger S. Pressman: “Software Engineering: A
Practitioner's Approach”, 6th Ed., McGraw-Hill,
2004.
 John Musa: “Software Reliability Engineering”,
McGraw-Hill

@ ISR-CMU 2010

6


Q&A

Kiểm thử phần mềm là gì?
Kiểm thử phần mềm là quá trình thực thi 1 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?

@ ISR-CMU 2010

7


Q&A

Thú vị nghề kiểm thử phần
mềm?
 Nghề chuyên đi tìm…lỗi.
 Cảm giác rất “Yomost”!

@ ISR-CMU 2010

8


Thuật ngữ

TEST

?

ERROR

?
FAULT
DEBUG

?
FAILURE

9


Chi phí thay đổi
60-100x

1.5-6x
1x
Xác định yêu cầu Phát triển Sau khi đã phát hành

4


Mục tiêu
 Khám phá nền tảng của kiểm thử phần
mềm để mọi người hiểu 6 í chính sau:
1. Các định nghĩa và chi phí của các khiếm
khuyết (defect).
2. Các định nghĩa và mục tiêu của kiểm thử
phần mềm.
3. Mục tiêu và quy trình làm việc của người
kiểm thử.
4. Điều gì làm nên một người kiểm thử giỏi.
5. Thực tiễn của kiểm thử phần mềm.
6. Các thuật ngữ của kiểm thử phần mềm.
@ ISR-CMU 2010

11


Ví dụ
 Giả sử có một hàm của một phần mềm nào đó
được xác định như sau:
nextDate (tháng, ngày, năm): hàm mà kết
quả đầu ra là ngày tiếp theo của ngày đầu vào. 1
≤ tháng ≤ 12, 1 ≤ ngày ≤ 31,1900 ≤ năm ≤
2060.
Hàm này đã được cài đặt bởi ngơn ngữ java.
 Nếu chỉ có các đặc tả và các file .class, làm thế nào
có thể chắc chắn rằng hàm đó đã được cài đặt chính
xác?
 Nếu đã cài đặt hàm, có nghĩa là, có các file .java, làm
thế nào có thể chắc chắn rằng code là chính xác?
@ ISR-CMU 2010

6


Ví dụ 1 (1)
 Nếu bạn có các đặc tả và các file.class, có lẽ có thể tiếp tục như sau:
1. Suy nghĩ một vài phút dựa trên các đặc tả và chọn ngày 2006/06/16
như là một đầu vào cho chương trình.
2. Bắt đầu chương trình.
3. Nhập 6 vào trường tháng, 16 vào trường ngày và 2006 vào trường
năm.
4. Nhấp vào nút cho biết.
5. Xem kết quả: 2006/06/17.

Cuối cùng: kết quả là chính xác như mong muốn.
=>hàm đúng.
- Giả sử: đầu vào là ngày 2006/12/31.
+ Lặp lại các bước từ 2 đến 5.
+ Kết quả: 1/32/2007.

@ ISR-CMU 2010

13


Ví dụ 1(2)
B1: Mở giao diện Next Date

B2: Nhập: 6 vào ô Mont
16 vào ô Date
2006 vào ô Year

B3: Click vào nút Tell
và xem kết quả hiện
lên là ngày
16/6/2006
@ ISR-CMU 2010

14


Ví dụ 1(3)
B1: Mở giao diện Next Date.

B2: Nhập: 12 vào ô
month
31 vào ô Date
2006 vào ô Year

B3:Click vào nút Tell
và kết quả hiện lên là
32/1/2007
@ ISR-CMU 2010

15


Ví dụ 2 (1)
 Khi đã thực hiện 1 chức năng , tức là đã có mã nguồn của nó.
Nhưng làm sao để biết được code đó là chính xác. Hãy xem ví
dụ dưới đây :

@ ISR-CMU 2010

16


Ví dụ 2 (2)
 Để kiểm tra code, thì mỗi dịng sẽ được chạy ít nhất một lần.
Nhưng file Year.java chỉ là một phần của chương trình, nó khơng
thể chạy một mình. Vì vậy cần code thêm 1 đoạn để kiểm tra xem
1 năm nào đó có phải là năm nhuận hay không.

@ ISR-CMU 2010

17


Kết luận
 Hai ví dụ cho ta biết được rằng chắc chắn sẽ có một số sai
lầm trong chương trình. Trong thử nghiệm phần mềm, đây
được gọi là một lỗi(defect).
 Những ví dụ này là hai phương pháp tiếp cận khác nhau,
đều có thể áp dụng để tìm lỗi. Một được gọi là kiếm tra
chức năng như trong ví dụ 1, ví dụ 2 được gọi là kiểm tra
cấu trúc
 Bây giờ bạn có thể tự hỏi mình rằng là lí do tại sao chúng
ta phải tìm các lỗi(defect)?

@ ISR-CMU 2010

18


Tại sao lỗi lại phát sinh trong phần mềm?
 Phần mềm được tạo ra bởi chính chúng ta
 Chúng ta có thể biết nhiều thứ những chúng ta khơng thể biết được tất
cả mọi thứ.
 Các lập trình viên đều có kĩ năng, nhưng khơng phải ai cũng hồn hảo.
 1 số lập trình viên khơng có những quy tắc khắt khe với các đoạn mã
của mình.
 Các lập trình viên là những người dễ gây ra sai sót (lỗi).
 Làm việc dưới áp lực ngày càng tăng để đảm bảo đúng thời
hạn

 Khơng có thời gian để kiểm tra, các chức năng có thể bị làm sai.
 Hệ thống có thể khơng đáp ứng đầy đủ các u cầu ban đầu.
 Phần mềm thực sự phức tạp, trừu tượng và vơ hình
 Khó có thể xem phần mềm nếu nó là chưa hồn chỉnh hoặc hoạt động
thiếu chính xác.
 Khó có ai có thể hiểu hết hồn tồn 1 hệ thống lớn.
 Q nhiều giao diện bên ngồi khơng cần thiết.
@ ISR-CMU 2010

19


Tại sao phải tìm kiếm các lỗi
 Phần mềm được viết bởi con người. Và họ tạo ra những sai
sót . Chi phí của các lỗi có thể là rất cao.
 Từ góc nhìn của 1 người phát triển phần mềm:
• Phải mất rất nhiều thời gian và nỗ lực để sửa chữa các lỗi. Một cuộc khảo
sát cho thấy khoảng 50% thời gian làm việc của người lao động phần mềm
được chi tiêu vào việc tìm kiếm và sửa lỗi.
• Càng sớm tìm ra lỗi thì chúng ta càng tiết kiệm được chi phí
• Bài giảng 11 sẽ có thơng tin chi tiết hơn

 Từ góc nhìn của 1 người dùng cuối:
• Khơng ai thích 1 phần mềm mà sử dụng thì hay bị treo.
• Với việc sử dụng nhiều hơn và thường xuyên hơn của phần mềm trong
cuộc sống hàng ngày ,chúng ta cần các phần mềm có chất lượng hơn, đáng
tin cậy hơn và an toàn hơn.

 Kết luận
 Phải cần kĩ thuật để tìm các lỗi và đó là mục đích của kiểm thử

phần mềm

@ ISR-CMU 2010

20