Tất cả câu hỏi

Ngân hàng câu hỏi trắc nghiệm có đáp án và giải thích chi tiết.

Bấm vào từng câu để xem đáp án
#101
ĐỘ CHÍNH XÁC
4 LỰA CHỌN
ABoundary value analysis
Equivalence partitioningĐÚNG
CDecision table testing
DState transition testing
Giải thích

Đáp án đúng: B. Phân hoạch tương đương chia miền giá trị thành các lớp mà hệ thống được kỳ vọng xử lý như nhau, và kỹ thuật này áp dụng được cho cả ĐẦU VÀO lẫn ĐẦU RA, nhờ đó đạt được bao phủ cả hai phía chỉ với một ca kiểm thử đại diện cho mỗi lớp. Phân tích giá trị biên (A) là kỹ thuật bổ sung, tập trung vào rìa của các lớp chứ không tự nó cho bao phủ toàn miền; bảng quyết định (C) dùng cho tổ hợp điều kiện nghiệp vụ; kiểm thử chuyển trạng thái (D) dùng khi hành vi phụ thuộc vào trạng thái và lịch sử.

#102
ĐỘ CHÍNH XÁC
4 LỰA CHỌN
A2 Test Cases
B3 Test Cases
4 Test CasesĐÚNG
DNot achievable
Giải thích

Đáp án đúng: C. Đoạn chương trình gồm hai cấu trúc rẽ nhánh nối tiếp và độc lập nhau. Cấu trúc thứ nhất if-else cho hai đường đi (đi nhánh statement 1 hoặc statement 2); cấu trúc thứ hai if-then cũng cho hai đường đi (thực thi statement 3 hoặc bỏ qua). Vì hai điều kiện độc lập, tổng số đường đi qua cả đoạn là 2 × 2 = 4, nên cần 4 ca kiểm thử để phủ hết mọi trình tự câu lệnh. Lưu ý phân biệt với bao phủ câu lệnh (chỉ cần 2 ca) và bao phủ nhánh (cũng 2 ca) - phủ ĐƯỜNG ĐI luôn đòi hỏi nhiều ca hơn.

#103
ĐỘ CHÍNH XÁC
3 LỰA CHỌN
AOFF to ON
BON to OFF
FAULT to ONĐÚNG
Giải thích

Đáp án đúng: C. Theo sơ đồ, công tắc có ba trạng thái: OFF, ON và FAULT. Các chuyển hợp lệ được vẽ là OFF sang ON, ON sang OFF, ON sang FAULT và FAULT quay về chính nó. Không có mũi tên nào đi từ FAULT sang ON, nên chuyển "FAULT to ON" là chuyển KHÔNG hợp lệ - đây chính là loại ca kiểm thử âm mà kỹ thuật state transition testing dùng để kiểm tra hệ thống có chặn được chuyển trạng thái sai hay không. Hai phương án A và B đều là chuyển đã được vẽ tường minh trên sơ đồ nên hợp lệ.

#104
ĐỘ CHÍNH XÁC
4 LỰA CHỌN
AIs the same as equivalence partitioning tests
Test boundary conditions on, below and above the edges of input and output equivalence classesĐÚNG
CTests combinations of input circumstances
DIs used in white box testing strategy
Giải thích

Đáp án đúng: B. Kiểm thử giá trị biên tập trung vào các giá trị nằm TẠI biên và ngay dưới, ngay trên biên của các lớp tương đương đầu vào và đầu ra, vì lỗi lập trình rất hay xảy ra ở chỗ so sánh nhỏ hơn với nhỏ hơn hoặc bằng. Nó bổ sung cho phân hoạch tương đương chứ không đồng nhất với kỹ thuật này (A sai). Kiểm thử tổ hợp các điều kiện đầu vào (C) là bảng quyết định; và giá trị biên là kỹ thuật hộp ĐEN dựa trên đặc tả, không phải chiến lược hộp trắng (D sai).

#105
ĐỘ CHÍNH XÁC
4 LỰA CHỌN
ACLASS
BcLASS
CCLass
CLa01ssĐÚNG
Giải thích

Đá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.

#106
ĐỘ CHÍNH XÁC
4 LỰA CHỌN
ATraditional system development
BIterative development
CSystem maintenance
Purchased/contracted softwareĐÚNG
Giải thích

Đá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.

#107
ĐỘ CHÍNH XÁC
4 LỰA CHỌN
Aii is true and i,iii,iv are false
i,iii,iv are true and ii is falseĐÚNG
Ci,iii,iv are false and ii is true
Diii is true and I,ii,iv are false
Giải thích

Đá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.

#108
ĐỘ CHÍNH XÁC
4 LỰA CHỌN
AThe use of a variable before it has been defined
BUnreachable ("dead") code
Memory leaksĐÚNG
DArray bound violations
Giải thích

Đáp án đúng: C. Phân tích tĩnh làm việc trên mã nguồn mà không chạy chương trình, nên nó phát hiện tốt các khiếm khuyết lộ ra từ cấu trúc mã: dùng biến trước khi gán (A), mã không bao giờ được thực thi (B), truy cập vượt biên mảng khi chỉ số xác định tĩnh được (D). Ngược lại, rò rỉ bộ nhớ là hiện tượng chỉ bộc lộ trong quá trình CHẠY, khi bộ nhớ được cấp phát mà không được giải phóng theo thời gian - đó là địa hạt của phân tích động và các công cụ theo dõi bộ nhớ, nên phân tích tĩnh không tìm được.

#109
ĐỘ CHÍNH XÁC
4 LỰA CHỌN
ACompiling code is not a form of static analysis
Static analysis need not be performed before imperative code is executedĐÚNG
Static analysis can find faults that are hard to find with dynamic testing.ĐÚNG
DExtensive statistical analysis will not be needed if white- Box testing is to be performed.
Giải thích

Đáp án đúng: B và C. Phân tích tĩnh là việc phân tích mã nguồn hoặc tài liệu mà KHÔNG thực thi chương trình. Phát biểu C đúng: nhờ soi trực tiếp cấu trúc mã, nó phát hiện được những khiếm khuyết mà kiểm thử động rất khó lộ ra, như biến chưa khởi tạo, mã không bao giờ chạy tới, vi phạm chuẩn lập trình. Phát biểu B cũng đúng: phân tích tĩnh không bắt buộc phải làm trước khi mã được thực thi, nó có thể áp dụng ở bất kỳ thời điểm nào của vòng đời. Phát biểu A sai vì bản thân trình biên dịch chính là một dạng phân tích tĩnh; phát biểu D sai vì kiểm thử hộp trắng không thay thế được phân tích tĩnh.

#110
ĐỘ CHÍNH XÁC
4 LỰA CHỌN
Ai,ii,iii,iv,v,vi
Bvi,i,ii,iii,iv,v
i,v,iv,ii,iii,viĐÚNG
Di,ii,iii,v,iv,vi
Giải thí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í.

#111
ĐỘ CHÍNH XÁC
4 LỰA CHỌN
Ai,ii,iii,iv are true
i,ii,iii are true and iv is false.ĐÚNG
Cii,iii,iv are true and i is false.
Di,iv are true and ii, iii are false.
Giải thích

Đáp án đúng: B. Các vai trò trong một cuộc rà soát chính thức gồm: Manager (người quyết định tổ chức rà soát, cấp nguồn lực), Moderator (người điều phối, dẫn dắt cuộc họp), Author (tác giả tài liệu), Reviewers (người rà soát) và Scribe/Recorder (người ghi chép). Như vậy i, ii, iii đều đúng, còn "Assistant Manager" (iv) không phải một vai trò được định nghĩa trong quy trình rà soát chính thức, nên iv sai - đúng như phương án B mô tả.

#112
ĐỘ CHÍNH XÁC
4 LỰA CHỌN
Organizational FactorsĐÚNG
BPoor Software characteristics
CError Prone software delivered.
DSoftware that does not perform its intended functions
Giải thích

Đá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.

#113
ĐỘ CHÍNH XÁC
4 LỰA CHỌN
ASupplier issues
BOrganization factors
CTechnical issues
Error-prone software deliveredĐÚNG
Giải thích

Đáp án đúng: D. Rủi ro được chia thành rủi ro dự án (project risk) - liên quan tới khả năng quản lý và triển khai dự án - và rủi ro sản phẩm (product risk) - liên quan tới bản thân phần mềm được giao. Vấn đề nhà cung cấp (A), yếu tố tổ chức (B) và vấn đề kỹ thuật (C) đều là rủi ro dự án. Riêng "phần mềm giao ra dễ phát sinh lỗi" (D) mô tả chất lượng của chính sản phẩm nên là rủi ro SẢN PHẨM, không phải rủi ro dự án - đó là phương án cần chọn.

#114
ĐỘ CHÍNH XÁC
4 LỰA CHỌN
ATop-down integration
Bottom-up integrationĐÚNG
CNone of the others
DModule integration
Giải thích

Đá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.

#115
ĐỘ CHÍNH XÁC
4 LỰA CHỌN
Incorrect program behaviour due to a fault in the programĐÚNG
BBug found before product Release
CBug found after product Release
DBug found during Design phase
Giải thích

Đá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.

#116
ĐỘ CHÍNH XÁC
4 LỰA CHỌN
AComponent testing should be performed by development
BComponent testing is also known as isolation or module testing
CComponent testing should have completion criteria planned
Component testing does not involve regression testingĐÚNG
Giải thích

Đá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).

#117
ĐỘ CHÍNH XÁC
4 LỰA CHỌN
AThe documentation is poor, so it takes longer to find out what the software is doing.
BWages are rising
The fault has been built into more documentation, code, tests, etcĐÚNG
DNone of the others
Giải thích

Đáp án đúng: C. Chi phí sửa một lỗi tăng theo cấp số nhân khi lỗi được phát hiện muộn vì lỗi đó đã bị "xây" vào ngày càng nhiều sản phẩm trung gian: tài liệu thiết kế, mã nguồn, ca kiểm thử, dữ liệu kiểm thử và cả những phần đã dựa trên nó. Sửa lỗi lúc này kéo theo sửa toàn bộ chuỗi sản phẩm ấy rồi kiểm thử hồi quy lại. Phương án A và B nêu những nguyên nhân ngoại vi (tài liệu kém, lương tăng) chỉ có tác động thứ yếu; phương án D bị loại vì C đã nêu đúng nguyên nhân cốt lõi.

#118
ĐỘ CHÍNH XÁC
4 LỰA CHỌN
AValidation Testing
BIntegration Testing
CUser Acceptance Testing
System TestingĐÚNG
Giải thích

Đá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 đề.

#119
ĐỘ CHÍNH XÁC
4 LỰA CHỌN
ASystem integration
BFunctional testing
Non-functional testing.ĐÚNG
DRequirements testing
Giải thích

Đá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.

#120
ĐỘ CHÍNH XÁC
4 LỰA CHỌN
AIs unlikely to be completed on schedule
Is unlikely to cause a failureĐÚNG
CIs likely to be fault-free
DIs likely to be liked by the users
Giải thích

Đá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.