Você está na página 1de 60

VALDEMAR COLEN DA SILVA JUNIOR

QUAL A VIABILIDADE PARA A IMPLANTAO DE TESTES DE SOFTWARES NA EMPRESA DOCTUM DE CONSULTORIA JUNIOR DE TEFILO OTONI?

Tefilo Otoni FACULDADES UNIFICADAS DOCTUM DE TEFILO OTONI MG 2012

VALDEMAR COLEN DA SILVA JUNIOR

QUAL A VIABILIDADE PARA A IMPLANTAO DE TESTES DE SOFTWARES NA EMPRESA DOCTUM DE CONSULTORIA JUNIOR DE TEFILO OTONI?
Monografia apresentada ao Curso de Sistemas de Informaes das Faculdades Unificadas Doctum de Tefilo Otoni, como requisito parcial obteno do titulo de Bacharel em Sistemas de Informao. rea de Concentrao: Engenharia de Software. Orientador: Prof. Oseas Teixeira.

Tefilo Otoni FACULDADES UNIFICADAS DOCTUM DE TEFILO OTONI MG 2012

FOLHA DE AVALIAO

___________________________________________

___________________________________________

___________________________________________

Dedico este trabalho, aos meus Pais que sempre me apoiaram e sempre estiveram ao meu lado, e as minhas Irms que nunca mediram esforos para me ajudar diante de alguma dificuldade.

AGRADECIMENTOS

Agradeo primeiramente a Deus, pois tudo posso naquele que me fortalece, Pela inspirao e fora que ele me concedeu durante toda a caminhada do curso. Aos meus Pais Valdemar e Gorete, Que sempre foram mais que simples pais, muitas vezes, Foram, professores, amigos, conselheiros, irmos, Obrigado Me e Pai, pela fora, carinho, confiana e amor, Que sempre depositaram em mim. Amo vocs. As minhas irms, Valderia e Polyana, Que sempre estiveram comigo, me apoiando, E me dando foras para superar algumas dificuldades. Agradeo algumas pessoas que passaram por minha vida, Durante essa caminhada, que se foram, mais me proporcionaram, Um grande aprendizado e alguns momentos felizes. Aos companheiros, amigos e colegas do curso, pela convivncia, Do dia-a-dia, que acima de tudo trouxe grande aprendizado, Descontrao e diverso em muitos momentos. Aos professores, que muitas das vezes foram, grandes amigos e Conselheiros. Ao professor Oseas, que me orientou e incentivou durante a realizao deste Trabalho, e que alm disso, se tornou um verdadeiro amigo, Que com certeza ser lembrado sempre. Obrigado mestre Oseas.

O sucesso um professor perverso. Ele seduz as pessoas inteligentes e as faz pensar que jamais vo cair.
Bill Gates

LISTA DE SIGLAS E ABREVIATURAS IFPUG International Function Point users group. CEPF Contagem estimativa de pontos de funo. APF Anlise de ponto de Funo cronometrado. ALI Arquivo logico interno. AEI Arquivo de interface externa. EE Entrada externa. SE Sada externar. CMD Interpretador de Linhas de Comandos. TXT Arquivo de texto. NBR ISO Normas e regulamentao. PFNA Ponto de funo no ajustado. PFA Ponto de funo ajustado. FA Fator de ajuste. NI Nvel de Influncia. PHP Linguagem de programao.

LISTA DE TABELAS

Tabela 1 Tempo gasto para a execuo dos testes .......................................... 45 Tabela 2 - Identificao da complexidade de tabelas ........................................... 46 Tabela 3 - Identificao da complexidade dos formulrios ................................... 46 Tabela 4 - Identificao da complexidade dos relatrios simples......................... 47 Tabela 5 - Identificao dos Arquivos Lgicos Internos da Aplicao .................. 47 Tabela 6 - Identificao das Entradas Externas da Aplicao ............................. 47 Tabela 7 - Identificao das Consultas Externas da Aplicao ............................ 48 Tabela 8 - Caractersticas Gerais dos Sistemas .................................................. 49

LISTA DE FIGURAS

Figura 1 - Tabela currculo, do Banco de Currculos das Faculdades Unificadas Doctum de Tefilo Otoni ....................................................................................... 33 Figura 2 - Arquivo de configurao do dbmonster.properties ............................... 34 Figura 3 - Comandos digitados na CMD, para que os dados seja inseridos na tabela destino .................................................................................................................. 35 Figura 4 - Tabela currculo com alguns dados j inseridos .................................. 36 Figura 5 - Pagina inicial do JMeter ....................................................................... 40 Figura 6 - Definio do nome do grupo e quantidade de usurios ....................... 40 Figura 7 - Configurao do HTTP Proxy .............................................................. 41 Figura 8 - Configurao do Proxy do navegador .................................................. 42 Figura 9 - Grfico de resultados ........................................................................... 43 Figura 10 - Resultados em tabela ........................................................................ 43 Figura 11 - Relatrio Agregado ............................................................................ 44

LISTA DE GRFICOS

Grfico 2 - Tempo gasto para executar o teste em uma tabela............................ 37 Grfico 3 - Tempo gasto para se testar todas as tabelas ..................................... 38

RESUMO

O presente trabalho tem como objetivo verificar qual a viabilidade para a implantao da prtica de teste no ambiente de desenvolvimento de softwares da Empresa Doctum de Consultoria Junior de Tefilo Otoni, visando o desenvolvimento de produtos de softwares baseados em mtricas de qualidade, levando em considerao o tempo total gasto neste processo aps a implementao de alguns dos principais tipos de testes existentes. Sero cronometrados o tempo para planejamento, configurao e execuo dos testes e, a partir desse estudo, avaliar o custo/benefcio dessa prtica. Custo em relao ao tempo gasto para execuo desses testes que poderiam ser convertidos em tempo de

programao,contrabalanceado com as vantagens, ou benefcios, que o mesmo traria se adotado como parte no processo de desenvolvimento. sabido que, uma falha encontrada aps a implantao de um software, leva um tempo de localizao e reparao do defeito bem maior do que seria gasto se os testes fossem realizados durante o processo de desenvolvimento, causando danos financeiros e operacionais em grau elevado aos stakeholders como tambm, danos irreversveis imagem da SoftwareHouse. Os casos de testes sero executados no projeto atual que a empresa junior est trabalhando, o Banco de Currculos, onde sero executados um teste de Desempenho utilizando a ferramenta DBMonster e, um teste de Estresse utilizando a ferramenta JMeter, ambas ferramentas livres. Aps isso, ser calculado, atravs da tcnica de Contagem de Pontos de Funo, o tamanho ideal da equipe de desenvolvimento tomando como base o software Banco de Currculos e, logo em seguida, comparar o resultado com o quadro de pessoal de que o setor de desenvolvimento da Empresa Doctum de Consultoria Junior de Tefilo Otoni dispe atualmente, sugerindo os devidos ajustes, caso necessrio. Palavras-chave:Teste de Software Empresa Junior Aplicao Software Banco de Currculos.

SUMRIO

INTRODUO ..................................................................................................... 12 2. IMPORTANCIA DA INFORMAO ................................................................ 15 2.1. Sistemas de Informao................................................................... 15 2.1.1. Tipos de Sistemas de Informao ......................................... 16 2.1.1.1. Sistemas de Processamento de Transaes ..................... 16 2.1.1.2. Sistemas de Informao Gerencial .................................... 16 2.1.1.3. Sistemas de Apoio a Deciso............................................. 16 2.1.1.4. Inteligncia Artificial ............................................................ 17 2.1.1.5. Sistemas Especialistas ....................................................... 17 3. ISO 9126 .......................................................................................................... 19 3.1. O que um software de qualidade?................................................ 19 4. PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ............................... 21 5. IMPORTANCIA DOS TESTES DE SOFTWARES ........................................... 23 5.1. Tipos de Testes de Software ........................................................... 23 5.1.1.Teste de Funcionalidade ........................................................ 23 5.1.2.Teste de Usabilidade .............................................................. 24 5.1.3.Teste de Carga (Estresse) ..................................................... 24 5.1.4.Teste de Volume .................................................................... 24 5.1.5.Teste de Configurao (Ambiente)......................................... 25 5.1.6.Teste de Compatibilidade (Funcionamento) ........................... 25 5.1.7.Teste de Segurana ............................................................... 25 5.1.8.Teste de Performance (Desempenho) ................................... 26 5.1.9.Teste de Instalao ................................................................ 26 5.1.10. Teste de Confiabilidade e Disponibilidade .......................... 26 5.1.11. Teste de Recuperao ........................................................ 27 5.1.12. Teste de Contingencia ........................................................ 27 5.1.13. Teste de Integrao ............................................................ 27

5.1.14. Teste Baseado em Requisitos............................................. 28 5.1.15. Teste de Parties .............................................................. 28 5.1.16. Teste Estrutural ................................................................... 28 6. ANALISE DE PONTOS DE FUNO ............................................................. 30
7. RESULTADOS E DISCUSSES ..................................................................... 32

7.1 Implementando o teste de Desempenho com DBMonster ............. 32 7.2 Anlise dos Resultados do Teste de Desempenho ........................ 36 7.1.1. Vantagens ............................................................................. 38
7.3 Implementando o teste de Estresse com JMeter ............................ 39

7.3.1 Anlise dos Resultados do Teste de Estresse ............................................ 44 7.3.2 Vantagens ................................................................................................... 45 7.4. Passos para se determinar o tamanho ideal da Equipe ................ 45 CONCLUSO ...................................................................................................... 51 REFERNCIAS BIBLIOGRFICAS .................................................................... 54 ANEXOS .............................................................................................................. 56 ANEXO A Arquivo dbmonster-schema.xml ........................................ 57

12

INTRODUO

A presente monografia foi elaborada no 8 perodo da graduao em Sistemas de Informao, como requisito final para concluso do curso. Trata-se de um estudo sobre o tema Qual a Viabilidade para a Implantao de Testes de Softwares na Empresa Doctum de Consultoria Junior de Tefilo Otoni?. Sabe-se que nos dias atuais, h uma demanda muito grande na utilizao de softwares, pois, tudo est sendo automatizado, e por traz dessa automatizao, na maioria das vezes h um software trabalhando, programado para funcionar corretamente, mais em alguns casos estes softwares deixam a desejar e sempre esto sujeitos a falhas e erros de funcionamento. Para que se minimize essa situao, existe uma srie de testes que podem ser elaborados na fase de desenvolvimento desses softwares, o que pode ser uma tarefa bem simples para as grandes Software Houses, devido ao seu potencial em recursos humanos e financeiros para investir nessa tcnica que, apesar das suas claras vantagens, custosa e exige profissionais qualificados e experientes . Mas ainda uma tarefa rdua, ou seja, uma realidade um pouco distante para as pequenas e micro empresas desenvolvedoras de softwares, pois, precisam desenvolver softwares, geralmente simples em grau de complexidade, em um curto espao de tempo e assim conseguir atender as muitas demandas propostas por diversos clientes. Porm, exatamente devido a essas exigncias impostas pelos clientes, que desejam o seu software desenvolvido o mais rpido possvel, que a fase de testes ignorada no processo de desenvolvimento. No entanto, essa pesquisa tem como uma de suas principais finalidades demonstrar que existem algumas prticas de testes que podem fazer parte da rotina de desenvolvimento sem afetar de maneira impactante o cronograma acordado no

13

projeto e, ainda aumentando, de forma muito significante, a qualidade dos softwares criados. Quando se adota a prtica de testar softwares, obtido um retorno favorvel para a empresa, sendo que a mesma saber de antemo quais so as deficincias que seu software possui e poder corrig-las antes que o mesmo entre em produo, porm, devido a presso sob os desenvolvedores para cumprirem o prazo estipulado, a primeira prtica a ser descartada o teste de software. O objetivo principal da pesquisa, verificar a viabilidade da implantao de testes de softwares no ambiente de desenvolvimento da empresa Doctum de Consultoria Jnior, tomando como base o software que foi desenvolvido recentemente, que o Banco de Currculos, os demais objetivos visados so, primeiramente, criar um ambiente de teste utilizando-se as ferramentas livres JMeter e DBMonster; executar os testes no software Banco de Currculos, cronometrando o tempo gasto desde o planejamento at a execuo dos mesmos; avaliar o tamanho da equipe atual da Empresa Doctum de Consultoria Junior com base no tamanho ideal utilizando a Contagem de Pontos de Funo; e por ultimo, propor o desenvolvimento de produtos de softwares praticamente livre de falhas e erros. A Empresa Doctum de Consultoria Junior, composta pelos cursos de Administrao, Cincias Contbeis e Sistemas de Informao, atenta ao crescimento das atividades econmicas do municpio de Tefilo Otoni, que consequentemente, resulta em uma grande procura por mo de obra especializada, props a criao do Balco de Empregos, onde a empresa seria uma ponte entre os alunos e os empresrios da regio. Diante disso, o setor de desenvolvimento principiou a desenvolver o software Banco de Currculos para gerenciar de forma automatizada essa intermediao. Porm, os sistemas produzidos pela Empresa Doctum de Consultoria Junior no seguem nenhum tipo de padronizao, em especial a prtica de testes de softwares, por no conhecerem a fundo as ferramentas de automao existentes, por acreditarem que essa prtica no tem uma relevncia considervel dentro do processo de desenvolvimento e por acharem que isso atrasaria o cronograma. Diante do exposto surge a problemtica: Qual a Viabilidade para a Implantao de Testes de Softwares na Empresa Doctum de Consultoria Junior de Tefilo Otoni? Hipteses foram levantadas para avaliar essa questo:

14

H0: A implantao de testes de software na empresa Doctum Consultoria Junior, invivel pelo fato de ser uma pratica custosa na questo de tempo. H1: A implantao de testes de software na empresa Doctum Consultoria Junior, invivel por falta de pessoas, qualificadas e em quantidade adequada, para executar essa funo na empresa.

H2: A implantao de testes de software ir diagnosticar problemas que podem aparecer futuramente depois de sua comercializao, o que ir acarretar de modo geral uma insatisfao por parte do cliente.

H3: Um tempo gasto a mais com testes, ir diminuir ou at mesmo excluir um futuro problema, que possa trazer perdas para o cliente e principalmente, abalar a relao entre as partes envolvidas, ou seja, cliente e empresa.

H4: Empresa com maior credibilidade destacar no mercado pelo fato de seus produtos no apresentarem problemas indesejveis. H5: Fazer o uso de algumas ferramentas de automao como auxilio durante a execuo dos testes, como: DBMonster e JMeter facilita a execuo dos mesmos. Este trabalho quanto natureza classificado como aplicado e, quanto

forma de abordagem qualitativo, pois, foi fundamentado em uma reviso literria, como tambm quantitativo, pois, foram realizados testes e quantificados os seus resultados para posterior anlise. Esta pesquisa foi estruturada em forma de captulos. O primeiro captulo fala da importncia da informao nos tempos atuais, como tambm dos sistemas de informao e sua categorias. O segundo capitulo explana sobre a ISO 9126, que trata das definies de qualidade do produto de software e mtricas para medir as mesmas. O terceiro captulo abrange o processo de desenvolvimento de softwares, abordando todas as suas fases e boas prticas de desenvolvimento. O quarto captulo trata da importncia dos testes de softwares como parte integrante das fases de desenvolvimento, como tambm explana todos os tipos de teste existentes. O quinto captulo define o conceito de Anlise de Pontos de Funo, suas origens e sua finalidade e como esta contribui para a pesquisa. O sexto capitulo trata dos resultados e discurses que foram elaboradas a partir da pesquisa.

15

2. IMPORTANCIA DA INFORMAO

Nos tempos atuais, o que h de mais importante em uma organizao a informao, que a mesma adquiriu organizando os dados que possui, relacionado a algo que se deseja aperfeioar, e principalmente, como auxilio na tomada. Quando a informao utilizada de maneira eficaz, no importa o quanto foi gasto para que ela seja colocada em prtica, e sim, o retorno que a mesma trar para empresa, seja em conhecimento, seja em lucros financeiros. (STAIR E REYNOLDS, 2011, p. 4-6). Uma informao, sendo bem utilizada, trar lucros organizao, mas tambm quando a mesma tratada de forma indevida e imprecisa, pode causar danos e perdas inesperadas e indesejveis, convertendo-se em prejuzos incalculveis. (STAIR E REYNOLDS, 2011, p. 4-6). Mas quando uma informao bem trabalhada, segura e confivel, ela se transforma em conhecimento, algo de sumo importncia para qualquer organizao, seja qual for a sua rea de atuao. (STAIR E REYNOLDS 2011, p. 4-6).

2.1. Sistemas de Informao

Segundo Stair e Reynolds (2011, p. 8) um sistema de informao formado por um conjunto de elementos ou componentes inter-relacionados que coleta, manipula, armazena e distribui os dados e informaes para se alcanar um determinado objetivo especifico. Pode-se dizer que um sistema de informao o responsvel por gerir toda a existncia de uma organizao, pois, tudo o que se refere a ela, deve estar registrado neste sistema, disponibilizando de maneira segura para quem, de alguma forma, tiver a necessidade e autorizao de registrar, processar ou extrair alguma informao do mesmo.

16

2.1.1. Tipos de Sistemas de Informao

2.1.1.1. Sistemas de Processamento de Transaes

um sistema responsvel por gerenciar transaes que so efetivadas dentro de uma empresa. Responsvel por processar todo e qualquer tipo de transaes financeiras, como tambm, as vrias rotinas que fazem parte do processo de ngocio da organizao. Ele ir emitir extratos, gerar balanos, confeccionar inventrios, dessa forma facilitando e agilizando os processos com respostas rpidas e precisas. (STAIR E REYNOLDS, 2011, p. 18-19).

2.1.1.2. Sistemas de Informao Gerencial

um organizado processo que engloba softwares, pessoas e um sistema de armazenamento bem elaborado, combinados para que haja uma harmonia entre esses elementos obtendo assim informaes bem precisas, e assim, o seu administrador poder gerir a mesma, de uma forma mais eficiente. A partir da, ele ir receber informaes detalhadas de todos seus setores internos, como produtos, funcionrios, arrecadao, caixa, reposies, e com todas essas informaes detalhadas em mos pode-se fazer um estudo cauteloso de qual dessas reas necessita de alguma mudana, ou seja, melhorar ou aperfeioar seus aspectos mais relevantes. (STAIR E REYNOLDS, 2011, p. 19).

2.1.1.3. Sistemas de Apoio a Deciso

Um sistema de apoio deciso tem basicamente a mesma estrutura de um sistema de informao gerencial, mas ele se diferencia em sua utilizao, ou seja,

17

em sua funo. Pois ele usado como apoio, exatamente como o nome j diz, auxiliando os gestores a tomarem decises no rotineiras, ou seja, no estruturadas onde o mesmo possui pouco ou nenhum conhecimento sobre o problema. Um sistema de apoio deciso tem grande eficincia para apoiar nesse momento em que o administrador no sabe o que fazer ou qual deciso tomar diante de um problema proposto. Sistemas de Processamento de Transaes alimentam o SAD com informaes rotineiras do dia a dia da empresa, enquanto essas informaes em seu banco de dados so organizadas de maneira de fcil acesso. Dessa forma, quando ocorre um evento no rotineiro na empresa, o sistema poder dar um retorno para o que est acontecendo de errado, propondo uma soluo vivel. (STAIR E REYNOLDS, 2011, p. 19-20).

2.1.1.4. Inteligncia Artificial

Segundo Stair e Reynolds (2011, p. 22) quando maquinas assumem tarefas complexas e perigosas. Pode-se entender melhor esse sistema observando o processo de fabricao de um carro, que um processo quase totalmente automatizado. Algumas pessoas dividem o espao com essas mquinas, mas somente para desempenhar funes mais detalhadas durante o processo de fabricao. E tambm pode-se ressaltar os avanos medicinais que esto surgindo dia aps dia, trazendo solues para o que antes era considerado como algo impossvel de acontecer, como por exemplo, as prteses que esto sendo desenvolvidas, para que em um futuro no muito distante, pessoas com algum tipo de paralisao tenham uma vida normal. (STAIR E REYNOLDS, 2011, p. 22).

2.1.1.5. Sistemas Especialistas

18

So sistemas que foram bem aperfeioados para alguma rea de atuao especfica, onde seu funcionamento embasado em experincias passadas para obter respostas precisas. Os sistemas especialistas so alimentados por conhecimento atravs do ser humano e possui a capacidade de aprender com o passar do tempo, e uma das vantagens sobre o especialista humano que o sistema nunca ir esquecer as informaes inseridas em seu banco de dados. (STAIR E REYNOLDS, 2011, p. 22). Os sistemas especialistas tm a capacidade de determinar a fronteira do problema que se encontra diante do mesmo com a fronteira da possvel soluo, podendo assim, tomar decises e executar tarefas especficas em uma velocidade bem superior ao especialista humano. (STAIR E REYNOLDS, 2011, p. 22).

19

3. ISO 9126

Responsvel por garantir a qualidade de softwares, a ISO define os passos e processos a serem seguidos durante o desenvolvimento de softwares e de testes, para que seja garantida a qualidade do mesmo a partir do que est explicito na normatizao e regras que foram impostas por ela. (NBR ISO 9126 (2003, p. 2) A ISO se divide em duas partes, para que as regras fiquem bem definidas e entendidas quando as mesmas estiverem sendo consultadas durante o processo de desenvolvimento de softwares, sendo que uma parte visa a qualidade interna e qualidade externa e a outra parte responsvel pela qualidade em uso. Assim ambas as partes juntas iro descrever um modelo de qualidade do de software, (NBR ISO 9126 (2003, p. 2). Mas seguindo a diante, estas duas partes se ramificam em outros requisitos que so exigidos para que haja uma validao desse software a fim de ser reconhecido como um software de qualidade. Dentre essas ramificaes, para que possa haver realmente qualidade em um software, se encontra uma que indispensvel durante o processo de desenvolvimento, e que muitas das vezes no praticada, pelo fato de ser um pouco demorada e necessitar de investimentos para que seja uma ao de qualidade e que retorne sucesso aps a sua implementao. So os testes de softwares, que um dos fatores primordiais para se obter um software de qualidade, pois s a partir dos testes que se consegue alcanar a qualidade que o software necessita para ser comercializado com a garantia de o mesmo far realmente aquilo que foi proposto a ser feito. (NBR ISO 9126 (2003, p. 2-11).

3.1. O que um software de qualidade?

20

Software de qualidade aquele que passou por exaustivos testes, foi testado por uma equipe competente que revisou e colocou em pratica todos os testes recomendados para aquele determinado tipo de software. E o mais importante, fez a correo de tudo aquilo que estava com alguma falha ou erro. Revisou e tomou cuidado especial com a segurana do software, pois a segurana considerada um ponto primordial. (BARTI 2002, p. 3-4). Um software com qualidade aquele testado, revisado, seguro, que esteja de acordo com os requisitos impostos pelo cliente e que tenha qualidade garantida pela a empresa que o desenvolveu. (BARTI, 2002, p. 3-4).

21

4. PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

O processo de desenvolvimento de um software um conjunto de passos a serem seguidos e que no final ser gerado um feedback do que foi feito. Tudo se inicia no momento em que os requisitos so levantados juntamente com o cliente, atravs de uma discusso entre o cliente e um membro da equipe que est desenvolvendo o software. Nesse momento, so passados pelo cliente todos os requisitos que o software dever atender. Depois que os requisitos so levantados e entendidos, deve-se ser elaborado o projeto do sistema, onde so definidas tecnologias e ferramentas a serem utilizadas, linguagem de programao, plataformas, tamanho da equipe, entre outros detalhes. Logo aps, comea a fase de implementao, momento em que os programadores executam tudo aquilo que foi determinado no projeto. de suma importncia aps a fase de implementao, que seja feita a validao do software, passando-o por alguns testes, mas principalmente verificando se o mesmo est funcionando de acordo com o que foi especificado nos seus requisitos. E por fim, este software deve estar apto s mudanas e atualizaes que forem necessrias para um melhor funcionamento. (SOMMERVILLE, 2007, p.42). Apesar de existir um passo a passo para o desenvolvimento de um bom software, obedecendo algumas regras bsicas que so facilmente acessadas, h um despreparo muito grande das pequenas empresas de desenvolvimento no que diz respeito a esses procedimentos, talvez por falta de conhecimento da tcnica, ou por acharem que a tcnica lhes custa um tempo precioso que poderia ser usado em horas de programao ou at mesmo por falta de recursos financeiros, e por este motivo, essas pequenas empresas so consideradas amadoras e despreparadas para assumirem as responsabilidades e alcanar as metas no desenvolvimento de um projeto.

22

Por isso que muitas vezes essas pequenas empresas sofrem um grande preconceito, no por serem pequenas, mas por falta de preparao. Pesquisas revelaram que uma grande parte dos projetos que comearam a serem desenvolvidos foi cancelada antes de sua finalizao, outra grande parte falha no momento da implantao, em outros casos, os custos extrapolam de forma bem impactante os custos que foram previstos inicialmente, e os prazos sempre excedem o previsto. (BARTI 2002, p. 6-7).

23

5. IMPORTANCIA DOS TESTES DE SOFTWARES

A princpio, os testes de softwares so vistos como uma tarefa sem importncia e custosa ao ponto de serem eliminados do processo de

desenvolvimento. Mas no como parece. Ele o ponto mais importante durante o desenvolvimento de um software. Em tempos passados, os testes no tinham a mesma intensidade e no era dada a mesma importncia que se dada hoje entre as grandes corporaes na rea de desenvolvimento, pois eles ainda no estavam totalmente fundamentados, os programadores no tinham uma viso do que realmente eram os testes. Os softwares eram simplesmente revisados pela mesma pessoa que o desenvolveu, o que no era muito confivel e costumava dar muitos problemas inesperados, pelo pequeno valor que os testes tinham dentro da organizao. (BARTI, 2002, p. 6-7).

5.1. Tipos de Testes de Software

5.1.1. Teste de Funcionalidade

Segundo Barti (2002, p. 113), este teste responsvel por garantir toda a funcionalidade do sistema, usado para garantir que tudo esteja funcionando corretamente. O teste proposto para avaliar se haver alguma divergncia entre o que foi definido nos requisitos do software, no mesmo, j em funcionamento, este teste no ira lidar com o cdigo-fonte do software, mas somente suas interfaces, ou seja, em execuo. Ele usar as repostas que o software retorna diante de cada solicitao do usurio, para constatar se o mesmo est funcionando de uma forma

24

eficaz e de acordo com o que foi solicitado. Este um teste prioritrio diante dos demais. O teste de funcionalidade tambm pode ser identificado como teste de release, geralmente um processo de teste caixa-preta no qual os testes so derivados da especificao do sistema, pois, seu estudo d-se apenas por meio de estudos de entradas e sadas no software. (SOMMERVILLE, 2007, p.359).

5.1.2. Teste de Usabilidade

Este teste tem por finalidade verificar as condies de uso do software do ponto de vista do usurio final, assim analisando a facilidade de navegao entre as telas do sistema, a clareza de textos e mensagens que so apresentados ao usurio, o acesso simplificado de mecanismos de apoio ao usurio, o numero de interaes para executar uma determinada funo, padronizao visual, entre outros aspectos. O foco principal desse tipo de teste medir a facilidade de manuseio e aprendizagem do produto, como tambm, avisar sobre aes que podem danificar ou perder, de forma irreversvel, dados pertencentes ao usurio. (BARTI, 2002, p. 114).

5.1.3. Teste de Carga (Estresse)

Segundo Barti (2002, p. 114), o teste de carga utilizado para lidar com todas as situaes de uso do software. Ele envolve todo o funcionamento do software, testa a capacidade de resposta perante as variaes de solicitaes, sejam elas em um grande ou pequeno nmero. um teste bastante usado em softwares de misso critica, pois requer um grande esforo em respostas as solicitaes.

5.1.4. Teste de Volume

25

O mesmo autor (2002, p. 115) afirma que esse teste tem a finalidade de determinar os limites de processamento e carga do software, mas diferentemente do teste de carga, este teste observa as oscilaes do processamento, efetuado atravs de solicitaes de grande volume, pois o seu foco principal que o software atinja seu limite mximo de processamento.

5.1.5. Teste de Configurao (Ambiente)

Ainda segundo Barti (2002, p. 115), o teste responsvel por verificar a compatibilidade do sistema com as diversas configuraes de hardwares e softwares existentes. recomendado para avaliar se o sistema est funcionando nos diversos tipos de ambientes que foram especificados no momento em que foram feitos os requisitos do sistema.

5.1.6. Teste de Compatibilidade (Funcionamento)

Teste utilizado para verificar se o sistema ir funcionar em verses e configuraes mais antigas, sejam elas de hardware ou de software, pois, s vezes podem ocorrer incompatibilidades entre os mesmos no momento em que for necessria uma atualizao no sistema. O que significa que algumas interfaces foram modificadas, pois o foco principal garantir que as novas verses consigam se comunicar com interfaces mais antigas mesmo havendo estas modificaes. (BARTI 2002, p. 116).

5.1.7. Teste de Segurana

26

Este teste tem como sua principal finalidade analisar e detectar falhas de segurana que podem existir no software deixando-o vulnervel, pois, um sistema com um nvel de segurana baixo ter suas informaes facilmente acessadas por Crackers ou pessoas mal intencionadas. A idia principal elaborar testes visando quebras de protocolos e algumas outras brechas que podem conter no sistema, ao ponto de deix-lo imune quando houver a tentativa de algum ataque sobre ele. (BARTI 2002, p. 116).

5.1.8. Teste de Performance (Desempenho)

Teste usado para medir o tempo de resposta do sistema no momento em que o mesmo est em seu pico mximo de acessos. Dessa forma pode-se avaliar seu tempo de resposta diante das vrias solicitaes que foram feitas, e assim compar-las com as que foram especificadas em seus requisitos, (BARTI 2002, p. 117). Segundo Sommerville (2007, p.361), o teste tambm projetado para assegurar que o sistema pode operar na carga necessria. Isso envolve geralmente o planejamento de uma serie de testes em que a carga constantemente aumentada at que o desempenho se torne inaceitvel. .

5.1.9. Teste de Instalao

Verifica se o processo de instalao est de acordo com o que foi especificado em seus requisitos, observando durante o processo de instalao, qual o comportamento do sistema perante algumas situaes indesejveis e se ele consegue expor alternativas e solues, para algumas dificuldades encontradas durante o processo. (BARTI 2002, p. 117).

5.1.10. Teste de Confiabilidade e Disponibilidade

27

Segundo Barti (2002, p.118):


Essa categoria visa monitorar o software por um determinado perodo de tempo e avaliar o nvel de confiabilidade da arquitetura da soluo. Essas informaes devem ser coletadas durante a execuo dos prprios testes de sistema, identificando sempre quando uma interrupo foi produzida por uma falha da infra-estrutura (confiabilidade) e contabilizando o tempo necessrio para a resoluo desse problema (disponibilidade). Essas monitoraes so interessantes de serem realizadas junto com os testes de aceite (alpha-teste), nos quais o ambiente fica totalmente disponvel para os usurios e a incidncia de falhas est geralmente associada infra-estrutura da soluo. Em outras situaes, as interrupes provenientes de defeitos de software prejudicariam os ndices de confiabilidade e disponibilidade da aplicao.

5.1.11. Teste de Recuperao

Teste que avalia o comportamento do sistema perante a ocorrncia de um erro, seja do prprio sistema ou do hardware ou software do ambiente em que o sistema esteja instalado. O teste ir verificar a tolerncia do sistema perante esses erros e se o mesmo tem o poder de se manter em execuo, e em que estado o software se encontrar quando as coisas voltarem ao normal. (BARTI 2002, p. 118).

5.1.12. Teste de Contingencia

Segundo Barti (2002, p.119):


Essa categoria de testes visa validar os procedimentos de contingncia a serem aplicados determinada situao prevista no planejamento do software. A idia simular os cenrios de contingncia e avaliar a preciso dos procedimentos. Esses testes devem ser realizados pela prpria equipe de planto, na qual o tempo total de execuo do plano de contingncia tambm ser avaliado.

5.1.13. Teste de Integrao

28

O teste executado de modo que a equipe de teste acesse o cdigo-fonte do software com o intuito de encontrar erros, e quando erros so encontrados essa equipe analisa o cdigo buscando a sua origem, para que o mesmo seja solucionado. Segundo Sommerville (2007, p.357):
Para muitos sistemas de grande porte, provavelmente so usados os trs tipos de componentes. O teste de integrao verifica se esses componentes funcionam realmente em conjunto, se so chamados corretamente e se transferem dados corretos no tempo correto por meio de suas interfaces. A integrao do sistema envolve a identificao de clusters de componentes que realizam alguma funcionalidade do sistema, e a integrao desses componentes pela adio de cdigos que fazem com que eles trabalhem em conjunto. Algumas vezes, um esqueleto geral do sistema desenvolvido primeiro, e os componentes so adicionados a ele.

5.1.14. Teste Baseado em Requisitos

O teste usado para firmar que requisitos devem ser testveis, dessa forma, observa-se que os requisitos levantados antes do desenvolvimento do software foram bem utilizados durante o desenvolvimento de suas ferramentas, e dessa forma pode-se validar que o software est obedecendo risca tudo o que foi levantado e documentado. (SOMMERVILLE 2007, p.364).

5.1.15. Teste de Parties

Segundo Sommerville (2007, p. 365):


Teste de parties no qual so identificadas parties de entrada e de sada e projetados testes de modo que o sistema processe as entradas de todas as parties e gere as sadas em todas as parties. As parties so grupos de dados com caractersticas em comum, como nmeros negativos, todos os nomes com menos de 30 caracteres, todos os eventos que surgem pela escolha de itens de um menu, etc.

5.1.16. Teste Estrutural

29

aplicado o conhecimento da estrutura do programa para projetar testes que exercitem todas as partes do programa, pois ao ser testado, deve-se tentar executar cada declarao pelo menos uma vez. O teste estrutural ajuda a identificar casos de teste que podem tornar isso possvel. E este mesmo teste tambm pode ser identificado como: teste de caixa branca, teste caixa de vidro ou teste caixa clara, nomes usados para diferenci-los do teste de caixa preta. (SOMMERVILLE 2007, p.364,367).

30

6. ANALISE DE PONTOS DE FUNO

Os testes so de suma importncia no desenvolvimento de um software, pois, so executados para avaliar a sua confiabilidade e segurana. Nos tempos atuais existe um uso muito grande de tecnologia, os testes iro expor seus pontos fracos e solucion-los de forma segura. (HAZAN C, p. 27) Pontos de funo, o tamanho funcional de um software levando em considerao, a medida que se faz entre as funcionalidades que o mesmo possui, observadas pelo ponto de vista dos usurios.(HAZAN C, p. 27) Essas medidas devem ser executadas seguindo as mtricas descritas pela IFPUG (International Function Point Users Group), que responsvel pelas regras de contagem dos pontos de funo. (HAZAN C, p. 27) Obedecendo a essas regras impostas pelo IFPUG, utiliza-se o mtodo CEPF (Contagem Estimativa de Pontos de Funo) que contm duas maneiras de medir o tamanho de um software, uma delas a contagem de pontos de funo, que mede o software usando as regras do IFPUG, e existe tambm, a estimativa de ponto de funo, que retorna uma avaliao aproximada do tamanho de um software. (HAZAN C, p. 27) O mtodo CEPF tem a finalidade de fazer a medio de um software, de maneira mais simples , com base nas ferramentas funcionais que o aplicativo possui, dividindo-as em suas funes distintas para se encaixarem na APF (analise de ponto de Funo) que se subdivide em: ALI (arquivo lgico interno), AIE (arquivo de interface externa), EE (entrada externa) e SE (sada externa). (HAZAN C, p. 27) Atravs da Anlise de Pontos de Funo, pode-se extrair informaes relevantes para um projeto e contrato de desenvolvimento de uma software, essas informaes so o tamanho funcional do software, a quantidade de esforo, ou seja, quantos homens-hora necessrios, o prazo de entrega, o custo e, finalmente, o tamanho da equipe. Lembrando que esses valores so aproximados, e que a

31

exatido dos resultados variam de acordo com a experincia da equipe e auxilio de projetos passados bem sucedidos. (HAZAN C, p. 27)

32

7. RESULTADOS E DISCUSSES

A partir de ento, sero aplicados os dois testes propostos anteriormente, utilizando as ferramentas DBMonster e JMeter, onde sero executados testes de Desempenho e Estresse respectivamente, sendo cronometrado o tempo desde o planejamento at sua execuo, analisando assim, suas vantagens em relao a custo, facilidade de uso, entre outros.

7.1 Implementando o teste de Desempenho com DBMonster

O DBMonster uma ferramenta gratuita implementada com a linguagem de programao Java, que a partir de scripts SQL gerados, insere dados criados de forma randmica e os armazena em um banco de dados. Essa ferramenta, que pode ser baixada do endereo:

http://sourceforge.net/projects/dbmonster/, voltada para desenvolvedores de aplicaes com banco de dados que possuem a necessidade de ajustar ndices ou testar o desempenho da aplicao sob um grande volume de carga. Conecta-se com vrios tipos de sistemas gerenciadores de banco de dados como Postgresql, Oracle, Hsqldb, e Mysql, sendo este o SGBD a ser testado, utilizado pelo Banco de Currculos. O teste consiste em gerar dados aleatrios e os inserir no banco de dados da aplicao, afim de testar a carga de inseres simultneas que a mesma consegue suportar. A partir dos resultados obtidos, os desenvolvedores desse sistema tero uma viso de como sua aplicao se comportar durante seu uso em um ambiente real de produo, evitando sobrecargas inesperadas.

33

Inicialmente testaremos a tabela currculos, que se encontra no banco de dados nomeado como Empresa_Junior do Banco de currculos, que pode ser observada na figura 1.

Figura 1: Tabela currculo, do Banco de Currculos das Faculdades Unificadas Doctum de Tefilo Otoni.

Fonte: prprio autor.

Esse teste deve ser executado em uma tabela por vez. Aps a definio da tabela que ser testada, deve-se editar o arquivo de configurao utilizado pela ferramenta que far a insero dos dados no banco de forma randmica, o arquivo est localizado no diretrio raiz /dbmonster-core-1.0.3 e est com o nome dbmonster-schema.xml. No arquivo dbmonster-schema.xml deve ser especificado o nome da tabela e os nomes das colunas que a tabela possui. Feito isso, devem ser criados os arquivos com os dados que sero inseridos na tabela, esses arquivos devem ser de texto com a extenso txt. A partir de ento vejamos como fazer a ligao da tabela currculo com o arquivo dbmonster-schema.xml. No arquivo dbmonster-schema.xml, o nome da tabela do banco de dados e a quantidade de inseres que a tabela ir receber inserido nas tags tablename e rows respectivamente. Para o teste proposto, a tabela currculos ir receber 100 inseres simultneas conforme a seguir, <tablename="curriculo" rows="100"> (ANEXO A, linha 7). A prxima linha a ser configurada onde se insere os nomes das colunas contidas na tabela a ser testada. Neste caso, a tabela currculo possui uma coluna chamada idiomas, ento, deve-se fazer a configurao da seguinte maneira: <columnname="idiomas" databaseDefault="false">, (ANEXO A, linha 19). Esse procedimento deve ser repetido para todas as colunas.

34

Como foi dito anteriormente, devem ser criados arquivos no formato txt contendo os dados que sero inseridos em cada coluna. No caso da coluna idioma, utilizando um editor de texto qualquer, basta criar um arquivo contendo algumas informaes (de acordo com o tipo definido para a coluna) e salva-lo com um nome especifico, em nosso caso o arquivo ser salvo com o nome idiomas_dictionary.txt. Feito isso, o nome do arquivo criado deve ser referenciado da seguinte forma dentro do arquivo de configurao, na tag propertyname: <propertyname="dictFile" value="idiomas_dictionary.txt"/>(ANEXO A, linha 22). Esses passos devem ser seguidos para cada coluna contida na tabela a ser testada. Aps o termino da configurao do arquivo dbmonster-schema.xml, necessrio criar outro arquivo chamado dbmonster.properties que deve ser salvo no diretrio raiz /dbmonster-core-1.0.3. Este arquivo contm as informaes necessrias para que o DBMonster consiga realizar conexo com o SGBD da aplicao. Os parmetros passados so: o tipo de SGBD que est sendo usado (mysql, oracle, etc), IP ou nome do servidor Web, o nome do banco de dados, usurio e senha do mesmo. Observe na figura 2, lembrando que essa configurao est de acordo com a tabela que estamos trabalhando.

Figura 2: Arquivo de configurao do dbmonster.properties.

Fonte: prprio autor.

Aps esta configurao, ser usado o mysql-connector-java-5.1.17-bin, para fazer a comunicao com o banco de dados, e o mesmo dever j estar no diretrio raiz /dbmonster-core-1.0.3. Lembrando que para o teste que est sendo

implementado, o diretrio /dbmonster-core-1.0.3 est localizada na rea de trabalho do computador utilizado.

35

Terminado todos os passos da configurao, deve-se abrir o CMD do Windows, e digitar o seguinte comando para ter acesso ao diretrio /dbmonstercore-1.0.3, conforme a figura 3.

cd Desktop\dbmonster-core-1.0.3

Feito isto, j estar dentro do diretrio /dbmonster, ento, execute o seguinte comando, conforme a figura 3, para que os dados sejam inseridos na tabela destino.: java -classpath mysql-connector-java-5.1.17-bin.jar;dbmonster-core-1.0.3.jar pl.kernelpanic.dbmonster.Launcher -s dbmonster-schema.xml c dbmonster.properties

Figura 3: Comandos digitados na CMD, para que os dados sejam inseridos na tabela destino.

Fonte: prprio autor.

A partir de ento, o dbmonster ir inserir os dados que esto nos arquivos de texto que foram criados anteriormente, nas respectivas colunas da tabela curriculo.

36

Observando a figura1, nota-se que a tabela currculo se encontra vazia, sem nenhum dado inserido na mesma. Agora, ao observar a figura 4, pode-se perceber que dados foram inseridos.

Figura 4: Tabela currculo com alguns dados j inseridos.

Fonte: prprio autor

7.2 Anlise dos Resultados do Teste de Desempenho

Aps o planejamento, configurao e execuo do teste de Desempenho na tabela currculos, foi cronometrado o tempo gasto em cada ao e com base nestas informaes, pode-se determinar o custo mdio de tempo para se adotar esse tipo de teste em sistemas que venham a ser desenvolvidos com porte e complexidade semelhantes ao Banco de Currculos, conforme observado no grfico 2.

37

Grfico 2: Tempo gasto para executar o teste em uma tabela.

Tempo gasto no teste de uma tabela


00:07:12 00:06:29 00:05:46 00:05:02 00:04:19 00:03:36 00:02:53 00:02:10 00:01:26 00:00:43 00:00:00 tabela testada

configurar tabela a ser testada criao de dados a serem inseridos na tabela teste da tabela

Fonte: prprio autor

Levando em considerao que a tabela testada possui cinco colunas, observou-se que foram gastos 00:04:42 (quatro minutos e trinta segundos) para configurao, 00:06:15 (seis minutos e dez segundos) para criar os dados que foram inseridos nas colunas e 00:04:21 (quatro minutos e vinte dois segundos) para execuo do teste. Atravs dos dados obtidos no processo de teste na tabela currculo, foram calculados o tempo de planejamento, configurao e execuo gastos para se fazer os testes em todas as tabelas do Banco de Currculos, conforme apresentado no grfico 3, levando em considerao que o banco de dados dessa aplicao possui 11 tabelas, e um total de 51 colunas.

38

Grfico 3: Tempo gasto para se testar todas as tabelas

Tempo gasto em todas as tabelas


01:12:00 01:04:48 00:57:36 00:50:24 00:43:12 00:36:00 00:28:48 00:21:36 00:14:24 00:07:12 00:00:00 tabelas testadas

configurao das tabelas a serem testadas


criao dos dados a serem inseridos nas tabelas testando as tabelas

Fonte: prprio autor.

Resumindo as informaes contidas no grfico 3, podemos observar que aproximadamente gastar-se-ia 00:48:58 (quarenta e oito minutos e cinqenta e oito segundos) para fazer a configurao de todas as tabelas a serem testadas, 01:02:07 (uma hora, dois minutos e sete segundos) para criar os dados que sero inseridos nestas tabelas e 00:08:21 (oito minutos e vinte e um segundos) para executar os testes nas mesmas. Contudo verifica-se que foi gasto um tempo total de 01:58:45 (uma hora cinqenta e oito minutos e quarenta e cinco segundos) para concluir todos os passos necessrios e executar o teste de Desempenho no Banco de Currculos.

7.1.1. Vantagens

Umas das principais vantagens observadas no DBMonster, foi a facilidade em se desenvolver um caso de teste, sendo que, bastou inserir informaes especficas da prpria aplicao a ser testada em seus arquivos de configuraes que j se encontram pr-configurados. Foi necessrio apenas, criar alguns arquivos no formato de texto, contendo os dados que se deseja inserir em uma determinada tabela do banco de currculos,

39

e logo em seguida, com a simples execuo de alguns comandos no cmd do Windows, que os dados criados foram inseridos na tabela de forma simples e eficaz. Contudo, a grande vantagem do DBMonster a insero de um grande volume de dados simultneos, em uma determinada aplicao, levando em considerao a facilidade de se trabalhar com a ferramenta, que bem simples.

7.3 Implementando o teste de Estresse com JMeter

O JMeter uma ferramenta gratuita, baseada na linguagem Java, desenvolvida e atualizada pela Apache Foudation, para a execuo de testes de Carga e Estresse, que pode ser baixada no endereo: http://jmeter.apache.org/. O teste que utilizaremos a seguir ser o teste de Estresse, que consiste em testar a capacidade de resposta, perante as variaes de solicitaes ao software, sejam elas em um grande ou pequeno numero de solicitaes ao sistema. Assim os desenvolvedores sabero o quanto o software suporta, e podero determinar quais so seus limites de capacidade de resposta. Para iniciar o teste, ser definido o nome do plano de teste. Como pode ser visto na figura 5: Pagina inicial do JMeter.

40

Figura 5: Pagina inicial do JMeter.

Fonte: prprio autor

O JMeter, trabalha com o conceito de threads, que simula usurios virtuais realizando acessos simultneos ao software testado.

Figura 6: definio do nome do grupo e quantidade de usurios.

Fonte: prprio autor

41

De acordo com a figura 6, na tela de grupo de usurios, ser definido o numero de usurios virtuais que faro acesso ao banco de currculos, e nome do grupo criado. No teste que ser executado, o campo nome ser definido como Alunos Doctum, que est representando os alunos reais que faro o acesso no banco de currculos. E no campo Usurios Virtuais (threads) definido o numero de usurios que faro acesso ao banco. Lembrando que esse nmero de usurios que foi definido, faro acesso simultaneamente ao sistema. O passo seguinte ser configurar o servidor HTTP proxy, que responsvel por gravar as aes que o usurio real executa no sistema, e assim, definir que os usurios virtuais executem essas mesmas aes.

Figura 7: Configurao do HTTP Proxy.

Fonte: prprio autor

A partir de ento, de acordo com a figura 7, definida a porta 8080 no campo porta. Definir como localhost no campo incluir do filtro de tipo de contedo. Ento basta gravar o que ser testado, clicando no cone iniciar que est localizado na parte inferior do aplicativo. Feita essas configuraes, ser configurado o navegador da internet que est executando a aplicao. Usando o Mozilla Firefox, basta configurar a conexo de acesso do navegador no campo HTTP: como localhost e em porta: para 8080, e

42

selecionar o campo usar este proxy para todos os protocolos. De acordo com a figura 8.

Figura 8: Configurao do Proxy do navegador.

Fonte: prprio autor

Aps a gravao de todas as aes que foram executadas no navegador, hora de rodar o teste, ou seja, vamos saber como o banco de currculos se comporta durante a execuo deste teste. Para isso necessrio definir que o aplicativo JMeter faa a gerao dos resultados obtidos, em grficos e tabelas como mostram as figuras 9, 10 e 11 respectivamente.

43

Figura 9: grfico de resultados.

Fonte: prprio autor

Figura 10: Resultados em tabela.

Fonte: prprio autor

44

Figura 11: Relatrio Agregado.

Fonte: prprio autor

Aps a definio de como os resultados do teste sero apresentados, basta clicar no menu executar e na opo iniciar, para que o programa inicie o teste. Feitos esses passos, o programa ir exibir os resultados que foram obtidos.

7.3.1 Anlise dos Resultados do Teste de Estresse

Com base nesses passos executados para se testar o Banco de Currculos das Faculdades Unificadas Doctum, pode-se medir o tempo gasto para planejar, configurar e executar os testes em toda a aplicao. Atravs dessa medio pode-se notar que foi gasto um tempo de 27 minutos e 50 segundos para planejar, configurar e executar o teste no Banco de Currculos, o qual pode ser observado na tabela 1.

45

Tabela 1: Tempo gasto para a execuo dos testes. AES Planejar e configurar conexo Gerar as aes que sero testadas Executar o teste sobre as aes geradas Verificar relatrios e grficos TEMPO 00:02:00 00:20:25 00:02:35 00:02:00

Com base na tabela 1, nota-se que foram gastos 2 minutos para planejar o teste e configurar a conexo entre o JMeter e o Navegador Mozila Firefox, e ainda 20 minutos e 25 segundos para gerar as aes que foram testadas, enquanto o aplicativo JMeter gravava essas aes e, por fim, foram gastos 2 minutos e 35 segundos para executar o teste sobre as aes que foram geradas. E ainda utilizouse 2 minutos para fazer a verificao dos relatrios e grficos que foram gerados pelo sistema, afim de saber como o Banco de Currculos se comportou durante a execuo do teste.

7.3.2 Vantagens

Uma das principais vantagens do JMeter que ele simula virtualmente usurios reais que acessam alguma aplicao. Pois ele capaz de virtualizar a quantidade de usurios que o testador desejar, assim, fazendo com que esses usurios virtuais acessem a aplicao simultaneamente, testando qual a carga que a mesma suporta. Com esse teste, o desenvolvedor da aplicao poder corrigir erros que o software apresentar quando ele receber um grande nmero de acessos, alm do mais, seus desenvolvedores tero conhecimento de qual ser a carga mxima que o mesmo suporta com acessos simultneos, podendo esta informao ser utilizada tambm para fins de documentao.

7.4. Passos para se determinar o tamanho ideal da Equipe

46

Atravs da tcnica de anlise de pontos de funo, pode-se determinar qual seria aproximadamente o tamanho ideal da equipe de desenvolvimento e de teste de softwares, lembrando que os testes no devem ser executados pelos

desenvolvedores, mas sim, por profissionais qualificados na rea, devido ao fato de que o programador procura no encontrar erros e sim comprovar que o software desenvolvido por ele no possui nenhum defeito. Os passos sero analisados para verificar se a Empresa Jnior possui um quadro de pessoal adequado para se implantar a fase de testes de softwares em meio seu ciclo de desenvolvimento. Primeiro foi encontrado o valor do Ponto de Funo no Ajustado que chamaremos de PFNA, e que so levados em conta os seguintes atributos: ALI: quantidade de tabelas que possui no banco de dados. E qual a sua complexidade, que pode ser observado na tabela 2.

Tabela 2: Identificao da complexidade de tabelas. N de tabelas 1 a 19 20 a 50 51 ou mais Complexidade Simples Media Alta

Fonte: Manual de praticas de contagem de Pontos de Funo, verso 4.2.1

EE: Quantidade de formulrios que h na a aplicao. E sua respectiva complexidade, que pode se comparada na tabela 3.

Tabela 3: Identificao da complexidade dos formulrios. Formulrios 1a4 5 a 15 16 ou mais Complexidade Simples Media Alta

Fonte: Revista Engenharia de Software Magazine, edio 02

CE: Relatrios simples que o aplicativo fornece ao usurio. Se grau de complexidade pode ser observado na tabela 4.

47

Tabela 4: Identificao da complexidade dos relatrios simples. Relatrios simples 0a1 2a3 4 ou mais Complexidade Simples Media Alta

Fonte: Revista Engenharia de Software Magazine, edio 02

SE: Relatrio Complexo (utiliza algum tipo de calculo ou algoritmo). No h nenhum no aplicativo testado. Com base nas tabelas acima, foram retirados alguns dos dados para nossa pesquisa, que a complexidade de acordo com a estrutura na qual foi desenvolvida o software Banco de Currculos, que possui 11 tabelas, 9 formulrios, gera 2 relatrios simples, e nenhum relatrio complexo. No passo seguinte foi encontrado o valor correspondente a cada complexidade, seguindo as tabelas 5, 6 e 7 podemos ver sua classificao com seus respectivos valores.

Tabela 5: Identificao dos Arquivos Lgicos Internos da Aplicao. N ALIs Simples N ALIs Media N ALIs Complexo X.7 = PF X.10 = PF X.15 = PF

Fonte: Revista Engenharia de Software Magazine, edio 02

Tabela 6: Identificao das Entradas Externas da Aplicao. N EEs Simples N EEs Media N EEs Complexo X.7 = PF X.10 = PF X.15 = PF

Fonte: Revista Engenharia de Software Magazine, edio 02

48

Tabela 7: Identificao das Consultas Externas da Aplicao. N CEs Simples N CEs Media N CEs Complexo X.7 = PF X.10 = PF X.15 = PF

Fonte: Revista Engenharia de Software Magazine, edio 02

Com ajuda das tabelas acima j possvel encontrar facilmente o PFNA. De acordo com o clculo a seguir.

ALI = Complexidade Simples. 11 x 7 = 77. EE = Complexidade Mdia. 9 x 4 = 36. CE = Complexidade Mdia. 2 x 4 = 8 SE = Complexidade Mdia. No h.

PFNA = 77+36+8 = 121. O segundo passo foi encontrar o valor do Ponto de Funo Ajustado que chamaremos de PFA, que encontrado atravs da formula: PFNA x FA, onde FA o Fator de Ajuste. FA = (NI x 0,01) + 0,65. Onde NI o Nvel de Influncia baseada na soma dos valores das 14 caractersticas que um software possui e que podem influenciar no momento do desenvolvimento do mesmo. Caractersticas que podem ser visualizadas na tabela 8.

49

Tabela 8: Caractersticas Gerais dos Sistemas. Caractersticas Gerais dos Sistemas Comunicao de Dados ........................ Processamento Distribudo ................... Desempenho ......................................... Utilizao dos Equipamentos ................ Volume de Transaes ......................... Entrada de Dados ................................. Eficincia do Usurio Final .................... Atualizaes On-Line .......................... Processo Complexo .............................. Reutilizao ........................................... Facilidade de Implantao..................... Facilidade de Operao ........................ Localizao Mltipla .............................. Facilidade de Manuteno .................... Nvel de Influncia (NI) Nvel de Influncia 4 Valor fixo 4 Valor fixo X Valor a definir 1 Valor fixo X Valor a definir 5 Valor fixo 5 Valor fixo 3 Valor fixo X Valor a definir X Valor a definir X Valor a definir 0 Valor fixo X Valor a definir 2 Valor fixo

Fonte: Revista Engenharia de Software Magazine, edio 02

NI = 41.

FA = (41 x 0,01) + 0,65 FA = 1,06.

PFA = PFNA x FA = 121 x 1,06 = 128. O terceiro passo foi encontrar o tamanho ideal da equipe atravs da seguinte formula: Prazo = Esforo / Tamanho Equipe * 6 * 22 (6 horas dirias em 22 dias do ms). Onde Esforo = PFA * horas por PF, sendo que levaremos em conta a linguagem utilizada, PHP (-1h a +7h para programadores experientes), levando em considerao que os programadores da Doctum no so to experientes ainda, colocaremos o valor 10h/pf. Esforo = 121 x 10 = 1210. Prazo = PFA0,34 = 1210,34 = 5,10, ou seja, 5 meses. Voltando ao clculo do tamanho da equipe: Prazo = Esforo / Tamanho Equipe * 6 * 22. 5 = 1210/Tamanho Equipe * 132. Tamanho equipe = 1,83, que arredondando vai para 2 membros. Lembrando que esses dois membros fariam parte somente da equipe de desenvolvimento, trabalhando 6 horas por dia em vinte e dois dias do ms, sendo

50

que o ideal seria, com base no tamanho da equipe encontrada, no mnimo 1 testador trabalhando em igual perodo. De acordo com o levantamento feito na Empresa Doctum de Consultoria Junior, ela consta de um quadro pessoal no setor de desenvolvimento de somente 2 programadores que trabalham de forma eventual, sendo apenas um deles com vinculo empregatcio permanente com a instituio, porm, executando outras tarefas alheias Empresa Doctum de Consultoria Junior.

51

CONCLUSO

A tecnologia evolui dia aps dia, e a maioria de ns nos sentimos atrados por essa evoluo. E com essa alavancada da tecnologia, comea a surgir pequenas empresas que buscam usufruir desse avano, com o intuito de solucionarem problemas em seus processos de negcios que, de forma manual, seria impossvel de solucionar. Mais em alguns casos, onde deveria haver a soluo de um problema, acaba se transformando em um problema muito grave, ou seja, com o intuito de crescer e poder emergir no mercado, pequenas empresas desenvolvedoras de softwares, desenvolvem projetos que no passam por nenhum tipo de verificao, validao ou testes. E com isso foram levantadas algumas hipteses para chegar soluo da questo problema: H0: A implantao de testes de software na empresa Doctum Consultoria Junior, invivel pelo fato de ser uma prtica custosa na questo do tempo. H1: A implantao de testes de software na empresa Doctum Consultoria Junior, invivel por falta de pessoas, qualificadas e em quantidade adequada, para executar essa funo na empresa. H2: A implantao de testes de software ir diagnosticar problemas que podem aparecer futuramente depois de sua comercializao, o que ir acarretar de modo geral uma insatisfao por parte do cliente. H3: Um tempo gasto a mais com testes, ir diminuir ou at mesmo excluir um futuro problema, que possa trazer perdas para o cliente e principalmente, abalar a relao entre as partes envolvidas, ou seja, cliente e empresa. H4: Empresa com maior credibilidade destacar no mercado pelo fato de seus produtos no apresentarem problemas indesejveis.

52

H5: Fazer o uso de algumas ferramentas de automao como auxilio durante a execuo dos testes, como: DBMonster e JMeter facilita a execuo dos mesmos. A hiptese 0 foi invalidada pois os testes aplicados corresponderam apenas a 40% das horas dirias trabalhadas por um programador, sendo que, esses testes no so aplicados todos os dias e sim quando h demanda. As ferramentas de testes tambm se mostraram bastante teis no quesito automao de tarefas. A hiptese 1 foi validada devido ao fato de que, mesmo com auxilio das ferramentas de automao de testes, o testador deve ter um conhecimento prvio e aprofundado das mesmas, como tambm, dominar os tipos de testes existentes para elaborar um planejamento correto. Mostrou-se tambm validada pelo fato de que a Empresa Doctum de Consultoria Junior possuir recursos humanos insuficientes em nmero como mostra o clculo feito atravs da anlise de pontos de funo. A hiptese 2 foi validada com base nos resultados colhidos com os testes de desempenho e de estresse executados no Banco de Currculos, onde foi observado a capacidade de se ver clara e previamente atributos como capacidade de resposta e suporte mximo a volume de transaes. A Empresa Doctum de Consultoria Junior, assim como toda a rede Doctum preza pela qualidade nos servios prestados. Da mesma forma, os sistemas desenvolvidos pela mesma devem manter essa qualidade, validando assim a hiptese 3, onde um problema descoberto na fase de desenvolvimento vai evitar a estreita relao entre a instituio e seus discentes, como tambm, mantendo a posio que a Doctum j conquistou no mercado de instituio sria e focada em seus objetivos, validando tambm assim a hiptese 4. Por fim, durante os testes utilizando as ferramentas DBMonster e JMeter, foi possvel observar a robustez dessas ferramentas aliadas s suas interfaces simples e intuitivas, de fcil configurao e execuo, validando a ultima hiptese levantada. Essa pesquisa pde mostrar que realmente vivel a implantao de testes de softwares no ambiente de desenvolvimento da empresa Doctum de Consultoria Junior, evitando danos futuros com relao a falhas de softwares que venham a ser futuramente desenvolvidos pela mesma, desde que o seu quadro de pessoal seja ajustado de acordo com o que foi proposto no estudo acima. O teste de Unidade o teste feito na menor poro de um software, ou seja, o cdigo fonte. Foram pesquisadas algumas ferramentas de automao de testes de Unidade muito eficazes, porem, no foram aplicadas devido ao fato que s

53

funcionam em cdigos desenvolvidos baseados na programao orientada a objetos, pois, testam classes e mtodos. Com base nisso, fica como Trabalho Futuro a verificao da viabilidade da migrao da atual estrutura do software Banco de Currculos para uma estrutura baseada na programao orientada a objetos, onde facilitaria a aplicao de testes de softwares mais refinados, abriria um amplo leque de opes em ferramentas de automao de testes gratuitas e facilitaria documentaes, manutenes e atualizaes futuras.

54

REFERNCIAS BIBLIOGRFICAS

SOMMERVILLE, Lan. Engenharia de Software.8 Ed. So Paulo: Pearson AddisonWesley, 2007.

BARTI, Alexandre. Garantia da Qualidade de Software. Rio de Janeiro: Elsevier, 2002. STAIR, Ralph M. REYNOLDS, George W. Principios de Sistemas de Informao:Traduo da 9 Edio Norte Americana. 1 Ed. Cengage Learning, 2010.

HAZAN, Claudia. Analise de Pontos de Funo: Uma aplicao nas estimativas de tamanho de Projetos de Software, So Paulo, Engenharia de Software Magazine Ed. 2, p. 31-32, 2009.

NETO, A. C. D. Introduo ao Teste de softwares. Revista engenharia de software magazine edio 06. 2011. NBR ISO 9126-1: 2003, Engenharia de Software Qualidade de Produto.

http://www.linhadecodigo.com.br/artigo/2775/introducao-ao-teste-de-software.aspx acessado em 25/08/2012

http://www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=1097 acessado em 30/08/2012

http://testwarequality.blogspot.com.br/p/ambientes-de-testes.html acessado em 25/10/2012 LUCHINI, A. Projeto aumentando a empregabilidade dos estudantes da doctum to atravs da implantao do balco de empregos. Empresa Doctum de Consultoria Junior, 2011.

55

DBMonster, http://sourceforge.net/projects/dbmonster/. acessado em 25/08/2012.

JMeter, http://jakarta.apache.org/jmeter/. acessado em 25/08/2012.

Test Dictionary, http://sourceforge.net/projects/test-dictionary/. acessado em 25/08/2012.

Black, R., Eldh, S., Evan, I., et al. Glossrio Padro de Termos Utilizados em Teste de Software, http://www.bstqb.org.br/uploads/docs/glossario_pb_1.4.pdf, Verso 1.3br, 2007.

International Function Point Users Group (IFPUG). Manual de Prticas de Contagem de Pontos de Funo. Verso 4.2.1, Janeiro de 2005. http://www.linhadecodigo.com.br/artigo/2775/introducao-ao-teste-de-software.aspx acessado em 20/04/2012. http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-teste-desoftware/8035. Artigo de Arilo Claudio Dias Neto acessado em 11/06/2012

SOUZA, Vinicius Rodrigues; VALE, Ricardo Cunha; ARAJO, Marco Antnio Pereira.Teste de Desempenho de Aplicaes Web com Apache JMeter, So Paulo, Engenharia de Software Magazine Ed. 7, p.36 -47, 2010.

SPNOLA, Rodrigo Oliveira; ARAJO, Marco Antnio Pereira; SPNOLA,Eduardo Oliveira, TESTE SOFTWARE: veja como elaborar casos de teste a partir da especificao de casos e uso.Engenharia de Software Magazine 6 edio. Brasil: DevMedia, 2008.

56

ANEXOS

57

ANEXO A Arquivo dbmonster-schema.xml

<?xml version="1.0"?> <!DOCTYPEdbmonster-schema PUBLIC "-//kernelpanic.pl//DBMonster Database Schema 1.1.dtd"> <dbmonster-schema> <name>Test Schema</name> <table name="curriculo" rows="100"> <key databaseDefault="false"> <generator type="pl.kernelpanic.dbmonster.generator.MaxKeyGenerator"> <property name="columnName" value="id_curriculo"/> </generator> </key> <column name="experiensia_pro" databaseDefault="false"> <generator type="pl.kernelpanic.dbmonster.generator.DictionaryGenerator"> <property name="unique" value="false"/> <property name="dictFile" value="esperiencia_dictionary.txt"/> </generator> </column> <column name="idiomas" databaseDefault="false"> <generator type="pl.kernelpanic.dbmonster.generator.DictionaryGenerator"> <property name="unique" value="false"/> <property name="dictFile" value="idioma_dictionary.txt"/> </generator> </column> <column name="profissao_pretendida" databaseDefault="false"> <generator type="pl.kernelpanic.dbmonster.generator.DictionaryGenerator"> <property name="unique" value="false"/> DTD 1.1//EN" "http://dbmonster.kernelpanic.pl/dtd/dbmonster-schema-

58

<property name="dictFile" value="profissao_dictionary.txt"/> </generator> </column> <column name="data" databaseDefault="false"> <generator type="pl.kernelpanic.dbmonster.generator.DictionaryGenerator"> <property name="unique" value="false"/> <property name="dictFile" value="data_dictionary.txt"/> </generator> </column> </table> </dbmonster-schema>