无数事实证明，专业的测试必须要由无利害关系、独立的人或团队来进行。原因是多方面的：第一，开发人员编写的程序，就好比父母对待自己的子女一样，都是凝聚了心血的成果，所以审视的目光通常不会客观；第二，有的时候设计和开发人员本身的理解可能有误，陷在错误的圈子而不能自拔，这时候必须由它山之石来引入全新的思维才可能跳出这个圈子；第三个理由可能比较阴暗了，对开发人员来讲，发现了BUG是一种痛苦，因为意味着自己要投入更多的时间，加班甚至牺牲周末，而且领导不会领这种情；谁让你编的代码有问题呢？可是测试人员则没有这层顾虑，他们非但不会因为BUG的发现而损失什么，反之还有可能立功受奖，以产品质量的维护者自居，于公于私有利无弊，所以，由这些人进行的测试一定是很有动力的。项目干多了，你会发现，这第三个理由是更直观站得住脚的，尽管它无情地披露了大家灵魂里的阴暗面。
而且公司要直面市场的压力，人在长时间的重压下必然要选择逃避和释放，这是人的本能反应，与责任心无关。如果你以为开发人员会自己主动地毫不留情地测试自己编写的程序，你真的是太天真了，即使有这种可能，那他也一定是别有用心，比如以此获得老板的青睐。
测试的第二个作用，确保我们开发活动的方向是正确的。这听起来有点神了，但是光靠测试能够做的吗？
这是一个宏大的命题，应该是项目所有的参与者共同努力的方向，产品的大方向不能说是由测试在独自把握着。不过在此过程中测试可以起到很大的作用。
软件研发团队的成长和小孩子刚学走路是一个逻辑，是无知和自负的（经验不足的研发团队，某种程度上也是无知和自负的。）。正常情况下，无知--->碰壁--->吸取教训，这是一个很好的成长过程，吃一堑长一智嘛。但是市场和用户没有父母那么慈爱，他们不会因为你年轻就温良恭俭让了。在他们的强大压力下，研发团队比小孩子的选择还要少，他们只能硬着头皮向着未知的领域冲，而且不能犯错，很多时候犯了错误碰了壁就意味着Game over。
那岂不是没有办法了？
办法总是有的。如果小孩子学习走路，耐心的父母可以尝试着预测他行走的路线，清除掉他前行的障碍，随时注意他走路的姿势，确保他的每一步都踏在预测的路线上，这样就能制止他走到危险的地方，从而很大程度上保证了他的安全。这其实就是软件项目中测试的作用。在设计阶段参与，预测项目行进的方向，预测项目的风险并及时排除；在项目执行过程中，注意监督每一步都是按照事先确定的方向和时间在走，如果偏离或延迟能及时发现并纠正，项目就会始终健康地进行下去了。说起来容易，但真正实施起来会有各种各样的挑战。开发项目中究竟会遇到那些障碍，事先我们是无法一一看清楚的。这时就需要项目管理者的经验和洞察力了。测试在这个时候能起的作用就是提供数据和事实来帮助项目管理者做出正确的决定。
测试中都能提供那些数据和事实能起到这样的作用呢？
软件测试报告的主要内容：
（1）软件成熟度的定量评估（总体来说和问题的严重性、数量、出现频率、新模块的数量和规模等等因素相关）；
（2）测试用例通过率和不通过率（最简单一目了然的方式来了解当前软件的状况，通过率越高不通过率越低，软件越稳定。但缺点就是无法与那些测试用例意外的问题相匹配）；
（3）软件成熟度变化趋势（通过变化趋势，我们能够看出软件变成熟的速率，可以帮助管理者预测项目还需要运行多久）；
（4）今后可能的问题和成熟度走向（与变化趋势相关的信息，尤其适用于当开发进行中，一些新的不稳定模块即将加入到软件基线中，那么在可预测的将来这些模块会带来新的问题，从而影响软件的成熟度）；
（5）严重问题列表（最实际地反应当前软件的风险在何处，尤其当讨论产品是否可以上市的时候，这一内容尤为重要。管理者需要这一数据来判断上市的风险是否可以容忍）；
（6）一些关键问题的风险评估（有问题不一定严重，问题严重但用户不见得关心，这些信息需要借助测试人员的经验和判断，管理者也会参考这些信息做出正确的决定）；
有了这些素材，项目的管理者能够对项目的过去、现在和未来大体有一个判断，这就相当于提供了项目的行进方向，比起单纯地发现问题来说，这种帮助更为宏观和具有战略性，是测试的更大价值所在。
相关链接：
