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

Đáp án đúng: "i, ii and iv.". Theo ISTQB Foundation, quản lý cấu hình (configuration management) phục vụ kiểm thử ở chỗ giúp xác định duy nhất, kiểm soát phiên bản và theo dõi thay đổi của mọi hạng mục: phần mềm được kiểm (nhờ đó biết đang kiểm phiên bản nào, mục i) và testware như kế hoạch, ca kiểm thử, kịch bản, dữ liệu (kiểm soát phiên bản ở mục ii, theo dõi thay đổi ở mục iv), để kết quả kiểm thử truy vết được về đúng phiên bản. Mục iii, phát triển testware mới, là việc thiết kế và hiện thực kiểm thử; mục v, phân tích nhu cầu testware mới, là việc phân tích và lập kế hoạch kiểm thử; cả hai không phải mục đích của quản lý cấu hình. "ii, iv and v." sai vì có mục v và thiếu mục i. "ii, iii and iv." sai vì có mục iii và thiếu mục i. "i, iii and v." sai vì chứa hai mục không thuộc quản lý cấu hình và bỏ sót kiểm soát phiên bản, theo dõi thay đổi testware.

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

Đáp án đúng: "Requirement Analysis". Quy trình kiểm thử cơ bản (Fundamental Test Process) trong ISTQB gồm năm nhóm hoạt động: lập kế hoạch và kiểm soát, phân tích và thiết kế, triển khai và thực thi, đánh giá tiêu chí thoát và báo cáo, kết thúc kiểm thử. Phân tích yêu cầu là hoạt động của vòng đời phát triển phần mềm do người phân tích nghiệp vụ thực hiện để xác định hệ thống phải làm gì; kiểm thử có thể rà soát tài liệu yêu cầu nhưng đó là rà soát cơ sở kiểm thử chứ không phải một pha mang tên phân tích yêu cầu. "Test Planning and Control" là pha đầu tiên, đặt mục tiêu và theo dõi tiến độ. "Test implementation and Execution" là pha xây quy trình kiểm thử và chạy kiểm thử. "Evaluating Exit criteria and reporting" là pha đối chiếu kết quả với tiêu chí thoát và báo cáo cho các bên liên quan.

Đáp án đúng: "Configuration Control". Quản lý cấu hình (configuration management) gồm các hoạt động nhận diện cấu hình, kiểm soát cấu hình, ghi nhận trạng thái và kiểm toán cấu hình. Kiểm soát cấu hình (configuration control) bao gồm việc cung cấp và quản lý một thư viện có kiểm soát (controlled library) chứa mọi hạng mục cấu hình, cùng việc đánh giá, phê duyệt và thực hiện thay đổi lên các hạng mục đó, bảo đảm không ai sửa phiên bản đã được chấp thuận mà không qua quy trình. "Status Accounting" (ghi nhận trạng thái) là ghi chép và báo cáo tình trạng của các hạng mục cùng các yêu cầu thay đổi, chẳng hạn phiên bản nào đang dùng ở đâu, thay đổi nào đã duyệt, không phải việc quản lý thư viện. "Configuration Identification" (nhận diện cấu hình) là chọn ra các hạng mục cấu hình, đặt tên, đánh số phiên bản và xác lập baseline, tức bước xác định cái gì cần quản lý chứ chưa phải lưu giữ và kiểm soát chúng.

Đáp án đúng: "The objective of the test". Theo ISTQB Foundation, việc chọn kỹ thuật kiểm thử (test technique) chịu tác động của nhiều yếu tố như loại hệ thống, rủi ro, yêu cầu hợp đồng, kinh nghiệm người kiểm thử, thời gian và công cụ, nhưng điểm xuất phát luôn là lần kiểm thử này nhằm đạt điều gì: muốn phủ các biên dữ liệu thì chọn phân tích giá trị biên, muốn phủ tổ hợp điều kiện thì chọn bảng quyết định, muốn phủ nhánh mã thì chọn kỹ thuật hộp trắng. Chỗ gây tranh cãi là "How appropriate the technique is for testing the application": có bản lưu hành của câu này chấm nó là đúng, và mức độ phù hợp với ứng dụng quả thật là một yếu tố cần cân nhắc, nhưng "phù hợp" chỉ đánh giá được sau khi đã biết mục tiêu kiểm thử, nên nó là hệ quả chứ không phải tiêu chí gốc. "How well you know a particular technique" là độ quen tay của cá nhân, dễ dẫn tới chọn kỹ thuật mình thích thay vì kỹ thuật cần dùng. "Whether there is a tool to support the technique" chỉ là điều kiện hỗ trợ việc thực thi, không quyết định nên kiểm thử theo hướng nào.

Đá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: "(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: "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: "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: "All of the others". Mô hình tăng trưởng độ tin cậy thống kê (statistical reliability model) dự báo tốc độ tìm lỗi theo thời gian, ví dụ kỳ vọng nhiều lỗi lúc đầu rồi giảm dần, và nếu quản lý lịch dự án bám vào đường cong đó thì phát sinh nhiều rủi ro; cả ba phát biểu đều là rủi ro thật nên phương án gộp đúng. Phát biểu "Testers spend more energy early in the product trying to find bugs" đúng: để khớp đường cong dự báo, tester dồn sức tìm lỗi sớm thay vì chuẩn bị làm phần còn lại của dự án hiệu quả hơn, nhưng nó chỉ là một rủi ro nên chọn riêng nó là thiếu. Phát biểu "Managers might not realize that the testing effort is ineffective" đúng: cuối dự án quản lý vốn chờ tỉ lệ tìm lỗi thấp, nên tỉ lệ thấp do kiểm thử kém hiệu quả không làm họ cảnh giác; chọn riêng nó cũng thiếu. Phát biểu "increase the end-of-project pressure on testers to not find bugs" đúng: khi lịch phụ thuộc vào việc đường cong đi xuống, tester bị áp lực không tìm hoặc không báo lỗi; chọn riêng nó cũng bỏ sót hai rủi ro kia.

Đáp án đúng: "Error Guessing". Đoán lỗi (error guessing) là kỹ thuật dựa trên kinh nghiệm: người kiểm thử dựa vào hiểu biết về những lỗi hay gặp, những chỗ hệ thống từng hỏng, để thiết kế ca kiểm thử nhắm vào đó. ISTQB nêu các kỹ thuật dựa trên kinh nghiệm thường được dùng để bổ sung cho các kỹ thuật hình thức, có hệ thống (đặc tả hay cấu trúc), vì chúng bắt được những lỗi mà cách tiếp cận chặt chẽ bỏ sót. "Regression testing" là chạy lại ca kiểm thử sau thay đổi, một loại kiểm thử liên quan đến thay đổi chứ không phải thứ bổ sung cho kiểm thử chặt chẽ. "Integration testing." là một cấp kiểm thử kiểm giao diện giữa các thành phần, bản thân nó cần được thực hiện chặt chẽ. "System testing." cũng là một cấp kiểm thử trên toàn hệ thống, không phải kỹ thuật dùng để lấp chỗ hổng của kỹ thuật hình thức.

Đáp án đúng: "i is true and ii,iii,iv are false". Kiểm chứng (verification) trả lời câu hỏi chúng ta có xây sản phẩm đúng cách không, tức đối chiếu sản phẩm làm ra với đặc tả và tiêu chuẩn, nên nó giúp kiểm tra chất lượng của sản phẩm đã xây (mục i). Mục ii nói xây đúng sản phẩm, đó là định nghĩa của thẩm định (validation), kiểm tra sản phẩm có đáp ứng nhu cầu thật của người dùng không. Mục iii nói giúp phát triển sản phẩm, nhưng verification là hoạt động đánh giá chứ không phải hoạt động phát triển, và mục iv về hao phí công cụ thì không liên quan. "i,ii,iii are true and iv is false" là phương án một số nguồn chấm đúng, nhưng nó gộp nhầm validation vào verification và coi hoạt động đánh giá là hoạt động phát triển, nên không đứng được. "Options i,ii,iii,iv are true." còn thêm cả mục iv vô can. "ii is true and i,iii,iv are false." chọn đúng mục thuộc validation và loại mục duy nhất thuộc verification.

Đáp án đúng: "De-bugging.". Quản lý kiểm thử (test management) bao gồm lập kế hoạch và ước lượng, giám sát và điều khiển, quản lý rủi ro, quản lý sự cố và quản lý cấu hình; gỡ lỗi (debugging) là hoạt động phát triển, do lập trình viên tìm nguyên nhân lỗi, sửa mã và kiểm tra bản sửa, không phải trách nhiệm của quản lý kiểm thử nên kém quan trọng nhất trong bối cảnh này. "Estimating test duration." là ước lượng thời gian kiểm thử, phần cốt lõi của lập kế hoạch giúp bố trí lịch và nguồn lực. "Incident Management" theo dõi sự cố từ lúc phát hiện tới khi đóng, cung cấp số liệu cho giám sát tiến độ và quyết định phát hành. "Configuration Management." bảo đảm biết chính xác phiên bản phần mềm và testware đang được kiểm thử, để kết quả kiểm thử truy vết và tái lập được.

Đáp án đúng: "Missing Statements". Độ phủ câu lệnh (statement coverage) đo tỉ lệ câu lệnh có trong mã đã được thực thi bởi bộ ca kiểm thử. Vì nó chỉ đo những gì đang tồn tại trong mã, nó không thể phát hiện câu lệnh bị thiếu: một phép kiểm tra hay một xử lý mà lập trình viên quên viết thì không có dòng nào để đánh dấu là chưa chạy, nên độ phủ vẫn có thể đạt 100%. Muốn phát hiện thiếu sót này phải đối chiếu với đặc tả bằng kỹ thuật hộp đen hoặc rà soát. "Unused Branches" thì phân tích độ phủ câu lệnh vẫn làm lộ ra khi phần thân của nhánh đó chưa từng được thực thi. "Dead Code" (mã chết) luôn hiện ra là không được phủ, vì không ca kiểm thử nào chạy tới được. "Unused Statement" cũng hiện ngay trong báo cáo độ phủ như dòng chưa thực thi, nên đây đúng là thứ độ phủ câu lệnh kiểm tra được.

Đáp án đúng: "Dynamic analysis tool". Theo ISTQB Foundation, công cụ phân tích động (dynamic analysis tool) theo dõi chương trình khi đang chạy để phát hiện lỗi chỉ lộ ra lúc thực thi, như rò rỉ bộ nhớ (memory leak), con trỏ chưa gán hoặc trỏ sai (unassigned pointers) và lỗi số học con trỏ. Rò rỉ bộ nhớ phụ thuộc đường đi thực tế và vòng đời cấp phát, nên phải quan sát lúc chạy mới đánh dấu chính xác được. "Static Analysis tool." phân tích mã mà không chạy nó, tìm được biến chưa định nghĩa, mã chết, vi phạm chuẩn lập trình, nhưng không bắt được rò rỉ bộ nhớ một cách tin cậy. "Maintenance tool." không phải nhóm công cụ kiểm thử nào trong phân loại của ISTQB. "Configuration tool." thường chỉ công cụ quản lý cấu hình, dùng để lưu vết phiên bản và bản dựng của phần mềm, testware, chứ không giám sát bộ nhớ khi chạy.

Đáp án đúng: "Black-box testing". Kiểm thử hộp đen (black-box testing) thiết kế ca kiểm thử từ đặc tả chức năng mà không cần biết cấu trúc bên trong, với mục đích chứng minh từng chức năng của chương trình hoạt động đúng: đưa đầu vào, quan sát đầu ra, đối chiếu với yêu cầu. Định nghĩa trong câu hỏi, lập ca kiểm thử để chứng minh mỗi chức năng đều vận hành được, chính là định nghĩa kinh điển của kiểm thử hộp đen. "Glass-box testing" là tên gọi khác của kiểm thử hộp trắng, dựa vào cấu trúc mã để phủ câu lệnh, nhánh, đường đi chứ không xuất phát từ chức năng. "White-box testing" cũng vậy, mục tiêu là kiểm các đường logic bên trong. "Grey-box testing" kết hợp hiểu biết một phần cấu trúc bên trong với góc nhìn chức năng, không phải kỹ thuật thuần tuý dựa vào chức năng như câu hỏi mô tả.

Đáp án đúng: "Test data.". ISTQB nói lượng kiểm thử cần làm (how much testing is enough) phụ thuộc vào mức độ rủi ro, gồm rủi ro kỹ thuật, an toàn và kinh doanh, cùng các ràng buộc của dự án như thời gian, ngân sách và yêu cầu hợp đồng, pháp lý. Dữ liệu kiểm thử chỉ là đầu vào dùng để chạy các ca kiểm thử đã quyết định làm, nó được chuẩn bị theo khối lượng kiểm thử chứ không quyết định khối lượng đó. "Risks involved" là yếu tố quyết định quan trọng nhất: chỗ rủi ro cao phải kiểm thử kỹ hơn. "Contractual requirements" quyết định lượng kiểm thử vì hợp đồng có thể ấn định mức độ phủ hay loại kiểm thử bắt buộc. "Legal requirements" cũng vậy: các quy định pháp lý, ví dụ trong ngành y tế, hàng không, buộc phải đạt mức kiểm thử nhất định.

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