4、clean code思想对我们很有帮助。经验表明，把代码写复杂很容易，但是把代码写得简单并不容易。测试人员的代码功底毕竟还不是很好，所以需要有经验的人在旁边加以指点。在指引他们写清晰的代码的时候，一开始不用马上引入一些新的名词，比如SRP（Single Responsibility Principle） ，面向对象的设计等等，而是通过pair work的方式，让大家看到实际的例子，看起来很复杂的代码如何可以变得简单…

　　鼓励大家把函数写得尽可能短一些，函数和变量的名字尽可能有意义一些，一个函数的名字不要挂羊头卖狗肉，言行不一

　　一个函数应该只有一个抽象层次……

　　大家的悟性都还不错，当看到自己写的比较乱的代码原来可以整理的很干净的时候，自然而然会希望朝这个方向靠拢。

　　5、充分利用python动态语言的特性。比如python的decorator功能，可以对函数做一些动态行为的修饰，可以使代码写得更加简洁，去掉不必要的冗余代码。再如我们内部开发的keyword wrapper的功能，可以实现一个函数名词映射到多个不同的实现，然后在运行的时候去寻找适合当前版本的实现，可以使我们的测试代码灵活兼容不同的版本，等等。

　　6、对代码书写必要的注释，但重点在Why to Do 而不是What to Do

　　效果：

　　我们用较短的时间，除了重用了一些以前身经百战的测试函数库外， 基本上相当于重写了之前的很多测试用例，改进了之前测试的coverage， 而且发现一些系统行为和我们预期的行为不同，相当于对被测系统有更深的认识。

　　发现了一些疑似或真正的软件Bug。

　　自动化测试用例的稳定性比以前改进不少，测试人员对于自动化测试的结果更有信心了。

　　对于我们重构过的测试，能否真正做到不碰到非软件原因引起的失败，还得继续观察，估计也没那么完美，呵呵，但我们应该可以做到发现问题，随时改进

　　我们得到的体会：

　　1、测试代码也需要不断的重构。似乎有位大师是这么说的，“对代码要无情的重构”，“无情”这两个字说得好。对于你感觉不好的东西，比如重复的或者可读性性很差的代码，不要因为自己写的，或者花了很多时间心慈手软，应该是”挥泪斩马谡“，毫不犹豫的把它们改掉。

　　2、测试代码其实比一般的产品代码更需要clean code，因为测试代码是写给更多的人看的，是描述需求的边界的，一旦需求理解错误，其实比产品的实现理解错误更糟糕，呵呵。这点不知道大家是否认同？

　　后记：

　　我们的经验可能和我们采用了基于模型的测试（MBT） 这样的实践有一定关系，MBT要求我们的high level Keyword，或者也叫Test Action，要能表达特别多的信息量，所以才迫不得已把很多需求信息放在python中来描述 。 毕竟这也会失去一些Robot Case的优势， 如果你的实践不同，能否借鉴还需要具体问题具体分析。

　　注：Robot是一个关键字驱动的ATDD的自动化测试框架。