电文处理任务小结

过去的两个月，我们项目组8个人做一个对应（日方的見積もり是13个人月），共19本任务。

我们先搭建环境，那时日方客户的IF设计书还没有给，我们只能根据在客户现场的同事的只言片语来调查既存代码，做准备。

-》后来看来，这种调查，大方向都不太明确，多少有些盲目性。（20090506追加）

这个系统还是很大的，也很老，听说已经跑了几十年了，我们这次的任务是追加处理（供最终用户在嵌入式设备上进行使用）。

画面是另外一个公司做，我们只做处理（接受到request（一串数据），在“后台”进行处理，返回response（又一串数据））。

这个和我们以前的对应任务（比较纯粹的Web任务）有所区别，刚开始时，大家连输入什么输出什么都不清楚（没有设计书）。

还多亏在第一次电视会议中，在客户现场的同事当场画了一个图，讲解了一下，我们才了解大概流程和我们要做的处理。

期间，特别是刚开始的式样理解阶段，我们不断通过QA进行确认，并且每周和日方客户开两次电视会议。

国庆前我们比较好地调查了既存Source中关于PC的处理部分。

-》也将调查结果形成了文档，这种文档在后来的开发中也确实起到了一定作用。这边要注意一个问题，就是分配调查任务后，最终一定要形成一个调查结果（文档）。需要杜绝这种情况的出现：调查确实是调查了，但最终什么结果也没有。过段时间，想利用这个调查情况的时候，却又什么也记不起来了。（20090506追加）

国庆后，在客户现场的同事回来了两周，帮助我们理解和把关，确认了很多式样，导致那两周的QA数量大减，呵呵。

-》这个任务能最终顺利完成，这个BSE起的作用确实很大。（20090506追加）

同时，逐步地，大家对自己的任务也越来越清楚了。

然后，我们就依葫芦画瓢（特别是业务逻辑部分，基本参照PC的处理逻辑），将各自对应代码逐步写出来了，还算顺利。

都是新规文件，然后调用既存代码（客户一直强调不允许修改既存source，担心影响别的地方，这也符合OCP原则）。

但是后来遇到一个问题，现在看来，也算是一个经验教训吧，就是测试式样书的问题。

当时为了更好地控制进度（以保证按期纳品），我们对外（日方客户）排了一个Schedule的同时，内部又排一个，提前一点点。

前面的式样理解、source调查、code都是按内部计划来走的，相对于外部计划而言，时间还有点空余。

但是，后来，由于测试式样书的反复指摘和对应修改，在这上面就耗了两三周的时间，远远超过了原先安排的时间。

-》因为日方客户需要进行两轮review，我们的日方客户A的review和A的客户B的review。再加上日方客户安排的人手又不够，导致review上所花的时间超长。（20090506追加）

这个“突发”状况，不仅把我们前面争取来的空余时间全部吞掉了，还导致了纳期的延迟，比原计划延了一周。

这次对应，我们这边只做UT（单元测试），使用JUnit工具测试，每本或多或少地写了几百或几十条测试Case。

因为业务关系，很多case都要人为修改电文或者DB，一条条地测，截图（日方客户要留作Evidence）。

客户那边做SI（集合测试），应该是和另一个公司做的页面结合起来进行测试吧。

也有可能不是，因为我们部门的首席技术专家用Java Swing写了一个SI的测试工具，也纳品给日方客户了。

现在的新对应，日方客户已经注意了，将测试式样书的时间提到了Code之前（尽管实际上我们这边已经同时在做Code了）。

有几点感受：

一是前面提到的测试式样书的问题；

二是式样不断变更的问题（也许到了快要纳品的时候，还是有式样要变更。也许，这也是做项目的一大特点吧）；

三是式样理解逐步的问题（式样并不是一下子在式样理解阶段就全部搞定的，可能只能说那时理解的是大部分；code时又理解一部分，写测试式样书，甚至于做单元测试的时候，还有可能发现个别式样理解错了）

今天就先写到这，以后想起再来补充。

20081113补充两点：

<!-- --><!-- --> <!-- -->

调查既存 source 时做调查文档，做些记录，以后再回过头来确认相应问题时，可以快速定位。这个问题，遇到过几次，逐步明白客户这样要求的好处了。

 

在数据库表很多的情况下，把自己负责的部分中要用到的表单独放到一个文件夹，用的时候找起来很方便。

<!-- --><!-- --> <!-- -->

20081210 补充：

 

关于测试

 

使用 JUnit 工具 进行 测试， 关于 case 的编号问题，因为这次 case 相当地多，刚开始是按规约来给各个 case 命名的，但是测试起来才发现，这样并不好，每测试一次，还要稍微费点力气来找下一条测试 case 。后来，改变策略，使用编号（和测试式样书的 case 号保持一致），那样测试起来更方便一些。

 

单元测试全部完成后，才发现，其实不需要那么麻烦（每次点击一下运行所有，然后再从几百或几十个测试方法中选择一个运行），其实只要打开 outline 视图就可以快速定位了。

 

感觉我们在极细微错误的认识程度上，仍然和日方客户有所差距。比如说这次 CJ 部分的测试，因为 code 时货币符号错写成了全角，需要改成半角，说小点，其实就是个显示的问题。按照我们中国人的“惯性思维”，也许这个只要对应完，重新测试一下就可以了，感觉重新截图好像就不是那么一定必要了（因为 case 很多，同时手机截图也很麻烦）。但是日方客户并不这么认为，他们认为应该尽早发现画面的文字显示有些混乱这样的小混乱，如果这一类错误都不能及时发现，那么背后肯定隐藏更大的错误。之所以这么考虑，也许是因为日方客户遵守确保安全的“ HEINLICH 法则”吧，他们对于质量的思考方式：消灭小故障，就能够确保安全。

 

后来，我们仔细对照画面设计书，又在我们实现的画面上发现了两三个类似的 bug 。由此，也不得不佩服日方客户工作态度的严谨。