先讲自己遇到的两个小故事。
去年底新开始负责一个项目的测试工作，这个项目在我之前，并没有正式的测试人员，开发写完代码然后就自己测试一下，没问题就上线。一次和相邻团队活动，一开发技术牛人得知我是新来负责测试的，寒暄之余，他的第一个问题是，你是用什么来做测试的？
听到这个问题，我不禁一愣，他问的“什么”是什么意思？是指一种测试框架？或是一种测试工具？或是一种测试方法？还是其他？我赶紧回答，我正在准备自己的一套测试框架，也在吸取社区上的各种成熟的东西，测试用例也在建设中。
做测试5年多时间，之前从没被问过这个问题。
进入项目的前两个月，我在整理之前开发用到的各种测试方法和测试工具，一方面为了自己了解这个项目的状况，另一方面也可以把以前的成果沉淀下来，为后面形成测试用例体系做准备。这时候来了一个测试的助手，因为是新人，我让他先看下我之前先整理出来的那些个测试用例，同时也可以结合自己的经验做一些扩展补充。他看了会，也跟我抛了个让我很吃惊的问题：你说的测试用例就是指哪几个工具？言外之意，就是觉得那几个工具就是几个命令行，运行一下不就可以了，还有什么可以扩展补充的？后来知道，原来他想写code，想做自动化。
我终于意识到，原来大家对测试的理解是有很大不同的。我不能讲他们的理解不对，因为他们的工作背景和经验形成的对测试的一些看法，在某些场景下确是对的；但我觉得根据自己以前的经验和个人认识，我对他们的理解有很大的不认同。
我就来讲讲自己对测试的一些看法，完全是作为交流的目的，有讲得不对的地方，恳请大家更正。
测试是干什么的？本着以终为始的原则来分析问题，我们首先需要了解测试的职责是什么：毫无疑问，测试存在的价值就是保证产品的质量，让产品给用户提供好的服务。所以，这个目标决定了测试该做的事情，一切与这个目标一致的事情，都是测试需要做的；而所有对这个目标无直接用处的事情，测试需要考虑是否该做；至于违背了这个目标的事情，应该杜绝去做。
所以，对于测试，最重要的第一件事情是需要了解产品。看上去这是一句废话，项目中的任何人都需要了解产品！我想强调的是，测试需要比开发在某些方面更了解产品。对产品的了解分为两个部分，一部分是需求，另一部分是设计。对测试来讲，对前者的了解优先级比后者更为重要。需求定义了这个产品需要做成什么样，它可以为用户解决什么样的问题，以及为用户提供了什么样的功能。而设计仅仅是开发为了实现需求，在基于自己对需求的理解上，用某一种方式实现了产品。需求决定了设计。
开发对产品的理解体现在设计上，而测试对产品的理解体现在测试用例上。
回到主题来，测试该做的第一件事情，是测试用例的齐备。可以没有所谓测试框架，也可以没有自动化，都不会从根本上影响测试质量；测试用例、测试场景不齐全，会直接导致产品潜在Bug没有被发现，用户拿到的产品服务质量很差。而且，我觉得如果测试场景没有完善，就急匆匆的去做一种框架或是自动化，也注定是很快要做重工的，因为很大可能你后面新加入的大量测试场景会彻底推翻你前期实现的测试框架、自动化模式。
当然，我也不是说要等所有测试场景都确定下来，才能开始自动化；自动化确实可以节省人力，腾出更多资源去做测试用例拓展；但要先确保最基础的测试场景完善。测试框架、自动化只是工具，它们的价值在于帮助测试人员提高工作效率，把一些劳动交给机器做，为测试人员省出时间去做更有价值的测试工作；但它们做到再好，对用户来讲，他们毫不关心；就像有人提到，Windows Vista的自动化测试程度很高，而忽视了用户体验，结果注定是一个失败的产品。
我这里的测试用例实际上是广义上的测试用例，包含各种测试类型：功能测试用例，性能测试用例，系统测试用例，兼容性测试用例，安全测试用例，等等等等。我觉得根据产品的需求或者项目的需要，提高测试用例覆盖度这个过程才是测试应该花大气力去做的事情、测试工作中的重中之重。至于如何去完善测试用例，有很多很多的方法、技巧和经验，我也在学习中，这里就先不聊了。
齐全的测试用例是为了可以尽量的覆盖产品逻辑，尽量可以发现潜在的Bug，或是尽量确认可以正常工作的场景。但这个过程的前提，就是开发已经实现了产品，他们已经有Bug潜伏在某些地方了；事后尽早挽救是一个好的方法，但如果能够事先预防，防患于未然，那更是大家期望的。在软件开发中，测试在项目前期的参与，对于保障产品质量非常有益。
项目的第一阶段是需求定义。需求定义远比我们寻常的理解要复杂得多：它绝对不等同于用户需要什么功能，我们就把这个定义成一个产品需求。很多时候，用户都并不清楚他们真正想要的是什么。用户说，我很热。你可以给他一个风扇，甚至给他一台空调，但也许你给他一杯水就能解决问题。用户说，你们产品的更新过程太慢了，需要十几分钟！你可以去优化下载流程，压缩下载包尺寸，但也许你只要把更新工作放在后台执行而不影响用户的正常操作，他就很满意了。需求定义的工作一般是PM的职责，但是，开发团队是最终把需求转换成产品的人，开发对产品需求的理解和定义，也在很大程度上决定了产品在用户面前是什么样。这个时候，测试需要参与进来，和开发一起来理解需求，定义需求，Review需求。这个过程，在有些公司，叫做SRS(Software Requirement Specification)的形成。
开发在理解需求之后，就要开始设计了。设计决定了他将来的代码会写成什么样。好的开发流程，测试一样需要参与设计的Review；即使很多国内公司把这个都省了，开发直接写代码了，测试仍然有机会参与。可以跟开发聊聊他会如何实现，如果你经验丰富，他一样会很感激你给予他的反馈和帮助。代码写好之后，在正式Check In之前，还会有一个非常重要的环节：Code Review。作为测试，你如果想要知道你将来的测试用例该如何更有效率、更有针对性，你就得好好利用这个机会，好好Review。
测试参与CodeReview的好处远不止帮助开发发现一些显而易见的代码错误或是其他一些Code Review可以发现的Bug。Code Review可以帮助测试从设计上更好的理解产品。也许你不需要理解具体每一行代码他为什么要这样写，但你必须了解他的大体程序逻辑，有哪些输入场景、输出场景，有哪些条件判断，有哪些是复用稳定的旧的代码、哪些是全新写的代码，还有哪些是会被其他模块、甚至是需求从没讲过模块调用的代码功能......这些都是你后面设计测试用例的绝好素材。同时，你还可以根据你的经验，提醒开发应该把某些适合的基础场景实现单元测试，或是让开发自己做一些基础的冒烟测试。这些都对你后面的测试工作大有帮助。
好的开发流程对于软件质量的保障作用是非常大的。也有人抱怨，如果公司的开发很不讲流程怎么办？我个人的答案是，别人可以不讲流程，但如果你是一个优秀的测试，如果你懂流程、你可以证明按照你的流程结果更好，你还有一个责任，就是需要你去推动别人来遵循流程。不要以为那是经理们的事情；很多经理在这方面经验也许都没有你多；但好的经理他们会看清什么是对的，如果你在做对的事情，你肯定能够得到他们的支持。最重要一点还在于，如果你一直能够在带头做对的事情，在做你认为是TL、经理该做的事情，你离经理的位置也不会远。况且，测试流程也绝对不是只有经理们才需要关注的事情。
（这部分按照开发流程，应该写到设计用例的前面。）
如果这三个工作都做好了，可以说测试工作的大部分工作都完成了；剩下来的就是测试用例的执行了，以及为了提高效率的自动化、一些工具的实现、测试框架的精炼和使用，或其他一些琐碎的事情了。现在很多公司开始把测试用例执行外包了，说明这确实有需求市场；也有人在讨论这样会不会让外包公司的测试人员觉得测试低级而无趣了？我觉得对也不对。对确实是因为相比测试用例设计而言，单纯的测试执行在技术程度上要求要低；但不对，是想说，尽管是执行，测试人员一样有很多空间可以发挥。谁说测试执行过程中间就不能扩展更多、更有效率的测试用例了？被大家一直都看好的自动化测试难道解决的不就是测试执行的问题吗？探索性测试(ET)研究的重点不也是单纯的测试执行问题么？同一条测试用例，好的测试人员和普通的测试人员的执行结果和价值也是有很多不一样的。
这些工作做好了并不意味着，这些工作在前面阶段做完了，后面就再不需要做了。实际上，很多问题都是在测试过程中，根据自己经验调整原有的测试用例、甚至新增加一些测试用例发现的。我强调的是这些工作内容应该是测试人员日常工作中的主体。在整个开发流程上，它们往往会呈螺旋叠加的。
所以，我们用什么来做测试？答案绝不应该是某一个测试框架，或是某一个自动化工具。
如果你也是测试，你的答案是什么？