在实际项目过程中，存在不少对测试的误会，听着无伤大雅，但是如果真的这么做了，可能测试朋友们就要和你友尽了。我们这里摘录几条，看起来都好“有道理”啊！
说法一、测试在开发结束后才开始
这样的说法在多年前一度很占上风。开发都没结束，测试怎么进行啊，测什么呢？想想真的好有道理啊，我还能说什么呢。
不过经过这么多年的教育和熏陶，现在官方场合的言论中，已经很少这么提及了，毕竟这样的提法多少有些“政治不正确”。我们知道开发结束后，开始的是测试执行，而不是整个测试。按照伟大的测试生命周期理论，我们也是有测试需求、测试计划、测试设计、测试环境准备等很多工作要做的啊。
只是到了实际的工作中，一些行动最能体现这个想法。
比如项目资源分配的时候，各类测试服务器往往在测试执行前夜才如“及时雨”般就绪，毕竟支持部门也很忙，前面给你们也用不上啊。还别不高兴，你看隔壁的项目组是进入测试执行阶段，我们才把测试环境的准备提上日程的。
比如我们不少客户找上门的时候，都是万分焦急；为什么呢？因为开发已经基本结束，测试该进场了啊，不然赶不上上线时间表了。碰到这种情况，我真想补一句：大哥，早些时候干嘛去了啊；现在这个点进去要赶上这个时间点，臣妾表示做不到啊。
说法二、测试的意义就是发现缺陷
这个提法，我相信现在也非常有市场。不少测试团队一直有着“以发现BUG为荣”的指导思想。这个无可厚非，能够发现BUG，尤其能够发现别人不能发现的BUG，显然是一种技能，甚至是一种天分。一些测试团队的绩效、以及一些测试大赛也都是以发现BUG的个数（或者加权个数）为指标的。
只是，如果过于强调这一块，甚至让测试的意义与发现BUG划上等号，则有违质量保证的宗旨了。
举个例子，大家知道在功能测试中会有回归测试的部分，侧重于对原有功能的再次确认，这部分测试大概率是不会有缺陷的。那么，以缺陷为价值评判指标的话，这部分测试会显得没啥意义。但是，真相并非如此，要知道现在市场上的自动化测试绝大部分是以回归测试为对象的；如此大的投入，绝对不会用在一个没有意义的事情上。而且哪怕是全新功能的测试，但凡所测软件不是“极品巨作”，能够发现BUG而通不过的测试用例所占的也是小比例。所以，不得不很抱歉地说一句：我们又做了好多无用功啊。
其实，测试工作有很大一部分的作用是给产品盖一个“质量已检疫”之类的印章，而不是一定要证明这个产品哪里不行。江湖上有一个说法：功能测试前期是抱着怀疑的态度和找茬的信念去找系统的BUG，而后期回归测试是以严谨的作风去验证这个系统是无错的。
众所周知，在一个系统提交上线前，往往会进行多轮测试。因为第一轮测试完后，会有缺陷；那么修复缺陷后，显然得再测一轮去验证。这里问一个问题：如果系统今天就要上线了，在“最后一轮”终极验证中，作为测试的你是祈祷测试用例全部愉快地通过，系统可以顺利上线呢？还是说希望能找出一个BUG从而扬名立万，然后陪着开发加班改完BUG又来一轮终极测试呢？【请注意，一脸坏笑的测略君绝对没有诱导大家刻意去放过一些缺陷，我们的讨论是以职业操守为前提的】
说法三、提交缺陷是测试的事
看到这个说法的时候，大家是否觉得：这不是废话么?提BUG是上帝赋予测试的神圣使命啊。感谢这个神圣的安排，提交缺陷这个事情，测试人员本来就责无旁贷啊。
我们一直在强调一个共识，就是保证质量是整个软件团队的事情，而不仅仅是测试人员的事情。那么换言之，人人都有责任去提交自己发现的缺陷。事实上，几乎所有的缺陷管理工具，对于提交BUG这个事情都是不限角色的；这些工具创造者们的理念领先我们好多团队的实践。
在这点上，用户往往是除了测试以外最热心的了。我们有好几个用JIRA或者Redmine工具的团队，经常看到用户在系统上提交各个阶段发现的BUG，只要他们在某个环境上发现了问题。与之相对的，在软件团队内部，可能做得就不够好。
前几天，在一个调研聊天中，与一位开发聊起PeerCodeReview和开发测试。我就问了一下“如果发现了问题或者缺陷怎么办？”“和对方说一下，然后改掉。”我不死心地追问：“不会记录到JIRA里么？”“这个太麻烦了，开发改起来很快，马上就发新版本的。我们一般是测试发现的BUG才登JIRA。”看起来是我太过于认真了，尽管团队实施敏捷有一段时间了，但是距离人人都是QA的境界还有很长的路。
不过，身边还是有一些开发非常热心，喜欢报一些BUG的。最近，公司在推一个问题反馈系统，反馈的对象也包括公司使用的内部系统。一段时间后，我们对于热心提问题的同事发了一些奖品，排名第一的是一位QA，毕竟是本色表现么；而紧随其后的则是一位开发，这个就不得不点赞了。所以各位QA们，如果身边有乐意报BUG的开发，一定要记得对他好啊~
说法四、自动化测试就是使用工具
很多次，我在和人聊起自动化测试这个话题。对方就会问起：你们用什么工具的？也有一些场合建议一些测试小伙伴学点自动化测试，他们也会很直接地问：学哪个工具有前途呢？每次面临这个场景，我竟有种无言以对的尴尬。
而自动化本身的内容也远不是一两个工具可以涵盖的：从自动化对象上，会有测试管理、测试数据准备、测试环境搭建、测试执行等各个环节；从测试类别上，可以应用在功能测试、性能测试、安全测试、兼容性测试等；从实施方式上，可以自写脚本、可以使用工具、可以搭建框架等等；从方法上，诸如录制回放、数据驱动、关键字驱动等等；……
基本上，但凡你能想到的所有测试工作，能够替换手工的动作和方法，应该都是在自动化测试的范畴中。所以每次有客户提起要做自动化，我都会问清楚具体目标是什么，以免产生误会。
当然，通常概念上的自动化测试主要是指测试执行的自动化。具体实施确实离不开工具，所以对于工具的精通和使用绝对是一个必备技能。至于哪个工具更好，只能具体问题具体分析了。而且工具也绝对不仅仅是我们所熟知的那些被贴上自动化标签的。要知道自动化测试的本质是用代码代替手工，即我们把测试当作一个业务对象去开发一个或一套支持系统，因此任何编程工具都可能成为有效的自动化测试的工具。
举个例子，在编程界很不起眼VBA就是一个自动化测试界的神器，用以支持测试中的数据收集、数据对比等各项数据处理流程和动作，方便快捷。比如我之前团队就有成员用VBA写了一个蕴含相当复杂业务逻辑的风控报表比对测试工具，大量基于数据的计算和对比都蕴含在那一个外表平常的Excel文件中；又比如也有QALead觉得收集各类测试报告太麻烦，用一个宏实现特定目录下固定格式的测试执行数据收集，生成测试报告不是难事。
