testes não funcionais: performance e alta disponibilidade ... · the software economics company...

Testes Não Funcionais: Performance e

Alta Disponibilidade no Mercado de

Capitais

The Software Economics Company


Agenda

• Institucional

• Riscos e Garantia da Qualidade (QA)

• Classificação de requisitos e testes não funcionais

• Serviços de QA aplicados

• Computação e Estatística aplicadas

• Tipos de análises realizadas

• Feedback de clientes

• Exemplos de casos de teste não funcionais


Sobre a PrimeUp

• Fundada em 2004 no Rio de Janeiro, incubada na PUC-Rio com sua origem no LES (Laboratório de Engenharia de Software).

• Quando de profissionais (Dsc e Msc) com mais de 20 anos de experiência em TI e Gerência de Projetos.

• Mais de 60 profissionais

• IBM Premier Business Partner (mais de 35 certificações IBM Rational)

• Forte experiência em ferramentas, definição de processo e implantação: PPM, ALM, Garantia da Qualidade/Performance, Capacidade e Governança em TI.

• Escritórios no Rio, São Paulo e em breve Belo Horizonte


Área de Negócio PLAN

Garantir o alinhamento estratégicos entre as prioridades

do negócio e os investimentos planejados através da

medição, análise e avaliação objetiva dos cenários de

investimento com uma visão centralizada de recursos,

orçamento e riscos. Permite manter os projetos adaptados

às mudanças no negócios e nas necessidades dos cliente

mantendo o melhor portfólio possível a cada momento e

maximizando o uso dos recursos da organização.


Área de Negócio BUILD

Gerenciamento de Ciclo de Vida de Aplicativos (ALM) é o

casamento entre gerência de negócio com engenharia de

software, com ferramentas que facilitam e integram

processos como análise de requisitos, modelagem de

arquitetura, desenvolvimento de código, gerenciamento

de mudanças, gerenciamento de testes e gerenciamento

de versões de produtos realizados. O objetivo é tomar a

melhor decisão entre desenvolver, adquirir ou modernizar

as aplicações e acompanhar a execução do projeto até a

realização dos benefícios planejados.


Área de Negócio RUN

Dentre os objetivos dessa prática, destacam-se a

manutenção de um ambiente ótimo para a performance

das aplicações, minimização de incidentes em produção e

contenção de custos. Engloba otimização da infraestrutura

física, tempo de resposta e capacidade dos serviços de TI

e do middleware e das aplicações. Utiliza testes

funcionais, testes de carga e stress, modelos

computacionais, tecnologias de monitoração e modelos

estatísticos para a identificação de gargalos, riscos

operacionais, oportunidades de melhoria e promoção

segura de aplicações para a produção.


Clientes

BANK INSURANCE MEDIA ENERGY SI & ISV PUBLIC

CSP RETAIL FSS LOGISTIC DEFENSE


Parcerias


7.5%

23.6%

62.5%

FX contracts Index-based contracts Mini contracts

0 1 3 7 12 15 13 17 20 25

84

164 162 151 156 162

203

Jun-09 Jul-09 Aug-09 Sep-09 Oct-09 Nov-09 Dec-09 Jan-10 Feb-10 Mar-10 Apr-10 May-10 Jun-10 Jul-10 Aug-10 Sep-10 Oct-10

3.2%

1.4%

3.3% 3.2% 2.6%4.1%

4.8%

21 participantes ativos em Set de 2010

* Fonte: BVMF Investor Relations

HFT (participação por grupo de contratos)

Segmento BM&F (milhares de contratos)

9

Contexto e Motivação

Crescimento do mercado de High Frequency Trading (HFT) no mercado de derivativos


Garantia da Qualidade?

• Mais que testes, uma área de (QA) deve pensar na minimização de Riscos Operacionais de TI

RESOLUCAO BCB N. 003380, DE 29 DE JUNHO DE 2006

=

IMOBILIZAÇÃO DE CAPITAL

• RISCO: a probabilidade de uma ameaça explorar uma vulnerabilidade de um determinado ativo, provocando impactos nos negócios da organização.

• INTERESSE: Diminução de risco operacional possibilita diminuir o volume de capital imobilizado


Riscos operacionais

17/01/2012 UOL ECONOMIA: “Problemas técnicos atrasam início de pregão na Bovespa”

‘


Como mitigar?

• Além de executar os testes, QA deve :

Analisar requisitos não funcionais

Sugerir recomendações para produção

Propor alterações na especificação do sistema

Fornecer guidelines para área de desenvolvimento


Classificação de teste não funcional


Classificação de testes não funcionais

Desempenho •Teste de Desempenho

•Benchmarking

Capacidade •Teste de Capacidade/Stress

•Escalabilidade

Confiabilidade

•Tolerância a falhas

•Alta Disponibilidade (HA)

•Teste de recuperação de desastre (DR)

•Estabilidade


Tipo de requisitos não funcionais

• Qual o tempo de resposta? Desempenho

• Sistema/componente se recupera em caso de falha? (TaF)

• Sistema/componente possui Alta Disponibilidade? (HA)

• Qual o tempo de recuperação de desastre? (DR)

• Quantidade (ou tempo) de mensagens perdidas em caso de desastre? (DR)

• O sistema é escalável? (Escalabilidade)

• Quantos usuários simultâneos o sistema suporta? (Capacidade/Stress)

• O sistema de trading permanece estável durante o pregão? (8 horas)? (Estabilidade)

• Quantos usuários simultâneos com RTT 2 segundos o sistema suporta?

• Quantos úsuários simultânoes o sistema suporta, com RTT 2 segundos e utilização máxima de 45% de CPU ?


Atividades desenvolvidas

• Manutenção evolutiva de aplicações em laboratório

• Gestão de riscos não funcionais associada à gestão de mudanças em ambiente

produtivo

• Troubleshooting/Análise de erros não funcionais em produção (PSG)

• Capacity planning/sizing

• Recomendação de hardware por perfil de utilização


Capacity planning

• Caiu da moda, pois “hardware ficou muito barato”?

Voltou a tona agora com “TI nas nuvens”

“TI verde” precisa poupar energia

• Capacity planning/sizing

Com testes

Com dados de produção

Com simulação

Com entrevistas/PoC


• Média, média ponderada, Desvio Padrão, regressão, correlação, histograma, curva normal: uso no dia a dia

• Teoria de filas, lei de Amdahl

• Conceitos avançados de sistema operacional

• Conceitos de arquitetura de sistemas, estrutura de dados, redes TCP/UDP over IP

Computação e Estatística Aplicada


Análise de Capacidade e Performance

Response Time vs Throughput

0.000

1.000

2.000

3.000

4.000

5.000

6.000

7.000

8.000

9.000

10.000

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31

Throughput

Res

pons

e Ti

me

Queue Time

Service Time

Response Time

A BASE PARA A ANÁLISE: TAXA DE CHEGADA VS TEMPO DE RESPOSTA

SLA / QOS



Análise de Vazão (throughput)



Tempo de Serviço

Response Time vs Throughput

0.000

1.000

2.000

3.000

4.000

5.000

6.000

7.000

8.000

9.000

10.000

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31

Throughput

Res

pons

e Ti

me

Queue Time

Service Time

Response Time

Servidor

λ

• LEI DE AMDAHL - Batch

OLTP

BATCH

• MODELOS DE FILAS - Online Throughput ou Lambda

Utilização CPU

Metodologia


sar 300 1 > file & iostat –xdk 300 2 > file & Ou perfmon.

Ordens/s Web pages/s

KBytes/s User calls/s (Banco de dados)

Transações (taxa de chegada)

CPU (ou I/O) (hardware + setup)

Tempo de Serviço (capacidade)

(lambda / #CPUs) = % utilização / service_time

calculado

Medida de Capacidade


MODELO M/M/N – LATÊNCIA EM FUNÇÃO DE TRANSAÇÕES

Capacity Planning Sinacor


Malha Batch – Fechamento

BOL_Fechamento = 1315 + 0,0130 * Movimentos Atualizados + 162,3 ERRO = +/- 6%

Capacity Planning Sinacor


Feedback dos clientes - I

O resultado ficou excelente! Ficou bastante claro o breakdown das causas raiz e das limitações, e matematicamente o modelo está bastante correto. Por favor, transmita meus parabéns para a equipe.

Baseado nessas informações, conseguiremos oferecer o insumo à área de negócios das reais limitações, e dar um guia para clientes que necessitarem calibrar seus algos para manter o desvio padrão otimizado. Ficamos pendentes somente a recomendação de TPS/sessão FIX.

Muito obrigado pelo empenho, e mais uma vez, parabéns.


Feedback dos clientes - II

Pessoal,

Ontem tivemos uma apresentação do nosso diretor executivo Ciclano Beltrano falando sobre as metas, realizações e sobre alguns pontos que estão por vir.

Fiquei muito feliz com alguns pontos abordado pelo Beltrano, onde ela ressalta a importância da área de QA para a empresa, inclusive o primeiro item foi um dado que QA forneceu. Por este motivo estou repassando este e-mail pra vocês para saberem que QA esta em evidência e a importância da nossa área para toda empresa.


Teste = Verificação de Risco

• Cada teste está relacionado a um único objetivo.

• Um teste pode ter um ou mais cenários de teste.

• Exemplo: “Objetivo: Comparar desempenho das versões 6.1 e 6.2” (Benchmarking).


Cenário de teste

• Em geral, está relacionado com as configurações do teste e/ou de ambiente. Um cenário pode ter um ou mais casos de testes.

• Exemplo:

Cenário 1: log em modo assíncrono

Cenário 2: log em modo síncrono


• Engloba as configurações completas de um cenário.

• Exemplo:

• 1000 usuários conectados com 10 listeners



Caso de teste


• Descreve o método utilizado. Exemplo:

“O teste é iniciado com carga mínima constante de 100 mensagens por

segundo, e a cada 60 segundos de execução a carga é dobrada. A duração de

cada bateria de execução será de 5 minutos, e entre cada bateria, o sistema

será reinicializado e realizada limpeza no banco de dados. A carga utilizará

proporção de negócios por oferta registrada será de 1 para 10, equivalente à

proporção média (por instrumento) verificada em ambiente de produção.”

Metodologia de teste


Critério de sucesso/aceite

• O critério de aceite definido é um conjunto de requisitos foi atingido ou não (passed or failed).

• Exemplos:

“Requisito: Tempo de resposta médio + desvio-padrão menor ou igual a 17 milissegundos e CPU Utilizada < 45%.

Resultado Obtido: média + desvio = 15,42 ms – CPU Utilizada = 32%

PASSED”

Perguntas?


[email protected]

testes não funcionais: performance e alta disponibilidade ... · the software economics company...

Documents