Teste de software em RTI

O software RTI está no centro de muitas missões críticas sistemas. É claro que nossos clientes se preocupam profundamente com a confiabilidade e a qualidade de seus sistemas. Portanto, quando me encontro com os clientes e apresento o processo de desenvolvimento do RTI, discutimos as práticas de desenvolvimento, as ferramentas que usamos e o laboratório RTI IIoT. Muitos estão especialmente curiosos sobre os testes de software que fazemos na RTI e as estruturas de teste que usamos. Sempre gosto dessas conversas; estamos orgulhosos de nossa atenção aos testes. Esta postagem do blog resume os testes que realizamos.

Nosso processo de desenvolvimento e teste são comuns a todo o pacote de produtos RTI Connext. A exceção é o RTI Connext DDS CERT, que visa aplicativos que requerem certificação de segurança e segue um processo de desenvolvimento diferente. Durante o desenvolvimento, e antes de a RTI lançar qualquer novo software, executamos uma grande bateria de testes para validar a funcionalidade correta e para garantir que o software tenha um bom desempenho e escalabilidade.

Testes de unidade validar se as funções individuais funcionam conforme o esperado. Os testes de unidade são usados ​​como o mecanismo de teste de regressão principal em cada lançamento de produto. A estrutura de teste de unidade faz mais do que apenas testar funções individuais. Ele também permite um nível de teste de recurso de nó único. Em versões mais recentes, incorporamos configurações de Qualidade de Serviço (QoS) fornecidas pelo cliente como parte de nossa configuração de teste. Nossos processos são projetados para garantir o funcionamento correto em ambientes tão realistas quanto possível.

Como parte do desenvolvimento de novos recursos, criamos um plano de teste de recursos e implementamos um conjunto de testes de recursos de ponta a ponta . Esses testes são implementados por meio de um conjunto de testes personalizado ou, no caso do Connext DDS Micro, em uma nova estrutura de teste distribuída. Este ambiente de teste usa vários “executores de teste” que executam testes em máquinas diferentes e um “gerenciador de teste” que sincroniza a execução de teste entre os executores de teste. Uma linguagem de teste DDS simples foi desenvolvida para descrever os testes, e cada executor de teste executa um script, publica os resultados (PASSA / FALHA) e aguarda a execução do próximo script. O foco principal dos testes de recursos são:

• Teste APIs em nível de aplicativo e políticas de QoS DDS (prazo, disponibilidade, etc.)
• Limites de recursos de teste
• Teste o endianismo cruzado
• Teste de descoberta
• Teste de desempenho
• Garanta a estabilidade

Realizamos vários níveis de testes de interoperabilidade:

• Testamos a interoperabilidade com outros produtos RTI durante o desenvolvimento e durante o teste de instalação. Desenvolvemos um conjunto de testes automatizados de interoperabilidade. Por exemplo, o Connext 6 introduziu uma série de novos recursos em comum entre as bibliotecas Connext DDS Micro 3.0 e Connext DDS core 6.0. Geramos automaticamente milhares de combinações de configuração e validamos o comportamento correto. A interoperabilidade com versões mais antigas do RTI é testada quando determinamos, após análise, que existe o risco de interromper a interoperabilidade.
• Interoperabilidade de linguagem é feito indiretamente, uma vez que várias de nossas ferramentas são escritas em Java ou outras linguagens. Por exemplo, testamos a interoperabilidade com um aplicativo baseado em Java ao usar as ferramentas baseadas em Java da RTI, como o RTI Admin Console em combinação com aplicativos em outras linguagens.
• Um nível básico de interoperabilidade com outros fornecedores de DDS é feito regularmente nas reuniões do DDS do Object Management Group (OMG). Os fornecedores coordenam um conjunto mais aprofundado de testes para validar a segurança DDS, os tipos extensíveis e o protocolo de conexão DDS-RTPS (https://github.com/omg-dds).

Instalar testes capturar testes de integração e interoperabilidade entre vários produtos. Esses testes são executados manualmente e por meio de um conjunto de testes de instalação automatizada. Teste de instalação cobre uma ampla variedade de questões de integração e interoperabilidade:

• Instalação - Todos os arquivos estão instalados corretamente?
• Interface gráfica do usuário (GUI) - No momento, não há nenhum teste de GUI automatizado. Durante o teste de instalação manual, verificamos se as integrações funcionam corretamente:por exemplo, entre o RTI Launcher e o rtiddsgen , ou rtiprototyper .
• Documentação - A documentação correta é enviada?
• Teste de funcionalidade básica para todos os produtos usando os exemplos enviados. Para alguns produtos, percorremos todo o Guia de primeiros passos. Este teste é repetido em várias plataformas.
• testes básicos de interoperabilidade de produtos e idiomas .

Para acelerar e ampliar esses testes, temos testes de instalação automatizados para muitas funções. Os testes atuais cobrem:

• Instalação - verifique se os arquivos estão instalados corretamente.
• Executar os utilitários, incluindo rtiddsping , rtiddsspy e rtiprototyper.
• Execução de exemplos gerados por rtiddsgen em C, C ++, C ++ 03, C ++ 11, C ++ CLI, C # e Java, usando uma combinação de bibliotecas DDS estáticas / dinâmicas e de liberação / depuração.
• Executar exemplos enviados usando uma combinação de bibliotecas DDS estáticas / dinâmicas e de liberação / depuração.
• Exemplos de desempenho em C ++ e Java.
• Exemplos enviados de TCP em C.

Esses testes são executados em 80 arquiteturas diferentes, incluindo plataformas Windows, Linux, Solaris, Lynx, QNX, Darwin e VxWorks.

Temos uma variedade de testes de perfil de desempenho e memória. Criar um teste de desempenho distribuído válido e significativo é extremamente desafiador. Abordagens simples não podem controlar ou mesmo medir aproximadamente compensações em buffers, rendimento, latência, entrega em tempo real, pilhas e sistema operacional. A RTI tem ampla experiência na avaliação das métricas de desempenho que mais importam para sistemas do mundo real.

• Os testes de unidade capturam informações de desempenho e memória para funções específicas.
• Usamos nosso teste de desempenho (perfTest) para caracterizar o desempenho do Connext DDS. Investimos muito no perfTest para que ele possa fazer medições realistas. Ele pode ser usado em conjunto com outros produtos, como o Routing Service. Usamos o PerfTest para reunir nossos dados públicos de latência e taxa de transferência. Os resultados de desempenho estão disponíveis em https://www.rti.com/products/dds/benchmarks.html.
• memTest foi criado para monitorar a pegada de memória do Connext DDS Core. O Connext DDS Micro reúne informações detalhadas sobre a pegada da memória como parte dos testes de unidade.
• Outros aplicativos, como RTI Admin Console e RTI Recording Service, possuem recursos integrados de monitoramento de desempenho.

A integração contínua de PerfTest e MemTest garante que não regrediremos (além de uma porcentagem predefinida) conforme novos recursos são adicionados ao produto Connext DDS.

Testes de resistência emular cenários de longa duração. Os testes de resistência monitoram a memória heap em vários casos de uso dinâmico, como criar e excluir participantes remotos ou criar e excluir terminais remotos. A estrutura de teste de resistência também é executada com RTI Security Plugins em um caso de uso de teste fuzz onde os pacotes RTPS são alterados aleatoriamente. Os testes são executados com o Generally Available Release (GAR) mais recente.

Teste em larga escala e teste de estresse é construído propositadamente como parte do desenvolvimento de novos recursos. Por exemplo, quando introduzimos a Mobilidade de Transporte (também conhecida como mobilidade IP), criamos um conjunto de testes para emular a conexão e a desconexão de vários pontos de acesso sem fio. Quando aprimoramos a implementação de descoberta, criamos uma estrutura de teste especial para simular milhares de endpoints e verificar automaticamente se eles foram descobertos por cada aplicativo. Normalmente, esses testes não são executados novamente a cada versão, em parte devido aos requisitos de equipamento e rede. Alguns testes (por exemplo, um teste de descoberta em grande escala) são executados novamente quando fazemos alterações na implementação da descoberta.

Nosso produto é poderoso e complexo e deve funcionar em uma incrível variedade de aplicativos ainda mais complexos. Portanto, é claro que não podemos testar to

[1] [2] 下一页