2022年软件测试经典面试题总结.docx

精选学习资料 - - - - - - - - - 1、 什么是兼容性测试？兼容性测试侧重哪些方面？兼容测试：兼容性测试是指测试软件在特定的硬件平台上、不同的应用软件之间、不同的操纵系统平台上、不 同的网络等环境中是否能够很友好的运行的测试；兼容的类型：细分为a硬件兼容性测试：与整机兼容,与外设兼容 b软件兼容性测试：操作系统 /平台的兼容,数据库兼容,不同浏览器兼容,不同应用软件之间的兼容,软硬件 协作的兼容c数据兼容性测试 兼容测试的重点：对兼容环境的分析；通常,是在运行软件的环境不是很确定的情形下,才需要做兼容测试；2、 我现在有个程序,发觉在 Windows 上运行得很慢,怎么判别是程序存在问题仍是软硬件系统存在问题？1、确认当前软硬件配置是否符合软件的举荐标准2、确认当前的系统是否独立,没有对外供应类似消耗CPU,内存等资源的服务；3、假如是 C/S 或 B/S 结构的软件,检查与服务器的连接是否有问题,或者拜访有问题造成；4、在系统没有负载的情形下,查看应用程序对 CPU/内存的拜访情形；5、检查系统是否有中毒的特点；6、可能的话在另一台相同配置,相同操作系统的机器上运行3、 测试的策略有哪些？测试策略可以定义为：项目测试中,描述测试活动的一般方法和目标,其中包括要进行的测试阶段及测试类 型；所以按阶段分：可以分为单元测试,集成测试,系统测试,回来测试等 按测试类型可以分为：黑盒 /白盒测试,静态 /动态测试,手工 /自动化测试,功能 /性能测试,安全性测试,牢靠 性测试,界面测试,强度测试,压力测试,负载测试,容量测试,稳固性测试,兼容性测试,Beta/a 测试等4、 正交表测试用例设计方法的特点是什么？1、用最少的试验掩盖最多的操作,测试用例设计很少,效率高,但是很复杂；2、对于基本的验证功能,以及二次集成引起的缺陷,一般都能找出来；但是更深的缺陷,更复杂的缺陷,仍是 无能为力的；3、具体的环境下,正交表一般都很难做的；大多数,只在系统测试的时候使用此方法；5、 描述测试用例设计的完整过程？对需求文档 产品需求文档、软件需求规格说明书等进行分析需求分析及需求变更的爱护工作；依据需求文档,得出测试需求 功能测试需求、非功能性测试需求；依据测试需求设计测试方案,评审测试方案；方案评审通过后,设计测试用例,再对测试用例进行评审；6、 单元测试的策略有哪些？自顶向下的单元测试策略：先对最顶层的单元进行测试,把顶层所调用的单元做成桩模块；其次对其次层进行 测试,使用上面已测试的模单元做驱动模块；如此类推,直到测试完全部模块；自底向上的单元测试策略：先对模块调用层次图上最低层的模块进行单元测试,模拟调用该模块的模块做驱动 模块；然后再对上面一层做单元测试,用下面已被测试过的模块做桩模块；一次类推,直到测试完全部模块；孤立的测试策略：不考虑每个模块与其他模块之间的关系,为每个模块设计桩模块和驱动模块,每个模块独立 进行测试；7、 你所熟识的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区分与联系如功能测试、性 能测试 ？1 名师归纳总结 - - - - - - -第 1 页,共 14 页精选学习资料 - - - - - - - - - 容量测试 测试系统对不同级别数据容量下的工作才能,意在猎取系统的最正确数据处理容量和最大处理容量；稳固性测试 测试系统的长期稳固运行的才能；同疲惫强度测试的区分是,稳固性测试的压力强度较小,一般趋向于客户现 场日常状态下的压力强度,当然在时间不能保证稳固性的状态下,需要加大压力强度来测试,此时的压力强度 就会高于正常值；兼容性测试是指测试软件在特定的硬件平台上、不同的应用软件之间、不同的操纵系统平台上、不同的网络等 环境中是否能够很友好的运行的测试；压力测试 通过确定一个系统的瓶颈或者不能接受的性能点,来获得系统能供应的最大的服务级别的测试；8、 软件缺陷或者叫Bug 记录都包含了哪些内容？如何提交高质量的软件缺陷Bug 记录？1.bug ID 8.影响版本9.当前指派人12.相关需求3.精炼语言,做到言简意赅；9、 Beta 测试与 Alpha 测试有什么区分？Beta testing 测试 ,测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试；开发者通常不在测试现场 . Alpha testing 测试 ,是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试 . 2 名师归纳总结 - - - - - - -第 2 页,共 14 页精选学习资料 - - - - - - - - - 10、什么是桩模块？什么是驱动模块？桩模块：被测模块调用模块驱动模块：调用被测模块的模块11、什么是扇入？什么是扇出？扇入：被调用次数,扇出：调其它模块数目12、阐述工作版本的定义？软件开发过程中,用于内部测试的功能和性能不完善的软件编译版；工作版本既可以是系统的可操作版本,也可以是要在发布产品中演示的部分功能模块；13、简述一下缺陷的生命周期？提交 ->确认 ->安排 ->修复 ->验证 ->关闭14、你认为做好测试方案工作的关键是什么？总的来说,测试方案由以下几个部分组成：目标和范畴,项目估算,风险方案,资源配置,进度支配跟踪和掌握机制所以,方案工作的关键是做好以下几个任务：测试方案工作的目的是什么？测试方案工作的内容都包括什么？其中哪些是最重要的？也可以用上面的来答复15、你认为做好测试用例工作的关键是什么？需求和设计文档的懂得程度,对系统的熟识程度16、你觉得软件测试通过的标准应当是什么样的？缺陷密度值到达客户的要求17、简述集成测试与系统测试关系？1集成测试的主要依据概要设计说明书,系统测试的主要依据是需求设计说明书；2集成测试是系统模块的测试,系统测试是对整个系统的测试,包括相关的软硬件平台、网络以及相关外设的测试；18、一套完整的测试应当由哪些阶段组成？需求分析 测试方案 测试设计 测试环境搭建 测试执行 测试记录 缺陷治理 软件评估3 名师归纳总结 - - - - - - -第 3 页,共 14 页精选学习资料 - - - - - - - - - 19、集成测试也叫组装测试或者联合测试,请简述集成测试的主要内容？集成测试是在单元测试的基础上,测试在将全部的软件单元依据概要设计规格说明的要求组装成模块、子系统 或系统的过程中各部分工作是否到达或实现相应技术指标及要求的活动；集成测试应当考虑以下问题：1在把各个模块连接起来的时候,穿越模块接口的数据是否会丢失；2一个模块的功能是否会对另一个模块的功能产生不利的影响；3各个子功能组合起来,能否到达预期要求的父功能；4全局数据结构是否有问题；5单个模块的误差累积起来,是否会放大,从而到达不能接受的程度；20、单元测试主要内容是什么？1,模块接口测试；单元测试的基础,只有在数据能正确流入,流出模块的前提下才有意义；2,局部数据结构测试 检查局部数据结构是为了保证暂时储备在模块内的数据在程序执行中完整,正确；重点是一些执行函数是否正确执行,内部是否运行正确；局部数据结构往往是错误的根源,应认真设计测试用例；3,边界条件测试 单元测试中最重要的一项任务；由于软件常常在边界上失败,采纳边界值分析,可能发觉新的错误；4,模块中全部独立路径的测试 在模块中执行每一条独立执行路径进行测试,单元测试的基本任务保证模块中每条语句执行一次；5,模块的各条错误处理通路测试：程序在遇到反常情形时不应当退出,好的程序应能预见各种出错条件,并预设各种出错处理通路；21、如何懂得强度测试？测试系统在高负载,高强度下的工作才能,意在猎取系统在极限状态下运行时的各项性能指数,查看其是否在答应的范畴内；注：1.疲惫强度测试是一类特殊的强度测试,主要测试系统长时间运行后的性能表现,例如 7x24 小时的压力测试；2. 强度测试总是通常模拟系统在反常的资源配置下运行,如人为降低系统工作环境所需要的资源 ,如网络带宽 ,系统内存 ,数据锁等等 ,以测试系统在资源不足的情形下的工作状态22、如何懂得压力、负载、性能测试测试？性能测试是通过自动化的测试工具模拟多种正常、峰值以及反常负载条件来对系统的各项性能指标进行的测试,通常包含了负载测试,压力测试等；b 负载测试 通过测试系统在资源超负荷情形下的表现,以发觉设计上的错误或验证系统的负载才能；在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及连续正常运行的能 力；负载测试的目标是确定并确保系统在超出最大预期工作量的情形下仍能正常运行；c 压力测试 压力测试是在强负载下的测试,查看应用系统在峰值使用情形下性能行为,从而有效地发觉系统的某项功能隐 患、系统是否具有良好的容错才能和可复原才能,检测系统能供应的最大的服务级别的测试；压力测试可以看成是强负载下的负载测试；4 名师归纳总结 - - - - - - -第 4 页,共 14 页精选学习资料 - - - - - - - - - 23、什么是系统瓶颈？软件系统业务才能起限制,约束,使其不能满意用户特定业务需求的关键因素；严格的技术角度上讲,全部的系统都会有瓶颈,由于大多数系统的资源配置是不和谐的,如 cup 使用率刚好到达 100% 时,内存正好耗尽的系统；但是不多见；所以我们要从应用角度争论：关键是看系统能否满意用户需求；在用户极限使用系统的情形下,系统的响应仍旧正常,可以认为系统没有瓶颈或者瓶颈不影响用户工作；测试系统瓶颈主要是实现下面两个目的：-发觉外表的瓶颈；模拟用户的操作,找出用户极限使用系统时的瓶颈,然后解决瓶颈,这是性能测试的基本目标；-发觉潜在的瓶颈并解决,保证系统的长期稳固；24、软件测试人员就是QA 吗？软件测试人员的职责是尽可能的找出软件缺陷,确保缺陷能被修复；QA 质量保证人员主要职责是创建或者制定标准和方法,提高促进软件开发才能和削减软件缺陷；测试人员的主要工作是测试,质量保证人员日常工作重要内容是检查与评审,测试工作也是保证人员的工作对象；25、什么是软件测试,软件测试的目的？包括阶段性产品进行验证和确认的活动过程,其目的软件测试就是贯穿整个软件开发生命周期、对软件产品是尽快尽早地发觉在软件产品中存在的各种问题与用户需求、预先的定义不一样的地方；26、写出 bug 报告流转的步骤,每步的责任人及主要完成的工作；测试人员提交新的 Bug 入库,错误状态为 New ；高级测试员 /测试经理验证缺陷,假如缺陷已经提交,拒绝,标记为Declined-Duplicated ,假如确认未提交且是缺陷,安排给开发组；设置状态为 Open；假如不是缺陷,就拒绝,设置为 Declined 状态；开发经理安排 bug 至对应的模块开发人员；开发人员查询状态为 Open 的缺陷,假如不行以重现就更新报告,反馈给开发经理；可以重现就判定是否可以修复,是就修复并置状态为 Fixed；不能解决的 Bug,要留下文字说明及保持 Bug 为 Open 状态；对于不能解决和延期解决的缺陷,不能由开发人员自己打算,一般要通过某种会议评审会通过才能认可；测试人员查询状态为 Fixed 的缺陷,然后验证缺陷是否已解决,如解决,置缺陷的状态为 Closed,如没有解决 ,置缺陷状态为 Reopen；查询状态为 Declined-Duplicated 的缺陷,进行关闭,置缺陷的状态为 Closed；27、画出软件测试的 V 模型图；5 名师归纳总结 - - - - - - -第 5 页,共 14 页精选学习资料 - - - - - - - - - 28、请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区分与联系；黑盒测试：已知产品的功能设计规格,可以进行测试证明每个已经实现的功能是否符合需求；白盒测试：已知产品的内部工作过程,可以通过测试证明每种内部操作是否符合设计规格的要求；全部内部成 分是否经过检查；黑盒测试要在软件的接口处进行,这种方法是把测试对象看做一个黑盒子,测试人员完全不考虑程序内部规律 和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符合太的功能说明；因此黑盒测试又叫功能 测试或者数据驱动测试；白盒测试是对软件的过程性细节做认真的检查,这种方法是把测试对象看做一个打开的盒子,太答应测试人员 利用程序内部的规律结构和有关信息,设计或者挑选测试用例,对程序全部规律路径进行测试；通过不同点检 查程序的状态,确定实际状态是否与预期的状态一样；因此,白盒测试又叫规律驱动测试或者结构测试；单元测试模块测试是开发者编写的一小段代码,用于检验被测代码的一个很小的,很明确的功能是否正 确；通常而言,一个单元测试用于判定某个特定条件下某个特定函数的行为,由程序员自己完成；集成测试组装测试,联合测试是单元测试的规律扩展；它的最简洁形式：两个已经测试过的单元组合成一 个组件,并且测试他们之间的接口；方法是测试片段的组合,并最终扩展进程,将您的模块与其他组的模块一 起测试,最终,将构成进程的全部模块一起测试；系统测试：将经过测试的子系统装配成一个完整的系统来测试；目的是对最终软件系统进行全面的测试,确保 最终软件系统满意产品需求并且遵循系统设计；验收测试：目的是确保软件预备就绪,并且可以让最终用户将其用于执行软件的既定功能和任务；验收测试向用户外表系统能够像预定需求那样工作；29、测试用例通常包括那些内容？着重阐述编制测试用例的具体做法 标识符 ID 测试项 测试需求 测试环境 6 名师归纳总结 - - - - - - -第 6 页,共 14 页精选学习资料 - - - - - - - - - 测试前提 输入数据 操作步骤 : 预期输出 实际输出 测试用例之间的关联其他元素 : 优先级 所在模块 测试时间测试人 编制人 审评人 版本号 测试阶段 测试类型30、集成测试通常都有那些策略？自顶向下测试 自顶向下集成Top-Down Integration 方式是一个递增的组装软件结构的方法；从主控模块主程序开头沿 掌握层向下移动,把模块一一组合起来；分两种方法：第一：先深度：依据结构,用一条主掌握路径将全部模块组合起来；其次：先宽度：逐层组合全部下属模块,在每一层水平地 步骤一：用主控模块作为测试驱动程序,其直接下属模块用承接模块来代替；步骤二：依据所挑选的集成测试法先深度或先宽度步骤三：在组合每个实际模块时都要进行测试；,每次用实际模块代替下属的承接模块步骤四：完成一组测试后再用一个实际模块代替另一个承接模块；步骤五：可以进行回来测试即重新再做全部的或者部分已做过的测试自底向上测试,以保证不引入新的错误；自底向上的集成Bottom-Up Integration 方式是最常使用的方法；其他集成方法都或多或少地继承、吸取了这 种集成方式的思想；自底向上集成方式从程序模块结构中最底层的模块开头组装和测试；由于模块是自底向上 进行组装的,对于一个给定层次的模块,它的子模块包括子模块的全部下属模块事前已经完成组装并经过 测试,所以不再需要编制桩模块一种能模拟真实模块,给待测模块供应调用接口或数据的测试用软件模块；自底向上集成测试的步骤大致如下：依据概要设计规格说明,明确有哪些被测模块；在熟识被测模块性质的基础上对被测模块进行分层,步骤一：在同一层次上的测试可以并行进行,然后排出测试活动的先后关系,制定测试进度方案；,可以排出各活动之间 的时间序列关系,处于同一层次的测试活动可以 同时进行,而不会相互影响；步骤二：在步骤一的基础上,按时间线序关系,将软件单元集成为模块,并测试在集成过程中显现的问题；这7 名师归纳总结 - - - - - - -第 7 页,共 14 页精选学习资料 - - - - - - - - - 里,可能需要测试人员开发一些驱动模块来驱动集成活动中形成的被测模块；对于比较大的模块,可以先将其 中的某几个软件单元集成为子模块,然后再集成为一个较大的模块；步骤三：将各软件模块集成为子系统或分系统；检测各自子系统是否能正常工作；同样,可能需要测试人员开发少量的驱动模块来驱动被测子系统；步骤四： 将各子系统集成为最终用户系统,测试是否存在各分系统能否在最终用户系统中正常工作；方案点评：自底向上的集成测试方案是工程实践中最常用的测试方法；相关技术也较为成熟；它的优点很明 显： 治理便利、测试人员能较好地锁定软件故障所在位置；但它对于某些开发模式不适用,如使用 XP 开发方 法,它会要求测试人员在全部软件单元实现之前完成核心软件部件的集成测试；尽管如此,自底向上的集成测 试方法仍不失为一个可供参考的集成测试方案；核心系统测试 核心系统先行集成测试法的思想是先对核心软件部件进行集成测试,在测试通过的基础上再按各外围软件部件 的重要程度逐个集成到核心系统中；每次加入一个外围软件部件都产生一个产品基线,直至最终形成稳固的软 件产品；核心系统先行集成测试法对应的集成过程是一个逐步趋于闭合的螺旋形曲线,代表产品逐步定型的过 程；其步骤如下：步骤一： 对核心系统中的每个模块进行单独的、充分的测试,必要时使用驱动模块和桩模块；步骤二：对于核心系统中的全部模块一次性集合到被测系统中,解决集成中显现的各类问题；在核心系统规模 相对较大的情形下,也可以依据自底向上的步骤,集成核心系统的各组成模块；步骤三：依据各外围软件部件的重要程度以及模块间的相互制约关系,拟定外围软件部件集成到核心系统中的 次序方案；方案经评审以后,即可进行外围软件部件的集成；步骤四： 在外围软件部件添加到核心系统以前,外围软件部件应先完成内部的模块级集成测试；步骤五： 按次序不断加入外围软件部件,排除外围软件部件集成中显现的问题,形成最终的用户系统；方案点评：该集成测试方法对于快速软件开发很有成效,适合较复杂系统的集成测试,能保证一些重要的功能 和服务的实现；缺点是采纳此法的系统一般应能明确区分核心软件部件和外围软件部件,核心软件部件应具有 较高的耦合度,外围软件部件内部也应具有较高的耦合度,但各外围软件部件之间应具有较低的耦合度；高频集成测试 高频集成测试是指同步于软件开发过程,每隔一段时间对开发团队的现有代码进行一次集成测试；如某些自动 化集成测试工具能实现每日深夜对开发团队的现有代码进行一次集成测试,然后将测试结果发到各开发人员的 电子邮箱中；该集成测试方法频繁地将新代码加入到一个已经稳固的基线中,以免集成故障难以发觉,同时控 制可能显现的基线偏差；使用高频集成测试需要具备肯定的条件：可以连续获得一个稳固的增量,并且该增量 内部已被验证没有问题；大部分有意义的功能增加可以在一个相对稳固的时间间隔如每个工作日内获得；测试包和代码的开发工作必需是并行进行的,并且需要版本掌握工具来保证始终爱护的是测试脚本和代码的最 新版本；必需借助于使用自动化工具来完成；高频集成一个显著的特点就是集成次数频繁,明显,人工的方法 是不胜任的；高频集成测试一般采纳如下步骤来完成：步骤一：挑选集成测试自动化工具；如很多Java 项目采纳Junit+Ant 方案来实现集成测试的自动化,也有一些8 名师归纳总结 - - - - - - -第 8 页,共 14 页精选学习资料 - - - - - - - - - 商业集成测试工具可供挑选；步骤二：设置版本掌握工具,以确保集成测试自动化工具所获得的版本是最新版本；如使用CVS 进行版本控制；步骤三： 测试人员和开发人员负责编写对应程序代码的测试脚本；步骤四：设置自动化集成测试工具,每隔一段时间对配置治理库的新添加的代码进行自动化的集成测试,并将 测试报告汇报给开发人员和测试人员；步骤五： 测试人员监督代码开发人员准时关闭不合格项；依据步骤三至步骤五不断循环,直至形成最终软件产品；方案点评：该测试方案能在开发过程中准时发觉代码错误,能直观地看到开发团队的有效工程进度；在此方案 中,开发爱护源代码与开发爱护软件测试包被给予了同等的重要性,这对有效防止错误、准时订正错误都很有 帮忙；该方案的缺点在于测试包有时候可能不能暴露深层次的编码错误和图形界面错误；以上我们介绍了几种常见的集成测试方案,一般来讲,在现代复杂软件项目集成测试过程中,通常采纳核心系 统先行集成测试和高频集成测试相结合的方式进行,自底向上的集成测试方案在采纳传统瀑布式开发模式的软 件项目集成过程中较为常见；读者应当结合项目的实际工程环境及各测试方案适用的范畴进行合理的选型；31、阶段评审与项目评审有什么区分？标记 阶段评审 对项目各阶段评审：对阶段成果和工作 项目评审 对项目总体评审：对工作和产品32、测试产品与测试项目的区分是什么？习惯上把开发完成进行商业化,几乎不进行代码修改就可以售给用户使用的软件称为软件产品；把针对一个或几个特定的用户而开发的软件称为软件项目,软件项目是一种个性化的产品,可以是依据用户要 求全部重新开发,也可以修改已有的软件产品来满意特定的用户需求；区分：1.质量不同,产品的质量要求高一些,修复发布后产品的缺陷成本较高,甚至带来很多负面的影响；而项目通 常面对某一个用户,虽然质量越高越好,但是一般只要满意用户要求就可以；2.测试资源投入多少不同；软件产品通常是研发中心来开发,进度压力要小些,同时由于质量要求高,因此会 投入较多的人力,物力资源；33、和用户共同测试UAT 测试的留意点有哪些？软件产品在投产前,通常都会进行用户验收测试；假如用户验收测试没有通过,直接结果就是拿不酬劳,间接 影响是损害了公司的形象,而后者的影响往往更严峻；依据作者的体会,用户验收测试肯定要让用户中意；实际上用户现场测试更趋于是一种演示；在不欺诈用户的前提下,我们向用户展现我们软件的优点,最终让“ 用户” 中意并欣然支付酬劳才是我们的目标；因此用户测试要留意下面的事项：9 名师归纳总结 - - - - - - -第 9 页,共 14 页精选学习资料 - - - - - - - - - 1用户现场测试不行能测试全部功能,因此要测试核心功能；这需要提前做好预备,这些核心功能肯定要预 先经过测试,证明没有问题才可以和用户共同进行测试；测试核心模块的目的是建立用户对软件的信心；当然假如这些模块假如问题较多,不应当进行演示；2假如某些模块的确有问题,我们可以演示其它重要的业务功能模块,必要时要向用户做成合理的说明；争 得时间后,准时修改缺陷来补偿；3永久不能欺诈用户,蒙混过关；道理很简洁,由于软件是要给用户用的,问题早晚会暴露出来,除非你可以立刻修改；和用户进行测试仍要留意各种沟通技巧,争取不但短期利益得到了满意,仍要为后面得合作打好基础；34、您所熟识的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中 的应用；1等价类划分划分等价类 : 等价类是指某个输入域的子集合.在该子集合中 ,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定 :测试某等价类的代表值就等于对这一类其它值的测试 .因此 ,可以把全部输入数据合理划分为假设干等价类 ,在每一个等价类中取一个数据作为测试的输入条件 ,就可以用少量代表性的测试数据 .取得较好的测试结果 .等价类划分可有两种不同的情形 :有效等价类和无效等价类 . 2边界值分析法边界值分析方法是对等价类划分方法的补充；测试工作体会告知我,大量的错误是发生在输入或输出范畴的边界上 ,而不是发生在输入输出范畴的内部 .因此针对各种边界情形设计测试用例 ,可以查出更多的错误 . 使用边界值分析方法设计测试用例 ,第一应确定边界情形 .通常输入和输出等价类的边界 ,就是应着重测试的边界情形 .应当选取正好等于 ,刚刚大于或刚刚小于边界的值作为测试数据 ,而不是选取等价类中的典型值或任意值作为测试数据 . 3错误估计法基于体会和直觉估计程序中全部可能存在的各种错误 , 从而有针对性的设计测试用例的方法 . 错误估计方法的基本思想 : 列举出程序中全部可能有的错误和简洁发生错误的特殊情形 ,依据他们挑选测试用例 . 例如 , 在单元测试时曾列出的很多在模块中常见的错误 . 以前产品测试中曾经发觉的错误等 , 这些就是体会的总结 . 仍有 , 输入数据和输出数据为 0 的情形 . 输入表格为空格或输入表格只有一行 . 这些都是简洁发生错误的情形 . 可挑选这些情形下的例子作为测试用例 . 4因果图方法前面介绍的等价类划分方法和边界值分析方法 ,都是着重考虑输入条件 ,但未考虑输入条件之间的联系 , 相互组合等 . 考虑输入条件之间的相互组合 ,可能会产生一些新的情形 . 但要检查输入条件的组合不是一件简洁的事情 , 即使把全部输入条件划分成等价类 ,他们之间的组合情形也相当多 . 因此必需考虑采纳一种适合于描述对于多种条件的组合 ,相应产生多个动作的形式来考虑设计测试用例 . 这就需要利用因果图规律模型. 因果图方法最终生成的就是判定表 . 它适合于检查程序输入条件的各种组合情形 . 35、软件测试报告应当包含哪些内容？编写目的 :这部分描述文档内容简要输入文档 :：说明编写此报告的输入文档包括：信息、数据、结果等测试进度： 记录测试类型,测试活动的起始和终止时间测试版本： 记录实际测试活动中所测试的版本测试环境： 描述实际测试活动中使用的测试环境,并附测试环境网络拓扑图测试过程所完成的测试类型：描述实际测试活动中所进行的各种测试活动及工作内容10 名师归纳总结 - - - - - - -第 10 页,共 14 页精选学习资料 - - - - - - - - - 测试工作量： 记录测试过程中各类人员的工作量投入 测试结果分析：代码掩盖率分析 代码掩盖率分析 测试需求掩盖情形 用例执行情形分析 系统性能指标分析 测试问题回忆：描述测试工作终止后,遗留的问题和问题未能解决的缘由；描述在测试工作中遇到的问题,如 沟通情形,测试环境情形,典型的测试技术和解决方案 测试量化数据分析：测试汇总信息 缺陷数据分析 缺陷总体数据统计 缺陷分级统计 缺陷来源分析 遗留缺陷与典型缺陷分析 测试结论及产品质量分析 缺陷清单36、软件验收测试除了alpha ,beta 测试以外 ,仍有哪一种 . 正式验收测试37、需求测试留意事项有哪些？2 完整性：每一项需求都必需将全部要实现的功能描述清晰,以使开发人员获得设计和实现这些功能所需的所 有必要信息；2 正确性：每一项需求都必需精确的陈述其要开发的功能；2 一样性：指与其它软件需求或高层需求不相冲突 2 可行性：每一项需求都必需是已系统和环境的权能和限制范畴可以实施的；2 无二义性：对全部需求说明的读者都只能有一个明确统一的说明,由于自然语言极易导致二义性,所以尽量 把每项需求简明的用户性的语言表达出来；2 健壮性：需求的说明中是否对可能显现的反常进行了分析,并且对这些反常进行了容错处理；2 必要性：可懂得为每项需求都是用来授权你编写文档的“ 根源”,要使每项需求都能回溯至某项客户的输入；2 可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试；2可修改性：每项需求只应在SRS中显现一次；这样更换时简洁保持一样性；另外,使用目录列表、索引和相互参照列表方法使软件需求规格说明书更简洁修改；2 可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链,这种可跟踪性要求每项需求以一种结构化的,粒度好f i n e - g r a i n e d 的方式编写并单独标明,而不是大段大段的表达；2 安排优先级：应当对全部的需求安排优先级；假如把全部的需求都看作同样的重要,那么项目治理者在开发或节约预算或调度中就丢失掌握自由度11 名师归纳总结 - - - - - - -第 11 页,共 14 页精选学习资料 - - - - - - - - - 38、简述软件系统中用户文档的测试要点？ 1读者群；文档面对的读者定位要明确；对于初级用户、中级用户以及高级用户应当有不同的定位 2术语；文档中用到的术语要适用与定位的读者群,用法一样,标准定义与业界标准相吻合； 3正确性；测试中需检查全部信息是否真实正确,查找由于过期产品说明书和销售人员夸大事实而 导致的错误；检查全部的目录、索引和章节引用是否已更新,尝试链接是否精确,产品支持、地址和邮 政编码是否正确； 4完整性；对比软件界面检查是否有重要的分支没有描述到,甚至是否有整个大模块没有描述到,主要是测试文档内容的全面性； 5一样性；依据文档描述的操作执行后,检查软件返回的实际结果是否与文档描述的相同； 6易用性；对关键步骤以粗体或背景色给用户以提示,合理的页面布局、适量的图表都可以给用户 更高的易用性；需要留意的是文档要有助于用户排除错误；不但描述正确操作,也要描述错误处理方法；文档对于用户看到的错误信息应当有更具体的文档说明； 7图表与界面截图；检查全部图表与界面截图是否与发行版本相同； 8样例与例如；像用户一样载入和使用样例；假如是一段程序,就输入数据并执行它；以每一个模 块制作文件,确认它们的正确性； 9语言；不显现错别字,不要显现有二义性的说法；特殊要留意的是屏幕截图或绘制图形中的文 字； 10印刷与包装；检查印刷质量；手册厚度与开本是否合适；包装盒的大小是否合适；有没有零碎易 丢失的小部件等等；39、软件测试的文档测试应当贯穿于软件生命周期的全过程,其中用户文档是文档测试的重点；那么软件系统 的用户文档包括哪些？用户手册安装和设置指导 联机帮忙 指南、向导 样例、例如和模板 授权 /注册登记表 最终用户许可协议40、软件的构造号与版本号之间的区分？BVTBuildVerificationTest标记参考答案：版本掌握命名格式: 主版本号 .子版本号 .修正版本号 .编译版本号 Major.Minor .Revision.Build 应依据下面的商定使用这些部分：Major ：具有相同名称但不同主版本号的程序集不行互换；例如,这适用于对产品的大量重写,这些重写 使得无法实现向后兼容性；Minor ：假如两个程序集的名称和主版本号相同,而次版本号不同,这指示显著增强,但照料到了向后兼 容性；例如,这适用于产品的修正版或完全向后兼容的新版本；Build ：内部版本号的不同表示对相同源所作的重新编译；这适合于更换处理器、平台或编译器的情形；Revision ：名称、主版本号和次版本号都相同但修订号不同的程序集应是完全可互换的；这适用于修复以 前发布的程序集中的安全漏洞；BVTBuildVerificationTest：作为 Build 的一部分,主要是通过对基本功能、特殊是关键功能的测试,保证新增代码没有导致功能失 效,保证版本的连续稳固；实现 BVT 方式是有以下几种：1、测试人员手工验证关键功能实现的正确性；特点：这是传统开发方法中,通常采纳的方式；无需爱护测试脚本的成本,在测试人力资源充分,测试人 员熟识业务、并对系统操作娴熟情形下效率很高,比较敏捷快速；缺点：人力成本较高；对测试人员才能有肯定要求；测试人员面对重复的工作,简洁产生疲惫懈怠,从而影响测试质量；12 名师归纳总结 - - - - - - -第 12 页,共 14 页精选学习资料 - - - - - - - - - 2、借助基于 GUI 的自动化功能测试工具来完成,将各基本功能操作录制成测试脚本,每次回放测试脚本 验证功能实现的正确性；特点：能够模拟用户操作完成自动的测试,从 UI 入口到业务实现,每一层的代 码实现都经过验证；节约人力成本；降低测试人员重复劳动的工作量,机器不会疲惫；缺点：对于 UI 变 动比较频繁的系统来说,这种方式的爱护成本很高,实施起来特别困难；另外,在项目周期较短且后续无连续性或继承的情形下,也不举荐使用此方式；3、由开发人员通过自动化测试工具完成业务层的BVT 测试；特点：通过对业务层关键功能的连续集成测试,保证系统功能的连续稳固；可以结合DailyBuild ,做为 Build 的一部分,自动实现并输入BVT 报告；缺点：仅对业务规章实现的正确性进行了测试,对表现层无法测试到,对于诸如：前台页面控件各种大事 响应、页面元素变化等方面的问题无法保证；41、引入测试治理的含义？标记 风险分析,进度掌握、角色安排、质量掌握42、软件的安全性应从哪几个方面去测试？用户认证机制：如数字证书、智能卡、双重认证、安全电子交易协议 加密机制 安全防护策略：如安全日志、入侵检测、隔离防护、漏洞扫描 数据备份与复原手段：储备设备、储备优化、储备爱护、储备治理 防病毒系统开发及环境搭建类面试题43、简述 DNS 、活