certified tester...istqb® advanced level syllabus ctal technical tester analyst versão 2019br...

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




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




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




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




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




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.




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




• 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;




• 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)




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.




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).




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;




• 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].




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


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.




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.




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).


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.




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.


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




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).


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.




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.


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




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.


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




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)




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.




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


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.




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.




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




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;




• 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.




• 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;




• 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.




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




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].




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


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


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.


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.




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.




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




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.




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.




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;




• 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).




• 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;




• 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;




• 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".




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).




• 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.




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.




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




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,




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:




• 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;




• 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);




• 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




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.




5 Revisões [165 min]

Conceitos-chave

anti-padrão


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.




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;




• 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;




• 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?




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?




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.


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.




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.




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




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.




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:




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.




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




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);




• 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.




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,




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.




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® 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]

http://www.sei.cmu.edu/library/abstracts/books/0321154959.cfm

http://www.sei.cmu.edu/library/abstracts/books/0321154959.cfm




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

http://www.mccabe.com/pdf/mccabe-nist235r.pdf




http://www.amazon.com/gp/redirect.html?link_code=ur2&tag=markuttinsweb-20&camp=1789&creative=9325&location=%2FPractical-Model-Based-Testing-Tools-Approach%2Fdp%2F0123725011%2Fsr%3D1-1%2Fqid%3D1157585827%2Fref%3Dsr_1_1%3Fie%3DUTF8%26s%3Dbooks








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

http://www.nist.gov/

http://www.codeproject.com/KB/architecture/SWArchitectureReview.aspx

http://www.w3c.org/

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

%20

https://whatwg.org/validator/




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

certified tester...istqb® advanced level syllabus ctal technical tester analyst versão 2019br...

Documents