Quando a unidade de teste vs teste manual
https://stackoverflow.com/questions/601438
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Enquanto teste de unidade parece eficaz para projetos maiores, onde as APIs precisam estar força industrial (por exemplo, o desenvolvimento das APIs do .NET Framework, etc.), ao que parece, possivelmente, como um exagero em projetos menores.
Quando é o TDD automatizado aproximar da melhor maneira, e quando ele pode ser melhor usar apenas técnicas de testes manuais, o log de erros, triagem, corrigi-los, etc.
Outra questão - quando eu era um testador da Microsoft, foi enfatizado para nós que havia um valor em ter os desenvolvedores e testadores ser pessoas diferentes, e que a tensão entre esses dois grupos podem ajudar a criar um grande produto em o fim. Pode TDD quebrar essa idéia e criar uma situação onde um desenvolvedor pode não ser a pessoa certa para encontrar rigorosamente seus próprios erros? Pode ser automatizado, mas parece que há muitas maneiras de escrever os testes, e que é questionável se um determinado conjunto de testes vai "provar" que a qualidade é aceitável.
Solução
A eficácia do TDD é independente do tamanho do projeto. Vou praticar as três leis da TDD mesmo no exercício de programação menor. Os testes não levam muito tempo para escrever, e eles economizar uma enorme quantidade de tempo de depuração. Eles também me permita refatorar o código sem medo de quebrar alguma coisa.
TDD é uma disciplina semelhante à disciplina de dual-entrada-de escrituração praticadas pelos contadores. Ele evita erros in-the-pequena. Contadores entrará cada transação duas vezes; uma vez como um crédito, e uma vez como um débito. Se nenhum erro simples foram feitas, em seguida, o balanço vai somar zero. Que zero é um cheque local simples que impede que os executivos de ir para a cadeia.
Pelos mesmos programadores simbólicos escrever testes de unidade antes de seu código como uma verificação no local simples. Com efeito, eles escrevem cada bit de código duas vezes; uma vez como um teste, e uma vez como código de produção. Se os testes passam, os dois pedaços de código estão de acordo. Nem prática protege contra erros maiores e mais complexas, mas ambas as práticas são, todavia, valiosos.
A prática de TDD não é realmente uma técnica de teste, é uma prática de desenvolvimento. O "teste" palavra em TDD é mais ou menos uma coincidência. Como tal, TDD não é um substituto para boas práticas de teste, e bons testadores QA. Na verdade, é uma idéia muito boa para ter testadores experientes escrever planos de teste de controle de qualidade de forma independente (e, muitas vezes antes de) os programadores escrever o código (e seus testes de unidade).
É a minha preferência (na verdade minha paixão) que estes testes de controle de qualidade independentes também são automatizados usando uma ferramenta como FitNesse , selênio , ou Watir . Os testes devem ser de fácil leitura por pessoas de negócios, de fácil execução, e absolutamente inequívoca. Você deve ser capaz de executá-las em qualquer momento, geralmente muitas vezes por dia.
Cada sistema também precisa ser testado manualmente. No entanto, o teste manual nunca deve ser rote. Um teste que pode ser programado deve ser automatizado. Você só quer colocar seres humanos no loop quando o julgamento humano é necessário. Portanto os seres humanos devem estar fazendo exploratória testes , não seguir cegamente os planos de teste.
Assim, a resposta curta para a questão de quando a unidade-teste contra o teste manual é que não há "versus". Você deve escrever testes de unidade automatizados início para a grande maioria do código que você escreve. Você deveria ter automatizado testes de aceitação do QA escritos por testadores. E você também deve praticar o teste manual exploratória estratégico.
Outras dicas
Os testes de unidade não são destinadas a substituir os ensaios funcionais / componentes. Testes de unidade são realmente focado, para que eles não serão base de dados bater, serviços externos, etc. testes de integração faz isso, mas você pode tê-los realmente focado. A linha de fundo, é que na questão específica, a resposta é que eles não substituir os testes manuais. Agora, automatizado testes funcionais + testes de componentes automatizados certamente pode substituir testes manuais. Vai depender muito do projeto e da abordagem a ele em quem vai realmente fazer aqueles.
Update 1: Note-se que se os desenvolvedores estão criando automatizado testes funcionais você ainda quer revisão que aqueles têm a cobertura adequada, complementando-os conforme apropriado. Alguns desenvolvedores a criar automatizado testes funcionais, com sua estrutura de teste "unidade", porque eles ainda têm de fazer testes de fumo, independentemente dos testes de unidade, e isso realmente ajuda a ter aqueles automatizado :)
Update 2: O teste de unidade não é um exagero para um projeto pequeno, nem é automatizar os testes de fumo ou usando TDD. O que é um exagero é ter a equipe fazer nada disso para a sua primeira vez no projeto pequeno. Fazer qualquer um desses têm uma curva de aprendizagem associada (especialmente o teste de unidade ou TDD), e nem sempre vai ser feito para a direita em primeiro lugar. Você também quer alguém que tem vindo a fazer isso por um tempo envolvido, para ajudar a evitar armadilhas e obter passados ??alguns desafios de codificação que não são óbvias quando se inicia nele. A questão é que não é comum para que as equipes têm essas habilidades.
TDD é a melhor abordagem sempre que for viável fazê-lo. testes de TDD é, cobertura de código através automática quantificável e método confiável de garantir a qualidade do código.
Os testes manuais exige uma enorme quantidade de tempo (em comparação com TDD) e sofre de erro humano.
Não há nada dizendo que TDD significa único teste desenvolvedores. Desenvolvedores deve ser responsável por codificar uma porcentagem do quadro de teste. QA deve ser responsável por uma parcela muito maior. APIs de teste Programadores da maneira que querem para testá-los. QA testa APIs de maneiras que eu realmente nunca teria pensado para e fazer coisas que, embora aparentemente louco, são realmente feitas pelos clientes.
Eu diria que a Unidade-testes são uma ajuda os programadores a responder à pergunta:
Será que este código faz o que eu acho que faz?
Esta é uma pergunta que eles precisam se perguntar muito. Programers como a qualquer coisa automatizar eles fazem um monte onde podem.
A equipe de teste separada precisa responder a uma pergunta diferente: -
Este sistema faz o que eu (e os usuários finais) esperar que façam? Ou não me surpreender?
Há toda uma classe enorme de bugs relacionados com o programador ou designers que têm uma ideia diferente sobre o que é correto que os testes de unidade nunca será recolhida.
De acordo com os estudos de vários projectos (1), Os testes unitários encontrar
Um teste que é automatizado executado com mais freqüência, assim ele vai encontrar defeitos mais cedo e reduzir o custo total destes imensamente - que é o verdadeiro valor da automação de teste.
investir seu Ressources sabiamente e escolher os frutos mais baixos primeiro.
Acho que testes automatizados são mais fáceis de escrever e manter para pequenas unidades de código - funções isolado e classes. funcionalidade do usuário final é mais fácil testado manualmente - e um bom testador vai encontrar muitas esquisitices além dos testes necessários. Não configurá-los uns contra os outros, você precisa de ambos.
Dev vs. Testers Desenvolvedores são notoriamente ruim em testar seu próprio código: razões são de natureza psicológica, técnica e última não menos econômica - testadores são geralmente mais baratos do que os desenvolvedores. Mas os desenvolvedores podem fazer a sua parte, e fazer o teste mais fácil. TDD faz testando uma parte intrínseca da construção do programa, e não apenas uma reflexão tardia, que é o verdadeiro valor de TDD.
Outro ponto interessante sobre o teste: Não há nenhum ponto em uma cobertura de 100%. Estatisticamente, erros seguem uma regra 80:20 - a maioria dos erros é encontrada em pequenas seções de código. Alguns estudos sugerem que este é ainda mais acentuada - e os testes devem incidem sobre os lugares onde os erros aparecem.
(1) Programação Produtividade Jones 1986 u.a., citado de código completo, 2º. ed. Mas, como já foi dito, unidade testes são apenas uma parte de testes, integração, regressão e testes do sistema pode ser - no menos parcialmente -. Automatizado bem
A minha interpretação dos resultados: "muitos olhos" tem a melhor detecção de defeitos, mas somente se você tem algum processo formal que os torna realmente olhar
.Os testes de unidade só pode ir tão longe (como pode todos os outros tipos de testes). Eu olho em testes como uma espécie de processo de "peneira". Cada tipo diferente de teste é como uma peneira que você está colocando por baixo da saída de seu processo de desenvolvimento. O material que sai é (espero) apresenta na sua maioria para o seu produto de software, mas também contém bugs. Os bichos vêm em lotes de diferentes formas e tamanhos.
Alguns dos erros são bastante fáceis de encontrar, porque eles são grandes ou pego em basicamente qualquer tipo de peneira. Por outro lado, alguns erros são lisa e brilhante, ou não tem um monte de ganchos nas laterais para que pudessem escapar por um tipo de peneira com bastante facilidade. Um tipo diferente de crivo pode ter diferentes orifícios de forma ou tamanho por isso será capaz de capturar diferentes tipos de erros. Quanto mais peneiras que você tem, mais bugs que você vai pegar.
Obviamente, quanto mais peneiras que você tem no caminho, mais lento ele é para as características de obter através de, bem, então você vai querer tentar encontrar um meio termo onde você não está gastando muito tempo testando que você nunca chegar a liberar qualquer software.
O ponto mais bonitas (IMO) de testes de unidade automatizados é que quando você mudar (melhorar, refactor) o código existente, é fácil de teste que você não quebrá-lo. Seria tedioso para teste de tudo manualmente novamente e novamente.
Cada é testado.
Algumas aplicações fazer o teste na forma de faz minha compilação de código e não o código parecem Função .
Algumas aplicações fazer o teste com Testes de unidade . Alguns desenvolvedores são religiosos sobre testes unitários, TDD e cobertura de código para uma falha. Como tudo, muito mais frequentemente do que não é mau.
Algumas aplicações são felizmente o suficiente para fazer o teste através de um QA equipe. Algumas equipes de QA automatizar seus testes, outros escrevem casos de teste e teste manualmente.
Michael Feathers, que escreveu: trabalhar efetivamente com Legacy Code , escreveu que o código não envolto em testes é código legado. Até que você tenha experimentado a Big Ball of Mud , eu não acho que qualquer desenvolvedor realmente entende o benefício de boa Application Architecture e um conjunto de testes de unidade bem escritos.
Tendo teste de diferentes pessoas é uma ótima idéia. Quanto mais as pessoas que podem olhar para uma aplicação o mais provável que todos os cenários vai ficar coberto, incluindo os que você não tinha a intenção de acontecer.
TDD tem obtido um mau rap ultimamente. Quando penso em TDD Penso desenvolvedores dogmáticas meticulosamente escrever testes antes de escrever a implementação. Embora isto seja verdade, o que tem sido negligenciado é escrevendo os testes, (primeira ou logo após) o desenvolvedor experimenta o método / classe na pele do consumidor. falhas de projeto e deficiências são imediatamente aparentes.
Eu argumentam que o tamanho do projeto é irrelevante. O que é importante é o tempo de vida do projeto. Quanto mais tempo um projeto vive mais a probabilidade de que um desenvolvedor diferente daquele que escreveu ele vai trabalhar sobre ela. Os testes unitários são documentação às expectativas do aplicativo -. Um manual de tipos
A sua questão parece ser mais sobre automatizado testando vs teste manual. O teste de unidade é uma forma de testes automatizados, mas uma forma muito específica.
O seu comentário sobre ter testadores e desenvolvedores independentes é direito sobre a marca embora. Mas isso não os desenvolvedores médios não deve fazer algum tipo de verificação.
O teste de unidade é uma maneira para os desenvolvedores obter um feedback rápido sobre o que eles estão fazendo. Eles escrever testes para pequenas unidades executar rapidamente de código e verificar sua exatidão. Não é realmente testar no sentido de que você parece usar a palavra testar apenas como uma verificação de sintaxe por um compilador não está testando. O teste de unidade é uma técnica de desenvolvimento. Código que foi escrito usando esta técnica é provavelmente de maior qualidade do que o código escrito sem, mas ainda tem que passar por controle de qualidade.
A pergunta sobre o teste automatizado vs teste manual para o departamento de teste é mais fácil de responder. Sempre que o projeto se torna grande o suficiente para justificar o investimento de escrever testes automatizados que você deve usar testes automatizados. Quando você tem um monte de testes em tempo um pequeno você deve fazê-las manualmente.
Tendo sido em ambos os lados, QA e desenvolvimento, gostaria de afirmar que alguém deve testar sempre manualmente seu código. Mesmo se você estiver usando TDD, há uma abundância de coisas que você como um desenvolvedor pode não ser capaz de cobrir com testes de unidade, ou não pode pensar sobre o teste. Este especialmente inclui usabilidade e estética. Estética inclui grafia correta, gramática e formatação de saída.
exemplo da vida real 1:
Um desenvolvedor estava criando um relatório apresentamos em nossa intranet para os gestores. Havia muitas fórmulas, todos os quais o desenvolvedor testados antes do código veio a QA. Verificou-se que as fórmulas foram, na verdade, produzindo a saída correta. O que pedimos desenvolvimento para corrigir, quase imediatamente, foi o fato de que os números eram exibidos no rosa em um fundo roxo.
exemplo da vida real 2:
I escrever código no meu tempo livre, usando TDD. Eu gosto de pensar que eu testá-lo completamente. Um dia minha esposa passou por quando eu tinha uma mensagem de diálogo-se, lê-lo, e prontamente perguntou: "O que na Terra é que a mensagem quer dizer com isso?" Eu pensei que a mensagem era bastante clara, mas quando eu reli eu percebi que estava falando de pai e filho nós em um controle de árvore, e provavelmente não faria sentido para o usuário médio. I reformulado a mensagem. Neste caso, era uma questão de usabilidade, o que não foi pego pelo meu próprio teste.
teste de unidade parece eficaz para projetos maiores, onde as APIs precisam estar força industrial, ao que parece, possivelmente, como um exagero em projetos menores.
É verdade que os testes unitários de uma API em movimento são frágeis, mas teste de unidade também é eficaz em projetos de API-less tais como aplicações. Unit-teste serve para testar as unidades de um projeto é feito com. Ele permite assegurar a cada trabalhos de unidade como esperado. Esta é uma verdadeira rede de segurança quando se modifica - refatoração -. O código
Quanto ao tamanho do projeto está em causa, é verdade que a escrita unidade-testes para um projeto pequeno pode ser um exagero. E aqui, eu definiria projeto pequeno como um pequeno programa, que pode ser testado manualmente, mas muito facilmente e rapidamente, em não mais do que alguns segundos. Também um pequeno projeto pode crescer, caso em que pode ser vantajoso ter testes de unidade à mão.
havia um valor em ter os desenvolvedores e testadores ser pessoas diferentes, e que a tensão entre esses dois grupos podem ajudar a criar um grande produto no final.
Seja qual for o processo de desenvolvimento, teste de unidade não se destina a substituir quaisquer outras etapas do teste, mas para complementá-los com testes no nível de desenvolvimento, de modo que os desenvolvedores podem obter feedback muito cedo, sem ter que esperar por uma compilação oficial e teste oficial. Com a unidade de testes, a equipe de desenvolvimento fornece código que funciona, não o código livre de bugs a jusante, mas o código que pode ser testado pela equipe de teste (s).
Para resumir, eu testar manualmente quando é realmente muito fácil, ou ao escrever testes de unidade é muito complexo, e eu não visam a cobertura de 100%.
Eu acredito que é possível combinar a expertise de QA / teste pessoal (definindo os testes / critérios de aceitação), com o conceito TDD de usar um desenvolvedor de propriedade API (como se opor a GUI ou HTTP / mensagens interface) para conduzir um aplicação sob teste.
É ainda fundamental ter funcionários QA independente, mas nós não precisamos de mais enormes equipes de teste manuais com ferramentas de teste modernos como FitNesse, Selênio e Twist.
Só para esclarecer algo que muitas pessoas parecem perder:
TDD, no sentido de "teste de falha de gravação, o código de escrita a passagem make teste, refatorar, repita" É geralmente mais eficiente e útil quando você escrever unidade testes.
Você escreve um teste de unidade em torno de apenas a classe / função / unidade de código que você está trabalhando, usando simulações ou topos de abstrair o resto do sistema.
"Automated" testar geralmente se refere à aceitação / testes mais elevados de integração nível / funcionais - você pode fazer TDD em torno deste nível de teste, e é muitas vezes a única opção para o código fortemente ui-driven, mas você deve estar ciente de que este tipo de teste é mais frágil, mais difícil escrever teste anterior, e nenhum substituto para o teste de unidade.
TDD me dá, como o desenvolvedor, a confiança de que a mudança que eu estou fazendo para o código tem as conseqüências intencionais e só as consequências pretendidas, e, assim, a metáfora de TDD como uma "rede de segurança" é útil; alterar qualquer código em um sistema sem ele e você pode ter nenhuma idéia o que mais você pode ter quebrado.
tensão Engenharia entre desenvolvedores e testadores é realmente uma má notícia; desenvolvedores cultivar um "bem, os testadores são pagos para encontrar os bugs" mentalidade (levando a preguiça) e os testadores - sensação como se eles não estão sendo vistos para fazer seus trabalhos se não encontrar quaisquer falhas - lance -se tantos problemas triviais como podem. Este é um desperdício bruta de tempo de todos.
A melhor desenvolvimento de software, na minha humilde experiência, é onde o testador também é um desenvolvedor e os testes de unidade e código são escritos juntos como parte de um exercício par de programação. Isso coloca imediatamente as duas pessoas do mesmo lado do problema, trabalhando em conjunto para o mesmo objectivo, ao invés de colocá-los em oposição um ao outro.
O teste de unidade não é o mesmo que o teste funcional. E, tanto quanto a automação está em causa, normalmente deve ser considerada quando o ciclo de teste será repetido mais de 2 ou 3 vezes ... é preferível para testes de regressão. Se o projeto for pequeno ou ele não terá alterações ou atualizações frequentes, em seguida, o teste manual é um melhor e menos rentável opção. Em tais casos, a automação irá revelar-se mais caro com a escrita de argumentos e maintainence.
