目前开发人员对测试人员的工作有一些不太理解：用户不可能进行的操作，测试人员非要进行操作，甚至找出一些开发人员都没有想到的操作；有时还设计一些用户没有的流程进行测试；还有时提出一些用户没有提出的要求，比如非要增加一个列表排序功能；测试组的数据库服务器本身就是一台PC机，配置不高，运行复杂程序比较慢，非要提出来要求修改。等等、等等。在开发任务不太忙的时候还能忍受，如果开发任务很紧的时候就容易发生摩擦了。
测试人员到底是怎么想的？怎么有时总是往牛角尖里钻呢？怎么总是让人搞不懂？后续章节里就简单的说说“测试人员的脑袋里到底在想什么呢？”
测试人员测试考虑问题基本有几个方面：
“测试人员的脑子里到底在想什么呢？”（一）
在一个项目中，测试人员与开发人员的良好合作往往起到事倍功半的作用。纵观一个成熟的项目，测试与开发都是紧密合作、相得益彰的。在软件行业说明举例中大家都习惯于用微软、IBM、HP等国际大企业来说明，也确实如此，这些大公司都是一些好的借鉴。好像有这么一个规律：凡是做的好的项目，测试与开发的合作也都是比较好的。而在国内一些企业里，由于软件工程发展相对晚一些，这方面的经验比较少，好多项目中测试人员和开发人员经常会发生一些摩擦、甚至冲突，一些有经验的管理人员、开发人员和测试人员还比较好一些，而经验较少的人员表现比较突出，如果再加上一些管理方面不够到位的话这种冲突就比较严重了，有的项目测试人员和开发人员甚至到了互相不能容忍的地步。这不是夸大其辞，确认经历过这样的公司和这样的人，往往是经验越丰富的人员对测试与开发的作用越理解的比较透彻。
追其原因，主要是因为测试和开发的工作内容虽然相同，但考虑问题的角度却各异。这样有时候站在这个角度看到的问题与另一个角度看到的问题是不相同的。有时这种不相同就会导致争议发生。如果双方都能够站在对方的角度考虑一下就会明白对方为什么要提出这样的问题。但是站在对方的角度来考虑不是说说就能明白的，有时非得亲身体验一回不可，否则还是有一些不理解。更何况对方是怎么想的、原则是什么都不一定能够说的很清楚。
往往会听到这样的评价：测试人员不知道怎么想的，总是做一些用户不可能进行的操作；我真服了测试人员，不是好好的测试功能，不知道都在想些什么，非要搞一大堆没用的数据录入；我看测试人员故意找茬，本来好好的功能非要钻牛角尖，找出几个没用的BUG来表现自己的水平。等等。
后续章节就测试人员考虑问题的思想因素做一说明，试图起到抛砖引玉的作用，供开发人员和测试人员来参考。文章中的描述或用词不妥之处也希望大家指出来我尽快更正，提前道谢了！
“测试人员的脑子里到底在想什么呢？”（二）
系统是否做了该做的事情？还有就是系统是否做了不该做的事情？
今天，在用户现场的测试人员打电话回来：“我们的系统出现了一个大的问题：通过前台界面修改一条记录没有成功，系统也很正确的进行了提示，可是后台系统却把修改信息发了出去，其他厂家开发的系统接收到消息后同时进行了响应的修改，并且把修改成功的信息发送回来了，可是我们的系统却没有成功修改，导致业务不能正常进行，这样的系统根本就不能放行。”
这个案例就是一个很好的说明。测试人员在测试的时候首先会考虑系统是否实现了预期的功能－前台界面修改记录不成功进行提醒，但同时还要考虑系统是否做了不该做的事情，在这个案例中就是既然没有修改成功，那就不应该发送消息给其他系统要求修改相关信息。
这种问题多发生在功能之间的接口或者是多个人开发的系统中。例如在航天史上有名的案例：美国发射火星探测器，整个研发过程都比较严密，但是最终登录失败了。问题的原因就在于系统出现了问题：火星着陆与着陆后出现不衔接。着陆后系统运行应该在着陆的数据基础上运行，而项目研发的时候着陆后的系统运行实在数据清空的基础上运行，根本就没有考虑到实际情况。
这种情况开发人员与测试人员容易发生争议的地方是：开发人员认为我做的系统或功能没有问题，我已经测试通过。有的还会说当初没有告诉我要这样做，或者是别人没有在我的基础上考虑，或者别人没有给我传送我需要的数据。这时如果项目组织不够好的话测试人员往往要协调多名开发人员或开发团队来解决问题，有如果不乐观的话会吃力不讨好，无人理睬。
“测试人员的脑子里到底在想什么呢？”（三）
不仅要进行合法性的测试，同时还要考虑非法的是否可以进行。
测试人员认为合法输入或流程等一定能够正常进行，同时非法的输入或者流程不能够进行，系统应该有所判断并有相关信息提示。为什么要有提示？不一定所有使用系统的人都知道哪些是非法的。
举个很简单的例子：数据录入的时候，如果没有进行非法检查，一些非法字符进入系统很可能会给以后造成很大的数据错误，比如一些保留字、特殊字符等等。例如在一个文本框中输入一个单引号（‘）成功的话，在数据库中有时执行一条SQL语句的时候会把单引号做为SQL命令而导致SQL脚本执行不成功或者录入错误数据。试想如果在远程紧急救护系统中把紧急抢救时间1分钟错误成10分钟后果会是什么？如果关键时刻系统出现崩溃会是什么后果？那就不是BUG了，是杀人！
这种情况开发人员往往会说：测试的都是些什么呀？不痛不痒。能不能发现一些重要的、深层的BUG呀？岂不是这个不中要的BUG如果把数据放行进入数据库，后面就会出现重要的、深层的BUG了。有时对这些BUG不置可否。
“测试人员的脑子里到底在想什么呢？”（四）
健壮性、稳定性
这是测试人员和开发人员最容易产生争议的问题。测试人员总是从各个角度进行测试，尤其是各个非法操作角度进行测试，测试人员想：不能因为用户的误操作导致系统出错或者崩溃，所以尽量考虑各种非常情况，有的情况开发人员都觉得有点变态了。下面是测试人员和开发人员的一段对话，从中可以看出一些不同点：
开发人员：“用户输入数据时怎么可能按住键盘不放呢？你这样按着不放能不出错吗？”
测试人员：“用户是不会故意按着键盘不放的，但是有可能不小心会用手或者书之类的东西压着键盘，如果发生这样的事情，我们的系统总不能崩溃吧？怎么着也应该给个提示或者警告一下。”
有时候用户是会发生错误的，人吗，误操作总是难免的，如果有了误操作系统就出一点小错，用户还能忍受，如果出打错或者崩溃，用户估计会有意见了。测试人员正式从这个方面进行考虑的。
易用性
一般经常与用户接触的人员会对易用性理解深刻，用户觉得操作繁琐会要求系统修改的，上帝不满意了你能不管吗？
测试人员说了：我操作都感到麻烦，用户会操作的舒服吗？
这是测试人员对待系统在易用性方面的心态。
比如测试人员说“在查询结果中增加一个排序功能或者模糊匹配功能吧，要不查出这么多的数据，要找用户要的那个数据太不容易了。”
“这个增加功能太慢了，我都等的有点不耐烦了！”
有时这些提示会被开发人员忽略掉的。
“测试人员的脑子里到底在想什么呢？”（五）
安全性
（略）
响应速度、容量、压力负载
“这个增加功能太慢了，我都等的有点不耐烦了！”如果测试人员觉得时间长，用户也会有这种感觉的，更何况到用户使用的时候数据量可能会更多，随着用户数据量的增加，速度还会下降的。有时测试人员提出有关速度等性能问题的时候就是基于这个思路提出来的。
尽可能多的发现BUG
测试人员的职责就是找BUG，尽可能多的发现BUG，不管BUG是严重的还是轻微的，都要提出来。如果有时系统相对稳定或者测试人员不熟悉系统的时候，会发现很多轻微的BUG，比如显示错字、位置不对等等，开发人员会认为这些问题都不是问题而轻视测试人员，从而造成矛盾。
提前、尽早、不断
测试人员的原则之一。提前发现问题有助于尽早的解决问题降低成本（时间、人力、金钱等成本），也有助于对系统有全盘的把握。
不断测试原则比较典型的矛盾是这样：
开发人员：“能不能一次测试完就告诉我有多少问题？总是没个完。”
要知道BUG是永远都存在的，不可能一下子发现全部问题的。
足够好的测试
测试不是无休止的，所以即使你想进行完全的测试是不可能的，这在好多教科书中都有介绍，再加上测试是有成本的，需要花费时间、金钱、人力资源等成本的，有时过多的测试对企业来说是亏本的，因此测试有一个结束时间。但是总不能在不该停止测试的时候停止，否则系统中包含很多问题怎么办？因此测试既不能过度，也不能过少，进行足够好的测试就可以了。
这怎么会有矛盾呢？可以看一看开发人员的这句话就明白了：“用户都发现问题了，测试人员怎么不测试了呢？害的我们费这么大劲去修改。”
管理方式（处理方式）
有的管理人员对测试认识比较深刻，只要是测试人员发现问题，就要求开发人员必须限期修改完成，而不是对问题进行分析、评估并根据开发人员的工作量进行适当的安排。这样有时开发人员容易与测试人员造成矛盾：这么简单的问题也要提出来，而且这么多小问题，我哪有时间去改那！测试人员也不高兴了，我没有错呀，我都把问题发现了，提前告诉你不是很好吗？要是到了用户那里岂不是麻烦了？我做了好事不但不感谢，反倒成了我的不是了。但是测试人员也不愿意得罪开发人员呀，所以有时矛盾发展结果就成了开发人员与测试人员私下里达成协议：不记录问题，与双方都有利。
争议处理流程
（略）
缺陷处理成本 环节少
（略）
本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/