zezologs

Testes Instáveis do Selenium

eudescosta — Tue, 02 Jun 2009 13:33:22 +0000

Já recebi alguns emails, onde as pessoas me questionam sobre o Selenium, questionando principalmente sua competência funcional.

Alguns, falam que hora funciona, hora não funciona, outros falam que quando executa o teste manualmente o teste passa, mas quando roda no Selenium ele não passa.

Bem, é complicado analisar estas questões remotamente, geralmente os questionamentos sobre estes problemas, vem com pouca informação e não da para avaliar a causa do problema, desta forma só consigo ver o efeito e trabalhar nele … e isso me deixa bastante incomodado, não gosto de trabalhar no efeito e sim na causa.

Bem, Simon Stewart do Google, montou uma pequena lista relatando algum destes problemas, dêem uma olhada no post do pessoal, talvez, tenha algo no post que pode lhe ajudar.

http://googletesting.blogspot.com/2009/06/my-selenium-tests-arent-stable.html

PS. Se alguem precisar de ajudar para traduzir algum problema que o Google botou lá me avisa que traduzo (só não abusem da ‘alma boa’ aqui ;))

comentários

sexta-feira, junho 5, 2009, Liana comentou: show teu blog, zezinho! bjos

sexta-feira, junho 5, 2009, Elóra Dana comentou: ≈shock≈ Olá estou tendo esses problemas também, ainda bem que encontrei esse post, irei procurar na lista do Google. Tenho outra dúvida, estava lendo a respeito do LoggingSelenium: http://loggingselenium.sourceforge.net/usage.html Você tem alguma informação a respeito, estou começando a mexer no Selenium e queria saber como criar um log, eu vi essa biblioteca, mas não consigo executar nem o exemplo que está no site. Não tem muita explicação de como configurar os jar. Você sabe onde posso encontrar um exemplo? Obrigada.

quarta-feira, junho 10, 2009, BobMarche comentou: Thanks for the useful info. It's so interesting

quinta-feira, junho 11, 2009, eudescosta comentou: @Elóra Dana: Infelizmente nunca mechi o LoggingSelenium. :( @Liana: Valeus! :) @BobMarche: Thanks for sharing your opinion! ;)

terça-feira, junho 23, 2009, Leonardo Molinari comentou: As suas colocações sobre a ferramenta são importantes. Questionar sempre é fundamental. Fica aqui um convite: aceita ser entrevistado p/ meu blog, sobre o seu trabalho de divulgação de qualidade/testes? Se aceitar te envio várias perguntas, e publico no meu blog. Aceita?. Inclusive seu site está no meio das referências do meu livro novo, em um dos capítulos. Parabens... Meu livro novo, Testes de Performance, já está disponível para venda no site da Ed. Visual Books desde ontem. Veja lá o sumário p/ vc ter idéia. Ele já está causando um enorme impacto. Veja no link: http://www.visualbooks.com.br/shop/mostralivro.asp?escolha=9788575022467 Abraços, Leonardo Molinari

sábado, julho 4, 2009, eudescosta comentou: @Leonardo: Obrigado, pelas palavras. Quanto a sua entrevista, convite aceito. :)

Uma nuvem…do que foi falado aqui

eudescosta — Mon, 01 Jun 2009 15:35:58 +0000

Um post relâmpago.

O que mais foi discurido aqui no blog, desde seu início, em forma de nuvem.

O que diferencia esta nuvem da tradicional ‘tag cloud’ do Wordpress e similares, é que no Wordpress o usuário tem que informar qual a trag do referido post, já o Wordle, lê seu RSS, e faz uma média das palavras mais utilizadas no seu blog.

O resultado você vê abaixo.

Clique aqui para ver diretamente no site Wordle.

Estimando Esforço de Automação

eudescosta — Wed, 27 May 2009 14:46:12 +0000

É muito comum passarmos por situações onde temos que realizar uma estimativa de quanto tempo levaremos para automatizar uma suite de testes.

Duas boas dicas para realizar estas estimativas.

1) O esforço de automação é geralmente 1/3 do esforço de desenvolvimento, logo, se para se implementar uma funcionalidade que o desenvolvedor levou 3 dias, estima-se 1 dia para escrever os testes para esta funcionalidade

2) Estima-se que se leve de 3 a 10 vezes a mais, para automatizar um teste, do que o tempo levado na execução manual. Logo, se um teste leva 1 minuto para ser executado manualmente, estima-se que se leve de 3 a 10 minutos para automatiza-lo.

Pronto, levando em conta estes dois fatores, sua estimativa será bem razoável.

Apresentação de Introdução a Automação

eudescosta — Tue, 26 May 2009 21:17:05 +0000

Estou disnponibilizando uma apresentação de introdução a automação de testes (estruturais e funcionais).

Esta apresentação visa prover uma visão geral sobre automação, muito bom para aqueles que estão iniciando e querem conhecer um pouco mais sobre esta prática, segue agenda:

Motivação
Erros Comuns
Processo
Frameworks
Automação Caixa Branca
Automação Caixa Preta

Qualquer dúvida é so comentar.

comentários

quarta-feira, maio 27, 2009, Leonardo Molinari comentou: Oi.. tudo bom? Boa apresentação. Sempre é bom ter coisas assim. Parabens Dica boa: na tua lista de livros, seria legal atualizar pois o meu de livro de Testes Funcionais, já é referencia neste aspecto. E mais... ups (fofoca.. hahaha). Está saindo o meu de testes de performance. Esse é mais profundo. Não é livro de ferramenta. ë de tecnica, ensinando analisar testes, graficos de performance, descobrir gargalos. Vc vai adorar. Vou até em Teoria da Filas.. ahhaha.. Quando sair te aviso. Vai ao lançamento? será em SP. [ ]s Leonardo Molinari

Top 10 vulnerabilidades em aplicações web

eudescosta — Mon, 13 Apr 2009 14:08:25 +0000

Pessoal,

Segue uma lista das 10 principais vulerabilidades em aplicações web, que recebi por email, recentemente.

Para nós, essa é uma lista muito interessante.

1º - XSS Cros site scripting - 13% das ocorrências. Técnica de ataque que permite executar scripts maliciosos no navegador do usuário da aplicação vulnerável.

2º - Manipulação de dados ocultos - 13% das ocorrências. A aplicação vulnerável permite acesso indevido quando dados ocultos são manipulados indevidamente.

3º - Falha ao restringir acesso a URL ou funcionalidade - 11% das ocorrências. A aplicação não restringe adequadamente suas áreas restritas.

4º - Tratamento indevido de erro, revelação de informações sensíveis - 9% das ocorrências. A aplicação revela informações sensíveis através de uso não esperado.

5º - Armazenamento inseguro de criptografia - 9% das ocorrências. Dados sensíveis que precisam ser armazenados de forma criptografada estão em texto livre ou com criptografia inadequada.

6º - Comunicação insegura - 8% das ocorrências. A aplicação trafega dados sensíveis através de canis não-seguros.

7º - Falha da especificação de requisitos - 8% das ocorrências. Os controles de segurança que deveriam existir não existem devido a falha na especificação.

8º - Injeção de comandos - 8% das ocorrências. Técnica de ataque que explora injeção de comandos através de aplicação para ser processado por outros sistemas ou camadas. Por exemplo: SQL Injection, SMTP Injection, HTML Injection etc.

9º - Processo inadequado de cadastro de usuários - 5% das ocorrências. O cadastro de usuário deve seguir algumas recomendações de segurança, que se não forem seguidas, podem expor a aplicação a diversos incidentes.

10º Quebra de autenticação e gerenciamento de sessão - 5% das ocorrências. Aplicações vulneráveis permitem burlar o processo de autenticação através de gestão fraca de sessão ou procedimentos inseguros. Outros ataques respondem por 11% das ocorrências - vide gráfico neste endereço

Fonte: http://wnews.uol.com.br/site/noticias/materia.php?id_secao=4&id_conteudo=10324

Há tambem um gráfico feito por Ricardo Kiyoshi Batori, da http://www.batori.com.br/, que reflete a lista acima.

Questionamentos sobre o Testlink (#1)

eudescosta — Sun, 01 Mar 2009 20:44:31 +0000

Irei responder em forma de post, algumas perguntas feitas pelos leitores do blog. É uma boa forma de valorizar a participação do leitor e ao mesmo tempo ajudar aqueles que por ventura tenham a mesma dúvida.

Irei responder os questionamentos do leitor Ubiratan referente ao post Ferramentas de Teste: Testlink.

1) Qual seria a técnica e o critério de teste que essa ferramenta utiliza?
R- O Testlink não se preocupa com a técnica de teste a ser utilizada. Seja ela caixa-branca, preta, cinza ou testes de RNF´s. A ferramenta irá apenas armazenar o resultado reportado e prover informações via relatórios (resumidamente).

Utilizo o Testlink para registrar a execução de testes caixa-branca (testes unitários e de integração), bem como a execução dos testes funcionais.

A forma como você irá organizar sua suíte de testes no Testlink depende de você.

O mesmo fundamento vai para o critério de teste (completude, corretude, etc…), a ferramenta deixa a critério daquele que escreve os testes, a definição do critério a ser utilizada.

2) Qual a maturidade desta ferramenta? Faz muito tempo que ela foi lançada?
R- O Testlink é amplamente utilizado por diversas empresas no Brasil e fora.

Não tenho como falar em números exatos, pois não tenho estas informações, mas recebo alguns emails de leitores de várias empresas com dúvidas na ferramenta.

Em pesquisa finalizada em 23/04/2008 o Testlink lidera em relação a ferramentas opensource

Fonte: http://www.teamst.org/index.php?option=com_content&task=view&id=61&Itemid=2

3) Você sabe qual o grupo de desenvolvedores que mantém essa ferramenta?
R- A ferramenta é open source gerenciada por um grupo de desenvolvedores, mais informações aqui. Eles mantêm um grupo no google onde testers podem contrubuir, desenvolvendo e ajudando a melhorar a ferramenta.

Comentários abertos para aqueles que desejam complementar as respostas acima.

comentários

sexta-feira, junho 5, 2009, Neimar Vieira comentou: Por favor estou com problema ao abrir o Testlink, esetou abrindo ele pelo wampserver_ localhost_Testlink e esta dando a seguinte msg Missing file: C:\wamp\www\testlink\third_party\adodb/drivers/adodb-[configure_bug_track_db_type].inc.php ADONewConnection: Unable to load database driver '' o que devo fazer Grato

sexta-feira, junho 5, 2009, eudescosta comentou: Difícil analisar remotamente, mas é um problema de ambiente (APACHE + PHP + MYSQL)... .

Bugs do Homem

eudescosta — Mon, 02 Feb 2009 02:48:49 +0000

Esta semana presenciamos o bug do google, que falou por alguns minutos que todos os sites do mundo eram ‘perigosos’. O bug foi resolvido, e a causa de seu erro, foi atribuída a um humano.

Unfortunately (and here’s the human error), the URL of ‘/’ was mistakenly checked in as a value to the file and ‘/’ expands to all URLs.

O resultado você vê abaixo…

Hoje, enquanto estava navegando, passei pelo site do globo, e vi a imagem abaixo

Os dois erros acima foram erros bobos, causados por nós, humanos, em momentos de ‘breve distração’, mas que repercutem bastante.

Deixo dois links bem interessantes para quem se interessar

No 1 link, tem uma tabela interessante, veja abaixo:

Description

Error Probability

General rate for errors involving high stress levels

0.3

Operator fails to act correctly in the first 30 minutes of an emergency situation

0.1

Operator fails to act correctly after the first few hours in a high stress situation

0.03

Error in a routine operation where care is required

0.01

Error in simple routine operation

0.001

Selection of the wrong switch (dissimilar in shape)

0.001

Human-performance limit: single operator

0.0001

Human-performance limit: team of operators performing a well designed task

0.00001

comentários

segunda-feira, fevereiro 2, 2009, Eudes via Rec6 comentou: Bugs do Homem | zezologs... Pequenos erros causando grandes transtornos...

Feliz Ano Novo!

eudescosta — Wed, 31 Dec 2008 03:00:00 +0000

Obrigado a todos que acompanham o blog, a participação de vocês foi fundamental e ajudou muito este blog a atingir seu objetivo.

Para vocês, um Feliz Ano Novo!

Não sou adepto das tradições de fim de ano… não me visto de branco, ou qualquer outra cor que simbolize algo, nem tomo banho de mar para lavar a alma, simplesmente não aderi a estas tradições.

Para mim, o que vale é a reflexão, e estabelecimento de novas metas… que, por sinal, nem deveria esperar o fim de ano para ser feita

Mas vamos lá, vamos aos resultados deste ano de 2008:

Passados: 95%
Bloqueados: 2%
Falhados: 3%

Meu percentual de aceitação gira em torno dos 95%, logo, podemos afirmar que o ano de 2008, foi um projeto de sucesso! Nos resta agora esperar pelos defeitos escapados.

Por enquanto, fico na espectativa dos bugs que 2009 irá achar.

Na vida pessoal, devo apenas agradaçer a amorosa companhia e paciência da minha amada, agradeçer aos amigos por mais esse ano de camaradagem, e aos meus pais… bem quanto ao meus pais, serei eternamente grato a tudo.

Na vida profissional, ainda aprendo, e enquanto estiver aprendendo, estarei feliz.

Aprendi muito com o projeto em que trabalhei anteriormente, o que me fez amadurecer ainda mais.

No projeto em que me encontro atualmente, estabeleci uma meta: Automação, e graças ao amadurecimento supracitado, as coisas fluiram muito bem.

Automação, por sinal, passará a fazer parte de minha rotina em 2009, implantei automação caixa branca no projeto atual, e até hoje não sei porque nunca tinha feito isso antes

Quanto ao blog, fechamos o ano com mais de 5,776 visitas, onde 3,126 são visitas únicas e 16,902 page views e uma taxa de 53,95% de novas visitas por mês… para um blog que começou sem pretenção alguma, acho estes números muito bons.

Fico bastante feliz em saber que várias pessoas foram beneficiadas pelo uso do blog, por isso, planejo manter a mesma postura, postando ainda mais informações úteis.

Sucesso e tudo de bom!

Testlink: Exportação de Casos de Teste

eudescosta — Wed, 12 Nov 2008 17:52:14 +0000

Para quem trabalha com escita de testes em português e por ventura precisar exportar os testes do testlink, talvez passe por um pequeno contratempo com relação a exportação dos testes.

Alguns caracteres, como por exemplo: ‘ã’, ‘ç’, serão impressos na codificação do html (a lista completa está aqui).

Isso impede que a funcionalidade de exportar seja funcionalmente utilizada, pois a leitura do artafato fica prejudicada.

Bem a solução para isso é bem simples.

Vá no arquivo config.inc.php, altere a linha 117 para

define('DB_SUPPORTS_UTF8', FALSE);

Vá no arquivo tcexport.php, acresente apos a linha 129

$content = html_entity_decode($content);

Bem é isso!

Qualquer dúvida é só falar.

comentários

quarta-feira, abril 8, 2009, Chicohuck comentou: como faço para traduzir a ferramenta para o português? Você pode me ajudar? Valeu,,..

sábado, maio 2, 2009, Alexandre comentou: Olá amigo, eu tentei fazer as alterações que vc está orientando para resolver o problema de acento no testlink, porém não consegui... O arquivo config.inc.php só tem 103 linhas... Você pode me ajudar? meu testlink é o 1.8.1

segunda-feira, maio 4, 2009, Alexandre Santos comentou: Bom dia! Você poderia me enviar o arquivo config.inc.php já com a alteração para eu fazer a comparação com o meu arquivo? Pode me enviar no meu email: alexandre.silvasantos@gmail.com Desde já agradeço. Alexandre

segunda-feira, maio 4, 2009, eudescosta comentou: Alexandre, Não estou com o testlink agora, mas a versão que usei foi a 1.7.4.

Automação e Códigos Não Testáveis

eudescosta — Thu, 06 Nov 2008 14:07:31 +0000

No início do projeto que participo atualmente, passei por algumas dificuldades em automatizar alguns testes, devido a forma como o código estava sendo produzido.

Após algumas conversas com a equipe, conseguimos tornar o nosso código testável, e atualmente não temos problemas.

Uma das grandes barreiras que achei neste processo de automação caixa branca, foi convencer os desenvolvedores que escrever um código testável não é ‘capricho’ e sim uma necessidade diante da retorno que estes testes propocionam.

Bem, para quem está passando pelo mesmo problema, segue um slide do pessoal do google falando sobre o assunto.

comentários

domingo, dezembro 14, 2008, Jackson comentou: Ola. Muito bons os conteúdos de seu blog, parabéns! Realmente convencer programadores de codificar de forma adequada, não é fácil. Ministro aulas de programação e a cada dia vejo mais e mais novatos aprendendo a programar somente na cópia de códgos da internet e não se aprofundando em metodologias, em estudar a linguagem em si e etc. :/ Vou me sintonizar no RSS. Abraço

Dilbert e seu Tester, o Bob Bastard

eudescosta — Tue, 28 Oct 2008 15:58:09 +0000

Dilbert, pra quem não conhece é um personagem em quadrinhos criado por Scott Adams, a descrição de Dilbert segundo o Wikipedia…

Tem 30 anos, é engenheiro e trabalha numa empresa californiana de alta tecnologia. Prefere os computadores às pessoas. Trabalha fechado em cubículos, veste roupas sem graça e a sua barriguinha revela as longas horas de trabalho sedentário. É o mais famoso da família Adams. Vive com o seu cão, Dogbert.

Então, estava ontem em casa assistindo os vídeos de dilbert no youtube, e encontrei uma série dedicada aos engenheiros de teste.

Todos nós sabemos que existe uma atmosfera quase que folclórica em torno dos engenheiros de teste, somos vistos como o carrasco em um projeto, aquele que sente prazer em achar bugs, quando maior a criticidade do bug maior a felicidade do tester.

Os desenvolvedores, por sua vez andam na contra maré, quanto menor a criticidade dos bugs, maior a felicidade dos desenvolvedores, isto proporciona um cenário hostil perfeito.

Nos projetos em que passei, o relacionamento testers vs. desenvolvedores sempre foi muito saudável, isso deve-se, acredito eu, a nossa maturidade. A importância dos testers é inquestionável, quanto a isso ninguem tem dúvida, toda a equipe absorve esta idéia ,e o ambiente, que acima descrito seria de grande hostilidade, simplesmente não é.

Mas é claro que todo este clima rende piadas em sua maioria bastante engraçadas e discontraídas.

Dilbert, por sua vez, não poderia deixar isso passar batido, e fez sua parte, vejam os vídeos abaixo, e divirtam-se!.

Dilbert Cartoon 01X05- Testing - part 1/3

Dilbert Cartoon 01X05- Testing - part 2/3

Dilbert Cartoon 01X05- Testing - part 3/3

comentários

terça-feira, outubro 28, 2008, Eudes via Rec6 comentou: Dibert e seu Tester, o Bob Bastard. | zezologs... Dilbert em sua série dedicada aos engenheiros de teste...

Engenharia de Testes, Caso: Google, Zurich

eudescosta — Mon, 20 Oct 2008 16:14:40 +0000

Um link bem interessante escrito por Roshan Sembacuttiaratchy “Engenheiro de Sistemas em Teste” do Google.

Achei o texto muito bom, e concordo muito com o que está escrito lá, acredito que o papel de Engenheiro de Testes é muito mais “envolvente” do que muita gente pensa!

Pra quem trabalha com testes é uma leitura obrigatória.

Outra coisa bem interessante é como ele se intitula “Engenheiro de Sistemas em Teste”, acredito que pelo texto abaixo…

“The people working in Test Engineering are software developers with a passion for testing and test automation.”

…deduziremos.

Muita gente pensa que um Engenheiro de Testes senta em frente do computador apertando botões, esperando por resultados esperados, definidos nos casos de teste, mas diferente disso, acredito que nosso papel vai muito além disso.

…When I tell people that I’m a Test Engineer at Google, I get a confused look from them and questions as to what I actually do. Do I sit in front of a keyboard clicking every button and link on screen? Do I watch over the infinite number of monkeys, checking to make sure they produce Shakespeare’s work while clicking said links? Or do we create better and smarter pigeons?…

…Test Engineering’s objective is to help improve the quality of the projects we’re involved in. We work integrated with the project team, developing test frameworks and setting up test systems…

…One of our key mantras is automation, so our first task whenever we’re assigned to a new project is to evaluate the current state of test automation, identify what we could do to improve the results obtained, reduce the total run time, and make the best use of available resources…

So to answer the questions posed initially, I write software which performs the task of clicking every button and every link, and which then verifies the result of these actions.

O post completo pode ser acessado em http://googletesting.blogspot.com/2008/10/test-engineering-at-google.html, recomento fortemente a leitura.

comentários

quarta-feira, outubro 22, 2008, Eudes via Rec6 comentou: Engenharia de Testes, Caso: Google, Zurich | zezologs... Post muito bom do site de testes do google, engenheiro de testes vai muito além do que muita gente pensa! ...

Mudança de Layout e Algumas Explicações

eudescosta — Sat, 18 Oct 2008 04:29:33 +0000

Fui ali no pai Google e voltei com esse novo tema, cansei do tema anterior, não sou designer, e com o tempo as imperfeições do tema que criei estavam me incomodando, e antes que me irritasse de vez, decidi trocar.

Bem, aproveitando o ensejo, deixe-me aproveitar para justificar minha ausência nestes dias. A vida está corrida, muito corrida… Estou dando aula em uma faculdade local e não imaginava que preparar aulas fosse tão oneroso, mas no fim das contas acaba sendo divertido. Além das aulas tem a especialização.

Irei organizar meu tempo e postar algumas novidades que tenho pra falar, e não irá demorar muito até o próximo post!

UPDATE (19/10/2008 2:00 AM)

Depois de tanto ir e vir do pai Google com novos temas para o blog, cheguei a uma conclusão…

nenhum tema é tão bom e eficiente, quanto aquele que é feito por você.

Procurei por horas por um novo tema que atingisse minhas expectativas e não achei, por isso voltei a versão inicial (e ao meu ver eficiente) e irei trabalhando em outro tema off-line.

Dica: MSTest (/noisolation e arquivos de configuração)

eudescosta — Thu, 18 Sep 2008 19:59:08 +0000

Passei duas manhãs tentando resolver um problema na análise de cobertura de código, provocado por uma modificação em nossa arquitetura aqui no projeto.

Usamos o VS 2008 para a implementação dos testes unitários/integração, este projeto encontra-se em uma solução diferente da solução de desenvolvimento, como trabalhamos manipulando vários arquivos, meus testes sempre se perdiam quando os desenvolvedores chamavam alguns métodos do framework do VS que informava o caminho dos arquivos a serem manipulados pela aplicação.

Bolamos uma solução para isso, e para tal, foi necessário a inclusão de um arquivo de configuração no projeto de testes, onde neste arquivo eu informava ao VS qual o caminho dos templates, arquivos de configuração, etc.

Bem, tudo aconteceu muito eficientemente, até o dia que tive que coletar a cobertura dos meus testes, pelo NCover.

Agora foi a vez do MStest se perder nos caminhos dos arquivos de configuração, templates, etc. … mas a solução para isso foi facilmente encontrada nos forums do msdn.

Seria necessário, indicar para o mstest a localização do arquivo .testrunconfig e rodar o MStest no mesmo diretório em que se encontra o seu arquivo de configuração (.config)

/testcontainer: /runconfig:.testrunconfig

Feito isso, tudo roda tranquilamente.

No entanto, para rodar os testes pelo NCover preciso usar o /noisolation e esse é o problema, pois existe uma “combinação maldita” nesse cenário.

Quando rodamos os testes pelo mstest usando o /noisolation e mais um arquivo de configuração (/runconfig:.testrunconfig), precisamos realizar algumas alterações no arquivo de configuração do mstest para que tudo funcione corretamente.

A razão pelo qual isso faz-se necessário, é porque quando indicamos o /noisolation o VS roda os testes baseado no processo do MSTest.exe e não pelo VSTestHost.exe (utilizado ao rodar os testes pelo IDE do VS), desta forma quando fazemos isto, temos que alterar também o arquivo MSTest.exe.config localizado geralmente em C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE.

Meu arquivo originalmente contêm as linhas

Mas tive que realizar algumas alterações e inclui as mesmas linhas contidas no meu arquivo de configuração (.config).

Feito isso, tudo funcionou perfeitamente.

Bem, como passei um bom tempo (duas manhãs) para resolver este problema, simplesmente porque não achei nada em forums que respondesse minha questão, estou relatando isto aqui no blog para ajudar alguem que possa estar passando pelo mesmo problema.

Dicas JMeter: ‘Once Only Controller’

eudescosta — Tue, 16 Sep 2008 16:51:25 +0000

Quando executamos um teste de performance, carga ou stress em alguma aplicação WEB usando JMeter, devemos ter bastante cuidado para que o script confeccionado para a realização do teste não afete os resultados, isso é um pensamento bastante óbvio que devemos ter em mente antes de executarmos um teste desta natureza.

É natural, que ao escrevermos o nosso primeiro script no JMeter, WebLoad, WAST, ou qualquer outra ferramenta, essa preocupação não esteja na lista de prioridades, pois estamos preocupados em ver o script funcionado…mas quando falamos em testar performance de aplicações, precisamos sim ter um cuidado muito especial com a performance do seu próprio script, por uma razão obvia: Seu script pode estar ‘retardando’ ainda mais a aplicação.

É importante entendermos que seu script deverá conter uma rotina lógica, sensata e real.

Quando planejamos testar a vazão/throughput de uma tela de cadastro, por exemplo, não faz sentido termos requisições que logam no sistema sendo executadas a cada thread, isso é um exemplo claro, de que o seu script irá afetar SIM o resultado do seu teste! tornando-o NÃO CONFIÁVEL.

Pois bem, a dica aqui é bem simples, no JMeter existe um ‘Logic Controller’ chamado ‘Once Only Controller’, como próprio nome sugere, ‘Controlador Apenas Uma Vez’.

Incluindo uma thread nesse controller, fará com que sua requisição seja executada apenas no início do seu script, ele deverá ficar desta forma:

Observe que tenho 3 requisições dentro do meu ‘Once Only Controller’ isso fará com que eles sejam executados apenas no início do script, como mostra umagem abaixo.

È isso, devemos ter alguns cuidados com o nosso script, pois ele pode afetar o resultado dos testes, e práticas bastante simples como esta acima mencionada, nos evita alguns problemas.

Definindo Requisito-Não Funcional de Performance

eudescosta — Thu, 28 Aug 2008 12:18:39 +0000

A definição do requisito não funcional de performance é uma atividade muito particular de cada projeto de desenvolvimento, assim sendo, as preocupações variam muito de projeto em projeto. No entanto, algumas preocupações podem ser muito similares dependendo da natureza, tipo e plataforma em que a aplicação é desenvolvida.

Irei postar aqui uma lista com algumas preguntas que podem ajudar muito aqueles que necerssitam definir este requisito não-funcional, as perguntas a seguir não são “leis” e sim um guia inicial para a definição deste requisito, este questionário deverá mudar bastante contendo informações específicas do seu projeto.

Com isto em mente vamos ao questionário:

1.    Qual a quantidade de requisições simultâneas nos horários de pico?
2.    Qual a quantidade de requisições por segundo será demandada aos nossos serviços?
3.   Qual o tempo de resposta médio esperado?
4.    Quantos usuários logado no sistema a aplicação deverá suportar?
5.    Qual a importância dos testes de performance no escopo do projeto?
6.    Quais os cenários mais críticos envolvendo performance dentro da aplicação?
7.    Qual o volume médio de transações diárias? e qual o pico de demanda?
8.    Qual a taxa de crescimento de usuários prevista?
9.    Qual o tamanho médio em bytes destas transações?
10.    Qual a velocidade dos links que proverão acesso a aplicação?
11.   Quais as preocupações relacionadas a performance já existem?
12.    Qual a taxa de crescimento (estimativa) da base de dados.
13.    Existe necessidade de execução em cluster (aplicação rodando em varias instâncias).
14    Qual a configuração utilizada no servidor que hospedará a aplicação?
14.1    Quais fabricantes?
14.2    Quantos processadores têm cada servidor? caso haja mais de um.
14.3    Quando de memória RAM?
14.4    Qual o cache utilizado?
14.5    Como é implementada a segurança dos servidores?
14.6    Existe algum cluster instalado?
15.    Existe alguma solução para balanceamento de carga adotada?
Se sim:
15.1    Qual plataforma?
15.2    Qual arquitetura?
15.3    Qual o mecanismo de controle de seção?
15.4    O balanceamento é feito por hardware ou software?

Qualquer dúvida é só comentar!

comentários

sexta-feira, setembro 12, 2008, Elias Nogueira comentou: Eudes, Parabens! Muito bom esse questionário!!! Aproveitando, posso atualizar o documento de Questionário de Teste de Performance com estes teus pontos também? Abraço!

sexta-feira, setembro 12, 2008, eudescosta comentou: Opa Elias, Pode sim cara, fica a vontade! Abraço.

Automação de Testes, uma tendência

eudescosta — Fri, 15 Aug 2008 23:51:38 +0000

A Computer World dedicou um post para falar das 6 areas de TI que são a prova de recessão aqui, esta informação é baseada em uma pesquisa realizada pela jobfox.

O resultado da pesquisa pode ser acessada aqui e Teste de Software/Qualidade está na lista das 6 áreas da computação que podem ser consideradas a prova de recessão, as outras áreas que constam nesta lista são:

1) Software design/development (No. 4)
2) Networking/systems administration (No. 10)
3) Database administration (No. 18)
4) Software implementation analyst (No. 19)

Na área de Teste de Software, o documento faz uma ressalva para a área de testes “Especially good for those with automated testing expertise.” ou seja, especialmente bom para aqueles com conhecimento em automação de testes…não é de agora que ouvimos falar disso.

A crescente necessidade por qualidade em projetos de desenvolvimento de software, faz com que técnicas de prevenção de defeitos se tornarem cada dia mais importante e valorizadas no mercado.

A pesquisa foi realizada em Julho/2008.

comentários

sexta-feira, agosto 15, 2008, Eudes via Rec6 comentou: Automação de Testes, uma tendência | ...zezologs... Pesquisa realizada pela jobfox aponta teste de software com foco em automação, como uma das 6 áreas de TI a prova de recessões ...

14 Regras Básicas Para Aplicações WEB

eudescosta — Thu, 14 Aug 2008 23:57:04 +0000

Recebi uma indicação de Saulo Dourado, designer gráfico do CESAR, de um livro chamado “High Performance Web Sites” que contém uma lista de 14 “regras” para o desenvolvimento de frontends eficientes, estas mesmas 14 regras são usadas no YSlow, que abordei em “Dicas: Firebug e YSlow“.

O autor do livro e do YSlow é Steve Sounders um guru na arte e ciência de performance em aplicações WEB.

As 14 regras são:

Regra 1: Minimize HTTP Requests

Problema) 80-90% do tempo navegando em uma página WEB é gasto em requisições HTTP, requisições estas que envolvem Imagens, Scripts, CSS, Flash que são referenciados no HTML.

Solução 01) Use Image Maps

Imagem Maps é uma técnica que mapeia uma imagem, ao invés de carragar cada imagem individualmente como fazemos de costume, criamos uma imagem unica e mapeamos cada parte da imagem via javascript.

Exemplos: http://stevesouders.com/examples/imagemap.php, http://en.wikipedia.org/wiki/Image_map

Solução 02) Similar ao Image Maps só que com CSS

Exemplo: http://css-tricks.com/css-sprites-what-they-are-why-theyre-cool-and-how-to-use-them/

Regra 2: Use CDN´s (Content Delivery Network)

Assim como descrito na 1º Regra “80-90% do tempo navegando em uma página WEB é gasto em requisições HTTP.”

CDN´s são servidores que hospedam conteúdo estático em servidores separados da sua aplicação, ou em caso de portais de grande porte, este conteúdo não somente é de conteúdo estático, como tambem de todo o conteúdo do site, que seria distribuído baseado na região de onde a requisições foi feita.

Regra 3: Use “Expires Header“

Problema) Browsers usam cache para reduzir a quantidade de HTTP requests.

Solução) “Expires Headers” fala por quanto tempo um componente deve ser armazenado em cache.

Regra 4: Utilize Gzip

Problema) Excesso de HTTP Requests, causado pelos componetes de uma aplicação (imagens, css, etc)

Solução) Comprima seus arquivos usando gzip. A maioria dos browsers disponíveis no mercado suportam compressão de aquivos via o ‘Accept-Encoding’.

Gzip é o mais popular e eficiente método de compressão atualmente.

Exemplos) http://www.weberdev.com/get_example-3993.html

Regra 5: Mova CSS para o topo

Problema) CSS no final provoca demora no carregamento da página.

Solução) Esta prática, acredito que todos fazem a contento, pelo menos desde que comecei a trabalhar com WEB costumo por os CSS no topo, mas para aqueles que o inserem no final da página, vai ai o alerta, isso afeta o carregamento de suas páginas, a explicação é bastante óbvia, quando o browser recebe uma solicitação, ele procura primeiro quais elementos gráficos carregar para depois carregar o conteúdo da página, tornando o CSS no final um equívoco.

Regra 6: Mova scripts para baixo

Ao contrário do CSS, os scripts em sua maioria devem ser movidos para o final da pagina, deixando os scripts no podem afetar o carregamento gradual da página, movendo os scripts para final, permite a paralelização do download do conteúdo do site.

Regra 7: Evite expressões em CSS

Muitos utilizam expressões em CSS para definir um background-color que mudem dinamicamente, a cada hora, isso é um exemplo de uso desnecessário de expressões em CSS, neste caso, isto poderia estar em um script em javascript, php, C#, etc… .

Regra 8: ‘Inlined’ JavaScript e CSS

Não consegui uma tradução para esta regra, mas irei explicar do que se trata.

‘Inline’ Javasctipt e CSS diz respeito a incluir os CSS e o Javascript inteiro na página ao invés de deixa-los em arquivos externos, como fazemos de costume.

Regra 9: Minimize Domínios

Algumas aplicações precisam fazer verificações de DNS, tente reduzir isso ao máximo.

Regra 10: Minimize JavaScript

Trata-se de uma boa prática em relação a confecção de CSS. Esta boa prática diz respeito a nomenclatura usada nos elementos.

Reduzir ao máximo o nome dos elementos, ou seja, fazer um refactoring no CSS.

Regra 11: Evite Redirecionamentos

Redirecimentos são usados para rotear uma URL para outra URL, está prática, por motivos claros reduzem o tempo de carregamento das páginas.

Regra 12: Remova Scritps Duplicados

Da mesma forma que temos que fazer refactoring periódicos, no código de nossas aplicações, devemos fazer refactoring tambem no código do nosso front-end.

Muitas vezes esquecemos que o front-end tambem tem código

Regra 13: Desabilite ETags

ETags é um mecanismo que webservers e browsers usam para determinar se o componente do cache do browser combina com com o que está no servidor.

O problema com ETags é qu eles são tipicamente construidos usando atributos que os tornam únicos para o servidor que hospeda o site, logo eles nunca vão combinar com o cache do browser.

Regra 14: Cache AJAX

Como a própria regra fala, permita que o AJAX utilize o cache so seu browser

Todos os exemplos acima estão muito bem organizados aqui, o autor destas regras é o Steve Sounders, eu apenas traduzi para o português algumas partes importantes das 14 regras.

Estas regras, não se aplicam em todos os casos, mas é importante termos a consciência de que elas existem e que a não adoção de muitas destas regras, implicará em redução da performance de sua aplicação.

comentários

sexta-feira, agosto 15, 2008, Eudes via Rec6 comentou: 14 Regras Básicas Para Aplicações WEB | ...zezologs... Lista de 14 regras a serem utilizadas em projetos de desenvolvimento de aplicações WEB. ...

domingo, agosto 17, 2008, eudescosta no diHITT comentou: 14 Regras Básicas Para Aplicações WEB ... Lista de 14 regras definidas por Steve Sounders, a serem utilizadas em projetos de desenvolvimento de aplicações WEB visando a melhoria da performance do produto final. ...

domingo, agosto 17, 2008, www.digga.com.br comentou: 14 Regras Básicas Para Aplicações WEB... Recebi uma indicação de Saulo Dourado, designer gráfico do CESAR, de um livro chamado “High Performance Web Sites” que contém uma lista de 14 “regras” para o desenvolvimento de frontends eficientes, estas mesmas 14 regras são usadas no YSl...

quarta-feira, agosto 20, 2008, Silvio Blauth comentou: ≈up≈

terça-feira, outubro 28, 2008, Claudio comentou: ≈up≈ Valeu!! Muito bom!

Template de Relatório de Testes do VS

eudescosta — Mon, 11 Aug 2008 14:48:40 +0000

Recebi emails de alguns leitores, pedindo para que disponibilizasse o template que utilizo para gerar os relatórios apartir do .trx como explicado neste post.

Bem, estou disponibilizando o template em excel para quem tiver interesse, para aqueles que chegaram aqui de paraquedas, este template deve ser utilizado por quem executa testes no Visual Studio e precisa enviar relatórios diários/semanais/mensais/anuais… para os interessados nos resultados dos testes.

O template é bastante simples e foi confeccionado no próprio excel, usando o código do mapa XML do .trx gerado após a execução dos testes no Visual Studio (o .trx geralmente fica na pasta ‘Test Results’).

Para utilizá-lo basta importar o .trx via Dados > XML > Importar e pronto.

A imagem acima ilustra como ficará os resultados após esta importação, depois basta inserir isto em um email e enviar para aqueles interessados no resultado.

É isso, espero que este .xls ajude aqueles que tinham um grande trabalho para gerar um relatório apresentável destes .trx.

O template pode ser baixado aqui.

Dicas: Firebug e YSlow

eudescosta — Mon, 28 Jul 2008 00:50:22 +0000

Pra quem testa aplicações WEB, e deseja uma ferramenta bem prática para realizar alguns testes de performance (tempo-resposta), uma boa dica é o firebug e o YSlow.

Firebug é uma ferramenta que uso a bastante tempo, e acho uma das ferramentas indispensáveis para quem trabalha com aplicações WEB independente da plataforma de desenvolvimento, pois para o firebug, o que importa é o front-end, ele atualmente é uma extensão do Firefox, no entanto existe uma forma de utilizá-lo no IE, Opera e Safari seguindo os seguintes estes procedimentos.

Já o YSlow é uma ferramenta que se incorpora ao firebug, e é exclusivo para testes de tempo-resposta de aplicações WEB, no Firefox, depois de instalado, eles ficam no rodapé direito de seu browser…o inseto é o firebug, e o cronômetro o YSlow, como na imagem abaixo.

Clicando nesse inseto (firebug), uma série de funcionalidades lhe é disponibilizada, não vou aborda todas aqui pois não é o caso, afinal a ferramenta é bem intuitiva e sua usabilidade é ótima.

A dica que quero deixar aqui, é a aba ‘Rede’, nesta aba o firebug realiza uma medição do tempo-resposta das imagens/java-script/css que compõem sua aplicação, e exibe-os como imagem abaixo.

Isto é muito bom para identificar gargalos, que foram introduzidos na aplicação, por engano ou até mesmo propositalmente, mas que acabaram esquecidos.

Certa vez, no deploy de uma aplicação, encontrei 5 CSS´s (Cascading Style Sheets) na aplicação, sem contar os inúmeros scripts do jquery, que poderiam ser otimizados e alguns deles retirados.

Já o YSlow é ainda mais legal no ponto de vista dos testes de performance, ele segue uma série de regras com o parâmetros para analisar os resultados de dos testes, veja imagem abaixo.

A análise acima é daqui do zezologs.org, já ouviram o ditado que diz “casa de ferreiro, espeto de pau” pois é segundo o YSlow recebi nota “D”, isso não é bem uma novidade, pois já havia identificado isso a um certo tempo, apenas não tive muito tempo para resolver, até porque com o todo site que utiliza o wordpress, precisa de plugins, e resolver este problema é bem mais trabalhoso que imaginamos, pois teria que ir de plugin em plugin melhorando o código, e isso, é fora de cogitação…seria bom que todos que aqueles que escrevem plugins para o Wordpresse seguissem a risca o que Mark fala neste post “How to write a solid and stable WordPress plugin“, mas enfim, prosseguindo…

Na próxima tela ele faz um comparativo com o cache vazio e cheio

E na última, lista os componentes que compões sua aplicação.

E isso ai, fica ai a dica ;).

comentários

sexta-feira, agosto 15, 2008, 13 Regras Básicas Para Aplicações WEB | ...zezologs comentou: [...] de frontend eficientes, estas mesmas 14 regras são usadas no YSlow, que abordei em “Dicas: Firebug e YSlow“. O autor do livro e do YSlow é Steve Sounders um guru na arte e ciência de performance em [...]

zezologs

Testes Instáveis do Selenium

comentários

leia mais...

Uma nuvem…do que foi falado aqui

leia mais...

Estimando Esforço de Automação

leia mais...

Apresentação de Introdução a Automação

comentários

leia mais...

Top 10 vulnerabilidades em aplicações web

leia mais...

Questionamentos sobre o Testlink (#1)

comentários

leia mais...

Bugs do Homem

comentários

leia mais...

Feliz Ano Novo!

leia mais...

Testlink: Exportação de Casos de Teste

comentários

leia mais...

Automação e Códigos Não Testáveis

comentários

leia mais...

Dilbert e seu Tester, o Bob Bastard

comentários

leia mais...

Engenharia de Testes, Caso: Google, Zurich

comentários

leia mais...

Mudança de Layout e Algumas Explicações

leia mais...

Dica: MSTest (/noisolation e arquivos de configuração)

leia mais...

Dicas JMeter: ‘Once Only Controller’

leia mais...

Definindo Requisito-Não Funcional de Performance

comentários

leia mais...

Automação de Testes, uma tendência

comentários

leia mais...

14 Regras Básicas Para Aplicações WEB

comentários

leia mais...

Template de Relatório de Testes do VS

leia mais...

Dicas: Firebug e YSlow

comentários

leia mais...