OOAD - Teste e garantia de qualidade

Uma vez que o código do programa é escrito, ele deve ser testado para detectar e subsequentemente tratar todos os erros nele. Vários esquemas são usados ​​para fins de teste.

Outro aspecto importante é a adequação do propósito de um programa que verifica se o programa serve ao propósito a que se destina. A aptidão define a qualidade do software.

Testando Sistemas Orientados a Objetos

O teste é uma atividade contínua durante o desenvolvimento de software. Em sistemas orientados a objetos, o teste abrange três níveis, a saber, teste de unidade, teste de subsistema e teste de sistema.

Teste de Unidade

No teste de unidade, as classes individuais são testadas. É visto se os atributos de classe são implementados de acordo com o design e se os métodos e as interfaces estão livres de erros. O teste de unidade é de responsabilidade do engenheiro de aplicação que implementa a estrutura.

Teste de subsistema

Isso envolve o teste de um determinado módulo ou subsistema e é de responsabilidade do líder do subsistema. Envolve testar as associações dentro do subsistema, bem como a interação do subsistema com o exterior. Os testes de subsistema podem ser usados ​​como testes de regressão para cada versão recém-lançada do subsistema.

Teste de Sistema

O teste do sistema envolve o teste do sistema como um todo e é responsabilidade da equipe de garantia de qualidade. A equipe costuma usar testes de sistema como testes de regressão ao montar novos lançamentos.

Técnicas de teste orientado a objetos

Teste de caixa cinza

Os diferentes tipos de casos de teste que podem ser projetados para testar programas orientados a objetos são chamados de casos de teste de caixa cinza. Alguns dos tipos importantes de teste de caixa cinza são -

  • State model based testing - Isso abrange a cobertura do estado, cobertura da transição do estado e cobertura do caminho da transição do estado.

  • Use case based testing - Cada cenário em cada caso de uso é testado.

  • Class diagram based testing - Cada classe, classe derivada, associações e agregações são testadas.

  • Sequence diagram based testing - Os métodos nas mensagens nos diagramas de seqüência são testados.

Técnicas para teste de subsistema

As duas principais abordagens de teste de subsistema são -

  • Thread based testing - Todas as classes necessárias para realizar um único caso de uso em um subsistema são integradas e testadas.

  • Use based testing- As interfaces e serviços dos módulos em cada nível de hierarquia são testados. Os testes começam nas classes individuais aos pequenos módulos compostos por classes, gradualmente para os módulos maiores e, finalmente, todos os subsistemas principais.

Categorias de teste de sistema

  • Alpha testing - Isso é realizado pela equipe de testes da organização que desenvolve o software.

  • Beta testing - Isso é realizado por um grupo seleto de clientes cooperantes.

  • Acceptance testing - Isso é realizado pelo cliente antes de aceitar as entregas.

Garantia de Qualidade de Software

Qualidade de Software

Schulmeyer e McManus definiram a qualidade do software como “a adequação para o uso do produto de software total”. Um software de boa qualidade faz exatamente o que deve fazer e é interpretado em termos de satisfação da especificação de requisitos definida pelo usuário.

Garantia da Qualidade

A garantia de qualidade de software é uma metodologia que determina até que ponto um produto de software é adequado para uso. As atividades incluídas para determinar a qualidade do software são -

  • Auditing
  • Desenvolvimento de padrões e diretrizes
  • Produção de relatórios
  • Revisão do sistema de qualidade

Fatores de Qualidade

  • Correctness - A correção determina se os requisitos de software são atendidos de forma adequada.

  • Usability - A usabilidade determina se o software pode ser usado por diferentes categorias de usuários (iniciantes, não técnicos e especialistas).

  • Portability - A portabilidade determina se o software pode operar em diferentes plataformas com diferentes dispositivos de hardware.

  • Maintainability - A capacidade de manutenção determina a facilidade com que os erros podem ser corrigidos e os módulos podem ser atualizados.

  • Reusability - Reutilização determina se os módulos e classes podem ser reutilizados para desenvolver outros produtos de software.

Métricas Orientadas a Objetos

As métricas podem ser amplamente classificadas em três categorias: métricas do projeto, métricas do produto e métricas do processo.

Métricas de Projeto

As métricas do projeto permitem que um gerente de projeto de software avalie o status e o desempenho de um projeto em andamento. As seguintes métricas são apropriadas para projetos de software orientado a objetos -

  • Número de scripts de cenário
  • Número de classes principais
  • Número de aulas de apoio
  • Número de subsistemas

Métricas do Produto

As métricas do produto medem as características do produto de software que foi desenvolvido. As métricas de produto adequadas para sistemas orientados a objetos são -

  • Methods per Class- Determina a complexidade de uma aula. Se todos os métodos de uma classe são considerados igualmente complexos, então uma classe com mais métodos é mais complexa e, portanto, mais suscetível a erros.

  • Inheritance Structure- Sistemas com várias pequenas redes de herança são mais bem estruturados do que sistemas com uma única grande rede de herança. Como regra geral, uma árvore de herança não deve ter mais de 7 (± 2) níveis e a árvore deve ser balanceada.

  • Coupling and Cohesion - Módulos de baixo acoplamento e alta coesão são considerados mais bem projetados, pois permitem maior reutilização e manutenção.

  • Response for a Class - Mede a eficiência dos métodos que são chamados pelas instâncias da classe.

Métricas de Processo

As métricas de processo ajudam a medir o desempenho de um processo. Eles são coletados em todos os projetos por longos períodos de tempo. Eles são usados ​​como indicadores para melhorias de processo de software de longo prazo. Algumas métricas de processo são -

  • Número de KLOC (Kilo Lines of Code)
  • Eficiência de remoção de defeitos
  • Número médio de falhas detectadas durante o teste
  • Número de defeitos latentes por KLOC