Câu hỏi: SWT301 - Phần 3: Kỹ thuật kiểm thử tĩnh và rà soát

Đáp án đúng: "Memory leaks". Phân tích tĩnh (static analysis) xem xét mã nguồn mà không chạy chương trình, dựa trên luồng điều khiển và luồng dữ liệu. Rò rỉ bộ nhớ (memory leak) phụ thuộc vào việc cấp phát và giải phóng diễn ra thế nào lúc chạy, trên đường đi và dữ liệu cụ thể, nên phải dùng công cụ phân tích động (dynamic analysis) mới phát hiện tin cậy được. "The use of a variable before it has been defined" là bất thường luồng dữ liệu kinh điển mà phân tích tĩnh tìm được bằng cách lần theo cặp định nghĩa và sử dụng biến. "Unreachable ("dead") code" tìm được bằng phân tích luồng điều khiển, vì đồ thị cho thấy không có đường nào tới đoạn mã đó. "Array bound violations" phân tích tĩnh cũng phát hiện được khi chỉ số mảng có thể xác định từ mã, ví dụ hằng số hay biến vòng lặp vượt kích thước khai báo.

Đáp án đúng: "i,iii,iv are true and ii is false". Thanh tra (inspection) là loại rà soát hình thức nhất theo ISTQB: do người điều phối (moderator) đã được đào tạo dẫn dắt chứ không phải tác giả, có vai trò rõ ràng, có tiêu chí vào và ra, dùng danh sách kiểm tra, có quy trình theo dõi (follow-up) chính thức để xác nhận lỗi đã sửa, và mục tiêu chính là tìm lỗi; vì vậy các mệnh đề i, iii, iv đúng. Mệnh đề ii sai vì thanh tra bắt buộc có bước chuẩn bị cá nhân (individual preparation) trước cuộc họp, mỗi người tự đọc tài liệu và ghi lại lỗi tiềm năng. "ii is true and i,iii,iv are false" sai vì coi việc bỏ chuẩn bị là đặc điểm của thanh tra và phủ nhận cả người điều phối, quy trình theo dõi lẫn mục tiêu tìm lỗi. "i,iii,iv are false and ii is true" là chính nhận định đó viết đảo thứ tự, sai vì cùng lý do thanh tra luôn có chuẩn bị trước họp. "iii is true and I,ii,iv are false" chỉ nhận quy trình theo dõi mà bác vai trò người điều phối và mục tiêu tìm lỗi, trái với bản chất của thanh tra.

Đáp án đúng: "Inspection". Trong các loại review của ISTQB, inspection (thanh tra) là loại hình thức nhất: do người điều phối (moderator) đã được đào tạo dẫn dắt, người tham gia có vai trò xác định, có tiêu chí đầu vào và đầu ra, dùng checklist, ghi nhận và đo đạc lỗi, mục tiêu chính là phát hiện khuyết tật trong sản phẩm công việc. Mô tả "đánh giá chính thức do người review đủ năng lực và độc lập thực hiện để phát hiện lỗi" khớp với tính chất đó. "Walkthrough" do chính tác giả dẫn dắt, có thể hình thức hoặc không, mục tiêu thiên về chia sẻ hiểu biết và học hỏi hơn là đánh giá độc lập. "Review" là tên chung của mọi hình thức đánh giá tĩnh, từ không chính thức tới inspection, nên quá rộng để là đáp án. "Non Conformance" nghĩa là sự không phù hợp với yêu cầu, tức là một kết quả có thể được phát hiện, không phải một loại review.

Đáp án đúng: "How much of the code has been covered". Thanh tra (inspection) là dạng rà soát (review) hình thức nhất trong kiểm thử tĩnh (static testing): người tham gia đọc tài liệu hoặc mã nguồn mà không chạy chương trình, dựa trên danh mục kiểm tra (checklist) để tìm lỗi. Độ phủ mã (code coverage) lại là phép đo của kiểm thử động: nó chỉ có được khi chạy ca kiểm thử và ghi nhận câu lệnh, nhánh nào đã thực thi, nên thanh tra không cho biết được. "Variables not defined in the code" tìm được khi thanh tra mã, vì người đọc thấy biến dùng mà chưa khai báo. "Spelling and grammar faults in the documents" tìm được khi thanh tra tài liệu, là loại lỗi dễ thấy nhất khi đọc kỹ. "Requirements that have been omitted from the design documents" cũng tìm được, vì thanh tra đối chiếu tài liệu thiết kế với tài liệu yêu cầu gốc nên phát hiện yêu cầu bị bỏ sót.

Đáp án đúng: "Scenario , Dry Run , Peer Group". Buổi duyệt qua (walkthrough) do chính tác giả dẫn dắt, thường dùng kịch bản (scenario) và chạy thử trên giấy (dry run) để đưa nhóm đồng nghiệp (peer group) đi qua sản phẩm, mục tiêu là học hỏi, hiểu chung và tìm khiếm khuyết; hình thức có thể từ không chính thức tới khá chính thức. "Pre Meeting Preparations" là đặc trưng của thanh tra (inspection), nơi người rà soát bắt buộc chuẩn bị riêng trước buổi họp; với walkthrough việc chuẩn bị trước chỉ là tuỳ chọn. "Formal Follow Up Process" cũng thuộc inspection: có quy trình theo dõi chính thức để kiểm tra các khiếm khuyết đã được sửa. "Includes Metrics" là đặc điểm của inspection, nơi số đo được thu thập để cải tiến quy trình, còn walkthrough thường không thu thập số đo.

Đáp án đúng: "Explaining the objective". Theo ISTQB Foundation, quy trình rà soát hình thức (formal review) gồm lập kế hoạch (planning), khởi động (kick-off), chuẩn bị cá nhân (individual preparation), họp rà soát (review meeting), làm lại (rework) và theo dõi (follow-up). Ở bước kick-off, người điều phối phân phát tài liệu và giải thích mục tiêu, quy trình và tài liệu cho những người tham gia, nên giải thích mục tiêu thuộc đúng bước này. "Fixing defects found typically done by author" là bước rework: tác giả sửa lỗi sau buổi họp. "Follow up" là bước riêng ở cuối: kiểm tra lỗi đã được sửa, thu thập số đo và đánh giá tiêu chí thoát. "Individual Meeting preparations" ứng với bước chuẩn bị cá nhân, diễn ra sau kick-off, khi từng người tự đọc tài liệu và ghi lại lỗi, câu hỏi trước buổi họp.

Đá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: "Difficult to test". Độ phức tạp chu trình (cyclomatic complexity) của McCabe đo số đường đi độc lập tuyến tính qua đồ thị luồng điều khiển, tính bằng số điểm quyết định cộng một. Con số này cũng là số ca kiểm thử tối thiểu để phủ hết các đường cơ sở, nên độ phức tạp cao nghĩa là nhiều nhánh, nhiều đường cần kiểm thử, khó đạt độ phủ và khó suy luận hành vi, tức là khó kiểm thử. "Large" sai vì độ phức tạp chu trình đo cấu trúc rẽ nhánh chứ không đo số dòng; một chương trình dài mà tuần tự vẫn có độ phức tạp thấp. "Small" sai vì độ phức tạp cao không ngụ ý chương trình nhỏ, ngược lại thường có nhiều lệnh điều kiện. "Difficult to write" không phải điều chỉ số này đo: một đoạn mã nhiều nhánh có thể viết nhanh, cái khó thể hiện rõ nhất là ở số ca kiểm thử và công sức kiểm thử, bảo trì.

Đáp án đúng: "Static testing requires the running of tests through the code". Câu hỏi tìm phát biểu sai: kiểm thử tĩnh (static testing) là kiểm tra sản phẩm phần mềm mà không thực thi mã, nên nói nó đòi hỏi chạy kiểm thử qua mã là đặc điểm của kiểm thử động (dynamic testing). Các phát biểu kia đều đúng nên không được chọn. "Static testing includes desk checking" đúng vì kiểm tra trên bàn (desk checking), tức tự đọc và lần theo mã bằng tay, là một hình thức kiểm thử tĩnh. "Static testing includes techniques such as reviews and inspections" đúng vì rà soát (review) và thanh tra (inspection) là nhóm kỹ thuật tĩnh chính trong ISTQB. "Static testing can give measurements such as cyclomatic complexity" đúng vì công cụ phân tích tĩnh (static analysis) tính được độ phức tạp chu trình từ cấu trúc mã mà không cần chạy chương trì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: "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: "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: "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: "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: "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.

Đáp án đúng: "Scribe". Người ghi chép (scribe, recorder) trong rà soát hình thức có nhiệm vụ ghi lại mọi lỗi, vấn đề và điểm còn mở được nêu trong cuộc họp rà soát, cùng các đề xuất cải tiến, làm cơ sở cho bước làm lại và theo dõi. "Moderator" dẫn dắt quy trình và chủ trì cuộc họp; việc điều hành đòi hỏi tập trung nên ghi chép được giao cho người khác. "Reviewers" là những người rà soát, tìm lỗi và nêu vấn đề trong cuộc họp; họ cung cấp nội dung chứ không phải người lưu lại. "Author" là tác giả tài liệu, người nhận danh sách lỗi để sửa trong bước làm lại; ở một số rà soát ít hình thức tác giả có thể tự ghi, nhưng vai trò được giao chính thức việc này là người ghi chép.