# Một Số Điều Bạn Cần Biết Về Vòng Đời Bug Trong Kiểm Thử Phần Mềm

- Published: 2022-11-10T14:50:06+07:00
- Updated: 2026-11-04T15:52:25+07:00
- Author: GCT Solutions
- Categories: Kiểm thử phần mềm
- Canonical: https://gct-solutions.net/blogs/bug-life-cycle-in-software-testing
- Language: vi

> Thông thường, các giao thức trong Vòng đời phát triển phần mềm (SDLC) được nhóm sản xuất tuân theo khi tạo ra bất kỳ sản phẩm phần mềm nào. Tuy nhiên, quá trình phát triển không phải lúc nào cũng đơn giản và liền mạch. Trên thực tế, nhiều dạng lỗi và sai sót thường xảy ra với sản phẩm trong quá trình phát triển. Nnhững lỗi này cần được nhận ra và khắc phục trong suốt quá trình phát triển để đưa ra sản phẩm phần mềm cuối cùng có chất lượng cao. Vì vậy, trong bài đăng này, chúng ta sẽ nói về các lỗi (bug) trong quá trình phát triển phần mềm, cách chúng được phát hiện trong quá trình kiểm thử phần mềm và cách khắc phục.

## **Vòng đời bug trong kiểm thử phần mềm là gì?**

Trong kiểm thử phần mềm, **Vòng đời bug** là tập hợp chính xác các giai đoạn mà bug trải qua trong suốt vòng đời của nó. Mục tiêu của vòng **đời bug** là làm cho quá trình sửa chữa bug hiệu quả hơn thông qua việc phối hợp và thông báo tình trạng hiện tại của các bug khi chúng được xử lý bởi nhiều người.

## **Vòng đời của bug trong quy trình kiểm thử phần mềm là gì?**

**Vòng đời bug** được chia thành chín giai đoạn như dưới đây:

### **1. Mới xuất hiện**

Ở giai đoạn đầu của vòng đời, vấn đề được phát hiện. Khi một bug mới được phát hiện, nó sẽ được gán trạng thái, sau khi quá trình kiểm tra và xác nhận bắt đầu, nó sẽ lại có trạng thái mới.

### **2. Được ủy quyền**

Bug mới xuất hiện sẽ được giao cho bộ phận thích hợp giải quyết. Thông thường, quản lý nhóm kiểm thử sẽ là người chỉ định các bug cho nhóm sản xuất.

### **3. Mở**

Khi một nhà sản xuất bắt đầu giải quyết vấn đề, bug ở trạng thái mở. Các nhà sản xuất sẽ bắt đầu khắc phục bug dựa trên các thông số kỹ thuật. Cũng có khả năng vấn đề sẽ không xuất hiện một cách thích hợp; trong trường hợp này, nhà sản xuất có thể chuyển vấn đề sang một trong bốn trạng thái này vì những lý do cụ thể.

- Trùng lặp
- Bị hoãn
- Bị từ chối
- Không phải là bug

### **4. Sửa**

Khi nhà sản xuất thực hiện các biện pháp thích hợp và các vấn đề được giải quyết, trạng thái được đánh dấu là đã khắc phục.

### **5. Chờ kiểm tra lại**

Sau khi nhà sản xuất đã giải quyết vấn đề và thực hiện các điều chỉnh cần thiết, nó sẽ được giao lại cho tester để kiểm tra lại. Thời gian chờ đợi kiểm thử lặp lại và sự cố vẫn ở trong tình trạng “Đang chờ kiểm tra lại”.

### **6. Lặp lại kiểm thử**

Trường hợp bước vào giai đoạn kiểm thử lại khi tester tiếp tục kiểm tra sự cố. Tester sẽ kiểm tra lại xem nhà sản xuất có sửa chữa các vấn đề đúng theo yêu cầu hay không.

### **7. Mở lại**

Nếu các yêu cầu không được hoàn thành một cách chính xác và sự cố vẫn còn trong các chức năng, tester sẽ mở lại trạng thái bug.

### **8. Xác nhận**

Nếu sự cố không có vấn đề gì và đã được nhà sản xuất sửa chữa một cách thích hợp, trạng thái của bug sẽ được thay đổi và nó được ghi lại là đã xác nhận.

### **9. Hoàn thành**

Khi một lỗ hổng không tồn tại và được đánh giá và xác nhận đầy đủ, dẫn đến tình trạng đóng. Tester sửa đổi trạng thái của bug.

Sau đây là một số ví dụ về **vòng đời bug**:

1. Mới. Một **tester đảm bảo chất lượng** (hãy gọi anh ta là Tom) truy cập trang web của một cửa hàng sách trực tuyến mà anh ta đang đánh giá và thêm một cuốn sách vào giỏ hàng. Vật phẩm được thêm vào giỏ hàng của Tom, nhưng anh ấy không thể đặt hai cuốn sách giống nhau. Một cú nhấp chuột vào "+" để điều chỉnh số lượng không có tác dụng. Tom nêu chi tiết vấn đề và tạo một báo cáo bug dưới dạng “Mới”.

2. Được giao. Một PM (giả sử Susan, người quản lý dự án) nhận thấy một lỗ hổng trong danh sách. Vấn đề có vẻ là thực tế và quan trọng. Susan đã giao công việc cho Brian, một nhà sản xuất phụ, người phát triển tính năng giỏ hàng.

3. Mở. Brian nhận được nhiệm vụ mới và cố gắng sao chép nó bằng cách làm theo các hướng dẫn trong báo cáo. Biểu tượng "+" không hoạt động như dự định. Brian cập nhật trạng thái bug thành Mở và bắt đầu điều tra nguyên nhân. Tuy nhiên, không phải trường hợp nào cũng diễn ra như vậy. Brian hiểu rằng bug có thể không hợp lệ. Trong khi cố gắng giải quyết nó ngay lập tức, anh ta có thể sử dụng một trạng thái thay thế, chẳng hạn như:

- Nhân bản. Trong khi đọc báo cáo, Brian nhận thấy rằng Peter, một tester phần mềm khác, đã báo cáo bug này một ngày trước đó. Brian phân loại vấn đề là trùng lặp.
- Bị từ chối. Brian thêm sách vào giỏ và nhấp vào "+" bằng cách sử dụng hướng dẫn từ báo cáo sự cố. Số giảm còn hai. Có lẽ sự cố là do kết nối internet không đáng tin cậy. Hoặc bug xảy ra trên một thiết bị nào đó, nhưng Tom không đề cập đến thông tin này trong phần mô tả.
- Hoãn lại. Lỗ hổng này chỉ ảnh hưởng đến trình duyệt Firefox, trình duyệt có lượng người dùng hạn chế. Brian chọn sửa nó sau khi xác định được nguồn gốc của các bug thanh toán. thành viên của khả năng của nhóm thử nghiệm
- Không phải là bug. Brian được thông báo nhưng nhanh chóng phát hiện ra Tom đã cố gắng mua thêm một cuốn sách điện tử. Điều này là không thể do logic của trang web: người dùng có thể truy cập ebook từ bất kỳ thiết bị nào, loại bỏ nhu cầu lấy nó hai lần.
- Cần thêm thông tin. Brian không chắc chắn về hoàn cảnh xuất hiện của con bọ. Người dùng có đang đăng nhập vào tài khoản của mình lúc này không? Tom đang cố thêm một mặt hàng trên trang sản phẩm hay ở giai đoạn xác nhận đơn hàng?
- Không thể sửa chữa được. Brian nhận thức được tình hình và đã cố gắng khắc phục nó nhiều lần. Đó là một bug khó xác định và anh ấy sẽ phải qua một cơ sở mã lớn để sửa chữa nó. Hiện tại, một người có thể đặt hai cuốn sách bằng cách nhập "2" vào ô hiển thị số lượng hàng hóa.

4. Đã sửa. Brian phát hiện và sửa bug mã hóa. Sau đó, anh ta thay đổi tiến trình thành “Đã sửa”.

5. Chờ kiểm tra lại. Khi bug đã được sửa, kiểm thử sẽ được giao cho Tom và chờ quá trình kiểm tra lại.

6. Kiểm thử lại. Tom được thông báo rằng trạng thái lỗi của anh ấy đã thay đổi. Anh ấy phải kiểm tra lại chức năng và đảm bảo rằng người dùng hiện có thể điều chỉnh số lượng sách. Anh ấy kích hoạt trạng thái thử lại và bắt đầu làm việc.

7. Đã mở lại. Không may rằng Tom thấy vấn đề vẫn tồn tại trong suốt quá trình kiểm thử lại. Số lượng mục không thay đổi khi bạn nhấp vào "+". Lỗi được mở lại và đưa cho Brian. Brian cần kiểm tra lại vấn đề. Sự cố sẽ được kiểm thử lại lần nữa khi nó đã được khắc phục.

8. Đã xác minh. Trong quá trình kiểm thử, Tom đảm bảo rằng nút hoạt động như dự định. Người dùng hiện có thể điều chỉnh số lượng hàng hóa trong giỏ bằng cách nhấn "+". Tom cập nhật trạng thái của bug thành. Đã xác minh.

9. Đã đóng. Susan kết thúc công việc sau khi xác nhận rằng vấn đề đã được giải quyết.

![gct-solution-what-is-the-bug-life-cycle-in-software-testing’s-workflow](https://gct-solution.net/images/images/gct-solution-what-is-the-bug-life-cycle-in-software-testing%E2%80%99s-workflow%281%29.png)

### **Kết luận**

**Vòng đời của bug** kết thúc khi bug đã được khắc phục và vấn đề được giải quyết. Tuy nhiên, giai đoạn tiếp theo của chu kỳ phát triển mở ra: kiểm thử hồi quy. Sau khi mọi thứ đã được khắc phục, **QA tester** kiểm thử hệ thống (hoặc ít nhất là các chức năng quan trọng trong) để đảm bảo rằng các sửa đổi gần đây không ảnh hưởng đến các chức năng. Nói cách khác, điều quan trọng là phải đảm bảo rằng việc sửa chữa không làm sai lệch những gì trước đó đã hoạt động bình thường. Và nếu có, một **vòng đời bug** sẽ lại bắt đầu.

GCT Solutions đồng hành cùng doanh nghiệp trong việc triển khai giải pháp AI và phát triển các nền tảng số hiện đại nhằm nâng cao hiệu quả vận hành một cách rõ ràng và có thể đo lường. Với năng lực về [AI Services](https://gct-solution.net/services/mobile-app-development), [AI Consulting](https://gct-solution.net/services/mobile-app-development), [Platform Modernization](https://gct-solution.net/services/mobile-app-development) and [Software Engineering](https://gct-solution.net/services/mobile-app-development) chúng tôi giúp tổ chức mở rộng quy mô công nghệ, tối ưu hoạt động và đẩy nhanh quá trình chuyển đổi số.

**Author**: Chi Vo - Content Marketing Executive