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

Đáp án đúng: "Test Effectiveness". Độ phủ mã (code coverage) là tỉ lệ cấu trúc mã như câu lệnh, nhánh, điều kiện đã được bộ ca kiểm thử thực thi. Nó cho biết bộ kiểm thử đã chạm tới bao nhiêu phần của mã, phần nào chưa được kiểm thử, nên được dùng làm thước đo mức kỹ lưỡng, tức hiệu quả của kiểm thử (test effectiveness) và để thiết kế thêm ca kiểm thử cho phần còn trống. "Defects" sai vì độ phủ không đếm lỗi; độ phủ cao vẫn có thể còn lỗi và độ phủ thấp không nói được có bao nhiêu lỗi. "Trends analysis" (phân tích xu hướng) dùng chuỗi số liệu theo thời gian như số lỗi mở, đóng mỗi tuần, không phải điều độ phủ mã đo trực tiếp. "Time Spent Testing" là số đo công sức, nỗ lực của đội kiểm thử, không phản ánh mã đã được thực thi tới đâu.

Đáp án đúng: "Debugging defects". ISTQB phân biệt rõ kiểm thử với gỡ lỗi (debugging): kiểm thử làm lộ ra thất bại do khiếm khuyết gây ra, còn gỡ lỗi là hoạt động phát triển nhằm tìm nguyên nhân, phân tích và sửa khiếm khuyết, thường do lập trình viên làm, nên gỡ lỗi không phải mục tiêu của kiểm thử. "Finding defects" là mục tiêu kinh điển của kiểm thử. "Gaining confidence about the level of quality and providing information" cũng là mục tiêu được nêu rõ: kiểm thử tạo niềm tin vào mức chất lượng và cung cấp thông tin cho việc ra quyết định. "Preventing defects." là mục tiêu đạt được nhờ tham gia kiểm thử sớm, rà soát yêu cầu và thiết kế để chặn khiếm khuyết trước khi nó được viết vào mã.

Đáp án đúng: "Capture/Playback". Công cụ ghi và phát lại (capture/playback) ghi lại thao tác của người kiểm thử thành kịch bản rồi chạy lại tự động bao nhiêu lần cũng được, nên là công cụ thực thi kiểm thử điển hình dùng để tự động hoá kiểm thử hồi quy (regression test), loại kiểm thử phải lặp lại sau mỗi lần thay đổi. "Output comparator." chỉ so sánh kết quả thực tế với kết quả mong đợi; nó hỗ trợ kiểm thử tự động nhưng tự nó không chạy được các ca kiểm thử, nên không phải công cụ chính để tự động hoá hồi quy. "Data tester" gợi tới việc chuẩn bị hoặc kiểm tra dữ liệu kiểm thử, phục vụ khâu chuẩn bị chứ không phát lại kiểm thử. "Boundary tester" gợi tới thiết kế ca kiểm thử theo giá trị biên, là khâu thiết kế chứ không phải tự động thực thi lặp lại.

Đáp án đúng: "(i) Gray Box Testing". Kiểm thử hộp xám (gray box testing) là thuật ngữ được định nghĩa rõ là sự kết hợp hai góc nhìn: người kiểm thử biết một phần cấu trúc bên trong, như thiết kế dữ liệu, thuật toán, kiến trúc, để thiết kế ca kiểm thử tốt hơn, nhưng vẫn thực thi và đánh giá từ bên ngoài như hộp đen. Chỗ dễ nhầm là "(ii) Hybrid Testing": tên gọi nghe như pha trộn, nhưng nó không phải thuật ngữ chuẩn trong ISTQB Foundation và không được định nghĩa là kết hợp hộp đen với hộp trắng, nên không thể coi là đáp án. Vì vậy "Both of (i) and (ii)" sai do kéo theo một thuật ngữ không chuẩn. "None of (i) nor (ii)" sai vì gray box đúng là kỹ thuật mang cả đặc điểm hộp đen và hộp trắng.

Đáp án đúng: "i,ii,iii are true and iv is false.". Theo ISTQB, một cuộc rà soát hình thức (formal review) có các vai trò: quản lý (manager) quyết định thực hiện rà soát, cấp thời gian và nguồn lực; người điều phối (moderator) dẫn dắt quy trình và chủ trì cuộc họp; tác giả (author) của tài liệu; người rà soát (reviewer) tìm lỗi; người ghi chép (scribe, recorder) ghi lại lỗi và vấn đề. Vì vậy i, ii, iii đều đúng, còn trợ lý quản lý (assistant manager) không phải vai trò được định nghĩa trong rà soát nên iv sai. "i,ii,iii,iv are true" sai vì nhận cả trợ lý quản lý. "ii,iii,iv are true and i is false." sai vì loại quản lý, trong khi quản lý là vai trò chính thức quyết định và cấp nguồn lực cho rà soát. "i,iv are true and ii, iii are false." sai nặng nhất vì bác cả người điều phối lẫn người ghi chép, hai vai trò cốt lõi của cuộc họp rà soát.

Đáp án đúng: "Designed by a person from a different organization". ISTQB sắp mức độc lập của kiểm thử từ thấp tới cao: chính tác giả tự kiểm thử, một người khác trong cùng nhóm, một người từ nhóm hay bộ phận khác trong tổ chức, rồi tới người từ tổ chức khác như công ty kiểm thử thuê ngoài hay đơn vị chứng nhận; người ngoài tổ chức ít chịu ảnh hưởng của áp lực nội bộ và thiên kiến của tác giả nhất, nên độc lập cao nhất. "Designed by persons who write the software under test" là mức thấp nhất vì tác giả dễ mù với lỗi của chính mình. "Designed by another person" chỉ là mức độc lập kế tiếp, vẫn có thể cùng nhóm, cùng chịu áp lực tiến độ. "Designed by a person from a different section" độc lập hơn vì khác bộ phận, nhưng vẫn cùng tổ chức nên chưa đạt mức cao nhấ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: "Mediates between people". Người điều phối (moderator) dẫn dắt quy trình rà soát: lập kế hoạch, chủ trì cuộc họp, giữ thảo luận đúng hướng và làm trung gian hòa giải giữa các quan điểm khác nhau, đặc biệt giữa tác giả và người rà soát, để buổi họp tập trung vào lỗi trong tài liệu chứ không thành chỉ trích cá nhân. "Takes minutes of the meeting" là việc của người ghi chép (scribe), người lưu lại lỗi và vấn đề được nêu. "Writes the documents to be reviewed" là vai trò tác giả (author), người không nên làm điều phối trong rà soát hình thức để giữ khách quan. "Takes telephone calls" không phải vai trò nào trong rà soát; cuộc họp rà soát cần tập trung và không có ai được giao việc nghe điện thoạ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: "Syntax testing". Chuẩn BS 7925-2 về kiểm thử thành phần chia kỹ thuật thành hai nhóm: hộp trắng (white box) dựa trên cấu trúc mã như statement testing, branch testing, data flow testing, và hộp đen (black box) dựa trên đặc tả như phân hoạch tương đương, giá trị biên, syntax testing. Syntax testing thiết kế ca kiểm thử từ cú pháp đầu vào đã đặc tả hình thức, không nhìn vào mã, nên không thuộc hộp trắng. Cần nói thẳng: "Random testing" cũng được BS 7925-2 xếp vào nhóm hộp đen, vì nó sinh đầu vào ngẫu nhiên theo phân bố của miền đầu vào chứ không dựa vào cấu trúc mã, nên xét chặt thì câu hỏi có hai phát biểu đúng; vì đề chỉ cho chọn một, đáp án chốt là syntax testing theo cách hiểu phổ biến nhất, còn random testing là phương án nhiễu rất sát. "Data Flow testing." là kỹ thuật hộp trắng, thiết kế ca theo cặp định nghĩa và sử dụng biến. "Statement testing" là kỹ thuật hộp trắng cơ bản nhất, nhắm cho mọi câu lệnh được thực thi.

Đáp án đúng: "Generating expected outputs". Câu hỏi dạng EXCEPT: cần tìm việc mà công cụ thực thi kiểm thử thương mại thông thường không làm được. Công cụ thực thi chạy và đối chiếu, nhưng kết quả mong đợi phải đến từ một nguồn hiểu đặc tả, tức test oracle như yêu cầu, người kiểm thử hay hệ thống tham chiếu; công cụ không tự biết đầu ra đúng là gì, đó là bài toán oracle. Các phát biểu kia đều là năng lực điển hình của công cụ nên không được chọn. "Replaying inputs according to a programmed script" đúng vì chạy lại kịch bản đã lập trình là chức năng cốt lõi. "Comparison of expected outcomes with actual outcomes" đúng vì công cụ so kết quả thực tế với kết quả mong đợi đã được cung cấp sẵn. "Recording test inputs" đúng vì kiểu record/playback ghi lại thao tác đầu vào. "Reading test values from a data file" đúng vì kiểm thử hướng dữ liệu (data-driven) đọc giá trị từ tệp dữ liệu.

Đáp án đúng: "Is a valuable source of project information during testing if it contains all incidents". Hệ thống ghi nhận sự cố (incident logging) lưu mọi sự kiện bất thường cần điều tra; khi nó đầy đủ, dữ liệu trong đó cho biết số khiếm khuyết theo mức độ, mật độ lỗi theo thành phần, tốc độ tìm và đóng lỗi, giúp quản lý theo dõi tiến độ, đánh giá rủi ro và quyết định phát hành, nên là nguồn thông tin dự án quý giá với điều kiện mọi sự cố đều được ghi. "Only records defects" sai vì sự cố gồm cả lỗi môi trường, lỗi ca kiểm thử, hiểu sai yêu cầu, không phải sự cố nào cũng là khiếm khuyết của phần mềm. "Is of limited value" sai vì nó là một trong những nguồn số đo quan trọng nhất của kiểm thử. "Should be used only by the test team." sai vì lập trình viên, trưởng dự án và các bên liên quan cũng dùng nó để sửa lỗi và ra quyết định.

Đáp án đúng: "Even though the numbers you look at appear better, to achieve these numbers, people are doing other aspects of their work much less well.". Rối loạn đo lường (measurement dysfunction) là hiện tượng khi một chỉ số được dùng để đánh giá con người, họ điều chỉnh hành vi cho chỉ số đẹp lên, nhưng cái giá là những phần việc không được đo bị làm kém đi; ví dụ chấm điểm người kiểm thử theo số lỗi tìm được thì họ báo nhiều lỗi vặt và né lỗi khó, con số tốt hơn mà chất lượng thực giảm. "We don't know how to measure a variable (our measurement is dysfunctional)" mô tả việc không biết cách đo, đó là vấn đề độ tin cậy của phép đo chứ không phải sự biến dạng hành vi do bị đo. "You are measuring the wrong thing and thus reaching the wrong conclusions." là lỗi chọn sai đại lượng dẫn tới kết luận sai, không nói tới việc con người làm tệ đi phần việc khác. "All of the others" sai vì hai mô tả kia không phải bản chất của rối loạn đo lường.

Đáp án đúng: "ISO 9126". ISO 9126 là chuẩn quốc tế về chất lượng sản phẩm phần mềm, định nghĩa mô hình sáu đặc tính chất lượng (chức năng, độ tin cậy, khả dụng, hiệu suất, khả năng bảo trì, khả chuyển) kèm các đặc tính con và số đo; sau này nó được thay bằng bộ ISO 25000 (SQuaRE). Các con số ở phương án nhiễu gợi tới những chuẩn IEEE khác chứ không phải chuẩn chất lượng sản phẩm. "ISO 829" mang số của IEEE 829, chuẩn về tài liệu kiểm thử phần mềm như kế hoạch, đặc tả và báo cáo kiểm thử. "ISO 1012" mang số của IEEE 1012, chuẩn về kiểm chứng và thẩm định (verification and validation). "ISO 1028" mang số của IEEE 1028, chuẩn về rà soát phần mềm như thanh tra, walkthrough, rà soát kỹ thuật. Không con số nào trong ba con số này là chuẩn chất lượng sản phẩm phần mềm.

Đáp án đúng: "Test boundary conditions on, below and above the edges of input and output equivalence classes". Kiểm thử giá trị biên (boundary value testing) là kỹ thuật hộp đen, mở rộng từ phân vùng tương đương: thay vì lấy một giá trị bất kỳ trong phân vùng, nó chọn các giá trị nằm đúng ở mép, ngay dưới và ngay trên mép của các lớp tương đương, áp dụng cho cả đầu vào lẫn đầu ra, vì lỗi hay tập trung ở biên như dùng nhầm dấu nhỏ hơn với nhỏ hơn hoặc bằng. "Is the same as equivalence partitioning tests" sai vì phân vùng tương đương chỉ cần một đại diện bất kỳ mỗi lớp, còn giá trị biên chọn có chủ đích ở mép lớp, hai kỹ thuật liên quan nhưng khác nhau. "Tests combinations of input circumstances" mô tả bảng quyết định hay đồ thị nhân quả, kỹ thuật xử lý tổ hợp điều kiện. "Is used in white box testing strategy" sai vì giá trị biên dựa trên đặc tả, thuộc nhóm hộp đen chứ không dựa vào cấu trúc mã.

Đáp án đúng: "i,ii,iii are true and iv is false". Theo ISTQB, kiểm thử thành phần (component testing) là cấp kiểm thử các phần nhỏ nhất có thể kiểm thử riêng, còn được gọi là kiểm thử đơn vị (unit testing), kiểm thử mô-đun (module testing) và kiểm thử chương trình (program testing), nên mục i, ii, iii đúng. Kiểm thử thành phần hệ thống (system component testing) không phải tên gọi chuẩn; nó lẫn lộn giữa cấp thành phần và cấp hệ thống, vốn là hai cấp kiểm thử khác nhau, nên mục iv sai. "i,ii,iii,iv are false" sai vì loại cả ba tên đồng nghĩa đã được thừa nhận. "i,ii,iv are true and iii is false" sai vì loại kiểm thử mô-đun, một tên gọi chuẩn, lại nhận mục iv không chuẩn. "All of them are true" sai vì đưa cả mục iv vào.

Đáp án đúng: "Viability". Chất lượng phần mềm được mô tả bằng các thuộc tính chất lượng trong các mô hình như McCall hay ISO/IEC 9126 (nay là ISO/IEC 25010), chẳng hạn tính đúng đắn, tính dùng được, tính tin cậy, tính bảo trì, tính tái sử dụng, tính khả chuyển. Viability (tính khả thi, khả năng tồn tại về mặt kinh doanh) là khái niệm đánh giá dự án hay sản phẩm có đáng đầu tư, có sinh lời hay không, không phải một thuộc tính chất lượng của bản thân phần mềm. "Correctness" là tính đúng đắn, mức phần mềm thoả đặc tả và đáp ứng mục tiêu người dùng, là một yếu tố chất lượng cốt lõi. "Usability" là tính dùng được, phần mềm dễ học, dễ thao tác đến đâu, thuộc nhóm đặc tính chất lượng trong ISO 9126. "Reusability" là tính tái sử dụng, mức thành phần có thể dùng lại ở hệ thống khác, có mặt trong nhóm yếu tố chất lượng của McCall.

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

Đáp án đúng: "A small team to establish the best way to use the tool". Theo ISTQB Foundation, khi đưa một công cụ mới vào tổ chức nên bắt đầu bằng dự án thí điểm (pilot project) với một nhóm nhỏ: tìm hiểu công cụ chi tiết, xác định cách nó khớp với quy trình hiện có, đặt ra cách dùng chuẩn, quy ước đặt tên và cách bảo trì, đánh giá lợi ích so với chi phí. Chỉ sau khi thí điểm thành công mới triển khai rộng. "Everyone who may eventually have some use for the tool" sai vì triển khai cho mọi người ngay khi chưa có cách dùng chuẩn dễ dẫn tới dùng lộn xộn và thất bại. "The independent testing team" không phải câu trả lời đúng vì việc thí điểm do một nhóm nhỏ được chọn đảm nhận, không gắn cứng với đội kiểm thử độc lập. "The vendor contractor to write the initial scripts" sai vì nhà cung cấp viết kịch bản thì tổ chức không tự học được cách dùng phù hợp với mình.

Đáp án đúng: "i,v,iv,ii,iii,vi". Quy trình review chính thức theo ISTQB Foundation gồm sáu bước theo thứ tự: lập kế hoạch (planning) chọn người, vai trò và tiêu chí; khởi động (kick-off) phát tài liệu, giải thích mục tiêu; chuẩn bị cá nhân (individual preparation) từng người tự đọc và ghi lỗi; họp review (review meeting) thảo luận, ghi nhận kết quả; làm lại (rework) tác giả sửa lỗi; theo dõi (follow-up) moderator kiểm tra việc sửa và tiêu chí kết thúc. Ứng với ký hiệu là i, v, iv, ii, iii, vi. "i,ii,iii,iv,v,vi" chỉ giữ thứ tự liệt kê, đặt họp review trước cả khởi động và chuẩn bị. "vi,i,ii,iii,iv,v" đặt theo dõi lên đầu, trong khi chưa có gì để theo dõi. "i,ii,iii,v,iv,vi" đặt khởi động và chuẩn bị cá nhân sau khi đã họp và làm lại, ngược với logic phải chuẩn bị trước khi họp.