其实相对于开发人员显性能力的提高，测试人员的提高很多是隐性的，单从技术的角度来讲，测试员是拍马也赶不上开发人员的进步的，这很容易理解，你的测试脚本如果比你的项目脚本还多的话。。呵呵呵可能吗？
我来谈谈测试人员的隐性提高吧，在我们的测试过程中，即使是再枯燥的测试，也有可以学到的技术，这一点在昨日对整个系统做测试时，感触很深。
其一，严谨性
就一般的测试而言，往往只是判断功能是否能够正常实现，但慢慢的你在工作中会发现有些缺陷，是分角色的，相同的功能，管理员是正确的，普通用户是错误的，单独点击是正确的，执行了一个前提操作，再次点击就是错误的，在工作中，随着这样的BUG的积累，你在测试的时候就会有意思的更严谨的去思考，哪怕即使是一个发布和编辑的功能，你都会考虑到除了单独的测发布，编辑这两条用例，还有发布后编辑和编辑后发布这样的2条用例，你的测试工作将更加严谨。
其二，计划性
在工作中，尤其是一个人负责一个项目的新人朋友，我相信没有人指导的你们，很迷惑，对自己的工作没有办法做一个评估，对自己的工作量没有办法进行安排，工作闲得时候埋怨没事做，工作大得时候埋怨太累，其实工作量是可以自我控制的，这个控制是相对的，即时是工作量很大的时候，你也应该先在自己的心里构建一个流程，画上一幅画，将这个系统的布局，功能点的分布都在心里过一遍，再开始有计划的测试，哪些功能模块是关联起来的，哪些功能是独立的，对于这个的掌握尤为重要，假若工作量为100.有效率的进行测试你的工作量就只有100，如果经验丰富的话，比如你能够确定某个表单是相同的，这里不会出现的错误，另一个地方绝对不会出现，因为都是用得同一张表单，那么你的实际工作量可能只有80，而如果你不能进行判断，并且你甚至在开始测试前对整个系统都不在心里或纸上大致的分析下，那你的工作量很有可能是200，比如你在测试添加的时候，没有测试到删除，那么你测试删除的时候就会再走一次添加，这就是无意义的工作量。所以计划性很重要，并且只能在你工作中学习到。
其三，预见性和可分析性
这一点，有点不好讲，还是举个列子吧，测试同样的一个功能模块，测试员甲使用了10条测试数据，测试员乙使用了1条测试数据，都达到了相同的覆盖率和测试效果，那么这里就可以看出测试员乙的测试数据更具备针对性，也就是测试员乙在测试时更具备预见性，相同的一个功能页面，两个输入框，一个输入框要求数字，一个输入框要求字母，甲在测试第一个输入框时考虑几个方面但在对待第二个输入框时只为了快速操作随手输入了几个字母，这种情况经常发生吧，对吗？而乙在测试时，数据是关联的，即考虑了甲的输入限定也考虑了第二个输入框的限制，也就是乙的一组用例对应了2个输入框，这种做法无疑让你的每一份工作都有了应有的效益，也减少了你过多的工作量，这里实质上就是一个预见性和可分析性的工作经验，乙在看见该功能模块后，能够预见各个功能模块的关联操作，并记录好自己使用的测试数据，如果该测试数据到中途走不通了，就分析数据，寻找原因，这里就是一个针对性的测试，而甲所做得就是广散网，缺少了针对性，自然，工作起来就很枯燥了，乙就不一样，他的每一分工作时间都是在思考中的，每一个步骤，每一个操作都是有目的的有意义的。随着我们工作的时间积累，这一点会越来越明显，比如一个10年测试经验的人绝对不会再去对一个输入框做一系列的等价类边界值划分，他们只需要输入几个特殊的数据，就可以实现很好的覆盖，对于一个有经验的测试员，他所使用的每一个数据不说百分之百都有价值，但百分之八十都有可分析性，让开发人员能够从这些数据中快速定位Bug，这份能力减少的不仅仅是测试员的工作量也减少了开发人员的工作量。
其四，判断力
作为测试员在判断是否是Bug的时候是需要具备一定的判断力的，最低要求能够判断这是不是缺陷，之前的博文中提及过，现在的很多开发人员已经在进行自测了，也就是单独对功能点进行测试的时代正在蜕变，在我们寻找Bug的时候已经不能局限于点击按钮是否报错，而应该从更深层次去定义缺陷，这里就需要足够的判断力，虽然我们常常说测试要从文档开始进行，文档测试通过后再来开发，但实际中很多时候测试人员的介入已经是在项目中期或者晚期，这个时候项目都快要完成了你再测试文档也没有多少用了，这个时候你就要根据实际情况考虑功能的合理性，也就是将文档测试上得技巧运用在实际测试中，假如你判断某个地方在设计的时候是有问题的，你就应该提出来，而不是他不报错就可以了，比如一个页面有两个查看的功能一个名为查阅，一个名为查看，实现的功能和方式完全一样，这个时候你可以很直接的要求只保留一个查看功能，这是对设计上的缺陷要有足够的判断力。另外在判断缺陷严重程度和优先级也会在我们工作的过程中逐渐提高，刚接触测试的时候，也许你认为只要是Bug都是万恶的，都应该立即改掉，接触一段时间后，你开始意识到有些Bug是可以滞后修改的，有些bug是可以允许的，熟练后你甚至会认为有些明显是缺陷的地方是不需要管得，最直接的列子对于注册用户名和密码，新人也许会纠结在需求不明中，用户没有限定数据类型，没有限定长度，没有一个标准怎么测？熟练后，就不会考虑这个问题，根据实际项目如果用户对登录本身并不重视，只是起一个登录作用不需要做都少验证，那么就可能只测一下正确能不能登录，错误能不能登录一些情况而不会过多的去考虑长度，数据类型，这些都需要判断力，也正是我们测试的一种经验，是我们在工作中可以提高的能力。
