bug管理规范】的更多相关文章

资源来自:http://wenku.baidu.com/view/ae55b3b565ce05087632132b.html…
1. 禅道简介 禅道是一个基于"敏捷开发"模式的软件开发全生命周期管理软件,在国内的软件开发公司里占据了超过70%的份额,从大公司到小公司,都能适用. 禅道官网:http://www.zentao.net/ 2. Bug管理规范 2.1 角色及人员 一般来说,禅道用于需求/Bug管理方面,在用户角色上,是分为这么几个角色: 1.公司/部门管理层  以下简称"管理层" 2.产品经理 以下简称"产品经理" 职责:负责整个产品生命周期内的全面管理 3.…
1. 禅道简介 禅道是一个基于“敏捷开发”模式的软件开发全生命周期管理软件,在国内的软件开发公司里占据最大的份额,从大公司到小公司,都能适用. 笔者使用禅道多年,根据自己的经验总结了一套Bug管理的方法论,不只是禅道,也可以运用在别的软件开发管理系统上. 2. Bug管理规范 2.1 角色及人员 一般来说,禅道用于需求/Bug管理方面,在用户角色上,是分为这么几个角色: 1.公司/部门管理层  以下简称“管理层” 2.产品经理 以下简称“产品经理” 职责:负责整个产品生命周期内的全面管理 3.项…
1.bug由来 虫子爬进主机引起继电器短路,导致机器故障.真正的缺陷是:主机散热孔少装了块金属丝,这样才能防止虫子爬到主机. 2.什么是bug? bug是缺陷的一种表现形式,而一个缺陷是可以引发多种bug的.软件测试,为了发现软件中的错误而运行软件的过程. Bug评判点 1)软件未达到客户需求文档 的功能和性能 2)软件出现客户需求不能容忍的错误 3)软件的使用未能符合客户的习惯和工作环境(易用性兼容性) 4)软件超出需求文档的范围(需求bug) Bug分类: Defect,缺陷:存在于软件中的…
BUG描述规范 一. 目的与适用范围 1.1 目的 报告软件测试错误的目的是为了保证修复错误的人员可以明确报告的错误,从而有利于分析错误产生的原因,定位错误,然后修正之.因此,报告软件测试错误的基本要求是准确.简洁.完整.规范. 1.2 适用范围 本规范适用于测试过程中对BUG描述的规范与约束. 二. BUG描述规范 1. 描述:简洁.准确,完整,揭示错误实质,记录缺陷或错误出现的位置 描述要准确反映错误的本质内容,简短明了.为了便于寻找指定的测试错误,描述中要包含错误发生时的用户界面(UI).…
关于Git的一些分支管理规范... 一.分支与角色说明 Git 分支类型 master 分支(主分支) 稳定版本 develop 分支(开发分支) 最新版本 release 分支(发布分支) 发布新版本 hotfix 分支(热修复分支) 修复线上Bug feature 分支(特性分支) 实现新特性 Gitlab 角色与项目角色对应关系 Owner(拥有者) Git 管理员 Master(管理员) 开发主管 Developer(开发者) 开发人员 Reporter(报告者) 测试人员 Guest(…
BUG提交规范 1.标题 2.步骤描述 ①.步骤使用序号编排 ②.在特定情况下发生的问题,还需提供准确的前提条件 ③.精准的描述bug产生的路径后,再描述现象 如: >打开客户端进行首页->点击“我的”页面->点击用户头像进入个人资料页 >个人资料页点击头像选择拍照->拍照后点击保存头像 >从个人资料页返回 “我的”页面,查看头像是否更新④.若步骤并不能必现错误,需要说明出现错误的概率(需要多次测试的基础上,若必现则填写100%,若偶现,则执行多次后统计概率填写) 3.…
GIT库代码管理规范 一. 规范要求 1. 每个项目建立单独的GIT库.每个GIT库包括两条线,命名规则如下: 开发线(测试):项目名称_DEV 生产线(正式):项目名称 2. 每条线只允许增量不允许回滚: 3. 每个开发人员拉各自的分支开发,合并前先获取DEV代码,再提交合并: 4. 提交分支时注明:动作类型(新增.修改.删除)+改动明细: 5. 从开发线合并到生产线,由测试工程师负责拉代码/标注更新内容: 6. 由发布工程师将代码部署到服务器: 7. 禁止开发人员访问生产线,生产线不对开发人…
原文地址: http://blog.jboost.cn/2019/06/17/git-branch.html 许多公司的开发团队都采用Git来做代码版本控制.如何有效地协同开发人员之间,以及开发.测试.上线各环节的工作,可能都有各自的流程与规范.本文分享的是作者一直沿用的团队项目Git分支管理规范,希望给有缘阅读的人以参考,如果有更好的实践,也欢迎探讨.交流. 分支管理 创建项目时(一般是服务型项目,工具型或辅助型项目可以简单一些),会针对不同环境创建三个常设分支: develop:开发环境的稳…
1.包命名规范1)说明打包人:姓名拼音首字母小写 dev:开发环境 test:测试环境 pre:预发布环境 prod:正式环境 例如:版本号:1.2.3,说明:第一个数字大版本:变更框架.调整结构时变动,第2个数字模块版本:新增.修改模块时变动,第3个数字迭代版本,修复BUG时变动 每次发布新包的时候,同类环境的包保留最近3个版本的包. 2)安卓包 APP端版本号_环境_build构建次数_日期_时间_打包人.apk AndroidVer1.2.3_test_build1_yyyymmdd_10…