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

Đá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: "Exhaustive testing". ISTQB Foundation nêu bảy nguyên tắc kiểm thử (testing principles), trong đó có nguyên tắc "exhaustive testing is impossible": kiểm thử vét cạn mọi tổ hợp đầu vào và điều kiện tiền đề là bất khả thi trừ ca rất tầm thường, nên phải dùng phân tích rủi ro và mức ưu tiên để khoanh vùng. Bản thân "Exhaustive testing" (kiểm thử vét cạn) vì vậy không phải nguyên tắc mà là điều nguyên tắc phủ nhận. "Early testing" (kiểm thử sớm) là nguyên tắc thật: bắt đầu kiểm thử càng sớm càng tốt trong vòng đời để lỗi được phát hiện khi sửa còn rẻ. "Defect clustering" (lỗi tập trung theo cụm) là nguyên tắc thật: phần lớn lỗi nằm trong một số ít mô-đun. "Pesticide paradox" (nghịch lý thuốc trừ sâu) cũng là nguyên tắc thật: chạy lặp lại cùng một bộ ca kiểm thử sẽ dần không tìm thêm lỗi mới, nên phải rà soát và bổ sung ca kiểm thử thường xuyên.

Đá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: "Improve software accuracy". Kiểm thử (testing) chỉ đo và phơi bày tình trạng của phần mềm: nó tìm ra khiếm khuyết và cung cấp thông tin, còn việc sửa mã để phần mềm chạy chính xác hơn là gỡ lỗi (debugging) do lập trình viên làm sau đó, nên bản thân việc chạy kiểm thử không làm độ chính xác tăng lên. "Find faults" là mục tiêu kinh điển của kiểm thử, nên kiểm thử chắc chắn giúp được việc này. "Check user friendliness." cũng nằm trong phạm vi kiểm thử, cụ thể là kiểm thử khả dụng (usability testing), một loại kiểm thử phi chức năng. "Assure quality" là chỗ dễ tranh cãi nhất: có quan điểm cho rằng chất lượng không thể kiểm thử mà ra (quality cannot be tested in), nên nói kiểm thử không đảm bảo được chất lượng cũng có lý; tuy vậy trong khung ISTQB kiểm thử được xếp là một hoạt động của đảm bảo chất lượng (quality assurance), giúp đánh giá và tạo niềm tin vào chất lượng, nên thứ kiểm thử rõ ràng không tự làm được vẫn là cải thiện độ chính xác, việc chỉ đạt được qua sửa lỗi.

Đáp án đúng: "Open, Assigned, Fixed, Closed". Vòng đời lỗi (bug life cycle, defect life cycle) mô tả các trạng thái mà một báo cáo lỗi đi qua: người kiểm thử phát hiện và ghi nhận lỗi nên lỗi ở trạng thái Open (mở, có nơi gọi New), trưởng nhóm duyệt rồi giao cho lập trình viên nên chuyển sang Assigned (đã giao), lập trình viên sửa xong thì đánh dấu Fixed (đã sửa), người kiểm thử chạy lại ca kiểm thử (kiểm thử xác nhận, retest) thấy lỗi không còn thì chuyển thành Closed (đóng); nếu lỗi vẫn còn thì mở lại (Reopened). "Open, Fixed, Assigned, Closed" sai vì lỗi chưa thể được sửa khi chưa giao cho ai chịu trách nhiệm. "Assigned, Open, Closed, Fixed" sai hai chỗ: không thể giao một lỗi chưa được ghi nhận, và không thể đóng lỗi trước khi sửa. "Assigned, Open, Fixed, Closed" tuy đặt Fixed trước Closed đúng thứ tự nhưng vẫn giao việc trước khi lỗi được mở.

Đáp án đúng: "Acceptance testing". Theo ISTQB Foundation, kiểm thử chấp nhận (acceptance testing) có nhiều dạng: kiểm thử chấp nhận của người dùng (UAT), kiểm thử chấp nhận vận hành (operational acceptance testing), kiểm thử chấp nhận theo hợp đồng và theo quy định (contract and regulation acceptance testing), cùng alpha và beta testing. Kiểm thử theo hợp đồng đối chiếu hệ thống với tiêu chí chấp nhận ghi trong hợp đồng, còn kiểm thử theo quy định đối chiếu với luật, chuẩn an toàn hay quy định của cơ quan quản lý, nên cả hai là một nhánh của cấp chấp nhận. "System testing" (kiểm thử hệ thống) kiểm tra toàn hệ thống theo đặc tả chức năng và phi chức năng, do đội kiểm thử thực hiện chứ không nhằm xác nhận nghĩa vụ hợp đồng. "Integration testing" (kiểm thử tích hợp) tập trung vào giao diện giữa các thành phần. "Smoke testing" (kiểm thử khói) chỉ là lượt chạy nhanh các chức năng chính để xem bản dựng có đủ ổn định cho kiểm thử sâu hơn không.

Đáp án đúng: "Stop when scheduled time for testing expires". Về nguyên tắc, ISTQB khuyên dừng kiểm thử theo tiêu chí kết thúc (exit criteria) dựa trên rủi ro và độ phủ đã đặt ra từ khi lập kế hoạch, vì kiểm thử vét cạn là không thể. Tuy vậy, trong các điều kiện cụ thể được nêu, chỉ hết thời gian theo lịch (hạn kiểm thử hoặc hạn phát hành) là điều kiện dừng được dùng thật trong dự án, và đây là cách trả lời kinh điển của câu hỏi này; đó cũng là chỗ dễ tranh cãi vì có người cho rằng không điều kiện nào đủ chuẩn. "Stop if 75% of the pre-defined number of errors is detected." không phải tiêu chí chuẩn: số lỗi tồn tại không biết trước nên một tỷ lệ phần trăm trên con số định sẵn không có cơ sở. "Stop when all the test cases execute with detecting few errors." cũng sai vì ít lỗi có thể chỉ do bộ ca kiểm thử yếu, không chứng tỏ phần mềm tốt. "None of the others" không được chọn vì điều kiện hết thời gian theo lịch vẫn là một điều kiện dừng hợp lệ trên thực tế.

Đáp án đúng: "Reducing test time". Khi phương pháp phát triển tốt hơn (rà soát yêu cầu, thiết kế cẩn thận, kiểm thử đơn vị kỹ), phần mềm bàn giao cho các pha kiểm thử chứa ít khiếm khuyết hơn; ít khiếm khuyết nghĩa là ít thất bại (failure) phải điều tra, ít báo cáo sự cố, ít vòng sửa rồi kiểm thử xác nhận (confirmation testing) và kiểm thử hồi quy (regression testing), nên tổng thời gian các pha kiểm thử giảm. "No change" sai vì thời gian kiểm thử không chỉ là chạy bộ ca cố định mà còn gồm các vòng lặp do lỗi sinh ra, và phần này co lại khi chất lượng tăng. "Increasing test time" đi ngược quan hệ trên: chất lượng tốt hơn không tạo thêm việc kiểm thử. "Can’t say" sai vì quan hệ giữa chất lượng đầu vào và công sức kiểm thử là rõ ràng, đây chính là lý do kiểm thử sớm và phòng ngừa khiếm khuyết được khuyến khích trong ISTQB.

Đáp án đúng: "Should be able to understand the source code.". Câu hỏi tìm phát biểu KHÔNG đúng về người kiểm thử hộp đen (black-box tester). Kiểm thử hộp đen là kỹ thuật dựa trên đặc tả: ca kiểm thử được suy ra từ yêu cầu và hành vi bên ngoài của hệ thống, người kiểm thử không cần nhìn vào cấu trúc bên trong, nên đòi hỏi hiểu mã nguồn là đặc điểm của kiểm thử hộp trắng (white-box), không phải hộp đen. "Should be able to understand a functional specification or requirements document" là phát biểu đúng, vì đặc tả chức năng và tài liệu yêu cầu chính là cơ sở kiểm thử (test basis) của kiểm thử hộp đen. "Is highly motivated to find faults" cũng đúng: người kiểm thử tốt mang tâm thế đi tìm lỗi chứ không đi chứng minh hệ thống chạy được. "Is creative to find the system’s weaknesses" đúng vì đoán lỗi (error guessing) và kiểm thử thăm dò cần óc sáng tạo để nghĩ ra tình huống làm hệ thống hỏng.

Đáp án đúng: "Driver". Khi kiểm thử thành phần (component testing), đơn vị cần kiểm thử thường chưa có mã gọi nó, nên lập trình viên viết một trình điều khiển (driver): đoạn mã thay cho thành phần gọi, có nhiệm vụ gọi hàm cần kiểm thử, truyền dữ liệu kiểm thử vào và nhận kết quả trả về để so sánh. Đó đúng là vai trò câu hỏi mô tả. "Stub" (hàm giả) làm chiều ngược lại: thay cho thành phần mà hàm đang kiểm thử gọi xuống, trả về giá trị dựng sẵn, nên nó được gọi chứ không đi gọi hàm. "Proxy" là mẫu thiết kế hay thành phần mạng làm trung gian chuyển tiếp lời gọi, không phải thuật ngữ cho mã gọi hàm để kiểm thử. "None of the others" sai vì đã có một thuật ngữ chính xác cho vai trò này là driver; trong kiểm thử tích hợp từ dưới lên (bottom-up), driver chính là thứ được dùng để gọi các mô-đun cấp thấp đã hoàn thành.

Đáp án đúng: "System Testing". Kiểm thử hệ thống (system testing) là cấp kiểm thử trên toàn bộ hệ thống đã tích hợp, kiểm tra cả yêu cầu chức năng lẫn phi chức năng như hiệu năng, bảo mật, tính dùng được, và thường chạy một bộ ca kiểm thử định sẵn để chứng minh với ban quản lý rằng hệ thống đáp ứng đặc tả. Mô tả trong câu hỏi khớp đúng định nghĩa này: toàn hệ thống, mọi loại yêu cầu, đối chiếu với specifications. "Validation Testing" là khái niệm rộng, hỏi xem sản phẩm có đúng là thứ người dùng cần hay không, không gắn riêng với việc kiểm toàn hệ thống theo đặc tả. "Integration Testing" chỉ kiểm giao diện và tương tác giữa các thành phần khi ghép lại, chưa phải toàn bộ hệ thống. "User Acceptance Testing" do người dùng thực hiện để quyết định có chấp nhận hệ thống hay không, căn cứ vào nhu cầu nghiệp vụ chứ không phải để kiểm đủ mọi yêu cầu cấu trúc và chất lượng trước ban quản lý.

Đáp án đúng: "Confirmation testing". Kiểm thử xác nhận (confirmation testing, còn gọi re-testing, kiểm thử lại) là chạy lại đúng những ca kiểm thử đã thất bại sau khi khiếm khuyết được sửa, để xác nhận khiếm khuyết gốc thật sự đã được loại bỏ; đây chính là tình huống câu hỏi mô tả. "Regression testing" là kiểm thử hồi quy: chạy lại các ca kiểm thử trên phần đã kiểm thử trước đó để phát hiện khiếm khuyết mới bị đưa vào hoặc bị lộ ra do thay đổi, tức là tìm tác dụng phụ ở chỗ khác chứ không kiểm tra lỗi gốc đã hết chưa. "Maintenance testing" là kiểm thử bảo trì, áp dụng khi hệ thống đang vận hành bị sửa đổi, chuyển đổi môi trường hoặc ngừng sử dụng; nó là một bối cảnh kiểm thử chứ không phải tên của việc chạy lại ca thất bại. "None of the above" sai vì đã có thuật ngữ khớp chính xác với mô tả.

Đáp án đúng: "Test Implementation and execution". Trong quy trình kiểm thử cơ bản (fundamental test process) của ISTQB, giai đoạn thực hiện và thực thi kiểm thử gồm tạo dữ liệu và bộ kiểm thử, chạy ca kiểm thử, ghi nhật ký, so sánh kết quả thực tế với kết quả mong đợi, báo cáo các sai khác (discrepancies) thành sự cố (incident) rồi kiểm thử lại sau khi sửa; sai khác được báo ngay lúc phát hiện nên việc này thuộc giai đoạn đó. "Test Analysis and Design" là giai đoạn rà soát cơ sở kiểm thử, xác định điều kiện kiểm thử và thiết kế ca kiểm thử, lúc đó chưa chạy gì nên chưa có sai khác để báo. "Evaluating exit criteria and reporting" đối chiếu nhật ký kiểm thử với tiêu chí kết thúc và viết báo cáo tổng hợp cho bên liên quan, không phải nơi ghi từng sự cố. "Test Closure Activities" là khâu đóng: kiểm tra sản phẩm bàn giao, lưu trữ testware, rút kinh nghiệm, diễn ra sau khi việc thực thi đã xong.

Đáp án đúng: "ii,iii,iv is true and i is false". ISTQB Foundation liệt kê nhiệm vụ điển hình của người kiểm thử (tester): rà soát và góp ý kế hoạch kiểm thử, phân tích và đánh giá yêu cầu về khả năng kiểm thử, tạo đặc tả kiểm thử (test specifications), thiết lập môi trường, chuẩn bị và thu thập dữ liệu kiểm thử (prepare and acquire test data), triển khai kiểm thử ở mọi cấp, thực thi và ghi nhật ký (implement tests on all test levels, execute and log), dùng công cụ và tự động hoá. Như vậy mục ii, iii, iv đều là việc của tester. Mục i, làm việc với nhà cung cấp công cụ để tìm cách khai thác công cụ tốt nhất cho dự án, thuộc nhiệm vụ của trưởng nhóm kiểm thử (test leader) vì gắn với quyết định quản lý và lựa chọn công cụ. "i, ii, iii is true and iv is false" sai vì nhận nhầm mục i và loại mục iv. "i is true and ii,iii,iv are false" đảo ngược hoàn toàn sự phân vai. "iii and iv is correct and i and ii are incorrect" bỏ sót mục ii, trong khi chuẩn bị dữ liệu kiểm thử là việc tester trực tiếp làm.

Đáp án đúng: "Breadth Test and Depth Test". Kiểm thử bảo trì (maintenance testing) diễn ra khi hệ thống đang vận hành bị sửa đổi, nâng cấp, chuyển môi trường hoặc gỡ bỏ. Cách tiếp cận của nó gồm hai chiều: kiểm thử theo chiều sâu (depth test) để kiểm kỹ chính phần vừa thay đổi, và kiểm thử theo chiều rộng (breadth test) để rà hồi quy trên các phần khác của hệ thống xem thay đổi có gây ảnh hưởng ngoài ý muốn hay không, phạm vi được quyết định qua phân tích tác động (impact analysis). "Re-testing" chỉ là việc chạy lại ca kiểm thử đã thất bại sau khi lỗi được sửa, là một hoạt động nằm bên trong chứ không phải phương pháp tổng thể. "Confirmation Testing" là tên gọi khác của re-testing, nên cũng chỉ là một phần của chiều sâu. "Sanity Testing" là phép kiểm nhanh xem bản dựng có đủ ổn định để kiểm tiếp hay không, không phải phương pháp riêng của kiểm thử bảo trì.

Đáp án đúng: "Available skills and experience in the proposed techniques.". Theo ISTQB, khi chọn cách tiếp cận kiểm thử (test approach) phải xét bối cảnh: rủi ro thất bại của dự án và sản phẩm, kỹ năng và kinh nghiệm của con người với kỹ thuật, công cụ, phương pháp đề xuất, mục tiêu kiểm thử, quy định pháp lý và bản chất sản phẩm; trong các yếu tố được nêu ở đây, kỹ năng và kinh nghiệm sẵn có quyết định trực tiếp việc kỹ thuật có áp dụng được hiệu quả hay không. "Availability of tools to support the proposed techniques." là yếu tố phụ: công cụ chỉ hỗ trợ, thiếu người biết dùng kỹ thuật thì công cụ không cứu được. "The budget allowed for training in proposed techniques." chỉ là cách bù đắp khi thiếu kỹ năng, không phải tiêu chí trung tâm. "The willingness of the test team to learn new techniques." là thái độ đáng quý nhưng không bảo đảm năng lực thực hiện ngay trong dự án hiện tại.

Đáp án đúng: "Done by an Entity Outside the Project’s sphere of influence". Thẩm định và xác nhận độc lập (Independent Verification and Validation, IV&V) là việc kiểm tra sản phẩm có làm đúng đặc tả (verification) và có đáp ứng nhu cầu sử dụng (validation) hay không, do một bên độc lập với dự án về kỹ thuật, quản lý và tài chính thực hiện; theo thang mức độc lập của ISTQB, mức cao nhất là người kiểm thử đến từ bên ngoài tổ chức, giúp tránh định kiến của người làm ra sản phẩm. "Done by the Developer" là mức độc lập thấp nhất, tác giả tự kiểm tra sản phẩm của chính mình. "Done by the Test Engineers" chỉ độc lập một phần khi họ vẫn thuộc dự án, chịu cùng áp lực tiến độ và báo cáo cho cùng quản lý dự án. "Done By Management" không đúng vì ban quản lý dự án là bên chịu trách nhiệm tiến độ và chi phí, chính là thứ IV&V phải đứng ngoài để giữ khách quan.

Đáp án đúng: "ii , iii are true and i is false". Trình điều khiển kiểm thử (driver) là mã thay cho thành phần gọi, dùng để gọi thành phần đang kiểm thử và truyền dữ liệu vào. Trong thuật ngữ kiểm thử, driver cùng với stub tạo thành môi trường giàn giáo bao quanh thành phần, nên driver còn được gọi là test harness (giàn kiểm thử, bộ khung chứa driver, stub và dữ liệu để chạy kiểm thử) và scaffolding (giàn giáo, mã phụ trợ dựng tạm để chạy kiểm thử rồi bỏ đi). Vì thế mục ii và iii đúng. Mục i, "Spade", không phải thuật ngữ nào trong kiểm thử phần mềm cả. "i , ii are true and iii is false" sai vì nhận Spade và loại scaffolding. "i , iii are true and ii is false" sai vì nhận Spade và loại test harness. "All of i, ii and iii are true" sai vì Spade không phải tên gọi khác của driver.

Đá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: "Test Analysis and Design". Trong quy trình kiểm thử cơ bản (Fundamental Test Process) của ISTQB, nhiệm vụ đầu tiên của pha phân tích và thiết kế kiểm thử là rà soát cơ sở kiểm thử (test basis) như yêu cầu, kiến trúc, thiết kế, giao diện, đánh giá khả năng kiểm thử của chúng, rồi xác định điều kiện kiểm thử và thiết kế ca kiểm thử. "Test Implementation and execution" diễn ra sau đó, khi ca kiểm thử đã có: xây quy trình kiểm thử, chuẩn bị dữ liệu, môi trường, chạy kiểm thử và ghi kết quả. "Test Closure Activities" là pha kết thúc: lưu trữ testware, bàn giao, rút kinh nghiệm, không quay lại đọc cơ sở kiểm thử. "Evaluating exit criteria and reporting" là đối chiếu kết quả chạy với tiêu chí thoát và viết báo cáo tổng kết, cũng không phải lúc rà soát tài liệu đầu vào.