看了一篇关于软测的文章，文中说到软测的三个阶段，最后一个阶段是说以人为本的测试，笔者略有感触，所以也来谈谈“以人为本”的测试。

　　刚进公司的时候，笔者也非常痴迷于测试流程，CMMI之类，觉得流程框架之类很伟大，指引并驱动着我们的工作，每一项工作都应该有输入输出，并且符合标准，基线化犹如心中女神一般，充满向往，心醉神往。然而软件工程发展至今，即便像出现了各种各样的开发流程，但由于其复杂性，易变性，等诸多其它人为因素，导致整个软件工程中的各个阶段都不可能百分百符合要求，甚至连百分之五十都没有，于是最后到测试人员手中的交付物可能寥寥无几，甚至质量低下，这不能说是其他人员的不努力，只能说是现状仍然没有一个比较完美的解决方案来保证每一环都没有偏差。

　　这是软件工程的现状，那现有的测试流程呢，我想一般公司的系统级别的测试流程大致多为制定测试计划，写用例，执行用例，跟踪缺陷。如果说这几个环节，每个都做到位，我想这样的测试一定是能够给软件带来极大信心的，只是又有多少人知道该怎么写计划，该写些什么，用例该怎么写，该测什么；大部分人都知道等价类边界值这样的测试方法，然而究竟该怎么样划分这个等价类，边界到底该定在哪里，又有谁能准确无误地描述清楚呢。流程规范告诉我们要覆盖所有的需求和功能，流程规范还告诉我们每个功能要用等价类边界值，异常分析等等方法去测试，流程规范又告诉我们要用用例去覆盖功能，这样的测试是充分的，是全面的。诚然，这些都没错，但是实际上可能吗。接着说到执行用例，一套不完备的，可能描述都有欠缺的，测试目标不明确的用例再去被执行，其结果可想而知，究竟有多少用例是有价值的，是能够真正发现问题的，这的确是需要打一个问号的，在实际的工作中，发现问题往往并不是依靠执行用例，而是测试人员的个人能力，于是引出“以人为本”的测试。

　　按照用例按部就班地执行无异于抹杀了测试工作者的智慧，软件工程正是因为其复杂性、创新性而区别于工厂流水线，一味地按照某一个固定的框架、规定、流程、程序之类必定是要死的。尤其是测试，测试人员需要的不是高效的执行率，循规蹈矩的态度，亦或是各种陈旧的方法技能，需要的是自身对于测试理解的高度，一种批判精神，一双敏锐的眼睛，一颗求真执着的心，和一个时刻都会有些古怪想法的脑子。在测试过程中，更不应该按部就班地执行用例，而是要不断探索，不断挖掘，带着一颗好奇心，像来到一个新大陆一样充满热情与兴奋。系统正常流程是这样，那如果我按一下那个，再点一下另外一个会怎样；如果我在地址栏里输入这些参数会怎样；如果我突然关机，突然断线，会怎样。时刻有这种新奇的想法，一定会带来一些意想不到的结果和体验。测试人员更应该比开发人员具备开阔的思维和想象力，来向开发展现另一个不一样的世界，他们从未到达的一种境界。开发关注的是如何实现，测试就应该关注开发没有想到的事情，甚至是前端业务人员没有想到的事情，这就是测试人员的高度，对于业务的精通，对于软件本身的熟悉，对于需求和功能的理解，都必须得有自己独特的见解和想法。依赖于个人经验和能力的测试才能真正做好测试这份工作，把这份工作带到一个新的高度，与公司层面相匹配的高度。

　　不管任何工作，只有真正“以人为本”，才能发挥自身最大的潜能，带来最大的效益，测试人员是可以证明这些的。