敏捷实践——测试

       实话说在前面，我没不是测试人员也没有混过贵圈，只是从开发的角度来记录下关于测试的点滴。

测试驱动开发

       ——首先编写测试的另一个重要效果，是测试可作为一种无价的文档形式。

       首先编写测试真是一种让人有爱又恨的行为，想象一下给你一天的时间交付一个几K的特性，然而还要花半天写测试用例是不是很抓狂？但是当测试把你的特性打回时，又恨自己没有多花那么一点时间去写个完整的测试用例。所以，即使确实没时间写测试脚本，起码也写个测试用例的文档吧，你会发现能省下好多功夫。

       对于开发人员，团队暂没有硬性要求每个特性要配套多少的自动化测试脚本，甚至没有硬性要求特性分析时的用例输出。但是我认为这也不会是很遥不可及的事情了，因为我们的白板上每天都写着开发流程的其中一项是LLT。从我的实际经验来看，花点时间写测试脚本确实能够提高代码质量，并且很多时候可以减少以后特性的调试工作量。能促进模块解耦这么高级的东西请原谅我还没遇到过。。。

      在我们的团队，自动化测试每天都要跑一遍，把所有人写的测试脚本跑一遍，保证新加入的特性不会对已有的特性造成影响。

验收测试

       验收和测试按照我的理解应该是两个不同的活动。

       在每次特性转测试前都必须先进行验收，开发人员、特性设计工程师和测试工程师都必须参加并验收过程记录个归档。在验收过程中，开发人员会按照测试人员提前给出的红线用例（一般是特性的基本功能）进行演示，设计人员和测试人员会根据特性的澄清纪要进行验收。当遇到具有争议性的问题时，设计人员和测试人员进行协商确定最终方案。在验收过程中发现的问题也会在转测试前修改合入，保证测试的顺利进行。验收如果通过，则表示该特性顺利交付测试，在后续的测试过程中即使发现问题也不能把特性打回而只能作为缺陷引入。因此验收过程其实是保证特性交付的一个重要手段。

       我们必须明确一点，软件质量是开发出来的，测试只是作为一种验证手段。测试人员在特性转测前会根据设计文档和澄清纪要编写测试用例，并在测试过程中配合开发人员复现软件问题。这里插个题外话，测试人员的绩效是通过测试效果来衡量的，这里的测试效果包含指标和结果。指标是测试过程中的问题数，是正向绩效。结果是指软件在实际用户处暴露的问题，是负向绩效。因此从客观上讲测试人员和开发人员应该是对立的（软件的问题数也作为开发人员的负向绩效），然而又被捆绑在同一条船上。

       在每个迭代期间有两个点，一个是健康点，一个是迭代点。整个版本的问题数在这两个时间点必须低于一个规定值，否则版本认为迭代的特性交付是存在风险的，必须采取措施规避。因此在这两个时间点，无论是开发人员还是测试人员都加班加点定位问题。

       突然发现我们每天都工作在一个矛盾体中。。。