Como a equipe do Ubuntu faz testes automatizados?

Question

Como a equipe do Ubuntu garante que os erros não aparecerão novamente?

Eu já vi várias vezes. Um pacote é inutilizável após a instalação.

Sim, às vezes os erros são corrigidos muito rapidamente.

Mas não vejo esforço para melhorar o teste automatizado, para que o bug não apareça novamente.

Aqui estão dois exemplos que me afetaram durante as duas últimas semanas:

• link
• link

Existem mais exemplos, mas listá-los não faz parte da pergunta.

Um comentário da página de erros vsftp :

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

OK, mas "teste" na citação acima é o teste manual .

Para garantir que testes automatizados de qualidade sejam necessários.

Para mim, o teste manual é uma perda de tempo. Por outro lado, a criação de testes automatizados garante qualidade.

Aqui novamente a pergunta:

Como a equipe do Ubuntu garante que os erros não apareçam novamente?

História desta questão

Primeiro, o título era "Como a equipe do Ubuntu garante que os erros 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 baixe as respostas que explicam apenas a forma como o teste manual é feito.

    

Answer 1

O Ubuntu tem testes automatizados. Por exemplo, o teste automatizado é usado para impedir que seu primeiro exemplo de bug ocorra novamente. Fui eu quem consertou 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

Eu não sei porque 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 para esse bug" no resumo.

Lembre-se que o Ubuntu é uma distribuição: é uma integração integrada de muitos projetos externos que chamamos de upstreams. O Ubuntu não seria possível sem o trabalho de outros no ecossistema do Software Livre, e também dependemos dos autores do upstream para fornecer testes, já que são especialistas em seu software.

Além disso, como somos uma agregação de projetos diferentes, uma única infraestrutura de teste automático não faz sentido. Áreas diferentes têm necessidades diferentes. Portanto, nossa estratégia de testes é bastante difundida para atender a essas necessidades, cobrindo testes manuais e automatizados por meio de várias infraestruturas diferentes.

Onde projetos upstream fornecem testes automatizados, os executamos como parte da compilação do pacote. A compilação do pacote falhará se os testes não forem aprovados. Certificar-se de que qualquer teste automatizado disponível esteja ativado dessa maneira faz parte de nossos requisitos para a inclusão principal : Se o pacote for enviado um conjunto de testes, e não há razão óbvia para que ele não funcione durante a compilação (por exemplo, ele precisa de privilégios de root ou de acesso à rede), ele deve ser executado durante a compilação do pacote e um conjunto de testes com falha deve falhar.

Além disso, executamos "testes de pacotes automáticos como instalados" com base em uma especificação chamada dep8 , projetada para testando que a integração entre pacotes funciona corretamente. As atualizações de pacotes que retornam 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 vi referências a eles ao longo dos anos, e isso inclui testes automatizados de GUI, o que acho bastante impressionante. Congratulo-me com outra resposta que abrange testes automatizados de desktop e telefone.

    

Answer 2

Várias maneiras.

1. Muitos olhos.

   O Ubuntu é Open Source, o que significa que qualquer pessoa pode ver o código e ver qual é o problema. As pessoas que estão interessadas em olhar para o código geralmente encontrarão bugs nele ou enquanto o usam, e os reportará na barra de lançamento e o público pode até corrigi-los .

   

   Quandovocêtivertestadoesugeridoacorreção,soliciteumamesclagemcomopacoteprincipaldoUbuntu.Outrosdesenvolvedoresrevisamessaalteraçãoe,seaprovado,aadicionará.

   Comoqualquerumpodeconsertá-los,elessãovistosrapidamente,eelessãorevisados,elessãomenospropensosaficarporaquiporumtempo.Issolevaaopróximoponto.

   Essesolhostambémincluemolhosdecomputador:

   TheupstreamQAprocessmustbedocumented/demonstratedandlinkedfromtheSRUtrackingbug.Inothercaseswheresuchupstreamautomatictestingisnotavailable...

   Oquemostraquenormalmenteotesteautomáticoestáemvigor.

2. VersõesBeta

   AntesdeoUbuntuserlançadoaopúblico,existemversõesbeta.Atualmenteéo15.10Beta,paraser lançado em 22 de outubro de 2015 . Muitas, e muitas pessoas terão usado, revisando e corrigindo bugs antes de serem lançadas (para 5 meses 22 dias neste caso).

   Isso significa que todos os bugs são removidos imediatamente (por causa do Many Eyes), e os usuários comuns não são afetados porque são corrigidos antes de serem lançados oficialmente.

3. Escritores de códigos especialistas

   Pessoas que são boas em escrever códigos de alta qualidade são as pessoas que estão escrevendo o código. Não há apenas uma pessoa sentada escrevendo o Ubuntu assim:

   

   ExistempessoasdetodoomundoepessoasempregadaspelaCanonical,aempresaportrásdoUbuntu.Todasessaspessoascontribuemcomumpoucodenovocódigo.Seeuescrever2000linhasdecódigo,haverámuitosbugs.Se200pessoasescreveremapenas10,haverámuitomenos.

4. Fundaçõesestáveis

   Tantoquantoeusei,oUbuntunãoéreescritoapartirdozerocadavezqueháumanovaversão.Emvezdisso,apróximaversãocomeçacomoaversãoatual(ouseja,em2015/04/30ambos15.10e15.04foramosmesmos)enovosrecursossãoadicionadosapartirdaí.

   Sevocêtemumaboabaseparatrabalhar,entãovocêtemmenoscódigoparaescreverepodeconfiarnoquejáexiste.Sevocêpodeconfiarnoqueestálá,menosbugsentrarão.

5. Softwaredeversionamentoegravação

   Seomesmobugaparecermaisdeumavez(emversõesdiferentes,ouacorreçãonãofuncionou,ouobugvoltoudevidoaoutropatch),entãoelestêmadocumentaçãoparaexplicarcomoelafoicorrigida-eelespodemconsertá-lonovamente.

Tantoquantoeupossodizer,nãohátestesautomatizados.Masoqueéumtesteautomatizado?Secompila,éesse?Vocênãopodesimplesmentedizer"testes automatizados" sem explicar o que é

    

Answer 3

Não escreva código com erros. lol ok. Perdi a vontade de escrever uma resposta detalhada a isso. Aqui está um artigo decente: link

e aqui está um bom livro sobre como fazer erros 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á erros de transmissão. Como se alguém encontrasse uma vulnerabilidade no iostream.h e cada pedaço de software que chama essa biblioteca, então, também poderia ter esse bug, pelo menos para ser revisto.

quanto ao teste automatizado, ele existe, mas também tem limitações. Não tenho conhecimento de 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. Tanto quanto eu sei, tudo isso ainda está em sua infância, Heres algum trabalho de estudantes de doutorado: link