MAINTENANCE TESTING (KIỂM THỬ BẢO TRÌ)
Các nội dung sẽ xuất hiện trong đề thi
- So sánh kiểm thử bảo trì (kiểm thử một hệ thống vận hành) với kiểm thử một ứng dụng mới liên quan đến các loại kiểm thử, kích hoạt kiểm thử và số lượng kiểm thử. (K2)
- Xác định lý do kiểm thử bảo trì (sửa đổi, di chuyển và sự rút lui). (K2)
- Mô tả vai trò của kiểm thử hồi quy và phân tích tác động trong bảo trì. (K2)
Sau khi được triển khai, một hệ thống thường được sử dụng trong nhiều năm hoặc thậm chí nhiều thập kỷ. Trong thời gian này, hệ thống và môi trường hoạt động của nó thường được sửa chữa, thay đổi hoặc mở rộng. Kiểm thử được thực hiện trong giai đoạn vòng đời này được gọi là “kiểm tra bảo trì”.
Lưu ý rằng kiểm thử bảo trì khác với kiểm thử khả năng bảo trì (xác định mức độ dễ dàng để duy trì hệ thống).
Quy trình phát triển và kiểm thử áp dụng cho các phần phát triển mới cơ bản không thay đổi cho mục đích bảo trì. Các bước quy trình kiểm thử tương tự sẽ được áp dụng và tùy thuộc vào quy mô và rủi ro của các thay đổi được thực hiện, một số cấp độ kiểm thử được thực hiện: 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. Quy trình kiểm thử bảo trì thường bắt đầu bằng việc nhận yêu cầu cho một sự thay đổi hoặc yêu cầu cho kế hoạch phát hành. Người quản lý (test manager) sẽ sử dụng điều này làm cơ sở để tạo ra một kế hoạch kiểm thử. Khi nhận được thông số kỹ thuật mới hoặc đã thay đổi, các trường hợp kiểm thử tương ứng được chỉ định hoặc điều chỉnh. Khi nhận được đối tượng kiểm thử, các kiểm thử mới, các kiểm thử được sửa đổi cũng như các kiểm thử hồi quy được thực hiện.
Kiểm thử bảo trì với kiểm thử một ứng dụng mới khác nhau ở cách tiếp cận. Có một số lĩnh vực mà hầu hết sự khác biệt xảy ra, ví dụ như liên quan đến cơ sở kiểm thử. Hoạt động “đuổi theo” (catching-up) thường được yêu cầu khi hệ thống được bảo trì. Các thông số kỹ thuật thường bị “thiếu” và một bộ phần mềm kiểm thử liên quan đến các thông số kỹ thuật đơn giản là không tồn tại. Có thể thực hiện hoạt động đuổi theo này cùng với việc kiểm thử một bản phát hành bảo trì mới, điều này có thể giúp làm giảm chi phí. Nếu không thể biên dịch bất kỳ thông số kỹ thuật nào mà từ đó có thể viết các trường hợp kiểm thử (bao gồm cả kết quả mong đợi, cơ sở kiểm thử thay thế), ví dụ: một test oracle, nên được tìm kiếm bằng sự thỏa hiệp.
Cần tìm kiếm tài liệu gần nhất với thông số kỹ thuật và có thể được quản lý bởi các nhà phát triển cũng như người kiểm thử. Trong những trường hợp như vậy, nên thu hút sự chú ý của khách hàng đến chất lượng kiểm thử thấp hơn có thể đạt được. Hãy nhận biết các vấn đề có thể xảy ra của “việc sản xuất hàng ngày”. Trong trường hợp xấu nhất, không ai biết cái gì đang được kiểm thử, nhiều trường hợp kiểm thử đang thực hiện cùng một kịch bản và nếu một sự cố được phát hiện thì thường rất khó để tái hiện lại lỗi thực tế do rất khó để truy lại ở thiết kế và/hoặc yêu cầu kiểm thử. Lưu ý rằng khả năng tái hiện lại việc kiểm thử cũng rất quan trọng đối với kiểm thử bảo trì.
Trong nhiều trường hợp, một khía cạnh mà hơi khác so với tình hình phát triển là tổ chức kiểm thử. Hoạt động phát triển mới và các hoạt động kiểm thử thích hợp của chúng thường được thực hiện như một phần của dự án, trong khi các kiểm thử bảo trì thường được thực hiện như một hoạt động trong tổ chức thông thường. Kết quả là thường thiếu một số nguồn lực và tính linh hoạt, và quá trình kiểm thử có thể gặp nhiều cạnh tranh hơn từ các hoạt động khác.
Nội dung tiếp theo giới thiệu chi tiết hơn về Kiểm thử bảo trì.
Bản gốc Tiếng Anh các bạn có thể Tải về Tại đây.
Syllabus tải về Tại đây
