你用什么来做测试？

发布时间: 2011-12-14 11:14    作者: leafy1980(CSDNblog)    来源: 51Testing软件测试网采编

字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿  | 推荐标签： 软件测试

　　先讲自己遇到的两个小故事。

　　去年底新开始负责一个项目的测试工作，这个项目在我之前，并没有正式的测试人员，开发写完代码然后就自己测试一下，没问题就上线。一次和相邻团队活动，一开发技术牛人得知我是新来负责测试的，寒暄之余，他的第一个问题是，你是用什么来做测试的？

　　听到这个问题，我不禁一愣，他问的“什么”是什么意思？是指一种测试框架？或是一种测试工具？或是一种测试方法？还是其他？我赶紧回答，我正在准备自己的一套测试框架，也在吸取社区上的各种成熟的东西，测试用例也在建设中。

　　做测试5年多时间，之前从没被问过这个问题。

　　进入项目的前两个月，我在整理之前开发用到的各种测试方法和测试工具，一方面为了自己了解这个项目的状况，另一方面也可以把以前的成果沉淀下来，为后面形成测试用例体系做准备。这时候来了一个测试的助手，因为是新人，我让他先看下我之前先整理出来的那些个测试用例，同时也可以结合自己的经验做一些扩展补充。他看了会，也跟我抛了个让我很吃惊的问题：你说的测试用例就是指哪几个工具？言外之意，就是觉得那几个工具就是几个命令行，运行一下不就可以了，还有什么可以扩展补充的？后来知道，原来他想写code，想做自动化。

　　我终于意识到，原来大家对测试的理解是有很大不同的。我不能讲他们的理解不对，因为他们的工作背景和经验形成的对测试的一些看法，在某些场景下确是对的；但我觉得根据自己以前的经验和个人认识，我对他们的理解有很大的不认同。

　　我就来讲讲自己对测试的一些看法，完全是作为交流的目的，有讲得不对的地方，恳请大家更正。

　　测试是干什么的？本着以终为始的原则来分析问题，我们首先需要了解测试的职责是什么：毫无疑问，测试存在的价值就是保证产品的质量，让产品给用户提供好的服务。所以，这个目标决定了测试该做的事情，一切与这个目标一致的事情，都是测试需要做的；而所有对这个目标无直接用处的事情，测试需要考虑是否该做；至于违背了这个目标的事情，应该杜绝去做。

　　所以，对于测试，最重要的第一件事情是需要了解产品。看上去这是一句废话，项目中的任何人都需要了解产品！我想强调的是，测试需要比开发在某些方面更了解产品。对产品的了解分为两个部分，一部分是需求，另一部分是设计。对测试来讲，对前者的了解优先级比后者更为重要。需求定义了这个产品需要做成什么样，它可以为用户解决什么样的问题，以及为用户提供了什么样的功能。而设计仅仅是开发为了实现需求，在基于自己对需求的理解上，用某一种方式实现了产品。需求决定了设计。

　　开发对产品的理解体现在设计上，而测试对产品的理解体现在测试用例上。

　　回到主题来，测试该做的第一件事情，是测试用例的齐备。可以没有所谓测试框架，也可以没有自动化，都不会从根本上影响测试质量；测试用例、测试场景不齐全，会直接导致产品潜在Bug没有被发现，用户拿到的产品服务质量很差。而且，我觉得如果测试场景没有完善，就急匆匆的去做一种框架或是自动化，也注定是很快要做重工的，因为很大可能你后面新加入的大量测试场景会彻底推翻你前期实现的测试框架、自动化模式。

　　当然，我也不是说要等所有测试场景都确定下来，才能开始自动化；自动化确实可以节省人力，腾出更多资源去做测试用例拓展；但要先确保最基础的测试场景完善。测试框架、自动化只是工具，它们的价值在于帮助测试人员提高工作效率，把一些劳动交给机器做，为测试人员省出时间去做更有价值的测试工作；但它们做到再好，对用户来讲，他们毫不关心；就像有人提到，Windows Vista的自动化测试程度很高，而忽视了用户体验，结果注定是一个失败的产品。

　　我这里的测试用例实际上是广义上的测试用例，包含各种测试类型：功能测试用例，性能测试用例，系统测试用例，兼容性测试用例，安全测试用例，等等等等。我觉得根据产品的需求或者项目的需要，提高测试用例覆盖度这个过程才是测试应该花大气力去做的事情、测试工作中的重中之重。至于如何去完善测试用例，有很多很多的方法、技巧和经验，我也在学习中，这里就先不聊了。

　　齐全的测试用例是为了可以尽量的覆盖产品逻辑，尽量可以发现潜在的Bug，或是尽量确认可以正常工作的场景。但这个过程的前提，就是开发已经实现了产品，他们已经有Bug潜伏在某些地方了；事后尽早挽救是一个好的方法，但如果能够事先预防，防患于未然，那更是大家期望的。在软件开发中，测试在项目前期的参与，对于保障产品质量非常有益。