1

UNIP INTERATIVA

ANALISE E DESENVOLVIMENTO DE SISTEMAS

BRUNO CSAR MANOEL SIQUEIRA RA: 1548816

PIM V CASOS DE TESTES

ARARAQUARA

2016
 2

BRUNO CSAR MANOEL SIQUEIRA

PIM V CASOS DE TESTES

Monografia apresentada como exigncia para

obteno 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 avaliao do PIMV referente
ao Curso superior Tecnolgico em Analise e desenvolvimento de Sistemas. A tcnica
utilizada para avaliar se o sistema est de acordo como as conformidades previstas
pelo Departamento de Extenso, Pesquisa e Ps-graduao a funcional caixa-
preta que verifica situaes de sucesso e insucesso na execuo de determinadas
funcionalidades denominadas casos de teste. A universidade informou 10 casos de
testes os quais sero criados roteiros especficos para cada caso, executados e
geradas as evidencias dos sucessos ou insucessos observados. Ao final ser gerado
um relatrio final apontando as possveis falhas do sistema, auxiliando a DEPP na
aceitao do Sistema.

Palavras-chave: sistema, teste, projetos, anlise.

 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

Sumrio

1 Introduo ............................................................................................................... 7
2 Testes ...................................................................................................................... 8
2.1 Tcnicas para testes ........................................................................................... 9
2.2 Tcnica 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 Relatrio final ..................................................................................................... 41
17 Concluso ........................................................................................................... 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 INTRODUO

A Engenharia de Software cresceu bastante ao longo do tempo procurando

assegurar critrios, tcnicas, mtodos e ferramentas para a produo de um bom
software, em consequncia disso, o aumento da utilizao de sistemas baseados em
computao 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 produo.
A Engenharia de Software pode ser conceituada ento como uma disciplina
que aplica os princpios de engenharia com o objetivo de produzir software de alta
qualidade e de baixo custo e atravs de um conjunto de etapas que envolvem o
desenvolvimento e aplicao de mtodos, tcnicas e ferramentas, oferece meios
para que tais objetivos possam ser alcanados.
O processo do desenvolvimento de um software envolve uma srie de
exerccios nas quais, apesar dos mtodos, das tcnicas e ferramentas empregadas,
erros no produto ainda podem existir. As prticas associadas sob o nome de
Garantia de Qualidade de Software tm sido introduzidas ao longo de todo processo
de desenvolvimento, entre elas destacamos atividades de Verificao, Validao e
Teste, que tem por objetivo minimizar a ocorrncia de erros e riscos associados ao
produto.
Dentro dessas tcnicas de verificao e validao, existe a atividade de teste,
uma das mais utilizadas e importantes, constituindo-se em um dos elementos para
fornecer evidncias da confiabilidade do software complementando outros requisitos,
por exemplo, o uso de revises e de tcnicas formais e rigorosas de especificao e
de verificao.
A Prtica de teste consiste em uma anlise dinmica do produto e uma
atividade de grande importncia para a identificao e eliminao de problemas que
persistem. Do ponto de vista de qualidade do processo, o teste sistemtico uma
prtica fundamental para o crescimento para o Nvel Trs do Modelo CMM do
Software Engineering Institute. Ainda, o conjunto de informao oriundo da prtica
de teste significativo para as atividades de depurao, manuteno e de
confiabilidade de um Software. Refora-se que a atividade de teste tem sido
apontada como uma das mais onerosas no desenvolvimento de software, porm
de extrema importncia para garantia de um software de qualidade.
 8

2 TESTES

Testes de software so 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
cdigo e o de caixa-preta, no.

Teste de Instalao: Consiste em testar se o software instala como planejado em

diferentes hardwares e em diferentes condies como pouco espao de
memria, interrupes de rede, interrupes na instalao, etc.

Teste de Configurao: Testa se o software funciona no hardware que ele ser

instalado.

Teste de Integridade: Testa a resistncia do software a falhas, ou seja, a robustez.

Teste Funcional: Testa os requisitos funcionais, funes e os casos de uso (A

aplicao faz o que deveria fazer?).

Teste de Integrao: Testa se um ou mais componentes combinados funcionam de

maneira adequada. Pode-se dizer que o teste de integrao composto por vrios
testes de unidade.

Teste de Segurana: Testa se o sistema e os dados so acessados de maneira

segura apenas pelo usurio autorizado das aes.

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

normal de dados e transaes envolvendo o banco de dados durante um
longo perodo 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 condies normais de uso, exemplo o tempo de resposta, nmero
de transaes por minuto, usurios simultneos; Teste de stress, testa o software
sob condies extremas de uso. Grande volume de transaes e usurios
simultneos. Picos excessivos de carga em curtos perodos de tempo e Teste de
estabilidade testa se o sistema se mantm funcionando de maneira adequada aps
um perodo de uso.

Teste de Usabilidade: um teste focado na experincia do usurio, consistncia da

interface, layout, acesso s funcionalidades, etc.

Teste de Regresso: um reteste de um sistema ou componente para verificar se

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

Teste de Manuteno: Testa a mudana de ambiente se no interferiu no

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

2.1 TCNICAS PARA TESTES

Para se conduzir e avaliar a qualidade da atividade de teste tm-se as tcnicas de

teste funcional, estrutural e baseada em erros. Tais tcnicas diferenciam-se pela
origem da informao utilizada na avaliao e construo dos conjuntos de casos
de teste. Nesta monografia apresenta-se com mais detalhes a tcnica funcional ou
caixa preta como conhecido. Atravs desse critrio, os principais aspectos
pertinentes atividade de teste de cobertura de software. Para propiciar uma viso
mais abrangente, apresenta-se primeiramente uma viso geral da tcnica funcional
e os critrios mais conhecidos dessa tcnica.
 10

2.2 TCNICA FUNCIONAL

O teste funcional tambm conhecido como teste caixa preta pelo fato de tratar o
software como uma caixa cujo contedo desconhecido e da qual s possvel
visualizar o lado externo, ou seja, os dados de entrada fornecidos e as respostas
produzidas como sada.

Na tcnica de teste funcional so veri ficadas as funes do sistema sem se

preocupar com os detalhes de implementao.

O teste funcional envolve dois passos principais: identifi car as funes que o
software deve realizar e criar casos de teste capazes de checar se essas funes
esto sendo realizadas pelo software. As funes que o software deve possuir so
indentifi cadas a partir de sua especifi cao. Assim, uma especifi cao bem
elaborada e de acordo com os requisitos do usurio essencial para esse tipo de
teste.

Alguns exemplos de critrios de teste funcional so. :

Particionamento em Classes de Equivalncia: a partir das condies de entrada de

dados indentifi cadas na especifi cao, divide-se o domnio de entrada de um
programa em classes de equivalncia vlidas e invlidas. Em seguida seleciona-se o
menor nmero possvel de casos de teste, baseando-se na hiptese que um
elemento de uma classe seria representativo da classe toda, sendo que para cada
uma das classes invlidas deve ser gerado um caso de teste distinto. O uso de
particionamento permite examinar os requisitos mais sistematicamente e restringir o
nmero de casos de teste existentes. Alguns autores tambm consideram o domnio
de sada do programa para estabelecer as classes de equivalncia.

Anlise do Valor Limite: um complemento ao critrio Particionamento em Classes

de Equivalncia, sendo que os limites associados s condies de entrada so
exercitados de forma mais rigorosa; ao invs de selecionar-se qualquer elemento de
uma classe, os casos de teste so escolhidos nas fronteiras das
 11

classes, pois nesses pontos se concentra um grande nmero de erros. O espao

de sada do programa tambm particionado e so exigidos casos de teste que
produzam resultados nos limites dessas classes de sada.

Grafo de Causa-Efeito: os critrios anteriores no exploram combinaes das

condies de entrada. Este critrio estabelece requisitos de teste baseados nas
possveis combinaes das condies de entrada. Primeiramente, so levantadas as
possveis condies de entrada (causas) e as possveis aes (efeitos) do
programa. A seguir construdo um grafo relacionando as causas e efeitos
levantados. Esse grafo convertido em uma tabela de deciso a partir da qual so
derivados os casos de teste.

Um dos problemas relacionado aos critrios funcionais que muitas vezes a

especifi cao do programa feita de modo descritivo e no formal. Dessa maneira,
os requisitos de teste derivados de tais especifi caes so tambm, de certa forma,
imprecisos e informais. Como consequncia, tem-se difi culdade em automatizar a
aplicao de tais critrios, restritos aplicao manual. Por outro lado, para a
aplicao desses critrios essencial apenas que se indentifi quem as entradas, a
funo a ser computada e a sada do programa, o que os tornam aplicveis
praticamente em todas fases de teste (unidade, integrao e sistema).
 12

3 FUNDAMENTOS DO TESTE DE SOFTWARE

O teste expe 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 tangvel.
Depois vem o teste. O engenheiro cria uma srie de casos de testes, que so
destinados a "demolir o software que foi construdo. 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 so por natureza pessoas construtivas. O teste
exige que o desenvolvedor reveja noes preconcebidas da "corretividade" do
software recm desenvolvido e supere um conflito de interesses que ocorre quando
erros so descobertos.

3.1 OBJETIVOS DO TESTE

Glen Myers enumera algumas regras que podem servir bem como objetivos
do teste:
1. Teste um processo de execuo 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 no descoberto.
3. Um teste bem-sucedido aquele que descobre um erro ainda no
descoberto.
Esses objetivos implicam uma dramtica mudana de ponto de vista. Eles vo
contra a viso comum de que um teste bem-sucedido aquele no qual no so
encontrados erros. Nosso objetivo projetar testes que descobrem
sistematicamente diferentes classes de erros e faz-lo com uma quantidade mnima
de tempo ou esforo.
Se o teste for conduzido de maneira bem-sucedida (de acordo com os
objetivo declarados anteriormente), ele descobrir erros no software. Como benefcio
secundrio, o teste demonstra que as funes do software parecem estar
funcionando do acordo com a especificao de que os requisitos de comportamento
 13

e desempenho parecem estar sendo satisfeitos. Alm disso, os dados coletados

medida que o teste conduzido fornecem uma boa indicao da confiabilidade do
software e alguma indicao da qualidade de todo o software.

3.2 PRINCIPIOS DO TESTE

Antes de aplicar mtodos para projetar casos de teste efetivos, um

engenheiro de software deve entender os princpios bsicos que guiam o teste de
software. Davi sugere um conjunto de princpios 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 indesejveis (do ponto de vista do cliente) so aqueles que levam o programa a
deixar de satisfazer seus requisitos.
Os testes devem ser planejados muito antes do incio do teste. O
planejamento de teste pode comear to logo o modelo de requisitos seja
completado. A definio detalhada dos casos de teste pode comear to logo o
modelo de projeto tenha sido consolidado. Assim sendo, todos os testes podem ser
planejados e projetados antes que qualquer cdigo tenha sido gerado.
O princpio de Pareto se aplica ao teste de software. Colocado simplesmente
o princpio de Pareto implica que 80% de todos os erros descobertos durante teste
vo provavelmente ser relacionados a 20% de todos os componentes do programa.
O problema, sem dvida, isolar os componentes suspeitos e test-los
rigorosamente.
O teste deve comear "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 no possvel. A quantidade de permutaes de caminho
mesmo para um programa de tamanho moderado, excepcionalmente grande. Por
essa razo, impossvel executar todas as combinaes de caminhos durante o
 14

teste. possvel, no entanto, cobrir adequadamente a lgica do programa e garantir

que todas as condies no projeto, a nvel de componente, tenham sido exercitadas.
Para ser mais efetivo, o teste deveria ser conduzido por terceiros. Por mais
efetivo, ns 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 no a pessoa adequada para conduzir todos os
testes do software.

3.3 TESTABILIDADE

Antes de aplicar mtodos para projetar casos de teste efetivos, um

engenheiro de software deve entender os princpios bsicos que guiam o teste de
software. Davi sugere um conjunto de princpios 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 indesejveis (do ponto de vista do cliente) so aqueles que levam o programa a
deixar de satisfazer seus requisitos.
Os testes devem ser planejados muito antes do incio do teste. O
planejamento de teste pode comear to logo o modelo de requisitos seja
completado. A definio detalhada dos casos de teste pode comear to logo o
modelo de projeto tenha sido consolidado. Assim sendo, todos os testes podem ser
planejados e projetados antes que qualquer cdigo tenha sido gerado.
O princpio de Pareto se aplica ao teste de software. Colocado simplesmente
o princpio de Pareto implica que 80% de todos os erros descobertos durante teste
vo provavelmente ser relacionados a 20% de todos os componentes do programa.
O problema, sem dvida, isolar os componentes suspeitos e test-los
rigorosamente.
O teste deve comear "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 no possvel. A quantidade de permutaes de caminho

mesmo para um programa de tamanho moderado, excepcionalmente grande. Por
essa razo, impossvel executar todas as combinaes de caminhos durante o
teste. possvel, no entanto, cobrir adequadamente a lgica do programa e garantir
que todas as condies no projeto, a nvel de componente, tenham sido exercitadas.
Para ser mais efetivo, o teste deveria ser conduzido por terceiros. Por mais
efetivo, ns 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 no a pessoa adequada para conduzir todos os
testes do software.

4 PLANEJAMENTO

O projeto deve ser executado para que sirva de avaliao do PIMV referente
ao Curso superior Tecnolgico em Analise e desenvolvimento de Sistemas.
A tcnica utilizada para avaliar se o sistema est de acordo como as
conformidades previstas pelo Departamento de Extenso, Pesquisa e Ps-
graduao e a funcional caixa-preta que verifica situaes de sucesso e insucesso
na execuo de determinadas funcionalidades denominadas casos de teste.
A universidade informou 10 casos de testes os quais sero criados roteiros
especficos para cada caso, executados e geradas as evidencias dos sucessos ou
insucessos observados.
Ao final ser gerado um relatrio final apontando as possveis falhas do
sistema, auxiliando a DEPP na aceitao 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 submisso com um autor cadastrado
com sucesso (nenhum campo pode ficar em branco).
 16

Caso de teste 3: Gerar um artigo completo com trs autores cadastrados com
sucesso (nenhum campo pode ficar em branco).
Caso de teste 4: Gerar um artigo completo com trs autores com e-mails
invlidos (nenhum campo pode ficar em branco).
Caso de teste 5: Gerar um artigo completo com trs 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 formatao em negrito, itlico, 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
Alm dos casos de testes relacionados s regras de negcio, ser necessrio
criar os testes relativos ao comportamento tcnico da tela do sistema.
Avalie a tela do sistema e crie, para todos os campos e controles existentes,
os testes de interface relacionados a: domnio de todos os campos; Validao de
cada campo; Aes em botes e links existentes; Mensagens exibidas pelo
sistema.
Com os casos de teste acima podemos iniciar a etapa de criao de um
roteiro de teste modelo que auxiliar na execuo 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

No tem boto 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 RELATRIO FINAL

O DEPP (Departamento de Extenso, Pesquisa e Ps- graduao) de uma

universidade necessitou de uma soluo em forma de software que pudesse atender
a critrios normativos em quesito da mais adequada formatao de artigos para
serem submetidos a congressos e revistas cientficas da prpria universidade
solicitante do servio.
Com isso, se fez neces sria a contratao de uma empresa que pudesse
desenvolver o software proposto, sendo que ele deveria atender a alguns critrios
mencionados a seguir, como: Estar de acordo com as normas de formatao
adotadas pelo DEPP, possuir o mximo de 42.000 caracteres e gerar duas verses
que seriam a blind review e a outra com a devida identificao do(s) autor (es) do
artigo.
Para a devida validao do Sistema de Formatao de Artigos Acadmicos
desenvolvido, foi solicitado aos alunos do curso de Anlise e Desenvolvimento de
Sistemas realizarem diversos testes tcnicos (em caixa preta) que fogem aos
domnios do conhecimento dos usurios finais, que esto de acordo com critrios da
Engenharia de Software, de modo a mitigar erros que poderiam ou podem ocorrer
com o contnuo uso do sistema.
Houve um consenso entre os alunos para uma padronizao dos testes a
serem realizados, de forma a criar um mtodo mais claro e eficaz para a validao
dos casos propostos pelo coordenador do curso de ADS, criando assim passos
concisos para a melhor absoro da interao e criando mtricas para as respostas
provenientes do sistema, no deixando de lado a anlise das funcionalidades bem
como da interface e interatividade do sistema desenvolvido.
Aps testes sistemticos, os alunos conseguiram observar em uma viso
holstica as respostas de acordo com as entradas propostas em cada caso ou roteiro
e, a partir de tal premissa, uma avaliao geral do software foi realizada,
demonstrando os prs e contras encontrados na verso corrente disponibilizada.
Tendo em vista estas respostas, deve-se esperar uma gradual evoluo do sistema
a fim de que esteja perfeitamente alinhado aos critrios exigidos em primeira
instncia.
 42

17 CONCLUSO

O software todo o processo que envolve sua concepo, 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
possvel mapear entradas e sadas esperadas do software, de modo a obter
parmetros que propusessem resolver problemas que surgiram aps analise da
verso corrente, tornando assim a curva de desenvolvimento do sistema menos
acentuada com a diminuio de inconsistncias que poderiam passar
despercebidos pela equipe de desenvolvedores, uma vez que tais testes permitem
simular com maior preciso o a linha de pensamento do usurio final, com a
diferena de que todo o processo sistematizado e documentado para uma maior
absoro por parte dos analistas e programadores que podero propor novas
solues para futuras verses 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 cdigo. 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.