1. KIỂM TRA PHẦN MỀM LÀ GÌ?
“Chạy thử" PM hay một chức năng của
PM, xem nó "chạy" đúng như mong muốn hay
không
Có thể thực hiện từng chặng, sau mỗi chức
năng hoặc module được phát triển, hoặc thực
hiện sau cùng, khi PM đã được phát triển hoàn
tất(PM nhỏ)
Bước đệm giữa giai đoạn xây dựng PM và
sử dụng PM, trước khi giao sản phẩm hoàn
chỉnh cho khách hàng
3. Test case & Test Script
• Testcase: Một tình huống kiểm tra, được
thiết kế để kiểm tra một đối tượng có thỏa
mãn yêu cầu đặt ra hay không
– Mô tả: Đặc tả các điều kiện cần có để tiến
hành kiểm tra
– Input: Dữ liệu đầu vào
– Output: Kết quả trả về mong muốn
4. Test case & Test Script
• Test Script: Một nhóm mã lệnh tự động
hóa một trình tự kiểm tra, giúp cho việc
kiểm tra nhanh hơn, hoặc cho những
trường hợp mà kiểm tra bằng tay sẽ rất
khó khăn hoặc không khả thi.
– Các Test Script có thể tạo thủ công hoặc tạo
tự động dùng công cụ kiểm tra tự động.
5. Unit Test – Kiểm tra mức đơn vị
• Unit: Một thành phần PM nhỏ nhất mà ta
có thể kiểm tra được:
Function, Procedure, Class, Method...
• Do lập trình viên thực hiện và càng
sớm càng tốt trong giai đoạn viết code và
xuyên suốt chu kỳ PTPM
• Unit Test đòi hỏi phải chuẩn bị trước các
test case hoặc test script, trong đó chỉ định
rõ dữ liệu vào, các bước thực hiện và dữ
liệu mong chờ sẽ xuất ra
6. Unit Test – Kiểm tra mức đơn vị
• Mục đích: Bảo đảm thông tin được xử lý
và xuất (khỏi Unit) là chính xác
• Thời gian tốn cho Unit Test sẽ được đền
bù bằng việc tiết kiệm rất nhiều thời gian
và chi phí cho việc kiểm tra và sửa lỗi ở
các mức kiểm tra sau đó
7. Integration Test – Kiểm tra tích hợp
• Kết hợp các thành phần của một ứng
dụng và kiểm tra như một ứng dụng đã
hoàn thành
• Kết hợp các thành phần lại với nhau và
kiểm tra sự giao tiếp giữa chúng
• Mục tiêu:
– Phát hiện lỗi giao tiếp xảy ra giữa các Unit
– chuẩn bị cho kiểm tra ở mức hệ thống
(System Test).
8. Integration Test – Kiểm tra tích hợp
• Mọi giao tiếp liên quan đến Unit thật sự
được kiểm tra đầy đủ khi các Unit tích hợp
với nhau trong khi thực hiện Integration
Test
• Chỉ nên thực hiện trên những Unit đã
được kiểm tra cẩn thận trước đó bằng
Unit Test, và tất cả các lỗi mức Unit đã
được sửa chữa
9. Integration Test – Kiểm tra tích hợp
• Nên tích hợp dần từng Unit.
Một Unit tại một thời điểm được tích hợp vào
một nhóm các Unit khác đã tích hợp trước đó
và đã hoàn tất các đợt Integration Test trước
đó
10. Integration Test – Kiểm tra tích hợp
• Các loại:
– Kiểm tra cấu trúc: (Tương tự White Box Test)
• Nhằm bảo đảm các thành phần bên trong của một chương trình
chạy đúng
• Chú trọng đến hoạt động của các thành phần cấu trúc của
chương trình chẳng hạn các lệnh và nhánh bên trong
– Kiểm tra chức năng (Tương tự Black Box Test )
• Kiểm tra chỉ chú trọng đến chức năng của chương trình, không
quan tâm đến cấu trúc bên trong
• Chỉ khảo sát chức năng của chương trình theo yêu cầu kỹ
thuật.
– Kiểm tra hiệu năng (Performance): Kiểm tra việc vận hành
của hệ thống
– Kiểm tra khả năng chịu tải(stress):Kiểm tra các giới hạn
của hệ thống
11. System Test - Kiểm tra mức hệ thống
• Kiểm tra thiết kế và toàn bộ hệ thống (sau khi tích
hợp) có thỏa mãn yêu cầu đặt ra hay không
• Bắt đầu khi tất cả các bộ phận của PM đã được
tích hợp thành công
• Các hình thức (không nhất thiết phải thực hiện tất
cả các hình thức)
– Kiểm tra chức năng (Functional Test)
– Kiểm tra khả năng vận hành (Performance Test)
– Kiểm tra khả năng chịu tải (Stress Test hay Load Test)
– Kiểm tra cấu hình (Configuration Test)
– Kiểm tra khả năng bảo mật (Security Test)
– Kiểm tra khả năng phục hồi (Recovery Test)
12. System Test - Kiểm tra mức hệ thống
• Kiểm tra chức năng (Functional Test)
– Bảo đảm các hành vi của hệ thống thỏa mãn đúng
yêu cầu thiết kế
• Kiểm tra khả năng vận hành
– Bảo đảm tối ưu việc phân bổ tài nguyên hệ thống (ví
dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý
hay đáp ứng câu truy vấn
• Kiểm tra khả năng chịu tải (Stress Test hay Load Test)
– bảo đảm hệ thống vận hành đúng dưới áp lực cao
– tập trung vào các trạng thái tới hạn, các "điểm
chết", các tình huống bất thường
13. System Test - Kiểm tra mức hệ thống
• Kiểm tra cấu hình (Configuration Test)
– Bảo đảm tính toàn vẹn, bảo mật của dữ liệu và
của hệ thống.
• Kiểm tra khả năng bảo mật
• Kiểm tra khả năng phục hồi
– Bảo đảm hệ thống có khả năng khôi phục trạng
thái ổn định trước đó trong tình huống mất tài
nguyên hoặc dữ liệu;
– Đặc biệt quan trọng đối với các hệ thống giao
dịch như ngân hàng trực tuyến
14. Acceptance Test - Kiểm tra nhận sản
phẩm
• Khách hàng thực hiện (hoặc ủy quyền cho
một nhóm thứ ba thực hiện).
• Mục đích: chứng minh PM thỏa mãn tất cả
yêu cầu của khách hàng và khách hàng
chấp nhận sản phẩm.
16. Lập kế hoạch kiểm tra
• Mục đích: Chỉ định và mô tả các loại kiểm
tra sẽ được triển khai và thực hiện.
• Thời diểm:Khi các yêu cầu đã tương đối
đầy đủ, các chức năng và luồng dữ liệu
chính đã được mô tả
17. Lập kế hoạch kiểm tra
• Kết quả : Tài liệu kế hoạch KTPM (master
test plan)
– Chi tiết từ các loại kiểm tra
– Chiến lược kiểm tra
– Thời gian và phân bổ kiểm tra viên
• Các bản kế hoạch chi tiết lần lượt được
thiết kế theo trình tự thời gian phát triển
của dự án
19. Các bước lập kế hoạch
• Xác định yêu cầu kiểm tra:
– Bộ phận, thành phần của PM cần kiểm tra
– Phạm vi hoặc giới hạn của việc kiểm tra
– Xác định nhu cầu nhân lực
• Khảo sát rủi ro
– Rủi ro xảy ra làm chậm hoặc cản trở quá trình cũng
như chất lượng kiểm tra(kỹ năng và kinh nghiệm của
kiểm tra viên )
• Chiến lược kiểm tra
– Phương pháp tiếp cận để thực hiện việc kiểm tra trên
PM
– Kỹ thuật và công cụ hỗ trợ kiểm tra
– Phương pháp dùng để đánh giá chất lượng kiểm tra
cũng như điều kiện để xác định thời gian kiểm tra
20. Các bước lập kế hoạch
• Xác định nguồn lực
– kỹ năng, kinh nghiệm của kiểm tra viên
– phần cứng, phần mềm, công cụ, thiết bị giả lập
• Lập kế hoạch chi tiết
– Ước lượng thời gian, khối lượng công việc
– Xác định chi tiết các phần công việc, người thực
hiện
– Thời gian tất cả các điểm mốc của quá trình kiểm
tra.
21. Các bước lập kế hoạch
• Tổng hợp và tạo các bản kế hoạch kiểm
tra:
– kế hoạch chung và kế hoạch chi tiết.
• Xem xét các kế hoạch kiểm tra
– Có sự tham gia của tất cả những người có
liên quan
– Bảo đảm các kế hoạch là khả thi, phát hiện và
sữa chữa các sai sót trong các bản kế hoạch
22. Thiết kế Test
• Mục đích:
– Chỉ định các Test Case và các bước kiểm tra chi
tiết cho mỗi phiên bản PM
– Bảo đảm tất cả các tình huống kiểm tra “quét” hết
tất cả yêu cầu cần kiểm tra
• Sửa chữa, cập nhật, thêm hoặc bớt xuyên
suốt chu kỳ PTPM, vào bất cứ lúc nào có sự
thay đổi yêu cầu, hoặc sau khi phân tích thấy
cần được sửa chữa hoặc bổ sung
23. Các bước thiết kế test
• Xác định và mô tả Test Case
– Xác định các điều kiện cần thiết lập trước và
trong lúc kiểm tra
– Mô tả đối tượng hoặc dữ liệu đầu vào
– Mô tả các kết quả mong chờ sau khi kiểm tra
• Mô tả các bước chi tiết để kiểm tra
– mô tả chi tiết để hoàn thành một Test Case
– chỉ định các loại dữ liệu nào cần có để thực thi
các Test Case (trực tiếp, gián tiếp, trung gian, hệ
thống…)
24. Các bước thiết kế test
• Xem xét và khảo sát độ bao phủ của việc kiểm tra
– xác định việc kiểm tra đã hoàn thành hay chưa?
– bao nhiêu phần trăm PM đã được kiểm tra
=> căn cứ trên yêu cầu của phần mềm hoặc căn cứ
trên số lượng code đã viết
• Xem xét Test Case và các bước kiểm tra
– có sự tham gia của tất cả những người có liên
quan, kể cả trưởng dự án nhằm bảo đảm các Test
Case và dữ liệu yêu cầu là đủ và phản ánh đúng các
yêu cầu cần kiểm tra, độ bao phủ đạt yêu cầu, cũng
như để phát hiện (và sữa chữa) các sai sót
26. Phát triển Test Script
• Mục đích: Tạo ra các Test Script có khả
năng chạy trên máy tính giúp tự động hóa
việc thực thi các bước kiểm tra đã định
nghĩa ở bước thiết kế test
• Không bắt buộc trong
27. Các bước phát triển Test Script
• Tạo Test Script
– thủ công
– công cụ hỗ trợ để phát sinh script một cách tự
động
– có khả năng tái sử dụng càng nhiều càng tốt
để tối ưu hóa công việc
• Chỉnh sửa
– chỉnh sửa từ test script có sẳn hoặc sinh bằng
công cụ
28. Các bước phát triển Test Script
• Thành lập các bộ dữ liệu ngoài dành cho
các Test Script
– bộ dữ liệu này sẽ được các Test Script sử
dụng khi thực hiện kiểm tra tự động
– Việc tách riêng dữ liệu cho phép dễ dàng thay
đổi dữ liệu khi kiểm tra, cũng như giúp việc
chỉnh sửa hoặc tái sử dụng các script sau này
29. Các bước phát triển Test Script
• Kiểm tra Test script
– bảo đảm các Test Script hoạt động đúng yêu
cầu
– thể hiện đúng ý đồ của các bước kiểm tra
• Xem xét và khảo sát độ bao phủ của việc
kiểm tra
– bảo đảm các Test Script được tạo ra bao phủ
toàn bộ các bước kiểm tra theo yêu cầu
30. Thực hiện kiểm tra
• Cách thức :
– Thủ công
– Test Script
• Đánh giá quá trình kiểm tra:
– giám sát quá trình kiểm tra suôn sẻ
– bổ sung hay sữa chữa để quá trình kiểm tra được tốt
hơn
– Nếu quá trình diễn ra trơn tru, kiểm tra viên hoàn
thành chu kỳ kiểm tra và chuyển qua bước “Thẩm
định kết quả kiểm tra”
– Nếu quá trình bị treo hoặc dừng giữa chừng, kiểm
tra viên cần phân tích để xác định nguyên nhân
lỗi, khắc phục lỗi và lập lại quá trình kiểm tra.
31. Thực hiện kiểm tra
• Thẩm định kết quả kiểm tra
• Xem xét để bảo đảm kết quả nhận được là đáng tin
cậy
• Những lỗi xảy ra không phải do PM mà do dữ
liệu dùng để kiểm tra, môi trường kiểm tra
hoặc các bước kiểm tra (hoặc Test Script)
• Lỗi xảy ra do quá trình kiểm tra, cần phải sửa
chữa và kiểm tra lại từ đầu
32. Đánh giá quá trình kiểm tra
• Mục đích: Đánh giá toàn bộ quá trình kiểm
tra
– xem xét và đánh giá kết quả kiểm tra
– liệt kê lỗi,
– chỉ định các yêu cầu thay đổi,
– tính toán các số liệu liên quan đến quá trình
kiểm tra
• Đánh giá kết quả kiểm tra toàn cục, nhằm
vào bản thân giá trị của các kết quả kiểm
tra
