Please enable JavaScript.
Coggle requires JavaScript to display documents.
Lí thuyết Kiểm Thư Phần Mềm (01 - Tổng quan (Định nghĩa (Verification (đặc…
Lí thuyết Kiểm Thư Phần Mềm
01 - Tổng quan
Định nghĩa
quá trình thực thi CT -> tìm lỗi
hoạt động kiểm tra Verification (chạy chính xác) và Validation (thỏa mãn y/c KH) -> chất lượng PM
Validation chiếm 80% hiệu quả
Testing - tìm input cho CT chạy sai
Debug - tìm lỗi từ KQ chạy sai của CT
Verification
đặc tả, thiết kế
lỗi lập trình
Validation
nhu cầu
lõi phân tích, thiết kế
Thứ tự : verification -> validation
Tại sao ?
Chi phí sữa lỗi có thể rất lớn
Tìm lỗi -> sửa lỗi
bảo đảm độ tin cậy + chất lượng
Hậu quả lỗi PM có thể gây ra rất lớn, thậm chí là chết người
Qui trình kiểm thử
Req
Lập Test plan
Thiết kế test -> phương pháp
Thiết lập Env/ Script
Test execution
Report (->6 : Re-test)
Closure
Phân tích -> test types, test levels
Static Testing (Ko chạy PM) - Dynamic Testing (chạy PM)
Thái độ của Tester
cẩn thận
tò mò
chỉ trích, phê phán
can đảm
Kĩ năng Tester
giao tiếp
đọc
giải quyết vấn đề
lập báo cáo
quản lí bản thân
ngoại ngữ
Lập test plan
chỉ định, mô tả các chiến lược kiểm thử
Yêu cầu, rủi ro, chiến lược, nhân lực/ thiết bị, lập KH chi tiết
Thiết kế
Bảo đảm bao phủ hết các tình huống cần ktra
02 - Kiểm thử trong Vòng đời PM
Kiểm thử tốt?
cho mỗi giai đoạn/ phần phát triển
liên tục, không trùng lặp
bắt đầu sớm, ngăn ngùa lỗi
Test Levels
Unit Testing
kiểm thử mỗi đơn vị trước khi tích hợp
thấp, cụ thể, chi tiết nhất
Mục tiêu : bào đảm mã nguồn từng đơn vị đúng theo đặc tả
Dev thực hiện
lỗi sửa ngay, không cần báo cáo
Intergration Testing
Mục tiêu : kiểm tra tương tác giữa các đơn vị/ hệ thống
Dev / Người thiết kế/ Tester
System Testing
bước cuối của của 2. Intergration Testing
Mục tiêu ; phát hiện sai sót trong toàn bộ hệ thống chạy trên môi trường
Tester
Acceptance Testing
Xác nhận đáp ứng đúng mong đợi người dùng
KH/ người sử dụng hoặc bên Tester thứ 3
Bước cuối cùng của Validation
Regression Testing
Kiểm tra lại khi có sự thay đổi
Test Types
Functional testing/ Black-box testing
Security
Performance testing
Usability
Recovery
Non-functional
Structural testing/ White-box testing
03 - Test Plan
Mô tả phạm vi, nhân lực và kế hoạch của các hoạt động test dự kiên
Input : req, Project plan, Tiêu chí chấp nhận
Output
How - Phương pháp
What - Test types/ levels
When
Who - ai thực hiện task nào
Where - Môi trường
Các tiêu chuẩn
Rủi ro + kế hoạch dự phòng
Cấu trúc
Giới thiệu
Yêu cầu Kiểm thử
Chiến lược kiểm thử
Tài nguyên
Các mốc thời gian
Các sản phẩm
4 - BlackBox Testing
Phân hoạch tương đương
Phân chia DL thành các lớp có cùng hành vi
Tạo ca kiểm thử cho mỗi lớp tương đương
Kiểm thử 1 giá trị đại diện
Giảm SL, tăng độ phủ
3 bước
XĐ input & output (có thể có thông báo lỗi)
XĐ lớp tương đương cho từng input & output
Dựa vào điều kiện đầu vào/ra
Lớp tương đương biểu diễn 1 tập hợp trạng thái
valid / invalid
XĐ các ca kiểm thử
Phân tích Giá trị biên
Dùng khi các lớp tương đương có thứ tự
Chọn các giá trị xoay quanh giá trị biên
Chọn các test case
Giá trị biên cho đầu vào
Giá trị đầu vào cho ra các giá trị biên đầu ra
Decision Table
dựa trên bảng chân trị
có nhiều điều kiện +phụ thuộc lẫn nhau
Bùng nổ khi có nhiều ĐK
4 bước
XĐ tập Cause & Effect
Lập bảng quyết định
Rút gọn bảng
Mỗi cột -> 1 test case
Cause-Effect Graph
dựa trên đồ thị Nguyên nhân/ kết quả
Giảm thiểu bùng nổ tổ hợp
5 bước
XĐ tập Cause & Effect
XĐ tập Luật (Rule = Cause -> Effect)
Vẽ đồ thị Cause - effect
Chuyển đồ thị sang Decision table rút gọn
Chuyển mỗi cột của Decision Table -> 1 test case
State Transition Testing
kiểm tra sự thay đổi trạng thái của hệ thống
3 bước
Mô hình -> Máy trạng thái or State transiton diagram
Lập bảng trạng thái -> xem xét các bước chuyển trạng thái có thể gây lỗi
Thiết kế test cases từ Bảng và Mô hình
Phủ tất cả các trạng thái
Phủ tất cả các bước chuyển trạng thái
5 - Test Case
3 bước
Mô tả - các ĐK cần
Nhập
Expected result
Test step
Test case - List test steps
Test Scenario - List test case và phối hợp của chúng
Cấu trúc
ID
Name
Precondition
Steps
Expected result
Actucal result
Status
Tester
Tested date
Remark
A good test case
Accurate
Economical - ko dư thùa
Repeatable, reusable
Traceable - test y/c nào
Appropriate
Self-standing
Self-cleaning
6- Test report
Bug report
báo cáo lỗi cho mỗi test case failed
Nội dung
ID, Name
Problem summary
How to reproduce it
Reported by, Date, Assign to
Status
Priority, Severity
Đặc điểm
written
numbered
simple
understandable
reproducible
legible - rõ ràng
non-judmental
Test summary report
Summary
Test case result report
Defect report
Status Bug
NEW
assigned
open
Dupplicate
fixed
pending retest
retest
reOpened
verified
closed
7 - WhiteBox testing
Kiểm thử đường cơ sở
Vẽ đồ thị lưu trình
Độ phức tạp?
Tập cơ sở các đường dẫn độc lập?
Thiết kế test case cho mỗi đường dẫn độc lập
Kiểm thử cấu trúc điều kiện
Dòng điều khiển
Statement Coverage - qua hết các đỉnh
Decision/branch Coverage - qua hết các cạnh
Condition Coverage
Path Coverage