融合视讯测试

项目已经快结束了，大家都没有轻松。

第一轮SDV测试，周一会结束。7.5K的代码量，300多个问题单。算起来还属正常，但如果在初期方案的设计时就多加入测试的部分，我想问题单的数量，应该可以减少一半。

一些平常的功能，像静音、音量调整。都没有在设计上有所体现，所以开发这台机器，因为没有看到图纸，所以所有播放相关的页面，居然连声音控制的功能都没有实现。真是笑话！在开发过程中，开发人员不会依照自己的想法去改，也许他想到了某些设计会出错，但他们不会去做这样的努力。他们只会做出来之后，被测试出发现问题不对了，反馈出问题，然后再由CCB决议更改设计或其它。当然，开发如此是没有错的。那么如何让开发完成的东西，不会出那么多的BUG。想想，既然开发人员在实现时，都是如此的“机械化”。那么，指引开发人员的一定要正确，才能使开发人员做出较好的东西。

现在回顾，发现很多问题存在。返回规则的实现、消息提醒交互的规则、部分功能的实现、UCD设计的统一等等。需求和某些规则在一开始的不确定，开发过程中的临时更改。使得开发人员在开发实现时，阻力比较大。本来指引性的东西，现在变得不确定，开发显得很无奈。而测试人员在设计完测试用例之后，同样也发现很多设计用例与实际实现有差别。追问是哪里出错时，才发觉搞UCD设计的，应市场方面的要求，又更改了些许设计或更改。

相信大家都知道问题在哪里，但归究起来是哪些方面呢？我觉得团队执行力的问题，这个团队包括市场、设计、开发、测试，这些都不应该分开，对于一个项目，他们就是一个整体。我想在执行方面，问题是不大的。而执行的能力有问题，存在一定的问题。这里的能力是多方面的，对于一个人，那只是个人的能力如何。而对于一个团队，那么这个能力就对应于整个团队的各个属性，团队的决策、协调、组织、运作等等。特别对应于这种多个小组形成的团队，其中的团队能力就越显重要。一个人的肢体在执行大脑传递的动作指令时，肢体会相应的做出反应。而如果大脑在肢体动作反应周期内，发送了两个不协调的的动作指令时，那这个人的动作会很滑稽。同样的，如果从上层传达的指令不明确，那么下层在指令执行上，也会出现同样的情况。避免这样的情况，只有上层在确定好动作指令之后下达。

如何确定上层下达的指定就是正确的？测试，从一开始就强化测试的执行。充分的给初期的SRS、UCD等设计做仔细的评审测试，而且宁肯在这个过程上，多花费一些时间，也不要急于赶进度。将一些仍没确定好方案的东西，扔给开发去实现。这样只能出现上面的情况。