随着软件市场和客户需求的变化，敏捷开发模式逐渐成为重要的角色，而客户响应频繁、需求更新快、开发周期短、迭代次数多等特点，给软件设计、开发人员以及测试人员都带来了很大的压力。在这些压力之下，如何为客户提供满意、高质量的产品，已然成为我们必须不断思考、不断改进、不断完善的重大课题。

　　在多年的敏捷测试实践中，我逐渐摸索出一套实用而高效的测试技巧，即“心理学在敏捷测试中的应用”，通俗一点讲，就是“‘看人下菜碟儿’测试法”。

　　在测试每一个项目时，因每次迭代过程中的测试时间有限，测试人员不得不考虑如何制定出严密的测试计划和策略，以便在有限的时间内完成覆盖更多、更重要的测试点，为项目组和客户提供高效、高质量的服务，同时体现测试人员的价值。

　　在起初的工作中，我经常因为需要测试的功能点很多，而测试的时间又远远不足而烦恼（因为项目组人员较少，测试人员比例又非常低，每个测试人员需要负责的范围很大，甚至在曾经的一段时期内只有我一个测试员，同时“伺候”四个开发程序员）。为了解决这个烦恼，我就千方百计地想找到一个“讨巧”的办法来提高测试效率。

　　心随意动，从缺陷报告中我渐渐发现，造成缺陷的原因有很多种，而以下几点则为导致绝大多数缺陷的主要原因：

　　（1）需求本身就存在问题，而客户和我们都没有发现；

　　（2）需求设计人员对需求的理解和客户不一致；

　　（3）编码人员没有充分理解需求就开始编码；

　　（4）由于编码人员的粗心大意。

　　而（3）和（4）则为主要原因之重点原因。我决定，就从这两点入手，想方设法提高测试效率。经归纳可以看出，原因（3）和（4）是人为的因素占主导。再仔细揣摩，之所以在开发编码过程中出现这类问题，跟编码人员的性格和经历有着很大的关系。因此，我便根据所要测试模块的编码人员的个性特点，制定出一套具有针对性的个性化的测试执行策略。换句话就是说，对待不同的编码人员，我便持不同的测试重点，对症下药，“看人下菜碟儿”，去测试他们的代码：

　　1、对待粗心的编码人员

　　在执行测试这类编码人员的代码时，除了功能的大流程以外，测试重点应该放在功能的一些细节上，如：取值、赋值的数据类型；计算的边界值；参数的默认值；UI显示上的错别字，等等。

　　2、对待喜欢“投机取巧”的编码人员

　　代码复用是很正常的，也是很提倡的。合理地提高代码的复用性，会提高很多开发、维护效率。但是，不合理的复用就会造成系统缺陷。有些程序员在发现要开发的模块和某个已有的模块很相似的时候，会主观地想直接挪用已有代码，而看似相同的功能在不同的前提环境下，可能有不小的内在变化。如果这时这个程序员只是直接把已有的代码简单复制过来，忽略了那些细小的差异，比如：参数的默认值，取值范围，输出格式等等，这就会造成缺陷，有时甚至是一些隐藏的缺陷。对待这样的“懒人”，我们就得像对待“粗心的朋友”一样，格外注重细节。

　　3、对待有主见的编码人员

　　对待此类编码人员，测试人员就要十分注意他对需求的理解问题，因为这类编码人员可能经历过很多项目，在这个过程中难免就会形成一些思维定式，而这类人员又十分有主见（有时是固执）。所以，其很有可能会对当前的需求有更多自己的臆想，而这些臆想往往极有可能偏离客户的需求。测试这样的代码，尤其是涉及系统的新功能时，就要重点查看功能主线流程是否符合客户需求。因为有时他们在开发过程中，从需求出发点就跟客户有偏差。可以想象，从一个不正确的点出发，就可能在后续的开发中造成“差之毫厘，谬以千里”的谬误。此时，即使代码的算法再精妙，关键点处理得再完美，而它本身已经不是客户原来想要的那个东西了。