1. Lỗi phần mềm là gì?

Một lỗi phần mềm là một lỗi, lỗ hổng, thất bại, hoặc có lỗi trong một chương trình máy tính hoặc hệ thống đó là nguyên nhân nó tạo ra kết quả không chính xác hoặc không mong muốn, hoặc vận hành theo cách không được định hướng trước.

2. Những thuật ngữ nào mô tả lỗi phần mềm?

Phụ thuộc vào nơi mà bạn được làm việc (như một tester), bạn sẽ sử dụng những thuật ngữ khác nhau để mô tả điều gì sẽ xảy đến khi phần mềm bị lỗi. Dưới đây là một số thuật ngữ: 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

Fault, failure và defect có xu hướng ám chỉ một vấn đề thật sự quan trọng, thậm chí là nguy hiểm. Dường như là không đúng khi gọi một biểu tượng (icon) không được tô đúng màu là 1 lỗi (fault). Những từ này cũng thường ám chỉ một lời khiển trách: chính là do nó (fault) mà phát sinh lỗi phần mềm (software failure)

Anomaly, incident, variance thì không có vẻ là quá tiêu cực và thường được sử dụng để đề cập tới sự vận hành không được dự tính trước thay vì hoàn toàn là lỗi (all-out failure).

Có lẽ, Problem, error và bug là những thuật ngữ chung nhất thường được sử dụng, dùng để chỉ sai sót của lập trình viên trong quá trình tạo ra sản phẩm.

3. Quy tắc xác định lỗi phần mềm?

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 calulator 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 (bug) theo quy tắc 5.

4. Vòng đời của lỗi?

Vòng đời của lỗi 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

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

Một trong những kỹ năng quan trọng nhất mà bạn cần có trong hộp công cụ của người kiểm thử nghiệm là khả năng viết một báo cáo lỗi tốt. Việc tìm kiếm lỗi chỉ là một phần của công việc, bởi vì nếu các nhà phát triển không thể phát hiện ra lỗi bạn tìm thấy, họ sẽ gặp khó khăn để khắc phục chúng. Phần mềm theo dõi lỗi của bạn nên bao gồm một số trường bắt buộc để đảm bảo rằng người kiểm thử đưa ra một bản báo cáo đầy đủ về lỗi mà họ gặp phải. Và người kiểm thử nên trau dồi kỹ năng mô tả của họ.

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.

6. 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!

Tài liệu tham khảo: https://voer.edu.vn/c/loi-bug-la-gi/4c771e16/32455ae1 http://toolsqa.com/software-testing/defect-life-cycle/