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

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

Đáp án đúng: "Inexpensive way to get some benefit". Rà soát không chính thức (informal review) không có quy trình định sẵn, không bắt buộc ghi biên bản, có thể chỉ là một đồng nghiệp đọc lại tài liệu hoặc lập trình đôi; ISTQB nêu mục tiêu chính của nó là một cách rẻ để thu được một phần lợi ích của việc rà soát. "Find defects" là mục tiêu chính của thanh tra (inspection), loại rà soát hình thức nhất. "Learning, gaining understanding, effect finding" là mục tiêu của duyệt qua (walkthrough), nơi tác giả trình bày để mọi người học hỏi và hiểu tài liệu. "Discuss, make decisions, solve technical problems" là mục tiêu của rà soát kỹ thuật (technical review), nơi các chuyên gia thảo luận, đạt đồng thuận và chọn phương án kỹ thuật.

Đáp án đúng gồm hai ý: "Static analysis need not be performed before imperative code is executed" và "Static analysis can find faults that are hard to find with dynamic testing.". Phân tích tĩnh (static analysis) là việc công cụ khảo sát mã nguồn hoặc mô hình mà không chạy chương trình; vì không phụ thuộc vào việc chạy, nó có thể làm trước, song song hay sau khi mã được thực thi chứ không bắt buộc phải xong trước, và nó tìm được những lỗi mà kiểm thử động khó chạm tới như biến dùng trước khi gán giá trị, mã không bao giờ chạy tới, vi phạm chuẩn lập trình, lỗ hổng bảo mật hay độ phức tạp quá cao. "Compiling code is not a form of static analysis" sai vì trình biên dịch chính là một dạng phân tích tĩnh: nó kiểm tra cú pháp, kiểu dữ liệu, biến chưa khai báo mà không chạy chương trình. Phát biểu "Extensive statistical analysis will not be needed if white- Box testing is to be performed." sai vì kiểm thử hộp trắng là kiểm thử động, chạy mã để đo độ phủ, nên không thay được việc phân tích mã khi không chạy; hai cách bổ sung cho nhau chứ không loại trừ nhau.

Đá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: "Memory leaks". Phân tích tĩnh (static analysis) xem xét mã nguồn mà không chạy chương trình, dựa trên luồng điều khiển và luồng dữ liệu. Rò rỉ bộ nhớ (memory leak) phụ thuộc vào việc cấp phát và giải phóng diễn ra thế nào lúc chạy, trên đường đi và dữ liệu cụ thể, nên phải dùng công cụ phân tích động (dynamic analysis) mới phát hiện tin cậy được. "The use of a variable before it has been defined" là bất thường luồng dữ liệu kinh điển mà phân tích tĩnh tìm được bằng cách lần theo cặp định nghĩa và sử dụng biến. "Unreachable ("dead") code" tìm được bằng phân tích luồng điều khiển, vì đồ thị cho thấy không có đường nào tới đoạn mã đó. "Array bound violations" phân tích tĩnh cũng phát hiện được khi chỉ số mảng có thể xác định từ mã, ví dụ hằng số hay biến vòng lặp vượt kích thước khai báo.

Đá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: "i,iii,iv are true and ii is false". Thanh tra (inspection) là loại rà soát hình thức nhất theo ISTQB: do người điều phối (moderator) đã được đào tạo dẫn dắt chứ không phải tác giả, có vai trò rõ ràng, có tiêu chí vào và ra, dùng danh sách kiểm tra, có quy trình theo dõi (follow-up) chính thức để xác nhận lỗi đã sửa, và mục tiêu chính là tìm lỗi; vì vậy các mệnh đề i, iii, iv đúng. Mệnh đề ii sai vì thanh tra bắt buộc có bước chuẩn bị cá nhân (individual preparation) trước cuộc họp, mỗi người tự đọc tài liệu và ghi lại lỗi tiềm năng. "ii is true and i,iii,iv are false" sai vì coi việc bỏ chuẩn bị là đặc điểm của thanh tra và phủ nhận cả người điều phối, quy trình theo dõi lẫn mục tiêu tìm lỗi. "i,iii,iv are false and ii is true" là chính nhận định đó viết đảo thứ tự, sai vì cùng lý do thanh tra luôn có chuẩn bị trước họp. "iii is true and I,ii,iv are false" chỉ nhận quy trình theo dõi mà bác vai trò người điều phối và mục tiêu tìm lỗi, trái với bản chất của thanh tra.

Đá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: "Purchased/contracted software". Với phần mềm mua sẵn hoặc thuê bên ngoài phát triển (như sản phẩm thương mại đóng gói, COTS), mã nguồn và cấu trúc bên trong thường thuộc quyền nhà cung cấp và không được giao cho bên mua, nên người kiểm thử chủ yếu chỉ kiểm được theo hộp đen, dựa vào đặc tả, tài liệu và kiểm thử chấp nhận. "Traditional system development" là phát triển nội bộ theo mô hình tuần tự, đội kiểm thử có thể tiếp cận mã và thiết kế. "Iterative development" là phát triển theo vòng lặp, mã nguồn cũng do chính tổ chức nắm giữ nên vẫn có thể kiểm thử hộp trắng. "System maintenance" là bảo trì hệ thống đang vận hành, thường do tổ chức sở hữu mã nguồn thực hiện, nên cấu trúc bên trong sẵn có để phân tích tác động và kiểm thử.

Đáp án đúng: "CLa01ss". Ô nhập chỉ nhận chữ cái in hoa hoặc in thường, nên theo phân vùng tương đương (equivalence partitioning) mọi chuỗi chỉ gồm chữ cái, bất kể pha trộn hoa thường ra sao, cùng thuộc lớp hợp lệ; lớp không hợp lệ là chuỗi chứa ký tự ngoài chữ cái như chữ số, ký tự đặc biệt. "CLa01ss" chứa chữ số 0 và 1 nên thuộc lớp không hợp lệ. "CLASS" toàn chữ in hoa nên hợp lệ. "cLASS" pha chữ thường đầu với chữ in hoa nhưng vẫn chỉ có chữ cái nên hợp lệ. "CLass" pha in hoa và in thường, cũng toàn chữ cái nên hợp lệ; việc đổi kiểu hoa thường không tạo ra lớp mới vì ô chấp nhận cả hai.

Đá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: "FAULT to ON". Sơ đồ chuyển trạng thái của công tắc có ba trạng thái: từ OFF có mũi tên sang ON, từ ON có mũi tên quay về OFF, từ ON có mũi tên sang FAULT, còn FAULT chỉ có một mũi tên vòng về chính nó. Trong kiểm thử chuyển trạng thái (state transition testing), chuyển trạng thái hợp lệ là cặp trạng thái có mũi tên nối theo đúng chiều; cặp nào không có mũi tên là chuyển không hợp lệ, cần được kiểm thử để chắc hệ thống từ chối nó. Từ FAULT không có mũi tên nào đi ra ngoài, nên đi từ FAULT sang ON là chuyển không hợp lệ: công tắc đã hỏng không thể tự bật lại. "ON to OFF" hợp lệ vì có mũi tên từ ON về OFF, tức tắt công tắc. "OFF to ON" hợp lệ vì có mũi tên từ OFF sang ON, tức bật công tắc.

Đáp án đúng: "22,23,24". Theo phân hoạch tương đương (equivalence partitioning), nhiệt độ chia thành ba lớp theo hành vi của công tắc: dưới 18 thì công tắc tắt, trên 21 thì công tắc bật, còn từ 18 tới 21 là vùng giữa, công tắc giữ nguyên trạng thái. Các giá trị trong cùng một lớp được kỳ vọng làm hệ thống xử lý như nhau. 22, 23, 24 đều lớn hơn 21 nên cùng thuộc lớp bật. "12,16,22" trộn hai lớp: 12 và 16 dưới 18 thuộc lớp tắt, còn 22 thuộc lớp bật. "24,27,17" cũng trộn: 24 và 27 thuộc lớp bật nhưng 17 dưới 18 thuộc lớp tắt. "14,15,19" có 14 và 15 thuộc lớp tắt, còn 19 nằm trong vùng 18 tới 21 nên thuộc lớp giữa, không cùng lớp với hai giá trị kia.

Đáp án đúng: "4 Test Cases". Đoạn mã có hai câu lệnh if nối tiếp và độc lập: câu thứ nhất có hai hướng (Condition 1 đúng thì chạy statement 1, sai thì chạy statement 2), câu thứ hai cũng có hai hướng (Condition 2 đúng thì chạy statement 3, sai thì bỏ qua). Mỗi hướng của câu thứ nhất đều đi tiếp được vào cả hai hướng của câu thứ hai, nên số đường đi là 2 × 2 = 4: statement 1 rồi statement 3, statement 1 rồi bỏ qua, statement 2 rồi statement 3, statement 2 rồi bỏ qua; phủ mọi đường cần 4 ca kiểm thử. "2 Test Cases" chỉ đủ cho độ phủ nhánh, mỗi quyết định đúng một lần và sai một lần, nhưng chưa phủ mọi tổ hợp. "3 Test Cases" là độ phức tạp vòng, số quyết định cộng 1, tức số đường độc lập của tập cơ sở chứ không phải toàn bộ đường đi. "Not achievable" sai vì hai điều kiện độc lập nên cả bốn tổ hợp đều tạo ra được, và đoạn mã không có vòng lặp khiến số đường vô hạn.

Đáp án đúng: "Pole Coverage". Độ phủ logic (logic coverage) là nhóm tiêu chí hộp trắng đo mức các cấu trúc logic của chương trình đã được thực thi. Các dạng chuẩn gồm độ phủ câu lệnh, độ phủ nhánh hay quyết định, độ phủ điều kiện, độ phủ kết hợp điều kiện và độ phủ đường đi. Không có tiêu chí nào gọi là pole coverage, nên đây là dạng không hợp lệ. "Statement Coverage" (độ phủ câu lệnh) là dạng cơ bản nhất, đo tỉ lệ câu lệnh đã chạy. "Condition Coverage" (độ phủ điều kiện) yêu cầu mỗi điều kiện đơn trong một biểu thức quyết định nhận cả giá trị đúng và sai. "Path Coverage" (độ phủ đường đi) yêu cầu thực thi mọi đường đi qua chương trình, là tiêu chí mạnh nhất trong nhóm nhưng thường không khả thi đầy đủ khi có vòng lặp. Cả ba đều là dạng hợp lệ nên không phải đáp án.

Đáp án đúng: "Equivalence partitioning". Phân vùng tương đương (equivalence partitioning) chia miền dữ liệu thành các phân vùng mà mọi giá trị trong cùng phân vùng được kỳ vọng xử lý như nhau; ISTQB nêu rõ kỹ thuật này áp dụng cho cả đầu vào lẫn đầu ra, nên có thể dùng để đạt mục tiêu độ phủ đầu vào và độ phủ đầu ra (mỗi phân vùng được kiểm ít nhất một lần). "Boundary value analysis" là phần mở rộng của phân vùng tương đương, chỉ tập trung vào các giá trị nằm ở mép phân vùng, nên nó đo độ phủ biên chứ không phải kỹ thuật nền để phủ đầu vào và đầu ra. "Decision table testing" nhắm vào độ phủ các tổ hợp điều kiện và hành động tương ứng. "State transition testing" nhắm vào độ phủ trạng thái và chuyển trạng thái của hệ thống, không phải phủ miền giá trị vào ra.

Đá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: "1Y, 2Z, 3X, 4W.". Ghép từng thuật ngữ với định nghĩa: kiểm thử bảng quyết định (decision table testing) kiểm các tổ hợp đầu vào mà nếu không có bảng thì có thể chưa từng được thực thi, nên 1 ứng với Y; kiểm thử quyết định (decision testing) là một dạng kiểm thử luồng điều khiển dựa trên các kết quả của quyết định, nên 2 ứng với Z; kiểm thử chuyển trạng thái (state transition testing) kiểm hệ thống phản hồi khác nhau tuỳ điều kiện hiện tại hay lịch sử trước đó, nên 3 ứng với X; kiểm thử thăm dò (exploratory testing) thực hiện trong các khung thời gian để đạt mục tiêu cụ thể, bổ sung cho kiểm thử có cấu trúc, nên 4 ứng với W. "1X ,2W, 3Z, 4Y." sai hết cả bốn cặp. "1Z, 2X, 3W, 4Y." gán định nghĩa luồng điều khiển cho bảng quyết định và định nghĩa trạng thái cho decision testing. "1Z, 2Y, 3X, 4W." chỉ đúng hai cặp sau, đảo vị trí của bảng quyết định với kiểm thử quyết định.

Đáp án đúng: "During test planning.". ISTQB nêu rằng thủ tục và hạ tầng quản lý cấu hình (configuration management) phải được chọn, ghi lại và triển khai ngay khi lập kế hoạch kiểm thử, để mọi testware và phiên bản phần mềm được định danh, kiểm soát phiên bản và truy vết được từ đầu. "During test analysis." đã muộn: lúc này cơ sở kiểm thử và điều kiện kiểm thử đã được tạo ra, chúng cần được quản lý phiên bản từ trước. "During test execution." quá muộn: chạy kiểm thử mà không biết đang chạy trên phiên bản nào, với ca kiểm thử phiên bản nào thì kết quả không tái hiện được. "When evaluating exit criteria" là gần cuối quy trình, khi đó quản lý cấu hình không còn phát huy tác dụng phòng ngừa.

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