Tất cả câu hỏi

Đáp án đúng: "Improvements suggested by users". Sự cố (incident) là bất kỳ sự kiện nào xảy ra trong kiểm thử cần được điều tra, thường là chênh lệch giữa kết quả thực tế và kết quả mong đợi. Theo ISTQB Foundation, sự cố có thể được ghi nhận đối với bất kỳ sản phẩm công việc nào có thể chứa lỗi, như yêu cầu, tài liệu, ca kiểm thử hay mã. Góp ý cải tiến của người dùng thì không phải sai lệch so với điều mong đợi mà là đề xuất thay đổi, thường được quản lý như yêu cầu thay đổi hay yêu cầu nâng cấp (change request, enhancement request), nên thông thường không mở sự cố cho nó. "Requirements" có thể bị ghi sự cố khi yêu cầu mâu thuẫn, mơ hồ hay sai. "Documentation" như hướng dẫn sử dụng có thể bị ghi sự cố khi mô tả không khớp hệ thống. "Test cases" cũng có thể bị ghi sự cố khi chính kết quả mong đợi trong ca kiểm thử bị sai.

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

Đá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: "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: "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: "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: "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: "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: "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: "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: "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: "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: "Moderator". Trong rà soát hình thức (formal review) theo ISTQB Foundation, người điều phối (moderator) là người dẫn dắt việc rà soát tài liệu: lập kế hoạch rà soát, điều hành buổi họp và theo dõi sau buổi họp (follow-up), đồng thời làm trung gian giữa các quan điểm và thường quyết định có rà soát lại hay không. "Reviewer" (người rà soát, còn gọi checker hay inspector) là người đọc tài liệu để tìm lỗi, không chịu trách nhiệm tổ chức. "Author" (tác giả) là người viết hoặc chịu trách nhiệm chính về tài liệu được rà soát, nhận lỗi và sửa chúng ở bước làm lại; tác giả không nên điều phối để giữ khách quan. "Auditor" (kiểm toán viên) thuộc hoạt động kiểm toán (audit), đánh giá độc lập mức tuân thủ chuẩn và quy trình, không phải vai trò trong một buổi rà soát tài liệu.

Đáp án đúng: "i-c , ii-a , iii-d , iv-b". Mô hình chữ V (V-model) ghép mỗi bước phát triển bên trái với một cấp kiểm thử bên phải dùng sản phẩm của bước đó làm cơ sở kiểm thử: yêu cầu nghiệp vụ (business requirements) là căn cứ của kiểm thử chấp nhận nên iv ghép b, thiết kế mức cao (hi-level design) mô tả kiến trúc toàn hệ thống nên ứng với kiểm thử hệ thống, i ghép c, thiết kế mức thấp (low-level design) mô tả các mô-đun và giao diện giữa chúng nên ứng với kiểm thử tích hợp, iii ghép d, còn mã (code) ứng với kiểm thử đơn vị, ii ghép a. "i-d , ii-a , iii-c , iv-b" đảo cặp thiết kế mức cao và mức thấp, gán kiểm thử hệ thống cho thiết kế mức thấp. "i-c , ii-d , iii-a , iv-b" đặt kiểm thử tích hợp cho mã và kiểm thử đơn vị cho thiết kế mức thấp, ngược thứ bậc. "i-b , ii-a , iii-d , iv-c" gán kiểm thử chấp nhận cho thiết kế mức cao và kiểm thử hệ thống cho yêu cầu nghiệp vụ, trong khi chấp nhận phải đối chiếu với nhu cầu nghiệp vụ.

Đáp án đúng: "Black-box testing". Kiểm thử hộp đen (black-box testing) thiết kế ca kiểm thử từ đặc tả chức năng mà không cần biết cấu trúc bên trong, với mục đích chứng minh từng chức năng của chương trình hoạt động đúng: đưa đầu vào, quan sát đầu ra, đối chiếu với yêu cầu. Định nghĩa trong câu hỏi, lập ca kiểm thử để chứng minh mỗi chức năng đều vận hành được, chính là định nghĩa kinh điển của kiểm thử hộp đen. "Glass-box testing" là tên gọi khác của kiểm thử hộp trắng, dựa vào cấu trúc mã để phủ câu lệnh, nhánh, đường đi chứ không xuất phát từ chức năng. "White-box testing" cũng vậy, mục tiêu là kiểm các đường logic bên trong. "Grey-box testing" kết hợp hiểu biết một phần cấu trúc bên trong với góc nhìn chức năng, không phải kỹ thuật thuần tuý dựa vào chức năng như câu hỏi mô tả.

Đáp án đúng: "Missing Statements". Độ phủ câu lệnh (statement coverage) đo tỉ lệ câu lệnh có trong mã đã được thực thi bởi bộ ca kiểm thử. Vì nó chỉ đo những gì đang tồn tại trong mã, nó không thể phát hiện câu lệnh bị thiếu: một phép kiểm tra hay một xử lý mà lập trình viên quên viết thì không có dòng nào để đánh dấu là chưa chạy, nên độ phủ vẫn có thể đạt 100%. Muốn phát hiện thiếu sót này phải đối chiếu với đặc tả bằng kỹ thuật hộp đen hoặc rà soát. "Unused Branches" thì phân tích độ phủ câu lệnh vẫn làm lộ ra khi phần thân của nhánh đó chưa từng được thực thi. "Dead Code" (mã chết) luôn hiện ra là không được phủ, vì không ca kiểm thử nào chạy tới được. "Unused Statement" cũng hiện ngay trong báo cáo độ phủ như dòng chưa thực thi, nên đây đúng là thứ độ phủ câu lệnh kiểm tra được.

Đáp án đúng: "De-bugging.". Quản lý kiểm thử (test management) bao gồm lập kế hoạch và ước lượng, giám sát và điều khiển, quản lý rủi ro, quản lý sự cố và quản lý cấu hình; gỡ lỗi (debugging) là hoạt động phát triển, do lập trình viên tìm nguyên nhân lỗi, sửa mã và kiểm tra bản sửa, không phải trách nhiệm của quản lý kiểm thử nên kém quan trọng nhất trong bối cảnh này. "Estimating test duration." là ước lượng thời gian kiểm thử, phần cốt lõi của lập kế hoạch giúp bố trí lịch và nguồn lực. "Incident Management" theo dõi sự cố từ lúc phát hiện tới khi đóng, cung cấp số liệu cho giám sát tiến độ và quyết định phát hành. "Configuration Management." bảo đảm biết chính xác phiên bản phần mềm và testware đang được kiểm thử, để kết quả kiểm thử truy vết và tái lập được.

Đáp án đúng: "i is true and ii,iii,iv are false". Kiểm chứng (verification) trả lời câu hỏi chúng ta có xây sản phẩm đúng cách không, tức đối chiếu sản phẩm làm ra với đặc tả và tiêu chuẩn, nên nó giúp kiểm tra chất lượng của sản phẩm đã xây (mục i). Mục ii nói xây đúng sản phẩm, đó là định nghĩa của thẩm định (validation), kiểm tra sản phẩm có đáp ứng nhu cầu thật của người dùng không. Mục iii nói giúp phát triển sản phẩm, nhưng verification là hoạt động đánh giá chứ không phải hoạt động phát triển, và mục iv về hao phí công cụ thì không liên quan. "i,ii,iii are true and iv is false" là phương án một số nguồn chấm đúng, nhưng nó gộp nhầm validation vào verification và coi hoạt động đánh giá là hoạt động phát triển, nên không đứng được. "Options i,ii,iii,iv are true." còn thêm cả mục iv vô can. "ii is true and i,iii,iv are false." chọn đúng mục thuộc validation và loại mục duy nhất thuộc verification.

Đáp án đúng: "Error Guessing". Đoán lỗi (error guessing) là kỹ thuật dựa trên kinh nghiệm: người kiểm thử dựa vào hiểu biết về những lỗi hay gặp, những chỗ hệ thống từng hỏng, để thiết kế ca kiểm thử nhắm vào đó. ISTQB nêu các kỹ thuật dựa trên kinh nghiệm thường được dùng để bổ sung cho các kỹ thuật hình thức, có hệ thống (đặc tả hay cấu trúc), vì chúng bắt được những lỗi mà cách tiếp cận chặt chẽ bỏ sót. "Regression testing" là chạy lại ca kiểm thử sau thay đổi, một loại kiểm thử liên quan đến thay đổi chứ không phải thứ bổ sung cho kiểm thử chặt chẽ. "Integration testing." là một cấp kiểm thử kiểm giao diện giữa các thành phần, bản thân nó cần được thực hiện chặt chẽ. "System testing." cũng là một cấp kiểm thử trên toàn hệ thống, không phải kỹ thuật dùng để lấp chỗ hổng của kỹ thuật hình thức.

Đáp án đúng: "Requirement Analysis". Quy trình kiểm thử cơ bản (Fundamental Test Process) trong ISTQB gồm năm nhóm hoạt động: lập kế hoạch và kiểm soát, phân tích và thiết kế, triển khai và thực thi, đánh giá tiêu chí thoát và báo cáo, kết thúc kiểm thử. Phân tích yêu cầu là hoạt động của vòng đời phát triển phần mềm do người phân tích nghiệp vụ thực hiện để xác định hệ thống phải làm gì; kiểm thử có thể rà soát tài liệu yêu cầu nhưng đó là rà soát cơ sở kiểm thử chứ không phải một pha mang tên phân tích yêu cầu. "Test Planning and Control" là pha đầu tiên, đặt mục tiêu và theo dõi tiến độ. "Test implementation and Execution" là pha xây quy trình kiểm thử và chạy kiểm thử. "Evaluating Exit criteria and reporting" là pha đối chiếu kết quả với tiêu chí thoát và báo cáo cho các bên liên quan.