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

A A. Lỗi logic (Logic error) B B. Lỗi cú pháp (Syntax error) C C. Lỗi hiệu suất (Performance defect) D D. Lỗi phần cứng (Hardware error)

A A. Kiểm thử dựa trên hành vi (Behavior-based testing) B B. Kiểm thử dựa trên cấu trúc (Structure-based testing) C C. Kiểm thử chức năng (Functional testing) D D. Kiểm thử phi chức năng (Non-functional testing)

A A. Tự động hóa hoàn toàn quy trình kiểm thử B B. Cải thiện khả năng theo dõi, quản lý và báo cáo về các hoạt động kiểm thử C C. Thay thế hoàn toàn vai trò của người kiểm thử D D. Đảm bảo 100% phần mềm không có lỗi

A A. Tổng số lỗi được phát hiện trong dự án B B. Số lượng lỗi trên một đơn vị kích thước phần mềm (ví dụ: lỗi trên 1000 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 trung bình của các lỗi

A A. Kiểm thử bảo mật (Security testing) B B. Kiểm thử hiệu suất (Performance testing) C C. Kiểm thử giao diện người dùng (UI testing) D D. Kiểm thử khả năng sử dụng (Usability testing)

A A. Selenium B B. JUnit C C. JMeter D D. SonarQube

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

A A. Đo thời gian phản hồi của hệ thống B B. Mô phỏng số lượng người dùng đồng thời lớn để đánh giá khả năng chịu tải của hệ thống C C. Tìm ra điểm yếu bảo mật của hệ thống D D. Kiểm tra khả năng phục hồi của hệ thống sau sự cố

A A. Giai đoạn thực hiện kiểm thử (Test execution) B B. Giai đoạn thiết kế kiểm thử (Test design) C C. Giai đoạn lập kế hoạch kiểm thử (Test planning) D D. Giai đoạn phân tích yêu cầu (Requirements analysis)

A A. Test plan (Kế hoạch kiểm thử) B B. Test case (Ca kiểm thử) C C. Business Requirement Specification (Đặc tả yêu cầu nghiệp vụ) D D. Test report (Báo cáo kiểm thử)

A A. Đảm bảo phần mềm đáp ứng yêu cầu kỹ thuật B B. Xác nhận phần mềm đáp ứng nhu cầu và mong đợi của người dùng/khách hàng C C. Tìm ra tất cả các lỗi tiềm ẩn trong phần mềm D D. Đánh giá hiệu suất và khả năng chịu tải của phần mềm

A A. Kiểm tra cấu hình bảo mật của hệ thống B B. Mô phỏng các cuộc tấn công thực tế để đánh giá khả năng phòng thủ của hệ thống C C. Kiểm tra mã nguồn để tìm lỗ hổng bảo mật D D. Kiểm tra nhật ký hệ thống để phát hiện xâm nhập

A A. Ý kiến cá nhân về lỗi B B. Các bước tái hiện lỗi một cách chi tiết và rõ ràng C C. Ước tính thời gian sửa lỗi D D. Đề xuất giải pháp sửa lỗi

A A. Trước khi phát hành phiên bản phần mềm mới B B. Sau khi sửa lỗi hoặc thay đổi mã nguồn C C. Trong giai đoạn phân tích yêu cầu D D. Khi phát hiện lỗi nghiêm trọng trong quá trình sử dụng

A A. Các module ở mức thấp nhất (lá) của cấu trúc B B. Các module ở mức cao nhất (gốc) của cấu trúc C C. Các module có mức độ phức tạp cao nhất D D. Các module có mức độ rủi ro cao nhất

A A. Tần suất xuất hiện lỗi B B. Mức độ ảnh hưởng của lỗi đến chức năng và hoạt động của phần mềm C C. Khả năng tái hiện lỗi D D. Chi phí để sửa lỗi

A A. Kiểm tra chi tiết tất cả các chức năng của phần mềm B B. Xác minh nhanh chóng các chức năng cốt lõi của phần mềm hoạt động ổn định sau khi build C C. Kiểm tra hiệu suất của phần mềm dưới tải nặng D D. Tìm ra các lỗi bảo mật nghiêm trọng

A A. Khi có yêu cầu rõ ràng và đầy đủ B B. Khi thời gian kiểm thử bị hạn chế và cần tập trung vào các khu vực rủi ro cao C C. Khi cần kiểm thử hồi quy một cách kỹ lưỡng D D. Khi cần tự động hóa các ca kiểm thử

A A. Một mô hình phát triển phần mềm tuyến tính tuần tự B B. Một mô hình kiểm thử song song với các giai đoạn phát triển C C. Một mô hình kiểm thử lặp đi lặp lại D D. Một mô hình kiểm thử Agile

A A. Đo thời gian phản hồi trung bình của hệ thống B B. Đánh giá khả năng của hệ thống khi vượt quá giới hạn tải thông thường C C. Tìm ra lỗi chức năng trong điều kiện tải cao D D. Kiểm tra khả năng mở rộng của hệ thống

A A. Đen (Black-box) B B. Trắng (White-box) C C. Xám (Gray-box) D D. Tự động (Automated)

A A. Mã nguồn của phần mềm B B. Các file bên ngoài (ví dụ: Excel, CSV, database) C C. Yêu cầu người dùng D D. Kết quả kiểm thử trước đó

A A. Chỉ thực hiện kiểm thử vào cuối mỗi sprint B B. Thực hiện kiểm thử liên tục và song song với quá trình phát triển C C. Giao phó hoàn toàn cho đội kiểm thử độc lập D D. Chỉ tập trung vào kiểm thử chức năng, bỏ qua kiểm thử phi chức nă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. Giá trị trung bình của phạm vi đầu vào B B. Giá trị nhỏ nhất và lớn nhất của phạm vi đầu vào, cũng như giá trị ngay trên và dưới biên C C. Giá trị ngẫu nhiên trong phạm vi đầu vào D D. Giá trị phổ biến nhất được sử dụng

A A. Cho các dự án có phạm vi nhỏ và thời gian ngắn B B. Cho các loại kiểm thử lặp đi lặp lại, kiểm thử hồi quy, và kiểm thử hiệu suất C C. Cho tất cả các loại kiểm thử phần mềm D D. Cho các dự án mới bắt đầu và yêu cầu thay đổi thường xuyên

A A. Kiểm tra tất cả các giá trị đầu vào có thể B B. Giảm số lượng ca kiểm thử bằng cách nhóm các giá trị đầu vào tương đương C C. Kiểm tra các giá trị biên của phạm vi đầu vào D D. Tăng cường độ bao phủ mã

A A. Cấu trúc bên trong và mã nguồn của phần mềm B B. Yêu cầu chức năng và hành vi bên ngoài của phần mềm C C. Hiệu suất và khả năng mở rộng của phần mềm D D. Tính bảo mật và an toàn của phần mềm

A A. Kiểm thử có thể chứng minh phần mềm không có lỗi B B. Kiểm thử sớm giúp tiết kiệm chi phí C C. Kiểm thử toàn diện là khả thi trong mọi trường hợp D D. Không cần lập kế hoạch kiểm thử nếu dự án nhỏ

A A. Mô tả chức năng kiểm thử và kết quả mong đợi B B. Dữ liệu đầu vào, các bước thực hiện và kết quả mong đợi C C. Môi trường kiểm thử và công cụ sử dụng D D. Người thực hiện kiểm thử và ngày thực hiện