200+ câu Trắc nghiệm Kiểm thử phần mềm có đáp án - Phần 5

Hệ thống phải cho phép người dùng đăng nhập

Hệ thống phải phản hồi yêu cầu trong vòng 2 giây

Hệ thống phải cho phép người dùng tạo báo cáo

Hệ thống phải hiển thị danh sách sản phẩm

Hệ thống xử lý dữ liệu lớn

Hệ thống có hành vi thay đổi dựa trên các sự kiện hoặc trạng thái trước đó

Hệ thống chỉ có các chức năng giao dịch đơn giản

Hệ thống lưu trữ dữ liệu

Kiểm thử nhánh (Branch Testing)

Kiểm thử đường đi (Path Testing)

Kiểm thử câu lệnh (Statement Testing)

Kiểm thử điều kiện (Condition Testing)

Kiểm thử tất cả các kết hợp (All Combination Testing)

Kiểm thử thăm dò (Exploratory Testing)

Kiểm thử dựa trên rủi ro (Risk-Based Testing)

Kiểm thử biên (Boundary Value Analysis)

Giai đoạn kiểm thử chấp nhận người dùng (UAT)

Giai đoạn kiểm thử tích hợp

Giai đoạn kiểm thử đơn vị

Giai đoạn bảo trì sau khi triển khai

Ngay khi phát hiện ra một hành vi không mong muốn

Sau khi đã hoàn thành toàn bộ quá trình kiểm thử

Chỉ khi lỗi có mức độ nghiêm trọng cao

Khi người dùng báo cáo lỗi trực tiếp

Kiểm thử cho thấy sự hiện diện của lỗi, không cho thấy sự vắng mặt của lỗi

Kiểm thử phụ thuộc vào ngữ cảnh

Kiểm thử sớm để tiết kiệm chi phí

Mọi kiểm thử đều cần được tự động hóa

Chỉ trước khi phát hành sản phẩm cuối cùng

Sau khi mọi tính năng đã được phát triển xong

Liên tục trong suốt các sprint và trước mỗi bản phát hành

Chỉ khi có báo cáo lỗi nghiêm trọng

Các luồng dữ liệu đi qua chương trình

Các đường đi thực thi của chương trình dựa trên các cấu trúc điều khiển (như if, while, for)

Các giá trị biên của các biến

Các giao diện người dùng

Khả năng bảo mật dữ liệu người dùng

Khả năng đáp ứng, tốc độ, độ ổn định và sử dụng tài nguyên của hệ thống dưới các tải khác nhau

Tính dễ sử dụng và thân thiện với người dùng của giao diện

Khả năng tương thích với các hệ điều hành khác nhau

Không sử dụng bất kỳ kiến thức nào về cấu trúc bên trong

Sử dụng kiến thức hạn chế về cấu trúc bên trong để thiết kế các trường hợp kiểm thử hiệu quả hơn

Sử dụng toàn bộ kiến thức chi tiết về mã nguồn và kiến trúc

Chỉ sử dụng kiến thức về cơ sở dữ liệu

Tập trung nguồn lực vào các chức năng ít có khả năng xảy ra lỗi

Đảm bảo độ bao phủ mã nguồn cao nhất có thể

Ưu tiên kiểm thử các lĩnh vực có khả năng xảy ra lỗi cao nhất và tác động lớn nhất

Tự động hóa toàn bộ quy trình kiểm thử càng sớm càng tốt

Để viết mã nguồn cho ứng dụng

Để cung cấp một bản sao cấu hình phần cứng và phần mềm giống với môi trường sản xuất, nơi các ca kiểm thử được thực thi

Để lưu trữ tất cả các tài liệu dự án

Để theo dõi tiến độ của các ca kiểm thử

Mô hình Thác nước (Waterfall Model)

Mô hình Lặp (Iterative Model)

Mô hình Agile

Mô hình V (V-Model)

Phát hiện các lỗi mới được giới thiệu do thay đổi mã nguồn

Kiểm tra tất cả các chức năng của hệ thống từ đầu

Đánh giá hiệu năng của hệ thống dưới tải cao

Xác minh rằng các yêu cầu phi chức năng đã được đáp ứng

Kiểm thử thăm dò (Exploratory Testing)

Kiểm thử dựa trên cặp lỗi (Pairwise Testing)

Kiểm thử tất cả các kết hợp (All Combination Testing)

Kiểm thử phân vùng tương đương (Equivalence Partitioning)

Kiểm thử hộp trắng (White-box Testing)

Kiểm thử hộp đen (Black-box Testing)

Kiểm thử hộp xám (Gray-box Testing)

Kiểm thử đơn vị (Unit Testing)

Tốc độ xử lý của các giao dịch

Mức độ dễ dàng, hiệu quả và hài lòng khi người dùng tương tác với hệ thống

Khả năng chống lại các cuộc tấn công mạng

Tính chính xác của các phép tính số học

Một danh sách các lỗi đã tìm thấy

Một tài liệu mô tả chiến lược, mục tiêu, phạm vi, tài nguyên và lịch trình của hoạt động kiểm thử

Một tập hợp các trường hợp kiểm thử chi tiết

Một công cụ dùng để tự động hóa việc thực thi kiểm thử

Phân vùng tương đương (Equivalence Partitioning)

Phân tích giá trị biên (Boundary Value Analysis)

Bảng quyết định (Decision Table Testing)

Kiểm thử dựa trên trạng thái (State Transition Testing)

Khi chỉ có một vài điều kiện đầu vào

Khi có nhiều điều kiện đầu vào kết hợp với nhau theo các quy tắc logic phức tạp để xác định hành vi của hệ thống

Khi cần kiểm tra hiệu năng của hệ thống

Khi muốn kiểm tra tất cả các trường hợp biên

Trường hợp kiểm thử biên (Boundary Value Test Case)

Trường hợp kiểm thử hợp lệ (Valid Test Case)

Trường hợp kiểm thử không hợp lệ (Invalid Test Case)

Trường hợp kiểm thử ngoại lệ (Exception Test Case)

Kiểm tra từng module riêng lẻ một cách độc lập

Xác minh sự tương tác và luồng dữ liệu giữa các module hoặc dịch vụ đã được tích hợp

Đảm bảo hệ thống đáp ứng yêu cầu của người dùng cuối

Đánh giá hiệu năng tổng thể của hệ thống

Sau khi hệ thống đã được triển khai

Trong giai đoạn kiểm thử chấp nhận người dùng

Trong quá trình phát triển, bởi các lập trình viên

Sau khi kiểm thử tích hợp hoàn tất

Một đoạn mã tự động hóa quy trình kiểm thử

Một tập hợp các bước chi tiết, điều kiện, đầu vào và kết quả mong đợi để xác minh một tính năng hoặc chức năng cụ thể của phần mềm

Một tài liệu mô tả kiến trúc tổng thể của hệ thống

Một báo cáo về tất cả các lỗi đã tìm thấy

Kiểm thử điều kiện (Condition Testing)

Kiểm thử quyết định (Decision Testing)

Kiểm thử trạng thái (State Testing)

Kiểm thử luồng dữ liệu (Data Flow Testing)

Có, vì mọi câu lệnh đã được thực thi

Không, vì nó không đảm bảo các nhánh logic hoặc các đường đi phức tạp đã được kiểm tra

Không, vì nó chỉ tập trung vào các lỗi cú pháp

Có, nếu các trường hợp kiểm thử được thiết kế tốt

Kiểm thử hộp trắng

Kiểm thử hộp đen

Kiểm thử hộp xám

Kiểm thử dựa trên mô hình

Khi mã nguồn có quá ít câu lệnh

Khi mã nguồn có các vòng lặp và các nhánh phức tạp dẫn đến số lượng đường đi là rất lớn (hoặc vô hạn)

Khi chỉ có một vài điều kiện logic trong mã

Khi phần mềm được phát triển theo mô hình Agile

Để ghi lại các bước thực hiện trong test case

Để cung cấp đầu vào cho các trường hợp kiểm thử và xác minh kết quả đầu ra

Để mô tả các yêu cầu của dự án

Để báo cáo các lỗi tìm thấy