1 <?xml version="1.0" encoding="utf-8"?>

     2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

     3 <!-- This component and the accompanying materials are made available under the terms of the License 

     4 "Eclipse Public License v1.0" which accompanies this distribution, 

     5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

     6 <!-- Initial Contributors:

     7     Nokia Corporation - initial contribution.

     8 Contributors: 

     9 -->

    10 <!DOCTYPE concept

    11   PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

    12 <concept id="GUID-A0A7B5B7-57F6-5FDF-BB7A-2FA40561A737" xml:lang="en"><title>Kernel

    13 Tests Guide</title><shortdesc>Provides a number of automatic and manual tests to verify that

    14 kernel and peripherals are functioning as expected in your development environment. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

    15 <section id="GUID-BDCBD7CB-D933-44A2-944A-A6DA56147625"><title>Purpose</title> <p>The

    16 kernel tests provide performance bench marking for kernel and peripheral devices

    17 and ensures that all required components are working as expected. </p> </section>

    18 <section id="GUID-F06EC66A-ED2B-4D39-9711-2F169DF39316"><title>Building a

    19 test</title> <p>Tests are built using the Symbian ROM build utility. </p> <p>A

    20 handy script has been produced to simplify test building: </p> <p>To build

    21 a series of automatic tests execute <filepath>rom.bat,</filepath> found in <filepath>\e32\rombuild</filepath>.

    22 You will need to set the attributes and options to tell the system which tests

    23 to run. </p> <p>For example, to build a debug MISA ROM image, using the ARM4

    24 Instruction set, containing both the E32Test and F32Test tests, enter: </p> <p><userinput>cd <parmname>\e32\rombuild</parmname> </userinput> </p> <p><userinput>rom <cmdname>--assp</cmdname> =<parmname>misa</parmname> <parmname>--inst</parmname> =<parmname>arm4</parmname> <cmdname>--build</cmdname> =<parmname>urel</parmname> <cmdname>--type</cmdname> =<parmname>alltests</parmname> </userinput> </p> <p>Which

    25 creates <filepath>misabaarm4.img</filepath>,<filepath> rombuild.log</filepath> and <filepath>rom.oby</filepath> in<filepath> \e32\rombuild</filepath>. The <codeph>*.img</codeph> image file should be renamed and then transferred

    26 to the target hardware as appropriate for the target device. </p> <p>Test

    27 configuration can be customized by editing <filepath>e32test\group\bld.inf</filepath> and

    28 adding or removing device drivers or kernel tests as required. All tests included

    29 in the default build are part of the automatic test, those marked as manual

    30 need to be explicitly included. </p> </section>

    31 <section id="GUID-8A26BDB3-B4DD-42C9-8529-0F0B1E381789"><title>Executing tests</title> <p>The

    32 kernel tests can be built and executed as automatic or manual tests. </p> <p> <note/>  </p> <ul>

    33 <li id="GUID-6BAC5BC4-3A87-5773-8154-79965CFE8D58"><p> <b>Automatic test</b>  </p> <p>Tests

    34 flagged as automatic are built into test scripts, which are then built into

    35 the ROM image. </p> </li>

    36 <li id="GUID-91A433D5-BB6A-50EA-BD1F-BF8AD911FAF6"><p> <b>Manual test</b>  </p> <p>Some

    37 of the manual tests do not produce the log data via serial port which is indicated

    38 in the test reference document. The successful completion of these tests should

    39 be verified by monitoring the screen output, rather than referring to the

    40 log data at the end of a testing session. </p> </li>

    41 </ul> </section>

    42 <section id="GUID-5D14B23B-1747-4985-9F74-7F487CA2F8FE"><title>Verification

    43 of the test results</title> <p><b>Automatic test </b> </p> <p>All automatic

    44 tests output a log file via serial port. Such output should be captured using

    45 HyperTerminal or a tool with similar functionality. Each test uses the <xref href="GUID-D16A6778-660E-302A-A3B5-DD98A088B7EC.dita"><apiname>RTest</apiname></xref> class

    46 which is part of the EPOC base. The log data output is specific to the test,

    47 however there are few elements of the output that are similar across all tests. </p> <p>If

    48 the output generated by <codeph>RTest</codeph> shows </p> <codeblock id="GUID-75FFCCA8-39E7-5D25-B1B9-9EAC2BC10E8B" xml:space="preserve">FAIL : T_DSPACE failed check 1 at line Number: 660</codeblock> <p>it means a particular test case in the test program has failed. The line

    49 and check number of the failed test case is displayed. This will help to track

    50 the defect in the test code. </p> <p>If the output generated by RTest shows </p> <codeblock id="GUID-9282986C-9FA6-58EC-8A22-0C49BC182287" xml:space="preserve">RTEST: SUCCESS : T_OPEN test completed O.K.</codeblock> <p>it

    51 means the test is successful. </p> <p><b>Manual test </b> </p> <p>For manual

    52 tests that output log file the procedure is the same as explained above. For

    53 tests that do not output serial logs, successful completion of the test should

    54 be verified by monitoring the screen output. Since these tests are still RTest

    55 based the output will still follow the patterns outlined above. </p> </section>

    56 </conbody><related-links>

    57 <link href="GUID-6BD9D6ED-99EA-5611-AF58-A6694ADE95F4.dita"><linktext>Kernel Utilities

    58 Test Guide</linktext></link>

    59 <link href="GUID-8C2B9DC3-9D96-560A-B27A-A8EB6C9A342C.dita"><linktext>SDIO test

    60 Guide</linktext></link>

    61 </related-links></concept>