Etapas da Qualidade de Software

Prévia do material em texto

Etapas da qualidade 
de software – Testes de 
Integração
 
SST
Passos, Ubiratan Roberte Cardoso
Etapas da qualidade de software – Testes de Integração/ 
Ubiratan Roberte Cardoso Passos 
Ano: 2020
nº de p.: 11 
Copyright © 2020. Delinea Tecnologia Educacional. Todos os direitos reservados.
Etapas da qualidade 
de software – Testes de 
Integração
3
Apresentação
A qualidade de um software está relacionada ao funcionamento desse software 
com correção e eficiência e, neste momento, vamos estabelecer características a 
serem observadas para estruturar testes efetivos, que cumpram com o objetivo de 
identificar erros e falhas na execução do software.
A seguir, vamos ilustrar algumas estratégias de testes, que incluem os testes 
de unidade, de integração, de regressão e de fumaça, destacando propriedades 
e objetivos de cada um. Por fim, vamos destacar ajustes nessas estratégias no 
contexto do desenvolvimento orientado a objetos. 
Estratégias de teste de software
Estratégias de teste de software são como roteiros que descrevem um passo a 
passo para o planejamento e execução dos testes, ajudando também a definir o 
quanto de trabalho, tempo e recursos serão necessários para realizá-los. Logo, 
qualquer que seja a estratégia de testes, ela deve incorporar as atividades de 
planejamento, projeto de casos de teste, execução dos testes, coleta e avaliação 
dos dados resultantes.
Uma estratégia de teste de software deve ser flexível o bastante para promover uma 
abordagem de teste personalizada. Ao mesmo tempo, deve ser rígida o bastante 
para estimular um planejamento razoável e o acompanhamento, à medida que o 
projeto progride. 
4
Existem muitas propostas de estratégia de testes disponíveis na literatura, todas 
elas fornecem um modelo para testes e possuem as seguintes características:
Características das estratégias de teste
Fonte: Plataforma Deduca (2020).
Uma estratégia de teste de software deve acomodar testes de baixo nível, 
necessários para verificar se um pequeno segmento de código-fonte foi 
implementado corretamente, bem como testes de alto nível, que validam as funções 
principais do sistema de acordo com os requisitos do cliente.
Uma questão que surge quando se discute testes de softwares 
é saber quando terminar os testes ou se os testes realizados 
foram suficientes. Infelizmente, não existe uma resposta definitiva 
para essa pergunta, mas existem algumas tentativas iniciais e 
empíricas, que afirmam que o teste nunca termina, uma vez que 
o encargo simplesmente passa do engenheiro de software para o 
usuário final, ou que o teste acaba quando o tempo ou o dinheiro 
acabam.
Atenção
5
A abordagem de sala limpa sugere técnicas de uso estatístico (KELLY; OSHANA, 
2000) que executa uma série de testes derivados de uma amostragem estatística 
de todas as execuções possíveis do programa por todos os usuários em uma 
população escolhida. Outros, (SINGPURWALLA; WILSON, 1999), por exemplo, 
defendem o uso de modelagem estatística e teoria de confiabilidade de software 
para prever a integralidade do teste. Coletando métricas durante o teste do 
software e utilizando modelos existentes de confiabilidade de software, é possível 
desenvolver diretrizes significativas para identificar até quando testar. 
Estratégias de testes para softwares 
convencionais
Existem diversas estratégias que podem ser utilizadas para se testar um software 
como, por exemplo, esperar até que tudo esteja pronto, e então testar o sistema 
completo (o que não funciona), ou, pode-se realizar testes diários sempre que 
algo novo for construído. Apesar de muito eficaz, poucos desenvolvedores a 
aplicam. Então, uma solução viável é a realização dos testes assumindo uma 
visão incremental, iniciando pelos testes de unidade, passando para os testes de 
integração, validação e terminando no teste geral do sistema. Vejamos a seguir:
1) Testes de Unidade
Os testes de unidade focam seu esforço na verificação da menor unidade do projeto 
de software – componente ou módulo de software. Guiados pela descrição do 
projeto no nível de componentes, caminhos de controle importante são testados 
para se descobrir erros que possam estar dentro dos limites de cada módulo. Os 
testes de unidade enfocam a lógica interna de processamento e as estruturas de 
dados dentro dos limites de um componente, podendo ser conduzido em paralelo 
para diversos componentes.
Testes de unidade normalmente são considerados como auxiliares da etapa de 
codificação, sendo que o projeto dos testes de unidade pode ocorrer antes ou 
depois que o código-fonte for gerado. Um exame das informações de projeto 
fornece instruções para estabelecer casos de testes que provavelmente mostrarão 
os erros em cada uma das categorias descritas anteriormente. Cada caso de 
teste deverá ser acoplado a um conjunto de resultados esperados, um esquema é 
apresentado a seguir.
6
Esquema de resultados esperados
Fonte: Adaptada de Pressman e Maxim (2016).
2) Testes de integração
O teste de integração é uma técnica sistemática para construir a arquitetura de 
software ao mesmo tempo que conduz testes para descobrir erros associados com 
as interfaces. O objetivo é construir uma estrutura de programa determinada pelo 
projeto a partir de componentes testados em unidade. Isso se faz necessário pois 
equivocadamente, alguns engenheiros com menos experiência acreditam que, uma 
vez que os módulos funcionam independentemente, eles certamente funcionariam 
em conjunto, o que pode não ser verdade. São formatos de testes de integração 
descendente ou ascendente.
Integrações descendentes e ascendentes
Fonte: Adaptada de Pressman e Maxim (2016).
7
• Integração descendente: Teste de integração descendente (top-down) é uma 
abordagem na qual módulos são integrados deslocando-se para baixo por 
meio da hierarquia de controle, começando com o módulo de controle princi-
pal (programa principal). Módulos subordinados ao módulo de controle prin-
cipal são incorporados à estrutura de uma maneira: primeiro-em-profundi-
dade ou primeiro-em-largura (depth-first ou breadth-first). Nesse modelo, o 
processo de integração é executado em uma série de cinco passos: 
• Integração ascendente. O teste de integração ascendente (bottom-up), como 
o nome diz, começa a construção e o teste com módulos atômicos (isto é, 
componentes nos níveis mais baixos na estrutura do programa). Devido aos 
componentes serem integrados de baixo para cima, a funcionalidade propor-
cionada por componentes subordinados a um dado nível está sempre dispo-
nível e a necessidade de pseudocontroladores é eliminada. Uma estratégia 
de integração ascendente pode ser implementada com os seguintes passos:
3) Testes de regressão
Sempre que um novo módulo é integrado aos testes de integração, o software muda 
e são estabelecidos novos caminhos de fluxo de dados, podendo ocorrer novas 
entradas e saídas e até mesmo uma nova lógica de controle de chamadas. Essas 
alterações podem fazer com que funções parem de funcionar.
No contexto de uma estratégia de teste de integração, o teste de regressão é 
a reexecução do mesmo subconjunto de testes que já foram executados para 
assegurar que as alterações não tenham propagado efeitos colaterais indesejados. 
O teste de regressão ajuda a garantir que as alterações não introduzam 
comportamento indesejado ou erros adicionais.
O teste de regressão pode ser realizado a partir de uma amostra representativa 
dos testes que utilizam todas as funções do software; de testes adicionais que 
focalizam as funções de software que podem ser afetadas pela alteração ou por 
testes que focalizam os componentes do software que foram alterados.
À medida que o teste de integração progride, o número de testes de regressão pode 
crescer muito. Portanto, o conjunto de testes de regressão deve ser projetado de 
forma a incluir somente aqueles testes que tratam de uma ou mais classes de erros 
em cada uma das funções principais do programa.
8
4) Testes de fumaça
No contexto dos testesde integração, a abordagem do teste fumaça é 
frequentemente utilizada em projetos com prazos críticos, permitindo que o projeto 
seja avaliado constantemente e é composta das seguintes atividades: 
• Componentes de software são integrados em uma “construção” (build), que 
inclui todos os arquivos de dados, bibliotecas, módulos reutilizáveis e com-
ponentes para implementar uma ou mais funções do produto; 
• Uma série de testes é criada para expor erros que impedem a construção de 
executar corretamente sua função. A finalidade deverá ser descobrir erros 
“bloqueadores” (showstopper) que apresentam a mais alta probabilidade de 
atrasar o cronograma do software; e 
• A construção é integrada com outras construções, e o produto inteiro (em 
sua forma atual) passa diariamente pelo teste fumaça. A abordagem de inte-
gração pode ser descendente ou ascendente.
McConnell (1996) afirma que, mantendo uma frequência diária de 
testes do produto inteiro, é possível oferecer tanto aos gerentes 
quanto aos profissionais uma ideia realística do progresso do teste 
de integração.
Atenção
 Alguns dos benefícios trazidos pelo teste fumaça são: 
• Redução dos riscos de integração;
• Melhoria na qualidade do produto final; e
• Simplificação no diagnóstico e correção de erros. 
9
Testes no contexto da orientação a 
objetos
Quando consideramos o software orientado ao objeto, o conceito de unidades 
se modifica. O encapsulamento controla a definição de classes e objetos e isso 
significa que cada classe e cada instância de uma classe (objeto) empacotam 
atributos (dados) e as operações que manipulam esses dados.
Devido ao software orientado a objeto não ter uma estrutura óbvia de controle 
hierárquico, as estratégias tradicionais de integração descendente e ascendente 
têm pouco significado. 
1) Testes de unidade 
Como uma classe pode conter um conjunto de diferentes operações, e uma 
operação em particular pode existir como parte de um conjunto de diferentes 
classes, a tática aplicada a teste de unidade precisa modificar-se. Para ilustrar, 
considere uma hierarquia de classe na qual uma operação X é definida para a 
superclasse e é herdada por várias subclasses. Veja no diagrama.
Teste de unidade
Fonte: Elaborado pelo autor (2020).
Cada subclasse usa uma operação X, mas é aplicada dentro do contexto dos 
atributos e operações privadas definidas para a subclasse. Como o contexto no 
qual a operação X é utilizada varia de maneira sutil, torna-se necessário testar 
a operação X no contexto de cada uma das subclasses. Isso significa que testar 
a operação X isoladamente (a abordagem de teste de unidade convencional) é 
usualmente ineficaz no contexto orientado ao objeto.
10
2) Testes de integração
Existem duas estratégias diferentes para teste de integração para sistemas OO. 
A primeira, baseada na sequência de execução (thread-based testing), integra o 
conjunto de classes necessárias para responder a uma entrada ou um evento do 
sistema. Cada sequência de execução é integrada e testada individualmente. O 
teste de regressão é aplicado para garantir que não ocorram efeitos colaterais. 
A segunda abordagem de integração, teste baseado em uso (use-based testing), 
inicia a construção do sistema testando aquelas classes (chamadas de classes 
independentes) que usam poucas (ou nenhuma) classes servidoras. Depois que 
as classes independentes são testadas, o próximo nível de classes, chamadas de 
classes dependentes, que usam as classes independentes, são testadas. 
O teste de agregado (cluster) é uma etapa no teste de integração de software OO. 
Nesse caso, um agregado de classes colaboradoras (determinado examinando-se 
os modelos CRC e o modelo objeto-relacionamento) é exercitado, projetando casos 
de teste que tentam descobrir erros nas colaborações.
Fechamento
Estudamos que uma estratégia de teste pode ser interpretada como um processo 
que envolve atividades de planejamento, projeto, execução, além da coleta e 
avaliação dos resultados objetivos, a ser realizada durante todo o processo de 
desenvolvimento do software.
Destacamos como pode ser desenvolvida uma estratégia de testes e indicamos os 
principais tipos de testes que podem ser empregados. O teste de unidade consiste 
em verificar a menor unidade funcional do projeto de software enquanto o de 
integração está associado com a arquitetura com software e busca identificar erros 
associados com interfaces. Cabe ressaltar que o teste de regressão é empregado 
na ocorrência de alterações ou acréscimos de módulo ao sistema desenvolvido ou 
em desenvolvimento.
Por fim, enfatizamos o cuidado de se empregar testes em softwares construídos 
sob a ótica da orientação a objetos, em função do encapsulamento e do controle 
hierárquico.
11
Referências
KELLY, D.; OSHANA, R. Improving Software Quality Using Statistical Techniques, 
Information and Software Technology, Elsevier, vol. 42, August 2000, p. 801–807. 
MCCONNELL, S. Best Practices: Daily Build and Smoke Test, IEEE Software, v. 13, n. 
4, p. 143-144, July 1996. 
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem 
profissional. 8. ed. Porto Alegre: AMGH, 2016. RADICE, R. High-Quality Low Cost 
Software Inspections,. [S.l.]: Paradoxicon Publishing, 2002. 
SINGPURWALLA, N.; WILSON, S. Statistical Methods in Software Engineering: 
Reliability and Risk. [S.l.]: Springer-Verlag, 1999.