test case


 测试用例是用文字叙述还是写代码啊?

test case


In software engineering, the most common definition of a test case is a set of
 conditions or variables under which a tester will determine if a requirement
or use case upon an application is partially or fully satisfied. It may take m
any test cases to determine that a requirement is fully satisfied. In order to f
ully test that all
the requirements of an application are met, there must be at least one test ca
se for each requirement unless a requirement has sub requirements. In that sit
uation, each sub requirement must have at least one test case. This is frequentl
y done using a Trac
eability matrix. Some methodologies, like RUP, recommend creating at least two
 test cases for each requirement. One of them should perform positive testing
of requirement and other should perform negative testing. Written test cases sho
uld include a descr
iption of the functionality to be tested, and the preparation required to ensu
re that the test can be conducted.

If the application is created without formal requirements, then test cases can
 be written based on the accepted normal operation of programs of a similar cl
ass. In some schools of testing, test cases are not written at all but the act
ivities and results are reported after the tests have been run.

What characterizes a formal, written test case is that there is a known input
and an expected output, which is worked out before the test is executed. The k
nown input should test a precondition and the expected output should test a po
stcondition.

Under special circumstances, there could be a need to run the test, produce re
sults, and then a team of experts would evaluate if the results can be conside
red as a pass. This happens often on new products' performance number determin
ation. The first test is taken as the base line for subsequent test / product re
lease cycles.

Written test cases are usually collected into Test suites.

A variation of test cases are most commonly used in acceptance testing. Accept
ance testing is done by a group of end-users or clients of the system to ensur
e the developed system meets their requirements. User acceptance testing is us
ually differentiated by the inclusion of happy path or positive test cases.


Structure of test case

Formal, written test cases consist of three main parts with subsections:

    * Information contains general information about Test case.
          o Identifier is unique identifier of test case for further reference
s, for example, while describing found defect.
          o Test case owner/creator is name of tester or test designer, who cr
eated test or is responsible for its development
          o Version of current Test case definition
          o Name of test case should be human-oriented title which allows to q
uickly understand test case purpose and scope.
          o Identifier of requirement which is covered by test case. Also here
 could be identifier of use case or functional specification item.
          o Purpose contains short description of test purpose, what functiona
lity it checks.
          o Dependencies
    * Test case activity
          o Testing environment/configuration contains information about confi
guration of hardware or software which must be met while executing test case

          o Initialization describes actions, which must be performed before t
est case execution is started. For example, we should open some file.
          o Finalization describes actions to be done after test case is perfo
rmed. For example if test case crashes database, tester should restore it befo
re other test cases will be performed.
          o Actions step by step to be done to complete test.
          o Input data description
    * Results
          o Expected results contains description of what tester should see af
ter all test steps has been completed
          o Actual results contains a brief description of what the tester saw
 after the test steps has been completed. This is often replaced with a Pass/F
ail. Quite often if a test case fails, reference to the defect involved should
 be listed in this column.

Not all written tests require all of these sections.

from answers.com 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值