一、面试基础题
简述测试流程:
1、阅读相关技术文档（如产品PRD、UI设计、产品流程图等）。
2、参加需求评审会议。
3、根据最终确定的需求文档编写测试计划。
4、编写测试用例（等价类划分法、边界值分析法等）。
5、用例评审(主要参与人员：开发、测试、产品、测试leader)。
6、开发提交代码至SVN或者GIT ，配管搭建测试环境。
7、执行测试用例，记录发现的问题。
8、验证bug与回归测试。
9、编写测试报告。
10、产品上线。
补充测试用例设计过程：
根据需求得出测试需求
设计测试方案，评审测试方案
方案评审通过后，设计测试用例，再对测试用例进行评审
什么是软件测试？软件测试的目的与原则
使用人工或自动手段，来运行或测试某个系统的过程。其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
软件测试的目的：
测试是程序的执行过程，目的在于发现错误。
一个成功的测试用例在于发现至今未发现的错误。
一个成功的测试是发现了至今未发现的错误的测试。
确保产品完成了它所承诺或公布的功能，并且用户可以访问到的功能都有明确的书面说明。
确保产品满足性能和效率的要求。
确保产品是健壮的和适应用户环境的。
问：软件生存周期及其模型是什么？
软件生存周期是软件开发全部过程、活动和任务的结构框架，是从可行性研究到需求分析、软件设计、编码、测试、软件发布维护的过程。在经历需求、分析、设计、实现、部署后，软件将被使用并进入维护阶段，直到最后由于缺少维护费用而逐渐消亡。这样的一个过程，称为”生命周期模型”（Life Cycle Model）。
什么是软件质量？
软件质量：软件产品的特性可以满足用户的功能、性能需求的能力。
自动化测试脚本开发的主要步骤:
1、通过某些方式定位到我们要执行的对象、目标( Target)
2、对这个对象进行什么操作(command)
3、通过操作对定位到的元素赋值(value)
4、添加断言操作
目前主要的测试用例设计方法是什么？
白盒测试：逻辑覆盖、循环覆盖、基本路径覆盖
黑盒测试：边界值分析法、等价类划分、错误猜测法、因果图法、状态图法、测试大纲法、随机测试场景法
常见的测试用例设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用
1）等价类划分划分
等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试。因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据。取得较好的测试结果。等价类划分可有两种不同的情况:有效等价类和无效等价类。
2）边界值分析法
边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设（面试题目：什么样的工作环境适合你&#from一个常见的软件测试面试题来自end#lt；结束）计测试用例，可以查出更多的错误。
使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。
3）错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。
错误推测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。例如，在单元测试时曾列出的许多在模块中常见的错误。以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。
4）因果图方法
前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系，相互组合等。考虑输入条件之间的相互组合，可能会产生一些新的情况。但要检查输入条件的组合不是一件容易的事情，即使把所有输入条件划分成等价类，他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图(逻辑模型)。因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。
5）正交表分析法
有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。
6）场景分析方法
指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。
测试的策略有哪些?
黑盒/白盒/灰盒，静态/动态，手工/自动，冒烟测试，回归测试，公测（Beta测试的策略）
补充：公测是什么?还有没有其他的测试策略？测试策略和测试方法以及测试类型有什么区别？
按测试 策略分类：
1、静态与动态测试
2、黑盒与白盒测试
3、手工和自动测试
4、冒烟测试
5、回归测试；
按测试阶段分类：单元测试、集成测试、系统测试；
其他常见测试方法：1、功能测试 2、性能测试 3、压力测试 4、负载测试 5、易用性测试 6、安装测试 7、界面测试 8、配置测试 9、文档测试 10、兼容性测试 11、安全性测12、恢复测试
α测试是由一个用户在开发环境下进行的测试本地连接没有有效的ip地址，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha 测试不能由程序员或测试员完成。
β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta 测试不能由程序员或测试员完成。
回归测试（对软件的新版本测试时，重复执行上一个版本测试时的用例，是为了验证缺陷是否真正修复，确认修复后是否影响其它功能）；
冒烟测试：对新版本测试之前，先验证下软件的基本功能是否实现，是否具备可测性。
单元测试的策略有哪些？
逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析
正交表测试用例设计方法的特点是什么？
答：用最少的实验覆盖最多的操作，测试用例设计很少，效率高，但是很复杂；对于基本的验证功能，以及二次集成引起的缺陷，一般都能找出来；但是更深的缺陷，更复杂的缺陷，还是无能为力的；具体的环境下，正交表一般都很难做的。大多数，只在系统测试的时候使用此方法。
补充：什么时候用系统测试，测试的每个阶段是什么，比如单元、集成、系统、公测，每个阶段需要什么技术，有什么要求
软件的安全性应从哪几个方面去测试？
(1) 用户认证机制：如数据证书、智能卡、双重认证、安全电子交易协议
(2) 加密机制
(3) 安全防护策略：如安全日志、入侵检测、隔离防护、漏洞扫描
(4) 数据备份与恢复手段：存储设备、存储优化、存储保护、存储管理
(5) 防病毒系统
软件安全性测试包括程序、数据库安全性测试。根据系统安全指标不同测试策略也不同。
用户认证安全的测试要考虑问题：
明确区分系统中不同用户权限
系统中会不会出现用户冲突
系统会不会因用户的权限的改变造成混乱
用户登陆密码是否是可见、可复制
是否可以通过绝对途径登陆系统（拷贝用户登陆后的链接直接进入系统）
用户退出系统后是否删除了所有鉴权标记，是否可以使用后退键而不通过输入口令进入系统
系统网络安全的测试要考虑问题
测试采取的防护措施是否正确装配好，有关系统的补丁是否打上
模拟非授权攻击，看防护系统是否坚固
采用成熟的网络漏洞检查工具检查系统相关漏洞（即用最专业的黑客攻击工具攻击试一下，现在最常用的是 NBSI 系列和 IPhacker IP ）
采用各种木马检查工具检查系统木马情况
采用各种防外挂工具检查系统各组程序的外挂漏洞
数据库安全考虑问题：
系统数据是否机密（比如对银行系统，这一点就特别重要，一般的网站就没有太高要求）系统数据的完整性（我刚刚结束的企业实名核查服务系统中就曾存在数据的不完整，对于这个系统的功能实现有了障碍）
系统数据可管理性
系统数据的独立性
系统数据可备份和恢复能力（数据备份是否完整，可否恢复，恢复是否可以完整）
α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha 测试不能由程序员或测试员完成。
β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta 测试不能由程序员或测试员完成。
需求测试的注意事项有哪些？
是否使用了公司的模板
文档内容是否符合规范
所有的需求是分级是否清析适当？
所有的需求是否具有一致性
需求是否可行（即，该需求组合有解决方案）
需求可否用己知的约束来实现
需求是否足够（即，可以把它送到一个规范的开发组织，并有一个生产出所需要产品的合理的可能性）
所有的其它需求是交叉引用是否正确
用户描述是否清楚
是否用客户的语言来描述需求
每个需求描述是否清楚没有岐义，可以移交给一个独立的组去实现时也能理解
是否所有的需求都是可验证的
是否每条需求都具有独立性，即使发生了变化也不会影响其它需求
性能指标是否明确
非功能性需求是否得到充分表现
是否完整列出适用的标准或协议
标准和协议之间是否存在冲突
问：你在测试中发现了一个 bug ，但是开发经理认为这不是一个 bug ，你应该怎样解决。
将问题提交到缺陷管理库里面进行备案。
要获取判断的依据和标准：根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；根据用户的一般使用习惯，来确认是否是缺陷；
与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；
合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。
等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。
问：给你一个网站，你如何测试？
1、查找需求说明、网站设计 m 等相关文档，分析测试需求。
2、制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：
功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试
3、设计测试用例：
功能性测试可以包括，但不限于以下几个方面：
链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回等。提交功能的测试。
多媒体元素是否可以正确加载和显示。多语言支持是否能够正确显示选择的语言等。
界面测试可以包括但不限于一下几个方面：
页面是否风格统一，美观
文字检查
对于必须但为安装的空间，是否提供自动下载并安装的功能
控件是否正常使用
页面布局是否合理，重点内容和热点内容是否突出
问：一台客户端有三百个客户与三百个客户端有三百个客户对服务器施压，有什么区别?
300 个用户在一个客户端上，会占用客户机更多的资源，而影响测试的结果。线程之间可能发生干扰，而产生一些异常。300 个用户在一个客户端上，需要更大的带宽。IP 地址的问题，可能需要使用 IP Spoof 来绕过服务器对于单一 IP 地址最大连接数的限制。所有用户在一个客户端上，不必考虑分布式管理的问题；而用户分布在不同的客户端上，需要考虑使用控制器来整体调配不同客户机上的用户。同时，还需要给予相应的权限配置和防火墙设置。
你工作中遇到最具价值的bug，就是重大bug咯，例如app性能测试测哪些，那你就看一看性能测试的视频咯
软件的安全性应从哪几个方面 去测试？
软件安全性测试包括程序、数据库安全性测试。根据系统安全指标不同测试策略也不同。
用户认证安全的测试要考虑问题：
明确区分系统中不同用户权限
系统中会不会出现用户冲突
系统会不会因用户的权限的改变造成混乱
用户登陆密码是否是可见、可复制
是否可以通过绝对途径登陆系统（拷贝用户登陆后的链接直接进入系统）
用户退出系统后是否删除了所有鉴权标记，是否可以使用后退键而不通过输入口令进入系统
系统网络安全的测试要考虑问题
测试采取的防护措施是否正确装配好，有关系统的补丁是否打上
模拟非授权攻击，看防护系统是否坚固
采用成熟的网络漏洞检查工具检查系统相关漏洞（即用最专业的黑客攻击工具攻击试一下，
现在最常用的是 NBSI 系列和 IPhacker IP ）
采用各种木马检查工具检查系统木马情况
采用各种防外挂工具检查系统各组程序的外挂漏洞
数据库安全考虑问题：
系统数据是否机密（比如对银行系统，这一点就特别重要，一般的网站就没有太高要求）
系统数据的完整性（我刚刚结束的企业实名核查服务系统中就曾存在数据的不完整，对于这个系统的功能实现有了障碍）
系统数据可管理性
系统数据的独立性
系统数据可备份和恢复能力（数据备份是否完整，可否恢复，恢复是否可以完整）
软件质量保证体系是什么 国家标准中与质量保证管理相关的几个标准是什么? ? 他们的编号和全称是什么? ?
SQA 由一套软件工程过程和方法组成，以保证（软件的）质量。SQA 贯穿整个软件开发过程，(它)应包括需求文档评审、代码控制、代码评审、变更管理、配置管理、版本管理和软件测试。
测试人员在软件开发过程中的任务是什么？
1、寻找 Bug；
2、避免软件开发过程中的缺陷；
3、衡量软件的品质；
4、关注用户的需求。
总的目标是：确保软件的质量。
在您以往的工作中，一条软件缺陷（或者叫 Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？
一条 Bug 记录最基本应包含：编号、Bug 所属模块、Bug 描述、Bug 级别、发现日期、发现人、修改日期、修改人、修改方法、回归结果等等；
要有效的发现 Bug 需参考需求以及详细设计等前期文档设计出高效的测试用例，然后严格执行测试用例，对发现的问题要充分确认
肯定，然后再向外发布如此才能提高提交 Bug 的质量。
黑盒测试和白盒测试是软件测试的两种基本方法，请分别说明各自的优点和缺点！
黑盒测试的优点有：比较简单，不需要了解程序内部的代码及实现；与软件的内部实现无关；从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题；基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；在做软件自动化测试时较为方便。
黑盒测试的缺点有：不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的 30%；自动化测试的复用性较低。
白盒测试的优点有：帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。
白盒测试的缺点有：程序运行会有很多不同的路径，不可能测试所有的运行路径；测试基于代码，只能测试开发人员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求；系统庞大时，测试开销会非常大。
什么是系统瓶颈？
参考答案：
瓶颈主要是指整个软硬件构成的软件系统某一方面或者几个方面能力不能满足用户的特定业务要求，“特定”是指瓶颈会在某些条件下会出现，因为毕竟大多数系统在投入前。
严格的从技术角度讲，所有的系统都会有瓶颈，因为大多数系统的资源配置不是协调的，例如CPU使用率刚好达到100％时，内存也正好耗尽的系统不是很多见。因此我们讨论系统瓶颈要从应用的角度讨论：关键是看系统能否满足用户需求。在用户极限使用系统的情况下，系统的响应仍然正常，我们可以认为改系统没有瓶颈或者瓶颈不会影响用户工作。
因此我们测试系统瓶颈主要是实现下面两个目的：
-发现“表面”的瓶颈。主要是模拟用户的操作，找出用户极限使用系统时的瓶颈，然后解决瓶颈，这是性能测试的基本目标。
-发现潜在的瓶颈并解决，保证系统的长期稳定性。主要是考虑用户在将来扩展系统或者业务发生变化时，系统能够适应变化。满足用户目前需求的系统不是最好的，我们设计系统的目标是在保证系统整个软件生命周期能够不断适应用户的变化，或者通过简单扩展系统就可以适应新的变化。
手机APP测试
：主要包括功能、性能测试、稳定性、兼容性、用户测试。
性能测试：CPU占用/内存占用 /耗电测试 /流量消耗测试 /安装包大小 /加载时间测试 /核心功能相应时间 (①启动时间检测：检测App在终端上首次启动时间。②内存、CPU耗用检测：检测App在终端上运行时不同时段占用内存、CPU情况。③流量耗用检测：检测App在终端上运行时的网络流量消耗情况。④电池温度检测：检测App在终端上运行时，对终端的电池温度等性能指标的影响情况 )
兼容性测试：屏幕分辨率 /网络状态，状态切换 /android版本 /安装卸载升级等 /权限设置 /与其他APP兼容性 (①安装卸载测试：测试App在指定终端上是否可正常安装、正常卸载，准确定位错误原因。②遍历测试：自动识别App可执行的功能，在一定时间内遍历App的不同功能界面，通过截图记录操作路径 并输出日志、定位异常现象。③运行稳定性测试：类似Monkey的随机性压力测试，测试App运行期的稳定性。④UI适配测试：测试App的UI与目标终端的屏幕是否适配，记录是否存在渲染失败、错位、黑边框、黑白屏等现象。)
稳定性测试包括：服务器异常时稳定性 /外部事件影响（电话，短信等） /内存是否有溢出或者泄漏 /多线程问题 。
什么是并发？在lordrunner中，如何进行并发的测试？集合点失败了会怎么样？
参考答案：
在同一时间点，支持多个不同的操作。
LoadRunner中提供IP伪装，集合点，配合虚拟用户的设计，以及在多台电脑上设置，可以比较好的模拟真实的并发。
集合点，即是多个用户在某个时刻，某个特定的环境下同时进行虚拟用户的操作的。集合点失败，则集合点的才操作就会取消，测试就不能进行。
详细的描述一个测试活动完整的过程。
答案：（供参考，本答案主要是瀑布模型的做法）
项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后 SQA 进入项目，开始进行统计和跟踪开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。测试用例完成后，测试和开发需要进行评审。测试人员搭建环境开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现 BUG后提交给 BugZilla。开发提交第二个版本，包括 Bug Fix 以及增加了部分功能，测试人员进行测试。重复上面的工作，一般是 3-4 个版本后 BUG 数量减少，达到出货的要求。如果有客户反馈的问题，需要测试人员协助重现并重新测试。
在您以往的工作中，一条软件缺陷（或者叫 Bug ）记录都包含了哪些内容？如何提交高质量的软件缺陷（ Bug ）记录？
在传统的 BugZilla 中，BUG 描述应该包括以下的信息和 BUG 产生对应的软件版本和模块开发的接口人员BUG 的优先级BUG 的严重程度BUG 可能属于的模块，如果不能确认，可以用开发人员来判断BUG 标题，需要清晰的描述现象BUG 描述，需要尽量给出重新 Bug 的步骤BUG 附件中能给出相关的日志和截图。高质量的 BUG 记录就是指很容易理解的 BUG 记录，所以，对于描述的要求高，能提供的信息多且准确，很好的帮助开发人员定位，因此提交高质量的软件缺陷记录需要注意对 BUG 记录的描述质量多且准确。
您认为在测试人员同开发人员的沟通过程中，如何提高沟通的效率和改善沟通的效果？维持测试人员同开发团队中其他成员 良好的人际关系的关键是什么？
尽量面对面的沟通，其次是能直接通过电话沟通，如果只能通过 Email 等非及时沟通工具的话，强调必须对特性的理解深刻以及能表达清楚。运用一些测试管理工具如 TestDirector 进行管理也是较有效的方法，同时要注意在TestDirector 中对 BUG 有准确的描述。在团队中建立测试人员与开发人员良好沟通中注意以下几点：一真诚二是团队精神三是在专业上有共同语言四是要对事不对人，工作至上当然也可以通过直接指出一些小问题，而不是进入 BUG Tracking System 来增加对方的好感。
软件测试项目从什么时候开始？为什么？
软件测试应该在需求分析阶段就介入,因为测试的对象不仅仅是程序编码,应该对软件开发过程中产生的所有产品都测试,并且软件缺陷存在放大趋势.缺陷发现的越晚,修复它所花费的成本就越大.
测试结束的标准是什么？
从微观上来说，在测试计划中定义，比如系统在一定性能下平稳运行 72 小时，目前 BugTracking System 中，本版本中没有一般严重的 BUG，普通 BUG 的数量在 3 以下，BUG 修复率 90%以上等等参数，然后由开发经理，测试经理，项目经理共同签字认同版本 Release。如果说宏观的，则是当这个软件彻底的消失以后，测试就结束了。
您是否了解以往所工作的企业的软件开发过程？如果了解，请试述一个完整的开发过程需要完成哪些工作？分别由哪些不同的角色来完成这些工作？您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？
开发过程—需求调研（需求人员）、需求分析（需求人员）、概要设计（设计人员）、详细设计(设计人员)、编码（开发人员）测试过程—需求评审、系统测试设计、概要设计评审、集成测试设计、详细设计评审、单元测试设计、测试执行测试工作的整个过程都做过，擅长做测试设计过程决定质量，软件的过程改进正是为了提高软件的质量，将过往的种种经验和教训积累起来。
补充
1.明确测试的目标，增强测试计划的实用性编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确
2．采用评审和更新机制，保证测试计划满足实际需求
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。分别创建测试计划与测试详细规格、测试用例,应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。
请你回答一下性能测试有哪些指标，对一个登录功能做性能测试，有哪些指标，怎么测出可同时处理的最大请求数量
参考回答：
性能测试常用指标：
从外部看，主要有
1、吞吐量：每秒钟系统能够处理的请求数，任务数
2、响应时间：服务处理一个请求或一个任务的耗时
3、错误率：一批请求中结果出错的请求所占比例
从服务器的角度看，性能测试关注CPU，内存，服务器负载，网络，磁盘ＩＯ
对登录功能做性能测试
单用户登陆的响应界面是否符合预期
单用户登陆时后台请求数量是否过多
高并发场景下用户登录的响应界面是否符合预期
高并发场景下服务端的监控指标是否符合预期
高集合点并发场景下是否存在资源死锁和不合理的资源等待
长时间大量用户连续登录和登出本地连接没有有效的ip地址，服务器端是否存在内存泄漏
怎么测出可同时处理的最大请求数量
可以采用性能测试工具(WeTest服务器性能)，该工具是腾讯wetest团队出品，使用起来很简单方便，但测试功能相当强大，能提供10w+以上的并发量，定位性能拐点，测出服务器模型最大并发
什么是兼容型测试？兼容性测试侧重哪些方面？
兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行，即是通常说的软件的可移植性。兼容的类型，如果细分的话，有平台的兼容，网络兼容，数据库兼容，以及数据格式的兼容。兼容测试的重点是，对兼容环境的分析。通常，是在运行软件的环境不是很确定的情况下，才需要做兼容。根据软件运行的需要，或者根据需求文档，一般能够得出用户会在什么环境下使用该软件，把这些环境整理成表单，就得出做兼容测试的兼容环境了
兼容和配置测试的区别在于，做配置测试通常不是在Clean OS下做测试，而兼容测试多是在Clean OS环境下做的。
补充：做兼容测试的具体步骤：在列好的软硬件环境清单做冒烟测试，还是每一步都测试。测出不兼容，怎么和开发沟通，开发面对这些不兼容需要做什么。如果修复成本很高，怎么和产品经理沟通。和谁确认表单
软件测试项目从什么时候开始，？为什么？
软件测试应该在需求分析阶段就介入,因为测试的对象不仅仅是程序编码,应该对软件开发
过程中产生的所有产品都测试,并且软件缺陷存在放大趋势.缺陷发现的越晚,修复它所花费的成本就越大.
二、测试实战面试题
我现在有个程序，发现在Windows上运行的很慢，怎么判别是程序存在问题还是软硬件系统存在问题
1、检查系统是否有中毒的特征
2、检查软件/硬件的配置是否符合软件的推荐标准
3、确认当前的系统是否独立，即没有对外提供什么消耗CPU资源的服务
4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成
5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况
补充：每一步该怎么实现，需要用到什么技术
一个程序有n个变量采用边界值分析可以产生几个测试用例
4n+1
请设计一个关于ATM自动取款机的测试用例。
1）功能
a)ATM所识别卡的类型；
b)密码验证(身份登陆、是否为掩码、输入错误密码时是否提示，连续三次错误吞卡等)；
c)取款功能：
i、金额多少的限制，单次最大最小提取金额、每天最大提取金额等）；
Ii、取款币种的不同，如人民币、美元、欧元等。
d)是否提示客户操作完成后，打印相关操作信息；
e)查询功能是否正常；
f)转账功能是否正常；
g)是否提示客户操作完成后，取回客户卡；
2）性能
a)是否有自动吞卡：非法客户密码错误客户规定时间内未完成相关操作功能的客户。（如果有，有无报警功能(保密报警)）
b)平均无故障时间，平均故障修复时间，输入密码后验证时间，出钞票时间，查询余额等待时间。
3）易用性
a)ATM各个操作功能(硬件)是否正常、易懂；
b)ATM的界面显示是否友好；
c)ATM是否支持英文操作；
d)ATM是否存在异常（断电、黑客入侵）有自动保护（报警）功能；
如何测试一个 纸杯？
功能度：用水杯装水看漏不漏；水能不能被喝到
安全性：杯子有没有毒或细菌
可靠性：杯子从不同高度落下的损坏程度
可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用
兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等
易用性：杯子是否烫手、是否有防滑措施、是否方便饮用
用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述
疲劳测试：将杯子盛上水（案例一）放 24 小时检查泄漏时间和情况；盛上汽油（案例二）
放 24 小时检查泄漏时间和情况等
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透
我手上这支笔，请你根据这支笔设计测试用例
首先我要测它的外观、颜色是否符合要求、所占的空间是多大、是否环保、接下来测它的质量、这支笔是否能够写字流畅、写出的自得颜色是否符合要求、能使用多长时间等
测试手机开机键
功能测试：按下开机键，屏幕能否亮起
性能测试：按下开机键，屏幕能否在规定时间内亮起
压力测试：连续多次按下开机键，观察屏幕是否能一直亮起，到多久时间失灵
健壮性测试：给定一个中了病毒的手机或者是淘汰许久的老机子，安歇开机键观察屏幕能否亮起
可靠性测试：连续按下开机键有限次数，比如1万次，记录屏幕未亮起的次数
可用性测试：开机键按下费不费力，开机键的形状设计是否贴合手指，开机键的位置设计是否方便
如何回答登录功能怎么进行测试？
首先，进行界面测试。
查看界面上的所有元素是否齐全；
没有输入内容时，是否有相应的提示语；
验证码是否能够显示；
移动鼠标，【登陆】按钮默认不能点击；
【忘记密码】是否有个小问号“？”（其他都有）；
第二，进行功能测试。
输入正确的用户名、密码、验证码，点【登陆】能登陆；
输入正确的用户名、错误的密码、正确的验证码，提示用户名或密码错误；
输入错误的用户名、正确的验证码，提示用户名或密码错误；
输入正确的用户名、密码，错误的验证码，提示验证码错误；
输入不符合规则的手机号或者邮箱应该提示错误；
页面长时间不登陆和操作，验证码会不会过期；
点【记住密码】，登录后退出，再次登陆是不是可以不输入密码；
点【忘记密码】能够跳转到密码设置页面（至于是什么不用管，就是能不能跳转）
只点击验证码图案，验证码能不能刷新；
页面刷新，验证码图案能不能刷新；
输入栏是否设置快速删除按钮；
用户名和密码是否大小写敏感；
用户名和密码前后有空格的处理；
登陆成功，是否有记住密码功能；
登陆失败后，不能记录密码的功能；
新用户第一次登陆成功，是否有修改密码提示；
用户登录过程中log中是否有个人信息明文打印；
是否支持第三方登陆；
刷新页面时是否会刷新验证码；
输入密码的时候，大写键盘开启的时候要有提示信息 ；
不同级别的用户，比如管理员用户和普通用户，登录系统后的权限是否正确；
第三、业务安全测试。
有没有登陆错误次数的限制；
每次登陆错误之后有没有限制再次登陆的时间间隔；
是否支持一个账号多地登陆；
不同机型登陆，异地登陆是否有提醒 ；
不登录的情况下，在浏览器中直接输入登录后的URL地址，验证是否会重新定向到用户登录界面；
第四、兼容性测试。
在相同浏览器的不同版本上打开登录页面，效果是否一致；在不同浏览器上打开登录页面，效果是否一致；在不同操作系统的不同浏览器打开登录页面，效果是否一致；在不同的屏幕分辨率下打开登录页面，效果是否一致；
第五、代码安全性测试。
用户输入登录信息登陆时，个人信息是不是会显示在浏览器地址栏；
用户登陆的时候，通过抓包工具抓数据，密码是否加密；
查看页面源代码，验证码是否直接显示在代码中；
密码在后台储存时是否加密；
是否可以使用登录的API发送登录请求，并绕开验证码校验；
用户名和密码的输入框中分别输入典型的“SQL注入攻击”字符串，验证系统的返回页面；
用户名和密码的输入框中分别输入典型的“XSS跨站脚本攻击”字符串，验证系统行为是否被篡改；
第六、页面性能测试。
单用户登录的响应时间是否小于3秒；
通过工具向登录页发起大量请求，查看页面响应时间的变化；
通过工具对登陆功能进行并发测试；通过工具向登录页发起大量请求，查看页面何时崩溃；
通过工具向登录页发起大量请求，查看页面崩溃后有没有良好的提示信息；
通过工具向登录页发起大量请求，查看页面崩溃后多长时间能够恢复服务；
弱网，不同网速时登陆的时间，网络切换和网络延迟时登陆界面是否正常；
最后、易用性测试。
页面是否美观；
功能是否都可以使用；
页面速度快不快；
页面元素加载是否耗费网络流量；
能不能第三方登陆；
为什么不使用手机验证码登陆；
输入框能否可以以Tab键切换。
如何回答京东购物车功能怎么进行测试？
1.功能测试
a）、未登录时：
将商品加入购物车，页面跳转到登录页面，登录成功后购物车数量增加。
b）、登录后：
所有链接是否跳转正确；
商品是否可以成功加入购物车；
没有限购要求的商品，添加数量能不能超过库存数；
购物车商品总数是否有限制；
商品总数统计是否正确；
全选功能是否可用；
删除功能是否可用；
删除功能是否有提示；
价格总计是否正确；
商品文字太长时是否显示完整；
购物车中下架的商品是否有标识，是否还能支付；
新加入购物车商品排序（添加购物车中存在的店铺的商品和购物车中不存在的店铺的商品）；
是否支持快TAB、ENTER等快捷键；
商品删除后商品总数是否减少；
本文到此结束，希望对大家有所帮助！