Introdução Ao Teste De Software 2nd

Edition Marcio Delamaro Mario Jino

Visit to download the full and correct content document:
https://ebookmass.com/product/introducao-ao-teste-de-software-2nd-edition-marcio-d
elamaro-mario-jino/
Sumário
1. Capa
2. Folha de Rosto
3. Copyright
4. Prefácio
5. Sumário
6. 1 Conceitos Básicos
1. 1.1 Introdução
2. 1.2 Validação, verificação e teste de software
3. 1.3 Alguns termos do jargão
4. 1.4 Fases da atividade de teste
5. 1.5 Técnicas e critérios de teste
6. 1.6 Características e limitações
7. 1.7 Temas relacionados
8. 1.8 Considerações finais
7. 2 Teste Funcional
1. 2.1 Introdução
2. 2.2 Histórico
3. 2.3 Critérios
4. 2.4 Considerações finais
5. Referências
8. 3 Teste Baseado em Modelos
1. 3.1 Introdução
2. 3.2 Máquinas de Estados Finitos
3. 3.3 Sequências básicas
1. 3.3.1 Sequências de sincronização
2. 3.3.2 Sequências de distinção
3. 3.3.3 Sequências UIO
4. 3.3.4 Conjunto de caracterização
4. 3.4 Geração de sequências de teste
1. 3.4.1 Método TT
2. 3.4.2 Método DS
3. 3.4.3 Método UIO
4. 3.4.4 Método W
5. 3.5 Comparação entre os métodos
6. 3.6 Considerações finais
7. Referências
 9. 4 Teste Estrutural
1. 4.1 Introdução
2. 4.2 Histórico
3. 4.3 Definições e conceitos básicos
1. 4.4 Critérios de teste estrutural
2. 4.4.1 Critérios baseados na complexidade
3. 4.4.2 Critérios baseados em fluxo de controle
4. 4.4.3 Critérios baseados em fluxo de dados
5. 4.4.4 Exemplo de aplicação
4. 4.5 Ferramentas
1. 4.5.1 POKE-TOOL
5. 4.6 Considerações finais
6. Referências
10. 5 Teste de Mutação
1. 5.1 Introdução
2. 5.2 Histórico
3. 5.3 Definições e conceitos básicos
4. 5.4 Aplicação do teste de mutação
1. 5.4.1 Geração dos mutantes
2. 5.4.2 Execução do programa em teste
3. 5.4.3 Execução dos mutantes
4. 5.4.4 Análise dos mutantes vivos
5. 5.5 Ferramentas
1. 5.5.1 Proteum
2. 5.5.2 µJava
6. 5.6 Mutação de interface
7. 5.7 Mutação em modelos
8. 5.8 Outros trabalhos
9. 5.9 Considerações finais
10. Referências
11. 6 Teste Orientado a Objetos e de Componentes
1. 6.1 Introdução
2. 6.2 Definições e conceitos básicos
3. 6.3 Tipos de defeitos em POO
1. 6.3.1 Efeitos colaterais da programação OO
4. 6.4 Fases de teste OO
5. 6.5 Estratégias, técnicas e critérios de teste OO
1. 6.5.1 Critérios estruturais
2. 6.5.2 Estratégia de teste incremental hierárquica
6. 6.6 Teste de componentes
 1. 6.6.1 Estratégias e critérios de teste
2. 6.6.2 Problemas no teste de integração
7. 6.7 Ferramentas
8. 6.8 Considerações finais
9. Referências
12. 7 Teste de Aspectos e Teste Apoiado por Aspectos
1. 7.1 Introdução
1. 7.1.1 Definições
2. 7.1.2 AspectJ
2. 7.2 Teste de programas OO apoiado por aspectos
1. 7.2.1 Imitadores virtuais de objetos
2. 7.2.2 Teste embutido em componentes
3. 7.2.3 Verificação de padrões de código
4. 7.2.4 Teste de invariantes, pré e pós-condições
5. 7.2.5 Instrumentação de código
3. 7.3 Teste de programas orientados a aspectos
1. 7.3.1 Teste estrutural de unidade
2. 7.3.2 Teste estrutural de integração
3. 7.3.3 JaBUTi/AJ: uma ferramenta de teste estrutural
4. 7.3.4 Teste baseado em estados
5. 7.3.5 Teste de mutação
6. 7.3.6 Proteum/AJ: uma ferramenta de teste de mutação de programas
AspectJ
7. 7.3.7 Estratégia de ordenação de classes e aspectos para o teste de
integração
4. 7.4 Considerações finais
5. Referências
13. 8 Teste de Aplicações Web
1. 8.1 Introdução
2. 8.2 Teste estrutural
3. 8.3 Teste baseado em modelos de comportamento
4. 8.4 Teste baseado em defeitos
1. 8.4.1 Teste de mutação
2. 8.4.2 Injeção de erros
5. 8.5 Teste baseado em sessões do usuário
6. 8.6 Considerações finais
7. Referências
14. 9 Teste de Programas Concorrentes
1. 9.1 Introdução
2. 9.2 Programas concorrentes
 3. 9.3 Tipos de erros em programas concorrentes
4. 9.4 Teste estrutural de programas concorrentes
1. 9.4.1 Critérios estruturais de teste
2. 9.4.2 Exemplo de aplicação
5. 9.5 Teste determinístico e não determinístico
6. 9.6 Teste de mutação em programas concorrentes
7. 9.7 Ferramentas
1. 9.7.1 Ferramentas para teste estrutural
2. 9.7.2 Ferramentas para teste de mutação
3. 9.7.3 Ferramentas para teste baseado em modelos
4. 9.7.4 Ferramentas para detecção de deadlock e condições de disputa
5. 9.7.5 Ferramentas para teste determinístico
6. 9.7.6 Ferramentas para execução simbólica
8. 9.8 Considerações finais
9. Referências
15. 10 Teste em Dispositivos Móveis
1. 10.1 Introdução
2. 10.2 Engenharia de aplicações móveis
3. 10.3 Teste de software para aplicações móveis
1. 10.3 .1 Tipos de teste para aplicações móveis
2. 10.3.2 Abordagens para execução dos testes
3. 10.3.3 Critérios de teste em lojas de aplicativos
4. 10.4 Tipos de falhas em aplicações móveis
5. 10.5 Testes funcionais/comportamentais em aplicações móveis
1. 10.5.1 Abordagens de teste funcional/comportamental
2. 10.5.2 Ferramentas de teste funcional/comportamental
6. 10.6 Testes estruturais em aplicações móveis
1. 10.6.1 Testes estruturais que auxiliam a cobertura de código
2. 10.6.2 Testes estruturais para detecção de violações de concorrência e
exceção
7. 10.7 Testes de usabilidade em aplicações móveis
1. 10.7.1 Modelo de avaliação de usabilidade em aplicações móveis
2. 10.7.2 Abordagens de teste de usabilidade em aplicações móveis
8. 10.8 Validação de requisitos de qualidade de serviços
1. 10.8.1 Testes de desempenho/confiabilidade
2. 10.8.2 Teste de segurança e privacidade
9. 10.9 Testes de compatibilidade e conectividade em aplicações móveis
1. 10.9.1 Teste de mobilidade e conectividade
2. 10.9.2 Teste de interoperabilidade
10. 10.10 Considerações finais
 11. Referências
16. 11 Estudos Teóricos e Experimentais
1. 11.1 Introdução
2. 11.2 Estudos teóricos de critérios de teste
3. 11.3 Estudos experimentais
1. 11.3.1 Técnicas estrutural e baseada em erros
2. 11.3.2 Técnica funcional
4. 11.4 Considerações finais
5. Referências
17. 12 Geração de Dados de Teste
1. 12.1 Introdução
2. 12.2 Geração aleatória
3. 12.3 Geração com execução simbólica
4. 12.4 Geração com execução dinâmica
5. 12.5 Geração com restrições de defeito
6. 12.6 Geração com algoritmos de busca
1. 12.6.1 Meta-heurísticas
2. 12.6.2 SBST: contexto e diretrizes para a aplicação
3. 12.6.3 Trabalhos com ênfase na estrutura
4. 12.6.4 Trabalhos com ênfase em modelos ou na especificação
5. 12.6.5 Outras abordagens
7. 12.7 Considerações finais
8. Referências
18. 13 Confiabilidade
1. 13.1 Introdução
2. 13.2 Fundamentos de confiabilidade de software
1. 13.2.1 Definições
2. 13.2.2 Medição da confiabilidade
3. 13.2.3 Funções de confiabilidade
3. 13.3 Modelos de confiabilidade
1. 13.3.1 Modelagem
2. 13.3.2 Classificação de modelos de confiabilidade
4. 13.4 Principais modelos de confiabilidade
1. 13.4.1 Modelos de implante de defeitos
2. 13.4.2 Modelos baseados no domínio dos dados
3. 13.4.3 Modelos baseados no domínio do tempo
4. 13.4.4 Modelos baseados em cobertura de teste
5. 13.4.5 Limitações dos modelos de confiabilidade
5. 13.5 Cálculo da confiabilidade de software
1. 13.5.1 Procedimento geral
 2. 13.5.2 Aplicações de medidas da confiabilidade
6. 13.6 Confiabilidade de software para aplicativos móveis
7. 13.7 Considerações finais
8. Referências
19. Índice Remissivo
© 2016, Elsevier Editora Ltda.
Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998.
Nenhuma parte deste livro, sem autorização prévia por escrito da editora, poderá ser reproduzida
ou transmitida sejam quais forem os meios empregados: eletrônicos, mecânicos, fotográficos,
gravação ou quaisquer outros.
ISBN 13: 978-85-352-8352-5
ISBN (versão digital): 978-85-352-8353-2
Copidesque: Jacqueline Gutierrez
Editoração Eletrônica: Márcio Delamaro
Produção digital: Loope | design e publicações digitais - www.loope.com.br
Elsevier Editora Ltda. Conhecimento sem Fronteiras
Rua Sete de Setembro, 111 – 16o andar
20050-006 – Centro – Rio de Janeiro – RJ
Rua Quintana, 753 – 8Oo andar
04569-011 – Brooklin – São Paulo – SP
Serviço de Atendimento ao Cliente
0800 026 53 40
atendimento1@elsevier.com
Consulte nosso catálogo completo, os últimos lançamentos e os serviços exclusivos no site www.
elsevier.com.br.

NOTA
Muito zelo e técnica foram empregados na edição desta obra. No entanto, podem ocorrer erros
de digitação, impressão ou dúvida conceitual. Em qualquer das hipóteses, solicitamos a
comunicação ao nosso serviço de Atendimento ao Cliente para que possamos esclarecer ou
encaminhar a questão.
Para todos os efeitos legais, nem a editora, nem os autores, nem os editores, nem os
tradutores, nem os revisores ou colaboradores, assumem qualquer responsabilidade por
qualquer efeito danoso e/ou malefício a pessoas ou propriedades envolvendo
responsabilidade, negligência etc. de produtos, ou advindos de qualquer uso ou emprego de
quaisquer métodos, produtos, instruções ou ideias contidos no material aqui publicado.
A Editora

CIP-BRASIL. CATALOGAÇÃO-NA-FONTE
SINDICATO NACIONAL DOS EDITORES DE LIVROS, RJ
I48
Introdução ao teste de software / organização Márcio Eduardo Delamaro, José
Carlos Maldonado, Mario Jino. - [2. ed.] - Rio de Janeiro : Elsevier, 2016. il.; 24 cm.
Inclui bibliografia e índice
 978-85-352-8352-5
Software – Testes. I. Delamaro, Márcio Eduardo. II. Maldonado, José Carlos. III.
Jino, Mario.
16-31848 CDD: 005.14
CDU: 004.415.538

31/03/2016 01/04/2016
Prefácio
Elemento fundamental para a manutenção de várias atividades da sociedade contemporânea
(talvez sem exagero de praticamente todas elas, nos próximos anos...), o software se faz presente
nas mais diferentes situações cotidianas, dispositivos e contextos. A ideia do que é um software,
o qual confesso representa uma questão que tenho tentado responder sem muito sucesso,
transcende minha capacidade de abstração e ao mesmo tempo me fascina.
Toda esta reconhecida relevância e importância de um software, ao longo dos anos, tem
motivado a busca por tecnologias que garantam a elaboração e disponibilização de softwares
corretos, seguros, escaláveis, persistentes e ubíquos.
Apesar dos avanços obtidos até então, este elemento ainda apresenta propriedades
desconhecidas para os engenheiros de softwares. Diferentes categorias de softwares (acreditando
ser possível categorizá-los) demandam processos e tecnologias distintas, tornando a tomada de
decisão a respeito de sua engenharia uma tarefa não trivial. Diferentes variáveis de contexto
podem influenciar sua concepção e elaboração. E afetar seu comportamento. Desta forma,
tecnologias que apresentam evidência sobre sua viabilidade, eficiência e eficácia quando
utilizadas no contexto do desenvolvimento e manutenção de um software facilitam o trabalho
dos engenheiros de software. Uma delas, presente em todos os processos de desenvolvimento e
manutenção conhecidos e essencial no ciclo de vida de produtos engenheirados, é o Teste de
Software.
Meus primeiros contatos com atividades chamadas “teste de software” se deram lá pelos anos
1980, ainda na graduação de engenharia elétrica na UFJF. Desenvolvíamos sistemas científicos
para engenharia em Fortran IV, os quais necessitavam realizar cálculos dos mais diversos tipos.
O tal “teste” representava a última chance de verificar um software antes da entrega e implicava
colocá-lo para executar, fornecer dados de entrada que dariam resultados previamente
conhecidos e assim comparar os resultados obtidos com o que se esperava chegando ao
entendimento se algo estaria ou não correto. Encontrava muito “erro”. Sem planejamento
detalhado. Sem qualquer critério de teste que não fossem aquelas funcionalidades “visíveis”. E,
portanto, sem percepção de cobertura e riscos de eventuais problemas adicionais. Tinha alguma
noção do que poderia estar correto. Mas não conseguia ainda perceber o que não estava. Ou o
que deveria fazer para aumentar a capacidade de observação. Felizmente nenhum circuito
elétrico calculado com aqueles softwares colapsou. Talvez hoje definisse aquelas atividades
como teste “ad-hoc”, por delicadeza conceitual...
Lá pelo início dos anos 1990 (final do mestrado e início do doutorado na COPPE/UFRJ) tive a
honra e oportunidade de começar a aprender um pouco mais sobre testes de software com os
grupos de pesquisa representados pelos Professores Mario Jino (DCA/FEC/UNICAMP) e José
Carlos Maldonado (ICMC/USP), atualmente responsáveis por algumas gerações de excelentes
pesquisadores em testes de software no Brasil. Tornei-me um aluno aplicado e usuário do
conhecimento e das tecnologias geradas por eles, fazendo daqueles grupos meu referencial na
área.
Revelar falhas com os testes planejados e a partir daí identificar os defeitos (faltas) no software
passou a ser “lugar comum” em todos os projetos de software dos quais participei. E passou a
representar um tópico importante dentro das disciplinas de engenharia de software que ofereço.
Desde então muita coisa aconteceu e evoluiu. Muito conhecimento tem sido continuamente
produzido e compartilhado. Embora o conhecimento gerado ao longo dos anos ainda não tenha
se propagado totalmente para a indústria, e talvez ainda esteja (em sua forma abrangente)
surpreendentemente distante da maioria dos currículos de graduação, temos hoje um corpo de
conhecimento robusto e baseado em evidência que pode e deve ser utilizado pelos engenheiros
de software na tomada de decisão sobre testes de software e na busca incansável pela eliminação
dos defeitos no software.
Toda esta evolução só foi possível devido à competência e dedicação de grupos de pesquisa
que têm contribuído explicitamente para a evolução do conhecimento sobre Testes de Software.
Neste ponto em particular, devemos destacar e agradecer aos organizadores desta obra
(Professores Mario Jino, José Carlos Maldonado e Márcio Delamaro) juntamente com os vários
autores dos diferentes capítulos (os quais também tive o prazer de conhecer e admirar seu
trabalho) que nos brindam com esta edição revisada e atualizada de Introdução ao Teste de
Software.
O texto apresenta tópicos relevantes ao cenário do teste de software que influenciam seu
planejamento, o projeto de casos de teste, a execução e a análise dos resultados. São 13 capítulos
(independentes e autocontidos) com bibliografia complementar, que oferecem uma discussão
coerente sobre conceitos básicos, teste funcional, teste baseado em modelos, teste estrutural, teste
de mutação, testes orientados a objetos e de componentes, testes de aspectos e teste apoiado por
aspectos, teste de aplicação web, testes de programas concorrentes, testes em dispositivos
móveis, estudos teóricos e experimentais, geração de dados de testes e confiabilidade. A
organização adotada nesta obra torna sua leitura uma atividade amena, permitindo ao leitor
escolher os tópicos adequados à realidade dos projetos e do ensino/aprendizagem na área.
Embora independentes, a leitura do Capítulo 1 (conceitos básicos) é essencial antes da leitura de
quaisquer outros capítulos, pois ele apresenta as bases conceituais para todos os outros.
Continuo em minha trajetória de aprendizado, e ainda não consegui responder à questão básica
do que é um software, mas consigo entender claramente que “a atividade de teste é complexa”,
como bem afirmam os meus Professores Mario Jino, José Carlos Maldonado e Márcio Delamaro
no capítulo inicial deste excelente livro Introdução ao Teste de software. Espero que esta
“complexidade” seja para você, assim como tem sido para mim, um desafio constante e atraente
para justificar a leitura, aplicação e evolução do conhecimento oferecido neste livro nos projetos
de engenharia do software ou no apoio a seus cursos de graduação e pós-graduação.
Boa leitura! Bons testes!

Guilherme Horta Travassos

Professor Titular COPPE/UFRJ
Pesquisador CNPq
Sumário
Capa
Folha de Rosto
Copyright
Prefácio
1 Conceitos Básicos
1.1 Introdução
1.2 Validação, verificação e teste de software
1.3 Alguns termos do jargão
1.4 Fases da atividade de teste
1.5 Técnicas e critérios de teste
1.6 Características e limitações
1.7 Temas relacionados
1.8 Considerações finais
2 Teste Funcional
2.1 Introdução
2.2 Histórico
2.3 Critérios
2.4 Considerações finais
Referências
3 Teste Baseado em Modelos
3.1 Introdução
3.2 Máquinas de Estados Finitos
3.3 Sequências básicas
3.3.1 Sequências de sincronização
3.3.2 Sequências de distinção
3.3.3 Sequências UIO
3.3.4 Conjunto de caracterização
3.4 Geração de sequências de teste
3.4.1 Método TT
3.4.2 Método DS
3.4.3 Método UIO
3.4.4 Método W
3.5 Comparação entre os métodos
3.6 Considerações finais
Referências
4 Teste Estrutural
4.1 Introdução
4.2 Histórico
4.3 Definições e conceitos básicos
 4.4 Critérios de teste estrutural
4.4.1 Critérios baseados na complexidade
4.4.2 Critérios baseados em fluxo de controle
4.4.3 Critérios baseados em fluxo de dados
4.4.4 Exemplo de aplicação
4.5 Ferramentas
4.5.1 POKE-TOOL
4.6 Considerações finais
Referências
5 Teste de Mutação
5.1 Introdução
5.2 Histórico
5.3 Definições e conceitos básicos
5.4 Aplicação do teste de mutação
5.4.1 Geração dos mutantes
5.4.2 Execução do programa em teste
5.4.3 Execução dos mutantes
5.4.4 Análise dos mutantes vivos
5.5 Ferramentas
5.5.1 Proteum
5.5.2 µJava
5.6 Mutação de interface
5.7 Mutação em modelos
5.8 Outros trabalhos
5.9 Considerações finais
Referências
6 Teste Orientado a Objetos e de Componentes
6.1 Introdução
6.2 Definições e conceitos básicos
6.3 Tipos de defeitos em POO
6.3.1 Efeitos colaterais da programação OO
6.4 Fases de teste OO
6.5 Estratégias, técnicas e critérios de teste OO
6.5.1 Critérios estruturais
6.5.2 Estratégia de teste incremental hierárquica
6.6 Teste de componentes
6.6.1 Estratégias e critérios de teste
6.6.2 Problemas no teste de integração
6.7 Ferramentas
6.8 Considerações finais
Referências
7 Teste de Aspectos e Teste Apoiado por Aspectos
7.1 Introdução
7.1.1 Definições
7.1.2 AspectJ
 7.2 Teste de programas OO apoiado por aspectos
7.2.1 Imitadores virtuais de objetos
7.2.2 Teste embutido em componentes
7.2.3 Verificação de padrões de código
7.2.4 Teste de invariantes, pré e pós-condições
7.2.5 Instrumentação de código
7.3 Teste de programas orientados a aspectos
7.3.1 Teste estrutural de unidade
7.3.2 Teste estrutural de integração
7.3.3 JaBUTi/AJ: uma ferramenta de teste estrutural
7.3.4 Teste baseado em estados
7.3.5 Teste de mutação
7.3.6 Proteum/AJ: uma ferramenta de teste de mutação de programas AspectJ
7.3.7 Estratégia de ordenação de classes e aspectos para o teste de integração
7.4 Considerações finais
Referências
8 Teste de Aplicações Web
8.1 Introdução
8.2 Teste estrutural
8.3 Teste baseado em modelos de comportamento
8.4 Teste baseado em defeitos
8.4.1 Teste de mutação
8.4.2 Injeção de erros
8.5 Teste baseado em sessões do usuário
8.6 Considerações finais
Referências
9 Teste de Programas Concorrentes
9.1 Introdução
9.2 Programas concorrentes
9.3 Tipos de erros em programas concorrentes
9.4 Teste estrutural de programas concorrentes
9.4.1 Critérios estruturais de teste
9.4.2 Exemplo de aplicação
9.5 Teste determinístico e não determinístico
9.6 Teste de mutação em programas concorrentes
9.7 Ferramentas
9.7.1 Ferramentas para teste estrutural
9.7.2 Ferramentas para teste de mutação
9.7.3 Ferramentas para teste baseado em modelos
9.7.4 Ferramentas para detecção de deadlock e condições de disputa
9.7.5 Ferramentas para teste determinístico
9.7.6 Ferramentas para execução simbólica
9.8 Considerações finais
Referências
10 Teste em Dispositivos Móveis
10.1 Introdução
 10.2 Engenharia de aplicações móveis
10.3 Teste de software para aplicações móveis
10.3 .1 Tipos de teste para aplicações móveis
10.3.2 Abordagens para execução dos testes
10.3.3 Critérios de teste em lojas de aplicativos
10.4 Tipos de falhas em aplicações móveis
10.5 Testes funcionais/comportamentais em aplicações móveis
10.5.1 Abordagens de teste funcional/comportamental
10.5.2 Ferramentas de teste funcional/comportamental
10.6 Testes estruturais em aplicações móveis
10.6.1 Testes estruturais que auxiliam a cobertura de código
10.6.2 Testes estruturais para detecção de violações de concorrência e exceção
10.7 Testes de usabilidade em aplicações móveis
10.7.1 Modelo de avaliação de usabilidade em aplicações móveis
10.7.2 Abordagens de teste de usabilidade em aplicações móveis
10.8 Validação de requisitos de qualidade de serviços
10.8.1 Testes de desempenho/confiabilidade
10.8.2 Teste de segurança e privacidade
10.9 Testes de compatibilidade e conectividade em aplicações móveis
10.9.1 Teste de mobilidade e conectividade
10.9.2 Teste de interoperabilidade
10.10 Considerações finais
Referências
11 Estudos Teóricos e Experimentais
11.1 Introdução
11.2 Estudos teóricos de critérios de teste
11.3 Estudos experimentais
11.3.1 Técnicas estrutural e baseada em erros
11.3.2 Técnica funcional
11.4 Considerações finais
Referências
12 Geração de Dados de Teste
12.1 Introdução
12.2 Geração aleatória
12.3 Geração com execução simbólica
12.4 Geração com execução dinâmica
12.5 Geração com restrições de defeito
12.6 Geração com algoritmos de busca
12.6.1 Meta-heurísticas
12.6.2 SBST: contexto e diretrizes para a aplicação
12.6.3 Trabalhos com ênfase na estrutura
12.6.4 Trabalhos com ênfase em modelos ou na especificação
12.6.5 Outras abordagens
12.7 Considerações finais
Referências
13 Confiabilidade
 13.1 Introdução
13.2 Fundamentos de confiabilidade de software
13.2.1 Definições
13.2.2 Medição da confiabilidade
13.2.3 Funções de confiabilidade
13.3 Modelos de confiabilidade
13.3.1 Modelagem
13.3.2 Classificação de modelos de confiabilidade
13.4 Principais modelos de confiabilidade
13.4.1 Modelos de implante de defeitos
13.4.2 Modelos baseados no domínio dos dados
13.4.3 Modelos baseados no domínio do tempo
13.4.4 Modelos baseados em cobertura de teste
13.4.5 Limitações dos modelos de confiabilidade
13.5 Cálculo da confiabilidade de software
13.5.1 Procedimento geral
13.5.2 Aplicações de medidas da confiabilidade
13.6 Confiabilidade de software para aplicativos móveis
13.7 Considerações finais
Referências

Índice Remissivo
Capítulo 1
Conceitos Básicos
Márcio Eduardo Delamaro (ICMC/USP)
José Carlos Maldonado (ICMC/USP)
Mario Jino (DCA/FEEC/Unicamp)
1.1 Introdução
Para que possamos tratar de um assunto tão vasto quanto o proposto neste livro, é necessário,
primeiro, estabelecer uma linguagem própria. Como acontece em muitas das áreas da
Computação e das ciências em geral, termos comuns adquirem significados particulares quando
usados tecnicamente.
Este capítulo tem o objetivo de estabelecer o escopo no qual o restante do livro se insere, de
apresentar os principais termos do jargão da área e introduzir conceitos que serão úteis durante a
leitura do texto.
1.2 Validação, verificação e teste de software
Definitivamente, a construção de software não é uma tarefa simples. Pelo contrário, pode se
tornar bastante complexa, dependendo das características e dimensões do sistema a ser criado.
Por isso, está sujeita a diversos tipos de problemas que acabam resultando na obtenção de um
produto diferente daquele que se esperava.
Muitos fatores podem ser identificados como causas de tais problemas, mas a maioria deles
tem uma única origem: erro humano. Como a maioria das atividades de engenharia, a construção
de software depende principalmente da habilidade, da interpretação e da execução das pessoas
que o constroem; por isso, erros acabam surgindo, mesmo com a utilização de métodos e
ferramentas de engenharia de software.
Para que tais erros não perdurem, ou seja, para serem descobertos antes de o software ser
liberado para utilização, existe uma série de atividades, coletivamente chamadas de “Validação,
Verificação e Teste”, ou “VV&T”, com a finalidade de garantir que tanto o modo pelo qual o
software está sendo construído quanto o produto em si estejam em conformidade com o
especificado.
Atividades de VV&T não se restringem ao produto final. Ao contrário, podem e devem ser
conduzidas durante todo o processo de desenvolvimento do software, desde a sua concepção, e
englobam diferentes técnicas.
Em geral, dividem-se as atividades de VV&T em estáticas e dinâmicas. As estáticas são as que
não requerem a execução ou mesmo a existência de um programa ou modelo executável para
serem conduzidas. As dinâmicas são as que se baseiam na execução de um programa ou de um
modelo.
O objeto principal deste livro – o teste de software – é uma atividade dinâmica. Seu intuito é
executar o programa ou modelo utilizando algumas entradas em particular e verificar se seu
comportamento está de acordo com o esperado. Caso a execução apresente resultados não
especificados, dizemos que um erro ou defeito (Seção 1.3) foi identificado. Além disso, os dados
de tal execução podem servir como fonte de informação para a localização e a correção de tais
defeitos.
Outras atividades de VV&T não são tratadas neste livro. São atividades importantes e que
permitem a eliminação de erros desde as fases iniciais do processo de desenvolvimento, o que,
em geral, representa uma economia significativa de recursos. Alguns exemplos de tais atividades
são as revisões técnicas e os walkthroughs.
1.3 Alguns termos do jargão
Nesta seção procuramos identificar alguns termos importantes e que ajudarão o leitor a melhor
compreender os textos dos próximos capítulos.
Na seção anterior dissemos que diversos “problemas” podem emergir durante o
desenvolvimento de software e, em seguida, nos referimos a esses como “erros”. A literatura
tradicional estabelece significados específicos para este e outros termos relacionados como:
falha, defeito, erro, engano. Vamos procurar identificar cada um deles.
Definimos “defeito” (do inglês, fault) como sendo um passo, processo ou definição de dados
incorretos, e “engano” (mistake), como a ação humana que produz um defeito. Assim, esses dois
conceitos são estáticos, pois estão associados a um determinado programa ou modelo e não
dependem de uma execução particular.
O estado de um programa ou, mais precisamente, da execução de um programa em
determinado instante, é dado pelo valor da memória (ou das variáveis do programa) e do
apontador de instruções. A existência de um defeito pode ocasionar um “erro” (error) durante
uma execução do programa, que se caracteriza por um estado inconsistente ou inesperado. Tal
estado pode levar a uma “falha” (failure), ou seja, pode fazer com que o resultado produzido pela
execução seja diferente do resultado esperado.
Note-se que essas definições não são seguidas o tempo todo nem são unanimidade entre os
pesquisadores e engenheiros de software, principalmente em situações informais do dia a dia.
Em particular, utiliza-se “erro” de maneira bastante flexível, muitas vezes significando defeito,
erro ou até falha.
O “domínio” de entrada de um programa P, denotado por D(P ), é o conjunto de todos os
possíveis valores que podem ser utilizados para executar P. Por exemplo, vamos tomar um
programa que recebe como parâmetros de entrada dois números inteiros x e y, com y ≥ 0, e
computa o valor de xy , indicando um erro caso os argumentos estejam fora do intervalo
especificado. O domínio de entrada deste programa é formado por todos os possíveis pares de
números inteiros (x, y). Da mesma forma, pode-se estabelecer o domínio de saída do programa,
que é o conjunto de todos os possíveis resultados produzidos pelo programa. No nosso exemplo,
seria o conjunto de números inteiros e mensagens de erro produzidos pelo programa.
Um “dado de teste” para um programa P é um elemento do domínio de entrada de P. Um “caso
de teste” é um par formado por um dado de teste mais o resultado esperado para a execução do
programa com aquele dado de teste. Por exemplo, no programa que computa xy , teríamos os
seguintes casos de teste: (2, 3), 8 , (4, 3), 64 , (3, −1), “Erro” . Ao conjunto de todos os casos
de teste usados durante determinada atividade de teste costuma-se chamar “conjunto de teste” ou
“conjunto de casos de teste”.
A Figura 1.1 mostra um cenário típico da atividade de teste. Definido um conjunto de casos de
teste T, executa-se o programa em teste com T e verifica-se qual é o resultado obtido. Se o
resultado produzido pela execução de P coincide com o resultado esperado, então nenhum erro
foi identificado. Se, para algum caso de teste, o resultado obtido difere do esperado, então um
defeito foi revelado. Como sugere a Figura 1.1, em geral, fica por conta do testador, baseado na
especificação do programa (S(P )) ou em qualquer forma de documento que defina seu
comportamento, a análise sobre a correção de uma execução. Na verdade, o testador na figura
está desempenhando um papel que costumamos chamar de “oráculo”, isto é, aquele instrumento
que decide se a saída obtida de determinada execução coincide com a saída esperada.

Figura 1.1 – Cenário típico da atividade de teste.

1.4 Fases da atividade de teste
A atividade de teste é complexa. São diversos os fatores que podem colaborar para a ocorrência
de erros. Por exemplo, a utilização de um algoritmo incorreto para computar o valor das
mensalidades a serem pagas para um empréstimo ou a não utilização de uma política de
segurança em alguma funcionalidade do software são dois tipos distintos de engano e, de certa
forma, encontram-se em níveis diferentes de abstração. O primeiro tipo de erro provavelmente
está confinado a uma função ou rotina que implementa de forma incorreta uma dada
funcionalidade. No segundo caso, mesmo que exista uma certa política de segurança
implementada de maneira correta, é preciso verificar se todos os pontos nos quais essa política
deveria ser aplicada fazem-no de maneira correta.
Por isso, a atividade de teste é dividida em fases com objetivos distintos. De forma geral,
podemos estabelecer como fases o teste de unidade, o teste de integração e o teste de sistemas. O
teste de unidade tem como foco as menores unidades de um programa, que podem ser funções,
procedimentos, métodos ou classes. Nesse contexto, espera-se que sejam identificados erros
relacionados a algoritmos incorretos ou mal implementados, estruturas de dados incorretas ou
simples erros de programação. Como cada unidade é testada separadamente, o teste de unidade
pode ser aplicado à medida que ocorre a implementação das unidades e pelo próprio
desenvolvedor, sem a necessidade de dispor-se do sistema totalmente finalizado.
No teste de integração, que deve ser realizado após serem testadas as unidades
individualmente, a ênfase é dada na construção da estrutura do sistema. À medida que as
diversas partes do software são colocadas para trabalhar juntas, é preciso verificar se a interação
entre elas funciona de maneira adequada e não leva a erros. Também nesse caso é necessário um
grande conhecimento das estruturas internas e das interações existentes entre as partes do sistema
e, por isso, o teste de integração tende a ser executado pela própria equipe de desenvolvimento.
Depois que se tem o sistema completo, com todas as suas partes integradas, inicia-se o teste de
sistema. O objetivo é verificar se as funcionalidades especificadas nos documentos de requisitos
estão todas corretamente implementadas. Aspectos de correção, completude e coerência devem
ser explorados, bem como requisitos não funcionais como segurança, performance e robustez.
Muitas organizações adotam a estratégia de designar uma equipe independente para realizar o
teste de sistemas.
Além dessas três fases de teste, destacamos, ainda, o que se costuma chamar de “teste de
regressão”. Esse tipo de teste não se realiza durante o processo “normal” de desenvolvimento,
mas sim durante a manutenção do software. A cada modificação efetuada no sistema, após a sua
liberação, corre-se o risco de que novos defeitos sejam introduzidos. Por esse motivo, é
necessário, após a manutenção, realizar testes que mostrem que as modificações efetuadas estão
corretas, ou seja, que os novos requisitos implementados (se for esse o caso) funcionam como o
esperado e que os requisitos anteriormente testados continuam válidos.
Independentemente da fase de teste, existem algumas etapas bem definidas para a execução da
atividade de teste. São elas: 1) planejamento; 2) projeto de casos de teste; 3) execução; e análise.
1.5 Técnicas e critérios de teste
Podemos notar na Figura 1.1 que, ao se testar um programa P, selecionam-se alguns pontos
específicos do domínio D(P ) para a execução de P. Idealmente, o programa em teste deveria ser
executado com todos os elementos de D(P ) para garantir que não contém defeitos. Em geral, tal
abordagem é infactível por causa da cardinalidade de D(P ). Por exemplo, no programa que
computa xy , o domínio é formado por todos os pares de números inteiros (x, y), o que produz um
conjunto de cardinalidade 2n ∗ 2n, onde n é o número de bits usado para representar um número
inteiro. Em uma arquitetura com 32 bits isso representa 264 = 18446744073709551616. Se cada
caso de teste pudesse ser executado em 1 milissegundo, precisaríamos de 5.849.424 séculos para
executá-los todos.
Assim, é importante procurarmos formas de utilizar apenas um subconjunto reduzido de D(P )
para a execução de P, mas que tenha alta probabilidade de revelar a presença de possíveis
defeitos. A ideia central para isso é a de “subdomínios” de teste. Um subdomínio de D(P ) é um
subconjunto do domínio de entrada que contém dados de teste “semelhantes”. Por exemplo,
podemos argumentar que os casos de teste (2, −1), “Erro” e (2, −2), “Erro” são semelhantes,
pois, qualquer que seja a implementação, intuitivamente espera-se que P se comporte de maneira
semelhante para ambos os casos de teste. Nesse caso, não seria necessário executar o programa
em teste com os dois casos de teste. Generalizando, qualquer caso de teste da forma (x, y),
“Erro” em que x > 0 e y < 0 se comporta do mesmo modo ou, em outras palavras, pertence a um
mesmo subdomínio de D(P ); por isso, basta executar P com apenas um deles.
Caso isso seja feito para todos os subdomínios de D(P ), consegue-se um conjunto de T
bastante reduzido em relação a D(P ) mas que, de certa maneira, representa cada um dos seus
elementos.
Na essência, existem duas formas de se procurar selecionar elementos de cada um dos
subdomínios de teste. A primeira é o que se chama de “teste aleatório”, em que um grande
número de casos de teste é selecionado aleatoriamente, de modo que, probabilisticamente, se
tenha uma boa chance de que todos os subdomínios estejam representados no conjunto de teste
T. A segunda é o “teste de partição” ou, mais corretamente, “teste de subdomínios”, no qual se
procura estabelecer quais são os subdomínios a serem utilizados e, então, selecionam-se os casos
de teste em cada subdomínio. Cada uma dessas abordagens tem suas vantagens e desvantagens.
Neste livro, as técnicas apresentadas se encaixam na segunda estratégia, não sendo abordado o
teste aleatório.
Em relação ao teste de subdomínios, fica a questão de como identificar os subdomínios para,
então, fazer a seleção de casos de teste. O que ocorre, na prática, é que são estabelecidas certas
“regras” para identificar quando dados de teste devem estar no mesmo subdomínio ou não. Em
geral, são definidos “requisitos de teste”, por exemplo, executar determinada estrutura do
programa. Os dados de teste que satisfazem esse requisito pertencem ao mesmo subdomínio.
Dessa forma, dependendo do tipo de regra que se utiliza, são obtidos subdomínios diferentes e,
portanto, conjuntos diferentes de teste. Tais regras são chamadas “critérios de teste”. Podemos
identificar três tipos diferentes de critérios: funcionais, estruturais e baseados em defeitos (ou
erros). O que diferencia cada uma dessas técnicas é o tipo de informação utilizada para
estabelecer os subdomínios. Um conjunto de teste que satisfaz todos os requisitos de um critério
de teste C, ou seja, que tem pelo menos um caso de teste para cada subdomínio determinado por
C, é dito “adequado” a C ou “C-adequado”.
Não vamos, aqui, entrar em detalhes sobre as técnicas de teste, pois estas são discutidas na
primeira parte deste livro.
Another random document with
no related content on Scribd:
Toda a cousa negra é preta,
Papel é de trapos velhos,
Olhos do. são besbelhos,
Bordão de velho é moleta:
O mascarado é careta,
Tabaco é fumo pizado,
Peixe de moquem é assado,
O pirão duro é taipeiro,
Mareta em mar é carneiro,
Rapadura é mel coalhado.

Quem não tem juizo é tolo,

Quem morre fica sem vida,
Perna delgada é comprida,
Reposto de jogo é bôlo:
Negro ladino é creoulo,
Sebo de vacca é gordura,
Figado e bofes forçura,
Manteiga é nata de leite,
É oleo todo o azeite,
E todo o vigario é cura.

Sem a lingua não se falla,

Quem não come morre á fome,
A empinge toda come,
O surrão de couro é mala:
Palalá é... rala,
O tatú tem casca dura,
O salgado faz secura,
Arroz sem casca é pilado,
As sôpas são pão molhado,
O ferrolho é fechadura.
Os bancos servem de assento,
Leicenço tem carnegão,
Homem de villa é villão,
As pennas voam com vento:
O adro da egreja é bento,
A camisa é roupa branca,
Pau que fecha a porta é tranca,
Tem ventas todo o nariz,
Toda a batata é raiz,
A cara feia é carranca.

A farinha do Brazil
Primeiro foi mandioca,
Milho estalado é pipoca,
O gato todo é subtil:
Tres barris e um barril
Enchem todos uma pipa,
Não se faz casa sem ripa,
Ou vara com seu sipó,
Quem não tem ninguem é só,
Todo o bom cavallo esquipa.

Sempre é boa a espada nova,

Mas a velha é saramago,
Homem que gagueja é gago,
Toda a banana é pacova:
Quem morreu vai para a cova,
Olho do .. é mataco:
Agua de flor do sovaco
Deu sempre vida a um morto,
O que tem um olho é torto,
Guariba não é macaco.
Solimão e rozalgar
Matam, porque são veneno,
Grande doutor foi Galeno,
O fazer curso é purgar:
Fallar por solfa é cantar,
Na botica ha trementina,
Criança femea é menina,
.... ..... ..
Mascarado é papa-angú,
Oleo de pinha é resina.

Tabaco pobre é macaya.

Ave sem penna é morcego,
Toda a agua do Mondego
Desemboca pela praia:
Quem é mulher veste saia,
Os homens vestem calções,
Têm os negros seus bordões,
E cinco palmos a vara,
Tantas arrobas de tara
Tem cada um dos caixões.

Aguardente é geribita,
...dura é .....,
A ...... é pismam
E todo o listão é fita:
A colera logo irrita,
Ganhamú é caranguejo,
Não é sancto São Serejo,
Mas no ceu moram os sanctos;
Todas as casas têm cantos,
Do leite se faz o queijo.
Nos trunfos ha basto e sota,
Dará cartas quem foi mão,
A mulher tem seu pampam,
Pelo pé se calça a bota:
Quem não tem voto não vota,
O que deu cartas é pé,
O escrivão porta por fé,
Obra grosseira é do Porto,
Todo o defuncto está morto,
Vaza e mais enche a maré.

Almorreimas é quentura,
As redes têm seus cadilhos,
Zebedeu foi pae de filhos,
Quem morreu, já não tem cura:
........................
.......................
Jogo de trez é a espadilha,
Ao de dous lhe chamam zanga,
Camisa tem sua manga,
Não ha navio sem quilha.

Faz pasteis o pasteleiro,

Toda a virgem é donzella,
No Brazil ha já cannella,
Todo o frade é redoleiro.
Bate no ferro o ferreiro
E o marido na mulher,
Porque um e mais outro quer,
E gostam da tal asneira,
E não ha mister peneira
Quem farinha não tiver
Todas as côres são tintas,
Duro pau é supipira,
Quem é manso não tem ira,
Do zengá se fazem cintas:
Portugal tem ricas quintas,
E cada uma tem seu dono,
O que quer dormir tem somno,
O que dorme está dormindo,
O que veio tem já vindo
E toda a solfa tem tono.

Ha pelo entrudo filhozes,

Não ha carne na quaresma,
É todo o fedelho—lesma,
No poder os reis são crozes:
Quem tem dente come nozes,
O que quebra está quebrando,
Quem come está manducando,
O que corre vai correndo,
O que bebe está bebendo
E quem joga está jogando.

Dico vere veritates,

Crede mihi, vou fallando,
E quanto mais for andando,
Magis dicam asnitates:
No Recife ha mil mascates
Sobreposse mercadores,
Geme quem padece dores,
É o ... todo vento,
Freiras moram no convento,
E quem quer tem seus amores.
As madrinhas são comadres,
Chocolate tem cacau
Passa dez não é pacau,
Clerigos todos são padres:
É cego não ver por grades,
O limão todo é azedo,
O que tem pavor tem medo,
É boa a mulher que ....,
Não é boa a ... mole,
A pedra grande é penedo.

Quem tem boca vai a Roma,

Quem tem sangue faz chouriços,
As abelhas têm cortiços,
A zabelê sua coma:
O ruim assucar é broma,
A canada tem quartilho,
Não tem pé a mão de milho,
Coruja não é canario,
Livro velho é calendario,
O maná não é quintilho.

É o memento lembrança
Das almas do outro mundo,
A panella tem seu fundo,
E quem herdou teve herança:
É zombar estar de chança,
Muitos filhos tem Antonio
Nunes, do seu matrimonio,
Que dos outros não sabemos;
Aposto que já entendemos
Em que é purga o antimonio.
Os sapatos levam sola,
A carne de boi é vacca,
A ... em criança é caca,
É redonda toda a bola:
Passarinho na gaiola
Está prezo na cadeia,
O gatinho bravo meia,
São frades os franciscanos,
O homem velho já tem annos,
A formosa não é feia.

Quem vai só—vai solitario,

Quem tem fome excusa môlho,
O ... tem no meio ôlho,
Tem a mulher ordinario:
Chama-se a pessa Calvario;
Cidades tem Portugal,
Ouro é o que ouro val,
Pratos de côr tem rabique,
Não se faz renda sem pique,
Todo o salgado tem sal.

Peccados mortaes são septe,

E dez são os mandamentos,
Septe são os Sacramentos,
O estojo tem canivete:
Os frades com seu topete
Não pagam luguel de cazas,
Os anjinhos levam azas,
Cães de fila todos mordem,
Sacramento sexto é ordem,
Ganhou o que fez mais vazas.
Estas pois e outras verdades,
Amigo, que aqui vos digo,
São as de que sou amigo;
.........................
O mais são só asnidades
D’esses que dizem rodeios,
Porque só por estes meios
Se falla bem portuguez;
Tudo o mais é ser francez,
E trazer na boca freios.
 JUSTIÇA
QUE FAZ O P. NA HONRA HYPOCRITA PELOS ESTRAGOS QUE
ANDA FAZENDO NA VERDADEIRA HONRA

Uma cidade tão nobre[2],

Uma gente tão honrada,
Veja-se um dia louvada
Desde o mais rico ao mais pobre:
Cada pessoa o seu cobre;
Mas si o diabo me atiça,
Que indo a fazer-lhes justiça,
Algum saia a justiçar,
Não me poderão negar
Que por direito e por lei
Esta é a justiça que manda El-Rei.

[2] Lisboa.

O fidalgo de solar
Se dá por envergonhado
De um tostão pedir prestado
Para o ventre sustentar:
Diz que antes o quer furtar,
Por manter a negra honra,
Que passar pela deshonra
De que lh’o neguem talvez:
Mas si o vires nas galés
Com honras de vice-rei,
Esta é a justiça que manda El-Rei.
 A donzella embiocada,
Mal trajada, peior comida,
Antes quer na sua vida
Ter saia que ser honrada:
É publica amancebada
Por manter a negra honrinha,
E si lh’o chama a visinha,
E lh’o ouve a clerizia,
Dão com ella na enxovia,
E paga a pena da lei:
Esta é a justiça que manda El-Rei.

A casada com adorno,

E o marido mal vestido,
Crêde que este tal marido
Pentêa monho de ...
Si disser pelo contorno
Que si soffre a frei Thomaz,
Por manter a honrinha o faz;
Esperae pela pancada,
Que com carocha pintada
De Angola ha de ser vis-rei:
Esta é a justiça que manda El-Rei.

Os lettrados peralvilhos,
Citando o mesmo doutor
A favor do réu e auctor,
Comem de ambos os carrilhos:
Si se diz pelos corrilhos
Sua prevaricação,
A desculpa que vos dão
É a honra de seus parentes;
E entonces os requerentes
Fogem d’esta infame grei:
Esta é a justiça que manda El-Rei.
 O clerigo julgador,
Que’as causas julga sem pejo,
Não reparando que eu vejo
Que erra a lei e erra o doutor:
Quando vem do monsenhor
A sentença revogada,
Por saber que foi comprada
Pelo gimbo ou pelo abraço,
Responde o padre madraço:
Minha honra é minha lei;
Esta é a justiça que manda El-Rei.

O mercador avarento
Quando a sua conta extende,
No que compra e no que vende
Tira duzentos por cento:
Não é elle tão jumento
Que não saiba que em Lisboa
Se lhe ha de dar na gamboa;
Mas comido já o dinheiro,
Diz que a honra está primeiro,
E que honrado a toda a lei.
Esta é a justiça que manda El-Rei.

A viuva auctorisada,
Que não possue vintem,
Porque o marido de bem
Deixou a casa empenhada:
Alli entra a fradalhada,
Qual formiga em correição,
Dizendo que á casa vão
Manter a honra da casa;
Si a vires arder em brasa,
Que ardeu a honra entendei.
Esta é a justiça que manda El-Rei.
 O Adonis da manhãa,
O Cupido em todo o dia,
Que anda correndo a coxia
Com recadinhos á irmãa,
E si lhe cortam a lãa
Diz que anda naquelle andar
Pela honra conservar
Bem tractado e bem vestido;
Eu o verei tão despido,
Que até as costas lhe verei.
Esta é a justiça que manda El-Rei.

Si vires um dom abbade

Sôbre o pulpito cioso,
Não lhe chameis religioso,
Chamae-lhe embora de frade:
E si o tal Paternidade
Rouba as rendas do convento,
Para acudir ao sustento
Da ..., como da peita
Com que livra de suspeita
Do Geral, do Vice-Rei,
Esta é a justiça que manda El-Rei.
 DIALOGO
ENTRE O DEMONIO E A ALMA

Cantavam naquelle tempo os chulos da Bahia certas

cantigas por uma toada triste que rematava, dizendo:
«Banguê, que será de ti?» Mas outros mais piedosos
reduziam a mesma canção ao Divino finalizando assim: «Meu
Deus, que será de mim?» E o P. entre o temporal e o eterno
de uma o outra chularia introduziu uma alma christãa
resistindo ás tentações do demonio com a glosa de ambos os
extremos:

Meu Deus, que será de mim?

Banguê, que será de ti?

Alma—Si o descuido do futuro

E a lembrança do presente
É em mim tão continente,
Como do mundo murmuro?
Será porque não procuro
Temer do principio o fim?
Será porque sigo assim
Cegamente o meu peccado?
Mas si me vir condemnado,
Meu Deus, que será de mim?
Dem.—Si não segues meus enganos
E meus deleites não segues,
Temo que nunca socegues
No florido de teus annos:
Vê como vivem ufanos
Os descuidados de si:
Canta, baila, folga e ri;
Porque os que não se alegraram,
Dous infernos militaram:
Banguê, que será de ti?

Alma—Si para o céu me creastes,

Meu Deus, á imagem vossa,
Como é possivel que possa
Fugir-vos, pois me buscastes?
E si para mim tractastes
O melhor remedio e fim;
Eu, como ingrato Caim,
D’este bem tão esquecido,
Tendo-vos tão offendido,
Meu Deus, que será de mim?

Dem.—Todo o cantar allivia

E todo o folgar alegra,
Toda a branca, parda e negra
Tem sua hora de folia:
Só tu na melancolia
Tens allivio? Canta aqui
E torna a cantar alli,
Que d’esse modo o practicam
Os que alegres prognosticam
Banguê, que será de ti?
Alma—Eu para vós—offensor,
Vós para mim—derretido?
Eu—de vós tão esquecido,
E vós de mim—Redemptor?
Ai como sinto, Senhor,
De tão mau principio o fim,
Si me não valeis assim,
Como áquelle que na cruz
Feristes com vossa luz?
Meu Deus, que será de mim?

Dem.—Como assim na flor dos annos

Colhes o fructo amargoso?
Não vês que todo o penoso
É causa de muitos damnos?
Deixa, deixa desenganos,
Segue os deleites, que aqui
Te offereço, porque alli
Os mais que cantando vão,
Dizem na triste canção:
Banguê, que será de ti?

Alma—Quem vos offendeu, Senhor?

Uma creatura vossa?
Como é possivel que eu possa
Offender meu Creador?
Triste de mim peccador,
Si a gloria que daes sem fim,
Perdida num Serafim
Se perder em mim tambem?
Si eu perder tamanho bem,
Meu Deus, que será de mim?
Dem.—Si a tua culpa merece
Do teu Deus toda a esquivança,
Folga no mundo e descança
Que o arrepender aborrece:
Si o peccado te entristece,
Como já em outros vi,
Te prometto desde aqui
Que os mais da tua facção
E tu no inferno dirão:
Banguê, que será de ti?
 CONTRA
OS INGRATOS MURMURADORES DO BEM QUE
ACTUALMENTE RECEBEM DA MÃE UNIVERSAL, QUE OS
AFFAGA, SE QUEIXA A BAHIA, CONFESSANDO-SE DAS
CULPAS, QUE LHE DÃO, PELOS PRECEITOS DO DECALOGO

ROMANCE

Já que me põem a tormento

Murmuradores noviços,
Carregando sobre mim
Suas culpas e delictos;
Por credito do meu nome,
E não por temer castigo,
Confessar quero os peccados
Que faço, e que patrocino.
E si alguem tiver a mal
Descobrir este sigillo,
Não me infame que eu serei
Pedra em poço, ou seixo em rio.
Sabei, céu, sabei estrellas,
Escutae, flores e lirios,
Montes, serras, peixes, aves,
Lua, sol, mortos e vivos,
Que não ha nem póde haver,
Desde o Sul ao Norte frio,
Cidade com mais maldades,
Nem provincia com mais vicios,
Do que sou eu, porque em mim
Recopilados e unidos
Estão junctos quantos têm
Mundos e reinos distinctos.
Tenho Turcos, tenho Persas,
 Homens de nação impios,
Mogores, Armenios, Gregos,
Infieis e outros gentios.
Tenho ousados Mermidonios,
Tenho Judeus, tenho Assyrios,
E de quantas seitas ha
Muito tenho, e muito abrigo.
E sinão digam aquelles
Presados de vingativos,
Que sanctidade têm mais
Que um Turco e que um Mohabito!
Digam idolatras falsos,
Que estou vendo de continuo
Adorarem ao dinheiro,
Gula, ambição e amoricos!
Quantos com capa christãa
Professam o judaismo,
Mostrando hypocritamente
Devoção á Lei de Christo!
Quantos com pelle de ovelha
São lobos enfurecidos,
Ladrões, falsos, aleivosos,
Embusteiros e assassinos!
Estes por seu mau viver,
Sempre pessimo e nocivo,
São os que me accusam damnos,
E põem labéos inauditos.
Mas o que mais me atormenta
É ver que os contemplativos,
Sabendo a minha innocencia,
Dão a seu mentir ouvidos.
Até os mesmos culpados
Têm tomado por capricho,
Para mais me difamarem
Pôrem pela praça escriptos,
Onde escrevem sem vergonha,
Não só brancos, mas mestiços,
 Que para os bons sou inferno,
E para os mais paraizo.
Oh velhacos insolentes,
Ingratos, mal procedidos!
Si eu sou essa que dizeis,
Porque não largais meu sitio?
Porque habitais em tal terra,
Podendo em melhor abrigo?
Eu pego em vós? eu vos rogo?
Respondei: dizei, maldictos?
Mandei acaso chamar-vos,
Ou por carta, ou por aviso?
Não viestes para aqui
Por vosso livre alvedrio?
A todos não dei entrada,
Tractando-vos como a filhos?
Que razão tendes agora
De difamar-me atrevidos?
Meus males de quem procedem?
Não é de vós? claro é isso:
Que eu não faço mal a nada
Por ser terra e matto arisco.
Si me lançais má semente
Como quereis fructo limpo?
Lançae-a boa, e vereis
Si vos dou cachos optimos.
Eu me lembro que algum tempo,
Isto foi no meu principio,
A semente que me davam
Era boa e de bom trigo.
Por cuja causa meus campos
Produziam pomos lindos,
De que ainda se conservam
Alguns remotos indicios.
Mas depois que vós viestes
Carregados, como ouriços,
De sementes invejosas
 E legumes de maus vicios;
Logo declinei comvosco,
E tal volta tenho tido,
Que o que produzia rozas
Hoje só produz espinhos.
Mas para que se conheça
Si fallo verdade ou minto,
E quanto os vossos enganos
Têm difamado meu brio:
Confessar quero de plano
O que encubro por servir-vos,
E saiba quem me moteja
Os premios que ganho nisso.
Já que fui tão pouco attenta,
Que a luz da razão e o sizo
Não só quiz cegar por gosto,
Mas ser do mundo ludibrio.
Vós me ensinastes a ser
Das inconstancias archivo,
Pois nem as pedras que gero
Guardam fé aos edificios.
Por vosso respeito dei
Campo franco e grande auxilio
Para que se quebrantassem
Os mandamentos divinos.
Cada um por suas obras
Verá contra quem me explico,
Sem andar excogitando
Para quem se aponta o tiro.

PRECEITO I

Que de quilombos que tenho.

Com mestres superlativos,
Nos quaes se ensina de noite
Os calundús e feitiços!