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

Đáp án đúng: "The fault has been built into more documentation, code, tests, etc". Một lỗi sinh ra ở pha đầu, ví dụ trong yêu cầu, sẽ lan sang thiết kế, mã nguồn, tài liệu người dùng và cả ca kiểm thử được viết theo yêu cầu đó; càng phát hiện muộn thì càng nhiều sản phẩm công việc phải sửa lại và kiểm lại, nên chi phí sửa tăng theo cấp số qua từng pha. Đây là lý do ISTQB đặt nguyên tắc kiểm thử sớm (early testing). "The documentation is poor, so it takes longer to find out what the software is doing." chỉ là một tình huống riêng của dự án có tài liệu kém, không giải thích quy luật chung áp dụng cho mọi dự án. "Wages are rising" không liên quan: chi phí tăng vì khối lượng sửa chữa lan rộng chứ không vì lương tăng theo thời gian. "None of the others" sai vì đã có một phương án nêu đúng nguyên nhân là lỗi bị nhúng vào ngày càng nhiều sản phẩm công việc.

Đáp án đúng: "The answer depends on the risk for your industry, contract and special requirements". Kiểm thử vét cạn là không thể, nên ISTQB trả lời câu hỏi bao nhiêu kiểm thử là đủ bằng rủi ro: mức rủi ro của ngành và sản phẩm, ràng buộc hợp đồng, yêu cầu đặc biệt như quy định pháp lý, cùng thời gian và ngân sách, quyết định phải kiểm thử sâu tới đâu và ưu tiên chỗ nào. "This question is impossible to answer" sai vì tuy không có con số tuyệt đối, ta vẫn trả lời được bằng tiêu chí dựa trên rủi ro và tiêu chí thoát. "This question is easy to answer" sai vì câu trả lời đòi hỏi phân tích rủi ro cho từng bối cảnh, không có công thức chung. "This answer depends on the maturity of your developers" chỉ đúng một phần: lập trình viên trưởng thành có thể sinh ít khiếm khuyết hơn, nhưng đó không phải căn cứ chính để quyết định mức kiểm thử, rủi ro mới là căn cứ.

Đáp án đúng: "Dynamic analysis". Rò rỉ bộ nhớ (memory leak) xảy ra khi chương trình cấp phát bộ nhớ mà không giải phóng, chỉ lộ ra khi phần mềm đang chạy và tích tụ dần theo thời gian; công cụ phân tích động (dynamic analysis tool) theo dõi chương trình lúc thực thi, ghi lại từng lần cấp phát và giải phóng, nên ISTQB xếp việc phát hiện rò rỉ bộ nhớ vào nhóm công cụ này. "State analysis" không phải tên một nhóm công cụ kiểm thử; phân tích trạng thái là cách mô hình hóa hành vi, không đo việc dùng bộ nhớ. "Coverage analysis" đo phần mã đã được chạy bởi các ca kiểm thử, không theo dõi cấp phát bộ nhớ. "Memory analysis" nghe gần đúng nhưng không phải tên nhóm trong phân loại công cụ của ISTQB; các trình theo dõi bộ nhớ thực chất là một dạng công cụ phân tích động, nên tên nhóm đúng vẫn là phân tích động.

Đáp án đúng: "Both of (1) and (2)". Công cụ và tự động hoá kiểm thử mang lại hai thuộc tính cốt lõi: tốc độ và hiệu suất, vì máy chạy hàng nghìn ca kiểm thử lặp lại nhanh hơn người rất nhiều, giảm việc thủ công lặp đi lặp lại; và độ chính xác, độ chuẩn xác, vì máy thực hiện đúng từng bước như nhau mọi lần, so sánh kết quả không bỏ sót và không mệt mỏi. ISTQB Foundation cũng nêu lợi ích của công cụ là giảm việc lặp lại, tăng tính nhất quán và khả năng lặp lại, cung cấp đánh giá khách quan. Vì cả hai thuộc tính cùng đúng nên phải chọn cả hai. "(1) Speed & efficiency" chỉ nêu một nửa, bỏ mất tính chính xác. "(2) Accuracy & precision" cũng chỉ nêu một nửa, bỏ mất tốc độ. "None of (1) nor (2)" sai vì phủ nhận cả hai lợi ích cơ bản nhất mà tự động hoá mang lại.

Đáp án đúng: "4, 5, 99". Phân tích giá trị biên (boundary value analysis) lấy giá trị nằm đúng ở mép mỗi phân vùng tương đương. Số lượng đặt hàng có ba phân vùng: dưới 5 là không hợp lệ (biên trên là 4), từ 5 đến 99 là hợp lệ không giảm giá (biên là 5 và 99), từ 100 trở lên được giảm 20% (biên dưới là 100). Vậy các giá trị biên là 4, 5, 99, 100, và nhóm có cả ba giá trị đều là biên chỉ có 4, 5 và 99. "5, 6, 20" sai vì 20 nằm giữa phân vùng, còn 6 không phải mép phân vùng nào trong cách lấy hai giá trị biên. "4, 5, 80" có hai giá trị biên đúng nhưng 80 nằm lọt giữa phân vùng 5 đến 99, chỉ là giá trị đại diện của phân vùng tương đương. "1, 20, 100" chỉ có 100 là biên, còn 1 và 20 đều là giá trị nằm giữa phân vùng.

Đáp án đúng: "Error guessing". Đoán lỗi (error guessing) là kỹ thuật kiểm thử động dựa trên kinh nghiệm: người kiểm thử dự đoán chỗ phần mềm hay sai rồi thiết kế ca kiểm thử để chạy chương trình nhắm vào chỗ đó, nên nó không phải kỹ thuật tĩnh. Kiểm thử tĩnh (static testing) đánh giá sản phẩm mà không thực thi mã, gồm rà soát và phân tích tĩnh. "Walkthrough" là duyệt qua do tác giả dẫn dắt, một loại rà soát nên là kỹ thuật tĩnh. "Inspections" là thanh tra, loại rà soát chính thức nhất, cũng là kỹ thuật tĩnh. "Data flow analysis" là phân tích luồng dữ liệu, thường do công cụ phân tích tĩnh thực hiện trên mã nguồn để tìm biến dùng trước khi gán hay gán mà không dùng, không cần chạy chương trình nên cũng thuộc nhóm tĩnh.

Đáp án đúng: "Usability testing.". Kiểm thử phi chức năng kiểm tra hệ thống làm việc tốt tới mức nào theo các đặc tính chất lượng; kiểm thử khả năng sử dụng (usability testing) đánh giá người dùng có dễ học, dễ thao tác, hài lòng với giao diện hay không, là một loại phi chức năng điển hình bên cạnh hiệu năng, độ tin cậy, khả năng bảo trì. "Statement Coverage." là độ phủ câu lệnh, một kỹ thuật kiểm thử hộp trắng dựa trên cấu trúc mã, đo tỷ lệ câu lệnh đã được chạy. "Dataflow testing." cũng là kỹ thuật hộp trắng, thiết kế ca kiểm thử theo các cặp định nghĩa và sử dụng biến trong mã. "Cause-effect graphing" là kỹ thuật hộp đen dùng đồ thị nguyên nhân và kết quả để sinh ca kiểm thử chức năng từ tổ hợp điều kiện đầu vào; nó kiểm tra hệ thống làm gì chứ không đo chất lượng hoạt động.

Đáp án đúng: "i,iii,iv are true and ii is false". Dàn ý kế hoạch kiểm thử (test plan outline) theo IEEE 829 gồm các mục: định danh kế hoạch, giới thiệu, hạng mục kiểm thử (test items), tính năng được và không được kiểm thử, cách tiếp cận, tiêu chí đạt/không đạt, tiêu chí tạm dừng và tiếp tục, sản phẩm bàn giao của kiểm thử (test deliverables), nhiệm vụ kiểm thử, nhu cầu môi trường, trách nhiệm (responsibilities), nhân sự và đào tạo, lịch, rủi ro và phê duyệt. Vậy mục i, iii, iv đều có. Kịch bản kiểm thử (test scripts) là mức chi tiết thực thi, thuộc đặc tả thủ tục kiểm thử (test procedure specification) chứ không nằm trong kế hoạch. "i,ii,iii are true and iv is false" sai vì nhận kịch bản và bỏ trách nhiệm. "ii,iii are true and i and iv are false" sai vì bỏ hạng mục kiểm thử, mục cốt lõi của kế hoạch. "i,ii are false and iii , iv are true" bỏ sót hạng mục kiểm thử.

Đáp án đúng: "ii is true and i,iii,iv are false". Xác nhận (validation) trả lời câu hỏi "chúng ta có xây đúng sản phẩm không", tức sản phẩm có đáp ứng nhu cầu và mục đích sử dụng thật của người dùng, nên mục ii đúng. Mục i, kiểm chất lượng của sản phẩm đã làm ra so với đặc tả, gần với kiểm định (verification), trả lời câu hỏi "chúng ta có xây sản phẩm đúng cách không". Mục iii sai vì validation là hoạt động đánh giá, không trực tiếp phát triển sản phẩm; mục iv về theo dõi hao mòn, lỗi thời của công cụ không liên quan. "Options i,ii,iii,iv are true" sai vì nhận cả những mục không thuộc validation. "i,ii,iii are true and iv is false" sai vì gộp verification và việc phát triển vào validation. "iii is true and i,ii,iv are false." sai vì phủ nhận đúng mục định nghĩa validation và nhận mục phát triển sản phẩ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: "1&2 are true and 3 is false". Khi nhận một phần mềm với thời gian và nguồn lực có hạn, không thể kiểm thử vét cạn, nên ISTQB khuyên kiểm thử dựa trên rủi ro (risk-based testing): ưu tiên các vùng quan trọng nhất với quy trình nghiệp vụ, nơi hỏng hóc gây tác động lớn, và các vùng nhiều khả năng chứa lỗi nhất theo nguyên lý lỗi tụ thành cụm (defect clustering). Vì thế mệnh đề 1 và 2 đúng, còn kiểm thử các chức năng dễ nhất là sai vì dễ kiểm thử không có nghĩa là rủi ro cao. "1,2&3 are true." sai vì nhận cả tiêu chí dễ nhất, vốn không phản ánh tác động hay khả năng hỏng. "1 is true, 2&3 are false." bỏ mất vùng nhiều lỗi, trái với nguyên lý lỗi tụ thành cụm. "1&2 are false, 3 is true" đảo ngược hoàn toàn, chọn việc dễ thay vì việc quan trọng.

Đá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: "Uncover software errors". Mục tiêu căn bản của kiểm thử phần mềm là tìm ra lỗi: chạy chương trình với ý định phát hiện khuyết tật, qua đó cung cấp thông tin về chất lượng và giảm rủi ro. ISTQB nhấn mạnh kiểm thử chỉ cho thấy có lỗi, không chứng minh được là không còn lỗi. "Determine the productivity of programmers" sai vì kiểm thử đánh giá sản phẩm chứ không đánh giá con người; dùng số lỗi để chấm năng suất còn làm hỏng quan hệ giữa người kiểm thử và lập trình viên. "Eliminate the need for future program maintenance" sai vì bảo trì luôn cần do yêu cầu thay đổi, môi trường thay đổi và lỗi còn sót, kiểm thử không loại bỏ được nhu cầu đó. "Eliminate every error prior to release" trái với nguyên tắc kiểm thử vét cạn là không thể và kiểm thử không chứng minh được sự vắng mặt của lỗi.

Đáp án đúng: "Debugging defects". ISTQB phân biệt rõ kiểm thử với gỡ lỗi (debugging): kiểm thử làm lộ ra thất bại do khiếm khuyết gây ra, còn gỡ lỗi là hoạt động phát triển nhằm tìm nguyên nhân, phân tích và sửa khiếm khuyết, thường do lập trình viên làm, nên gỡ lỗi không phải mục tiêu của kiểm thử. "Finding defects" là mục tiêu kinh điển của kiểm thử. "Gaining confidence about the level of quality and providing information" cũng là mục tiêu được nêu rõ: kiểm thử tạo niềm tin vào mức chất lượng và cung cấp thông tin cho việc ra quyết định. "Preventing defects." là mục tiêu đạt được nhờ tham gia kiểm thử sớm, rà soát yêu cầu và thiết kế để chặn khiếm khuyết trước khi nó được viết vào mã.

Đáp án đúng: "Faults in requirements are the most expensive to fix". Chi phí sửa lỗi tăng theo thời gian lỗi tồn tại trong vòng đời phát triển: lỗi trong yêu cầu được đưa vào sớm nhất rồi lan sang thiết kế, mã, tài liệu và ca kiểm thử, nên nếu chỉ phát hiện ở kiểm thử chấp nhận hay khi vận hành thì phải sửa lại mọi sản phẩm dựng trên nó; đó là lý do ISTQB nhấn mạnh kiểm thử sớm và rà soát yêu cầu. "Faults in program specifications are the most expensive to fix" sai vì đặc tả chương trình được viết sau yêu cầu, lỗi ở đó lan qua ít tầng hơn. "Faults in designs are the most expensive to fix." cũng vậy: thiết kế đứng sau yêu cầu nên lỗi thiết kế tốn kém nhưng vẫn ít hơn. "Faults in code are the most expensive to fix." sai vì lỗi mã thường chỉ cần sửa trong mã rồi chạy lại kiểm thử, phạm vi ảnh hưởng hẹp nhất trong bốn loại.

Đáp án đúng: "i and iv". ISTQB Foundation liệt kê lợi ích tiềm năng của công cụ kiểm thử: giảm công việc lặp lại, tăng tính nhất quán và khả năng lặp lại của kiểm thử (mục iv), cung cấp đánh giá khách quan như số đo tĩnh, độ phủ, và dễ truy cập thông tin về kiểm thử và quá trình kiểm thử (mục i) qua thống kê, biểu đồ. Ngược lại, tài liệu này nêu rõ rủi ro là đánh giá thấp thời gian, chi phí để giới thiệu công cụ và đánh giá thấp công sức bảo trì các tài sản kiểm thử do công cụ sinh ra. Vì vậy mục ii, giảm bảo trì testware, và mục iii, dễ và rẻ để triển khai, là hai kỳ vọng sai. "ii and iv" sai vì kèm giảm bảo trì, vốn là rủi ro chứ không phải lợi ích. "ii and iii" sai vì cả hai đều là kỳ vọng phi thực tế. "i and iii" sai vì triển khai công cụ thường tốn kém và mất công, không dễ và rẻ.

Đá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: "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: "LCSAJ (Linear Code Sequence and Jump)". LCSAJ là kỹ thuật hộp trắng (white-box, dựa trên cấu trúc) được mô tả trong BS 7925-2: nó xét các đoạn mã chạy tuần tự rồi nhảy tới một vị trí khác, ca kiểm thử được suy ra từ cấu trúc mã nguồn nên phải nhìn vào bên trong chương trình. Kỹ thuật hộp đen (black-box) suy ra ca kiểm thử từ đặc tả mà không cần biết mã. "State transition testing" là hộp đen vì dựa trên mô hình trạng thái và sự kiện trong đặc tả. "Syntax testing" là hộp đen vì dựa trên văn phạm mô tả định dạng dữ liệu vào, BS 7925-2 xếp nó vào nhóm kỹ thuật đặc tả. "Boundary value analysis" là hộp đen vì lấy giá trị ở biên các phân vùng tương đương được xác định từ đặc tả.

Đáp án đúng: "Define when to stop testing". Tiêu chí kết thúc (exit criteria) là tập điều kiện thống nhất với bên liên quan, như độ phủ phải đạt, số lỗi nghiêm trọng còn mở, mức rủi ro còn lại, để quyết định một hoạt động hay một cấp kiểm thử được coi là xong; mục đích của nó là xác định khi nào dừng kiểm thử. "End of test level" chỉ mô tả thời điểm kết thúc một cấp, tức kết quả khi tiêu chí đã được thỏa, không phải mục đích của tiêu chí. "When a set of tests has achieved a specific pre condition" lẫn với tiêu chí đầu vào (entry criteria), vốn là điều kiện tiên quyết để bắt đầu một hoạt động chứ không phải để kết thúc. "All of the others" sai vì hai mô tả kia không phải mục đích của tiêu chí kết thúc.