1. Definição e classificação de problemas de software
1 Classificação de problemas de software
a. Erro de software
b. Defeito de software
c.
Falha de software d.
Definição de falha de software :
(1) erro de software: refere-se ao ciclo de vida do software indesejável ou inaceitável erro humano, o resultado do qual levará a defeitos de software.
Pontos de preocupação: erro humano
(2) defeitos de software: aqueles desvios indesejáveis ou inaceitáveis no software (programas, dados, documentos).
Pontos de preocupação: deficiências ou áreas incompletas
Geralmente, podem existir defeitos de software quando uma das cinco condições a seguir é atendida.
a. O software não cumpre as funções especificadas no manual do produto.
b. O software apresenta um erro que não ocorrerá conforme especificado no manual do produto.
c. A função do software está além do escopo especificado no manual do produto.
d. O software não atinge a meta que a especificação do produto não indica, mas deveria ser alcançada.
e. Os testadores de software acham que o software é difícil de entender, difícil de usar, lento para executar e os usuários finais acham que não é fácil de usar.
(3) Falha de software: Refere-se ao estado interno indesejável ou inaceitável que ocorre durante a operação do software. Se não houver medida apropriada (tolerância a falhas ou mecanismo de tratamento de exceções) para lidar com isso a tempo, ocorrerá falha de software.
Preocupação: estado interno
(4) falha de software: refere-se a um resultado indesejável ou inaceitável de comportamento externo quando o software está sendo executado.
Foco: Resultado do comportamento externo2
. Mecanismo de falha de software
Erro de software ——> Defeito de software ——> Falha de software ——> Falha de
software Erro de software é um tipo de erro humano. Um erro de software deve produzir um ou mais defeitos de software.
Quando um defeito de software é ativado, ocorre uma falha de software.
O mesmo defeito de software é ativado em condições diferentes, o que pode causar falhas de software diferentes.
Se as falhas de software não forem tratadas a tempo usando a tolerância a falhas, isso inevitavelmente levará a falhas de software.
A mesma falha de software pode produzir falhas de software diferentes em condições diferentes.
3 - Causas de erros e defeitos de software O
principal motivo é a inconsistência entre o software desenvolvido, a especificação de requisitos e a especificação de design de software, e o fracasso em atingir o objetivo das necessidades dos usuários potenciais na realização do software.
2. Rastreamento e gerenciamento de erros de software
1. Severidade e prioridade de defeitos e erros
a. Nível de severidade
severo: falha do sistema, perda de dados, destruição de dados.
Mais sérios: erros operacionais, resultados errados, funções ausentes.
Geral: pequenos problemas, erros de digitação.
Recomendação: Não afeta o uso de falhas ou melhor realização.
b. Prioridade Prioridade
mais alta: Repare imediatamente e interrompa os testes adicionais.
Segunda prioridade mais alta: deve ser corrigida antes do lançamento do produto.
Prioridade média: deve ser corrigida antes do lançamento do produto.
Prioridade mais baixa: pode ser corrigida, mas pode ser liberada.
2 Gerenciamento de rastreamento de erros de software
Descrição de informações de bug a. Informações de
registro de bug
Nome do software de
teste Número da versão de teste
Nome do
evento de
teste de teste de software e ambiente de configuração de hardware
constatou que o tipo errado de
nível de gravidade de erro de software
etapas detalhadas
necessárias
anotação de teste de referência
b.Bug processamento de processamento de informações
Nome do
tempo de
processamento das etapas
de processamento do estado atual do log de erros
3 Erro de software Descrição do status
a. Novas informações (Nova): o bug de software recentemente relatado (Bug) no teste.
b. Abrir: O erro foi confirmado e atribuído aos desenvolvedores relevantes para processamento.
c. Fixo (Fixo): O erro foi corrigido pelo desenvolvedor e está aguardando a verificação do testador.
④ Recusado: Testadores seniores ou desenvolvedores acreditam que não é um erro e se recusam a modificar o bug.
⑤ Adiado: Este erro não será corrigido na versão atual, mas será corrigido na próxima versão.
⑥ Fechar (Custado): O erro foi corrigido e verificado.
4.
Etapa do processo de gerenciamento de erros : a
primeira etapa: o testador envia novas informações de erro e as insere no banco de dados de informações de erros do sistema de gerenciamento de rastreamento de erros (como TD), e o estado de erro é definido como o estado inicial "Novo" .
Etapa 2: testadores seniores verificam os erros e lidam com eles de acordo.
① Se a confirmação for um erro, atribua-o ao desenvolvedor correspondente e defina o status do erro para "Aberto".
② Se o testador sênior acreditar que o "erro" no status "Novo" não é um erro, ele se recusará a modificar e definir o status de erro como "Recusado".
Etapa 3: O desenvolvedor consulta todos os erros com o status "Aberto" e lida com os erros da seguinte maneira:
① Se o desenvolvedor acredita que o erro com o status "Aberto" não é um erro, recuse-se a modificar e definir o status do erro para "Recusado".
② Se for um erro, corrija-o e defina o status do erro para "Corrigido".
③ Se for um erro sem solução, deixe uma descrição em texto e mantenha o status do erro como "Aberto".
④ Se você precisar adiar a resolução do erro, deixe uma descrição de texto e defina o status do erro para "Adiado".
Nota: Para erros não resolvidos e adiados, o desenvolvedor não pode decidir por si mesmo e geralmente requer algum tipo de reunião (reunião de revisão) para passar antes da aprovação.
Passo 4: O testador consulta todos os erros com o status "Corrigido", verifica se esses erros foram resolvidos e faz o seguinte tratamento:
① Se o problema for resolvido, defina o status do erro para "Custado".
② Se o problema não for resolvido, defina o status de erro para "Aberto" novamente.
5. Princípios de gerenciamento de processos de erro
① Para garantir a correção do tratamento de erros, testadores com ampla experiência em testes são necessários para verificar se os erros encontrados são erros reais e se as etapas de teste escritas são precisas e podem ser repetidas.
② As informações de processamento devem ser mantidas para cada processamento de erro, incluindo nome de processamento, hora, método de processamento, processamento de opinião, status do bug, etc.
③Rejeção ou adiamento de erros de tratamento não podem ser decididos unilateralmente pelo programador, mas devem ser decididos em conjunto pelo gerente de projeto, gerente de teste e gerente de design.
④Após o erro ser reparado, ele deve ser verificado pelo testador que relatou o erro, e o erro pode ser fechado após a confirmação de que foi corrigido.
⑤Forte a comunicação entre testadores e programadores. Para erros no estado "Adiado", eles precisam trocar opiniões para evitar que erros reais sejam perdidos. Para alguns erros que não podem ser repetidos, você pode pedir aos testadores para adicionar etapas e métodos de teste detalhados, bem como casos de teste necessários.
Eu recomendo um grupo de teste de software aqui, QQ; 642830685. O grupo compartilhará recursos de teste de software, perguntas de entrevista de teste e informações do setor de teste de vez em quando. Você pode trocar tecnologia ativamente no grupo. Além disso, existem especialistas técnicos para responder para você. problema. Depois de ler, lembre-se de me curtir, seus curtidas são minha motivação inesgotável para atualizar o artigo. Reabasteça, recarregue!
Depois de ler