PHÂN TÍCH TÁC ĐỘNG VÀ KIỂM THỬ HỒI QUY
Thông thường kiểm thử bảo trì sẽ bao gồm hai phần:
- Kiểm thử các thay đổi
- Kiểm thử hồi quy để chỉ ra rằng phần còn lại của hệ thống không bị ảnh hưởng bởi công việc bảo trì.
Ngoài việc kiểm thử những gì đã được thay đổi, kiểm thử bảo trì bao gồm kiểm thử hồi quy rộng rãi cho các phần của hệ thống chưa được thay đổi. Một hoạt động chính và quan trọng trong kiểm thử bảo trì là phân tích tác động. Trong quá trình phân tích tác động, cùng với các bên liên quan, sẽ đưa ra quyết định về những phần nào của hệ thống có thể bị ảnh hưởng ngoài ý muốn và do đó cần kiểm thử hồi quy một cách cẩn thận. Phân tích rủi ro sẽ giúp quyết định tập trung kiểm thử hồi quy vào phần nào, bởi vì nhóm sẽ không có thời gian để thực hiện tất cả các kiểm thử hiện có.
Nếu các thông số kỹ thuật kiểm thử ban đầu của hệ thống được giữ lại, người ta có thể sử dụng lại chúng để kiểm thử hồi quy và điều chỉnh chúng để thay đổi hệ thống. Điều này có thể đơn giản như thay đổi kết quả mong đợi cho các bài kiểm thử hiện tại. Đôi khi, các kiểm thử bổ sung có thể cần phải được xây dựng.
Mở rộng hoặc cải tiến hệ thống có thể có nghĩa là các mảng mới đã được chỉ định và việc kiểm thử sẽ được chuẩn bị giống như đối với sự phát triển. Cũng có thể cần cập nhật bộ kiểm thử tự động, thường được sử dụng để hỗ trợ kiểm tra hồi quy.
KÍCH HOẠT KIỂM THỬ BẢO TRÌ
Như đã nêu, kiểm thử bảo trì được thực hiện trên hệ thống vận hành hiện có. Nó được kích hoạt bởi các sửa đổi, chuyển dịch hoặc ngừng hoạt động của hệ thống.
Các sửa đổi bao gồm các thay đổi nâng cao theo kế hoạch (ví dụ: dựa trên bản phát hành), các thay đổi khắc phục và khẩn cấp cũng như các thay đổi về môi trường, chẳng hạn như nâng cấp cơ sở dữ liệu hoặc hệ điều hành theo kế hoạch hoặc các bản vá cho các lỗ hổng mới được phát hiện hoặc được phát hiện của hệ điều hành.
Kiểm thử bảo trì cho việc chuyển dữ liệu (ví dụ: từ nền tảng này sang nền tảng khác) nên bao gồm kiểm thử hoạt động của môi trường mới, cũng như phần mềm đã thay đổi. Kiểm thử bảo trì cho việc ngừng hoạt động của một hệ thống có thể bao gồm kiểm thử việc chuyển dữ liệu hoặc lưu trữ dữ liệu, nếu thời gian lưu giữ dữ liệu dài là bắt buộc.
Vì các sửa đổi thường là phần chính của kiểm thử bảo trì đối với hầu hết các tổ chức, điều này sẽ được thảo luận chi tiết hơn. Từ quan điểm kiểm thử, có hai loại sửa đổi. Có những sửa đổi trong đó việc kiểm thử có thể được lên kế hoạch và cũng có những sửa đổi khắc phục đột xuất, hoàn toàn không thể lên kế hoạch. Bảo trì khắc phục đột xuất diễn ra khi việc tìm kiếm các giải pháp cho các lỗi không thể bị trì hoãn. Quy trình kiểm thử đặc biệt được yêu cầu tại thời điểm đó.
Sửa đổi theo kế hoạch
Các loại sửa đổi theo kế hoạch sau đây có thể được xác định:
- Sửa đổi hoàn hảo (thích ứng phần mềm theo mong muốn của người dùng, ví dụ bằng cách cung cấp các chức năng mới hoặc nâng cao hiệu suất);
- Sửa đổi thích ứng (phần mềm thích ứng với những thay đổi môi trường như phần cứng mới, phần mềm hệ thống mới hoặc luật mới);
- Sửa đổi theo kế hoạch sửa chữa (sửa chữa các vấn đề có thể trì hoãn).
Cách tiếp cận kiểm thử có cấu trúc tiêu chuẩn gần như hoàn toàn có thể áp dụng cho các sửa đổi theo kế hoạch. Trung bình, sửa đổi theo kế hoạch đại diện cho hơn 90% công việc bảo trì trên hệ thống. [Pol và van Veenendaal]
Sửa đổi điều chỉnh đặc biệt
Các sửa đổi khắc phục đặc biệt liên quan đến các giải pháp trực tiếp, ví dụ: một hoạt động sản xuất kết thúc vào đêm khuya, một mạng lưới bị hỏng với vài trăm người dùng đang trực tuyến, một thư có địa chỉ không chính xác.
Có các quy tắc khác nhau và các thủ tục khác nhau để giải quyết các vấn đề thuộc loại này. Sẽ không thể thực hiện các bước cần thiết cho cách tiếp cận có cấu trúc để kiểm thử. Tuy nhiên, nếu một số hoạt động được thực hiện trước khi xảy ra sự cố có thể xảy ra, thì có thể đạt được tình huống trong đó kiểm thử đáng tin cậy được thực hiện bất chấp “các trạm hoảng loạn” xung quanh. Ở một mức độ nào đó, kiểm thử bảo trì này thường giống như sơ cứu – vá lỗi – và ở giai đoạn sau, quy trình kiểm thử tiêu chuẩn sẽ được tuân theo để thiết lập bản sửa lỗi, kiểm thử mạnh mẽ và thiết lập một cấp độ tài liệu phù hợp.
Cần thực hiện phân tích rủi ro của hệ thống vận hành để thiết lập các chức năng hoặc chương trình nàogây ra rủi ro lớn nhất đối cho dịch vụ vận hành trong trường hợp xảy ra thảm họa. Sau đó, thiết lập (liên quan đến các chức năng có nguy cơ) hành động (kiểm thử) nào sẽ được thực hiện nếu một sự cố cụ thể xảy ra.
Một số trục trặc có thể được xác định và có nhiều cách khác nhau để ứng phó với chúng đối với từng chức năng gặp rủi ro. Phản ứng có thể xảy ra có thể là chức năng liên quan có nguy cơ phải luôn được kiểm thử hoặc trong một số trường hợp nhất định, kiểm thử có thể được thực hiện khi rà soát lại (ví dụ: ngày hôm sau).
Nếu quyết định rằng một chức năng cụ thể có nguy cơ phải luôn được kiểm thử bất cứ khi nào có liên quan, thì một số kiểm thử tiêu chuẩn có thể được thực hiện gần như ngay lập tức, nên được chuẩn bị cho mục đích này. Các bài kiểm thử tiêu chuẩn rõ ràng sẽ được chuẩn bị và duy trì theo phương pháp kiểm thử có cấu trúc.
Do đó, ngay cả trong trường hợp sửa đổi đặc biệt, có thể mang lại sự cải thiện về chất lượng bằng cách áp dụng một phương pháp kiểm thử cụ thể. Điều quan trọng là phải thực hiện phân tích rủi ro kỹ lưỡng của hệ thống và chỉ định một bộ kiểm thử tiêu chuẩn phù hợp.
Bản gốc Tiếng Anh các bạn có thể Tải về Tại đây.
