Quy trình phát triển phần mềm
Tại sao phải kiểm thử (testing) phần
mềm?
Testing là gì?
Những nguyên lý tổng quát trong kiểm
thử
Quy trình kiểm thử cơ bản
Các kiểu kiểm thử
64 trang |
Chia sẻ: thuychi16 | Lượt xem: 919 | Lượt tải: 2
Bạn đang xem trước 20 trang tài liệu Đảm bảo và kiểm soát chất lượng - Chương 2: Các yếu tố cơ bản trong kiểm soát chất lượng phần mềm, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
ĐẢM BẢO VÀ KIỂM SOÁT
CHẤT LƯỢNG
HCM – 10/2012
Chương 2:
Các yếu tố cơ bản trong
kiểm soát chất lượng
phần mềm
11/5/2016
Nội dung
Quy trình phát triển phần mềm
Tại sao phải kiểm thử (testing) phần
mềm?
Testing là gì?
Những nguyên lý tổng quát trong kiểm
thử
Quy trình kiểm thử cơ bản
Các kiểu kiểm thử
1/5/2016 Trang 2
Quy trình phát triển phần mềm
1/5/2016 Trang 3
Làm sao đi được tới
ROME du lịch một chuyến
nhỉ?
Quy trình phát triển phần mềm
1/5/2016 Trang 4
Quy trình phát triển phần mềm
1/5/2016 Trang 5
Quy trình phát triển phần mềm
1/5/2016 Trang 6
Phần mềm
Yêu cầu phần mềm
Lập trình
Thiết kế
Lập trình
Phân tích
Thiết kế
Lập trình
Phân tích
Thiết kế
Lập trình
Kiểm thử
1
2 3
4
Quy trình phát triển phần mềm
1/5/2016 Trang 7
Qui trình phần mềm là gì?
Chuỗi hoạt động
Theo thứ tự nhất định
Sản xuất phần mềm
Qui trình công nghệ phần
mềm là tổ hợp các bước, các
giai đoạn phải trải qua khi
thực hiện việc sản xuất phần
mềm.
Nội dung
Quy trình phát triển phần mềm
Tại sao phải kiểm thử (testing)
phần mềm?
Testing là gì?
Những nguyên lý tổng quát trong
testing
Quy trình Testing cơ bản
Các kiểu kiểm thử
1/5/2016 Trang 8
Tại sao phải kiểm thử (testing)
phần mềm?
Xét các phần mềm thực tế
Chuyển đổi tiền tệ
Hệ thống ATM
Hệ thống điều khiển máy bay, tàu điện, tên
lửa
Hoạt động không đúng – gây ra nhiều
vấn đề:
Tiền bạc
Thời gian
Tổn hại tính mạng con người
1/5/2016 Trang 9
Những hậu quả do lỗi phần
mềm gây ra
Vụ sụp đổ của Ariane 5, 1996
Bị tan tành sau 40 giây cất cánh, bị thiệt
hại khoảng ½ tỉ USD
Nguyên nhân: bị lỗi về xử dụng số thực.
Do chuyển đổi từ 64bit integer sang 16 bit
integer có dấu => bị tràn số
Phóng tên lửa vào Sao Hỏa, 1999
Bị biến mất ngay khi bắt đầu, bị thiệt hại
khoảng 125 triệu USD
Nguyên nhân: dùng sai đơn vị trong
chương trình
1/5/2016 Trang 10
Tại sao phải kiểm thử (testing)
phần mềm?
“Lỗi phần mềm là chuyện hiển nhiên của cuộc
sống. Chúng ta dù cố gắng đến mức nào thì
thực tế là ngay cả những lập trình viên xuất
sắc nhất cũng không có thể lúc nào cũng viết
được những đoạn mã không có lỗi. Tính trung
bình, ngay cả một lập trình viên loại tốt thì
cũng có từ 1 đến 3 lỗi trên 100 dòng lệnh.
Người ta ước lượng rằng việc Testing để tìm ra
các lỗi này chiếm phân nửa khối lượng công
việc phải làm để có được một phần mềm hoạt
động được”.
(Software Testing Techniques, Second Edition,
by Boris Beizer, Van Nostrand Reinhold, 1990,
ISBN 1850328803).
1/5/2016 Trang 11
Nguyên nhân các khiếm khuyết
1/5/2016 Trang 12
Con người tạo ra lỗi
...
Hệ quả là xuất hiện
khiếm khuyết ...
hệ thống thực hiện
công việc sai xót
Nguyên nhân các khiếm khuyết
Con người tạo ra lỗi (error – mistake)
Hệ quả là xuất hiện khiếm khuyết(sai
lầm/ sai sót - fault, rối - bug)
Dòng mã, hệ thống, phần mềm, tài liệu
• Dư thừa
• Thiếu xót
Khi mã thực thi, hệ thống thực hiện
công việc sai xót -> thực hiện không
mong đợi (failure – hỏng hóc)
Hệ quả không mong đợi (Incident)
1/5/2016 Trang 13
Nguyên nhân các khiếm khuyết
Khiếm khuyết có thể xảy ra bởi
Áp lực về thời gian
Mã phức tạp
Hạ tầng phức tạp
Thay đổi công nghệ
Tương tác nhiều hệ thống
Tác động từ bên ngoài
1/5/2016 Trang 14
Nội dung
Tại sao phải kiểm thử (testing) phần
mềm?
Testing là gì?
Những nguyên lý tổng quát trong kiểm
thử
Quy trình Kiểm thử cơ bản
Triết lý của việc kiểm thử
Những định nghĩa cơ bản
Các kiểu kiểm thử
1/5/2016 Trang 15
Testing phần mềm là gì?
Testing phần mềm là qui trình chứng
minh phần mềm không có lỗi.
Mục đích của Testing phần mềm là chỉ
ra rằng phần mềm thực hiện đúng các
chức năng mong muốn.
Testing phần mềm là qui trình thi hành
phần mềm với ý định tìm kiếm các lỗi
của nó.
Testing phần mềm được xem là qui
trình cố gắng tìm kiếm các lỗi của phần
mềm theo tinh thần "hủy diệt".
1/5/2016 Trang 16
Testing phần mềm là gì?
Mục tiêu
Tìm khiếm khuyết
Ngăn ngừa khiếm khuyết
Chứng minh được phần mềm hoạt động đúng
như đã thiết kế
Chứng minh được phần mềm đáp ứng yêu
cầu của user
Góp phần chứng minh chất lượng của phần
mềm
Tăng tin tưởng mức chất lượng và thông
tin cung cấp
1/5/2016 Trang 17
Phần mềm đáp ứng yêu cầu
của user
1/5/2016 Trang 18
Phần mềm đáp ứng yêu cầu
của user
1/5/2016 Trang 19
Khác biệt giữa Gỡ rối(Debug)
và Testing
Testing:
Cho thấy các trường hợp không mong đợi
do khiếm khuyết phần mềm
Testers
Gỡ rối (Debug):
Hoạt động phát triển
Xác định nguyên nhân và sửa chữa mã lỗi
Testing lại khiếm khuyết có được sửa
đúng
Developers
1/5/2016 Trang 20
Nội dung
Tại sao phải kiểm thử (testing) phần
mềm?
Testing là gì?
Những nguyên lý tổng quát trong
testing
Quy trình Testing cơ bản
Triết lý của việc Testing
Những định nghĩa cơ bản
1/5/2016 Trang 21
Những nguyên lý tổng quát
trong testing
Những nguyên lý này được đúc kết thông
qua quá trình phát triển và qua các hướng
dẫn tổng quát nhất cho việc testing
Có 7+ nguyên lý chính
Testing để khơi bày các lỗi ra ngoài
Không thể vét cạn hết các trường hợp
Testing sớm
Gom nhóm các khiếm khuyết
Nghịch lý thuốc trừ sâu (Pesticide paradox)
Phụ thuộc ngữ cảnh
Ảo tưởng “không lỗi” (Absence-of-errors
fallacy)
1/5/2016 Trang 22
Testing để khơi bày các lỗi ra
ngoài
Testing có thể khơi bày các lỗi ra ngoài,
nhưng không chứng minh được chương
trình hết lỗi
Testing để giảm khả năng để xót lỗi lại
trong chương trình
1/5/2016 Trang 23
Không thể vét cạn hết các
trường hợp
1/5/2016 Trang 24
Hê thống có
20 màn hình
Trung bình: 10 fields / screen
2 types input / field
(date as Jan 3 or 3/1)
(number as integer or decimal)
Around 100 possible values
Số lượng test cho toàn bộ:
20 x 4 x 3 x 10 x 2 x 100 = 480,000 tests
Nếu 1 giây/test => 8000 phút = 133 giờ = 17.7 ngày
Trung bình 4 menu
3 lựa chọn/ menu
10 giây = 34 tuần, 1 phút = 4 năm, 10 phút = 40 năm
Không thể vét cạn hết các
trường hợp
1/5/2016 Trang 25
Số lượng test cho trường hợp lỗi:
Username: Giả sử chúng ta có 50 ký tự có thể nhập được gồm
chữ thường, chữ hoa, số, ký tự đặt biệt thì ta cần 50 mũ 20 lần
giá trị
Password: tương tự như Username, chúng ta cũng có 50 mũ
20 lần giá trị
Và chúng ta cũng cần tổ hợp Username và pasword lại nữa
Nhiều nhất là 20
ký tự
Không thể vét cạn hết các
trường hợp
Vì thời gian testing luôn có giới hạn
Việc quyết định bao nhiêu là đủ nên dựa
vào:
• Bảng miêu tả các rủi ro: Rủi ro kỹ thuật, nghiệp
vụ, dự án
• Các ràng buộc về thời gian lẫn ngân sách
• Những yêu cầu đặc biệt của khách hàng
Qua đó giúp xác định:
• Những phần nào nên test trước
• Những phần nào nên tập trung
• Những phần nào sẽ không test (trong thời gian
này)
1/5/2016 Trang 26
Testing sớm
Nên bắt đầu sớm nhất có thể trong chu
kỳ phát triển
Việc phát hiện lỗi quá trễ thường sẽ tốn
nhiều chi phí hơn để khắc phục:
• Chịu áp lực về thời gian
• Phải testing lại phần lớn những chức năng để
ổn định trước đó
Giúp nắm rõ về các yêu cầu của hệ thống
để có những bước chuẩn bị môi trường
hay kế hoạch đào tạo (training) tốt hơn
1/5/2016 Trang 27
Gom nhóm các khiếm khuyết
Thông thường một nhóm nhỏ các chức
năng phần mềm gây ra phần lớn các
khiếm khuyết của hệ thống
Áp dụng nguyên lý Pareto: 80% lỗi có
nguyên nhân từ 20% các chức năng
⇒ cô lập và testing những chức năng khả
nghi nhất.
1/5/2016 Trang 28
Nghịch lý thuốc trừ sâu
(Pesticide paradox)
Lặp lại cùng mẫu testing:
Không tìm thấy khiếm khuyết mới
Kịch bản Testing cần rà soát và xem xét
lại đều đặn
Những phần mới hay khác biệt nên
được viết lại để có thể kiếm được những
lỗi tiềm ẩn mới
1/5/2016 Trang 29
Phụ thuộc ngữ cảnh
Thực hiện khác nhau trong những ngữ
cảnh khác nhau
Cùng bộ mẫu test không thể sử dụng cho
tất cả mọi trường hợp bởi vì những sản
phẩm phần mềm khác nhau sẽ có những
tính năng và mục đích sử dụng khác nhau
Không phải tất cả phần mềm đều có cùng
cấp độ rủi ro và không phải tất cả những
khiếm khuyết đều có chung mức độ tàn
phá
1/5/2016 Trang 30
Ảo tưởng “không lỗi”
(Absence-of-errors fallacy)
Tìm và khắc phục khiếm khuyết là vô
nghĩa nếu hệ thống:
Không có giá trị
Không đáp ứng yêu cầu cần thiết
Không đáp ứng kỳ vọng người sử dụng
1/5/2016 Trang 31
Những nguyên lý khác
Nên được hoạch định trước khi thực hiện
Nên tiến hành từ nhỏ đến lớn: bắt đầu từ những
module riêng biệt rồi sau đó tích hợp các module
lại.
Nên được thực hiện bởi những đối tượng KHÔNG
tham gia vào quá trình phát triển phần mềm.
Nguyên tắc ngẫu nhiên:
‰Dữ liệu và chức năng được chọn, tuy có chủ đích
nhưng không phải xuất hiện theo thứ tự nhất định.
Nguyên tắc "người sử dụng kém":
Người có trình độ thấp mức chấp nhận được dùng
thử.
• Có thể gây các sự cố không lường trước được
Nguyên tắc "kẻ phá hoại":
Hệ thống rơi vào tay có trình độ nghiệp vụ cao, chủ ý
phá hoại.
1/5/2016 Trang 32
Nội dung
Tại sao phải kiểm thử (testing) phần
mềm?
Testing là gì?
Những nguyên lý tổng quát trong
testing
Quy trình Testing cơ bản
Triết lý của việc Testing
Những định nghĩa cơ bản
Các kiểu kiểm thử
1/5/2016 Trang 33
Qui trình kiểm thử phần mềm
1/5/2016 Trang 34
Lập kế
hoạch test
Thiết kế
test
So sánh kết quả
test với test case
Chuẩn bị dữ
liệu test
Chạy ứng dụng
với bộ dữ liệu test
Test Report
Test Results
Test Data
Test CaseTest plan
Các hoạt động kiểm thử
1/5/2016 Trang 35
Cài đặt và chuẩn bị
Test
Bắt đầu
Lập kế hoạch Test
Thiết kế Test
Test tích hợp
Kết thúc
Test hệ thống
Tổng hợp, báo cáo
Xem xét và Đánh
giá kết quả test
Chuẩn bị
Test
Phân tích kết
quả
Lập kế
hoạch
Các hoạt động kiểm thử
1/5/2016 Trang 36
Cài đặt và chuẩn bị
Test
Bắt đầu
Lập kế hoạch Test
Thiết kế Test
Test tích hợp
Kết thúc
Test hệ thống
Tổng hợp, báo cáo
Xem xét và Đánh giá
kết quả test
Kế hoạch test
Test case
Test procedure
Test scrip
Test data
Môi trường
Lỗi
Biên bản test
Bcáo KQ test
Đề xuất
Bcáo tổng hợp test
Hồ sơ
Các hoạt động kiểm thử
1/5/2016 Trang 37
Construction Thử nghiệm
Construction Lập trình
Solution Thiết kế kiến trúc
Definition Xác định yêu cầu
Cài đặt và chuẩn bị
Test
Bắt đầu
Lập kế hoạch Test
Thiết kế Test
Test tích hợp
Kết thúc
Test hệ thống
Tổng hợp, báo cáo
Xem xét và Đánh giá
kết quả test
Termination (Kết thúc)
Transition (Triển khai)
Definition (Xác định yêu cầu)
Solution (Thiết kế kiến trúc)
Construction (Xây dựng)
Coding (lập trình)
Testing (thử nghiệm)
Initiation (khởi động)
Lập kế hoạch Test
Định nghĩa
Nhận dạng các chiến lược được dùng để
Testing và đảm bảo rằng sản phẩm
thỏa mãn đặc tả thiết kế phần mềm và
các yêu cầu khác về phần mềm.
Định nghĩa các mục tiêu và phạm vi của
Test.
Nhận dạng phương pháp luận mà đội
Test sẽ dùng để thực hiện công việc
Test.
1/5/2016 Trang 38
Lập kế hoạch Test
Định nghĩa
Nhận dạng phần cứng, phần mềm và
các tiện ích cần cho Test.
Nhận dạng các tính chất và chức năng
sẽ được Test.
Xác định các hệ số rủi ro gây nguy hại
cho việc Test.
Lập lịch Test và phân phối công việc
cho mỗi thành viên tham gia.
1/5/2016 Trang 39
Kế hoạch Test
Giới thiệu
Mục đích
Thông tin chung
Tài liệu liên quan
Phạm vi test
Ràng buộc
Liệt kê các rủi ro
Chiến lược Test
Phương thức
Môi trường Test
1/5/2016 Trang 40
Tài Nguyên
Nhân lực
Hệ thống
Các mốc thời gian
chính (Milestones)
Tiêu chí dừng Test
Phân tích thiết kế Test-Case
Mỗi testcase chứa các thông tin cần thiết
để Test thành phần phần mềm theo 1 mục
tiêu xác định. Thường testcase gồm bộ 3
thông tin:
Tập dữ liệu đầu vào
Trạng thái của thành phần phầm mềm
Tập kết quả kỳ vọng
1/5/2016 Trang 41
Phân tích thiết kế Test-Case
Các phương pháp thiết kế testcase
Test hộp đen (Black box testing)
Test hộp trắng (White box testing)
1/5/2016 Trang 42
output
Phân tích thiết kế Test-Case
Xem xét cơ sở cho việc Test:„ yêu cầu,
kiến trúc, thiết kế, giao tiếp (interface),
Đánh giá khả năng test (testability) của
các hệ thống và yêu cầu
Yêu cầu: hệ thống cần đáp ứng đủ nhanh
khi user tương tác
=> Hệ thống cần đáp ứng không quá 5s
với 20 người cùng truy cập
1/5/2016 Trang 43
Phân tích thiết kế Test-Case
Xác định và lập ưu tiên các điều kiện
Test
Thiết kế và lập ưu tiên các Test-case
Xác định tập dữ liệu cần thiết hỗ trợ
Test-case
Thiết kế việc thiết lập môi trường Test
cũng như hạ tầng và những công cụ
cần thiết
1/5/2016 Trang 44
Thực hiện Test
Testers sẽ được bố trí công việc bởi Test
Leader để thi hành Testing
Lập thứ tự ưu tiên các testcase
Thi hành Testing theo từng testcase bằng tay
hay tự động
Thực hiện Testing đặc biệt (ad-hoc)
Thực hiện kịch bản Testing mà không được
định nghĩa trong testcase.
Testing lại các lỗi đã được sửa.
Tester sẽ tạo các báo cáo về lỗi trong suốt
quá trình kiểm lỗi và theo dõi chúng cho đến
khi chúng đã được xử lý.
1/5/2016 Trang 45
Thực hiện Test
1/5/2016 Trang 46
Nhận bản build
thực hiện Test
Sẳn sàng?
Từ chối Build
Tạo kết quả
test
No
Tìm thấy lỗi?
Đạt?
Yes
Thực hiện Test
(test cases)
Re-Test
(Fixed defects)
Đóng lỗi
Yes
No
Đệ trình/ Re-Open
Lỗi đến tracking system (*)
No
Yes
(*) See more in Defects Workflow
Thực hiện Test
1/5/2016 Trang 47
Thật sự lỗi?
Đóng lỗi
No
Re-Test đạt?
Yes
Phân cho Tester
Xem xét lại bởi
Test Lead, Dev Lead, PM
Yes
No
Lỗi trong hệ thống
No
Yes
Không rõ lỗi?
Phân ngược lại Tester
để thêm thông tin
Phân Developer
để sửa
Lỗi đã sửa?
Lỗi chưa giải
quyết
Giải thích tại sao
được chấp nhận
Bởi PM/Leader
Cập nhật thêm
Thông tin
Giải thích tại sao
đóng lỗi
Yes
No
Đánh giá - Lập báo cáo
Tạo các báo cáo lỗi.
Đánh giá các kết quả Testing, thống kê
các yêu cầu thay đổi.
Tính và phân phối các thông tin đo
lường hoạt động Testing.
Tạo bảng tổng kết đánh giá hoạt động
Testing.
Xác định xem đã đạt tiêu chí thành
công và hoàn thành Testing chưa.
1/5/2016 Trang 48
Hoạt động kết thúc Testing
Hoạt động này chỉ thực hiện khi:
Phần mềm đã được chuyển giao
Dự án bị hủy (Cancel)
Milestone được hoàn thành
1/5/2016 Trang 49
Hoạt động kết thúc Testing
Công việc chính
Kiểm tra công việc đã phân theo kế hoạch
và tất cả các khiếm khuyết đã được giải
quyết
Hoàn tất và cất giữ các Testware (các
scripts, môi trường Testing, hạ tầng) để sử
dụng sau này
Bàn giao testware đến tổ chức bảo trì
Phân tích bài học học được
1/5/2016 Trang 50
Nội dung
Tại sao phải kiểm thử (testing) phần
mềm?
Testing là gì?
Những nguyên lý tổng quát trong
testing
Quy trình Testing cơ bản
Các kiểu kiểm thử
1/5/2016 Trang 51
Các kiểu kiểm thử
Testing Type
Kiểm thử Chức năng - Function Test
Kiểm thử Phi chức năng - Non-Functional
Test
Kiểm thử Hồi quy - Regression Test
Kiểm thử cài đặt
Kiểm thử khả năng tương thích
Kiểm thử sự phá hủy
Kiểm thử hiệu suất phần mềm
Kiểm thử tính khả dụng
Kiểm thử bảo mật
Tính toàn cầu và bản địa hóa
1/5/2016 Trang 52
Kiểm thử chức năng
Function Test
Chức năng là những gì mà chương trình có thể đáp
ứng được mô tả rõ ràng trong các tài liệu:
Trường hợp sử dụng (Use case)
Yêu cầu chức năng
Có thể thực hiện tại tất cả các cấp độ Test
Không quan tâm đến các khía cạnh khác như giao
diện đẹp, xấu, dễ sử dụng hay không, thời gian xử
lý nhanh hay chậm,...
Test chức năng có thể được hoàn thành từ 2
hướng:
Dựa trên yêu cầu (Requirement)
• Bản mô tả tóm lược những chức năng cần Test hay không
cần Test
Dựa trên quy trình nghiệp vụ
• Dựa trên những nghiệp vụ hằng ngày
• Hay những trường hợp sử dụng thực tế
1/5/2016 Trang 53
Kiểm tra Phi chức năng
Non-Functional Test
Test những chức năng làm hệ thống tốt
hơn, không có những chức năng này hệ
thống vẫn hoạt động được nhưng rất
khó được sự chấp nhận của người sử
dụng
Có thể thực hiện tại tất cả các cấp độ
Test
ISO/IEC 9126, 2001 đã định nghĩa rất
nhiều tiêu chí chất lượng về Phi chức
năng
1/5/2016 Trang 54
ISO/IEC 9126, 2001
Tính năng (Functionality)
Tính phù hợp (Suitability)
Tính chính xác (Accuracy)
Khả năng tương tác
(Interoperability)
Tính bảo mật/an toàn (Security)
Tính tin cậy (Reability)
Tính hoàn thiện (Maturity)
Khả năng chịu lỗi (Fault tolerant)
Khả năng phục hồi (Recoverability)
Tính khả dụng (Usability)
Dễ hiểu (Understandability)
Dễ học (Learnability)
Khả năng vận hành (Operability)
Tính hấp dẫn (Attractiveness)
1/5/2016 Trang 55
Tính hiệu quả (Efficiency)
Thời gian xử lý (Time behavior)
Sử dụng tài nguyên (Utilization)
Khả năng bảo trì
(Maintainability)
Khả năng phân tích (Analysability)
Khả năng thay đổi được
(Changeability)
Tính ổn định (Stability)
Khả năng kiểm thử được (Testability)
Tính khả chuyển (Portability)
Khả năng thích nghi (Adaptability)
Khả năng cài đặt (Installability)
Khả năng chung sống (Co-existence)
Khả năng thay thế được
(Replaceability)
Kiểm thử hồi quy
Regression Test
Mỗi lần một module mới được thêm vào
phần mềm sẽ thay đổi:
Các đường dẫn luồng dữ liệu mới
Các thay đổi có thể gây nên các vấn đề với
các chức năng đã làm việc hoàn hảo trước
đó.
Kiểm thử hồi qui là việc thực hiện lại
một số tập con các kiểm thử đã được
thực hiện trước đó để đảm bảo rằng các
thay đổi mới không sinh ra những hiệu
ứng không mong muốn
1/5/2016 Trang 56
Kiểm thử hồi quy
Regression Test
Kiểm thử hồi quy có thể thực hiện thủ công,
bằng cách thực hiện lại tập con tất cả các
trường hợp kiểm thử hoặc có thể thực hiện tự
động
Bộ kiểm thử hồi quy (tập con các kiểm
thử sẽ được thực thi) gồm ba lớp các
trường hợp kiểm thử khác nhau:
Một mẫu đại diện của các kiểm thử sẽ thực
hiện tất cả các chức năng chính của phần
mềm
Các trường hợp kiểm thử bổ sung tập trung vào
các chức năng phần mềm có khả năng bị tác
động khi có sự thay đổi
Các kiểm thử tập trung vào các thành phần mới
1/5/2016 Trang 57
Kiểm thử hồi quy
Regression Test
Ví dụ:
Một phần mềm đang phát triển khi kiểm tra nó chạy tốt
các chức năng A, B và C.
Thay đổi code của chức năng C:
• Nếu chỉ kiểm tra chức năng C thì chưa đủ, cần phải kiểm
tra lại tất cả các chức năng khác liên quan đến chức năng
C (A, B).
• Lý do là khi C thay đổi, nó có thể sẽ làm A và B không còn
làm việc đúng nữa.
Hệ quả của kiểm thử hồi quy:
Thường tốn rất nhiều thời gian và công sức.
Không được phép bỏ qua vì có thể dẫn đến tình trạng
phát sinh hoặc tái xuất hiện những lỗi nghiêm trọng,
mặc dù ta “tưởng rằng” những lỗi đó hoặc không có
hoặc đã được kiểm tra và sửa chữa rồi.
1/5/2016 Trang 58
Các kiểu kiểm thử khác
Kiểm thử cài đặt
Đảm bảo rằng hệ thống được cài đặt đúng
theo file hướng dẫn trên thiết bị thực tế
Kiểm thử khả năng tương thích
Với các hệ điều hành
Hoặc với các phần mềm ứng dụng khác
(có thể là các phiên bản cũ hay mới của hệ
điều hành)
Hoặc môi trường thiết bị phần cứng khác
như trên destop, laptop, tablet hay smart
phone
1/5/2016 Trang 59
Các kiểu kiểm thử khác
Kiểm thử sự phá hủy
Cố gắng làm hỏng phần mềm hoặc một hệ
thống con.
Nó xác minh rằng các phần mềm có chức
năng đúng ngay cả khi nó nhận được đầu
vào không hợp lệ hoặc không mong muốn
Kiểm thử hiệu suất phần mềm
Kiểm thử tính khả dụng
Kiểm thử bảo mật
Tính toàn cầu và bản địa hóa
1/5/2016 Trang 60
ĐẢM BẢO VÀ KIỂM SOÁT
CHẤT LƯỢNG
611/5/2016
Bài tập
1) Hãy nêu ra những cách thức để có thể test được
phần lớn các trường hợp của màn hình bên dưới
với chi phí thấp nhất và hiệu quả có thể chấp nhận
được
1/5/2016 Trang 62
Bài tập
2) Viết 1 kế hoạch Test theo mẫu cho 1 dự án
cụ thể
3) Viết những test ca