Embed Size (px)
DESCRIPTION
Projeto Aplicado do 4°Ciclo ao qual fiz parte no curso de Analise e Desenvolvimento de Sistemas na Unimonte
Citation preview
UNIMONTE
GRADUS
CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE
SISTEMAS
PROJETO APLICADO
Leandro Ferraz Pereira
Luiz da Silva Nakazone
Narciso Oliveira da Silva
Paulo Henrique de Vasconcellos
Rafael Menezes Correa
Rodrigo Alves de Morais
Profª. Nina Maria Bueno
Santos
2010
ESTUDO SOBRE TESTES DE SOFTWARE
Trabalho de conclusão da disciplina Projeto Aplicado do 4º ciclo do Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas.
Santos
2010
RESUMO
No universo do desenvolvimento de sistemas existem palavras que não
devem ser ignoradas, uma delas é qualidade. A qualidade do software desenvolvido
é o ponto chave para o retorno a imagem do desenvolvedor ou da Empresa
responsável pelo desenvolvimento, sendo este retorno positivo ou muito negativo.
Esta pesquisa foi desenvolvida pra tratar o principal tópico da qualidade de
software que é o teste. Através dos testes é que iremos garantir a qualidade da
aplicação desenvolvida e obter o retorno positivo ao responsável pelo
desenvolvimento. Existem diversas técnicas para testar o software antes, durante e
posteriormente ao desenvolvimento, cada um com sua especialidade. Existem
também muitos aplicativos que auxiliam ou até mesmo realizam o teste retornando o
resultado para que apenas seja analisado.
O objetivo desta pesquisa é estudar e compreender a utilidade e importância
das técnicas de testes realizados antes, durante e posteriormente ao
desenvolvimento do sistema, explicando seu funcionamento para concluir como a
aplicação de técnicas de teste de software pode melhorar a qualidade do sistema
desenvolvido.
LISTA DE FIGURAS
FIGURA 1: GRAFO DE FLUXO ............................................................. 18 FIGURA 2: BIG-BANG ........................................................................ 20 FIGURA 3: TESTE INCREMENTAL......................................................... 21 FIGURA 4: TELA DO PROJETO DE SISTEMA ONLY SONY GAMES. ............. 37 FIGURA 5: TESTE DE CAIXA BRANCA. ................................................. 39
LISTA DE TABELAS
TABELA 1: MASSA DE DADOS PARA TESTE. .......................................... 38 TABELA 2: TESTE REALIZADO. ............................................................ 38 TABELA 3: CAMINHOS PERCORRIDOS. ................................................. 39 TABELA 4: FORMULÁRIO PARA TESTE. ................................................. 41
SUMÁRIO
INTRODUÇÃO ...................................................................................................................................................... 7
1. ENGENHARIA DE SOFTWARE .................................................................................................................... 9
2. TESTES DE SOFTWARE ............................................................................................................................. 12
2.1 CONCEITUAÇÃO .......................................................................................................................................... 12
2.2 UTILIDADE DOS TESTES .............................................................................................................................. 14
3. TIPOS DE TESTES ........................................................................................................................................ 15
3.1 CAIXA PRETA .............................................................................................................................................. 16 3.2 CAIXA BRANCA ............................................................................................................................................ 17
3.2.1 Fluxo de Controle ............................................................................................................................ 17 3.2.2 Fluxo de Dados ................................................................................................................................ 18 3.2.3 Fluxo de Complexidade .................................................................................................................. 18
3.3 TESTE DE INTEGRAÇÃO .............................................................................................................................. 19 3.3.1 Big-Bang ........................................................................................................................................... 19 3.3.2 Integração incremental ................................................................................................................... 20 3.3.3 Top-down .......................................................................................................................................... 21 3.3.4 Bottom-Up ......................................................................................................................................... 22 3.3.5 Sandwich .......................................................................................................................................... 22
3.4 TESTE DE UNIDADE .................................................................................................................................... 23
3.5 TESTE DE SISTEMAS................................................................................................................................... 24 3.6 TESTE DE INTERFACE ................................................................................................................................. 24 3.7 TESTE FUNCIONAL ...................................................................................................................................... 25 3.8 TESTE OPERACIONAL ................................................................................................................................. 26
3.9 TESTE DE PERFORMANCE .......................................................................................................................... 26
3.10 TESTE DE CARGA ..................................................................................................................................... 26
3.11 TESTE DE VOLUME ................................................................................................................................... 26 3.12 TESTE DE ESTRESSE (STRESS) ............................................................................................................... 27 3.13 TESTE DE ACEITAÇÃO .............................................................................................................................. 27
3.13.1 Aceitação Formal ........................................................................................................................... 28 3.13.2 Aceitação Informal ......................................................................................................................... 28
3.14 BASEADO EM ERROS ................................................................................................................................ 29 3.14.1 Semeadura de Erros ..................................................................................................................... 29 3.14.2 Análise de Mutantes...................................................................................................................... 29
4. TESTES DE SEGURANÇA .......................................................................................................................... 30
5. TESTES MAIS UTILIZADO .......................................................................................................................... 32
5.1 ENTREVISTAS ............................................................................................................................................. 32 5.1.1 Datasus ............................................................................................................................................. 33 5.1.2 Prefeitura de Santos........................................................................................................................ 34
5.2 PESQUISAS ................................................................................................................................................. 34 5.3 CONCLUSÃO ............................................................................................................................................... 35
6. EXEMPLOS DE TESTES.............................................................................................................................. 37
6.1 TESTE DE CAIXA PRETA (BLACK BOX) ...................................................................................................... 37 6.2 TESTE DE CAIXA BRANCA (WHITE BOX) .................................................................................................... 39 6.3 TESTE DE ACEITAÇÃO ................................................................................................................................ 40
6.3.1 Objetivo ............................................................................................................................................. 40 6.3.2 Descrição do Produto Entregue .................................................................................................... 40 6.3.3 Resultados alcançados ................................................................................................................... 40 6.3.4 Documentos relacionados ao aceite ............................................................................................. 40 6.3.5 Registros (para projetos internos) ................................................................................................. 40 6.3.6 Declaração do Aceite ...................................................................................................................... 41
CONCLUSÃO ...................................................................................................................................................... 42
REFERÊNCIAS ................................................................................................................................................... 43
7
INTRODUÇÃO
Quando pensamos em desenvolvimento de softwares ou na Engenharia de
Software propriamente dita, nos preocupamos com a qualidade do produto, por isso
logo pensamos nos testes de software. O teste enfatiza principalmente a avaliação
da qualidade do produto, podendo localizar, documentar e reparar erros. O objetivo
desta pesquisa é tratar sobre o que são os testes, como eles surgiram, e também os
tipos de teste que existem na atualidade, também mostrando suas finalidades e os
mais utilizados no mercado. Mostraremos também alguns exemplos práticos para
ilustrar os processos dos testes de um software.
O primeiro capítulo abordará a Engenharia de Software: como surgiu e o
motivo. Este é considerado o ponto chave para o surgimento das técnicas de
software. O capítulo seguinte conceitua teste de software e explica sua utilidade e
importância, também aborda a qualidade de produto de software que é um
conhecimento importante para o desenvolvedor por tratar-se de uma norma.
Nesta pesquisa foram reunidas diversas técnicas de teste estudadas que
estão descritos no terceiro capítulo. Diferente da conceituação de teste de software,
neste tópico está conceituada cada uma das técnicas de teste estudadas, entre elas,
a técnica de teste de segurança, que recebe um capítulo a parte (quarto) por possuir
uma importância superior aos testes tradicionais.
Toda informação desta pesquisa partiu de livros, sites e abordagem a
profissionais de informática da área de desenvolvimento de sistemas. Utilizando da
abordagem, foram realizadas entrevistas com algumas empresas com o objetivo de
saber quais os testes que utilizam e tentar concluir quais os mais utilizados no
mercado. O resultado está descrito no quinto capítulo e, no sexto são apresentados
exemplos de três dos testes estudados.
Existem inúmeras técnicas ou métodos pra realizar os testes, cada um com
sua finalidade, mas de modo geral sua principal finalidade é localizar e expor os
pontos fracos do software, e com essas informações, os responsáveis pelo
planejamento e desenvolvimento (o analista, programador, engenheiro e etc.) terão
as informações necessárias para corrigir os possíveis erros que podem ocorrer
durante o desenvolvimento ou futura alteração. Mais de um terço das falhas
poderiam ser evitados por testes de software e em média 50% dos erros só são
8
encontrados na produção. Por estes motivos os testes de software vêm se
popularizando cada vez mais no mercado.
9
1. ENGENHARIA DE SOFTWARE
A engenharia de software é uma área do conhecimento que nos oferece as
melhores técnicas para o desenvolvimento de software de qualquer natureza. Tem
como característica trazer para a área de TI (Tecnologia da Informação) os
princípios efetivos da engenharia com o propósito de obter um produto final de
software de forma eficiente, confiável e econômica. Na engenharia propriamente dita
já temos estes conceitos; um exemplo prático para uma comparação é a construção
de um prédio: a engenharia é necessária para a criação do projeto, elaboração de
sua construção através de uma análise profunda, desenvolvimento e manutenção.
Na década de sessenta, houve uma explosão conhecida como crise do
software. A demanda de software exigida pelo mercado foi acima do esperado e
havia uma dificuldade extrema no desenvolvimento, ainda mais quando se tratava
de sistemas complexos demais. Não havia demanda para atender o mercado,
causando:
• Custo elevadíssimo, estourando o orçamento das empresas contratantes;
• Prazos fora do combinado (desenvolvimento, entrega, manutenção, etc.);
• Insatisfação do cliente diante do sistema apresentado, pois seus requisitos
não eram atendidos;
• O gerenciamento do desenvolvimento do software era uma etapa
impraticável;
• A codificação era de difícil interpretação e não havia documentação, ou
seja, ao sair um programador do projeto, o que entrava no lugar não
entendia o programa e, muitas vezes era necessário iniciar a codificação
do programa novamente. (RAMOS, 2010)
Foi então que a engenharia de software surgiu, como uma tentativa de
combater todos os sintomas da crise diretamente.
Ainda hoje, existe uma dificuldade muito grande em aplicá-la, pois é vista
como muito complexa e metódica. Muitos desenvolvedores não visualizam sua
aplicação como um investimento em tempo e conhecimento.
10
O IEEE (Institute of Electrical and Electronics Engineers, em português -
Instituto de Engenheiros Eletricistas e Eletrônicos) criou um guia dividido em dez
itens que compreende o que podemos chamar de melhores práticas da engenharia
de software. O guia chama-se SWEBOK (Software Engineering Body of Knowledge,
em português – Corpo de Conhecimento da Engenharia de Software) e está dividido
nas seguintes áreas:
• Requisitos – são definidos em conjunto com o solicitante para solução de
problemas reais;
• Projeto – definição da arquitetura, das conexões, componentes e outras
características de sistema ou componentes;
• Construção – neste item, alguns testes já são apurados (tema do projeto).
Há um trabalho minucioso da criação do software pela combinação de
códigos, testes de unidade, testes de integração, verificação e depuração;
• Testes – através de técnicas ou métodos, o software é apurado;
• Manutenção – após a apuração através dos testes, o sistema é entregue
ao solicitante e retorna para verificação de anomalia ou alteração de
requisitos para adequação;
• Gerência de configuração – este item é necessário para identificar o que
mudou no sistema, o porquê de ter mudado e quem fez a mudança; o
objetivo é controlar as configurações e garantir a integridade e
rastreabilidade das configurações;
• Gerência de engenharia – neste item são aplicadas as atividades de
gerenciamento para garantir um melhor desenvolvimento e manutenção;
• Ferramentas e métodos – como o item mesmo descreve, são ferramentas
e métodos de desenvolvimentos utilizados com o objetivo de auxiliar nas
atividades do ciclo de vida do software (esta é a definição do próprio
SWEBOK);
• Qualidade – outra importante abordagem. O item que também caracteriza
as informações deste projeto. Trata-se da qualidade do software em si, um
dos problemas que se alastravam durante a crise do software.
(FERNANDES, 2004; IEEE, 2010)
11
Como foi dito, é importante fazer a abordagem sobre engenharia de software
e SWEBOK para que se entenda de onde surgiram os testes e o porquê de ser
diretamente ligada a qualidade. Não é possível dizer exatamente como os testes
surgiram, mas existem muitos relatos de que o surgimento foi exatamente após a
criação da engenharia de software.
Em entrevista com Mário Sérgio Rocha, professor da Instituição de Ensino
Superior Unimonte que vivenciou este período da adequação da engenharia de
software, perguntamos em qual momento passou a realizar técnicas de teste em
suas aplicações; o professor informou que sempre utilizou os chamados testes de
mesa para verificar a exatidão da informação em suas aplicações, mas lembra-se
claramente que as técnicas de testes e seus aprimoramentos surgiram mesmo após
a criação da engenharia de software.
Nos tópicos a seguir, serão abordados os testes mais especificamente e sua
ligação com a qualidade de software.
12
2. TESTES DE SOFTWARE
2.1 Conceituação
Não é possível dizer que um sistema funciona ou funcionará 100% durante
toda sua vida útil, ainda mais quando se trata de um sistema de grande porte.
Porém, podemos utilizar de vários recursos que garantem seu bom funcionamento
em virtude do motivo no qual o sistema foi criado. Estes recursos são chamados de
testes de software, que são uma parcela do que podemos agregar a qualidade de
software. (CAMPOS, 2010)
O que se espera de um sistema é o que consiste na ISO/IEC (International
Standards for Business/ International Electrotechnical Commission, em português –
Organização Internacional para Normalização/ Comissão Eletrotécnica Internacional)
9126-1:
• Funcionalidade – propriedades, atributos e funções específicas que estão
dentro de um requisito explícito ou implícito do usuário;
• Usabilidade – deve ser de fácil entendimento, simples de operar e ser
atraente pra o usuário;
• Confiabilidade – o sistema deverá manter-se em um mesmo nível de
desempenho dentro das condições estabelecidas;
• Eficiência – está relacionado diretamente com o desempenho do sistema;
• Manutenibilidade – quando houver necessidade de modificações, o
processo deve ser feito sem complicações;
• Portabilidade – possuir suporte pra mudança de ambiente.
A ISSO/IEC é a norma para qualidade de produto de software. Todos estes
itens, quando seguidos podem garantir a satisfação do cliente. A qualidade do
sistema desenvolvido pode definir o futuro do desenvolvedor ou da empresa
responsável pelo desenvolvimento da aplicação, pois está ligada diretamente a sua
imagem. Uma empresa que não obtém a satisfação do cliente por não atender aos
requisitos por ele especificados, por não possuir uma interface atraente ou de fácil
manipulação ou até mesmo por apresentar erros constantes, cria uma imagem
13
negativa no mercado. O desenvolvedor deve estar consciente dos termos
apresentados pela norma de qualidade e respeitá-los, evitando vários problemas
futuros. (CAMPOS, 2010)
Como já mencionado, nenhum sistema funciona ou funcionará perfeitamente,
todo sistema possui algum tipo de problema. Muitos sistemas necessitam de
alterações diárias para que estejam funcionando ao menos da forma que o usuário
deseja, ou seja, estar de acordo com os requisitos do sistema, o que também não
garante que estejam trabalhando corretamente. Alguns dos casos que levam o
software a ter algum tipo de erro/problema são:
• Software complexo demais;
• Erros de lógica ocorridos durante ou posterior a sua criação;
• Prazo de entrega (obriga a equipe de desenvolvimento a apressar o
desenvolvimento gerando diversos problemas);
• Desentendimento na equipe de desenvolvimento (analistas,
programadores ou qualquer indivíduo envolvido no projeto);
• Alteração do projeto ou parte dele durante o desenvolvimento.
Para diminuir esta carga de deficiências, os testes são utilizados. Estes testes
são, na verdade, um conjunto de métodos/técnicas e ferramentas específicas que
auxiliam a encontrar erros e manter o sistema equivalente ao que foi requisitado.
Os testes auxiliam no tratamento de riscos associados à performance e a tudo
que se refere à qualidade de software, são trabalhados baseando-se na intuição, no
código, na especificação, na falha, no uso ou na natureza da aplicação. Existem
também outras técnicas além destas mencionadas.
No próximo sub-tópico será abordada mais especificamente a utilidade dos
testes. (CAETANO, 2010)
14
2.2 Utilidade dos testes
O teste de software é uma fase do processo de Engenharia de Software que
visa atingir um nível máximo de qualidade do produto. O objetivo deste tipo de teste
é garantir que defeitos sejam encontrados no produto, para que eles sejam
corrigidos pela equipe responsável. (CRESPO, 2004)
O conceito de teste de software pode tanto ser analisado e compreendido de
uma maneira formal, ou também de uma maneira mais intuitiva. De uma forma
simplificada, testar um software significa verificar através de uma execução
controlada se o seu comportamento está de acordo com o especificado. (CRESPO,
2004)
Testar uma aplicação e relatar erros é fornecer um diagnóstico do estado do
software, e é muito importante que estas informações sejam as mais completas e
precisas possível, pois elas vão servir de base para tomadas de decisões em
relação ao projeto que está sendo analisado. (CRESPO, 2004)
Esses erros podem ser originados por diversos motivos. Um exemplo é uma
especificação que pode estar incompleta ou errada, ou até mesmo pode conter
requisitos impossíveis de serem implementados devido à limitação do software ou
hardware. A implementação também pode estar incompleta ou errada, por exemplo,
um erro no código. Assim, um erro de software é o resultado de um ou mais defeitos
em alguns aspectos do sistema desenvolvido. (CRESPO, 2004)
Quanto mais cedo um defeito for encontrado no ciclo de vida de um software
através de testes, mais barato é o custo de sua correção. De acordo com Myers
autor do livro The Art of Software Testing (em português - A arte do teste de
software), corrigir um erro no software que se propagou até o ambiente de produção
pode chegar a ser cem vezes mais caro do que corrigir e encontrar este mesmo erro
nas fases iniciais do projeto. Por isso um bom planejamento dessas atividades pode
significar economia para um projeto, visto que a identificação de erros no início do
ciclo de desenvolvimento do software pode reduzir os custos da sua correção,
aumentando assim sua confiabilidade. (CRESPO, 2004)
Veremos no próximo capítulo alguns dos tipos de testes existentes.
15
3. TIPOS DE TESTES
Com base em estudos em livros e sites especializados sobre o assunto, foi
elaborado este capitulo sobre tipos de testes de software.
A importância dos testes durante o desenvolvimento do software quanto na
fase de construção do projeto tem como um dos principais fatores prezar as
especificações do projeto e a qualidade do produto.
Neste capítulo iremos conhecer quais são os principais testes utilizados no
desenvolvimento de softwares:
• Caixa Preta;
• Caixa Branca;
• Fluxo de Controle;
• Fluxo de Dados;
• Fluxo de Complexidade;
• Teste de Integração;
• Incremental;
• Top Down;
• Bottom Up;
• Sandwich;
• Big Bang;
• Teste de Unidade;
• Teste de Sistema;
• Teste de Interface;
• Teste de Funcional;
• Teste Operacional;
• Teste de Performance;
• Teste de Carga;
• Teste de Volume;
• Teste de Stress;
• Teste de Aceitação;
• Baseado em erros;
16
3.1 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 já conhecido e esperado previamente. Como detalhes de
implementação não são considerados, os casos de testes são todos derivados da
especificação.
Quanto mais entradas são fornecidas, mais rico será o teste. Numa situação
ideal todas as entradas possíveis seriam testadas, mas na maioria dos casos isso é
impossível.
Outro problema é que a especificação pode estar ambígua em relação ao
sistema produzido e como resultado as entradas especificadas podem não ser as
mesmas aceitas para o teste.
Uma abordagem mais realista para o teste de caixa-preta é escolher um
subconjunto de entradas que maximize a riqueza do teste. Pode-se agrupar
subconjuntos de entradas possíveis que são processadas similarmente, de forma
que testar somente um elemento desse subconjunto serve para averiguar a
qualidade de todo o subconjunto. Por exemplo: em um sistema que aceita um inteiro
como entrada, testar todos os casos possíveis pode gerar, pelo menos, dezenas de
milhares de casos de testes distintos.
Entretanto, a partir da especificação do sistema, pode-se encontrar um
subconjunto de inteiros que maximizem a qualidade do teste. Depende do propósito
do sistema, mas casos possíveis incluem inteiros pares, inteiros ímpares, zero,
inteiros positivos, inteiros negativos, o maior inteiro, o menor inteiro.
Definição do teste caixa preta é de ignorar os mecanismos internos de um
sistema e focalizar apenas as saídas geradas em reposta a entradas e condições de
execução selecionada. (PAULA FILHO, 2009)
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. A aplicação de técnicas de teste
leva o testador a produzir um conjunto de casos de teste (ou situações de teste).
A aplicação combinada de outra técnica – técnica de particionamento de
equivalência (ou uso de classes de equivalência) permite avaliar se a quantidade de
17
casos de teste produzida é coerente. A partir das classes de equivalência
identificadas, o testador construirá casos de teste que atuem nos limites superiores e
inferiores destas classes, de forma que um número mínimo de casos de teste
permita a maior cobertura de teste possível.
Uma abordagem no desenvolvimento do teste de caixa-preta é o teste
baseado na especificação, de forma que as funcionalidades são testadas de acordo
com os requisitos. Apesar de necessário, esse tipo de teste é insuficiente para
identificar certos riscos num projeto de software.
3.2 Caixa branca
Método de teste estrutural onde o foco é efetuar teste no código fonte de um
software.
Referido teste leva em conta os mecanismos internos de um sistema ou
componente.
Importante ressaltar que, no entendimento de Wilson de Pádua Paula Filho,
são sinônimos de teste de caixa branca: Teste estrutural (structural testing); Teste
de caixa transparente (glass-box testing).
A caixa branca é uma técnica que trabalha diretamente sobre o código fonte
dos componentes do programa para que seja possível serem avaliados alguns dos
principais critérios de classificação de testes, quais sejam:
• Fluxo de Controle
• Fluxo de Dados
• Fluxo de Complexidade
3.2.1 Fluxo de Controle
O fluxo de controle utiliza apenas características de controle da execução do
programa, como comandos ou desvios para determinar quais estruturas são
necessários. Os critérios mais conhecidos dessa classe são TODOS-NÓS, que
exige que a execução do programa passe, no mínimo, uma vez em cada vértice do
grafo de fluxo, ou seja, que cada comando do programa seja executado pelo menos
uma vez.
18
Grafo de fluxo é uma forma de visualizar o fluxo de controle lógico, usando a
notação de uma forma ilustrada na figura. O grafo de fluxo permite seguir mais
facilmente os caminhos do programa.
Figura 1: Grafo de Fluxo
Fonte: Própria
3.2.2 Fluxo de Dados
O critério de fluxo de dados utiliza as informações do fluxo de dados do
programa para determinar os requisitos de teste. Esses critérios exploram as
interações que envolvem definições de variáveis e referências a tais definições para
estabelecerem os requisitos de teste.
O método fluxo de dados seleciona caminhos de teste de software de acordo
com a localização das definições e dos usos das variáveis do software.
3.2.3 Fluxo de Complexidade
O critério baseado em complexidade utiliza informações sobre a
complexidade do programa para derivar os requisitos de teste. Um critério bastante
conhecido dessa classe é o critério de McCabe, que utiliza a complexidade
ciclomática do grafo de programa para derivar os requisitos de teste.
19
Essencialmente, esse critério requer que um conjunto de caminhos linearmente
independentes do grafo de programa seja executado.
A complexidade ciclomática é uma métrica útil para previsão dos módulos que
provavelmente sejam propensos a erro. Ela pode ser usada tanto para planejamento
de teste quanto para projeto de casos de teste.
3.3 Teste de Integração
Integração sucede o Teste de Unidade, onde os módulos são testados
individualmente.
O Teste em tela é uma atividade sistemática aplicada durante a integração da
estrutura do software, visando analisá-la em busca de erros associados às
Interfaces entre os módulos.
O objetivo do Teste é verificar os módulos testados no nível de unidade e
construir a estrutura do software que foi estipulado no projeto.
Nesse Teste, os componentes são combinados e avaliados para testar a
integração entre eles. (PAULA FILHO, 2009)
O conceito da técnica sistemática para estrutura do software realizando testes
para descobrir erros associados à interface. A técnica de testes de integração é
composta por algumas estratégias, que são:
• Incremental
• Top-Dowm
• Sandwich
• Big-Bang
3.3.1 Big-Bang
Big-Bang é uma estratégia de teste, onde os módulos são testados
isoladamente e depois integrados de uma vez só.
20
Figura 2: Big-Bang
Fonte: Teste & Qualidade de Software
Para utilizar uma integração usando a estratégia Big-Bang é necessário stubs
e drivers para testar os módulos isoladamente.
Stubs é um Proxy para os objetos remotos no lado cliente, e skeleton seriam
esses Proxy no lado do servidor. Os Stubs repassam os métodos invocados do
cliente remoto para os skeletons, que seriam os servidores. O skeleton devolve o
resultado para o cliente, através dos stubs.
Drivers é um software que gere a comunicação entre um software e um
hardware, para que eles possam se entender.
A vantagem de utilizar essa estratégia de teste encontra-se na eficiência em
relação a sistemas de pequeno e médio porte.
A desvantagem, por sua vez, surge nos casos em que ocorra alguma falha na
interface de um modulo com outro, uma vez que será difícil ser preciso ao encontrar
a causa da falha, por se tratar de uma estratégia não incremental.
3.3.2 Integração incremental
É a junção de todos os módulos, onde eles são divididos por etapas. Os
módulos são: incremental, top-down, sandwich, big-bang.
21
A integração ocorre através de uma série de ciclos de teste. Em cada ciclo os
módulos vão se integrando com os módulos já existentes e testados para gerar
maiores módulos. O conceito é concluir todas as etapas de testes, nas quais os
desenvolvedores vão efetuando correções, de acordo com os erros que forem
surgindo e, assim, até concluir todas as etapas.
O exemplo clássico de uma abordagem incremental ocorre freqüentemente
na fabricação de bolos. Como qualquer confeitaria, antes de colocar a massa no
forno, esta é degustada e, antes de colocar a cobertura, verifica-se sua consistência
e sabor.
Outro exemplo de integração incremental são as atividades que são
integradas durante as fases de testes.
Figura 3: Teste Incremental
Fonte: Própria
Uma das principais vantagens de se utilizar a estratégia incremental está em
não precisar esperar até que todo o sistema esteja pronto para iniciar os testes. As
possibilidades de falhas no projeto são menores, uma vez que os módulos são
verificados antes e, dessa forma, é possível fazer a correção de possíveis falhas
encontradas.
A desvantagem é que, por se tratar da integração de todos os módulos, acaba
se tornando mais complexo na implementação do teste.
3.3.3 Top-down
22
A abordagem descendente, também conhecida como top-down – ou ‘de cima
para baixo’ –, é uma técnica que funciona do nível mais alto ao mais baixo, como o
próprio nome diz. De forma hierárquica, ele começa por um controle principal e
passa gradativamente, de forma seqüencial entre os outros módulos subordinados.
O teste de integração top-down é uma abordagem incremental para a
construção da arquitetura de software. (ROGER PRESSMAN,2006)
3.3.4 Bottom-Up
A abordagem para integrar os componentes, a fim de testar o sistema maior,
é denominada teste bottom-up.
Quando esse método é utilizado, cada componente no nível inferior da
hierarquia do sistema é testado individualmente. Os próximos componentes a serem
incluídos nos testes são aqueles que chamam os que foram previamente testados.
Essa abordagem é seguida repetidamente, até que todos os componentes sejam
incluídos no teste.
Ao contrário da top-down, a integração do sistema começa a partir do nível
mais baixo do software, ou seja, o módulo. O módulo é classificado como o mais
baixo nível se ele não depende de outro módulo. A Bottom-Up assume que todos os
módulos foram individualmente testados antes.
Para integrar um conjunto de módulos usando a Bottom-Up, nós precisamos
construir um driver (controlador) que chamará o módulo a ser integrado. Uma vez
que a integração de um grupo de baixo nível de módulos tenha sido considera
satisfatória, o driver irá substituir o atual módulo e um, ou mais drivers, serão usados
para integrar mais módulos com um conjunto de módulos já integrados. O processo
de integração Botton-Up continua até todos os módulos terem sido integrados.
3.3.5 Sandwich
A técnica Sandwich é uma integração das técnicas Top-down e Botton-up,
que se subdivide em três camadas, que são:
• Lógica
• Meio
23
• Operacional
A Lógica contém os módulos que são mais freqüentemente utilizados, esta
camada é testada utilizando a técnica Bottom-up. O Meio são os módulos restantes.
Já o Operacional é a camada que contem os módulos principais. Do ponto de
vista operacional, esta camada é testada utilizando a técnica Top-Down.
A utilização das técnicas Top-Down, para os níveis superiores, e Botton-Up,
para os níveis inferiores, pode ser o melhor ajuste para o teste de integração do
software.
Porém, existem alguns pontos que devem ser observados, senão vejamos: no
teste de níveis superiores da estrutura do programa forem integrados de cima para
baixo, o numero de drivers pode ser reduzido substancialmente na integração dos
módulos inferiores, já nos teste inferiores, o numero de clusters (módulos que
executam uma sub-função do sistema) pode ser reduzido substancialmente na
integração dos módulos superiores.
Usando a técnica Sandwich a integração é mais flexível e adaptável, porém,
ela é mais complexa de ser planejada.
3.4 Teste de Unidade
O teste de unidade é realizado na menor unidade dos programas e objetiva a
verificação de erros existentes nas unidades de projeto do mesmo. De certa forma, o
teste de unidade é um meio de teste de caixa branca, onde pode ser realizado em
paralelo sobre diferentes módulos. Lembrando que o teste de unidade não corrige
erro, apenas os encontra. Vejamos alguns benefícios do teste de unidade:
• Essencial para análise de desempenho;
• Aumento de produtividade dos desenvolvedores;
• Essencial para refactoring (em português – refatoração), processo que
melhora o rendimento do software limpando seu código;
• Servem como documentação do sistema;
• Num desenvolvimento incremental, ajuda a manter o foco na parte
envolvida pelo incremento e.
24
3.5 Teste de Sistemas
Teste de Sistema tem como principal função avaliar erros que possam ser
ocasionados por hardware, software, peopleware (usuário) e dados.
O teste de sistema inclui diversas modalidades de teste, cujo objetivo é testar
o sistema computacional como um todo.
Um problema clássico de teste de sistemas é ser “dedo-duro”. Isso acontece
quando algum erro ocorre e os desenvolvedores que codificam parte do software
alegam culpa alheia, nunca assumindo a responsabilidade. Para evitar que isso
ocorra, a engenharia de software deve antecipar possíveis causas do problema de
interface. Assim, foram desenvolvidas quatro etapas, que são:
1. Projetar caminhos de manipulação de erros – para que testem toda a
informação que chega de outros elementos que compõem o sistema;
2. Conduzir uma série de testes - para que simule maus dados ou outros
erros em potencial na interface do software;
3. Registrar os resultados de testes – para que possa usar como parâmetro
de evidencia, em caso de existir “dedo-duro”;
4. Participar do planejamento e do projeto de teste – para garantir que o
software seja testado de forma adequada.
3.6 Teste de Interface
O teste de interface deve garantir que as informações fluam adequadamente
para dentro e para fora da unidade de software a ser testada. O teste de interface é
o mais importante e deve ser o primeiro dos testes a ser aplicado sobre uma
unidade de software. Ele deve ser realizado em primeiro lugar, pois qualquer
problema observado durante a execução deste põe em dúvida os resultados obtidos
nos demais testes sobre a mesma unidade. Durante sua realização, devem ser
observados os seguintes aspectos:
• Coerência (em termos de números, atributos e sistemas de unidades)
entre argumentos de um módulo e os parâmetros de entrada;
25
• Coerência (em termos de números, atributos e sistemas de unidades)
entre argumentos passados aos módulos chamados e os parâmetros de
entrada;
• Verificação sobre a consistência dos argumentos e a ordem de passagem
destes nas funções embutidas;
• Existência de referências a parâmetros não associados ao ponto de
entrada atual;
• Alteração de argumentos de entrada/ saída;
• Consistência de variáveis globais ao longo dos módulos;
• Passagem de restrições sobre argumentos.
Se houver caso de unidades que envolvam tratamento de entradas/ saídas,
as operações em geral, envolvendo tratamento de arquivos ou programação de
dispositivos periféricos devem ser cuidadosamente (ou exaustivamente) verificadas.
3.7 Teste Funcional
O teste do sistema começa com o teste funcional. Enquanto os testes
anteriores se concentravam nos componentes e em suas interações, essa primeira
etapa ignora a estrutura do sistema e tem como foco a sua funcionalidade.
Teste funcional tem o objetivo de testar as funcionalidades, requerimentos,
regras de negócio presentes na documentação.
É utilizada para demonstrar que os softwares são de funções operacionais, a
entrada é adequadamente aceita e a saída corretamente produzida.
Funcionalidade é uma atividade complementar aos testes de caixa branca,
com a finalidade de descobrir tipos/classes de erros.
Procura-se descobrir erro em:
• Funções incorretas ou ausentes;
• Erros de interface;
• Erros nas estruturas de dados;
• Acesso a bancos de dados externos;
• Erros de desempenho;
26
• Erro de inicialização e término.
3.8 Teste Operacional
Nessa técnica o sistema produzido é colocado para teste em ambiente de
produção e é conduzido diretamente pelos administradores do ambiente final em
que o sistema entrara em produção. Nessa fase de teste são efetuadas várias
simulações como a instalação do software ou uma copia de segurança dos dados
entre outras, que visam garantir que o sistema ao entrar em ambiente de produção
garantira o suporte aos negócios da empresa. (MYERS, 2004)
3.9 Teste de Performance
Com este teste, podemos medir o desempenho da aplicação, são trabalhados
os fluxos de execução, o acesso direto aos dados no banco e todas as chamadas e
execuções de funções do sistema.
Seu objetivo é identificar os picos de perfornance, ou seja, o chamado
“gargalo” durante a execução da tarefa.
3.10 Teste de Carga
Teste de carga é efetuado através de programas que geram carga no sistema
exercitando um conjunto adequado de instruções. Este teste, geralmente mede as
taxas de transferência de dados das cargas de execução da aplicação, ou seja, o
trabalho que está sendo executado. São calculados e relatados os valores tolerantes
para a operação.
3.11 Teste de Volume
Este teste é destinado a realizar a verificação a capacidade da aplicação em
tratar um volume alto de dados. Seus parâmetros principais são a entrada e saída
de dados ou dados tratados diretamente em seu banco.
Este teste requer uma estratégia teoricamente simples, como utilizar entrada
de dados em seu volume máximo em cada um dos campos ou, até mesmo, forçar
27
situações em que um relatório retorne um volume enorme de dados do banco
causando restrições que prevejam que nenhum dado seja retornado.
3.12 Teste de Estresse (Stress)
Os testes de estresse avaliam o sistema quando este é levado ao seu limite
por um pequeno período.
Se os requisitos definem que um sistema deve lidar com até um número
especificado de dispositivos ou usuários, um teste de estresse avalia o desempenho
do sistema quando todos esses dispositivos ou usuários estiverem ativos
simultaneamente. Este teste é muito importante para sistemas que geralmente
operam abaixo de sua capacidade máxima, mas que são severamente forçados em
certos picos de demanda.
Os testes evolvem toda a equipe de desenvolvimento como o analista – que é
responsável por especificar a simulação dos testes –, a equipe responsável pelo
banco de dados – que verifica o tempo de resposta do servidor de banco de dados –
e, também, da equipe de suporte – responsável pela analise da resposta do
hardware e do sistema operacional.
3.13 Teste de Aceitação
Os testes de aceitação são testes formais, que são conduzidos para
determinar se um software satisfaz ou não os critérios de aceitação correspondentes
e para que a entidade autorizada possa se decidir se aceitara ou não o software.
Existem três segmentos de Teste de Aceitação, são eles:
• Aceitação formal;
• Aceitação informal (teste alfa);
• Teste Beta.
O segmento selecionado se baseia geralmente nos requisitos contratuais, nos
padrões organizacionais e corporativos, bem como no domínio do aplicativo.
(WTHREEX, 2010)
28
3.13.1 Aceitação Formal
O teste de aceitação formal é um processo bastante gerenciado e costuma
ser uma extensão do teste de sistema. Os testes são projetados e planejados com o
mesmo cuidado e alto nível de detalhe do teste de sistema e os casos de testes
escolhidos devem ser um subconjunto dos que foram realizados anteriormente no
teste de sistema. É muito importante não se distanciar de nenhuma forma dos casos
de testes escolhidos.
O teste, em algumas organizações é executado diretamente pela organização
do usuário final, em outras é executado por um grupo de testes independentes.
(WTHREEX, 2010)
3.13.2 Aceitação Informal
Neste teste os procedimentos para execução não precisam de tanto rigor na
sua definição como no teste formal. As tarefas de negócios e suas funções a serem
exploradas são identificadas e documentadas, porém não existe caso de teste para
seguir, quem determina isso é o testador individual. Essa abordagem de teste não é
tão bem controlada como a do teste formal e é mais subjetiva do que a do teste
formal. (WTHREEX, 2010)
3.13.3 Teste Beta
O teste beta é o menos controlado dos três segmentos do teste de aceitação,
ele é executado inteiramente pelo testador individual onde a quantidade de detalhes,
os dados e a abordagem adotada e de inteira responsabilidade dele. Cada testador
e responsável por criar o próprio ambiente, selecionar os dados correspondentes e
determinar as funções a serem exploradas e identificar os próprios critério que o
levarão a aceitar ou não o software.
O teste beta geralmente é implementado por usuários finais, com pouco ou
nenhum gerenciamento por parte da organização de desenvolvimento, por isso ele é
o mais subjetivo de todos os segmentos do teste de aceitação. (WTHREEX, 2010)
29
3.14 Baseado em erros
Também conhecido como Teste de Mutação é caracterizado pela inclusão
proposital de erros como forma de revelar erros existentes previamente. Esse teste
fornece indicadores que possibilitam o melhor gerenciamento do processo de teste.
(PRESSMAN, 2006)
Dentro do Teste Baseado em Erros, existem dois tipos de segmentos de
teste, são eles:
• Semeadura de Erros;
• Analise de Mutantes.
3.14.1 Semeadura de Erros
Neste segmento de teste erros artificiais são introduzidos no código do
programa para logo após realizar um caso de teste para se verificar quais são os
erros naturais e erros artificiais dentro do programa. Assim seguindo como base a
proporção de erros naturais/artificiais encontrados no código do programa é possível
estimar a quantidade de erros remanescentes para o conjunto de caso de teste
definidos para este programa. (PRESSMAN, 2006)
3.14.2 Análise de Mutantes
Nesta técnica, gera-se um caso de teste (T) para um programa (P) e verifica-
se se ele esta funcionando corretamente. Logo após a essa verificação a partir do
código que esta funcionando perfeitamente geram-se programas com pequenas
modificações no código chamados de programas mutantes (M). Esses programas
mutantes (M) são verificados em relação ao caso de teste (T), caso a verificação de
M apresentar algum resultado diferente a do código original P o mutante é
“descartado” caso contrario se o programa M não apresentar resultados diferentes
de P o código desse programa vai para analise mais profunda. (PRESSMAN, 2006)
Outro teste que não poderia deixar de ser citado é teste de segurança.
Considerado um teste muito importante, ganhou um capítulo a parte e será
abordado a seguir.
30
4. TESTES DE SEGURANÇA
Os Testes de Segurança de Softwares tem uma importância muito grande no
desenvolvimento de uma aplicação, pois servem para garantir a confidencialidade,
integridade e disponibilidade das informações que serão tratadas pelo software, o
que não é garantido pelos testes de softwares “tradicionais”, que buscam apenas
garantir a qualidade e funcionalidade dos requisitos do software a ser desenvolvido.
Estes tipos de testes garantem que requisitos de segurança de software sejam
seguidos, mesmo quando estes requisitos não fazem parte das especificações
funcionais. (TECH, 2008)
Atualmente existem vários problemas relacionados à segurança de software,
pois muitas empresas não colocam no projeto de seu sistema os testes de
segurança e, se colocam, não são aplicados corretamente, ocasionando assim
futuras falhas em seu sistema desenvolvido, abrindo brechas para possíveis ataques
hackers, vazamento de informações sensíveis a organização e até o paralizamento
total da aplicação. Mas, três problemas relacionados à segurança de software estão
entre os principais e mais críticos existentes hoje, são eles:
• Buffer Overflow (Estouro de Pilha): acontece quando um buffer de
tamanho determinado na fonte do sistema recebe mais dados do que o
esperado, assim o buffer literalmente “estoura” e acaba sobrescrevendo
parte da pilha, mudando assim o valor das variáveis locais, parâmetros e
ou endereço de retorno. Assim essa falha pode tanto parar o sistema ou
gerar comandos arbitrários na máquina dando, por exemplo, num ataque
mal intencionado no sistema, o prompt de comando dá acesso irrestrito ao
sistema operacional.
• SQL Injection (Injeção de SQL): é uma falha que permite executar
comandos SQL, tanto de manipulação de dados (select, insert, update,
delete) ou comandos de definição de dados (create, drop, alter). Esses
comandos são injetados em campos de formulários no sistema
disponibilizado para o usuário tratar informações. Explorando essa falha
em um sistema, pode se obter por exemplo os nomes de todos os
31
usuários do sistema ou a lista de endereços cadastrados dos clientes mais
importantes para a organização.
• XSS (Cross-site Scripting, em português – e um termo em inglês sem
tradução específica): é uma vulnerabilidade muito encontrada em sistemas
web. Essa vulnerabilidade quando explorada permite ao atacante inserir
códigos maliciosos nesses sistemas web, para que sejam executados no
momento em que tais sistemas forem acessados. Por essa vulnerabilidade
ser explorada em sistemas web, o ataque permite, por exemplo, que
conteúdos em uma zona sem privilégios sejam executados com permissão
de uma zona privilegiada, assim podendo executar scripts Active X sem
que o usuário saiba.
Estes tipos de falhas são considerados críticas, porém são bem fáceis de
serem detectadas, se durante o projeto os testes de segurança forem bem
aplicados, tornando assim um software com qualidade e também seguro. (I
MASTERS, 2008)
Conhecendo tantos testes, precisamos identificar quais são mais aplicados
nas empresas atualmente, para tanto, foram realizadas entrevistas com profissionais
da área e empresas desenvolvedoras de sistemas, abordado no próximo capítulo.
32
5. TESTES MAIS UTILIZADO
Para falar dos testes mais utilizados no mercado atual tivemos que fazer
algumas pesquisas e entrevistas com profissionais que atualmente, trabalham no
desenvolvimento software. Toda empresa que está desenvolvendo seu software,
tem por premissa que ele funcione perfeitamente, atendendo os requisitos funcionais
e não contendo erros.
Passamos a observar primeiramente as empresas onde trabalhamos, e
começamos a perceber que por mais que as empresas queiram um software sem
erros, a maioria delas não adotou um padrão para os testes, ou seja, não utilizam
um procedimento único, com metodologias e técnicas de testes de software. Isso
não quer dizer que elas não testam, e nem se preocupam com a qualidade do
produto final. O fato é que as técnicas de testes ainda são uma área muito nova no
mercado da tecnologia, faltando até mesmo mão de obra qualificada. E nisso
observamos que os testes acontecem da seguinte maneira:
• As equipes de desenvolvimento acabam elas mesmas testando de acordo
com o desenvolvimento de cada programa, ou seja, a cada programa do
sistema que fica pronto,
• O programador faz o primeiro teste, para ver se roda e se não há nenhum
erro de programação, estando tudo certo ele pede para um estagiário ou
usuário fazer um teste simulando uma situação real. Isso acontece em
pequenas empresas como na Soldier de Segurança.
5.1 Entrevistas
Conseguimos entrar em contato com algumas empresas, que gentilmente nos
atenderam, falando sobre seus processos de testes. Enviamos alguns questionários
e com essas respostas obtivemos informações que nos ajudaram a formar uma
opinião.
Uma delas foi o DATASUS (departamento de informática do SUS – Sistema
Único de Saúde). No Datasus tem o chamado PTS (Processo de Teste de
Software).
33
Pesquisa respondida por: Márcia Cristina da Silva, Analista de Sistemas,
Departamento de Gerencia de Testes.
5.1.1 Datasus
Quais são as Técnicas de testes e ferramentas mais utilizadas por sua
equipe?
Márcia: As técnicas de testes e as ferramentas normalmente estão
diretamente associadas ao tipo de teste.
Por exemplo, para testes do tipo Funcional, utilizamos as técnicas de
"Requisitos" e "Stress de Campos".
A “Técnica de Requisitos” visa identificar as inconsistências ou divergências
entre os requisitos especificados na documentação versus os requisitos
implementados na aplicação.
O objetivo desta técnica é determinar se o sistema é executado conforme
especificado e técnica de “Stress de Campos” determina a capacidade que o
sistema tem para tratar as transações incorretas apropriadamente. Os objetivos da
técnica de Stress de Campos são:
• Determinar se todas as condições de erro esperadas são reconhecidas
pelo sistema;
• Determinar se foi atribuída responsabilidade para processar os erros
identificados;
• Determinar se é mantido um controle razoável sobre os erros durante o
processo de correção.
Para selecionar a ferramentas que vão atender ao projeto de teste é
necessário saber as características do aplicativo que será submetido para teste. No
site do PTS do DATASUS através do link: <http://pts.datasus.gov.br/PTS/default.ph
p?area=0302> foram indicadas as ferramentas que o laboratório de testes do
DATASUS dispõe com uma breve descrição do objetivo de cada uma delas.
Se possível citar os tipos de testes em ordem de prioridade/importância,
e o que não pode faltar?
34
Márcia: Não somos uma fábrica de teste por isso a prioridade/importância
está associada ao escopo do projeto de teste como também a necessidade do
cliente.
Também entramos em contato com a empresa Sicpa do Brasil, empresa
multinacional do ramo de tintas de segurança.
Pesquisa respondida por Sandro Santos Guimarães, Analista de Sistemas,
Arquiteto Java.
Quais são as Técnicas de testes mais utilizadas por sua equipe?
Márcia: Teste cruzado: onde um programador testa a tarefa de outro
programador.
Teste automatizado: criamos testes para a aplicação via código, onde
garantimos que qualquer alteração futura não interferirá no que já foi testado.
E se utilizam alguma ferramenta de automação de teste?
Márcia: Para testes básicos utilizamos JSFUNIT. E para os Testes
automatizados JUNIT.
5.1.2 Prefeitura de Santos
Em contato com Gabriel Rubens, estagiário em análise de Sistemas e Hélio
Rangel, Analista de Sistemas da prefeitura de Santos, eles nos informaram como
funciona o desenvolvimento e testes. Lá existem três equipes de desenvolvimento,
uma delas que é feita pela Unicamp (Universidade Estadual de Campinas) que é
uma parceira da prefeitura e outras duas são internas.
A Unicamp é responsável por uma parte do desenvolvimento e testes, ela
possui uma equipe de teste interna onde é feito o desenvolvimento dos sistemas que
ela terceiriza os serviços de testes de software, onde a empresa contratada apenas
informa os erros.
5.2 Pesquisas
Em um workshop que se discutia sobre Testes no Desenvolvimento de
Software realizado por uma parceria da APETI (Associação dos Profissionais e
35
Empresas de Tecnologia da Informação), com o ITS, (Instituto de Tecnologia de
Software), encabeçado por dois grandes profissionais de TI (Tecnologia da
Informação), Davi Yoshida (coordenador do Centro de Qualidade de Teste de
Software do ITS), e consultor em melhoria de processos de Software. E Roberto
Gavioli, Gerente de projetos na área de TI e Telecomunicações para grandes
empresas como SEMP Toshiba, Belgo Mineira e consultor do ITS em melhoria de
processos e gerência de projetos. Durante o evento eles argumentaram sobre a
importância de se fazer o planejamento de teste de software, passando por
condições similares às do cliente como:
• Ambiente,
• Interfaces,
• Massa de dados e etc.
”O planejamento do teste de software é um projeto dentro de outro projeto”,
resume o Palestrante Roberto Gavioli. (YOSHIDA, 2007)
5.3 Conclusão
Portanto, podemos afirmar que os testes mais utilizados variam para cada tipo
de aplicação, porém alguns testes não podem faltar, exemplo:
• Aceitação, que geralmente é executado por um grupo restrito de usuários
finais, simulando as rotinas reais da empresa, avaliando se o produto final
atende ou não os requisitos da empresa, avaliando se é aquilo que eles
esperavam;
• Caixa branca, um teste que verifica o comportamento interno do software,
agindo diretamente no código fonte, verificando o fluxo de dados, testando
os ciclos e os caminhos lógicos;
• Caixa Preta, que também é um teste funcional focado na entrada e saída
de dados, avaliando apenas o comportamento externo, fornecendo os
dados de entrada, executa e verifica se o teste e a saída estão aderentes
ao resultado esperado;
36
• Teste de “Stress”, sem dúvidas é muito utilizado, tanto para um sistema
local, web restrito (intranet) para os usuários de uma empresa, como para
um site de vendas onde não se pode prever o número de acessos ao
mesmo tempo;
Analisando a literatura, associada ao que foi dito nas entrevistas, podemos
afirmar que cada empresa acaba criando a sua própria metodologia de testes, com
suas técnicas e ferramentas de preferência e que atendam as necessidades de cada
software, não sendo uma regra utilizar uma ferramenta específica ou mesmo
técnica, vai depender do tipo de software, porque o importante é oferecer um
software de qualidade.
Para compreender o porquê de estes testes serem os mais utilizados nas
empresas, veremos no próximo capítulo a aplicação de três deles.
37
6. EXEMPLOS DE TESTES
6.1 Teste de Caixa Preta (Black Box)
Determina se o requisito foi total ou parcialmente satisfeito pelo produto. Se
preocupando apenas com os resultados produzidos, não como ele foi implementado.
Mostrando que as funções dos softwares são operacionais, que a entrada é
adequadamente aceita e a saída é corretamente produzida. (RATIONAL
SOFTWARE CORP)
Procurando descobrir os seguintes erros:
• Funções incorretas ou ausentes;
• Erros de interface;
• Erros nas estruturas de dados ou no acesso a bancos de dados externos;
• Erros de desempenho;
• Erros de inicialização e término.
Exemplo: testar o login desta pagina.
Figura 4: Tela do projeto de sistema Only Sony Games. Fonte: Projeto Aplicado do 3º Módulo desenvolvido pelo grupo01 dos alunos de Análise e
Desenvolvimento de Sistemas da Unimonte.
38
Os dados do login podem ser alfanuméricos (ex.: abc123) e senha somente
numérica (ex.: 123) com no máximo 8 dígitos cada.
Entradas válidas para login variando de AAAAAAAA até 99999999,
misturando entre letra e número (ex.: A5G83HQ0).
Saída válida para login: “Não cadastrado”, “Não é válido”, “Válido”.
Entradas válidas para senha variando se de 00000000 até 99999999.
Saída válida para senha: “Não cadastrado”, “Não é válido”, “Válido”.
Tabela 1: Massa de dados para teste.
Fonte: Própria.
Tabela 2: Teste realizado.
Entradas de dados Saídas de dados
Usuário Não
cadastrado
Não é válido
Válido
T1 Luiz Nakazone Login luiz_201 SIM SIM NÃO
Senha 15984672 SIM NÃO SIM
T2 Narciso Oliveira Login Narcisos NÃO NÃO SIM
Senha 17593460 NÃO NÃO SIM
T3 Paulo Henrique Login Phenri81 SIM NÃO SIM
Senha A7P4F6Q8 SIM SIM NÃO
T4 Rodrigo Alves Login ralves87 SIM NÃO SIM
Senha 94316708 SIM NÃO SIM
Fonte: Própria.
Resumo do teste:
T1: Luiz Nakazone login e senha não estão cadastradas, sendo o login não é
válido e senha é válida.
T2: Narciso Oliveira login e senha estão cadastradas, sendo o login e a senha
são válidas.
T3: Paulo Henrique login e senha não estão cadastradas, sendo o login é
válido e senha não é válida.
Massa e dados a ser testada Usuário Login Senha
Luiz Nakazone luiz_201 15984672 Narciso Oliveira Narcisos 17593460 Paulo Henrique Phenri81 A7P4F6Q8 Rodrigo Alves ralves87 94316708
39
T4: Rodrigo Alves login e senha não estão cadastradas, sendo o login e a
senha é válida.
6.2 Teste de Caixa Branca (White Box)
Demonstra possíveis imperfeições na estruturação interna do sistema, por
meio de testes que possam exercitar diversos caminhos de execução.
São testados os caminhos lógicos através do software, fornecendo-se casos
de teste que põem à prova conjuntos específicos de condições e os laços.
(RATIONAL SOFTWARE CORP)
Tabela 3: Caminhos percorridos.
Massa de dados a ser testada
Valores de entrada Caminho percorrido X = 2, Y = 2. 1;2;3;4;8;9. X = 10, Y = 5. 1;2;3;4;5;6;4;8;9. X = 3, Y = 5. 1;2;3;4;5;7;4;5;6;4;5;7;4;8;9.
Fonte: (RATIONAL SOFTWARE CORP).
Figura 5: Teste de Caixa Branca. Fonte: Própria.
40
6.3 Teste de Aceitação
Baseando se na idéia de um grupo de usuários finais terem feito uso de um
novo sistema que está sendo implantado, simulando situações reais do cotidiano do
trabalho.
Termo de Aceite nome do projeto
Versão: Beta
Responsável: nome/departamento
São Paulo, data
6.3.1 Objetivo
Este documento tem por objetivo registrar, junto ao cliente e ao gerente do
projeto, a conclusão e entrega final de cada fase ou do projeto como um todo.
6.3.2 Descrição do Produto Entregue
Descrever o produto, serviço ou fase do projeto que foi completada e/ou
entregue.
6.3.3 Resultados alcançados
Apresentar a lista de resultados alcançados com o produto e/ou fase do
projeto entregue.
6.3.4 Documentos relacionados ao aceite
Telas, plano de testes, funções, registros de homologação.
6.3.5 Registros (para projetos internos)
41
Tabela 4: Formulário para teste.
Dados Finais
Data de Início Data do termo de abertura da fase e/ou projeto
Data de Término Data de término da fase e/ou projeto
Recursos
(internos e
externos)
Quantidade de recursos alocados
Custo Total de horas consumidas ou custo HH total
Fonte: (CAMPOS, 2010).
6.3.6 Declaração do Aceite
Reconheço que a fase ABC e/ou o projeto Exemplo foi entregue
satisfatoriamente, atendendo minhas expectativas e alcançando os resultados
esperados. Sendo
assim, nada mais é devido e damos por concluída essa fase e/ou projeto
Exemplo.
Cliente:
_____________________________ Data: ____/____/____
Nome, área/departamento
Gerente do Projeto:
_____________________________ Data: ____/____/____
Nome, área/departamento
42
CONCLUSÃO
A realização desta pesquisa foi gratificante, nos deu conhecimento e alguma
experiência na área de teste de software. Com a pesquisa e estudo definimos que
quando falamos de teste, não se trata de uma metodologia, e sim de técnicas e
métodos. Os testes são importantes por vários motivos, como garantir a qualidade
do software, atender plenamente os requisitos do solicitante do software, encontrar
erros antes, durante e após o desenvolvimento do sistema, documentar os erros e
repará-los, entre outros.
Concluímos que o sistema desenvolvido com a utilização das técnicas de
software possui uma margem muito menor de falhas em relação ao que não utiliza
nenhuma. Não se pode esquecer jamais que não existe sistema perfeito, a aplicação
pode não retornar nenhuma falha, mas estar com seu código sujo, gerando as
informações corretamente, porém, em um tempo elevado. A utilização da técnica de
performance, unidade ou de stress ajudariam a identificar este elevado tempo de
processamento, o resultado seria uma melhora em seu desempenho, o que
responde claramente o problema de pesquisa proposto.
A utilização das técnicas de teste de software pode elevar o tempo de
desenvolvimento, porém, como explicado neste trabalho, mais diretamente nos
capítulos 3 e 4, os testes tem por objetivo apenas melhorar a qualidade. Esta
afirmação se aplica a qualquer sistema, existem testes específicos para qualquer
tipo de sistema, desde técnicas mais simples até as mais sofisticadas, que contam
com a utilização de software de terceiros.
Existem outros testes que não foram citados nesta pesquisa por questão de
tempo de desenvolvimento e estudo, porém, é um assunto muito interessante e
deveria ser tratado com maior ênfase em cursos de desenvolvimento, tudo para
gerar uma melhor prática.
43
REFERÊNCIAS
Livros
CRESPO, Adalberto Nobiato. Uma Metodologia para Teste de Software.
UNICAMP, 2004.
PRESSMAN, Roger S.. Engenharia de Software. Editora McGraw-Hill, Sexta
Edição, 2006.
PFLEEGER, Shari Lawrence. Engenharia de Software. Editora Prentice Hall,
Segunda Edição, 2007.
SOMMERVILLE, Ian. Engenharia de Software. Editora Prentice Hall, Sexta
Edição, 2003.
PAULA FILHO, Wilson de Pádua. Engenharia de Software: Fundamentos,
Métodos e Padrões. Editora LTC, Terceira Edição, 2009.
Sites
BADARÓ, Ruben. Como garantir Qualidade de Software?. Disponível em:
<http://imasters.uol.com.br/artigo/12181/desenvolvimento/como_garantir_qualidade_
de_software/>. Acesso em 20 de mar. de 2010.
CAETANO, Cristiano. Teste de Software for Dummies. Disponível em
<http://www.linhadecodigo.com.br/Artigo.aspx?id=1026>. Acesso em 1 de mar. de
2010.
CAMPOS, Fábio Martinho. Quais são as Reais Características da
Qualidade da NBR ISO/IEC 9126-1?. Disponível em <http://www.testexpert
.com.br/?q=node/126>. Acesso em 1 de mar. de 2010.
WTHREEX. Conceitos de teste de software. Disponível em <http://www.
wthreex.com/rup/portugues/process/workflow/tes/co_accte.htm>. Acesso em 13 de
mai. de 2010.
DATASUS, PTS. Processo de teste de software do departamento de
informática do SUS. Disponível em: <http://pts.datasus.gov.br/PTS/default.php?
area=01> Acesso em 23 de mar. de 2010.
44
ELIAS, Wagner. Testes de Segurança de Software (Tech-Ed 2008).
<http://wagnerelias.com/2008/10/28/testes-de-seguranca-de-software-tech-ed-
2008/>. Acesso em 20 de mar. de 2010.
FERNANDES, Jorge H. C.. As 10 Áreas da Engenharia de Software,
Conforme o SWEBOK. Disponível em: <http://www.cic.unb.br/~jhcf/MyBooks/iess/
Intro/10AreasDaEngenhariaDeSoftware.pdf>. Acesso em 14 de mar. de 2010.
IEEE. Guide to the Software Engineering Body of Knowledge (SWEBOK).
Disponível em <http://www.swebok.org>. Acesso em 15 de mar. de 2010.
MOCARATTI, José Carlos. Teste de desenvolvimento de software – Você
precisa disto? Disponível em <http://www.macoratti.net/tst_sw1.htm> Acesso em
25 de abr. 2010.
RAMOS, Ricardo Argenton. Engenharia de Software 1 – Aula 1. Disponível
em: <http://www.univasf.edu.br/~ricardo.aramos/disciplinas/ESI2009_2/Aula01.pdf>.
Acesso em 14 de mar. de 2010.
Técnicas de teste de software. Disponível em <http://www2.dem.inpe.br/ijar/
TesteSoftware1.html> Acesso em 24 de abr. de 2010.
Teste & Qualidade de Software. Disponível em: <http://qualidadebr.word
press.com/tag/teste-de-integracao/>. Acesso em 12 de abr. de 2010.
YOSHIDA, David. Workshop discuti Testes no Desenvolvimento de
Software. Disponível em: <http://apeti.org.br/asp/index.asp?ir=noticias.asp&Codi
go=108158>. Acesso em 23 de mar. de 2010.
