Meego Wiki
Views

Quality/TestSuite/MCTS/MCTS Development Guideline

From MeeGo wiki
(Difference between revisions)
Jump to: navigation, search
Line 3: Line 3:
'''Test Case Naming'''
'''Test Case Naming'''
-
        * Show the purpose clearly, avoid simply use number.
+
* Show the purpose clearly, avoid simply use number.
-
        * Name length should less than 30
+
* Name length should less than 30
-
        * Use '_' to connect words  
+
* Use '_' to connect words  
'''Test Definition'''
'''Test Definition'''
-
        * XML format :http://gitorious.org/qa-tools/test-definition
+
* XML format :http://gitorious.org/qa-tools/test-definition
-
        * One test package corresponds one test case definition file         
+
* One test package corresponds one test case definition file         
'''File header'''
'''File header'''
-
        * Copyright
+
* Copyright
-
        * License
+
* License
-
        * Author
+
* Author
-
        * Changelog     
+
* Changelog     
'''Check list'''
'''Check list'''
* README
* README
Line 23: Line 23:
* pack.sh: the script to make package
* pack.sh: the script to make package
* test.spec: spec files to create package
* test.spec: spec files to create package
-
'''Makefile (??? If need automake)'''
+
'''Makefile (??? If need automake)'''
* make : build test package.
* make : build test package.
* make install: install test binary or script into /usr/bin, tests.xml into /usr/share/<testpackagename>/tests.xml
* make install: install test binary or script into /usr/bin, tests.xml into /usr/share/<testpackagename>/tests.xml
Line 31: Line 31:
'''Coding Style'''
'''Coding Style'''
-
        * C/C++ : http://www.chris-lott.org/resources/cstyle/indhill-cstyle.html
+
* C/C++ : http://www.chris-lott.org/resources/cstyle/indhill-cstyle.html
-
        * Python: http://www.python.org/dev/peps/pep-0008/
+
* Python: http://www.python.org/dev/peps/pep-0008/
-
        * Shell : http://hub.opensolaris.org/bin/view/Community+Group+on/shellstyle
+
* Shell : http://hub.opensolaris.org/bin/view/Community+Group+on/shellstyle
'''Test Case Design'''  
'''Test Case Design'''  
-
Common Rule:
+
*Common Rule:
-
        * Automate test under condition of stability
+
** Automate test under condition of stability
-
        * Main function should keep simple and structure keep neat.
+
** Main function should keep simple and structure keep neat.
-
        * Define common function file shared between test cases.
+
** Define common function file shared between test cases.
-
        * Have no dependency on other test case.
+
** Have no dependency on other test case.
-
        * Have no dependency on UX or vertical specific apps.
+
** Have no dependency on UX or vertical specific apps.
-
        * Have no dependency on test framework.
+
** Have no dependency on test framework.
-
        * Platform irrelevant
+
** Platform irrelevant
-
        * Clean environment after test complete.
+
** Clean environment after test complete.
-
        * Avoid hard coding - String, Digital
+
** Avoid hard coding - String, Digital
-
        * If parameters number greater than 3, use getopts
+
** If parameters number greater than 3, use getopts
-
        * Suitable comments
+
** Suitable comments
          
          
-
Test Level Specific Rules:
+
*Test Level Specific Rules:
-
        Thorough
+
**Thorough
-
        * All APIs should be covered.
+
*** All APIs should be covered.
-
        * A test case targets an usage (API combination) instead of an API itself
+
*** A test case targets an usage (API combination) instead of an API itself
-
        * Test need cover param pairs with equivalence partitioning and boundary condition  (All-pairs optional)
+
*** Test need cover param pairs with equivalence partitioning and boundary condition  (All-pairs optional)
-
        Average
+
**Average
-
        * All cared APIs should be covered (e.g. new functionality relevant APIs) with thorough test rules
+
*** Legacy or low risk APIs are covered only with positive tests
-
        * Legacy or low risk APIs are covered only with positive tests
+
          
          
-
        Lightweight
+
**Lightweight
-
        * Test most ciritical functionalities  
+
*** Test most critical functionalities  
-
        * With most typical parm-pairs
+
*** With most typical parm-pairs

Revision as of 09:13, 9 June 2010

MeeGo Core Test Suite(CTS) Development Guideline

Test Case Naming

  • Show the purpose clearly, avoid simply use number.
  • Name length should less than 30
  • Use '_' to connect words

Test Definition

File header

  • Copyright
  • License
  • Author
  • Changelog

Check list

  • README
  • src/ : contain source files
  • utils/: contain utility and tools if any
  • Makefile
  • tests.xml
  • data/: contain small data files (For big data such as media content, need separate package)
  • pack.sh: the script to make package
  • test.spec: spec files to create package

Makefile (??? If need automake)

  • make : build test package.
  • make install: install test binary or script into /usr/bin, tests.xml into /usr/share/<testpackagename>/tests.xml
  • make clean: remove all object file and tempory files
  • make uninstall: remove test binary or scripts, tests.xml under target installation directory.
  • make package: create rpm for current test package

Coding Style

Test Case Design

  • Common Rule:
    • Automate test under condition of stability
    • Main function should keep simple and structure keep neat.
    • Define common function file shared between test cases.
    • Have no dependency on other test case.
    • Have no dependency on UX or vertical specific apps.
    • Have no dependency on test framework.
    • Platform irrelevant
    • Clean environment after test complete.
    • Avoid hard coding - String, Digital
    • If parameters number greater than 3, use getopts
    • Suitable comments
  • Test Level Specific Rules:
    • Thorough
      • All APIs should be covered.
      • A test case targets an usage (API combination) instead of an API itself
      • Test need cover param pairs with equivalence partitioning and boundary condition (All-pairs optional)
    • Average
      • Legacy or low risk APIs are covered only with positive tests
    • Lightweight
      • Test most critical functionalities
      • With most typical parm-pairs
Retrieved from "http://wiki.meego.com/Quality/TestSuite/MCTS/MCTS_Development_Guideline"
Personal tools