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

Mật độ lỗi (defect density) là số lượng lỗi được tìm thấy trên một đơn vị kích thước của phần mềm (ví dụ, lỗi trên 1000 dòng mã - KLOC). Nó là một chỉ số chất lượng, thường đượ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 phần mềm.

Phân tích yêu cầu thị trường là một hoạt động thuộc giai đoạn phân tích yêu cầu trong quy trình phát triển phần mềm, nhưng không phải là một công đoạn trực tiếp trong quy trình kiểm thử phần mềm. Quy trình kiểm thử thường bắt đầu sau khi có các yêu cầu phần mềm rõ ràng.

Trong kiểm thử phần mềm, `false positive′ (dương tính giả) xảy ra khi một trường hợp kiểm thử báo cáo có lỗi (failed) nhưng thực tế không có lỗi nào tồn tại. Điều này có thể do lỗi trong trường hợp kiểm thử, môi trường kiểm thử hoặc công cụ kiểm thử.

Kiểm thử chấp nhận (Acceptance testing), đặc biệt là kiểm thử chấp nhận của người dùng (User Acceptance Testing - UAT), thường được thực hiện bởi người dùng cuối hoặc khách hàng để đảm bảo 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ử theo cặp (pairwise testing) là một kỹ thuật kiểm thử hộp đen giúp giảm số lượng trường hợp kiểm thử bằng cách đảm bảo rằng mỗi cặp kết hợp của các tham số đầu vào được kiểm thử ít nhất một lần. Nó hiệu quả hơn so với việc kiểm thử tất cả các tổ hợp nhưng vẫn bao phủ nhiều trường hợp quan trọng.

Độ bao phủ mã là một thước đo đánh giá mức độ mà mã nguồn đã được thực thi bởi các trường hợp kiểm thử. Nó thường được biểu diễn bằng phần trăm, ví dụ như phần trăm dòng lệnh, nhánh rẽ, hoặc đường dẫn đã được kiểm thử.

Kiểm thử stress (stress testing) là một loại kiểm thử hiệu năng nhằm mục đích đẩy hệ thống đến giới hạn hoặc vượt quá tải bình thường để xác định điểm tới hạn, khả năng chịu đựng và khả năng phục hồi của hệ thống khi gặp tình huống tải cao hoặc bất thường.

Kiểm thử tích hợp từ dưới lên (bottom-up integration testing) bắt đầu bằng việc kiểm thử các module cấp thấp nhất (đơn vị) một cách riêng lẻ, sau đó tích hợp và kiểm thử các nhóm module này dần dần, tiến lên các module cấp cao hơn trong kiến trúc hệ thống.

Kiểm thử dựa trên rủi ro (risk-based testing) là một phương pháp kiểm thử ưu tiên các khu vực hoặc module của phần mềm có rủi ro cao hơn (ví dụ, có khả năng lỗi cao hơn hoặc ảnh hưởng lớn hơn nếu có lỗi). Nó giúp tập trung nguồn lực kiểm thử vào những nơi quan trọng nhất.

Test harness (bộ khung kiểm thử) là một môi trường hoặc hệ thống được tạo ra để hỗ trợ việc thực hiện kiểm thử tự động. Nó thường bao gồm các công cụ, dữ liệu kiểm thử, và giao diện để thiết lập, thực thi các trường hợp kiểm thử và thu thập kết quả một cách tự động.

Kiểm thử xâm nhập (penetration testing) là một loại kiểm thử bảo mật chủ động, trong đó các chuyên gia bảo mật (pentester) mô phỏng các cuộc tấn công mạng thực tế để tìm kiếm và khai thác các lỗ hổng bảo mật trong hệ thống. Mục tiêu là đánh giá khả năng phòng thủ của hệ thống.

Kỹ thuật giá trị biên dựa trên nguyên tắc rằng lỗi thường xảy ra ở biên của các miền giá trị đầu vào. Do đó, nó tập trung vào việc kiểm thử các giá trị biên, giá trị ngay trên và dưới biên của mỗi phân vùng tương đương.

Trong mô hình chữ V, `Kiểm thử hệ thống′ được thực hiện sau giai đoạn `Thiết kế kiến trúc′ và xác minh rằng hệ thống đã được xây dựng đúng theo thiết kế kiến trúc và đáp ứng các yêu cầu hệ thống.

Kiểm thử hộp trắng, còn gọi là kiểm thử hộp kính, đòi hỏi người kiểm thử phải hiểu rõ cấu trúc mã nguồn để thiết kế các trường hợp kiểm thử bao phủ các đường dẫn thực thi, nhánh rẽ và điều kiện trong mã.

Kiểm thử hộp đen tập trung vào việc kiểm tra chức năng của phần mềm từ góc độ người dùng, không cần biết cấu trúc bên trong của nó. Do đó, nó kiểm tra giao diện và chức năng bên ngoài.

Kiểm thử khả năng sử dụng (usability testing) là một loại kiểm thử phi chức năng tập trung vào việc đánh giá mức độ dễ dàng 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á trải nghiệm người dùng tổng thể.

Kiểm thử alpha thường được thực hiện nội bộ bởi đội ngũ phát triển trong môi trường phòng thí nghiệm hoặc môi trường phát triển. Kiểm thử beta được thực hiện bởi người dùng cuối thực tế trong môi trường sử dụng của họ, bên ngoài tổ chức phát triển.

Kiểm thử thăm dò (exploratory testing) là một phương pháp kiểm thử ít cấu trúc hơn, trong đó người kiểm thử đồng thời học hỏi về phần mềm, thiết kế và thực hiện các trường hợp kiểm thử. Nó nhấn mạnh sự linh hoạt, sáng tạo và khám phá trong quá trình kiểm thử.

Quản lý lỗi là một quy trình có hệ thống để ghi nhận, theo dõi, ưu tiên, gán trách nhiệm, xác minh sửa lỗi và đóng các lỗi (defect∕bug) được phát hiện trong quá trình kiểm thử. Mục tiêu là đảm bảo tất cả các lỗi được xử lý một cách hiệu quả.

Phân vùng tương đương là một kỹ thuật kiểm thử hộp đen. Nó chia dữ liệu đầu vào thành các phân vùng tương đương, sao cho việc kiểm thử một giá trị trong phân vùng sẽ tương đương với việc kiểm thử bất kỳ giá trị nào khác trong cùng phân vùng đó.

Kiểm thử đơn vị tập trung vào việc kiểm tra các thành phần nhỏ nhất của phần mềm (đơn vị, module). Do đó, nó thường phát hiện các lỗi logic, lỗi thuật toán hoặc lỗi lập trình cụ thể trong từng module.

Kiểm thử khói (smoke test) là một loại kiểm thử nhanh chóng và sơ bộ được thực hiện sau mỗi lần build mã nguồn mới để đảm bảo rằng các chức năng cốt lõi của phần mềm hoạt động ổn định. Nếu smoke test thất bại, build đó sẽ bị từ chối và không được chuyển sang giai đoạn kiểm thử sâu hơn.

Kiểm thử hồi quy được thực hiện để đảm bảo rằng các thay đổi mã mới không làm hỏng các chức năng hiện có của phần mềm. Nó giúp phát hiện các lỗi vô tình được đưa vào do thay đổi.

Khả năng chịu tải trong kiểm thử hiệu năng thường được đo bằng số lượng giao dịch mà hệ thống có thể xử lý thành công trong một giây (Transactions Per Second - TPS). Đây là chỉ số quan trọng để đánh giá hiệu suất hệ thống dưới tải.

Kiểm thử chấp nhận được thực hiện để xác minh rằng phần mềm đáp ứng các tiêu chí chấp nhận đã được xác định bởi người dùng hoặc khách hàng. Mục tiêu là đảm bảo phần mềm đáp ứng nhu cầu kinh doanh và yêu cầu sử dụng thực tế.

Test closure (kết thúc kiểm thử) là giai đoạn cuối cùng của quy trình kiểm thử, bao gồm các hoạt động như tổng kết kết quả kiểm thử, đánh giá chất lượng phần mềm, tạo báo cáo kết thúc kiểm thử, bàn giao các tài liệu kiểm thử và đánh giá bài học kinh nghiệm cho các dự án sau.

Một trường hợp kiểm thử (test case) là một tài liệu chi tiết mô tả các bước, dữ liệu đầu vào, điều kiện tiên quyết và kết quả mong đợi để xác minh một khía cạnh cụ thể của chức năng phần mềm. Nó là đơn vị cơ bản của kiểm thử.

Selenium là một framework phổ biến được sử dụng để tự động hóa kiểm thử giao diện người dùng (UI) cho các ứng dụng web. Nó cho phép tương tác với các thành phần UI như trình duyệt, nút, trường văn bản, v.v.

Mặc dù trong một số ngữ cảnh có thể phân biệt `bug′ và `defect′ (ví dụ, defect có thể chỉ sai sót trong yêu cầu hoặc thiết kế, còn bug là lỗi trong mã), trong thực tế kiểm thử phần mềm, hai thuật ngữ này thường được sử dụng hoán đổi cho nhau để chỉ bất kỳ sai lệch nào so với hành vi mong đợi của phần mềm.

Kiểm thử tự động đặc biệt hiệu quả và mang lại lợi ích lớn nhất cho các kiểm thử hồi quy, vì chúng thường được thực hiện lặp đi lặp lại sau mỗi lần thay đổi mã. Tự động hóa giúp tiết kiệm thời gian, công sức và đảm bảo tính nhất quán trong kiểm thử hồi quy.