GigaSlide - Teste de Software (Prova 2)

TMS - Teste e
manutenção de
software
Unidade 02 – Projeto e planejamento de testes
Sistemas de Informação
Professor: Gleisson Amaral
Puc Minas – Unidades Barreiro, Contagem e São Gabriel

Curso: Sistemas de Informação
TMS - Teste e manutenção de software
Unidades de ensino:
2 Projeto e planejamento de testes (2h)

2
2.0 – Projeto e planejamento de testes:
O plano de teste é um documento que aborda

sistematicamente o teste de sistemas.
Ele consiste da modelagem detalhada do fluxo de

trabalho durante o processo de testes, são
abordadas as atividades que comporão o teste e as
ferramentas que serão utilizadas.
Tem como função estruturar as etapas, as

atividades, os artefatos, os papéis e as
responsabilidades do teste, permitindo
organização e controle de todo o ciclo do teste,
minimizando os riscos e agregando valor ao
software.

3
Objetivos do plano de testes:
1. Identificar informações existentes do projeto

e o software que deve ser testado.
2. Listar os requisitos de teste recomendados

(nível alto, com poucos detalhes).
3. Recomendar e descrever as estratégias de

teste a serem empregadas.
4. Identificar os recursos requeridos e fornecer

uma estimativa dos esforços de teste.

4
Objetivos do plano de testes:
Abaixo a estrutura mais comum de um plano de

testes;
1. Introdução. Contém uma identificação do

projeto, descrição dos objetivos do documento,
o público ao qual ele se destina e escopo do
projeto a ser desenvolvido. ...
2. Requisitos a serem testados. ...
3. Estratégias e ferramentas de teste. ...
4. Equipe e infraestrutura. ...
5. Cronograma de atividades. ...
6. Documentação complementar.

5
Análise de um plano de testes real e em uso:
Plano de testes do TCE - Pernambuco

Plano de testes do TJ – Parana
Obs: Ambos estão disponíveis para downlaod no SGA\material didático\Apoio

6
Estudo de caso: Maraka:
Leia atentamente o artigo 03 – Maraká... E responda ao questionário abaixo;
01 – Quais os principais problemas os autores relataram ter encontrado nos processos de testes de software?
02 – Destaque a importância da documentação dos testes segundo os dados oferecidos pelos autores do artigo.
03 – Quais benefícios a infraestrutura maraká oferece ao processo de testes te software?
Poste o questionário acima em formato texto para a atividade relacionada a esta aula.

7
TMS - Teste e
manutenção de
software
Unidade 03 – Confiabilidade de software

Unidades de ensino:
3 Confiabilidade de software (2h)

2
3. Confiabilidade de software / Normas de qualidade:
A confiabilidade de software é definida como a

probabilidade do sistema funcionar sem ocorrência de
falhas num período e ambiente especificados.
Mas, o que vem a ser uma falha? Uma falha é uma

ocorrência quando um serviço ou funcionalidade
entregue por um software não está mais em
conformidade com a especificação.
Para identificar falhas potenciais, existe o teste de

confiabilidade, que no contexto da engenharia de
software, é um teste em que são validadas as entradas,
saídas e operações efetuadas em relação aos requisitos
definidos previamente para a aplicação.

3
3. Confiabilidade de software / Normas de qualidade:
Confiabilidade de software, ao contrário de muitos

outros fatores de qualidade, pode ser medida
diretamente e estimada usando dados históricos e de
desenvolvimento.
Exemplo: Estima-se que o Programa X tenha uma

confiabilidade de 0.96 por 8 horas corridas de
processamento. Se o Programa X for executado 100
vezes e exigir 8 horas de tempo corrido de
processamento (tempo de execução), é provável que
funcione corretamente (sem falha) 96 das 100 vezes.

4
3. Confiabilidade de software:

5
3. Os elementos da confiabilidade de software:
Atributos:
A confiabilidade geral pode ser medida através dos atributos qualitativos ou quantitativos abaixo descritos,
Disponibilidade - disponibilidade para o serviço correto

Confiabilidade - continuidade do serviço correto
Segurança - ausência de consequências catastróficas para o (s) usuário (s) e o meio ambiente
Integridade - ausência de alteração inadequada de dados ou regras do sistema
Manutenibilidade - capacidade de fácil manutenção e reparo
Confidencialidade - Capacidade de manter reserva sobre dados sigilosos

6
3. Os elementos da confiabilidade de software:
Ameaças:
A confiabilidade geral também pode ser medida pelas ameaças que podem afetar um sistema.
Defeito: A presença de um defeito em um sistema pode ou não levar a uma falha, a falha poderá ocorrer em decorrência de
uma combinação específica de parâmetros, falta de parâmetros, ou parâmetros inconsistentes. Ex: Data futura extrema ou
passado extremo
Erro: um erro é uma discrepância entre o comportamento pretendido e real dentro dos limites do sistema. Os erros ocorrem
no tempo de execução quando alguma parte do sistema entra em um estado inesperado. Como os erros são gerados a partir
de estados inválidos, eles são difíceis de observar sem mecanismos especiais. Ex: Referencia a um registro inexistente em uma
tabela de domínio.

7
3.1 Mecanismos que contribuem para a confiabilidade de software:
3.1.1 Padronização
Conjunto de regras que devem ser observadas durante a construção do programa, visando uma homogeneização dos diversos
componentes que integram o sistema.
A padronização confere estrutura e disciplina à forma, permitindo que a codificação de diversos programas se assemelhe.
A padronização deve levar em conta as idiossincrasias da linguagem utilizada, sendo necessária a elaboração de regras
diferenciadas para as diferentes linguagens tratadas.

8
3.1.2 Reutilização do código
Rotinas de uso repetitivo no sistema devem estar pré codificadas em módulos específicos, que podem ser chamados
constantemente para dentro do programa.
Definições de layouts dos arquivos com maiores índices de referência no sistema, bem como definições dos cabeçalhos
tomados como padrão para os relatórios e o conjunto de comandos para sua impressão, devem. também, ser disponibilizados
em módulos de acesso geral.
A utilização destes módulos, além de confiável em função de serem exaustivamente testados, permite que qualquer alteração
neles seja imediatamente assimilada pelos programas que os compartilham, evitando divergências lógicas entre programas.

9
3.1.3 Modularização
É a organização de um programa em unidades independentes, cujo comportamento é controlado por um conjunto de regras.
Suas metas são:
a) Decompor um programa em partes independentes;

b) Dividir um problema complexo em problemas menores e mais simples;
c) Verificar a correção de um modulo de programa, independentemente de sua utilização como uma unidade em um sistema
maior. Permite fácil detecção de erros, por isolá-los, e impede que o erro repercuta no programa como um todo.
A modularização de um programa deve ser construída tendo em vista a redução dos acoplamentos (interdependências) entre
módulos e o aumento da coesão de seus elementos internos (quão fortemente os elementos dentro de um modulo
relacionam-se).

10
3.1.4 Sugestões de incremento da confiabilidade na codificação
a) Descrição do domínio dos conteúdos dos campos que permitam ter suas entradas pré-definidas;
b) Comentários na abertura dos módulos do programa, descrevendo entradas permitidas e saídas esperadas;
c) Sempre que possível, utilização de rotinas de tratamento de erros.

11
3.2 Softwares com tolerância a falhas
Atributos do software que evidenciam sua capacidade de manter um nível de desempenho especificado nos casos de falhas no
software ou de violação nas interfaces especificadas.
3.3 Recuperabilidade das falhas de software
Atributos do software que evidenciam sua capacidade de restabelecer seu nível de desempenho e recuperar os dados
diretamente afetados em caso de falha. bem como o tempo e esforço dispendidos no processo.
Fim

12
TMS - Teste e
manutenção de
software
Unidade 04 – Planejamento de teste de software

Unidades de ensino:
4 Planejamento de teste de (6h)
4.1 Plano de testes (2h)

2
4.1 Plano de testes:
Uma atividade essencial no desenvolvimento de todo e qualquer projeto é o planejamento.
Um plano tem o papel semelhante ao de um ‘mapa’. Sem um mapa, um plano ou qualquer outra fonte de informação similar,
você não conhecerá seus objetivos, nem aonde quer chegar e jamais terá a certeza de ter alcançado sua meta. Perceba que
entender o propósito do planejamento é de suma importância a fim de monitorar a execução de atividades, sendo também
importante conhecer o papel dos riscos no planejamento, bem como diferenciar estratégias de planos. Planejamento
engloba três atividades principais:
1. Definir um cronograma de atividades: estabelecer as atividades que devem ser realizadas, as etapas a serem seguidas e a
ordem cronológica de execução;
2. Fazer alocação de recursos: definir quem realiza as atividades e quais ferramentas/recursos a serem utilizados;
3. Definir marcos de projeto – estabelecer os marcos, ou milestones, a serem alcançados com objetivo de se fazer o
acompanhamento.

3
Sim, os testes de software são planejados. E para garantir a qualidade e o sucesso de uma entrega, durante essa fase existem
documentos que auxiliam e direcionam a equipe nas tomadas de decisões.
Na prática, os mais utilizados são: Plano de testes, suíte de testes e casos de testes (ou cenários de testes, caso estivermos
falando de BDD).
Plano de testes: Formaliza a estratégia de testes, contendo informações sobre o escopo de testes, configuração de
ambiente, recursos necessários e cronograma de testes.
Suítes de testes: Uma coleção de casos de testes destinados a testar um fluxo para verificar um determinado
comportamento.
Casos de testes: Uma especificação detalhada do teste que deve ser repetível, contendo uma ação e um resultado
esperado.
Bartié (2002)

4
Durante a criação do plano de testes, a equipe deve levar em consideração a estrutura da equipe atual e manter o equilíbrio
para a execução de cada tipo de teste.
Em 2009, no livro ‘Succeeding with Agile’, Mike Cohn tornou conhecida uma forma para equilibrar a proporção dos testes
que devem ser executados em cada etapa do desenvolvimento de software, levando em consideração o custo e a
complexidade da execução.
Esta forma foi chamada de Pirâmide de Testes (conforme a figura ao lado) e está
relacionada com a proporção ideal para a implementação de testes automatizados.
No entanto, na prática, esse conceito “pode” por muitas vezes ser invertido.

5
Para ter equilíbrio no planejamento dos testes é necessário entender o significado de cada camada da pirâmide.
Explicando e classificando cada camada:
Testes de unidade: Tem por objetivo garantir que a menor unidade do sistema seja validada, como por exemplo: métodos,
classes, funções. Normalmente são testes realizados pelos desenvolvedores.
Testes de serviço: São testes realizados nos serviços da aplicação, nas regras de negócios abaixo da camada de “UI”.
Normalmente utilizando ferramentas para auxiliar nesse processo, de tal forma, evitando que esse teste seja realizado
apenas quando a “UI” estiver sendo validada. Comprovam a efetiva conexão dos sistemas garantindo a integração entre eles.
Testes de UI (User interface): O objetivo deste teste é focar os esforços nas funcionalidades críticas, em funcionalidades que
envolvam aspectos da interface e diferentes dispositivos (browsers, versões de sistema operacional). É neste momento que a
jornada de navegação do usuário é reproduzido.

6
Conforme a figura 1 (ao lado), na base da pirâmide de testes automatizados se tem um espaço maior para
os testes de unidade, onde, o principal esforço deve ser realizado, por conta de ter um baixo custo para
implementação e execução. Na camada intermediária se tem uma quantidade média para testes de
integração ou de serviços. E por fim, no topo e em menor quantidade os testes de UI, focando nos
principais fluxos do sistema. Figura 1
Conforme a figura 2 (ao lado), adiciona-se um espaço para testes

manuais, logo após os testes de UI, aqui entram aqueles testes que não
são passíveis de automação.
Quando o conceito da pirâmide é invertido, conforme a primeira parte da

figura acima, os planos de economizar tempo, dinheiro e de colher
resultados positivos nas entregas de software, pode ser prejudicados.
Figura 2

7
Itens de um Plano de Teste Conteúdo
1. Introdução Contém uma identificação do projeto, descrição dos objetivos do documento, o público ao qual
ele se destina e escopo do projeto a ser desenvolvido. Pode adicionalmente conter termos e
abreviações usadas, além de informar como o plano deve evoluir.
2. Requisitos a serem Esta seção descreve em linhas gerais o conjunto de requisitos a serem testados no projeto a ser
testados desenvolvido, comunicando o que deve ser verificado. Exemplos de requisitos a serem testados
são: desempenho, segurança, interface de usuário, controle de acesso, funcionalidades.
3. Estratégias e ferramentas Apresenta um conjunto de tipos de testes a serem realizados, respectivas técnicas empregadas e
de teste critério de finalização de teste. Além disso, é listado o conjunto de ferramentas utilizadas.
4. Equipe e infra-estrutura Contém descrição da equipe e da infra-estrutura utilizada para o desenvolvimento das atividades
de testes, incluindo: pessoal, equipamentos, software de apoio, materiais, dentre outros. Isto
visa garantir uma estrutura adequada para a execução das atividades de testes previstas no
plano.
5. Cronograma de Contém uma descrição de marcos importantes (milestones) das atividades (incluindo as datas de
atividades início e fim da atividade). Apenas marcos relevantes devem ser listados, ou seja, aqueles que
contribuirão nas atividades de testes. Por exemplo: projeto de testes, execução de testes ou
avaliação de testes.
6. Documentação Apresenta-se uma relação dos documentos pertinentes ao projeto.
complementar

8
Avaliação de artigo científico: SBQS - Caracterização do Estado da Prática das Atividades de Teste em um Cenário de
Desenvolvimento de Software Brasileiro
O artigo faz parte dos anuários da SBQS – Sociedade Brasileira da Qualidade de Software, e retrata o cenário dos testes de
software na primeira década dos anos 2000, mais precisamente em 2006.
De lá para cá houve grande mudança na disponibilidade e na qualidade das ferramentas para automação de testes.
Assim pede-se;
Leitura atenda do artigo e produção de uma resenha que deverá ser depositada no Canvas até a data limite.
Puc Minas – Unidades Barreiro, Contagem e São Gabriel Fim

9
TMS - Teste e
manutenção de
software
Unidade 04 – Teste de software baseado em riscos

Unidades de ensino:
4.2 Riscos do software (2h)

2
4.2 Riscos do software:
Por definição, no nosso segmento, o risco é qualquer evento improvável e incerto, com impacto positivo ou negativo no
sucesso do projeto. Os eventos imprevisíveis podem afetar os negócios, o custo, a qualidade do produto e a pontualidade da
entrega.
O Teste Baseado em Riscos (TBR) utiliza uma abordagem para verificar a probabilidade de falhas de aplicativos. Esta
metodologia é utilizada com objetivo de testar os diversos cenários possíveis para verificar seu impacto nos negócios.
O TBR prioriza os módulos e funções com base na probabilidade de erros para remover bugs críticos. Qualquer bug crítico
encontrado no ambiente de produção pode levar a clientes insatisfeitos, impactar seriamente sua experiência e causar perda
de negócios.
Essa abordagem de teste também garante que os erros encontrados pelo usuário final não causem impacto nos resultados
da aplicação ou na experiência desse mesmo usuário.

3
Quando usar o teste baseado em risco? Uma vez que é um desafio testar exaustivamente todo o software, por isso é vital
selecionar as partes mais importantes para garantir testes adequados.
• Essa técnica de teste é preferida quando a equipe tem restrições de tempo, recursos e orçamento.
• A técnica é seguida por uma análise baseada em riscos para avaliar as vulnerabilidades do sistema.
• Também é usado para avaliar aspectos críticos dos negócios e áreas propensas a defeitos.

4
Fatos importantes:
• Após o desenvolvimento e mesmo que os requisitos tenham sido estritamente seguidos, não há garantias de que um
sistema de software esteja correto.
• Falhas podem surgir nas mais variadas direções
• Falhas importantes podem permanecer imperceptíveis por anos e fazer o software falhar de maneira inesperada.
Causas mais comuns identificadas no levantamento dos riscos de falha;
• Mudanças em interfaces.
• Aumento no número de usuários
• Alterações no modelo de negócio
• Alterações no ambiente da aplicação

5
O propósito da Análise de Risco de Software é determinar o que testar, a prioridade do teste e a abrangência dos testes
Quem deve fazer? Idealmente, uma equipe de especialistas multidisciplinar composta por;
• Analistas de negócio,
• Analistas de sistema,
• Desenvolvedores,
• Testadores,
• Usuários,
• Outros diretamente interessados.

6
Avaliação de artigo científico: 05 - Proposta de modelo de teste de software baseado em riscos
Pede-se;
Leitura atenta do artigo e produção de uma resenha que deverá ser depositada no Canvas até a data limite.

7
TMS - Teste e
manutenção de
software
Unidade 04 – Cenários de teste de software
Puc Minas – Unidades: Barreiro, Contagem e São Gabriel

Unidades de ensino:
4.3 Cenários de teste (2h)

2
4.2 Cenários de teste x Casos de teste x Scripts de teste:
Apesar de Cenários de teste e casos de teste serem comummente confundidos, eles não são a mesma coisa.
Como escolher entre cenário, caso o script de teste e qual tipo usar? A boa notícia é que não há necessidade de escolher
apenas um, pois usualmente os testadores fazem uso de todos, às vezes simultaneamente.
Numa equipe, os testes serão divididos por habilidade e conhecimento.
• Tem alguma tarefa que precisa ser repetida regularmente e tem um testador disponível? Faça uso do script de teste. Uma
ferramenta robusta como o TestComplete pode usar esses scripts para criar testes automatizados em vários dispositivos,
plataformas e ambientes de forma rápida.
• Pensou em várias ideias que precisam ser testadas e tem um testador habilidoso disponível? Faça uso dos casos de teste.
Agora, precisa pensar em ações mais abrangentes, tentar pensar em como o usuário vai agir? Crie alguns cenários de teste
e coloque seus melhores testadores nesta tarefa.
Todas essas formas de documentação são importantes, contanto que você entenda seus benefícios e limitações.

3
4.2 Cenários de teste:
Um cenário de teste é uma descrição de um objetivo que

o usuário pode encontrar ao utilizar o programa. Um
exemplo seria “Testar se um usuário consegue fazer o
“Log-Off” do programa ao fechá-lo”. Tipicamente, um
cenário de teste vai precisar de diferentes tipos de testes
para garantir que o objetivo tenha sido bem testado.
Utilizando este exemplo, o testador pode escolher fechar o

programa pelo menu, fechá-lo pelo gerenciador de
tarefas, desligar o computador ou como o programa reage
quando fica sem memória e dá erro. Já que os cenários de
testes oferecem pouca informação sobre como completar
o teste, os testadores tem uma grande flexibilização para
buscar uma solução.

4
Assim como os casos de teste, a flexibilidade dos cenários oferecem prós e contras similares. O conhecimento de causa e as
habilidades em testes podem facilitar os testadores a transformar os cenários em ideias concretas, escolher a abordagem
mais lógica e rodar os testes que podem extrair os problemas importantes.
Este tipo de trabalho é um desafio para um testador

habilidoso, mas pode ser difícil ou até mesmo
impossível para um novato.
Entretanto, se o novato estiver amparado em uma

equipe, ele pode aprender o suficiente para conseguir.

5
4.2 Casos de teste:
Os casos de teste descrevem uma ideia específica a ser testada, sem detalhar os dados necessários e etapas exatas a serem
executadas. Por exemplo, um caso de teste poderia ser “Testar se um código de desconto pode ser aplicado em um produto
em promoção”.
Isso não descreve quantos vão ser códigos ou como serão

utilizados. A forma de testar este caso pode variar de tempos
em tempos.
O testador pode usar um link para aplicar o desconto, inserir
um código, solicitar alguém do suporte ao consumidor para
aplicar o desconto ou tentar outras formas criativas de
encontrar o resultado. Os casos de teste proporcionam uma
flexibilidade para os testadores decidirem de que forma eles
pretendem completar o teste.

6
4.2 Casos de teste:
Esta flexibilidade dos casos é boa e ruim. Flexibilidade é benéfica quando o testador já é familiarizado com testes e com os
detalhes do software que está sendo testado. Se o testador entendeu claramente o que já foi testado, o que foi modificado
recentemente no programa e quantos usuários geralmente usam o programa, as estratégias de teste pode ser tanto usar os
caminhos que os usuários normalmente usam ou formas mais inusitadas, para encontrar bugs escondidos.
Por outro lado, se os testadores não tiverem

compreendido como o programa é usado, os
riscos recentes e como avaliar esses riscos
como um testador, eles podem não ter a
informação ou habilidade necessária para
realizar ações que podem encontrar bugs
importantes.

7
4.2 Script de teste:
É a forma mais detalhada de documentar um teste, o script. Quando os scripts de teste são mencionados, geralmente
detalham linha por linha cada ação e dados necessários para rodar o teste. Um script tipicamente tem etapas que ajudam a
entender como usar o programa, quais botões apertar e em qual ordem, como executar uma ação em particular no
programa, etc. Esses scripts também incluem resultados específicos de cada etapa, como a verificação de uma mudança na
interface. Em termos práticos, o exemplo seria:
Ação – Clique no botão X, Resultado – A janela fechou.
Quando um testador começa um novo trabalho, nem sempre ele sabe muito sobre o produto, a abrangência do negócio ou
até mesmo sobre testes de software. Neste momento os scripts entram. Se o testador seguir cuidadosamente as instruções,
inserir “abc”, clicar no botão de enviar, garantir que foi enviado e as informações salvas – essas instruções são uma boa base
para entender a ideia de teste.

8
4.2 Cenários, Casos e Scripts de teste:
Existem alguns pontos importantes a se considerar antes de dedicar muito tempo nos scripts detalhados. Os projetos de
software ativos mudam constantemente, páginas são refeitas, a experiência do usuário muda e novas funcionalidades são
adicionadas.
Para ser mais produtivo com o tempo, os testadores precisam ter um esforço contínuo para atualizar os scripts. O problema
disso é o tempo investido na atualização que poderia ser usado para rodar mais testes. Outro empecilho é que os scripts de
testes são feitos para testar uma coisa específica repetidamente, fazendo uso dos mesmos caminhos e dados toda vez que o
teste é executado.
Isso significa que se tiver algum bug que não esteja no roteiro do script, ele não será encontrado, a não ser que o testador
fuja do script. Testes com scripts não incentivam os testadores a serem criativos e nem habilidosos para encontrar bugs.

9
Avaliação de artigo científico: 06 - Um ambiente para geração de cenários de testes para linhas de produto de software
sensíveis ao contexto
Pede-se a leitura atenta do artigo e;
• Relate os softwares de testes utilizados pelo autor e informe quais benefícios e problemas cada um apresentou.
• Produza uma resenha sobre op artigo
Por fim, deposite um documento com as duas respostas no Canvas até a data limite.

10

GigaSlide - Teste de Software (Prova 2)

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

GigaSlide - Teste de Software (Prova 2)

Enviado por

Direitos autorais:

Formatos disponíveis

TMS - Teste e

Unidade 02 – Projeto e planejamento de testes

Puc Minas – Unidades Barreiro, Contagem e São Gabriel

2 Projeto e planejamento de testes (2h)

Puc Minas – Unidades Barreiro, Contagem e São Gabriel

2.0 – Projeto e planejamento de testes:

O plano de teste é um documento que aborda

Ele consiste da modelagem detalhada do fluxo de

Tem como função estruturar as etapas, as

Puc Minas – Unidades Barreiro, Contagem e São Gabriel

Objetivos do plano de testes:

1. Identificar informações existentes do projeto

2. Listar os requisitos de teste recomendados

3. Recomendar e descrever as estratégias de

4. Identificar os recursos requeridos e fornecer

Puc Minas – Unidades Barreiro, Contagem e São Gabriel

Abaixo a estrutura mais comum de um plano de

1. Introdução. Contém uma identificação do

Puc Minas – Unidades Barreiro, Contagem e São Gabriel

Plano de testes do TCE - Pernambuco

Obs: Ambos estão disponíveis para downlaod no SGA\material didático\Apoio

Puc Minas – Unidades Barreiro, Contagem e São Gabriel

Leia atentamente o artigo 03 – Maraká... E responda ao questionário abaixo;

03 – Quais benefícios a infraestrutura maraká oferece ao processo de testes te software?

Puc Minas – Unidades Barreiro, Contagem e São Gabriel

Unidade 03 – Confiabilidade de software

Puc Minas – Unidades Barreiro, Contagem e São Gabriel

3 Confiabilidade de software (2h)

Puc Minas – Unidades Barreiro, Contagem e São Gabriel

3. Confiabilidade de software / Normas de qualidade:

A confiabilidade de software é definida como a

Mas, o que vem a ser uma falha? Uma falha é uma

Para identificar falhas potenciais, existe o teste de

Puc Minas – Unidades Barreiro, Contagem e São Gabriel

3. Confiabilidade de software / Normas de qualidade:

Confiabilidade de software, ao contrário de muitos

Exemplo: Estima-se que o Programa X tenha uma

Puc Minas – Unidades Barreiro, Contagem e São Gabriel

Puc Minas – Unidades Barreiro, Contagem e São Gabriel

3. Os elementos da confiabilidade de software:

Disponibilidade - disponibilidade para o serviço correto

Puc Minas – Unidades Barreiro, Contagem e São Gabriel

3. Os elementos da confiabilidade de software:

Puc Minas – Unidades Barreiro, Contagem e São Gabriel

3.1 Mecanismos que contribuem para a confiabilidade de software:

Puc Minas – Unidades Barreiro, Contagem e São Gabriel

3.1 Mecanismos que contribuem para a confiabilidade de software:

3.1.2 Reutilização do código

Puc Minas – Unidades Barreiro, Contagem e São Gabriel

3.1 Mecanismos que contribuem para a confiabilidade de software:

a) Decompor um programa em partes independentes;

Puc Minas – Unidades Barreiro, Contagem e São Gabriel

3.1 Mecanismos que contribuem para a confiabilidade de software:

3.1.4 Sugestões de incremento da confiabilidade na codificação

Puc Minas – Unidades Barreiro, Contagem e São Gabriel

3.1 Mecanismos que contribuem para a confiabilidade de software:

3.2 Softwares com tolerância a falhas

3.3 Recuperabilidade das falhas de software

Puc Minas – Unidades Barreiro, Contagem e São Gabriel

Unidade 04 – Planejamento de teste de software

Puc Minas – Unidades Barreiro, Contagem e São Gabriel

4 Planejamento de teste de (6h)

4.1 Plano de testes (2h)