Sự khác biệt giữa một khiếm khuyết và một lỗi là gì?
Sự khác biệt giữa một khiếm khuyết và một lỗi là gì?
Câu trả lời:
Một lỗi là kết quả của một lỗi mã hóa
Một khiếm khuyết là một sai lệch so với yêu cầu
Đó là: Lỗi không nhất thiết có nghĩa là có lỗi trong mã , nó có thể là một chức năng không được triển khai nhưng được xác định trong các yêu cầu của phần mềm.
Từ trang Wikipedia về kiểm thử phần mềm :
Không phải tất cả các lỗi phần mềm là do lỗi mã hóa. Một nguồn phổ biến của các lỗi đắt tiền là do các khoảng trống yêu cầu, ví dụ, các yêu cầu không được nhận ra, dẫn đến lỗi thiếu sót của nhà thiết kế chương trình. [14] Một nguồn phổ biến của các lỗ hổng yêu cầu là các yêu cầu phi chức năng như khả năng kiểm tra, khả năng mở rộng, khả năng bảo trì, khả năng sử dụng, hiệu suất và bảo mật.
Trích dẫn Ilene Burnstein từ cuốn sách Kiểm thử phần mềm thực hành (được khuyến nghị), những người tham gia định nghĩa trong "Bộ sưu tập tiêu chuẩn kỹ thuật phần mềm của IEEE" (1994) và "Thuật ngữ tiêu chuẩn kỹ thuật phần mềm của IEEE" (tiêu chuẩn 610.12, 1990):
Lỗi là lỗi, hiểu sai hoặc hiểu sai về phía nhà phát triển phần mềm
Trong danh mục nhà phát triển, chúng tôi bao gồm các kỹ sư phần mềm, lập trình viên, nhà phân tích và người thử nghiệm. Ví dụ, nhà phát triển có thể hiểu nhầm ký hiệu thiết kế hoặc lập trình viên có thể nhập tên biến không chính xác.
Một lỗi (lỗi) được đưa vào phần mềm do lỗi. Đó là một sự bất thường trong phần mềm có thể khiến nó hoạt động không chính xác, và không theo đặc điểm kỹ thuật của nó.
Lỗi hoặc khiếm khuyết đôi khi được gọi là lỗi trên mạng. Sử dụng thuật ngữ sau này tầm thường hóa các lỗi ảnh hưởng đến chất lượng phần mềm. Việc sử dụng thuật ngữ khiếm khuyết trên mạng cũng liên quan đến các tạo phẩm phần mềm như các yêu cầu và tài liệu thiết kế. Khiếm khuyết xảy ra trong các tạo tác này cũng là do lỗi và thường được phát hiện trong quá trình xem xét.
Lỗi là không có khả năng của một hệ thống hoặc thành phần phần mềm để thực hiện các chức năng cần thiết của nó trong các yêu cầu hiệu suất được chỉ định.
Trong quá trình thực thi một thành phần hoặc hệ thống phần mềm, người kiểm tra, nhà phát triển hoặc người dùng quan sát rằng nó không tạo ra kết quả như mong đợi. Trong một số trường hợp, một loại hành vi sai trái cụ thể chỉ ra một loại lỗi nhất định. Chúng ta có thể nói rằng loại hành vi sai trái là một triệu chứng của lỗi. Một nhà phát triển / người thử nghiệm có kinh nghiệm sẽ có một nền tảng kiến thức về các trường hợp lỗi / triệu chứng / lỗi (mô hình lỗi như được mô tả trong Chương 3) được lưu trữ trong bộ nhớ. Hành vi không chính xác có thể bao gồm tạo ra các giá trị không chính xác cho các biến đầu ra, phản hồi không chính xác trên một phần của thiết bị hoặc hình ảnh không chính xác trên màn hình. Trong quá trình phát triển lỗi thường được quan sát bởi người kiểm tra và lỗi được xác định và sửa chữa bởi các nhà phát triển.
Bạn có thể đọc toàn bộ chương trong Google Sách, tại đây .
Có một số thuật ngữ khác nhau liên quan đến lỗi phần mềm. Trích từ một khóa học tôi đã tham gia:
Lỗi : Hành động hoặc thiếu sót của con người dẫn đến lỗi.
Lỗi : Lỗi là một lỗi phần mềm (bước không đúng, quy trình hoặc định nghĩa dữ liệu) gây ra lỗi.
Lỗi : Tương tự như Lỗi.
Lỗi : Không có khả năng phần mềm thực hiện các chức năng được yêu cầu trong các yêu cầu hiệu suất được chỉ định.
Theo đó, không có sự khác biệt giữa lỗi và lỗi. Tuy nhiên, một số người cho rằng lỗi là một lỗi được tìm thấy trước khi phát hành phần mềm, trong khi lỗi là do khách hàng tìm thấy.
Tôi không thể cưỡng lại việc đăng "trường hợp lỗi thực tế đầu tiên được tìm thấy".
Trời ơi.
Quay lại thời xưa - hoạt động của máy tính bị lỗi là do tất cả các loại - bao gồm chuột nhai dây điện và các lỗi thực sự (sinh vật) xâm nhập vào công trình.
Thuật ngữ BUG đã bị mắc kẹt như một thuật ngữ có nghĩa là một cái gì đó không hoạt động như mong đợi.
BUG nên được coi là một thuật ngữ biệt ngữ có nghĩa là một khiếm khuyết.
Một khiếm khuyết là một thuật ngữ chính xác có nghĩa là điều đó không làm như nó nên.
Bất cứ nơi nào có thể, sử dụng DEFECT thay vì BUG thực sự mang theo ý nghĩa mà chúng tôi thừa nhận những thất bại của chúng tôi (lỗi của chúng tôi, thiếu hiểu biết về các yêu cầu của người dùng hoặc những điều chúng tôi bỏ qua khi thực hiện) thay vì mặc quần áo như một lỗi "nghe có vẻ tầm thường hơn" ".
Sử dụng DEFECT.
Cố gắng không sử dụng thuật ngữ BUG. Nó ngớ ngẩn, không liên quan, lịch sử và tầm thường.
Từ Thuật ngữ tiêu chuẩn của thuật ngữ kỹ thuật phần mềm, được trích dẫn trong Cơ quan kiến thức kỹ thuật phần mềm KA về kiểm tra phần mềm và chất lượng phần mềm:
lỗi. Xem: lỗi; lỗi.
lỗi. (1) Sự khác biệt giữa giá trị hoặc điều kiện được tính toán, quan sát hoặc đo được và giá trị hoặc điều kiện đúng, được chỉ định hoặc đúng về mặt lý thuyết. Ví dụ: chênh lệch 30 mét giữa kết quả tính toán và kết quả chính xác. (2) Một bước, quy trình hoặc định nghĩa dữ liệu không chính xác. Ví dụ, một hướng dẫn không chính xác trong một chương trình máy tính. (3) Một kết quả không chính xác. Ví dụ: kết quả tính toán là 12 khi kết quả đúng là 10. (4) Một hành động của con người tạo ra kết quả không chính xác. Ví dụ, một hành động không chính xác về phía lập trình viên hoặc nhà điều hành. Lưu ý: Mặc dù cả bốn định nghĩa đều được sử dụng phổ biến, một phân biệt gán định nghĩa 1 cho từ lỗi Lỗi, định nghĩa 2 cho từ lỗi Lỗi, định nghĩa 3 cho từ Lỗi, lỗi và định nghĩa 4 cho từ lỗi Sai. Xem a2so: lỗi động; lỗi nghiêm trọng; lỗi bản địa; lỗi ngữ nghĩa; lỗi cú pháp; lỗi tĩnh; lỗi thoáng qua.
thất bại. Không có khả năng của một hệ thống hoặc thành phần để thực hiện các chức năng cần thiết của nó trong các yêu cầu hiệu suất được chỉ định. Lưu ý: Kỷ luật về khả năng chịu lỗi phân biệt giữa hành động của con người (lỗi), biểu hiện của nó (lỗi phần cứng hoặc phần mềm), kết quả của lỗi (lỗi) và số lượng kết quả không chính xác (lỗi). Xem thêm: tai nạn; thất bại phụ thuộc; ngoại lệ; chế độ thất bại; tỷ lệ thất bại; thất bại nặng nề; thất bại thất bại; thất bại độc lập; thất bại ngẫu nhiên; thất bại mềm; thất bại mắc kẹt.
lỗi. (1) Khiếm khuyết trong thiết bị hoặc thành phần phần cứng; ví dụ ngắn mạch hoặc đứt dây. (2) Một bước, quy trình hoặc định nghĩa dữ liệu không chính xác trong chương trình máy tính. Lưu ý: Định nghĩa này được sử dụng chủ yếu bởi các quy tắc chịu lỗi. Trong cách sử dụng phổ biến, các thuật ngữ lỗi lỗi và lỗi bug được sử dụng để diễn đạt ý nghĩa này. Xem thêm: lỗi nhạy cảm với dữ liệu; chương trình lỗi nhạy cảm; lỗi tương đương; mặt nạ lỗi; lỗi gián đoạn.
Tôi nghĩ định nghĩa về sự thất bại là phù hợp nhất. Mọi thứ bắt đầu với một lỗi, cho dù đó là trong các yêu cầu, thiết kế, thực hiện hoặc trường hợp / quy trình thử nghiệm. Nếu lỗi này được biểu hiện trong phần mềm, nó sẽ trở thành một lỗi. Một lỗi được gây ra bởi sự tồn tại của một hoặc nhiều lỗi trong phần mềm.
Mặc dù vậy, tôi không quan tâm đến định nghĩa chính thức về lỗi. Tôi rất thích định nghĩa được cung cấp bởi dukeofgaming trong câu trả lời của anh ấy , tuy nhiên, cái trong câu trả lời này là định nghĩa lỗi chuẩn của IEEE.
Câu trả lời của Dan McGrath đóng đinh đúng.
Có lẽ một ví dụ sẽ làm cho nó rõ ràng hơn.
Ví dụ: Khách hàng muốn biểu mẫu web có thể lưu và đóng cửa sổ.
Kịch bản # 1: Biểu mẫu web có nút lưu và nút đóng khác. Kết quả: Khiếm khuyết, vì khách hàng muốn nút 1 để lưu và đóng cửa sổ. Nhà phát triển hiểu lầm và tạo riêng. Bởi vì cả hai nút thực hiện các yêu cầu của họ, đó không phải là lỗi, mà là lỗi vì nó không đáp ứng yêu cầu của khách hàng.
Kịch bản # 2: Biểu mẫu web có nút lưu và đóng, nhưng chỉ lưu nhưng không đóng. Kết quả: Lỗi. Bởi vì nút không thực hiện theo yêu cầu / mong đợi. Nhà phát triển biết rằng nó được cho là tạo ra kết quả đó nhưng cuối cùng thì không. (có lẽ lỗi mã hóa)
Không chắc chắn nếu điều này làm cho nó rõ ràng hơn.
p / s: từ quan điểm của nhà phát triển (tôi đã từng), cả lỗi và lỗi đều quan trọng như nhau. Chúng tôi vẫn sẽ sửa nó.
Chúng tôi thậm chí đã gặp phải sự bất thường kỳ lạ, chúng tôi đã phân loại theo các lỗi và chúng tôi liên tục cố gắng tìm ra nguyên nhân và cách khắc phục nó. Chấm dứt lỗi không làm cho nó tầm thường so với khuyết điểm.
Sự khác biệt là thuật ngữ "lỗi" nghe có vẻ kỳ diệu. Như thể một chương trình có thể ngẫu nhiên có lỗi trong đó sau khi bạn lập trình xong. Nếu nó có lỗi ngẫu nhiên thì điều đó có nghĩa là bạn đã không tuân thủ các thông số kỹ thuật và chương trình của bạn bị lỗi.
Lỗi có nghĩa là lỗi trong đó chương trình không phù hợp với thông số kỹ thuật. Điều này là nghiêm trọng hơn và về cơ bản nói, bất kỳ lỗi nào là một vấn đề lớn với chương trình và điều này có nghĩa là chương trình không phù hợp để được phát hành.
Sự khác biệt là ở thái độ của các lập trình viên sử dụng các thuật ngữ. Có hàng triệu chương trình được phát hành có lỗi và mọi người vẫn ổn với điều đó bởi vì họ chấp nhận vì một lý do nào đó rằng một lỗi là kỳ diệu và ngẫu nhiên và mỗi chương trình đều có ít nhất một lỗi. Tuy nhiên, một lập trình viên sử dụng thuật ngữ "khiếm khuyết" có thể trở nên không thoải mái khi phát hành một chương trình có khiếm khuyết vì thuật ngữ này hàm ý mức độ nghiêm trọng cao hơn.
Ý nghĩa của việc thích một thuật ngữ hơn các thuật ngữ khác ảnh hưởng đến chúng ta hàng ngày.
Theo độ tin cậy: các khái niệm và thuật ngữ cơ bản :
Một lỗi hệ thống xảy ra khi dịch vụ được phân phối không hoàn thành chức năng hệ thống, sau đó là những gì hệ thống được dự định. Một lỗi là một phần của trạng thái hệ thống có thể dẫn đến lỗi tiếp theo: lỗi ảnh hưởng đến dịch vụ là một dấu hiệu cho thấy lỗi xảy ra hoặc đã xảy ra. Nguyên nhân được phân xử hoặc đưa ra giả thuyết về lỗi là một lỗi .
Tôi hiểu khiếm khuyết như chỉ là một tên khác cho lỗi.
Lỗi là khó hiểu và có thể đại diện cho một lỗi hoặc một lỗi tùy thuộc vào bối cảnh.
Lưu ý rằng không có đề cập đến đặc điểm kỹ thuật: thậm chí một thông số kỹ thuật có thể bị lỗi.
Đây là một cái tôi đã làm trước đó cho nhà tuyển dụng Q-LEAP của tôi dựa trên từ vựng ISTQB và tôi cũng đã kiểm tra từ vựng của IEEE. Thưởng thức.
Lỗi và khuyết tật? Giống nhau mặc dù người ta có thể có cuộc thảo luận bất tận về điều này. Chúng tôi thực sự có những thứ khác để lo lắng, cuộc sống đã đủ phức tạp rồi, v.v.
Một ví dụ về cách sử dụng thuật ngữ này trong tự nhiên, từ "Cách phần mềm kiểm tra của Google" trang. 113. Mở một bài viết về "Phần mềm IEEE" và nó được sử dụng theo cùng một cách. Thật vậy, người ta hiếm khi gặp từ "khiếm khuyết" trong cuộc sống thực.
Cuộc đời của một con bọ
Lỗi và báo cáo lỗi là một yếu tố mà mọi người kiểm tra đều hiểu. Tìm lỗi, sửa lỗi, sửa lỗi và hồi quy lỗi là nhịp đập và quy trình làm việc cho chất lượng phần mềm. Đây là một phần của thử nghiệm thông thường nhất tại Google, nhưng vẫn có một vài sai lệch thú vị so với định mức. Đối với phần này, chúng tôi bỏ qua các lỗi được đệ trình để theo dõi các mục công việc và sử dụng thuật ngữ để xác định mã bị hỏng thực tế. Do đó, lỗi thường đại diện cho quy trình làm việc hàng giờ và hàng ngày cho các nhóm kỹ thuật.
Một lỗi được sinh ra. Lỗi được tìm thấy và nộp bởi tất cả mọi người tại Google. Người quản lý sản phẩm báo cáo lỗi khi họ bắt gặp sự cố trong các bản dựng ban đầu khác nhau về hình thức thông số kỹ thuật / suy nghĩ của họ. Các nhà phát triển gửi các lỗi khi họ nhận ra rằng họ đã vô tình kiểm tra một vấn đề hoặc tìm thấy một vấn đề ở đâu đó trong cơ sở mã, hoặc trong khi làm thức ăn cho các sản phẩm của Google. Lỗi cũng đến từ lĩnh vực này, từ những người kiểm tra có nguồn gốc đám đông, kiểm tra nhà cung cấp bên ngoài và được các Quản lý Cộng đồng đệ trình theo dõi các Nhóm Google dành riêng cho sản phẩm. Nhiều phiên bản nội bộ của ứng dụng cũng có các cách nhanh chóng bằng một cú nhấp để xử lý các lỗi, như bản đồ của Google. Và, đôi khi, các chương trình phần mềm tạo ra lỗi thông qua API.
Ngoài lỗi cụ thể / nhiệm vụ / vé / lỗi / vấn đề / bất kỳ trường hợp hệ thống theo dõi nào, những từ này không có ý nghĩa chính xác và do đó thảo luận về sự khác biệt giữa chúng là vô nghĩa. Khi bạn đang giải quyết quy trình công việc của mình, bạn nên giải quyết thuật ngữ và cung cấp các mô tả.
Trong môi trường hiện tại của tôi, "khiếm khuyết" là bất kỳ mục nào trong Jira. Có vẻ như chính Jira sử dụng thuật ngữ "vấn đề". Chúng tôi có thể đã thừa hưởng nó từ một số hệ thống trước đó. "Lỗi" là một loại vấn đề khi một cái gì đó không hoạt động như mong đợi và được mô tả trong tài liệu. "Yêu cầu tính năng" khi một cái gì đó hoạt động như mong đợi nhưng mong muốn được cải thiện (nó có thể rõ ràng và quan trọng, nhưng nếu hành vi hiện tại được mô tả thì đó vẫn là một yêu cầu tính năng). Có nhiều loại hơn nhưng 2 loại đó được sử dụng bởi những người bên ngoài nhóm phát triển để hỏi điều gì đó từ nó.
Nếu bạn đang chọn tên cho các loại sự cố, âm thanh "lỗi" và "lỗi" tương tự như tôi. Sự khác biệt giữa chúng là phong cách. Vì tiếng Anh không phải là ngôn ngữ mẹ đẻ của tôi, tôi thực sự không thể nhìn thấy nhiều ngôn ngữ đó và không chắc những gì tôi thấy là chính xác.