Essentials on Automation Tests

Introdução / Introduction

Hoje em dia são enumeras as empresas a acoplar muito do seu esforço numa abordagem mais faseada e efetiva no contexto dos testes a software. Este facto emana da necessidade das empresas providenciarem o produto final com uma maior qualidade junto do cliente. Presume-se que, uma grande quota do mercado das tecnologias, nomeadamente empresas da área de TI, reúnam muito do seu esforço em testes manuais a software, como p.ex., estimar todos os passos do fluxo de registo de um formulário. Desta feita, são muitos os recursos físicos, humanos (tempo e paciência) despendidos em atividades repetitivas podendo estas ser testadas através de TAs.

Within the scope of the software tests, a wide group of companies engages an extensive effort in a more phased and effective approach nowadays. This fact seems to result of the necessity to provide a better quality on-time delivery of the final product. It is assumed that a large quote of the technology market, including IT companies, employ much of its effort on software manual testing, such as to identify all the steps from the online registration form that the user going to use later. With that, numerous physical and human resources (time and patience) are spent, this implies much time on repetitive activities which can be tested through ATs.

É neste ponto que surge a oportunidade de enfatizar a necessidade e utilidade dos TAs. A utilização deste recente paradigma em sistemas de informação consiste numa abordagem cabal, uma forma mais granular de testar e automatizar todos (ou os mais importantes e repetitivos) fluxos de execução de determinado sistema. De notar, que ao longo deste artigo é dado um exemplo de um sistema de informação, normalmente adotado por grande parte das empresas de prestação de serviços, e é distribuída toda a informação necessária para a construção de um ecossistema de TAs sobre este tipo de sistemas, assim como, algumas das tecnologias mais usadas dentro deste tema.

This is the opportunity to emphasize the ATs utility. The usability provided by this new paradigm consists on a full approach, namely a rather granular way to test all the system execution flows. Note that, the present article gives an example of a model information system usually adopted by most companies. Information about how to build an ATs ecosystem and the used technologies is also delivered.

Visão Geral / Overview

Segundo Cem Kaner, autor do livro “Lessons Learned in Software Testing“, o propósito da automatização de testes pode ser resumidamente descrito como a aplicação de estratégias e ferramentas tendo em vista a redução do envolvimento humano em atividades manuais repetitivas. Os TAs, ou automatização de testes, tem como grande missão e foco a comparação dos resultados esperados com os resultados reais de um teste a determinado sistema da informação. Para isso, são estabelecidas pré-condições, de forma a viabilizar a automatização do sistema alvo, e com o objetivo do deploy dos resultados do teste para posterior escrutínio.

According Cem Kaner, author of “Lessons Learned in Software Testing”, the purpose of the test automation can be briefly described as the application of strategies and tools with a view to reducing human involvement in repetitive manual activities. ATs, also mentioned as automation tests, have a mission to compare the expect and actual results of a specific test on a system. For this, preconditions are established, in order to facilitate the automation of the target system. More over, the deployment of the test results for later scrutiny is an important piece within this matter.

De uma forma mais genérica, um TA pode ser iniciado a partir de um processo manual de teste já estabelecido e formalizado.

Currently is said that, an AT can be started from an already established and formalized manual test.

Recuando um pouco na linha dos testes a software, é importante perceber que um teste manual permite identificar diversos erros (bugs) num sistema, mas este é um trabalho bastante maçudo, e que demanda um grande esforço em tempo. Notar que pode não ser efetivo na procura de classes específicas de defeitos (defects).

Going back in the landscape of software testing, it is important to notice that through manual tests is possible to identify several issues on a system (errors or bugs), but this is an hard task, and requires great effort and time. Note that, this task can not be effective in finding specific class defects.

Com a automatização podem ser produzidos casos de teste bastante granulares, o que providência uma validação bastante rápida e periódica. Este tipo de abordagem é muito rica para softwares com uma longa vida, e pode ser um excelente aliado na regressão (testes de regressão), i.e., garantir que correções no código ou novos commits de código não causem quebras de funcionalidades que já havia sido implementadas.

Automation improves test validation over a rapid and incremental way. This means widespread granularity on the datasets and test cases. Thus, this approach is indicated for software with a long life-cycle, and shows be a important ally on regression testing, i.e., ensure that corrections to the code or new code commits cause no functionality breaks that had already been implemented.

A automatização de testes envolve duas distintas abordagens: white box e black box.

ATs involves two different approaches: white and black box.

Neste tipo de abordagem (white box) existe pleno conhecimento da estrutura interna e do modelo de negócio.

On white box testing approach there is full knowledge of the internal structure and business model of the proposal system.

Numa abordagem do tipo black box, não existe conhecimento sobre o modelo de negócio do sistema de informação, nem qualquer intrusão (ou adaptação) do sistema com o foco na fácil integração da automatização.

Regarding to black box approach, there is no knowledge about the system business model, nor any intrusion in the system with the focus on easy integration of automation.

Mesmo partindo para um abordagem mais ou menos intrusiva, este tipo de automatização é bastante cara e é usada, geralmente, a par com técnicas manuais. Especialmente, é importante a longo prazo, pois permite a conceção e validação de testes de regressão sobre o sistema com maior amplitude e profundidade.

Even assuming a more or less intrusive approach, this type of automation is very expensive and is used simultaneously with manual techniques. In particular, for software testing later it is important, it allows the design and validation of regression testing of the system with greater depth and efficiency.

Testes Manuais versus Testes Automatizados / Manual Tests versus Automation Tests

Nem sempre a utilização de TAs é a melhor solução. Em seguida, ficam umas linhas relativas ao diversos contextos de aplicação de testes manuais e automatizados.

The use of ATs is not the best solution always. Then, a few lines for the different application contexts of manual and automated tests are presented below.

Quando utilizar testes manuais:

Testes que envolvam tarefas mais intelectuais, e que exijam análise e pensamento lógico;
Testes de usabilidade;
Tarefas dinâmicas; e
Em sistemas que apresentem curto ciclo de vida.

When to use manual tests:

Tests involving more intellectual tasks, which require analysis and logical thinking;
Usability testing;
Dynamic tasks; and
On system that have short life cycle.

Quando utilizar ferramentas de automatização de testes:

Quando envolver tarefas repetitivas;
Aplicações com longos ciclos de vida; e
Testes que devem ser feitos com maior frequência (testes periódicos).

When to use ATs tools:

When involves repetitive tasks;
Applications with long life cycles; and
Tests that should be done more frequently (periodic testing).

Na prática, quando é suposto implementar um ecossistema de testes automatizados, o arquiteto de automatização encontra dois diferentes paradigmas:

Baseados na interface gráfica; e
Baseados na lógica do negócio.

O primeiro paradigma está confinado com a interação dos interfaces gráficos do sistema, simulando assim, as ações dos utilizadores.

When is implemented an automated testing ecosystem, the automation architect finds two different paradigms:

Graphical User Interface (GUI) based; and
Based on the business model.

The first one is confined to the interaction of GUIs, simulating thus the actions of users.

Vantagens / Advantages:

Não requer modificações na aplicação para criar os TAs. O teste usa as mesmas interfaces disponibilizadas ao utilizador (este exemplo é excelente para corroborar um teste do tipo black box).

It does not require modifications in the application to create the TAs. The test uses the same interfaces of user (this example corroborates a black box test).

Desvantagens / Disadvantages:

Existe uma forte dependência da estabilidade da Graphical User Interface (GUI). Se a interface mudar os testes falham. Neste caso, tanto os testers como os developers deverão manter guidelines standard de desenvolvimento, como por exemplo, identificar cada elemento web, p.ex., uma label ou um botão, com um campo denominado “id“.

Dependence of the GUI stability is a highlighted factor. Tests fail if the interface change. To solve this problem, testers and developers must maintain standard guidelines of development, e.g., to identify each web element, a label or a button, with a so-called “id” field.

Relativamente ao segundo paradigma, os TAs exercitam as funcionalidades da aplicação sem interagir com a GUI. Normalmente, concentram-se em APIs, interfaces de linha de comandos, web-services, hooks, etc.

Regarding to the second, ATs exercises the application functionality without GUI interaction . Usually, this type of paradigm directs the focus upon APIs, command line interfaces, web-services, hooks, etc.

Vantagens / Advantages:

Foco na camada onde existe maior probabilidade de existirem erros. Alto desempenho para testes repetitivos, etc.

Focus on the layer where there is greater likelihood of errors exist. High performance for repetitive tests, etc.

Desvantagens / Disadvantages:

Requer grandes modificações na aplicação a fim de expor as suas funcionalidades, Exige profissionais especializados em programação para a criação dos testes e estágios mais avançados da automatização. É necessária, quase sempre, a criação de soluções caseiras (ecossistema modelados conforme as necessidades atuais de implementação).

Changes in the system to expose the funcionalities are required. It also required programmers, once it is necessary to build the tests. Over this approach is always necessary the creation of homemade solutions (modeled ecosystems according to the present implementation requirements).

Esta secção apresentou um breve background dos teste automatizados. Em seguida, é proposto um modelo de negócio a automatizar e as ferramentas mais usadas para este tipo de automatização. Espera-se que no final do artigo sejam explícitos os passos base de criação de um ecossistema de TAs.

This section provides a brief background of ATs. A business model with the objective to automation is proposed below. The tools used for automating are also delivered. It is expected that the all the steps of “How to create a ATs ecosystem” are understood at the end of this article.

Sistema proposto / Proposal System

O diagrama de arquitetura abaixo apresenta o ecossistema/modelo de negócio a automatizar.

The ecosystem/business model to automate is presented in the architecture diagram below.

O ecossistema é composto por 3 grandes componentes, nomeadamente o Order Entry, o orquestrador (Order Manager) e por último, os sistemas externos (External Systems). Resumidamente, neste ecossistema pretende-se representar um fluxo completo de troca de mensagens entre diferentes sistemas com diferentes pontos de evolução. Este pode ser comparado a um ambiente de negócio de uma empresa de venda ao público, por exemplo, de materiais de construção.

This ecosystem consists of three major components, termed the Order Entry, the orchestrator (Order Manager) and lastly, the External Systems. In short, it is intended to depicture a complete flow of exchange of messages between different systems with different evolution points. A business environment of a company selling to the public, like building materials, is a valid example for this AT ecosystem.

Order Entry: Este sistema é o front-end de todo o ecossistema. Aqui, o funcionário pode criar novos clientes, registar encomendas, submeter faturação, etc.

Order Entry: It is the ecosystem entire front-end. It provides an interface to add new customers, to register orders, billing, etc.

Order Manager: Este é responsável por orquestrar todas as mensagens. Durante a compra de um produto são necessários alguns passos, e.g., registo do cliente, assegurar o stock do produto, agendar entrega de produtos junto do cliente, colocar a compra na pilha de faturação, etc. Este sistema possui integrados todos os fluxos dos possíveis cenários de troca de mensagens entre sistemas, que diga-se de passagem, faz parte do ADN de qualquer Order Manager vulgar.

Order Manager: This is responsible for orchestrating all messages. A set of steps are performed during the product purchasing, e.g., customer record, ensure the product stock, schedule product delivery, puts a new order on the billing queue, etc. This system seems to have integrated all the possible flows of messaging scenarios between systems, that therefore, is part of the any Order Manager DNA.

Exemplo: Registar um cliente / Example: Client register

Ordem entra no Order Manager (OM) oriunda do Order Entry (OE);
O OM, automaticamente, notifica o OE que recebeu a mensagem;
O OM envia para o External System (ES) a informação relativa ao cliente;
O ES responde ao OM dizendo que o cliente foi registado na base de dados; e
O OM notifica o OE que o fluxo terminou e que o cliente foi registado no sistema.

Order enters in the Order Manager (OM) coming from the Order Entry (OE);
OM automatically notifies the OE that received the message;
OM sends to the External System (ES) the customer information;
ES responds to OM saying that the client was registered in the database; and
OM notifies the OE that flow was done and the client was also registered in the system.

External Systems: Representa todos os sistemas externos do ecossistema, como por exemplo, o inventário de produtos, a base de dados de faturação, etc.

External Systems: It represents all external systems ecosystem, for example, product inventory, the billing database, etc.

Como automatizar este modelo de negócio / How to automate this business model

O diagrama seguinte apresenta uma proposta de como implementar um ecosistema de TAs sobre o modelo de negócio anteriormente apresentado.

The following diagram shows a proposal of how to implement an ATs ecosystem on the business model previously presented.

A vermelho está explicito que é necessário construir dois sistemas, (i) os casos de teste/regras que validam se o sistema se comporta como esperado, e (ii), os mocks. Neste caso, o objetivo é o teste dos fluxos. Para tal, é necessário validar o OM, pois este orquestra todos os fluxos de mensagens e cenários possíveis, como o exemplo, de um registo de um novo utilizador, que será o fluxo validado no decorrer deste artigo.

The diagram above is marked with the red color on two distinct parts, (i) the test cases/rules that validate the system, and (ii), the mocks. In this case, the aims this proposal is to test all the flows from OM. To do this, the validation of the OM is needed once it orchestra all the message flows and scenarios, e.g., the user register example that will be validated along this article.

Para interação com o OM neste exemplo em concreto, é necessário a construção de mocks. Estes são réplicas dos sistema externos reais, e respondem ao OM com a mensagem esperada (réplica da mensagem original do ES). A razão pela qual é necessária a construção de mocks, é que os TAs devem ser o menos intrusivos possíveis (black box approach). Nesse sentido, através dos mocks é possível perceber toda a comunicação entre o OM e os sistemas externos, i.e., contabilizar e validar todos os passos, de acordo com o fluxo a automatizar, neste caso “Registar um cliente“. Também com os mocks, é possíveis validar campos mandatórios numa mensagem. Por exemplo, o protocolo SOAP opera sobre envelopes SOAP, mensagens no formato XML. Desta feita, poderia ser testado dinâmicamente o conteúdo de determinados campos mandatórios no XML, e.g., trocar o campo do telefone por letras.

Once the goal for this example is OM stimulation, then, the edification of mocks/stubs is needed because this objects are replications of the actual external systems, and provide an expected message (reply of the original ES message) to OM. The principal reason for the construction of mocks is that the ATs should not be intrusive (black box approach). In this sense, through mocks is possible to see all communication between OM and the External Systems, i.e., validate all the steps, according with flow to automation, in this case, the scenario “Register a client.” Also with the mocks, it is possible to validate mandatory fields in a message. Notice that, SOAP protocol operates on SOAP envelopes and delivers XML format messages. Thus, dynamic content could be tested on certain mandatory fields, e.g., change the phone field by words.

Este é um tipo de teste automático trivial, e de uma forma mais coloquial e jocosa, parece ser inútil para exemplificar as potencialidades dos TAs. Todavia, relembrar, que este tipo de paradigma pode ser ajustado a outros casos concretos, pois o objetivo deste artigo é entregar uma breve overview sobre TAs e como construir uma solução rápida e eficiente no seio de qualquer ecossistema.

This is a kind of trivial ATs, and in a more colloquial and humorous way, it seems useless to exemplify its potential. Nonetheless, remember that this type of paradigm can be adjusted to other specific cases. The purpose of this article is to give a brief overview on ATs and how to build a quick and efficient solution upon any ecosystem.

Em seguida, é apresentado o diagrama de arquitetura para TAs e um diagrama de sequência, que apresenta a troca de mensagens entre o OE, o OM, o componente de Test Cases (Jenkins) e os respetivos mocks.

The architecture and sequence diagrams are presented below. These show the exchange of messages between the OE, OM, the Test Cases component (Jenkins) and the aforementioned mocks.

Este diagrama apresenta a arquitetura final, proposta para construção do ecossistema de TAs. É possível identificar algumas tecnologias ilustradas no diagrama. Estas serão descritas brevemente adiante, logo após o diagrama de sequência apresentado a seguir.

This diagram shows the final architecture, proposal for construction of ATs ecosystem. Some technologies can be briefly identified on the diagram, thus, after the sequence diagram presented, these are described in a more cohesive form.

O fluxo se procede como apresentado no diagrama. Reparar, que esta engenharia já desmistifica aquilo que vai ser a troca de mensagens deste ambiente de automação.

The flow proceeds as shown the diagram. Notice that, this engineering unmask what will be the exchange of messages for this automation environment.

É feita uma invocação, no OE, através do paradigma UI, de criação de um novo registo de utilizador (paradigma de testes baseado no UI);
O OE envia uma mensagem SOAP para o OM;
O OM notifica o OE com a mensagem de sucesso e contrata o serviço externo, neste caso os mocks produzidos;
Os mocks simulam que registaram o cliente (enviando uma resposta esperada) e enviam uma mensagem de sucesso para o OM; e
Finalmente, o OM notifica o OE que o registo foi catalogado no sistema.

The create user invocation is made into OE, possible from UI handling (test paradigm UI based);
OE sends a SOAP message to the OM;
OM notifies the OE with the message of success and hires the external service, in this case, the mocks;
The mocks simulate that registered the client (sending an expected response) and sends a success message to the OM; and
Finally, the OM notifies the OE that registration was cataloged in the system.

Com base neste fluxo, é construído o caso de teste, em cucumber, e validado cada passo do fluxo de acordo com as mensagens recebidas nos mocks, e os dados presentes no OE, acedidos e visíveis, através da UI do utilizador.

Based on this flow, the test case is implemented on cucumber and validated each step of the flow in accordance with the messages received in the mock objects. Also the data on the OE are accessible and visible by the user UI.

Tecnologias usadas para automatização / Used tecnologies for automation

Esta secção tem o objetivo de apresentar de forma breve algumas das ferramentas mais usadas no contexto da automação de tests. Para isso, em seguida é entregue uma pequena descrição e utilidade de cada uma.

This section aims to present briefly some of the tools commonly used upon ATs. Thus, is given a short description and utility detached below.

Linux

Um sistema operativo de eleição para este tipo de tarefas é sem dúvidas o Linux. Este dispensa apresentações. A razão pela qual foi mencionado está relacionado com algumas tecnologias a seguir, nomeadamente o Docker, o Ruby / Cucumber, e sobretudo o report de resultados dos testes para o Kibana, uma vez que este, o SO Linux, se torna uma ferramenta bastante coesiva no que toca a configurações.

An undoubtedly Operating System (OS) for this kind of tasks is the Linux. This needs no introductions. The reason to the choice is present in the mentioned technologies below, like Docker, Ruby / Cucumber, and especially the tests report for Kibana. Linux OS becomes a fairly cohesive regarding the configurations.

Relativamente a algumas distribuições, o autor dá algum destaque ao Red Hat e CentOS.

Regarding to some distributions, the author gives some prominence to Red Hat and CentOS.

https://www.centos.org

http://www.redhat.com/en

Docker

O Docker é um aplicativo, comparado, por vezes, a uma Virtual Machine (VM), que emula kernels de sistemas operativos. Na prática, ele pode ser mesmo entendido como uma VM.

Docker is an application sometimes compared with a Virtual Machine (VM) that emulates operating system kernels. In practice, it may even be understood as a VM.

Entrando em detalhes: O Docker utiliza Linux Containers (LXC), que correm no mesmo SO do servidor host. Isto permite o uso compartilhado de diversos recursos do SO host. Ele também utiliza AuFS para o sistema de arquivos.

Going into details: The Docker uses Linux Containers (LXC) that run the same operating system of the host server. This allows the shared use of several features of the host operating system. It also uses AuFS to the file system.

Ele é bastante útil e possui uma majestosa capacidade no que toca à portabilidade de sistemas/migração.

It is very useful for migration and portability of the systems.

Ficam alguns endereços: / Some URLs:

Página oficial: / Official page: https://docs.docker.com

Tutorial Online : https://www.docker.com/tryit

Online Repo: https://registry.hub.docker.com

Versionamento de Código (Code Versioning) – Subversion / GitHub

É importante usar versionamento de código em qualquer projeto. Tanto o Subversion como o GitHub são majestosas ferramentas para esse efeito. De notar, que é essencial o uso de uma destas ferramentas num estágio mais avançado, nomeadamente aquando da execução de um teste através de integração contínua e periodicamente no Jenkins. Este, para executar um novo teste (build) verifica e descarrega, sempre, a versão mais atual do código (o último commit).

Code versioning is must upon project implementation. For this purpose, Subversion or GitHub are majestic tools, and provide a good user experience. Notice that, in a later stage, it shows be a very important ally for the continuous integration server, namely, the so-called Jenkins. This, to perform a new test (upon Jenkins context, a build), it checks and discharges the most current version of the code (the last commit).

Ruby / Ruby on Rails

Acompanhando os recentes progressos do Ruby, e inclusive o RoR, estes têm-se mostrado bastante perspicazes no que toca a implementação de web-services, hooks, sistemas baseados na web, scripting, interação com bases de dados, entre outros. É uma linguagem compilada e com uma integração bastante poderosa, baseada no paradigma MVC.

Following the recent progress of Ruby, and even the RoR, these have been quite effective regarding the implementation of web-services, hooks, web-based systems, scripting, interaction with databases, and others. It is a compiled language and has very powerful integration, based on the MVC paradigm.

O RoR permite a rapida criação de mocks, e torna fácil a integração de outras frameworks/libs, como por exemplo, o Cucumber, Selenium, YAML, etc.

The RoR allows fast creation of mocks and makes it easy to integrate other frameworks/libs, such as Cucumber, Selenium, YAML, etc.

http://rubyonrails.org

Cucumber

O Cucumber é uma ferramenta que pode executar documentação de funcionalidades escrita em texto puro. É de fácil integração com o Ruby/RoR e a especificação é algo como o apresentado a seguir.

Cucumber is a tool that can perform functions of documentation written in plain text. It is easy to integrate with the Ruby / RoR and the spec is something like shown below.

Feature: Products registration
  In order to control my products
  As a system's user
  I want to be able to manage the products registration
  
  Scenario: Creating a new product
    Given I visit the new product page
    When I fill the new product form with Foobar as description and 10.00 as the price
    And click on the 'Create' button
    Then the number of existent products should be increased by one
    And I should be sent to the new product's page

Todos os steps são “programados”, e para que o scenario seja válido, todas as asserções, por steps, terão de ser validas (true).

All steps are “programmed”, and for the scenario validation, all assertions must be valid (true).

Selenium / Capybara

Tanto o Selenium como o Capybara são duas bibliotecas para UI handling. Permitem a fácil interação com componentes UI na web, como por exemplo, preencher um formulário de cadastro, automatizar determinadas ações que apenas um “ser humano e racional” poderia efetuar via web–browser.

Selenium and Capybara are two libraries for UI handling. These, allow easy interaction with UI components on the web, for example, fill in a registration form, automate certain actions that only a “human and rational” could make web-browser via.

A seguir é apresentado um trecho de código referente a um processo de autenticação usando o Selenium.

A code snippet referring to an authentication process using Selenium is presented as follows.

@driver.get 'http://example/login'
 @driver.find_element(id: 'username').send_keys('username')
 @driver.find_element(id: 'password').send_keys('password')
 @driver.find_element(id: 'login').submit
 @driver.find_element(css: '.flash.success').displayed?.should be_true

Jenkins

Jenkins é um sistema de Integração Contínua (CI), projetado para fazer builds automáticos de um projeto a partir de gatilhos pré-definidos (periódico, cada push representa um acesso ao repositório).

Jenkins is a Continuous Integration system (CI), designed to produce automated builds for projects from predefined triggers (every push presents an access to repository).

https://jenkins-ci.org

Logstash / Elasticsearch / Kibana

Estas ferramentas são uma peça fundamental para o report de resultados dos testes, falhas, etc. Digamos que, consegue entregar ao cliente ou ao público alvo, uma panoplia de resultados bastante granular e convincente. Tango o logstash como o elasticsearch são tecnologias para armazenar raw data, logs centralizados com um grande tamanho. Por sua vez, o elasticsearh cria, de forma automática, pilhas de dados, que são carregados para um componente web pelo Kibana.

These tools are a fundamental pieces for test report. Thus, is provided a better deliver to the client or target audience, because a panoply of very granular and convincing results, tables and graphics, are performed. Logstash and ElasticSearch are technologies for storing raw data, centralized logs with a large size. In turn, elasticsearh builds automatically data cells that are loaded onto a web component by Kibana.

É possível obter uma visualização 360º sobre os testes automatizados implementados, com o acréscimo de poder entregar ao cliente uma dashboard com os resultados dos testes.

In this sense, it is possible to get a 360 vision through the implemented ATs, with the addition of being able to deliver a dashboard with the results much more depicted.

http://williamdurand.fr/2014/12/17/elasticsearch-logstash-kibana-with-docker

Reflexão Final/ Final Refletion

Automatizar os testes de software pode nem sempre ser uma boa escolha, apesar de ter a suas muitas vantagens, afinal, nada como um cérebro humano comandando a caça aos bugs.

Automating software testing may not always be a good choice, despite its many advantages, after all, nothing like a human brain leading the hunt for bugs.

Referências / References

[1] http://pt.wikipedia.org/wiki/Automa%C3%A7%C3%A3o_de_teste
[2] http://crowdtest.me/testes-manuais-automacao-qual-melhor-opcao/
[3] http://www.qualister.com.br/blog/introducao-a-automacao-de-testes
[4] http://pt.slideshare.net/mauricioaniche/testes-automatizados-de-software
[5] https://andrethiago.wordpress.com/2011/04/06/as-vantagens-do-teste-unitario/
[6] http://www.qualister.com.br/blog/automacao-de-testes-em-webservices-com-soapui-parte-4-extraindo-dados-de-respostas-a-requisicoes-rest