软件测试常见bug(软件测试常见笔试题)

excel本身应该不会在光标闪烁的时候出现突然选定而无法输入的情况吧，只可能是输入的时候无意碰到了回车，方向键等按钮导致这种情况。如果真的装了控件，可以试试把这个控件去掉，再看看稳定性怎么样，来确定是本身的bug还是控件的原因。

虽然说我们在工作中一再要求大家要认真细心，但是对于许多的新手来说，依然会在不知不觉中犯错误。下面云南电脑培训http://www.kmbdqn.com/就通过软件测试岗位做为分析案例，了解一下，一个软床测试新人都容易犯的测试错误都有哪些。1.没有测试我们很容易毫无原因地掉入这个陷阱。从现在开始，制定计划添加测试到你现在正在处理的代码中，并添加测试到将来的项目中。2.没有从项目一开始就启动测试我们很难再回过头去添加测试，并且可能需要改变架构才能添加测试，这样做终将需要你花更长的时间才能产出可信任的代码。从一开始就在项目的生命周期添加测试可以节省时间和精力。3.编写失败的测试TDD方法的普及将红—绿—重构的理念带到软件测试世界。这个理念常常被误认为应该“通过编写一个失败的测试开始”。其实并非如此。在写代码之前创建测试的目的是定义系统的正确行为应该是什么。在许多情况下，它是一个失败的测试(红色表示)，但它可能会通过一个非决定性的或未实现的测试来表示。4.担心未实现测试软件开发中的一个大问题就是，代码和任何关于系统实际上应该做什么的文档之间的沟壑。通过拥有一个名称中明确定义你终想要实现的预期行为的测试，你将从测试中得到一定的价值，即使将怎么写测试目前还不得知。5.没有很好地命名测试命名软件这件事出了名的很难做好，这同样适用于测试。关于如何命名测试有几种流行的约定。无论你使用哪一种都没有关系，只要你能够一贯使用，并准确描述正在测试什么。6.让测试做太多事情又长又复杂的名字通常说明了你想同时测试多件事情。单个测试应该只测试一件事情。如果失败了也应该在代码中注明是什么地方出了错。你没有必要为了知道代码中出了什么问题而查看是哪部分测试失败。这并不意味着你不应该在测试中有多个断言，但这些断言应该紧密相关。例如，一个查看订单处理系统输出，并确认输出中是否有一个单一项目以及它是否包含具体项目的测试，是ok的。但一个验证相同系统的输出的测试，既创建一个特定项目，又记录到数据库中，还发送确认电子邮件，就不行了。7.没有实际测试代码经常可以看到测试新手创建过于复杂的模型以及不能实际测试代码的设置程序。他们可能会验证模拟代码是否正确，或者模拟代码是否和真正代码做相同的事情，或没有任何断言而只是执行代码。这样的“测试”都是白费力气，特别是如果它们的存在只是为了提高代码覆盖率水平的话。8.担心代码覆盖率代码覆盖率的理念很崇高，但往往实际价值有限。知道运行测试的时候有多少代码被执行应该是有用的，但因为它不考虑正在执行代码的测试的质量，因此就变得没有意义。代码覆盖率在它数值非常高或非常低的时候，是挺博人眼球的。如果非常高，就表明，比起带来的价值，过多的代码可能正在被测试。非常低的代码覆盖率表明有可能代码的测试不够。因为这样模棱两可的意思，有的人就不知道单一片段的代码是否应该进行测试。我用一个简单的问题来明确这一点：代码是否包含重大的复杂性?如果包含，那么你需要一些测试。如果没有的话，你就不需要。测试属性访问器不过是浪费时间。如果它们失败的话，那么比起你正在写的代码，你的代码体系出现了一些更根本的问题。如果你不用看一段代码，就立即知道一切，那么它就不重大。这不仅适用于代码，也适用于你写代码。如果我们在任意点重访代码，那么它就需要测试。如果在现有代码中发现过bug，那就说明这一块的代码对其复杂性没有进行充分的测试。9.着眼于一种类型的测试一旦你开始测试，很容易只纠结于一种风格的测试。这是一个错误。只用一种类型的测试，你就不能充分测试系统的所有部分。你需要单元测试来确认代码的各个组件是否能够正确工作。你需要集成测试来确认不同组件是否能够协同工作。你需要自动化UI测试来验证软件是否可以如预期使用。后，你需要为任何不容易自动化的部分和探索性尝试进行手动测试。

复制的 希望对你有用。、 软件缺陷1、概念：软件缺陷简单说就是存在于软件（文档、数据、程序）之中的那些不希望，或不可接受的偏差，而导致软件产生的质量问题。按照一般的定义，只要符合下面5个规则中的一个，就叫做软件缺陷。 软件未达到软件规格说明书中规定的功能； 软件超出软件规格说明书中指明的范围； 软件未达到软件规格说明书中指出的应达到的目标； 软件运行出现错误； 软件测试人员认为软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好。 2、软件缺陷的种类（1）功能不正常（2）软件在使用上不方便（3）软件的结构未做良好规划（4）功能不充分（5）与软件操作者的互动不良（6）使用性能不佳（7）未做好错误处理（8）边界错误（9）计算错误（10）使用一段时间所产生的错误（11）控制流程的错误（12）在大数据量压力之下所产生的错误（13）在不同硬件环境下产生的错误（14）版本控制不良所产生的错误（15）软件文档的错误3、正确面对软件缺陷在软件测试过程中，软件测试人员必须确保测试过程发现的软件缺陷得以关闭； 测试是为了证明程序有错，而不是证明程序没错。不管测试计划多么完善和执行测试多么努力，也不能保证所有软件缺陷发现了就能修复。有些软件缺陷可能会完全被忽略，还有一些可能推迟到软件后续版本中修复。有些软件缺陷不被修复的原因如下。（1）没有足够的时间（2）不算真正的软件缺陷（3）修复的风险太大（4）不值得修复（5）测试误登记 4、缺陷的分类按严重程度划分：严重、较严重、一般、建议严重：系统崩溃、数据丢失、数据毁坏 较严重：操作性错误、错误结果、遗漏功能 一般：小问题、错别字、UI布局、罕见故障 建议：不影响使用的瑕疵或更好的实现按优先级划分：最高、次高、中等、最低 最高优先级：立即修复，停止进一步测试 次高优先级：在产品发布之前必须修复 中等优先级：如果时间允许应该修复 最低优先级：可能会修复，但是也能发布缺陷的分类按测试种类划分： 逻辑功能类性能类界面类 易用性类 兼容性类

一般软件测试的面试分为三轮：笔试，HR面试，技术面试。前两轮，根据不同企业，或有或无，但最后一个技术面试是企业了解你“行不行”的关键环节，每个企业都会有的。在平时的学习、工作中一定要善于总结，如果回答不好，面试官会认为你技术能力有限或者不勤于思考，是很容易被pass掉的。简单为大家总结了些面试过程中经常会被问到的问题：hr会问的几个问题1.你觉得自己的优缺点是什么2.你上一家公司的薪资是多少，调了几次薪3.为什么从上一家公司离职呢4.离职证明和背调可以吗？5，你还有什么问题要问吗？（这些问题都带坑！回答不好会死在这儿的，不知道怎么回答，可以百度下或者联系在线客服）技术方面的问题【功能方面】1.你是怎样理解软件测试的2.让你介绍你做的项目的业务流程3.软件测试的流程4..你认为什么是bug，说一下你印象深刻的bug，结合项目说一下你们公司有哪些类型的bug和bug评判严重程度的标准5.如何保证软件测试的质量6.如何保证你写的测试用例覆盖所有的场景7.如果用户在正式环境发现一个bug，你在测试环境没有发现，怎么办8.项目测试到什么程度就可以上线了【场景方面】1.让你写登录，支付，充值，购物车，文件上传，三角形，笔，水杯等的测试点（80%的公司会让你分析测试点！！！）【计算机网络基础知识】1.http协议的内容是什么?2.请求头的内容有哪些3.常见的状态码有些4.http和https的区别有哪些5.tcp和udp的区别6.请描述下tcp的三次握手四次挥手的过程7.网关的作用8.osi七层模型每一层的作用9.session是什么，cookie是什么，有什么使用场景10.session和cookie的区别【接口测试】1.你认为的接口是什么2.接口测试工具工作的原理是什么呢？3.接口中包含哪些内容4.接口用例如何写5.你是如何做接口测试的，使用的什么工具？6.接口自动化了解过吗7.get和post的区别【自动化测试】1.可能会问到selenium2.selenium元素定位的方式，显示等待，隐式等待，强制等待的区别等3.接口自动化脚本的编写原理和过程这块可以不用担心，只要会一些简单的就可以了，因为对于初中级测试来说，自动化是一个加分项，一般如果自动化掌握的很熟练的同学薪资是在12-25k之间的【其他测试问题】1.简述转包过程，你用的抓包工具是什么2.如何分析一个bug是前端还是后端bug3.url后面跟数据的话如何拼接上去4.抓包的原理是什么5.你们公司使用的bug管理工具是什么6.弱网测试是如何实现的7.web测试和app测试的区别是什么8.给你一个软件你会如何进行测试9.兼容性测试你是如何做的（从app 和 web两方面回答）10.冒泡排序之类的一些代码题11.如果在正是环境发现bug测试环境没发现怎么办12.如果有一个bug，怎么判断这个bug是前端代码导致的还是后端代码导致的这些问题回答的正确与否直接决定了你能否留下，甚至能拿多少薪资的问题，多回答对一个问题，就有可能多为自己争取到500-1000块的工资呢。如果不知道怎么回答，可以私信细聊哦！

1、查看报错日志，通过日志分析，需要有一定的经验，并且有一定的代码基础，才能更好地定位问题。2、查看数据库的数据，了解所测功能的数据表结构，测试过程中，查看数据库的数据，确认数据的正确性。3、查看缓存（如Memcache、apc、redis等缓存）是否正确。扩展资料：快速发现bug方法1、尽快熟悉公司的产品业务，根据产品的业务属性来熟悉产品的业务流程，这样才能迅速找出软件中存在的一些重要的缺陷，这样发现的软件的价值才是有价值的，否则即使能找到一些软件缺陷，那也是纯软件的缺陷，价值不大。2、不用让程序开发员＂用户不会这样操作＂的观点说服自己，遇到这样的情况，要坚持自己的正确的观点，把这种现象作为一个Bug。
产品说明书中规定要做的事情,而软件没有实现,例如:产品说明书要求计算器要实现加,减,乘和除功能,做出来的计算器不能进行除运算,这就是一个BUG.产品说明书中规定不要做的事情,而软件却实现了,例如:产品说明书要求计算器除加,减,乘和除功能外其它的功能不要实现,做出来的计算器不仅能进行加减乘除运算,还能进行乘方或三角函数运算,这也是一个BUG.
一是需求和设计目标（概要），与原来想的不一样，原则上都是不对的。 二是看实现效果，可能是软件本身运行的问题等。即实现的不够好。 三是漏洞，包括安全问题、可靠问题等。
不存在唯一标准！确定是否为BUG应从两方面考虑：开发人员方面与客户方面。
是否满足客户需求