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

Đá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: "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: "ii,iii,iv are correct and i is incorrect". ISTQB Foundation liệt kê các yếu tố thành công của review gồm: mỗi buổi review có mục tiêu rõ ràng được xác định trước, đúng người tham gia, khuyết tật tìm được được hoan nghênh và nêu một cách khách quan, có sự ủng hộ của ban quản lý cho quy trình review, và chú trọng việc học hỏi, cải tiến quy trình. Vì vậy mục ii, iii, iv đúng, còn mục i nói review "không có mục tiêu định trước" là ngược với yếu tố thành công nên sai. "iii , i , iv is correct and ii is incorrect" sai vì coi mục i là đúng và bác mục ii, trong khi thái độ khách quan với lỗi chính là điều kiện cốt lõi. "i , iii , iv , ii is in correct" sai vì phủ nhận cả ba yếu tố đúng. "ii is correct" chỉ nhận một mục, bỏ sót sự ủng hộ của ban quản lý và việc chú trọng học hỏi.

Đá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: "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: "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: "Suggestions as to how to fix the problem.". Báo cáo sự cố (incident report) theo IEEE 829 mô tả điều đã quan sát được để người khác tái hiện và phân tích: ai báo, khi nào, phiên bản phần mềm và môi trường, các bước, kết quả mong đợi và kết quả thực tế, mức nghiêm trọng; còn chẩn đoán nguyên nhân và cách sửa là việc của lập trình viên khi gỡ lỗi, nên đề xuất cách sửa thường không có trên báo cáo. "The name and/or organisational position of the person raising the problem." là thông tin chuẩn để biết ai phát hiện và liên hệ lại. "Version of the Software Under Test." là bắt buộc vì không biết phiên bản thì không tái hiện được lỗi. "Actual and expected results." là phần cốt lõi, chính độ lệch giữa hai kết quả này làm nên sự cố.

Đáp án đúng: "Enforcement of coding standards.". Công cụ phân tích tĩnh (static analysis tool) đọc mã nguồn mà không chạy nó, đối chiếu với tập quy tắc để báo các vi phạm như đặt tên sai quy ước, hàm quá dài, độ phức tạp vòng cao, biến không dùng; kiểm tra tuân thủ chuẩn lập trình một cách tự động, đồng loạt trên toàn bộ mã là thế mạnh rõ nhất của loại công cụ này. "Supporting reviews." là việc của công cụ hỗ trợ rà soát (review tool) như lưu tài liệu, ghi nhận xét, quản lý cuộc họp; phân tích tĩnh có thể góp số liệu cho rà soát nhưng không phải công cụ chuyên cho việc đó. "Validating models of the software." là việc của công cụ mô hình hóa (modelling tool), kiểm tra tính nhất quán của mô hình như sơ đồ UML hay mô hình dữ liệu. "Testing code executed in a special test harness." là kiểm thử động: mã được chạy trong khung kiểm thử (test harness) có driver và stub, thuộc công cụ thực thi kiểm thử hoặc kiểm thử đơn vị.

Đáp án đúng: "Preventative tests are designed early; reactive tests are designed after the software has been produced.". ISTQB Foundation phân loại cách tiếp cận kiểm thử theo thời điểm thiết kế ca kiểm thử: cách tiếp cận phòng ngừa (preventative) thiết kế kiểm thử càng sớm càng tốt, ngay từ khi có yêu cầu và thiết kế, để ngăn lỗi lọt vào sản phẩm; cách tiếp cận phản ứng (reactive) chỉ thiết kế kiểm thử sau khi phần mềm đã được làm ra, phản ứng với sản phẩm thực tế, ví dụ kiểm thử thăm dò. Khác biệt then chốt vì vậy là thời điểm. "Preventative tests and reactive tests are designed as early as possible." sai vì xoá mất khác biệt, gán cả hai vào thiết kế sớm. "Preventative testing is always analytical; reactive testing is always heuristic." sai vì phân tích (analytical) hay dựa kinh nghiệm (heuristic) là một trục phân loại chiến lược khác, không gắn cứng với phòng ngừa hay phản ứng. "Preventative tests are designed after the software has been produced; reactive tests are designed early in response to review comments." đảo ngược hai định nghĩa.

Đáp án đúng: "Equivalence partitioning". Phân vùng tương đương (equivalence partitioning) chia miền dữ liệu thành các phân vùng mà mọi giá trị trong cùng phân vùng được kỳ vọng xử lý như nhau; ISTQB nêu rõ kỹ thuật này áp dụng cho cả đầu vào lẫn đầu ra, nên có thể dùng để đạt mục tiêu độ phủ đầu vào và độ phủ đầu ra (mỗi phân vùng được kiểm ít nhất một lần). "Boundary value analysis" là phần mở rộng của phân vùng tương đương, chỉ tập trung vào các giá trị nằm ở mép phân vùng, nên nó đo độ phủ biên chứ không phải kỹ thuật nền để phủ đầu vào và đầu ra. "Decision table testing" nhắm vào độ phủ các tổ hợp điều kiện và hành động tương ứng. "State transition testing" nhắm vào độ phủ trạng thái và chuyển trạng thái của hệ thống, không phải phủ miền giá trị vào ra.

Đáp án đúng: "3,10,22". Phân vùng tương đương (equivalence partitioning) chia miền nhập thành các lớp được xử lý như nhau: lớp không hợp lệ nhỏ hơn 10, lớp hợp lệ từ 10 tới 21, lớp không hợp lệ từ 22 trở lên; muốn phủ mọi phân vùng chỉ cần mỗi lớp một giá trị. Giá trị 3 rơi vào lớp nhỏ hơn 10, 10 rơi vào lớp hợp lệ, 22 rơi vào lớp từ 22 trở lên, nên đủ ba lớp. "10,11,21" có cả ba giá trị đều nằm trong lớp hợp lệ, bỏ sót hai lớp không hợp lệ. "3,20,21" phủ lớp nhỏ hơn 10 và lớp hợp lệ nhưng không có giá trị nào từ 22 trở lên. "10,21,22" phủ lớp hợp lệ và lớp từ 22 trở lên nhưng thiếu giá trị nhỏ hơn 10; bộ này trông giống giá trị biên nhưng phân tích biên là kỹ thuật khác.

Đáp án đúng: "Top-down integration testing". Kiểm thử hệ thống (system testing) xét toàn bộ hệ thống đã tích hợp đầy đủ, đối chiếu với đặc tả yêu cầu cả chức năng lẫn phi chức năng; còn tích hợp từ trên xuống là một chiến lược của cấp kiểm thử tích hợp (integration testing), ghép dần các mô-đun từ mô-đun điều khiển cao nhất xuống và dùng stub thay cho mô-đun cấp dưới chưa có, nên nó diễn ra trước và không thuộc kiểm thử hệ thống. "Business process-based testing" thuộc kiểm thử hệ thống vì ca kiểm thử dựng theo quy trình nghiệp vụ, kịch bản sử dụng đầu cuối. "Performance, load and stress testing" là kiểm thử phi chức năng tiêu biểu ở cấp hệ thống, đo thời gian phản hồi và khả năng chịu tải trên môi trường gần giống thật. "Requirements-based testing" thiết kế ca kiểm thử từ đặc tả yêu cầu, chính là cơ sở kiểm thử chủ yếu của cấp hệ thống. "Usability testing" đánh giá mức dễ học, dễ dùng của hệ thống hoàn chỉnh, cũng là kiểm thử phi chức năng ở cấp này.

Đá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: "Business scenarios". Use case (ca sử dụng) mô tả tương tác giữa tác nhân (actor) và hệ thống để hoàn thành một mục tiêu nghiệp vụ, gồm luồng chính, luồng thay thế và luồng ngoại lệ; kiểm thử dựa trên use case vì vậy rất hữu ích để kiểm các kịch bản nghiệp vụ, luồng quy trình từ đầu đến cuối, thường ở cấp kiểm thử hệ thống và chấp nhận, và hay phát hiện lỗi ở chỗ các thành phần phối hợp với nhau. "Performance testing" là kiểm thử phi chức năng về tốc độ, tải, tài nguyên; use case có thể cung cấp kịch bản tải nhưng bản thân nó không đo hiệu năng. "Unit testing" kiểm từng thành phần riêng lẻ, quá nhỏ so với một use case trải qua nhiều thành phần. "Static testing" là xem xét sản phẩm mà không chạy mã, trong khi kiểm thử theo use case là kiểm thử động, thực thi kịch bản trên hệ thống.

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