Como a equipe do Ubuntu garante que os bugs não aparecerão novamente?
Eu já vi isso várias vezes. Um pacote fica inutilizável após a instalação.
Sim, às vezes os bugs são corrigidos muito rapidamente.
Mas não vejo nenhum esforço para melhorar os testes automatizados, para que o bug não apareça novamente.
Aqui estão dois exemplos que me afetaram durante as últimas duas semanas:
- https://bugs.launchpad.net/ubuntu/+source/vsftpd/+bug/1219857
- https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1290847
Existem mais exemplos, mas listá-los não faz parte da questão.
Um comentário da vsftppágina do bug:
Por favor, ajude-nos testando este novo pacote. Verhttps://wiki.ubuntu.com/Testing/EnableProposedpara documentação sobre como habilitar e usar o -proposto. Seu feedback nos ajudará a divulgar esta atualização para outros usuários do Ubuntu.
OK, mas "teste" na citação acima émanualtestando.
Para garantir a qualidadeautomatizadoé necessário testar.
Para mim, o teste manual é uma perda de tempo. Por outro lado, construir testes automatizados garante qualidade.
Aqui novamente a pergunta:
Como a equipe do Ubuntu garante que os bugs não apareçam novamente?
História desta questão
Primeiro o título era "Como a equipe do Ubuntu garante que os bugs não apareçam novamente?". Agora é "Como a equipe do Ubuntu faz testes automatizados?". Isso foi feito porque acredito que o teste manual não é uma solução. Por favor, não vote negativamente em respostas que apenas explicam como o teste manual é feito.
Responder1
O Ubuntu possui testes automatizados. Por exemplo, testes automatizados são usados para evitar que seu primeiro exemplo de bug aconteça novamente. Fui eu quem corrigiu o primeiro bug do vsftpd que você mencionou e, ao fazer isso, também adicionei um teste automatizado para evitar que a mesma coisa acontecesse novamente. Você pode ver isso na entrada do changelog que foi postada no próprio bug:
vsftpd (3.0.2-1ubuntu2.14.04.1) trusty; urgency=medium
* d/p/ubuntu-seccomp-gettimeofday.patch: permit gettimeofday() for logging
calls (LP: #1219857).
* Add dep8 smoke test.
-- Robie Basak <[email protected]> Tue, 29 Apr 2014 15:33:07 +0000
Não sei por que você considera o bug um exemplo de falta de testes automatizados, já que faço várias menções a isso no bug. Por exemplo, eu disse "teste dep8 adicionado para detectar isso no futuro" e "O teste dep8 incluído verifica automaticamente a correção deste bug" no resumo.
Lembre-se que o Ubuntu é uma distribuição: é uma agregação integrada de muitos projetos externos que chamamos de upstreams. O Ubuntu não seria possível sem o trabalho de outros no ecossistema mais amplo do Software Livre e, da mesma forma, dependemos frequentemente dos autores originais para fornecer testes, uma vez que são os especialistas em seu software.
Além disso, como somos uma agregação de projetos diferentes, uma única infraestrutura de testes automáticos não faz sentido. Áreas diferentes têm necessidades diferentes. Portanto, nossa estratégia de testes é bastante difundida para atender a essas necessidades, abrangendo testes manuais e automatizados por meio de diversas infraestruturas diferentes.
Onde os projetos upstream fornecem testes automatizados, nós os executamos como parte da construção do pacote. A construção do pacote falhará se os testes não forem aprovados. Garantir que qualquer teste automatizado disponível esteja habilitado desta forma faz parte do nossorequisitos para inclusão principal:Se o pacote enviar um conjunto de testes, e não houver nenhuma razão óbvia para que ele não possa funcionar durante a construção (por exemplo, ele precisa de privilégios de root ou acesso à rede), ele deverá ser executado durante a construção do pacote, e um conjunto de testes com falha deverá falhar na construção.
Além disso, executamos "testes automáticos de pacotes instalados" com base em uma especificação chamadadep8, que foi projetado para testar se a integração entre pacotes funciona corretamente. As atualizações de pacotes que regridem os testes dep8 não passam para a versão de desenvolvimento até serem corrigidas.
Estou menos familiarizado com os testes automatizados feitos pelas equipes de desktop e telefone, mas sei que existem mais mecanismos porque tenho visto referências a eles ao longo dos anos, e isso inclui testes automatizados de GUI, que considero bastante impressionantes. Congratulo-me com outra resposta que abrange testes automatizados de desktop e telefone.
Responder2
De várias maneiras.
Muitos olhos.
Ubuntu é Open Source, o que significa que qualquer pessoa pode olhar o código e ver qual é o problema. As pessoas interessadas em examinar o código muitas vezes encontrarão bugs nele ou à medida que o utilizam, ereportá-los no launchpadeo público pode até consertá-los.
Depois de testá-lo e sugerir a correção, você solicita uma fusão com o pacote principal do Ubuntu. Outros desenvolvedores analisam esta mudança e, se aprovada, irão adicioná-la.
Como qualquer pessoa pode consertá-los, eles são detectados rapidamente e revisados, é menos provável que fiquem por aí por um tempo. Isso leva ao próximo ponto.
Esses olhos também incluem olhos de computador:
O processo de controle de qualidade upstream deve ser documentado/demonstrado e vinculado ao bug de rastreamento do SRU. Em outros casos em que esse teste automático upstream não esteja disponível...
O que mostra que normalmente existem testes automáticos.
Lançamentos beta
Antes do Ubuntu ser lançado ao público, existem versões beta. Atualmente é o 15.10 Beta, a serlançado em 22 de outubro de 2015. Muitas e muitas pessoas estarão usando, revisando e corrigindo bugs antes de seu lançamento (por5 meses 22 diasnesse caso).
Isso significa que quaisquer bugs são removidos imediatamente (por causa dos Muitos Olhos) e os usuários típicos não são afetados porque são corrigidos antes de serem lançados oficialmente.
Escritores de código especializados
Pessoas que são boas em escrever código de alta qualidade são aquelas que escrevem o código. Não há apenas uma pessoa sentada escrevendo Ubuntu assim:
Existem pessoas de todo o mundo e funcionários da Canonical, a empresa por trás do Ubuntu. Todas essas pessoas contribuem com um pouco de código novo. Se eu escrever 2.000 linhas de código, haverá muitos bugs. Se 200 pessoas escreverem apenas 10, haverá muito menos.
Fundações estáveis
Pelo que eu sei, o Ubuntu não é reescrito desde o início cada vez que há um novo lançamento. Em vez disso, a próxima versão começa como a versão atual (ou seja, em 30/04/2015, tanto 15.10 quanto 15.04 eram iguais) e novos recursos são adicionados a partir daí.
Se você tiver uma boa base para trabalhar, terá menos código para escrever e poderá confiar no que já existe. Se você puder confiar no que está lá, menos bugs entrarão.
Software de versionamento e gravação
Se o mesmo bug aparecer mais de uma vez (em versões diferentes, ou a correção não funcionou, ou o bug voltou devido a outro patch), então eles têm a documentação para explicar como foi corrigido - e podem corrigi-lo novamente .
Pelo que sei, não existem testes automatizados. Mas o que é um teste automatizado? Se compilar, é esse? Você não pode simplesmente dizer “testes automatizados” sem explicar o que são
Responder3
Não escreva código com bugs. lol ok. Perdi a vontade de escrever uma resposta detalhada a isso. Aqui está um artigo decente: https://www.iiitd.edu.in/~jalote/papers/CommonBugs.pdf
e aqui está um bom livro sobre como fazererros em C++
A melhor resposta pode ser apenas realizar algumas tarefas de desenvolvimento de software e ver por si mesmo de onde vêm os problemas. Lidar com entradas/resultados inesperados é um grande problema na minha experiência. Depois, há bugs downstream. Como se alguém encontrasse uma vulnerabilidade em iostream.h e cada pedaço de software que chama essa biblioteca também pudesse ter esse bug, precisa pelo menos ser revisado.
quanto aos testes automatizados, eles existem, mas também têm limitações. Não conheço uma única solução que funcione em todos os idiomas. Se você estiver realmente interessado, escreva-nos um depurador de código genético com alguma IA. Pelo que eu sei, tudo ainda está em sua infância. Aqui estão alguns trabalhos de estudantes de doutorado: https://www.cs.cmu.edu/~clegoues/docs/legoues-icse09.pdf