11 1 --teste_de_software_motivação_e_conceitos_basicos

294 visualizações

Publicada em

teste de software

Publicada em: Meio ambiente
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
294
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
3
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

11 1 --teste_de_software_motivação_e_conceitos_basicos

  1. 1. Centro de Tecnologia da Informação Renato Archer – CTI/MCT Centro de Tecnologia da Informação Renato Archer, CTI Ministério da Ciência e Tecnologia, MCT Teste de Software: Motivação e Conceitos Básicos Autores: Adalberto Nobiato Crespo: Adalberto.crespo@cti.gov.br Mario Jino: Jino@dca.fee.unicamp.br Miguel Argollo: Miguel.argollo@cti.gov.br Paulo Bueno: Paulo.bueno@cti.gov.br Celso Penteado de Barros: Celso.barros@cti.gov Outubro/2009 Teste de Software: Motivação e Conceitos Básicos Página 1
  2. 2. Centro de Tecnologia da Informação Renato Archer – CTI/MCT Teste de Software: Motivação e Conceitos Básicos Apresentação Este documento apresenta uma introdução ao teste de software, um conjunto de atividades de extrema importância para a obtenção de produtos de software de qualidade. Como um texto inicial, buscou-se apresentar os conceitos fundamentais de teste de uma forma simples e breve. São descritos, dentre outros conceitos de teste: o objetivo; os procedimentos; o processo; os tipos; os níveis e as técnicas aplicadas à atividade de teste. O objetivo é apontar práticas aceitas como eficazes por profissionais da área e também padrões recentes de teste de software, definidos por órgãos como ISO/IEC e IEEE. É importante notar que a adoção de qualquer tecnologia de teste por parte das organizações ou profissionais envolvidos com o SPB deve ser calcada em uma análise cuidadosa das reais necessidades de teste, tendo em vista o objetivo da organização ou do profissional e a natureza do software produzido. Diferentes usuários podem se interessar prioritariamente por partes distintas deste documento. Embora a leitura integral seja recomendada, podem-se identificar duas áreas de interesse: aspectos mais técnicos do teste e aspectos mais voltados à política e ao gerenciamento do teste. As Seções 1, 2, 3 e 11 abordam a motivação, alguns conceitos que são essenciais para todos os leitores assim como as conclusões. As Seções 4, 5, 6 e 7 discutem conceitos como níveis, ciclos, tipos, técnicas, critérios e ferramentas de teste; conteúdo importante para os desenvolvedores de software e os responsáveis pelo teste (gerentes, projetistas e executores de teste). As Seções 8, 9, 10 apresentam os conceitos de processo, documentação, análise de riscos, e considerações políticas e estratégicas do teste, temas relacionados à gerência estratégica de TI, importantes para os responsáveis pela área de qualidade e de processos da organização. Guias e tutoriais de teste estão sendo desenvolvidos para complementar este documento. Teste de Software: Motivação e Conceitos Básicos Página 2
  3. 3. Centro de Tecnologia da Informação Renato Archer – CTI/MCT Conteúdo 1 Introdução: software público, qualidade e teste ............................................................. 4 2 Teste de software: objetivo, custos e benefícios ............................................................. 5 3 O sucesso no teste: provocar falhas que mostrem defeitos ............................................ 8 4 Níveis e ciclos do teste: quando testar .......................................................................... 11 5 Tipos de teste: o que testar ........................................................................................... 13 6 Técnicas e critérios de teste: como testar ..................................................................... 15 6.1 Critérios da técnica funcional ................................................................................... 17 6.2 Critérios da técnica estrutural .................................................................................. 21 7 Ferramentas de apoio ao teste ...................................................................................... 24 8 Processo e documentação do teste: como organizar o trabalho .................................. 26 9 Análise de riscos: priorizar aspectos para o teste .......................................................... 28 10 Política e processo de teste: o papel do teste na estratégia da organização ................ 29 11 Conclusão: transformando conceitos de teste em melhores produtos de software .... 31 Teste de Software: Motivação e Conceitos Básicos Página 3
  4. 4. Centro de Tecnologia da Informação Renato Archer – CTI/MCT 1 Introdução: software público, qualidade e teste O amadurecimento da indústria de software no Brasil traz consigo um aumento da competitividade entre as empresas brasileiras desenvolvedoras e também destas com empresas de outros países. Neste contexto, a promoção da qualidade de produtos de software é um fator crítico de sucesso. Também de suma importância é o aprimoramento dos processos de engenharia e de gestão no desenvolvimento de software, visando permitir projetos bem sucedidos, com menores custos e respeitando os limites de prazo. O Software Público Brasileiro (SPB) adota um modelo de desenvolvimento de software caracterizado pelo compartilhamento de produtos de software, assim como dos artefatos e serviços a eles relacionados. A existência de um alto nível de qualidade do software, artefatos e serviços compartilhados seguramente tem uma influência positiva para o sucesso deste modelo. Deste modo, a adoção de práticas visando avaliar e aprimorar a qualidade deve ser estimulada no contexto do SPB. O desenvolvimento de software não é uma tarefa fácil e, por ser fortemente baseada no trabalho humano, é altamente sujeita a erros. Portanto, por mais que se adotem processos de software bem estabelecidos, e que estes sejam executados por pessoas capacitadas, usando técnicas e ferramentas adequadas, erros durante o desenvolvimento acontecem e resultam em deficiências no software. A atividade de teste visa identificar estas deficiências, permitindo assim o aprimoramento dos produtos de software. O restante do documento está organizado do seguinte modo. A Seção 2 aborda a necessidade do teste e os impactos negativos de um teste inadequado; a Seção 3 define alguns conceitos fundamentais; a Seção 4 mostra como o esforço de teste pode ser realizado em etapas e ciclos; a Seção 5 apresenta alguns tipos de teste existentes; a Seção 6 descreve as principais técnicas e critérios para seleção e avaliação de testes; a Seção 7 cita alguns tipos de ferramentas que podem apoiar esta atividade, enquanto a Seção 8 descreve as atividades principais e as informações envolvidas em um processo de teste; a Seção 9 sumariza como a análise de riscos pode ser considerada no teste; a Seção 10 aborda como situar estrategicamente o teste em relação aos objetivos da organização. Finalmente, tem-se a conclusão na Seção 11. Teste de Software: Motivação e Conceitos Básicos Página 4
  5. 5. Centro de Tecnologia da Informação Renato Archer – CTI/MCT 2 Teste de software: objetivo, custos e benefícios Existem diversas definições de teste de software; por exemplo: • “Teste é uma atividade direcionada para avaliar um atributo ou capacidade de um programa ou sistema e determinar se ele satisfaz os resultados requeridos”1; • “Teste é o processo de executar um programa com a intenção de encontrar defeitos”2; • “Teste é o processo pelo qual se explora e se entende o estado dos benefícios e riscos associados com a versão de um sistema de software”3. Todas essas definições são válidas e destacam algum aspecto importante da atividade de teste. De maneira simplificada podemos entender o teste de software como: “a execução do software de uma forma controlada com o objetivo de avaliar se o software se comporta ou não conforme especificado”. Trata-se, portanto, de uma atividade fundamental para avaliar se o software produzido atende aos requisitos levantados com os usuários. No entanto, teste não exclui a realização de outras atividades como as inspeções efetuadas nos artefatos produzidos ao longo do processo de software. Uma questão essencial é: “por que existe a necessidade de se testar software?” Uma resposta (provocativa) a esta pergunta tem a forma de outra questão: “você se sentiria confortável em ser o passageiro de um vôo em uma aeronave que nunca decolou antes?” O processo de projeto e construção de aeronaves envolve uma série de atividades de teste da aeronave como um todo e de seus componentes principais (asas, turbinas, sistemas eletrônicos, sistemas mecânicos). Essas atividades visam a confirmar as teorias consideradas no projeto, obter dados empíricos e avaliar os aspectos não embasados por teorias, avaliar a conformidade com padrões de segurança e de desempenho de vôo, além de vários outros pontos. Os testes são aplicados em componentes, em subsistemas, e na aeronave inteira, incluindo o teste em condições reais de vôo. Esta questão é obviamente 1 Hetzel, B. 1988, “The Complete Guide to Software Testing (2nd Ed.)”. QED Information Sciences, Inc. 2 Myers, G.J., 1979, “The Art of Software Testing”, Addison-Wesley, New York. 3 Cem Kaner, James Bach e Bret Pettichord, “Lessons Learned in Software Testing: A Context-Driven Approach”, Willey Computer Publishing, 2002. Teste de Software: Motivação e Conceitos Básicos Página 5
  6. 6. Centro de Tecnologia da Informação Renato Archer – CTI/MCT um exagero proposital; uma aeronave não testada nunca seria liberada para um vôo comercial. Analogamente, um software não deve ser liberado para uso sem que atividades adequadas de teste tenham sido realizadas. Por meio do teste diversas deficiências existentes no software, relacionadas a problemas de funcionalidade, desempenho, segurança, instalação e utilização podem ser encontradas e removidas, antes que o software “entre em vôo”, isto é, seja implantado para o uso dos clientes. Enfim, testa-se software porque o desenvolvimento de sistemas envolve uma série de atividades em que as possibilidades de ocorrência de erros humanos são inúmeras. Erros podem ocorrer logo no início do processo de criação do software, quando objetivos definidos podem estar incorretos ou incompletos. Além disso, erros podem ocorrer nas demais fases do desenvolvimento, como projeto, codificação e integração do software. Essencialmente erros ocorrem pela dificuldade dos seres humanos de executar tarefas e se comunicar com perfeição. Esses são os mesmos motivos que justificam o teste rigoroso em aeronaves. O teste de software não é uma atividade tecnicamente fácil nem barata. A atividade de teste representa um percentual significativo do custo total de desenvolvimento do software. Estudos mostram que, dependendo do tipo do software e do processo de desenvolvimento, o custo do teste tipicamente fica entre 50% e 80% do custo total 4. No entanto, é fato reconhecido que a ausência de uma atividade de teste bem realizada acarreta um custo total significativamente maior. O retrabalho devido à manutenção corretiva de problemas de especificação, projeto e programação é uma realidade amplamente conhecida. Estatísticas apresentadas mostram ainda que cada R$ 1,00 investido em prevenção de defeitos diminui de R$ 3,00 a R$ 10,00 os custos de manutenção corretiva. E cada R$ 1,00 investido em remoção de defeitos diminui de R$ 2,00 a R$ 5,00 os custos de manutenção corretiva. Um estudo do NIST (Instituto Nacional de Padrões e Tecnologia, órgão do Departamento de Comércio dos Estados Unidos) aponta impactos negativos de 4 Boehm, B. W. 1981, “Software Engineering Economics.” 1st. Prentice Hall PTR Teste de Software: Motivação e Conceitos Básicos Página 6
  7. 7. Centro de Tecnologia da Informação Renato Archer – CTI/MCT inadequações nas atividades de teste5. Dentre os problemas acarretados pelo teste inadequado podem-se destacar: • Crescimento do número de falhas em uso devido à má qualidade do software, acarretando perdas na reputação da organização e no potencial de negócios futuros; • Aumento no custo de desenvolvimento de software, visto que o custo da correção de problemas no software cresce ao longo dos estágios do desenvolvimento, tendo seu maior valor quando é necessário corrigir problemas em um software já implantado no cliente; • Atraso para disponibilizar o produto ao mercado devido à ausência de processos e técnicas de teste padronizadas e a conseqüente necessidade de criar às pressas uma infra-estrutura de teste. Esta lista de problemas é mais extensa, e apresenta problemas potencialmente dramáticos, no caso de software com altos requisitos de confiabilidade, tais como: software de controle de reatores nucleares; software aeroespacial e software de monitoramento de leitos em UTIs. O teste inadequado de softwares que manipulam informações de alto valor, como dados estratégicos de empresas e informações bancárias, também pode acarretar grandes danos financeiros e de imagem às organizações. No contexto do SPB as deficiências no teste de um produto de software podem acarretar uma perda de reputação deste software entre os seus possíveis usuários, limitando consequentemente os potenciais benefícios trazidos pelo software. Raymond define o “modelo bazar” de desenvolvimento no qual o código fonte do software é disponibilizado publicamente na internet e desenvolvido de forma colaborativa e compartilhada por milhares de desenvolvedores espalhados pelo mundo; é o modelo utilizado para o desenvolvimento do Kernel do sistema operacional Linux 6. Segundo Raymond, ao se usar este modelo de desenvolvimento “quanto mais largamente o código fonte estiver disponível para o teste, exame e experimentação, mais rapidamente os “bugs” 5 The National Institute of Standards and Technology (NIST) Strategic Planning and Economic Analysis Group, “The Economic Impacts of Inadequate Infrastructure for Software Testing,” Maio, 2002 6 Eric S. Raymond, “The Cathedral & the Bazaar, Musings on Linux and Open Source by an Accidental Revolutionary,” Fevereiro, 2001, O´Reilly & Associates, Inc. Teste de Software: Motivação e Conceitos Básicos Página 7
  8. 8. Centro de Tecnologia da Informação Renato Archer – CTI/MCT serão descobertos”, chamada por ele de “Lei Linus” – referindo-se a Linus Torvalds, idealizador do Linux – “given enough eyeballs, all bugs are shallow” 7. Na medida em que o SPB caracteriza-se pelo compartilhamento de código fonte e de outros artefatos de software, é razoável esperar que as práticas de teste possam ser conduzidas de forma eficiente, aproveitando a característica colaborativa do ambiente e o espírito engajado e investigativo de muitos membros de comunidades. A utilização de boas práticas de teste neste contexto tem o potencial de aumentar a qualidade dos produtos de software e os benefícios do SPB à sociedade. 3 O sucesso no teste: provocar falhas que mostrem defeitos O teste de software pode também ser definido como “a execução de um software com o objetivo de encontrar defeitos”. Neste caso, fica explícita a idéia de que o teste deve exercitar o software de uma maneira tal que este falhe, permitindo assim a posterior identificação e remoção da causa desta falha. Deve-se ter em mente que um defeito (fault ou defect em inglês) é uma anomalia no software que pode causar uma falha (exemplos: um comando imperfeito, incompleto, ausente ou extra no software). Uma falha (failure) é a ocorrência de uma discrepância entre o resultado observado da execução do software e o resultado prescrito pelos requisitos. Um erro (error) é um estado incorreto, intermediário ou final, de execução do software que pode produzir um resultado incorreto, ou seja, pode levar a uma falha do software. Um defeito no software é introduzido devido a algum engano (mistake) cometido em algum momento no desenvolvimento do software e não descoberto em atividades de inspeção. Por exemplo: o foguete Ariane V explodiu em 1996, cerca de 40 segundos após ter decolado 8. O foguete saiu de sua rota programada e se desintegrou devido a forças aerodinâmicas. Em uma análise posterior do incidente, verificou-se que o software de controle do vôo indicou uma direção errada ao foguete (esta foi a falha) devido a uma 7 “se os olhos forem suficientes, todos os bugs serão vistos” em uma tradução livre. Ou: “... dados grupos grandes o suficiente de testadores-beta e de desenvolvedores, quase todos os problemas serão identificados rapidamente e o conserto será óbvio para alguém...”. 8 ARIANE 5 Flight 501 Failure Report by the Inquiry Board, Julho, 1996. Teste de Software: Motivação e Conceitos Básicos Página 8
  9. 9. Centro de Tecnologia da Informação Renato Archer conversão incorreta de uma variável defeito). Esta conversão produziu um erro de overflow, isto é, um valor errôneo de uma variável (este foi o erro), que ocasionou a resposta incorreta do software. O engano foi, provavelmente, cometido por um programador, que inseriu no software um comando de atribuição indevido. Portanto, para um defei (este foi o de uma forma tal que o defeito seja “sensibilizado” falha. Isto ocorre quando o comando defeituoso é executado e cria um as variáveis internas, por exemplo) ainda que este erro seja propagado, ao longo da execução, do ponto onde foi criado defeituoso) para alguma saída do software, ocasionando uma resposta final incorreta (valores incorretos para alguma saída produzida, por exemplo). A Figura 1 ilustra a cadeia de eventos que se inicia com um engano e que pode resultar em uma falha do software. Figura 1: C Em uma visão simplificada, a realização do teste a. Selecionar valores para as teste (chamados de Dad partir do conjunto de todos os possíveis valores que podem ser usados para executar o software, chamado de Teste de Software: Motivação e Conceitos Básicos – CTI/MCT ftware: tipo real de 64 bits em um inteiro de 16 bits efeito ser descoberto é necessário que o software seja executado e provoque uma falha estado de erro (valores incorretos para ternas, exemplo). Para que a falha aconteça, é necessário (logo após o comando Cadeia de Eventos Para a Falha do Software envolve: Variáveis de Entrada a serem submetidos ao software em ados de Entrada ou de Dados de Teste); esta seleção é feita a Domínio de Entrada do software. Página 9
  10. 10. Centro de Tecnologia da Informação Renato Archer b. Executar o software com os dados de teste , as variáveis de entrada e acionar alguma função no software c. Avaliar se a saída produzida corresponde à do software, isto é, se o comportamento e os valores produzidos como resultado da execução foram os corretos Um par dados de entrada de Teste. Uma coleção de vários Teste. Para a realização do teste, presume hamado Caso onjunto de Casos de permita avaliar se certo resultado acordo com a especificação (ou Esta avaliação é feita por meio de um papel de oráculo e realiza a comparação “esperado versus obtido” software falhou ou não. A Figura 2 apresenta uma visão simplificada do teste: de entrada e a avaliação da saída produzida pelo programa esperados. Uma limitação inerente à atividade de teste é identificando se o software está correto. O teste pode revelar a ausência desses defeitos. Portanto, por mais rigoroso que seja o teste, não é possível assegurar que não permaneceram no software defeitos “escondidos” Teste de Software: Motivação e Conceitos Básicos – CTI/MCT ftware: teste, ou seja, informar os valores para software; e saída esperada segundo a especificação , corretos. e resultados esperados associados é chamado de um casos de teste é referida como um Conjunto presume-se a existência de algum meio ou dispositivo que - ou comportamento - produzido pelo software está de seja, se é o resultado esperado de um software correto). oráculo. Normalmente o executor do teste assume o obtido”, identifica a execução do programa com dados em relação aos resultados Figura 2: Visão Simplificada do Teste sua impossibilidade de provar que um . presença de defeitos no software, mas não a escondidos”, não encontrados Página 10
  11. 11. Centro de Tecnologia da Informação Renato Archer – CTI/MCT durante o teste. No entanto, o teste pode dar subsídios para que se avalie o quão confiável (ou não) é o software. 4 Níveis e ciclos do teste: quando testar O teste de software é normalmente realizado em uma série de fases, ou níveis: • Teste de Unidade; • Teste de Integração; • Teste de Sistema; e • Teste de Aceitação. Após o desenvolvimento de cada unidade do software (procedimento, função, método ou classe) é realizado o teste de unidade (ou teste unitário), que visa a identificar defeitos introduzidos nos algoritmos e estruturas de dados dessas unidades. Em geral, o teste de unidade é feito pelo próprio desenvolvedor da unidade. As unidades são então incrementalmente integradas e testadas (teste de integração). Esta etapa é realizada pelos desenvolvedores ou por elementos de uma equipe de teste e visa a identificar defeitos de interface entre as unidades. Depois de integrado, o software é testado “como um todo”: o teste de sistema é o nível de teste cujos requisitos são derivados da especificação de requisitos funcionais e não funcionais, e é aplicado para verificar se o software e o hardware executam corretamente ou não quando integrados ao ambiente de operação. O teste de aceitação é então conduzido para estabelecer se o sistema satisfaz ou não os critérios de aceitação definidos com o cliente. Deve-se notar que em cada um desses níveis (unidade, integração, sistema e aceitação) diversos ciclos de teste podem ocorrer. Em cada ciclo de teste um procedimento de teste é realizado, por meio do qual um ou mais casos de teste são executados. Falhas provocadas por casos de teste devem ser registradas para posterior depuração do software (localização e remoção dos defeitos) pela equipe de desenvolvimento. No próximo ciclo, casos de teste devem ser re-executados para avaliar se os defeitos que ocasionaram as falhas foram realmente removidos e se as alterações no software não introduziram inadvertidamente outros defeitos. Pode ocorrer também a necessidade de se retornar a um nível de teste anterior. Por exemplo: durante o teste de integração podem ser identificados Teste de Software: Motivação e Conceitos Básicos Página 11
  12. 12. Centro de Tecnologia da Informação Renato Archer problemas que requeiram muitas alterações em pode ser adequado, além de re novamente o teste de unidade as algum módulo do software. Neste caso, O teste de um software já testado previamente Teste de Regressão. Este teste busca verificar se as modificações efetuadas não introduziram novos defeitos ou ativaram defeitos em partes inalteradas do código; visa também avaliar se o software ainda satisfaz os seus r tipicamente realizado na fase de manutenção, após a realização de mudanças no software ou no seu ambiente. Conforme descrito no parágrafo anterior, este teste também pode ocorrer ao longo do desenvolvimento do software. A Figura 3 ilustra um processo sequencialmente: teste de unidade níveis são mostrados os ciclos execução de casos de teste. A figura mostra de teste. Teste de Software: Motivação e Conceitos Básicos – CTI/MCT ftware: re-executar casos de teste de integração, também realizar do módulo alterado. e que sofreu mudanças é chamado de . requisitos. O teste de regressão é em que os níveis de teste são executados quencialmente: unidade, de integração, de sistema e de aceitação. que envolvem alterações do software (ou depuração ão também o fluxo de retorno a níveis anteriores Figura 3: Níveis e Ciclos de Teste Página 12 equisitos. Em todos os depuração) e a re-também
  13. 13. Centro de Tecnologia da Informação Renato Archer – CTI/MCT É importante destacar que não é obrigatório que todos os níveis de teste ocorram para que se tenha um teste adequado. A necessidade ou não de realizar cada um desses níveis deve ser decidida a partir da análise da situação específica, conforme descrito nas seções sobre processos de teste (Seções 8 e 10). 5 Tipos de teste: o que testar Diversos atributos de qualidade do software podem ser avaliados por meio de testes. Características de qualidade de software definidas em padrões como a ISO/IEC 9126 9 podem servir como base para a definição de aspectos do software a serem avaliados por meio da realização de testes. Portanto, existem diversos tipos de teste; cada tipo visa à avaliação de um aspecto distinto do software e pode ser aplicado em um ou mais níveis de teste (unidade, integração, etc.). O teste de funcionalidade busca avaliar se o software apresenta um conjunto de funções que satisfaça ou não às necessidades levantadas (associadas aos requisitos definidos). O teste de desempenho visa a avaliar se o software executa as funções previstas satisfazendo ou não os requisitos de desempenho definidos (e.g., velocidade de processamento, tempo de resposta, uso de memória). O teste de interoperabilidade avalia a capacidade do software em interagir com um ou mais componentes ou sistemas. O teste de segurança (security) visa a avaliar a habilidade do software de impedir o acesso não autorizado – acidental ou deliberado – ao software ou a dados. O teste de sanidade (smoke test) envolve a execução de um subconjunto dos testes projetados que cobrem algumas funcionalidades principais; pode ser realizado 9 ISO/IEC 9126-1:2001 Software engineering -- Product Quality -- Part 1: Quality model Teste de Software: Motivação e Conceitos Básicos Página 13
  14. 14. Centro de Tecnologia da Informação Renato Archer – CTI/MCT periodicamente, ou como uma atividade inicial para avaliar se o software está pronto para um esforço maior de teste. O teste de estresse simula condições atípicas de utilização do software, provocando aumentos e reduções sucessivas de transações que superem os volumes máximos previstos para a capacidade de processamento dos componentes ou do sistema. O teste de usabilidade visa a determinar quão facilmente o produto de software é compreendido, apreendido e usado, e quão agradável ele é ao usuário. O teste de portabilidade busca avaliar o nível de facilidade de transferência de um ambiente de hardware e software para outro ambiente. O teste de carga consiste em medir o comportamento de um componente ou sistema submetido a cargas de processamento crescentes para determinar qual nível de carga o sistema pode tratar; por exemplo, número de usuários ou número de transações. O teste de instalação busca avaliar se o software é instalado e desinstalado com sucesso ou não em determinado ambiente operacional. O teste de recuperação determina a capacidade ou incapacidade de um produto de software de restabelecer condições normais de operação e de recuperar dados afetados, em caso de falha. A determinação de quais tipos de teste devem ser utilizados e em qual (quais) nível (níveis) eles devem ser aplicados, ocorre durante a fase de planejamento do teste. Esta definição é feita considerando-se as informações disponíveis sobre a natureza do software em teste e dos requisitos específicos dos módulos que compõem o software. Na maior parte das situações é adequado focar atenção no teste de funcionalidade para avaliar os se os requisitos funcionais do software são satisfeitos ou não. Este teste deve ser complementado por outros tipos de teste (carga, desempenho, etc) para avaliar se os requisitos não funcionais do software são satisfeitos ou não. Teste de Software: Motivação e Conceitos Básicos Página 14
  15. 15. Centro de Tecnologia da Informação Renato Archer – CTI/MCT 6 Técnicas e critérios de teste: como testar Esta seção apresenta algumas Técnicas e Critérios de Teste úteis para a seleção de bons casos de teste. É importante ressalvar que existem outras técnicas não relatadas aqui; procurou-se destacar as técnicas mais usadas na prática ou mais consolidadas na literatura. Como este documento apresenta apenas uma visão inicial sobre técnicas e critérios, é recomendada a consulta a tutoriais específicos e de literatura especializada para maiores informações. Uma tarefa fundamental na atividade de teste é a seleção dos casos de teste a serem utilizados. Esta seleção é necessária porque o Teste Exaustivo, feito com todas as possíveis combinações de valores de entrada, é quase sempre inviável. Por exemplo, considere um software que tenha como entrada 15 variáveis, sendo que cada uma delas pode assumir 7 valores diferentes. Considere ainda que a execução de cada caso de teste demore 1/100 de segundo (0,01 segundo). Para realizar o teste exaustivo deste software seriam necessários 715/100 segundos, o que equivale a 1.505 anos e alguns meses de processamento. Tendo em vista o objetivo principal do teste de revelar defeitos e a restrição de que os cronogramas e orçamentos sejam cumpridos, é aconselhável a utilização de Técnicas de Teste. Estas técnicas estabelecem procedimentos para selecionar - ou criar - os casos de teste que resultem em um conjunto de teste eficaz e de tamanho moderado. As técnicas de teste determinam a natureza da informação a ser utilizada para se fazer a seleção ou a avaliação de conjuntos de teste. Na técnica de Teste Funcional os casos de teste são selecionados por meio da análise da especificação do software, ou utilizando modelos criados na fase de análise e projeto do software. Na técnica de Teste Estrutural os casos de teste são selecionados por meio da análise da estrutura interna do software. Na técnica de teste Baseada em Defeitos, casos de teste são selecionados a partir de classes de defeitos que podem ser introduzidos ao longo do desenvolvimento do software. A Figura 4 ilustra as técnicas funcional e estrutural de teste. Teste de Software: Motivação e Conceitos Básicos Página 15
  16. 16. Centro de Tecnologia da Informação Renato Archer As diversas técnicas de teste não são excludentes; técnicas é recomendada, pois os defeitos revelados pela aplicação de ser diferentes. A utilização de uma técnica de teste ocorre por meio da aplicação de Teste. Um critério de teste determina um conjunto de que devem ser exercitados pela realização do teste. comandos - ou todos os nós requeridos os comandos do código do software deve ser executado (ou exercitado), pelo menos uma vez, por algum dado de teste. A Cobertura do Teste, Critério equeridos do software todos os . software o percentual de elementos requeridos exercitados por um conjunto de casos executados. Por exemplo, o percentual de comandos executados durante o teste seria uma medida de cobertura considerando medida de cobertura quantifica, sob certa perspectiva, a qualidade do teste realizado. razoável supor, neste exemplo, que um conjunto de teste que executa 90% dos comandos de um software é melhor do que outro conjunto de teste de teste É 10 O teste caixa preta inclui outras técnicas além da técnica funcional, única que está sendo considerada neste documento. Teste de Software: Motivação e Conceitos Básicos – CTI/MCT ftware: Figura 4: Técnicas de Teste 10 as na verdade, a utilização de várias ada, cada uma delas podem de algum Elementos Requeridos Por exemplo, o critério - da técnica estrutural de teste define como elementos o software. Neste caso, cada comando do so este, com respeito a um critério de teste específico, mede . considerando-se o critério de teste do exemplo anterior. Deste modo, a que executa apenas 50% dos Página 16
  17. 17. Centro de Tecnologia da Informação Renato Archer – CTI/MCT comandos. Se um conjunto de casos de teste exercita todos os elementos requeridos pelo critério, diz-se que tal conjunto satisfaz o critério. Em geral, os critérios de teste podem ser utilizados para: criar um conjunto de casos de teste; avaliar um conjunto de casos de teste já criado; ou ainda, servir como uma condição para a finalização do teste. A seguir é feita uma breve descrição de alguns critérios de teste da técnica funcional e da técnica estrutural, as mais usadas na prática. 6.1 Critérios da técnica funcional Os critérios da técnica de teste funcional caracterizam-se por utilizar informações originadas da especificação do software como base para a seleção de casos de teste. Artefatos criados na fase de análise de requisitos e de projeto do software, tais como o documento de requisitos do software ou modelos como diagramas UML, são utilizados para criar os casos de teste. A idéia essencial da técnica funcional é selecionar dados de teste representativos o suficiente para avaliar se as funcionalidades definidas na especificação do software foram implementadas corretamente ou não. Para tanto, operações associadas às funcionalidades são identificadas e dados de teste que as exercitem são definidos e executados. O critério Particionamento de Equivalência divide o domínio de entrada do software em classes de equivalência e requer que pelo menos um dado de teste de cada classe seja selecionado e executado. Essas classes são definidas pressupondo que todo dado de entrada pertencente a uma classe é tratado do mesmo modo, de acordo com a especificação do software. Portanto, cada dado de teste selecionado representa os demais dados de testes da sua classe de equivalência. Por exemplo, se a especificação define que um software recebe como entrada uma variável idade, tipo inteiro, que pode variar de 0 a 120 anos (incluindo os extremos), poderiam ser identificadas as seguintes classes de equivalência: • Classe 1: idade menor que zero – referida como classe de valores inválidos; • Classe 2: idade entre 0 e 120 – classe de valores válidos; e, • Classe 3: idade maior que 120 – outra classe de valores inválidos. Teste de Software: Motivação e Conceitos Básicos Página 17
  18. 18. Centro de Tecnologia da Informação Renato Archer – CTI/MCT Ao se executar o software com dados de teste que pertençam às Classes 1 e 3 espera-se que os valores fornecidos sejam identificados como não aceitáveis e sejam emitidas mensagens apropriadas. Ao se executar o software com um dado de teste que pertença à Classe 2 o valor fornecido deve ser aceito e uma saída apropriada deve ser produzida. A Figura 5 ilustra as classes de equivalência do exemplo e os dados de teste selecionados para exercitar cada classe. Classe 2 (valores válidos) (valores inválidos) Classe 1 (valores inválidos) -39 0 45 120 135 Figura 5: Classes de Equivalência e Dados de Teste Classe 3 Dependendo da especificação, se existirem diferentes tipos de tratamento dentro de alguma dessas classes, ela deve ser subdividida. Por exemplo, a Classe 2 pode ser subdividida em sub-classes: 2.1 – idade entre 0 e 17; 2.2 – idade entre 18 e 20; e 2.3 – idade entre 21 e 120. Esta divisão faz sentido e deve ser feita se a especificação do software definir tratamentos distintos para estas diferentes faixas de valores. Neste caso a Classe 2 não é homogênea e, portanto, a execução de apenas um caso de tese da classe seria insuficiente. Deve-se notar que o modo como as classes de equivalência são definidas influencia fortemente a eficácia do critério. Esta definição deve ser feita de forma cuidadosa, analisando-se a natureza de cada variável de entrada do programa e a especificação do software em teste. O critério Análise de Valores Limite complementa o critério Particionamento de Equivalência. Freqüentemente as situações de transição de comportamento do software de uma classe para outra classe, as situações limite, são implementadas de forma incorreta. Estas situações costumam ser inerentemente complexas e acabam induzindo a erros de análise, projeto ou codificação. Para descobrir defeitos associados a estas situações é recomendada a seleção de dados de teste situados nos limites das classes. No exemplo anterior (variável idade, tipo inteiro, Teste de Software: Motivação e Conceitos Básicos Página 18
  19. 19. Centro de Tecnologia da Informação Renato Archer – CTI/MCT que pode variar de 0 a 120 anos, incluindo os extremos) os valores limite seriam: 1, 0 e -1, referentes ao limite entre as Classes 1 e 2; e 119, 120, 121, referentes ao limite entre as Classes 2 e 3, conforme ilustrado na Figura 6. Notar que são selecionados valores exatamente no limite, valores imediatamente inferiores e imediatamente superiores ao limite. A definição dos valores limite também deve ser feita cuidadosamente, analisando-se a natureza de cada variável de entrada do programa e a especificação do software em teste. Classe 2 (valores válidos) (valores inválidos) -1 0 1 119 120 121 Figura 6: Valores Limite e Dados de Teste Classe 3 (valores inválidos) Classe 1 Teste baseado em modelos Alguns critérios caracterizam-se por utilizar modelos do software (representações intermediárias do software) como base para a seleção de dados de teste. Esses critérios são freqüentemente chamados de Teste Baseado em Modelos (Model Based Testing). Modelos como Máquinas de Estados Finitas (FSM), ou modelos definidos em linguagens como UML (Unified Modelling Language) ou SDL (Specification and Description Language) podem ser utilizados para este propósito. O Teste Baseado em Casos de Uso utiliza os modelos de Casos de Uso (representação definida na UML), criados na fase de análise de requisitos e de projeto do software, para a seleção de casos de teste. Casos de Uso são muito usados para especificar o comportamento esperado do sistema do ponto de vista dos atores que interagem com o sistema. Como são elaborados normalmente em etapas iniciais do processo de desenvolvimento, esses modelos são úteis para o projeto antecipado de casos de teste, principalmente os que serão aplicados nos testes de sistema e de aceitação do software. A aplicação do critério de teste é feita nos seguintes passos: Teste de Software: Motivação e Conceitos Básicos Página 19
  20. 20. Centro de Tecnologia da Informação Renato Archer – CTI/MCT a. Descrever os fluxos de eventos para o caso de uso. Devem ser descritos tanto o fluxo de eventos básico como os fluxos alternativos e de exceção. b. Definir o conjunto de cenários que serão usados nos testes. Cada cenário pode ser formado a partir dos fluxos de eventos identificados bem como das combinações desses fluxos. c. Definir casos de teste para cada um dos cenários, ou seja, para cada cenário definir valores de entrada, ações no software que provoquem a execução do cenário e as saídas esperadas. d. Executar o software com os dados de teste, avaliar se os resultados produzidos correspondem aos esperados, registrar os resultados e os incidentes observados. Notar que os passos a, b e c podem ser realizados logo que a especificação dos casos de uso esteja pronta e revisada; não é necessário esperar a conclusão da implementação dos casos de uso para realizá-los. O passo d pode ser realizado em momentos distintos, dependendo do nível do teste realizado: quando os módulos que implementam as funções especificadas nos casos de uso estiverem disponíveis (no caso do teste de “partes” do sistema); quando o sistema como um todo estiver integrado e disponível (no caso do teste de sistema); ou ainda, quando o sistema for utilizado no processo de aceitação pelo cliente (no caso do teste de aceitação). Naturalmente, outros modelos (da UML ou de outras linguagens) podem ser utilizados de forma semelhante para a seleção de casos de teste. Por exemplo, Diagramas de Estados (com os Statecharts) podem servir como base para a seleção de casos de teste que exercitem transições de estado que podem ocorrer em um objeto. Critérios de teste baseados em modelos de estados são úteis para aplicações nas quais muitas transições complexas de estado dos objetos são possíveis, tais como sistemas de controle de processos e sistemas de telefonia. Diagramas de Colaboração, que descrevem a interação entre objetos para especificar um comportamento, também podem ser utilizados para seleção de casos de teste. Critérios de teste baseados em Diagramas de Colaboração permitem avaliar interações específicas entre objetos, formadas por seqüências de comunicações. Os casos de teste visam a Teste de Software: Motivação e Conceitos Básicos Página 20
  21. 21. Centro de Tecnologia da Informação Renato Archer – CTI/MCT exercitar e avaliar se as trocas de mensagens, que caracterizam a colaboração de um conjunto de objetos, permitem atingir os propósitos definidos na especificação do sistema. 6.2 Critérios da técnica estrutural Na técnica de Teste Estrutural os dados de teste são selecionados por meio da análise da estrutura interna do software. Portanto, o código fonte do software deve estar disponível, pois ele é utilizado para a seleção dos dados de teste. A motivação para o uso desses critérios muitas vezes é feita com questionamentos do tipo: “você confiaria em um software se fosse informado que algumas instruções deste software nunca foram executadas antes?” Esta pergunta enfatiza que defeitos em trechos não exercitados do código fonte do software certamente não serão descobertos. Na Técnica Estrutural uma unidade de software (função, procedimento ou método) é considerada como o conjunto de seus componentes estruturais. Estes componentes estruturais podem ser comandos de desvio (como os comandos: if-then; switch; while e repeat) ou outros comandos (instruções como: x = y + 2; read(a,b); x = func(a,b) ). O software pode ser representado por um Grafo de Fluxo de Controle (GFC) composto de nós – correspondem a blocos de comandos que são sempre executados conjuntamente -, e ramos, que correspondem a possíveis desvios no fluxo de execução. O GFC possui um único nó de entrada, um único nó de saída, e define um conjunto de caminhos que podem ser executados do nó de entrada ao nó de saída, passando por certos comandos e desvios ao longo da execução. Quando se executa o software com um dado de teste, algum caminho específico será executado no programa (isto só não ocorre caso o software entre em um laço infinito). A Figura 7 mostra um código fonte em C (identifier.c) e o respectivo GFC 11. Notar que o código fonte apresenta no lado esquerdo como comentários o número do nó do GFC ao qual o comando pertence. É possível identificar conjuntos de comandos executados sempre conjuntamente, por exemplo, os comandos precedidos por /* 01 */ que pertencem ao nó 1 do GFC. Pode-se também observar o efeito de comandos de desvio no fluxo de 11 Código fonte e GFC presentes em: Barbosa E., Maldonado, J., Vincenzi, A., Delamaro, M., Souza, S., Jino, M. “Introdução ao Teste de Software”, XIV Simpósio Brasileiro de Engenharia de Software”, 2000. Teste de Software: Motivação e Conceitos Básicos Página 21
  22. 22. Centro de Tecnologia da Informação Renato Archer – CTI/MCT controle, por exemplo, o comando while presente no nó 4 do grafo, ou o comando if-then-else iniciado no nó 8. /* 01 */ { /* 01 */ char achar; /* 01 */ int length, valid_id; /* 01 */ length = 0; /* 01 */ printf (“Digite um possível identificadorn”); /* 01 */ printf (“seguido por <ENTER>: “); /* 01 */ achar = fgetc (stdin); /* 01 */ valid_id = valid_starter (achar); /* 01 */ if (valid_id) /* 02 */ length = 1; /* 03 */ achar = fgetc (stdin); /* 04 */ while (achar != ‘n’) /* 05 */ { /* 05 */ if (!(valid_follower (achar))) /* 06 */ valid_id = 0; /* 07 */ length++; /* 07 */ achar = fgetc (stdin); /* 07 */ } /* 08 */ if (valid_id && (length >= 1) && (length < 6) ) /* 09 */ printf (“Validon”); /* 10 */ else /* 10 */ printf (“Invalidon”); /* 11 */ } Figura 7: Código Fonte e Respectivo Grafo de Fluxo de Controle Critérios de teste estrutural estabelecem componentes internos do software como elementos requeridos. O critério de teste Todos os Comandos (ou Todos os Nós) requer que cada comando do software seja exercitado pelo menos uma vez durante o teste. A determinação de dados de teste que exercitem um comando específico requer a análise do código fonte do software e a escolha de valores para as variáveis de entrada que provoquem a execução do comando. Por exemplo, a Figura 8 mostra um trecho de programa no qual há um comando de decisão if-then-else e o respectivo GFC. Para que os comandos representados por B sejam executados é necessária a seleção de valores de entrada tais que a condição lógica do comando if seja satisfeita; por exemplo, valores de entrada que façam com que x tenha valor 100 e y tenha valor 30 imediatamente antes do comando if (notar que x e y podem ser variáveis de entrada, mas também podem ser computadas internamente, a partir de outras variáveis). Outros dados de teste serão necessários para exercitar os comandos Teste de Software: Motivação e Conceitos Básicos Página 22
  23. 23. Centro de Tecnologia da Informação Renato Archer – CTI/MCT representados por C; por exemplo, dados que resultem nos valores x = 20 e y = 15 antes do comando if. A …; A if (x > y * 2) B { … } C else C { … } D …; A B C D Figura 8: Comando if-then-else e Respectivo Grafo de Fluxo de Controle A …; A If (x > y * 2) B { … } C …; A B C Figura 9: Comando if-then e Respectivo Grafo de Fluxo de Controle O critério Todos os Ramos requer que cada possível transferência de controle seja exercitada pelo menos uma vez. A Figura 9 mostra um trecho de programa com um comando condicional if-then. Os dados de teste que satisfazem a condição do if, exercitam os comandos representados em B e também os em C. Este critério, no entanto (ao contrário do anterior), requer a execução de dados de teste adicionais, que provoquem a transferência de controle (ou ramo) do comando if diretamente para os comandos em C (sem passar por B). O critério Todos os Caminhos requer que cada diferente caminho no GFC seja executado pelo menos uma vez. Este critério é geralmente considerado excessivamente exigente visto que, em programas reais, a sua aplicação tende a gerar conjuntos muito grandes de elementos requeridos. Considere a Figura 10 que mostra um trecho de código com dois comandos if-then-else em sequência e o respectivo GFC; note que o segundo comando if pertence ao nó D no grafo. A execução de apenas dois casos de teste é suficiente para exercitar todos os nós e também todos os arcos do GFC; por exemplo, utilizando um caso de teste que exercite a seqüência ABDEG e outro que exercite a Teste de Software: Motivação e Conceitos Básicos Página 23
  24. 24. Centro de Tecnologia da Informação Renato Archer – CTI/MCT seqüência ACDFG. No entanto, para satisfazer o critério todos os caminhos são necessários quatro casos de teste, cada um exercitando um caminho do GFC: ABDEG, ABDFG, ACDEG e ACDFG. A …; A if (x > y * 2) B { … } C else C { … } D if (z > w) E { … } F else F { … } G …; A B C D E F G Figura 10: Comandos if-then em Sequência e Respectivo Grafo de Fluxo de Controle Existem outros critérios estruturais que não serão abordados neste documento. Mais informações sobre os critérios apresentados e sobre como utilizá-los encontram-se em tutoriais específicos e em literatura especializada. 7 Ferramentas de apoio ao teste As empresas de software são cada vez mais pressionadas a produzir produtos de qualidade em curto espaço de tempo. Esta situação coloca uma forte pressão em suas equipes de teste, que são levadas a tentar aumentar a cobertura dos testes realizados sem comprometer os prazos de entrega do projeto. O emprego de ferramentas de apoio pode reduzir o esforço e aprimorar a qualidade do teste. Estas ferramentas não são suficientes para automatizar completamente o teste, mas podem auxiliar o testador na realização de diversas atividades. São exemplos de atividades de teste para as quais se encontram ferramentas de apoio: • Definição dos elementos requeridos para o teste: para as diversas técnicas são determinados elementos requeridos que podem servir de base para a criação de casos de teste; Teste de Software: Motivação e Conceitos Básicos Página 24
  25. 25. Centro de Tecnologia da Informação Renato Archer – CTI/MCT • Avaliação de cobertura atingida no teste e a identificação de elementos requeridos não exercitados: para as diversas técnicas são avaliados o nível de cobertura atingido (percentual de elementos requeridos exercitados) e os elementos requeridos ainda não exercitados. As ferramentas permitem quantificar a qualidade do teste; • Captura de eventos e de respostas do software: gravação e reprodução de informações do teste, tais como: dados de entrada, eventos de entrada, interfaces e informações mostradas; • Execução do teste: execução do software com um conjunto de casos de teste e a avaliação do resultado produzido. Ferramentas podem ser aplicadas tanto para o teste de unidade como para o teste de sistema; • Armazenamento e gerenciamento de informações de teste: manutenção de informações de teste – planos, projetos, scritps e casos de teste. Ferramentas permitem também o rastreamento de informações associando casos de teste aos requisitos do software a serem validados; • Armazenamento e gerenciamento de incidentes: registro de informações sobre incidentes ocorridos e acompanhamento da resolução; • Definição e gerenciamento do processo de teste: definição de aspectos do processo de teste como recursos, medidas, atividades e tarefas, e também o gerenciamento da execução do processo de teste. A adoção de um processo de teste para a organização (veja próximas seções) pode incluir a avaliação de quais tipos de ferramentas são adequadas aos objetivos estabelecidos para o teste. Teste de Software: Motivação e Conceitos Básicos Página 25
  26. 26. Centro de Tecnologia da Informação Renato Archer – CTI/MCT 8 Processo e documentação do teste: como organizar o trabalho A adoção de um processo bem estabelecido para realizar as diversas atividades da engenharia de software contribui positivamente para que se alcance o objetivo pretendido. Um processo é um conjunto de passos parcialmente ordenados, constituídos por atividades, métodos, práticas e transformações, usado para atingir uma meta. A atividade de teste de software também deve ser conduzida por meio de um processo bem estabelecido. Um processo de teste de software é um conjunto de passos parcialmente ordenados constituídos por atividades, métodos e práticas, usadas para testar um produto de software. Um exemplo de modelo de processo de teste é o ArtProTest (“Artifact Oriented Process Model for Testing”) 12,13. Este modelo é baseado em artefatos de teste determinados na Norma IEEE Std 829-1998 14 e é formado por subprocessos, definidos e ordenados de forma a permitir que o teste seja eficiente e eficaz. No subprocesso Planejar é criado o Plano de Teste de Software, que contém, dentre outras informações: extensão e abordagem do teste; recursos necessários, equipe e treinamento, cronograma de atividades; ambiente operacional; itens a serem testados, o nível e abordagem de teste para cada item, atividades, tarefas e respectivos responsáveis, além de riscos e planos de contingência no teste. O subprocesso Projetar envolve: refinar a abordagem de teste, definir e especificar os casos de teste; estabelecer o ambiente e procedimentos de teste. O subprocesso Executar envolve: executar, registrar, suspender, retomar, parar, encerrar e tratar as contingências no teste. O subprocesso Registrar visa relatar a execução dos testes e os incidentes observados (defeito no software ou anomalia de funcionamento do ambiente). Também são sumarizados os resultados do teste e as avaliações baseadas nesses resultados. 12 Crespo, A. N.; Silva, O. J. ; Borges, C. A.; Salviano, C. F.; Argollo Junior, M. T. E.; Jino, M. “Uma Metodologia para Teste de Software no Contexto da Melhoria de Processo”. III Simpósio Brasileiro de Qualidade de Software, 2004. v. 3. p. 271-285. 13 Bueno, P.M.S., Crespo A.N., Jino, M., “Analysis of an Artifact Oriented Test Process Model and of Testing Aspects of CMMI”. In: 7th International Conference on Product Focused Software Process Improvement, Amsterdam., Lecturer Notes in Computer Science. Berlin: Springer-Verlag, 2006. v. 4034. p. 263-277. 14 IEEE Std 829 (1998), “IEEE Standard for Software Test Documentation”, IEEE, New York. Teste de Software: Motivação e Conceitos Básicos Página 26
  27. 27. Centro de Tecnologia da Informação Renato Archer – CTI/MCT É importante destacar que existem diversas atividades associadas a cada subprocesso descrito anteriormente, que criam ou utilizam os artefatos que documentam o teste (plano de teste, projetos de teste, etc). A definição de como esta informação de teste deve ser estruturada em artefatos (isto é, a definição de “templates” de teste) é uma etapa importante da implantação de um processo de teste em uma organização. O processo de teste deve ser alinhado com o processo de desenvolvimento como um todo. Uma alternativa é organizar os subprocessos de teste considerando as principais fases do processo de desenvolvimento e associando a cada fase o nível de teste de software correspondente – unidades, integração, sistema e aceitação (Modelo V). As atividades de teste podem ser iniciadas junto com as atividades de desenvolvimento, logo que as informações necessárias estejam disponíveis. Neste caso, o planejamento do teste deve ser realizado junto com o planejamento do desenvolvimento, enquanto que o projeto do teste de aceitação pode ser iniciado logo que os requisitos do software tenham sido definidos. A execução de atividades de teste o mais cedo possível diminui as chances de que esta atividade seja feita de forma apressada no final do projeto, devido à necessidade de entregar o produto ao cliente. Alguns modelos de processo de desenvolvimento de software, como o Espiral ou o RUP, definem iterações (ou ciclos) para o desenvolvimento do software. Ao invés da realização seqüencial das atividades de desenvolvimento do software, como no tradicional modelo “cascata” 15, são definidas iterações para o desenvolvimento e incrementos (ou releases) são associados a cada iteração. Cada incremento envolve a realização das atividades para: definição de requisitos, projeto, implementação, integração e testes. Nestes casos, as atividades de teste devem ser associadas às atividades de desenvolvimento em cada iteração, de modo que haja o adequado replanejamento, projeto, execução e registro dos testes. Recomenda-se realizar um planejamento global do teste junto com o planejamento do desenvolvimento. O teste final do sistema e o teste de aceitação são executados após o término da última iteração do processo de desenvolvimento. 15 Tipicamente, as atividades realizadas no modelo cascata são: análise de requisitos; projeto do software; implementação e teste de unidades; integração e teste de integração; teste de sistema; implantação e teste de aceitação. Teste de Software: Motivação e Conceitos Básicos Página 27
  28. 28. Centro de Tecnologia da Informação Renato Archer – CTI/MCT Alguns modelos mais recentes enfatizam o projeto de testes e sua execução como um elemento central do desenvolvimento do software. A abordagem Desenvolvimento Baseado em Testes (ou TDD, sigla em inglês) é frequentemente adotada em métodos ágeis, como a Programação Extrema (XP). No TDD os casos de teste são criados pelos desenvolvedores antes mesmo que o código fonte seja criado. 9 Análise de riscos: priorizar aspectos para o teste Em muitos casos o software em teste possui algumas partes (ou funcionalidades) nas quais a ocorrência de uma falha pode acarretar graves conseqüências a seus usuários, podendo impactar negativamente seus negócios e eventualmente até mesmo colocar a integridade de vidas humanas em risco. Por outro lado, o mesmo software pode possuir partes nas quais a ocorrência de falhas, embora não desejável, não seja crítica em termos dos negócios de seus usuários, impactando-os somente de forma marginal. Neste contexto, uma preocupação fundamental do teste é avaliar as funcionalidades do software que sejam mais importantes para o negócio de seus futuros usuários e propor e desenvolver atividades de teste que abordem com o devido cuidado essas áreas. Pensar nos testes com a perspectiva dos riscos que as falhas possam provocar é um aspecto importante para o sucesso do teste. A análise de riscos deve ocorrer no planejamento do teste e deve dar subsídios para a definição de tipos e técnicas de teste a serem utilizadas em cada parte do software, assim como o quão rigoroso deve ser o teste daquela parte do software. Em última análise, a consideração dos riscos envolvidos permite alocar os recursos de teste de uma maneira prudente, dosando o rigor e o esforço do teste de cada parte do software ao nível requerido de confiabilidade. Teste de Software: Motivação e Conceitos Básicos Página 28
  29. 29. Centro de Tecnologia da Informação Renato Archer – CTI/MCT 10 Política e processo de teste: o papel do teste na estratégia da organização A definição de uma Política de Teste é fundamental para qualquer organização que pretende definir ou aprimorar as suas atividades de teste. Trata-se, portanto, de um primeiro passo importante que servirá de base para definição do processo de teste da organização. A política de teste define, de maneira geral, os objetivos e a visão estratégica em relação ao teste. Portanto, deve estar alinhada com a política de qualidade e com os objetivos de negócios da organização. Ao se estabelecer uma visão comum sobre o teste para todos os envolvidos com esta atividade, obtém-se um alinhamento das iniciativas para a utilização ou melhoria do processo de teste, tanto no desenvolvimento como na manutenção de software. Recomenda-se, portanto, que a política de teste seja documentada, divulgada e tenha um responsável definido. A definição de indicadores associados aos objetivos do teste permite a avaliação e a melhoria contínua do processo de teste na organização. Tipicamente uma política de teste aborda: objetivos e importância do teste; níveis de qualidade a serem atingidos; nível de independência da equipe de teste; principais responsabilidades; definição em alto nível do processo de teste; e separação entre teste e depuração. A partir do momento em que se estabelece “o quê” as atividades de teste devem atingir na organização – a Política de Teste – pode-se trabalhar para definir “como” os objetivos serão atingidos. A definição do “como” dá-se pelo estabelecimento de um processo de teste. Modelos de processos genéricos de teste e modelos de maturidade de teste podem servir como inspiração nesta tarefa. Um modelo de processo genérico de teste, como é o descrito na Seção 8, pode ser adaptado às necessidades específicas de cada organização. Tal tipo de modelo define um conteúdo amplo em teste (formado por atividades, métodos, artefatos, etc.) que serve como base para o estabelecimento de processos customizados, fundamentados nas necessidades de teste específicas de cada organização. O termo Estratégia de Teste também é utilizado na literatura com significado semelhante, ou seja, atividades, métodos, artefatos de teste adotados por uma organização. Teste de Software: Motivação e Conceitos Básicos Página 29
  30. 30. Centro de Tecnologia da Informação Renato Archer – CTI/MCT Modelos de maturidade de testes, tais como o Test Process Improvement (TPI) 16 ou o Test Maturity Model Integration (TMMi) 17, também podem ser utilizados para definir um processo de teste bem como para guiar a sua avaliação e melhoria. O TMMi é complementar ao modelo CMMI e aborda aspectos importantes para os gerentes e analistas de testes e demais profissionais de qualidade de software. Assim como o modelo em estágios do CMMI, o TMMi usa o conceito de níveis de maturidade para a avaliação e melhoria do processo de teste. A adoção de um processo de teste, feita por meio da customização de um modelo de processo genérico de teste, é referida como uma implantação ou configuração de um processo de teste na organização. Os modelos de processos genéricos de teste ou os modelos de maturidade do teste podem ser utilizados também para aprimorar, de forma controlada e gradual, um processo de teste já existente na organização. A implantação de um processo de teste deve ser feita de forma cuidadosa, por meio da análise das reais necessidades de teste e das possibilidades da organização. Fatores como tipo de software desenvolvido, requisitos de confiabilidade e segurança, bem como a disponibilidade de recursos humanos e financeiros da organização, devem ser levados em conta nesta implantação. Em geral, requisitos rigorosos de confiabilidade e segurança do software determinam a definição de processos de teste mais completos, contemplando vários níveis, tipos e técnicas de teste. Por outro lado, em muitos casos um processo “leve” – com poucos níveis e utilizando técnicas simples e documentando apenas o essencial – pode ser o suficiente. Processos de teste mais completos demandam um maior esforço por parte da organização, mas tendem a propiciar melhores produtos de software, além de evidências mais claras da qualidade do teste. 16 Koomen, T. and Pol M., (1999), “Test Process Improvement: A practical step-by step guide to structured testing”. ACM Press, London, England. 17 TMMi Foundation, “Test Maturity Model Integration (TMMi®) Version 2.0”, 2009. Teste de Software: Motivação e Conceitos Básicos Página 30
  31. 31. Centro de Tecnologia da Informação Renato Archer – CTI/MCT 11 Conclusão: transformando conceitos de teste em melhores produtos de software Este documento apresentou um corpo de conhecimentos fundamentais em Teste de Software. O conteúdo foi abordado mais em extensão do que em profundidade, isto é, espera-se que o leitor tenha adquirido um conhecimento amplo dos vários aspectos das atividades de teste; entretanto, é necessário o aprofundamento nos assuntos específicos conforme o interesse e os objetivos específicos. Os guias e os tutoriais de teste (em elaboração) irão prover o aprofundamento em alguns aspectos tratados de forma rápida neste documento. A literatura específica de teste também pode ser útil para este intento. Espera-se que com a aplicação do conteúdo apresentado, os diversos atores envolvidos com as questões de qualidade e teste das mais diversas organizações possam definir ou aprimorar as suas práticas de teste. Em especial, espera-se que todos os participantes que compõem o ecossistema do SPB possam se beneficiar da aplicação deste conteúdo e também possam contribuir para o aprimoramento do conhecimento público de teste de software do SPB. Teste de Software: Motivação e Conceitos Básicos Página 31

×