Symbian3/PDK/Source/GUID-A0A7B5B7-57F6-5FDF-BB7A-2FA40561A737.dita
author Dominic Pinkman <Dominic.Pinkman@Nokia.com>
Tue, 30 Mar 2010 11:56:28 +0100
changeset 5 f345bda72bc4
parent 3 46218c8b8afa
child 14 578be2adaf3e
permissions -rw-r--r--
Week 12 contribution of PDK documentation_content. See release notes for details. Fixes Bug 2054, Bug 1583, Bug 381, Bug 390, Bug 463, Bug 1897, Bug 344, Bug 1319, Bug 394, Bug 1520, Bug 1522, Bug 1892"

<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="GUID-A0A7B5B7-57F6-5FDF-BB7A-2FA40561A737" xml:lang="en"><title>Kernel
Tests Guide</title><shortdesc>Provides a number of automatic and manual tests to verify that
kernel and peripherals are functioning as expected in your development environment. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
<section id="GUID-BDCBD7CB-D933-44A2-944A-A6DA56147625"><title>Purpose</title> <p>The
kernel tests provide performance bench marking for kernel and peripheral devices
and ensures that all required components are working as expected. </p> </section>
<section id="GUID-F06EC66A-ED2B-4D39-9711-2F169DF39316"><title>Building a
test</title> <p>Tests are built using the Symbian ROM build utility. </p> <p>A
handy script has been produced to simplify test building: </p> <p>To build
a series of automatic tests execute <filepath>rom.bat,</filepath> found in <filepath>\e32\rombuild</filepath>.
You will need to set the attributes and options to tell the system which tests
to run. </p> <p>For example, to build a debug MISA ROM image, using the ARM4
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
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
to the target hardware as appropriate for the target device. </p> <p>Test
configuration can be customized by editing <filepath>e32test\group\bld.inf</filepath> and
adding or removing device drivers or kernel tests as required. All tests included
in the default build are part of the automatic test, those marked as manual
need to be explicitly included. </p> </section>
<section id="GUID-8A26BDB3-B4DD-42C9-8529-0F0B1E381789"><title>Executing tests</title> <p>The
kernel tests can be built and executed as automatic or manual tests. </p> <p> <note/>  </p> <ul>
<li id="GUID-6BAC5BC4-3A87-5773-8154-79965CFE8D58"><p> <b>Automatic test</b>  </p> <p>Tests
flagged as automatic are built into test scripts, which are then built into
the ROM image. </p> </li>
<li id="GUID-91A433D5-BB6A-50EA-BD1F-BF8AD911FAF6"><p> <b>Manual test</b>  </p> <p>Some
of the manual tests do not produce the log data via serial port which is indicated
in the test reference document. The successful completion of these tests should
be verified by monitoring the screen output, rather than referring to the
log data at the end of a testing session. </p> </li>
</ul> </section>
<section id="GUID-5D14B23B-1747-4985-9F74-7F487CA2F8FE"><title>Verification
of the test results</title> <p><b>Automatic test </b> </p> <p>All automatic
tests output a log file via serial port. Such output should be captured using
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
which is part of the EPOC base. The log data output is specific to the test,
however there are few elements of the output that are similar across all tests. </p> <p>If
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
and check number of the failed test case is displayed. This will help to track
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
means the test is successful. </p> <p><b>Manual test </b> </p> <p>For manual
tests that output log file the procedure is the same as explained above. For
tests that do not output serial logs, successful completion of the test should
be verified by monitoring the screen output. Since these tests are still RTest
based the output will still follow the patterns outlined above. </p> </section>
</conbody><related-links>
<link href="GUID-6BD9D6ED-99EA-5611-AF58-A6694ADE95F4.dita"><linktext>Kernel Utilities
Test Guide</linktext></link>
<link href="GUID-8C2B9DC3-9D96-560A-B27A-A8EB6C9A342C.dita"><linktext>SDIO test
Guide</linktext></link>
</related-links></concept>