.st0{fill:#FFFFFF;}

Tìm hiểu về Defect – Bug

Lỗi phần mềm (Defect) trong chương trình hoặc hệ thống máy tính làm cho kết quả không chính xác hoặc không mong muốn được gọi là “Bug” hoặc “Defect“. Quá trình sửa lỗi được gọi là “debug” và thường sử dụng kỹ thuật hoặc công cụ chính thức để xác định lỗi (Defect), và kể từ những năm 1950, một số hệ thống máy tính đã được thiết kế để ngăn chặn, phát hiện hoặc tự động sửa lỗi (debug) máy tính khác nhau trong quá trình hoạt động.
Hầu hết những lỗi được phát sinh từ sai sót trong mã nguồn của chương trình hoặc trong các thành phần của hệ điều hành gây ra

Những thuật ngữ về lỗi phần mềm

Tùy từng văn hóa và phong cách làm việc của từng công ty mà có những nguyên tắc, định nghĩa khác nhau về Lỗi phần mềm. Tuy nhiên về cơ bản vẫn dựa trên các thuật ngữ sau:

  • Defect: nhược điểm
  • Fault: khuyết điểm
  • Failure: sự thất bại
  • Anomaly: sự dị thường
  • Variance: biến dị
  • Incident: việc rắc rối
  • Problem: vấn đề
  • Error: lỗi
  • Bug: lỗi
  • Feature: đặc trưng
  • Inconsistency: sự mâu thuẫn

Tại sao phần mềm lại có lỗi?

Có rất nhiều lý do cho lỗi phần mềm. Lý do phổ biến nhất là những sai lầm của con người trong việc thiết kế phần mềm và mã hóa. Một khi bạn đã biết nguyên nhân gây ra lỗi thì bạn sẽ dễ dàng khắc phục và giảm thiểu các lỗi này.
defect

Sự khác nhau giữa Bug, Defect, Failure và Error trong phần mềm

  • BUG: Là một khiếm khuyết trong một thành phần hoặc hệ thống mà nó có thể làm cho thành phần hoặc hệ thống này không thực hiện đúng chức năng yêu cầu của nó, ví dụ như thông báo sai hoặc định nghĩa dữ liệu không đúng. Một bug, nếu gặp phải trong quá trình hệ thống hoạt động, có thể gây ra failure trong thành phần hoặc hệ thống đó. (A flaw in a component or system that can cause the component or system to fail to perform its required function, e.g. an incorrect statement or data definition. A defect, if encountered during execution, may cause a failure of the component or system.)
  • DEFECT:Lỗi trong qua trình phát triển hoặc lỗi logic (coding or logic) làm cho chương trình hoạt động sai yêu cầu đề ra. (Về cơ bản là giống định nghĩa bug).
  • ERROR: Là hành động của con người dẫn đến kết quả sai. (A human action that produces an incorrect result.) [Theo tài liệu IEEE 610]
  • Còn Failure chính là sự khác biệt giữa kết quả thực tế trên màn hình và kết quả mong đợi của một thành phần, hệ thống hoặc service nào đó.

Note: Không phải 100% failure là do bug gây ra, trong quá trình test cấu hình sai, test sai môi trường hoặc làm thiếu bước có thể dẫn đến failure
Học cùng chúng tôi qua video: Miễn Phí

Quy tắc xác định lỗi

Một lỗi phần mềm xuất hiện khi 1 hoặc nhiều hơn trong 5 quy tắc dưới đây là đúng:
Quy tắc 1: Phần mềm không thực hiện một số thứ giống như mô tả trong bản đặc tả phần mềm Ví dụ: đặc tả của 1 calculator đã nói rõ rằng: nó sẽ thực thi phép cộng, phép trừ, phép nhân, phép chia đúng. Nếu bạn nhận việc kiểm thử phần mềm Calculator, nhấn phím “+” và không có chuyện gì xảy ra, đó chính là một lỗi
Quy tắc 2: Phần mềm thực hiện một số việc mà bản đặc tả yêu cầu nó không được thực hiện Ví dụ: Bản đặc tả phần mềm yêu cầu rằng, calculator sẽ không bao giờ bị đột ngột ngưng hoạt động, bị khóa lại hoặc bị đóng băng. Nếu bạn ấn liên tục lên các phím và nhận được thông điệp từ calculator là “not responding” (dừng quá trình hồi đáp với dữ liệu vào), đây là một lỗi theo quy tắc 2.
Quy tắc 3: Phần mềm thực hiện một số chức năng mà bản đặc tả không đề cập tới Ví dụ: Lập trình viên tự ý thêm vào phép tính căn bậc 2, trong khi đặc tả của calculator chỉ yêu cầu các phép tính cộng, trừ, nhân, chia.
Quy tắc 4: Phần mềm không thực hiện một số việc mà bản đặc tả không đề cập tới, nhưng là những việc nên làm
Ví dụ: Bạn mong muốn rằng công việc sẽ được duy trì cho đến khi pin hoàn toàn hết, hoặc ít nhất bằng cách nào đó báo cho bạn biết Pin đã yếu. Những phép tính đúng đã không xảy ra khi pin yếu, và nó cũng không chỉ rõ điều gì sẽ xảy đến. Quy tắc số 4 tạo nên lỗi này.
Quy tắc 5: Trong con mắt của người kiểm thử, phần mềm là khó hiểu, khó sử dụng, chậm đối với người sử dụng Trong trường hợp của calculator, có lẽ bạn đã tìm thấy những nút có kích thước quá nhỏ. Hoặc có thể sự sắp xếp của nút “=” đã làm cho nó khó sử dụng. Hoặc sự bố trí màu sắc làm cho nó rất khó nhìn… Tất cả những điều này đều là lỗi (defect) theo quy tắc 5.
Xem thêm: Videos and Screencasts

Vòng đời của lỗi

Vòng đời của  defect là một hành trình mà mà lỗi đi qua trong suốt cuộc đời của nó. Nó thay đổi từ tổ chức này sang tổ chức khác, từ dự án này đến dự án khác và nó được điều chỉnh bởi quy trình kiểm thử phần mềm.Vòng đời của lỗi bao gồm các trạng thái dưới đây:

  • New: Khi mà lần lỗi được log lên lần đầu tiên bời người kiểm thử
  • Assigned: Khi lỗi đã được đăng lên và chỉ định cho lập trình viên nào đó
  • Open: Khi lập trình viên đang sửa lỗi
  • Fixed: Khi lập trình viên đã hoàn thành việc sửa lỗi
  • Retest: Người kiểm thử kiếm tra lại lỗi đã được sửa hay chưa, có phát sinh thêm lỗi mới nào không
  • Reopened: Nếu lỗi vẫn còn, người kiểm thử sẽ trả lại cho lập trình viên. Lỗi phải đi lại một vòng đời như cũ.
  • Deferred: Lỗi sẽ được sửa trong bản phát hành tiếp theo. Lý do có thể là độ ưu tiên của lỗi có thể là thấp, thiếu thời gian để phát hành hoặc lỗi có thể không có ảnh hưởng lớn đến phần mềm.
  • Rejected: Nếu lập trình viên cho rằng không phải là lỗi, họ có thể chuyển sang trạng thái này
  • Duplicate: Lỗi được đăng trùng với nhau
  • Closed: Khi người kiểm thử đã thấy lỗi được sửa triệt để
  • Not a bug/Enhancement: Một số thay đổi trong ứng dụng, không phải là lỗi

defect

Bug Severity – Priority

1. Severity

Severity là mức độ ảnh hưởng của Bug/ Defect với sự phát triển hoặc hoạt động của ứng dụng đang test. Mức độ ảnh hưởng tới các function càng cao thì severity càng cao. Tester/QA thường là người xác định severity.

Phân loại Severity

  • Critical: Defect khiến cho tiến trình hoạt động của toàn phần mềm bị ngưng hoàn toàn, không còn phần nào có thể chạy được
  • Major: Defect nghiêm trọng, có thể là sập hệ thống nhưng có một số phần khác vẫn hoạt động được
  • Medium: Defect gây ra một số hành vi ngoài mong đợi nhưng hệ thống vẫn hoạt động
  • Low: Defect không gây ra bất kì sự cố lớn nào cho hệ thống.

Xác định Severity của Defect

Dựa trên tần suất xuất hiện: Trong một số trường hợp, nếu sự xuất hiện của một defect nhỏ thường xảy ra trong mã, ảnh hưởng của nó có thể nhiều hơn. Vì vậy, từ quan điểm của người dùng, nó nghiêm trọng hơn mặc dù đó là một defect nhỏ.
Dựa trên sự cô lập defect: Cô lập defect có thể giúp tìm ra mức độ nghiêm trọng theo bảng dưới đây:

2. Priority

Priority là thứ tự cần xử lý defect. Priority càng cao nghĩa là defect càng cần được giải quyết sớm Thông thường, những defect ảnh hưởng đến hoạt động của cả hệ thống sẽ được ưu tiên cao hơn những defect của các chức năng nhỏ.

Phân loại Priority

  • Low: Defect ảnh hưởng đến hoạt động hệ thống nhưng nó có thể giải quyết sau khi những defect nghiêm trọng hơn đã được giải quyết
  • Medium: Defect nên được giải quyết trong tiến trình dự án hoặc có thể đợi đến khi version mới ra
  • High: Defect phải được giải quyết càng sớm càng tốt vì nó ảnh hưởng nghiêm trọng đến hệ thống và không thể được sử dụng cho đến khi được khắc phục

Kết hợp Severity + Priority

Trong báo cáo lỗi, mức độ nghiêm trọng và mức độ ưu tiên thường được điền bởi người viết báo cáo lỗi, nhưng nên được cả nhóm xem xét có thể được xác định dựa trên các tiêu chí sau:

  • Độ nghiêm trọng cao – Lỗi ưu tiên cao

Ví dụ như trên một trang web Thương mại điện tử, mỗi khách hàng nhận được thông báo lỗi trên mẫu đặt phòng và không thể đặt hàng, hoặc trang sản phẩm ném phản ứng Lỗi 500.

  • Mức độ nghiêm trọng cao – Lỗi ưu tiên thấp

Điều này xảy ra khi lỗi gây ra các vấn đề lớn, nhưng nó chỉ xảy ra trong điều kiện hoặc tình huống rất hiếm, ví dụ như khách hàng sử dụng các trình duyệt cũ rất cũ không thể tiếp tục mua sản phẩm. Bởi vì số lượng khách hàng có trình duyệt rất cũ rất thấp, nên không phải là ưu tiên cao để khắc phục sự cố.

  • Mức độ ưu tiên cao – Mức độ nghiêm trọng thấp

Điều này có thể xảy ra khi, ví dụ, logo hoặc tên của công ty không được hiển thị trên trang web. Điều quan trọng là phải khắc phục sự cố càng sớm càng tốt, mặc dù nó không gây ra nhiều thiệt hại.

  • Mức độ ưu tiên thấp – Mức độ nghiêm trọng thấp

Đối với những trường hợp lỗi không gây ra thảm họa và chỉ ảnh hưởng đến số lượng khách hàng rất nhỏ, cả Độ nghiêm trọng và Mức độ ưu tiên đều thấp, ví dụ trang chính sách bảo mật mất nhiều thời gian để tải. Không nhiều người xem trang chính sách bảo mật và tải chậm không ảnh hưởng đến khách hàng nhiều.
Độ ưu tiên và độ nghiêm trọng chỉ là hai trong số rất nhiều thông tin quan trọng khác chúng ta cần phải cung cấp như môi trường của con bug, mức độ lặp đi lặp lại, các bước mô tả con bug, phạm vi của con bug… Tuy nhiên, việc hiểu đúng về mức độ nghiêm trọng, độ ưu tiên của sản phẩm cho thấy người kiểm thử thực sự hiểu rõ và quan tâm đến chất lượng sản phẩm cũng như thể hiện sự chuyên nghiệp của một kỹ sư kiểm thử.
Báo cáo lỗi là một khía cạnh quan trọng của kiểm thử phần mềm. Một báo cáo lỗi tốt giúp giao tiếp tốt với đội ngũ phát triển hiệu quả và tránh nhầm lẫn, bên cạnh đó cũng là để phòng ngừa và phát hiện những vấn đề nghiêm trọng xảy ra, liên quan và ảnh hưởng trực tiếp đến chất lượng sản phẩm phần mềm.

Mẹo để viết một báo cáo lỗi tốt

Báo cáo lỗi tốt bao gồm:

  • TIÊU ĐỀ: Mọi thứ bắt đầu với một tiêu đề. Nó phải rõ ràng để người đọc có một cái nhìn tổng quát ngay trong nháy mắt
  • NỘI DUNG LỖI: Mô tả phải rõ ràng và súc tích. Nên nhớ rằng người đọc báo cáo của bạn đã không thấy lỗi trước đó.
  • CÁC BƯỚC TÁI HIỆN LỖI: Cần mô tả cụ thể các bước để tái hiện lỗi. Có thể dùng các công cụ để chụp ảnh, quay phim để làm cho các bước này rõ ràng hơn. Khi lỗi không xảy ra với tỉ lệ 100% theo các bước bạn mô tả, thì bạn phải cung cấp thông tin đó cho lập trình viên được biết.
  • KẾT QUẢ HIỆN TẠI: Bạn phải làm rõ kết quả hiện tại như thế nào, khác với kì vọng ra sao. Trường này giúp ngăn ngừa bất kỳ sự hiểu nhầm nào và cho lập trình viên biết chuyện gì đã xảy ra
  • KẾT QUẢ MONG MUỐN: Bạn cần nêu ra những yêu cầu cụ thể theo như đặc tả ban đầu khi thực hiện các bước bạn đã nêu ra.
  • PHIÊN BẢN: Bạn cũng cần phải có được phiên bản phần mềm đúng. Đôi khi một lỗi sẽ được khắc phục khi một lỗi khác được giải quyết, hoặc chỉ đơn giản bởi một số thay đổi trong phiên bản mới nhất của phần mềm. Nếu sai phiên bản, lập trình viên có thể mất rất nhiều thời gian để tìm ra lỗi đó.
  • THÔNG TIN CHI TIẾT: Bạn đang sử dụng thiết bị nào? Hệ điều hành nào đang chạy? Bạn đã sử dụng trình duyệt nào? Mọi chi tiết bạn có thể đưa ra về nền tảng sẽ giúp ích cho các lập trình viên nhanh chóng tái hiện lỗi.
  • MỨC ĐỘ ƯU TIÊN VÀ MỨC ĐỘ NGHIÊM TRỌNG: Đề cập đến Mức độ ưu tiên và Mức độ nghiêm trọng của lỗi giúp quản lí dự án và lập trình viên biết nên ưu tiên sửa lỗi nào trước.
  • TÀI LIỆU MINH HỌA: Những tài liệu đính kèm, thường là ảnh chụp màn hình hoặc video, thường được các lập trình viên xem đầu tiên, trước khi đọc các bước mô tả của bạn. Vì vậy ảnh hoặc video minh họa đính kèm sẽ giúp các lập trình viên tiết kiệm nhiều thời gian quý báu!
  • TAGS & LINKS: Bạn nên sử dụng các thẻ mô tả cho phép bạn lọc cơ sở dữ liệu và tìm các nhóm lỗi liên quan. Đôi khi bạn muốn đưa một ID lỗi hoặc một liên kết trong báo cáo lỗi của bạn lên một cái gì đó mà bạn cảm thấy có liên quan chặt chẽ hoặc tương tự nhưng không tương tự như một bản sao.
  • ASSIGNEE: Tùy vào quy trình của dự án bạn đang làm, quy định sẽ chỉ định lỗi cho ai.

KẾT LUẬN

Đối với người kiểm thử phần mềm, muốn tìm ra lỗi phải hiểu lỗi là gì. Khi đã tìm ra lỗi, việc quan trọng hơn là phải truyền tải nó một các dễ hiểu nhất tới các lập trình viên. Hy vọng bài viết trên sẽ giúp cho bạn có cái nhìn tổng quan về lỗi và cách trình bày lỗi!

related posts:




Leave a Reply:

Your email address will not be published. Required fields are marked

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}