Good Mood

Explore the Differences between Smoke Testing and Sanity Testing in detail with examples:

In this tutorial, we will learn what is Sanity Testing and Smoke Testing in Software Testing. Também aprenderemos as principais diferenças entre o teste de sanidade e o teste de fumaça com exemplos simples.

na maioria das vezes ficamos confusos entre o Significado de teste de sanidade e teste de Fumaça. Em primeiro lugar, estes dois ensaios são muito “diferentes” e são realizados durante diferentes fases de um ciclo de ensaio.,

Sanity Testing

Sanity Testing is done when as a QA we do not have sufficient time to run all the test cases, be it Functional Testing, UI, OS or Browser Testing.

Portanto, eu definiria,

“Teste de sanidade como uma execução de teste que é feito para tocar cada implementação e seu impacto, mas não completamente ou em profundidade, ele pode incluir funcional, UI, versão, etc. testes dependendo da implementação e seu impacto.”

não estamos todos em uma situação em que temos que assinar em um ou dois dias, mas a compilação para testes ainda não foi lançada?,Sim, eu aposto que você também deve ter enfrentado esta situação pelo menos uma vez em sua experiência de teste de Software. Bem, eu enfrentei muito porque meu(S) projeto (s) eram principalmente ágeis e às vezes nos pediram para entregá-lo no mesmo dia. Oops, como eu poderia testar e liberar a construção em um trecho de horas?

I used to go nuts at times because even if it was a small functionality, the implication could be tremendous. E como uma cereja no topo do bolo, os clientes às vezes simplesmente se recusam a dar tempo extra., Como poderia completar todo o teste em poucas horas, verificar todas as funcionalidades, Bugs e liberá-lo?

a resposta para todos esses problemas foi muito simples, ou seja, nada além de usar a estratégia de teste de sanidade mental.

Quando fazemos este teste para um módulo ou funcionalidade ou um sistema completo, os casos de teste para execução são selecionados de modo que eles vão tocar todos os bits e peças importantes do mesmo, ou seja, testes amplos mas rasos.

às vezes o teste é mesmo feito aleatoriamente, sem casos de teste., Mas lembre-se, Teste de sanidade deve ser feito apenas quando você está correndo pouco tempo, nunca use isso para seus lançamentos regulares. Teoricamente, este teste é um subconjunto de testes de regressão.

minha experiência

de meus 8 anos de carreira em testes de Software, por 3 anos eu estava trabalhando em metodologia ágil e esse foi o momento em que eu usei um teste de sanidade.

Todas as grandes versões foram planejadas e executadas de forma sistemática, mas às vezes, pequenas versões foram solicitadas para serem entregues o mais rápido possível., Não tivemos muito tempo para documentar os casos de teste, executar, fazer a documentação do bug, fazer a regressão e seguir todo o processo.

Daí a seguir estão algumas das principais dicas que eu usei para seguir em tais situações:

#1) Sentar-se com o gerente e a equipe de desenvolvimento quando eles estão discutindo a implementação porque eles têm de trabalhar rápido e, portanto, não podemos esperar que eles nos explicam separadamente.

isto também o ajudaria a ter uma ideia sobre o que eles vão implementar, qual a área que isso vai afetar, etc.,, esta é uma coisa muito importante a fazer porque às vezes simplesmente não percebemos as implicações e se qualquer funcionalidade existente vai ser prejudicada (na pior das hipóteses).

#2) Como você está com pouco tempo, no momento em que a equipe de desenvolvimento está trabalhando na implementação, você pode anotar os casos de teste mais ou menos em ferramentas como Evernote, etc. Mas certifique-se de que você escrevê-los em algum lugar para que você possa adicioná-los mais tarde para a ferramenta de caso de teste.,

#3) Mantenha o seu testbed pronto de acordo com a implementação e se sentir que existem quaisquer bandeiras vermelhas, como alguma criação de dados específica, se um testbed vai levar tempo (e é um teste importante para o lançamento), então levante essas bandeiras imediatamente e informe o seu gerente ou PO sobre o bloqueio de estrada.

só porque o cliente quer o mais rápido possível, isso não significa que um QA irá liberar mesmo se ele for meio testado.,

#4) Faça um acordo com sua equipe e gerente que, devido ao crunch de tempo, você só vai comunicar os bugs para a equipe de desenvolvimento e o processo formal de adição, marcando os bugs para diferentes fases na ferramenta de rastreamento de bugs será feito mais tarde, a fim de economizar tempo.

#5) Quando a equipe de desenvolvimento está testando no seu final, tente fazer par com eles (chamado dev-QA paring) e fazer uma rodada básica em sua própria configuração, isso irá ajudar a evitar o para e fro da compilação se a implementação básica estiver falhando.,

#6) Agora que você tem a compilação, teste as regras de negócio e todos os casos de uso em primeiro lugar. Você pode manter testes como uma validação de um campo, navegação, etc para mais tarde.

#7) quaisquer bugs que você encontrar, tome nota de todos eles e tente reportá-los juntos para os desenvolvedores, em vez de relatar individualmente, porque será fácil para eles trabalhar em um grupo.

#8) Se você tem um requisito para o teste de desempenho global ou teste de esforço ou carga, então certifique-se de que você tem uma estrutura de automação adequada para o mesmo., Porque é quase impossível testá-los manualmente com um teste de sanidade.

#9) Esta é a parte mais importante e, de fato, a última etapa de sua sanidade estratégia de teste – “Quando você redigir o lançamento de e-mail ou o documento, mencionar todos os casos de testes que você executou, os bugs encontrados com um marcador de status e se nada foi deixado testados mencioná-la com razões” Tentar escrever um nítido história sobre o teste que irá transmitir a todos o que foi testado, verificado e que não foi.eu segui isto religiosamente quando estava a usar este teste.,

Let me share my own experience:

#1) we were working on a website and it used to popup ads based on the keywords. Os anunciantes costumavam colocar a oferta para palavras-chave particulares que tinham uma tela projetada para o mesmo. O valor padrão de licitação usado para ser mostrado como $ 0,25, que o licitante poderia até mesmo mudar.

havia mais um lugar onde esta licitação padrão usada para aparecer e poderia ser alterada para outro valor também. O cliente veio com um pedido para mudar o valor padrão de $ 0,25 para $ 0,5, mas ele mencionou apenas a tela óbvia.,durante a nossa discussão de brainstorming, esquecemo-nos (?) sobre esta outra tela porque não foi usado muito para esse propósito. Mas enquanto testava quando eu corri o caso básico da oferta ser $ 0,5 e checked end to end, eu descobri que o cronjob para o mesmo estava falhando porque em um lugar ele estava encontrando $0,25.

eu relatei isso para a minha equipe e fizemos a mudança e entregamos com sucesso no mesmo dia.

#2) no mesmo projeto (mencionado acima), nos pediram para adicionar um pequeno campo de texto para notas/comentários para licitação., Foi uma implementação muito simples e comprometemo-nos a concretizá-la no mesmo dia.

por isso, como mencionado acima, eu testei todas as regras de negócio e casos de uso em torno dele e, quando eu fiz alguns testes de validação, eu achei que quando eu entrei uma combinação de caracteres especiais como </>, a página caiu.

Nós pensamos sobre isso e descobrimos que os licitantes reais não vão em qualquer caso usar tais combinações. Por isso, lançámo-lo com uma nota bem redigida sobre a questão., O cliente aceitou isso como um bug, mas concordou com a gente para implementá-lo mais tarde, porque era um bug grave, mas não um bug anterior.

#3) Recentemente, eu estava trabalhando em um projeto de app móvel, e tínhamos um requisito para atualizar o tempo de entrega mostrado no app de acordo com o fuso horário. Não foi apenas para ser testado no aplicativo, mas também para o serviço web.

enquanto a equipe de desenvolvimento estava trabalhando na implementação, eu criei os scripts de automação para o teste do serviço web e os scripts DB para mudar o fuso horário do item de entrega., Isto poupou-me esforços e poderíamos obter melhores resultados num curto espaço de tempo.

Sanidade Teste Vs Teste de Regressão

são Dadas abaixo algumas diferenças entre os dois:

a Estratégia Para Testes de aplicativos Móveis

Você deve estar se perguntando por que estou mencionando especificamente sobre aplicativos móveis aqui?

A razão é que o SO e a versão do navegador para aplicações web ou desktop não variam muito e, especialmente, os tamanhos de tela são padrão. Mas com aplicativos móveis, o tamanho da tela, a rede móvel, as versões SO, etc afetam a estabilidade, aparência e, em suma, o sucesso de seu aplicativo móvel.,

portanto, uma formulação de estratégia torna-se crítica quando você está realizando este teste em um aplicativo móvel, porque uma falha pode colocá-lo em grandes problemas. Os testes devem ser feitos com inteligência e cautela também.

a seguir estão alguns ponteiros para ajudá-lo a realizar este teste com sucesso em um ‘aplicativo móvel’:

#1) Em Primeiro Lugar, analisar o impacto da versão do SO na implementação com sua equipe.

tente encontrar respostas para perguntas como, o comportamento será diferente em todas as versões? A implementação irá funcionar na versão mais baixa suportada ou não?, Haverá problemas de desempenho para a implementação de versões? Há alguma característica específica do SO que possa afetar o comportamento da implementação? etc.

#2) na nota acima, analisar para os modelos de telefone também, ou seja, existem algumas características do telefone que irão impactar a implementação? A implementação do comportamento está mudando com o GPS? O comportamento de implementação está mudando com a câmera do telefone? etc. Se você descobrir que não há impacto, evite testes em diferentes modelos de telefone.,

#3) a menos que haja quaisquer alterações UI para a implementação eu recomendaria manter o teste UI na menor prioridade, você pode informar a equipe (se quiser) que a UI não será testada.

#4) a fim de economizar seu tempo, evite testes em boas redes, porque é óbvio que a implementação vai funcionar como esperado em uma rede forte. Eu recomendaria começar com testes em uma rede 4G ou 3G.

# 5) este teste deve ser feito em menos tempo, mas certifique-se de que você faz pelo menos um teste de campo, a menos que seja uma mera mudança UI.,

#6) Se você deve testar para uma matriz de SO diferentes e sua versão, eu sugeriria que você faça isso de uma forma inteligente. Por exemplo, escolha os pares mais baixos, médios e os mais recentes da versão OS para testes. Você pode mencionar no documento de lançamento que nem todas as combinações são testadas.

#7) numa linha semelhante, para o teste de sanidade da implementação da IU, use tamanhos de ecrã pequenos, médios e grandes para poupar tempo. Você também pode usar um simulador e emulador.,

medidas de precaução

teste de sanidade é realizado quando você está correndo pouco tempo e, portanto, não é possível para você executar cada caso de teste e, mais importante, você não tem tempo suficiente para planejar seus testes. Para evitar os jogos de culpa, é melhor tomar medidas de precaução.em tais casos, a falta de comunicação escrita, documentação de teste e falhas são bastante comuns.,

para garantir que não é vítima disto, certifique-se de que:

• nunca aceite uma compilação para testes até que não lhe seja dado um requisito escrito partilhado pelo cliente. Acontece que os clientes comunicam alterações ou novas implementações verbalmente ou em chat ou um simples 1 liner em um e-mail e esperam que tratemos isso como um requisito. Obrigar o seu cliente a fornecer alguns pontos básicos de funcionalidade e critérios de aceitação.
• sempre faça notas grosseiras de seus casos de teste e bugs Se você não estiver tendo tempo suficiente para escrevê-los corretamente. Nunca deixe estes indocumentados., Se houver algum tempo, partilhe-o com a sua liderança ou equipa para que, se faltar alguma coisa, eles o possam apontar facilmente.se você e sua equipe tiverem pouco tempo, certifique-se de que os bugs estão marcados no estado apropriado em um e-mail? Você pode enviar por e-mail a lista completa de bugs para a equipe e fazer com que os devs os marquem apropriadamente. Mantém sempre a bola no campo do outro.
• Se você tem o Framework de automação pronto, use isso e evite fazer o teste manual, dessa forma em menos tempo você pode cobrir mais.,evite o cenário de” lançamento em 1 hora”, a menos que tenha 100% de certeza de que será capaz de entregar.
• Por último, mas não menos importante, como mencionado acima, elabore um e-mail de lançamento detalhado comunicando o que é testado, o que é deixado de fora, razões, riscos, quais bugs são resolvidos, o que é ‘Latered’ etc.

Como um QA, você deve julgar qual é a parte mais importante da implementação que precisa ser testada e quais são as partes que podem ser deixadas de fora ou teste básico.,

mesmo em um curto período de tempo, planeie uma estratégia sobre como você quer fazer e você será capaz de alcançar o melhor no prazo dado.

ensaio de fumos

ensaio de fumos não é um ensaio exaustivo, mas é um grupo de ensaios que são executados para verificar se as funcionalidades básicas dessa construção específica estão a funcionar bem como esperado ou não. Este é e deve ser sempre o primeiro teste a ser feito em qualquer ‘nova’ construção.,

Quando a equipe de desenvolvimento libera uma compilação para o QA para testes, obviamente não é possível testar toda a compilação e verificar imediatamente se alguma das implementações está tendo bugs ou se alguma da funcionalidade de trabalho está quebrada.

à luz disto, como é que um QA vai certificar-se de que as funcionalidades básicas estão a funcionar bem?

A resposta a isso será realizar um teste de Fumaça.

Uma vez que os testes são marcados como testes de fumaça (no conjunto de testes) passar, só então a construção é aceita pelo QA para testes em profundidade e/ou regressão., Se algum dos testes de fumaça falhar, a construção é rejeitada e a equipe de desenvolvimento precisa corrigir o problema e liberar uma nova construção para testes.teoricamente, o ensaio de fumos é definido como um ensaio ao nível da superfície para certificar que a Constituição fornecida pela equipa de desenvolvimento à equipa de avaliação do desempenho está pronta para novos ensaios. Este teste também é realizado pela equipe de desenvolvimento antes de lançar a compilação para a equipe de QA.este ensaio é normalmente utilizado em ensaios de integração, ensaios de sistemas e ensaios de Nível de aceitação. Nunca trate isso como um substituto para o fim Real de terminar os testes completos., Inclui testes positivos e negativos, dependendo da implementação do build.

exemplos de ensaio de fumos

Este ensaio é normalmente utilizado para ensaios de integração, aceitação e sistema.

em minha carreira como QA, eu sempre aceitei uma construção apenas depois de ter realizado um teste de fumaça. Então, vamos entender o que é um teste de fumaça a partir da perspectiva de todos esses três testes, com alguns exemplos.

#1) ensaios de aceitação

sempre que uma compilação é libertada para o QA, deve ser feito o ensaio de fumos sob a forma de um ensaio de aceitação.,

neste ensaio, o primeiro e mais importante ensaio de fumos consiste em verificar a funcionalidade básica esperada da implementação. Assim, você deve verificar todas as implementações para essa construção em particular.

vamos levar os seguintes exemplos como implementações feitas em uma compilação para entender os testes de fumaça para aqueles:

• implementou a funcionalidade de login para permitir que os drivers registrados para login com sucesso.
• implementou a funcionalidade do painel de instrumentos para mostrar as rotas que um driver deve executar hoje.,
• implementou a funcionalidade para mostrar uma mensagem apropriada se não existirem rotas para um determinado dia.

na compilação acima, no nível de aceitação, o teste de fumos significará verificar que as três implementações básicas estão funcionando bem. Se algum destes três está quebrado, então o QA deve rejeitar a construção.

#2) Teste de integração

este teste é geralmente feito quando os módulos individuais são implementados e testados., No nível de testes de integração, este teste é realizado para garantir que toda a integração básica e funcionalidades finais estão funcionando bem como esperado.

pode ser a integração de dois módulos ou de todos os módulos juntos, portanto, a complexidade do teste de fumaça irá variar dependendo do nível de integração.consideremos os seguintes exemplos de implementação de integração para este teste:

• implementou a integração de módulos de rota e paragem.
• implementou a integração da atualização do Estado de chegada e reflete o mesmo no ecrã de paragens.,
• implementou a integração de pick up completo até os módulos de funcionalidade de entrega.

nesta compilação, o teste de fumaça não só irá verificar estas três implementações básicas, mas para a terceira implementação, alguns casos irão verificar para integração completa também. Ajuda muito descobrir as questões que são introduzidas na integração e as que passaram despercebidas pela equipe de desenvolvimento.

# 3) Teste do sistema

como o próprio nome sugere, para o nível do sistema, o teste de fumaça inclui testes para os fluxos de trabalho mais importantes e comumente usados do sistema., Isto só é feito após o sistema completo estar pronto & testado, e este teste para o nível do sistema pode ser referido como teste de fumos antes do teste de regressão também.

Antes de iniciar a regressão do sistema completo, as características básicas de fim a fim são ensaiadas como parte do ensaio de fumos. O conjunto de testes de fumaça para o sistema completo compreende os casos de teste final a final que os usuários finais vão usar com muita frequência.isto é geralmente feito com a ajuda de ferramentas de automação.,

importância na metodologia SCRUM

Atualmente, os projetos dificilmente seguem a metodologia Waterfall na implementação do projeto, principalmente todos os projetos seguem apenas ágil e SCRUM. Em comparação com o método tradicional da cachoeira, o teste de fumaça tem alta consideração em SCRUM e ágil.trabalhei 4 anos no SCRUM. E como sabemos que em SCRUM, os sprints são de menor duração e, portanto, é de extrema importância fazer este teste, de modo que as construções falhadas podem ser imediatamente relatadas à equipe de desenvolvimento e corrigidas também.,

a seguir estão algumas takeaway on the importance of this testing in SCRUM:

• fora da corrida de quinze dias, o intervalo é alocado para a QA, mas às vezes as compilações para a QA são adiadas.
• em sprints, é melhor para a equipe que as questões sejam relatadas em uma fase inicial.
• Cada história tem um conjunto de critérios de aceitação, portanto, testar os primeiros 2-3 critérios de aceitação é igual ao teste de fumaça dessa funcionalidade. Os clientes rejeitam a entrega se um único critério estiver falhando.,
• apenas imagine o que vai acontecer se forem 2 dias que a equipe de desenvolvimento lhe entregou a compilação e apenas 3 dias estão restando para a demonstração e você se depara com uma falha de funcionalidade básica.
• em média, um sprint tem histórias que variam de 5-10, portanto, quando a construção é dada é importante ter certeza de que cada história é implementada como esperado antes de aceitar a construção em testes.
• Quando o sistema completo deve ser testado e regredido, um sprint é dedicado à atividade., Uma quinzena talvez um pouco menos para testar todo o sistema, por isso é muito importante verificar as funcionalidades mais básicas antes de iniciar a regressão.

Smoke Test Vs Build Acceptance Testing

Smoke tests is directly related to Build Acceptance Testing (MTD).

no BAT, nós fazemos o mesmo teste-para verificar se a compilação não falhou e que o sistema está funcionando bem ou não. Às vezes, acontece que quando uma construção é criada, algumas questões são introduzidas e quando é entregue, a construção não funciona para o QA.,

I would say that BAT is a part of a smoke check because if the system is failing, how can you as a QA accept the build for testing? Não apenas as funcionalidades, o sistema em si tem que trabalhar antes que o QA prossiga com testes em profundidade.

ciclo de ensaio de fumos

o fluxograma seguinte explica o ciclo de ensaio de fumos.

Uma vez que um build é implantado para um QA, o ciclo básico seguido é que, se o teste de fumaça passa, o build é aceito pela equipe de QA para mais testes, mas se ele falhar, o build é rejeitado até que os problemas relatados são corrigidos.,

ciclo de ensaio

quem deve realizar o ensaio de fumo?

nem toda a equipa está envolvida neste tipo de testes para evitar o desperdício de tempo de todos os testes de fumaça.

O teste de fumaça é idealmente realizado pelo líder de QA que decide com base no resultado sobre se deve passar a compilação para a equipa para mais testes ou rejeitá-lo. Ou na ausência da liderança, a própria QA também pode realizar este teste.

às vezes, quando o projeto é de grande escala, um grupo de QA também pode realizar este teste para verificar qualquer showstoppers., Mas isso não é assim no caso de SCRUM porque SCRUM é uma estrutura plana sem pistas ou gerentes e cada testador tem suas próprias responsabilidades para com suas histórias.

daí qa’s individuais realizar este teste para as histórias que eles possuem.por que devemos automatizar os testes de fumos?

este teste é o primeiro teste a ser feito em uma compilação lançada pela equipe de desenvolvimento. Com base nos resultados deste teste, mais testes são feitos (ou a compilação é rejeitada).,

A melhor maneira de fazer este teste é usar uma ferramenta de automação e agendar o pacote de fumaça para executar quando uma nova compilação é criada. Deves estar a pensar porque devo “automatizar a sala de testes de fumo”?

vamos olhar para o seguinte caso:

vamos dizer que você está a uma semana de sua libertação e fora do total de 500 casos de teste, seu conjunto de teste de fumaça é composto de 80-90. Se você começar a executar todos esses 80-90 casos de teste manualmente, imagine Quanto tempo você vai levar? Acho que 4-5 dias (mínimo).,

mas se você usar automação e criar scripts para executar todos estes 80-90 casos de teste, então idealmente, estes serão executados em 2-3 horas e você terá os resultados com você instantaneamente. Não poupou o seu precioso tempo e lhe deu os resultados sobre a construção-em muito menos tempo?há 5 anos, estava a testar uma aplicação de projecção financeira, que teve dados sobre o teu salário, poupanças, etc., e projetou seus impostos, economias, lucros dependendo das regras financeiras. Junto com isso, tivemos personalização para os países que dependem do país e suas regras fiscais usadas para mudar (no código).,

para este projeto, eu tive 800 casos de teste e 250 foram casos de teste de fumaça. Com o uso de selênio, poderíamos facilmente automatizar e obter os resultados desses 250 casos de teste em 3-4 horas. Não só nos poupou tempo, como nos mostrou o mais rápido possível sobre os showstoppers.

portanto, a menos que seja impossível automatizar, tome a ajuda de automação para este teste.

Vantagens E Desvantagens

Vamos primeiro dar uma olhada nas vantagens como ele tem muito a oferecer quando comparado com as poucas desvantagens.vantagens:

• fácil de executar.
• reduz o risco.,os defeitos são identificados numa fase muito precoce.poupa esforços, tempo e dinheiro.
• é executado rapidamente se automatizado.menos riscos e problemas de integração.
• melhora a qualidade geral do sistema.

desvantagens:

• este teste não é igual ou um substituto para o teste funcional completo.mesmo após o teste de fumaça passar, você pode encontrar bugs showstopper.,
• este tipo de teste é melhor adequado se você puder automatizar o outro um monte de tempo é gasto na execução manual dos casos de teste, especialmente em projetos de grande escala com cerca de 700-800 casos de teste.

o ensaio de fumos deve ser feito definitivamente em cada construção, uma vez que aponta para as principais falhas e showstoppers numa fase muito precoce. Isto aplica-se não só às novas funcionalidades, mas também à integração de módulos, à fixação de questões e à improvisação. É um processo muito simples de executar e obter o resultado correto.,este ensaio pode ser tratado como ponto de entrada para o ensaio funcional completo da funcionalidade ou do sistema (no seu conjunto). Mas antes disso, a equipe de QA deve ser muito clara sobre quais testes devem ser feitos como testes de fumaça. Este teste pode minimizar os esforços, economizar tempo e melhorar a qualidade do sistema. Possui um lugar muito importante em sprints como o tempo em sprints é menor.este teste pode ser feito manualmente e também com a ajuda de ferramentas de automação. Mas a melhor e preferida maneira é usar ferramentas de automação para economizar tempo.,

diferença entre o teste de fumaça e o teste de sanidade

na maioria das vezes ficamos confusos entre o Significado de teste de sanidade e teste de Fumaça. Em primeiro lugar, estes dois ensaios são muito “diferentes” e realizados em diferentes fases de um ciclo de ensaio.

a Seguir é uma representação esquemática de suas diferenças:

FUMAÇA TESTE

• Este teste teve origem no teste de hardware prática de se transformar em uma nova peça de hardware, pela primeira vez, e, considerando que é um sucesso se ele não pegar fogo e fumaça. Na indústria de software, este teste é uma abordagem superficial e ampla, através da qual todas as áreas da aplicação sem entrar em muito profundo, é testado.,
• um teste de fumos é rotulado, usando um conjunto escrito de testes ou um teste automatizado
• um teste de fumos é projetado para tocar todas as partes da aplicação de uma forma superficial. É superficial e largo.
• este teste é realizado para garantir se as funções mais cruciais de um programa estão funcionando, mas não se incomodando com os detalhes mais finos. (Como a verificação da construção).este teste é um exame de saúde normal até à constituição de um pedido antes de o fazer para testar em profundidade.,

teste de sanidade mental

• um teste de sanidade mental é um teste de regressão estreito que se concentra em uma ou algumas áreas de funcionalidade. O teste de sanidade é geralmente estreito e profundo.
• este ensaio é normalmente desenroscado.
• este ensaio é utilizado para determinar que uma pequena secção da aplicação ainda está a funcionar após uma pequena alteração.este ensaio é um ensaio superficial, que é realizado sempre que um ensaio superficial é suficiente para provar que a aplicação está a funcionar de acordo com as especificações. Este nível de testes é um subconjunto de testes de regressão.,
• isto é para verificar se os requisitos são cumpridos ou não, Verificando todas as características largura-primeiro.