Phân tích tác động trong kiểm thử phần mềm
Charles Moore
⚡ Tóm tắt thông minh
Phân tích tác động trong kiểm thử phần mềm đánh giá cách một thay đổi được đề xuất ảnh hưởng đến các yêu cầu, thiết kế, mã nguồn, kiểm thử và tiến độ bàn giao, giúp...ping Các nhóm ước tính nỗ lực, ưu tiên phạm vi kiểm thử hồi quy và ngăn ngừa các lỗi ngoài ý muốn trước khi phát hành.
Phân tích tác động là gì?
Phân tích tác động là quá trình phân tích ảnh hưởng của những thay đổi được thực hiện đối với một sản phẩm hoặc ứng dụng đã được triển khai. Nó xác định các khu vực của hệ thống có thể bị ảnh hưởng khi một phần hoặc tính năng cụ thể của ứng dụng được thay đổi.
Tác động được đánh giá trên các khía cạnh Yêu cầu, Thiết kế & ArchiCấu trúc, Thử nghiệm và Lịch trình giao hàng.
Mỗi khi bổ sung các tính năng mới vào ứng dụng hoặc sản phẩm, việc kiểm tra xem những thay đổi đó sẽ ảnh hưởng như thế nào đến hiệu suất và độ ổn định của hệ thống là điều vô cùng cần thiết. Phân tích tác động được thực hiện vì lý do này.
Tại sao cần thực hiện phân tích tác động của sự thay đổi?
- Để hiểu rõ kết quả có thể xảy ra khi thực hiện thay đổi. Việc thêm quá nhiều chức năng vào sản phẩm có thể làm giảm hiệu suất tổng thể.
- Xác định tất cả các tập tin, tài liệu và mô hình có thể cần được sửa đổi nếu nhóm quyết định thực hiện thay đổi.
- Ước tính nỗ lực cần thiết để thực hiện sự thay đổi.
- Xác định các nhiệm vụ cần thiết để thực hiện sự thay đổi.
- Liệt kê các mối phụ thuộc vào phần tử cụ thể đang được thay đổi.
Tài liệu phân tích tác động là gì?
Tài liệu Phân tích Tác động có thể được sử dụng như một danh sách kiểm tra để đánh giá yêu cầu thay đổi trước khi nhóm bắt đầu thực hiện. Tài liệu này cần ghi lại các chi tiết như:
- Một mô tả ngắn gọn về vấn đề.
- Giải thích hoặc đưa ra ví dụ về cách mà lỗi đó gây ra sự cố hoặc kém hiệu quả.
- Ước tính độ phức tạp.
- Ước tính chi phí và thời gian sửa chữa.
- Chức năng cần kiểm tra.
- Các trường hợp kiểm thử mới được tạo ra cho sự thay đổi này.
- Các tài liệu tham khảo như bản đặc tả kỹ thuật hoặc các ghi chú thiết kế liên quan.
Ví dụ:
Tài liệu phân tích tác động.
- Thay đổi ID yêu cầu:
- Chức vụ:
- Description:
- Ngày chuẩn bị:
- Ước tính mức độ ưu tiên:
- Lợi ích tương đối
- Hình phạt tương đối
- Chi phí tương đối
- Nguy cơ tương đối
- Tổng thời gian dự kiến: ______ giờ
- Thời gian làm việc ước tính bị mất: ______ giờ
- Thời gian dự kiến ảnh hưởng đến tiến độ: ______ ngày
- Chất lượng bị ảnh hưởng:
- Các yêu cầu khác bị ảnh hưởng:
- Các nhiệm vụ khác bị ảnh hưởng:
- Vấn đề tích hợp:
Cách trình bày mức độ ảnh hưởng của phân tích tác động
Phân tích tác động có thể được biểu diễn bằng mã màu thể hiện mức độ quan trọng của các thay đổi đối với hệ thống. Một mã màu phổ biến được hiển thị bên dưới:
- Màu đỏ — Tác động mạnh
- Màu vàng — Tác động vừa phải
- Màu xanh lá cây — Tác động yếu
Bảng trên giải thích tác động của những thay đổi đã được thực hiện:
- Các đặc điểm được đánh dấu màu đỏ là những đặc điểm chính bị thay đổi. Các đặc điểm màu vàng ít bị ảnh hưởng bởi sự thay đổi hơn. Các đặc điểm màu xanh lá cây bị ảnh hưởng ít nhất.
- Các tính năng được liệt kê theo chiều dọc là những tính năng đang được thay đổi. Các tính năng được liệt kê theo chiều ngang là những tính năng bị ảnh hưởng bởi sự thay đổi đó. Trong ví dụ trên, sự thay đổi ở Tính năng 1 ảnh hưởng đến Tính năng 3.
- Đối với các dự án lớn có nhiều tính năng và chức năng, bảng trên có thể không thực tế. Trong trường hợp đó, một phương pháp khác được áp dụng, trong đó nhà phát triển trực tiếp đánh dấu mức độ ảnh hưởng của các thay đổi đối với các tính năng chính, như minh họa bên dưới, trong đó tác động của tính năng chính được đánh dấu đối với từng tính năng phụ.
Một số câu hỏi mẫu cần xem xét khi thực hiện Phân tích Tác động:
- Tác dụng phụ hoặc rủi ro bất lợi của việc thực hiện thay đổi được đề xuất là gì?
- Có cần phải mua thêm công cụ nào để triển khai và kiểm tra sự thay đổi này không?
- Nếu sự thay đổi được chấp nhận, thì bao nhiêu công sức đã đầu tư sẽ bị lãng phí?
- Liệu những thay đổi được đề xuất có ảnh hưởng tiêu cực đến các yêu cầu về hiệu suất không?
- Liệu có cần thêm thông tin từ người dùng để xác minh thay đổi được đề xuất không?
- Sự thay đổi có làm tăng giá thành sản phẩm không?
- Liệu đội ngũ nhân viên hiện tại có đủ kiến thức và kỹ năng để thực hiện sự thay đổi được đề xuất hay không?
- Thay đổi được đề xuất có đặt ra bất kỳ nhu cầu không thể chấp nhận nào đối với bất kỳ tài nguyên máy tính nào không?
Các phương pháp tốt nhất để phân tích tác động của sự thay đổi
- Trước khi bắt đầu Phân tích Tác động, hãy đảm bảo yêu cầu thử nghiệm xác định rõ mọi phần của dự án bị ảnh hưởng bởi các thay đổi.
- Việc liên tục trao đổi thông tin giữa nhà phát triển và người kiểm thử là điều bắt buộc để đảm bảo không bỏ sót bất kỳ thay đổi nào cần thiết trong sản phẩm cuối cùng.
- Xác định xem có cần thay đổi, xóa hoặc thêm bất kỳ thành phần nào vào giao diện người dùng hay không.
- Ước tính số lượng các trường hợp kiểm thử chấp nhận, kiểm thử hệ thống và kiểm thử tích hợp cần thiết.
- Xác định bất kỳ tác động nào của sự thay đổi được đề xuất đối với kế hoạch dự án, kế hoạch quản lý cấu hình hoặc kế hoạch đảm bảo chất lượng.
Các loại phân tích tác động trong kiểm thử phần mềm
Phân tích tác động của sự thay đổi không phải là một kỹ thuật duy nhất. Thông thường, các chuyên gia sử dụng một trong ba loại phân tích bổ sung cho nhau để trả lời các câu hỏi khác nhau về một sự thay đổi được đề xuất.
- TracPhân tích tác động khả thi: Sử dụng các yêu cầu TracMa trận khả năng và các liên kết thiết kế giúp ánh xạ mọi yêu cầu đến các mô-đun, bài kiểm tra và tài liệu thực hiện yêu cầu đó. Khi một yêu cầu thay đổi, ma trận sẽ chỉ ra mọi thành phần hạ nguồn cần được cập nhật hoặc kiểm tra lại.
- Phân tích tác động phụ thuộc: Nghiên cứu biểu đồ cuộc gọi, luồng dữ liệu và cấu hình giao diện.tracts bên trong codebase. Một thay đổi đối với một mô-đun là tracThông qua các cuộc gọi trực tiếp, cuộc gọi gián tiếp và các cấu trúc dữ liệu được chia sẻ, các hiệu ứng lan tỏa tiềm ẩn được bộc lộ trước khi sự thay đổi được triển khai.
- Phân tích tác động thực nghiệm (lịch sử): Công cụ này xem xét dữ liệu thay đổi trong quá khứ — các lỗi trước đây, các sprint thất bại và các lỗi thoát khỏi kiểm thử hồi quy — để dự đoán cách thay đổi hiện tại sẽ hoạt động. Các công cụ hiện đại kết hợp việc khai thác lịch sử kiểm soát phiên bản với các mô hình thống kê hoặc máy học để đánh giá rủi ro của mỗi thay đổi.
Hầu hết các đội đều kết hợp ít nhất hai trong số các loại hình này. TracPhân tích khả năng hoạt động cho bạn biết những tài liệu nào bị ảnh hưởng, phân tích phụ thuộc cho bạn biết đoạn mã nào bị ảnh hưởng, và phân tích lịch sử cho bạn biết mức độ rủi ro của thay đổi đó.
Các công cụ phổ biến để phân tích tác động của sự thay đổi
Phân tích tác động thay đổi hiện đại hiếm khi được thực hiện trên bảng tính. Các nhóm thường kết hợp công cụ quản lý yêu cầu với công cụ phân tích mã và công cụ quản lý kiểm thử có chung một hệ thống. tracKhả năng vận động cột sống.
- Jama Connect, IBM CỬA, Modern Requirementsvà Yêu cầu về Thị lực: Ghi nhận các yêu cầu, duy trì các tiêu chuẩn cơ bản và tạo báo cáo tác động trên các yêu cầu, bài kiểm tra và rủi ro liên quan khi có đề xuất thay đổi.
- Atlassian Jira với Xray hoặc Zephyr: Track câu chuyện người dùng, lỗi và trường hợp kiểm thử. Báo cáo tác động hiển thị mọi câu chuyện và bài kiểm thử mà một thay đổi được đề xuất ảnh hưởng đến trong một sprint hoặc release train.
- SonarQubeHiểu bằng SciTools và Structure101: Phân tích các phụ thuộc mã nguồn và tạo biểu đồ cuộc gọi cũng như báo cáo liên kết để kỹ sư có thể thấy mã nguồn phía sau bị ảnh hưởng bởi sự thay đổi.
- Có thể khởi chạy, Testim Tự phục hồi và TestGrid: Sử dụng máy học để dự đoán những bài kiểm tra nào có khả năng phát hiện ra các lỗi do thay đổi gây ra cao nhất, cho phép lựa chọn bài kiểm tra thông minh và chu kỳ hồi quy nhanh hơn.
- Microsoft Excel hoặc Google Trang tính: Vẫn được sử dụng rộng rãi cho tài liệu Phân tích Tác động ban đầu, bảng ảnh hưởng được mã hóa màu sắc và nhật ký yêu cầu thay đổi trong các dự án nhỏ hơn.
Sự kết hợp phù hợp phụ thuộc vào quy mô của mã nguồn, môi trường pháp lý và phương thức phân phối. Các ngành công nghiệp chịu sự quản lý chặt chẽ thường dựa vào Jama hoặc DOORS để đảm bảo tính minh bạch và khả năng kiểm toán. tracTrong khi đó, các nhóm phát triển sản phẩm theo mô hình Agile lại dựa vào Jira. SonarQubevà một công cụ đánh giá tác động.
