SIPTEST System Intelligent Process Testing. SLAs a aplicar em frentes de testes funcionais

(1)

SIPTEST - System Intelligent Testing Link Consulting,SA | Pág. 0 de 8

SIPTEST – System Intelligent Process Testing.

SLAs a aplicar em frentes de testes funcionais

(2)

SIPTEST - System Intelligent Process Testing Link Consulting,SA | Pág. 1 de 8

Índice

1 Introdução... 2 2 SLAs a aplicar na frente de testes funcionais ... 5 3 Referências ... 7

(3)

1 Introdução

No desenvolvimento de software, “testar” involve normalmente várias fases (a figura 1ilusta a relação entre as várias fases de teste). Primeiro, cada componente do programa étestado individualmente, ou seja, isolado dos outros componentes do sistema. Tais testes,conhecidos como testes de componentes ou testes unitários, verificam se o componentefunciona como esperado com os tipos de input avaliados no estudo desses componentes.

Testes unitários são executados num ambiente controlado (quando possível), desta forma a equipa de teste pode controlar os dados de input e observar o output e os dados produzidos pelo componente. Além disso, a equipa de teste verifica as estruturas de dados internas, a lógica, e as condições de controlo para a entrada e saída de dados. Quando todos os componentes tiverem sido testados individualmente, a próxima fase é assegurar que as interfaces entre componentes estão definidas e funcionam adequadamente. Testes de Integração é o processo de verificação de que os componentes do sistema funcionam como um conjunto, tal como descrito na especificação do programa. Testes Funcionais (o foco deste relatório) são baseado na análise da especificação da funcionalidade de um

componente ou sistema e também conhecidos como testes blackbox. Portanto, testes funcionais oferecem a possibilidade de verificar que o sistema funciona como deveria (que faz aquilo que o utilizador espera que faça). Permitem também à equipa Quality assurance (QA) verificar se o software está pronto para a entrega. Um exemplo simples de um teste funcional é, se um sistema bancário permitir aos utilizadores modificar a sua conta,

adicionar/remover dados, imprimir relatórios, os testes funcionais devem assegurar que o utilizador pode executar essas tarefas no sistema. Muitos dos testes de sistema, incluindo os testes funcionais devem ser concebidos na mesma altura que os requisitos, e devem ser incluídos no plano de teste do sistema [1]. Portanto, alterações aos requisitos implicam que os testes e o plano de testes devam refletir essas mesmas mudanças. Como os testes funcionais são na sua essência testes black box, Equivalence Class Partitioning e Boundary-Value Analysis são métodos úteis para a geração de casos de teste. Intrusive Testing, Random Testing, State Transition Testing, Static Testing e Thread Testing são também métodos úteis. O resultado da fase de testes funcionais é um sistema em funcionamento.

(4)

SIPTEST - System Intelligent Process Testing Link Consulting,SA | Pág. 3 de 8 Figura 1 – Fases de Teste

Os testes funcionais, descritos anteriormente, comparam o sistema desenvolvido com as funções descritas, em seguida os testes de desempenho validam os restantes requisitos de software/hardware. Testes de desempenho são utilizados para avaliar se um determinado sistema ou componente satisfaz, ou não, os seus requisitos específicos de desempenho. Quando os testes de desempenho são realizados com sucesso no ambiente real de um cliente, é produzido um sistema válido na perspetiva de desempenho.

Quando a fase dos testes de desempenho termina, os programadores garantem que o sistema funciona de acordo com o seu entendimento da descrição do sistema. O próximo passo é avaliar com o cliente para garantir que o sistema funciona de acordo com as suas expetativas. Testes de Aceitação são um teste formal relativo às necessidades do utilizador, dos requisitos, e processos de negócios realizados para determinar se é ou não um sistema que satisfaz os critérios de aceitação. Permite também que o utilizador, clientes ou entidades autorizadas determinem se aceitam ou não o sistema. Ou seja, o prestador do serviço reune-se com o cliente para realizar os testes de aceitação, onde o sistema é confrontado com a descrição dos requisitos do cliente. Após a conclusão dos testes de aceitação o sistema é instalado no ambiente onde será realmente utilizado, e um teste final (testes de instalação) é executado para garantir que o sistema funciona como esperado no ambiente real de utilização. Independentemente do tamanho do sistema a ser testado, o tipo de teste descrito em cada fase é necessário para garantir o funcionamento correto do sistema.

Nos dias de hoje, está perfeitamente entendido que “testar” é uma área especializada que ajuda as organizações a reduzirem os riscos e a obterem um maior valor comercial em todo o ciclo de desenvolvimento de software [3]. No entanto, muitas organizações continuam a ignorar a fase de validação e verificação do sistema. Essencialmente, testes de software consistem em exercitar todos os caminhos possíveis de um software e verificar que estes não apresentem falhas. Este processo por ser realizado pela própria organização ou através de modelo outsourcing, Testing as a Service (TaaS), em que as atividades de teste são realizadas por um prestador de serviços. TaaS é mais adequado para testes especializados, ou seja, testes que não requeiram grande conhecimento sobre o sistema.

(5)

Serviços que são usualmente utilizados pelo modelo TaaS incluem testes de regressão automatizados, testes de desempenho, testes de segurança e monitorização ou teste de software baseados na cloud. Um Service Level Agreement (SLA) é um importante documento que é utilizado para definir os valores/métricas que regularam a relação entre o cliente e o prestador de serviço e pode fazer parte do contrato de serviço [4]. O acordo é geralmente expresso uma linguagem simples para poder ser entendido pelas duas partes. O documento pode incluir também termos técnicos para definir o serviço em questão. O SLA pode abordar várias áreas, incluindo a disponibilidade do serviço, o desempenho do serviço, como irá funcionar, as prioridades, as responsabilidades das partes envolvidas, garantias, etc. Um SLA faz sentido quando a organização tem o processo de teste como um serviço de testes onde é preciso definir valores/métricas que regulem a relação com os clientes. Assim, desde o ínicio, o SLA deve ser enquadrado de tal forma que, mais tarde, possa ser fácil para o cliente e para o prestador do serviço consultá-lo sempre que surgir alguma divergência entre as duas partes.

No caso de outsourcing, um SLA é extremamente importante. O ambiente no qual o projeto outsource é executado é inteiramente diferente do ambiente de testes tradicional que os projetos internos usufruem. Devido à distância, a diferentes culturas e produtividade, esses projetos necessitam de um nível de amadurecimento elevado para garantir confiança ao cliente. Nestas situações, um SLA tornam-se a única ferramenta para defesa dos clientes.

(6)

2 SLAs a aplicar na frente de testes funcionais

Os testes funcionais verificam que o sistema já integrado executa as funções tal como especificado nos requisitos. Um SLA típicos aplicável a testes funcionais pode ser definido segundo as métricas dos vários métodos que

caraterizam os testes funcionais [2]: EquivalenceClass Partitioning, Boundary-Value Analysis, Random Testing, State Transition Testing e Static Testing.

Equivalence Class Partitioning

Neste método, o domínio de dados de entrada é dividido em diferentes classes de dados de equivalência. É tipicamente utilizado para reduzir o número total de casos de teste para um conjunto finito, mantendo a cobertura máxima dos requisitos.

Algumas das caraterísticas que podem ser incluídas num SLA são: preferência pelos casos de teste que incluem combinações dos valores de limite; garantir que todos os valores representativos de uma classe de equivalência ocorrem pelo menos uma vez num caso de teste; pode também ser utilizada a medição de quantos dos casos de teste com base em classes de equivalência foram cobertos pelos casos de teste (para determinar a abrangência dos testes). O valor de equivalence class partitioning [5] depende da determinação das classes de equivalência.

Equivalence Class (EC) = (número de combinações EC testadas/ número total de combinações EC) * 100

Boundary-Value Analysis

É amplamente reconhecido que os valores de entrada nos extremos do domínio de entrada, causam mais erros no sistema [3]. A técnica de teste Boundary-Value Analysis é utilizada para identificar erros utilizando valores de entrada de fronteira do domínio e não, encontrar erros com valores intermédios do domínio de entrada. Análise do valor fronteira deve ser feita em conjunto com o equivalence partitioning.

No acordo entre o cliente e o prestador do serviço (software) podem ser incluídas as seguintes regras: definição de valores fronteira para todos os casos de teste; tal como a equivalence partitioning, os valores de teste gerados a partir de cada análise de limite devem ser combinados para gerar os casos de teste; semelhante ao equivalence partitioningo boundary-value pode ser medido [5].

Boundary-Value (BV) = (número de combinações BV testadas/ número total de combinações BV)*100

Random Testing

É um tipo de teste funcional que é útil quando o tempo necessário para escrever e executar testes é muito longo (ou a complexidade do problema torna impossível testar cada combinação). Em relação a Random Testing, o SLA pode descrever, por exemplo, a exigência deque não poderá haver falhas aleatórias durante 2 semanas antes do lançamento do sistema.

(7)

SIPTEST - System Intelligent Process Testing Link Consulting,SA | Pág. 6 de 8 State Transition Testing

State Transition Testing é utilizado quando algum componente do sistema pode ser descrito como uma “máquina de estados finito”. Isto significa, que o sistema pode estar num número (finito) de diferentes estados, e as transições de um estado para outro é determinada pelas regras da máquina de estados.

Alguns dos pontos que podem ser abordados no SLA relativos a State Transition Testing são: cada estado deve ser coberto pelo menos uma vez; cada transição deve ser executada pelo menos uma vez; cada transição que viole a especificação deve ser verificada. Uma tabela de estados pode ser utilizada para verificar o número total de combinações de estados e transições (válidas e inválidas). Para software crítico o SLA pode também incluir as seguintes regras [5]: todas as combinações de transições têm que ser verificadas; todas as transições em qualquer ordem, com todos os estados possíveis, têm que ser verificadas.

Static Testing

É uma forma de testar o sistema que não envolve a execução da aplicação a ser testada. Static Testing envolve analisar o código da aplicação para verificar principalmente a conformidade com os requisitos funcionais, com o design, as funcionalidades em falta e possíveis erros no código. Static Tests são em geral, eficazes na deteção de erros de lógica e de codificação.

Uma possível métrica (passível de ser definida no SLA) para determinar se um programa (flow graph do programa) é mais ou menos complexo, é a cyclomatic complexity [6, 4]. Quanto mais complexo for o flow graph do programa, maior será o valor de cyclomatic complexity.

Cyclomatic Complexity = L-N +2*P

Onde L é o número de ligações entre os vários nós do flow graph, N é o número de nós que constituem o flow graph e P é o número de componentes independentes (número de partes desconetadas do flow graph).

(8)

3 Referências

[1] I. Burnstein. Practical Software Testing: A Process-Oriented Approach. Springer Professional Computing. Springer, 2010.

[2] S.L. Pfleeger e J.M. Atlee. Software Engineering: Theory and Practice. Prentice Hall, 2009.

[3] I. Sommerville. Software engineering. International computer science series. Addison-Wesley, 2007. [4] A. Ahmed. Software Testing as a Service. Taylor & Francis, 2009.

[5] David Sinclair. Software Testing Class, Dynamic Testing: Black Box Testing.

http://www.computing.dcu.ie/~davids/courses/CA267/CA267_ Dynamic_Testing_Black_Box_2p.pdf, 2012. [6] Thomas J. McCabe. A complexity measure. Em Proceedings of the 2nd international conference on Software engineering, ICSE ’76, páginas 407–, Los Alamitos, CA, USA, 1976. IEEE Computer Society Press.

[7] P. Farris, N.T. Bendle, P.E. Pfeifer, e D.J. Reibstein. Marketing Metrics: The Definitive Guide to Measuring Marketing Performance. Wharton school publishing. FT Press, 2010.