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