Tất cả câu hỏi

Đáp án đúng: "Big-bang". Kiểm thử tích hợp tăng dần (incremental integration testing) ghép từng thành phần hoặc từng nhóm nhỏ vào rồi kiểm thử ngay, nên khi lỗi xuất hiện dễ khoanh vùng nguyên nhân. Tích hợp vụ nổ lớn (big-bang integration) thì ngược lại: ghép tất cả thành phần một lần rồi mới kiểm thử cả khối, nên không phải cách tiếp cận tăng dần và khó định vị lỗi. "Top down" (từ trên xuống) là cách tăng dần, bắt đầu từ mô-đun điều khiển cấp cao, dùng stub thay cho mô-đun cấp dưới chưa có. "Bottom up" (từ dưới lên) cũng tăng dần, bắt đầu từ mô-đun cấp thấp, dùng driver để gọi chúng. "Functional incrementation." là tích hợp tăng dần theo từng chức năng hay tính năng, ghép những thành phần cần cho một chức năng rồi mới chuyển sang chức năng kế tiếp, nên cũng thuộc nhóm tăng dần.

Đáp án đúng: "Number of independent paths in the basis set of a program". Độ phức tạp vòng (cyclomatic complexity) của McCabe đo cấu trúc luồng điều khiển: V(G) = E − N + 2, với E là số cạnh và N là số nút của đồ thị luồng điều khiển; ý nghĩa của con số này là số đường đi độc lập tuyến tính trong tập cơ sở (basis set), tức số ca kiểm thử tối thiểu cho kiểm thử đường cơ sở (basis path testing). "Number of binary decisions + 1" là một công thức tính nhanh V(G) cho chương trình chỉ có quyết định hai nhánh, tức là cách tính chứ không phải đại lượng mà độ phức tạp vòng biểu thị. "Number bound for the number of tests that must be conducted to ensure that all statements" mô tả cận trên của số ca kiểm thử để mọi câu lệnh được chạy ít nhất một lần; độ phức tạp vòng đúng là cung cấp cận trên đó, nhưng đó là hệ quả, còn định nghĩa cốt lõi là số đường độc lập. "Number of branches and decisions" sai vì đó chỉ là số đếm thô các nhánh và quyết định, không tương ứng với số đường độc lập.

Đáp án đúng: "i,ii,iii are true and iv is false.". ISTQB liệt kê các yếu tố bối cảnh khi chọn cách tiếp cận kiểm thử gồm: rủi ro thất bại của dự án, mối nguy với sản phẩm và rủi ro sản phẩm hỏng gây hại cho con người (mục i), kỹ năng và kinh nghiệm của con người với kỹ thuật, công cụ, phương pháp đề xuất (mục ii), mục tiêu của nỗ lực kiểm thử và sứ mệnh của nhóm kiểm thử (mục iii), cùng quy định pháp lý và bản chất sản phẩm; quy mô nhóm kiểm thử (mục iv) không nằm trong danh sách này, nó ảnh hưởng tới lịch và phân bổ công việc chứ không quyết định cách tiếp cận. "i,ii,iii,iv are true" sai vì coi cả quy mô nhóm là yếu tố chọn cách tiếp cận. "ii,iii,iv are true and i is false." sai vì loại rủi ro, yếu tố quan trọng nhất của kiểm thử dựa trên rủi ro. "i,iv are true and ii, iii are false." sai vì loại kỹ năng và mục tiêu kiểm thử, hai yếu tố được nêu rõ.

Đáp án đúng: "Poor software and poor testing". Lỗi mà người dùng gặp phải là lỗi đã lọt qua toàn bộ quá trình phát triển và kiểm thử: nó tồn tại vì phần mềm được làm ra có khuyết tật (yêu cầu, thiết kế, mã chưa tốt), và nó lọt tới tay người dùng vì kiểm thử chưa đủ tốt để phát hiện, do thiết kế ca kiểm thử yếu, độ phủ thấp hay ưu tiên sai rủi ro. Hai yếu tố này cùng đúng nên phương án gộp cả hai là đầy đủ nhất. "Insufficient time for testing" có thể là một nguyên nhân góp phần, nhưng thiếu thời gian chỉ dẫn tới kiểm thử kém, và dù đủ thời gian mà phần mềm kém, kiểm thử kém thì lỗi vẫn lọt, nên nó chỉ là một khía cạnh hẹp. "Bad luck" không phải lời giải thích kỹ thuật; lỗi là hệ quả của sai sót con người trong phát triển và kiểm thử, có thể phòng ngừa và phát hiện bằng quy trình tốt.

Đáp án đúng: "Requirements management tools". Theo phân loại công cụ trong ISTQB Foundation, công cụ quản lý yêu cầu (requirements management tool) lưu trữ các phát biểu yêu cầu cùng thuộc tính của chúng, kiểm tra tính nhất quán và yêu cầu chưa định nghĩa, cho phép xếp mức ưu tiên và lập truy vết (traceability) từ từng ca kiểm thử tới yêu cầu, chức năng, tính năng; đó đúng là bộ chức năng câu hỏi mô tả. "Incident management tools" (công cụ quản lý sự cố) lưu và theo dõi báo cáo lỗi, sự cố cùng trạng thái xử lý, không quản lý yêu cầu. "Configuration management tools" (công cụ quản lý cấu hình) lưu phiên bản và bản dựng của phần mềm, testware, giúp truy vết phiên bản chứ không kiểm tra tính nhất quán hay ưu tiên yêu cầu. "None of the others" sai vì đã có một loại công cụ khớp đúng mô tả.

Đáp án đúng: "Sign the system off for release". Quyết định phát hành thuộc về các bên liên quan như quản lý dự án, chủ sản phẩm hay khách hàng; trưởng nhóm kiểm thử (test manager) cung cấp thông tin về chất lượng và rủi ro còn lại để họ quyết định, chứ không tự ký cho hệ thống phát hành, vì như thế vừa vượt thẩm quyền vừa làm mất tính độc lập của kiểm thử. "Report on deviations from the project plan" là việc đúng vai trò, thuộc hoạt động giám sát và kiểm soát kiểm thử. "Re-allocate resource to meet original plans" cũng là hành động kiểm soát kiểm thử (test control) mà trưởng nhóm được phép làm khi tiến độ lệch. "Rise incidents on faults that they have found" là trách nhiệm của bất kỳ ai phát hiện khiếm khuyết. "Provide information for risk analysis and quality improvement" là đóng góp quan trọng của kiểm thử cho quản lý rủi ro và cải tiến quy trình.

Đáp án đúng: "Regression Testing". Định nghĩa ISTQB của kiểm thử hồi quy (regression testing) là kiểm thử lặp lại một chương trình đã được kiểm thử, sau khi sửa đổi, nhằm phát hiện lỗi mới bị đưa vào hoặc bị làm lộ ra do thay đổi, kể cả thay đổi ở thành phần phần mềm khác có liên quan hay không liên quan; câu hỏi chép gần như nguyên văn định nghĩa này. Điểm mấu chốt là nó tìm tác dụng phụ ngoài chủ đích của thay đổi. "Re Testing" và "Confirmation Testing" là cùng một khái niệm, kiểm thử xác nhận: chạy lại đúng ca kiểm thử từng thất bại để xác nhận lỗi đó đã được sửa, chứ không đi tìm lỗi mới nảy sinh ở chỗ khác. "Negative Testing" (kiểm thử phủ định) là dùng dữ liệu không hợp lệ hoặc thao tác sai để xem hệ thống xử lý lỗi có đúng không, không gắn với việc phần mềm vừa bị sửa đổi.

Đáp án đúng: "A failure". Trong chuỗi thuật ngữ của ISTQB, con người phạm sai lầm (error hay mistake), sai lầm đó tạo ra khiếm khuyết nằm trong mã hoặc tài liệu (defect, fault, bug), và khi đoạn mã khiếm khuyết được thực thi thì hệ thống có thể lệch khỏi hành vi mong đợi, sự lệch quan sát được ấy là thất bại (failure); câu hỏi nhấn vào thứ người dùng cuối nhìn thấy nên đó là failure. "An error" là hành động sai của con người, xảy ra trong đầu người viết chứ không phải thứ người dùng thấy. "A mistake" là từ đồng nghĩa với error nên bị loại cùng lý do. "A fault" là khiếm khuyết nằm tĩnh trong mã, có thể tồn tại mà chưa bao giờ lộ ra. "A defect" cũng là khiếm khuyết trong sản phẩm, nguyên nhân của thất bại chứ không phải biểu hiện bên ngoài.

Đáp án đúng: "Scribe". Trong review chính thức theo ISTQB, người ghi chép (scribe hay recorder) có nhiệm vụ ghi lại mọi khuyết tật, vấn đề và điểm còn bỏ ngỏ được nêu ra trong buổi họp review, để sau đó tác giả có danh sách mà sửa và người điều phối theo dõi việc khắc phục. "Moderator" là người điều phối, dẫn dắt buổi review, lập kế hoạch, điều hành cuộc họp, giữ đúng mục tiêu và quyết định có cần theo dõi tiếp hay không, không phải người ghi biên bản. "Author" là tác giả sản phẩm được review, chịu trách nhiệm sửa các khuyết tật được ghi lại ở bước làm lại (rework). "Manager" là người quản lý, quyết định có tiến hành review, phân bổ thời gian, nguồn lực và đánh giá hiệu quả của review, thường không trực tiếp ghi chép trong buổi họp.

Đáp án đúng: "Verification activities should not involve testers (reviews, inspections etc)". Phát biểu này sai vì ISTQB Foundation khuyến khích người kiểm thử tham gia hoạt động kiểm chứng (verification) như rà soát và thanh tra ngay từ sớm: họ góp góc nhìn về khả năng kiểm thử, phát hiện yêu cầu mơ hồ và học sản phẩm để thiết kế kiểm thử tốt hơn, đúng nguyên tắc kiểm thử sớm. Câu hỏi tìm phát biểu không đúng nên đây là đáp án. "Performance testing can be done during unit testing as well as during the testing of whole system" là đúng, vì kiểm thử hiệu năng có thể áp ở cấp đơn vị, ví dụ đo thời gian một thuật toán, lẫn cấp hệ thống. "The acceptance test does not necessarily include a regression test" cũng đúng, vì mục tiêu kiểm thử chấp nhận là xây dựng niềm tin và xác nhận sẵn sàng triển khai, hồi quy không bắt buộc phải nằm trong đó. "Test environments should be as similar to production environments as possible" đúng, vì môi trường càng giống thực tế càng giảm rủi ro lỗi chỉ lộ ra khi vận hành.

Đáp án đúng: "i , ii,iii,iv is correct". Theo ISTQB Foundation, công cụ phân tích tĩnh (static analysis tool) đọc mã mà không chạy chương trình và phát hiện được nhiều loại lỗi: biến được khai báo mà không bao giờ dùng (mục i), lỗ hổng bảo mật như tràn bộ đệm hay đầu vào không được kiểm tra (mục ii), vi phạm chuẩn lập trình (programming standard violations, mục iii), và hàm, thủ tục không bao giờ được gọi tức mã chết (mục iv). Cả bốn đều là ví dụ chuẩn trong danh sách lỗi mà phân tích tĩnh phát hiện. "iii ,is correct I,ii,iv are incorrect." sai vì chỉ nhận vi phạm chuẩn mà bỏ ba loại lỗi kia, trong khi biến không dùng hay hàm không được gọi là kết quả điển hình của phân tích luồng dữ liệu và luồng điều khiển. "i ,ii, iii and iv are incorrect" phủ nhận toàn bộ, trái với chức năng cơ bản của công cụ. "iv, ii is correct" bỏ sót biến không dùng và vi phạm chuẩn.

Đáp án đúng: "Driver". Khi kiểm thử một thành phần riêng lẻ mà mô-đun gọi nó chưa có, lập trình viên viết một driver (trình điều khiển): đoạn mã đứng ở vị trí bên gọi, gọi hàm cần kiểm thử, truyền dữ liệu kiểm thử vào và nhận kết quả để so sánh với kết quả mong đợi; driver được dùng nhiều trong tích hợp từ dưới lên. "Stub" là chiều ngược lại: nó thay thế cho thành phần mà hàm đang kiểm thử gọi tới, chỉ trả về giá trị giả định đơn giản, dùng nhiều trong tích hợp từ trên xuống. "Proxy" là mẫu thiết kế hay thành phần trung gian chuyển tiếp lời gọi tới một đối tượng khác, không phải thuật ngữ kiểm thử chỉ đoạn mã gọi thành phần đang kiểm thử. "None of the others" sai vì driver chính là thứ câu hỏi mô tả.

Đáp án đúng: "ii & iii are true, i, iv & v are false.". Lập kế hoạch kiểm thử (test planning) xác định phạm vi, rủi ro, mục tiêu, cách tiếp cận tổng thể, lịch, tiêu chí thoát và phân bổ nguồn lực, nên mục ii (xác định cách tiếp cận tổng thể) và mục iii (phân công nguồn lực) thuộc kế hoạch. Viết điều kiện kiểm thử và phát triển ca kiểm thử thuộc pha phân tích và thiết kế (rồi hoàn thiện ở pha triển khai), còn dựng môi trường kiểm thử thuộc pha triển khai và thực thi, nên mục i, iv, v không thuộc kế hoạch. "i, ii & iv are true, iii & v are false." sai vì coi phát triển ca kiểm thử và dựng môi trường là lập kế hoạch, lại loại việc phân công nguồn lực. "iv & v are true, i, ii & iii are false." đảo ngược hoàn toàn, loại cả hai hoạt động lập kế hoạch thật. "i, ii & iii are true iv & v are false." đúng hai mục nhưng gộp nhầm việc phát triển ca kiểm thử.

Đáp án đúng: "Viability". Chất lượng phần mềm được mô tả bằng các thuộc tính chất lượng trong các mô hình như McCall hay ISO/IEC 9126 (nay là ISO/IEC 25010), chẳng hạn tính đúng đắn, tính dùng được, tính tin cậy, tính bảo trì, tính tái sử dụng, tính khả chuyển. Viability (tính khả thi, khả năng tồn tại về mặt kinh doanh) là khái niệm đánh giá dự án hay sản phẩm có đáng đầu tư, có sinh lời hay không, không phải một thuộc tính chất lượng của bản thân phần mềm. "Correctness" là tính đúng đắn, mức phần mềm thoả đặc tả và đáp ứng mục tiêu người dùng, là một yếu tố chất lượng cốt lõi. "Usability" là tính dùng được, phần mềm dễ học, dễ thao tác đến đâu, thuộc nhóm đặc tính chất lượng trong ISO 9126. "Reusability" là tính tái sử dụng, mức thành phần có thể dùng lại ở hệ thống khác, có mặt trong nhóm yếu tố chất lượng của McCall.

Đáp án đúng: "i,ii,iii are correct and iv is incorrect". Theo ISTQB Foundation, theo dõi tiến độ kiểm thử (test progress monitoring) dùng các số đo như tỉ lệ công việc chuẩn bị ca kiểm thử, tỉ lệ công việc chuẩn bị môi trường kiểm thử, tỉ lệ ca kiểm thử đã thực thi (đạt, không đạt, chưa chạy), thông tin về lỗi như mật độ lỗi (defect density), số lỗi tìm thấy và đã sửa, độ phủ, mốc thời gian và chi phí. Mục i, ii, iii đều thuộc danh sách đó. Mục iv, quy mô đội kiểm thử và kỹ năng của kỹ sư, là đầu vào của lập kế hoạch và ước lượng nhân lực, không cho biết công việc đã tiến tới đâu. "iv is correct and i,ii,iii are incorrect" đảo ngược hoàn toàn. "i,ii are correct and iii,iv are incorrect" bỏ sót thông tin lỗi, vốn là chỉ số tiến độ quan trọng. "i,iv are correct and ii , iii are incorrect" nhận nhầm mục iv và bỏ sót tiến độ chuẩn bị môi trường cùng thông tin lỗi.

Đáp án đúng: "ii. and iv. are more for developers.". Theo cách ISTQB phân loại công cụ, công cụ đo độ phủ (coverage measurement) và công cụ phân tích động (dynamic analysis, ví dụ dò rò rỉ bộ nhớ, con trỏ treo) gắn chặt với mã nguồn và thường do lập trình viên dùng khi kiểm thử thành phần, nên mục ii và iv là nhóm thiên về lập trình viên. Công cụ kiểm thử hiệu năng (mục i) chủ yếu do kiểm thử viên chuyên trách dùng ở cấp hệ thống, bộ so sánh kết quả (test comparator, mục iii) là công cụ hỗ trợ thực thi kiểm thử chung, còn quản lý sự cố (mục v) thuộc nhóm quản lý kiểm thử. "i, iii. and iv. are more for developers." sai vì gộp cả công cụ hiệu năng và bộ so sánh. "ii, iii. and iv. are more for developers." sai vì thêm bộ so sánh vốn không riêng cho lập trình viên. "ii. and iii. are more for developers." sai vì bỏ mất phân tích động và đưa bộ so sánh vào.

Đáp án đúng: "Eliminate some of the requirements that have not yet been implemented.". Dự án bị ràng buộc cả ngày giao lẫn chuẩn chất lượng, nên trong tam giác phạm vi, thời gian, chất lượng thì chỉ còn phạm vi là được phép điều chỉnh; cắt bớt các yêu cầu chưa hiện thực (thường là yêu cầu ưu tiên thấp, thoả thuận lại với khách hàng) là cách khả thi để kịp hạn mà không hạ chất lượng. "Add more engineers to the project to make up for lost work." vấp phải định luật Brooks: thêm người vào dự án đang trễ còn làm nó trễ hơn, vì người mới cần thời gian làm quen và chi phí giao tiếp tăng. "Ask the current developers to work overtime until the lost work is recovered." không bền: bù sáu tuần trong bốn tháng đòi tăng ca kéo dài, gây mệt mỏi và sinh thêm lỗi, trái với yêu cầu giữ chất lượng. "Hire more software quality assurance personnel." không tăng năng lực phát triển, nên không lấy lại được khối lượng mã còn thiếu.

Đáp án đúng: "Procedure". Trong quản lý chất lượng, thủ tục (procedure) là chuỗi bước cụ thể, làm lần lượt từng bước một, mô tả cách thực hiện một công việc để bảo đảm các chuẩn (standards) được đáp ứng; chuẩn nói cái gì phải đạt, thủ tục nói làm thế nào để đạt. "SDLC" là vòng đời phát triển phần mềm, mô tả các giai đoạn phát triển ở mức tổng thể chứ không phải hướng dẫn từng bước để tuân thủ một chuẩn. "Project Plan" (kế hoạch dự án) xác định phạm vi, lịch, nguồn lực và rủi ro của một dự án, không phải phương pháp từng bước lặp lại được. "Policy" (chính sách) là tuyên bố định hướng ở cấp quản lý, nói tổ chức cam kết điều gì và vì sao; chính sách được hiện thực hoá bằng chuẩn và thủ tục chứ bản thân nó không gồm các bước thực hiện.

Đáp án đúng: "1 -b, 2-c, 3-a". Ước lượng kiểm thử (test estimation) là dự tính công sức, thời gian cần cho các hoạt động kiểm thử, nên 1 ghép với b; giám sát kiểm thử (test monitoring) là thu thập và theo dõi các số đo tiến độ như số ca đã chạy, số lỗi tìm thấy, độ phủ đạt được, nên 3 ghép với a; điều khiển kiểm thử (test control) là hành động khắc phục khi giám sát thấy lệch kế hoạch, chẳng hạn phân bổ lại nguồn lực hay đổi thứ tự ưu tiên, nên 2 ghép với c. "1 -b, 2-a, 3-c" đảo vai giám sát và điều khiển: coi điều khiển là đo đếm còn giám sát là phân bổ lại nguồn lực. "1 -c, 2-a, 3-b" sai cả ba cặp, gán việc phân bổ lại nguồn lực cho ước lượng và công sức cho giám sát. "1 -a, 2-b, 3-c" cũng sai cả ba vì coi ước lượng là đo tiến độ, trong khi ước lượng diễn ra từ lúc lập kế hoạch, khi chưa có tiến độ nào để đo.