Modelo básico de um plano de testes de performance - Parte 2
Autor: Cadu Rossi | Publicado: 2016-06-10T08:11:00-07:00


Nesse post irei descrever alguns detalhes do modelo de plano de testes de performance básico que utilizo na maioria dos projetos.
Apresento abaixo alguns comentários em cada um dos itens do plano de teste de performance:

1- Descrição do Sistema sob teste
&nbsp; &nbsp; &nbsp; &nbsp; (Apenas um parágrafo com a descrição resumida dos SUT - System Under Test, para que todos envolvidos nas atividades de teste estejam alinhados sobre as características do sistema.)

 1.1 Volumetria estimada
  (Quantidade de usuários ou requisições simultâneas. No caso de um sistema novo, esses valores serão estimativas. Se o sistema já existir, podemos utilizar dados de monitoração, marketing, pesquisas, ou quaisquer dados que possam indicar a volumetria.)
    
 1.2 Necessidade dos testes
  (Esse item se refere a necessidade de negócios, devemos descrever o que motivou os testes. Por exemplo, podemos dizer que os testes são necessários devido a uma campanha de marketing que irá atrair uma grande quantidade de usuários acessando um website.)
  
2- Critérios de Aceite
  (Os critérios de aceite variam conforme as características do sistema, porém de maneira geral temos: quantidade de usuários ou requisições simultâneas que o sistema deve suportar, tempo de resposta máximo desejável e consumo máximo de recursos da infraestrutura.)


3- Declaração do Escopo dos Testes
 3.1 Objetivo dos testes
  (Os objetivos de um teste de performance podem variar bastante, porém alguns exemplos são: verificar o comportamento da infraestrutura e tempos de resposta com uma determinada carga de usuários, encontrar possíveis gargalos, identificar pontos de melhoria de performance, descobrir a quantidade de usuários que o sistema e infraestrutura suportam, etc...)
 
 3.2 Estratégia dos testes
  (Nesse item costumo descrever qual ferramenta de testes será usada, qual ambiente será submetido aos testes, como os scripts serão configurados, etc. Esse item é importante para que as equipes entendam como os testes serão abordados pelos analistas de teste.)

 3.3 Cenários de teste
  (Acredito que seja importante incluir tabelas com as funcionalidades e distribuição de carga para cada cenário de teste, também URLs, perfis de usuário e outras informações relevantes.)
 
 3.4 Baterias de teste
  (Descrever quantas baterias de teste foram planejadas, com suas respectivas cargas, duração, e demais informações.)
 
 3.5 Data e horário da execução dos testes
  (Descrição da data e horário da execução dos testes.)
 
4- Topologia e Infraestrutura
 4.1 Lista dos servidores envolvidos nos testes
  (Criar uma lista com as informações relevantes de cada servidor envolvido nos testes, como: Nome do servidor, Sistema Operacional, Tipo de Servidor (web, application, banco de dados, etc..), e também a configuração de hardware se possível.)

 4.2 Topologia do ambiente sob teste
  (Muito importante incluir um desenho da topologia da infraestrutura do ambiente sob teste.)
 
 4.3 Instrumentação necessária para monitoração
  (Esse item tem grande importância, e é onde a maioria dos analistas de teste se perdem, pois estão preocupados em definir os cenários de teste e desenvolver os scripts, e se esquecem da monitoração da infraestrutura. Na minha opinião devemos ter uma lista com os contadores de performance de cada sistema operacional, banco de dados e aplicação, e também especificar quais logs devem ser coletados. Exemplo: Em um servidor Windows, coletar via PERFMON o %Processor Time e os logs da aplicação no diretório C:\app\xyz.)

5- Entregas, Premissas e Restrições
 5.1 Entregas
  (Lista dos entregáveis, como o próprio plano de testes, relatórios técnicos, apresentações, etc.)
 
 5.2 Premissas e Restrições
  (Esse item talvez seja o maior de todos. Particularmente, gosto de criar uma lista com todos os pontos que podem gerar impactos ou riscos nas atividades de teste, como: quem são os responsáveis por aprovar formalmente a execução dos testes, quem deve disponibilizar informações como massa de teste e usuários para login, descrever que o sistema sob teste deverá estar funcionando durante o período de desenvolvimento dos scripts e execução, descrever quais pessoas/equipes devem acompanhar a execução dos testes, etc. Enfim, detalhar qualquer particularidade para que todas atividades ocorram sem causar nenhum impacto para o cliente e para a equipe de teste de performance.)  
  
6- Cronograma
  (Sempre costumo incluir uma tabela com as datas estimadas para cada atividade relacionada ao teste de performance.)
  
7- Contatos
  (Uma lista com a relação de todas pessoas envolvidas nos testes, como: gerente de projeto, analistas de teste e responsáveis pela infraestrutura. Uma boa prática é incluir também e-mail e telefone de todos envolvidos, para facilitar a comunicação.)
  
  
  
Com esse modelo já é possível planejar as atividades que fazem parte de um teste de performance. Novamente, esse é apenas um modelo básico.
Cada projeto de testes de performance tem suas particularidades e devem ser analisadas com critério.