Introdução ao Teste de Software (Ammann & Offutt) menciona na p.32 um modelo de maturidade de teste de 5 níveis:

Nível 0 Não há diferença entre teste e depuração.

Nível 1 O objetivo do teste é mostrar que o software funciona.

Nível 2 O objetivo do teste é mostrar que o software não funciona.

Nível 3 O objetivo do teste não é provar nada específico, mas reduzir o risco de uso do software.

O teste de nível 4 é uma disciplina mental que ajuda todos os profissionais de TI a desenvolver software de qualidade superior.

Embora eles não entrem em muito mais detalhes. Quais são as diferenças entre depuração e teste?

O teste destina-se a encontrar defeitos no código, ou de um ângulo diferente, para provar a um nível adequado (nunca pode ser 100%) que o programa faz o que deve fazer. Pode ser manual ou automatizado e possui muitos tipos diferentes, como testes de unidade, integração, sistema / aceitação, estresse, carga, imersão etc.

Depuração é o processo de encontrar e remover um bug específico do programa. É sempre um processo único e manual, pois todos os bugs são diferentes.

Meu palpite é que o autor quer dizer que, no nível 0, apenas testes manuais são executados, de maneira ad hoc, sem um plano de teste ou qualquer coisa para garantir que o testador realmente teste exaustivamente o recurso em teste e que os testes possam ser executados. repetido de forma confiável.

A depuração é um processo manual passo a passo envolvido, não estruturado e não confiável. Ao testar através da depuração, você cria cenários que não são repetíveis, portanto, inúteis para o teste de regressão. Todos os níveis diferentes de 0 (no seu exemplo) excluem a depuração na minha opinião por esse motivo exato.

A depuração é uma tentativa de corrigir problemas conhecidos e desconhecidos, revisando metodicamente o código. Quando você está depurando, geralmente não está focado no código como um todo e quase sempre trabalha no back-end, no código real.

O teste é uma tentativa de criar um problema através de várias maneiras de usar o código que pode ser depurado. É quase sempre feito no espaço do usuário, onde você executa o código como um usuário final e tenta quebrá-lo.

Em termos simples, é dito que um "bug" ocorreu quando o seu programa, em execução, não se comporta da maneira que deveria. Ou seja, não produz a saída ou os resultados esperados. Qualquer tentativa de encontrar a fonte desse bug, encontrar maneiras de corrigir o comportamento e fazer alterações no código ou na configuração para corrigir o problema pode ser denominada depuração.

O teste é onde você garante que o programa ou código funcione corretamente e de maneira robusta sob diferentes condições: Você "testa" seu código fornecendo entradas, entradas corretas padrão, entradas intencionalmente erradas, valores de limite, mudança de ambiente (SO, arquivo de configuração) . Basicamente, podemos dizer que você tenta descobrir bugs e eventualmente "depurá-los" no processo de teste. Espero que ajude.

Não há nenhum. Se você fizer certo:

Bata neles alto, bata neles baixo :

Teste de regressão e o aperto do Saff

Kent Beck, Instituto dos Três Rios

Resumo: Para isolar efetivamente um defeito, comece com um teste no nível do sistema e progressivamente alinhado e podado até que você tenha o menor teste possível que demonstre o defeito.

O teste é um privilégio que você desfruta antes de liberar para o cliente.

Bugs são um pesadelo que você suporta depois de liberar para o cliente.

Outros mencionaram quais são as diferenças entre teste e depuração.

Eu gostaria de enfatizar uma parte comum . Quando um testador encontra um defeito, ele deve ser isolado. A depuração é uma das técnicas para isolar o problema e encontrar as causas principais, analisando o estado do aplicativo e seu código em tempo de execução. De fato, a depuração é definida pelos Dicionários Oxford como "o processo de identificação e remoção de erros do hardware ou software do computador".

Quem isolará (ou depurará em particular) um defeito, seja um testador ou um desenvolvedor, é uma questão secundária.

O modelo de maturidade de teste que você listou é uma descrição da mentalidade da equipe de desenvolvimento.

O que a lista implica, sem dizer explicitamente, é como a mudança de mentalidade afeta a maneira como os testes são realizados.

À medida que a equipe de desenvolvimento avança para o próximo nível, o escopo dos testes é ampliado.

No nível 0, nenhum teste é feito, porque a equipe acha que não é necessário.

No nível 1, o teste é realizado para fornecer uma cobertura nominal das funcionalidades básicas.

No Nível 2, o teste é ampliado para incluir tudo no Nível 1 e adiciona testes destrutivos (uma equipe de teste dedicada que tem acesso a todas as informações às quais os desenvolvedores têm acesso, incluindo código fonte e binários, e tenta encontrar bugs que podem ser acionado a partir de uma função de usuário)

No nível 3, além de tudo nos níveis 1-2, são adicionados testes não funcionais / testes não corretos (como características de desempenho).

No nível 4, os objetivos do teste de software são bem compreendidos por todas as pessoas, incluindo a equipe de TI voltada para o cliente. Assim, a equipe de TI poderá fornecer feedback sobre quais cenários testar, melhorando a cobertura de risco do Nível 4.

(Isenção de responsabilidade: não tenho acesso ao livro, portanto, minha terminologia pode estar incorreta.)

Bugs são erros visíveis. Depuração é o processo iniciado após o design do caso de teste. É uma tarefa mais difícil do que testar, porque no processo de depuração, precisamos descobrir a fonte do erro e removê-lo; portanto, às vezes, a depuração frustra o usuário.

Falando em termos práticos todos os dias, acho que depende totalmente do contexto .

Em uma equipe de médio porte, trabalhando com padrões altos / muito altos (pense em sistemas bancários, militares, de grande escala, de alto orçamento ou críticos para negócios), acho que claramente "depuração" deve ser "resultado de teste" , e eles são claramente coisas muito diferentes . O teste ideal leva à depuração (em um ambiente de preparação) e na produção precisamos de quase zero de qualquer um.

O teste é amplo, regular e muito formalizado - enquanto a depuração é um processo específico que ocorre ocasionalmente quando há necessidade de corrigir uma falha específica - o que não é óbvio e requer uma investigação mais profunda do funcionamento de um sistema e dos resultados resultantes.

Aqui, na minha mente, testar é algo essencial, enquanto a depuração é uma ferramenta específica necessária apenas quando a resolução de uma falha é opaca.

Entendo perfeitamente a utilidade óbvia no TDD para grandes equipes e / ou sistemas que simplesmente não podem se dar ao luxo de ser "buggy". Também claramente faz muito sentido para sistemas complexos (geralmente "back-end") ou se existe uma alta proporção de complexidade no código em comparação com a saída. Então o "teste" tem uma chance realista de informar quando e por que ocorrem falhas. Os sistemas que executam muito trabalho complexo e ou resultam em saídas claramente mensuráveis ​​geralmente são prontamente testáveis ​​e, portanto, o teste é distinto da depuração. Nesses casos, o teste implica fortemente um método formal e baseado em procedimento para confirmar ou não confirmar a correspondência entre expectativas e resultados reais. Os testes acontecem o tempo todo e ocasionalmente nos informa sobre a necessidade de depuração.

Seria adorável se essa fosse uma verdade onipresente, eu adoraria se meus ciclos de desenvolvimento fossem delimitados por uma saída binária claramente definida (vermelho, verde), mas ...

No meu caso (o que é reconhecidamente particular - trabalhar 98% sozinho em sistemas administrativos corporativos focados em dados, baseados na Web, de pequeno e médio porte, com recursos insuficientes), eu realmente não consigo ver como o TDD poderia me ajudar. Ou melhor, "depuração" e "teste" são praticamente os mesmos.

Principalmente, embora o uso do termo "teste" implique / esteja intimamente relacionado à metodologia do TDD.

Eu sei que isso é uma coisa totalmente, totalmente não-Zeitgeist, "evite os que não acreditam, evite, evite", algo desprezivelmente não-legal de se dizer. Mas, pensando no meu contexto, com um chapéu prático, eu nem sequer vagamente, na minha imaginação mais selvagem, vejo como o TDD poderia me ajudar a oferecer mais valor ao dinheiro para meus clientes.

Ou melhor, discordo totalmente da suposição comum de que "teste" é um processo formal baseado em código.

Minha objeção básica (aplicável no meu * contexto * particular ) é que ...

Se não consigo escrever um código que funcione de maneira confiável - então como diabos devo escrever um código que funcione de maneira confiável para testar o referido código presumivelmente sub-padrão?

Para mim, eu nunca vi nenhum exemplo nem argumento de que (no meu contexto particular) me entusiasmou o suficiente para sequer se preocupar pensando sobre escrever um único teste , eu poderia ser a escrever algum código de teste laughably insubstancial agora, talvez "o meu retorno repositório de um usuário entidade com Nome == X, quando eu solicito exatamente - e apenas - isso? ", mas provavelmente há mais utilidade em escrever esse streaming, talvez a Internet seja realmente apenas pura boba. um lixo auto-gratificante, descontroladamente desinformado, ferozmente imbecil e esbanjador, mas apenas sinto a necessidade de bancar o advogado do diabo aqui. (Esperando que alguém me mostre a luz e me converta, talvez isso acabe dando aos meus clientes uma melhor relação custo-benefício?).

Indiscutivelmente, "depuração" às vezes é o mesmo que "teste". Com isso, quero dizer realmente que, na minha vida profissional diária, passo pelo menos um terço do meu tempo brincando com a versão local do meu sistema em diferentes navegadores, tentando desesperadamente várias coisas malucas na tentativa de interromper meu trabalho e depois investigar as razões pelas quais falhou e corrigi-las.

Eu concordo 100% com a utilidade óbvia no mantra TDD "vermelho / verde / refator", mas para mim (trabalhando com orçamento mediano, solo RIA solo) eu realmente adoraria que alguém me mostrasse como poderia possivelmente , de maneira lógica e vital, obtenha realisticamente qualquer valor adicional ao escrever mais ( apenas como código de teste potencialmente defeituoso ) do que na interação com o resultado total (e essencialmente apenas) de meus esforços, que estão essencialmente vinculados à interação humana real.

Para mim, quando os desenvolvedores falam sobre "teste", geralmente implica TDD.

Eu tento codificar como se houvesse testes, acho que todos os padrões / práticas e tendências que todo esse desenvolvimento focado em testes incentivou são fantásticos e bonitos, mas para mim, no meu pequeno mundo, "testar" não está escrevendo mais código, é realmente testar o mundo real o produz de maneira realista, e isso é praticamente o mesmo que depuração, ou melhor, a mudança ativa aqui é a "depuração", que é um resultado direto do "teste" não automatizado, humano e centrado na produção. Isso contrasta com a visão geralmente aceita de "teste" como algo automatizado e formal e "depuração" como algo humano e ad-hoc ou não-estruturado.

Se o objetivo é realmente valioso em relação ao custo / esforço, e você está criando aplicativos interativos baseados na Web, o resultado do esforço são as páginas da Web e, essencialmente, como elas reagem à contribuição humana - para que "testar" seja melhor alcançado através do teste essas páginas da web, através de interação humana real. Quando essa interação leva a resultados inesperados ou indesejáveis, ocorre a "depuração". A depuração também está intimamente relacionada à idéia de inspeção em tempo real do estado do programa. O teste geralmente está associado à automação, o que eu acho que costuma ser uma associação infeliz.

Se o objetivo é realmente valioso para o esforço, e o teste automatizado é eficiente e altamente benéfico, enquanto a depuração é apenas uma saída desse teste ou um substituto ruim para o teste automatizado, por que o segundo site mais visitado do mundo (Facebook) ) tantas vezes repleta de erros cegamente óbvios (para os usuários, mas claramente não para a equipe e o código de teste)?

Talvez seja porque eles estão se concentrando nas luzes verdes tranquilizadoras e esquecendo de realmente usar os resultados de seu trabalho?

Muitos desenvolvedores acham que o teste é algo que você faz com código e a depuração é algo que você faz ocasionalmente com o IDE porque um ícone fica vermelho e você não sabe por que? Penso que estas palavras têm julgamentos de valor infelizes associados a elas, que geralmente obscurecem a realidade prática em que devemos nos concentrar para fechar as lacunas entre expectativas e resultados.

Simplesmente,

Testar significa encontrar as entradas que causam falha de um software durante a depuração é o processo de encontrar a falha de uma determinada falha.