Câu hỏi: SWT301 Software Testing – Bộ ôn tập cuối kỳ số 4

Đáp án đúng: "State-Transition". Kiểm thử phi chức năng (non-functional testing) đánh giá hệ thống hoạt động tốt tới mức nào theo các đặc tính chất lượng, còn chuyển trạng thái (state transition testing) là một kỹ thuật thiết kế ca kiểm thử hộp đen: mô hình hóa các trạng thái, sự kiện và chuyển tiếp giữa chúng để kiểm tra hệ thống có làm đúng chức năng hay không, nên nó không phải một loại kiểm thử phi chức năng. "Usability" là kiểm thử khả năng sử dụng, đo mức dễ học, dễ thao tác, một loại phi chức năng điển hình. "Performance" là kiểm thử hiệu năng, đo thời gian phản hồi và thông lượng dưới tải, cũng là phi chức năng. "Security" là kiểm thử bảo mật, kiểm tra khả năng chống truy cập trái phép; đề cương ISTQB cũ dựa trên ISO 9126 từng xếp bảo mật vào nhóm chức năng, nhưng theo ISO 25010 và đề cương hiện hành bảo mật là một đặc tính chất lượng phi chức năng, nên nó vẫn thuộc nhóm được hỏi.

Đá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: "Defects and issues are identified and corrected". Câu hỏi tìm quy tắc không nên tuân theo. Trong review, nhiệm vụ của buổi họp là phát hiện và ghi nhận khuyết tật, vấn đề chứ không sửa chúng ngay tại chỗ; việc sửa thuộc bước làm lại (rework) do tác giả thực hiện sau buổi họp, nếu vừa tìm vừa sửa thì cuộc họp sa vào bàn giải pháp và mất trọng tâm. Các phát biểu kia đều là quy tắc đúng nên không được chọn. "The product is reviewed not the producer" là nguyên tắc cốt lõi: đánh giá sản phẩm chứ không phán xét con người, giúp tác giả không phòng thủ. "All members of the reviewing team are responsible for the result of the review" đúng vì chất lượng review là trách nhiệm chung của cả nhóm chứ không riêng tác giả hay moderator. "Each review has a clear predefined objective" đúng vì mục tiêu rõ ràng định trước là một yếu tố thành công của review theo ISTQB.

Đá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: "Reporting discrepancies as incidents.". Thực hiện và thực thi kiểm thử (test implementation and execution) là giai đoạn hoàn thiện thủ tục kiểm thử, chạy ca kiểm thử, ghi nhật ký, so sánh kết quả thực tế với kết quả mong đợi, và khi có sai khác thì báo cáo thành sự cố (incident) để phân tích nguyên nhân; đó là nhiệm vụ chính của giai đoạn này theo quy trình kiểm thử cơ bản của ISTQB. "Measuring and analyzing results." thuộc lập kế hoạch và điều khiển kiểm thử, nơi người quản lý đo tiến độ và phân tích kết quả để điều chỉnh kế hoạch. "Identifying test conditions or test requirements." thuộc phân tích và thiết kế kiểm thử, diễn ra trước khi có ca kiểm thử để chạy. "Assessing if more tests are needed." thuộc giai đoạn đánh giá tiêu chí kết thúc và báo cáo, khi đối chiếu kết quả với tiêu chí để quyết định có cần kiểm thử thêm không.

Đá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: "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: "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: "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: "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: "Performance testing". Kiểm thử phi chức năng (non-functional testing) kiểm tra hệ thống hoạt động tốt đến mức nào, tức các đặc tính chất lượng như hiệu năng, tải, khả năng chịu áp lực, tính dùng được, độ tin cậy, bảo mật, chứ không phải hệ thống làm được gì. Kiểm thử hiệu năng đo thời gian phản hồi, thông lượng, mức dùng tài nguyên nên là ví dụ điển hình của loại này. "Unit testing" là một cấp kiểm thử (kiểm thử thành phần), có thể chứa cả kiểm thử chức năng lẫn phi chức năng, bản thân nó không phải một loại kiểm thử phi chức năng. "Regression testing" là kiểm thử liên quan đến thay đổi, chạy lại ca cũ sau khi sửa đổi để phát hiện lỗi mới phát sinh, không gắn với đặc tính chất lượng nào. "Sanity testing" là phép kiểm nhanh các chức năng chính xem bản dựng có đủ ổn định để kiểm sâu hơn, mang tính chức năng.

Đáp án đúng: "Technical Review". Theo ISTQB, rà soát kỹ thuật (technical review) là quá trình được ghi lại, tập trung đạt đồng thuận và tìm khiếm khuyết, có sự tham gia của đồng nghiệp và chuyên gia kỹ thuật, và có thể tiến hành như rà soát đồng cấp (peer review) không có quản lý tham gia; vì thế peer review thường được gọi đồng nghĩa với technical review. "Inspection" là thanh tra, loại rà soát chính thức nhất do người điều phối được đào tạo dẫn dắt, có vai trò định sẵn, tiêu chí vào ra và số đo; nó cũng có đồng nghiệp tham gia nhưng có tên gọi riêng. "Walkthrough" là duyệt qua do chính tác giả dẫn dắt nhằm chia sẻ hiểu biết, không phải tên khác của peer review. "Formal Review" là thuật ngữ chung chỉ mọi rà soát có quy trình chính thức, bao trùm nhiều loại chứ không trùng với peer review.

Đáp án đúng: "User requirements.". Công cụ ghi và phát lại (capture and replay) ghi các thao tác trên giao diện như nhấp chuột, gõ phím thành kịch bản để chạy lại tự động nhiều lần, nên hợp với "GUI testing", với kiểm thử hồi quy, và với "Performance testing" khi kịch bản đã ghi được nhân lên thành nhiều người dùng ảo để tạo tải. "User requirements." không phải một hoạt động kiểm thử chạy được bằng ghi rồi phát lại: yêu cầu người dùng là tài liệu, được thẩm định bằng rà soát và kiểm thử chấp nhận với người dùng thật, nên đây là chỗ ghi-phát lại ít dùng nhất. Có ý kiến chọn "Recovery testing" vì kiểm thử phục hồi phải cố ý gây sự cố như ngắt điện, rút mạng, điều mà công cụ ghi thao tác không tạo ra được; lập luận đó có lý, nhưng sau khi gây sự cố, kịch bản ghi sẵn vẫn được phát lại để xác nhận hệ thống khôi phục đúng, còn với yêu cầu người dùng thì gần như không có chỗ dùng.

Đá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: "Implementation and execution.". Trong quy trình kiểm thử cơ bản của ISTQB, giai đoạn thực hiện và thực thi bắt đầu bằng việc hoàn thiện ca kiểm thử thành thủ tục kiểm thử (test procedure), chuẩn bị dữ liệu, viết kịch bản tự động và gom các thủ tục thành bộ kiểm thử (test suite) để thực thi hiệu quả, sau đó mới chạy và ghi kết quả. "Planning and control." xác định mục tiêu, phạm vi, cách tiếp cận, nguồn lực và theo dõi tiến độ, lúc đó chưa có ca kiểm thử cụ thể nào để gom. "Analysis and design." rà soát cơ sở kiểm thử, xác định điều kiện kiểm thử, thiết kế ca kiểm thử mức cao và môi trường kiểm thử, còn việc xếp chúng thành bộ để chạy diễn ra ở bước sau. "Test closure." diễn ra khi đã kiểm thử xong: kiểm tra sản phẩm bàn giao, lưu trữ testware, rút kinh nghiệm.

Đá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: "2 tests for statement coverage, 2 for branch coverage". Đoạn mã có hai lệnh IF. Lệnh thứ nhất: nếu A lớn hơn B thì gán C = A - B, ngược lại gán C = A + B. Sau đó đọc D, lệnh thứ hai: nếu C bằng D thì in Error. Độ phủ câu lệnh (statement coverage) cần mọi lệnh chạy ít nhất một lần. Ca thứ nhất cho A lớn hơn B và chọn D bằng C, chạy lệnh trừ cùng lệnh in. Ca thứ hai cho A không lớn hơn B, chạy lệnh cộng. Không ca nào chạy được cả lệnh trừ lẫn lệnh cộng, nên cần đúng 2 ca. Độ phủ nhánh (branch coverage) cần mỗi quyết định đi cả nhánh đúng lẫn sai: ca thứ nhất cho đúng ở cả hai IF, ca thứ hai cho sai ở cả hai IF nếu chọn D khác C, nên 2 ca đủ phủ bốn nhánh. "1 test for statement coverage, 3 for branch coverage" sai vì một ca không thể chạy cả hai nhánh gán của IF đầu, và nhánh chỉ cần 2 ca. "2 tests for statement coverage. 3 for branch coverage" sai ở số ca nhánh. "3 tests for statement coverage, 3 for branch coverage" và "3 tests for statement coverage, 2 for branch coverage" sai vì câu lệnh chỉ cần 2 ca.

Đáp án đúng: "Management". Rà soát kỹ thuật (technical review) là buổi thảo luận giữa đồng nghiệp và chuyên gia kỹ thuật nhằm đạt đồng thuận về nội dung kỹ thuật và tìm khiếm khuyết; ISTQB mô tả nó có thể thực hiện như rà soát đồng cấp (peer review) không có sự tham gia của quản lý, vì sự có mặt của quản lý khiến người tham gia ngại nêu vấn đề và dễ biến buổi rà soát thành đánh giá con người. "Analysts" là người viết hoặc hiểu sâu yêu cầu, thường tham gia rà soát kỹ thuật tài liệu yêu cầu và thiết kế. "Developers" là đồng nghiệp kỹ thuật cốt lõi, rà soát mã và thiết kế của nhau. "Testers" tham gia để kiểm tra khả năng kiểm thử và phát hiện mâu thuẫn trong sản phẩm được rà soát, cũng là thành phần kỹ thuật bình thường.

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