TrueSTUDIO内でエディターを開いた場合、外部エディターに飛べますか？

 TrueSTUDIO内でエディターを開いた場合、外部エディターに飛べますか？

以下の操作で外部エディタに飛ぶことが出来ます。 

 Window > Preferences, フィルターを使い“file associations”をサーチする。 .c/.cpp の拡張子までスクロールして選択。“associated editor” がしたのフィールドに現れることを確認する。もしなければ“Add”を押下してください。

インストール時に必要な条件

インストール時に必要な条件

インストールには以下の条件が必要になります。

•1 GB RAM

• 1,6 GB のHDDスペース

• Network card

• ライセンス登録のためのインターネットアクセス

• Installation keyを受信するためのメールアカウント

動作環境は？

必要なスペックは？

動作環境は以下のもので確認が取れております。

• Microsoft® Windows® XP

• Microsoft® Windows ®Vista (32-bit version)

• Microsoft® Windows® Vista (64-bit version)

• Microsoft® Windows® 7 (32-bit version)

• Microsoft® Windows® 7 (64-bit version)

Different types of code coverage analysis:コードカバレッジ解析の様々なタイプ　

Types of code coverage analysis

Code coverage analysis is used to measure the quality of software testing, usually using dynamic execution flow analysis.

There are many different types of code coverage analysis, some very basic and others that are very rigorous and complicated to perform without advanced tool support. To explain how the different types of code coverage analysis works, let's consider the trivial code example below:

As we can see, this code section contains a red code block that is always executed, a green code block that is sometimes executed (dependent on the result of the if-statement), and a blue code block that is always executed. This can be visualised as an execution flow graph.

The execution flow graph above shows that this trivial code section contains two different execution paths:

One execution path runs the red code block and then jumps directly to the blue code block and runs that too (the if-statement evaluates to false).

The other execution path runs the red code block, jumps to the green code block and runs that, and finally, it jumps to the blue code block and run that too (the if-statement evaluates to true).

Statement coverage and block coverage

This very basic type of code coverage analysis is sometimes included in embedded debuggers. Statement coverage can only report whether a statement has been executed or not, which potentially leaves many types of code constructs (in particular execution branches) untested. A variant of Statement coverage is Block coverage, that provides the same measurement based on code blocks instead of statements.

Function coverage

This basic type of code coverage analysis is sometimes included in standard debuggers too. Function coverage can only report whether a function has been called or not, it does not say anything about what was executed inside it, or how or why the function was called. And it does not measure how many of the function calls that are made.

Function call coverage

Function call coverage measures how many of the available function calls have actually been made. For example, a code section might make many function calls. To reach 100% Function call coverage, every function call in the code section must be executed at least one time. If a call to a function is made, it is implied that function coverage is fulfilled for that function too (if it is called, it is executed too).

Branch coverage

Branch coverage is an advanced type of code coverage, that requires that all code blocks and all execution paths have been taken. As such it builds on top of statement or block coverage, adding more advanced requirements.

To fulfill Branch coverage for the code example above, the code must be executed minimum two times; one time with the if-statement evaluating to false, and another time with the if-statement evaluating to true. Only then have all the code blocks and all the execution paths been tested.

Also note that Branch coverage only considers the overall branch decision in the if-statement (i.e. that both if-true and if-false are tested). But it does not consider how the expression evaluated to true or false, i.e. it does not consider the subexpressions forming the overall branch decision.

Modified condition/decision coverage

Modified condition/decision coverage (MC/DC) is a very advanced type of code coverageanalysis. It builds on top of Branch coverage, and as such, it too requires that all code blocks and all execution paths has been tested.

But it adds the requirement that all sub-expressions in complex branch expressions must be considered too. MC/DC requires that all sub-expressions have been shown to, independently of other sub-expressions, drive the overall branch decision.

Effectively, this means that the code section above must be executed many times, such that all subexpressions have been the tested to independently of the others, be the driving decision factor in the overall branch decision.

Safety-critical software is often required to be tested such that it fulfills MC/DC-level code coverage analysis successfully. RTCA DO-178B for example, requires MC/DC-level testing of airborne software of "Level A" criticality, which is the most safety-critical part of airborne software, such as the flight control or avionics system.

But any software project benefit from rigorous code coverage analysis, such as:

• Companies who want to avoid bad reputation on the market by releasing products of poor quality
• Products that are very difficult or expensive to upgrade in the field
• Products that are produced in very high volume
• Safety-critical or semi-safety-critical products

Summary

Atollic TrueANALYZER® is a very powerful tool for code coverage analysis, as it performs test quality measurements using dynamic execution flow analysis of your application as it runs in your target board.

Atollic TrueANALYZER® performs Block coverage, Function coverage, Function call coverage, Branch coverage as well as Modified condition/Decision coverage (MC/DC). The tool us super-simple to use, as it only requires two mouse clicks to perform a full MC/DC test in your target board!