工作已将近三年了，虽然这三个年头里我都在积极的学习着与测试相关的技术；但是能沉淀的东西很少。相信测试同学都有类似的感觉。

不要为了测试而测试

前几天做一个测试的PPT，就是讲项目中要用到的测试技术，总结了半天其实实际的产品中没用到什么技术含量的技能，熟悉需求，并转化成用例，待项目上线后验证功能就 OK了；对一个自身质量要求不高的项目，我们有时候为了体现自己价值，非要在一些不痛不养的问题上用力过猛。

举个不恰当例子，某钢琴高手开了一个补习班教钢琴，家长送来一孩子目的只是让孩子学学钢琴；钢琴高手为了体验自己的价值（牛B），硬是按照贝多芬的标准去培养，孩子弹不会《XX交响曲》不让孩子走。先不说孩子有没有贝多芬的钢琴天资，也许孩子压根就不想成为贝多芬。

当然了，如果你办的是“中国音乐家钢琴协会”，你有责任要求会员达到国际超一流水平，为国家和个人赢得荣誉。

有时候不要为了测试去测试，或为了体现自己的价值去做一些对整个项目贡献不大的事儿。当然，我在这里不是让测试人员放弃自己的原则。要知道不管是产品、开发、测试都是围绕着产品的发展贡献。

为贡献产品的发展测试远比为了测试了测试所带来的价值大得多；所以站在产品的发展上去看待测试工作更能体现自己的价值。

记得去年的总结自己对 测试流程 的理解。随着工作年龄的加长对这些问题也有进一步的看法；所以，再拿来炒一炒，希望能炒出新的味道。

没有最好的开发测试流程，只有最适合项目的开发测试的流程；

---

去年的一篇说软件测试流程，严格规范的测试流程一定比没流程好，敏捷的流程一定比传统的瀑布流程先进。这个观点没有大的错误，但是我们忽略了所做的产品这个“对象”；忽略了产品的特点与阶段。

例如两三个开发合伙开发一个项目（或产品），这时你让他们建立一套规范的流程，按流程实施，显然是不现实，我想摆在他们面前最主要的问题是，如何快速的把客户需要的功能开发出来换成money ，维持生计以及公司运作。

例如一个各种功能已经成熟的项目，有着庞大的用户群，以维护为主的更新，它的版本功能的上线必须要建立严格的发布流程，经过充分的测试才能上线；用户群越大，暴露的问题越多，问题带来的影响也会越大。

同样是一个Web产品，笔者目前所做的项目流程完全不是这样；我们的发布流程很简单，测试流程也很简单，不去写的规范又复杂的测试用例，放弃了使用缺陷管理工具来反馈问题；

沟通变得尤为重要；我不否认这样做会给产品带来了一定的风险；对于严重的问题，我们可以通过快速的版本回滚，对于轻微的问题，我们很快会在下个版本迭代中修复。是不是有点敏捷的味道在里面。

为什么会这样？因为这个产品属于前期开发阶段，很多功能还没上线。整个团队都在贡献着产品的发展；需要快速的将需求转化成功能给用户使用。

所以，没有最好的开发测试流程，只有最适合项目与阶段的开发测试的流程。

产品质量与用户容忍度

---

之前看过不少人讨论到底需不需要测试人员；我想说测试人员N年后不管是被重视了还是被淘汰了“测试的行为”永远不会消失；因为没有质量的产品基本上等于没有价值（也就是说没存在的意义），至于对产品质量的要求是由用户容忍度决定的。

Facebook 没有测试人员！但是测试行为一直都在。开发找需求，开发、自测、发布，获得用户反馈，决定功能下线还是上新的功能---相当于一条龙的服务。因为用户的容忍度允许他这么做。

微软不能这么干，修复一个 Windows 的 bug 成本很高，而且用户是花钱买的，也许用户是用来创造价值的（办室、存储、管理），也许一个文件丢失，系统崩溃会给用户带来巨大损失；所以，微软需要很多的测试员。

拿修复成本与用户容忍度做标准，Web 产品优于客户端产品；在 Web 产品中也要分行业；用户对银行系统、火车票、购物网站的容忍度显然要低一些，反过来说也就是对产品的质量要求更高，因为与钱挂钩。就算同一个产品，会员与免费用户的容忍度也是不一样的；因为会员用户有权得到更好质量与服务。

所以，关注分析用户的容忍度的测试才不会把自己变得格格不入。

提升自己的贡献

---

前面的东西貌似都在“弱化”测试存在的价值；俺本来就不被重视，所以俺就需要更加认真和努力找问题来提升自己存在的价值，你现在说，有些产品不需要太指着的去测试；那你说俺还能干啥？

当我们把测试看成是为开发和产品服务时，也许情况会完全不一样。我们可以提供哪些服务？

• 用测试发现产品的不可以测试性

前面已经提到队团不管是否有测试人员，但测试行为一定会存在；如果一个产品都不可测试，如何去发现并修复bug ，如何去维护与扩展？尤其对于web产品来讲，不可维护与扩展的产品无疑是致命的。（可以通过项目重构再解决）

• 建立产品质量的评估方法

为项目团队提供每个版本的bug趋势分析数据，让项目中的每个人都了解项目当前的状态

通过分析bug数据来建立或完善各种 Checklist，帮助项目团队更好的完成需求评审、设计评审以及代码评审，减少bug出现的机会。同时，可以定期将多个项目的Checklist进行合并，使单个项目的经验可以通过Test Team快速的流动起来，及时的作用于其他项目

主动为Architect Team提供每个项目的性能测试数据，帮助他们获取更多的实际项目信息，减少踏入“陷阱”的几率

• 建立可持续运行的测试框架

建立自动化测试测试框架；构建持续集成，使版本的迭代与更新得到快速的反馈。

• 建立关注开发质量的开发文化

没有测试人员自测节省人力的了，尤其在单元测试层面。产品的质量应该由开发与测试共同承担。（现实中的责任到人，让团队很难形成这种文化）

• 贡献产品发展

旧病成医，测试的产品多了自然会对产品有自己的理解，产品的定位，用户习惯与体验； 可以从测试的角度贡献产品的发展。（这个由产品的特点，公司文化决定）