Testes de Software Resumo Livro Proprietário

Prévia do material em texto

Testes de Software – Resumo Livro Proprietário
1. Importância do teste de software 
1.1 Introdução a teste de software
Para iniciar a discussão gostaríamos que você pensasse na seguinte pergunta:
 “Você conhece um software de qualidade?”
Independente da sua resposta ser SIM ou NÃO, gostaria que você pensasse no que levou você a dar esta resposta. “No que você se baseou para julgar a qualidade do software? O que é qualidade de software? Como será que se faz para atingir qualidade de um software?”.
Qualidade de Software têm como objetivo garantir que requisitos de qualidade de software sejam satisfeitos pelo software. 
Seguindo Pressman (PRESSMAN, 2006):
“Qualidade de software é a conformidade com requisitos funcionais e de desempenho explicitamente declarados, normas de desenvolvimento explicitamente documentadas e características implícitas que são esperadas em todo software desenvolvido profissionalmente”.
Pressman (PRESSMAN, 2006) reforça que o time de SQA deve olhar para o
software procurando ter o ponto de vista do cliente, procurando sempre responder perguntas como:
• O software satisfaz critérios de qualidade? Confiabilidade, usabilidade, disponibilidade, etc;
• O desenvolvimento do software foi conduzido de acordo com padrões preestabelecidos?
• As disciplinas técnicas desempenharam seu papel de forma adequada como parte das atividades de SQA?
Todos, sem exceção, são responsáveis pela qualidade do produto de software.
Do ponto de vista técnico, temos duas atividades de extrema importância
para garantir a qualidade de um software: verificação e validação – conhecidas
como atividades de V&V.
Seguindo Pressman (PRESSMAN, 2006):
Verificação - Atividades para responder à pergunta: “Estamos construindo o produto corretamente?”;
Validação - Atividades para responder à pergunta: “Estamos construindo o produto certo?”.
Além de classificadas como verificação e/ou validação, as atividades V&V são classificadas como estáticas e dinâmicas. 
Atividades estáticas são aquelas que não dependem de um artefato executável para serem realizadas. Em outras palavras, não é necessário ter um código fonte para realizar atividades de V&V estáticas.
Atividades dinâmica são aquelas que dependem de um artefato executável para serem realizadas. Em outras palavras, é necessário ter um código fonte executável para realizar atividades de V&V dinâmicas.
As atividades de V&V são tipicamente executadas usando uma ou mais das quatro técnicas listadas a seguir:
Análise - Que é o uso de técnicas ou modelos matemáticos, simulações algoritmos ou procedimentos científicos para determinar se o produto ou artefato está em conformidade com seus requisitos.
Demonstração - É um exame visual do produto de software sendo executado em um cenário específico a fim de identificar se ele está em conformidade com os requisitos. As famosas “demos” são um exemplo dessas demonstrações.
Inspeção - É uma examinação visual (comumente envolvendo a manipulação manual dos artefatos) de um artefato não executável, novamente para identificar a conformidade do artefato com seus requisitos.
Teste - É a simulação de um artefato executável com entradas e pré-condições conhecidas e a comparação entre a saída atual e a saída esperada para determinar se o artefato está em conformidade com os requisitos.
Pressman (PRESSMAN, 2006) reforça que a atividade de teste é o último reduto no qual a qualidade do software pode ser avaliada e defeitos podem ser identificados antes de serem entregues ao usuário final.
Podemos dizer que a análise e inspeção são técnicas essencialmente estáticas e que demonstração e teste são técnicas dinâmicas – as duas primeiras não exigem que se tenha um artefato executável para serem aplicadas, enquanto que as duas últimas dependem de um artefato.
1.2 Termos & conceitos sobre teste
Myers (MYERS, 2004) define que “Teste é o processo de executar um programa ou sistema com a intenção de encontrar erros”.
Talvez você pense imediatamente: “Uma solução para não ter problema no software é testar todas as possibilidades.” Afinal, dessa forma, nós podemos garantir que todas as funcionalidades foram executadas de todas as formas possíveis e como consequência, todos os defeitos foram encontrados.
Isso é o que chamamos de teste exaustivo. Pezzè e Young (PREZZÈ e YOUNG, 2007) ressaltam que o teste exaustivo pode ser considerado uma autêntica “prova por casos”.
No entanto, os mesmos autores levantam um ponto importante: 
Quanto tempo levaria para ser executado um teste exaustivo? 
Além da impossibilidade de testar por exaustão, ainda temos o impacto da escolha dos dados corretos, pois um conjunto de dados pode fazer com que o defeito seja identificado, e outro conjunto de dados pode fazer com que o defeito nunca seja identificado.
Considerando a impossibilidade de testar por exaustão, nós devemos aplicar os critérios de teste, que nos ajudam, entre outras coisas, a definir melhor nossos casos de testes e os dados de entrada a fim de identificar defeito.
PERGUNTA
Mas, afinal, o que é caso de teste?
Casos de teste é uma sequência de passos que devem ser executados no sistema, sendo que os dados de entrada e saída esperada para cada passo são especificados. A prática nos diz que os casos de teste devem “direcionar” as ações do testador em uma determinada funcionalidade e fazer com que ele observe se o resultado que ele obtém em cada passo é o resultado esperado, de acordo com os requisitos.
A norma (IEEE 829-2008, 2008) menciona que um caso de teste deve conter:
1. IDENTIFICADOR DO CASO DE TESTE
Número único de identificação do caso de teste em questão.
2. OBJETIVO DO CASO DE TESTE
Mostra de forma breve qual é a intenção de teste do caso de teste.
3. ENTRADAS
Todas as entradas que serão consideradas no caso de teste.
4. SAÍDAS
As saídas esperadas de acordo com as entradas indicadas na execução dos testes.
5. AMBIENTES NECESSÁRIOS OU CONDIÇÕES DE AMBIENTE
Quais ambientes de hardware e software, inclusive com versionamentos, que devem ser montados para o caso de teste em questão.
6. PROCEDIMENTOS ESPECIAIS REQUISITADOS PARA EXECUÇÃO DO CASO DE TESTE
Como o analista de teste deve proceder para a execução do caso de teste em questão. Deve especificar com detalhes o que deve ser testado e a forma que o teste deve ser executado.
7. DEPENDÊNCIA COM OUTROS CASOS DE TESTE
No caso deste caso de teste estar relacionado com outro caso de teste, então, especificar este relacionamento aqui.
Pensando no exemplo, um caso de teste possível seria:
1. Caso de teste 1: entrada negativa
2. Verificar se entradas negativas são possíveis
3. (E) Digite “- 30000”
4. (S) 0,99
5. Nenhum
6. Nenhum
7. Não
Uma sugestão de como reportar um defeito é (ISTQB, 2016):
• Identificador do defeito: todo defeito deve ter um identificar único para facilitar a comunicação e localização;
• Descrição do defeito: uma descrição sucinta do defeito encontrado
• Versão do produto: para saber em qual versão do sistema o defeito foi encontrado;
• Passos detalhados: descrição de passos realizados no sistema, incluindo
os dados utilizados para encontrar o defeito. 
• Data de reporte do defeito: para facilitar o gerenciamento;
• Reportado por: para saber qual o testador identificou o defeito;
• Status: aqui, diferentes nomes podem ser aplicados, mas o objetivo é permitir que todos os envolvidos saibam se o defeito já foi endereçado, analisado, corrigido, se tem algum desenvolvedor encarregado de arrumar o programa, se o testador já viu a resolução e assim por diante.
• Corrigido por: Nome do desenvolvedor que corrigiu o defeito;
• Data de encerramento: a data que o defeito foi dado como inexistente;
• Severidade: para informar quão grave é o defeito no sistema, como por exemplo, bloqueia a versão, crítico, pequeno;
• Prioridade: para definir a prioridade em corrigir o defeito: alta, média ou baixa.
Outro conceito importante no contexto de teste é o conceito de cenário de teste. De acordo com a normaIEEE 829-2008 (IEEE 829-2008, 2008), cenário de teste é um conjunto de casos de teste relacionados, que comumente testam o mesmo componente ou a mesma funcionalidade do sistema.
Cenários de caso de teste também chamados de suítes ou ciclos de teste.
A definição da norma ISO/IEC/IEEE 24765:2010 (ISO/IEC/IEEE 24765, 2010), estabelece que:
Engano (Mistake) - Uma ação humana que produz um resultado incorreto, como uma codificação ou modelagem errada;
Defeito (Fault) - Uma imperfeição ou deficiência em um artefato que faz com que este não esteja em conformidade com os requisitos ou especificações, sendo necessária sua correção ou substituição. Termos como “erro” e “bug” comumente são usados para expressar defeitos;
Erro (Error) - Resultado incoerente produzido por meio de uma ação no sistema;
Falha (Failure) - Incapacidade do software exercer a função para a qual foi desenvolvido.
Sendo assim, engano introduz um defeito que quando é exercitado, idealmente por meio da execução de um caso de teste, produz um erro no sistema e esse erro, consequentemente, faz com que o sistema falhe.
1.3 O teste nas fases de vida e de desenvolvimento de um software
Se relembrarmos os principais modelos de processo, veremos que todos incluem a atividade de teste.
2. Teste no programa
Na grande maioria dos sistemas os requisitos não são executáveis e uma forma de garantir a qualidade deles é por meio de atividades V&V de inspeção, como revisões técnicas formais.
Revisões técnicas não são exclusividade de requisitos – essas atividades podem ser aplicadas em todos os artefatos produzidos durante o ciclo de vida de um sistema, incluindo código-fonte.
As revisões técnicas formais, de acordo com (Pressman, Engenharia de Software - Uma abordagem profissional, 2011) podem ser vistas como um filtro para o processo de engenharia de software, afinal, ao revisar um artefato, ou seja, uma representação do software, seja ela visual ou textual, e corrigir possíveis defeitos, o próximo artefato e ser construído tendo o artefato revisado como base não irá propagar esse defeito. Exemplo: ao inspecionar um documento de requisito, identificar e corrigir os defeitos, ao definir o diagrama de casos de uso, esses defeitos não serão mais propagados, tornando o custo de correção menor, pois isso é feito apenas em um artefato.
2.2 Observando cenários da vida real
(Exemplo fictício para apresentar o próximo tópico)
2.3 Técnica de testes, o que é isso?
O que determina a técnica a ser usada é a necessidade da equipe, do cliente, as características do software, a estratégia de teste que foi planejada e principalmente o dado do software ao qual você tem acesso – afinal, nem sempre temos acesso ao código fonte de um software, mas nem por isso temos que deixar de testá-lo.
A norma ISO/IEC/IEEE 29119-4 (ISO/IEC/IEEE 29119-4, 2015) define três técnicas de teste:
• Técnica baseada em especificação, que é a técnica caixa preta, também conhecida como técnica funcional;
• Técnica baseada em estrutura, que é a técnica caixa branca, também conhecida como técnica estrutural;
• Técnica baseada em experiência, que é a técnica baseada em erros.
2.4 Teste caixa preta, o teste funcional
Essa técnica pode ser adotada quando a equipe de teste tem acesso a especificação do sistema.
Como o próprio nome indica, essa técnica de teste considera que o sistema a ser testado é uma caixa preta – você não sabe o que tem dentro, só sabe o que precisa colocar dentro da caixa e o que você espera que sala da caixa.
Você sabe os dados que devem colocar dentro da caixa, considerando a especificação das funcionalidades que devem estar implementadas no software, e você também sabe qual a saída de dados esperada.
No entanto, na seção sobre termos e conceitos sobre teste, nós vimos que alguns defeitos são encontrados dependendo da entrada de dados que é usada no teste. Vimos também que teste por exaustão é algo quase impossível.
Para ajudar existe o que chamamos de critérios de teste.
Os critérios de teste servem para ajudar a definir, selecionar ou revisar os casos de teste a fim de aumentar as possibilidades de identificação de defeitos e estabelecer um nível elevado de confiança dos testes. Em outras palavras, como não é possível testar todas as possibilidades, os critérios ajudam a definir um conjunto finito de casos de teste que potencialmente podem identificar defeitos – critérios de teste nos dizem quando parar de definir casos de teste.
Para entendermos melhor, vamos pensar da seguinte forma: imagine um critério de teste fictício chamado “Critério dos números primos menores que 20”. Esse critério diz que toda funcionalidade que requer entrada de números inteiros deve ser testada usando todos os números primos menores que 20 (lembre-se, é apenas um exemplo). Sendo assim, o requisito desse critério é: temos que definir casos de teste que considerem como entrada os números 2, 3, 5, 7, 11, 13, 17 e 19. Se formos nos basear em um conjunto existente de casos de teste, temos que analisar quais números já estão sendo considerados e determinar, se necessário, quais casos de teste devem ser definidos. Se não tivermos casos de teste para esses números, não estamos em conformidade com os requisitos do critério de teste.
Considerando que temos técnicas diferentes de teste – uma baseada em código e outra baseada em funcionalidade – os critérios de teste também são diferentes para testes caixa branca e caixa preta.
Os principais critérios de teste caixa preta são: Particionamento de Equivalência e Análise do Valor limite.
• Particionamento de Equivalência
Partições de equivalência é quando qualquer valor, dentro de um dado intervalo, tem a mesma importância (Myers, 2004). Se a condição de entrada mencionada no requisito especifica um membro de um conjunto (por exemplo, um valor a ser selecionado a partir de uma lista, valor maior que 40) ou uma condição boolena (sim/não, verdadeiro/falso etc.) devemos definir uma classe válida e uma inválida (Fabbri, 2009).
Para esse contexto, temos uma classe válida e uma inválida: classe válida: valor maior que 40; classe inválida; valor menor que 40. Dessa forma, devemos definir dois casos de teste - um no qual o valor de entrada seja maior que 40; um no qual o valor de entrada seja menor que 40.
• Análise do valor limite
O critério de análise do valor limite é complementar ao Particionamento de Equivalência. O requisito do critério análise do valor imite é definir casos de teste para valores de entrada que estão no limite das classes de equivalência.
– O valor 40 – que está entre as classes de equivalência;
– O valor 100 – poderia ser o limite da entrada.
Devemos lembrar que quanto mais custoso de aplicar um critério de teste, ou seja, quanto mais casos de teste o critério definir, mais defeitos ele tende a identificar – a competência está em identificar o mínimo suficiente para encontrar defeitos sem que o projeto atrase e sem que defeitos críticos cheguem no usuário final.
2.5 Teste caixa branca, o teste estrutural
Essa técnica pode ser adotada quando a equipe de teste tem acesso ao código fonte do sistema.
Como o próprio nome indica, essa técnica de teste considera que o sistema a ser testado é uma caixa branca – você sabe exatamente o que tem dentro da caixa. Você continua tendo que saber o que precisa colocar dentro da caixa e o que você espera que saia da caixa, como fazemos no teste caixa preta, mas a grande diferença aqui é que você define “o que colocar dentro da caixa” com
base no que tem dentro da caixa.
Você sabe os dados que deve colocar dentro da caixa e sabe qual a saída de dados esperada, mas nessa técnica, você decide os dados a serem inseridos na caixa com base no código fonte do sistema.
De acordo com Myers (Myers, 2004), na técnica estrutural o objetivo do testador é se preocupar com o comportamento de cada uma das estruturas internas do programa. Em outras palavras, a preocupação é com a lógica que foi implementada. Quando não há especificação do sistema, essapode ser uma das formas possíveis de testar o que foi implementado.
Para facilitar a definição dos casos de teste da técnica caixa branca (estrutural), a maioria dos critérios dessa técnica é uma representação visual do código a ser testado, chamado de Grafo de Fluxo de Controle ou apenas Grafo do Programa.
O Grafo de Fluxo de Controle nada mais é que um conjunto de nós conectados por arcos com setas que mostram sua direção – os nós representam um bloco de comando (isso é, uma sequência atômica de linhas de código – se uma for executada, todas as outras serão) e os arcos indicam a precedência ou a transferência de controle (a sequência de execução do código fonte e seus desvios).
Se observarmos, um programa de computador é uma grande combinação dessas estruturas (Maldonado & Fabbri, 2001). 
Os critérios de teste da técnica caixa branca são divididos em Teste Baseado em Fluxo de Controle e Teste Baseado em Fluxo de Dados.
Os principais critérios de teste caixa branca Baseado em Fluxo de Controle são Teste de Comandos e Teste de Ramos.
• Teste de Comandos ou Teste Todos os nós
Esse critério de teste define como requisito de teste que todos os comandos dos programas sejam executados ao menos uma vez. Ou seja, se olharmos para o grafo de fluxo e controle de um programa, temos que criar casos de teste de forma que todos os nós sejam exercitados ao menos uma vez.
• Teste de Ramos ou Todas as Arestas ou Todos os Arcos
Esse critério de teste define como requisito de teste que todas as condições verdadeiras e falsas do programa sejam executadas. Em outras palavras, todos os arcos (também chamados de arestas) do grafo de fluxo de controle devem ser exercitados, mesmo que para isso, o mesmo nó seja executado mais de uma vez (Maldonado & Fabbri, 2001).
Para sabermos o número de casos de teste necessários para atingir o critério de Ramos, basta identificarmos os caminhos que farão com que cada arco seja executado ao menos uma vez – sendo assim, cinco casos de teste nos ajudam a cumprir essa missão. Exemplo de sequências:
CT 1) 1-2-4-5-14;
CT 2) 1-2-4-5-9-10-9-11-12-13-14
CT 3) 1-2-4-6-9-11-12-13-12-13-14
CT 4) 1-3-4-7-9-10-9-11-12-13-14
CT 5) 1-3-4-8-9-10-9-11-12-13-14
O principal critério de teste caixa branca Baseado em Fluxo de Dados é Todos os Usos.
• Todos os usos
Esse critério de teste define como requisito de teste que todos os usos das variáveis utilizadas em cada comando sejam executados.
Depois de reportar os defeitos de maneira adequada, uma outra atividade deve ser conduzida – a depuração.
2.6 Depuração
De forma geral podemos dizer que depurar é o processo de executar o software e/ou percorrer o código fonte até entender o defeito previamente encontrado e identificar o que causa o defeito para que a correção seja feita. Sendo assim, temos uma constatação importante: a atividade de depuração é consequência de um teste bem-sucedido, afinal, se a depuração é necessária, é porque um defeito foi encontrado durante os testes do sistema.
Meyer (1979) propôs três abordagens para executar a depuração: força bruta, rastreamento e eliminação de causa.
FORÇA BRUTA
Tenta-se utilizar o próprio computador para a descoberta, inserindo, por exemplo, vários comandos de escrita no programa (mensagens na tela com valores internamente utilizados), listagem de memória, rastreadores de execução etc.
RASTREAMENTO (CONHECIDO COMO BACKTRACKING)
Nessa abordagem a busca pelo problema inicia-se no local em que o sintoma foi detectado e rastreia-se o software (comumente o código fonte) para trás, manualmente, até que o local da causa seja encontrado.
ELIMINAÇÃO DE CAUSA
Nessa abordagem a pessoa (ou o time) que está depurando o sistema supõe uma causa e casos de teste são elaborados para comprovar ou refutar essa hipótese/suposição.
2.7 Teste de ambiente web
Pressman (Pressman, Engenharia de Software, 2006) salienta estratégias de teste que devem ser consideradas no ambiente web; teste de conteúdo, teste de interface, teste de navegação, teste de componente, teste de configuração, de segurança e de desempenho.
3. Teste na implantação do sistema
3.1 Estratégia de teste
Um dos modelos básicos, que serviu de inspiração para muitos autores proporem modelos mais detalhados e que ilustra muito bem a estratégia básica de teste e como ela adere a um processo de desenvolvimento é o apresentado por Pressman (PRESSMAN, 2006) e está ilustrado na figura 3.1.
Nesse modelo, o processo de engenharia de software básico é apresentado como um espiral, que engloba também as estratégias de teste que podem ser utilizadas em cada atividade do processo de engenharia.
Pois bem, se pensarmos que a atividade de teste deve acompanhar todo o desenvolvimento do software, é natural pensarmos que cada artefato gerado durante o desenvolvimento do software dê origem ou sirva de base para executarmos diferentes estratégias de teste.
Olhando novamente na figura, conseguimos fazer um paralelo de cada atividade de desenvolvimento com as estratégias básicas de teste. Porém, para os testes, ao contrário de irmos caminhando para o centro do espiral, vamos caminhando para sair do espiral.
Com o sistema codificado, ou seja, com o código fonte, podemos criar os testes unitários. Com as “unidades” testadas, podemos executar testes de integração, ou seja, testar um conjunto de unidades e verificar se juntas elas funcionam da forma como deveriam e foram arquitetadas. Com o conjunto de unidades funcionando e continuando a caminhada para fora do espiral, executamos
o teste de validação, com o intuito de verificar se os requisitos previamente definidos estão sendo satisfeitos no sistema desenvolvido. Por fim, executamos testes no sistema como um todo, a fim de verificar se o software e todos os outros elementos do sistema funcionam como o esperado e atingem o objetivo final.
3.2 Teste de Unidade
De acordo com (PRESSMAN, 2006), o teste de unidade dedica esforço de teste para identificar defeitos na menor unidade do sistema, que pode ser um componente, um módulo ou, considerando o paradigma orientado a objetivo, que é o mais comum hoje em dia, uma classe ou um método.
De acordo com Myers (MYERS, 2004), as vantagens de se realizar testes unitários são:
• Os testes unitários são uma forma de gerenciar de maneira mais fácil os elementos de testes (casos de teste, resultado etc.), uma vez que a atenção é focada inicialmente em unidades menores do programa;
• Os testes unitários facilitam a tarefa de depuração (que vimos no capítulo 2), uma vez que, quando um defeito for encontrado, o escopo de depuração é menor, afinal, sabemos em qual unidade ele foi encontrado;
• Permite que a atividade de teste seja feita de forma paralela, pois várias unidades podem ser testadas simultaneamente.
Como em outras situações, a opção de usar a técnica funcional ou estrutural depende dos artefatos que o testador tem em mãos. No entanto, o teste unitário, por considerar a menor unidade do sistema, está intimamente relacionado à fase de codificação do software e por isso, pensar em critérios estruturais pode ser mais fácil nesse momento.
Além disso, há técnicas de desenvolvimento como o TDD (Test Driven Development) (BECK, 2003) (SOMMERVILLE, 2011) que prevê que os testes sejam programados antes mesmo da unidade a ser testada.
Quando vamos criar testes unitários, comumente precisamos criar pseudocontroladores, também conhecidos como drivers, e pseudocontrolados, também conhecidos como stubs.
(PRESSMAN, 2006).
O driver cumpre o papel da unidade que “chama” a unidade a ser testada. Já o stub faz o papel das outras unidades que são “chamadas” pela nossa unidade.
Dica: relacionada ao JUnit, que é uma ferramenta para automatizar o teste unitário para programas feitos em Java.
3.3 Teste de Integração
As unidades estando livres de defeito não garantem que o sistema esteja livre de defeitos. O sistema, de certa forma, é a integração de todas as unidades e assim, precisamos testar essa integração.
Para Pressman (PRESSMAN,2006) o teste de integração é uma maneira sistemática de construir a arquitetura do software e identificar defeitos associados às interfaces (interface, aqui, se refere a forma como as unidades se comunicam, e não a interface gráfica do sistema).
Myers (MYERS, 2004) apresenta duas formas de teste de integração. Uma forma é a conhecida como integração big-bang, que é testar os módulos/unidades de forma independente e depois combinar todas as unidades, compor o programa e então testar a integração entre eles. Outra forma é a integração incremental, que combina um módulo previamente testado de forma unitária com um conjunto de módulos no qual o teste de integração já foi feito. Após testar esse novo conjunto, um outro módulo é agregado e assim por diante, até compor o sistema por completo.
A integração big-bang pode até funcionar em alguns casos, mas sua principal desvantagem é a dificuldade em isolar em qual unidade está o defeito encontrado na integração. Já na integração incremental, como podemos imaginar, essa identificação fica mais fácil de ser feita, pois as unidades vão sendo acrescentadas uma de cada vez.
Optando em realizar teste de integração incremental, temos duas abordagens: uma é a abordagem de teste incremental top-down (ou integração descendente) e a outra abordagem é teste incremental bottom-up (ou integração ascendente).
Na abordagem top-down a ideia é escolher uma unidade principal e ir adicionando unidades “abaixo” dela.
Para fazer essa integração e de certa forma ir construindo a árvore que é o sistema (como vemos em estrutura de dados) pode-se optar em caminhar em largura ou profundidade. (PRESSMAN, 2006) (SOMMERVILLE, 2011)
Na abordagem de integração bottom-up a ideia é testar a integração de maneira oposta, ou seja, de baixo para cima. Para isso, é necessário identificar módulos ou conjunto de módulos/unidades que sejam altamente dependentes e com isso definir o que é chamado de clusters, construções ou aglomerados.
Para entender melhor, vamos observar a figura, na qual temos 3 clusters definidos. Como podemos ver, eles são um conjunto de unidades atômicas, ou seja, não funciona isoladamente, o que é muito comum nas unidades mais básicas, módulos abaixo na arquitetura de integração do sistema – por exemplo, o cadastro de produto em um sistema de loja não funciona sem o cadastro de tipo de produto.
Para testar o cluster 1, precisamos de uma unidade para “exercitar” essas unidades aglomeradas. Executamos os casos de teste e assim, garantimos que defeitos foram encontrados no cluster. O mesmo se repete com os clusters 2 e 3.
Esse processo se repete até que a unidade central (provavelmente a que daria início aos testes na abordagem top-down) se integre a todos os testes de integração que tenham sido executados.
Quando falamos em teste de integração, outra estratégia de teste entra em pauta: teste de regressão.
Pode ser possível que ao testar uma funcionalidade de U1 uma funcionalidade do que está no cluster 1 se comporte de maneira não esperada. Obviamente esse risco também existe na abordagem top-down.
De acordo com Pressman (PRESSMAN, 2006), teste de regressão é a reexecução de testes que já foram executados anteriormente com o objetivo de garantir que as novas integrações não tenham efeitos indesejados – ou seja, defeitos.
Pressman (PRESSMAN, 2006), apresenta três classes de testes de integração que, de certa forma, ajudam na escolha de quais testes irão compor o ciclo de regressão. Vamos a eles:
1. Um conjunto representativo de casos de teste que representam/exercitam todas as funcionalidades do sistema;
2. Casos de teste que testam especificamente partes que podem ser afetadas com as mudanças e/ou adição de novas unidades;
3. Casos de teste que possuem como foco testar a nova unidade ou unidade modificada.
3.4 Teste de validação
Após testar as unidades e a integração das unidades/módulos, podemos pensar que o sistema está pronto para ser utilizado. Nesse ponto, lembramos de uma figura de extrema importância para um sistema: o usuário.
Com o sistema integrado, é o momento de exercitar o sistema como se fossemos os usuários.
De acordo com Pressman (PRESSMAN, 2011), o teste de validação tem como foco as ações dos usuários e as saídas dos sistemas conhecidas pelo usuário. Outra boa definição é a que teste de validação determina se o sistema está em conformidade com os requisitos definidos, se contempla as funcionalidades para o qual foi desenvolvido e satisfaz os objetivos e necessidades do usuário
(ISTQB, 2016).
Como podemos imaginar um testador não pode ter a pretensão de garantir que os testes de validação irão repetir exatamente o comportamento do usuário. Sendo assim, testes alfa e beta podem ser considerados como uma estratégia de teste, com o objetivo de ter a oportunidade dos usuários reais identificarem defeitos.
Entende-se por testes alfa, o teste realizado no ambiente de desenvolvimento por equipes de técnicos independentes ou por usuários em potencial, e testes beta, o teste realizado em ambiente real por um grupo seleto ou reduzido de usuários reais.
3.5 Teste de sistema
PERGUNTA
Será que o software devidamente testado usando as estratégias de teste unitário, integração e validação, funcionará da mesma maneira em qualquer ambiente?
Isso ressalta a importância de especificarmos o ambiente mínimo que o sistema deve funcionar e também conhecer o usuário final e o sistema no qual o software deverá funcionar, pois assim, podemos executar os testes de sistemas.
Para Pressman (PRESSMAN, 2006), Testes de Sistemas é um conjunto de testes executados com o objetivo de exercitar todos os componentes que fazem parte do sistema informatizado, ou seja, um sistema que depende de um software. Apesar de cada teste ter um objetivo específico, o objetivo comum é identificar, caso exista, defeitos ao exercitar todos os componentes do sistema em conjunto com o software, que teve suas unidades devidamente testadas, integradas e seus requisitos validados.
Testes comumente executados na estratégia de teste de sistema são (PRESSMAN, 2006):
TESTE DE SEGURANÇA
Verifica se o sistema foi desenvolvido considerando mecanismos de proteção e se esses mecanismos serão suficientes para proteger uma possível invasão ou uso indevido das informações. Nesse momento, o testador deve atuar como um hacker e fazer de tudo para invadir o sistema. Tendo feito a invasão, identifica-se o problema e o sistema é melhorado.
TESTES DE RECUPERAÇÃO
Verifica como o software, no contexto do sistema, se recupera de falhas (forçadas pela equipe de teste) de forma adequada e sem prejudicar o uso do sistema. É importante que o software se recupere de erros (ou da maioria deles) e também, que seja tolerante a falhas, ou seja, que alguma falha de processamento ou requisição (por exemplo) não deve causar falhas em todo o sistema.
TESTE DE DESEMPENHO
Verifica como o software se comporta em ambiente integrado e como ele responde às requisições. Para executar esse teste e fazer as medições adequadas (nem mais, nem menos), é importante entender a demanda de usuários, quantas pessoas usarão o sistema com frequência, picos de uso etc.
TESTE DE STRESS
Verifica a quantidade máxima de carga que o sistema suporta até falhar. Por quantidade de carga, podemos entender o número de usuário logado, o tanto de requisições, o volume da massa de dados, quantidade de upload/download e assim por diante. Como o nome indica, o objetivo é estressar o sistema até que ele falhe – dessa forma, saberemos o limite de uso do sistema.
É importante mencionar que o teste de stress caminha junto com o teste de desempenho e considerando a natureza desses testes, ferramentas para automatizar testes são geralmente necessárias.
3.6 Teste de migração
PERGUNTA
• Será que o software irá funcionar da mesma forma no Linux como funcionada no Microsoft Windows?
• Será que quando um dos nós do banco “clusterizado” não estiver disponível, o sistema vai ser impactado?
É importante que alguns testes deintegração e de validação sejam executados no contexto de teste de migração, para garantir que a migração de ambiente não afetou o sistema como um todo, afinal, um sistema informatizado é a junção de muitos componentes, incluindo um software.
Sendo assim, podemos entender que o teste de imigração deve ser feito sempre que exista uma mudança na arquitetura do sistema ou na migração dos dados (como a troca de tecnologias de gerenciamento de banco de dados). Como exemplo de cenários nos quais testes de migração são relevantes, Pinkster (PINKSTER, 2016). Cita:
• Junções de mais sistemas/serviços no sistema atual;
• Mudança para novo sistema operacional;
• Substituição, melhoria ou consolidação das tecnologias de armazenamento de dados;
• Virtualização de ambientes;
• Mudanças na estrutura do banco de dados;
• Realocação de centro de dados (datacenter);
• Manutenção feita nos servidores;
• Aplicação de balanceamento de carga ou qualquer outra mudança relacionada a ajuste de performance.
4. Teste de software em sistemas em produção
4.1 Teste de software nos diversos tipos de manutenção
Quando o cliente começa a utilizar o sistema, o software entra na fase de manutenção, ou seja, o software é modificado frequentemente.
De acordo com (SOMMERVILLE, 2011), há três categorias de manutenção de software:
CORREÇÃO DE DEFEITOS
O autor salienta que erros de codificação não geram correções de alto custo, erros de projeto geralmente exige a reescrita de muitos componentes e linhas de código, o que torna o custo maior e erros de requisitos são os que geram correções de alto custo, pois implica em alterar o projeto e reescrever muitas linhas de código, quando não, escrever novas e inutilizar linhas existentes.
ADAPTAÇÃO AMBIENTAL
Esse tipo de manutenção é necessária quando o sistema que o software está inserido sofre alguma alteração e então, manutenções são necessárias para que o sistema se adeque a essas mudanças. Isso pode ocorrer com o software em si ou com os sistemas/componentes que ele se comunica. ADIÇÃO DE FUNCIONALIDADE
Esse tipo de manutenção ocorre quando os requisitos do sistema mudam ou precisam ser aprimorados em decorrência de mudança de negócio, mudança organizacional e até mesmo mudanças legais. Esse é o tipo de manutenção mais frequente, pois ao utilizar o software, o usuário tem a chance de sugerir melhorias e novos requisitos.
Sommerville (SOMMERVILLE, 2011) ressalta que outros nomes também são utilizados para nomear as categorias de manutenção – manutenção corretiva, que é equivalente à correção de defeitos; manutenção adaptativa, que é equivalente à adaptação ambiental e a manutenção perfectiva, que é equivalente à adição de funcionalidade.
Independentemente do tipo de manutenção que é necessária no software, o fato é que assim como a manutenção impacta no código e consequentemente na documentação do sistema, os testes também são impactados.
Dependendo da manutenção que será feita e de como ela foi projetada, o time de teste deve criar novos casos de teste, inseri-los nos ciclos e no plano de teste. Dependendo da situação, ao invés de criar nos casos de teste, o time de teste deve identificar o caso de teste que ficará obsoleto após a mudança e atualizar esse ou esses casos de teste para que ele atenda à modificação que foi feita.
4.2 Requisitos de qualidade de software
Pressman (PRESSMAN, 2006) salienta três pontos importantes sobre o tema:
REQUISITOS DE SOFTWARE
É o ponto básico para se medir qualidade do software. Se o software não atende aos requisitos funcionais e não-funcionais especificados, então não é possível dizer que o há qualidade;
NORMAS/CONVENÇÕES
Há diversas normas ou padrões de desenvolvimento que devem ser seguidos a fim de evitar que haja falta de qualidade. Podemos citar aqui tanto modelos de processo de desenvolvimento (qualidade de processo) como normas, convenções, boas práticas e guias de desenvolvimento do software que
disseminam formas adequadas de especificar, modelar, codificar, desenvolver interfaces gráficas, interfaces de comunicação (qualidade do produto). Se esses critérios são deixados de lado, quase sempre pode resultar em falta de qualidade;
REQUISITOS IMPLÍCITOS
Quando se trata de software, há um conjunto de requisitos que comumente não são explícitos, mas que são esperados, como usabilidade, navegabilidade etc. Se um software está em conformidade com requisitos funcionais, mas peca em relação a esses requisitos implícitos, a percepção de qualidade também é prejudicada. Podemos dizer que aqui estão os requisitos mais difíceis de serem especificados, os requisitos que são óbvios do ponto de vista do cliente, mas em alguns casos, difíceis de serem captados pelos desenvolvedores.
Exemplo: quando o cliente pede um software web, para ele, pode ser muito claro que o software irá funcionar na “internet”, independente de qual dispositivo ele utilize, afinal, internet é internet em qualquer dispositivo. No entanto, sabemos que é necessário saber de antemão os dispositivos, pois há adaptações que devem ser feitas para que o software funcione em celulares.
Pressman (PRESSMAN, 2006) resume muito bem que:
Qualidade de software é uma mistura complexa de fatores que variam com cada aplicação diferente e com os clientes que as encomendam.
REQUISITOS DE QUALIDADE
CONFIABILIDADE
CORREÇÃO 
DISPONIBILIDADE
EFICIÊNCIA
ESCALABILIDADE 
FLEXIBILIDADE 
FUNCIONALIDADE
INTEGRIDADE 
INTEROPERABILIDADE
MANUTENABILIDADE
PRAZO DE COLOCAÇÃO NO MERCADO
PORTABILIDADE 
REUTILIZAÇÃO
SEGURANÇA 
TESTABILIDADE 
UTILIZAÇÃO / USABILIDADE
Obviamente, alguns desses critérios dependem intimamente com o código-fonte e arquitetura do sistema (não se limitando a isso), como correção (do ponto de vista de código), escalabilidade, flexibilidade, interoperabilidade, manutenabilidade, portabilidade, reutilização.
Outros estão intimamente relacionados com o projeto do software e com os requisitos especificados, como confiabilidade, correção (do ponto de vista dos requisitos implementados), eficiência, funcionalidade, integridade, segurança, testabilidade e usabilidade. Outros estão mais relacionados com o plano de negócio, como prazo de colocação no mercado.
Vamos discutir como a atividade de teste se relaciona com cada um dos requisitos/atributos.
CONFIABILIDADE
Por meio dos testes de integração, de validação e de sistema é importante termos em mente que o sistema deve ser confiável do ponto de vista técnico, afinal, a equipe técnica deve confiar nos componentes que fazem parte do sistema (e que muitas vezes, não são desenvolvidos por eles) e principalmente do ponto de vista do usuário, que deve confiar que o sistema funciona da maneira correta, é seguro (testes de segurança), armazena os dados da maneira correta, exibe mensagens corretas, emite relatórios corretos e assim por diante.
CORREÇÃO
Por meio dos testes de unidade, integração, de validação e de sistema é importante termos em mente o quão correto o sistema está. Se estivermos aplicando testes estruturais, podemos verificar se o código está correto. Se estivermos aplicando testes funcionais, podemos validar se os requisitos foram implementados da maneira como deveria. De certa forma, as famosas perguntas de verificação e validação são muito pertinentes nesse requisito de qualidade: “Estamos construindo corretamente o produto?”; “Estamos construindo o produto certo?”.
DISPONIBILIDADE
Por meio de testes de sistemas, especialmente testes de desempenho e stress, podemos tentar identificar defeitos que comprometem a disponibilidade de um software, no entanto, esse critério é altamente relacionado ao ambiente que ele se encontra, e sabemos o quão difícil é prever todas as possibilidades de ambiente na atividade de teste.
EFICIÊNCIA
No contexto de software, eficiência é garantir que o software realize ou permita realizar certas atividades de maneira correta e em menor tempo, podendo até dizer que o software permite que a atividade seja realizada de forma “mais esperta” que outra,ou “mais otimizada” que outra forma. Testes de desempenho também podem ajudar, assim como testes alfa e beta, afinal, a experiência do 
usuário é que dirá de maneira mais completa sobre a eficiência de um sistema.
ESCALABILIDADE
Nesse contexto, escalabilidade significa a capacidade do sistema de atender mais usuários, de funcionar corretamente em arquiteturas maiores etc. Testes de stress podem ser úteis para identificar defeitos em escalabilidade ou ao menos apontar a capacidade de escalabilidade atual.
FLEXIBILIDADE
Esse requisito de qualidade está mais relacionado à arquitetura e ao projeto do software que em relação as funcionalidades, afinal são esses fatores que determinam a possiblidade e facilidade do sistema sofrer manutenções de adição de funcionalidades e ter seu uso ampliado. Dificilmente testes, mesmo que estruturais, identificam problemas que ferem a flexibilidade de um sistema. No entanto, podem ajudar a identificar “maus-cheiros” no código, conhecidos como bad-smells (SCHUMACHER, ZAZWORKA, et al., 2010).
FUNCIONALIDADE
Testes de integração, de sistema e de migração são estratégias que originalmente se preocupam em verificar e validar se as funcionalidades estão em conformidade com os requisitos funcionais especificados. Esse é um dos requisitos de qualidade altamente relacionado a atividade de teste.
INTEGRIDADE
Novamente, todas as estratégias de teste podem auxiliar a identificar defeitos em relação a integridade do sistema como um todo: integridade dos dados, dos acessos, das informações expostas para os usuários e para os outros componentes do sistema.
INTEROPERABILIDADE
Assim como flexibilidade, esse requisito de qualidade está mais relacionado à arquitetura e ao projeto do software que em relação as funcionalidades, afinal são esses fatores que determinam a possiblidade e facilidade do sistema de comunicar com outros sistemas, ou seja, de inserirmos um novo componente no sistema atual (como por exemplo, a integração de um sistema ERP com um sistema de CRM (Customer Relationship Management).
MANUTENABILIDADE
Esse é um requisito também relacionado à arquitetura e ao projeto do software, propriamente a forma como foi desenvolvido. Testes podem identificar, principalmente após testes feitos nas fases de manutenção, que alterações do código geraram muitos ou poucos defeitos, no entanto, esse critério de qualidade pode ser atingido por meio do uso de padrões de desenvolvimento como reuso ou padrões específicos para manutenção (HAMMOUDA, 2004).
PRAZO DE COLOCAÇÃO NO MERCADO
Esse critério, como salientado por (PRESSMAN, 2006), não é relacionado ao software propriamente, mas sim em relação a sua gestão. Um software que se propõe a resolver um problema existente precisa estar no mercado antes que outros o façam, afinal, o primeiro software lançado tende a captar mais usuários que os que vierem depois. Testes, nesse contexto, apenas podem ajudar a entregar no mercado um sistema sem defeitos ou com poucos defeitos.
PORTABILIDADE
Testes de sistemas e principalmente os de migração podem identificar defeitos quando uma portabilidade de ambiente e dispositivos é planejada, mas é necessário que o software tenha sido projetado e desenvolvido para isso.
REUTILIZAÇÃO
Esse requisito de qualidade se assemelha ao requisito de Manutenabilidade. Testes unitários ajudam a identificar defeitos nas unidades/componentes e assim, identificar se eles estão prontos para serem reutilizados. No entanto, é importante que a arquitetura do componente tenha sido projetada para que ele possa ser reutilizado – técnicas como padrões de projeto, família de produtos entre outras (GAMMA, JOHNSON, et al., 1994).
SEGURANÇA
Testes de segurança são importantes e devem ser considerados na estratégia de teste de sistemas. No entanto, vale ressaltar que requisitos de segurança bem especificados ajudam muito o time de desenvolvimento, assim como diretrizes de codificação e de configuração de ambiente com esse fim.
TESTABILIDADE
Teste é um tópico tão importante que é considerado um requisito de qualidade – ou seja, a atividade de teste é realizada para identificar defeitos e garantir a qualidade do software, mas é importante que os artefatos do software, como requisitos de projetos e principalmente o código sejam testáveis! A revisão dos requisitos (ou inspeção) é tão importante quanto, pois requisitos ambíguos, por exemplo, permitem testes ambíguos, o que pode dificultar a identificação de defeitos.
UTILIZAÇÃO / USABILIDADE
Os testes de validação são ideais para avaliar a usabilidade, facilidade de utilização do software do ponto de vista do usuário. Como foi dito no capítulo anterior, testes alfa e beta também são importantes, pois só o usuário poderá opinar sobre a usabilidade do sistema. No entanto, como foi dito, há diretrizes para ajudar a atingir esse requisito de qualidade, como as Heurísticas de Nielsen (NIELSEN, 1995) e a biblioteca de padrões Welie (WELIE, 2016).
Como sabemos, a qualidade de software é algo que deve ser buscado em conjunto, por todos os envolvidos no processo de desenvolvimento e manutenção.
Na fase de manutenção, a equipe de teste deve estar atenta no planejamento da atividade para testar o mínimo necessário. Não é possível testar todo o sistema novamente - para identificar defeitos não só nas funcionalidades que sofreram manutenção, mas em todas as outras funcionalidades que podem ter sido afetadas.
Sommerville (SOMMERVILLE, 2011) ressalta que atualmente, os sistemas de software estão tão enraizados na sociedade que são fundamentais para governo, empresas e indivíduos. Dessa forma, é imprescindível que esses sistemas sejam confiáveis e disponíveis.
4.3 Confiabilidade e disponibilidade
De acordo com o dicionário Michaelis (Michaelis, 2016), confiabilidade é:
“Qualidade ou estado daquele ou daquilo em que se pode confiar”.
O mesmo dicionário define disponibilidade, entre outras definições, como:
“Qualidade daquele ou daquilo que é ou está disponível”.
Sommerville (SOMMERVILLE, 2011) apresenta quatro dimensões principais da confiança de um sistema que podem guiar a definição de casos de teste. As quatro dimensões assim como uma sucinta descrição são apresentadas na figura.
Obviamente, devemos nos atentar ao contexto do sistema que estamos testando. Se considerarmos um software desktop, não desenvolvido para ser acessado via internet, disponibilidade, nesse contexto, é estar disponível no horário designado pelos clientes, ter o servidor de dados disponível todo o tempo de uso e assim por diante.
Sobre confiabilidade, o que permeia esses testes são os requisitos do sistema. Nesse caso, especialmente, todos os testes podem ser úteis. No entanto, testes de sistema e de validação, que verificam o comportamento do software no seu ambiente e do ponto de vista do cliente, tendem a identificar mais defeitos.
Segurança e proteção são testes que caminham juntos, e estão claramente definidos na estratégia de teste de sistemas. A equipe de teste deve procurar se especializar nesse tipo de teste e em alguns casos, procurar consultoria para tais testes – especialistas em invasão de servidores, de sistemas de comunicação e sistemas de gerenciamento de banco de dados.
5. Ferramentas de teste de software
5.1 Introdução às ferramentas de teste de software
5.2 Ferramentas de teste no desenvolvimento de sistema
JUnit
NUnit
5.3 Ferramentas de teste para o programa
Selenium
Sikuli
EclEmma
5.4 Ferramentas de teste para o ambiente web
JMeter
5.5 Ferramentas de teste para o sistema em produção