"MÉTODO, SISTEMA E APARELHO PARA TESTAR SOFTWARE, E, DISPOSITIVO SOB TESTE"
DESCRIÇÃO
CAMPO TÉCNICO
A invenção está relacionada a teste de software e, em particular, a um método para sondagem dinâmica de software. DESCRIÇÃO DE ARTE RELACIONADA
Entre fomentadores de software, um dos requisitos mais importantes é para o software ser confiável. Confiabilidade se refere à habilidade de software operar sem falha por uma duração especificada de tempo em um ambiente especificado. Para assegurar um nível de confiabilidade suficientemente alto, software deve ser testado completamente e depurado antes de liberação. Normalmente, o programa de software inteiro é testado como um todo, como também os componentes funcionais individuais (por exemplo, chamadas de função, sub-rotinas) que compõem o programa de software. Tipicamente, vetores de teste são gerados contendo uma série de valores para as variáveis que são requeridas pelo software e/ou um ou mais componentes funcionais. Os valores de variável são escolhidos para representar vários tipos de condições de uso e ambientes nos quais o software é pretendido ser corrido. Os vetores de teste são então aplicados ao software e/ou um ou mais componentes funcionais, e os valores de variável são observados e registrados.
Um tipo de teste que é executado freqüentemente é chamado análise de regressão, ou às vezes teste de verificação. Análise de regressão envolve o re-teste seletivo de software que foi modificado a fim de fixar problemas conhecidos. O re-teste seletivo é executado a fim de assegurar que os problemas identificados foram fixados, e que nenhum outro componente funcional previamente operante falhou como resultado das reparações. Este tipo de teste é basicamente uma medida de controle de qualidade para
assegurar que o código modificado ainda obedeça seus requisitos especificados e que qualquer código inalterado não foi afetado pela atividade de manutenção.
Uma característica importante em análise de regressão especificamente e em teste de software em geral é a habilidade para observar os valores de variável resultando dos vetores de teste. Tentativas anteriores para observar os valores de variável de software e/ou componentes funcionais disso envolvidos fixando manualmente pontos de ruptura e outras armadilhas no próprio código fonte. Mais recentemente, ferramentas de desenvolvimento de software tal como 'Code Composer Studio™' de Texas Instruments e LabVIEW™ de National Instruments incluem sondas de software que podem ser inseridas no código sob teste. As sondas de software permitem as variáveis no código sob teste serem observadas em tempo real quando o software é executado. Porém, estas ultimas soluções só são baseadas em obter os valores de variável fora do código sob teste (por exemplo, assim elas podem ser analisadas). Elas não permitem aos valores de variável serem mudados durante a execução do software. Em outras palavras, estas sondas de software existentes são só sondas de mão única ou unidirecionais visto que os dados são permitidos fluir só do código sob teste para o sistema de teste. Elas não permitem a direção de transferência de dados ser invertida de forma que os dados fluam do sistema de teste no código sob teste.
Outras sondas são bidirecionais visto que as sondas permitem a dados fluírem do código sob teste para o sistema de teste e vice-versa. Um exemplo de uma sonda bidirecional pode ser achado no comumente possuído Pedido Serial US N0 10/428733, intitulado "BI-DIRECTIONAL PROBING OF SOFTWARE", depositado em 1 de maio de 2003, que está por este meio incorporado por referência.
Em soluções existentes, porém, ambas sondas unidirecionais e bidirecionais operam em modo estático, significando que as sondas precisam ser determinadas durante o tempo de compilação do software sob teste. Se a sonda não for introduzida durante o tempo de compilação, o único modo para introduzir a sonda é reconstruir o software sob de teste, que é indesejável. Também, até mesmo enquanto uma sonda está inativa, ela ainda consome uma quantidade pequena de memória, que pode adicionar a uma quantidade significante de memória para um sistema inteiro.
Portanto, há uma necessidade por uma sonda que possa ser instalada no software sob teste durante tempo corrido em vez de tempo de compilação, tal que as sondas possam ser introduzidas e removidas como precisado e só sondas instaladas consomem memória.
SUMÁRIO DA INVENÇÃO
Um método de testar software tendo uma pluralidade de módulos de software nele é provido aqui. O método inclui executar o software, incluindo a pluralidade de módulos de software usada pelo software e identificar dois da pluralidade de módulos de software que estão ligados diretamente um ao outro. Uma sonda é inserida entre os dois módulos de software identificados enquanto o software está sendo executado. A sonda produz dados sendo trocados entre os dois módulos de software identificados a um sistema de teste por esse meio para extrair dados do software.
De acordo com outra concretização da presente invenção, um sistema para testar software é provido. O sistema inclui um software sob teste, o software tendo uma pluralidade de módulos de software nele. Pelo menos um aplicativo é acoplado ao software sob teste. Uma unidade de testador controla o pelo menos um aplicativo, tal que a unidade de testador seja configurada para fazer o pelo menos uma aplicativo executar o software sob teste, incluindo qualquer módulo de software usado pelo software sob teste. A unidade de testador também é configurada para identificar dois dos módulos de software usados pelo software sob teste que estão em comunicação direta um ao outro, inserir uma sonda entre os dois módulos de software μ-
identificados enquanto o software sob teste está sendo executado, e produzir dados sendo trocados entre os dois módulos de software identificados pela sonda por esse meio para extrair dados do software sob teste.
De acordo com ainda outra concretização da presente invenção, um método de testar software tendo uma pluralidade de módulos de software nele é provido. O método inclui pedir uma sonda para o software enquanto o software está sendo executado e obter uma pega para a sonda do gerente de componente. Dois da pluralidade de módulos de software a serem testados são identificados e os dois módulos de software identificados ligados diretamente um ao outro. A pega da sonda é inserida entre os dois módulos de software identificados.
De acordo com outra concretização da presente invenção, um aparelho para testar software tendo uma pluralidade de variáveis de dados e argumentos de função nele é provido. O aparelho inclui uma unidade de processamento central e uma unidade de armazenamento conectada à unidade de processamento central. A unidade de armazenamento armazena instruções legíveis por computador para instruir a unidade de processamento central para executar o software e identificar um local de endereço para pelo menos uma das variáveis ou argumentos usados pelo software. A unidade de armazenamento também armazena instruções legíveis por computador para instruir a unidade de processamento central para inserir dinamicamente uma sonda no local de endereço e produzir quaisquer dados armazenados no local de endereço à unidade de processamento central por esse meio para monitorar os dados.
De acordo com ainda outra concretização da presente
invenção, um dispositivo sob de teste é provido. O dispositivo sob teste inclui uma pluralidade de módulos de software ligados em uma cadeia de software e um gerente de componente acoplado aos módulos de software e para administrar os módulos de software. Os módulos de software são adaptados %0
para serem separados e realinhados durante uso, tal que uma sonda possa ser inserida entre dois da pluralidade de módulos de software durante operação do software.
De acordo com outra concretização da presente invenção, um método de testar software tendo uma pluralidade de módulos de software nele é provido. O método inclui criar uma sonda de software e receber um identificador de sonda, o identificador de sonda identificando a sonda de software. Um testador é instruído para inserir ou remover a sonda de software na pluralidade de módulos de software. Uma confirmação que a sonda de software foi inserida ou removida também é recebida.
De acordo com ainda outra concretização, um método de testar software tendo uma pluralidade de módulos de software nele é provido. O método inclui obter uma pega para uma sonda e colocar um identificador de sonda em um banco de dados de sonda. O identificador de sonda é retornado a um computador pessoal. Uma instrução para inserir ou remover a sonda na pluralidade de módulos de software é recebida e a pluralidade de módulos de software é re-arranjada. O estado da sonda na pluralidade de módulos de software é confirmado e uma mensagem confirmando a colocação da sonda ao computador pessoal é transmitida. BREVE DESCRIÇÃO DOS DESENHOS
Um melhor entendimento da invenção pode ser tido por referência à descrição detalhada seguinte quando tomada junto com os desenhos acompanhantes, em que:
Figura Ia ilustra um ambiente de teste de software exemplar de acordo com concretizações da invenção;
Figura Ib ilustra um esquemático de uma sonda dinâmica inserida entre módulos de software da Figura la;
Figura 1 c ilustra um esquemático dos módulos de software da Figura Ia sem uma sonda inserida entre eles; Figura 2 ilustra um método de implementar a sonda de software dinâmica de acordo com concretizações da invenção; e
Figura 3 ilustra um sistema exemplar no qual a sonda de software bidirecional de acordo com concretizações da invenção pode ser implementada.
DESCRIÇÃO DE CONCRETIZAÇÕES ILUSTRATIVAS DA
INVENÇÃO
Como aludido acima, sondas unidirecionais e bidirecionais existentes carecem de flexibilidade visto que as sondas precisam ser determinadas durante o tempo de compilação do software sob teste (SUT). Caso contrário, o único modo para introduzir uma sonda é reconstruir o SUT inteiro. Também, até mesmo se não ativada, cada sonda consome uma quantidade pequena de memória e pode portanto adicionar a uma quantidade considerável dado o número de sondas que podem precisar ser usadas.
Concretizações da invenção provêem um método e sistema para testar software usando sondas dinâmicas. As sondas dinâmicas da invenção não precisam ser inseridas durante a compilação do software, mas ao invés são capazes de serem inseridas durante o tempo corrido do software. Introduzir uma sonda em um SUT durante tempo corrido tem várias vantagens, incluindo limitar a inserção a só essas sondas que são realmente precisadas, por esse meio diminuindo o uso de memória cara e ciclos de CPU. Ademais, é possível introduzir uma sonda essencialmente em qualquer lugar no SUT onde há uma cadeia de comunicação (cadeia de COM). As sondas dinâmicas assim melhoram grandemente a flexibilidade ambos em teste e depuração do SUT. Ademais, as sondas são bidirecionais, significando que elas permitem a dados fluírem ambos do SUT para o sistema de teste e vice- versa.
Em uma concretização preferida, o software sendo sondado também é dinâmico visto que pode ser ligado durante tempo corrido a outros módulos de software já existentes. A ligação dinâmica permite a uma cadeia inteira de módulos de software ser ligada junta ou "construída" durante tempo corrido.
Dentro da plataforma, um mecanismo de ligação é usado para executar a ligação dos módulos de software. Outros mecanismos de ligação semelhantes incluem, por exemplo Microsoft COM e outros sistemas de COM de proprietário. Enquanto estes mecanismos de ligação usam um tipo de software de controle para operar a ligação atual, os módulos de software específicos que são ligados, e a ordem na qual eles são ligados, são ditados pelos aplicativos de cliente que correm em cima da plataforma. Se o usuário quiser mudar o modo que os módulos de software são encadeados, ele deve fazer assim pelos aplicativos sobre a plataforma. Portanto, o software de controle tem que exportar essa funcionalidade aos aplicativos de cliente pela plataforma.
De acordo com concretizações da invenção, uma cadeia de módulos de software operando em um fluxo de dados pode ser se "separada" e uma sonda de plataforma de verificação e teste dinâmico (TVP) introduzida entre eles. Como usado aqui, os termos "ligação" e "cadeia" se referem à habilidade dos módulos de software trocarem dados e caso contrário se comunicarem entre si. Para criar uma sonda dinâmica, o aplicativo de cliente, no computador pessoal (PC), cria a sonda dinâmica com o banco de dados de TVP, que retorna um ID único. O banco de dados de TVP então pede ao gerente de componente uma pega ou ligação à sonda dinâmica. O aplicativo de PC de cliente então instrui o TVP para instruir o software de controle para re-arranjar a cadeia de módulo de software de forma que a sonda dinâmica faça parte da cadeia no local desejado. Uma vez no lugar, a sonda dinâmica é operada pelo sistema de teste da mesma maneira como as sondas estáticas mencionadas acima. Depois disso, o usuário do sistema de teste pode injetar dados dentro ou dados de sonda fora da nova sonda dinâmica. Se uma sonda dinâmica for para ser removida, o procedimento descrito acima é executado ao contrário.
Em algumas concretizações, os módulos de software podem ter interfaces que são desconhecidas à sonda dinâmica. Portanto5 a fim de introduzir uma sonda dinâmica entre tais módulos de software, a interface da sonda dinâmica é preferivelmente projetada para ser uma interface geral, como explicado ademais abaixo. A interpretação dos dados é então deixada ao aplicativo de cliente que está correndo no PC.
Se referindo primeiro à Figura la, um sistema de teste de software 1OO é mostrado no qual a técnica de sondagem dinâmica da presente invenção pode ser usada. O sistema de teste de software 100 está conectado a um SUT 102 por pelo menos uma sonda dinâmica de software 104. A pelo menos uma sonda dinâmica de software 104 pode ser identificada por seu ID de sonda único, por exemplo, PID 1, PID 2, PID 3, e assim por diante. A geração dos IDs de sonda será descrita abaixo em mais detalhe com respeito à Figura 2.
A sonda dinâmica 104 está conectada a uma plataforma de verificação e teste (TVP) 106 (que pode ser uma TVP de proprietário ou um TVP padrão conhecida a pessoas tendo habilidade ordinária na arte). A TVP 106, por sua vez, está acoplada a outros módulos de teste, tal como, mas não limitado a, um mux de depuração 108. O mux de depuração 108, por sua vez, está conectado a um computador pessoal (PC) 110. O mux de depuração 108 recebe todas as comunicações do PC IlOe transfere as comunicações à TVP 106. O PC 110 controla todo o teste.
O SUT 102 inclui vários módulos de software separados 102a, 102b, 102c, 102d, quatro de quais são ilustrados na Figura 1. Estes módulos de software 102a, 102b, 102c, 102d incluem uma pluralidade de variáveis de dados e argumentos de função, tais como, mas não limitado a, codificadores, equalizadores, filtros gerais, e similares. Os módulos de software 102a, 102b, 102c, 102d devem ser capazes de serem ligados dinamicamente um ao outro. Em outras palavras, os módulos de software 102a, 102b, 102c, 102d são capazes de serem manobrados durante o tempo de compilação. Isto permite a cadeia de módulos de software 102a, 102b, 102c, 102d ser rompida à parte durante tempo corrido.
A sonda dinâmica 104 é capaz de ser colocada dinamicamente entre quaisquer destes módulos de software 102a, 102b, 102c, 102d. Colocar dinamicamente a sonda dinâmica 104 significa que a sonda dinâmica 104 pode ser inserida entre os módulos de software 102a, 102b, 102c, 102d durante o tempo corrido em vez do tempo de compilação do software 102. A sonda dinâmica 104 também pode ser removida durante tempo corrido. Permitindo a colocação e remoção da sonda dinâmica 104 durante tempo corrido, sondas estranhas não são precisadas e espaço de memória pode ser conservado.
Em algumas concretizações, a sonda dinâmica 104 pode ser inserida entre módulos de software com interfaces tendo múltiplos parâmetros. Para estes módulos, a sonda dinâmica 104 preferivelmente tem uma interface geral. Uma interface geral é uma que só requer dois parâmetros: o comprimento dos dados e o ponteiro para os dados. Outros parâmetros, tais como a taxa de bit e a freqüência de amostragem podem ser ocultos nos dados. A sonda não precisa ter estes outros parâmetros mais específicos.
A interface geral é preferivelmente projetada para permitir, entre outras coisas, dados serem extraídos, e injetados nos módulos de software 102a, 102b, 102c, 102d. A interface geral preferivelmente também inclui o ID de sonda e um ponteiro para os dados que são para serem injetados, ou extraídos dos módulos de software 102a, 102b, 102c, 102d. A interface geral preferivelmente ademais inclui um modo para facilitar a criação e apagamento da sonda 104.
Se referindo agora à Figura lb, uma ilustração da sonda dinâmica 104 inserida entre os módulos de software 102a e 102b é provida. Como ilustrado, a sonda 104 está inserida entre os dois módulos de software 102a e 102b e se comunica com a TVP 106. A TVP 106 também está acoplada ao MUX de Depuração 108, como descrito acima junto com a Figura la. O MUX de Depuração 108 também está acoplado ao PC 110.
Figura Ic ilustra o módulos de software 102a, 102b com a sonda 104 removida. Como mostrado, o módulos de software 102a, 102b estão acoplados um ao outro.
Se referindo agora à Figura 2, um método para registrar uma sonda dinâmica de acordo com uma concretização da invenção será descrito. Como mostrado, o PC 110 cria a sonda com a TVP 106 (etapa 202). A TVP 106 então se comunica com o gerente de componente 118 para obter a pega à interface de sonda (etapa 204). O gerente de componente 118 então envia a pega à TVP 106 (etapa 206), que então coloca a sonda de TVP 104 no banco de dados (etapa 207). Na etapa 208, a TVP 106 então retorna o ID de sonda para o PC 110.
O PC 110 então envia uma instrução à TVP 106 sobre se a sonda deveria ser inserida ou removida na cadeia de software na etapa 210. A TVP 106 então remete a instrução para o software de controle 116, que re- arranja a cadeia de software (etapa 212). O software de controle 116 confirma que a sonda está na cadeia de software (ou foi removida) na etapa 214. Na etapa 216, a TVP 106 então se comunica com o PC 110 sobre a colocação (ou remoção) da sonda.
A técnica de sondagem dinâmica da presente invenção pode ser implementada em qualquer sistema de teste. Figura 3 mostra um sistema de teste exemplar 300 para implementar a técnica de sondagem dinâmica. O sistema de teste 300 inclui um testador 302 e um dispositivo sob teste 304 que estão em comunicação entre si. O testador 302 é um computador típico tendo vários componentes funcionais, incluindo uma CPU 306, uma unidade de interface de entrada/saída 308, e uma unidade de armazenamento 310. Estes componentes são bem conhecidos a pessoas de habilidade ordinária na arte de computador e portanto são descritas só brevemente aqui. A CPU 306 opera a execução de todos os programas de software no testador 302, incluindo o sistema operacional e qualquer software correndo nele. A unidade de interface 308 serve para conectar o testador 302 ao dispositivo sob teste 304, como também qualquer dispositivo de entrada/saída (por exemplo, teclado, mouse, unidade de exibição, impressora, etc.) conectado a ele. A unidade de armazenamento 310 provê armazenamento temporário (por exemplo, RAM) e/ou armazenamento de longo prazo (por exemplo, unidade de disco rígido) para qualquer programa de software e/ou dados que podem ser precisados para a execução do sistema operacional e do software correndo no testador 302.
Armazenados na unidade de armazenamento 310 estão vários aplicativos de software, incluindo uma ferramenta de desenvolvimento de software 312. A ferramenta de desenvolvimento de software 312 opera da mesma maneira e tem muitas das mesmas características como ferramentas de desenvolvimento de software existentes tais como 'Code Composer Studio™', de Texas Instruments e LabVIEW™ de National Instruments, ou outras ferramentas de desenvolvimento de software semelhantes. De acordo com concretizações da invenção, porém, a ferramenta de desenvolvimento de software 312 ademais inclui uma plataforma de verificação e teste (TVP) 314. A TVP 314 é capaz de controlar a sondagem bidirecional de qualquer software sendo testado usando a ferramenta de desenvolvimento de software 312, e analisando os dados sendo sondados. Especificamente, a TVP 314 permite a dados serem capturados do código sob teste, injetados no código sob teste, ou ambos, como determinado por um usuário. O módulo de controle e análise de sonda 314 também permite ao usuário gerar vetores de teste baseado nos dados obtidos e injetar os vetores de teste de volta no código sob teste. Isto torna mais fácil e mais conveniente para o usuário monitorar e testar a operação e confiabilidade do código sob teste.
Na concretização presente, o código sob teste, incluindo as instruções de sonda dinâmica, é executado em uma unidade separada, isto é o dispositivo sob teste 304, que está em comunicação com o testador 302. O dispositivo sob teste 304, como o testador 302, é um computador típico que tem vários componentes funcionais, incluindo uma CPU 316, uma unidade de interface de entrada/saída 318, e uma unidade de armazenamento 320. Os componentes do dispositivo sob teste 304 são semelhantes em função às suas contrapartes no testador 302 e portanto não serão descritos aqui. O ponto principal é que o código sob teste 322, incluindo o código fonte sondado e as instruções de sonda dinâmica e implementação, é armazenado e executado separadamente do testador 302. (Veja os blocos exemplares de código de fonte acima para exemplos de instruções de sonda).
O método descrito acima permite a sonda ser inserida em tempo real, que dá a pessoa executando a flexibilidade de teste para inserir as sondas quando elas são precisadas. Também, porque as sondas são removíveis, memória pode ser economizada removendo sondas inativas ou depois que uma sonda executou o teste desejado.
Deveria ser enfatizado que o termo inclui/incluindo, quando usado nesta especificação, é tomado para especificar a presença de características declaradas, inteiros, etapas, ou componentes, mas não impede a presença ou adição de uma ou mais outras características, inteiros, etapas, componentes, ou grupos disso.
Enquanto concretizações e aplicações particulares da presente invenção foram ilustradas e descritas, é para ser entendido que a invenção não está limitada à construção precisa e composições expostas aqui, e que modificações e variações podem ser feitas ao antecedente sem partir da extensão da invenção como definida nas reivindicações anexas.