简要列出bug的几种状态

1、New:（新的）

当某个“bug”被发现的时候（第一次），测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来，并将bug的状态设为New。

2、Assigned（已指派的）

当一个bug被指认为New之后，将其将给开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”。

3、Open（打开的）

一旦开发人员开始处理bug的时候，他（她）就将这个bug的状态设置为“Open”，这表示开发人员正在处理这个“bug”。

4、Fixed（已修复的）

当开发人员进行处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组。

5、Pending Reset（待在测试的）

当bug被返还到测试组后，我们将bug的状态设置为“Pending Reset”。

6、Reset（再测试）

测试组的负责人将bug指定给某位测试人员进行再测试，并将bug的状态设置为“Reset”。

扩展资料：

由于现代社会的发展，bug另有一种引汪拍申意义，用来形容某事物厉害的超乎想象，BUG可以使电脑系统崩溃、容易被施诈者攻击，现有修复漏洞的工具。

程序错误（英语：Bug），在程序设计中的术语，是指在软件运行中因为程序本身有错误而造成的功能不正常、体验不佳、死机、数据丢失、非正常中断等现象。

中文常称BUG为“缺陷”。而且，“缺陷”一词更能反映事情的本质。因为“臭虫”是从外面爬进去的，并非程序本身有问题。而程序本身存在的问题，是程序原来就具有的。因此，在这里将BUG翻译为“系统漏洞”更合适。

在程序运用中，特别是应用程序，会出现莫名其妙的警告，让普通用户丈二和尚----摸不着头脑，这些警告常被称作“BUG”。

游戏中的BUG,简单来说就是游戏程序的漏洞，游戏程序中的缺陷。游戏中有BUG是很正常的，孙陵亩尤其是在网络游戏中。即使所有的网络游戏都是经过封测、内测和公测这三个大的步骤，但由于游戏文件和游戏中的任务以及地图的不断更新和增加，难免会在游戏制作方面出现错误和偏差。

1.良性BUG

良性BUG即不会产生严重后果，甚至为玩家带来了利益的BUG。通常很多良性BUG被玩家们利用，方便游戏或副本，不过此举带有一定的作弊性，因此利用这种BUG来游戏是不值得提倡的。例如有些则森FPS游戏中可以卡入一些副本，从而使得不被击杀。

2.恶性BUG

恶性BUG即游戏中致命的，会对游戏过程及体验造成严重影响的BUG。例如正常 *** 作中，由于执行文件冲突或错误不兼容而导致的系统自动退出或者服务器断开等等。

为了减少这种情况的发生，游戏制作方都在大力加强游戏的升级和补丁。如果BUG严重，网络游戏运营公司会采取回档处理，以减少玩家利用BUG或者玩家因为BUG而造成的损失。

参考资料：百度百科——bug

1）、在Red Hat Linux中竖尺函数库可以分为3种类型：静态函数库、共享函数库和动态加载函数库。

静态函数库在应用程序编译时就把函数的执行代码加入抄到应用程序中。

共享函数库中的函数当一个可执行程序启动时被加载。袭

动态加载函数库可以在程序运行的任何阶段加载函数。

2）、使用nm和ldd命令可以获得关于库函数的信息。

nm命令可以列出一个函数库文件中的符号表，它对静态的库函数和共享的库函数都能起作用。

ldd命令zd可以列出一个程序正常运行所需要的共享库。

3）、库函数缺余纤高省存放在/lib和/usr/竖扮lib中，以及动态库配置文件内所列的目录中。

如果库函数没有在这些目录下，可以在中加入所须目录，后运行ldconfig命令，使之生效。或设置环境变量LD_LIBRARY_PATH或LD_PRELOAD加入库函数所存放的目录。

还有不会的请参考《linux就该这么学》，针对各种linux疑难杂症，帮助linux学习者

大家好，我是十一。

前面篇我们都在讲测试用例设计的案例、设计方法、工具。本篇呢我们来聊聊bug，程序里的小虫子。

所谓“（Bug）”，是指程序中隐藏的错误或者缺陷。

早在 软件测试的工作周期 一文附录中我们就已经对bug来源做了解释，感兴趣的点击链接回顾。

一条Bug记录最基本应包含：

※bug编号：bug的唯一id，以方便尽快找到此bug。

※bug标题：bug摘要，阐述bug大体内世蚂容。

※bug严重级别，优先级：作为缺陷是否修复以及缺陷修复优先级的决定性因素。

※bug产生的模块：记录bug所属模块，方便开发定位问题。

※bug对应的版本：bug对应的软件版本，方便后续的统计归档以及开发定位问题。

※bug描述：bug的产生环境、详细步骤，期望结果、实际结果。

※附件：包括但不仅限于截图、日志、录像、所用到的示例文件以及应用；同样是方便复现解决缺陷的。

以上是上报bug（创建）bug必须的，在后续我们还会对bug进行修复、复测等工作，那在为了记录后续工作，bug还应该包含：

※bug状态：开始、修复中、修复完成、提测、搜肆埋测试中、测试通过/失败、关闭等，后续bug周期中会讲到。

※bug修订人：bug修订人员。

※bug复测人：通常是谁报的bug最后返回给谁测试，但是在某些情况下比如bug报告人任务积累太多/不在的情况下也会分给其他人，所以通常会记录bug复测责任人。

※bug修订说明：由bug修订人来写，说明bug产生原因，修改思路等。

※bug复测说明：由复测人员来写，说明复测过程，复测结果等。

※bug备注：备注，以便记录一些额外信息。

俗话说，事有轻重缓急。生活如此，工作亦如此。软件缺陷也并不是平等的，根据当前环境我们将不同的缺陷按照严重程度以及优先级进行分类，开发通过这个分类来决定bug是否修改以及bug修改的先后顺序（“缺陷的轻重缓急”）。

具体划分方法各个公司不尽相同，但是通用原则大体一样：

※ 严重性 ：表示软件缺陷的恶劣程度，当用户碰到该缺陷时影响的可能性和程度。

※ 优先级 ：表示修复缺陷的重要程度和紧迫程度。

下面我们给出严重性和优先级的常用划分方法，需要注意的是，我们这个只是示例，每个公司划分方法也都不尽相同，多多少少有些改变，大家作为参考即可。

严重性：

    a.系统崩溃、数据丢失、数据毁坏、安全性被破坏、核心功能未实现（比如QQ 没有做聊天功能）、主体功能实现与需求不符（比如QQ聊天功能只能发消息不能收消息）

    b. *** 作性错误、结果错误、功能模块的某个点未实现（比如QQ没有做消息提醒）,兼容性错误

    c.小问题、拼写错误，UI布局不美观、特定情况下的罕见bug

    d.一些易用性的建议（也可以归为3）

优先级：

    a.立即修复，阻止了进一步测试

    b.在产品发布之前必须修复

    c.如果时间允许应该修复

    d.可能会修复，不影响发布。

再次重申，上述清单只是范例，具体的缺陷划分规则还要依据实际项目、应用场景来制定。比如：通常我们认为毁坏用户数据的缺陷比简单的拼写错误缺陷严重。但是如果数据毁坏仅在用户几乎用不到的罕见特例中出现，而拼写错误导致所有用户安装软件产生问题呢？此时数据毁坏与拼写错误的优先级和严重性就不言而喻了，必然是拼写错误的严重性和优先级高于数据毁坏的。

严重性和优先级对于审查缺陷报告并决定哪些软件缺陷应该修复，以何种顺序修复的人员极为重要。如果一个程序员受命修复10个缺陷，他就应该先从严重性为1 、优先级为1这样的缺陷着手，而不是优先修复简单的，有简到难。

同样，两个项目经理--一个管理广告门户网站/游戏软件，一个管理医院检测仪/性能检测类软件，对待同样的问题就会做出两种选择，比如同样都是页面美观问题，在前者那优先级可能就是2，在后者那可能就是3或者4了。

好了，今天到此结束。如有任何问题请留言及时与我沟雹首通，我会尽快回复大家！谢谢大家~我们下次再见！

---