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

Kiểm thử hiệu năng (Performance testing) được thiết kế để đánh giá các khía cạnh hiệu suất của phần mềm như tốc độ, khả năng mở rộng, độ ổn định và khả năng đáp ứng dưới các điều kiện tải khác nhau. Các loại kiểm thử khác tập trung vào chức năng, bảo mật hoặc khả năng sử dụng.

Kiểm thử chấp nhận (Acceptance testing), đặc biệt là kiểm thử chấp nhận của người dùng (User Acceptance Testing - UAT), thường được thực hiện bởi người dùng cuối hoặc khách hàng để xác minh rằng phần mềm đáp ứng nhu cầu và mong đợi của họ trong môi trường thực tế. Các lựa chọn khác có thể tham gia vào các giai đoạn kiểm thử khác.

Trong kiểm thử hiệu năng, `tải trọng′ (load) thường đề cập đến số lượng người dùng đồng thời, số lượng giao dịch, hoặc lượng dữ liệu mà hệ thống phần mềm phải xử lý trong một khoảng thời gian nhất định. Nó là yếu tố chính để đánh giá khả năng chịu tải và hiệu suất của hệ thống.

Kiểm thử thăm dò (Exploratory testing) là một phương pháp kiểm thử linh hoạt, ít tuân thủ kịch bản, nơi người kiểm thử đồng thời thiết kế và thực hiện kiểm thử, dựa trên học hỏi và khám phá phần mềm trong quá trình kiểm thử. Ngược lại, kiểm thử theo kịch bản (Scripted testing) tuân theo các trường hợp kiểm thử đã được chuẩn bị trước một cách chi tiết.

Mục tiêu chính của kiểm thử phần mềm là xác định và báo cáo lỗi trong phần mềm để có thể sửa chữa chúng trước khi phát hành, từ đó nâng cao chất lượng phần mềm. Không thể chứng minh phần mềm không có lỗi (lựa chọn 1), và kiểm thử không trực tiếp tăng tốc phát triển (lựa chọn 4).

Kiểm thử hồi quy được thực hiện sau khi có thay đổi (ví dụ 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 gây ra lỗi mới hoặc làm hỏng các chức năng đã hoạt động trước đó. Các lựa chọn khác mô tả các loại kiểm thử khác nhau.

Các bước tái hiện lỗi (Steps to reproduce) là thông tin quan trọng nhất trong báo cáo lỗi. Nó cho phép nhà phát triển tái tạo lỗi một cách chính xác và nhanh chóng, từ đó hiểu rõ nguyên nhân và sửa lỗi hiệu quả. Các thông tin khác có thể hữu ích nhưng không quan trọng bằng các bước tái hiện lỗi.

Lập kế hoạch kiểm thử (Test planning) là quá trình xác định phạm vi, mục tiêu, chiến lược, nguồn lực, lịch trình và các hoạt động kiểm thử khác cần thiết cho một dự án. Nó là bước quan trọng đầu tiên để đảm bảo hoạt động kiểm thử được thực hiện một cách có hệ thống và hiệu quả. Các lựa chọn khác là các giai đoạn hoặc hoạt động khác trong quy trình kiểm thử.

Trong phương pháp Agile, kiểm thử là một phần không thể thiếu của mỗi Sprint và được thực hiện liên tục trong suốt quá trình phát triển. Kiểm thử Agile nhấn mạnh sự hợp tác chặt chẽ giữa người kiểm thử và nhà phát triển, kiểm thử sớm và thường xuyên, và tự động hóa kiểm thử để đảm bảo chất lượng phần mềm được duy trì liên tục trong các Sprint ngắn.

Ma trận truy vết yêu cầu (RTM) là một công cụ được sử dụng để liên kết các yêu cầu của dự án với các trường hợp kiểm thử tương ứng. Mục đích chính là đảm bảo rằng tất cả các yêu cầu đã được đề ra đều được kiểm thử đầy đủ và không có yêu cầu nào bị bỏ sót. Các lựa chọn khác có thể là các chức năng phụ trợ hoặc không liên quan đến RTM.

Trong mô hình chữ V, giai đoạn kiểm thử tích hợp (Integration testing) tương ứng với giai đoạn thiết kế mức cao (High-level design). Kiểm thử đơn vị tương ứng với thiết kế chi tiết, kiểm thử hệ thống tương ứng với thiết kế kiến trúc, và kiểm thử chấp nhận tương ứng với yêu cầu.

Kiểm thử API (Application Programming Interface) tập trung vào việc kiểm tra giao tiếp và tương tác giữa các thành phần phần mềm khác nhau, hoặc giữa các hệ thống phần mềm riêng biệt. Nó kiểm tra xem API có hoạt động đúng như mong đợi, xử lý dữ liệu chính xác và đáp ứng các yêu cầu về hiệu suất và bảo mật hay không. Các lựa chọn khác không phải là trọng tâm của kiểm thử API.

Khái niệm `Kiểm thử phần mềm là một quá trình sáng tạo và trí tuệ` nhấn mạnh rằng kiểm thử không chỉ là việc chạy các trường hợp kiểm thử theo kịch bản, mà còn đòi hỏi người kiểm thử phải tư duy phản biện, sáng tạo để thiết kế các trường hợp kiểm thử hiệu quả, khám phá các tình huống kiểm thử khác nhau, và tìm ra các lỗi tiềm ẩn mà có thể không dễ dàng phát hiện. Nó đòi hỏi kỹ năng phân tích, suy luận và khả năng nhìn nhận vấn đề từ nhiều góc độ.

Kiểm thử biên (Boundary value testing) là một kỹ thuật kiểm thử hộp đen tập trung vào việc kiểm tra các giá trị biên của dữ liệu đầu vào và đầu ra. Nó dựa trên giả định rằng lỗi thường có xu hướng xảy ra tại hoặc gần các biên của phạm vi dữ liệu hợp lệ hoặc không hợp lệ.

Độ ưu tiên (Priority) của lỗi xác định thứ tự mà lỗi cần được sửa chữa (ví dụ: cao, trung bình, thấp), thường dựa trên giá trị kinh doanh hoặc tác động đến lịch trình dự án. Mức độ nghiêm trọng (Severity) mô tả mức độ ảnh hưởng của lỗi đến chức năng hoặc hệ thống (ví dụ: nghiêm trọng, lớn, nhỏ). Chúng là hai khía cạnh khác nhau nhưng bổ sung cho nhau trong quản lý lỗi.

Công cụ quản lý kiểm thử (Test management tools) hỗ trợ các hoạt động quản lý toàn bộ quy trình kiểm thử, bao gồm lập kế hoạch, thiết kế trường hợp kiểm thử, thực thi kiểm thử, theo dõi lỗi và tạo báo cáo. Chúng giúp cải thiện hiệu quả và khả năng quản lý của quá trình kiểm thử. Các lựa chọn khác có thể là chức năng của các loại công cụ khác (ví dụ: công cụ tự động hóa kiểm thử, công cụ phân tích mã tĩnh).

Kiểm thử cặp đôi (Pair testing) là một kỹ thuật kiểm thử hợp tác, trong đó hai người kiểm thử làm việc cùng nhau trên cùng một máy tính để kiểm tra phần mềm. Một người đóng vai trò `người lái′ (driver) thực hiện thao tác kiểm thử, người kia đóng vai trò `người dẫn đường′ (navigator) xem xét, đặt câu hỏi và đưa ra gợi ý. Mục đích là tận dụng kiến thức và kỹ năng của cả hai người để tìm ra nhiều lỗi hơn.

Nguyên tắc `Kiểm thử sớm′ (Early testing) khuyến khích việc bắt đầu các hoạt động kiểm thử càng sớm càng tốt trong vòng đời phát triển phần mềm, lý tưởng là ngay từ giai đoạn yêu cầu và thiết kế. Điều này giúp phát hiện và sửa lỗi sớm, giảm chi phí và rủi ro.

Kiểm thử khói là một loại kiểm thử nhanh chóng, bề mặt, được thực hiện sau mỗi bản dựng mới để đảm bảo rằng các chức năng cốt lõi của phần mềm hoạt động bình thường và ổn định. Nó giúp phát hiện sớm các lỗi nghiêm trọng và quyết định xem bản dựng có đủ ổn định để tiếp tục kiểm thử sâu hơn hay không.

Kiểm thử đơn vị (Unit testing) 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, như hàm hoặc lớp, một cách độc lập. Các loại kiểm thử khác kiểm tra ở mức độ tích hợp hoặc hệ thống lớn hơn.

Kiểm thử hộp trắng (White-box testing), còn gọi là kiểm thử cấu trúc, đòi hỏi người kiểm thử phải hiểu cấu trúc bên trong và mã nguồn của phần mềm để thiết kế các trường hợp kiểm thử. Kiểm thử hộp đen và hộp xám không yêu cầu hoặc hạn chế truy cập mã nguồn.

Phân vùng tương đương là một kỹ thuật kiểm thử hộp đen. Nó chia dữ liệu đầu vào thành các phân vùng tương đương, sao cho việc kiểm thử một giá trị trong phân vùng được coi là tương đương với việc kiểm thử bất kỳ giá trị nào khác trong cùng phân vùng đó. Mục đích là giảm số lượng trường hợp kiểm thử cần thiết mà vẫn đảm bảo độ bao phủ hợp lý.

Kiểm thử chấp nhận hoạt động (OAT) tập trung vào việc xác minh rằng phần mềm sẵn sàng để triển khai và vận hành trong môi trường sản xuất. Nó kiểm tra các khía cạnh như khả năng cài đặt, cấu hình, sao lưu, phục hồi, bảo trì và khả năng hoạt động ổn định trong môi trường thực tế. Các lựa chọn khác liên quan đến các loại kiểm thử chấp nhận khác (UAT - người dùng) hoặc các khía cạnh kiểm thử khác (hiệu năng, khả năng sử dụng).

Kiểm thử bảo mật (Security testing) là loại kiểm thử chuyên biệt được thiết kế để xác định và đánh giá các lỗ hổng bảo mật, rủi ro và điểm yếu tiềm ẩn trong phần mềm có thể bị khai thác để gây hại. Các loại kiểm thử khác có mục tiêu khác nhau và không tập trung vào bảo mật.

Kiểm thử đột biến (Mutation testing) là một kỹ thuật kiểm thử hộp trắng được sử dụng để đánh giá độ mạnh của bộ trường hợp kiểm thử. Nó thực hiện bằng cách tạo ra các phiên bản `đột biến′ của mã nguồn (chứa các lỗi nhỏ) và sau đó chạy bộ trường hợp kiểm thử trên các phiên bản đột biến này. Nếu bộ trường hợp kiểm thử tốt, nó sẽ phát hiện ra các đột biến (tức là `giết′ đột biến). Độ mạnh của bộ trường hợp kiểm thử được đo bằng tỷ lệ đột biến bị giết.

Trường hợp kiểm thử (Test case) là tài liệu chi tiết mô tả các bước, dữ liệu đầu vào, điều kiện tiên quyết và kết quả mong đợi cho một lần kiểm thử cụ thể. Kế hoạch kiểm thử là tài liệu cấp cao hơn, báo cáo kiểm thử tóm tắt kết quả, và ma trận truy vết yêu cầu theo dõi mối quan hệ giữa yêu cầu và kiểm thử.

Trong kiểm thử chấp nhận, đặc biệt là kiểm thử chấp nhận của người dùng (UAT), người kiểm thử cần có `tâm lý của người dùng cuối′ để đánh giá phần mềm từ góc độ người dùng thực tế, đảm bảo rằng phần mềm dễ sử dụng, đáp ứng nhu cầu và mong đợi của họ. Các loại kiểm thử khác có thể tập trung vào các khía cạnh kỹ thuật hoặc chức năng khác.

Độ bao phủ mã là thước đo phần trăm mã nguồn đã được thực thi bởi các trường hợp kiểm thử. Nó chủ yếu được sử dụng trong kiểm thử hộp trắng để đánh giá mức độ kiểm thử cấu trúc mã. Các loại kiểm thử khác không trực tiếp sử dụng độ bao phủ mã làm thước đo chính.

Trong ngữ cảnh kiểm thử phần mềm, `lỗi′ (bug) và `khuyết tật′ (defect) thường được sử dụng tương đương nhau để chỉ bất kỳ sự sai lệch nào so với hành vi mong đợi hoặc yêu cầu đặc tả của phần mềm. Mặc dù có thể có sự khác biệt nhỏ trong cách sử dụng ở một số ngữ cảnh cụ thể, nhưng trong thực tế, chúng thường được coi là đồng nghĩa.

Kiểm thử hộp đen được gọi là kiểm thử chức năng vì nó tập trung vào việc kiểm tra chức năng của phần mềm từ bên ngoài, không cần biết cấu trúc bên trong của nó. Các lựa chọn khác liên quan đến kiểm thử hộp trắng hoặc các khía cạnh cụ thể của kiểm thử.