Xem thêm

150 câu hỏi và câu trả lời phỏng vấn kiểm thử phần mềm hàng đầu (Phần I)

Huy Erick
Exploratory Testing - Kiểm thử thăm dò Exploratory Testing (Kiểm thử thăm dò) là một cách tiếp cận kiểm thử phần mềm trong đó người kiểm thử tham gia vào việc lập kế hoạch và...

Exploratory Testing - Kiểm thử thăm dò

Exploratory Testing (Kiểm thử thăm dò) là một cách tiếp cận kiểm thử phần mềm trong đó người kiểm thử tham gia vào việc lập kế hoạch và thực hiện kiểm thử. Việc lập kế hoạch bao gồm tạo ra điều kiện kiểm thử, một tuyên bố ngắn về phạm vi của nỗ lực kiểm thử ngắn (1 đến 2 giờ), các mục tiêu và các phương pháp khả thi sẽ được sử dụng. Thiết kế kiểm thử và thực hiện kiểm thử được thực hiện đồng thời với điều kiện kiểm thử, test case hoặc các kịch bản kiểm thử. Điều này không có nghĩa là các kỹ thuật kiểm thử khác sẽ không được sử dụng.

Ví dụ, kiểm thử viên có thể quyết định sử dụng phân tích giá trị biên nhưng chỉ kiểm tra các giá trị biên quan trọng nhất mà không cần ghi lại. Một số ghi chú sẽ được viết trong phiên kiểm thử thăm dò và báo cáo có thể được tạo sau đó.

Use case - Tính năng tương tác giữa người dùng và hệ thống

Use case là danh sách các tính năng tương tác giữa người dùng (xác định role) và hệ thống. Use case giúp xác định và thực hiện các yêu cầu chức năng của ứng dụng từ đầu đến cuối.

SDLC và STLC - Quá trình phát triển và xác nhận phần mềm

SDLC liên quan đến việc phát triển/mã hóa phần mềm, trong khi STLC liên quan đến việc xác nhận xử lý và xác minh phần mềm.

Mối quan hệ giữa trường hợp kiểm thử và yêu cầu

Mối quan hệ giữa trường hợp kiểm thử và yêu cầu được liên kết với nhau thông qua một tài liệu gọi là ma trận truy xuất nguồn gốc.

Kiểm thử phân vùng tương đương

Kiểm thử phân vùng tương đương là một kỹ thuật kiểm thử phần mềm trong đó dữ liệu đầu vào của ứng dụng được chia thành các phân vùng tương đương nhau. Mỗi phân vùng tương đương sẽ cho kết quả đầu ra giống nhau. Phương pháp kiểm thử này giúp giảm thời gian kiểm thử phần mềm.

Kiểm thử hộp trắng và kiểm thử hộp đen

Kiểm thử hộp trắng là kỹ thuật liên quan đến việc lựa chọn các trường hợp kiểm thử dựa trên phân tích cấu trúc bên trong của một chức năng hoặc một hệ thống. Nó còn được gọi là kiểm thử dựa trên mã hoặc kiểm thử cấu trúc.

Các loại thử nghiệm hộp trắng bao gồm:

  • Kiểm thử đường cơ bản - Đồ thị dòng
  • Kiểm thử dựa trên luồng điều khiển

Kiểm thử hộp đen là phương pháp kiểm thử phần mềm mà không cần biết cấu trúc bên trong của chức năng hoặc chương trình. Nó thường được sử dụng để kiểm tra chức năng của một ứng dụng.

Các kỹ thuật kiểm thử hộp đen bao gồm:

  • Phân vùng tương đương
  • Phân tích giá trị biên
  • Kiểm thử dựa vào đồ thị
  • Sử dụng bảng quyết định

Kiểm tra tĩnh và kiểm thử động

Kiểm tra tĩnh: Trong phương pháp kiểm thử tĩnh, mã lệnh không được thực thi, mà chủ yếu kiểm tra tính đúng đắn của mã lệnh, thuật toán hoặc tài liệu.

Kiểm thử động: Để thực hiện kiểm thử động, mã lệnh được yêu cầu phải được thực thi.

Xác minh và xác thực

Xác minh là quá trình đánh giá phần mềm trong giai đoạn phát triển để xác định xem ứng dụng có thỏa mãn các yêu cầu đã chỉ định hay không.

Xác thực là quá trình đánh giá phần mềm sau quá trình phát triển để kiểm tra xem phần mềm có đáp ứng yêu cầu của khách hàng hay không.

Các cấp độ kiểm thử

Có bốn cấp độ kiểm thử:

  • Kiểm thử đơn vị - Kiểm thử mức đơn vị
  • Kiểm thử tích hợp - Kiểm thử tích hợp các mô-đun
  • Kiểm thử hệ thống - Kiểm thử toàn bộ hệ thống
  • Kiểm thử chấp nhận - Kiểm thử chấp nhận từ người dùng

Kiểm thử tích hợp

Kiểm thử tích hợp là một cấp độ kiểm thử trong quy trình kiểm thử phần mềm, trong đó các mô-đun phần mềm riêng lẻ được kết hợp và kiểm tra. Nó thường được thực hiện sau kiểm thử đơn vị và kiểm thử chức năng.

Test Plan - Kế hoạch kiểm thử

Test Plan là một tài liệu mô tả phạm vi, cách tiếp cận, tài nguyên và lịch trình của các hoạt động kiểm thử. Một Test Plan sẽ bao gồm:

  • Mục tiêu kiểm thử
  • Chiến lược kiểm thử
  • Tiêu chuẩn dừng test
  • Hoạch định nguồn lực
  • Sản phẩm kiểm thử

Rủi ro trong kiểm thử phần mềm

Các rủi ro phổ biến trong dự án kiểm thử phần mềm là:

  • Không đủ nguồn nhân lực
  • Môi trường kiểm thử không được thiết lập đúng
  • Ngân sách hạn chế
  • Giới hạn thời gian

Ước tính dự án kiểm thử

Để ước tính dự án kiểm thử, bạn phải xem xét các điểm sau:

  • Chia dự án thành các task nhỏ nhất
  • Phân bổ nhiệm vụ cho từng thành viên trong nhóm
  • Ước tính nỗ lực cần thiết để hoàn thành mỗi nhiệm vụ
  • Xác thực dự toán

Lợi ích của báo cáo kiểm thử

Một báo cáo kiểm thử chứa thông tin về dự án, mục tiêu kiểm thử và tóm tắt kiểm thử. Lợi ích của báo cáo kiểm thử là:

  • Báo cáo hiện trạng của dự án và chất lượng sản phẩm
  • Các bên liên quan và khách hàng có thể hành động khắc phục khi cần thiết
  • Quyết định xem sản phẩm đã sẵn sàng để phát hành chưa

Đánh giá quản lý và Đảm bảo chất lượng phần mềm

Đánh giá quản lý cũng được gọi là Đảm bảo chất lượng phần mềm hoặc SQA. SQA tập trung vào quy trình phần mềm hơn là sản phẩm. Nó là một tập hợp các hoạt động được thiết kế để đảm bảo rằng người quản lý dự án tuân theo quy trình chuẩn. SQA giúp người quản lý kiểm tra dự án theo các tiêu chuẩn đã đặt.

RTM - Đánh giá đầy đủ của yêu cầu

RTM được chuẩn bị trước khi thiết kế test case. Yêu cầu phải được truy xuất từ các hoạt động đánh giá.

Ma trận truy xuất và ma trận kiểm thử

Ma trận truy xuất được sử dụng để ánh xạ chất lượng thực tế, nỗ lực, kế hoạch, tài nguyên và thời gian cần thiết của tất cả các giai đoạn kiểm thử phần mềm. Ma trận truy xuất nguồn gốc là ánh xạ giữa các trường hợp kiểm thử và yêu cầu của khách hàng.

Stubs và Drivers

Stubs và drivers đều là một phần của kiểm thử gia tăng. Stubs được sử dụng trong kiểm thử từ dưới lên, trong khi drivers được sử dụng trong cách tiếp cận từ trên xuống. Để kiểm tra mô-đun chính, stubs được sử dụng, đó là một đoạn mã giả hoặc chương trình.

1