apostila (2)
57 pág.

apostila (2)


DisciplinaEx Metologia Cientifica39 materiais199 seguidores
Pré-visualização18 páginas
coleta e gerencia os dados de 
teste e avalia o resultado de cada ciclo de testes. 
Fonte: BSTQB (Brazilian Software Testing Quali-
fications Board)
Regressão
Na Psicologia, a regressão faz o paciente voltar ao pas-
sado avaliando acontecimentos e aprendendo com os er-
ros ou acertos obtidos. Pois bem, no método de Regres-
são em testes de softwares vamos encontrar o objetivo 
de avaliar todas as experiências em testes do passado, e 
a cada nova versão disponibilizada executam-se os testes 
já realizados anteriormente e que apresentaram sucesso.
Pressman (2010) afirma que como o método atua de 
modo a confirmar a eficiência já obtida em testes realiza-
dos em versões anteriores, este tipo de teste é mais rápi-
do. Muito embora não seja um método infalível, em vir-
tude de mudanças impactantes que possam ter ocorrido 
no desenvolvimento de uma nova versão, demonstra ser 
relativamente prático e eficiente. Quando a aplicação é 
crítica, o testador pode sugerir um novo desenvolvimento 
e não apenas uma atualização. 
Testes de Software
13
Outros Tipos de Testes
\u2022 Caixa Cinza: uma combinação entre teste caixa 
preta e teste caixa branca. Consiste em analisar a 
parte lógica mais a funcionalidade do sistema, com-
parando o que foi realizado com as especificações 
previamente estabelecidas. De acordo com Lewis e 
Veerapillai (2005), o testador, neste método, comu-
nica-se com o desenvolvedor para em comum acor-
do entender e otimizar o sistema. Esta técnica pode 
incluir também o uso de engenharia reversa para 
determinar por exemplo, os limites superiores e in-
feriores das classes, além de mensagens de erro.
\u2022 Teste ad hoc: teste realizado informalmente. Não 
ocorre preparação formal, não são usadas técnicas 
reconhecidas de projeto de teste, não há expectati-
va para resultados e a arbitrariedade guia a ativida-
de da execução do teste.
\u2022 Teste ágil: prática de teste para projetos que usam 
metodologias ágeis, como por exemplo, o Extreme 
Programming (XP), que trata o desenvolvimento 
como cliente do teste e enfatiza o paradigma de 
testar antes. 
Caro aluno, o anexo 1 traz diversos outros tipos de tes-
tes existentes no mercado. Confira!
Leia mais no artigo da revista Engenharia de Software - 
Introdução à Teste de Software 
Disponível em: http://www.devmedia.com.br/artigo-
-engenharia-de-software-introducao-a-teste-de-softwa-
re/8035#ixzz27Pk4sNNA
Testes de Software
14
Prezado aluno, neste ponto, proponho que faça um exercício simples para que possa 
perceber que para se identificar erros, mesmo em um quadro simples, requer certa con-
centração e disposição. Se isto ocorre com uma simples imagem duplicada com alguns 
erros, imagine um software com milhares de linhas de código.
Testes de Software
15
Exercícios do Capítulo 1 
1 \u2013 Testes são divididos em tipos de testes distintos principalmente porque:
a) Cada estágio de teste tem um propósito diferente.
b) Podem ser executados testes diferentes em ambientes diferentes.
c) É mais fácil lidar com testes em estágios.
d) Quanto mais estágios, melhor o teste.
e) Ainda não foram desenvolvidos tipos específicos para alguns processos de desenvolvimento.
2 \u2013 Um importante benefício de inspeção de códigos é:
a) É barato.
b) Permite que o código seja testado antes que o ambiente de execução esteja pronto.
c) Pode ser feita pelo desenvolvedor somente.
d) Ajuda a confirmar a capacidade de desenvolvimento.
e) Colabora com a rentabilidade do projeto.
3 \u2013 Uma falha:
a) Ocorre quando há uma instrução ou comando incorreto.
b) É um desvio de especificação.
c) É um comportamento inconsistente.
d) É uma informação inadequada fornecida.
e) Nenhuma das anteriores.
4 \u2013 O teste tipo caixa cinza, se refere a:
a) Um tipo de teste efetuado com os componentes físicos.
b) Um teste de ação retardada, em que o resultado só aparece a médio ou longo prazo.
c) Uma referencia a um teste ineficiente.
d) Uma combinação entre teste caixa preta e teste caixa branca.
e) Um teste de integridade.
5 \u2013 Este teste possui critérios baseados em Fluxo de Controle e em Fluxo de Dados, portanto avalia a parte estrutural 
do software.
a) Teste caixa preta.
b) Teste caixa cinza.
c) Teste ad hoc.
d) Teste ágil.
e) Teste caixa branca.
Testes de Software
16
Automação de Testes
Importância dos Testes de Software
Caro aluno considere novamente a analogia que fize-
mos sobre os recalls que montadoras eventualmente fa-
zem.
Seria correto afirmarmos que, se uma montadora ad-
mite em um recall uma falha em seu carro ou projeto, ela 
deva ser considerada incompetente ou seu produto ser 
um péssimo negócio para seus clientes?
Com certeza nos sentiremos traídos se uma falha for 
detectada e escondida para supostamente não denegrir 
a imagem da empresa. Na verdade esta imagem certa-
mente se denegriria se a empresa não tomasse a atitude 
de admitir o erro, assumir a responsabilidade e corrigir a 
falha detectada.
Então, podemos concluir apropriadamente que encon-
trar um erro, uma falha ou mesmo um defeito em um sof-
tware desenvolvido, não vai necessariamente expor uma 
incompetência. Na verdade, como já dissemos, estranha-
ríamos muito se não fosse encontrado qualquer proble-
ma em um software complexo. Não somos infalíveis, por 
melhores profissionais que sejamos. Isto é importante 
compreender e admitir, tanto o desenvolvedor como o 
testador.
Testes automatizados podem fazer a diferença no que 
diz respeito à confiança que um software desenvolvido 
pode alcançar. Como qualquer artefato, o código fonte 
dos testes automatizados e os documentos gerados re-
querem qualidade. À medida que se aumenta a comple-
xidade do software, os testes automatizados aumentam 
sua abrangência também. 
Segundo Pressman (2010), o teste frequente respon-
de por mais esforço de projeto do que qualquer outra 
atividade de engenharia de software. Se é conduzido ao 
acaso, tempo é desperdiçado, esforço desnecessário é 
despendido e, ainda pior, erros se infiltram sem serem 
descobertos. Assim, seria razoável estabelecer uma estra-
tégia sistêmica para o teste de software. 
A figura 5 mostra 2 imagens que apresentam a distri-
buição de defeitos de software e o esforço de retrabalho 
para sua correção e o custo para se corrigir defeitos inse-
ridos na fase de análise de requisitos e detectados poste-
riormente.
Testes de Software
17
Figura 5 \u2013 Origem dos defeitos, esforço de retrabalho e custo de correção
Fonte: http://tmtestes.com.br/conteudo/show/id/113
Testes de Software
18
Voltando à analogia do recall, entendemos que admi-
tir falhas, erros ou defeitos e corrigi-los, contribui para 
a manutenção da existência de grandes montadoras. Da 
mesma forma, identificar e corrigir falhas, erros e defeitos 
em um software, contribuirá para a manutenção da exis-
tência de um software desenvolvido. 
Ciclo de Vida de Testes de Software
Segundo Pressman (2010), o teste e a depuração, são 
atividades diferentes, mas a depuração deve ser acomo-
dada em qualquer estratégia de teste.
Conforme abordado na seção 1.4. Estratégias de Teste, 
temos vários estágios na definição da estratégia de testes, 
no entanto, se considerarmos o seu ciclo de vida ficará 
mais claro o entendimento e a importância da elaboração 
de estratégias para a implementação de testes.
Uma estratégia de teste deve acomodar testes de bai-
xo nível, que atuam na identificação de problemas em um 
pequeno segmento do código fonte e testes de alto nível, 
que validam as principais funções do sistema levando em 
consideração os requisitos do cliente. Uma estratégia for-
nece diretrizes aos profissionais e um conjunto de refe-
rências para o gestor. 
Na analogia anterior, nos referimos a admitir