Captulo 1

CONCEITOS BSICOS DE TESTE DE SOFTWARE

Viso histrica da execuo dos testes Demonstrao dcada de 70 Garantir que o produto funciona; Testes feitos pelos desenvolvedores. Deteco dcada de 80/90 Garantir que o produto atende aos requisitos; Testes feitos pelos desenvolvedores e usurios Preveno dcada de 90/00 Garantir que o produto funciona, atende aos requisitos e no tem defeitos; Testes feitos pelos desenvolvedores, usurios e testadores.

Nas dcadas de 1960 e 1970, os desenvolvedores dedicavam a maior parcela dos seus esforos nas atividades de codificao e nos testes unitrios. Estima-se que 80% desse esforo era despendido nessas atividades. Uma parcela menor era dedicada integrao dos programas e nos testes dos sistemas. As atividades de teste eram consideradas um mal necessrio para provar aos usurios que os produtos funcionavam e no eram tratadas como um processo formal alinhado com as atividades do processo de desenvolvimento de sistemas (tambm poucas vezes tratado como processo). A partir dos anos 1980, durante o processo de desenvolvimento, passou a ser dada maior importncia analise dos requisitos, ao desenho funcional e tcnico dos novos sistemas. Um esforo maior passou a ser dedicado integrao das diversas peas que compunham os softwares e ao teste destes para funcionarem como um sistema. As atividades de teste passaram a ser tratadas como processo formal, aparecendo as Metodologias de Teste que evoluram at os dias de hoje. Nos ltimos anos, com a utilizao da Internet para a realizao de negcios, houve uma mudana significativa na abrangncia e complexidade das aplicaes, onde fatores, tais como segurana e performance passam a ser relevantes, tornando a atividade de testar cada vez mais especializada.

O que teste de software

Existem diversas definies para teste de software: avaliar se o software est fazendo o que deveria fazer, de acordo com os seus requisitos, e no est fazendo o que no deveria fazer;

 processo de executar um programa ou sistema com a inteno de encontrar defeitos (teste negativo) (Glen Myers 1979); qualquer atividade que a partir da avaliao de um atributo ou capacidade de um programa ou sistema seja possvel determinar se ele alcana os resultados desejados (Bill Hetzel 1988). Muitas outras definies poderiam ser ainda citadas, mas em essncia, teste de software o processo que visa a sua execuo de forma controlada, com o objetivo de avaliar o seu comportamento baseado no que foi especificado. A execuo dos testes considerada um tipo de validao. Na prtica, no se pode testar um programa completamente e garantir que ele ficar livre de bugs. quase impossvel testar todas as possibilidades de formas e alternativas de entrada de dados, bem como testar as diversas possibilidades e condies criadas pela lgica do programador. Segundo uma estimativa de Beizer (1990), a mdia do nmero de defeitos em programas liberados para testes de 1 a 3 por 100 instrues executveis. Claro, existem diferenas entre programadores, porm uma coisa certa, todos eles cometem erros em grau maior ou menor. Se no se podem descobrir todos os defeitos de um programa e em conseqncia nunca se pode afirmar que ele est 100% correto, por que testar? Porque o propsito dos testes descobrir e corrigir os problemas e com isto melhorar a sua qualidade. O quanto se quer melhorar depender de quanto se deseja investir. A qualidade do software depende tambm do investimento feito no processo de testes. Um software mal testado poder custar caro (e muito) para a organizao. Dentro do processo de teste existem tambm as tcnicas de verificao, tais como: inspeo, reviso de produtos e walkthroughs. Estas tcnicas baseadas em reunies e check-lists servem para identificar defeitos de elaborao, descumprimento de padres e das boas prticas. Devem ser realizados em documentos produzidos, planos, cdigos, especificaes, requisitos etc., preferencialmente antes da execuo dos testes. Estas tcnicas, usadas de forma combinada com os testes, aumentam sensivelmente a qualidade final dos softwares desenvolvidos.
NOTA

Para uma discusso mais completa sobre Validao e Verificao consultar o IEEE Standard for Software Verification and Validation Plans (ANSI/IEEE Standard 1012-1986).

O texto abaixo foi tirado de um documento sobre CMMI e mostra algumas diferenas sobre Verificao e Validao conforme tratamos anteriormente: As reas de processo Validao e Verificao so aquelas dentro do contexto do prprio objetivo da rea de teste. Verificao cobre os testes unitrios, de integrao e de sistemas. Validao cobre os testes de aceitao. Neste ltimo caso importante evidenciar que a equipe de testes participa tambm dos testes de aceitao. Lembramos tambm que o teste de sistema repete tambm o teste de integrao executado com um

nvel de detalhes maior. Alm disso temos o contexto das inspees e revises que so feitas pela equipe de teste de software nos seus prprios artefatos ou nos artefatos criados pela equipe de desenvolvimento. Em resumo a validao se refere exclusivamente ao teste de aceitao e verificao aos testes unitrio, de integrao e de sistemas. Realmente as inspees tcnicas e revises esto no processo de verificao tambm sob o enfoque do modelo CMMI.

O processo de teste
O processo de teste deve basear-se em uma metodologia aderente ao processo de desenvolvimento, em pessoal tcnico qualificado, em ambiente e ferramentas adequadas. A metodologia de teste deve ser o documento bsico para organizar a atividade de testar aplicaes no contexto da empresa. Como indesejvel o desenvolvimento de sistemas sem uma metodologia adequada, tambm acontece o mesmo com as atividades de teste. O desenho da Figura 1.1 mostra as fases de um ciclo de vida num processo de testes:
FIGURA 1.1

Procedimentos iniciais Elaborao do documento Guia Operacional de Testes (GOT), ou seja, o estabelecimento de um acordo entre as partes envolvidas no projeto de teste (usurio, desenvolvimento, teste e produo) para a definio dos seguintes assuntos: objetivo do projeto de teste, pessoal a ser envolvido (desenvolvimento, equipe de testes e usurios), as responsabilidades de cada um, o plano preliminar de trabalho, a avaliao dos riscos, os nveis de servio acordados e qualquer item considerado relevante pelo responsvel das atividades de teste para garantir o sucesso do projeto. Planejamento Elaborao e reviso da Estratgia de Testes e do Plano de Teste. Preparao - Preparao do ambiente de teste, incluindo equipamentos, rede, pessoal, software e ferramentas.

Especificao - Elaborao e reviso dos Casos de Teste, scripts ( no caso de uso de ferramentas de automao de testes) e dos Roteiros de Teste e execuo dos testes de verificao da documentao do sistema (testes estticos). Execuo Execuo dos testes planejados conforme os Casos de Teste, scripts (no caso de uso de ferramentas de automao de testes) e dos Roteiros de Teste com os correspondentes registros dos resultados obtidos. Entrega - Concluso do processo de testes com a entrega do sistema para o ambiente de produo. Outro aspecto importante que deve ser considerado a forma como os processos de desenvolvimento de sistemas e de testes interagem. De qualquer forma tenha em mente que o ciclo de vida mostrado apenas um exemplo e que existem outros ciclos de vida para o processo de teste. Ou seja, poderemos encontrar denominaes diferentes para as mesmas atividades ou fases. Na Tabela 1.2 mostrado o paralelismo entre as fases dos dois processos. Tabela 1.2
PROCESSO DE TESTE Planejamento PROCESSO DE DESENVOLVIMENTO Planejamento do projeto de desenvolvimento AES REQUERIDAS Integrao dos planos Preparao da estratgia de testes e planos de testes Reviso dos planos de testes Elaborao e reviso dos casos de teste e dos roteiros de teste Atualizao do plano do projeto de desenvolvimento Execuo Construo Busca de defeitos e correes Validao (Testes) e Verificao (Revises/ Walkthrough/ Inspeo Validao (Testes) e Verificao (Revises/ Walkthrough/ Inspeo VERIFICAO /VALIDAO Verificao (Revises/ Walkthrough/ Inspeo)

Especificao

Projeto lgico e fsico

Verificao (Revises/ Walkthrough/ Inspeo)

Execuo

Implantao

Busca de defeitos e correes

Como regra geral, os planejadores de projetos de desenvolvimento de sistemas devem considerar 50% a 75% do custo de desenvolvimento para as atividades de garantir que os programas funcionaro satisfatoriamente nos termos das suas especificaes funcionais e no funcionais e dentro do ambiente estabelecido na entrega, atravs do apropriado processo de depurao, testes e atividades de verificao . (Hallpern and Santhanam, 2002). Uma outra viso da integrao dos dois processos pode ser vista na Figura 1.3.

FIGURA 1.3

O grande destaque da Figura 1.3 mostrar a importncia da Gerncia de Requisitos em ambos os processos.

A importncia dos testes

Conforme Boehm (1976), quanto mais tarde um defeito for identificado mais caro fica para corrigi-lo e mais ainda, os custos de descobrir e corrigir defeitos no software aumentam exponencialmente na proporo que o trabalho evolui atravs das fases do projeto de desenvolvimento. Um outro aspecto que devemos considerar o papel dos testes na manuteno dos sistemas. Uma grande parcela do oramento de TI das organizaes dedicada manuteno dos softwares aps eles entrarem em produo.

A maioria dos testes feitos durante a manuteno so os mesmos que foram feitos durante o desenvolvimento. Neste momento devem ser aplicados os Testes de Regresso, preferencialmente se automatizados, todas as vezes que os programas , mudarem. Fica evidente que: Quanto melhores forem os testes feitos durante o desenvolvimento, menores sero os custos de manuteno; As manutenes solicitadas pelos usurios so fontes de novos defeitos, inclusive gerando problemas em partes do programa que no foram modificados. Para identificar estas situaes, sempre deve ser aplicados os dificados. devem Testes de Regresso completos, evitando testar apenas as modificaes realizadas; Certos testes, tais como o de carga em ambiente Web, s podem ser realizados com auxilio de ferramentas de automao de testes, pois possuem ferramentas a capacidade de simular o ambiente real, muito difcil de ser realizado por pessoas; Quanto mais especializada e independente a equipe de testes, tanto melhor ser a qualidade do sistema e menor o custo total.

Dimenso dos testes

Figura 1.4 A Figura 1.4 mostra as dimenses do teste que est dividida em:

Tipos de teste; Niveis de Teste; Tcnica de teste.

Tcnicas de teste Testes Caixa Preta (Black Box): visam verificar a funcionalidade e a aderncia aos requisitos, em uma tica externa ou do usurio, sem se basear em qualquer conhecimento do cdigo e da lgica interna do componente testado. Testes Caixa Branca (White Box): visam avaliar as clusulas de cdigo, a lgica interna do componente codificado, as configuraes e outros elementos tcnicos. Estgios (ou Nveis) de teste Testes unitrios: estgio mais baixo da escala de testes e so aplicados nos menores componentes de cdigo criados, visando garantir que estes atendem as especificaes, em termos de caractersticas e funcionalidade. Os testes unitrios verificam o funcionamento de um pedao do sistema ou software isoladamente ou que possam ser testados separadamente, podendo, inclusive, ser um programa ou um componente. Na grande maioria dos casos estes testes so realizados pelos desenvolvedores. Testes de integrao: so executados em uma combinao de componentes para verificar se eles funcionam corretamente juntos, conforme as especificaes. Componentes podem ser pedaos de cdigo, mdulos, aplicaes distintas, clientes e servidores etc. Normalmente feito pelos desenvolvedores. Testes de sistema: so realizados pela equipe de testes, visando a execuo do sistema como um todo ou um subsistema (parte do sistema), dentro de um ambiente operacional controlado, para validar a exatido e perfeio na execuo de suas funes. Neste estgio de testes deve ser simulada a operao normal do sistema, sendo testadas todas as suas funes de forma mais prxima possvel do que ir ocorrer no ambiente de produo. So usados dados de teste e situaes de teste de modo a tentar evitar a ocorrncia de defeitos em ambiente de produo. Esses testes so feitos pela equipe de teste de software. Testes de aceitao: so os testes finais de execuo do sistema, realizados pelos usurios, visando verificar se a soluo atende aos objetivos do negcio e a seus requisitos, no que diz respeito funcionalidade e usabilidade, antes da utilizao no ambiente de produo. Os testes, embora sejam de responsabilidade dos usurios, so conduzidos com total suporte da equipe de testes e da equipe do projeto. Tipos de testes Testes de regresso: visam a garantir que o software permanea intacto depois de novos testes serem realizados. Um conjunto de dados e scripts deve ser mantido como baseline e executado para verificar que mudanas introduzidas posteriormente no danificaro cdigos j considerados bons e aceitos. Os resultados esperados a partir do baseline devem ser comparados aos resultados aps as mudanas. As discrepncias devem ser resolvidas antes de atingir o prximo nvel de testes. Testes de carga: visam a avaliar a resposta de um software sob uma pesada carga de dados ou uma grande quantidade de usurios simultneos para verificar o nvel de escalabilidade, ou seja, o momento onde o tempo de resposta comea a degradar ou a aplicao comea a falhar.

Estes testes devem ser aplicados durante os testes de sistema e so chamados de testes de estresse. Testes Back-to-back: o mesmo teste executado em verses diferentes do software e os resultados so comparados. Testes de Configurao: verificam se o software est apto a rodar em diferentes verses ou configuraes de ambientes (hardware e software), como, por exemplo, diversos browsers ou verses de browsers. Testes de Usabilidade: verificam o nvel de facilidade de uso do software pelos usurios. Deve ser efetuado principalmente em aplicaes Web, onde existe muita navegao entre pginas. As telas de ajuda devem ser avaliadas quanto ao seu contedo e clareza de linguagem, assim como as mensagens de erro. Testa-se tambm os links para outras pginas. Testes de Instalao: verificam o processo de instalao parcial, total ou a atualizao do aplicativo. Testes de Segurana: validam a capacidade de proteo do software contra acesso interno ou externo no autorizado. Testes de Recuperao: validam a capacidade e qualidade da recuperao do software aps crashes, falhas de hardware ou outros problemas catastrficos. Testes de Compatibilidade: validam a capacidade do software de executar em um particular ambiente de hardware/software/sistema operacional/rede etc. Testes de Desempenho: visam garantir que o sistema atende aos nveis de desempenho e tempo de resposta acordados com os usurios e definidos nos requisitos. So tambm chamados de testes de performance. Testes Funcionais: grupos de testes que avaliam se o que foi especificado foi implementado, normalmente servindo de base a um processo de verificao automtica. Neste teste devem ser considerados os valores extremos que examinam os limites do sistema. Testes de Qualidade de Cdigo: grupos de testes com o intuito de verificar o cdigo fonte dos programas em consonncia com padres, melhores prticas, instrues no executadas e outros. Testes de Alteraes: visam a rastrear alteraes de programas durante o processo de teste. Testes de Recuperao de Verses: verificam a capacidade de retornar a uma verso anterior do sistema. Testes de Interoperabilidade: avaliam as condies de integrao com outros softwares e/ou ambientes. Por exemplo, se o sistema recebe informao de um outro, se alguma ao deve ser tomada e vice-versa. Testes de Sobrevivncia (ou Confiabilidade ou Disponibilidade): avaliam a capacidade do software em continuar operando mesmo quando algum elemento (software ou hardware) fica inoperante ou para de funcionar. Por exemplo: queda de um dos servidores utilizados, queda de uma parte do Banco de Dados etc. Testes Estticos: Avaliam toda a documentao do projeto, tais como modelos, requisitos etc. Testes Embutidos: avaliam a integrao entre o hardware e o software, como por exemplo, um sinal para que um equipamento entre em funcionamento.

Testes de Verificao do Site Web: verificam problemas que possa haver no site Web tais como links invlidos, arquivos rfos, pginas lentas, ligaes entre pginas/componentes e outros. Testes de Conferncia de Arquivos: Verificam alteraes nos arquivos usados Testes Alfa: so executados quando o desenvolvimento est prximo sua concluso. Este tipo de teste geralmente realizado por usurios ou outros usurios internos e no pelos programadores ou equipe de testes. Normalmente, estes testes so feitos de forma descontrolada, isto , sem nenhuma relao com o organograma de testes. Testes Beta: so executados quando o desenvolvimento e testes esto praticamente concludos, e o maior nmero possvel de defeitos/problemas precisam ser encontrados antes da release final. Normalmente estes testes so feitos de forma descontrolada, isto , sem nenhuma relao com o plano de testes.

Quando terminar os testes?

Todos ns sabemos que os defeitos podem ocorrer a qualquer momento. Ningum pode garantir que um software est completamente livre de defeitos. Evitar que os defeitos ocorram uma das tarefas dos testadores. Muitas vezes necessrio horas e mais horas de teste para encontrar um nico defeito. Teste toma tempo e custa dinheiro. Garantir que o software no tenha nenhum defeito pode custar muito caro e consumir muito tempo. Logo precisamos determinar qual o melhor momento de interromper os testes. Existem alguns conceitos que permitem visualizar o melhor momento de interromper os testes: Quando o custo da correo dos defeitos for maior do que o custo da ocorrncia do defeito Trata-se de um conceito pouco preciso, pois nem sempre temos essas informaes.

Figura 1.5 Um dos caminhos de encontrarmos essa relao determinar quanto custa a ocorrncia de um defeito em produo em termos de negcio e qual o impacto que a aplicao fora do ar poderia causar. Lembre-se que o Windows XP foi lanado com milhares de defeitos que foram sendo corrigidos atravs do

tempo. Muitas vezes o tempo de mercado indica o melhor momento de liberar o software e interromper os testes, embora esses possam continuar paralelamente ao lanamento do produto. Quando o nmero de defeitos encontrados indicar Esse nmero ser vlido se voc tiver informaes histricas sobre nmero de defeitos encontrados relacionados com casos de uso, por exemplo. Neste caso os casos de uso precisam estar classificados por algum indicador, como, grau de complexidade. Ou seja, voc tem informaes histricas que um caso de uso complexo, por exemplo, tem cerca de 10 defeitos em mdia. Voc j est testando h algum tempo e encontrou 11 defeitos. Caso o prazo estoure voc tem um critrio de interrupo dos testes. Outro indicador seria o intervalo entre a ocorrncia de defeitos. Voc est testando um requisito e a incidncia de defeitos est se tornando cada vez mais esparsa no tempo. Intervalos de tempo muito grande podem indicar que os defeitos sero cada vez mais raros. Quando todo o software for coberto pelos testes Para garantir isso voc vai precisar de um software que indique que todas as linhas de cdigo foram cobertas pelo teste ou todos os desvios foram percorridos. Outro caminho garantir que todos os requisitos foram testados. Isso pode ser feito atravs de uma matriz de rastreabilidade. Essa matriz indica que os requisitos esto ligados a casos de uso que esto ligados a programas que esto ligados a casos de teste. De qualquer forma, todos ns sabemos que os grandes indicadores para a interrupo dos testes sero sempre o tempo e os custos.