3.1 Visão Geral do Processo de Teste de Software
processo de teste de software e o processo de desenvolvimento de software é semelhante, assim como várias partes do plano de teste, design de teste, desenvolvimento de testes, execução de teste e avaliação de teste.
(1) O programa de testes. De acordo com as necessidades do usuário informar sobre a especificações de requisitos e indicadores de desempenho funcional, a definição da demanda relatório de ensaio correspondente que todo o trabalho de testes subsequentes serão realizadas em torno dos requisitos de teste. Ao mesmo tempo, selecione o conteúdo do teste apropriado, disposições testadores razoáveis, tempo de teste e recursos de teste.
(2) teste de criação. design de teste refere-se à fase de planejamento teste de decomposição para desenvolver requisitos de teste, subdivididos em um número de processo de teste executável e seleccionar os casos de teste apropriadas para cada processo de teste, para assegurar a validade dos resultados dos testes.
(3) o desenvolvimento do teste. Estabelecer processo de teste automatizado pode ser repetida utilização.
(4) a execução do teste. teste automático Durante a fase de desenvolvimento do teste do estabelecimento, e defeitos encontrados para acompanhar a gestão. É geralmente realizada por um teste de unidade de teste, testes de integração, testes de validação e etapas de regressão testando.
(5) teste e avaliação. Vinculativo cobertura de teste quantificar domínio e relatórios de rastreamento de defeitos sobre o andamento do trabalho e da qualidade e eficiência da equipe de desenvolvimento de software de aplicação de uma avaliação global.
No procedimento de teste, o teste realizado por realizar as seguintes etapas: teste de unidade, de ensaio de integração, os testes de validação e de aceitação, mostrado na Figura 3.1.
Figura processo de execução do teste 3.1 Software
(1) teste de unidade: testando cada módulos de software mínimos, a implementação de um programa de teste para cada unidade do código-fonte, o programa verifica se cada módulo é implementado corretamente predeterminado função para garantir que ele possa trabalhar.
(2) Teste de Integração: O módulo foi testado para a integração de montagem, que visam testar questões de estrutura de programas associados a design de software.
(3) teste de validação: testar o software satisfaz os requisitos de funcionamento e desempenho na especificação de requisitos, de configuração de software é determinada completamente e correctamente. Ao mesmo produto de software de testes de tempo pode coordenar com o ambiente operacional real em outras partes do sistema (tais como hardware, banco de dados e pessoal de operação).
(4) teste de aceitação: software de processo de teste como a qualidade do produto final, o software principal permite aos utilizadores de teste e re-executar um subconjunto de ensaios têm sido feitos para assegurar que não haja introdução de novos erros.
3.2 Testes Unitários
1. conteúdo de teste de unidade
Meios para testar o módulo de programa de teste, existem os seguintes cinco tarefas principais: a interface de teste do módulo, a estrutura de dados local do ensaio, as condições de limite do teste, o caminho de execução e teste de manuseamento de erro, mostrada na Figura 3.2.
Figura tarefa teste 3,2 unidade a ser resolvido
1) Teste de Módulo de Interface
fluxo de dados, o módulo sob teste a teste, verifica os dados de saída do módulo é correcta. Assim, uma interface de módulo deve compreende uma tabela de parâmetros, os parâmetros de escala sub-módulo, os dados globais, arquivo de entrada / saída operações para testar e similares. Em particular, para o seguinte.
(1) O número de módulos coincide parâmetro aceita o número real de parâmetros de entrada do módulo.
Tipos de parâmetros formais e os parâmetros reais do módulo (2) coincidir com a entrada.
Seja na forma de parâmetros de unidade e parâmetros reais utilizadas pelo módulo (3) entradas estão alinhados.
(4) Quando a chamada de outros módulos, o número do número real de parâmetros transmitidos é chamado com os parâmetros formais do módulo são os mesmos.
(5) Quando a chamada de outros módulos, parâmetro real transmitida com os parâmetros formais do chamado jogo módulo.
(6) chama um outro módulo, a unidade e os parâmetros reais da forma transmitida os parâmetros módulo de chamada são consistentes.
parâmetro (7) número de chamada de função interno, e atributo ordem é correcta.
(8) No caso do módulo com uma pluralidade de entradas, se os parâmetros de referência de corrente independente da entrada.
(9) se os parâmetros de leitura-modificação.
(10) se uma variável global em todos os seus módulos têm a mesma referência definições.
Se inclui um módulo de E / S externa dentro, você também deve considerar os seguintes fatores:
(1) atributos de arquivo estão corretos.
(2) abre e fecha afirmação está correta.
(3) o comprimento da capacidade tampão da partida de gravação.
Se deseja abrir o arquivo antes (4) durante as operações de leitura / gravação.
(5) No final do identificador de ficheiro é fechado o ficheiro.
(6) o texto escrito / entrada para erros.
(7) I / verificação de erros O e se fazer um acordo.
2) a estrutura de dados local do teste
O teste verifica a problemas de integridade de estrutura de dados local, como uma especificação de tipo de dados, initialize, faltas, etc., e para testar a influência no módulo de dados global.
No decorrer do módulo deve ser testado dentro do módulo pode manter a integridade dos dados, incluindo o conteúdo de dados internos, sob a forma de relações mútuas e erros não ocorrem.
Note-se que os tipos de locais de estrutura de dados de erros: Tipo de descrição incorreta ou inconsistente; inicialização incorreta ou padrão valores; erro de nome variável, tais como erros de ortografia ou erro de escrita; underflow, estouro ou um erro de endereço.
3) teste de caminho de execução
Importante caso de teste de teste do módulo caminho de execução, em que os caminhos de execução básicos e teste ciclovia muitas vezes pode encontrar um monte de erros. Como o teste deve ser capaz de descobrir o erro de cálculo de erro, determinação incorreta ou o fluxo normal de controlo gerado.
Erros comuns: prioridade aritmética incorreta ou enganosa; erro de operação em modo misto; erro de inicialização; a precisão não é suficiente precisas; representação simbólica incorrecta da expressão.
E uma cobertura para as condições de determinação, os casos de teste podem ser encontrados os seguintes erros: comparação de erro de diferentes tipos de dados; determinação incorreta ou incorreta; operação lógica incorreta ou prioritários; lugar devido a um erro deve ser igual a precisão não pode ser igual a variável; termina laço incorrectas ou inexistentes; quando se trata de reciclagem ramo não pode parar, modificar de forma inadequada a variável de loop.
4) Medição Tratamento de erros
Tratamento de erros do módulo de controlo contém erros ou defeitos. Por exemplo, se a rejeitar a entrada razoável, se a descrição de erro é difícil de entender, se a localização de falhas é errado, se a causa do relatório de erro é errado, se o tratamento de condições de erro é incorreta, o sistema a condição de erro antes da manipulação de erro já está causando a intervenção.
manipulação de erro de teste chave módulo quando ocorre um erro no trabalho, tratamento de erros instalações que são válidos.
5) teste de condição de limite
Testando as condições de contorno é a etapa final da unidade de testes, análise de valor limite deve ser usada para projetar casos de teste. O teste está funcionando corretamente no limite, o conjunto de módulo de teste para limitar o processamento de dados.
Alguns tipos de dados de fronteira relacionadas, tais como a primeira, a última, máximo, mínimo, máximo, mínimo, máximo, mínimo e assim por diante.
Em condições de contorno do teste, o teste deve ser projetado para verificar o seguinte:
(1), se houver um erro na 0, 1 ...... n vezes n ciclos.
Toma cálculo do valor máximo (2) ou a determinação, se existe um valor mínimo de erro.
fluxo (3) de dados, o fluxo de controlo é exactamente igual a, maior do que, se o erro é menor do que o valor de comparação determinado.
Passo 2. Unidade de Teste
O teste de unidade é geralmente levada a cabo na fase de codificação. código-fonte completo através da preparação e revisão e verificação, após a confirmação de nenhum erro de sintaxe, começou a projetar casos de teste para testes de unidade.
O módulo não é um programa independente, considerando o módulo de teste, tendo em conta as suas ligações com o mundo exterior, então use algum módulo auxiliar para simular outros módulos associados ao módulo sob teste. módulo auxiliar é dividido em dois seguintes:
(1) do módulo de accionamento (drive): é utilizado em um módulo analógico do módulo sob teste, correspondendo a um módulo de programa principal em teste para receber dados de teste, e envia os dados para o módulo sob teste, o módulo sob teste início finalmente, a saída dos resultados medidos.
(2) o topo (cepo): utilizada para simular o curso do módulo sob teste módulo invocado. Stubs fosse apenas um processamento de dados em geral alguns, você não precisa de todos os recursos dos sub-módulos são trazidos, mas não não fazer nada.
O módulo sob teste, que está associada com o módulo de accionamento e o topo em conjunto formam um "ambiente de teste", mostrada na Figura 3.3.
Figura ambiente de teste de ensaio de 3,3 unidade
3.3 Teste de Integração
Processo de acordo com os requisitos de concepção de software, os módulos são ligados entre si por meio de teste de unidade, o sistema de software como composição definida chamado "integrado". O teste de integração é a de teste para este processo, de acordo com a relação de dependência entre a interface do módulo. A Figura 3.4 mostra um exemplo da hierarquia da FIG software.
Porque o teste de integração não é realizada em um ambiente real, mas em um ambiente de desenvolvimento separado ou ambiente de teste, integração de testes necessários para o pessoal selecionado a partir do grupo de desenvolvimento geral, sob a supervisão do chefe do desenvolvimento. líder da equipe de desenvolvimento responsável por assegurar a implementação da plena integração testar usando a tecnologia de teste apropriado em um controle razoável qualidade e supervisão. testes de integração, teste por um observador independente para monitorar o teste.
3,4 diagrama esquemático da hierarquia de software
1. A principal tarefa do teste de integração
É um software integrado sistema de teste testando técnicas de montagem, de acordo com a concepção requisitos dos módulos individuais em conjunto após a montagem da unidade de teste, o software requer estrutura de software do sistema realista, encontrados em vários erros relacionados com a interface. O teste de integração é principalmente apropriado para as seguintes vários sistemas de software:
(1) exigem um alto sistemas de software de qualidade de software, tais como software aeroespacial, software de telecomunicações, o software do sistema subjacente.
(2) o uso de um âmbito de aplicação mais amplo, um maior número de utilizadores do software.
(3) utilizando o programa de linguagem de desenvolvimento de software com um ponteiro semelhante ao C / C ++.
(4), as bibliotecas de middleware e outros produtos.
A principal tarefa do teste de integração é abordar os seguintes cinco questões:
(1) Os módulos são ligados entre si, cada módulo chama os dados de controlo através da interface é perdida.
(2) combinar as respectivas funções, funções de verificação pode alcançar os requisitos esperados.
Função é (3) um módulo de função para outro módulo deve ser afectada de forma adversa.
Se (4) estrutura global de dados em questão, não seria modificações incomuns.
Erro (5) se o módulo único acumulado é alargada, de modo a atingir um grau inaceitável.
2. Método de Teste de Integração
A principal integração de software de teste Os testes de problemas estruturais, de modo que o teste baseado na interface do módulo, principalmente teste de caixa-preta, caixa branca devidamente aditados. testes de integração deve seguir os seguintes passos.
Passo 1: Verificar a relação entre a composição de um sistema de módulos completos.
Passo 2: necessidades de interacção e comunicação entre o módulo de avaliação, confirmar as interfaces entre os módulos.
Passo 3: gerar um conjunto de casos de teste.
Etapa 4: um incrementais módulos de teste sequencialmente adicionados ao processo de teste do sistema e sequência lógica / funcional é repetido.
processo de teste de integração com particular atenção para o módulo de chave de teste, o módulo de chave tem, tipicamente, uma ou mais das características seguintes:
(1) Corresponde às várias exigências simultaneamente a função;
(2) ter uma série de funções de controlo de alto nível;
(3) complexo, sujeito a erros;
(4) os requisitos especiais de desempenho.
O principal objectivo do ensaio consiste em verificar a integração e a interacção de cada um dos módulos de interface da composição do sistema de software, e, por conseguinte, a integração dos dados dos requisitos de teste e a dificuldade do conteúdo não é muito alta. Integração testes geralmente não usam dados reais, você pode usar uma parte dos dados de teste representativas. Ao criar dados de teste, condições de contorno deve garantir que os dados totalmente testado sistema de software.
Incluindo testes de integração testes de integração não-incremental e testes de integração incremental.
Teste de Integração 1) não incremental
Testes de Integração método não incremental-passo para testar, depois de uma unidade de testes individuais para todos os módulos, a estrutura de programa de acordo com a fig ligar os módulos entre si, o processo de ligação, após o teste, como um todo.
2) Teste de Integração Incremental
Método de teste de integração incremental compreende teste de cima para baixo incremental, e um teste de integração parcial de baixo para cima a partir de testes de sanduíches.
teste (1) incremental de cima para baixo. De cima para baixo periódica teste passo a passo e integração gradual diagrama estrutural de acordo com um teste de cima para baixo. O módulo integrado é o primeiro módulo mestre integrado ordem (programa principal), e depois seguir a hierarquia de integração de software de controlo para baixo. Descendente modo pode ser integrado e estratégias de profundidade-primeiro em largura primeira estratégia, mostrada na Figura 3.5.
FIG baixo 3,5 autoteste periódica esquemática
(2) teste incremental de baixo para cima. teste incremental de baixo para cima a partir do "atómica" (estrutura do módulo de software de fundo) do módulo, começando com a estrutura de baixo para cima de integração gradual Fig e testes. A Figura 3.6 representa um processo de baixo para cima de teste incremental.
3.6 um diagrama esquemático de baixo para cima de um teste incremental
testes de integração (3) sanduíche. A integração também chamado de integração híbrido sanduíche, ele top-down e bottom-up rolou para as vantagens e desvantagens. sistema de sanduíche é dividido em três camadas são integrados com uma camada intermédia, como uma camada de destino. A camada de topo da camada de destino usando cima para baixo de modo de teste de teste integrado, o uso de camada de integração estratégia de baixo para cima por baixo da camada de alvo, a camada de destino é finalmente testados.
Como ilustrado usando o procedimento pilha S2, S3 e S4, o utilizador interface de teste M1 3,7, usando condutores D5 e D6 função do módulo inferior M7, M8 e M9 foram testados. Quando todo o sistema integrado, o programa pilha S2, S3 e S4 para o módulo camada intermediária M2, M3 e M4, condutores D5 e D6 do módulo substituído M5 e M6 da camada intermédia, a camada intermédia de tal modo que o módulo funcional é para ser testado.
integração FIG testar sanduíches esquemáticos 3,7
teste 3,4 confirmação
Para confirmação testes para verificar a validade do software, ou seja, para verificar a funcionalidade e desempenho do software e outras características atender às necessidades do usuário.
Na fase de teste precisa ser feito para confirmar o trabalho mostrada na Figura 3.8. Você deve primeiro testar a eficácia da revisão, bem como configuração de software, instalação e testes de aceitação e testando depois pelos peritos, para tornar-se uma entrega de software.
FIG passo de confirmação de teste 3,8
1. Teste de validade
Validade do teste em ambiente simulado, o uso de métodos de teste caixa preta para verificar se o software em teste atende aos requisitos listados na especificação de requisitos. Para isso, planos de teste, disposições relativas a ensaios do tipo a fazer, para desenvolver um conjunto de etapas de teste, descrever os casos de teste. Para determinar se o software apresenta consistente com os requisitos através da implementação de planos de teste pré-definidos e procedimentos de teste para garantir que todos os requisitos funcionais de software são cumpridos, todo o software para atingir os requisitos de desempenho, todos os documentos estão corretos e fácil de usar.
2. Configuração Software Review
O objetivo da revisão é garantir que a configuração de todos os componentes, incluindo o ambiente de funcionamento real do sistema de software de configuração de software são o ambiente de suporte completo, a qualidade de todos os aspectos de conformidade com todos os requisitos. No processo de teste de validação, deve respeitar estritamente as disposições do etapas para usar o usuário do manual e manual de operação, a fim de verificar a integridade e exatidão da documentação, registo omissões e erros encontrados, e apropriadamente complementar e correta.
3.5 Teste de Aceitação
testes de aceitação do usuário é principalmente para testes, desenvolvedores de software e pessoal de garantia da qualidade, devem participar. Pelo usuário para participar do projeto de casos de teste, entrada de dados de teste através da interface do usuário, a saída dos resultados da análise do teste. Os dados reais são geralmente utilizados na produção de teste. Durante o teste, além de considerar a função e desempenho do software, mas também para lidar com a portabilidade, compatibilidade, manutenção, recursos de recuperação de erros e outros softwares para confirmar.
3.5.1 teste α e teste β
Após a entrega do software, os usuários serão como realmente usar o programa para desenvolvedores é imprevisível. Porque os problemas do usuário de tal mal-entendido sobre o método de operação de software, muitas vezes vai ocorrer durante a utilização; combinação de dados anormalidade; gerando para alguns usuários parecem ser clara, mas para outros é difícil de entender o usuário saída, e assim por diante.
α e teste teste β é usado para localizar erros pode ser o utilizador final pode encontrar. α teste para testar um utilizador pode ser realizado no ambiente de desenvolvimento, o ensaio pode ser realizado no interior do utilizador empresa na simulação do ambiente real de funcionamento. α teste é um teste realizado sob uma atmosfera controlada. O objetivo do teste é a avaliação de produtos de software que funcionam, usabilidade, confiabilidade, desempenho e suporte FURPS α, com particular destaque para a interface e as características do produto. Α início após o fim do teste pode ser iniciado a partir do produto de software codificado, ou começando após o módulo (partição) o teste é concluído, o teste pode ser confirmado que o produto durante certo grau de estabilidade e fiabilidade.
β teste é um teste realizado em um ou mais de ambiente real do utilizador por uma pluralidade de utilizadores de software. E α teste diferente é que os desenvolvedores muitas vezes não local de teste. Portanto, β teste é realizado nos desenvolvedores de software de aplicação de campo sob ambiente incontrolável. No teste de β, o registro do usuário todos os problemas encontrados, incluindo julgamentos reais e subjetivos, e informar regularmente o desenvolvedor, o desenvolvedor depois de relatórios detalhados de usuários, mudanças fazer, e, finalmente, os produtos de software entregues a todos os utilizadores usar. teste de β enfoca o apoio do produto, incluindo documentação, treinamento e suporte ao cliente para a capacidade de produção. Apenas quando α teste atinge um certo nível de fiabilidade, β pode iniciar os testes.
3.5.2 Teste de Regressão
Qualquer fase do ciclo de vida do software, desde que o software foi alterado, você pode dar o defeito de software causou o problema. A mudança pode ser devido a erros de software encontrado e fez alterações, mas também pode ser devido à integração ou manutenção fase adicionado um novo módulo e outras circunstâncias. testes de regressão é um teste para verificar a integridade e precisão da tecnologia mudou o sistema, refere-se à re-implementação de um subconjunto de testes foram feitos para garantir que a modificação não introduzir novos erros ou antes devido à mudança causada pela descoberta erro não for detectado, ou seja, para garantir a mudança não trouxe efeitos colaterais indesejados. Portanto, todas as fases do desenvolvimento de software serão realizados vários testes de regressão.
1. Pré-requisito para a implementação de testes de regressão
(1) Quando o software continha erros são encontrados, se o rastreamento de erro e sistema de gestão não é perfeito, estes erros podem ser desperdiçada modificações;
(2) o desenvolvedor de mal-entendido ou mal, isso poderia levar a uma revisão feita apenas corrige um bug na aparência externa, mas não corrigir o erro em si, resultando na modificação falhou;
(3) modificação também é possível produzir efeitos colaterais que conduzem a partes do software não foram modificados para produzir novos problemas, de modo que iria trabalhar função normal gera um erro.
2. O teste de regressão de duas estratégias
O teste de regressão está a testar durante todas as fases das actividades de ensaio, a fim de inspecção defeito foi encontrado que não há nenhuma modificação correcta e processo de revisão causou nenhum novo defeito. As estratégias a seguir pode ser usado para testes de regressão.
1) repetição do teste completo
Repita o teste for concluído todos os casos de teste mais uma vez completamente executadas, para confirmar os métodos de teste modificados em torno da questão da validade e se as mudanças afetados. A desvantagem é que deverá ter casos de uso implementação total, aumentando assim os custos do projeto, também afetará o cronograma do projeto, é difícil de implementar plenamente.
2) teste de repetição selectiva
Refere-se a testes de repetição selectiva pode ser realizada para seleccionar uma parte, a fim de confirmar a exactidão do perímetro modificado questão e está sujeito a modificações do método de ensaio de impacto. Aqui estão vários métodos de ensaios repetidos seletivos:
(1) abrange o método modificações.
(2) Método de influência externa.
(3) índice atingiu um método.
(4) secção transversal com base em um teste de funcionamento.
teste de selecção à base de Risco (5).
3. processo de teste de regressão
processo de teste de regressão tem tipicamente as seguintes etapas.
Passo 1: Política fase de formulação em testes, testes de regressão para desenvolver estratégias.
Passo 2: Determinar a versão de testes de regressão.
Passo 3: Teste de Regressão lançamento, testes de regressão testes de regressão de acordo com a política.
Passo 4: Por testes de regressão, um único defeito de monitoramento off.
Passo 5: O teste de regressão não for aprovada, um único retorno defeito; desenvolvedores para re-editar, fazer testes de regressão novamente.
4. Comparação de testes de regressão e teste geral
O teste de regressão e teste geral em comparação com um número de diferentes pontos, foram atribuídas a partir da disponibilidade de um plano de teste, teste de alcance, o tempo, o desenvolvimento de informações, termos completos de tempo e de eficácia, etc, são introduzidos.
Disponibilidade (1) plano de teste: sistemas de teste gerais de acordo com especificações e planos de teste, casos de teste são novos, e testes de regressão pode ser uma mudança de especificação, o programa modificado e a necessidade de atualizar o plano de teste.
(2) Teste Âmbito: O objectivo geral do teste é a detecção da correcção de todo o programa, o objectivo é detectar regressão testar a exactidão da porção relevante do sistema modificada e a sua integração com a função original.
(3) alocação de tempo: o tempo necessário para testar o orçamento geral antes que o software é normalmente desenvolvido; e o tempo necessário para testes de regressão (especialmente de testes de regressão corretiva) muitas vezes não estão incluídas no cronograma do produto.
(4) o desenvolvimento da informação: desenvolvimento teste de conhecimentos gerais e informações sobre disponível a qualquer momento, e testes de regressão pode ser realizado em diferentes lugares e épocas, necessidade de reter informações para garantir o desenvolvimento adequado dos testes de regressão.
(5) o tempo de conclusão: Uma vez que apenas uma parte dos testes de regressão do programa de teste, completando assim o tempo necessário para os testes é geralmente menos tempo do que os testes normalmente necessários.
(6) Freqüência de Execução: testes de regressão, muitas vezes muitas vezes durante o ciclo de vida de um sistema, uma vez que o sistema foi modificado sobre a necessidade de testes de regressão.
