1°

Em primeiro Lugar realizar testes e esquematizando as funções completas de um software se

fosse de texto por exemplo, cuidaria do básico. (editar abrir fechar textos)2°mexeria na
estética criaria layout sempre partindo do básico e testando em cada passo. Verificaria se o
programa realiza suas atribuições de forma confiável, Se cada método de entrada a saída
obtida corresponde ao objetivo esperado, verificar se não existem erros de lógica e código, no
fluxo de dados, no entendimento de requisitos, de codificação, tipográficos ou de interface em
todas as fases do projeto, Identificar e interferir na presença do erro, iniciando-se a depuração,
corrigir todos os erros identificados., depois realizar o teste de segurança passo e realizar por
ultimo um teste de validação para ter totalmente certeza que o software ira atender com
todas as expectativas nele desenvolvidas.

Leia mais em Brainly.com.br - https://brainly.com.br/tarefa/7681077#readmore

2°

#SegurançaDaInformação #Redes #Professor

Olá, vou ajudá-la a responder essa questão.

Primeiramente, explicando, pois essa questão parece um pouco com o curso/diciplina de

Engenharia de Software:

Em Engenharia de Softwares estudamos "Qualidade de Software":

Para que um Software seja de Qualidade, é necessário Testes nele, para isso devemos nos
fundamentar em 3 Prinicipios:
Definir um cronograma, uma sequência de etapas que deve ser aplicada.

Aqui você vai definir todas as etapas, tempo estimativo para a conclusão, vai DIVIDIR as tarefas
do que será analisado e testado.

Passar as Atividades a serem executadas com seus respectivos recursos.

Quem vai realizar e com quais recursos vai fazer.

Definir os Marcos do Projeto.

Basicamente Estabelecer Marcos/Milestones, para fazer um acompanhamentodo projeto.

APROFUNDANDO NA MATÉRIA:

De forma mais simples, com um papel em mãos, poderíamos definir 12 passos fundamentais
básicos e comuns a maioria dos Softwares.

1 - Teste de Compatibilidade do Software com o Hardware

Se o Software é compatível com os recursos de Hardware (Memória, Processador etc).

2 - Teste de Instalação do Software no Sistema Operacional Principal

Se existe conflito dos recursos do Sistema Operacional com o Software, espaço em disco,
Drivers e outros Softwares, tais como Antivírus, recursos de Rede, se durante a instalação
acontece paradas ou se ele afeta o Sistema Operacional.

3 - Teste de Integridade dos recursos do Software

Chamado de Robustez do Software, verifica-se a sua "resistência" a erros ou falhas e execução
ou de código. Basicamente se o Software se manterá íntegro, com a menor chance possível de
ser modificado.

4 - Teste de Segurança dos Dados usados pelo Software.

Digamos que seu Software é uma rede social interna, em uma Intranet, para ele salvar os
dados (Nome, Senha, Conversas)ele usa um Banco de Dados também interno, será que o
Software diretamente acessado pelo Usuário permite que alguém acesse sua Senha, por meio
de uma falha do Action, ou no Import, será que os dados são enviados criptogrados na rede
por meio do POST, será que esse Banco de Dados tem falhas que permitem um SQL Inject.

5 - Teste de Funcionalidade do Software

"Será que o Software faz tudo o que deveria fazer?" "Será que ele tem todos os recursos
necessários do objetivo ou contratado, será que ele não tem mais do que realmente precisa?"
- Todas essas perguntas devem ser feitas para esse teste.

6 - Teste de Unidade

Aqui você vai avaliar os recursos um por um, classe por classe do código.

7 - Teste de Integração

Será que os recursos do Software funcionam de forma integrada sem Bugs, exemplo, vou
pegar esse Site, que é um Software, será que é possível, enquanto eu escrevo essa resposta ver
minhas notificações sem que o Site ou o código Bugue. Testar mais de um recurso
simuntaneamente.

8 - Teste de Volume
Será que o SO está se comportando normal com o uso de processo que o Software vai exigir
em sua funcionalidade padrão, ou se a rede vai permitir.

9 - Performace do Software.

Você vai stressar ele kkkk, testar se ele roda bem, mesmo após um longo período de uso, se os
usuários ficam estáveis (No caso de uma Rede Social), se todos os dados (Vídeos, Áudios,
Imagens e Textos) estão rodando de forma satisfatória.

10 - Teste de Uso ou Usuabilidade do Software.

"O Layout, os botões, a aparência e seu uso é intuitivo, o visual Facilidade o uso por um leigo?"
"Se o usuário apertar o Botão 15 vezes seguidas de 'Solicitar Ficha', será que o Software vai
abrir de forma redundante a mesma solicitação?" - Tudo isso.

11 - Caixa Branca e Caixa Preta.

Testa os recursos do código e visuais. Entra aqui algumas das etapas ditas a cima.

12 - Manutenção

Verifique se o Software e seu uso não afetou o SO de forma negativa ou modificou algum
recurso do SO ou de outros Softwares.

Espero ter ajudado, até mais!

Leia mais em Brainly.com.br - https://brainly.com.br/tarefa/7769236#readmore

3°
A atividade de teste durante o ciclo de vida do software

Autora: Luciane Neves - GPS

Resumo

Este é o primeiro de uma série de artigos onde é realizado um estudo da atividade de

testes e sua aplicação durante o ciclo de vida do software como uma ferramenta para
aumentar a qualidade do produto e otimizar a utilização dos recursos empregados no
processo de teste de software.

Neste artigo serão considerados os princípios, objetivos e classificação dos testes, com a
finalidade de fundamentar, através do estudo da teoria de testes, os assuntos que serão
abordados posteriormente.

Palavras-chave: acurácia, ciclo de vida, confia-bilidade, desenvolvimento, qualidade,

revisão, testes.

1. Introdução

A fase de testes ocupa, normalmente, 40% do tempo planejado para um projeto e um

erro descoberto tardiamente em um sistema provoca um acréscimo de 60% nos custos
do projeto[6]. Nenhum programador ou analista, por mais experiente que seja, está
imune a falhas de codificação e projeto.

Estes são alguns dos motivos que têm feito com que a atividade de teste de software
tenha se tornado um dos itens mais estudados no contexto de aprimoramento da
qualidade de software.

Apesar de parecer simples à primeira vista, a atividade de teste exige um bom

planejamento e controle durante a execução para ser bem sucedida. Conhecer os
aspectos da atividade de testes como as limitações, objetivos, formas de criação de
massa de testes e de aplicação de técnicas de teste de acordo com o momento do
projeto, facilita o trabalho de planejamento e controle.

E nesta atividade o melhor é investir ao longo de todo o processo de forma equilibrada

para evitar a necessidade de um esforço muito grande e menos efetivo ao final do
desenvolvimento.

2. Qualidade de software e testes

A história da garantia de qualidade no desenvolvimento de software tem paralelo com a

história da qualidade no processo de manufatura de hardware. Na fase inicial da
computação (décadas de 50 e 60), a qualidade era uma responsabilidade exclusiva do
programador, sendo que padrões de garantia de qualidade para o software foram
introduzidos no desenvolvimento de software sob contrato militar durante a década de
70. A partir daí espalharam-se rapidamente para o desenvolvimento comercial
de software [6].

Neste artigo entende-se que a atividade de teste deve ser usada em todas as etapas do
processo de desenvolvimento de software e que, ao invés de representar uma última
revisão, seja utilizada como "milestone" entre todas as fases do projeto, pois os erros,
como afirma Deutsch, podem estar já nas primeiras fases do projeto, e quanto mais
tarde forem descobertos, maior impacto causarão. Do ponto de vista financeiro, um
estudo realizado pela IBM [3] mostra que enquanto um erro encontrado e corrigido
durante a fase de projeto custa 1 unidade monetária, se o mesmo for encontrado
durante a atividade de testes de código, custará 15 unidades. Após o lançamento do
produto, a correção do mesmo erro custará entre 60 e 100 unidades monetárias.

3. Teste de software

Este capítulo abordará os aspectos fundamentais da atividade de teste, através de

revisão bibliográfica. Os princípios, limitações e objetivos da atividade de teste serão
apresentados nos itens que se seguem. Veremos também as características principais de
cada classe de testes.

3.1 Considerações

Programar é um exercício para resolução de problemas[1], uma vez que um programa é

um modelo que pretende representar a solução para um problema do mundo real
escrito em linguagem de máquina. Por ter tal característica, faz parte do processo
determinar se esta representação da solução é válida e correta.

Se considerarmos que todas as definições produzidas ao longo do ciclo de vida

do software podem ser representadas em linguagem formal, pode-se perceber que
todos estes produtos podem ser testados de forma a validar e medir sua qualidade.

Os objetos testados são todos aqueles que aparecem durante o processo de

desenvolvimento de software. Isto inclui módulos de código, especificações de requisitos
e projeto, estruturas de dados, e qualquer outro objeto que surja durante o processo de
desenvolvimento e implementação de software.

Portanto, o termo programa designa qualquer objeto que possa ser conceitualmente ou
realmente executado. É este o significado utilizado no presente artigo.

Programas podem ser vistos como uma função, uma vez que descrevem o
relacionamento dos elementos de entrada com os elementos de saída. O processo de
testes é utilizado para verificar se o programa realiza suas atribuições de forma
confiável, ou seja, se para uma determinada entrada, a saída obtida corresponde à
esperada.

Uma completa validação do programa em qualquer estágio do ciclo de vida pode ser
obtida através da execução do processo de teste para cada valor de entrada possível. Se
cada instância for bem-sucedida, o programa foi verificado; senão, um erro foi
encontrado. Este método é conhecido com o teste exaustivo e é a única técnica de
testes que garantiria a validade do programa. Lamentavelmente esta técnica não é
viável. Na maior parte dos casos, o domínio da função (conjunto de dados de entrada
possíveis) é infinito, ou quando finito, grande o bastante para fazer o número de testes
requeridos inviável.

Visando reduzir o número potencialmente infinito de testes do processo de testes

exaustivos para um número possível, deve-se encontrar um critério para selecionar
elementos representativos do domínio da função. Estes critérios devem refletir tanto a
descrição funcional quanto a estrutura do programa.

O subconjunto de elementos selecionado para ser usado no processo de testes é

chamado de conjunto de dados de teste ou ‘test set". No entanto, o problema é
encontrar um test set adequado, que seja grande o suficiente para englobar todos os
valores válidos do domínio e suficientemente pequeno para que se possa testar
elementos de cada tipo de entrada do conjunto.

A principal técnica de teste continua sendo executar o software usando uma massa de
testes que contenha dados representativos como entradas para o sistema ou módulo e
comparar a saída gerada com a esperada. Diferenças representam falhas que devem ser
corrigidas.

3.2 Princípios do teste de software

Adaptando a citação de Glen Myers[5] , pode-se dizer que a atividade de teste

de software é o processo de revisar especificações, projetos e programas com a intenção
de descobrir erros. Alguns dos itens que são comuns a todos autores e pesquisadores do
assunto "teste de software" e que descrevem os fundamentos e princípios desta
atividade, estão relacionados abaixo:

 Conforme a Lei de Pareto, 80% dos erros podem ser localizados em 20% do
projeto, geralmente nos módulos principais do sistema;

 A atividade de teste não prova a ausência de erros, apenas a existência dos

mesmos;

 Bons casos de teste são aqueles que encontram falhas no sistema até então não
descobertas;

 Bons casos de teste são projetados levando em conta os requisitos do projeto;

 Um critério que pode ser utilizado para determinação do esforço a ser gasto na
atividade de teste de software é verificar qual o grau de severidade das
conseqüências advindas do seu mau funcionamento;

 A probabilidade de encontrar um erro numa determinada parte do sistema é

proporcional ao número de erros já encontrados nesta parte;

 A maior parte dos autores concorda que os programas devem,

preferencialmente, ser testados por pessoas não envolvidas no processo de
desenvolvimento, por uma equipe independente. Pode haver também a
interação dos desenvolvedores com a equipe independente, justificando as
decisões tomadas durante o projeto. Esta abordagem ajuda na revisão do
 projeto.

3.3 Objetivos do teste

O objetivo da atividade de teste pode ser entendido da seguinte forma:

 no início de cada fase verificar se esta etapa do projeto reflete exatamente os

requisitos e definições da fase imediatamente anterior, para com isso garantir
que o produto encomendado e o gerado pela atividade de desenvolvimento do
software sejam os mesmos, através dos diferentes níveis de refinamento do
projeto;

 verificar se não existem erros de lógica no projeto e código, no fluxo de dados,

no entendimento de requisitos, de codificação, tipográficos ou de interface em
todas as fases do projeto;

 identificar e interferir na presença do erro, iniciando-se a depuração, sendo que

quanto antes for descoberta a falha, menos custoso será para adequá-la;

 ter em mente que, uma vez que errar é humano e atividade de desenvolvimento
de software é um exercício bastante complexo, os erros existem e devem ser
descobertos. Portanto, o sucesso em um teste consiste em descobrir os erros e
corrigi-los.

3.4 Classificação dos testes

Podemos classificar os métodos de teste de acordo com suas características básicas.

Existem testes estáticos e dinâmicos, testes estruturais e funcionais, testes de unidade e
integração, testes de validação, testes alfa e beta, testes de recuperação, testes de
segurança, testes de estresse e testes de desempenho. Pode-se descrever
resumidamente cada um destes grupos da seguinte forma:

 Testes estáticos ou testes humanos: não são feitos através da execução real do
programa, mas sim através da execução conceitual do mesmo. Métodos
classificados como estáticos são os de walkthrough, inspeções e peer rating. São
utilizados principalmente para validar as primeiras etapas do projeto como: de
elicitação de requisitos, projeto preliminar e projeto detalhado, podendo ser
usados para validar o código também.

 Testes dinâmicos: Requerem que o programa seja executado, e por isso seguem
o modelo tradicional de teste de programa, no qual o programa é executado
com alguns casos de teste e os resultados da execução são examinados para
verificar se o programa operou de acordo com o esperado. São usados
principalmente na validação do código em módulos e na integração geral do
sistema.

 Testes funcionais: Uma vez que testes exaustivos não são viáveis, características
do domínio de entrada são examinadas para que se tente descobrir formas de
derivar um conjunto de dados de teste representativo que consiga exercitar
 completamente a estrutura do sistema. Os dados de teste precisam ser
derivados de uma análise dos requisitos funcionais e incluir elementos
representativos de todas as variáveis do domínio. Este conjunto deve incluir
tanto dados de entrada válidos quanto inválidos. Geralmente, os dados no
conjunto de dados de teste podem ser classificados em três classes: de fronteira,
não de fronteira e especiais. Exemplificando: Se X for um número e se
tivermos Xtal que, a < X < b, então X deve ser testados para os valores a + 1 e b –
1 da classe válida, para os valores a e b da classe inválida e para valores especiais
tais como zero, vazio, ou caracteres alfabéticos. São considerados métodos de
testes funcionais ou de caixa preta: o particionamento de equivalência, a análise
de valor limite, a técnica de grafo de causa-efeito e os testes de comparação.

 Testes estruturais: Diferentemente dos testes funcionais, que se preocupam

com a função que o programa desempenha sem se preocupar com a maneira
como a função foi implementada, o teste estrutural enfoca a implementação e a
estrutura da função. Embora geralmente usado durante a fase de codificação,
testes estruturais podem ser usados em todas as fase do ciclo de vida
do software nas quais o software é representado formalmente. A intenção do
teste estrutural é encontrar dados de teste que terão cobertura suficiente de
todas as estruturas presentes na representação formal.

 Testes de unidade: Concentra-se no esforço de verificação da menor unidade de

projeto de software: o módulo. Através do uso da descrição do projeto
detalhado como guia, caminhos de controle importantes são testados para
descobrir erros dentro das fronteiras do módulo. Este teste baseia-se sempre na
caixa branca, e esse passo pode ser realizado em paralelo para múltiplos
módulos. Nos testes de unidade são verificados: a interface com o módulo, a
estrutura de dados local, as condições de limite, todos os caminhos
independentes através da estrutura de controle e todos os caminhos de
tratamento de erros. Um caminho independente é qualquer caminho através do
programa que introduza um novo conjunto de instruções de processamento ou
uma condição nova. O procedimento comumente utilizado para teste de
unidade envolve o desenvolvimento de um software driver e/ou stubpara cada
unidade de teste. O driver é um programa principal que aceita dados de caso de
teste, passa tais dados para o módulo a ser testado e imprime os dados
relevantes. Os stubs servem para substituir módulos que estejam subordinados
ao módulo a ser testado. Um stub ou programa simulado usa a interface do
módulo subordinado, pode fazer manipulação de dados mínima, imprime
verificação de entrada e retorna.

 Testes de integração: O objetivo é, a partir dos módulos testados no nível de

unidade, construir a estrutura do programa que foi determinada pelo projeto de
forma sistemática, testando também a interface dos módulos. A integração pode
ser incremental ou não-incremental. A integração não-incremental, executada
através da abordagem do big-bang combinando-se antecipadamente todos os
módulos, não costuma ser eficaz, dada a amplitude de um teste do programa
 como um todo. Torna-se difícil isolar um erro e, quando esses são corrigidos,
novos erros são gerados na estrutura do programa. Já a integração incremental é
mais eficiente, podendo seguir a abordagem top-down ou a bottom-up.
Discussões sobre as vantagens e desvantagens relativas do teste de
integração top-downversus bottom-up podem ser vistas em [2].

 Testes de validação: O teste de validação pode ser considerado bem sucedido

quando o softwarefunciona da maneira esperada pelo cliente. Ou seja, verifica-
se se o produto certo foi construído, seguindo a especificação de requisitos
do software. A validação do software, na fase de testes, é realizada por meio de
uma série de testes de caixa preta que demonstram a conformidade com os
requisitos.

 Testes alfa e beta: São os testes de aceitação, feitos pelo usuário, que
dificilmente opera o sistema da forma prevista, e visam descobrir erros
cumulativos que poderiam deteriorar o sistema no decorrer do tempo. O teste
alfa é executado por um cliente nas instalações do desenvolvedor, sendo
acompanhado pelo desenvolvedor, que registra os problemas encontrados no
uso. O ambiente é controlado. Já o teste beta é realizado em uma ou mais
instalações do cliente pelo usuário final do software. Geralmente o
desenvolvedor não está presente. Assim, o teste beta é uma aplicação real
do software, sem que haja controle por parte do desenvolvedor. Os problemas
são registrados pelo usuário e repassados regularmente ao desenvolvedor, que
corrige o software antes de lançar o produto para venda.

 Teste de segurança: O teste de segurança tenta verificar se todos os mecanismos

de proteção embutidos em um sistema o protegerão de acessos indevidos.
Todas as formas de ataque devem ser simuladas. A finalidade é dificultar o
acesso indevido de forma que seja mais interessante e barato obter a
informação de forma correta e legal.

 Testes de estresse: O teste de estresse é feito para confrontar o sistema com

situações anormais. O teste de estresse executa o sistema de forma que exige
recursos em quantidade, freqüência ou volume anormais.

 Teste de desempenho: O teste de desempenho é idealizado para testar o

desempenho do softwarequando executado dentro do contexto de um sistema
integrado. Algumas vezes os testes de desempenho são combinados com os de
estresse e podem ser executados durante todo o processo de desenvolvimento.

4. Conclusões

Embora seja difícil medir e definir um software como sendo de boa qualidade, é fácil
identificar um softwarede má qualidade. Os erros freqüentes, o mau funcionamento, ou
a inadequação aos requisitos são sempre notados.

A atividade de testes, quando bem realizada, torna-se uma forma de avaliar e agregar
qualidade ao produto, reduzir custos e retrabalho, melhorando a imagem da empresa e
ampliando sua capacidade competitiva.

Por estas razões, esforços de planejamento e controle da execução de testes devem ser
feitos a partir das etapas iniciais, para que a atividade de testes esteja de acordo com a
qualidade do software que se pretende gerar.

5. Próximos passos

Nos próximos artigos serão apresentadas as técnicas de teste existentes, através de

revisão bibliográfica. Com base nestas técnicas e tendo em vista as necessidades da
atividade de teste para cada etapa do processo de desenvolvimento, será proposta a
aplicação das técnicas ou estratégia que sejam as mais indicadas para as diferentes fases
do projeto.

Serão vistas técnicas funcionais, estruturais, estáticas e dinâmicas, apresentando-se suas

características e oportunidades de aplicação. Para cada fase serão sugeridas alternativas
da utilização das técnicas e listas de revisão, com o objetivo de facilitar o planejamento
da atividade de testes.