精华内容
下载资源
问答
  • Bug流程

    2010-09-29 14:09:00
    Bug的处理 开发组长/经理 每天对Bug进行分配,标注处理意见,给定优先级(发版前必须三方:需求、开发、产品共同确定)。问题分配时,应尽可能将咨询类、理解错误类等问题处理掉,而不是留给开发人员。...
    Bug的处理

    开发组长/经理
    每天对Bug进行分配,标注处理意见,给定优先级(发版前必须三方:需求、开发、产品共同确定)。问题分配时,应尽可能将咨询类、理解错误类等问题处理掉,而不是留给开发人员。有可能是需求的问题,分配给需求人员。定期对Bug库分析,找出常出错的模块,进行代码审查

    开发人员
    分析Bug,写出问题原因,修改Bug;实行Bug优先原则,严重程度B-Major类或紧急程度3-High类以上(包含)bug5个或5个以上,停止新功能的开发。

    需求人员
    解释需求,给出处理意见,将Bug库中的建议整理成需求文档。评审确定后列入开发计划

    测试人员
    不参与问题的优先级的定位,只用Bug级别反映Bug的严重程度。验证Bug是否已被解决

    测试组长/经理

    审核测试人员提交的Bug。定期对Bug库进行分析,描绘出曲线图等,报告现状、预测趋势。在测试总结报告中给出意见

    产品人员
    可以对优先级和处理意见等进行审核,如果有意见,和项目组商量定夺

     

    Bug状态(Status):指缺陷通过一个跟踪修复过程的进展情况。包括NewOpenReopenFixedClosedRejected

    New

    为测试人员新问题提交所标志的状态。

    Open

    为任务分配人(开发组长/经理)对该问题准备进行修改并对该问题分配修改人员所标志的状态。Bug解决中的状态,由任务分配人改变。对没有进入此状态的Bug,程序员不用管。

    Reopen

    为测试人员对修改问题进行验证后没有通过所标志的状态;或者已经修改正确的问题,又重新出现错误。由测试人员改变。

    Fixed

    为开发人员修改问题后所标志的状态,修改后还未测试。

    Closed

    为测试人员对修改问题进行验证后通过所标志的状态。由测试人员改变。

    Rejected

    开发人员认为不是Bug、描述不清、重复、不能复现、不采纳所提意见建议、或虽然是个错误但还没到非改不可的地步故可忽略不计、或者测试人员提错,从而拒绝的问题。由Bug分配人或者开发人员来设置。

    Bug严重级别(SeverityBug级别):是指因缺陷引起的故障对软件产品的影响程度。由测试人员指定。

    A-Crash

    错误导致了死机、产品失败(“崩溃”)、系统悬挂无法操作;

    B-Major

    功能未实现或导致一个特性不能运行并且不可能有替代方案;

    C-Minor

    错误导致了一个特性不能运行但可有一个替代方案;

    D-Trivial

    错误是表面化或微小的(提示信息不太准确友好、错别字、UI布局或罕见故障等),对功能几乎没有影响,产品及属性仍可使用;

    E-Nice to Have(建议)

    建设性的意见或建议。

    Bug优先级(Priority):指缺陷必须被修复的紧急程度。由Bug分配者(开发组长/经理)指定。

    5-Urgent

    阻止相关开发人员的进一步开发活动,立即进行修复工作;阻止与此密切相关功能的进一步测试

    4-Very High

    必须修改,发版前必须修正

    3-High

    必须修改,不一定马上修改,但需确定在某个特定里程碑结束前须修正

    2-Medium

    如果时间允许应该修改

    1-Low

    允许不修改

    功能模块(Subject)TD中需在Test Plan页中定义好Subject,才能在Defects页中使用。

    问题描述附件附图 请参见后面第四部分‘Bug描述要求’的有关内容。

    处理意见:开发组长/经理(或具体Bug分配人员) 在审核新Bug时、将Bug分配给开发人员解决前,需要给出该Bug的处理意见。

    Fixable

    可修改。表示Bug可以被修复或更正

    Duplicated

    重复。表示该Bug已经被其它测试人员找出来了(‘纯粹’重复),或者开发认为原因是相同的(但从测试来看,认为出现的地方有所不同、表现有所不同等)

    Postponed

    延后。由于时间、进度、重要程度或者技术/需求等方面的原因,认为不能解决、须延期解决、或者本版不做留待到后续版本解决的Bug
    (注:因‘Bug状态’字段中也有该值,根据各组各自使用情况,可以只保留一个,或者开发/测试各有侧重地使用这两个Postponed

    By Design

    因设计结构问题无法修改。测试人员认为是Bug,不符合逻辑,也不符合用户的要求,但开发人员则认为是按照设计做的、只能如此处理,否则修改代价太大

    Cant Reproduce  

    不可复现。不能重现(如因Bug出现的环境重现不了了),或以前出现的某个Bug自动消失了(可能是在处理其他Bug的时候把这个Bug 一并修复掉了)。
    (注:因TD本身亦带有‘是否复现(Reproducible)’字段,根据各组各自使用情况,可以用它来标识,或者不用它而在‘处理意见’字段中用该值标识出)

    Disagree With Suggestion

    不同意所提意见或建议,不采纳

    Not Error

    不是问题。测试人员提错了

    Wont Fix

    这个Bug是一个错误,但还没有重要到非要更正不可的地步,可以忽略不计

    说明:
    1. 定为DuplicatedBug,必须注明和XXXbug重复
    2. 测试人员对标明为DuplicatedBug复测,需要XXXBug修改后方可进行
    3. 定期回顾Can't Reproduce,Postponed
    4. 定期整理By Design

    其它一些字段(及所定义的枚举值)的定义解释,供有需要用到的组参考:

    测试状态(TestState:新提交的Bug定位标准。由测试人员指定。一般有8个(提交Bug时给出)

    1New Defects(或写成Defect

    Bug

    2Second Defects(或写成SB

    复测时新出现的Bug

    3Faculative

    偶发性

    4Reappear

    原来修改过的问题又重新出现

    5By Requirement

    需求要求但没有做的功能

    6Suggestion

    需求需要完善

    7Differ With Requirement

    与需求不一致

    8By Design

    设计要求但没有做的功能

    复测状态(ReTestState):复测时给出的状态,测试人员对于经过验证的Bug应按以下几种标准进行定位。由测试人员指定。一般有1OK2PD3DV4NB5NR6AR

    OK

    正确

    PD

    此问题悬而不决

    DV

    有错误可以暂时不考虑

    NB

    不是错误

    NR

    不能复现的错误

    AR

    需求不明确

    问题定位:

    Calculate_error

    计算错误,指计算过程中、计算结果错误。

    Data_error

    数据错误,指非计算结果类的数据错误。

    Graphics_error

    图形错误,指绘图、图形显示、图形编辑时发生的错误。

    Interface_error

    界面错误

    Requirement_error

    需求错误

    Function_error

    功能错误

    Unknown_error

    未知错误

    缺陷来源(Source):指引起缺陷的起因。

    Requirement

    由于需求的问题引起的缺陷

    Architecture

    由于构架的问题引起的缺陷

    Design

    由于设计的问题引起的缺陷

    Code

    由于编码的问题引起的缺陷

    Test

    由于测试的问题引起的缺陷

    Integration

    由于集成的问题引起的缺陷

    类型(Type):是根据缺陷的自然属性划分的缺陷种类。

    F- Function

    影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。并且设计文档需要正式的变更。如逻辑,指针,循环,递归,功能等缺陷

    A- Assignment 

    需要修改少量代码,如初始化或控制块。如声明、重复命名,范围、限定等缺陷

    I- Interface 

    与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。

    C- Checking

    提示的错误信息,不适当的数据验证等缺陷。

    B- Build/package/merge

    由于配置库、变更管理或版本控制引起的错误

    D- Documentation 

    影响发布和维护,包括注释。

    G- Algorithm 

    算法错误。

    U- User Interface

    人机交互特性:屏幕格式,确认用户输入,功能有效性,页面排版等方面的缺陷

    P- Performance

    不满足系统可测量的属性值,如:执行时间,事务处理速率等。

    N- Norms

    不符合各种标准的要求,如编码标准、设计符号等。

    (以上依各组实际情况可以作适当调整)

    项目组各角色在Bug库中的权限

    管理员:全部权限

    测试组长/经理:全部权限

    测试人员:可添加Bug、不能删除Bug、可添加注释评论(R&D Comments)、不可修改他人所提Bug、可调整:Bug概要(题目,Summary)、问题描述、附件附图(Attachments)Bug状态、Bug级别、测试版本、测试产品、功能模块、测试状态、问题定位、复测状态、注释评论(R&D Comments)、复测人、复测日期、修改人

    开发人员/需求人员:不能删除Bug、可添加注释评论(R&D Comments)、可调整:注释评论(R&D Comments)、是否复现、Bug状态(不过无法直接标为closed)、问题描述、处理意见、待测版本、修改人、修改日期。可添加Bug

    开发组长/经理/需求经理:除了开发人员的权限,还可调整:优先级别、责任人、Bug概要(题目,Summary) 、附件附图(Attachments)

    项目经理:可添加Bug、可添加注释评论(R&D Comments)、可修改字段:Bug概要(题目,Summary) 、问题描述、附件附图(Attachments) Bug状态(不过无法直接标为closed)、修改人、优先级别、问题定位、处理意见、注释评论(R&D Comments) 、是否复现、责任人、待测版本。也可删除Bug,但要与测试组长/经理协商。

    不属于项目组成员的其他人如研发中心经理组成员等,有必要查看TD库的话,可分配给其帐号及查看的权限。

    Bug描述要求

    Bug描述的要求为分类准确、叙述简洁、步骤清楚、有实例、易再现、复杂问题有据可查(截图或其它形式的附件)。测试组长/经理把关,以开发人员的角度来审查Bug描述,看其是否描述清楚了Bug,不好描述的把工程文件或截图作为附件提交。具体要求为:

    • 问题描述一般格式:问题描述时,建议分几步描述:模块或功能点=>测试步骤=>期望结果=>实际结果=>其它信息,可依实际情况调整;
    • 单一:尽量一个报告只针对一个软件缺陷,报告形式应方便阅读。在主报告之后应注明不同的条件;
    • 简洁:每个步骤的描述应尽可能简洁明了。只解释事实、演示和描述软件缺陷必要的细节,不要写无关信息;
    • 再现:问题必须在自己机器上能复现方可入库(个别严重问题复现不了也可入库,但需标明);
    • 复杂的问题应附截图补充说明或直接通知指定的修改人;考虑到网络数据传输效率,截图的文件格式建议用JPGGIF,不建议用BMP;抓图可用TestDirector自带的功能,亦可用HyperSnap之类的专用抓图工具。
    • 报告中不允许使用抽象词句:比如“有错误”之类;
    • 有关操作系统特征问题:应在不同操作系统上进行操作,看是否能重现,并在Bug报告中标识;
    • Bug描述示例:

    例一
    河北98土建标准换算
    操作
    1.输入9-24
    2.F8
    3.F8输入10
    期望结果:进行换算
    实际结果:提示“输入的厚度应大于20

    例二(模块或功能点也可在‘功能模块’字段中规定,则Bug描述中就不必写了)
    操作:
    1.打开新建向导;
    2.在“新建”中的“项目名称”中输入>80个字符;
    3.点击“下一步”
    期望结果:“项目名称”应<=80个字符,输入大于80个字符,点击“下一步”应有错误提示
    实际结果:进入“比重调整”界面

    例三(程序员知道期望结果的情况下)
    云南98土建
    操作:
    1.输入13-170
    2.F5
    3.F5中修改3240008的名称, 处于编辑状态
    4.到人材机,再回来
    实际结果 F5中变白板
    :若3不处于编辑态切换则正常

    例四(建议、需求类)
    功能:预算页,子目排序后可恢复原顺序
    用途:用户误操作后可复原

    注:所有项目采用TestDirector进行Bug管理,该工具能从测试步骤自动生成Bug报告,因此对于Bug描述要求在测试方案用例设计(在Test Plan页中)阶段就可以进行控制。

    附:好的Bug报告应满足以下几方面的要求:

    • 结构清晰
    • 复现故障再写报告
    • 隔离Bug:更改条件复测
    • 归纳:是否其他模块也有相同的Bug
    • 比较:其他测试用例是否使用到此Bug
    • 总结:报告的开头有Bug的总结
    • 精简:不要有多余的步骤和语言
    • 无歧义:语言明确
    • 中立:无批评性语言
    • 讨论:将要发出的报告送其他测试人员讨论

    小结

    • 通过专业的技术测试出精确的Bug
    • 通过准确的文档报告Bug
    • 通过良好的沟通使Bug尽快解决。
    展开全文
  • bug流程设计图

    2014-02-19 16:49:00
    bug流程设计图,对bug使用申报过程的流程介绍
  • 软件测试BUG流程

    2011-11-23 22:05:48
    软件测试BUG流程图,软件测试BUG流程图,软件测试BUG流程图,软件测试BUG流程图,
  • 软件测试bug流程

    2012-02-24 09:11:15
    TD使用流程、软件测试bug流程
  • BUG流程分析

    2014-07-31 15:15:12
    关于BUG流程相信大家都已经很熟悉了,并且用起来也得心应手,在此不再赘述。以下对BUG有一些小小的建议,主要针对我们日常工作中没有注意到的地方说的,建议虽小,但要重视噢。  对于研发经理:  当一个BUG被你...

     关于BUG流程相信大家都已经很熟悉了,并且用起来也得心应手,在此不再赘述。以下对BUG有一些小小的建议,主要针对我们日常工作中没有注意到的地方说的,建议虽小,但要重视噢。

      对于研发经理:

      当一个BUG被你审核通过,在派给开发人员时,你应该将BUG的状态改为“打开”。

      审核BUG时你有最高权限,可以审核BUG的所有信息是否正确,所以最好重新审核一下我们提交的BUG严重程度,你有权修改哦。还有类型也可以修改的。

      对于软件工程师:

      请开发人员修正后,注明修改后达到的功能效果以及可能影响到哪些其他的功能模块,还有拒绝或延期的理由。同时最好写上解决的方式或非正常解决问题的原因,对于我们来说这些积累是一笔很大的财富。

      如果你正陷入让测试人员使用bug管理库的苦恼中,你只要不用其他方法接受bug报告。如果你的测试人员习惯将bug报告用邮件的形式发给你,你只需用一个简短的消息回复他们:“请将它们输入到bug库中,因为我无法追踪邮件。”

      对于测试人员:

      请测试人员提交新错误时,尽量用最简洁的语言最清晰的描述出BUG的出处、操作步骤、现象、(建议),并尽量截图。

      尽量减少重现的步骤以达到用最少的步骤来重现问题;这对编程人员来说是很有帮助发现问题根源的。

      当你的bug报告以“not repro(不可重现)”打回给你时,先检查一个步骤是否有遗漏或清晰,再去找编程人员。编程人员通常是在无法用bug报告中的步骤重现bug时才选择这个选项。

      不要使用完全的大写形式,那样会让人感觉象控诉。不要使用感叹号或其他表现个人感情色彩的词语或符号。

      不要使用含糊的词语(例如,好像,似乎)来描述发现的现象。

      在提交BUG的标题第一行写上错误的总结是非常关键的。这要求测试人员编写的报告要能够吸引读者,引起他们的注意,并使和管理层的沟通清晰。

      再次强调,在bug report的初稿完成后,测试人员应该反复阅读它,集中剔除那些没有关系的步骤或词语。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤而消磨报告欢迎程度的无穷唠叨都不是bug report的目标。

      测试人员在精简空话的同时或其之后随即应该再仔细检查报告是否有会产生误解的地方。测试人员应该尽量避免使用模糊的,会产生歧义的和主观的词语。目标是使用能够表述事实,清楚的,不会产生争执的词语。

      大家都要注意的地方:

      当你发现一个BUG,或者正在修改BUG时,请考虑如下问题:

      1. 同一软件中的相似功能是否有相同的问题?

      2. 其他的浏览器是否有相同的问题?

      3. 其他的软硬件配置是否有相同的问题?

      4. 其他的区域(locales)是否有相同的问题?

      5. 不同的安排设置是否有相同的问题?

      6. 以前的版本否有相同的问题?

    展开全文
  • 测试BUG流程管理规范

    2016-07-20 09:32:05
    BUG单描述模板,开发和测试工作配合流程
  • bug流程&提交规范

    千次阅读 2016-03-23 14:04:44
    1 缺陷处理状态转换流程图 说明: 1、 有效bug数是指出现过fixed,deferred状态的bug数。 2、 bug的最终状态是closed 、deferred。 3、 明确认为不是缺陷的,则状态可置为rejected。 4、 ...

    1 缺陷处理状态转换流程图

    说明:

    1、 有效bug数是指出现过fixed,deferred状态的bug数。

    2、  bug的最终状态是closed 、deferred。

    3、  明确认为不是缺陷的,则状态可置为rejected。

    4、  确认是缺陷,但本次不进行修复的,则PM在注释内写明原因,由测试负责人deferred。

    5、  deferred后续知道已经修复的,由测试负责人或产品线负责人直接closed,并添加备注说明;

    6、  deferredàopen,一般由SQA根据后续跟踪情况来置这个状态的变化,表明这个bug又开始重新修复了。

    也可以由下一次负责测试该bug的测试人员来打开。

    7、  rejectedàdeferred, 由产品线负责人或项目测试负责人置状态的变化,并添加备注说明原因;

    8、  出现需求问题或架构问题时,开发人员将该缺陷 assign to 给相应的需求和架构人员 进行 fixed。

    9、  如何批量修改QC里的字段:在缺陷页面,通过过滤器先把目标数据过滤出来。通过“编辑”- “替换”功能来进行批量数据修改。 

    10、    缺陷状态转换权限:

    角色组 tester1(测试成员、安全工程师、SQA)  tester2(测试负责人、产品线负责人)  Dev(Dev、PM、RA、UI、PD、DBA) 
    状态转换 new-open deferred-open open-fixed
      fixed-updated update-reopen open-rejected
      fixed-closed rejected-reopen fix-updated
      fixed-reopen rejected-deferred reopen-fixed
      update-closed fixed-reopen reopen-rejected
      update-reopen fixed-updated
      rejected-reopen new-open
      rejected-closed $any-closed
      deferred-open

        7、详细QC模块及bug状态转换权限设置如附录五:QC权限设置说明

    2缺陷录入页面

    Test权限提交:

      

    Codereview权限提交:

    3 缺陷处理页面

         进行缺陷修复或改变状态时,系统会提示缺陷必填项,如下图。此类必填项的选值需要在项目组内达成意见一致。建议在开发修复处理,存在分岐时,在项目组内讨论决定。

      

    *缺陷引入阶段:*用于缺陷溢出率的统计分析(缺陷溢出率:各阶段引入的缺陷遗漏至之后的阶段被发现的比率),该指标可应用于缺陷预防措施的思考改进。同时体现测试向前(该测试向前不仅指QA向前,更包含开发、PD的测试向前)

    *缺陷分层:*用于代码层次的缺陷率统计。可以关注单元测试质量、接口测试的质量层次分析。

    *单元测试可避免:*可作为是否需要补充单元测试case的依据。

    *缺陷性质:*Bug产生的根因进行分类统计,实现有效预防措施制定的依据。

    4填写字段含义说明

    • 缺陷录入信息:
    字段名称 是否必填 类型 默认值 字段值
    Project Y List
    项目名称,同步于Aone。规则为:项目名称的第一个拼音字母(大写)_项目名称
    Subject Y List
    来源于“测试计划”模块。
    Assigned To Y List
    指定修复人员。
    缺陷严重等级 Y List
    见附录一
    Priority N List
    优先级,取值如下: 
    1-       Low 
    2-       Medium 
    3-       High 
    4-       Very High 
    5-       Urgent
    缺陷类型 Y List
    见附录二
    缺陷细分 Y List
    见附录二
    缺陷状态 Y List Open New/open/fixed/rejected/reopen/closed/deferred
    系统 Y List
    修改代码的系统
    发现方式 N List 用例执行 用例执行;UI自动化测试;单元测试;接口测试;codereview;性能测试;随机测试
    缺陷发现阶段 Y List
    需求分析;程序设计;程序编码;冒烟测试;功能测试;分支回归;Release回归;预发布验证;集成测试阶段;
    • 缺陷处理信息:
    字段名称 是否必填 类型 默认值 字段值
    缺陷引入阶段 Y List
    1-       FRD引入; 
    2-       DEMO引入; 
    3-       设计引入; 
    4-       编码引入; 
    5-       历史遗留; 
    6-       解决冲突引入; 
    7-       发布过程引入; 
    8-       bugfix引入
    缺陷分层 Y List
    1-       前端 
    2-       Web 
    3-       Biz/dal 
    4-       Biz/service 
    5-       Biz/Util 
    6-       二方库 
    7-       其他
    缺陷性质 Y List
    见附录三
    单元测试可避免 N List N Y/N

    附录一 缺陷严重等级

    等级定义:  
    Urgent (V级) 紧急(系统和应用级错):
      无法启服务;程序crash死机;出现致命错误(505)等大面积不能测试。
    Very High(IV级) 非常高(模块级、主干功能级、性能、安全漏洞级):
      模块功能未实现(主干功能有误),导致系统出现严重问题或致命错误,影响产品的使用;
    III 分支功能出现错误。
      错误导致了一个特性不能运行但可有一个替代方案或暂不影响其他功能测试;
    II 错误是表面化或微小的,对功能几乎没有影响,产品及属性仍可使用;
    I 建设性的意见或建议

    附录二 缺陷类型和缺陷细分

    缺陷类型 缺陷细分 名词解释 举例说明
    1-功能缺陷 1-1 权限错误 用户权限配置错误,或页面对权限处理错误  
      1-2 功能遗漏/判断条件缺失/缺省值错误 未实现功能;对某一条分支条件判断缺失;页面的缺省值不正确等  
      1-3 字段校验错误 页面控件的异常校验错误;
      1-4 算法逻辑错误 功能实现的逻辑存在漏洞;判断正常的情况下,逻辑处理异常等
      1-5 老数据兼容问题/未做脏数据判断/数据空值未判断

      1-6 未判断空指针异常

      1-7 转义问题 Html字符转义出错 如&、</td>特殊字符页面展示时未做处理
      1-8 并发处理错误 对并处的处理没有控制 如“查询”按钮的控制,在返回结果前未控制不可点击; 
    数据判断逻辑只在入口处控制,未在真正执行处理时控制;
      1-9 SQL错误 SQL写错了。
    其他 其他不能归类,纯粹手误等。
    2-UI缺陷 2-1 js/css错误

      2-2 URL/文案错误

      2-3 实现方式与需求不符

      2-4 浏览器兼容错误

      其他

    3-需求缺陷 3-1 UC&FRD缺陷

      3-2 Demo缺陷

      3-3 需求变更未传达清楚

      其他

    4-易用性建议 4-1 页面显示 页面显示的建议(而不是和需求不符合的点)
      4-2 用户操作

      其他

    5-性能缺陷 5-1 内存溢出

      5-2 性能未达需求

      5-3 sql执行效率差

      5-4 性能优化建议

      其他

    6-数据库缺陷 6-1 建表/字段/SEQ/INDEX/trigger等遗漏

      6-2 同步策略错误

      其他

    7-安全漏洞 7-1 XSS(跨站脚本攻击) 用户的输入未做任何处理直接原样显示在页面。
      7-2 CSRF(跨站请求伪造) 通过伪造请求攻击用户或服务器。
      7-3 SQL注入 将用户的数据直接拼装为SQL语句
      7-4 Access Control(权限漏洞) 未对用户身份进行权限验证,越权操作。
      7-5 Url Redirect(跳转漏洞) 对用户输入的url跳转未做任何处理。
      7-6 上传下载漏洞 上传时未检查文件类型、上传时未检查文件内容
      其他

    8-平台缺陷 平台缺陷 由于平台系统而引发的缺陷

    附录三 缺陷性质(参考)

    缺陷性质 名词解释 举例
    需求设计不明/需求设计错误 需求或设计本身不明确或者错误 群发邮件时无退订链接字段,不能增加退订链接,无法群送邮件 
    需求考虑不全;已经修改。 
    场景考虑不全 对涉及影响的场景范围考虑不全,缺漏部分场景的处理 当前合同为直销开户时,电销机会退回, 限定机会为and status = 'assigned'会有问题, 如果机会在公海或者经理库时无法退回, 应改成只有是有效机会,就应该退库
    需求理解错误 对需求的理解错误,或产生歧义 如果是签单电销和当前机会跟进电销不一致时, 机会是cancel, 正确的应该是succeed
    文案错误 页面显示处理不正确,错别字,提示不友好,CSS错误等。 1、 编辑预约页面按钮没有国际化  
    2、 小记修改页面嵌入survey的页面不会自适应
    环境配置/SQL脚本未运行/脏数据 环境配置项(antx.p)值不正确,或者SQL脚本没有在数据库部署运行,或者测试的脏数据(线上不可能存在的数据) Aone上提交的antx.p配置项值错误,或者测试环境配置错误等
    测试代码未清理/废弃代码删除/冗余处理 用于测试调试的代码未清理。或者对废弃代码进行删除时未评估到影响范围。或者存在冗余代码的现象。
    可读性/代码风格/命名不规范/注释错误 代码的可读性不高,风格不统一,命名不符合规范。注释存在错误。 1.字符串比较,建议用系统提供的StringUtil.equals(str1, str2),避免存在空字符串抛异常。 
    2. “查找到member_id+site与客户表的member_id+domain一致的数据并返回”和“查找到site和domain一致的那条数据”这部分代码重复程度高,建议可以封装在同一个方法内。
    性能隐患 代码逻辑功能正确,但存在性能问题。
    合并冲突解决 分支合并时存在冲突,解决过程中出现错误。
    重复缺陷 测试同学对同一根本问题提出的多个缺陷 1、0088.自动录入获取时,未获取到方案联系人信息 
    2、0088.自动录入获取时,未获取到KP联系人信息 
    原因:跟付冰确认 点击'自动录入'时也未获取到方案联系人信 获取信息的方法不改,还是以前的获取av信息 

    上述两个缺陷应为同一根因缺陷。其中一个为重复缺陷。
    其他 上面未包含的其他各类原因。
    展开全文
  • Git之修复Bug流程

    2018-07-15 11:08:00
    当一个项目已经上线,同时又在原有基础上新增功能模块,于是乎就要在原有代码的基础上进行开发,在新增模块功能的开发的过程中,项目发现了一个紧急Bug,需要修复。应对这种情况,有以下两种解决方案: # 方案一:...

     

     

    场景描述

           当一个项目已经上线,同时又在原有基础上新增功能模块,于是乎就要在原有代码的基础上进行开发,在新增模块功能的开发的过程中,项目发现了一个紧急Bug,需要修复。应对这种情况,有以下两种解决方案:

    # 方案一:stash

           stash 用于将工作区发生变化的所有文件获取临时存储在“某个地方”,将工作区还原当前版本未操作前的状态;当bug修复完毕后,可将临时存储在“某个地方”的文件再次拿回到工作区(此方案不常用,故不赘述);

    方案二:branch

           branch 称为分支,默认仅有一个名为 master 的分支;一般开发新功能流程为:开发新功能时会在分支dev上进行,开发完毕后再合并到 master 分支。

     

    # Bug修复流程如下:

     

    -------------------------------------------------------------

    作者:罗穆瑞

    转载请保留此段声明,且在文章页面明显位置给出原文链接,谢谢!

    ------------------------------------------------------------------------------

    如果觉得这篇文章对你有小小的帮助的话,记得在右下角点个“推荐”哦,博主在此感谢!

    ------------------------------------------------------------------------------

    展开全文
  • 1.首先进入登录页面,输入用户名admin、密码123456 2.登录以后点击新建bug 3.先进行简单的输入,点击保存 4.则会显示如下效果 观察首页,现在bug已经创建提交成功 ...
  • 笔者总结了工作中遇到bug的处理流程,如下:   一、bug确认 分配到一个bug后,要根据bug单号到bug管理系统查看该bug的详细信息。 1. 查看问题现象,了解问题 2. 查看软件版本和操作流程,检查当前版本和操作...
  • 由于是突然想到要记录点什么,所以今天看到什么就写什么,希望对自己和一起加油的伙伴一点帮助。... bug常见的分类:  calss A:  代码错误  设计缺陷  界面优化  配置相关  安装部署...
  • 张经理是一家成熟互联网企业的测试主管,这段时间要为一个新成立的项目...约60%的测试工程师,都提到,在BUG修改意见和开发人员有分歧时,说服对方修复bug是一件有难度的事情。 那么今天我们就聊一聊,当测试
  • 图1 流程草图 图2流程设置及说明 图1 图2 各流程节点说明 1用例Review:可选流程.如果用例Review流程没有被选取,新提交的测试用例,状态为“己审核”状态,审核人为自动审批(既用例编写人)。用例...
  • 1、打开菜单栏PACKAGE->Database Enginneering->Edit DLL Templates;2、下拉选择语种MySQL,并选中脚本列表里的"DLL script File",点右侧代码面板内,按Ctrl+F搜索“SET FOREIGN_KEY_CHECKS=”,有2处地方;...
  • 一、註冊帳號 ...密钥的設置流程   3.設置Gerrit的SSH賬戶  openstack使用Gerrit管理代碼評審的過程以保證代碼的質量, 通過Launchpad 訪問下列網址上傳自己的SSH公鑰,開啟畫面如下圖所示::   ...
  • bug管理流程bug管理流程bug管理流程bug管理流程bug管理流程bug管理流程bug管理流程bug管理流程
  • http://blog.csdn.net/v587_lu/article/details/50515827 转载于:https://blog.51cto.com/zhaozhangxiao/1905114
  • 原因:Bug.xml中,增加了新的权限组 解决方法:先在项目集中增加同样的权限组,再执行导入操作。 转载于:https://www.cnblogs.com/rubyw/archive/2013/04/16/3024289.html...
  • bug状态流程

    2013-05-21 15:41:51
    非copy,亲手绘制bug流程图一张,有需要的可以来下载。
  • BUG处理流程

    2015-07-03 16:43:59
    BUG处理流程BUG状态流转,BUG书写标准
  • bug流程简图

    万次阅读 2020-06-20 15:42:37
  • bug处理流程

    2018-09-28 10:59:01
    简述关于bug的相关流程,包括生命周期,包括项目各角色如何处理。
  • bug状态流程图+bug处理流程+角色
  • BUG跟踪流程

    2013-04-24 12:52:29
    bug跟踪流程,以图表的形式详细说明了如何发现BUG,回归BUG
  • bug状态流程图+bug处理流程+角色..pdf
  • Bug管理流程

    2008-04-22 11:36:34
    Bug管理流程.pdf

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 6,501
精华内容 2,600
关键字:

bug流程