Avaliação de Software

Prévia do material em texto

Avaliação de Software
Aula 1 –
No início do desenvolvimento, quando só existia a função de programador e que era exercida por poucos, não haviam atividades de testes. Na verdade, não havia nem processo definido de desenvolvimento de software.
Na medida em que os erros ocorriam, após o software estar pronto, o próprio programador percorria o código para solução dos erros. Os testes aconteciam com o próprio usuário.
Somente na década de 70, quando os conceitos de engenharia de software emergiram sendo adotados como modelo para as universidades é que os primeiros procedimentos de testes, muito tímidos, começaram a ser usados, porém havia pouco consenso sobre o que viria a ser teste.
	
Por volta de 1979, Myers produziu um dos primeiros trabalhos mais completos e profundos trabalho sobre um processo de teste de software. Myers é o autor do livro "The Art of Software Testing", considerado por muitos como a primeira obra de real valor sobre teste de software e a criadora de termos muito usados como 'Caixa Branca e Caixa Preta" e "Caso de Teste". Myers também ficou conhecido pela regra 10 de Myers.
A Regra 10 de Myers mostra que quanto mais tarde os defeitos forem encontrados tanto mais caro será corrigi-los.
Nos anos 80 começou a surgir o conceito de Qualidade de software, onde o processo de desenvolvimento já estava sendo estruturado em fases e os testes aconteciam desde o início. Muitas organizações e padrões surgiram nesta época, mas o que ganhou maior dimensão e importância para as organizações de software foi o modelo CMM, elaborado pelo SEI.
Nos anos 90 as ferramentas de teste começaram a ser produzidas e determinados tipos de testes que antes não eram possíveis de serem executados, tornaram-se uma realidade e trazendo alta produtividade e qualidade no processo de teste.
Cenário Atual do Desenvolvimento de Software - Sistemas de software tornam-se cada vez mais parte do nosso dia-a-dia, desde aplicações comerciais (ex: bancos) até produtos de consumo (ex: carros). Com a globalização a integração entre matriz-filiais, fornecedores e clientes torna-se uma realidade e os sistemas além de complexos demandam grande integração entre suas diversas funcionalidades que devem atender a toda a empresa, de forma unificada.
Neste contexto, a maioria das pessoas já teve alguma experiência com um software que não funcionou como esperado. Softwares que não funcionam corretamente podem levar a muitos problemas, incluindo financeiro, tempo e reputação das empresas. Podem inclusive, chegar a influenciar na integridade das pessoas.
Consequentemente o conceito de teste ganha complexidade, pois os riscos dos softwares não funcionarem a contento, cresce de forma exponencial. Ainda assim poucas empresas percebem que a implantação de um processo de garantia de qualidade de software é uma questão de estratégia de sobrevivência em um mercado cada vez mais exigente e competitivo.
Apresentamos abaixo a evolução do processo de qualidade e de teste de software (Bartié, 2002)
A realidade dos projetos de software - Apesar de Sistemas de software tornam-se cada vez mais parte do nosso dia-a-dia e de serem um dos aspectos mais estratégicos para se viabilizar o aprimoramento e a inovação dos produtos e serviços nas organizações, o que acontece de fato, é que as indústrias de software estão despreparadas para atender às rápidas necessidades dos mercados porque não investiram em seus processos internos.
Não existe garantia de que a solução tecnologia contratada será entregue no prazo e nos custos negociados. Estudo americano demonstra o quanto imaturo ainda estão as indústrias de software:
30% dos projetos são cancelados;
70% dos projetos falham na funcionalidade;
Os custos extrapolam 180% a previsão;
Os orçamentos extrapolam em 200% os cronogramas iniciais.
Qualidade do software e processo - Todas as decisões tomadas durante o processo de desenvolvimento do software podem comprometer sua qualidade final. Se desejarmos produzir software com qualidade, é necessário investir em qualidade em todos os pontos do processo.
A qualidade de software é um processo sistemático que focaliza todas as etapas e artefatos gerados com objetivo de garantir a conformidade e uniformidade de processos e produtos, prevenindo e eliminados defeitos.
A partir de processos uniformes e consistentes a tendência é que o produto final gerado, ou seja, o software seja eficiente. Softwares mal testados geram prejuízos as empresas, como:
• Retrabalho, aumentando o custo do projeto.
• Informações erradas que podem originar decisões equivocadas. 
• Insatisfação dos usuários.
Assim, podemos concluir que é impossível obter um software com qualidade com processos de desenvolvimento ineficientes. Não é possível estabelecer um processo de garantia de qualidade que não enfoque simultaneamente o produto tecnológico e o processo de desenvolvimento desse software. Desta forma podemos estabelecer duas dimensões para obtenção da qualidade
Qualidade do Processo - Na dimensão da qualidade do processo, a qualidade deve existir desde o início, ou seja, já na fase de análise de requisitos, quando acontece o levantamento de requisitos. O quanto antes detectarmos problemas, mas facilmente e com menor custo eles serão resolvidos. Entretanto poucas empresas percebem com clareza e implementam atividades para essa dimensão. É importante salientar que a qualidade nos processos é primordial e será aplicada em documentos e modelos gerados por cada fase que compõe o processo de desenvolvimento usado pela empresa. Este é o desafio, garantir a qualidade de um software, ou seja, estabelecendo uma cultura de não tolerância a erros através de processos estruturados por mecanismos de inibição e impedimentos de falhas. Desta forma os diversos artefatos gerados durante o ciclo de desenvolvimento tenham procedimentos que avaliam sua qualidade, possibilitando a identificação prematura de defeitos nesses artefatos. Nesta dimensão de qualidade, ou seja, a qualidade do processo pode ser medida através de testes aplicados nos documentos gerados em cada fase do ciclo de desenvolvimento do software através de testes chamados de testes de verificação ou testes estáticos.
Qualidade do Produto - Nesta dimensão o objetivo principal é a garantia da qualidade do produto tecnológico gerado durante o ciclo de desenvolvimento. 
Esta dimensão é muitas vezes negligenciada por parte das empresas devido a problemas de cronogramas com o cliente. Apesar de empregada nas organizações, o grau de eficiência das atividades relacionadas a esta dimensão ainda é baixo. Para o teste do produto, obviamente, existe a necessidade de uma instância do sistema implementada, em parte ou na totalidade. Assim a qualidade do produto é garantida com a aplicação de testes sistemáticos nos vários estágios de desenvolvimento. Nesta dimensão a qualidade pode ser medida através da aplicação de testes chamados de testes de software ou testes de validação ou ainda testes dinâmicos.
O conceito de testes - De uma maneira geral os testes são vistos como forma de provar que tudo está bem e funcionando conforme o estabelecido. Existem várias definições para o conceito de testes:
Teste é o processo de demonstrar que os defeitos não estão presentes
Teste é o processo de demonstrar que algo funciona corretamente.
Teste é o processo de provar que determinadas coisas (funções) fazem o que devem fazer.
Todas estas definições dão uma dimensão positiva sobre o problema, ou seja, se está tudo funcionando adequadamente. Porém o objetivo real do teste de software é mostrar que um software está de acordo com suas especificações e que ele atende as expectativas do cliente. Desta forma o software é testado para revelar erros cometidos inadvertidamente quando o software foi produzido e construído. Em uma definição ampliada de testes teremos:
"processo sistemático e planejado que tem por finalidade única a identificação deerros. ”
Fonte: Bartié, 2002
Por conta desta definição de teste é importante ressaltar que a equipe de qualidade, ou de testes, deve ser o mais independente possível da equipe de desenvolvimento de forma a não estar envolvida emocionalmente nem politicamente com o projeto, tendo um comportamento mais objetivo e direto. Esta equipe terá mais facilidade em focar nos pontos que inicialmente o projeto deveria atender e por motivos desconhecidos foram abandonados ou não atendidos corretamente.
Devemos levar em consideração que os testes podem ser usados para mostrar a presença de erros, porém não conseguirá cobrir todas as infinitas combinações existentes em um ambiente de execução real.
Myers concluiu que zero-defeito é algo inatingível? Ou seja, pela complexidade envolvida e pelo número altíssimo de situações existentes, torna-se impossível imaginar um produto de software “livre de erros”. Sempre existirão erros a serem descobertos.
A qualidade de software trabalha com o conceito de zero-defeito, ou seja, representa a não tolerância a erros. O objetivo é definir um processo que contenha mecanismos de inibição de defeitos, impedimento de que falhas sejam criadas e propagadas para as fases seguintes. Todo o processo é desenhado para minimizar a incidência de problemas.
Os Pilares da qualidade de software - Para compreender melhor o processo de qualidade de software e sua implementação, segundo Bartié (2002), podemos fazer uma referência ao processo de gerenciamento de qualidade do PMBOK que estrutura o processo de qualidade em três subprocessos complementares:
Todo erro custa dinheiro. Podemos entender que o custo da qualidade é todo o investimento realizado com a finalidade de um produto ou serviço atingir a qualidade desejada. Estes custos estão relacionados aos:
Custos da Conformidade - Significa o esforço para garantir a qualidade. São todos os investimentos realizados para planejar e manter toda uma infraestrutura de pessoas, processos e ferramentas cujo objetivo seja prevenir e detectar. 
Custos da não-conformidade - Está relacionado aos defeitos e suas correções. São todos os custos de atividades ligadas ao esforço de reparar falhas de produtos originados no decorrer do processo de desenvolvimento.
A Implantação - A implantação de um processo de qualidade tanto no processo, como no produto tem um custo, porém é vantajosa, pois quanto mais tardiamente os erros forem descobertos, mais cara custa a solução. 
Para Myers quanto mais tardiamente descobrimos os erros, mais caros eles ficam. Segundo a regra 10 de Myers, significa que quando um erro não é identificado, os custos de sua correção multiplicam-se por 10 para cada fase do processo de desenvolvimento de software em que o erro migra por isso os testes de verificação, ao longo do processo de desenvolvimento tornam-se uma ajuda na redução dos custos de qualidade: detectam o problema antes de ser implementado.
Aula 2 – 
Como já vimos na aula anterior o controle da qualidade é um processo contínuo e sistêmico de acompanhamento da eficiência do desenvolvimento do software em relação aos requisitos propostos. 
Normalmente temos uma tendência a pensar o desenvolvimento de software como uma linha de tempo na qual todas as etapas serão cumpridas e que existe uma etapa específica para a realização dos testes.
Processo de qualidade de software - O processo de qualidade de software pode ser decomposto em fases que se organizam em um formato de “U” e consequentemente deve existir uma relação de “um-para-um” entre as fases de desenvolvimento e as atividades a serem desempenhadas pela equipe de qualidade, conforme a figura abaixo:
Momentos do processo de desenvolvimento de software - O processo de desenvolvimento de software é dividido em dois momentos que possuem características diferentes e consequentemente necessitam de métodos de avaliação também diferentes: Teste de verificação e teste de validação.
Os testes de verificação e validação são complementares, não devendo ser encarados como atividades redundantes. Cada um possui natureza e objetivo distinto, fortalecendo desta forma o processo de detecção de erros e aumentando a qualidade final do produto.
Teste de verificação - Processo de auditoria de atividades e avaliação de documentos gerados em todas as fases do processo de desenvolvimento de software. Não envolve o processamento de softwares, pois não existe uma encarnação desde ainda. Os testes de verificação serão aplicados respeitando os estágios de desenvolvimento.
Modelo de negócios - Verificação de Negócios
Especificação de requisitos – Verificação de requisitos
Análise e modelagem - Verificação, Análise e Modelagem
Implementação - Verificação da Implementação
Teste de Validação
O que é? - Processo formal de avaliação de produtos tecnológicos que podem ser aplicados em componentes isolados, módulos existentes ou mesmo a totalidade do sistema,
Objetivo – Avaliara a conformidade de software com os requisitos e especificações analisadas e revisadas nas etapas iniciais do projeto.
Característica – caracterizasse pela presença física do software e de seu processamento em um ambiente tecnicamente preparado. As validações serão aplicadas respeitando os estágios de desenvolvimento.
Fatores de Insucesso dos processos de Qualidade
Aula 3 – 
Testes de Verificação - Como já estudamos na aula anterior e ainda segundo Bartié (2002), os testes de verificação devem garantir a qualidade de todas as etapas do desenvolvimento de sistemas.  Neste sentido a qualidade será obtida através da correta construção de documentos e a adequada realização das atividades previstas no processo corporativo de engenharia de software. Desta forma os testes de verificação devem concentra-se em dois aspectos bem distintos:
Revisões Técnicas - À medida que os softwares são desenvolvidos é possível que ocorram erros. AS revisões técnicas são o mecanismo mais efetivo para descobrir erros antes que sejam passados para os usuários finais.  Por isso são utilizadas logo no início do processo de gestão de qualidade.
É um processo "humano" de análise de determinado documento e consequentemente um processo subjetivo e passível de falhas. Este processo requer pessoas adequadamente treinadas para desempenhar seus papéis durante a condução das atividades de verificação.  
Ao se descobrir um erro logo no início do processo, fica menos caro corrigi-lo. Nós já estudamos isso através da regra 10 de Myers, lembra?  Assim devemos levar em consideração que os erros podem aumentar à medida que o processo continua. Um erro relativamente insignificante, sem tratamento no início do processo, pode ser ampliado e se transformar em um conjunto de erros graves para a sequência do projeto.
As revisões minimizam o tempo de desenvolvimento do software devido à redução do número de reformulações que serão necessárias ao longo do projeto. Existem diferentes técnicas de revisão e cada uma delas apresenta características e um tipo de aplicação. Para cada fase do processo de criação de documentos, conforme a figura abaixo, podemos aplicar um tipo de revisão diferente:
Revisões Isoladas - Esse método de verificação é muito eficiente apesar de pouco explorado, na detecção prematura de erros de definições e soluções registradas. Seu objetivo principal é antecipar a revisão de documento com entregas de versões ainda não acabadas para que possam ser analisados os tópicos já abordados, são realizadas validações parciais do documento. Desta forma possibilita correções nos documentos durante sua fase de concepção.
Neste caso, a ação dos revisores é isolada, sendo normalmente utilizado um único revisor que proporá as modificaçõesnecessárias.  O grande problema desta técnica é que o autor pode ter uma visão de conjunto mais apurada que o revisor já que a utilização de único revisor poderá propor mudanças que prejudiquem uma visão integrada do problema.
Revisões Formais - as revisões formais exigem uma equipe multidisciplinar de profissionais de forma que as decisões sejam analisadas por diversos ângulos. É fundamental documentar tudo o que foi discutido, os principais problemas detectados, suas correções e as sugestões de melhoria. Esta documentação é produzida pela equipe de qualidade e posteriormente apresentada aos autores do documento para realização das modificações e posteriormente submetido a uma nova revisão.
Normalmente em um processo de revisão podemos ter as seguintes fases:
Reunião de Acompanhamento - As reuniões de acompanhamento é a forma de verificação menor formal do que as reuniões de revisão, já que não necessita de uma adequada preparação por parte dos participantes. Neste caso somente o apresentador que normalmente é o autor do documento prepara-se para a reunião enquanto as demais participantes simplesmente comparecem.
O Objetivo desta reunião não é a detecção de erros e sim democratizar as informações entre todos os participantes, o que permite envolver um número maior de pessoas que podem colaborar no processo de desenvolvimento do software.
A dinâmica normalmente utilizada é a distribuição do material a todos os participantes para que possam realizar a análise antecipada dos documentos e que posteriormente em reunião pré-agendada todos poderão debater dúvidas e divergências existentes.
Auditorias - Segundo Bartié (2002), a auditorias concentram-se nas atividades críticas de um processo de engenharia de software. Seu objetivo de uma auditoria de qualidade é avaliar se:
1. Um determinado projeto e as diversas equipes estão respeitando o processo de desenvolvimento;
2. Se estão registrando os defeitos encontrados
3. Se estão produzindo as atas de reuniões
4. Se estão realizando as reuniões de revisões,
5. Se estão realizando as documentações obrigatórias
6. Se estão atualizando o mapa de riscos dos projetos
7. E se estão envolvendo clientes e usuários nos processos
Enfim eles verificam todo o processo e devem estar atentos caso alguma atividade previamente definida não esteja sendo respeitada.
Aplicação do processo de verificação - O processo de validação requer um conjunto de procedimentos e regras, dentre várias possibilidades, que auxiliarão as equipes de qualidade na verificação:
Planejar mão de obra e tarefas de cada um
Preparar o pessoal de forma que recebam o máximo de material sobre o tema em questão.
Verificar os documentos
Aplicar check-list nas verificações.
A figura apresentada mostra um modelo de referência, onde são identificadas quatro características que contribuem para a formalidade na qual o processo de verificação deve ser conduzido:
As verificações devem ser aplicadas com um nível de formalidade apropriado para o produto a ser construído, a cronologia do projeto e as pessoas que estão realizando o trabalho. 
A formalidade do processo está relacionada a fatores como a maturidade do processo de desenvolvimento, requisitos legais e reguladores ou a necessidade de acompanhamento de auditoria.  O modo como o processo é conduzido depende do seu objetivo (ex: encontrar defeitos, obter compreensão, discussão ou decisões por um consenso) e do tipo de verificação a ser realizada: reuniões isoladas, reuniões formais, reuniões de acompanhamento e auditorias.
As fases dos Testes de Verificação - Cada etapa do processo de desenvolvimento cumpre uma etapa e produz documentos e/ou modelos pertinentes a finalidade da fase.
A etapa de verificação é fundamental no processo, pois desde as fases iniciais pode-se aferir a qualidade do processo e não deixar que problemas sejam migrados para as fases seguintes.
Nesta aula estudaremos como proceder as verificações pertinentes para cada fase do processo de desenvolvimento de software:
Fase de Negócio - Nesta fase estabelecemos o primeiro contato com as necessidades, expectativas e exigências dos clientes. Através da modelagem de negócios poderemos criar uma macro visão da extensão do projeto e os seus principais objetivos.
O objetivo da verificação nesta fase é garantir que os documentos produzidos tenham aderência às necessidades apontadas pelos clientes. É importante o exercício de revisão destes documentos com o próprio cliente.
O que avaliar nessa fase:
- Avaliar se todas as necessidades, metas e exigências foram listadas;
- Verificar se a modelagem de negócios cobre todas as necessidades;
- Conferir se as projeções realizadas são baseadas em métricas e indicadores confiáveis;
- Avaliar a existência de alternativas a essa solução;
- Avaliar o retorno sobre o investimento em cada alternativa existente (ROI);
- Validar as opções de investimento (árvore de decisão).
Checklist - Como já visto anteriormente, o checklist é um importante instrumento que auxilia revisores e auditores no processo de verificação.
Fase de Requisitos - Esta fase tem a missão de detalhar todos os aspectos funcionais e não funcionais relativos à solução a ser construída. O conjunto de especificações de negócio serão, nesta fase, detalhados em seu nível máximo, deverão ser apontados todos os aspectos a serem implementados.  Vale lembrar aqui, que o sucesso de qualquer projeto de software depende desta fase, pois esta fase direcionará todas as fases posteriores do desenvolvimento de software e estabelecem um escopo para o produto final.
Fase de análise e modelagem - Nesta etapa o objetivo é definir uma solução tecnológica que suporte além dos requisitos estabelecidos pelo cliente, os requisitos de qualidade que deverão ser atendidos pela arquitetura do software a ser modelada.
Fase de implementação - Nesta fase todas as documentações produzidas nas fases anteriores serão transformadas em código de uma determinada linguagem de desenvolvimento. O objetivo da verificação nesta fase é garantir que a qualidade do código-fonte gerado pela equipe de desenvolvimento, o que pode ser verificado através das “boas práticas de programação” garantidas através da adoção de normas e padrões corporativos seguidos pela equipe de desenvolvimento.  
Aula 4 – 
Teste de Validação - Na aula passada estudamos os testes de verificação que avaliavam as documentações, nesta aula iremos estudar os testes de validação. Este tipo de teste está focado na aplicação, pois neste momento do processo de desenvolvimento já temos um produto computacional. Seu principal objetivo é identificar o maior número possível de erros tanto nos componentes isolados quanto na solução como um todo e por isso o sucesso do teste de validação está apoiado no forte planejamento de todas as atividades de testes.
Estratégias de Testes – Caixa Branca e Caixa Preta
Teste de CAIXA BRANCA - O teste da caixa-branca, também conhecido como teste da caixa-de-vidro, é baseado na arquitetura interna do software e utiliza a estrutura de controle descrita no programa para derivar casos teste. São empregadas técnicas que avaliam a estrutura de sequência, decisão e repetição, através da simulação de situações que exercitem todas as estruturas utilizadas na codificação adequadamente.
Para a realização dos testes de caixa-branca, é necessário que o profissional de teste conheça toda a tecnologia empregada pelo software (linguagem de programação, arquitetura do software, banco de dados), pois são testes altamente eficientes na detecção dos erros, porém são difíceis de serem empregados.
A finalidade dos testes de caixa-branca é encontrar o menor número de casos de teste que permita que todos os comandos de um programa sejam executados pelo menos uma vez.
Os casos de teste no teste de caixa branca são determinados a partir das estruturas de controle do programa, conforme a figura abaixo,com o objetivo de forçar que todos os caminhos possíveis do fluxo de controle do programa sejam percorridos durante os testes. A ideia é que o profissional de teste consiga identificar o maior número possível de cenários de testes que atendam ao maior número possível de situações.
É possível criar casos de teste que:
Garantam que todos os caminhos independentes de um módulo foram exercitados pelo menos uma vez;
Exercitam todas as decisões lógicas nos seus estados verdadeiros e falsos;
Executam todos os ciclos em seus limites e dentro de suas fronteiras operacionais;
Exercitam estruturas de dados internas para assegurar sua validade.
Teste de CAIXA PRETA - O teste da caixa preta, também conhecido como teste comportamental, focaliza os requisitos funcionais do software e utiliza técnicas para garantir que os requisitos do sistema sejam amplamente atendidos pelo software construído. Este tipo de teste complementa o teste da caixa branca permitindo descobrir uma classe de erros diferentes daquela obtida com métodos da caixa-branca. Diferentemente aos testes da caixa-branca, o teste da caixa-preta não requer o conhecimento da tecnologia empregada e dos conceitos de implementação do software.
É necessário que o profissional de testes conheça os requisitos, suas características e comportamentos esperados, para que o software seja avaliado através dos resultados gerados pela aplicação. Neste caso quanto maior a variedade de cenários, maior será o conjunto de simulações que serão avaliadas e comparadas com os requisitos da aplicação, implementados através da construção de casos de testes.
 
Os testes de caixa preta são realizados para responder as seguintes perguntas:
Como a validade funcional é testada?
Como o comportamento e o desempenho do sistema é testado?
Que classes de entrada farão bons casos de teste?
O sistema é particularmente sensível a certos valores de entrada?
Como as fronteiras de uma classe dedados é isolada?
Que taxas e volumes de dados o sistema pode tolerar?
Que efeito combinações específicas de dados terão sobre a operação do sistema?
E tentam encontrar erros nas seguintes categorias:
Funções incorretas ou faltando;   
Erros de interface;
Erros em estruturas de dados ou acesso a bases de dados externas;
Erros de comportamento ou de desempenho;           
Erros de inicialização e término.
Há várias formas (Bartié, 2002) de identificar e planejar os casos de testes a serem aplicados nos testes de validação, porém, o direcionamento dos testes baseia-se exclusivamente em requisitos da solução tecnológica a ser desenvolvida ou na estrutura interna do código-fonte a ser implementado.
Testes baseados na estrutura interna
Nessa abordagem, os testes requerem conhecimento profundo da tecnologia empregada e do projeto desenvolvido, de forma a exercitarem adequadamente todas as estruturas internas do projeto. Este tipo de teste requer que o testador tenha um amplo conhecimento interno do software e subdivide-se em:
Teste de fluxo de dados - Este método seleciona caminhos de teste de um programa de acordo com as localizações de definições e usos de variáveis no programa. São úteis para selecionar caminhos de teste de um programa que contenha instruções de laços e if aninhadas.  
Uma vez que as instruções de um programa se relacionam entre si de acordo com as definições e usos de variáveis, a abordagem de teste de fluxo de dados é eficiente para a proteção contra erros.
Teste de condição - O teste de condição, segundo Pressman, é um método de projeto de caso de teste que exercita as condições lógicas contidas em um módulo de programa:
Uma condição simples é uma variável booleana ou uma expressão relacional, possivelmente precedida por um operador NOT. 
Uma condição composta é formada por duas ou mais condições simples, operadores booleanos e parênteses.
Este tipo de teste foca o teste de cada condição no programa para garantir que ele não contenha erros.
Teste de Ciclo - Este tipo de teste focaliza exclusivamente a validade das construções de ciclo, já que são em sua grande maioria a base da maioria dos algoritmos implementados. Podem ser definidos quatro tipos diferentes de classes de ciclos:
Simples; Alinhados; Concatenados; Não-estruturados.
 Teste de caminho básico - O teste de caminho básico permite ao projetista de casos de teste derivar uma medida da complexidade lógica de um projeto procedimental e usar essa medida como guia para definir um conjunto de base de caminhos de execução.
Testes baseados em Requisitos
Nessa abordagem, os testes são baseados nos documentos de requisitos e modelados através de especificações funcionais e suplementares, os requisitos devem ser decompostos em casos de testes de forma a avaliarem todos os cenários existentes e validarem todas as variações. Existem diferentes métodos de testes de caixa-preta que podem ser subdivididos em:
Baseados em grafo - O método de teste com base em grafos, leva em consideração os objetos modelados no software e as relações que unem estes objetos. A ideia é definir uma série de testes que verificam se os objetos têm a relação esperada uns com outros. 
Um grafo é uma coleção de nós que representam objetos, ligações que representam as relações entre objetos, peso de nó que descrevem as propriedades de um nó e pesos de ligação que descrevem alguma característica de uma ligação.
Particionamento e equivalência - Neste método o domínio de entrada de um programa é divido em classes de dados a partir das quais podem ser criados casos de teste. Um caso de teste ideal descobre sozinho uma classe de erros (por exemplo, processamento incorreto de todos os dados de caracteres) que poderia de outro modo requerer que fossem executados muitos casos de teste até que o erro geral aparecesse.
Classes de equivalência podem ser definidas de acordo com as seguintes regras:
Se uma condição de entrada especifica um intervalo, são definidas uma classe de equivalência válida e duas classes de equivalência inválidas.
Se uma condição de entrada requer um valor específico, são definidas uma classe de equivalência válida e duas classes de equivalência inválida.
Se uma condição de entrada especifica um membro de um conjunto, são definidas uma classe de equivalência válida e uma classe de equivalência inválida.
Se uma condição de entrada for booleana, são definidas uma classe válida e uma inválida.
Análise de Valor-limite - A análise do valor limite (boundary value analisys – BVA) é uma técnica que complementa o particionamento de equivalência, levando em consideração na construção dos casos de teste os valores limites das condições de entrada e saída.
As diretrizes para o teste de análise de valor-limite, são muito similares a técnica de particionamento de equivalência:
Se uma condição de entrada especifica um intervalo limitado por valores a e b, deverão ser projetados casos de teste com valores a e b imediatamente acima e abaixo de a e b. 
Se uma condição de entrada especifica um conjunto de valores, deverão ser desenvolvidos casos de teste que usam os números mínimo e máximo. São testados também valores imediatamente acima e abaixo dos valores mínimos e máximo.
Aplicar as diretrizes 1 e 2 às condições de saída. 
Se as estruturas de dados internas do programa prescreverem fronteiras, não esquecer de criar caso de teste para exercitar a estrutura de dados na fronteira. Por exemplo, uma tabela que tem um limite definido de 100 entradas.
Teste de Matriz Ortogonal - O teste de matriz ortogonal pode ser aplicado a problemas nos quais o domínio de entrada é relativamente pequeno, mas muito grande para acomodar um teste exaustivo. O objetivo do teste é a construção de caso de teste com uma visualização geométrica associada aos valores de entrada de uma aplicação. Na função enviar para uma aplicação de fax, por exemplo (Pressman,2010): São passados quatro parâmetros: P1, P2, P3 e P4, onde cada parâmetro assumetrês valores discretos.
P1 assume os seguintes valores:
P1=1, enviar agora;
P1=2, enviar após 1 hora;
P1=3, enviar depois da meia-noite;
P2, P3 e P4 também assumem valores, 1, 2 e 3, significando outras funções de envio.
Testes Progressivos e Regressivos
É muito comum na maioria das empresas, que após o software entrar em produção, ocorra a necessidade de manutenções para correção de algum defeito ou para a adição de uma nova funcionalidade. 
Toda vez que um novo módulo é adicionado ou corrigido, o software se modifica e novos caminhos de fluxos de dados podem ser estabelecidos, novas E/S podem ocorrer ou ainda novas lógicas de controle podem ser adicionadas.
Essas modificações podem causar problemas em funções que previamente funcionavam corretamente, daí a necessidade de utilizarmos os testes progressivos e/ou regressivos nas validações.
Testes Progressivos - São elaborados de acordo com a evolução do produto. Á medida que o software recebe novas funcionalidades, um novo conjunto de testes deve ser criado. Desta forma, os testes de progressão testam somente as inovações do software (novas funções implementadas), assumindo que nenhum erro foi introduzido após seu processo de desenvolvimento.
Testes Regressivos - Trata-se de reexecutar um subconjunto (total ou parcial) de testes previamente executados. Seu objetivo é garantir que as alterações e inserções não prejudicarão o funcionamento do software. As novas versões do produto devem ser submetidas a uma nova sessão de testes para detectar eventuais impactos em outras funcionalidades,
Vamos imaginar o seguinte cenário:
A empresa XPTO possui um sistema Alfa atendido por vários clientes, vamos considerar a seguinte situação:
O sistema Alfa atende a duas categorias de clientes, o cliente Regular e o cliente VIp. O cliente VIP responde por 75% do faturamento. A necessidade de políticas de negociação para clientes ocasionais gera demanda para uma nova funcionalidade.
Por conta disso foi gerada uma nova versão e somente foram aplicados testes progressivos. Desta forma, não foi percebido que a política de negociação do cliente Vip foi afetada com esta mudança, ocasionando reduções nos preços das linhas inteiras de produtos.
Essas reduções de preços aumentaram repentinamente a requisição de pedidos. O erro foi identificado e a solução foi disponibilizada rapidamente. Foram seis horas para a solução completa do problema.
Atualmente, a maior parte dos esforços dos testes aplicados nas empresas está concentrada nas funcionalidades recém-construídas ou modificadas. Como não existe mecanismo que avalie as mudanças que provocam problemas em outras funcionalidades existentes, o risco de uma pequena mudança gera problemas no ambiente de produção aumenta consideravelmente. Para redução dos riscos, é aconselhável a utilização dos testes progressivo e regressivo.
Aula 5 – 
Categorias dos testes de validação
Normalmente, verificamos que empresas que diversificam suas ações em relação aos testes de software, demonstram falhas relacionadas ao conceito de categorização aplicado, tornando inferior a qualidade do planejamento da validação do software. Este fato ocorre devido os profissionais de testes planejarem trabalhos de naturezas diversas em uma única abordagem e levantamento.
Aplicação de testes em categorias - A categorização dos cenários proporciona o melhor planejamento dos testes, facilitando o entendimento e reduzindo os esforços de validação do software. O agrupamento em categorias permite o refinamento dos cenários de software, ampliando a cobertura dos testes. 
É necessário observar que cada categoria possui seu ciclo de teste independente e naturezas conflitantes, por diversas vezes, não possibilitando sua coexistência. Suportar atividades simultaneamente significa conciliar interesses opostos.
Abaixo mostra o levantamento dos cenários aplicando-se os conceitos de categorização. Se compararmos à figura anterior verificaremos a vantagem nesta categorização.
Funcional
Simular saques acima do saldo disponível;
Simular saque na conta-poupança;
Simular saque acima do limite do valor da conta;
Simular saque com valores não múltiplos das notas.
Segurança
Simular saques com o cartão vencido;
Avaliar se a senha do cartão está sendo avaliada antes e depois da transação;
Avaliar se a senha adicional ou randômica está sendo requisitada no início da operação;
Simular saque noturno acima do valor permitido.
Usabilidade
Avaliar se todas as telas possuem ajuda;
Avaliar se as mensagens são claras e objetivas;
Avaliar se o padrão visual é mantido em todos os momentos;
Avaliar se todas as operações possuem caminhos de fuga.
Performance
Avaliar se a duração do saque dura mais do que 30 segs. Num universo de 5 milhões de correntistas e 100 milhões de movimentações bancárias.
Carga e Concorrência
Simular 2 saques simultâneos na mesma conta corrente;
Simular 10.000 saques simultâneos.
Configuração
Simular saque com impressora do fornecedor A B e C;
Simular saques no Windows 95, 98, NT e 2000;
Simular saque com impressora do fornecedor X, Y, e Z.
Recuperação
Simular saque com defeito no "cash-dispenser";
Simular saque com defeito na impressora;
Simular saque com falha de conexão com a central;
Simular saque com queda de energia.
Contingência
Disparar processo de instalação inicial
Cada categoria de teste possui um determinado objetivo a ser alcançado, definindo o propósito da realização dos testes, estabelecendo um escopo das ações e planejamentos destes trabalhos. Sem este escopo, existiria uma dispersão natural no esforço de criação dos testes de um determinado sistema. 
Forma de classificação do conteúdo utilizado em cada teste.
Porque categorizamos os testes? Para aumentar a eficiência da detecção do maior número possível de cenários de testes.
Testes sem Categorização (Sem Foco)
Levantamentos Unificados. 
Superficialidade do Levantamento. 
Única documentação dos testes. 
Visão única dos Testes
Falta de priorização das categorias.
Aplicação de todas as categorias sem avaliação
Dificuldade em segregar a execução dos testes.
Testes sem Categorização (Com Foco)
Levantamentos Categorizados.
Profundidade dos Levantamentos.
Documentações Categorizadas
Visão categorizada dos Testes. 
Priorização das Categorias.
Métricas de esforço e eficiência das categorias
Somente categorias relevantes são aplicadas.
Execuções separadas de testes, flexibilizando a operação.
Durante o planejamento dos testes devemos estudar quais as categorias de testes serão aplicadas ao processo de validação de software. Após esta categorização estaremos aptos a identificar todos os cenários existentes para cada transação a ser testada.
Visão Categorizada dos testes de software - Existem diversas visões acerca de categorizações dos testes de software. Uma das visões é o modelo FURPS, que representa as categorias que podem ser usadas na definição de requisitos e testes de validação de software, assim como os atributos de Qualidade de Software.
Este modelo é parte do Rational Unified Process. (RUP) Ele consiste nas seguintes categorias:
SUPORTABILIDADEUSABILIDADE
• Teste de interface.
• Teste de usabilidade.
FUNCIONALIDADE
• Teste funcional.
• Teste de regressão.
• Teste de volume.
• Teste de segurança
• Teste de configuração.
• Teste de instalação
DESEMPENHO
• Teste de avaliação de desempenho ou benchmark.
• Teste de contenção.
• Teste de carga.
• Perfil de desempenho.	
CONFIABILIDADE
• Teste de integridade.
• Teste de estrutura.
• Teste de estresse.
• Smoke test.
Já a ISO/IEC 9126-1 apresenta a seguinte categorização:
Conectividade: Integração entre componentes (hardware e software);
Continuidade: Capacidade de operar ininterruptamente (Ex.: 24 x 7);
Segurança: A certeza de que o dado somente pode ser alterado por aqueles autorizados;
Eficiência: A relação entre os níveis de desempenho dosistema e os recursos;
Funcionalidade: Estar de acordo com a especificação Funcional;
Usabilidade: Facilidade de uso do sistema pelos Usuários;
Performance: Velocidade de processamento da informação;
Portabilidade: Capacidade do programa processar em diversos Ambientes
Principais Categorias de Teste de Validação
Teste de Funcionalidade - Categoria de teste que tem por objetivo avaliar e garantir que todos os requisitos especificados sejam implementados, geralmente servindo como base de um processo de verificação automática. Os testes funcionais estão relacionados as regras de negócio para que se obtenha ampla cobertura dos cenários de negócio. Sua melhor descrição está em um modelo de casos de uso e em casos de uso. Os testes podem ser executados validando as seguintes condições:
Pré-condições de uma transação de negócios.
Fluxo de dados de uma transação de negócios.
Cenários primário, alternativos e de execução de uma transação de negócios.
Pós-condições de uma transação de negócios.
Teste de Usabilidade - Categoria de teste que enfatiza o nível de facilidade de uso da aplicação por seus clientes ou usuários. Os testes de usabilidade focalizam o nível de facilidade de navegação entre as telas da aplicação e as telas de ajuda devem ser avaliadas quanto a clareza do seu conteúdo e linguagem, bem como as mensagens de erro.
Pré entrar em cada tela e avaliar a facilidade de navegação entre as mesmas.
Realizar n operações e depois desfazê-las.
Realizar procedimentos críticos e avaliar mensagens de alerta.
Avaliar número de passos para realizar as principais operações.
Avaliar a existência de ajuda em todas as telas.
Realizar n buscas no manual de ajuda e validar os procedimentos sugeridos
Teste de Carga (Stress) - Categoria de teste destinado a avaliar como o sistema responde em condição anormais, provocando aumentos e reduções consecutivas de operações. O teste de carga no sistema abrange cargas de trabalho extremas, hardware e serviços indisponíveis, memória insuficiente ou recursos compartilhados limitados. 
Elevando e reduzindo sucessivamente o número de transações simultâneas
Aumentando e reduzindo o tráfego de rede
Aumentando o número de usuários simultâneos
Combinando todos estes elementos.
Teste de Volume - Categoria de teste que submete a aplicação a ser testada a grandes quantidades de dados para determinar os limites de processamento e carga do aplicativo, e toda a infraestrutura da solução. O teste de volume é executado através de incrementos sucessivos das operações realizadas com o sistema, até atingir o limite máximo de processamento da infraestrutura do software.
Aumentando sucessivamente o volume de transações.
Aumentando sucessivamente o volume de consultas.
Aumentando sucessivamente o tamanho de arquivos a serem processados
Teste de Configuração (Ambiente) - Categoria de teste que verifica se o software está apto a rodar em diferentes configurações de software e hardware, o objetivo é garantir que o aplicativo seja executado sobre os mais variados ambientes de produção.
Variando os sistemas operacionais (incluídas versões).
Variando os browsers.
Variando os hardwares que irão interagir com a solução.
Combinando todos esses elementos.
Teste de Compatibilidade (Versionamento) - Categoria de teste destinado a validar a capacidade do software em interagir com outras aplicações, versões anteriores e dispositivos físicos. O objetivo é garantir que novas versões suportem as antigas interfaces.
Importando-se os dados gerados pela solução anterior.
Comunicando-se com todas as versões anteriores e atuais.
Teste de Segurança - Categoria de teste que tem por objetivo detectar as falhas de segurança que podem comprometer o sigilo e a fidelidade das informações, bem como provocar perdas de dados ou interrupções de processamento.
Validando todos os requisitos de segurança identificados
Tentar acessar funcionalidades e informações que requerem perfil avançado.
Tentar invadir/derrubar o servidor de dados/internet.
Tentar extrair backups de informações sigilosas
Tentar descobrir senhas e quebrar protocolos de segurança
Tentar processar transações geradas de fontes inexistentes
Tentar simular comportamento/infecção por vírus.
Teste de Performance (Desempenho) - Categoria de teste destinado a determinar se o desempenho nas situações previstas de pico máximo de acesso e concorrência está consistente com os requisitos definidos.
Validar todos os requisitos de desempenho identificados
Simular n usuários acessando a mesma informação, de forma simultânea
Simular n usuários processando a mesma transação, de forma simultânea
Simular n% de tráfego de rede
Combinar todos esses elementos
Teste de instalação - Categoria de teste destinado a determinar se os procedimentos de instalação de uma aplicação, assim como avaliar se estes possibilitam as várias alternativas previstas nos requisitos identificados.
Pré efetuar a primeira instalação do software.
Realizar a instalação de um software já instalado.
Realizar a instalação de atualização de um software.
Efetuar todas as alternativas de instalação.
Validar pré-requisitos de instalação do software.
Teste de Confiabilidade e Disponibilidade - Categoria de teste destinado a monitorar o software por um determinado período de tempo e avaliar o nível de confiabilidade da arquitetura da solução. Já que as interrupções provenientes de defeitos de software prejudicariam os índices de confiabilidade e disponibilidade da aplicação.
Monitorar permanentemente o ambiente de aceite (alpha-teste)
Identificar todas as interrupções do ambiente (confiabilidade)
Identificar o tempo de interrupção do ambiente (disponibilidade)
Teste de Recuperação - Categoria de teste destinado a avaliar o comportamento do software após a ocorrência de um erro ou de determinadas condições anormais. Devem também contemplar os procedimentos de recuperação do estado inicial da transação interrompida, impedindo que determinados processamentos sejam realizados pela metade e sejam interpretados como completos.
Interrupção do acesso à rede: por alguns instantes ou por um longo período
Interrupção do processamento: através do desligamento do micro e através do desligamento do servidor
Geração de arquivos, cancelamento do processamento e avaliação dos arquivos gerados.
Teste de Contingência - Categoria de teste destinado a validar os procedimentos de contingência a serem aplicados à determinada situação prevista no planejamento do software. O objetivo é simular os cenários de contingências e avaliar a precisão dos procedimentos.
Instalação emergencial de uma aplicação
Recuperação da perda de conexão da filial com a matriz.
Aula 6 - Casos de testes
Nós vimos nas aulas anteriores que os métodos de verificação utilizam técnicas de testes estáticos para avaliar a qualidade dos documentos gerados durante todas as etapas do desenvolvimento do software. 
Porém para avaliarmos a qualidade de um sistema, os testes não podem ser estáticos precisam ser dinâmicos, pois devemos submeter o software a determinadas condições de uso de forma a avaliar se o comportamento está de acordo com o esperado. 
Desta forma torna-se necessário a utilização de uma forma sistémica de trabalho com o objetivo de identificar o maior número possível de situações de testes.
Isto é possível através da utilização de algumas técnicas para auxiliar na identificação dos diversos cenários de teste.
O que é um caso de teste: Os casos de testes são um conjunto de entradas de teste, condições de execução e resultados esperados desenvolvidos para testar o caminho de um programa ou verificar o cumprimento de um requisito específico. Os casos de teste refletem os requisitos que devem ser averiguados. A verificação pode ser realizada de forma variada e por profissionais distintos. Torna-se fundamental para o sucesso do projeto selecionar os requisitos mais importantes e adequados para o teste, pois:
Os casos de teste constituema base do design e do desenvolvimento dos Scripts de Teste.
Cada caso de teste reflete um cenário.
A "profundidade" do teste é proporcional ao número de casos de testes, gerando maior confiança no processo de teste e na qualidade do produto.
A escala do esforço de teste é proporcional ao número de casos de teste, é possível estimar com mais precisão a duração dos estágios subsequentes do ciclo de teste.
Requisitos teste de caixa preta
Estrutura Interna (teste de caixa branca)
Importância dos Casos de testes
Os métodos a serem utilizados mudam de acordo com a abordagem de testes a ser empregado, porém todas as formas básicas são fundamentais para garantir que o produto final seja adequado, cabe aos profissionais de testes produzirem um número suficiente de casos de testes para cada abordagem.
Métodos Caixa Preta para obtenção dos casos de Testes
Não tem como obtermos um software de qualidade sem a existência de um processo de desenvolvimento que assegure o comportamento do software comparando-o com requisitos funcionais estabelecidos no projeto. 
Os testes da caixa preta, já estudados na aula 4, são uma abordagem complementar aos testes de caixa branca, com a finalidade de identificar um conjunto de situações que serão empregadas em forma de testes para a identificação de erros.
É importante perceber que a variedade de cenários permitirá o maior conjunto de simulações que serão avaliadas e comparadas com os requisitos contratados, sendo então fundamental a utilização de métodos que permitam identificar o maior número de casos de testes, garantindo ampla variedade de cenários para a execução do sistema.
 
Os principais métodos de testes de caixa-preta para obtenção dos casos de testes são:
Métodos de decomposição de requisitos.
Métodos de Análise de Documentos.
Métodos de decomposição de requisitos - Os requisitos do software são elementos fundamentais nos processos de testes uma vez que originam os cenários de testes que por sua vez dão origem aos casos de testes. Cada requisito carrega em si um conjunto de cenários dentro da realidade de cada sistema.
A decomposição de um requisito em cenário é fundamental para descobrir todas as possibilidades envolvidas na dinâmica do software. É necessário explorar todos os cenários possíveis para cada requisito existente.
Destacam-se os três tipos de cenários que podem estar contidos nos requisitos:
Cenário Primário - É a situação mais básica de compreensão de um requisito de software. Trata-se da representação de um cenário perfeito que será usada como linha mestra para o entendimento de outros cenários existentes.
Cenário alternativo - São variações possíveis dentro do cenário primário, isto é, os caminhos alternativos ou situações equivalentes que conduzirão ao mesmo objetivo.
Cenário Exceção - Trata-se de possíveis problemas e inconsistências que impedem a finalização de determinado requisito. São todas as condições impeditivas que podem ocorrer a qualquer requisito.
Para o sistema de vendas, por exemplo, no módulo realizar pagamentos a decomposição nos três tipos de cenários estudados ficará:
Métodos de Análise de Documentos - Uma outra forma de decomposição poderá ser através da utilização de documentos e modelos, dependendo da metodologia de desenvolvimento usada. Qualquer documento pode conter elementos essenciais para auxiliar na localização de novos casos de testes e no refinamento e ampliação do esforço de planejamento dos testes.
Se por exemplo estiver sendo usada a orientação a objeto juntamente com a linguagem UML como padrão de documentação, as principais fontes para extrair os casos de testes são os destacados abaixo.
Diagramas de estado
Diagrama de estado – que representa um estado ou situação em que um objeto pode se encontrar no decorrer da execução de processos de um sistema. Com isso, o objeto pode passar de um estado inicial para um estado final através de uma transição.
Podemos por exemplo, pensar no diagrama de estado do ciclo de vida de um livro. Cada transição de um estado para outro do livro deverá ser considerada um caso de teste (cenários positivos), enquanto que as transições “proibidas” deverão ser inseridas como cenários negativos, uma que também deverão ser testadas.
Diagrama de atividades – Representa todo o fluxo de processamento de um determinado evento de negócio, revelando todos os caminhos alternativos (caminhos positivos) e as situações que impossibilitam a finalização desse evento (cenários negativos).
Um bom diagrama de atividades deverá revelar o conjunto completo de casos de testes que deverão ser inseridos no planejamento de testes.
Métodos Caixa Branca para obtenção dos casos de Testes
Baseia-se num minucioso exame dos detalhes procedimentais do software, ou seja, a linha de código. São testados os caminhos lógicos através do software, fornecendo-se casos de teste que põem à prova conjuntos específicos de condições e laços. Esses cenários devem ser modelados de forma a atendar ao maior número de situações, exigindo o menor esforço possível para executá-los.
Os principais métodos de testes de caixa-branca para obtenção dos casos de testes são:
Aula 7 – Teste de Validação 
O teste de validação inicia-se no final do teste de integração, quando os componentes individuais foram executados, o software está completo e os erros de interface corrigidos.
Na etapa de validação ou no nível de sistema, a distinção entre o software convencional e orientado a objetos desaparece, o teste focaliza ações visíveis e saídas do sistema reconhecida pelo usuário.
A validação do software se torna bem-sucedida quando o software funciona de maneira adequadamente esperada pelo cliente, desta forma, é obtida por intermédio de uma série de testes que demonstram conformidade com os requisitos. O plano e o procedimento de teste são projetados para garantir que:
Fases dos testes de Validação - Nos testes de validação os mecanismos de testes estão segmentados em dois níveis de testes:
Baixo Nível – Teste de Unidade e Teste Integração
Alto Nível - Teste Sistema e Teste Aceitação
Baixo Nível – Teste de Unidade - O teste de unidade é realizado no estágio mais baixo da escala de teste, isto é, no código do programa e normalmente é realizado pelo desenvolvedor.  Concentra-se em cada unidade do software, de acordo com o que é implementado no código fonte. Utiliza as técnicas de teste de caixa branca e caixa preta. 
Este tipo de teste é aplicado nos menores componentes de código criado, visando garantir que estes atendem as especificações em termos de características e de funcionalidade.  
O teste de unidade foca na lógica interna de processamento e nas estruturas de dados dentro dos limites de um componente, conforme a figura ao lado.
Estrutura de dados local: A estrutura de dados local é examinada para garantir que os dados armazenados temporariamente mantenham sua integridade durante todos os passos na execução de um algoritmo.
Condições limite: As condições limite são testadas para garantir que o módulo opere adequadamente nas fronteiras estabelecidas para restringir ou limitar o processamento.
Caminhos independentes: Todos os caminhos independentes da estrutura de controle são usados para assegurar que todas as instruções em um módulo tenham sido executadas pelo menos uma vez.
Caminhos independentes: Todos os caminhos independentes da estrutura de controle são usados para assegurar que todas as instruções em um módulo tenham sido executadas pelo menos uma vez.
Casos de testes: Casos de testes deverão ser projetados para descobrir erros devido a computações errôneas, comparações incorretas ou fluxo de controle inadequado.
Procedimentos de teste de unidade
O teste de unidade é considerado um auxiliar para a etapa de codificação.  Podem ocorrer antes de começar a codificação ou depois que ocódigo-fonte tiver sido gerado. Como cada componente não é um programa independente deve ser construído um pseudocontrolador e/ou um pseudocontrolado para cada teste de unidade. 
Eles irão auxiliar no teste unitário já que um pseudocontrolador representa o “programa principal” que aceita dados do caso de teste e passa esses dados para o componente a ser testado. Já o pseudocontrolado utiliza a interface dos módulos subordinados, pode fazer uma manipulação de dados mínima através de verificação de entrada e retorno do controle para o módulo que está sendo testado.
Baixo Nível - Testes de Integração - O teste de integração focaliza o pacote de software completo e trata da verificação do programa como um todo. Este tipo de teste faz uso de técnicas de projeto de casos de teste que enfocam as entradas e saídas, além de exercitar caminhos específicos.
Mesmo que todos os módulos estejam funcionando individualmente, não se pode garantir que eles funcionarão em conjunto:
Os dados podem ser perdidos na interface;
A imprecisão aceitável individualmente de cada módulo pode ser amplificada no funcionamento em conjunto;
As estruturas de dados globais podem apresentar problemas;
Segundo Pressman, o teste de integração é uma técnica sistemática para construir a arquitetura do software enquanto se conduz testes para descobrir erros associados com as interfaces a partir dos componentes já testados através do teste de unidade. Existem basicamente duas abordagens que podem ser utilizadas:
Não incremental (big-Bang) - Neste tipo de abordagem todos os componentes são combinados com antecedência e o programa inteiro é testado de uma vez. Segundo Pressman, usualmente, o resultado desta abordagem é o caos, pois normalmente são encontrados muitos erros tornando a correção difícil, pois fica complicado isolar as causas dos erros. Uma vez corrigidos os erros, novos erros aparecem e o processo parece não ter fim.
Incremental - Este tipo de abordagem é a antítese da abordagem big-bang. O programa é construído e testado em pequenos incrementos. Os erros são mais fáceis de isolar e corrigir e pode ser aplicada uma interface sistemática de testes. Neste contexto existem várias estratégias incrementais de integração: 
Teste de regressão
Teste fumaça
Integração descendente ou Top-down
Integração ascendente ou Botton-up
Teste de Alto Nível - Testes de Sistema - O teste de sistema se refere ao comportamento de todo o sistema / produto definido pelo escopo de um projeto ou programa de desenvolvimento. Neste tipo de teste o ambiente de teste deve corresponder o máximo possível ao objetivo final, ou o ambiente de produção, para minimizar que os riscos de falhas específicas de ambiente não serem encontradas durante o teste.
O objetivo do teste de sistema é realizar a execução do sistema como um todo, dentro de um ambiente operacional controlado, para validar a exatidão e perfeição na execução de suas funções, acompanhando cenários sistêmicos elaborados pelo profissional de requisitos do projeto e devem retratar os requisitos funcionais e não-funcionais do sistema.   Normalmente este tipo de teste é realizado por uma equipe de teste independente, onde o analista de teste irá elaborar os casos de testes, normalmente em conjunto com os desenvolvedores e executando os testes em um ambiente controlado, no caso o ambiente de teste.
Os testes podem ser baseados em:
Especificação de riscos e/ou de requisitos, processos de negócios, casos
O teste de sistema é na realidade uma série de diferentes testes cuja finalidade primária é exercitar totalmente o sistema e que apesar de terem finalidades diferentes, todos funcionam no sentido de verificar se os elementos do sistema foram integrados adequadamente e executam as suas funções corretamente:
• Teste de desempenho
• Teste de disponibilização
• Teste de recuperação
• Teste de segurança
• Teste de esforço (estresse)
Testes de Aceitação - É impossível que se preveja como o cliente realmente usará um programa. As instruções de uso podem ser mal interpretadas, combinações estranhas de dados podem ser regularmente usadas, saídas que pareciam claras ao analista podem ser ininteligíveis para um usuário em campo. Desta forma o teste de aceitação é de responsabilidade do cliente. Dependendo da abrangência dos usuários podem ser aplicados de duas maneiras:
Software customizado para um cliente / Software desenvolvido como produto para muitos clientes
Software customizado para um cliente 
São realizados testes de aceitação, realizados pelo usuário final para capacitá-lo e para validar todos os requisitos.
Pode variar de um test drive informal a uma série de testes planejados.
Software desenvolvido como produto para muitos clientes 
Teste Alfa - É conduzido na instalação do desenvolvedor por um grupo representativo de usuários finais. O software é utilizado em um cenário natural e realizado em conjunto desenvolvedores e usuários, registrando os erros e os problemas de uso. Este tipo de teste normalmente é conduzido em um ambiente controlado.
Teste Beta - O teste Beta é conduzido nas instalações de um ou mais usuários finais e neste tipo de teste o desenvolvedor não deverá estar presente. O cliente registra todos os problemas encontrados durante o teste e vai relatando para o desenvolvedor em intervalos regulares. Com o resultado do teste beta, os desenvolvedores fazem as modificações necessárias e preparam a liberação do software para todos os clientes.
Existem muitas empresas que colocam versões beta de seus softwares na internet para que os usuários possam fazer o teste com o novo produto que neste caso, ainda não foi lançado oficialmente.
Aula 8 – Testware
Como já estudamos nas aulas anteriores, e segundo Pressman, 2005, na Engenharia de software, o teste é uma das etapas do ciclo de desenvolvimento de software que tem por objetivo executar um programa com a intenção de descobrir erros (Pressman 2005).
O teste contribui para a produtividade, confiabilidade e qualidade do software. Desta forma todos os cuidados existentes no desenvolvimento de um software também devem também existir no processo de desenvolvimento dos componentes que se referem à automação dos procedimentos de testes. Devemos considerar que apesar do testware ser um subproduto do processo de desenvolvimento de software e estão ligados um no outro.
Assim, torna-se necessário uma série de ações com o objetivo de tornar o processo de teste confiável e produtivo:
Criação e manutenção de ambientes de teste
Controle do ambiente de software através de um sistema de gerenciamento de configurações
Utilização de rotinas de backups (armazenamento periódico)
Criação de padrões de elaboração de documentos e relatórios
Equipe capacitada a utilizar ferramentas e metodologias de testes
Conceito de Testware - Segundo Bartie, testware são todos os produtos gerados nas fases de verificação e validação, incluindo todas as formas de documentação, automação e relatórios produzidos.
Assim como os engenheiros de software constroem softwares o trabalho dos engenheiros de teste é o teste.
Checklist
Planejamento e especificações de teste.
Rotinas automatizadas de execução de teste.
Casos de testes.
Massa de testes. 
Relatórios finais de validação de testes
Ambientes de Testes - A combinação entre os elementos de hardware e software, é chamada de infraestrutura. No processo de desenvolvimento de software, cada ciclo de vida do software necessita de uma infraestrutura e requer um local físico adequado, denominado ambiente.
"Ambiente é um local físico onde existe uma infraestrutura de hardware e software adequada a uma determinada missão."Desta forma cada ciclo do processo de desenvolvimento de software de software irá requer uma infraestrutura diferenciada, isto é, de um ambiente distinto.
Ambiente de desenvolvimento
 Este ambiente deverá fornecer toda a infraestrutura necessária de hardware e software para o desenvolvimentode um novo software. Ele deverá ser dividido em duas partes: 
Uma para atender as necessidades da equipe de desenvolvimento.
Outra para atender as necessidades de teste da própria equipe de desenvolvimento.
Quem utiliza este ambiente?
Deve estar disponível para a equipe de desenvolvimento, ou seja, os analistas e programadores.
No ambiente voltado exclusivamente para o segmento de teste dentro do ambiente de desenvolvimento deverão ser aplicados os testes de unidade e de integração, e que podem ser:
Aplicados pela própria equipe de desenvolvimento ou por equipe de teste independente.
Ambiente de Produção - Fornece toda a infraestrutura necessário de hardware e software para a o produto desempenhe totalmente as funcionalidades paras quais foi projetado.  Neste ambiente é garantido o controle do ambiente e segurança contra invasões. É através dos erros identificados neste ambiente é que pode mensurar o quanto o trabalho da equipe de qualidade de software está sendo efetivo.
No ambiente de Produção também são realizados testes de aceite, que neste caso será o Beta-teste. 
Neste tipo de teste apenas um grupo de usuários selecionados terá acesso a uma “nova versão” do produto.
Equipe de teste independente - Em um primeiro momento é possível empregar profissionais de desenvolvimento para compor as equipes de qualidade de software, porém é imprescindível que com o tempo esta equipe se profissionalize. 
Os profissionais que atuam na área de teste devem possuir cultura no processo de teste de software, nas metodologias empregas e nas ferramentas de automação que são bastante diferenciadas do processo de desenvolvimento.
O papel de um grupo independente de teste é remover os problemas associados ao fato de deixar o desenvolvedor testar o software que ele mesmo criou. O teste independente remove o conflito de interesses que, de outra forma, poderia estar presente.
A equipe independente de teste faz parte da equipe de desenvolvimento de software no sentido de que ela se envolve durante a análise, e o projeto e permanece envolvido (planejando e especificando procedimentos de teste) durante o projeto inteiro.  
É comum em muitos casos a equipe de teste responder a organização de garantia de qualidade de software para, desta forma, obter um grau de independência que poderia não ser possível se fizesse parte da organização de engenharia de software.
Gestão e aferição da qualidade dos produtos de software - Assim para a gestão e aferição da qualidade dos produtos de softwares desenvolvidos as organizações podem estar estruturadas de diferentes formas:
Gerência da qualidade 
 Pode estar centralizada em uma única gerência que contemple os aspectos da qualidade, como já estudamos. Poderá ainda estar segmentada por uma destas especializações:
Gerência da Qualidade de software 
Área responsável pela garantia da qualidade do software. Responde pelo gerenciamento dos profissionais de qualidade envolvidos na verificação das diversas etapas de um processo de engenharia de software e está voltada para a gestão da garantia da qualidade de software, ou seja, tem como objetivo verificar a aderência entre o processo de desenvolvimento estabelecido e as práticas dos diversos profissionais envolvidos no processo.
Gerência de teste de software 
Área responsável pelo gerenciamento de todo o processo de testes de software da organização. Sua atuação está voltada especificamente à estruturação e condução de um processo de teste de software consistente, ou seja, na validação do produto tecnológico que está sendo produzido e não em garantir a adequada realização do processo de engenharia de software.
Equipe de teste - Existem diferentes papéis com diferentes reponsabilidades dentro de uma equipe de teste independente, que podem ser, por exemplo:
Aula – 9
Gestão das ferramentas de apoio a testes - O emprego de ferramentas de apoio ao processo de testes é tão relevante quanto às ferramentas que apoiam o processo de desenvolvimento de software.
As ferramentas de apoio podem auxiliar no gerenciamento e na elaboração de checklists, nas atividades de gestão de documentos e controles de suas versões, e em outras atividades desenvolvidas.
Automação de teste - A diferença entre testes e automação de testes, é que no primeiro você realiza a tarefa de testar, e no segundo você usa um software que imita a interação com a aplicação no que se refere ao teste tal qual um ser humano faria (Graham e Fewster,1999). 
Basicamente os testes de software podem ocorrer de duas formas:
Testes Manuais - É a utilização de recursos humanos para realizar todos os procedimentos de testes especificados. Este tipo de teste requer um número muito grande de profissionais e um controle eficiente de documentos em circulação.
O risco inerente a esse tipo de teste é a grande incidência de erros humanos no processo devido:
A não-execução dos procedimentos na ordem estabelecida;
Aos valores digitados erradamente.
Testes automatizados - utilizam ferramentas de testes que possibilitem simular usuários ou atividades humanas de forma a não requere procedimentos manuais no processo de execução dos testes.
Entretanto requerem profissionais especializados e tempo no desenvolvimento da automação dos testes.
Tipos de testes automatizados (progressivos e regressivos) - A automação de teste deve ser vista, em dois sentidos:
Teste Regressivo - Quando temos nova versão de software e comparamos com a versão anterior, o teste é em função de algo do passado.
Teste Progressivo - Quando utilizamos um script de teste de desempenho para simular a quantidade de 1.000 usuários virtuais e depois reexecutamos numa nova versão do sistema usando agora 2.000, desejamos ver o comportamento futuro do sistema.
Ferramentas de teste automatizado de software - As revisões e testes são instrumentos de controle de qualidade de um projeto. Existem diversas ferramentas de apoio a tais atividades, que variam tanto quanto a parâmetros como técnicas implementadas e linguagens suportadas:
Ferramentas de Planejamento de testes.
Ferramentas de Modelagem e Automação.
Ferramentas de Suporte aos Testes.
Ferramentas de execução e conferência.
Ferramentas de Revisões e Inspeções.
Para um bom desempenho do processo de automatização estas ferramentas devem ser integradas entre si.
Ferramentas de planejamento de testes - Esta categoria de ferramenta apoia a fase de planejamento dos testes, definindo escopos, abordagens, recursos e programando atividades. As ferramentas de planejamento de teste auxiliam também no processo de documentação, possibilitando:
Gerar planejamentos padronizados.
Elaborar estimativas de tempo e custos.
Dimensionar as equipes de acordo com o tempo disponível.
Análise de Criticidade - Apoiam o processo de priorização de sistemas, identificando quais os sistemas devem ser testados, permitindo:
Direcionar os esforços de forma eficiente.
Gerar resultados em curto espaço de tempo.
Estimar tempo, custos e equipes através da análise de complexidade de cada software.
Gerador de documentos – facilitam o processo de documentação, através do uso de parametrizações e templates de documentos, permitindo:
Gerenciar as versões de modelos.
Organização de um work-flow de preparação
Elaboração, inspeção e aceite de documentos 
Ferramentas de revisões e inspeções - Esta categoria de ferramenta apoia o processo de verificação do software, auxiliam nas tarefas de revisões dos documentos e nas inspeções técnicas. Suas principais características são a:
Análise de complexidade - Auxilia a identificar onde estão as áreas mais complexas e quais possuem maior risco de introduzir novos erros, além de quantificar o esforço e os custos dos testes a serem empregados.
Compreensão de código -Auxilia a inspecionar os códigos-fontes, possibilitando avaliar a aderência a padrõesde programação estabelecidos pela organização, como por exemplo:
Padrão de nome,
Utilização de rotinas corporativas,
Variáveis não utilizadas, 
Sub-rotinas internas não acionadas, 
APIs incompatíveis com determinados sistemas operacionais.
Análise sintática e de semântica -Localiza erros na sintaxe e na semântica dos comandos empregados no código, os quais o compilador não acusaria, sendo possível detectar defeitos antes de os testes formais serem iniciados.
Ferramentas de modelagem e automação - As ferramentas de modelagem auxiliam no processo de construção e documentação de como serão testados todos os requisitos de negócio, possibilitando registrar todos os procedimentos de teste a cada cenário estabelecido e ainda o processo de conferência dos dados.
Estas ferramentas possibilitam o desenvolvimento de scripts automatizados. As principais características destas ferramentas são:
Modelagem de testes - Auxilia nos processos de planejamento e construção dos testes, identificado os diversos cenários estabelecidos para cada requisito a ser testado. Determina as informações que devem ser empregadas em cada procedimento de teste, atingindo o menor nível de detalhamento. 
Vale ressaltar que a modelagem dos testes é um processo mental, assim nenhuma ferramenta substituirá a experiência e abstração de um bom analista de testes, porém estas ferramentas auxiliam na estruturação das ideias.
Geração de massa de dados - Possibilita a geração automática de massa de dados baseada no planejamento dos testes e critérios estabelecidos de forma a garantir uma massa diferenciada e nas circunstâncias desejadas.
Automação de scripts - Possibilita a interação entre as rotinas automatizadas e os softwares a serem testados através da captura de valores em telas, arquivos, relatórios ou mesmo em banco de dados. Permitem automatizar não somente as atividades de entrada de informações, como o processo de conferência (análise da saída das informações).
Ferramentas de execução e conferência - As ferramentas de execução e conferência possibilitam o gerenciamento e o controle do processo de execução, reexecução e medição dos testes planejados.  Possibilitam integração entre as demais fases, de forma a executar os testes selecionados no planejamento.
As principais características destas ferramentas são:
Executor de scripts - Possibilita a interação entre as rotinas automatizadas e os softwares a serem testados através da captura de valores em telas, arquivos, relatórios ou mesmo em banco de dados. Permitem automatizar não somente as atividades de entrada de informações, como o processo de conferência (análise da saída das informações).
Análise de cobertura - Possibilita estabelecer uma métrica de cobertura do teste através do monitoramento das linhas de código executadas. Os testes de caixa branca requerem esse tipo de ferramenta, pois possibilita visualizar áreas do código não cobertas pelos testes em execução.
Como as ferramentas de execução e conferência são normalmente integradas aos softwares de planejamento de testes e desenvolvimento de scripts, o executor de scripts permite executar os procedimentos na ordem e frequências preestabelecidas. Permite também a gestão do ciclo de testes como um todo, com o controle de execução de cada caso de testes, o controle da reexecução dos testes e os desvios de testes provocados por erros inesperados.
Simuladores e medidores de performance - Estão diretamente ligadas aos testes de sistema, como os testes de carga, volume e performance, já que nessa categoria é impossível conceber a ideia de realizar testes sem empregar ferramentas específicas.
Testadores de memória - Auxiliam no processo de detecção de problemas em relação ao uso e alocação de memória pela aplicação. Sendo assim devem ser específicas para cada linguagem e ambiente.
Ferramentas de suporte aos testes - Estas ferramentas apoiam atividades que não estão diretamente ligadas ao processo de testes, porém garantem que determinados itens fundamentais desse processo estão sendo bem gerenciados.
As principais características destas ferramentas são: Gerenciamento de defeitos e gerenciamento de configurações.
Gerenciamento de defeitos - Tem como objetivo acompanhar e controlar os defeitos identificados durante o ciclo de vida do software e monitorá-los até a sua solução final, através da produção de um grande número de indicadores de qualidade. Permite parametrizações de forma a customizar um workflow de resolução de problemas, para melhor adapta-se a estrutura da empresa.  Também é conhecido por: gerenciamento de erros, gerenciamento de problemas, registro de ocorrências, controle de incidências.
Gerenciamento de configurações - Permite controlar e coordenar as mudanças efetuadas em documentações, fontes e ambientes físicos.  Estabelece a relação entre os artefatos de software e identifica-los através de um único controle de versão enquanto ocorre modificações de fontes de uma versão anterior.
Projeto de automação de teste - Um projeto de automação de teste é um investimento alto e de longa duração, e por isso mesmo os dirigentes das organizações obviamente tem expectativas em relação a custos e aos benefícios trazidos pela sua implementação. Por isso um projeto de automação de testes deve ser cercado de alguns cuidados:
Infraestrutura - Disponibilidade de máquina e seus recursos, um projeto em desenvolvimento (em fase de testes) dedicado para o projeto de automação de testes.
Metodologia - Existência de metodologias de desenvolvimento e testes consolidadas e usadas, que possam se integrar com a ferramenta escolhida.
Ferramenta - Seleção da ferramenta certa, adequada à tecnologia usada e que possa integrar com as metodologias de desenvolvimento e teste.
Quais casos de testes são candidatos a automatização? - A cada nova versão de um software torna-se necessário realizar um novo conjunto de teste, visando ampliar as melhorias implementadas. Desta forma também é necessário reexecutar um conjunto de casos de testes (todos ou partes) de forma a avaliar se as mudanças realizadas danificaram outras partes do software que já funcionava.
Os custos relativos à execução dos testes de progressão não são importantes. Porém são importantes os custos de execução dos testes de regressão, pois estes devem ser reexecutados ao longo do ciclo de vida do software.
Desta forma devemos considerar que os testes automatizados visam a otimização da execução dos testes, mas deve ser feito, preventivamente, um estudo de viabilidade técnica e um estudo de custo benefício para sua utilização ou não. 
Os testes automatizados não substituem os testes manuais, eles são complementares e para isso devemos levar em consideração que todo caso de teste é naturalmente candidato à automação, mas naturalmente nem todos são recomendáveis para automação:
 
O caso de teste for algo pontual e específico de alguma versão do software e não se espera que seja testado em versões futuras, não é candidato à automação.
O caso de teste tiver características de uso de uma grande massa de dados, indica ser um data-driven test que precisará provavelmente ser automatizado. 
Existe tempo hábil para automatizar o teste desejado devido ao cronograma, então ele não será momentaneamente um teste a ser automatizado. 
Aula 10 – 
Documentação - Documentar é fundamental para formalizar o processo de qualidade, o conteúdo da documentação deve ser claro e bem definido, constando todos os itens que devem ser abordados, possibilitando que todos os envolvidos no processo de avaliação da qualidade possam:
Acompanhar a evolução do trabalho.
Rastrear como as atividades foram planejadas
Verificar em que condições foram executadas e quais defeitos foram identificados.
Neste contexto é importante perceber a importância da documentação tendo em vista que:
O software existe inicialmente na forma de documentos.
A qualidade do produto final depende da qualidade da documentação
Os documentos são meios de comunicação entre