Ôn tập thi lại SWT301 Summer 2026

Đáp án đúng: A. Rủi ro dự án là những rủi ro đe doạ khả năng dự án đạt mục tiêu, gồm yếu tố tổ chức (thiếu nhân lực, thiếu kỹ năng, vấn đề giao tiếp, chính trị nội bộ), yếu tố nhà cung cấp và yếu tố kỹ thuật. Vì vậy "Organizational Factors" là câu trả lời. Các phương án B, C, D - đặc tính phần mềm kém, phần mềm giao ra dễ lỗi, phần mềm không thực hiện đúng chức năng - đều mô tả chất lượng của sản phẩm được giao nên thuộc nhóm rủi ro sản phẩm.

Đáp án đúng: D. Kiểm thử hệ thống (system testing) tiến hành trên toàn bộ hệ thống đã tích hợp, kiểm tra mọi yêu cầu chức năng, thông tin, cấu trúc và chất lượng, và dùng một bộ ca kiểm thử đã định trước để chứng minh với ban quản lý rằng hệ thống đáp ứng đặc tả. Kiểm thử tích hợp (B) chỉ tập trung vào giao tiếp giữa các thành phần; kiểm thử chấp nhận người dùng (C) do người dùng thực hiện theo tiêu chí chấp nhận của họ, sau kiểm thử hệ thống; còn kiểm thử thẩm định (A) là khái niệm rộng, trả lời câu hỏi có xây dựng đúng sản phẩm hay không chứ không phải một mức kiểm thử cụ thể như mô tả trong đề.

Đáp án đúng: D. Phát biểu SAI là "kiểm thử thành phần không liên quan tới kiểm thử hồi quy": khi một thành phần được sửa, chính ở mức thành phần người ta phải chạy lại các ca kiểm thử cũ để bảo đảm thay đổi không phá vỡ hành vi đã đúng - đó là kiểm thử hồi quy ở mức đơn vị, thường được tự động hoá. Các phát biểu còn lại đều đúng: kiểm thử thành phần thường do chính đội phát triển thực hiện (A), còn được gọi là kiểm thử đơn vị, kiểm thử mô-đun hay kiểm thử cô lập (B), và cũng cần được lập kế hoạch với tiêu chí hoàn thành rõ ràng (C).

Đáp án đúng: C. Bảo mật, hiệu năng, độ tin cậy và tính khả dụng đều là các thuộc tính CHẤT LƯỢNG, mô tả hệ thống hoạt động TỐT ĐẾN MỨC NÀO chứ không phải hệ thống làm được gì. Việc đánh giá chúng thuộc phạm vi kiểm thử phi chức năng. Kiểm thử chức năng (B) chỉ kiểm tra hệ thống có thực hiện đúng các chức năng đặc tả hay không; tích hợp hệ thống (A) là một mức kiểm thử, quan tâm tới giao tiếp giữa các hệ thống; kiểm thử yêu cầu (D) không phải một loại kiểm thử tiêu chuẩn theo cách phân loại chức năng - phi chức năng - cấu trúc - liên quan đến thay đổi.

Đáp án đúng: B. Độ tin cậy (reliability) là xác suất phần mềm hoạt động không phát sinh sự cố trong một khoảng thời gian và điều kiện xác định. Vì vậy hệ thống tin cậy là hệ thống ÍT có khả năng gây ra hỏng hóc (failure) khi vận hành. Cần phân biệt fault (lỗi nằm trong mã) với failure (biểu hiện sai khi chạy): một hệ thống vẫn có thể chứa nhiều fault ở những nhánh hiếm khi được thực thi mà vẫn rất tin cậy, nên phương án C "gần như không còn lỗi" không phải định nghĩa của độ tin cậy. Phương án A nói về tiến độ dự án và phương án D nói về mức độ hài lòng của người dùng, đều là thuộc tính khác.

Đáp án đúng: C. Không thể kiểm thử vét cạn, nên câu hỏi "kiểm thử bao nhiêu là đủ" không có đáp số cố định: mức độ đủ phụ thuộc vào rủi ro của ngành nghề, các ràng buộc hợp đồng và những yêu cầu đặc thù của sản phẩm. Phần mềm y tế hay hàng không đòi hỏi mức kiểm thử khác hẳn một ứng dụng giải trí. Phương án A quá bi quan vì câu hỏi vẫn trả lời được khi đặt trong bối cảnh rủi ro cụ thể; phương án B ngược lại, quá lạc quan; phương án D chỉ nêu một yếu tố nhỏ, mức trưởng thành của đội phát triển không phải căn cứ chính để xác định khối lượng kiểm thử.

Đáp án đúng: A. Tiêu chí đầu ra (exit criteria) được đặt ra ngay trong kế hoạch kiểm thử để xác định khi nào một MỨC kiểm thử được coi là hoàn tất, thường gồm mức độ bao phủ đạt được, số lỗi còn mở, rủi ro tồn đọng và chi phí. Phương án B chỉ nói tới việc một phép kiểm thử đơn lẻ chạy xong, đó là chuyện thực thi chứ không phải tiêu chí đầu ra của cả mức kiểm thử; phương án C nói về vòng đời sản phẩm (khi nào ngừng sử dụng hệ thống); phương án D là việc so sánh kết quả thực tế với kết quả mong đợi, tức tiêu chí đạt/không đạt của một ca kiểm thử.

Đáp án đúng: C. Kiểm thử chỉ nên dừng khi các tiêu chí hoàn thành (test completion criteria / exit criteria) đã được thoả mãn, bởi đó là thước đo khách quan đã thống nhất từ khi lập kế hoạch. Hết thời gian (A) hay chạy xong toàn bộ ca kiểm thử đã lập (B) chỉ là điều kiện hành chính, không nói lên chất lượng sản phẩm. Không tìm thấy lỗi nào (D) càng nguy hiểm vì có thể do bộ ca kiểm thử yếu chứ không phải phần mềm tốt - kiểm thử không chứng minh được sự vắng mặt của lỗi.

Đáp án đúng: A. Khi thời gian và nguồn lực có hạn, kiểm thử phải được ưu tiên theo rủi ro. Hai định hướng đúng là kiểm thử những vùng trọng yếu nhất với quy trình nghiệp vụ (1) và những vùng có khả năng chứa nhiều lỗi nhất (2) - nguyên lý "defect clustering" cho biết lỗi thường dồn vào một số ít mô-đun. Định hướng (3), kiểm thử những chức năng dễ nhất, là sai vì nó tiêu tốn công sức vào phần ít rủi ro và bỏ sót phần nguy hiểm. Vì vậy 1 và 2 đúng, 3 sai, tức phương án A; các phương án còn lại hoặc công nhận (3) hoặc phủ nhận (1), (2) nên đều không đạt.

Đáp án đúng: A. Nhiệm vụ của Test Lead / Test Leader mang tính quản lý và định hướng: làm việc với nhà cung cấp công cụ để tận dụng công cụ cho dự án (i), viết báo cáo tổng kết kiểm thử từ dữ liệu thu thập được (ii), và quyết định cái gì nên tự động hoá, tự động tới mức nào và bằng cách nào (iii). Riêng việc soạn đặc tả kiểm thử, tức thiết kế chi tiết các ca kiểm thử (iv), là công việc của người kiểm thử (tester) chứ không phải của trưởng nhóm. Vậy i, ii, iii đúng và iv sai, đúng như phương án A.

Đáp án đúng: C. Giá trị cốt lõi mà công cụ và tự động hoá mang lại nằm ở cả hai nhóm thuộc tính. Thứ nhất là tốc độ và hiệu suất: máy chạy hàng nghìn ca kiểm thử trong thời gian con người chỉ chạy được vài chục, cho phép hồi quy sau mỗi lần build. Thứ hai là độ chính xác và tính nhất quán: công cụ lặp lại đúng từng bước, không mệt mỏi, không bỏ sót, nên kết quả có thể tái lập. Vì cả (1) và (2) đều đúng nên phải chọn phương án gộp; chọn riêng A hoặc B đều bỏ mất một nửa lợi ích, còn D phủ định cả hai nên sai.

Đáp án đúng: A. Ma trận Chức năng/Kiểm thử (Function/Test Matrix) đối chiếu từng chức năng của hệ thống với các ca kiểm thử tương ứng và trạng thái thực hiện của chúng, cho thấy tiến độ và mức bao phủ TẠI THỜI ĐIỂM đang kiểm thử. Vì được lập và cập nhật trong lúc kiểm thử còn diễn ra, nó được xếp vào nhóm báo cáo kiểm thử tạm thời (interim test report). Báo cáo kiểm thử cuối cùng (B) chỉ lập khi kết thúc; báo cáo trạng thái dự án (C) và báo cáo quản lý (D) có phạm vi rộng hơn, không phải phân loại của tài liệu này.

Đáp án đúng: D. Trường dữ liệu chỉ chấp nhận chữ cái, không phân biệt hoa thường. Vì vậy CLASS, cLASS và CLass đều nằm trong lớp tương đương HỢP LỆ - chúng chỉ khác nhau ở kiểu chữ, một yếu tố mà đặc tả đã cho phép. Riêng CLa01ss chứa hai chữ số 0 và 1 nên rơi vào lớp tương đương KHÔNG hợp lệ, đúng như câu hỏi yêu cầu. Đây cũng là minh hoạ cho nguyên tắc phân hoạch tương đương: mỗi lớp là tập giá trị mà hệ thống được kỳ vọng xử lý theo cùng một cách.

Đáp án đúng: C. Sáu pha của quy trình rà soát chính thức theo đúng thứ tự là: Planning (lập kế hoạch, chọn người, xác định tiêu chí vào ra) → Kick Off (họp mở đầu, phân phát tài liệu, giải thích mục tiêu) → Individual Preparations (mỗi người tự nghiên cứu và ghi nhận vấn đề) → Review Meeting (họp rà soát, thảo luận và ghi nhận lỗi) → Rework (tác giả sửa) → Follow Up (kiểm tra việc sửa và đóng rà soát). Chuỗi này ứng với i, v, iv, ii, iii, vi, tức phương án C. Các phương án còn lại đảo lộn thứ tự, đặc biệt đặt Kick Off và Individual Preparations sai vị trí.

Đáp án đúng: B. Rà soát chính thức (Inspection) có các đặc điểm: do một moderator được đào tạo dẫn dắt chứ không phải tác giả (i đúng); có quy trình theo dõi khắc phục chính thức sau cuộc họp (iii đúng); mục tiêu chính là tìm khiếm khuyết (iv đúng). Riêng phát biểu ii - "không có chuẩn bị trước cuộc họp" - là SAI, vì Individual Preparations chính là pha bắt buộc và quyết định hiệu quả của Inspection. Vậy i, iii, iv đúng và ii sai, tương ứng phương án B.

Đáp án đúng: B. Tích hợp từ dưới lên (bottom-up integration) bắt đầu từ các mô-đun ở mức thấp nhất, tức các mô-đun lá trong cây gọi hàm, rồi ghép dần lên các mô-đun cấp cao hơn; nó cần các driver để giả lập mô-đun gọi. Ngược lại, tích hợp từ trên xuống (A) bắt đầu từ mô-đun điều khiển cấp cao và dùng stub thay cho các mô-đun chưa có. "Module integration" (D) không phải tên một chiến lược tích hợp chuẩn, còn C bị loại vì B đã đúng.

Đáp án đúng: A. Theo thuật ngữ chuẩn, failure (hỏng hóc) là biểu hiện hành vi sai của chương trình khi thực thi, do một fault (lỗi trong mã) gây ra, và fault lại bắt nguồn từ error (sai sót của con người). Vì vậy failure gắn với hành vi chạy sai chứ không gắn với thời điểm tìm thấy lỗi. Các phương án B, C, D đều định nghĩa theo mốc thời gian phát hiện - trước khi phát hành, sau khi phát hành hay trong pha thiết kế - nên nhầm giữa khái niệm failure với cách phân loại lỗi theo giai đoạn.

Một số yếu tố thành công cho một cuộc đánh giá bao gồm: mỗi đánh giá không có một mục tiêu được định trước (i), các lỗi được tìm thấy được chào đón và được thể hiện một cách khách quan (ii), quản lý hỗ trợ một quá trình đánh giá tốt (iii) và có một trọng tâm vào việc học hỏi và cải tiến quy trình (iv). Các yếu tố này đóng vai trò quan trọng trong việc đảm bảo rằng quá trình đánh giá được thực hiện một cách hiệu quả và mang lại kết quả tích cực. Điều này giúp cho các cá nhân và tổ chức có thể học hỏi từ các lỗi và cải thiện quy trình của mình.

Đáp án đúng: D. Với phần mềm mua sẵn hoặc thuê ngoài gia công, bên mua thường chỉ nhận được sản phẩm chạy được cùng tài liệu người dùng, còn mã nguồn và cấu trúc bên trong thuộc quyền sở hữu của nhà cung cấp nên không có sẵn cho đội kiểm thử. Do đó chỉ có thể kiểm thử hộp đen dựa trên đặc tả. Trong phát triển truyền thống (A), phát triển lặp (B) và bảo trì hệ thống (C), tổ chức đều nắm mã nguồn của mình nên đội kiểm thử có thể tiếp cận cấu trúc nội bộ khi cần áp dụng kỹ thuật hộp trắng.

Sử dụng các công cụ kiểm thử (test tools) có thể mang lại nhiều lợi ích cho quá trình kiểm thử và bảo trì phần mềm. Trong số các lựa chọn trên, hai lợi ích được cho là có thể đạt được là dễ dàng truy cập thông tin về kiểm thử và kiểm tra (i) và sự nhất quán cao hơn trong kiểm thử (iv). Điều này là vì các công cụ kiểm thử thường cung cấp khả năng truy cập dễ dàng vào thông tin về kiểm thử, bao gồm cả lịch sử kiểm thử và kết quả kiểm thử. Đồng thời, các công cụ kiểm thử cũng có thể giúp đảm bảo rằng các kiểm thử được thực hiện một cách nhất quán và chính xác, giảm thiểu khả năng xảy ra lỗi trong quá trình kiểm thử. Các lợi ích khác như giảm thiểu bảo trì phần mềm kiểm thử (ii) và dễ dàng và rẻ tiền để triển khai (iii) có thể không được đảm bảo khi sử dụng các công cụ kiểm thử, vì chúng phụ thuộc vào nhiều yếu tố như loại công cụ, quy trình kiểm thử và nguồn lực của tổ chức.