Bug

1.现阶段bug根本分类性能逻辑，用户体验bug分类功能型bug，需要型bug，性能型bug，常识型bug2.bug产生程序在开发时考虑不周全导致程序在应用时不合乎用户习惯3.发现bug的办法等价类划分法，边界值分析法，谬误揣测法，因果图法4.实际中bug的排查（F12排查network bug）重现问题：首先，须要尝试重现用户报告的问题。这可能须要模仿用户的应用场景和环境，或者在特定的条件下触发bug。通过重现问题，能够更好地了解问题的体现和特色，为后续的剖析和定位打下基础。日志剖析：查看相干的日志文件是排查bug的重要伎俩。日志文件中通常蕴含了程序运行时的详细信息，如函数调用、变量值、错误信息等。通过剖析日志文件，能够理解程序在呈现问题时的运行状态，从而定位到可能的问题所在。代码审查：对可能引发问题的代码进行审查，查看是否存在逻辑谬误、语法错误、内存透露等问题。能够借助代码审查工具来进步审查的效率和准确性。5.软件测试工作的实质软件测试工作的实质能够概括为“测”和“试”两个方面。首先，“测”是指对软件的需要和设计文档、代码等进行检测，找出其中存在的缺点和问题。这个过程须要借助各种测试方法和工具，对软件的性能、性能、安全性等方面进行测试，以确保软件的品质和稳定性。通过测试，能够发现软件中的谬误和缺点，为开发人员提供反馈和倡议，帮忙他们改良和欠缺软件产品。其次，“试”是指在用户应用的软件环境、硬件环境和其余非凡状况下，尝试软件是否能够失常运行。这个过程须要模仿用户的应用场景和环境，对软件进行全面的测试，以确保软件在理论应用中可能失常运行，满足用户的需要和冀望。通过测试，能够发现软件在不同环境下的兼容性和稳定性问题，为开发人员提供改良的倡议和方向。6.HTTP状态信息码6.1 1xx：信息性状态码，示意接管的申请正在解决。例如，100示意持续解决申请，通常与分块传输编码一起应用。6.2 2xx：胜利状态码，示意申请已胜利被服务器接管、了解并解决。其中，200是最常见的状态码，示意申请胜利。6.3 3xx：重定向状态码，示意须要采取进一步的操作能力实现申请。例如，301示意永久性重定向，302示意临时性重定向。6.4 4xx：客户端谬误状态码，示意申请蕴含谬误或无奈被服务器了解。例如，400示意申请语法错误，401示意未受权（身份验证失败），403示意禁止拜访（权限问题），404示意资源未找到（URL不存在）。6.5 5xx：服务器谬误状态码，示意服务器在解决申请时产生了谬误。例如，500示意服务器外部谬误，502示意作为网关或代理的服务器从上游服务器收到了有效的响应。问题答复为什么须要进行软件测试？软件测试的目标在于发现并修复程序中的谬误，缩小用户在应用过程中遇到的各种谬误和异样，进步用户的满意度和粘性。同时，测试也能够通过竞品剖析和用户反馈，为软件的优化改良提供参考，推动其继续倒退。此外，软件测试还能够帮忙升高同类型产品开发遇到问题的危险，进步开发效率，加重测试代码保护工作，以及节俭资源其余软件开发模型1.疾速原型模型：这个模型强调了疾速构建软件原型并进行迭代，通过屡次迭代来不断完善软件产品。2.增量模型：这个模型将软件产品分解成小块，每次开发和测试一个模块或一组模块，逐渐构建残缺的软件。3.螺旋模型：这个模型将开发过程视为一系列的迭代，每个迭代都包含打算、危险剖析、工程和评估四个阶段。在测试过程中，如何进步沟通效率和改善沟通的效率？1.明确沟通指标：在开始沟通之前，明确沟通的目标和须要达成的指标，这有助于确保沟通的方向和重点。2.定期团队会议：定期举办团队会议，无论是面对面还是近程，这有助于团队成员之间的信息同步和问题探讨。3.建设沟通标准：制订沟通的最佳实际和标准，例如更新文档的工夫、提交缺点的格局、会议的议程等，以进步沟通的效率和清晰度。4.聆听和反馈：踊跃聆听别人的意见和倡议，并提供及时的反馈。这有助于确保信息的精确传递和了解。5.透明度和共享：放弃我的项目信息的透明度，及时共享测试后果、进度更新和危险信息，以便团队成员可能做出相应的决策。6.抵触解决：当呈现沟通阻碍或抵触时，及时采取措施解决，防止问题的扩充。测试计划工作的目标是什么？测试计划工作的内容都包含什么？其中哪些是最重要的软件开发过程中测试计划工作的目标是确保软件产品在交付给客户之前可能满足既定的需要和质量标准。测试计划工作的次要目标包含：1.风险管理：通过测试计划，能够辨认潜在的危险，并制订相应的缓解措施。2.资源分配：明确测试流动中所需的各种资源，如工夫、人力、硬件和软件等。3.测试范畴定义：明确须要进行测试的性能、性能以及其余非性能需要。4.测试策略制订：确定测试方法、测试类型、测试工具和测试数据等。5.进度布局：安顿测试流动的时间表，确保测试流动能按时实现。6.品质管制：确保软件产品达到预约的质量标准。测试计划工作的次要内容包含：1.引言：介绍测试计划的目标、背景、参考资料和定义。2.测试策略：形容测试范畴、办法、类型和工具。3.测试对象：具体阐明要测试的性能、性能和需要。4.测试资源：列出进行测试所需的硬件、软件、人员和估算。5.测试进度安顿：制订测试流动的时间表，包含次要测试阶段的开始和完结日期。6.危险评估：辨认潜在危险，并探讨应答策略。最重要的内容可能包含：1.测试范畴和策略：这决定了测试团队将关注哪些方面，以及如何进行测试。2.资源分配：确保有足够的人力和物力资源来反对测试流动。3.进度布局：正当的进度安顿能够确保测试流动不会延误。4.风险管理：提前辨认和布局可能的危险，能够缩小我的项目失败的可能性。

一、背景漏测Bug是指产品逻辑缺点在测试过程中没有被发现（尤其是测试环境能够重现的缺点），上线版本公布后或者在用户应用体验后发现并反馈回来的缺点。可能造成线上故障或者资损，在对产品测试过程中，本人也不免呈现一些Bug的漏测，因而对Bug漏测进行一些思考，并进行总结。 二、起因剖析Bug其实是任何利用产品都会有的一个问题，不是所有的Bug都能被发现，包含资深测试，或多或少的会呈现线上缺点，谁也不能把软件所有的性能操作、使用场景想周全。虽说不能做到齐全零缺点，然而每次公布的产品，咱们须要谋求缺点越来越少，产品质量越来越高，缩小线上问题的反馈。 为什么会呈现缺点漏测，次要有以下几点： 2.1  需要评审阶段，对业务需要细节了解不明确，设计存在不合理，未深刻开掘隐含拓展需要问题剖析在理论产品研发过程中，产品需要其实处于一个细化、优化、下钻过程中，在需要PRD文档交互文档输入进行评审时，未能把一些产品细节问题、隐含需要裸露进去，而测试用例的编写是基于PRD、交互文档以及本人对该需要教训了解所波及测试用例。 改良措施需要评审前，咱们应该先仔细阅读PRD及交互文档，先造成本人对产品的思考，通过脑图的形式列出对产品设计的疑难点,从用户或者从行业角度找出产品设计缺点点。需要评审会议中，带着列出的疑难点向产品、开发沟通本人对产品的纳闷和质疑点，多提几个为什么？如何实现？数据获取起源？超出预期的数据怎么解决？缓存解决机制如何？数据保留何处？逻辑由前端解决还是后端服务？后端服务逻辑是否跟第三方关联？需要评审实现后，依照肯定的性能，将需要拆分成若干大模块，大模块拆分成小性能点，而后思考性能点的具体实现流程，通过思维导图细分模块性能、从页面、交互、边界解决、接口逻辑、环境配置等维度进行梳理需要，尽可能开掘隐含可拓展需要点，而后进行一次测试组内需要评审和技术复盘，让合作成员一起补充隐含需要，使得产品设计缺点尽早且最大化地裸露进去。在前期技术评审时，探讨逻辑交互以及上下游数据走向和音讯发送流转，串联技术侧疑难点。2.2  测试用例笼罩不全面，场景呈现脱漏问题剖析在测试用例设计过程中，容易呈现思维受限或者需要盲区，咱们不可能齐全笼罩用户应用的所有场景，编写测试用例的时不可能把所有的场景都能想周全，把所有的场景下的状况都写成测试用例去模仿、去笼罩这也是不太事实的。 改良措施用例设计开始之前，列思维导图 通过思维导图列出业务流程，前、后端接口逻辑。而后依照PRD和交互文档，按照UI界面切分成大的功能块，而后在大功能块，而后在大功能块再切成小功能块，最初到性能点，每个性能点通过UI、基本功能、边界、内存、数据、交互、接口逻辑等维度发展用例设计导图，并列出需找产品、开发确认的疑点。 用例设计实现后组织用例评审 a. 组织开发、产品进行测试用例评审，并抛出用例设计时的疑难，通过产品实现角度、数据存储、用户、产品体验角度对用例进行评审欠缺补充。 b. 组织测试组内提前预审测试用例也是十分必须的，对于正式用例评审前会组内进行预审，在版本完结后组织全量用例汇合入也会进行串讲用例，特地是一些教训老道或者业务相熟的老司机们，能够在用例评审上疾速的帮忙指出用例的脱漏点，有助于测试人员关上思路，尽可能多的笼罩用户场景，值得注意的是用例评审上遇到不确定的，应立即记录下来作为待办项，完结后及时找相干人员确认，防止猜想不确定。 总结用户反馈、欠缺测试用例流程-下钻测试用例构建以有恃无恐 a. 产品测试公布上线后，对于用户反馈的缺点，如果缺点是因为场景设计不全引起的，咱们先剖析呈现问题的场景是必现还是偶现，如果是必现，咱们能够通过和技术同学沟通，确认该场景的一些具体复现步骤，确认引入起因，解决方案。 b. 对于线上如果呈现缺点须要对测试用例欠缺：除了补充该场景case外，思考一些和该场景相关联的场景，将多种场景下测试用例及时欠缺、评审，减少到用例库中去。 c. 针对线上缺点剖析其具体起因做复盘总结，关注线上问题反馈群，及时发现问题、定位问题、剖析起因，判断是否为老逻辑引入还是新性能引发问题，精准化补充对应的用例，针对特地场景补充接口自动化、防资损数据狗校验、全量用例汇合BVT用例。 2.3  测试阶段未严格依照测试用例执行问题剖析依照测试用例执行测试，能够让咱们尽可能的不呈现脱漏一些测试点。不能因为某一个人或者对某一块业务相熟简化其测试用例，不严格依照测试用例来执行测试，这样呈现了一些脱漏Bug切实是不应该。 改良措施测试用例不肯定能保障所有的场景和性能点都能笼罩到，然而严格依照测试用例执行测试，能最大水平上保障产品质量，尽量避免呈现缺点。养成测试纪录习惯：对于测试阻塞用例、测试Fail用例，应该重点关注并记录，在回归测试阶段进行精准回归测试，确保修复Bug导致关联性能引入的新Bug也能被发现。尽管测试流程很标准，然而软件品质还是不如意。 2.4  测试环境、测试资源受限，导致缺点漏测问题剖析对于现阶段得物的测试环境问题是及其简单的，业务零碎不是孤立存在的，关联方环环相扣，而且关联系统经常呈现不稳固的状况，另外波及身份证、银行卡等稀缺资源的应用无限，往往测试完一个无效数据废除一个无效数据，所以咱们能够尽可能通过mock、还原客户的理论环境问题。 事实毕竟不是实在的环境，因为环境的差别，可能呈现很多意想不到的问题，例如：配置问题、数据源问题、以及数据同步问题，这些都是可能只在个性的环境、特定的操作步骤下才会裸露进去，在咱们的测试环境还原不进去，只能基于预发环境或者生产环境来验证问题，导致品质可能呈现危险隐患。 改良措施1）引入灰度公布测试 测试组在预公布环境上进行回归测试，能根本模仿实在环境执行测试环境无奈测试的用例，又不影响线上用户的失常应用。 2）生产验证环节做好case筛选 首先进行生产验证case梳理，生产验证case除了筛选p0+p1级别case进行回归外，还应该蕴含测试环境mock or 挡板阻塞的测试case，以及后端接口对前端响应的case，在生产回归阶段严格依照生产验证case执行去笼罩实在线上环境场景。 3）增强后端以及关联方业务逻辑的理解 前端不仅须要理解前端与后端接口的交互业务逻辑，还需理解后端接口与其它关联方的接口交互逻辑，校验判断其给的接口数据是否正确，对测试环境测试用例的笼罩水平有整体的把控度，以确保生产环境的测试用例笼罩做到全面性。 2.5  开发人员引入的新Bug问题剖析有一些开发人员只会针对你所提交的Bug中问题的形容步骤解决，并不会去排查该问题有可能波及的所有点，有可能呈现解决了这个问题，而引入了一个新的问题。一个不相熟功能模块的开发人员来修复Bug，因为业务不相熟，考虑不周全导致有意识的引入新的Bug。 改良措施1）代码review 从代码治理层面：开发修复一个Bug提交代码自测通过筹备提测时，开发团队提交代码进行代码review，引入新Bug的可能性概率就会较小，升高危险存在。2）精准回归测试 从测试自我涵养层面：在开发提测后，理解代码改变点，精准剖析改变点对相关联的性能点的影响，将开发人员修复的Bug确认验证，并将相关联的性能点尽可能的遍历回归测试到3）找开发聊聊开发是如何修复这个性能* 跟开发聊实现很容易从开发的设计中你能够把握到测试的留神点，并记录体现在用例中。例如Ａ开发已经用某种形式做了B性能，呈现了某个Bug，当初B性能用了同样形式实现，那么极有可能之前的Bug还会呈现在C性能。4）覆盖率的实际和利用 减少开发冒烟执行代码覆盖率，依据覆盖率数据分析有那些冒烟用例未笼罩到，是办法未笼罩到、还是类未笼罩到或者是异样逻辑的校验未回归到，用开发自测和覆盖率的形式升高其新Bug的引入。2.6  探索性测试环节欠缺问题剖析咱们发现的很多Bug都不是按测试用例执行发现进去的，都是在测试过程中随便测试发现的，而这些步骤在测试用例中并未体现，咱们的测试用例不可能笼罩所有的场景。 改良措施1）准入测试通过后进行ET测试 在测试准入测试实现进入SIT测试阶段：一般来说，ET测试是最容易发现Bug的，所以在测试准入测试实现进入SIT测试阶段，先进行一轮探索性测试，使的大部分的Bug先在测试后期裸露进去，让Bug累计数量达到肯定的峰值，尽早发现Bug，品质越高。2）UAT 测试之前进行组内ET测试 SIT测试进入序幕，UAT测试之前组织一次组内ET测试，让组内不同的测试用不同的测试形式，测试思维，测试教训，测试习惯进行摸索测试，能发现一些因为思维定势局限起因导致漏测的Bug、诡异的Bug或者应用不合理的中央。3）精准化测试 精准测试的测试用例聚类分析性能，能够无效地发现“测试的谬误”。例如一个用例执行步骤谬误，它的聚类后果必然会发生变化，管理者通过系统分析的后果就能够发现并纠正这一类的谬误，而之前可能须要在现场回归重复的确认。精准测试的核心技术要点是测试用例与代码的追溯技术。这项技术简略来说就是当性能执行实现当前对应的整体代码执行状况就会立刻产生，即当点击一个测试用例，就立刻追踪到对应的代码和模块。精准测试测试破绽剖析性能，实用于麻利测试。它能够基于程序静态数据和动静运行数据，主动剖析软件缺陷最高危险的地位，疏导首先对于高风险的模块实现笼罩，在无限工夫内实现最具备危险的模块的笼罩测试。 三、对于开发角度侧思考3.1  自测背景开发人员做好自测，十分必要，也是大趋势。后期都是开发自测，前期才是用户体验方面的测试。从老本和工夫上剖析，Bug越晚发现修复老本越高；从批改的效率来讲，越早解决会越快。一个优良的开发者，自测的Bug肯定会多于测试发现的Bug，也就是轮到测试的时候Bug数量相当少。 3.2  疑难问题思考工夫和进度太紧张，排期紧凑。对本人代码过于自信，自认为有很强的健壮性，不忍心去批改。认为这是测试的责任，多度依赖测试。不知如何无效的做好自测，笼罩全面。开发冒烟测试对于QA创立指定的用例了解不透彻，执行简洁。3.3  思维转变代码品质、我的项目品质均是咱们的责任。测试和开发人员思考问题不同，开发是在制作软件，测试是在毁坏软件，想方法去找出问题。任何性能都有失常场景和异样场景，少数应用等价类和边界值去抉择数据，笼罩全面。不要置信任何开发的代码是无Bug。走出具体实现时用的开发思维，站在需要和用户的角度去自测是否通过，如果本人是用户去测试你的性能。3.4  不仔细认真自测带来的痛处和隐患需要脱漏：一旦被用户发现此问题，用户印象会大打折扣，可能间接从开始应用即放弃应用，将带来十分大的客户散失。性能事变：主流程性能没有测试到位，或者异样场景没有测试到位，导致线上频繁报错，体验极度不好，间接认为就是事变。需要延期上线：如果自测不充沛，测试花大量的工夫去沟通低等级bug，甚至主流程走不上来，这样无疑会给开发带来返工、反复测试、耗时、需要延期、我的项目延期等一系列问题。3.5  制订自测报告标准功能模块介绍及背景介绍性能、背景介绍应用用户群体介绍环境信息版本号Hosts、代码公布分支预发or正式功能设计文档以及UI设计图等数据库数据同步、环境配置、开关设定等梳理好的自测点编写代码时候记录的业务点和测试点需要变更的自测点正向、逆向、异样场景测试点兼容性开发此性能是否会对其余性能造成影响，一行代码是否会引发新的问题呈现自测理论后果：高等级Bug数量、影响冒烟外围流程中等级Bug数量、串联流程链路低等级Bug数量、页面展现UI成果开发冒烟自测阶段覆盖率一轮、集成阶段覆盖率冀望后果：合乎测试SOP规定准出规范冒烟自测以及集成阶段覆盖率规范测试阶段Bug数量的管制上线后Bug数量的管制，品质月复盘满足数量管制规范四、总结缺点漏测产生后咱们须要深入分析漏测的Bug，思考哪方面做的不够，是业务逻辑了解误差？用例评测脱漏？技术计划存在不合理？思考设计用例方向呈现了偏差？多问一些几个为什么，换位思考角度想问题，正当设计评测。确保相似的Bug能被预防提前发现裸露进去，从而尽可能的升高缺点的产生，进步产品质量。在每个不同阶段做好用例测试计划执行，减少精细化测试以及探索性测试环节，须要开辟新的测试思维思维，走出习用惯例的测试思维。同时也要站在开发侧、编写代码设计的思维逻辑去思考，升高可能在测试阶段呈现Bug漏测、脱漏的呈现，开发侧也需严格执行自测和覆盖率SOP要求准出。 *文 /Viki  要是感觉文章对你有帮忙的话，欢送评论转发点赞～

具体谬误 itech8deMacBook-Pro :: src/go_applet_health_spider/app ‹master› » go get code.baidu.com/map_backend/go_applet_health_spider/app/crawler# cd .; git clone https://code.baidu.com/map_backend/go_applet_health_spider.git /Users/itech8/data/app/my_app/go/src/code.baidu.com/map_backend/go_applet_health_spiderCloning into '/Users/itech8/data/app/my_app/go/src/code.baidu.com/map_backend/go_applet_health_spider'...fatal: could not read Username for 'https://code.baidu.com': terminal prompts disabledpackage code.baidu.com/map_backend/go_applet_health_spider/app/crawler: exit status 128起因go get disable "terminal prompt" by default（Go get 命令默认禁用terminal prompt，即终端提醒） 解决方案：环境设置GIT_TERMINAL_PROMPT=1 export GIT_TERMINAL_PROMPT=1go get XXX

1.体检业务 申请 档案服务器 提醒token 有效档案方服务器总是看不到体检方提交的增加档案申请的日志,体检方本人倒是能够看到申请日志谬误起因:体检方拷贝测试环境的镜像,在线上机器配置了测试环境的host,哎,无语啊 感悟:host 应该在申请方的机器上配置,例如本地host 2.上线侥幸抽奖流动提醒找不到数据库驱动, 查看是否真的没装mysql扩大？坑爹了，运维[[email protected] ~]# app/health/medical-care » php -m|grep mysqlmysqlimysqlndpdo_mysql 3.Curl 申请 原生curl 切记申请url 带上协定头 http或者https 4.vendor包文件缺失解决办法: vendor包放进版本库 包文件缺失的起因可能是:我的项目第一次 composer install之后,在composer.json增加require包之后,删除了vendor,然而没有删除composer.lock又用了composer install执行导致装置的时候执行了composer.lock文件下的包而已,并没有走composer.json 5.php代码,上线后没有看到成果？php opcache是否开启？重启php 6.日志文件权限是否赋予写入权限 7.新增机器后,业务配置文件是否存在？可思考分布式配置核心解决方案 8.数据库执行大批量查问操作时,页面提醒 504 timeout设置php和nginx配置参数仍旧不行后发现slb配置默认申请工夫是60s,改到最大值180s后胜利 9.阿里云音讯服务 mns 业务向topic里塞数据,测试环境失常,上线后,发现队列中始终没数据,问运维得悉,是权限问题 继续整顿。。。

问题形容：前端单页面利用，打包部署到测试环境后呈现白屏 零碎环境 macos m1pro 零碎版本12.0技术栈： umi+react+ant-design+qrcode.react排查过程【看报错】看控制台报错：无任何谬误，连任何waring和console.log也没有【看dom构造】看dom构造，失常加载【看资源加载】看network资源加载状况：资源加载失常，无任何报错【排除浏览器插件问题和缓存问题】应用chrome暗藏模式（无其余插件），分明chrome缓存，换其余浏览器（safari）也有效【排除我的项目打包问题】拜访这个我的项目的其余路由失常【排除电脑问题】页面在其余共事电脑上关上失常(一样的chrome版本)解决方案重启电脑，最好搞定了这是个十分奇葩的问题，前端问题，最初竟然依附重启电脑好了。有晓得的欢送留言

上周只上了三天班，但我也丝毫不敢懈怠，BUG 更是一个也没少写。 看着满屏幕的 ERROR，我陷入深思。为什么我写的代如此烂，无奈像大牛们写的那般优雅？ 越想越自大，越想越抑郁。我感觉这样不行，肯定得振作起来。 正如一位愚人已经说过： 世间万事万物，都是有两面性的：有它光明的一面，也就有他明朗的一面；有它踊跃的一面就有他消极的一面；有他好的一面也有它坏的一面。我的代码尽管不够优雅，但写的 BUG 还能比他人差吗？ 而后我在网上搜了一下，没错，BUG 也比他人差。 软件开发历史上有哪些驰名的 BUG 呢？明天咱们就来好好聊一聊，涨涨奇怪的知识点。 第一个 BUG 上图中有一只飞蛾被贴在了一张纸上，这可不是某个人的非凡喜好，而是计算机的第一个 bug。 它导致了哈佛 Mark II 计算机中的继电器短路。Grace Murray Hopper 找到了它，并把它放在了日志中。 如果没有这个 bug，咱们可能对计算机中的谬误就有不同的说法了。 这可能是最驰名的计算机谬误了。 500 英里外的邮件一位国外做邮件服务的管理员，有用户向他埋怨说：他们不能发送超过 500 英里间隔的电子邮件。 这不是扯淡吗？这可是互联网业务，怎么还跟理论间隔无关了。 管理员一听也是一脸懵逼，基本不置信。依据程序员法令即可推理：原来还好好的呢。 有一位用户还特意做了一张邮件发送失败的地图。地图上显式，邮件的送达区域半径比 500 英里就多那么一点点：半径内的收件人，全收到了，之外的，全失败了。 看来是真的有这个问题，还是得排查啊。到底是怎么回事呢？ 原来是一次软件降级导致近程服务器超时工夫被设为 0。在一个具备典型负载的特定机器上，零超时意味着如果连接时间略微超过 3 毫秒，服务器就会终止连贯。 而以光速流传的电信号，在 3 毫秒的工夫内所能达到的间隔大概是： 0.003 * c (光速) = 558.84719 miles星期三解体的零碎一家医院用来监控病人衰弱的数据库，每到周三，会本人解体。 我就不一样了，我是周一到周四都会解体。只有周五状态失常，因为马上就要修周末了。 说回这个零碎，该零碎记录日志是用 C 格调的代码编写的，把日志字符串记录到了一个固定长度的缓冲区中，其中日志工夫一栏，格局例如「Monday, July 17, 1997, 10:38:47.123」。 看到这是不是有点灵感了，必定是跟工夫有关系，让咱们把信息再明确一下： 星期长度Sunday6Monday6Tuesday7Wednesday9Thursday8Friday6Saturday8这样的话就清晰了，起因就是周三的字符串长度更长，在这一天，缓冲区恰好溢出了。 这 BUG，还真的就是这么奇妙。 《江南 Style》爆表这个 BUG 可能很多同学都晓得，也就是几年前的事件。 ...

1、测试人员提交新的Bug入库，谬误状态为New。 2、高级测试人员验证谬误，如果确认是谬误，调配给相应的开发人员，设置状态为Open。如果不是谬误，则回绝，设置为Declined(回绝)状态。 3、开发人员查问状态为Open的Bug，如果不是谬误，则置状态为Declined；如果是Bug则修复并置状态为Fixed。不能解决的Bug，要留下文字说明及放弃Bug治理为Open状态。对于不能解决和延期解决的Bug，不能由开发人员本人决定，个别要通过某种会议（评审会）通过能力认可。 4、测试人员查问状态为Fixed的Bug，而后验证Bug是否已解决，如解决置Bug的状态为Closed，如没有解决置状态为Reopen。 举荐浏览： 软件测试时怎么找到更多的bug 测试人员定位bug的根本要求 线上解决bug的个别流程 软件测试中如何疾速发现Bug？分享8条测试准则 测试工作中八成会遇到的一些软件测试治理问题

谬误形容： 用 postman 测试接口 GET /api/orders/by/user/123，返回 Cannot GET 关上控制台之后，发现有一个红色报错： Refused to load the font 'http://localhost:5000/api/ord...' because it violates the following Content Security Policy directive: "default-src 'none'". Note that 'font-src' was not explicitly set, so 'default-src' is used as a fallback. 谬误起因： 原来是路由配置中，门路写错了，前面多了一个空格

外围思路标准并欠缺自测流程，将Bug扼杀在自测阶段，显著升高提测后的线下Bug率。品质和效率乍一看是存在抵触的，更高的品质要求会破费更多的工夫，但如果通过更多的自测工夫，来缩小测试和返工所占用的工夫，那么在晋升我的项目品质的同时，未必会就义效率，甚至还可能缩短整体工时 操作流程在开发工作实现后，提测节点前，产出Checklist模式的自测用例文档，对照文档进行自测，通过所有查看项，并在每一项后打勾确认提测时除了提供我的项目、分支等必要信息外，还应该提供该需要对应的自测用例文档和测试后果，方能提交测试，否则测试人员有权打回本次提测留存自测文档，如果提测后品质问题仍然重大，不便复盘总结经验执行依赖测试人员需在提测前提前产出标准的测试用例文档，并组织评审会议进行对齐。因为开发人员自行编写自测用例是十分低效、且很难零碎笼罩大部分case的，故而自测用例文档是在通过评审对齐后的测试用例的根底之上，进行扩大的。并且较早的产出测试用例，也有助于开发人员尽早躲避一些异样，晋升开发效率提测打回机制。为了束缚并标准自测的执行，测试人员应该领有打回提测的能力，并能够针对显著没有自测，但已显示自测通过的状况发动复盘品质问题定期统计和总结。如果在自测后提测，仍然存在较高的Bug率，应该总结起因，是测试用例覆盖范围不够，还是开发人员没有用心自测，或者其余什么起因，有总结才有执行力束缚和将来提高的空间，对测试团队和开发团队都有晋升明确执行范畴。品质和效率是存在肯定水平抵触的，谋求极致的品质很可能会就义开发效率，这须要寻找平衡点，故而并非所有我的项目都依照自测标准来执行，具体执行规范能够依据团队状况制订后果预期显著升高提测期间的线下Bug率，争取将问题都解决在自测阶段无效升高线上Bug率，越来越欠缺的测试/自测用例，以及开发/测试人员的二次执行确认，确保常见流程不会呈现问题综合开发效率晋升，自测尽管会缩短一部分开发工夫，但能无效升高测试和返工工夫，整体效率取得晋升

简介： 由阿里云云效主办的2021年第3届83行代码挑战赛曾经收官。超2万人围观，近4000人参赛，85个团队组团来战。大赛采纳游戏闯关玩儿法，交融元宇宙科幻和剧本杀元素，让一众开发者玩得不可开交。明天请来决赛赛题设计者杜万，给大家分享一下设计与解题思路。 搭配《用代码玩剧本杀？第3届83行代码大赛剧情官网解析》应用成果更佳。 第四题整体是一个C/S架构，客户客户端是一个编译好的命令行程序，不可被批改，服务端是一个 Spring Boot 的 Web 利用；赛题要求，找出服务端程序的 BUG 并修复；客户端有两个职责，一个是说去向服务端发送失常 HTTP 申请，让参赛者发现BUG。 另一个是验证 bug 修复状况，而后发送给远端的评分程序，取得评分。整个赛题是跑在咱们阿里云 DevStudio 下面，在 DevStudio 里咱们启动一个Intellij IDEA 的社区版，内置了利用观测器（AppObserver） 插件。 Bug 1 ：修复 Regex咱们来看第一个bug 如何修复吧。运行 ‘mvn test’，10 个测试有 9 个谬误。 这里有好几个BUG，咱们先看正则表达式相干的，咱们先修复ExtractHtmlTest，翻阅源码，很快能定位到 Utils.stripHtmlTag 办法，办法名字面意思是去除 HTML Tag 标签，而后认真查看日志会发现。 删除的Tag内容包含了 > 和 ，那阐明正则有问题，下图是对正则的分析。 所以该 BUG上述两种修复办法都是 OK 的。 解法:将 Utils.java 里的正则表达式<(?.*)>改为<(?[^>]*)>。 Bug 2：修复尾串缺失再次执行 mvn test，发现还有单测没有通过，咱们会发现字符串少了一截。 再次查看 Utils.stripHtmlTag 办法，发现 matcher.appendReplacement 办法，如果不相熟该办法，查看JDK的正文后，会发现 matcher.appendReplacement 和 matcher.appendTail 是成对呈现的。所以在循环外补上 matcher.appendTail(builder)。 ...

最近线上产生了一个问题，共事找我说有个用户名字不对，正则验证不通过。 于是我就去数据库查问看了下这个用户的名字信息，就长这个样子。 没认真看如同没啥问题啊，然而认真看了两遍发现如同不太对，怎么这个字这么宽呢？ 我靠，这塔喵的是如同是全角啊！ 具体起因就是因为插入的名字是全角的，导致其余中央调用接口取名字用正则判断不通过。 修复这个问题很简略，从新用半角的字体更新一下名字就能够了，另外前端是有校验的，后端没有用正则做校验，须要补上这个校验逻辑。 然而这个问题就很奇怪，这个全角和半角难道没有校验的吗？ 带着好奇，我特意测试了一下淘宝、腾讯和头条的注册，看是不是能够保留全角。 首先试了下淘宝，红框中我输出的是全角的手机号，很显著全角是不行的。 再试试ＱＱ注册，发现也是不能够的，这很好，大家都不要全角的。 问题到这里其实很清晰了，前后端在注册的时候必定脱漏了这个校验的逻辑，补上即可。 我再测试了一下匹配英文的正则： var　p = /^[A-Za-z0-9]+$/gp.match('qqq')　//输入truep.match('ｑｑｑ')　//输入false所以倡议大家没有对手机号、名字之类做校验的能够补上一个正则的校验，避免落库的数据是全角，防止坑爹。 这个会引发很多问题，比方如果全角保留的手机号，调发送手机验证码接口，他人校验的是半角的规定，你发送验证码都该报错了！ 问题都说完了，无妨再理解下到底什么是全角？什么是半角？ 用过输入法大家必定都见过，然而具体的区别可能还真不知道。 在GB/T 9851.2-2008《印刷技术术语 第二局部：印前术语》中有对应的解释： 2.31 全角 em排字的度量单位，宽度等于所应用的文字的磅数（point），用作排版宽度程度方向的度量。 2.32 半角 en排字的量度单位，宽度等于同一磅数全角的一半。 大家都晓得，咱们中文字体都是方块字，包含排版也是一样，所以咱们的汉字一个字的宽度是一样的。 然而在英文里就不一样了，一个英文字母的宽度可能是不一样的，所以全角/半角的概念诞生就是为了英文而服务的。 它要表白的意思很简略，就是代表字体宽度的概念而已。 而实际上，全角/半角这个概念来源于日本，在日文中，角的意思就是正方形，所以全角/半角的含意就是整个正方形/半个正方形的意思。 这个还有很多叫法，比方全身/半身，港台地区叫全形/半形，然而无论怎样，这些称说都是在印刷行业的里术语称说。 然而起初，随着计算机的倒退，如同咱们科技界的人不太懂这玩意儿，间接把全角/半角搬过去用了，于是就造成了当初咱们晓得的场面。 咱们都晓得，最开始的时候为了映射二进制和英文字母的关系，有了ASCII码，它只有1个字节，最多也只能表白256个符号，而且英文也没用完，只用了128个。 然而对于中文和很多其余语言来说，256个符号必定是不够用的，那咋办呢？那就只能用两个字节了。 所以，随着用户的应用习惯，逐步习惯地把全角当成双字节的中文、韩文，半角当成英文这样子。 在计算机倒退初期的时候，全角/半角的概念大略就等同于单字节/双字节这样的含意，另外还有一层含意就是咱们下面说过的示意宽度，全角示意占用排版的宽度是半角的一倍。 当然了，随着计算的倒退，又诞生了GB2312、GBK，Unicode、UTF-8这些编码，比方GBK中文英文都是两个字节，UTF8下文中3个字节，当初的全角/半角的概念就和占用存储空间大小没有任何关系了。 所以总结下来啊，全角/半角的称说起源日文，然而被谬误的间接带入了科技界（印刷界的人说我都不晓得你们这么牛逼），最后的时候全角/半角就是代表宽度的含意，也被约定俗成地赋予了双字节/单字节的含意，当初来看它只能用户形容宽度更为适合一点。 还有啊，做好代码的参数校验，这个落库了就麻烦了，否则还得跟我一样去刷一遍数据！ 参考资料： https://zh.wikipedia.org/wiki... https://www.thetype.com/2018/...

作者：王向 爱可生 DBA 团队成员，负责公司 DMP 产品的运维和客户 MySQL 问题的解决。善于数据库故障解决。对数据库技术和 python 有着浓重的趣味。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 本文目录： 前言 什么是“Unix千年虫” 试验2038年时 MySQL 会不会受到千年虫影响？ 试验后果 问题起因 影响范畴 解决方案 前言笔者在五一假期间，闲来无事刷了刷论坛博客；看到很多人在探讨2038年“Unix千年虫”危机！。来了趣味于是测试了下 MySQL 会不会受到“Unix千年虫“的影响而逝世 什么是“Unix千年虫”古时候，“千年虫”bug已经引发了很大的恐慌，甚至不少影视剧中都有夸张的刻画。不过在紧急商量和“打补丁”之后，软硬件“无奈正确处理2000年问题”的千年虫危机算是安稳度过了。但……事实真的如此吗？对于 Unix 类操作系统来说，它们其实还面临着同样的问题，那就是——2038年危机！（又称“Unix千年虫”）！！ 截图来自度娘百科： 试验2038年时 MySQL 会不会受到千年虫影响？启动测试 MySQL 并监控 error 日志 随便把零碎工夫调整到2038年 看到了什么？MySQL 它自闭了间接 shutdown 试验后果如果工夫穿梭来到了2038年或将操作系统的 date 调整为2038年，比方2038-10-20，你会发现正在运行的 MySQL 会主动放弃医治，重启后同样会主动敞开，无奈应用，MySQL 不反对2038年之后的日期。 2038-10-20T00:01:01.976322+08:00 2 [Warning] Current time has got past year 2038.Validating current time with 5 iterations before initiating the normal servershutdown process.2038-10-20T00:01:01.976465+08:00 2 [Warning] Iteration 1: Current time obtainedfrom system is greater than 20382038-10-20T00:01:01.976484+08:00 2 [Warning] Iteration 2: Current time obtainedfrom system is greater than 20382038-10-20T00:01:01.976538+08:00 2 [Warning] Iteration 3: Current time obtainedfrom system is greater than 20382038-10-20T00:01:01.976560+08:00 2 [Warning] Iteration 4: Current time obtainedfrom system is greater than 20382038-10-20T00:01:01.976580+08:00 2 [Warning] Iteration 5: Current time obtainedfrom system is greater than 20382038-10-20T00:01:01.976634+08:00 2 [ERROR] This MySQL server doesn't supportdates later than 2038问题起因MySQL timestamp 反对的最大工夫范畴是 '1970-01-01 00:00:01.000000' 到 '2038-01-19 03:14:07.999999'，在源码 sql/sql_parse.cc 的 dispatch_command() 函数里，有一段代码，检测以后工夫是否超过2038年，如果超过，则会立刻进行 MySQL。 ...

每到一个中央先找 WiFi，曾经是有数现代人的习惯了。然而，遇到奇奇怪怪的 WiFi 名（SSID）可要审慎了。最近就有人在应用 iPhone 手机连贯 WiFi 时遇到了麻烦。 平安研究员 Carl Schou 在用 iPhone 手机尝试连贯名称为 %p%s%s%s%s%n 的 WiFi 后，发现手机 WiFi 性能无奈应用，手动关上 WiFi 也会主动敞开，重启手机或更改 WiFi 名都没用。 Carl Schou 首先在运行 iOS 14.4.2 版本的 iPhone XS 上测试发现了这一 bug，起初在 iOS 14.6 版本上的试验表明这一 bug 仍然存在。 Carl Schou 在 Twitter 上颁布这一 bug 后，很多网友在本人的 iPhone 手机上复现了这一问题，甚至有网友发现该 bug 还会影响 AirDrop 的失常应用。 不过，目前安卓手机用户并未受到该 bug 的影响。 尽管看似无厘头，但这个 bug 是实在存在的。有网友认为该 bug 应该失去更多关注，这有可能是权限晋升破绽，万一被利用，很多 iPhone 用户将受影响。 iPhone 为什么会呈现这样的 bug？该 bug 被爆出后，许多平安研究员进行了剖析，认为有可能是输出解析问题导致了该 bug。 当 WiFi 名称呈现带有 % 的字符串时，iOS 可能会将 WiFi 名误认为字符串格式化说明符。 ...

1.执行查问出现异常。 问题剖析： 将呈现的sql查看是否是谬误的sql语句（可放入数据库执行是否能执行胜利）查问后果集到字段的映射看是否和sql语句中数据库字段是否统一。1.执行查问出NullPointException异样问题剖析： 在调用父类办法的时候能够间接this点办法。不用创立dao层对象在调用（会呈现空指针异样）

在 IT 世界，你永远也想不到哪里会呈现怎么诡异的 bug。比方往年 3 月份，一位苹果用户名为 Rachel True 的用户称无奈登录其 iCloud 帐户，而「罪魁祸首」居然是姓名。在程序代码中，「true」和「false」通常被用来判断虚实，导致她无奈登录的起因是苹果 iCloud 零碎主动疏忽了她名字中的「true」。 最近，另一个相似的 bug 呈现了。不过这次问题出在 Safari 浏览器上。 GitHub 用户 quarterdeck 在应用 Safari 浏览器时发现了一个奇怪的景象：当页面 p 标签含有 Welcome Back 字样时，将触发用户名、明码主动填充： 通过重复试验和思考，ta 认为该景象呈现的起因是：Safari 假如所有带有「Welcome Back」的页面为登录页面，进而触发用户名明码主动填充。 如何解决呢？ta 发现只有在 Welcome 和 Back 两个单词之间增加不间断空格，就可阻止 Safari 浏览器的这一行为。 <p>welcome&nbsp;back</p> 另一位用户 laurensgroeneveld 复现了这一 bug，并找到了另一种解决方案：在 p 标签中增加 style="display: none;。 还有人发现，「Sign In」也有同样的成果： 对于这一景象，网友们开展了强烈探讨。 一切都是浏览器的锅？浏览器提供「记住明码」的性能，以在用户下次应用时进行主动填充。很多时候这一性能的确提供了便当，但它还牵扯到许多问题，如安全性、误触发等。 对于上文介绍的问题，有网友称，这并非 Safari 独有的问题，ta 用过的所有明码管理工具都用某种启发式办法决定某个字段是否须要主动填充。 有网友示意，是否显示主动填充的决定权应该是用户，而不是网站。 这个问题还引起了对几个风行浏览器的大探讨： 看起来 Safari 是「当代」IE。 不，Chrome 才是新的 IE。 两者都是新的 IE。一个推送新个性时不顾生态系统的其余局部，另一个回绝施行规范同时也不顾生态系统的其余局部。因而，我认为两者都是新的 IE，只不过处于不同的阶段。 ...

简介： 心愿本文能够帮忙到大家，能够用一种优雅形式接入参数校验，爱护零碎解放本身，从你我做起！ 作者 | 中野起源 | 阿里技术公众号 一 不厌其烦的 if else?参数校验，为了爱护本人的代码，个别都会在开发中假如所有的参数都是不牢靠的。针对所有的参数校验场景本人一次进行判断及错误信息的提醒。 例如： if(a.size > 10 && a.size < 100){ Result result = Reuslt.fail("非法参数size , 请查看输出!") ; return result;}if(xxx) return xxx ;还有一种case，重一点的业务参数校验，有时候也会被不厌其烦地校验，散落在各个子系统或者零碎的各处模块代码中。 例如： if(!validItem(itemId)){ Result result = Reuslt.fail("不存在的商品id , 请查看输出!") ; return result;}private boolean validItem(itemId){ // RPC getItem // 是否空判断 return item != null;}针对以上的场景，本文探讨一下如何优雅地在业务零碎中做参数校验，分享构建通用校验模块的一些实际。 二 业内框架 hibernate validator1 简介JSR提供了一套Bean校验标准的API，保护在包javax.validation.constraints下。该标准应用属性或者办法参数或者类上的一套简洁易用的注解来做参数校验。开发者在开发过程中，仅需在须要校验的中央加上形如@NotNull, @NotEmpty , @Email的注解，就能够将参数校验的重任委托给一些第三方校验框架来解决。 引自网络： JSR-303 是 JAVA EE 6 中的一项子标准，叫做 Bean Validation，官网参考实现是Hibernate Validator。此实现与 Hibernate ORM 没有任何关系。JSR 303 用于对 Java Bean 中的字段的值进行验证。 ...

环境：Win10.0.19042 MDK5.34 问题：设置GB2312编码后，字体效b果被锁定为相似宋体的外观，批改字体无奈造成扭转。 测试发现改为其余编码能够解决（如UTF-8），但可能存在中文编码的各种问题。 上网搜寻后，发现能够应用YaHei-Consolas-Hybrid字体（一款同时具备较柔美的中/英文字符的字体）来解决这一问题。 （不过这个字体没有我可爱的JetBrains Mono难看就是了）

在过来的20年里英国邮局的工作人员始终在解决一款名为 Horizon 的软件，这款软件有一个致命的缺点：它让很多员工被误以为偷了数万英镑。当地的一些邮递员因而被判有罪，甚至被送进了监狱，因为邮局官网保持认为软件是可信的。 通过几十年的奋斗，39人的定罪终于被颠覆了。据报道，这是英国史上最大的一次误判。 美好生活被突破，只因软件出错此事件对这些雇员的影响是微小的：据 BBC 报道，有些职工失去了婚姻或与陪伴孩子的工夫。曾在邮局任职的 Janet Skinner 说，在长达九个月的监禁中，她被带离了她的两个孩子身边，而这所有是因为软件官网 5.9 万英镑的缺口。不仅如此，因为她的刑事定罪，她还失去了一份工作。 她和那些像她一样的员工因被误判进监狱而导致的损失是无法挽回的，而这所有的始作俑者就是软件 Horizon 。 据 BBC 报道，另一名妇女赌咒本人是无辜的，但仍在怀孕期间因偷盗被送进监狱。还有一位男士因电脑系统显示他简直损失了十万英镑而他杀，几个月后，他的继任者也因软件的差别而面临损失。 Horizon 由日本富士通公司制作，该公司在2000年至2014年间，其信息被用于起诉 736 名邮局员工，并导致其中一些人最终进了监狱。零碎谬误会让它报告在员工管制下的帐户呈现了缺口。 除此之外 BBC 报道，一些员工甚至试图用抵押屋宇或用本人的钱来填补账户缺口。 沉冤得雪，噩梦“完结”现在，员工们的噩梦仿佛要完结了，继 39 人的定罪被颠覆后被颠覆后，去年 12 月又有 6 人被无罪释放，邮局也始终在致力为其余因软件造成损失的员工提供经济弥补。 2019 年，邮局与 555 名索赔人达成和解，并向他们领取了赔偿金，同时还建设了一套弥补其余受影响员工的体系。截至目前，2400 多件索赔案被受理。 四月初时，邮政局局长说 Horizon 将会被新的解决方案取代。在同一次阐明会上，他提到，邮政局将与政府单干，抵偿因而软件谬误而受到影响的雇员。 英国首相 Boris Johnson 也于两日前发表了观点，称最后的定罪是“令人震惊的不公正。” 我同意上诉法院决定颠覆39名前邮递员在 Horizon 争端中的定罪，这是令人震惊的不公正，多年来此事件对很多家庭产生了毁灭性的影响。 咱们应该也将吸取教训，以确保这种状况不再产生。 -鲍里斯·约翰逊（@BorisJohnson）2021年4月23日 一些员工对于“赔偿金结算后，他们的罪名就将被革除”的处理结果感到开心，但也有一些组织呐喊政府对此事件进行全面的公开考察，一些在两日前被证实清白的人呐喊查究相干负责人的责任。 邮局认为这些谬误不可能是计算机系统出错，只管他们晓得这种说法是不成立的。有证据表明，邮局的法律部门早在一些定罪之前就曾经意识到软件可能会产生不精确的后果。 邮局工作人员的代表之一说，邮局为了谋求声誉和利益承受了许多一般民众的生命，自在和理智的丢失。 参考链接： https://www.theverge.com/2021... END -

简介：因为线上线下环境隔离的问题，线上的输出很多时候难以在日常环境中结构，定位 bug 效率低下。是否有简略快捷的方法呢？ 一个小故事 周末12点的闹钟在回龙观均价3000的出租屋短促的响起，程序员小A慵懒的拿过手机，滑开手机告诉栏，没有未接电话，点开手机的拦挡信箱，没有报警短信，昨晚的公布肯定很顺利。小A幸福的伸了个懒腰。戴上3000块的BeatsSolo Pro，音乐逐步响起来，小A缓缓的闭上了眼睛，正午的阳光从窗户漫进来，撒在小A稠密的头发上。此时的小A正在脑海中勾画着本人美妙的将来。房东说：十年前住在这间屋的小B，当初曾经是某度的T10 大佬，五年前住在这儿的小T，当初曾经在某条率领200人的团队，想到这儿，小A的嘴角微微上扬，那我也肯定不会太差吧～ 嘀嘀..耳机里传来两声音讯提示音，小A心里咯噔一声，刺骨的寒意洋溢开来，北京三月的阳光忽然就不暖了。小A使劲的微微睁开双眼，告诉栏测试同学小C的头像一闪而过。 xx线上BUG紧急修复群 小C: “@小A 昨晚上线的代码如同有点有问题，来公司看下？我在公司等你。”点开群设置，老板的头像赫然在列。 怀着愧疚、彷徨、懊悔、无奈、愤恨的情绪，小A翻身穿上他在路边买的价值20元的人字拖，坐上了返回西二旗的地铁十号线。 不久，西二旗某办公室传来了亘古不变的对话，“这段代码测试过，在我电脑上没问题啊”、"你重启下试试"、“是不是代码没上线”、“是不是谁把我代码冲掉了”、“你们测试数据是不是有问题呀”……于是一个下午过来了、一个早晨过来了、一个周末过来了、一个程序员的青春过来了、一个程序员本就不长的职业生涯过来了。 一个小总结 下面这个虚构的小故事只是想阐明一个简略的景象，程序员的很多工夫被线上bug fix占据。因为线上线下环境不统一、输入输出不一等等起因，很多bug定位起来效率低下，耗时巨长，导致很多时候程序员遇到线上bug总是头疼不已，情不自禁的想要甩锅给外在因素，在确定是本人的问题的时候再排查问题。那么线上问题排查到底难在哪儿？首先来看看咱们排查线上问题的一个根本步骤，这个步骤个别是排查大多数线上问题的步骤。 步骤1：找到能复现问题的输出；步骤2：判断该输出是否在日常环境结构, 如果能，调到步骤5。如果不能，持续步骤3；步骤3：查看线上环境日志，看是否找到异样输出相干的异样日志，辅助排查问题；步骤4：初步推断问题起因，尝试修复并加上更多日志输入。而后打包、公布。反复步骤3直到定位根因；步骤5：日常结构雷同输出，单点调试，定位问题； 理论的场景中，因为线上线下环境隔离的问题，线上的输出很多时候难以在日常环境中结构，大多数时候咱们都在步骤2、3、4中循环，于是工夫就在循环中缓缓的流逝了。 下面做这么多步骤其实对于查问题而言就是心愿能够晓得当某段代码执行不合乎预期的时候，这段代码的输出是什么，输入是什么，抛出了什么异样，以及代码中每一行的具体执行状况。那么是否有一款产品能够让用户方便快捷的实现这个指标呢？答案是有的。 聊一聊ARMS 阿里云的利用实时监控服务ARMS是一款利用性能治理（APM）产品，蕴含利用监控、Prometheus监控和前端监控三大子产品，涵盖分布式应用、容器环境、浏览器、小程序、APP 等畛域的性能治理，能帮忙用户实现全栈式性能监控和端到端全链路追踪诊断。 ARMS最新推出了Arthas诊断性能，其第一个版本次要蕴含四个能力，别离是JVM概览、线程耗时剖析、办法执行剖析以及性能剖析：• JVM概览：查看实时的JVM内存、GC信息以及操作系统信息、环境变量、零碎变量等信息。• 线程耗时剖析：查看实时的线程耗时状况，并可查看每个线程实时的办法堆栈。• 办法执行剖析：实时的抓取满足指定条件的办法执行明细、出入参数以及异样。• 性能剖析：快捷的通过火焰图的的模式，展现零碎性能瓶颈。 ARMS的Arthas性能应用起来也比较简单，详情可参照文档。上面来简略聊一聊如何利用ARMS的Arthas诊断能力来进行线上问题的定位。 聊一聊ARMS Arthas诊断 上一节简略介绍了下ARMS的Arthas诊断具备的能力，那么用这些能力能解决哪些线上问题呢？在这里，咱们对线上问题进行了一个演绎总结，将其分为上面四类问题： • 办法执行不合乎预期：包含办法执行耗时、办法返回值、办法抛出了异样等状况，体现在利用上可能是一些接口或者服务的RT增高，错误率增高，返回值异样等。• 过程CPU耗时突增：个别有代码死循环问题、FullGC导 GC线程耗时高、并发应用HashMap等。• 性能优化问题：次要用于剖析性能瓶颈，辅助性能优化，包含 CPU 耗时、内存调配、锁竞争、itimer 等状况的性能剖析。• 其余问题：比方初始化环境变量读取谬误、内核版本不符合要求、类抵触等问题。 上面就以一个理论的demo来演示如何利用ARMS的Arthas来进行办法执行不合乎预期这种问题的诊断，后续的文章会持续介绍如何利用Arthas进行其余类型问题的诊断。 利用ARMS Arthas诊断办法执行不合乎预期类问题 问题背景：product 利用的com.alibabacloud.hipstershop.productserviceapi.service.ProductService@confirmInventory 接口某次公布后均匀 RT 达到 400，公布以前的均匀 RT 在 1ms 以下，如下图所示。当初想定位耗时具体耗在哪儿。 图 1 首先，进入ARMS Arthas诊断的页面。当咱们进行BUG定位的时候，首先须要晓得出问题的类名和办法名，依照图示截图中的红色正文输出相应的类名和办法名。如果你是EDAS用户，可间接抉择一个服务或者接口，后盾会主动推断相应的实现类和办法。对应到本案例，对应的类是com.alibabacloud.xxx.xxx.xxx.ProductService，办法是confirmInventory。填写结束后点击确定。 图 2 如下图所示，点击确定后能够失去confirmInventory办法执行的纪录，蕴含执行的入参，返回值异样以及办法执行明细。 图 3 然而这次执行的耗时2.89ms，不是咱们预期中的一次耗时高调用。此时，可点击右上角批改诊断参数，设定抓取耗时大于300ms的办法调用(除此以外还能够设置更多的过滤条件，包含办法参数满足的条件等等，具体可查看文档。 图 4 点击确定后，点击右上角刷新图标再次诊断，这次抓取到一次耗时1501ms的办法调用，发现原来是在该办法的执行过程中，执行了Thread.sleep() 办法。 图5 到这里，你可能还会好奇，为什么会执行sleep办法呢？这块代码的逻辑是怎么的呢？点击右上角查看办法源码，高深莫测的将办法源码与办法执行明细相结合。如下图所示，confirmInventory办法中执行的每一次办法调用最初会以“//-”为前缀展现该办法执行的耗时状况。 图 6 ...

小程序canvas保留图片空白小程序canvas绘制图片时，必须先要把图片下载下来，先调用wx.getImageInfo返回长期门路，再绘图

1、打log，看日志代码log的重要性和代码自身是一样的。在要害的逻辑和判断条件处增加日志，最好做到即便不做debug也能够理解代码运行逻辑。如果不晓得哪些地方应加日志，简略的形式就是所有的自定义函数的入口和进口都增加上日志。能够应用切面编程或者代理，本人封装一个log的框架，利用切面或代理操作就会简略很多，对原始的代码入侵也小。 日志中不仅要有流程的标记，还有有状态信息，比方：工夫、线程号或用户id、要害的参数信息。能阐明谁在什么工夫什么条件下做了一件什么事件，把这个事件说分明就行。 这样的日志量可能会很大，日志的分级解决也很重要，trace、debug、info、warn、error等信息别离示意。error信息中除了异样时的运行栈信息，还须要有一些要害的内存参数信息，比方以后办法的参数或者逻辑的要害条件等。 2、用户访谈要不要做用户访谈？打电话还是与用户见面？这个要看工程师的集体沟通能力。有的人和用户沟通亲切且业余，沟通能力强，有谈话的技巧，用户不恶感，那就能够做用户访谈，和用户理解分明过后产生问题，做了什么操作。很多奇怪的问题都是和特定的操作环境甚至操作流程有关系，做用户访谈要问分明的几件事： 过后的操作环境，零碎，运行环境网络环境，如果是网络问题，和用户沟通一下能不能接入他们网络复现问题过后的操作过程，操作程序一些非凡的操作习惯记下根本的信息，最好用脑子记，过后不要打字或用写下来，这样会给用户压迫感，感觉太正式了，说的内容就会本人提前解决一下。很多操作的细节就是在无心中提到的，所以访谈的时候能够适当随便些，然而留神凝听，如果有细节感觉有点不太一样，先记在心里，不要打断用户，让他顺畅的说完，再发问。 3、代码review，画流程图梳理分明代码逻辑，多看几遍代码，一边看代码，一边和需要/逻辑比照，发现异常的中央。如果逻辑比较复杂，档次比拟深，看一遍记不住所有逻辑，那最好画出流程图，逻辑梳理找到破绽或可疑点。运气不好，还要减少log，测试调试。 4、用google这个老本最低，能够先做。把问题、异样信息贴到google外面，先看看其他人遇到相似的状况了吗？60%的问题这种形式就能解决。 5、用工具剖析运行状态如果能够复现问题了，就能够应用一些内存剖析工具，查看产生问题的状态。不同技术都有内存剖析工具，jmap, jstack等等，多多利用，学习怎么应用这样工具会让解决问题效率晋升很多。 6、评估危害没有不存在bug的程序，评估bug的危害和解决老本就很重要。有没有间接影响到了用户体验，影响到领取流程，影响到了生命安全，影响到用户比例有多少。 有的问题频率尽管不高，然而很致命；有到尽管不会挫伤生命，然而规模大；有的规模不大，也不致命，但用户产生一次就被劝退了。这些都很重大。 危害的评估，次要是三个方面：规模频率、重大水平、危害是否可逆。

环境形容：Ubuntu16.04+ docker container下 问题形容：最近在我的项目中用pudb调试过程中发现的编码问题，google+Baidu各种解决办法都无奈解决，细节如下：问题在只呈现在应用Python -m pudb.run **.py的时候，要是间接python **.py则没有问题。Anyway，网上各种改默认编码格局的办法对我这个问题都不实用。 办法：先用折中办法，删除掉src中的所有汉字正文（中文编码问题实锤）。查看无误。。。先这样跳过，有工夫再看。

错误信息在应用Dockerfile建设Docker镜像的时候，应用pip下载安装numpy时，呈现以下error，Record！ ERROR: Exception:Traceback (most recent call last): File "/opt/conda/lib/python3.6/site-packages/pip/_vendor/urllib3/response.py", line 437, in _error_catcher yield File "/opt/conda/lib/python3.6/site-packages/pip/_vendor/urllib3/response.py", line 519, in read data = self._fp.read(amt) if not fp_closed else b"" File "/opt/conda/lib/python3.6/site-packages/pip/_vendor/cachecontrol/filewrapper.py", line 62, in read data = self.__fp.read(amt) File "/opt/conda/lib/python3.6/http/client.py", line 449, in read n = self.readinto(b) File "/opt/conda/lib/python3.6/http/client.py", line 493, in readinto n = self.fp.readinto(b) File "/opt/conda/lib/python3.6/socket.py", line 586, in readinto return self._sock.recv_into(b) File "/opt/conda/lib/python3.6/ssl.py", line 1012, in recv_into return self.read(nbytes, buffer) File "/opt/conda/lib/python3.6/ssl.py", line 874, in read return self._sslobj.read(len, buffer) File "/opt/conda/lib/python3.6/ssl.py", line 631, in read v = self._sslobj.read(len, buffer)socket.timeout: The read operation timed outDuring handling of the above exception, another exception occurred:Traceback (most recent call last): File "/opt/conda/lib/python3.6/site-packages/pip/_internal/cli/base_command.py", line 228, in _main status = self.run(options, args) File "/opt/conda/lib/python3.6/site-packages/pip/_internal/cli/req_command.py", line 182, in wrapper return func(self, options, args) File "/opt/conda/lib/python3.6/site-packages/pip/_internal/commands/install.py", line 324, in run reqs, check_supported_wheels=not options.target_dir File "/opt/conda/lib/python3.6/site-packages/pip/_internal/resolution/legacy/resolver.py", line 183, in resolve discovered_reqs.extend(self._resolve_one(requirement_set, req)) File "/opt/conda/lib/python3.6/site-packages/pip/_internal/resolution/legacy/resolver.py", line 388, in _resolve_one abstract_dist = self._get_abstract_dist_for(req_to_install) File "/opt/conda/lib/python3.6/site-packages/pip/_internal/resolution/legacy/resolver.py", line 340, in _get_abstract_dist_for abstract_dist = self.preparer.prepare_linked_requirement(req) File "/opt/conda/lib/python3.6/site-packages/pip/_internal/operations/prepare.py", line 469, in prepare_linked_requirement hashes=self._get_linked_req_hashes(req) File "/opt/conda/lib/python3.6/site-packages/pip/_internal/operations/prepare.py", line 259, in unpack_url hashes=hashes, File "/opt/conda/lib/python3.6/site-packages/pip/_internal/operations/prepare.py", line 130, in get_http_url link, downloader, temp_dir.path, hashes File "/opt/conda/lib/python3.6/site-packages/pip/_internal/operations/prepare.py", line 282, in _download_http_url for chunk in download.chunks: File "/opt/conda/lib/python3.6/site-packages/pip/_internal/cli/progress_bars.py", line 168, in iter for x in it: File "/opt/conda/lib/python3.6/site-packages/pip/_internal/network/utils.py", line 88, in response_chunks decode_content=False, File "/opt/conda/lib/python3.6/site-packages/pip/_vendor/urllib3/response.py", line 576, in stream data = self.read(amt=amt, decode_content=decode_content) File "/opt/conda/lib/python3.6/site-packages/pip/_vendor/urllib3/response.py", line 541, in read raise IncompleteRead(self._fp_bytes_read, self.length_remaining) File "/opt/conda/lib/python3.6/contextlib.py", line 99, in __exit__ self.gen.throw(type, value, traceback) File "/opt/conda/lib/python3.6/site-packages/pip/_vendor/urllib3/response.py", line 442, in _error_catcher raise ReadTimeoutError(self._pool, None, "Read timed out.")pip._vendor.urllib3.exceptions.ReadTimeoutError: HTTPSConnectionPool(host='files.pythonhosted.org', port=443): Read timed out.起因因为国内网络起因，pip下载会十分耗时。 ...

环境：Ubuntu 16.04 + Docker问题形容：python调用Pyqt5呈现的链接库找不到相干问题libxcb-xkb.so.1: cannot open shared object file: No such file or directory解决办法：装置对应依赖apt-get install libxcb-xkb1 扩大：依据链接库的名字对应装置依赖若呈现此error： libxcb-xinerama.so.0: cannot open shared object file: No such file or directory装置对应依赖：apt-get install libxcb-xinerama0相似问题链接库：apt-get install libxcb-icccm4apt-get install libxcb-image0apt-get install libxcb-keysyms1apt-get install libxcb-randr0apt-get install libxcb-render-util0apt-get install libxcb-shape0apt-get install libxcb-xfixes0apt-get install libxcb-xinerama0apt-get install libxcb-xkb1记录：服务器端无显示器，Pyqt5链接库链接不上display

具体谬误ImportError: libGL.so.1: cannot open shared object file: No such file or directory 环境：Ubuntu16.04+Docker 解决办法sudo apt updatesudo apt install libgl1-mesa-glx

所有的字下面的字符对应上面的图片 要看清楚所有的异样信息 我的拆坑记录找不到数据异样 绑定异样 xml id值写错报错 if加了；导致上面的变量异样了忘了加service 导致 NoSuchBean 报错了呈现此谬误查看以后类包名是否在启动包中 写js肯定要仔细检查每个代码的字母 重视大小写 肯定要详解看清楚代码当前写代码 走一步 测试一步；分页不能点击时来看看应该有帮忙 搜寻框搜寻不到数据 不在客户端提示信息 少写了#号

所有的字下面的字符对应上面的图片 要看清楚所有的异样信息 我的拆坑记录找不到数据异样 绑定异样 xml id值写错报错 if加了；导致上面的变量异样了忘了加service 导致 NoSuchBean 报错了呈现此谬误查看以后类包名是否在启动包中 写js肯定要仔细检查每个代码的字母 重视大小写 肯定要详解看清楚代码当前写代码 走一步 测试一步；分页不能点击时来看看应该有帮忙

简介： 缺陷分析做得好，bug 写得少。阿里资深技术专家和你分享如何进行高质量的缺陷分析，总结了 5 个要点，通过缺陷分析消除开发中的各种盲点，打造一个学习型的团队。 软件开发中的缺陷隐含着极高的价值，但是许多组织都仅仅忍受了缺陷带来的成本和后果，却让价值白白溜掉了。 缺陷的价值是其触发的学习和成长的机会。把握缺陷带来的学习机会，可以快速提高组织的能力，未来的缺陷更少，成本更低，更容易成功。但同时，有效的缺陷分析和跟踪行动需要有效的方法和相应的组织的支持。 缺陷隐含着极高的价值最近我们做了一次关于缺陷分析的工作坊。 “发生缺陷是一件好事吗？” 在工作坊开始的时候，我这么问参与的同学。 “那当然是一件坏事了。”“不管是不是好事，它就在那儿。我觉得无所谓好不好，这是一件正常的事情。” “这么说好像也对，但是缺陷很麻烦，我没法喜欢缺陷。” 是的，没有人喜欢缺陷，它消耗研发成本，影响开发周期，但同时，缺陷又和软件开发如影随形，无论多少，始终都在。这是为什么呢？ 看下面的这张图： 软件开发和工业生产完全不同。工业生产通过消除过程中的各种可变性，能够逐步逼近零缺陷的目标。所以，六西格玛方法在工业生产中非常行之有效。 软件开发的过程则恰恰相反。每一次开发，都是不确定的，我们往往都是在项目临近结束的时候，对整个项目的各种问题和细节才变得清晰。在这种假设下，与其追求零缺陷，倒不如说是我们应该追求降低缺陷的影响，比如，在缺陷产生的第一时间（注入时间甚至注入之前）就发现缺陷——因为这时候缺陷的成本几乎为零，这也就可以等价为“零缺陷”了吧。 如果说工业生产中的六西格玛方法来自于对生产系统的打造，那么，在软件开发中，“零缺陷”对应的系统是什么呢？它当然包含软件研发的流程和工具，但是，在我看来，最重要的，应该是打造软件的核心主体——人。通过缺陷分析来持续学习，才能不浪费缺陷所消耗的成本。 为什么会重复踩坑有不少团队是有缺陷原因分析的。我曾经仔细分析过一个团队的缺陷原因分析，发现了下面这些缺陷原因的高频词： 编码有问题，下次写代码的时候想的更仔细一些。代码评审做的不好。下次代码评审要充分。业务场景分析不全面，下次分析的更全面一些。......我相信，写下上述原因分析的同学，内心一定是很真诚的，也是真心觉得自己当时代码写的不够好，业务场景分析的不全面，代码评审不够充分。但是，这个分析带来的行动，却往往是不可达成的。是真的想的不仔细吗，还是就是想不到？这次评审做的不好，下次就肯定能做好了吗？这次场景分析不全，那么怎么才能更全呢? 这种原因分析过于宽泛了，以至于很难产生实际有效的改进行动，下次往往还是会在同样的地方跌倒——大家只要看一下在既往的原因分析中，有多少次类似的答案？每一次重复，就是一次新的踩坑。 还有一类原因分析，恰恰相反，又过于具体化了，具体化到了没有学习价值的层面上。例如，这是当时设计的不对，A 服务就不该调用 B 服务，A 服务应该考虑到B服务调用中的异常场景，等等。好吧，缺陷现在已经修复了，A 服务调用 B 服务出现的异常场景已经固化在代码中了，下一次如果是 C 服务调用 D 服务的异常场景应该怎么办呢？ 最合适的缺陷原因应该基于这样的标准：这些原因需要形成系统化的可行动的结果。这个标准的检验方式是：下一次如果发生某某场景，我们的应对方案是否有效? 做好缺陷分析的 5 个要点在实践中，我们总结了 5 个要点，来最大化出于学习目的的缺陷分析的实践操作。它们是： 及时总结，设置卡点结对分析，小组总结负面清单支持下的全量分析可操作的结果团体学习，机制建设及时总结，设置卡点“缺陷分析很重要，但是研发同学都太忙了，我们两个月集中做一次怎么样？”别那么紧张——及时才是最节约的方式。要从忙碌中解放出来，每次花 15 分钟，做一次有效的缺陷分析，时间已经妥妥的啦。 缺陷分析的最好时间是缺陷修复完成的时间。此时记忆最新鲜、也能早收益。如果一个缺陷已经过去了两个月，那么缺陷分析的成本就变高了，得找回原来的记忆和当时的上下文，这个记忆准确不准确还是另一回事。 怎样才能保证及时地做，从而保证这些重要而不紧急的事情发生呢？一个比较有效的方式，是设置流程中的卡点：当缺陷被设定为已修复状态、或者设定为已关闭状态时，强制把缺陷分析设定为一个流程卡点，这样就能形成比较好的驱动。 结对分析，小组总结谁来负责缺陷分析？是让具体这个缺陷的同学来做，还是召集整个团队一起？ 召集整个团队来做缺陷分析，有时候代价过于高昂。即使仅仅分析比较后期的线上问题，即使每个缺陷仅仅分析 15 分钟：100 个缺陷，每个团队 8 个人，乘积就是 12,000分钟，合 200 个小时，也是一个惊人的数字，投入产出不成比例。 解决缺陷的同学确实是对这个缺陷理解最好。但是，这会不会形成“单点问题”，降低问题分析的有效性？ 我们的方案是： 把结对分析作为制度 让解决缺陷的同学担任负责人，搭配上一个小伙伴。结对既形成了知识方面的互补，一定程度上消除了思维盲点，也通过结对形成了更深入的讨论，也提前进行结果的“验收”，提高分析的质量。如果有必要，结对的小组可以自主决定是否引入其他人参与。 团队定期讨论学习 团队定期对重要的缺陷分析结果进行讨论，既是对小组成果的验收，更有利于在团队成员间形成传播，互相学习。 负面清单支持下的全量分析缺陷分析的目的是提升，所以，重在解决那些“未知的未知”的问题。显然不是每个缺陷都应该深入分析。但是，如果我们针对每个缺陷都定义它该不该分析，又会导致决策成本过高，而且质量也不可靠。所以，我们的做法是在默认全量的基础上，使用负面清单进行过滤。凡是负面清单不存在的，都进行缺陷分析。负面清单是团队级别的。每个团队都应该维护自己的列表，例如： 偶发问题已经列在改进项中的问题（不断扩充）这个事情和淘金有些类似，明确不要什么，能更高效地避免那些真正值得做的事情不被淹没。事实上，每次缺陷分析都会扩充负面清单的长度，所需的缺陷分析数量将越来越少，问题越来越聚焦，时间也越来越节省。 可操作的结果缺陷分析应该产生有价值的洞见，足够的深度是重点。在如何产生深度洞见方面已经有非常多成熟的方法，最典型的是 5 Whys，此外还有鱼骨图等著名工具可用。为了控制篇幅，本文略去对这些方法的介绍，只通过一个实例来说明在实际的缺陷分析中，我们是如何产生深度洞见的。 某缺陷描述了如下的场景（该实例在不影响问题说明的情况下做了适度抽象）： ...

问题描述数据库中有如下的地址信息表，需要实现一个更具用户输入的任何内容进行搜索可能匹配的地址信息。 -- MySQL版本: 5.7.25CREATE TABLE Address ( id BIGINT NOT NULL AUTO_INCREMENT, address VARCHAR(100) NOT NULL DEFAULT '', city VARCHAR(50) NOT NULL DEFAULT '', state VARCHAR(50) NOT NULL DEFAULT '', country VARCHAR(50) NOT NULL DEFAULT '', zip_code VARCHAR(10) NOT NULL DEFAULT '', FULLTEXT ftidx_location(address, city, state, country, zip_code)) ENGINE=INNODB DEFAULT CHARSET=utf8;insert into Address(city, state) values ('Irving', 'TX');容易想到利用如下的sql进行检索。 -- 这里的 ${input} 为用户输入的内容select * from Address where match(address, city, state, country, zip_code) against (${input});然而对于太短的输入，如 "TX"，即使数据库中存在 state = TX 的数据，该SQL也是无法检索到任何结果。或者输入 "Irvin" 也是无法查找到内容的。下面将对该问题进行分析和解决，使用"Irvin,TX"作为用户输入进行分析（不含双引号）。 ...

bug异常主要信息如下：javax.validation.UnexpectedTypeException: HV00030: No validator could be found for constraint 'org.hibernate.constraint.Length' validating type 'java.time.LocalDateTime' . Check configuration for 'inTime' 如图所示：1.先说明一下该bug的由来，一个微服务A去调用另一个微服务B，微服务B出现了上面的异常日志，而微服务A的异常日志如下，feign.FeignException：status 500 reading xxxhandlexx(String，xxDTO)：2.由于被调用的B微服务已经有了异常日志，说明该调用已经发送到B微服务了，我们可以从B微服务的异常日志来排查异常。3.回到第一张图的异常日志，这里已经很清晰了，javax.validation.UnexpectedTypeException: HV00030: No validator could be found for constraint 'org.hibernate.constraint.Length' validating type 'java.time.LocalDateTime' . Check configuration for 'inTime'，validation参数校验的时候出现了异常，LocalDateTime类型的变量inTime无法找到有Length的校验约束，请检查'inTime'变量的配置，这里的inTime是方法参数DTO对象的一个字段，如图所示：这里的@Length(max = 30)是导致异常的主要原因，笔者起初inTime的变量类型是String类型，上面加了@Length(max = 30)参数校验，后来换成了LocalDateTime，但是当时也不知道不能用@Length(max = 30)参数校验也忘记去掉了，这里导致方法入参的时候校验失败，抛出异常。那么为什么@Length注解无法用到LocalDateTime变量类型上呢？我们点进去看一下源码：注释：Validate that the string is between min and max included.可以看到只是能用于注解到String类型的变量。把@Length去掉bug就解决了。 如果文章有误，希望指出来。

目前，移动端BUG管理小程序已经上线并且保持持续更新，欢迎大家使用！扫描小程序码就可以随时随地进行BUG管理了哦！1.注册/登录如果您是第一次使用MadPecker，可以直接在小程序里完成注册。小程序登录时用的邮箱地址和密码和PC端的一致，而且登录一次之后，下次进入小程序直接进入项目界面，免去了重复登录的烦恼。2.处理BUGMadPecker小程序和PC端数据完全互通，在小程序上可以完成指派、完成、通过、不通过、关闭、再打开等操作。最早做MadPecker的初心，就是为了提高我们自身团队的工作效率。随着MadPecker进一步的成长，我们有了越来越多的产品线以及越来越多的支持者，我们也同样希望这款产品能够多少对您有一点小小的帮助。当然，如果您对我们的平台有哪些意见或者建议的话，欢迎您在我们的公众号后台留言，小啄我看到了之后会及时回复大家。Peace！

一.简介 vsftpd 是linux上的一款强大ftp服务器，可配置为2种模式：PASV(被动模式)和PORT(主动模式)。2种模式在建立控制通道的时候是完全一样的，但是在数据通道的建立上有所不同。被动模式（推荐）下在数据通道建立的时候，服务器被动开放随机端口（可限定）让客户端来连接，从而建立数据通道。而主动模式（默认）下在建立数据通道时，服务器主动通过客户端发出的端口信息建立数据通道。 二.步骤 yum -y install vsftpd //yum安装 mkdir /home/dev/ftpfile //创建ftp共享文件夹 useradd cyl -d /ftpfile -s /sbin/nologin //创建虚拟用户，为了安全起见，不给登录权限 chown -R cyl.cyl /home/dev/ftpfile //修改文件夹权限 passwd cyl 111111 //重设密码 cd /etc/vsftpd vim chroot_list //用户列表 vim /etc/selinux/config 修改为SELINUX=disabled //启用ftp支持 reboot //重启服务器 vim /etc/vsftpd/vsftpd.conf //修改配置项 配置防火墙： 重启防火墙和vsftpd 访问后报错：500 OOPS: cannot change directory:/home/dev/ftpfile/ 修改dev文件夹权限：chmod 777 dev 本人创业团队产品MadPecker，主要做BUG管理、测试管理、应用分发网址:www.madpecker.com，有需要的朋友欢迎试用、体验！本文为MadPecker团队技术人员编写，转载请标明出处

早上9点上班，晚上9点下班，一周上班6天，这样的工作强度在互联网公司十分常见。那么真的每个人都能接受这样的福报吗？告别996，提升工作效率才是关键！ 1.制定工作计划 大家都知道，制定工作计划的重要性是毋庸置疑的，没有计划的工作就想拿着一把钝刀砍柴，杂乱的工作内容会让你不知道应该在什么时间点做什么事情。有数据显示，只要用20分钟制定一个计划就能节约一个小时的工作时间，并且琐碎的事情也不会成为你大脑的负担。 项目管理者或者项目成员可以列出今天需要完成的事情，分配好处理人，设置好计划时间，那么这名处理人就能够知道这是今天需要完成的任务。当然，如果任务没有按时完成，计划时间后边会显示一个“已超期”标识，这就表示任务没有按时完成。2.确定工作重点 每个人的工作时间都是有限的，但是为什么别人能够在相同的时间内获得比较多的工作成果呢？在时间管理理论中一个核心的点就是四象限法则，这个法则把要做的事情按照紧急、不紧急、重要、不重要的排列组合分为四个象限，包含紧急且重要的事情、紧急不重要的事情、重要不紧急的事情、不紧急不重要的事情。 我们将四象限法则加入我们的系统，并将其浓缩为急、高、中、低四个优先级。项目成员在工作时可以根据实际情况确定工作的重点，优先处理相对较急的任务，这样的话，即使工作时间有限也可以在工作中生产最大的价值。3.分类工作任务 这一点相信很多人在工作中都深有体会，同类的工作放在一起做可以大大减少工作时长、提高工作效率。反之，杂乱无序的工作任务再加上突发的情况，很有可能让我们感到头大并且削减我们的工作热情。 为了增加工作的层次感让工作内容更加清晰，我们在系统中加入了模块的设定，模块可以由项目管理者在项目配置中自定义，之后所有项目成员都可以根据模块来分类自己的工作任务。如果说按模块工作还不能满足需求，可以自定义标签再对任务进行区分。 最早做MadPecker的初心，就是为了提高我们自身团队的工作效率。随着MadPecker进一步的成长，我们有了越来越多的产品线以及越来越多的支持者，我们也同样希望这款产品能够多少对您有一点小小的帮助。当然，如果您对我们的平台有哪些意见或者建议的话，欢迎您在我们的公众号后台留言，小啄我看到了之后会及时回复大家。Peace！

近期Tableau着实刷屏了，身边的朋友纷纷“墙裂”推荐，其强大的数据处理及可视化分析号称比传统excel等现有解决方案提高10-100倍，堪称是【报表网红】。同样的，我们MadPecker在提测领域也可以帮助测试人员、开发人员提升10-100倍的工作效率，【提测网红】实至名归。 对于大多数团队而言，提测应该都是比较”糟心“的事情，测试用例的录制，测试计划的编排，测试过程中产生的bug的跟踪和修复，都将直接影响项目的上线质量。今天小啄给大家分享一下如何让每个团队的测试变得更有效率。 高效使用测试框架 测试人员在接到一份新项目的测试任务的时候，肯定是需要先理清楚测试思路的。为此，我们搭建了一套完整的测试框架，从用例录制到BUG提交形成规范的测试机制，即使是测试新手也几乎不用学习成本就可以完成测试任务。关于一些用户提出的在测试过程中遇到的问题： 1.测试用例写不全，总是感觉还有缺漏 2.测试用例深度不够，只能发现一些表面的问题，扎根深处的问题没法发现 3.测试过程中总是这点点那点点，没有根据场景进行项目测试，也不知道实际用户的使用习惯 针对类似的问题，我们根据长期积累下来的经验统一了测试用例的编写规范，目的在于提高测试用例的可读性、可执行性和合理性。因为编写测试用例相当于整个测试流程的地基，没有把地基打好，测试结果就不言而喻了。所以测试人员在编写测试用例时，需要以最小功能模块来划分用例，这样才能保证用例覆盖足够广，也使得后续问题的出现大大减小。那么如何高效地使用测试框架呢？我们建议先测主线再测支线。主线指的是真实用户完成一套正常流程所走的路线，支线指的是围绕主线的功能模块及其功能细节，这两条路线在系统中都可以使用同一套框架。 为保证测试流程更加接近真实用户的使用情况，我们构建了可复用的测试用例和测试场景，方便大家使用场景法进行测试。场景法是通过运用场景对系统的功能点或业务流程的描述来提高测试效果的。可复用的用例、场景也帮助测试人员大大地提高了工作效率。 同样的，测试执行也是测试框架中的一部分，测试执行将所有测试用例量化，然后整合起来指定给执行的负责人，并保证测试计划的有效性，确立每个测试阶段测试完成以及测试成功的标准和要实现的目标。通过执行中的通过率和完成度两项指标，测试人员或者项目的负责人都可以很清楚地了解到本轮测试的完成情况并对项目进行风险评估。在测试过程中，我们设定了BUG反馈机制，执行中产生的BUG直接反馈给开发人员，使得整个测试流程形成闭环。 打造测试界的网红产品 在MadPecker测试管理功能上线的短短几个月内，大量团队争相涌进，并将MadPecker作为团队的首要测试管理工具，使得我们的产品在业内积攒了一定的知名度。在此，小啄代表团队所有人感谢大家的信任。同时，我们也欢迎越来越多的团队加入进来，让每个团队的提测变得更有效率！

如果第二次看到我的文章，欢迎「文末」扫码订阅我个人的公众号（跨界架构师）哟~ 每周五早8点 按时送达。当然了，也会时不时加个餐～ 这篇是「分布式系统理论」系列的第20篇。提前预告一下，后面还有一篇文章，这个系列就结束了。 在之前，核心的概念都讲的差不多了。前面Z哥带你已经聊过了「数据一致性」、「高可用」、「易扩展」、「高性能」主题下的一些实践思路。 这篇讲怎么构建一个「易测试」的系统。 作为一位开发人员，可能一听到测试就想关掉这篇文章了。那我只能说too young，too naive。 作为关注我这个号的“跨界者“们，你不能将自己的边界划的太清楚，特别在当下这个变化越来越快、适者生存的时代。要活的像“水”一样，与所处的环境结合的更紧密。 除此之外，测试工作并不是单单测试人员的事，开发人员是不是编写了一个易测试的系统也至关重要。 在Z哥我过去的几年coding经验中，总结了六点认为有助于构建出一个易测试的系统建议，在这里分享给你。 第一点，分层。分层其实除了之前聊到的「易扩展」之外，对于测试工作的进行也是有很大帮助，规模越大的系统越是如此。 脑子里想象一下，一条业务线好比一根管道，每一次的业务操作会经历整根管道的流转最终到达终点。 往往很多时候，其实我们已经定位到了问题可能产生的范围，但是由于项目没有做好分层，导致每一次的测试工作不得不“从头开始”。这是多么痛苦的一件事。 做好分层只要记住一个概念就行，「高内聚低耦合」。具体可以参考之前的文章，文末放链接。 第二点，无状态。前面的文章里说过，满足无状态的功能点意味着可以动态的进行扩容而不用考虑“状态丢失”问题。其实同时它也支持了一种测试场景，就是「容量规划」。 为了支撑业务的不断发展以及不定期举行的大型活动，我们需要清楚的知道，到底部署多少台机器为宜。 当然，你也可以选择拍脑袋的方式进行，尽量多加一些就好了。但这不是一个科学的方法，也容易造成更多的浪费。 进行容量规划的过程就好比通过水龙头装水到一组杯子里。比如，你现在的要求是1分钟装入3L水，那么通过不断的调整杯子的数量和大小，理想情况是刚刚好达到这个要求为宜。 如果此时支持无状态，那么整个过程中水龙头一直开着就好了，你只要专心调整杯子的数量和大小就行。做好无状态具体也可以参考之前的文章，文末放链接。 第三点，避免硬编码，尽量配置化。可能你一看到那些庞杂的配置项就头疼，但是不得不说，配置对于测试工作的开展是有很大帮助的。 反而用“眼不见为净”的方式，硬编码到逻辑代码中是“掩耳盗铃”的办法。 特别是以下这些用途的变量，尽量放到配置中去，否则每次配置的变更都需要重新打包编译代码，是多么麻烦的一件事情。 容量类的配置次数类的配置开关类的配置时间类的配置这些类型的配置之间的共同点是，没有永远正确、永远合理的配置。你要根据你当前的需求，不断的调整他们。 如果可以引入一个集中式的配置中心就更好了，这样可以不用一个个登陆服务器去修改配置。 第四点，依赖注入。如果你平时经常编写单元测试的话，对这个应该感受颇深。因为支持依赖注入的代码，更容易编写单元测试。 但它的价值还不止于此，随着系统规模越来越大，对于直接在生产环境进行故障演练需求越迫切，因为这才足够真实。 但是又要求不能对正常的业务数据产生影响，怎么做？那就只能单独准备演练数据，然后写入到单独的数据库中。 这个时候，依赖注入就起作用了。我们可以将载入数据源的地方设计成支持依赖注入的，如此一来，你就可以灵活的切换到不同的数据源，进行故障演练。 public interface IDataSource{ public string getName(int id);}public class DataSourceMysql implements IDataSource{ public string getName(int id){ // 从正常的数据库里中获取数据。 }}public class DataSourceDrill implements IDataSource{public string getName(int id){ // 从故障演练的数据库里中获取数据。 }}public class UserBLL{ private IDataSource _database; public UserBLL(IDataSource database){ _database = database; } public void MethodA(int id){ // do something... var name = _database.getName(id); // do something... }}//以下是调用的时候new UserBLL(new DataSourceMysql()).MethodA(id); //处理的是正常数据new UserBLL(new DataSourceDrill()).MethodA(id); //处理的是演练数据第五点，打日志。测试工作最终做的好不好，看的是数据，是结果。这就意味着，对一个系统要求是「可观测」的。 ...

前言也许大家都知道，分析 Kernel Dump 有个常用的工具叫 Crash，在我刚开始学习分析 Kernel Dump 的时候，总是花大量的时间折腾这个工具的用法，却总是记不住这个工具的功能。后来有一次在参加某次内部分享的时候，有位大佬说了一句话让我印象非常深刻：这些工具怎么用的大家不用记，等到真正开始用的时候你就会猜到这个工具有什么功能。这篇文章我想通过分析一个实际的案例，尽量把学习Kernel Dump需要用到的知识串起来，虽然某些知识也许只会在这个案例中用到，但是我相信所用到的方法是可以应用到各个地方的。 起线上有一台 VM 宕机了，刚好有抓到 dump，拿到一台测试机上就可以开始分析了。首先需要的是 kernel 版本对应的 symbol，如果事先不知道 kernel 的版本，可以通过 `strings corefile | grep "Linux version"' 获取到当前 corefile 的 kernel 版本，例如 3.10.0-862.14.4.el7.x86_64 在获取到内核版本之后，根据相应的发行版以及系统架构到特定的 symbol 发布页面下载 symbol，这里的发行版是 Centos，可以到 http://debuginfo.centos.org/ 下载。如果是 Ubuntu 发行版，可以到 http://ddebs.ubuntu.com/ 下载。要找到指定 kernel 版本的 symbol 很简单，只需要拿着 kernel 版本 3.10.0-862.14.4.el7.x86_64 搜一下就能找到了，通常我们需要的 symbol 的只有下面这三个中的两个，但是我总是记不住是哪两个，所以我会把三个都下载下来并安装：kernel-debug-debuginfo-3.10.0-862.14.4.el7.x86_64.rpm、kernel-debuginfo-3.10.0-862.14.4.el7.x86_64.rpm、kernel-debuginfo-common-x86_64-3.10.0-862.14.4.el7.x86_64.rpm。在安装的时候由于依赖的关系需要先安装 common 的 symbol 才能安装其它 symbol，另外如果测试机上的 kernel 版本比 corefile 的版本新，需要加上 --force 选项才能安装上。 承在 symbol 安装完之后，就可以通过 crash 载入 corefile 和 symbol 了。 ...

尽管工程师用代码创造了AI，但AI又可以对这些代码点评一番、甚至修复Bug，工程师和AI的关系正在变得微妙。AI评委引热议，阿里巴巴表示：AI不会取代工程师4月18日，2019阿里巴巴研发效能峰会——“83行代码挑战赛”决赛现场引入了一位“AI评委”，和专家评委、大众评委配合，对选手提交的的代码做综合评价，这也是全球代码比赛中出现的首位AI评委。这场面向阿里3万多名工程师的技术大会旨在进一步提升内部的研发效率，而“83行代码挑战赛”可以说是阿里巴巴史上最大规模的代码品鉴会。比赛源自1年前阿里内网一次集体晒83行代码的活动，阿里巴巴集团CTO张建锋、蚂蚁金服CTO程立，甚至马云、彭蕾都有参与。这位AI评委运行在云端，当选手提交代码后，会从静态分析、运行时分析、群体共性等不同维度对代码快速打分。比赛现场，大屏实时显示选手分数，随着AI评委、专家评委、大众评委的分数依次出现，分数排行榜会根据综合打分实时滚动，一个逻辑语言的处理甚至可能瞬间提高选手排名。结合现场专家和大众评委的观点来看，AI评委的评分相当准确，且打分最为迅速，几乎是在代码提交后立刻出现结果。AI评委是谁？这位AI评委来自阿里巴巴代码平台研发的人工智能系统，其中最重要的一环是集成了Precfix（Patch Recommendation by Empirically Clustering），不依赖测试用例、编译结果，通过非规则化的智能扫描，即可自动定位代码中的Bug，并提供修复建议，速度可达毫秒级，且误报率低。Precfix能够发现一些规则检查和人工评审都无法发现的缺陷，根本性地提升代码质量，有效减少开发工程师debug及代码评审时间。同时，Precfix提供的修复建议，能帮助工程师快速理解缺陷和解决问题。目前，Precfix已被部署到阿里巴巴代码生产环境，用于缺陷检查。工程师写好代码，就提交到线上，Precfix会进行review，指出缺陷代码及相应的修复建议。据一位工程师透露，过去人工review代码查找bug可能需要几小时甚至几天时间不等，而现在不用一杯咖啡的时间，Precfix就可以review完提交的全部代码，提高了至少20%效率。未来，Precfix还会随着阿里代码平台的上云，一起为全球开发者服务。本文作者：阿里云头条阅读原文本文为云栖社区原创内容，未经允许不得转载。

如果这是第二次看到我的文章，欢迎文末扫码订阅我个人的公众号（跨界架构师）哟~ 本文长度为4818字，建议阅读13分钟。坚持原创，每一篇都是用心之作～这是一篇半娱乐性的吐槽文章，权当给广大技术人员解解闷：）。哈哈哈，然后我要开始讲一个经常在发生的事实了。（程序员们可能会感到一些不适）99.999999999%做技术的都会被问到或者被吐槽到：“你的程序怎么又出bug了！”反正，我作为程序员的内心世界是：如同一万只草泥马飞奔而过，难以压抑内心的激动，每次都差点忍不住想说“你写篇几百字的作文还有错别字呢，我码个几万行的代码还不允许出错了？“可能同样是做技术的你此时在不断点头，哈哈。但是这么讲毕竟也缓解不了矛盾，我们还是得摆事实讲道理不是？啥都不怕，就怕程序员有文化！所以，Z哥想来带你好好分析一下这个事情，当你再遇到这个情况的时候，可以拿这些观点来反驳（不是做技术的也可以了解下程序员的难处，谁没个难处呢，多多包容）什么是Bug任何一个「问题」的产生，本身是没有好坏之分的，但是为什么会有的就不被care，甚至还会很喜欢，而有的会被吐槽呢？根本原因是因为产生了利益损失。比如年前拼多多出问题送了很多无门槛券。作为一个用户，自然很喜欢，夸你夸到飞起，怎么会吐槽你呢。但是作为利益损失方，必然破口大骂，害我倾家荡产！所以，如果没有产生利益损失，我想其他人也不会来找你吐槽。但是「问题」就等于「bug」吗？我认为并不是，「问题」不等于「 bug」。因为程序员的职责是什么？拿造房子来比喻的话，我认为最核心的工作真的和“搬砖”（非贬义词）无异，就是根据设计师（产品经理）设计好的设计图砌砖（编码），建成和设计图纸上一模一样的建筑。所以，如果一个东西造出来与设计不符，那么它可以说是bug或者缺陷（缺斤少两不完整）。否则，并不是bug，但可以被称之为「漏洞」（完全没考虑到的），表示不在预料之内的情况。之前看到过一个形象的比喻：你家里的窗可以从外面打开，那叫漏洞。你家里的窗打不开，那叫bug。但是要承认，bug是必然存在的。为什么？它是如何出现的呢？Bug是如何出现的正如前面所说，程序员做的是“造房子”的事情。这件事完整的步骤分为3步。与产品经理讨论并确定功能（确定一个可以实现的设计图纸）将每个单独的元件抽象出来（确定施工方案）将相关的元件实现并进行组合，完成建设（带上材料开始施工）第一步，“与产品经理讨论并确定功能”主要是沟通，靠“看”和“理解”。但是沟通本身是一个有损耗的过程，特别是在职责非常明确的组织中，产品经理啪啦啪啦讲了很多，到实际做的时候你必然还是会去翻阅需求原型、需求文档之类的重新理解一下。这个时候就是一个非常危险的时期。比如像下面这个的答案是什么？答案是17？不对。我猜你可能没注意到这些地方。为了让你有深刻的印象，这个举例可能比较刻意和夸张一些，但是我想在你的身边，由于没注意到或者理解有误的现象肯定很常见。沟通是相互的，这锅只让程序员背的话的确太委屈了点。第二步，“将每个单独的元件抽象出来”这主要是一个人抽象能力的体现。但是抽象是啥？抽象是“透过现象看到本质”的能力，这个能力理论上是可以无限增长的。随着你对相关信息的掌握越多，这个能力会越强，会无限趋近于100%，但永远不会真正达到100%，因为没人知道怎么才算100%。所以，当你具备的信息没那么多的时候，是不是就抽象的不是那么合理？不合理会导致什么？虽然不会直接产生bug，但是会更容易产生bug。但是人不都是需要经历这么一个成长的过程么？可以说，精通一项能力的背后都是踩着无数的bug过来的。要么在来这个组织之前已经踩过了，要么在这个组织里踩。因此，前者的薪资也比后者高。所以，如果过分苛求没有bug，等于是在扼杀每个人成长的机会，并且在透支未来的可能性。人会变得非常保守、不敢尝试新事物。但是外部环境在不断变化，新事物总会被动的需要去接纳（技术的更新越来越快，趋势不可逆），然而对新事物的接受能力又得不到锻炼，一旦遇到这种情况，在接触新事物的时候会产生更多的问题（欠下的债总要还的）。第三步，“将相关的元件实现并进行组合，完成建设”这就是实际的coding过程，而coding是一个主观的，完全由人主观掌控的事情。人毕竟不是机器，不可能不犯错，就如前面提到的写文章的时候出现错别字一样。可能你会说，有测试人员啊，测试的工作不就是通过逆向思维来给程序员查缺补漏吗？的确是的，但测试的介入只是降低错误率，只是让不出现bug的概率小数点后多几位，指望发现100%的问题还是不太现实的。至少在当下的条件下是这样，为什么呢？因为代码的本质是各种逻辑的组合。比如，一个完整的业务流程有10个环节，每个环节有3种可能性，这是一个什么复杂度的系统？3 ^ 10 = 59049个分支（理论上存在的可能性数量），想要100%覆盖这些场景，付出的成本几乎是不可接受的。然而我们实际的系统中遇到的个别场景甚至还要复杂的多。其实每个正在运行的系统都有bug，包括我们每天在使用一些热门系统（玩游戏的小伙伴们肯定熟悉“卡bug”这个词）。只是这些bug有没有被执行到，有没有被发现，被多少人发现而已。那么，我们只能举手投降吗？那倒不至于，办法还是有的。减少bug的惯性想法首先最容易想到的一点是，增加测试人员。这也是最容易看得到的“成本”一种方式，毕竟招一个人就得支出一份工资啊。所以，增加测试人员这个方案是最不容易被老板们采纳的方案。除非你可以说服这个人力成本的投入小于获得的价值。另外，这个方案其实还增加了沟通成本，沟通的「隐性成本」其实非常大，但是往往容易被忽略。（关于沟通成本，感兴趣的可以看我之前写的《就简单聊聊沟通效率问题》）其次会想到的就是程序员代码写的严谨一点，仔细一点啊。这也是一种缺啥补啥的惯性思维。先撇开到底能不能达到严谨一点，仔细一点的目的。那怕达到了，他会产生什么结果呢？可能是下面3种。更多的条件验证更多的单元测试更多的抽象提炼可以确定的是，这些工作会增加2样硬性的东西，投入的时间和整体的复杂度。时间很好理解，我们就来聊聊复杂度。一个常识是，越简单的东西越不容易产生bug。比如1+1=2，出现bug的可能性无非就是加号写成来减号，1写成了4之类。但是，1+1=2，并且1*1=1，并且1/1=1，。。。等等这些验证条件越多，那么由于验证条件自身的错误而产生问题的可能性反而更多。所以，代码的复杂度和产生bug的概率是成正比的，并且具有「边际效用递减」的效果。这就意味着，做更多的验证带来的收益会越来越小。因此，这个方案哪怕真能执行到位，也不是一个特别好的方案。那有没有相对靠谱一些的办法呢？有，但需要我们换一个角度来看待这个问题。换一个角度看待bug既然无法100%避免bug，那我们可以换个角度考虑一下，如何让解决bug的过程更快，甚至快到你都没有察觉。解决bug主要就是做2件事，找到bug的产生点，然后修复它。每天都在解决bug的程序员们应该知道，这事最费时间的是“找bug”的过程。因为“修复bug”是一个技术性问题，这个对不同人的差异其实是很小的，因为程序员们每天在写的代码都是差不多的，非常同质化的，况且还有标准答案“文档”可以参考。比如，都知道string.concat()是拼接，string.split()是分割。该用分割的地方不小心用了拼接，那改掉就好。但是“找bug”就不是这样了。比如，你刚刚改完一行代码后发布出现的问题，你不用找就知道问题出现在哪。但是让你排查一个刚接手没多久的系统肯定是一脸懵逼。根本原因在于，这个过程不像技术性问题具有确定性，它是充满不确定性的，处在一个“混沌”的环境中。所以，对待bug的重点就变成了：如何更快的发现和找到bug。关于这点Z哥的建议是：打好日志学会利用工具每次的迭代规模尽可能的小首先，打好日志。日志其实就是我们在编码的时候安插在程序中“记录员”，它替我们记录着我们认为容易出现问题的地方所产生的信息。但是系统无时无刻都在运行着，必然会产生大量的日志信息，如何从这些信息中快速的找到关键信息，就是需要考虑的问题。另外，如果每个人都随意的用自己喜欢的记录日志的方式，那么从风格迥异的日志中找你需要的信息就变得很头疼，时间不一致，格式不一致等等。所以，要做好打日志这个事情，就需要定义一个标准，比如必须要有时间，包含当前上下文的参数等等。我们还可以给日志做一下归类，定义不同的日志级别，在记录的时候带上前缀。比如【info】、【warning】、【error】之类。如此一来，平时更着重关注的就是error级别的信息，而且由于将其他级别的信息剥离了出去，使得这里的数据量大大减少，更便于查看。不过，日志记录毕竟是一个在做“预判”，如果日志中没有记录到怎么办呢？这里提醒大家不要先想着怎么调试。如果你面对的系统是一个单体应用倒还好。如果你面对的是一个大型的分布式系统，调试的效率低不说，这事你一个人可能还完不成。而且，如果你直接调试生产环境的话，说不准还会产生什么副作用，摊上新的问题。找bug本质上是一个排除法的过程，设断点调试也是如此。但是从起点开始一步一步的做排除法效率太低了。应该先通过自己的经验、拥有的部分信息先逻辑推理一下，缩小排查的范围。哪怕你最终还是需要调试的话，先做这个事情也会让后续的工作更高效一些。第二点，利用工具。这里的“工具”不要简单的理解成利用“调试工具”。正如上面提到的，找bug的本质是一个排除法的过程，那么任何能够帮你更高效的做排除法的工具都是可以利用的。比如，从系统的「事件查看器」中获取更多的环境信息。利用windows平台的windbg、lunix平台的MAT之类的工具直接分析抓到的dump文件。借助可视化工具更高效的发现问题，如FlameGraph等。另外，如果能主动的告诉你哪里出现bug了，就更棒了。所以，我们可以搭建一套查看方便，信息同步及时的日志框架，以便让有价值的信息第一时间呈现在你的面前。如果有高效的筛选功能就更好了。很多日志框架Z哥没用过，就不发表什么言论了，但是elasticsearch + logstash + kibana这套用起来还是很爽的，体系也比较成熟，部署起来也很简单，大家可以尝试一下。再配上ElastAlert或者Sentinl，可以把实时预警机制也包含了。最后，每次的迭代规模尽可能的小。这个说起来容易，做起来难，因为这是由整个团队的文化来决定的。这个点的内容完全可以单独开一篇讲，这里就简要阐述下。MVP（Minimum Viable Product）式的小步快跑，其实除了让系统或者产品的功能演进更科学之外，还可以让每次迭代所面临的风险更小。正如前面提到的，你改一行代码发布上去，如果出问题，你说问题在哪？相对的，再想象一下，一次性发布一个开发了半年的版本，前一晚能睡的安稳不？总结好了，我们总结一下。这篇呢Z哥先阐述了我对“什么是bug”的理解，然后分析了bug是如何产生的，以及我们可能会做的一些惯性选择。最后给你的建议是，以如何更快的找到bug为出发点来考虑。通过「打好日志」、「学会利用工具」、「每次的迭代规模尽可能的小」这3种方式来进行。不过话说回来，虽然我们无法避免出bug（一个项目开发完后没测出bug？你问任何一个技术人员都说“做梦呢”），但是争取让bug更少是我们的本职工作。因为对bug容忍度低的另一层含义是，大家对系统的依赖越来越重，越来越多的事情在通过程序完成，而不是人力。但是再有人咄咄逼人，就把这篇文章丢给他！相关文章：就简单聊聊沟通效率问题作者：Zachary出处：https://www.cnblogs.com/Zacha…如果你喜欢这篇文章，可以点一下文末的「赞」。这样可以给我一点反馈。: )谢谢你的举手之劳。▶关于作者：张帆（Zachary，个人微信号：Zachary-ZF）。坚持用心打磨每一篇高质量原创。欢迎扫描下方的二维码~。定期发表原创内容：架构设计丨分布式系统丨产品丨运营丨一些思考。如果你是初级程序员，想提升但不知道如何下手。又或者做程序员多年，陷入了一些瓶颈想拓宽一下视野。欢迎关注我的公众号「跨界架构师」，回复「技术」，送你一份我长期收集和整理的思维导图。如果你是运营，面对不断变化的市场束手无策。又或者想了解主流的运营策略，以丰富自己的“仓库”。欢迎关注我的公众号「跨界架构师」，回复「运营」，送你一份我长期收集和整理的思维导图。

今天在写一个小的 CSS Demo，一个关于 3d 球的旋转动画，关于 CSS 3D，少不了会使用下面这几个属性：{ transform-style: preserve-3d; perspective: 1000; transform: translate3d();}这个 Demo 你可以戳这里，大概是这样：CodePen Demo - 3D ball:嗯，大概到了这个效果，想到了 CSS 混合模式 mix-blend-mode，寻思着，利用混合模式，是否能让效果更上一层楼或者碰撞出一些其他火花。mix-blend-mode：我们通常称之为混合模式，利用混合模式将多个图层混合可以得到一个新的效果，mix-blend-mode 描述了元素的内容应该与元素的直系父元素的内容和元素的背景如何混合。关于混合模式的一些使用可以看这里：不可思议的混合模式 background-blend-mode (二)、不可思议的混合模式 background-blend-modeCSS 3D 配合 mix-blend-mode然而，给元素加上了一个混合模式之后，神奇的事情发生了，3D 效果消失了。也就是在每个光点的 CSS 元素代码中添加这样一句：{ mix-blend-mode: lighten;}效果从 CSS 3D 变成了 2D。这就很蹊跷了，预想中的混合并没有发生，取而代之的是 3D 的失效。我想，也许与内核有关，上面的效果是在 chrome 65.0.3325.181 试验得到的。是否与浏览器内核有关？带着这样的疑问，我又测试了下其他几个内核：firefox 64.0 – 这次更加诡异，整个图案都不会再被渲染出来Safari 12.0.2 – 渲染正常Safari 是可以正常展示的，只能初略的认为，应该是与内核有关系的。那应该也有很多人遇到过同样的问题，带着这个疑惑，google 一下。爆栈网也有同学提出类似的疑惑：StackOverflow – mix-blend-mode is broken by 3D transformations on page随后，在 chromium bug 提交网站上，找到了 15 年的一个 bug 单，也是对这个问题的疑问：BUG -CSS mix-blend-mode turns off CSS perspective.最终在 bug 单的最下面找到了可能靠谱的回答：When we have mix-blend-mode, the closest ancestor that creates stacking context will isolate blending. We create a render surface at the root of this isolated group and because render surfaces don’t support preserve-3d(because they render into separate FBO), we see a flattened result.ajuma@ suggested that this bug maybe much easier to fix after Slimming paint v2 if we can somehow disentangle transforms from layers.翻译一下，意思大概是：当我们使用 CSS 混合模式的时候，堆叠上下文会重新对这个使用了混合模式的元素的根节点处创建一个独立的渲染平面，但是很可惜，这个渲染平面是不支持 preserve-3d 的(因为它们渲染到单独的FBO中)，所以我们看到是一个 2D 的平面效果。验证 Layer borders上面的那句话应该已经可以作为结论，我再使用 chrome 提供的工具验证一下，打开开发者工具的 Rendering -> Layer borders：黄色代表 CSS 渲染时候的 GraphicsLayer 层， 蓝色网格表示瓦片(tile)，你可以把它们当作是层的单元（并不是层），Chrome 内核可以将它们作为一个大层的部分上传给 GPU 进行渲染加速。正常 3D 模式下，开启 Layer borders 效果：添加了 mix-blend-mode 的 3D 模式下，开启 Layer borders 效果：可以看到，在 mix-blend-mode 的 3D 模式下，确实在整个球形元素之外，又多了一层蓝色 tile。也就是上文提到的独立的渲染平面，也就是因为这个渲染平面不支持 preserve-3d 的原因，我们最终得到了一个 2D 平面图形。滤镜也会导致 CSS 3D 失效完了吗？没有。不是吧，这谁顶得住啊。那么如果是因为 mix-blend-mode 多生成了一个独立渲染平面导致的 3D 失效，那么是否有其他元素也会导致同样的结果呢？带着疑惑，去掉了 mix-blend-mode，我又给设置了 3d 的元素添加了一个滤镜：{- mix-blend-mode: lighten;+ filter: blur(1px);}果然，出现了同样的问题，3D 失效：总结一下嗯。那么应该可以初步得到一个结论就是所有这些在渲染时候需要再独立生成一个渲染平面，且包含了 preserve-3d 的属性，都会导致内部的 CSS 3D 失效。暂时我发现的有下述几个属性，都会导致 CSS 3D 失效：mix-blend-modebackground-blend-modefilter其他问题这个 bug 有什么影响额，通常来说，很少会有人在使用 CSS 3D 的同时使用混合模式或者滤镜，这两个属性更多的锦上添花的作用，所以大部分时候，不使用它们就不会有问题， 所以影响不是很大。上文中的 FBO 是什么？上文的 FBO 准确而言是什么我也无法 100% 确定，推测应该是 Frame Buffer Object，帧缓存对象，存在于显存中。帧缓存是一些二维数组和 OpenGL 所使用的存储区的集合：颜色缓存、深度缓存、模板缓存和累计缓存。各种三维场景现在渲染到屏幕上都是先放到一个 FBO 中，可以理解为一张离屛图片，用于加速渲染。Bug 何时会被修复在 chromium bugs 网站，上述 bug 被合并到 issue 575099，并且最终状态是 Untriaged，表示尚未分配优先级，意思是等待某人确定哪个人应该认领并修复该特定错误。所以，短期内可能无望解决。最后感谢耐心读完。更多精彩 CSS 技术文章汇总在我的 Github – iCSS ，持续更新，欢迎点个 star 订阅收藏。好了，本文到此结束，希望对你有帮助 :)如果还有什么疑问或者建议，可以多多交流，原创文章，文笔有限，才疏学浅，文中若有不正之处，万望告知。 ...

标题挺长，踩过坑的应该看的明白。不过限于目前所做产品流程的限制，我并没有解决掉这个问题，只是简单说一下相应的思路。iOS的系统浏览器是Safari，用于Portal认证的则是CNA（Captive Network Assistant），二者的区别在于前者可以打开wachat:这种私有协议头网址，后者无法打开并且限制很多，比如无法使用alert()、无法正常使用window.open()（只能做跳转）等等。问题的症结在于在新版的CNA中是不认wechat:这样的私有协议头的，所以自然也就拉不起来微信。解决时需要引导用户点击a标签<a target="_system"></a>触发Safari，然后再在Safari拉起微信就行了。我目前的portal触发逻辑是，客户端连到wifi上回触发landing，首先返回码设定为401用于触发客户端的portal页面，同时判断客户端UA，如果是部分安卓或iOS就渲染landing实体页（landing.ejs），页面的title和body均为“Success”以作为iOS欺骗（并且会加快从连接到弹出portal的响应时间）；js部分，ios是直接打开认证URL，针对部分安卓则是加了判断document.visibilityState == ‘visible’时触发跳转的事件，用来解决不弹portal的问题。但由于点击按钮之后就直接进到js拉微信认证的流程了（少一步引导拉起微信），所以其实需要部分变更产品流程才行（这个版本暂时没戏）。参考链接：iOS: Open a Welcome Page in Safari, not CNA微信连WI-Fi解决ios无法呼出微信