Teste de software - Guia rápido

O que é teste?

Teste é o processo de avaliação de um sistema ou de seu (s) componente (s) com a intenção de descobrir se ele satisfaz ou não os requisitos especificados. Em palavras simples, teste é executar um sistema para identificar quaisquer lacunas, erros ou requisitos ausentes que sejam contrários aos requisitos reais.

De acordo com o padrão ANSI / IEEE 1059, Teste pode ser definido como - Um processo de análise de um item de software para detectar as diferenças entre as condições existentes e necessárias (ou seja, defeitos / erros / bugs) e para avaliar os recursos do item de software.

Quem faz o teste?

Depende do processo e das partes interessadas associadas ao (s) projeto (s). Na indústria de TI, as grandes empresas têm uma equipe com responsabilidades para avaliar o software desenvolvido no contexto dos requisitos fornecidos. Além disso, os desenvolvedores também realizam testes que são chamadosUnit Testing. Na maioria dos casos, os seguintes profissionais estão envolvidos no teste de um sistema dentro de suas respectivas capacidades -

• Testador de software
• Desenvolvedor de software
• Líder / Gerente de Projeto
• Usuário final

Diferentes empresas têm diferentes designações para pessoas que testam o software com base em sua experiência e conhecimento, como testador de software, engenheiro de garantia de qualidade de software, analista de controle de qualidade, etc.

Não é possível testar o software em nenhum momento durante seu ciclo. As próximas duas seções indicam quando o teste deve ser iniciado e quando encerrá-lo durante o SDLC.

Quando começar o teste?

O início precoce dos testes reduz o custo e o tempo de retrabalho e produção de software livre de erros que é entregue ao cliente. No entanto, no Ciclo de Vida de Desenvolvimento de Software (SDLC), o teste pode ser iniciado na fase de Coleta de Requisitos e continuado até a implantação do software.

Também depende do modelo de desenvolvimento que está sendo usado. Por exemplo, no modelo em Cachoeira, o teste formal é conduzido na fase de teste; mas no modelo incremental, o teste é executado no final de cada incremento / iteração e todo o aplicativo é testado no final.

O teste é feito de diferentes formas em cada fase do SDLC -

• Durante a fase de coleta de requisitos, a análise e verificação dos requisitos também são consideradas como teste.

• A revisão do design na fase de design com a intenção de aprimorá-lo também é considerada um teste.

• O teste realizado por um desenvolvedor na conclusão do código também é classificado como teste.

Quando parar de testar?

É difícil determinar quando interromper o teste, pois o teste é um processo sem fim e ninguém pode alegar que um software foi 100% testado. Os seguintes aspectos devem ser considerados para interromper o processo de teste -

• Prazos de teste

• Conclusão da execução do caso de teste

• Conclusão da cobertura funcional e de código até um certo ponto

• A taxa de bug cai abaixo de um certo nível e nenhum bug de alta prioridade é identificado

• Decisão de gestão

Validação de verificação

Esses dois termos são muito confusos para a maioria das pessoas, que os usam de forma intercambiável. A tabela a seguir destaca as diferenças entre verificação e validação.

Sr. Não.	Verificação	Validação
1	A verificação aborda a preocupação: "Você está construindo certo?"	A validação aborda a preocupação: "Você está construindo a coisa certa?"
2	Garante que o sistema de software atenda a todas as funcionalidades.	Garante que as funcionalidades atendam ao comportamento pretendido.
3	A verificação ocorre primeiro e inclui a verificação de documentação, código, etc.	A validação ocorre após a verificação e envolve principalmente a verificação de todo o produto.
4	Feito por desenvolvedores.	Feito por testadores.
5	Ele tem atividades estáticas, pois inclui a coleta de revisões, orientações e inspeções para verificar um software.	Possui atividades dinâmicas, pois inclui a execução do software em relação aos requisitos.
6	É um processo objetivo e nenhuma decisão subjetiva deve ser necessária para verificar um software.	É um processo subjetivo e envolve decisões subjetivas sobre o quão bem um software funciona.

A seguir, estão alguns dos mitos mais comuns sobre o teste de software.

Mito 1: o teste é muito caro

Reality- Há um ditado que diz: pague menos pelos testes durante o desenvolvimento do software ou pague mais pela manutenção ou correção posterior. O teste antecipado economiza tempo e custo em muitos aspectos; no entanto, reduzir o custo sem testar pode resultar no design impróprio de um aplicativo de software, tornando o produto inútil.

Mito 2: o teste consome muito tempo

Reality- Durante as fases SDLC, o teste nunca é um processo demorado. No entanto, diagnosticar e corrigir os erros identificados durante o teste adequado é uma atividade demorada, mas produtiva.

Mito 3: Somente produtos totalmente desenvolvidos são testados

Reality- Sem dúvida, o teste depende do código-fonte, mas a revisão dos requisitos e o desenvolvimento de casos de teste são independentes do código desenvolvido. No entanto, a abordagem iterativa ou incremental como um modelo de ciclo de vida de desenvolvimento pode reduzir a dependência do teste no software totalmente desenvolvido.

Mito 4: o teste completo é possível

Reality- Torna-se um problema quando um cliente ou testador pensa que o teste completo é possível. É possível que todos os caminhos tenham sido testados pela equipe, mas a ocorrência de testes completos nunca é possível. Pode haver alguns cenários que nunca são executados pela equipe de teste ou pelo cliente durante o ciclo de vida de desenvolvimento do software e podem ser executados após a implantação do projeto.

Mito 5: um software testado não contém erros

Reality - Este é um mito muito comum no qual os clientes, gerentes de projeto e a equipe de gerenciamento acreditam. Ninguém pode afirmar com certeza absoluta que um aplicativo de software é 100% livre de bugs, mesmo que um testador com excelentes habilidades de teste tenha testado o aplicativo .

Mito 6: Os defeitos perdidos são devidos aos testadores

Reality- Não é uma abordagem correta culpar os testadores por bugs que permanecem no aplicativo, mesmo após o teste ter sido executado. Esse mito está relacionado às restrições de mudança de tempo, custo e requisitos. No entanto, a estratégia de teste também pode resultar na perda de bugs pela equipe de teste.

Mito 7: Os testadores são responsáveis ​​pela qualidade do produto

Reality- É uma interpretação errônea muito comum que apenas os testadores ou a equipe de teste devem ser responsáveis ​​pela qualidade do produto. As responsabilidades dos testadores incluem a identificação de bugs para as partes interessadas e, em seguida, é sua decisão se eles irão corrigir o bug ou lançar o software. Liberar o software na hora coloca mais pressão sobre os testadores, pois eles serão responsabilizados por qualquer erro.

Mito 8: A automação de teste deve ser usada sempre que possível para reduzir o tempo

Reality- Sim, é verdade que o Test Automation reduz o tempo de teste, mas não é possível iniciar a automação de teste a qualquer momento durante o desenvolvimento do software. O autômato de teste deve ser iniciado quando o software foi testado manualmente e está estável até certo ponto. Além disso, a automação de teste nunca pode ser usada se os requisitos continuarem mudando.

Mito 9: Qualquer pessoa pode testar um aplicativo de software

Reality- Pessoas fora da indústria de TI pensam e até acreditam que qualquer pessoa pode testar um software e testar não é um trabalho criativo. No entanto, os testadores sabem muito bem que isso é um mito. Pensar em cenários alternativos, tentar travar um software com a intenção de explorar possíveis bugs, não é possível para a pessoa que o desenvolveu.

Mito 10: A única tarefa de um testador é encontrar bugs

Reality- Encontrar bugs em um software é tarefa dos testadores, mas, ao mesmo tempo, eles são especialistas no domínio do software específico. Os desenvolvedores são responsáveis ​​apenas pelo componente ou área específica que lhes é atribuída, mas os testadores entendem o funcionamento geral do software, quais são as dependências e os impactos de um módulo em outro.

Teste, garantia de qualidade e controle de qualidade

A maioria das pessoas fica confusa quando se trata de identificar as diferenças entre garantia de qualidade, controle de qualidade e testes. Embora estejam inter-relacionados e até certo ponto, podem ser considerados como atividades iguais, mas existem pontos distintivos que os diferenciam. A tabela a seguir lista os pontos que diferenciam QA, QC e teste.

Garantia da Qualidade	Controle de qualidade	Testando
QA inclui atividades que garantem a implementação de processos, procedimentos e padrões no contexto da verificação do software desenvolvido e dos requisitos pretendidos.	Inclui atividades que garantem a verificação de um software desenvolvido em relação aos requisitos documentados (ou não em alguns casos).	Inclui atividades que garantem a identificação de bugs / erros / defeitos em um software.
Concentra-se em processos e procedimentos em vez de conduzir testes reais no sistema.	Concentra-se no teste real executando o software com o objetivo de identificar bug / defeito por meio da implementação de procedimentos e processos.	Concentra-se em testes reais.
Atividades orientadas a processos.	Atividades orientadas para o produto.	Atividades orientadas para o produto.
Atividades preventivas.	É um processo corretivo.	É um processo preventivo.
É um subconjunto do Software Test Life Cycle (STLC).	O CQ pode ser considerado como o subconjunto da Garantia de Qualidade.	Teste é o subconjunto do Controle de Qualidade.

Auditoria e Inspeção

Audit- É um processo sistemático para determinar como o processo de teste real é conduzido dentro de uma organização ou equipe. Geralmente, é um exame independente dos processos envolvidos durante o teste de um software. De acordo com o IEEE, é uma revisão dos processos documentados que as organizações implementam e seguem. Os tipos de auditoria incluem Auditoria de Conformidade Legal, Auditoria Interna e Auditoria de Sistema.

Inspection- É uma técnica formal que envolve revisões técnicas formais ou informais de qualquer artefato, identificando qualquer erro ou lacuna. De acordo com o IEEE94, a inspeção é uma técnica de avaliação formal na qual os requisitos, projetos ou códigos de software são examinados em detalhes por uma pessoa ou um grupo diferente do autor para detectar falhas, violações dos padrões de desenvolvimento e outros problemas.

As reuniões formais de inspeção podem incluir os seguintes processos: Planejamento, Preparação da Visão Geral, Reunião de Inspeção, Retrabalho e Acompanhamento.

Teste e depuração

Testing- Envolve a identificação de bug / erro / defeito em um software sem corrigi-lo. Normalmente, profissionais com experiência em garantia de qualidade estão envolvidos na identificação de bugs. O teste é realizado na fase de teste.

Debugging- Envolve identificar, isolar e corrigir os problemas / bugs. Os desenvolvedores que codificam o software realizam a depuração ao encontrar um erro no código. A depuração é uma parte do Teste de Caixa Branca ou Teste de Unidade. A depuração pode ser realizada na fase de desenvolvimento durante a realização de testes de unidade ou em fases durante a correção dos bugs relatados.

Muitas organizações em todo o mundo desenvolvem e implementam diferentes padrões para melhorar as necessidades de qualidade de seus softwares. Este capítulo descreve resumidamente alguns dos padrões amplamente usados ​​relacionados à Garantia de Qualidade e Teste.

ISO / IEC 9126

Este padrão trata dos seguintes aspectos para determinar a qualidade de um aplicativo de software -

• Modelo de qualidade
• Métricas externas
• Métricas internas
• Qualidade em métricas de uso

Este padrão apresenta algum conjunto de atributos de qualidade para qualquer software, como -

• Functionality
• Reliability
• Usability
• Efficiency
• Maintainability
• Portability

Os atributos de qualidade mencionados acima são divididos em subfatores, que você pode estudar ao estudar o padrão em detalhes.

ISO / IEC 9241-11

A Parte 11 deste padrão trata da extensão em que um produto pode ser usado por usuários específicos para atingir objetivos específicos com Eficácia, Eficiência e Satisfação em um contexto de uso especificado.

Este padrão propôs um framework que descreve os componentes de usabilidade e a relação entre eles. Neste padrão, a usabilidade é considerada em termos de desempenho e satisfação do usuário. De acordo com a ISO 9241-11, a usabilidade depende do contexto de uso e o nível de usabilidade mudará conforme o contexto muda.

ISO / IEC 25000: 2005

ISO / IEC 25000: 2005 é comumente conhecido como o padrão que fornece as diretrizes para Requisitos e Avaliação de Qualidade de Software (SQuaRE). Este padrão ajuda a organizar e aprimorar o processo relacionado aos requisitos de qualidade de software e suas avaliações. Na realidade, o ISO-25000 substitui os dois antigos padrões ISO, ou seja, ISO-9126 e ISO-14598.

SQuaRE é dividido em sub-partes, como -

• ISO 2500n - Divisão de Gestão da Qualidade
• ISO 2501n - Divisão de Modelo de Qualidade
• ISO 2502n - Divisão de Medição de Qualidade
• ISO 2503n - Divisão de Requisitos de Qualidade
• ISO 2504n - Divisão de Avaliação de Qualidade

Os principais conteúdos do SQuaRE são -

• Termos e definições
• Modelos de Referência
• Guia geral
• Guias de divisão individual
• Padrão relacionado à Engenharia de Requisitos (ou seja, especificação, planejamento, medição e processo de avaliação)

ISO / IEC 12119

Este padrão trata de pacotes de software entregues ao cliente. Não enfoca nem trata do processo de produção dos clientes. O conteúdo principal está relacionado aos seguintes itens -

• Conjunto de requisitos para pacotes de software.
• Instruções para testar um pacote de software entregue em relação aos requisitos especificados.

Diversos

Alguns dos outros padrões relacionados aos processos de controle de qualidade e teste são mencionados abaixo -

Sr. Não	Padrão e descrição
1	IEEE 829 Um padrão para o formato de documentos usados ​​em diferentes estágios de teste de software.
2	IEEE 1061 Uma metodologia para estabelecer requisitos de qualidade, identificando, implementando, analisando e validando o processo e produto de métricas de qualidade de software.
3	IEEE 1059 Guia para Planos de Verificação e Validação de Software.
4	IEEE 1008 Um padrão para teste de unidade.
5	IEEE 1012 Um padrão para verificação e validação de software.
6	IEEE 1028 Um padrão para inspeções de software.
7	IEEE 1044 Um padrão para a classificação de anomalias de software.
8	IEEE 1044-1 Um guia para a classificação de anomalias de software.
9	IEEE 830 Um guia para desenvolver especificações de requisitos de sistema.
10	IEEE 730 Um padrão para planos de garantia de qualidade de software.
11	IEEE 1061 Um padrão para métricas e metodologia de qualidade de software.
12	IEEE 12207 Um padrão para processos de ciclo de vida de software e dados de ciclo de vida.
13	BS 7925-1 Um vocabulário de termos usados ​​em testes de software.
14	BS 7925-2 Um padrão para teste de componentes de software.

Esta seção descreve os diferentes tipos de teste que podem ser usados ​​para testar um software durante o SDLC.

Teste Manual

O teste manual inclui testar um software manualmente, ou seja, sem usar qualquer ferramenta automatizada ou qualquer script. Nesse tipo, o testador assume a função de um usuário final e testa o software para identificar qualquer comportamento inesperado ou bug. Existem diferentes estágios para o teste manual, como teste de unidade, teste de integração, teste de sistema e teste de aceitação do usuário.

Os testadores usam planos de teste, casos de teste ou cenários de teste para testar um software e garantir a integridade do teste. O teste manual também inclui teste exploratório, à medida que os testadores exploram o software para identificar erros nele.

Teste de automação

O teste de automação, também conhecido como Automação de Teste, ocorre quando o testador grava scripts e usa outro software para testar o produto. Este processo envolve a automação de um processo manual. O teste de automação é usado para executar novamente os cenários de teste que foram executados de forma manual, rápida e repetida.

Além do teste de regressão, o teste de automação também é usado para testar o aplicativo do ponto de vista de carga, desempenho e estresse. Ele aumenta a cobertura do teste, melhora a precisão e economiza tempo e dinheiro em comparação com o teste manual.

O que automatizar?

Não é possível automatizar tudo em um software. As áreas nas quais um usuário pode fazer transações, como o formulário de login ou formulários de registro, qualquer área onde um grande número de usuários possa acessar o software simultaneamente deve ser automatizada.

Além disso, todos os itens da GUI, conexões com bancos de dados, validações de campo, etc. podem ser testados com eficiência automatizando o processo manual.

Quando automatizar?

A automação de teste deve ser usada considerando os seguintes aspectos de um software -

• Projetos grandes e críticos
• Projetos que exigem testes nas mesmas áreas com frequência
• Os requisitos não mudam com frequência
• Acessando o aplicativo para carga e desempenho com muitos usuários virtuais
• Software estável em relação ao teste manual
• Disponibilidade de tempo

Como automatizar?

A automação é feita usando uma linguagem de computador de suporte, como scripts VB e um aplicativo de software automatizado. Existem muitas ferramentas disponíveis que podem ser usadas para escrever scripts de automação. Antes de mencionar as ferramentas, vamos identificar o processo que pode ser usado para automatizar o processo de teste -

• Identificação de áreas dentro de um software para automação
• Seleção de ferramenta apropriada para automação de teste
• Escrevendo scripts de teste
• Desenvolvimento de trajes de teste
• Execução de scripts
• Crie relatórios de resultados
• Identifique qualquer bug ou problema de desempenho em potencial

Ferramentas de teste de software

As seguintes ferramentas podem ser usadas para testes de automação -

• HP Quick Test Professional
• Selenium
• IBM Rational Functional Tester
• SilkTest
• TestComplete
• Teste em qualquer lugar
• WinRunner
• LoadRunner
• Visual Studio Test Professional
• WATIR

Existem diferentes métodos que podem ser usados ​​para teste de software. Este capítulo descreve resumidamente os métodos disponíveis.

Teste de caixa preta

A técnica de testar sem ter nenhum conhecimento do funcionamento interno do aplicativo é chamada de teste de caixa preta. O testador está alheio à arquitetura do sistema e não tem acesso ao código-fonte. Normalmente, ao realizar um teste de caixa preta, um testador irá interagir com a interface do usuário do sistema, fornecendo entradas e examinando saídas sem saber como e onde as entradas são trabalhadas.

A tabela a seguir lista as vantagens e desvantagens do teste de caixa preta.

Vantagens	Desvantagens
Bem adequado e eficiente para grandes segmentos de código.	Cobertura limitada, uma vez que apenas um número selecionado de cenários de teste é realmente executado.
O acesso ao código não é necessário.	Teste ineficiente, devido ao fato de que o testador tem conhecimento limitado sobre um aplicativo.
Separa claramente a perspectiva do usuário da perspectiva do desenvolvedor por meio de funções definidas de forma visível.	Cobertura cega, uma vez que o testador não pode visar segmentos de código específicos ou áreas sujeitas a erros.
Um grande número de testadores moderadamente qualificados pode testar o aplicativo sem nenhum conhecimento de implementação, linguagem de programação ou sistemas operacionais.	Os casos de teste são difíceis de projetar.

Teste de caixa branca

O teste de caixa branca é a investigação detalhada da lógica interna e da estrutura do código. O teste de caixa branca também é chamadoglass testing ou open-box testing. A fim de realizarwhite-box testando em um aplicativo, um testador precisa saber o funcionamento interno do código.

O testador precisa dar uma olhada no código-fonte e descobrir qual unidade / parte do código está se comportando de maneira inadequada.

A tabela a seguir lista as vantagens e desvantagens do teste de caixa branca.

Vantagens	Desvantagens
Como o testador tem conhecimento do código-fonte, torna-se muito fácil descobrir quais tipos de dados podem ajudar a testar o aplicativo com eficácia.	Devido ao fato de que um testador qualificado é necessário para realizar o teste de caixa branca, os custos aumentam.
Isso ajuda a otimizar o código.	Às vezes, é impossível examinar cada canto e esquina para descobrir erros ocultos que podem criar problemas, pois muitos caminhos não serão testados.
Linhas extras de código podem ser removidas, o que pode trazer defeitos ocultos.	É difícil manter o teste de caixa branca, pois requer ferramentas especializadas, como analisadores de código e ferramentas de depuração.
Devido ao conhecimento do testador sobre o código, a cobertura máxima é obtida durante a escrita do cenário de teste.

Teste Gray-Box

O teste de caixa cinza é uma técnica para testar o aplicativo com um conhecimento limitado do funcionamento interno de um aplicativo. Em testes de software, a frase quanto mais você sabe, melhor tem muito peso durante o teste de um aplicativo.

Dominar o domínio de um sistema sempre dá ao testador uma vantagem sobre alguém com conhecimento de domínio limitado. Ao contrário do teste de caixa preta, em que o testador testa apenas a interface do usuário do aplicativo; no teste de caixa cinza, o testador tem acesso aos documentos de design e ao banco de dados. Tendo esse conhecimento, um testador pode preparar melhores dados de teste e cenários de teste enquanto faz um plano de teste.

Vantagens	Desvantagens
Oferece benefícios combinados de teste de caixa preta e caixa branca sempre que possível.	Como o acesso ao código-fonte não está disponível, a capacidade de revisar o código e testar a cobertura é limitada.
Os testadores da caixa cinza não dependem do código-fonte; em vez disso, eles contam com a definição de interface e especificações funcionais.	Os testes podem ser redundantes se o designer do software já executou um caso de teste.
Com base nas informações limitadas disponíveis, um testador de caixa cinza pode projetar cenários de teste excelentes, especialmente em torno de protocolos de comunicação e manipulação de tipo de dados.	Testar todos os fluxos de entrada possíveis não é realista porque levaria uma quantidade de tempo irracional; portanto, muitos caminhos de programa não serão testados.
O teste é feito do ponto de vista do usuário e não do designer.

Uma comparação de métodos de teste

A tabela a seguir lista os pontos que diferenciam o teste de caixa preta, o teste de caixa cinza e o teste de caixa branca.

Teste de caixa preta	Teste Gray-Box	Teste de caixa branca
O funcionamento interno de um aplicativo não precisa ser conhecido.	O testador tem conhecimento limitado do funcionamento interno do aplicativo.	O testador tem total conhecimento do funcionamento interno do aplicativo.
Também conhecido como teste de caixa fechada, teste orientado por dados ou teste funcional.	Também conhecido como teste translúcido, porque o testador tem conhecimento limitado do interior do aplicativo.	Também conhecido como teste de caixa clara, teste estrutural ou teste baseado em código.
Executado por usuários finais e também por testadores e desenvolvedores.	Executado por usuários finais e também por testadores e desenvolvedores.	Normalmente feito por testadores e desenvolvedores.
O teste é baseado em expectativas externas - o comportamento interno do aplicativo é desconhecido.	O teste é feito com base em diagramas de banco de dados de alto nível e diagramas de fluxo de dados.	O funcionamento interno é totalmente conhecido e o testador pode projetar os dados de teste de acordo.
É exaustivo e o menos demorado.	Parcialmente demorado e exaustivo.	O tipo de teste mais exaustivo e demorado.
Não adequado para teste de algoritmo.	Não adequado para teste de algoritmo.	Adequado para teste de algoritmo.
Isso só pode ser feito pelo método de tentativa e erro.	Domínios de dados e limites internos podem ser testados, se conhecidos.	Domínios de dados e limites internos podem ser melhor testados.

Existem diferentes níveis durante o processo de teste. Neste capítulo, é fornecida uma breve descrição sobre esses níveis.

Os níveis de teste incluem diferentes metodologias que podem ser usadas durante a realização de testes de software. Os principais níveis de teste de software são -

• Teste funcional

• Teste Não Funcional

Teste funcional

Esse é um tipo de teste de caixa preta baseado nas especificações do software a ser testado. O aplicativo é testado fornecendo entrada e, em seguida, os resultados são examinados e precisam estar em conformidade com a funcionalidade para a qual foram destinados. O teste funcional de um software é conduzido em um sistema completo e integrado para avaliar a conformidade do sistema com seus requisitos especificados.

Existem cinco etapas envolvidas ao testar a funcionalidade de um aplicativo.

Passos	Descrição
Eu	A determinação da funcionalidade que o aplicativo pretendido deve executar.
II	A criação de dados de teste com base nas especificações do aplicativo.
III	A saída com base nos dados de teste e nas especificações do aplicativo.
IV	A escrita de cenários de teste e a execução de casos de teste.
V	A comparação dos resultados reais e esperados com base nos casos de teste executados.

Uma prática de teste eficaz verá as etapas acima aplicadas às políticas de teste de cada organização e, portanto, garantirá que a organização mantenha os mais rígidos padrões no que diz respeito à qualidade de software.

Teste de Unidade

Este tipo de teste é executado por desenvolvedores antes que a configuração seja entregue à equipe de teste para executar formalmente os casos de teste. O teste de unidade é executado pelos respectivos desenvolvedores nas unidades individuais das áreas atribuídas ao código-fonte. Os desenvolvedores usam dados de teste diferentes dos dados de teste da equipe de garantia de qualidade.

O objetivo do teste de unidade é isolar cada parte do programa e mostrar que as partes individuais estão corretas em termos de requisitos e funcionalidade.

Limitações do teste de unidade

O teste não consegue detectar todos os bugs em um aplicativo. É impossível avaliar cada caminho de execução em cada aplicativo de software. O mesmo acontece com o teste de unidade.

Há um limite para o número de cenários e dados de teste que um desenvolvedor pode usar para verificar um código-fonte. Depois de esgotar todas as opções, não há escolha a não ser interromper o teste de unidade e mesclar o segmento de código com outras unidades.

Teste de integração

O teste de integração é definido como o teste de partes combinadas de um aplicativo para determinar se funcionam corretamente. O teste de integração pode ser feito de duas maneiras: Teste de integração bottom-up e teste de integração Top-down.

Sr. Não.	Método de teste de integração
1	Bottom-up integration Esse teste começa com o teste de unidade, seguido por testes de combinações de unidades de nível mais alto progressivamente chamadas de módulos ou compilações.
2	Top-down integration Neste teste, os módulos de nível mais alto são testados primeiro e progressivamente, os módulos de nível mais baixo são testados depois.

Em um ambiente de desenvolvimento de software abrangente, o teste ascendente geralmente é feito primeiro, seguido pelo teste descendente. O processo termina com vários testes do aplicativo completo, de preferência em cenários projetados para simular situações reais.

Teste de Sistema

O teste do sistema testa o sistema como um todo. Depois que todos os componentes estão integrados, o aplicativo como um todo é testado rigorosamente para verificar se atende aos padrões de qualidade especificados. Este tipo de teste é realizado por uma equipe de testes especializada.

O teste do sistema é importante pelos seguintes motivos -

• O teste do sistema é a primeira etapa do Ciclo de Vida de Desenvolvimento de Software, em que o aplicativo é testado como um todo.

• O aplicativo é testado exaustivamente para verificar se atende às especificações funcionais e técnicas.

• O aplicativo é testado em um ambiente muito próximo ao ambiente de produção onde o aplicativo será implantado.

• O teste de sistema nos permite testar, verificar e validar tanto os requisitos de negócios quanto a arquitetura do aplicativo.

Teste de Regressão

Sempre que uma alteração em um aplicativo de software é feita, é bem possível que outras áreas dentro do aplicativo tenham sido afetadas por essa alteração. O teste de regressão é executado para verificar se um bug corrigido não resultou em outra funcionalidade ou violação de regra de negócios. A intenção do teste de regressão é garantir que uma mudança, como uma correção de bug, não resulte na descoberta de outra falha no aplicativo.

O teste de regressão é importante pelos seguintes motivos -

• Minimize as lacunas no teste quando um aplicativo com alterações feitas tiver que ser testado.

• Testar as novas mudanças para verificar se as mudanças feitas não afetaram nenhuma outra área do aplicativo.

• Reduz os riscos quando o teste de regressão é executado no aplicativo.

• A cobertura do teste é aumentada sem comprometer os prazos.

• Aumente a velocidade de comercialização do produto.

Teste de aceitação

Este é sem dúvida o tipo de teste mais importante, pois é conduzido pela Equipe de Garantia de Qualidade, que avaliará se a aplicação atende às especificações pretendidas e aos requisitos do cliente. A equipe de QA terá um conjunto de cenários pré-escritos e casos de teste que serão usados ​​para testar o aplicativo.

Mais ideias serão compartilhadas sobre o aplicativo e mais testes podem ser realizados nele para avaliar sua precisão e os motivos pelos quais o projeto foi iniciado. Os testes de aceitação não se destinam apenas a apontar erros ortográficos simples, erros cosméticos ou lacunas de interface, mas também a apontar quaisquer bugs no aplicativo que resultarão em travamentos do sistema ou erros graves no aplicativo.

Ao realizar testes de aceitação em um aplicativo, a equipe de teste reduzirá o desempenho do aplicativo na produção. Existem também requisitos legais e contratuais para aceitação do sistema.

Teste Alfa

Este teste é a primeira fase do teste e será realizado entre as equipes (equipes de desenvolvedor e QA). Os testes de unidade, de integração e de sistema, quando combinados, são conhecidos como testes alfa. Durante esta fase, os seguintes aspectos serão testados no aplicativo -

• Erros de ortografia

• Links quebrados

• Direções nubladas

• O aplicativo será testado em máquinas com a especificação mais baixa para testar os tempos de carregamento e quaisquer problemas de latência.

Teste beta

Este teste é executado após o teste alfa ter sido executado com sucesso. No teste beta, uma amostra do público-alvo testa o aplicativo. O teste beta também é conhecido comopre-release testing. Versões de teste beta do software são distribuídas idealmente para um grande público na Web, em parte para dar ao programa um teste do "mundo real" e em parte para fornecer uma prévia do próximo lançamento. Nesta fase, o público testará o seguinte -

• Os usuários irão instalar, executar o aplicativo e enviar seus comentários para a equipe do projeto.

• Erros de digitação, fluxo de aplicativo confuso e até mesmo travamentos.

• Obtendo o feedback, a equipe do projeto pode corrigir os problemas antes de lançar o software para os usuários reais.

• Quanto mais problemas você corrigir para resolver problemas reais do usuário, maior será a qualidade do seu aplicativo.

• Ter um aplicativo de qualidade superior quando você o lançar para o público em geral aumentará a satisfação do cliente.

Teste Não Funcional

Esta seção é baseada no teste de um aplicativo de seus atributos não funcionais. O teste não funcional envolve o teste de um software a partir dos requisitos que não são funcionais por natureza, mas são importantes, como desempenho, segurança, interface do usuário, etc.

Alguns dos tipos de teste não funcionais importantes e comumente usados ​​são discutidos abaixo.

Teste de performance

Ele é mais usado para identificar quaisquer gargalos ou problemas de desempenho, em vez de encontrar bugs em um software. Existem diferentes causas que contribuem para diminuir o desempenho de um software -

• Atraso de rede

• Processamento do lado do cliente

• Processamento de transação de banco de dados

• Balanceamento de carga entre servidores

• Renderização de dados

O teste de desempenho é considerado um dos tipos de teste importantes e obrigatórios em termos dos seguintes aspectos -

• Velocidade (ou seja, tempo de resposta, processamento de dados e acesso)

• Capacity

• Stability

• Scalability

O teste de desempenho pode ser qualitativo ou quantitativo e pode ser dividido em diferentes subtipos, como Load testing e Stress testing.

Teste de carga

É um processo de testar o comportamento de um software aplicando carga máxima em termos de software acessando e manipulando grandes dados de entrada. Isso pode ser feito em condições normais e de pico de carga. Este tipo de teste identifica a capacidade máxima do software e seu comportamento no horário de pico.

Na maioria das vezes, o teste de carga é executado com a ajuda de ferramentas automatizadas, como Load Runner, AppLoader, IBM Rational Performance Tester, Apache JMeter, Silk Performer, Visual Studio Load Test, etc.

Os usuários virtuais (VUsers) são definidos na ferramenta de teste automatizado e o script é executado para verificar o teste de carga do software. O número de usuários pode ser aumentado ou diminuído simultaneamente ou incrementalmente com base nos requisitos.

Teste de Estresse

O teste de estresse inclui testar o comportamento de um software sob condições anormais. Por exemplo, pode incluir retirar alguns recursos ou aplicar uma carga além do limite de carga real.

O objetivo do teste de estresse é testar o software aplicando a carga ao sistema e assumindo os recursos usados ​​pelo software para identificar o ponto de ruptura. Este teste pode ser realizado testando diferentes cenários, como -

• Desligamento ou reinicialização das portas de rede aleatoriamente

• Ligar ou desligar o banco de dados

• Executando diferentes processos que consomem recursos como CPU, memória, servidor, etc.

Testando usabilidade

O teste de usabilidade é uma técnica de caixa preta e é usado para identificar qualquer erro (s) e melhorias no software, observando os usuários durante seu uso e operação.

De acordo com Nielsen, a usabilidade pode ser definida em termos de cinco fatores, ou seja, eficiência de uso, capacidade de aprendizado, capacidade de memória, erros / segurança e satisfação. Segundo ele, a usabilidade de um produto será boa e o sistema é utilizável se possuir os fatores acima.

Nigel Bevan e Macleod consideraram que usabilidade é o requisito de qualidade que pode ser medido como o resultado de interações com um sistema de computador. Este requisito pode ser atendido e o usuário final ficará satisfeito se os objetivos pretendidos forem alcançados de forma eficaz com o uso de recursos adequados.

Molich em 2000 afirmou que um sistema amigável deve cumprir os cinco objetivos a seguir, ou seja, fácil de aprender, fácil de lembrar, eficiente de usar, satisfatório de usar e fácil de entender.

Além das diferentes definições de usabilidade, existem alguns padrões e modelos e métodos de qualidade que definem usabilidade na forma de atributos e subatributos, como ISO-9126, ISO-9241-11, ISO-13407 e IEEE std. 610,12, etc.

IU vs Teste de Usabilidade

O teste de IU envolve o teste da Interface Gráfica do Usuário do Software. O teste de IU garante que a GUI funcione de acordo com os requisitos e testados em termos de cor, alinhamento, tamanho e outras propriedades.

Por outro lado, o teste de usabilidade garante uma GUI boa e amigável que pode ser facilmente manuseada. O teste de IU pode ser considerado uma subparte do teste de usabilidade.

Teste de Segurança

O teste de segurança envolve testar um software para identificar quaisquer falhas e lacunas do ponto de vista de segurança e vulnerabilidade. Listados abaixo estão os principais aspectos que os testes de segurança devem garantir -

• Confidentiality

• Integrity

• Authentication

• Availability

• Authorization

• Non-repudiation

• O software é seguro contra vulnerabilidades conhecidas e desconhecidas

• Os dados do software estão seguros

• O software está de acordo com todos os regulamentos de segurança

• Verificação e validação de entrada

• Ataques de inserção SQL

• Falhas de injeção

• Problemas de gerenciamento de sessão

• Ataques de script entre sites

• Vulnerabilidades de estouro de buffer

• Ataques de passagem de diretório

Teste de portabilidade

O teste de portabilidade inclui o teste de um software com o objetivo de garantir sua reutilização e que também possa ser movido de outro software. A seguir estão as estratégias que podem ser usadas para testes de portabilidade -

• Transferir um software instalado de um computador para outro.

• Construir executável (.exe) para executar o software em diferentes plataformas.

O teste de portabilidade pode ser considerado uma das subpartes do teste de sistema, pois esse tipo de teste inclui o teste geral de um software com relação ao seu uso em diferentes ambientes. Hardware de computador, sistemas operacionais e navegadores são o foco principal dos testes de portabilidade. Algumas das pré-condições para o teste de portabilidade são as seguintes -

• O software deve ser projetado e codificado levando em consideração os requisitos de portabilidade.

• O teste de unidade foi executado nos componentes associados.

• O teste de integração foi executado.

• O ambiente de teste foi estabelecido.

A documentação de teste envolve a documentação de artefatos que devem ser desenvolvidos antes ou durante o teste do Software.

A documentação para teste de software ajuda a estimar o esforço de teste necessário, cobertura de teste, rastreamento / rastreamento de requisitos, etc. Esta seção descreve alguns dos artefatos documentados comumente usados ​​relacionados a testes de software, como -

• Plano de teste
• Cenário de Teste
• Caso de teste
• Matriz de rastreabilidade

Plano de teste

Um plano de teste descreve a estratégia que será usada para testar um aplicativo, os recursos que serão usados, o ambiente de teste no qual o teste será executado e as limitações do teste e o cronograma das atividades de teste. Normalmente, o líder da equipe de garantia de qualidade será responsável por escrever um plano de teste.

Um plano de teste inclui o seguinte -

• Introdução ao documento do Plano de Teste
• Suposições ao testar o aplicativo
• Lista de casos de teste incluídos no teste do aplicativo
• Lista de recursos a serem testados
• Que tipo de abordagem usar ao testar o software
• Lista de entregas que precisam ser testadas
• Os recursos alocados para testar o aplicativo
• Quaisquer riscos envolvidos durante o processo de teste
• Uma programação de tarefas e marcos a serem alcançados

Cenário de Teste

É uma instrução de uma linha que notifica qual área do aplicativo será testada. Os cenários de teste são usados ​​para garantir que todos os fluxos do processo sejam testados de ponta a ponta. Uma área específica de um aplicativo pode ter de apenas um cenário de teste a algumas centenas de cenários, dependendo da magnitude e da complexidade do aplicativo.

Os termos 'cenário de teste' e 'casos de teste' são usados ​​alternadamente, no entanto, um cenário de teste tem várias etapas, enquanto um caso de teste tem uma única etapa. Visto dessa perspectiva, os cenários de teste são casos de teste, mas incluem vários casos de teste e a sequência em que devem ser executados. Além disso, cada teste depende da saída do teste anterior.

Caso de teste

Os casos de teste envolvem um conjunto de etapas, condições e entradas que podem ser usadas durante a execução de tarefas de teste. O objetivo principal desta atividade é garantir que um software seja aprovado ou reprovado em termos de funcionalidade e outros aspectos. Existem muitos tipos de casos de teste, como funcional, negativo, erro, casos de teste lógicos, casos de teste físicos, casos de teste de IU, etc.

Além disso, os casos de teste são escritos para controlar a cobertura de teste de um software. Geralmente, não há modelos formais que podem ser usados ​​durante a escrita do caso de teste. No entanto, os seguintes componentes estão sempre disponíveis e incluídos em cada caso de teste -

• ID do caso de teste
• Módulo de produto
• Versão do produto
• Histórico de Revisão
• Purpose
• Assumptions
• Pre-conditions
• Steps
• Resultado esperado
• Resultado real
• Post-conditions

Muitos casos de teste podem ser derivados de um único cenário de teste. Além disso, às vezes, vários casos de teste são escritos para um único software, que são coletivamente conhecidos como suítes de teste.

Matriz de rastreabilidade

A Matriz de Rastreabilidade (também conhecida como Matriz de Rastreabilidade de Requisito - RTM) é uma tabela usada para rastrear os requisitos durante o Ciclo de Vida de Desenvolvimento de Software. Ele pode ser usado para rastreamento direto (ou seja, de Requisitos para Projeto ou Codificação) ou para trás (ou seja, de Codificação para Requisitos). Existem muitos modelos definidos pelo usuário para RTM.

Cada requisito no documento RTM está vinculado ao seu caso de teste associado para que o teste possa ser feito de acordo com os requisitos mencionados. Além disso, o Bug ID também está incluído e vinculado a seus requisitos e casos de teste associados. Os principais objetivos desta matriz são -

• Certifique-se de que o software seja desenvolvido de acordo com os requisitos mencionados.
• Ajuda a encontrar a causa raiz de qualquer bug.
• Ajuda no rastreamento dos documentos desenvolvidos durante as diferentes fases do SDLC.

Estimar os esforços necessários para o teste é uma das tarefas principais e importantes no SDLC. A estimativa correta ajuda a testar o software com cobertura máxima. Esta seção descreve algumas das técnicas que podem ser úteis na estimativa dos esforços necessários para o teste.

Análise de Ponto Funcional

Este método é baseado na análise dos requisitos funcionais do usuário do software com as seguintes categorias -

• Outputs
• Inquiries
• Inputs
• Arquivos internos
• Arquivos externos

Análise de Ponto de Teste

Este processo de estimativa é usado para análise de ponto de função para caixa preta ou teste de aceitação. Os principais elementos deste método são: Tamanho, Produtividade, Estratégia, Interface, Complexidade e Uniformidade.

Método Mark-II

É um método de estimativa usado para analisar e medir a estimativa com base na visão funcional do usuário final. O procedimento para o método Mark-II é o seguinte -

• Determine o ponto de vista
• Objetivo e tipo de contagem
• Defina o limite da contagem
• Identifique as transações lógicas
• Identifique e categorize os tipos de entidade de dados
• Conte os tipos de elementos de dados de entrada
• Conte o tamanho funcional

Diversos

Você pode usar outras técnicas de estimativa populares, como -

• Técnica Delphi
• Estimativa Baseada em Analogia
• Estimativa baseada em enumeração de caso de teste
• Estimativa baseada em tarefas (atividades)
• Método IFPUG