从2009年9月份开始，我进入了金融业的另一个行业—保险行业，进行保险行业的测试。刚进入这个行业，测试工作忙，很少上来了，也没有发表什么文章，近来业务时间比较多一些，可以上来多与大家交流一下了。做了2年银行系统的测试，我想再做2年保险行业的测试，我想再出一本书，就是面向金融行业的，全部以金融行业的测试为案例，把自己的工作经验做个总结。今后也会陆续写点保险行业的测试经验，欢迎这个行业的朋友多多交流。

                                                        懒懒的写了一小段。

                                                        2009年11月29日

阅读指引

本书第1-2章是测试基础和方法论的介绍，读者可以有选择的阅读；第3-11章是以测试项目的实施过程为主线，把项目中各活动分别进行了讲解，全面展示了测试项目实施过程中的技术运用和方法运用。第12章是作者对项目管理的总结体会。本书正文后提供了报告模板共3份，可作为大型测试项目文档模板参考。

第一部分：测试方法论

第一章、  实践者的方法论，介绍软件测试目的、分类、活动流程、测试人员应掌握的一些协议及金融软件系统特点和测试特点。

第二章、  软件质量和缺陷报告，介绍软件质量和质量模型及子属性，缺陷跟踪流程和缺陷跟踪工具，缺陷故障模型及典型缺陷分析。

第二部分：测试计划和测试设计

第三章、文档审查和测试需求分析，介绍文档审查和评审，测试需求分析及QC中的测试需求管理。

第四章、测试设计，首先介绍常用测试用例设计方法和运用案例，项目中各阶段的测试用例设计，最后讲解在测试设计阶段所应该做的一些其他工作，例如熟悉“新”技术、“新”系统等。

第五章、做好项目测试计划，讲解如何编写测试计划，包括目标、范围、资源、进度、轮次、策略、风险、测试约定和约束条件等,提供一份测试计划模板。

第三部分：项目中的5种测试执行活动

第六章、单元测试及单元测试结果审核，介绍白盒测试基础，单元测试步骤、内容和用例设计。单元测试工具和测试驱动框架，JUnit介绍及运用案例，每日构建和单元测试结果审核。

第七章、产品集成测试，包括集成测试流程、策略、执行流程和结果分析等。

第八章、项目功能测试，测试环境搭建、数据准备、参数和流程配置、冒烟测试、工作分工、QC的测试执行要求，测试过程数据采集和分析以及界面测试中使用的流程和规范等。

第九章、项目性能测试，常用指标和术语。资源监控和数据采集，性能测试过程，全面展示了一个金融项目的性能测试项目全过程，是非常全面的一个案例。常见性能测试故障模型。

第十章、用户验收测试和测试报告评审，测试报告和测试报告评审。

第十一章、自动化测试，包括自动化工具QTP介绍，自动化测试流程，自动化脚本编写规范，QC和QTP构建自动化测试框架等

第四部分：项目管理

第十二章、项目管理，包括工作量评估模型，测试范围控制、质量管理、人员管理、风险管理、沟通、测试度量和配置管理等。

附录：

附录中包括了3份测试报告模板，包括功能测试报告模板、性能测试报告模板、测试总结报告模板，这三份模板提供读者编写测试报告或制作测试报告模板时参考

第一部分　　软件测试策略基础

为什么要编写测试策略？测试策略就是如何进行软件测试的计划。测试策略的目标包括：

取得利益相关者（比如管理部门、开发人员、测试人员、顾客和用户等）的一致性目标；

从开始阶段对期望值进行管理；

确保“开发方向正确”；

确定所有要进行的测试类型。

1、策略与软件测试策略

（1）策略：在一定的政治路线指导下，根据具体条件而规定的斗争原则、方式和方法。<新华字典>

（2）软件测试策略：在一定的软件测试标准、测试规范的指导下，依据测试项目的特定环境约束而规定的软件测试的原则、方式、方法的集合。

测试策略为测试提供全局分析，并确定或参考：

项目计划、风险和需求；

相关的规则、政策或指示；

所需过程、标准与模板；

支持准则；

利益相关者及其测试目标；

测试资源与评估；

测试层次与阶段；

测试环境；

各阶段的完成标准；

所需的测试文档与检查方法。

2、软件测试策略的重要性

（1）任何一个完全测试或穷举测试的工作量都是巨大的，在实践上是行不通的，因此任何实际测试都不能保证被测程序中不遗漏错误或缺陷；

（2）为了最大程度较少这种遗漏，同时最大限度发现可能存在的错误，在实施测试前必须确定合适的测试方法和测试策略，并以此为依据制定详细的测试案例。

3、软件测试策略的目的

是不是所有软件测试都要运用现有软件测试方法去测试呢？答案是否定的。依据软件本身性质、规模和应用场合的不同，我们将选择不同测试方案，以最少的软硬件、人力资源投入得到最佳的测试效果，这就是测试策略的目标所在。

4、软件测试策略的影响因素

软件测试策略随着软件生命周期的变化、软件测试方法、技术与工具的不同发生的变化。这就要求我们在制定测试策略时候，应该综合考虑测试策略的影响因素及其依赖关系。这些影响因素可能包括：测试项目资源因素、项目的约束和测试项目的特殊需要等。

5、软件测试策略的制定过程

（1）输入

需要的软硬件资源的详细说明；

针对测试和进度约束而需要的人力资源的角色和职责；

测试方法、测试标准和完成标准；

目标系统的功能性和技术性需求；

系统局限（即系统不能够提供的需求）等等。

（2）输出

已批准和签署的测试策略文档、测试用例、测试计划；

需要解决方案的测试项目；

（3）过程

1）确定测试的需求

测试需求所确定的是测试内容，即测试的具体对象。在分析测试需求时，可应用以下几条一般规则：

测试需求必须是可观测、可测评的行为。如果不能观测或测评测试需求，就无法对其进行评估，以确定需求是否已经满足。

在每个用例或系统的补充需求与测试需求之间不存在一对一的关系。用例通常具有多个测试需求；有些补充需求将派生一个或多个测试需求，而其他补充需求（如市场需求或包装需求）将不派生任何测试需求。

测试需求可能有许多来源，其中包括用例模型、补充需求、设计需求、业务用例、与最终用户的访谈和软件构架文档等。应该对所有这些来源进行检查，以收集可用于确定测试需求的信息。

2）评估风险并确定测试优先级¤

成功的测试需要在测试工作中成功地权衡资源约束和风险等因素。为此，应该确定测试工作的优先级，以便先测试最重要、最有意义或风险最高的用例或构件。为了确定测试工作的优先级，需执行风险评估和实施概要，并将其作为确定测试优先级的基础。

3）确定测试策略

一个好的测试策略应该包括：实施的测试类型和测试的目标、实施测试的阶段、技术、用于评估测试结果和测试是否完成的评测和标准、对测试策略所述的测试工作存在影响的特殊事项等内容。

如何才能确定一个好的测试策略呢？我们可以从基于测试技术的测试策略、基于测试方案的测试策略两个方面来回答这个问题。

①  基于测试技术的测试策略的要点

著名测试专家给出了使用各种测试方法的综合策略：

任何情况下都必须使用边界值测试方法；

必要时使用等价类划分方法补充一定数量的测试用例；

对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，看是否达到了要求；

如果程序功能规格说明中含有输入条的组合情况，则已开始可以选择因果图方法。

②  基于测试方案的测试策略

对于基于测试方法的测试策略，一般来说应该考虑如下方面：

根据程序的重要性和一旦发生故障将造成的损失来确定它的测试等级和测试重点；

认真研究，使用尽可能少的测试用例发现尽可能多的程序错误，避免测试过度和测试不足!

第二部分　　测试策略的方法

软件测试的策略、方法和技术是多种多样的。对于软件测试技术，可以从不同的角度加以分类：从是否需要执行被测软件的角度，可分为静态测试和动态测试。从测试是否针对系统的内部结构和具体实现算法的角度来看，可分为白盒测试和黑盒测试。

1.  静态方法与动态方法

所谓静态方法是指不运行被测程序本身，仅通过分析或检查源程序的文法、结构、过程、接口等来检查程序的正确性。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。
 
　　动态方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率和健壮性等性能，这种方法由三部分组成：构造测试实例、执行程序、分析程序的输出结果。

2.  功能测试与结构测试

（1）功能测试

功能测试是指在对程序进行的功能抽象的基础上，将程序划分成功能单元，然后在数据抽象的基础上，对每个功能单元生成测试数据进行测试。用这种方法进行测试时，被测程序被当作打不开的黑盒，因而无法了解其内部构造，因此又称为黑盒测试。

黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用。在测试时，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当接收输入数据而产生正确的输出信息，并且保持外部信息的完整性。

在功能测试中，被测软件的输入域和输出域往往是无限域，因此穷举测试通常是不可行的。必须以某种策略分析软件规格说明，从而得出测试用例集，尽可能全面而又高效地对软件进行测试。下面就说明几种功能测试的方法：

a.  等价类划分

所谓等价类，就是指某个输入域的集合，集合中的每个输入对揭露程序错误来说是等效的，把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例，这就是等价类划分方法。它是功能测试的基本方法。

b.  因果图法

因果图是一种形式语言，由自然语言写成的规范转换而成，这种形式语言实际上是一种使用简化记号表示数字逻辑图。因果图法是帮助人们系统地选择一组高效测试用例的方法，此外，它还能指出程序规范中的不完全性和二义性。

c.  边值分析

实践证明，软件在输入、输出域的边界附近容易出现差错，边值分析是考虑边界条件而选取测试用例的一种功能测试方法。所谓边界条件，是相对于输入和输出等价类直接在其边缘上，稍高于和稍低于其边界的这些状态条件。边值分析是对等价类划分的有效补充。

（2）  结构测试

结构测试是根据被测程序的内部结构设计测试用例的一类测试，又称为白盒测试。白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能。其主要方法有逻辑驱动、基路测试等，主要用于软件验证。白盒法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。白盒法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。

与功能测试不同的是，结构测试涉及程序内部结构。尽管用户更倾向于基于程序规格说明的功能测试，但是结构测试能发现潜在的逻辑错误，而这种错误往往是功能测试发现不了的。它们各有利弊，常常结合使用。

第三部分　　测试策略文档范例

●  测试目的：

（1） 测试的范围，哪些功能要包括在内，哪些要排除在外

（2） 谁是客户和最终用户，谁就是测试结果的验收者

（3） 测试的次序和日程安排

（4） 验收的条件，成功因素，限制

●  资源需求：

（1） 制定计划和运行测试需要哪些技术和经验

（2） 相关人员的角色和责任

（3） 谁将对测试工作进行全盘协调

（4） 谁负责测试资料管理，版本控制，错误跟踪

●  测试环境：

（1） 用于测试的系统配置怎样

（2） 需要什么自动化工具

（3） 需要哪些测试数据（数据库和输入交易），如何安装

（4） 您如何前调系统时钟

●  测试过程：

（1） 运行测试时要遵循哪些过程（设置、执行、记录）

（2） 测试案例如何制定，其标准格式是什么

（3） 测试案例定义的覆盖要求是什么

     1、软件培训课程开发，重点是软件测试培训课程开发；

        包括开发语言，脚本语言，数据库，操作系统，测试工具，单元测试，性能测试，功能测试，测试用例设计，白盒测试，JUnit、CppUnit、Dunit 等，LoadRunner，QTP。

     2、实习项目开发，重点是软件测试实习项目开发；

        有多个真实系统，提供学员/学生进行系统功能测试，性能测试实战。

     3、提供软件测试类企业内训。

        培训项目见上面。

     4、面向社会进行软件测试专题培训。

        主要是利用周末进行为期两天的培训。

        欢迎合作联系。

    测试需求：

    要对公司提供的Web services进行测试，包括功能和性能，当然只是测试压力。 功能就是把从web services 调用中把提交一条发送的WAP push广告信息插入到数据库，因为数据库表之间有关联，所以插入后数据后，会自动选择决定选择投放的频道，当用户单击频道上的链接后再显示广告文字或图片。功能就是要测试插入一条广告后，是否正确的选择频道，并且插入的信息是正确的。性能测试则是测试当前服务器能够部署的web services能处理多少条插入的广告信息。

   测试开发设计：

   把发布的Web services地址直接添加到测试开发的web references中，通过在C#中直接调用Web services方法，把从界面的广告信息传递给该方法。为了检验插入是否正确，打开数据库读取字段与测试数据进行比对。在压力测试时，通过开辟多个线程，向系统施加压力（本系统在压力时，没有改变插入的数据，其在数据库表中因为有ID为主键，所以不会冲突）。

  界面如下：

  自动化测试无处不在，只要有时间，有条件，可以随时开发适合的测试小工具，满足测试的需要。下次再讲解一个直接通过读取页面链接，进行压力测试的例子。

      下面是系统界面截图：

下面是Excel形式所有员工工资总表，各字段内容可定制。

发送后每个员工收到的工资条如下：

  该软件可灵活定制，可以转让源码，财务发工资条的好帮手，现低价出售，每版本费用大约在100元左右。

     提供电子商务等网站、桌面应用系统、电子政务等所有系统调用，通过客户机或服务器连接该模块，直接发送短信、Wap push和彩信。彩信可模拟网关（模拟发送号码）。使您的系统集成短信、彩信信息发发送，把信息直接投递给您的客户，可支持客户短信回复。 

     模块组成：

     1、客户机或服务器上的监控发送模块，把数据库中的信息直接发送；

     2、接收模块，提供Web service和动态链接库，客户可以直接把发送内容通过该模块保存在数据库。

     数据库支持：

     Oralce、SQL server、MySql等

     部署：

     1、web service可以直接被大多数开发语言调用；

     2、C#和C++两种形式的动态链接库支持调用；

     系统组成和部署：

     1、Modem模块为硬件部分，直接发送短信、彩信和Wap push的硬件，支持USB和串口两种；

     2、监控部分原理为对数据库中的发送信息进行轮询，如果有发送信息，则调用发送方法直接发送，并显示发送是否成功结果。

     简易界面截图如下（界面可定制）：

    Web service部分：

 如果有需要的客户请联系：

 manok@tom.com，QQ：36115774，功能可定制，价格低廉，可提供源代码

如下图，你在安装到“数据库服务器配置”配置页面时，要如图填写，这里的“服务器名称”是指oracle数据库安装所在的服务器名称，非数据库名称。如果是本机输入localhost即可，如果是其他服务器，输入IP地址即可。数据库管理员用户名和密码没有问题，输入你在安装数据库设定的密码，这里默认使用system账户，就不用换了。下面的那个“显示高级选项”一定要选中，再单击【下一步】，很多人没有选中这个复选框，没有修改;QC默认给定的数据库SID名称而报错“数据库连接属性不正确”。

在下图中。前面3个编辑框中的设定一般不用修改默认即可，但是错在Oracle SID这个值，QC安装过程中，其带来的默认值为数据库服务器的名称，这个可能是QC开发人员所犯的一个错误而产生的缺陷。如果你上一页输入的是localhost，这里他也会显示localhost，显然这个不是Oracle SID，所以要修改为你安装数据库时所给定的SID名称。

后面选择默认表空间，如果自己没有建立表空间，则选择系统默认给定的一个也可。自己建立表空间为了数据安全。

这一页就是我们建立数据库的安装参数摘要。

最后祝愿大家安装顺利，使用好这个强大的测试管理工具QC。

   购买了《编程之美》这本书，真是希望了解微软的高手们对编程的理解。但是当阅读到本书的VI 面试杂谈时，有一段话，我深感意外，“那些只会用鼠标点击测试，然后报告bug的人员叫Software Test Engineer（STE），这样的事一般会外包给别的公司。“，我对作者及编辑对软件测试工程师工作的理解不敢苟同，测试工程师的工作也有非常多的技术含量的，其工作也不仅仅是点击鼠标进行测试，微软可能是这样，据我了解微软有测试驱动开发和测试工程师两种岗位，测试工程师是按照测试驱动开发工程师开发完成的测试工具去做测试的，但是国内或国外，基本上还不是这样做测试，不像微软去招聘一位家庭主妇去做Windows或Office的点击测试，测试工程师是需要大量的测试设计、测试分析的。

    该书的作者都是微软的员工，书的舆论导向对测试行业的发展无意，对测试工程师工作的误解，对测试外包公司也是一种蔑视，作为向国内大众发行的书，这种描述是对测试行业认知上的偏激和错误理解，希望你们做出妥善处理，消除对测试工程师及测试外包公司的误解和蔑视，做益于软件行业发展的事情，做促进软件质量发展的事情。测试工程师和开发工程师一样，都是为了公司推出高质量的产品，工作没有贵贱之分，你微软认为把技术含量低的工作外包给公司是公司行为，并不具有代表性，无论如何不能伤害国内正在发展之中的软件测试行业及广大测试工程师。

来源：中国经济新闻网-中国经济时报  作者：龙昊

    中国经济新闻网讯：记者龙昊北京报道  ４月２８日，金融ＩＴ综合解决方案提供商东南融通宣布，以１００％现金收购国内保险ＩＴ服务领域企业尚洋信德。收购完成之后，东南融通在保险ＩＴ解决方案市场的整体市场份额将居国内第二位。

    东南融通是中国第一家在纽交所上市的软件企业，也是中国本土排名第一的银行ＩＴ解决方案提供商，２００６年进入保险行业。ＩＤＣ的研究报告显示，合并前东南融通自身保险业务在中国保险ＩＴ解决方案市场中的整体份额位居第四位，在保险管理类解决方案市场位居第一位。公司主要客户覆盖了太平洋保险、中国平安、泰康人寿、新华人寿等保险机构。

    成立于１９９４年的尚洋信德则植根于保险ＩＴ解决方案市场，公司与中国人保、中国人寿、太平洋、新华等保险公司建立了良好的业务伙伴关系。

    专家认为，ＩＴ解决方案市场的整合将有利于提升解决方案商的技术实力和服务质量，也为合并后的融通尚洋在保险领域带来了更加广阔的成长机会。

   1、国内企业还是受金融危机的影响，在人才网站发布的招聘信息大部分是在做广告；

   2、自己年龄大了，且薪水要求也较高（相对于测试岗位薪水），所以更少有人问津；

   3、自己在能力还存在不足，一直无法面对外语口语，毕竟听说可能是全程外语免试尤其是印度人免试时，就担心；

   4、不管是做产品还是做项目，每个公司还是考虑成本最小化，利益最大化，所以在经济形势不太好的前提下，减少人员的成本是必须考虑的；

   5、自己的经历问题。先是在航天做软件测试，后面做培训，后面在分众做无线业务，最后2年金融行业外包带团队做大型项目的项目实施是最重要的经历，但是时间不是太长。

    现在静下心来，想想走过的路和未来的路

    作为测试人员，我曾经感到欣慰几件事情：

    1、研发经理曾对我说：你是见过的最厉害的测试人员，能开发能测试；

    2、某外包项目结束，研发人员的下一个项目还是让我们原班测试团队去实施；

    3、测试视野和测试视角开拓，曾经用扩音器测试无线引号是否接收到，软件测试需要根据测试需要想办法，尤其是异常条件的构造；

一、国内银行软件项目外包的几个阶段 

1、20世纪80年代，手工操作向电算化迈进，基本上自己开发自己实施。

2、20世纪90年代，建设城域联网系统，集成商开发实施。 

3、20世纪90年代末期，建设省域集中的系统，集成商与银行合作开发实施。 

4、21世纪开始，建设全国集中的系统，银行软件开发中心为主，专业软件开发商参与开发。 

5、将来，采购成熟软件产品成为银行的自主开发平台。 

二、国内银行软件项目外包的现状成因 

国内银行软件项目实施经历了从自主开发到依赖集成商开发到银行自主开发的历程，从自主开发到依赖集成商开发这一里程，暂且不表。本文集中探讨依赖集成商开发到银行自主开发的这一历程，我们先来分析一下这一历程的成因： 

1、从集成商方面来讲，他应用软件的开发是以带动硬件销售为目的的，在20世纪90年代可以利用硬件的高额利润来维持其软件开发上的成本投入，但进入21世纪以后，硬件价格越来越透明，其利润越来越薄，以软养硬的目标已经越来越不可能了，这也促使其软件的应用开发必须要追求好的产出，这就与银行思路形成了一定的矛盾。 

2、从银行方面来讲，随着应用系统的建设，银行已经储备了大量的应用软件开发人才和银行业务系统设计专家，特别是随着数据向总行的集中，应用软件项目开发逐步集中到总行以后，各总行软件开发中心从分行抽调了大量的技术和业务人才，使其完全有能力来自主实施其应用项目的开发。 

3、从大环境来看，金融向外资开放日益临近，金融产品创新将越来越多，银行应用系统也越来越复杂，应用系统的专业化程度也越来越高，原来的系统集成商的开发能力已经不能满足银行业务发展的需要，这也需要银行的软件开发随之转化思路，形成以软件开发中心为主，专业应用开发商为辅的应用项目开发思路。 

三、目前银行应用系统开发模式的优劣 

各大银行目前都成立了规模惊人的软件开发中心，工行形成了以珠海软件开发中心为主，上海、浙江、广州、北京软件开发分部为辅的软件开发队伍，拥有开发力量3000多人；农行形成了以北京丰台开发中心为主，浙江、广东、福建等地正在逐步完善开发分部建设，拥有开发队伍近2000人；建行形成了以厦门开发中心为主，北京、上海、湖北等地为分中心的软件开发队伍，拥有2000多人的开发队伍；中行以半公司化运作的北京博科公司为主，在北京、深圳两地建设了两个开发基地。 

各大银行的总行软件开发中心发展都不超过8年，除中行外规模都已经翻了四五番，开发的应用项目都已经过千项，各大银行这么热衷于建设软件开发中心，肯定有他热衷的理由： 

1、自己掌握应用系统开发的主动权，适合本行的实际需求。 

2、自己开发的应用自己便于维护。 
3、节省了软件外购的成本。 
4、吸收消化分行软件开发人才，使数据上收后分行的技术骨干不至于流失。 
各大银行在热衷建设软件开发中心的同时，也非常注重与专业银行软件开发公司的合作，并在专业公司的配合下，完成专业技能要求教高，非银行传统业务领域的创新业务应用系统开发，比如CTI、保险、证券、理财等应用系统的开发就主要借助专业公司的力量来完成，而以往传统的以两联两天为代表的银行系统集成商正在退出各大银行的应用软件项目建设。 
当然，这样的应用软件项目开发模式并不是十全十美的，主要存在如下缺陷： 
1、由于各软件开发中心人员，特别是近两年进入软件开发中心的大部分开发人员编制都不属于总行，当数据集中结束一段时间后，总行项目将越来越少，总行对开发人员需求也将不再迫切，待遇降低裁减人员将不可避免，这势必导致原有项目的开发人员流失，不能达到自己维护应用系统的目的。 
2、软件开发中心员工作为银行工作人员，国企本质导致的激励措施、项目管理、人力成本等因素难免不尽如人意，实际成本并不低。 
3、总行软件开发中心自视为总行领导，到分行实施项目或分行有需求更改要时响应速度比较慢，导致应用开发跟不上发达地区分行的业务需要。

4、软件开发中心的信息或其自我封闭性导致专业公司进入开发中心非常困难，并不能吸收到业界领先的专业应用产品。

四、四大国有银行软件外包模式的比较 
1、工商银行，是国内银行IT建设的领头羊，珠海工行软件开发中心是成立最早的软件开发中心，发展也最快，目前已经有1500多人的规模，它与其他四个研发分部组成了工行软件开发的基础。其软件外包采取以我为主，拿来主义的路子。 
由总行计财部召集，科技部门参与，首先举行标准的软件外包入围资格招标，只有具备入围资格的公司才能参与其珠海开发中心及其研发分部的具体应用项目的外包投标资格。 
珠海开发中心及研发分部的项目一般以自我开发为主，只有在项目紧张缺少人手或项目需要利用专业公司的技能来提高项目质量和开发效率时才会定向进行招标。 
某一个软件公司招标中了工总行1000个人月的外包资格标，实际上最终只参与了100个人月不到的外包项目。其外包项目采用每人天800到1000的标准与公司结算。 

2、农业银行，曾经是各大银行中开发力量最薄弱效率最低的银行，其在2005年开始实施的数据大集中项目中，一改常态显示出高水准的组织开发实施能力，最大的原因就是抛弃了一直以来以集成商开发应用为主体的开发模式，而是采用集中行内技术业务优势设计业务及技术标准，同时逐个项目引进业内最优秀的专业软件公司，吸收其产品或业务经验，并一起讨论开发应用的模式，并由软件开发中心技术人员与参与开发公司配对到各分行进行实施指导，既提高了协调效率又提高的实施效率。
其结果也导致了某家靠农行发家的大集成商几乎失去了农行软件应用的全部市场。其外包项目按18000一个人月的标准与公司进行结算。 
3、中国银行，曾经IT很牛气的一家银行，也是一直坚持软件开发中心进行公司化运作的银行，但是看看这几年的IT发展，已经彻底落在了其他大行的后面，其数据集中只好引进了一家在国内银行只有失败案例的国外公司来主导实施。其外包项目按25000一个人月的方式与公司结算。 
4、建设银行，其IT建设最多灾多难的一家银行。幸好建行在IT建设上舍得投入，也给各地分行充分放权，只要总行还没有规划内的应用，分行都可以先期实施，这样既保证了总行的规划又保证了分行及时响应变化多端的业务需求。 
其外包项目按技术及业务能力对参与人员进行考核，确定其每人月的费用标准，项目经理基本上是30000，五年以上开发经验25000，二年以上开发经验20000，一年左右开发经验15000，实习生没有费用，根据公司的实际人员投入情况结算费用。 
五、国内银行软件外包的机遇和挑战 
除中行外，各大银行的数据大集中都已经结束，是不是说国内软件企业的冬天就来了呢，应该说不是，更大的机遇正等待着服务与银行的软件公司：

◆银行新的业务领域不断在拓展，必然带来新的应用项目。

◆银行的管理系统自动化程度还不高，必须要用电子化手段来实现。

◆银行的资产管理业务电子化水平还很低，需要持续的投入。

◆银行的核心系统还需要从以帐户为中心向以客户为中心转变，将导致新的IT系统重建。

◆对银行业务监管的不断深入，也促进了其IT新的投入。

◆银行IT本身的复杂性也导致必须增加对自身运载的各种管理。 

当然机遇与挑战并存，传统的银行IT软件服务公司必须以变来适应变化的机遇：

◆首先要完善自身的精细化管理，降低成本，保证因人力外包而带来的利润率的下降。

◆提高外包队伍的稳定性，保证形成业界领先的外包品牌。

◆提高专业化的技术或业务能力，保证提供专业化的服务。

◆提高项目产品化的能力，把从外包学到的业务技术积累形成产品，推广到其他中小银行。

国内银行信息化建设要想提高商业价值，必须提高建设速度，而建设速度的提升，必须通过专业化外包来实现，中国银行业的外包之路任重道远。

一个系统经常会规划多年的业务规模，并对其性能提出要求。在测试设计时就需要测试在系统运行了多年时的性能，此时数据库中会有大量的历史数据，我们在测试时需要首先构造这些历史数据，我们称之为基础数据，这种情况的测试称为大数据量测试。由于构造数据的量级不同，我们会考虑采用不同的构造数据的方法。

常用构造基础数据的方法有：

1、使用自动化测试工具；

2、使用专用的测试数据产生工具；

3、使用数据库脚本语言直编写存储过程等产生；

4、使用其他的辅助工具产生；

下面讲解一下各种数据产生方法的优缺点。

1、使用自动化测试工具；

使用自动化测试工具如QTP、WinRunner、Robot等录制脚本，参数化需要构造的业务数据，然后运行脚本，通过反复运行业务场景在后台数据库中产生业务数据。
该方法的使用场合：不熟悉后台数据库结构，业务数据量需求不是很大。
优点：测试脚本录制一遍，可以反复运行。
缺点：参数化数据，需要对业务规则或数据库表有一定了解，否则会导致运行失败。

2、使用专用的测试数据产生工具；

常用的数据构造数据有Quest公司的DataFactory、开源DBMonster。

DataFactory 是一种快速的、易于产生测试数据工具，它能建模复杂数据关系，且有带有GUI界面。DataFactory是一个功能强大的数据产生器，它允许测试人员毫不费力地产生百万行有意义的测试数据。在使用中首先读取数据库中表的schema，即表的定义之类的内容，以列表的形式显示；然后由用户定制要产生数据的具体内容，如数字范围、字符串长度、要产生数据记录的个数等等，最后运行工程，生成数据。

DBMonster ( http://dbmonster.kernelpanic.pl )是一个Java的开源项目，通过JDBC方式连接数据库，因此可以在任何支持Java和JDBC的平台上运行。DBMonster开发的原意是为数据库开发者服务，可以协助产生大量的规则或不规则数据，便于数据库开发者基于这些数据进行数据库的调优。DBMonster通过两个XML文件（配置文件 和 schema文件）控制数据产生的行为，配置文件指明需要连接的数据库、连接使用的用户名和口令、需要操作的sheme、重试次数等全局设置，而 scheme文件则指明针对每张数据表的每个字段产生数据的规则。

3、使用数据库脚本语言直编写存储过程等产生；

要利用该方法构造基础数据，需要对后台数据库的表结构有一定的了解，例如表之间的关联关系、表的自增长主键如何实现的、表中的特殊字段的代码如何产生等。在熟悉表结构的基础上编写存储过程。对于复杂业务系统其数据库结构往往也相当复杂，可编写多个存储过程去分别产生各个表中的数据，然后由一个总的存储过程控制产生数据的规则和数量等。
该方法的适用场合：对数据库表结构非常熟悉，并且熟悉相应的存储过程编写。
优点：在数据库后台执行，效率非常高。
缺点：需要花大量的时间熟悉表结构和存储过程的调试。

4、使用其他辅助工具

使用PowerDesigner工具。

首先从数据库中Reverse Engineering出来数据库的Schema，然后设置测试数据所需要的Profile，以及各个表所需要的测试数据量，再生成Insert脚本，最后通过数据库的命令行程序执行这个SQL脚本将数据Insert到数据库中。对于不同的数据库命令行程序不同，比如对MS SQL Server是osql,对Sybase ASE是isql，对Oracle是sqlplus等。

该方法的使用场合：对数据库结构不熟悉，同时需要产生大量业务数据（如千万级）。
优点是：做了相应设置之后，Insert脚本自动生成，产生数据时不需要有业务数据。
缺点是：对于千万级的测试数据可能要分成若干个SQL脚本，分别产生，并行运行。对Oracle之类的数据库尤其要考虑时间日期以及时间戳类型的字段的值得处理问题。

使用PL/SQL Developer工具

在该工具中【Tools】菜单栏下有【Data Generator】菜单，利用该工具可以针对具体的表构造利用其构造规则，设置需要产生的数据。

TOAD工具：

TOAD工具与PL/SQL Developer工具类似，也是数据库客户端管理工具。TOAD套件中集成了数据生成测试工具和压力测试工具。数据生成测试工具有助于开发人员快速生成大量有实际意义且引用关系正确的测试数据，简化应用的测试过程。

使用Informatica工具：

Informatica是数据挖掘工具。可利用该工具构造海量数据。在现有的业务数据的基础上，使用Informatica工具，将现有的业务数据（平面文件数据或数据库表中的数据）多次重复装载到数据库中，可以快速构造出千万级的大数据量数据，且生成的大数据量数据在质量和可用性方面有保障。

优点：生成速度很快。

缺点：使用这种方法数据库相应的表中必须有相应的数据，且数据重复利用时也要考虑字段值重复问题。

    发现网上很有地方转载我blog中的文章，不注明出处，大部分写来自网上或论坛。作者作此声明，请尊重作者，以后转载本blog文章需全部注明，作者：manok，来自blog：www.bt-test.com（manok-软件测试中文站）

首先确定项目外包测试的核心问题—对项目外包测试的定位。

项目外包测试是一种服务性工作，所以把服务放在第一位是做任何事情的出发点。作为项目经理，一定要把这种思想告诉给我们的测试团队成员，树立服务意识。因为我们所有成员几乎都是做技术出身，放下思想包袱，站在客户角度上思考问题和做事情，任何问题都有解决的方法。

做项目管理，需要面对的事情非常多，下面我从工程管理、项目管理、人员管理等方面描述。

1、工程管理

某客户质量中心已经有了一套测试规范流程，在流程中规定了测试流程，测试团队要按照规范流程去做。但是在贯彻执行过程中，也要注意方式方法，因为质量要提高，流程也要不断的改进，所以我们团队应该主动的完善流程，把流程应该在项目中贯彻执行，这在执行过程中会遇到各种各样的问题，需要灵活处理。

（1）单元测试审核。虽然流程中要求研发团队做单元测试，实际执行很难落实，所以我们在方案中就不要把单元测试审核放在里面，否则会带来很多问题。

（2）集成测试。在一般流程中，集成测试是系统测试之前的测试，而质量中心要求进行集成测试，但是由于我们所面对的不是代码模块的集成，在外包项目中，应该是产品级的集成，一般是研发团队基本完成研发后，才能进行集成测试，所以这种集成主要是为了进行系统测试而进行的系统集成，所以尽量少放一些时间在集成测试上面。通过系统上线反馈的问题来看，很多问题来自于系统接口上面，这些在需求中也可能没有描述，但是需要我们要非常熟悉银行的业务和业务接口上的处理，例如：黄金项目中在网银上使用18位卡号，而不是直接使用中间的11位卡号的问题。

（3）系统功能测试。系统功能测试应该是我们测试工作中的最重点的内容。对于功能测试，必须做好测试设计和测试策略。在测试执行前期考虑好，整个系统功能测试需要解决的问题，要实现考虑好，因为在测试执行时，往往没有太多的时间进行再准考虑。

（4）系统性能测试。性能测试是需要测试技术含量最高的工作。测试环境是一个大问题，需要多个部门之间的协调，要提前做好测试环境的考虑。系统性能指标要与业务和技术人员多沟通，要明确性能指标，也要同质量中心进行沟通，明确性能测试范围。记住，虽然没有在性能测试范围之间，系统上线出现性能问题，就算没有合同或计划上的责任，也难逃留下不好的印象。

（5）UAT。在我们的测试计划中包括测试资源的计划中，要考虑行方的验收测试，这个验收测试是协助性工作，但是可能需要的时间、人员等都很难确定，是一个风险点。

（6）测试计划。提供三份测试计划，尽量在测试计划中考虑整个系统测试中所采取的策略、方法、需要协助的资源等，虽然说由于进度延期，会使计划发生变更，但是整个测试的策略、方法等不会发生变化，所以对于每个阶段的测试活动做一份好的测试计划非常关键。

2、人员管理

（1）提供测试服务靠技术，需要专业的人提供专业的技术，所以根据客户需求规划好整个团队的人员结构。

（2）形成良好的团队氛围。让成员知道哪些是应该做的，哪些是不应该做的，团队面貌、团队作风可以提现我们测试团队的素质。

（3）尽量保持测试团队的稳定。项目经理通过各种激励措施，保证测试团队的稳定。

（4）项目经理要以身作则，带头遵守团队纪律。

（5）项目是松散的组织，项目经常有人员变动，在人员变动时要考虑工作交接。

3、沟通和汇报

（1）项目外包测试提供的是一种技术服务，服务中必须进行大量沟通和汇报，以展示我们的工作成果。除了行方要求的汇报外，尽量多汇报、多沟通。让项目干系人了解测试、测试方法、测试策略以及测试需要的支持等，因为很多人对测试不了解，我们必须把我们的测试团队的工作内容展示出来，逐渐消除很多人对测试的片面或错误认识。例如：黄金项目中在测试执行阶段增加了日报，通过邮件形式让项目所有人了解测试进展，遇到的问题，需要的支持以及下一步的工作重点和计划等。另外，汇报时也可以考虑增加一些生动活泼的形式，例如向中心领导汇报时用PPT形式，简明扼要，比用word形式更直观，汇报内容采用先总后分的形式可以节省领导获得信息的时间。

（2）我们服务面对的部门比较多，要分析项目干系人不同，其关心项目的角度不同，沟通和汇报时要讲解一些策略。

（3）项目情况也要向公司领导汇报，注意在汇报时，需要的资源要提前申请，给领导列出安排的时间。

（4）可能对项目实施有较大影响的沟通，最好使用邮件等正式形式，而不是通过口头或IM沟通。

4、风险

（1）外包测试项目风险非常大，虽然我们有入口准则和出口准则，但是研发进度、业务需求变更、政策风险等很多，虽然测试团队无法规避这些风险，但是测试团队通过预测这些风险，及时做出调整，则会降低风险发生时带来的影响。

（2）项目风险、组织风险、技术风险都要考虑。项目经理能够站在全局上看，洞察项目的进展，对可能影响项目进展的风险做出预判，并做出调整。

（3）一旦风险发生不要害怕。我们工作就是解决问题的，问题发生了，就要通过公司、客户、研发团队来一起解决。

（4）掌握主动，减少风险。测试团队能做的事情自己做是减少风险发生的有效措施，我们不能依靠研发和客户，把主动权掌握在自己手中，可以保证项目实施上少受影响。

5、缺陷和缺陷跟踪处理

（1）测试组在保证业务功能正确的同时，必须可能多的发现缺陷并把缺陷提交到缺陷管理系统。记住，缺陷数量是客户评价我们的一个重要指标。

（2）缺陷修复周期。事先约定的缺陷修复周期在项目过程中是很难落实，需要多方协调。利用这个武器，把工作主动权掌握在测试人员手中。

6、项目管理

（1）制订轮次执行策略。每个测试轮次要有重点，在有限的时间内不可能全部执行完成。

（2）工作任务分开。工作分开往往是项目经理很头疼的事情，项目事情非常多而杂，哪些工作由哪些人来做，需要很好的考虑。因为项目时间短，没有返工的余地。

（3）项目管理中能处理的事情自己处理。领导事情非常多，对项目工作细节不太了解，他们往往只注重结果，也就是大多数领导都是“结果导向型”领导，把矛盾和冲突能在项目组内部消化的就消化了，不要让领导天天为你的项目担心。

（4）站在客户角度上再想想。做出一个决策或下一个决定之前，要认真考虑一下项目各干系人对你所做决定的反映，不要让自己的老板吃惊，也不要让客户领导吃惊。

（5）技术型项目经理的弱点要改进。做技术出身的项目经理一般是原则性比较强，而做项目却不需要这么高的原则。做事情没有绝对对错或应该怎么做就不能换一个方式的事情，做到外圆内方是最高境界。关系到公司利益等的事情可以反馈到公司领导层，不要自己做主张，千万不要在客户现场发生冲突。把棘手问题和矛盾让公司去解决吧。

（6）规范化、专业化、职业化。工作要规范，技术要专业，表现要职业。测试团队代表着公司形象，一举一动、一言一行都表示着公司是否规范、是否职业。测试团队内部问题内部解决，少抱怨多做事。

（7）在能力范围内，能为客户多做一些看似额外的事情，可能得到意外收获。项目有紧有松，在条件允许情况下，多为客户做点事情就是服务意识的具体体现。

（8）客户需要的项目管理人员是技术背景好，又要管理才能的技术性管理人才。作为项目经理，要全面发展，才能带领团队做好项目。

（9）变被动工作为主动工作。很多测试人员习惯了被动工作或基本上处于一种被动工作的方式，当然这跟测试工作本身性质有关，但是我们测试团队不能在客户技术团队、业务团队、研发团队、质量部门等中处于被动的位置，这样更加处处受限，想办法把被动性质的工作变成主动工作吧。

上面这些内容，从几个方面总结了在某银行做测试项目的经验，我想只是其中几个点，还无法覆盖整个项目管理。项目管理的内容非常之广泛，需要理论上的知识体系，更需要项目的磨练，才能从一位技术人员转换为技术型的职业项目管理人员。

1、测试人员的价值怎么体现？发现的Bug数？Bug数怎么转换成业绩？

2、测试团队如果要背负公司业绩的话，怎么折算？不是说测试单个人员的考核，是整个测试团队的价值

3、引申出来的问题是：要统计一些什么数据出来，表现测试团队的价值

表面上来看，测试人员不直接创造价值，但是他们是软件产品从生产到销售乃至售后升级阶段提供质量保证服务的人员。可以说，软件测试人员承担了质量检查监督的职责，在产品价值中包含着测试人员创造的价值，试想，是一个质量高的产品其价值自然比质量低的价值高，其在市场中的竞争有优势，售后支持工作量少，用户投诉少，这些都可能蕴含测试人员带来的价值。但是如何区分是测试团队带来的价值还是研发团队等其他团队带来的价值呢，我想研发和测试本来就不应该分开来谈到底谁的价值大谁的价值小，因为要衡量在研发过程中的产品缺陷到底影响有多大，不修复缺陷带来的损失，谁都无法准确估计。如果要施行测试团队单独业绩考虑，则可以通过不断地获取测试团队的量化指标以及其他一些措施来达到目的。

测试部门要提现价值，我认为可以下面几个方面去考虑：

1、研发团队的反馈、销售和售后支持人员的反馈。这些反馈很直接，能反映产品生产过程和销售后，对产品质量方面使用上的直接感受。如果可能，获取的反馈数据同历史数据比较，包括销售数据、客户投诉数据、上线后维护阶段的缺陷统计分析；

2、同类产品评测对比。同类产品评测中，产品在各个方面的得分，能提现测试部门的价值。

3、测试数据度量。要在测试过程中，注重测试数据的收集和分析。例如：产品版本缺陷发现率-每千行代码发现缺陷的数量，缺陷修复率-缺陷修复和发现缺陷总数的比率，缺陷模块分布—哪些模块缺陷比较多，可分析原因。版本与版本之间的缺陷数量比较。缺陷修复周期—缺陷被提交到已修复状态的时间。缺陷存活周期—缺陷从被提交到被关闭的时间。数据统计的越全面，越有利于度量。

4、测试结果的统计数据促进研发过程改进（是达到测试能力上的5级水平，说起来容易，做起来比较难），根据统计出来的数据，分析是哪些原因导致的缺陷，例如，研发人员能力水平、工作态度、研发流程、研发团队之间的接口、产品设计、文档描述等等，用缺陷产生的来源指导过程的改进。

另外，我发现，测试团队往往都是在被动的工作，我想是否可以更主动的工作呢？可以根据公司具体情况考虑如何实施。把测试工作不仅仅是保证开发过程阶段成果的质量，而是在质量保证过程中，采取更主动的工作方法。例如：测试团队制订页面设计规范、熟悉业务，站在业务的角度上的提出基于业务的问题，甚至协助产品设计。

测试团队要提现业绩，我们知道产品研发有成本，有效益，那是否从销售业绩可以体现测试团队的业绩呢，显然很难。我们不能天天对研发或老板喊着我们发现多少多少bug，老板可能也不关心这些，他关心的是产品卖出多少，赢利多少。发现缺陷多，对公司来说，也不是光彩事，也不能对外宣传。

既然，我们很难说服老板，我们创造了多少价值，能否对老板说，我们测试团队为公司减少了多少成本或可能损失呢？例如，产品投诉、一个投诉会消耗多少成本去修复，这个是否可以通过历史统计来获得呢？再有就目前产品发布后，出现的问题，是否由于测试资源不足导致的呢？结果研发又投入多少工作量去修补？

如果测试团队做考核标准，则：

1、可以根据公司对研发部门的业绩考核标准，来考虑测试部门的业务考核。

2、测试部门业绩考核是否由研发部门、产品部门、销售部门，售后部门综合考虑。对研发保质报量的完成工作的贡献值、对整个产品质量的提高贡献，对销售业绩提高的贡献值，对售后服务工作量、投诉减少的贡献值。再把这些东西细化，形成业绩考核体系，当然要根据公司是否施行这种体系来定。

    2009年1月11日，金融业软件和解决方案提供商东南融通金融科技有限公司(NYSE: LFT)宣布已经签署协议100%收购中国金融服务行业领先的第三方测试公司迈捷测试。预计并购交割将于2009年3月底之前完成。
 
   迈捷测试（http://www.jactus.com/）成立于1999年，是中国首批提供第三方软件测试和软件质量管理服务的公司之一。公司总部位于北京，并在上海和广州拥有分支机构。作为金融服务行业领先的专业测试公司，公司提供全面的测试服务，包括功能和性能测试，项目和产品评估，以及测试咨询和培训服务。客户基础覆盖一些大型国有银行，政策性银行，股份制银行，城市商业银行，保险公司以及证券行业。

“我们相信专业测试服务对我们具有重要的战略意义，代表了在中国金融科技市场中很有潜力的机会”，东南融通首席执行官连伟舟先生指出，“这个并购使我们成为金融行业首屈一指的测试服务提供商。虽然目前来看迈捷测试对我们财务结果的贡献还很有限，但是我们现有的80名工程师的测试团队加上迈捷测试的100多名工程师使得我们能够将测试服务和我们的软件解决方案整合起来，从而为客户提供更优质的服务。”

周六和周日到崇明岛旅游札记：

第一天（周六）

1、  各自从自己家出发，乘1号线到底(富锦路站),然后过马路向北走50米乘北石线或彭石线到底,就可到码头，坐车3元到码头。

2、  购买船票（18/元人）大约10点半到南门港（船上浏览江上风景、聊天，拍照等），不能购买回程船票。18*6=108元

3、  在南门的步行街简单吃午饭，套餐9菜一汤，还不错，加上几瓶酒。134元

4、  前往南门附近的农工商超市采购午餐烧烤用品（180元）。大约1点从镇中心包车（这个车是我们崇明的同事实现找好的）（30元）前往东平森林公园。

5、  大约20分钟到森林公园大门，其大门的景色非常好，树木绿色很有层次感。门票40元/人，个人买没有旅行团体价格。 40*6=240。

6、  在东平森林公园中游玩，呼吸清新空气，感受自然；里面是免费的自行车可以骑，出门时放在门口即可。

7、  我们玩到大约5点的时候去烧烤的地方，租用场地，非烧烤场地不允许烧烤的。场地费用每个人收8元*6=48,租用烧烤炉子120元（老板娘有点欺骗我们，其实购买那个一次性的烧烤炉-只要30元也能烤1.5-2个小时左右，实际上我们也就是烤了1.5个小时，老板娘说是只能用不到1个小时），包括一点点蔬菜50元(土豆,玉米,香菇,蒜苗)。后面老板娘送我们一杯油，几袋调料，包括免费两把烧烤钳子使用。花费了215元，后面加了一杯油3元。总共218。

8、  烧烤过程还不错，因为当天阴天，没有其他烧烤的人，只有我们几个。整个烧烤过程，还是比较不错，大家轮流上去展现手艺，把我们从农工商购买的烧烤用品全部烤完了，大家喝啤酒，非常不错。最后给老板娘要了一壶热水，冲了我们自己从家带的咖啡和豆粉，非常舒服。

9、  当我们烧烤完时，已经很晚了，我们担心迷路，还好老板娘派了一个师傅带我们到大门口，走了大约有20多分钟，这个还是很感谢老板娘的，那天晚上在公园还走失了一个人，警车在里面找人呢。

10、 事先订好的车送我们到了前卫村（30元/人），直接到了事先联系好的这家536号，老板娘很热情(临走的时候还把家里仅有的几个柿子-非常甜而且水分足免费送给了我们)。上到4楼一看，条件很不错，挺干净的，6人3个房间，总共只收了我们240元。我们先订了明天的早饭（5元/人）和午饭，基本上包括了崇明的大部分特色菜，300元。

11、 晚上活动是4个男的打麻将，一直打到凌晨1点半。

第二天（周日）

1、  早上起来，在村里转了一小圈，房子盖的都不错。

2、  8点半左右，我们一起吃早饭，早饭很丰盛,有崇明糕,金花菜,白煮蛋,油爆花生,榨菜炒蛋,咸茄子和红薯.注意呀，如果人不够，不能先吃的，是因为一些菜要一次性做好。

3、  9:30-12:00点前卫村周边游玩:瀛洲古村,卡丁车,动物园,木化石馆,根雕馆,休闲广场,蔬果采摘园等；

4、  12点回农家院吃午饭(就在536号对面)，午饭非常丰盛且厨师的手艺可以说相当的好，吃的我们几个人都不想回去了,还想再待几天吃个过瘾,其中包括崇明毛蟹、红焖羊肉、炖土鸡、红烧支鱼豆腐,红烧肉烧蛋,香芋,甜糯玉米,芋艿和红薯,金瓜丝,油炸小鱼等；

5、  吃过午饭已经是2点多了，3点左右，车把我们送到了新河轮渡站（50元），坐15点半的船回石洞口码头，各自回家（13元/人）；

108+134+180+2+300+240+218+380+100=1680元   人均280元。

注意：

1、瀛东村电话-（021）59436276。

2、渡轮咨询电话：69693666

3、农家小院电话：