Erro de software

Da Wikipédia, a enciclopédia livre
Ir para a navegação Saltar para pesquisar

Um bug de software é um erro, falha ou falha em um programa ou sistema de computador que faz com que ele produza um resultado incorreto ou inesperado, ou se comporte de maneira não intencional. O processo de encontrar e corrigir bugs é chamado de " depuração " e geralmente usa técnicas ou ferramentas formais para identificar bugs e, desde a década de 1950, alguns sistemas de computador foram projetados para também deter, detectar ou corrigir automaticamente vários bugs de computador durante as operações.

A maioria dos bugs surge de erros e erros cometidos no design de um programa ou em seu código-fonte ou em componentes e sistemas operacionais usados ​​por esses programas. Alguns são causados ​​por compiladores que produzem código incorreto. Um programa que contém muitos bugs e/ou bugs que interferem seriamente em sua funcionalidade é considerado buggy (defeituoso). Bugs podem desencadear erros que podem ter efeitos cascata . Os bugs podem ter efeitos sutis ou fazer com que o programa trave ou congele o computador. Outros bugs se qualificam como bugs de segurança e podem, por exemplo, permitir que um usuário mal -intencionado ignorecontroles de acesso para obter privilégios não autorizados . [1]

Alguns bugs de software foram associados a desastres. Bugs no código que controlavam a máquina de radioterapia Therac-25 foram diretamente responsáveis ​​pela morte de pacientes na década de 1980. Em 1996, o protótipo do foguete Ariane 5 , de US$ 1 bilhão , da Agência Espacial Européia foi destruído menos de um minuto após o lançamento devido a um bug no programa de computador de orientação a bordo. [2] Em junho de 1994, um helicóptero Chinook da Royal Air Force caiu em Mull of Kintyre , matando 29 pessoas. Isso foi inicialmente descartado como erro do piloto, mas uma investigação da Computer Weekly convenceu a Câmara dos Lordes inquérito de que pode ter sido causado por um bug de software no computador de controle do motor da aeronave . [3]

Em 2002, um estudo encomendado pelo Instituto Nacional de Padrões e Tecnologia do Departamento de Comércio dos EUA concluiu que "bugs de software, ou erros, são tão prevalentes e tão prejudiciais que custam à economia dos EUA cerca de US$ 59 bilhões anualmente, ou cerca de 0,6 por cento do produto interno bruto". [4]

História

A palavra do inglês médio bugge é a base para os termos " bugbear " e " bugaboo " como termos usados ​​para um monstro. [5]

O termo "bug" para descrever defeitos faz parte do jargão da engenharia desde a década de 1870 e é anterior a computadores eletrônicos e softwares de computador; pode ter sido originalmente usado em engenharia de hardware para descrever avarias mecânicas. Por exemplo, Thomas Edison escreveu as seguintes palavras em uma carta a um associado em 1878: [6]

Tem sido assim em todas as minhas invenções. O primeiro passo é uma intuição, e vem com uma explosão, depois surgem as dificuldades - essa coisa acaba e [é] então que os "Bugs" - como são chamados esses pequenos defeitos e dificuldades - se mostram e meses de intensa observação, estudo e trabalho são necessários antes que o sucesso ou fracasso comercial seja certamente alcançado. [7]

Baffle Ball , o primeiro jogo de pinball mecânico , foi anunciado como "livre de bugs" em 1931. [8] Problemas com equipamentos militares durante a Segunda Guerra Mundial foram referidos como bugs (ou falhas ). [9] Em um livro publicado em 1942, Louise Dickinson Rich , falando de uma máquina de corte de gelo motorizada , disse: "A serragem de gelo foi suspensa até que o criador pudesse ser trazido para tirar os insetos de sua querida." [10]

Isaac Asimov usou o termo "bug" para se relacionar com problemas com um robô em seu conto " Catch That Rabbit ", publicado em 1944.

Uma página do log do computador eletromecânico Harvard Mark II , apresentando uma mariposa morta que foi removida do dispositivo.

O termo "bug" foi usado em um relato da pioneira da computação Grace Hopper , que divulgou a causa de um mau funcionamento em um computador eletromecânico inicial. [11] Uma versão típica da história é:

Em 1946, quando Hopper foi dispensada da ativa, ingressou na Faculdade de Harvard no Laboratório de Computação, onde continuou seu trabalho no Mark II e Mark III . Os operadores rastrearam um erro no Mark II para uma mariposa presa em um relé, cunhando o termo bug . Este bug foi cuidadosamente removido e colado no livro de registro. Decorrente do primeiro bug, hoje chamamos erros ou falhas em um programa de bug . [12]

Hopper não encontrou o bug, como ela prontamente reconheceu. A data no livro de registro era 9 de setembro de 1947. [13] [14] [15] Os operadores que o encontraram, incluindo William "Bill" Burke, mais tarde do Laboratório de Armas Navais , Dahlgren, Virgínia , [16] estavam familiarizados com o termo de engenharia e divertidamente manteve o inseto com a notação "Primeiro caso real de bug encontrado". Hopper adorava contar a história. [17] Este livro de registro, completo com traça anexada, faz parte da coleção do Museu Nacional Smithsonian de História Americana . [14]

O termo relacionado " debug " também parece anteceder seu uso na computação: a etimologia da palavra do Oxford English Dictionary contém um atestado de 1945, no contexto de motores de aeronaves. [18]

O conceito de que o software pode conter erros remonta às notas de 1843 de Ada Lovelace sobre a máquina analítica , nas quais ela fala da possibilidade de "cartões" de programa para a máquina analítica de Charles Babbage serem errôneos:

... um processo de análise também deve ter sido realizado para fornecer à Máquina Analítica os dados operacionais necessários ; e que aqui também pode ser uma possível fonte de erro. Admitindo que o mecanismo real seja infalível em seus processos, as cartas podem dar ordens erradas.

Relatório "Bugs no sistema"

O Open Technology Institute, administrado pelo grupo New America, [19] divulgou um relatório "Bugs in the System" em agosto de 2016, afirmando que os formuladores de políticas dos EUA deveriam fazer reformas para ajudar os pesquisadores a identificar e resolver bugs de software. O relatório "destaca a necessidade de reforma no campo da descoberta e divulgação de vulnerabilidades de software". [20] Um dos autores do relatório disse que o Congresso não fez o suficiente para lidar com a vulnerabilidade do software cibernético, embora o Congresso tenha aprovado vários projetos de lei para combater a questão maior da segurança cibernética. [20]

Pesquisadores governamentais, empresas e especialistas em segurança cibernética são as pessoas que normalmente descobrem falhas de software. O relatório pede a reforma das leis de crimes de computador e direitos autorais. [20]

A Lei de Fraude e Abuso de Computadores, a Lei de Direitos Autorais do Milênio Digital e a Lei de Privacidade de Comunicações Eletrônicas criminalizam e criam penalidades civis para ações que os pesquisadores de segurança realizam rotineiramente enquanto conduzem pesquisas de segurança legítimas, disse o relatório. [20]

Terminologia

Embora o uso do termo "bug" para descrever erros de software seja comum, muitos sugeriram que ele deveria ser abandonado. Um argumento é que a palavra "bug" está divorciada do sentido de que um ser humano causou o problema e, em vez disso, implica que o defeito surgiu por conta própria, levando a um impulso para abandonar o termo "bug" em favor de termos como "defeito", com sucesso limitado. [21] Desde a década de 1970, Gary Kildall sugeriu com humor o uso do termo "erro". [22] [23]

Na engenharia de software, metamorfismo de erro (do grego meta = "mudança", morph = "forma") refere-se à evolução de um defeito no estágio final de implantação do software. A transformação de um "erro" cometido por um analista nas fases iniciais do ciclo de vida de desenvolvimento de software, que leva a um "defeito" na fase final do ciclo, tem sido chamada de 'metamorfismo do erro'. [24]

Diferentes estágios de um "erro" em todo o ciclo podem ser descritos como "erros", "anomalias", "falhas", "falhas", "erros", "exceções", "falhas", "falhas", "bugs" , "defeitos", "incidentes" ou "efeitos colaterais". [24]

Prevenção

Erro resultante de um bug de software exibido em duas telas na estação La Croix de Berny, na França.

A indústria de software tem se esforçado muito para reduzir a contagem de bugs. [25] [26] Estes incluem:

Erros tipográficos

Bugs geralmente aparecem quando o programador comete um erro de lógica . Várias inovações em estilo de programação e programação defensiva são projetadas para tornar esses bugs menos prováveis ​​ou mais fáceis de detectar. Alguns erros de digitação, especialmente de símbolos ou operadores lógicos/matemáticos , permitem que o programa funcione incorretamente, enquanto outros, como um símbolo ausente ou um nome com erros ortográficos, podem impedir o funcionamento do programa. As linguagens compiladas podem revelar alguns erros de digitação quando o código-fonte é compilado.

Metodologias de desenvolvimento

Vários esquemas auxiliam no gerenciamento da atividade do programador para que menos bugs sejam produzidos. A engenharia de software (que também aborda problemas de design de software) aplica muitas técnicas para evitar defeitos. Por exemplo, especificações formais de programas indicam o comportamento exato dos programas para que os erros de projeto possam ser eliminados. Infelizmente, as especificações formais são impraticáveis ​​para qualquer coisa, exceto os programas mais curtos, devido a problemas de explosão combinatória e indeterminação .

O teste de unidade envolve escrever um teste para cada função (unidade) que um programa deve executar.

No desenvolvimento orientado a testes, os testes de unidade são escritos antes do código e o código não é considerado completo até que todos os testes sejam concluídos com sucesso.

O desenvolvimento ágil de software envolve lançamentos de software frequentes com alterações relativamente pequenas. Os defeitos são revelados pelo feedback do usuário.

O desenvolvimento de código aberto permite que qualquer pessoa examine o código-fonte. Uma escola de pensamento popularizada por Eric S. Raymond como a lei de Linus diz que o software de código aberto popular tem mais chance de ter poucos ou nenhum bug do que outro software, porque "com olhos suficientes, todos os bugs são superficiais". [27] Essa afirmação foi contestada, no entanto: o especialista em segurança de computadores Elias Levy escreveu que "é fácil ocultar vulnerabilidades em código-fonte complexo, pouco compreendido e não documentado", porque "mesmo que as pessoas estejam revisando o código, isso não t significa que eles estão qualificados para fazê-lo." [28] Um exemplo disso realmente acontecendo, acidentalmente,.

Suporte à linguagem de programação

As linguagens de programação incluem recursos para ajudar a evitar bugs, como sistemas de tipo estático, namespaces restritos e programação modular . Por exemplo, quando um programador escreve (pseudocódigo) LET REAL_VALUE PI = "THREE AND A BIT", embora isso possa estar sintaticamente correto, o código falha em uma verificação de tipo . As linguagens compiladas capturam isso sem ter que executar o programa. As linguagens interpretadas detectam esses erros em tempo de execução. Algumas linguagens excluem deliberadamente recursos que facilmente levam a bugs, em detrimento do desempenho mais lento: o princípio geral é que quase sempre é melhor escrever um código mais simples e mais lento do que um código inescrutável que roda um pouco mais rápido, especialmente considerando que o custo de manutençãoé substancial. Por exemplo, a linguagem de programação Java não suporta aritmética de ponteiro ; implementações de algumas linguagens, como Pascal e linguagens de script, geralmente têm verificação de limites de tempo de execução de matrizes, pelo menos em uma compilação de depuração.

Análise de código

Ferramentas para análise de código ajudam os desenvolvedores inspecionando o texto do programa além dos recursos do compilador para detectar possíveis problemas. Embora em geral o problema de encontrar todos os erros de programação dada uma especificação não seja solucionável (veja problema de parada ), essas ferramentas exploram o fato de que programadores humanos tendem a cometer certos tipos de erros simples frequentemente ao escrever software.

Instrumentação

Ferramentas para monitorar o desempenho do software em execução, seja especificamente para encontrar problemas como gargalos ou para garantir o funcionamento correto, podem ser incorporadas no código explicitamente (talvez tão simples quanto uma declaração dizendo PRINT "I AM HERE"), ou fornecidas como Ferramentas. Muitas vezes é uma surpresa descobrir onde a maior parte do tempo é tomada por um pedaço de código, e essa remoção de suposições pode fazer com que o código seja reescrito.

Testando

Os testadores de software são pessoas cuja principal tarefa é encontrar bugs ou escrever código para dar suporte aos testes. Em alguns projetos, mais recursos podem ser gastos em testes do que no desenvolvimento do programa.

As medições durante o teste podem fornecer uma estimativa do número de bugs prováveis ​​restantes; isso se torna mais confiável quanto mais tempo um produto é testado e desenvolvido. [ citação necessária ]

Depuração

O histórico de bugs típico ( dados do projeto GNU Classpath ). Um novo bug enviado pelo usuário não é confirmado. Uma vez reproduzido por um desenvolvedor, é um bug confirmado . Os bugs confirmados são corrigidos posteriormente . Bugs pertencentes a outras categorias (irreprodutíveis, não serão corrigidos, etc.)

Encontrar e corrigir bugs, ou depurar , é uma parte importante da programação de computadores . Maurice Wilkes , um pioneiro da computação, descreveu sua percepção no final da década de 1940 de que grande parte do resto de sua vida seria gasto encontrando erros em seus próprios programas. [29]

Normalmente, a parte mais difícil da depuração é encontrar o bug. Uma vez encontrado, corrigi-lo geralmente é relativamente fácil. Programas conhecidos como depuradores ajudam os programadores a localizar bugs executando código linha por linha, observando valores de variáveis ​​e outros recursos para observar o comportamento do programa. Sem um depurador, o código pode ser adicionado para que mensagens ou valores possam ser gravados em um console ou em uma janela ou arquivo de log para rastrear a execução do programa ou mostrar valores.

No entanto, mesmo com a ajuda de um depurador, localizar bugs é uma arte. Não é incomum que um bug em uma seção de um programa cause falhas em uma seção completamente diferente, [ citação necessária ] tornando-o especialmente difícil de rastrear (por exemplo, um erro em uma rotina de renderização de gráficos causando uma E/S de arquivo rotina falhar), em uma parte aparentemente não relacionada do sistema.

Às vezes, um bug não é uma falha isolada, mas representa um erro de pensamento ou planejamento por parte do programador. Esses erros de lógica exigem que uma seção do programa seja revisada ou reescrita. Como parte da revisão de código , percorrer o código e imaginar ou transcrever o processo de execução pode frequentemente encontrar erros sem nunca reproduzir o bug como tal.

Mais tipicamente, o primeiro passo para localizar um bug é reproduzi-lo de forma confiável. Uma vez que o bug é reproduzível, o programador pode usar um depurador ou outra ferramenta enquanto reproduz o erro para encontrar o ponto em que o programa se desviou.

Alguns bugs são revelados por entradas que podem ser difíceis para o programador recriar. Uma causa das mortes da máquina de radiação Therac-25 foi um bug (especificamente, uma condição de corrida ) que ocorreu apenas quando o operador da máquina entrou muito rapidamente em um plano de tratamento; levou dias de prática para se tornar capaz de fazer isso, então o bug não se manifestou nos testes ou quando o fabricante tentou duplicá-lo. Outros bugs podem parar de ocorrer sempre que a configuração for aumentada para ajudar a encontrar o bug, como executar o programa com um depurador; estes são chamados heisenbugs (humoricamente nomeados após o princípio da incerteza de Heisenberg ).

Desde a década de 1990, particularmente após o desastre do Ariane 5 Flight 501 , o interesse em auxílios automatizados para depuração aumentou, como análise de código estático por interpretação abstrata . [30]

Algumas classes de bugs não têm nada a ver com o código. Documentação ou hardware defeituosos podem levar a problemas no uso do sistema, mesmo que o código corresponda à documentação. Em alguns casos, as alterações no código eliminam o problema, mesmo que o código não corresponda mais à documentação. Sistemas embarcados frequentemente contornam bugs de hardware, já que fazer uma nova versão de uma ROM é muito mais barato do que remanufaturar o hardware, especialmente se forem itens de commodities .

Benchmark de bugs

Para facilitar a pesquisa reproduzível sobre teste e depuração, os pesquisadores usam benchmarks de bugs selecionados:

  • a referência da Siemens
  • ManyBugs [31] é um benchmark de 185 C bugs em nove programas de código aberto.
  • Defects4J [32] é um benchmark de 341 bugs Java de 5 projetos de código aberto. Ele contém os patches correspondentes, que cobrem uma variedade de tipos de patches. [33]
  • BEARS [34] é um benchmark de falhas de construção de integração contínua com foco em falhas de teste. Ele foi criado monitorando compilações de projetos de código aberto no Travis CI .

Gerenciamento de bugs

O gerenciamento de bugs inclui o processo de documentar, categorizar, atribuir, reproduzir, corrigir e liberar o código corrigido. As alterações propostas ao software – bugs, solicitações de aprimoramento e até versões inteiras – geralmente são rastreadas e gerenciadas usando sistemas de rastreamento de bugs ou sistemas de rastreamento de problemas . [35] Os itens adicionados podem ser chamados de defeitos, tickets, problemas ou, seguindo o paradigma de desenvolvimento ágil , histórias e épicos. As categorias podem ser objetivas, subjetivas ou uma combinação, como número da versão , área do software, gravidade e prioridade, bem como o tipo de problema, como uma solicitação de recurso ou um bug.

Uma triagem de bugs analisa os bugs e decide se e quando corrigi-los. A decisão é baseada na prioridade do bug e em fatores como cronogramas do projeto. A triagem não visa investigar a causa dos bugs, mas sim o custo de corrigi-los. A triagem acontece regularmente, e passa por bugs abertos ou reabertos desde a reunião anterior. Os participantes do processo de triagem geralmente são o gerente de projeto, gerente de desenvolvimento, gerente de teste, gerente de construção e especialistas técnicos. [36] [37]

Gravidade

A gravidade é a intensidade do impacto que o bug tem na operação do sistema. [38] Esse impacto pode ser perda de dados, financeiro, perda de boa vontade e desperdício de esforço. Os níveis de gravidade não são padronizados. Os impactos diferem entre os setores. Uma falha em um videogame tem um impacto totalmente diferente de uma falha em um navegador da web ou sistema de monitoramento em tempo real. Por exemplo, os níveis de gravidade do bug podem ser "travar ou travar", "sem solução alternativa" (o que significa que não há como o cliente realizar uma determinada tarefa), "tem solução alternativa" (o que significa que o usuário ainda pode realizar a tarefa), "visual defeito" (por exemplo, uma imagem ausente ou um botão ou elemento de formulário deslocado) ou "erro de documentação". Alguns editores de software usam severidades mais qualificadas, como "crítico", "alto", "baixo", "bloqueador" ou "trivial". [39]A gravidade de um bug pode ser uma categoria separada de sua prioridade para correção, e as duas podem ser quantificadas e gerenciadas separadamente.

Prioridade

A prioridade controla onde um bug se enquadra na lista de mudanças planejadas. A prioridade é decidida por cada produtor de software. As prioridades podem ser numéricas, como 1 a 5, ou nomeadas, como "crítica", "alta", "baixa" ou "adiada". Essas escalas de classificação podem ser semelhantes ou até idênticas às classificações de gravidade , mas são avaliadas como uma combinação da gravidade do bug com seu esforço estimado de correção; um bug com gravidade baixa, mas fácil de corrigir, pode ter uma prioridade mais alta do que um bug com gravidade moderada que requer esforço excessivo para ser corrigido. As classificações de prioridade podem ser alinhadas com as versões do produto, como prioridade "crítica", indicando todos os bugs que devem ser corrigidos antes da próxima versão do software.

Lançamentos de software

É uma prática comum lançar software com bugs conhecidos e de baixa prioridade. Bugs de prioridade suficientemente alta podem garantir uma liberação especial de parte do código contendo apenas módulos com essas correções. Estes são conhecidos como patches . A maioria dos lançamentos inclui uma mistura de mudanças de comportamento e várias correções de bugs. As versões que enfatizam correções de bugs são conhecidas como versões de manutenção , para diferenciá-las das principais versões que enfatizam adições ou alterações de recursos.

Os motivos pelos quais um editor de software opta por não corrigir ou até mesmo corrigir um bug específico incluem:

  • Um prazo deve ser cumprido e os recursos são insuficientes para corrigir todos os bugs dentro do prazo. [40]
  • O bug já foi corrigido em uma próxima versão e não é de alta prioridade.
  • As alterações necessárias para corrigir o bug são muito caras ou afetam muitos outros componentes, exigindo uma grande atividade de teste.
  • Pode-se suspeitar, ou saber, que alguns usuários estão confiando no comportamento de bugs existente; uma correção proposta pode introduzir uma alteração importante .
  • O problema está em uma área que ficará obsoleta com uma versão futura; corrigi-lo é desnecessário.
  • "Isto não é um erro, é um recurso". [41] Surgiu um mal-entendido entre o comportamento esperado e o percebido ou o recurso não documentado .

Tipos

Em projetos de desenvolvimento de software, um “erro” ou “falha” pode ser introduzido em qualquer estágio. Bugs surgem de descuidos ou mal-entendidos feitos por uma equipe de software durante a especificação, projeto, codificação, entrada de dados ou documentação. Por exemplo, um programa relativamente simples para colocar uma lista de palavras em ordem alfabética, o design pode deixar de considerar o que deve acontecer quando uma palavra contém um hífen . Ou, ao converter um design abstrato em código, o codificador pode criar inadvertidamente um erro off-by-one e não conseguir classificar a última palavra em uma lista. Erros podem ser tão simples quanto um erro de digitação: um "<" onde um ">" foi pretendido.

Outra categoria de bug é chamada de condição de corrida que pode ocorrer quando os programas têm vários componentes em execução ao mesmo tempo. Se os componentes interagirem em uma ordem diferente da pretendida pelo desenvolvedor, eles podem interferir uns nos outros e impedir que o programa conclua suas tarefas. Esses bugs podem ser difíceis de detectar ou antecipar, pois podem não ocorrer durante todas as execuções de um programa.

Erros conceituais são um mal-entendido do desenvolvedor sobre o que o software deve fazer. O software resultante pode funcionar de acordo com o entendimento do desenvolvedor, mas não o que é realmente necessário. Outros tipos:

Aritmética

Lógica

Sintaxe

  • Uso do operador errado, como realizar atribuição em vez de teste de igualdade . Por exemplo, em alguns idiomas x=5 definirá o valor de x para 5 enquanto x==5 verificará se x é atualmente 5 ou algum outro número. As linguagens interpretadas permitem que esse código falhe. As linguagens compiladas podem detectar esses erros antes do início do teste.

Recurso

Multi-threading

Interface

  • Uso incorreto da API. [42]
  • Implementação de protocolo incorreta.
  • Manuseio incorreto de hardware.
  • Suposições incorretas de uma plataforma específica.
  • Sistemas incompatíveis. Uma nova API ou protocolo de comunicação pode parecer funcionar quando dois sistemas usam versões diferentes, mas podem ocorrer erros quando uma função ou recurso implementado em uma versão é alterado ou ausente em outra. Em sistemas de produção que devem ser executados continuamente, o desligamento de todo o sistema para uma atualização importante pode não ser possível, como na indústria de telecomunicações [43] ou na Internet. [44] [45] [46] Neste caso, segmentos menores de um grande sistema são atualizados individualmente, para minimizar a interrupção de uma grande rede. No entanto, algumas seções podem ser ignoradas e não atualizadas e causar erros de compatibilidade que podem ser difíceis de encontrar e reparar.
  • Anotações de código incorretas [47]

Trabalho em equipe

  • Atualizações não propagadas; por exemplo, o programador altera "myAdd", mas esquece de alterar "mySubtract", que usa o mesmo algoritmo. Esses erros são mitigados pela filosofia Don't Repeat Yourself .
  • Comentários desatualizados ou incorretos: muitos programadores assumem que os comentários descrevem com precisão o código.
  • Diferenças entre documentação e produto.

Implicações

A quantidade e o tipo de dano que um bug de software pode causar afeta naturalmente a tomada de decisões, os processos e a política em relação à qualidade do software. Em aplicações como voos espaciais tripulados ou segurança automotiva , uma vez que falhas de software têm o potencial de causar ferimentos ou até mesmo a morte humana, tal software terá muito mais escrutínio e controle de qualidade do que, por exemplo, um site de compras online. Em aplicativos como bancos, onde falhas de software têm o potencial de causar sérios danos financeiros a um banco ou a seus clientes, o controle de qualidade também é mais importante do que, digamos, um aplicativo de edição de fotos. O Software Assurance Technology Center da NASA conseguiu reduzir o número de erros para menos de 0,1 por 1000 linhas de código ( SLOC )[ citação necessária ] mas isso não foi considerado viável para projetos no mundo dos negócios.

De acordo com um estudo da NASA sobre " Flight Software Complexity ", "um processo de desenvolvimento de software excepcionalmente bom pode manter defeitos tão baixos quanto 1 defeito por 10.000 linhas de código". [48]

Além dos danos causados ​​pelos bugs, parte de seu custo se deve ao esforço investido em corrigi-los. Em 1978, Lientz e al. mostrou que a mediana dos projetos investe 17% do esforço de desenvolvimento na correção de bugs. [49] Em uma pesquisa em 2020 nos repositórios do GitHub , a mediana é de 20%. [50]

Erros conhecidos

Vários bugs de software se tornaram bem conhecidos, geralmente devido à sua gravidade: exemplos incluem vários acidentes espaciais e de aeronaves militares. Possivelmente o bug mais famoso é o problema do ano 2000 , também conhecido como o bug Y2K, no qual se temia que o colapso econômico mundial acontecesse no início do ano 2000 como resultado dos computadores pensarem que era 1900. (No final , não ocorreram grandes problemas.) A interrupção da negociação de ações de 2012 envolveu uma dessas incompatibilidades entre a API antiga e uma nova API.

Na cultura popular

  • Tanto no romance de 1968 2001: A Space Odyssey quanto no filme de 1968 correspondente 2001: A Space Odyssey , o computador de bordo de uma nave espacial, HAL 9000 , tenta matar todos os membros da tripulação. No romance seguinte de 1982, 2010: Odyssey Two , e no filme de 1984 que o acompanha, 2010 , é revelado que essa ação foi causada pelo computador ter sido programado com dois objetivos conflitantes: divulgar totalmente todas as suas informações e manter o verdadeiro propósito do segredo de voo da tripulação; esse conflito fez com que HAL se tornasse paranóico e eventualmente homicida.
  • Na versão em inglês da música Nena 1983 99 Luftballons (99 Red Balloons) como resultado de "bugs no software", um lançamento de um grupo de 99 balões vermelhos é confundido com um lançamento de míssil nuclear inimigo, exigindo uma resposta de lançamento equivalente , resultando em catástrofe.
  • Na comédia americana de 1999 Office Space , três funcionários tentam explorar a preocupação de sua empresa em consertar o bug do computador Y2K infectando o sistema de computador da empresa com um vírus que envia centavos arredondados para uma conta bancária separada. O plano sai pela culatra, pois o próprio vírus tem seu próprio bug, que envia grandes quantias de dinheiro para a conta prematuramente.
  • O romance de 2004 The Bug , de Ellen Ullman , é sobre a tentativa de um programador de encontrar um bug indescritível em um aplicativo de banco de dados. [51]
  • O filme canadense de 2008 Control Alt Delete é sobre um programador de computador no final de 1999 lutando para corrigir bugs em sua empresa relacionados ao problema do ano 2000.

Veja também

Referências

  1. ^ Mittal, Varun; Aditya, Shivam (1 de janeiro de 2015). "Desenvolvimentos recentes no campo da correção de bugs" . Procedia Ciência da Computação . Conferência Internacional sobre Informática, Comunicação e Convergência (ICCC 2015). 48 : 288-297. doi : 10.1016/j.procs.2015.04.184 . ISSN  1877-0509 .
  2. ^ "Ariane 501 - Apresentação do relatório do Conselho de Inquérito" . www.esa.int . Recuperado em 29 de janeiro de 2022 .
  3. ^ Prof. Simon Rogerson . "O desastre do helicóptero Chinook" . Ccsr.cse.dmu.ac.uk. Arquivado do original em 17 de julho de 2012 . Recuperado em 24 de setembro de 2012 .
  4. ^ "Bugs de software custam caro a economia dos EUA" . 10 de junho de 2009. Arquivado a partir do original em 10 de junho de 2009 . Recuperado em 24 de setembro de 2012 .{{cite web}}: CS1 maint: unfit URL (link)
  5. ^ Pessoal da Computerworld (3 de setembro de 2011). "Mariposa na máquina: Depurando as origens do 'bug'" . Computerworld . Arquivado a partir do original em 25 de agosto de 2015.
  6. ^ "Você sabia? Edison cunhou o termo "Bug"" . 1 de agosto de 2013 . Recuperado em 19 de julho de 2019 .
  7. Edison to Puskas, 13 de novembro de 1878, Edison papers, Edison National Laboratory, US National Park Service, West Orange, NJ, citado em Hughes, Thomas Parke (1989). American Genesis: um século de invenção e entusiasmo tecnológico, 1870-1970 . Livros do pinguim. pág. 75. ISBN 978-0-14-009741-2.
  8. ^ "Baffle Ball" . Banco de dados de Pinball da Internet. (Veja a imagem do anúncio na entrada de referência)
  9. ^ "Porta-aviões modernos são resultado de 20 anos de experimentação inteligente" . Vida . 29 de junho de 1942. p. 25. Arquivado do original em 4 de junho de 2013 . Recuperado em 17 de novembro de 2011 .
  10. Dickinson Rich, Louise (1942), We Took to the Woods , JB Lippincott Co, p. 93, LCCN 42024308 , OCLC 405243 , arquivado a partir do original em 16 de março de 2017.  
  11. ^ Teste FCAT NRT , Harcourt, 18 de março de 2008
  12. ^ "Danis, Sharron Ann: "Rear Almirante Grace Murray Hopper"" . ei.cs.vt.edu. 16 de fevereiro de 1997 . Recuperado em 31 de janeiro de 2010 .
  13. ^ " Bug Arquivado em 23 de março de 2017, no Wayback Machine ", The Jargon File , ver. 4.4.7. Recuperado em 3 de junho de 2010.
  14. ^ a b " Log Book With Computer Bug Archived March 23, 2017, at the Wayback Machine ", Museu Nacional de História Americana, Smithsonian Institution.
  15. ^ " O primeiro "bug do computador ", Centro Histórico Naval. Mas observe que o computador Harvard Mark II não estava completo até o verão de 1947.
  16. ^ IEEE Annals of the History of Computing, Vol 22 Issue 1, 2000
  17. ^ James S. Huggins. "Primeiro Bug do Computador" . Jamesshuggins. com. Arquivado do original em 16 de agosto de 2000 . Recuperado em 24 de setembro de 2012 .
  18. ^ Jornal da Sociedade Aeronáutica Real . 49, 183/2, 1945 "Varia... passando pela fase de teste de tipo e teste de voo e 'depuração'..."
  19. ^ Wilson, Andi; Schulman, Ross; Bankston, Kevin; Senhor, Trey. "Bugs no sistema" (PDF) . Instituto de Política Aberta . Arquivado (PDF) do original em 21 de setembro de 2016 . Recuperado em 22 de agosto de 2016 .
  20. ^ a b c d Rozens, Tracy (12 de agosto de 2016). "Reformas cibernéticas necessárias para fortalecer a descoberta e divulgação de bugs de software: relatório New America - Homeland Preparedness News" . Recuperado em 23 de agosto de 2016 .
  21. ^ "Notícias no SEI 1999 Archive" . cmu.edu . Arquivado do original em 26 de maio de 2013.
  22. ^ Shustek, Len (2 de agosto de 2016). "Em suas próprias palavras: Gary Kildall" . Pessoas notáveis . Museu de História do Computador . Arquivado do original em 17 de dezembro de 2016.
  23. ^ Kildall, Gary Arlen (2 de agosto de 2016) [1993]. Kildall, Scott ; Kildall, Kristin (eds.). "Conexões de computador: pessoas, lugares e eventos na evolução da indústria de computadores pessoais" (Manuscrito, parte 1). Família Killall: 14–15. Arquivado do original em 17 de novembro de 2016 . Recuperado em 17 de novembro de 2016 . {{cite journal}}: Cite journal requires |journal= (help)
  24. ^ a b "Experiência de teste: te: a revista para testadores profissionais". Experiência de teste . Alemanha: experiência de teste: 42. março de 2012. ISSN 1866-5705 .  (assinatura obrigatória)
  25. ^ Huizinga, Dorota; Kolawa, Adam (2007). Prevenção Automatizada de Defeitos: Melhores Práticas em Gerenciamento de Software . Imprensa da Sociedade de Computadores Wiley-IEEE. pág. 426. ISBN 978-0-470-04212-0. Arquivado do original em 25 de abril de 2012.
  26. ^ McDonald, Marc; Musson, Roberto; Smith, Ross (2007). O Guia Prático para Prevenção de Defeitos . Imprensa da Microsoft. pág. 480 . ISBN 978-0-7356-2253-1.
  27. "Release Early, Release Frequentemente" Arquivado em 14 de maio de 2011, no Wayback Machine , Eric S. Raymond , The Cathedral and the Bazaar
  28. "Wide Open Source" Arquivado em 29 de setembro de 2007, no Wayback Machine , Elias Levy , SecurityFocus , 17 de abril de 2000
  29. ^ Frases de Maurice Wilkes
  30. ^ "História da PolySpace Technologies" . christele.faure.pagesperso-orange.fr . Recuperado em 1 de agosto de 2019 .
  31. ^ Le Goues, Claire; Holtschulte, Neal; Smith, Edward K.; Brun, Yuriy; Devanbu, Premkumar; Forrest, Stephanie; Weimer, Westley (2015). "The ManyBugs e IntroClass Benchmarks para Reparo Automatizado de Programas C" . Transações IEEE em Engenharia de Software . 41 (12): 1236-1256. doi : 10.1109/TSE.2015.2454513 . ISSN 0098-5589 . 
  32. ^ Apenas, René; Jalali, Darioush; Ernst, Michael D. (2014). "Defects4J: um banco de dados de falhas existentes para permitir estudos de testes controlados para programas Java". Anais do Simpósio Internacional de Teste e Análise de Software 2014 - ISSTA 2014 . págs. 437-440. CiteSeerX 10.1.1.646.3086 . doi : 10.1145/2610384.2628055 . ISBN  9781450326452. S2CID  12796895 .
  33. ^ Sobreira, Victor; Durieux, Thomas; Madeiral, Fernanda; Monperrus, Martin; de Almeida Maia, Marcelo (2018). "Dissection of a bug dataset: Anatomy of 395 patches from Defects4J". 2018 IEEE 25th International Conference on Software Analysis, Evolution and Reengineering (SANER) . págs. 130–140. arXiv : 1801.06393 . doi : 10.1109/SANER.2018.8330203 . ISBN 978-1-5386-4969-5. S2CID  4607810 .
  34. ^ Madeiral, Fernanda; Urli, Simon; Maia, Marcelo; Monperrus, Martin; Maia, Marcelo A. (2019). "BEARS: Um Benchmark de Bug Java Extensível para Estudos de Reparo Automático de Programa". 2019 IEEE 26th International Conference on Software Analysis, Evolution and Reengineering (SANER) . págs. 468–478. arXiv : 1901.06024 . doi : 10.1109/SANER.2019.8667991 . ISBN 978-1-7281-0591-8. S2CID  58028949 .
  35. Allen, Mitch (maio-junho de 2002). "Bug Tracking Basics: Um guia para iniciantes para relatar e rastrear defeitos" . Revista de Engenharia de Qualidade e Teste de Software . Vol. 4, não. 3. pp. 20–24 . Recuperado em 19 de dezembro de 2017 .
  36. ^ Rex Preto (2002). Gerenciando o processo de teste (2ª Ed.) . Wiley Índia Unip. Limitado. pág. 139. ISBN 9788126503131. Recuperado em 19 de junho de 2021 .
  37. Chris Vander Mey (24 de agosto de 2012). Excelência no transporte - Lições práticas sobre como construir e lançar um software excepcional, aprendidas no trabalho no Google e na Amazon . Mídia O'Reilly . pág. 79-81. ISBN 9781449336608.
  38. ^ Soleimani Neysiani, Behzad; Babamir, Seyed Morteza; Aritsugi, Masayoshi (1 de outubro de 2020). "Modelo de extração de recursos eficiente para melhoria de desempenho de validação de detecção de relatórios de bugs duplicados em sistemas de triagem de bugs de software" . Tecnologia da Informação e Software . 126 : 106344. doi : 10.1016/j.infsof.2020.106344 . S2CID 219733047 . 
  39. ^ "5.3. Anatomia de um Bug" . bugzilla.org . Arquivado do original em 23 de maio de 2013.
  40. ^ "The Next Generation 1996 Lexicon A a Z: Lançamento Slipstream" . Próxima Geração . Não. 15. Imagine Media . Março de 1996. p. 41.
  41. ^ Carr, Nicholas (2018). "'Isto não é um erro, é um recurso.' Trite—ou Just Right? " .wired.com .
  42. ^ Monperrus, Martin; Bruch, Marcel; Mezini, Mira (2010). "Detectando chamadas de método ausentes em software orientado a objetos" . ECOOP 2010 – Programação Orientada a Objetos (PDF) . Notas de aula em Ciência da Computação. Vol. 6183. pp. 2–25. doi : 10.1007/978-3-642-14107-2_2 . ISBN  978-3-642-14106-5. S2CID  16724498 .
  43. ^ Kimbler, K. (1998). Interações de Recursos em Sistemas de Telecomunicações e Software V . Imprensa IOS. pág. 8. ISBN 978-90-5199-431-5.
  44. ^ Syed, Mahbubur Rahman (1 de julho de 2001). Multimedia Networking: Tecnologia, Gestão e Aplicações: Tecnologia, Gestão e Aplicações . Idea Group Inc (IGI). pág. 398. ISBN 978-1-59140-005-9.
  45. ^ Wu, Chwan-Hwa (John); Irwin, J. David (19 de abril de 2016). Introdução às Redes de Computadores e Cibersegurança . Imprensa CRC. pág. 500. ISBN 978-1-4665-7214-0.
  46. ^ RFC 1263: Citação "TCP Extensions Considered Harmful": "o tempo para distribuir a nova versão do protocolo para todos os hosts pode ser bastante longo (na verdade para sempre). ... Se houver a menor incompatibilidade entre as versões antigas e novas , o caos pode resultar."
  47. ^ Yu, Zhongxing; Bai, Chenggang; Seinturier, Lionel; Monperrus, Martin (2019). "Caracterizando o Uso, Evolução e Impacto das Anotações Java na Prática" . Transações IEEE em Engenharia de Software . 47 (5): 1. arXiv : 1805.01965 . doi : 10.1109/TSE.2019.2910516 . S2CID 102351817 . 
  48. ^ Dvorak, estudo da NASA de Daniel L. 1 na complexidade do software do vôo . CiteSeerX 10.1.1.711.2976 . 
  49. ^ Lientz, BP; Swanson, EB; Tompkins, GE (1978). "Características da Manutenção de Software Aplicativo". Comunicações da ACM . 21 (6): 466-471. doi : 10.1145/359511.359522 . S2CID 14950091 . 
  50. ^ Amit, Idan; Feitelson, Dror G. (2020). "A Métrica de Qualidade do Código de Probabilidade de Confirmação Corretiva". arXiv : 2007.10912 [ cs.SE ].
  51. ^ Ullman, Ellen (2004). O Bug . Picador . ISBN 978-1-250-00249-5.

Links externos