Kiểm thử phần mềm: Các mức kiểm thử (Test levels)

Kiểm thử phần mềm: Các mức kiểm thử  (Test levels)

Tiếp tục series tóm tắt từ cuốn sách: FOUNDATIONS OF SOFTWARE TESTING ISTQB CERTIFICATION của tác giả Dorothy Graham, Erik van Veenendaal, Isabel Evans và Rex Black và một số kinh nghiệm của cá nhân trong quá trình làm việc nhằm cung cấp cho các bạn một cái nhìn tổng quan về kiểm thử phần mềm và các kiến thức cơ bản về kiểm thử, các kỹ thuật dùng trong kiểm thử và các công cụ hỗ trợ.

Để tiếp nối nội dung từ bài viết Kiểm thử phần mềm: Các mô hình phát triển phần mềm. Bài viết hôm nay mình sẽ giới thiệu với các bạn 4 mức kiểm thử: kiểm thử thành phần, kiểm thử tích hợp, kiểm thử hệ thống và kiểm thử chấp nhận.

alt

1. Kiểm thử thành phần (Component testing).

  • Cơ sở kiểm thử:
  • Các yêu cầu thành phần.
  • Thiết kế chi tiết.
  • Code.
  • Đối tượng kiểm thử:
  • Các thành phần (các hàm (Function), thủ tục (Procedure), lớp (Class), hoặc các phương thức (Method), các đối tượng (objects)...).
  • Các module, chương trình.
  • Chuyển đổi dữ liệu thay đổi chương trình.
  • Mô hình cơ sở dữ liệu:

Kiểm thử thành phần ( còn gọi là kiểm thử đơn vị, module, chương trình) tìm kiếm các lỗi và các chức năng, module phần mềm, chương trình, đối tượng, các lớp(class)... có thể được thực hiện biệt lập với phần còn lại của hệ thống, phụ thuộc vào vòng đời phát triển và hệ thống..

Hầu hết các stub và driver được sử dụng để thay thế sự khuyết thiếu của phần mềm và mô phỏng giao diện giữa các thành phần phần mềm một cách đơn giản.

  • Stub là một chương trình hoặc thành phần giả lập (thay thế cho chương trình hoặc thành phần chưa code xong để kiểm thử)

  • Driver là một thành phần của phần mềm hoặc công cụ kiểm thử thay thế cho một thành phần mà sẽ điều khiển hoặc gọi đến một thành phần hoặc hệ thống khác.
    alt

  • Kiểm thử thành phần bao gồm:

  • Kiểm thử chức năng và phi chức năng.

  • Các trường hợp kiểm thử bắt nguồn từ các đặc điểm kỹ thuật của thành phần, thiết kế phần mềm hoặc các mô hình dữ liệu .

  • Kiểm thử thành phần thực hiện khi truy cập vào code . Người thực hiện kiểm thử là lập trình viên viết code.

2. Kiểm thử tích hợp (Integration testing)

  • Cơ sở kiểm thử:

  • Thiết kế hệ thống và phần mềm.

  • Kiến trúc.

  • Luồng công việc (Workflows).

  • Các trường hợp sử dụng (use case).

  • Đối tượng kiểm thử:

  • Triển khai cơ sở dữ liệu các hệ thống con.

  • Cơ sở hạ tầng ( Infrastructure).

  • Giao diện.

  • Cấu hình hệ thống - cấu hình dữ liệu.

    Kiểm thử tích hợp kiểm thử giao diện giữa các thành phần, tương tác với các thành phần khác nhau của hệ thống như hệ điều hành, hệ thống tài liệu, phần cứng hoặc là giao diện giữa các hệ thống.

Có nhiều hơn một mức kiểm thử tích hợp:
- Kiểm thử tích hợp thành phần là kiểm tra sự tương tác giữa các thành phần phần mềm và được thực hiện sau kiểm thử thành phần.

  • Kiểm thử tích hợp hệ thống kiểm tra sự tương tác giữa các hệ thống khác nhau và có thể được thực hiện sau kiểm thử hệ thống.

Có 4 loại kiểm thử trong kiểm thử tích hợp:

  • Kiểm thử dựa vào cấu trúc (structure) như là Top-down và Bottom-up.
  • Kiểm thử chức năng (functional).
  • Kiểm tra hiệu năng (performance): Kiểm tra việc vận hành của hệ thống.
  • Kiểm tra khả năng chịu tải (stress): kiểm tra giới hạn của hệ thống.

3. Kiểm thử hệ thống(System testing).

  • Cơ sở kiểm thử.
  • Chi tiết yêu cầu của hệ thống và phần mềm.
  • Các trường hợp sử dụng ( use cases).
  • Chi tiết các chức năng.
  • Báo cáo phân tích rủi ro.
  • Đối tượng kiểm thử:
  • Hệ thống, người dùng và hướng dẫn cách hoạt động.
  • Cấu hình hệ thống.

Kiểm thử hệ thống bao gồm các loại kiểm thử sau:

  • Kiểm thử chức năng (Functional Test): bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu cầu thiết kế.
  • Kiểm thử hiệu năng (Performance Test): bảo đảm tối ưu việc phân bổ tài nguyên hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu truy vấn…
  • Kiểm thử khả năng chịu tải (Stress Test hay Load Test): bảo đảm hệ thống vận hành đúng dưới áp lực cao. Stress Test tập trung vào các trạng thái tới hạn, các tình huống bất thường…
  • Kiểm thử cấu hình (Configuration Test)
  • Kiểm thử khả năng bảo mật (Security Test): bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ thống.
  • Kiểm thử khả năng phục hồi (Recovery Test): bảo đảm hệ thống có khả năng khôi phục trạng thái ổn định trước đó trong tình huống mất tài nguyên hoặc dữ liệu.

4. Kiểm thử chấp nhận (Acceptance testing).

  • Cơ sở kiểm thử:
  • Yêu cầu người dùng.
  • Yêu cầu hệ thống.
  • Các trường hợp sử dụng (Use cases).
  • Các quy trình nghiệp vụ.
  • Báo cáo phân tích rủi ro.
  • Đối tượng kiểm thử:
  • Các quy trình nghiệp vụ trên hệ thống đã được tích hợp đầy đủ.
  • Các quy trình vận hành và bảo trì.
  • Các phương thức người dùng ( User procedures).
  • Các Forms.
  • Các báo cáo.

Kiểm thử chấp nhận là trách nhiệm của khách hàng và người dùng hệ thống, Mục tiêu của kiểm thử chấp nhận là tạo sự tin cậy trong hệ thống, các bộ phận của hệ thống hoặc các đặc tính phi chức năng của hệ thống.

Kiểm thử chấp nhận có thể xảy ra vào các thời điểm khác nhau trong vòng đời phát triển phần mềm:

  • Một sản phẩm phần mềm thương mại (COTS-Commercial Off The Shelf ) có thể kiểm thử chấp nhận khi được cài đặt hoặc tích hợp.
  • Kiểm thử chấp nhận kiểm tra tính tiện ích của một thành phần có thể được thực hiện trong quá trình kiểm thử thành phần.
  • Kiểm thử chấp nhận của một chức năng mới có thể thực hiện trước khi kiểm thử hệ thống.

Trong kiểm thử chấp nhận có 2 loại kiểm thử chính, do tính đặc biệt của chúng, chúng được chuẩn bị và thực hiện riêng biệt.

  • Alpha testing: Là việc kiểm thử hoạt động chức năng thực tế hoặc giả lập do người dùng/khách hàng tiềm năng hoặc một nhóm test độc lập thực hiện tại nơi sản xuất phần mềm. Alpha test là một hình thức kiểm thử chấp nhận nội bộ trước khi phần mềm được tiến hành kiểm thử beta.
  • Beta testing (hoặc thử nghiệm thực địa) : Được thực hiện sau alpha testing. Gửi hệ thống tới một số người dùng - là người cài đặt và sử dụng nó trong điều kiện làm việc thực tế. Người dùng gửi báo cáo về các sự cố, lỗi của hệ thống đến các tổ chức phát triển nơi mà các lỗi được sửa chữa.

Mình vừa giới thiệu đến một số loại kiểm thử phần mềm phổ biến mà kỹ sư kiểm thử thường thực thi. Ngoài những loại kiểm thử kể trên, còn một số loại kiểm thử khác nhưng vì chúng không được phổ biến nên mình tạm thời không giới thiệu trong bài viết này. Ở bài viết tiếp theo mình sẽ giới thiệu với các bạn Các loại kiểm thử (Test types) và kiểm thử bảo trì.