[TOC] ## **一、软件工程** <details> <summary>1. 阐述软件生命周期都有哪些阶段？常见的软件生命周期模型有哪些？</summary> ``` 软件生命周期是指一个计算机软件从功能确定、设计，到开发成功投入使用，并在使用 中不断地修改、增补和完善，直到停止该软件的使用的全过程（从酝酿到废弃的过程）。 生命周期从收到应用软件开始算起，到该软件不再使用为止。它有如下各方面的内容： 初始构思、需求分析、功能设计、内部设计、文档计划、测试计划、文档准备、集成、 测试、维护、升级、再测试、逐步淘汰 (phase-out)、等等。 瀑布模型，迭代式模型，快速原型模型，螺旋模型。 ``` </details> <br/> <details> <summary>2. 什么是版本控制，常用的版本控制系统有哪些？</summary> ``` 版本控制（Revision control）是一种软体工程技巧，籍以在开发的过程中，确保由不同 人所编辑的同一档案都得到更新。 Git(读音为/gɪt/。)是一个开源的分布式版本控制系统，可以有效、高速的处理从很小到 非常大的项目版本管理。 Git 是Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控 制软件。https://git-scm.com/doc SVN 是 Subversion 的简称，是一个开放源代码的版本控制系统，相较于 RCS、CVS， 它采用了分支管理系统，它的设计目标就是取代CVS。互联网上很多版本控制服务已从CVS 迁移到Subversion。https://tortoisesvn.net/support.html ``` </details> <br/> <details> <summary>3. 简述软件测试与软件开发之间的关系？</summary> ``` （1）项目规划阶段：负责从单元测试到系统测试的整个测试阶段的监控。 （2）需求分析阶段：确定测试需求分析、系统测试计划的制定，评审后成为管理项目。 测试需求分析是对产品生命周期中测试所需求的资源、配置、每阶段评判通过的规约； 系统测试计划则是依据软件的需求规格说明书，制定测试计划和设计相应的测试用例。 （3）详细设计和概要设计阶段：确保集成测试计划和单元测试计划完成。 （4）编码阶段：由开发人员进行自己负责部分的代码的测试。在项目较大时，由专人 进行编码阶段的测试任务。 （5）测试阶段（单元、集成、系统测试）：依据测试代码进行测试，并提交相应的测 试状态报告和测试结束报告。 开发和测试是一个有机的整体！在产品的发布之前，开发和测试是循环进行的，测出的 缺陷要经开发人员修改后继续测试。在开发的同时测试经理开始编写测试用例，测试文 档要参考开发文档，所以开发和测试是不可分割的，少了任何一个都不能开发出产品。 从角色方面看，像理论和实验的关系，开发人员通过自己的想象创造出一套思想，之后 测试人员再对它进行检验、证伪，开发人员再修改的过程从而不断丰富产品。从方法方 面看，是演绎和归纳的关系，一个要掌握大量的技术，一个要不断的从实例中学习。因 这两方面的不同，所以开发和测试看上去做的工作很不一样。 开发与测试是相辅相承、密不可分的，开发人员开发出新的产品后要通过测试判断产品 是否完全满足用户的需求。如果发现缺陷，提交给开发人员进行修复，然后再转交测试 人员进行回归测试，直到产品符合需求规格说明。一个符合用户需求的产品是开发和测 试共同努力的成果。 ``` </details> <br /> <details> <summary>4. 什么是软件测试，定义和目的？ </summary> ``` 目的：用最少的人力、物力、时间来找到软件的错误并修复，从而降低商业风险 定义：使用人工和自动手段来检测软件是否满足需求 ``` </details> <br /> ## **二、测试模型** <details> <summary>5. 常见测试模型有哪些</summary>  * 特点：这是一种古老的瀑布模型，反映了实际和测试之间的关系 * 局限：仅仅把测试过程作为编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，如果前面设计错误，得一直到后期的验收测试才被发现，耗时耗力。  * 特点：测试与开发同时进行，在 V 模型的基础上，增加了在开发阶段的同步测试 * 局限：仍然不支持迭代，减少了一定错误发生率，但是需按照流水线进行设计、编码和测试 </details> <br /> <details> <summary>6. 请根据”V”模型分别概述测试人员在软件的需求定义阶段、设计阶段、编码阶段、系统集成阶段的工作任务及其相应生成的文档？ </summary> ``` 统集成阶段的工作任务及其相应生成的文档？ 需求定义阶段：根据项目需求提取测试需求 并形成测试需求文档，根据提取的测试需求和项目计 划进行测试计划的拟定，测试计划文档 设计阶段：根据测试需求拟定测试方案并形成测试方案文档；根据测试方案制定测试用例，并形 成测试用例文档 编码阶段：执行测试并完善测试用例文档 系统集成阶段：测试总结报告，阶段问题统计报告，测试问题报告 ``` </details> <br /> <details> <summary>7. W 模型的描述？</summary> ``` 软件测试主要内容是对软件正确性、完整性、安全性和质量确认及验证。为了验证这些，软件测 试是与开发同步进行的，它们之间的关系同步进行一一对应，当开发进行需求分析、概要设计、 详细设计、编码实现、模块集成、系统构建与实施、交付运行时，测试人员对应工作是需求测 试、概要设计测试、详细设计测试、单元测试、集成测试、系统测试、验收测试。 图中显示W模型增加了软件开发各阶段中同步进行的验证和确认活动，测试的活动与软件开发整 体是同步进行，测试的对象不仅仅是程序，还包括需求和设计，有利于尽早地全面的发现问题可 降低软件开发和成本。 ``` </details> <br /> ## **三、测试计划** <details> <summary>8. 编写测试计划的目的是？</summary> 使测试工作顺利进行；使项目参与人员沟通更舒畅；使测试工作更加系统化。 </details> <br /> <details> <summary>9. 测试计划编写的六要素？</summary> ``` why——为什么要进行这些测试 what—测试哪些方面，不同阶段的工作内容 when—测试不同阶段的起止时间 where—相应文档，缺陷的存放位置，测试环境等 who—项目有关人员组成，安排哪些测试人员进行测试 how—如何去做，使用哪些测试工具以及测试方法进行测试。 ``` </details> <br /> <details> <summary>10.项目版本执行过程中，测试人员如何把控测试进度？</summary> ``` 在项目的系统测试过程中，测试负责人要及时了解测试进度，跟踪 BUG 提交、修复及验证情况 以及系统的拷机情况。 在开发初期阶段，测试组执行 BBFV 时，很多模块、功能点的开发完成进度和原计划会存在一定 的偏差，就需要测试负责人动态的刷新 WBS 计划，根据实际的开发进度调整测试计划。 在开发阶段，存在版本编译不出来导致无法测试，开发人员修复代码太随意导致版本稳定性反 复，需求变更过大导致后端测试开发变更严重等现象，会导致测试工作无法正常进行。就需要测 试负责人及时反馈出来，根据项目本身的特点进行对应的处理。 当测试进度出现延期时，要及时确认问题原因，如果是问题协查导致，则需及时与研发人员进行 沟通协商，看问题是否必须在测试环境进行排查，若为必现问题可与研发协商要求其在自己环境 进行排查，若必须占用测试环境，则需及时调整测试计划，若因此可能影响版本的发布，则应及 时与 SE 确认。 若发现有较多 BUG 未解决，则应主动联系 SE 及研发人员召开 BUG 会确定问题的解决时间。若 发现有较多 BUG未验证，则应提醒项目组的测试人员及时进行验证，对于一些拷机或非必现的 BUG，建议测试人员在此 BUG 上现做拷机标记，连续拷机一周未再复现的做关闭处理，若再次 复现则继续进行排查。 疑难问题的跟控：比较难复现的问题，怎么去尝试复现。比较难定位的问题，怎么驱动、反馈给 SE，协调开发人员定位问题。比较难处理的问题，怎么跟控反馈进度等 每天下班前需确认拷机内容，每天上班第一件事需确认拷机结果，只有这样才能保证拷机的效 果，实现拷机的真正意义。 ``` </details> <br /> <details> <summary>11.测试人员在软件开发过程中的任务是什么？</summary> ``` 寻找 Bug；避免软件开发过程中的缺陷；衡量软件的品质；关注用户的需求。总的目标是：确保 软件的质量。 ``` </details> <br /> <details> <summary>12.请列出你所知道的软件测试种类，至少 5 项？</summary>  </details> <br /> ## **四、测试类型** <details> <summary>13.黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系？</summary> ``` 黑盒测试：把测试对象当成一个黑盒子，测试人员完全不考虑逻辑结构和内部特性， 只 依据程式的需求说明书来检查程序的功能是否满足它的功能说明。 白盒测试：把测试对象当成一个透明的盒子，允许测试人员利用程序内部逻辑结构及相 关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。 单元测试：白盒测试的一种，对软件设计中的单元模块进行测试。 集成测试：在单元测试的基础上，对单元模块之间的连接和组装进行测试。 系统测试：在所有都考虑的情况下，对系统进行测试。 验收测试：第三方进行的确认软件满足需求的测试。 ``` </details> <br /> <details> <summary>14.黑盒测试和白盒测试常用的测试方法有哪些，举个例子？</summary> ``` 黑盒有等价类划分法，边界分析法，因果图法和错误猜测法。 白盒有逻辑覆盖法，循环测试路径选择，基本路径测试。 例子：在一次输入多个条件的完整性查询中。利用等价类划分法则和边界分析法则，首 先利用等价类划分法，可以一个或多个结果是OK的测试用例，然后确认多个NG的测试 用例，然后利用边界值分析法，可以对结果分别是OK和NG的测试用例进行扩展和补充。 ``` </details> <br /> <details> <summary>15. 简述黑盒测试和白盒测试的优缺点？</summary> ※ 黑盒测试的优点有： 1. 比较简单，不需要了解程序内部的代码及实现； 2. 与软件的内部实现无关； 3. 从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题； 4. 基于软件开发文档，所以也能知道软件实现了文档中的哪些功能； 5. 在做软件自动化测试时较为方便。 ※ 黑盒测试的缺点有： 1. 不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的 30%； 2. 自动化测试的复用性较低。 ※ 白盒测试的优点有： 1. 帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。 ※ 白盒测试的缺点有： 1. 程序运行会有很多不同的路径，不可能测试所有的运行路径；测试基于代码，只能测试开发人员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求；系统庞大时，测试开销会非常大。 </details> <br /> <details> <summary>16.在没有产品说明书和需求文档的情况下能够进行黑盒测试的设计吗？</summary> ``` 能，可以通过其他工作内容去替代产品说明书和需求文档 根据客户的功能点整理测试需求追溯表 根据开发人员的 Software Specification List 整理功能测试点 开展项目跨部门讨论会，主要整理对功能点的理解和认识 测试人员整理用例需求疑问提交项目组或者产品 项目内部的用例品胜 邮件客户代表确认部分争议问题 项目的 Demo 和部分已经开发的系统 参考同行业和竞争对手的类似产品 交叉模块之间的测试 咨询客户或相关者 ``` </details> <br /> <details> <summary>17.单元测试的策略有哪些，主要内容有哪些？</summary> 逻辑覆盖，循环覆盖，同行评审，桌前检查，代码走查，代码评审，静态数据流分析。 </details> <br /> <details> <summary>18. 白盒测试逻辑覆盖有哪几种覆盖标准，覆盖率最高的是什么？</summary> 语句覆盖，分支覆盖，条件覆盖，路径覆盖，分支条件覆盖，覆盖率最高的是路径覆盖。 ``` 1.语句覆盖：就是设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。 2.判定覆盖：使设计的测试用例保证程序中每个判断的每个取值分支至少经历一次。 3.条件覆盖：条件覆盖是指选择足够的测试用例，使得运行这些测试用例时，判定中每个 条件的所有可能结果至少出现一次，但未必能覆盖全部分支 4.判定条件覆盖：判定-条件覆盖就是设计足够的测试用例，使得判断中每个条件的所有 可能取值至少执行一次，同时每个判断的所有可能判断结果至少执行，即要求各个判断的 所有可能的条件取值组合至少执行一次。 5.条件组合覆盖：在白盒测试法中，选择足够的测试用例，使所有判定中各条件判断结果 的所有组合至少出现一次，满足这种覆盖标准成为条件组合覆盖。 6.路径覆盖：是每条可能执行到的路径至少执行一次。 补充： （1）语句覆盖在所有的测试方法中是一种最弱的覆盖。 （2）判定覆盖和条件覆盖比语句覆盖强，满足判定/条件覆盖标准的测试用例一定也满足 判定覆盖、条件覆盖和语句覆盖 （3）路径覆盖也是一种比较强的覆盖，但未必考虑判定条件结果的组合，并不能代替条 件覆盖和条件组合覆盖。 ``` </details> <br /> <details> <summary>19. Beta测试和Alpha测试有什么区别？</summary> ``` 大型通用软件，在正式发布前，通常需要执行 Alpha 和 Beta 测试，目的是从实际终端用 户的使用角度，对软件的功能和性能进行测试，以发现可能只有最终用户才能发现的错 误。 Alpha 测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实 际操作环境下进行的受控测试，Alpha 测试不能由程序员或测试员完成。Alpha 测试发现 的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。目的是评 价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。 Alpha 测试可以从软件产品编码结束之后开始，或在模块（子系统）测试完成后开始， 也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册（草 稿）等应该在 Alpha 测试前准备好。 Beta 测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通 常不在测试现场，Beta测试不能由程序员或测试员完成。因而，Beta 测试是在开发者无 法控制的环境下进行的软件现场应用。在 Beta 测试中，由用户记下遇到的所有问题，包 括真实的以及主管认定的，定期向开发者报告，开发者在综合用户的报告后，做出修 改，最后将软件产品交付给全体用户使用。Beta 测试着重于产品的支持性，包括文档、 客户培训和支持产品的生产能力。只有当 Alpha 测试达到一定的可靠程度后，才能开始 Beta 测试。由于Beta 测试的主要目标是测试可支持性，所以Beta测试应该尽可能由主持 产品发行的人员来管理。 ``` </details> <br /> ## **五、测试流程** <details> <summary>20. 软件测试的基本流程有哪些？</summary> ``` 需求分析、编写测试用例、评审测试用例、搭建环境、等待程序开发包、部署程序开发包、 冒烟测试、执行具体的测试用例细节、Bug 跟踪处理回归测试、N 轮之后满足需求，测试结束。 ``` </details> <br /> <details> <summary>21. 测试结束的标准是什么？</summary> ``` 第一类标准：测试超过了预定时间，则停止测试。 第二类标准：执行了所有的测试用例，但并没有发现故障，则停止测试。 第三类标准：使用特定的测试用例设计方案作为判断测试停止的基础。 第四类标准：正面指出停止测试的具体要求，即停止测试的标准可定义为查出某一预订 数目的故障。 第五类标准：根据单位时间内查出故障的数量决定是否停止测试。 ``` </details> <br /> <details> <summary>22.软件测试的原则是什么？</summary> ``` 1) 应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。 2) 测试用例应由测试输入数据和对应的预期输出结果这两部分组成。 3) 程序员应避免检查自己的程序。 4) 在设计测试用例时，应包括合理的输入条件和不合理的输入条件。 5) 软件测试的原则 6) 充分注意测试中的群集现象。 经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。 7) 严格执行测试计划，排除测试的随意性。 8) 应当对每一个测试结果做全面检查。 9) 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。 ``` </details> <br /> ## **六、用例设计** <details> <summary>23. 什么是测试用例，测试用例的基本要素？</summary> ``` 测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试 某个程序路径或核实是否满足某个特定需求。 测试用例的基本元素： 测试索引，测试环境，测试输入，测试操作，预期结果，评价标 准。 ``` </details> <br /> <details> <summary>24.描述测试用例设计的完整过程？</summary> ``` 首先根据需求文档、概要设计、测试计划、测试方案细分出各功能模块的测试项； 再根据各测试项，按照概要设计、详细设计以及测试方案中测试的覆盖率细分出测试子 项； 最后按照测试子项、根据测试用例的设计方法（因果图、边界值、等价类等的设计方 法）书写测试用例。 注意： 选用适合的用例管理工具（如 word，excel）； l 用例一定要及时更新（补充新的想法，删除过时的需求）； 做好用例分级； 做好用例评审，写用例之前可以征询相关人员的意见，如果评审通过可以参考其执行测 试，如果未通过，需要继续修改直到通过为止。 可以考虑结对编写，这个是不错的主意； 要全面，包括功能、性能、兼容性、安全性、易用性、容错性等等； 注意把握适当的颗粒度。 ``` </details> <br /> <details> <summary>25.好的测试用例有哪些特点？</summary> ``` 质量属性： 正确性：确保测试标题描述部分的内容正确性。 经济性：只为确定需要的目的设计相应的测试步骤。 可重复性：自我一致性，即不管谁执行此用例，结果一样。 适应性：既能适应短期需要，又能考虑长远需要。 可追踪性：用例能追踪到一个具体的需求。 自我清理性：单个用例不会影响整个测试环境，即用例执行完了可以恢复原有的测试环境。 结构化和可测试性 含有规范的测试标题和编号。 含有一个确定的测试某一个特定需求的目的。 含有关于测试方法的描述。 指定条件信息\-环境、数据、预置的条件测试、安全入口等。 含有操作步骤和预期结果。 陈述任何辅助证据，例如截图报告并确保这些东西妥善保存。 确保测试环境的干净（即用例不会影响整个环境）。 描述时使用主动语气结构。 操作步骤不要超过 15 步。 确保单个用例测试执行时用时不超过 20 分钟。 自动化脚本用例添加必要的注释，比如目的、输入和期望结果。 如果可能，建议提供可选择性的预置条件测试。 用例之间的先后顺序是否跟业务流程一致，即用例在业务流程中的彼此顺序关系是否合理。 配置管理： 采用命名和编号规范归档。 保存为特定的格式，文件类型。 用例版本是否与当前被测试软件版本一致（对应）。 包含用例需要的相应测试对象，如特定数据库。 存档阅读。 存档时按角色控制访问方式 当网络备份时存档。 离线归档。 ``` </details> <br /> <details> <summary>26.写测试用例时要注意什么问题</summary> ``` 1、复用率：如果随着产品不停得升级，需要设计的详细些，追求一劳永逸；仅使用一两次，则 没有必要设计的过于详细； 2、项目进展：项目时间如果允许可以设计的详细些，反之则能执行即可； 3、使用对象：测试用例如果供多人使用，尤其让后参加测试的工程师来执行，则需要设计的详细些。 4、用例的冗余 5、操作步骤要细分简明，可执行。 ``` </details> <br /> <details> <summary>27.如何在有限的情况下提高测试效率，保证产品的上线质量？</summary> ``` 1、一个详细合理的详细的测试计划 2、测试尽早的介入项目，连接项目的业务需求，做好测试的前期准备 3、对测试项目前景充满信心，调整最佳心态，保持愉悦的工作心情 4、提高测试接受的标准，减少测试版本的送测次数 ``` </details> <br /> <details> <summary>28.如何降低漏测率</summary> ``` 1、需求评审 2、梳理需求，尽早与开发人员、需求人员进行需求确认，统一不同角色对需求的认识 3、用例设计及评审 4、测试执行 5、bug 回归 6、发布前的功能回归 ``` </details> <br /> <details> <summary>29.测试用例的基本设计方法</summary> ``` 1、等价类划分法 (有效等价类:对于程序规格说明来说，是合理的，有意义的输入数据构成的集合) (无效等价类:对于程序规格说明来说，是不合理的，无意义的输入数据构成的集合) 2、边界值分析法 3、错误推断法 4、因果图判定表法 5、正交实验法 6、流程法 7、场景法 ``` </details> <br /> <details> <summary>30.测试为什么要写测试用例</summary> ``` 1、深入了解需求的过程 2、测试执行的指导 3、规划测试数据的准备 4、反应测试进度 5、举一反三发现隐藏缺陷 6、分析缺陷标准 ``` </details> <br /> ## **七、缺陷 bug** <details> <summary>31.什么是缺陷报告，缺陷报告的作用，缺陷报告的要点</summary> ``` （1）缺陷报告是描述软件缺陷现象和重现步骤的集合。软件缺陷报告 Software Bug Report(SBR)或软件问题报告 software Problem Report(SPR)。 （2）缺陷报告是软件测试人员的工作成果之一，体现软件测试的价值缺陷报告可以把软 件存在的缺陷准确的描述出来，便于开发人员修正缺陷报告可以反映项目/产品当前的质 量状态，便于项目整体进度和质量控制软件测试缺陷报告是软件测试的输出成果之一， 可以衡量测试人员的工作能力。 （3）标题(Title)简洁、准确、完整、反映缺陷本质、方便查询前缀+标题正文，标题正文 采用结果和动作，或者现象和位置的方式表达；步骤(Steps)可复现、完整、简洁、准确 按数字编号；实际结果(Actual results)准确、详细描述软件的现象和特征；期望结果 (Expected results)准确、丰富、有理有据；平台(Platforms)准确；截图(Sereenshots)准 确反映缺陷特征；注释(Notes)关于缺陷的辅助说明。 ``` </details> <br /> <details> <summary>32.软件测试缺陷报告的 5C 原则</summary> ``` Correct（准确）：每个组成部分的描述准确，不会引起误解； Clear（清晰）：每个组成部分的描述清晰，易于理解； Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容； Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息； Consistent（一致）：按照一致的格式书写全部缺陷报告。 ``` </details> <br /> <details> <summary>34.缺陷描述（报告单）中应该包括哪些内容？</summary> ``` 缺陷的标题，简要描述。缺陷的类型。缺陷的详细步骤描述。缺陷的实际结果。期望结 果。有的缺陷需要上传截图，日志信息。缺陷的等级。缺陷指派给开发同事。（开发主 管） ``` </details> <br /> <details> <summary>35.如何提高缺陷的记录质量？</summary> ``` 通用 UI 要统一、准确；尽量使用业界惯用的表达术语和表达方法；使用业界惯用的表达 术语和表达方法，保证表达准确，体现专业化；每条缺陷报告只包括一个缺陷；不可重 现的缺陷也要报告；明确指明缺陷类型；明确指明缺陷严重等级和优先等级；描述 (Description) ，简洁、准确，完整，揭示缺陷实质，记录缺陷或缺陷出现的位置；短行 之间使用自动数字序号，使用相同的字体、字号、行间距； 每一个步骤尽量只记录一个 操作；确认步骤完整，准确，简短；根据缺陷，可选择是否进行图象捕捉； 检查拼写和 语法缺陷；尽量使用短语和短句，避免复杂句型句式；缺陷描述内容。 ``` </details> <br /> <details> <summary>36.如果一个缺陷被提交后，开发人员认为不是问题，怎么处理？</summary> ``` a)首先，将问题提交到缺陷管理库里面进行备案。 b)然后，要获取判断的依据和标准： v.根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据； vi.如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷； vii.根据用户的一般使用习惯，来确认是否是缺陷； viii.与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷； c)合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不掺杂个人情 绪。 d)等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道， 向上级反映，并有上级做出决定。 ``` </details> <br /> <details> <summary>37.缺陷的优先级划分和描述</summary> ``` 一般来说按照下面的来分，具体的是由每个公司而定。 软件缺陷有四种级别，分别为：致命的(Fatal)，严重的(Critical)，一般的(Major)，微小 的(Minor)。 A 类—致命的软件缺陷(Fatal):造成系统或应用程序崩溃、死机、系统挂起，或造成数据 丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。如代码错误，死循 环，数据库发生死锁、与数据库连接错误或数据通讯错误，未考虑异常操作，功能错误 等。 B 类—严重错误的软件缺陷（critical）：系统的主要功能部分丧失、数据不能保存，系 统的次要功能完全丧失。 问题局限在本模块，导致模块功能失效或异常退出。如致命的 错误声明，程序接口错误，数据库的表、业务规则、缺省值未加完整性等约束条件。 C 类—一般错误的软件缺陷（major）：次要功能没有完全实现但不影响使用。如提示信 息不太准确，或用户界面差，操作时间长，模块功能部分失效等，打印内容、格式错 误，删除操作未给出提示，数据库表中有过多的空字段。 D 类—较小错误的软件缺陷（Minor）:使操作者不方便或遇到麻烦，但它不影响功能过 的操作和执行，如错别字、界面不规范（字体大小不统一，文字排列不整齐，可输入区 域和只读区域没有明显的区分标志），辅助说明描述不清。 E 类- 建议问题的软件缺陷（Enhancemental）：由问题提出人对测试对象的改进意见或 测试人员提出的建议、质疑。 ``` </details> <br /> ## **八、测试实例** <details> <summary>38.一个有广告的纸杯子，请设计测试用例？</summary> 测试项目：杯子 ``` 需求测试：查看杯子使用说明书 界面测试：查看杯子外观 功能度：用水杯装水看漏不漏；水能不能被喝到 安全性：杯子有没有毒或细菌 可靠性：杯子从不同高度落下的损坏程度 可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用 兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等 易用性：杯子是否烫手、是否有防滑措施、是否方便饮用 用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述 疲劳测试：将杯子盛上水（案例一）放 24 小时检查泄漏时间和情况；盛上汽油（案例二）放 24 小时检查泄漏 时间和情况等 压力测试：用根针并在针上面不断加重量，看压强多大时会穿透 跌落测试: 杯子加包装(有填充物),在多高的情况摔下不破损 震动测试: 杯子加包装(有填充物),六面震动,检查产品是否能应对恶劣的铁路\公路\航空运输 基本功能测试（逻辑功能测试）。 （1）硬度：是否达到设计标准。 装载能力：在杯子内分别装入少量的、半杯的、满杯的，看其装载量是否达到设计标准。 装载种类：开水（是否产生异味）、温水、冷水、冰水、咖啡... （2）界面测试（UI 测试）。 看其形状、大小设计是否适合人方便拿起。 外观是否吸引人（广告嘛），赏心悦目。 带广告的图案沾水受是否掉色、模糊。 （3）易用性测试。 看其形状、大小设计是否适合人方便拿起。 残疾人士用此杯去喝水的容程度。 杯子设计是否上大下小，在运输过程中可以套在一起有效利用空间，在使用时也容易拿开。 （4）稳定性测试（24 X 7 测试）。装入液体后记录其多少以后漏水。 （5）安全性测试。杯子所用的材料（包括纸基、涂层和广告颜料）是否符合食品卫生标准，在 内外温度等环境因素下是否会与所盛各种饮料相反应，而产生对人体有害的物质。 （6）本地化测试。为国际化和本地化的需要，广告图案和文字是否在政治、宗教和文化方面具 有广泛的适用性。 （7）对设计的改进建议。“如果是一次性杯子，能否标示已使用（比如变色）”和“杯子是否有使 用者标贴（多人使用时防止混淆）”。 ``` </details> <br /> <details> <summary>39.一个身份证号码输入框，怎么设计用例？</summary> ``` 校验身份证号规则的有效性（包括地址码、生日期码、顺序码和校验码 校验 15 位身份证号和 18 位身份正好都是可用的 校验末位是 X 的情况 校验不足 15 位、16-17 位和大于 18 位的情况 如果是必输项，校验不输入的时候会不会有正确的提示 如果不是必输项，则要校验不输入的时候流程能否正常进行 校验输入非数字的情况，是否会有正确提示信息（包括大小写字母、汉字、特殊字符和标点符号） 校验输入全角的数字的时候，系统是否会识别（这个得根据需求确定是否可以使用全角的数字） ``` </details> <br /> <details> <summary>40.登录功能怎么设计测试用例？</summary> ``` 具体需求： 有一个登录页面，有一个账号和一个密码输入框, 一个提交按钮。 此题的考察目的： 1、了解需求（测什么都是从了解需求开始）； 2、是否有设计 Test Case 的能力 3、是否熟悉各种测试方法； 4、是否有丰富的 Web 测试经验； 5、是否了解 Web 开发； 了解需求： 1、登录界面应该是弹出窗口式的，还是直接在网页里面； 2、账号长度和密码的强度（比如需要多少位、大小写敏感、特殊字符混搭等）； 3、界面美观是否有特殊要求？（即是否要进行 UI 测试）； 4、···· 用例设计： 测试需求分析完成后，开始用例设计，主要可以从以下几个方面考虑： 功能测试(Function Test) 1、输入正确的账号和密码，点击提交按钮，验证是否能正确登录。（正常输入） 2、输入错误的账号或者密码, 验证登录会失败，并且提示相应的错误信息。（错误校验） 3、登录成功后能否跳转到正确的页面（低） 4、账号和密码，如果太短或者太长，应该怎么处理（安全性，密码太短时是否有提示） 5、账号和密码，中有特殊字符（比如空格），和其他非英文的情况（是否做了过滤） 6、记住账号的功能 7、登录失败后，不能记录密码的功能 8、账号和密码前后有空格的处理 9、密码是否加密显示（星号圆点等） 10、牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），刷新或换一个按钮是否好用 11、登录页面中的注册、忘记密码，登出用另一帐号登录等链接是否正确 12、输入密码的时候，大写键盘开启的时候要有提示信息。 13、什么都不输入，点击提交按钮，看提示信息。（非空检查） 界面测试(UI Test) 1、布局是否合理，2 个 Testbox 和一个按钮是否对齐 2、Testbox 和按钮的长度，高度是否符合要求 3、界面的设计风格是否与 UI 的设计风格统一 4、界面中的文字简洁易懂，没有错别字。 性能测试(Performance Test) 1、打开登录页面，需要几秒 2 、输入正确的账号和密码后，登录成功跳转到新页面，不超过 5 秒 安全性测试(Security Test) 1、登录成功后生成的 Cookie 是否有 HttpOnly(降低脚本盗取风险) 2、账号和密码是否通过加密的方式，发送给 Web 服务器 3、账号和密码的验证，应该是用服务器端验证，而不能单单是在客户端用 javaScript 验证 4、账号和密码的输入框，应该屏蔽 SQL 注入攻击 5、账号和密码的输入框，应该禁止输入脚本（防止 XSS 攻击） 6、错误登录的次数限制（防止暴力破解） 7、考虑是否支持多用户在同一机器上登录； 8、考虑一用户在多台机器上登录 可用性测试(Usability Test) 1、是否可以全用键盘操作，是否有快捷键 2、输入账号，密码后按回车，是否可以登录 3、输入框是否可以以 Tab 键切换 兼容性测试（Compatibility Test） 1、主流的浏览器下能否显示正常已经功能正常（IE6~11, FireFox, Chrome, Safari 等 ） 2、不同的平台是否能正常工作，比如 Windows, Mac 3、移动设备上是否正常工作，比如 iPhone, Android 4、不同的分辨率 本地化测试 （Localization Test） 1、不同语言环境下，页面的显示是否正确。 软件辅助性测试 （Accessibility Test） 软件辅助功能测试是指测试软件是否向残疾用户提供足够的辅助功能 1、高对比度下能否显示正常（视力不好的人使用） ``` </details> <br /> <details> <summary>41.移动端和 web 端测试有什么区别</summary> ``` 单纯从功能测试的层面上来讲的话，APP 测试、web 测试 在流程和功能测试上是没有区别的。 根据两者载体不一样，则区别如下： 系统结构方面 web 项目，b/s 架构，基于浏览器的；web 测试只要更新了服务器端，客户端就会同步会更新。 app 项目，c/s 结构的，必须要有客户端；app 修改了服务端，则客户端用户所有核心版本都需要进行回归 测试一遍。 性能方面 web 项目 需监测 响应时间、CPU、Memory app 项目 除了监测 响应时间、CPU、Memory 外，还需监测 流量、电量等 兼容方面 （1）web 项目： 1. 浏览器（火狐、谷歌、IE 等） 2. 操作系统（Windows7、Windows10、Linux 等） （2）app 项目： 1. 设备系统:iOS（ipad、iphone）、Android（三星、华为、联想等） 、Windows（Win7、Win8）、 OSX（Mac） 2. 手机设备可根据 手机型号、分辨率不同 相对于 Wed 项目，APP 有专项测试 1. 干扰测试：中断，来电，短信，关机，重启等 2. 弱网络测试（模拟 2g、3g、4g，wifi 网络状态以及丢包情况）；网络切换测试（网络断开后重连、3g 切 换到 4g/wifi 等） 3. 安装、更新、卸载 安装：需考虑安装时的中断、弱网、安装后删除安装文件等情况 卸载：需考虑 卸载后是否删除 app 相关的文件 更新：分强制更新、非强制更新、增量包更新、断点续传、弱网状态下更新 4. 界面操作：关于手机端测试，需注意手势，横竖屏切换，多点触控，前后台切换 5. 安全测试：安装包是否可反编译代码、安装包是否签名、权限设置，例如访问通讯录等 6. 边界测试：可用存储空间少、没有 SD 卡/双 SD 卡、飞行模式、系统时间有误、第三方依赖（QQ、微信 登录）等 7. 权限测试：设置某个 App 是否可以获取该权限，例如是否可访问通讯录、相册、照相机等 测试工具方面 自动化工具：APP 一般使用 Appium; Web 一般使用 Selenium 性能测试工具：APP 一般使用 JMeter; Web 一般使用 LR、JMeter ``` </details> <br /> <details> <summary>42.测试一个 C/S 客户端时，需要考虑的因素 </summary> ``` 客户端安装测试 客户端升级测试 客户端可维护性测试 （1）个体的客户端应用以“分离的”模式被测试——不考虑服务器和底层 网络的运行； （2）客户端软件和关联的服务器端应用被一起测试，但网络运行不被明 显的考虑； （3）完整的 C/S 体系结构，包括网络运行和性能被测试。 应用功能测试——客户端应用被独立地执行，以揭示在其运行中的错误。 服务器测试——测试服务器的协调和数据管理功能，也考虑服务器性能 （整体反映时间和数据吞吐量）。 数据库测试——测试服务器存储的数据的精确性和完整性，检查客户端应 用提交的事务，以保证数据被正确地 存储、更新和检索。 事务测试——创建一系列的测试以保证每类事务被按照需求处理。测试着 重于处理的正确性，也关注性能问题。 网络通信测试——这些测试验证网络节点间的通信正常地发生，并且消息 传递、事务和相关的网络交通无错的 发生。 ``` </details> <br /> <details> <summary>43.测试电梯，请详细描述 </summary> **如果给你一台电梯，请问你如何测试它，分析如下：** ``` 1.功能：上升、下降、停止、开门、关门、梯内电话、灯光、指示灯等； 2.性能：速度、反应时间、关门时间等； 3.压力：超载、尖锐物碰撞电梯壁等； 4.安全：停电、报警装置、轿箱停靠位置、有人扒门时的情况等； 5.可用性：按键高度、操作是否方便、舒适程度等； 6.UI：美观程度、光滑程度、形状、质感等； 7.稳定性：长时间运行情况等； 8.兼容性：不同电压是否可工作、不同类型电话是否可安装等。其实在简单分析的过程中，发现许多东西根本测试不全，比如电话、灯光、材质、调度程序、可维修性等，当发现在一个用例中无法说清楚时，这些应该拆分开来分别测试。可以告诉主考官，你需要模块化地测试电话、灯光等。再有在一起的组装测试。 下面是详细的测试点： 需求测试：查看电梯使用说明书、安全说明书等 界面测试：查看电梯外观 功能测试： 1. 测试电梯能否实现正常的上升和下降功能。 2. 电梯的按钮是否都可以使用。 3. 电梯门的打开，关闭是否正常。 4. 报警装置是否可用。 5. 与其他电梯之间是否协作良好。 6. 通风状况如何。 7. 突然停电时的情况。 8. 上升途中的响应。 1）电梯本来在 1 楼，如果有人按 18 楼，那么电梯在上升到 5 楼的时候，有人按了 10 楼，这时候是否会 在 10 楼先停下来 2）电梯下降到 10 层时显示满员，此时若 8 层有人等待电梯，是否在 8 层停。 9. 是否有手机信号 可靠性测试： 1. 门关上的一刹那出现障碍物。 2. 同时按关门和开门按钮。 3. 点击当前楼层号码 4. 多次点击同一楼层号码 5. 同时按上键和下键 易用性：电梯的按钮的设计符合一般人的习惯吗 用户文档：使用手册是否对电梯的用法、限制、使用条件等有详细的描述 压力测试：1.看电梯的最大承重量，在负载过重时报警装置是否有提醒 稳定性测试：看垫底在最大负载下平行运行的最长时间 ``` </details> <br /> <details> <summary>44.对一只圆珠笔进行测试</summary> ``` 1.界面测试，无论我们做那类软件（嵌入式别提），只要给用户有看到的东西，从测试的角度，就要考虑 界面测试，这个呢，现在针对微软的产品，某公司开发了一套界面检查表，我这里有一份，想要可以找 我。 界面测试测什么，怎么测呢？针对这个问题我是这样回答的，印刷在产品上的图片，文字，这可能涉及不 同的东西，有圆珠笔厂家的信息，也有针对不同用户的信息（譬如小孩子喜欢颜色搭配多一点的，而成人 用稳重的产品等），可能涉及的还有人的审美观，你圆珠笔色彩搭配之类的 2. 功能测试，这是我们测试的重点，也是客户针对某家公司产品给出满意度的参考点，圆珠笔功能主要是 书写， 这里面涉及一个功用方面的焦点——书写的快慢程度，也就是流利不流利的问题（这涉及笔芯的材 质问题） 针对这方面的测试，个人认为应从以下几点 ： a.材质问题，这涉及程序员和用户之间的关系，两者利益均有，程序员考虑成本问题，用户考虑污染问 题，也 就是说制作圆珠笔的材料与环境的问题，厂商考虑价格因素，用户考虑环境因素以及安全性因素 这就把安全性测试给说出来了，大的方面因为笔油材质的问题，和使用者之间的健康问题有联系， 要测小 的方面，笔油的速率，以及书写后是否马上可以涂抹，可否修改，这都涉及安全性的问题 b. 性能问题，温度，湿度，气压对笔芯产生不同的影响 3. 安全性问题 测试不同的高度，笔身做自由落体损坏程度 4. 兼容性问题 不同的笔筒和笔芯之间的互相兼容 5. 强度测试 弹簧在不同的压力之下，承受变形的程度 6. 在金山面试时候，考官特意问我针对笔芯那个米珠如何测试 或者 1、界面测试 界面测试也就是对其外表先进行判断。 尺寸是否适合用户使用？用户需要的是什么样的尺寸，小孩和成年人使用的尺寸是有区别的； 色彩搭配是否合理？形状是否美观？ 是否方便携带和存放？ 笔芯颜色是否与客户要求一致？ 笔身印的 logo 或者文字是否这么正确 2、功能测试 笔筒开合； 笔芯替换； 出墨快慢； 笔头出墨粗细； 是不是可操作性签字笔； 3、性能测试 笔芯的寿命； 笔墨的气味； 写过的字用纸水浸透后，笔墨是否会晕开 压力测试：笔尖在多大压力范围内可以正常写字，不能正常出墨，太重损坏笔尖或纸张； 笔壳能在多大压力范围内正常使用？成人用力太重掰断笔壳，掉到地上易摔， 能在纸上写出清晰的字 4、性能测试 握笔的地方纹路是否会硌手或太滑； 书写的流畅度； 写出的墨水多久能干； 高温和低温环境对笔芯出墨和笔壳的影响； 长时间不盖笔套，或笔盖盖多长时间不用，会不会对笔下次写字有影响 5、安全测试 笔墨是否有易燃性； 笔墨是否对皮肤有害； 笔杆折断，材质是否容易刮伤手； 误食笔芯是否会引起中毒（有小孩或者有人喜欢咬笔头） 6、兼容性测试 笔壳和笔芯是否能够很好的适应主流签字笔尺寸； 这个笔芯的笔尖如果损坏，换上其他的笔芯的笔尖是否能用； 这个笔芯的笔墨如果用完，换上其他笔芯的笔墨是否可以使用； 笔的笔墨如果在其他笔的笔墨上写字是否可以成功覆盖 7、其他测试 （1）比较测试 与其他品牌签字笔比较，优劣在哪些地方？ （2）场景测试 笔从高处摔到地上，笔尖是否会摔坏； 倒着写，是否可以写出很多字来； 扔到水里，笔墨会不会一直晕开； 笔在粗糙的纸上是否能写出字… ``` </details> <br /> <details> <summary>45.测试一个网上购物的购物车 </summary> ``` 界面测试： ·打开页面后，页面的布局是否合理，显示是否完整； ·鼠标浮动在购物车按钮，迷你购物车界面显示是否正常； ·不同卖家的商品在不同的 table 区域显示，区分明显； ·页面的 tooltips 能正常显示； 功能测试： ·所有页面链接功能正常，可以点击到正确页面； ·页面关联本地软件阿里旺旺的 icon 点击后，能打开软件； ·从商品信息页面添加的商品能显示在购物车中； ·购物车页面打开的同时，在其他页面添加了商品，购物车页面刷新后，新的商品能显示； ·若未登录，点击购物车，则提示用户输入用户名和密码，或者提示其他的非注册用户购物方式； ·商品未勾选的状态下，结算按钮是灰色无法点击的； ·勾选商品后，已选商品的总价会显示，结算按钮变高亮可点击工作； ·勾选商品，点击结算按钮后，进入确认订单信息页面； ·购物车页面中，可以对添加的商品信息做信息的修改，并自动保存成功； ·卖家在线的时候，旺旺 icon 高亮，反之，灰色； ·购物车有商品降价或者库存告急的，那么点击对应的 tab，降价或者告急商品会归类后显示； ·购物车能添加的商品种类是有数量上限的； ·不要的商品，可以删除； （其他特有的功能不做赘述，只讨论常见通用功能） 若商品已经失效，购物车的商品是否可以继续结算 已进入支付界面但支付未成功，重新进入购物车，又重新添加了一些物品，则原有的物品是否能正确保留； （感觉这个还挺关键，经常是没完成支付，又添加了一些物品，最后再一起支付） 性能测试： ·打开购物车页面要多久； 可用性测试： ·快捷键功能知否支持 兼容测试： ·不同浏览器上的测试功能是否正常； ·app 上测试 ``` </details> <br /> <details> <summary>46.请以微信点赞，功能点进行测试 </summary> ``` 1. 功能测试 考虑功能是否符合预期 2. 接口 考虑各内部和外部的接口，比如朋友圈客户端和服务端的交互接口的功能。朋友圈点赞功能和消息提示功 能的 接口（点了赞之后对应的朋友收到提示信息） 3. 平台 手机版 pad 版 web 版 4. 用户操作场景 测试用户常用场景，比如：用户打开微信看到十条消息提示，点击后进入朋友圈界面显示了“谁谁谁点了赞” 5. 速度、延迟 6. 性能测试 模拟一些多用户并发操作的场景 7. 安全 ``` </details> <br /> <details> <summary>47.搜索框怎么测</summary> 增： 搜索功能分为简单搜索和高级搜索 简单搜索： 先展示百度的简单搜索界面，仅供参考：  ``` 界面测试 ·搜索框 UI 显示正常，布局合理； ·搜索页面布局合理，无错别字； ·搜索出的结果展示，布局合理； ·已查看过的结果链接，链接的眼神要灰化处理，和没有点击过的结果链接区分； ·结果数量庞大时，页面的分页布局合理； 功能测试 ·链接测试：页面上的链接都可连接至正确的页面 ·搜索历史内容记录，便于查找检索过的内容 ·搜索内容联想输入，便于用户搜索的便捷与准确性 ·搜索功能测试（重点） ·搜索内容为空，验证系统如何处理 ·搜索内容为空格，查看系统如何处理 ·边界值验证，在允许的字符串范围内外，验证系统的处理 ·超长字符串的输入，系统是否会截取允许的长度来检索结果 ·合法的字符串长度后，加空格，验证检索结果 ·多个关键词中间加入空格，tab，逗号后，验证系统的结果是否正确 ·验证每种合法的输入，结果是否正确 ·是否支持检索内容的复制、粘贴、编辑等操作 ·是否支持回车键搜索 ·多次输入相同的内容，查看系统每次检索的结果是否正确，相同 ·特殊字符，转义符，html 脚本等需作处理 ·敏感词汇，提示用户无权限等信息 ·输入的内容，是否支持快捷键操作等 ·只能输入允许的字符串长度 安全性测试（没有做过，只能列出一些简单的注意点） ·脚本的禁用 ·SQl 注入，检索 sql select 语句等 ·敏感内容的检索是禁止的 ·特殊字符的检索 ·被删除、加密、授权的数据，不允许被查出来的，是否有安全控制设计 兼容性测试 ·多平台 windows，mac ·移动平台 ios，android ·多浏览器 FF，Chrome，IE，国内主流浏览器等 性能测试 ·搜索页面打开的速度是否满足设计要求 ·搜索出结果消耗的时间，是否满足设计要求 本地化测试 ·登录时，自动切换至相应语言国家的搜索主页 高级搜索： 先展示百度的高级搜索页面，仅供参考： ```  场景法测试，主要是为了验证搜索结果的正确性：  每个场景，对应了一种高级搜索活动从开始到退出搜索的完整过程 </details> <br />