1．规范化软件测试是增加项目成本
增加软件测试人员和预留项目测试时间，表面上看是增加了人员成本或延长了项目周期，为此会投入了更多的项目资金。然而我们知道，越早发现软件中存在的问题，开发费用就越低；美国质量保证研究所对软件测试的研究结果表明：在编码后修改软件缺陷的成本是编码前的10倍，在产品交付后修改软件缺陷的成本是交付前的10倍；软件质量越高，软件发布后的维护费用越低。

所以，即使您的客户（包含本公司市场部人员）有最好的忍耐力，或愿意免费充当你的测试队伍，前期找出缺陷也是会省去很多的后期排错和维护的费用。加上由于产品不成熟而造成市场声誉受损，单从经济效益方面来考虑，前期足够的测试也是值得投入的。

2．期望短期通过增加软件测试投入，迅速达到零Bug率
即使你有充裕的资金，也不是说软件测试投入得越多越好。增加测试人力和时间上的投入，的确能帮助我们找出更多的Bug。但二者不是一种线性关系，随着测试投入的不断放大，产品质量上升是逐渐收敛的。一个项目投入10个测试人员，发现了70％的缺陷，并不表明投入20个人就能找出几乎所有的Bug，也许这个数字只会是85％。

所以，根据公司的具体情况，如策略方针、市场定位以及产品类别等因素，来决定开发和测试人员的比率和测试投入才是合理的。举例来说，做一个ERP 解决方案、一个杀毒软件乃至一个航天飞船的控制系统，对测试的要求（包括技术结构和资源占用等）肯定是不一样的。

另外，软件质量的好坏，和整个软件开发过程的优劣是密不可分的，决不是仅仅通过加强测试就可以完全控制的。

3．期望用测试自动化代替大部分人工劳动
目前，很多的企业首先是从节约成本的角度考虑去引入测试自动化工具的。

是的，自动化测试工具的确能用于完成部分重复、枯燥的手工作业，但不要指望他来代替人工测试。一般来讲，产品化的软件更适于功能测试的自动化，由标准模块组装的系统更好，因为其功能稳定，界面变化不大。性能测试似乎更加依赖于自动化测试工具（如模拟多个虚拟用户和收集性能指标等），但考虑购买时也要注意，假设一个软件不支持DotNet Remoting，也许她就不一定适用于贵公司。

不要因为自动化测试工具前面有”自动化”三个字就认为他的主要目的是来代替手工劳动的。不要因为大部分测试自动化工具有“功能“和“性能”两种脚本类型，就认为自动化测试不是做用户界面验证就是做产品性能检测的。不需要昂贵的自动化工具，某些重复测试任务也可以考虑用编程方式实现自动化。

我们认为，大部分情况下，原则可以是：自动化20％的测试用例，用于覆盖80％的用户操作密集的功能和核心商业逻辑（如工资计算准确度要求高，虽然每月才执行一次）。实现功能测试自动化来完成重复、枯燥的回归测试任务，引入性能测试自动化工具来改善你测试的广度和深度。同时带来一点好处是，毕竟机器和脚本是客观的，他总是会完成你所分配的所有任务，而没有半点遗漏，从而自动化有助于你真正掌握和控制你的回归测试覆盖率。

4．忽视需求阶段的参与
按笔者的理解，软件测试工作同时兼顾了“证明软件的实现和需求是一致的”和“验证软件在某些情况下可能会产生问题”的两个方面。因此，测试人员对需求的理解就从另一个角度影响了整个测试工作的可靠性和效率。

测试人员和开发人员同时、同等地从上游获得需求，并持有自己的理解，可以排除部分功能实现和需求错位的问题。

同时，资深的测试人员整天和产品打交道，兼有另一种特殊的“公司产品专家”的角色，在某个行业或公司久了，完全有能力提出好的功能和设计方面的建议。

在某些公司，需求文档本来就不是很完善，从市场调研人员到项目经理、开发经理，Leader，再到具体Coding的程序员，每一层之间的传递都有可能存在需求理解上的偏差。让测试人员参与需求阶段的工作，可以在一定程度上起到双保险，更好地杜绝需求和实现之间的差异的发生。

5．忽视用户操作密集和核心功能的回归测试
做过测试的人有这样的经验，当项目趋于结束的后期或产品维护阶段，正常功能性操作的缺陷会逐渐减少，或者发现，执行当初的测试用例已不再能高效的发现Bug了。

这个时候，安排做一些拓展性或异常操作方面的随即性测试，能利于挖掘出更为隐蔽的缺陷。 但此时，不要疏忽定期做主要功能的回归测试，特别是在每个阶段性的Release前。毕竟常用功能和核心业务逻辑是用户最关心的，试想又有谁能接受“复制、粘贴功能不可用的记事本”和“工资老是算错的财务软件”呢？

也许这倒是自动化工具的一个用武之地。

6．忽视软件测试建档
对于软件测试，四个最典型的书面文档是测试计划，测试用例，缺陷列表，分析报告。

测试计划：测试作为整个项目工程的一部分，在早期做出较为详细的测试范围，人力预算，执行时间，技术需求/培训和软硬件资源占用等方面的考虑，便于有目的、有计划地完成后面的测试工作，测试Team也能更好的与其他Team协作。后期评审中，以此为一个基线，更容易发现执行中的问题和及时作出调整。

测试用例：可以让参与测试的人员，特别是那些平日总是有点被动的人（我想每个单位或多或少都有吧），花足够的精力，第一时间去系统地理解需求。在此基础上进行的同行评审，则可以防止需求理解的不彻底和偏差，尽早发现可能存在的测试漏洞。同时，测试用例作为新旧人员交替时知识传递的媒体，利于新人（时常也有从其他Team借调的人员）尽快切入特定模块的测试工作，而不是被成堆的需求文档所淹没。

缺陷列表：好的缺陷管理应该引入一个软件系统，而不是使用传统意义上的Word或Excel文档。想象一下，当缺陷数目达到几百个，按照某些工业模板去生成Bug文件，怎能做到方便的管理、查询和分析？如果测试周期持续很长，测试人员又不止一个，报Bug前寻找雷同的旧记录都将非常费时，费力。

分析报告：笔者建议，每个测试周期结束，至少完成两个方面的总结和汇报。

一，产品质量方面，主要从缺陷分析的角度评估当前产品或部分已交付的功能，确认是否符合项目最初的时间计划和质量要求。

二，测试过程方面，对照当初的测试计划安排，评估执行是否彻底，说明所遇问题，并以此做出及时调整。总结和汇报的最终目的是调优：持续改进测试的过程，使其符合本公司实际情况，更加高效、规范。

7．软件测试是技术要求不高的岗位
单从目前用人最多的黑盒功能测试（暂且这么说，其实这种分类有时并不是很明显）岗位来说，测试人员对计算机技术的要求也许可以不是很高。

一般来讲，测试人员除了逻辑思维，沟通能力等自身素质外，技能暂且可分为两种：一是行业知识，比如丰富的财务或ERP实施经验；另一种是计算机技术，如计算机语言和软件项目经验。

好的测试人员，不光要能不懈地执行常规的测试任务，更要有严谨的态度和严密的思维，去覆盖更多的”可能”，发现别人很难找到的bug；利用自己丰富的行业经验，判断需求到系统功能的实现是否合理；站在一定高度对软件框架，设计方法，项目管理等做出合理的建议。所有这些，加上软件测试管理相关的其他技术（如配置管理等），又怎能说，要求不高，前途不大呢？

9．不当的认识和不合理的组织架构
和开发人员同属一个大的团队，测试人员总是寻找开发人员的错误，并“乐于”将之公布于众。 有些开发认为, 一直受别人监督，心里难免有些戒备和不愉快。

其实，测试和开发人员之间，任何企业都不是在树立一种警察和小偷的关系。如果我们开发人员换一个角度，把测试人员当作你的伙伴，使其为你服务，理解他们的工作目标是“使你作品更加的完美”，那何尝又不是一件好事呢？据笔者的个人经验，善于“利用”测试TEAM的项目主管总是会很有收获。如果恰好你就是个主管，不妨回头考虑一下以下问题：测试TEAM在项目进度、阶段性产品质量等方面曾经为你提供过多少有用的信息？他们又是如何PUSH整个团队向前的？

软件产业相对于制造业起步较晚，工业化的生产方式还不够成熟。直到今天，软件测试的重要性并未被大多数的国内企业所重视。在很多公司，测试还是开发的附属工作，由写代码的本人来完成。暂且不谈个人思维定视带来的局限性，如此操作，测试是否真正的被充分的执行，本身就是一个问题。

再好些的公司，有了专职的测试人员，但他们依然属于开发TEAM，并总是安排由其中一些经验和资格相对较浅的人来完成。测试人员每天运行开发丢过来的并不完全能RUN的程序，文档不完整则依附于开发人员给于讲解，日子一长，以至于做一个真正的开发便成为他们的第一理想，还谈什么测试技术的学习和职业的发展？

我们建议，对具体项目的测试TEAM的领导可以是双重的，其分别来自于 项目主管和部门主管，并总是保持相对的平衡。