Đề thi, bài tập trắc nghiệm online Kiểm thử phần mềm – Đề 4

Trong mô hình chữ V, mỗi giai đoạn kiểm thử được liên kết với một giai đoạn phát triển tương ứng. Kiểm thử hệ thống (System Testing) xác minh rằng hệ thống đáp ứng các yêu cầu đã được xác định trong giai đoạn Yêu cầu.

Tự động hóa kiểm thử mang lại nhiều lợi ích như giảm chi phí, tăng tốc độ, và cải thiện độ tin cậy. Tuy nhiên, nó không thể loại bỏ hoàn toàn nhu cầu kiểm thử thủ công. Kiểm thử thủ công vẫn cần thiết cho các loại kiểm thử khám phá (exploratory testing), kiểm thử khả năng sử dụng, và các trường hợp phức tạp hoặc mới.

Test Stub và Test Driver được sử dụng trong kiểm thử tích hợp, đặc biệt là kiểm thử tích hợp từ trên xuống (top-down) và từ dưới lên (bottom-up). Stub thay thế các module phụ thuộc chưa phát triển, Driver thay thế module gọi để kiểm thử các module cấp thấp hơn.

Kiểm thử cặp đôi (Pairwise testing) là một kỹ thuật thiết kế test case hộp đen. Nó dựa trên nguyên tắc rằng hầu hết các lỗi phần mềm được kích hoạt bởi sự tương tác của một cặp tham số đầu vào. Pairwise testing tạo ra test case để kiểm tra tất cả các cặp kết hợp có thể của các tham số đầu vào, giúp giảm đáng kể số lượng test case so với kiểm tra tất cả các kết hợp (exhaustive testing) mà vẫn phát hiện được nhiều lỗi.

Statement Coverage (Bao phủ lệnh) là một kỹ thuật kiểm thử hộp trắng. Nó tập trung vào việc đảm bảo rằng mỗi lệnh trong mã nguồn đã được thực thi ít nhất một lần bởi các test case. Các kỹ thuật còn lại (Boundary Value Analysis, Equivalence Partitioning, Decision Table Testing) đều là các kỹ thuật kiểm thử hộp đen.

Kiểm thử chấp nhận được thực hiện bởi người dùng cuối hoặc khách hàng (hoặc đại diện của họ). Mục đích là xác minh rằng phần mềm đáp ứng các yêu cầu kinh doanh và mong đợi của họ, và sẵn sàng để được chấp nhận và đưa vào sử dụng thực tế.

Phân vùng tương đương là một kỹ thuật thiết kế test case hộp đen. Nó chia miền đầu vào thành các phân vùng tương đương, sao cho việc chọn một giá trị bất kỳ từ một phân vùng sẽ có kết quả tương tự như chọn giá trị khác trong cùng phân vùng. Điều này giúp giảm đáng kể số lượng test case cần thiết mà vẫn đảm bảo kiểm thử hiệu quả các trường hợp điển hình.

Kiểm thử trong Agile là một hoạt động liên tục và lặp đi lặp lại trong suốt mỗi sprint. Nó tích hợp chặt chẽ với quá trình phát triển, với mục tiêu phát hiện và sửa lỗi càng sớm càng tốt. Kiểm thử thường được thực hiện bởi cả nhà phát triển và kiểm thử viên, và đôi khi cả các thành viên khác trong nhóm.

Kiểm thử khám phá (Exploratory Testing) là một phương pháp kiểm thử ít dựa vào kế hoạch và kịch bản chi tiết. Kiểm thử viên đồng thời học về hệ thống, thiết kế và thực hiện kiểm thử, và ghi nhận kết quả. Mục tiêu chính là tìm ra lỗi nhanh chóng và hiệu quả, đặc biệt trong các khu vực chức năng mới hoặc phức tạp, hoặc các khu vực có rủi ro cao mà có thể chưa được kiểm thử kỹ bằng các phương pháp truyền thống.

SonarQube là một công cụ phân tích mã tĩnh phổ biến. Nó giúp phát hiện các lỗi tiềm ẩn, lỗ hổng bảo mật, và các vấn đề về chất lượng mã (như code smells, code duplication) trong mã nguồn, từ đó cải thiện chất lượng và độ tin cậy của phần mềm.

Kiểm thử API tập trung vào việc kiểm tra giao tiếp và tương tác giữa các thành phần phần mềm thông qua API (Application Programming Interface). Nó xác minh rằng API hoạt động đúng như mong đợi, dữ liệu được truyền tải chính xác, và các thành phần phần mềm có thể giao tiếp với nhau một cách hiệu quả.

Các bước tái hiện lỗi (steps to reproduce) là thông tin quan trọng nhất trong báo cáo lỗi. Chúng cho phép nhà phát triển chính xác tái hiện lại lỗi và hiểu được nguyên nhân gốc rễ, từ đó sửa lỗi hiệu quả. Môi trường kiểm thử cũng quan trọng, nhưng bước tái hiện là yếu tố then chốt để sửa lỗi.

Kiểm thử chuyển trạng thái (State Transition Testing) phù hợp với các hệ thống có hành vi dựa trên trạng thái, tức là hệ thống mà hành vi của nó thay đổi tùy thuộc vào trạng thái hiện tại và các sự kiện xảy ra. Ví dụ: hệ thống điều khiển, hệ thống giao thức, hoặc các ứng dụng có quy trình làm việc phức tạp.

Kiểm thử chấp nhận (Acceptance testing) thường là giai đoạn kiểm thử cuối cùng trước khi phát hành phần mềm. Nó được thực hiện sau khi kiểm thử hệ thống và trước khi phần mềm được đưa vào sử dụng thực tế. Mục đích là xác nhận rằng phần mềm đã sẵn sàng để được chấp nhận bởi người dùng/khách hàng.

Kiểm thử hiệu năng tập trung vào các khía cạnh phi chức năng như tốc độ, khả năng chịu tải, độ ổn định, và khả năng sử dụng tài nguyên. Lỗi chức năng là mục tiêu của các loại kiểm thử chức năng (như kiểm thử hộp đen, kiểm thử hệ thống...). Các lỗi còn lại (tràn bộ nhớ, thời gian phản hồi chậm, khả năng chịu tải kém) đều liên quan trực tiếp đến hiệu năng.

Selenium là một công cụ tự động hóa kiểm thử chức năng web, chủ yếu được sử dụng cho kiểm thử giao diện người dùng. JMeter, LoadRunner, và Gatling là các công cụ phổ biến được sử dụng rộng rãi trong kiểm thử hiệu năng để mô phỏng tải người dùng và đo lường hiệu suất hệ thống.

Kiểm thử hộp đen kiểm tra chức năng của phần mềm mà không cần biết cấu trúc bên trong. Nó tập trung vào việc xác minh rằng phần mềm hoạt động đúng như mong đợi từ góc độ người dùng, tức là giao diện và chức năng.

Verification là quá trình đảm bảo rằng 'chúng ta xây dựng sản phẩm đúng cách' (building the product right), tập trung vào quy trình phát triển, tiêu chuẩn, và đặc tả. Validation là quá trình đảm bảo rằng 'chúng ta xây dựng đúng sản phẩm' (building the right product), tập trung vào việc sản phẩm đáp ứng yêu cầu và mong đợi của người dùng/khách hàng.

Kiểm thử tải (Load testing) là một loại kiểm thử hiệu năng, tập trung vào việc đánh giá hiệu suất hệ thống dưới tải trọng dự kiến. Penetration testing, vulnerability scanning, và security auditing là các loại kiểm thử bảo mật, nhằm phát hiện và đánh giá các lỗ hổng và rủi ro bảo mật trong hệ thống.

Quyết định dừng kiểm thử nên dựa trên các tiêu chí dừng kiểm thử (exit criteria) đã được xác định từ trước trong kế hoạch kiểm thử. Các tiêu chí này có thể bao gồm độ bao phủ mã đạt yêu cầu, số lượng lỗi nghiêm trọng giảm xuống dưới mức chấp nhận, hoặc đạt được một mức độ tin cậy nhất định. Đôi khi, yếu tố thời gian và ngân sách cũng ảnh hưởng đến quyết định dừng kiểm thử, nhưng tiêu chí dừng kiểm thử vẫn là yếu tố chính.

Độ bao phủ mã là một số liệu đo lường hiệu quả kiểm thử, cho biết tỷ lệ phần trăm dòng lệnh, nhánh, hoặc đường dẫn trong mã nguồn đã được thực thi (bao phủ) bởi các bộ kiểm thử. Mục tiêu là đảm bảo các phần quan trọng của mã đã được kiểm tra.

Kiểm thử đơn vị được thực hiện đầu tiên, ngay sau khi các đơn vị mã (modules, functions) được phát triển. Mục đích là kiểm tra tính đúng đắn của từng đơn vị mã riêng lẻ trước khi tích hợp chúng lại.

Kiểm thử chấp nhận (Acceptance testing), còn được gọi là User Acceptance Testing (UAT), được thực hiện bởi người dùng cuối hoặc khách hàng để xác minh rằng phần mềm đáp ứng nhu cầu và mong đợi của họ trong môi trường sử dụng thực tế.

Kiểm thử tải (Load testing) kiểm tra hiệu suất hệ thống dưới tải trọng dự kiến hoặc tải trọng cao nhưng vẫn trong giới hạn hoạt động bình thường. Kiểm thử chịu tải (Stress testing) đẩy hệ thống vượt quá giới hạn chịu tải bình thường để xem hệ thống phản ứng như thế nào khi gặp điều kiện tải cực đoan, và xác định điểm gãy của hệ thống.

Mật độ lỗi (Defect Density) là một số liệu chất lượng phần mềm, đo lường số lượng lỗi được tìm thấy trên một đơn vị kích thước mã (thường là trên 1000 dòng code - KLOC). Nó được sử dụng để đánh giá chất lượng mã nguồn và hiệu quả của quy trình phát triển và kiểm thử.

Kiểm thử đột biến (Mutation Testing) là một phương pháp đánh giá tính hiệu quả của bộ test case. Nó thực hiện bằng cách tạo ra các 'đột biến' nhỏ trong mã nguồn (ví dụ: thay đổi một toán tử, một giá trị). Sau đó, bộ test case được chạy lại để xem liệu chúng có thể phát hiện ra các đột biến này hay không. Nếu bộ test case tốt, nó sẽ 'giết' được nhiều đột biến (tức là phát hiện ra sự thay đổi). Nếu không, bộ test case cần được cải thiện.

Kiểm thử khả năng sử dụng (Usability testing) tập trung vào việc đánh giá mức độ dễ sử dụng, hiệu quả, và sự hài lòng của người dùng khi tương tác với phần mềm. Nó đánh giá các khía cạnh như giao diện trực quan, dễ học, dễ nhớ, và đáp ứng nhu cầu người dùng.

Kiểm thử hồi quy là bắt buộc sau bất kỳ thay đổi nào trong mã nguồn (sửa lỗi, thêm tính năng, thay đổi cấu hình...) hoặc môi trường (nâng cấp hệ điều hành, thư viện...). Mục đích là đảm bảo rằng các thay đổi mới không gây ra lỗi ở các chức năng đã hoạt động trước đó.

Phân tích giá trị biên là một kỹ thuật kiểm thử hộp đen. Nó tập trung vào việc kiểm tra các giá trị tại biên của miền đầu vào (input domain) và các giá trị ngay trên và dưới biên. Mục đích là tìm ra lỗi có thể xảy ra tại các giới hạn đầu vào.

Quản lý Test Case tập trung vào việc tổ chức, lưu trữ, theo dõi trạng thái thực thi, và báo cáo kết quả của các test case. Nó giúp kiểm thử viên quản lý hiệu quả số lượng lớn test case, đảm bảo tính nhất quán và khả năng truy vết trong quá trình kiểm thử.