Google+ Followers

sexta-feira, 3 de abril de 2015


Automação de Testes para dispositivos Mobile: Appium


O Appium trata-se de um framework de automação de teste open source para aplicações mobile ( nativas e/ou híbridas), suportando tanto dispositivos Android quanto IOS.

Appium visa automatizar qualquer aplicativo móvel de qualquer idioma e em qualquer framework, com acesso total a back-end APIs e DBs de código. Escrever testes com suas ferramentas favoritas utilizando várias linguagens de programação(Ruby, Java, PHP e etc.), e também (com o Selenium WebDriver API e bibliotecas de cliente específicos de idioma).

Filosofia

Appium é baseado na ideia de testar aplicativos nativos, não deve exigir um SDK ou recompilar seu aplicativos. E que você deve ser capaz de usar suas práticas preferidas dos testes, frameworks e ferramentas. O Appium é um projeto open source e tem feito decisões de desenho, ferramentas para incentivar a comunidade a contribuir vibrantemente.

Ambiente

O appium roda tanto em OSx, Win e Linux.

Para aprender a instalar e configurar  o APPIUM acesse:   www.saltonacomputacao.com 

ISO 29.119 - Proposta de Padronização de Testes de Software





A Organização Internacional de Padrões (International Standards Organisation - ISO), em colaboração com outros grupos, está preparando um novo padrão: o ISO/IEC/IEEE 29919. Este padrão busca padronizar e discriminar muitas das práticas e técnicas para testes de projetos de software. 

A resposta da comunidade de testes vem sendo muito negativa a esse novo padrão, em razão da natureza prescritiva do padrão e da exclusão de abordagens dirigidas ao contexto (context-driven).

 O objetivo declarado do padrão é:
 O ISO/IEC/IEEE 29119 Software Testing é um conjunto de normas internacionalmente acordadas para teste de software e que pode ser usada em qualquer organização ou ciclo de vida de desenvolvimento de software. Implementando estas normas, adotam-se os únicos padrões de testes acordados e reconhecidos internacionalmente, que irão prover a organização com uma abordagem de alta qualidade para testes e que pode ser comunicada por todo o mundo.

Stuard Reid, líder do grupo de trabalho da ISO que está desenvolvendo o padrão, compartilhou um webinar que explica a intenção e o conteúdo do padrão proposto.

O novo padrão vai substituir padrões existentes que foram publicados por diferentes grupos:
- IEEE 829 Test Documentation
- IEEE 1008 Unit Testing
- BS 7925-1 Vocabulary of Terms in Software Testing
- BS 7925-2 Software Component Testing Standard

Fonte: www.infoq.com - Acesso em 03/04/2015

Falhas em estados sobrecarregam sistema do seguro-desemprego


Os trabalhadores que estão buscando o seguro-desemprego desde março estão encontrando dificuldades. Segundo o Ministério do Trabalho (MTE), o sistema está sobrecarregado por conta de falhas nos sistemas de atendimento em alguns estados.

Procurado pelo G1, o ministério explicou que há dificuldades em postos de atendimento presencial em alguns locais, como o Rio de Janeiro, e no Distrito Federal, sob responsabilidade dos governos desses locais.

Com isso, há um aumento na procura através do sistema do MTE, que fica sobrecarregado. O ministério afirmou, no entanto, que não há informação sobre qualquer paralisação nacional.

A reportagem do G1 constatou que trabalhadores que buscavam atendimento no Poupa tempo de Santo Amaro, na zona sul de São Paulo, chegavam a esperar mais de duas horas pelo atendimento. Funcionários informavam que o sistema estava fora do ar e que o público precisaria esperar.

Fonte: http://g1.globo.com  - Por Estadão - Acesso em 02/03/15

quinta-feira, 2 de abril de 2015

Android teve menos de 1% de infecções em 2014, diz relatório do Google


por 
Para o TechTudo

Google divulgou hoje (02) seu relatório oficial sobre segurança do Android no ano de 2014. Esse é o resultado da análise de bilhões de dados que foram recolhidos pela empresa no ano passado, com base no uso de seu sistema operacional. A conclusão é que menos de 1% dos aparelhos Android possuíam apps perigosos, e que é muito mais seguro instalar apenas aplicativos da Google Play.

Gráfico mostrando o número de Androids infectados (Foto: Divulgação)Gráfico mostrando o número de Androids infectados (Foto: Divulgação)


Apesar de notícias sobre malwares e outras pragas no sistema móvel serem comuns, a empresa tem investido pesado em segurança. Recentemente, o Android ganhou incrementos em segurança bastante importantes, tais como a criptografia completa do chip de memória, sandbox melhorado, proteção contra ataques de força bruta e melhorias na autenticação com os “trustlets”.
Como se não bastasse, desde o mês passado os apps disponibilizados na Google Play passam por uma avaliação humana antes de serem aprovados. A empresa também recomenda que você mantenha ativada a opção “Verificação de segurança” em seu Android, para impedir que programas potencialmente perigosos sejam instalados.
Quando analisados os dispositivos que não possuem root, a porcentagem de aparelhos infectados ficou abaixo de 1%. Essa taxa cai ainda mais quando analisamos os smartphones que instalam somente da Google Play, chegando a 0,15% apenas. Em outras palavras, se você não tem root e só instala apps da loja oficial, as chances do seu celular ter algum vírus são mínimas.
Gráfico de infecções por país (Foto: Divulgação)Gráfico de infecções por país (Foto: Divulgação)
A loja oficial é segura, pois há varreduras constantes da equipe de segurança em busca de aplicativos potencialmente perigosos. Diariamente, são feitas mais de 200 milhões de varreduras nos mais de 1 bilhão de dispositivos conectados à Google Play.
Dois dos países com notáveis índices de infecção nos Android são China e Rússia. Na China, a porcentagem de aparelhos com apps perigosos chega a mais de 7%. Já na Rússia esse número chega a quase 5%. Bem maiores que no restante do globo, que não ultrapassa nem os 2%. 

domingo, 22 de março de 2015

Requisito Funcional e Requisito Não-Funcional


Você sabe o significado da palavra requisito? Bem de acordo com o dicionário Aurélio, o significado da palavra requisito é: “Condição necessária para se alcançar certo objetivo; quesito”.  Na área de Engenharia de Software o significado não é diferente. Os requisitos são todas as funcionalidades que um sistema deve atender para satisfazer um contrato ou um documento de especificação. Na Engenharia de Software os requisitos são divididos em Requisito Funcional e Requisito Não Funcional.

Requisito Funcional:
especifica determinada função que um componente ou sistema deve desempenhar [IEEE 610].
Requisito Não Funcional:
requisito que não diz respeito à funcionalidade, mas a características como:

- confiabilidade;
- eficiência;
- usabilidade;
- manutenibilidade e 
- portabilidade.


Quando se fala em Requisito Funcional é fácil porque nos lembramos das funcionalidades, mas quando o assunto é Requisito Não Funcional fica difícil levantar os requisitos dentro de cada uma das características citadas acima. Então para ajudar vamos entender cada uma das características de qualidade segundo a norma ISO 9126-1.

Característica
Descrição
Confiabilidade
Capacidade do software de manter um nível especifico de performance quando usado sob determinadas condições preestabelecidas.
Eficiência
Capacidade do software de manter a performance, em relação aos recursos disponíveis, quando usado sob determinadas condições especificas.
Usabilidade
Capacidade do software de ser entendido, aprendido, usado e atrativo quando usado sob determinadas condições especificas.
Manutenibilidade
Capacidade do software de ser mantido.
Portabilidade
Capacidade do software de ser transferido de um ambiente para outro.

Depois de descrever cada uma das características fica mais fácil ainda se usarmos um pouco de exemplos. Então vamos a alguns exemplos de Requisito Não Funcional. Os exemplos abaixo retirei de um teste de performance que realizei para um portal de  uma empresa de telecomunicações. 



Eficiência:
  1. O sistema deverá suportar até 1300 TPS (Transações por segundo).
  2. O sistema deverá funcionar 24 horas por dia, sete dias por semana (24x7).
  3. O tempo de resposta das requisições não devem ultrapassar 5 ou 7 segundos.
  4. O sistema deverá suportar até X requisições simultânea por segundo.
  5. O sistema deverá ser capaz de atender uma requisição para os usuários em até 5 segundos no horário de pico com até 50 usuários simultâneos.
  6. O sistema deverá ser capaz de atender uma requisição de consulta de saldo para os usuários em até x segundos.


Confiabilidade:
  1. O sistema deverá permitir que somente usuários e parceiros autorizados realizem ativação e/ou desativação de pacotes
  2. Todos os acessos ao sistema serão realizados para usuários devidamente autenticados conforme perfil de acesso. 
  3. O log de disco deverá ser expurgado em até 6 dias ou quando a capacidade do disco atingir 60 Gbytes. 
  4. Apenas os usuários com privilégios de acesso de parceiros poderão utilizar os logs das requisições. 
  5. O sistema deverá garantir o sigilo das informações trafegadas na rede interna e externa (internet).  

Manutenibilidade:

  1. O sistema deverá dar suporte aos protocolos WSS e LSS.

Portabilidade:

  1. O sistema deverá se comunicar com outros sistemas, barramentos, hardware e base de dados.

Bem espero que tenham entendido um pouco mais sobre Requisito Funcional e Requisito Não Funcional e até próximo post. 

Sara Meireles
Analista de Teste