软件测试——bug处理流程图，让你上班少走弯路

前言

梳理好一个完整的bug处理流程图&＃xff0c;不仅仅可以事半功倍也能处理好同事关系&＃xff0c;列如&＃xff08;开发小哥&＃xff09;

bug处理流程图

上图就是bug处理的正常流程图&＃xff0c;在使用缺陷管理工具的时候&＃xff0c;这个流程图有助于我们正确了解缺陷的处理过程&＃xff0c;帮助我们如何跟踪bug.

接下来我们来说说&＃xff0c;bug的定义&＃xff1a;

&＃xff08;在读下面的内容之前&＃xff0c;我们首先来说说为什么要 这么详细的的了解bug,甚至得记住。软件测试的工作就是围绕发现bug而展开的&＃xff0c;在日常的工作中发现bug的数量是我们工作的重点&＃xff0c;因此&＃xff0c;记住bug的来源或者产生的原因能够帮助我们在工作中更有突破点&＃xff0c;在写测试用例的时候&＃xff0c;会出更针对性。俗话说&＃xff0c;不想当将军的士兵不是好的士兵。&＃xff09;

bug其实称之为软件缺陷&＃xff0c;&＃xff08;英文单词用defect来表示。&＃xff09;,俗称就是bug.

软件缺陷&＃xff1a;即为计算机软件或程序中存在的任何一种破坏正常运行能力的问题、错误、或者隐藏的功能缺陷、瑕疵。

缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。

围绕需求规格说明书而展开来说明bug

1&＃xff09;软件没有实现说明书中所列出的功能。

2)软件出现了说明书中提到的不应该出现的事情。

3&＃xff09;软件实现了说明书中没有提到的功能。

4&＃xff09;软件没有实现说明书中没有提到但应该实现的功能。

5&＃xff09;软件非常难于学习&＃xff0c;使用&＃xff0c;运转速度很慢&＃xff0c;用户认为无法达到预期。

bug的来源&＃xff1a;

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

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

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

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

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

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

缺陷产生的原因&＃xff1a;

1、需求不清晰

2、系统结构非常复杂&＃xff0c;对象、类太多&＃xff0c;隐藏着一些参数传递、方法调用、对象状态变化等方面的问题。

3、对程序逻辑路径或数据范围的边界考虑不够周全&＃xff0c;

4、对一些实时应用&＃xff0c;要进行精心设计和技术处理&＃xff0c;保证精确的时间同步

5、没有考虑系统奔溃后的自我恢复或数据的异地备份、灾难性恢复等问题

6、系统运行环境的复杂

7、由于通信端口多、存取和加密手段的矛盾性等&＃xff0c;会造成系统的安全性或适用性等问题

8、新技术的采用&＃xff0c;可能涉及技术或系统兼容的问题&＃xff0c;事先没有考虑到

从团队问题来说&＃xff1a;

1、系统需求分析时对客户的需求理解不清楚&＃xff0c;或者和用户的沟通存在一些困难

2、不同阶段的开发人员相互理解不一致

3、对于设计或者编程上的一些假定或者依赖性&＃xff0c;相关人员没有充分沟通

4、项目组成员技术水平参差不齐&＃xff0c;新员工较多&＃xff0c;或者培训不够等原因也容易引起问题

从技术问题来说&＃xff1a;

1、算法错误&＃xff1b;

2、语法错误

3、计算和精度问题

4、系统结构不合理、算法选择不科学、造成系统性能低下

5、接口参数传递不匹配&＃xff0c;导致模块集成出现问题

从缺陷管理问题来说&＃xff1a;

1、缺乏质量文化&＃xff0c;不重视质量计划&＃xff0c;对质量、资源、任务、成本等的平衡性把握不好

2、开发周期短&＃xff0c;各项工作不能完全按照定义好的流程来进行&＃xff0c;也给各类开发人员造成太大的压力&＃xff0c;引起一些人为的错误

3、开发流程不够完善&＃xff0c;风险估计不足等

bug的等级要记牢&＃xff1a;否则&＃xff0c;嘿嘿&＃xff1a;

bug的状态&＃xff1a;

1、新建&＃xff08;new&＃xff09;

2、打回&＃xff08;freeback&＃xff09;

3、已确认&＃xff08;confirmed&＃xff09;

4、拒绝&＃xff08;rejected&＃xff09;

5、延期&＃xff08;postponed&＃xff09;

6、已分派&＃xff08;assigned&＃xff09;

7、重新打开&＃xff08;reopen&＃xff09;

8、已解决&＃xff08;fixed&＃xff09;

9、已关闭&＃xff08;cpsed&＃xff09;

bug 的优先级&＃xff1a;

1、低&＃xff08;low&＃xff09; :低优先级留到最后解决&＃xff0c;如果项目的进度很紧&＃xff0c;可以在产品发布以前不解决

2、中&＃xff08;medium&＃xff09;如果时间允许应该修改

3、高&＃xff08;high&＃xff09;将处于5和4 优先级的bug修改完后再进行修改&＃xff0c;但需要确定在某个特定里程碑结束前须修正

4、加急&＃xff08;urgent&＃xff09;一到两天之内必须修改&＃xff0c;并且版前必须进行修正

5、特急&＃xff08;immediate&＃xff09;必须修改&＃xff0c;并且需要立即进行修改

bug的严重级别&＃xff1a;

1、建议&＃xff08;enhancemental&＃xff09;

2、小错误&＃xff08;minor&＃xff09;

3、一般&＃xff08;normal&＃xff09;

4、严重&＃xff08;major&＃xff09;

5、宕机&＃xff08;block&＃xff09;

以上的等级是一定要清楚的&＃xff0c;通常在公司bug的提交会使用bug管理工具&＃xff0c;例如禅道。对于提交bug的严重级别优先级状态是一定要清楚的&＃xff0c;否则是一定会给你的公司做带来不便的。

 如果对你有一点点帮助&＃xff0c;各位的「点赞」就是小编创作的最大动力&＃xff0c;我们下篇文章见