O que constitui um bug?


10

Na verdade, o que é um bug? alguma regra predefinida?


Podemos ter algum contexto? Você está falando de um ponto de vista puramente técnico ou de bugs que serão relatados nos sites de rastreamento?
Jeremy

5
Todos os erros são apenas escondida características :)
Marco Ceppi

2
I tendem a dizer "recursos não documentados" em vez de escondido :-)
Pouco Jawa

Respostas:


14

Um erro é:

Um bug de software é o termo comum usado para descrever um erro, falha, erro, falha ou falha em um programa ou sistema de computador que produz um resultado incorreto ou inesperado ou faz com que ele se comporte de maneiras não intencionais. (Da Wikipedia )

Aqui está outra boa definição do que constitui um bug. Ou:

  1. O programa não se comportou de acordo com as intenções do programador. ou
  2. As intenções do programador não atendiam às expectativas comuns e razoáveis ​​do usuário.

A comunidade Ubuntu possui uma excelente definição de bug neste wiki , destacando especialmente a diferença entre bug e recursos ausentes :

Um bug de software é um erro ou falha em um programa de computador que faz com que ele não funcione como deveria. Isso pode ser tão simples quanto falhar no trabalho, ou tão complicado quanto um resultado sutilmente incorreto [...] Algumas coisas não são erros, mas faltam recursos que devem ser razoavelmente incluídos. Os recursos ausentes não devem ser relatados como bugs; em vez disso, FeatureSpecifications deve ser escrito para eles.

Embora seja difícil traçar uma linha que separa as duas definições e responder à pergunta, são erros ou recursos ausentes? , é possível fornecer algumas diretrizes:

  • se for um problema que tenha muitos detalhes para resolver, provavelmente será um recurso. Por exemplo, a incapacidade de gravar arquivos com segurança em uma partição moderna do Windows é um recurso que falta.
  • A incapacidade de gravar arquivos com segurança em uma partição ReiserFS seria um bug.

A diferença entre as duas afirmações é: a primeira é mais difundida (suporta janelas modernas FS) e, portanto, pode ser vista como um recurso ausente, enquanto a outra enfatiza um problema único (não é possível gravar no ReiserFS) - um bug específico.

Se você estiver interessado, recomendo que você dê uma olhada no wiki da equipe BugSquad . O combate a bugs é uma das atividades mais interessantes envolvidas no ciclo de desenvolvimento de software, além de ser uma ótima oportunidade de aprendizado :-)

Obrigado!


legal, embora não esteja diretamente relacionado, talvez valha a pena mencionar que todo bug que você deseja cometer deve ser reproduzível.
Danizmax

Não, existem erros devido às condições da corrida. Por que você não deveria querer comprometê-los também? Será difícil, se o programador não puder reproduzir o bug, mas isso não afeta o desejo de fazê-lo, não é?
usuário desconhecido

Consulte também o guia de bugs do Ubuntu BugSquad: wiki.ubuntu.com/Bugs
Thomas Ward

2

Eu vou dar um jeito. Principalmente, comportamento não pretendido pelo designer / programador (descontando o design incorreto). Em termos de quais bugs você deve reportar às pessoas, qualquer coisa que torne o programa mais difícil de usar e se ajuste à descrição acima. Isso inclui, do pior ao menos grave, travamentos do sistema, travamentos do X, travamentos de programas e quaisquer bugs internos do programa.

Os erros que causam falhas ou o fechamento de janelas geralmente causam algum tipo de saída para stderror se você executou o aplicativo a partir de um terminal, isso pode ser útil. Consulte também os logs do sistema para obter relatórios de erros.


1

Um bug é um erro em um programa ou sistema de computador, portanto, o programa não funciona corretamente ou não funciona. Portanto, os erros podem resultar de um código de programação incorreto ou de um código de programação que não é suficientemente robusto e não pode lidar com certas exceções (por exemplo: divisão por 0)


1

Para todos os fins práticos, o termo "bug" deve ser evitado como um termo muito confuso.

A melhor resposta para sua pergunta enche um livro inteiro: "Por que os programas falham", de Andreas Zeller. Um livro que deve estar na estante de todos os programadores. O autor também faz um bom esforço para não chamá-los de "bugs" (continue lendo). Porque, como resposta da crncosta, já sugere um "bug" não é apenas um erro de programação. É por isso que algumas pessoas preferem o termo "problema" (o que leva a "rastreador de problemas" em vez de "rastreador de erros").

Porque o que é percebido como erro por um usuário final não precisa ser um erro. Pode ser - mesmo que isso seja frequentemente usado como uma desculpa esfarrapada - simplesmente por design. Algumas falhas, no entanto, uma vez observadas, são classificadas como "bugs", mesmo devido à falta de um recurso.

O autor do livro mencionado acima gasta várias páginas na definição de termos como falha e defeito e descreve por que "bug" não é um termo apropriado (muito confuso).

Resumo de sua terminologia:

  1. programador cria o defeito
  2. defeito causa uma infecção ("estado defeituoso do programa")
  3. infecção se propaga
  4. infecção causa falha ("comportamento ruim / não intencional observável")
  5. observador (geralmente o usuário final) vê a falha

Como você pode ver, o autor distingue causa e efeito, que no caso de "bug" é quase sempre misturado. Na maioria das vezes, o termo "bug" está sendo aplicado ao defeito , à infecção e à falha .

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.