Câu hỏi: SWT301 Software Testing – Bộ ôn tập thi lại số 4

Đáp án đúng: "False". Phát biểu rằng kiểm thử kỹ lưỡng có thể loại bỏ mọi lỗi khỏi chương trình trước khi giao cho khách hàng là sai, vì nó trái với hai nguyên tắc kiểm thử trong ISTQB Foundation. Thứ nhất, kiểm thử cho thấy sự hiện diện của lỗi chứ không chứng minh được không còn lỗi (testing shows presence of defects): dù không tìm thấy lỗi nào, ta cũng không thể kết luận phần mềm đúng hoàn toàn. Thứ hai, kiểm thử vét cạn là bất khả thi (exhaustive testing is impossible): số tổ hợp đầu vào, trạng thái và đường đi quá lớn để thử hết, nên luôn phải chọn mẫu theo rủi ro và ưu tiên. Kiểm thử làm giảm xác suất lỗi còn sót và tăng niềm tin vào chất lượng, nhưng không bảo đảm loại bỏ tất cả. Vì vậy "True" sai: nó đòi hỏi một điều kiểm thử không thể đạt được dù làm kỹ tới đâu.

Đáp án đúng: "None of the others". Theo mô hình quản lý lỗi của QAI, quy trình quản lý lỗi (defect management process) gồm các bước phòng ngừa lỗi (defect prevention), thiết lập đường cơ sở cho sản phẩm bàn giao (deliverable baselining), phát hiện lỗi (defect discovery), giải quyết lỗi (defect resolution), cải tiến quy trình (process improvement) và báo cáo quản lý (management reporting); cả ba mục được nêu đều nằm trong quy trình nên không có mục nào bị loại. Chỗ dễ tranh cãi là "Deliverable base-lining": nhiều tài liệu ôn tập chọn nó vì nghe giống việc quản lý cấu hình, nhưng trong mô hình này nó là một bước chính thức, xác định thời điểm một sản phẩm được coi là hoàn tất để từ đó mọi sai lệch mới tính là lỗi. "Defect prevention" thuộc quy trình vì là bước đầu, giảm rủi ro lỗi xuất hiện. "Management reporting" thuộc quy trình vì là bước cuối, đưa số liệu lỗi lên quản lý để ra quyết định.

Đáp án đúng: "All of the others". Kiểm thử vòng lặp (loop testing) là kỹ thuật hộp trắng tập trung vào tính đúng đắn của cấu trúc lặp, với cách thiết kế riêng cho từng loại vòng lặp, nên áp dụng được cho tất cả các loại được nêu. "Simple Loops" là vòng lặp đơn, kiểm thử bằng cách bỏ qua vòng, chạy một lần, hai lần, nhiều lần và quanh số lần tối đa. "Nested Loops" là vòng lặp lồng nhau, kiểm thử từ vòng trong cùng ra ngoài trong khi giữ các vòng ngoài ở giá trị nhỏ nhất. "Concatenated Loops" là các vòng lặp nối tiếp, kiểm thử như vòng đơn nếu chúng độc lập, hoặc như vòng lồng nếu vòng sau phụ thuộc vào vòng trước. Mỗi loại riêng lẻ đều đúng nhưng chọn một cái là chưa đủ, vì kỹ thuật này bao trùm cả ba.

Đáp án đúng gồm hai ý: "Static analysis need not be performed before imperative code is executed" và "Static analysis can find faults that are hard to find with dynamic testing.". Phân tích tĩnh (static analysis) là việc công cụ khảo sát mã nguồn hoặc mô hình mà không chạy chương trình; vì không phụ thuộc vào việc chạy, nó có thể làm trước, song song hay sau khi mã được thực thi chứ không bắt buộc phải xong trước, và nó tìm được những lỗi mà kiểm thử động khó chạm tới như biến dùng trước khi gán giá trị, mã không bao giờ chạy tới, vi phạm chuẩn lập trình, lỗ hổng bảo mật hay độ phức tạp quá cao. "Compiling code is not a form of static analysis" sai vì trình biên dịch chính là một dạng phân tích tĩnh: nó kiểm tra cú pháp, kiểu dữ liệu, biến chưa khai báo mà không chạy chương trình. Phát biểu "Extensive statistical analysis will not be needed if white- Box testing is to be performed." sai vì kiểm thử hộp trắng là kiểm thử động, chạy mã để đo độ phủ, nên không thay được việc phân tích mã khi không chạy; hai cách bổ sung cho nhau chứ không loại trừ nhau.

Đáp án đúng: "Non-functional testing.". Bảo mật, hiệu năng, độ tin cậy và khả năng sử dụng là các đặc tính chất lượng mô tả hệ thống hoạt động tốt tới mức nào chứ không phải hệ thống làm gì; kiểm thử phi chức năng (non-functional testing) là loại kiểm thử đánh giá chính các đặc tính đó, ví dụ hệ thống ngân hàng trực tuyến phải chịu được nhiều người đăng nhập cùng lúc và chống được truy cập trái phép. "Functional testing" kiểm tra các chức năng như chuyển khoản, tra số dư có cho kết quả đúng không, không đo thuộc tính chất lượng. "System integration" là kiểm thử tích hợp hệ thống, xét tương tác với hệ thống bên ngoài như cổng thanh toán, là một cấp kiểm thử chứ không phải loại kiểm thử hướng vào thuộc tính chất lượng. "Requirements testing" là kiểm thử dựa trên yêu cầu, một cách lấy cơ sở kiểm thử, không gắn riêng với nhóm thuộc tính nào.

Đáp án đúng: "Define when to stop testing". Tiêu chí kết thúc (exit criteria) là tập điều kiện thống nhất với bên liên quan, như độ phủ phải đạt, số lỗi nghiêm trọng còn mở, mức rủi ro còn lại, để quyết định một hoạt động hay một cấp kiểm thử được coi là xong; mục đích của nó là xác định khi nào dừng kiểm thử. "End of test level" chỉ mô tả thời điểm kết thúc một cấp, tức kết quả khi tiêu chí đã được thỏa, không phải mục đích của tiêu chí. "When a set of tests has achieved a specific pre condition" lẫn với tiêu chí đầu vào (entry criteria), vốn là điều kiện tiên quyết để bắt đầu một hoạt động chứ không phải để kết thúc. "All of the others" sai vì hai mô tả kia không phải mục đích của tiêu chí kết thúc.

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

Đáp án đúng: "Dynamic analysis tool". Theo ISTQB Foundation, công cụ phân tích động (dynamic analysis tool) theo dõi chương trình khi đang chạy để phát hiện lỗi chỉ lộ ra lúc thực thi, như rò rỉ bộ nhớ (memory leak), con trỏ chưa gán hoặc trỏ sai (unassigned pointers) và lỗi số học con trỏ. Rò rỉ bộ nhớ phụ thuộc đường đi thực tế và vòng đời cấp phát, nên phải quan sát lúc chạy mới đánh dấu chính xác được. "Static Analysis tool." phân tích mã mà không chạy nó, tìm được biến chưa định nghĩa, mã chết, vi phạm chuẩn lập trình, nhưng không bắt được rò rỉ bộ nhớ một cách tin cậy. "Maintenance tool." không phải nhóm công cụ kiểm thử nào trong phân loại của ISTQB. "Configuration tool." thường chỉ công cụ quản lý cấu hình, dùng để lưu vết phiên bản và bản dựng của phần mềm, testware, chứ không giám sát bộ nhớ khi chạy.

Đáp án đúng: "Analyze your needs and requirements". Theo ISTQB, đưa công cụ kiểm thử vào tổ chức bắt đầu bằng việc đánh giá mức trưởng thành của tổ chức và phân tích nhu cầu, xác định yêu cầu rõ ràng mà công cụ phải đáp ứng; chỉ khi biết mình cần gì mới đánh giá nhà cung cấp, làm thử nghiệm khái niệm (proof of concept) và dự trù chi phí. "Attend a tool exhibition" là cách tìm hiểu thị trường, hữu ích ở bước khảo sát sau khi đã có yêu cầu, nếu đi trước dễ bị cuốn theo tính năng hào nhoáng. "Invite a vendor to give a demo" thuộc bước đánh giá nhà cung cấp, chưa có yêu cầu thì không biết xem demo để so với cái gì. "Find out what your budget would be for the tool" cần làm nhưng ngân sách phải dựa trên nhu cầu và lợi ích dự kiến. "Search the internet" cũng chỉ là khảo sát lựa chọn, không phải điểm xuất phát.

Đáp án đúng: "Reducing test time". Khi phương pháp phát triển tốt hơn (rà soát yêu cầu, thiết kế cẩn thận, kiểm thử đơn vị kỹ), phần mềm bàn giao cho các pha kiểm thử chứa ít khiếm khuyết hơn; ít khiếm khuyết nghĩa là ít thất bại (failure) phải điều tra, ít báo cáo sự cố, ít vòng sửa rồi kiểm thử xác nhận (confirmation testing) và kiểm thử hồi quy (regression testing), nên tổng thời gian các pha kiểm thử giảm. "No change" sai vì thời gian kiểm thử không chỉ là chạy bộ ca cố định mà còn gồm các vòng lặp do lỗi sinh ra, và phần này co lại khi chất lượng tăng. "Increasing test time" đi ngược quan hệ trên: chất lượng tốt hơn không tạo thêm việc kiểm thử. "Can’t say" sai vì quan hệ giữa chất lượng đầu vào và công sức kiểm thử là rõ ràng, đây chính là lý do kiểm thử sớm và phòng ngừa khiếm khuyết được khuyến khích trong ISTQB.

Đáp án đúng: "Supportability". Chuẩn ISO 9126 về chất lượng sản phẩm phần mềm định nghĩa sáu đặc tính chất lượng: chức năng (functionality), độ tin cậy (reliability), tính khả dụng (usability), hiệu suất (efficiency), khả năng bảo trì (maintainability) và tính khả chuyển (portability). Khả năng hỗ trợ (supportability) không có trong danh sách này; nó là chữ S trong mô hình FURPS của Hewlett-Packard, một cách phân loại khác. "Functionality" là đặc tính thứ nhất của ISO 9126, gồm tính phù hợp, độ chính xác, khả năng tương tác, bảo mật. "Usability" là đặc tính về mức dễ hiểu, dễ học, dễ vận hành. "Maintainability" là đặc tính về mức dễ phân tích, dễ thay đổi, ổn định và dễ kiểm thử của phần mềm. Ba đặc tính này đều thuộc chuẩn nên không phải đáp án.

Đáp án đúng: "Expected results.". Theo IEEE 829, kế hoạch kiểm thử (test plan) gồm các mục như định danh, hạng mục kiểm thử, tính năng sẽ kiểm và không kiểm, cách tiếp cận, tiêu chí đạt hay không đạt, tiêu chí tạm dừng và điều kiện tiếp tục, sản phẩm bàn giao, nhiệm vụ, nhu cầu môi trường, trách nhiệm, nhân sự và đào tạo, lịch, rủi ro, phê duyệt. Kết quả mong đợi của từng ca kiểm thử là chi tiết ở mức đặc tả ca kiểm thử (test case specification), không nằm trong kế hoạch. "Features to be tested." là mục bắt buộc của kế hoạch, xác định phạm vi kiểm thử. "Environmental needs." cũng là một mục của kế hoạch, mô tả phần cứng, phần mềm, công cụ cần có. "Suspension criteria." thuộc kế hoạch, quy định khi nào tạm dừng kiểm thử và điều kiện để tiếp tục.

Đáp án đúng: "Boo01k". Phân vùng tương đương (equivalence partitioning) chọn một giá trị đại diện cho mỗi lớp dữ liệu được hệ thống xử lý như nhau; với ô chỉ nhận giá trị chữ và số (alphanumeric), giá trị tiêu biểu cho lớp hợp lệ là chuỗi pha trộn cả chữ cái lẫn chữ số, và "Boo01k" chứa chữ B, o, k cùng chữ số 0 và 1 nên thể hiện đúng lớp này. "BOOK" chỉ gồm chữ in hoa, "Book" chỉ gồm chữ cái với chữ đầu viết hoa, "book" chỉ gồm chữ thường; hiểu rộng thì chuỗi toàn chữ cái vẫn có thể được ô chấp nhận, nhưng chúng không có chữ số nên không đại diện cho đặc trưng chữ và số mà câu hỏi muốn kiểm tra, chúng là đại diện cho lớp chỉ có chữ cái, khác với lớp chữ và số.

Đáp án đúng: "An inspection is led by a moderator and a walkthrough is led by the author.". Theo ISTQB, duyệt qua (walkthrough) do tác giả dẫn dắt, trình bày tài liệu cho đồng nghiệp để chia sẻ hiểu biết và nhận góp ý; thanh tra (inspection) là loại rà soát hình thức nhất, do người điều phối được đào tạo dẫn dắt, có chuẩn bị cá nhân, tiêu chí vào ra và theo dõi chính thức. "Both inspections and walkthroughs are led by the author." sai về phía thanh tra, vì tác giả không được làm người điều phối để giữ khách quan. "Both inspections and walkthroughs are led by a trained moderator." sai về phía duyệt qua, vốn do chính tác giả chủ trì. Phát biểu "The author is not present during inspections." sai vì tác giả vẫn có mặt trong thanh tra, chỉ không giữ vai trò dẫn dắt, và thường giải đáp câu hỏi, nhận danh sách lỗi để sửa.

Đáp án đúng: "Test Closure Activities". Theo quy trình kiểm thử cơ bản của ISTQB Foundation, hoạt động đóng kiểm thử (test closure activities) gồm kiểm tra sản phẩm bàn giao đã đủ chưa, đóng báo cáo sự cố, lập tài liệu chấp nhận hệ thống, hoàn thiện và lưu trữ testware, bàn giao testware cho bộ phận bảo trì (handover of testware), và rút kinh nghiệm cho các dự án sau. Bàn giao testware nằm đúng ở giai đoạn này vì chỉ diễn ra khi kiểm thử đã kết thúc. "Test Analysis and Design" là lúc rà soát cơ sở kiểm thử, xác định điều kiện kiểm thử và thiết kế ca kiểm thử. "Test Planning and control" là lúc xác định mục tiêu, phạm vi, cách tiếp cận và theo dõi tiến độ, điều chỉnh khi lệch kế hoạch. "Evaluating exit criteria and reporting" là lúc so kết quả thực thi với tiêu chí thoát và viết báo cáo tóm tắt, chưa phải lúc bàn giao.

Đáp án đúng: "s = 4 and 5, t = 3, u = 2, v = 1". Ghép theo đặc điểm của từng loại review trong ISTQB: inspection do moderator được đào tạo dẫn dắt và dùng tiêu chí đầu vào, đầu ra nên ứng với 4 và 5; peer review (review đồng cấp, như technical review) chỉ gồm người cùng cấp chuyên môn, không có quản lý tham gia nên ứng với 3; informal review (review không chính thức) thường không lập tài liệu nên ứng với 2; walkthrough do chính tác giả dẫn dắt nên ứng với 1. "s = 4, t = 3, u = 2 and 5, v = 1" sai vì gán tiêu chí đầu vào, đầu ra cho review không chính thức, vốn không có quy trình như vậy. "s = 1 and 5, t = 3, u = 2, v = 4" đảo người dẫn dắt: inspection không do tác giả dẫn, walkthrough không cần moderator được đào tạo. "s = 5, t = 4, u = 3, v = 1 and 2" sai vì gán moderator cho peer review và gán tính không tài liệu cho walkthrough. "s = 4 and 5, t = 1, u = 2, v = 3" sai vì cho peer review do tác giả dẫn và walkthrough là nơi không có quản lý.

Đáp án đúng: "Load Testing". Kiểm thử tải (load testing) là loại kiểm thử hiệu năng, đặt đối tượng dưới các mức tải công việc khác nhau, chẳng hạn số người dùng đồng thời hay số giao dịch tăng dần, để đo và đánh giá hành vi hiệu năng cũng như khả năng tiếp tục hoạt động đúng ở từng mức tải. Mô tả trong câu hỏi, thay đổi workload để đo hiệu năng và khả năng hoạt động, khớp đúng định nghĩa này. "Integration Testing" kiểm giao diện và tương tác giữa các thành phần hay hệ thống được ghép lại, không xoay quanh mức tải. "System Testing" là cấp kiểm thử trên toàn bộ hệ thống, có thể chứa kiểm thử tải nhưng là khái niệm rộng hơn, không chỉ riêng việc thay đổi tải. "Usability Testing" đánh giá mức dễ học, dễ dùng đối với người dùng thật, không đo hành vi dưới tải.

Đáp án đúng: "Tool support.". Chi phí của rà soát (review) thường được tính gồm chính quá trình rà soát, tức thời gian lập kế hoạch, chuẩn bị riêng và họp; công phân tích các số đo thu được; và công cải tiến quy trình rút ra từ kết quả rà soát; hỗ trợ công cụ không được tính vào nhóm chi phí này vì rà soát có thể làm hoàn toàn bằng tài liệu và con người. "Review process itself" là khoản chi phí lớn nhất, chính là công sức của những người tham gia. "Metrics analysis" là chi phí vì thu thập và phân tích số đo như số khiếm khuyết, tốc độ rà soát cần thời gian. "Process improvement." dễ gây nhầm vì nó thường được xem là lợi ích của rà soát, nhưng để hiện thực hoá cải tiến quy trình người ta phải bỏ công phân tích nguyên nhân và thay đổi cách làm sau buổi rà soát, nên nó cũng được tính là một khoản chi phí.

Đáp án đúng: "Error guessing". Đoán lỗi (error guessing) là kỹ thuật kiểm thử động dựa trên kinh nghiệm: người kiểm thử dự đoán chỗ phần mềm hay sai rồi thiết kế ca kiểm thử để chạy chương trình nhắm vào chỗ đó, nên nó không phải kỹ thuật tĩnh. Kiểm thử tĩnh (static testing) đánh giá sản phẩm mà không thực thi mã, gồm rà soát và phân tích tĩnh. "Walkthrough" là duyệt qua do tác giả dẫn dắt, một loại rà soát nên là kỹ thuật tĩnh. "Inspections" là thanh tra, loại rà soát chính thức nhất, cũng là kỹ thuật tĩnh. "Data flow analysis" là phân tích luồng dữ liệu, thường do công cụ phân tích tĩnh thực hiện trên mã nguồn để tìm biến dùng trước khi gán hay gán mà không dùng, không cần chạy chương trình nên cũng thuộc nhóm tĩnh.

Đáp án đúng: "Selecting the personnel, allocating roles.". Quy trình rà soát hình thức theo ISTQB gồm lập kế hoạch, khởi động (kick-off), chuẩn bị cá nhân, họp rà soát, làm lại (rework) và theo dõi (follow-up); bước lập kế hoạch định nghĩa tiêu chí rà soát, chọn người tham gia, phân vai, xác định tiêu chí vào ra và kiểm tra tiêu chí vào. "Explaining the objectives" là việc của buổi khởi động, khi người điều phối phát tài liệu, giải thích mục tiêu, quy trình và tài liệu cho người tham gia. "Individual Meeting preparations" là bước chuẩn bị cá nhân, mỗi người rà soát tự đọc tài liệu và ghi lỗi tiềm năng trước cuộc họp. "Follow up" là bước cuối, khi người điều phối kiểm tra các lỗi đã được sửa và tiêu chí ra đã đạt.