Định nghĩa lỗi phần mềm. Blizzard Entertainment khẳng định rằng lỗi Bug của tôi không phải là lỗi gì cả. Họ có đúng không? [đóng cửa]

Theo Wikipepdia,

Lỗi phần mềm là thuật ngữ phổ biến được sử dụng để mô tả lỗi, sai sót, lỗi, lỗi hoặc lỗi trong chương trình máy tính hoặc hệ thống tạo ra kết quả không chính xác hoặc không mong muốn hoặc khiến nó hoạt động theo cách không lường trước được.

Gần đây tôi đã tìm thấy một "lỗi" trong StarCraft 2 tạo ra kết quả không mong muốn: http://eu.battle.net/sc2/en/forum/topic/2868627470

Vấn đề là nếu tôi giữ StarCraft 2 được thu nhỏ trong một thời gian dài, trò chơi sẽ không ngắt kết nối hoặc tạo ra bất kỳ hình thức hết thời gian chờ nào. Tuy nhiên, nó sẽ ngắt kết nối sau trận chiến đầu tiên và đôi khi cũng mất dữ liệu trò chơi (thống kê trận đấu).

Thật không may, theo Blizzard:

Trò chơi không được thiết kế để được giảm thiểu trong một khoảng thời gian dài như vậy. (Blizzard) không thể coi hành vi đó là sai lầm vì StarCraft II không có nghĩa là được giảm thiểu trong nhiều giờ.

Vì vậy, "lỗi" của tôi thực sự là một lỗi?

Đối với một nhóm phần mềm, một lỗi là một vấn đề phần mềm cần được sửa chữa. Không phải tất cả các vấn đề phần mềm cần phải được sửa chữa.

Cập nhật phần mềm là tốn kém. Blizzard đang nói với bạn rằng vấn đề của bạn là một trường hợp cạnh. Nói cách khác, vấn đề trường hợp cạnh mà bạn phát hiện ra không nhất thiết là thứ mà họ đã kiểm tra hoặc quan tâm để giải quyết. Khắc phục sự cố sẽ giúp bạn, nhưng rất có thể nó sẽ không giúp được nhiều người khác. Tuy nhiên, chi phí để sửa lỗi có thể cao. Thay vào đó, họ có thể đầu tư tài nguyên của mình vào các tính năng mới hoặc thậm chí hoàn thành Diablo III.

Kiểu này làm tôi nhớ đến con mèo trong lò vi sóng , cụ thể là trường hợp của bà Smith năm 1983.

Vấn đề là, bạn mong đợi sản phẩm hoạt động theo cách như vậy. Chủ yếu là vì một số sản phẩm tương tự hoạt động như vậy, tức là nếu bạn giảm thiểu chúng trong nhiều giờ và sau đó mở chúng ra, chúng hoạt động (mặc dù điều ngược lại không phổ biến như bạn nghĩ).

Bà Smith biết từ kinh nghiệm của mình, rằng việc phơi khô mèo trong lò sẽ không gây hại cho chúng (dĩ nhiên là có một chút thận trọng). Chính xác hơn từ kinh nghiệm cô có với tất cả các lò nướng cô đã thử. Sau đó, cô cho rằng nó sẽ giống với lò vi sóng mà cô được tặng. Giả định này là sai. Lò vi sóng không được thiết kế để làm khô mèo. Không phải là lò nướng thông thường. Họ chỉ tình cờ không giết chết con mèo trong quá trình này như là một tác dụng phụ của các quá trình vật lý mà họ sử dụng để tạo ra nhiệt.

Bây giờ là nhà sản xuất lò vi sóng, bạn có thể đặt một cuộn dây đốt nóng và số lượng cảm biến vào lò vi sóng. Cái sau sẽ xác định, liệu nội dung hiện tại có phải là một con mèo hay không và sử dụng cuộn dây thay vì vi sóng.

Theo cách tương tự, người ta có thể sản xuất lò vi sóng phù hợp với mèo khô, Blizzard có thể tạo ra một phiên bản SC2 phù hợp để ở trạng thái tối thiểu trong thời gian dài.

Cá nhân, tôi sẵn sàng trả nhiều tiền hơn cho lò vi sóng có thể làm khô mèo chỉ vì niềm vui của nó (giả sử có một biểu tượng phù hợp với việc sấy khô mèo ở phía trước mà tôi có thể tự hào chỉ vào). Nhưng tôi sẽ không quan tâm đến một trò chơi có thể giảm thiểu trong nhiều giờ.

SC2 được thiết kế để đáp ứng các yêu cầu nhất định. Kỳ vọng của bạn không phải là một phần của những điều đó. Bạn có thể tự do đo SC2 theo mong đợi của bạn. Nhưng liệu Blizzard có bao gồm tất cả chúng trong phạm vi yêu cầu của chúng hay không cuối cùng là lựa chọn của chúng.

Tất cả những gì bạn thực sự có thể tranh luận là, đó là một thất bại trong thiết kế. Thông thường chỉ ra rằng trừ khi một phần đáng kể người dùng bị nhầm lẫn bởi thiết kế hoặc không hài lòng với nó, nó đủ tốt. Tôi chắc chắn nếu đủ người dùng nói rằng họ chia sẻ kỳ vọng của bạn, Blizzard sẽ mang lại và đưa nó vào thiết kế. Điều này sẽ khiến vấn đề của bạn trở thành một lỗi thực tế và Blizzard sẽ khắc phục nó.

Tôi nghĩ rằng đây là một trường hợp phần mềm không được sử dụng theo định nghĩa của thông số kỹ thuật. Họ nói

Trò chơi không được thiết kế để được giảm thiểu trong một khoảng thời gian dài như vậy.

Điều đó có nghĩa là họ có một số định nghĩa ở đâu đó được coi là "khoảng thời gian dài". Nếu bạn thu nhỏ chương trình trong hơn một "khoảng thời gian dài", nó sẽ vượt xa các thông số kỹ thuật của họ và vượt xa những gì họ đã thử nghiệm (giả sử họ chính thức đề cập đến điều này) và họ không đảm bảo điều gì sẽ xảy ra. Tất nhiên, thật tuyệt nếu hướng dẫn sử dụng ở đâu đó nói rằng "chúng tôi chỉ thử nghiệm chương trình này để được giảm thiểu trong khoảng thời gian không quá 10 phút. Giảm thiểu thời gian lâu hơn so với rủi ro của riêng bạn!".

Vì vậy, không, tôi không nghĩ rằng đây thực sự là một lỗi. Trong văn phòng của tôi, đây sẽ được gọi là "sự cố đào tạo người dùng" (mà tôi nói là một dạng của vấn đề giao tiếp , vì trong trường hợp này vì không có thời gian tối thiểu để truyền đạt thời gian tối thiểu cho người dùng) vì người dùng là không sử dụng chương trình đúng cách. Không phải là nó giúp ích nhiều cho Blizzard, trừ khi họ đưa nó vào hướng dẫn ...

Không phải là một lỗi. Một lỗi là hành vi không tuân thủ các đặc điểm kỹ thuật. Nếu thông số kỹ thuật nói rằng ca sử dụng không phải là hành vi được hỗ trợ thì mọi hành vi - được coi là hợp lệ hay không - trong trường hợp sử dụng đó là 'theo thiết kế'.

Trong kịch bản này, trò chơi hoạt động hoàn toàn có thể được coi là hành vi không xác định.

Nếu tôi là trưởng nhóm phát triển trong dự án đó, tôi sẽ gọi đó là lỗi nhưng là lỗi nhỏ vì nó nằm ngoài dự đoán hoạt động bình thường của phần mềm. Nếu nó sẽ được thực hiện trên tất cả, tôi có thể giao nó cho một lập trình viên cơ sở hoặc một người thuê mới hơn là một bài tập học tập cho họ hơn bất cứ điều gì khác.

Đó là một ý tưởng tốt để theo dõi các lỗi nhỏ này vì chúng có thể chỉ ra các vấn đề tiềm ẩn sâu rộng hơn. Ví dụ, lỗi lưu dữ liệu bạn gặp phải. Nó có vẻ nhỏ do cách nó xảy ra nhưng có thể có những trường hợp khác mà dữ liệu bị mất. Bằng cách sử dụng hệ thống báo cáo lỗi, bạn có thể tìm thấy tất cả các trường hợp xảy ra sự cố tương tự và xem liệu có yếu tố chung nào không. Trong một hệ thống phức tạp, có loại tài liệu này có thể giúp bạn tìm ra các lỗi nghiêm trọng và tinh vi hơn.

Tôi sẽ không đồng ý với hầu hết mọi người ở đây.

Là một người chơi cũ của Starcraft (bản gốc), tôi có thể chứng thực rằng đây là (hoặc ít nhất là) hành vi rất phổ biến. Người dùng rời khỏi trò chơi vào 24/7 để giữ vị trí của họ trong các phòng trò chuyện và tham gia các trò chơi khi họ quay lại lần nữa. Tôi chắc chắn rằng Battle.net được cập nhật có một số cải tiến có thể làm giảm nhu cầu này, nhưng nó vẫn xảy ra rất nhiều.

Nó sẽ có ý nghĩa hơn nhiều khi nó không cho phép bạn tham gia một trò chơi mà không kết nối lại nếu phiên của bạn theo một cách nào đó, hình dạng hoặc hình thức, đã hết hạn. Việc nó cho phép bạn tham gia các trò chơi sau khi bạn hết hạn phiên là một lỗi với tôi. Điều đáng lo ngại ở đây, và một điều chưa thực sự được đưa ra, là các nhà phát triển cần phải hiểu người dùng của họ. Đây rất có thể là một trường hợp cạnh, nhưng nó là một trường hợp cạnh cho các game thủ rất tận tâm mà họ nên được đặt để làm hài lòng.

Về mặt kỹ thuật, họ có thể lập luận rằng đó là do thiết kế, và đó không phải là thứ họ định sửa. Đó vẫn là một lỗi trong mắt tôi, điều này cuối cùng tùy thuộc vào việc họ có phân loại nó là lỗi hay không. Điều đó không có nghĩa là người chơi đồng ý.

Dù sao, tôi nghĩ rằng tôi sẽ đưa ra một câu trả lời hơi khác so với những gì được đăng cho đến nay.

Một lỗi hợp lý có thể được định nghĩa là "bất kỳ sai lệch nào so với hành vi dự định của phần mềm".

Rõ ràng họ (và đó là phần mềm của họ để họ xác định cách thức hoạt động của nó) không bao giờ có ý định phần mềm xử lý tình huống này để nó không đáp ứng định nghĩa về lỗi này.

Tuy nhiên, những gì tôi muốn nói là, ít nhất, dưới mức tối ưu là cách nó xử lý tình trạng này.

Rác vào, rác ra (đó là người dùng làm điều gì đó ngu ngốc hoặc xấu hoặc bất ngờ và kết quả là một cái gì đó xấu xảy ra) đã được coi là một tiêu chuẩn hành vi kém. Tôi muốn nói ít nhất nó sẽ thanh lịch hơn trong cách xử lý tình trạng này.

Vì vậy, không hoàn toàn là một lỗi, nhưng xử lý kém của một trường hợp cạnh.

Điều đó nói rằng nếu tôi là họ thì đó không phải là điều tôi có thể cân nhắc sửa chữa (tốn kém vì quá ít lợi ích), mặc dù tôi có thể đề cập với nhóm để tham khảo trong tương lai rằng đó là điều họ có thể xử lý tốt hơn.

Định nghĩa của một lỗi không liên quan gì đến hành vi của phần mềm. Một lỗi được xác định dựa trên hành vi của phần mềm có phù hợp với ý định của nó hay không. Và ai là người nói ý định đó là gì? (Vì tôi đang làm việc với các lập trình viên ở đây, tôi sẽ làm rõ câu đầu tiên - không có hành vi phần mềm nào có thể, mà chính nó, tạo thành một lỗi).

Hãy nhớ rằng nói chung một lỗi là điều mà các nhà phát triển phần mềm phải sửa. Vì vậy, định nghĩa của một lỗi dựa trên những gì họ muốn sửa. Ví dụ: "hoạt động chính xác hơn 50% thời gian là tính năng chúng tôi dự định phát hành trong các phiên bản trong tương lai". Bất cứ điều gì có thể được định nghĩa là không phải là một lỗi bằng cách giả vờ phần mềm không bao giờ có ý định giải quyết vấn đề cụ thể đó. Vì vậy, trong thực tế, những gì cấu thành một lỗi là một sự cân nhắc chính trị hoàn toàn.

(Bên cạnh đó, điều này cắt giảm cả hai cách. Đối với một khách hàng không phải trả tiền cho việc sửa lỗi nhưng phải trả tiền cho sự phát triển mới "nó không thực hiện một số tính năng mà tôi chỉ nghĩ đến nhưng bây giờ tôi đã nghĩ đến quyết định là 100% ngụ ý bởi những điều tôi đã đề cập "rõ ràng là một lỗi.)

Tôi sẽ không xem xét việc không ngắt kết nối một lỗi. Nó chỉ là một lỗi nếu nó được cho là (theo thiết kế, ý định) ngắt kết nối và nó không. Tôi sẽ gọi những gì bạn đã gửi một yêu cầu tính năng.

Điều đó nói rằng, mất dữ liệu sau trận chiến - đó có thể là lỗi. Tôi không biết nhiều về Starcraft, nhưng tôi nghi ngờ đó không phải do thiết kế.