Aula 03 - Testes de Software

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

*
*
*
1.9. Confiabilidade de Software
Se um programa deixar de funcionar repetidamente, pouco importa se outros fatores de qualidade de software são aceitáveis. 
Confiabilidade é definida como a probabilidade de operação livre de falhas de um programa de computador num ambiente específico durante determinado tempo.
Falha é uma não conformidade aos requisitos do software
Uma falha pode ser corrigida em segundos, outra pode exigir meses. A correção de uma pode introduzir outras.
*
*
*
Diferentemente do hardware, onde os modelos de confiabilidade baseiam-se em falhas devido ao desgaste, no software todas as falhas remetem-se a problemas de projeto e implementação.
MTBF = MTTF + MTTR
MTBF - mean time between failure (tempo médio entre a ocorrência de falha)
MTTF - mean time to failure (tempo médio até a ocorrência de falha)
MTTR - mean time to repair (tempo médio de reparo)
1.9.1. Medidas de Confiabilidade
*
*
*
É a probabilidade de que um programa esteja operando de acordo com os requisitos em determinado ponto do tempo.
 Disponibilidade = MTTF x 100%
 (MTTF + MTTR)
A medida de disponibilidade é bem mais sensível ao MTTR, que é uma medida indireta da capacidade de manutenção do software.
1.9.2. Medidas de Disponibilidade
*
*
*
Do ponto de vista do ITIL, disponibilidade é a proporção de tempo que um cliente é capaz de acessar um determinado serviço. A disponibilidade é medida do ponto de vista do cliente e registrada no Acordo de Nível de Serviço.
Disponibilidade = Tempo acordado - tempo fora de serviço x 100%
 Tempo acordado
1.9.2. Medidas de Disponibilidade
*
*
*
Categorias de modelos de confiabilidade de software:
1. Modelos que prevêem a confiabilidade como uma função do tempo cronológico (calendário).
2. Modelos que prevêem a confiabilidade como uma função do tempo de processamento transcorrido (tempo de execução da CPU). Estes modelos apresentam os melhores resultados globais.
1.9.3. Modelos de Confiabilidade
*
*
*
Quando o software é usado como parte do controle de Ambientes Críticos, as falhas tornam-se muito mais difíceis de serem detectadas, podendo resultar em significativos danos e até perda de vidas.
É uma atividade que se concentra na identificação e avaliação de casualidades em potencial que possam exercer um impacto negativo sobre o software e fazer com que todo o sistema falhe. 
Se as casualidades puderem ser identificadas, é possível especificar características de projeto que as eliminem ou controlem.
1.10. Segurança de Software
*
*
*
Um processo de modelagem e análise é levado a efeito. Inicialmente, as casualidades são identificadas e dispostas por categorias, criticidade e risco.
Exemplo de algumas casualidades associadas a um piloto automático computadorizado de um automóvel: 
Aceleração descontrolada que não pode ser parada
Não responde à pressão sobre o pedal do freio
Não liga quando o comutador é ativado
Perde ou ganha velocidade lentamente
1.10. Segurança de Software
*
*
*
Logo que as casualidades são identificadas e analisadas, os requisitos relacionados à segurança podem ser especificados.
A especificação pode conter uma lista de eventos indesejáveis e as respostas desejadas a esses eventos.
1.10. Segurança de Software
*
*
*
A confiabilidade de software usa a análise estatística para determinar a probabilidade de que uma falha venha a ocorrer, entretanto, a ocorrência de uma falha não resulta necessariamente num risco ou deformação.
A segurança de software examina as maneiras segundo as quais as falhas resultam em condições que podem levar a uma deformação.
Ou seja, as falhas não são consideradas no vazio, mas são avaliadas no contexto de um sistema por inteiro.
1.10. Segurança de Software
*
*
*
A necessidade de qualidade de software é reconhecida por praticamente todos os gerentes e profissionais da área, porém muito poucos estão interessados em estabelecer funções de Garantia de Qualidade de Software formais.
1.11. Uma Abordagem à GQS
*
*
*
Razões para essa aparente contradição:
Os gerentes relutam em incorrer em custos extras.
Os profissionais acham que estão fazendo tudo o que precisa ser feito.
Ninguém sabe onde colocar essa função na organização.
Todos querem evitar a burocracia que, segundo entendem, a GQS introduzirá no processo de engenharia de software.
1.11. Uma Abordagem à GQS
*
*
*
Um grupo de SQA assume a responsabilidade de estabelecer padrões e procedimentos para conseguir qualidade de software e assegurar que cada um seja seguido.
Escala de Avaliação
da Qualidade
A qualidade é de responsabilidade exclusiva do indivíduo, que pode projetar, revisar e testar em qualquer nível de satisfação.
Onde a empresa se encontra?
Todas as organizações de desenvolvimento têm algum mecanismo para a avaliação da qualidade
1.11. Uma Abordagem à GQS
*
*
*
Preocupações mais importantes para instituir atividades de Garantia de Qualidade de Software:
 Examinar a necessidade de GQS e 
 Estabelecer um plano para instituição da GQS.
1.11. Uma Abordagem à GQS
*
*
*
Antes de mais nada, a organização deve adotar procedimentos, métodos e ferramentas de engenharia de software. Essa metodologia, quando combinada com um paradigma efetivo para o desenvolvimento do software, pode contribuir muito para melhorar a qualidade de todo o software produzido.
A primeira etapa a ser realizada como parte de um esforço para instituir procedimentos de garantia de qualidade é uma auditoria SQA. Tópicos:
 Políticas
 Organização
 Interfaces funcionais
1.11.1 Examinando a necessidade
*
*
*
Quais políticas, procedimentos e padrões atuais existem para todas as fases de desenvolvimento?
Eles são postos em prática?
Há uma política (sustentada pela administração) para GQS?
As políticas são aplicadas tanto para desenvolvimento como as de manutenção?
1.11.2 Auditoria - Políticas
*
*
*
Onde a engenharia de software se localiza no gráfico da organização?
Onde se localiza a garantia de qualidade?
1.11.3 Auditoria - Organização
*
*
*
Qual a relação atual entre as funções de GQS e de garantia de qualidade e outros envolvidos?
Como a GQS interage com as pessoas que executam revisões técnicas formais, gerenciamento de configuração e teste?
Assim que as questões são identificadas, as potencialidades e fragilidades também o são. Se a necessidade de uma GQS for evidente, uma avaliação cuidadosa de prós e contras é efetuada.
1.11.4 Auditoria – Interfaces Funcionais
*
*
*
O software terá menos defeitos latentes resultando em redução do esforço e do tempo gasto durante as atividades de teste e manutenção.
A maior confiabilidade resultará em maior satisfação do cliente.
Os custos de manutenção podem ser reduzidos.
O custo do ciclo de vida global do software é reduzido.
1.12 Aspectos Positivos da GQS 
*
*
*
Difícil de ser instituída em pequenas empresas, onde os recursos disponíveis para realizar as atividades não estão à disposição. 
Representa uma mudança cultural - e uma mudança nunca é fácil.
Exigem gastos que não poderiam ser orçamentados explicitamente
1.12 Aspectos Negativos da GQS 
*
*
*
Logo que uma organização tenha resolvido instituir a Garantia de Qualidade de Software, um plano deve ser desenvolvido e padrões devem ser “adquiridos”.
O Plano constitui um mapa rodoviário para a instituição da garantia da qualidade de software.
fim
1.13 Planejamento da GQS