1 软件工程概述1.1 软件开发生命周期软件开发过程包括：计划、需求分析、设计、编码、测试、运行和维护。软件定义时期包括可行性研究和详细需求分析过程，任务是确定软件开发工程必须完成的总目标，具体可分成问题的定义、可行性研究、需求分析等。软件开发时期就是软件的设计与实现，可分成概要设计、详细设计、编码、测试等。软件运行和维护就是把软件产品移交给用户使用。1.2 软件系统文档软件系统文档可以分为用户文档和系统文档两类，用户文档主要描述系统功能和使用方法，并不关系统这些功能是怎样实现的；系统文档描述系统设计、实现和测试等各方面的内容。1.3 软件工程过程软件工程过程是指获得软件产品包括以下4个方面活动：1> P（Plan）：软件规格说明，规定软件的功能及其运行时的限制；2> D（Do）：软件开发，开发出满足规格说明的软件；3> C（Check）：软件确认，确认开发的软件能够满足用户的需求；4> A（Action）：软件严谨，软件在运行过程中不断改进以满足客户新的需求。1.4 软件系统工具软件系统工具通常可以按软件过程活动分为软件开发工具、软件维护工具、软件管理和支持工具。软件开发工具：需求分析工具、设计工具、编码与排错工具、测试工具等；软件维护工具：版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具；软件管理和软件支持工具：项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择。按描述需求定义的方法可以将需求分析工具分为基于自然语言或图像描述的工具和基于形式化需求定义语言的工具。1.5 软件设计软件设计的四个活动：数据设计、架构（体系结构）设计、人机界面（接口）设计和过程设计。2 能力成熟度模型2.1 软件能力成熟度模型CMM软件能力成熟度模型CMM：是对软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。侧重于软件开发组织中的有关软件过程的宏观管理。软件工程 = 工程过程 + 管理过程CMMI咨询评估（Capability Maturity Model Integration）是一种评价组织过程改进的现状的评估方法，分为整体成熟度和具体过程能力成熟度评估。分为5个登记，CMMI5级最高。等级名称说明关键过程区域1级初始级（Initial）工作无序，不稳定，管理无章法，过程不可预测，难以控制且被动（成功看运气），项目成功完全依赖个人努力和英雄式核心任务的作用2级可重复级（Repeatable）建立了基本的管理规程，有章可循和较被动的项目级能力（稍有经验），有必要的过程准则来重复以前在同类项目中的成功。软件配置管理、软件质量保证、软件子合同管理、软件项目跟踪与监督、软件项目策划、软件需求管理3级已定义级（Defined）实现了标准化和文档化，建立了积极的组织级流程（合格），管理和工程两方面的软件过程已经文档化、标准化、并综合成整个软件开发组织的标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程来开发和维护软件。同行评审、组间协调、软件产品工程、集成软件管理、培训大纲、组织过程定义、组织过程集点4级已管理级（Managed）建立了定量的质量目标，过程可度量，可控制，制定了软件过程和产品质量的详细度量标准，对软件过程和产品质量有定量的理解和控制。软件质量管理和定量过程管理5级优化级（Optimizing）采用新技术、新方法，持续关注过程改进（高追求），加强了定量分析、通过来自过程质量反馈和来自新观念、新技术的反馈使过程不断持续地改进。过程更改管理、技术改革管理和缺陷预防2.2 能力成熟度模型集成CMMICMMI是若干过程模型的综合和改进，不仅仅软件，而是支持读个工程学科和领域的、系统的、一致的过程改进框架，能适应现代工程的特点和需要，能提高过程的质量和工作效率。其表示方法有阶段式模型和连续式模型。2.2.1 阶段式模型类似于CMM，它关注组织的成熟度，五个成熟度模型如下：能力等级特点关键过程区域初始级过程不可预测且缺乏控制已管理级过程为项目服务需求管理、项目计划、配置管理、项目监督与控制、供应商合同管理、度量和分析、过程和产品质量保证已定义级过程为组织服务需求开发、技术解决方案、产品集成、验证、确认组织级过程焦点、组织级过程定义、组织级培训、集成项目管理、风险管理、集成化的团队、决策分析和解决方案、组织集成环境定量管理过程已度量和控制组织过程性能、定量项目管理优化级集中于过程改进和优化组织级改革与实施、因果分析和解决方案2.2.2 连续式模型关注每个过程的能力，一个组织对不同的过程域可以达到不同的过程域能力等级。3 软件过程模型软件过程是制作软件产品的一组活动以及结果，这些活动主要有软件人员来完成，软件活动主要有以下：1> 软件描述：必须定义软件功能以及使用限制；2> 软件开发：即软件的设计和实现，软件工程人员制作出能满足描述的软件；3> 软件有效性验证：软件必须经过严格的验证，以保证能够满足客户的需求；4> 软件进化：软件随着客户需求的变化不断改进。3.1 瀑布模型瀑布模型（SDLC）：瀑布模型是一个经典的软件生命周期模型，一般将软件开发分为：可行性分析（计划）、需求分析、软件设计（概要设计、详细设计）、编码（含单元测试）、测试、运行维护等几个阶段。最经典的模型，讲究线性、稳扎稳打。特点：1> 从上一项开发活动接受该项活动的工作对象作为输入；2> 利用这一输入，实施该项活动应完成的工作内容；3> 给出该项活动的工作成果，作为输出传给下一项开发活动；4> 给该项活动的实施工作成果进行评审。若其工作成果得到确认，则继续进行下一项开发活动；否则返回前一项，甚至更前项的活动。尽量减少多个阶段间的反复，以相对来说较小的费用来开发软件。优点：文档驱动，全程组织管理规范，确认阶段性任务完成，才继续下一阶段任务；缺点：不适应用户需求变化；过程往往难以执行；开发过程式线性的，效果在末期才可见，增加了风险；场景：适用于项目需求清楚明确、变化较小；团队熟悉软件领域；用户使用环境稳定、参与度低的项目；3.2 螺旋模型螺旋模型是一个演化软件过程模型，将原型实现的迭代特征与线性顺序（瀑布）模型中控制的系统化的方面结合起来，在螺旋模型中，软件开发时一系列的增量发布。开发过程具有周期性重复的螺旋线状。四个象限分别标志每个周期锁划分的四个阶段：制定计划、风险分析、实施工程和客户评估。螺旋模型强调了风险分析，特别适用于庞大而复杂的、高风险的系统。瀑布模型+增量模型+风险分析1> 从制定计划开始，然后分线分析，如果通过则进入开发阶段，开发完成后再进行评估；2> 评估后又进入外一层螺旋进行下一次循环迭代，制定计划，风险分析；3> 直到项目开发完成或没有通过风险分析为止。优点：设计灵活；分段构建；保持客户始终参与交互；项目可控性好；缺点：要求具备较高的风险评估经验和知识，否则会造成重大损失；开发周期长，过多迭代和增加开发成本，延迟交付时间；场景：只适合大规模的软件项目，尤其是内部的；需求不明确，需要控制风险；3.3 V模型V模型从整体上看起来，就是一个V字型的结构，由左右两边组成。左边下画线分别代表了需求分析、概要设计、详细设计、编码，右边的上画线代表了单元测试、集成测试、系统测试与验收测试。V模型特点如下：1> 单元测试的主要目的是针对编码过程中可能存在的各种错误；2> 集成测试的主要目的是针对详细设计中可能存在的问题；3> 系统测试主要针对概要设计，检查系统作为一个整体是否有效地得到运行；4> 验收测试通常由业务专家或者用户进行，以确认产品能真正符合用户业务上的需要。5> V模型用于需求明确和需求变更不频繁的情形。思考：建房是边建就边用铅垂线，还是建好以后再去测量？优点：每个阶段都清晰，每个过程都可控；包含多种测试；缺点：测试介入较晚，难以发现和修改前期缺陷；测试和开发串行；场景：适用于传统项目开发，不适合高性能高风险或难以模块化的项目；3.4 原型化模型原型化模型第一步就是创建一个快速模型，能够满足项目干系人与未来的用户可以与原型进行交互，再通过与相关干系人进行充分的讨论和分析，最终弄清楚当前系统的需求，进行了充分的了解之后，在原型的基础上开发出用户满意的产品。原型法认为在很难一下子全面准确地提出用户需求的情况下，原型应当具备的特点如下：1> 实际可行；2> 具有最终系统的基本特征；3> 构造方便、快速、造价低。原型发的特点在于原型法对用户的需求是动态响应、逐步纳入的。经过和用户针对原型的讨论和交流，弄清需求，以便真正把握用户的需求。充分了解后，再在原型基础上开发。严格来说，不算一种模型，只是一种获取需求的方法。优点：可以得到较良好的定义，容易适应需求的变化；有利于开发和培训同步；开发费用降低，开发周期短，对用户更友好；缺点：客户与开发者对原型的理解不同；准确的原型设计比较困难；快速原型加上持续修改可能导致产品质量低下，可维护性差；场景：主要针对与小型快捷的，且需求不明确的项目。对所开发领域比较熟悉，且有快速原型开发工具；产品一直或者升级；3.5 增量模型增量模型，首先开发核心模块功能，而后与用户确认，之后再次开发次核心模块的功能，即每次开发一部分功能并与用户需求确认，最终完成项目开发，优先级最高的服务最先交付。将软件模块化，每模块为以增量组件，分别进行开发，所有增量叠加在一起就形成了最终的软件产品。每个增量分别开发时，都是一个瀑布模型，所以可以把增量模型看成是瀑布模型的升级版。特点：由于并不是从系统整体角度规划各个模块，因此不利于模块划分。难点在于如何将客户需求划分为多个增量。与原型不同的是增量模型每一次增量版本都可以作为独立可操作性的作品，而原型的构造一般是为了演示。优点：人员分配灵活，早起投入资源少；用户认可，则可加大投入；开发风险较小；缺点：并行开发可能遇到难继承的风险；软件必须可模块化，且具备开放式体系；场景：对已有版本升级或新版本开发；对完成期限要求很高；对所开发领域比较熟悉而且已有原型系统。3.6 喷泉模型喷泉模型是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法，使开发过程具有迭代性和无间隙性。3.7 基于构建的开发模型CBSDCBSD利用预先包装的构件来构造应用系统，构件可以是组织内部开发的构件，也可以是商品化成品软件构件。特点：增强了复用性，在系统开发过程中，会构件一个构件库，供其他系统复用，因此可以提高可靠性，节省时间和成本。3.7 形式化方法模型形式化方法模型是建立在严格数学基础上的一种软件开发方法，主要活动是生成计算机形式化的数学规格说明。3.8 敏捷模型互联网时代的软件开发方式，诞生于90年代，能够应对快速变化的需求，更注重软件开发中人的作用，强调面对面的沟通（比文档有效）。在互联网企业中被广泛应用。其开发宣言：个体和交互胜过过程和工具、可以工作的软件胜过面面俱到的文档、客户合作胜过合同谈判、相应变化胜过遵循计划。敏捷方法区别于其他方法的两个特点：是适应性的而非预设性；是面向人的而非面向过程的。敏捷方法的核心思想：敏捷方法是适应型，而非可预测型；敏捷方法是以人为本，而非以过程为本，要发挥人的特性；迭代增量式的开发过程，以原型开发思想为基础，采用迭代增量式开发，发行版小型化。优点：以人为本，充分利用每个开发者的优势；缺点：项目周期长，难以保证开发人员不更换；没有文档导致交接困难；核心思想：小步快跑、不断迭代；快速：最快速度交付，保持这种优势占有市场；高效：团队成员高效协同，保障持续交付价值；试错：通过低成本试错，找到客户真正需求；下面介绍主要敏捷方法。3.8.1 极限编程（XP）基础和价值观是交流、朴素、反馈和勇气，即任何一个软件项目都可以从4个方面入手改善：加强交流、从简单做起、寻求反馈、用于实事求是。XP是一种近螺旋式开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期，通过积极的交流、反馈以及其他一些列的方法，开发人员和客户可以分厂清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。XP提倡测试先行，为了将以后出现bug几率降到最低。3.8.2 水晶系列方法与XP方法一样，都有以人为中心的理念，但在实践上有所不同。其目的是发展一种提倡“机动性的”方法，包括具有共性的核心元素，每个都含独特的角色、过程模式、工作产品和实践。3.8.3 并列争球法（Scrum）是一种迭代的增量化过程，把每段时间（如30天）一次的迭代称为一个冲刺（sprint），并按需求的优先级别来实现产品，多个自组织和自治的小组并行地递增实现产品。3.8.4 特性驱动开发方法（FDD）特性驱动开发方法，是一个迭代的开发模型，认为有效迭代软件开发需要3个要素：人、过程和技术。有5个核心过程：开发整体对象模型、构造特征列表、计划特征开发、特征设计和特征构建。3.9 统一过程模型（RUP）RUP描述了如何有效地利用商业的、可靠的方法开发和部署软件，是一种重量级过程。RUP类似一个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针、模板以及事例支持。3.9.1 核心工作流RUP软件开发生命周期是一个二维的软件开发模型，RUP中有9个核心工作流，如下：1> 业务建模：理解待开发系统所在的机构及其商业运作，确保所有参与人员对待开发系统所在的机构有共同的认识，评估待开发系统对所在机构的影响；2> 需求：定义系统功能及用户界面，使客户知道系统的功能，使开发人员理解系统的需求，为项目预算及计划提供基础；3> 分析与设计：把需求分析的结果转化为分析与设计模型；4> 实现：把设计模型转换为实现结果，对开发的代码做单元测试，将不同实现人员开发的模块集成为可执行系统；5> 测试：检查各子系统之间的交互、集成，验证所有需求是否均被正确实现，对发现的软件质量上的缺陷进行归档，对软件质量提出改进建议；6> 部署：打包、分发、安装软件，升级旧系统；培训用户级销售人员，并提供技术支持；7> 配置与变更管理：跟踪并维护系统开发过程中产生的所有制品的完整性和一致性；8> 项目管理：为软件开发项目提供计划、人员分配、执行、监控等方面的指导，为风险管理提供框架；9> 环境：为软件开发机构提供软件开发环境，即提供过程管理和工具的支持。3.9.2 4个阶段RUP把软件开发生命周期划分为多个循环，每个循环生成产品的一个新的版本，每个循环依次由4个连续的阶段组成，每个阶段完成确定性的任务，这4个阶段如下：1> 初始阶段：定义最终产品视图和业务模型，并确定系统范围；2> 细化阶段：设计及确定系统的体系结构，制订工作计划及资源要求；3> 构造阶段：构造产品并继续演进需求、体系结构、计划直至产品提交；4> 移交阶段：把产品提交给用户使用。3.9.3 核心概念RUP中定义了一些核心概念，如下：1> 角色：WHO的问题，角色描述某个人或一个小组的行为与职责。RUP预先定义了很多角色，如体系结构师、设计人员、实现人员、测试员和配置管理人员等，并对每一个角色的工作和职责都做了详尽的说明；2> 活动：HOW的问题，活动是一个有明确目的的独立工作单元；3> 制品：WHAT的问题，制品是活动生成、创建或修改的一段信息；4> 工作流：When的问题，工作流描述了一个有意义的连续的活动序列，每个工作流产生一些有价值的产品，并显示了角色至今的关系。3.9.4 RUP特点1> 用例驱动：需求分析、设计、实现和测试等活动都是用例驱动的；2> 以体系结构为中心：包括系统的总体组织和全局控制、通信协议等，是一个多维的结构，会采用多个视图来描述。在典型的4+1视图模型中：a> 分析人员和测试人员关心的是系统的行为，会侧重于用例视图；b> 最终用户关心的是系统功能，会侧重于逻辑视图；c> 程序员关心的是系统配置、装配等问题，会侧重于实现视图；d> 系统集成人员关心的是系统的性能、可伸缩性、吞吐率等问题，会侧重于进程视图；e> 系统工程师关心的是系统的发布、安装、拓扑结构等问题，会侧重于部署视图。3> 迭代与增量：把整个项目开发分为多个迭代过程，在每次迭代中，只考虑系统的一部分需求，进行分析、设计、实现、测试和部署等过程，每次迭代是在已完成部分的基础上进行的，每次增加一些新的功能实现，以此进行下去，直至最后项目的完成。4 需求分析目的：弥合开发人员（懂技术）和用户（懂业务）之间可能存在的认识差异；任务：确定待开发软件的功能、性能、数据和界面等要求。4.1 需求分类序号分类说明举例1功能需求软件必须具备什么样的功能2非功能需求产品必须具备的属性或品质，如可靠性、性能、响应时间、容错性和扩展性系统2万人同时在线、99.99999%可靠性、响应时间在2s以内、语音识别准确度98%3设计约束也称为限制条件、补充规约，通常是对解决方案的约束说明业务环境（客户）：预算、法律法规；使用环境（客户）：用户群体、喜好；构建环境（开发）：团队实力、管理能力；技术环境：服务器、开发语言、技术趋势4.2 需求分析步骤序号步骤说明1确定系统综合要求包括系统界面要求（外部特征：输入输出数据）、功能要求、性能要求（响应时间、吞吐量、处理时间、主外存限制等）、安全和保密性要求、可靠性要求、运行要求（软硬件和通信接口等）、异常处理（资源故障、不合法输入、非法操作和数组越界等）要求和未来可能的要求。2分析系统数据要求包括基本数据元素、数据元素之间的逻辑关系、数据量和峰值等。常用数据描述方式是实体-关系模型（E-R）模型3导出系统逻辑模型在结构化分析方法中可用数据流图来描述；在面向对象分析方法中可用类模型来描述。4修正项目开发计划更准确地估算软件成本和进度，修正项目开发计划；5开发演示原型需求不明确时，可先开发原型系统，用于验证用户需求；4.3 需求管理需求管理包括变更控制、版本控制、需求跟踪、需求状态跟踪。变更控制包括：建议变更、分析影响、做出决策、交流、合并、测量需求的稳定性；版本控制包括：确定需求文档版本、确定单个需求文档版本；需求跟踪包括：定义对其他需求的连接链、定义对其他系统元素的连接链；需求状态跟踪包括：定义需求状态、跟踪需求每一个状态。4.3.1 需求变更管理需求变更管理师需求管理的重要内容，需求变更管理的过程主要包括问题分析和变更表述、变更分析和成本计算、变更实现。具体来说，需求变更是因为需求发生变化。根据软件工程思想，需求说明书一般要经过论证，如果在需求说明书经过论证后，需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减，均属于需求变更，因此需求变更必然会带来响应的问题。4.4 结构化分析方法结构化分析（Structured Analysis，SA）方法是一种面向数据流的需求分析方法，适用于分析大型数据处理系统，其基本思想是自顶向下逐层分解。SA方法的分析结果由一套分层的数据流图、一本数据字典、一组小说明（也成加工逻辑）、补充材料组成。4.4.1 数据流图数据流图又被称为数据流程图（Data Flow Diagram，DFD），是一种便于用户理解、分析系统数据流程的图形工具。摆脱了系统物理内容，精确地在逻辑上描述系统功能、输入、输出和数据存储等，是系统逻辑模型重要组成部分。4.4.1.1 DFD基本成分序号成分说明备注1数据流有一组固定成分的数据组成，表示数据流向每个数据流都必须有名字（除流入和流出）注：是数据流，非控制流2加工描述了输入数据流到输出数据流之间的变换每个加工都有名字和编号（分层DFD的层次和图，属于子加工）3数据存储表示存储的数据每个数据存储都有名称4外部实体存在于软件系统之外的人员或组织指出系统所需数据的发源地和所产生的数据的归宿地4.4.1.2 分层数据流图的画法1> 画系统的输入和输出。把整个软件系统看做一个大的加工，然后根据系统从哪些外部实体接收数据流，以及系统发送数据流到哪些外部实体，就可以画出系统的输入和输出图，这张图称为顶层图。2> 画系统的内部。将顶层图的加工分解成若干个加工，并用数据流将这些加工连接起来，使得顶层图中的输入数据经过若干个加工处理后变成顶层图的输出数据流。这张图称为0层图。从一个加工画出一张数据流图的过程实际上就是对这个加工的分解。确定数据流的方法：当用户把若干个数据看做一个单位来处理（这些数据一起到达，一起加工时），可把这些数据看成一个数据流。对于一些以后某个时间要使用的数据可以组织成一个数据存储来表示。3> 画加工的内部。把每个加工看做一个小系统，该加工的输入输出数据流看成小系统的输入输出数据流。于是可以用画0层图同样的方法画出每个加工的DFD子图。4> 对第3步分解出来的DFD子图中的每个加工，重复第3步分解，直至图中尚未分解的加工都足够简单（也就是说这种加工不必再分解）为止。至此，得到了一套分层数据流图。对图和加工进行编号对于一个软件系统，其数据流图可能有许多层，每一层又有许多张图，为了区分不同的加工和不同的DFD子图，应该对每张图和每个加工进行编号，以利于管理。1> 父图与子图。假设分层数据流图里的某张图（图A）中的某个加工可用另一张图（图B）来分解，称图A是图B的父图，图B是图A的子图。在一张图中，有些加工需要进一步分解，有些加工则不必分解。因此如果父图中有n个加工，那么它可以用0~n个子图，但每张子图都只对应一张父图。2> 编号。1）顶层图只有一张，图中的加工也只有一个，所以不必编号。2）0层图只有一张，图中的加工可以分别是0.1，0.2，...，或者是1，2...。3）子图号就是附图中被分解的加工号。4）图的加工号由图号、圈点和序号组成。4.4.1.3 实例某考务处理系统有如下功能：1> 对考生送来的报名单进行检查；2> 对合格的报名单进行检查；3> 对阅卷站送来的成绩单进行检查，并根据考试中心指定的合格标准审定合格者；4> 制作考生通知单（内含成绩合格/不合格标志）送给考生；5> 按地区、年龄、文化程度、职业和考试级别进行成绩分类统计和试题难度分析，产生统计分析表。该考务系统的分层数据流图如下图所示：4.4.1.4 应注意的问题1> 适当地位数据流、加工、数据存储、外部实体命名，名字反映该成分的实际含义，避免空洞的名字；2> 画数据流而不要画控制流；3> 每条数据流的输入或者输出都是加工；4> 一个加工的输出数据流不应与输入数据流同名，即使它们的组成成分相同；5> 允许一个加工有多条数据流流向另一个加工，也允许一个加工有两个相同的输出数据流流向两个不同的加工；6> 保持父图与子图的平衡。即父图中某加工的输入输出数据必须与它的子图的输入输出数据流在数量和名字上相同。7> 在自顶向下的分解过程中，若一个数据存储首次出现时只与一个加工有关，那么这个数据存储应作为这个加工的内部文件而不必画出；8> 保持数据守恒，即一个加工所有输出数据流中的数据必须能从该加工的输入数据流中直接获得，或者是通过该加工能产生的数据；9> 每个加工必须既有输入数据流，又有输出数据流；10> 在整套数据流图中，每个数据存储必须既有读的数据流，又有写的数据流，但在某一张子图中可能只有读没有写，或者只有写没有读。5 逆向工程软件复用是将已有软件的各种有关知识用于建立新的软件，以缩减软件开发和维护的花费。软件复用是提高软件生产力和质量的一种重要技术。早起的软件复用主要是代码级复用，被复用的知识专指程序，后来扩大到包括领域知识、开发经验、设计决定、体系结构、需求、设计、代码和文档等一切有关方面。逆向工程：软件的逆向工程师分析程序，力图在比源代码更高抽象层次上建立程序的表示过程，逆向工程是设计的恢复过程，其包含4个级别：1> 实现级：包括程序的抽象语法树、符号表、过程的设计表示；2> 结构级：包括反映程序分量之间相互依赖关系的信息，例如调用图、结构图、程序和数据结构；3> 功能级：包括反映程序段功能及程序段之间关系的信息，例如数据和控制流模型；4> 领域级：包括反映程序分量和程序诸实体与应用领域概念之间对应关系的信息，例如E-R模型。其中，领域级抽象级别最高，完备性最低；实现级抽象级别最低，完备性最高。与逆向工程相关的概念有重构、设计恢复、再工程和正向工程。1> 重构是指在同一抽象级别上转换系统描述形式；2> 设计恢复是指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息；3> 再工程是指在逆向工程所获得信息的基础上，修改或重构已有的系统，产生系统的一个新版本。再工程师对现有系统的重新开发过程，包括逆向工程、新需求的考虑过程和正向工程三个步骤。它不仅能从已存在的程序中重新获得设计信息，而且还能使用这些信息来重构现有系统，以改进它的综合质量。在利用再工程重构现有系统的同时，一般会增加新的需求，包括增加新的功能和改善系统的性能；4> 正向工程是指不仅从现有系统中恢复设计信息，而且使用该信息取改变或重构现有系统，以改善其整体质量。6 面向对象开发面向对象分析方法（Object-Oriented Analysis，OOA）的基本任务是运用OO方法，对问题于进行分析和理解。6.1 面向对象的基本概念6.1.1 对象对象：基本的运行时的实体，既包括数据（属性），也包括作用与数据的操作（行为）。一个对象通常可由对象名、属性和操作三部分组成。6.1.2 消息消息：对象之间进行通信的一种构造叫作消息。消息体现了对象之间的交互，通过它向目标对象发送操作请求。6.1.3 类类：定义了一组大体上相似的对象，一个类锁包含的方法和数据描述一组对象的共同行为和属性。类是在对象之上的抽象，对象时类的具体化，是类的实例（instance）。在分析和设计时，通常把注意力放在类上。类可以分为实体类、结构类（边界类）和控制类三种。1> 实体类的对象表示显示世界中真实的实体，如人、物等。2> 接口类的对象为用户提供一种与系统合作交互的方式，分为人和系统两大类，其中人的接口可以是显示屏、窗口、web窗体、对话框、菜单、列表框、其他显示控制、条形码、二维码或者用户与系统交互的其他方法；系统接口涉及到把数据发送到其他系统，或者从其他系统接收数据。3> 控制类的对象用来控制活动流，充当协调者。6.1.4 封装封装是一种信息隐蔽技术，将相关的概念组成一个单元模块，并通过一个名称来引用。面向对象封装是将数据和基于数据的操作封装成一个整体对象，对数据的访问或修改只能通过对象对外提供的接口进行。6.1.5 继承继承：父类和子类之间共享数据和方法的机制，表示类之间的层次关系，这种关系使得某类对象可以继承另外一类对象的特征，又可分为单继承和多继承。6.1.6 多态多态：不同的对象收到同一消息可以产生完全不同的结果，这一现象叫作多态（polymorphism）。多态包括参数多态（不同类型参数多种结构类型）、包含多态（父子类型关系）、过载多态（类似于重载，一个名字不同含义）、强制多态（强制类型转换）四种类型。多态由继承机制支持，将通用消息放在抽象层，具体不同的功能实现放在底层。6.1.7 绑定绑定：绑定是一个把过程调用和响应调用所需执行的代码加以结合的过程。在一般程序设计语言中，绑定是在编译时进行的，叫作静态绑定。动态绑定是在运行时进行的，在运行过程中，当一个对象发送消息请求服务时，要根据接受对象的具体情况将请求的操作与实现的方法进行连接。6.1.8 抽象抽象：通过特定的实例抽取共同特征以后形成概念的过程。它强调主要特征，忽略次要特征。一个对象是现实世界中一个实体的抽象，一个类是一组对象的抽象，抽象是一种单一化的描述，它强调给出与应用相关的特性，抛弃不相关的特性。6.1.9 接口接口描述操作规范的说明，其只能说明操作应该做什么，并没有定义操作如何做。6.1.10 覆盖子类在原有父类接口的基础上，用适合于自己要求的实现去置换父类中相应实现，即在子类中重定义一个与父类同名同参的方法。6.1.11 函数重载与覆盖要区分，函数重载与子类父类无关，且函数是同名不同参数。6.2 面向对象分析面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型构成。面向对象的分析是为了确定问题域，理解问题。包含五个活动：认定对象、组织对象、描述对象间的相互作用、确定对象的操作、定义对象的内部信息。6.3 面向对象设计面向对象设计时设计分析模型和实现相应源代码，设计问题域的解决方案，与技术相关。OOD同样遵循抽象、信息隐蔽、功能独立、模块化等设计准则。面向对象设计模型则包含以包图表示的软件体系结构图、以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图和用以描述流程化处理过程的活动图等。6.3.1 面向对象设计原则1> 单一责任原则：就一个类而言，应该仅有一个引起它变化的原因，即当需要修改某个类的时候原因有且只有一个，让一个类只做一种责任类型。2> 开放-封闭原则：软件实体（类、模块、函数等）应该是可以扩展的，即开放的；但是不可修改的，即封闭的；3> 里氏替换原则：子类型必须能够替换掉它们的基类，即在任何父类可以出现的地方，都可以用子类的实体来赋值给父类型的引用；4> 依赖倒置原则：抽象不应该依赖于细节，细节应该依赖于抽象，即高层模块不应该依赖于低层模块，二者都应该依赖于抽象；5> 接口分离原则：不应该强迫客户依赖于它们不用的方法，接口属于客户，不属于它所在的类层次结构。即依赖于抽象，不要依赖于具体，同时在抽象级别不应该有对于细节的依赖。这样做的好处就在于可以最大限度地应对可能的变化。除了上述五大原则外，Robert C.Martin提出的面向对象设计原则还包括：1> 重用发布等价原则：重用的粒度就是发布的粒度；2> 共同封闭原则：包中的所有类对于同一类性质的变化应该是共同封闭的，一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响；3> 共同重用原则：一个包中所有类应该是共同重用的，如果重用了包中的一个类，那么就要重用包中所有的类；4> 无环依赖原则：在包的依赖关系图中不允许存在环，即包之间的结构必须是一个直接的无环图形；5> 稳定依赖原则：朝着稳定的方向进行依赖；6> 稳定抽象原则：包的抽象程度应该和其稳定程度一致。6.3.2 统一建模语言UML概述UML是面向对象软件的标准化建模语言，由构造块、规则和公共机制三个要素构成。UML（Unified Modeling Language）统一建模语言，UML是一种为面向对象系统的产品进行说明、可视化和编制文档的一种标准语言。具有严格的语法和语义规范，采用一组图形符号来描述软件模型，是软件建模的重要工具。可以建立需求模型、逻辑模型、设计模型和实现模型。UML作用1> 为软件系统建立可视化模型；2> 为软件系统建立构件（模型->多种语言代码）；3> 为软件系统建立文档；静态图：用例图、类图、对象图、包图、构件图、部署图；动态图：状态图、活动图、协作图、序列图；逻辑视图logicalview：主要支持系统的功能需求，即系统提供给最终用户的服务，设计的对象模型（使用面对象的设计方法时）；开发视图developmentview：也称为模块视图，在UML中被称为实现视图，主要侧重于软件模块的组织和管理，通过系统I/O关系的模型图和子系统图来描述，主要描述在开发环境中软件的静态组织结构，类图属于开发视图；进程视图processview：侧重于系统的运行特性，主要关注一些非功能性需求，例如系统的性能和可用性等，强调并发性、分布性、系统集成性和容错能力，定义了逻辑视图中的各个类的操作具体是在哪一个线程中被执行的；物理视图physicalview：在UML中被称为部署视图，它主要考虑如何把软件映射到硬件上，通常要考虑到解决系统拓扑结构、系统安装和通信等问题。6.3.3 UML图1> 功能模型：从用户的角度展示系统的功能，包括用例图（谁使用系统，用系统可以做什么）；2> 对象模型：采用对象、属性、操作、关联等概念展示系统的结构基础，包括类图、对象图等；3> 动态模型：展现系统的内部行为，包括时序图（序列图）、活动图、状态图等；6.3.3.1 类图类图属于静态图。依赖：一个事物的语义依赖于另一个事物的语义变化而变化；关联：是一种结构关系，描述了一组链，链式对象之间的连接，分为组合和聚合，都是都部分和整体的关系，其中组合事物之间的关系更强。两个类之间的关联，实际上是两个类所扮演角色的关联，因此两个类之间可以有多个由不同角色标识的关联。泛化：一般/特殊的关系，子类和父类之间的关系；实现：一个类指定了另一个类保证执行的契约。6.3.3.2 对象图6.3.3.3 用例图用例图是静态图，展现了一组用例、参与者以及它们之间的关系。用例图中的参与者是人、硬件或其他系统可以扮演的角色；用例是参与者完成的一些列操作，用例之间的关系有扩展、包含、泛化。6.3.3.4 序列图序列图也成为顺序图，属于动态图，是场景的图形化表示，描述了以时间顺序组织的对象之间的交互活动。有同步消息（进行阻塞调用，调用者中止执行，等待控制权返回，需要等待返回消息，用实心三角箭头表示）、异步消息（发出消息后继续执行，不引起调用者阻塞，也不等待返回消息，由空心箭头表示）、返回消息（由从右到左的虚线箭头表示）三种。6.3.3.5 通信图通信图也成协作图，属于动态图，强调参加交互的对象的组织，如下：6.3.3.6 状态图状态图（State Diagram）：属于动态视图，描述单个对象在多个用例中的行为，包括简单状态和组合状态。转换可以通过事件触发器触发，事件触发后相应的监护条件会进行检查。状态图中转换和状态是两个独立的概念，如下方框代表状态，箭头代表触发事件，实心圆点为起点和终点。6.3.3.7 活动图活动图（activity diagram）：属于动态视图，是一种特殊的状态图，展现了系统内从一个活动到另一个活动的流程。活动的分岔和混合线是一条水平粗线，其下有并发分岔、并发回合、监护表达式、分支、流等操作，每个分岔的分支代表了可同时运行的线程数。活动图能够并行执行的是在一个分叉粗线下的分支上的活动。6.3.3.8 组件图组件图（componnet diagram）：又称构件图，属于静态视图，显示组件以及他们之间依赖关系。6.3.3.9 部署图部署图（deployment diagram，配置图）：显示系统中软件和硬件的物理架构。协作图（collaboration diagram）：属于动态视图，显示了一系列对象和在这些对象之间的联系以及对象间发送和接受的消息；6.4 面向对象的测试一般来说，面向对象的测试可分为4个层次。1> 算法层：测试类中定义的每个方法，基本上相当于传统软件测试中的单元测试；2> 类层：测试封装在同一个类中的所有方法与属性之间的相互作用。在面向对象软件中类是基本模块，因此可以认为这是面向对象测试中所特有的模块测试；3> 模板层：测试一组协同工作的类之间的相互作用，大体上相当于传统软件测试中的集成测试，但是也有面向对象软件的特点（例如对象之间通过发送消息相互作用）。4> 系统层：把各个子系统组装成完整的面向对象软件系统，在组装过程中同时进行测试。}

1、你的测试职业发展是什么?测试经验越多，测试能力越高。所以我的职业发展是需要时间积累的，一步步向着高级测试工程师奔去。而且我也有初步的职业规划，前3年积累测试经验，按如何做好测试工程师的要点去要求自己，不断更新自己改正自己，做好测试任务。2、你认为测试人员需要具备哪些素质做测试应该要有一定的协调能力，因为测试人员经常要与开发接触处理一些问题，如果处理不好的话会引起一些冲突，这样的话工作上就会不好做。还有测试人员要有一定的耐心，有的时候做测试很枯燥乏味。除了耐心，测试人员不能放过每一个可能的错误。3、你为什么能够做测试这一行虽然我的测试技术还不是很成熟，但是我觉得我还是可以胜任软件测试这个工作的，因为做软件测试不仅是要求技术好，还有有一定的沟通能力，耐心、细心等外在因素。综合起来看我认为我是胜任这个工作的。4、测试的目的是什么?测试的目的是找出软件产品中的错误，是软件尽可能的符合用户的要求。当然软件测试是不可能找出全部错误的。5、测试分为哪几个阶段?一般来说分为5个阶段：单元测试、集成测试、确认测试、系统测试、验收测试6、单元测试的测试对象、目的、测试依据、测试方法?测试对象是模块内部的程序错误，目的是消除局部模块逻辑和功能上的错误和缺陷。测试依据是模块的详细设计，测试方法是采用白盒测试。7、怎样看待加班问题加班的话我没有太多意见，但是我还是觉得如果能够合理安排时间的话，不会有太多时候加班的。8、结合你以前的学习和工作经验，你认为如何做好测试。根据我以前的工作和学习经验，我认为做好工作首先要有一个良好的沟通，只有沟通无障碍了，才会有好的协作，才会有更好的效率，再一个就是技术一定要过关，做测试要有足够的耐心，和一个良好的工作习惯，不懂的就要问，实时与同事沟通这样的话才能做好测试工作。9、你为什么选择软件测试行业因为之前了解软件测试这个行业，觉得他的发展前景很好。10、根据你以前的工作或学习经验描述一下软件开发、测试过程，由哪些角色负责，你做什么要有架构师、开发经理、测试经理、程序员、测试员。我在里面主要是负责所分到的模块执行测试用例。11、根据你的经验说说你对软件测试/质量保证的理解软件质量保证与测试是根据软件开发阶段的规格说明和程序的内部结构而精心设计的一批测试用例(即输入数据和预期的输出结果)，并根据这些测试用例去运行程序，以发现错误的过程。它是对应用程序的各个方面进行测试以检查其功能、语言有效性及其外观排布。12、软件测试的流程是什么?需求调查：全面了解系统概况、应用领域、软件开发周期、软件开发环境、开发组织、时间安排、功能需求、性能需求、质量需求及测试要求等。根据系统概况进行项目所需的人员、时间和工作量估计以及项目报价。制定初步的项目计划。测试准备：组织测试团队、培训、建立测试和管理环境等。测试设计：按照测试要求进行每个测试项的测试设计，包括测试用例的设计和测试脚本的开发等。测试实施：按照测试计划实施测试。测试评估：根据测试的结果，出具测试评估报告。13、你对SQA的职责和工作活动(如软件度量)的理解?SQA就是独立于软件开发的项目组，通过对软件开发过程的监控，来保证软件的开发流程按照指定的CMM规程(如果有相应的CMM规程),对于不符合项及时提出建议和改进方案，必要时可以向高层经理汇报以求问题的解决。通过这样的途径来预防缺陷的引入，从而减少后期软件的维护成本。SQA主要的工作活动包括制定SQA工作计划，参与阶段产物的评审，进行过程质量、功能配置及物理配置的审计等;对项目开发过程中产生的数据进行度量等等。14、说说你对软件配置管理的理解项目在开发过程中要用相应的配置管理工具对配置项(包括各个阶段的产物)进行变更控制，配置管理的使用取决于项目规模和复杂性及风险的水平。软件的规模越大，配置管理就越显得重要。还有在配置管理中，有一个很重要的概念，那就是基线，是在一定阶段各个配置项的组合，一个基线就提供了一个正式的标准，随后的工作便基于此标准，并只有经过授权后才能变更这个标准。配置管理工具主要有CC，VSS,CVS,SVN等，我只用过SVN，对其他的工具不是很熟悉。15、怎样写测试计划和测试用例简单点，测试计划里应有详细的测试策略和测试方法，合理详尽的资源安排等，至于测试用例，那是依赖于需求(包括功能与非功能需求)是否细化到功能点，是否可测试等。16、说说主流的软件工程思想(如CMM、CMMI、RUP,XP,PSP,TSP等)的大致情况及对他们的理解CMM:SW Capability Maturity Model软件能力成熟度模型，其作用是软件过程的改进、评估及软件能力的评鉴。CMMI:Capability Maturity Model Integration能力成熟度模型集成 CMMI融入了大部分最新的软件管理实践，同时弥补了SW-CMM模型中的缺陷。RUP:rational unified process是软件工程话过程。XP:extreme program，即极限编程的意思，适用于小型团队的软件开发，像上面第三个问题就可以结合原型法采用这样的开发流程。要明白测试对于xp开发的重要性，强调测试(重点是单元测试)先行的理念。编程可以明显提高代码的质量，持续集成对于快速定位问题有好处。PSP，TSP分别是个体软件过程和群体软件过程。大家都知道，CMM只是告诉你做什么但并没有告诉你如何做，所以PSP/TSP就是告诉你企业在实施CMM的过程中如何做，PSP强调建立个人技能(如何制定计划、控制质量及如何与其他人相互协作等等)。而TSP着重于生产并交付高质量的软件产品(如何有效的规划和管理所面临的项目开发任务等等)。总之，实施CMM，永远不能真正做到能力成熟度的提升，只有将实施CMM与实施PSP和TSP有机结合起来，才能发挥最大的效力。因此，软件过程框架应该是CMM/PSP/TSP的有机集成。17、你是怎样保证软件质量的，也就是说你觉得怎样才能最大限度的保证软件的质量?测试并不能够最大限度的保证软件的质量，软件的高质量是开发和设计出来的，而不是测试出来的，它不仅要通过对软件开发流程的监控，使得软件开发的各个阶段都要按照指定的规程进行，通过对各个阶段产物的评审，QA对流程的监控，对功能及配置的审计来达到开发的最优化。当然测试也是保证软件质量的一个重要方式，是软件质量保证工程的一个重要组成部分。18、基于目前中国的国情，大多数公司的项目进度紧张、人员较少、需求文档根本没有或者很不规范，你认为在这种情况下怎样保证软件的质量?(大多数公司最想知道的就是在这种困难面前你该怎么保证软件的质量，因为这些公司一般就是这种情况--既不想投入过多又想保证质量)出现以上的情况，如果仅仅想通过测试来提高软件质量，那几乎是不可能的，原因是没有足够的时间让你去测试，少而不规范的文档导致测试需求无法细化到足够且有针对行的测试。所以，作为公司质量保证的因该和项目经理确定符合项目本身是和的软件生命周期模型(比如RUP的建材，原型法)，明确项目的开发流程并督促项目组按照此流程开展工作，所有项目组成员(项目经理更加重要)都要制定出合理的工作计划，加强代码的单元测试，在客户既定的产品交付日期范围内，进行产品的持续集成等等，如果时间允许可以再配合客户进行必要的系统功能测试。19、一个测试工程师应该具备哪些素质和技能?1-掌握基本的测试基础理论2-本着找出软件存在的问题的态度进行测试，不要以挑刺的形象出现3-可熟练阅读需求规格说明书等文档4-以用户的观点看问题5-有强烈的质量意识6-细心和责任心7-良好的有效的沟通方式(与开发人员及客户)8-具有以往的测试经验能够及时准确的判断出高危险区在何处20、做好软件测试的一些关键点1-测试人员必须经过测试基础知识和理论的相关培训2-测试人员必须熟悉系统功能和业务3-测试要有计划，而且测试方案要和整个项目计划协调好4-必须实现编写测试用例，测试执行阶段必须根据测试用例进行5-易用性，功能，分支，边界，性能等功能行和非功能性需求都要进行测试6-对于复杂的流程一定要进行流程分支，组合条件分析，再进行等价类划分准备相关测试数据7-测试设计的一个重要内容是要准备好具体的测试数据，清楚这个测试数据是测试那个场景或分支的。8-个人任务平均每三个测试用例至少应该发现一个BUG，否则只能说明测试用例质量不好9-除了每天构建的重复测试可以考虑测试自动化外，其他暂时都不要考虑去自动话21、软件测试员自身素质培养1-首先，应对软件测试感兴趣和对自己有自信，如果具备了这两点，那么在开发过程中不管遇到什么样的困难，相信一定能克服2-善于怀疑，实际上没有绝对正确的，总有错误的地方，具有叛逆心理，别人认为不可能发生的事情，我却认为可能发生，别人认为是对的，我却认为不是对的。3-打破沙锅问到底的精神，对于只出现过一次的BUG一定要找出原因，不解决誓不罢休。4-保持一个良好的心情，否则可能无法把测试做好。不要把生活中的不愉快的情绪带到工作中来。5-做测试时要细心，不是所有的BUG都能很容易找出，一定要细心才能找到这些BUG。6-灵活一些，聪明一点，多造一些容易产生BUG的例子。7-在有条件的情况下，多和客户沟通，他们身上有你所需要的。8-设身处地为客户着想，从他们的角度去测试系统。9-不要让程序员，以“这种情况不可能发生”这句话说服你，相反，你应该去说服他，告诉他在客户心理，并不是这样的10-考虑问题要全面，结合客户的需求，业务流程和系统的架构等多方面考虑问题。11-提出问题不要复杂化，这点和前面矛盾，如果你是一个新手，暂时不要管这点，因为最终将有你的小组成员讨论解决。12-追求完美，对于新测试员来说，努力追求完美，这对你很好，尽管有些事情无法做到，但你应该尝试。13-幽默感，能和开发小组很好的沟通是关键，试着给你的开发小组找一个BUG杀手，或对他们说“我简直不敢相信，你写的程序居然到现在没有找到BUG”。22、为什要在一个团队中开展测试工作?因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样，测试同样也需要质量认证，这个时候就需要在团队中开展软件测试的工作。在测试的过程中发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。23、你所熟悉的软件测试类型有哪些?测试类型有：功能测试、性能测试、界面测试功能测试在测试工作中占有比例最大，功能测试也叫黑盒测试。性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。区别在于，功能测试关注产品的所有功能，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注产品整体的多用户并发下的稳定性和健壮性。界面测试则关注与用户体验相关内容，用户使用该产品的时候是否已用，是否易懂，是否规范(用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告)。做某个性能测试的时候，首先它可能是个功能点，首先要保证她的功能是没有问题的，然后再考虑性能的问题。24、你认为做好测试用例设计工作的关键是什么白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结构。黑盒测试用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题。软件的黑盒测试意味着测试要在软件的接口处进行，这种方法是把测试对象看作是一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或者数据驱动测试。黑盒测试主要是为了发现以下几类错误：、1-是否有不正确或遗漏的功能2-在接口上，输入是否能正确的接受?能否输出正确的结果。3-是否有数据结构错误或外部信息(例如数据文件)访问错误4-性能上是否能够满足要求5-是否有初始化或终止性错误软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看作一个打开的盒子，它允许测试人员利用程序内部的逻辑结构和有关信息，设计或者选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一直。因此白盒测试又称为结合测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：1-对程序模块的所有独立的执行路径至少测试一遍。2-对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。3-在循环的边界和运行的界限内执行循环体。4-测试内部数据结构的有效性，等等。25、请详细介绍一下各种测试类型的含义1-单元测试(模块测试)是开发者编写的一小段代码，用于检验被测试代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。2-集成测试(也叫组装测试、联合测试)是单元测试的逻辑扩展。它最简单的形式是：两个已经经过测试的单元组合成一个组件，并且测试它们之间的接口。从这一层上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。3-系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中制定功能的有效方法。(常见的联调测试)。系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求而遵循系统设计。4-验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让用户将其执行软件的既定功能和任务。验收测试是向未来的用户表明系统能够像预订要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。26、测试计划工作的目的是什么?测试计划工作的内容都包括什么?其中哪些是最重要的?软件测试计划是知道测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试策略和测试方法(最好能先评审)。27、您认为做好测试计划工作的关键是什么?1-明确测试的目标，增强测试计划的实用性编写软件测试计划的重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果准确2-坚持“5W”规则，明确内容与过程“5W”规则指的是“WHAT(做什么)”、“WHY(为什么做)”、"WHEN(何时做)"、"WHERE(在哪里)"、"HOW(如何做)"。利用“5W"规则创建软件测试计划，可以帮助测试团队理解测试的目的(WHY)，明确测试的范围和内容(WHAT)，确定测试的开始和结束日期(WHEN)，指出测试的方法和工具(HOW)，给出测试文档和软件存放的位置(WHERE)。3-采用评审和更新机制，保证测试计划满足实际需求测试计划完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。4-分别创建测试计划与测试详细规格、测试用例应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。28、当开发人员说不是BUG时，你如何应付?开发人员说不是BUG，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动。3方商量确定好后再看要不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的一句是什么?如果被用户发现或出了问题，会有什么不良结果?程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来，跟开发经理和测试经理进行确认，如果要修改就改，如果不要修改就不改。其实有些真的不是BUG，我也只是建议的方式写进测试文档中，如果开发人员不修改也没有大问题。如果不是BUG的话，一定要坚持自己的立场，让问题得到最后的确认。29、你自认为测试的优势在哪里?优势在于我对测试坚定不移的信心和热情，虽然经验还不足，但测试需要的基本技能我有信心在工作中得以发挥。30、什么是系统瓶颈?瓶颈主要是指整个软硬件构成的软件系统某一方面或者几个方面能力不能满足用户的特定业务要求，“特定”是指瓶颈会在某些条件下会出现，因为毕竟大多数系统在投入前。严格的从技术角度讲，所有的系统都会有瓶颈，因为大多数系统的资源配置不是协调的，例如CPU使用率刚好达到100%时，内存也正好耗尽的系统不是很多见。因此我们讨论系统瓶颈要从应用的角度讨论：关键是看系统能否满足用户需求。在用户极限使用系统的情况下，系统的响应仍然正常，我们可以认为改系统没有瓶颈或者瓶颈不会影响用户工作。因此我们测试系统瓶颈主要是实现下面两个目的：-发现“表面”的瓶颈。主要是模拟用户的操作，找出用户极限使用系统时的瓶颈，然后解决瓶颈，这是性能测试的基本目标。-发现潜在的瓶颈并解决，保证系统的长期稳定性。主要是考虑用户在将来扩展系统或者业务发生变化时，系统能够适应变化。满足用户目前需求的系统不是最好的，我们设计系统的目标是在保证系统整个软件生命周期能够不断适应用户的变化，或者通过简单扩展系统就可以适应新的变化。31、文档测试主要包含什么内容?在国内软件开发管理中，文档管理几乎是最弱的一项，因而在测试工作中特别容易忽略文档测试也就不足为奇了。要想给用户提供完整的产品，文档测试是必不可少的。文档测试一般注重下面几个方面：文档的完整性：主要是测试文档内容的全面性与完整性，从总体上把握文档的质量。例如用户手册应该包括软件的所有功能模块。描述与软件实际情况的一致性：主要测试软件文档与软件实际的一致程度。例如用户手册基本完整后，我们还要注意用户手册与实际功能描述是否一致。因为文档往往跟不上软件版本的更新速度。易理解性：主要是检查文档对关键、重要的操作有无图文说明，文字、图表是否易于理解。对于关键、重要的操作仅仅只有文字说明肯定是不够的，应该附有图表使说明更为直观和明了。文档中提供操作的实例：这项检查内容主要针对用户手册。对主要功能和关键操作提供的应用实例是否丰富，提供的实例描述是否详细。只有简单的图文说明，而无实例的用户手册看起来就像是软件界面的简单拷贝，对于用户来说，实际上没有什么帮助。印刷与包装质量：主要是检查软件文档的商品化程度。有些用户手册是简单打印、装订而成，过于粗糙，不易于用户保存。优秀的文档例如用户手册和技术白皮书，应提供商品化包装，并且印刷精美。32、功能测试用例需要详细到什么程度才是合格的?这个问题也是测试工程师经常问的问题。有人主张测试用例详细到每个步骤执行什么都要写出来，目的是即使一个不了解系统的新手都可以按照测试用例来执行工作。主张这类写法的人还可以举出例子：欧美、日本等软件外包文档都是这样做的。另外一种观点就是主张写的粗些，类似于编写测试大纲。主张这种观点的人是因为软件开发需求管理不规范，变动十分频繁，因而不能按照欧美的高标准来编写测试用例。这样的测试用例容易维护，可以让测试执行人员有更大的发挥空间。实际上，软件测试用例的详细程度首先要以覆盖到测试点为基本要求。举个例子：“用户登陆系统”的测试用例可以不写出具体的执行数据，但是至少要写出五种以上情况()，如果只用一句话覆盖了这个功能是不合格的测试用例。覆盖功能点不是指列出功能点，而是要写出功能点的各个方面(如果组合情况较多时可以采用等价划分)。另一个影响测试用例的就是组织的开发能力和测试对象特点。如果开发力量比较落后，编写较详细的测试用例是不现实的，因为根本没有那么大的资源投入，当然这种情况很随着团队的发展而逐渐有所改善。测试对象特点重点是指测试对象在进度、成本等方面的要求，如果进度较紧张的情况下，是根本没有时间写出高质量的测试用例的，甚至有些时候测试工作只是一种辅助工作，因而不编写测试用例。因此，测试用例的编写要根据测试对象特点、团队的执行能力等各个方面综合起来决定编写策略。最后要注意的是测试人员一定不能抱怨，力争在不断提高测试用例编写水平的同时，不断地提高自身能力。33、配置和兼容性测试的区别是什么?配置测试的目的是保证软件在其相关的硬件上能够正常运行，而兼容性测试主要是测试软件能否与不同的软件正确协作。配置测试的核心内容就是使用各种硬件来测试软件的运行情况，一般包括：(1)软件在不同的主机上的运行情况，例如Dell和Apple;(2)软件在不同的组件上的运行情况，例如开发的拨号程序要测试在不同厂商生产的Modem上的运行情况;(3)不同的外设;(4)不同的接口;(5)不同的可选项，例如不同的内存大小;兼容性测试的核心内容：(1)测试软件是否能在不同的操作系统平台上兼容;(2)测试软件是否能在同一操作系统平台的不同版本上兼容;(3)软件本身能否向前或者向后兼容;(4)测试软件能否与其它相关的软件兼容;(5)数据兼容性测试，主要是指数据能否共享;配置和兼容性测试通称对开发系统类软件比较重要，例如驱动程序、操作系统、数据库管理系统等。具体进行时仍然按照测试用例来执行。34、软件文档测试主要包含什么?随着软件文档系统日益庞大，文档测试已经成为软件测试的重要内容。文档测试对象主要如下：-包装文字和图形;-市场宣传材料、广告以及其它插页;-授权、注册登记表;-最终用户许可协议;-安装和设置向导;-用户手册;-联机帮助;-样例、示范例子和模板;-……文档测试的目的是提高易用性和可靠性，降低支持费用，因为用户通过文档就可以自己解决问题。因文档测试的检查内容主要如下：-读者对象——主要是文档的内容是否能让该级别的读者理解;-术语——主要是检查术语是否适合读者;-内容和主题——检查主题是否合适、是否丢失、格式是否规范等;-图标和屏幕抓图——检查图表的准确度和精确度;-样例和示例——是否与软件功能一致;-拼写和语法;-文档的关联性——是否与其它相关文档的内容一致，例如与广告信息是否一致;文档测试是相当重要的一项测试工作，不但要给予充分的重视，更要要认真的完成，象做功能测试一样来对待文档测试。35、没有产品说明书和需求文档地情况下能够进行黑盒测试吗?这个问题是国内测试工程师经常遇到的问题，根源就是国内软件开发文档管理不规范，对变更的管理方法就更不合理了。实际上没有任何文档的时候，测试人员是能够进行黑盒测试的，这种测试方式我们可以称之为探索测试，具体做法就是测试工程师根据自己的专业技能、领域知识等不断的深入了解测试对象、理解软件功能，进而发现缺陷。在这种做法基本上把软件当成了产品说明书，测试过程中要和开发人员不断的进行交流。尤其在作项目的时候，进度压力比较大，可以作为加急测试方案。最大的风险是不知道有些特性是否被遗漏。36、测试中的“杀虫剂怪事”是指什么?“杀虫剂怪事”一词由BorisBeizer在其编著的《软件测试技术》第二版中提出。用于描述测试人员对同一测试对象进行的测试次数越多，发现的缺陷就会越来越少的现象。就像老用一种农药，害虫就会有免疫力，农药发挥不了效力。这种现象的根本原因就是测试人员对测试软件过于熟悉，形成思维定势。为了克服这种现象，测试人员需要不断编写新的测试程序或者测试用例，对程序的不同部分进行测试，以发现更多的缺陷。也可以引用新人来测试软件，刚刚进来的新手往往能发现一些意想不到的问题。37、在配置测试中，如何判断发现的缺陷是普通问题还是特定的配置问题?在进行配置测试时，测试工程师仍然会发现一些普通的缺陷，也就是与配置环境无关的缺陷。因此判断新发现的问题，需要在不同的配置中重新执行发现软件缺陷的步骤，如果软件缺陷不出现了，就可能是配置缺陷;如果在所有的配置中都出现，就可能是普通缺陷。需要注意的是，配置问题可以在一大类配置中出现。例如，拨号程序可能在所有的外置Modem中都存在问题，而内置的Modem不会有任何问题。38、为什么尽量不要让时间有富裕的员工去做一些测试?表面上看这体现了管理的效率和灵活性，但实际上也体现了管理者对测试的轻视。测试和测试的人有很大关系。测试工作人员应该是勤奋并富有耐心，善于学习、思考和发现问题，细心有条理，总结问题，如果具备这样的优点，做其它工作同样也会很出色，因此这里还有一个要求，就是要喜欢测试这项工作。如果他是专职的，那么肯定更有经验和信心。国内的小伙子好象都喜欢做程序员，两者工作性质不同，待遇不同，地位不同，对自我实现的价值的认识也不同，这是行业的一个需要改善的问题。如果只是为了完成任务而完成任务，或者发现了几个问题就觉得满意了，这在任何其它工作中都是不行的。39、完全测试程序是可能的吗?软件测试初学者可能认为拿到软件后需要进行完全测试，找到全部的软件缺陷，使软件“零缺陷”发布。实际上完全测试是不可能的。主要有以下一个原因：-完全测试比较耗时，时间上不允许;-完全测试通常意味着较多资源投入，这在现实中往往是行不通的;-输入量太大，不能一一进行测试;-输出结果太多，只能分类进行验证;-软件实现途径太多;-软件产品说明书没有客观标准，从不同的角度看，软件缺陷的标准不同;因此测试的程度要根据实际情况确定。40、软件测试的风险主要体现在哪里?我们没有对软件进行完全测试，实际就是选择了风险，因为缺陷极有可能存在没有进行测试的部分。举个例子，程序员为了方便，在调试程序时会弹出一些提示信息框，而这些提示只在某种条件下会弹出，碰巧程序发布前这些代码中的一些没有被注释掉。在测试时测试工程师又没有对其进行测试。如果客户碰到它，这将是代价昂贵的缺陷，因为交付后才被客户发现。因此，我们要尽可能的选择最合适的测试量，把风险降低到最小。41、发现的缺陷越多，说明软件缺陷越多吗?这是一个比较常见的现象。测试工程师在没有找到缺陷前会绞尽脑汁的思考，但是找到一个后，会接二连三的发现很多缺陷，颇有个人成就感。其中的原因主要如下：-代码复用、拷贝代码导致程序员容易犯相同的错误。类的继承导致所有的子类会包含基类的错误，反复拷贝同一代码意味可能也复制了缺陷。-程序员比较劳累是可以导致某些连续编写的功能缺陷较多。程序员加班是一种司空见惯的现象，因此体力不只时容易编写一些缺陷较多的程序。而这些连续潜伏缺陷恰恰时测试工程师大显身手的地方。“缺陷一个连着一个”不是一个客观规律，只是一个常见的现象。如果软件编写的比较好，这种现象就不常见了。测试人员只要严肃认真的测试程序就可以了。42、所有的软件缺陷都能修复吗?所有的软件缺陷都要修复吗?从技术上讲，所有的软件缺陷都是能够修复的，但是没有必要修复所有的软件缺陷。测试人员要做的是能够正确判断什么时候不能追求软件的完美。对于整个项目团队，要做的是对每一个软件缺陷进行取舍，根据风险决定那些缺陷要修复。发生这种现象的主要原因如下：-没有足够的时间资源。在任何一个项目中，通常情况下开发人员和测试人员都是不够用的，而且在项目中没有预算足够的回归测试时间，再加上修改缺陷可能引入新的缺陷，因此在交付期限的强大压力下，必须放弃某些缺陷的修改。-有些缺陷只是特殊情况下出现，这种缺陷处于商业利益考虑，可以在以后升级中进行修复。-不是缺陷的缺陷。我们经常会碰到某些功能方面的问题被当成缺陷来处理，这类问题可以以后有时间时考虑再处理。最后要说的是，缺陷是否修改要由软件测试人员、项目经理、程序员共同讨论来决定是否修复，不同角色的人员从不同的角度来思考，以做出正确的决定。43、软件测试人员就是QA吗?软件测试人员的职责是尽可能早的找出软件缺陷，确保得以修复。而质量保证人员(QA)主要职责是创建或者制定标准和方法，提高促进软件开发能力和减少软件缺陷。测试人员的主要工作是测试，质量保证人员日常工作重要内容是检查与评审，测试工作也是测试保证人员的工作对象。软件测试和质量是相辅相成的关系，都是为了提高软件质量而工作。44、如何减少测试人员跳槽带来的损失?在IT行业里跳槽已经是一种司空见惯的现象，而且跳槽无论给公司还是给个人都会带来一定的损失。测试队伍也无疑会面临跳槽的威胁，作为测试经理管理者，只有从日常工作中开始做起，最能最大限度的减少损失。建议我们从以下两个方面做起：加强部门内员工之间的互相学习，互相学习是建立学习型组织的基本要求，是知识互相转移的过程。在此基础上，可以把个人拥有的技术以知识的形式沉积下来，也就完成了隐性知识到显性知识的转化。-通常情况下，企业能为员工提供足够大的发展空间时，如果不是待遇特别低，员工都不会主动离开企业。因此我们要想留住员工，管理者就应该把员工的个人成长和企业的发展联系起来，为员工设定合理发展规划并付诸实现。不过这项要求做起来比较，要有比较好的企业文化为依托。45、测试产品与测试项目的区别是什么?习惯上把开发完成后进行商业化、几乎不进行代码修改就可以售给用户使用的软件成为软件产品，也就是可以买“卖拷贝”的软件，例如Windows2000。而通常把针对一个或者几个特定的用户而开发的软件成为软件项目，软件项目是一种个性化的产品，可以是按照用户要求全部重新开发，也可以修改已有的软件产品来满足特定的用户需求。项目和产品的不同特点，决定我们测试产品和测试项目仍然会有很多不同的地方：-质量要求不同。通常产品的质量要高一些，修复发布后产品的缺陷成本较高，甚至会带来很多负面的影响。而做项目通常面向某一用户，虽然质量越高越好，但是一般只要满足用户要求就可以了。-测试资源投入多少不同。做软件产品通常是研发中心来开发，进度压力要小些。同时由于质量要求高，因此会投入较多的人力、物力资源。-项目最后要和用户共同验收测试，这是产品测试不具有的特点。此外，测试产品与测试项目在缺陷管理方面、测试策略制定都会有很大不同，测试管理者应该结合具体的环境，恰如其分的完成工作。46、和用户共同测试(UAT测试)的注意点有哪些?软件产品在投产前，通常都会进行用户验收测试。如果用户验收测试没有通过，直接结果就是那不到“Money”，间接影响是损害了公司的形象，而后者的影响往往更严重。根据作者的经验，用户验收测试一定要让用户满意。实际上用户现场测试更趋于是一种演示。在不欺骗用户的前提下，我们向用户展示我们软件的优点，最后让“上帝”满意并欣然掏出“银子”才是我们的目标。因此用户测试要注意下面的事项：(1)用户现场测试不可能测试全部功能，因此要测试核心功能。这需要提前做好准备，这些核心功能一定要预先经过测试，证明没有问题才可以和用户共同进行测试。测试核心模块的目的是建立用户对软件的信心。当然如果这些模块如果问题较多，不应该进行演示。(2)如果某些模块确实有问题，我们可以演示其它重要的业务功能模块，必要时要向用户做成合理的解释。争得时间后，及时修改缺陷来弥补。(3)永远不能欺骗用户，蒙混过关。道理很简单，因为软件是要给用户用的，问题早晚会暴露出来，除非你可以马上修改。和用户进行测试还要注意各种交流技巧，争取不但短期利益得到了满足，还要为后面得合作打好基础。47、如何编写提交给用户的测试报告?随着测试工作越来越受重视，开发团队向客户提供测试文档是不可避免的事情。很多人会问：“我们可以把工作中的测试报告提供给客户吗?”答案是否定的。因为提供内部测试报告，可能会让客户失去信心，甚至否定项目。测试报告一般分为内部测试报告和外部测试报告。内部报告是我们在测试工作中的项目文档，反映了测试工作的实施情况，这里不过多讨论，读者可以参考相关教材。这里主要讨论一下外部测试报告的写法，一般外部测试报告要满足下面几个要求：-根据内部测试报告进行编写，一般可以摘录;-不可以向客户报告严重缺陷，即使是已经修改的缺陷，开发中的缺陷也没有必要让客户知道;-报告上可以列出一些缺陷，但必须是中级的缺陷，而且这些缺陷必须是修复的;-报告上面的内容尽量要真实可靠;-整个测试报告要仔细审阅，力争不给项目带来负面作用，尤其是性能测试报告。总之，外部测试报告要小心谨慎的编写。48、测试工具在测试工作中是什么地位?国内的很多测试工程师对测试工具相当迷恋，尤其是一些新手，甚至期望测试工具可以取代手工测试。测试工具在测试工作中起的是辅助作用，一般用来提高测试效率。自动化测试弥补了手工测试的不足，减轻一定的工作量。实际上测试工具是无法替代大多数手工测试的，而一些诸如性能测试等自动化测试也是手工所不能完成的。对于自动测试技术，应当依据软件的不同情况来分别对待，一般自动技术会应用在引起大量重复性工作的地方、系统的压力点、以及任何适合使用程序解决大批量输入数据的地方。然后再寻找合适的自动测试工具，或者自己开发测试程序。一定不要为了使用测试工具而使用。49、常见的测试用例设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。1-等价类划分常见的软件测试面试题划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.2-边界值分析法边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.3-错误推测法基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例-例如, 在单元测试时曾列出的许多在模块中常见的错误-以前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行-这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例.4-因果图方法前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等-考虑输入条件之间的相互组合,可能会产生一些新的情况-但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多-因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例-这就需要利用因果图(逻辑模型)-因果图方法最终生成的就是判定表-它适合于检查程序输入条件的各种组合情况.5-正交表分析法有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。6-场景分析方法指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。50、您认为做好测试用例设计工作的关键是什么?白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题51、详细的描述一个测试活动完整的过程。1-项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后sqa进入项目，开始进行统计和跟踪2-开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。3-测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。4-测试用例完成后，测试和开发需要进行评审。5-测试人员搭建环境6-开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现bug后提交给bugzilla。7-开发提交第二个版本，包括bug fix以及增加了部分功能，测试人员进行测试。8-重复上面的工作，一般是3-4个版本后bug数量减少，达到出货的要求。9-如果有客户反馈的问题，需要测试人员协助重现以及回归测试。52、以往是否曾经从事过性能测试工作?请尽可能的详细描述您以往的性能测试工作的完整过程。曾经做过一套网管系统的性能测试，主要测试该软件在同时管理大量终端的情况下，在响应时间，cpu/磁盘/内存等参数是否满足要求。也曾经做过软交换系统的呼叫性能测试，主要是测试软交换系统在有大量呼叫的情况下，响应时间，呼叫成功率，cpu/磁盘/内存等参数是否满足设计要求。53、在您以往的工作中，一条软件缺陷(或者叫bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(bug)记录?1-在传统的bugzilla中，bug描述应该包括以下的信息2-和bug产生对应的软件版本3-开发的接口人员4-bug的优先级5-bug的严重程度6-bug可能属于的模块，如果不能确认，可以用开发人员来判断7-bug标题，需要清晰的描述现象8-bug描述，需要尽量给出重新bug的步骤9-bug附件中能给出相关的日志和截图。高质量的bug记录就是指很容易理解的bug记录，所以，对于描述的要求高，能提供的信息多且准确，很好的帮助开发人员定位。54、您在从事性能测试工作时，是否使用过一些测试工具?如果有，请试述该工具的工作原理，并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。测试网管系统中，使用的mimic来模拟终端，能够大量的节省成本。测试软交换系统的时候，使用的prolab来模拟终端并发送呼叫软交换，他完成了同时数百人才能完成的摘机拨号工作，主要工作原理是产生一些符合要求的ip包并发送给软交换系统，同时对软交换系统的回应进行处理，决定下一步动作。55、您认为性能测试工作的目的是什么?做好性能测试工作的关键是什么?主要是保障在大量用户的情况下，服务能正常使用。【Linux】56、怎么清屏？怎么退出当前命令？怎么执行睡眠？怎么查看当前用户 id？查看指定帮助用什么命令？答案：清屏：clear退出当前命令：ctrl+c 彻底退出执行睡眠 ：ctrl+z 挂起当前进程fg 恢复后台查看当前用户 id：”id“：查看显示目前登陆账户的 uid 和 gid 及所属分组及用户名查看指定帮助：如 man adduser 这个很全 而且有例子；adduser --help 这个告诉你一些常用参数；info adduesr；57、建立软链接(快捷方式)，以及硬链接的命令。答案：软链接：ln -s slink source硬链接：ln link source58、查看文件内容有哪些命令可以使用？答案：vi 文件名 #编辑方式查看，可修改cat 文件名 #显示全部文件内容more 文件名 #分页显示文件内容less 文件名 #与 more 相似，更好的是可以往前翻页tail 文件名 #仅查看尾部，还可以指定行数head 文件名 #仅查看头部,还可以指定行数59、Linux 下命令有哪几种可使用的通配符？分别代表什么含义?答案：“？”可替代单个字符。“*”可替代任意多个字符。60、用什么命令对一个文件的内容进行统计？(行号、单词数、字节数)答案：wc 命令 - c 统计字节数 - l 统计行数 - w 统计字数。61、怎么使一个命令在后台运行?答案：一般都是使用 & 在命令结尾来让程序自动运行。(命令后可以不追加空格)62、把后台任务调到前台执行使用什么命令?把停下的后台任务在后台执行起来用什么命令?答案：把后台任务调到前台执行 fg把停下的后台任务在后台执行起来 bg63、搜索文件用什么命令? 格式是怎么样的?答案：find <指定目录> <指定条件> <指定动作>whereis 加参数与文件名locate 只加文件名find 直接搜索磁盘，较慢。find / -name "string*"64、使用什么命令查看用过的命令列表?答案：history65、查找命令的可执行文件是去哪查找的? 怎么对其进行设置及添加?答案：whereis [-bfmsu][-B <目录>...][-M <目录>...][-S <目录>...][文件...]66、通过什么命令查找执行命令?答案：which 只能查可执行文件whereis 只能查二进制文件、说明文档，源文件等67、当你需要给命令绑定一个宏或者按键的时候，应该怎么做呢？答案：可以使用bind命令，bind可以很方便地在shell中实现宏或按键的绑定。在进行按键绑定的时候，我们需要先获取到绑定按键对应的字符序列。比如获取F12的字符序列获取方法如下：先按下Ctrl+V,然后按下F12 .我们就可以得到F12的字符序列 ^[[24~。接着使用bind进行绑定。[root@localhost ~]# bind ‘”\e[24~":"date"'注意：相同的按键在不同的终端或终端模拟器下可能会产生不同的字符序列。【附】也可以使用showkey -a命令查看按键对应的字符序列。68、你的系统目前有许多正在运行的任务，在不重启机器的条件下，有什么方法可以把所有正在运行的进程移除呢？答案：使用linux命令 ’disown -r ’可以将所有正在运行的进程移除。69、怎样查看一个linux命令的概要与用法？假设你在/bin目录中偶然看到一个你从没见过的的命令，怎样才能知道它的作用和用法呢？答案：使用命令whatis 可以先出显示出这个命令的用法简要，比如，你可以使用whatis zcat 去查看‘zcat’的介绍以及使用简要。【接口测试】70、接口测试如何设计测试用例？（必问，有没有感觉答得整个人都不好了？）接口测试一般考虑入参形式的变化和接口的业务逻辑，一般设计接口测试用例采用等价类、边界值、场景法居多！接口测试设计测试用例的思路如下：1.接口业务逻辑测试?(正例)接口逻辑测试是指根据业务逻辑、输入参数、输出值的描述，对正常输入情况下所得的输出值是否正确的测试，也就是测试对外提供的接口服务是否正常工作。2.模块接口测试?(反例)模块接口测试是为了保证数据的安全及程序在异常情况下的逻辑的正确性而进行的测试。?模块接口测试的主要包括以下几个方面：?1）鉴权码token异常(鉴权码为空<没有鉴权码>,错误的鉴权码,过期的鉴权码)。2）其他参数异常。1、必填项检查2、参数的长度、类型、格式异常：常规参数：(数字、字符串、日期)参数长度：6-18位。或身份证、电话的长度。参数类型：数字(精度)，字母，中文，带空格的参数，特殊字符。日期格式：日期：年月日，年月日时分秒，日期格式(包括/,-,:等)。3）错误码异常覆盖。4）接口测试其他的关注点接口有翻页时，页码与页数的异常值测试数据库的增删改查，比如一个post接口操作完成后，通过列表页接口看下新的数据是否和刚才的post一致接口返回的图片地址能否打开，图片尺寸是否符合需求当输出参数有联动性时，需要校验返回两参数的实际结果是否都符合需求。所有列表页接口必须考虑排序值所有功能都要考虑兼容旧版本71、get和post请求有什么区别？POST和GET都是向服务器提交数据，并且都会从服务器获取数据。区别：1）传送方式：get通过地址栏传输，post通过报文传输2）传送长度：get参数有长度限制（受限于url长度），而post无限制3）GET产生一个TCP数据包（对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200返回数据），POST产生两个TCP数据包（对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok返回数据）4）get请求参数会被完整保留在浏览历史记录里，而post中的参数不会被保留5）在做数据查询时，建议用GET方式；而在做数据添加、修改或删除时，建议用post方式72、常见的POST提交数据方式答：主要有四种方式：application/x-www-form-urlencoded、multipart/form-data、application/json、text/xml等。73、接口测试中有哪些要注意的测试点？11.1)接口中返回了图片地址，要手工去进行图片的测试（大小、内容）11.2)接口完成查询功能的时候，数据返回的排序显示11.3)接口测试的时候，关注参数的默认值、必填项74、之前在接口测试过程中，使用的工具是什么？postman或jmeter(5.1)6、postman你在工作中使用流程是什么样的？1) 编写好用例2) 在postman先建好url环境变量3) 根据接口用例所属的模块新建集合管理75、postman支持什么类型的协议测试？http和https协议的76、jmeter之前用的是什么版本？如何安装的？jmeter用的是5.1.1版本，安装如下：先在电脑上安装jdk1.8或以上的版本，然后从官网下载最新的安装包，解压后，进行环境变量的配置，配置好后即安装完成77、jmeter中如何实现关联？先从上一个接口中通过正则表达式提取器或jsonpath解析器截取下一个接口需要的参数值保存到变量，然后在写一个接口中通过${变量名}去获取78、你们公司的接口测试流程是怎样的？（有没有感觉熟悉，貌似在哪里听过）接口测试我们是在XX项目做的，主要有XX接口，XX接口，XX接口等。1、首先是从开发那里拿到API接口文档，了解接口业务、包括接口地址、请求方式，入参、出参，token鉴权，返回格式等信息。2、然后使用Postman或Jmeter工具执行接口测试，一般使用Jmeter的步骤是这样的：1、首先新建一个线程组。2、然后就是新建一个HTTP请求默认值。（输入接口服务器IP和端口）3、再新建很多HTTP请求，一个请求一个用例。（输入接口路径，访问方式，参数等。）4、然后创建断言和查看结果树。3、最后调试并执行用例，最后编写接口测试报告4、其实我们做接口的时候也碰到了蛮多的问题，都是自己独立解决的，比如返回值乱码（修改jmeter的配置文件为UTF-8编码方式），比如需要登录后才能取得token鉴权码并且这个鉴权码在下面的请求中需要用到（使用正则表达式提取器提取token的值等。79、接口测试执行中比对数据库吗？肯定啊，因为接口返回值的数据来源于数据库，接口对数据的操作还要进行深层次的数据库检查！80、响应状态码有哪些？1xx：指示信息--表示请求已接受，继续处理2xx：成功--表示请求已被成功接收、理解、接受3xx：重定向--要完成请求必须进行更进一步的操作4xx：客户端错误--请求有语法错误或请求无法实现81、什么是DNS？DNS 是域名系统 (Domain Name System)，DNS是用来做域名解析的,它会在你上网输入网址后，把它转换成IP，然后去访问对方服务器；没有它，你想上百度就要记住百度的IP，但有了DNS的处理，你只需要记住对应网站的域名，即网址就可以了。82、在接口测试过程中发现的bug多不多？能举几个栗子？这个问题其实回到起来很简单，只要做过接口测试的，总能发现几个BUG吧，把你平常发现的bug说2-3个就可以了。 面试官出这个题，主要是想知道你是不是真的做过接口测试，毕竟现在很多小伙伴简历都是写的假的（你要不写估计面试机会都没有，没办法，为了生存，能理解） 比如，提现输入框，在页面上输入负数，肯定是无法提交过去（前端页面会判断金额），如果我不走前端，直接用接口工具发请求，输入一个负数过去。 （假设服务端没做提现金额数据判断） 余额=当前余额（100）-提现金额（-100），那么提现-100，余额就变成200了，也就是越提现，余额越大了。83、你做接口测试，测什么？可用性测试根据约定的协议、方法、格式内容，传输数据到接口经处理后返回期望的结果：接口功能是否正确实现；返回值测试 - 返回值除了内容要正确，类型也要正确，保证调用方能够正确地解析；参数值边界值、等价类测试；错误和异常处理测试输入异常值（空值、特殊字符、超过约定长度等），接口能正确处理，且按预期响应；输入错误的参数，接口能正确处理，并按预期响应；多输入、少输入参数，接口能正确处理，且按预期响应；错误传输数据格式（如json格式写成form格式）测试；安全性测试，主要指传输数据的安全性：敏感数据（如密码、秘钥）等是否加密传输；返回数据是否含有敏感数据，如用户密码、完整的用户银行账号信息等；接口是否对传入的数据做安全校验，如身份ID加token类似校验；接口是否防止恶意请求（如大量伪造请求接口致使服务器崩溃）；性能测试，如接口的响应时间、并发处理能力、压测处理情况：并发请求相同的接口（特别为POST请求），接口的处理情况（如插入了相同的记录导致数据出错，引发系统故障）；接口响应时长在用户可忍受的范围内；对于请求量大的接口做压测，确定最大的瓶颈点是否满足当前业务需要；84、之前用过抓包工具没有？如何使用的？之前在项目中用过fiddler抓包工具进行HTTP协议请求的抓取打开fiddler之后，默认浏览器配置了127.0.0.1 8888端口的代理，在fiddler设置好过滤策略后，打开需要进行抓包的网站进行操作，就可以进行抓包85、在项目中如何用jmeter进行接口测试？1) 把线程组数量设置为1，循环次数设置为12) 配置好全局变量URL通过配置元件---用户自定义的变量添加3) 增加配置元件http请求默认值，放置在用户定义的变量之后4) 添加事务控制器管理和组织测试用例5) 在事务控制中添加http请求添加测试用例中的接口请求信息6) 添加对应的断言元件进行断言86、平常用什么工具测接口的？常用http协议接口测试工具，如：postman、fiddler、jmeter；webService接口用SoapUI、jmeter等。87、jmeter添加http请求默认值元件有什么作用？添加并设置好后，相当于给所有的http请求取样器都设置了默认值，既不用填写取样器中的比如主机地址、端口、代理等，都可以使用http请求默认值设置的88、请简述一下cookie、session以及token的区别（有没有感觉整个是万年不变的面试题）cookie数据存放在客户的浏览器上，session数据放在服务器上cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗，考虑到安全应当使用sessionsession会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，考虑到减轻服务器性能方面应当使用cookie单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie可以将登陆信息等重要信息存放为session；其他信息需要保存，可以放在cookie89、谈谈你对HTTP协议的了解？超文本传输协议，端口为80，特点（无记忆功能、快速）是由请求和响应两部分组成请求由请求头、请求行、请求正文组成；响应是由响应头、响应行、响应正文组成，之前我们公司的接口是采用https协议的。90、什么是Http协议无状态协议?怎么解决HTTP协议无状态协议无状态是指协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。即我们给服务器发送 HTTP 请求之后，服务器根据请求，会给我们发送数据过来，但是，发送完，不会记录任何信息。HTTP 是一个无状态协议，这意味着每个请求都是独立的，Keep-Alive 没能改变这个结果。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。HTTP 协议这种特性有优点也有缺点，优点在于解放了服务器，每一次请求“点到为止”不会造成不必要连接占用，缺点在于每次请求会传输大量重复的内容信息。客户端与服务器进行动态交互的 Web 应用程序出现之后，HTTP 无状态的特性严重阻碍了这些应用程序的实现，毕竟交互是需要承前启后的，简单的购物车程序也要知道用户到底在之前选择了什么商品。于是，两种用于保持 HTTP 连接状态的技术就应运而生了，一个是 Cookie，而另一个则是 Session。91、接口执行测试后返回结果做对比，一般比对哪部分内容？之前必须要对比的就是返回状态码，其次再去对比返回其它关键内容92、为什么开展接口测试？接口测试属于集成测试、测试介入越早、就越能在项目早期发现问题，其修复问题的成本越低接口测试非常快速、UI自动化执行一个测试用例10S左右、接口测试用例执行的话，需要的时间是毫秒级的93、json数据是什么，你平时如何解析json数据？一种开发常用的数据报文格式，由键值对和数组两种格式构成。可以通过工具bejson网站等94、依赖于第三方数据的接口如何进行测试？mock接着面试官会问你，如果mock的，然后你就顺着坑继续挖，搭建mock服务95、接口测试中，依赖登录状态的接口如何测试？依赖登录状态的接口的本质上是在每次发送请求时需要带上session或者cookie才能发送成功，在构建POST请求时添加必要的session或者cookie96、postman中设置环境变量有什么用？在之前项目中，接口测试测试的环境有开发环境，测试环境等，为了测试的时候方便，就在postman设置环境变量，到时所有接口都引用该环境变量，这样就不用为了切换环境导致每次都去修改被测系统接口的主机地址；点击右上角环境变量管理按钮-新建环境变量，在脚本中使用{{变量名}}去调用97、如何模拟弱网做测试？Fiddler和charles都可以模拟弱网测试，平常说的模拟丢包，也是模拟弱网测试98、在接口测试中关联是什么含义？如何用postman设置关联？关联就是把上一个接口返回值的部分截取出来，作为下一个接口的参数，能让接口串联运行在postman中设置关联的步骤如下：1) 先通过正则表达式提取的方式或json取值的方式把下一个接口需要的信息从上一个接口截取出来2) 使用设置全局变量的代码把取出来的值保存到全局变量3) 在下一个接口中，使用{{全局变量}}代替要替换的静态值99、postman参数化有哪几种方式？内建变量、pre-scripts编写js脚本、批量运行时导入csv或json格式的文件100、Newman如何执行postman脚本？Newman run 脚本名称 也可以添加参数生成html报表等101、jmeter中如何设置断言？右击请求---断言---响应断言---响应断言界面输入要检查比对的项，设置好断言后，执行接口测试如果是通过的，查看结果树不会有任何提示，如果断言失败，就会有红色报错。如果接口返回的数据是json数据，也可以添加json断言【自动化测试】102、你会封装自动化测试框架吗？这个问得最多，甚至有很多公司直接写在招聘要求中！当然可以，自动化框架主要的核心框架就是分层+PO模式：分别为：基础封装层BasePage，PO页面对象层，TestCase测试用例层。然后再加上日志处理模块，ini配置文件读取模块，unittest+ddt数据驱动模块，jenkins持续集成模式组成。103、如何把自动化测试在公司中实施并推广起来的？1.项目组调研选择自动化工具并开会演示demo案例，我们主要是演示selenium和robotframework两种。2.搭建自动化测试框架，在项目中逐步开展自动化。3.把该项目的自动化流程、框架固化成文档4.推广到公司的其它项目组应用104、请描述一下自动化测试流程？1.编写自动化测试计划2.设计自动化测试用例3.编写自动化测试框架和脚本4.调试并维护脚本5.无人值守测试6.后期脚本维护（添加用例、开发更新版本）105、自动化测试用例如何编写？以下答案二选一即可：1.用例是自动化测试工程师自己设计的，一般刚开始已基本业务流程为主（登录–完成一个业务–退出）2.从系统测试用例中进行筛选或由业务工程师提供106、上一个项目中自动化测试的执行策略？上一个项目中是定时执行的，设置的执行时间是晚上12点，执行完毕后会自动发送邮件通知107、自动化测试发现BUG多吗？不多，因为之前项目组是把已经测试通过的基本功能再进行自动化脚本编写和在后续版本执行自动化测试，它主要是保证已经测试通过的功能在新版本更新后没有问题。108、你觉得自动化测试的价值在哪里？你们公司为什么要做自动化测试？引用自动化测试之后，能代替大量繁琐的回归测试工作，把业务测试人员解放出来，既而让业务测试人员把精力集中在复杂的业务功能模块上，自动化测试一般是对稳定下来的功能进行自动化，保证不会因为产品的更新导致之前稳定下来的功能出现BUG109、自动化测试有误报过bug吗？产生误报怎么办？有误报过，有时候自动化测试报告中显示发现了bug,实际去通过手工测试去确认又不存在该bug。误报原因一般是：1.元素定位不稳定，需要尽量提高脚本的稳定性；2.开发更新了页面但是测试没有及时更新维护!110、自动化测试过程中，你遇到了哪些问题，是如何解决的？1.频繁地变更页面，经常要修改页面对象类里面的代码2.自动化测试偶尔出现过误报3.自动化测试结果出现覆盖的情况：Jenkins根据时间建立文件夹4.自动化测试代码维护比较麻烦5.自动化测试进行数据库对比数据111、在上一家公司做自动化测试用的什么框架？可以说出以下自己擅长的一种：1.python+selenium+unittest+htmltestrunner2.python+selenium+pytest+allurerobotframework+Selenium2Library112、在selenium自动化测试中，你一般完成什么类型的测试？自动化覆盖率？主要是冒烟测试和回归测试。回归测试主要写一些功能稳定的场景，通过自动化手段去实现，节约测试时间。因为自动化测试用例也是在不断的更新和迭代，没有刻意去统计，大概在30%-40%左右！113、在执行脚本过程，如何实现当前元素高亮显示？这个其实就是利用javaScript去修改当前元素的边框样式来到达高亮显示的效果，114、如果一个元素无法定位，你一般会考虑哪些方面的原因？1.页面加载元素过慢，加等待时间2.页面有frame框架页，需要先跳转入frame框架再定位3.可能该元素是动态元素，定位方式要优化，可以使用部分元素定位或通过父节点或兄弟节点定位。4.可能识别了元素，但是不能操作，比如元素不可用，不可写等。需要使用js先把前置的操作完成，115、元素定位方法你熟悉的有哪些？id name classname link_text css xpath116、遇到frame框架页面怎么处理？先用driver.switch_to.frame()跳转进去frame，然后再操作页面元素，操作完后使用driver.swith_to.default_content()跳转出来117、遇到alert弹出窗如何处理？使用driver.switch_to.alert方法先跳转到alert弹出窗口然后再通过accept点击确定按钮，通过dismiss点击取消难，通过text()获得弹出窗口的文本。118、如何处理多窗口？这个多窗口之间跳转处理，我们在项目中也经常遇到。就是，当你点击一个链接，这个链接会在一个新的tab打开，然后你接下来要在新tab打开的页面查找元素，1.我们在点击链接前使用driver.current_window_handle获得当前窗口句柄。2.再点击链接。点击后通过driver.window_handles获得所有窗口的句柄，3.然后再循环找到新窗口的句柄，然后再通过driver.switch_to.window()方法跳转到新的窗口。119、怎么验证元素是enable/disabled/checked状态？定位元素后：分别通过isEnabled()，isSelected()，isDisplayed()三个方法进行判断。120、 如何处理下拉菜单？在Selenium中有一个叫Select的类，这个类支持对下拉菜单进行操作。使用方法如下：1.定位元素2.把定位的元素转化成Select对象。sel = Select(定位的元素对象)3.通过下标或者值或者文本选中下拉框。sel.select_by_index(index);sel.select_by_value(value);sel.select_by_visible_text(text);121、在日历这种web 表单你是如何处理的?首先要分析当前网页试用日历插件的前端代码，看看能不能通过元素定位，点击日期实现，如果不能，可能需要借助javascript。还有些日历控件一个文本输入框，可以直接sendKeys()方法来实现传入一个时间的数据。122、举例一下说明一下你遇到过那些异常常见的selenium异常有这些：NoSuchElementException：没有该元素异常TimeoutException ： 超时异常ElementNotVisibleException ：元素不可见异常NoSuchAttributeException ：没有这样属性异常NoSuchFrameException ：没有该frame异常123、关闭浏览器中quit和close的区别简单来说，两个都可以实现退出浏览器session功能，close是关闭你当前聚焦的tab页面，而quit是关闭全部浏览器tab页面，并退出浏览器session。知道这两个区别，我们就知道quit一般用在结束测试之前的操作，close用在执行用例过程中关闭某一个页面的操作。124、在Selenium中如何实现截图，如何实现用例执行失败才截图在Selenium中提供了一个get_screenshot_as_file()的方法来截图的，一般结合try/except捕获异常时使用，进行错误截图。125、如何实现文件上传？定位元素后，直接使用send_keys()方法设置就行，参数为需要上传的文件的路径。126、自动化中有哪三类等待？他们有什么特点？1.线程等待（强制等待）如time.sleep(2)：线程强制休眠2秒钟，2秒过后，再执行后续的代码。建议少用。2.imlicitlyWait（隐式等待）会在指定的时间范围内不断的查找元素，直到找到元素或超时，特点是必须等待整个页面加载完成。3.WebDriverWait（显式等待）通常是我们自定义的一个函数代码，这段代码用来等待某个元素加载完成，再继续执行后续的代码127、你写的测试脚本能在不同浏览器上运行吗当然可以，我写的用例可以在在IE，火狐和谷歌这三种浏览器上运行。实现的思路是封装一个方法，分别传入一个浏览器的字符串，如果传入IE就使用IE，如果传入FireFox就使用FireFox，如果传入Chrome就使用Chrome浏览器，并且使用什么浏览器可以在总的ini配置文件中进行配置。需要注意的是每个浏览器使用的驱动不一样。128、什么是PO模式，为什么要使用它PO是Page Object 模式的简称，它是一种设计思想，意思是，把一个页面，当做一个对象，页面的元素和元素之间操作方法就是页面对象的属性和行为，PO模式一般使用三层架构，分别为：基础封装层BasePage，PO页面对象层，TestCase测试用例层。感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取}

1、你的测试职业发展是什么？　　测试经验越多，测试能力越高。所以我的职业发展是需要时间积累的，一步步向着高级测试工程师奔去。而且我也有初步的职业规划，前3年积累测试经验，按如何做好测试工程师的要点去要求自己，不断更新自己改正自己，做好测试任务。　　2、你认为测试人员需要具备哪些素质　　做测试应该要有一定的协调能力，因为测试人员经常要与开发接触处理一些问题，如果处理不好的话会引起一些冲突，这样的话工作上就会不好做。还有测试人员要有一定的耐心，有的时候做测试很枯燥乏味。除了耐心，测试人员不能放过每一个可能的错误。　　3、你为什么能够做测试这一行　　虽然我的测试技术还不是很成熟，但是我觉得我还是可以胜任软件测试这个工作的，因为做软件测试不仅是要求技术好，还有有一定的沟通能力，耐心、细心等外在因素。综合起来看我认为我是胜任这个工作的。　　4、测试的目的是什么？　　测试的目的是找出软件产品中的错误，是软件尽可能的符合用户的要求。当然软件测试是不可能找出全部错误的。　　5、测试分为哪几个阶段？　　一般来说分为5个阶段：单元测试、集成测试、确认测试、系统测试、验收测试　　6、单元测试的测试对象、目的、测试依据、测试方法？　　测试对象是模块内部的程序错误，目的是消除局部模块逻辑和功能上的错误和缺陷。测试依据是模块的详细设计，测试方法是采用白盒测试。　　7、怎样看待加班问题　　加班的话我没有太多意见，但是我还是觉得如果能够合理安排时间的话，不会有太多时候加班的。　　8、结合你以前的学习和工作经验，你认为如何做好测试。　　根据我以前的工作和学习经验，我认为做好工作首先要有一个良好的沟通，只有沟通无障碍了，才会有好的协作，才会有更好的效率，再一个就是技术一定要过关，做测试要有足够的耐心，和一个良好的工作习惯，不懂的就要问，实时与同事沟通这样的话才能做好测试工作。　　9、你为什么选择软件测试行业　　因为之前了解软件测试这个行业，觉得他的发展前景很好。　　10、根据你以前的工作或学习经验描述一下软件开发、测试过程，由哪些角色负责，你做什么　　要有架构师、开发经理、测试经理、程序员、测试员。我在里面主要是负责所分到的模块执行测试用例。　　11、根据你的经验说说你对软件测试/质量保证的理解　　软件质量保证与测试是根据软件开发阶段的规格说明和程序的内部结构而精心设计的一批测试用例(即输入数据和预期的输出结果)，并根据这些测试用例去运行程序，以发现错误的过程。它是对应用程序的各个方面进行测试以检查其功能、语言有效性及其外观排布。　　12、软件测试的流程是什么？　　需求调查：全面了解系统概况、应用领域、软件开发周期、软件开发环境、开发组织、时间安排、功能需求、性能需求、质量需求及测试要求等。根据系统概况进行项目所需的人员、时间和工作量估计以及项目报价。　　制定初步的项目计划。　　测试准备：组织测试团队、培训、建立测试和管理环境等。　　测试设计：按照测试要求进行每个测试项的测试设计，包括测试用例的设计和测试脚本的开发等。　　测试实施：按照测试计划实施测试。　　测试评估：根据测试的结果，出具测试评估报告。　　13、你对SQA的职责和工作活动(如软件度量)的理解?　　SQA就是独立于软件开发的项目组，通过对软件开发过程的监控，来保证软件的开发流程按照指定的CMM规程(如果有相应的CMM规程),对于不符合项及时提出建议和改进方案，必要时可以向高层经理汇报以求问题的解决。通过这样的途径来预防缺陷的引入，从而减少后期软件的维护成本。SQA主要的工作活动包括制定SQA工作计划，参与阶段产物的评审，进行过程质量、功能配置及物理配置的审计等；对项目开发过程中产生的数据进行度量等等。　　14、说说你对软件配置管理的理解　　项目在开发过程中要用相应的配置管理工具对配置项(包括各个阶段的产物)进行变更控制，配置管理的使用取决于项目规模和复杂性及风险的水平。软件的规模越大，配置管理就越显得重要。还有在配置管理中，有一个很重要的概念，那就是基线，是在一定阶段各个配置项的组合，一个基线就提供了一个正式的标准，随后的工作便基于此标准，并只有经过授权后才能变更这个标准。配置管理工具主要有CC，VSS,CVS,SVN等，我只用过SVN，对其他的工具不是很熟悉。　　15、怎样写测试计划和测试用例　　简单点，测试计划里应有详细的测试策略和测试方法，合理详尽的资源安排等，至于测试用例，那是依赖于需求(包括功能与非功能需求)是否细化到功能点，是否可测试等。　　16、说说主流的软件工程思想(如CMM、CMMI、RUP,XP,PSP,TSP等)的大致情况及对他们的理解　　CMM:SWCapability Maturity Model软件能力成熟度模型，其作用是软件过程的改进、评估及软件能力的评鉴。　　CMMI:CapabilityMaturity Model Integration能力成熟度模型集成 CMMI融入了大部分最新的软件管理实践，同时弥补了SW-CMM模型中的缺陷。　　RUP:rationalunified process是软件工程话过程。　　XP:extremeprogram，即极限编程的意思，适用于小型团队的软件开发，像上面第三个问题就可以结合原型法采用这样的开发流程。要明白测试对于xp开发的重要性，强调测试(重点是单元测试)先行的理念。编程可以明显提高代码的质量，持续集成对于快速定位问题有好处。　　PSP，TSP分别是个体软件过程和群体软件过程。大家都知道，CMM只是告诉你做什么但并没有告诉你如何做，所以PSP/TSP就是告诉你企业在实施CMM的过程中如何做，PSP强调建立个人技能(如何制定计划、控制质量及如何与其他人相互协作等等)。而TSP着重于生产并交付高质量的软件产品(如何有效的规划和管理所面临的项目开发任务等等)。总之，实施CMM，永远不能真正做到能力成熟度的提升，只有将实施CMM与实施PSP和TSP有机结合起来，才能发挥最大的效力。因此，软件过程框架应该是CMM/PSP/TSP的有机集成。　　17、你是怎样保证软件质量的，也就是说你觉得怎样才能最大限度的保证软件的质量？　　测试并不能够最大限度的保证软件的质量，软件的高质量是开发和设计出来的，而不是测试出来的，它不仅要通过对软件开发流程的监控，使得软件开发的各个阶段都要按照指定的规程进行，通过对各个阶段产物的评审，QA对流程的监控，对功能及配置的审计来达到开发的最优化。当然测试也是保证软件质量的一个重要方式，是软件质量保证工程的一个重要组成部分。　　18、基于目前中国的国情，大多数公司的项目进度紧张、人员较少、需求文档根本没有或者很不规范，你认为在这种情况下怎样保证软件的质量？(大多数公司最想知道的就是在这种困难面前你该怎么保证软件的质量，因为这些公司一般就是这种情况--既不想投入过多又想保证质量)　　出现以上的情况，如果仅仅想通过测试来提高软件质量，那几乎是不可能的，原因是没有足够的时间让你去测试，少而不规范的文档导致测试需求无法细化到足够且有针对行的测试。所以，作为公司质量保证的因该和项目经理确定符合项目本身是和的软件生命周期模型(比如RUP的建材，原型法)，明确项目的开发流程并督促项目组按照此流程开展工作，所有项目组成员(项目经理更加重要)都要制定出合理的工作计划，加强代码的单元测试，在客户既定的产品交付日期范围内，进行产品的持续集成等等，如果时间允许可以再配合客户进行必要的系统功能测试。　　19、一个测试工程师应该具备哪些素质和技能？　　1-掌握基本的测试基础理论　　2-本着找出软件存在的问题的态度进行测试，不要以挑刺的形象出现　　3-可熟练阅读需求规格说明书等文档　　4-以用户的观点看问题　　5-有强烈的质量意识　　6-细心和责任心　　7-良好的有效的沟通方式(与开发人员及客户)　　8-具有以往的测试经验能够及时准确的判断出高危险区在何处　　20、做好软件测试的一些关键点　　1-测试人员必须经过测试基础知识和理论的相关培训　　2-测试人员必须熟悉系统功能和业务　　3-测试要有计划，而且测试方案要和整个项目计划协调好　　4-必须实现编写测试用例，测试执行阶段必须根据测试用例进行　　5-易用性，功能，分支，边界，性能等功能行和非功能性需求都要进行测试　　6-对于复杂的流程一定要进行流程分支，组合条件分析，再进行等价类划分准备相关测试数据　　7-测试设计的一个重要内容是要准备好具体的测试数据，清楚这个测试数据是测试那个场景或分支的。　　8-个人任务平均每三个测试用例至少应该发现一个BUG，否则只能说明测试用例质量不好　　9-除了每天构建的重复测试可以考虑测试自动化外，其他暂时都不要考虑去自动话　　21、软件测试员自身素质培养　　1-首先，应对软件测试感兴趣和对自己有自信，如果具备了这两点，那么在开发过程中不管遇到什么样的困难，相信一定能克服　　2-善于怀疑，实际上没有绝对正确的，总有错误的地方，具有叛逆心理，别人认为不可能发生的事情，我却认为可能发生，别人认为是对的，我却认为不是对的。　　3-打破沙锅问到底的精神，对于只出现过一次的BUG一定要找出原因，不解决誓不罢休。　　4-保持一个良好的心情，否则可能无法把测试做好。不要把生活中的不愉快的情绪带到工作中来。　　5-做测试时要细心，不是所有的BUG都能很容易找出，一定要细心才能找到这些BUG。　　6-灵活一些，聪明一点，多造一些容易产生BUG的例子。　　7-在有条件的情况下，多和客户沟通，他们身上有你所需要的。　　8-设身处地为客户着想，从他们的角度去测试系统。　　9-不要让程序员，以“这种情况不可能发生”这句话说服你，相反，你应该去说服他，告诉他在客户心理，并不是这样的　　10-考虑问题要全面，结合客户的需求，业务流程和系统的架构等多方面考虑问题。　　11-提出问题不要复杂化，这点和前面矛盾，如果你是一个新手，暂时不要管这点，因为最终将有你的小组成员讨论解决。　　12-追求完美，对于新测试员来说，努力追求完美，这对你很好，尽管有些事情无法做到，但你应该尝试。　　13-幽默感，能和开发小组很好的沟通是关键，试着给你的开发小组找一个BUG杀手，或对他们说“我简直不敢相信，你写的程序居然到现在没有找到BUG”。　　22、为什要在一个团队中开展测试工作？　　因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样，测试同样也需要质量认证，这个时候就需要在团队中开展软件测试的工作。在测试的过程中发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。　　23、你所熟悉的软件测试类型有哪些?　　测试类型有：功能测试、性能测试、界面测试　　功能测试在测试工作中占有比例最大，功能测试也叫黑盒测试。　　性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。　　界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。　　区别在于，功能测试关注产品的所有功能，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注产品整体的多用户并发下的稳定性和健壮性。界面测试则关注与用户体验相关内容，用户使用该产品的时候是否已用，是否易懂，是否规范(用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告)。做某个性能测试的时候，首先它可能是个功能点，首先要保证她的功能是没有问题的，然后再考虑性能的问题。　　24、你认为做好测试用例设计工作的关键是什么　　白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结构。黑盒测试用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题。软件的黑盒测试意味着测试要在软件的接口处进行，这种方法是把测试对象看作是一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或者数据驱动测试。黑盒测试主要是为了发现以下几类错误：、　　1-是否有不正确或遗漏的功能　　2-在接口上，输入是否能正确的接受？能否输出正确的结果。　　3-是否有数据结构错误或外部信息(例如数据文件)访问错误　　4-性能上是否能够满足要求　　5-是否有初始化或终止性错误　　软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看作一个打开的盒子，它允许测试人员利用程序内部的逻辑结构和有关信息，设计或者选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一直。因此白盒测试又称为结合测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：　　1-对程序模块的所有独立的执行路径至少测试一遍。　　2-对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。　　3-在循环的边界和运行的界限内执行循环体。　　4-测试内部数据结构的有效性，等等。　　25、请详细介绍一下各种测试类型的含义　　1-单元测试(模块测试)是开发者编写的一小段代码，用于检验被测试代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。　　2-集成测试(也叫组装测试、联合测试)是单元测试的逻辑扩展。它最简单的形式是：两个已经经过测试的单元组合成一个组件，并且测试它们之间的接口。从这一层上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。　　3-系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中制定功能的有效方法。(常见的联调测试)。系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求而遵循系统设计。　　4-验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让用户将其执行软件的既定功能和任务。验收测试是向未来的用户表明系统能够像预订要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。　　26、测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？　　软件测试计划是知道测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。　　测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试策略和测试方法(最好能先评审)。　　27、您认为做好测试计划工作的关键是什么？　　1-明确测试的目标，增强测试计划的实用性　　编写软件测试计划的重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果准确　　2-坚持“5W”规则，明确内容与过程　　“5W”规则指的是“WHAT(做什么)”、“WHY(为什么做)”、"WHEN(何时做)"、"WHERE(在哪里)"、"HOW(如何做)"。利用“5W"规则创建软件测试计划，可以帮助测试团队理解测试的目的(WHY)，明确测试的范围和内容(WHAT)，确定测试的开始和结束日期(WHEN)，指出测试的方法和工具(HOW)，给出测试文档和软件存放的位置(WHERE)。　　3-采用评审和更新机制，保证测试计划满足实际需求　　测试计划完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。　　4-分别创建测试计划与测试详细规格、测试用例　　应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。　　28、当开发人员说不是BUG时，你如何应付？　　开发人员说不是BUG，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动。3方商量确定好后再看要不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的一句是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来，跟开发经理和测试经理进行确认，如果要修改就改，如果不要修改就不改。其实有些真的不是BUG，我也只是建议的方式写进测试文档中，如果开发人员不修改也没有大问题。如果不是BUG的话，一定要坚持自己的立场，让问题得到最后的确认。　　29、你自认为测试的优势在哪里？　　优势在于我对测试坚定不移的信心和热情，虽然经验还不足，但测试需要的基本技能我有信心在工作中得以发挥。　　30、什么是系统瓶颈？　　瓶颈主要是指整个软硬件构成的软件系统某一方面或者几个方面能力不能满足用户的特定业务要求，“特定”是指瓶颈会在某些条件下会出现，因为毕竟大多数系统在投入前。　　严格的从技术角度讲，所有的系统都会有瓶颈，因为大多数系统的资源配置不是协调的，例如CPU使用率刚好达到100％时，内存也正好耗尽的系统不是很多见。因此我们讨论系统瓶颈要从应用的角度讨论：关键是看系统能否满足用户需求。在用户极限使用系统的情况下，系统的响应仍然正常，我们可以认为改系统没有瓶颈或者瓶颈不会影响用户工作。　　因此我们测试系统瓶颈主要是实现下面两个目的：　　-发现“表面”的瓶颈。主要是模拟用户的操作，找出用户极限使用系统时的瓶颈，然后解决瓶颈，这是性能测试的基本目标。　　-发现潜在的瓶颈并解决，保证系统的长期稳定性。主要是考虑用户在将来扩展系统或者业务发生变化时，系统能够适应变化。满足用户目前需求的系统不是最好的，我们设计系统的目标是在保证系统整个软件生命周期能够不断适应用户的变化，或者通过简单扩展系统就可以适应新的变化。　　31、文档测试主要包含什么内容？　　在国内软件开发管理中，文档管理几乎是最弱的一项，因而在测试工作中特别容易忽略文档测试也就不足为奇了。要想给用户提供完整的产品，文档测试是必不可少的。文档测试一般注重下面几个方面：　　文档的完整性：主要是测试文档内容的全面性与完整性，从总体上把握文档的质量。例如用户手册应该包括软件的所有功能模块。　　描述与软件实际情况的一致性：主要测试软件文档与软件实际的一致程度。例如用户手册基本完整后，我们还要注意用户手册与实际功能描述是否一致。因为文档往往跟不上软件版本的更新速度。　　易理解性：主要是检查文档对关键、重要的操作有无图文说明，文字、图表是否易于理解。对于关键、重要的操作仅仅只有文字说明肯定是不够的，应该附有图表使说明更为直观和明了。　　文档中提供操作的实例：这项检查内容主要针对用户手册。对主要功能和关键操作提供的应用实例是否丰富，提供的实例描述是否详细。只有简单的图文说明，而无实例的用户手册看起来就像是软件界面的简单拷贝，对于用户来说，实际上没有什么帮助。　　印刷与包装质量：主要是检查软件文档的商品化程度。有些用户手册是简单打印、装订而成，过于粗糙，不易于用户保存。优秀的文档例如用户手册和技术白皮书，应提供商品化包装，并且印刷精美。　　32、功能测试用例需要详细到什么程度才是合格的？　　这个问题也是测试工程师经常问的问题。有人主张测试用例详细到每个步骤执行什么都要写出来，目的是即使一个不了解系统的新手都可以按照测试用例来执行工作。主张这类写法的人还可以举出例子：欧美、日本等软件外包文档都是这样做的。　　另外一种观点就是主张写的粗些，类似于编写测试大纲。主张这种观点的人是因为软件开发需求管理不规范，变动十分频繁，因而不能按照欧美的高标准来编写测试用例。这样的测试用例容易维护，可以让测试执行人员有更大的发挥空间。　　实际上，软件测试用例的详细程度首先要以覆盖到测试点为基本要求。举个例子：“用户登陆系统”的测试用例可以不写出具体的执行数据，但是至少要写出五种以上情况（），如果只用一句话覆盖了这个功能是不合格的测试用例。覆盖功能点不是指列出功能点，而是要写出功能点的各个方面（如果组合情况较多时可以采用等价划分）。　　另一个影响测试用例的就是组织的开发能力和测试对象特点。如果开发力量比较落后，编写较详细的测试用例是不现实的，因为根本没有那么大的资源投入，当然这种情况很随着团队的发展而逐渐有所改善。测试对象特点重点是指测试对象在进度、成本等方面的要求，如果进度较紧张的情况下，是根本没有时间写出高质量的测试用例的，甚至有些时候测试工作只是一种辅助工作，因而不编写测试用例。　　因此，测试用例的编写要根据测试对象特点、团队的执行能力等各个方面综合起来决定编写策略。最后要注意的是测试人员一定不能抱怨，力争在不断提高测试用例编写水平的同时，不断地提高自身能力。　　33、配置和兼容性测试的区别是什么？　　配置测试的目的是保证软件在其相关的硬件上能够正常运行，而兼容性测试主要是测试软件能否与不同的软件正确协作。　　配置测试的核心内容就是使用各种硬件来测试软件的运行情况，一般包括：　　（1）软件在不同的主机上的运行情况，例如Dell和Apple；　　（2）软件在不同的组件上的运行情况，例如开发的拨号程序要测试在不同厂商生产的Modem上的运行情况；　　（3）不同的外设；　　（4）不同的接口；　　（5）不同的可选项，例如不同的内存大小；　　兼容性测试的核心内容：　　（1）测试软件是否能在不同的操作系统平台上兼容；　　（2）测试软件是否能在同一操作系统平台的不同版本上兼容；　　（3）软件本身能否向前或者向后兼容；　　（4）测试软件能否与其它相关的软件兼容；　　（5）数据兼容性测试，主要是指数据能否共享；　　配置和兼容性测试通称对开发系统类软件比较重要，例如驱动程序、操作系统、数据库管理系统等。具体进行时仍然按照测试用例来执行。　　34、软件文档测试主要包含什么？　　随着软件文档系统日益庞大，文档测试已经成为软件测试的重要内容。文档测试对象主要如下：　　-包装文字和图形；　　-市场宣传材料、广告以及其它插页；　　-授权、注册登记表；　　-最终用户许可协议；　　-安装和设置向导；　　-用户手册；　　-联机帮助；　　-样例、示范例子和模板；　　-……　　文档测试的目的是提高易用性和可靠性，降低支持费用，因为用户通过文档就可以自己解决问题。因文档测试的检查内容主要如下：　　-读者对象——主要是文档的内容是否能让该级别的读者理解；　　-术语——主要是检查术语是否适合读者；　　-内容和主题——检查主题是否合适、是否丢失、格式是否规范等；　　-图标和屏幕抓图——检查图表的准确度和精确度；　　-样例和示例——是否与软件功能一致；　　-拼写和语法；　　-文档的关联性——是否与其它相关文档的内容一致，例如与广告信息是否一致；　　文档测试是相当重要的一项测试工作，不但要给予充分的重视，更要要认真的完成，象做功能测试一样来对待文档测试。　　35、没有产品说明书和需求文档地情况下能够进行黑盒测试吗？　　这个问题是国内测试工程师经常遇到的问题，根源就是国内软件开发文档管理不规范，对变更的管理方法就更不合理了。实际上没有任何文档的时候，测试人员是能够进行黑盒测试的，这种测试方式我们可以称之为探索测试，具体做法就是测试工程师根据自己的专业技能、领域知识等不断的深入了解测试对象、理解软件功能，进而发现缺陷。　　在这种做法基本上把软件当成了产品说明书，测试过程中要和开发人员不断的进行交流。尤其在作项目的时候，进度压力比较大，可以作为加急测试方案。最大的风险是不知道有些特性是否被遗漏。　　36、测试中的“杀虫剂怪事”是指什么？　　“杀虫剂怪事”一词由BorisBeizer在其编著的《软件测试技术》第二版中提出。用于描述测试人员对同一测试对象进行的测试次数越多，发现的缺陷就会越来越少的现象。就像老用一种农药，害虫就会有免疫力，农药发挥不了效力。这种现象的根本原因就是测试人员对测试软件过于熟悉，形成思维定势。　　为了克服这种现象，测试人员需要不断编写新的测试程序或者测试用例，对程序的不同部分进行测试，以发现更多的缺陷。也可以引用新人来测试软件，刚刚进来的新手往往能发现一些意想不到的问题。　　37、在配置测试中，如何判断发现的缺陷是普通问题还是特定的配置问题？　　在进行配置测试时，测试工程师仍然会发现一些普通的缺陷，也就是与配置环境无关的缺陷。因此判断新发现的问题，需要在不同的配置中重新执行发现软件缺陷的步骤，如果软件缺陷不出现了，就可能是配置缺陷；如果在所有的配置中都出现，就可能是普通缺陷。　　需要注意的是，配置问题可以在一大类配置中出现。例如，拨号程序可能在所有的外置Modem中都存在问题，而内置的Modem不会有任何问题。　　38、为什么尽量不要让时间有富裕的员工去做一些测试？　　表面上看这体现了管理的效率和灵活性，但实际上也体现了管理者对测试的轻视。测试和测试的人有很大关系。测试工作人员应该是勤奋并富有耐心，善于学习、思考和发现问题，细心有条理，总结问题，如果具备这样的优点，做其它工作同样也会很出色，因此这里还有一个要求，就是要喜欢测试这项工作。如果他是专职的，那么肯定更有经验和信心。国内的小伙子好象都喜欢做程序员，两者工作性质不同，待遇不同，地位不同，对自我实现的价值的认识也不同，这是行业的一个需要改善的问题。如果只是为了完成任务而完成任务，或者发现了几个问题就觉得满意了，这在任何其它工作中都是不行的。　　39、完全测试程序是可能的吗？　　软件测试初学者可能认为拿到软件后需要进行完全测试，找到全部的软件缺陷，使软件“零缺陷”发布。实际上完全测试是不可能的。主要有以下一个原因：　　-完全测试比较耗时，时间上不允许；　　-完全测试通常意味着较多资源投入，这在现实中往往是行不通的；　　-输入量太大，不能一一进行测试；　　-输出结果太多，只能分类进行验证；　　-软件实现途径太多；　　-软件产品说明书没有客观标准，从不同的角度看，软件缺陷的标准不同；　　因此测试的程度要根据实际情况确定。　　40、软件测试的风险主要体现在哪里？　　我们没有对软件进行完全测试，实际就是选择了风险，因为缺陷极有可能存在没有进行测试的部分。举个例子，程序员为了方便，在调试程序时会弹出一些提示信息框，而这些提示只在某种条件下会弹出，碰巧程序发布前这些代码中的一些没有被注释掉。在测试时测试工程师又没有对其进行测试。如果客户碰到它，这将是代价昂贵的缺陷，因为交付后才被客户发现。　　因此，我们要尽可能的选择最合适的测试量，把风险降低到最小。　　41、发现的缺陷越多，说明软件缺陷越多吗？　　这是一个比较常见的现象。测试工程师在没有找到缺陷前会绞尽脑汁的思考，但是找到一个后，会接二连三的发现很多缺陷，颇有个人成就感。其中的原因主要如下：　　-代码复用、拷贝代码导致程序员容易犯相同的错误。类的继承导致所有的子类会包含基类的错误，反复拷贝同一代码意味可能也复制了缺陷。　　-程序员比较劳累是可以导致某些连续编写的功能缺陷较多。程序员加班是一种司空见惯的现象，因此体力不只时容易编写一些缺陷较多的程序。而这些连续潜伏缺陷恰恰时测试工程师大显身手的地方。　　“缺陷一个连着一个”不是一个客观规律，只是一个常见的现象。如果软件编写的比较好，这种现象就不常见了。测试人员只要严肃认真的测试程序就可以了。　　42、所有的软件缺陷都能修复吗？所有的软件缺陷都要修复吗？　　从技术上讲，所有的软件缺陷都是能够修复的，但是没有必要修复所有的软件缺陷。测试人员要做的是能够正确判断什么时候不能追求软件的完美。对于整个项目团队，要做的是对每一个软件缺陷进行取舍，根据风险决定那些缺陷要修复。发生这种现象的主要原因如下：　　-没有足够的时间资源。在任何一个项目中，通常情况下开发人员和测试人员都是不够用的，而且在项目中没有预算足够的回归测试时间，再加上修改缺陷可能引入新的缺陷，因此在交付期限的强大压力下，必须放弃某些缺陷的修改。　　-有些缺陷只是特殊情况下出现，这种缺陷处于商业利益考虑，可以在以后升级中进行修复。　　-不是缺陷的缺陷。我们经常会碰到某些功能方面的问题被当成缺陷来处理，这类问题可以以后有时间时考虑再处理。　　最后要说的是，缺陷是否修改要由软件测试人员、项目经理、程序员共同讨论来决定是否修复，不同角色的人员从不同的角度来思考，以做出正确的决定。　　43、软件测试人员就是QA吗？　　软件测试人员的职责是尽可能早的找出软件缺陷，确保得以修复。而质量保证人员（QA）主要职责是创建或者制定标准和方法，提高促进软件开发能力和减少软件缺陷。测试人员的主要工作是测试，质量保证人员日常工作重要内容是检查与评审，测试工作也是测试保证人员的工作对象。　　软件测试和质量是相辅相成的关系，都是为了提高软件质量而工作。　　44、如何减少测试人员跳槽带来的损失？　　在IT行业里跳槽已经是一种司空见惯的现象，而且跳槽无论给公司还是给个人都会带来一定的损失。测试队伍也无疑会面临跳槽的威胁，作为测试经理管理者，只有从日常工作中开始做起，最能最大限度的减少损失。建议我们从以下两个方面做起：　　-加强部门内员工之间的互相学习，互相学习是建立学习型组织的基本要求，是知识互相转移的过程。在此基础上，可以把个人拥有的技术以知识的形式沉积下来，也就完成了隐性知识到显性知识的转化。　　-通常情况下，企业能为员工提供足够大的发展空间时，如果不是待遇特别低，员工都不会主动离开企业。因此我们要想留住员工，管理者就应该把员工的个人成长和企业的发展联系起来，为员工设定合理发展规划并付诸实现。不过这项要求做起来比较，要有比较好的企业文化为依托。　　45、测试产品与测试项目的区别是什么？　　习惯上把开发完成后进行商业化、几乎不进行代码修改就可以售给用户使用的软件成为软件产品，也就是可以买“卖拷贝”的软件，例如Windows2000。而通常把针对一个或者几个特定的用户而开发的软件成为软件项目，软件项目是一种个性化的产品，可以是按照用户要求全部重新开发，也可以修改已有的软件产品来满足特定的用户需求。项目和产品的不同特点，决定我们测试产品和测试项目仍然会有很多不同的地方：　　-质量要求不同。通常产品的质量要高一些，修复发布后产品的缺陷成本较高，甚至会带来很多负面的影响。而做项目通常面向某一用户，虽然质量越高越好，但是一般只要满足用户要求就可以了。　　-测试资源投入多少不同。做软件产品通常是研发中心来开发，进度压力要小些。同时由于质量要求高，因此会投入较多的人力、物力资源。　　-项目最后要和用户共同验收测试，这是产品测试不具有的特点。　　此外，测试产品与测试项目在缺陷管理方面、测试策略制定都会有很大不同，测试管理者应该结合具体的环境，恰如其分的完成工作。　　46、和用户共同测试（UAT测试）的注意点有哪些？　　软件产品在投产前，通常都会进行用户验收测试。如果用户验收测试没有通过，直接结果就是那不到“Money”，间接影响是损害了公司的形象，而后者的影响往往更严重。根据作者的经验，用户验收测试一定要让用户满意。　　实际上用户现场测试更趋于是一种演示。在不欺骗用户的前提下，我们向用户展示我们软件的优点，最后让“上帝”满意并欣然掏出“银子”才是我们的目标。因此用户测试要注意下面的事项：　　（1）用户现场测试不可能测试全部功能，因此要测试核心功能。这需要提前做好准备，这些核心功能一定要预先经过测试，证明没有问题才可以和用户共同进行测试。测试核心模块的目的是建立用户对软件的信心。当然如果这些模块如果问题较多，不应该进行演示。　　（2）如果某些模块确实有问题，我们可以演示其它重要的业务功能模块，必要时要向用户做成合理的解释。争得时间后，及时修改缺陷来弥补。　　（3）永远不能欺骗用户，蒙混过关。道理很简单，因为软件是要给用户用的，问题早晚会暴露出来，除非你可以马上修改。　　和用户进行测试还要注意各种交流技巧，争取不但短期利益得到了满足，还要为后面得合作打好基础。　　47、如何编写提交给用户的测试报告？　　随着测试工作越来越受重视，开发团队向客户提供测试文档是不可避免的事情。很多人会问：“我们可以把工作中的测试报告提供给客户吗？”答案是否定的。因为提供内部测试报告，可能会让客户失去信心，甚至否定项目。　　测试报告一般分为内部测试报告和外部测试报告。内部报告是我们在测试工作中的项目文档，反映了测试工作的实施情况，这里不过多讨论，读者可以参考相关教材。这里主要讨论一下外部测试报告的写法，一般外部测试报告要满足下面几个要求：　　-根据内部测试报告进行编写，一般可以摘录；　　-不可以向客户报告严重缺陷，即使是已经修改的缺陷，开发中的缺陷也没有必要让客户知道；　　-报告上可以列出一些缺陷，但必须是中级的缺陷，而且这些缺陷必须是修复的；　　-报告上面的内容尽量要真实可靠；　　-整个测试报告要仔细审阅，力争不给项目带来负面作用，尤其是性能测试报告。　　总之，外部测试报告要小心谨慎的编写。　　48、测试工具在测试工作中是什么地位？　　国内的很多测试工程师对测试工具相当迷恋，尤其是一些新手，甚至期望测试工具可以取代手工测试。测试工具在测试工作中起的是辅助作用，一般用来提高测试效率。自动化测试弥补了手工测试的不足，减轻一定的工作量。实际上测试工具是无法替代大多数手工测试的，而一些诸如性能测试等自动化测试也是手工所不能完成的。　　对于自动测试技术，应当依据软件的不同情况来分别对待，一般自动技术会应用在引起大量重复性工作的地方、系统的压力点、以及任何适合使用程序解决大批量输入数据的地方。然后再寻找合适的自动测试工具，或者自己开发测试程序。一定不要为了使用测试工具而使用。　　49、常见的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。　　1-等价类划分　　常见的软件测试面试题划分等价类:等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.　　2-边界值分析法　　边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.　　使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.　　3-错误推测法　　基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法.　　错误推测方法的基本思想:列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例-例如, 在单元测试时曾列出的许多在模块中常见的错误-以前产品测试中曾经发现的错误等,这些就是经验的总结。还有, 输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行-这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例.　　4-因果图方法　　前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系,相互组合等-考虑输入条件之间的相互组合,可能会产生一些新的情况-但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多-因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例-这就需要利用因果图（逻辑模型）-因果图方法最终生成的就是判定表-它适合于检查程序输入条件的各种组合情况.　　5-正交表分析法　　有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。　　6-场景分析方法　　指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。　　50、您认为做好测试用例设计工作的关键是什么？　　白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果　　黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题　　51、详细的描述一个测试活动完整的过程。　　1-项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后sqa进入项目，开始进行统计和跟踪　　2-开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。　　3-测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。　　4-测试用例完成后，测试和开发需要进行评审。　　5-测试人员搭建环境　　6-开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现bug后提交给bugzilla。　　7-开发提交第二个版本，包括bugfix以及增加了部分功能，测试人员进行测试。　　8-重复上面的工作，一般是3-4个版本后bug数量减少，达到出货的要求。　　9-如果有客户反馈的问题，需要测试人员协助重现以及回归测试。　　52、以往是否曾经从事过性能测试工作？请尽可能的详细描述您以往的性能测试工作的完整过程。　　曾经做过一套网管系统的性能测试，主要测试该软件在同时管理大量终端的情况下，在响应时间，cpu/磁盘/内存等参数是否满足要求。　　也曾经做过软交换系统的呼叫性能测试，主要是测试软交换系统在有大量呼叫的情况下，响应时间，呼叫成功率，cpu/磁盘/内存等参数是否满足设计要求。　　53、在您以往的工作中，一条软件缺陷（或者叫bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（bug）记录？　　1-在传统的bugzilla中，bug描述应该包括以下的信息　　2-和bug产生对应的软件版本　　3-开发的接口人员　　4-bug的优先级　　5-bug的严重程度　　6-bug可能属于的模块，如果不能确认，可以用开发人员来判断　　7-bug标题，需要清晰的描述现象　　8-bug描述，需要尽量给出重新bug的步骤　　9-bug附件中能给出相关的日志和截图。　　高质量的bug记录就是指很容易理解的bug记录，所以，对于描述的要求高，能提供的信息多且准确，很好的帮助开发人员定位。　　54、您在从事性能测试工作时，是否使用过一些测试工具？如果有，请试述该工具的工作原理，并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。　　测试网管系统中，使用的mimic来模拟终端，能够大量的节省成本。　　测试软交换系统的时候，使用的prolab来模拟终端并发送呼叫软交换，他完成了同时数百人才能完成的摘机拨号工作，主要工作原理是产生一些符合要求的ip包并发送给软交换系统，同时对软交换系统的回应进行处理，决定下一步动作。　　55、您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？　　主要是保障在大量用户的情况下，服务能正常使用。}