bài giảng kiểm thử phần mềm

1. Software testing
Kiểm thử phần mềm

2. Nội dung
 Kiểm thử hệ thống (system testing)
 Kiểm thử thành phần (component testing)
 Thiết kế test case (test case design)
 Kiểm thử tự động (test automation)

3. Tiến trình Kiểm thử
 Kiểm thử thành phần
 Kiểm thử các thành phần riêng biệt của chương trình
 Thường là trách nhiệm của người phát triển phần mềm
 Kiểm thử xuất phát từ kinh nghiệm của người phát
triển phần mềm.
Kiểm thử hệ thống
- Kiểm thử các nhóm thành phần tích hợp để tạo ra 1 hệ
thống hoặc 1 hệ thống phụ
- Là trách nhiệm của nhóm kiểm thử độc lập
- Kiểm thử dựa trên đặc tả hệ thống

4. Giai đoạn kiểm thử
Component testing System testing
Software developer Independent testing team

5. Kiểm tra lỗi
 Mục tiêu của việc kiểm tra lỗi là để phát hiện
ra những lỗi trong chương trình
 Kiểm tra thành công là làm cho chương trình
chạy 1 cách bất thường

6. Mục tiêu của tiến trình kiểm tra
 Kiểm thử xác nhận
- Để giải thích cho người phát triển phần mềm và
khách hàng thấy được các yêu cầu mà hệ thống có.
- kiểm thử thành công là cho thấy hệ thống hoạt động
như dự định
 Defect testing
- Để phát hiện lỗi hoặc khiếm khuyết trong hệ thống
mà hoạt động của nó không đúng hoặc không phù
hợp với đặc tả.
- Một kiểm thử thành công là làm cho hệ thống thực
hiện không chính xác và để lộ một khiếm khuyết
trong hệ thống.

7. Quy trình kiểm thử phần mềm
Test case Test data
Test
results
Test
reports
Design test
cases
Prepare test
data
Run program
with test data
Compare
results to test
cases

8. Chính sách kiểm thử
 Chỉ có kiểm thử đầy đủ mới có thể cho thấy 1 chương
trình luôn có khiếm khuyết. Tuy nhiên, kiểm thử đầy đủ
là việc không thể.
 Chính sách kiểm thử xác định các phương pháp được
sử dụng trong việc chọn lựa kiểm thử hệ thống.
- Tất cả các chức năng truy cập trong trình đơn nên
được kiểm thử
- Sự kết hợp các chức năng trong cùng 1 trình đơn cần
được kiểm thử.
- Trường hợp đầu vào là từ phía người dùng thì tất cả
các chức năng đều phải được kiểm thử với cả đầu vào
đúng và sai.

9. Kiểm thử hệ thống
 Bao gồm các thành phần tích hợp để tạo ra 1 hệ thống
hoặc 1 hệ thống phụ.
 Có thể bao gồm việc kiểm thử 1 increment được giao
cho khách hàng.
 Hai giai đoạn:
- Kiểm thử tích hợp: nhóm kiểm thử có thể truy cập vào
mã nguồn của hệ thống. Hệ thống được kiểm thử là các
thành phần được tích hợp.
- Kiểm thử phát hành(release testing): nhóm kiểm thử
kiểm thử hệ thống hoàn chỉnh sẽ được chuyển giao như
một black-box.

10. Kiểm thử tích hợp
 Bao gồm việc xây dựng 1 hệ thống từ các thành
phần và kiểm thử để phát hiện vấn đề phát sinh từ
các tương tác thành phần.
 Tích hợp đầu-cuối:
Phát triển khung sườn hệ thống và populate nó
với các thành phần.
 Tịch hợp trên-dưới:
 Để đơn giản hóa các lỗi cục bộ, hệ thống nên
được tích hợp từng bước một.

11. Incremental integration testing
A
B
A
B
C
A
B
C
D
T1
T2
T3
T1
T2
T3
T1
T2
T3
T4
T4
T5

12. Tiếp cận kiểm thử
 Xác nhận kiến trúc: Kiểm thử tích hợp Top-
Down để phát hiện ra sai sót trong kiến trúc
của hệ thống.

13. Black-box testing

14. Nguyên tắc kiểm thử
 Nguyên tắc kiểm thừ là các gợi ý cho nhóm kiểm thử
để giúp họ chọn cách kiểm thử mà sẽ làm bộc lộ các
khuyết điểm trong hệ thống.
 Chọn các đầu vào tác động đến hệ thống để tạo ra tất cả
các thông báo lỗi.
 Thiết kế đầu vào để gây ra lỗi tràn bộ đệm
 Lặp lại các đầu vào giống nhau hoặc hàng loạt đầu vào
trong 1 vài lần.
 Lượng kết quả tính toán là quá nhiều hay quá ít.

15. Kịch bản kiểm thử
A student in Scotland is studying American History and has been
asked to write a paper on ‘Frontier mentality in the American
West from 1840 to 1880’. To do this, she needs to find sources
from a range of libraries. She logs on to the LIBSYS system
and uses the search facility to discover if she can access
riginal documents from that time. She discovers sources in
various US university libraries and downloads copies of some
of these. However, for one document, she needs to have
confirmation from her university that she is a genuine student
and that use is for non-commercial purposes. The student then
uses the facility in LIBSYS that can request such permission
and registers her request. If granted, the document will be
downloaded to the registered library’s server and printed for
her. She receives a message from LIBSYS telling her that she
will receive an e-mail message when the printed document is
available for collection.

16. Các kiểm thử hệ thống
 Kiểm tra cơ chế đăng nhập bằng cách sử dụng thông tin
đăng nhập chính xác và không chính xác để kiểm tra rằng
người dùng hợp lệ được chấp nhận và người sử dụng không
hợp lệ bị từ chối.
 Kiểm tra các tìm kiếm cơ sở bằng cách sử dụng các truy vấn
khác nhau đối với nguồn đã biết đê kiểm tra xem cơ chế tìm
kiếm có thực sự tìm kiếm các tài liệu.
 Kiểm tra hệ thống trình bày cơ sở để kiểm tra xem thông tin
về các văn bản có được hiển thị đúng cách.
 Kiểm tra các cơ chế để yêu cầu sự cho phép để tải về.
 Kiểm tra e-mail phản hồi cho biết rằng các tài liệu được tải
về là tồn tại.

17. Use cases
 Use cases có thể là các cơ sở để phát sinh các
kiểm thử cho hệ thống. Chúng giúp cho việc
xác định các hoạt động để kiểm thử và giúp
cho việc thiết kế test case.
 Từ một lược đồ trình tự liên quan, các
đầu vào và đầu ra phải được tạo ra cho các lần
kiểm thừ có thể được xác định.

18. Collect weather data sequence chart

19. Kiểm thử hiệu suất
 Một phần của release testing có thể bao gồm thử
nghiệm sự nổi lên đặc tính của một hệ thống,
chẳng hạn như hiệu suất và độ tin cậy.
 Hiệu suất kiểm tra thường liên quan đến kế hoạch
hàng loạt các bài kiểm tra nơi nạp là ổn định
tăng cho đến khi hệ thống hoạt động
trở nên không thể chấp nhận.

20. Kiểm thử thành phần
 Thành phần test là quá trình thử nghiệm thành phần riêng biệt trong hệ
thống. Đây là một quá trình kiểm tra lỗi như vậy mục đích của nó là để lộ
những lỗi lầm trong các thành phần.
Có nhiều loại khác nhau của thành phần có thể sẽ được thử nghiệm ở giai
đoạn này:
 chức năng cá nhân hoặc các chức năng trong một đối tượng.
 các lớp đối tượng có nhiều thuộc tính và chức năng.
 các chức năng của thành phần hỗn hợp được tạo thành từ các đối tượng
khác nhau. các thành phần hỗn hợp có một giao diện được định nghĩa được
sử dụng để truy cập các chức năng của nó
 chức năng cá nhân hoặc các phương pháp cá nhân là loại đơn giản nhất của
thành phần, các test của bạn là một tập hợp các đường dẫn đến những thói
quen với các thông số đầu vào khác nhau. bạn có thể sử dụng các phương
pháp tiếp cận để kiểm tra , thảo luận trong phần tiếp theo, để thiết kế các
test chức năng hoặc các chức năng.

21. Giao diện đối tượng trạm thời tiết

22. Trạm thử nghiệm thời tiết
 Cần phải xác định trường hợp thử nghiệm cho báo cáo thời
tiết, hiệu chỉnh, kiểm tra, khởi động và tắt máy.
 Sử dụng một mô hình nhà nước, xác định trình tự của chuyển
trạng thái để thử nghiệm và sự kiện trình tự để gây ra những
hiệu ứng chuyển tiếp
 Ví dụ: Chờ đợi -> đo đạc -> Kiểm tra -> Truyền -> Chờ đợi

23. Kiểm thử giao diện
 Mục tiêu là để phát hiện lỗi do Giao diện hoặc
giả định không hợp lệ về giao diện.
 Đặc biệt quan trọng đối với hướng đối tượng
phát triển các đối tượng được xác định bằng
các giao diện của nó.

24. Interface testing

25. Các loại giao diện
Các thông số giao diện
 Dữ liệu truyền từ một thủ tục khác.
Chia sẻ bộ nhớ giao diện.
_ Block của bộ nhớ được chia sẻ giữa các thủ tục hoặc chức
năng.
Giao diện thủ tục
_ Hệ thống đóng gói là một tập hợp các thủ tục và bởi các hệ
thống phụ khác.
Thông báo qua giao diện
_ Hệ thống yêu cầu dịch vụ từ system.s

26. Lỗi giao diện
*Sử dụng sai giao diện
Một thành phần giao diện gọi thành phần khác và làm cho một lỗi
trong việc sử dụng thành phần đó
ví dụ: sai thứ tự các thông số .
*Sự hiểu lầm giao diện
Những giả định về hành vi của các thành phần không chính xác.
*Lỗi thời
Các tên gọi của tốc độ hoạt động và các thông tin mới được truy
cập về thành phần khác .

27. Hướng dẫn kiểm tra giao diện
 Thiết kế các bài kiểm tra để các tham số được gọi là
thủ tục tại phạm vi các đầu cực của của nó.
 Luôn luôn kiểm tra các tham số con trỏ với con trỏ
null.
 Thiết kế các bài kiểm tra thành phần gây thất bại.
 Sử dụng qua tin nhắn thử nghiệm trong hệ thống.
 Trong chia sẻ hệ thống bộ nhớ, thay đổi thứ tự
các thành phần được kích hoạt.

28. Trường hợp kiểm tra thiết kế
 Liên quan đến việc thiết kế các trường hợp thử nghiệm (đầu vào và kết quả
đầu ra) dùng để kiểm tra hệ thống.
 Mục tiêu của thiết kế trường hợp thử nghiệm là tạo ra một
thiết lập các bài kiểm tra có hiệu quả trong quá trình xác nhận và lỗi thử
nghiệm.
 Thiết kế phương pháp tiếp cận:
 Dựa trên yêu cầu thử nghiệm;
 Phân vùng thử nghiệm;
 thử nghiệm Kết cấu.

29. Thử nghiệm dựa trên yêu cầu
 Một nguyên tắc chung của yêu cầu kỹ thuật này là
yêu cầu cần được kiểm chứng.
 Yêu cầu dựa trên thử nghiệm là một xác nhận kiểm
tra kỹ thuật, nơi bạn xem xét từng yêu cầu và rút ra
một tập hợp các yêu cầu kiểm thử.

30. yêu cầu LIBSYS
 Người dùng sẽ có thể tìm kiếm hoặc là tất cả các thiết
lập ban đầu của cơ sở dữ liệu hoặc chọn một tập con
từ đó.
 Hệ thống sẽ cung cấp cho người xem thích hợp cho
người sử dụng để đọc tài liệu trong tài liệu lưu trữ.
 Mỗi đơn hàng được cấp một định danh duy nhất
(ORDER_ID) mà người dùng phải có thể sao chép
vào khu vực lưu trữ lâu dài của tài khoản.

31. Kiểm thử LIBSYS
 Bắt đầu tìm kiếm: cho người sử dụng tìm kiếm cho các hạng
mục được biết đến
 Bắt đầu dùng tìm kiếm cho các hạng mục đó được biết là có
mặt và được biết không có mặt, nơi tập hợp các cơ sở dữ liệu
bao gồm 2 cơ sở dữ liệu
 Bắt đầu dùng tìm kiếm cho các hạng mục đó được biết là có
mặt và được biết không có mặt nơi đặt cơ sở dữ liệu, bao gồm
hơn 2 cơ sở dữ liệu.
 Chọn một cơ sở dữ liệu từ các thiết lập cơ sở dữ liệu và bắt
đầu
người dùng tìm kiếm cho các hạng mục được biết là hiện tại và
được biết đến không có mặt.
 Chọn nhiều hơn một cơ sở dữ liệu từ các thiết lập cơ sở dữ liệu
và bắt đầu tìm kiếm cho các hạng mục đó được biết là có mặt
và được biết không có mặt.

32. Phân vùng thử nghiệm
 Dữ liệu đầu vào và kết quả đầu ra thường rơi vào
các lớp học khác nhau mà tất cả các thành viên của
một lớp học có liên quan.
 Mỗi của các lớp này là tương đương phân vùng, lĩnh
vực mà chương trình cư xử một cách tương đương
cho mỗi lớp thành viên.
 trường hợp kiểm tra nên được lựa chọn từ mỗi phân
vùng.

33. phân vùng tương đương

34. search routine - input partitions
 Nhập vào những gì phù hợp với điều kiện ban
đầu
 Nhập vào nơi yếu tố khóa là 1 thành phần của
mảng
 Nhập vào nơi yếu tố khóa không là 1 thành
phần của mảng

35. search routine - input partitions

36. Nguyên tắc kiểm thử( tuần tự)
 Kiểm thử phần mềm với trình tự mà chỉ có 1
giá trị đơn
 Sử dụng các kích thước khác nhau của trình tự
trong những kiểm thử khác nhau
 Xuất phát từ việc kiểm thử : phần đầu giữa
cuối của trình tự cho phép
 Kiểm thử với chiều dài trình tự là 0

37. Kiểm thử cấu trúc
 Thông thường gọi là kiểm thử white-box
 Dẫn xuất của trường hợp kiểm thử dựa theo
cấu trúc chương trình. Sự nhận biết của
chương trình được dùng để xác nhận trường
hợp kiểm thử thêm vào
 Đối tượng để thi hành tất cả dòng lệnh chương
trình( không phải tất cả đường kết hợp)

38. Kiểm thử cấu trúc

39. Tìm kiếm nhị phân- phân vùng
tương đương
 Thỏa mãn điều kiện ban đầu, yếu tố khóa trong mảng
 Thỏa mãn điều kiện ban đầu, yếu tố khóa không ở
trong mảng
 Không thỏa mãn điều kiện ban đầu, yếu tố khóa trong
mảng
 Không thỏa mãn điều kiện ban đầu, yếu tố khóa
không ở trong mảng
 Mảng nhập vào giá trị đơn
 Mảng nhập vào giá trị chẵn
 Mảng nhập vào giá trị lẻ

40. Tìm kiếm nhị phân- phân vùng
tương đương

41. Kiểm thử đường đi
 Đối tượng của kiểm thử đường đi là để chắc
chắn rằng bộ trường hợp kiểm thử là mỗi
đường trong chương trình được thực thi tệ nhất
1 lần
 Điểm bắt đầu cho kiểm thử đường đi là
chương trình luồng đồ thị, biểu diễn node mô
tả sự giải quyết của chương trình và vòng cung
biểu thị luồng điều khiển
 Những dòng lệnh với các điều kiện là node
trong luồng đồ thị

42. Kiểm thử tự động
 Kiểm thử là giai đoạn tốn kém.quy trình kiểm
thử cung cấp loạt các công cụ để giảm thời
gian và chi phí
 Hệ thống như là Junit hỗ trợ sự thực thi kiểm
thử tự động
 Hầu hết quy trình kiểm thử là hệ thống mở vì
kiểm thừ cần là đặc tả tổ chức
 Chúng thông thường khó để tích hợp vói quy
trình thiết kế và phần tích thân thiện

43. A testing workbench

44. Testing workbench adaptation
 Các tập lệnh phải được phát triển để thích ứng
với giao diện người dùng, kiểu dáng cho bộ
sinh dữ liệu thử
 Kiểm tra kết quả đầu ra phải được kiểm chứng
lại bằng phương pháp thủ công
 Đặc biệt có thể so sánh các tập tin để phát
triển

45. Key points
 Kiểm thử giao diện là tìm ra những lỗi trong
việc thiết kế giao diện của những thành phần
hỗn hợp cấu thành
 Phân tích cấu trúc dựa vào việc phân tích 1
chương trình và kiểm tra những phát sinh từ
việc phân tích đó.
 Hệ thống kiểm thử tự động làm giảm chi phí
kiểm thử bằng cách hỗ trợ trong việc kiểm thử
chương trình với 1 loạt các công cụ phần mềm.