最近工作重心转回code，虽然比传说中的码农层次稍微高一些（个人感觉啊），可也相差无几。真正参与（设计、开发）的第3个项目，公司产品的3.0版本，分为模块化的开发，然后大家将各自的模块做一个组合。要说的是关于在这几个项目中关于测试的感受。

这里啰嗦几句，跟主题无关。最近老看到一些什么“大公司做人，小公司做事”的论调，相当不以为然，调整好自己的
心态无论做事还是做人，真最重要。虽然自己没能做到”像随时要离开一样做好准备，像永远要留下一样用心。”但是
还是尽量认真做事，认真做人吧。

好了言归正传。同事L曾戏说，我们真正把客户当做我们团队的一部分，由他们负责来测试。我想这个是由于欠缺规
划，或者是协调的不合理的原因。时间紧固然是一个因素，但是我也从来没见过暴雪因为时间紧就让玩家来测试的，
他们宁愿担着跳票带来的风险也要践行“暴雪出品，必属精品”。

没了解过专门的测试团队是如何工作的，但是个人觉得这个不光光是测试本身的问题。
为什么需要测试？提高软件质量，给客户提供优质服务。软件质量是由软件整个开发生命周期决定的，从需求分析，
到概要设计，到编码，到单元测试，到集成测试。每一环都会影响到软件质量。
如何测试？现在很流行的TDD，敏捷等都提倡将测试提前，尽早发现问题。这里要提一句关于敏捷中常用的”拥抱变化
“的是一个很好的理念，将测试提前才能很好的发现问题，发现需求上的不足，正”真拥抱变化”,还记得Bob大叔的
MarkIV型咖啡机就是这么产生的。那么涉及到测试时的具体操作该如何处理呢？如单元测试的时候，可能需要设计一
个简单的测试环境，一些尽可能多的覆盖实际应用的测试用例，对测试结果有一个预期，能很好的发现问题。这里提
到的测试环境和用例的设计，需要对实际的业务有一些了解，符合8/2原则，设计的用例至少要覆盖实际应用中的80%
场景，对另外的不场景的20%应该单独测试。到了系统整体测试的时候，在场景选择，用例设计的就需要考虑跟多的
因素了。比如对软硬件环境（可能这个应该算作压力测试吧）的要求，用例选取需要覆盖到系统中各个模块中等。
反观现在我们的开发过程，需求跟设计是放在一起做的，甚至有一些设计来限制需求的感觉（当然这个没有任何问题，软件本身就是为了来简化人工操作，提高效率的），设计出来经过一些简单的推演，大家就开始动手code，过程中会发现一些问题，再次讨论，修改设计（个人开始很喜欢这个过程了，有些类似于敏捷的迭代，拥抱变化）。自己做一些测试数据测试完成后，交付模块整体测试。

看起来很美的一个过程，实际操作的时候，发现很多问题，其中有一些觉得就是缺乏很好的测试。

需求跟设计是否真的能分开，没必要争论，有很多需求确实是泡沫，在设计过程中跟客户沟通、交流，发现原来他们要的那个需求根本就不是原来他们提出来的，有了一个简单的设计再跟他们沟通，他们反而自己提出剪掉那些泡面。
问题就在我们的沟通机制做的还不够好，还需要规范、高效一些，记得项目过程中好几次开会的时候，零时被叫道会议室，还没明白过来是怎么回事，就开始了argument，最后发现大家要表达的是一个意思。当然这个argument也带来了大家对这个设计理解更加深刻，但是否只有argument这一种方法来理解设计？是否可以在讨论之前，设计者自己出具些能覆盖整个项目的测试用例，先分发给大家参考一下，或许大家能从中发现一些不足，一些亮点，下次设计的时候借鉴”团队不是一群码农”。这个是关于设计阶段的，到了code阶段，还会对设计有一些改动，这个时候更需要有一些好的用例了，因为往往需要修改的设计会牵连到很多的模块，而修改的提出来之一个模块的负责人，这个是需要该木刻的负责人出具一些用例，来表明前面的设计不能满足，而后面的设计能很好的实现，将这些用例分发相关模块负责人，共同探讨一下是否会对其他木刻有冲击。

以上文字写于某个等待某个测试数据的中午。

• «Previous Post
• Next Post »

---