Plano de Teste de Software para Árvore Binária de Pesquisa

Documento fazer Plano de Teste Maior https://translate.googleusercontent.
com/translate_f
VHTN Software Development
Plano de Teste de Software
13 de maro de 2003
Enviado por:
Valerie Stanton
Hatsey Frezghi
Todd Wilkinson
Nick Monge
1 de 25 22/11/2017 09:04
Documento fazer Plano de Teste Maior https://translate.googleusercontent.com/translate_f
ndice
1 Introduo
1.1 Interao em equipe
2 Objetivo de teste
3 Viso geral do processo
4 Processo de teste
5 Estratgia de teste
5.1 Teste de Unidade
5.1.1 White Box Testing
5.1.2 Black Box Testing
5.2 Teste de integrao
5.2.1 Teste incremental
5.3 Teste do Sistema
5.3.1 Teste de Validao de Funo
5.3.2 Teste de performance
6 Critrios de Entrada e Sada
6.1.1 Black Box Phase
6.1.2 Fase da caixa branca
6.2.1 Critrios de Entrada de Teste de Integrao
6.2.2 Critrios de sada do teste de integrao
6.3 Teste do sistema
6.3.1 Critrios de Entrada do Teste do Sistema
6.3.2 Critrios de sada do sistema
6.4 Envio ou lanamento ao vivo
6.4.1 Critrios de entrada para envio / lanamento ao vivo
6.4.2 Critrios de sada de envio / sada ao vivo
7 Processamento de Bug Tracking / Bug
7.1 Vrias funes na resoluo de erros
7.2 Formulrio de Relatrio de Erro
8 Papis e responsabilidades
8.1 Equipe de desenvolvimento
8.2 Equipe de teste
9 Programao de teste
10 Entregveis
11 Referncias
2 de 25 22/11/2017 09:04
1 Introduo
Este documento uma viso geral de alto nvel que define nossa estratgia de teste para o aplicativo Tree
Ordenado. O objetivo comunicar padres e procedimentos de qualidade para todo o projeto. Ele retrata um
instantneo do projeto no final da fase de planejamento. Este documento abordar os diferentes padres que
se aplicam unidade, integrao e teste do sistema da aplicao especificada. Usaremos critrios de teste sob
a caixa branca, caixa preta e paradigma de teste do sistema. Este paradigma incluir, mas no est limitado a,
critrios de teste, mtodos e casos de teste do projeto geral. Ao longo do processo de teste, aplicaremos as
especificaes da documentao de teste descritas no Padro IEEE 829-1983 para Documentao de Teste de
Software.
1.1 Interao em equipe
O seguinte descreve o nvel de interao da equipe necessria para ter um produto bem-sucedido.
A Equipe de teste trabalhar em estreita colaborao com a equipe de desenvolvimento para alcanar
um design de alta qualidade e especificaes de interface de usurio com base nos requisitos do
cliente. A equipe de teste responsvel por visualizar os casos de teste e aumentar os problemas e
preocupaes de qualidade durante as reunies para abordar questes precocemente no ciclo de
desenvolvimento.
A equipe de teste trabalhar em estreita colaborao com a equipe de desenvolvimento para

determinar se o aplicativo atende ou no aos padres para a completude. Se uma rea no for aceitvel
para o teste, a data de concluso do cdigo ser empurrada, dando aos desenvolvedores tempo
adicional para estabilizar a rea.
Uma vez que o aplicativo interage com um componente de sistema de back-end, a equipe de teste
precisar incluir um plano para testes de integrao. Os testes de integrao devem ser executados com
sucesso antes do teste do sistema.
2 Objetivo de teste
O objetivo do nosso plano de teste encontrar e denunciar o maior nmero possvel de erros para melhorar a
integridade do nosso programa. Embora testes exaustivos no sejam possveis, iremos exercer uma ampla
gama de testes para alcanar nosso objetivo. Estaremos testando um aplicativo de rvore de Pesquisa Binria
utilizando um formato de passagem pr-ordem. Haver oito funes principais usadas para gerenciar nossa
aplicao: carregar, armazenar, limpar, pesquisar, inserir, excluir, listar em ordem crescente e listar por ordem
decrescente. Nossa interface de usurio para utilizar essas funes projetada para ser fcil de usar e fornecer
manipulao fcil da rvore. O aplicativo s ser usado como uma ferramenta de demonstrao, mas
gostaramos de garantir que ele poderia ser executado a partir de uma variedade de plataformas com pouco
impacto no desempenho ou usabilidade.
3 Viso geral do processo
3 de 25 22/11/2017 09:04
O seguinte representa o fluxo geral do processo de teste:

1. Identifique os requisitos a serem testados. Todos os casos de teste devem ser derivados usando a
especificao atual do programa.
2. Identifique quais testes especficos sero usados para testar cada mdulo.
3. Revise os dados do teste e os casos de teste para garantir que a unidade tenha sido cuidadosamente
verificada e que os dados do teste e os casos de teste sejam adequados para verificar o funcionamento
adequado da unidade.
4. Identifique os resultados esperados para cada teste.
5. Documentar a configurao do caso de teste, os dados do teste e os resultados esperados.
6. Execute o (s) teste (s).
7. Documentar os dados do teste, os casos de teste e a configurao do teste utilizados durante o processo
de teste. Esta informao deve ser enviada atravs do Relatrio de Teste da Unidade / Sistema (STR).
8. O teste de unidade bem sucedido necessrio antes que a unidade seja elegvel para a integrao de
componentes / teste do sistema.
9. O teste sem xito requer um formulrio de relatrio de erro a ser gerado. Este documento deve
descrever o caso de teste, o problema encontrado, a causa possvel e a sequncia de eventos que
levaram ao problema. Deve ser utilizado como base para posterior anlise tcnica.
10. Os documentos de teste e os relatrios devem ser enviados. Quaisquer especificaes a serem
revisadas, revisadas ou atualizadas devem ser tratadas imediatamente.
4 Processo de teste
Figura 1: fluxo de processo de teste
4 de 25 22/11/2017 09:04
O diagrama acima descreve a abordagem do processo de teste que ser seguida.
uma. Organizar projeto envolve a criao de um teste do sistema Plano, Schedule & Test
Approach, e atribuir responsabilidades.
b. Concepo / construo System Test envolve a identificao de ciclos de teste, casos de
teste, Entrada e Sada de Critrios, resultados esperados, etc. Em geral, as condies de teste /
resultados esperados sero identificados pela equipe de teste em conjunto com a equipe de
desenvolvimento. A Equipa de Teste identificar casos de teste e os dados necessrios. As condies
de teste so derivadas do Documento de Especificaes do Programa.
c. Procedimentos concepo / construo de teste inclui a criao de procedimentos, tais como
sistemas de gerenciamento de erros e relatrios de status.
d. Construir ambiente de teste inclui solicitando / construo de hardware, software e dados
set-ups.
e. Executar testes do sistema - Os testes identificados no projeto / configurao Procedimentos
de teste ser executado. Todos os resultados sero documentados e os Formulrios de Relatrio de
Bugs preenchidos e entregues Equipe de Desenvolvimento, conforme necessrio.
f. Signoff - Signoff acontece quando todos os critrios de sada pr-definidos foram alcanados.
5 Estratgia de teste
O seguinte descreve os tipos de testes que sero feitos para testes de unidade, integrao e sistema. Embora
inclua o que ser testado, os casos de uso especfico que determinam como o teste feito sero detalhados no
Documento de Teste de Teste. O modelo que ser usado para projetar casos de uso mostrado na Figura 2.
Testado por:
Tipo de teste
Nmero do caso de teste
Nome do caso de teste
Descrio do caso de
teste
Item (s) a ser testado

1
2
Especificaes
Esperado
Entrada Resultado / Resultado
5 de 25 22/11/2017 09:04
Etapas processuais
1
Figura 2: modelo de caso de teste
Teste de unidade feito no nvel de cdigo fonte ou cdigo para erros de programao especficos do idioma,
como sintaxe incorreta, erros de lgica ou para testar funes especficas ou mdulos de cdigo. Os casos de
teste da unidade devem ser projetados para testar a validade da correo dos programas.
5.1.1 White Box Testing
No teste da caixa branca, a UI ignorada. Entradas e sadas so testadas diretamente no nvel do cdigo e os
resultados so comparados com as especificaes. Esta forma de teste ignora a funo do programa em teste e
se concentrar apenas no seu cdigo e na estrutura desse cdigo. Os criadores de casos de teste devem gerar
casos que no apenas levam cada condio a assumir todos os valores possveis pelo menos uma vez, mas isso
faz com que cada uma dessas condies seja executada pelo menos uma vez. Para garantir que isso acontea,
estaremos aplicando testes de filial. Como a funcionalidade do programa relativamente simples, esse mtodo
ser vivel para se candidatar.
Cada funo do repositrio de rvore binria executada de forma independente; portanto, um fluxo de
programa para cada funo foi derivado do cdigo.
5.1.1.1 Teste de filial
Usando o grfico de fluxo do programa para cada funo, poderemos determinar todos os ramos que
precisaro ser testados e sero usados para desenvolver os casos de teste correspondentes.
Inserir
6 de 25 22/11/2017 09:04
Excluir
7 de 25 22/11/2017 09:04
8 de 25 22/11/2017 09:04
Pesquisa
Lista
Ler (Carregar)
Armazenar / Escrever
9 de 25 22/11/2017 09:04
5.1.2 Black Box Testing
O teste de caixa preta geralmente envolve a execuo de todas as entradas possveis para verificar se resulta
em sadas diretas usando o software como o usurio final faria. Ns decidimos realizar testes de
Particionamento de Equivalncia e Anlise de Valor de Limite em nossa aplicao.
5.1.2.1 Particionamento equivalente
Ao considerar as entradas para nossos testes de equivalncia, sero utilizados os seguintes tipos:
Valores de entrada legal - Testar valores dentro dos limites das classes de equivalncia de
especificaes. Isso deve ser dados de entrada que o programa espera e est programado para se
transformar em valores utilizveis.
Valores de entrada ilegais - Classificaes equivalentes de teste fora dos limites da especificao. Isso
deve ser dados de entrada, o programa pode ser apresentado, mas isso no produzir nenhum resultado
significativo.
A tcnica de particionamento de equivalncia uma tcnica de seleo de caso de teste em que o designer de
teste examina o espao de entrada definido para a unidade sob teste e procura encontrar conjuntos de entrada
que so ou deveriam ser processados de forma idntica. A tabela a seguir representa nossas classes de
equivalncia, vlidas e invlidas.
Evento de Entrada / Sada Classes de equivalncia vlida Classes de equivalncia

invlidas
Insira o nmero mximo de 25 valores > 25 valores
valores permitidos
Ingresar nmeros inteiros Inteiros entre -999 e 999 Inteiros> 999
Inteiros <-999
10 de 25 22/11/2017 09:04
No-inteiros (caracteres)
No-inteiros (valores decimais)
Carregar arquivo externo Arquivo delimitado por vrgulas com Sem vrgulas
apenas um valor por linha
Mltiplas entradas por linha
Nenhum contedo do arquivo
o arquivo existe Arquivo no existe
Armazenar arquivo externo o arquivo existe Arquivo no existe
5.1.2.2 Teste de valor de limite
O intervalo aceitvel de valores para esta aplicao foi definido pela equipe de desenvolvimento. Devido s
limitaes da GUI, os desenvolvedores tambm limitaram o tamanho dos valores de entrada para nmeros
inteiros de trs dgitos. Os intervalos vlidos e invlidos so mostrados abaixo, juntamente com os valores de
teste de limite vlidos e invlidos correspondentes.
Faixa aceitvel: -999 x 999

Intervalo invlido: - <x <-999 e 999 <x <+
Testes de limites vlidos:
Limite de 1: x = -999
Boundary 2: x = 0
Boundary 3: x = 999
Testes de limites invlidos:
Limite de 4: x = 1000
Boundary 5: x = -1000
Boundary 6: x = -999999
Limite 7: x = 999999
5.2.1 Teste incremental
Existem dois mdulos primrios que precisaro ser integrados: o mdulo de interface grfica do usurio e o
mdulo Tree Repository (back-end). Os dois componentes, uma vez integrados, formam o aplicativo de
rvore de Pesquisa Binria completo. O seguinte descreve esses mdulos, bem como as etapas que precisaro
ser tomadas para alcanar a integrao completa. Estaremos empregando uma estratgia de teste incremental
11 de 25 22/11/2017 09:04
para completar a integrao.
Mdulo 1 - Mdulo de interface de usurio grfico (GUI)
Este mdulo fornece uma GUI simples onde o usurio pode executar as diferentes aes (funes). Este
mdulo ser testado separado do backend para verificar se cada interface (por exemplo, boto de insero)
est funcionando corretamente e, em geral, para testar se as aes do evento do mouse esto funcionando
corretamente. O teste ser realizado escrevendo um talo para cada elemento na interface.
Mdulo 2 - Mdulo de backend do repositrio de rvores
O "repositrio de rvores" fornece o armazenamento para os elementos de dados e implementa os algoritmos

e a funcionalidade associada da rvore binria. Este mdulo ser testado separadamente da GUI, imprimindo
os resultados no Console. Ao testar este mdulo, seguiremos o mtodo de teste incremental, ou seja, testando
uma funo primeiro e depois continuamos adicionando funo adicional e testando-a novamente at que
todas as funes necessrias sejam testadas.
Quando a GUI combinada com o mdulo backend, teremos uma aplicao de rvore de pesquisa binria
completa. Para alcanar a integrao completa desses dois mdulos, testaremos cada elemento na GUI,
substituindo os tales pela funo apropriada do back-end. Os resultados sero exibidos dentro da GUI em
vez de atravs do Console. Ao testar os mdulos combinados, seguiremos o mtodo de teste incremental.
Cada talo ser substitudo um de cada vez e testado. Isso ser feito at que todos os stubs tenham sido
substitudos pelas funes apropriadas do backend.
5.3 Teste do Sistema
Os objetivos do teste do sistema so detectar falhas que s podem ser expostas, testando todo o sistema
integrado ou parte importante dele. Geralmente, o teste do sistema est preocupado principalmente com reas
como desempenho, segurana, validao, carga / estresse e sensibilidade de configurao. Mas, no nosso caso,
enfocem-se apenas na validao e no desempenho das funes. E em ambos os casos, usaremos o mtodo de
teste de caixa preta.
5.3.1 Teste de Validao de Funo
O "aplicativo de rvore de pesquisa binria" integrado ser testado com base nos requisitos para garantir que
ns construmos o aplicativo correto. Ao fazer este teste, tentaremos encontrar os erros nas entradas e sadas,
ou seja, testaremos cada funo para garantir que ele implemente corretamente os algoritmos da rvore de
Pesquisa Binria e que a rvore resultante exiba os valores na localizao correta graficamente. O
comportamento de cada funo, bem como seus respectivos algoritmos, esto contidos na Especificao do
Programa de Software.
Funo Comportamento esperado

Carga consulte a especificao do programa de software
Loja consulte a especificao do programa de software
12 de 25 22/11/2017 09:04
Inserir consulte a especificao do programa de software
Excluir consulte a especificao do programa de software
Pesquisa consulte a especificao do programa de software
Claro consulte a especificao do programa de software
Lista em ordem ascendente consulte a especificao do programa de software
Lista em ordem decrescente consulte a especificao do programa de software
Alm disso, vamos testar:
As interfaces para garantir que elas funcionam como desejado (ou seja, verifique se cada interface
est se comportando como esperado, especificamente verificando que a ao apropriada est
associada a cada evento mouse_click).
A interao entre a GUI e o repositrio backend. Nesse caso, os dados sero inseridos e verificar se
eles so processados no backend e fornecer o resultado esperado.
5.3.2 Teste de performance
Este teste ser conduzido para avaliar o cumprimento de um sistema com requisitos de desempenho
especificados. Isso ser feito usando o mtodo de teste de caixa preta. E isso ser realizado por:
Armazenando os dados mximos no arquivo e tentando inserir e observando como o aplicativo
executar quando estiver fora do limite.
Excluindo dados e verifique se ele segue o algoritmo de classificao correto para classificar os dados
ou a sada resultantes.
Tentando armazenar novos dados e verificar se ele escreve o existente uma vez.
Tentando carregar os dados enquanto eles j esto carregados
6 Critrios de Entrada e Sada
Esta seo descreve os critrios gerais pelos quais o teste comea, temporariamente interrompido, retomado e
concludo em cada fase de teste. Diferentes caractersticas / componentes podem ter uma ligeira variao de
seus critrios, caso em que esses devem ser mencionados no plano de teste de caractersticas. A fase de teste
tambm mapeia a definio de nvel de impacto quando um defeito inserido na fase de rastreamento de
bugs.
Teste de unidade feito no nvel de cdigo fonte ou cdigo para erros de programao especficos do idioma,
como sintaxe incorreta, erros de lgica ou para testar funes especficas ou mdulos de cdigo. Os casos de
teste da unidade devem ser projetados para testar a validade da correo dos programas.
6.1.1 Black Box Phase
13 de 25 22/11/2017 09:04
O teste de caixa preta geralmente envolve a execuo de todas as entradas possveis para verificar se resulta
em sadas diretas usando o software como o usurio final faria. Usaremos as mtricas de complexidade de
Particionamento de Equivalncia e Anlise de Valor de Limite para determinar quantificadamente quantos
casos de teste so necessrios para alcanar a cobertura mxima de cdigo.
6.1.1.1 Critrios de entrada na caixa preta
Os critrios de entrada da caixa preta dependero da especificao do componente e dos requisitos da

interface do usurio. Coisas que devem ser feitas na entrada no estgio Black Box:
Todas as funes da rvore Binria, Carga, Armazenamento, Limpar, Ordenar Ascendente, Ordenar
Descendente, Inserir, Excluir, Pesquisar, devem ser codificadas ou testadas.
O tipo de mtodos de teste Black Box ser determinado aps a entrada. Usaremos Partio de
Equivalncia e Anlise de Valor de Limite.
A Partio de Equivalncia incluir, somente tipos de dados inteiros, nenhum tipo de dados de
caracteres aceitos, cada campo de dados ser delimitado por vrgulas e haver 1 valor por linha no
arquivo de dados.
A Anlise do Valor de Fronteira incluir, os valores de tipo de dados Inteiros tero um valor limite de
(-999,999). Zero est includo. O tamanho do arquivo limitado a 25 entradas.
6.1.1.2 Critrios de sada da caixa preta
O Black Box Exit Criteria listado abaixo explica o que precisa ser concludo em ordem para sair da fase Black
Box. Para sair da fase Black Box 100% taxa de sucesso deve ser alcanada. Coisas que devem ser feitas aps
sair do estgio Black Box:
As classes de equivalncia tero sido criadas para os valores de entrada vlidos e invlidos. Para o
nosso programa de rvore Binria, os valores de domnio de entrada para Parties de Equivalncia
incluiro apenas tipos de dados inteiros, cada campo de dados ser delimitado por uma vrgula e um
retorno de carro e um valor de dados por linha no arquivo de dados de entrada.
O Mtodo de Partio de Equivalncia gerar casos de Teste com base nas classes de Equivalncia. Os
valores de domnio de entrada invlidos para classes Equivalncia incluiro carregar um arquivo de
dados de entrada vazio, inserindo cordas de caracteres, inserindo um delimitador diferente de uma
vrgula e inserindo mais de um valor de dados por linha no arquivo de dados de entrada.
Anlise do valor de limite gerar casos de teste com base nos valores limite dos valores do tipo de
dados Inteiros de (-999,999). Esses casos de teste testaro valores acima e abaixo dos valores de limite
especificados. Por exemplo, valores que incluem infinito, infinito negativo, zero e nmeros decimais.
Outro conjunto de casos de teste ser criado com base no valor limite do tamanho do arquivo limitado
a 25 entradas. Esses casos de teste testaro certas entradas no arquivo de entrada de dados e maiores
que 25 entradas.
Todos os erros de cdigo que esto expostos so corrigidos.
6.1.2 Fase da caixa branca
Os critrios da Caixa branca aplicam-se para fins de foco na estrutura interna do programa e descubra todos os
erros internos do programa. Os defeitos sero categorizados e a qualidade do produto ser avaliada.
14 de 25 22/11/2017 09:04
6.1.2.1 Critrios de entrada na caixa branca
Os Critrios de Entrada da Caixa Branca basear-se-o nos engenheiros de QA verificando que os principais
recursos funcionam sozinhos, mas no necessariamente em combinao; O tratamento de exceo no ser
implementado. O design e a interface humana so estveis. Coisas que devem ser feitas na entrada na fase da
Caixa Branca:
Todas as funes da rvore Binria, Carregar, Armazenar, Limpar, Ordenar Ascending, Ordenar
Descendente, Inserir, Excluir, Pesquisar, devem ser codificadas.
O tipo de mtodos de teste de caixa branca ser determinado aps a entrada. Utilizaremos testes de
Teste de Caminho de Base e Validao de Funo em todas as propriedades da rvore Binria.
Black Box Testing deve estar em seus estgios tardios.
Depois que os critrios da Caixa Branca foram atendidos, o produto entra no estgio da Caixa Branca.
Durante a fase da Caixa Branca, a Engenharia de Desenvolvimento enfatiza a refinao do produto e a
reparao de defeitos. A nfase do Design de Informaes no desenvolvimento da documentao do usurio
do produto.
6.1.2.2 Critrios de sada da caixa branca
O cenrio da rvore Binria no White Box deve ter uma sensao geralmente estvel para ele. O teste da
caixa branca continua at a caixa preta ou o prximo critrio de marco so atendidos. Para sair da fase da
caixa branca, a taxa de sucesso de 100% deve ser alcanada. O seguinte descreve o estado do produto aps a
sada do White Box Stage:
Todas as funes da rvore Binria, Carga, Armazenamento, Limpar, Ordenar Ascending, Ordenar
Descendente, Inserir, Excluir e Pesquisar so implementadas, operacionais e testadas.
Todos os testes de testes de ramo sero gerados. Os casos de teste sero gerados a partir dos diagramas
de fluxo de controle de todas as funes.
A interface grfica da rvore Binria foi revisada e considerada satisfatria pelos engenheiros de
desenvolvimento e pelos engenheiros de qualidade, e estvel, ou seja, no h mais mudanas nas
caixas de dilogo ou outros elementos da interface esto planejados. Alteraes menores (batidas de
palavras, etc.) so aceitveis, mas devem ser organizadas com os Engenheiros de Desenvolvimento e
Teste.
Existem dois mdulos que sero integrados para Testes de Integrao. Os dois mdulos so o mdulo da
interface grfica do usurio e o mdulo do repositrio de rvores (back-end). Os dois componentes consistiro
em uma mistura de stubs, driver e cdigo de funo total. O seguinte descreve os critrios de entrada e sada
para testes de integrao.
6.2.1 Critrios de Entrada de Teste de Integrao
Os Critrios de Entrada do Teste de Integrao dependero de ambos os mdulos para serem operacionais. O
design da rvore Binria e a interface humana devem ser estveis. Coisas que devem ser feitas na entrada na
15 de 25 22/11/2017 09:04
etapa de Teste de Integrao:
Todas as funes da rvore Binria, Carregar, Armazenar, Limpar, Ordenar Ascendente, Ordenar
Descendente, Inserir, Excluir, Pesquisar, devem ser codificadas e / ou stubs criadas.
A interface de usurio grfica deve ser codificada e / ou um driver e stubs devem ser criados. O driver
implementado para facilitar os valores de entrada e sada do caso de teste.
Interfaces e interaes entre o Mdulo de rvore Binria e a Interface Grfica do Usurio devem estar
operacionais.
Uma estratgia de teste de integrao ascendente ser conduzida. Os detalhes baixos da rvore binria
e da interface grfica sero integrados. Um driver ser escrito para facilitar os valores de entrada e
sada do caso de teste. O driver ir satisfazer os detalhes de alto nvel dos valores de entrada e sada.
Black Box Testing deve estar nos estgios tardios ou concludo.
White Box Testing deveria ter comeado.
6.2.2 Critrios de sada do teste de integrao
Os critrios de sada do teste de integrao dependero de ambos os mdulos para serem operacionais. O
design da rvore Binria e a interface humana devem ser estveis. Para sair da fase de teste de integrao, a
taxa de sucesso de 100% deve ser alcanada. Coisas que devem ser feitas na sada do estgio de Teste de
Integrao:

O Mdulo de rvore Binria e o Mdulo de Interface de Usurio Grfico iro interagir juntamente
com a preciso completa, de acordo com o Design de Especificao do Sistema. Todas as
discrepncias so corrigidas.
Ambos os mdulos esto prontos para teste do sistema. Stubs e drivers so substitudos por cdigo
totalmente funcional.
Black Box Testing est completo.
White Box Testing deve ser em seus estgios tardios ou concludo.
6.3 Teste do sistema
Os critrios do Teste do Sistema aplicam-se para classificar defeitos e avaliar o nvel de qualidade do produto.
Todos os elementos do Mdulo de rvore Binria e da Interface Grfica do Usurio so agrupados e testados
como um todo. O teste do sistema concentra-se em funes e desempenho, confiabilidade, instilao,
comportamento durante condies especiais e testes de estresse.
6.3.1 Critrios de Entrada do Teste do Sistema
Os Critrios de Entrada especificados pelos Engenheiros de Desenvolvimento, devem ser cumpridos antes que
o Teste do Sistema possa comear. No caso em que nenhum critrio no tenha sido alcanado, o Teste do
Sistema pode comear se os Engenheiros de Desenvolvimento e Testes estiverem totalmente de acordo em
que o risco gerencivel.
A Interface Grfica do Usurio e o Mdulo Back-end da rvore Binria devem ser totalmente
funcionais.
Todo o cdigo desenvolvido deve ser testado por unidade. O teste de unidade e link deve ser concludo
16 de 25 22/11/2017 09:04
e assinado pela equipe de desenvolvimento.

Todos os hardware e ambientes de teste devem estar no lugar e gratuitos para o uso do teste do
sistema.
Todos os testes Black Box devem ser completos e os erros expostos devem ser corrigidos.
Todos os testes de caixa branca devem ser completos e os erros expostos devem ser corrigidos.
O teste de integrao deve ser completo e os erros expostos devem ser corrigidos
O Teste de Validao de Funo o mtodo aceito de teste para todas as funes da rvore Binria:
Carregar, Armazenar, Limpar, Ordenar Ascending, Ordenar Descendente, Inserir, Excluir e Pesquisar.
A Interface Grfica do Usurio ser o mtodo de interao com o sistema, de modo que a GUI ser
testada completamente.
Os Engenheiros de Desenvolvimento e Teste concordam que o Teste de Validao de Funo cobrir o
desempenho da funo, a confiabilidade, o estresse e o teste de carga.
6.3.2 Critrios de sada do sistema
Os Critrios de Sada devem satisfazer todos os critrios listados abaixo. Isso verifica que todos os elementos
do projeto se apropriam adequadamente. Isto para se certificar de que todas as funes e funes do sistema
de acordo com o Documento de Especificao do Sistema.
Todos os testes de validao de funo so 100 por cento bem sucedidos. Testando todas as funes da
rvore Binria: Carregar, Armazenar, Limpar, Ordenar Ascendente, Ordenar Descendente, Inserir e
Excluir, e Procurar interagir com a preciso completa.
Nenhuma degradao do desempenho do sistema em diferentes plataformas do sistema operacional
Windows ser afetada. (O Windows 95 ou superior aceitvel)
A interface grfica do usurio executa os requisitos de especificao do sistema.
Todas as propriedades da rvore binria so expressas corretamente atravs da interface grfica do
usurio.
Todos os campos de entrada na interface grfica do usurio esto funcionando corretamente.
Todos os erros de alta prioridade do teste do sistema devem ser corrigidos e testados.
Se algum erro de mdia ou baixa prioridade estiverem pendentes - o Engenheiro de Desenvolvimento
e o Gerenciador de teste devem assinar o risco de implementao como aceitvel.
6.4 Envio ou lanamento ao vivo
O teste da rvore Binria reduzido e combina todas as fases do teste em duas fases - Teste de Funo
Completa e Regresso - e segue os critrios de lanamento.
6.4.1 Critrios de entrada para envio / lanamento ao vivo
Os critrios para entrar nas etapas finais so os seguintes:
A QA verifica que todos os defeitos do produto aberto, independentemente de defeitos fixos,

documentados, diferidos ou endereados.
A QA verifica que os testes de regresso em todos os defeitos do produto e o produto inteiro foram
concludos.
QA verifica se todos os erros "For Verify" foram regredidos.
17 de 25 22/11/2017 09:04
O software est congelado quando o produto passa seu marco final. Se qualquer alterao de cdigo for feita
aps o marco final, os recursos corrigidos devem ser testados de novo. O QA e os Engenheiros de
Desenvolvimento monitora de perto as correes que entram na compilao final para minimizar os riscos.
Depois que os critrios de marco final foram atendidos, o produto entra no estgio Live Release.
6.4.2 Critrios de sada de envio / sada ao vivo
A etapa de Envio / lanamento ao vivo quando o produto est pronto para disponibilidade geral para o
pblico e a documentao do usurio final. O produto deve satisfazer completamente suas especificaes de
lanamento e a documentao do usurio deve descrever adequadamente a funcionalidade do produto. Ambos
devem estar prontos para uso pelo usurio final.
O QA testa a verso final do produto para verificar se o produto a ser divulgado ao pblico em geral
da mxima qualidade e satisfaz especificaes de design originais.
O produto deve receber aprovao da equipe do produto.
O QA e o Desenvolvimento devem preparar as Notas de verso.
O produto j est pronto para enviar ou publicar no ambiente de produo.
7 Processamento de Bug Tracking / Bug
Durante o teste, os membros da equipe de teste normalmente encontram um comportamento que vai contra
um requisito de design especificado ou implcito no produto. Quando isso acontece, documentaremos e
reproduziremos os erros para os desenvolvedores.
Expectativa de um bug:
Acompanhe a verso do aplicativo que o erro encontrado

Determine se o bug j foi escrito
Indique as etapas para reproduzir o bug - escreva detalhes suficientes para outros que olhem o bug
para poder duplic-lo; exclua etapas desnecessrias (ou seja, se o ponto de acesso for irrelevante, seja
mais geral em seus passos).
Resultados reais - seja especfico em suas descobertas.
Resultados esperados - como o produto deve se comportar de acordo com os requisitos especificados
ou implcitos.
Implicaes - Como o defeito afeta a qualidade do produto?
A tabela a seguir define os nveis de impacto a serem usados ao entrar em bugs.
Impacto Definies
1 - Fatal Stopper teste: Se voc no puder acessar uma funo e precisa do erro a ser
corrigido imediatamente. O defeito impede a QA de testar a rea
caracterstica, a sub-rea ou a funcionalidade do recurso.
2 - Srio Stopper Beta: Este um erro que os usurios poderiam experimentar tais
como: corrupo de dados, erros de clculo, dados incorretos, UE de e falha
do sistema em cenrios de usurio comum, o risco de QA significativo, e
grandes defeitos UI.
18 de 25 22/11/2017 09:04
3 - Menor Viver de lanamento: Um erro que deve ser corrigido antes do produto ser
oficialmente concludo, UE de ou falha, contedo e interface do usurio e as
mudanas grficas necessrias para a liberao.
7.1 Vrias funes na resoluo de erros
Autor - A pessoa que escreveu o bug; este ser algum na equipe de QA

Resolver - Normalmente um engenheiro designado para uma rea especfica da aplicao.
Verificador - normalmente um engenheiro de QA responsvel por testar a correo e fechar o bug.
7.2 Formulrio de Relatrio de Erro
19 de 25 22/11/2017 09:04
8 Papis e responsabilidades
8.1 Equipe de desenvolvimento

Lder do Projeto de Desenvolvimento de Cdigo - V. Stanton
Certifique-se de que a Fase 1 seja entregue programao e qualidade
20 de 25 22/11/2017 09:04
Certifique-se de que os critrios de sada sejam alcanados antes do sinal de teste do sistema
Revise regularmente o progresso do teste com o controlador de teste.
Levantar e gerenciar problemas / riscos relacionados ao controle de equipes de teste de projeto ou
externo.
Revise e assine a abordagem de teste, planos e cronograma.
SQA Projeto Lder - H. Frezghi
Revise regularmente o progresso dos testes
Gerenciar problemas / riscos relacionados Equipe de Teste do Sistema
Fornecer recursos necessrios para completar o teste do sistema
8.2 Equipe de teste
Test Planner / Controller - N. Monge

Produza condies de teste de alto nvel e detalhadas
Produzir resultados esperados
Relatar o progresso em reunies peridicas de relatrios de status
Reviso coordenada e assinatura de condies de teste
Gerencie os ciclos de teste individuais e resolva consultas / problemas do testador.
Probador de chumbo - T. Wilkinson
Identificar dados de teste

Execute condies de teste e resultados de marcao
Preparar relatrios de erros de software
Administre o sistema de medio de erros
Certifique-se de que os interrupes / problemas dos sistemas de teste so relatados imediatamente e
seguidos.
Certifique-se de que os critrios de entrada sejam alcanados antes do incio do teste do sistema.
Certifique-se de que os critrios de sada sejam alcanados antes do sinal de teste do sistema.
9 Programao de teste
A seo contm o cronograma geral do projeto. Discute as fases e os principais marcos relacionados com a
garantia de qualidade. Ele discute os objetivos e padres de teste que gostaramos de alcanar para cada fase
de teste que ser implantada, por exemplo, teste de usabilidade, aceitao completa de cdigo, teste beta, teste
de integrao, teste de regresso, teste de sistema.
As datas-chave para o desenvolvimento geral da rvore Binria e Testes so descritas abaixo. Para obter
detalhes sobre o cronograma, consulte a Agenda do projeto da rvore binria (este documento). Para obter
detalhes sobre produtos de qualidade de engenharia geral, consulte o documento do plano de teste.
Milhas do
programa de Data final Notas QA Entregveis / Funes
rvore binria
21 de 25 22/11/2017 09:04
Milhas do
rvore binria
Fase de 20/02/03 Neste marco, o planejamento de Atividades de planejamento de
planejamento alto nvel deve ser concludo. testes de alto nvel, que incluem
Algumas das entregveis so: o desenvolvimento preliminar do
Plano do projeto, especificaes Plano de QA mestre (este
da funo do programa. documento, cronograma de
controle de qualidade).
Fase de desenho 27/02/03 Este um marco orientado para os Os engenheiros de
recursos, onde os requisitos e as desenvolvimento e teste
iniciativas so definidas e as participam ativamente do design
solues so finalizadas. As de recursos, inspecionando e
entregveis para esta fase so o revisando os requisitos e
cdigo-fonte do programa e outros documentos de design. medida
documentos relacionados ao que os documentos de design so
design. concludos, os engenheiros de
teste so encorajados a comear a
trabalhar no documento do Plano
de Teste e a testar o planejamento
do projeto.
Cdigo 03/06/03 Este marco quando todo o Os engenheiros de teste deve ter
completo desenvolvimento e funes da concludo ou em fase final do seu
-A infraestrutura infraestrutura devem ser plano de teste de infra-estrutura
completos. A equipe de teste deve preliminar, casos de teste e outros
ter testes de unidade e integrao documentos de controle de
pr-formados antes de verificar o qualidade do exame de execuo
cdigo em qualquer compilao. para cada recurso ou
componente, como cenrios de
teste, resultados esperados,
conjuntos de dados,
procedimentos de teste, scripts e
aplicvel ferramentas de teste.
code Complete 03/10/03 Esta etapa inclui o teste de Os engenheiros de teste deve ter
-Funo unidade e de reviso de cdigo de fornecido Cdigo Teste de
cada componente funo antes de Avaliao Completo para
verificar o cdigo para a fase de Engenheiro de Desenvolvimento
teste. Os resultados incluem de uma semana antes da data
especificao de testes de sistema, Code Complete Review. Os
especificaes de testes de engenheiros de teste deve
unidade, plano de integrao. tambm ter concludo ou em fase
final do seu plano de teste
preliminar White Box, casos de
teste e outros documentos de
controle de qualidade do exame
de execuo para cada recurso ou
componente, como cenrios de
teste, resultados esperados,
22 de 25 22/11/2017 09:04
Milhas do
rvore binria
conjuntos de dados,
procedimentos de teste, scripts e
ferramentas de teste aplicveis.
beta Pronto 03/15/03 Este marco representa que todos 2 semanas regresso da rvore
os recursos esto prontos para o binria apresenta a Beta ea
desligamento verso beta. preparao para Shutdown Beta.
caracterstica 03/15/03 Esta fase permite recurso de Todos os erros verificados e
completa limpar para verificar restantes documentao QA finalizado.
correes de bugs e testes de Os engenheiros de teste deve
regresso em torno das correes avaliar que caractersticas Binary
de bugs. Este marco indica que o Tree est pronto para regresso
recurso est pronto para regresso Beta e j comearam seus
Beta. relatrios preliminares resumo do
teste.
Teste de 03/20/03 Este marco representa que todo o execuo de testes de regresso
regresso cdigo e GUI interface de rvore completa do sistema e atualize
binria com a rvore binria est Relatrios Resumidos Teste
pronto para testes de regresso. completas para regresso.
Navio / Vivo 04/03/03 Produto est fora. Todos os documentos de teste
inacabadas deve ser completa.
A programao Microsoft Project est includo no final deste documento.
10 entregas
Especificaes Funo Programa
cdigo fonte do programa
documento plano de teste - este documento dever abordar os objetivos do teste, critrios, normas,
prazos e atribuies, e ferramentas de teste.
- Plano de Testes Unitrios
- Plano de integrao
- Plano de Teste do Sistema
Teste Documento de Concepo

- Unit design de teste de caixa-branca - cobre critrios de teste branco, mtodos e casos de teste
- Unit design de teste caixa-preta - cobre critrios de teste caixa-preta, mtodos e casos de teste
- projeto de teste do sistema - cobre critrios de teste do sistema, mtodos e casos de teste, scripts.
documento de relatrio de teste

- Unidade de caixa branca relatrio de ensaio - cobre unidade branca resultados do teste caixa,
problemas, resumo e anlise
23 de 25 22/11/2017 09:04
- Unidade de caixa-preta relatrio de ensaio - cobre resultados caixa preta unidade de teste,
problemas, resumo e anlise
- Relatrio de teste do sistema - cobre resultados de teste do sistema, problemas, resumo e anlise
24 de 25 22/11/2017 09:04
11 Referncias
Pressman, Roger S. Engenharia de Software - Abordagem de um praticante . Quinta edio. McGraw-Hill,

Inc.
Kaner, C., Falk, J., Nguyen, H.-Q. O teste de software de computador . Wiley Computer Publishing, 1999.
Plano de Teste de Software 1
25 de 25 22/11/2017 09:04

Plano de Teste de Software para Árvore Binária de Pesquisa

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Plano de Teste de Software para Árvore Binária de Pesquisa

Uploaded by

Copyright:

Available Formats

Documento fazer Plano de Teste Maior https://translate.googleusercontent.

VHTN Software Development

Plano de Teste de Software

1.1 Interao em equipe

A equipe de teste trabalhar em estreita colaborao com a equipe de desenvolvimento para

3 Viso geral do processo

O seguinte representa o fluxo geral do processo de teste:

4. Identifique os resultados esperados para cada teste.

5. Documentar a configurao do caso de teste, os dados do teste e os resultados esperados.

6. Execute o (s) teste (s).

Figura 1: fluxo de processo de teste

O diagrama acima descreve a abordagem do processo de teste que ser seguida.

Item (s) a ser testado

Figura 2: modelo de caso de teste

5.1 Teste de Unidade

5.1.1 White Box Testing

5.1.1.1 Teste de filial

5.1.2 Black Box Testing

5.1.2.1 Particionamento equivalente

Evento de Entrada / Sada Classes de equivalncia vlida Classes de equivalncia

Ingresar nmeros inteiros Inteiros entre -999 e 999 Inteiros> 999

No-inteiros (valores decimais)

Nenhum contedo do arquivo

o arquivo existe Arquivo no existe

Armazenar arquivo externo o arquivo existe Arquivo no existe

5.1.2.2 Teste de valor de limite

Faixa aceitvel: -999 x 999

Testes de limites vlidos:

Testes de limites invlidos:

5.2 Teste de integrao

5.2.1 Teste incremental

para completar a integrao.

Mdulo 1 - Mdulo de interface de usurio grfico (GUI)

Mdulo 2 - Mdulo de backend do repositrio de rvores

O "repositrio de rvores" fornece o armazenamento para os elementos de dados e implementa os algoritmos

5.3 Teste do Sistema

5.3.1 Teste de Validao de Funo

Funo Comportamento esperado

Loja consulte a especificao do programa de software

Inserir consulte a especificao do programa de software

Excluir consulte a especificao do programa de software

Pesquisa consulte a especificao do programa de software

Claro consulte a especificao do programa de software

Lista em ordem ascendente consulte a especificao do programa de software

Lista em ordem decrescente consulte a especificao do programa de software

Alm disso, vamos testar:

5.3.2 Teste de performance

6 Critrios de Entrada e Sada

6.1 Teste de Unidade

6.1.1 Black Box Phase

6.1.1.1 Critrios de entrada na caixa preta

Os critrios de entrada da caixa preta dependero da especificao do componente e dos requisitos da

6.1.1.2 Critrios de sada da caixa preta

6.1.2 Fase da caixa branca

6.1.2.1 Critrios de entrada na caixa branca

6.1.2.2 Critrios de sada da caixa branca

6.2 Teste de integrao

6.2.1 Critrios de Entrada de Teste de Integrao

etapa de Teste de Integrao:

6.2.2 Critrios de sada do teste de integrao

Todos os erros de cdigo que esto expostos so corrigidos.

6.3 Teste do sistema