Importância do Teste de Software

Prévia do material em texto

Importância do teste de software 
Motivação: Software com falhas resulta em prejuízos e riscos. Rigorosos testes em sistemas e 
documentações pode reduzir os riscos de ocorrência de problemas no ambiente operacional, e 
contribui para a qualidade dos sistemas do software se os defeitos encontrados forem 
corrigidos antes de implantados em produção. Diversos fatores podem ser identificados como 
causa de tais problemas. Segundo Delamaro et al. um engano (mistake) humano produz um 
defeito (fault), a existencia de um defeito pode ocasionar a ocorrência de um erro (error) 
durante uma execução do programa que se caracteriza por um estado incosistente ou 
inesperado de uma determinada funcionalidade produzindo a falha (failure). 
Definição de teste de software: O teste do software é a investigação do software a fim de 
fornecer informações sobre sua qualidade em relação ao contexto em que ele deve operar. 
Isso inclui o processo de utilizar o produto para encontrar seus defeitos. O teste é um processo 
realizado pelo testador de software, que permeia outros processos da engenharia de software, 
e que envolve ações que vão do levantamento de requisitos até a execução do teste 
propriamente dito. 
Testes de software: 
Caixa-Branca: Também chamado de teste estrutural ou orientado à lógica, a técnica de caixa-
branca avalia o comportamento interno do componente de software. Essa técnica trabalha 
diretamente sobre o código fonte do componente de software para avaliar aspectos tais como: 
teste de condição, teste de fluxo de dados, teste de ciclos, teste de caminhos lógicos, códigos 
nunca executados. Este tipo de teste é desenvolvido analisando o código fonte e elaborando 
casos de teste que cubram todas as possibilidades do componente de software. Dessa 
maneira, todas as variações relevantes originadas por estruturas de condições são testadas. A 
técnica de teste de caixa-branca é recomendada para as fases de teste de unidade e teste de 
integração, cuja responsabilidade principal fica a cargo dos desenvolvedores do software, que 
por sua vez conhecem bem o código fonte produzido. 
Caixa-preta: Também chamada de teste funcional, orientado a dado ou orientado a entrada e 
saída, a técnica de caixa-preta avalia o comportamento externo do componente de software, 
sem se considerar o comportamento interno do mesmo. Dados de entrada são fornecidos, o 
teste é executado e o resultado obtido é comparado a um resultado esperado previamente 
conhecido. Quanto mais entradas são fornecidas, mais rico será o teste. Essa técnica é 
aplicável a todas as fases de teste – teste unitário, teste de integração, teste de sistema e teste 
de aceitação. 
Testes de Unidade: Conhecido como teste de unidade ou teste de módulo. É a fase em que se 
testam as menores unidades de software desenvolvidas (pequenas partes ou unidades do 
sistema). Testar pequenos trechos de código. Assim, o objetivo é o de encontrar falhas de 
funcionamento dentro de uma pequena parte do sistema funcionando independentemente do 
todo. 
Teste de sistema: Na fase de teste de sistema, o objetivo é executar o sistema sob ponto de 
vista de seu usuário final, varrendo as funcionalidades em busca de falhas em relação aos 
objetivos originais. 
Teste de aceitação: Geralmente, os testes de aceitação são realizados por um grupo restrito 
de usuários finais do sistema, que simulam operações de rotina do sistema de modo a verificar 
se seu comportamento está de acordo com o solicitado. Validação de um software pelo 
comprador, pelo usuário ou por terceira parte, com o uso de dados ou cenários especificados 
ou reais. Pode incluir testes funcionais, de configuração, de recuperação de falhas, de 
segurança e de desempenho. 
Teste de operação: Nessa fase o teste é conduzido pelos administradores do ambiente final 
em que o sistema ou software entrará em ambiente produtivo. Envolve testes de instalação, 
simulações com cópia de segurança dos bancos de dados, etc. 
Teste Alfa e Beta: PRESSMAN afirma que o teste alfa é conduzido pelo cliente no ambiente do 
desenvolvedor, com este "olhando sobre o ombro" do usuário e registrando erros e problemas 
de uso. PRESSMAN afirma que o teste beta é conduzido em uma ou mais instalações do 
cliente, pelo usuário final do software. Diferente do teste alfa, o desenvolvedor geralmente 
não está presente. Consequentemente, o teste beta é uma aplicação do software num 
ambiente que não pode ser controlado pelo desenvolvedor. 
RTF – Revisões Técnicas Formais 
Uma RTF concentra-se numa parte específica do software global. Em vez de tentar revisar todo 
o projeto, RTF são levadas a efeito para cada módulo ou pequeno grupo de módulos. Com isso, 
a RTF tem uma probabilidade maior de revelar erros. 
Diretrizes da RTF 
• Revise o produto, não o produtor; 
• Fixe e mantenha uma agenda; 
• Limite o debate e a refutação; 
• Enuncie as áreas problemáticas, mas não tente resolver cada problema anotado; 
• Limite o número de participantes e insista numa preparação antecipada; 
• Desenvolva uma lista de conferência (checklist) para cada produto que provavelmente 
será revisto; 
• Atribua recursos e uma programação de tempo para as RTF’s. 
 
Depuração 
 
Depuração não é teste! Mas sempre ocorre como uma conseqüência do teste. 
O processo de depuração inicia-se com a execução de um caso de teste. Os resultados são 
avaliados, e qualquer falta de correspondência entre o resultado esperado e o real é 
encontrada. 
O processo de depuração tenta ligar o sintoma à causa, levando assim à correção do erro. 
Portanto, a depuração sempre terá um dentre dois resultados: 
• A causa será encontrada, corrigida e removida; 
• A causa não será descoberta. 
Independente da abordagem que se considera, a depuração tem um objetivo primordial: 
descobrir e corrigir a causa de um erro de software. 
 
 
Em geral, três categorias de abordagens à depuração podem ser propostas: 
• Força bruta - "deixe que o computador descubra o erro"; 
• Backtracking - o código fonte é rastreado para trás no local em que o 
sintoma foi descoberto; 
• Eliminação da causa - os dados relacionados à ocorrência de erros são 
organizados para isolar causas em potencial. 
 
Revisões Técnicas Formais 
 
 Objetivos: 
 
1) Descobrir erros de função, lógica ou implementação em qualquer 
representação do software. 
2) Verificar se o software que se encontra em revisão atende a seus requisitos 
3) Garantir que o software tenha sido representado de acordo com padrões pré-
definidos 
4) Obter um software que seja desenvolvido uniformemente 
5) Tornar os projetos mais administráveis 
 
 
 
 
Além disso: 
 
- espaço de treinamento possibilitando que os engenheiros juniores observem 
diferentes abordagens a análise, projeto e implementação de software 
 
 - promove backup e continuidade. Várias pessoas se familiarizam com partes do 
software que de outro modo poderiam não conhecer. 
 
 Reunião da Revisão de Software 
 
Uma Revisão Técnica Formal é conduzida em uma reunião e será bem sucedida 
se for planejada, controlada e cuidada. 
 
Independentemente do formato de Revisão Técnica, toda Reunião de Revisão deve 
estar de acordo com: 
 
1) Envolver de 3 a 5 pessoas na revisão 
2) Deve haver uma preparação para a reunião (essa preparação não deve exigir 
mais de 2 horas de trabalho de cada pessoa) 
3) A Reunião de Revisão deve durar menos de 2 horas 
 
A Revisão Técnica Formal focaliza uma parte específica (pequena) do software - 
maior probabilidade de descobrir erros. 
 
Diretrizes de Revisão 
 
Devem ser estabelecidas antecipadamente, distribuídas a todos os revisores, ter a 
concordância de todos e então encaminhada. 
 
Conjunto mínimo de diretrizes para as revisõestécnicas formais: 
 
1) Revise o produto, não o produtor. 
2) Fixe e mantenha uma agenda 
3) Limite o debate e a refutação 
4) Enuncie as áreas problemáticas, mas não tente resolver cada problema anotado. 
Diretrizes de Revisão 
5) Faça anotações por escrito. 
6) Limite o número de participantes e 
insista numa preparação antecipada. 
7) Desenvolva uma lista de conferência (checklist) para cada produto que 
provavelmente será revisto. 
8) Atribua recursos e uma programação de tempo para as Revisões Técnicas 
Formais 
9) Realize um treinamento significativo para todos os revisores. 
10) Reveja suas antigas revisões.