Consiste na realização de testes específicos com o software de maneira a validá-lo para o uso intencional definido nas especificações do produto.
O passo inicial dos testes de software a serem realizados com o protótipo BETA é o planejamento dos testes. Planeja-se inicialmente os testes de aceitação com base na especificação de requisitos de software. Desses testes e do desenho do software são derivados os testes de integração. Derivados desses últimos e com base no desenho detalhado e na documentação do software codificado, planeja-se os testes de unidade os quais podem ser realizados pelos próprios desenvolvedores.
Deve-se então desenhar os testes. Isso significa especificar os testes a serem realizados: sua seqüência, os casos de teste a ele associados e os procedimentos de teste a serem utilizados. Um caso de teste é um conjunto possível de entradas para um determinado caso de uso do programa. Para esse conjunto de entradas devem ser especificados procedimentos de teste indican-do telas e menus a serem executados e as saídas esperadas. Os testes relacionados com funcionalidades que impliquem em parâmetros críticos de projeto devem comportar indicadores especiais nas fichas relacionadas com os testes a serem realizados.
Deve-se então desenhar os testes. Isso significa especificar os testes a serem realizados: sua seqüência, os casos de teste a ele associados e os procedimentos de teste a serem utilizados. Um caso de teste é um conjunto possível de entradas para um determinado caso de uso do programa. Para esse conjunto de entradas devem ser especificados procedimentos de teste indican-do telas e menus a serem executados e as saídas esperadas. Os testes relacionados com funcionalidades que impliquem em parâmetros críticos de projeto devem comportar indicadores especiais nas fichas relacionadas com os testes a serem realizados.
Os testes a serem realizados com o software desenvolvido visam validá-los, uma vez que há exigências normativas relacionadas com a realização de processos de validação de software independentes dos testes funcionais a serem realizados com o hardware.
Os testes devem ser normalmente realizados por pessoas que não participaram do projeto do software a ser testado. Embora o planejamento dos testes deva ser realizado por pessoa experiente, a execução de testes baseados em planos e especificações bem definidos pode ser realizada por projetistas menos experientes.
Existem basicamente duas maneiras de se construírem testes:
– método da caixa branca – objetivam determinar defeitos na estrutura interna do produto através de testes que exercitem suficientemente os possíveis caminhos de execução;
– método da caixa preta – objetiva detectar se os requisitos foram total ou parcialmente satisfeitos pelo produto. Esses testes não verificam como ocorre o processamento, mas apenas os resultados produzidos.
Esses métodos são utilizados para elaborar os testes a serem aplicados ao produto que são de três tipos:
– testes de unidade – objetiva verificar um elemento que possa ser tratado como uma unidade de implementação: uma sub-rotina por exemplo;
– testes de integração – objetiva verificar as interfaces entre as partes de uma arquitetura de software para as quais já foi realizado teste de unidade;
– testes de aceitação – objetiva validar o produto (verificar o atendimento dos requisitos especificados) e devem ser realizados em ambiente o mais próximo possível ao ambiente real de execução.
No MRM, os testes de software são tratados isoladamente na fase de otimização. Nessa fase todo o ciclo de testes de software é realizado. Na fase de validação do produto apenas os testes de aceitação são retomados.
REF.: PAULA FILHO, 2001 é utilizado integralmente para a confecção dessa atividade.
Os testes devem ser normalmente realizados por pessoas que não participaram do projeto do software a ser testado. Embora o planejamento dos testes deva ser realizado por pessoa experiente, a execução de testes baseados em planos e especificações bem definidos pode ser realizada por projetistas menos experientes.
Existem basicamente duas maneiras de se construírem testes:
– método da caixa branca – objetivam determinar defeitos na estrutura interna do produto através de testes que exercitem suficientemente os possíveis caminhos de execução;
– método da caixa preta – objetiva detectar se os requisitos foram total ou parcialmente satisfeitos pelo produto. Esses testes não verificam como ocorre o processamento, mas apenas os resultados produzidos.
Esses métodos são utilizados para elaborar os testes a serem aplicados ao produto que são de três tipos:
– testes de unidade – objetiva verificar um elemento que possa ser tratado como uma unidade de implementação: uma sub-rotina por exemplo;
– testes de integração – objetiva verificar as interfaces entre as partes de uma arquitetura de software para as quais já foi realizado teste de unidade;
– testes de aceitação – objetiva validar o produto (verificar o atendimento dos requisitos especificados) e devem ser realizados em ambiente o mais próximo possível ao ambiente real de execução.
No MRM, os testes de software são tratados isoladamente na fase de otimização. Nessa fase todo o ciclo de testes de software é realizado. Na fase de validação do produto apenas os testes de aceitação são retomados.
REF.: PAULA FILHO, 2001 é utilizado integralmente para a confecção dessa atividade.
Deve-se então implementar os testes. O ambiente de teste é preparado, o que implica na instalação e configuração dos sistemas de medição necessários à verificação das saídas quando estas se tratarem de resultados de hardware. Pode ser necessário desenvolver código especialmente para a realização dos testes. Assim sendo devem ser então realizados os testes de integração, inicialmente, e posteriormente, os testes de aceitação. Os testes de unidade podem ser realizados ao longo da implementação pela própria equipe de desenvolvedores.
Deve-se então verificar se todos os testes foram concluídos e documentá-los em um balanço final que indique variações quanto ao esperado e problemas não-resolvidos.
Os testes que já tenham sido contemplados com a atividade de teste do protótipo BETA devem ser explicitamente indicados.
Deve-se então verificar se todos os testes foram concluídos e documentá-los em um balanço final que indique variações quanto ao esperado e problemas não-resolvidos.
Os testes que já tenham sido contemplados com a atividade de teste do protótipo BETA devem ser explicitamente indicados.
Os testes a serem realizados com o software desenvolvido têm como entrada a matriz de verificação do produto, os resultados dos testes de unidade realizados ao longo do desenvolvimento dos softwares de alto nível e assembly e os resultados dos testes realizados com o hardware de projeto.
A saída é um relatório de testes de integração e verificação de software ou um registro das necessidades de alteração de software com base na especificação de requisitos.
A atividade pode ser retomada caso a revisão de fase indique a necessidade de rever algum aspecto do projeto de software cujo cumprimento não tenha sido demonstrado nos testes de aceitação.
A saída é um relatório de testes de integração e verificação de software ou um registro das necessidades de alteração de software com base na especificação de requisitos.
A atividade pode ser retomada caso a revisão de fase indique a necessidade de rever algum aspecto do projeto de software cujo cumprimento não tenha sido demonstrado nos testes de aceitação.
