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

A A. Chia dữ liệu đầu vào thành các nhóm tương đương và chọn một giá trị đại diện từ mỗi nhóm để kiểm thử. B B. Kiểm thử tất cả các giá trị đầu vào có thể. C C. Kiểm thử các giá trị biên của dữ liệu đầu vào. D D. Kiểm thử ngẫu nhiên dữ liệu đầu vào.

A A. Kiểm tra tính đúng đắn của chức năng. B B. Đánh giá tốc độ, khả năng mở rộng và độ ổn định của phần mềm dưới tải. C C. Kiểm tra giao diện người dùng. D D. Tìm kiếm lỗ hổng bảo mật.

A A. Kiểm thử alpha do lập trình viên thực hiện, beta do người kiểm thử chuyên nghiệp. B B. Kiểm thử alpha thực hiện tại môi trường của nhà phát triển, beta thực hiện bởi người dùng cuối trong môi trường thực tế. C C. Kiểm thử alpha tập trung vào chức năng, beta tập trung vào hiệu suất. D D. Kiểm thử alpha là kiểm thử hộp trắng, beta là kiểm thử hộp đen.

A A. Giảm tốc độ kiểm thử. B B. Chi phí đầu tư ban đầu cao, khó bảo trì script kiểm thử, và có thể bỏ sót các lỗi liên quan đến giao diện người dùng hoặc trải nghiệm người dùng. C C. Tăng số lượng lỗi bỏ sót. D D. Giảm độ tin cậy của kiểm thử.

A A. Khi logic nghiệp vụ phức tạp và có nhiều điều kiện và hành động. B B. Khi kiểm thử giao diện người dùng. C C. Khi kiểm thử hiệu suất. D D. Khi kiểm thử bảo mật.

A A. Kiểm thử hệ thống. B B. Kiểm thử chấp nhận. C C. Kiểm thử đơn vị. D D. Kiểm thử hồi quy.

A A. Kiểm thử dựa trên kịch bản được viết trước. B B. Kiểm thử tự động hoàn toàn. C C. Kiểm thử đồng thời học hỏi về hệ thống và thiết kế kiểm thử trong quá trình thực hiện, ít dựa vào tài liệu. D D. Kiểm thử hiệu suất chuyên sâu.

A A. Kiểm tra chức năng của phần mềm từ góc độ người dùng. B B. Kiểm tra cấu trúc bên trong và logic của mã nguồn. C C. Kiểm tra hiệu suất của phần mềm. D D. Kiểm tra tính bảo mật của phần mềm.

A A. Selenium. B B. Jira. C C. JUnit. D D. LoadRunner.

A A. Số lượng lỗi được tìm thấy trong một khoảng thời gian nhất định. 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. Mức độ nghiêm trọng của các lỗi. D D. Tỷ lệ lỗi được sửa chữa thành công.

A A. Số lượng lỗi được tìm thấy. B B. Phần trăm mã nguồn đã được thực thi bởi các trường hợp kiểm thử. C C. Hiệu suất của phần mềm. D D. Mức độ thân thiện của giao diện người dùng.

A A. Loại bỏ hoàn toàn nhu cầu kiểm thử thủ công. B B. Tăng tốc độ kiểm thử, giảm chi phí và cải thiện độ tin cậy của kiểm thử hồi quy. C C. Tìm ra tất cả các lỗi trong phần mềm. D D. Thay thế vai trò của người kiểm thử.

A A. Kiểm tra tất cả các chức năng của phần mềm từ đầu. B B. Đảm bảo rằng các thay đổi mới không gây ra lỗi ở các chức năng đã hoạt động tốt trước đó. C C. Tìm ra các lỗi hiệu suất trong phần mềm. D D. Kiểm tra tính bảo mật sau mỗi lần phát hành.

A A. Bắt đầu giai đoạn kiểm thử mới. B B. Xác định khi nào hoạt động kiểm thử đã hoàn thành và các tiêu chí kết thúc đã đạt được. C C. Báo cáo tất cả các lỗi đã tìm thấy. D D. Phân tích nguyên nhân gốc rễ củ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 và phát hiện lỗi. D D. Triển khai phần mềm.

A A. Trước khi phát hành phần mềm cho người dùng cuối. B B. Sau khi kiểm thử đơn vị hoàn tất. C C. Sau mỗi build mới để xác nhận nhanh chóng các chức năng chính hoạt động. D D. Chỉ khi có yêu cầu thay đổi lớn.

A A. Kiểm tra hiệu suất dưới tải thông thường. B B. Kiểm tra hiệu suất khi hệ thống vượt quá giới hạn tải dự kiến để xác định điểm gãy và khả năng phục hồi. C C. Kiểm tra hiệu suất giao diện người dùng. D D. Kiểm tra hiệu suất cơ sở dữ liệu.

A A. Giai đoạn lập kế hoạch dự án. B B. Giai đoạn phân tích yêu cầu. C C. Giai đoạn thiết kế kiến trúc. D D. Giai đoạn thiết kế chi tiết.

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ử hộp trắng. B B. Kiểm thử hộp đen. C C. Kiểm thử hộp xám. D D. Kiểm thử tĩnh.

A A. Các giá trị ngẫu nhiên. B B. Các giá trị nằm trong phạm vi hợp lệ. C C. Các giá trị ở biên của phạm vi đầu vào (giá trị min, max, và các giá trị lân cận). D D. Các giá trị không hợp lệ.

A A. Giai đoạn thực thi kiểm thử. B B. Giai đoạn phân tích yêu cầu và thiết kế. C C. Giai đoạn báo cáo kết quả kiểm thử. D D. Giai đoạn đóng dự án.

A A. Kiểm tra các chính sách bảo mật của tổ chức. B B. Mô phỏng các cuộc tấn công thực tế để tìm ra lỗ hổng bảo mật và đánh giá mức độ an toàn của hệ thống. C C. Kiểm tra mã nguồn để tìm lỗi bảo mật. D D. Kiểm tra quyền truy cập của người dùng.

A A. Thực hiện tất cả các trường hợp kiểm thử có thể. B B. Tập trung kiểm thử vào các khu vực rủi ro cao, chức năng quan trọng hoặc thường xuyên thay đổi để tối ưu hóa nguồn lực và thời gian. C C. Giảm số lượng trường hợp kiểm thử. D D. Loại bỏ kiểm thử thủ công.

A A. Kiểm thử đơn vị. B B. Kiểm thử tích hợp. C C. Kiểm thử giao diện người dùng (UI testing). D D. Kiểm thử hệ thống.

A A. Thay thế hoàn toàn người kiểm thử. B B. Tự động sinh ra các trường hợp kiểm thử từ mô tả hành vi mong muốn của hệ thống. C C. Đánh giá hiệu suất của hệ thống. D D. Quản lý lỗi.

A A. Lập trình viên. B B. Người kiểm thử chuyên nghiệp (Tester). C C. Người dùng cuối hoặc đại diện người dùng. D D. Quản lý dự án.

A A. Lỗi là lỗi trong yêu cầu, khuyết tật là lỗi trong mã. B B. Lỗi và khuyết tật là hai thuật ngữ hoàn toàn khác nhau. C C. Lỗi và khuyết tật thường được sử dụng thay thế cho nhau để chỉ sự sai lệch so với mong đợi. D D. Khuyết tật là lỗi do người dùng gây ra, lỗi là do lập trình viên.

A A. Mơ hồ và chung chung để bao quát nhiều tình huống. B B. Dài dòng và phức tạp để kiểm tra nhiều chức năng cùng lúc. C C. Rõ ràng, dễ hiểu, có thể tái sử dụng và tập trung vào một mục tiêu kiểm thử cụ thể. D D. Chỉ tập trung vào các trường hợp thành công, không cần kiểm tra trường hợp lỗi.

A A. Kiểm thử đơn vị. B B. Kiểm thử tích hợp. C C. Code review (Đánh giá mã). D D. Kiểm thử hệ thống.