Tất cả câu hỏi

Đá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: "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: "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: "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: "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: "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: "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: "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: "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: "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: "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: "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,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: "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: "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: "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: "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: "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: "It offers seamless integration with relational databases, NoSQL stores, and JPA". Spring Boot hỗ trợ truy cập dữ liệu rất rộng: có starter cho JDBC với JdbcTemplate, cho Data JPA với Hibernate, cho các kho NoSQL như MongoDB, Redis, Cassandra, và tự cấu hình DataSource, EntityManagerFactory hay client tương ứng dựa trên thư viện có trong classpath cùng thuộc tính trong application.properties, đều tích hợp với Spring Data. "It only supports relational databases via raw JDBC" sai vì ngoài JDBC thuần Spring Boot còn hỗ trợ JPA và NoSQL. "It excludes JPA to encourage NoSQL usage" sai vì JPA chính là một trong những lựa chọn chủ lực qua spring-boot-starter-data-jpa. "It requires a custom driver for each vendor and does not integrate with Spring Data" sai ở cả hai vế: Spring Boot dùng driver JDBC chuẩn của nhà cung cấp, thường tự nhận ra driver từ URL kết nối, và tích hợp chặt với Spring Data.

Đáp án đúng: "Relational databases using the Java Persistence API (JPA).". Spring Data JPA là mô-đun của họ Spring Data dành cho cơ sở dữ liệu quan hệ: nó dựa trên JPA (đặc tả ánh xạ đối tượng – quan hệ của Java) và provider như Hibernate để ánh xạ entity sang bảng, rồi bổ sung repository tự sinh, truy vấn suy từ tên phương thức, phân trang và auditing, giảm mạnh mã truy cập dữ liệu lặp lại. "NoSQL databases." sai vì kho NoSQL có các mô-đun riêng như Spring Data MongoDB hay Spring Data Redis, không đi qua JPA. "Message queues." sai vì hàng đợi thông điệp dùng Spring AMQP, Spring for Apache Kafka hoặc JMS. "Cloud storage." sai vì lưu trữ đám mây như S3 dùng SDK của nhà cung cấp hoặc Spring Cloud AWS, nằm ngoài phạm vi Spring Data JPA.