这里我不想讨论需求为什么变化那么快，为什么会允许这样随意地变更。因为许多公司的现状就是如此，让他们形成配置管理的意识，不是一天两天能解决的事。或者有些企业，虽然知道配置管理的重要性，但是真正到了要落实的时候，就把原本订的配置管理流程束之高阁了。
在需求变化频繁的情况下，作为测试人员，最重要的就是要搞清楚以下几点：
1.哪些需求发生了变化
2.这些需求变化后，对测试工作会产生哪些影响。包括会不会影响测试用例，如果影响，会对哪些用例产生影响。当发生较大改动时，还要明确是不是影响到了测试方案，甚至是测试计划？
3.明确这些变化，会对自己的工作进度产生多大的影响。当发现自己的大部分用例都受到影响，需要修改时，应该第一时间向上级反映情况。由他定夺解决方案，而不是自作主张，或是一声不响。
关于如何确定哪些需求发生了变化，最好的工具当然是需求跟踪矩阵了。需求跟踪矩阵是从开发和测试两条线，同时进行跟踪的。但是，要实现需求跟踪矩阵，可不是容易的事情。尤其对于需求变化频繁的公司来说，基本可以断定他们是没有配置管理的。那么需求跟踪矩阵就根本没有实现的可能。但是，公司没有，不代表我们自己没有。
公司的测试任务分配，一般都是按照子系统或者是模块来分的。比如TesterA测试子系统A，TesterB测试子系统B。那么这时，我们完全可以只针对自己测试的子系统，完成需求跟踪矩阵。我们只需要自己维护测试线的需求跟踪，至于开发线，那可是管不着了。但是这里还是有点问题。我们一般理解的需求跟踪矩阵，是将SRS分成子SRS，然后针对每个子SRS，建立跟踪关系。但是忽略了各个子SRS之间的关联关系。要想把各个子SRS划分得没有一点联系，那是不太可能得。如果有两个子SRS，称为SRS1和SRS2，你测试的是SRS1相关模块，而SRS2相关模块是别人测的。当SRS1相关开发人员告诉你需求已变更后，你分析后得知影响到了SRS2，那么你必须和测试SRS2相关模块的测试人员及时沟通。你能保证做到这点，但是对方未必会在SRS2发生变化时，及时通知你SRS1受影响的部分。这时你需要事先和测试组的其他人员充分沟通，让他们及时通知可能会影响到你的变更。如果他们不及时通知，你就完全有推卸责任的理由了。对于开发人员也是一样，他们擅自改了程序，不通知变更SRS，或者不及时通知变更，你也完全有理由推卸责任了。
我们的目标肯定是要把测试工作做好，而不是自己没有责任就好了。当建立了自己的需求跟踪矩阵以后，就可以快速定位变更部分，而且目前企业没有配置管理的理念，所以可以及时变更你的用例，方案，甚至是计划。当发现受变更影响的部分非常多时，应该及时通知上级，让他们了解情况，并做出决策。
总结一下的：需求变化快，测试工作需要重新写用例，方案，甚至计划。这时遇到问题：
1.得不到及时通知
解决方案：没有办法，只能事先和开发人员以及测试组内部人员事前声明，不及时通知的部分，一概不付责任
2.不知道需求变化后，对哪些工作产生了影响
解决方案：公司没有配置管理，没有需求跟踪，那么就建立自己的小的需求跟踪。只跟踪测试线。把自己的工作做好，并及时通知其他受影响的测试人员。
3.发现自己大部分用例，方案，甚至计划要重新修改，而没有充足时间
解决方案：及时通知上级，让他给解决方案，而不是自己苦干。
文章来源于领测软件测试网 https://www.ltesting.net/
