软件测试

　　本来在一家杭州软件测试公司工作，三月初的时候无意中收到深圳腾讯云的电话（对方表明身份后，说看到我的简历，想和我聊聊。当时没有电面经验再加上也没有进来也没有投简历，爽快的答应聊就聊呗。上来就是技术问题，当时蒙了，我简历也不知道啥时候怎么他就知道啦，当时电面后想着估计黄啦），后面就没音讯啦，从那次以后开始踏上2016找实习的征途。之后再内推腾讯互动娱乐，没收收到电面。所以按照正常的实习生流程走下来。经过笔试，一个礼拜后于4月9号夜收到腾讯一面通知（4月10号），今天特意分享一下《十道腾讯软件开发工程师面试题》希望大家能够受用。 　　1、介绍一下你自己。（严格来说这个不能算一个问题，每家公司基本都要问） 　　一、OSI模型有几层？ 　　二、说说C++的多态？为什么使用虚函数比非虚函数耗费的时间更多？ 　　三、有一个全局变量int a=0，现在两个线程各自循环执行100次a++操作，问最后a的值是多少？ 　　四、对于海量数据，用什么数据结构存储用户搜索的高频关键词比较合适？比如，当用户输入“黄”字，输入框要自动显 示“黄晓明”，“黄蓉”，“黄山”，“黄鹤楼”等提示，但是能存储的量很有限，所以需要选择恰当的数据结构。（我先后说 了数组和堆，似乎都被否决了） 　　五、智力题：一片草地的草每天匀速地长，m只羊花p天能吃完，n只羊花q天能吃完，问现在k只羊花多少天能吃完？（ 记不清m,p,n

　　 黑盒测试 ：不基于内部设计和代码的任何知识，而是基于需求和 功能 性。 　　 白盒测试 ：基于一个应用代码的内部逻辑知识，测试是基于覆盖全部代码、分支、路径、条件。 　　 单元测试 ：最微小规模的测试;以测试某个 功能 或代码块。典型地由程序员而非测试员来做，因为它需要知道内部程序设计和编码的细节知识。这个工作不容易作好，除非应用系统有一个设计很好的体系结构;还可能需要开发测试驱动器模块或测试套具。 　　 累积综合测试 ：当一个新 功能 增加后，对应用系统所做的连续测试。它要求应用系统的不同形态的 功能 能够足够独立以可以在全部系统完成前能分别工作，或当需要时那些测试驱动器已被开发出来;这种测试可由程序员或测试员来做。 　　 集成测试 ：一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。 　　 功能测试 ：用于测试应用系统的 功能 需求的黑盒测试方法。这类测试应由测试员做，这并不意味着程序员在发布前不必检查他们的代码能否工作(自然他能用于测试的各个阶段)。 　　 系统测试 ：基于系统整体需求说明书的黑盒类测试;应覆盖系统所有联合的部件。 　　 端到端测试 ：类似于系统测试;测试级的“宏大”的端点;涉及整个应用系统环境在一个现实世界使用时的模拟情形的所有测试

　　很多人懵懵懂懂进入了软件测试行业，有些人做的开开心心，事业发展顺顺利利，有些人不断地换工作，每次工作都不开心，不知道是自己怎么了，还是周围怎么了。在不断地换工作过程中，你有考虑过自己是否适合这个行业吗？下面我来给你讲下软件测试人员的基本素质。 　　软件测试人员的基本素质你根据自己的判断觉得自己很OK，想入行，但软件测试行业会喜欢你吗？你符合行业的职业道德吗？可能有些人觉得这都不重要，重要的是我喜欢。但是我个人觉得这很重要。这里插一个真实的例子：一家 杭州软件测试 （www.proginn.com/users/hangzhou/csgcs/）公司主管上周开掉一个很有技术能力的成员，一个执行能力、理解能力、做事非常有效的成员，我曾在领导面前多次夸赞他的做事有效率，但最终我不得不下定决心开掉他。理由是：无团队协作精神，无法和他人一起和谐开展工作。 　　学习技术都是很快的，只要你聪明，只要你用心，技术都应该不是难事，但有些素养是很难培养的，这个跟成长的环境、接受的教育、心智的成熟等都有很大的关系。人无完人，有些人能准确的感知自己是否符合要求，对做的不好之处会自动调整；有些人需要提点才能感知，他会按照别人的意见去改变：而有些人被提点了也感觉不到，因此他们一直不会变，他们觉得自己没有错，为什么要改？而团队中如有一个人一直不断地同一个错误，终究会被团队抛弃。 　　每个行业除了对硬技术的要求

敏捷项目测试策略文档模板 　　在一个敏捷工作环境种，我们的研发工作以冲刺期和高度迭代的形式展开。每一个迭代周期都关注少数的需求或者用户故事，所以在文档在敏捷项目种的数量和内容方面都倾向于轻量化。 　　对于测试计划这样的文档也是如此，不过我们也确实需要为敏捷团队去提供一个概要的敏捷测试策略，以供指导。 　　敏捷测试策略文档是为了给团队提供一个最佳的测试实践和一些形式的测试体系。记住，敏捷并不意味着没有体系。 　　下面我们来看一个敏捷测试策略文档，看看我们都应该包含些什么内容。 1.　　 一份测试策略中通常都会对于更宽泛的商业目的和目标做出任务说明。 　　 一个典型的任务说明可以是： 　　“通过快速反馈和缺陷预防，持续的交付可工作的，满足用户需求的软件，而不仅仅是缺陷发现” 　　细化以后： 　　“● 在定义完需求的接收条件/测试之后，代码才能进行编写。 　　 ● 接收测试不通过，一个需求就不能被判断为完成。” 　　在敏捷项目中，通常还会包含关于质量保证的提示： 　　● 质量保证是系统和可靠的保证产品满足用户需求的一系列活动。 　　● 在SCRUM（敏捷）中，质量保证是所有人的责任，而不单单是测试人员。在我们开发新产品的过程中，我们通过质量保证活动来确保正确的质量。　 　 2.　　 测试级别 　　 2.1　　单元测试 　　WHY : 确保代码被正确开发 　　WHO : 开发工程师

测试计划是最早出现,最先被遗忘的测试产物.在项目早期,测试计划代表了对软件功能的预期.但是,除非得到持续的关注,它会很快随着新代码的完成,功能特性的改变以及设计的调整而过期.伴随着计划内或计划外的变更,维护一份测试计划是要花费大量精力的,除非多数项目的成员会定期查看,否则测试计划并没有什么价值. 后面这一点是测试计划真正的杀手:试问在产品的整个生命周期中,测试计划能在多大程度上作为测试活动的指导?测试人员会不断参考计划来安排一个应用的测试吗?会要求开发人员在功能增加或修改时去更新测试计划吗?在开发经理管理todo列表的时候,他们会在桌面上打开一份测试计划吗?在进展沟通会议上,测试经理会经常参考测试计划的内容吗?如果测试计划真的重要,那么所有这些事情应该每天都会发生. 理想情况下,测试计划应当在项目执行中发挥核心作用,应当在软件的整个生命周期中持续有效:随着代码库的更新而更新,时刻代表最新的产品功能,而不是停留在项目开始阶段时的样子.他应该可以帮助一个新加入的工程师迅速跟上项目进展. 下面是我们希望测试计划中具有的一些特性. 及时地更新 描述了软件的目标和卖点 描述了软件的结构,各种组件和功能特性的名称 描述了软件的功能和操作简介 不必花过多的时间去撰写,必须随时可以被修改 应该描述必测点 应该能在测试中提供有用的信息,从而帮助确定进展以及覆盖率上的不足. ACC(Attribute

　　一、 测试用例 是软件测试的核心 。 　　软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。 　　影响软件测试的因素很多，例如软件本身的复杂程度、开发人员(包括分析、设计、编程和测试的人员)的素质、测试方法和技术的运用等等。因为有些因素是客观存在的，无法避免。有些因素则是波动的、不稳定的，例如开发队伍是流动的，有经验的走了，新人不断补充进来;一个具体的人工作也受情绪等影响，等等。如何 保障软件测试质量的稳定?有了 测试用例 ，无论是谁来测试，参照 测试用例 实施，都能保障测试的质量。可以把人为因素的影响减少到最小。即便最初的 测试用例 考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。 　　因此 测试用例 的设计和编制是软件测试活动中最重要的。 测试用例 是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障。 　 　二、什么叫 测试用例 ？ 　　 测试用例 (Test Case)目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略，内容包括 测试目标 、 测试环境 、输入数据、 测试步骤 、预期结果、 测试脚本 等，并形成文档

从事软件测试行业多年，不管是目前比较流行的业务测试，还是最常见的功能测试，80/20原则（80% 的软件缺陷常常生存在软件20% 的空间里）一直都是适用的。 然而，有时候在总结测试经验的时候发现，这个软件测试行业入门必知的一个知识好像在测试过程中已经被忽略了；看过有人调查的一篇文章，超过60%的人可能都忘记80-20原则是什么了；文章中提到一句很有意思的话是可能你在测试了很久也没有发现很重要的bug，可能一个大佬过来点点点几下就发现几个bug，这说明你根本没有理解被测软件的重点在哪里，导致在测试过程中盲目的测试。我认为可以把80-20原则理解为测试过程中要抓住测试的重点，要把更多的时间很精力投入在那20%重点模块中。 很多时候公司的项目进展都非常紧张，根本没有留下足够的时间给我们测试，我们发现bug之后还要给开发修改，然后再回归测试。此时我们如果无法抓住测试的重点，可能会导致漏测，甚至发布之后出现网上问题。 不同的公司对测试团队的考核可能不一样，有的公司可能考核bug的数量，有的公司考核bug的质量，但总之，我建议大家都可以思考一下是否可以利用80-20原则发现更多更有质量的bug。 来源： oschina 链接： https://my.oschina.net/u/4265622/blog/3220446

从事软件测试行业多年，不管是目前比较流行的业务测试，还是最常见的功能测试，80/20原则（80% 的软件缺陷常常生存在软件20% 的空间里）一直都是适用的。 然而，有时候在总结测试经验的时候发现，这个软件测试行业入门必知的一个知识好像在测试过程中已经被忽略了；看过有人调查的一篇文章，超过60%的人可能都忘记80-20原则是什么了；文章中提到一句很有意思的话是可能你在测试了很久也没有发现很重要的bug，可能一个大佬过来点点点几下就发现几个bug，这说明你根本没有理解被测软件的重点在哪里，导致在测试过程中盲目的测试。我认为可以把80-20原则理解为测试过程中要抓住测试的重点，要把更多的时间很精力投入在那20%重点模块中。 很多时候公司的项目进展都非常紧张，根本没有留下足够的时间给我们测试，我们发现bug之后还要给开发修改，然后再回归测试。此时我们如果无法抓住测试的重点，可能会导致漏测，甚至发布之后出现网上问题。 不同的公司对测试团队的考核可能不一样，有的公司可能考核bug的数量，有的公司考核bug的质量，但总之，我建议大家都可以思考一下是否可以利用80-20原则发现更多更有质量的bug。 来源： oschina 链接： https://my.oschina.net/u/4339497/blog/3220448

第三章 软件测试计划编写 本章重点 1、掌握软件测试计划的设计 2、掌握软件测试的类型和目的 一、软件测试计划的设计 确定测试需求 测试人原要理解客户需求，参与审核需求文档，理解项目的目标、限制，了解用户应用背景，通过复查，走查，审查来的方式根据用户需求定义并完善测试需求，以作为整个测试的标准。 确定测试策略 （1）、测试的范围（将要测试什么） （2）、测试方法（如何完成测试，白盒测试，黑盒测试） （3）、测试入口/退出条件（测试标准） （4）、自动化策略（是否使用自动化测试工具，哪个阶段用什么工具） 确定测试系统 （1）、测试构架 （2）、测试环境 （3）、测试配置 预估测试工作量 （1）、确定任务 （2）、预估工作量 （3）、确定时间进度计划，评估风险(确定测试对象的优先级及测试实现的先后顺序) 复查测试计划 （1）、编写策略、系统、工作量和时间进度文档 （2）、与项目团队一起复查测试计划 二、软件测试的类型和目的 功能测试 确保所有的被测对象功能正常 用户界面测试 确保所有界面元素符合需求，运行效果正常 性能测试 确保系统在一般状态和极限状态下，都可以保持正常的响应速度和最大用户连接数量 兼容性测试 确保系统在不同的操作系统平台上, 不同的网络环境中正常运行 安全及访问权限测试 常见测试计划模版有四种，详见附件 点赞 收藏 分享 文章举报 tea_year 博客专家

单元测试对代码质量的影响 1.（过去的做法） 记得大一大二写程序的时候，从来都不写单元测试，现在去分析当时的心理，可能出于三个原因。第一，当时写代码的水平非常low，当然现在也挺low的，不过现在是大三了，更何况在上《软件工程》，编写代码的水平较以前肯定会有很大的提高。大一大二的时候，可能当时老师布置下任务以后，等到老师检查的时候差不多才刚刚把任务完成，来不及写单元测试就需要向老师展示结果了，这是第一个原因。第二个原因则是不敢写单元测试，以前写程序的时候往往用一组特殊的数据去验证程序的正确性，只要这组数据能让程序得到正确的结果，那就代表自己写的这个程序过关了，从未想过多用几组数据去测试一下，也不敢用别的数据去测试，因为一换数据就有可能导致程序出错，正是这种害怕程序出错的心理，让我的编程水平在很长的一段时间内都处于一个停滞不前的状态。第三个原因则是不会写单元测试，过去老师对我们的要求就是能实现程序应有的功能，所谓的测试也就只是多用几组数据去测试一下程序的结果，从来不会单独的写一个小程序从多方面的角度去验证程序。 因此，真正学习了单元测试并在实际的编程中使用单元测试时，才发现，单元测试是保证代码质量的有效手段。所谓的单元测试其实就是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为