mzhan017的博客

摘要：业务配置的refresh功能存在设计缺陷，导致备板切换主板时配置数据更新延迟，影响业务恢复。核心问题在于未及时初始化refresh操作的全局变量。该问题暴露了系统设计的不合理性，需优化refresh机制以避免配置同步延迟。

摘要：针对测试人员过度依赖开发人员指导的问题，文章指出测试应以客户文档和需求说明为主要依据，发挥主观能动性独立编写测试用例。即使产生较多无效工单，也应视为正常学习过程，不必过分自责。文中强调测试团队需建立独立思考的工作模式，减少对开发的依赖性。

这次断电，还发现一次，Openstack上配置的子网的网关失效的情况，重新删除添加网关恢复业务。这个时候可能就存在的一个问题，因为设备运行了几个月，或者一年多，有些配置上的修改，可能没有做持久化操作；而且有用时间过长，修改的人都忘记做记录。最近公司遇到一次物业周末断电整修的情况，跟着所有的实验设备都得断电。这个时候，重新上电，发现业务不通，或者有问题的概率就上来了。所以，一定要在做配置修改的那个时刻，做好配置持久化工作，以免断电之后出现重复的问题。所以断电对于实验设备来说，意味着，没有错，就是要断电重启。

产品安装的时候需要一个对外的IP/网络，是测试/设备人员通过Openstack提供的网络来建立的。但是感觉这个测试人员对网络的整体不是很了解，因为在中间在说这个IP安装的时候就设置上了，之前是好的，怎么现在不好了（按理说，来了这么多年，应该不至于不了解这个网络）。首先发现这个问题的是一个Sanity测试人员，然后开ticket到开发，我们就将问题推到设备管理人员那里，因为研发没有权限访问host主机的权限，而且这个网络不是开发负责建设，应该是设备网络设施的人来负责调查问题。这就是一个不求甚解的一个例子。

如果这么干，就完全的属于绕过（Workaround）方式，其实并不能保证一定会根本解决问题，因为问题的根本原因还没找到；所以不要着急上workaround，而是要抓住机会学习，并找到根本的原因。说安装完成之后，kibana的web访问不了，elasticsearch报timeout的链接错误。如果是一个爱学习的人，这就是一个非常好的学习机会。这个时候应该下载下来源代码，顺错误的信息，自己尝试着看一下代码，说不定问题就可以迎刃而解。也是一个非常好的入门开源世界的契机！就像社会上的很多问题一样一样的！

而且在之前，即使自己不认识，相应的不理解整句话，但是不影响我们忽略看到的信息，而且不会特意查字典）。所以，如果不进一步的学习新的信息/新的知识（相对于个人来说新），那就永远不能深入进去，也就是碰到类似情况的时候，或者和别人交流相关话题的时候，就有可能不知道如何作答别人的问题，同时又有天生的内向性格，最终的结果是显得有些“呆”！自从认识了这个单词，接下来的几天，突然发现在看资料的时候，就经常的碰到这个词，还庆幸自己上周刚学的，难不住我。但是当知道了这个新事物的意思之后，就会发现，之前自己很“呆瓜”。

其实这些指标都是在倒逼大家去主动学习/认真工作的工具。假如测试开出来的无效bug比较多，说明测试需要做专门的再培训。从广度/深度上，来增加测试对产品/测试的知识量。但是在人的灵活性方面来说，有时候，测试为了提高自己的有效bug量，会捂着问题不放，导致开出问题单的时间比较晚，开发进入也就晚，影响整个项目的进度。又比如层三层四，捂着问题不放，导致传递到研发的时间就晚，导致问题处理不及时，影响整个客户对公司及产品的印象。层三/层四也面临这样的kpi。开发的是，要求bug量少！测试的是，有效bug量多！

不得不说这个jira做的是很成功，很多开源产品在使用。

所以遇到问题，分析原因改善流程的过程，才是一个好的反馈过程。就是需要总结方法，关于这个问题，我想到的方法就是为每个讲解器进行编号，贴上标签，然后再按照家庭单位分发，然后才能体现清晰的设备管理，与责任，应该可以帮助解决此类问题。最近去旅游，是团体游，因为大多是文物古迹，需要导游给讲解，如果是外放，可能影响其他游人，所以使用了一种蓝牙无线的讲解器，每人一个。现在看，根据当时的讲解器的分发管理流程，丢失是不可避免。所以当下一次，我们发现这样类似的情况的时候，要及时的提出自己的建议，让此类丢的可能性减小到最低！

而这名同事这几天一直没有仔细的查看这个字符串的实际内容，仍然按照没有回车符的字符串去验证功能。在问题调试的过程中，还发现一个ksh的问题，调用strdup的时候传递一个0进来，当然会发生coredump。发现了这个问题的根本，是调用perl语言获取一个字符串的时候多了一个回车，没有做strip，导致后续的错误。然后从github上看，这个问题已经解决了，但是没有在实际的产品里引入fix，这个让人比较失望。人无完人，每天做事肯定有做错的事情，但是怎么自己反省，然后跳出怪圈，才是解决问题的思路。

最近产品出现好多问题，需要分析，总结发现这个回归测试的测试集很不完备；由于产品的持久性实在是太久，到目前为止已经有二十多年的历史，在整个开发的过程中，已经欠下了很大的回归测试债务，或者是当时的测试环境受限；如果这样推理过来，其实和现实的社会的演变也是一模一样，如果测试完备，哪里可能出现问题，这样就不会显示出来什么乱世，也就无所谓英雄，三侠五义；所以和平年代的稳定，其实是要归功于回归测试/测试的完备，也就是质量的反复确认人员；少了回归测试，问题就不免暴露在外，而且出现的概率也是随着开发量的增大而增大！

如果哪一天我进化出来听键盘就能识别字母的能力，那这个就会刚才那个ATT问题一样的情况了，非常的勾引人的注意力！但后来发现，只能听一半的问题描述，因为只有当前这个旁边同事的话到了我耳朵里，其他线上与会的参与者不在这里，就听不到。目前的现状是：由于MS-teams的应用，在家办公的普及，以及会议室的紧缺，导致很多会议是在线上进行；综合下来的最终结果是会议比较多，尤其是周一二，而且大都是线上进行。声音这个东西，对于自己发出的，自己肯定不会认为是噪音，但是对于旁边的人来说，就不一定了，有可能打扰到别人的思路。

这就和标题对应上了，因为如果是一名新手刚入门产品测试，和研发的交际就少，没有形成类似开发的定式思维，所以会东一锤头，西一榔头的拿着产品做实验，多多少少的就涵盖了，由于之前开发和老测试人员定式思维所不能覆盖的区域。在之前的工作经历中，不止一次发现这个规律：新手测试人员，刚上手的时候，总是能找到成熟产品（经过好几轮测试）的几个问题，货真价实的问题。怎么想起来这个规律了呢？从这里也可以看出来，测试人员的测试在征求其他人的建议，这里要说明，征求建议可以，但是不能完全的依赖这个建议，尤其是和研发比较近的人的建议。

从之前的观察来看，设备供应商的研发作为甲方给乙方开问题单的时候，有一个规律，就是如果自己经过很长时间的调试找到一个乙方问题，而且得到了乙方的承认。有可能接下来的很短时间内甲方研发，会提另外一个问题，而第二个提出的问题单，一般都不是真正的问题，而被标记位invalid。有没有可能是在发现第一个问题之后，经过很长时间的调试，增加了自己对乙方系统有了深入了解，而且第一个问题的确认让自己的信心大增，同时还可能误导自己认为乙方的质量欠缺可能很大，导致后续的代码阅读的时候，稍有感觉异常，就会认为是个问题。

如果一个简单的网络问题，被来来回回的耽误个把月，又是工单，又是拉人，又是各种催单。因为和甲方沟通的就是这些技术员，也就是对甲方的外在表现。像上面这个问题，就非常的典型，在十几年的工作经验里，出现过很多次。更典型的是，甲方一般是不会将具体的根本原因以及解决方法分享给乙方。而且这算不算是机密事情，也未可知。最近遇到一个客户现场网络的问题，其实很可以说明现场支持的水平。即使有不懂的地方或者未知领域，就探索的劲头这一方面来说，还是有一些欠缺。乙方很难有勇气说，“我的印象我自己说了算，不管好坏，甲方你必须得认可”！

从我的理解，关于总结的工作，有时候也不能完全依赖于员工自觉的去做，而是要给其一定的时间来做，要以摊派的形式给特定员工来做总结性的工作。最近听一个测试同事分享关于VMware的知识，最后被问到：你们测试中遇到的单纯的VMware的问题多不多，这名同事虽然回答了，但是感觉好像也没有回答，或者说没有回答到点上。其实提问的人想得到的是一个关于VMware问题的总结性的数据。因为自由的环境里，作为一个完整的团体，而且都是高智慧生命体，不是说体重二百斤的话语权会更重，话语权更重的是拿数据与事实做为依据。

当一名好的测试，在遇到问题时，第一时间的应对步骤是：开个bug/ticket，或者主动分析一下，而不应该重装系统/重启系统等操作来尝试恢复。有时候测试开出问题之后，可能以问题描述作为问题分析的起始点，这样就有可能导致遗漏系统警告信息，因为测试可能没有注意到警告，在问题描述力没有提及。从各方的设想，管理人员，开发，周围同事，还是需要一些debug问题的能力，即使不是那面强烈的能力，也需要基本分析能力（有助于增加自己的reputation）。既然是问题，如果可以正向解决是最好不过，即使是测试环境问题。

oops，还有人在这个bugzilla 打广告。后续这个问题被标注为spam，再后来就看不到了。这个算是不要reputation了。也算是兵以诈立的实现方式。当然这种方式实在是不可取。

不经常见的开源项目，第一次接触。

就说需要有一个容忍度，如果超出容忍度，我们就要去做反馈，去纠错，修正。

关于办公楼的选择及装修建设，也许不算做是项目管理的范畴；但是如果地段选择，装修不合理，肯定会有稍许的影响。这里总结最近碰到的一些经验；

所以有时候现场维护、支持的管理者会希望从研发拉人过来做支持：一方面是能力会好一些，另一方面关键是对系统熟悉。但是我倒是觉着，现场维护也没有必要从研发拉人，当然能拉过来是非常好的。只要有人，就疯狂的做操作，模拟客户的各种操作，有的没的，将软件作为一个沙袋。只要有不顺心于维护的易操作性问题，多提意见，而且要将意见的优先级提至最高。原因是处理问题时，一定要先找到真正的原因之后，再去做补救操作。原因是只有找到真正的原因之后才能避免：由于问题不清，而后又执行了不必要或者错误的变通方法，导致环境进一步恶化的情况。

当客户现场出现问题的时候，尤其是升级换版的时候，面临的压力很大。压力之下的操作是会变形的，所以不能完全依赖于现场的熟练操作，反而是要求软件高高的自主维护性、可靠性、鲁棒性上。因为来来回回次数变多的同时，出现错误的机率几何增长。如果当我们开始抱怨现场维护工程师对于vi的操作不熟练的时候，可能要反思的一个问题是：为什么需要要让现场工程师做vi操作？不应该是简简单单的一条命令就完成的操作吗？是否要将软件的这种易操作性、稳定性作为一个高优先级的任务来定制呢？不要让软件的难操作，不稳定性成为客户对软件的第一印象。

如果一个软件，从客户，系统测试，现场支持过来的问题中，如果无效问题/配置问题，占的比重过大。问题总结分析，也是是项目管理的一个重要环节。可以在问题总结时，发现目前项目，软件存在的问题，及时应对。对于以上几点，都需要做后续改进。避免无效，配置，噪音问题。因为会占用研发额外的经历去处理。

反馈在各行各业都是重点

这里分享一下日常工作中碰到一些协作相关的经验。团队之间的协作也是必不可少的一项管理内容。但是如何更好的实现团队之间的协作呢？从问题处理的角度出发，考虑协作，问题跟踪的完整性是必不可少的。可以跟踪问题的系统是Jira或者Bugzilla（问题跟踪系统）；

项目管理：版本未能准时发布

技术经验分享的重要性

客户问题处理方法

选对人与积极性的矛盾

git 使用总结

文章目录宏定义里是两个变量组合宏定义里是两个变量组合例如：#define GET_ID_STR 13, “not good” /// 这里的本意是一个宏可以得到两个参数。printf(“id =%d, str=%s\n”,GET_ID_STR);如果后人再用这个GET_ID_STR时一定要小心（怎么才能让他小心呢？），不然可能会写出：printf(“id =%d\n”,GET_ID_STR);建议分开来写；一件事情是一件事情。......

全栈，无边界工作

好习惯

如果根据部门一年来所做的事情为背景，来设置猜数游戏，是一个不错的选择；例如：本部门过去一年新增客户数是多少？但是在选择谁来回答时，要确保完全的公平性，非常困难，但是也要做到大体公平。例如通过抢红包的顺序做答题顺序，很可能导致回答者来来回回就那几个人，原因是，每个人使用的手机性能不一样，运营商也不一样，导致抢到红包的就那么几个人。最好的方式有轮询。...

最近项目组外出集体活动，吃自助，之后多人上吐下泻。食物中毒。我们要追问到底。找到RCA。作为程序员，天天被人追问RCA。终于逮到一次自己作为当事人，有权追问RCA时，一定不能手软。从追问人的角度考虑，准问RCA是一件让人兴奋的事情。...

如果产品已经上线很长时间，很稳定，多个用户使用。其中一个客户要一个增强功能，而其他用户没有这种需求。

说老板们给了某同事两件不甚关联的活，分在两个团队里，一半的时间干A工作，另一半时间干B工作。问，性能损耗是多少？如果可以用同样的工资，是否可以换两个便宜点的人，来做？