Software testing
- Development testing
- Test-driven development
- Release testing
- User testing
Program testing
2 khái niệm q.trọng: verification và validation.
flowchart TB
p1["Phân tích"]
p2["Thiết kế"]
p3["Lập trình (verification, đáp ứng yêu cầu thiết kế requirements)"]
p4["Kiểm thử (validation)"]
p1-->p2-->p3-->p4
Kiểm tra tĩnh
Flow
flowchart TB
p1["Test plan"]
p2["Test design, anwser what question"]
p3["(1..1) Test case (1..*)"]
p4["Defect (0..*)"]
p5["(1..*) Usecase/Req/Us (1..1)"]
p1-->p2-->p3-->p4
p2-->p5
Test design ⇒ test case ⇒ thực hiện
Tham khảo: bug link, bugzilla
Mỗi công đoạn làm 1 phần nào đó. Với mỗi bạn làm ít nhất 1 công đoạn ở 1 chức năng nào đó.
Cần có test report ⇒ tránh các lỗi phát sinh khi demo chương trình
Phải viết test report ⇒ báo cáo lỗi
Bộ test case phải đủ tốt để tìm ra lỗi. Có sửa phải test lại.
| Sau khi viết test case ⇒ thực hiện thủ công | viết chương trình thực hiện tự động. |
Dev viết unit test.
Chọn thủ công hay tự động dựa vào việc đánh giá. Phải có test data ⇒ mất thời gian nếu test case phức tạp.
Thêm chức năng mới ⇒ kiểm thử tự động để giảm bớt thời gian.
Chức năng không thay đổi ⇒ Viết test tự động ⇒ xác định trong test plan.
Quan trọng vẫn là test case
Test driven development
Viết code cho sp ⇒ test coi đúng chưa ⇒ nếu chưa thì chỉnh code ⇒ thực hiện đến khi mọi thứ đã đc fix ⇒ Đi đến chức năng kế.
Xác định chức năng cần viết test ⇒ viết test ⇒ chạy test ⇒ pass thì quay lại từ đầu ⇒ fail thì cập nhật code chức năng lại và chạy lại test.
Thực tế ít công ty áp dụng cách này.
Sequence diagram
Không nói đến thứ tự thực hiện. Chỉ để demo cách server/app vs người dùng giao tiếp.
Nếu code và sequence diagram không link vs nhau ⇒ cần xem lại.
Sequence diagram quá chi tiết ⇒ có khả năng áp dụng reverse engine ⇒ không cần sequence diagram quá chi tiết.
Viết một cách tổng quan, không quá chi tiết.
Nếu am hiểu về các hoạt động ⇒ có thể không cần vẽ diagram.
Written at Software Technology’s session