Buscar

PIM 5 - ROTEIRO DE TESTES CAIXA PRETA

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

UNIP INTERATIVA 
Projeto Integrado Multidisciplinar 
Curso: Análise e desenvolvimento de sistemas 
 
 
 
 
 
 
PROJETO DE UM ROTEIRO DE TESTES CAIXA-PRETA PARA UM SISTEMA DE 
FORMATAÇÃO DE ARTIGOS ACADÊMICOS. 
 
 
 
 
 
 
 
 
 
Polo Unip - Paraisópolis (MG) 
2019 
 
 
UNIP INTERATIVA 
Projeto Integrado Multidisciplinar 
Curso: Análise e desenvolvimento de sistemas 
 
 
 
 
 
 
PROJETO DE UM ROTEIRO DE TESTES CAIXA-PRETA PARA UM SISTEMA DE 
FORMATAÇÃO DE ARTIGOS ACADÊMICOS. 
 
 
 
Edgar de Oliveira – RA 1822238 
Fábio Luiz de Melo – RA 1816984 
Gustavo Cristiano Ferreira – RA 1866828 
Arthur Henrique B. C. Gerino – RA 1807504 
 
Curso: Análise e desenvolvimento de sistemas 
Semestre: 3º Semestre 
 
 
 
Polo Unip - Paraisópolis (MG) 
2019 
 
 
RESUMO 
 
A Engenharia de software tem como objetivo definir as especificações, 
métodos para o desenvolvimento e manutenção do software. Dentre suas 
especificações estão os testes, neste trabalho iremos abordar o teste caixa preta. 
Iremos abordar o teste seguindo dez roteiros de teste previamente 
estabelecidos. Como objetivo iremos gerar os resultados com o teste e também, 
realizar uma inspeção de usabilidade no sistema por meio da técnica de avaliação 
heurística e apresentar um relatório com os resultados. 
Palavras-chave: engenharia de software, teste, validação, caixa preta. 
 
 
 
ABSTRACT 
 
Software Engineering aims to define the specifications, methods for software 
development and maintenance. Among its specifications are the tests, in this project 
we will address the black box test. 
We will approach the test following ten previously established test scripts. As 
an objective we will generate the results with the test and also, perform a usability 
inspection in the system through the heuristic evaluation technique and present a 
report with the results. 
Keywords: software engineering, testing, validation, black box. 
 
 
 
SUMÁRIO 
 
1 INTRODUÇÃO .......................................................................................................... 6 
2 PROJETO ................................................................................................................... 7 
3 OBJETIVO ................................................................................................................. 7 
4 TESTE CAIXA PRETA ............................................................................................ 7 
4.1 DEFINIÇÃO ................................................................................................................... 7 
4.2 CASOS DE TESTES ......................................................................................................... 7 
4.3 EXECUÇÃO DOS TESTES ............................................................................................... 8 
4.3.1 Caso de teste 01 ........................................................................................................... 8 
4.3.2 Caso de teste 02 ........................................................................................................... 9 
4.3.3 Caso de teste 03 ......................................................................................................... 10 
4.3.4 Caso de teste 04 ......................................................................................................... 10 
4.3.5 Caso de teste 05 ......................................................................................................... 11 
4.3.6 Caso de teste 06 ......................................................................................................... 13 
4.3.7 Caso de teste 07 ......................................................................................................... 13 
4.3.8 Caso de teste 08 ......................................................................................................... 15 
4.3.9 Caso de teste 09 ......................................................................................................... 15 
4.3.10 Caso de teste 10 ......................................................................................................... 16 
4.3.10.1 Especificações da interface ...................................................................................... 16 
4.3.10.2 Especificações da mensagem a ser exibida ............................................................. 17 
4.3.10.3 Testes funcionais da interface ................................................................................. 17 
4.3.10.4 Avaliação heurística de usabilidade da interface .................................................. 18 
4.3.10.5 Relatório de avaliação .............................................................................................. 20 
5 CONCLUSÃO .......................................................................................................... 20 
 REFERÊNCIAS ....................................................................................................... 22 
 
 
 
6 
 
1 INTRODUÇÃO 
O teste de software não se trata de um assunto recente, contudo, no 
mercado atual de desenvolvimento de softwares, muitos fornecedores desenvolvem 
sistemas sem uma metodologia voltada à qualidade. Na maioria das vezes, o custo 
com o teste é uma das principais justificativas para não aplicar métodos visando 
obter um software com qualidade. Porém, isso é uma inverdade. O custo com a 
manutenção e o retrabalho será muito maior. Segundo Pressman, este custo pode 
chegar a 100 vezes mais nos projetos que não utilizaram metodologias de testes. 
Com a evolução no desenvolvimento de softwares, diversos métodos de 
testes surgiram. A primeira conhecida, foi no fim da década de 1970, desenvolvida 
por Jim McCall para o Departamento de Defesa, ela foi definida por um conjunto de 
características internas e externas de um software, sendo o primeiro modelo de 
qualidade a ser divulgado e utilizado. 
Iremos descrever, neste trabalho, um roteiro de testes caixa-preta para um 
sistema de formatação de artigos acadêmicos e gerar os resultados com o teste, 
conforme os casos de testes definidos no contexto do trabalho. Também, realizar 
uma inspeção de usabilidade no sistema por meio da técnica de avaliação heurística 
e apresentar um relatório com os resultados. 
No primeiro capítulo contêm a introdução do trabalho. No segundo e terceiro 
capítulo trazemos a descrição e objetivos deste trabalho. Depois, no quarto capítulo 
iremos abordar o teste caixa preta aplicado no sistema, para identificação de 
possíveis problemas na programação do sistema, assim como validar a interface do 
sistema seguindo as heurísticas apresentadas por Jakob Nielsen. Por fim teremos 
as considerações finais e referências bibliográficas utilizadas. 
 
7 
 
2 PROJETO 
O projeto consiste em criar um roteiro de testes caixa-preta para um sistema 
de formatação de artigos acadêmicos e realizar uma inspeção de usabilidade no 
sistema por meio da técnica de avaliação heurística. Os testes deverão ser 
aplicados no sistema, online, armazenado em http://sfaa.unipinterativa.edu.br/pdf/. 
3 OBJETIVO 
O trabalho tem como objetivo obter os resultados com o teste do teste caixa 
preta para casa um dos casos de teste definidos, assim como apresentar um 
relatório com os resultados da inspeção de usabilidade seguindo os parâmetros pré-
estabelecidos. 
4 TESTE CAIXA PRETA 
4.1 Definição 
Teste de caixa-preta é um teste de software para verificar a saída dos dados 
usando entradas de vários tipos sem a verificação da codificação feita pelo 
programador, daí vem o nome caixa
preta. Tais entradas não são escolhidas 
conforme a estrutura do programa. Tem como base as especificações levantadas no 
início do projeto. 
4.2 Casos de testes 
Os casos de testes são condições utilizadas no teste do software, visando 
garantir a qualidade, de acordo com as especificações de casos de uso e o protótipo 
de telas. Tem como objetivo identificar os cenários de sucesso, e insucessos que 
podem acontecer na utilização do software. 
Os casos de testes definidos neste projeto foram os seguintes: 
Quadro 1 – Casos de testes definidos para este trabalho 
Nº Descrição 
01 Gerar um artigo completo com um autor cadastrado com sucesso (nenhum campo 
pode ser branco). 
02 Gerar um artigo para submissão com um autor cadastrado com sucesso (nenhum 
campo pode ser branco). 
8 
 
03 Gerar um artigo completo com três autores cadastrados com sucesso (nenhum 
campo pode ser branco). 
04 Gerar um artigo completo com três autores com e-mails inválidos (nenhum campo 
pode ser branco). 
05 Gerar um artigo completo com três autores com os campos de autor em branco. 
06 Gerar um artigo completo com um autor cadastrado com sucesso (nenhum campo 
pode ser branco) e limpar os dados sem gerar o artigo. 
07 Gerar um artigo completo com um autor cadastrado com sucesso (nenhum campo 
pode ser branco), criando no campo “corpo de texto” um texto com trechos 
formatados em negrito, itálico, subscrito, sobrescrito e com texto justificado com 
sucesso. 
08 Gerar um artigo completo com um autor cadastrado com sucesso (nenhum campo 
pode ser branco), anexando no campo “corpo de texto” uma imagem de um arquivo 
com sucesso. 
09 Gerar um artigo completo com um autor cadastrado com sucesso (nenhum campo 
pode ser branco), anexando no campo “Notas” uma URL de um arquivo com 
sucesso e criando um texto formatado à esquerda e em negrito. 
10 Testes de interface. Além dos casos de testes relacionados às regras de negócio, 
será necessário criar os testes relativos ao comportamento técnico da tela do 
sistema. 
 
4.3 Execução dos testes 
4.3.1 Caso de teste 01 
Quadro 2 - Resultado caso de teste 01 
Caso de teste 01 
Objetivo Gerar um artigo completo com um autor cadastrado com sucesso 
(Nenhum campo pode ser branco) 
Passos para o 
teste 
Preencher todos os campos, clicar no botão “Gerar” na sessão 
“Arquivo Completo” 
Resultado Com todos campos preenchidos o arquivo foi gerado com sucesso, 
conforme Figura 01. 
Evidências Figura 01 – Resultado do caso de teste 01
9 
 
 
Fonte: Captura de tela do sistema testado 
 
 
4.3.2 Caso de teste 02 
Quadro 3 - Resultado caso de teste 02 
Caso de teste 02 
Objetivo Gerar um artigo para submissão com um autor cadastrado com 
sucesso (Nenhum campo pode ser branco) 
Passos para o 
teste 
Preencher todos os campos, clicar no botão “Gerar” na sessão 
“Arquivo para submissão (blind review)” 
Resultado Com todos campos preenchidos o arquivo foi gerado com sucesso, 
porém em nenhum local foi incluído os dados do autor, conforme 
Figura 02. 
Evidências Figura 02 – Resultado do caso de teste 02
 
Fonte: Captura de tela do sistema testado 
10 
 
4.3.3 Caso de teste 03 
Quadro 4 - Resultado caso de teste 03 
Caso de teste 03 
Objetivo Gerar um artigo completo com três autores cadastrados com sucesso 
(Nenhum campo pode ser branco) 
Passos para o 
teste 
Preencher todos os campos, clicar no botão “Gerar” na sessão 
“Arquivo Completo” 
Resultado Com todos campos preenchidos o arquivo foi gerado com sucesso, 
com todos os dados informados para os três autores, conforme 
Figura 02. 
Evidências Figura 03 – Resultado do caso de teste 03
 
Fonte: Captura de tela do sistema testado 
 
4.3.4 Caso de teste 04 
Quadro 3 - Resultado caso de teste 04 
Caso de teste 04 
Objetivo Gerar um artigo completo com três autores com e-mails inválidos 
(Nenhum campo pode ser branco) 
Passos para o 
teste 
Preencher todos os campos, incluindo no e-mail um valor inválido 
para tal campo, por exemplo: “teste erro” e clicar no botão “Gerar” na 
sessão “Arquivo Completo” 
Resultado Ao preencher com o valor incorreto o e-mail foi exibido uma caixa de 
diálogo informando que o e-mail é inválido e mostrou um alerta visual, 
de cor vermelha, entorno do campo, conforme figuras 04 e 05. No 
entanto, esta validação só aconteceu para o primeiro autor, nos 
demais não houve validação. Conforme Figura 06. 
Evidências Figura 06 – Resultado 3 do caso de uso 04 
11 
 
 
Fonte: Captura de tela do sistema testado 
 
Figura 05 – Resultado 2 do caso de uso 04 
 
Fonte: Captura de tela do sistema testado 
 
Figura 06 – Resultado 3 do caso de uso 04 
 
Fonte: Captura de tela do sistema testado 
 
4.3.5 Caso de teste 05 
Quadro 6 - Resultado caso de teste 05 
Caso de teste 05 
Objetivo Gerar um artigo completo com três autores com os campos de autor 
em branco. 
Passos para o 
teste 
Preencher todos os campos, exceto os três campos “autor” e clicar 
no botão “Gerar” na sessão “Arquivo Completo” 
Resultado Ao os demais campos e clicar em gerar o sistema exibiu um diálogo 
informando que o campo autor deveria ser informado, confirme 
Figura 07, e mostrou um alerta visual, de cor vermelha, entorno do 
campo, conforme Figura 08. No entanto, esta validação só aconteceu 
para o primeiro autor, nos demais não houve validação. Conforme 
Figura 09. 
Evidências Figura 09 – Resultado 1 do caso de teste 05
12 
 
 
Fonte: Captura de tela do sistema testado 
 
Figura 08 – Resultado 2 do caso de teste 05 
 
Fonte: Captura de tela do sistema testado 
 
Figura 09 – Resultado 3 do caso de teste 05
 
Fonte: Captura de tela do sistema testado 
 
 
 
 
13 
 
4.3.6 Caso de teste 06 
Quadro 7 - Resultado caso de teste 06 
Caso de teste 06 
Objetivo Gerar um artigo completo com um autor cadastrado com sucesso e 
limpar os dados sem gerar o artigo. (Nenhum campo pode ser 
branco) 
Passos para o 
teste 
Preencher todos os campos, com um autor e clicar no botão 
“Limpar”. 
Resultado Ao clicar em limpar, todos os campos foram limpos, com exceção 
dos campos: “Corpo do texto”, “Notas” e “Referências bibliográficas”. 
Evidências Figura 10 – Resultado caso de teste 06 
 
Fonte: Captura de tela do sistema testado 
 
4.3.7 Caso de teste 07 
Quadro 8 - Resultado caso de teste 07 
Caso de teste 07 
Objetivo Gerar um artigo completo com um autor cadastrado com sucesso, 
criando no campo “corpo de texto” um texto com trechos formatados 
em negrito, itálico, subscrito, sobrescrito e com texto justificado com 
sucesso (Nenhum campo pode ser branco). 
Passos para o 
teste 
Preencher todos os campos e no campo “corpo de texto” incluir um 
texto com as formações solicitadas. 
Resultado No teste realizado todas as formatações foram mantidas com 
sucesso conforme podemos verificar nas Figuras 11 e 12. 
Evidências Figura11 – Preenchimento caso de teste 07
14 
 
 
Fonte: Captura de tela do sistema testado 
 
Figura 12 – Resultado caso de teste 07
 
Fonte: Captura de tela do sistema testado 
 
 
 
 
15 
 
4.3.8 Caso de teste 08 
Quadro 9 - Resultado caso de teste 08 
Caso de teste 08 
Objetivo Gerar um artigo completo com um autor cadastrado com sucesso, 
anexando no campo “corpo de texto” uma imagem de um arquivo 
com sucesso (Nenhum campo pode ser branco). 
Passos para o 
teste 
- 
Resultado Não há um botão para anexar arquivos no campo “corpo do texto” e 
não é possível colar uma imagem neste campo. 
Evidências Figura 13 – Resultado caso de teste 08 
 
Fonte: Captura de tela do sistema testado 
 
4.3.9 Caso de teste 09 
Quadro 10 - Resultado caso de teste 09 
Caso de teste 09
Objetivo Gerar um artigo completo com um autor cadastrado com sucesso, 
anexando no campo “Notas” uma URL de um arquivo com sucesso e 
criando um texto formatado à esquerda e em negrito (Nenhum campo 
pode ser branco). 
Passos para o 
teste 
Preencher todos os dados, incluindo uma URL no campo de Notas, 
com alinhamento a esquerda e negrito, depois clicar em “Gerar” 
Resultado No teste realizado a formatação de negrito foi mantida, porém o 
alinhamento passou a ser justificado, conforme podemos verificar nas 
Figuras 14 e 15. 
Evidências Figura14 – Preenchimento caso de teste 09
16 
 
 
Fonte: Captura de tela do sistema testado 
 
Figura 15 – Resultado caso de teste 09 
 
Fonte: Captura de tela do sistema testado 
 
4.3.10 Caso de teste 10 
Neste tópico iremos abordar os testes realizados na interface do sistema. 
Estes testes são importantes para garantir uma correta entrada de dados, fazendo 
que o sistema se torne mais robusto e confiável. 
4.3.10.1 Especificações da interface 
Quadro 11 – Especificações da interface 
Elemento Descrição Tipo/tamanho Formato Validação 
Campo Título Alfa (livre) Alinhado à 
esquerda 
Deve ser preenchido 
Campo Título em 
inglês 
Alfa (livre) 
 
Alinhado à 
esquerda 
 
Deve ser preenchido 
 
Botão Autores Botão - Adiciona autor 
Campo Autor Alfa (livre) Alinhado à 
esquerda 
Deve ser preenchido 
 
Campo Titulação Alfa (livre) Alinhado à 
esquerda 
Deve ser preenchido 
 
17 
 
Campo Vínculo 
institucional 
Alfa (livre) Alinhado à 
esquerda 
Deve ser preenchido 
 
Campo E-mail de 
contato 
Alfa(livre) 
 
Alinhado à 
esquerda 
Deve ser preenchido, dever 
ser um e-mail válido 
Campo Resumo Alfa (1000) Alinhado à 
esquerda 
Deve ser preenchido, não 
pode ultrapassar 1000 
caracteres 
 
Campo Palavras-
Chave 
Alfa (livre) 
 
Alinhado à 
esquerda 
Deve ser preenchido 
 
Campo Abstract Alfa (1000) Alinhado à 
esquerda 
Deve ser preenchido, não 
pode ultrapassar 1000 
caracteres 
Campo Keywords Alfa (livre) 
 
Alinhado à 
esquerda 
Deve ser preenchido 
 
Campo Corpo do 
texto 
Alfa (livre) Alinhado à 
esquerda 
Deve ser preenchido 
 
Campo Notas Alfa (livre) Alinhado à 
esquerda 
Deve ser preenchido 
 
Campo Referências 
bibliográficas 
Alfa (livre) Alinhado à 
esquerda 
Deve ser preenchido 
 
Botão Arquivo 
completo 
Botão 
 
- Gera arquivo completo 
Botão Arquivo para 
submissão 
(blind review) 
Botão 
 
- Gera arquivo para submissão 
Botão Limpar Botão 
 
- Limpa campos 
 
4.3.10.2 Especificações da mensagem a ser exibida 
Quadro 12 - Especificações da mensagem a ser exibida 
Element
o 
Descrição Situação Mensagem a ser exibida 
Botão Gerar Autor não preenchido Por favor, verifique o campo 
Autor 
Botão Gerar Titulação não preenchido Por favor, verifique o campo 
Titulação 
Botão Gerar Vínculo institucional não 
preenchido 
Por favor, verifique o campo 
Vínculo institucional 
Botão Gerar E-mail de contato não 
preenchido 
Por favor, verifique o campo 
E-mail 
4.3.10.3 Testes funcionais da interface 
Quadro 13 – Testes funcionais da interface 
18 
 
 
 
 
 
Campo Título OK Livre 
OK 
Texto 
OK 
Não 
OK 
Aceita OK - - 
Campo Título em 
inglês 
OK Livre 
OK 
Texto 
OK 
Não 
OK 
Aceita OK - - 
Botão Autores OK - - - - - - OK 
Campo Autor OK Livre 
OK 
Texto 
OK 
Sim 
OK 
Aceita OK - - 
Campo Titulação OK Livre 
OK 
Texto 
OK 
Sim 
OK 
Aceita OK - - 
Campo Vínculo 
institucional 
OK Livre 
OK 
Texto 
OK 
Sim 
OK 
Aceita OK - - 
Campo E-mail de 
contato 
OK Livre 
OK 
E-mail 
OK 
Sim 
OK 
Aceita OK - - 
Campo Resumo OK 1000 
OK 
Texto 
OK 
Não 
OK 
Aceita OK - - 
Campo Palavras-
Chave 
OK Livre 
OK 
Texto 
OK 
Não 
OK 
Aceita OK - - 
Campo Abstract OK 1000 
OK 
Texto 
OK 
Não 
OK 
Aceita OK - - 
Campo Keywords OK Livre 
OK 
Texto 
OK 
Não 
OK 
Aceita OK - - 
Campo Corpo do 
texto 
OK Livre 
OK 
Texto 
OK 
Não 
OK 
Aceita OK - - 
Campo Notas OK Livre 
OK 
Texto 
OK 
Não 
OK 
Aceita OK - - 
Campo Referências 
bibliográficas 
OK Livre 
OK 
Texto 
OK 
Não 
OK 
Aceita OK - - 
Botão Arquivo 
completo 
OK - - - - - - OK 
Botão Arquivo para 
submissão 
OK - - - - - - OK 
Botão Limpar OK - - - - - - Não limpa 
todos 
campos 
 
4.3.10.4 Avaliação heurística de usabilidade da interface 
Segundo LIESENBERG (2005), a inspeção de usabilidade tem como 
objetivo remover todo e qualquer erro antes do teste com o usuário. Neste momento 
pode-se ter novas ideia que irão facilitar a utilização da interface. 
D
es
cr
iç
ão
 
E
le
m
en
to
 
O
rt
o
g
ra
fi
a 
O
b
ri
g
at
ó
ri
o
 
T
am
an
h
o
 d
o
s 
ca
m
p
o
s 
C
ar
ac
te
re
s 
es
p
ec
ia
is
 
V
al
o
re
s 
d
e 
d
o
m
ín
io
 
O
rd
em
 
al
fa
b
ét
ic
a 
N
av
eg
aç
ão
 
F
o
rm
at
o
 
19 
 
Na inspeção de usabilidade, avaliadores especialistas em desenvolvimento 
de interfaces utilizam-se de métodos específicos para avaliações. A avaliação 
heurística é uma destas avaliações realizadas. Nesta avaliação diversos avaliadores 
realizam testes seguindo heurísticas pré-estabelecidas. 
A seguir será realizada avaliação do sistema seguindo as heurísticas 
apresentadas por Jakob Nielsen. Jakob Nielsen é um cientista da computação com 
Ph.D. em interação homem-máquina 
Quadro 14 – Resultado da avaliação de usabilidade da interface 
Item avaliado Resultado 
Visibilidade do estado do sistema O sistema tem design bem definido e 
oportunamente mostra-se de fácil 
utilização. Não demostrou em nenhum 
momento da utilização que pudesse deixar 
o usuário “perdido”. 
Correlação entre o sistema e o mundo real Sistema possui palavras e frases que 
correlacionam com o mundo real. Botões e 
campos tem suas descrições bem claras e 
objetivas. 
Liberdade e controle do usuário O sistema não possui opção para que 
depois de clicar em gerar o arquivo, o 
usuário possa retornar e corrigir 
informações sem que seja necessário 
redigitar todo as informações novamente. 
Consistência e padrões Não foram encontradas controvérsias nas 
palavras e frases dos campos ou botões. 
Na verdade, os botões de gerar arquivos 
possuem exatamente a mesma descrição. 
Prevenção de erros Não foram encontrados erros não 
esperados. Os campos obrigatórios 
apresentam mensagem de validação 
(exceto para os autores adicionais). 
Nenhum erro ou BUG foi encontrado. 
Reconhecimento em vez de memorização Design claro e intuitivo, não é necessária 
nenhuma explicação para utilização do 
20 
 
sistema. O usuário em seu primeiro contato 
já consegue usar sem qualquer 
treinamento. 
Flexibilidade e eficiência de uso Não existe nenhum atalho ou ação 
personalizável para este sistema. 
Projeto estético e minimalista Os diálogos exibidos são claros e cordiais. 
Deixando claro o que o usuário deve fazer 
para corrigir o que não está válido. 
Suporte para o usuário no reconhecimento, 
no diagnóstico e na recuperação de erros 
Não foram encontrados erros que 
exibissem qualquer tipo de mensagem que 
não fosse de fácil compreensão. Apenas os 
alertas de validações foram exibidos. 
Ajuda e documentação Sistema claro, sem necessidade de estudo 
de documentações para utilização, sendo 
que esta não existe ou não nos foi 
apresentada. 
 
4.3.10.5 Relatório de avaliação 
O sistema denominado
“Editor de Texto”, disponível no sitio na internet com 
endereço http://sfaa.unipinterativa.edu.br/pdf/, foi testado por nossa equipe de 
testes, seguindo as dez heurísticas, apresentadas por Jakob Nielsen, e teve um 
resultado bastante satisfatório quanto a usabilidade de sua interface. De modo geral 
o sistema possui frases e palavras que não confundem os usuários em sua 
utilização. Assim como, as ações que precisam ser executadas através dos botões 
de ações apresentam total correlação com o mundo real. Igualmente satisfatório 
foram as mensagens de diálogo exibidas nas validações dos campos obrigatórios. 
Desta forma, definimos como APROVADO, no teste de USABILIDADE DA 
INTERFACE. 
5 CONCLUSÃO 
Com os testes realizados foi possível constatar problemas nas validações dos 
campos de autores, sendo assim foi possível incluir dados em brancos ou inválidos 
de acordo com o tipo de dados. Também foram identificados problemas na rotina de 
“limpar”, onde alguns campos permaneceram com as informações digitadas. Vimos 
21 
 
que não existia uma ferramenta que atendesse as especificações do caso de teste 
08. E finalmente, identificamos um problema com o campo notas, onde não se 
mantém o alinhamento desejado. 
Foram realizados testes de interface onde não foram encontradas 
anormalidades. 
Com isso podemos concluir que os testes são fundamentais durante e após o 
processo de desenvolvimento do software. Mesmo que isso gere um custo maior 
nesta fase, ao longo prazo terá grandes benefícios para a empresa que desenvolve 
o produto. Além de produzir um efeito muito positivo nos primeiros contatos do 
usuário/cliente com o software. 
Compreendemos, também, com a disciplina Engenharia de Software II, os 
benefícios, importância e obstáculos no controle de qualidade na produção do 
software. Porém, com os diversos processos e modelos existentes é altamente 
viável que toda e qualquer fornecedora de software aplique um SGQ (Sistemas de 
Gestão da Qualidade). Estudamos também o impacto do processo de manutenção 
de software e os conceitos para melhoria e aplicação de técnicas eficazes que visam 
facilitar este processo. 
Na disciplina de Projeto de Interface com o Usuário vimos a importância de 
uma interface bem definida e que facilite a utilização pelo usuário. Estudamos os 
processos que ajudam no processo de projeto da interface de um software. 
22 
 
REFERÊNCIAS 
Nascimento, André Luiz Sena. Técnicas de Caixa Preta de Teste de Software. 
DEVMEDIA. Disponível em: https://www.devmedia.com.br/tecnicas-de-caixa-preta-
de-teste-de-software/8898. Acessado em 10 de abril de 2019. 
 
Sommerville, Ian. Engenharia de software, 8a edição. Pearson Addison - Wesley, 
2007. 
Pfleeger, Shari Lawrence. Engenharia de software: teoria e prática. São Paulo: 
Prentice Hall, 2004. 
Souza, Luciano Soares de. Projeto de interface com o usuário. São Paulo: Editora 
Sol, 2015. 
Ribeiro, André Luiz. Engenharia de Software II. São Paulo: Editora Sol, 2015.

Teste o Premium para desbloquear

Aproveite todos os benefícios por 3 dias sem pagar! 😉
Já tem cadastro?

Continue navegando