RESUMO Esta artigodascravaa inffu6nciado uso da farramentasda taste na melhoriada qualidadado software dasanvolvidona OSLOG SOi::..fv\fARES,A DascreveSe aquj todo o procasso dasdea selacl;;:ddoas farramantasnecassariasate sos rasultadosda sue utilizagAo,passando pela montagamdo ambients, cuidadosa tar a vantagens da sua uttlizao. Durantetodo esta prooasso foram ragistadosalguns vs(ores comparativesralativamantaa axacu;:Soda testes com recurseou nae a farramenta.
AUTOMATIZACAO 00 PROCESSO DE TESTES
o relat6rio aborda Osseguintes pontos:
Ferramentas de teste - onde se descreve as motivaJes para o seu uso os tipos de ferramentas de teste existentes e a identifica60 de quais as necessarias ao projeoto; UtilizaV:aodas ferramentas - onde se descrevem os cuidados a ter na montagem do ambiente e na gravao dos testes; Impactos da utiliza60 das ferramentas - onde se descrevem os impactos Que a utiliza8o das ferramentas teve sobre a maneira de trabalhar, sobre a documenta60 dos testes e sobre os tempos de execu96o dos testes; Vantagens e desvantagens no uso da ferramenta onde se apresentam os prob!emas sentidos e o valor aorescentado, resultantes da utilize&o da ferramenta.
onde se apresentam algumas perspeotivas de Perspectives para o futuro trabalho futuro.
Conclus6es
2.1 MOTNACAO O procedimento de teste tern as seguintes fases[Myers79]: * Analise, identificao
do que e que se pretende testar; * Desenho, definigo dos oasos de teste e de come os utilizar; * Execu98o, onde dads uma vers8o do sistema se aplicam todos os casos de teste.
Os testes a uma determinada funcionalidade t6m de ser executados quando eta Le concluida e tSm de ser repetidos sempre Que eta e alterada, e corrigido um problema com ela relaccionado ou e felts qualquer outra alters8o, da aplica5o, Que posse ter implicaCJes no seu funcionamento. - . _ -. __
Considerando ainda Que qualquer alterao no c6digo pode ter efeitos colaterais imprevisiveis, devem-se executar periodicamente testes de regress8o. Estes consistem na reexecu5o de um conjunto de testes para assegurar Que tudo o Que funcionava barn anteriormente, continua a funcionar.
A utilizao de uma ferramenta de taste tern como principal objectivo, a repeti5o da execu5o dos casos de taste libertando assim os elementos da equips de tests para actividades mats interessantes e criativas, como a criao de novos casos de tests.
Com a utilizao de ferramentas de taste o ciclo de Vida das aplicaJes/projectos decresce consideravelmente e aumenta a qua&dads do produto final, devido fundamentalmente sos seguintes factores: * A re-execu98o dos casos de taste tome-se muito mats rapids, pois e automatica,e pods inclusivamente ser desencadeada em periodos em Que os recursos computacionais no forem to necessarios Ce.gdurante a noite); * A possibilidade de erros humanos e eliminada, pois, deixam de ex(stir casos de tests desenhados e n8o executados introdu8o de valores de entrada errados, utiliza98o de vanavets de ambients e imagens incorrectas. * Detec9gLopossivel de zones de c6digo MAotestadas;
DatecgAo previa de problemas de mem6ria; 2.2 TIPOS DE FERRAMENTAS 08 TESTS As ferramentas de taste podem dividir-se Segundoas seguintes categorias [Kit 95]: _Kevls.a.o e I.nspecGa~o - apol.am a execuao_ a.e revl.so~es, verm.- caoe-s e inspec96es dos requisitos desenho funcional documentao, testes e codigo. * Baseadas no C6digo - ajudam o utilizador na: * Analise da complexidade do c6digo - em geral utilizam as metricas de complexidade e ciclomatica de McCabe. * Comprenso do c6digo atraves da uti!izao de graficos de estrutura, identifica8o de dependencies, iderltificac8o de areas de c6digo Quedevem merecer especial ateno e detec8o de c6digo morto. * Analise sintatica e semantics - permitindo a detec98o de erros Que o compilador n8o detects verificao do c6digo, podendo detectar erros sem8nticos e inferir o Que esta sintaticamente incorrecto.Sao normalmente dependentes da linguagem utilizada.
Planeamento de testes - apoiam na definio do 6mbito, dos recursos e das datas previstas para as actividades relacionadas com os testes. Usualmente oferecem formatos pr6-definidos baseadas nas normas ANSI/IEEE.
Desenho e Desenvolvimento - automatizam a geraq;;:8ode dados de taste baseedos num formeto definido pelo utilizedor. Oferecem formatos pr6-definidos baseados nas normas ANSI/IEEE.
Execuc5o e AvaliaGSo - Permitem e execuQ8ode casos de taste e availso dos resultados.Podem ser classificadasem * Capture e re-execuC5o permitem graver todes as ectividedes do utilizador durante o taste, incluindo carregamento em teclas movimenfos do rato, capture de imagens e Va|ores ASCII As imagens e caracteres cepturados servem de Va|ores de compareo ne re-execu98o do tests gravado * Analise de coberture - permitem availer a compietude de um conjunto de testes, mostrando as panes de c6digo n5o testadas. S5o utilizadas com as ferramentas de capture reexecu98o e permitem crier casos de taste Quecobrem 100% do c6digo; -. . ---_ ----_ ^_ * Analise de erros de mem6ria - permitem a detec5o de probfemas de mem6ria no c6digo; * Gest6o de casos de taste - permitem organizer e gerir os casos de taste; * Simu\adores e medidores de desempenho - Perm\tern identificar panes da aplica60 Quedominam o tempo de execu8o da mesma.
Ferramentas de suporte aos testes - Fomecem todo o suporte necessario as actividades relacionadas com os testes.
* GestSo de problemas - s6o utifizadas para gravar, acompanhar e na general(dado assistir na gest5o de problemas detectados quer pelos utiffzadores finals quer pets equips de testes durante o cicfo de Vida dos produtos de software. . GestSo de configuraQ6es - contro\am e coordenam as a\tera9l6es aos documentos, testes e c6digo duranfe o ciclo de Vida do projecto. 2.3 IDENTIFICAgAO OAS FERRAMENTAS OE TESTE NECESSARIAS AO PROJECTO Tomou-se evidente Que, para evitar o esforCo dispendido em testes de regress8o, Que se repetiam sucessivamente durante o ciclo de Vida do Projedo, 56 a automatizaC8o da execu98o dos testes pouparfa tempo e motivaria a equips de testes.
A automatize5o dos testes das componentes interactfvas constituiu o Problema principal, pois, exigia a aquisi8o de urns ferramenta de captura e re-execu95o de eventos de X windows. No momento, e visto ester-se a trabalhar hums 0nice plataforma (VMS), as experi6ncias efectuadas para a obterl95o de urns ferramenta deste tipo n8o foram bem sucedidas pelo Quese optou por central esforCosem: * DocumentaQSoe gest5o dos problemas detectados; . Documental;;;5odos testes efectuados as componentes interactivas uh\fzando urns norma interns baseada na norma [IEEE829); * AutomatizeC80 dos testes efectuados a componentes n5o inferactfvas, ou a panes das quais se pudesse eliminar facilmente a interac96o com o utilfzador. Ao iniclar o trabalho sobre mats plataformas (SOLARIS, HP-"UX) a Quantidade de ferramentas disponfveis fol aumentado, decidindo-Se ent6o a selecCSo e aQuisiC8o de uma ferramenfa de execuGgo e availsG5o com componentes de: * Capture e re-execuo - Que permitie grevar os testes e re-executa-los sempre Que necessario, fornecendo iambem relet6rios sobre o sucesso cu insucesso veriflcado durante a re-execuao; *
Gest5o de casos de taste - Que permitia organizar os casos de teste e criar bateries com os mesmos, fornecendo tambem relat6rios com metricas e informa9go hist6rica relativa a execu(;;8odos testes; * Analise de cobertura - Que permitie detector es zonas de c6digo n&o testades e consequentemente a criao de novos casos de teste.
Os criterios para a seleco de ferramenta foram definidos antecipadamente e incluiram os seguintes aspectos: . . * *
Plataformas e linguagens suportades - A ferramenta teria de trabalhar sobre SOIIARIS, HP-UX , WINDOWS e WINDOWS-NT e teria de fazer analise de cobertura a c6digo escrito em C e C++.
Portabilidade dos ficheiros gerados pela ferramenta correspondentes aos testes gravados Dada a necessidade de execu5o dos mesmos testes em plataformas diferentes, era importante a independ6ncia do ficheiro gerado em relado a plataforma.
Facilidade de gravap5o dos testes qualquer pessoa envolvida no projecto deveria poder usar a ferramenta para gravar testes, geralmente desenhados por algu6m da equipa de testes.
Existencia de outras funcionalidades complementares as de captura/reexecu8o, nomeadamente analise de cobertura e gest8o de casos de taste. Alem desta foram posteriormente adquiridas ferramentas de * Analise de erros de mem6ria Permitem detectar zonas de c6digo com problemas de mem6ria tais como mem6ria alocada e nao libertada, tentativas de utilizacao de mem6ria n8o alocada; * An8Ilse de desempenho - Permitem identi6car zonas de c6digo da aplicao determinam o tempo de execuo.
Que A utilizag8o destas ferramentas durante a re-execu50 dos testes gravados permitia detector as zonas de c6digo com problemas, cobertas pelos casos de taste grevados. ,~ , .'..-.^_ ,-_ 3. UTIUZAII;;;AOOAS FERRAMENTAS Estando perfeitamente canvictos das vantagens da utilizeo de ferramentas de testes, tambem estavamos conscientes Que teriamos de enfrentar algumas dificuldades tais como: * Espao em disco ocupado pelos testes gravados; * Manuten60 dos casos de teste; * Aprendizagem e adapta96o a uma nova ferramenta.
Para minorar sates problemas houve ent6o grande cuidado na defini8o de: * .
Ambiente de grava8o e re-execu8o dos testes;
Cuidadosa ter durante a grava8o dos testes. 3.1 AMBIENTE DE GRAVAI[;;:AOE RE-EXECUl{;;:A0 3.1.1 DISPOSICAO OAS JANEIAS NO SCRAM Tendo em cants Quetadas as pasi96es relativas a clicks e mevimentes do rota s5a capturadas pols ferramenta 6 abrigat6rie Que a dispasiC5o das janelas e (canes usados num determinado teste sejam as mesmas no inicio da grava8o/caPtura e re-execu98a do mesma teste. Qualquer pequeMadlferen9a Mas candil96es iniciais podera levar a falhas ou a resultados enganadares na re execuCSe.Para evifar Que cada pessaa tivesse Que dacumentar cuidadasamente a dfsPasi98o das janelas, antes de iniciar a gravs98e do seu teste optau-se par uma disPas!CADcamum para tadas os testes. 3.1.2 DEFINICAO DEVARIAVEIS, S(MBOLOS E UNKS De mode a permitir Que um teste gravado numa determinada plataforma possa ser re-executado nas diferentes platafarmas e necessarie exist(rem gui6es com a defini5a das mesmas variSveis simbatas e links para as diferentes Platafarmas de mada a garantir Que a interpreta98o seja a mesma. Estes gui6es SAD semPre executadas antes da re-execu6o de cada teste gravado.
Exempio:
Para Ianr um determinada componente da OBLOG CASE e necessaria lan9ar um executavel Que dependenda da platafarma esta em directorios diferentes. Para permitir Que um taste a este componente seja gravado numa unica plataforma e re-executado nas outras, tern"so o seguinte nos gui6es da ambiente: SOIARIS: alias oblog=/apps/smg/smg HP.-UX:alias oblog=/apps/smg/Release/smg VMS:oblog="@oblog_com:setings.com" A grava60 do taste passa a ser independents da plataforma e bastando executar o comando:
$oblog 3.1.3 REPOSITORIOS Dada toda a informa(;:&o,inserida durante um teste as componentes interactivas da OBLOG CASE, ser guardada em reposit6rio e necessario assegurar Que o seu estado inicial seja guardado. Para facilitar esta tarefa e necessario ter farramentas que automatizem a importaAc e exporta8o do reposit6rio. 3.2 CUIDADOS A TER DURANTE A GRAVACAO * O estado inicial da aplica5o em taste dove ser facilmente reproduzivel, tanto em relai;;:6oao ambiente como ao conteL:Idodo reposit6rio. * Devem utilizar-se os bot6es do rato o monos possfvel, de modo a evitar Que pequenas altera96es de posio conduzam a repetiCSoda grava8o do teste; * Sempre que possfvel devem utilizar-se mnem6nicas e keyboard accelerators (conjun96es de teclas que permitem aceder diredamente a uma op98o de um menu sem ter de o abrlr) , de modo a evitar que simples trocas de posiQ8o nos menus levem a repetl8o da gravap6o do teste; * Sempre Quepossivel dove-se capturar s6 a area necess8ria para compara9:5ode modo a economizar o espao em disco. * Devem utilizar-se mecanismos de sincroniza95o de modo a garanfir Que a reexecug5o do teste n8o falhe por alteraC6esno tempo de resposta do sistema. Em geral as ferramentas de captura e re-execuC5o disponibilizam mecanismos de sincroniza~6o com janelas, com areas do ecran ou com strings. -4. IMPACTOS OA UTILIZAI/;:AO OAS FERRAMENTAS 4.1 IMPACTOS NA NOSSA MANE|RA OE TRABALHAR Selecionedas as ferramentas de teste iniciou-Se o processo de automatiza60 de testes ao editor grafico. A primeira fase foi a de grava80 de todos os testes ja desenhados.
De modo a aproveitar, ao meximo, a utiliza5o da ferramenta, foi necessario proceder a algumas altera96es na maneira de trabalhar: * Redesenhar os testes de modo a permitir a reutiliza(;;:5ode certos ficheiros gerados pela ferramenta em verios testes. Antes da gravec8o de qualquer teste, e necessario identificar o conjunto de casos de teste Que possam ser reutilizavets noutros testes e coloce-!os em bibliotecas de ficheiros reutiliz8veis. Minimizando-se assim, o trabalho necesserio na grava(;;:6ode testes, o espaCo em disco ocupado polos ficheiros gerados pela ferramenta e o esforCo de manuten60 de casos de teste;
Exemp!o:
Com a bancada OBLOG e possivel char objectos de 3 categorias diferentes (OBL, TBX D8X). Para todas estas categorias e possivel criar acJes passivas e activas de verios tipos de acordo com determinadas restri6es~ O teste de ariaC&ode acG6estinha o seguinte desenho TCI - Criar acl;:Jespessivas para um objecto tipo OBL TC2 - Criar ac(;;6esactivas para um objecto tipo DBL TC3 - Crier acl;;;6espassivas.para um objecto tipo T8L TC4 - Criar acC6esactivas para um objedo tipo DBX
Para evitar a gravaC8o repetida da cria(;;;5ode ac(;;:6espassivas e activas para cada tipo de objecto estas foram gravadas isoladamente hum fichelro reutilizadas em todos os casos de teste. * Passar a utilizar keyboard accelerators e mnem6nicas sempre Que possivel de modo a minimizar o esforCo de manuten95o dos testes, decorrente das altera(;;;6esefectuadas na aplica(;:5o; SUpcndo Quehum determinado menu tern-se as op96es * SAVE Ctrl+S * PRINT Ctrl+P Ac gravar um taste a funcionalidade de print, se se use o rato para a sue selecicnar directamente a op8o correspondente corre-se o risco de mais tarda este taste vir a falhar por altera9o da posi(;;:5oda op8o.
Se numa posterior vars8o se decidir trocar as posiJes do save e print no menu. O taste Que fol gravado para o print val falhar pois ira em primeiro luger ascolher a op9o da save e o dialogo que Ira aparacer Sara completamente diferente do dialogo Quapareceu quando se ascolheu print. A solu98o para resolver este tipo de problamas e user sampra qua estejam disponiveis os keyboard accelerators (CtrI+P e Ctrl+S), pois estas se foram altarados, fact/manta se alteram nos fichairos gerados pela farramenta da grava(;;5o enquanto qua as posi(;:6as de click s5o muito mais dif(css de determiner a como tel de alterer.
Adapta(;;;5odas ferramentas de fmporta(;;:5oe exportao do reposit6rio OBLOG de forma a serem utilizados a partir da ferramenta de taste;
Adapta(;:o dos gui5es de defini(;;;8ode variaveis, simbolos e /inks; 4.2 IMPACTOS NA DOCUMENTAII;:AO Todos os testes desenhados ate ao momento, estavam documantados Segundo uma norma intama basaada na norma [IEEE&29] Uma vez qua o components de Gast&o de casos de tests perm(tis documentar os casos da tests e respectivas baterias de taste, muita da informao Que astava registada em papal passou a aster embutida na ferramenta.
Por outro lado passou a ser nacessario ter informao ad(clonal relativaments a * Cascs de teste e fiche(ms geradospela ferramanta,relativosa cads taste; * Biblictecas de fiche(ms reutilizaveis; * Ficheiros correspondentes a baterias da taste executados palo Gastor da casos de taste. .~ --~ 4.3 IMPACTOS NOS TEMPOS DE EXECUCA0 Durante todo o processo de automatizaAo, foram registadas alguns Velcros Que nos indicam urns ordem de grandeza relatfvamente a: * Tempo dispendido na grava9o de um teste versus execuo recurso ao uso da ferramenta; do teste sem Veriffcou-se Que o tempo gasto na grava(;;:5ode cada teste era em media ires vezes mais Que o tempo gasto pela pessoa a executa-lo sem recurso a ferramenta. Neste tempo de gravaC8o esta incluido o tempo necess8rio para redesenhar os testes, o Que aconteceu na malaria dos casos e o tempo de adaptso a nova ferramenta.
Tempo dispendido na execu95o da baterias de testes gravados versus tempo Que serfs necessario para repetir a execu8o dos testes sem recurso a ferramenta.
Esta relao e muito varfavel pois, o tempo de execu98o das baterias de teste 8 proporcfonal a sobrecarga da maquina e velocidade de execu(;;;8odefinida para os testes na ferramenta. O tempo de execudo de um teste sem recurso a ferramenta depende do tipo de pessoa Que o val executar.
Contudo a tftulo de exemplo consegufmos obter os seguintes Va(ores: Urn determinado teste planeado para 1 homemldia supondo Que irfa ser executado por uma pessoa rSpida e effcaz, passou a ser re-executado em 5 mfnutos numa situso em Que a maQuinn n8o apresentava grande sobrecarga. A este tempo e preciso adfcionar a ansOsedos resultados Que no caso de sucesso do teste e irrelevante, e no caso de tnsucesso leva a urns analise mats cuidada. 5. VANTAGENS E DESVANTAGENS NO USO DA FERRAMENTA A maioria dos problemas sentidos na utffza95o da ferramenta foram conseQu8ncfa da: * Inexist6ncia de formaC5o para a utiliza5o da mesma, o Que levou a um perfodo de aprendizagem com recurso a manuals e ao grupo de suporte da empress fabricante da mesma; * Altera98o no modo de trabalhar, com vista a evitar a necessidade de ter Que Se redesenhar alguns dos casos de teste levou a uso de bfbliotecas e a um major cuidado, por parte da equipa de desenvolvimento nas alteraJes ao interface grafico; Necessidade de espaco em disco para a grava60 dos testes; Falta de recursos humanos totalmente disponiveis para esta tarefa, o Que levou a um acrescimo do tempo inicialmente previsto para a grava98o dos testes; Dificuldades em fazer as pessoas respeitar as regras definidas para a grava60 dos taste de modo a garantir o sucesso na re-execu80;
Num futuro pr6ximo, pensamos melhorar signiftcativamente este processo, adquirindo ferramentas Quenos permitam fazer * Utiliza8o da ferramenta em ambiente windows e windows-NT para os quais Se est;5oa desenvolver vers6es da OBLOG CASE. Integra60 com a ferramenta de gest6o de configuraJes no novo ambiente de desenvolvimento de modo a permitir o controle de altera6es aos testes gravados em cada vers8o da O8LOG CASE; GeraV;5oautomatics de casos de taste; Analise estatica de c6digo de modo a de obter inforrna8o Que nos permita detectar c6digo mono, variaveis e funJes declaradas e n8o usadas, variaveis n5o inicializadas, comentarios dentro de comentarios entre outras possiveis problemas.
Obten5o de mats metricas relacionadas com o c6digo fonte relativamente a linhas de c6digo, linhas de coment8rios, nOmero de funC6es, complexidade ciclomatica.
Obten95o de m6tdcas mats rigorosas relativamente ao desempenho na gravec::6o de testes, de modo a permitir availer com mats rigor o tempo ganho com automatiza(;;&odo processo de taste. 7. CONCLUSOES Este artigo apresentou uma descri9o da automatiza5o do processo de testes usado na OBLOG Software, com recurse ao uso de ferramentas de teste. O valor acrescentado resultante da utiliza9o das mesma, fez-se sentir em varies campos, dos quais importa salientar; . Redu9o do tempo necessano para as diferentes fases de teste com consequente redu98o do ciclo de Vida de cada de desenvolvimento de soare; * Reduco de erros humanos isto e, casos de teste que ficam por executor, variaveis de ambiente mat definidas; * Detec(;;;8o previa, de areas de c6digo no testadas com o uso da ferramenta de anal|Sede cobertura; * Detec8o de problemas de mem6ria, re-executando os testes com imagens linkadas com a ferramenta de analise de mem6ria; * Maior facilidade na obtencAo de metricas; * Major grau de motivaC8oda equipa de trabalho; . Aumento da qualidade do processo de desenvolvlmento e do produto final, come consequ6ncia 6bvia dos ponies referido acima. [Myers79} Glenford J. Myers , The Art of Sottware Testing Wiley ,1979. [Yourdon95] Ed Yourdon "New Development Strategies, March 1995.
Testing", Application [Beizer9O] Seizer B. Software Testing Tecniques, Van Nostrand Reinhold, 1984 [kit95] Edward Kit, "Software Testing in Real World" Factor Equilibrio, Junho 1995. [SES94] Mazza C.,Fairclough J. Me\ton, Pablo D. de, Scheffer A., Stevens R., Software Engineering Standards. Prentice Han Intemacional (UK) Limited, 1994 [IEEE829} ANSUIEEE Documentation
Std 829-1983 -IEEE