Tất cả câu hỏi

Đáp án đúng: "The answer depends on the risk for your industry, contract and special requirements". Kiểm thử vét cạn là không thể, nên ISTQB trả lời câu hỏi bao nhiêu kiểm thử là đủ bằng rủi ro: mức rủi ro của ngành và sản phẩm, ràng buộc hợp đồng, yêu cầu đặc biệt như quy định pháp lý, cùng thời gian và ngân sách, quyết định phải kiểm thử sâu tới đâu và ưu tiên chỗ nào. "This question is impossible to answer" sai vì tuy không có con số tuyệt đối, ta vẫn trả lời được bằng tiêu chí dựa trên rủi ro và tiêu chí thoát. "This question is easy to answer" sai vì câu trả lời đòi hỏi phân tích rủi ro cho từng bối cảnh, không có công thức chung. "This answer depends on the maturity of your developers" chỉ đúng một phần: lập trình viên trưởng thành có thể sinh ít khiếm khuyết hơn, nhưng đó không phải căn cứ chính để quyết định mức kiểm thử, rủi ro mới là căn cứ.

Đáp án đúng: "To define when a test level is complete.". Tiêu chí thoát (exit criteria) là các điều kiện được thống nhất với các bên liên quan, như mức độ phủ đạt được, số khiếm khuyết nghiêm trọng còn mở, rủi ro còn lại, để quyết định một cấp kiểm thử hay một hoạt động kiểm thử đã có thể coi là hoàn thành; chúng được đặt khi lập kế hoạch và được đánh giá ở pha đánh giá tiêu chí thoát và báo cáo. "To determine when a test has completed." nhầm phạm vi: một ca kiểm thử chạy xong là khi các bước được thực hiện hết, không cần tiêu chí thoát. "To identify when a software system should be retired." thuộc quyết định bảo trì và vòng đời sản phẩm, không liên quan tới tiêu chí thoát của kiểm thử. "To determine whether a test has passed." là việc so kết quả thực tế với kết quả mong đợi của từng ca, khác với việc quyết định dừng cả cấp kiểm thử.

Đáp án đúng: "When the test completion criteria have been met". Tiêu chí hoàn thành (test completion criteria, hay exit criteria) được đặt từ lúc lập kế hoạch, chẳng hạn mức độ phủ, số khiếm khuyết còn mở, rủi ro còn lại chấp nhận được, và chính chúng là căn cứ khách quan để dừng kiểm thử. "When time for testing has run out." là điều hay xảy ra trong thực tế nhưng là dừng vì áp lực, không bảo đảm chất lượng đạt yêu cầu; thời gian chỉ hợp lệ khi đã được ghi vào tiêu chí. "When all planned tests have been run" chưa đủ vì có thể còn nhiều ca thất bại hay khiếm khuyết nghiêm trọng chưa sửa. "When no faults have been found by the tests run" sai vì kiểm thử chỉ chứng minh có khiếm khuyết chứ không chứng minh được không còn khiếm khuyết; không tìm thấy lỗi có thể chỉ do bộ ca yếu.

Đáp án đúng: "1&2 are true and 3 is false". Khi nhận một phần mềm với thời gian và nguồn lực có hạn, không thể kiểm thử vét cạn, nên ISTQB khuyên kiểm thử dựa trên rủi ro (risk-based testing): ưu tiên các vùng quan trọng nhất với quy trình nghiệp vụ, nơi hỏng hóc gây tác động lớn, và các vùng nhiều khả năng chứa lỗi nhất theo nguyên lý lỗi tụ thành cụm (defect clustering). Vì thế mệnh đề 1 và 2 đúng, còn kiểm thử các chức năng dễ nhất là sai vì dễ kiểm thử không có nghĩa là rủi ro cao. "1,2&3 are true." sai vì nhận cả tiêu chí dễ nhất, vốn không phản ánh tác động hay khả năng hỏng. "1 is true, 2&3 are false." bỏ mất vùng nhiều lỗi, trái với nguyên lý lỗi tụ thành cụm. "1&2 are false, 3 is true" đảo ngược hoàn toàn, chọn việc dễ thay vì việc quan trọng.

Đáp án đúng: "If the client needs to have a dialog with the service". Broker Forwarding chuyển tiếp mọi lời gọi qua broker, còn Broker Handle thì broker chỉ trả về một handle (tham chiếu) tới dịch vụ để sau đó client giao tiếp trực tiếp với dịch vụ. Vì vậy Broker Handle đặc biệt hữu ích khi client cần trao đổi nhiều lượt, tức là có một phiên hội thoại với dịch vụ: chỉ phải qua broker một lần rồi làm việc trực tiếp, tránh nút thắt cổ chai. Nếu client chỉ gọi một lần, như phương án "If the client only communicates with the service once", thì forwarding đơn giản hơn; phương án "knows the type of service required" mô tả tình huống dùng dịch vụ môi giới nói chung; phương án "If the client needs to provide the broker with a handle" đảo ngược vai trò - chính broker mới là bên cấp handle.

Đáp án đúng: "Defining system structure and high-level components". Thiết kế kiến trúc trong phát triển phần mềm tập trung vào việc xác định cấu trúc tổng thể của hệ thống và các thành phần ở mức cao: hệ thống gồm những khối nào, mỗi khối chịu trách nhiệm gì, chúng giao tiếp qua giao diện và cơ chế nào, đồng thời cân nhắc các thuộc tính chất lượng như hiệu năng, bảo mật, khả năng mở rộng. Chi tiết hoá hiện thực của từng lớp thuộc thiết kế chi tiết; viết ca kiểm thử thuộc pha kiểm thử; tái cấu trúc mã nguồn là hoạt động cải tiến mã đã có, đều nằm ở mức thấp hơn so với thiết kế kiến trúc.

Đáp án đúng: "The number of objects in a relationship." Multiplicity trong UML thể hiện số lượng đối tượng có thể tham gia vào một quan hệ - tức là mỗi thể hiện ở đầu này của liên kết ứng với bao nhiêu thể hiện ở đầu kia, viết dưới dạng 1, 0..1, 1..* hay *. Nó ràng buộc cấu trúc dữ liệu của mô hình và là căn cứ để sinh khoá ngoại, bảng trung gian khi ánh xạ sang cơ sở dữ liệu quan hệ. Số lượng lớp ("The number of classes."), số thuộc tính ("The number of attributes.") và số chuyển trạng thái ("The number of state transitions.") đều là những đại lượng đếm khác trong mô hình, không phải nội dung mà ký hiệu multiplicity biểu diễn.

Đáp án đúng: "A class that is required by all members of the SPL". Trong dòng sản phẩm phần mềm (SPL), kernel class là lớp bắt buộc phải có ở MỌI thành viên của dòng sản phẩm - đó là phần lõi chung, không thay đổi giữa các biến thể. Bên cạnh kernel còn có lớp tuỳ chọn (optional) chỉ xuất hiện ở một số thành viên và lớp biến thể (variant) có nhiều phiên bản khác nhau. Các phương án "An entity class in the SPL" và "A SPL class that stores essential data" mô tả vai trò lưu trữ dữ liệu của lớp thực thể chứ không nói tới tính bắt buộc chung; phương án "An external class to the SPL" đặt lớp ra ngoài dòng sản phẩm, trái hẳn với ý nghĩa "lõi" của kernel.

Đáp án đúng: "To describe a use case that includes other use cases". Inclusion use case là use case được các use case khác gọi tới bằng quan hệ include, dùng để tách phần hành vi chung lặp lại ở nhiều use case ra một nơi duy nhất. Trong câu hỏi này, cách diễn đạt đúng nhất là dùng nó để mô tả một use case có bao gồm các use case khác, tức là mối quan hệ bao hàm giữa các use case. Phương án "To describe an inclusive use case" chỉ lặp lại chính từ trong câu hỏi mà không giải thích được điều gì; "To describe a lengthy interaction with an actor" nói về độ dài tương tác với tác nhân, hoàn toàn không phải tiêu chí để tách một inclusion use case.

Đáp án đúng: "Ability to handle increasing load". Scalability - khả năng mở rộng - là thuộc tính chất lượng phản ánh khả năng hệ thống đáp ứng được tải tăng lên (nhiều người dùng, nhiều giao dịch, nhiều dữ liệu hơn) mà vẫn giữ được mức chất lượng dịch vụ, thường bằng cách bổ sung tài nguyên theo chiều ngang hoặc chiều dọc. Khả năng chạy trên nhiều nền tảng là portability; bảo vệ tài nguyên là security; còn tốc độ thuật toán chỉ là một yếu tố góp phần vào performance. Cả ba đều là những thuộc tính chất lượng khác, không phải định nghĩa của scalability.

Đáp án đúng: "Software architecture design". Pha thiết kế kiến trúc phần mềm là nơi trả lời câu hỏi các thành phần phần mềm ghép với nhau và tương tác ra sao để thoả mãn yêu cầu: xác định các thành phần chính, giao diện, cơ chế giao tiếp và các mẫu kiến trúc được dùng. "Requirement gathering" mới chỉ làm rõ hệ thống phải làm gì; "User interface design" chỉ giải quyết một khía cạnh hẹp là tương tác với người dùng; "Testing and validation" diễn ra sau, nhằm kiểm chứng rằng hệ thống đã xây dựng đáp ứng đúng yêu cầu chứ không phải nơi định hình cấu trúc.

Đáp án đúng: "Multiplicity". Khi thiết lập liên kết giữa các đối tượng trên sơ đồ lớp, khái niệm nền tảng là multiplicity - bội số, cho biết mỗi thể hiện của lớp này có thể liên kết với bao nhiêu thể hiện của lớp kia (1, 0..1, 1..*, *). Bội số quyết định bản chất quan hệ một - một, một - nhiều hay nhiều - nhiều và về sau chi phối cả cách ánh xạ sang cơ sở dữ liệu quan hệ. Kiểu dữ liệu thuộc về thuộc tính của lớp; tên use case nằm ở mô hình use case; transition trigger là yếu tố của máy trạng thái, đều không liên quan tới việc xác lập liên kết.

Đáp án đúng: "To partition the system into manageable, reusable modules". Trọng tâm của thiết kế kiến trúc hệ thống con là phân hoạch hệ thống thành các mô-đun dễ quản lý và có thể tái sử dụng, mỗi mô-đun có trách nhiệm rõ ràng, kết dính cao bên trong và ghép lỏng với bên ngoài qua giao diện được định nghĩa tường minh. Nhờ đó nhiều nhóm có thể phát triển song song và thay đổi cục bộ không lan rộng. Phương án "To eliminate object-oriented design dependencies" sai vì thiết kế kiến trúc quản lý chứ không loại bỏ phụ thuộc hướng đối tượng; phương án "To simplify use case modeling" nhầm sang pha phân tích use case; phương án "To reduce the need for UML diagrams" sai vì kiến trúc càng cần UML để mô tả, không phải để giảm bớt.

Đáp án đúng: "The structuring of the system into subsystems". Thiết kế kiến trúc hệ thống con tập trung vào việc cấu trúc hoá toàn hệ thống thành các hệ thống con: xác định ranh giới, trách nhiệm, giao diện và quan hệ giữa chúng, đồng thời chọn mẫu kiến trúc phù hợp. Đây là mức nhìn tổng thể, đứng trên mức lớp. Phương án "The transition from analysis to design" mô tả chung cả bước chuyển từ phân tích sang thiết kế chứ không nói được trọng tâm; phương án "The design of user interfaces" chỉ là một phần nhỏ thuộc thiết kế giao diện người dùng; phương án "The implementation of individual classes" thuộc mức thiết kế chi tiết và hiện thực từng lớp, diễn ra sau khi cấu trúc hệ thống con đã được xác lập.

Đáp án đúng: "Provide structured architectural modeling". COMET (Collaborative Object Modeling and Architectural Design Method) là phương pháp thiết kế cung cấp một quy trình mô hình hoá kiến trúc có cấu trúc: đi từ mô hình use case sang mô hình phân tích tĩnh và động, rồi tới thiết kế kiến trúc phần mềm bằng các mẫu kiến trúc và mẫu thiết kế. Mục tiêu chính là giúp nhóm phát triển tổ chức được quá trình thiết kế một cách có hệ thống. Phương án "Increase database performance" nhầm sang tối ưu cơ sở dữ liệu; phương án "Eliminate the need for state charts" sai vì COMET dùng rất nhiều statechart; phương án "Enforce strict coding conventions" nói về quy ước viết mã, hoàn toàn nằm ngoài phạm vi của một phương pháp thiết kế kiến trúc.

Đáp án đúng: "A class that cannot be instantiated and may contain abstract operations". Trong UML, abstract class là lớp không thể tạo thể hiện trực tiếp và có thể chứa các thao tác trừu tượng - những thao tác chỉ khai báo chữ ký, để lớp con hiện thực hoá. Lớp trừu tượng tồn tại nhằm gom phần chung của các lớp con và định nghĩa giao diện đa hình cho chúng; trong sơ đồ, tên lớp được viết nghiêng để đánh dấu. Các phương án "A class that has no attributes", "A class with only static methods" và "A class defined without associations" nêu những đặc điểm không liên quan: một lớp không có thuộc tính, một lớp chỉ có phương thức tĩnh hay một lớp không có liên kết đều vẫn có thể được khởi tạo bình thường nên không phải lớp trừu tượng.

Đáp án đúng: "Layered architecture". Kiến trúc phân tầng tổ chức hệ thống thành một hệ thứ bậc các tầng, trong đó mỗi tầng cung cấp dịch vụ cho tầng ngay trên nó và chỉ sử dụng dịch vụ của tầng ngay dưới. Cách tổ chức này làm rõ trách nhiệm, giới hạn phạm vi thay đổi và cho phép thay thế một tầng mà ít ảnh hưởng phần còn lại. Client-server chia theo vai trò yêu cầu - phục vụ chứ không theo thứ bậc dịch vụ; peer-to-peer đặt các nút ngang hàng, vừa là client vừa là server; pipe-and-filter nối các bộ lọc thành dây chuyền xử lý dữ liệu tuần tự.

Đáp án đúng: "Generalization". Trả tiền mặt và trả bằng thẻ là hai cách thực hiện KHÁC NHAU của cùng một hành vi trả tiền, nên use case Cash payment là một trường hợp chuyên biệt hoá của use case Payment - quan hệ generalization, trong đó Payment đóng vai trò use case trừu tượng. Quan hệ "Include" dùng khi một use case luôn gọi trọn vẹn một use case khác như phần dùng chung; "Extend" dùng cho hành vi tuỳ chọn, chỉ chèn thêm khi thoả điều kiện; còn "Abstract" là một tính chất của phần tử mô hình chứ không phải một loại quan hệ giữa các use case.

Đáp án đúng: "Whether to partition by domain or technical capabilities". Một cân nhắc then chốt khi phân hoạch thành phần là chọn ranh giới phân chia: theo miền nghiệp vụ (mỗi thành phần phụ trách một mảng nghiệp vụ trọn vẹn) hay theo năng lực kỹ thuật (chia theo tầng như giao diện, nghiệp vụ, dữ liệu). Lựa chọn này quyết định mức độ kết dính, ghép nối và khả năng phát triển độc lập của từng nhóm. Ngôn ngữ lập trình ("Programming language used"), phần cứng chạy hệ thống ("Hardware the system will run on") và bảng màu giao diện ("UI color scheme") là những quyết định ở mức hiện thực hoặc trình bày, không định hình cách chia hệ thống thành các thành phần.

Đáp án đúng: "Identify the system’s objects and their relationships". Mục tiêu chính của phân tích hướng đối tượng là nhận diện các đối tượng của hệ thống trong miền bài toán cùng thuộc tính, trách nhiệm và quan hệ giữa chúng, từ đó xây dựng mô hình tĩnh và mô hình động phản ánh bài toán thực tế. Đây là bước "làm rõ cái gì" trước khi chuyển sang thiết kế "làm như thế nào". Phương án "Define user interface layouts" và phương án "Develop a deployment model" thuộc pha thiết kế (giao diện người dùng, mô hình triển khai); phương án "Optimize database queries" là việc tối ưu ở mức hiện thực và cơ sở dữ liệu, diễn ra rất muộn trong vòng đời và không phải mục tiêu của phân tích.