说起程序猿,总绕不开的一个话题就是bug,估计每个程序猿听到某某测试跑过来一脸淫笑的告诉你这个功能有个bug的时候,总有种恨不得掐死他的想法.其实程序猿跟bug的关系,感觉有点像父亲和儿子的关系,自己制造的bug,哭着也要自己解决,就像自己生的儿子,哪天又犯了错,就算气得恨铁不成钢,也要教育他帮他改正一样.好了,扯远了,按照一般程序猿的心理,bug再正常不过了,解决就是了.可是你想过,解决bug的时间和人力成本吗? 1.bug从修复到解决的流程 通常情况下,一个bug从发现到解决的流程应该是这几

一.背景 最近在推进组内流程规范专项建设,从"研发测试流程"."提测规范"."测试准入标准"."bug优先级标准"."测试停止标准"."测试准出标准"和"测试报告模板"7个纬度制定了标准,希望能给看到的人带来一点火花. 二.准入标准 提测后,进入测试环节,需满足以下全部条件: 1)     冒烟测试用例全部通过 2)     主流程可以走通 3)     界面上的功能

结合Git使用Bitbucket进行代码版本管理流程规范与实践   By:授客 QQ:1033553122   目录 目录 1 一. 测试环境 2 二. 新建项目 2 三. 新建公有版本库 3 四. 初始化公有版本库 3 <1> 克隆公有版本库 3 <2> 全局姓名和邮件设置 4 <3> 初始化公有版本库为“裸库” 4 五. 项目权限配置 6 六. 用户和组管理 7 七. 公有版本库权限设置 9 八. Fork私有版本库 11 九. 开始第一次迭代开发 13 1. 功能

最近参加了一个比赛,然后看到队友编程的代码,我觉得真的是觉得注释和命名规范的重要性了,因为几乎每个字符都要咨询他,用老师的话来说,这就是命名不规范的后续反应.所以此时的我意识到写一篇关于注释程序的重要性了,因此特地的写一篇文章规范自己,也帮助新手入门. (这篇文章已经是我自己更新的第三遍了,第一次叫浅谈注释的重要性,那时候我刚入门不久:学着学着我会发现变量名也很重要,第二次是规范变量名:这次我又改了,我觉得不止是这些东西,从长远的来说,编程以后就是自己的工作,或者说工具,所以遵循一套编码规则很重

前言 我们这些初学者,目前要做的就是遵守代码规范,这是最基本的,而且每个团队的规范可能还不一样,以后工作了,尽可能和团队保持一致,目前初学者就按照官方的要求即可 新人进入一个企业,不会接触到核心的架构级别的代码,这些东西大多数有大佬写好了.所以新人要做的就是维护别人的代码,因此代码的可阅读性,良好的可维护性是最重要的,关键的影响性能的代码,不需要我们写,慢慢的写得多了,积累的多了,看几个优秀的代码就会了了,所以,初学者前期关注代码规范,不写bug,就ok. 学习软件开发目录的规范,为了让自己理解

BUG描述规范 一. 目的与适用范围 1.1 目的 报告软件测试错误的目的是为了保证修复错误的人员可以明确报告的错误,从而有利于分析错误产生的原因,定位错误,然后修正之.因此,报告软件测试错误的基本要求是准确.简洁.完整.规范. 1.2 适用范围 本规范适用于测试过程中对BUG描述的规范与约束. 二. BUG描述规范 1. 描述:简洁.准确,完整,揭示错误实质,记录缺陷或错误出现的位置 描述要准确反映错误的本质内容,简短明了.为了便于寻找指定的测试错误,描述中要包含错误发生时的用户界面(UI).

芯盾时代_Devops_Docker操作说明及使用规范 北京芯盾时代科技有限公司 2019年1月 修订记录 版本号 修订人 修订日期 修订描述 v0.1 芯盾 2019/1/15 初次创建 v0.2 芯盾 2019/1/16 5.4增加compose文件限制内存CPU,启动顺序限定,取消links v0.3 芯盾 2019/1/17 增加1.3docker基础知识,更新5.5stack启动命令 v0.4 芯盾 2019/1/17 增加7章端口规划 v0.5 芯盾 2019/1/19 补充数据库提

场景描述 当一个项目已经上线,同时又在原有基础上新增功能模块,于是乎就要在原有代码的基础上进行开发,在新增模块功能的开发的过程中,项目发现了一个紧急Bug,需要修复.应对这种情况,有以下两种解决方案: # 方案一:stash stash 用于将工作区发生变化的所有文件获取临时存储在“某个地方”,将工作区还原当前版本未操作前的状态:当bug修复完毕后,可将临时存储在“某个地方”的文件再次拿回到工作区(此方案不常用,故不赘述): 方案二:branch branch 称为分支,默认仅有一个名为 mas

我们在前面已经介绍了coding.net和本地git的基本用法. 但是多人协作开发时情况会复杂得多,所以我们最好有一些规范来保证项目多人开发顺利进行. 比如说 规范一 master代码分支  需要开启代码保护,也就是提交到master分支或者其他分支与master分支合并必须经过审核. 规范二 不能直接在master代码上直接进行开发,最好先更新master最新的代码之后 在当前代码基础上新建为一个新的分支,完成功能后,提交到新分支,最后把新分支  合并请求到  master即可. 本章主要记录

1. 命名规范 (1).变量命名规范 1.变量使用驼峰命名法 禁止使用拼音或者拼音加数字 2.变量也应具有描述性,杜绝一切拼音.或拼音英文混杂的命名方式 3.变量包数字.字母和下划线字符,不允许使用其他字符,变量命名最好使用项目 中有据可查的英文缩写方式, 尽可以要使用一目了然容易理解的形式: 4.变量以字母开头,如果变量包多个单词,首字母小写,当包多个单词时,后面 的每个单词的首字母大写. 例如 :$itSports 5.变量使用有效命名 例如评论:$commentArr 6.变量属性标记清楚

1,Action中get,set方法的使用流程? 前台form中有一个<input type="text" name="username"/> 如果传到action.在action中应该有一个属性,名字也叫username:而且这个username有get/set方法,其中get方法的命名必须为getUsername,其中set方法的命名必须为setUsername.这里方法名称按java Bean的规定.注意不是setUserName和getUserN

故事背景 前段时间上线了一个从Oracle迁移到TiDB的项目,某一天应用端反馈有一个诡异的现象,就是有张小表做全表delete的时候执行比较慢,而且有越来越慢的迹象.这个表每次删除的数据不超过20行,那为啥删20行数据会这么慢呢,我们来一探究竟. 问题排查 根据应用端提供的表名去慢查询里面搜索,确实发现了大量全表删除的SQL: 从列表中找一条来看看具体的时间分布: 可以发现绝大部分时间都花了Coprocessor阶段,这个阶段表示请求已经被下推到了TiKV执行,我们继续看看在TiKV里面都做了

一. 官方登录时序图 二. 简单理解 这里仅按照官方推荐的规范来 0. 前置条件 一共有三端: - 微信小程序客户端 - 第三方服务器端(自己搭建) - 微信服务器端 1. 客户端获得code,并将code传给第三方服务端 微信小程序端调用wx.login,获取登录凭证(code),并调用接口,将code发送到第三方客户端 2. 第三方服务端用code换session_key和openid 小程序端将code传给第三方服务器端,第三方服务器端调用接口,用code换取session_key和ope

BUG:软件系统中存在的可能导致系统出错.失效.死机等问题的错误或缺陷. 描述一个缺陷,需要以下核心要素 标题:用简洁的话描述该缺陷,主要让开发知道这是一个什么样的缺陷 参数设置:Bug的类型(功能/性能/界面等),Bug的严重程度.Bug优先级(是否需要立即修复等).所属项目模块.项目的版本号 详细描述:便于开发重现和定位缺陷 主要包括: 1.测试环境:如:浏览器及版本号,操作系统,手机app或微信公众号测试明确手机型号,版本号,微信版本号等 2.测试数据:用户名和密码,及相关的业务数据 3.

SVN代码管理与版本控制 by:授客 QQ:1033553122   欢迎加入软件性能测试交流群(QQ群):7156436   目录 一. 二. 三. 四. 五. 六. 七. 一. 创建根目录 创建一个空文件夹,例如 svn,作为所有版本库的根目录 [root@localhost ~]# mkdir -p /svn/ 二. 创建版本库 进入svn目录,创建版本库 [root@localhost ~]# cd /svn/ [root@localhost svn]# svnadmin create

一.提单模板 标题:[项目组][模块][子模块][发生原因]问题简要描述描述:[预置条件] 有就写清楚,没有就写无[操作步骤]1.XXXXX2.XXXXXX3.XXXXX[实际结果] XXXXX[预期结果] XXXXXX[问题发生时间]——偶现的问题必须要写,必现问题可以不用写[设备信息]机器人SN号[复现概率]3/3[备注]如果有一些其他信息,可以写在这里 二.偶现bug 在上述提交bug要求上添加:1.填写复现概率(30次以上),寻找规律协助开发定位2.截图3.记录时间点4.记录设备编号5.

欢迎关注我的公众号,了解更多的测试知识:[软件测试经验与教训] 一一BUG描述基础知识 Bug标题中需包含Bug的具体位置并以[]标注 举例:[模块-子模块-页面]XXXXXXXXXXXX Bug标题中切勿出现错别字 错误示例: 奔溃(崩溃),电击(点击),登陆,(登录),重置(充值),现实(显示) 当所发现Bug前提条件为空时,需要填无.特殊条件下的Bug必须详细描述产生Bug的前提. 示例:只有在使用附件中的图片(大图片:60M)时,会出现此Bug. 描述复现步骤中的页面切换为避免出现描述不

1) 项目分析 2) 项目经理分工协作 程序就具体流程: 1: 按项目名称: 建git, 数据库, 线上测试虚拟机 2: 按项目经理分配的大的模块. 自行划分工作阶段 a: 划分为小的模块 b: 预估时间, 汇报每日完成工作量 c: 代码开发完成 d: 项目经理 review Coding (如果有问题需修改) e: 测试代码 3) 线上统一测试

资源来自:http://wenku.baidu.com/view/ae55b3b565ce05087632132b.html

手动修改冲突之后,git add . git commit ,git push

Svn服务在win2008 搭建 1:svn服务的原理与架构 1.Svn服务可以理解为加强版的ftp文件服务器, svn采用HTTP协议的方式进行文件传输 2.服务端安装好后,普通用户也需要下载一个client端来进行同步服务端的文件到本地 3.根据相应的权限指定特定的用户进行export输出(下载),或import输入(上传) 4.服务端安装完成后首先就是创建Repositories(库){存储所有的文件用的} 在库中创建相应的目录(folder)右击设置相应权限并且应用 5.再者就是在use