Metodologia de geração de teste para sistemas embarcados – uma experiência no INPE Ana Maria Ambrosio 06/out/2007

Tópicos Visão geral do INPE Metodologia de teste CoFI Aplicação da CoFI no projeto QSEE: lições aprendidas e resultados obtidos

INPE Instituto Nacional de Pesquisas Espaciais Subordinado ao Ministério de Ciência e tecnologia - MCT Missão: Produzir ciência e tecnologia nas áreas espacial e do ambiente terrestre e oferecer produtos e serviços singulares em benefício do Brasil.

Instalações do INPE

Principais áreas de atuação Laboratório de Integração e Testes Ciências espaciais e atmosféricas Previsão de tempo e estudos climáticos Engenharia e Tecnologia Espacial Observação da Terra Centro de rastreio e controle de satélites

Áreas favorecidas pelo programa espacial brasileiro no contexto do INPE energia agricultura ecosistemas clima saúde biodiversidade desastres

Missões espaciais realizadas MECB – Missão espacial completa brasileira SCD1/93 SCD2/98 SCD2A/97 CBERS – China-Brazil Earth Resources Satellite CBERS3 - CBERS1/99 CBERS2/03 CBERS4 - CBERS2B/07 Satélites científicos e tecnológicos Mirax - SACI-1/99 SACI-2/99 Satec/03

Metodologia de geração de teste para sistemas embarcados COFI Conformidade e Falhas Injetáveis

Motivação “Os excelentes resultados de geração automática de teste de software, apresentados pela academia ainda não estão sendo adotados na indústria. “ Fonte: Lai, 2002

Condado ConDado Seqüência abstrata de casos de teste Geração automática de teste a partir de FSM/EFSM inicial(Idle) trans(Idle,t1,WCon,L0,Ln):- transmitu(‘SENDr',L2,Ln). receiveu(‘CR',L0,L1), trans(WCon,t2,C,L0,Ln):- transmit(‘CC’,L2,Ln). receiveu(‘SEND',L0,L1), ... ConDado Seqüência abstrata de casos de teste senddata (U, SENDrequest) recdata (L, CR) senddata (L, CC) recdata (U, SENDconfirm) senddata (U, DATArequest, “xHn*e”, 2, 14) recdata (L, DT) senddata (L, ACK) recdata (L, DISrequest) senddata (L, DISrequest) recdata(U, DISindication)

Dificuldades teste de conformidade com geração automática: baseada em métodos formais, requer um modelo formal completo que represente o comportamento do software  difícil de ser obtido pode gerar um número intratável de casos de testes

CoFI- Conformidade e Falhas Injetáveis Objetivo: Sistematizar a criação de casos de testes Atender necessidades de teste de software em aplicações espaciais Fazer uso das técnicas e ferramentas de geração automática de teste a partir de FSM/EFSM Incluir a técnica de injeção de falhas A nossa proposta foi então definir uma metodologia, como uma forma de sistematizar a criação de testes; que atendesse necessidades de teste de software em aplicações especiais; que fizesse uso das ferramentas de geração automática de teste e de injeção de falhas, já desenvolvidas. A injeção de falhas é conveniente para validação de software a bordo de satélites devido à radiação sofrida pelas equipamentos no ambiente espacial (A região de mais intensa radiação no espaço é chamada cinturão de Van Allen, consta de uma zona de partículas altamente carregadas, localizada em altas altitudes no campo magnético da Terra. James A. Van Allen foi quem as descobriu em 1958. (Enciclopédia Britânica)

Visão geral da CoFI Descrição formal do software Passos de transformação da descrição do software diagramas UML Especificações textuais Descrição formal do software Seqüência Teste Arquitetura de teste Casos de teste Casos de falha

Seqüência de teste CoFI Passos da CoFI 1. SERVIÇO /propósitos de teste Definição do contexto da IUT 2. Usuários, meio físico 4. Casos de uso 3. Entradas, Saídas, Arq. Teste, PCOs CENÁRIOS NORMAIS CENÁRIOS EXCEPCIONAIS 5. Diagrama Seqüência Normal Transformações 6. Diagrama Estados Normal 8. Matriz de Transições 9. Modelo de Falhas 10. Diagrama Seqüência Excepcional 11. Diagrama Estados Excepcional Geração automática 7. Deriva casos de teste 12. Deriva casos de falha Seqüência de teste CoFI

Decomposição do SuT na CoFI Por serviço (ou por propósito de teste), que por sua vez é dividido em cenários Por tipo de comportamento: normal; exceções especificadas, caminhos furtivos (entradas inoportunas) tolerância a falhas (falhas provocadas pelo hardware) Para modelar o comportamento do software a ser testado, para fins de geração automática de teste, faz-se 2 tipos de decomposição: por serviço ( ou grande função ou propósito de teste, no caso de software em que o conceito de serviço não é bem estabelecido); por tipo de comportamento que o software frente as diversas entradas possíveis: normal ( frente a entradas corretas, esperadas) Exceções especificadas (frente a entradas excepcionais especificadas) Caminhos furtivos (entradas inoportunas, i,é, entradas corretas em momentos não esperados) Tolerãncia a falhas (as entradas são falhas de hardware – entradas incorretas e não esperadas Os trÊS ÚLTIMOS TIPOS SERVEM PARA MEDIR A ROBUSTEZ.

Modelos parciais do comportamento

Aplicação da CoFI no projeto QSEE – Qualidade de Software Embarcado em aplicações Espaciais : lições aprendidas e resultados obtidos

Projeto QSEE Qualidade de Software Embarcado em aplicações Espaciais Objetivos: Transferência de tecnologia do INPE para a indústria nacional de software Uso das normas ECSS pela Ciências Espaciais e Atmosféricas (CEA/INPE) no desenvolvimento de software de cargas úteis de satélite Desenvolvimento de um processo de aceitação de software para o INPE apoiado na abordagem de Verificação e Validação Independente de Software

SWPDC - aplicação em teste software embedded in an Payload Data handling Computer that controls scientific experiments on-board of a MIRAX satellite under development at INPE C language; Labview Main functions: Scientific data aquisition housekeeping, test & diagnostic data preparation error recognition and handling mechanism for commmunication, memory and processor failures Communication with OBDH, event processors, thermistors

Ambiente de teste do SWPDC

QSEE-TAS EPPs Simulator Restrições, Facilidades de Teste Modelo de Watchdog simulation Mem. error Restrições, Facilidades de Teste Modelo de falhas de hardware: memória, processador comunicação SWPDC embarcado Na placa do PDC

Ambiente de teste no INPE

Criação dos modelos de estado Serviços Especificação Tipos de comportamento (Norm) Normal (SExc) Specified exception (SPat) Sneak path Fault Tolerance (M&Pr) Entradas/Saídas Ambiente de teste Modelos Nomes dos eventos Comandos para o injetor de falhas Tipos de falhas de hw, parâmetros, temporizadores

Tipos de falhas x entradas/saídas Dados corrompidos CmdTurnOnEPP2,CKS{badcks} CmdPrepMemoryDumpData,Mem,18,EndI,8000,EndF,FFFF Comando repetido CmdTransTestData_2X Comando fora-de-ordem Comando truncado CmdTurnOffEPP1,NU,{sup} Comando atrasado ou adiantado ObsEndT Erro simples ObsSingleError Erro duplo ObsDoubleError Primeira ocorrência da falha de processador ObsErrorProc1 Segunda ocorrência da falha de processador ObsErrorProc2 Comunicação Memória Processador

S4 - serviço Dados de teste – M&Pr CmdTurnOnPDC ObsStartTimer60s ObsEnd60s CmdTurnOnEPP1 RspCmdRec CmdTurnOnEPP2 ObsStartTimer30s ObsEnd30s ObsErrorProc1 ObsWriteHKReport CmdPrepTestData ObsStarTimer10s ObsDoubleError ObsEnd10s CmdTransmTestData RspTestData,CSR,1 ObsSingleError ObsCorrectError ObsErrorProc2 ObsReset CmdTransmCientData RspNoData ObsTurnOffPDC ObsPDC_Off

Derivação de casos de teste e casos de falhas MME para edição Modelos Condado para geração Arquivo de saída CTest.seq

Arquivo com casos de teste de uma máquina File.seq

Resultados 11 serviços foram definidos 97 modelos gerados 770 casos de teste 51 erros

Mudança de modo de operação S8 Carga e execução de programa 15 Serviços Modelos Norm SExc SPat Com M&Pr Total S1 Inicialização 2 1 6 S2 Dados Científicos 7 S3 Dados de Housekeeping 3 11 S4 Dados de Teste 4 12 S5 Dados de Diagnóstico 14 S6 Descarga de Memória 5 16 S7 Mudança de modo de operação S8 Carga e execução de programa 15 S9 Sintaxe de mensagem do OBDH S10 Sintaxe de mensagem dos EPPs S11 Comandos Especiais 10 24 22 13 97

51 erros 770 casos Casos de falha 319 12 39 451 normais Casos de falha Tipo de falha de hw Casos de falha Erros Comunicação 283 31 Processador 80 5 Memória 88 3 Total 451 39

Comentários sobre os resultados do projeto QSSE Os resultados surpreenderam com 51 erros ainda encontrados Considerando que a validação se deu sobre um software fornecido por uma empresa Brasileira de Software proeminente, desenvolvido por uma equipe competente sob rigorosas regras de garantia de qualidade 45% erros de código 33% erros de não-conformidade nos documentos 22% ambos Considerando que todas as não-conformidades entre código e documentos foram computadas. Atenção às falhas é mais efetivo que no comportamento normal para a validação

Lições aprendidas – CoFI em um caso real O esforço de criar os modelos foi compensado pela superior organização dos testes alcançada com a aplicação da metodologia CoFI em comparação com o projeto dos testes de forma ad-hoc Os modelos voltam a atenção dos testadores para falhas e exceções que podem ocorrer durante a operação do software levando ao projeto de situações que os desenvolvedores normalmente não pensam Os casos de teste gerados pela Condado são auto-contidos, i.é, cada caso pode ser executado independentemente, desta forma o veredicto não depende da ordem de execução dos casos e facilita a re-execução.

Comentários sobre a metodologia de teste CoFI A metodologia CoFI reduz a distância entre a prática (geração de teste a partir de uma especificação textual) e o uso de métodos formais (especificação em autômatos) É de fácil aprendizagem e permite automação dos passos, pois usa modelos UML Possibilita reuso em teste, porque a geração parte da especificação Orienta a definição de experimentos determinísticos para Injeção de Falhas

Estação Espacial Internacional Construção 1998 - 2005 Sputnik – 1º satélite artificial a orbitar a terra - USRR 1957 ana@dss.inpe.br