对日软件开发体会之二

多数日本企业在软件开发流程中各个组的组长一般只做review工作，review你的用例是否全面覆盖了你的需求，review你提交的成果物有没有错误。Review是一份很细致的工作，需要对需求的把握十分理解。除了组长做review工作外，测试和测试之间还要做交叉测试，各自造不同的数据，在提交成果物之前确保找出所有的bug。

 

这种交叉review和交叉测试的过程其实每个企业都有提到，但一方面是人力的问题，另一方面是时间的问题，似乎很少有企业能真正做到位。

 

然后对日软件开发中测试人员的要求比开发人员的要求高，在项目的时间计划安排上也是测试时间远远要比开发时间多，一般开发时间安排为1人/日的话，测试时间起码是2.5人/日。因为在前面文章中我已提到需求文档上已经把所有的代码实现逻辑写好了，开发人员几乎在开发时只要将需求上的逻辑加一件“外套”，就像现在我们使用的ruby脚本一样，在业务流代码已经完成的基础上我们只要给将业务流代码加个驱动方法使它跑起来就结束工作了；而测试人员比较辛苦，开发人员在开发的这段时间一般还不够测试人员写TC的；在测试的时候还要保留证据证明你是完全按照case来执行测试的。比如在执行某一个用例的时候用到了哪些数据，如果是测试前台页面的，那就需要将页面上文本框的内容截图出来，如果是测试后台批处理程序的，那么需要做一个输入数据文档，同时将程序跑出来的日志、生成的各类统计文档等全都保留下来，将这些文档的内容和预期结果做对照，来判定测试的用例是否通过。

 

当然我们是否也需要花那么多的时间去做这一系列的产出物我觉得需要探讨？就目前我们的业务来说，我个人觉得没有必要，但那样做确实有一定的好处，首先很规范，不会马马虎虎一测了之；其次，一系列的输入数据文档便于回归测试，也便于下次业务有变动后可以节省造数据的时间。