Documento de Testes

Prévia do material em texto

CredRU v1.0 
 
 
 
 
TRABALHO FINAL 
Verificação e validação 
 
 
 
 
Aplicação: 
CedRU 
Sistema Gerenciador de Restaurante Universitário 
 
 
 
 
 
 
 
 
Equipe: 
Erley Diangelys A. Araújo 
Matheus de Oliveira Silva 
Suzana Karen da Silva Gomes 
Leonh Matheus 
Paulo Victor Alencar Sêrejo 
 
 
 
 
 
 
 
 
Página 1
 
 
CredRU v1.0 
 
 
 
 
 
 
Histórico da Revisão 
 
D​ATA V​ERSÃO D​ESCRIÇÃO A​UTOR 
12/06/2019 0.1 Escolha do Sistema e Introdução Erley Diangelys 
14/06/2019 0.2 Criação dos Casos de Teste Erley Diangelys 
14/06/2019 0.3 Revisão dos casos Matheus Silva 
15/06/2019 0.4 Formatação Inicial do Documento Suzana Karen 
15/06/2019 0.5 Revisão da Formatação 
Paulo Victor 
Leonh Matheus 
15/06/2019 1.0 Análise dos resultados dos testes Erley Diangelys 
17/06/2019 1.0 Revisão Geral 
Erley Diangelys 
Suzana Karen 
Matheus Silva 
Paulo Victor 
Leonh Matheus 
18/06/2019 1.0 Considerações Finais Matheus Silva 
Suzana Karen 
25/06/2019 1.0 Entrega do Trabalho 
Erley Diangelys 
Suzana Karen 
Matheus Silva 
Paulo Victor 
Leonh Matheus 
 
 
 
Página 2
 
 
CredRU v1.0 
 
Sumário 
 
Cenário Geral 4 
1,1 Objetivo 4 
1.2 Posicionamento 4 
1.3 Descrição do Projeto 4 
1.4 Abrangência 4 
1.5 Papel das Partes Interessadas 5 
1.6 Necessidades e Funcionalidades 6 
1.7 Restrições 7 
1.8 Proposta de Solução Tecnológica Escolhida 7 
2. Regras 8 
2.1 Testes 8 
2.1.1 Teste caixa preta 8 
2.1.2 Teste Caixa Branca 8 
2.1.3 Análise de risco 9 
3. Estratégia de teste 10 
3.1 Estratégia para teste caixa preta 10 
3.2 Estratégia para teste caixa branca 10 
4. Projeto de caso de testes 11 
4.1 introdução 11 
4.2 Escopo 11 
4.2 Planejamento para os testes 11 
4.2.1 Necessidades de Hardware 11 
4.2.2 Necessidade de Software 11 
4.2.3 Necessidade de Pessoa 11 
4.3 Cronograma de testes 12 
4.4 Casos de Testes 12 
CT001 Acessar o sistema CredRU 12 
CT002 – Cadastrar RU 12 
CT003 – Manter Usuário 13 
CT004 – Alterar Preços 14 
CT005 – Vender Créditos 14 
5. Execução 15 
5.1Execução do teste caixa preta 15 
5.2 Execução do teste caixa branca 15 
6. Análise dos resultados e próximos passos 18 
   
 
Página 3
 
 
CredRU v1.0 
 
1. C​ENÁRIO​ G​ERAL 
 
1,1 O​BJETIVO 
 
O propósito deste documento é coletar, analisar e definir as necessidades de                       
alto-nível e características do projeto de software ​CRED RU​, focando nas                     
potencialidades requeridas pelos afetados e usuários-alvo, e como estes                 
requisitos serão abordados no projeto de software. 
A visão do projeto documenta o ambiente geral de processos a ser                       
desenvolvido para o sistema durante o projeto, fornecendo a todos os                     
envolvidos uma descrição compreensível deste e suas macro-funcionalidades. 
O Documento de Visão do Projeto documenta apenas as necessidades e                     
funcionalidades do sistema que estarão sendo atendidas no projeto de                   
software. 
 
1.2 P​OSICIONAMENTO 
 
1.2.1 Cenário 
 
A construção desse software está pautada na contestação da falta de                     
um sistema para gerenciamento dos restaurantes universitários espalhados               
nas mais diversas instâncias de uma grande universidade, a velocidade do                     
processo de venda e checagem dos créditos seria aumentada e melhorada,                     
além disso é possível destacar uma melhoria no controle de usuários e                       
estatísticas de uso​. 
 
1.2.1 Oportunidade de Negócio 
 
Suprir uma necessidade geral de grandes universidades, um software                 
para gerenciar restaurantes universitário, suas vendas, saldos e usuários.  
 
1.3 D​ESCRIÇÃO​ ​DO​ P​ROJETO 
 
A aplicação nasceu na disciplina de desenvolvimento web, após a                   
sugestão do professor da mesma, que fosse desenvolvido um sistema para                     
gerenciar restaurantes universitários, desde o gerenciamento dos alimentos               
até a venda dos créditos. 
Como funções básicas o sistema tem: manter usuários (cadastro,                 
edição e remoção), manter restaurantes universitários(adição e remoção),               
manter alimentos (adicionar novos alimentos, edição e remoção) , manter                   
cardápio (criar cardápio, adicionar alimentos e exibição), vender créditos,                 
debitar crédito e exibir perfis. O projeto pode ser encontrado seguindo o link:                         
<​https://github.com/erleydiangelys/CredRU​> 
 
1.4 A​BRANGÊNCIA 
 
 
Página 4
 
https://github.com/erleydiangelys/CredRU
 
CredRU v1.0 
 
O projeto tem potencial para impactar diretamente o dia a dia da maioria dos                           
universitários e funcionários dos campi de grandes universidades. 
 
1.5 P​APEL​ ​DAS​ P​ARTES​ I​NTERESSADAS 
 
1.5.1 Administrador 
 
 
Descrição 
Usuário responsável pela administração do sistema, 
e gerenciamento de todos os envolvidos. 
Papel 
A partir desse ator, todos os outros são cadastrados 
e mantidos no sistema, é ele também que gerencia 
todo o restaurante universitário. 
Representante 
O administrador do sistema pode ser qualquer 
gestor da empresa, que será responsável por 
administrar o sistema e manter usuários e 
funcionários. 
 
 
1.5.2 Nutricionista 
 
 
Descrição 
Responsável por manter os alimentos que compõem 
o cardápio.  
Papel 
O Nutricionista será responsável por adicionar 
novos alimentos ao cardápio e por manter a 
composição das refeições. 
Representante 
Esse papel pode ser desempenhado pelo 
nutricionista do RU. 
 
 
1.5.3 Escaneador 
 
 
Descrição 
Responsável por validar a entrada dos alunos no 
restaurante universitário. 
Papel 
O Escaneador será responsável por debitar os 
créditos virtuais e liberar a entrada dos alunos no 
recinto 
Representante 
Esse papel pode ser desempenhado por um 
funcionário qualquer do restaurante universitário, 
previamente treinado a usar o sistema. 
 
 
1.5.4 Usuário Comum 
 
 
Descrição 
O usuário comum será todo aquele que apenas 
utiliza o sistema para ter acesso a alimentação 
Papel 
Responsável unicamente por comprar créditos para 
ter acesso ao sistema. 
Representante 
Esse papel pode ser desempenhado pelos alunos 
que usarão o sistema. 
 
Página 5
 
 
CredRU v1.0 
 
 
 
1.6 N​ECESSIDADES​ ​E​ F​UNCIONALIDADES 
 
Necessidade 1 - ​Visualizar perfil  Benefício 
Os envolvidos no sistema precisam ter acesso a um perfil para visualizar suas 
informações e saldos 
Crítico 
001  Descrição das Funcionalidades/atores envolvidos 
F001 
visualizar perfil 
Usuário Comum, Administrador, Nutricionista, Escaneador 
 
 
 
 
Necessidade 2 - ​Manter Usuário  Benefício 
É necessário manter informações dos usuários que utilizarão o sistema  Crítico 
002   Descrição das Funcionalidades/atores envolvidos 
002  
Manter (adicionar, remover, visualizar e editar) informações dos usuários 
cadastrados no sistema 
Administrador 
 
 
Necessidade 3 - ​Vender Créditos  Benefício 
É necessário vender créditos para acesso ao restaurante universitário  Crítico 
003  Descrição das Funcionalidades/atores envolvidos 
003  
Vender créditos 
Administrador 
 
 
Necessidade 4 - ​Cadastrar Restaurante Universitário  Benefício 
É necessário os restaurantes universitários que serão administrados pelo 
sistema 
Crítico 
004  Descrição das Funcionalidades/atores envolvidos 
004  
Adicionar e editar informações dos restaurantes universitários cadastrados no 
sistema 
Administrador 
 
 
Necessidade 5 - ​Visualizar Relatórios  Benefício 
É necessário ter acesso a informações acerca do uso do restaurante 
universitário pelos usuários que utilizarão o sistema 
Crítico 
005  Descrição das Funcionalidades/atores envolvidos 
005  
Visualizar relatórios disponibilizados pelo sistema 
Administrador 
 
 
Necessidade 6 - ​Alterar Preços  Benefício 
É necessário alterar preçosdas refeições sempre que alguma mudança interna 
possibilitar isso. 
Crítico 
006  Descrição das Funcionalidades/atores envolvidos 
006  
alterar preços das refeições 
Administrador 
 
 
Necessidade 7 - ​Debitar Créditos  Benefício 
 
Página 6
 
 
CredRU v1.0 
 
É necessário debitar os créditos dos usuários para permitir o ingresso no local 
de alimentação 
Crítico 
007  Descrição das Funcionalidades/atores envolvidos 
007  
Debitar Créditos 
Escaneador 
 
 
Necessidade 8 - ​Cadastrar Alimento  Benefício 
É necessário cadastrar os alimentos que farão parte das refeições servidas no 
restaurante 
Crítico 
008  Descrição das Funcionalidades/atores envolvidos 
008  
Cadastrar Refeição 
Nutricionista 
 
 
Necessidade 9 - ​Cadastrar Refeição  Benefício 
É necessário cadastrar as refeições que serão servidas no restaurante 
universitário 
Crítico 
009  Descrição das Funcionalidades/atores envolvidos 
009  
Cadastrar refeições 
Nutricionista 
 
 
 
1.7 R​ESTRIÇÕES 
 
É importante atentar-se aos diferentes tipos de usuários que utilizam do                       
restaurante universitário todos os dias, pois existem diferentes preços para estes.                     
Alunos residentes são isentos de taxa, enquanto alunos comuns pagam R$1,10 por                       
refeição. Usuários externos pagam um valor de R$5,50 por refeição.   
 
 
1.8 P​ROPOSTA​ ​DE​ S​OLUÇÃO​ T​ECNOLÓGICA​ E​SCOLHIDA 
 
A linguagem de programação utilizada será JAVA aplicando a tecnologia JSP                     
(Java Server Page), conjuntamente serão usadas tecnologias voltadas para o                   
front-end como HTML, CSS e JavaScript, além do framework BOOTSTRAP para                     
simplificar e padronizar os elementos que compõe a interface gráfica do sistema. No                         
desenvolvimento será usada a IDE NETBEANS e o web container GLASS FISH para                         
testes. 
   
 
Página 7
 
 
CredRU v1.0 
 
 
2. R​EGRAS 
 
2.1 T​ESTES  
2.1.1 T​ESTE​ ​CAIXA​ ​PRETA 
O Teste de Caixa-Preta ou Teste Funcional, também é usado na                     
engenharia de software, no problema de identificação de sistemas, e advém                     
do fato de que ao analisar o comportamento de um objeto, ignora-se                       
totalmente sua construção interna. 
 
Nesse tipo de teste, uma determinada função g() que não aceita                     
valores negativos, mas não possui tratamento adequado de exceção, poderia                   
ser testada para cem mil valores diferentes no intervalo [0...10​6​], sem que                       
fosse detectado algum defeito. 
 
O teste de caixa-preta é baseado nos requisitos funcionais do                   
software. Como não há conhecimento sobre a operação interna do programa,                     
o avaliador se concentra nas funções que o software deve desempenhar. A                       
partir da especificação são determinadas as saídas esperadas para certos                   
conjuntos de entrada de dados. 
 
Esse tipo de teste reflete, de certa forma, a óptica do usuário, que está                           
interessado em se servir do programa sem considerar os detalhes de sua                       
construção. Comparando a outros tipos de teste, este é relativamente mais                     
simples. 
 
 
2.1.2 T​ESTE​ C​AIXA​ B​RANCA 
T​ambém conhecido como teste estrutural. É aquele em que o analista                     
tem total acesso à estrutura interna da entidade sendo analisada e permite,                       
por exemplo, que o analista escolha partes específicas de um componente                     
para serem testadas. 
 
O fato de conhecer o código do programa permite que o avaliador                       
projete testes mais precisos. Por exemplo, se a definição de uma função ​g()​,                         
para um determinado programa, afirma que ela não aceita valores negativos,                     
um avaliador poderia provocar uma chamada ​fun(-1) e descobrir que um                     
tratamento de exceções não está corretamente implementado. 
 
Esses testes são projetados em função da estrutura do componente e                     
podem permitir verificação mais precisa de comportamento do produto. Ele                   
permite ao avaliador concentrar a atenção nos pontos mais importantes ou                     
“perigosos” do código, de uma maneira mais precisa do que no caso do teste                           
caixa-preta. Tais pontos podem até ser identificados durante o                 
desenvolvimento e cobertos com o uso de assertivas e testes. 
 
 
 
Página 8
 
 
CredRU v1.0 
 
 
2.1.3 A​NÁLISE​ ​DE​ ​RISCO 
 
A análise de risco no processo de teste de software tem o objetivo de avaliar os                               
fatores cujas ocorrências podem vir a acarretar falhas no sistema e perda para a                           
empresa. É uma avaliação dos recursos de informação de uma organização, dos                       
seus controles e das suas vulnerabilidades. A análise de riscos combina a                       
probabilidade de ocorrência de um problema com a gravidade e o grau de prejuízos                           
que os danos poderão acarretar. 
 
Um risco apenas vira uma ameaça quando existe uma vulnerabilidade. Dentro de                       
um o processo de teste de software, uma análise de risco envolve a identificação das                             
ameaças mais prováveis em conjunto com o exame das vulnerabilidades                   
relacionadas ao software. Os motivos que podem levar ao risco são muitos, como                         
por exemplo, um processo de teste mal definido ou até mesmo não conduzido de                           
forma planejada. 
   
 
Página 9
 
 
CredRU v1.0 
 
 
 
3. E​STRATÉGIA​ ​DE​ ​TESTE 
 
3.1 E​STRATÉGIA​ ​PARA​ ​TESTE​ ​CAIXA​ ​PRETA 
Será utilizada a técnica de particionamento por classe de equivalência sobre os                       
casos de uso 6 e 7 (debitar crédito e atualizar preço) casos de uso esses baseados                               
nas necessidades 6 e 7 apresentados na seção 1 deste documento. 
 
 
Partições a ser verificada para o caso de uso 6: 
 
Partição Inválida  Partição válida 
Quant crédito<0  Quant crédito >0 
 
 
Partições a ser verificada para o caso de uso 7: 
 
 
Partição Inválida  Partição válida  Partição inválida 
valores <0  0 < valores <7,00$  valores > 7,00$ 
 
 
 
3.2 E​STRATÉGIA​ ​PARA​ ​TESTE​ ​CAIXA​ ​BRANCA 
Será utilizada uma análise estática automatizada utilizando a ferramenta PMD                   
ferramenta essa que detecta erros e cold smells (mal cheiro de designers). 
 
Exemplo de relatório: 
 
 
 
 
Página 10 
 
 
CredRU v1.0 
 
 
4. P​ROJETO​ ​DE​ ​CASO​ ​DE​ ​TESTES 
4.1 ​INTRODUÇÃO 
Este documento de Plano de Teste tem o objetivo de documentar as informações                         
necessárias para planejar e controlar os testes de validação do projeto CredRU v.1.0.                         
O documento descreve o plano geral de testes referente aos cadastros básicos de                         
forma a direcionar os esforços de teste e os Casos de Teste a serem executados                             
para validar o produt​o. 
 
  4.2 E​SCOPO 
Este documento descreve o Plano de Testes a ser usado pelo projeto CredRU v.1.0                           
para avaliar a qualidade funcional, confiabilidade e performance.  
 
  4.2 P​LANEJAMENTO​ ​PARA​ ​OS​ ​TESTES 
4.2.1 N​ECESSIDADES​ ​DE​ H​ARDWARE 
T​IPO​ ​DE 
H​ARDWARE 
D​ETALHAMENTO  Q​UANTIDADE  F​ORMA​ ​DE 
D​ISPONIBILIZAÇÃO 
D​ATA​ L​IMITE  
Servidor WEB    1  Corporativo  15/06/2019 
 
4.2.2 N​ECESSIDADE​ ​DE​ S​OFTWARE 
T​IPO​ ​DE​ S​OFTWARE  D​ETALHAMENTO  Q​UANTIDADE  F​ORMA​ ​DE 
D​ISPONIBILIZAÇÃO 
D​ATA​ L​IMITE  
Navegador WEB –     
Google Chrome 
Versão 2.2 ouSuperior 
1  Corporativo  15/06/2019 
Navegador WEB - Mozilla       
Firefox  
Versão 3.1 ou 
Superior 
1  Corporativo  15/06/2019 
 
4.2.3 N​ECESSIDADE​ ​DE​ P​ESSOA 
P​APEL  E​NVOLVIMENTO 
E​STIMADO  Q​UANTIDADE 
P​ERÍODO​ ​DE​ E​NVOLVIMENTO 
NO​ P​ROJETO 
Testador  2 horas  1  15/06/2019 a 15/06/2019 
 
 
Página 11 
 
 
CredRU v1.0 
 
 
 
 
 
 
 
4.3 C​RONOGRAMA​ ​DE​ ​TESTES 
 
TESTES DE SISTEMA 
A​TIVIDADE  D​ATA​ ​DE​ I​NÍCIO  D​URAÇÃO 
(​HORAS​) 
P​APEL​ R​ESPONSÁVEL​/E​NVOLVIDOS 
Preparar o ambiente de teste  15/06/2019  1 hora  Testador 
Realizar os testes  15/06/2019  1 hora  Testador 
 
4.4 C​ASOS​ ​DE​ T​ESTES 
Para a definição dos Casos de Teste foi utilizado o software desenvolvido e a Especificação                             
de Casos de Uso. 
 
C​ASO​ N​O 
CT001 A​CESSAR​ ​O​ ​SISTEMA​ C​RED​RU  
O​BJETIVO 
DO​ T​ESTE 
Verificar se o usuário consegue efetuar o login. 
P​ASSOS 
1. Acessar a página de login do CredRU: 
Menu iniciar > Programas > Navegador. 
2. No campo endereço, digite: 
 ​http://localhost:8080/CredRU/Visitante?comando=Login 
3. Informe o usuário:  
 ​ 3.1 ​Comprador: compra  
 ​3.2 ​Nutricionista: nutri 
 ​3.3 ​Escaneador: escan 
 ​3.4 ​Administrador: admin 
4. Informe a senha: senha 
 
C​RITÉRIOS 
DE​ Ê​XITO 
O usuário deve conseguir acessar a próxima tela onde tem o menu de funcionalidades                           
disponíveis para o seu respectivo perfil. 
 
C​ASO​ N​O 
CT002 – C​ADASTRAR​ RU 
 
O​BJETIVO 
DO​ T​ESTE 
Verificar se o usuário consegue cadastrar o RU 
P​ASSOS  1. Executar o CT001 com o perfil de administrador; 
 
Página 12 
 
 
CredRU v1.0 
 
2. Clicar em “Cadastrar RU”; 
3. O sistema irá carregar a tela de cadastro mostrando os campos Nome, Hora                         
Início e Hora Final para o Horário de Funcionamento dos turnos Manhã, Tarde e                           
Noite. 
4. O usuário informa o nome do RU (informação obrigatória); 
5. O usuário informa a hora início e hora final do horário de funcionamento no                           
período manhã (informação obrigatória); 
6. O usuário informa a hora início e hora final do horário de funcionamento no                           
período tarde (informação obrigatória); 
7. O usuário informa a hora início e hora final do horário de funcionamento no                           
período noite (informação obrigatória); 
8. Para finalização do cadastro, clicar sobre o botão “Registrar”. 
 
C​RITÉRIOS 
DE​ Ê​XITO 
1. O usuário deve conseguir realizar o cadastro do RU; 
2. As informações referentes ao RU deverão ser salvas na memória.; 
3. O sistema retorna mensagem de êxito ou de falha do processo. 
 
 
C​ASO​ N​O 
CT003 – M​ANTER​ U​SUÁRIO 
O​BJETIVO 
DO​ T​ESTE 
Verificar se o usuário consegue cadastrar e editar um usuário.  
P​ASSOS 
1. Acesso ao sistema. 
1. Executar o CT001 com o perfil de Administrador. 
2. Cadastrar Usuário. 
1. Clicar na opção “Cadastrar Usuário”; 
2. O sistema irá carregar a tela de cadastro mostrando os campos Nome                       
Completo, Usuário, Status, Nível de Acesso, Perfil, Crie uma senha,                   
Confirme sua senha; 
3. O usuário informa o nome completo (informação obrigatória); 
4. O usuário informa o nome de usuário (informação obrigatória); 
5. O usuário seleciona o status (informação obrigatória); 
6. O usuário seleciona o nível de acesso (informação obrigatória); 
7. O usuário seleciona o perfil (informação obrigatória); 
8. O usuário informa a senha (informação obrigatória); 
9. O usuário informa a senha novamente (informação obrigatória); 
10. Para finalização do cadastro, clicar sobre o botão “Registrar”. 
3. Editar Usuário. 
1. Clicar na opção “Alterar Usuário”; 
2. O sistema irá carregar a tela de edição com o campo Usuário; 
3. O usuário informa o nome de usuário; 
4. O usuário clica no botão “Pesquisar”; 
5. O sistema irá carregar a tela de edição com o retorno das informações                         
do usuário informado nos campos Nome Completo, Usuário, Status,                 
Nível de Acesso, Perfil; 
6. O usuário informa a senha (campo obrigatório); 
7. O usuário informa a senha novamente (campo obrigatório); 
 
Página 13 
 
 
CredRU v1.0 
 
8. Para a finalização da alteração, clicar sobre o botão “Atualizar”. 
 
C​RITÉRIOS 
DE​ Ê​XITO 
1. Acesso ao sistema. 
1. O usuário deve conseguir acessar o sistema. 
3. Cadastrar Usuário. 
1. O usuário deve conseguir realizar o cadastro do usuário; 
2. As informações referentes ao tema deverão ser salvas no banco de dados; 
3. O sistema retorna mensagem de êxito ou de falha do processo. 
4. Editar Usuário. 
1. O usuário deve conseguir alterar o usuário; 
2. As informações referentes à alteração deverão ser salvas no banco de dados. 
 
 
 
C​ASO​ N​O 
CT004 – A​LTERAR​ P​REÇOS 
O​BJETIVO 
DO​ T​ESTE 
Verificar se o usuário consegue os preços das refeições. 
P​ASSOS 
 
1. Executar o CT001 com o perfil de Administrador; 
2. Clicar na opção “Alterar Preços”; 
3. O sistema irá carregar a tela de alteração de preço mostrando os campos de                           
aluno, professor e servidor. 
4. O usuário terá que alterar os preços equivalente ao aluno, professor e servidor. 
5. O usuário vai ter que informar se é residente, isento e autorizado. 
6. Para finalizar o usuário terá que selecionar “alterar” para que os preços possam                         
ser alterados. 
C​RITÉRIOS 
DE​ Ê​XITO 
1. O usuário deve conseguir acessar o sistema; 
2. O usuário deve conseguir realizar as alterações de preço; 
3. As informações referentes à alteração deverão ser salvas no banco de dados. 
 
 
 
C​ASO​ N​O 
CT005 – V​ENDER​ C​RÉDITOS 
O​BJETIVO 
DO​ T​ESTE 
Verificar se o usuário consegue vender créditos. 
P​ASSOS 
1. Executar o CT001 com o perfil de Administrador; 
2. Clicar na opção “Vender Créditos”; 
3. O sistema irá carregar a tela de venda de créditos mostrando o campo Nome                           
de usuário; 
4. O usuário informa o nome de usuário; 
5. O usuário seleciona o RU; 
6. O usuário clica no botão “Buscar; 
7. O sistema retorna uma tela com os valores disponíveis para compra; 
8. Para finalizar, o usuário clica no botão “Comprar” 
 
 
Página 14 
 
 
CredRU v1.0 
 
C​RITÉRIOS 
DE​ Ê​XITO 
1. O usuário deve conseguir acessar o sistema; 
2. O usuário deve conseguir realizar a venda de créditos; 
3. As informações referentes à venda de crédito deverão ser salvas no banco de                         
dados. 
 
 
5. E​XECUÇÃO 
 
 
5.1E​XECUÇÃO​ ​DO​ ​TESTE​ ​CAIXA​ ​PRETA 
Valores testados para as classes do caso de uso 6 
 
Partição Inválida  Partição válida 
Quant crédito<=-2  QUant crédito =3 
 
 
 
Valores testados para as classes do caso de uso 7 
 
Partição Inválida  Partição válida  Partição inválida 
valor = -3,00$  valor= 5,50  valor=20,00$ 
 
As saídas foram obtidas com esperado, muito disso se deve ao fato serem funções                           
simples a maior complexidade do sistema com certeza está no entendimento do                       
domínio e de suas regras. 
 
 
5.2 E​XECUÇÃO​ ​DO​ ​TESTE​ ​CAIXA​ ​BRANCA 
A ferramenta é iniciada e logo inicia a verificação automática do código em busca de                             
problemas. 
 
Página 15 
 
 
CredRU v1.0 
 
 
 
 
 
Abaixo são mostrados alguns dos problemas encontrados pela ferramenta. 
 
 
 
Página 16 
 
 
CredRU v1.0 
 
 
Foram encontrados muitos problemas pela ferramenta de verificação estática                 
evidenciando a necessidade também de muitas correções. 
 
   
 
Página 17 
 
 
CredRU v1.0 
 
6. A​NÁLISE​ ​DOS​ ​RESULTADOS​ ​E​ ​PRÓXIMOS​ ​PASSOS 
 
Após a realização dos testes foi evidenciado a necessidade de muitas                     
correções no projeto, o que indica que os testes obtiveram sucesso uma vez queidentificaram erros e problemas, que é o objetivo de qualquer teste de software. 
 
Embora os resultados tenham sido bons e considerados suficientes seria                   
interessante o uso de outras técnicas para complementares para aumentar ainda                     
mais o alcance dos testes e com isso possibilitar a identificação de novos erros. 
 
É importante destacar que o tempo aplicado a estes testes foi insuficiente o                         
que impacta muito negativamente nos resultados, com mais tempo disponível seria                     
possível apresentar mais resultados interessantes. 
 
A correção de todos os problemas encontrados seria o próximo passo a ser                         
executado que pela complexidade baixa encontrada nos erros poderia ser feito em                       
tempo hábil. 
 
Página 18