7 loại lỗi phần mềm mà mỗi người kiểm thử viên nên biết

Đã đến lúc có một bài về các vấn đề cơ bản của kiểm thử phần mềm. Bài viết này dựa trên các loại lỗi của kiểm thử phần mềm mà mỗi người kiểm thử viên nên biết Lỗi phần mềm có rất nhiều loại. Một lỗi là một lỗi không có vấn đề gì cả. Nhưng đôi khi điều quan trọng là phải hiểu bản chất của lỗi, ý nghĩa và nguyên nhân để xử lý nó làm sao cho tốt hơn. Điều này giúp cho sự phản ứng với phần mềm trở nên nhanh hơn và điều quan trọng nhất là có sự phản ứng với phần mềm một cách thích hợp.

Trong bài này, chúng ta sẽ thảo luận về các loại lỗi phần mềm phổ biến và cách xác định chúng trong quá trình kiểm thử với một số ví dụ và bài tập đơn giản

Hãy bắt đầu xác định lỗi phần mềm và bugs.

Lỗi phần mềm và bugs

Như đã được định nghĩa trong Wikimedia "error là một sự sai lệch về tính chính xác và tính đúng đắn" và " Bugs phần mềm là một error, flow, failure hoặc lỗi trong một chương trình hoặc hệ thống máy tính gây ra kết quả không chính xác hoặc không mong muốn hoặc thực hiện theo cách không mong muốn" Vì vậy, nó có thể được suy luận như sau:

• Error là một sự trái ngược của kết quả thực tế với kết quả mong muốn
• Error là một loại bug của phần mềm
• Error có thể xuất hiện do yêu cầu không đầy đủ hoặc không chính xác do vấn đề về nhập dữ liệu của con người

Danh mục chung của các lỗi phần mềm:

1. Lỗi chức năng:

Chức năng là một cách để phần mềm hoạt động. Phần mềm bị lỗi nếu những chức năng mong muốn hoạt động một cách khó khăn, lúng túng, khó hiểu, hoặc không thể.

Kiểm tra ảnh chụp màn hình:

Chức năng mong muốn cho button Cancel là cửa sổ "tạo project mới" sẽ đóng và không có thay đổi nào được lưu (nghĩa là không có project mới nào được tạo). Nếu button Cancel không click được thì đó là lỗi chức năng.

2. Lỗi giao tiếp:

Những lỗi này xảy ra khi phần mềm giao tiếp với người dùng cuối. Mọi thứ mà người dùng cuối cần biết để sử dụng phần mềm phải được cung cấp trên màn hình.

Một vài ví dụ về lỗi giao tiếp:

• Không cung cấp hướng dẫn trợ giúp hoặc menu.
• Các tính năng là một phần của bản release nhưng không được ghi lại trong menu trợ giúp, một button "Save" không nên xóa một file vv...

3. Lỗi thiếu command:

Điều này xảy ra khi một tập lệnh mong muốn bị thiếu. Xem screenshot phía dưới:

Cửa sổ này cho phép người dùng tạo một project mới. Tuy nhiên, không có tùy chọn để người dùng có thể thoát mà không cần tạo dự án. Vì button/option "Cancel" không được cung cấp cho người dùng. Đây là một lỗi thiếu command.

4. Lỗi Syntactic:

Lỗi syntactic là lỗi sai chính tả hoặc câu không chính xác, nó rất rõ ràng khi kiểm thử GUI phần mềm. Xin lưu ý rằng chúng tôi không đề cập đến các lỗi cú pháp trong code của chương trình. Trình biên dịch sẽ cảnh báo cho develop biết về bất kỳ lỗi cú pháp nào xảy ra trong code.

Dưới đây là một lỗi chính tả sai từ "Cancel"

Đây cũng là một lỗi sai cú pháp

5. Lỗi xử lý lỗi:

Bất kỳ lỗi nào xảy ra trong khi người dùng tương tác với phần mềm cần phải được xử lý một cách rõ ràng và có ý nghĩa. Nếu không, nó được gọi là Error Handling Error.

Hãy nhìn vào hình ảnh dưới đây. Thông báo lỗi không cho biết lỗi thực sự là gì, thiếu trường bắt buộc nhập, lỗi saving, lỗi load page hoặc một lỗi hệ thống? Do đó, đây là một lỗi "Error Handing Error".

Khi có thể, các bước tiếp theo cần được liệt kê để người dùng tuân theo:

Nếu phần mềm có một số trường bắt buộc nhất cần phải điền trước khi họ có thể lưu các thông tin trên một biểu mẫu, message xác nhận phải rõ ràng và chỉ ra hành động mà người dùng yêu cầu.

Dưới đây là một ví dụ khác:

6. Lỗi tính toán

Những lỗi này xảy ra do bất kỳ lý do nào dưới đây:

• Logic không tốt
• Công thức tính toán không chính xác
• Loại dữ liệu không phù hợp
• Lỗi coding
• Có vấn đề về call function vv...

Năm 1999, NASA mất một tàu vũ trụ thăm dò trên sao Hỏa vì một trong những nhà thầu phụ đã sử dụng các đơn vị tiếng Anh thay vì hệ thống số liệu dự kiến. Điều này làm cho quỹ đạo hoạt động của động cơ không chính xác. Do sự cố này mà chiếc tàu vũ trị đã bị rơi gần như ngay lập tức khi nó đến sao Hỏa.

7. Lỗi control flow

Control flow của một phần mềm mô tả nó sẽ làm gì tiếp theo và điều kiện như thế nào Ví dụ: hãy xem xét một hệ thống mà người dùng phải điền vào một biểu mẫu các tùy chọn có sẵn như: Save, Save và Close, và Cancel. Nếu người dùng nhấn vào button "Save và Close" thông tin người dùng trong biểu mẫu sẽ được lưu lại và đóng biểu mẫu. Nếu nhấn vào button mà không đóng biểu mẫu thì đó là lỗi control flow.

Một số bài tập ví dụ:

Exercise #1: Hãy các loại lỗi theo follow dưới đây:

Đây là lỗi "Error Handling Errors"

Exercise #2:

Đây là lỗi thiếu command. Button Cancel là bắt buộc nhưng lại bị thiếu. Ngoài ra, cả hai button "Proceed" và "Delete" là thừa và thực hiện các chức năng giống nhau.

Exercise #3

Đây là lỗi Syntactic

Bước tiếp theo:

Report một lỗi đã được xác định là cần thiết. Để có kết quả tốt nhất hãy thực hiện report ngay. Trong report bug thì cần mô tả được bug, mức độ ưu tiên, mức độ nghiêm trọng, các bước tái hiện và ảnh chụp màn hình (nếu có).

Xác định, phân loại, báo cáo và cuối cùng là loại bỏ khiếm khuyết là một phần của hoạt động kiểm soát chất lượng. Tuy nhiên, phòng bệnh thì tốt hơn chữa bệnh. Mấu chốt của quản lý chất lượng phần mềm là thiết lập các quy trình giám sát và kiểm thử tại mỗi giai đoạn của vòng đời phát tiển phần mềm. Mục đích là để phát hiện các lỗi càng sớm càng tốt. Điều này là do chi phí tìm và sửa lỗi tăng lên đáng kể khi tiến hành phát triển phầm mềm. Do đó, việc xác định lỗi sớm là rất cần thiết.

Việc sửa lỗi trong giai đoạn phân tích yêu cầu là rẻ nhất, dần dần nó đắt dần lên với từng giai đoạn và đắt nhất là vào giai đoạn bảo trì sau khi release. Là một kỹ sư kiểm thử phần mềm, chúng ta có thể có hoặc không trực tiếp tham gia vào việc xác định các yêu cầu. Chúng ta cũng có thể ít nhiều kiểm soát trực tiếp về chất lượng của yêu cầu.

Do đó, điều quan trọng là chúng ta có thể xác đinh, tìm kiếm và báo cáo bất kỳ lỗi nào mà chúng ta gặp phải trong giai đoạn kiểm thử.

Link tham khảo: http://www.softwaretestinghelp.com/types-of-software-errors/