O teste parte fundamental no ciclo de vida de um software.

Abaixo esto listados 7

princpios fundamentais que envolvem o processo de teste e devem servir como um guia
geral, tanto para testadores quanto para desenvolvedores. Afinal, ambos participam
efetivamente do processo de amadurecimento do sistema.
1 Prncipio: Testes apontam a presena de falhas
Testes conseguem identificar a existncia de falhas, mas no pode garantir a ausncia
delas. Mesmo se nenhum erro for identificado em uma bateria de testes, no possvel
afirmar que o software est livre de falhas.
2 Princpio: Teste exaustivo impossvel
A menos que a aplicao sendo testada tenha uma estrutura lgica muito simples e
valores de entrada limitados, teste exaustivo invivel pois seria extremamente custoso
cobrir todos os cenrios possveis. Deve-se calcular o esforo dos testes baseando-se
nos riscos e prioridades.
3 Princpio: Teste antecipado
Ao desenvolver um software, as atividades de teste devem comear o quanto antes.
Assim que os requisitos ou modelagem do sistema estiverem prontos, possvel
comear o trabalho de modelagem do plano de testes. O quanto antes uma falha for
identificada no ciclo de vida de um sistema, mais barata e mais simples ser a correo.
4 Princpio: Agrupamento de falhas
A maioria das falhas encontradas durante a execuo dos testes est concentrada em um
nmero pequeno de mdulos. Sempre existe uma rea do software que responsvel
pelo maior nmero de erros.
5 Princpio: Paradoxo do pesticida
Um conjunto de testes, se executado vrias vezes, pode no mais detectar novas falhas.
Para contornar esse problema, os casos de teste devem ser frequentemente revisados e
atualizados. Eles devem ser reformulados para abordar novas reas do sistema e assim
aumentar a chance de detectar novas falhas.
6 Princpio: Teste depende de contexto
Os testes devem ser elaborados de acordo com o tipo do software. Por exemplo, um
sistema bancrio deve ser testado de maneira diferente de uma rede social. H questes
de segurana que devem ser mais precisamente abordadas no primeiro caso. Da mesma
forma que testes web so elaborados com foco diferente dos testes de aplicaes
desktop.
7 Princpio: Ausncia de erros uma iluso

Identificar e corrigir os problemas de um software no garantem que ele est pronto. Os

testes foram elaborados para identificar todas as possveis falhas? O sistema atende s
necessidades e expectativas dos usurios? Ou seja, existem outros fatores que devem ser
considerados para garantir a qualidade do sistema.
Fonte:http://crowdtest.me/7-principios-fundamentais-teste-software/
1 dimenso - Estgios ou nveis de teste(quando testar)
Teste de Unidade - estgio mais baixo da escala de teste. Costuma ser feito pelos
programadores.
Teste de integrao - Teste do sistema ao trmino de cada iterao. Geralmente
realizado pelo analista de sistema.
Teste de Sistema - Execuo do sistema como um todo. Costuma ser realizado pelo
analista de teste em ambiente de teste.
Teste de aceitao - Testes antes da implantao do software. Em geral feito pelo
usurio em ambiente de homologao.

2 dimenso - Tipos de teste(o que testar)

De acordo com a metodologia de qualidade FURPS:
Funcionalidade: Teste funcional, Teste de regresso, Teste de volume, Teste de
segurana.
Usabilidade: Teste de interface, Teste de usabilidade.
Confiabilidade: Teste de integridade, Teste de estrutura, Teste de estresse, Smoke
test.
Desempenho: Teste de avaliao de desempenho ou benchmark, Teste de conteno,
Teste de carga, Perfil de desempenho.
Suportabilidade: Teste de configurao, Teste de instalao.
3 dimenso - Tcnicas de teste(como testar)
Estrutural - Verificar se o sistema desenvolvido e os programas funcionam. ...Pretende
determinar se a tecnologia utilizada foi apropriada e se, quando montados, os
componentes funcionam como uma unidade coesa.
Funcional - Assegurar que as especificaes e os requisitos do software foram
atendidos.
-----------------------------------------------Ento de acordo com a questo

a) Teste de Aceitao (NVEL DE TESTE) Teste de Regresso (TIPO DE TESTE)

Teste Estrutural(TCNICA DE TESTE)
b) Teste de Funcionalidade(TIPO DE TESTE) Teste de Desempenho (TIPO DE
TESTE) Teste de Unidade(NVEL DE TESTE)
c) Teste de Interface(TIPO DE TESTE) Teste de Carga(TIPO DE TESTE)
Teste de Segurana(TIPO DE TESTE)
d) Teste Funcional(TCNICA DE TESTE) Teste de Volume (TIPO DE TESTE)
Teste de Sistema (NVEL DE TESTE)
e) Teste de Usabilidade (TIPO DE TESTE) Teste de Funcionalidade(TIPO DE
TESTE) Teste de Integrao (NVEL DE TESTE)

No contexto das redes de computadores e telecomunicaes, o Multi

Protocol Label Switching (MPLS) um mecanismo de transporte de
dados pertencente famlia das redes de comutao de pacotes. O MPLS
padronizado pelo IETF - Internet Engineering Task Force atravs da RFC3031 e opera numa camada OSI intermediria s definies tradicionais do
Layer 2 (Enlace) e Layer 3 (Rede), pelo que se tornou recorrente ser referido
como um protocolo de "Layer 2,5".
O label um identificador curto, de tamanho fixo e significado local. Todo
pacote ao entrar numa rede MPLS recebe um label. Este pode ser pensado
como uma forma abreviada para o cabealho do pacote. Desta forma os
roteadores s analisam os labels para poder encaminhar o pacote. O
cabealho MPLS deve ser posicionado depois de qualquer cabealho da
camada 2 e antes do cabealho da camada 3, ele conhecido como Shim
Header e est apresentado na figura desta pgina.

Uma assinatura digital garante as seguintes propriedades:

Autenticidade: o receptor deve poder confirmar que a assinatura foi feita pelo receptor;
Integridade: qualquer alterao da mensagem faz com que a assinatura no
corresponda ao documento;
No repudio ou irretratabilidade: o emissor no pode negar a autenticidade da
mensagem.Ou seja, o sigilo da mensagem.
Pseudo-cabealho so para algumas coisas, mas dentre elas no tem
checksum. Tem duas extenses para segurana que so: Authentication
Header e Encapsulating Security Payload.
Na extenso hop-by-hop h controle de fluxo atravs do tipo Jumborgram.
Mas importante ver que o protocolo que faz esse controle de fluxo no
Jumborgram o RSVP e no o UDP.

Mtricas e Estimativas de Software

A medio de software se dedica a derivar um valor numrico para algum atributo
de um produto ou processo de software. Comparando-se esses valores uns com os
outros e aos padres que se aplicam em sua organizao, voc pode ser capaz de
tirar concluses. Sobre a qualidade de software ou os processos de software
[Sommerville]. Ou seja, uma mtrica de software uma medio que se refere a um
software, processo ou documentao.
Existem vrias classificaes para as mtricas de software. Algumas delas esto
listadas a seguir.

Internas ou Externas

Mtricas Internas ou Estticas: medies de um produto de software a partir

de suas prprias caractersticas internas sem a necessidade de execuo dos
programas. Por exemplo, linhas de cdigo, nmeros de erros encontrados em
revises, dados coletados na documentao, etc.

Mtricas Externas ou Dinmicas: so medies de um produto de software a

partir do comportamento do sistema ou do seu efeito no ambiente durante a
execuo dos seus programas.

Diretas ou Indiretas

Mtricas Diretas, Bsicas ou Quantitativas: no dependem da medio de

outros atributos. Exemplo: custo/esforo do desenvolvimento, linhas de cdigo,
velocidade de execuo, quantidade de memria, nmero de erros, quantidade
de defeitos. Concentram-se na sada do processo de engenharia de software.

Mtricas Indiretas, Derivadas ou Qualitativas: dependem da medio de

outros atributos. Exemplo: produtividade, qualidade e tcnicas (funcionalidade,
manutenabilidade, complexidade, eficincia, confiabilidade, modularidade,
portabilidade). Indicam o quanto o software atende aos requisitos definidos
pelo usurio.

Orientadas a Tamanho, Funo ou Pessoas

Mtricas Orientadas a Tamanho: baseadas no nmero de linhas de cdigo

produzidas (LOC)

Mtricas Orientadas a Funo: baseadas na funcionalidade de software, tais

como a Analise de Pontos de Funo.

Mtrica Orientadas a Pessoas: indicam a forma como as pessoas devem

desenvolver os programas.

Objetivas ou subjetivas

Objetivas: independem do autor da medio ou julgamento humano. Exemplo:

quantidade de defeitos.

Subjetiva: dependem do autor da medio ou julgamento humano. Exemplo:

classificar a criticidade de um defeito.

Produtividade, Qualidade ou Tcnica

Produtividade: resultado do processo de desenvolvimento

Qualidade: nvel de exigncia ou satisfao do usurio

Tcnica: funcionalidade, manutenabilidade, modularidade, complexidade,

eficincia, confiabilidade, portabilidade.

Exemplos de Mtricas

Fan-in e Fan-out: Fan-in o nmero de funes que chamam a funo X.

Fan-out o nmero de funes chamadas pela funo X.

Extenso de Cdigo: quanto maior for o tamanho do cdigo de um

componente, mais complexo e propenso a erros este componente ser

Complexidade Ciclomtica: complexidade de controle do programa. Utiliza

grafos e a seguinte frmula:
o

M=E-N+2P, onde:

M = complexidade ciclomtica
E = quantidade de setas
N = quantidade de ns
P = quantidade de componentes conectados

Extenso de Identificadores: extenso mdia de identificadores distintos de

um programa. Quanto maiores forem os identificadores, mais eles sero
significativos e mais compreensvel ser o programa.

Profundidade de aninhamento das declaraes condicionais: declaraes

IF profundamente aninhadas so difceis de compreender e so
potencialmente propensas a erros.

ndice de Fog: extenso mdia das palavras e sentenas nas documentaes

Mean Time To Failure (MTTF): tempo que o software roda sem falhar

Densidade do defeito: quantidade de defeitos (durante um perodo de tempo)

pelo tamanho do software

Mean Time Between Failures (MTBF): tempo mdio entre as falhas. Ajuda a
prever quando ocorrer a prxima falha.

O TCU assegura s partes o exerccio da ampla defesa em todas as etapas da apreciao

e julgamento dos processos. Essa matria est disciplinada na Resoluo no 36/95 do
Tribunal.
O art. 202 do Regimento Interno do TCU estabelece que, se verificada irregularidade, o
Tribunal ou o Relator, havendo dbito, ordena a citao do responsvel para apresentar
defesa ou recolher a quantia devida. No havendo dbito, determina a audincia do
responsvel para apresentar razes de justificativa.
A deciso do Tribunal da qual resulte imputao de dbito ou cominao de multa torna
a dvida lquida e certa e tem eficcia de ttulo executivo. Nesse caso, o responsvel

notificado para, no prazo de quinze dias, recolher o valor devido. Se o responsvel, aps
ter sido notificado, no recolher tempestivamente a importncia devida, formalizado
processo de cobrana executiva, o qual encaminhado ao Ministrio Pblico junto ao
Tribunal para, por meio da Advocacia-Geral da Unio (AGU) ou das unidades
jurisdicionadas ao TCU, promover a cobrana judicial da dvida ou o arresto de bens.

Condenao de Responsveis

Entre as funes bsicas do Tribunal est a funo sancionadora (incisos VIII a XI do

art. 71 da Constituio Federal), a qual configura-se na aplicao de penalidades aos
responsveis, em caso de ilegalidade de despesa ou irregularidade de contas. As sanes
esto previstas na Lei n 8.443/92 e podem envolver desde aplicao de multa e
obrigao de devoluo do dbito apurado, at afastamento provisrio do cargo, o
arresto dos bens de responsveis julgados em dbito e a inabilitao para o exerccio de
cargo em comisso ou funo de confiana no mbito da administrao pblica.
Cumpre destacar que essas penalidades no excluem a aplicao de sanes penais e
administrativas pelas autoridades competentes, em razo das mesmas irregularidades
constatadas pelo Tribunal de Contas da Unio. Entre elas est a declarao de
inelegibilidade por parte da Justia Eleitoral.
Periodicamente, o TCU envia ao Ministrio Pblico Eleitoral os nomes dos
responsveis cujas contas foram julgadas irregulares nos cinco anos anteriores, para os
fins previstos na Lei Complementar no 64/90, que trata da declarao de inelegibilidade.
O Tribunal pode, ainda, conforme disposto nos incisos IX e X do art. 71 da
Constituio, fixar prazo para que o rgo ou entidade adote as providncias necessrias
ao exato cumprimento da lei, caso haja alguma ilegalidade, ou sustar o ato impugnado.
No caso de contratos, se no atendido, o Tribunal comunica o fato ao Congresso
Nacional, a quem compete adotar o ato de sustao.

O PMBOK 5 define 3 tipos de Ciclo de Vida de Projeto:

a) Previstos ou previsveis: escopo, tempo e custos so definidos mais cedo, em funo
da estabilidade da rea de negcio na qual o projeto est sendo desenvolvido. Estes
projetos progridem atravs de uma srie de fases sequenciais ou sobrepostas.

So preferidos quando a rea de atuao bem conhecida e estvel, exige-se que o

produto seja entregue por inteiro.
b) Iterativos e incrementais: as fases (iteraes) repetem uma ou mais atividades, a
medida que aumenta a compreenso sobre o projeto.
Preferidos quando a organizao necessita administrar mudanas dos objetivos e
escopo, reduzir a complexidade de um projeto ou quando a entrega parcial do produto
benfica.
c) adaptativos: direcionadas mudanas ou geis, reage a altos nveis de mudanas e
envolvimento contnuo das partes interessadas; so tambm iterativos e incrementais,
com a diferena que as iteraes so muito rpidas (2 a 4 semanas) com tempo e
recursos fixos.
Preferidos em ambientes em rpida mutao, requisitos e escopo difceis de definir
antecipadamente, possvel definir pequenas melhorias incrementais que entregaro valor
s partes interessadas.

O padro ISO/IEC 38500:2008 Governana corporativa da tecnologia da informao

baseia-se em seis princpios bsicos.
Princpios do ISO/IEC 38500:
1 PRINCPIO - RESPONSABILIDADE
2 PRINCPIO - ESTRATGIA
3 PRINCPIO - AQUISIO
4 PRINCPIO - DESEMPENHO
5 PRINCPIO - CONFORMIDADE
6 PRINCPIO - COMPORTAMENTO HUMANO
Para mais informaes de como o COBIT 5 apoia a adoo dos princpios e abordagem
de implementao do padro ISO/IEC 38500:2008 Governana corporativa da
tecnologia da informao ver APNDICE E do COBIT 5
Fonte: COBIT 5 (pg 61 a 64)

Construir, Adquirir e Implementar (BAI) - este domnio cobre identificao,

desenvolvimento e/ou aquisio de solues de TI
para executar a estratgia de TI estabelecida, assim como a sua implementao e
integrao junto aos processos de negcio. Mudanas e manutenes em sistemas

existentes tambm esto cobertas por este domnio, para assegurar a continuidade dos
respectivos ciclos de vida.
BAI01
BAI02
BAI03
BAI04
BAI05
BAI06
BAI07
BAI08
BAI09
BAI10

Gerenciar programas e projetos

Gerenciar a defi nio de requisitos
Gerenciar a identifi cao e a construo de solues
Gerenciar disponibilidade e capacidade
Gerenciar a habilitao da mudana organizacional
Gerenciar mudanas
Gerenciar o aceite e a transio das mudanas
Gerenciar o conhecimento
Gerenciar ativos
Gerenciar a confi gurao

Entregar, Reparar e Suportar (DSS) - este domnio cobre a entrega propriamente dita
dos servios requeridos, incluindo gerenciamento de segurana e continuidade, reparo
de equipamentos e demais itens relacionados, suporte aos servios para os usurios,
gesto dos dados e da infraestrutura operacional.
DSS01
DSS02
DSS03
DSS04
DSS05
DSS06

Gerenciar operaes
Gerenciar requisies de servios e incidentes
Gerenciar problemas
Gerenciar a continuidade
Gerenciar os servios de segurana
Gerenciar controles de processos de negcios

Tunning BD = otimizao de uso de recursos para aumentar o througput e

minimizar a conteno, possibilitando o maior workload possvel de ser
processado.

Galera encontrei o seguinte trecho em uma monografia e quero compartilhar. Peo

desculpas por no encontrar uma fonte consagrada da rea. Mas como solucionou minha
dvida, segue abaixo.
Segundo a monografia abaixo,"Entretanto, para este ajuste necessrio estar ciente dos
fatores determinantes para a sintonia do SGBD que so:
a) Workload - a carga de trabalho imposta;
b) Throughput: - a capacidade e/ou velocidade de processamento de dados do
computador;
c) Recursos - hardware disponvel e as ferramentas de softwares a serem empregados;
d) Otimizao - o otimizador do banco de dados, componente responsvel pela
identificao da melhor forma de execuo de um comando SQL;

e) Conteno - a condio em que h dois ou mais pedidos conflitantes ao mesmo

tempo, algo como duas atualizaes no mesmo dado por exemplo.
**Com isto, pode-se definir Sintonia em Banco de Dados como uma otimizao nos
recursos usados para aumentar throughput e diretamente diminuir a conteno,
fazendo com que se tenha a capacidade de executar um workload maior em um
mesmo tempo x ."
http://periodicos.unesc.net/index.php/sulcomp/article/viewFile/787/740

Lista contendo as mais importantes regras de sintaxe da XML:

1 - Um documento XML deve possuir raiz nica.
2 - Todas as tags devem ser fechadas (elementos devem possuir tag inicial e tag final)
3 - Os nomes de elementos (tags) e atributos so sensveis caracteres maisculos e
minsculos.
4 - Os elementos devem ser bem-aninhados (tags fecham em ordem oposta a que foram
abertas).
5 - Atributos no se repetem em um mesmo elemento.
6 - Todo atributo deve possuir algum valor e este valor deve ser especificado entre
aspas.
7 - Alguns caracteres especiais, como < , & e > devem ser especificados com
o uso de entidades pr-definidas (no caso & lt; , & amp; e & gt; , respectivamente).
8 - Nomes de tags no podem conter espaos em branco nem os caracteres !"#$
%&'()*+,/;<=>?@[\]^`{|}~. Alm disso, no podem comear com um nmero, .
(ponto) ou - " (trao).

A habilidade de se modificar a definio de um esquema (nvel de abstrao) sem afetar

a definio de esquema em um nvel mais alto chamada de independncia de dados,
essa independncia dividida em dois nveis:

Independncia fsica de dados: a habilidade de modificar o esquema fsico

sem a necessidade de reescrever os programas aplicativos. As modificaes no
nvel fsico so ocasionalmente necessrias para melhorar o desempenho.

Independncia lgica de dados: a habilidade de modificar o esquema

conceitual sem a necessidade de reescrever os programas aplicativos. As
modificaes no nvel conceitual so necessrias quanto a estrutura lgica do
banco de dados alterada (por exemplo, a adio de contas de bolsas de
mercado num sistema bancrio)

A independncia lgica dos dados mais difcil de ser alcanada do que a

independncia fsica, porm os programas so bastante dependentes da estrutura lgica
dos dados que eles acessam.
O conceito de independncia dos dados similar em muitos aspectos ao conceito de
tipos abstratos de dados em modernas linguagens de programao. Ambos escondem
detalhes de implementao do usurio. Isto permite ao usurio concentrar-se na
estrutura geral em vez de detalhes de baixo nvel de implementao.

Existem muitas motivaes para os bancos NoSQL, como por exemplo usar um
modelo mais adequado para os seu dados ou facilitar alteraes de schema; ou ainda
alm, melhorar o desempenho e simplificar a replicao para ter a to sonhada
escalabilidade linear.
O teorema CAP
Claro que todos os benefcios no vem sem custo, comparado com os bancos de dados
tradicionais vamos perder alguma funcionalidade/garantia para ganhar outra. O tradeoff
arquitetural descrito no bem conhecido CAP theorem.

A palestra famosa do Dr. Eric Brewer introduz o teorema e explica que em

qualquer sistema distribudo stateful preciso escolher entre consistncia
forte (C Consistency), alta disponibilidade (A availability) e
tolerncia a particionamento dos dados na rede(P Network
Partition Tolerance). Segundo o teorema CAP, entre as trs propriedades,
somente duas podem ser garantidas ao mesmo tempo:

Partition-Tolerance
Poder particionar nossos dados em diferentes ns de um cluster um dos recursos que
aparecem com frequncia nos bancos NoSQL. Saber lidar com a
separao/particionamento das dados devido uma falha na rede conhecido
como Partition-Tolerant. No entanto, segundo o teorema CAP, em troca eles iro
sacrificar a consistncia forte ou a alta disponibilidade. Isso diferente dos bancos
tradicionais, que no possuem essa caracterstica no design do sistema ou delegam isso
para o filesystem.
NoSQL 1: Sistemas CP

Para sistemas que precisam da consistncia forte e tolerncia a particionamento (CP)

necessrio abrir a mo da disponibilidade (um pouco). Pode acontecer, caso haja
particionamento e o sistema no entre em consenso, que uma escrita seja rejeitada.
Claro que os sistemas tentam evitar isso ao mximo, tanto que no costuma existir, por
exemplo, uma transao distribuda e sim um protocolo de consensos para garantir a
consistncia forte. Exemplos desses sistemas CP so BigTable, HBase ou MongoDB
entre vrios outros.
NoSQL 2: Sistemas AP
Por outro lado existem sistemas que jamais podem ficar offline (24/7), portanto no
desejam sacrificar a disponibilidade. Para ter alta disponibilidade mesmo com um
tolerncia a particionamento (PA) preciso prejudicar a consistncia (eventualconsistency). A ideia aqui que os sistemas aceitam escritas sempre e tentam
sincronizar os dados em algum momento depois (read-consistency). Ento pode ter uma
janela de inconsistncia. Exemplos aqui so Amazon Dynamo, Cassandra ou Riak.
Sistemas CA
Os sistemas com consistncia forte e alta disponibilidade (CA) (alta disponibilidade de
um n apenas) no sabem lidar com a possvel falha de uma partio. Caso ocorra,
sistema inteiro pode ficar indisponvel at o membro do cluster voltar. Exemplos disso
so algumas configuraes clssicas de bancos relacionais.
Qual a diferena entra CA e CP?
Vimos brevemente o teorema CAP e a escolha que os sistemas NoSQL fazem (CP ou
AP) comparado com os bancos tradicionais (CA). importante mencionar que para o
desenvolvedor no haver tantas diferenas entre CA ou CP. SEMPRE teremos
consistncia forte, no entanto, um sistema fica indisponvel (CA) quando h
particionamento pois tem apenas alta disponibilidade por n e o outro sistema (CP)
tente chegar a um consenso se aceita uma escrita ou no, que no pior dos casos tambm
pode significar a indisponibilidade para uma parte dos dados. Seguindo desse raciocnio
podemos perceber que a consistncia e disponibilidade so extremos quando h
particionamento. Isso foi uma dvida que me incomodou bastante antes da minha
palestra no Caelumday 2009. Podemos concluir que quando h particionamento (P)
ter alta disponibilidade (A) ou consistncia (C) forte: P?(A|C)
Mas o que acontece se NO h particionamento?
uma pergunta que o CAP no responde. A primeira resposta poderia ser: claro que vai
ser consistente j que ningum gosta de lidar com dados desatualizados. Mas olhando
para os sistemas NoSQL nem sempre isso verdade. Existem sistemas que SEMPRE
so eventually-consistent. Mas porque?

Consistncia ou Latncia
H mais um motivo porque poderia fazer sentido sacrificar a consistncia: O tempo da
resposta ou a latncia. Da mesma maneira que um sistema offline pode custar caro, um
sistema lento tambm pode. Por isso pode fazer sentido abrir a mo da consistncia para
diminuir a latncia.
De CAP para PAC/CL
O artigo do blog do Prof. Daniel Abadi explica o tradeoff com parties e sem. Ele
sugere substituir a sigla CAP com PAC/CL (ou P?(A|C):(C|L)), traduzindo levemente
modificado do artigo dele:
se h particionamento (P), o sistema pode valorizar a disponibilidade (A) ou a
consistncia (C), seno, quando o sistema roda sem parties, o sistema pode favorecer
o tempo da resposta/latncia (L) ou a consistncia (C).
Exemplos de PAC/CL
Seguindo dessa linha PC/C significa que o sistema valoriza a consistncia sempre, com
ou sem parties. Banco de dados tradicionais so sempre fortemente consistentes, ou
seja PC/C. Amazon Dynamo ou Cassandra so sempre fracamente consistente,
favorecendo a alta disponibilidade e o tempo da resposta (latncia), ou seja PA/L. Mas
existem misturas como o GenieDB (PA/C), que s trabalha consistente em caso de
nenhuma parties. Quando h parties valoriza a alta disponibilidade. Exemplo
contrrio disso o Yahoo Sherpa, que usa PC/L, ou seja com parties favorece
consistncia, sem parties diminuir a latncia.
Durante o curso FJ-91, diversas questes e decises arquiteturais so abordadas e
discutidas, sendo que uma delas envolve o teorema CAP e os bancos de dados NoSQL.

Um NAS (Network Attached Storage), por sua vez, roda um sistema operacional
completo e funciona como um servidor de arquivos, ligado diretamente na rede.
Muitas vezes, eles so chamados de "network storage", ou simplesmente de "storage",
termos que so mais descritivos para o pblico no tcnico do que "NAS". Entre o
pblico tcnico, eles so tambm chamado de "filers" (arquivadores). O termo "storage"
na verdade um termo tcnico genrico para solues de armazenamento, que usado
tambm em outras situaes, como no caso das SANs.

SAN se comporta como se fosse uma nica unidade de armazenamento, que o servidor
pode acessar diretamente, de forma transparente. Ou seja, como se voc conectasse
um nico HD de 100 TB (por exemplo) no servidor, diferente de um NAS, que se

comporta como um servidor de arquivos e pode ser acessado simultaneamente por

vrios clientes.
Apesar disso, na grande maioria dos casos, o objetivo de usar uma SAN no
simplesmente obter um grande espao de armazenamento, mas sim obter ganhos de
desempenho e de confiabilidade para aplicaes crticas.

As fases do TDD so:

1 - Adicione um teste no TDD para a nova funcionalidade. Este teste tem que falhar.
2 - Execute todos os testes e verifique se algum falhou. Verifica se o novo teste no traz
um erro j existente, logo no decorrente da nova funcionalidade
3 - Escreva o cdigo. Pode no ser perfeito e pode passar no teste de forma no
elegante. Ser melhorado depois.
4 - Execute todos os testes automatizados
5 - Refatore o cdigo
6 - Repita tudo
A ordem no est certa e faltam os passos 4 e 5.