Ví dụ: một PM đang phát triển khi kiểm tra cho thấy nó chạy tốt các chức năng A, B và C. Khi có thay đổi code của chức năng C, nếu chỉ kiểm tra chức năng C thì chưa đủ, cần phải kiểm tra[r]
(1)CHƯƠNG 2
MỨC ĐỘ VÀ NHIỆM VỤ CỦA KIỂM TRA PHẦN MỀM
Một hoạt động mang tính sống cịn dự án sản xuất gia cơng phần mềm (PM), kiểm tra (Testing) Dân làm PM hẳn không nghi ngờ vai trị quan trọng nó, nhiên khơng phải (cả ngành ngành) hiểu rõ hoạt động Bản thân công việc kiểm tra phần mềm (KTPM) lĩnh vực hoạt động độc lập "hấp dẫn" Cùng với dự án gia cơng sản xuất PM, có nhiều dự án mà nội dung công việc kiểm tra PM khách hàng phát triển sẵn
Mặc dù công việc KTPM không xa lạ song khái niệm kỹ thuật lại rắc rối Bài viết nhằm cung cấp nhìn tương đối bao quát lĩnh vực "tưởng cũ không cũ”
I KIỂM TRA PHẦN MỀM LÀ GÌ?
Thực kiểm tra phần mềm cơng việc mà người tham gia phát triển phần mềm (PTPM) biết làm Theo nghĩa thông thường nhất, kiểm tra phần mềm bao gồm việc "chạy thử" PM hay chức PM, xem "chạy" mong muốn hay khơng Việc kiểm tra thực chặng, sau chức module phát triển, thực sau cùng, PM phát triển hoàn tất
(2)Hình 1: 4 mức độ kiểm tra phần mềm II CÁC MỨC ĐỘ CỦA KIỂM TRA PHẦN MỀM
Thực tế, kiểm tra phần mềm không đơn giản nhiều người thường nghĩ, cơng việc có nhiều mức độ khác có mối tương quan với chặng phát triển dự án PTPM Hình cho thấy mức độ kiểm tra phần mềm hình cho thấy mối tương quan với chặng PTPM mơ hình V-model
Phần sau làm rõ chi tiết mức độ kiểm tra phần mềm, số thuật ngữ khơng có từ tương đương sát nghĩa tiếng Việt, mặt khác để bạn tiện tham khảo sau này, xin giữ nguyên số thuật ngữ gốc tiếng Anh
1 Unit Test – Kiểm tra mức đơn vị
Để hiểu rõ Unit Test, khái niệm trước tiên ta cần làm rõ: đơn vị PM (Unit)?
(3)Vì Unit chọn để kiểm tra thường có kích thước nhỏ chức hoạt động đơn giản, khơng khó khăn việc tổ chức, kiểm tra, ghi nhận phân tích kết kiểm tra Nếu phát lỗi, việc xác định nguyên nhân khắc phục tương đối dễ dàng khoanh vùng đơn thể Unit kiểm tra Một nguyên lý đúc kết từ thực tiễn: thời gian tốn cho Unit Test đền bù việc tiết kiệm nhiều thời gian chi phí cho việc kiểm tra sửa lỗi mức kiểm tra sau
Unit Test thường lập trình viên thực Cơng đoạn cần thực sớm tốt giai đoạn viết code xuyên suốt chu kỳ PTPM Thơng thường, Unit Test địi hỏi kiểm tra viên có kiến thức thiết kế code chương trình Mục đích Unit Test bảo đảm thơng tin xử lý xuất (khỏi Unit) xác, mối tương quan với liệu nhập chức Unit Điều thường đòi hỏi tất nhánh bên Unit phải kiểm tra để phát nhánh phát sinh lỗi Một nhánh thường chuỗi lệnh thực thi Unit, ví dụ: chuỗi lệnh sau điều kiện If nằm then else nhánh Thực tế việc chọn lựa nhánh để đơn giản hóa việc kiểm tra quét hết Unit đòi hỏi phải có kỹ thuật, đơi phải dùng thuật tốn để chọn lựa
Cũng mức kiểm tra khác, Unit Test đòi hỏi phải chuẩn bị trước tình (test case) kịch (script), định rõ liệu vào, bước thực liệu mong chờ xuất Các test case script nên giữ lại để tái sử dụng
2 Integration Test – Kiểm tra tích hợp
Integration test kết hợp thành phần ứng dụng kiểm tra ứng dụng hoàn thành Trong Unit Test kiểm tra thành phần Unit riêng lẻ Intgration Test kết hợp chúng lại với kiểm tra giao tiếp chúng
Integration Test có mục tiêu chính:
• Phát lỗi giao tiếp xảy Unit
(4)Trong Unit Test, lập trình viên cố gắng phát lỗi liên quan đến chức cấu trúc nội Unit Có số phép kiểm tra đơn giản giao tiếp Unit với thành phần liên quan khác, nhiên giao tiếp liên quan đến Unit thật kiểm tra đầy đủ Unit tích hợp với thực Integration Test
Trừ số ngoại lệ, Integration Test nên thực Unit kiểm tra cẩn thận trước Unit Test, tất lỗi mức Unit sửa chữa Một số người hiểu sai Unit qua giai đoạn Unit Test với giao tiếp giả lập khơng cần phải thực Integration Test Thực tế việc tích hợp Unit dẫn đến tình hoàn toàn khác
Một chiến lược cần quan tâm Integration Test nên tích hợp dần Unit Một Unit thời điểm tích hợp vào nhóm Unit khác tích hợp trước hoàn tất (passed) đợt Integration Test trước Lúc này, ta cần kiểm tra giao tiếp Unit thêm vào với hệ thống Unit tích hợp trước đó, điều làm cho số lượng kiểm tra giảm nhiều, sai sót giảm đáng kể
Có loại kiểm tra Integration Test:
• Kiểm tra cấu trúc (structure): Tương tự White Box Test (kiểm tra nhằm bảo đảm thành phần bên chương trình chạy đúng), trọng đến hoạt động thành phần cấu trúc nội chương trình chẳng hạn lệnh nhánh bên
• Kiểm tra chức (functional): Tương tự Black Box Test (kiểm tra trọng đến chức chương trình, khơng quan tâm đến cấu trúc bên trong), khảo sát chức chương trình theo yêu cầu kỹ thuật
• Kiểm tra hiệu (performance): Kiểm tra việc vận hành hệ thống • Kiểm tra khả chịu tải (stress): Kiểm tra giới hạn hệ thống 3 System Test - Kiểm tra mức hệ thống
(5)System Test bắt đầu tất phận PM tích hợp thành công Thông thường loại kiểm tra tốn nhiều công sức thời gian Trong nhiều trường hợp, việc kiểm tra đòi hỏi số thiết bị phụ trợ, phần mềm phần cứng đặc thù, đặc biệt ứng dụng thời gian thực, hệ thống phân bố, hệ thống nhúng Ở mức độ hệ thống, người kiểm tra tìm kiếm lỗi, trọng tâm đánh giá hoạt động, thao tác, tin cậy yêu cầu khác liên quan đến chất lượng toàn hệ thống
Điểm khác then chốt Integration Test System Test System Test trọng hành vi lỗi toàn hệ thống, Integration Test trọng giao tiếp đơn thể đối tượng chúng làm việc Thông thường ta phải thực Unit Test Integration Test để bảo đảm Unit tương tác chúng hoạt động xác trước thực System Test
Sau hoàn thành Integration Test, hệ thống PM hình thành với thành phần kiểm tra đầy đủ Tại thời điểm này, lập trình viên kiểm tra viên (tester) bắt đầu kiểm tra PM hệ thống hoàn chỉnh Việc lập kế hoạch cho System Test nên giai đoạn hình thành phân tích u cầu Phần sau ta nói rõ quy trình System Test điển hình
System Test kiểm tra hành vi chức phần mềm lẫn yêu cầu chất lượng độ tin cậy, tính tiện lợi sử dụng, hiệu bảo mật Mức kiểm tra đặc biệt thích hợp cho việc phát lỗi giao tiếp với PM phần cứng bên ngoài, chẳng hạn lỗi "tắc nghẽn" (deadlock) chiếm dụng nhớ Sau giai đoạn System Test, PM thường sẵn sàng cho khách hàng người dùng cuối kiểm tra để chấp nhận (Acceptance Test) dùng thử (Alpha/Beta Test)
Địi hỏi nhiều cơng sức, thời gian tính xác, khách quan, System Test thường thực nhóm kiểm tra viên hồn tồn độc lập với nhóm phát triển dự án
Bản thân System Test lại gồm nhiều loại kiểm tra khác (xem hình 3), phổ biến gồm:
(6)• Kiểm tra khả vận hành (Performance Test): bảo đảm tối ưu việc phân bổ tài nguyên hệ thống (ví dụ nhớ) nhằm đạt tiêu thời gian xử lý hay đáp ứng câu truy vấn
• Kiểm tra khả chịu tải (Stress Test hay Load Test): bảo đảm hệ thống vận hành áp lực cao (ví dụ nhiều người truy xuất lúc) Stress Test tập trung vào trạng thái tới hạn, "điểm chết", tình bất thường
• Kiểm tra cấu hình (Configuration Test)
• Kiểm tra khả bảo mật (Security Test): bảo đảm tính tồn vẹn, bảo mật liệu hệ thống
• Kiểm tra khả phục hồi (Recovery Test): bảo đảm hệ thống có khả khơi phục trạng thái ổn định trước tình tài ngun liệu; đặc biệt quan trọng hệ thống giao dịch ngân hàng trực tuyến
Nhìn từ quan điểm người dùng, kiểm tra quan trọng: bảo đảm hệ thống đủ khả làm việc mơi trường thực
(7)Hình 2: Mối tương quan phát triển kiểm tra phần mềm 4 Acceptance Test - Kiểm tra chấp nhận sản phẩm
Thông thường, sau giai đoạn System Test Acceptance Test, khách hàng thực (hoặc ủy quyền cho nhóm thứ ba thực hiện) Mục đích Acceptance Test để chứng minh PM thỏa mãn tất yêu cầu khách hàng khách hàng chấp nhận sản phẩm (và trả tiền toán hợp đồng)
Acceptance Test có ý nghĩa quan trọng, hầu hết trường hợp, phép kiểm tra System Test Accepatnce Test gần tương tự, chất cách thức thực lại khác biệt
Đối với sản phẩm dành bán rộng rãi thị trường cho nhiều người sử dụng, thông thường thông qua hai loại kiểm tra gọi Alpha Test Beta Test Với Alpha Test, người sử dụng (tiềm năng) kiểm tra PM nơi PTPM, lập trình viên ghi nhận lỗi phản hồi, lên kế hoạch sửa chữa Với Beta Test, PM gửi tới cho người sử dụng (tiềm năng) để kiểm tra môi trường thực, lỗi phản hồi gửi ngược lại cho lập trình viên để sửa chữa
Thực tế cho thấy, khách hàng không quan tâm khơng tham gia vào q trình PTPM kết Acceptance Test sai lệch lớn, PM trải qua tất kiểm tra trước Sự sai lệch liên quan đến việc hiểu sai yêu cầu mong chờ khách hàng Ví dụ đơi PM xuất sắc vượt qua phép kiểm tra chức thực nhóm thực dự án, khách hàng kiểm tra sau thất vọng bố cục hình nghèo nàn, thao tác khơng tự nhiên, khơng theo tập quán sử dụng khách hàng
(8)Hình 3: Các loại kiểm tra khác System Test 5 Regression Test - Kiểm tra hồi quy
Trước tiên cần khẳng định Regression Test mức kiểm tra, mức khác nói Nó đơn kiểm tra lại PM sau có thay đổi xảy ra, để bảo đảm phiên PM thực tốt chức phiên cũ thay đổi không gây lỗi chức vốn làm việc tốt Regression test thực mức kiểm tra
(9)nghiêm trọng, ta "tưởng rằng" lỗi khơng có kiểm tra sửa chữa rồi!
III NHI M V C A KI M TRA PH N M M Ệ Ụ Ủ Ể Ầ Ề
Kiểm tra phần mềm phải thực hai nhiệm vụ: xác minh thẩm định
Xác minh thẩm định hệ phần mềm trình liên tục xuyên suốt giai đoạn trình phần mềm Xác minh thẩm định từ chung cho trình kiểm tra để đảm bảo phần mềm thỏa mãn yêu cầu chúng yêu cầu thỏa mãn nhu cầu người sắm phần mềm
Xác minh thẩm định trình kéo dài suốt vịng đời Nó bắt đầu duyệt xét u cầu Xác minh thẩm định có hai mục tiêu:
i) Phát khuyết tật hệ thống
ii) Đánh giá xem hệ thống liệu có dùng hay không?
Sự khác xác minh thẩm định là:
i) Thẩm định: Xem xét xây dựng có là sản phẩm đúng khơng? Tức kiểm tra xem chương trình có mong đợi người dùng hay không
ii) Xác minh: Xem xét xây dựng có đúng sản phẩm không? Như thế, xác minh kiểm tra chương trình có phù hợp với đặc tả hay khơng
Như trên, kiểm tra trình tìm kiếm lỗi Một kiểm tra tốt có khả cao tìm kiếm lỗi chưa phát Một kiểm tra thành cơng kiểm tra tìm lỗi mới, kiểm tra tồi kiểm tra mà không tìm lỗi
(10) Khơng làm điều cần phải làm: lỗi bỏ sót thường xuất ứng dụng phát triển
Làm điều không cần làm: lỗi lệnh cư trú trước ứng dụng bảo trì
Các kiểm tra có mặt mức khác tiến hành cá nhân khác trình phát triển ứng dụng Các kiểm tra tiến hành đội ngũ dự án kiểm tra tiến hành quan bên để chấp nhận ứng dụng
Các kiểm tra đội dự án gọi kiểm tra phát triển (Development test) Như nói kiểm tra phát triển bao gồm kiểm tra đơn vị, kiểm tra hệ thống con, kiểm tra tích hợp kiểm tra hệ thống
Các kiểm tra quan bên gọi đảm bảo chất lượng (Quality assurance-QA) kiểm tra chấp nhận (Acceptance test) Người người sử dụng đại diện người dùng, tạo mục đích, đánh giá khách quan ứng dụng quan bên coi có mục đích thành viên nhóm
Kiểm tra đảm bảo chất lượng tương tự kiểm tra hệ thống mặt mục đích tiến hành, khác họ nằm ngồi điều khiển dự án trưởng Các báo cáo kiểm tra đảm bảo chất lượng gửi thường xuyên tới nhóm phát triển quản lý dự án Các kiểm tra viên đảm bảo chất lượng lập kế hoạch cho chiến lược tiến hành kiểm tra để đảm bảo ứng dụng thực tất chức cần thiết Kiểm tra đảm bảo chất lượng kiểm tra cuối làm trước ứng dụng đưa sản xuất đại trà
(11)Mỗi mức kiểm tra đòi hỏi xác định chiến lược kiểm tra Chiến lược kiểm tra hộp trắng kiểm tra hộp đen
Dữ liệu vào tạo theo thiết kế để sinh liệu khác mà không ý tới chức logic thực Các kết dự đoán so sánh với kết thực tế để đánh giá mức độ thành công
Chiến lược White-box mở hộp nhìn vào logic đặc tả ứng dụng để kiểm tra làm Kiểm tra sử dụng đặc tả logic để tạo xử lý khác dự đoán kết Các kết trung gian đầu cuối dự đốn định lượng nhờ kiểm tra white-box
Chiến lược kiểm tra top–down hay bottom–up: xác định kiểm tra phát triển mã tiến hành nào:
Kiểm tra top–down cho mã điều khiển tới hạn chức phát triển kiểm tra Tiếp theo chức thứ cấp hàm hỗ trợ Các giai o n phát tri n ng d ng đ ạ ể ứ ụ
Ph m vi m c tiêuạ ụ
Yêu c u ch c n ng/Thi t k logicầ ứ ă ế ế
Thi t k v t lýế ế ậ
c t mơ hình c u trúc ch ng trình
Đặ ả ấ ươ
Mã hố module/ch ng trìnhươ
Ki m tra đ n vể ị Ki m tra tích h pể ợ Ki m tra h th ngể ệ ố QA/Ki m tra ch p thu nể ấ ậ
(12)Lý thuyết có nhiều module tới hạn kiểm tra, ổn định chương trình
Kiểm tra bottom–up cho thay đổi module khả sinh lỗi Tồn module mã đơn vị kiểm tra Sau kiểm tra tiến hành mức độ tích hợp
Các chiến lược kiểm tra khơng loại trừ lẫn nhau, chúng sử dụng đơn lẻ đồng thời Lý tưởng kiểm tra cho ứng dụng bao gồm nhiều chiến lược để phát hết lỗi
Sau chiến lược xác định, áp dụng để tạo trường hợp kiểm tra cụ thể Test case: giao dịch riêng biệt ghi liệu tạo logic kiểm tra Cho trường hợp kiểm tra tất kết xử lý dự đoán Đối với ứng dụng on-line off-line tài liệu hoá, test scripts hội thoại tạo người dùng ứng dụng thay đổi từ hội thoại Test plan: tư liệu hoá chiến lược, kiểu, trường hợp mô tả cho kiểm tra vài khối ứng dụng Tất kế hoạch tạo thành kế hoạch tổng thể cho ứng dụng
Kiểm tra lặp lại khơng cịn lỗi, đạt mức độ chấp nhận Bước xử lý kiểm tra, đầu vào kiểm tra, cấu hình mã ứng dụng
được đòi hỏi để tạo kiểm tra
Bước thứ hai so sánh kết kiểm tra với kết dự tính định lượng khác biệt
Bước loại trừ lỗi, gỡ rối mã Khi việc mã hố lại hồn thành, kiểm tra lại tiến hành
(13)