PIM V ADS UNIP

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

UNIP INTERATIVA
Projeto Integrado Multidisciplinar
Cursos Superiores de Tecnologia
PROJETO DE DESENVOLVIMENTO DE UM ROTEIRO DE TESTES PARA UM SISTEMA DE FORMATAÇÃO DE ARTIGOS ACADÊMICOS
XXXXXXXXX
XXXX
UNIP – Universidade Paulista
UNIP INTERATIVA
Projeto Integrado Multidisciplinar
Cursos Superiores de Tecnologia
PROJETO DE DESENVOLVIMENTO DE UM ROTEIRO DE TESTES PARA UM SISTEMA DE FORMATAÇÃO DE ARTIGOS ACADÊMICOS
XXXXXXXXX
RA: XXXXXX
Curso: Análise e Desenvolvimento de Sistemas
2° Semestre
XXXXXXX
XXXXX
UNIP – Universidade Paulista
RESUMO
Atualmente a engenharia de software dispõe de todo um arcabouço de ferramentas, técnicas e práticas destinadas à tarefa de estudos que tem a finalidade de agregar qualidade ao produto, podendo assim também fazer uma medição desta qualidade em relação aos defeitos encontrados e propor soluções. Este estudo prevê a elaboração de dez roteiros de um tipo específico de teste, chamado caixa-preta, no qual consiste na analise de um tipo de defeito denominado de funcionalidade, que é quando o software não faz o que o usuário espera que ele faça. O roteiro seguirá os casos de teste destinados no projeto de software para forma tação de artigos acadêmicos e todas as observações e verificações devem ser devidamente armazenadas e documentadas.
Palavras chaves: teste, caixa-preta, software, roteiro, desenvolvimento;
ABSTRACT
Nowadays, software engineering has a whole set of tools, techniques and practices aimed at the task of studies that have the purpose of adding quality to the product, thus also making a measurement of this quality in relation to the defects found and proposing solutions. This study envisages the preparation of ten scripts of a specific type of test, called a black box, in which it consists of the analysis of a type of defect called functionality, which is when the software does not do what the user expects it to do. The script will follow the test cases intended in the software design for writing academic articles and all observations and verifications should be properly stored and documented.
Key words: test, black box, software, script, development;
SUMÁRIO
	INTRODUÇÃO.............................................................................................................6
OBJETIVO GERAL.....................................................................................................7
2.	CONCEITO DE CAIXA PRETA................................................................................7
3. 	AVALIAÇÃO HEURÍSTICA DE INSTERFACE.....................................................7
4. 	MÉTODOS DE INSPEÇÃO DE USABILIDADE.....................................................8
5. 	ROTEIRO DE TESTES...............................................................................................9 
6.	AVALIAÇÃO HEURÍSTICA...................................................................................19
CONCLUSÃO.........................................................................................................................20
REFERÊNCIAS BIBLIOGRÁFICAS..................................................................................21
INTRODUÇÃO
O Projeto Integrado Multidisciplinar é um trabalho que consiste em apresentar todas as disciplinas estudadas enquadradas no projeto. A princípio o presente trabalho visa descrever toda prática que envolve a Análise e Desenvolvimento de Sistemas dentro do projeto, do ponto de vista prático em conformidade com o aprendizado visto a partir de livros, sites e em tele aulas no decorrer do atual período. 
Este artigo pretende dar um breve descritivo sobre a atividade de testar e avaliar softwares, fazendo uma abordagem das dimensões do teste - Como, o Que e Quando testar -, o ciclo de vida do produto, papéis e suas responsabilidades de uma equipe de analista de testes , o processo de testes como o planejamento e controle , e por fim mostra a definição de uma Fábrica de Testes de Software.
OBJETIVO GERAL
Desenvolver e executar um roteiro de testes caixa-preta em um sistema de forma tação de artigos acadêmicos e gerar os resultados obtidos com o teste, além de realizar uma inspeção de usabilidade no sistema por meio da técnica de avaliação heurística e a presentar um relatório com os resultados .		
CONCEITOS DE CAIXA-PRETA
O teste de tipo caixa-preta, o analista não tem acesso ao código fonte e desconhece a estrutura interna do sistema em que esta analisando. Este teste também conheci do como teste funcional, pois é baseado nos requisitos funcionais do software. O foco, nesse caso, é nos requisitos da aplicação, ou seja, nas ações que ela deve desempenhar. Para que possamos mostrar quais tipos de problemas que esse teste rastreia, podemos citar alguns exemplos : 
 1. Data de nascimento preenchida com data futura; 
 2. Campos de preenchimento obrigatório que não são validados; 
 3. Utilizar números negativos em campos tipo valor a pagar; 
 4. Botões que não executam as ações de vidas. 
 Enfim, todo tipo de falha funcional , ou seja, falhas que contrariamos requisitos da aplicação. Há que se destacar, contudo, que existe um elemento com um aos dois tipos de teste. Tanto no teste de caixa branca quanto no teste de caixa preta , o analista não sabe qual será o comportamento da aplicação ou do alvo de teste em uma determinada situação. A imprevisibilidade de resultados é com um aos dois casos.
3.	AVALIAÇÃO HEURÍSTICA DE INTERFACE
A Avaliação Heurística é um método de inspeção utilizado por arquitetos de informação e designer de interação para realizar testes de usabilidade em interfaces de modo rápido, fácil e barato. O termo avaliação heurística foi introduz ido por volta do início da década de 90 por Jakob Nielsen e Rolf Molich , que desenvolveram métodos e estabeleceram padrões previam ente testados que fornecem subsídios para deixar as interfaces mais fáceis para s erem utilizadas por seus usuários . Para realização dos teste de usabilidade são selecionados de 3 a 5 avaliadores , nos quais submetem-se as partes do projeto, por exemplo, sites institucionais, portal de conteúdo, e-commerces , sites para dispositivos móveis , protótipos, entre outros . 
Aos princípios heurísticos, é possível realizar comparativos entre o que foi projeta do na interface e o que realmente é necessário para um elo sólido e consistente, assim havendo uma maior interação humano computador, gerando assim um eixo que define o que deve ser considerado com o primordial para o desenvolvimento de websites e, em seu bojo, é necessário considerar os elementos relacionados à sua adequada estruturação, como Arquitetura da Informação, Arquitetura de Design, Navegabilidade, Conteúdo e Interatividade. A cada etapa realizada é atribuído o valor da gravidade de cada problema encontrado nas interfaces por intermédio da escala proposta em (Nielsen e Mack, 1994a), vejam os a seguir essa escala e o que se relaciona:
0 – Não é considerado, totalmente, um problema de usabilidade; 
1 – Problema apena s estético: não necessita ser consertado a menos que tenha tempo extra disponível no projeto; 
2 – Problema menor de usabilidade: o concerto deste problema deverá ser baixa prioridade; 
3 – Problema maior de usabilidade: é importante conserta-lo , para isso deverá ser dado alta prioridade; 
4 – Catástrofe de usabilidade : é obrigatório conserta-lo, antes do produto ser divulgado. 
 	MÉTODOS DE INSPEÇÃO DE USABILIDADE
Métodos
de inspeção de usabilidade têm por objetivo a avaliação de aspectos visuais relacionados com a usabilidade de interfaces a fim de detectar problemas no projeto e fazer recomendações para a eliminação de tais problemas, questão relacionados a aspectos de uma interface de usuário que podem causar problemas na aprendizagem de seu uso, no próprio uso eficiente do sistema ou no grau de satisfação do usuário. Temos alguns tipos de métodos de inspeção, que podem variar dê acordo com cada interface que é projetada. A seguir mostramos alguns desses tipos: 
 - Automático: um software de a vali ação baseado em métricas específicas monitora a execução de tarefas via a interface em avaliação e produz diagnósticos baseados nos dados coletados (em geral, tem impacto limitado). 
- Empírico: usabilidade é avaliada, com base na experiência prática do avaliador, em sessões com usuários.
- Formal: utiliza-se de modelos para localizar problemas de usabilidade . 
- Informal: a vali ações se baseiam em regras de senso com u m bem como habilidades, conhecimento e experiência de avaliadores (avaliações usualmente sem a participação de usuários).
 Nem sempre é fácil obter usuários "típicos" (representantes do universo do público alvo ) para participar de sessões de teste , alguns problemas não são descobertos em testes com o usuário , a combinação de avaliação mais teste produz resultados mel hores e satisfatórios Análise depende do que for considerado problema e do julgamento de como diferentes aspectos problemáticos podem ter como causa um mesmo problema subjacente. Todo aspecto que sofre u uma alteração e melhorou uma ou mais medidas de usabilidade pode ser considerado um problema de usabilidade.
Recomendações para a correção de problemas detectados e essenciais na reparação e diagnostico de usabilidade, para isso são da s recomendações que pode m ser mais difícil do que detectar problemas (pra alguns problemas a solução pode ser óbvia como trocar o rótulo de um botão e para outros não ). Priorizar problemas encontrados em função do grau de severidade para auxiliar no planejamento de alocação de recursos para resolvê-los. Os mais severos devem ser consertados independentemente do custo de tais consertos. 
	ROTEIRO DE TESTES
Caso de teste 1: Gerar um artigo completo com um autor cadastrado com sucesso ( nenhum campo pode ser branco). Resultado do teste 1: 
Caso de teste 2: Gerar um artigo para submissão com um autor cadastrado com sucesso (nenhum campo pode ser branco).
Caso de teste 3: Gerar um artigo completo com três autores cadastrados com sucesso (nenhum campo pode ser branco).
Caso de teste 4: Gerar um artigo completo com três autores com e-mails inválidos (nenhum campo pode ser 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 ser 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 ser branco), criando no campo “corpo do texto” um texto com formatação em negrito, itálico, subscrito e sobrescrito com texto justificado com sucesso.
Caso de teste 8: Gerar um artigo completo com um autor cadastrado com sucesso (nenhum campo pode ser 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 ser 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.
Conforme a imagem acima, quando se pede para gerar o artigo em branco somente o campo e-mail é obrigatório, o restante gera o arquivo em branco. 
 
 
 AVALIAÇÃO HEURÍSTICA
 
No meu ponto de vista , os campos teriam que ser e ter botões de incremento de opções para facilitar ao usuário. Também teria que ter campo para anexar imagem. Na visualização teria que ter o rewell em PDF que até o momento isso ainda não é possível.
CONCLUSÃO
O teste de software é uma das áreas pouco conhecida da Tecnologia da Informação e é , ao mesmo tempo, uma das mais antigas e fundamentais para a entrega de um produto de boa qualidade e de alta tecnologia. Para poder testar um software , o profissional que está envolvido com a área, precisa estudar constantemente e estar ante nado com as novas tecnologias do momento que poderão ser utilizadas no desenvolvimento do futuro sistema. Por isso ele precisa ser crítico, comprometido e saber discutir sobre o produto para mostrar ao desenvolvedor o problema que precisa ser corrigido. Dependendo da metodologia que é aplica da na empresa para efetuar o processo de desenvolvi mento de software. Se for utilizado um modelo ágil, que tem a metodologia mais atual, ou o modelo “V”, o profissional de teste começará o seu trabalho já na concepção e construção da análise d o software. Isso significa que antes de efetuar o desenvolvimento, o profissional fará a análise de teste buscando informações de como o usuário espera que o sistema reaja medi ante a solução que será implementada. Neste processo já podemos descobrir alguns possíveis erros do software. Por tudo isso, o teste de software pode ser visto como uma boa parcela do processo de qualidade de software. Ele existe para obter um controle de qualidade do produto averiguando, se este atende a os requisitos propostos e trazendo uma vantagem competitiva do produto no mercado.
REFERÊNCIAS BIBLIOGRÁFICAS
Alexandre Bartie. “Processo de Teste de Software – Parte 01”. http://imasters.uol.com.br/ artigo/6102 /des_de_software/processo_de_teste_de_software_parte_01/. Publicado em 07/05/2007. 
Alexandre Bartie. Fábrica de Testes – Parte 01. http://imasters.uol.com.br/artigo/4435/des_de_software/fabrica_de_testes_parte_01/. Publicado em 26/07/2006. 
KRUCHTEN , Philippe ; “Introdução ao RUP Rational Unified Process”; Editora Ciência Moderna