Vòng đời của bug trong kiểm thử phần mềm

Vòng đời của khuyết tật hoặc vòng đời của khuyết tật là một tập hợp các trạng thái cụ thể mà một khuyết tật phải trải qua trong suốt vòng đời của nó. Mục đích của việc tạo ra một quy trình cho vòng đời của lỗi / lỗi là để giúp người chịu trách nhiệm về lỗi / lỗi đó dễ dàng quản lý và thay đổi trạng thái cho đến khi lỗi / lỗi được xóa hoàn toàn khỏi hệ thống.

<3 Vì vậy, vòng đời của một lỗi là từ thời điểm người kiểm tra phát hiện ra lỗi cho đến khi nó bị đóng lại.

Bạn Đang Xem: Vòng đời của bug trong kiểm thử phần mềm

1. Sơ đồ vòng đời lỗi

Sơ đồ vòng đời của bug

Mô tả chi tiết từng trạng thái của lỗi trong suốt vòng đời của nó

Mới (mới)

Khi người kiểm thử thực thi một trường hợp thử nghiệm và kết quả của trường hợp thử nghiệm đó không như mong đợi, họ sẽ gọi đó là lỗi. Đó là, sự khác biệt giữa kết quả mong đợi và kết quả thực tế được gọi là lỗi. Vì vậy, lỗi này cần được sửa. Nhưng không phải những người kiểm tra sửa lỗi mà chính những lập trình viên mới là người sửa nó.

Người kiểm tra sẽ báo cáo lỗi này như thế nào? Họ sẽ đến gặp nhà phát triển và nói: Này, tôi đã tìm thấy một lỗi, hãy sửa nó càng sớm càng tốt? Câu trả lời là không. Người kiểm tra cần ghi lại lỗi này cho trưởng nhóm, người sẽ chỉ định một nhà phát triển sửa lỗi này sau khi phân tích. (Có nhiều công ty nơi người kiểm thử chỉ định lỗi trực tiếp cho nhà phát triển, không thông qua trưởng nhóm).

→ Khi người kiểm tra tìm thấy lỗi, nó sẽ có trạng thái mới.

Mở

Các lỗi được ghi lại bởi người kiểm tra. Trưởng nhóm cần xác minh rằng lỗi thực sự là lỗi và sau đó lỗi sẽ được mở. Sơ đồ sau đây cho thấy các hoạt động mà trưởng nhóm cần hoàn thành:

Hoạt động sẽ được hoàn thành bởi trưởng nhóm

Bị từ chối

Xem Thêm : Mantra Yoga là gì? Hướng dẫn chi tiết về Mantra Yoga dành cho người mới tập

Các lỗi được đánh dấu là bị từ chối khi chúng không hợp lệ. Điều này có nghĩa là đôi khi người kiểm tra có thể hiểu sai các tính năng và đánh dấu chúng là lỗi. Trong trường hợp này, lỗi sẽ bị loại sau khi được trưởng nhóm kiểm tra lại.

→ Khi người kiểm tra báo cáo lỗi nhưng đó là một tính năng của ứng dụng, trưởng nhóm sẽ đánh dấu lỗi đó là bị từ chối (h1).

Lặp lại (lặp lại)

Nếu lỗi hợp lệ, trưởng nhóm sẽ kiểm tra xem lỗi đã được người khác ghi lại hay chưa. Nếu ai đó đã đăng nhập nó, trưởng nhóm sẽ đánh dấu nó là một bản sao. Nếu những người kiểm tra khác không báo cáo, trưởng nhóm sẽ xem xét trong phạm vi.

Như chúng ta đều biết, chúng ta làm việc như một nhóm. Phần mềm hoặc mô-đun giống nhau có thể được chỉ định cho nhiều người thử nghiệm, trong trường hợp đó, nhiều người thử nghiệm có thể tìm thấy cùng một lỗi.

Do đó, trưởng nhóm cần đảm bảo rằng cùng một lỗi không được báo cáo hai lần trở lên.

→ Nếu ​​hai hoặc nhiều người kiểm tra báo cáo cùng một lỗi, lỗi được báo cáo sau đó sẽ được đánh dấu là trùng lặp.

Hoãn (hoãn)

Nếu lỗi không bị trùng lặp, nhưng không có trong phiên bản hiện tại, nó sẽ được đánh dấu là bị hoãn lại. Điều này có nghĩa là giả sử bạn đang theo một mô hình nhanh nhẹn, họ chia các yêu cầu của dự án thành các lần chạy nước rút, ví dụ thành 10 lần chạy nước rút: sprint 1, sprint 2, …, sprint 10. Hiện đang ở sprint 1, nhưng lỗi bạn tìm thấy có liên quan đến một tính năng sẽ được phát triển trong sprint 2, lỗi sẽ được đánh dấu là hoãn lại. Lỗi bị trì hoãn là một lỗi, nhưng sẽ được sửa trong bản phát hành trong tương lai.

→ Khi một lỗi là một phần của bản phát hành trong tương lai, nó sẽ được đánh dấu là bị hoãn lại.

Đã giao (lỗi chuyển nhượng)

Khi lỗi được tìm thấy là hợp lệ, duy nhất và là một phần của phiên bản hiện tại, trưởng nhóm sẽ chỉ định lỗi cho nhà phát triển.

Xem Thêm : Kiếp sau là gì và bằng chứng về luân hồi có kiếp sau?

Khắc phục

Sau khi nhận được lỗi từ trưởng nhóm, nhà phát triển sẽ chỉnh sửa và sửa lỗi theo yêu cầu, đồng thời chuyển cho người thử nghiệm để kiểm tra lại.

Kiểm tra lại

Sau khi lỗi được sửa và chức năng / tính năng đã sẵn sàng để thử nghiệm, người thử nghiệm sẽ thực hiện lại trường hợp thử nghiệm bị lỗi và xác minh rằng nó đang hoạt động chính xác. Đây được gọi là kiểm tra lại.

Đóng

Khi một lỗi đã được sửa, kiểm tra lại và hoạt động theo yêu cầu, người kiểm tra sẽ đánh dấu lỗi đó là đã đóng.

Mở lại

Có hai tình huống mà chúng tôi cần mở lại lỗi:

• Tình huống 1: Khi nhà phát triển sửa lỗi và người kiểm tra thử lại, nhưng sau khi kiểm tra lại, lỗi vẫn tồn tại, người kiểm tra sẽ mở lại lỗi và gán cho nhà phát triển.

• Tình huống 2: Có một tình huống trong đó lỗi đã được sửa và đóng lại. Trong trường hợp này, người kiểm tra cần mở lại lỗi đã đóng và gán nó cho nhà phát triển.

  2. Mô tả Vòng đời Lỗi / Lỗi

  

  1. Người kiểm tra đã tìm thấy lỗi / lỗi
  2. Chỉ định Trạng thái Lỗi: Mới / Mới
  3. Giao lỗi cho người quản lý dự án để phân tích
  4. Người quản lý dự án quyết định xem lỗi có hợp lệ không
  5. Nếu lỗi không hợp lệ, trạng thái sẽ chuyển thành “bị từ chối / bị từ chối”.
  6. Nếu lỗi không bị từ chối, bước tiếp theo là kiểm tra xem nó có nằm trong phạm vi không. Giả sử chúng ta có một tính năng khác – tính năng email của cùng một ứng dụng, bạn sẽ thấy nó có lỗi. Nhưng nằm ngoài phạm vi của phiên bản ứng dụng này, trạng thái của lỗi có thể thay đổi thành “Bị hoãn / hoãn lại”.
  7. Tiếp theo, quản trị viên cần xác minh rằng các lỗi tương tự đã được tìm thấy trước đó. Nếu nó đã tồn tại, lỗi này sẽ được coi là “trùng lặp / trùng lặp”.
  8. Nếu không có vấn đề gì trong khi nhà phát triển sửa lỗi, lỗi sẽ chuyển sang trạng thái “Đang xử lý / Đang xử lý”.
  9. Sau khi mã được sửa. Lỗi sẽ được gán trạng thái “Đã sửa / Đã sửa”
  10. Tiếp theo, người kiểm tra sẽ kiểm tra lại mã đã sửa đổi. Nếu trường hợp kiểm tra liên quan vượt qua, hãy đóng lỗi hoặc thay đổi trạng thái thành “đã đóng”. Nếu trường hợp thử nghiệm lại không thành công, hãy mở lại / mở lại lỗi và chuyển lại cho nhà phát triển
  11. Hãy xem xét tình huống trong đó, trong phiên bản đầu tiên, một lỗi đã được tìm thấy trong chuỗi fax, trình tự này đã được sửa và chỉ định trạng thái đóng. Trong lần nâng cấp thứ hai, lỗi tương tự lại xuất hiện. Trong trường hợp này, khiếm khuyết đã đóng sẽ được mở lại.

  Bản dịch và tài liệu tham khảo từ https://www.guru99.com/defect-life-cycle.html và software-testing-tutorials-automation.com/2016/12/bug-life-cycle.html Data