后台开发怎么测bug

后台的bug与逻辑、性能和安全性有关。当bug出现时，一般来说分大致3种情况。

1，数据库层面的。

可能少某个字段，或者字段值为空等等，这些可能在设计数据库时就埋下了错误的种子，导致程序调用数据库错误的数据产生bug，这一类问题不算普遍，但也是最容易忽视的一种情况，有时候从数据库入手定位bug说不定还能发现数据库的设计缺陷呢。

2，网络层面的。

通常这种都是网络情况较差的时候产生的，比如手机的移动网络信号不好，又或是公司网络不稳定，导致js/css未加载完全或者请求超时等等，这种问题其实非程序bug造成的，可以不用提交bug，也不用让开发毫无头绪的去查代码的问题。

当然如果可以的话也可以当优化建议提给开发，让他优化代码，比如压缩js/css，增加超时时间，超时后的重试机制。

3，代码层面的。

普遍的bug基本都是代码有问题造成的，排除掉1和2剩下后就可以确定是程序bug了。对于了解网络架构的人来说，其实程序也分前端和后端的，一般对于界面显示有问题直接可以判断是前端的问题，比如系统兼容性，浏览器兼容性。

bug是一个英文单词，本意是指昆虫、小虫、损坏、犯贫、缺陷、窃听器等意思。现在一般是指在电脑系统或程序中，隐藏着的一些未被发现的缺陷或问题，简称程序漏洞。另外bug还有一种引申意义，用来形容某事物厉害的超乎想象。

所谓"(Bug)"，是指电脑系统的硬件、系统软件(如 *** 作系统)或应用软件(如文字处理软件)出错。硬件的出错有两个原因，一是设计错误，一是硬件部件老化失效等。

软件的Bug，狭义概念是指软件程序的漏洞或缺陷，广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等。

对于快速定位，个人的经验处理一般如下（基本可以定位到我在 淘宝 遇到的 90% 以上的复杂 CSS BUG 问题）：
1、检查页面的标签是否闭合
不要小看这条，也许折腾了你两天都没有解决的 CSS BUG 问题，却仅仅源于这里。毕竟页面的模板一般都是由开发来嵌套的，而他们很容易犯此类问题。
快捷提示：可以用 Dreamweaver 打开文件检查，一般没有闭合的标签，会背景高亮。
2、样式排除法
有些复杂的页面也许加载了 N 个外链 CSS 文件，那么逐个删除 CSS 文件，找到 BUG 触发的具体 CSS 文件，缩小锁定的范围。
对于刚才锁定的问题 CSS 样式文件，逐行删除具体的样式定义，定位到具体的触发样式定义，甚至是具体的触发样式属性。
3、模块确认法
有时候我们也可以从页面的 HTML 元素出发。删除页面中不同的 HTML 模块，寻找到触发问题的 HTML 模块。
4、检查是否清除浮动
其实有不少的 CSS BUG 问题是因为没有清除浮动造成的。养成良好的清除浮动的习惯是必要的，推荐使用 无额外 HTML 标签的清除浮动的方法（尽量避免使用 overflow:hidden;zoom:1 的类似方法来清除浮动，会有太多的限制性）。
5、检查 IE 下是否触发 haslayout
很多的 IE 下复杂 CSS BUG 都与 IE 特有的 haslayout 息息相关。熟悉和理解 haslayout 对于处理复杂的 CSS BUG 会事半功倍。推荐阅读 old9 翻译的 《On having layout》（如果无法翻越穿越伟大的 GFW，可阅读 蓝色上的转帖 ）
快捷提示：如果触发了 haslayout，IE 的调试工具 IE Developer Toolbar 中的属性中将会显示 haslayout 值为 -1。
6、边框背景调试法
故名思议就是给元素设置显眼的边框或者背景（一般黑色或红色），进行调试。此方法是最常用的调试 CSS BUG 的方法之一，对于复杂 BUG 依旧适用。经济实惠还环保

大家好，我是十一。

前面篇我们都在讲测试用例设计的案例、设计方法、工具。本篇呢我们来聊聊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了。

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

---