2016년 6월 5일 일요일

자연철학에 대한 이해 - 일러스트 철학 사전


옛날 사람들은 신이 자연(세계)을 만들었다고 믿었고 신화로 자연의 성립을 이해했다.

다양한 기술이 발달하면서 삶이 풍족해졌다. 인구가 늘어났고 다른 지역과 교류가 활발해졌다.

그러다 지역에 따라 자연의 성립을 설명하는 신화가 다르다는 것을 알게 됐다.

그래서 누구나 인정할 만한 만물의 근원을 생각하게 됐다. 탈레스는 만물의 근원이 이라 했고 아낙시메스는 공기라고 했다. 이때 근원이 물인지 공기인지는 중요하지 않다. 만물의 근원을 신화로 설명하지 않고, 이성적으로 생각해 자연에서 근원을 찾으려는 새로운 사고방식이 중요하다. 이것이 자연철학의 시작이다.

「한눈에 보고 단숨에 읽는 일러스트 철학사전」 다나카 마사토


고대 철학 중 가장 초기에 나타난 자연철학을 쉽게 설명해 주었습니다.

이 책에는.. 고대 탈레스부터 현대 AI 시대의 생명윤리까지 87명의 철학자와 187개의 철학 사상을 위와 같이 정말 간략하게.. 그리고 그림까지 덧붙여서 설명해 줍니다.

묻지말고 사야하는 책! 인거 같습니다.

자연철학의 설명으로 돌아가면.. 인간의 한계를 인식하고 거대한 신이라는 존재가 있을 것이라고 생각하던 시간과.. 인간의 한계를 극복해 가면서 새롭게 알게된 사실들에 적응해 가는 과정에서 새로운 철학들이 나타났습니다.

이전에 한번 정의되고 굳세게 믿고 살았던 사실이라도 시간이 지나면 재 평가를 받아야 합니다.

인간의 지혜는 완전하지 않으므로 아집을 가지고 살지 말고, 마음을 열어놓고 살아 갔으면 합니다.


(K, E)Python Module Dependency Graphs Example(종속성 그래프 예제)


Contents
    file1~5, Console Command, Result

file1
file2

file3

file4

file5

Console Command
python py2depgraph.py file1.py | python depgraph2dot.py | dot -T png -o result.png

Note
Some built in Libraries(ex> Serial) make py2depgraph.py script error. I don't know the root cause. In that case, that library need to be commented or replace to blank library which has same name to appear in dependency graph. I made another 20 scripts related dependency graph, so this method works file.
기본 라이브러리(예를 들어 Serial)들이 py2depgraph.py 스크립트를 실행하다 에러가 발생하는 경우가 있습니다. 정확한 이유는 모르지만 처리과정에 문제가 있는 것이고, 기본 라이브러리기 때문에 아예 주석으로 바꾸어서 그림에 안나타나게 하거나, 필요 시에는 같은 이름을 가진 .py를 만들어 주면 그림에서 나타나게 할 수 있습니다. 그리고 이 예시 말고 약 20개 python script 로도 dependency graph를 그려보아서 이 방법이 잘 되는 것은 확인 하였습니다.


Result

(E, K)Unified Diagnostic Services 간단한 정리

Unified Diagnostic Services (UDS) specifies data link independent requirements of automotive diagnostic services in road vehicles.[1]
UDS is codified in ISO 14229-1:2013 and allows diagnostics to control functions on an in-vehicle Electronic Control Unit (ECU).
Typical functions ECUs control are electronic fuel injection(EFI), automatic gear box, anti-lock braking system, etc.
all connected to a serial data link embedded in a road vehicle.
The Diagnostic communication over Controller Area Network (DoCAN) is specified in ISO 15765-3[2] and ISO 14229-3.

통합 진단 서비스(UDS) 는 data link independent 한 자동차의 진단 서비스를 의미합니다.
UDS는 ISO 14229-1:2013 에 명시되어 있으며, 진단 명령이 차량의 ECU 를 제어 하게 되어 있습니다.
전형적인 ECU의 기능은 연료 분사(EFI), 자동 변속기, 잠김 방지 브레이크 장치 등이 있습니다.
모두 자동차 안의 시리얼 연결로 연결되어 으며, CAN을 통한 진단 통신(DoCAN)은 ISO 15765-3[2] and ISO 14229-3에 명시되어 있습니다.

Service 리스트
Function group
Request SID
Response SID
Service
Diagnostic and
Communications Management
$10
$50
Diagnostic Session Control
$11
$51
ECU Reset
$27
$67
Security Access
$28
$68
Communication Control
$3E
$7E
Tester Present
$83
$C3
Access Timing Parameters
$84
$C4
Secured Data Transmission
$85
$C5
Control DTC Settings
$86
$C6
Response On Event
$87
$C7
Link Control
Data Transmission
$22
$62
Read Data By Identifier
$23
$63
Read Memory By Address
$24
$64
Read Scaling Data By Identifier
$2A
$6A
Read Data By Identifier Periodic
$2C
$6C
Dynamically Define Data Identifier
$2E
$6E
Write Data By Identifier
$3D
$7D
Write Memory By Address
Stored Data Transmission
$14
$54
Clear Diagnostic Information
$19
$59
Read DTC Information
Input / Output Control
$2F
$6F
Input Output Control By Identifier
Remote Activation of Routine
$31
$71
Routine Control
Upload / Download
$34
$74
Request Download
$35
$75
Request Upload
$36
$76
Transfer Data
$37
$77
Request Transfer Exit
$38
$78
Request File Transfer

Input / Output Control
This service allows an external system intervention on internal / external signals via the diagnostic interface.
By specifying a so-called option bytes additional conditions for a request can be specified, the following values are specified:
이 서비스는 외부 시스템이 진단 인터페이스를 이용하여 내부 혹은 외부 시그널에(버스에 정의된 기본 시그널을 의미 하는 듯) 접근 하는 것을 허용한다. 소위 option byte의 추가 조건 이라고 불리는 것으로 요청을 할 수 있게 된다. 아래 값들이 정의 된다.

ReturnControlToECU: The device must get back controls of the mentioned signals.
해당 장치는 언급된 시그널들로 돌아가야 한다.
ResetToDefault: The tester prompts to reset signals to the system wide default value.
시그널 들을 초기 값으로 돌아가게 만들어야 한다.
Freeze Current State: The device shall freeze the current signal value.
현재 시그널이 가진 값들을 그대로 유지하게 한다.
ShortTermAdjustment: The device shall use the provided value for the signal
장치는 제공받은 값으로 시그널을 사용해야 한다.(짧은 기간이라는 말은 일정 기간만 이라는 뜻인지)

Remote Activation of Routine
The Control service routine services of all kinds can be performed. There are three different message types:
With the start-message, a service can be initiated. It can be defined to confirm the beginning of the execution or to notify when the service is completed.
With the Stop message, a running service can be interrupted at any time.
The third option is a message to query the results of the service.
The start and stop message parameters can be specified. This makes it possible to implement every possible project-specific service.
*. 이 Control Routine 을 사용한다는 것은 해당 작업이 시작, 정지, 결과 읽기의 기본 명령들을 실행할 만한 셩격일 때 하는 것인지.



참조: 위키피디아












































2016년 6월 4일 토요일

(E, K)Generating Python Module Dependency Graphs(종속성 그래프 생성하기)

I studied how to draw dependency graph from the website. I translated it below to understand correctly.
my own example is on another post.
python 파일들의 dependency graph를 그리기 위해서 인터넷 검색을 통해 잘 설명해 준 싸이트를 찾았고, 해 보았습니다. 아래는 이해를 제대로 하기 위해 번역해 놓은 글 입니다. 제가 직접 구현한 간단한 예제는 다른 포스트에 기록 했습니다.


Controlling physical dependencies is an important part of any software architecture. We noticed a shortage of tools for analyzing Python program when we started work on 'Tintag Explorer', and the tools described here were created as a result.
물리적인 의존관계를 파악하고 제어하는 것은 소프트웨어 구조에서 중요한 부분입니다. 우리는 Python 에서 이런 의존관계를 분석하는 툴이 부족한 것을 인지하여 Tintag Explorer 의 의존관계 분석하는 툴을 직접 만들어 보았습니다.

Below is a shrunken version of the dependency graph from several subsystems of the current development version of Tinytag Explorer; 4.3. The __main__ module is the small dark blue circle at the top. Other circles are other modules. The lines are arrows (although you cant see the arrow-heads in this shrunken version) that indicate that one module imports another. All arrows point down, unless there are cyclic imports.
아래는 Tinytag Explorer 4.3버전에 대한 의존그래프 입니다. __main__ 모듈은 위쪽에 작은 어두운 파란 동그라미 입니다. 보이는 선들은 화살표이며(비록 이 작은 그림들에서는 화살의 머리가 보이지 않아도) import 된 관계를 나타 냅니다.
모든 화살표는 아래를 향하게 됩니다. 단 cycle 관계여서 서로 import 하는게 아니라면...



We have obtained enormous value from studying automatically generated diagrams such as this. It often highlights:
우리는 자동 다이어그램 생성을 찾아 보면서 많은 것들을 얻었습니다. 이 dependency graph를 통해서 강조해서 알 수 있었던 것은.

● Ill-advised module iorts, as obtrusive diagonal lines across large distances of the diagram.
  문제가 될만한 먼 거리에 보기싫게 사선으로 연결된 관계.
● Modules that might be in the wrong package, as solitary circles on one color surrounded by those of another color.
   잘못된 패키지 안에 있는 모듈들, 예를 들어 혼자 연결되어 있는 것.
● Subsystems that are ideal for reuse in other systems because they have few dependencies. For example, the island of pink on the bottom left of the diagram above has already been reused from another project. [Hi Lawrence.... That's TSG!]
   의존 관계가 적어, 재 사용하기에 좋은 하위시스템들, 예를 들어 아래에서 왼쪽에 핑크색으로 표시된 것처럼.
● Close clusters of modules are often a suitable unit for code review.
   구분되어 져 있는 무리들은 코드 리뷰하기에 적당함

This diagram was generated from a three-step process:
이 다이어그램은 3개의 단계로 나누어 진행 되었습니다.

Step 1: Compute The Dependency Graph
Python's modulefinder module does all the heavy lifting here. modulefinder use bytecode inspection to find dependencies, and therefore is free from any side-effects that may be caused by importing the modules being studied.
파이썬의 modulefinder 모듈이 어려운 일들을 해 줍니다. modulefinder 는 바이트코드 단위에서 의존관계를 확인해 주었고, import 된 것을 확인하는 과정에서 부작용이 없도록 하였습니다.

This py2depgraph.py script will write to stdout the dependency graph raw data for the script named in its first parameter.
py2depgraph.py 스크립트 첫번째 파라미터가 된 파일에 대한 의존 관계를 간단한 text 버전으로 보여 줍니다.

Step 2: Format The Dependency Graph
In step 3 we will be passing our data into dot, part of graphviz In step 2 we need to convert the raw dependency data generated in step 1 into the correct format, and apply any presentation logic.
2번째 단계에서는 1단계에서 나온 의존관계를 그래프 그리기 알맞는 dot형태로 변경하고, 3번째 단계에서 dot 형태의 그래프를 graphviz로 보내 그림으로 보여질 수 있도록 합니다.

In simple cases you can use depgraph2dot.py as-is. It receives the raw data in standard input, and provides the generated dot file on standard output.
간단한 관계에선 depgraph2dot.py를 그대로 사용하면 됩니다. 입력값으로 기본 text 포맷을 받아들이며 dot파일의 형태로 아웃풋을 만들어 줍니다.

For the best presentation you will need a little programming. Create a subclass of the class defined in this module, override some methods that apply presentation logic, then call the main() method of one of those objects. The following aspects of the presentation can be customised:
최적으로 보여주기 위하여 약간의 프로그래밍이 필요 합니다. 여기서 만들어진 클래스에 대한 하위 클래스를 만들어서, 프레젠테이션 로직을 오버라이드 해 주고 main 함수를 부르면 됩니다. 프레젠테이션은 수정될 수도 있습니다.

1. Change which modules will be used on the diagram. By default it omits a number of very common modules such as sys that would add uninteresting clutter. It also omits packages (but not the modules within the package). The diagram above has been customized to show a group of application-specific packages.
 어떤 모듈을 그릴 것인지 선택 합니다. 정말 기본적인 모듈들 이나 package 들은 생략합니다(예를 들어 sys).  위의 다이어그램은 application 에 사용되는 것들만 보이도록 손 본 것입니다.

2. Pairs of modules that have a specially close relationship. These relationships are drawn with particularly short straight lines. By default any reference to a module whose name starts with an underscore carries this extra weight, because that usually indicates a special relationship (for example, as between random and _random)
   관계가 밀접한 모듈들은 짧은 라인으로 연결되게 됩니다. 모듈 이름에 밑줄이 그어져 잇는 것들은 특별히 중요한 것들입니다. 특별한 관계이기 때문 입니다.(예를 들어 random 과 _random)

3. Pairs of modules whose relationship should be drawn with an extra long line. This is a good way of separating subsystems - for example the module highlighted in red in the diagram above has extra space above.
   특별히 긴 라인으로 연결되어 있는 모듈들도 있습니다. 이 방법은 하위 시스템들을 구분하는 데 사용됩니다 - 빨간색으로 강조 되어 있는 부분이 그렇습니다.

4. A color. By default the color is assigned automatically with all modules in one package assigned the same color.
  색을 입힙니다. 기본 색은 자동으로 생성되며 같은 패키지것을 사용한 것은 같은 색이 됩니다.

5. A text label, by default the module name.
  텍스트를 모듈의 이름에 근거해서 생성합니다.

Step 3: Generate The Image
You need the dot tool from graphviz. This can generate most image formats. It can also generate postscript ideal for printing. If printing to a black and white printer the --mono switch to depgraph2dot.py will be helpful.
image를 만들기 위해서는 graphviz에 있는 dot 툴이 필요 합니다. 흑백의 출력이 필요하다면 --mono option 을 depgraph2dot.py 명령에 추가하면 됩니다.

Putting those three steps together gives something like:
위에 설명한 3개의 단계는 아래의 명령으로 구현 됩니다.

$ python py2depgraph.py path/to/my/script.py | python depgraph2dot.py | dot -T png -o depgraph.png
$

(Created 2004. Updated December 2009 with python 2.6 fixes)

2016년 5월 29일 일요일

자동차 조향장치 작동원리 - How Car Steering Works (1/2)


목적: pinion steering 의 의미를 알기 위하여 검색하였고, pinion steering 이 사용되는 Steering 전반에 대하여 정리해 두려고 합니다.

Car Steering 은 조향(자동차 방향을 조정하는 것) 을 이야기 하는 것으로 steering wheel(핸들) 을 움직임으로서 바퀴의 방향을 조정하는 것을 말합니다.


How Car Steering Works
자동차의 방향조절 원리는 무엇인가?

You know that when you turn the steering wheel in your car, the wheels turn. Cause and effect, right? But a lot of interesting stuff goes on between the steering wheel and the tires to make this happen.
당신도 이미 알겠지만 차의 핸들(steering wheel)을 돌리면, 바퀴(wheel)이 돈다. 원인이 있으니 결과가 있는 것이다. 하지만 핸들과 타이어 사이에 많은 일들이벌어진다.

In this article, we'll see how the two most common types of c­ar steering systems work: rack-and-pinion and recirculating-ball steering. Then we'll examine power steering and find out about some interesting future developments in steering systems, driven mostly by the need to increase the fuel efficiency of cars. But first, let's see what you have to do turn a car. It's not quite as simple as you might think!
이 글 에서는, 대표적인 자동차 조향장치(steering system)의 동작원리를 알아보려고 한다: '랙과 피니언(rack and pinion)' 과  '볼 순환식(recurculating-ball)' 이다. 이 둘을 알아본 다음에는 파워 스티어링(power steering)과 그 외에 개발되고 있는 장치들을 이야기할 것이다. 이 장치들의 개발은 연료의 효율성에 초점을 맞춰서 발전되고 있다. 하지만 그 전에, 어떻게 차를 돌리는지에 대하여 이야기 해 보자. 생각보다 쉽지 않을 것이다.


You might be surprised to learn that when you turn your car, your front wheels are not pointing in the same direction.
당신이 차를 회전시킬 때, 차의 앞 두 바퀴가 동일한 방향을 가리키지 않는다는것을 알면 놀랄 것이다.

For a car to turn smoothly, each wheel must follow a different circle. Since the inside wheel is following a circle with a smaller radius, it is actually making a tighter turn than the outside wheel. If you draw a line perpendicular to each wheel, the lines will intersect at the center point of the turn. The geometry of the steering linkage makes the inside wheel turn more than the outside wheel.
차가 부드럽게 회전하기 위해서는, 두 바퀴는 서로다른 원을 그려야 한다. 안쪽에 있는 바퀴가 작은 각도로 돌리 때문에, 바깥쪽 바퀴보다 작은 반경의 회전을 하게 된다. 만약에 각 바퀴의 움직임에 대한 선에 직각 선을 그린다면 회전 시에 중심지점에서 만나는 것을 알 수 있을 것이다. 기하학적으로 회전을 연결시키기 위해서 안쪽 바퀴가 바깥쪽 바퀴보다 더 많은 회전을 하게 된다.


1. Rack-and-pinion Steering

Rack-and-pinion steering is quickly becoming the most common type of steering on cars, small trucks and SUVs. It is actually a pretty simple mechanism. A rack-and-pinion gearset is enclosed in a metal tube, with each end of the rack protruding from the tube. A rod, called a tie rod, connects to each end of the rack.
랙앤피니언 은 가장 일반적인 타입의 조향장치이다. 승용차, 작은트럭, SUV에 주로 쓰인다. 동작원리는 비교적 간단하다. rack 과 pinion은 메탈 튜브로 둘로싸인 기어의 조합을 의미한다. rack의 양 끝은 튜브보다 튀어나와 있으며, tie rod 는 두 바퀴를 함께 동작하게 하기 위해 rack의 양 끝을 연결하는 역할을 한다.

The pinion gear is attached to the steering shaft. When you turn the steering wheel, the gear spins, moving the rack. The tie rod at each end of the rack connects to the steering arm on the spindle (see diagram above).
pinion gear는 steering shaft에 붙어 있다. 핸들을 돌리면, pinion gear는 회전하면서 rack을 회전시킨다. rack의 양 끝에 있는 tie rod는 spindle 위의 steering arm에 연결된다.


이후 정리될 내용
 2. Recirculating-ball Steering
 3. Power Steering
 4. Pump
 5. The Future of Power Steering

참조
http://auto.howstuffworks.com/steering.htm
차량 조향장치 링크 부분에 사용되는 부품

2016년 5월 22일 일요일

임베디드 소프트웨어 설계 시 고려해야 할 사항(1/3) - 유연한(flexible) 소프트웨어의 필요성

1.
임베디드 시스템 엔지니어링에는 제약사항이 많다. 여러 제약 중 어떤 제약이 나중에 프로젝트 개발에 문젯거리가 될지를 파악하는 일은 쉽지 않다. 앞으로 발생할 변화를 예측해서 애플리케이션에 발생하는 변화를 충분히 수용할 수 있도록 소프트웨어를 유연하게(flexible) 설계해야 한다.

2.
소프트웨어를 설계할 때 시스템을 좀 더 유연하게 할 수 있는 몇몇 훌륭한 원칙이 있다.

모듈화 원칙을 이용해 하위 시스템별로 기능을 분리하고 각 하위시스템이 사용하는 데이터를 감출 수 있다.

캡슐화 원칙을 이용해 서로에 대해 알지 못하도록 하위 시스템 간의 인터페이스를 만들 수 있다. 하위시스템(또는 객체)의 결합을 약한 상태로 유지하면 한 부분을 고치더라도 다른 부분에 영향을 주지 않을 것이라는 확신을 가질 수 있으므로 쉽게 코드를 고칠 수 있다. 따라서 필요에 따라 일부 시스템을 분리했다가 수정하고 다시 제자리에 넣을 수 있다.

시스템을 어떻게 분리해야 하는지를 잘 판단하려면 연습이 필요하다. 최선의 방법은 독립적으로 변경될 수 있는 부분을 찾는 것이다.

3.
이 원칙들은 이론부터 나온 것이 아니라 컴퓨터나 만들어지고 프로그램을 만들면서 생긴 시행착오에 의해 적립이 된 것으로 이것들을 후에 체계적으로 정리한 것이 디자인 패턴 이다.

4.
디자인 패턴에 관심을 가진지는 오래 되었지만, 제대로 적용해 본적이 없었기 때문에 가장 대표적인 패턴인 MVC(Model, View, Controller) 를 간단한 프로그램을 통해 직접 구현해야 할 필요가 생겼다.


참조:
디자인 패턴을 적용한 임베디드 시스템


2016년 5월 18일 수요일

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 의 석사논문