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

A A. Lỗi cú pháp. B B. Lỗi logic. C C. Lỗi giao diện người dùng. D D. Lỗi hiệu năng.

A A. Tốc độ thực hiện nhanh hơn. B B. Độ chính xác cao hơn. C C. Khả năng linh hoạt và khám phá lỗi mới tốt hơn. D D. Chi phí thấp hơn trong dài hạn.

A A. Bất kỳ sự cố nào gây ra sự chậm trễ trong dự án. B B. 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. C C. Bất kỳ đoạn code nào khó đọc. D D. Bất kỳ yêu cầu nào chưa được thực hiện.

A A. Tính linh hoạt và thích ứng với thay đổi. B B. Kiểm thử liên tục và tự động hóa. C C. Sự tương ứng giữa giai đoạn phát triển và giai đoạn kiểm thử. D D. Sự tham gia sớm của khách hàng vào quá trình kiểm thử.

A A. Đo độ bao phủ mã. B B. Quản lý lỗi phần mềm. C C. Đảm bảo rằng tất cả các yêu cầu đều được kiểm thử. D D. Lập kế hoạch kiểm thử.

A A. Báo cáo phải dài dòng và chi tiết nhất có thể. B B. Báo cáo phải chứa ý kiến cá nhân của người kiểm thử. C C. Báo cáo phải rõ ràng, ngắn gọn, dễ tái hiện lỗi và cung cấp đủ thông tin cần thiết. D D. Báo cáo nên đổ lỗi cho nhà phát triển gây ra lỗi.

A A. Kiểm thử hộp đen. B B. Kiểm thử hộp trắng. C C. Kiểm thử hiệu năng. D D. Kiểm thử khả năng sử dụng.

A A. Việc sử dụng quá nhiều công cụ kiểm thử tự động hóa. B B. Việc lặp lại cùng một bộ test case sẽ giảm hiệu quả phát hiện lỗi mới. C C. Sự khó khăn trong việc tìm lỗi ở giai đoạn cuối của dự án. D D. Mâu thuẫn giữa chi phí và lợi ích của kiểm thử.

A A. Kiểm thử hộp đen. B B. Kiểm thử hộp trắng. C C. Kiểm thử tích hợp. D D. Kiểm thử hệ thống.

A A. Kiểm thử đơn vị (Unit testing). B B. Kiểm thử tích hợp (Integration testing). C C. Kiểm thử hệ thống (System testing). D D. Kiểm thử chấp nhận (Acceptance testing).

A A. Kiểm thử chức năng. B B. Kiểm thử cấu trúc. C C. Kiểm thử hiệu năng. D D. Kiểm thử chấp nhận.

A A. Để ghi lại kết quả kiểm thử. B B. Để mô tả chi tiết từng ca kiểm thử. C C. Để xác định phạm vi, mục tiêu, nguồn lực và lịch trình kiểm thử. D D. Để theo dõi lỗi và quá trình sửa lỗi.

A A. Xây dựng phần mềm. B B. Gỡ lỗi phần mềm. C C. Đánh giá chất lượng phần mềm để phát hiện lỗi. D D. Triển khai phần mềm.

A A. Kiểm tra chức năng đăng nhập của ứng dụng. B B. Đảm bảo ứng dụng web có thể xử lý đồng thời hàng ngàn người dùng. C C. Kiểm tra giao diện người dùng của ứng dụng di động. D D. Xác minh logic nghiệp vụ của một module cụ thể.

A A. Kiểm thử hiệu năng dưới tải nặng. B B. Một loại kiểm thử chấp nhận. C C. Kiểm thử nhanh chóng các chức năng cốt lõi để đảm bảo build ổn định. D D. Kiểm thử bảo mật xâm nhập.

A A. Sau khi phát hành phần mềm. B B. Trước khi bắt đầu phát triển phần mềm. C C. Sau khi có thay đổi hoặc sửa lỗi trong phần mềm. D D. Trong giai đoạn lập kế hoạch dự án.

A A. Chứng minh rằng phần mềm không có lỗi. B B. Tìm càng nhiều lỗi càng tốt trước khi phát hành. C C. Đảm bảo phần mềm đáp ứng mọi yêu cầu của khách hàng. D D. Tăng tốc độ phát triển phần mềm.

A A. Đo thời gian phản hồi của hệ thống. B B. Xác định điểm giới hạn chịu tải của hệ thống. C C. Kiểm tra khả năng mở rộng của hệ thống. D D. Đảm bảo hệ thống hoạt động ổn định trong điều kiện bình thường.

A A. Kiểm thử chức năng. B B. Kiểm thử hiệu năng. C C. Kiểm thử bảo mật. D D. Kiểm thử khả năng sử dụng (Usability testing).

A A. Chỉ ở cuối mỗi Sprint. B B. Liên tục và lặp đi lặp lại trong suốt Sprint. C C. Chỉ sau khi hoàn thành tất cả các Sprint. D D. Bởi một nhóm kiểm thử riêng biệt sau khi phát triển xong.

A A. Một loại lỗi phần mềm. B B. Một tài liệu mô tả các bước kiểm thử, dữ liệu đầu vào và kết quả mong đợi. C C. Một công cụ tự động hóa kiểm thử. D D. Một báo cáo về kết quả kiểm thử.

A A. Số lượng lỗi đã sửa. B B. Số lượng lỗi tìm thấy trên kích thước phần mềm (ví dụ: lỗi trên mỗi nghìn dòng code). C C. Thời gian trung bình để sửa một lỗi. D D. Mức độ nghiêm trọng của lỗi.

A A. Cấu trúc code bên trong của phần mềm. B B. Yêu cầu chức năng và đầu vào/đầu ra của phần mềm. C C. Hiệu suất của phần mềm. D D. Mức độ bảo mật của phần mềm.

A A. Nhóm kiểm thử độc lập. B B. Nhà phát triển phần mềm. C C. Khách hàng. D D. Quản lý dự án.

A A. Khi đã kiểm thử mọi thứ có thể. B B. Khi hết thời gian hoặc ngân sách. C C. Khi đạt được tiêu chí dừng kiểm thử đã xác định (ví dụ: độ bao phủ, mật độ lỗi). D D. Khi không còn lỗi nào được tìm thấy.

A A. Không cần kiến thức về cấu trúc bên trong. B B. Yêu cầu truy cập đầy đủ vào mã nguồn. C C. Kết hợp kiến thức về cả hộp đen và hộp trắng. D D. Chỉ tập trung vào giao diện người dùng.

A A. Kiểm thử hộp trắng. B B. Kiểm thử hộp đen. C C. Kiểm thử thăm dò (Exploratory testing). D D. Kiểm thử tự động hóa.

A A. Thời gian cần thiết để sửa lỗi. B B. Ảnh hưởng của lỗi đến hoạt động của phần mềm. C C. Khả năng xảy ra lỗi. D D. Số lượng người dùng bị ảnh hưởng bởi lỗi.

A A. Kiểm thử tự động hóa luôn nhanh hơn kiểm thử thủ công. B B. Kiểm thử tự động hóa có thể giúp tăng độ bao phủ kiểm thử. C C. Kiểm thử tự động hóa đặc biệt hiệu quả cho kiểm thử hồi quy. D D. Kiểm thử tự động hóa có thể giảm chi phí kiểm thử trong dài hạn.

A A. Nhóm phát triển. B B. Nhóm kiểm thử độc lập. C C. Người dùng cuối hoặc khách hàng. D D. Quản lý chất lượng.