PIM V - TI Analise e Desenvolvimento

Prévia do material em texto

UNIP INTERATIVA 
Projeto Integrado Multidisciplinar 
Cursos Superiores de Tecnologia 
 
 
 
 
 
 
 
 
 
 
 
TESTE DE SOFTWARE 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Porto Alegre 
2019 
 
 
UNIP INTERATIVA 
Projeto Integrado Multidisciplinar 
Cursos Superiores de Tecnologia 
 
 
 
 
 
 
 
 
 
TESTE DE SOFTWARE 
 
 
 
 
Superior Técnico em Análise e Desenvolvimento de Sistemas. 
Projeto Integrado Multidisciplinar V 
1º Semestre/2019 
Orientador: 
Prof. Antônio Palmeira 
 
 
 
 
 
 
 
 
 
Porto Alegre 
2019 
 
 
 
RESUMO 
 
TESTE DE SOFTWARE. 
 
 Este trabalho tem a finalidade de mostrar como seria o dia a dia de um 
desenvolvedor de software para testar tudo que é produzido para os clientes. 
 
 Normalmente o software produzido era testado somente no final da 
produção para mostrar que o mesmo funcionava. 
 
 A partir da década de 80 começaram a ser elaborados métodos de testes 
que passaram a fazer parte do processo de desenvolvimento de software e no final 
da década de 90 começou a ser criado as funções de gerente de teste, analista de 
teste e operador de teste tornando estes cada vez mais relevantes no ciclo de vida 
do software e assumindo um perfil de prevenção de problemas, e não apenas de 
localização de erros. 
 
 Avaliação heurística é um método de inspeção de usabilidade utilizado para 
encontrar problemas de projeto de interfaces. Tem como base princípios de 
usabilidade amplamente reconhecidos e aceitos denominados heurísticos. 
 
 Este método considerado econômico, de fácil aprendizagem e fácil de ser 
aplicado, as sessões de avaliação individual duram normalmente uma a duas horas. 
 
 O avaliador navega pela interface pelo menos duas vezes, uma vez para 
obter uma percepção mais geral de possíveis fluxos de interações e o escopo do 
sistema e uma segunda vez para analisar elementos específicos da interface e 
inspeciona diversos elementos de diálogo e os compara com os princípios aceitos. 
 
Palavras-Chave: Desenvolvimento, heurístico e econômico. 
 
 
 
 
ABSTRACT 
 
SOFTWARE TEST 
 
 This work has the purpose of showing how it would be the day to day of a 
software developer to test everything that is produced for the clients. 
 
 Usually the software produced was tested only at the end of production to 
show that it worked. 
 
 From the 80's began to be elaborated test methods that became part of the 
software development process and in the late 90's began to be created the functions 
of test manager, test analyst and test operator making these increasingly relevant in 
the software life cycle and assuming a problem prevention profile, not just error 
location. 
 
 Heuristic evaluation is a usability inspection method used to find interface 
design problems. It is based on widely recognized and accepted usability principles 
called heuristics. 
 
 This method, considered economical, easy to learn and easy to apply, 
individual assessment sessions usually last one to two hours. 
 
 The evaluator navigates through the interface at least twice, once for a more 
general perception of possible interactions flows and the scope of the system and a 
second time to analyze specific elements of the interface and inspects various 
elements of dialogue and compares them with the principles accepted. 
 
Keywords: Development, heuristic and economic. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
SUMÁRIO 
 
RESUMO................................................................................................................... IV 
ABSTRACT ................................................................................................................ V 
LISTA DE ILUSTRAÇÕES ...................................................................................... VII 
1 INTRODUÇÃO ...................................................................................................... 9 
1.1 TESTE DE SOFTWARE ..................................................................................... 9 
1.2 DEFEITOS, ERROS E FALHAS ........................................................................ 9 
2 ROTEIRO DE TESTES ....................................................................................... 12 
2.1 ESTRUTURA DO TESTE ................................................................................. 12 
2.2 DEZ CASOS DE TESTE .................................................................................. 13 
3 INÍCIO DOS TESTES .......................................................................................... 15 
3.1 CASO DE TESTE 01: ....................................................................................... 15 
3.2 CASO DE TESTE 02: ....................................................................................... 15 
3.3 CASO DE TESTE 03: ....................................................................................... 16 
3.4 CASO DE TESTE 04: ....................................................................................... 17 
3.5 CASO DE TESTE 05: ....................................................................................... 19 
3.6 CASO DE TESTE 06: ....................................................................................... 20 
3.7 CASO DE TESTE 07: ....................................................................................... 22 
3.8 CASO DE TESTE 08: ....................................................................................... 23 
3.9 CASO DE TESTE 09: ....................................................................................... 24 
3.10 CASO DE TESTE 10: ....................................................................................... 26 
3.11 CARACTERES INFINITOS .............................................................................. 27 
4 AVALIAÇÃO HEURÍSTICA ................................................................................ 29 
4.1 INSPEÇÃO DE USABILIDADE ........................................................................ 29 
4.2 RELATÓRIO FINAL.......................................................................................... 29 
5 CONCLUSÕES ................................................................................................... 33 
BIBLIOGRAFIA ........................................................................................................ 34 
 
 
 
LISTA DE ILUSTRAÇÕES 
 
TABELA 1 - QUATROS TIPOS DE ERROS E SUAS DEFINIÇÕES. ................... 10 
TABELA 2 - PRINCIPAIS TIPOS E DEFEITOS DE UM SOFTWARE. ................. 10 
FIGURA 1 - CASO DE TESTE 01 ........................................................................ 15 
FIGURA 2 - CASO DE TESTE 02 ........................................................................ 16 
FIGURA 3 - CASO DE TESTE 03 ........................................................................ 17 
FIGURA 4 - CASO DE TESTE 04 ........................................................................ 18 
FIGURA 5 - CADASTRO OBRIGATÓRIO ........................................................... 19 
FIGURA 6 - GERAÇÃO DO CADASTRO ............................................................ 19 
FIGURA 7 - CASO DE TESTE 05 ........................................................................ 20 
FIGURA 8 - CASO DE TESTE 06 ÍNICIO ............................................................ 21 
FIGURA 9 - CASO DE TESTE 06 PARTE FINAL ................................................ 22 
FIGURA 10 - CASO DE TESTE 07 ........................................................................ 23 
FIGURA 11 - CASO DE TESTE 08 IMAGEM ......................................................... 24 
FIGURA 12 - CASO DE TESTE 09. ....................................................................... 25 
TABELA 3 - TABELA ESPECIFICAÇÃO DA INTERFACE .................................. 26 
TABELA 4 - TABELA ESPECIFICAÇÃO DA MENSAGEM A SER EXIBIDA ...... 26 
 
 
IN T R O D U Ç Ã O | 8 
 
 
1 INTRODUÇÃO 
I N T R O D U Ç Ã O | 9 
 
 
1 INTRODUÇÃO 
1.1 TESTE DE SOFTWARE 
 O teste de software não era levado a sério pelos fabricantes, pois ele só era 
usado no final do projeto para mostrar para o cliente que o sistema funcionava. 
 Somente a partir da década de 1980 começaram a ser elaborados métodos 
de testes que passaram fazer parte do processo de desenvolvimento de software, de 
maneira formal e como uma atividade essencial ao processo de construção. 
 No final da década de 1990 começaram a ser criadas as funções de gerente 
de testes, analista de testes e operador de testes, que são especialistas no 
planejamento, na elaboração e na execução dos testes, tornando estes cada vez 
mais relevantes no ciclo de vida do software e assumindo um perfil de prevenção de 
problemas, e não apenas de localização de erros. 
 As definições sobre testes de software variam, mas todas convergem para 
os conceitos básicos de encontrar defeitos em um software que está sendo testado, 
conferir se está de acordo com os requisitos definidos pelo usuário e verificar se 
realiza o que deveria ser feito. 
 
1.2 DEFEITOS, ERROS E FALHAS 
 Sabe-se que software não é uma entidade física e, portanto, não sofre 
qualquer tipo de desgaste (físico) como geralmente acontece com o hardware. 
Entretanto, apesar de não sofrer desgaste físico como o hardware, software está 
sujeito a modificações que ocorrem durante o ciclo de vida. 
 Essas modificações podem acontecer devido à inserção de defeitos 
decorrentes do desenvolvimento os quais são geralmente corrigidos antes da 
entrega do produto. Mas, observe que novos defeitos ainda podem ser (e 
geralmente são) inseridos devido às modificações que o software sofre devido a sua 
evolução. 
 Por exemplo, toda vez que uma nova funcionalidade é desejada ou 
solicitada pelo cliente, torna-se necessário adicionar e/ou modificar as instruções já 
existentes no software. Como resultado dessas mudanças, novos defeitos podem 
I N T R O D U Ç Ã O | 10 
 
 
ser introduzidos e, portanto, pode também causar a deterioração na qualidade do 
software. 
 De acordo com o documento IEEE Std 610.12-1990 que apresenta o IEEE 
Standard Glossary of Software Engineering Terminology, abaixo podemos ver uma 
tabela informando os quatros tipos de erros que iremos encontrar em uma produção 
de software. 
 
 
TABELA 1 - QUATROS TIPOS DE ERROS E SUAS DEFINIÇÕES. 
 Em 2013, Rios e Moreira chegaram na conclusão que diversos tipos de 
defeitos podem ser encontrados em um software. 
 Esses defeitos podem ser evitados, desde que sejam do conhecimento do 
desenvolvedor, e podem fazer parte de um checklist de boas práticas para serem 
tratados nas fases iniciais da codificação, juntamente com os padrões de código. 
 
TABELA 2 - PRINCIPAIS TIPOS E DEFEITOS DE UM SOFTWARE. 
 
 
 
ERRO! FONTE DE REFERÊNCIA NÃO ENCONTRADA.
 ROTEIRO DE TESTES 
R O T E I R O D E T E S T E S | 12 
 
 
2 ROTEIRO DE TESTES 
2.1 ESTRUTURA DO TESTE 
 O roteiro de testes e uma descrição detalhada do passo a passo para a 
execução do sistema, a fim de verificar cada caso de teste identificado na fase 
anterior. Para cada caso de teste deve haver um roteiro contendo as seguintes 
informações: 
1) Nome do caso de testes; 
2) Procedimento inicial para determinar onde começa o teste; 
3) Descrição detalhada contendo: 
1.Passos para a execução; 
2.Dados de entrada; 
3.Resultado esperado; 
4.Situação (sucesso ou não); 
5.Data da realização; 
6.Usuário que realizou o teste. 
4) Evidencia de realização do teste. 
Observe que nos dois exemplos são informados os dados de entrada 
para que a operação seja verificada por meio do dado de saída. O que 
são esses dados de entrada e o resultado esperado? 
5) Procedimento inicial: descreve detalhadamente as atividades que 
precisam ser feitas antes de iniciar a execução dos testes. 
6) Dado de entrada: e a informação que deve ser inserida no sistema 
para satisfazer o passo descrito e gerar a saída esperada. 
7) Resultado esperado: e o dado de saída gerado pelo sistema após a 
execução do passo e que serve de avaliação para indicar o sucesso da 
realização do passo. 
8) Evidencia de teste: e a informação que pode mostrar ao usuário que o 
caso de teste foi realmente executado. Pode ser uma “foto” da tela, um 
arquivo, dentre outros. 
 
R O T E I R O D E T E S T E S | 13 
 
 
2.2 DEZ CASOS DE TESTE 
 Caso de teste: 
1 - Gerar um artigo completo com um autor cadastrado com sucesso (nenhum 
campo pode ser branco). 
2 - Gerar um artigo para submissão com um autor cadastrado com sucesso (nenhum 
campo pode ser branco). 
3 - Gerar um artigo completo com três autores cadastrados com sucesso (nenhum 
campo pode ser branco). 
4 - Gerar um artigo completo com três autores com e-mails inválidos (nenhum 
campo pode ser branco). 
5 - Gerar um artigo completo com três autores com os campos de autor em branco. 
6 - Gerar um artigo completo com um autor cadastrado com sucesso (nenhum 
campo pode ser branco) e limpar os dados sem gerar o artigo. 
7 - 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. 
8 - 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. 
9 - 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. 
 
 
 
 
 
I N Í C I O D O S T E S T E S | 15 
 
 
 3 INÍCIO DOS TESTESERRO! FONTE DE 
REFERÊNCIA NÃO ENCONTRADA. 
I N Í C I O D O S T E S T E S | 16 
 
 
3 INÍCIO DOS TESTES 
3.1 CASO DE TESTE 01: 
 Gerar um artigo completo com um autor cadastrado com sucesso (nenhum 
campo pode ser branco). 
 
 
FIGURA 1 - CASO DE TESTE 01 
 Podemos ver que o editor gerou o texto com todos os campos informados. 
Foi confirmado que todos os campos funcionam normalmente. 
 
3.2 CASO DE TESTE 02: 
 Gerar um artigo para submissão com um autor cadastrado com sucesso 
(nenhum campo pode ser branco). 
I N Í C I O D O S T E S T E S | 17 
 
 
 
FIGURA 2 - CASO DE TESTE 02 
 Como verificado no teste ao ser feito o cadastro do autor em submissão o 
mesmo quando gerado não aparece no conteúdo. 
3.3 CASO DE TESTE 03: 
 Gerar um artigo completo com três autores cadastrados com sucesso 
(nenhum campo pode ser branco). 
I N Í C I O D O S T E S T E S | 18 
 
 
 
FIGURA 3 - CASO DE TESTE 03 
 Como podemos observar o texto gerado foi incluído os três autores como 
proposto e o nome deles parece com uma numeração para ser indicado quem foi o 
primeiro a ser incluído. 
 
3.4 CASO DE TESTE 04: 
 Gerar um artigo completo com três autores com e-mails inválidos (nenhum 
campo pode ser branco). 
I N Í C I O D O S T E S T E S | 19 
 
 
 
FIGURA 4 - CASO DE TESTE 04 
 Como podemos ver e gerado um erro na primeira inclusão, sendo impossível 
mexer nos outros cadastros de e-mail. 
 É informado o seguinte erro “Por favor, informe um e-mail válido! ”. 
 Neste ponto foi verificado que o sistema de editor só aceita um e-mail sendo 
válido se constar um “@” e um “.” (ponto) dentro do campo de cadastro. 
 
 
 
 
I N Í C I O D O S T E S T E S | 20 
 
 
 
FIGURA 5 - CADASTRO OBRIGATÓRIO 
 Podemos observar que foi colocado as informações que o sistema está 
programado para aceitar. 
 
 
FIGURA 6 - GERAÇÃO DO CADASTRO 
 Após ter sido geradoo cadastro obrigatório pude concluir que para não ser 
gerado o erro deve ter um caractere qualquer dentro dos campos, sendo letra ou 
número e no campo e-mail ficando o “@” e o “.” (ponto) ele funciona. 
 
3.5 CASO DE TESTE 05: 
 Gerar um artigo completo com três autores com os campos de autor em 
branco. 
I N Í C I O D O S T E S T E S | 21 
 
 
 
FIGURA 7 - CASO DE TESTE 05 
 Ao tentar gerar o editor sem o autor foi informado na tela “Por favor, verificar 
o campo Autor ”, como se trata de um campo obrigatório tem que ser informado 
qualquer caractere entre letras e números para poder ser gerado. 
 
3.6 CASO DE TESTE 06: 
 Gerar um artigo completo com um autor cadastrado com sucesso (nenhum 
campo pode ser branco) e limpar os dados sem gerar o artigo. 
I N Í C I O D O S T E S T E S | 22 
 
 
 
FIGURA 8 - CASO DE TESTE 06 ÍNICIO 
 Foi informado todos os campos como solicitado no cabeçario do teste, ao 
ser apertado o botão de limpar foi analisado que os campos do título até o keywords 
tinha sido apagado. 
I N Í C I O D O S T E S T E S | 23 
 
 
 
FIGURA 9 - CASO DE TESTE 06 PARTE FINAL 
 Pude observar que dentro dos campos corpo do teste, notas e referencia 
bibliográfica mesmo após ter sido apertado o botão de limpar continuou mantendo 
as informações incluídas. 
 
3.7 CASO DE TESTE 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. 
I N Í C I O D O S T E S T E S | 24 
 
 
 
FIGURA 10 - CASO DE TESTE 07 
 Na figura acima foi colocado o texto no corpo do editor e incluído alguns 
formatos diferentes como subscrito, sobrescrito, itálico e negrito. 
 
3.8 CASO DE TESTE 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. 
I N Í C I O D O S T E S T E S | 25 
 
 
 
FIGURA 11 - CASO DE TESTE 08 IMAGEM 
 Foi tentado inserir uma imagem, mais sem sucesso pois não tem suporte 
para ser incluída imagens. 
 
3.9 CASO DE TESTE 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. 
 
I N Í C I O D O S T E S T E S | 26 
 
 
 
FIGURA 12 - CASO DE TESTE 09. 
 Como verificado foi colocado um texto mais longo na “Nota” em negrito e 
com um link. 
 
 
I N Í C I O D O S T E S T E S | 27 
 
 
3.10 CASO DE TESTE 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. 
 
TABELA 3 - TABELA ESPECIFICAÇÃO DA INTERFACE 
 
 Como podemos verificar na tabela a cima foi analisado todos os elementos 
um a um para ser validados conforme são usados. 
 
 Na tabela abaixo podemos ver todas as mensagens de erro que aparecem 
no editor. 
 
TABELA 4 - TABELA ESPECIFICAÇÃO DA MENSAGEM A SER EXIBIDA 
 
I N Í C I O D O S T E S T E S | 28 
 
 
3.11 CARACTERES INFINITOS 
 Foi feito um teste para saber se o editor de teste teria uma limitação para 
quando chegassem no final da quantidade de caracteres. 
 
 
FIGURA 13 - CARACTERES INFINITOS 
 Pode-se verificar que não tem limites nos campos, sendo o campo do e-mail 
o único que exige a necessidade de ser incluído o “@” e o “.” (ponto). 
 Observando o topo do editor podemos ver que foi possível chegar em – 
300.117 caracteres restantes passando muito do estimado de 42.000. 
 
 
 
 
4 ERRO! FONTE DE REFERÊNCIA NÃO 
ENCONTRADA. HEURÍSTICA 
A V A L I A Ç Ã O H E U R Í S T I C A | 30 
 
 
4 ERRO! FONTE DE REFERÊNCIA NÃO ENCONTRADA. HEURÍSTICA 
4.1 INSPEÇÃO DE USABILIDADE 
 Avaliação heurística é um método de inspeção de usabilidade utilizado para 
encontrar problemas de projeto de interfaces. 
 Método considerado econômico, de fácil aprendizagem e fácil de ser 
aplicado, as sessões de avaliação individual duram de normalmente uma a duas 
horas. 
 O avaliador navega pela interface pelo menos duas vezes e inspeciona 
diversos elementos de diálogo. 
 Jakob Nielsen, depois de analisar centenas de problemas de usabilidade, 
estabeleceu dez princípios gerais para projeto de interação. 
1. Visibilidade do estado do sistema; 
2. Correlação entre o sistema e o mundo real; 
3. Liberdade e controle do usuário; 
4. Consistência e padrões; 
5. Prevenção de erros; 
6. Reconhecimento em vez de memorização; 
7. Flexibilidade e eficiência de uso; 
8. Projeto estético e minimalista; 
9. Suporte para o usuário no reconhecimento, no diagnóstico e na 
recuperação de erros; 
10. Ajuda e documentação. 
 
4.2 LEVANTAMENTO PARA O RELATÓRIO 
A. Domínio de todos os campos; 
 
Foi verificado que todos os campos podiam ser manipulados com 
informações. 
 
B. Validação de cada campo; 
 
1) Título – Pode ser incluído qualquer informação sem limite. 
2) Título em Inglês - Pode ser incluído qualquer informação sem 
limite. 
3) Autor- Campo obrigatório- Pode ser incluído qualquer 
informação sem limite. 
4) Titulação- Campo obrigatório- Pode ser incluído qualquer 
informação sem limite. 
5) Vínculo institucional - Campo obrigatório- Pode ser incluído 
qualquer informação sem limite. 
6) E-mail de contato - Campo obrigatório- O campo só deixa ser 
gerado se tiver o “@” e o “.” (ponto) dentro do campo. 
7) Resumo- Pode ser incluído qualquer informação sem limite. 
A V A L I A Ç Ã O H E U R Í S T I C A | 31 
 
 
8) Palavras-Chave- Pode ser incluído qualquer informação sem 
limite. 
9) Abstract- Pode ser incluído qualquer informação sem limite. 
10) Keywords- Pode ser incluído qualquer informação sem limite. 
11) Corpo do texto- Pode ser incluído qualquer informação sem 
limite. 
12) Notas- Pode ser incluído qualquer informação sem limite. 
13) Referências bibliográficas- Pode ser incluído qualquer 
informação sem limite. 
 
C. Ações em botões e links existentes; 
 
1) Autores – Aumenta os números de autores quantas vezes for 
clicado. 
2) Arquivo completo – Gera o texto. 
3) Arquivo para submissão (blind review) – Gera o texto sem o 
nome do autor. 
4) LIMPAR – Limpa os campos entre o título até o keyword. 
 
D. Mensagens exibidas pelo sistema. 
 
Nos campos obrigatórios se não for incluído alguma informação é 
informada a seguintes mensagens: 
 
"Por favor, verifique o campo Autor" 
"Por favor, verifique o campo Titulação" 
"Por favor, verifique o campo Vínculo institucional" 
"Por favor, verifique o campo E-mail" 
 
4.3 RELATÓRIO FINAL 
 Venho por meio desta informar que os teste feitos no software editor de texto 
que se encontra no caminho “http://sfaa.unipinterativa.edu.br/pdf/”, foi testado dez 
vezes sendo feito testes diferentes para ser verificado todos os possiveis problemas 
do mesmo. 
 Foi analisado todos os campos e verificado que podesse incluir imformação 
dentro deles sendo letras ou números. 
 Podesse verificar que no cabeçario do editor encontrasse a informação da 
quantidade de caracteres que pode ser incluido nos campos. Porem foi testado e 
constatado que pode ser ultrapassado sem limites o número informado de 42.000 
(quarenta e dois mil) caracteres. 
 Verifiquei tambem que o botão “+” onde aumenta a quantidade de autores 
pode ser incluido uma quantidade infinita de autores. 
 No campo “e-mail de contato” se tiver somente o “@” e um “.” (ponto) o 
editor deixa ser gerado o arquivo, o memso acontece com o outros campos 
obrigatorios onde é só informar uma letra ou número que vai funcionar. 
A V A L I A Ç Ã O H E U R Í S T I C A | 32 
 
 
 Foi verificado que no botão “gerar” do Arquivo completo estando os campos 
obrigatórios com os seu caracteres adequados o arquivo é gerado, não sendo 
necessário o preenchimentodos outros campos. 
 No botão “gerar” do Arquivo para submissão (blind review) podemos 
observar que todo o conteúdo dos campos é gerado no arquivo menos o nome do 
autor. 
 No botão “Limpar” verificamos que é feito a limpeza somente do título até o 
campo Keywords, e os outros campos do corpo do texto para baixo permanecem 
intactos. 
 Após ter sido feito varias analises do editor de texto podemos concluir que o 
mesmo tem falhas de execução. 
 
 
 
 
 
 
 5 CONCLUSÕES 
C O N C L U S Õ E S | 34 
 
 
5 CONCLUSÕES 
 Com os conhecimentos em Engenharia de Software II foi possível ser feito 
10 (dez) testes de caixa preta no software editor de texto podendo mostrar um pouco 
do dia a dia de um desenvolvedor de software, onde o trabalho não é só no 
desenvolvimento mais também no teste do produto para ser feito a entrega para o 
cliente. 
 Usando os conhecimentos em Projeto de Interface com o usuário foi 
possível fazer uma avaliação heurística que é um método de inspeção de 
usabilidade utilizado para encontrar problemas de projeto de interfaces sendo 
elaborado um relatório no final de todos os testes que foram feitos. 
 
 
 
 
 
 
BIBLIOGRAFIA 
 
https://www.devmedia.com.br/sobre-a-necessidade-de-educacao-continuada-
engenharia-de-software-32/19011 
 
https://docplayer.com.br/59225308-Desenvolvimento-de-software-testes-de-
software-topicos-da-aula-onde-estamos-verificacao-x-validacao-testes-de-
software.html