NEW
Font size
WorksheetsKiểm thử _ test 2
Total questions: 50
Worksheet time: 25mins
Kiểm thử chấp nhận được chia thành mấy mức?
1
2
3
4
Kiểm thử Alpha được thực hiện bởi ai?
Những người trong tổ chức nhưng không tham gia phát triển phần mềm
Người dùng cuối
Nhà cung cấp phần mềm
Những người tham gia phát triển phần mềm
Kiểm thử Beta được thực hiện ở đâu?
Tại tổ chức phát triển phần mềm
Tại địa điểm của người dùng cuối
Tại phòng kiểm thử nội bộ
Trên môi trường giả lập
Ai là người thực hiện kiểm thử Beta?
Người dùng cuối hoặc khách hàng
Những người phát triển phần mềm
Nhân viên kiểm thử nội bộ
Nhà quản lý dự án
Alpha testing là một dạng của loại kiểm thử nào?
Unit testing
Integration testing
System testing
Acceptance testing
Tại sao kiểm thử này được gọi là Alpha?
Vì nó là giai đoạn kiểm thử cuối cùng
Vì nó được thực hiện sau kiểm thử Beta
Vì nó không được thực hiện trong giai đoạn thiết kế phần mềm mà sau kiểm thử beta
Vì nó được thực hiện sớm, gần cuối phát triển phần mềm, trước kiểm thử Beta
Mục đích chính của Alpha testing là gì?
Kiểm tra khả năng chịu tải của hệ thống
Đánh giá trải nghiệm người dùng cuối
Xác định tất cả các vấn đề/lỗi có thể xảy ra trước khi phát hành sản phẩm
Xác định tất cả các vấn đề/lỗi không thể xảy ra trước khi phát hành sản phẩm
Alpha testing thường được thực hiện khi nào?
Ngay khi phần mềm bắt đầu phát triển
Sau khi phát hành phần mềm ra thị trường
Gần cuối quá trình phát triển phần mềm
Ngoài quá trình bảo trì phần mềm
Lợi thế lớn nhất của Beta testing là gì?
Kiểm tra hiệu suất phần mềm trong môi trường giả lập
Tìm lỗi nhỏ trong mã nguồn
Nhận phản hồi trực tiếp từ người dùng cuối và kiểm tra phần mềm trong môi trường giả lập
Nhận phản hồi trực tiếp từ người dùng cuối và kiểm tra phần mềm trong môi trường thực tế
Phiên bản beta của phần mềm được phát hành cho ai?
Một số lượng hạn chế người trong nội bộ để lấy phản hồi
Một số lượng hạn chế người dùng cuối để lấy phản hồi
Chỉ cho đội kiểm thử nội bộ
Tất cả người dùng trên toàn cầu
Beta testing là một dạng của loại kiểm thử nào?
Integration testing
Acceptance testing
System testing
Unit testing
Sanity testing được thực hiện khi nào?
Sau khi triển khai phần mềm ra thị trường
Sau khi nhận được một bản build với những thay đổi nhỏ về mã hoặc chức năng
Sau khi nhận được một bản build với những thay đổi lớn về mã hoặc chức năng
Sau khi nhận được một bản tài liệu với những thay đổi nhỏ về tài liệu và chức năng
Mục đích chính của Sanity testing là gì?
Kiểm tra toàn bộ hệ thống phần mềm
Kiểm tra khả năng chịu tải của phần mềm
Xác định rằng các lỗi đã được sửa và không gây ra vấn đề mới
Xác định rằng các lỗi đã được sửa và gây ra vấn đề mới
Mục đích chính của Sanity testing là gì?
Xác định rằng chức năng được đề xuất hoạt động gần như mong đợi
Kiểm tra toàn bộ phần mềm một cách chi tiết bởi người dùng cuối để đánh giá trải nghiệm
Kiểm tra hiệu suất hệ thống và cân bằng tài để đánh giá trước khi đóng dự án
Đánh giá trải nghiệm người dùng
Tại sao Sanity testing giúp tiết kiệm thời gian và công sức?
Vì nó kiểm tra toàn bộ phần mềm từ đầu đến cuối
Vì nó chỉ tập trung vào một hoặc một vài vùng ảnh hưởng của chức năng
Vì nó chỉ tập trung vào toàn bộ chức năng của hệ thống
Vì nó không phát hiện lỗi trong phần mềm
Khi nào Smoke Testing được thực hiện?
Sau khi hoàn tất kiểm thử hồi quy
Khi có một bản build mới và các chức năng chính cần được kiểm tra
Khi có một bản build mới và các chức năng chính cần xuất bản
Trước khi phát triển phần mềm
Mục đích chính của Smoke Testing là gì?
Kiểm tra toàn bộ phần mềm một cách chi tiết để không bỏ xót bất kì chức năng hoặc bug gây lỗi nào
Xác định xem build có thiếu sót gì không để tránh lãng phí thời gian và tài nguyên
Tối ưu hiệu suất phần mềm để nâng cao trải nghiệm người dùng
Đánh giá trải nghiệm người dùng
Smoke Testing được thực hiện khi nào trong quá trình kiểm thử?
Sau khi hoàn tất tất cả các giai đoạn kiểm thử
Trước giai đoạn kiểm thử hồi quy
Sau khi phần mềm được triển khai trên môi trường thực tế
Sau kiểm thử hồi quy
Mục đích chính của kiểm thử hồi quy là gì?
Xác định lỗi hiệu suất của hệ thống tránh gây khó khăn trong việc sử dụng
Đảm bảo rằng những thay đổi trong source code không ảnh hưởng đến các chức năng hiện có
Kiểm tra giao diện người dùng của phần mềm có phù hợp và dễ nhìn không
Kiểm tra bảo mật của phần mềm có bị rò rỉ dữ liệu hoặc dễ khai khác không
Kiểm thử hồi quy được thực hiện bằng cách nào?
Kiểm tra một tính năng mới mà không quan tâm đến tính năng cũ
Kiểm thử lại các trường hợp đã thực hiện để đảm bảo các chức năng hiện có vẫn hoạt động tốt
Chỉ kiểm thử code mới mà không quan tâm đến code cũ
Chỉ kiểm tra các chức năng mới được phát triển
Khi nào nên thực hiện kiểm thử hồi quy?
Khi phần mềm được triển khai ra thị trường
Trước khi phát triển phần mềm
Sau khi thay đổi source code để kiểm tra tính ổn định của phần mềm
Khi phần mềm đã ngừng bảo trì
Khi thực hiện kiểm thử hồi quy, có thể áp dụng những phương pháp nào để đảm bảo phần mềm hoạt động ổn định sau khi thay đổi code?
Chỉ thực hiện kiểm thử lại tất cả các test case không quan trọng (UnPrietest All)
Chỉ lựa chọn một số test case ngẫu nhiên thay đổi (Randome Test Selection)
Ưu tiên kiểm thử các test case quan trọng nhất trước (Prioritization of Test Cases)
Cả A, B và C đều là các phương pháp kiểm thử hồi quy
Đâu là đặc điểm chính của kiểm thử tĩnh?
Chạy phần mềm để kiểm tra lỗi trong quá trình thực thi
Kiểm tra bằng cách review mà không cần chạy chương trình
Chỉ được thực hiện sau khi phần mềm đã hoàn thiện
Kiểm tra bằng cách review kết quả của chương trình hiển thị được
Trong kiểm thử tĩnh, những hoạt động review nào thường được thực hiện?
Chạy thử phần mềm để kiểm tra lỗi
Kiểm thử hộp đen và kiểm thử hộp trắng
Hướng dẫn, Đánh giá kĩ thuât, kiểm tra.
Kiểm thử hồi quy và kiểm thử hiệu suất
Đặc điểm nào mô tả chính xác về kiểm thử hộp đen (Black-box Testing)?
Kiểm tra phần mềm bằng cách xem xét mã nguồn bên trong phần mềm như một chiếc hộp đen
Kiểm tra phần mềm mà không cần biết về cấu trúc bên trong phền mềm như một chiếc hộp đen
Chỉ có thể thực hiện bởi các nhà phát triển phần mềm
Cần hiểu rõ cấu trúc bên trong của phần mềm để thực hiện kiểm thử
Trong kiểm thử hộp đen, đối tượng nào thường được kiểm thử?
Một thành phần phần mềm như chức năng, module hoặc phân hệ
Kiểm tra giao diện người dùng mà không quan tâm đến đầu vào và đầu ra
Toàn bộ phần cứng của hệ thống
Chỉ kiểm tra mã nguồn bên trong hệ thống
Đâu là một trong những ưu điểm chính của kiểm thử hộp đen (Black-box Testing)?
Tester cần hiểu rõ mã nguồn và cách phần mềm được triển khai
Chỉ có thể được thực hiện bởi lập trình viên có kinh nghiệm
Tester có thể không cần biết ngôn ngữ lập trình hoặc cách phần mềm được thực hiện
Tester phải hiểu rõ các ngôn ngữ lập trình và cách chức năng phần mềm được thực hiện
Đâu là một nhược điểm của kiểm thử hộp đen (Black-box Testing)?
Bắt buộc phải có kiến thức lập trình để thực hiện kiểm thử
Cần một lượng lớn dữ liệu đầu vào và có thể gặp khó khăn khi thiết kế test case nếu thiếu thông số rõ ràng
Không thể kiểm tra phần mềm từ góc nhìn của người dùng
Cần một lượng lớn dữ liệu đầu vào và không thể gặp khó khăn khi thiết kế test case nếu thiếu thông số rõ ràng
Những phương pháp nào thường được sử dụng trong kiểm thử hộp đen (Black-box Testing)?
Kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống
Phân lớp tương đương, Phân tích giá trị biên, Bảng quyết định
Kiểm thử hồi quy, kiểm thử chịu tải, kiểm thử khả dụng
Phân tích tập hợp, phân tích giá trị gốc, Bảng Kanba
Đâu là lỗi không thuộc kiểm thử hộp đen (Black-box Testing)?
Chức năng không chính xác hoặc thiếu
Lỗi giao diện hoặc hành vi của ứng dụng
Lỗi trong cấu trúc dữ liệu hoặc truy cập cơ sở dữ liệu bên ngoài
Lỗi do sai sót trong thuật toán cài đặt và logic lập trình của chương trình
Theo định nghĩa của ISTQB, Test Plan là gì?
Một tài liệu mô tả chi tiết mã nguồn của phần mềm
Một tài liệu mô tả phạm vi, cách tiếp cận, nguồn lực và lịch trình của các hoạt động kiểm tra dự kiến
Một tài liệu xác định chiến lược kiểm thử, phạm vi, tài nguyên và lịch trình phát triển hệ thống
Một kế hoạch phát triển phần mềm do nhóm lập trình viên thực hiện
Mục đích của bước so sánh kết quả kiểm thử với kết quả kỳ vọng trong kiểm thử hộp đen là gì?
Không có ý nghĩa quan trọng trong quy trình kiểm thử
Xác nhận rằng phần mềm hoạt động chính xác theo yêu cầu
Chỉ để ghi nhận dữ liệu đầu vào của test case
Xác định sự khác biệt giữa kết quả thực tế và mong đợi, từ đó lập báo cáo kiểm thử
Khi định nghĩa một test case trong kiểm thử hộp đen, thông tin nào cần được xác định?
Tên lập trình viên đã viết chức năng cần kiểm thử
Giá trị dữ liệu nhập, trạng thái của phần mềm, giá trị dữ liệu xuất
Danh sách tất cả các lỗi từng xuất hiện trong hệ thống
Cách thức phần mềm hoạt động ở cấp độ mã nguồn
Điền vào chỗ trống các từ khóa còn thiếu trong các bước kiểm thử hộp đen sau:
Bước 1: Phân tích _______ về các _______ mà TPPM cần thực hiện.
Bước 2: Dùng một kỹ thuật định nghĩa các _______ để định nghĩa các testcase.
Bước 3: _______ các testcase đã định nghĩa.
Bước 4: So sánh kết quả thu được với _______ trong từng testcase, từ đó lập báo cáo về kết quả kiểm.
(yêu cầu, chức năng, thuật toán, lỗi)
(đặc tả, yêu cầu chức năng, testcase xác định, kiểm thử, kết quả kỳ vọng)
(thiết kế, quy trình, tham số, báo cáo)
(hệ thống, phương pháp, kiểm thử tự động, kết quả thực tế)
Tại sao Test Plan lại quan trọng trong quá trình kiểm thử phần mềm?
Chỉ dành riêng cho nhóm kiểm thử và không cần thiết với các bên liên quan khác
Giúp các bên liên quan hiểu kế hoạch phát triển phần mềm, đóng vai trò như một quy tắc ứng xử và lưu trữ thông tin nội bộ để tham khảo trong tương lai
Giúp các bên liên quan hiểu kế hoạch kiểm thử, đóng vai trò như một quy tắc hướng dẫn và lưu trữ thông tin quan trọng để tham khảo trong tương lai
Được sử dụng chủ yếu để viết mã kiểm thử tự động mà không liên quan đến quản lý dự án
Điền vào chỗ trống các từ khóa còn thiếu trong các bước thiết kế chiến lược kiểm thử trong Test Plan sau:
Bước 1: Xác định _______ kiểm thử.
Bước 2: Xác định _______ kiểm thử.
Bước 3: _______ về rủi ro và vấn đề.
Bước 4: Tạo _______.
(quy trình, phạm vi, báo cáo, chiến lược)
(phạm vi, loại, tài liệu, test logistics)
(mục tiêu, chiến lược, kế hoạch, logistics)
(kịch bản, phương pháp, đánh giá, quy trình)
Trước khi bắt đầu giai đoạn kiểm thử, những sản phẩm thử nghiệm nào cần được cung cấp?
Mã nguồn hoàn chỉnh của phần mềm
Tester cần có công cụ kiểm thử tự động
Tài liệu kế hoạch kiểm tra, tài liệu trường hợp thử nghiệm, kiểm tra thông số kỹ thuật thiết kế
Tài liệu về nhân sự, tài liệu trường hợp tai nạn, thông số kĩ thuật và báo cáo kết quả thử nghiệm kiểm thử
Trong quá trình thử nghiệm, những sản phẩm thử nghiệm nào cần được cung cấp?
Chỉ cần có tài liệu kế hoạch kiểm tra và tài liệu trường hợp thử nghiệm
Mã nguồn phần mềm và tài liệu hướng dẫn sử dụng
Tập lệnh thử nghiệm, trình mô phỏng, dữ liệu thử nghiệm, kiểm tra ma trận xác định nguồn gốc, nhật ký lỗi và nhật ký thực thi
Tập lệnh thực thi, trình mô tả, dữ liệu khách hàng, kiểm tra ma trận xác định nguồn gốc, nhật ký vào ra và nhật ký thực thi
Sau khi các chu kỳ thử nghiệm kết thúc, những sản phẩm thử nghiệm nào cần được cung cấp?
Mã nguồn cuối cùng của phần mềm
Danh sách các lỗi chưa sửa nhưng không có báo cáo chi tiết
Kết quả/báo cáo của bản kế hoạch phát triển, báo cáo ưu điểm, hướng dẫn quy trình kiểm tra, ghi chú thời gian thực hiện
Kết quả/báo cáo thử nghiệm, báo cáo khiếm khuyết, hướng dẫn quy trình cài đặt/kiểm tra, ghi chú phát hành
Điền vào chỗ trống các từ khóa còn thiếu trong các bước xác định Testcase sau:
Bước 1: Xác định _______ test.
Bước 2: Xác định _______ testing.
Bước 3: Xác định _______ _______.
Bước 4: Xác định _______ cho TCs.
Bước 5: Xác định _______ _______ giữa các nguyên tắc mô-đun.
(mục tiêu, tốc độ, chức năng chính, định dạng, sự khác biệt)
(chiến lược, khả năng mở rộng, yêu cầu bảo mật, template, tính tương thích)
(mục đích, hiệu suất, yêu cầu phi chức năng, biểu mẫu, tính ảnh hưởng)
(phạm vi, độ tin cậy, yêu cầu kỹ thuật, quy trình, quan hệ)
Những yếu tố nào quan trọng trong quá trình viết TestCase
Các TestCase luôn cố định và không cần cập nhật thường xuyên.
Các TestCase nên được viết một lần, không cần sửa đổi, không cần phân bổ giữa các Tester trong nhóm.
Các TestCase có thể thay đổi nhưng không cần phân nhóm, không có sự phụ thuộc hoặc liên kết với nhau trong toàn bộ bộ test
Các TestCase có xu hướng sửa đổi và cập nhật thường xuyên, phân bổ giữa các Tester, phân cụm theo nhóm và có thể phụ thuộc lẫn nhau
Mục tiêu chính của việc viết Test Case là gì?
Đảm bảo ứng dụng không bao giờ có lỗi và hoạt động hoàn hảo trong mọi trường hợp.
Xác nhận phạm vi thử nghiệm của một ứng dụng để đảm bảo tất cả các chức năng cần thiết đều được kiểm tra
Xác nhận rằng ứng dụng được phát triển đúng theo yêu cầu mà không cần kiểm thử thực tế
Giúp nhóm phát triển hiểu rõ hơn về mã nguồn mà không cần thực hiện kiểm thử
Test Case là gì?
Một tài liệu mô tả cách lập trình ứng dụng để đảm bảo nó hoạt động đúng
Một tập hợp các hướng dẫn kiểm thử giúp xác thực một mục tiêu cụ thể và kiểm tra hành vi mong đợi của hệ thống
Một tài liệu mô tả cách lập trình ứng dụng để đảm bảo nó hoạt động đúng
Một tập hợp các hướng dẫn viết chương trình với mục tiêu cụ thể và thực thi hành vi mong đợi của hệ thống
Thành phần nào sau đây không thuộc cấu trúc cần thiết khi viết Test Case
Test case id
Code implementation.
Steps to be executed
Expected Result
Thành phần nào sau đây không phải là một phần của Test Case
Pass/Fail
System requirements document
Test data
Comments
Thành phần nào trong Test Case cho biết hệ thống có hoạt động đúng với kết quả mong đợi hay không
Assumptions
Pass/Fail
Steps to be executed
Unit to test
Thành phần nào trong Test Case mô tả dữ liệu được sử dụng để kiểm tra?
Test case id
Expected Result
Test data
Comments
Yếu tố nào không phải là một phần của Test Plan?
Lịch trình & Dự toán (Schedule & Estimation)
Viết mã kiểm thử tự động (Write Automation Scripts)
Thiết kế chiến lược kiểm thử (Design the Test Strategy)
Xác định tiêu chí kiểm thử (Define Test Criteria)
Điền từ còn thiếu vào chỗ trống:
Bước 1: ___ sản phẩm (Analyze the product)
Bước 2: Thiết kế ___ kiểm thử (Design the Test Strategy)
Bước 3: Xác định ___ kiểm thử (Define the Test Objectives)
Bước 4: Xác định ___ kiểm thử (Define Test Criteria)
Đánh giá, kế hoạch, tiêu chí, sản phẩm
Phân tích, chiến lược, mục tiêu, tiêu chí
Định nghĩa, tài nguyên, tiêu chí, môi trường
Kiểm tra, hoạch định, mục tiêu, tài nguyên
Điền từ còn thiếu vào chỗ trống để hoàn thành các bước của Test Plan:
Bước 5: Hoạch định ___ (Resource Planning)
Bước 6: Lên kế hoạch ___ kiểm thử (Test Environment)
Bước 7: ___ & Dự toán (Schedule & Estimation)
Bước 8: Xác định ___ kiểm thử (Determine Test Deliverables)
dự án, kiểm thử, phạm vi, báo cáo
chiến lược, tiêu chí, tài nguyên, báo cáo
nguồn lực, môi trường, lịch trình, sản phẩm
tài nguyên, thử nghiệm, quy trình, kết quả
