课程：
css样式设计时快速定位bug的几个好方法
1、检查是否清除浮动
其实有不少的 CSS BUG 问题是因为没有清除浮动造成的。养成良好的清除浮动的习惯是必要的，推荐使用 无额外 HTML 标签的清除浮动的方法（尽量避免使用 overflow:hidden;zoom:1 的类似方法来清除浮动，会有太多的限制性）。
2、检查 IE 下是否触发 haslayout
很多的 IE 下复杂 CSS BUG 都与 IE 特有的 haslayout 息息相关。熟悉和理解 haslayout 对于处理复杂的
CSS BUG 会事半功倍。推荐阅读 old9 翻译的 《On having layout》（如果无法翻越穿越伟大的 GFW，可阅读
蓝色上的转帖 ）
快捷提示：如果触发了 haslayout，IE 的调试工具 IE Developer Toolbar 中的属性中将会显示 haslayout 值为 -1。
3、边框背景调试法
故名思议就是给元素设置显眼的边框或者背景（一般黑色或红色），进行调试。此方法是最常用的调试 CSS BUG 的方法之一，对于复杂 BUG 依旧适用。经济实惠还环保.
4、检查页面的标签是否闭合
不要小看这条，也许折腾了你两天都没有解决的 CSS BUG 问题，却仅仅源于这里。毕竟页面的模板一般都是由开发来嵌套的，而他们很容易犯此类问题。
快捷提示：可以用 Dreamweaver 打开文件检查，一般没有闭合的标签，会黄色背景高亮。
5、样式排除法
有些复杂的页面也许加载了 N 个外链 CSS 文件，那么逐个删除 CSS 文件，找到 BUG 触发的具体 CSS 文件，缩小锁定的范围。
软件测试如何定位bug
对于刚入行的软件测试新手迅速找出软件中的Bug思路如下：
1、
尽快熟悉公司的产品业务 比如你们公司做ERP软件的，你肯定要迅速熟悉EPR的业务流程；比如你们公司是做法院软件的，那么你一定要熟悉法院审判案件的流程，只有熟悉了产品的业务流程、你才能迅速找出软件中存在的一些重要的缺陷，你发现的软件缺陷才是有价值的。否则即使你能找到一些软件缺陷，那也是纯软件的缺陷，价值不大。
2、
把自己当成是用户 把自己当成是用户去使用该系统，比如在使用该系统过程中是这样操作的吗？
（1） 比如在大量要求用户输入的软件界面中，有一些用户喜欢使用Tab键采用全键盘的输入；此时的正确的接口应该采取从左到右，从上到下的顺序。
（2） 比如有的用户喜欢使用快捷键操作等（Ctr+C，Ctr+V，Ctr+F），但是实际情况下一些开发出来的软件的快捷键却根本不起作用。
（3） 比如软件在需要用户输入的信息的时候（特别是在填写个人资料的时候），必填项后面一律要用*等醒目的标示，要让用户知道这个地方时必须填写的。
（4） 下拉框不选值的时候，应该有个默认值；并且要多检查程序中的多处下拉框，因为很多情况下下拉框取不到值。
3、
善于怀疑，不要迷信高手 世界上没有绝对正确的，总有错误的地方，具有叛逆心理，别人认为不可能发生的事，我却认为可能发生。别人认为是对的，我却认为不是对的。如果你认为某个或者某些程序员水平很高，他写的这个地方应该没问题吧，那么我要说你错了，这样很容易遗漏软件中的Bug。因为程序开发人员毕竟是普通的人，只要是人就会犯错误的。
4、
不要让程序开发人员的观点：“用户不会进行这样的操作”而说服自己 遇到这样的情况，你要坚持你自己正确的想法，以后对方会明白你的。比如在一个录入员工基本信息的系统中，系统中对员工的年龄作为负值、而没有作为判断、也可以保存到数据库中，此时你不要被程序员的用户不会进行这样操作的观点说服自己，你要坚持你正确的观点，把这种现象作为一个Bug吧，勇敢点！你的选择不会不错！
5、
在软件测试过程中要跟踪一条数据完整的流程 在软件测试的时候要跟踪一条数据完整的流程，保证数据的正确性这个真的是太重要了：假如你在测试一个销售的类型的软件的时候：你应该先做订货-à入库-à盘点-à销售-à查询。首先你要保证这个数据的流向是正确的无误的。假如你在测试法院审判软件的时候，你要先收案-à立案-à发送审批-à排期---审理审判-à结案判决-à归档-à查询。总之跟踪一条数据的流程，保证数据的正确性。如果经过你测试的软件在用户使用过程中业务流程上都走不通的话，那么这样的软件你说经过你的测试，但是在比人看来与没有测试有什么区别呢？
6、
回归测试要注意的细项 程序员提交新的程序版本后，作为测试人员应该立即与程序员沟通这个修改的功能、并且这个新修改的功能影响哪些功能。举个简单的例子来说明一下：比如在一款软件中，程序开发人员修改了某个“会员”的某个字段信息。作为测试人员首先你要测试“会员”的功能这个是你首先需要做的。另外你还要和程序员沟通询问他们新修改的这个会员的字段，会影响会员的销售功能吗？会对会员以前的销售记录的查询有影响吗？如果对这些功能有影响，那么这些功能都是你在回归测试的时候重点测试的地方，也是最容易产生Bug的地方了。
7、
与使用者互动的缺陷
（1）如填写资料错误应的时候，应该能够提示错误的位置，让用户知道是这个地方输入数据不对。
（2）删除数据之前给一定要给出是否删除确认提示。
（3）不要在软件中使用中英文混合的提示比如：比如对于用户某个操作的错误提示，不要一会用“error”、一会用“错误”；一会用“succeed”另一会用“成功”，总之要统一。
当然要想简单省事并全面定位分析BUG，也可以直接交给成熟的第三方测试，TestBird的测试很全面，可以进一步了解下！
如何快速定位页面中复杂 CSS 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 依旧适用。经济实惠还环保.
QQ客服
新浪微博