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

Đáp án đúng: "To give information for a risk based decision about release". Theo ISTQB, kiểm thử không chứng minh được phần mềm hết lỗi; giá trị chính của nó trước khi phát hành là cung cấp thông tin về chất lượng và mức rủi ro còn lại để người có thẩm quyền (chủ sản phẩm, quản lý) ra quyết định phát hành dựa trên rủi ro. "To show that system will work after release" sai vì kiểm thử chỉ cho thấy sự có mặt của lỗi chứ không chứng minh được hệ thống chắc chắn chạy đúng. "To decide when the software is of sufficient quality to release" sai vì quyết định phát hành thuộc về bên liên quan; kiểm thử cung cấp dữ liệu cho quyết định đó chứ không tự quyết. "To find as many bugs as possible before release" là một mục tiêu của kiểm thử nhưng không phải lý do chính trước phát hành: tìm thật nhiều lỗi vẫn không cho biết rủi ro còn lại có chấp nhận được hay không, và kiểm thử vét cạn là không thể.

Đáp án đúng: "i,ii,iii are correct and iv is incorrect". Theo ISTQB Foundation, theo dõi tiến độ kiểm thử (test progress monitoring) dùng các số đo như tỉ lệ công việc chuẩn bị ca kiểm thử, tỉ lệ công việc chuẩn bị môi trường kiểm thử, tỉ lệ ca kiểm thử đã thực thi (đạt, không đạt, chưa chạy), thông tin về lỗi như mật độ lỗi (defect density), số lỗi tìm thấy và đã sửa, độ phủ, mốc thời gian và chi phí. Mục i, ii, iii đều thuộc danh sách đó. Mục iv, quy mô đội kiểm thử và kỹ năng của kỹ sư, là đầu vào của lập kế hoạch và ước lượng nhân lực, không cho biết công việc đã tiến tới đâu. "iv is correct and i,ii,iii are incorrect" đảo ngược hoàn toàn. "i,ii are correct and iii,iv are incorrect" bỏ sót thông tin lỗi, vốn là chỉ số tiến độ quan trọng. "i,iv are correct and ii , iii are incorrect" nhận nhầm mục iv và bỏ sót tiến độ chuẩn bị môi trường cùng thông tin lỗi.

Đá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: "ii & iii are true, i, iv & v are false.". Lập kế hoạch kiểm thử (test planning) xác định phạm vi, rủi ro, mục tiêu, cách tiếp cận tổng thể, lịch, tiêu chí thoát và phân bổ nguồn lực, nên mục ii (xác định cách tiếp cận tổng thể) và mục iii (phân công nguồn lực) thuộc kế hoạch. Viết điều kiện kiểm thử và phát triển ca kiểm thử thuộc pha phân tích và thiết kế (rồi hoàn thiện ở pha triển khai), còn dựng môi trường kiểm thử thuộc pha triển khai và thực thi, nên mục i, iv, v không thuộc kế hoạch. "i, ii & iv are true, iii & v are false." sai vì coi phát triển ca kiểm thử và dựng môi trường là lập kế hoạch, lại loại việc phân công nguồn lực. "iv & v are true, i, ii & iii are false." đảo ngược hoàn toàn, loại cả hai hoạt động lập kế hoạch thật. "i, ii & iii are true iv & v are false." đúng hai mục nhưng gộp nhầm việc phát triển ca kiểm thử.

Đáp án đúng: "Driver". Khi kiểm thử một thành phần riêng lẻ mà mô-đun gọi nó chưa có, lập trình viên viết một driver (trình điều khiển): đoạn mã đứng ở vị trí bên gọi, 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ả để so sánh với kết quả mong đợi; driver được dùng nhiều trong tích hợp từ dưới lên. "Stub" là chiều ngược lại: nó thay thế cho thành phần mà hàm đang kiểm thử gọi tới, chỉ trả về giá trị giả định đơn giản, dùng nhiều trong tích hợp từ trên xuống. "Proxy" là mẫu thiết kế hay thành phần trung gian chuyển tiếp lời gọi tới một đối tượng khác, không phải thuật ngữ kiểm thử chỉ đoạn mã gọi thành phần đang kiểm thử. "None of the others" sai vì driver chính là thứ câu hỏi mô tả.

Đáp án đúng: "Lack of Objectivity". ISTQB Foundation nhấn mạnh tâm lý học kiểm thử: người viết ra sản phẩm thường mang sẵn giả định về cách nó hoạt động và có tâm lý muốn chứng minh nó đúng, nên khó nhìn ra lỗi của chính mình. Sự thiếu khách quan (lack of objectivity) này là lý do chính để cần kiểm thử độc lập (independent testing). "Lack of technical documentation" không phải lý do then chốt, vì chính lập trình viên là người hiểu mã rõ nhất, thiếu tài liệu ảnh hưởng tới người khác nhiều hơn tới họ. "Lack of test tools on the market for developers" sai vì có rất nhiều công cụ cho lập trình viên như khung kiểm thử đơn vị, công cụ đo độ phủ. "Lack of training" có thể xảy ra ở từng người nhưng không phải nguyên nhân cốt lõi, vì kể cả lập trình viên được đào tạo kiểm thử tốt vẫn bị điểm mù khi tự kiểm thử sản phẩm của mình.

Đáp án đúng: "Tool support for test execution and logging.". Bộ so sánh kiểm thử (test comparator) là công cụ tự động đối chiếu kết quả thực tế với kết quả mong đợi, chẳng hạn so sánh tệp, cơ sở dữ liệu hay màn hình đầu ra; ISTQB Foundation xếp nó vào nhóm công cụ hỗ trợ thực thi và ghi nhật ký kiểm thử, cùng với công cụ thực thi kiểm thử, test harness, unit test framework và công cụ đo độ phủ, vì việc so sánh diễn ra ngay khi chạy ca kiểm thử và kết quả được ghi lại. "Tool support for performance and monitoring." gồm công cụ kiểm thử tải, hiệu năng, theo dõi tài nguyên, không có chức năng đối chiếu kết quả. "Tool support for static testing." gồm công cụ hỗ trợ review, phân tích tĩnh, mô hình hoá, làm việc khi chưa chạy chương trình nên không có kết quả thực tế để so sánh. "Tool support for the management of testing and tests." gồm công cụ quản lý kiểm thử, quản lý yêu cầu, quản lý sự cố, quản lý cấu hình.

Đáp án đúng: "Analyze your needs and requirements". Theo ISTQB, đưa công cụ kiểm thử vào tổ chức bắt đầu bằng việc đánh giá mức trưởng thành của tổ chức và phân tích nhu cầu, xác định yêu cầu rõ ràng mà công cụ phải đáp ứng; chỉ khi biết mình cần gì mới đánh giá nhà cung cấp, làm thử nghiệm khái niệm (proof of concept) và dự trù chi phí. "Attend a tool exhibition" là cách tìm hiểu thị trường, hữu ích ở bước khảo sát sau khi đã có yêu cầu, nếu đi trước dễ bị cuốn theo tính năng hào nhoáng. "Invite a vendor to give a demo" thuộc bước đánh giá nhà cung cấp, chưa có yêu cầu thì không biết xem demo để so với cái gì. "Find out what your budget would be for the tool" cần làm nhưng ngân sách phải dựa trên nhu cầu và lợi ích dự kiến. "Search the internet" cũng chỉ là khảo sát lựa chọn, không phải điểm xuất phát.

Đáp án đúng: "User requirements.". Công cụ ghi và phát lại (capture and replay) ghi các thao tác trên giao diện như nhấp chuột, gõ phím thành kịch bản để chạy lại tự động nhiều lần, nên hợp với "GUI testing", với kiểm thử hồi quy, và với "Performance testing" khi kịch bản đã ghi được nhân lên thành nhiều người dùng ảo để tạo tải. "User requirements." không phải một hoạt động kiểm thử chạy được bằng ghi rồi phát lại: yêu cầu người dùng là tài liệu, được thẩm định bằng rà soát và kiểm thử chấp nhận với người dùng thật, nên đây là chỗ ghi-phát lại ít dùng nhất. Có ý kiến chọn "Recovery testing" vì kiểm thử phục hồi phải cố ý gây sự cố như ngắt điện, rút mạng, điều mà công cụ ghi thao tác không tạo ra được; lập luận đó có lý, nhưng sau khi gây sự cố, kịch bản ghi sẵn vẫn được phát lại để xác nhận hệ thống khôi phục đúng, còn với yêu cầu người dùng thì gần như không có chỗ dùng.

Đá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: "(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: "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: "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: "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: "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: "Management". Rà soát kỹ thuật (technical review) là buổi thảo luận giữa đồng nghiệp và chuyên gia kỹ thuật nhằm đạt đồng thuận về nội dung kỹ thuật và tìm khiếm khuyết; ISTQB mô tả nó có thể thực hiện như rà soát đồng cấp (peer review) không có sự tham gia của quản lý, vì sự có mặt của quản lý khiến người tham gia ngại nêu vấn đề và dễ biến buổi rà soát thành đánh giá con người. "Analysts" là người viết hoặc hiểu sâu yêu cầu, thường tham gia rà soát kỹ thuật tài liệu yêu cầu và thiết kế. "Developers" là đồng nghiệp kỹ thuật cốt lõi, rà soát mã và thiết kế của nhau. "Testers" tham gia để kiểm tra khả năng kiểm thử và phát hiện mâu thuẫn trong sản phẩm được rà soát, cũng là thành phần kỹ thuật bình thường.

Đáp án đúng: "Verification activities should not involve testers (reviews, inspections etc)". Phát biểu này sai vì ISTQB Foundation khuyến khích người kiểm thử tham gia hoạt động kiểm chứng (verification) như rà soát và thanh tra ngay từ sớm: họ góp góc nhìn về khả năng kiểm thử, phát hiện yêu cầu mơ hồ và học sản phẩm để thiết kế kiểm thử tốt hơn, đúng nguyên tắc kiểm thử sớm. Câu hỏi tìm phát biểu không đúng nên đây là đáp án. "Performance testing can be done during unit testing as well as during the testing of whole system" là đúng, vì kiểm thử hiệu năng có thể áp ở cấp đơn vị, ví dụ đo thời gian một thuật toán, lẫn cấp hệ thống. "The acceptance test does not necessarily include a regression test" cũng đúng, vì mục tiêu kiểm thử chấp nhận là xây dựng niềm tin và xác nhận sẵn sàng triển khai, hồi quy không bắt buộc phải nằm trong đó. "Test environments should be as similar to production environments as possible" đúng, vì môi trường càng giống thực tế càng giảm rủi ro lỗi chỉ lộ ra khi vận hành.

Đá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: "A failure". Trong chuỗi thuật ngữ của ISTQB, con người phạm sai lầm (error hay mistake), sai lầm đó tạo ra khiếm khuyết nằm trong mã hoặc tài liệu (defect, fault, bug), và khi đoạn mã khiếm khuyết được thực thi thì hệ thống có thể lệch khỏi hành vi mong đợi, sự lệch quan sát được ấy là thất bại (failure); câu hỏi nhấn vào thứ người dùng cuối nhìn thấy nên đó là failure. "An error" là hành động sai của con người, xảy ra trong đầu người viết chứ không phải thứ người dùng thấy. "A mistake" là từ đồng nghĩa với error nên bị loại cùng lý do. "A fault" là khiếm khuyết nằm tĩnh trong mã, có thể tồn tại mà chưa bao giờ lộ ra. "A defect" cũng là khiếm khuyết trong sản phẩm, nguyên nhân của thất bại chứ không phải biểu hiện bên ngoài.