Visão Geral do Processo Praticado

69

4 PROCESSO DE VERIFICAÇÃO POR TESTES BASEADO NA

70

BlackBurn (2004), apesar da automação, esses testes ainda precisam ser criados manualmente.

Dito isto e considerando o contexto de sistemas críticos, softwares embarcados demandam um número elevado de testes, podendo conter centenas ou até milhares de casos de testes. Esses, por sua vez, também são extensos, possuem muitas variáveis de entrada / saída e geram um alto volume de dados.

Uma consideração de substancial importância é a definição de uma abordagem para a realização dos testes, isto impacta no planejamento, na efetiva arquitetura do conjunto de casos de testes e, ainda, na maneira que pequenos componentes serão integrados.

Segundo Myers et al. (2012), a abordagem empregada no processo de testes implica a definição dos casos de teste, a ferramenta que deve ser usada, a ordem em que os componentes são testados e, ainda, o custo de localizar e reparar os erros.

Figura 4.1 – Diagrama do modelo em V.

Fonte: Adaptado de Jorgensen (2002).

A priori, abordagens de testes dividem os esforços e também refletem o ciclo de vida de desenvolvimento utilizado. Um modelo de processo de

71

desenvolvimento aplicado atualmente e bastante difundido no desenvolvimento de sistemas e software críticos é o modelo em V, como mostra a Figura 4.1.

O modelo em V representa as atividades do ciclo de vida do desenvolvimento de um software, desde a especificação de requisitos até a integração de sistema, com variantes que podem representar até a fase de manutenção. O modelo é considerado como uma extensão do modelo cascata, apresentando uma abordagem na fase de testes chamada Bottom-Up.

Nesta abordagem, são testados em um primeiro momento os itens de mais baixo nível e o foco das atividades de teste caminha na hierarquia estrutural do sistema até alcançar os componentes de mais alto nível.

Portanto, após todas as atividades que precedem os testes, como planejamento e desenvolvimento de stubs e drivers, a aplicação das técnicas de teste inicia-se nas unidades de software. Na sequência, são aplicados os testes de integração dos componentes de software e findam-se nos testes de sistema ou funcionais.

Contudo, o modelo em V apresenta algumas desvantagens como aponta vector software (2014): alta demanda de esforço aplicado ao desenvolvimento de drivers para testes, risco de desenvolvimento de casos de testes baseados no código desenvolvido, e a identificação tardia de potenciais defeitos no software.

Figura 4.2 – Desenvolvimento tradicional de software.

Fonte: Adaptado de Vector Software (2014).

72

A Figura 4.2 apresenta uma visão diferente das atividades de teste presentes no modelo em V e, também, ilustra como o processo de verificação por testes avança no escopo do produto de software como também chama atenção para a cobertura de código durante os testes.

Entre as normas citadas neste trabalho, segundo a E-ST-40C, as normas do conjunto ECSS não impõem a adoção de um modelo de ciclo de vida de desenvolvimento específico. Entretanto, o encadeamento dos processos de Engenharia de Software e revisões formais (ver Figura 2.3 na seção 2.6.2 ) naturalmente remetem à adoção do modelo cascata.

Podemos concluir que estas normas do conjunto ECSS preconizam a prática e a adoção um ciclo de vida similar ao modelo cascata, e também que seu processo de verificação segue a abordagem Bottom-Up para os testes, ainda que explicitamente não os façam na norma, como habitualmente acontece no meio aeroespacial.

A norma do setor aeronáutico DO-178B, versão que precede a atual DO-178C, propunha o uso de um ciclo de vida de desenvolvimento iterativo devido ao conceito praticado de desenvolvimento incremental das funções de sistema, complexidade e desenvolvimento de requisitos.

A Figura 4.3 ilustra o processo de verificação desta norma apresentando as atividades existentes, na qual é possível identificar a sugestão de uma abordagem Bottom-Up, com a aplicação dos testes iniciando a partir dos testes de baixo nível (Low-Level Tests), continuando com os Testes de Integração de Software (Software Integration Tests) e finalizando com os Testes de integração de Hardware/Software (Hardware/Software Integration Tests), embora não exista claramente em seu conteúdo um viés sobre a abordagem a ser praticada, diferentemente de como se apresenta este mesmo processo em sua atual versão (DO-178C).

Myers et al. (2012) menciona que a grande quantidade de unidades e componentes de software implicam na demanda de um grande número de

73

drives para a execução dos testes, apesar da baixa complexidade e facilidade de criação de cada um destes.

Figura 4.3 – Processo de verificação por testes segundo DO-178B.

Fonte: Adaptado de RTCA-DO-178B (1992).

Ainda sobre os testes em unidades de software, segundo Vector Software (2014), para criar uma suíte de testes com alcance e cobertura de código perto de 100% seria necessário gerar uma linha de código de teste (drivers, stubs e dados de teste) para cada linha de código do software a ser testado.

No entanto, como já mencionado, ferramentas computacionais minimizam uma considerável parte do esforço envolvido na preparação e, principalmente, aplicação de um efetivo conjunto de testes. Blackburn (1999) também acrescenta que tais ferramentas são valiosas para reduzir a prevenção de erros manuais no processo de teste, enquanto libera os desenvolvedores a se concentrar na tarefa mais complexa para o desenvolvimento, especificação e análise.

74

Contudo, verificamos que o desempenho das atividades de teste e a efetividade do processo de verificação demandam o auxílio de ferramentas semiautomáticas.

Quanto às abordagens dos processos de verificação apresentados nesta seção, eles ilustram os processos praticados pela indústria de software, especialmente, a indústria espacial através do conjunto ECSS.

Porém, verificamos que as normas desse conjunto, aqui representada pela norma E-ST-40C, no que tange aos processos de desenvolvimento de software, possuem uma desatualização ante, por exemplo, a norma aeronáutica DO-178C. Isto ocorre pois não tratam aspectos como prática de novas abordagens e incorporação de novas tecnologias de desenvolvimento, quanto a qualificação de ferramentas abordado na norma aeronáutica e ausente na espacial, isto justificativa a ausência da certificação como um exigência.

De acordo com Blackburn (1998), o mercado impulsiona as companhias a definirem ou/e adotarem novas abordagens para reduzir custos, contribuindo também para a melhoria dos processos, principalmente, quando buscamos entregar produtos de qualidade ou galgamos uma certificação.