当前位置:首页 >> 信息与通信 >>

Testing


Testing with CANoe Note, CANoe 学习笔记 2.1 CANoe Test Concept 2.1.1 Architecture CANoe: analysis, simulation component and test. Test sequence: CAPL/.NET program or an XML file(also called CAPL

test modules,.NET test modules, XML test modules). Test modules access the remaining buses simulation

Test Module, Test Group, Test Case, Test step Test Result –Verdicts(pass or fail) Test execution is evaluated on two levels, the level of test cases and the level of entire test module. 2.2 Reporting of Test Results 2.2.1 Overview Hard drive: XML format(convert HTML with the help of a XSLT style sheet) CANoe also support other modes of recording information, so-called Logging Feature.

2.1.2 2.1.3

Manually and automatically generated report information The test description by suitable CAPL/.NET commands (e.g. TestCaseComment) or XML elements, (e.g. <description> in <testmodule> or <testcase>). 2.2.3 Use of identifiers 2.2.4 Test steps The level of detail, An identifier, A description, and a result. Evaluated: pass, fail, warning, none. In CAPL/.NET test modules the user can only define test steps. In XML test modules, tests are defined by the more abstract test functions which output the test steps without user intervention. 2.2.5 Documentation of CAPL programs by test steps 2.3 Formulating test cases in CAPL 2.2.1 Principle MainTest

2.2.2

2.2.2

Setting up a CAPL test module That are identified by the key word testcase, That have no return value, That can have parameters like other functions, Whose call is automatically recorded in the test report (see 2.2.2), and For which CANoe automatically computes a test result, i.e. a verdict (see 2.1.3). The MainTest function is really the “main program” of a test module. A CAPL file with test cases in CAPL may also be assigned to XML test modules as a test case library.

2.2.3

2.2.4 2.2.5 2.2.6 2.2.7

The XML test module only contains the calls with the concrete parameters. Wait commands Sequential execution of a CAPL test program can be interrupted by wait commands. The execution of an event procedure in a CAPL program is not interruptible. Wait commands with complex conditions TestJoin CAPL commands Event procedures in test modules User-defined events Differences between CAPL for simulation/analysis and for testing

2.4

Defining test cases in XML test modules 2.2.1 Principle The most important difference is the way in which test cases are described. In XML test modules test cases are described by a sequence of test functions and control functions. Test functions consist of test primitives and the test patterns. A test pattern contains: ? The actual test sequence, ? The check of the condition by which the verdict is set, ? Generation of report outputs, and ? Parameters for configuration of the test patterns. An example of a simple test module with a test case that is implemented by exactly one test pattern: <testmodule title=”Mirror Control Test” version=”1.2”> <testcase ident=”TC 2.4.1” title=”Mirror Close Right” > <statechange title=”Close Mirror, check motor” wait=”1000”> <in> <cansignal name=”Mirror_2”>1</cansignal> </in> <expected> <cansignal name=”MirrorMotor2”><gt>5</gt></cansignal> </expected> </statechange> </testcase> </testmodule> In XML test modules too, test cases should not be built upon one another, and the ECU under test should be reset to its initial state after each test. Setting up XML test modules

2.2.2

Sequence execution 2.2.3 Working with test functions Many test patterns and primitives operate with signals. 2.5 Programming test cases in .NET test modules To program a .NET test module, you need to specify a .NET file as the source file for the test module. The recommended programming language is C#. The .NET API is an additional way to specify and implement test cases in CANoe. 2.2.1 Principle The .NET Test API in CANoe can be used either for creating a pure .NET test module, or a so-called test library with independent test cases that can be called from an XML test module. no Main() method in the .NET code. 2.2.2 Setting up purely .NET test modules A .NET test module inherits from the class Vector.CANoe.TFS.Testmodule and consists primarily of the Main() method and the implementation of test cases. public class CentralLockingSystem : TestModule { public override void Main() { TestGroupBegin("Test the windows", "Checks the window functions"); SimpleWindowTest(true); // test case - open the window SimpleWindowTest(false); // test case - close the window TestGroupEnd(); } [TestCase("Open/close the window")] public void SimpleWindowTest(bool open) { // some test code } 2.2.3 } Wait points As in CAPL, it is possible to wait for various events in .NET test modules. Execution.Wait(50); // Wait for 50 ms Execution.Wait<LockState>(1); // Wait for the signal LockState to reach value 1 Type Library The generation of the type libraries for the access to the database objects (signals, environment and system variables, messages) is done completely automatically by CANoe. Event procedures in test modules So-called event procedures are used to process events in .NET test modules. Handler for signal, environment variables and system variables: [OnChange(typeof(LockState))] // Signal LockState Handler to process a key event: *OnKey(“k”)+

2.2.4

2.2.5

2.2.6

Handler to process a timer event cyclically: [OnTimer(500)] Handlers to process CAN message events [OnCANFrame], [OnAnyCANFrame()] The .NET API only supports on change handlers for signal types (in contrast to CAPL that supports both on change and on update handlers). Observation of system conditions The observation of system conditions n parallel to the test sequence is realized with checks. There are three types of checks in .NET: Constraints, Conditions, and Observation. Constraints/conditions (as known form CAPL and XML) influence the verdict of the test module but Observation does not. ? Signal based checks can be easily setup by using the ValueCheck class: ICheck observeLockState = new ValueCheck<LockState>(1) ? It is also possible to let a user-defined handler decide about the check result: [Criterion] // Define custom criteria [OnChange(typeof(AntiTheftSystemActive))] [OnChange(typeof(LockState))] bool AntiTheftSystemCriterion() { … } ICheck observeAntiTheftSystem = new Check(AntiTheftSystemCriterion)

2.6

? As in CAPL there are also predefined chechs for e.g. cycle time observation. ? Additionally the user gets the possibility to define its own check in .NET. The checks should only be defined, started and stopped in the “main test program”, not in event procedures. XML test modules versus CAPL/.NET test modules XML test modules do not replace CAPL or .NET test modules, rather they supplement them as another description type that in many cases permits simpler definition of the tests. Stated quite simply, the important difference is that in XML test sequences the user only assigns parameter values, while in CAPL or .NET the test sequences are programmed. CAPL/.NET and XML test modules have many similarities, but technically they differ in the aspects listed in the table below.

2.2.1 2.2.2

Strengths of XML test modules: Easy application, Generation, Parameterization, No programming necessary. Strengths of CAPL test modules: Maximum flexibility, Complex flow control.

Strengths of .NET test modules: Full-grown programming language, Powerful programming environment. 2.7 Constraints and conditions 2.2.1 Principle Constraints and conditions are checks that are performed in parallel to the specified test sequence. 2.2.2 Use of predefined checks in CAPL and .NET Four steps must be performed to use checks as constraints or conditions: 1. Create, parameterize and start the necessary check from the Test Service Library. The associated functions begin with the prefix ChkStart_. The functions each return a unique ID for the newly created check. 2. A constraint or a condition is generated by TestAddConstraint or TestAddCondition. The check created in Step 1 represents the constraint/condition statement, and its ID is now passed as a parameter. From this time point forward the constraint/condition monitoring that runs in parallel takes effect, i.e. “the check becomes semantic”. 3. Constraint/condition monitoring is removed again by TestRemoveConstraint or TestRemoveCondition. The check is deleted by ChkControl_Destroy. Example in CAPL: testcase TC () { dword check_id; check_id = ChkStart_MsgAbsCycleTimeViolation (StatusMsg, 90, 110); TestAddConstraint (check_id); … // The actual test sequence is located here … TestRemoveConstraint (check_id); ChkControl_Destroy (check_id); } Monitoring is in force between TestAddConstraint and TestRemoveConstraint. These two commands must be executed in the same context, i.e. in the same test case or in MainTest. 2.2.3 Constraints and conditions in XML Example: <testcase ident=”TC2” title=”Wiping Level 2”> <conditions> <cycletime_abs min="0" max="1100"> <canmsg id="WipingStatus"/> </cycletime_abs> </conditions> … </testcase> 2.2.4 User-defined test conditions

2.2.3

User-defined events can be used to implement any desired constraints and conditions in CAPL. Example: on message Status { if (this.Temperature > 100) TestSupplyTextEvent (“Overheated”); } testcase TC { TestAddConstraint (“Overheated”); … // The actual test sequence is located here … TestRemoveConstraint (“Overheated”); } 2.2.5 Influencing the test flow Constraints and conditions do not affect the test flow in CAPL/.NET test modules. In XML test modules they lead to termination of the test case being processed. TestCheckConstraint, TestCheckCondition TestGetVerdictLastTestCase , TestGetVerdictModule 2.8 Test Service Library The Test Service Library is an integral part of the CANoe Test Feature Set. It contains prepared testing and value generating functions intended to simplify test setup: ? ? Checks: Checking functions that operate in parallel to the defined test sequence. Checks are used primarily in constraints and conditions (compare 2.5).

Stimulus generators: These commands are used to generate a specific sequence of values for a signal or environment variable in order to stimulate an ECU. In general it is advisable to insert the call of ChkControl_Reset just before its reuse as a constraint or condition. 2.2.1 Checks Checks can be implemented in CAPL simulation nodes and in test modules. 2.2.2 Stimulus Generators Stimulus generators generate series of values that are applied to signals or environment variables. 2.9 Test setup The test setup offers a few advanced options such as consecutive execution of multiple test modules and merging of test reports from different test modules. 3.0 Test strategies Tests can be developed and implemented according to different strategies. This chapter describes a few such test strategies and their implementation in CANoe. In practice, however, mixed forms are encountered frequently, and some test strategies may be implemented in parallel.

3.1 Protocol tests Tests that primarily involve direct communication between tester and ECU to stimulate and evaluate the ECU under test are called protocol tests. 3.1.1 Test concept 3.1.2 Implementation in CANoe Protocol tests can be implemented very linearly in CAPL test modules using existing CAPL functions and the supplemental wait functions of the Test Feature Set. Typically the test sequence follows a simple scheme that repeats as often as needed: ? Output of a message to the ECU under test (Stimulus). ? Waiting for the ECU’s response. ? Evaluation of the response if necessary. Application Tests this layer is often called the Interaction Layer. 3.2.1 Test concept The actual communication is abstracted via an Interaction Layer. 3.2.2 Implementation in CANoe Invariants test Tests may consist of operating the ECU under various limit conditions and continuously checking it for conformance to certain specified behaviors. These specified behaviors are conditions that must be maintained under all circumstances, and they are frequently referred to as “invariants”. Therefore we also call this type of testing the invariants test. 3.3.1 Test concept 3.3.2 Implementation in CANoe Interface to a Test Management System Besides using CANoe as a standalone test tool, it is often necessary to interface a higher-order test system. Fundamentals of test management The Test Management System concept is not rigidly defined. It is understood to cover systems that save and manage information for testing. Principle of the interface

3.2

3.3

4.0

4.1

4.2


相关文章:
51testing软件测试培训笔记
51testing软件测试培训笔记_专业资料。a第一阶段考试重点归纳 第一章 测试基础 1. 软件测试的目的: 证明 (表达软件能够工作) 检测 → (发现错误) 预防 → (管...
testing
choosing test conditions, designing test cases and checking results, evaluating exit criteria, reporting on the testing process and system under test, and fi...
软件测试英语术语+缩写
Design-based testing:基于设计的测试 ? Desk checking:桌面检查 领测国际科技(北京)有限公司 领测软件测试网 http://www.ltesting.net/ ? Development testing:...
测试报告模板(Testing Report Template)
测试报告模板(Testing Report Template)_计算机软件及应用_IT/计算机_专业资料。可针对软件产品,项目,以及不同的版本编写不同的测试报告 提供了详细的报告说明 ...
English Testing
English Testing_英语学习_外语学习_教育专区。q@aEnglish Testing: True-false (判断): 判断) ---U1.Introduction to language testing: : 1. Both testing ...
51testing测试用例贴整理笔记
51testing软件测试培训笔... 34页 2下载券 51testing软件测试培训笔... 35页 1下载券 软件测试精要-51Testing 25页 免费 51Testing精选03-测试用... 22页 ...
软件测试分类
1、按是否查看程序内部结构分为: (1)黑盒测试(black-box testing):只关心输入和输出的结果 (2)白盒测试(white-box testing):去研究里面的源代码和程序结构 2...
目前国家认可的第三方检测中心
Ltd., Shanghai Intertek 检测服务(上海)有限公司 www.intertek.com Intertek Testing Services Guangzhou Ltd. Science City Branch Intertek 检测广州有限科学分公司 ...
雅思写作重点词汇总结:动物保护类
Multiply Furthermore, testing on white mice may contribute to the decline of cost, as they multiply quickly as well as being raised conveniently. 6. ...
Animal testings should be banned.
Animal testings should be banned._英语学习_外语学习_教育专区。Specific Purpose:To persuade my audience that animal testings should be banned. Central Idea...
更多相关标签:
test | testimonial | testin云测试平台 | testin云测试 | testin | testng | testing period | 51testing |