certified tester...istqb® advanced level syllabus ctal technical tester analyst versão 2019br...
Post on 31-Jul-2020
8 Views
Preview:
TRANSCRIPT
Brazilian Software Testing Qualifications Board
Tradução realizada pelo WG-Traduções do BSTQB do syllabus do ISTQB:
Certified Tester Advanced Level Syllabus –Technical Tester Analyst - 2019
Certified Tester Advanced Level Syllabus
Technical Tester Analyst
CTAL-TTA
2019br
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 2 de 73
Direitos Autorais
Este documento pode ser copiado na sua totalidade, ou trechos podem ser utilizados, se a fonte
for reconhecida.
Copyright © International Software Testing Qualifications Board (ISTQB®).
Advanced Level Working Group: Graham Bath (vice-presidente), Rex Black, Judy McKay, Kenji
Onoshi, Mike Smith (presidente), Erik van Veenendaal
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 3 de 73
Histórico das revisões
Versão Data Comentários
2012 19 Oct 2012 GA release for 2012 version
2019 V1.0 18 Oct 2019 GA release for 2019 version
2019 V1.0 br Versão na Língua Portuguesa
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 4 de 73
Sumário
Direitos Autorais ....................................................................................................................................... 2
Histórico das revisões .............................................................................................................................. 3
Sumário ..................................................................................................................................................... 4
Agradecimentos ........................................................................................................................................ 7
0 Introdução a este Syllabus ................................................................................................................ 8
0.1 Objetivo deste documento ....................................................................................................... 8
0.2 A certificação de nível avançado no teste de software .......................................................... 8
0.3 Objetivos de aprendizagem examináveis e níveis cognitivos ................................................ 8
0.4 Expectativas de experiência ...................................................................................................... 9
0.5 O exame de certificação ............................................................................................................ 9
0.6 Pré-requisito para o exame ...................................................................................................... 9
0.7 Credenciamento de cursos ....................................................................................................... 9
0.8 Nível de detalhe do syllabus ..................................................................................................... 9
0.9 Como este syllabus é organizado ........................................................................................... 10
1 Tarefas do Analista Técnico de Teste em testes baseados em risco [30 min]................................. 11
1.1 Introdução ................................................................................................................................ 12
1.2 Tarefas de teste baseadas em risco ....................................................................................... 12
1.2.1 Identificação do risco ........................................................................................................... 12
1.2.2 Avaliação do risco................................................................................................................. 13
1.2.3 Mitigação do risco ................................................................................................................ 13
2 Técnicas de teste caixa-branca [345 min] ............................................................................................ 15
2.1 Introdução ................................................................................................................................ 16
2.2 Teste de instrução ................................................................................................................... 16
2.3 Teste de decisão ...................................................................................................................... 17
2.4 Teste de decisão de condição modificada (MC / DC) ............................................................ 17
2.5 Teste de condição múltipla ..................................................................................................... 19
2.6 Teste do caminho básico......................................................................................................... 20
2.7 Teste de API .............................................................................................................................. 21
2.8 Selecionando uma técnica de teste caixa-branca ................................................................. 22
3 Técnicas Analíticas [210 min] ................................................................................................................ 24
3.1 Introdução ................................................................................................................................ 25
3.2 Análise Estática ........................................................................................................................ 25
3.2.1 Análise do fluxo de controle................................................................................................ 25
3.2.2 Análise do fluxo de dados ................................................................................................... 26
3.2.3 Usando a análise estática para melhorar a capacidade de manutenção ....................... 27
3.2.4 Gráficos de chamadas ......................................................................................................... 28
3.3 Análise dinâmica ...................................................................................................................... 29
3.3.1 Visão geral............................................................................................................................. 29
3.3.2 Detectando vazamentos de memória ................................................................................ 30
3.3.3 Detectando ponteiros selvagens ........................................................................................ 31
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 5 de 73
3.3.4 Análise da eficiência da performance ................................................................................ 31
4 Características de qualidade para testes técnicos [345 min]............................................................. 33
4.1 Introdução ................................................................................................................................ 35
4.2 Questões gerais de planejamento ......................................................................................... 36
4.2.1 Requisitos dos stakeholders ............................................................................................... 36
4.2.2 Aquisição e treinamento de ferramentas necessárias ..................................................... 37
4.2.3 Requisitos do ambiente de teste ........................................................................................ 37
4.2.4 Considerações organizacionais ........................................................................................... 38
4.2.5 Considerações sobre segurança de dados ........................................................................ 38
4.2.6 Riscos e defeitos típicos ....................................................................................................... 38
4.3 Teste de segurança .................................................................................................................. 38
4.3.1 Motivos para considerar o teste de segurança ................................................................. 38
4.3.2 Planejamento de teste de segurança ................................................................................. 39
4.3.3 Especificação de teste de segurança .................................................................................. 40
4.4 Teste de confiabilidade ........................................................................................................... 41
4.4.1 Introdução ............................................................................................................................ 41
4.4.2 Medindo a maturidade do software ................................................................................... 42
4.4.3 Teste de tolerância a falhas................................................................................................. 42
4.4.4 Teste de recuperação .......................................................................................................... 42
4.4.5 Teste de disponibilidade ...................................................................................................... 43
4.4.6 Planejamento de teste de confiabilidade ........................................................................... 44
4.4.7 Especificação do teste de confiabilidade ........................................................................... 44
4.5 Teste de performance ............................................................................................................. 45
4.5.1 Tipos de teste de performance ........................................................................................... 45
4.5.2 Planejamento de teste de performance ............................................................................ 46
4.5.3 Especificação de teste de performance ............................................................................. 47
4.5.4 Subcaracterísticas de qualidade de eficiência de performance ...................................... 47
4.6 Teste de manutenção .............................................................................................................. 48
4.6.1 Teste de manutenção estática e dinâmica......................................................................... 49
4.6.2 Subcaracterísticas de manutenibilidade ............................................................................ 49
4.7 Teste de portabilidade ............................................................................................................ 50
4.7.1 Introdução ............................................................................................................................ 50
4.7.2 Teste de instalabilidade ....................................................................................................... 50
4.7.3 Teste de adaptabilidade ...................................................................................................... 51
4.7.4 Teste de substituibilidade ................................................................................................... 51
4.8 Teste de compatibilidade ........................................................................................................ 52
4.8.1 Introdução ............................................................................................................................ 52
4.8.2 Teste de coexistência ........................................................................................................... 52
5 Revisões [165 min] ................................................................................................................................. 53
5.1 Tarefas do Analista Técnico de Teste nas revisões ............................................................... 54
5.2 Usando listas de verificação nas revisões ............................................................................. 54
5.2.1 Revisões de arquitetura ....................................................................................................... 55
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 6 de 73
5.2.2 Revisões de código ............................................................................................................... 56
6 Ferramentas de teste e automação [180 min] .................................................................................... 58
6.1 Definindo o projeto de automação de teste ......................................................................... 59
6.1.1 Selecionando a abordagem de automação ....................................................................... 60
6.1.2 Modelando processos de negócios para automação ....................................................... 62
6.2 Ferramentas específicas de teste ........................................................................................... 64
6.2.1 Ferramentas para plantar / injetar falhas .......................................................................... 64
6.2.2 Ferramentas de teste de performance .............................................................................. 64
6.2.3 Ferramentas para testes baseados na web ....................................................................... 65
6.2.4 Ferramentas para suportar testes baseados em modelo ................................................ 66
6.2.5 Ferramentas de teste e compilação de componentes...................................................... 66
6.2.6 Ferramentas para suportar testes de aplicativos móveis ................................................ 67
Referências .............................................................................................................................................. 69
Normas e Padrões ............................................................................................................................... 69
Documentos ISTQB® ........................................................................................................................... 69
Literatura.............................................................................................................................................. 70
Outras referências ............................................................................................................................... 72
Apêndice A: Visão geral das características de qualidade................................................................... 73
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 7 de 73
Agradecimentos
Esse documento foi produzido pela equipe International Software Testing Qualifications Board
Advanced Level Working Group: Graham Bath (vice-chair), Rex Black, Judy McKay, Kenji Onoshi, Mike
Smith (chair), Erik van Veenendaal
As seguintes pessoas participaram na revisão, comentário e votação deste syllabus:
Dani Almog Andrew Archer Rex Black
Armin Born Sudeep Chatterjee Tibor Csöndes
Wim Decoutere Klaudia Dusser-Zieger Melinda Eckrich-Brájer
Peter Foldhazi David Frei Karol Frühauf
Jan Giesen Attila Gyuri Matthias Hamburg
Tamás Horváth N. Khimanand Jan te Kock
Attila Kovács Claire Lohr Rik Marselis
Marton Matyas Judy McKay Dénes Medzihradszky
Petr Neugebauer Ingvar Nordström Pálma Polyák
Meile Posthuma Stuart Reid Lloyd Roden
Adam Roman Jan Sabak Péter Sótér
Benjamin Timmermans Stephanie van Dijck Paul Weymouth
A equipe de produção agradece à equipe de revisão e aos Conselhos Nacionais por suas sugestões
e contribuições.
Este documento foi formalmente divulgado pela Assembleia Geral do ISTQB® em 20 de outubro de
2019, , e sua versão na Língua Portuguesa em 27 de junho de 2020.
O BSTQB agradece aos voluntários de seu grupo de trabalho de traduções (WG Traduções) pelo
empenho e esforço na tradução e revisão deste material: Eduardo Medeiros Rodrigues, George
Fialkovitz Jr, Irene Nagase, Paula Renata Z. de Souza, Yuri Fialkovitz.
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 8 de 73
0 Introdução a este Syllabus
0.1 Objetivo deste documento
Este documento forma a base de conhecimento para a Certificação ISTQB® CTAL-TTA Technical Test
Analyst. O ISTQB® fornece este syllabus da seguinte forma:
1. Aos Conselhos Nacionais, para traduzirem ao seu idioma local e credenciar os provedores
de treinamento. Os Conselhos Nacionais podem adaptar o programa às suas necessidades
linguísticas específicas e modificar as referências para se adaptarem às suas publicações
locais.
2. Aos Conselhos de Exame, para derivar questões de exame em sua língua local com base
nos objetivos de aprendizagem para cada módulo.
3. Aos Provedores de Treinamento, para que produzam o material didático e determinem
métodos apropriados de ensino.
4. Aos Candidatos à Certificação, como uma fonte para se prepararem para o exame.
5. À Comunidade Internacional de Software e à Engenharia de Sistemas, para avançar a
profissão de software e testes de sistema, e servir como base para livros e artigos.
O ISTQB® permite que outras entidades usem esse syllabus para outros fins, desde que obtenham
autorização prévia por escrito.
0.2 A certificação de nível avançado no teste de software
A certificação de nível avançado é composta por três syllabi distintos relacionados com as
seguintes funções:
• Gerente de Teste
• Analista de Teste
• Analista Técnico de Teste
O ISTQB® Advanced Level Overview 2019 é um documento separado [ISTQB_AL_OVIEW] que inclui as
seguintes informações:
• Resultados de negócio;
• Matriz de rastreabilidade entre os resultados de negócio e os objetivos de aprendizagem;
• Sumário.
0.3 Objetivos de aprendizagem examináveis e níveis cognitivos
Os objetivos de aprendizagem suportam os resultados de negócios e são usados para criar o
exame para obter a Certificação ISTQB® CTAL-TTA Technical Test Analyst.
Os níveis cognitivos dos objetivos de aprendizagem nos níveis K2, K3 e K4 são mostrados no início
de cada capítulo e são classificados da seguinte forma:
• K2: Entender
• K3: Aplicar
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 9 de 73
• K4: Analisar
As definições de todos os termos listados como conceitos-chave logo abaixo dos títulos dos
capítulos devem ser lembradas (K1), mesmo que não explicitamente mencionadas nos objetivos
de aprendizagem.
0.4 Expectativas de experiência
Alguns dos objetivos de aprendizagem para o Analista Técnico de Teste assumem que a
experiência básica está disponível nas seguintes áreas:
• Conhecimentos gerais em programação;
• Conhecimentos gerais em arquitetura de sistemas.
0.5 O exame de certificação
O exame para Analista Técnico de Teste do Nível Avançado será baseado nesse syllabus. As
respostas às perguntas do exame podem exigir o uso de materiais baseados em mais de um
capítulo desse syllabus. Todos os capítulos são examináveis, exceto a introdução e os apêndices.
Normas, livros e outros syllabi do ISTQB® são incluídos como referências, mas seu conteúdo não é
examinável além do que está resumido nesse documento.
O formato do exame é de múltipla escolha com 45 questões. Para passar no exame, o candidato
deve obter pelo menos 65% de acerto do total de pontos (100 pontos).
O exame pode ser feito como parte de um curso de treinamento credenciado ou realizado
independentemente (p. ex., em um centro de exames ou em um exame público). A conclusão de
um curso de treinamento credenciado não é um pré-requisito para um exame.
0.6 Pré-requisito para o exame
Estar aprovado na certificação CTFL Foundation Level é pré-requisito para que o candidato faça um
exame de certificação CTAL-TTA Technical Test Analyst.
0.7 Credenciamento de cursos
Um Conselho Nacional do ISTQB® (como o BSTQB) pode credenciar provedores de treinamento
cujo material de curso siga esse syllabus. Os provedores de treinamento devem obter as diretrizes
de credenciamento do Conselho Nacional ou do órgão que realiza o credenciamento. Um curso
credenciado é reconhecido como estando em conformidade com esse syllabus e é permitido ter
um exame ISTQB® como parte do curso.
0.8 Nível de detalhe do syllabus
O nível de detalhe nesse syllabus permite cursos e exames consistentes internacionalmente. Para
alcançar este objetivo, o syllabus consiste em:
• Objetivos gerais de instrução descrevendo a intenção do Analista Técnico de Teste;
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 10 de 73
• Uma lista de termos que os alunos devem ser capazes de lembrar;
• Os objetivos de aprendizagem para cada área de conhecimento, descrevendo o resultado
da aprendizagem cognitiva a alcançar;
• Uma descrição dos conceitos-chave, incluindo referências a fontes como normas e
legislações.
O conteúdo do syllabus não é uma descrição de toda a área de conhecimento; ele reflete o nível
de detalhe a ser coberto nos cursos de treinamento do Nível Avançado. Ele se concentra no
material que pode ser aplicado a qualquer projeto de software, utilizando qualquer ciclo de vida.
O syllabus não contém nenhum objetivo de aprendizagem específico relacionado com qualquer
ciclo de vida ou método de desenvolvimento de software em particular, mas discute como estes
conceitos se aplicam em projetos Ágeis, e outros tipos de ciclos de vida como iterativos,
incrementais e sequenciais.
0.9 Como este syllabus é organizado
Há seis capítulos com conteúdo examinável. No título de cada capítulo é especificado entre
colchetes o tempo mínimo de estudo para cada capítulo; o tempo não é fornecido para
subcapítulos. Para cursos de formação credenciados, o syllabus requer um mínimo de 21 horas e
15 minutos de instrução, distribuídos pelos seis capítulos da seguinte forma:
• Capítulo 1: Tarefas do Analista Técnico de Teste em testes baseados em risco (30 minutos)
• Capítulo 2: Técnicas de teste caixa-branca (345 minutos)
• Capítulo 3: Técnicas Analíticas (210 minutos)
• Capítulo 4: Características de qualidade para testes técnicos (345 minutos)
• Capítulo 5: Revisões (165 minutos)
• Capítulo 6: Ferramentas de teste e automação (180 minutos)
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 11 de 73
1 Tarefas do Analista Técnico de Teste em testes baseados em risco [30 min]
Conceitos-chave
risco de produto, avaliação de risco, identificação de risco, mitigação de risco, teste baseado em
risco
Objetivos de aprendizagem
1.2 Tarefas de teste baseadas em risco
TTA-1.2.1 (K2) Resumir os fatores de risco genéricos que o Analista Técnico de Teste normalmente
precisa considerar.
TTA-1.2.2 (K2) Resumir as atividades do Analista Técnico de Teste em uma abordagem baseada em
risco para atividades de teste.
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 12 de 73
1.1 Introdução
O Gerente de Teste tem a responsabilidade geral de estabelecer e gerenciar uma estratégia de
teste baseada em risco. O Gerente de Teste geralmente solicita o envolvimento do Analista Técnico
de Teste para garantir que a abordagem baseada em risco seja implementada corretamente.
O Analista Técnico de Teste trabalha dentro da estrutura de teste baseada em risco estabelecida
pelo Gerente de Teste do projeto. Eles contribuem com seu conhecimento técnico dos riscos do
produto inerentes ao projeto, como riscos relacionados à segurança, confiabilidade e performance
do sistema.
1.2 Tarefas de teste baseadas em risco
Devido a seu conhecimento técnico específico, os Analistas de teste técnico estão envolvidos
ativamente nas seguintes tarefas de teste com base em risco:
• Identificação do risco
• Avaliação do risco
• Mitigação do risco
Essas tarefas são executadas iterativamente ao longo do projeto para lidar com riscos emergentes
de produtos e mudanças de prioridades, além de avaliar e comunicar regularmente o status dos
riscos.
1.2.1 Identificação do risco
Ao chamar a amostra mais ampla possível de stakeholders, é mais provável que o processo de
identificação de riscos detecte o maior número possível de riscos significativos. Como os Analistas
Técnicos de Teste possuem habilidades técnicas exclusivas, eles são particularmente adequados
para conduzir entrevistas com os especialistas, trocar ideias com colegas de trabalho, e analisar as
experiências atuais e passadas para determinar onde estão as áreas prováveis de risco do produto.
Em particular, o Analista Técnico de Teste trabalha em estreita colaboração com outros
stakeholders, como Desenvolvedores, Arquitetos, Engenheiros de Pperações, Proprietários de
Produtos (product owner), escritórios de suporte locais e técnicos de service desk, para determinar
as áreas técnicas de risco que afetam o produto e o projeto. O envolvimento de outros
stakeholders garante que todas as visualizações sejam consideradas e geralmente são facilitadas
pelo Gerente de Teste.
Os riscos que podem ser identificados pelo Analista Técnico de Teste geralmente são baseados
nas características de qualidade [ISO25010] listadas no capítulo 4 e incluem, por exemplo:
• Eficiência de performance (p. ex., a incapacidade de obter os tempos de resposta exigidos
em condições de alta carga);
• Segurança (p. ex., a divulgação de dados confidenciais por meio de ataques de segurança);
• Confiabilidade (p. ex., um aplicativo incapaz de atender à disponibilidade especificada no
contrato de nível de serviço).
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 13 de 73
1.2.2 Avaliação do risco
Embora a identificação de riscos tenha como objetivo identificar o maior número possível de riscos
pertinentes, a avaliação de riscos é o estudo desses riscos identificados, a fim de categorizá-los e
determinar a probabilidade e o impacto associado a eles. A probabilidade de ocorrência é
geralmente interpretada como a probabilidade de que o problema em potencial possa existir no
sistema em teste.
O Analista Técnico de Teste contribui para encontrar e entender o risco potencial técnico do
produto para cada item de risco, enquanto o Analista de Teste contribui para entender o potencial
impacto comercial do problema, caso ocorra.
Os riscos do projeto podem afetar o sucesso geral do projeto. Normalmente, os seguintes riscos
genéricos do projeto precisam ser considerados:
• Conflitos entre os stakeholders em relação aos requisitos técnicos;
• Problemas de comunicação resultantes da localização geográfica da equipe de
desenvolvimento;
• Ferramentas e tecnologia (incluindo habilidades relevantes);
• Tempo, recursos e pressão gerencial;
• Falta de garantia de qualidade anterior;
• Altas taxas de mudança de requisitos técnicos.
Os fatores de risco do produto podem resultar em um número maior de defeitos. Normalmente,
os seguintes riscos genéricos do produto precisam ser considerados:
• Complexidade da tecnologia;
• Complexidade da estrutura do código;
• Quantidade de reutilização em comparação com o novo código;
• Quantidade de defeitos encontrados relacionados às características técnicas de qualidade
(histórico de defeitos);
• Interface técnica e problemas de integração.
Dadas as informações de risco disponíveis, o Analista Técnico de Teste propõe um nível de risco
inicial de acordo com as diretrizes estabelecidas pelo Gerente de Teste. Por exemplo, o Gerente
de Testes pode determinar que os riscos serão classificados com valores de 1 a 10, sendo 1 o risco
mais alto. O valor inicial pode ser modificado pelo Gerente de Teste quando todas as
considerações dos stakeholders forem vistas.
1.2.3 Mitigação do risco
Durante o projeto, o Analista Técnico de Teste influencia como o teste responde aos riscos
identificados. Isso geralmente envolve:
• Reduzir o risco executando os testes mais importantes (aqueles que tratam de áreas de
alto risco) e colocando em ação medidas de mitigação e contingência apropriadas,
conforme declarado no plano de teste;
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 14 de 73
• Avaliar os riscos com base em informações adicionais coletadas à medida que o projeto se
desenrola, e usar essas informações para implementar medidas de mitigação destinadas a
diminuir a probabilidade ou evitar o impacto desses riscos.
O Analista Técnico de Teste geralmente coopera com especialistas em áreas como segurança e
performance para definir medidas de mitigação de riscos e elementos da estratégia de teste
organizacional. Informações adicionais podem ser obtidas nos syllabi ISTQB® CTAL-SEC Security
Tester [ISTQB_AL_SEC] e ISTQB® CTFL-PT Performance Testing [ISTQB_FL_PT].
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 15 de 73
2 Técnicas de teste caixa-branca [345 min]
Conceitos-chave
teste de API, condição atômica, teste de fluxo de controle, complexidade ciclomática, teste de
decisão, teste de decisão de condição modificada, teste de condição múltipla, teste de caminho,
curto-circuito, teste de instrução, técnica de teste caixa-branca
Objetivos de aprendizagem
Note: As Os 2.2.1, 2.3.1, 2.4.1, 2.5.1 e 2.6.1 se referem a um "item de especificação". Isso inclui itens
como seções de código, requisitos, histórias de usuários, casos de uso e especificações funcionais.
2.2 Teste de instrução
TTA-2.2.1 (K3) Escrever os casos de teste para um determinado item de especificação aplicando a
técnica de teste de instrução para atingir um nível definido de cobertura.
2.3 Teste de decisão
TTA-2.3.1 (K3) Escrever casos de teste para um determinado item especificado aplicando a técnica
de teste decisão para atingir um nível definido de cobertura.
2.4 Teste de decisão de condição modificada (MC / DC)
TTA-2.4.1 (K3) Escrever casos de teste aplicando a técnica de modelagem de teste de decisão de
condição modificada (MC / DC) para atingir um nível definido de cobertura.
2.5 Teste de condição múltipla
TTA-2.5.1 (K3) Escrever casos de teste para um determinado item de especificação aplicando a
técnica de teste de condição múltipla para obter um nível definido de cobertura.
2.6 Teste do caminho básico
TTA-2.6.1 (K3) Escrever casos de teste para um determinado item de especificação aplicando o
Simplified Baseline Method de McCabe.
2.7 Teste de API
TTA-2.7.1 (K2) Entender a aplicabilidade dos testes de API e os tipos de defeitos encontrados.
2.8 Selecionando uma técnica de teste caixa-branca
TTA-2.8.1 (K4) Selecionar a técnica de teste caixa-branca apropriada de acordo com uma
determinada situação do projeto.
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 16 de 73
2.1 Introdução
Este capítulo descreve principalmente técnicas de teste caixa-branca. Essas técnicas se aplicam ao
código e outras estruturas, como fluxogramas de processos de negócios.
Cada técnica específica permite que os casos de teste sejam derivados sistematicamente, se
concentrando em um aspecto específico da estrutura a ser considerada. As técnicas fornecem
critérios de cobertura que devem ser medidos e associados a um objetivo definido por cada
projeto ou organização. Obter a cobertura total não significa que todo o conjunto de teste esteja
completo, mas que a técnica utilizada não sugere mais testes úteis para a estrutura considerada.
As seguintes técnicas estão presentes nesse syllabus:
• Teste de instrução;
• Teste de decisão;
• Teste de decisão de condição modificada;
• Teste de condição múltipla;
• Teste do caminho básico;
• Teste de API;
O syllabus CTFL Foundation Level [ISTQB_FL] apresenta o teste de instrução e o teste de decisão. O
teste de instrução exercita as instruções executáveis no código, enquanto o teste de Decisão
exercita as decisões no código e testa o código que é executado com base nos resultados da
decisão.
As técnicas de teste de decisão de condição modificada e de várias condições listadas acima são
baseadas em predicados de decisão e encontram amplamente os mesmos tipos de defeitos. Não
importa quão complexo seja um predicado de decisão, ele será avaliado como VERDADEIRO ou
FALSO, o que determinará o caminho percorrido pelo código. Um defeito é detectado quando o
caminho pretendido não é utilizado porque um predicado de decisão não é avaliado conforme o
esperado.
As quatro primeiras técnicas são sucessivamente mais completas (e o teste do caminho básico é
mais completo que o teste de instrução e decisão); técnicas mais completas geralmente exigem
que mais testes sejam definidos para atingir a cobertura pretendida e encontrar os defeitos mais
sutis.
Consulte [Bath14], [Beizer90], [Beizer95], [Copeland03], [McCabe96], [ISO29119] e [Koomen06].
2.2 Teste de instrução
O teste de instrução exercita as instruções executáveis no código. A cobertura é medida como o
número de instruções executadas pelos testes dividido pelo número total de instruções
executáveis no objeto de teste, normalmente expresso como uma porcentagem.
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 17 de 73
Aplicabilidade
Esse nível de cobertura deve ser considerado no mínimo para todo o código que está sendo
testado.
Limitações e Dificuldades
As decisões não são consideradas. Mesmo com altas porcentagens de cobertura de instrução pode
não se detectar certos defeitos na lógica do código.
2.3 Teste de decisão
O teste de decisão exercita e testa as decisões no código que é executado com base nos resultados
da decisão. Para fazer isso, os casos de teste seguem os fluxos de controle que ocorrem a partir
de um ponto de decisão (p. ex., para uma instrução IF, um para o resultado verdadeiro e outro
para o falso; para uma instrução CASE, seriam necessários casos de teste para todos os possíveis
resultados, incluindo o padrão).
A cobertura é medida como o número de resultados da decisão executados pelos testes dividido
pelo número total de resultados da decisão no objeto de teste, normalmente expresso em
porcentagem.
Comparado às técnicas de teste de decisão de condição modificada e de condição múltipla
descritas abaixo, o teste de decisão considera toda a decisão como um todo e avalia os resultados
VERDADEIRO e FALSO em casos de teste separados.
Aplicabilidade
Esse nível de cobertura deve ser considerado quando o código que está sendo testado é
importante ou mesmo crítico (consulte a tabela n o capítulo 2.8).
Limitações e Dificuldades
Como pode exigir mais casos de teste do que testar apenas no nível da instrução, pode ser
problemático quando o tempo é curto. O teste de decisão não considera os detalhes de como uma
decisão com várias condições é tomada e pode falhar na detecção de defeitos causados por
combinações dessas condições.
2.4 Teste de decisão de condição modificada (MC / DC)
Comparado ao teste de decisão, que considera toda a decisão como um todo e avalia os resultados
VERDADEIRO e FALSO em casos de teste separados, o teste de decisão de condição modificada
considera como uma decisão é tomada quando inclui várias condições (caso contrário, é
simplesmente teste de decisão).
Cada predicado de decisão é composto de uma ou mais condições atômicas simples, cada uma
avaliada como um valor booleano discreto. Eles são combinados logicamente para determinar o
resultado da decisão. Essa técnica verifica se cada uma das condições atômicas afeta de forma
independente e correta o resultado geral da decisão.
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 18 de 73
Essa técnica fornece um nível de cobertura mais forte do que a cobertura de instruções e decisões
quando existem decisões que contêm várias condições. Assumindo N condições atômicas
independentes e únicas, o teste de decisão de condição modificada geralmente pode ser
alcançado com casos de teste exclusivos N+1. O teste de decisão de condição modificada requer
pares de casos de teste que mostram que uma única condição atômica pode afetar
independentemente o resultado de uma decisão.
No exemplo a seguir, uma instrução "Se (A ou B) e C, então..." é considerada.
A B C (A ou B) e C
Teste 1 VERDADEIRO FALSO VERDADEIRO VERDADEIRO
Teste 2 FALSO VERDADEIRO VERDADEIRO VERDADEIRO
Teste 3 FALSO FALSO VERDADEIRO FALSO
Teste 4 VERDADEIRO FALSO FALSO FALSO
No Teste 1, A é VERDADEIRO e o resultado geral é VERDADEIRO. Se A for alterado para FALSO
(como no Teste 3, mantendo os outros valores inalterados), o resultado será alterado para FALSO,
mostrando que A pode afetar independentemente o resultado da decisão.
No Teste 2, B é VERDADEIRO e o resultado geral é VERDADEIRO. Se B for alterado para FALSO
(como no Teste 3, mantendo outros valores inalterados), o resultado será alterado para FALSO,
mostrando que B pode afetar independentemente o resultado da decisão.
No Teste 1, C é VERDADEIRO e o resultado geral é VERDADEIRO. Se C for alterado para FALSO
(como no Teste 4, mantendo outros valores inalterados), o resultado será alterado para FALSO,
mostrando que C pode afetar independentemente o resultado da decisão.
Observe que, diferentemente das técnicas de instrução e teste de decisão, não há "níveis definidos
de cobertura" para o teste de decisão de condição modificada; ou é alcançado (100%) ou não.
Aplicabilidade
Essa técnica é usada na indústria aeroespacial e em outras indústrias para sistemas críticos de
proteção. É usado ao testar software em que uma falha pode causar uma catástrofe.
Limitações e Dificuldades
Conseguir a cobertura de teste de decisão de condição modificada pode ser complicado quando
há várias ocorrências de uma variável em uma decisão com várias condições; quando isso ocorre,
as condições podem ser "acopladas". Dependendo da decisão, pode não ser possível variar o valor
de uma condição, de modo que somente isso faça com que o resultado da decisão mude. Uma
abordagem para resolver esse problema é especificar que apenas condições atômicas
desacopladas devem ser testadas no nível do teste de decisão de condição modificada. A outra
abordagem é analisar cada decisão na qual o acoplamento ocorre caso a caso.
Algumas linguagens de programação ou interpretadores são projetadas de modo a exibir um
comportamento em curto-circuito ao avaliar uma instrução de decisão complexa no código. Ou
seja, o código de execução pode não avaliar uma expressão inteira se o resultado da avaliação
puder ser determinado após a avaliação de apenas uma parte da expressão. Por exemplo, se
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 19 de 73
estiver avaliando a decisão “A e B”, não há razão para avaliar B se A já tiver sido avaliada como
FALSO. Nenhum valor de B pode alterar o resultado; portanto, o código pode economizar tempo
de execução ao não avaliar B. O curto-circuito pode afetar a capacidade de obter cobertura de
teste de decisão de condição modificada, pois alguns testes necessários podem não ser
alcançáveis.
2.5 Teste de condição múltipla
Em casos raros, pode ser necessário testar todas as combinações possíveis de condições atômicas
que uma decisão possa conter. Esse nível exaustivo de teste é chamado de teste de várias
condições. O número de testes necessários depende do número de condições atômicas na
instrução de decisão, e pode ser determinado calculando 2N onde N é o número de condições
atômicas desacopladas. Usando o mesmo exemplo de antes, os seguintes testes são necessários
para obter uma cobertura condições múltiplas:
A B C (A ou B) e C
Teste 1 VERDADEIRO VERDADEIRO VERDADEIRO VERDADEIRO
Teste 2 VERDADEIRO VERDADEIRO FALSO FALSO
Teste 3 VERDADEIRO FALSO VERDADEIRO VERDADEIRO
Teste 4 VERDADEIRO FALSO FALSO FALSO
Teste 5 FALSO VERDADEIRO VERDADEIRO VERDADEIRO
Teste 6 FALSO VERDADEIRO FALSO FALSO
Teste 7 FALSO FALSO VERDADEIRO FALSO
Teste 8 FALSO FALSO FALSO FALSO
A cobertura é medida como o número de combinações de condições únicas executadas pelos
testes dividido pelo número total de combinações de condições no objeto de teste, normalmente
expresso como uma porcentagem.
Aplicabilidade
Essa técnica é usada para testar o software integrado que é esperado para ser executado de forma
confiável sem travar por longos períodos (p. ex., comutadores telefônicos que devem durar 30
anos).
Limitações e Dificuldades
Como o número de casos de teste pode ser derivado diretamente de uma “tabela verdade”
contendo todas as condições atômicas, esse nível de cobertura pode ser facilmente determinado.
No entanto, o grande número de casos de teste necessários torna a cobertura de teste de decisão
de condição modificada mais viável para a maioria das situações.
Se a linguagem de programação usa curto-circuito, o número de casos de teste reais geralmente
será reduzido, dependendo da ordem e do agrupamento de operações lógicas que são executadas
nas condições atômicas.
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 20 de 73
2.6 Teste do caminho básico
O teste de caminho em geral consiste em identificar caminhos através do código e, em seguida,
criar testes para cobri-los. Conceitualmente, seria útil testar todos os caminhos exclusivos do
sistema. Em qualquer sistema não trivial, no entanto, o número de casos de teste pode se tornar
excessivamente grande devido à natureza das estruturas em loop. Por outro lado, o teste do
caminho básico pode ser realizado realisticamente e segue o Simplified Baseline Method
desenvolvido por McCabe [McCabe96].
A técnica é aplicada pelas seguintes etapas:
1) Criar um gráfico de fluxo de controle para um determinado item de especificação (p. ex.,
código ou especificação de modelagem funcional). Observe que este também pode ser o
primeiro passo na realização da análise do fluxo de controle (consulte o capítulo 3.2.1).
2) Selecionar um caminho básico através do código (não um caminho de exceção). Esse
caminho básico deve ser o caminho mais importante para o teste - o risco pode ser usado
para fazer esse julgamento.
3) Gerar um segundo caminho alterando o resultado da primeira decisão no caminho básico,
mantendo o número máximo de resultados da decisão igual ao caminho básico.
4) Gerar um terceiro caminho iniciando novamente com o caminho básico e alterando o
resultado da segunda decisão no caminho. Quando são encontradas decisões de várias vias
(p. ex., uma instrução de caso), cada resultado da decisão deve ser testado antes de passar
para a próxima decisão.
5) Gerar novos caminhos alterando cada um dos resultados no caminho básico. Quando
novas decisões são encontradas, o resultado mais importante deve ser seguido primeiro.
6) Depois que todos os resultados da decisão no caminho básico serem cobertos, aplicar a
mesma abordagem aos caminhos subsequentes até que todos os resultados da decisão no
item de especificação tenham sido exercidos.
Aplicabilidade
O método simplificado do caminho básico, conforme definido acima, é frequentemente executado
em softwares de missão crítica. É uma boa adição aos outros métodos abordados neste capítulo,
porque analisa os caminhos do software e não apenas a maneira como as decisões são tomadas.
Limitações e Dificuldades
Quando o syllabus foi lançado, o suporte da ferramenta para o teste do caminho básico era
limitado.
Cobertura
A técnica descrita acima deve garantir a cobertura total de todos os caminhos linearmente
independentes e o número de caminhos deve corresponder à complexidade ciclomática do
código. Dependendo da complexidade do código, pode ser útil usar uma ferramenta para verificar
se foi alcançada a cobertura total do conjunto básico de caminhos. A cobertura é medida como o
número de caminhos linearmente independentes executados pelos testes divididos pelo número
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 21 de 73
total de caminhos linearmente independentes no objeto de teste, normalmente expresso em
porcentagem. O teste do caminho básico fornece testes mais completos do que a cobertura da
decisão, com um aumento relativamente pequeno no número de testes [NIST96].
2.7 Teste de API
Uma interface de programação de aplicativos (API, Application Programming Interface) é um código
que permite a comunicação entre diferentes processos, programas ou sistemas. As APIs são
frequentemente utilizadas em um relacionamento cliente/servidor em que um processo fornece
algum tipo de funcionalidade a outros processos.
O teste de API é um tipo de teste, e não uma técnica. Em certos aspectos, o teste da API é bastante
semelhante ao teste de uma interface gráfica do usuário (GUI). O foco está na avaliação dos valores
de entrada e dos dados retornados.
Testes negativos geralmente são cruciais ao lidar com APIs. Os programadores que usam APIs para
acessar serviços externos ao seu próprio código podem tentar usar interfaces de API de maneiras
para as quais eles não foram planejados. Isso significa que o tratamento robusto de erros é
essencial para evitar operações incorretas. O teste combinatório de diferentes interfaces pode ser
necessário porque as APIs geralmente são usadas em conjunto com outras APIs e porque uma
única interface pode conter vários parâmetros, onde os valores dessas podem ser combinados de
várias maneiras.
As APIs são frequentemente pouco acopladas, resultando na possibilidade muito real de
transações perdidas ou falhas de tempo. Isso requer testes completos dos mecanismos de
recuperação e nova tentativa. Uma organização que fornece uma interface de API deve garantir
que todos os serviços tenham uma disponibilidade muito alta, isso geralmente exige testes
rigorosos de confiabilidade pelo editor da API, bem como suporte à infraestrutura.
Aplicabilidade
O teste de API está se tornando mais importante para testar sistemas de sistemas à medida que
os sistemas individuais são distribuídos ou usam o processamento remoto como uma forma de
descarregar algum trabalho para outros processadores. Exemplos incluem:
• Chamadas de sistemas operacionais
• Service-Oriented Architectures (SOA)
• Remote Procedure Calls (RPC)
• Serviços da Web
O software encapsulado [Burns18] resulta na divisão de um programa de software em vários
contêineres que se comunicam usando mecanismos como os listados acima. O teste da API
também deve direcionar essas interfaces.
Limitações e Dificuldades
Testar uma API diretamente geralmente requer que um Analista Técnico de Teste use ferramentas
especializadas. Como normalmente não há interface gráfica direta associada a uma API, podem
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 22 de 73
ser necessárias ferramentas para configurar o ambiente inicial, organizar os dados, chamar a API
e determinar o resultado.
Cobertura
O teste de API é uma descrição de um tipo de teste; não indica nenhum nível específico de
cobertura. No mínimo, o teste da API deve fazer chamadas para a API com valores realistas e
inesperados de entrada para verificar o tratamento das exceções. Os testes de API mais completos
podem garantir que as entidades que chamam sejam exercitadas pelo menos uma vez ou que
todas as chamadas possíveis sejam feitas pelo menos uma vez.
Tipos de Defeitos
Os tipos de defeitos que podem ser encontrados testando APIs são bastante diferentes. São
comuns os problemas de interface, assim como os de manipulação de dados, problemas de
tempo, perda de transações e duplicação de transações.
2.8 Selecionando uma técnica de teste caixa-branca
O contexto do sistema em teste terá impacto nos níveis de risco e criticidade do produto (veja
abaixo). Esses fatores influenciam a métrica de cobertura necessária (e, portanto, a técnica de teste
caixa-branca a ser usada) e a profundidade da cobertura a ser alcançada. Em geral, quanto mais
crítico o sistema e maior o nível de risco do produto, mais rigorosos são os requisitos de cobertura
e maior a necessidade de tempo e recursos para atingir a cobertura desejada.
Às vezes, a métrica de cobertura necessária pode ser derivada dos padrões aplicáveis que se
aplicam ao sistema de software. Por exemplo, se o software fosse usado em um ambiente
aeronáutico, pode ser necessário estar em conformidade com o padrão DO-178C (na Europa, ED-
12C.) Esse padrão contém as cinco condições de falha a seguir:
1) Catastrófico: falha pode causar falta de função crítica necessária para voar ou aterrar com
segurança o avião;
2) Perigoso: a falha pode ter um grande impacto negativo na segurança ou na eficiência da
performance;
3) Maior: falha é significativa, mas menos grave que A ou B;
4) Menor: falha é perceptível, mas com menos impacto que C;
5) Sem efeito: a falha não tem impacto na segurança.
Se o sistema de software estiver classificado como nível A, deverá ser testado com 100% de
cobertura do teste de decisão de condição modificada. Se for nível B, deve ser testado com 100%
de cobertura no nível de decisão, sendo opcional o teste de decisão de condição modificada. O
nível C requer 100% de cobertura de instrução, no mínimo.
Da mesma forma, o [IEC61508] é um padrão internacional para a proteção funcional de sistemas
programáveis, eletrônicos e relacionados à segurança. Esse padrão foi adaptado em muitas áreas
diferentes, incluindo automotiva, ferroviária, manufatureira, usinas nucleares e máquinas
industriais. A criticidade é definida usando uma escala de níveis de integridade de segurança (SIL)
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 23 de 73
em que SIL1 é o menos crítico e SIL4 é o mais crítico. O padrão fornece recomendações para a
cobertura de teste, conforme mostrado na tabela a seguir (observe que as definições exatas para
cada SIL e o significado de "recomendado" e "altamente recomendado" estão definidas no padrão).
SIL 100% Cobertura de
Declaração
100% Cobertura de Desvio
(Decisão)
100% Cobertura de Decisão e
Condição Modificada
1 Recomendado Recomendado Recomendado
2 Altamente recomendado Recomendado Recomendado
3 Altamente recomendado Altamente recomendado Recomendado
4 Altamente recomendado Altamente recomendado Altamente recomendado
Nos sistemas modernos, é raro que todo o processamento seja feito em um único sistema. O teste
da API deve ser instituído sempre que parte do processamento for feito remotamente. A
criticidade do sistema deve determinar quanto esforço deve ser investido nos testes da API.
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 24 de 73
3 Técnicas Analíticas [210 min]
Conceitos-chave
análise do fluxo de controle, complexidade ciclomática, análise do fluxo de dados, par definição-
utilização, análise dinâmica, vazamento de memória, teste de integração em pares, teste de
integração de vizinhança, análise estática, ponteiro selvagem
Objetivos de aprendizagem
3.2 Análise Estática
TTA-3.2.1 (K3) Usar a análise do fluxo de controle para detectar se o código tem alguma anomalia
de fluxo de controle.
TTA-3.2.2 (K2) Explicar como a análise do fluxo de dados é usada para detectar se o código tem
alguma anomalia no fluxo de dados.
TTA-3.2.3 (K3) Propor maneiras de melhorar a manutenção do código aplicando análise estática.
TTA-3.2.4 (K2) Explicar o uso de gráficos de chamada para estabelecer estratégias de teste de
integração.
3.3 Análise Dinâmica
TTA-3.3.1 (K3) Aplicar a análise dinâmica para atingir uma meta especificada.
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 25 de 73
3.1 Introdução
Existem dois tipos de análise: análise estática e análise dinâmica.
A análise estática (capítulo 3.2) abrange os testes analíticos que podem ocorrer sem a execução
do software. Como o software não está em execução, ele é examinado por uma ferramenta ou
por uma pessoa para determinar se será processado corretamente quando for executado. Essa
visão estática do software permite uma análise detalhada sem a necessidade de criar os dados e
as pré-condições que causariam o exercício de um cenário.
Observe que as diferentes formas de revisão relevantes para o Analista Técnico de Teste são
abordadas no Capítulo 5.
A análise dinâmica (capítulo 3.3) requer a execução real do código e é usada para encontrar falhas
que são facilmente detectadas quando o código está em execução (p. ex., vazamentos de
memória). A análise dinâmica, como na análise estática, pode depender de ferramentas ou de um
indivíduo para monitorar o sistema em execução, observando tais indicadores como um rápido
aumento do uso da memória.
3.2 Análise Estática
O objetivo da análise estática é detectar defeitos reais ou potenciais na arquitetura de código e
sistema, e melhorar sua capacidade de manutenção. A análise estática geralmente é suportada
por ferramentas.
3.2.1 Análise do fluxo de controle
A análise do fluxo de controle é a técnica estática na qual as etapas seguidas por um programa
são analisadas, através do uso de um gráfico de fluxo de controle ou de uma ferramenta. Existem
várias anomalias que podem ser encontradas em um sistema usando essa técnica, incluindo loops
mal projetados (p. ex., com vários pontos de entrada), alvos ambíguos de chamadas de função em
certas linguagens (p. ex., Scheme), sequenciamento incorreto de operações etc.
A análise do fluxo de controle pode ser usada para determinar a complexidade ciclomática. O valor
da complexidade ciclomática é um número inteiro positivo que representa o número de caminhos
independentes em um gráfico fortemente conectado. Os loops e iterações são ignorados assim
que são percorridos uma vez. Cada caminho, da entrada à saída, representa um caminho exclusivo
através do módulo. Cada caminho exclusivo deve ser testado.
O valor da complexidade ciclomática é geralmente usado para entender a complexidade geral de
um módulo. A teoria de Thomas McCabe [McCabe 76] era que, quanto mais complexo o sistema,
mais difícil seria manter e mais defeitos ele conteria. Muitos estudos ao longo dos anos
observaram essa correlação entre complexidade e número de defeitos contidos. O NIST (National
Institute of Standards and Technology) recomenda um valor máximo de complexidade “10”.
Qualquer módulo medido com uma complexidade mais alta deve ser revisto para possível divisão
em submódulos.
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 26 de 73
3.2.2 Análise do fluxo de dados
A análise do fluxo de dados abrange uma variedade de técnicas que coletam informações sobre o
uso de variáveis em um sistema. O ciclo de vida de cada variável é investigado (ou seja, onde é
declarado, definido, lido, avaliado e destruído), uma vez que anomalias podem ocorrer durante
qualquer uma dessas operações ou se as operações estiverem fora de sequência.
Uma técnica comum é chamada de notação de uso de definição, em que o ciclo de vida de cada
variável é dividido em três ações atômicas diferentes:
• d: (declared) quando a variável é declarada, definida ou inicializada;
• u: (used) quando a variável é usada ou lida em um predicado de computação ou de decisão;
• k: (killed) quando a variável é morta ou sai de escopo.
Uma notação alternativa comum para d-u-k é: d (define: definido) - r (reference: referência) - u
(undefine: indefinido).
Essas três ações atômicas são combinadas em pares ("pares de definição-uso") para ilustrar o fluxo
de dados. Por exemplo, um "caminho duplo" representa um fragmento do código em que uma
variável de dados é definida e usada posteriormente.
As possíveis anomalias de fluxo de dados incluem executar a ação correta em uma variável no
momento errado ou executar uma ação incorreta nos dados em uma variável. Estas anomalias
incluem:
• Falha na atribuição de um valor a uma variável antes de sua utilização;
• Tomar um caminho errado devido a um valor incorreto em um predicado de controle;
• Tentar usar uma variável após ser destruída;
• Referenciar uma variável quando ela está fora do escopo;
• Declarar e destruir uma variável sem a utilizar;
• Redefinir uma variável antes dela ser utilizada;
• Falhar em destruir uma variável alocada dinamicamente (causando um possível vazamento
de memória);
• Modificar uma variável, o que resulta em efeitos colaterais inesperados (p. ex., efeitos de
ondulação ao alterar uma variável global sem considerar todos os usos dessa variável).
A linguagem de desenvolvimento usada pode orientar as regras usadas na análise do fluxo de
dados. As linguagens de programação podem permitir que o programador execute determinadas
ações com variáveis que não são ilegais, mas pode fazer com que o sistema se comporte de
maneira diferente do esperado pelo programador em determinadas circunstâncias. Por exemplo,
uma variável pode ser definida duas vezes sem realmente ser usada quando um determinado
caminho é seguido. A análise do fluxo de dados geralmente rotula esses usos de "suspeitos".
Embora isso possa ser um uso legal do recurso de atribuição de variáveis, pode levar a problemas
futuros de manutenção no código.
O teste de fluxo de dados "usa o gráfico de controle de fluxo para explorar as coisas irracionais que
podem acontecer aos dados" [Beizer90] e, portanto, encontra defeitos diferentes dos da análise do
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 27 de 73
fluxo de controle. O Analista Técnico de Teste deve incluir essa técnica no planejamento de testes,
pois muitos desses defeitos causam falhas intermitentes difíceis de encontrar durante a execução
de testes dinâmicos.
A análise do fluxo de dados é uma técnica estática; poderão ocorrer problemas quando os dados
forem usados no sistema em tempo de execução. Por exemplo, a variável de dados estática pode
conter um ponteiro para uma matriz criada dinamicamente que nem existe até o tempo de
execução. O uso de vários processadores e as multitarefas preventivas podem criar condições de
processamento que não serão encontradas pelo fluxo de dados ou pela análise do fluxo de
controle.
3.2.3 Usando a análise estática para melhorar a capacidade de manutenção
A análise estática pode ser aplicada de várias maneiras para melhorar a manutenção do código,
arquitetura e sites.
Um código mal escrito, não-comentado e não estruturado tende a ser mais difícil de se manter.
Pode exigir mais esforço dos desenvolvedores para localizar e analisar defeitos no código, e a
modificação do código para corrigir um defeito ou adicionar um novo recurso pode resultar na
introdução de outros defeitos.
A análise estática é usada com o suporte da ferramenta para melhorar a manutenção do código,
verificando a conformidade com os padrões e diretrizes de codificação. Esses padrões e diretrizes
descrevem práticas necessárias de codificação, como convenções de nomenclatura, comentários,
indentação e modularização de código. Observe que as ferramentas de análise estática
geralmente emitem avisos em vez de detectar erros. Esses avisos podem ser destacados, mesmo
que o código esteja sintaticamente correto.
As ferramentas de análise estática podem ser aplicadas ao código usado para implementar sites
da Web para verificar a possível exposição a vulnerabilidades de segurança, como injeção de
código, segurança de cookies, scripts entre sites, violação de recursos e injeção de código SQL.
Detalhes adicionais são fornecidos no capítulo 4.3 e no Syllabus CTAL-SEC Security Tester [ISTQB_
ALSEC_SYL].
Projetos modulares geralmente resultam em código mais sustentável. As ferramentas de análise
estática suportam o desenvolvimento de código modular das seguintes maneiras:
• Eles pesquisam código repetido. Essas seções de código podem ser candidatas à fatoração
em módulos (embora a sobrecarga de tempo de execução imposta por chamadas de
módulo possa ser um problema para sistemas em tempo real);
• Eles geram métricas que são indicadores valiosos da modularização de código. Isso inclui
medidas de conexão e coesão. Um sistema que tenha boa manutenção é mais provável
que tenha uma baixa medida de conexão (o grau em que os módulos dependem um do
outro durante a execução) e uma alta medida de coesão (o grau em que um módulo é
independente e focado em uma única tarefa).
• Eles indicam, no código orientado a objetos, onde objetos derivados podem ter muita ou
pouca visibilidade nas classes pai;
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 28 de 73
• Eles destacam áreas em código ou arquitetura com um alto nível de complexidade
estrutural.
A manutenção de um site também pode ser suportada usando ferramentas de análise estática.
Aqui, o objetivo é verificar se a estrutura em forma de árvore do site está bem equilibrada ou se
há um desequilíbrio que levará a:
• Tarefas de teste mais difíceis;
• Maior carga de trabalho de manutenção;
• Navegação difícil para o usuário.
3.2.4 Gráficos de chamadas
Os gráficos de chamada são uma representação estática da complexidade da comunicação. São
gráficos direcionados nos quais os nós representam os módulos do programa e as arestas
representam a comunicação entre esses módulos.
Os gráficos de chamada podem ser usados em testes de unidade, onde diferentes funções ou
métodos chamam um ao outro, em integração e teste de sistema quando módulos separados se
chamam, ou em teste de integração de sistema quando sistemas separados chamam um ao outro.
Os gráficos de chamada podem ser usados para os seguintes propósitos:
• Modelar testes que chamam um módulo ou sistema específico;
• Estabelecer o número de locais no software a partir dos quais um módulo ou sistema é
chamado;
• Avaliar a estrutura do código e da arquitetura do sistema;
• Dar sugestões para a ordem de integração (p. ex., integração em pares e vizinhança,
conforme discutido abaixo).
No syllabus CTFL Foundation Level [ISTQB_FL], duas categorias diferentes de teste de integração
foram discutidas: incremental (de cima para baixo, de baixo para cima etc.) e não incremental (big-
bang). Os métodos incrementais foram considerados preferidos porque introduzem o código em
incrementos, facilitando assim o isolamento de defeitos, uma vez que a quantidade de código
envolvida é limitada.
Nesse syllabus, são apresentados mais três métodos não incrementais usando gráficos de
chamada. Estes podem ser preferíveis aos métodos incrementais, que provavelmente exigirão
compilações adicionais para concluir o teste e código não entregável a ser gravado para dar
suporte ao teste. Esses três métodos são:
• Teste de integração em pares (para não confundir com a técnica de teste caixa-preta "teste
em pares"), tem como alvo pares de componentes que trabalham juntos, como visto no
gráfico de chamadas para testes de integração. Embora esse método reduza o número de
compilações apenas em uma pequena quantidade, reduz a quantidade de código de
equipamento de teste necessário.
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 29 de 73
• A integração de vizinhança testa todos os nós que se conectam a um determinado nó como
base para o teste de integração. Todos os nós predecessores e sucessores de um nó
específico no gráfico de chamadas são a base do teste.
• A abordagem de predicado de projeto de McCabe usa a teoria da complexidade ciclomática
aplicada a um gráfico de chamadas para módulos. Isso requer a construção de um gráfico
de chamada que mostra as diferentes maneiras pelas quais os módulos podem se chamar,
incluindo:
• Chamada incondicional: a chamada de um módulo para outro sempre acontece;
• Chamada condicional: a chamada de um módulo para outro às vezes acontece;
• Chamada condicional mutuamente exclusiva: um módulo chama um (e apenas
um) de um número de módulos diferentes;
• Chamada iterativa: um módulo chama outro pelo menos uma vez, mas pode
chamá-lo várias vezes;
• Chamada condicional iterativa: um módulo pode chamar outro zero várias vezes;
Após criar o gráfico de chamada, a complexidade da integração é calculada e testes são
criados para cobrir o gráfico.
Consulte [Jorgensen07] para obter mais informações sobre o uso de gráficos de chamadas e testes
de integração de vizinhança.
3.3 Análise dinâmica
3.3.1 Visão geral
A análise dinâmica é usada para detectar falhas em que os sintomas são visíveis apenas quando o
código é executado. Por exemplo, a possibilidade de vazamentos de memória pode ser detectável
por análise estática (encontrar código que aloca, mas nunca libera memória), mas um vazamento
de memória é facilmente aparente na análise dinâmica.
Falhas que não são imediatamente reproduzíveis (intermitentes) podem ter consequências
significativas no esforço de teste e na capacidade de liberar ou usar produtivamente o software.
Tais falhas podem ser causadas por vazamentos de memória ou recursos, uso incorreto de
ponteiros e outras corrupções (p. ex., na pilha do sistema) [Kaner02]. Devido à natureza dessas
falhas, que podem incluir a piora gradual da performance do sistema ou até mesmo falhas do
sistema, as estratégias de teste devem considerar os riscos associados a esses defeitos e, quando
apropriado, realizar análises dinâmicas para reduzi-los (geralmente usando ferramentas). Como
essas falhas geralmente são as falhas mais caras para localizar e corrigir, é recomendável iniciar a
análise dinâmica no início do projeto.
A análise dinâmica pode ser aplicada para realizar o seguinte:
• Impedir a ocorrência de falhas detectando vazamentos de memória (consultar o capítulo
3.3.2) e ponteiros selvagens (consultar o capítulo 3.3.3);
• Analisar falhas do sistema que não podem ser facilmente reproduzidas;
• Avaliar o comportamento da rede;
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 30 de 73
• Melhorar a performance do sistema, fornecendo informações sobre o comportamento do
sistema em tempo de execução, que podem ser usadas para fazer alterações informadas.
A análise dinâmica pode ser realizada em qualquer nível de teste e requer habilidades técnicas e
do sistema para:
• Especificar os objetivos de teste da análise dinâmica;
• Determinar o tempo adequado para iniciar e parar a análise;
• Analisar os resultados.
Durante o teste do sistema, ferramentas de análise dinâmica podem ser usadas mesmo se os
Analistas Técnicos de Teste tiverem habilidades técnicas mínimas; as ferramentas utilizadas
geralmente criam registros abrangentes que podem ser analisados por aqueles com as
habilidades técnicas necessárias.
3.3.2 Detectando vazamentos de memória
Um vazamento de memória ocorre quando as áreas de memória (RAM) disponíveis alocadas por
um programa, não são liberadas após o uso. Esta área de memória é deixada como alocada e não
está disponível para reutilização. Quando isso ocorre com frequência ou em situações de pouca
memória, o programa pode ficar sem memória utilizável. Historicamente, a manipulação de
memória era de responsabilidade do programador. Quaisquer áreas de memória alocadas
dinamicamente tiveram que ser liberadas pelo programa de alocação dentro do escopo correto
para evitar um vazamento de memória. Muitos ambientes de programação modernos incluem
“coleta de lixo” automática ou semi-automática, onde a memória alocada é liberada após o uso,
sem a intervenção direta do programador. Isolar vazamentos de memória pode ser muito difícil
nos casos em que a memória alocada existente é liberada pela coleta automática de lixo.
Vazamentos de memória causam problemas que se desenvolvem ao longo do tempo e podem
não ser imediatamente óbvios. Pode ser esse o caso se, por exemplo, o software foi instalado
recentemente ou o sistema reiniciado, o que geralmente ocorre durante o teste. Por esses
motivos, os efeitos negativos dos vazamentos de memória podem ser notados primeiro quando o
programa está em produção.
O principal sintoma de um vazamento de memória é um agravamento constante do tempo de
resposta do sistema, o que pode resultar em falha do sistema. Embora essas falhas possam ser
resolvidas com a reinicialização (reinicialização) do sistema, isso nem sempre é prático ou mesmo
possível.
Muitas ferramentas de análise dinâmica identificam áreas no código onde ocorrem vazamentos
de memória para que possam ser corrigidos. Monitores de memória simples também podem ser
usados para obter uma impressão geral de que a memória disponível está diminuindo ao longo
do tempo, embora ainda seja necessária uma análise de acompanhamento para determinar a
causa exata do declínio.
Aqui estão outros tipos de vazamentos que também devem ser considerados. Os exemplos
incluem identificadores de arquivo, semáforos e conjuntos de conexões de recursos.
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 31 de 73
3.3.3 Detectando ponteiros selvagens
Os ponteiros "selvagens" dentro de um programa são indicadores que não são mais precisos e
não devem ser usados. Por exemplo, um ponteiro selvagem pode ter "perdido" o objeto ou a
função para a qual deveria estar apontando ou não aponta para a área da memória pretendida (p.
ex., aponta para uma área que está além dos limites alocados de uma matriz) . Quando um
programa usa ponteiros selvagens, uma variedade de consequências pode ocorrer, incluindo:
• O programa pode ter a performance esperada. Pode ser o caso em que o ponteiro
selvagem acessa a memória que atualmente não é usada pelo programa e é supostamente
"livre" ou contém um valor aceitável.
• O programa pode falhar. Nesse caso, o ponteiro selvagem pode ter feito com que uma
parte da memória seja usada incorretamente, o que é crítico para a execução do programa
(p. ex., o sistema operacional).
• O programa não funciona corretamente porque os objetos requeridos por ele não podem
ser acessados. Sob essas condições, o programa pode continuar funcionando, embora uma
mensagem de erro possa ser emitida.
• Os dados no local da memória podem estar corrompidos pelo ponteiro e
consequentemente valores incorretos são usados (isso também pode representar uma
ameaça à segurança).
Observe que quaisquer alterações feitas no uso da memória do programa (p. ex., uma nova
compilação após uma alteração de software) podem desencadear qualquer uma das quatro
consequências listadas acima. Isso é particularmente crítico quando, inicialmente, o programa
executa conforme o esperado, apesar do uso de ponteiros selvagens, e depois trava
inesperadamente (talvez até em produção) após uma alteração de software. É importante
observar que essas falhas geralmente são sintomas de um defeito subjacente (ou seja, um
ponteiro selvagem) (consulte [Kaner02], “Lição 74”). As ferramentas podem ajudar a identificar
ponteiros selvagens à medida que são usados pelo programa, independentemente de seu impacto
na execução do programa. Alguns sistemas operacionais possuem funções internas para verificar
violações de acesso à memória durante o tempo de execução. Por exemplo, o sistema operacional
pode gerar uma exceção quando um aplicativo tenta acessar um local de memória que está fora
da área de memória permitida desse aplicativo.
3.3.4 Análise da eficiência da performance
A análise dinâmica não é apenas útil para detectar falhas. Com a análise dinâmica da performance
do programa, as ferramentas ajudam a identificar gargalos na eficiência da performance e gerar
uma ampla variedade de métricas que podem ser usadas pelo desenvolvedor para ajustar a
performance do sistema. Por exemplo, informações podem ser fornecidas sobre o número de
vezes que um módulo é chamado durante a execução. Módulos que são chamados com
frequência seriam prováveis candidatos à melhoria de performance.
Ao mesclar as informações sobre o comportamento dinâmico do software com as informações
obtidas dos gráficos de chamadas durante a análise estática (consulte o capítulo 3.2.4), o testador
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 32 de 73
também pode identificar os módulos que podem ser candidatos a testes detalhados e extensivos
(p. ex., módulos que são frequentemente chamados e possuem muitas interfaces).
A análise dinâmica da performance do programa geralmente é feita durante a realização de testes
do sistema, embora também possa ser feita ao testar um único subsistema em fases anteriores
do teste, usando um ambiente preparado para teste. Detalhes adicionais são fornecidos no
syllabus CTFL-PT Performance Testing [ISTQB_FL_PT].
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 33 de 73
4 Características de qualidade para testes técnicos [345 min]
Conceitos-chave
responsabilidade, adaptabilidade, analisabilidade, autenticidade, disponibilidade, capacidade,
coexistência, compatibilidade, confidencialidade, tolerância a falhas, instalabilidade, integridade,
manutenção, maturidade, modificabilidade, modularidade, não rejeição, teste de aceite, perfil
operacional, eficiência de performance, portabilidade, característica de qualidade, capacidade de
recuperação, confiabilidade, modelo de crescimento da confiabilidade, substituibilidade, utilização
de recursos, reutilização, segurança, testabilidade, comportamento temporal
Objetivos de aprendizagem
4.2 Questões gerais de planejamento
TTA-4.2.1 (K4) Para um cenário específico, analisar os requisitos não funcionais e escrever as
respectivas seções do plano de teste.
TTA-4.2.2 (K3) Dado um risco específico do produto, definir os tipos de teste não-funcionais
apropriados.
TTA-4.2.3 (K2) Entender e explicar os estágios no ciclo de vida de desenvolvimento de software de
um aplicativo em que os testes não funcionais geralmente devem ser aplicados.
TTA-4.2.4 (K3) Para um determinado cenário, definir os tipos de defeitos que você esperaria
encontrar usando os diferentes tipos de testes não funcionais.
4.3 Teste de segurança
TTA-4.3.1 (K2) Explicar os motivos para incluir o teste de segurança em uma abordagem de teste.
TTA-4.3.2 (K2) Explicar os principais aspectos do planejamento e especificação do teste de
segurança.
4.4 Teste de confiabilidade
TTA-4.4.1 (K2) Explicar os motivos para incluir os testes de confiabilidade em uma abordagem de
teste
TTA-4.4.2 (K2) Explicar os principais aspectos do planejamento e especificação do teste de
confiabilidade.
4.5 Teste de performance
TTA-4.5.1 (K2) Explicar os motivos de incluir o teste de performance em uma abordagem de teste.
TTA-4.5.2 (K2) Explicar os principais aspectos do planejamento e especificação do teste de
performance.
4.6 Teste de manutenção
TTA-4.6.1 (K2) Explicar as razões para incluir os testes de manutenção em uma abordagem de
teste.
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 34 de 73
4.7 Teste de portabilidade
TTA-4.7.1 (K2) Explicar os motivos para incluir os testes de portabilidade em uma abordagem de
teste.
4.8 Teste de compatibilidade
TTA-4.8.1 (K2) Explicar os motivos para incluir os testes de compatibilidade em uma abordagem
de teste.
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 35 de 73
4.1 Introdução
Em geral, o Analista Técnico de Teste concentra os testes em "como" o produto funciona, em vez
dos aspectos funcionais de "o que" ele faz. Esses testes podem ocorrer em qualquer nível de teste.
Por exemplo, durante o teste de componentes de sistemas embarcados e em tempo real, é
importante realizar comparações de eficiência de performance e testar o uso dos recursos.
Durante o teste de aceite operacional e o teste do sistema, é apropriado o teste dos aspectos de
confiabilidade, como a capacidade de recuperação. Os testes nesse nível visam testar um sistema
específico, ou seja, combinações de hardware e software. O sistema específico em teste pode
incluir vários servidores, clientes, bancos de dados, redes e outros recursos. Independentemente
do nível de teste, o teste deve ser realizado de acordo com as prioridades de risco e os recursos
disponíveis.
Deve-se notar que os testes dinâmicos e estáticos (consulte o capítulo 3) podem ser aplicados para
testar as características de qualidade não-funcionais descritas nesse capítulo.
A descrição das características de qualidade do produto fornecida na ISO-25010 [ISO25010] é
usada como um guia para descrever as características e suas subcaracterísticas. Eles são
mostrados na tabela abaixo, juntamente com uma indicação de quais características ou
subcaracterísticas são cobertas pelos analistas de testes e pelos analistas técnicos de teste.
Características Subcaracterísticas TA TTA
Adequação
funcional Correção funcional, adequação funcional, integridade funcional X
Confiabilidade Maturidade, tolerância a falhas, recuperação, disponibilidade X
Usabilidade
Reconhecimento de adequação, capacidade de aprender,
operacionalidade, atratividade, proteção contra erros do usuário,
acessibilidade
X
Eficiência da
performance Comportamento temporal, utilização de recursos, capacidade X
Manutenção Analisabilidade, modificabilidade, testabilidade, modularidade,
reutilização X
Portabilidade Adaptabilidade, instalabilidade, substituibilidade X
Segurança Confidencialidade, integridade, não rejeição, responsabilidade,
autenticidade X
Compatibilidade Coexistência X
Interoperabilidade X
Observe que uma tabela é fornecida no Apêndice A, que compara as características descritas na
ISO 9126 (conforme usada na versão 2012 deste syllabus) com as da ISO-25010 mais recente.
Para todas as características e subcaracterísticas de qualidade discutidas nesse capítulo, os riscos
típicos devem ser reconhecidos para que uma abordagem de teste apropriada possa ser formada
e documentada. O teste das características de qualidade requer atenção especial ao tempo do
ciclo de vida, ferramentas necessárias, padrões exigidos, disponibilidade de software e
documentação e conhecimento técnico. Sem planejar uma abordagem para lidar com cada
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 36 de 73
característica e suas necessidades exclusivas de teste, o testador pode não ter um tempo
adequado de planejamento, preparação e execução de teste embutido no cronograma [Bath14].
Alguns desses testes, por exemplo, testes de performance, requerem planejamento extenso,
equipamentos dedicados, ferramentas específicas, habilidades especializadas em testes e, na
maioria dos casos, uma quantidade significativa de tempo. O teste das características e
subcaracterísticas da qualidade deve ser integrado ao cronograma geral de testes, com os
recursos adequados alocados ao esforço. Cada um desses tipos de teste tem necessidades
específicas, tem como alvo problemas específicos e pode ocorrer em momentos diferentes
durante o ciclo de vida de desenvolvimento de software, conforme discutido nas seções abaixo.
Embora o Gerente de Teste se preocupe em compilar e relatar as informações resumidas das
métricas referentes às características e subcaracterísticas da qualidade, o Analista de Testes ou o
Analista Técnico de Teste (de acordo com a tabela acima) reúne as informações de cada métrica.
As medições das características de qualidade reunidas em testes de pré-produção pelo Analista
Técnico de Teste podem formar a base dos SLAs (Service Level Agreements) entre o fornecedor e os
stakeholders (p. ex., clientes, operadores) do sistema de software. Em alguns casos, os testes
podem continuar sua execução depois que o software entra em produção, geralmente por uma
equipe ou organização separada. Isso geralmente é observado nos testes para medir a eficiência
e a confiabilidade da performance, que podem mostrar resultados diferentes no ambiente de
produção e no ambiente de teste.
4.2 Questões gerais de planejamento
A falha no planejamento de testes não funcionais pode colocar o sucesso de um aplicativo em
considerável risco. O Analista Técnico de Testes pode ser solicitado pelo Gerente de Testes para
identificar os principais riscos para as características relevantes da qualidade (consulte a tabela no
capítulo 4.1) e solucionar quaisquer problemas de planejamento associados aos testes propostos.
Esta informação pode ser usada na criação do plano de teste principal.
Os seguintes fatores gerais são considerados ao executar essas tarefas:
• Requisitos dos stakeholders;
• Aquisição e treinamento de ferramentas necessárias;
• Requisitos do ambiente de teste;
• Considerações organizacionais;
• Considerações sobre segurança de dados;
• Riscos e defeitos típicos.
4.2.1 Requisitos dos stakeholders
Os requisitos não funcionais costumam ser mal especificados ou até inexistentes. No estágio de
planejamento, os Analistas Técnicos de Teste devem ser capazes de obter níveis de expectativa
relacionados às características técnicas de qualidade dos stakeholders afetados e avaliar os riscos
que eles representam.
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 37 de 73
Uma abordagem comum é assumir que, se o cliente estiver satisfeito com a versão existente do
sistema, ele continuará satisfeito com as novas versões, desde que os níveis de qualidade
alcançados sejam mantidos. Isso permite que a versão existente do sistema seja usada como
referência. Essa pode ser uma abordagem particularmente útil a ser adotada para algumas das
características de qualidade não-funcionais, como eficiência de performance, nas quais os
stakeholders podem achar difícil especificar seus requisitos.
É aconselhável obter vários pontos de vista ao capturar requisitos não funcionais. Eles devem ser
extraídos de stakeholders, como clientes, proprietários de produtos, usuários, equipe de
operações e equipe de manutenção. Se os principais stakeholders forem excluídos, é provável que
alguns requisitos sejam perdidos. Para obter mais detalhes sobre os requisitos de captura,
consulte o syllabus do CTAL-TM Test Manager [ISTQB_AL_TM].
Os requisitos não funcionais em projetos ágeis podem ser declarados como histórias de usuários
ou adicionados às funcionalidades específicas nos casos de uso como restrições não funcionais.
4.2.2 Aquisição e treinamento de ferramentas necessárias
Ferramentas comerciais ou simuladores são particularmente relevantes para a eficiência de
performance e determinados testes de segurança. Os Analistas Técnicos de Teste devem estimar
os custos e prazos envolvidos na aquisição, aprendizado e implementação das ferramentas. Onde
ferramentas especializadas devem ser usadas, o planejamento deve levar em consideração as
curvas de aprendizado de novas ferramentas ou o custo da contratação de especialistas externos
nas ferramentas.
O desenvolvimento de um simulador complexo pode representar um projeto por si só e deve ser
planejado como tal. Em particular, o teste e a documentação da ferramenta desenvolvida devem
ser contabilizados no cronograma e no plano de recursos. O orçamento e o tempo devem ser
planejados para atualizar e testar novamente o simulador conforme o produto simulado é
alterado. O planejamento de simuladores para uso em aplicações críticas de proteção deve levar
em conta o teste de aceite e a possível certificação do simulador por um organismo independente.
4.2.3 Requisitos do ambiente de teste
Muitos testes técnicos (p. ex., testes de segurança, testes de performance) requerem um ambiente
de teste semelhante à produção para fornecer medidas realistas. Dependendo do tamanho e da
complexidade do sistema em teste, isso pode ter um impacto significativo no planejamento e
financiamento dos testes. Como o custo desses ambientes pode ser alto, as seguintes alternativas
podem ser consideradas:
• Usar o ambiente de produção;
• Usar uma versão reduzida do sistema, cuidando para que os resultados dos testes obtidos
sejam suficientemente representativos ao sistema de produção;
• Usar recursos baseados na nuvem como uma alternativa para adquiri-los diretamente;
• Usar ambientes virtualizados.
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 38 de 73
O tempo dessas execuções de teste deve ser planejado com cuidado e é bem provável que esses
testes possam ser executados apenas em horários específicos (p. ex., em tempos de uso baixos).
4.2.4 Considerações organizacionais
Os testes técnicos podem envolver a medição do comportamento de vários componentes em um
sistema completo (p. ex., servidores, bancos de dados, redes). Se esses componentes forem
distribuídos por vários sites e organizações diferentes, o esforço necessário para planejar e
coordenar os testes pode ser significativo. Por exemplo, certos componentes de software podem
estar disponíveis apenas para testes do sistema em determinados momentos do dia ou ano, ou
as organizações podem oferecer suporte apenas para testes por um número limitado de dias.
Deixar de confirmar se os componentes e a equipe do sistema (ou seja, conhecimento
"emprestado") de outras organizações estão disponíveis "de plantão" para fins de teste pode
resultar em sérios distúrbios nos testes programados.
4.2.5 Considerações sobre segurança de dados
Medidas de segurança específicas implementadas para um sistema devem ser levadas em
consideração no estágio de planejamento do teste para garantir que todas as atividades de teste
sejam possíveis. Por exemplo, o uso da criptografia de dados pode dificultar a criação de dados de
teste e a verificação dos resultados.
As políticas e leis de proteção de dados podem impedir a geração de qualquer dado de teste
necessário com base nos dados de produção (p. ex., dados pessoais, dados de cartão de crédito).
Tornar os dados de teste anônimos é uma tarefa não trivial que deve ser planejada como parte da
implementação do teste.
4.2.6 Riscos e defeitos típicos
Identificar e gerenciar riscos é uma consideração fundamental para o planejamento de testes
(consulte o Capítulo 1). O Analista Técnico de Teste identifica os riscos do produto usando o
conhecimento dos tipos típicos de defeitos que se espera de uma característica de qualidade
específica. Isso permite que os tipos de teste necessários para lidar com esses riscos sejam
selecionados. Esses aspectos específicos são abordados nas seções restantes deste capítulo, que
descrevem as características individuais da qualidade.
4.3 Teste de segurança
4.3.1 Motivos para considerar o teste de segurança
O teste de segurança avalia a vulnerabilidade de um sistema às ameaças que comprometem a
política de segurança do sistema. A seguir, é apresentada uma lista de possíveis ameaças que
devem ser exploradas durante os testes de segurança:
• Cópia não autorizada de aplicativos ou dados;
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 39 de 73
• Controle de acesso não autorizado (p. ex., capacidade de executar tarefas para as quais o
usuário não tem direitos). Direitos do usuário, acesso e privilégios são o foco deste teste.
Esta informação deve estar disponível nas especificações do sistema;
• Software que exibe efeitos colaterais indesejados ao executar a função pretendida. Por
exemplo, um “Media Player” que reproduz corretamente o áudio, mas faz isso gravando
arquivos no armazenamento temporário não criptografado, exibe um efeito colateral que
pode ser explorado por piratas do software;
• Código inserido em uma página da web que pode ser acessada por usuários (scripts entre
sites ou XSS). Este código pode ser malicioso;
• Estouro de buffer que pode ser causado pela inserção de strings em um campo de entrada
da interface do usuário que são maiores do que o código pode manipular corretamente.
Uma vulnerabilidade de estouro de buffer representa uma oportunidade para executar
instruções de código mal-intencionado;
• Denial of Service, que impede que os usuários interajam com um aplicativo (p. ex.,
sobrecarregando um servidor da Web com solicitações "incômodas").
• A interceptação, imitação ou alteração e retransmissão subsequente de comunicações (p.
ex., transações com cartão de crédito) por terceiros, de modo que um usuário permaneça
inconsciente da presença desse terceiro (ataque Man in the Middle);
• Quebrar os códigos de criptografia usados para proteger dados confidenciais;
• Bombas lógicas (às vezes chamadas de Ovos de Páscoa), que podem ser inseridas
maliciosamente no código e ativadas apenas sob determinadas condições (p. ex., em uma
data específica). Quando as bombas lógicas são ativadas, elas podem executar atos
maliciosos, como a exclusão de arquivos ou a formatação de discos.
4.3.2 Planejamento de teste de segurança
Em geral, os seguintes aspectos são de particular relevância ao planejar testes de segurança:
• Como os problemas de segurança podem ser introduzidos durante a arquitetura, o
desenho e a implementação do sistema, os testes de segurança podem ser agendados para
os níveis de unidade, integração e teste do sistema. Devido à natureza variável das ameaças
à segurança, os testes de segurança também podem ser agendados regularmente após o
sistema entrar em produção. Isso é particularmente verdadeiro para arquiteturas
dinâmicas abertas, como a Internet das Coisas (IoT), em que a fase de produção é
caracterizada por muitas atualizações nos elementos de software e hardware usados.
• As abordagens de teste propostas pelo Analista Técnico de Testes podem incluir revisões
da arquitetura, desenho e código, e a análise estática do código com ferramentas de
segurança. Eles podem ser eficazes para encontrar problemas de segurança que são
facilmente esquecidos durante o teste dinâmico.
• O Analista Técnico de Teste pode ser chamado para planejar e executar determinados
ataques de segurança (veja abaixo), que exigem planejamento e coordenação cuidadosos
com os stakeholders (incluindo especialistas em testes de segurança). Outros testes de
segurança podem ser realizados em cooperação com desenvolvedores ou analistas de
teste (p. ex., testando direitos, acesso e privilégios de usuário).
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 40 de 73
• Um aspecto essencial do planejamento de testes de segurança é obter aprovações. Para o
Analista Técnico de Teste, isso significa garantir que uma permissão explícita tenha sido
obtida do Gerente de Teste para executar os testes de segurança planejados. Quaisquer
testes adicionais não planejados realizados podem parecer ataques reais e a pessoa que
os realiza pode estar em risco de ação legal. Sem nada escrito para mostrar intenção e
autorização, pode ser difícil explicar de forma convincente a desculpa "Estávamos
realizando um teste de segurança".
• Todo o planejamento dos testes de segurança deve ser coordenado com o responsável pela
segurança da informação da organização, se a ela possuir essa função.
• Deve-se observar que as melhorias que podem ser feitas na segurança de um sistema
podem afetar sua eficiência ou confiabilidade de performance. Após fazer melhorias na
segurança, é aconselhável considerar a necessidade de realizar testes para medir a
eficiência ou a confiabilidade da performance (consulte as seções 4.4 e 4.5 abaixo).
Padrões individuais podem ser aplicados ao realizar um planejamento de teste de segurança,
como [ISO/IEC 62443-3-2], que se aplica aos sistemas de controle e automação industrial.
O syllabus CTAL-SEC Security Tester [ISTQB_AL_SEC] inclui mais detalhes dos principais elementos
do plano de teste de segurança.
4.3.3 Especificação de teste de segurança
Testes de segurança específicos podem ser agrupados [Whittaker04] de acordo com a origem do
risco de segurança. Isso inclui:
• Relacionado à interface do usuário: acesso não autorizado e entradas maliciosas;
• Relacionado ao sistema de arquivos: acesso a dados confidenciais armazenados em
arquivos ou repositórios;
• Relacionado ao sistema operacional: armazenamento de informações confidenciais,
como senhas não criptografada na memória, que podem ser expostas quando o sistema
falha devido a entradas maliciosas;
• Relacionado à software externo: interações que podem ocorrer entre componentes
externos que o sistema utiliza. Eles podem estar no nível da rede (p. ex., pacotes ou
mensagens incorretas passadas) ou no nível do componente de software (p. ex., falha de
um componente de software no qual o software depende).
As subcaracterísticas de segurança ISO 25010 [ISO25010] também fornecem uma base a partir da
qual os testes de segurança podem ser especificados. Eles se concentram nos seguintes aspectos
de segurança:
• Confidencialidade: o grau em que um produto ou sistema garante que os dados sejam
acessíveis apenas àqueles autorizados a ter acesso;
• Integridade: o grau em que um sistema, produto ou componente impede o acesso não
autorizado ou a modificação de programas ou dados de computador;
• Não-repúdio: o grau em que as ações ou eventos podem ser comprovadamente
realizados, para que não possam ser negados posteriormente;
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 41 de 73
• Prestação de contas: o grau em que as ações de uma entidade podem ser rastreadas
exclusivamente para a entidade;
• Autenticidade: o grau em que se pode provar que a identidade de um sujeito ou recurso
é a reivindicada.
A seguinte abordagem [Whittaker04] pode ser usada para desenvolver testes de segurança:
• Reunir informações que possam ser úteis na especificação dos testes, como nomes de
funcionários, endereços físicos, detalhes sobre as redes internas, números IP, identidade
do software ou hardware usado e versão do sistema operacional.
• Verificar a vulnerabilidade usando ferramentas amplamente disponíveis. Essas
ferramentas não são usadas diretamente para comprometer o(s) sistema(s), mas para
identificar a vulnerabilidade resultante, ou que podem resultar, em uma violação da política
de segurança. Vulnerabilidades específicas também podem ser identificadas usando
informações e checklists, como as fornecidas pelo National Institute of Standards and
Technology (NIST) [Web-1] e pelo Open Web Application Security Project ™ (OWASP) [Web-4].
• Desenvolver "planos de ataque" (ou seja, um plano de ações de teste destinadas a
comprometer a política de segurança de um sistema específico) usando as informações
coletadas. Precisam ser especificadas nos planos de ataque várias entradas por meio de
várias interfaces (p. ex., interface do usuário, sistema de arquivos) para detectar os defeitos
de segurança mais graves. Os vários "ataques" descritos em [Whittaker04] são uma fonte
valiosa de técnicas desenvolvidas especificamente para testes de segurança.
Observe que os planos de ataque podem ser desenvolvidos para testes de penetração (consulte
[ISTQB_AL_SEC]).
As questões de segurança também podem ser expostas através de revisões (ver Capítulo 5) ou da
utilização de ferramentas de análise estática (ver Secção 3.2). As ferramentas de análise estática
contêm um extenso conjunto de regras específicas para ameaças à segurança e contra as quais o
código é verificado. Por exemplo, problemas de excesso de buffer, causados por falha na
verificação do tamanho do buffer antes da atribuição de dados, podem ser encontrados pela
ferramenta
O capítulo 3.2 (análise estática) e o syllabus CTAL-SEC Security Tester [ISTQB_AL_SEC] incluem mais
detalhes dos testes de segurança.
4.4 Teste de confiabilidade
4.4.1 Introdução
A classificação ISO 25010 das características de qualidade do produto define as seguintes
subcaracterísticas de confiabilidade:
• Maturidade: o grau em que um componente ou sistema atende às necessidades de
confiabilidade em operação normal;
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 42 de 73
• Tolerância ao erro: a capacidade do produto de software de manter um nível específico
de performance em casos de defeitos de software ou de violação de sua interface
especificada;
• Recuperabilidade: a capacidade do produto de software para restabelecer um nível
específico de performance e recuperar os dados diretamente afetados em caso de falha;
• Disponibilidade: o grau em que um componente ou sistema está operacional e acessível
quando necessário para uso.
4.4.2 Medindo a maturidade do software
Um objetivo do teste de confiabilidade é monitorar uma medida estatística da maturidade do
software ao longo do tempo e compará-la com uma meta de confiabilidade desejada que pode
ser expressa como um SLA (Service Level Agreement). As medidas podem assumir a forma de tempo
médio entre falhas (MTBF), tempo médio para reparo (MTTR) ou qualquer outra forma de medição
da intensidade de falhas (p. ex., número de falhas de uma determinada gravidade que ocorrem
por semana). Eles podem ser usados como critério de saída (p. ex., para liberação da produção).
Observe que a maturidade no contexto de confiabilidade não deve ser confundida com a
maturidade do processo geral de teste de software, conforme discutido no syllabus do CTAL-TM
Test Manager [ISTQB_AL_TM].
4.4.3 Teste de tolerância a falhas
Além do teste funcional que avalia a tolerância do software a falhas em termos de manipulação
inesperada de valores de entrada (chamados testes negativos), são necessários testes adicionais
para avaliar a tolerância de um sistema a falhas que ocorrem externamente ao aplicativo em teste.
Tais falhas são normalmente relatadas pelo sistema operacional (p. ex., disco cheio, processo ou
serviço não disponível, arquivo não encontrado, memória não disponível). Testes de tolerância a
falhas no nível do sistema podem ser suportados por ferramentas específicas.
Observe que os termos “robustez” e “tolerância a erros” também são comumente usados ao
discutir a tolerância a falhas (consulte [ISTQB_GLOSSARY] para obter detalhes).
4.4.4 Teste de recuperação
Outras formas de teste de confiabilidade avaliam a capacidade do sistema de software de se
recuperar de falhas de hardware ou software de uma maneira predeterminada, o que
subsequentemente permite que as operações normais sejam retomadas. Os testes de
recuperação incluem teste sobre falha e teste de backup e restauração.
Os testes sobre falhas são realizados onde as consequências de uma falha de software são tão
negativas que medidas específicas de hardware ou software foram implementadas para garantir
a operação do sistema, mesmo no caso de uma falha. Os testes sobre falhas podem ser aplicáveis,
por exemplo, onde o risco de perda financeira é extremo ou onde existem problemas críticos de
segurança (proteção). Onde as falhas podem resultar de eventos catastróficos, a forma do teste
de recuperação também pode ser chamada de teste de "recuperação de desastre".
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 43 de 73
As típicas medidas preventivas para as falhas de hardware podem incluir o balanceamento de
carga em vários processadores e servidores, processadores ou discos de cluster, para que um
possa substituir imediatamente o outro se falhar (sistemas redundantes). Uma típica medida pode
ser a implementação de mais de uma instância independente de um sistema de software (p. ex.,
o sistema de controle de voo de uma aeronave) nos chamados sistemas redundantes. Os sistemas
redundantes geralmente são uma combinação de medidas de software e hardware e podem ser
chamados de sistemas duplex, triplex ou quadruplex, dependendo do número de instâncias
independentes (duas, três ou quatro, respectivamente). O aspecto diferente do software é
alcançado quando os mesmos requisitos são fornecidos a duas ou mais equipes de
desenvolvimento independentes e não conectadas, com o objetivo de ter os mesmos serviços
fornecidos com software diferente. Isso protege os sistemas redundantes, pois uma entrada
defeituosa semelhante tem menos probabilidade de ter o mesmo resultado. Essas medidas
tomadas para melhorar a capacidade de recuperação de um sistema também podem influenciar
diretamente sua confiabilidade e devem ser consideradas ao realizar os testes de confiabilidade.
O teste sobre falha foi projetado para testar explicitamente os sistemas, simulando modos de falha
ou realmente causando falhas em um ambiente controlado. Após uma falha, o mecanismo é
testado para garantir que os dados não sejam perdidos ou corrompidos e que quaisquer níveis de
serviço acordados sejam mantidos (p. ex., disponibilidade da função ou tempos de resposta).
Os testes de backup e recuperação se concentram nas medidas processuais configuradas para
minimizar os efeitos de uma falha. Esses testes avaliam os procedimentos (geralmente
documentados em um manual) para fazer diferentes formas de backup e restaurar esses dados
se ocorrer perda ou corrupção de dados. Os casos de teste são projetados para garantir que os
caminhos críticos de cada procedimento sejam cobertos. Revisões técnicas podem ser executadas
para "executar a seco" esses cenários e validar os manuais com relação aos procedimentos reais.
O teste de aceite operacional exercita os cenários em um ambiente de produção ou semelhante à
produção para validar seu uso real.
As medidas para testes de backup e restauração podem incluir o seguinte:
• Tempo gasto para executar diferentes tipos de backup (p. ex., completo, incremental);
• Tempo gasto para restaurar dados;
• Níveis garantia de backup de dados (p. ex., recuperação de todos os dados com no máximo
24 horas, recuperação de dados de transações específicas com no máximo uma hora) .
4.4.5 Teste de disponibilidade
Qualquer sistema que tenha interfaces com outros sistemas ou processos (p. ex., para receber
entradas) depende da disponibilidade dessas interfaces para garantir a operacionalidade geral.
O teste de disponibilidade atende principalmente aos seguintes objetivos:
• Estabelecer se os componentes e processos necessários do sistema estão disponíveis (sob
demanda ou continuamente) e responder conforme o esperado às solicitações
• Fornecer medidas a partir das quais um nível geral de disponibilidade pode ser obtido
(geralmente fornecido como uma porcentagem do tempo em um SLA).
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 44 de 73
• Estabelecer se um sistema geral está pronto para operação (p. ex., como um dos critérios
para o teste de aceite operacional).
O teste de disponibilidade é realizado antes e depois da entrada em serviço operacional e é
particularmente relevante para as seguintes situações:
• Onde os sistemas são compostos de outros sistemas (ou seja, sistemas de sistemas). Os
testes se concentram na disponibilidade de todos os sistemas de componentes individuais.
• Onde um sistema ou serviço é fornecido externamente (p. ex., de um fornecedor
terceirizado). Os testes se concentram na medição dos níveis de disponibilidade para
garantir que os níveis de serviço acordados sejam mantidos.
A disponibilidade pode ser medida usando ferramentas de monitoramento dedicadas ou
executando testes específicos. Esses testes são tipicamente automatizados e podem ser
executados paralelamente às operações normais desde que não as afetem (p. ex., reduzindo a
eficiência da performance).
4.4.6 Planejamento de teste de confiabilidade
Em geral, os seguintes aspectos são de particular relevância ao planejar testes de confiabilidade:
• A monitoração da confiabilidade pode ser contínua, mesmo após o software entrar em
produção. A organização e a equipe responsável pela operação do software devem ser
consultadas ao reunir requisitos de confiabilidade para fins de planejamento de teste.
• O Analista Técnico de Teste pode selecionar um modelo de crescimento da confiabilidade
que mostre os níveis esperados de confiabilidade ao longo do tempo. Um modelo de
crescimento da confiabilidade pode fornecer informações úteis ao Gerenciador de Testes,
permitindo a comparação dos níveis de confiabilidade esperados e alcançados.
• Testes de confiabilidade devem ser realizados em um ambiente semelhante ao de
produção. O ambiente usado deve permanecer o mais estável possível para permitir que
as tendências de confiabilidade sejam monitoradas ao longo do tempo.
• Como os testes de confiabilidade geralmente exigem o uso de todo o sistema, eles são
geralmente realizados como parte dos testes do sistema. No entanto, componentes
individuais podem ser submetidos a testes de confiabilidade, bem como conjuntos
integrados de componentes. Revisões detalhadas de arquitetura, desenho e código
também podem ser usadas para remover alguns dos riscos de problemas de confiabilidade
que ocorrem no sistema implementado.
• Para produzir resultados estatisticamente significativos, os testes de confiabilidade
geralmente exigem longos períodos de execução. Isso pode dificultar seu agendamento no
planejamento dos testes.
4.4.7 Especificação do teste de confiabilidade
O teste de confiabilidade pode assumir a forma de um conjunto repetido de testes
predeterminados. Podem ser testes selecionados aleatoriamente a partir de um grupo de casos
de teste, ou gerados por um modelo estatístico usando métodos aleatórios ou pseudo-aleatórios.
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 45 de 73
Os testes também podem ser baseados em padrões de uso que às vezes são chamados de “Perfis
Operacionais” (consulte capítulo 4.5.3).
Onde os testes de confiabilidade são agendados para execução automática em paralelo às
operações normais (p. ex., para testar a disponibilidade), geralmente são especificados de forma
mais simples possível, para evitar possível impacto negativo na eficiência da performance do
sistema.
Certos testes de confiabilidade podem especificar que ações intensivas em memória sejam
executadas repetidamente, para que possíveis vazamentos de memória sejam detectados.
4.5 Teste de performance
4.5.1 Tipos de teste de performance
Teste de carga
O teste de carga concentra-se na capacidade de um sistema lidar com níveis crescentes de cargas
reais resultantes de solicitações de transação, geradas por um certo número de usuários ou
processos simultâneos. Os tempos médios de resposta dos usuários em diferentes cenários típicos
de uso (perfis operacionais) podem ser medidos e analisados. Veja também [Splaine01].
Teste de estresse
O teste de estresse concentra-se na capacidade de um sistema ou componente em lidar com picos
de cargas dentro ou além dos limites da capacidade de carga de trabalho prevista, ou com
disponibilidade reduzida de recursos, como largura de banda disponível. Os níveis de performance
devem se degradar lenta e previsivelmente sem falhas, à medida que os níveis de estresse
aumentam. Em particular, a integridade funcional do sistema deve ser testada enquanto o sistema
está sob estresse, a fim de encontrar possíveis defeitos no processamento funcional ou
inconsistências de dados.
Um possível objetivo do teste de estresse é descobrir os limites nos quais um sistema realmente
falha, para que o "elo mais fraco da cadeia" possa ser determinado. O teste de estresse permite
que capacidade adicional seja adicionada ao sistema em tempo hábil (p. ex., memória, capacidade
da CPU, armazenamento do banco de dados).
Teste de escalabilidade
O teste de escalabilidade concentra-se na capacidade de um sistema atender a requisitos futuros
de eficiência, que podem estar além dos atualmente exigidos. O objetivo do teste é determinar a
capacidade de crescimento do sistema (p. ex., com mais usuários, grandes quantidades de dados
armazenados) sem atingir um ponto em que os requisitos de performance atualmente
especificados não possam ser atendidos ou o sistema falhe. Uma vez conhecidos os limites de
escalabilidade, os valores-limite podem ser definidos e monitorados na produção para fornecer
um aviso de problemas iminentes. Além disso, o ambiente de produção pode ser ajustado com
quantidades apropriadas de hardware para atender às necessidades previstas.
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 46 de 73
4.5.2 Planejamento de teste de performance
Além das questões gerais de planejamento descritas no capítulo 4.2, os seguintes fatores podem
influenciar o planejamento dos testes de performance:
• Dependendo do ambiente de teste usado e do software testado, (consulte capítulo 4.2.3),
os testes de performance podem exigir que todo o sistema seja implementado antes que
testes eficazes sejam realizados. Nesse caso, o teste de performance geralmente está
programado para ocorrer durante o teste do sistema. Outros testes de performance que
são executados efetivamente no nível do componente são agendados durante o teste de
unidade.
• Em geral, é desejável realizar testes iniciais de eficiência de performance o mais cedo
possível, mesmo se um ambiente semelhante à produção ainda não estiver disponível.
Esses testes iniciais podem encontrar problemas de eficiência de performance (p. ex.,
gargalos) e reduzir o risco do projeto, evitando correções de consumo de tempo nos
estágios posteriores do desenvolvimento ou produção de software.
• As revisões de código, em particular aquelas que se concentram nas interações com o
banco de dados, com os componentes, e no tratamento de erros, podem identificar
problemas de eficiência de performance (particularmente no que diz respeito à lógica de
“esperar e tentar novamente” e consultas ineficientes) e devem ser agendadas no início do
ciclo de vida de desenvolvimento de software.
• A largura de banda de hardware, software e rede necessária para executar os testes de
performance deve ser planejada e orçada. As necessidades dependem principalmente da
carga gerada, que pode basear-se no número de usuários virtuais simulados e na
quantidade de tráfego de rede que eles provavelmente gerarão. A falta de consideração
disso pode resultar em medições de performance não representativas. Por exemplo,
verificar os requisitos de escalabilidade de um site da internet muito visitado pode exigir a
simulação de centenas de milhares de usuários virtuais.
• A geração da carga necessária para os testes de performance pode influenciar
significativamente nos custos de aquisição de hardware e ferramenta. Isso deve ser
considerado no planejamento desses testes para garantir que haja financiamento
adequado.
• Os custos de geração de carga para os testes de performance podem ser minimizados
alugando-se uma infraestrutura de teste. Isso pode envolver, por exemplo, o aluguel de
licenças ferramentas de performance ou o uso de serviços terceirizados para atender às
necessidades de hardware (p. ex., serviços em nuvem). Se essa abordagem for adotada, o
tempo disponível para a realização dos testes de performance pode ser limitado e,
portanto, deve ser cuidadosamente planejado.
• Deve-se tomar cuidado no estágio de planejamento para garantir que a ferramenta de
performance a ser usada forneça a compatibilidade necessária com os protocolos de
comunicação usados pelo sistema em teste.
• Os defeitos relacionados à eficiência da performance geralmente têm um impacto
significativo no sistema em teste. Quando os requisitos são imperativos, geralmente é útil
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 47 de 73
realizar testes de performance nos componentes críticos (via drivers e simuladores) para
que os testes possam começar no início do ciclo de vida, em vez de esperar pelos testes do
sistema.
O syllabus CTFL-PT Performance Testing [ISTQB_FL_PT] inclui mais detalhes do planejamento de
testes de performance.
4.5.3 Especificação de teste de performance
A especificação de testes para diferentes tipos de testes de performance, como carga e estresse,
é baseada na definição de perfis operacionais. Eles representam formas distintas de
comportamento do usuário ao interagir com um aplicativo. Pode haver vários perfis operacionais
para um determinado aplicativo.
O número de usuários por perfil operacional pode ser obtido usando ferramentas de
monitoramento (onde o aplicativo real ou comparável já está disponível) ou prevendo o uso. Tais
previsões podem ser baseadas em algoritmos ou fornecidas pelo negócio da organização. Isso é
especialmente importante para especificar o(s) perfil(is) operacional(is) usados para teste de
escalabilidade.
Os perfis operacionais são a base para o número e os tipos de casos de teste usados durante o
teste de performance. Esses testes geralmente são controlados por ferramentas de teste que
criam usuários "virtuais" ou simulados em quantidades que representam o perfil em teste
(consulte o capítulo 6.2.2).
O syllabus CTFL-PT Performance Testing [ISTQB_FL_PT] inclui mais detalhes sobre a modelagem do
teste de performance.
4.5.4 Subcaracterísticas de qualidade de eficiência de performance
A classificação ISO 25010 das características de qualidade do produto inclui as seguintes
subcaracterísticas de eficiência de performance:
• Comportamento temporal: a capacidade de um componente ou sistema responder a
entradas do usuário ou do sistema dentro de um período e condições especificas;
• Utilização de recurso: a capacidade do produto de software de usar quantidades e tipos
apropriados de recursos;
• Capacidade: o limite máximo para o qual um parâmetro específico pode ser manipulado.
Comportamento temporal
O comportamento do tempo concentra-se na capacidade de um componente ou sistema
responder às entradas do usuário ou do sistema dentro de um período e condições específicas.
As medidas de comportamento do tempo variam de acordo com os objetivos do teste. Para
componentes de software individuais, o comportamento do tempo pode ser medido de acordo
com os ciclos da CPU, enquanto para sistemas baseados no cliente, o comportamento do tempo
pode ser medido de acordo com o tempo necessário para responder a uma solicitação específica
do usuário. Para sistemas cujas arquiteturas consistem em vários componentes (p. ex., clientes,
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 48 de 73
servidores, bancos de dados), são realizadas medições de comportamento do tempo para
transações entre componentes individuais, para que "gargalos" possam ser identificados.
Utilização de recurso
Os testes relacionados à utilização de recursos avaliam o uso de recursos do sistema (p. ex., uso
de memória, capacidade de disco, largura de banda da rede, conexões) em relação a um
benchmark predefinido. Eles são comparados tanto em cargas normais quanto em situações de
estresse, como altos níveis de transações e volumes de dados, para determinar se está ocorrendo
um crescimento não natural do uso.
Por exemplo, para sistemas embarcados em tempo real, o uso da memória (às vezes chamado de
"área de cobertura da memória") desempenha um papel significativo nos testes de performance.
Se o espaço ocupado na memória exceder a medida permitida, o sistema poderá ter memória
insuficiente para executar suas tarefas dentro dos períodos especificados. Isso pode tornar o
sistema mais lento ou até causar uma pane no sistema.
A análise dinâmica também pode ser aplicada à tarefa de investigar a utilização de recursos
(consulte o capítulo 3.3.4) e detectar gargalos na eficiência da performance.
Capacidade
A capacidade de um sistema (incluindo software e hardware) representa o limite máximo para o
qual um parâmetro específico pode ser manipulado. Os requisitos de capacidade geralmente são
especificados por stakeholders técnicos e operacionais e podem estar relacionados a parâmetros
como o número máximo de usuários que podem usar um aplicativo em um determinado
momento, o volume máximo de dados que podem ser transmitidos por segundo (largura de
banda) e o número máximo de transações que podem ser tratadas por segundo.
A abordagem para testar os limites de capacidade é geralmente semelhante à abordagem descrita
nos capítulos 4.5.2 e 4.5.3 para testar a eficiência da performance. Os perfis operacionais para
testes de capacidade concentram-se na geração de uma carga que exerce o limite específico. Isso
pode envolver, por exemplo, gerar uma carga que submeta o sistema à quantidade máxima de
transferência de dados. As abordagens de teste de estresse e teste de escalabilidade também
podem ser aplicadas à capacidade de testar o comportamento do sistema além dos limites de
capacidade especificados (consulte os capítulos 4.5.1.2 e 4.5.1.3, respectivamente).
4.6 Teste de manutenção
O software geralmente gasta substancialmente mais de sua vida útil sendo mantido do que
desenvolvido. O teste de manutenção é realizado para testar o impacto das alterações em um
sistema operacional ou em seu ambiente. Para garantir que a tarefa de realizar manutenção seja
o mais eficiente possível, são realizados testes de manutenção para medir a facilidade com que o
código possa ser analisado, alterado e testado.
Os objetivos típicos de manutenção dos stakeholders afetados (p. ex., o proprietário ou o operador
do software) incluem:
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 49 de 73
• Minimizar o custo de propriedade ou operação do software;
• Minimizar o tempo de inatividade necessário para a manutenção do software.
Os testes de manutenção devem ser incluídos em uma abordagem de teste em que se aplique um
ou mais dos seguintes fatores:
• As alterações de software são prováveis após a entrada em produção do software (p. ex.,
para corrigir defeitos ou introduzir atualizações planejadas);
• Os benefícios de alcançar os objetivos de manutenção durante o ciclo de vida de
desenvolvimento do software são considerados pelos stakeholders como superiores aos
custos da realização dos testes de manutenção e da realização das alterações necessárias;
• Os riscos de baixa manutenção do software (p. ex., longos tempos de resposta a defeitos
relatados por usuários ou clientes) justificam a realização de testes de manutenção.
4.6.1 Teste de manutenção estática e dinâmica
As técnicas apropriadas para testes de manutenção incluem análise e revisões estáticas, conforme
discutido nos capítulos 3.2 e 5.2. O teste de manutenção deve ser iniciado assim que a
documentação da modelagem estiver disponível e deve continuar durante todo o esforço de
implementação do código. Como a capacidade de manutenção é incorporada ao código e à
documentação de cada componente de código individual, a capacidade de manutenção pode ser
avaliada no início do ciclo de vida de desenvolvimento de software sem ter que esperar por um
sistema completo e em execução.
O teste dinâmico de manutenção concentra-se nos procedimentos documentados desenvolvidos
para manter um aplicativo específico (p. ex., para executar atualizações de software). As seleções
de cenários de manutenção são usadas como casos de teste para garantir que os níveis de serviço
necessários sejam atingíveis com os procedimentos documentados. Essa forma de teste é
particularmente relevante quando a infraestrutura subjacente é complexa e os procedimentos de
suporte podem envolver vários departamentos ou organizações. Essa forma de teste pode ocorrer
como parte do teste de aceite operacional.
4.6.2 Subcaracterísticas de manutenibilidade
A capacidade de manutenção de um sistema pode ser medida em termos do esforço necessário
para diagnosticar problemas identificados dentro de um sistema (analisabilidade) e testar o
sistema alterado (testabilidade). Os fatores que influenciam a analisabilidade e a testabilidade
incluem a aplicação de boas práticas de programação (p. ex., comentários, nomeação de variáveis,
indentação) e a disponibilidade de documentação técnica (p. ex., especificações de desenho do
sistema, especificações de interface).
Outras subcaracterísticas relevantes de qualidade para manutenção [ISO25010] são:
• Modificabilidade: o grau em que um componente ou sistema pode ser efetivamente e
eficientemente modificado sem a introdução de defeitos ou degradação da qualidade do
produto existente;
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 50 de 73
• Modularidade: o grau em que um sistema, produto ou componente é composto de
componentes distintos, de modo que uma alteração em um componente tenha um
impacto mínimo em outros componentes;
• Reutilização: o grau em que um ativo pode ser usado em mais de um sistema ou na
construção de outros ativos.
4.7 Teste de portabilidade
4.7.1 Introdução
Os testes de portabilidade em geral estão relacionados ao grau em que um componente ou
sistema de software pode ser transferido para o ambiente pretendido, inicialmente ou de um
ambiente existente.
A [ISO25010] inclui as seguintes subcaracterísticas de portabilidade:
• Instalabilidade: a capacidade de um produto de software ser instalado em um ambiente
específico;
• Adaptabilidade: o grau em que um componente ou sistema pode ser adaptado para
ambientes de hardware e software diferentes ou em evolução;
• Substituibilidade: a capacidade de um produto de software ser usado no lugar de outro,
no mesmo ambiente, para a mesma finalidade.
O teste de portabilidade pode começar com os componentes individuais (p. ex., substituibilidade
de um componente específico, como mudar de um sistema de gerenciamento de banco de dados
para outro) e depois expandir-se no escopo à medida que mais código se torna disponível. A
instalabilidade pode não ser testável até que todos os componentes do produto estejam
funcionando corretamente.
A portabilidade deve ser projetada e incorporada ao produto e, portanto, deve ser considerada no
início das fases de arquitetura e modelagem. As revisões de arquitetura e modelagem podem ser
particularmente produtivas para identificar possíveis requisitos e problemas de portabilidade (p.
ex., dependência de um sistema operacional específico).
4.7.2 Teste de instalabilidade
Os testes de instalabilidade são realizados no software e nos procedimentos escritos utilizados
para instalar o software no ambiente de destino. Isso pode incluir, por exemplo, o software
desenvolvido para instalar um sistema operacional em um processador, ou um "assistente de
instalação” para instalar um produto em um computador cliente.
Os objetivos comuns do teste de instalabilidade incluem:
• Validar se o software pode ser instalado com sucesso seguindo as instruções de um manual
de instalação (incluindo a execução de qualquer script de instalação) ou usando um
assistente de instalação. Isso inclui o teste das opções de instalação para diferentes
configurações de hardware ou software, e para vários níveis de instalação (p. ex., inicial ou
atualização);
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 51 de 73
• Testar se as falhas que ocorrem durante a instalação (p. ex., falha ao carregar DLLs
específicas) são tratadas corretamente pelo software de instalação sem deixar o sistema
em um estado indefinido (p. ex., software parcialmente instalado ou configurações
incorretas do sistema);
• Testar se uma instalação ou desinstalação parcial pode ser concluída;
• Testar se um assistente de instalação pode identificar com êxito as plataformas inválidas
de hardware ou as configurações do sistema operacional;
• Medir se o processo de instalação pode ser concluído dentro de um número específico de
tempo ou dentro de um número específico de etapas;
• Validar se o software pode ser desativado ou desinstalado com sucesso.
O teste de funcionalidade é normalmente realizado após o teste de instalação para detectar
quaisquer defeitos que possam ter sido introduzidos pela instalação (p. ex., configurações
incorretas, funções não disponíveis). O teste de usabilidade é normalmente executado em paralelo
com o teste de instalabilidade (p. ex., para validar que os usuários recebam instruções
compreensíveis e mensagens de feedback ou erro durante a instalação).
4.7.3 Teste de adaptabilidade
O teste de adaptabilidade verifica se um determinado aplicativo pode funcionar corretamente em
todos os ambientes de destino (hardware, software, middleware, sistema operacional etc.). Um
sistema adaptativo é, portanto, um sistema aberto capaz de ajustar seu comportamento de acordo
com as mudanças em seu ambiente ou em partes do próprio sistema. A especificação dos testes
de adaptabilidade requer que as combinações dos ambientes de destino pretendidos sejam
identificadas, configuradas e disponibilizadas para a equipe de testes. Esses ambientes são então
testados usando uma seleção de casos de teste funcionais que exercitam os vários componentes
presentes no ambiente.
A adaptabilidade pode estar relacionada à capacidade do software de ser portado para vários
ambientes específicos, executando um procedimento predefinido. Os testes podem avaliar este
procedimento.
Os testes de adaptabilidade podem ser realizados em conjunto com os testes de instalabilidade e
normalmente são seguidos por testes funcionais para detectar quaisquer defeitos que possam ter
sido introduzidos na adaptação do software a um ambiente diferente.
4.7.4 Teste de substituibilidade
O teste de substituibilidade concentra-se na capacidade dos componentes de software em um
sistema serem trocados por outros. Isso pode ser particularmente relevante para sistemas que
usam software comercial pronto para uso (COTS) para componentes específicos do sistema.
Os testes de substituibilidade podem ser realizados em paralelo com os testes de integração
funcional, onde mais de um componente alternativo está disponível para integração no sistema
completo. A substituibilidade pode ser avaliada por revisão técnica ou inspeção nos níveis de
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 52 de 73
arquitetura e modelagem, onde a ênfase é colocada na definição clara de interfaces para possíveis
componentes substituíveis.
4.8 Teste de compatibilidade
4.8.1 Introdução
O teste de compatibilidade considera os seguintes aspectos [ISO25010]:
• Coexistência: o grau em que um item de teste pode funcionar satisfatoriamente ao lado
de outros produtos independentes em um ambiente compartilhado. Isto é descrito abaixo.
• Interoperabilidade: o grau em que um sistema troca informações com outros sistemas ou
componentes. Isso é descrito no syllabus ISTQB® CTAL-TA Test Analyst [ISTQB_AL_TA].
4.8.2 Teste de coexistência
Diz-se que os sistemas de computador que não estão relacionados entre si coexistem quando
podem ser executados no mesmo ambiente (p. ex., no mesmo hardware) sem afetar o
comportamento um do outro (p. ex., conflitos de recursos). Os testes de coexistência devem ser
realizados quando o software novo ou atualizado for implementado em ambientes que já
contenham aplicativos instalados.
Problemas de coexistência podem surgir quando o aplicativo é testado em um ambiente em que
é o único aplicativo instalado (onde os problemas de incompatibilidade não são detectáveis) e
depois é implantado em outro ambiente (p. ex., produção) onde outros aplicativos estão em
execução.
Os objetivos comuns dos testes de coexistência incluem:
• Avaliação do possível impacto adverso na funcionalidade quando os aplicativos são
carregados no mesmo ambiente (p. ex., uso conflitante de recursos quando um servidor
executa vários aplicativos);
• Avaliação do impacto em qualquer aplicativo resultante da implantação de correções e
atualizações do sistema operacional.
Os problemas de coexistência devem ser analisados ao planejar o ambiente de produção alvo,
mas os testes reais normalmente são executados após o teste do sistema ser concluído com êxito.
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 53 de 73
5 Revisões [165 min]
Conceitos-chave
anti-padrão
Objetivos de aprendizagem
5.1 Tarefas do Analista Técnico de Teste nas revisões
TTA 5.1.1 (K2) Explicar por que a preparação da revisão é importante para o Analista Técnico de
Teste
5.2 Usando listas de verificação nas revisões
TTA 5.2.1 (K4) Analisar a arquitetura de um projeto e identificar os problemas de acordo com um
checklist fornecido no syllabus.
TTA 5.2.2 (K4) Analisar uma seção do código ou pseudocódigo e identificar os problemas de acordo
com um checklist fornecido no syllabus.
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 54 de 73
5.1 Tarefas do Analista Técnico de Teste nas revisões
Os Analistas Técnicos de Teste devem ser participantes ativos no processo de revisão técnica,
fornecendo suas visualizações exclusivas. Todos os participantes da revisão devem ter
treinamento formal em revisão para entender melhor suas respectivas funções e devem se
comprometer com os benefícios de uma revisão técnica bem conduzida. Isso inclui manter uma
relação de trabalho construtiva com os autores ao descrever e discutir os comentários da revisão.
Para uma descrição completa das revisões técnicas, incluindo várias listas de verificação, consulte
[Wiegers02]. Os Analistas Técnicos de Teste normalmente participam de revisões e inspeções
técnicas, onde trazem um ponto de vista operacional (comportamental) que pode ser esquecido
pelos desenvolvedores. Além disso, os Analistas Técnicos de Teste desempenham um papel
importante na definição, aplicação e manutenção de listas de verificação de revisão e informações
sobre a gravidade dos defeitos.
Independentemente do tipo de revisão que está sendo realizada, o Analista Técnico de Teste deve
ter tempo suficiente para se preparar. Isso inclui tempo para revisar o produto de trabalho, tempo
para verificar a documentação com referências cruzadas para verificar a consistência e tempo para
determinar o que pode estar faltando no produto de trabalho. Sem tempo de preparação
adequado, a revisão pode se tornar um exercício de edição, e não uma revisão verdadeira. Uma
boa revisão inclui a compreensão do que está escrito, a determinação do que está faltando e a
verificação de que o produto descrito é consistente com outros produtos que já foram
desenvolvidos ou estão em desenvolvimento. Por exemplo, ao revisar um plano de teste no nível
de integração, o Analista Técnico de Teste também deve considerar os itens que estão sendo
integrados. Eles estão prontos para a integração? Existem dependências que devem ser
documentadas? Existem dados disponíveis para testar os pontos de integração? Uma revisão não
é isolada para um produto de trabalho que está sendo revisado, ela também deve considerar a
interação desse item com outros no sistema.
5.2 Usando listas de verificação nas revisões
As listas de verificação são usadas durante as revisões para lembrar os participantes de verificar
pontos específicos durante a revisão. As listas de verificação também podem ajudar a personalizar
a revisão, por exemplo, "esta é a mesma lista que usamos para cada revisão e não estamos
segmentando apenas seu produto de trabalho". As listas de verificação podem ser genéricas e
usadas para todas as revisões ou focadas em características ou áreas específicas da qualidade. Por
exemplo, um checklist genérico pode verificar o uso adequado dos termos "dever" e "poder", e
verificar a formatação adequada e itens de conformidade semelhantes. Um checklist direcionado
pode se concentrar em problemas de segurança ou eficiência de performance.
Os checklilsts mais úteis são aqueles desenvolvidos gradualmente por uma organização individual,
porque refletem:
• A natureza do produto;
• O ambiente de desenvolvimento:
• Pessoal;
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 55 de 73
• Ferramentas;
• Prioridades;
• A história de sucessos e defeitos anteriores;
• Problemas específicos (p. ex., eficiência de performance, segurança etc.).
As listas de verificação devem ser personalizadas para a organização e talvez para o projeto em
particular. As listas de verificação fornecidas neste capítulo são apenas para servir como exemplos.
Algumas organizações estendem a noção usual de um checklist de software para incluir
“antipadrões” que se refiram a erros comuns, técnicas inadequadas e outras práticas ineficazes. O
termo deriva do conceito popular de "padrões de desenho", que são soluções reutilizáveis para
problemas comuns que demonstraram ser eficazes em situações práticas [Gamma94]. Um
antipadrão, portanto, é um erro comumente feito, geralmente implementado como um atalho
conveniente.
É importante lembrar que, se um requisito não pode ser testado, o que significa que não é definido
de forma que o Analista Técnico de Teste possa determinar como testá-lo, é um defeito. Por
exemplo, um requisito que declara "o software deve ser rápido" não pode ser testado. Como o
Analista Técnico de Testes determina se o software é rápido? Se, em vez disso, o requisito dissesse
"o software deve fornecer um tempo de resposta máximo de três segundos sob condições específicas de
carga", a testabilidade desse requisito é substancialmente melhor assumindo as "condições
específicas de carga" definidas (p. ex., número de usuários simultâneos, atividades executadas
pelos usuários). Também é um requisito abrangente, porque esse requisito pode facilmente gerar
muitos casos de teste individuais em um aplicativo não trivial. A rastreabilidade deste requisito
para os casos de teste também é crítica, pois se o requisito mudar, todos os casos de teste
precisarão ser revisados e atualizados conforme necessário.
5.2.1 Revisões de arquitetura
A arquitetura de software consiste na organização fundamental de um sistema, incorporado em
seus componentes, em seus relacionamentos entre si e com o meio ambiente e nos princípios que
governam seu desenho e evolução. [ISO42010], [Bass03].
As listas de verificação usadas para revisões de arquitetura podem, por exemplo, incluir a
verificação da implementação adequada dos seguintes itens, citados em [Web-2]:
• Pool de conexões: reduzindo o tempo de execução adicional associado ao estabelecimento
de conexões com o banco de dados, estabelecendo um pool compartilhado de conexões;
• Balanceamento de carga: distribuindo a carga uniformemente entre um conjunto de
recursos;
• Processamento distribuído;
• Armazenamento em cache: usando uma cópia local dos dados para reduzir o tempo de
acesso;
• Instanciação ociosa;
• Concorrência de transação;
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 56 de 73
• Isolamento do processo entre o processamento transacional online (OLTP) e o
processamento analítico online (OLAP);
• Replicação de dados”.
5.2.2 Revisões de código
As listas de verificação para revisões de código são necessariamente muito detalhadas e, assim
como as listas de verificação para revisões de arquitetura, são úteis quando são específicas da
linguagem, do projeto e da organização. A inclusão de antipadrões no nível do código é útil,
principalmente para desenvolvedores de software menos experientes.
Checklist usado para revisões de código pode incluir:
1. Estrutura
• O código implementa de forma completa e correta o desenho?
• O código está em conformidade com os padrões de codificação pertinentes?
• O código é bem estruturado, consistente em estilo e formatado de forma consistente?
• Existem procedimentos desnecessários, irrelevantes ou código inacessível?
• Existem restos de simuladores ou rotinas de teste no código?
• Qualquer código pode ser substituído por chamadas para componentes reutilizáveis
externos ou funções em bibliotecas?
• Existem blocos de código repetido que podem ser condensados em um único
procedimento?
• O uso do armazenamento é eficiente?
• Os símbolos são usados em vez de constantes de "números mágicos" ou strings?
• Existem módulos excessivamente complexos que devem ser reestruturados ou divididos
em vários módulos?
2. Documentação
• O código está claro e adequadamente documentado com um estilo de comentário fácil de
se manter?
• Todos os comentários são consistentes com o código?
• A documentação está em conformidade com os padrões aplicáveis?
3. Variáveis
• Todas as variáveis são definidas corretamente com nomes significativos, consistentes e
claros?
• Existem variáveis redundantes ou não utilizadas?
4. Operações aritméticas
• O código evita comparar números de ponto flutuante para igualdade?
• O código evita sistematicamente erros de arredondamento?
• O código evita acréscimos e subtrações em números com magnitudes muito diferentes?
• Os divisores são testados para zero ou ruídos?
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 57 de 73
5. Loops e Ramos
• Todos os loops, ramificações e construções lógicas estão completos, corretos e
armazenados corretamente?
• Os casos mais comuns são testados primeiro nas cadeias IF-ELSEIF?
• Todos os casos são cobertos por um bloco IF-ELSEIF ou CASE, incluindo cláusulas ELSE ou
DEFAULT?
• Todas as instruções de caso têm um padrão?
• As condições de fim de loop são óbvias e invariavelmente alcançáveis?
• Os índices ou subscritos foram inicializados corretamente e imediatamente antes do loop?
• Alguma instrução que está nos loops pode ser colocada fora?
• O código no loop evita manipular uma variável indexada ou usá-la ao sair do loop?
6. Programação defensiva
• Os índices, ponteiros e subscritos são testados em relação a limites de matriz, registro ou
arquivo?
• Os dados importados e os argumentos de entrada são testados quanto à validade e
integridade?
• Todas as variáveis de saída estão atribuídas?
• O elemento de dados correto é operado em cada instrução?
• Toda alocação de memória é liberada?
• Timeouts ou interceptações de erro são usados para acessar dispositivos externos?
• Os arquivos são verificados quanto à existência antes de tentar acessá-los?
• Todos os arquivos e dispositivos são deixados no estado correto após o encerramento do
programa?
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 58 de 73
6 Ferramentas de teste e automação [180 min]
Conceitos-chave
captura e reprodução, teste orientado por dados, depuração, emulador, plantando falhas,
hiperlink, teste orientado por palavras-chave, eficiência de performance, simulador, execução de
teste, gerenciamento de teste.
Objetivos de aprendizagem
6.1 Definindo o projeto de automação de teste
TTA-6.1.1 (K2) Resumir as atividades que o Analista Técnico de Teste executa ao configurar um
projeto de automação de teste.
TTA-6.1.2 (K2) Resumir as diferenças entre a automação orientada por dados e a por palavras-
chave.
TTA-6.1.3 (K2) Resumir os problemas técnicos comuns que fazem com que os projetos de
automação falhem ao atingir o retorno de investimento planejado.
TTA-6.1.4 (K3) Construir palavras-chave com base em um determinado processo de negócio.
6.2 Ferramentas específicas de teste
TTA-6.2.1 (K2) Resumir o objetivo das ferramentas para plantar e injetar falhas.
TTA-6.2.2 (K2) Resumir as principais características e questões de implementação para
ferramentas de teste de performance.
TTA-6.2.3 (K2) Explicar o objetivo geral das ferramentas usadas para testes baseados na web.
TTA-6.2.4 (K2) Explicar como as ferramentas suportam a prática de teste baseado em modelo.
TTA-6.2.5 (K2) Descrever os objetivos das ferramentas usadas para dar suporte ao teste de
componentes e ao processo de compilação.
TTA-6.2.6 (K2) Descrever os objetivos das ferramentas usadas para dar suporte ao teste de
aplicativos móveis.
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 59 de 73
6.1 Definindo o projeto de automação de teste
Para serem econômicas, as ferramentas de teste (e particularmente aquelas que suportam a sua
execução), devem ser cuidadosamente arquitetadas e projetadas. A implementação de uma
estratégia de automação de execução de teste sem uma arquitetura sólida geralmente resulta em
um conjunto de ferramentas de manutenção dispendiosa, insuficiente para a finalidade e incapaz
de atingir o retorno desejado do investimento.
Um projeto de automação de teste deve ser considerado um projeto de desenvolvimento de
software. Isso inclui a necessidade de documentação da arquitetura, documentação detalhada do
projeto, revisões de projeto e código, testes de componentes e de integração de componentes,
bem como testes finais do sistema. O teste pode ser desnecessariamente atrasado ou complicado
quando o código de automação de teste usado é instável ou impreciso.
Existem várias tarefas que o Analista Técnico de Teste pode executar em relação à automação da
execução de teste. Esses incluem:
• Determinar quem será responsável pela execução do teste (possivelmente em
coordenação com um Gerente de Teste);
• Selecionar a ferramenta apropriada para a organização, linha do tempo, habilidades da
equipe e requisitos de manutenção (observe que isso pode significar decidir criar uma
ferramenta para usar em vez de adquirir uma);
• Definir os requisitos de interface entre a ferramenta de automação e outras ferramentas,
como gerenciamento de teste, gerenciamento de defeitos e ferramentas usadas para
integração contínua;
• Desenvolver quaisquer adaptadores necessários para criar uma interface entre a
ferramenta de execução de teste e o software em teste;
• Selecionar a abordagem de automação, ou seja, orientada por palavras-chave ou por dados
(consulte o capítulo 6.1.1);
• Trabalhar com o Gerente de Teste para estimar o custo da implementação, incluindo
treinamento. Em projetos ágeis, esse aspecto normalmente seria discutido e acordado em
reuniões de planejamento de projeto/sprint com toda a equipe;
• Agendar o projeto de automação e alocar o tempo para manutenção;
• Treinar os analistas de teste e analistas de negócios para usar e fornecer dados para a
automação;
• Determinar como e quando os testes automatizados serão executados;
• Determinar como os resultados do teste automatizado serão combinados com os
resultados do teste manual;
Em projetos com forte ênfase na automação de teste, um Engenheiro de Automação de Teste pode
ser encarregado de muitas dessas atividades (consulte o syllabus CTAL-TAE Test Automation Engineer
[ISTQB_AL_TAE] para obter detalhes). Certas tarefas organizacionais podem ser executadas por
um Gerente de Teste de acordo com as necessidades e preferências do projeto. Nos projetos ágeis,
a atribuição dessas tarefas a funções é geralmente mais flexível e menos formal.
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 60 de 73
Essas atividades e as decisões resultantes influenciarão a escalabilidade e a capacidade de
manutenção da solução de automação. Deve-se gastar tempo suficiente pesquisando as opções,
investigando as ferramentas e tecnologias disponíveis e entendendo os planos futuros da
organização.
6.1.1 Selecionando a abordagem de automação
Esse capítulo considera os seguintes fatores que afetam a abordagem de automação de teste:
• Automatizando através da GUI;
• Aplicação de uma abordagem orientada por dados;
• Aplicação de uma abordagem orientada por palavras-chave;
• Lidando com falhas de software;
• Considerando o estado do sistema.
O syllabus CTAL-TAE Test Automation Engineer [ISTQB_AL_TAE] inclui mais detalhes sobre a seleção
de uma abordagem de automação.
6.1.1.1 Automatizando através da GUI
A automação de teste não se limita aos testes por meio da GUI. Existem ferramentas para ajudar
a automatizar os testes no nível da API, por meio de uma interface de linha de comando (CLI) e
outros pontos de interface no software em teste. Uma das primeiras decisões que o Analista
Técnico de Testes deve tomar é determinar a interface mais eficaz a ser acessada para automatizar
o teste. As ferramentas gerais de execução de teste requerem o desenvolvimento de adaptadores
para essas interfaces. O planejamento deve considerar o esforço para o desenvolvimento do
adaptador.
Uma das dificuldades de testar através da GUI é a tendência dela mudar à medida que o software
evolui. Dependendo da maneira como o código de automação de teste é projetado, isso pode
resultar em uma carga significativa de manutenção. Por exemplo, o uso do recurso de
captura/reprodução de uma ferramenta de automação de teste pode resultar em casos de teste
automatizados (geralmente chamados de scripts de teste) que não são mais executados como
desejado se a GUI for alterada. Isso ocorre porque o script gravado captura interações com os
objetos gráficos quando o testador executa o software manualmente. Se os objetos acessados
forem alterados, os scripts gravados também poderão precisar de atualização para refletir essas
alterações.
As ferramentas de captura/reprodução podem ser usadas como um ponto de partida conveniente
para o desenvolvimento de scripts de automação. O testador registra uma sessão de teste e o
script gravado é modificado para melhorar a capacidade de manutenção (p. ex., substituindo
partes do script gravado por funções reutilizáveis).
6.1.1.2 Aplicando uma abordagem orientada por dados
Dependendo do software que está sendo testado, os dados usados para cada teste podem ser
diferentes, embora as etapas de teste executadas sejam praticamente idênticas (p. ex., testando
o tratamento de erros para um campo de entrada inserindo vários valores inválidos e verificando
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 61 de 73
o erro retornado para cada). É ineficiente desenvolver e manter um script de teste automatizado
para cada um desses valores testados. Uma solução técnica comum para esse problema é mover
os dados dos scripts para um armazenamento externo, como uma planilha ou um banco de dados.
As funções são escritas para acessar os dados específicos de cada execução do script de teste, o
que permite que um único script trabalhe com um conjunto de dados de teste que forneça os
valores de entrada e os resultados esperados (p. ex., um valor mostrado em um campo de texto
ou um mensagem de erro). Essa abordagem é chamada orientada por dados.
Ao usar essa abordagem, além dos scripts de teste que processam os dados fornecidos, são
necessários um ambiente e uma infraestrutura para suportar a execução do script ou conjunto de
scripts. Os dados reais mantidos na planilha ou no banco de dados são criados por Analistas de
Teste que estão familiarizados com a função comercial do software. Em projetos ágeis, o
representante comercial (p. ex., dono do produto) também pode estar envolvido na definição dos
dados, em particular nos testes de aceite. Essa divisão do trabalho permite que os responsáveis
pelo desenvolvimento dos scripts de teste (p. ex., o Analista Técnico de Teste) se concentrem na
implementação de scripts de automação inteligente enquanto o Analista de Teste mantém a
propriedade no teste atual. Na maioria dos casos, o Analista de Teste será responsável pela
execução dos scripts de teste assim que a automação for implementada e testada.
6.1.1.3 Aplicando uma abordagem orientada por palavras-chave
A abordagem orientada por palavras-chave, vai além, separando a ação que será executada nos
dados fornecidos do script de teste [Buwalda01]. Para realizar essa separação adicional, é criada
uma meta linguagem de alto nível, que é descritiva e não diretamente executável. Cada instrução
dessa linguagem descreve um processo de negócios completo ou parcial do domínio que pode
exigir teste. Por exemplo, as palavras-chave do processo de negócios podem incluir "Login",
"CriarUsuário" e "RemoverUsuário". Uma palavra-chave descreve uma ação de alto nível que será
executada no domínio do aplicativo. As ações de nível inferior que denotam interação com a
própria interface do software, como: “ClicarBotão”, “SelecionarDaLista” ou “AbrirÁrvore” também
podem ser definidas e usadas para testar os recursos da GUI que não se encaixam perfeitamente
nas palavras-chave do processo de negócios.
Depois de definidas as palavras-chave e os dados utilizados, o automatizador de teste (p. ex.,
Analista Técnico de Teste ou Engenheiro de Automação de Teste) converte as palavras-chave do
processo de negócios e as ações de nível inferior em código automatizado de teste. As palavras-
chave e as ações, juntamente com os dados usados, podem ser armazenadas em planilhas ou
inseridas usando ferramentas específicas que suportam a automação de teste orientada por
palavras-chave. A estrutura de automação de teste implementa a palavra-chave como um
conjunto de uma ou mais funções executáveis ou scripts. As ferramentas leem os casos de teste
escritos com palavras-chave e chamam as funções ou scripts de teste apropriados que os
implementam. Os executáveis são implementados de uma maneira altamente modular para
permitir um mapeamento fácil de palavras-chave específicas. São necessárias habilidades de
programação para implementar esses scripts modulares.
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 62 de 73
Essa separação do conhecimento da lógica de negócios da programação real necessária para
implementar os scripts de automação de teste fornece o uso mais eficaz dos recursos de teste. O
Analista Técnico de Teste, na função de automatizador de teste, pode aplicar efetivamente as
habilidades de programação sem precisar se tornar um especialista no domínio em muitas áreas
da empresa.
Separar o código alterável dos dados ajuda a isolar a automação das alterações, melhorando a
capacidade de manutenção geral do código e melhorando o retorno do investimento em
automação.
6.1.1.4 Lidando com falhas de software
Em qualquer projeto de automação de teste, é importante antecipar e lidar com falhas de software.
Se ocorrer uma falha, o automatizador de teste deve determinar o que o software deve fazer. A
falha deve ser registrada e os testes continuam? Os testes devem ser encerrados? A falha pode
ser tratada com uma ação específica (como clicar em um botão em uma caixa de diálogo) ou talvez
adicionando um atraso no teste? Falhas de software não tratadas podem corromper os resultados
subsequentes do teste, além de causar problemas no teste que estava sendo executado quando
a falha ocorreu.
6.1.1.5 Considerando o estado do sistema
Também é importante considerar o estado do sistema no início e no final dos testes. Pode ser
necessário garantir que o sistema retorne a um estado predefinido após a conclusão da execução
do teste. Isso permitirá que um conjunto de teste automatizado seja executado repetidamente
sem intervenção manual para reposicionar o sistema em um estado conhecido. Para fazer isso, a
automação de teste pode ter que, por exemplo, excluir os dados criados ou alterar o status dos
registros em um banco de dados. A estrutura de automação deve garantir que uma finalização
adequada tenha sido realizada no final dos testes (ou seja, efetuando logout após o seu
encerramento).
6.1.2 Modelando processos de negócios para automação
Para implementar uma abordagem orientada por palavras-chave para automação de teste, os
processos de negócios testados devem ser modelados na linguagem de palavras-chave de alto
nível. É importante que a linguagem seja intuitiva para os usuários que provavelmente são os
Analistas de Teste trabalhando no projeto ou, no caso de projetos ágeis, o representante comercial
(p. ex., Dono do Produto).
Geralmente, as palavras-chave são usadas para representar interações comerciais de alto nível
com um sistema. Por exemplo, "Cancelar_Ordem" pode exigir a verificação da existência do pedido,
a verificação dos direitos de acesso da pessoa que solicita o cancelamento, a exibição do pedido a
ser cancelado e a confirmação do cancelamento. Sequências de palavras-chave (p. ex., "Login",
"Selecionar_Ordem", "Cancelar_Ordem") e os dados relevantes de teste são usados pelo Analista de
Teste para especificar os casos de teste. A seguir, é apresentada uma tabela de entrada simples
orientada por palavras-chave que pode ser usada para testar a capacidade do software de
adicionar, redefinir e excluir contas de usuário:
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 63 de 73
Palavras-chave Usuário Senha Resultado
Adicionar_Usuario User1 Verde Mensagem de usuário adicionado
Adicionar_Usuario @Rec34 @Rec35 Mensagem de usuário adicionado
Resetar_Senha User1 Vermelho Mensagem de confirmação de redefinição de senha
Remover_Usuario User1 Mensagem de usuário ou senha inválida
Adicionar_Usuario User3 Azul Mensagem de usuário adicionado
Remover_Usuario User2 Mensagem de usuário não encontrado
O script de automação que usa esta tabela procuraria os valores de entrada usados pelo script de
automação. Por exemplo, quando chega à linha com a palavra-chave "Remover_Usuario", apenas o
nome de usuário é necessário. Para adicionar um novo usuário, é necessário nome de usuário e
senha. Os valores de entrada também podem ser referenciados em um repositório de dados,
conforme mostrado com a segunda palavra-chave "Adicionar_Usuario", em que uma referência aos
dados é inserida, em vez dos próprios dados, fornecendo mais flexibilidade para acessar dados
que podem estar mudando à medida que os testes são executados. Isso permite que técnicas
orientadas a dados sejam combinadas com o esquema de palavras-chave.
Questões consideradas incluem o seguinte:
• Quanto mais granulares as palavras-chave, mais específicos os cenários que podem ser
abordados, mas a linguagem de alto nível pode se tornar mais complexo de manter;
• Permitir que os analistas de teste especifiquem ações de baixo nível ("ClicarBotão",
"SelecionarLista" etc.) torna os testes por palavras-chave muito mais capazes de lidar com
situações diferentes. No entanto, como essas ações estão vinculadas diretamente à GUI,
também pode fazer com que os testes exijam mais manutenção quando ocorrerem
alterações;
• O uso de palavras-chave agregadas pode simplificar o desenvolvimento, mas complicar a
manutenção. Por exemplo, pode haver seis palavras-chave diferentes que criam
coletivamente um registro. Uma palavra-chave que realmente chama todas as seis
palavras-chave consecutivamente deve ser criada para simplificar essa ação?
• Não importa quanta análise entre na linguagem das palavras-chave, haverá momentos em
que novas e diferentes palavras-chave serão necessárias. Existem dois domínios separados
para uma palavra-chave (ou seja, a lógica de negócios por trás dela e a funcionalidade de
automação para executá-la). Portanto, um processo deve ser criado para lidar com os dois
domínios.
A automação de testes orientada por palavras-chave pode reduzir significativamente os custos de
manutenção da automação, mas é mais onerosa, mais difícil de desenvolver e leva mais tempo
para ser projetada corretamente, a fim de obter o retorno esperado do investimento.
O syllabus CTAL-TAE Test Automation Engineer [ISTQB_AL_TAE] inclui mais detalhes sobre a
modelagem de processos de negócios para automação.
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 64 de 73
6.2 Ferramentas específicas de teste
Esse capítulo contém informações gerais sobre as ferramentas que provavelmente serão usadas
por um Analista Técnico de Teste além do discutido no plano de estudos do nível básico [ISTQB_FL].
Observe que informações detalhadas sobre ferramentas são fornecidas pelos seguintes
conteúdos programáticos do ISTQB®:
• CTFL-MAT Mobile Application Testing [ISTQB_FL_MAT]
• CTFL-PT Performance Testing [ISTQB_FL_PT]
• CTFL-MBT Model-Based Testing [ISTQB_FL_MBT]
• CTAL-TAE Test Automation Engineer [ISTQB_AL_TAE]
6.2.1 Ferramentas para plantar / injetar falhas
As ferramentas para plantar falhas realmente modificam o código em teste (possivelmente usando
algoritmos predefinidos) para verificar a cobertura obtida pelos testes especificados. Quando
aplicado de maneira sistemática, isso permite avaliar a qualidade dos testes (ou seja, sua
capacidade de detectar os defeitos inseridos) e, quando necessário, melhorar.
As ferramentas de injeção de falhas fornecem deliberadamente entradas incorretas ao software
para garantir que o software possa lidar com a falha. As entradas são injetadas para interromper
o fluxo normal de execução do código e permitir que a cobertura de teste seja estendida (p. ex.,
para cobrir condições de teste mais negativas e mecanismos de tratamento de erros de teste).
Esses dois tipos de ferramentas geralmente são usados pelo Analista Técnico de Teste, mas
também podem ser usados pelo desenvolvedor ao testar o código recém-desenvolvido.
6.2.2 Ferramentas de teste de performance
As ferramentas de teste de performance têm as seguintes funções principais:
• Gerar carga;
• Fornecer medição, monitoração, visualização e análise da resposta do sistema a uma
determinada carga;
• Fornecer percepções sobre o comportamento dos recursos dos componentes do sistema
e da rede.
A geração de carga é executada implementando um perfil operacional predefinido (consulte o
capítulo 4.5.3) como um script. O script pode ser capturado inicialmente para um único usuário
(possivelmente usando uma ferramenta de captura/reprodução) e é implementado para o perfil
operacional especificado usando a ferramenta de teste de performance. Essa implementação deve
levar em consideração a variação de dados por transação (ou conjuntos de transações).
As ferramentas de performance geram uma carga simulando um grande número de vários
usuários (usuários "virtuais") seguindo seus perfis operacionais designados para realizar tarefas,
incluindo a geração de volumes específicos de dados de entrada. Em comparação com os scripts
de automação de execução de teste individuais, muitos scripts de teste de performance
reproduzem a interação do usuário com o sistema no nível do protocolo de comunicações e não
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 65 de 73
simulando as interações do usuário por meio de uma interface gráfica. Isso geralmente reduz o
número necessário de "sessões" separadas durante o teste. Algumas ferramentas de geração de
carga também podem direcionar o aplicativo usando sua interface com o usuário para medir mais
de perto o tempo de resposta enquanto o sistema está sob carga.
Uma ampla gama de medições é realizada por uma ferramenta de teste de performance para
permitir a análise durante ou após a execução do teste. As métricas típicas obtidas e os relatórios
fornecidos incluem:
• Número de usuários simulados durante o teste;
• Número e tipos de transações geradas pelos usuários simulados e a taxa de chegada
dessas transações;
• Tempos de resposta a solicitações de transações específicas feitas pelos usuários;
• Relatórios e gráficos de carga em relação aos tempos de resposta;
• Relatórios sobre o uso de recursos (p. ex., uso ao longo do tempo com valores mínimos e
máximos);
Entre os fatores significativos considerados na implementação de ferramentas de teste de
performance podem ser incluídos:
• A largura da banda de hardware e rede necessária para gerar a carga;
• A compatibilidade da ferramenta com o protocolo de comunicação usado pelo sistema em
teste;
• A flexibilidade da ferramenta para permitir que diferentes perfis operacionais sejam
facilmente implementados;
• As instalações necessárias de monitoramento, análise e relatórios.
As ferramentas de teste de performance são normalmente adquiridas em vez de desenvolvidas
internamente devido ao esforço necessário para desenvolvê-las. Pode, no entanto, ser apropriado
desenvolver uma ferramenta de performance específica se restrições técnicas impedirem a
utilização de um produto disponível ou se o perfil de carga e as instalações fornecidas forem
relativamente simples. Detalhes adicionais sobre as ferramentas de teste de performance são
fornecidos no syllabus CTFL-PT Performance Testing [ISTQB_FL_PT].
6.2.3 Ferramentas para testes baseados na web
Uma variedade de ferramentas especializadas de código aberto e comerciais estão disponíveis
para testes na web. A lista a seguir mostra o objetivo de algumas dessas ferramentas:
• As ferramentas de teste de hiperlink são usadas para verificar e checar se nenhum hiperlink
quebrado ou ausente está presente em um site;
• Os verificadores de HTML e XML são ferramentas que examinam a conformidade com os
padrões HTML e XML das páginas criadas por um site;
• Simuladores de carga para testar como o servidor reagirá quando um elevado número de
usuários se conectar;
• Ferramentas leves de execução de automação que funcionam com diferentes navegadores;
• Ferramentas para verificar o servidor, checando arquivos órfãos (não vinculados);
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 66 de 73
• Verificadores ortográficos específicos para HTML;
• Ferramentas de verificação de arquivos CSS (Cascading Style Sheet);
• Ferramentas para verificar violações dos padrões, por exemplo, os padrões de
acessibilidade da Seção 508 nos EUA ou M/376 na Europa;
• Ferramentas que detectam uma variedade de problemas de segurança.
São boas fontes de ferramentas de teste da Web de código aberto:
• O World Wide Web Consortium (W3C) [Web-3] Esta organização define padrões para a
Internet e fornece uma variedade de ferramentas para verificar erros em relação a esses
padrões;
• O Web Hypertext Application Technology Working Group (WHATWG) [Web-5]. Esta organização
define padrões HTML. Eles possuem uma ferramenta que executa a validação HTML [Web-
6].
Algumas ferramentas que incluem um mecanismo webspider também podem fornecer
informações sobre o tamanho das páginas e o tempo necessário para baixá-las e se uma página
está presente ou não (p. ex., erro HTTP 404). Isso fornece informações úteis para o desenvolvedor,
o webmaster e o testador.
Os Analistas de Teste e os Analistas Técnicos de Teste usam essas ferramentas principalmente
durante os testes do sistema.
6.2.4 Ferramentas para suportar testes baseados em modelo
O Teste Baseado em Modelo (MBT) é uma técnica pela qual um modelo formal, como uma
máquina de estados finitos, é usado para descrever o comportamento pretendido no tempo de
execução de um sistema controlado por software. As ferramentas comerciais de MBT (consulte
[Utting07]) geralmente fornecem um mecanismo que permite ao usuário "executar" o modelo. Os
caminhos interessantes de execução podem ser salvos e usados como casos de teste. Outros
modelos executáveis, como a Rede de Petri (ou rede de transição) e Gráficos de Estado
(Statecharts), também oferecem suporte ao MBT.
Modelos (e ferramentas) de MBT podem ser usados para gerar grandes conjuntos de caminhos de
execução distintos. As ferramentas MBT também podem ajudar a reduzir o número muito grande
de caminhos possíveis que podem ser gerados em um modelo. O teste usando essas ferramentas
pode fornecer uma visão diferente do software a ser testado. Isso pode resultar na descoberta de
defeitos que podem ter sido perdidos pelo teste funcional.
Detalhes adicionais sobre ferramentas de teste baseadas em modelo são fornecidos no syllabus
CTFL-MBT Model-Based Testing [ISTQB_FL_MBT].
6.2.5 Ferramentas de teste e compilação de componentes
Embora as ferramentas de teste de componentes e automação de compilação sejam ferramentas
de desenvolvedor, em muitos casos, elas são usadas e mantidas por Analistas Técnicos de Teste,
especialmente no contexto do desenvolvimento ágil.
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 67 de 73
As ferramentas de teste de componentes geralmente são específicas da linguagem usada para
programar um módulo. Por exemplo, se Java foi usado como linguagem de programação, o JUnit
pode ser usado para automatizar o teste de unidade. Muitas outras linguagens têm suas próprias
ferramentas de teste especiais; esses são chamados coletivamente de estruturas xUnit. Essa
estrutura gera objetos de teste para cada classe criada, simplificando as tarefas que o
programador precisa executar ao automatizar o teste do componente.
As ferramentas de depuração facilitam o teste manual de componentes em um nível muito baixo,
permitindo que desenvolvedores e Analistas Técnicos de Teste alterem valores variáveis durante
a execução e percorram o código linha por linha durante o teste. As ferramentas de depuração
também são usadas para ajudar o desenvolvedor a isolar e identificar problemas no código
quando uma falha é relatada pela equipe de teste.
As ferramentas de automação de compilação geralmente permitem que uma nova compilação
seja acionada automaticamente sempre que um componente for alterado. Após a conclusão da
construção, outras ferramentas executam automaticamente os testes de componentes. Esse nível
de automação em torno do processo de construção é geralmente visto em um ambiente de
integração contínua.
Quando configurado corretamente, esse conjunto de ferramentas pode ter um efeito muito
positivo na qualidade das compilações lançadas no teste. Se uma alteração feita por um
programador introduzir defeitos de regressão na compilação, geralmente fará com que alguns dos
testes automatizados falhem, acionando uma investigação imediata sobre a causa das falhas antes
que a compilação seja liberada no ambiente de teste.
6.2.6 Ferramentas para suportar testes de aplicativos móveis
Emuladores e simuladores são ferramentas frequentemente usadas para suportar o teste de
aplicativos móveis.
Simuladores
Um simulador móvel modela o ambiente de tempo de execução da plataforma móvel. Os
aplicativos testados em um simulador são compilados em uma versão dedicada, que funciona no
simulador, mas não em um dispositivo real. Às vezes, os simuladores são usados como substitutos
para dispositivos reais em testes. No entanto, o aplicativo testado em um simulador difere do
aplicativo que será distribuído.
Emuladores
Um emulador móvel modela o hardware e utiliza o mesmo ambiente de tempo de execução que
o hardware físico. Aplicativos compilados implantados e testados em um emulador também
podem ser usados pelo dispositivo real.
Os emuladores são frequentemente usados para reduzir o custo dos ambientes de teste,
substituindo dispositivos reais. No entanto, um emulador não pode substituir completamente um
dispositivo porque o emulador pode se comportar de maneira diferente do dispositivo móvel que
ele tenta imitar. Além disso, alguns recursos podem não ser suportados, como (multi) touch,
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 68 de 73
acelerômetro e outros. Isso é parcialmente causado por limitações da plataforma usada para
executar o emulador.
Aspectos comuns
Simuladores e emuladores são úteis no estágio inicial de desenvolvimento, pois normalmente se
integram aos ambientes de desenvolvimento e permitem rápida implantação, teste e
monitoramento de aplicativos. O uso de um emulador ou simulador exige iniciá-lo, instalar o
aplicativo necessário e testá-lo como se estivesse no dispositivo real. Cada ambiente de
desenvolvimento de sistema operacional móvel geralmente vem com seu próprio emulador e
simulador. Emuladores e simuladores de terceiros também estão disponíveis.
Geralmente emuladores e simuladores permitem a configuração de vários parâmetros de uso.
Essas configurações podem incluir emulação de rede em diferentes velocidades, força do sinal e
perda de pacotes, alteração da orientação, geração de interrupções e dados de localização do GPS.
Algumas dessas configurações podem ser muito úteis, pois podem ser difíceis ou caras de replicar
com dispositivos reais, como posições globais do GPS ou pontos fortes de sinal.
O syllabus CTFL-MAT Mobile Application Testing [ISTQB_FL_MAT] inclui mais detalhes.
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 69 de 73
Referências
Normas e Padrões
As seguintes normas são mencionadas nestes respectivos capítulos.
[RTCA DO-178C/ED-12C]
Software Considerations in Airborne Systems and Equipment Certification, RTCA/EUROCAE ED12C. 2013,
Capítulo 2
[ISO9126]
ISO/IEC 9126-1:2001, Software Engineering – Software Product Quality, Capítulo 4
[ISO25010]
ISO/IEC 25010 (2014) Systems and software engineering – Systems and software Quality Requirements and
Evaluation (SQuaRE) System and software quality models, Capítulos 2 e 4
[ISO29119]
ISO/IEC/IEEE 29119-4 International Standard for Software and Systems Engineering - Software Testing Part
4: Test techniques. 2015, Capítulo 2
[ISO42010]
ISO/IEC/IEEE 42010:2011 Systems and software engineering - Architecture description, Capítulo 5
[IEC61508]
IEC 61508-5 (2010) Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related
Systems, Part 5: Examples of methods for the determination of safety integrity levels, Capítulo 2
Documentos ISTQB®
[ISTQB_FL]
ISTQB® CTFL Foundation Level, 2018br, https://www.bstqb.org.br/sobre-ctfl
[ISTQB_FL_AT]
ISTQB® CTFL-AT Agile Tester, 2014br, https://www.bstqb.org.br/sobre-ctfl-at
[ISTQB_FL_UT]
ISTQB® CTFL-UT Usability Testing, 2018br, https://www.bstqb.org.br/sobre-ctfl-ut
[ISTQB_FL_PT]
ISTQB® CTFL-PT Performance Testing, 2018br, https://www.bstqb.org.br/sobre-ctfl-pt
[ISTQB_FL_MAT]
ISTQB® CTFL-MAT Mobile Application Testing, 2019br, https://www.bstqb.org.br/sobre-ctfl-mat
[ISTQB_FL_MBT]
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 70 de 73
ISTQB® CTFL-MBT Model-Based Testing, 2015br, https://www.bstqb.org.br/sobre-ctfl-mbt
[ISTQB_AL_OVIEW]
ISTQB® Advanced Level Overview, 2019br
[ISTQB_AL_TA]
ISTQB® CTAL-TA Test Analyst,2019br, https://www.bstqb.org.br/sobre-ctal-ta
[ISTQB_AL_TM]
ISTQB® CTAL-TM Test Manager, 2012br, https://www.bstqb.org.br/sobre-ctal-tm
[ISTQB_AL_SEC]
ISTQB® CTAL-SEC Security Testing, 2016br, https://www.bstqb.org.br/sobre-ctal-sec
[ISTQB_AL_TAE]
ISTQB® CTAL-TAE Test Automation Engineer, 2017br, https://www.bstqb.org.br/sobre-ctal-tae
[ISTQB_GLOSSARY]
ISTQB® Glossary of Terms used in Software Testing, v3.2, 2019br, https://glossary.istqb.org
Literatura
[Bass03]
Len Bass, Paul Clements, Rick Kazman “Software Architecture in Practice (2nd edition)”, Addison-Wesley 2003,
ISBN 0-321-15495-9
[Bath14]
Graham Bath, Judy McKay, “The Software Test Engineer’s Handbook (2nd edition)”, Rocky Nook, 2014, ISBN
978-1-933952-24-6
[Beizer90]
Boris Beizer, "Software Testing Techniques Second Edition", International Thomson Computer Press, 1990,
ISBN 1-8503-2880-3
[Beizer95]
Boris Beizer, “Black-box Testing”, John Wiley & Sons, 1995, ISBN 0-471-12094-4
[Burns18]
Brendan Burns, “Designing Distributed Systems: Patterns and Paradigms for Scalable, Reliable Services”,
O’Reilly, 2018, ISBN 13: 978-1491983645
[Buwalda01]
Hans Buwalda, “Integrated Test Design and Automation”, Addison-Wesley Longman, 2001, ISBN 0-201-
73725-6
[Copeland03]
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 71 de 73
Lee Copeland, “A Practitioner's Guide to Software Test Design”, Artech House, 2003, ISBN 1-58053-791-X
[Gamma94]
Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994, ISBN 0-201-63361-
2
[Jorgensen07]
Paul C. Jorgensen, “Software Testing, a Craftsman’s Approach third edition”, CRC press, 2007, ISBN-13:978-0-
8493-7475-3
[Kaner02]
Cem Kaner, James Bach, Bret Pettichord; “Lessons Learned in Software Testing”; Wiley, 2002, ISBN: 0-471-
08112-4
[Koomen06]
Tim Koomen, Leo van der Aalst, Bart Broekman, Michael Vroon, "TMap Next for resultdriven testing"; UTN
Publishers, 2006, ISBN: 90-72194-79-9
[McCabe76]
Thomas J. McCabe, "A Complexity Measure", IEEE Transactions on Software Engineering, Vol. SE-2, No. 4,
December 1976. PP 308-320
[McCabe96]
Arthur H. Watson and Thomas J. McCabe. "Structured Testing: A Testing Methodology Using the Cyclomatic
Complexity Metric" (PDF), 1996, NIST Special Publication 500-235.
[NIST96]
Arthur H. Watson and Thomas J. McCabe, "Structured Testing: A Testing Methodology Using the Cyclomatic
Complexity Metric", NIST Special Publication 500-235, Prepared under NIST Contract 43NANB517266,
September 1996.
[Splaine01]
Steven Splaine, Stefan P. Jaskiel, “The Web-Testing Handbook”, STQE Publishing, 2001, ISBN 0-970-43630-0
[Utting07]
Mark Utting, Bruno Legeard, “Practical Model-Based Testing: A Tools Approach”, MorganKaufmann, 2007,
ISBN: 978-0-12-372501-1
[Whittaker04]
James Whittaker and Herbert Thompson, “How to Break Software Security”, Pearson / Addison-Wesley, 2004,
ISBN 0-321-19433-0
[Wiegers02]
Karl Wiegers, "Peer Reviews in Software: A Practical Guide", Addison-Wesley, 2002, ISBN 0-201-73485-0
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 72 de 73
Outras referências
As seguintes referências apontam para informações disponíveis na Internet. Mesmo que estas referências
tenham sido verificadas no momento da publicação desse syllbus, o ISTQB® não pode ser responsabilizado
se elas não estiverem mais disponíveis.
[Web-1]
http://www.nist.gov NIST National Institute of Standards and Technology - Capítulo 4
[Web-2]
http://www.codeproject.com/KB/architecture/SWArchitectureReview.aspx - Capítulo 5
[Web-3]
http://www.W3C.org - Capítulo 6
[Web-4]
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project - Capítulo 4
[Web-5]
https://whatwg.org - Capítulo 6
[Web-6]
https://whatwg.org/validator/ - Capítulo 6
ISTQB® Advanced Level Syllabus
CTAL Technical Tester Analyst
Versão 2019br Página 73 de 73
Apêndice A: Visão geral das características de qualidade
A tabela seguinte compara as características de qualidade descritas na ISO 9126 (usada no syllabus
CTAL-TTA versão 2012br) com as da versão mais recente [ISO25010] (usada no syllabus CTAL-TTA
versão 2019br). São mostradas apenas as características relevantes para o Analista Técnico de
Teste.
ISO/IEC 25010 ISO/IEC 9126-1 Notas
Eficiência de Performance Eficiência
Comportamento temporal Comportamento temporal
Utilização de recurso Utilização de recurso
Capacidade Nova subcaracterística
Compatibillidade Nova característica
Coexistência Coexistência Movido da Portability
Interoperabilidade Movido da Functionality (Test Analyst)
Confiabilidade Confiabilidade
Maturidade Maturidade
Disponibilidade Nova subcaracterística
Tolerância a falha Tolerância a falha
Recuperabilidade Recuperabilidade
Segurança Segurança Não havia subcaracterísticas
Confidencialidade Nova subcaracterística
Integridade Nova subcaracterística
Não rejeição Nova subcaracterística
Contabilização Nova subcaracterística
Autenticidade Nova subcaracterística
Manutenibilidade Manutenibilidade
Modularidade Nova subcaracterística
Reusabilidade Nova subcaracterística
Analisabilidade Analisabilidade
Modificável Estabilidade Combina Modificabilidade e Estabilidade
Modificabilidade
Testabilidade Testabilidade
Portabilidade Portabilidade
Adaptabilidade Adaptabilidade
Instalabilidade Instalabilidade
Coexistência Movido para Compatibilidade
Substituibilidade Substituibilidade
Conformidade Removida da 25010
top related