产品开发初期需要测试人员吗？如果需要，他们要作哪些工作？这些问题曾经被很多朋友问起。据我个人了解，很多国内中小型公司是不注重产品开发初期乃至整个开发过程中的测试工作的。例证一：有些公司认为在设计初期投入测试人员是代价高昂且无意义的，所以他们会要求产品开发的第一个周期结束后，开始设计测试用例。 例证二：认为测试工程师不需要参与到制定需求中，他们只要接受就可以了。于是乎，就出现了市场部门和开发部门直接沟通项目需求，测试经理直接参考需求设计 文档的状况。例证三：测试经理确实在产品开发初期参与项目需求的制定，并写出测试计划。但产品质量却是现场部署的工程师说了算。到了现场，发现这里不合用 户的意，那里运行不过。为了赶时间，只好坐在用户现场直接调试。改代码的改代码，调试的调试，哪里还管着产品是否需要全面的测试，只要能运行起来，用户能 用，就是胜利……

        权且不说这些管理行为是否更加浪费工钱，我们应该很容易得到关于“产品开发初期测试人员该做些什么”的一致答复：测试计划在开发初期能写挺好，不写也没什 么问题。测试一定要做的。但把怎样的产品交给用户是不确定的。目标就有一个，让用户用上再说——无论是对一个已经经营多年的产品，还是一个刚起步的公 司……

        其实，对测试的理解不是点头说，测试很重要就够了； 对测试的理解不是去声称，我们有一柜子完整的测试文档；对测试的理解也不是只关心“做与不做”，而全然不理测试的有效性。

        软件测试该如何理解如何执行，是一个很大的题目。在这里，我更关心的是在项目设计初期，我们该不该忽略测试人员，而测试人员又该做些什么样的工作。

        微软最 新的软件开发周期（product life cycle）分为产品定义（Product Definition），产品开发（Product Development），产品服务（Product Servicing）三个阶段。为了使资源得到最有效的使用，测试人员主要参与产品开发和后期服务这两个阶段。而在产品的定义阶段，则会有选择的要求一些 资深测试工程师和测试经理一起参与。他们主要负责：通过验证产品核心功能或用户使用场景，确定产品各功能的优先级；参加产品使用场景定义的评审；参加用户 体验文档的评审等。

        当然每个公司应该定义适合自己的开发模式。但是是否让测试工程师参与这些工作的主要目标应该是没有区别的：首先是熟悉客户需求；再来测试工程师应凭借自身 经验，从测试和维护的角度来判断被细分的客户需求中，哪些是合理的，哪些是不合理的，并反馈给项目经理或市场部门，以供他们参考；最后，则要根据这些项目 需求以及软件架构的文档，给出测试计划。

        上面这番描述是不是看上去并不很复杂，也不重要呢？非要在项目初期做吗？最终不都是根据需求文档来写测试计划嘛……

        这当然是很重要的环节。理由如下：

        1． 产品的可测性严重影响了后期测试团队的工作效率以及测试的有效性。越早提出此类相关问题，越可能进入开发工程师设计范围。同时，该项指标可为项目经理提供一个与“开发难度”并列的“测试难度”——这将会影响到项目负责人对开发周期的设计。

        2． 除项目经理外，测试工程师是最需要了解用户需求以及用户使用体验的角色。参与这些由产品经理，项目经理编写的文档评审，会让测试工程师们得到除了列在文档 上的核心需求外更多的信息——我们必须承认，因为人的因素，文档是不可能涵盖所有信息——这将会帮助工程师们以更快的速度对产品需求有更深层次的理解。

        3． 使得测试经理能够更早做出“是否需要提前编写测试工具或搭建测试平台”的决定。而这是很重要的一点。测试在开发流程中，因其所处位置，很容易因为开发团队中的突发事件导致周期被压缩。而自动化测试工 具虽然可以节省人力，但相比于手工测试，开发周期较长，见效较晚。通常一个工具从开发到可以用于测试需要一周到数月不等——完全取决于工具的规模。因此， 尽快确定“是否需要编写测试工具”是必要的。它可以帮助测试团队“抢回”更多的时间用于设计和调试测试工具，从而达到更好的测试效果。甚至可以避免掉因为 时间不够，而拒绝采用自动化工具转为手工测试的被动局面。

        理由其实还可以列出很多。但是，我觉得这几点应是最为主要的。它们能足够说明为什么测试人员需要参与产品开发初期的工作以及他们需要做些什么的问题。这里 再重复一下，在开发初期测试工程师需要：确定产品的可测性，了解用户需求，确定需要引入何种测试工具或平台。

        所以，在开发初期做好测试计划并不是可有可无的；用户需求不是只要工程师“买单”就可以的；不理会测试团队而埋头开发的产品，将会是一场“噩梦”，特别是当产品发布/部署的时候。

        但每个公司每个项目组不需要套用一样的模式。针对不同的需求，我们应该量体裁衣，做不同的剪裁。只是核心不该有变化，目标不该有变化。就如同国内一些公司对CMM的追宠——光有形，没有神，是实在不可取的。

        测试工作, 有轻松的时候,也有繁忙的时候,但总的来说忙大于轻松。记得刚上手测试时,不知道从何下手?产品的操作手册和命令手册,最基础的DD,却是新人最好的参考 资料;产品的操作手册和命令手册面向的就是用户,对于新产品,用户也是新人;产品资料,不仅仅是告诉你怎么使用它,里面还包括很多概念的阐述,功能的简 介,和部分实现方式;对于测试来说,都是很重要的资料.

        看产品资料的同时,也要学习产品所基于的协议,标准之类的;协议,标准阐述了功能的实现方式;在动手测试之前,需要有一定的了解.此时,不需要深究;以后随着测试的深入,自然而然会有更深的理解.

        当中,还应该初步掌握测试平台,测试工具和测试方法;不然开始工作时,那些测试工具会让你傻眼;虽然当你会用后是贼简单的DD,但是没有用过却是不怎么好用的DD!

        新人上手后,会经历这样的一个过程:自己测试的模块怎么问题很少,而其他同 事复杂的模块的问题那么多,为啥呢?实际上是这样的吗?答案是否定的!因为新人刚开始,对产品的熟悉程度还不够把产品里隐藏较深的问题发掘出来;还有,毕 竟是新人,还没有形成适合自己的一套测试方法和测试理论,这些都是需要通过长期的经验积累和总结才可以形成的.这时,新人可以查看前辈们的问题单,看看前 辈们是怎么样进行测试的,他们的测试过程,方法是怎么样的?对于新人来说,问题单是很多的学习资料.对于自己的测试方法和理论的形成有促进的作用.

        之后,信任就开始了漫长的测试执行阶段.测试是具有重复性的,相同的功能模块,相同的产品测试久了会有厌倦的心理;这时需要适当的调整下.可以和同事换模块测试;不仅可以避免测试的重复性,还可以学习新的技术,而因为人与人之间的测试方法和测试理论总是不一样的,一个模块让不同的人来测试,可以测试出不一样的问题来,对于产品的测试,更有覆盖性.

        而后,等测试时间的增长,测试人员除了测试执行外,其他测试工作会越来越多:测试设计(测试点,测试用例的写作)、外对测试用例的协作、各种开发\测试文 档资料的评审、对外测试支持、自动化脚本的写作、实验局开局等等;虽然这些工作对于测试执行来说,没有了相对的重复性,但是这些工作的难度或者说是复杂度 是大大增加了:因为测试执行只需要跟着测试点跑功能就成,而后面的这些,可没有那么简单.就举对外测试支持来说,外面运营商或是产家的测试注重实际运用的 测试,而新研发出来的产品在公司内部注重功能测试, 当然也是注重实际应用的;可是是新产品,外面还没有大规模应用的情况下,相对来说,实验室的测试和外面的测试差距还是蛮大的,所以需要测试人员反应要快, 能够在短时间内搭建好测试平台和测试环境,对对面突发性的测试需要进行验证;如果在产品不支持的情况下,需要研究出其他的解决方案来满足外面测试需要的功 能.

        对于测试人员来说,在测试过程中,或多或少总是会发现一些不是必现的问题.对测试人员来说,需要把问题出现时的现场在问题单中描述的很清楚,(配置文件, 操作过程log,流量的类型和大小等等)而且尽可能的对发现问题进行复现操作,当然这个过程也需要把握时间,因为测试版本的时间本来就是比较赶的,不能消 耗过多的时间在复现问题上.当整个版本在该论测试完成后,可以考虑集中时间对不能重现的问题进行复现工作.而在复现工作过程中,可以开发人员进行交流.因 为开发人员对于产品实现的流程比较测试人员要熟悉,一般来说开发可以提出一些很有价值的观点,有利于问题复线工作.

        测试产品时(测试资料,评审文档),测试人员需要带着怀疑的观点去测试,这个观点往往对于测试新人来说,是比较困难的.新人很容易是带着去验证的观点去测 试(总是认为产品,文档资料都是正确),所以发现的问题比较少;当如果换个角度,采用怀疑的观点去测试时,会发现很多原先没有发现的问题.特别是一些设计 方面的问题.虽然功能是没有问题的,但是实现的过程或是方法却不是最优的,这些问题是新人很难发现的,当然也是需要一定的经验积累的.