1

UNIP INTERATIVA

ANALISE E DESENVOLVIMENTO DE SISTEMAS

BRUNO CÉSAR MANOEL SIQUEIRA RA: 1548816

PIM V – CASOS DE TESTES

ARARAQUARA

2016
 2

BRUNO CÉSAR MANOEL SIQUEIRA

PIM V – CASOS DE TESTES

Monografia apresentada como exigência para

obtenção do grau de Tecnologia em Analise e
Desenvolvimento de Sistemas da UNIP
Interativa.

Orientador: Prof. André Luiz

ARARAQUARA

2016
 3

RESUMO

O projeto deve ser executado para que sirva de avaliação do PIMV referente
ao Curso superior Tecnológico em Analise e desenvolvimento de Sistemas. A técnica
utilizada para avaliar se o sistema está de acordo como as conformidades previstas
pelo Departamento de Extensão, Pesquisa e Pós-graduação é a funcional caixa-
preta que verifica situações de sucesso e insucesso na execução de determinadas
funcionalidades denominadas casos de teste. A universidade informou 10 casos de
testes os quais serão criados roteiros específicos para cada caso, executados e
geradas as evidencias dos sucessos ou insucessos observados. Ao final será gerado
um relatório final apontando as possíveis falhas do sistema, auxiliando a DEPP na
aceitação do Sistema.

Palavras-chave: sistema, teste, projetos, análise.

 4

ABSTRACT

The project should be implemented to serve as an assessment of PIMV

referring to superior Course Technology in Analysis and systems development. The
technique used to assess whether the system conforms to the compliance provided
by the Department of Extension, Research and Graduate Studies is the black-box
functional checking of success and failure situations in the execution of certain
features called test cases. The university reported 10 test cases which specific scripts
will be created for each case, executed and generated the evidence of observed
successes or failures. At the end a final report indicating the possible system failures,
helping DEPP acceptance of the system is generated.

Keywords: system, test, design, analysis.

 5

Sumário

1 Introdução ............................................................................................................... 7
2 Testes ...................................................................................................................... 8
2.1 Técnicas para testes ........................................................................................... 9
2.2 Técnica Funcional ............................................................................................. 10
3 Fundamentos de teste de software .................................................................... 12
3.1 Objetivos do teste ............................................................................................. 12
3.2 Principios do teste ............................................................................................ 13
3.3 Testabilidade ..................................................................................................... 14
4 Planejamento ........................................................................................................ 15
5 Projeto ................................................................................................................... 15
6 caso de teste 1 ...................................................................................................... 17
7 caso de teste 2 ...................................................................................................... 21
8 caso de teste 3 ...................................................................................................... 24
9 caso de teste 4 ...................................................................................................... 26
10 caso de teste 5 ................................................................................................... 28
11 caso de teste 6 .................................................................................................... 30
12 caso de teste 7 ................................................................................................... 33
13 caso de teste 8 .................................................................................................... 35
14 caso de teste 9 .................................................................................................... 36
15 caso de teste 10 .................................................................................................. 38
16 Relatório final ..................................................................................................... 41
17 Conclusão ........................................................................................................... 42
18 Bibliografia .......................................................................................................... 43
 6

Índice de figuras

Figura 1............................................................................................................ 17
Figura 2............................................................................................................ 18
Figura 3............................................................................................................ 18
Figura 4............................................................................................................ 19
Figura 5............................................................................................................ 19
Figura 6............................................................................................................ 20
Figura 7............................................................................................................ 21
Figura 8............................................................................................................ 22
Figura 9............................................................................................................ 23
Figura 10.......................................................................................................... 24
Figura 11...........................................................................................................25
Figura 12.......................................................................................................... 25
Figura 13.......................................................................................................... 26
Figura 14.......................................................................................................... 27
Figura 15.......................................................................................................... 28
Figura 16.......................................................................................................... 29
Figura 17.......................................................................................................... 30
Figura 18.......................................................................................................... 31
Figura 19.......................................................................................................... 32
Figura 20.......................................................................................................... 33
Figura 21.......................................................................................................... 34
Figura 22.......................................................................................................... 35
Figura 23.......................................................................................................... 36
Figura 24.......................................................................................................... 37
Figura 25.......................................................................................................... 38
Figura 26.......................................................................................................... 39
Figura 27.......................................................................................................... 40
 7

1 INTRODUÇÃO

A Engenharia de Software cresceu bastante ao longo do tempo procurando

assegurar critérios, técnicas, métodos e ferramentas para a produção de um bom
software, em consequência disso, o aumento da utilização de sistemas baseados em
computação em praticamente todas as áreas da atividade humana, o que provoca
crescente demanda por produtividade e qualidade, tanto do ponto de vista dos
produtos gerados como do ponto de vista do processo de produção.
A Engenharia de Software pode ser conceituada então como uma disciplina
que aplica os princípios de engenharia com o objetivo de produzir software de alta
qualidade e de baixo custo e através de um conjunto de etapas que envolvem o
desenvolvimento e aplicação de métodos, técnicas e ferramentas, oferece meios
para que tais objetivos possam ser alcançados.
O processo do desenvolvimento de um software envolve uma série de
exercícios nas quais, apesar dos métodos, das técnicas e ferramentas empregadas,
erros no produto ainda podem existir. As práticas associadas sob o nome de
Garantia de Qualidade de Software têm sido introduzidas ao longo de todo processo
de desenvolvimento, entre elas destacamos atividades de Verificação, Validação e
Teste, que tem por objetivo minimizar a ocorrência de erros e riscos associados ao
produto.
Dentro dessas técnicas de verificação e validação, existe a atividade de teste,
é uma das mais utilizadas e importantes, constituindo-se em um dos elementos para
fornecer evidências da confiabilidade do software complementando outros requisitos,
por exemplo, o uso de revisões e de técnicas formais e rigorosas de especificação e
de verificação.
A Prática de teste consiste em uma análise dinâmica do produto e é uma
atividade de grande importância para a identificação e eliminação de problemas que
persistem. Do ponto de vista de qualidade do processo, o teste sistemático é uma
prática fundamental para o crescimento para o Nível Três do Modelo CMM do
Software Engineering Institute. Ainda, o conjunto de informação oriundo da prática
de teste é significativo para as atividades de depuração, manutenção e de
confiabilidade de um Software. Reforça-se que a atividade de teste tem sido
apontada como uma das mais onerosas no desenvolvimento de software, porém é
de extrema importância para garantia de um software de qualidade.
 8

2 TESTES

Testes de software são divididos em alguns tipos de acordo com seu objetivo
particular, segue aqui os principais tipos de teste e o que eles abordam
resumidamente:

Teste de caixa branca e caixa preta: basicamente teste de caixa branca envolve o
código e o de caixa-preta, não.

Teste de Instalação: Consiste em testar se o software instala como planejado em

diferentes hardwares e em diferentes condições como pouco espaço de
memória, interrupções de rede, interrupções na instalação, etc.

Teste de Configuração: Testa se o software funciona no hardware que ele será

instalado.

Teste de Integridade: Testa a resistência do software a falhas, ou seja, a robustez.

Teste Funcional: Testa os requisitos funcionais, funções e os casos de uso (A

aplicação faz o que deveria fazer?).

Teste de Integração: Testa se um ou mais componentes combinados funcionam de

maneira adequada. Pode-se dizer que o teste de integração é composto por vários
testes de unidade.

Teste de Segurança: Testa se o sistema e os dados são acessados de maneira

segura apenas pelo usuário autorizado das ações.

Teste de Volume: Testa o comportamento do sistema operando com o volume

“normal” de dados e transações envolvendo o banco de dados durante um
longo período de tempo.
 9

Teste de Unidade: testa um componente isolado ou classe do sistema.

Teste de Desempenho (Performance): Se divide em 3 tipos: Teste de carga, testa o

software sob condições normais de uso, exemplo é o tempo de resposta, número
de transações por minuto, usuários simultâneos; Teste de stress, testa o software
sob condições extremas de uso. Grande volume de transações e usuários
simultâneos. Picos excessivos de carga em curtos períodos de tempo e Teste de
estabilidade testa se o sistema se mantém funcionando de maneira adequada após
um período de uso.

Teste de Usabilidade: É um teste focado na experiência do usuário, consistência da

interface, layout, acesso às funcionalidades, etc.

Teste de Regressão: É um reteste de um sistema ou componente para verificar se

alguma modificação recente causou algum efeito indesejado e para certificar que
o sistema ainda atende aos requisitos.

Teste de Manutenção: Testa a mudança de ambiente se não interferiu no

funcionamento do sistema. Nesta monografia, abordaremos o Teste Caixa Preta.

2.1 TÉCNICAS PARA TESTES

Para se conduzir e avaliar a qualidade da atividade de teste têm-se as técnicas de

teste funcional, estrutural e baseada em erros. Tais técnicas diferenciam-se pela
origem da informação utilizada na avaliação e construção dos conjuntos de casos
de teste. Nesta monografia apresenta-se com mais detalhes a técnica funcional ou
caixa preta como é conhecido. Através desse critério, os principais aspectos
pertinentes à atividade de teste de cobertura de software. Para propiciar uma visão
mais abrangente, apresenta-se primeiramente uma visão geral da técnica funcional
e os critérios mais conhecidos dessa técnica.
 10

2.2 TÉCNICA FUNCIONAL

O teste funcional também é conhecido como teste caixa preta pelo fato de tratar o
software como uma caixa cujo conteúdo é desconhecido e da qual só é possível
visualizar o lado externo, ou seja, os dados de entrada fornecidos e as respostas
produzidas como saída.

Na técnica de teste funcional são veri ficadas as funções do sistema sem se

preocupar com os detalhes de implementação.

O teste funcional envolve dois passos principais: identifi car as funções que o
software deve realizar e criar casos de teste capazes de checar se essas funções
estão sendo realizadas pelo software. As funções que o software deve possuir são
indentifi cadas a partir de sua especifi cação. Assim, uma especifi cação bem
elaborada e de acordo com os requisitos do usuário é essencial para esse tipo de
teste.

Alguns exemplos de critérios de teste funcional são. :

Particionamento em Classes de Equivalência: a partir das condições de entrada de

dados indentifi cadas na especifi cação, divide-se o domínio de entrada de um
programa em classes de equivalência válidas e inválidas. Em seguida seleciona-se o
menor número possível de casos de teste, baseando-se na hipótese que um
elemento de uma classe seria representativo da classe toda, sendo que para cada
uma das classes inválidas deve ser gerado um caso de teste distinto. O uso de
particionamento permite examinar os requisitos mais sistematicamente e restringir o
número de casos de teste existentes. Alguns autores também consideram o domínio
de saída do programa para estabelecer as classes de equivalência.

Análise do Valor Limite: é um complemento ao critério Particionamento em Classes

de Equivalência, sendo que os limites associados às condições de entrada são
exercitados de forma mais rigorosa; ao invés de selecionar-se qualquer elemento de
uma classe, os casos de teste são escolhidos nas fronteiras das
 11

classes, pois nesses pontos se concentra um grande número de erros. O espaço

de saída do programa também é particionado e são exigidos casos de teste que
produzam resultados nos limites dessas classes de saída.

Grafo de Causa-Efeito: os critérios anteriores não exploram combinações das

condições de entrada. Este critério estabelece requisitos de teste baseados nas
possíveis combinações das condições de entrada. Primeiramente, são levantadas as
possíveis condições de entrada (causas) e as possíveis ações (efeitos) do
programa. A seguir é construído um grafo relacionando as causas e efeitos
levantados. Esse grafo é convertido em uma tabela de decisão a partir da qual são
derivados os casos de teste.

Um dos problemas relacionado aos critérios funcionais é que muitas vezes a

especifi cação do programa é feita de modo descritivo e não formal. Dessa maneira,
os requisitos de teste derivados de tais especifi cações são também, de certa forma,
imprecisos e informais. Como consequência, tem-se difi culdade em automatizar a
aplicação de tais critérios, restritos à aplicação manual. Por outro lado, para a
aplicação desses critérios é essencial apenas que se indentifi quem as entradas, a
função a ser computada e a saída do programa, o que os tornam aplicáveis
praticamente em todas fases de teste (unidade, integração e sistema).
 12

3 FUNDAMENTOS DO TESTE DE SOFTWARE

O teste expõe uma anomalia interessante para o engenheiro de software.

Durante as primeiras atividades de engenharia de software, o engenheiro tenta
construir um software a partir de um conceito abstrato até um produto tangível.
Depois vem o teste. O engenheiro cria uma série de casos de testes, que são
destinados a "demolir” o software que foi construído. De fato, o teste é um passo do
processo de software que poderia ser visto (pelo menos psicologicamente) como
destrutivo em vez de construtivo.
Engenheiros de software são por natureza pessoas construtivas. O teste
exige que o desenvolvedor reveja noções preconcebidas da "corretividade" do
software recém desenvolvido e supere um conflito de interesses que ocorre quando
erros são descobertos.

3.1 OBJETIVOS DO TESTE

Glen Myers enumera algumas regras que podem servir bem como objetivos
do teste:
1. Teste é um processo de execução de um programa com a finalidade de
encontrar um erro.
2. Um bom caso de teste é aquele que tem alta probabilidade de encontrar
um erro ainda não descoberto.
3. Um teste bem-sucedido é aquele que descobre um erro ainda não
descoberto.
Esses objetivos implicam uma dramática mudança de ponto de vista. Eles vão
contra a visão comum de que um teste bem-sucedido é aquele no qual não são
encontrados erros. Nosso objetivo é projetar testes que descobrem
sistematicamente diferentes classes de erros e fazê-lo com uma quantidade mínima
de tempo ou esforço.
Se o teste for conduzido de maneira bem-sucedida (de acordo com os
objetivo declarados anteriormente), ele descobrirá erros no software. Como benefício
secundário, o teste demonstra que as funções do software parecem estar
funcionando do acordo com a especificação de que os requisitos de comportamento
 13

e desempenho parecem estar sendo satisfeitos. Além disso, os dados coletados à

medida que o teste é conduzido fornecem uma boa indicação da confiabilidade do
software e alguma indicação da qualidade de todo o software.

3.2 PRINCIPIOS DO TESTE

Antes de aplicar métodos para projetar casos de teste efetivos, um

engenheiro de software deve entender os princípios básicos que guiam o teste de
software. Davi sugere um conjunto de princípios de teste:
• Todos os testes devem ser relacionados aos requisitos do cliente. Como já
vimos, o objetivo do teste de software é descobrir erros. Segue-se que os defeitos
mais indesejáveis (do ponto de vista do cliente) são aqueles que levam o programa a
deixar de satisfazer seus requisitos.
• Os testes devem ser planejados muito antes do início do teste. O
planejamento de teste pode começar tão logo o modelo de requisitos seja
completado. A definição detalhada dos casos de teste pode começar tão logo o
modelo de projeto tenha sido consolidado. Assim sendo, todos os testes podem ser
planejados e projetados antes que qualquer código tenha sido gerado.
• O princípio de Pareto se aplica ao teste de software. Colocado simplesmente
o princípio de Pareto implica que 80% de todos os erros descobertos durante teste
vão provavelmente ser relacionados a 20% de todos os componentes do programa.
O problema, sem dúvida, é isolar os componentes suspeitos e testá-los
rigorosamente.
• O teste deve começar "no varejo" e progredir até o teste "no atacado". Os
primeiros testes planejados e executados geralmente concentram-se nos
componentes individuais. À medida que o teste progride, o foco se desloca numa
tentativa de encontrar erros em conjuntos integrados de componentes e finalmente
em todo o sistema.
• Teste completo não é possível. A quantidade de permutações de caminho
mesmo para um programa de tamanho moderado, é excepcionalmente grande. Por
essa razão, é impossível executar todas as combinações de caminhos durante o
 14

teste. É possível, no entanto, cobrir adequadamente a lógica do programa e garantir

que todas as condições no projeto, a nível de componente, tenham sido exercitadas.
• Para ser mais efetivo, o teste deveria ser conduzido por terceiros. Por mais
efetivo, nós queremos dizer teste que tem a maior probabilidade de encontrar erros
(o principal objetivo do teste). Por motivos explicitados anteriormente, o engenheiro
de software que criou o sistema não é a pessoa adequada para conduzir todos os
testes do software.

3.3 TESTABILIDADE

Antes de aplicar métodos para projetar casos de teste efetivos, um

engenheiro de software deve entender os princípios básicos que guiam o teste de
software. Davi sugere um conjunto de princípios de teste:
• Todos os testes devem ser relacionados aos requisitos do cliente. Como já
vimos, o objetivo do teste de software é descobrir erros. Segue-se que os defeitos
mais indesejáveis (do ponto de vista do cliente) são aqueles que levam o programa a
deixar de satisfazer seus requisitos.
• Os testes devem ser planejados muito antes do início do teste. O
planejamento de teste pode começar tão logo o modelo de requisitos seja
completado. A definição detalhada dos casos de teste pode começar tão logo o
modelo de projeto tenha sido consolidado. Assim sendo, todos os testes podem ser
planejados e projetados antes que qualquer código tenha sido gerado.
• O princípio de Pareto se aplica ao teste de software. Colocado simplesmente
o princípio de Pareto implica que 80% de todos os erros descobertos durante teste
vão provavelmente ser relacionados a 20% de todos os componentes do programa.
O problema, sem dúvida, é isolar os componentes suspeitos e testá-los
rigorosamente.
• O teste deve começar "no varejo" e progredir até o teste "no atacado". Os
primeiros testes planejados e executados geralmente concentram-se nos
componentes individuais. À medida que o teste progride, o foco se desloca numa
tentativa de encontrar erros em conjuntos integrados de componentes e finalmente
em todo o sistema.
 15

• Teste completo não é possível. A quantidade de permutações de caminho

mesmo para um programa de tamanho moderado, é excepcionalmente grande. Por
essa razão, é impossível executar todas as combinações de caminhos durante o
teste. É possível, no entanto, cobrir adequadamente a lógica do programa e garantir
que todas as condições no projeto, a nível de componente, tenham sido exercitadas.
• Para ser mais efetivo, o teste deveria ser conduzido por terceiros. Por mais
efetivo, nós queremos dizer teste que tem a maior probabilidade de encontrar erros
(o principal objetivo do teste). Por motivos explicitados anteriormente, o engenheiro
de software que criou o sistema não é a pessoa adequada para conduzir todos os
testes do software.

4 PLANEJAMENTO

O projeto deve ser executado para que sirva de avaliação do PIMV referente
ao Curso superior Tecnológico em Analise e desenvolvimento de Sistemas.
A técnica utilizada para avaliar se o sistema está de acordo como as
conformidades previstas pelo Departamento de Extensão, Pesquisa e Pós-
graduação e a funcional caixa-preta que verifica situações de sucesso e insucesso
na execução de determinadas funcionalidades denominadas casos de teste.
A universidade informou 10 casos de testes os quais serão criados roteiros
específicos para cada caso, executados e geradas as evidencias dos sucessos ou
insucessos observados.
Ao final será gerado um relatório final apontando as possíveis falhas do
sistema, auxiliando a DEPP na aceitação do Sistema.

5 PROJETO

Nesta fase vamos identificar os casos de teste informados pela DEPP e

elenca-lo abaixo:
Caso de teste 1: Gerar um artigo completo com um autor cadastrado com
sucesso (nenhum campo pode ficar em branco).
Caso de teste 2: Gerar um artigo para submissão com um autor cadastrado
com sucesso (nenhum campo pode ficar em branco).
 16

Caso de teste 3: Gerar um artigo completo com três autores cadastrados com
sucesso (nenhum campo pode ficar em branco).
Caso de teste 4: Gerar um artigo completo com três autores com e-mails
inválidos (nenhum campo pode ficar em branco).
Caso de teste 5: Gerar um artigo completo com três autores com os campos
de autor em branco.
Caso de teste 6: Gerar um artigo completo com um autor cadastrado com
sucesso (nenhum campo pode ficar em branco) e limpar os dados sem gerar o
artigo.
Caso de teste 7: Gerar um artigo completo com um autor cadastrado com
sucesso (nenhum campo pode ficar em branco), criando no campo “corpo do texto”
um texto com formatação em negrito, itálico, subscrito e sobrescrito e o texto
justificado com sucesso.
Caso de teste 8: Gerar um artigo completo com um autor cadastrado com
sucesso (nenhum campo pode ficar em branco), anexando no campo “corpo do
texto” uma imagem de um arquivo com sucesso.
Caso de teste 9: Gerar um artigo completo com um autor cadastrado com
sucesso (nenhum campo pode ficar em branco), anexando no campo “Notas” uma
URL de um arquivo com sucesso e criando um texto formato à esquerda e em
negrito.
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.
Avalie a tela do sistema e crie, para todos os campos e controles existentes,
os testes de interface relacionados a: domínio de todos os campos; · Validação de
cada campo; · Ações em botões e links existentes; · Mensagens exibidas pelo
sistema.
Com os casos de teste acima podemos iniciar a etapa de criação de um
roteiro de teste modelo que auxiliará na execução dos testes.
 17

6 CASO DE TESTE 1

Figura 1
 18

Figura 2

Figura 3
 19

Figura 4

Figura 5
 20

Figura 6
 21

7 CASO DE TESTE 2

Figura 7
 22

Figura 8
 23

Figura 9
 24

8 CASO DE TESTE 3

Figura 10
 25

Figura 11

Figura 12
 26

9 CASO DE TESTE 4

Figura 13
 27

Figura 14
 28

10 CASO DE TESTE 5

Figura 15
 29

Figura 16
 30

11 CASO DE TESTE 6

Figura 17
 31

Figura 18
 32

Figura 19
 33

12 CASO DE TESTE 7

Figura 20
 34

Figura 21
 35

13 CASO DE TESTE 8

Não tem botão para inserir imagem.

Figura 22
 36

14 CASO DE TESTE 9

Figura 23
 37

Figura 24
 38

15 CASO DE TESTE 10

Figura 25
 39

Figura 26
40
Figura 27
 41

16 RELATÓRIO FINAL

O DEPP (Departamento de Extensão, Pesquisa e Pós- graduação) de uma

universidade necessitou de uma solução em forma de software que pudesse atender
a critérios normativos em quesito da mais adequada formatação de artigos para
serem submetidos a congressos e revistas científicas da própria universidade
solicitante do serviço.
Com isso, se fez neces sária a contratação de uma empresa que pudesse
desenvolver o software proposto, sendo que ele deveria atender a alguns critérios
mencionados a seguir, como: Estar de acordo com as normas de formatação
adotadas pelo DEPP, possuir o máximo de 42.000 caracteres e gerar duas versões
que seriam a blind review e a outra com a devida identificação do(s) autor (es) do
artigo.
Para a devida validação do Sistema de Formatação de Artigos Acadêmicos
desenvolvido, foi solicitado aos alunos do curso de Análise e Desenvolvimento de
Sistemas realizarem diversos testes técnicos (em caixa preta) que fogem aos
domínios do conhecimento dos usuários finais, que estão de acordo com critérios da
Engenharia de Software, de modo a mitigar erros que poderiam ou podem ocorrer
com o contínuo uso do sistema.
Houve um consenso entre os alunos para uma padronização dos testes a
serem realizados, de forma a criar um método mais claro e eficaz para a validação
dos casos propostos pelo coordenador do curso de ADS, criando assim passos
concisos para a melhor absorção da interação e criando métricas para as respostas
provenientes do sistema, não deixando de lado a análise das funcionalidades bem
como da interface e interatividade do sistema desenvolvido.
Após testes sistemáticos, os alunos conseguiram observar em uma visão
holística as respostas de acordo com as entradas propostas em cada caso ou roteiro
e, a partir de tal premissa, uma avaliação geral do software foi realizada,
demonstrando os prós e contras encontrados na versão corrente disponibilizada.
Tendo em vista estas respostas, deve-se esperar uma gradual evolução do sistema
a fim de que esteja perfeitamente alinhado aos critérios exigidos em primeira
instância.
 42

17 CONCLUSÃO

O software é todo o processo que envolve sua concepção, desenvolvimento,

teste se a entrega do sistema para o cliente que, provavelmente, irá demandar
cada vez mais recursos ou funcionalidades mediante novas necessidades. Com
base nisso e focado em testes de caixa preta padronizados pelos alunos, foi
possível mapear entradas e saídas esperadas do software, de modo a obter
parâmetros que propusessem resolver problemas que surgiram após analise da
versão corrente, tornando assim a curva de desenvolvimento do sistema menos
acentuada com a diminuição de inconsistências que poderiam passar
despercebidos pela equipe de desenvolvedores, uma vez que tais testes permitem
simular com maior precisão o a linha de pensamento do usuário final, com a
diferença de que todo o processo é sistematizado e documentado para uma maior
absorção por parte dos analistas e programadores que poderão propor novas
soluções para futuras versões do sistema.
 43

18 BIBLIOGRAFIA

wikipedia. Disponivel em: <https://pt.wikipedia.org/wiki/Teste_de_software>.

Acesso em: 10 abril 2016.
DEVMEDIA. Disponivel em: <http://www.devmedia.com.br/artigo-engenharia-
de-software-introducao-a-teste-de-software/8035>. Acesso em: 10 abril 2016.
Linha de código. Disponivel em:
<http://www.linhadecodigo.com.br/artigo/2775/introducao-ao-teste-de-
software.aspx>. Acesso em: 10 abril 2016.
Targettrust. Disponivel em:
<http://www.targettrust.com.br/blog/desenvolvimento/testes/os-13-principais-tipos-
de-testes-de-software/>. Acesso em: 10 abril 2016.
testes de software. Disponivel em: <http://www.testesdesoftware.com/>.
Acesso em: 10 abril 2016.
Teste de software. Disponivel em:
<http://www.testesdesoftware.com/2009/09/tipos-de-teste.html>. Acesso em: 10 abril
2016.