1、B/S架构和C/S架构区别:
B/S只需要有操作系统和浏览器就行，可以实现跨平台，客户端零维护，但是个性化能力低，响应速度较慢；C/S响应速度快，安全性强，一般应用于局域网中，因为要针对不同的操作系统，需要针对性的开发，并且维护成本高
2、HTTP协议
超文本传输协议，是一种应用层协议；是万维网的数据通信的基础；最初的目的是为了提供一种发布和接收HTML页面方法。
3、POST与GET区别
①GET是不安全的，因为在传输过程，数据被放在请求的URL中；POST的所有操作对用户来说都是不可见的。
②GET传送的数据量较小，这主要是因为收URL长度限制；POST传送的数据量较大，一般被默认为不受限制
③GET限制Form表单的数据集的值必须为ASCLL字符；而且POST支持整个 ISO10646字符集
④GET执行效率却比POST方法好。GET是Form提交的默认方法
4、Cookie和Session的区别与联系
区别：①cookie存放在客户端的浏览器上，session放在服务器端上
②cookie相对来说不安全，可通过存放在本地的cookie进行cookie欺骗
③session会暂时存放在服务器端上，当访问量增多时，会占用服务器性能
联系：①session是通过cookie来工作的
②session和cookie之间是通过$_COOKIE[‘PHPSESSID‘]来联系的，通过$_COOKIE[‘PHPSESSID‘]可以知道session的 ID，从而获取到其他的信息
5、测试的目的
①软件测试是为了发现错误而执行程序的过程
②测试是为了证明程序有错，而不是证明程序无错误
③一个好的测试用例是在于它能发现至今未发现的错误
④一个成功的测试是发现了至今未发现的错误的测试
6、软件测试原则
①应当把“尽早和不断的测试”作为开发者的座右铭
②设计测试用例时，应该考虑到合法的输入和不合法的输入，以及各自边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断，电源断电等情况
③对测试错误结果一定要有一个确认的过程。一般由A测出来的错误，一定要由B来确认，严重的错误可以召开评审会进行讨论分析
④一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系
⑤制定严格的测试计划，并把测试时间安排的尽量宽松。不要希望在短时间内完成一个高水平测试
⑥回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的现象并不少见
⑦妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档
7、软件测试分为哪几个阶段？
单元测试--集成测试--系统测试--验收测试
8、单元测试与集成测试的侧重点
①单元测试是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试，测试重点是系统的模块，包括子程序的正确性验证等
②集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求，组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。测试重点是模块间的衔接以及参数的传递等
9、系统测试范围
将整个软件看作一个整体来进行册测试，包括功能、性能、兼容性
10、a测试与?测试的区别
在 B 测试中，采用的细节、数据和方法完全由各测试员决定：测试员负责创建环境，选择数据，并决定要研究的功能、特性或任务；测试员负责确定自己对于系统当前状态的接收标准。
B 测试由最终用户实施，通常开发组织对其很少或不进行管理。
11、验收测试怎么做？
验收测试是部署软件之前的最后一个测试操作。在软件产品完成了单元测试、集成测试和系统测试之后，产品发布之前所进行的软件测试活动。它是技术测试的最后一个阶段，也成为交付测试。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
验收测试是向未来的用户表名系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，既软件的功能和性能如同用户所合理期待的那样。
12、白盒、黑盒和灰盒测试区别
①白盒测试是通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句发现内部代码在算法，溢出，路径，条件等中的缺点或者错误，进而加以修正
②黑盒测试是通过使用整个软件或某种软件功能来严格地测试，而并没有通过检查程序的源代码或者很清楚地了解该软件或某种软件功能的源代码程序具体是怎样设计的。测试人员通过输入他们的数据然后看输出的结果从而了解软件怎样工作。通常测试人员在进行测试时，不仅使用肯定出正确结果的输入数据，而且还会使用有挑战性的输入数据以及可能结果会出错的输入数据以便了解软件怎样处理各种类型的数据
③灰盒测试就像黑盒测试一样是通过用户界面测试，但是测试人员已经有所了解该软件或某种软件功能的源代码程序具体是怎样设计的。甚至于还读过部分源代码。因此测试人员可以有的放矢地进行某种确定地条件/功能地测试。这样做地意义在于：如果你知道产品内部的设计和对产品有透过用户界面的深入了解，你就能够更有效和深入地从用户界面来测试它的各项性能。
13、冒烟测试的目的
为正式测试前，验证是否产品或系统的主要需求或预置条件是否存在 BUG
14、回归测试怎么做？
①重点测试软件中被修改的部分
②从原基础测试用例库中，排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的基线测试用例库
③依据一定的策略从测试用例库中选择测试用例测试被修改的软件
④如果必要，生成新的测试用例集，用于测试无法充分测试到的软件部分
⑤用新软件测试用例集执行修改后的软件
15、全部回归与部分回归的区别？
16、需求分析的目的
①把用户需求转化为功能需求：(1)对测试范围进度量 (2)对处理分支进行度量 (3)对需求业务的场景进行度量 (4)明确其功能对应的输入、处理和输出 (5)把隐式需求转变为明确
②明确测试活动的五个要素：测试需求是什么、决定怎么测试、明确测试时间、确定测试人员、确定测试环境；测试中需要的技能，工具以及相应的背景知识，测试过程中可能遇到的风险等。测试需求需要做到尽可能地详细明确，以避免测试遗漏和误解
17、测试计划的目的
编写软件测试计划的目的是指导测试组成员进行工作和让测试组以外的项目成员了解测试工作的
18、什么时候开始写测试计划
有了详细地产品需求说明书后，在系统设计阶段就应该写系统测试方案，系统测试计划并开始详细设计测试用例了。
19、由谁来编写测试计划
测试人员根据需求文档进行编写测试计划
20、测试计划的内容
简介、参考文档和提交文件、进度安排、测试资源、严重程度和优先级、风险分析、测试策略
21、结束条件(项目上线的条件)
第一类标准：测试超过了预定时间，则停止测试。
第二类标准：执行了所有的测试用例，但并没有发现故障，则停止测试。
第三类标准：使用特定的测试用例设计方案作为判断测试停止的基础
第四类标准：正面指出停止测试的具体要求，即停止测试的标准可定义为查出某一预订数目的故障。
第五类标准：根据单位时间内查出故障的数量决定是否停止测试。
22、常见的测试风险
①需求风险：产品需求的不明确，对产品需求理解不准确，导致测试范围存在误差，遗漏部分需求或者执行了错误的测试方式；另外需求变更导致测试用例变更，测试用例维护成本增加，实时更新时存在误差。
②测试用例风险：测试用例设计不完整，忽视了边界条件、异常输入等情况，用例覆盖率没有做到足够覆盖，测试用例没有得到全部执行，有些用例被有意或者无意的漏测，需求变更导致的测试时间被压缩等情况。
③缺陷风险：某些缺陷偶发，难以重现，容易被遗漏；缺陷跟踪不够积极主动，没做好缺陷记录和及时更新，同样的缺陷，导致的原因可能不同，对这点没意识到导致的线上生产问题等。
④代码质量风险：代码质量差，可读性差，重构性差，没做好注释等原因导致缺陷较多，修改难度增大；另外还有系统架构设计的不足，导致的扩展性不足，性能兼容差等问题。
⑤测试环境风险：测试环境和生产环境配置不同，测试环境交叉影响较大，测试环境数据量不足导致的测试结果误差等问题。
⑥测试技术风险：某些项目存在技术难度，测试能力和经验所限，技术水平相对较差导致测试进展缓慢，测试结果准确性不够，项目发布日期延期等问题。
⑦回归测试风险：回归测试，一般时间相对来说较少，且大多只回归主要的功能点用例，可能造成漏测；另外还有回归验证缺陷时业务流走不通导致的打回修复再验证造成的时间延后问题。
⑧沟通协调风险：项目进行过程中需要多方沟通协调，不同部门，岗位之间的沟通、协作，难免存在误解、沟通不畅的情况，比如需求变更没有及时沟通，开发代码提交没有及时告知，测试结果的反馈不及时等问题。
⑨研发流程风险：其中包括从产品需求评审、研发设计、代码提交、测试发布等一些列流程，流程的不规范不协调很可能导致很多问题；比如开发在不告知其他成员的情况下提交代码，发布没有预生产环境，生产出现
问题无法及时回滚等很多说烂了的情况。流程没必要一板一眼的执行，但没有流程是万万不行的。
⑩其它不可预计风险：一些突发状况、不可抗力等也构成风险因素，且难以预估和避免。对于这种情况，往往一时无法解决，建议做好备份方案和容灾机制，或者采用灰度发布等措施。
23、测试用例的要素
测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是
否满足某个特定需求
测试用例的基本元素： 测试索引，测试环境，测试输入，测试操作，预期结果，评价标准
-
测试用例编号
字符和数字组合成的字符串，用例编号应具有唯一性、易识别
系统测试
产品编号-ST-系统测试项名-系统测试子项名-XXX
集成测试
产品编号-IT-集成测试项名-集成测试子项名-XXX
单元测试
产品编号-UT-单元测试项名-单元测试子项名-XXX
-
测试项目
当前测试用例所在测试大类、被测试需求、被测模块、被测单元等
系统测试用例测试项目
软件需求项
集成测试用例测试项目
集成后的模块名或接口名
单元测试用例测试项目
被测函数名
-
测试标题
简单描述，需要用概括的语言描述用例的出发点和关注点，原则上每个用例的标题不能重复
4.重要级别
对基本和普通测试项的区分
高级别
保证系统基本功能、核心业务、重要特性、实际使用频率比较高的用例
中级别
重要程度介于高和低之间的测试用例
低级别
实际使用的频率不高，对系统业务功能影响不大的模块或功能的测试用例
-
预置条件
执行当前测试用例需要的前提条件，如果这些前提条件不满足，则后面测试步骤无法进行或无法得到 预期结果
6.输入
用例执行过程中需要加工的外部信息。根据软件测试用例的具体情况，有手工输入、文件、数据库记录等
7.操作步骤
执行当前测试用例需要经过的操作步骤，需要明确的给出一个步骤的描述，测试用例执行人员可以根据该步骤完成测试用例执行
8.预期输出
当前测试用例的预期输出结果，包括返回值内容，界面的响应结果，输出结果的规则符合度等
测试用例额外的要素
1.用例设计者
能准确的找到测试用例设计人员，对用例修改时能方便找准人员
2.用例设计日期
方便检查用例设计的进度
3.用例版本号
方便用例设计人员对用例的跟踪
4.对应的开发人员
出现BUG后能及时找到相应的人员进行修复
24、测试用例级别的划分
优先级一般都是和缺陷的严重程度对应的。
高（Highs）：保证功能性是稳定的，是按照需求的正常使用和实现点进行用例设计的，重要的错误和边界测试的测试用例的集合。
中（Mediums）：更全面的验证功能的各方面，包括流程中的各个节点出错情况、异常情况测试、中断、UI展示、用户体验等方面的测试用例设计
低（Lows）：不常被执行的测试用例。比如压力和性能测试用例设计，接口测试用例设计随着时间的推移已经从低级别变化到了中级别。
25、怎样保证覆盖用户需求？
①确认需求：面试官简单描述这道题后，你是否真的已经了解了他的需求呢，如上描述，需求范围过于笼统，也就是要明确用户故事。请问这个需求是怎样的项目背景或基于什么前提下而做的；会涉及到哪些支撑平台；具体需要怎样的权限可以上传操作；该功能的迭代会影响到哪些其他的存量功能等，是否有明确的性能需求等
②梳理需求，确认测试范围：是否需要考虑历史数据，数据来源，用户角色，支持哪些操作系统，兼容性要求（考虑平台兼容性、浏览器兼容性、手机型号 版本等），是否提供接口文档，DB设计文档等等
③制订测试计划：通过测试需求与测试范围，制订测试计划，我需要运用到的测试方法，工作量预估，测试资源，每个节点的测试类型，以及结束测试标准等等（可以针对此面试题来描述）测试计划需要经过项目组干系人评审通过后才可以进行下一步
④根据测试计划设计测试用例：当然，此步会根据个人习惯和经验来适当增减，如先使用思维导图理出测试想法， 然后再扩展。可以按可接受性测试用例、系统测试用例（接口、功能、性能、安全、UI、DB…）来开始设计用例。这样就可以按照所学的N+测试方法来充分设计Case了，而有了测试计划中的相关策略来指导 ，也不会疏漏其他的需求点了。
⑤后续的执行测试步骤（可以依情况来作描述）：我们暂且就此面试题展开分析 ，故不作深入探讨 。目前大多数需求分析都会将软件需求分解成一条条功能清单，然后将对应的功能点与对应的测试做一对多的映射建立，保证测试设计可以覆盖到每个最小单位的功能点。而以上一系列的测试步骤是从测试技能的角度来分析如何做测试设计可以保证到需求的覆盖率。
26、写好测试用例的关键 /写好用例要关注的维度
做好测bai试用例工作的关键是要充du分考虑测试计zhi划的实用性，坚持dao5W1H的原则zhuan，采用评审和更shu新机制以及测试策略。要充分考虑测试计划的实用性，即测试计划与实际之间的接近程度和可操作性。要坚持“5W1H”的原则，明确测试内容与过程。采用评审和更新机制，确保测试计划满足实际需求。因为软件项目是一个渐进的过程，中间不可避免地会发生需求变化，为满足需求变化，测试计划也需要及时地进行变更。测试策略要作为测试的重点进行描述。测试策略是测试计划中的重要组成部分，测试计划是从宏观上说明一个项目的测试需求、测试方法、测试人员安排等因素。
27、测试用例的状态
排队（In Queue）：测试用例已经指定给某个测试人，不准备在这一个测试阶段运行。
进行中（IP）：该测试正在进行，并且会持续一段时间。（如果一个测试所需要的时间少于一天，我就不会讲一个测试标为进行中，因为我每天会跟踪测试用例的状态）
阻塞（Block）：一些因素会导致测试不能进行到底，例如某个功能欠缺或者测试环境的某个部分欠缺。我通常会在测试用例总结工作表的意见栏记录下阻塞的状态。你可以把阻塞理解为：我希望运行测试，但是目前还不能运行测试。
跳过（Skip）：你决定在当前测试阶段跳过某个测试，可能是因为它的优先权相对较低。（同样地，我会在测试用例总结工作表的意见栏记录下我跳过这个测试的原因。）你可以把跳过理解为：我现在可以运行这个测试，但是我不想运行它。
通过（Pass）：测试运行结束，测试人得到了预料中的测试结果状态和测试行为。
失败（Fail）：在很多情况下，测试人得到预料之外的测试结果，状态或行为，这些结果与测试目标相差甚远。这就引发了关于系统质量的疑问。一个或多个测试错误需要记录下来。
警告（Warn）：在很多情况下，测试人得到预料之外的测试结果，状态或行为，但是这些结果与测试目标差别不是很大（我通常会在测试包总结工作表的通过一栏记为警告，而不是另加一栏）。另一种想法是，警告意味着当前的错误是无关紧要的，或者对正在测试的特征是没有意义的。系统报出了更多的错。我处理这个问题的一个标准是只和延期的或不是一定要改的错误相关的测试可以标记为警告，而不是失败。
关闭（Close）：一个测试在第一个循环中被标为失败或警告，第二个测试发布中将第一个测试循环出现的错误修改了。重新运行了整个测试用例后，没有错误出现。将这类测试标记为关闭而不是通过，使得你可以跟踪测试在某一个测试发布中失败的实事（同标记为警告的测试一样，我在测试包总结工作表中将标记为关闭的测试也纳入成功的范畴）。
28、常见的测试用例设计方法
等价类划分：多用于输入框：注册/登录
边界值：多和等价类划分结合使用，有边界限制的:注册的密码长度（掌握上点和离点的取值）
场景法：从基本流开始，再将基本流和备选流结合起来，可以确定用例场景
正交表：用于多个下拉框之间的组合，可以通过正交助手生成测试用例
错误推测：错误猜测法是测试经验丰富的人喜欢使用的一种测试用例设计方法。一般这种方法是基于经验和直觉推测程序中可能发送的各种错误，有针对性地设计。只能作为一种补充
因果图：因果图法比较适合输条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出
29、判定表用在哪些时候/哪些功能
用在多层条件判断组合的场景
30、什么时候用到场景法
从基本流开始，再将基本流和备选流结合起来，可以确定用例场景
31、测试环境怎么搭建的？
①向运维申请一台服务器
②安装依赖软件
拿python项目举例：安装python3、pymysql、redis等需要的工具。导入flask、pymysql、redis等需要的第三方模块
拿Java项目举例：安装JDK、tomcat、数据库等需要的工具。
③拉取代码
需要知道SVN地址或者Git地址
④修改配置文件
修改数据库、redis等配置文件的配置信息，修改成测试环境的配置信息
⑤编译、打包（python不需要编译直接可以运行，如果是Java、c、 c++需要编译）
⑥导入基础数据
建表、导入管理员账号之类的信息，即把sql在测试数据库执行一次
⑦启动程序。
32、偶然性问题的处理
33、当我们认为某个地方是bug，但开发认为不是bug，怎么处理？
①找到需求文档或者是原型图进行匹对
②尝试多种测试环境和测试方式来确认是否为 BUG
③整理 BUG 的复现步骤和出现频率
④开发坚持不认为是 BUG 的时候找项目经理，测试经理进行沟通来确认是否为 BUG
⑤将客户经理，测试人员，测试经理和项目经理进行开确认会来判断是否为 BUG
⑥测试人员需要将 BUG 整理并写入测试总结中
34、产品在上线后用户发现bug，这时测试人员应做哪些工作？
首先报告给项目经理，如果 BUG 是大问题，立马下线，减少损失，如果 BUG 是小问题，上报给开发人员，更新产品。
35、二八定理
80%的缺陷出现在20%的代码中；80%的BUG发现在20%的时间中；80%的花费在20%的错误代码上
①80%的工程活动是由20%的需求用掉的。
②80%的软件成本是由20%的构件用掉的。
③80%的缺陷是由20%的构件引起的。
④80%的软件废品和返工是由20的缺陷引起的。
⑤80%的资源是由20%构件用掉的。
⑥80%的工程活动是通过20%的工具完成的。
⑦80%的进展是20%的人完成的。
36、如何跟踪缺陷
一般缺陷分几个状态，新建 确认 修复 重新打开 关闭 这几个状态完成过程就代表一个缺陷跟踪的过程。
新建bug 相关人员确认bug 开发进行修复bug 然后你再次验证bug 如果该缺陷已修复，将bug关闭 如果该缺陷没有修复，将重新打开bug
①找到缺陷后，记录缺陷的各方面信息（如：日志，图片，测试步骤，是否能重复等等）
②.提交缺陷报告.
③跟踪这个缺陷，看其何时修复.
④当缺陷修复后，再对其进行测试.并对因这个缺陷而受影响的其它功能进行测试.（如果没有就不测）
⑤如果这个缺陷测试通过，关闭这个缺陷报告.如果没有通过，则再次指回修复缺陷人员，重新修复.
37、缺陷的状态
New（新的）：bug提交到缺陷库中会自动的被设置成New状态
Assigned（已指派）：当一个bug被认为New之后，将其分配开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”
Open（已打开）：开发人员开始处理bug时，他将这个bug的状态设置为“Open”，表示开发人员正在处理这个“bug”
Fixed（已修复）：当开发人员进行处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组
Rejected(被拒绝)：测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，开发组负责人就将这个bug的状态设置为“Rejected”
Postponed（延期）：有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为“Postponed”
Closed（已关闭）：测试人员经过再次测试后确认bug已经被解决，将bug的状态设置为“Closed”
Reopen（再次打开）：如经过再次测试发现bug仍然存在，测试人员将bug再次开发组，将bug的状态设置为“Reopen”
New：测试人bai员新建缺陷。du
open：开发人员打开zhi缺陷准备修改。dao
fixed：开发人员修改完zhuan毕。
reopen：回归测试不通过。shu
closed：回归测试通过。
reject：开发人员认为不是问题拒绝修改。
duplicate：提交的缺陷重复。
postpone：推迟修改。
abandon：开发人员认为不是问题或者已经提交过经过测试人员确认确实是这样，是一种特殊的closed。
38、缺陷的等级
系统崩溃、严重、一般、次要、建议
39、缺陷单应该包含这些要素
缺陷编号、缺陷标题、缺陷描述、重现步骤、严重程度、优先级、用例编号
40、测试报告的主要内容
所属产品 所属模块 当前指派 重现步骤 严重程度 bug类型 操作系统 优先级 附件
41、如何定位bug：
首先我们要去定位发现这个 BUG 的来源是属于前端还是后端，我们可以使用 fidder 进行抓包分析，在访问数据的是否抓取请求数据，比对请求数据是否正确，在服务器响应时我们可以抓取响应数据，并比对信息查看响应数据是否正确，如果是请求数据错误，那么该 BUG 属于前端的错误，如果是响应数据错误，那么该 BUG 属于后端（数据库）的错误，如果请求数据和响应数据都没有问题，那么就可以考虑是不是浏览器的解析出现的问题，我们就可以换一个浏览器再次进行测试一下。
42、开发没时间修复，如何推进bug的修复：
1、 针对路径较深的bug，测试在推动开发修复bug时，需要注意以下几点
a) 从用户的角度分析问题的严重性，分析用户的遇到此问题的概率，引导开发站在用户角度去思考，从而使开发意识到问题的严重性
b) 可以和开发人员列举一个之前的类似问题，为开发提供参考
c) 产品是负责这个软件的人员，当测试与开发意见无法达成一致时，不要因为无法推动开发修改而放弃，一定要找产品确认，最终的决定权交给产品人员。
2、 上线时间紧张，开发来不及修改了，这个时候测试应该分析问题的严重性，和产品人员商议是否需要修改
3、 修改bug改动较大，影响范围广，没有最优的解决方案等情况在项目即将上线的节点比较忌讳这种事情的发生。面对这种情况，建议开发人员做调研工作，请教其他的同事，或者组织一个临时会议，集众人之力研究好的修改方案
4、 第三方应用问题，开发无法修改。确认原因之后需要找相关的工作人员，例如产品，联系第三方输入法的工作人员，反馈问题，尽量推动应用解决问题
43、软件测试流程
我们一般在项目进行开立项会的时候进行参与，讨论需求并提出建议，在立项会中指定需求文档，由 UI 设计原型图，开发根据需求文档进行编码，我们测试会根据需求文档进行编写测试计划，根据模块的颗粒度进行划分并编写测试用例已经用例的评审，开发结束后测试对主要功能进行冒烟测试，执行测试用例，提交 BUG 开发进行修改，修改成功后关闭 BUG ，进行回归测试，在上线前进行测试总结。
44、项目介绍
45、对一支圆珠笔进行测试，要从哪些方面进行测试？
圆珠笔的颜色
圆珠笔内芯是什么材质的，是否安全
圆珠笔的外壳是什么材质的，是否安全
圆珠笔有没有保护帽或者按压
圆珠笔头书写是否顺畅
圆珠笔出水量是否正常
一只壳子能放多少只内芯
保护帽是否会容易脱落
用多大力气书写
写下的字能保存多长时间
圆珠笔握笔处有没有摩擦花纹
用力过大是否会损坏圆珠笔
当笔尖离开纸面时，内芯的油会不会拉丝
在什么样的纸面上书写会顺畅
当保护帽被儿童误食时，有没有小孔会防止儿童窒息
当用完没有将保护帽盖上时，多长时间笔会不能写
里面的内芯用完时，是否可以更换来减少浪费污染
当壳子坏掉时，里面的内芯是否可以直接拿来书写
内芯的油能写多少个字
是否会出现漏油现象
圆珠笔的长度有多长，是否合适
圆珠笔笔尖的直接是多少
圆珠笔的笔尖是什么材质的
圆珠笔的笔尖脱落是否还能正常书写
当圆珠笔不小心划到衣服上是否容易清洗
该圆珠笔高考是否可以使用
46、三角形测试用例设计：
我们可以设三角形的3条边分别为A，B，C。如果它们能够构成三角形的3条边，必须满足： (1)A>0，B>0，C>0，且A+B>C，B+C>A，A+C>B; (2)如果是等腰的，还要判断A=B，或B=C，或A=C。 (3)如果是等边的，则需判断是否A=B=C;
47、在项目中发现哪些经典bug？什么原因导致的？
原来在一个做客户端的公司，用户反映装了我们的软件之后电脑不能操作。后来大神远程定位问题发现：他电脑上ctrl键按下去弹不起来了
48、一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由。
49、在需求文档不太详细的情况下，如何开展测试？
①解决用户问题或达到用户目标需要具备的条件或能力
②遵守合同、协议、规范或其他要求
50、如何尽快找到软件中的bug?
①尽快熟悉软件的需求和业务，只有熟悉了产品的业务流程，才能迅速找出软件中存在的一些重要的缺陷
②把自己当成用户，把自己当成是用户去使用该系统，比如在使用该系统过程中是这样操作的码？
③善于怀疑，不要相信开发人员的能力
④不要相信程序开发人员的观点：“用户不会进行这样的操作”而说服自己
⑤使用完整的流程去测试软件系统，有些子流程在单独测试时没有问题，但按流程走的时候问题可能就出来了
51、什么是bug？
①产品说明书中规定要实现的功能，软件中没有实现
②代码行的错误
③软件很难理解，很难使用，速度超慢，测试人员站在最终用户的角度看到的问题是平常的但不是正确的。
④软件逻辑错误，导致无法操作
52、ATM机吞卡的吞卡现象是不是BUG?
不是；是特意设置的安全措施，防止有人马虎，操作后忘记取走银行卡而被人冒领卡中的钱，所以特意设置了倒计时，限时内没有取走银行卡就会吞卡。
53、如何减少非问题单的提交？
熟悉项目需求，充分了解各个各个功能模块的功能、参数、约束条件，弄清存在数据交互的模块之间的数据来源、数据流向；跟产品确认该问题是否属于非问题单。
54、有个程序，在windows上运行很慢，怎么判断是程序存在问题，还是软硬件系统存在问题？
①检查系统是否有中度的特征，如：浏览器窗口连续打开，系统中文图标改成统一图标，CPU 使用率保存 90% 以上等
②检查软件/硬件的配置是否符合软件的推荐标准
③确认当前的系统是否是独立，既没有对外提供什么消耗 CPU 资源的服务，如：虚拟机运行
④如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的
⑤在系统没有任何负载的情况下，查看性能监视器，确认应用程序对 CPU/内存的访问情况
性能监视器打开方法：1、开始->运行->输入perfmon->回车 2、右键->计算机->管理
55、你们发现bug会怎么处理。
一般测试人员首先发现 BUG，然后提交 BUG，开发人员确认是否是 BUG，如果不是就拒绝修复，如果是就修复 BUG，测试人员再对修复的 BUG 进行验证，如果确实修复了就关闭 BUG，如果 BUG 还存在就reopen
测试第二个月：基本问答
原文：https://www.cnblogs.com/han0911/p/14204616.html
