Đề 4 – Bài tập, đề thi trắc nghiệm online Kiểm thử phần mềm

Kiểm thử đơn vị (Unit testing) thường là bước đầu tiên, tập trung vào việc kiểm tra các thành phần nhỏ nhất của phần mềm (đơn vị) một cách độc lập trước khi tích hợp chúng lại.

Kế hoạch kiểm thử (Test plan) là tài liệu quan trọng nhất trong giai đoạn lập kế hoạch kiểm thử, nó vạch ra chiến lược, phạm vi, phương pháp, lịch trình, nguồn lực và trách nhiệm cho toàn bộ hoạt động kiểm thử phần mềm.

Phòng ngừa lỗi (Defect Prevention) là một hoạt động chủ động nhằm xác định và loại bỏ các nguyên nhân gốc rễ gây ra lỗi trong quá trình phát triển phần mềm, từ đó giảm thiểu số lượng lỗi phát sinh ngay từ đầu, thay vì chỉ tập trung vào việc tìm và sửa lỗi sau khi chúng đã xuất hiện.

Kiểm thử bảo mật (Security testing) nên được tích hợp vào toàn bộ vòng đời phát triển phần mềm, bắt đầu từ giai đoạn thiết kế, lập trình, kiểm thử và duy trì. Thực hiện sớm và liên tục giúp phát hiện và khắc phục các vấn đề bảo mật từ sớm, giảm thiểu rủi ro và chi phí sửa chữa.

Sai sót (Error) là hành động sai của con người (ví dụ, lỗi lập trình), còn lỗi (Bug∕Defect) là kết quả của sai sót đó, là sự khác biệt giữa hành vi mong đợi và hành vi thực tế của phần mềm.

Ma trận truy vết yêu cầu (RTM) là một tài liệu liên kết các yêu cầu của dự án với các test case tương ứng. Nó giúp đảm bảo rằng mọi yêu cầu đều được kiểm thử và có thể truy vết ngược lại từ test case đến yêu cầu gốc.

Kiểm thử khả năng sử dụng (Usability testing) tập trung vào việc đánh giá mức độ dễ sử dụng, hiệu quả, hiệu suất và sự hài lòng của người dùng khi tương tác với phần mềm. Nó đánh giá trải nghiệm người dùng (UX) chứ không chỉ chức năng hay hiệu năng.

Khi ứng dụng web có nhiều trường nhập liệu và quy tắc nghiệp vụ phức tạp, kiểm thử phân vùng tương đương (Equivalence partitioning) và giá trị biên (Boundary value analysis) là các kỹ thuật hộp đen hiệu quả để giảm số lượng test case cần thiết mà vẫn đảm bảo độ bao phủ kiểm thử tốt, đặc biệt là với các trường nhập liệu khác nhau và các ràng buộc dữ liệu.

Một test case điển hình bao gồm mô tả chức năng cần kiểm tra, dữ liệu đầu vào để thực hiện kiểm thử và kết quả mong đợi khi test case được thực thi thành công.

Nghịch lý thuốc trừ sâu (Pesticide Paradox) chỉ ra rằng nếu một bộ test case được sử dụng lặp đi lặp lại qua nhiều lần kiểm thử mà không được cập nhật hoặc thay đổi, nó sẽ dần mất đi khả năng phát hiện lỗi mới. Giống như thuốc trừ sâu mất hiệu quả khi sử dụng liên tục trên cùng một loại sâu bệnh.

Kiểm thử chấp nhận của người dùng (UAT) được thực hiện bởi người dùng cuối hoặc đại diện của họ. Mục đích là để xác nhận rằng phần mềm đáp ứng nhu cầu kinh doanh và mong đợi của người dùng trong môi trường thực tế của họ.

Việc dừng kiểm thử không nên dựa trên cảm tính hoặc các yếu tố ngẫu nhiên như hết thời gian hay đạt số lượng lỗi. Thay vào đó, cần xác định rõ các tiêu chí dừng kiểm thử (Test exit criteria) từ trước, ví dụ như đạt được mức độ bao phủ code mong muốn, tỷ lệ lỗi thấp hơn ngưỡng cho phép, và các rủi ro còn lại được chấp nhận bởi các bên liên quan.

Độ bao phủ code (Code coverage) đo lường tỷ lệ phần trăm các dòng code, nhánh rẽ, hoặc đường dẫn trong code đã được thực thi (bao phủ) bởi tập hợp các test case. Nó giúp đánh giá mức độ kiểm thử code đã đạt được.

Kiểm thử tích hợp (Integration testing) tập trung vào việc kiểm tra cách các module phần mềm khác nhau làm việc cùng nhau sau khi đã được kiểm thử đơn vị riêng lẻ. Mục đích là phát hiện lỗi trong giao tiếp và tương tác giữa các module.

Trong mô hình chữ V, giai đoạn kiểm thử hệ thống (System testing) tương ứng với giai đoạn thiết kế kiến trúc (Architectural design). Kiểm thử hệ thống xác minh rằng toàn bộ hệ thống đáp ứng các yêu cầu thiết kế kiến trúc.

Kiểm thử tải (Load testing) được thiết kế để đánh giá hiệu suất của hệ thống khi chịu tải trọng dự kiến, thường là số lượng người dùng đồng thời và khối lượng giao dịch dự kiến.

Kiểm thử hồi quy được thực hiện sau khi có thay đổi code (sửa lỗi, thêm tính năng) để đảm bảo rằng những thay đổi này không vô tình làm hỏng các chức năng hiện có của phần mềm.

Kiểm thử thăm dò (Exploratory testing) là một phương pháp kiểm thử ít chính thức hơn, trong đó tester đồng thời học về phần mềm, thiết kế và thực hiện test case, không theo kịch bản cố định. Nó phù hợp khi yêu cầu không rõ ràng hoặc cần khám phá nhanh chóng.

Lập kế hoạch kiểm thử (Test planning) là giai đoạn quan trọng để xác định chiến lược kiểm thử, phạm vi kiểm thử, mục tiêu, nguồn lực cần thiết (nhân sự, công cụ, môi trường), lịch trình và các rủi ro có thể xảy ra trong quá trình kiểm thử.

Kỹ thuật Phân tích giá trị biên (Boundary Value Analysis) tập trung vào việc kiểm tra các giá trị ở biên của các phân vùng dữ liệu đầu vào (ví dụ, giá trị nhỏ nhất, lớn nhất, giá trị ngay trên và dưới biên), vì lỗi thường có xu hướng xuất hiện ở các biên này.

Test stub và Test driver là các thành phần giả lập được sử dụng trong kiểm thử tích hợp (Integration testing), đặc biệt là phương pháp tích hợp từ trên xuống (top-down) và từ dưới lên (bottom-up). Stub giả lập các module cấp dưới mà module đang kiểm thử gọi đến, còn Driver giả lập module cấp trên gọi module đang kiểm thử.

Kiểm thử hộp đen kiểm tra chức năng của phần mềm từ quan điểm người dùng, không cần biết cấu trúc bên trong của code. Nó tập trung vào giao diện người dùng và các chức năng mà người dùng có thể tương tác.

Công cụ tự động hóa kiểm thử giúp thực hiện các test case lặp đi lặp lại một cách nhanh chóng và chính xác, giảm bớt công sức thủ công, tiết kiệm thời gian và chi phí, đồng thời tăng độ tin cậy và hiệu quả của quá trình kiểm thử.

Kiểm thử alpha thường được thực hiện trong môi trường phát triển bởi đội ngũ nội bộ (nhà phát triển, tester) để kiểm tra ban đầu. Kiểm thử beta được thực hiện bởi người dùng cuối thực tế trong môi trường của họ trước khi phần mềm được phát hành rộng rãi.

Kiểm thử Ad-hoc là một loại kiểm thử không chính thức, không theo kế hoạch hoặc test case cụ thể. Tester thực hiện kiểm thử một cách ngẫu nhiên, dựa trên kinh nghiệm và hiểu biết của mình về phần mềm, nhằm tìm ra lỗi một cách nhanh chóng và bất ngờ.

Kiểm thử phân vùng tương đương là một kỹ thuật kiểm thử hộp đen, dựa trên việc chia dữ liệu đầu vào thành các phân vùng hợp lệ và không hợp lệ để thiết kế test case, không cần xem xét cấu trúc code bên trong.

Phương pháp Bao phủ câu lệnh (Statement Coverage) đảm bảo rằng mỗi câu lệnh (dòng code) trong chương trình được thực thi ít nhất một lần trong quá trình kiểm thử. Tuy nhiên, nó không đảm bảo bao phủ hết các nhánh rẽ hoặc điều kiện phức tạp.

Mật độ lỗi (Defect Density) là một chỉ số chất lượng phần mềm, đo lường số lượng lỗi được tìm thấy trên một đơn vị kích thước phần mềm (thường là KLOC - nghìn dòng code). Nó giúp đánh giá chất lượng code và so sánh chất lượng giữa các dự án hoặc giai đoạn phát triển khác nhau.

Trạng thái `Resolved′ trong vòng đời lỗi thường chỉ ra rằng lỗi đã được lập trình viên sửa code và đã được kiểm tra lại bởi tester để xác nhận việc sửa lỗi thành công. Tuy nhiên, cần lưu ý rằng trạng thái này có thể có ý nghĩa hơi khác nhau tùy theo quy trình cụ thể của từng dự án.

Kiểm thử khói (Smoke testing) là một loại kiểm thử nhanh chóng và bề mặt, được thực hiện sau mỗi lần build mới để đảm bảo rằng các chức năng chính của phần mềm hoạt động ổn định và có thể tiếp tục các giai đoạn kiểm thử sâu hơn.