Một bảng quyết định được dùng

Kiểm thử Black-box (hộp đen) là một phương pháp kiểm thử phần mềm mà trong đó, người kiểm thử không cần biết cấu trúc bên trong, thiết kế, hay cách thức hoạt động của phần mềm. Thay vào đó, họ chỉ tập trung vào các đầu vào và đầu ra của phần mềm, để xem phần mềm có hoạt động đúng như mong đợi hay không. Mục tiêu của kiểm thử black-box là tìm ra các lỗi liên quan đến chức năng không đầy đủ hoặc không đúng, lỗi giao diện, và các lỗi thực thi khác mà người dùng có thể gặp phải khi sử dụng phần mềm.

• A. Chức năng không đầy đủ hay không đúng: Black-box testing nhằm phát hiện các chức năng bị thiếu hoặc hoạt động không đúng theo yêu cầu.
• B. Những lỗi giao diện: Kiểm thử black-box cũng giúp tìm ra các lỗi liên quan đến giao diện người dùng, đảm bảo tính thân thiện và dễ sử dụng.
• C. Những lỗi thực thi: Các lỗi trong quá trình thực thi, ví dụ như lỗi tính toán, lỗi xử lý dữ liệu, cũng có thể được phát hiện thông qua kiểm thử black-box.

Vì kiểm thử black-box bao gồm kiểm tra tất cả các khía cạnh trên, nên đáp án đúng là "Tất cả mục trên".

Biểu đồ dịch chuyển trạng thái (State Transition Diagram) mô tả các trạng thái mà một đối tượng có thể tồn tại và các sự kiện gây ra sự chuyển đổi giữa các trạng thái đó. Nó cho thấy hệ thống phản ứng như thế nào đối với các sự kiện bên ngoài, từ đó thay đổi trạng thái của mình. Do đó, đáp án đúng là "Chỉ ra những tƣơng tác của hệ thống đối với sự kiện bên ngoài". Các đáp án khác không mô tả đúng mục đích của biểu đồ dịch chuyển trạng thái.

Tiêu chuẩn đánh giá chất lượng của một thiết kế kiến trúc tập trung vào tính chức năng của hệ thống. Điều này bao gồm việc hệ thống có đáp ứng được các yêu cầu đặt ra, thực hiện đúng các chức năng dự kiến và đảm bảo hiệu quả hoạt động hay không. Các yếu tố khác như tính truy cập, tin cậy, dữ liệu, điều khiển và chi tiết thực thi cũng quan trọng nhưng chúng phục vụ cho mục tiêu cuối cùng là đảm bảo tính chức năng của hệ thống.

• Tính truy cập và tính tin cậy: Quan trọng để đảm bảo người dùng có thể sử dụng hệ thống một cách ổn định và an toàn, nhưng không phải là tiêu chuẩn đánh giá chất lượng chính của thiết kế kiến trúc.
• Dữ liệu và điều khiển của hệ thống: Liên quan đến cách hệ thống quản lý và xử lý thông tin, nhưng không trực tiếp đánh giá chất lượng tổng thể của thiết kế kiến trúc.
• Những chi tiết thực thi của hệ thống: Chi tiết thực thi là cần thiết cho việc triển khai, nhưng không phải là tiêu chí hàng đầu để đánh giá chất lượng thiết kế kiến trúc.

Trong phương pháp phân tích kiến trúc, việc mô tả mẫu kiến trúc thường sử dụng nhiều khung nhìn (view) khác nhau để thể hiện các khía cạnh khác nhau của hệ thống. Các khung nhìn phổ biến bao gồm:

• Khung nhìn dòng dữ liệu (Data Flow View): Thể hiện cách dữ liệu di chuyển và biến đổi trong hệ thống.
• Khung nhìn Module (Module View): Thể hiện cấu trúc module của hệ thống, cách các module được tổ chức và quan hệ giữa chúng.
• Khung nhìn Tiến trình (Process View): Thể hiện các tiến trình (processes) trong hệ thống và cách chúng tương tác với nhau.

Do đó, đáp án "Tất cả các mục trên" là đáp án chính xác nhất vì nó bao gồm tất cả các khung nhìn thường được sử dụng để mô tả mẫu kiến trúc.

Câu hỏi yêu cầu tìm nguyên lý thiết kế giao diện không cho phép người dùng còn quyền điều khiển tương tác. Các lựa chọn khác đều cho phép người dùng kiểm soát:

• Cho phép được gián đoạn: Người dùng có thể tạm dừng và tiếp tục công việc.
• Cho phép tương tác có thể undo: Người dùng có thể hoàn tác các hành động sai.
• Che dấu những bản chất kỹ thuật với những người dùng thường: Giúp giao diện thân thiện và dễ sử dụng hơn, người dùng tập trung vào tác vụ.

Chỉ có phương án "Chỉ cung cấp một cách thức xác định cứng khi hoàn thành tác vụ" là tước bỏ quyền kiểm soát của người dùng. Khi người dùng chỉ có một con đường duy nhất để hoàn thành tác vụ, họ không thể tùy biến hoặc điều chỉnh theo nhu cầu cá nhân.