Executar teste de integração hardware / software

Como pré-requisito para a execução dos procedimentos de testes, temos a análise estática que verifica a estrutura do código fonte e o atendimento de algumas métricas. As figuras seguintes apresentam os resultados desta análise.

110

Figura 5.8 – Aderência ao padrão de código MISRA-C.

Fonte: LDRA TBrun (2016).

A Figura 5.8 mostra a aderência ao padrão MISRA-C:2012, na qual podemos identificar que todos os métodos do componente de software atendem aos requisitos deste padrão de codificação. A Figura 5.9 apresenta o resultado da análise estática para a métrica Testabilidade, na qual podemos identificar que o método “sm_run” não passou. Isto em decorrência da quantidade de métodos dependentes (Fan-Out) deste, conforme podemos identificar através dos detalhes apresentados na Figura 5.10.

Figura 5.9 – Testabilidade do código.

Fonte: LDRA TBrun (2016).

111

Figura 5.10 – Detalhes da métrica Testabilidade do código.

Fonte: LDRA TBrun (2016).

A Figura 5.11, apresenta o resultado da análise estática para a métrica de qualidade de código Clareza, indicando que o código fonte apresenta informações suficientes para seu entendimento.

Figura 5.11 – Clareza do código.

Fonte: LDRA TBrun (2016).

A Figura 5.12, apresenta o resultado da análise estática para a métrica de qualidade Manutenabilidade do código fonte, na qual podemos identificar que o método “sm_run” novamente não passou.

112

Figura 5.12 – Manutenabilidade do código.

Fonte: LDRA TBrun (2016).

Através dos detalhes apresentados na Figura 5.13, identificamos que este método possui alta Complexidade Ciclomática e uma alta quantidade de Nós.

Isto se deve a natureza da estrutura do código referente a máquina de estados.

Melhorias para acomodar estas métricas poderiam impactar na segurança da máquina de estado e seu funcionamento para aplicações críticas e seguras.

Figura 5.13 – Detalhes da manutenabilidade.

Fonte: LDRA TBrun (2016).

Quanto à análise dinâmica, a Figura 5.14 apresenta o resultado para a análise de cobertura do código inicial, segundo o tipo Cobertura de Declaração segundo as métricas da norma DO-178C.

113

Figura 5.14 – Cobertura de código inicial.

Fonte: LDRA TBrun (2016).

A Figura 5.15 apresenta os detalhes da análise de cobertura de código inicial, no qual identificamos que apenas dois métodos (sm_init e sm_main) atingiram a cobertura de 100% de suas estruturas.

Figura 5.15 – Detalhamento da cobertura do código inicial.

Fonte: LDRA TBrun (2016).

A Figura 5.16 apresenta a porcentagem de cobertura identificada pela análise dinâmica nos arquivos do componente de software. Conforme mostra o quadro,

114

a média da cobertura de declaração está em 8% e a média de cobertura de ramo em 7%.

Figura 5.16 – Cobertura após a análise dinâmica inicial.

Fonte: LDRA TBrun (2016).

Os procedimentos de testes foram executados conforme podem ser vistos em ANEXO A – PROCEDIMENTOS DE TESTES, o gráfico da Figura 5.17 mostra o avanço da cobertura de código para declaração e ramo, combinados com os resultados da análise dinâmica. O resultado e o cumprimento da cobertura de requisitos e da estrutura do código são avaliados na atividade seguinte.

Figura 5.17 – Avanço da cobertura estrutural.

Fonte: Produção do autor.

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Inicial SM_PT01 SM_PT02 SM_PT03 SM_PT04 SM_PT05 SM_PT06 SM_PT07 SM_PT08 SM_PT09 SM_PT10 SM_PT11 SM_PT12 SM_PT13 SM_PT14 SM_PT15 SM_PT16 SM_PT17 SM_PT18 SM_PT19 SM_PT20 SM_PT21 SM_PT22 SM_PT23 SM_PT24 SM_PT25 SM_PT26 SM_PT27 SM_PT28 SM_PT29 SM_PT30

Stetament Coverage Branch Coverage

115 5.4.5. Análise de cobertura

Conforme ilustra o gráfico da Figura 5.17, todos os procedimentos de teste foram executados, os quais foram desenvolvidos com base nos requisitos.

Entretanto, podemos verificar que com a execução de todos os procedimentos de teste alcançou-se um índice de 100% de cobertura para o tipo Cobertura de Declaração conforme as métricas da norma DO-178C, enquanto a cobertura do tipo Cobertura de Ramo atingiu 93%.

A Figura 5.18 mostra os procedimentos que não atingiram todas as métricas para cobertura de código, enquanto a Figura 5.19 detalha estes procedimentos e a cobertura alcançada para cobertura de Declaração e Ramo.

Conforme orienta o processo proposto, isto justifica uma avaliação dos requisitos e procedimentos de testes associados para verificar se há a necessidade de alterá-los ou criar novos procedimentos de teste com base nestes requisitos.

Figura 5.18 – Cobertura de código conforme a DO-178C.

Fonte: LDRA TBrun (2016).

116

Figura 5.19 – Detalhamento da cobertura dos procedimentos.

Fonte: LDRA TBrun (2016).

Deve-se desenvolver novos procedimentos de teste para complementar os procedimentos executados, os quais atingiram a cobertura de requisito, mas não foram suficientes para atingir 100% da estrutura do código, sendo este um requisito oriundo da norma DO-178C para o nível A.

Os procedimentos de teste que devem ser desenvolvidos, estão este no escopo dos testes de baixo nível de software, uma vez que verificam estruturas de repetição e estruturas de decisão. Com isto, observamos que não há a necessidade de desenvolver os testes de integração de software.

Está customização do processo proposto, deve-se ao fato de que o software utilizado possui uma estrutura de componentes simples e não apresenta complexidade e tamanho significativos. Com isto, os testes executados ao nível de integração de hardware / software foram suficientes para cobrir a estrutura do código, com exceção de pequenas partes que devem ser concluídas com a execução de procedimento de testes em baixo nível de software.

117 5.4.6. Geração dos casos de testes

A Tabela 5.8, apresenta os procedimentos de teste complementares, os quais foram desenvolvidos para atingir a cobertura estrutural do código fonte, especialmente, do tipo cobertura de ramo.

Tabela 5.8 – Procedimentos de teste complementares.

Requisito Caso de Teste

Associado Descrição

SM_REQ37 PT_31

Verifica no estado OPERATIONAL a transição do modo OPEN para RETRACT ao detectar b_Panel

= 0, entretanto de modo complementar verifica a condição “FALSE” para o procedimento

“panelOpen”.

SM_REQ38 PT_32

Verifica no estado OPERATIONAL a não transição do modo RETRACT para CLOSE, entretanto de modo complementar verifica a condição “FALSE“

para o procedimento “retract”.

Fonte: Produção do autor.