STPE4011测试 设计 方法.docx

STPE4011测试 设计 方法.docx

《STPE4011测试 设计 方法.docx》由会员分享，可在线阅读，更多相关《STPE4011测试 设计 方法.docx（11页珍藏版）》请在冰豆网上搜索。

STPE4011测试设计方法

使用权限

本文档只限SKC&C内部使用.

本文档的制作,检查,审批原件要保存

制作人:

金东旭（译）

日期:

审核人:

尚彦学

日期:

文档在SKC&C内部的业务活动中使用。

审批人:

日期:

更新日志

1.0

定义

2003/11/01

更新编号

更新页及内容

制作日期

目录

1.序文1

1.1.目的1

1.2.参照1

2.设计向导1

2.1.数据设计1

1.序文

1.1.目的

已当前业务的需求定义结果为基础根据测试目的的不同开发测试case和测试数据。

提供详细的资料和执行测试计划并且为了在同一标准下进行作业将向导想全体成员共享.

1.2.参照

无

2.设计向导

2.1.数据设计

（1）概要

已当前业务的需求定义结果为基础根据测试目的的不同开发测试case和测试数据。

提供详细的资料和执行测试计划.所有测试设计里面要描述测试目的，期待结果，测试对象程序功能及结果。

应用程序开发相关的测试设计步骤如下.

-定义程序测试环境.

-设计单元及集成测试.

-设计系统测试.

-设计UAT.

-定义测试资源需求.

-检查测试设计.

测试设计步骤如下.

图1）测试设计步骤

（2）设计考虑事项

测试设计时考虑项.

-测试示例里面要包含期待的测试结果.如果期待的测试结果没有问题也不能保证其正确性。

-程序要不能由开发者或程序的运营部门的人来测试。

程序开发者的目的是让程序顺利运行，程序测试的目的是找出程序的错误。

要意识到找出自己制作或运营的程序中找到错误是很困难的。

-所有测试结果要仔细调查。

偶尔会产生新的错误。

-制定不仅仅是正常的还有非正常的不明确的结果的测试用例。

程序在正常的环境下可以运行是否正常的确认之外，还要考虑程序在非正常环境下运行的结果。

-不能假设没有错误。

测试的目的是发现错误而不是描述程序功能.成功的测试用例是发现没有发现的错误。

（3）设计构成要素

测试设计要包含下列构成要素

Ø测试目的

各测试事件类别要测试什么要明确定义.测试目的里面要描述要测试的功能及状态,要符合上层的期待结果。

考虑下列事项。

⏹测试目的根据测试功能和测试事件的不同而不同。

举例来说,集成测试的目的包含功能测试和功能间的接口测试。

项目期间的风险评价对测试目的地定义很有帮助。

举例来说,新技术的采用是为了测试这种新技术.

⏹测试目的要与应用系统需求或系统设计相关联。

根据测试目的不同，投入测试的程度不同，测试目的要有客户和信息系统关联部门来检查。

⏹测试时间的缩短，首先要给测试目的排好顺序。

即不能完全测试的情况下测试最重要的部分。

Ø测试示例

测试示例里要把输入资料，预想结果，测试执行环境文档化。

测试示例设计的测试目的及测试技术为根据。

这样的测试示例可以重复，可统计，可记录。

而且将测试示例组化成可管理的单位.这个是在测试阶段可以快速发现错误的方法,将关联的目的示例分组.举例来说,所有会员处理（例,确认会员数,追加的2次会员数的判定等）的测试目的找出这样的活动之间的作用间错误，通过执行一个测试循环。

Ø测试Team组织

各测试类别定义和描述测试Team的角色及责任.为了执行这些角色有必要描述描述责任和技术层面的角色/责任矩阵并得到测试执行者的确认。

图1）角色及责任矩阵

Ø测试脚本

意味着在线及一起处理测试进行的详细描述文档.脚本里面将测试时执行的阶段及示例文档化。

举例来说,测试脚本里面输入什么信息,期望得到什么结果的描述。

脚本的目的是将测试分阶段让测试可持续有效的执行。

Ø测试过程

测试关联的所有假设（Assumption）的记录,测试示例里面文档化。

要在测试战略设立之前定义，在战略开发后要在测试设计里面反应.假设里面包含机械性能，测试环境等主要的假设。

（4）测试事件

什么测试事件为了什么程序的执行制定，各事件特征要对应测试设计.各测试事件特征如下。

Ø单元测试事件

单元测试的焦点是程序或系统的小模块。

这个是为了测试模块是否与功能要求相对应。

单元测试在程序代码的检查后执行。

使用测试示例的定义的数据，测试各个模块,比较期待结果和测试结果后记录.如果符合期待结果的话进入到开发库。

Ø集成测试事件

集成测试是发现个别单元测试执行后即成后出现的问题执行的行为。

此测试时发生在单元程序之间的接口及相互作用上，所以可以发现在单元测试阶段没有发现的问题。

集成测试有下列3个目的.

⏹应用程序软件构成要素间接口妥当性分析

⏹应用程序和外部实体间接口妥当性分析

⏹设计明细书店对应妥当性分析

集成测试将集成的模块视为应用程序,应用程序视为子系统,子系统视为整个应用程序系统，有几种测试组成。

Ø系统测试事件

系统测试是评价新功能和成果的多次测试。

系统测试是确认应用程序的根本目的及需求是否满足根据定义的步骤执行的行为.所以系统测试包含从多种角度对系统全面测试，所以是最难的测试，有效性测试，最终需求测试，大小及压力测试,安全及控制测试,回归测试,文档及步骤测试,最终站点测试。

通过之前的测试事件的测试示例可以再使用。

但是单元及集成测试期间没有测试的文档，步骤，成果等追加的测试示例要在系统层面上开发出来.

系统集成比一个或2个层度的系统侧面的测试事件不同需要判断多种特性所以非常复杂。

系统测试要测试有效性，成果，延续性等焦点为目的，是需求，外包设计明细书的测试，系统测试不仅仅有单一的一个测试示例构成而是由一个整体的场景构成。

下面是系统测试例子：

⏹系统的测试一个功能的测试示例

⏹一定期间使用者完成的所有操作。

⏹自动化或手动作业的应用程序模拟

Ø用户测试事件

与系统测试相同用户测试的目的是判断软件系统是否满足业务目的地需求，客户机信息系统组织需求，设计明细书描述内容是否实现。

但是与系统测试不同，用户测试时客户机有影响力的信息系统个人来负责。

虽然用户测试的时候可以使用开发好的测试用例，但是为了负责人确认客户对系统的期待可以追加测试用例。

通过用户测试可以判断系统是否适合实际业务环境。

这是客户判断系统是否可使用，所以是最接近现实的。

在用户测试的时候出现错误，如果不影响继续测试则可以继续进行。

（5）测试方法

测试事件或目的不同可采用下面的测试方法.

Ø白盒测试（White-BoxTest）

白盒测试方法评价程序路径的逻辑性的所以也叫路径测试.即测试程序路径是否与预想结果一致，此模块或程序的逻辑路径假设已经知道。

测试数据不仅仅根据程序明细书制作的还要评价程序的逻辑性。

内部程序结构及逻辑的知识要掌握.白盒测试的的主要优点是发现黑盒测试之前可以发现的问题。

白盒测试的缺点如下:

⏹不能判断是否与程序明细书一致.白盒测试的内部结构及设计不是重点所以是否符合程序明细书就不判断。

⏹无法知道路径.

⏹没有寻找丢失的路径的方法.

⏹数据的敏感性的错误无法捕获.

通过白盒测试可以有效的执行所有可能的路径。

因为此测试要求天文数字般的测试用例。

结果性来看白盒技术是适用于最有效的一般技术.

白盒测试方法在测试示例设计时考虑下列事项。

⏹文章coverage:

程序内部的所有文章最小化执行.

⏹分支coverage:

将测试示例的所有决定分支，结果假设制定。

⏹状况coverage:

将测试示例在讨论范围内各个情况都至少走一遍。

⏹分支/状况coverage:

测试示例将决定内地各个状况分支最少走一遍。

分支部分最少得到一个以上结果的前提下制定。

⏹基本路径测试:

测试示例依赖于程序明细书和独立的代码逻辑制作。

这样的测试示例叫基本路径测试,程序上制作可走所有路径的测试.然后生成代码结构的基础的复杂的矩阵。

Ø黑盒测试（Black-BoxTest）

从数据测试的词方法焦点在于测试程序明细书的功能。

特别次方法通过组合输入资料可以评价是否能得出期待的结果。

黑盒测试示例设计是考虑下列事项:

⏹等级分解:

等级分解是将符合的数据和不符合的数据分别设定测试。

测试所有数据，在有限的范围内测试的方法，举例来说在以提供的范围内本金（600,000元~800,000元）的分为下列3个等级。

1.600,000元以下（不符合）

2.600,000元~800,000元（符合）

3.800,000元超过（不符合）

⏹边界分析:

提供的功能的投入/产出的边界为焦点开发测试示例的方法。

举例来说回归系统从1.00元到999,999.00元的话边界设计可以检查如下项。

4.最下边界+1或-10.00元或2.00元

5.边界（1.00元,$999,999.00元）

6.最上范围+1或-1999,998.00元或1,000,000.00元

⏹误差猜测:

测试示例测试执行者的直观及经验为基础开发。

ØIncremental测试（IncrementalTest）

此方法测试单元测试好的模块之间的接口。

将单元测试好的模块依次追加组合后测试。

Incremental测试分为下列3个形态。

⏹向下测试:

结构饼（StructuredChart）内从最高点模块到最低点模块测试

⏹向上测试:

结构饼（StructuredChart）内从最低的模块到最高点模块测试

⏹双向测试:

双向组合测试.

不能说哪个方法更好，但是双向测试容易使用。

产出物在使用向上测试方法的时候可以直接评价.向下测试时测试的产出物

实际从测试模块和其它模块之间得出（模拟的模块）。

使用向上测试的话产出物是从被测试的模块当中直接得出。

向下测试的主要优点是提供测试基础的程序版本的维护。

Ø事务测试（ThreadTest）

单元业务集成是使用的此方法是应用程序执行特定功能时测试单元业务的方法，事务测试与增加测试同时进行。

Ø回归测试（RegressionTest）

此方法在程序及应用程序在某种情况修正后执行的测试。

使用之前使用的测试cycle非常有利于测试。

使用之前的测试示例所以多系统的其他部分不会有影响。

下图表示各个测试事件适合的方法.

图3）测试事件/方法矩阵