[Música] o [Música] olá eu sou professor marcelo fantinato esta disciplina de engenharia de software do curso de engenharia da computação da univesp vamos agora com a aula número 18 anos e se tratar de teste de software teremos três aulas três vídeo aulas em que nós vamos tratar de teste de software começando com uma visão geral do assunto teste de software nós estamos tratando é do processo de desenvolvimento de software ciclo de vida de desenvolvimento de software já tratamos diferentes etapas do desse ciclo de vida começando com engenharia de requisitos modelagem projeto de de software chegamos
então na etapa da implementação em que nós não tratamos implementação propriamente dita nesta disciplina que a implementação ea codificação programação é para o qual vocês estão vendo em outras disciplinas específicas de programação então basicamente nós pulamos a programação mas qual é o resultado da programação a o código o programa o software propriamente dito que precisa obviamente ser testado para que para que se garanta que ele tenha qualidade então nós vamos agora tratar do teste de software o teste de software pra quem é feito então pra que sim é xeque a seu software tem ou não
qualidade então é basicamente isso que eu resumir na na apresentação da dci da dessa dessa aula eu vou agora detalhar um pouquinho mais como uma marca a população do que nós já vimos desde o início dessa dessa disciplina as vídeo aulas anteriores mas nós então partimos de uma especificação de requisitos do sistema algum tipo de documento que lista todos os requisitos do sistema requisitos do software ou seja o que o cliente deseja que o software o sistema tenha baseado nesses requisitos nós elaboramos um modelo desses tema que representa o comportamento a estrutura na alto nível
o contexto até a interação com o usuário vai ter com esse software enfim algum tipo de modelo alguns modelos é do sistema que representa aí o comportamento em geral do sistema baseado nesses modelos nós então projetamos o sistema projetamos o software ou seja qual quais são os detalhes de do software os detalhes de como o software deve funcionar pra que baseado nesses detalhes então nós possamos implementar o sistema implementar o software propriamente dito ou seja o código a qualificação a programação e então esse baseado nesse código nós precisamos então testar uma pessoa vai é testar
o software para dizer se esse código está ok ou se não está ok se foi encontrado um problema então esse só esse teste é feito em cima do software que foi implementado nós precisamos ver se o que foi implementado está de acordo com o que foi produzido projetado que por sua vez está de acordo com o que foi modelado quem em última instância têm que estar de acordo com o que foi requisitado pelo cliente ou seja nós fechamos todo o ciclo é de vida do software então aqui nessa vídeo aula nós estamos mais preocupados com
a etapa final que é testar o a implementação do sistema mas claro sempre lembrando que a implementação dos sistemas têm que estar de acordo com a os requisitos em última instância bom mas quais os objetivos do teste o que nós queremos é igual ao resultado do teste quando nós pensamos em vamos testar o sistema o que nós queremos com esse teste em geral a primeira coisa que vem à cabeça é a eu quero provar que o software está correto quero provar que não tem nenhum erro no software porém isso é uma visão errada o teste
porque nós nunca conseguimos provar que o software está correto por mais que nós façamos um bom teste de software mas que nós tenhamos bons analistas de testes bons testadores nós nunca vamos conseguir provar que o teste está correto aliás que o software está correto nós isso porque sempre pode haver um defeito escondido no software que ainda não foi capturado então você pode fazer inúmeros testes é detectar inúmeros defeitos em algum momento você começa é não pegar mais defeitos você pode achar que você caé detectou todos os defeitos você pode ter a ilusão de que você
não tem mais defeitos no software mas eles ainda estarão lá você pode ter certeza que ainda existem defeitos lá você não só não está mais conseguindo detectar esses defeitos porque você não está mais fazendo os testes corretos ou seja nós não podemos com o teste de software nós não podemos nunca assumir que nós vamos demonstrar que o software está livre de defeitos ok então nós vamos no máximo assumir que os objetivos do teste encontrar a existência de falhas então nós testamos para encontrar as falhas se nós não estamos mais encontrando falhas é porque o teste
não está sendo bom o suficiente se ele é bom ele encontra falhas no início é muito fácil encontrar as falhas em algum momento ele vai deixar de encontrar falhas porque as falhas mais fáceis de serem encontradas já foram encontradas em algum momento você precisa ser mais esperto mais criterioso é você precisa ser tt técnicas mais avançadas para encontrar as falhas que estão lá escondidas então é resumindo os testes podem mostrar apenas nessa de defeitos mas não a sua ausência então isso é muito importante quando você pra para o analista de teste um testador definir uma
estratégia de teste de software de uma forma um pouco mais sistemática é o que é então essa idéia de teste de software nós temos um sistema que deve ser testado e o que é testar esse sistema é você entrar com dados que o sistema né com a idéia de sistema entra com dados processos dados que saem saída é como resultados do sistema então você pode ter uma série de dados de entrada possíveis essas entradas são processadas você pode ter uma série de saídas possíveis como o sistema possui defeitos embutidos aqui algumas partes do sistema estão
estragadas né não estão corretas algumas possíveis entradas se elas forem escolhidas quando elas entrarem elas vão estimular essas partes dos sistemas que estão estragadas e vão gerar saídas incorretas ok então não é porque eu defini evite algumas partes do sistema estragado que toda a entrada vai sair vai gerar saída com o problema há porquê porque existem parte do sistema que estão ok então determinada entradas vão ser processadas corretamente vão gerar saídas corretas porém algumas entradas vão estimular partes dos sistemas que estão com problema e portanto vão gerar saídas com o problema então qual é o
objetivo do teste tentar encontrar essas entradas que ao serem executadas pelo sistema geram essas saídas que mostram as falhas do sistema é como teste exaustivo é impossível veja festar contudo todas as entradas possíveis é impossível então um bom teste é aquele que consegue observar quais as entradas vão ser mais prováveis de mostrar que o software possui problemas e isso não é algo trivial a bom uma outra há como a gente está falando por enquanto apenas de algumas é o de uma visão geral do teste na próxima aula a gente vai tratar um pouco mais de
técnica de teste então ainda dentro de uma visão geral uma característica um conceito bastante importante dentro da idéia de teste é a as atividades que a gente chama atividades de ver e ver o que é essa tive essa o que são essas atividades de ver vi é de validação e verificação por isso v e vi então quando nós estamos falando de checar a qualidade do software nós podemos ter dois tipos de atividades atividades de verificação e atividades de validação a qual a diferença entre elas ambas são para de alguma forma checar se o software está
sendo produzido com algum nível mínimo de qualidade mas existe uma diferença entre elas obviamente se não você não teria dois tipos de atividade diferente bom a diferença é é umas você quer ter alguma checagem pra saber se algo certo está sendo feito a diferença é a validação é pra você ver checar se você está construindo o software certo o software correto se o software que está sendo construído é aquele que o cliente quer por isso que a gente diz é o software certo é o software correto ou seja se o cliente quer que de 10%
de desconto o software estadão 10% de desconto então pra isso você está validando o software agora a verificação é se você está construindo software da maneira certa da maneira correta se você está construindo software corretamente da maneira certa significa você está usando as técnicas corretas para construir o software ou seja se você tinha que especificar os requisitos usando um caso de uso você foi vista da forma correta você usou o diagrama de casos de uso da forma correta você fez um diagrama de classe da forma correta você usou a linguagem java da forma correta você
é especificou um caso de teste você executou o caso de teste da forma correta você pode estar usando as técnicas da engenharia de software da forma totalmente incorreta e isso é ruim porque porque você pode usar a empresa pode usar um processo da forma totalmente errada a hora que uma outra pessoa precisa substituir alguém ela vai ter uma dificuldade muito grande e isso por tabela pode gerar falta de qualidade no produto final então a validação tem mais a ver com o produto em si ea verificação com o processo sendo definido e quando a gente está
falando de teste teste é uma das atividades de vv mas nós temos por exemplo outros tipos de atividade o teste é uma atividade dinâmica de vv porquê porque você executa o teste dinamicamente você executa mas existe por exemplo inspeções e revisões inspeção em revisão você não executa você abre o código e ver e olhar para o código ou você abre uma especificação de casa de uso e olha então você não está executando você está olhando e procurando os defeitos então o teste como é algo executável você só executa em cima de um programa ou em
cima de um protótipo já uma inspeção você pode fazer uma inspeção em cima de uma especificação de requisitos de uma arquitetura de software de um modelo do ml de um esquema de um banco de dados ou em cima mesmo de um programa só que não em cima da versão executado em cima do código fonte bom finalizando essa parte aqui de divisão geral do teste de software é a gente acaba usando eu mesmo já usei aqui nessa vídeo aula e de repente até de uma forma incorreta porque a gente acaba usando de forma incorreta diferentes palavras
por exemplo erro um defeito bug a falha e aqui engano e também as palavras inglesas ante usa o próprio bug é uma palavra em inglês o erro feio livre e às vezes a gente acaba misturando todas e se temos mas na verdade cada um deles significa uma coisa diferente da então por exemplo quando eu usei quando estava mostrando essa figura aqui é eu tentei dizer exatamente no contexto correto o sistema ele tem alguns defeitos aqui dentro quando eu disse que o sistema estava estragado é porque ele tem alguns defeitos ok e quando uma entrada dessa
parte aqui entra e estimula essas áreas defeituosas que eu tinha falado essas áreas estragadas mas o correto essas áreas defeituosas produz uma saída incorreta quando ele produza uma a uma saída incorreta significa que o sistema falhou então você detectou uma falha no sistema então o que tem dentro do sistema que está com um problema é um defeito e o resultado que você pega durante a execução é uma falha então não é por exemplo se dentro do sistema você deveria ter um x é maior que 10 então faça tal coisa e isso era o correcto e
alguém foi lá e colocou-se x a maior ou igual a 10 isso é um defeito devia ser só um maior que tal maior ou igual e isso é um defeito que está dentro do software você não pode dizer que tem uma falha lá dentro você não pode dizer que tem um erro lá dentro o certo é você dizer que tem um defeito agora se esse defeito faz com que uma pessoa com mais de dez anos deveria ter um desconto de 50% na compra dele mas com dez anos não deveria só há mais de dez então
11 12 13 deveria ter 10% de desconto e aí uma pessoa com dez anos recebeu desconto ela não deveria receber então você executou o sistema com dez anos com 11 anos ganhou se o desconto deveria ganhar 19 anos não deveria ganhar ganhou é não ganhou um toque aí com dez anos como deveria ser maior que 10 ganha desconto com dez anos não deveria ganhar mas como o sistema tem um defeito você entrou com dez anos ele ganhou desconto e não deveria ter ganho quando isso aconteceu você pegou uma falha durante a execução então o sistema
falhou então o nome correto para isso é falha é aí que você deve usar a falha e o erro o que é o erro é o a propagação desse defeito até acontecer a falha ou seja esse quando você passa pelo sistema nessa linha de código que tem um defeito e esse problema vai se propagar até a saída e isso você disse que o software está em condição de erro ok então aqui nós temos e por que aquele defeito aconteceu porque alguém em vez de colocar maior que 10 veio e colocou maior ou igual a 10
porque o programador fim ganhou então houve um engano então a nomenclatura correta é devido a um engano alguém introduziu um defeito no código que ao ser executado coloca o software o sistema em condição de erro o que pode levar uma falha na execução do software porque pode colocar o sistema em condição de erro e pode levar uma falha porque no meu exemplo se nunca você for fazer uma venda por uma pessoa que tem igual exatamente há dez anos isso aqui nunca vai acontecer o defeito está lá mas que nunca tiveram aquela entrada justamente isso aqui
nunca vai acontecer no meu exemplo especificamente a chance de isso nunca aconteceu é muito difícil mas dependendo do software o defeito está lá e pode ser que nunca venha a ocorrer tá e aí nós temos os termos em inglês né quando é que você usa o bug por exemplo o bug é o sinônimo de defeito que na verdade esse nome certo ou falte no blog neckel isso é incerto é é a palavra é informal o prefeito então nós temos uma stay o erro e o filho então cuidado pra não dizer que o software em vez
de dizer que ele tenha um facto que aqui é o defeito você dizer que ele tem uma feira livre filho é a falha ok então com isso nós finalizamos essa visão geral de teste de software e nas próximas duas aulas nós vamos começar a falar um pouco mais de detalhes técnicos a respeito de teste de software obrigado [Música] [Música] [Música] [Música]
