apostila (2)
57 pág.

apostila (2)


DisciplinaEx Metologia Cientifica39 materiais198 seguidores
Pré-visualização18 páginas
consegue-se encontrar possíveis 
falhas no resultado apresentado em consequência 
do mal funcionamento ou erro de algum dos com-
ponentes.
\u2022 Teste de validação: avalia o software em um am-
biente específico, considerando os requisitos defi-
nidos pelo cliente em uma situação próxima à rea-
lidade. Tem como objetivo provar ao cliente que o 
software atende as solicitações desejadas.
\u2022 Teste de sistema: este teste tenta impor a visão 
do cliente, dando normalmente uma perspectiva 
diferente ao testador. Normalmente executa-se em 
um ambiente que se assemelha ao ideal. Seu obje-
tivo é por o sistema desenvolvido completamente 
à prova, com todos os elementos adequadamente 
integrados e realizando suas funções corretamen-
te. Em testes de sistemas encontramos pelo menos 
4 tipos de testes:
o Teste de Recuperação: este procedimen-
to avalia a recuperação de uma falha dentro 
de um tempo especificado em caso de falha. 
Neste teste, podem ocorrem várias falhas 
forçadas para verificar a recuperação.
Figura 3 - Espiral de Estratégia de Testes
Testes de Software
10
o Teste de Segurança: neste caso o testa-
dor tenta penetrar no sistema provocando 
ações que prejudiquem alguém. Ele usa for-
mas ilegais ou impróprias simulando condi-
ções extremas de violação das informações.
o Teste de Estresse: este procedimento 
cria ambientes extremos para utilização do 
software. Volumes anormais e frequência ir-
regular têm como objetivo forçar falhas por 
sobrecarga, verificando as possíveis interrup-
ções e consequências de paradas anormais 
por estresse. Os dados, então, são avaliados 
para ver se não forram corrompidos ou per-
didos.
o Teste de Desempenho: todo sistema de-
senvolvido tem em suas especificação de 
requisitos o desempenho adequado de fun-
cionamento e após a integração dos compo-
nentes uma avaliação é indispensável para se 
obter o seu desempenho real.
De acordo com Pressman (2010), do ponto de vista 
procedimental, o teste no contexto da Engenharia de Sof-
tware é uma série de 4 passos que são implementados 
sequencialmente, conforme mostra a figura 4. 
Figura 4 - Passos de Teste de Software
Testes de Software
11
Inicialmente o teste focaliza cada componente indivi-
dualmente, garantindo que ele funcione adequadamente 
como uma unidade. Em seguida os componentes devem 
ser montados ou integrados para formar um pacote de 
software completo. Depois que o software tiver sido in-
tegrado um conjunto de testes de alto nível é conduzido, 
de forma que critérios de validação de requisitos sejam 
avaliados. O último passo avança para fora dos limites da 
Engenharia de Software indo em direção ao sistema de 
computação. O teste de sistema verifica se todos os ele-
mentos estão ajustados de forma que a função e o de-
sempenho global do sistema sejam alcançados.
Técnicas de Teste
Caro aluno, se testar é determinar se o objetivo está 
sendo alcançado, precisamos obrigatoriamente conhecer 
as técnicas envolvidas. Várias técnicas já existem e outras 
estão sendo criadas ou aperfeiçoadas de acordo com a 
necessidade que surge.
Em Engenharia de Software encontramos algumas téc-
nicas básicas que atualmente estão em prática no merca-
do e que é importante conhecermos, pois poderão servir 
de referência para o desenvolvimento ou aprimoramento 
de técnicas, são elas:
\u2022 Caixa Branca
\u2022 Caixa Preta
\u2022 Regressão 
Consideremos mais detalhadamente estas técnicas 
nas seções a seguir.
Caixa Branca ou Caixa de Vidro
O teste Caixa Branca possui critérios baseados em 
Fluxo de Controle e em Fluxo de Dados, portanto avalia 
a parte estrutural do software. Aplicamos esta prática di-
retamente no código do programa, fazendo teste lógico e 
comportamental. Analisam-se o fluxo de dados e os códi-
gos, usados ou não. 
De acordo com Myers (2004), a técnica de teste de cai-
xa branca é conhecida por vários nomes tais como teste 
estrutural e teste de caixa de vidro. O engenheiro de sis-
tema realiza o teste direto no código fonte do software. 
São determinados os dados de entrada para analisar a ló-
gica do software. Lewis e Veerapillai (2005) afirmam que 
a desvantagem desta técnica está no fato de que não se 
analisa a especificação, concentrando apenas no código 
fonte e não se verifica a lógica da especificação.
Segundo Pressman (2010) os principais testes de Caixa 
Branca são:
\u2022 Teste de caminho básico: determina o conjunto 
básico de caminhos para a execução dos testes. 
\u2022 Teste de Condição: todas as condições lógicas 
contidas no código são testadas e avaliadas. É co-
mum se deparar com erros de lógica booleana, erro 
de operadores e de expressões aritméticas.
\u2022 Teste de fluxo de dados: localiza as variáveis do 
programa e verifica suas definições. Esta técnica é 
mais complexa que as outras, portanto exige maior 
competência na implantação.
\u2022 Teste de Laços: em todos os laços definidos no 
programa ocorrerá alguma validação.
Caixa Preta
O nome Caixa Preta (Black Box) vem do sentido de 
que nesse tipo de teste não é necessário saber a estru-
tura interna, bem como o código ou a tecnologia que foi 
utilizada. Nesse tipo de análise essas questões são trans-
parentes para os analistas de teste. Para que se crie um 
projeto de teste bem sucedido é necessário usar a técnica 
de caixa preta junto com o de caixa branca, isto é, deve-se 
analisar, também, a estrutura interna da aplicação.
De acordo com Myers (2004) esta técnica avalia o sof-
tware conforme as entradas e saídas. Aplica-se externa-
mente no software sem considerar o funcionamento in-
terno do mesmo. Os dados de entrada são fornecidos ao 
Testes de Software
12
sistema que os processa e devolve uma saída previamen-
te conhecida pelo testador. Os resultados são compara-
dos para validar a efetividade da funcionalidade testada. 
Este tipo de técnica é baseada na especificação funcional 
e é recomendada para todas as fases de teste, unitário, 
integração, sistema e aceitação.
Este tipo de teste é particularmente útil para revelar 
problemas, tais como:
 9 funções incorretas ou omitidas;
 9 erros de interface;
 9 erros de comportamento ou desempenho e
 9 erros de iniciação e término.
As maratonas de programação geralmente utilizam o teste 
de caixa preta. Os participantes recebem uma especifica-
ção do software a ser desenvolvido e pontuam quando o 
programa entregue passa pelos testes produzindo as saídas 
esperadas de acordo com as entradas dadas. 
Veja:
http://www.youtube.com/watch?v=7TrldtG_wWI
Segundo Lewis e Veerapillai (2005), e complementado 
por Pressman (2010), os principais testes de caixa preta 
são:
\u2022 Particionamento de equivalência: o programa é 
dividido em classes, que são testadas com o obje-
tivo de eliminar redundâncias ou de se descobrir 
classes com erros.
\u2022 Análise de valor limite: nos limites é que encon-
tramos a maior parte dos erros, então o testador 
extrapola os valores suportados pelo sistema para 
forçar uma situação extrema com o objetivo claro 
de encontrar erros.
\u2022 Técnicas de grafo de causa-efeito: servem para 
oferecer uma representação concisa das condições 
lógicas e respectivas ações. A técnica compreende 
4 passos:
1. causas (condições de entrada) e efeitos 
(ações) são relacionados em um módulo e 
atribui-se um identificador para cada;
2. um grafo de causa e efeito é desenvolvi-
do;
3. o grafo é convertido em uma tabela de 
decisão;
4. as regras e tabelas de decisão são conver-
tidas em casos de testes.
Analista de Teste, Analista de Design ou Testador 
(Tester) são nomes utilizados para o profissional 
que identifica os itens de teste-alvo a serem 
avaliados pelo esforço de teste, define os testes 
apropriados necessários e quaisquer dados de 
teste associados,