(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 을 사용한다는 것은 해당 작업이 시작, 정지, 결과 읽기의 기본 명령들을 실행할 만한 셩격일 때 하는 것인지.



참조: 위키피디아

(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)

자동차 조향장치 작동원리 - 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
차량 조향장치 링크 부분에 사용되는 부품

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

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

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

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

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

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

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

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


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

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

내가 성장 가능하다고 생각하는것의 힘! - Carol Dweck: The power of believing that you can improve

현재의 내가 해결하기에는 조금 역부족인 일을 만났을 때 어떻게 생각하시나요?

크게 두 가지 반응을 보입니다.

1. 이거 풀기에는 내 능력이 부족하구나.
2. 아직은 내가 못푸는구나.

둘다 비슷한 반응이라고 생각할 수 있지만
1번은 능력이 부족한 것에 초점을 두는 것이고,
2번은 '아직'은 못풀지만 조금 더 성장하면 풀 수 있다는 것에 초점을 두는 것이라고 합니다.

스탠포드의 캐롤 드웩교수는 이 두가지의 마음가짐이 얼마나 학생들의 미래에 영향을 주는지 여러 연구결과를 통해서 증명해 줍니다.

"어떠한 상황에서도 나는 성장할 수 있습니다!" 라고 몸으로 이해했으면 좋겠네요.


두 유형의 사람 비교

자신의 능력이 성장할 수 있음을	알고 있는 사람	모르고 있는 사람
뇌의 활동	뇌 안의 전기 활동이 활발	뇌 활동이 거의 없음
실수에 대처하는 법	실수를 분석, 실수를 통해 배우고 개선	자신의 실수에서 도피
진학(과목이 어려움) 시 성적 변화	성적이 떨어져도 금방 회복	점점 성적이 떨어짐
어려운 과제에 대한 반응	스스로 멍청하다고 느끼고, 스스로 포기하고 싶게 한다.	머릿속의 뇌세포가 새롭거 더 강한 연결고리를 만드는 과정이라고 인식. 문제가 어려울 때가 똑똑해지고 있는 때라고 인식

아이들에게 성장 가능성을 알려주기 위한 방법
지혜로운 칭찬을 해야 합니다.
지능이나 재능을 칭찬하는 대신,
아이들이 거치는 과정을, 그들의 노력, 계획, 집중, 인내, 향상됨을 창찬해야 합니다.
이런 “과정에 대한 칭찬”은 어려움에 쉽게 굴하지 않는 강인한 아이들을 길러 냅니다.