Contents 1 MeeGo Graphics Test Plan 1.1 Component Summary 1.2 Feature to be Tested 1.2.1 Table.1 Basic features 1.2.2 Table.2 MeeGo-1.1 1.2.3 Table.3 MeeGo-1.2 1.3 Table.4 Feature not to be Tested 1.4 Test Strategy and Approach 1.5 Table.5 Feature/Case mapping 1.5.1 Test Automation 1.6 Test Design 1.7 Test Environment 1.7.1 Hardware Platforms 1.7.2 Tools 1.8 QA Contact 1.9 Developers 1.10 Referrences

MeeGo Graphics Test Plan

Component Summary

The graphics subsystem is composed of Xserver, Mesa, 2D driver (e.g. Xf86-video-intel) and Drm. It should provide the latest graphics h/w features, as well as meet requirement of UI framework (e.g. Clutter, Qt), Window Manager even applications.

Feature to be Tested

What features to be tested are made of basic features + accepted features of MeeGO-1.1/MeeGo-1.2.

Table.1 Basic features

FEA ID	Feature summary	Feature description and Test points	Platform	Priority
n/a	X11	* Xserver should work well with Mesa, 2D driver and other components. * Many X extensions should be supported, including Xrender, Xcomposite, Xdamage, Xrandr adn so on.	ALL	Major
n/a	OpenGL ES 2.0	Should support OpenGL ES 2.0	ALL	Major
n/a	OpenVG	Should support OpenVG	ALL	Major
n/a	Display	* Should support Single/Multi display * Mode setting * Rotation setting	ALL	Major
n/a	Input	Should support proper event for input devices (i.e. multi-touch) in X	ALL	Major
n/a	Video	Should support XVideo and libVA	ALL	n/a

Table.2 MeeGo-1.1

FEA ID	Feature summary	Feature description and Test points	Platform	Priority
4877	[FEA] Provide libOpenVG and libOpenVGU packages	OpenVG is supported	ALL	Major

Table.3 MeeGo-1.2

FEA ID	Feature summary	Test points	Platform	Priority
7614	[FEA] Multiple output (HDMI) support from Graphics and Window manager	* HDMI output is supported by graphics driver; * Multiple display is supported by Window Manager	HDMI platform	Major

Table.4 Feature not to be Tested

Summary	Detail scenario	Support	Reasons
OpenGL	OpenGL ES2.0 would be the default 3D backend	n/a	OpenGL not be supported by SGX540 h/w

Test Strategy and Approach

All the above features would be tested. You can get the latest cases from http://gitorious.org/qa-tools/mcts.

Table.5 Feature/Case mapping

FEA name	Target Lib	Test suite package name
X11	libX11 libXdamage libXcomposite libXrandr libXrender libXv	blts-x11
OpenGL ES2.0	libEGL libGLESv2	blts-opengles2-perf
OpenVG	libEGL libOpenVG	mcts-openvg-tests
Display	libXrandr	mcts-display-tests
Input	libX11	blts-input-devices
Video	libXv	blts-xvideo

Test Types:

Most of cases are auto cases and provide function and performance testing.

• Function test: All.
• Performance test: OpenGL ES2.0, OpenVG, Xrender.

Test level:

All the cases are API level and inplemented with C language.

Flexibility:

Nokia shares some test cases calling bluez-libs API in C language. Although those cases are not in our test strategy, we still try to use bluez-libs to enlarge our profile test scope if possible.

Test Automation

We will keep one PC as server machine for auto test, so automated cases are the profiles which can be used between two computers. Based on this strategy, we currently made FTP/OPP/PANU profiles test cases automated.
There is no low level profiles automated by us. Nokia share some codes in MWTS and BLTS to test RFCOMM and L2CAP profiles. But unfortunately, all their cases are semi-automatic in fact.
The test framework to run our auto cases is MCTS. Those cases are written by shell scripts, some utility tools (called by cases) are made by python. Before case running, a OBEXD-Server machine must be setup there and wait for obexd-client call. Detail information can be refered from the README file in MCTS:Bluez component. Git repository is http://gitorious.org/qa-tools/mcts

Test Design

Test points are written in Tested Feature Tables.
Test method is introduced in Test Strategy and Approach section.

Test Environment

Nearly all the bluez test cases need at least two devices. One is testing machine, the other may be some BT integrated device.
There are still some scripts needed for profile checking, since we do not depend on GUI APP.

Hardware Platforms

Test Platforms	Networking	Other Devices	Priority
Pinetrail Netbook: Acer NAV50	LAN, Wifi, BT	BT headset (Dell DH200), BT Keyboard (Dell)...	P1
Diamondville Netbook: EeePC 1005 HA	LAN, Wifi, BT	BT headset (Dell DH200), BT Keyboard (Dell)...	P2
Handset: Avaa	USB, BT-dongle (BT2.0+EDR)	BT headset (Dell DH200), BT Keyboard (Dell)...	P1

Tools

Some python scripts are used to check FTP/OPP/PBAP... functions in middleware (without GUI). They are from:

• bluez source code: bluez/test/simple-agent --- For bluetooth pairing
• bluez source code: bluez/test/test-network --- For PANU connection setup with BNEP (PAN Server)
• obexd source code: obexd-0.32/test/ftp-client --- For FTP send/get/browse checking

QA Contact

jingke.zhang@intel.com
zhaojuan.guo@intel.com (intern)

Developers

majid.awad@intel.com
qiang.z.zhang@intel.com

Referrences

BT Profile introduction: http://en.wikipedia.org/wiki/Bluetooth_profile
Bluez source and tool downloading: http://www.bluez.org
BIG offical webpage: http://www.bluetooth.org