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

Đáp án đúng: "Improvements suggested by users". Sự cố (incident) là bất kỳ sự kiện nào xảy ra trong kiểm thử cần được điều tra, thường là chênh lệch giữa kết quả thực tế và kết quả mong đợi. Theo ISTQB Foundation, sự cố có thể được ghi nhận đối với bất kỳ sản phẩm công việc nào có thể chứa lỗi, như yêu cầu, tài liệu, ca kiểm thử hay mã. Góp ý cải tiến của người dùng thì không phải sai lệch so với điều mong đợi mà là đề xuất thay đổi, thường được quản lý như yêu cầu thay đổi hay yêu cầu nâng cấp (change request, enhancement request), nên thông thường không mở sự cố cho nó. "Requirements" có thể bị ghi sự cố khi yêu cầu mâu thuẫn, mơ hồ hay sai. "Documentation" như hướng dẫn sử dụng có thể bị ghi sự cố khi mô tả không khớp hệ thống. "Test cases" cũng có thể bị ghi sự cố khi chính kết quả mong đợi trong ca kiểm thử bị sai.

Đáp án đúng: "Run the risk that the requirements are not satisfied.". Kiểm thử hộp trắng (white-box testing) thiết kế ca kiểm thử từ cấu trúc mã, nên chỉ kiểm được những gì đã được lập trình; nếu một yêu cầu bị hiểu sai hoặc bị bỏ sót hoàn toàn trong mã thì không có câu lệnh hay nhánh nào để phủ, và kiểm thử hộp trắng sẽ không phát hiện ra. Chỉ dùng hộp trắng vì vậy có rủi ro hệ thống không thoả yêu cầu. "Ensure the test item is adequately tested" sai vì độ phủ cấu trúc cao không đảm bảo đủ, còn thiếu góc nhìn từ đặc tả. "Make the need for black-box testing redundant." sai vì hai cách tiếp cận bổ sung cho nhau, hộp đen mới đối chiếu với yêu cầu. "Suffices for the unit testing phase" sai vì ngay ở cấp thành phần vẫn cần kiểm theo đặc tả của thành phần, hộp trắng một mình không đủ.

Đáp án đúng: "Both of (1) and (2)". Công cụ và tự động hoá kiểm thử mang lại hai thuộc tính cốt lõi: tốc độ và hiệu suất, vì máy chạy hàng nghìn ca kiểm thử lặp lại nhanh hơn người rất nhiều, giảm việc thủ công lặp đi lặp lại; và độ chính xác, độ chuẩn xác, vì máy thực hiện đúng từng bước như nhau mọi lần, so sánh kết quả không bỏ sót và không mệt mỏi. ISTQB Foundation cũng nêu lợi ích của công cụ là giảm việc lặp lại, tăng tính nhất quán và khả năng lặp lại, cung cấp đánh giá khách quan. Vì cả hai thuộc tính cùng đúng nên phải chọn cả hai. "(1) Speed & efficiency" chỉ nêu một nửa, bỏ mất tính chính xác. "(2) Accuracy & precision" cũng chỉ nêu một nửa, bỏ mất tốc độ. "None of (1) nor (2)" sai vì phủ nhận cả hai lợi ích cơ bản nhất mà tự động hoá mang lại.

Đáp án đúng: "i-c , ii-a , iii-d , iv-b". Mô hình chữ V (V-model) ghép mỗi bước phát triển bên trái với một cấp kiểm thử bên phải dùng sản phẩm của bước đó làm cơ sở kiểm thử: yêu cầu nghiệp vụ (business requirements) là căn cứ của kiểm thử chấp nhận nên iv ghép b, thiết kế mức cao (hi-level design) mô tả kiến trúc toàn hệ thống nên ứng với kiểm thử hệ thống, i ghép c, thiết kế mức thấp (low-level design) mô tả các mô-đun và giao diện giữa chúng nên ứng với kiểm thử tích hợp, iii ghép d, còn mã (code) ứng với kiểm thử đơn vị, ii ghép a. "i-d , ii-a , iii-c , iv-b" đảo cặp thiết kế mức cao và mức thấp, gán kiểm thử hệ thống cho thiết kế mức thấp. "i-c , ii-d , iii-a , iv-b" đặt kiểm thử tích hợp cho mã và kiểm thử đơn vị cho thiết kế mức thấp, ngược thứ bậc. "i-b , ii-a , iii-d , iv-c" gán kiểm thử chấp nhận cho thiết kế mức cao và kiểm thử hệ thống cho yêu cầu nghiệp vụ, trong khi chấp nhận phải đối chiếu với nhu cầu nghiệp vụ.

Đáp án đúng: "(2) Record/Playback". Kiểm thử hồi quy (regression testing) là chạy lại các ca kiểm thử đã có sau mỗi thay đổi để chắc rằng phần chưa sửa không bị ảnh hưởng; vì bộ ca này lặp lại nhiều lần với cùng các bước, công cụ ghi và phát lại (record/playback), một dạng công cụ thực thi kiểm thử tự động, là lựa chọn điển hình: ghi thao tác một lần rồi phát lại ở mỗi bản dựng mới và so kết quả. "(1) Performance" là công cụ đo hiệu năng, mô phỏng tải và thời gian đáp ứng, phục vụ kiểm thử phi chức năng chứ không nhằm xác nhận chức năng cũ còn chạy đúng. "Both of (1) and (2)" sai vì công cụ hiệu năng không phải loại công cụ dành cho hồi quy chức năng. "None of (1) nor (2)" sai vì record/playback chính là loại công cụ được dùng phổ biến nhất cho kiểm thử hồi quy.

Đáp án đúng: "The fault has been built into more documentation, code, tests, etc". Một lỗi sinh ra ở pha đầu, ví dụ trong yêu cầu, sẽ lan sang thiết kế, mã nguồn, tài liệu người dùng và cả ca kiểm thử được viết theo yêu cầu đó; càng phát hiện muộn thì càng nhiều sản phẩm công việc phải sửa lại và kiểm lại, nên chi phí sửa tăng theo cấp số qua từng pha. Đây là lý do ISTQB đặt nguyên tắc kiểm thử sớm (early testing). "The documentation is poor, so it takes longer to find out what the software is doing." chỉ là một tình huống riêng của dự án có tài liệu kém, không giải thích quy luật chung áp dụng cho mọi dự án. "Wages are rising" không liên quan: chi phí tăng vì khối lượng sửa chữa lan rộng chứ không vì lương tăng theo thời gian. "None of the others" sai vì đã có một phương án nêu đúng nguyên nhân là lỗi bị nhúng vào ngày càng nhiều sản phẩm công việc.

Đáp án đúng: "BS7925-2". BS 7925-2 là chuẩn của Viện Tiêu chuẩn Anh (BSI) về kiểm thử thành phần (component testing, còn gọi kiểm thử đơn vị): nó mô tả quy trình kiểm thử thành phần cùng các kỹ thuật thiết kế ca kiểm thử như phân hoạch tương đương, phân tích giá trị biên, kiểm thử chuyển trạng thái, độ phủ câu lệnh và nhánh, kèm cách đo độ phủ cho từng kỹ thuật. "IEEE 829" là chuẩn về tài liệu kiểm thử phần mềm (kế hoạch kiểm thử, đặc tả ca kiểm thử, báo cáo sự cố, báo cáo tổng kết), quy định mẫu tài liệu chứ không quy định cách kiểm thử thành phần. "IEEE 610" là bộ thuật ngữ chuẩn của kỹ nghệ phần mềm, chỉ định nghĩa các từ như error, fault, failure. "BS7925-1" là phần một của cùng bộ chuẩn, tức bảng thuật ngữ kiểm thử phần mềm (vocabulary) cung cấp định nghĩa dùng chung cho phần hai, chứ không phải chuẩn quy trình kiểm thử thành phần.

Đáp án đúng: "(ii) Structural Testing". Kiểm thử cấu trúc (structural testing, hộp trắng) thiết kế ca kiểm thử từ cấu trúc bên trong như câu lệnh, nhánh, đường đi, nhằm làm chạy qua từng phần của mã; vì xuất phát từ mã chứ không từ cách người dùng sử dụng, các ca này thường là những tổ hợp nhân tạo, không nhất thiết phản ánh tình huống thực tế. "(i) Functional testing" dựa trên yêu cầu và hành vi mong đợi, thường xây ca kiểm thử từ kịch bản nghiệp vụ, nên gần với tình huống thực tế hơn. "Both of (i) and (ii)" sai vì kiểm thử chức năng vốn nhằm mô phỏng cách hệ thống được dùng. "None of (i) nor (ii)" sai vì kiểm thử cấu trúc đúng là loại có thể không mô phỏng được thế giới thực.

Đáp án đúng: "Uncover software errors". Mục tiêu căn bản của kiểm thử phần mềm là tìm ra lỗi: chạy chương trình với ý định phát hiện khuyết tật, qua đó cung cấp thông tin về chất lượng và giảm rủi ro. ISTQB nhấn mạnh kiểm thử chỉ cho thấy có lỗi, không chứng minh được là không còn lỗi. "Determine the productivity of programmers" sai vì kiểm thử đánh giá sản phẩm chứ không đánh giá con người; dùng số lỗi để chấm năng suất còn làm hỏng quan hệ giữa người kiểm thử và lập trình viên. "Eliminate the need for future program maintenance" sai vì bảo trì luôn cần do yêu cầu thay đổi, môi trường thay đổi và lỗi còn sót, kiểm thử không loại bỏ được nhu cầu đó. "Eliminate every error prior to release" trái với nguyên tắc kiểm thử vét cạn là không thể và kiểm thử không chứng minh được sự vắng mặt của lỗi.

Đá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: "i and iv". ISTQB Foundation liệt kê lợi ích tiềm năng của công cụ kiểm thử: giảm công việc lặp lại, tăng tính nhất quán và khả năng lặp lại của kiểm thử (mục iv), cung cấp đánh giá khách quan như số đo tĩnh, độ phủ, và dễ truy cập thông tin về kiểm thử và quá trình kiểm thử (mục i) qua thống kê, biểu đồ. Ngược lại, tài liệu này nêu rõ rủi ro là đánh giá thấp thời gian, chi phí để giới thiệu công cụ và đánh giá thấp công sức bảo trì các tài sản kiểm thử do công cụ sinh ra. Vì vậy mục ii, giảm bảo trì testware, và mục iii, dễ và rẻ để triển khai, là hai kỳ vọng sai. "ii and iv" sai vì kèm giảm bảo trì, vốn là rủi ro chứ không phải lợi ích. "ii and iii" sai vì cả hai đều là kỳ vọng phi thực tế. "i and iii" sai vì triển khai công cụ thường tốn kém và mất công, không dễ và rẻ.

Đáp án đúng: "The likelihood of an adverse event and the impact of the event.". Theo ISTQB, rủi ro là khả năng một sự kiện bất lợi xảy ra kèm hậu quả của nó, và mức rủi ro được xác định bởi hai yếu tố: khả năng xảy ra (likelihood) và tác động (impact) nếu nó xảy ra, thường được ước bằng cách kết hợp hai đại lượng này. "The probability that an adverse event will occur." chỉ có một nửa: sự kiện rất dễ xảy ra nhưng hậu quả không đáng kể thì rủi ro vẫn thấp. "The cost of dealing with an adverse event if it occurs." là nửa còn lại, phần tác động, thiếu khả năng xảy ra. "The amount of testing planned before release of a system." là hệ quả chứ không phải nguyên nhân: lượng kiểm thử được lên kế hoạch dựa trên mức rủi ro, chứ không quyết định mức rủi ro.

Đá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: "Moderator". Trong rà soát hình thức (formal review) theo ISTQB Foundation, người điều phối (moderator) là người dẫn dắt việc rà soát tài liệu: lập kế hoạch rà soát, điều hành buổi họp và theo dõi sau buổi họp (follow-up), đồng thời làm trung gian giữa các quan điểm và thường quyết định có rà soát lại hay không. "Reviewer" (người rà soát, còn gọi checker hay inspector) là người đọc tài liệu để tìm lỗi, không chịu trách nhiệm tổ chức. "Author" (tác giả) là người viết hoặc chịu trách nhiệm chính về tài liệu được rà soát, nhận lỗi và sửa chúng ở bước làm lại; tác giả không nên điều phối để giữ khách quan. "Auditor" (kiểm toán viên) thuộc hoạt động kiểm toán (audit), đánh giá độc lập mức tuân thủ chuẩn và quy trình, không phải vai trò trong một buổi rà soát tài liệu.

Đáp án đúng: "(i) Identifying defects.". Theo ISTQB Foundation, rà soát (review), phân tích tĩnh (static analysis) và kiểm thử động (dynamic testing) có chung mục tiêu là xác định lỗi (identifying defects); chúng chỉ khác nhau ở cách tìm: rà soát và phân tích tĩnh tìm trực tiếp khiếm khuyết trong sản phẩm mà không chạy, còn kiểm thử động chạy phần mềm để làm lộ ra thất bại (failure) rồi lần về khiếm khuyết. Chúng bổ sung cho nhau vì mỗi kỹ thuật tìm hiệu quả những loại lỗi khác nhau. "(ii) Fixing defects." sai vì sửa lỗi là gỡ lỗi (debugging), việc của lập trình viên sau khi lỗi đã được tìm thấy, không phải mục tiêu của ba hoạt động này. "(i) and (ii)" sai vì kèm theo mục sửa lỗi. "None of (i) nor (ii)" sai vì phủ nhận cả mục tiêu chung là tìm lỗi.

Đáp án đúng: "Plan, Do, Check, Act". PDCA là chu trình cải tiến liên tục, gắn với tên Deming (còn gọi là vòng Deming hay Shewhart), gồm bốn bước: Plan (lập kế hoạch, đặt mục tiêu và cách làm), Do (thực hiện), Check (kiểm tra, đo kết quả so với mục tiêu) và Act (hành động điều chỉnh, chuẩn hoá cái tốt rồi bắt đầu vòng mới). Trong kiểm thử, chu trình này là nền cho cải tiến quy trình kiểm thử. "Plan, Do, Correct, Act" sai ở bước thứ ba: chu trình cần kiểm tra, đánh giá trước rồi mới điều chỉnh, sửa chữa thuộc về bước Act. "Plan, Debug, Check, Act" sai vì gỡ lỗi (debug) là hoạt động của lập trình viên, không phải bước của chu trình quản lý chất lượng. "Plan, Do, Check, Accept" sai ở bước cuối: Act là hành động cải tiến, không phải chấp nhận kết quả.

Đáp án đúng: "Faults in requirements are the most expensive to fix". Chi phí sửa lỗi tăng theo thời gian lỗi tồn tại trong vòng đời phát triển: lỗi trong yêu cầu được đưa vào sớm nhất rồi lan sang thiết kế, mã, tài liệu và ca kiểm thử, nên nếu chỉ phát hiện ở kiểm thử chấp nhận hay khi vận hành thì phải sửa lại mọi sản phẩm dựng trên nó; đó là lý do ISTQB nhấn mạnh kiểm thử sớm và rà soát yêu cầu. "Faults in program specifications are the most expensive to fix" sai vì đặc tả chương trình được viết sau yêu cầu, lỗi ở đó lan qua ít tầng hơn. "Faults in designs are the most expensive to fix." cũng vậy: thiết kế đứng sau yêu cầu nên lỗi thiết kế tốn kém nhưng vẫn ít hơn. "Faults in code are the most expensive to fix." sai vì lỗi mã thường chỉ cần sửa trong mã rồi chạy lại kiểm thử, phạm vi ảnh hưởng hẹp nhất trong bốn loại.

Đáp án đúng: "When the test completion criteria have been met". Tiêu chí hoàn thành (test completion criteria, hay exit criteria) được đặt từ lúc lập kế hoạch, chẳng hạn mức độ phủ, số khiếm khuyết còn mở, rủi ro còn lại chấp nhận được, và chính chúng là căn cứ khách quan để dừng kiểm thử. "When time for testing has run out." là điều hay xảy ra trong thực tế nhưng là dừng vì áp lực, không bảo đảm chất lượng đạt yêu cầu; thời gian chỉ hợp lệ khi đã được ghi vào tiêu chí. "When all planned tests have been run" chưa đủ vì có thể còn nhiều ca thất bại hay khiếm khuyết nghiêm trọng chưa sửa. "When no faults have been found by the tests run" sai vì kiểm thử chỉ chứng minh có khiếm khuyết chứ không chứng minh được không còn khiếm khuyết; không tìm thấy lỗi có thể chỉ do bộ ca yếu.

Đáp án đúng: "At all test levels.". Kiểm thử chức năng (functional testing) kiểm tra hệ thống làm gì, dựa trên đặc tả chức năng hoặc yêu cầu; theo ISTQB, nó là một loại kiểm thử (test type) chứ không phải một cấp kiểm thử, nên được thực hiện ở mọi cấp: kiểm thử đơn vị kiểm chức năng của từng thành phần, kiểm thử tích hợp kiểm chức năng của tương tác giữa các thành phần, kiểm thử hệ thống và chấp nhận kiểm chức năng đầu cuối. "At system and acceptance testing levels only." sai vì bỏ mất cấp đơn vị và tích hợp, nơi chức năng của từng phần cũng được kiểm. "At all levels above integration testing." sai vì loại cả cấp đơn vị lẫn chính cấp tích hợp. "At the acceptance testing level only." hẹp nhất, nhầm kiểm thử chức năng với kiểm thử chấp nhận người dùng.

Đáp án đúng: "i, ii, iv.". Theo ISTQB Foundation, khi chọn và đưa một công cụ kiểm thử vào tổ chức cần đánh giá mức trưởng thành và quy trình kiểm thử hiện tại của tổ chức, đánh giá công cụ theo yêu cầu rõ ràng và chạy thử nghiệm khái niệm (proof of concept), đánh giá nhà cung cấp, và xác định nhu cầu hướng dẫn, kèm cặp (coaching and mentoring) cho người dùng công cụ; sau đó áp dụng thử ở một dự án thí điểm. Mục iii, đưa công cụ vào một dự án đang trễ tiến độ để tiết kiệm thời gian, là điều ISTQB khuyên tránh, vì công cụ mới cần thời gian học và điều chỉnh, nên lúc đầu thường làm chậm hơn chứ không nhanh hơn. Có bản lưu hành của câu này chấm "i, iii, iv." là đúng, nhưng phương án đó chứa chính mục iii và bỏ mất proof of concept nên không đứng vững. "i, ii, iii." sai vì có mục iii và bỏ sót việc xác định nhu cầu kèm cặp. "ii, iii, iv." sai vì có mục iii và bỏ qua việc khảo sát quy trình kiểm thử của tổ chức.