今天，办公室的测试小妹热泪盈眶的讲："世间最遥远的距离，不是生与死，不是天各一方，也不是我就站在你面前，你却不知道我爱你，而是在第十轮测试报告入库的路上，你却告诉我发生了第十一轮需求变更，尤其是这个项目还不支持自动化测试！"讲完这段话，她悲壮的走向了第十一轮测试！
作为一个过来人，讲真，我满怀同情，但更多的是想说："小妹，现在流的泪，都是当初做测试需求分析时遗漏的水！"小妹负责的项目在短短两个月内进行了十几次的需求变更，要知道，该项目的定位是需求稳定型项目，按照套路来，迭代发生概率不大。那么，这样一个稳定型项目，为什么它的需求却充满了不稳定性呢？
原因有两点：一、这个项目的项目经理刚刚从其他项目组转过来，对项目的前世今生以及未来都理解不透彻，制定了一个残缺的需求规格说明；二、测试小妹严格遵守公司相关规章制度，以规格说明作为唯一需求源，继承产生了一个残缺的测试需求分析结果。最终导致陷入了不断加／变更需求的坑！
抛开项目经理的问题，作为测试人员，最根本的问题在于测试需求分析严重不充分。也许在未来的测试生涯中，小妹会懂得：以男性思维去获取测试需求，以女性思维设计测试用例！
一、男性思维偏于理性，女性思维偏于感性。对于软件测试来讲，理性，感性分别意味着理性认识和感性认识，也就是说，根据理性认识来进行测试需求分析，根据感性认识进行测试用例设计！
引用一段名词解释，感性认识：指客观事物直接作用于人的感觉器官而产生的，它反映的是事物的具体特征和外部联系，具有直接性和形象性的特点，是对事物现象的认识。而理性认识是对感性认识材料的抽象和概括，它具有间接性和抽象性的特点，反映的是事物的本质。
看完两者的定义，想必是恍然大悟吧，没错，测试需求分析过程需要对产品功能、性能、可靠性等等特性的测试点进行抽象和概括，而测试用例设计的过程实际上是对测试执行过程的预演，是对测试用例的具体特性和外部联系进行直接形象的描述。
二、男性思维偏于看整体，女性思维偏于看细节。作为一名测试需求分析人员，在进行测试需求分析的过程中，你需要站立于高山之颠（整个产品体系之上），来分析你的测试需求，只有从项目整体去看，才能更全面、精准的把握用户需求，如果在测试需求分析阶段，以女性思维去纠结更多细节，那么，后果就是，细节很完美，需求却总有遗漏，进入日复一日迭代的死循环！
而在测试用例设计阶段则刚好相反，我们需要更多的把握细节，不应该大而化之的去设计测试用例，需要针对已有测试需求点的每一个细节，设计详尽的测试用例，并对测试用例的输入输出、前置条件、运行环境等细节作出清晰准确的描述，确保测试用例的可用性、准确性以及测试需求的覆盖率！
三、男性思维相对受情绪影响要少，而女性思维情绪化相对较明显。这一差异说的是什么，相信大家都深有体会，那么在软件测试过程中，该如何利用这种差异呢？
同样，在测试需求分析过程中，我们应当尽量的采用男性思维特征，即减少"情绪"的影响（注意：这里说的情绪不是指喜怒哀乐，而是指测试人员的个人观点），也就是说，在测试需求分析时，应尽量实事求是，通过行业标准、需求规格说明、用户访谈、竞争对手现状等真实存在的具体的需求作为依据，进行分析。应尽量克服"情绪化"，不要将未经确认的测试人员个人的猜测、想象等擅自加入测试需求，这将有可能导致测试需求分析结果错误。
而在测试用例设计时，则可以较多采用女性思维方式，尽可能的去怀疑、猜测，通过这种"情绪化"的方式来设计测试用例，有利于更多的暴露软件问题！
最后，我想说，开头那个测试小妹就是我……曾走过的弯路，愿未来不再重复！
出自《51测试天地》原创测试文章系列（四十五）
