+1

Test levels, Test types, Test methods and Maintenance testing

I. Test levels, Test types & Test methods

1. Test levels

Test level là một tập hợp các hoạt động kiểm thử được tổ chức và quản lý cùng nhau. Trong mô hình phát triển phần mềm sequential, test level thường được định nghĩa như một tiêu chuẩn đầu ra (exit criteria) của từng level và là tiêu chuẩn đầu vào (entry criteria) của level tiếp theo.

Component testing(hay còn được gọi là Unit testing)

  • Tập trung vào kiểm thử riêng lẻ các thành phần
  • Thường được thực hiện bởi developer

Component integration testing ( hay được gọi là unit integration testing)

  • Tập trung vào kiểm thử giao diện và sự tương tác giữa các thành phần
  • Sử dụng các chiến lược kiểm thử như bottom-up, top-down or big-bang

System testing

  • Tập trung vào hành vi/ khả năng chung của toàn bộ hệ thống hoặc sản phẩm
  • Có thể được thực hiện bởi một đội kiểm thử độc lập - không thuộc dự án (independent test team)

System integration testing

  • Tập trung vào kiểm thử tương tác của hệ thống đang test với các hệ thống hoặc dịch vụ bên ngoài.
  • Để đảm bảo chất lượng, việc kiểm thử phải được thực hiện trên môi trường tương tự như môi trường thực tế.

Acceptance testing

  • Kiểm thử chấp nhận tập trung vào việc đảm bảo hệ thống thoả mãn các tính năng cung cấp cho người dùng
  • Thường được thực hiện bởi người dùng thử
  • Các hình thức chính như: UAT/OAT/ contractual and regulatory/ alpha/beta

2. Test types

Test type là tập các hoạt động liên quan đến chất lượng cụ thể và hầu hết được thực hiện ở mọi test levels

Functional testing

  • Tập trung vào “What” the test object should do ?
  • Đảm bảo tính chính xác, đầy đủ và phù hợp về mặc chức năng của hệ thống

Non-Functional testing

  • Tập trung vào “how well the system behaves” để đảm bảo hệ thống/ sản phẩm hoạt động tốt
  • Mục tiêu chính là kiểm thử các đặc điểm phi chức năng, được phân loại theo chuẩn ISO/IEC 25010 như :
    • Performance Efficiency
    • Compatibility
    • Usability
    • Reliability
    • Security
    • Maintainability
    • Portability
  • Đôi khi kiểm thử phi chức năng nên được tiến hành sớm trong vòng đời phát triển phần mềm

Structural testing

  • Kiểm thử với test cases được viết sau khi hiểu được thiết kế và kiến trúc bên trong của code.

Change related testing

  • Bao gồm 2 loại chính:

    • Confirmation testing (còn được gọi là Retesting)

      • Xác nhận rằng lỗi đã được sửa, bao gồm:
        • Thực hiện test lại các test cases đã failed trước đó do lỗi;
        • Thêm các trường hợp kiểm thử đối với các thay đổi do việc sửa lỗi;
    • Regression testing

      • Thực hiện kiểm thử hồi quy để xác nhận rằng không có hậu quả bất lợi nào sau khi có thay đổi trong hệ thống
      • Cần xác định được các ảnh hưởng của sự thay đổi đến:
        • Trong cùng một thành phần được thay đổi
        • Các thành phần khác trong cùng hệ thống
        • Hoặc kể các các hệ thống được kết nối từ bên ngoài
      • Bộ kiểm thử hồi quy được thực hiện nhiều lần và thông thường số lượng test cases sẽ được tăng dần với mỗi lần phát hành.
  • Cần phải thực hiện Confirmation testing và Regression testing ở tất cả các test levels khi lỗi được sửa hoặc có thay đổi.

3. Test methods

Black-box testing

  • Kiểm thử dựa trên đặc tả, các tài liệu từ các bên liên quan và hành vi phổ biến của các phần mềm/ sản phẩm tương tự
  • Đảm bảo hành vi của hệ thống đúng với yêu cầu đặc tả

White-box testing

  • Kiểm thử dựa trên việc triển khai và cấu trúc của hệ thống (ví dụ như, code, architecture, work flows, and data flows).

Grey-box testing

  • Kiểm thử kết hợp black-box và white-box

Ad hoc testing

  • Kiểm thử không có kế hoạch cụ thể
  • Chủ yếu dựa trên trực giác của tester

II. Maintenance testing

Thông thường phần mềm sẽ được kiểm thử trước và sau khi phát hành. Việc kiểm thử sau khi phần mềm phát hành được gọi là kiểm thử bảo trì (maintenance testing).

  • Theo ISO/IEC 14764, có thể có nhiều loại bảo trì khác nhau như sửa chữa (corrective), thích ứng với sự thay đổi môi trường, cải thiện hiệu suất hoặc khả năng bảo trì.
  • Phạm vi của kiểm thử bảo trì phụ thuộc vào:
    • Mức độ rủi ro của thay đổi
    • Quy mô của hệ thống
    • Quy mô của sự thay đổi
  • Các tác nhân kích hoạt hoạt động kiểm thử bảo trì bao gồm:
    • Modifications - các sửa đổi, nâng cấp trên hệ thống đã phát hành.
    • Upgrades or migrations of the operational environment - các nâng cấp hoặc thay đổi môi trường của hệ thống từ nền tảng này sang nền tảng khác.
    • Retirement - Khi hệ thống đã đi đến cuối vòng đời của nó, việc kiểm thử đối với hệ thống nghỉ hưu có thể bao gồm khả năng lưu trữ, khôi phục và truy xuất dữ liệu.

Tài liệu tham khảo:


All rights reserved

Viblo
Hãy đăng ký một tài khoản Viblo để nhận được nhiều bài viết thú vị hơn.
Đăng kí