Bài giảng Đảm bảo chất lượng phần mềm: Kiểm chứng sản phẩm giới thiệu nội dung về dùng mẫu thử, lỗi phần mềm, kiểm thử phần mềm, thiết kế testcase, các kỹ thuật debuging. mời các bạn tham khảo nội dung chi tiết.
AMBIENT/
Chủ đề:
Nội dung Text: Bài giảng Đảm bảo chất lượng phần mềm: Kiểm chứng sản phẩm - Nguyễn Anh Hào
- 1
SW Quality Assurance
05. Validation
(kiểm chứng sản phẩm)
Nguyễn Anh Hào
Khoa CNTT2
Học viện CNBCVT – Cs Tp.HCM
- 2 Validation
1. Là hành động để bảo đảm rằng đặc tả yêu
cầu cho phần mềm là đúng và đầy đủ so với
mong đợi
Ví dụ: hiện thực hoá những hiểu biết về PM thành
mẫu thử để đối chiếu với mong muốn.
2. Là hành động để bảo đảm rằng PM được làm
ra sẽ hoặc đã thỏa mãn mọi yêu cầu đã được
cam kết.
Thường được hiểu là hết lỗi, ie, không tìm được
chứng cứ của lỗi trong PM. Vd: Định nghĩa và
thực hiện hết các testcase trong unit-test,
system test, acceptance test,..
- 3 1.Dùng mẫu thử
Mẫu thử
Mẫu thử được dùng để sửa hoặc thêm yêu cầu
- 4 Prototype
- 5 2. Software errors
ANALISYS
DESIGN
CODE
DEBUG
- 6 Lỗi phần mềm
1. Tình huống nào thì phần mềm được cho là có
lỗi ?
Thực hiện sai yêu cầu
Không thực hiện được chức năng
Không thỏa mãn yêu cầu về tính năng
…
- 7 Lỗi phần mềm : ngôn từ
Error: là “sự hư hỏng” trong bản thân chương
trình (vd: logic bị sai).
Fault: là “sự hư hỏng” trong chức năng xử lý
của chương trình do error gây ra.
Failure : là “sự hư hỏng” nhận biết được, khi
phần mềm đang chạy đụng đến fault.
Không chắc là fault sẽ luôn luôn gây ra failure.
Defect: là khiếm khuyết của chương trình theo
cách đánh giá của người dùng (không hẳn là do
failures).
- 8 Lỗi phần mềm: vài nguyên nhân
1. Người yêu cầu (khách hàng) định nghĩa sai
yêu cầu cho phần mềm.
2. Hiểu lầm giữa khách hàng và người phát triễn.
3. Người phát triễn pm hiểu sai yêu cầu
4. Sai thiết kế luận lý (sai thiết kế về mặt ý niệm)
5. Sai mã lệnh.
6. Chương trình thực thi không đúng với yêu cầu
7. Thiếu kiểm thử
8. Lỗi sai trong thủ tục vận hành
9. Lỗi sai trong các tài liệu hướng dẫn sử dụng.
- 9 Kiểm thử phần mềm : quan điểm
1. Phần mềm có chất lượng tốt là phần mềm không có
failure => kiễm thử mọi test case ?
Dijkstra: kiểm thử chỉ khẳng định PM có lỗi, không
thể khẳng định PM hết lỗi, do tổ hợp input-output quá
lớn, điều khiển phức tạp hoặc môi trường sử dụng đa
dạng (SW Testting & QA from theory to practice,
P13)
2. Phát hiện để sửa lỗi trên các ấn phẩm ban đầu (đặc
tả yêu cầu, bản thiết kế) trước khi sử dụng là rất
cần thiết, để tránh phải làm lại.
Chứng minh cho cách làm và kiễm thử sản phẩm là 2
hành động hổ trợ lẫn nhau; ie ta cần chọn lựa hành
động cho phù hợp.
3. Ngăn ngừa lỗi vẫn tốt hơn là sửa lỗi.
4. Tự động hoá kiễm thử là cần thiết
- 10 Testing
Là hành động tìm chổ sai trong các ấn phẩm
của PM so với yêu cầu, bằng cách thực thi SP
PM hoặc mẫu thử của ấn phẩm.
Có 4 mức: Unit, integration, system &
Acceptance test
Regression test : tìm hiệu ứng lề khi cập nhật
ấn phẩm; nó là một phần trong 4 loại test trên
Testing còn gọi là kiểm thử có thực thi ≠ kiểm
thử phi thực thi (verification) : code inspection,
code walk-through,…
Testing ≠ Debug: để hiểu cách thực thi của PM
SW testing and quality assurance from theory to practice.pdf P16
- 11 Testing levels
1. Kiểm thử trên từng mô đun (unit)
Mô-đun có được thực thi đúng ?
2. Kiểm thử tích hợp nhiều mô đun (integration)
Các mô-đun có kết hợp được thành hệ thống ?
Giao tiếp giữa các mô-đun có đúng ?
3. Kiểm thử hệ thống (system)
Xem xét mức độ thỏa mãn yêu cầu của PM trong
môi trường chạy (functionality, performance,
reliability, security,…)
4. Kiểm thử chấp nhận (acceptance)
Chạy PM trong môi trường sử dụng của users
PM có thoả yêu cầu ? (peak workload performance,
response-time, human factors test, procedures,
backup & recovery)
- 12 Testing Levels
SW testing and quality assurance from theory to practice.pdf P16
- 13 Black box & White box testing
Black box testing = functional testing: không
cần biết cách thực thi chương trình, chỉ cần biết
logic của chức năng để định nghĩa dữ liệu test
(inputs, expected outcome)
White box testing = structural testing: xem xét
source code (data flow & control flow) để đưa ra
các testcase
- 14 Test case design
Thiết kế test-case: verification
Thực thi test-case: validation
- 15 Thiết kế testcase : test case gì cần ?
1. Từ usecase & tương tác trong usecase
(requirements)
2. Xem xét các trạng thái chấp nhận được và
không chấp nhận được từ mỗi hành động xử
lý của usecase trong lược đồ hoạt động, tuần
tự, trạng thái
3. Lập ra các test-case
4. Lập test procedures/scripts theo UI design
5. Lập ra test plan
- 16 Test plan
Test cases, dựa trên chức năng của PM
Test scripts, dựa trên cách xử lý của chức
năng
Test data (inputs, expected outcome) dựa trên
logic của chức năng
Thủ tục lưu trữ & sử dụng kết quả test (pass,
fail, inconclusive, reports)
Trình tự các bước thực hiện (schedule)
Yêu cầu về phần cứng, phần mềm và các
ràng buộc trong khi test (thiết lập môi trường
test)
- 17 Bao nhiêu cái test-case thì đủ ?
Nếu một chương trình đã được test và sửa
lỗi thì có phải là nó không còn lỗi, hay bộ
testcase chưa đủ để phát hiện các lỗi còn
lại ?
Nguyên lý McCabe: chỉ ra số test-case tối
thiểu cho một function (→coverage)
- 18 Control flow graph (CFG)
Basis_Path_Testing.pdf
SW testing & QA theory & practice.pdf (trang 89)
- 19 Control flow graph (CFG)
- 20 Control flow graph: example 1
Thêm vào BST
Báo xấu
Download
Vui lòng tải xuống để xem tài liệu đầy đủ
