某银行项目外包测试案例

某银行工程外包测试案例〔一〕跟踪需求分析和设计过程该过程在整个工程的前期完成，主要集中在2008.5~2008.7时间段内。在需求设计阶段是客户业务需求逐渐形成的过程。测试人员在业务人员开始编写业务需求时，没有进入工程组，因为这时候的需求还往往只是一个初稿，没有成型，测试人员并不需要参与前期需求编写工作，而是在需求初稿已经完成，在需求可以拿出来在整个工程组讨论时，测试人员就可以参与到这个讨论过程。测试人员参与需求讨论可以从测试视角发现业务需求中描述不准确、不正确的地方，帮助业务人员做好需求分析工作，减少需求中遗漏。因为测试人员往往根据积累了相同业务领域的经验，把测试过的工程需求与当前工程需求进行比照分析，更容易发现当前需求中的缺乏之处，把经验提供应业务人员和工程组参考。测试人员在这个过程往往承当业务人员和研发人员桥梁的作用，测试人员往往接触过类似工程或业务，对业务的理解能力往往高于研发人员，所以在某些时候测试人员可以把业务人员的需求转化为容易被开发人员理解的方式阐述，而把开发人员的编程的方式、方法讲解给业务人员。例如，把需求中的“输入”描述修改“从列表框选择”，那么可以使需求更具体和明确。跟踪需求分析和设计过程也有助于理解业务，是对需求逐渐熟悉的过程。在这个阶段，需求还没有确定下来，所以还不太适合设计测试用例，而通过参与业务人员、开发人员的讨论，逐渐熟悉业务需求，可以理解业务人员的想法，有比拟充足的时间理解整个业务。通过参与需求分析和设计过程，可以找到测试重点和难点。通过在分析讨论过程中，了解业务人员最关心的功能局部，最担忧系统的功能局部等，也了解开发人员对业务的理解情况，开发人员最不清楚和最不理解系统的局部，这样在测试设计和测试过程中可以针对性的多设计测试用例。某银行工程外包测试案例〔二〕提取测试需求过程提取测试需求过程是在逐渐熟悉业务需求后，开始提取测试需求，主要是在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工具进行培训，使所有工程组人员掌握该工具的使用，尤其是客户确定的缺陷处理流程，黄金交易管理系统按照下面的流程处理缺陷。需要强调的一下是，在黄金工程中，测试人员提交缺陷后，PM可以先把缺陷指派到业务人员，由业务人员确定是否为缺陷，这些缺陷往往是建议性缺陷，测试人员提出的这种类型缺陷，有可能会引起发布需求变更，所以需要得到业务人员确实认。对测试人员还要进行缺陷严重级别分类方面的培训，对于缺陷严重级别的分类，兴业银行在测试标准中已经具有了分类标准，但是并没有对这些分类标准的解释，需要具有经验的人员根据经验和分类标准去讲解如何对缺陷进行分类。对如何缺陷报告，我们也有一个标准，例如：缺陷描述要如何描述才能更清楚，更容易被开发人员理解。缺陷现象和再现步骤、截图、附件类型等也各有要求，在测试执行之前，要让工程组所有成员掌握这些要求，以便填写缺陷报告的统一性、可读性。在测试方案中，已经明确缺陷的修复周期，对于标识紧急程度“一般”的缺陷，要求2-3个工作日内进行修复，而对于紧急程度为“紧急”的缺陷，要求在1-2个工作日内进行修复，以免阻碍测试执行进展。除了对开发修复缺陷的要求外，也对测试组验证缺陷进行了要求，要求“已修”复缺陷必须在1-2个工作日内进行验证测试。缺陷数据的统计整理、汇报。工程组要定期的整理缺陷报告的数量、包括当前所处各种状态的数量，各种严重级别缺陷的数量，让客户工程经理了解当前测试的成果，同时在后面轮次发现缺陷有收敛趋势时，也让工程组逐渐感受到系统缺陷越来越少，系统越来越稳定。对于有争议的缺陷通过工程组协调会议解决。对于有争议的缺陷，我们会整理出来，缺陷协调会议上，由业务人员、技术人员、质量管理人员等评估这些缺陷该如何解决。某银行工程外包测试案例〔八〕2.4测试执行过程测试执行过程是整个工程测试工作的中心，测试执行过程也是测试方案落实的过程。在研发团队交付系统进入测试执行之前，我们首先进行入口准那么检查—通过冒烟测试方法判断交付系统是否到达了可进入测试的条件。依据系统不同，这个冒烟测试过程一般需要大约1~2天时间。对于集成测试入口准那么一般是至少已经完成了所有接口功能的90%且核心功能已经完成，并承诺在集成测试阶段完成剩下的所有接口及相关功能。冒烟测试会根据集成测试需求进行，测试需求主要是接口功能。在冒烟测试中，会统计出哪些接口功能已经完成，哪些没有完成，已经完成的接口所占的比例，只有到达了入口准那么才能进入正式集成测试。对于功能测试阶段同样采用入口准那么判断的方法，只要满足了功能测试的入口准那么，才能进入功能测试。根据我们的测试经验，很多工程由于周期短、任务重，往往到了研发工程组交付版本测试时，还有局部功能没有完成，这种情况下交付系统的质量不太可能高，且需要在测试团队测试执行过程中，研发团队会继续编写尚未完成功能的代码，形成测试与研发并行的局面，使测试执行和研发交错在一起，往往会出现版本管理混乱、研发最终完成全部功能的时间难以确定。而工程一旦出现延期，由于各方相互推卸责任而出现难以判断无法上线的根本原因，所以我们在工程中采用T+D形式确定测试时间，T是交付测试版本通过冒烟测试的时间，D是测试过程周期。2.4.1工作分工测试任务分工一定程度上会对工程完成质量产生一定影响。金融行业的软件系统比拟庞大和复杂，子系统接口、业务功能模块数量多、用户角色都比拟多，同时也要考虑测试团队每个成员的技术特长和技能水平。需要综合考虑上面这些因素，然后采取一种相对完善合理的方式进行工作分配。在工作分工上除了考虑系统模块和人员技能水平等外，也要考虑，分工方法会不会造成遗漏，也就是分工会不会产生测试工程师各自负责测试任务之间的空档，工作分工跟软件子系统接口一样，在接口的地方是非常容易引起问题的。工程经理必须判断不同分工方法的优缺点，并在实施时采取相应的措施进行必要的弥补。在分工时，工程组经理或测试组长必须把能写在任务安排中的工作都详细列出来，并让测试工程师明确自己所承当的测试任务和责任。在工作分工后，执行多个轮次测试时，要考虑每个轮次是否交换测试工作分工，交换与否各有利弊，工程经理要权衡到底采用那种模式。在这个工程中，我们采取了重点模块专人负责到底，而局部模块采取交叉方式。由于考虑到时间周期短，轮次较多，为保证测试质量是由专人负责，未交换工作。通过后面系统上线反应出现的问题来看，是有一些遗漏的。如果在时间和资源允许情况下，交换测试任务在一定程度上会减少遗漏。2.4.2测试轮次在黄金工程中功能测试采用了3轮集成测试，5轮功能测试，3轮性能的方案。到底采取多少轮测试才能保证系统质量呢？理论上讲，轮次越多发现错误也会越多。但是对于工程来说，工程是有时间限制的，要在有限的周期内，保证每个轮次完成工作的前提下，尽量多安排测试轮次。尤其是功能测试，应该至少执行5轮功能测试，得到的缺陷趋势图才会比拟清楚的展示发现缺陷和修复缺陷是否收敛。在每个测试轮次中，要执行全部的测试用例，这往往是客户的要求。在任务分工中，应该让测试工程师明确清楚自己所要执行的测试用例范围，以免产生遗漏。同时要求必须按照测试用例执行测试，在测试用例执行完成情况下，再做随机性测试。在每个轮次中，我们都会统计执行测试用例情况，测试需求覆盖情况，尤其是每个轮次中，无法执行的测试用例，也就是无法覆盖的测试需求。统计每个轮次所提交的缺陷数量，处在各种状态的缺陷，缺陷的严重级别分布如何，缺陷所在的模块等等。这些每个轮次的数据会统计在每个轮次的测试工作小结报告中，也是最后测试报告中不可或缺的内容，所以必须认真的统计好这些数据。某银行工程外包测试案例〔九〕2.4.3测试数据由于在设计测试用例中没有添加测试数据，所以在测试人员在执行测试流时，必须构造测试数据。下列图是测试人员记录的输入测试数据，执行用例时，输入这些测试数据，根据当时的价格行情，在Excel中计算出各种费用，再与系统查询出来的费用进行比照，从而判断系统计算是否正确。注：上面测试数据中的交易日期是测试中采用的日期，非用例执行日期。2.4.4填写并跟踪缺陷报告在黄金工程中，使用Hansky〔汉星天〕的Butterfly跟踪管理缺陷。在执行测试用例前，首先对Butterfly进行培训，使所有工程组人员掌握该工具的使用，尤其是客户确定的缺陷处理流程，黄金交易管理系统按照下面的流程处理缺陷。需要强调的一下是在工程中，测试人员提交缺陷后，缺陷分发负责人可以把属于需求方面的缺陷指派到业务人员，由业务人员确定是否为缺陷，如果为缺陷那么可能会引起发布需求变更。对测试人员还要进行缺陷严重级别分类方面的培训，对于缺陷严重级别的分类，某银行在测试标准中已经具有了分类标准，但是并没有对这些分类标准的解释，且分类侧重于计算机技术方面的分类而没有更多的从业务角度进行分类，所以需要具有客户方有工程经验的人员根据经验和分类标准去讲解如何对缺陷进行分类。对如何填写缺陷报告，我们也有一个标准，例如：缺陷描述要如何描述才能更清楚，更容易被开发人员理解。缺陷现象和再现步骤、截图、附件类型等也各有要求，在测试执行之前，要让工程组所有成员理解这些要求，以便使填写缺陷报告具有统一性、可读性。在测试方案中，已经明确缺陷的修复周期，对于标识紧急程度“一般”的缺陷，要求2~3个工作日内进行修复，而对于紧急程度为“紧急”的缺陷，要求在1~2个工作日内进行修复，以免阻碍测试执行的进度。除了对研发修复缺陷时间的要求外，不要忘记测试组本身验证缺陷的时间，我们工程中要求对“已修复”缺陷必须在1~2个工作日内进行验证。缺陷数据的统计整理、汇报。工程组要定期的整理缺陷报告的数量、包括当前所处各种状态的数量，各种严重级别缺陷的数量，让客户工程经理了解当前测试的成果，同时在后面轮次发现缺陷有收敛趋势时，也让工程干系人体验到系统缺陷越来越少，在一定程度上说明系统越来越稳定。对于有争议的缺陷通过工程组协调会议解决。对于有争议的缺陷，我们会整理出来，缺陷协调会议上，由业务人员、技术人员、质量管理人员等评估这些缺陷该如何处理。黄金工程中局部缺陷列表截图如下：某银行工程外包测试案例〔十〕2.4.5问题/风险记录和跟踪在黄金工程的测试过程中，要记录过程中遇到的问题和风险，并跟踪这些问题和风险的应对和问题的解决。下面摘自黄金工程的风险和问题跟踪表：图片看不清楚？请点击这里查看原图〔大图〕。在工程过程中，工程经理的主要职责之一就是要不断地分析工程潜在的风险和遇到的问题。风险管理是工程经理一项重要的事情，要不断洞察可能会影响测试进展和工程延期的事情，并通过各种措施躲避这些风险的发生，或使风险发生时对测试的影响最少。而对于风险产生导致出现的问题，要找出问题的解决方法，让问题影响最小化，同时也要分析问题产生的原因，以便于总结经验教训，防止问题的再次发生。2.4.6测试环境在我们所经历的测试工程中，测试环境一直是一个重要事情,往往成为影响测试进展的主要原因。在黄金工程中，测试环境的问题尤其突出。在黄金工程中，因为有移植测试，需要一套构造模拟移植数据的一期环境，性能测试需要一套环境，功能测试也需要一套环境，这样一共三套环境。每套测试环境中都需要银行核心系统、ACE和网银渠道等，且这些设备可能又不部署在一个网段中，防火墙、测试用机等都需要考虑。客户准备测试环境由于层层审核而往往需要很长时间，尤其是性能测试环境要求与上线运营环境相同或相似的设备，通常使用为上线而采购的设备，这可能需要更长的采购时间，测试团队提出要求时，一定要考虑这些因素。测试环境的维护。在黄金工程中测试环境的维护工作是由客户科技人员维护的，而被测试系统是由测试组来维护的。作为测试工程组，我们非常希望能够维护测试环境，但由于知识产权保护、平安等方面的原因，测试团队往往不能维护测试环境，但是提醒大家如果条件允许可以维护测试环境，这样对于测试组理解整个系统架构、安装部署测试和性能测试非常有好处。2.4.7配置管理在黄金工程中配置管理使用汉星天的FireFly，测试组利用公司提供的测试配置清单单独建立一套配置库目录结构，对测试过程中的各种文档进行管理。在整个测试过程中最重要的是被测试系统的版本管理。在测试方案中，我们约定每周二和周四升级版本，而在后面轮次中采取不限制升级时间的方式。前面几个轮次进行版本控制的目的是由于前期研发还有局部功能没有完成而研发不停的增加功能而发布版本，如果不加以控制，那么可能每天都发布新版本，而后面轮次不再控制的原因是开发功能应该已经完成，且版本趋向于稳定。在缺陷管理工具Butterfly中发现缺陷和缺陷修复的版本要跟研发发布版本一致。通过多个工程实践说明，控制好被测试系统版本，使测试执行过程比拟清晰，验证缺陷也比拟方便，时间过长和过短的发布版本，都可能影响测试进展。某银行工程外包测试案例〔十一〕3、技术运用3.1Excel的运用利用Excel的统计计算功能验证系统中的公式。该工程的测试理念-以会计清算为核心，以新增工作为重点，全力保证系统不会出现账务上的问题。在测试用例设计过程中，对了加深对计算公式的理解，我们用Excel列出系统所涉及到的所有公式，采用等价类划分和边界值等测试用例方法对公式中各个因子设计测试用例，覆盖计算公式的各种情况。3.2测试用例设计技术在设计测试用例过程中，我们黄工程组引入了测试执行流。该功能是HPQualityCenter提供了该功能，我们充分利用该功能组织测试用例，让测试执行更符合最终用户的使用场景，同时也到达了测试用例的最大复用。测试执行流截图如下：3.3自动化测试在工程实施过程中，我们使用客户提供的HPQuickTestProfessional功能自动化测试工具，同时客户质量中心升级了HPQualityCenter，添加了一个业务组件，我们对新增加了组件进行了研究，决定采用业务组件框架组织自动化测试脚本。该组件的使用，可以降低自动化测试的难度，便于脚本的封装和后续的维护阶段测试。业务组件的使用请参考下列图：3.4引入工程管理工具引入了开源的DotProject作为工程管理工具，便于对成员进行分工，工作完成情况统计以及管理，也在一定程度了减轻了测试人员的写汇报的负担。管理工具截图如下：某银行工程外包测试案例〔十二〕主要包括日报、周报和月报、Email、遇到问题时的汇报等。测试中的书面日报、周报、月报在黄金工程中，我们每天提交工作日报，在报告中汇总当日的工作进展，是否按照原方案完成了工作，如果产生了偏差，那么产生偏差的原因，例如，测试环境没有准备好，系统接口没有数据、产生了阻碍性的bug等。在日报列出第二天的工作方案，需要其他协助或解决的事情等。周报。我们每周汇总一个周报，根据客户模板填写，主要是汇报一周来的工作进展，是否产生偏差，人员资源的使用情况，列出风险，写出下周的工作等等。在工程中，我们每个月编写月工程汇报。向客户领导汇报，向公司领导工程的进展情况。把需要沟通的事情通过Email形式传递给客户，这种方式比拟正规，且可以一次性把要沟通的内容和沟通对象都包括，且可以留沟通记录，是一种反映问题、解决问题等很好方式。而对于一些比拟重要的事情，那么可以写出文件，以文件形式反应给相关各方。4.2会议沟通会议沟通包括工程组例会、测试组例会、临时的协调会议、汇报等。工程组例会是包括客户各方、开发公司、测试公司、QA等所有黄金工程干系人参与的每周进行的会议。在该会议上各方讲解工作进展、遇到的重大风险、下周的工作安排等。往往由各方主要工程参与人参加，主要是就工程中一些比拟重大问题的沟通。测试组例会是整个测试组每周召开的会议。主要是了解每个人的工作进展，遇到的问题，在例会上进行工作安排部署，解决测试过程遇到的技术问题、业务问题等等。临时的协调会议、汇报通常是在针对工程过程中突发的一些问题，由测试组发起举行的临时会议，目的就是反映问题，汇报情况，并希望通过沟通达成共识或找到问题解决措施等。4.3口头和IM沟通日常工作过程中的面对面的沟通，反映工程进展、遇到的问题、需要协调的事情等等；在工程中，口头沟通是使用最多的一种方式，由于工程各方在工程中关注的角度不同，对业务的理解不同，对其他团队工作的了解程度不同等原因，不进行当面沟通往往是很难取得沟通效果，口头沟通往往可以迅速解决某些非重大问题，使工作进展更快速。对于比拟重要的口头沟通，最好进行书面记录。IM沟通：日常工作过程中利用即时通讯工具进行沟通；工程过程中的一些小问题可以通过在线沟通工具进行沟通。5、工程管理某银行黄金交易管理系统〔二期〕测试为一个外包测试工程，具有工程管理的所有特征，涉及到工程管理9大领域中的几个主要领域。相对于其他行业的工程，IT领域的软件测试效劳要求必须对整个工程具有比拟好的管理，才能在周期短、责任重的情况下保质保量的完成工程。测试工作是一种效劳性质的工作，本身没有资源，这就要求工程经理能够调动所有的资源，为工程效劳。因为工程管理涉及到的内容非常多，我们摘取其中一些主要的内容与大家分享。进度管理。工程整个测试执行周期为2个月左右时间，如果包括前面的测试设计时间，大约4个月左右时间。往往在工程开始时，已经确定了上线日期，所以往往根据研发的进度方案确定测试进度方案，如果研发交付延期，测试设备无法按时到位等原因那么必然对测试产生影响。所以在制订测试进度方案时，要充分考虑到这些风险。在测试过程中，也要不断的预判风险，躲避风险，解决影响工程进展的问题，保证测试进度是工程经理的一项主要任务。范围管理。确定好黄金工程的测试所涉及到的业务范围，确定测试阶段，以便做好测试方案，评估好工程进度、所用资源以及资源分配等。质量管理。黄金工程中严格控制工程质量。控制质量主要包括工程组内部同行评审、工程经理审查，公司工程管理委员会和工程总监的审查，QA监督，以及客户现场的QA、质量中心测试经理、业务经理和技术经理的审查、各种测试方案、测试用例和测试报告的评审等等。质量管理也是工程经理日常的主要工作之一。资源管理。工程组只是提供测试效劳，工作需要的资源主要包括人