• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Projeto Aplicado 4°Ciclo Grp01 Testes De Software
 

Projeto Aplicado 4°Ciclo Grp01 Testes De Software

on

  • 1,349 views

Projeto Aplicado do 4°Ciclo ao qual fiz parte no curso de Analise e Desenvolvimento de Sistemas na Unimonte

Projeto Aplicado do 4°Ciclo ao qual fiz parte no curso de Analise e Desenvolvimento de Sistemas na Unimonte

Statistics

Views

Total Views
1,349
Views on SlideShare
1,347
Embed Views
2

Actions

Likes
1
Downloads
16
Comments
0

1 Embed 2

http://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Projeto Aplicado 4°Ciclo Grp01 Testes De Software Projeto Aplicado 4°Ciclo Grp01 Testes De Software Document Transcript

    • UNIMONTE GRADUSCURSO 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ãodevem ser ignoradas, uma delas é qualidade. A qualidade do software desenvolvidoé o ponto chave para o retorno a imagem do desenvolvedor ou da Empresaresponsável pelo desenvolvimento, sendo este retorno positivo ou muito negativo. Esta pesquisa foi desenvolvida pra tratar o principal tópico da qualidade desoftware que é o teste. Através dos testes é que iremos garantir a qualidade daaplicação desenvolvida e obter o retorno positivo ao responsável pelodesenvolvimento. Existem diversas técnicas para testar o software antes, durante eposteriormente ao desenvolvimento, cada um com sua especialidade. Existemtambém muitos aplicativos que auxiliam ou até mesmo realizam o teste retornando oresultado para que apenas seja analisado. O objetivo desta pesquisa é estudar e compreender a utilidade e importânciadas técnicas de testes realizados antes, durante e posteriormente aodesenvolvimento do sistema, explicando seu funcionamento para concluir como aaplicação de técnicas de teste de software pode melhorar a qualidade do sistemadesenvolvido.
    • LISTA DE FIGURASFIGURA 1: GRAFO DE FLUXO ............................................................. 18FIGURA 2: BIG-BANG ........................................................................ 20FIGURA 3: TESTE INCREMENTAL......................................................... 21FIGURA 4: TELA DO PROJETO DE SISTEMA ONLY SONY GAMES.............. 37FIGURA 5: TESTE DE CAIXA BRANCA. ................................................. 39
    • LISTA DE TABELASTABELA 1: MASSA DE DADOS PARA TESTE. .......................................... 38TABELA 2: TESTE REALIZADO. ............................................................ 38TABELA 3: CAMINHOS PERCORRIDOS. ................................................. 39TABELA 4: FORMULÁRIO PARA TESTE. ................................................. 41
    • SUMÁRIOINTRODUÇÃO ...................................................................................................................................................... 71. ENGENHARIA DE SOFTWARE .................................................................................................................... 92. TESTES DE SOFTWARE ............................................................................................................................. 12 2.1 CONCEITUAÇÃO .......................................................................................................................................... 12 2.2 UTILIDADE DOS TESTES .............................................................................................................................. 143. 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...................................................................................................................... 294. TESTES DE SEGURANÇA .......................................................................................................................... 305. 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 ............................................................................................................................................... 356. EXEMPLOS DE TESTES.............................................................................................................................. 37 6.1 TESTE DE CAIXA PRETA (BLACK BOX) ...................................................................................................... 37 6.2 TESTE DE CAIXA BRANCA (W HITE 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 ...................................................................................................................... 41CONCLUSÃO ...................................................................................................................................................... 42REFERÊNCIAS ................................................................................................................................................... 43
    • 7 INTRODUÇÃO Quando pensamos em desenvolvimento de softwares ou na Engenharia deSoftware propriamente dita, nos preocupamos com a qualidade do produto, por issologo pensamos nos testes de software. O teste enfatiza principalmente a avaliaçãoda qualidade do produto, podendo localizar, documentar e reparar erros. O objetivodesta pesquisa é tratar sobre o que são os testes, como eles surgiram, e também ostipos de teste que existem na atualidade, também mostrando suas finalidades e osmais utilizados no mercado. Mostraremos também alguns exemplos práticos parailustrar os processos dos testes de um software. O primeiro capítulo abordará a Engenharia de Software: como surgiu e omotivo. Este é considerado o ponto chave para o surgimento das técnicas desoftware. O capítulo seguinte conceitua teste de software e explica sua utilidade eimportância, também aborda a qualidade de produto de software que é umconhecimento importante para o desenvolvedor por tratar-se de uma norma. Nesta pesquisa foram reunidas diversas técnicas de teste estudadas queestã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 possuiruma importância superior aos testes tradicionais. Toda informação desta pesquisa partiu de livros, sites e abordagem aprofissionais de informática da área de desenvolvimento de sistemas. Utilizando daabordagem, foram realizadas entrevistas com algumas empresas com o objetivo desaber quais os testes que utilizam e tentar concluir quais os mais utilizados nomercado. O resultado está descrito no quinto capítulo e, no sexto são apresentadosexemplos de três dos testes estudados. Existem inúmeras técnicas ou métodos pra realizar os testes, cada um comsua finalidade, mas de modo geral sua principal finalidade é localizar e expor ospontos fracos do software, e com essas informações, os responsáveis peloplanejamento e desenvolvimento (o analista, programador, engenheiro e etc.) terãoas informações necessárias para corrigir os possíveis erros que podem ocorrerdurante o desenvolvimento ou futura alteração. Mais de um terço das falhaspoderiam ser evitados por testes de software e em média 50% dos erros só são
    • 8encontrados na produção. Por estes motivos os testes de software vêm sepopularizando cada vez mais no mercado.
    • 9 1. ENGENHARIA DE SOFTWARE A engenharia de software é uma área do conhecimento que nos oferece asmelhores técnicas para o desenvolvimento de software de qualquer natureza. Temcomo característica trazer para a área de TI (Tecnologia da Informação) osprincípios efetivos da engenharia com o propósito de obter um produto final desoftware de forma eficiente, confiável e econômica. Na engenharia propriamente ditajá temos estes conceitos; um exemplo prático para uma comparação é a construçãode um prédio: a engenharia é necessária para a criação do projeto, elaboração desua 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 dosoftware. A demanda de software exigida pelo mercado foi acima do esperado ehavia uma dificuldade extrema no desenvolvimento, ainda mais quando se tratavade 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 decombater todos os sintomas da crise diretamente. Ainda hoje, existe uma dificuldade muito grande em aplicá-la, pois é vistacomo muito complexa e metódica. Muitos desenvolvedores não visualizam suaaplicaçã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 dezitens que compreende o que podemos chamar de melhores práticas da engenhariade software. O guia chama-se SWEBOK (Software Engineering Body of Knowledge,em português – Corpo de Conhecimento da Engenharia de Software) e está divididonas 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 softwaree SWEBOK para que se entenda de onde surgiram os testes e o porquê de serdiretamente ligada a qualidade. Não é possível dizer exatamente como os testessurgiram, mas existem muitos relatos de que o surgimento foi exatamente após acriação da engenharia de software. Em entrevista com Mário Sérgio Rocha, professor da Instituição de EnsinoSuperior Unimonte que vivenciou este período da adequação da engenharia desoftware, perguntamos em qual momento passou a realizar técnicas de teste emsuas aplicações; o professor informou que sempre utilizou os chamados testes demesa para verificar a exatidão da informação em suas aplicações, mas lembra-seclaramente que as técnicas de testes e seus aprimoramentos surgiram mesmo apósa criação da engenharia de software. Nos tópicos a seguir, serão abordados os testes mais especificamente e sualigaçã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% durantetoda 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 funcionamentoem virtude do motivo no qual o sistema foi criado. Estes recursos são chamados detestes de software, que são uma parcela do que podemos agregar a qualidade desoftware. (CAMPOS, 2010) O que se espera de um sistema é o que consiste na ISO/IEC (InternationalStandards 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 estesitens, quando seguidos podem garantir a satisfação do cliente. A qualidade dosistema desenvolvido pode definir o futuro do desenvolvedor ou da empresaresponsável pelo desenvolvimento da aplicação, pois está ligada diretamente a suaimagem. Uma empresa que não obtém a satisfação do cliente por não atender aosrequisitos por ele especificados, por não possuir uma interface atraente ou de fácilmanipulação ou até mesmo por apresentar erros constantes, cria uma imagem
    • 13negativa no mercado. O desenvolvedor deve estar consciente dos termosapresentados pela norma de qualidade e respeitá-los, evitando vários problemasfuturos. (CAMPOS, 2010) Como já mencionado, nenhum sistema funciona ou funcionará perfeitamente,todo sistema possui algum tipo de problema. Muitos sistemas necessitam dealterações diárias para que estejam funcionando ao menos da forma que o usuáriodeseja, ou seja, estar de acordo com os requisitos do sistema, o que também nãogarante que estejam trabalhando corretamente. Alguns dos casos que levam osoftware 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 testessão, na verdade, um conjunto de métodos/técnicas e ferramentas específicas queauxiliam a encontrar erros e manter o sistema equivalente ao que foi requisitado. Os testes auxiliam no tratamento de riscos associados à performance e a tudoque se refere à qualidade de software, são trabalhados baseando-se na intuição, nocódigo, na especificação, na falha, no uso ou na natureza da aplicação. Existemtambém outras técnicas além destas mencionadas. No próximo sub-tópico será abordada mais especificamente a utilidade dostestes. (CAETANO, 2010)
    • 14 2.2 Utilidade dos testes O teste de software é uma fase do processo de Engenharia de Software quevisa 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 sejamcorrigidos pela equipe responsável. (CRESPO, 2004) O conceito de teste de software pode tanto ser analisado e compreendido deuma maneira formal, ou também de uma maneira mais intuitiva. De uma formasimplificada, testar um software significa verificar através de uma execuçãocontrolada 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 dosoftware, e é muito importante que estas informações sejam as mais completas eprecisas possível, pois elas vão servir de base para tomadas de decisões emrelação ao projeto que está sendo analisado. (CRESPO, 2004) Esses erros podem ser originados por diversos motivos. Um exemplo é umaespecificação que pode estar incompleta ou errada, ou até mesmo pode conterrequisitos impossíveis de serem implementados devido à limitação do software ouhardware. 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 defeitosem alguns aspectos do sistema desenvolvido. (CRESPO, 2004) Quanto mais cedo um defeito for encontrado no ciclo de vida de um softwareatravés de testes, mais barato é o custo de sua correção. De acordo com Myersautor do livro The Art of Software Testing (em português - A arte do teste desoftware), corrigir um erro no software que se propagou até o ambiente de produçãopode chegar a ser cem vezes mais caro do que corrigir e encontrar este mesmo erronas fases iniciais do projeto. Por isso um bom planejamento dessas atividades podesignificar economia para um projeto, visto que a identificação de erros no início dociclo 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, foielaborado este capitulo sobre tipos de testes de software. A importância dos testes durante o desenvolvimento do software quanto nafase de construção do projeto tem como um dos principais fatores prezar asespecificações do projeto e a qualidade do produto. Neste capítulo iremos conhecer quais são os principais testes utilizados nodesenvolvimento 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 aentrada e saída, a técnica de caixa-preta avalia o comportamento externo docomponente 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 deimplementação não são considerados, os casos de testes são todos derivados daespecificação. Quanto mais entradas são fornecidas, mais rico será o teste. Numa situaçãoideal 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 aosistema produzido e como resultado as entradas especificadas podem não ser asmesmas aceitas para o teste. Uma abordagem mais realista para o teste de caixa-preta é escolher umsubconjunto de entradas que maximize a riqueza do teste. Pode-se agruparsubconjuntos de entradas possíveis que são processadas similarmente, de formaque testar somente um elemento desse subconjunto serve para averiguar aqualidade de todo o subconjunto. Por exemplo: em um sistema que aceita um inteirocomo entrada, testar todos os casos possíveis pode gerar, pelo menos, dezenas demilhares de casos de testes distintos. Entretanto, a partir da especificação do sistema, pode-se encontrar umsubconjunto de inteiros que maximizem a qualidade do teste. Depende do propósitodo 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 umsistema e focalizar apenas as saídas geradas em reposta a entradas e condições deexecução selecionada. (PAULA FILHO, 2009) Essa técnica é aplicável a todas as fases de teste – teste unitário, teste deintegração, teste de sistema e teste de aceitação. A aplicação de técnicas de testeleva 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 deequivalência (ou uso de classes de equivalência) permite avaliar se a quantidade de
    • 17casos de teste produzida é coerente. A partir das classes de equivalênciaidentificadas, o testador construirá casos de teste que atuem nos limites superiores einferiores destas classes, de forma que um número mínimo de casos de testepermita a maior cobertura de teste possível. Uma abordagem no desenvolvimento do teste de caixa-preta é o testebaseado na especificação, de forma que as funcionalidades são testadas de acordocom os requisitos. Apesar de necessário, esse tipo de teste é insuficiente paraidentificar 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 umsoftware. Referido teste leva em conta os mecanismos internos de um sistema oucomponente. 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); Testede caixa transparente (glass-box testing). A caixa branca é uma técnica que trabalha diretamente sobre o código fontedos componentes do programa para que seja possível serem avaliados alguns dosprincipais 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 doprograma, como comandos ou desvios para determinar quais estruturas sãonecessários. Os critérios mais conhecidos dessa classe são TODOS-NÓS, queexige que a execução do programa passe, no mínimo, uma vez em cada vértice dografo de fluxo, ou seja, que cada comando do programa seja executado pelo menosuma vez.
    • 18 Grafo de fluxo é uma forma de visualizar o fluxo de controle lógico, usando anotação de uma forma ilustrada na figura. O grafo de fluxo permite seguir maisfacilmente 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 doprograma para determinar os requisitos de teste. Esses critérios exploram asinterações que envolvem definições de variáveis e referências a tais definições paraestabelecerem os requisitos de teste. O método fluxo de dados seleciona caminhos de teste de software de acordocom 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 acomplexidade do programa para derivar os requisitos de teste. Um critério bastanteconhecido dessa classe é o critério de McCabe, que utiliza a complexidadeciclomática do grafo de programa para derivar os requisitos de teste.
    • 19Essencialmente, esse critério requer que um conjunto de caminhos linearmenteindependentes do grafo de programa seja executado. A complexidade ciclomática é uma métrica útil para previsão dos módulos queprovavelmente sejam propensos a erro. Ela pode ser usada tanto para planejamentode 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 testadosindividualmente. O Teste em tela é uma atividade sistemática aplicada durante a integração daestrutura do software, visando analisá-la em busca de erros associados àsInterfaces entre os módulos. O objetivo do Teste é verificar os módulos testados no nível de unidade econstruir a estrutura do software que foi estipulado no projeto. Nesse Teste, os componentes são combinados e avaliados para testar aintegração entre eles. (PAULA FILHO, 2009) O conceito da técnica sistemática para estrutura do software realizando testespara 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 testadosisoladamente 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 stubse drivers para testar os módulos isoladamente. Stubs é um Proxy para os objetos remotos no lado cliente, e skeleton seriamesses Proxy no lado do servidor. Os Stubs repassam os métodos invocados docliente remoto para os skeletons, que seriam os servidores. O skeleton devolve oresultado para o cliente, através dos stubs. Drivers é um software que gere a comunicação entre um software e umhardware, para que eles possam se entender. A vantagem de utilizar essa estratégia de teste encontra-se na eficiência emrelação a sistemas de pequeno e médio porte. A desvantagem, por sua vez, surge nos casos em que ocorra alguma falha nainterface de um modulo com outro, uma vez que será difícil ser preciso ao encontrara 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. Osmó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 osmódulos vão se integrando com os módulos já existentes e testados para gerarmaiores módulos. O conceito é concluir todas as etapas de testes, nas quais osdesenvolvedores vão efetuando correções, de acordo com os erros que foremsurgindo e, assim, até concluir todas as etapas. O exemplo clássico de uma abordagem incremental ocorre freqüentementena fabricação de bolos. Como qualquer confeitaria, antes de colocar a massa noforno, esta é degustada e, antes de colocar a cobertura, verifica-se sua consistênciae sabor. Outro exemplo de integração incremental são as atividades que sãointegradas durante as fases de testes. Figura 3: Teste Incremental Fonte: Própria Uma das principais vantagens de se utilizar a estratégia incremental está emnão precisar esperar até que todo o sistema esteja pronto para iniciar os testes. Aspossibilidades de falhas no projeto são menores, uma vez que os módulos sãoverificados antes e, dessa forma, é possível fazer a correção de possíveis falhasencontradas. A desvantagem é que, por se tratar da integração de todos os módulos, acabase 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 cimapara baixo’ –, é uma técnica que funciona do nível mais alto ao mais baixo, como opróprio nome diz. De forma hierárquica, ele começa por um controle principal epassa gradativamente, de forma seqüencial entre os outros módulos subordinados. O teste de integração top-down é uma abordagem incremental para aconstruçã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 dahierarquia do sistema é testado individualmente. Os próximos componentes a seremincluídos nos testes são aqueles que chamam os que foram previamente testados.Essa abordagem é seguida repetidamente, até que todos os componentes sejamincluídos no teste. Ao contrário da top-down, a integração do sistema começa a partir do nívelmais baixo do software, ou seja, o módulo. O módulo é classificado como o maisbaixo nível se ele não depende de outro módulo. A Bottom-Up assume que todos osmódulos foram individualmente testados antes. Para integrar um conjunto de módulos usando a Bottom-Up, nós precisamosconstruir um driver (controlador) que chamará o módulo a ser integrado. Uma vezque a integração de um grupo de baixo nível de módulos tenha sido considerasatisfatória, o driver irá substituir o atual módulo e um, ou mais drivers, serão usadospara integrar mais módulos com um conjunto de módulos já integrados. O processode 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, estacamada é 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 devista 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 dosoftware. Porém, existem alguns pontos que devem ser observados, senão vejamos: noteste de níveis superiores da estrutura do programa forem integrados de cima parabaixo, o numero de drivers pode ser reduzido substancialmente na integração dosmódulos inferiores, já nos teste inferiores, o numero de clusters (módulos queexecutam uma sub-função do sistema) pode ser reduzido substancialmente naintegraçã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 averificação de erros existentes nas unidades de projeto do mesmo. De certa forma, oteste de unidade é um meio de teste de caixa branca, onde pode ser realizado emparalelo sobre diferentes módulos. Lembrando que o teste de unidade não corrigeerro, 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 serocasionados por hardware, software, peopleware (usuário) e dados. O teste de sistema inclui diversas modalidades de teste, cujo objetivo é testaro sistema computacional como um todo. Um problema clássico de teste de sistemas é ser “dedo-duro”. Isso acontecequando algum erro ocorre e os desenvolvedores que codificam parte do softwarealegam culpa alheia, nunca assumindo a responsabilidade. Para evitar que issoocorra, a engenharia de software deve antecipar possíveis causas do problema deinterface. 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 adequadamentepara 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 umaunidade de software. Ele deve ser realizado em primeiro lugar, pois qualquerproblema observado durante a execução deste põe em dúvida os resultados obtidosnos demais testes sobre a mesma unidade. Durante sua realização, devem serobservados 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 dedispositivos periféricos devem ser cuidadosamente (ou exaustivamente) verificadas. 3.7 Teste Funcional O teste do sistema começa com o teste funcional. Enquanto os testesanteriores se concentravam nos componentes e em suas interações, essa primeiraetapa 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, aentrada é 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 deprodução e é conduzido diretamente pelos administradores do ambiente final emque o sistema entrara em produção. Nessa fase de teste são efetuadas váriassimulações como a instalação do software ou uma copia de segurança dos dadosentre outras, que visam garantir que o sistema ao entrar em ambiente de produçãogarantira 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 trabalhadosos fluxos de execução, o acesso direto aos dados no banco e todas as chamadas eexecuçõ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 sistemaexercitando um conjunto adequado de instruções. Este teste, geralmente mede astaxas de transferência de dados das cargas de execução da aplicação, ou seja, otrabalho que está sendo executado. São calculados e relatados os valores tolerantespara a operação. 3.11 Teste de Volume Este teste é destinado a realizar a verificação a capacidade da aplicação emtratar um volume alto de dados. Seus parâmetros principais são a entrada e saídade dados ou dados tratados diretamente em seu banco. Este teste requer uma estratégia teoricamente simples, como utilizar entradade dados em seu volume máximo em cada um dos campos ou, até mesmo, forçar
    • 27situações em que um relatório retorne um volume enorme de dados do bancocausando 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 limitepor um pequeno período. Se os requisitos definem que um sistema deve lidar com até um númeroespecificado de dispositivos ou usuários, um teste de estresse avalia o desempenhodo sistema quando todos esses dispositivos ou usuários estiverem ativossimultaneamente. Este teste é muito importante para sistemas que geralmenteoperam abaixo de sua capacidade máxima, mas que são severamente forçados emcertos 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 pelobanco 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 dohardware e do sistema operacional. 3.13 Teste de Aceitação Os testes de aceitação são testes formais, que são conduzidos paradeterminar se um software satisfaz ou não os critérios de aceitação correspondentese 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, nospadrõ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 costumaser uma extensão do teste de sistema. Os testes são projetados e planejados com omesmo cuidado e alto nível de detalhe do teste de sistema e os casos de testesescolhidos devem ser um subconjunto dos que foram realizados anteriormente noteste de sistema. É muito importante não se distanciar de nenhuma forma dos casosde testes escolhidos. O teste, em algumas organizações é executado diretamente pela organizaçãodo 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 nasua definição como no teste formal. As tarefas de negócios e suas funções a seremexploradas são identificadas e documentadas, porém não existe caso de teste paraseguir, 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 testeformal. (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 testadore responsável por criar o próprio ambiente, selecionar os dados correspondentes edeterminar as funções a serem exploradas e identificar os próprios critério que olevarão a aceitar ou não o software. O teste beta geralmente é implementado por usuários finais, com pouco ounenhum 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ãoproposital de erros como forma de revelar erros existentes previamente. Esse testefornece indicadores que possibilitam o melhor gerenciamento do processo de teste.(PRESSMAN, 2006) Dentro do Teste Baseado em Erros, existem dois tipos de segmentos deteste, 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 doprograma para logo após realizar um caso de teste para se verificar quais são oserros naturais e erros artificiais dentro do programa. Assim seguindo como base aproporção de erros naturais/artificiais encontrados no código do programa é possívelestimar a quantidade de erros remanescentes para o conjunto de caso de testedefinidos 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 docódigo que esta funcionando perfeitamente geram-se programas com pequenasmodificações no código chamados de programas mutantes (M). Esses programasmutantes (M) são verificados em relação ao caso de teste (T), caso a verificação deM apresentar algum resultado diferente a do código original P o mutante é“descartado” caso contrario se o programa M não apresentar resultados diferentesde 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 nodesenvolvimento de uma aplicação, pois servem para garantir a confidencialidade,integridade e disponibilidade das informações que serão tratadas pelo software, oque não é garantido pelos testes de softwares “tradicionais”, que buscam apenasgarantir a qualidade e funcionalidade dos requisitos do software a ser desenvolvido.Estes tipos de testes garantem que requisitos de segurança de software sejamseguidos, mesmo quando estes requisitos não fazem parte das especificaçõesfuncionais. (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 desegurança e, se colocam, não são aplicados corretamente, ocasionando assimfuturas falhas em seu sistema desenvolvido, abrindo brechas para possíveis ataqueshackers, vazamento de informações sensíveis a organização e até o paralizamentototal da aplicação. Mas, três problemas relacionados à segurança de software estãoentre 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 deserem detectadas, se durante o projeto os testes de segurança forem bemaplicados, tornando assim um software com qualidade e também seguro. (IMASTERS, 2008) Conhecendo tantos testes, precisamos identificar quais são mais aplicadosnas empresas atualmente, para tanto, foram realizadas entrevistas com profissionaisda á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 fazeralgumas pesquisas e entrevistas com profissionais que atualmente, trabalham nodesenvolvimento software. Toda empresa que está desenvolvendo seu software,tem por premissa que ele funcione perfeitamente, atendendo os requisitos funcionaise não contendo erros. Passamos a observar primeiramente as empresas onde trabalhamos, ecomeçamos a perceber que por mais que as empresas queiram um software semerros, a maioria delas não adotou um padrão para os testes, ou seja, não utilizamum procedimento único, com metodologias e técnicas de testes de software. Issonão quer dizer que elas não testam, e nem se preocupam com a qualidade doproduto final. O fato é que as técnicas de testes ainda são uma área muito nova nomercado da tecnologia, faltando até mesmo mão de obra qualificada. E nissoobservamos 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 nosatenderam, falando sobre seus processos de testes. Enviamos alguns questionáriose com essas respostas obtivemos informações que nos ajudaram a formar umaopiniã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 deSoftware).
    • 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 suaequipe? Márcia: As técnicas de testes e as ferramentas normalmente estãodiretamente 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ênciasentre os requisitos especificados na documentação versus os requisitosimplementados na aplicação. O objetivo desta técnica é determinar se o sistema é executado conformeespecificado e técnica de “Stress de Campos” determina a capacidade que osistema tem para tratar as transações incorretas apropriadamente. Os objetivos daté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. Nosite do PTS do DATASUS através do link: <http://pts.datasus.gov.br/PTS/default.php?area=0302> foram indicadas as ferramentas que o laboratório de testes doDATASUS 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ânciaestá associada ao escopo do projeto de teste como também a necessidade docliente. Também entramos em contato com a empresa Sicpa do Brasil, empresamultinacional 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 outroprogramador. Teste automatizado: criamos testes para a aplicação via código, ondegarantimos 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 Testesautomatizados JUNIT. 5.1.2 Prefeitura de Santos Em contato com Gabriel Rubens, estagiário em análise de Sistemas e HélioRangel, Analista de Sistemas da prefeitura de Santos, eles nos informaram comofunciona 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, elapossui uma equipe de teste interna onde é feito o desenvolvimento dos sistemas queela terceiriza os serviços de testes de software, onde a empresa contratada apenasinforma os erros. 5.2 Pesquisas Em um workshop que se discutia sobre Testes no Desenvolvimento deSoftware realizado por uma parceria da APETI (Associação dos Profissionais e
    • 35Empresas de Tecnologia da Informação), com o ITS, (Instituto de Tecnologia deSoftware), encabeçado por dois grandes profissionais de TI (Tecnologia daInformação), Davi Yoshida (coordenador do Centro de Qualidade de Teste deSoftware do ITS), e consultor em melhoria de processos de Software. E RobertoGavioli, Gerente de projetos na área de TI e Telecomunicações para grandesempresas como SEMP Toshiba, Belgo Mineira e consultor do ITS em melhoria deprocessos e gerência de projetos. Durante o evento eles argumentaram sobre aimportância de se fazer o planejamento de teste de software, passando porcondiçõ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 tipode 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, podemosafirmar que cada empresa acaba criando a sua própria metodologia de testes, comsuas técnicas e ferramentas de preferência e que atendam as necessidades de cadasoftware, não sendo uma regra utilizar uma ferramenta específica ou mesmotécnica, vai depender do tipo de software, porque o importante é oferecer umsoftware de qualidade. Para compreender o porquê de estes testes serem os mais utilizados nasempresas, 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. Sepreocupando 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. (RATIONALSOFTWARE 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 somentenumé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. 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 Fonte: Própria. Tabela 2: Teste realizado. Entradas de dados Saídas de dados Não Não é Usuário Válido cadastrado válidoT1 Luiz Nakazone Login luiz_201 SIM SIM NÃO Senha 15984672 SIM NÃO SIMT2 Narciso Oliveira Login Narcisos NÃO NÃO SIM Senha 17593460 NÃO NÃO SIMT3 Paulo Henrique Login Phenri81 SIM NÃO SIM Senha A7P4F6Q8 SIM SIM NÃOT4 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.
    • 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, pormeio de testes que possam exercitar diversos caminhos de execução. São testados os caminhos lógicos através do software, fornecendo-se casosde 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 umnovo sistema que está sendo implantado, simulando situações reais do cotidiano dotrabalho. 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 doprojeto, 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/ouentregue. 6.3.3 Resultados alcançados Apresentar a lista de resultados alcançados com o produto e/ou fase doprojeto 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 FinaisData de Início Data do termo de abertura da fase e/ou projetoData de Término Data de término da fase e/ou projetoRecursos Quantidade de recursos alocados(internos eexternos)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 entreguesatisfatoriamente, atendendo minhas expectativas e alcançando os resultadosesperados. Sendo assim, nada mais é devido e damos por concluída essa fase e/ou projetoExemplo. 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 algumaexperiência na área de teste de software. Com a pesquisa e estudo definimos quequando falamos de teste, não se trata de uma metodologia, e sim de técnicas emétodos. Os testes são importantes por vários motivos, como garantir a qualidadedo software, atender plenamente os requisitos do solicitante do software, encontrarerros antes, durante e após o desenvolvimento do sistema, documentar os erros erepará-los, entre outros. Concluímos que o sistema desenvolvido com a utilização das técnicas desoftware possui uma margem muito menor de falhas em relação ao que não utilizanenhuma. Não se pode esquecer jamais que não existe sistema perfeito, a aplicaçãopode não retornar nenhuma falha, mas estar com seu código sujo, gerando asinformações corretamente, porém, em um tempo elevado. A utilização da técnica deperformance, unidade ou de stress ajudariam a identificar este elevado tempo deprocessamento, o resultado seria uma melhora em seu desempenho, o queresponde claramente o problema de pesquisa proposto. A utilização das técnicas de teste de software pode elevar o tempo dedesenvolvimento, porém, como explicado neste trabalho, mais diretamente noscapítulos 3 e 4, os testes tem por objetivo apenas melhorar a qualidade. Estaafirmação se aplica a qualquer sistema, existem testes específicos para qualquertipo de sistema, desde técnicas mais simples até as mais sofisticadas, que contamcom a utilização de software de terceiros. Existem outros testes que não foram citados nesta pesquisa por questão detempo de desenvolvimento e estudo, porém, é um assunto muito interessante edeveria ser tratado com maior ênfase em cursos de desenvolvimento, tudo paragerar 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, SextaEdição, 2006. PFLEEGER, Shari Lawrence. Engenharia de Software. Editora Prentice Hall,Segunda Edição, 2007. SOMMERVILLE, Ian. Engenharia de Software. Editora Prentice Hall, SextaEdiçã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. de2010. CAMPOS, Fábio Martinho. Quais são as Reais Características daQualidade 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 demai. de 2010. DATASUS, PTS. Processo de teste de software do departamento deinformá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 em25 de abr. 2010. RAMOS, Ricardo Argenton. Engenharia de Software 1 – Aula 1. Disponívelem: <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.wordpress.com/tag/teste-de-integracao/>. Acesso em 12 de abr. de 2010. YOSHIDA, David. Workshop discuti Testes no Desenvolvimento deSoftware. Disponível em: <http://apeti.org.br/asp/index.asp?ir=noticias.asp&Codigo=108158>. Acesso em 23 de mar. de 2010.