Mô hình nào đưa ra hình ảnh tiền sử (profile) người dùng cuối của hệ thống dựa vào máy tính:

Kiểm thử tích hợp bottom-up là một phương pháp kiểm thử phần mềm, trong đó các module ở mức thấp nhất được kiểm thử trước, sau đó tích hợp và kiểm thử các module ở mức cao hơn cho đến khi tất cả các module được tích hợp và kiểm thử.

* Những điểm quyết định chính được kiểm thử sớm: Đúng. Trong kiểm thử bottom-up, các module cấp thấp nhất (thường là các module quan trọng, quyết định) được kiểm thử đầu tiên, giúp phát hiện sớm các lỗi tiềm ẩn ở các thành phần cơ bản của hệ thống.
* Không có những driver cần được viết: Đúng. Driver là các đoạn code được sử dụng để thay thế các module cấp cao hơn chưa được phát triển trong quá trình kiểm thử các module cấp thấp hơn trong kiểm thử top-down. Trong kiểm thử bottom-up, ta không cần driver vì ta kiểm thử từ dưới lên, các module cấp thấp được kiểm thử độc lập trước khi tích hợp với các module cấp cao hơn.
* Không có những stub (nhánh) cần phải viết: Sai. Stub là các đoạn code được sử dụng để thay thế các module cấp thấp hơn chưa được phát triển trong quá trình kiểm thử các module cấp cao hơn trong kiểm thử top-down. Trong kiểm thử bottom-up, ta vẫn cần stubs để mô phỏng các module cấp cao hơn khi ta tích hợp các module cấp thấp lại với nhau.
* Không đòi hỏi kiểm thử hồi quy (regression): Sai. Kiểm thử hồi quy là cần thiết sau mỗi lần thay đổi code để đảm bảo các thay đổi không gây ra lỗi mới. Kiểm thử tích hợp bottom-up cũng không ngoại lệ, vẫn cần kiểm thử hồi quy.

Như vậy, các đáp án đúng là "Những điểm quyết định chính được kiểm thử sớm" và "Không có những driver cần được viết". Do câu hỏi chỉ cho phép chọn một đáp án, và "Những điểm quyết định chính được kiểm thử sớm" là một ưu điểm quan trọng hơn so với việc không cần driver, nên đáp án này được ưu tiên lựa chọn.

Thiết kế Testcase theo Boris Beizer cần đảm bảo các ràng buộc sau:

* Nhằm khám phá lỗi: Mục tiêu chính của testcase là tìm ra lỗi trong phần mềm.
* Nỗ lực và thời gian là tối thiểu: Testcase cần được thiết kế sao cho hiệu quả, tốn ít công sức và thời gian nhất mà vẫn đảm bảo khả năng phát hiện lỗi.
* Theo một cách thức đầy đủ: Testcase cần bao phủ đầy đủ các khía cạnh của phần mềm, đảm bảo không bỏ sót các trường hợp kiểm thử quan trọng.

Vì vậy, đáp án "Tất cả đều đúng" là đáp án chính xác nhất.

Kiến trúc phần mềm (software architecture) định nghĩa cấu trúc cơ bản của một hệ thống phần mềm. Các kiểu kiến trúc phổ biến bao gồm kiến trúc luồng dữ liệu (data flow), kiến trúc tầng (layered), và kiến trúc hướng sự kiện (event-driven). Kiến trúc ngữ cảnh (context architecture) là một khái niệm có liên quan, nhưng không trực tiếp được coi là một "kiểu kiến trúc" theo nghĩa các kiểu kiến trúc khác. "Gọi trả về" (callback) là một kỹ thuật lập trình, không phải là một kiểu kiến trúc.

Do đó, "Gọi trả về" không phải là một loại kiến trúc.

IEEE 830-1993 là một tiêu chuẩn được khuyến nghị cho đặc tả yêu cầu phần mềm (Software Requirement Specification - SRS). SRS là một tài liệu mô tả đầy đủ hành vi dự kiến của phần mềm sẽ được phát triển. Nó bao gồm một mô tả đầy đủ về những gì phần mềm sẽ làm và những ràng buộc mà nó phải tuân theo. Các tùy chọn khác như thiết kế phần mềm (Software Design), kiểm thử (Testing) và mã hóa (Coding) có các tiêu chuẩn IEEE riêng biệt.