Robot Framework 이해를 위한 정리(2/3)

테스트 자동화 도입 시 얻을 수 있는 것들 및 경계해야 하는 것들
이해하기 쉽습니다.

1. Common test automation promises
테스트 자동화가 약속하는 것들.

1) Run existing regression tests on a new version of a program
새롭게 변경된 프로그램에 회귀 테스트를 실행할 수 있다.

Being able to run previously created tests without extra effort clearly makes testing more efficient.
이전에 만들어져 있는 테스트를 간단하게 실행할 수 있도록 하여 효율적으로 테스트를 수행할 수 있도록 한다.

2) Run more tests more often
많은 테스트들을 자주 실행할 수 있도록 해준다.

Automation means faster test execution which means more test rounds. Automation should also make creating new test cases easy and fast.
자동화는 빠른 테스트 실행을 의미하기 때문에 테스트를 여러번 할 수 있다는 것을 의미하며, 또한 자동화는 새로운 테스트 케이스를 쉽고 빠르게 만들 수 있도록 한다.

3) Perform tests which would be difficult or impossible to do manually
수동으로 할 때는 어렵거나 아예 못할 것 들도 수행할 수 있다.

For example performance and stress tests are nearly impossible to conduct without automation.
예를 들어 성능 테스트나 스트레스 테스트 같은 것들은 자동화가 없다면 하기 어렵다. 왜냐하면 정말 다양하고 많은 테스트를 수행해야 하기 때문이다.

4) Better use of resources
자원을 효율적으로 사용할 수 있게 된다.

Automating repeating and boring tasks releases test engineers for more demanding and rewarding work.
반복적이고 지루한 일을 자동화 하는 것은 테스트 엔지니어가 의미있는 일을 할 수 있도록 만들어 준다.

5) Consistency and repeatability of tests
일관적이고 반복적인 테스트가 가능하게 된다.

Tests are always run the same way so test results can be consistently compared to previous results from previous testing rounds. Tests can also be easily repeated on different environments.
테스트들은 항상 같은 방식으로 실행기 되기 때문에 그 결과는 이전의 테스트들과도 일관성이 있게 나타난다. 테스트들은 다른 환경에서도 쉽게 실행될 수 있다.

6) Reuse of tests
재 사용성이 높다.

Reusing tests from earlier projects gives a kick start to a new project.
재 사용성은 새 프로젝트의 빠른 출발을 돕는다.

7) Earlier time to market
빠른 출시

Reusing tests and shortening test execution time fastens feedback cycle to developers. In the end that shortens the time to market.
테스트 재사용과 빠른 실행은 개발 주기를 더욱 빠르게 한다. 그래서 시장에 빨리 출시할 수 있게 한다.

8) Increased confidence
자신감 상승

Running an extensive set of tests often, consistently and on different environments successfully increases the confidence that the product really is ready to be released.

넓은 범위의 테스트를 자주, 일관성 있게 그리고 다양한 환경에서 성공적으로 실행할 수 있다는 것은 제품의 출시에 대한 자신감을 만들어줄 수 있다.



2. Common test automation problems
테스트 자동화의 문제점

1) Unrealistic expectations
실현 가능하지 않은 기대
Managers may believe test automation will solve all their testing problems and magically make the software quality better. Automation experts should help managers setting their expectations right.
매니저들은 테스트 자동화가 모든 문제를 해결해 주고 마법처럼 소프트웨어의 품질을 향상시켜 줄 것이라고 믿는다. 자동화 전문가들은 매니저들이 기대치를 올바르게 가지도록 도와야 한다.

2) Poor testing practice
낮은 테스트 경험
If testing practices and processes are inadequate it is better to start improving them than bringing in test automation. Automating chaos just gives faster chaos.
테스트에 대한 경험이나 테스트 프로세스가 제대로 갖춰지지 않았다면 그것을 먼저 향상시킨 다음에 테스트 자동화를 논의하는 것이 낮다. 혼란을 자동화 한다면 이해할 시간이 없어 혼란이 먼저 빠르게 찾아올 것이다.

3) Expectation that automated tests will find a lot of new defects
자동화된 테스트가 새로운 문제점을 찾아낼 것이라는 기대
After automated test has been run successfully once it is not very likely to find new bugs unless the tested functionality changes. Automators normally find more defects while they are developing tests than when tests are re-executed.
테스트가 자동화 되고 성공적으로 실행되고 난 다음에는 기능이 변경되지 않는 한 새로운 버그를 찾을 가능성이 낮다. 자동화 하는 사람들은 이미 실행된 테스트를 재 테스트 할 때보다 새로운 테스트를 만들 때 문제점을 더 찾는다.

4) False sense of security
보안에 대한 잘못된 인식
Just seeing a test report with no failures does not mean that the SUT did not have any. Tests may be incomplete, either not testing all features or not able to see failures when they occur. Tests may also have defects and show wrong results.
테스트 리포트에 fail 항목이 없다고 해서 테스트 대상에 버그가 없다는 것은 아니다. 테스트는 완벽하지 않으며, 전체를 다 테스트 하지 못했거나 fail이 발생했을 때 제대로 보지 못했을 수도 있다. 테스트 자체가 문제가 있거나 결과가 잘못되었을 가능성이 있다.

5) Maintenance
유지보수
When the SUT changes also its tests change. Human test engineers are able to handle even major changes without problems but automated tests can fail after a slightest change. If maintaining test automation system takes more time than testing manually it will surely be abandoned. The same will happen also if adding new features to the automation system is too cumbersome.
테스트 대상에 변경사항이 생기면 테스트도 변해야 한다. 테스트 엔지니어 들은 중요한 변경사항을 문제없이 다룰 수 있다. 하지만 자동화된 테스트는 작은 차이점에도 문제가 생길 수 있다. 만약에 테스트 자동화 시스템을 유지보수 하는데 수동으로 하는 것보다 더 많은 시간이 들어간다면 자동화를 하지 않는것이 낮다. 테스트 대상에 새로운 기능이 들어갈 때 다루기가 어렵울 때도 자동화를 하지 않는 것이 낮다.

6) Technical problems
기술적 문제
Building and taking test automation system to use is a technical challenge which is unlikely to proceed without problems. Tools may be incompatible with the tested system and they also often have defects themselves.
테스트 자동화를 구축하고 실행하는 것은 문제점을 만날수 밖에 벗은 기술적인 도전이다. 기존에 만들어진 도구들은 테스트 되는 시스템들에 호환될 가능성이 적으며, 그 자체도 문제가 있을 수 있다.

7) Organizational issues
관리적인 이슈
Successful test automation project requires both high technical skills and support from management. Test automation has also big impact on the organization and requires changes in many processes.
성공적인 테스트 자동화 정착되기 위해서는 기술의 수준이 높아야 함은 물론이고 경영진의 지원이 필요하다. 테스트 자동화는 단체에 큰 영향을 주며 프로세스들의 변경을 초래하기 때문이다.

*단어의 뜻
regression test
회귀 테스트는 회귀 버그를 찾는 테스트를 의미한다.
회귀 버그는 이전에 제대로 작동하던 소프트웨어 기능에 문제가 생기는 것을 가리킨다. 일반적으로 회귀 버그는 프로그램 변경 중 뜻하지 않게 발생한다.
회귀 테스트로는 이전의 실행 테스트를 재 실행하며 이전에 고쳐졌던 오류가 재현되는지 검사하는 방법이 많이 사용된다.
 버그가 발생했을 경우 이를 수정하면서 해당 버그를 발견할 수 있는 테스트 케이스를 작성하고 이를 이용해 프로그램을 변경할 때마다 테스트를 다시 수행하는 것이 좋다. 수동으로 할 수도 있지만, 보통은 테스트 자동화 툴을 사용한다.

이전글
Robot Framework 이해를 위한 정리(1/3)

참조
1. Robot Framework의 첫 제안이었던 헬싱키 대학 Laukkanen, Pekka 의 석사논문

Robot Framework 이해를 위한 정리(1/3)

정의
Robot Framework는 테스트 자동화를 위한 툴이다.

기원
기본 아이디어는 헬싱키 대학에 다니던 Pekka Laukkanen 의 2005년 석사 논문 'Data-Driven and Keyword-Driven Test Automation Frameworks'  에서 채택 되었으며  Nokia Siemens Networks 에서 첫번째 버전을 개발 하였다. 2008년부터 오픈소스가 되었다.

배경
1. 프로그램은 계속 커지고 있다.
2. 소프트웨어 품질은 더욱 중요해진다.
3. 소프트웨어 테스트를 잘 해야 한다는 압박이 더 커지고 있다.
4. 테스트 자동화는 분명히 이런 일의 크기를 줄여줄 수 있는 방법이다.
5. 하지만 테스트를 위한 시스템(System Under Test, SUT)이 변경되면 많은 걸 새로 작성해야 하고, 컴퓨터가 필요한 일을 해야 하는 것은 어려운 일이다.
6. 이런 상황에서 편리한 테스트 자동화를 위하여 Robot Framework를 제안한다.

테스트의 종류

			Static
SW Test
			Dynamic			Non Functional
						Functional			Unit
									Component
									System

테스트 자동화 Framework의 발전 3단계

1. 

테스트 데이터가 테스트 스크립트 안에 있다.

하나의 테스트 스크립트는 하나의 테스트를 수행한다.

시스템이 변경 된다면 테스트를 다시 써야 한다.

2. 

잘 디자인 되고, 모듈러 특성, 탄탄한 테스트, 문서화 되어 유지보수 가능

테스트 스크립트는 테스트의 수행만 하는 것이 아니라 테스트 전 기본 셋팅 수행, 테스트 초기화, 에러를 잡아서 원상복구 진행 가능 

여전히 테스트 데이터는 테스트 스크립트 속에 있다. 셋팅하는 스크립트는 테스트 케이스 마다 있다.

3. 

테스트 데이터는 테스트 스크립트와 분리된다. 이것은 두가지 분명한 이득이 있다.
1) 하나의 드라이버 스크립트로 여러 테스트 케이스에 사용할 수 있다.
2) 테스트 디자인과 Framework의 구분 해준다.
 - 테스트 될 특정 분야 지식
 - 프로그래밍 기술
이 3단계의 테스트 자동화 Framework는 Keyword Driven, Data Driven Framework 라고 불리며 이것은 이 논문의 제목 이다.


이후 진행
1. 설치(python, wxPython-unicode, robotframework(RIDE에서 바로 실행가능), robotframework-ride 설치, 이후 필요에 의해 pySerial 등 설치)
2. 실제 테스트케이스를 통한 분석


다음글
Robot Framework 이해를 위한 정리(2/3)

참조
1. Robot Framework 홈페이지
2. Robot Framework의 첫 제안이었던 헬싱키 대학 Laukkanen, Pekka 의 석사논문

(E, K) Robot framework, RIDE 3 - Libraries(라이브러리)

 Test libraries provide the actual testing capabilities to Robot Framework by providing keywords. There are several standard libraries that are bundled in with the framework, and galore of separately developed external libraries that can be installed based on your needs. Creating your own test libraries is a breeze.

Let us know if there are useful libraries missing from the list.

Test 라이브러리는 Robot Framework에서 실제 테스트를 키워드를 사용해서 할 수 있도록 해준다. 기본으로 설치되어 있는 라이브러리가 있고, 필요에 따라 설치할 수 있는 많은 외부 라이브러리들이 이미 개발되어 있다. 자신만의 라이브러리를 만드는 것도 쉽다.

만약 아래 리스트에 유용한 라이브러리가 빠져 있다면 알려주기 바란다.

* 한 눈에 볼 수 있도록 긴 표로 나타내었습니다.

STANDARD	Builtin	Provides a set of often needed generic keywords. Always automatically available without imports.
	Dialogs	Provides means for pausing the test execution and getting input from users.
	Collections	Provides a set of keywords for handling Python lists and dictionaries.
	OperatingSystem	Enables various operating system related tasks to be performed in the system where Robot Framework is running.
	Remote	Special library acting as a proxy between Robot Framework and test libraries elsewhere. Actual test libraries can be running on different machines    and be implemented using any programming language supporting XML-RPC protocol.
	Screenshot	Provides keywords to capture screenshots of the desktop.
	String	Library for generating, modifying and verifying strings.
	Telnet	Makes it possible to connect to Telnet servers and execute commands on the opened connections.
	XML	Library for generating, modifying and verifying XML files.
	Process	Library for running processes in the system. New in Robot Framework 2.8.
	DateTime	Library for date and time conversions. New in Robot Framework 2.8.5.
EXTERNAL	Android library	Library for all your Android automation needs. It uses Calabash Android internally.
	AnywhereLibrary	Library for testing Single-Page Apps (SPA). Uses Selenium Webdriver and Appium internally.
	AppiumLibrary	Library for Android- and iOS-testing. It uses Appium internally.
	Archive library	Library for handling zip- and tar-archives.
	AutoItLibrary	Windows GUI testing library that uses AutoIt freeware tool as a driver.
	Database Library (Java)	Java-based library for database testing. Works only with Jython.
	Database Library (Python)	Python based library for database testing. Works with any Python interpreter, including Jython.
	Diff Library	Library to diff two files together.
	Eclipse Library	Library for testing Eclipse RCP applications using SWT widgets.
	robotframework-faker	Library for Faker, a fake test data generator.
	FTP library	Library for testing and using FTP server with Robot Framework.
	HTTP library (livetest)	Library for HTTP level testing using livetest tool internally.
	HTTP library (Requests)	Library for HTTP level testing using Request internally.
	iOS library	Library for all your iOS automation needs. It uses Calabash iOS Server internally.
	ImageHorizonLibrary	Cross-platform, pure Python library for GUI automation based on image recognition.
	MongoDB library	Library for interacting with MongoDB using pymongo.
	MQTT library	Library for testing MQTT brokers and applications.
	Rammbock	Generic network protocol test library that offers easy way to specify network packets    and inspect the results of sent and received packets.
	RemoteSwingLibrary	Library for testing and connecting to a java process and using SwingLibrary, especially Java Web Start applications.
	SeleniumLibrary	Web testing library that uses popular Selenium tool internally. Uses deprecated Selenium 1.0 and is also itself deprecated.
	Selenium2Library	Web testing library that uses Selenium 2. For most parts drop-in-replacement for old SeleniumLibrary.
	Selenium2Library for Java	Java port of the Selenium2Library.
	SSHLibrary	Enables executing commands on remote machines over an SSH connection. Also supports transfering files using SFTP.
	SudsLibrary	A library for functional testing of SOAP-based web services based on Suds, a dynamic SOAP 1.1 client.
	SwingLibrary	Library for testing Java applications with Swing GUI.
	watir-robot	Web testing library that uses Watir tool.
OTHER	Creating test libraries	Creating test libraries section in Robot Framework User Guide.
	plone.app .robotframework	Provides resources and tools for writing functional Selenium tests for Plone CMS and its add-ons.
	JavalibCore	Base for implementing larger Java based test libraries for Robot Framework.
	Remote	Built-in special library acting as a proxy between Robot Framework and test libraries elsewhere. Actual test libraries can be running on different machines and be implemented    using any programming language supporting XML-RPC protocol.
	RemoteApplications	Special test library for launching Java applications on a separate JVM and taking other libraries into use on them.

(E, K) Robot framework, RIDE 2 - How to write good test cases using Robot Framework(Robot Framework에서 좋은 테스트 케이스는 어떻게 만드는가)

Introduction

• These are high-level guidelines for writing good test cases using Robot Framework.
  • How to actually interact with the system under test is out of the scope of this document.
• Robot Framework에서 좋은 테스트 케이스를 작성하는 추상화가 높은 가이드라인입니다.
• 시스템과 연계하는 것 까지는 이 문서에서 설명하지 않습니다.
• Most important guideline is keeping test cases as easy to understand as possible for people familiar with the domain.
  • This typically also eases maintenance.
• 가장 중효한 가이드 라인은 테스트 케이스를 이해하기 쉽게 만들어 사람들을 이 부분에 친숙하도록 만드는 것입니다.
• 이해하기 쉽도록 하면 유지보수하기도 쉬워 집니다.
• For more information about this subject, you may want to take a look at these great resources:
  • Robot Framework Dos and Don'ts slides that are based on this how-to.
  • Writing Maintainable Automated Acceptance Tests article by Dale Emery.
  • How to Structure a Scalable And Maintainable Acceptance Test Suite blog post by Andreas Ebbert-Karroum.
• 이 주제로 조금 더 많은 정보는, 아래의 대단한 리소스들에 있습니다:
• Robot Framework에서 할 것, 하지 않을 것 이 내용에 기반한
• 유지보수 쉬운 자동화 인수테스트를 쓰는 법 article by Dale Emery.
• 확장성과 유지보수가 쉬운 인수 테스트 모음을 어떻게 구조화 하는가 blog post by Andreas Ebbert-Karroum.

Naming

Test suite names

• Suite names should be as describing as possible.
• Names are created automatically from file or directory names:
  • Extensions are stripped.
  • Underscores are converted to spaces.
  • If name is all lower case, words are capitalized.
• Names can be relatively long, but overly long names are not convenient on the file system.
• The name of the top level suite can be overridden from the command line using the --name option if needed.

Examples:

• login_tests.robot -> Login Tests
• IP_v4_and_v6 -> IP v4 and v6

Test case names

• Test names should be describing similarly as suite names.
• If a suite contains many similar tests, and the suite itself is well named, test names can be shorter.
• Name is exactly what you you specify in the test case file without any conversion.

For example, if we have tests related to invalid login in a file invalid_login.robot, these would be OK test case names:

*** Test Cases ***
Empty Password
Empty Username
Empty Username And Password
Invalid Username
Invalid Password
Invalid Username And Password

These names would be somewhat long:

*** Test Cases ***
Login With Empty Password Should Fail
Login With Empty Username Should Fail
Login With Empty Username And Password Should Fail
Login With Invalid Username Should Fail
Login With Invalid Password Should Fail
Login With Invalid Username And Invalid Password Should Fail

Keyword names

• Also keyword names should be describing and clear.
• Should explain what the keyword does, not how it does it.
• Very different abstraction levels (e.g. Input Text or Administrator logs into system).
• There is no clear guideline should a keyword be fully title cased or should only the first letter is capitalized.
  • Title casing often used when the keyword name is short (e.g. Input Text).
  • Capitalizing just the first letter typically works better with keywords that are like sentences (e.g. Administrator logs into system). These keywords are often also higher level.

Good:

*** Keywords ***
Login With Valid Credentials

Bad:

*** Keywords ***
Input Valid Username And Valid Password And Click Login Button

Naming setup and teardown

• Try to use name that describes what is done.
  • Possibly use an existing keyword.
• More abstract names acceptable if a setup or teardown contain unrelated steps.
  • Listing steps in name is duplication and a maintenance problem (e.g. Login to system, add user, activate alarms and check balance).
  • Often better to use something generic (e.g. Initialize system).
• BuiltIn keyword Run Keywords can work well if keywords implementing lower level steps already exist.
  • Not reusable so best used when certain a setup or teardown scenario is needed only once.
• Everyone working with these tests should always understand what a setup or teardown does.

Good:

*** Settings ***
Suite Setup     Initialize System

Good (if only used once):

*** Settings ***
Suite Setup     Run Keywords
...             Login To System    AND
...             Add User           AND
...             Activate Alarms    AND
...             Check Balance

Bad:

*** Settings ***
Suite Setup     Login To System, Add User, Activate Alarms And Check Balance