Đáp án Quiz Testing — 75 câu hỏi có giải thích

Đáp án: B

Phạm vi. Unit kiểm một đơn vị logic tách biệt, chạy rất nhanh. Integration kiểm nhiều phần ghép lại (service + DB thật, API + handler), chậm hơn nhưng bắt được lỗi ở chỗ các phần nối với nhau.

Đáp án: C

Viết regression test tái hiện bug. Thứ tự quan trọng: viết test trước khi sửa và xác nhận nó đỏ — nếu nó xanh ngay từ đầu thì bạn chưa tái hiện đúng bug, và bản sửa có thể không đúng chỗ.

Đáp án: B

Một hành vi cho mỗi test (có thể vài assert cùng mô tả hành vi đó). Khi test đỏ, tên test phải cho biết ngay điều gì sai mà không cần mở code — đó là tiêu chí thực dụng nhất.

Đáp án: C

Thường là mock che mất phần đang lỗi: test mock tầng gọi API hoặc tầng DB, nên bug nằm trong chính phần bị mock. Test xanh vì nó chỉ kiểm tra mock hoạt động đúng như bạn đã khai.

Đáp án: A

userEvent (await user.type(...), await user.click(...)). Nó phát đúng chuỗi sự kiện thật — focus, keydown, input, change — nên bắt được lỗi mà fireEvent bỏ qua, ví dụ validate chạy theo blur.

Đáp án: A

Xem log lỗi trước, rồi chạy đúng test đó trên nhánh của mình và trên nhánh gốc. Đỏ ở cả hai thì là vấn đề sẵn có; chỉ đỏ trên nhánh mình thì thay đổi của bạn là nguyên nhân, dù trông không liên quan.

Đáp án: D

Stub cung cấp dữ liệu định trước để code chạy tiếp. Mock ngoài ra còn ghi lại và cho phép assert *cách nó được gọi* (bao nhiêu lần, với tham số nào). Stub kiểm kết quả, mock kiểm tương tác.

Đáp án: D

Có thể nó không kiểm tra thứ bạn tưởng. Nguyên nhân hay gặp: assert nằm trong callback không bao giờ chạy, quên await nên test kết thúc trước khi assert, hoặc điều kiện đúng một cách tầm thường.

Đáp án: B

Ba thứ nhanh: test liên quan tới file đã sửa, kiểm kiểu (tsc --noEmit), và linter. Chúng bắt phần lớn lỗi trong vài chục giây, thay vì chờ CI vài phút rồi push tiếp một commit sửa lỗi nhỏ.

Đáp án: D

Nó làm test đọc được ngay: phần đầu dựng dữ liệu và điều kiện, phần giữa gọi đúng một hành động cần kiểm, phần cuối khẳng định kết quả. Test lệch khỏi cấu trúc này — ví dụ có nhiều lần gọi xen kẽ khẳng định — thường là dấu hiệu đang kiểm quá nhiều thứ.

Đáp án: D

Tên nên nêu điều kiện và hành vi mong đợi, đọc lên như một câu: "trả về lỗi khi số tiền âm". Khi test đỏ trong báo cáo CI, tên là thứ duy nhất người đọc thấy đầu tiên — nếu nó không mô tả được vấn đề thì phải mở mã mới hiểu.

Đáp án: B

Phù hợp khi cùng một logic cần kiểm với nhiều bộ đầu vào — kiểm tra định dạng, tính toán, chuyển đổi. Mỗi dòng trong bảng là một trường hợp có tên riêng, nên thêm trường hợp biên chỉ tốn một dòng và báo lỗi vẫn chỉ đúng dòng nào sai.

Đáp án: C

Fake là hiện thực đơn giản hoá nhưng chạy thật — ví dụ một kho dữ liệu trong bộ nhớ. Mock tồn tại để khẳng định về lời gọi: nó được gọi bao nhiêu lần, với tham số nào. Fake kiểm kết quả, mock kiểm tương tác.

Đáp án: B

Nhiều test nhanh ở tầng thấp (unit), ít hơn ở tầng giữa (tích hợp), và ít nhất ở tầng đầu cuối. Lý do là chi phí: test đầu cuối chạy chậm, dễ không ổn định, và khi đỏ thì phải mất công tìm xem phần nào hỏng.

Đáp án: B

Chỉ kiểm vài luồng cốt lõi: mở trang chủ, đăng nhập, thực hiện một thao tác chính. Mục tiêu là phát hiện trong vòng một hai phút rằng bản vừa triển khai hỏng nặng, để quay lui trước khi nhiều người dùng gặp phải.

Đáp án: A

So với giá trị mong đợi cụ thể. Khi đỏ, báo lỗi hiện cả giá trị nhận được lẫn giá trị mong đợi nên biết ngay sai ở đâu. Các khẳng định lỏng như "khác rỗng" hay "không ném lỗi" đúng với rất nhiều kết quả sai.

Đáp án: C

Cần cho những gì máy không đánh giá được: trải nghiệm có tự nhiên không, thông báo lỗi có dễ hiểu không, luồng có chỗ nào gây bối rối. Và cho kiểm thử khám phá — người kiểm thử tự do thử các tình huống chưa ai nghĩ tới.

Đáp án: C

Để chạy riêng một test khi gỡ lỗi, chạy song song an toàn, và để một test đỏ nghĩa là mã hỏng chứ không phải test khác để lại trạng thái. Test phụ thuộc nhau tạo ra lỗi chỉ xuất hiện ở một thứ tự chạy nhất định — dạng lỗi tốn nhiều thời gian nhất để truy.

Đáp án: C

Rủi ro là mất bảo vệ một cách âm thầm: pipeline xanh nên không ai để ý, còn vùng mã đó không còn được kiểm. Nếu buộc phải bỏ qua, cần ghi lý do, gắn người chịu trách nhiệm và thời hạn, đồng thời cho pipeline báo số test bị bỏ qua.

Đáp án: D

Vì vòng phản hồi ngắn quyết định test có thực sự được dùng hay không. Chạy được trong vài giây ngay khi đang viết mã thì người phát triển chạy liên tục; phải chờ pipeline mười phút thì họ chỉ đẩy lên và hy vọng.

Đáp án: B

Mock ở tầng network (msw, nock, hoặc chặn fetch), không mock hàm của chính mình. Khi đó phần dựng URL, header, xử lý lỗi và parse response vẫn được chạy thật — đó chính là phần hay sai.

Đáp án: C

Không. Coverage đo dòng nào được thực thi, không đo bạn có assert gì. Một test gọi hàm rồi không kiểm tra gì vẫn cho 100% coverage. Nó hữu ích để tìm phần *chưa* được test, không phải để chứng minh chất lượng.

Đáp án: D

Điều tra nguyên nhân. Bốn nguồn phổ biến: chờ theo thời gian cố định (sleep 100), trạng thái dùng chung giữa các test, thứ tự chạy (test này phụ thuộc test kia), và thời gian/múi giờ. Retry chỉ nên là biện pháp tạm trong lúc đang sửa.

Đáp án: C

Ưu tiên getByRole('button', { name: /gửi/i }). Thứ tự khuyến nghị: role → label → placeholder → text → cuối cùng mới getByTestId. Query theo role vừa gần cách người dùng nhìn giao diện, vừa phát hiện thiếu nhãn truy cập.

Đáp án: D

await screen.findByText(...) hoặc await waitFor(() => expect(...)) — chờ tới khi điều kiện thoả, không chờ theo đồng hồ. Nhanh khi máy khoẻ, và không vỡ khi CI chậm hơn máy dev.

Đáp án: B

Bọc mỗi test trong một transaction rồi rollback: dữ liệu tự biến mất, không cần dọn, và mỗi test bắt đầu từ trạng thái sạch. Nếu framework không hỗ trợ thì dùng schema riêng cho mỗi worker để chạy song song.

Đáp án: D

Ưu tiên role + nhãn người dùng thấy (getByRole('button', { name: 'Thanh toán' })), và dùng data-testid cho những chỗ không có nhãn ổn định. Tránh XPath, class CSS, và vị trí theo thứ tự.

Đáp án: A

Không. Test qua API công khai — private là chi tiết cài đặt, và test bám vào nó sẽ đỏ mỗi lần refactor dù hành vi bên ngoài không đổi. Nếu một hàm private phức tạp đến mức muốn test riêng, đó là dấu hiệu nó nên trở thành một đơn vị độc lập.

Đáp án: C

Snapshot lớn đỏ với mọi thay đổi nhỏ — đổi một class, thêm một thẻ bọc là diff hàng trăm dòng. Người ta chạy -u cho nhanh, và từ đó snapshot không còn phát hiện được gì.

Đáp án: A

Đừng để hàm tự đọc đồng hồ: truyền now vào như tham số (hoặc tiêm một clock), khi đó test chỉ là hàm thuần với đầu vào cố định. Nếu không sửa được chữ ký hàm thì dùng fake timer để đóng băng thời gian.

Đáp án: A

Hai việc song song: chạy test song song (chia shard theo file, mỗi worker một DB riêng) và tách tầng — unit + integration nhanh làm điều kiện merge, e2e đầy đủ chạy sau khi merge hoặc theo lịch.

Đáp án: B

Ưu tiên theo mức thiệt hại nếu sai × độ phức tạp: tính tiền, phân quyền, tồn kho, luồng thanh toán, và mọi chỗ có nhiều nhánh điều kiện. Getter, mapper đơn giản hay code chỉ ghép chuỗi thì để sau.

Đáp án: C

Factory/builder có giá trị mặc định hợp lệ, test chỉ ghi đè phần liên quan: makeUser({ role: 'admin' }). Test đọc dễ vì chỉ thấy thứ quan trọng, và thêm field bắt buộc chỉ cần sửa một chỗ.

Đáp án: A

Ba nhóm quan trọng nhất: phân quyền (không đăng nhập, đăng nhập nhưng không phải chủ tài nguyên), dữ liệu đầu vào sai (thiếu field, kiểu sai, giá trị ngoài khoảng), và tài nguyên không tồn tại. Đó là nơi lỗ hổng thường nằm.

Đáp án: A

renderHook từ Testing Library, và mọi thao tác làm state đổi phải nằm trong act(...). Thiếu act thì React cảnh báo và giá trị đọc ra có thể là trạng thái cũ.

Đáp án: B

Gọi trực tiếp handler với một Request thật (new Request(url, { method, body })) rồi assert status cùng JSON của Response. Không mock req/res — handler nhận đúng loại đối tượng mà framework sẽ đưa vào.

Đáp án: B

Vì nhánh lỗi rất ít được chạy trong thực tế, nên bug ở đó sống lâu và chỉ lộ ra đúng lúc hệ thống đang có sự cố — thời điểm tệ nhất để phát hiện thêm một bug nữa.

Đáp án: A

Tạo ngay trong test, dùng factory: const user = await makeUser(); await makeOrders(user, 3). Test tự chứa nên đọc là biết điều kiện đầu vào, và không vỡ khi dữ liệu seed của môi trường thay đổi.

Đáp án: C

Một mục tiêu đo được: ví dụ "1000 request/giây với p95 dưới 300ms và tỉ lệ lỗi dưới 0,1%". Không có ngưỡng cụ thể thì kết quả chỉ là một đống số, không kết luận được đạt hay không.

Đáp án: D

Assert vào kết quả người dùng thấy: trạng thái loading xuất hiện, rồi dữ liệu hiện ra (await screen.findByText(...)), và khi API lỗi thì thông báo lỗi hiện ra. Không assert vào việc hàm fetch được gọi.

Đáp án: D

Vẫn xanh. Đó chính là phép thử cho chất lượng bộ test: nếu refactor không đổi hành vi mà test đỏ, test đang bám vào chi tiết cài đặt (mock nội bộ, tên hàm, cấu trúc DOM) thay vì hành vi quan sát được.

Đáp án: B

Ảnh lệch vì môi trường: font khác, chống răng cưa khác, tỉ lệ màn hình khác là diff báo đỏ dù giao diện không đổi. Cách xử lý là chụp trong môi trường cố định (container thống nhất) và đặt ngưỡng sai khác cho phép.

Đáp án: D

Test khi có quy tắc riêng dễ sai: định dạng tiền tệ theo vùng, số nhiều, làm tròn, cắt chuỗi theo độ dài. Đừng test lại việc thư viện hoạt động — đó là kiểm tra code của người khác.

Đáp án: C

Đăng nhập một lần trong bước chuẩn bị, lưu cookie/storageState, rồi mỗi test nạp lại trạng thái đó. Vẫn nên có một test đi qua form đăng nhập thật để bảo vệ chính luồng đó.

Đáp án: D

Viết characterization test ở tầng ngoài (API, hàm công khai) để chốt hành vi *hiện tại* — kể cả hành vi trông sai. Có lưới an toàn rồi mới sửa bug, và test cũ cho biết ngay nếu bản sửa làm vỡ chỗ khác.

Đáp án: B

Một test nên mô tả một kịch bản. Có if nghĩa là nó đang gộp hai kịch bản: khi đỏ, bạn không biết nhánh nào sai. Tách thành hai test có tên rõ ràng, hoặc dùng test theo bảng tham số.

Đáp án: C

Rò rỉ trạng thái giữa các test: biến ở mức module, dữ liệu còn lại trong DB, mock chưa được reset, timer chưa được dọn, hoặc biến môi trường bị test khác sửa.

Đáp án: C

Dùng đồng hồ giả của framework: thay các hàm hẹn giờ bằng bản mô phỏng, rồi tua thời gian tới đúng mốc cần. Test chạy tức thì, tất định, và kiểm được cả các mốc trung gian — điều không làm được nếu chờ thật.

Đáp án: B

Thay vì kiểm một vài ví dụ cụ thể, ta khai báo một tính chất luôn đúng — ví dụ "giải mã bản mã hoá luôn cho lại giá trị gốc" — và công cụ sinh hàng trăm đầu vào để tìm phản ví dụ, rồi thu nhỏ nó về trường hợp đơn giản nhất.

Đáp án: A

Chặn ở tầng mạng bằng một mock server chạy trong test. Nhờ đó toàn bộ mã dựng request, đặt header, xử lý mã lỗi và phân tích phản hồi vẫn chạy thật — chỉ có phần đi ra mạng bị thay. Thay thẳng hàm gọi API sẽ bỏ qua chính những phần hay có lỗi.

Đáp án: A

Ghi lại phản hồi thật một lần và phát lại trong test. Cách này giữ đúng cấu trúc thực tế, cho test chạy nhanh và tất định. Kèm theo cần một job chạy định kỳ gọi dịch vụ thật để phát hiện khi bên đó thay đổi.

Đáp án: D

Bọc mỗi test trong một transaction rồi quay lui ở cuối. Nhanh hơn xoá bảng nhiều lần và bảo đảm sạch tuyệt đối. Cần lưu ý: cách này không dùng được khi mã đang test tự quản lý transaction hoặc khi test chạy qua nhiều kết nối.

Đáp án: B

Mọi tài nguyên dùng chung phải cách ly theo luồng: cơ sở dữ liệu (schema riêng), thư mục tạm, cổng mạng, biến môi trường và các file cấu hình. Bỏ sót một thứ sẽ tạo ra lỗi ngẫu nhiên chỉ xuất hiện khi chạy song song.

Đáp án: D

Tập trung vào biên: trang cuối không đầy, danh sách rỗng, và số bản ghi chia hết cho kích thước trang. Quan trọng không kém là giá trị trùng khi sắp xếp — nếu không có tiêu chí phá vỡ trùng, một bản ghi có thể xuất hiện ở hai trang hoặc biến mất.

Đáp án: C

Chú ý làm tròn: chia hoá đơn cho ba người rồi làm tròn từng phần có thể cho tổng lệch một đơn vị nhỏ nhất so với số gốc. Test phải khẳng định tổng các phần bằng đúng số ban đầu, và kiểm cả các mốc làm tròn ở giữa.

Đáp án: C

Gọi hai lần với cùng tham số rồi khẳng định trạng thái hệ thống chỉ thay đổi một lần: một bản ghi được tạo, một lần trừ tiền, một email được gửi. Chỉ nhìn mã trạng thái là không đủ — cả hai lần đều có thể trả về thành công.

Đáp án: D

Bắt được các vi phạm quy tắc rõ ràng: ảnh thiếu văn bản thay thế, nút thiếu nhãn, độ tương phản không đạt, thứ tự tiêu đề sai, phần tử tương tác không truy cập được bằng bàn phím. Đây là phần kiểm được bằng máy, ước tính chỉ chiếm một phần các vấn đề thật.

Đáp án: B

Ba nhóm: thiếu khoá dịch ở một ngôn ngữ nào đó; độ dài văn bản làm vỡ giao diện khi ngôn ngữ khác dài hơn đáng kể; và định dạng theo vùng — ngày tháng, số thập phân, tiền tệ, thứ tự sắp xếp.

Đáp án: A

Phủ các nhánh lỗi: file vượt giới hạn kích thước, định dạng không cho phép (kể cả khi phần mở rộng nói đúng nhưng nội dung thật khác), tên file có ký tự đặc biệt hoặc đường dẫn, và file rỗng. Đây vừa là các nhánh xử lý lỗi vừa là bề mặt tấn công.

Đáp án: C

Khẳng định ở ranh giới hệ thống: email được đưa vào hàng đợi với đúng người nhận, đúng mẫu, và các biến trong nội dung đã được điền đúng. Việc gửi thật thuộc về dịch vụ bên ngoài và nên được kiểm riêng bằng một test chạy theo lịch.

Đáp án: D

Hai nhóm đặc thù: phân quyền theo từng trường — cùng một truy vấn có thể chạm tới trường mà người gọi không được xem; và độ phức tạp truy vấn — một truy vấn lồng sâu có thể tạo tải rất lớn. Cả hai cần test riêng vì REST không có các vấn đề này.

Đáp án: C

Ba nhóm: trượt cache thì lấy từ nguồn và ghi vào cache; trúng cache thì không gọi xuống nguồn; và vô hiệu hoá — sau khi dữ liệu đổi thì lần đọc kế tiếp phải thấy giá trị mới. Nhóm thứ ba là nơi hầu hết lỗi cache nằm ở đó.

Đáp án: D

Test các tổ hợp thực sự tồn tại: trạng thái hiện tại ở production, và trạng thái sau khi bật cờ mới. Số tổ hợp lý thuyết tăng theo cấp số nhân nên phủ hết là bất khả thi, nhưng số cấu hình thật đang chạy thì rất ít.

Đáp án: C

Giả lập phía server: trả lỗi ở hai lần đầu rồi thành công, và khẳng định client thử đúng số lần và chờ đúng khoảng giữa các lần. Dùng đồng hồ giả để không phải chờ thật. Kiểm cả trường hợp mọi lần đều thất bại.

Đáp án: C

Nó gom selector và thao tác của một trang vào một nơi, nên khi giao diện đổi chỉ phải sửa một file thay vì hàng chục test. Test viết ở mức nghiệp vụ — đăng nhập với tài khoản này, thêm sản phẩm kia — thay vì ở mức thao tác trên phần tử.

Đáp án: C

Tách logic xử lý thông điệp ra khỏi phần kết nối: hàm nhận một thông điệp và trả về trạng thái mới thì test được như hàm thuần. Phần kết nối chỉ cần vài test ở tầng cao cho việc kết nối lại, xử lý mất kết nối và thứ tự thông điệp.

Đáp án: A

Render một component con cố ý ném lỗi lúc render rồi khẳng định giao diện dự phòng xuất hiện và hàm ghi nhận lỗi được gọi. Lưu ý cơ chế này không bắt lỗi trong hàm xử lý sự kiện và trong mã bất đồng bộ — đó là giới hạn cần biết khi thiết kế.

Đáp án: B

Dùng bộ sinh có hạt giống: mỗi lần chạy lấy một hạt giống ngẫu nhiên, in nó ra, và khi test đỏ thì chạy lại với đúng hạt giống đó để tái hiện. Nhờ đó vừa có lợi ích khám phá của dữ liệu ngẫu nhiên, vừa gỡ lỗi được.

Đáp án: C

Phủ hai thứ: chạy trên dữ liệu có sẵn — nạp dữ liệu mẫu giống thật rồi chạy di trú và khẳng định dữ liệu được chuyển đổi đúng; và đường quay lui — chạy ngược lại rồi khẳng định schema trở về trạng thái trước.

Đáp án: A

Khẳng định vào quan hệ thứ tự: kết quả khớp chính xác phải đứng trên kết quả khớp một phần; bài viết mới hơn phải đứng trên bài cũ khi độ liên quan tương đương. Khẳng định vào điểm số cụ thể làm test đỏ mỗi lần tinh chỉnh thuật toán.

Đáp án: A

Chọn các mốc gây lỗi: thời điểm đổi giờ mùa hè (có giờ bị lặp và giờ không tồn tại), múi giờ lệch nửa giờ hoặc bốn mươi lăm phút, và các mốc nửa đêm ở nhiều vùng khác nhau. Các thời điểm thông thường gần như luôn đúng nên không phát hiện được gì.

Đáp án: B

Khẳng định vào dữ liệu đưa vào bộ dựng: các dòng hàng, tổng tiền, thông tin khách hàng đã được tính đúng chưa. Đây là phần chứa nghiệp vụ. So byte của file kết quả thì phụ thuộc phiên bản thư viện và dấu thời gian bên trong nên rất dễ vỡ.

Đáp án: A

Đặt hạn mức rất nhỏ trong cấu hình test — ví dụ ba lời gọi mỗi phút — rồi gọi bốn lần và khẳng định lần thứ tư nhận 429. Dùng đồng hồ giả để tua qua cửa sổ và khẳng định hạn mức được đặt lại đúng lúc.

Đáp án: D

Kết hợp hai mức: test từng chuyển trạng thái — dựng trạng thái đầu vào, gọi một hành động, khẳng định trạng thái mới; và một test cho luồng đầy đủ xác nhận các bước ghép nối đúng. Quan trọng nhất là phủ các chuyển trạng thái không hợp lệ.

Đáp án: D

Tập trung vào hàng đợi thao tác cục bộ và việc đồng bộ khi có mạng lại: thao tác được lưu đúng, gửi lên theo đúng thứ tự, và xử lý được trường hợp dữ liệu đã bị người khác sửa trong lúc mất mạng.