UNIVERSIDADE DO SUL DE SANTA CATARINA          ANDERSON ANTONIO DO NASCIMENTO DA SILVA                 MARIANA BENEDETT SE...
ANDERSON ANTONIO DO NASCIMENTO DA SILVA                 MARIANA BENEDETT SEVERINOIMPLANTAÇÃO E MELHORIA NA QUALIDADE DE AP...
ANDERSON ANTONIO DO NASCIMENTO DA SILVA                  MARIANA BENEDETT SEVERINOIMPLANTAÇÃO E MELHORIA NA QUALIDADE DE A...
Dedico este trabalho aos meus pais (José eAna) por sempre terem me apoiado eincentivado não somente para a conclusãodeste ...
AGRADECIMENTOS           Em primeiro lugar a Deus por nos ter dado forças para percorrer esse longo edificultoso trajeto, ...
"Não temos em nossas mãos a solução para todos os problemas do mundo; mas,diante dos problemas do mundo, temos nossas mãos...
RESUMOO propósito deste trabalho é fornecer uma ferramenta contendo um método simplificado quepossa auxiliar na implantaçã...
ABSTRACT       The purpose of this paper is to provide a tool containing a simplified method that canassist in the impleme...
LISTA DE ILUSTRAÇÕESFigura 1 - Pessoas envolvidas dentro da qualidade .......................................................
Quadro 6 - Manter Plano de Teste. ...........................................................................................
Figura 26 - Cadastro de caso de teste .......................................................................................
LISTA DE TABELASTabela 1 - Resultados da avaliação em abrangência por área de processo. .............................. 34T...
LISTA DE SIGLASBID - Banco Interamericano de Desenvolvimento.CMMI - Capability Maturity Model IntegrationETM - Equipe Técn...
SUMÁRIO1 INTRODUÇÃO..........................................................................................................
3.3.4 Testes de Aceitação....................................................................................................
5.2.3 Execução ..............................................................................................................
161 INTRODUÇÃO            Com a evolução tecnológica de hoje e a velocidade da comunicação imposta pelamodernização, o fat...
17           Os problemas se tornaram maiores a partir do momento em que surgiram asaplicações para internet e sistemas ma...
181.1.3 Objetivos Específicos       Realizar um estudo em Testes de Software e na metodologia a ser utilizada,         ve...
19Observa-se hoje que, para garantir a qualidade de um sistema, é necessário lidar com váriosfatores que convivem em um am...
20      e) Entrega da parte inicial do pré-projeto para avaliação.              Na terceira etapa ocorrerão os ajustes:   ...
21            O quinto capítulo aborda o processo criado, demonstrando todas as etapascontidas, tais como Inicialização, E...
222   QUALIDADE DE SOFTWARE           De acordo com a NBR ISO 9000:2000 (2000), qualidade é o grau no qual umconjunto de c...
23              Com base nas dificuldades, o responsável pela gerência de qualidade do softwaree os gerentes de cada área ...
24b) Controle de qualidade: A definição e a aprovação de processos que assegurem que os    procedimentos e os padrões de q...
25Quadro 1 - Gerenciamento da Qualidade do Projeto segundo o PMI.Fonte: PMI, 2004.2.1.1 Padrões de Qualidade             A...
26Quadro 2 - Padrões de produto e de processoFonte: Sommerville, 2003.             A definição de padrões deve ser analisa...
27Fluxograma 1 - Fluxo do gerenciamento da qualidade do processoFonte: Sommerville, 2003.2.1.3 O planejamento de Qualidade...
281. Introdução sobre o Produto: Uma descrição sobre o produto, seu mercado pretendido e as    respectivas expectativas qu...
292.1.4 Padrões de documentação             Um documento é a única maneira tangível de representar o software a serdesenvo...
302.1.5 Medição e Métricas           De acordo com Martinho (2008), o objetivo das medições, métricas e análises édirecion...
31apropriado quando o plano de métricas for produzido. No entanto, quando se apresenta umplano de métricas pela primeira v...
32servindo de orientação na fase de adaptação de um processo. Na análise de riscos, sãoconsiderados fatores como a não uti...
33Esquema 2 - Análise de RiscosFonte: Espinha, 2007.             Por fim, tem-se uma série de informações concatenadas que...
34Tabela 1 - Resultados da avaliação em abrangência por área de processo.Fonte: Espinha, 2007.Gráfico 1 - Resultados da av...
352.4   CONSIDERAÇÕES FINAIS           A busca pela qualidade de software não está somente no início do projeto, onde éfei...
363     TESTES      O presente capítulo aborda os conceitos de testes de software, bem como os tipos detestes existentes. ...
37Figura 3 - Localização da qualidade dentro da engenharia.Fonte: Molinari, 2008.             A engenharia de software mos...
38Gráfico 2 - Custo de correçõesFonte: Elaboração dos autores, 2010.             O gráfico 2 transmite a ideia de que, par...
39              Defeito é um ato inconsistente cometido por um indivíduo ao tentar entender umadeterminada informação, res...
40   a) Planejamento de Testes: é o processo de se planejar Testes. O       planejamento pode gerar um ou mais planos de T...
41              a) Critério de Teste: serve para selecionar e avaliar casos de Teste de forma a                  aumentar ...
42que o funcionamento do programa não está de acordo com o esperado pelo usuário. Porexemplo, quando um usuário da linha d...
433.1.3 Gerenciamento de Testes               Molinari (2008) declara que a gestão da qualidade representa um dos pilares ...
443.2.1 Definindo os requisitos            Para elaborar os casos de testes é necessário primeiramente levantar os requisi...
45amplitude e profundidade, mas devem ser vistos, pois sua importância pode variar entre oscenários.                    C...
46Quadro 3 - Exemplo de um Caso de Teste simples.Fonte: Pontes, 2009.             Entretanto, nada impede que sejam adicio...
47             A seguir, abordar-se-á o conceito destes e de outros tipos de Testes, bem comotécnicas de Testes Funcionais...
48           Como no teste estrutural, há diversas técnicas existentes que ajudam a executarum bom teste funcional. Durant...
493.3.4 Testes de Aceitação           São realizados geralmente por um restrito grupo de usuários finais do sistema.Esses ...
50Esquema 3 - Representação dos módulos de TesteFonte: Campos, 2009.3.3.5.2 Incremental             Um software é construí...
51             A figura abaixo representa componentes que foram estruturados de formaincremental:Esquema 4 - Testes de int...
523.3.5.4 Integração Bottom-up           Na técnica Botton-up, a integração do sistema começa a partir do nível mais baixo...
533.3.7 Teste de Estresse           Neste Teste será avaliado o comportamento do sistema sob condições críticas.Basicament...
543.3.8 Análise do Valor Limite ou Fronteira            Este Teste utiliza uma seleção dos casos de testes que põem a prov...
553.3.9 Tabela de decisão            A técnica de decisão pode ser aplicada a todas as situações quando a execução dosoftw...
563.3.10 Testes de Semântica            Segundo Freitas (2009), estes Testes devem ser usados para avaliar telas ourelatór...
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Upcoming SlideShare
Loading in...5
×

Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett

6,566

Published on

IMPLANTAÇÃO E MELHORIA NA QUALIDADE DE APLICAÇÕES ATRAVÉS DE UM SISTEMA DE GESTÃO DE TESTES.

Published in: Technology
2 Comments
1 Like
Statistics
Notes
No Downloads
Views
Total Views
6,566
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
62
Comments
2
Likes
1
Embeds 0
No embeds

No notes for slide

Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett

  1. 1. UNIVERSIDADE DO SUL DE SANTA CATARINA ANDERSON ANTONIO DO NASCIMENTO DA SILVA MARIANA BENEDETT SEVERINOIMPLANTAÇÃO E MELHORIA NA QUALIDADE DE APLICAÇÕES ATRAVÉS DE UM SISTEMA DE GESTÃO DE TESTES. Tubarão 2010
  2. 2. ANDERSON ANTONIO DO NASCIMENTO DA SILVA MARIANA BENEDETT SEVERINOIMPLANTAÇÃO E MELHORIA NA QUALIDADE DE APLICAÇÕES ATRAVÉS DE UM SISTEMA DE GESTÃO DE TESTES. Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Sistemas de Informação da Universidade do Sul de Santa Catarina, como requisito parcial à obtenção do título de Bacharel em Sistemas de Informação. Orientador: Prof. Edjandir Corrêa Costa. Tubarão 2010
  3. 3. ANDERSON ANTONIO DO NASCIMENTO DA SILVA MARIANA BENEDETT SEVERINOIMPLANTAÇÃO E MELHORIA NA QUALIDADE DE APLICAÇÕES ATRAVÉS DE UM SISTEMA DE GESTÃO DE TESTES. Este Trabalho de Conclusão de Curso foi julgado adequado à obtenção do título de Bacharel em Sistemas de Informação e aprovado em sua forma final pelo Curso de Graduação em Sistemas de Informação da Universidade do Sul de Santa Catarina. Tubarão, 14 de junho de 2010. ______________________________________________________ Prof. Rafael Avila Faraco. Universidade do Sul de Santa Catarina ______________________________________________________ Prof. Eder Cachoeira. Universidade do Sul de Santa Catarina ______________________________________________________ Prof. Alessandro Zanini. Universidade do Sul de Santa Catarina
  4. 4. Dedico este trabalho aos meus pais (José eAna) por sempre terem me apoiado eincentivado não somente para a conclusãodeste projeto, mas como em toda minha vida.(Anderson)Dedico este trabalho aos meus pais e toda aminha família pelo apoio, auxílio e educação,que me fez chegar até aqui. (Mariana)
  5. 5. AGRADECIMENTOS Em primeiro lugar a Deus por nos ter dado forças para percorrer esse longo edificultoso trajeto, muito importante em nossas vidas profissionais. A nossos pais devemos gratidão eterna por nos guiarem no caminho certo, peloapoio e incentivo que nos ajudou a seguir em frente. Aos nossos irmãos, familiares e amigos que nos auxiliaram nesse período. Aos professores e colegas que compartilharam conosco seus conhecimentos eexperiências. Ao nosso orientador Edjandir Corrêa Costa, que nos ajudou em momentos dedúvidas, fornecendo ideias que somaram no projeto.
  6. 6. "Não temos em nossas mãos a solução para todos os problemas do mundo; mas,diante dos problemas do mundo, temos nossas mãos.”(AUTOR DESCONHECIDO).
  7. 7. RESUMOO propósito deste trabalho é fornecer uma ferramenta contendo um método simplificado quepossa auxiliar na implantação de um processo de Testes de software. A ferramenta dará aogerente segurança e capacidade de medir a qualidade do seu produto. Neste trabalho,especificamente, a ferramenta elaborada pelos acadêmicos será um auxiliar no processo deTestes de software. A referida ferramenta foi desenvolvida a partir de estudos bibliográficos eeletrônicos, que serviram de base para a sua construção. A ferramenta em questão atua sob osníveis G e F do modelo de maturidade de software MPS.BR. A qualidade do software se tornahoje uma área de extrema importância para as organizações consumidoras que pretendemgarantir o seu espaço no mercado de desenvolvimento de software. Por conta disso, estasorganizações vêm procurando métodos e processos que possam avaliar a qualidade do seuproduto final. A área de Testes se mostra peça chave para a validação e a garantia de que oproduto está apto a ser entregue ao cliente da forma como foi solicitado. Observa-se hoje aimaturidade que as empresas têm na área Testes. Grande parte delas realiza seus Testesjuntamente com o desenvolvimento de software e, até mesmo, utilizando o usuário final dosistema, o que não é recomendado pelos conceituados processos de qualidade de software.Nesse sentido, os autores dessa monografia acreditam na importância dessa ferramenta para odesenvolvimento de softwares com qualidade.Palavras-chave: Qualidade de software. Testes de software. Processo de Teste.
  8. 8. ABSTRACT The purpose of this paper is to provide a tool containing a simplified method that canassist in the implementation of a process of Testing Software. The tool will give the managersecurity and ability to measure the quality of your product. In this work, specifically, the tooldeveloped by academiwill be a help in the process of Testing Software. This tool wasdeveloped from studies of bibliographic and electronic, which formed the basis for itsconstruction. The tool in question operates under the G and F levels of maturity model forsoftware MPS.BR. The quality of the software now becomes an area of extreme importancefor organizations to consumers wanting to ensure their place in the market for softwaredevelopment. Because of this, these organizations have been searching for methods andprocesses that can assess the quality of your final product. The area of Testing proves is a keypiece for the validation and assurance that the product is suitable to be delivered to thecustomer as it was requested. It is observed today immaturity that companies have in the fieldTests. Many of them realize their tests along with the development of software and even usingthe end user of the system, which is not recommended by reputable software qualityprocesses. In this sense, the authors of this monograph believe in the importance of this toolfor the development of software quality.Key words: software quality. Testing softwares. Testing process.
  9. 9. LISTA DE ILUSTRAÇÕESFigura 1 - Pessoas envolvidas dentro da qualidade .................................................................. 23Esquema 1 - Sincronismo entre desenvolvimento e Gerenciamento de Qualidade. ................ 24Quadro 1 - Gerenciamento da Qualidade do Projeto segundo o PMI. ..................................... 25Quadro 2 - Padrões de produto e de processo .......................................................................... 26Fluxograma 1 - Fluxo do gerenciamento da qualidade do processo ........................................ 27Figura 2 - Atributos de Qualidade do software ........................................................................ 28Esquema 2 - Padrões de intercâmbio de documentos .............................................................. 29Esquema 3 - Análise de Riscos ................................................................................................ 33Gráfico 1 - Resultados da avaliação em abrangência - ameaças .............................................. 34Figura 3 - Localização da qualidade dentro da engenharia. ..................................................... 37Gráfico 2 - Custo de correções ................................................................................................. 38Figura 4 - Defeito x Erro x Falha ............................................................................................. 39Figura 5 - Diferentes interpretações ao longo do ciclo de desenvolvimento de um software. . 42Quadro 3 - Exemplo de um Caso de Teste simples. ................................................................. 46Figura 6 - Componentes existentes em Testes caixa preta. ...................................................... 47Esquema 4 - Representação dos módulos de Teste .................................................................. 50Esquema 5 - Testes de integração. ........................................................................................... 51Figura 7 - Componentes existentes em Testes caixa branca. ................................................... 57Figura 8 - Níveis de refinamento. ............................................................................................. 58Figura 9 - Laços existentes nos Testes de ciclo. ....................................................................... 60Esquema 6 - Componentes do modelo MPS. ........................................................................... 63Diagrama 1 - Visão geral do Processo de Teste. ...................................................................... 73Diagrama 2 - Visão detalhada do processo de inicialização .................................................... 74Quadro 4 - Caso de Teste ......................................................................................................... 76Quadro 5 - Plano de Teste ........................................................................................................ 77Diagrama 3 - Visão detalhada do processo de Execução. ........................................................ 78Diagrama 4 - Visão detalhada do processo de Finalização. ..................................................... 80Figura 10 - Arquitetura de aplicações em padrão de projeto MVC.......................................... 83Esquema 7 - Arquitetura da aplicação. ..................................................................................... 84Diagrama 5 - Diagrama de Casos de Uso. ................................................................................ 85
  10. 10. Quadro 6 - Manter Plano de Teste. ........................................................................................... 86Quadro 7 - Manter Plano de Teste. ........................................................................................... 86Quadro 8 - Manter Plano de Teste. ........................................................................................... 87Quadro 9 - Manter Caso de Teste ............................................................................................. 87Quadro 10 - Executar Plano de Teste ....................................................................................... 88Quadro 11 - Gerenciar processo. .............................................................................................. 88Quadro 12 - Manter Usuário e Grupo. ...................................................................................... 89Diagrama 6 - Diagrama de domínio de Classe. ........................................................................ 90Quadro 13 - Descrição das classes ........................................................................................... 90Diagrama 7 - Diagrama geral de pacotes.................................................................................. 92Diagrama 8 - Diagrama de pacotes entitys. .............................................................................. 93Diagrama 9 - Diagrama de pacotes repository. ........................................................................ 94Diagrama 10 - Diagrama de pacotes service. ........................................................................... 95Diagrama 11 - Diagrama de pacotes DAO. .............................................................................. 96Diagrama 12 - Pacotes manager. .............................................................................................. 96Diagrama 13 - Pacotes servlet. ................................................................................................. 97Diagrama 14 - Diagrama de pacotes infrastructure. ................................................................ 97Diagrama 15 - Diagrama de pacotes view. ............................................................................... 98Diagrama 16 - Modelo de ER- Relacionamento entre tabelas. ................................................ 99Figura 11 - Tela de login ........................................................................................................ 105Figura 12 - Menu do usuário gerente de teste ........................................................................ 106Figura 13 - Menu do usuário analista de teste ........................................................................ 106Figura 14 - Menu do usuário Tester ....................................................................................... 107Figura 15 - Lista de usuários .................................................................................................. 107Figura 16 - Cadastro de usuário.............................................................................................. 108Figura 17 - Lista de grupo de usuários ................................................................................... 108Figura 18 - Cadastro de grupo de usuário............................................................................... 109Figura 19 - Lista tipo de teste ................................................................................................. 110Figura 20 - Cadastro de tipo de teste ...................................................................................... 110Figura 21 - Lista de prioridade ............................................................................................... 111Figura 22 - Cadastro de prioridade ......................................................................................... 111Figura 23 - Lista de plano de teste .......................................................................................... 112Figura 24 - Cadastro de plano de teste ................................................................................... 113Figura 25 - Lista de caso de teste ........................................................................................... 114
  11. 11. Figura 26 - Cadastro de caso de teste ..................................................................................... 115Figura 27 - Lista de ciclos de execução do plano de teste ...................................................... 115Figura 28 - Execução do plano de teste .................................................................................. 116Figura 29 - Notas da execução do plano de teste ................................................................... 117Figura 30 - Filtros do relatório de log de Teste ...................................................................... 117Figura 31 - Visualização do relatório de log de Teste ............................................................ 118Figura 32 - Filtros do relatório de Incidentes ......................................................................... 118Figura 33 - Visualização do relatório de incidentes ............................................................... 118Figura 34 - Filtros do relatório de sumário ............................................................................. 119Figura 35 – Visualização do relatório de sumário .................................................................. 119
  12. 12. LISTA DE TABELASTabela 1 - Resultados da avaliação em abrangência por área de processo. .............................. 34Tabela 2 - Refinamento utilizando Valores-Limites. ............................................................... 54Tabela 3 - Exemplo de uma tabela de decisão.......................................................................... 55Tabela 4 - Tabela dos representando níveis do MPS.BR. ........................................................ 64Tabela 5 - Dicionário de dados entidade usuário. .................................................................. 100Tabela 6 - Dicionário de dados entidade prioridade. .............................................................. 100Tabela 7 - Dicionário de dados entidade tipos de Teste. ........................................................ 101Tabela 8 - Dicionário de dados entidade grupo. ..................................................................... 101Tabela 9 - Dicionário de dados entidade de ligação entre grupo e usuário. ........................... 101Tabela 10 - Dicionário de dados entidade plano de Teste ...................................................... 102Tabela 11 - Dicionário de dados entidade caso de Teste ........................................................ 103Tabela 12 - Dicionário de dados entidade ciclo de Teste ....................................................... 104Tabela 13 - Dicionário de dados entidade ciclo de Teste notas.............................................. 104
  13. 13. LISTA DE SIGLASBID - Banco Interamericano de Desenvolvimento.CMMI - Capability Maturity Model IntegrationETM - Equipe Técnica do Modelo.FCC - Fórum de Credenciamento e Controle.FINEP - Financiadora de Estudos e Projetos.IA - Instituições Avaliadoras.IEE - Institute of Electrical and Electronics EngineersII - Instituições Implementadoras.MA-MPS - Modelo de Avaliação - Melhoria de Processo de Software.MCT - Ministério da Ciência e Tecnologia.MN-MPS - Modelo de Negocio - Melhoria de Processo de Software.MPS.BR - Melhoria de Processo de Software Brasileiro.MR-MPS - Modelo de Referencia - Melhoria de Processo de Software.MVC – Model View Controler – Padrao de projetoNIST - National Institute of Standards and TechnologyRIA – Rich Internet ApplicationSOFTEX - Associação para Promoção da Excelência do Software Brasileiro.
  14. 14. SUMÁRIO1 INTRODUÇÃO................................................................................................................. 161.1 OBJETIVOS .................................................................................................................... 171.1.2 Objetivo Geral ............................................................................................................. 171.1.3 Objetivos Específicos................................................................................................... 181.2 RESULTADOS ESPERADOS ........................................................................................ 181.3 JUSTIFICATIVA ............................................................................................................ 181.4 METODOLOGIA ............................................................................................................ 191.5 APRESENTAÇÃO DO DOCUMENTO ......................................................................... 202 QUALIDADE DE SOFTWARE....................................................................................... 222.1 GERENCIAMENTO DE QUALIDADE ........................................................................ 232.1.1 Padrões de Qualidade ................................................................................................. 252.1.2 Qualidade do Processo e do Produto. ........................................................................ 262.1.3 O planejamento de Qualidade.................................................................................... 272.1.4 Padrões de documentação .......................................................................................... 292.1.5 Medição e Métricas ..................................................................................................... 302.2 SOFTWARE QUALITY ASSURANCE .......................................................................... 312.3 ANÁLISE DE RISCOS ................................................................................................... 312.4 CONSIDERAÇÕES FINAIS ........................................................................................... 353 TESTES ............................................................................................................................. 363.1 VISÃO DE TESTES DE SOFTWARE ............................................................................ 363.1.1 Conceitos de Testes...................................................................................................... 383.1.2 Defeitos do desenvolvimento ...................................................................................... 413.1.3 Gerenciamento de Testes ............................................................................................ 433.2 REQUISITOS E CASOS DE TESTES ........................................................................... 433.2.1 Definindo os requisitos ................................................................................................ 443.2.2 Definindo casos de testes ............................................................................................. 443.3 TIPOS DE TESTES ......................................................................................................... 463.3.1 Teste Funcional............................................................................................................ 473.3.2 Testes de Unidade ........................................................................................................ 483.3.3 Testes de Sistema ......................................................................................................... 48
  15. 15. 3.3.4 Testes de Aceitação...................................................................................................... 493.3.5 Testes de Integração .................................................................................................... 493.3.5.1 Não Incremental ......................................................................................................... 493.3.5.2 Incremental ................................................................................................................. 503.3.5.3 Integração Top-down.................................................................................................. 513.3.5.4 Integração Bottom-up ................................................................................................. 523.3.6 Teste de Regressão ...................................................................................................... 523.3.7 Teste de Estresse .......................................................................................................... 533.3.8 Análise do Valor Limite ou Fronteira ....................................................................... 543.3.9 Tabela de decisão......................................................................................................... 553.3.10 Testes de Semântica .................................................................................................... 563.3.11 Testes Estruturais ........................................................................................................ 563.3.11.1 Técnicas de Testes Estruturais.................................................................................... 573.3.11.1.1 Cobertura de Linha de Código ................................................................................ 583.3.11.1.2 Cobertura de Caminhos ........................................................................................... 583.3.11.1.3 Cobertura de Decisões ............................................................................................ 593.3.11.1.4 Cobertura de Condições .......................................................................................... 593.3.11.1.5 Testes de Ciclos ....................................................................................................... 593.4 CONSIDERAÇÕES FINAIS ........................................................................................... 604 METODOLOGIA UTILIZADA: MPS.BR .................................................................... 624.1 NIVEL G – PARCIALMENTE GERENCIADO ............................................................ 644.1.1 Gerência de Projetos (GPR) ....................................................................................... 654.1.2 Gerência de Requisitos (GRE) ................................................................................... 654.2 NÍVEL F – GERENCIADO ............................................................................................ 664.2.1 Aquisição (AQU) ......................................................................................................... 664.2.2 Gerência de Configuração (GCO) ............................................................................. 674.2.3 Garantia de Qualidade (GQA) ................................................................................... 684.2.4 Medição (MED) ........................................................................................................... 694.3 CONSIDERAÇÕES FINAIS ........................................................................................... 705 DEFINIÇÃO E ELABORAÇÃO DO PROCESSO DE TESTE .................................. 715.1 PROCESSO ..................................................................................................................... 715.2 FASES.............................................................................................................................. 715.2.1 Papéis do Processo ....................................................................................................... 725.2.2 Inicialização ................................................................................................................. 74
  16. 16. 5.2.3 Execução ....................................................................................................................... 785.2.4 Finalização ................................................................................................................... 806 DESENVOLVIMENTO DO SISTEMA DE TESTES .................................................. 816.1 VISÃO GERAL ............................................................................................................... 826.1.1 Arquitetura .................................................................................................................. 826.2 MODELO CONCEITUAL .............................................................................................. 846.2.1 Diagrama de Caso de Uso ........................................................................................... 846.2.2 Descrição dos Casos de Uso ........................................................................................ 856.2.2.1 Manter Tipos de Teste ................................................................................................ 866.2.2.2 Manter Prioridade ....................................................................................................... 866.2.2.3 Manter Plano de Teste ................................................................................................ 876.2.2.4 Manter Caso de Teste ................................................................................................. 876.2.2.5 Executar Plano de Teste ............................................................................................. 886.2.2.6 Gerenciar Processos.................................................................................................... 886.2.2.7 Manter usuário e grupo ............................................................................................... 896.2.3 Modelo de Domínio de Classe .................................................................................... 906.3 PROJETO FÍSICO ........................................................................................................... 916.3.1 Diagrama de pacotes ................................................................................................... 916.3.2 Modelo E.R. ................................................................................................................. 996.3.3 Dicionário de Dados .................................................................................................. 1007 VALIDAÇÃO DA FERRAMENTA ............................................................................. 1058 CONCLUSÃO ................................................................................................................. 120REFERÊNCIAS ................................................................................................................... 122
  17. 17. 161 INTRODUÇÃO Com a evolução tecnológica de hoje e a velocidade da comunicação imposta pelamodernização, o fator Qualidade está mais elevado na pirâmide estratégica, tornando-sefundamental para assegurar a estabilidade de uma empresa. À medida que o acesso aoconhecimento se torna mais ágil, há também uma preocupação maior com a qualidade de umproduto/serviço oferecido. Comprometimento este que faz com que as empresas busquem porplanos agregando maior qualidade possível em seus projetos, com objetivo de satisfazer asexpectativas do cliente. Tratando de qualidade de software, pode-se dizer que está ligada diretamente aodesenvolvimento. Sendo assim, o foco de qualidade de uma aplicação está necessariamentevinculado à melhoria no processo de desenvolvimento do produto abrangendo conformidadecom padrões, definição de práticas consistentes, garantia de expectativas, Testes, revisõestécnicas, entre outros. Um dos papéis extremamente importantes desempenhados durante o processo dedesenvolvimento ligado à qualidade do software é o processo de Testes de software. Eleexecuta uma análise e verificação, assegurando que o software cumpra com o que foiespecificado durante o período de análise e atenda a necessidade do cliente. Kruchten, em seu livro The rational unified process, mencionado em Bastos eoutros (2007), propõe que existem pelo menos três dimensões de qualidade que precisam serconsideradas antes de se iniciar qualquer ciclo de Testes:  Confiança: o sistema é resistente a falhas durante a execução, isto é, não entra em loop, não interrompe a execução por falta de recursos, etc.  Funcionalidade: o sistema se comporta conforme o esperado e definido em seus requisitos.  Performance: o sistema tem um tempo de resposta adequado e aceitável, mesmo quando submetido a um volume de processamento próximo de situações reais ou de pico. Entre as décadas de 1970 a 1990, os Testes eram executados pelos própriosdesenvolvedores, com um nível de cobertura bastante reduzido. Muitas vezes, os usuáriosfinais eram envolvidos nestes Testes. Isto gerava uma grande incidência de erros, que eramcorrigidos no momento em que o sistema já estava em produção, ou seja, no momento em queesta correção se tornaria mais cara.
  18. 18. 17 Os problemas se tornaram maiores a partir do momento em que surgiram asaplicações para internet e sistemas mais complexos, devido a novas tecnologias. Estes fatoresfizeram com que as organizações começassem a busca pela melhoria na qualidade do softwaredesenvolvido por seus técnicos. Um dos caminhos seria um processo paralelo paraaprimoramento da atividade de Teste. (BASTOS et al., 2007). Foi utilizado nesta monografia o conceito de Testes de Molinari (2008), que tratada gerência, planejamento, controle e execução dos Testes em todos os níveis, de modo agarantir a implementação (projeto, desenvolvimento e entrega). Neste trabalho será desenvolvido uma ferramenta auxiliar no processo de Testes.Aplicada a ela, um modelo de Testes aderente até o segundo nível da metodologia MPS.BR(Melhoria de processo de Software Brasileiro).1.1 OBJETIVOS Serão apresentados neste momento os objetivos referentes ao trabalhodesenvolvido.1.1.2 Objetivo Geral Desenvolver, a partir de um estudo sobre processo de Testes, e após uma pesquisasobre as ferramentas de Testes já utilizadas, um software para apoio à gestão de Testes,implementando um processo aderente ao modelo MPS.BR até o nível F.
  19. 19. 181.1.3 Objetivos Específicos  Realizar um estudo em Testes de Software e na metodologia a ser utilizada, verificando sua viabilidade;  Definir um processo de Testes de software que descreva as atividades a serem executadas utilizando os conceitos de Testes de software e MPS.BR;  Realizar a análise e desenvolvimento do sistema a ser criado baseado no processo de Testes já definido;  Realizar uma validação da ferramenta desenvolvida.1.2 RESULTADOS ESPERADOS Partindo-se das hipóteses de que as ferramentas existentes são poucas, ou seja,insuficientes para atender à necessidade de gerenciamento do processo de Testes; e de queelas não oferecem um processo simplificado capaz de auxiliar na implantação do processo deTestes de software, os acadêmicos envolvidos nesta pesquisa optaram por desenvolver umanova ferramenta. Espera-se que a solução consista em um método simplificado para implantação deum processo de Testes, atendendo às áreas de Planejamento de Testes, Execução dos Testes eAnálise do Produto testado, assim como as demais figuras envolvidas no processo de Testes. Por fim, a ferramenta permitirá o acompanhamento do processo por meio derelatórios que devem auxiliar na tomada de decisão.1.3 JUSTIFICATIVA Testar um software hoje vai além de um modismo ou uma “simples prática”.Afinal, não há outra forma de garantir a funcionalidade de um software sem antes testá-la.
  20. 20. 19Observa-se hoje que, para garantir a qualidade de um sistema, é necessário lidar com váriosfatores que convivem em um ambiente, tais como: client-serves, mainframe e agora a Web.(MOLINARI, 2008). Existem hoje, no mercado de trabalho, inúmeros profissionais com experiência emuma determinada área, executando Testes funcionais em uma rotina que domina, e com isso,passa a executá-la sempre. Estes são chamados os Testes viciados. É essa a realidade demuitos analistas de softwares, mas que tende a mudar em breve à medida que se depara comaplicativos cada vez maiores, em diversos ambientes e de alta complexibilidade. Um dos principais objetivos na área de Testes é reduzir erros e agregar qualidadeao software. Para isso, é necessário um processo de Testes que se adapte da melhor forma aoprocesso de desenvolvimento e que, além da organização, possa enquadrar os diversos tiposde Testes cabíveis a cada tipo de aplicação. Cabe aqui um software que englobe estesrequisitos e que possa auxiliar de forma precisa uma empresa que planeja melhorar aqualidade do seu software, proporcionando um ganho real em seus produtos. Baseando-se nas ideias acima mencionadas, acredita-se na importância da criaçãodessa ferramenta para auxiliar o gerenciamento de Testes em nível empresarial.1.4 METODOLOGIA A monografia será desenvolvida basicamente em quatro etapas. Na primeira,haverá uma reunião da equipe para estruturar a idéia inicial e garantir a sua viabilidade. Apósobter a aprovação da proposta entregue ao professor da disciplina Projetos I, é iniciada asegunda etapa, que consiste em montar a primeira parte, o Pré-Projeto. Este acontecerá naseguinte ordem: a) Pesquisa sobre as metodologias de maturidade de software e gerenciamento de projetos, conceitos e processos que envolvem o Teste de software; b) Estudo sobre ferramentas existentes relacionadas à gestão de Testes; Testesautomatizados e planejamento; c) Estudo sobre as tecnologias que poderão ser aplicadas no desenvolvimento dosoftware final; d) Início o pré-projeto que deverá conter os tópicos Introdução e Revisão bibliográfica;
  21. 21. 20 e) Entrega da parte inicial do pré-projeto para avaliação. Na terceira etapa ocorrerão os ajustes: a) Ajustar o documento conforme erros/sugestões apontadas pelos avaliadores; b) Iniciar a modelagem nível conceitual do projeto, esta que representa a segunda parte do Pré-Projeto; c) Finalizar a modelagem nível conceitual do projeto; d) Entregar para avaliação o pré-projeto finalizado; Na quarta e última etapa, após a avaliação e aprovação do Projeto de Conclusãode Curso I, dar-se-á início à construção da ferramenta. a) Definição das tecnologias que serão aplicadas no desenvolvimento da ferramenta; b) Construção do banco de dados, baseado no modelo relacional existente no projeto conceitual; c) Construção da aplicação; d) Validação da ferramenta.1.5 APRESENTAÇÃO DO DOCUMENTO Este documento foi dividido e organizado em capítulos para que o leitor possacompreender melhor o assunto que será abordado. O capítulo em questão apresenta o problema, o objetivo do trabalho, suaabrangência e o motivo da sua realização. No capítulo capitulo seguinte, será abordado oconceito Qualidade de Software, abrangendo sua definição e importância dentro do processode desenvolvimento de software. O terceiro capítulo enfatiza os Testes, etapa que compõe oitem “qualidade de software” sendo uma das áreas mais importantes para garantia daqualidade de um produto. Aborda ainda tipos de Testes, explicando a importância dos casosde Testes no momento em que é realizado um Teste. O capítulo quatro apresenta a metodologia utilizada como embasamento teóricopara a definição do processo e a definição do processo em si. Serão citadas as etapas doprocesso de gestão de Testes definido, apontando as atividades e papéis que compõem cadaetapa.
  22. 22. 21 O quinto capítulo aborda o processo criado, demonstrando todas as etapascontidas, tais como Inicialização, Execução e Finalização. Cada etapa contém todas asatividades a serem executadas. O sexto capítulo apresenta o sistema construído conforme o processoanteriormente criado e mencionado no capítulo anterior, sua arquitetura e modelagem. Apósisso, será demonstrada a validação do sistema, exemplificando cada etapa do sistema por meiode suas telas. Conforme orientação recebida, este trabalho apresentará breves consideraçõesfinais para cada capitulo, pelo fato de cada um deles apresentar uma finalidade diferente. Por fim, serão apresentadas as considerações finais relativas ao trabalho em suatotalidade, capítulo no qual serão expostas ideias confirmando (ou não) as hipóteses eobjetivos levantados, bem como as prováveis contribuições deste trabalho na área dedesenvolvimento de software.
  23. 23. 222 QUALIDADE DE SOFTWARE De acordo com a NBR ISO 9000:2000 (2000), qualidade é o grau no qual umconjunto de características inerentes satisfaz os requisitos mencionados. Ou seja, pode-sedizer que, quando um produto e/ou serviço cumpre com os requisitos levantados atendendo anecessidade para o qual foi projetado, este produto e/ou serviço possui qualidade. Rocha acrescenta outras considerações sobre o conceito Qualidade: No processo de desenvolvimento de software a comunicação da informação passa por diversas fases e pessoas, e ela pode sofrer transformações o que propicia que ocorram enganos, interpretações errôneas e outras faltas, que podem desencadear falhas. Com isso é possível afirmar que ao longo de todo o processo de desenvolvimento de software, defeitos podem ser inseridos, então se torna necessário rastreá-los o quanto antes. (ROCHA, 2001, p. 66). A qualidade de software pode ser definida ainda como a “Conformidade arequisitos funcionais e de desempenho explicitamente declarados, a padrões dedesenvolvimento claramente documentados e a características implícitas que são esperadas detodo software profissionalmente desenvolvido.” (PRESSMAN, 1995, p. 724). Na opinião de Sommerville (2003), atingir um nível de qualidade é o objetivo damaioria das organizações. Não é aceitável entregar produtos de baixa qualidade e que tenhamque ser reparados após a entrega ao cliente. Assim como qualquer outro produtomanufaturado como um Carro, eletrônicos, eletrodomésticos e computadores, o software é umproduto pelo qual o cliente exige um bom funcionamento. Entretanto, tratar de qualidade desoftware não é uma tarefa simples, pois envolve uma série de conceitos complexos e questõesque devem ser avaliadas. Durante o desenvolvimento de um software, é comum encontrarobstáculos que possam impedir que o software seja entregue conforme sua especificação. A especificação deve ser orientada em direção às características do produto que ocliente deseja. Contudo, a organização de desenvolvimento pede também requisitos (como osrequisitos de facilidade de manutenção) que não estão incluídos na especificação. Não se sabe como especificar certas características de qualidade (por exemplo, afacilidade de manutenção) de uma maneira que não seja ambígua. “[...] é muito difícil escrever uma especificação completa de software. Portanto, embora um produto de software possa atender à sua especificação, os usuários podem não considerá-lo como um produto de alta qualidade.” Sommerville (2007, p. 458).
  24. 24. 23 Com base nas dificuldades, o responsável pela gerência de qualidade do softwaree os gerentes de cada área do desenvolvimento trabalham de forma a encontrar melhoresmétodos para aplicar às especificações, buscando atender a todos.Figura 1 - Pessoas envolvidas dentro da qualidadeFonte: Falbo, 2008. O Gerente de Qualidade exerce seu papel apoiando todos os envolvidos no projetoe encorajando-os em sua atividade.2.1 GERENCIAMENTO DE QUALIDADE Como foi dito anteriormente, é de responsabilidade dos gerentes a garantia donível de qualidade do seu produto. Eles visam criar uma Cultura de Qualidade, aplicandouma série de padrões e procedimentos que deverão ser utilizados durante a execução de umprojeto. Conforme Sommerville (2003), o gerenciamento de qualidade parte de três atividadesprincipais:a) Garantia de Qualidade: O estabelecimento de uma estrutura de procedimentos e padrõesorganizacionais.a) Planejamento de qualidade: A seleção de procedimentos e de padrões organizacionais.
  25. 25. 24b) Controle de qualidade: A definição e a aprovação de processos que assegurem que os procedimentos e os padrões de qualidade de projetos sejam seguidos pela equipe de desenvolvimento de software. O autor acima mencionado ainda afirma que o gerenciamento de qualidadefornece uma verificação independente sobre o processo. Os projetos finalizados ou produtosjá entregues são posteriormente avaliados por uma equipe de qualidade que deve serindependente do gerenciamento do projeto, pois desta forma se terá uma visão objetiva doprocesso, podendo reportar problemas e dificuldades com mais facilidade à gerência sênior. Ailustração abaixo apresenta a relação explicitada.Esquema 2 - Sincronismo entre desenvolvimento e Gerenciamento de Qualidade.Fonte: Sommerville, 2003. O gerenciamento de qualidade inclui todas as atividades da organização executoraque determinam as responsabilidades, os objetivos e as políticas de qualidade, de modo que oprojeto atenda às necessidades que motivaram sua realização. É implementado o sistema degerenciamento da qualidade através da política, dos procedimentos e dos processos deplanejamento da qualidade, garantia da qualidade e controle da mesma, com atividadesde melhoria contínua dos processos, conduzidas do início ao fim, conforme adequado. (PMI,2004, p.179). Os itens que compõem o gerenciamento de qualidade estão representados noquadro abaixo.
  26. 26. 25Quadro 1 - Gerenciamento da Qualidade do Projeto segundo o PMI.Fonte: PMI, 2004.2.1.1 Padrões de Qualidade As atividades e procedimentos que são definidos no gerenciamento da garantia dequalidade exigem uma estrutura de padrões que devem ser aplicados durante todo o processode desenvolvimento. Os dois padrões principais que podem ser definidos são: Padrões deProduto e Padrões de Processo. O primeiro trata de padrões que se aplicam ao produto,incluindo estrutura de documento de requisitos, padrões de documentação (como cabeçalho,itens, nomenclaturas), padrões de codificação, entre outros. Já o segundo define o fluxo doprocesso a ser seguido durante o desenvolvimento e validação, incluindo definições deespecificação e uma série de documentos que devem ser gerados durante o fluxo.(SOMMERVILLE, 2003). O quadro abaixo ilustra esta situação.
  27. 27. 26Quadro 2 - Padrões de produto e de processoFonte: Sommerville, 2003. A definição de padrões deve ser analisada para que não ocorram problemasrelacionados a padrões não apropriados. É importante decidir quais os padrões que devem serutilizados sem alterações e quais podem ser alterados. (SOMMERVILLE, 2003).2.1.2 Qualidade do Processo e do Produto. O propósito da Garantia da Qualidade do Processo e Produto é munir a equipe e agerência com uma visão clara sobre os processos e seus produtos de trabalho associados.(CMMI – DEV , 2003 apud JUNQUEIRA, 2009). Existe aqui uma nítida ligação entre os dois itens. A qualidade do software élargamente determinada pela qualidade do processo utilizado, que tem por finalidade a criaçãode um produto. Um é diretamente afetado pelo outro. Então, quando um produto final não éconcluído com qualidade, certamente há um fator causador dentro do processo responsávelpelo insucesso no produto final. Nessa situação, é necessária a medição dos atributos desoftware, tais como facilidade de manutenção, desempenho da aplicação, funcionalidade,fatores internos e externos ao processo para que seja realizada a sua melhoria. Para isso, éimportante que sejam realizadas atividades como as revisões e monitoramento no processo.(SOMMERVILLE, 2003). A seguir, apresenta-se um fluxograma ilustrativo.
  28. 28. 27Fluxograma 1 - Fluxo do gerenciamento da qualidade do processoFonte: Sommerville, 2003.2.1.3 O planejamento de Qualidade Planejamento de Qualidade: “Identificação dos padrões de qualidade relevantespara o projeto e determinação de como satisfazê-los.” (PMI, 2004, p.179). Para obter um processo e produto de qualidade, é necessário que se tenha umplanejamento dos objetivos claramente descritos e de fácil compreensão a toda equipeenvolvida no projeto. Ele serve também para avaliar o nível de qualidade que tem o produto. O planejamento de qualidade inclui um conjunto de ações que fazem com que osrequisitos sejam cumpridos. Esta tarefa não é simples. Segundo o National Institute ofStandards and Technology (NIST), aludido por Sommerville (2003), 80% dos custos dedesenvolvimento de aplicativos se destinam à identificação e à correção de erro. Desta forma,um projeto realizado com alto padrão de qualidade gera credibilidade com o cliente, bemcomo exige menos retrabalho e recursos adicionais. A elaboração de um Plano de Qualidade é uma atividade gerencial apoiada pelaadministração fiel a um conjunto de atividades que compõem o projeto. Ela estabelecemétricas visando custos, prazos e funcionalidades do projeto e a satisfação do cliente com oproduto. Humprey, referenciado por Sommerville (2003), em seu livro sobregerenciamento de software, sugere uma estrutura geral para um plano de qualidade, queinclui:
  29. 29. 281. Introdução sobre o Produto: Uma descrição sobre o produto, seu mercado pretendido e as respectivas expectativas quanto à qualidade.2. Planos para o produto: As datas importantes para a liberação e as respectivas responsabilidades referentes ao produto, juntamente com os planos para a distribuição e a prestação de serviços relacionados a ele.3. Descrição de processo: Os processos de desenvolvimento e de serviço que devem ser utilizados para o desenvolvimento e gerenciamento do produto.4. Metas de qualidade: As metas e os planos de qualidade para o produto, incluindo identificação e justificativa de importantes atributos da sua qualidade.5. Riscos e Gerenciamento de Riscos: Os principais riscos que podem afetar a qualidade do produto e as ações para evitar esses riscos. Existe uma ampla gama de atributos de qualidade de software em potencial quedevem ser considerados durante o processo de planejamento de qualidade. Em geral, não épossível para qualquer sistema ser otimizado em relação a todos os atributos, e, assim, umaparte importante do planejamento de qualidade é selecionar os principais atributos dequalidade e planejar como eles devem ser obtidos. (SOMMERVILLE, 2003). A figura aseguir representa os atributos da qualidade de software.Figura 2 - Atributos de Qualidade do softwareFonte: Desenvolvido pelo autor, 2010.
  30. 30. 292.1.4 Padrões de documentação Um documento é a única maneira tangível de representar o software a serdesenvolvido o processo. desta forma é extremamente importante a definição de um padrão dedocumentos de fácil entendimento e objetivo. Na padronização da documentação, deve-seconsiderar o processo de documentação (definindo o processo a ser seguido nadocumentação); padrões de documentos (os quais regem a estrutura e a apresentação dosdocumentos) e os padrões que asseguram que todas as cópias eletrônicas sejam compatíveis.Embora a documentação deva se adequar a necessidade de projetos específicos, é interessanteque se utilize o mesmo estilo para todos os documentos produzidos, como identificação,estrutura, apresentação do documento, padrões de atualização de documento. O esquema abaixo permite visualizar o processo de padrões de intercâmbio dedocumentos. Esta prática possibilita a transferência de documentos eletronicamente recriadosem forma original. Podem também limitar as fontes e estilos de texto utilizados (devido adiferentes recursos, impressoras e displays) e definir convenções do uso de ferramentas.(SOMMERVILLE, 2003).Esquema 1 - Padrões de intercâmbio de documentosFonte: Sommerville, 2003.
  31. 31. 302.1.5 Medição e Métricas De acordo com Martinho (2008), o objetivo das medições, métricas e análises édirecionar a melhoria contínua em todos os parâmetros da qualidade por um sistema demedição orientado a metas. A medição visa obter valores numéricos para atributos de um produto e/ouprocesso e compara com outros produtos/processos, buscando tirar conclusões sobre aqualidade do processo, avaliando se os objetivos pré-definidos estão próximos de seremalcançados. Já as métricas são as medições referentes ao processo ou produto. São geralmentemedidas características como a rastreabilidade, volatilidade, esforço, abrangência, qualidade etamanho. Segundo o WThreeX (2010), para se atingir a medição e métricas de qualidade emum processo, são necessários alguns elementos, mencionados abaixo. Os pontos colocados abaixo compõem as medições: a) Aceite do grau de cumprimento dos padrões do processo, diretrizes e implementação; b) Atingir o nível de implementação conforme o planejado; c) Conclusão dos artefatos utilizando as métricas de qualidade do produto descritas acima. Os pontos colocados abaixo compõem as métricas: a) Ser de fácil entendimento, objetivas e fáceis de coletar; b) Deve ser uma tarefa automatizada, de modo que não interfira nas atividades dos desenvolvedores; Tendências e valores absolutos de métricas devem ser usados ativamente pelas equipes de gerenciamento e de engenharia para informar o andamento e a qualidade em um formato consistente. Quanto à seleção de um conjunto mínimo ou mais extenso de métricas, estadependerá das características e do contexto do projeto. Se ele for grande ou tiver requisitosrigorosos de confiabilidade ou segurança e as equipes de desenvolvimento e avaliação tiveremum ótimo conhecimento sobre métricas, talvez seja útil coletar e analisar as métricas técnicas.O contrato pode exigir que determinadas métricas sejam coletadas ou a organização podeestar tentando aperfeiçoar habilidades e processos em áreas específicas. Não há uma respostasimples que se adapte a todas as circunstâncias. O gerente de projeto deve selecionar o que é
  32. 32. 31apropriado quando o plano de métricas for produzido. No entanto, quando se apresenta umplano de métricas pela primeira vez, convém manter a simplicidade, em vez de se arriscar ecometer erros. (WTHREEX, 2010).2.2 SOFTWARE QUALITY ASSURANCE A SQA (Software Quality Assurance ou Garantia de Qualidade de Software) estáenvolvida em todo o processo de desenvolvimento de software, monitorando e melhorando osprocessos e etapas. Ela faz com que os procedimentos e padrões sejam seguidos; identifica egarante a correção das falhas dentro do projeto. Segundo Pressman (1995, p. 725) a garantia de qualidade de software abrange: [...] (1) métodos e ferramentas de análise, projeto, codificação e Teste; (2) revisões técnicas formais que são aplicadas durante cada fase da engenharia de software; (3) uma estratégia de Teste de múltiplas fases; (4) controle da documentação de software e das mudanças feitas nela; (5) um procedimento para garantir a adequação aos padrões de desenvolvimento de software (quando aplicáveis); e (6) mecanismos de medição e divulgação. O acompanhamento do processo de qualidade de software é feito baseando-se nasmétricas que são obtidas por meio de técnicas de verificação e validação como avaliações,auditorias, inspeções e revisões. Já no produto, os métodos utilizados podem ser feitos pormeio de Testes de software, como Testes caixa preta, caixa branca, Testes funcionais, Testesde regressão, entre outros.2.3 ANÁLISE DE RISCOS Com a crescente demanda por qualidade de software, um processo bem definido éum fator extremamente importante. Se torna cada vez mais comum a busca por boas práticas emodelos conceituados como CMMI e MPS.BR. Entretanto, a implantação de um destesmodelos não é tarefa simples, pois deve passar pela política de cada organização, desviandosua cultura e crenças. A análise de riscos é uma necessidade encontrada hoje nessas empresas,
  33. 33. 32servindo de orientação na fase de adaptação de um processo. Na análise de riscos, sãoconsiderados fatores como a não utilização de boas práticas de desenvolvimento,considerando que a qualidade do software está diretamente associada à qualidade dosprocessos utilizados em sua produção e ao conhecimento técnico que os usuários do processotêm sobre as práticas definidas. (ESPINHA, 2007). Segundo Espinha (2007, p. 11): Risco é a “exposição à chance de perdas ou danos”. Embora exista também uma chance de alguma coisa sair melhor do que o esperado, o risco geralmente costuma ser associado a possíveis perdas ou danos. O conceito de risco resulta da incerteza quanto a eventos futuros e é parte de todas as atividades do desenvolvimento. A análise de riscos se baseia em uma estratégia de avaliação de todos os ativos doprocesso, bem como suas características (itens relacionados ao ativo). Ela extrai de cada ativo,informações de uma série de elementos que posteriormente auxiliam na tomada de decisão. Cada componente possui uma um checklist1 associado, composto pelos itens quedeverão ser verificados. Isto para que facilite a identificação do controle e questionários queserão utilizados para a coleta de dados. Os elementos que compõem este controle são:Nome do Controle: a característica do requisito;Justificativa: conceitos necessários para explicar porque o controle deve ser implementado;Ameaças: quais os elementos podem não aproveitar da implementação do controle para semanifestar e causar danos;Recomendação: fornece razões para implementação do controle;Referências: referências bibliográficas da ação;Probabilidade: representa a probabilidade de uma ameaça se manifestar caso o controle nãoesteja implementado na organização;Severidade: indica o grau do impacto negativo na organização, caso uma ou mais ameaças semanifestem;Agrupamento: indica a qual agrupamento o controle pertence. A imagem abaixo a análise de riscos em sua forma geral.1 Checklist pode ser definido como o conjunto de itens agrupados em uma lista de forma a facilitar a comparaçãoou garantir que as ações associadas a eles sejam gerenciadas adequadamente e não sejam esquecidas.
  34. 34. 33Esquema 2 - Análise de RiscosFonte: Espinha, 2007. Por fim, tem-se uma série de informações concatenadas que fornecem apoio aogestor do projeto. As ilustrações abaixo apresentam informações que foram extraídas atravésdo processo de análise de riscos.
  35. 35. 34Tabela 1 - Resultados da avaliação em abrangência por área de processo.Fonte: Espinha, 2007.Gráfico 1 - Resultados da avaliação em abrangência - ameaçasFonte: Espinha, 2007.
  36. 36. 352.4 CONSIDERAÇÕES FINAIS A busca pela qualidade de software não está somente no início do projeto, onde éfeito o levantamento dos requisitos; nem apenas no final realizando Testes funcionais. Aqualidade está presente durante toda engenharia do software: processo de desenvolvimentoque é utilizado, bem como as pessoas que estão envolvidas no processo. Podemos considerá-la como algo subjetivo que pode variar de acordo com as pessoas que estão envolvidas naavaliação da qualidade.
  37. 37. 363 TESTES O presente capítulo aborda os conceitos de testes de software, bem como os tipos detestes existentes. Além disso, mostra as dificuldades surgidas no processo de desenvolvimentoe meios de solucioná-las.3.1 VISÃO DE TESTES DE SOFTWARE Teste de software é o processo de execução de um produto para determinar se eleatingiu suas especificações e funcionou corretamente no ambiente para o qual foi projetado. Oseu objetivo é revelar falhas em um produto, para que as causas dessas falhas sejamidentificadas e possam ser corrigidas pela equipe de desenvolvimento antes da entrega final.Por conta dessa característica das atividades de Teste, dizemos que sua natureza é destrutiva,e não construtiva, pois visa o aumento da confiança de um produto através da exposição deseus problemas, porém antes de sua entrega ao usuário final. (DIAS NETO, 2007). O Teste, da maneira como é executado pela maioria das empresas – como umaetapa do processo do desenvolvimento e, em geral, executado pelos próprios desenvolvedorese pelos usuários do sistema – serve apenas para garantir que as especificações ou os requisitosdo negócio foram implementados. Como o processo de desenvolvimento cria produtos comdefeito, se faz necessário descobrir estes defeitos. Em um modelo de garantia de qualidadeisso é insuficiente. Quem poderia garantir que um software testado pelos própriosdesenvolvedores está corretamente testado? Com certeza, existem exceções, mas a melhorforma de testar um software é ter um processo de Teste claramente definido. (BASTOS et al.,2007). O Teste é um processo que envolve vários outros processos da engenharia desoftware, e ações que vão desde o levantamento de requisitos até a execução do Testepropriamente dito. (MOLINARI, 2008). A imagem mostrada abaixo ajuda a localizar oprocesso de Testes dentro da Engenharia de Software.
  38. 38. 37Figura 3 - Localização da qualidade dentro da engenharia.Fonte: Molinari, 2008. A engenharia de software mostra uma ciência, uma área de construção e gerênciado projeto. Quando se passa a enxergar mais fundo, percebemos que há nela uma área dequalidade. Sabemos que “ir ao encontro das necessidades dos clientes” é a chave para agarantia de um produto. Porém, isso só é possível mediante técnicas adequadas para garantir ofuncionamento do software. (MOLINARI, 2008). O autor prossegue, afirmando que os Testes mostram uma visão das falhas naqualidade externa, aquela que é visualizada, tal qual um sintoma de uma doença. As raízesdessas doenças estão na garantia interna, no controle por meio de diversos atributos, taiscomo: estrutura adequada de programação, usabilidade, padrões de codificação, etc. Myers (1979), referenciado em BASTOS et al., (2007) criou conceitos sobreTestes de Software – uma publicação que na época tornou-se uma das bíblias da qualidade desoftware. Nesta obra, Myers afirmava que:  Os Testes unitários podem remover entre 30% e 50% dos defeitos dos programas;  Os Testes de sistema podem remover entre 30% e 50% dos defeitos remanescentes;  Desse modo, os sistemas podem ir para produção ainda com aproximadamente 49% de defeitos;  Por último, as revisões de códigos podem reduzir entre 20% e 30% desses defeitos. Abaixo é apresentado um gráfico, elaborado pelos acadêmicos autores dessamonografia, com base nas ideias de Myers.
  39. 39. 38Gráfico 2 - Custo de correçõesFonte: Elaboração dos autores, 2010. O gráfico 2 transmite a ideia de que, para garantir maior qualidade em umproduto, é importante levantar a necessidade de cada fase do desenvolvimento para seremidentificados os problemas de forma rápida. Tendo isso aplicado ao processo utilizado, pode-se reduzir consideravelmente o custo do desenvolvimento, pois se torna fácil identificar umafalha logo no seu surgimento.3.1.1 Conceitos de Testes Segundo Dias Neto (2007), Teste é uma ação que pode ser realizada em diferentesestágios do desenvolvimento. Seus objetivos diferem de acordo com o estágio.  Etapas iniciais: expor defeitos para permitir correção;  Etapas finais: verificar se o sistema atende a especificações. Para introduzir os conceitos de Testes de software, é importante esclarecer algunsdos principais itens relacionados a esta atividade, tais como defeitos, erros e falhas. Adiferença entre estes três conceitos seguem abaixo. Elas estão definidas na terminologiapadrão para Engenharia de Software do IEE - Institute of Electrical and Electronics Engineers– (IEEE 610, 1990 apud DIAS NETO, 2007).
  40. 40. 39 Defeito é um ato inconsistente cometido por um indivíduo ao tentar entender umadeterminada informação, resolver um problema ou utilizar um método ou uma ferramenta.Por exemplo, uma instrução ou comando incorreto. Erro é uma manifestação concreta de um defeito num artefato de software.Diferença entre o valor obtido e o valor esperado, ou seja, qualquer estado intermediárioincorreto ou resultado inesperado na execução de um programa constitui um erro. Falha é o comportamento operacional do software diferente do esperado pelousuário. Uma falha pode ter sido causada por diversos erros e alguns erros podem nuncacausar uma falha. A ilustração abaixo expressa a diferença entre esses conceitos. Defeitos fazemparte do universo físico (a aplicação propriamente dita) e são causados por pessoas, porexemplo, através do mal uso de uma tecnologia. Defeitos podem ocasionar a manifestação deerros em um produto, ou seja, a construção de um software de forma diferente ao que foiespecificado (universo de informação). Por fim, os erros geram falhas, que sãocomportamentos inesperados em um software que afetam diretamente o usuário final daaplicação (universo do usuário) e pode inviabilizar a utilização de um software. (DIASNETO, 2007).Figura 4 - Defeito x Erro x FalhaFonte: Neto, 2007. Ao longo de um processo de testes, são abordados elementos que seguem desde afase inicial até a entrega de um software, necessários para que se possa conhecer mais a fundoa área de testes. Os elementos que seguem abaixo foram descritos com base no livro “TestesFuncionais de Software”, de Leonardo Molinari (2008, p. 56)
  41. 41. 40 a) Planejamento de Testes: é o processo de se planejar Testes. O planejamento pode gerar um ou mais planos de Testes; b) Plano de Testes: é o resultado do processo de planejamento de Testes. Ele representa a composição dos requisitos, casos de Testes, cenários de Testes a serem utilizados, e quaisquer outros documentos que sejam pertinentes ao planejamento; c) Requisitos de Testes: são requisitos dos Testes que representam o que deve ser testado em termos de meta. Um requisito deve gerar um ou mais casos de Testes; d) Tipos de Testes: são os tipos de Testes a serem realizados em um ambiente. Aqui, cada caso de Teste a ser realizado irá referenciar um tipo de Teste, ou alguma técnica a ser utilizada. Exemplo: Teste de performance, Teste funcional, Teste de segurança, etc; e) Casos de Teste: representa o que deve ser testado em detalhes. É a menor unidade de Teste, o desdobramento natural dos requisitos de Teste. Cada caso de Teste é composto por um conjunto de passos de Teste; f) Passo de Teste: é uma ação específica ou um passo para poder realizar um Teste. Um passo pertence a apenas um conjunto de passos de Teste. Exemplo: abrir a aplicação, clicar no botão X; g) Script de Teste: é também conhecido como “script de automação”. Conjuntos e passos que são executados em uma ferramenta de automação de Teste. Representa uma ação ou um caso de Teste gerado através da ferramenta de automação; h) Cenário de Teste: é um conjunto de casos de Teste ou scripts a serem executados em uma ordem com o objetivo de executar uma situação de Teste; i) Ambiente de Teste: é um conjunto de artefatos lógicos e físicos que compõe o ambiente onde os Testes serão planejados e executados; j) Relatório de Teste: é um relatório contendo informações dos Testes; k) Metodologia de Testes: é um conjunto de técnicas, método e estratégias que se volta para a criação e execução de um sistema qualquer; l) Processo de Teste: é um processo qualquer que representa como os Testes são gerenciados.Rocha (2001), aponta outro elemento e sua subdivisão:
  42. 42. 41 a) Critério de Teste: serve para selecionar e avaliar casos de Teste de forma a aumentar as possibilidades de provocar falhas ou, quando isso não ocorre, estabelecer um nível elevado de confiança na correção do produto.  O critério de cobertura dos Testes: permite a identificação de partes do programa que devem ser executadas para garantir a qualidade do software e indicar quando o mesmo foi suficientemente testado (RAPPS e WEYUKER, 1982, apud ROCHA, 2007). Ou seja, determinar o percentual de elementos necessários por um critério de Teste que foram executados pelo conjunto de casos de Teste;  O critério de adequação de casos de Teste: quando, a partir de um conjunto de casos de Teste “T” qualquer, ele é utilizado para verificar se “T” satisfaz os requisitos de Teste estabelecidos pelo critério. Ou seja, este critério avalia se os casos de Teste definidos são suficientes ou não para avaliação de um produto ou uma função;  O critério de geração de casos de Teste: quando o critério é utilizado para gerar um conjunto de casos de Teste “T” adequado para um produto ou função, ou seja, este critério define as regras e diretrizes para geração dos casos de Teste de um produto que esteja de acordo com o critério de adequação definido anteriormente.3.1.2 Defeitos do desenvolvimento No processo de desenvolvimento de software ocorrem muitos defeitos. Embora asempresas tenham grande preocupação com o uso dos melhores métodos de desenvolvimento,ferramentas ou profissionais, os defeitos permanecem presentes nos produtos, o que torna aatividade de Teste fundamental durante o desenvolvimento de um software. Já foi observadoque esta atividade corresponde ao último recurso para a avaliação do produto antes da suaentrega ao usuário final. O tamanho do projeto a ser desenvolvido e a quantidade de pessoasenvolvidas no processo são dois possíveis fatores que aumentam a complexidade dessa tarefa,e por consequência, aumentam também a probabilidade de defeitos. Assim, a ocorrência defalhas é inevitável. Mas o que significa dizer que um programa falhou? Basicamente significa
  43. 43. 42que o funcionamento do programa não está de acordo com o esperado pelo usuário. Porexemplo, quando um usuário da linha de produção efetua consultas no sistema das quais só agerência deveria ter acesso. De acordo com Dias Neto (2007), esse tipo de falha pode seroriginado por diversos motivos, como por exemplo:  A especificação pode estar errada ou incompleta;  A especificação pode conter requisitos impossíveis de serem implementados devido a limitações de hardware ou software;  A base de dados pode estar organizada de forma que não seja permitido distinguir os tipos de usuário;  Pode ser que haja um defeito no algoritmo de controle dos usuários. Os defeitos normalmente são introduzidos na transformação de informações entrediferentes fases do ciclo de desenvolvimento de um software. O exemplo abaixo citado porDias Neto (2007), expressa de forma clara o ciclo de vida do desenvolvimento: Os requisitos expressos pelo cliente são relatados textualmente em um documento de especificação de requisitos. Esse documento é então transformado em casos de uso, que por sua vez foi o artefato de entrada para o projeto do software e definição de sua arquitetura utilizando diagramas de classes da UML. Em seguida, esses modelos de projetos foram usados para a construção do software em uma linguagem que não segue o paradigma orientado a objetos. Observe que durante esse período uma série de transformações foi realizada até chegarmos ao produto final. Nesse meio tempo, defeitos podem ter sido inseridos. (DIAS NETO, 2007, p.56). A figura abaixo ilustra este exemplo:Figura 5 - Diferentes interpretações ao longo do ciclo de desenvolvimento de um software.Fonte: Dias Neto, 2007.
  44. 44. 433.1.3 Gerenciamento de Testes Molinari (2008) declara que a gestão da qualidade representa um dos pilares daQualidade de Software. Os outros pilares tratam dos elementos gestão de configuração, gestãode requisitos e Testes. Gestão de Configuração: trata de gerência, controle e registro dos artefatos quecompõem o software, incluindo aí todo o histórico da mudança do software em si; Gestão de Requisitos: trata de gerência, controle e registro das necessidades dosistema (requisitos) e dos usuários em todos os níveis, incluindo aí a rastreabilidade dasnecessidades e da sua mudança; Testes: trata de gerência, planejamento, controle e execução dos Testes em todosos níveis, de modo a garantir a implementação (projeto, desenvolvimento e entrega) dasnecessidades especificadas. Como dito anteriormente, quanto antes os testes iniciarem, mais barato será acorreção dos defeitos encontrados. O gerente de testes deve trabalhar neste sentido, definindoe acompanhando o processo para garantir a qualidade do sistema em desenvolvimento. Demodo geral, o processo de teste é representado por ciclos, que são as etapas a serem seguidasem todo o processo. Para Bastos et al. (2007), o ciclo de testes é representado pelas seguintesetapas:  Planejamento  Preparação  Especificação  Execução  Entrega3.2 REQUISITOS E CASOS DE TESTES Nesta seção serão abordados os requisitos e os casos de testes utilizados noprocesso.
  45. 45. 443.2.1 Definindo os requisitos Para elaborar os casos de testes é necessário primeiramente levantar os requisitosde testes. Não se deve confundir requisito de teste com caso de teste - este último seráexplicado mais adiante. Para criar tais requisitos deve-se definir exatamente o que se desejatestar em nível macro e em nível detalhado. (MOLINARI, 2008). Para realizar o levantamento geralmente se tem como base os documentos,especificações de usuários, necessidades do sistema e os casos de uso. Quanto mais detalhadofor o requisito, mais próximo do caso de testes ele vai ficar. Segundo Molinari (2008), osrequisitos devem possuir algumas características para que este seja bem elaborado, podemosdestacar as seguintes características: a) Sua escrita deve ser de forma clara e objetiva, não deve de maneira nenhuma conter ambiguidades em sua descrição; b) Deve ser único, não pode existir ambiguidade entre requisitos; c) A descrição deve ser adequada à realidade que ele propõe representar; d) Seu detalhamento deve ser completo, lembrando que completude não significa texto extenso, deve conter apenas o necessário. Os requisitos geralmente estão organizados em uma estrutura hierárquica. Deveconter um número de identificação único, descrição detalhada, seu status (posição atual nociclo de vida de um requisito. Ex.: criado, atualizado, finalizado, implementado, etc.) e suasdependências para com outros requisitos de Testes. (MOLINARI, 2008).3.2.2 Definindo casos de testes Descreve uma condição particular a ser testada e é composto por valores deentrada, restrições para a sua execução e um resultado ou comportamento esperado (CRAIG eJASKIEL, 2002, apud OLIVEIRA e PEREIRA, 2007). Conforme menciona Molinari (2008), os casos de Testes podem ser construídos,partindo dos requisitos. Nesta forma, o Caso de Teste será dividido em três grupos, chamadosde Cenário de Teste. Isso não significa que cada cenário deverá ser totalmente preenchido em
  46. 46. 45amplitude e profundidade, mas devem ser vistos, pois sua importância pode variar entre oscenários.  Cenário de Testes no caminho principal: são os casos de Testes envolvidos no fluxo normal do sistema-alvo de Teste, ou seja, são os Testes que o usuário normalmente utiliza;  Cenário de Testes no caminho alternativo: são os casos de testes que estão envolvidos no fluxo alternativo da execução da aplicação, são considerados Testes de menor importância;  Cenário de Testes de exceção: são os Testes em situações de possíveis problemas ou exceções que impedem ou atrapalham o funcionamento da aplicação. Além das técnicas existentes, é importante também testar os acessos da aplicaçãoao banco de dados, para verificar se a aplicação está trabalhando o dado de maneira correta,ou seja, se o dado foi lido, atualizado, alterado e excluído do banco de dados, certificandoassim a integridade da informação. Para executar essa validação, pode-se criar um caso deteste para essa função, ou mesmo acrescentar como um passo dentro dos casos de testesrespectivos. Assim como os requisitos, os casos de testes também possuem algumascaracterísticas para que sejam bem elaborados, entre elas podemos destacar as seguintes: a) Deve ser escrito de maneira objetiva e clara, sem ambiguidades no texto; b) Assim como acontece nos requisitos, o caso de Teste é único; c) Sua descrição deve estar adequada à realidade a qual propõe representar, contendo os passos para realizar o Teste: d) O caso de Teste deve estar completo; e) Deve possuir referências de outros casos de Testes, se necessário. Segundo Pontes (2009) um caso de teste simples deve possuir um objetivo, umpasso-a-passo de como executar o teste, suas pré-condições para iniciar o teste, caso sejanecessário, e o resultado esperado, como o exemplo que pode ser visualizado no quadroabaixo.
  47. 47. 46Quadro 3 - Exemplo de um Caso de Teste simples.Fonte: Pontes, 2009. Entretanto, nada impede que sejam adicionadas mais informações ao caso deteste, como: ambiente, dados de entrada, cronograma, dependências com outros casos detestes, entre outras.3.3 TIPOS DE TESTES O planejamento do Teste deve prever os tipos e as técnicas que serão utilizadas aorealizar um determinado Teste. Existem dois tipos básicos de Testes considerados os maisgenéricos: Testes Funcionais e Testes Estruturais. Nenhum destes é completo. Eles secompletam e devem ser aplicados em conjunto. Para cada um destes tipos podemos realizarinúmeras técnicas criadas para complementar os Testes. (MOLINARI, 2008). Para Rocha, aludido em Costa (2009), os principais níveis de Testes são:  Teste de Unidade  Teste de Integração  Teste de Sistema  Teste de Aceitação  Teste de Regressão.
  48. 48. 47 A seguir, abordar-se-á o conceito destes e de outros tipos de Testes, bem comotécnicas de Testes Funcionais e Testes Estruturais.3.3.1 Teste Funcional Molinari (2008) define os Testes funcionais como: [...] o tipo de Teste que tem por objetivo medir a qualidade funcional de componentes de um sistema. Este tipo de Teste, conhecido também como o Teste “caixa-preta”, propõe testar a funcionalidade do sistema – entrada e saída de dados - com uma visão externa da aplicação, de modo a assegurar a funcionalidade do sistema. Aqui não é considerada a verificação no interior da aplicação (código-fonte, estrutura). Os Testes são realizados executando a rotina ou sistema que pretende-se testarcomparando-o com o resultado previamente conhecido. No geral, o termo “Teste funcional”tente a ficar limitado a Testes unitários. Porém, nada impede de ser aplicada certagranularidade a um Teste funcional. Podemos testar um componente de um sistema ourealizar verificações em um arquivo de banco. Abaixo, segue a representação do teste caixa-preta.Figura 6 - Componentes existentes em Testes caixa preta.Fonte: Elaboração dos autores, 2009.
  49. 49. 48 Como no teste estrutural, há diversas técnicas existentes que ajudam a executarum bom teste funcional. Durante a execução de um checklist ou simplesmente o ato dehomologar uma tarefa, está se realizando técnicas de testes funcionais. Falta apenas o hábitode estar enfatizando estas atividades para melhorar o processo. Algumas técnicas existentes são Teste de Valor Limite ou Fronteiras (BoundaryValue Testing), Teste de Particionamento Equivalente (Equivalente Class Testing), Teste deRegressão, entre outros. Abaixo serão apresentados detalhes de algumas técnicas utilizadasnos Testes Funcionais. (MOLINARI, 2008).3.3.2 Testes de Unidade Este tipo de Teste, também conhecido como Testes unitários, tem por objetivoexplorar a menor unidade do projeto, procurando provocar falhas ocasionadas por defeitos delógica e de implementação em cada módulo, separadamente. O universo alvo desse tipo deTeste são os métodos dos objetos ou mesmo pequenos trechos de código. (ROCHA, 2001apud DIAS NETO, 2007).3.3.3 Testes de Sistema Avalia o software em busca de falhas por meio da utilização do mesmo, como sefosse um usuário final. Dessa maneira, os Testes são executados nos mesmos ambientes, comas mesmas condições e com os mesmos dados de entrada que um usuário utilizaria no seu dia-a-dia de manipulação do software. Verifica se o produto satisfaz seus requisitos. (ROCHA,2001 apud DIAS NETO, 2007).
  50. 50. 493.3.4 Testes de Aceitação São realizados geralmente por um restrito grupo de usuários finais do sistema.Esses simulam operações de rotina do sistema de modo a verificar se seu comportamento estáde acordo com o solicitado. (ROCHA 2001, apud DIAS NETO, 2007).3.3.5 Testes de Integração É uma técnica sistemática para construção da estrutura do programa. O Teste deintegração pode ser considerado como uma extensão lógica dos Testes unitários. Na suaforma mais simples, duas unidades que foram testadas são combinadas em um componente etestadas. Um componente neste caso, refere-se a um conjunto integrado de mais de umaunidade. O objetivo desta técnica é montar estruturas de testes para descobrir errosrelacionados à interface, combinando peças e testando em pares. (Pressman, 1995).3.3.5.1 Não Incremental A abordagem chamada de big-bang, onde os módulos são testados isoladamente edepois integrados de uma só vez. Os conjuntos de erros são difíceis de serem detectados, logodifíceis de serem corrigidos, pois devido ao tamanho e complexidade do programa, é difícilisolar as causas de tais erros. Testes não-incrementais são normalmente usados devido àspressões do dia a dia e os Testes são aplicados para demonstrar uma operabilidade mínima dosistema. (CAMPOS, 2009).
  51. 51. 50Esquema 3 - Representação dos módulos de TesteFonte: Campos, 2009.3.3.5.2 Incremental Um software é construído e testado em pequenos segmentos, tornando a correçãode erros mais fácil. A probabilidade de testar completamente a interface do sistema tambémaumenta.
  52. 52. 51 A figura abaixo representa componentes que foram estruturados de formaincremental:Esquema 4 - Testes de integração.Fonte: Elaboração dos autores, 2010. De acordo com Campos (2009), os pontos relevantes desta técnica são:  O Tester não precisa esperar até que todo o sistema esteja pronto, para iniciar os Testes;  Há um menor risco de fracasso geral do projeto, já que cada módulo é verificado antes e caso algo esteja errado a correção será implementada já no próximo ciclo de Teste;  A integração dos módulos só é realizada, após eles já terem sido verificados, ou seja, se algum erro acontecer, a causa provavelmente será a comunicação entre esses módulos.3.3.5.3 Integração Top-down É uma abordagem incremental. Como o nome já diz, a integração dos módulosacontece de cima para baixo, o que facilita a verificação antecipada dos pontos de decisão econtrole no processo de Teste. (CAMPOS, 2009).
  53. 53. 523.3.5.4 Integração Bottom-up Na técnica Botton-up, a integração do sistema começa a partir do nível mais baixodo software, ou seja, o módulo. O módulo é dito como o mais baixo nível se ele não dependede outro módulo. A Bottom-Up assume que todos os módulos foram individualmente testadosantes. (CAMPOS, 2009).3.3.6 Teste de Regressão Esta técnica de Teste trabalha de modo a testar segmentos já testados após aimplementação de uma mudança na aplicação. Ela tem por objetivo determinar se adocumentação do sistema permanece atual; verificar se os dados e as condições de Testepermanecem atuais; determinar se as funções previamente testadas continuam funcionandocorretamente após a introdução de mudanças no sistema. Costa (2009) menciona que os Testes de regressão tratam de executar Testes daversão anterior, na nova versão de um aplicativo, de modo a se certificar que o que está naaplicação continue certo. Um Teste de regressão deve ser executado sempre que o sistema sofre algumaalteração. Significa aplicar todos os Testes realizados anteriormente para garantir que osresultados não tenham sido afetados pelas mudanças realizadas, não só na parte alterada,como os outros segmentos do sistema. Um ponto negativo do Testes de regressão é o gasto excessivo de tempo e arepetição das operações, o que muitas vezes contribui para que eles não sejam realizados deforma completa. Como esses Testes são vitais para garantir a qualidade final do sistema, tem-se uma excelente justificativa para introduzir a automação de Testes na organização.
  54. 54. 533.3.7 Teste de Estresse Neste Teste será avaliado o comportamento do sistema sob condições críticas.Basicamente, este Teste tem o objetivo de avaliar os limites, ou seja, até quando o softwarepode ser exigido e até quais as falhas (caso existam) decorrentes dele, levando emconsideração as restrições. Tais como a memória, número de transações e capacidade daaplicação. Para Lourenço (2010), este tipo de Teste é indispensável quando se trata de Testesem aplicações cuja eficiência seja uma característica importante. Exemplos:  Servidores de arquivos web, que devem atender a solicitação de um grande número de clientes;  Aplicações industriais, tais como o controle de uma refinaria de petróleo; Jogos de Computador, que precisam de um desempenho aceitável para serem viáveis comercialmente. Este Teste permite a capacidade de responder à questões como:  O sistema consegue atingir o objetivo?  Qual o número máximo de transações realmente possível?  Se a plataforma de execução se degradar (por exemplo, uma falha parcial de rede, falta de espaço em disco, etc.), como o sistema se comportará? A maior dificuldade que se pode ter ao realizar este Teste é preparar a plataformapara executá-lo. Caso se queira saber a quantidade mínima de memória disponível para que osistema funcione, retirar a memória do computador seria uma solução trabalhosa. Para isso,existem no mercado aplicações que permitem tal avaliação, como WinStress (permite reduzirartificialmente a capacidade de desempenho do computador conforme configuração desejada.Possibilita também a variação de parâmetros como carga de CPU, memória disponível,espaço em disco e carga de rede). Ferramentas como DieselTest e OpenST, permitem testarum programa simulando um número arbitrário de conexões. (LOURENÇO, 2010).
  55. 55. 543.3.8 Análise do Valor Limite ou Fronteira Este Teste utiliza uma seleção dos casos de testes que põem a prova os valoresfronteiriços. São utilizadas extremidades da classe, tendo como variáveis a faixa de valores otamanho da estrutura, valores específicos, entre outros extraídos. Ao aplicar um caso de Testeutilizando esta técnica, é importante gerar entradas ou saídas que coincidem com ambos oslados de cada fronteira, incluindo o valor da própria fronteira. Segundo Freitas (2009) para seelaborar esta técnica, deve-se considerar as condições:  Se uma condição de entrada um intervalo, delimitado pelos valores A e B, os casos de teste devem ser projetados com valores A e B logo acima e logo abaixo de A e B respectivamente;  Se uma condição de entrada especificar uma série de valores, os casos de teste que ponham à prova números máximos e mínimos devem ser desenvolvidos. Valores logo acima e logo abaixo do mínimo e do máximo também são testados;  Aplicar as diretrizes 1 e 2 às condições de saída, por exemplo, supondo-se que uma tabela de temperatura versus pressão seja exigida como saída de um programa de análise de engenharia, os casos de teste devem ser projetados para criar um relatório de saída que produza um número máximo (e mínimo) permissível de entradas na tabela;  Se estruturas internas de dados do programa tiverem prescritas fronteiras, certificar-se de projetar um caso de teste para exercitar a estrutura de dados em sua fronteira. Abaixo, é apresentado um exemplo da técnica.Tabela 2 - Refinamento utilizando Valores-Limites.Fonte: FREITAS, 2009. Esta técnica é simples de trabalhar, e pode ser aplicada para realizar Testesunitários, de integração ou Teste de aceitação de usuários.
  56. 56. 553.3.9 Tabela de decisão A técnica de decisão pode ser aplicada a todas as situações quando a execução dosoftware depende de muitas decisões lógicas. Ela baseia-se em uma combinação de situaçõesque devem ocorrer para que uma determinada ação seja tomada, expressa por um determinadoprocessamento ou por um cálculo. A tabela de decisão contém condições que disparam asações, muitas vezes combinações verdadeiras e falsas para todas as condições de entrada, eações resultantes para cada combinação de condição. (FREITAS, 2009). Cada coluna da tabela corresponde a uma regra de negócio que define uma únicacombinação de condições que resulta na execução de ações associada com aquela regra. A cobertura padrão comumente usada em uma tabela de decisão é ter no mínimoum Teste por coluna cobrindo todas as combinações de condições apresentadas. (FREITAS,2009). A seguir, é mostrado um exemplo de tabela de decisão.Tabela 3 - Exemplo de uma tabela de decisão. .Fonte: FREITAS, 2009. No exemplo imaginário acima (Freitas, 2009) a decisão de se aceitar o seguro serábaseado no número de acidentes combinado com o sexo do motorista. Esta supostacompanhia de seguros entende que as pessoas do sexo feminino dirigem com mais cuidado,como podemos ver na tabela de decisão acima.
  57. 57. 563.3.10 Testes de Semântica Segundo Freitas (2009), estes Testes devem ser usados para avaliar telas ourelatórios têm defeitos de sintaxe e estão em conformidade com o modelo de dados do sistema(tamanho dos atributos, etc.). Para este Teste deve, também, ser usado um padrão para criaçãode telas e relatórios. Procedimentos:  Criar uma lista de verificação para as telas e relatórios;  Definir as telas e relatórios que serão testados;  Montar os scripts de Teste. É importante considerar que algumas empresas são bastante rígidas quando setrata da criação de telas e/ou relatórios.3.3.11 Testes Estruturais Os Testes estruturais, ou também chamados de caixa-branca, têm por objetivoavaliar o comportamento interno do sistema, simulando situações que exercitem todas asestruturas utilizadas na codificação. Permite um Teste mais preciso em relação aos pontoscríticos do código-fonte. Freitas (2009), afirma que os Testes estruturais devem considerar osseguintes aspectos:  Teste de condição;  Teste de ciclos;  Teste de fluxo de dados;  Teste de caminhos lógicos;  Códigos nunca executados. A imagem a seguir é uma representação desta técnica.

×