某银行项目外包测试案例

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

跟踪需求分析和设计过程

该过程在整个项目的前期完成，主要集中在2008.5~2008.7时间段内。

在需求设计阶段是客户业务需求逐渐形成的过程。测试人员在业务人员开始编写业务需求时，没有进入项目组，因为这时候的需求还往往只是一个初稿，没有成型，测试人员并不需要参与前期需求编写工作，而是在需求初稿已经完成，在需求可以拿出来在整个项目组讨论时，测试人员就可以参与到这个讨论过程。

测试人员参与需求讨论可以从测试视角发现业务需求中描述不准确、不正确的地方，帮助业务人员做好需求分析工作，减少需求中遗漏。因为测试人员往往根据积累了相同业务领域的经验，把测试过的项目需求与当前项目需求进行对比分析，更容易发现当前需求中的不足之处，把经验提供给业务人员和项目组参考。

测试人员在这个过程往往承担业务人员和研发人员桥梁的作用，测试人员往往接触过类似项目或业务，对业务的理解能力往往高于研发人员，所以在某些时候测试人员可以把业务人员的需求转化为容易被开发人员理解的方式阐述，而把开发人员的编程的方式、方法讲解给业务人员。例如，把需求中的“输入”描述修改“从列表框选择”，则可以使需求更具体和明确。

跟踪需求分析和设计过程也有助于理解业务，是对需求逐渐熟悉的过程。在这个阶段，需求还没有确定下来，所以还不太适合设计测试用例，而通过参与业务人员、开发人员的讨论，逐渐熟悉业务需求，可以理解业务人员的想法，有比较充足的时间理解整个业务。

1 / 30

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

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

提取测试需求过程

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

提取测试需求可以在跟踪需求分析和设计过程中提取，也可以在需求评审后提取。而在本项目中，我们是边参与需求分析和设计过程边进行提取测试需求的。

在提取测试需求前，先整理业务需求。业务需求即业务人员在需求文档列出的功能点，这些功能点可能对应着菜单，也可能分布在系统中的功能。我们把业务需求整理在一张表中，因为在测试计划中要列出功能点，这些整理的功能点可以直接用在测试计划中。

关于什么是测试需求呢？

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

1、有利于开发和测试

2 / 30

2、帮助定义测试范围 3、设置明确的团队目标 4、节省时间和投入

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

1、惟一的

2、精确的

3、有边界的

4、可测试的

测试组根据业务需求，把业务需求分解成测试需求，一条业务需求可能被分解成多条测试需求，以从不同的角度验证业务需求。在这个项目中，我们把300条业务功能需求分解成1300条测试需求。在HP Quality Center中，其结构截图如下：

3 / 30

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

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

设计测试用例过程

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

测试设计过程是设计用例使测试需求如何被测试验证的过程，也是整个测试过程中一个比较关键的环节。测试用例设计质量的优劣决定着测试执行的优劣。

通过把测试需求直接转化为测试用例描述，针对该描述设计测试用例步骤。在测试用例用例时，我们并没有添加测试数据，而是在测试用例执行时，再添加测试数据。这样做的好处不用针对不同轮次设计测试用例，实现测试用例的复用。在需求变更时，要有专人维护测试用例和测试需求，尤其是测试需求和测试用例的关联关系。

4 / 30

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

在测试规范中要求一条测试需求对应一个测试用例，这样可以就不会出现需要把测试用例作为文件夹形式，下面再添加测试用例描述的形式，这样做到了所有设计人员的形式统一，便于进行统计分析。这些我们在项目前期，我们首先对测试设计人员进行了培训，把如何使用QC工具展示我们的测试设计过程用规范的形式定义下来，并贯彻执行，保证

5 / 30

了整个项目测试工作上的统一性。

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

测试用例设计过程是整个测试中技术含量最高的过程。在测试用例设计过程中，我们安排了两位经验丰富的测试设计工程师进行测试用例设计工作。而在后期，该两位测试设计工程师将作为本项目组的两组组长，各带领几位测试工程师执行测试用例。

测试用例设计过程也需要工作量比较多的过程，该阶段工作通常占用整个测试周期的1/3左右的工作量。通常是在测试执行前，一直跟踪业务需求，不断的完善测试用例，加深对业务的理解程度。

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

6 / 30

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

2.2参与需求说明书的评审

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

听取各方对业务需求的意见，也从各方了解对系统的要求，例如：安全性、网络、业务规则等。在评审过程也往往会提出一些新的需求，这些新的需求会在评审后会补充到需

7 / 30

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

2.3测试计划

在整个黄金项目过程中，我们要提供客户4份测试计划。包括：整体测试计划、集成测试计划、功能测试计划和性能测试计划。

整体测试计划是在项目前期提供客户的一份总的测试计划，在该测试计划中对整个项目的测试范围、测试过程、测试方法、资源安排、计划进度等进行概括的描述。黄金项目包括了集成测试、功能测试、性能测试。对每个测试阶段的测试范围、测试方法和策略、测试进度分别进行了描述。通过该测试计划，使整个项目组对整个测试工作达成一种共识，使客户业务人员、科技人员以及开发公司等了解我们整个项目如何测试。也便于协调各种资源，来保障测试所需要的测试环境、测试工具、需要配合的资源等等。

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

8 / 30

性能测试计划是主要对黄金项目的压力、负载等进行测试规划。性能测试计划必须明确测试的范围，因为目前不同的人对性能测试的认识和理解不同，所以性能测试计划中必须详细的列出性能测试的测试范围，测试指标，选择哪些典型业务，做哪些类型的测试，让项目干系人了解性能测试如何做，理解指标的含义。在性能中最重要的是测试环境，因为黄金项目的性能测试环境跟上线运营环境存在着差别，要让整个项目干系人了解这种差异会对测试结果产生哪些方面的影响，当然测试组也会分析这种影响会对测试结果的影响。

上述三个测试计划都要通过项目总监的审查、项目组评审。测试计划设计完成后，首先要通过公司项目管理委员会的审查，根据审查意见完善测试计划，通过公司内部的审查后，要把测试计划正式交给客户后，客户会组织正式的测试计划评审会议，项目组根据评

9 / 30

审意见修改完善测试计划文档，以满足整个项目对测试的要求。

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

2.4 测试执行过程

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

在开发交付系统进入测试之前，我们首先通过冒烟测试方法判断系统是否达到可进入测试的条件。根据系统不同，这个冒烟测试一般需要大约2-3天时间。对于集成测试入口准则一般是至少已经完成了所有接口功能的90%且核心接口功能已经完成，并承诺在集成测试后面轮次完成所有的接口功能。在冒烟测试中，会根据这个接口功能表进行统计，哪些接口功能已经完成，哪些没有完成，已经完成的接口所占的比例，只有达到了入口准则才能进入后续的集成测试。对于功能测试也是采用入口准则判断的方式，只要达到了入口准则，才能进入功能测试。

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

2.4.1 工作分工

10 / 30

虽然说测试任务分工是项目组内部的事情，但是也可能会对项目完成质量产生一定的影响。金融行业的软件系统是比较庞大和复杂，子系统、模块功能的数量，用户角色都比较多，同时也要考虑项目组每个成员的技术特点、技能水平。需要综合考虑上面这些因素，然后采取一种相对完善合理的方式进行工作分配。

在工作分工上除了考虑系统模块和人员技能水平等外，也要考虑，分工方法会不会造成遗漏，也就是分工会不会产生测试工程师各自负责测试任务之间的空当，测试项目经理必须判断分工方法的优点和缺陷，并采取相应的措施进行必要的弥补。其实工作分工跟软件系统接口一样，在接口的地方是非常容易引起问题的。在分工时，项目组经理或测试组长必须把能写在任务安排中的工作都详细列出来，并让测试工程师明确自己所承担的测试任务。

在工作分工后，执行多个轮次测试时，要考虑每个轮次是否交换测试工作分工，交换与否各有利弊，项目经理要权衡到底采用那种模式。在黄金项目中，我们采取了重点模块专人负责到底，而部分模块采取交换的方式。由于考虑到时间周期短，轮次较多，为保证测试质量是由专人负责，未交换工作。如果在时间允许的情况下，交换工作对测试工作有一定好处。

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

2.4.2 测试轮次

黄金项目功能测试采用了3轮集成测试，5能测试，3轮性能的方案。到底采取多少轮测试才能保证系统质量呢？理论上讲，轮次越多越好。但是对于项目来说，项目周期是有限的，所以要在有限的周期内，尽量多安排测试轮次。尤其是功能测试，应该至少

11 / 30

执行5能测试，得到的缺陷趋势图才比较清楚的展示缺陷的收敛情况。

在每个测试轮次中，要执行全部的测试用例，这也是客户的要求。如何分工中包括对测试用例的分工，则应该让测试工程师明确清楚自己所要执行的测试用例标识，以免产生遗漏。

在每个轮次中，我们都会统计执行测试用例情况，测试需求覆盖情况，尤其是每个轮次中，无法执行的测试用例，也就是无法覆盖的测试需求和业务功能需求。统计每个轮次所提交的缺陷数量，处在各种状态的缺陷，缺陷的严重级别分布如何，缺陷所在的模块等等。这些每个轮次的数据会统计在每个轮次的测试工作小结报告中，也是最后测试报告中不可或缺的内容，所以必须认真的统计好这些数据。

2.4.3 测试数据

由于在设计测试用例中没有添加测试数据，所以在测试人员在执行测试流时，必须构造测试数据。下图是测试人员记录的输入测试数据，执行用例时，输入这些测试数据，根据当时的价格行情，在Excel中计算出各种费用，再与系统查询出来的费用进行对比，从而判断系统计算是否正确。

12 / 30

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

2.4.4填写并跟踪缺陷报告

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

在执行前，首先对Butterfly工具进行培训，使所有项目组人员掌握该工具的使用，尤其是客户确定的缺陷处理流程，黄金交易管理系统按照下面的流程处理缺陷。

需要强调的一下是，在黄金项目中，测试人员提交缺陷后，PM可以先把缺陷指派到业务人员，由业务人员确定是否为缺陷，这些缺陷往往是建议性缺陷，测试人员提出的这

13 / 30

种类型缺陷，有可能会引起发布需求变更，所以需要得到业务人员的确认。

对测试人员还要进行缺陷严重级别分类方面的培训，对于缺陷严重级别的分类，兴业银行在测试规范中已经具有了分类标准，但是并没有对这些分类标准的解释，需要具有经验的人员根据经验和分类规范去讲解如何对缺陷进行分类。

对如何缺陷报告，我们也有一个规范，例如：缺陷描述要如何描述才能更清楚，更容易被开发人员理解。缺陷现象和再现步骤、截图、附件类型等也各有要求，在测试执行之前，要让项目组所有成员掌握这些要求，以便填写缺陷报告的统一性、可读性。

在测试计划中，已经明确缺陷的修复周期，对于标识紧急程度“一般”的缺陷，要求2-3个工作日内进行修复，而对于紧急程度为“紧急”的缺陷，要求在1-2 个工作日内进行修复，以免阻碍测试执行进展。除了对开发修复缺陷的要求外，也对测试组验证缺陷进行了要求，要求“已修”复缺陷必须在1-2个工作日内进行验证测试。

14 / 30

缺陷数据的统计整理、汇报。项目组要定期的整理缺陷报告的数量、包括当前所处各种状态的数量，各种严重级别缺陷的数量，让客户项目经理了解当前测试的成果，同时在后面轮次发现缺陷有收敛趋势时，也让项目组逐渐感受到系统缺陷越来越少，系统越来越稳定。

对于有争议的缺陷通过项目组协调会议解决。对于有争议的缺陷，我们会整理出来，缺陷协调会议上，由业务人员、技术人员、质量管理人员等评估这些缺陷该如何解决。

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

2.4 测试执行过程

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

在研发团队交付系统进入测试执行之前，我们首先进行入口准则检查—通过冒烟测试方法判断交付系统是否达到了可进入测试的条件。依据系统不同，这个冒烟测试过程一般需要大约1~2天时间。对于集成测试入口准则一般是至少已经完成了所有接口功能的90%且核心功能已经完成，并承诺在集成测试阶段完成剩下的所有接口及相关功能。冒烟测试会根据集成测试需求进行，测试需求主要是接口功能。在冒烟测试中，会统计出哪些接口功能已经完成，哪些没有完成，已经完成的接口所占的比例，只有达到了入口准则才能进入正式集成测试。对于功能测试阶段同样采用入口准则判断的方法，只要满足了功能测试的入口准则，才能进入功能测试。

根据我们的测试经验，很多项目由于周期短、任务重，往往到了研发项目组交付版本测试时，还有部分功能没有完成，这种情况下交付系统的质量不太可能高，且需要在测试

15 / 30

团队测试执行过程中，研发团队会继续编写尚未完成功能的代码，形成测试与研发并行的局面，使测试执行和研发交错在一起，往往会出现版本管理混乱、研发最终完成全部功能的时间难以确定。而项目一旦出现延期，由于各方相互推卸责任而出现难以判断无法上线的根本原因，所以我们在项目中采用T+D形式确定测试时间，T是交付测试版本通过冒烟测试的时间，D是测试过程周期。

2.4.1 工作分工

测试任务分工一定程度上会对项目完成质量产生一定影响。金融行业的软件系统比较庞大和复杂，子系统接口、业务功能模块数量多、用户角色都比较多，同时也要考虑测试团队每个成员的技术特长和技能水平。需要综合考虑上面这些因素，然后采取一种相对完善合理的方式进行工作分配。

在工作分工上除了考虑系统模块和人员技能水平等外，也要考虑，分工方法会不会造成遗漏，也就是分工会不会产生测试工程师各自负责测试任务之间的空档，工作分工跟软件子系统接口一样，在接口的地方是非常容易引起问题的。项目经理必须判断不同分工方法的优缺点，并在实施时采取相应的措施进行必要的弥补。在分工时，项目组经理或测试组长必须把能写在任务安排中的工作都详细列出来，并让测试工程师明确自己所承担的测试任务和责任。

在工作分工后，执行多个轮次测试时，要考虑每个轮次是否交换测试工作分工，交换与否各有利弊，项目经理要权衡到底采用那种模式。在这个项目中，我们采取了重点模块专人负责到底，而部分模块采取交叉方式。由于考虑到时间周期短，轮次较多，为保证测试质量是由专人负责，未交换工作。

16 / 30

通过后面系统上线反馈出现的问题来看，是有一些遗漏的。如果在时间和资源允许情况下，交换测试任务在一定程度上会减少遗漏。

2.4.2 测试轮次

在黄金项目中功能测试采用了3轮集成测试，5能测试，3轮性能的方案。到底采取多少轮测试才能保证系统质量呢？理论上讲，轮次越多发现错误也会越多。但是对于项目来说，项目是有时间的，要在有限的周期内，保证每个轮次完成工作的前提下，尽量多安排测试轮次。尤其是功能测试，应该至少执行5能测试，得到的缺陷趋势图才会比较清楚的展示发现缺陷和修复缺陷是否收敛。

在每个测试轮次中，要执行全部的测试用例，这往往是客户的要求。在任务分工中，应该让测试工程师明确清楚自己所要执行的测试用例范围，以免产生遗漏。同时要求必须按照测试用例执行测试，在测试用例执行完成情况下，再做随机性测试。

在每个轮次中，我们都会统计执行测试用例情况，测试需求覆盖情况，尤其是每个轮次中，无法执行的测试用例，也就是无法覆盖的测试需求。统计每个轮次所提交的缺陷数量，处在各种状态的缺陷，缺陷的严重级别分布如何，缺陷所在的模块等等。这些每个轮次的数据会统计在每个轮次的测试工作小结报告中，也是最后测试报告中不可或缺的内容，所以必须认真的统计好这些数据。

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

2.4.3 测试数据

17 / 30

由于在设计测试用例中没有添加测试数据，所以在测试人员在执行测试流时，必须构造测试数据。下图是测试人员记录的输入测试数据，执行用例时，输入这些测试数据，根据当时的价格行情，在Excel中计算出各种费用，再与系统查询出来的费用进行对比，从而判断系统计算是否正确。

注：上面测试数据中的交易日期是测试中采用的日期，非用例执行日期。

2.4.4填写并跟踪缺陷报告

在黄金项目中，使用Hansky（汉星天）的Butterfly跟踪管理缺陷。

在执行测试用例前，首先对Butterfly进行培训，使所有项目组人员掌握该工具的使用，尤其是客户确定的缺陷处理流程，黄金交易管理系统按照下面的流程处理缺陷。

18 / 30

需要强调的一下是在项目中，测试人员提交缺陷后，缺陷分发负责人可以把属于需求方面的缺陷指派到业务人员，由业务人员确定是否为缺陷，如果为缺陷则可能会引起发布需求变更。

对测试人员还要进行缺陷严重级别分类方面的培训，对于缺陷严重级别的分类，某银行在测试规范中已经具有了分类标准，但是并没有对这些分类标准的解释，且分类侧重于计算机技术方面的分类而没有更多的从业务角度进行分类，所以需要具有客户方有项目经验的人员根据经验和分类规范去讲解如何对缺陷进行分类。

对如何填写缺陷报告，我们也有一个规范，例如：缺陷描述要如何描述才能更清楚，更容易被开发人员理解。缺陷现象和再现步骤、截图、附件类型等也各有要求，在测试执行之前，要让项目组所有成员理解这些要求，以便使填写缺陷报告具有统一性、可读性。

在测试计划中，已经明确缺陷的修复周期，对于标识紧急程度“一般”的缺陷，要求2~3个工作日内进行修复，而对于紧急程度为“紧急”的缺陷，要求在1~2 个工作日内进行修复，以免阻碍测试执行的进度。除了对研发修复缺陷时间的要求外，不要忘记测试组本身验证缺陷的时间，我们项目中要求对“已修复”缺陷必须在1~2个工作日内进行验

19 / 30

证。

缺陷数据的统计整理、汇报。项目组要定期的整理缺陷报告的数量、包括当前所处各种状态的数量，各种严重级别缺陷的数量，让客户项目经理了解当前测试的成果，同时在后面轮次发现缺陷有收敛趋势时，也让项目干系人体验到系统缺陷越来越少，在一定程度上说明系统越来越稳定。

对于有争议的缺陷通过项目组协调会议解决。对于有争议的缺陷，我们会整理出来，缺陷协调会议上，由业务人员、技术人员、质量管理人员等评估这些缺陷该如何处理。

黄金项目中部分缺陷列表截图如下：

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

2.4.5 问题/风险记录和跟踪

在黄金项目的测试过程中，要记录过程中遇到的问题和风险，并跟踪这些问题和风险的应对和问题的解决。

20 / 30

下面摘自黄金项目的风险和问题跟踪表：

在项目过程中，项目经理的主要职责之一就是要不断地分析项目潜在的风险和遇到的问题。风险管理是项目经理一项重要的事情，要不断洞察可能会影响测试进展和项目延期的事情，并通过各种措施规避这些风险的发生，或使风险发生时对测试的影响最少。而对于风险产生导致出现的问题，要找出问题的解决办法，让问题影响最小化，同时也要分析问题产生的原因，以便于总结经验教训，避免问题的再次发生。

2.4.6 测试环境

在我们所经历的测试项目中，测试环境一直是一个重要事情, 往往成为影响测试进展的主要原因。在黄金项目中，测试环境的问题尤其突出。

在黄金项目中，因为有移植测试，需要一套构造模拟移植数据的一期环境，性能测试需要一套环境，功能测试也需要一套环境，这样一共三套环境。每套测试环境中都需要银行核心系统、ACE和网银渠道等，且这些设备可能又不部署在一个网段中，防火墙、测试用机等都需要考虑。客户准备测试环境由于层层审核而往往需要很长时间，尤其是性能测

21 / 30

试环境要求与上线运营环境相同或相似的设备，通常使用为上线而采购的设备，这可能需要更长的采购时间，测试团队提出要求时，一定要考虑这些因素。

测试环境的维护。在黄金项目中测试环境的维护工作是由客户科技人员维护的，而被测试系统是由测试组来维护的。作为测试项目组，我们非常希望能够维护测试环境，但由于知识产权保护、安全等方面的原因，测试团队往往不能维护测试环境，但是提醒大家如果条件允许可以维护测试环境，这样对于测试组理解整个系统架构、安装部署测试和性能测试非常有好处。

2.4.7 配置管理

在黄金项目中配置管理使用汉星天的FireFly，测试组利用公司提供的测试配置清单单独建立一套配置库目录结构，对测试过程中的各种文档进行管理。

在整个测试过程中最重要的是被测试系统的版本管理。在测试计划中，我们约定每周二和周四升级版本，而在后面轮次中采取不升级时间的方式。前面几个轮次进行版本控制的目的是由于前期研发还有部分功能没有完成而研发不停的增加功能而发布版本，如果不加以控制，则可能每天都发布新版本，而后面轮次不再控制的原因是开发功能应该已经完成，且版本趋向于稳定。在缺陷管理工具Butterfly中发现缺陷和缺陷修复的版本要跟研发发布版本一致。

通过多个项目实践表明，控制好被测试系统版本，使测试执行过程比较清晰，验证缺陷也比较方便，时间过长和过短的发布版本，都可能影响测试进展。

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

22 / 30

3、技术运用

3.1 Excel的运用

利用Excel的统计计算功能验证系统中的公式。

该项目的测试理念-以会计清算为核心，以新增工作为重点，全力保证系统不会出现账务上的问题。在测试用例设计过程中，对了加深对计算公式的理解，我们用Excel列出系统所涉及到的所有公式，采用等价类划分和边界值等测试用例方法对公式中各个因子设计测试用例，覆盖计算公式的各种情况。

3.2 测试用例设计技术

在设计测试用例过程中，我们黄项目组引入了测试执行流。该功能是HPQualityCenter提供了该功能，我们充分利用该功能组织测试用例，让测试执行更符合最终用户的使用场景，同时也达到了测试用例的最大复用。

测试执行流截图如下：

23 / 30

3.3 自动化测试

在项目实施过程中，我们使用客户提供的HPQuickTestProfessional功能自动化测试工具，同时客户质量中心升级了HPQualityCenter，添加了一个业务组件，我们对新增加了组件进行了研究，决定采用业务组件框架组织自动化测试脚本。该组件的使用，可以降低自动化测试的难度，便于脚本的封装和后续的维护阶段测试。业务组件的使用请参考下图：

3.4 引入项目管理工具

24 / 30

引入了开源的DotProject作为项目管理工具，便于对成员进行分工，工作完成情况统计以及管理，也在一定程度了减轻了测试人员的写汇报的负担。

管理工具截图如下：

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

主要包括日报、周报和月报、Email、遇到问题时的汇报等。

测试中的书面日报、周报、月报

在黄金项目中，我们每天提交工作日报，在报告中汇总当日的工作进展，是否按照原计划完成了工作，如果产生了偏差，则产生偏差的原因，例如，测试环境没有准备好，系统接口没有数据、产生了阻碍性的bug等。在日报列出第二天的工作计划，需要其他协助或解决的事情等。

周报。我们每周汇总一个周报，根据客户模板填写，主要是汇报一周来的工作进展，是否产生偏差，人员资源的使用情况，列出风险，写出下周的工作等等。

25 / 30

在项目中，我们每个月编写月项目汇报。向客户领导汇报，向公司领导项目的进展情况。

把需要沟通的事情通过Email形式传递给客户，这种方式比较正规，且可以一次性把要沟通的内容和沟通对象都包括，且可以留沟通记录，是一种反映问题、解决问题等很好方式。而对于一些比较重要的事情，则可以写出文件，以文件形式反馈给相关各方。

4.2 会议沟通

会议沟通包括项目组例会、测试组例会、临时的协调会议、汇报等。

项目组例会是包括客户各方、开发公司、测试公司、QA等所有黄金项目干系人参与的每周进行的会议。在该会议上各方讲解工作进展、遇到的重大风险、下周的工作安排等。往往由各方主要项目参与人参加，主要是就项目中一些比较重大问题的沟通。

测试组例会是整个测试组每周召开的会议。主要是了解每个人的工作进展，遇到的问题，在例会上进行工作安排部署，解决测试过程遇到的技术问题、业务问题等等。

临时的协调会议、汇报通常是在针对项目过程中突发的一些问题，由测试组发起举行的临时会议，目的就是反映问题，汇报情况，并希望通过沟通达成共识或找到问题解决措施等。

4.3 口头和IM沟通

日常工作过程中的面对面的沟通，反映项目进展、遇到的问题、需要协调的事情等等；在项目中，口头沟通是使用最多的一种方式，由于项目各方在项目中关注的角度不同，对

26 / 30

业务的理解不同，对其他团队工作的了解程度不同等原因，不进行当面沟通往往是很难取得沟通效果，口头沟通往往可以迅速解决某些非重大问题，使工作进展更快速。对于比较重要的口头沟通，最好进行书面记录。

IM沟通：日常工作过程中利用即时通讯工具进行沟通；项目过程中的一些小问题可以通过在线沟通工具进行沟通。

5、项目管理

某银行黄金交易管理系统（二期）测试为一个外包测试项目，具有项目管理的所有特征，涉及到项目管理9大领域中的几个主要领域。相对于其他行业的项目，IT领域的软件测试服务要求必须对整个项目具有比较好的管理，才能在周期短、责任重的情况下保质保量的完成项目。测试工作是一种服务性质的工作，本身没有资源，这就要求项目经理能够调动所有的资源，为项目服务。

因为项目管理涉及到的内容非常多，我们摘取其中一些主要的内容与大家分享。

进度管理。项目整个测试执行周期为2个月左右时间，如果包括前面的测试设计时间，大约4个月左右时间。往往在项目开始时，已经确定了上线日期，所以往往根据研发的进度计划确定测试进度计划，如果研发交付延期，测试设备无法按时到位等原因则必然对测试产生影响。所以在制订测试进度计划时，要充分考虑到这些风险。在测试过程中，也要不断的预判风险，规避风险，解决影响项目进展的问题，保证测试进度是项目经理的一项主要任务。

范围管理。确定好黄金项目的测试所涉及到的业务范围，确定测试阶段，以便做好测

27 / 30

试计划，评估好项目进度、所用资源以及资源分配等。

质量管理。黄金项目中严格控制项目质量。控制质量主要包括项目组内部同行评审、项目经理审查，公司项目管理委员会和项目总监的审查，QA监督，以及客户现场的QA、质量中心测试经理、业务经理和技术经理的审查、各种测试计划、测试用例和测试报告的评审等等。质量管理也是项目经理日常的主要工作之一。

资源管理。项目组只是提供测试服务，工作需要的资源主要包括人力资源、测试环境和设备资源。项目经理需要在测试过程中做好人力资源的管理，根据项目的进展，申请资源并安排好人力资源的分配。同时也要不断的跟客户设备管理部门沟通，保证测试环境和测试设备的到位和部署。

在资源管理中最重要的人员管理。包括工作安排、加班、请假、绩效考核、人员培训、培养等都要进行考虑。项目经理既要保证项目的顺利进行，同时也要考虑员工的工作情况、职业发展、兴趣爱好等等。

风险管理。风险控制是项目经理的一项重要工作，项目经理必须对项目进展过程中可能出现的风险进行预判，便于同各方进行沟通，规避风险演变为问题出现，或者尽量让风险出现时对项目影响最小。黄金项目中，我们维护一张问题和风险跟踪表。

6、经验体会

经过近半年的项目实施，我们顺利的完成了某银行黄金交易管理系统（二期）项目测试工作，提交了200多个不同级别的缺陷，增强了软件系统的质量。目前，项目准备就绪，等待上线。经过项目实践，整个项目组积累了一些经验，也获得了一些体会，下面与大家

28 / 30

进行分享。

1、沟通是项目成功的关键因素

测试工作这样服务性质的工作决定了测试项目组需要跟项目各方进行沟通。项目干系人各方所站的角度不同，对同一个问题所反映出的态度也不同，所以项目经理需要根据项目干系人不同，从不同的角度去进行沟通，往往可以获得比较好的沟通效果。

2、WBS/工作任务拆分需要权衡利弊

测试工作本身涉及到的工作内容比较多，如何对工作进行拆分，以便项目组成员的任务分配。按照模块功能分工、还是安装角色分工等，各轮次人员负责部分是否更换，还是一个测试工程师负责到底。这些都要权利利弊，综合考虑后确定。

3、性能测试范围和环境的确定尤其重要

目前，不同的人对系统性能指标的理解和认识不尽相同，所以性能测试计划要能让项目干系人理解，测试范围，测试指标的含义，测试计划中列出的指标是否与业务人员、质量控制人员的理解一致，否则，就要调整测试计划或进行充分的沟通，使项目干系人对性能测试计划达成一致意见。

4、测试理念的普及

目前，测试行业是一个新兴行业，很多人对软件测试不理解或理解上存在误区，所以我们作为外包测试团队，也要向项目干系人讲解测试方法、测试过程等，针对当前项目所采取的测试策略等，使项目干系人了解软件测试，了解项目测试过程，以求获得各方的配

29 / 30

合和理解，保证测试工作的顺利进展。

7、项目收获

通过黄金项目的测试实施，对于整个公司和测试团队来说，具有重大的意义。

1、项目实施小组，通过认真负责工作态度，赢得了客户的认可和赞誉，提高了公司在客户方的美誉度，为后续的战略合作奠定了坚实的基础；

2、本次项目实施，培养了一批具有外包项目实战经验的测试工程师；通过项目实践，真正是感受到了外包测试与测试本公司产品的不同，锻炼了队伍；

3、软件测试行业是一种服务性质工作，在项目工作中主要是依靠测试经验和测试流程规范，通过项目培养他们独特的金融行业测试视角，这是通过培训、理论学习等很难获得的；强化测试流程规范，尤其是细化的工作流程规范，增加可度量等指标，使测试工作更加规范，流程更加合理。

30 / 30