Aula 5 - Avaliação de SW

Prévia do material em texto

Unidade III – Testes de Validação 
11 – Entendendo os Testes 
Unidade III 
Avaliação de Software 
Prof. Ulisses Sperle Graça 
Abr/2013 
2 
 Diferentemente dos testes de verificação que 
avaliam as atividades e documentações com o objetivo de 
detectar erros e quebras no processo, os testes de 
validação visam o produto computacional que é executado. 
Buscaremos todos os meios e recursos possíveis para 
criar uma infraestrutura que possibilite o maior número 
de erros com o menor esforço. 
O sucesso da validação está apoiado em um forte 
planejamento de todas as atividades de teste, nas quais a 
concentração dos trabalhos nos componentes mais 
complexos e nos requisitos mais críticos, uma vez que 
concentram a maior quantidade de erros. 
Fazendo uma Reflexão 
3 
 Os testes envolvem a execução total ou parcial do 
software, porém dentro de uma das duas abordagens abaixo: 
Estratégias Fundamentais 
 
Caixa 
Branca 
 
Caixa 
Preta 
 A estratégia escolhida determina o modo como serão 
conduzidos os testes, visando diminuir o esforço e ampliar as 
chances de detecção. 
Essas abordagens são complementares e não exclusivas, o que 
significa que teremos um produto de maior qualidade se ambas 
forem aplicadas. 
4 
 São baseados na estrutura interna do software. 
Empregam técnicas que objetivam identificar defeitos nas 
estruturas internas dos programas através da simulação de 
situações que exercitem adequadamente todas as estruturas 
na codificação. 
Estratégia de Caixa Branca 
Término do 
Processamento 
Início do 
Processamento 
Caminho A 
Caminho B 
5 
É necessário que o profissional conheça a tecnologia 
empregada, bem como conhecimento adequado da arquitetura 
interna. Deverá ter acesso a fontes, estruturas dos banco de 
dados e realizar os testes previstos no processo de validação 
dos componentes. 
Estes testes são conhecidos pela sua alta eficiência e difícil 
implantação. 
Uma área independente de testes pode ser inicialmente mais 
cara, porém gerará resultados mais rápidos e significativos. 
Lembre-se que a área de desenvolvimento tem por meta 
“construir softwares” e será cobrada por isso. Se pressionada 
ela poderá sacrificar os testes, diferentemente do ITG. 
Estratégia de Caixa Branca 
6 
Utiliza técnicas para garantir que os requisitos são plenamente 
atendidos pelo software construído, ou seja, se o algoritmo produz os 
resultados esperados. 
A grande vantagem é o fato de não requerer conhecimento da 
tecnologia empregada ou dos complexos conceitos de implementação, o 
que reduz a dificuldade de encontrar um profissional capacitado. 
Requer o conhecimento dos requisitos, suas características e 
comportamentos esperados, para que seja possível avaliar o software 
através dos resultados gerados. 
Estratégia de Caixa Preta 
Resultados 
Gerados 
Estímulos 
Produzidos 
7 
São conhecidos por serem mais simples de implementar, porém 
ambos são complexos e exigem alto grau de planejamento. 
O grande desafio de se implantar o método caixa preta é 
convencer a área que já executa as atividades de homologação 
e começar a exigir um planejamento mais apurado 
transparente, e introduzir um processo automatizado e 
confiável. 
Estratégia de Caixa Preta 
8 
Abordagens Fundamentais dos Testes 
 
Caixa Branca 
 
Caixa Preta 
Testes Baseados na Estrutura Interna Testes Baseados nos Requisitos 
9 
Todo o direcionamento dos testes (testdrivers) será 
baseado exclusivamente em requisitos ou na estrutura 
interna do código-fonte a ser implementado. 
 Cada uma dessas abordagens possui um conjunto de 
métodos de diferentes planejamentos e obtenção de 
testes de validação. 
Cabe aos profissionais de teste buscar a forma mais 
eficiente e adequada à realização dessas atividades. 
Abordagens Fundamentais dos Testes 
10 
Requer um conhecimento profundo da tecnologia e do projeto 
desenvolvido, de forma a exercitarem adequadamente todas as 
estruturas internas (estruturas de controle), visando a validação de 
todos os algoritmos empregados. 
Como os testes exigem o conhecimento interno do software, aqui 
sempre empregaremos a estratégia caixa branca para abordá-los. 
Testes Baseados na Estrutura Interna 
11 
São baseados nos documentos de requisitos e modelados através de 
especificações funcionais suplementares. 
Requisitos devem ser decompostos em casos de teste de forma a 
avaliarem os cenários existentes e validarem todas as variações. 
Como pode ser aplicados sem conhecimento da estrutura interna 
(como o código-fonte foi escrito), estes testes empregam a 
estratégia de Caixa Preta. 
Testes Baseados em Requisitos 
12 
Qualquer processo de desenvolvimento deve acomodar um modelo 
eficiente para incorporar mudanças. 
Estas mudanças provocam alterações estruturais que afetam 
funcionalidades já implementadas, gerando defeitos em pontos 
anteriormente perfeitos. 
A maior parte dos esforços dos testes está concentrada nas 
funcionalidades recém construídas ou modificadas, não existindo 
qualquer mecanismo que avalie se essas mudanças provocaram 
problemas em outras funcionalidades existentes, aumentando 
consideravelmente os riscos de uma pequena mudança gerar 
problemas no ambiente de produção. 
Progressividade e Regressividade dos Testes 
13 
Progressividade e Regressividade dos Testes 
Cenário Versão “A” 
Cliente 
VIP 
Cliente 
Normal 
Pedidos 
Cliente 
VIP 
Cliente 
Normal 
Pedidos 
Cliente 
Ocasional 
Cliente 
VIP 
Cliente 
Normal 
Pedidos 
Cliente 
Ocasional 
Cenário Versão “B” Cenário Versão “B.1” 
Erro ! 
14 
Todos os testes nascem como testes de progressão e 
acabam tornando posteriormente testes de regressão. 
São elaborados de acordo com a evolução do produto. 
À medida que o software ganha novas funcionalidades, um 
novo conjunto de testes deve ser criado. 
Aqui, somente é necessário testar as inovações do 
software, assumindo que nenhum erro foi introduzido após 
seu processo de desenvolvimento 
Testes Progressivos 
15 
Trata-se de reexecutar um subconjunto (total ou parcial) 
de testes previamente executados. 
Seu objetivo é assegurar que as alterações ou inserções d 
determinados segmentos (durante uma manutenção ou 
melhorias implementadas) não afetaram outras partes do 
produto. 
Toda nova versão do produto deveria ser submetida a uma 
nova sessão de testes para detectar impactos em outras 
funcionalidades. 
Testes Regressivos 
Unidade III – Testes de Validação 
12 – Categorias de Testes 
Unidade III 
Avaliação de Software 
Prof. Ulisses Sperle Graça 
Abr/2013 
17 
Muitos profissionais têm dificuldades em distinguir as diversas 
motivações do teste. 
Se não temos tempo e nem recursos suficientes para executar 
todos os procedimentos de teste, devemos planejar uma 
estratégia na qual estabelecemos quais tipos de erros 
queremos prioritariamente encontrar. 
É comum observarmos que os cenários de teste são muitas 
vezes dispersivos, pois buscam identificar toda natureza de 
defeitos. 
Misturar categorias de testes (usabilidade, funcionais, carga, 
performance, contingência etc.) faz com que os trabalhos de 
levantamento sejam superficiais e incompletos. 
Categorias de Teste 
18 
Levantamento de cenários 
- simular saques acima do saldo disponível; 
- simular saques com cartão vencido; 
- avaliar se a duração do saque dura até 30 seg. num 
universo de 5 milhões de correntistas e 100 milhões de 
movimentação bancária; 
- simular saque com defeito no “cash-dispenser”; 
- simular saque com impressora do fornecedor A, B e C; 
- avaliar se a senha do cartão esta sendo requisitada antes 
e depois da transação; 
- simular 2 saquessimultâneos na mesma conta-corrente; 
- simular saque na conta-poupança; 
- avaliar se a senha adicional e randômica esta sendo 
requisitada no início da operação. 
- simular saques no Windows 95, 98, NT e 2000; 
- avaliar se todas as telas possuem ajuda; 
Cenários de Testes 
Transfe
rência 
 
Depósito 
 
Saque 
Sem os conceitos de categorização 
19 
Se focarmos em uma única categoria de teste, poderemos melhorar o 
processo. 
É claro que determinadas categorias de importância reduzida (baixo 
risco) poderão ser planejadas em conjunto. 
A nossa preocupação é sempre com as categorias mais complexas e 
importantes, que exigem maior esforço e alto nível de qualidade dos 
levantamentos. 
Não podemos deixar que categorias críticas sejam prejudicadas por 
outras de menor importância. 
Percebemos facilmente na tabela a seguir, que a categorização de 
cenário possibilita organizar melhor todo o planejamento e que é mais 
simples refinar cenários de testes quando agrupamos em categorias, 
o que amplia a cobertura e eficiência. 
Organizando em Categorias de Teste 
20 
- simular saques acima do 
saldo disponível; 
- simular saque na conta-
poupança; 
- simular saque acima do 
valor do limite da conta; 
- simular saque com valores 
não múltiplos das notas; 
- simular saque com valores 
não múltiplos das notas; 
Funcional 
- avaliar se a duração do 
saque dura até 30 seg. num 
universo de 5 milhões de 
correntistas e 100 milhões de 
movimentação bancária; 
- garantir que manipulação 
com dispositivos físicos no 
saque não ultrapassem 10 
seg. da operação; 
 
Performance 
- avaliar se todas as telas 
possuem ajuda; 
- avaliar se 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; 
Usabilidade 
- simular saques com cartão 
vencido; 
- avaliar se a senha do cartão 
esta sendo requisitada antes 
e depois da transação; 
- avaliar se a senha adicional 
e randômica esta sendo 
requisitada no início da 
operação; 
- simular saque noturno 
acima do valor permitido; 
Segurança 
- simular 2 saques 
simultâneos na mesma conta-
corrente; 
- simular 10.000 saques 
simultâneos; 
Carga e Concorrência 
- disparar processo de 
instalação emergencial; 
 
Contingência 
- 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; 
Recuperaçã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; 
Configuração 
Com os conceitos de categorização 
Organizando em Categorias de Teste 
21 
Cada categoria possui seu ciclo de testes independente, uma vez que 
suas naturezas são muitas vezes conflitantes. 
Ex: testes funcionais e de performance ao mesmo tempo. 
Organizando em Categorias de Teste 
22 
Visando aumentar a eficiência dos testes, é fundamental que o 
levantamento dessas informações ocorra por categoria. 
Durante o planejamento dos testes, devemos estudar quais categorias 
serão aplicadas a após isso,identificaremos todos os cenários 
existentes para cada transação a ser estudada. 
Esta categorização estabelecerá como serão organizados e 
estruturados os cenários possibilitando trabalhos mais objetivos e 
focados. 
Entendendo as Categorias de Testes 
23 
Comparação entre levantamentos de testes 
Entendendo as Categorias de Testes 
Testes sem Categorização 
(sem foco) 
Testes com Categorização 
(com foco) 
1. Levantamentos unificados 1. Levantamentos categorizados 
2. Superficialidade do levantamento 2. Profundidade dos levantamentos 
3. Única documentação dos testes 3. Documentos categorizados 
4. Visão única dos testes 4. Visão categorizada dos testes 
5. Falta de priorização das categorias 5. Priorização das categorias 
6. Falta de métricas para cada categoria 6. Métricas de esforço e eficiência 
das categorias 
7. Aplicação de todas as categorias sem 
avaliação 
7. Somente categorias relevantes são 
aplicadas 
8. Dificuldade em segregar a execução 
dos testes 
8. Execuções separadas de testes, 
flexibilizando a operação 
24 
Verificação da Implementação 
 
Desempenho 
 
Portabilidade 
 
Configuração 
 
Funcional 
 
Recuperação 
 
Usabilidade 
 
Saque 
Cada categoria possui um determinado objetivo a ser alcançado, e 
que define o propósito dos testes e um escopo das ações e 
planejamentos desses trabalhos. Sem este escopo existiria uma 
dispersão natural dos esforços. 
25 
Tem o objetivo de simular todos os cenários de negócio e 
garantir que todos os requisitos funcionais foram testados 
e exigem profundo conhecimento das regras do negócio, 
para que todas as variações possíveis sejam simuladas. 
Estes testes devem ser direcionados pelos documentos de 
especificação funcional. 
São caracterizados pelo foco em negócios. 
Trata-se da categoria mais prioritária entre as demais, 
pois representa a aderência do software em relação às 
regras de negócio 
Teste de Funcionalidade 
26 
Estes testes podem ser executados validando as seguintes situações: 
 As pré-condições de uma transação de negócios; 
 O fluxo de dados de uma transação de negócios; 
 O cenário primário de uma transação de negócios; 
 Os cenários alternativos de transação de negócios; 
 Os cenários d exceção de transação de negócios; 
 As pós condições de transação de negócios; 
Teste de Funcionalidade 
27 
Tem o objetivo de simular as condições de utilização do 
software sobre a perspectiva do usuário final. 
Focalizam a facilidade de navegação, clareza do texto e 
mensagens ao usuário, mecanismo de apoio, volume 
reduzido de interações, padronização visual, entre outros, 
de forma a deixar o software mais simples e intuitivo. 
Teste de Usabilidade 
28 
Estes testes podem ser executados validando as seguintes situações: 
 Entrar em cada tela a avaliar a facilidade de navegação; 
 Realizar n operações e depois desfazê-las; 
 Realizar procedimentos críticos e avaliar mensagem de alerta; 
 Avaliar número de passos para realizar as principais operações; 
 Avaliar a existência d ajuda em todas as telas; 
 Realizar n buscas no manual de ajuda a validar os 
procedimentos sugeridos. 
 
Teste de Usabilidade 
29 
Tem o objetivo de simular as condições atípicas de 
utilização do software, provocando aumentos e reduções 
sucessivas de transações que superem os volumes máximos 
previstos, gerando contínuas situações de pico e avaliando 
como o software e toda a infraestrutura estão se 
comportando. 
São recomendados para softwares de missão crítica, pois 
requerem muito esforço na operacionalização. 
Teste de Carga (Stress) 
30 
Estes testes podem ser executados da seguinte forma: 
 Elevando e reduzindo sucessivamente o número de transações 
simultâneas; 
 Aumentando e reduzindo o tráfego na rede; 
 Aumentando o número de usuários simultâneos; 
 Combinando todos esses elementos. 
 
Teste de Carga (Stress) 
31 
Tem o objetivo determinar os limites de processamento e 
carga do software e de toda a infraestrutura. 
Contrário ao teste de carga, esse tipo não focaliza 
oscilações d processamento, mas o aumento contínuo dos 
parâmetros de execução. 
A ideia é conhecer os limites da solução e avaliar o quão 
próximo ou distante esses requisitos estão deste limite. 
Teste de Volume 
32 
Estes testes podem ser executados da seguinte forma: 
 Aumentando sucessivamente o volume de transações; 
 Aumentandosucessivamente o volume de consultas; 
 Aumentando sucessivamente o tamanho de arquivos a serem 
processados. 
Teste de Volume 
33 
Tem o objetivo executar o software sobre diversas 
configurações d software e hardware. 
A ideia é garantir que a solução “rode” adequadamente 
sobre os mais diversos ambientes de produção previstos 
no levantamento d requisitos. 
São recomendados para serem aplicados em software de 
missão crítica, pois requerem muito esforço para 
operacionalizá-los 
Teste de Configuração (Ambiente) 
34 
Estes testes podem ser executados da seguinte forma: 
 Variando os sistemas operacionais Incluindo versões); 
 Variando browsers; 
 Variando os hardwares que irão interagir com a solução; 
 Combinando todos estes elementos. 
Teste de Configuração (Ambiente) 
35 
Tem o objetivo executar o software interagindo com as 
versões anteriores de outras aplicações ou dispositivos 
físicos (software ou hardware). 
Durante procedimentos de mudança, é comum ocorrer a 
“quebra de compatibilidade” de uma versão mais recente 
com a anterior. 
Teste de Compatibilidade (Versionamento) 
36 
Estes testes podem ser executados da seguinte forma: 
 Importando-se dados gerados pela solução anterior; 
 Comunicando-se com todas as versões de layout (atual e 
anteriores). 
Teste de Compatibilidade (Versionamento) 
37 
Tem o objetivo detectar as falhas que podem 
comprometer o sigilo e a fidelidade das informações, bem 
como provocar perdas de dados ou interrupções de 
processamento. 
Estes ataques podem ter origem interna ou externa. 
A ideia é avaliar o nível de segurança que toda a 
infraestrutura oferece simulando situações que provoquem 
a quebra de protocolos de segurança expondo as 
fragilidades. 
Teste de Segurança 
38 
Estes testes podem ser executados da seguinte forma: 
 Validar todos os requisitos de segurança identificados; 
 Tentar acessar funcionalidades 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 por fontes inexistentes; 
 Tentar simular comportamento/infecção por vírus. 
Teste de Segurança 
39 
Tem o objetivo determinar se o desempenho, nas 
situações previstas de pico máximo de acesso e 
concorrência, está consistente com os requisitos 
definidos. 
Para estes testes, devemos especificar claramente o 
cenário que desejamos obter e apontar quais são os 
tempos de resposta considerados factíveis à realização de 
cada um. 
Teste de Performance (Desempenho) 
40 
Estes testes podem ser executados da seguinte forma: 
 Validar todos os requisitos de desempenho identificados; 
 Simular n usuários acessando a mesma informação, de forma 
simultânea; 
 Simular n usuários acessando a mesma transação, de forma 
simultânea; 
 Simular n% de tráfego de rede; 
 Combinar todos estes elementos. 
Teste de Performance (Desempenho) 
41 
Tem o objetivo validar os procedimentos de instalação de 
uma aplicação, bem como avaliar se estes possibilitam as 
várias alternativas previstas nos requisitos identificados. 
A ideia é aplicar as muitas variações de instalação (normal 
e alternativas) a avaliar seu comportamento durantes 
estes procedimentos. 
Recomenda-se que o próprio usuário realiza estas 
instalações. 
 
Teste de Instalação 
42 
Estes testes podem ser executados da seguinte forma: 
 Realizar 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; 
 Realizar a instalação de software em vários ambientes 
distintos; 
 Realizar todas as alternativas de instalação; 
 Validar pré requisitos de instalação de software. 
Teste de Instalação 
43 
Tem o objetivo de monitorar o software por um determinado 
período de tempo e avaliar o nível de confiabilidade da 
arquitetura da solução. 
Estas informações devem ser coletadas durante a execução dos 
próprios testes de sistema. Identificando sempre quando uma 
interrupção foi produzida por uma falha da infraestrutura 
(confiabilidade) e contabilizando o tempo necessário para a 
resolução do problema (disponibilidade). 
Estas monitorações são interessantes de serem realizadas 
junto com os testes de aceite (alpha-teste), nos quais o 
ambiente ficam totalmente disponíveis para os usuários e a 
incidência de falhas está geralmente associada à 
infraestrutura. Os defeitos do software também afetam 
estes índices. 
Teste de Confiabilidade e Disponibilidade 
44 
Estes testes podem ser executados da seguinte forma: 
 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 Confiabilidade e Disponibilidade 
45 
Tem o objetivo de avaliar o comportamento do software após a 
ocorrência de um erro ou de determinadas condições anormais. 
Algumas aplicações suportam soluções de missão crítica, 
exigindo alto índice de disponibilidade do software. 
Nesse caso, a arquitetura da aplicação deve ser tolerante a 
falhas, ou seja, no caso de erros de qualquer natureza, o 
software deve ter capacidade de se manter em execução até 
que a condição d impedimento desapareça. 
Os testes de recuperação 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. 
Teste de Recuperação 
46 
Estes testes podem ser executados da seguinte forma: 
 Interromper o acesso à rede; 
• Por alguns instantes; 
• Por um longo período. 
 Interromper o processamento; 
• Desligar o micro; 
• Desligar os servidor. 
 Gerar arquivos, cancelar o processamento e avaliar se existem 
arquivos gerados. 
Teste de Recuperação 
47 
Tem o objetivo de validar os procedimentos d contingência a 
serem aplicados à determinada situação prevista no 
planejamento. 
A ideia é simular cenários de contingência a avaliar a precisão 
dos procedimentos. 
Esses testes devem ser realizados pela própria equipe de 
plantão, no qual o tempo de execução do referido plano também 
será avaliado. 
Teste de Contingência 
48 
Estes testes podem ser executados da seguinte forma: 
 Instalação emergencial de uma aplicação; 
 Recuperação da perda de conexão da filial com a matriz. 
Teste de Contingência 
49 
Um único sistema poderá ser submetido a várias categorias de testes. 
O critério para estabelecer quais categorias serão executadas deve 
estar baseado nas características dos sistema e dos riscos envolvidos. 
Existe uma relação delicada entre custo e benefício dos trabalhos de 
teste. 
As categorias mais importantes são aquelas que irão garantir aspectos 
vitais do software. 
O fundamental é entender que existe um esforço e custos envolvidos 
na decisão de empregar ou não determinada categoria. 
Priorizando as Categorias de Testes 
50 
Um instrumento simples é a priorização das categorias 
dentro da perspectiva d importância e risco. 
Todos os esforços serão concentrados nas categorias 
prioritárias, por serem mais críticas. As demais deverão 
ser realizadas posteriormente caso exista tempo e 
recursos para tal. 
Uma forma eficiente de priorizar é idealizar uma tabela na 
qual serão avaliadas as características mais críticas e 
submetê-las a todas as áreas que estão participando do 
processo de desenvolvimento da aplicação. 
Priorizando as Categorias de Testes 
51Podemos definir que somente três itens poderão receber 
o mesmo grau d importância, para evitar supervalorização 
de todas, forçando uma melhor avaliação dos envolvidos. 
Ao final estes dados são compilados e seus resultados 
apresentados formalmente aos envolvidos para que tenham 
a oportunidade de discutir determinados pontos de 
conflito. 
Priorizando as Categorias de Testes 
52 
Priorizando as Categorias de Testes 
Características da Aplicação 
 
Importância 
 01. Funcional 
 
Essencial 
 02. Desempenho 
 
Médio Impacto 
 03. Confiabilidade/Disponibilidade 
 
Alto Impacto 
 04. Segurança 
 
Essencial 
 05. Carga e Concorrência 
 
Alto Impacto 
 06. Usabilidade 
 
Médio Impacto 
 07. Compatibilidade 
 
Essencial 
 08. Portabilidade 
 
Baixo Impacto 
 09. Contingência 
 
Alto Impacto 
 10. Instalação 
 
Médio Impacto 
 11. Distribuição 
 
Alto Impacto 
 12. Recuperação 
 
Alto Impacto