Chương 4 cung cấp kiến thức về các kỹ thuật kiểm tra tĩnh. Trong chương này người học sẽ tìm hiểu những nội dung cơ bản sau: Các phương pháp Testing (Kiểm thử tĩnh, kiểm thử động), các kiểu rà soát (Review), phân tích tĩnh. Mời các bạn cùng tham khảo.
AMBIENT/
Chủ đề:
Nội dung Text: Bài giảng Đảm bảo và kiểm soát chất lượng phần mềm: Chương 4 - Nguyễn Mạnh Tuấn
- ĐẢM BẢO VÀ KIỂM SOÁT
CHẤT LƯỢNG
Chương 4:
Các kỹ thuật kiểm tra
tĩnh
HCM – 10/2012
4/23/2014 1
- Nội dung
Các phương pháp Testing
Kiểm thử tĩnh
Kiểm thử động
Các kiểu rà soát (Review)
Phân tích tĩnh
4/23/2014 Trang 2
- Các phương pháp Testing
Static Dynamic
Reviews etc.
Static Analysis
Behavioural
Inspection
Walkthroughs Structural Non-functional Functional
Desk-checking etc. etc.
Control Usability Equivalence
Data Flow Partitioning
Flow Performance
etc. Boundary
etc. Value Analysis
Statement
Symbolic
Execution Branch/Decision Arcs Cause-Effect Graphing
Definition Branch Condition LCSAJ Random
-Use
Branch Condition State Transition
Combination
4/23/2014 Trang 3
- Kiểm thử tĩnh
Phân tích tĩnh thực hiện mà không cần
thực thi hệ thống thực sự. Điều này
ngược với kiểm thử động
Thường thì nó không kiểm thử chi tiết
mà chủ yếu kiểm tra tính đúng đắn của
code (mã lệnh), thuật toán hay tài liệu
Đây chính là verification trong mô
hình V&V
Những thực hiện: lập trình viên và QC
4/23/2014 Trang 4
- Lợi ích
Bổ sung cho kiểm tra động trong giai đoạn kiểm chứng
chương trình
Có thể phát hiện sớm 30%-70% lỗi
Chi phí chỉnh sửa một khiếm khuyết tăng lên nhanh
chóng sau mỗi giai đoạn. trong thiết kế tốn phí 1.0,
trước kiểm thử: 6.5, trong kiểm thử:15 và sau phân
phối sẽ từ 60 đến 100
Nhận diện tổng quát, các lỗi sớm được phát hiện.
Chi phí thấp hơn nhưng lại đạt được khả năng sửa lỗi
phù hợp hơn, tốt hơn
Chỉ ra một “lô” các lỗi “liên quan”
Sửa toàn thể (một loạt) lỗi sau đó
Phát hiện sự phụ thuộc, thiếu nhất quán
Nâng cao khả năng bảo trì mã/chương trình
N„ găn ngừa khiếm khuyết
4/23/2014 Trang 5
- Chi phí sửa lỗi trong quá trình
phát triển
4/23/2014 Trang 6
- Kiểm thử động
Kiểm thử động cần thực thi hệ thống
thực sự bao gồm nhập các giá trị đầu
vào và kiểm tra xem liệu đầu ra có như
mong muốn hay không
Đây chính là validation trong mô hình
V&V
Các phương pháp kiểm thử động gồm
có kiểm thử Unit – Unit Tests, Kiểm thử
tích hợp – Intergration Tests, Kiểm thử
hệ thống – System Tests, và Kiểm thử
chấp nhận sản phẩm – Acceptance
Tests
4/23/2014 Trang 7
- Kiểm thử Tĩnh vs. Kiểm thử Động
4/23/2014 Trang 8
- Nội dung
Các phương pháp Testing
Kiểm thử tĩnh
Kiểm thử động
Các kiểu rà soát (Review)
Phân tích tĩnh
4/23/2014 Trang 9
- Thế nào là rà soát (Review)
Review là quá trình kiểm tra có hệ thống
được thực hiện bởi 1 hay nhiều người với
mục tiêu chính là tìm kiếm và loại bỏ
những khiếm khuyết
Mục tiêu của rà soát:
Tìm kiếm khiếm khuyết
Thu sự hiểu biết
Tạo sự thảo luận
Review giúp xác định lỗi trước khi chúng
trở thành 1 phần của code thực thi
Làm những lỗi rẻ hơn và dễ sửa hơn
4/23/2014 Trang 10
- Các loại lỗi
Ba loại lỗi có ở mỗi bước của quá trình
phát triển phần mềm:
Lỗi mới được sinh ra
Lỗi còn lại của các bước trước
Lỗi được phóng đại lên do các nhân tố lỗi
của các bước trước
Nếu không rà soát lỗi tồn lại gia tăng
nhanh, và chi phí cho việc loại trừ các
lỗi ngày càng lớn; Nguyên tắc xử lý lỗi:
“chi phí bây giờ hay để lại sau phải với
chi phí nhiều hơn?”
4/23/2014 Trang 11
- Review: Chi phí và lợi ích
Chi phí
Thời gian
Sự nỗ lực thu thập và phân tích các yếu tố
(metrics)
Lợi ích
Lịch biểu ngắn hơn
Chu kỳ kiểm tra ngắn hơn, chi phí kiểm thử
thấp hơn
Gia tăng năng suất
Cải tiến chất lượng sản phẩm
4/23/2014 Trang 12
- Tiến trình chung của hoạt động
rà soát
4/23/2014 Trang 13
- Vai trò và Trách nhiệm
Điều phối/Chủ trì (Moderator):
Chủ trì các cuộc họp
Thư ký:
Tập hợp thông tin về tìm kiếm lỗi
Tác giả:
Mô tả, giải thích và trả lời các câu hỏi
Người rà soát (Reviewer/inspector):
Tìm kiếm lỗi
Người quản lý:
Lập kế hoạch, sắp xếp tài nguyên và việc huấn luyện,
hỗ trợ, phân tích các yếu tố quy trình
Đôi khi, một người có thể đóng nhiều vai trò
Tác giả đôi khi đóng vai trò như Trung gian
Một trong những người rà soát làm thư ký
4/23/2014 Trang 14
- Cuộc họp rà soát
Mọi cuộc họp rà soát phải:
Gồm từ 3 đến 5 người liên quan.
Phải chuẩn bị trước (1 người không quá2
giờ).
Cuộc họp chỉ nên từ 2-3 giờ. Mỗi cuộc họp rà
soát chỉ hạn chế trong một phần nhỏ, cụ thể.
Kết luận đưa ra 1 trong 3 quyết định sau:
Chấp nhận sản phẩm không cần chỉnh sửa
Khước từ sản phẩm vì những lỗi nghiêm trọng
Chấp nhận cho chỉnh sửa sản phẩm, sau khi
chỉnh sửa phải rà soát lại
4/23/2014 Trang 15
- Sản phẩm rà soát
Sản phẩm của cuộc họp rà soát:
Báo cáo các vấn đề nảy sinh do các cá
nhân rà soát nêu ra
Một danh sách các vấn đề cần giải quyết
Một văn bản tổng kết cuộc họp rà soát đó.
Văn bản tổng kết họp rà soát phải chỉ
rõ:
Đã rà soát cái gì
Ai rà soát
Tìm thấy cái gì và Kết luận ra sao
4/23/2014 Trang 16
- Những gì có thể được rà soát?
Bất kỳ thứ gì được viết ra:
Hợp đồng, chính sách, kế hoạch kinh
doanh
Yêu cầu, đánh giá mức độ khả thi, kế
hoạch kiểm tra chấp nhận (Acceptance
Test)
Kế hoạch Test, Test case, kết quả test
Bản thiết kế, CSDL
Source code
User guide, training
…
4/23/2014 Trang 17
- Nhân tố Rà soát thành công
Huấn luyện kỹ càng Phải có sự chuẩn bị
Rà soát cả chức năng – Rà soát sản phẩm,
phi chức năng không rà soát người
Lập và theo danh sách làm ra nó
kiểm tra (checklist)
Giới hạn tranh cãi
Tập trung tìm kiếm“vấn
đề”, không đi vào giải
quyết
Nắm rõ các ghi chú đã
viết
Giới hạn, cẩn thận chọn
lựa người tham gia
4/23/2014 Trang 18
- Các kiểu Review
4/23/2014 Trang 19
- Kiểm lại (Desk checking)
Start
Tác giả sẽ gởi tài liệu,
source code… cho Author Tự review
người cần rà soát
Author Dựa trên kế hoạch review,
thông báo cho reviewers
Reviewer Review và phát hiện lỗi
Author Sửa lỗi
Reviewer Kiểm tra lại
End
4/23/2014 Trang 20
Thêm vào BST
Báo xấu
Download
Vui lòng tải xuống để xem tài liệu đầy đủ
