最近两年还真做了不少的测试。现在发现测试的重要性，是自己吃过亏。你觉得已经找不出错误的地方，居然还真有；你觉得不会有影响的地方，居然还牵扯上了。还是那句老话： 测试只能证明问题的存在，而不能证明问题不存在。 回想对待测试的态度，已经做了一个准备。以前真的看不起测试，这在国内是普遍现象，现在逐渐认识到测试活动，不管是对个人，还是对项目公司，都是非常重要的： 1、TDD是测试与开发的融合。基本上很少有机会有专门的测试团队来验证你的代码，自己得测试，而且得详尽办法找到尽可能多的问题。 2、测试要是可复用的。这个问题比较难解决，测试的粒度太小的话，代码的变动，很容易破坏测试用例。一个方向是，测试输入和输出，而不要过分关注执行流。测试的复用能够保证每个Release都不会破坏既有的行为。 3、测试尽量自动化。这个跟应用紧密联系，千差万别，发挥聪明才智，总能找到自动化的解决方案。 4、测试适可而止。需要在投入和产出之间做出衡量。应该没有公司对待UT像对待代码一样严谨。可以用往往是成功产品的第一步。 5、还有一点需要注意，质量是规划出来的，而不是测试出来的。不要对测试期待太高。一个拙劣的架构或者设计，注定就是Bug的聚集地。前期不重视，没有提供测试的支持，临时抱佛脚，也是回天无力的。 我们不应该排斥测试，领导安排你做测试，应该高兴才对。一是可以找别人的茬；二是很好偷懒。当然这样的态度不推荐。测试跟开发是紧密联系在一起的，需要的是沟通，而不是相互指责。因为很难衡量测试的效果，以及对需求的理解偏差，所以测试很好偷懒。可以用下面的公式来衡量测试的效率： 测试效率 = 历史测试效率 × Bug数量 / （需求项目数 × 时间） 找茬偷懒都不好。好的是测试可以帮助熟悉系统。码农的出路中，两条很重要的就是领域专家和架构师，他们都需求对业务非常熟悉和了解。阅读需求文档不正是给你了解产品，了解用户，了解领域的机会么。实效点的作用，会在编码过程中潜移默化的提升考虑问题的广度和深度。 调整心态，测试的目的是保证产品的质量，为用户提供安全可靠的服务。只有将自己重新定位，才能正视自己的工作，为公司创造价值，为个人开辟蹊径。 测试是需要方法的。前面说了测试需要适可而止，需要平衡投入和产出，那么测试就应该有针对性，好钢用在刚韧上。两个指导性原则： 1、保证基本功能可用，基本测试。 2、识别出风险高的部分，比如交互，边界，顺序啊。 最后，找出来Bug是不是很有成就感？但请把成就感放在为客户提供高质量高可靠的产品上吧！ 原文地址：http://my.oschina.net/sulliy/blog/87766 |
