Robot Framework에 익숙해 지기 위해서 관련 페이지를 한글 옮겨 보았습니다.


Robot Framework is a generic test automation framework for acceptance testing and acceptance test-driven development (ATDD).

Robot Framework는 인수 테스트와 인수 테스트 기반 개발의 테스트 자동화를 위한 프레임워크이다.

It has easy-to-use tabular test data syntax and it utilizes the keyword-driven testing approach. 
다루기 쉬운 표 형태의 문법을 사용하며, 키워드 기반의 테스트를 가능하도록 한다.

Its testing capabilities can be extended by test libraries implemented either with Python or Java, and users can create new higher-level keywords from existing ones using the same syntax that is used for creating test cases.
파이썬이나 자바로 구현된 테스트 라이브러리 를 사용하며, 테스트 케이스를 만들 때 사용한 문법과 동일한 방법으로 추상성을 높인 키워드(사람이 이해하기 쉬운) 를 만들어 사용할 수도 있다.

Robot Framework project is hosted on GitHub where you can find further documentation, source code, and issue tracker. Downloads are hosted at PyPI. The framework has a rich ecosystem around it consisting of various generic test libraries and tools that are developed as separate projects.
Robot Framework 프로젝트는 GitHub에 위치하고 있으며, GitHub 에서 관련 문서, 소스 코드, 이슈 트래커들을 찾아볼 수 있다. 다운로드는 PyPI(Python Package Index, Python Package들을 다운받을 수 있게 모아놓은 싸이트)에서 가능하다. 이 Robot Framework는 풍부한 라이브러리들과 툴들이 여러 프로젝트들에서 개발되고 있다.

Robot Framework is operating system and application independent. The core framework is implemented using Python and runs also on Jython (JVM) and IronPython (.NET).
Robot Framework는 운영체제, 어플리케이션에 독립적이다. 주요 Framework(뼈대)는 파이썬으로 구현되었으며 Jython (JVM) 이나 IronPython (.NET) 을 사용해서도 실행될 수 있다.

RIDE is a test data editor for Robot Framework test data.
RIDE는 Robot Framework 를 위한 테스트 데이터 에디터 이다.(Robot framework IDE 정도인듯)

Robot Framework itself is open source software released under Apache License 2.0, and most of the libraries and tools in the ecosystem are also open source. The development of the core framework is supported by Nokia Networks.
Robot Framework 는 오픈 소스이며 Apache License 2.0, 라이센스를 따른다. 대부분의 라이브러리와 툴 들이 역시 오픈 소스이다. 중요 뼈대는 Nokia Networks. 에서 진행하였다.



Robot Framework는 크게 3가지 특징이 있는데
Clear, Easy, Modular 이다.

Clear.


Robot Framework has a modular architecture that can be extended with bundled and self-made test libraries.
Test data is defined in files using the syntax shown in the examples below. A file containing test cases creates a test suite and placing these files into directories creates a nested structure of test suites.
Robot Framework는 모듈러 구조이기 때문에 사용자 작성 테스트 라이브러리를 만들 수가 있다.
테스트 데이터는 아래 example 문법을 따라서 작성된 파일 안에 정의되어 있다. 테스트 케이스가 작성된 파일에는  폴더 구조로서 내부적으로 반복되는(트리 구조 같이) 테스트 모음을 구성할 수 있게 된다.

Example
*** Settings ***
Documentation     A test suite with a single test for valid login.
...
...               This test has a workflow that is created using keywords in
...               the imported resource file.
Resource          resource.txt

*** Test Cases ***
Valid Login
    Open Browser To Login Page
    Input Username    demo
    Input Password    mode
    Submit Credentials
    Welcome Page Should Be Open
    [Teardown]    Close Browser
                    
Let's start with a real-life example from our web demo project. Here we have a test suite with one test case which tests that login is valid. As you can see, test data syntax is based on keywords.
Keywords are composable, meaning you can define new keywords that use pre-existing keywords. This way, you can abstract details of testing to something that makes immediate sense; for example, we don't need to know what exactly the step Submit Credentials actually does, unless we want to. Test cases are therefore clear and readable, with just the right level of abstraction to convey the intent of the test, rather than the nuts and bolts.
See next example for what you're going to get once this example is run!
위의 실제 삶과 관련된 예제(web demo project에 쓰인)를 가지고 생각해 보자. 여기 테스트 모음이 있고 거기에는 하나의 테스트 케이스가 있다. 보이느느 바와 같이 문법은 Keyword를  기본으로 되어있다. 
Keyword 들은 기존에 존재하던 Keyword 들을 사용한 새로운 조합으로 새롭게 만들어낼 수도 있다. 이런 방법으로, 추상화(사람의 언어같이 알아보기 쉽도록) 할 수 있다. 예를 들어, SUBMIT CREDENTALS(자격 증명을 제출한다) 라는 단어가 실제 어떠한 일을 하는지는 알 필요가 없다.  그래서 테스트 케이스들은 의도에 알맞게 추상화가 되었다면, 알아듣기 쉽고, 읽어 이해하기 쉽다.


Easy.


When test execution is started, the framework first parses the test data. It then utilizes keywords provided by the test libraries to interact with the system under test. Libraries can communicate with the system either directly or using other test tools as drivers.

Test execution is started from the command line. As a result you get report and log in HTML format as well as an XML output. These provide extensive look into what your system does.
테스트가 시작되면, framework는 테스트 데이터를 먼저 분석한다. 그리고 키워드 들이 테스트 라이브러리를 바탕으로 실행될 수 있도록 한다. 라이브러리들은 시스템과 직접 혹은 테스트 툴을 통해서 사용될 수가 있다. 
테스트 실행은 명령 라인을 통해서 시작된다. 테스트의 결과로 테스트 리포트와 로그가 HTML 포맷과 XML 포맷으로 얻어진다.  이 것들은 시스템이 어떻게 동작하는지를 큰 틀에서 볼 수 있도록 한다.


Modular.


Robot Framework architecture
위 형태와 같이 모듈화가 되어있다.

History

The basic ideas for the Robot Framework were shaped in the Pekka Klärck's masters thesis[2] in 2005. The first version was developed at Nokia Siemens Networks the same year. Version 2.0 was released as open source software June 24, 2008 and version 2.8.4 was released February 7, 2014.[3]
The framework is written using the Python programming language and has an active community of contributors. It is released under Apache License 2.0 and can be downloaded from robotframework.org
Robot Framework는 가장 기본적인 아이디어는 2005년 Pekka Klärck[2]의 석사 논문에서 만들어 졌다. Nokia Siemens Networks에서는 첫번째 결과물을 같은 년도에 만들어 내었다. 2.0 버전은 오픈소스로 2008년 7월 24일 릴리스 되었고 2.8.4 버전은 2014년 2월 7일에 릴리스 되었다. Framework는 파이썬 언어(열정적인 컨트리뷰터가 많은)로 제작되었다. Apache License 2.0 라이센스이며 다운로드는 robotframework.org 에서 받을 수 있다.




참조


 As a co-designer of one of the world's most popular programming languages, one of the more frustrating behaviours I regularly see (both in the Python community and in others) is influential people trying to tap into fears of "losing" to other open source communities as a motivating force for community contributions. (I'm occasionally guilty of this misbehaviour myself, which makes it even easier to spot when others are falling into the same trap).
세계에서 가장 유명한 프로그래밍언어의 co-designer로서, 주기적으로 (Python community나 다른 프로그래밍 관련된 곳에서) 볼 수 있는 힘빠지는 광경은, 다른 커뮤니티가 더 잘나갈 수 있수도 있다고 겁을 주어 커뮤니티 기여자가 커뮤니티에 기여할 수 있도록 만들려고 하는 것 이다.(때때로 나도 이런짓을 했습니다, 다른사람이 쉽게 기여하지 않을 때 쉽게 사용할 수 있기 때문입니다.)


 While learning from the experiences of other programming language communities is a good thing, fear based approaches to motivating action are seriously problematic, as they encourage community members to see members of those other communities as enemies in a competition for contributor attention, rather than as potential allies in the larger challenge of advancing the state of the art in software development. It also has the effect of telling folks that enjoy those other languages that they're not welcome in a community that views them and their peers as "hostile competitors".
 다른 프로그래밍 언어의 커뮤니티에서의 경험으로 배우는 것은 좋은 것인데,  커뮤니티 멤버들로 하여금 다른 커뮤니티의 사람들을 소프트웨어 개발의 수준을 예술의 수준까지 끌어올리는 발전을 위한 잠재적인동맹의 관계로 생각하는 것이 아니라, 경쟁에서의 적으로 삼고 그 두려움을 기반으로 동기부여로 하는 것은 문제가 있어 보인다.


 In truth, we want there to be a rich smorgasboard of cross platform open source programming languages to choose from, as programming languages are first and foremost tools for thinking - they make it possible for us to convey our ideas in terms so explicit that even a computer can understand them. If someone has found a language to use that fits their brain and solves their immediate problems, that's great, regardless of the specific language (or languages) they choose.
 실제로, 우리는 선택이 풍부한 뷔페와 같이 서로다른 환경에서도 잘 돌아가는 여러가지 언어가 존재하기를 바란다. 프로그래밍 언어는 생각을 도와주는 도구이기 때문이다. - 프로그래밍 언어는 우리가 아이디어를 잘 표현할 수 있도록 하여 결국 컴퓨터 까지도 이해할 수 있도록 해준다. 만약 어떤 사람이 자신에게 주어진 문제를 잘 풀 수 있는, 자신에게 맞는 언어를 찾았다고 한다면 그 언어가 무엇이었든, 그건 엄청난 것이다..


So I have three specific requests for the Python community, and one broader suggestion. First, the specific requests:
 그래서 난 Pyhon 커뮤니티에 구체적인 3가지의 요청사항과 하나의 큰 제안이 있다.
3가지의 구체적인 요청사항은

1. If we find it necessary to appeal to tribal instincts to motivate action, we should avoid using tribal fear, and instead aim to use tribal pride. When we use fear as a motivator, as in phrasings like "If we don't do X, we're going to lose developer mindshare to language Y", we're deliberately creating negative emotions in folks freely contributing the results of their work to the world at large. Relying on tribal pride instead leads to phrasings like "It's currently really unclear how to solve problem X in Python. If we look to ecosystem Y, we can see they have a really nice approach to solving problem X that we can potentially adapt to provide a similarly nice user experience in Python". Actively emphasising taking pride in our own efforts, rather than denigrating the efforts of others, helps promote a culture of continuous learning within the Python community and also encourages the development of ever improving collaborative relationships with other communities.
1. 만약 커뮤니티에 동기부여가 필요하다고 생각되면, 커뮤니티에 대한 두려움을 사용하는 것은 피해야 한다. 대신에 커뮤니티의 자부심을 이용해야 한다. "만약에 우리가 뭘 하지 않는다면 다른 언어인 'y'에 개발자들의 마음을 빼앗기고 말 것이다." 와 같은 말을 통하여 두려움을 자극 한다면, 그것은 부정적인 감정을 유발하게 될 것이다. "지금은 X 라는 Python의 문제를 어떻게 풀 것인지를 모르지만 Y라는 환경을 보면 X 문제 해결을 위한 정말 훌륭한 방법을 발견할 수 있을 것이며 이것은 Python에 그와 비슷한 좋은 경험을 제공할 수 있을 것이다." 와 같이 다른 사람들의 노력을 폄하 하는 것이 아니라 능동적으로 우리의 노력에 자부심을 가지게 된다면, Python 커뮤니티 안에서는 지속적인 배움과 같은 문화를 퍼트리는데 도움이 되고 다른 커뮤니티와의 협업관계도 발전시킬 수 있을 것이다.


2. Refrain from adopting attitudes of contempt towards other open source programming language communities, especially if those communities have empowered people to solve their own problems rather than having to wait for commercial software vendors to design to address them. Most of the important problems in the world aren't profitable to solve (as the folks afflicted by them aren't personally wealthy and don't control institutional funding decisions), so we should be encouraging and applauding the folks stepping up to try to solve them, regardless of what we may think of their technology choices.
2. 다른 언어의 오픈소스 커뮤니티에서 배우는 것을 경멸하는 것을 삼가해 달라, 그리고 그 문제를 푸는것에 대해 상용 소프트웨어를 기다리게 하지 말고 자율권을 주어라. 많은 중요한 문제들은 해결한다고 해서 이익이 주어지는 것이 아니다(그 문제를 겪고 있는 사람들은 부자가 아니다.) 그래서 우리는 어떤 방법을 선택 하든지 간에 직접 해결하고 즐거워 하기를 바란다.


3. If someone we know is learning to program for the first time, and they choose to learn a language we don't personally like, we should support them in their choice anyway. They know what fits their brain better than we do, so the right language for us may not be the right language for them. If they start getting frustrated with their original choice, to the point where it's demotivating them from learning to program at all, then it makes sense to start recommending alternatives. This advice applies even for those of us involved in improving the tragically bad state of network security: the way we solve the problem with inherently insecure languages is by improving operating system sandboxing capabilities, progressively knocking down barriers to adoption for languages with better native security properties, and improving the default behaviours of existing languages, not by confusing beginners with arguments about why their chosen language is a poor choice from an application security perspective. (If folks are deploying unaudited software written by beginners to handle security sensitive tasks, it isn't the folks writing the software that are the problem, it's the folks deploying it without performing appropriate due diligence on the provenance and security properties of that software)

3. 만약에 우리가 아는 누군가가 처음으로 프로그램을 배우려고 한다면, 그리고 그들이 우리가 좋아하지 않는 언어를 선택했다고 할 지라도, 우리는 그들의 선택을 있는 그대로 지지해 주어야 한다. 그들은 그들 자신에게 어떠한 언어가 더 적절한지 더 잘알고 있다. 그러므로 우리에게 적절한 언어는 그들에게는 적절하지 않을 수 있다. 만약 그들이 그들 자신의 선택에 좌절하게 되고 그로 인해 프로그래밍을 배우려는 의지가 꺽이게 된다면, 그 때 다른 적절한 것을 추천하는 것은 의미가 있다. 이런 조언은 네트워크 보안에 적절치 않다는 것을 발견하고 나서 바꾸는 것과 비슷하다. 본질적으로 안전하지 않은 언어를 OS를 가지고 감싼다던가, 안전한 다른 언어를 가지고 온다던가로 해결할 수 있다. (만약 초보자가 사용한 확인되지 않은 소프트웨어가 배포되었다고 하면 사용하는 사람이 문제가 아니라 제대로 확인하지 않고 배포한 사람이 문제이다.)


 My broader suggestion is aimed at folks that are starting to encounter the limits of the core procedural subset of Python and would hence like to start exploring more of Python's own available "tools for thinking".
 나는 사람들이 Python의 한계를 만나도록 하여 Python 을 더 발전시킬 가능성을 찾았으면 한다(?)


 One of the things we do as part of the Python core development process is to look at features we appreciate having available in other languages we have experience with, and see whether or not there is a way to adapt them to be useful in making Python code easier to both read and write. This means that learning another programming language that focuses more specifically on a given style of software development can help improve anyone's understanding of that style of programming in the context of Python.
 Python의 개발에 있어서 중요한 과정의 하나는, 다른 언어들을 배우고 그 특징을 Python 에 적용하여 사용하기 쉽게 만드는 것이다. 이것은 다른 언어를 배운다는 것은 Python 프로그래밍을 더욱 잘 이해하게 만드는 것이다.


To aid in such efforts, I've provided a list below of some possible areas for exploration, and other languages which may provide additional insight into those areas. Where possible, I've linked to Wikipedia pages rather than directly to the relevant home pages, as Wikipedia often provides interesting historical context that's worth exploring when picking up a new programming language as an educational exercise rather than for immediate practical use.
 그런 노력을 돕기 위하여, 탐험해볼 몇가지의 영역들을 리스트 해 보았다, 그리고 그것들은 추가적인 통찰을 제공해 줄 것이다. 가능하면 직접적인 해당 언어의 홈페이지가 아니라 위키피디아의 페이지들을 소개함으로서, 실질적인 프로그래밍에 바로 들어가는 것이 아니라 위키피디아가 제공하는 역사적인 것을 경험해 봄으로 인한 교육적인 효과를 줄 수 있도록 하였다.

While I do know many of these languages personally (and have used several of them in developing production systems), the full list of recommendations includes additional languages that I only know indirectly (usually by either reading tutorials and design documentation, or by talking to folks that I trust to provide good insight into a language's strengths and weaknesses).
 이 언어들을 개인적으로 사용했지만(실제 생산에 참여해 보았다), 간접적으로만 체험해 본것들도 있다. (튜토리얼을 읽었거나 디자인 문서를 읽었거나 통찰을 가졌다고 하는 사람들과 얘기해서 들은것들)


 There are a lot of other languages that could have gone on this list, so the specific ones listed are a somewhat arbitrary subset based on my own interests (for example, I'm mainly interested in the dominant Linux, Android and Windows ecosystems, so I left out the niche-but-profitable Apple-centric Objective-C and Swift programming languages, and I'm not familiar enough with art-focused environments like Processing to even guess at what learning them might teach a Python developer). For a more complete list that takes into account factors beyond what a language might teach you as a developer, IEEE Spectrum's annual ranking of programming language popularity and growth is well worth a look.
 여러 다른 언어들이 여기의 리스트에서 빠져 있다. 여기에 나열되어 있는 것은 내가 관심이 있었던 것들 위주이다.(나는 주로 Linux, Android, Windows 에 관심이 있다. 그래서 애플중심의 C나 Swift언어나 Processing과 같은 것은 잘 모른다.) 도움이 되는 더욱 완벽한 리스트를 찾는다면 IEEE의 연간 프로그래밍 언어 순위를 확인해 보는것도 좋을 것 같다.




* 이 글은 Python 언어의 공동 설계자인 

* reference
http://www.curiousefficiency.org/posts/2015/10/languages-to-improve-your-python.html


많은 경험을 가진 프로그래머가 프로그래밍 언어를 개별 언어가 아닌 숲의 관점에서 구분해 놓은 것을 보는 것은 큰 의미를 가진다고 생각합니다.

3개의 내용으로 구분하였으며,
1. Abstract(이 글)
2. Intro
3. 각 언어별 세부 설명(작성되지 않음)
이며 원글의 링크 공유드립니다.

관련 검색 시 찾은 다른 분류
 - 링크1 System Languages, Architectural Languages, Architectural Languages


27 Languages
절차지향 프로그래밍 언어로서 위에서 아래로 순서대로 실행된다는 의미이며, 함수를 사용하여 함수를 따라서 실행될 수 있다.
 현실세계의 모습을 나타낼 수 있는 객체들의 조합으로 프로그래밍을 하는 언어
  객체지향의 의미를 가지고 있지만 C와 유사한 방식(?)으로 구현
  데이터를 Array형태로 다루는 언어이며 Array에서 Matrix까지 여러 차원의 데이터를 한꺼번에 다루며 이때 숫자형태를 주로 다루기 때문에 계산에 뛰어난 특징을 가진다.
  통계적으로 분석(Analyze)하며 그것을 눈에 보여주는(Visual) 에 특화되어 있는 언어.
  통계에 집중되어 개발된 언어를 살펴보면 Python에서도 통계쪽 강화를 위해서 습득할 수 있는 부분이 있을 것이라고 생각.
 함수형 언어를 의미하며 컴퓨터가 동작하는 방식에 최적화된 언어를 의미한다.
 특정한 이벤트가 들어올 때 까지 지속적으로 프로그램이 돌아가도록 하는 프로그램을 만들도록 특화된 언어. Back Ground에서 프로그램은 계속 켜져있어야 하기 때문에 보통 여러명의 유저를 받을 수 있도록 발전되어 있다.
 변수를 정적이 아니라 동적으로도 만들어서 사용할 수 있는 언어. 파이썬에도 3.5버전부터 이 개념이 적용 되었다.
 Code 자체를 Data로 사용할 수 있는 특징을 가지는 언어(아직 이해 부족)
 실질적인 특정 문제를 해결하기 위하여 발전한 언어
초보자들(그리고 어린이들)에게 컴퓨터가 동작하는 방식을 익힐 수 있도록 고안된 언어


+ Recent posts