1.问题描述
测试Solarinfo Moni APP过程中，有一次储能逆变器连接的电表硬件损坏，逆变器发出514故障告警，此时使用Moni iOS版监控逆变器数据中馈网功率和负载功率显示“--”，但用Moni Android版监控发现馈网功率和负载功率显示“0W”,很明显两个版本APP数据显示不一致。
2.解决分析过程
两个版本APP数据显示不一致？那么是哪个错了呢？当时我第一反应是iOS版显示不正确，按照之前需求约定，只有当连续多次数据获取失败时，才显示“--”。
但后来替换了电表，解除了514故障，我再次重现馈网功率和负载功率为0W的场景，而这时iOS版可以正确显示为0W。我找到需求负责人描述了这些情况，需求负责人却给了我一个惊人的答案：当逆变器发生514电表通信异常故障时，馈网功率因为无法获取到准确的数值，故让APP加了特殊处理显示为“--”，需求变更了！
这个答案才让我弄明白“两个版本APP数据显示不一致”，问题是出在Android版，没有依照最新需求修改代码逻辑。假如没有偶然遇到电表硬件故障，我可能直到测试结束，也不会发现这个问题，因为针对故障的测试已经结束。类似这种需求变更，测试人员最后知情的情况并不鲜见。
在测试过程中需求变更，是每一个项目都极有可能会碰到的问题。那么需求变更了，我们怎么办？我想在需求人员的思想里增加一个触发器，一旦需求有任何变动，第一时间触发事件“通知测试工程师”，但是这种触发器并不存在。
3.结论与经验
需求变更不可避免，而变更又可能会影响到整个项目的范围、时间、质量和成本等多个要素，若再出现“需求变更测试人员不知情或最后知情”，便可能会导致项目范围混乱、进度失控、质量不过关等严重后果，所以慎重应对“需求变更”尤为重要。根据行业经验，我想有以下几点可以改进：
一、需求人员做出的任意一项需求变更必须形成文本传送,比如填写变更记录单，杜绝电话或口头沟通。需求人员杜绝和开发人员私自沟通，所有沟通都应加上测试人员。
二、开发人员每次提交待测试版本时，必须填写版本说明，包含：本次新增功能、修改功能、修复的缺陷，以及修改影响的范围等。
三、测试人员多与需求人员沟通和确认需求点，在获悉需求变更时，应尽多了解需求变更的缘由，了解客户的真正需求，从测试的角度评估变更的合理性和完备性。再向开发人员了解变更影响范围，及时调整测试方法和测试用例，评估变更风险，确定回归测试范围。
最后不断总结每个项目情况，进一步优化变更流程和相关文档，并在以后新项目分析和设计初期借鉴这些总结经验，从而减少项目中后期的变更并尽早控制和降低变更风险。
频繁变动的原因1：
需求是源头，项目变动的原因就是需求不明确，又或者是需求改动频繁，那为什么会出现这样的问题？
出现这样的问题大多都是开发人员对需求把控不够，刚开始计划是只改动一点点，也有可能是觉得自己的代码不改，兄弟方修改就行，后面等到测试过程中，测试人员提出BUG，发现需要修改代码，而且修改的范围还很大。
讨论方案：
其实出现这样的问题本质上来说是因为没有遵循测试应该尽早介入的原则。
应对之策：测试人员在接到项目时，先不急于开展测试工作，可以先与相对应的需求人员和开发人员沟通，可以从先从业务流程方面与需求人员、开发人员沟通，同时知晓开发人员修改思路，代码设计结构等
但这个方法对测试人员要求极高，需要测试人员熟悉业务、熟悉场景设计、业务流程等，同时还需求测试人员对代码有一定的了解，如果讨论之前就知道整个代码的设计框架会特别有帮助。
恕我直言，上述这种讨论方案是没有什么可执行性的，属于白讨论了。
如果你能力够，那频繁改动代码带来的加班，你就不会遇到了。
如果你能力不够，那能达到上面这种“要求极高”的程度，在客观上就是不可能的，主观上是没有必要的。
对2的解释：
开发量的评估是开发的活，测试没有精力又当爹又当妈，又看开发代码又精通业务又写测试用例。这不是要求极高的事情，这是不合理的事情。你又看代码又懂业务又写测试用例，那你拿开发 产品经理 测试的工资吗？你这不是高标准要求自己，你这属于吃力不讨好甚至就是浪费时间。
开发觉得你越权，我的代码为什么需要你review，再说开发的代码谁给你的权限去看的？再说好几个开发的代码你一个人看，你干了TL的活，那TL对你能有好眼色吗，你拿TL的工资吗？一直发现实锤问题还好说明你伟光大，如果一旦你误报错误，威信会直线下降，开发一句“我除了正常开发还得给你个测试讲代码，你理解的还不对，你们测试真的没事干了吗？”是啊，你个测试不误正业啊。人家给你讲代码属于帮你学习，而你测试的工作是挑代码毛病指导开发改正，你这不是矛盾了吗？再说开发的代码那么简单吗？吃力不讨好。
产品经理觉得你在搞笑。产品经理从销售运营等拿过来的需求，和人家都认真讨论完了，然后你给挑毛病，不是扯呢吗？你和销售运营聊过了？你了解需求来源吗就开喷，还提意见，人家可能听你的吗？你知道这个按钮是干嘛的吗就喷？还是那句，你属于和产品经理学习的，然后你给挑毛病，矛盾啊！
说到架构就更不可能了，现在互联网技术架构其实就那么几个，开发的就那么几个，你说要改，那你考虑到成本了吗？你拿架构师的钱了？
我认为的应对之策： 做自动化测试用例，宗旨是测试做好测试的分内之事。
首先系统是可以分层的，一般是接口测试（黑盒/白盒）——功能测试。而这两类都可以做自动化。
接口测试的自动化做好了，分享给开发，开发拿过去就自测了，省了你一大堆时间，版本发布之前就能暴露一堆一堆的问题，包括边界问题。就算是他没有自测，你的测试也会节省很多时间，加班就他自己加了，他拿着你的用例就可以自己搞了。
功能测试的自动化一般是比较扯的，尤其牵扯到APP的自动化。这也就是说测试人员学python的源动力，会python才能写好这部分自动化测试用例。多数是不如手指点点点的。测试自身对代码的学习应该从这里开始，而不是从看开发的代码开始。
频繁变动的原因2：
因为是紧急上线的项目，测试时间都很短，那么测试人员需要把大量的时间花测试功能上面，而不是将时间浪费在环境上面。
在项目中遇到这样一种情况：
当开发人员转测的当天，测试人员和开发人员当天都会花费很多时间在调试环境上面。测试环境和开发环境是相对独立的环境，这也导致了有些配置不同的地方，开发人员在转测邮件中需要明确列清本次项目需要修改的配置，那么测试人员在配置环境的时候才能配置完善。
如果前面都做很好，那可以避免环境的bug，但由于某些原因，测试人员在测试过程中还是会遇到一些环境bug。
测试人员在测试过程中遇到BUG时，
第一，先去看BUG日志；
第二，根据BUG日志定位BUG错误的原因，是环境问题还是编码问题，又或者其它问题；
第三，根据分析的结果，能解决的问题尽量自己解决，比如是操作不当某个配置未配；
第四，如果是编码问题，则反馈给开发人员，提交bug，如果测试人员能定位出是什么原因的导致的更好
讨论方案：
在这里并不提倡遇到某些bug，测试人员不懂，但使劲钻研，这样反而会影响效率，主要是解决环境类，接口类，因配置或操作而引起的非bug问题。
同时不提倡测试人中一遇到bug不看不管，直接扔给开发人员解决，建议看bug日志，分析bug出现的原因，以便下次遇到类似bug。
这里没啥大问题，环境是运维 开发的事，再向后才是测试的事，当然测试环境测试需要负责也没啥说的。
建议还是在测试之前就写自动化用例，到时候手指点一点就OK了。
如果总出现比较大的环境崩溃问题，建议专门写一套通用的自动化验证环境用例，每次部署环境之后就执行一遍，也可以交给开发共用，这样又省去了浪费测试的时间。
bug日志测试是一定要看的，这对开发测试都有好处，遇到一些比较明显的脑残异常，及时指出，几次之后开发自己就看了，毕竟影响他绩效，几次不说，开发还会感谢你。
