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，此外还有鱼骨图等著名工具可用。为了控制篇幅，本文略去对这些方法的介绍，只通过一个实例来说明在实际的缺陷分析中，我们是如何产生深度洞见的。 某缺陷描述了如下的场景（该实例在不影响问题说明的情况下做了适度抽象）： ...