SIPTEST System Intelligent Process Testing.

(1)

SIPTEST – System Intelligent Process Testing.

Sistema de incentivos à investigação e desenvolvimento tecnológico (SI I&DT)

Relatório técnico-científico final do projeto nº 22952 (Janeiro de 2012 – Dezembro de 2013) Elaborado por: Link Consulting

(2)

System Intelligent Process Testing| Link Consulting,SA | Pág. 1 de 62

Índice

1 A Equipa de Projeto ... 4

1.1 Principais competências e atividades desenvolvidas ... 4

1.2 Impacto do seu envolvimento no projeto ... 8

1.3 Alterações estruturais na equipa ... 9

1.4 Novas contratações ... 9

1.5 Criação de departamento de I&D ... 9

2 O Projeto ... 10

2.1 Os objetivos e a estrutura ... 10

2.2 Calendarização das atividades do projeto ... 12

2.3 Identificação e justificação das principais alterações ao quadro dos investimentos previstos do projeto . 12 2.4 Identificar a carga horária despendida por cada técnico e por atividade ao longo do projeto ... 13

2.5 Identificar os custos indiretos e respetivo método de imputação, bem como o cálculo da percentagem dos custos indiretos – pedir relatórios ao IDT ... 14

3 Trabalho Desenvolvido ... 15

3.1 Atividades e tarefas desenvolvidas ... 15

3.1.1 A – Estudos preliminares... 15

3.1.2 B – Especificações técnicas ... 23

3.1.3 C – Aquisição e desenvolvimento de novos conhecimentos ... 40

3.1.4 D – Desenvolvimento ... 45

3.1.5 E – Construções de protótipos para testes e documentação da solução implementada ... 45

3.1.6 F – Testes e Ensaios ... 46

3.1.7 G – Promoção e divulgação de resultados ... 46

3.2 Milestones ... 46

3.3 Resultados alcançados ... 48

3.3.1 Eliminar limitações à execução de testes funcionais ... 48

3.3.2 Gestão eficaz de defeitos ... 49

3.3.3 Estender o QA à governação dos serviços ... 49

3.3.4 QA para além da entrada em produção ... 50

3.3.5 Envolver gestores de negócio nas iniciativas de QA ... 50

4 Resultados ... 51

(3)

4.2 Impacto do projeto para as entidades participantes ... 51

4.3 Principais/Potenciais clientes, Principais Concorrentes, Análise Comparativa ... 52

4.4 Quantificar o potencial valor de mercado dos resultados obtidos ... 52

5 Avaliação Ex-Post ... 53

6 Notas Finais ... 55

6.1 Participação em Conferências e Publicações ... 55

6.2 Sítio do projeto ... 57 6.3 Outros meios ... 58 6.3.1 Grafismo ... 58 6.3.2 Monofolhas de divulgação ... 58 6.3.3 Vídeo de divulgação ... 58 7 Referências ... 59 8 Anexos (opcionais) ... 60 9 Fecho do documento ... 61

Índice de Figuras

Figura 1 – Exemplo dos resultados na deteção de SQL Injection ... 18

Figura 2 – Interface do SoapUI ... 22

Figura 2 – Processo de criação e execução de testes de desempenho ... 27

Figura 4 – Níveis de maturidade TMMI e áreas de processo ... 29

Figura 5 – Integração das ferramentas do SIPTESTE ... 32

Figura 6 – Exemplo da estrutura do ficheiro XML consumido pelo EAMS ... 32

Figura 7 – Arquitetura SIPTEST ... 39

Figura 8 – Meta modelo da solução ... 41

Figura 9 – Modelo V ... 43

Figura 10 – Abstract conferência testes portugal ... 55

Figura 11 – Evento Testing Portugal ... 56

Figura 14 – Evento TOC ... 56

Figura 12 – Site projeto SIPTEST ... 57

(4)

Índice de Tabelas

Tabela 1 – Excerto da tabela de comparação de ferramenta de testes funcionais ... 17

Tabela 2 – Excerto da tabela de comparação de ferramenta de testes de segurança ... 18

Tabela 3 – Algumas das ferramentas de análise estática analisadas ... 19

Tabela 4 – Excerto da tabela de comparação de ferramenta de testes de carga e desempenho ... 20

Tabela 5 – Excerto da tabela de comparação de ferramenta de testes de capture/replay ... 21

(5)

1 A Equipa de Projeto

1.1 Principais competências e atividades desenvolvidas

A tabela seguinte apresenta de forma resumida a equipa de técnicos da Link, bem como dos recursos contratados à FEUP e à StongStep, que desempenharam actividades no projeto SIPTEST, sintetizando as principais tarefas que cada um dos perfis desempenhou no âmbito do projeto.

Perfil Nome Descrição das principais tarefas desempenhadas P1 – Especialista em Arquiteturas Empresariais Complexas Armando Vieira  A - Estudos Preliminares

o Estado da arte da evolução da prática de testes, tendo como referência o CMMI

 B – Especificações Técnicas

o Definição da arquitetura de integração das ferramentas selecionadas

 C – Aquisição e Desenvolvimento de Novos Conhecimentos e Capacidades para o Desenvolvimento

o Definição do Meta Modelo da Base de Conhecimento o Estado da Arte das técnicas de Arquitetura Empresarial para

suporte ao processo de testes  Desenvolvimento

o Instalação dos ambientes e ferramentas

o Desenvolvimento da Base de Conhecimento e Integração das Ferramentas de teste

o Desenvolvimento da ferramenta de gestão de testes

o Desenvolvimento do modelo final da ferramenta de gestão de testes P2 - Especialista em Ferramentas de Testes e de Gestão de Testes

Jorge Leandro  A - Estudos Preliminares

o Estudo comparativo de ferramentas de gestão de testes funcionais o Estudo comparativo de ferramentas de testes de segurança o Estudo comparativo de ferramentas de testes de carga e

desempenho

o Estudo comparativo de ferramentas de automação de testes  B – Especificações Técnicas

o Revisão e definição das metodologias e práticas melhoradas de testes de segurança

o Revisão e definição da metodologia de testes de carga e desempenho

o Revisão e definição da metodologia de automação de testes. o Revisão e definição da metodologia de testes funcionais o Definição da arquitetura de integração das ferramentas

(6)

System Intelligent Process Testing| Link Consulting,SA | Pág. 5 de 62 Perfil Nome Descrição das principais tarefas desempenhadas

o Definição de SLAs a aplicar na frente de testes funcionais o Definição de SLAs a aplicar na frente de testes de segurança o Definição de SLAs a aplicar na frente de testes de carga e

desempenho

o Definição de SLAs a aplicar na frente de automação de testes o Especificação de uma ferramenta de gestão de serviço integrada.  C – Aquisição e Desenvolvimento de Novos Conhecimentos e Capacidades

para o Desenvolvimento

o Comparação com as melhores práticas de gestão de testes o Estado da Arte das técnicas de Teste para Metodologias de

Desenvolvimento Específicas

o Estado da Arte das técnicas de Teste para Arquitecturas de SW específicas

 G – Promoção e Divulgação de Resultados

o Produção e publicação de documentos científicos

o Divulgação em fóruns Industriais e Científicos das lições aprendidas e resultados alcançados no SIPTEST

P3 - Especialista em Desenho e Tecnologia de Testes

José Marques  A - Estudos Preliminares

o Estudo comparativo de ferramentas de gestão de testes funcionais o Estudo comparativo de ferramentas de testes de segurança o Estudo comparativo de ferramentas de testes de carga e

desempenho

o Estudo comparativo de ferramentas de automação de testes o Estado da arte da evolução da prática de testes, tendo como

referência o CMMI  B – Especificações Técnicas

selecionadas

o Definição de SLAs a aplicar na frente de testes funcionais o Definição de SLAs a aplicar na frente de testes de segurança o Definição de SLAs a aplicar na frente de testes de carga e

desempenho

o Definição de SLAs a aplicar na frente de automação de testes o Especificação de uma ferramenta de gestão de serviço integrada.  C – Aquisição e Desenvolvimento de Novos Conhecimentos e Capacidades

para o Desenvolvimento

(7)

o Comparação com as melhores práticas de gestão de testes o Estado da Arte das técnicas de Arquitetura Empresarial para

suporte ao processo de testes

o Estado da Arte das técnicas de Teste para Metodologias de Desenvolvimento Específicas

o Estado da Arte das técnicas de Teste para Arquitecturas de SW específicas

 D – Desenvolvimento

o Desenvolvimento do modelo final da ferramenta de gestão de testes

 E – Construção de Protótipos

o Revisão da documentação e normalização dos processos definidos o Construção de Protótipos para Testes e Documentação da solução

implementada  F – Testes e Ensaios

o Testes Unitários e de Integração

o Set up da frente dos vários serviços de testes funcionais, segurança, carga, e automação de testes

o Produção e publicação de documentos científicos o Criação de um microsite da oferta

o Evento de fecho do projeto P4 – Especialistas em Engenharia de Software e Automação de Processos Diogo Henriques

o Definição do Meta Modelo da Base de Conhecimento  D – Desenvolvimento

o Construção de Protótipos para Testes e Documentação da solução implementada

 F – Testes e Ensaios

o Testes Unitários e de Integração Daniel Gonçalves Luis Gonçalves José Rodrigues

(8)

 G – Promoção e Divulgação de Resultados o Criação de um microsite da oferta o Evento de fecho do projeto P5 – Especialistas em Engenharia de Sistemas Nuno Camacho Silva  A - Estudos Preliminares

o Estado da arte da evolução da prática de testes, tendo como referência o CMMI

 B – Especificações Técnicas

selecionadas

o Comparação com as melhores práticas de gestão de testes o Estado da Arte das técnicas de Teste para Metodologias de

Desenvolvimento Específicas

o Estado da Arte das técnicas de Teste para Arquiteturas de SW específicas

 D – Desenvolvimento

o Desenvolvimento do modelo final da ferramenta de gestão de testes P6 – Especialista de Engenharia de Sistemas (novas contratações) Daniel Rodrigues  D – Desenvolvimento

o Construção de Protótipos para Testes e Documentação da solução implementada

 F – Testes e Ensaios

(9)

System Intelligent Process Testing| Link Consulting,SA | Pág. 8 de 62 Perfil Nome Descrição das principais tarefas desempenhadas P7 – Especialista em Automação de Testes para Softwares João Faria (FEUP)  A - Estudos Preliminares

o Estudo comparativo de ferramentas de gestão de testes funcionais o Estudo comparativo de ferramentas de testes de carga e

desempenho

o Estudo comparativo de ferramentas de automação de testes o Estado da arte da evolução da prática de testes, tendo como

referência o CMMI  B – Especificações Técnicas

o Revisão e definição das metodologias e boas práticas de teste o Revisão e definição da metodologia de testes funcionais

o Levantamento de referências sobre metodologias e boas práticas de testes funcionais, incluindo critérios de automação

o Revisão e definição da metodologia de testes funcionais o Definição de SLAs típicos aplicáveis a testes funcionais o Definição de SLAs aplicáveis a testes de segurança

o Levantamento de SLAs típicos aplicáveis a testes de carga e desempenho

o Definição de SLAs típicos aplicáveis a testes manuais e automáticos o Levantamento de referências sobre frameworks de gestão de

serviços de testes

o Produção e publicação de documentos científicos

o Evento de fecho do projeto Ana Paiva (FEUP) João Batista (FEUP) Tiago Marques (FEUP) José Cruz (FEUP) P8 - Especialistas em Enquadramento de Testes em boas práticas CMMI Pedro Henriques (StrongStep)

o Definição de SLAs a aplicar na frente de testes funcionais o Def. de SLAs a aplicar na frente de testes de segurança

o Def. de SLAs a aplicar na frente de testes de carga e desempenho o Def. de SLAs a aplicar na frente de automação de testes

o Revisão da documentação e normalização dos processos definidos o Set Up da frente dos vários serviços de testes funcionais,

segurança, carga e automação de testes Bruno

Martins (StrongStep)

1.2 Impacto do seu envolvimento no projeto

É de salientar a multiplicidade de competências desta equipa que se complementaram entre si para o atingimento dos objetivos do projeto.

Do ponto de vista específico da área de testes e qualidade, a equipa reúne os perfis com conhecimento técnico e funcional necessário. Desta forma foi possível enquadrar a solução desenvolvida no âmbito deste projeto na evolução dos serviços e soluções da área de SQA que se destina a responder a necessidades reais de grandes organizações que são o maior consumidor deste tipo de soluções e serviços.

(10)

Do ponto de vista técnico, os recursos que deram corpo aos perfis técnicos na área dos testes, arquiteturas SOA, arquitetura empresarial, são recursos com larga experiência no desenvolvimento de soluções em diferentes geografias e clientes reais enquadradas em diferentes contextos tecnológicos.

Do ponto de vista de conceção e desenho foram envolvidos recursos com larga experiência no desenvolvimento de soluções e sistemas de informação complexos, em ambientes próximos daquele que era pretendido neste projeto. É de salientar ainda a colaboração determinante estabelecida com os parceiros do meio científico e tecnológico – FEUP e StrongStep. Esta colaboração foi determinante para o sucesso do projeto, garantindo a segurança necessária para avançar para novas áreas algumas das quais transcendiam a experiência e conhecimento da equipa link. Para além da colaboração específica neste projeto e no contributo direto nos resultados do projeto esta colaboração contribuiu para a alimentação direta da equipa link com conhecimento técnico e cientifico inovador na área das metodologias de testes, automação de testes, e práticas CMMI, com capacidade de utilização na atividade de negócio da link que vai muito para além da oferta SQA.

Em sentido inverso, esta parceria com as SCT foi determinante para a instanciação do conhecimento genérico destas entidades numa solução específica e concreta de negócio. É prova disso a partição conjunta no maior certame nacional na área dos testes e qualidade, e o artigo admitido numa publicação científica da especialidade.

1.3 Alterações estruturais na equipa

No que respeita a alterações à equipa de projeto há apenas a registar a saída dos seguintes colaboradores: o Manuel Soares Morais, em Fevereiro de 2012,

o Daniel Gonçalves, em Julho de 2012.

1.4 Novas contratações

Foi efetuada uma nova contratação para participar no projeto SIPTEST, que não fazia parte do quadro de pessoal da empresa, com o seguinte perfil:

 Daniel Rodrigues: Especialista em Engenharia de Sistemas

O técnico Daniel Rodrigues continuará a integrar a equipa da oferta resultante do SIPTEST, dando suporte à solução desenvolvida e às novas funcionalidades que se pretende continuar a criar para a mesma.

1.5 Criação de departamento de I&D

A link Consulting possui um Departamento de I&D, que coordena todas as atividades de investigação industrial e desenvolvimento experimental da empresa, estando o seu SG IDI certificado segundo a NP4457:2007 desde 2010.

(11)

2 O Projeto

2.1 Os objetivos e a estrutura

O objetivo estruturante desta candidatura foi dotar a Link Consulting, mais concretamente a linha de oferta SQA, de uma solução de gestão de testes inovadora com o objetivo de oferecer aos seus clientes serviços integrados de testes funcionais e não funcionais (Ex: Carga e performance), reforçando ao mesmo tempo o seu potencial de internacionalização.

Tal objetivo implicou o desenvolvimento de uma solução que implementa um novo conceito de gestão e automação de testes, explorando três domínios de melhoria e inovação nas práticas de testes: Arquiteturas empresariais, arquiteturas SOA e processos de negócio.

De forma a atingir este objetivo genérico foi necessário percorrer várias etapas até a implementação da solução final.

A primeira dessas etapas consistiu na pesquisa e estudo comparativo de várias ferramentas de testes funcionais, não funcionais (segurança, carga e desempenho) e de automação. O objetivo destes estudos foi o de conhecer o estado da arte no que respeita às ferramentas de testes disponíveis no mercado, tendo em consideração, entre outros aspetos:

 A maturidade das ferramentas,

 A curva de aprendizagem das ferramentas

 Capacidades de integração das ferramentas com outras ferramentas e ambientes de desenvolvimento  Capacidades de análise gráfica do status de execução dos testes e dos defeitos detetados.

Desta pesquisa resultou a seleção do conjunto de ferramentas que viriam a ser integradas na solução SIPTEST. A etapa seguinte consistiu na análise de várias metodologias de testes funcionais, não funcionais e de automação de testes, bem como a sistematização de diversos níveis de serviço (SLAs). O objetivo desta etapa foi o de alinhar a solução a desenvolver com as melhores práticas e metodologias, tendo sempre em consideração as especificidades das arquiteturas SOA, assim como as recomendações do CMMI.

Por fim procedeu-se à definição da arquitetura de integração das ferramentas selecionadas, e ao desenvolvimento da solução. A solução concebida pela Link resultou da integração de diversos tipos de ferramentas frequentemente utilizadas, tanto na área do Quality Assurance (QA) como na área das arquiteturas SOA. Isoladamente, cada uma destas ferramentas apenas está vocacionada para garantir parte do processo de QA, ou apenas permite um acompanhamento parcial das iniciativas SOA de uma organização (sem abranger o QA).

Com a integração de vários tipos de ferramentas numa única plataforma, a Link procurou complementar as valências de cada uma delas de forma a contribuírem para um processo de QA unificado e consistente.

A plataforma integrada para testes em arquiteturas orientadas a serviços resultou da integração dos seguintes tipos de ferramentas:

 Ferramenta de gestão de testes (test management): Uma ferramenta de gestão de testes permite que testadores funcionais ou key users registem as suas baterias de testes funcionais, bem como os resultados da sua execução. Este tipo de ferramentas permite especificar, para cada teste que se pretenda executar

(12)

especificar, os seus passos, os respetivos resultados esperados e, após a execução, registar o respetivo resultado.

Trata-se portanto de um tipo de ferramenta essencial para os testadores funcionais e key users, onde é efetuado todo o planeamento das ações de QA e onde é registado a sua execução e progresso.

 Ferramenta de gestão de defeitos (bug tracking): Uma ferramenta de gestão de defeitos possibilita aos testadores reportar às equipas de desenvolvimento os defeitos detetados durante a execução dos testes. De forma genérica, este tipo de ferramentas permite gerir todo o ciclo de vida de um defeito, desde que é detetado (aberto) até à sua correção e validação (fecho), bem como classificar os defeitos reportados quanto à sua severidade e prioridade na correção. É portanto um tipo de ferramenta crucial em qualquer processo de QA, que agiliza a comunicação entre testadores e desenvolvimento no que respeita à deteção de defeitos e respetiva correção.

 Ferramenta de automação de testes funcionais a serviços (API functional testing): Uma ferramenta de automação de testes a serviços permite que testadores com um perfil técnico, ou mesmo membros das equipas de desenvolvimento, codifiquem e automatizem a execução de testes a serviços ou orquestrações de serviços. Este tipo de ferramentas requer tanto um conhecimento das API’s dos serviços testados como domínio da linguagem da ferramenta de automação utilizada. É pois um tipo de ferramenta vocacionada para perfis mais técnicos, onde os testes que são registados estão desprovidos de enquadramento funcional.

 Ferramenta de automação de testes de carga a serviços (API load testing): De forma similar ao tipo de ferramenta anterior, esta ferramenta permite a testadores com um perfil técnico codificar e automatizar a execução de testes de carga aos serviços. Tal como no caso anterior, este tipo de ferramenta está vocacionado para perfis mais técnicos, portanto menos focados nos aspetos funcionais e de negócio.  Ferramenta de governação SOA (SOA governance): Uma ferramenta de governação SOA possibilita aos

arquitetos SOA monitorizar de ponta a ponta o ciclo de vida das iniciativas de governação SOA. De forma genérica, um arquiteto poderá registar neste tipo de ferramenta todas as características relevantes de um serviço bem como as suas relações com outros serviços ou entidades da arquitetura (serviços dependentes, aplicações onde é utilizado, etc..).

De forma geral é omissa neste tipo de ferramentas informação relativa ao QA dos serviços (nº de casos de testes previstos, testes passados, testes falhados, defeitos abertos, etc…), devido a não existir uma forma expedita de atualizar este tipo de informação na ferramenta.

 Ferramenta de arquitetura empresarial (Enterprise Architecture): Uma ferramenta de arquitetura empresarial permite representar diversos domínios de uma organização como processos de negócio, sistemas de informação, serviços, orquestrações, infraestrutura, bem como as relações entre eles e a forma como estas evoluem ao longo do tempo, permitindo aos gestores de negócio fazer análises preditivas e tomar decisões. Tal como no caso anterior, também não é registado neste tipo de ferramentas informação sobre as iniciativas de QA em curso devido à inexistência de uma forma expedita de atualizar este tipo de informação.

Como mencionado anteriormente, se considerados de forma isolada, os tipos de ferramentas acima descritos não suportam um processo de QA de ponta a ponta, transversal aos diversos perfis comprometidos com a qualidade de

(13)

uma arquitetura SOA. Através da integração de todos estes tipos de ferramentas complementares numa única plataforma a link conseguiu garantir que a informação relevante sobre os processos de QA flui entre os vários tipos de ferramentas, promovendo assim a transparência e visibilidade para os vários tipos de perfis que as utilizam. Face aos resultados palpáveis obtidos com o projeto consideramos que todos os objetivos foram cabalmente atingidos e conseguimos com isto desenvolver e evoluir os processos e metodologias dos serviços fornecidos pela oferta SQA.

2.2 Calendarização das atividades do projeto

No essencial o calendário de execução das atividades do SIPTEST esteve sempre muito próximo do plano estabelecido inicialmente. Apenas foi necessário realizar reajustamentos ao plano de execução de algumas atividades, sem que tal tenha tido impacto no plano global do projeto.

Atividades Previsto Realizado

Início Fim Início Fim

A – Estudos Preliminares 02/01/2012 31/03/2012 02/01/2012 31/03/2012

B – Especificações Técnicas 01/04/2012 30/09/2012 02/04/2012 28/09/2012

C – Aquisição e Desenvolvimento de Novos

Conhecimentos 02/01/2012 01/07/2012 02/01/2012 28/12/2012

D – Desenvolvimento 01/08/2012 15/12/2013 03/09/2012 27/09/2013

E – Construção de Protótipos _01/04/2013 _{31/08/2013 02/01/2013 27/12/2013}

F – Testes e Ensaios _01/07/2013 _{15/11/2013 01/07/2013 27/12/2013}

G – Promoção e Divulgação de Resultados _01/10/2012 _{31/12/2013 01/10/2012 31/12/2013}

2.3 Identificação e justificação das principais alterações ao quadro dos investimentos previstos do

projeto

No que respeita aos investimentos previstos no SIPTEST não ocorreram alterações significativas, uma vez que todos foram realizados. Apenas há a mencionar o facto de nos serviços prestados pelo ROC se terem conseguido obter prestações de serviços por valores mais baixos que o previsto à data da candidatura.

(14)

2.4 Identificar a carga horária despendida por cada técnico e por atividade ao longo do projeto

A B C D E F G

Jan-Mar 2012 Abr-Set 2012 Jan-Dez 2012 Set-Dez 2012 Jan-Set 2013 Jan-Dez

2013 Jul-Dez 2013

Out-Dez

2012 Jan-Dez 2013

Previsto Realizado Previsto Realizado Previsto Realizado Previsto Realizado Previsto Realizado Previsto Realizado Previsto Realizad_o Previsto Realizado Previsto Realizado

P1 - Armando Vieira 113,7 5 114 469 452 406 406 299,25 300 698,25 699 __ __ 301 279 14 __ 126 140 P2 - Jorge Leandro 172,2 176 595,7 566 84 126 __ __ __ __ 302, 4 302 168 168 26,6 __ 240,8 193 P3 - José Marques 258,3 268 547,4 490 392 360 294 294 686 606,0 0 201, 6 202 224 172 15,4 __ 144,2 211 P4 - Manuel Morais 722,7 5 120 1771,0 4 756 1209,2 5 2168,2 5 699, 95 875 42,07 371,4 2 P4 - Daniel Gonçalves 240 368 220 P4 - Emanuel Teixeira 144 360 710 238 210 __ 119 P4 - Diogo Henriques 363 508 188 408 639 237 284 __ 84 P4 - José Rodrigues __ 472 128 400 620 209 302 __ 126 P5 - Nuno Silva 168 168 329 330 182 180 262,5 262 612,5 554 196 196 392 392 __ __ __ __ P6 - Daniel Rodrigues __ __ __ __ __ __ 248,5 250 506,8 489 196 196 280,7 274 __ __ __ __

(15)

2.5 Identificar os custos indiretos e respetivo método de imputação, bem como o cálculo da

percentagem dos custos indiretos – pedir relatórios ao IDT

Dada a natureza da actividade e dos projetos de IDT da Link Consulting o custo com o pessoal técnico operacional é a sua componente de custos directos maioritária. Consequentemente, todas as despesas necessárias à actividade da empresa, salvo quando sejam directamente relacionadas com outro projeto ou actividade específica, têm a natureza de Custos Indirectos ou “despesas de suporte”, necessárias para assegurar aos colaboradores operacionais as condições essenciais para desenvolverem a sua actividade.

Com o objectivo de optimizar o custo da actividades de suporte, quer em termos de pessoal, quer em termos de outros custos, a Link Consulting tem, desde sempre, optado por fazer uma distribuição destes custos indirectos proporcional, apenas, à dimensão do projeto, dimensão essa medida em função dos custos de pessoal directo (operacional) envolvidos no mesmo.

Como consequência deste critério, nos custos indirectos imputados a um dado projeto podem estar contemplados custos de rubricas que podem não ter uma relevância e correspondência directas com esse projeto. Todavia, como pela sua natureza “indirecta” esses custos não são facilmente associáveis aos diferentes projetos que suportam, parece-nos que esta prática representa uma boa aproximação para, de uma forma justa e equitativa, distribuir tais custos.

Exemplificando: para um dado projeto de ID que represente 2% da actividade da empresa, os custos de gestão administrativa, de reporting e de apoio jurídico, apesar de provavelmente poderem ser superiores a esses 2%, só são imputados nessa proporção. Em contrapartida, outros custos mais relacionados com a actividade corrente da Link, tais como o Marketing ou o Recrutamento, que numa primeira análise podem não estar relacionados com o referido projeto de ID, são também lançados nessa mesma proporção de 2%.

Face ao exposto, o Método de Cálculo dos Custos Indirectos a imputar ao SIPTEST corresponde ao “peso”, em temos de custo directo dos colaboradores envolvidos no projeto, versus o custo directo total de todos os colaboradores operacionais. Ou seja, o Cálculo dos Custos Indirectos (CI) a imputar ao projeto num determinado ano será igual a: CI = Peso do projeto no ano “x” x Total dos Custos Indirectos da empresa no ano “x”.

Sendo que o Peso do projeto (PP) num determinado ano é calculado do seguinte modo:

PP = Custos directos do pessoal operacional (Custo MO) afecto ao projeto no ano “x” / Total dos custos directos de todos os colaboradores operacionais no ano “x”.

Cálculo da % dos Custos Indirectos a afectar ao projeto SIPTEST em 2012: Custo MO do projeto = 201.805€

Custo de MO total dos operacionais da Link = 4.193.752,61 Percentagem de CI a imputar ao projeto em 2012 = 4,81%

Cálculo da % dos Custos Indirectos a afectar ao projeto SIPTEST em 2013: Custo MO do projeto = 207.677,66

Custo de MO total dos operacionais da Link = 4.664.730€ Percentagem de CI a imputar ao projeto = 4,45%

(16)

3 Trabalho Desenvolvido

3.1 Atividades e tarefas desenvolvidas

O projeto SIPTEST foi estruturado com base no desenvolvimento de um conjunto de sete atividades diferenciadas, que se complementam entre si, e foram essenciais à realização do mesmo. A consistência do projeto assentou na adequação das atividades aos objetivos da investigação e na conceção de tarefas necessárias para a concretização de cada atividade, sendo o sucesso da respetiva execução controlado por milestones que conferiram, por sua vez, sustentabilidade aos resultados obtidos e permitem aferir a concretização dos objetivos.

De seguida é apresentada a descrição e fundamentação de cada uma das sete atividades contempladas no projeto, assim como apresentado um quadro resumo das tarefas associadas a cada atividade.

3.1.1 A – Estudos preliminares

A primeira atividade do projeto “A. Estudos preliminares” foi concluída na sua totalidade e teve como missão o estudo comparativo de várias ferramentas de testes e a análise do estado da arte na prática de testes, tendo como referência o CMMI.

No decorrer desta atividade foi possível analisar e comparar vários tipos de ferramentas de testes funcionais, de testes carga e desempenho, de teste de segurança, e de automação de testes.

As ferramentas foram avaliadas e comparadas segundo vários parâmetros, sendo de destacar (genericamente):  A maturidade das ferramentas,

 A curva de aprendizagem das ferramentas

 Capacidades de integração das ferramentas com outras ferramentas e ambientes de desenvolvimento  Capacidades de análise gráfica do status de execução dos testes e dos defeitos detetados.

Estes estudos foram realizados em parceria com a FEUP e a StrongStep, e basearam-se tanto na documentação disponível sobres as ferramentas, como na instalação e utilização exploratória de algumas delas.

Tarefas Data de Conclusão

A.1 - Estudo comparativo de ferramentas de gestão de testes funcionais 24-02-2012 A.2 - Estudo comparativo de ferramentas de testes de segurança 24-02-2012 A.3 - Estudo comparativo de ferramentas de testes de carga e desempenho 14-03-2012 A.4 - Estudo comparativo de ferramentas de automação de testes 23-03-2012 A.5 - Estado da arte da evolução da prática de testes, tendo como referência o CMMI 30-03-2012

3.1.1.1 A1 – Estudo comparativo de ferramentas de gestão de testes funcionais

Para melhor direcionar os estudos efetuados e basear as comparações efetuadas às ferramentas de gestão de testes funcionais foram analisados alguns casos de estudo e artigos que permitiram identificar melhor as caraterísticas

(17)

essenciais de uma ferramenta de gestão de testes. Abaixo alguns dos artigos e estudos analisados e um sumário do seu conteúdo:

 Martin R. Woodward, Michael A. Hennell – “Strategic benefits of software test management: a case study”: Neste artigo, é apresentado um caso de estudo que enfatiza o facto de que, embora testes funcionais e testes estruturais pareçam técnicas opostas, podem realmente complementar-se e produzir uma estratégia de teste de software mais poderosa do que qualquer uma das duas separadas. Isto é conseguido através de um caso de estudo que comprova que partes do software ficam por testar se for usada apenas uma das duas técnicas.

 Michael W. Evans – “Productive Software Test Management”: Livro que explora como testadores devem abordar a criação de testes e boas práticas para evitar a falta de cobertura dos testes. O livro também aborda números princípios que testadores devem ter em consideração e explica algumas técnicas de organização de testes.

 Johnson et al. – “Method and system for test management”: Patente registada no âmbito de teste de software, com via a simplificar a importação e migração de configurações de testes.

 Iris Pinkster et al. – “Successful Test Management: An Integral Approach”: Este livro demostra quais as grandes componentes do teste de software, ensinando conceitos por trás dos diferentes tipos de testes, boas práticas, erros comuns na elaboração de testes e gestão de testes no geral.

 Eickelmann, N.S. – “An evaluation of software test environment architectures”: Artigo que verça sobre a otimização de ambientes de teste de software (STE) com base numa reestruturação da arquitetura desse mesmo ambiente. Particularmente, os autores propõem um arquitetura mais generalizada e comprovam o seu valor acrescentado e o ganho em eficácia por comparação a tradicionais ambientes de teste.

 Jonathan Bach - “Session-Based Test Management”: Neste artigo são analisadas e discutidas sessões de teste de software. São explicados os tipos de suporte que uma ferramenta de teste deve dar, métricas de testes e alguns conselhos do autor na resolução de problemas.

 Griselda Giraudo, Paolo Tonella - “Designing and Conducting an Empirical Study on Test Management Automation”: Este artigo visa passar ao leitor a experiência do autor na gestão de testes automatizados. Mais concretamente, é analisada a metodologia de testes adotada durante o projeto ITALO e é feita uma projeção dos resultados esperados. Finalmente, a nova metodologia é usada e os seus resultados são discutidos.

 Rudolf Ramler, Stefan Biffl, Paul Grünbacher - “Value-Based Management of Software Testing”: Artigo focado na maximização do retorno do investimento em testes de software. O trabalho em si descreve a motivação por detrás de “value-based testing”, descrevendo boas práticas que podem ser adotadas e descrever e demonstrar uma framework para a gestão deste tipo de testes.

 Hefner, R.H. - “Collaborative test management”: Este artigo apresenta os problemas mais comuns em testes formais de sistemas de larga escala e detalha uma abordagem à gestão colaborativa de testes de software. Para tal, como exemplo, apresenta uma tecnologia de informação baseada na Web, já aplicada em vários sistemas de teste da agência NASA.

Após a análise destes documentos foi reunida informação sobre algumas das mais conotadas ferramentas de gestão de testes de software, tendo em consideração as funcionalidades mais significativas deste tipo de ferramentas, de maneira a poderem ser comparadas e escolhida(s) a(s) mais apropriada(s), dependendo da utilização pretendida. Abaixo são listadas algumas das funcionalidades observadas:

(18)

 Gestão de Requisitos – capacidade da aplicação em fazer a gestão relacionada com requisitos funcionais e/ou não funcionais do sistema, considerando a interdependência entre requisitos;  Planos de teste – capacidade da aplicação de suportar a geração ou exportar planos de teste;  Relatórios – capacidade da aplicação de gerar relatórios com o resultado da execução dos testes ou

planos de teste;

 Bug-Tracking – indica se a aplicação contém um sistema integrado para rastreabilidade de erros aquando da execução dos testes;

 Testes Unitários – capacidade da aplicação de executar testes unitários de forma automática;  Testes a Pedido – capacidade da aplicação de executar testes não automatizados, i.e. com input do

utilizador para o início ou para os testes em si;

 Interface de Gestão e Análise – existência de uma interface da aplicação capaz de gerir, guardar, analisar e mostrar os resultados.

Toda esta informação foi agregada numa tabela similar à que se pode ver na figura abaixo:

Nome do Produto Empresa Tipo de Licença Gestão de Requisitos Planos de Teste Relatórios Bug-Tracking Testes Unitários Testes a Pedido Interface de Gestão e Análise XStudio

[10]

XQual Proprietária + GNU

Sim Sim Sim Sim Sim Sim Sim

HP Quality Center

[11]

HP (antiga Mercury)

Proprietária Sim Sim Sim Sim Sim Sim

QADirector

[12]

Micro Focus

Proprietária Sim Sim Sim

QMetry

[13]

QMetry Proprietária Sim Sim Sim Sim Sim Sim Sim

Rational TestManag er

[14]

IBM (antiga Rational)

Proprietária Sim Sim Sim Sim Sim

Tabela 1 – Excerto da tabela de comparação de ferramenta de testes funcionais

Como corolário desta tarefa a equipa de projeto elegeu ainda a ferramenta TestLink como a ferramenta de gestão de testes funcionais a integrar na solução a desenvolver. A principais razões para esta seleção foram o facto de se tratar de uma ferramenta amplamente disseminada e popular na comunidade de testadores funcionais, e cuja funcionalidades atendem as principais necessidade destes tipo de utilizadores e por outro lado se tratar de uma ferramenta free, que não requer qualquer tipo de licenciamento.

3.1.1.2 A2 - Estudo comparativo de ferramentas de testes de segurança Foram analisadas dois tipos de ferramentas de testes de segurança:

(19)

 Ferramentas estáticas: Que apenas examinam fragmentos de código e inferem sobre a existência ou não de vulnerabilidades no sistema.

No que respeita às ferramentas dinâmicas, foi analisado um estudo exaustivo realizado por Shay Chen a 60 ferramentas (open-source e comerciais) onde foram sintetizados alguns dos recursos mais críticos e capacidades de cada ferramenta, tais como:

 Características e capacidades  Benchmark de exatidão

 Cross-site scripting & taxa de falsos positivos  SQL Injection & taxa de falsos positivos

Tabela 2 – Excerto da tabela de comparação de ferramenta de testes de segurança

Figura 1 – Exemplo dos resultados na deteção de SQL Injection

A análise deste estudo permitiu identificar quais as ferramentas mais completas no mercado, direcionando a equipa na seleção das ferramentas que instalou para investigação e utilização exploratória.

(20)

Conforme mencionado anteriormente, foram também analisadas ferramentas de análise estática, que permitiu concluir as limitações existentes neste tipo de ferramentas, nomeadamente na deteção das falhas ao nível da arquitetura do software, e da integração entre vários componentes de uma aplicação.

Tabela 3 – Algumas das ferramentas de análise estática analisadas

3.1.1.3 A3 - Estudo comparativo de ferramentas de testes de carga e desempenho

O primeiro passo desta atividade consistiu em reunir alguns exemplos e linhas orientadoras sobre como selecionar uma ferramenta de testes de carga e desempenho. Abaixo alguns dos artigos consultados:

 A Comparison of Open Source Load Testing Tools ( http://www.jds.net.au/techtips/load-testing-tool-comparison/)

 Real-World Load Testing Tips to Avoid Bottlenecks When Your Web App Goes Live

(http://msdn.microsoft.com/en-us/magazine/cc188783.aspx)

 The French Social Security Administration Switches To Web Performance Load TesterTM From Open Source

(http://www.webperformance.com/library/whitepapers/CNAV/load-testing-CNAV.html)

 Choosing an Appropriate Performance Testing Tool ( http://fyi.oreilly.com/2009/01/choosing-an-appropriate-perfor.html)

 Load Testing Metrics (http://loadstorm.com/load-testing-metrics)  Software testing tool finder (http://www.vcaa.com/tools/)

Tendo como base os estudos realizados acima, foram analisadas várias ferramentas, e a comparação das mesmas sistematizadas numa tabela atendendo aos seguintes fatores comparativos:

 Pago/Livre – Se a aplicação é proprietária e paga ou se é livre (freeware);

 Linguagem dos testes – Fator importante para determinar a compatibilidade com outras aplicações, linguagem e compatibilidade dos testes, plugins e sistemas operativos;

(21)

 Aplicação ativa – indica se a aplicação se encontra em desenvolvimento ativo ou não;  Tipos de teste – tipos de testes de desempenho suportados (stress e carga);

 Sistema Operativo – indica o sistema operativo em que a aplicação pode ser executada;  Alvo – indica o tipo de software que aplicação pode testar

Tabela 4 – Excerto da tabela de comparação de ferramenta de testes de carga e desempenho

Como corolário desta tarefa a equipa de projeto elegeu ainda a ferramenta LoadUI como a ferramenta de testes carga a integrar na solução a desenvolver. As principais razões para esta seleção foram o facto de se tratar de uma ferramenta amplamente disseminada no seio das equipas de desenvolvimento em arquiteturas orientadas a serviços e por outro lado se tratar de uma ferramenta opensource, o que facilita a sua integração.

3.1.1.4 A4 - Estudo comparativo de ferramentas de automação de testes

O estudo comparativo de ferramentas de automação incidiu sobre dois tipos de ferramentas. As ferramentas de Capture/Replay e as frameworks de automação.

As ferramentas de Capture/Replay permitem executar várias vezes scripts de teste criados para garantir que os requisitos implementados são cumpridos ao longo da evolução da aplicação a testar. Os critérios escolhidos para a diferenciação das ferramentas de testes Capture/Replay foram os seguintes:

 Livre/Pago – indica se a aplicação é proprietária e paga ou se é livre (freeware);  Aplicação activa – indica se a aplicação se encontra em desenvolvimento ativo ou não;  Testes de Interface – Interface Desktop (GUI) ou interfaces WEB;

(22)

Tabela 5 – Excerto da tabela de comparação de ferramenta de testes de capture/replay

Para além das ferramentas de Capture/Replay, foram também estudadas e comparadas frameworks de automação através dos quais é possível simular as ações dos utilizadores sobre uma interface gráfica.

Tabela 6 – Excerto da tabela de comparação de frameworks de automação

Com base nas comparações acima, foram selecionadas seis ferramentas sobre as quais se realizaram estudos mais aprofundados. Três ferramentas de testes de serviços Web e três de testes a aplicações Desktop. Mais concretamente, as ferramentas foram o Badboy, o BlueDuck SDA e o SoapUI (para testes Web), o Expect, o Marathon e o Maveryx (para testes a aplicações Desktop).

Os estudos referidos acima focaram-se em algumas características essenciais para este tipo de ferramentas:

 Captura: a captura dos movimentos de cada teste é um fator a ter em conta aquando da comparação deste tipo de ferramentas;

(23)

 Dados de imput: O facto de uma aplicação ser capaz de gerar dados de input, seguir regras para os mesmos (expressões regulares, por exemplo) ou mesmo importar os dados de um ficheiro ou base de dados externos é um fator importante na diferenciação das ferramentas.

 Ambiente de execução: O agendamento de testes, opções de debug e suporte para múltiplos ambientes de desenvolvimento são aspetos cruciais na escolha de uma ferramenta de testes

 Resultados, e relatórios produzidos.

A conclusão desta etapa permitiu sobretudo revelar as potencialidades da ferramenta SoapUI (ferramenta que viria a ser integrada na solução desenvolvida). Esta ferramenta é desenvolvida pela SmartBear Software e suporta testes funcionais, de carga, regressão e aceitação a serviços. Suporta a maior parte dos protocolos e é capaz de modificar parâmetros intrínsecos dos mesmos, como por exemplo, timeouts ou tamanho dos requests. Para além disso esta ferramenta pode ser usada como ferramenta final ou como framework por ser adaptável e open-source.

Figura 2 – Interface do SoapUI

3.1.1.5 A4 – Estado da arte da evolução da prática de testes, tendo como referência o CMMI

Antes de iniciar um projeto de melhoria é necessário conhecer qual o nível de maturidade dos processos de teste existentes na organização. Portanto, a atual situação da organização tem que ser inicialmente avaliada. A avaliação torna claro que informação e que procedimentos estão em curso, e especialmente o que precisa ser melhorado Este estudo teve como foco as práticas genéricas do modelo TMMi e que derivam do modelo CMMI.

(24)

O TMMi é um guia e uma referência para melhorar o processo de teste de qualquer organização. O modelo pode também ser considerado como o “modelo”, uma descrição generalizada de como uma atividade, neste caso de teste, deve ser feita. O TMMi pode ser usado para complementar o CMMI (uma abordagem para melhoria de processos), ou de forma independente. Aplicando o TMMi para avaliar e melhorar um processo de teste de uma organização, a produtividade desta deverá aumentar e por consequentemente a qualidade do produto final.

Foram ainda analisadas as duas ações (Verificação & Validação) que podem melhorar a qualidade do software desenvolvido segundo o CMMI. O modelo CMMI contempla dois processos de controlo e análise para avaliação do software desenvolvido: Verificação e Validação (V & V). A Verificação e Validação inicia-se com a revisão dos requisitos e continua através das revisões de design e inspeções de código.

O objetivo principal do processo V & V é estabelecer confiança de que o sistema de software é ‘adequado à finalidade’:

 Verification: “Are we building the product right?”  Validation: “Are we building the right product?”

A Verificação inclui verificação do produto, bem como todos os intermediários relacionados com os requisitos, incluindo clientes, requisitos dos produtos, etc. A Verificação é inerente a um processo incremental, pois ocorre durante todo o desenvolvimento do produto, começando com a verificação dos requisitos, progredindo através da verificação do produto em evolução, e culminando com a verificação do produto terminado.

A atividade de Validação pode ser aplicada a qualquer aspeto do produto em qualquer ambiente de execução, tais como, operação, treino, produção, manutenção e suporte. A Validação demonstra que o produto irá cumprir o seu propósito, por outras palavras, a validação assegura que se desenvolveu o correto produto. As atividades de validação utilizam abordagens semelhantes à verificação (exemplo, teste, análise, inspeção, demonstração, simulação). Regularmente os utilizadores finais e outros stakeholders relevantes estão também envolvidos em atividades de validação.

3.1.2 B – Especificações técnicas

Esta etapa do projeto “B - Especificações Técnicas” foi concluída na sua totalidade e tinha como missão:

 A revisão e definição de metodologias de testes para as diversas frentes (segurança, carga e desempenho, automação, funcionais).

 Definição da arquitetura de integração das ferramentas selecionadas

 A definição dos níveis de serviço a aplicar nas diversas frentes de testes (segurança, carga e desempenho, automação, funcionais)

 Especificação de uma ferramenta de gestão de serviço integrada

Em termos das tarefas nas quais se consubstancia a atividade B temos:

Tarefas Data de Conclusão

B.1 - Revisão e definição das metodologias e práticas melhoradas de testes de segurança 04/05/2012 B.2 - Revisão e definição da metodologia de testes de carga e desempenho 18/05/2012 B.3 - Revisão e definição da metodologia de automação de testes. 21/06/2012

(25)

B.4 - Revisão e definição da metodologia de testes funcionais 20/06/2012 B.5 - Definição da arquitetura de integração das ferramentas selecionadas 25/07/2012 B.6 - Definição de SLAs a aplicar na frente de testes funcionais 31/07/2012 B.7 - Definição de SLAs a aplicar na frente de testes de segurança 24/08/2012 B.8 - Definição de SLAs a aplicar na frente de testes de carga e desempenho 19/09/2012 B.9 - Definição de SLAs a aplicar na frente de automação de testes 27/09/2012 B.10 - Especificação de uma ferramenta de gestão de serviço integrada 27/09/2012

3.1.2.1 B1 – Revisão e definição das metodologias e práticas melhoradas de testes de segurança

Nesta atividade foram analisadas várias metodologias e boas práticas para desenvolvimento de software mais seguro, tais como:

 SAFECode  BSIMM,  OSSTMM,

 10 Práticas para Codiﬁcação Segura  CERT, Padrões de Codiﬁcação Segura.

SAFECode é baseado num abordagem perspetiva que enfatiza o uso de práticas de segurança e técnicas que provaram ser eficazes em cada membro da organização SAFECode. Não faz juízos de valor deliberados sobre práticas de segurança e prioriza aquelas que foram reconhecidas, por especialistas (membros do SAFECode), como tendo o maior impacto - independentemente do tamanho da organização, recursos ou plataforma de computação.

O BSIMM emprega uma abordagem descritiva para o desenvolvimento seguro de software e não procura medir a eficácia dos processos de segurança. Por outras palavras, o BSIMM é útil para comparar as atividades de segurança para software observadas numa determinada organização, com as outras 42 organizações referidas no estudo.

O Manual Open-Source de uma Metodologia para Testes de Segurança (Open Source Security Testing Methodology Manual - OSSTMM) é uma metodologia de peer-reviewed para testes de segurança e métricas de desempenho, com vários anos de experiência. Os casos de teste do OSSTMM são divididos em cinco canais (secções), tais como, Recursos Humanos, Físico, Wireless, Telecomunicações e Redes de Dados. Coletivamente esses canais testam: informação e controlo de dados, níveis de segurança pessoais, fraudes e níveis de controlo de engenharia social, redes de computadores e telecomunicações, dispositivos wireless, dispositivos móveis, controlos de acesso físico e localizações físicas tais como edifícios, bases militares, etc. O OSSTMM incide nos detalhes técnicos sobre quais os itens que precisam ser testados, o que fazer antes, durante e após um teste de segurança, e como medir os resultados. Testes individuais, por si só, não são particularmente revolucionários, mas a metodologia como um todo representa o ponto de referência para a profissão de testes de segurança. Novos testes para as melhores práticas internacionais, regulamentos e preocupações éticas são adicionados regularmente ao manual.

O CERT, um centro de estudos para resposta e tratamento de incidentes em computadores, elaborou uma lista com 10 boas práticas para codificação segura para os programadores seguirem, quando estão a desenvolver o seu código e inclui sugestões para manter o código simples, validar os dados de entrada, etc.

(26)

1. Validar os dados de entrada. Uma apropriada validação pode eliminar uma vasta maioria das vulnerabilidades do software. O programador deve sempre desconfiar de onde os dados de entrada provêm incluindo linhas de comando, interfaces de rede, variáveis de ambiente, etc .

2. Avisos do compilador. O programador deve compilar o seu código utilizando o nível mais alto de alertas disponível no seu compilador e eliminar os avisos [CMSC00-A1, C++ MSC00-A2]. Podem ainda ser utilizadas ferramentas de análise dinâmica para detetar e tentar eliminar falhas de segurança.

3. Arquitetura e Design para políticas de segurança. Criar um arquitetura e um design para o software que implemente e force o cumprimento de políticas de segurança.

4. Manter o código simples. Manter o código tão simples e pequeno quanto possível. Sistemas complexos aumentam a probabilidade de existirem erros na sua implementação/configuração.

5. Negação por padrão. Basear as decisões de acesso em permissões ao contrário de exclusões. Isto significa, que por norma, o acesso é negado e as permissões de acesso identificam condições sobre as quais o acesso é permitido.

6. Respeitar o princípio do menor privilégio. Cada processo deve ser executado com o mínimo conjunto de privilégios necessário para realizar a sua tarefa. Esta abordagem reduz a oportunidade de uma pessoa mal-intencionada executar código arbitrário com elevados privilégios.

7. Alterar os dados a enviar para outros sistemas. Alterar todos os dados enviado para subsistemas complexos [C STR02-A3], tais como, bases de dados relacionais, etc. Isto porque pessoas mal-intencionadas podem ser capazes de invocar funcionalidades não utilizadas nesse componente através do uso de injeção SQL.

8. Práticas de defesa. Gerir os riscos com múltiplas estratégias defensivas, por forma a que se uma camada de defesa for invadida, a camada imediatamente a seguir pode evitar que uma falha de segurança se torne uma vulnerabilidade explorável e/ou limitar as consequências de uma exposição bem sucedida.

9. Utilizar técnicas eficazes que garantam qualidade. Técnicas que garantam qualidade, podem ser eficazes para identificar e eliminar vulnerabilidades. Devem ser incorporadas audições ao código fonte como parte de um programa de garantia de qualidade, bem como testes Fuzz, testes penetração, etc. Revisões independentes ao código fonte, podem também garantir mais segurança.

10. Adotar padrões de codificação segura. Desenvolver e/ou aplicar padrões de codificação segura para a sua linguagem e plataforma de desenvolvimento.

O CERT é parte do Carnegie Mellon University’s Software Engineering Institute e desenvolve padrões de codificação seguro para as linguagens de programação mais utilizadas, tais como, C/C++ e Java , através de um esforço de toda a comunidade, que inclui membros de desenvolvimento de software e comunidades de segurança para software. O CERT inclui também, orientações para evitar erros de codificação e implementação, bem como, erros de baixo nível no design de software.

1

MSC00-C. Compile cleanly at high warning levels, https://www.securecoding.cert.org/confluence/display/seccode/MSC00-C.+Compile+cleanly+at+high+warning+levels, 2012.

2

C++ MSC00-A, https://www.securecoding.cert.org/confluence/display/cplusplus/VOID+Compile+cleanly+at+high+warning+levels, 2012.

3

Sanitize data passed to complex subsystems, https://www.securecoding.cert.org/confluence/display/seccode/STR02-C.+Sanitize+data+passed+to+complex+subsystems, 2012.

(27)

Normas de codificação bem documentadas e exequíveis são essenciais para um desenvolvimento seguro de software. Padrões de codificação incentivam os programadores a seguir um conjunto de regras e guias, determinados pelos requisitos de um projeto e pela organização e não pela familiaridade dos programadores ou suas preferências. Uma vez estabelecidos esses padrões, podem ser utilizados como métrica para avaliar o código fonte (utilizando processos manuais ou automáticos) para o cumprimento da norma.

Padrões de Codificação para Java do CERT

Os Padrões de Codificação para Java do CERT incluem regras e práticas recomendadas para programação segura em Java Platform Standard Edition 6 e Java SE 7. A versão 1 desta norma já está concluída e pronta para revisão.

Padrões de Codificação Segura para C/C++ do CERT

Os Padrões de Codificação Segura para C/C++ do CERT fornecem regras e recomendações para codificação segura na linguagem de programação C. O objetivo principal destas regras é recomendar e eliminar práticas inseguras e comportamentos indefinidos que se podem tornar vulnerabilidades exploráveis. A aplicação deste padrão de codificação segura irá conduzir a um sistema mais robusto e mais resistente a ataques, logo com maior qualidade.

3.1.2.2 B2 – Revisão e definição das metodologias e práticas melhoradas de testes de carga e desempenho Nesta atividade foram utilizadas analisadas várias metodologias de teste de carga e desempenho.

Testes de carga são, por definição, testes que tentam sobrecarregar um sistema, dentro dos requisitos para os quais este foi desenvolvido, avaliando as respostas do mesmo. Para tal, estes testes usam o aumento de carga em um ou vários componentes, de uma maneira linear ou mais dinâmica.

Por oposição aos testes de carga, os testes de stress tentam sobrecarregar um sistema acima dos requisitos para os quais o sistema foi desenvolvido, avaliando as respostas do mesmo. Estes tipos de teste têm como objetivo o teste da estabilidade do sistema.

Testes de carga são capazes de detetar bugs que não são detetados em ambientes normais de execução. Testes de carga são também capazes de detetar problemas relacionados com “bufferoverflow”, “memory leaks” e má gestão de memória, além de determinar os limites dos recursos dos componentes de uma aplicação de software, por exemplo, bases de dados, hardware e redes, etc.,de forma a poder gerir e estimar a carga futura do sistema de software.

Por sua vez, os testes de stress são normalmente usados de maneira a detetar os pontos (carga necessária) em que um componente ou um sistema falha, chamados de “breaking points”. A utilidade deste tipo de testes está também no facto de que as falhas de um sistema sobrecarregado podem revelar erros na implementação do componente ou sistema.

Existem diferentes abordagens aos testes de carga, por exemplo:

 Testes de carga simples – execução de testes que impõe carga máxima em todos os componentes;  Testes de carga crescente – execução de carga crescente em todos os componentes de maneira a

detetar qual o limite de cada um;

 Testes de carga variável por componente – testes de carga crescente e variável efetuados a cada componente de maneira a detetar dependências não previstas entre os componentes.

(28)

Os tipos de teste de stress que existem são em parte similares à abordagem tomada nos testes de carga, mas com algumas modificações em termos do propósito. Desta maneira, os diferentes testes de stress existentes são:

 Testes de sensibilidade – testes realizados com o propósito de descobrir o impacto da sobrecarga de diferentes componentes de forma a perceber as dependências existentes;

 Testes por cenário – testes baseados em casos reais que exigiriam uma sobrecarga no sistema.

No decorrer desta atividade focou-se também no processo de testes associados aos testes de desempenho (ver figura abaixo), assim como nas boas práticas.

Figura 3 – Processo de criação e execução de testes de desempenho No que respeita às boas práticas na construção e execução de testes de desempenho, são:

 Um projeto que implemente testes de desempenho deve ter um documento que contenha uma linha de base para o desempenho esperado do sistema, para que durante a execução de testes possa ser feita uma comparação da expectativa vs condição atual do produto;

 O ambiente de execução de testes deve replicar com a maior precisão possível o ambiente de produção no qual o sistema vai ser instalado;

 O ambiente de desenvolvimento de testes de desempenho, tal como de outros testes, não deve ser agrupado com o ambiente de desenvolvimento do produto em si;

 Este tipo de testes deve ser executado e monitorizado com frequência de maneira a controlar o incremento em desempenho que cada parte ou componente desenvolvida tem.

(29)

System Intelligent Process Testing| Link Consulting,SA | Pág. 28 de 62 3.1.2.3 B3 – Revisão e definição da metodologia de automação de testes

Esta atividade focou-se essencialmente nos critérios de automação em que deverá assentar uma metodologia de testes.

Existem algumas circunstâncias que podem levar a preferência por criar ou executar testes automaticamente. Cabe aos testadores perceberem para cada teste ou conjunto de testes que pretendem correr se estes devem ser gerados ou executados automaticamente.

No caso da criação de testes, testadores devem ter em conta os seguintes critérios de modo a determinar que testes podem e/ou devem ser gerados automaticamente:

• Reutilização de tipos de testes • Dinamismo do output produzido • Previsibilidade do output

Concretamente, se for possível generalizar o teste ou conjunto de testes que se pretende desenvolver e os seus inputs (i.e., geração de classes de equivalência e valores fronteira automaticamente), então pode ser preferível automatiza-los. Da mesma maneira, se os outputs forem considerados dinâmicos na sua natureza ou difíceis de prever, será difícil julgar a sua validade; os testes devem portanto, nestes casos, não serem automatizados.

No caso da execução de testes, e tomando como certo que os dois últimos pontos dos critérios de automação da criação de testes também são válidos para a execução de testes, o critério de automação mais relevante para a execução de testes de software pode ser centrado na seguinte pergunta “Quantas vezes terão um teste ou um conjunto de testes de ser executado e com que frequência?”. De uma maneira lógica, quanto mais vezes executado e quanto maior for a frequência de execução de um teste ou conjunto de testes, maior estes serão candidatos à automação da sua execução.

3.1.2.4 B4 – Revisão e definição da metodologia de testes funcionais

Esta atividade aprofundou a metodologia de testes TMMI. O TMMi foi desenvolvido por uma comunidade de especialistas na área de testes designada TMMi Foundation4, para tentar corrigir a lacuna do CMMI e de outros modelos de teste, posicionando-se assim, como um modelo complementar ao CMMI. A framework TMMi foi implementada na já existente frameworkTMM (inicialmente desenvolvida pelo Illinois Institute of Technology em 1996) como ponto de partida e guiada através das boas práticas da framewok CMMI. O TMMi é uma compilação de todos os modelos de teste de software que suportem testes que não são cobertos ou estão em falta em vários modelos como TPI ou TMM. O TMMi segue um modelo de representação que utiliza conjuntos predefinidos de áreas de processos, para definir melhorias na área de teste que pode estar integrada ou é independente do desenvolvimento de software da organização.

Tal como o CMMI, o TMMi também utiliza o conceito de níveis de maturidade para avaliação e melhoramento de processos. Além do mais, as áreas de processo, objetivos e práticas chave são também identificadas. Aplicando os critérios de maturidade do TMMi qualquer organização poderá melhorar o processo de teste e por isso terá um impacto positivo no ciclo de desenvolvimento, e consequentemente uma melhoria na qualidade do produto final. O TMMi foi desenvolvido para apoiar as organizações de software na avaliação e melhoria dos seus processos de teste.

4

(30)

As experiências realizadas com a utilização do TMMi, são positivas e mostram que este estabelece um processo de teste mais eficaz e eficiente.

Níveis de Maturidade do TMMi

O TMMi é composto por vários níveis, através dos quais uma organização evolui de processos de teste ad hoc para processos geridos, definidos, medidos e otimizados. O cumprimento de cada nível garante à organização a passagem para o próximo nível de melhoramento. Os cinco níveis do TMMi (ver figura) descrevem uma hierarquia que permite melhorar o processo de teste.

Nível 1 - Inicial

O TMMi reconhece a tarefa de teste como sendo um processo indefinido e muitas vezes, na organização, considerado como uma tarefa de debugging. As organizações avaliadas com apenas o nível de maturidade 1, são caraterizadas por abandono de processos em tempos de crise e uma incapacidade de repetir sucessos. Não existem processos-chave envolvidos neste nível e é altamente recomendável o avanço para um nível superior.