Skip to content

Commit

Permalink
adicionando correções do capítulo 4 e alterando rodapé e redes sociais
Browse files Browse the repository at this point in the history
  • Loading branch information
feroline committed Sep 18, 2024
1 parent 320e417 commit ae01f1e
Show file tree
Hide file tree
Showing 16 changed files with 59 additions and 42 deletions.
7 changes: 7 additions & 0 deletions _includes/contatos.html
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
<div class="contatos ">
{% for contato in site.data.contatos reversed %}
<a href="{{contato.link}}" class="text-decoration-none text-muted contatos-item">
{% include {{ contato.svgPath }} %}
</a>
{% endfor %}
</div>
15 changes: 1 addition & 14 deletions _includes/rodape.html
Original file line number Diff line number Diff line change
@@ -1,19 +1,6 @@
<!-- TODO: diminuir o tamanho do rodapé fixo, deixando visivel apenas as redes -->

<nav class="navbar fixed-bottom bg-body-tertiary" id="rodape">
<nav class="navbar bg-body-tertiary">
<div class="container justify-content-center">
<footer>
<ul class="nav justify-content-center border-bottom mb-3">
{% for contato in site.data.contatos reversed %}

<li class="nav-item">
<a href="{{contato.link}}" class="nav-link px-2 text-muted">
{% include {{ contato.svgPath }} %}
</a>
</li>

{% endfor %}
</ul>
<p class="text-center text-muted">© 2024 QA Bentevi por Ana Rocha. Todos os direitos reservados </p>
</footer>
</div>
Expand Down
5 changes: 3 additions & 2 deletions _layouts/default.html
Original file line number Diff line number Diff line change
Expand Up @@ -23,6 +23,7 @@
</head>

<body>
{% include contatos.html %}
<div class="conteudo">
{% include navbar.html %}

Expand All @@ -31,9 +32,9 @@
{{content}}
</div>
</main>

{% include rodape.html %}
</div>
{% include rodape.html %}


<script src="{{'/assets/js/bootstrap.bundle.min.js' | relative_url }}"></script>
<script src="{{'/assets/js/custom.js' | relative_url}}"></script>
Expand Down
24 changes: 22 additions & 2 deletions assets/css/custom.css
Original file line number Diff line number Diff line change
@@ -1,16 +1,36 @@
:root {
--rodape-height: 6em;
--yellow: #fdd501;
}

#navbar-top {
transition: top 0.3s;
}

#rodape {
#rodape-redes {
height: fit-content;
margin: var(--rodape-height) 0.5em 0.5em 0.5em;
}

.conteudo {
margin-bottom: calc(var(--rodape-height) + 2em);
margin-bottom: 3%;
}

.contatos {
z-index: 1;
display: flex;
flex-direction: column;
position: fixed;
right: 3%;
top: 10em;
}

.contatos-item {
z-index: 0;
background-color: var(--yellow);
margin-bottom: 15%;
border-radius: 50%;
width: 35px;
height: 35px;
text-align: center;
}
2 changes: 1 addition & 1 deletion collections/_ctfl_resumo/capitulo-4/indice-4-1.md
Original file line number Diff line number Diff line change
Expand Up @@ -30,7 +30,7 @@ title: Visão Geral das Técnicas de Teste
<div>
<span><b>Técnicas de Teste Baseada na Experiência:</b></span>
<ul>
<li>Baseadas no conhecimento e experiência do Testador, dependendo de suas habilidades.</li>
<li>Baseada no conhecimento e experiência do testador, dependendo de suas habilidades.</li>
<li>São complementares as técnicas caixa-branca e caixa-preta, visto que podem detectar defeitos que poderiam passar despercebidos por estas.</li>
</ul>
</div>
8 changes: 4 additions & 4 deletions collections/_ctfl_resumo/capitulo-4/indice-4-2-2.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,12 +13,12 @@ title: Análise de Valor Limite (BVA)
<p>
<span><b>BVA de 2 valores:</b></span>
<ul>
<li>Para cada valor limite há dois itens de cobertura, o valor limite e seu vizinho mais próximo pertencente a partição Adjacente (vizinha).</li>
<li>Para cada valor limite há dois itens de cobertura, sendo o valor limite e seu vizinho mais próximo pertencente a partição seguinte (vizinha).</li>
<li>Para atingir 100% de cobertura todos os valores limites identificados devem ser executados.</li>
</ul>
</p>

<p>A cobertura é medida da seguinte forma e expressa em porcentagem, representada pela letra 'C': Número de Valores limites executados, dividido pelo número total de valor limite identificado, resultado representado pela letra 'Y'. </p>
<p>A cobertura é medida da seguinte forma e expressa em porcentagem (C): Número de Valores limites executados, dividido pelo número total de valor limite identificado (Y). </p>

<p>
<div class="d-flex flex-lg-row flex-md-row flex-sm-column justify-content-center">
Expand Down Expand Up @@ -57,12 +57,12 @@ title: Análise de Valor Limite (BVA)
<p>
<span><b>BVA de 3 valores:</b></span>
<ul>
<li>Para cada valor limite há três itens de cobertura, o valor limite e seus dois vizinhos.</li>
<li>Para cada valor limite há três itens de cobertura, sendo o valor limite, seu vizinho da partição seguinte e seu vizinho da mesma partição.</li>
<li>Para atingir 100% de cobertura todos os valores limites e seus vizinhos devem ser executados.</li>
</ul>
</p>

<p>A cobertura é medida da seguinte forma e expressa em porcentagem, representada pela letra 'C': Número de Valores limites executados mais seus vizinhos, dividido pelo número total de valor limite identificado mais seus vizinhos, resultado representado pela letra 'Y'. </p>
<p>A cobertura é medida da seguinte forma e expressa em porcentagem (C): Número de Valores limites executados mais seus vizinhos, dividido pelo número total de valor limite identificado mais seus vizinhos (Y) </p>

<p>
<div class="row justify-content-center">
Expand Down
2 changes: 1 addition & 1 deletion collections/_ctfl_resumo/capitulo-4/indice-4-2-3.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ title: Tabela de Decisão
---

<p>
É uma forma eficaz de registrar regras complexas como as Regras de Negócios. Nesta tabela são definidas condições e ações resultantes do sistema. Uma tabela completa cobre todas as combinações de condições, mas pode ser simplificada excluindo, fundindo condições inviáveis ou que não afetam o resultado.
É uma forma eficaz de registrar regras complexas como as Regras de Negócios. Nesta tabela são definidas condições e ações resultantes do sistema. Uma tabela completa cobre todas as combinações de condições, mas pode ser simplificada excluindo ou fundindo condições inviáveis ou que não afetam o resultado.
</p>

<table class="table table-sm table-bordered">
Expand Down
12 changes: 6 additions & 6 deletions collections/_ctfl_resumo/capitulo-4/indice-4-2-4.md
Original file line number Diff line number Diff line change
Expand Up @@ -54,13 +54,13 @@ title: Teste de Transição de Estado
<tbody>
<tr class="flex-row">
<th scope="row">Estado 1</th>
<td>Resultado 1.1</td>
<td>Resultado 1.2</td>
<td>Transição 1.1</td>
<td>Transição 1.2</td>
</tr>
<tr>
<th scope="row">Estado 2</th>
<td>Resultado 2.1</td>
<td>Resultado 2.2</td>
<td>Transição 2.1</td>
<td>Transição 2.2</td>
</tr>
</tbody>
</table>
Expand Down Expand Up @@ -191,7 +191,7 @@ title: Teste de Transição de Estado
</li>
<li>
<span>
<b>Cobertura de todas as transições:</b> Os itens de cobertura são todas as transições (válidas e inválidas), mostradas em uma tabela de estado. Para garantir 100% da cobertura, todas as transições devem ser executadas.A fórmula é:
<b>Cobertura de todas as transições:</b> Os itens de cobertura são todas as transições (válidas e inválidas), mostradas em uma tabela de estado. Para garantir 100% da cobertura, todas as transições devem ser executadas. A fórmula é:
</span>
<br>
<br>
Expand Down Expand Up @@ -231,6 +231,6 @@ title: Teste de Transição de Estado

<br>
<span>
A cobertura mais abrangente é a cobertura de todos as transições, logo em seguida a de transições válidas, após ela a de todos os estados. Isso se deve ao fato de que alguns estados podem ser alcançados sem necessariamente executar todas as transições, e ao executar todas as transições, tanto válidas quanto as inválidas, posso evitar o mascaramento de falhas.
A cobertura mais abrangente é a cobertura de todos as transições, logo em seguida a de transições válidas, após ela a de todos os estados. Isso se deve ao fato de que alguns estados podem ser alcançados sem necessariamente executar todas as transições, e ao executar todas as transições, tanto válidas quanto as inválidas, posso evitar o mascaramento de falhas e visitar todos os estados.
</span>
</p>
4 changes: 2 additions & 2 deletions collections/_ctfl_resumo/capitulo-4/indice-4-3-1.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,11 +8,11 @@ title: Teste de Instrução e Cobertura de Instrução

<p>
O objetivo é criar casos de teste que executem as instruções do código até um nível aceitável de cobertura.
Uma instrução isolada em um caso de teste pode não detectar alguns defeitos associados que dependam de dados específicos, por exemplo, um defeito somente é detectado com o valor de entrada '1', mas o caso de teste referente a essa instrução tem como valor de entrada 2.
Uma instrução isolada em um caso de teste pode não detectar alguns defeitos associados que dependam de dados específicos, por exemplo um defeito que somente é detectado com o valor de entrada '1', mas o caso de teste referente a essa instrução tem como valor de entrada '2'.
</p>

<p>
100% de cobertura de Instrução significa que todas as intruções do código foram executadas ao menos uma vez, mas não garante que toda a lógica de decisão tenha sido testada.
100% de cobertura de Instrução significa que todas as intruções do código foram executadas ao menos uma vez, mas não garante que toda a lógica de decisão tenha sido testada. Exemplo: Uma instrução (função) tem uma condição (decisão) representada por um 'if' e um 'else', ao executar essa instrução pode ser que o 'if' seja executado, entretanto o 'else' não, sendo assim nem toda decisão dentro da instrução será coberta.
</p>

<p>
Expand Down
8 changes: 5 additions & 3 deletions collections/_ctfl_resumo/capitulo-4/indice-4-3-2.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,14 +7,16 @@ title: Teste de Ramificação e Cobertura de Ramificação
---

<p>
<b>Ramificação:</b> É a transferência de controle entre dois nós no gráfico de fluxo de controle, ou seja, mostra as possíveis sequências nos quais as instruções do código-fonte são executadas. Cada transferência pode ser incondicional ou condicional.
<b>Ramificação:</b> É a transferência de controle entre dois nós no gráfico de fluxo de controle, ou seja, mostra as possíveis sequências nos quais as instruções do código-fonte são executadas. Cada transferência pode ser incondicional ou condicional, podendo representar uma lógica de decisão.
</p>

<p>Uma ramificação executada pode não detectar defeitos em casos que exijam a execução de caminho especifico no código.</p>
<p>
Uma ramificação executada pode não detectar defeitos em casos que exijam a execução de um caminho especifico no código.
</p>

<p>
100% de cobertura de Ramificação é igual a 100% de cobertura de instrução, mas não o contrário.
Os itens de cobertura são ramificações, e o objetivo é criar casos de teste para executar todas até um nível aceitável de cobertura. A cobertura é medida da seguinte forma, onde o número total de ramificações executadas pelos casos de teste é dividido pelo número total de ramificações, sendo expressa em porcentagem.
Os itens de cobertura são ramificações, e o objetivo é criar casos de teste para executar todas até um nível aceitável de cobertura. A cobertura é medida da seguinte forma, onde o número total de ramificações executadas pelos casos de teste é dividido pelo número total de ramificações existentes, sendo expressa em porcentagem.
</p>

<p>
Expand Down
4 changes: 2 additions & 2 deletions collections/_ctfl_resumo/capitulo-4/indice-4-4-2.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ title: Testes Exploratórios
<li>Um período de tempo definido</li>
<li>Uma carta de teste que contém os objetivos do teste</li>
<li>Uma reunião depois da sessão onde é discutido os resultados do teste</li>
<li>Os itens de cobertuiria são identificados durante a sessão de teste</li>
<li>Os itens de cobertura são identificados durante a sessão de teste</li>
</ul>

<p>São muito úteis quando há pouca especificação ou quando ela é inadequada, ou quando há uma significativa pressão de tempo. Complementa técnicas mais formais, como a de particionamento de equivalência. É mais eficaz com um testador experiênte, com domínio e habilidades anlíticas, curiosidade e criatividade.</p>
<p>São muito úteis quando há pouca especificação ou quando ela é inadequada, ou quando há uma significativa pressão de tempo. Complementa técnicas mais formais, como a de particionamento de equivalência. É mais eficaz com um testador experiente, com domínio e habilidades analíticas, curiosidade e criatividade.</p>
4 changes: 2 additions & 2 deletions collections/_ctfl_resumo/capitulo-4/indice-4-4-3.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,8 +8,8 @@ title: Testes Baseado em Lista de Verificação (Checklist)

<p> O testador modela, executa e implementa os testes baseado em uma lista de verificação, também chamado de Checklist. Essa lista pode ser baseada na experiência do testador, no conhecimento do que é importante para o usuário ou em como o software costuma falhar.</p>

<p>Geralmente é feita em forma de perguntas, deve verificar cada item separadamente e podem ser criadas para dar suporte a vários tipos de teste, incluindo funcionais e não funcionais, como por exemplo de teste não funcional as 10 heurísticas para teste de usabilidade de Nielsen. </p>
<p>Geralmente é feita em forma de perguntas, deve verificar cada item separadamente e podem ser criadas para dar suporte a vários tipos de teste, incluindo funcionais e não funcionais, como exemplo de teste não funcional temos as 10 heurísticas para teste de usabilidade de Nielsen. </p>

<p>Não deve conter itens que possam ser: Avaliados automaticamente, itens com critérios de entrada/saída ou itens muito gerais.</p>

<p>É necessário atualizar a lista constantemente, pois os mesmos erros podem não ser mais cometidos. Na ausencia de casos de teste detalhados é uma boa prática, aumentando a cobertura e tendo menos repetibilidade.</p>
<p>É necessário atualizar a lista constantemente, pois os mesmos erros podem não ser mais cometidos. Na ausência de casos de teste detalhados é uma boa prática, aumentando a cobertura e tendo menos repetibilidade.</p>
2 changes: 1 addition & 1 deletion collections/_ctfl_resumo/capitulo-4/indice-4-5-1.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@ title: Escrita colaborativa de histórias de Usuário
</p>

<p>
O formato mais comum é:
O formato mais comum de escrita é:
<br>
<b>Como</b> [ator ou persona] <b>eu quero</b> [meta a ser cumprida] <b>para que eu possa</b> [valor de negócio resultante da função]
</p>
Expand Down
2 changes: 1 addition & 1 deletion collections/_ctfl_resumo/capitulo-4/indice-4-5-3.md
Original file line number Diff line number Diff line change
Expand Up @@ -35,7 +35,7 @@ title: Desenvolvimento Orientado por Teste de Aceite (ATDD)
</p>

<ul>
<li>A linguagem utilizada normalmente é natural, para compreesão dos stakeholders.</li>
<li>A linguagem utilizada normalmente é natural, para melhor compreensão dos stakeholders.</li>
<li>Abrange todas as características das histórias de usuários, não indo além delas, mas podendo expor seus problemas.</li>
<li>Dois casos de teste não devem descrever as mesmas características.</li>
<li>Na automação os desenvolvedores escrevem o código de suporte a medida que implementam o recurso, tornando os testes requisitos executáveis.</li>
Expand Down
2 changes: 1 addition & 1 deletion collections/_ctfl_resumo/capitulo-4/indice-4-5.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,5 +11,5 @@ title: Abordagens de Teste Baseadas na Colaboração
<ul>
<li><b>Escrita colaborativa de histórias de usuário</b></li>
<li><b>Critérios de Aceite</b></li>
<li><b>Desenvolvimento Orientado opr Teste de Aceite</b></li>
<li><b>Desenvolvimento Orientado por Teste de Aceite</b></li>
</ul>

0 comments on commit ae01f1e

Please sign in to comment.