某银行项目外包测试案例文档格式.docx

某银行项目外包测试案例文档格式.docx

《某银行项目外包测试案例文档格式.docx》由会员分享，可在线阅读，更多相关《某银行项目外包测试案例文档格式.docx（19页珍藏版）》请在冰豆网上搜索。

　　通过参与需求分析和设计过程，可以找到测试重点和难点。

通过在分析讨论过程中，了解业务人员最关心的功能部分，最担心系统的功能部分等，也了解开发人员对业务的理解情况，开发人员最不清楚和最不理解系统的部分，这样在测试设计和测试过程中可以针对性的多设计测试用例。

某银行项目外包测试案例

（二）

提取测试需求过程

　　提取测试需求过程是在逐渐熟悉业务需求后，开始提取测试需求，主要是在2008年5月完成。

　　提取测试需求可以在跟踪需求分析和设计过程中提取，也可以在需求评审后提取。

而在本项目中，我们是边参与需求分析和设计过程边进行提取测试需求的。

　　在提取测试需求前，先整理业务需求。

业务需求即业务人员在需求文档列出的功能点，这些功能点可能对应着菜单，也可能分布在系统中的功能。

我们把业务需求整理在一张表中，因为在测试计划中要列出功能点，这些整理的功能点可以直接用在测试计划中。

　　关于什么是测试需求呢？

　　测试需求提供一个测试应用程序所必须的详细的描述。

一个测试需求是：

　　1、有利于开发和测试

　　2、帮助定义测试范围

　　3、设置明确的团队目标

　　4、节省时间和投入

　　一条有用的测试需求总是：

　　1、惟一的

　　2、精确的

　　3、有边界的

　　4、可测试的

　　测试组根据业务需求，把业务需求分解成测试需求，一条业务需求可能被分解成多条测试需求，以从不同的角度验证业务需求。

在这个项目中，我们把300条业务功能需求分解成1300条测试需求。

在HPQualityCenter中，其结构截图如下：

　　图片看不清楚？

请点击这里查看原图（大图）。

　　在上面的截图中，一级节点是按照客户角色渠道分类，二级节点是业务功能需求，而三级节点则是测试需求。

某银行项目外包测试案例（三）

设计测试用例过程

　　设计测试用例的过程是在2008年6到2008年7月。

　　测试设计过程是设计用例使测试需求如何被测试验证的过程，也是整个测试过程中一个比较关键的环节。

测试用例设计质量的优劣决定着测试执行的优劣。

　　通过把测试需求直接转化为测试用例描述，针对该描述设计测试用例步骤。

在测试用例用例时，我们并没有添加测试数据，而是在测试用例执行时，再添加测试数据。

这样做的好处不用针对不同轮次设计测试用例，实现测试用例的复用。

在需求变更时，要有专人维护测试用例和测试需求，尤其是测试需求和测试用例的关联关系。

　　测试用例管理上也支持同行评审，所以我们安排测试设计工程师进行测试用例的同行交叉检查，或者客户业务人员对测试用例进行审查。

对应每个测试用例可以添加审查意见。

　　在测试规范中要求一条测试需求对应一个测试用例，这样可以就不会出现需要把测试用例作为文件夹形式，下面再添加测试用例描述的形式，这样做到了所有设计人员的形式统一，便于进行统计分析。

这些我们在项目前期，我们首先对测试设计人员进行了培训，把如何使用QC工具展示我们的测试设计过程用规范的形式定义下来，并贯彻执行，保证了整个项目测试工作上的统一性。

　　在设计测试用例时，主要包括正向测试用例，异常情况测试用例。

而对于界面控件验证，操作易用性等我们要求是在测试中检查，而不用设计在测试用例中，对于功能界面的检查，我们项目组参考公司执行的测试规范，例如桌面系统和Web系统都有不同的检查项，这些检查项依据Windows平台的界面规范以及Web系统规范要求，同时也要参考黄金项目本身的用户对象，根据用户对象不同，对界面要求不尽相同。

　　测试用例设计过程是整个测试中技术含量最高的过程。

在测试用例设计过程中，我们安排了两位经验丰富的测试设计工程师进行测试用例设计工作。

而在后期，该两位测试设计工程师将作为本项目组的两组组长，各带领几位测试工程师执行测试用例。

　　测试用例设计过程也需要工作量比较多的过程，该阶段工作通常占用整个测试周期的1/3左右的工作量。

通常是在测试执行前，一直跟踪业务需求，不断的完善测试用例，加深对业务的理解程度。

　　举例：

一条业务功能需求对应的测试用例如下图

某银行项目外包测试案例（四）

2.2参与需求说明书的评审

　　黄金项目的需求评审工作是在2008.7进行。

　　听取各方对业务需求的意见，也从各方了解对系统的要求，例如：

安全性、网络、业务规则等。

在评审过程也往往会提出一些新的需求，这些新的需求会在评审后会补充到需求中。

这些新的需求要整合到原来的需求中，在这些新需求以及与原来需求接口的部分也是我们测试中要需要更多关注的地方。

　　2.3测试计划

　　在整个黄金项目过程中，我们要提供客户4份测试计划。

包括：

整体测试计划、集成测试计划、功能测试计划和性能测试计划。

　　整体测试计划是在项目前期提供客户的一份总的测试计划，在该测试计划中对整个项目的测试范围、测试过程、测试方法、资源安排、计划进度等进行概括的描述。

黄金项目包括了集成测试、功能测试、性能测试。

对每个测试阶段的测试范围、测试方法和策略、测试进度分别进行了描述。

通过该测试计划，使整个项目组对整个测试工作达成一种共识，使客户业务人员、科技人员以及开发公司等了解我们整个项目如何测试。

也便于协调各种资源，来保障测试所需要的测试环境、测试工具、需要配合的资源等等。

　　整个整体测试计划的目录内容如下：

　　性能测试计划是主要对黄金项目的压力、负载等进行测试规划。

性能测试计划必须明确测试的范围，因为目前不同的人对性能测试的认识和理解不同，所以性能测试计划中必须详细的列出性能测试的测试范围，测试指标，选择哪些典型业务，做哪些类型的测试，让项目干系人了解性能测试如何做，理解指标的含义。

在性能中最重要的是测试环境，因为黄金项目的性能测试环境跟上线运营环境存在着差别，要让整个项目干系人了解这种差异会对测试结果产生哪些方面的影响，当然测试组也会分析这种影响会对测试结果的影响。

　　上述三个测试计划都要通过项目总监的审查、项目组评审。

测试计划设计完成后，首先要通过公司项目管理委员会的审查，根据审查意见完善测试计划，通过公司内部的审查后，要把测试计划正式交给客户后，客户会组织正式的测试计划评审会议，项目组根据评审意见修改完善测试计划文档，以满足整个项目对测试的要求。

某银行项目外包测试案例（五）

2.4测试执行过程

　　测试执行过程是整个项目测试工作的中心，也是测试执行过程也是测试计划落实实践的过程。

　　在开发交付系统进入测试之前，我们首先通过冒烟测试方法判断系统是否达到可进入测试的条件。

根据系统不同，这个冒烟测试一般需要大约2-3天时间。

对于集成测试入口准则一般是至少已经完成了所有接口功能的90%且核心接口功能已经完成，并承诺在集成测试后面轮次完成所有的接口功能。

在冒烟测试中，会根据这个接口功能表进行统计，哪些接口功能已经完成，哪些没有完成，已经完成的接口所占的比例，只有达到了入口准则才能进入后续的集成测试。

对于功能测试也是采用入口准则判断的方式，只要达到了入口准则，才能进入功能测试。

　　根据我们的测试经验，很多项目都是周期比较紧张，往往到了开发项目组交付测试版本时，还有很多功能没有完成，这样交付系统的质量不可能太高，且需要在测试过程中，还需要继续研发，形成测试研发并行的过程，使测试和研发交错在一起，形成比较混乱的局面，后面项目延期时，很难判断是那块工作没有完成。

所有我们在项目中往往采用T+D形式确定测试时间，T是交付测试版本通过冒烟测试的时间，D是测试过程周期。

　　2.4.1工作分工

　　虽然说测试任务分工是项目组内部的事情，但是也可能会对项目完成质量产生一定的影响。

金融行业的软件系统是比较庞大和复杂，子系统、模块功能的数量，用户角色都比较多，同时也要考虑项目组每个成员的技术特点、技能水平。

需要综合考虑上面这些因素，然后采取一种相对完善合理的方式进行工作分配。

　　在工作分工上除了考虑系统模块和人员技能水平等外，也要考虑，分工方法会不会造成遗漏，也就是分工会不会产生测试工程师各自负责测试任务之间的空当，测试项目经理必须判断分工方法的优点和缺陷，并采取相应的措施进行必要的弥补。

其实工作分工跟软件系统接口一样，在接口的地方是非常容易引起问题的。

在分工时，项目组经理或测试组长必须把能写在任务安排中的工作都详细列出来，并让测试工程师明确自己所承担的测试任务。

　　在工作分工后，执行多个轮次测试时，要考虑每个轮次是否交换测试工作分工，交换与否各有利弊，项目经理要权衡到底采用那种模式。

在黄金项目中，我们采取了重点模块专人负责到底，而部分模块采取交换的方式。

由于考虑到时间周期短，轮次较多，为保证测试质量是由专人负责，未交换工作。

如果在时间允许的情况下，交换工作对测试工作有一定好处。

某银行项目外包测试案例（六）

2.4.2测试轮次

　　黄金项目功能测试采用了3轮集成测试，5轮功能测试，3轮性能的方案。

到底采取多少轮测试才能保证系统质量呢？

理论上讲，轮次越多越好。

但是对于项目来说，项目周期是有限的，所以要在有限的周期内，尽量多安排测试轮次。

尤其是功能测试，应该至少执行5轮功能测试，得到的缺陷趋势图才比较清楚的展示缺陷的收敛情况。

　　在每个测试轮次中，要执行全部的测试用例，这也是客户的要求。

如何分工中包括对测试用例的分工，则应该让测试工程师明确清楚自己所要执行的测试用例标识，以免产生遗漏。

　　在每个轮次中，我们都会统计执行测试用例情况，测试需求覆盖情况，尤其是每个轮次中，无法执行的测试用例，也就是无法覆盖的测试需求和业务功能需求。

统计每个轮次所提交的缺陷数量，处在各种状态的缺陷，缺陷的严重级别分布如何，缺陷所在的模块等等。

这些每个轮次的数据会统计在每个轮次的测试工作小结报告中，也是最后测试报告中不可或缺的内容，所以必须认真的统计好这些数据。

　　2.4.3测试数据

　　由于在设计测试用例中没有添加测试数据，所以在测试人员在执行测试流时，必须构造测试数据。

下图是测试人员记录的输入测试数据，执行用例时，输入这些测试数据，根据当时的价格行情，在Excel中计算出各种费用，再与系统查询出来的费用进行对比，从而判断系统计算是否正确。

某银行项目外包测试案例（七）

2.4.4填写并跟踪缺陷报告

　　在黄金项目中，使用汉星天的Butterfly管理缺陷。

　　在执行前，首先对Butterfly工具进行培训，使所有项目组人员掌握该工具的