此文转载自在 https://blog.csdn.net/weixin_30363263/article/details/80110247，其基础上做了一些调整去重。
一、你在测试中发现了一个 bug ，但是开发经理认为这不是一个 bug ，你应该怎样解决。
1、将问题提交到缺陷管理库里面进行备案。
2、要获取判断的依据和标准：
根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；
如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
根据用户的一般使用习惯，来确认是否是缺陷；
3、与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；
4、合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。
等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。
二、如果给你一个网站，你如何测试？
1、查找需求说明、网站设计 m 等相关文档，分析测试需求。
2、制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：
功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试
3、设计测试用例：
功能性测试可以包括，但不限于以下几个方面：
链接测试，链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回等；
多媒体元素是否可以正确加载和显示；
多语言支持是否能够正确显示选择的语言等。
界面测试可以包括但不限于以下几个方面：
页面是否风格统一，美观；
页面布局是否合理，重点内容和热点内容是否突出；
控件是否正常使用；
对于必须但为安装的空间，是否提供自动下载并安装的功能；
文字检查。
性能测试一般从以下三个方面考虑：
压力测试；负载测试；强度测试。
数据库测试要具体决定是否需要开展。
数据库一般需要考虑连接性，对数据的存取操作，数据内容的验证等方面。
安全性测试：
基本的登录功能的检查；
是否存在溢出错误，导致系统崩溃或者权限泄露；
关于开发语言的常见安全性问题检查，例如 SQL 注入；
如果需要高级的安全性测试，确定获得专业安全公司的帮助，外包测试，或者获取支持兼容性测试，根据需求说明的内容，确定支持的平台组合；
兼容性测试：
浏览器的兼容性；操作系统的兼容性；软件平台的兼容性；数据库的兼容性。
4、开展测试，并记录缺陷。
合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）。定期评审，对测试进行评估和总结，调整测试的内容。
三、软件生存周期及其模型是什么？
软件生存周期是软件开发全部过程、活动和任务的结构框架，是从可行性研究到需求分析、软件设计、编码、测试、软件发布维护的过程。
在经历需求、分析、设计、实现、部署后，软件将被使用并进入维护阶段，直到最后由于缺少维护费用而逐渐消亡。这样的一个过程，称为"生命周期模型"（Life Cycle Model）。
四、什么是软件测试？软件测试的目的与原则?
软件测试是使用人工或自动手段，来运行或测试某个系统的过程。其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
软件测试的目的：
在于发现错误，一个成功的测试用例在于发现至今未发现的错误，一个成功的测试是发现了至今未发现的错误的测试。
确保产品完成了它所承诺或公布的功能，并且用户可以访问到的功能都有明确的书面说明；
确保产品满足性能和效率的要求；
确保产品是健壮的和适应用户环境的。
软件测试的原则：
软件测试应尽早执行，并贯穿于整个软件生命周期；
软件测试应追溯需求；
软件测试应由第三方来构造；
穷举测试是不可能的,要遵循 Good-enough 原则；
必须确定预期输出（或结果）；
必须彻底检查每个测试结果；
充分注意测试中的群集现象；
缺陷的二八定理，即80%的错误是由20%的程序错误导致的；
严格执行测试计划，排除测试的随意性；
注意合法合理的输入，也要注意非法的非预期的输入；
测试应从“小规模”开始，逐步转向“大规模”；
反复使用同样的测试会使软件具有抵抗力；
关注缺陷的修复。
五、软件配置管理的作用？软件配置包括什么？
软件配置管理作为软件开发过程的必要环节和软件开发管理的基础，贯穿整个软件生命周期，同时对软件开发过程的宏观管理即项目管理也有重要的支持作用。一个软件开发组织真正有效的实施软件配置管理，将会使软件开发过程有更好的可预测性，使系统具有可重复性，大大提高软件组织的竞争力。
软件配置包括如下内容：
配置项识别；工作空间管理；版本控制；变更控制；状态报告；配置审计。
七、目前主要的测试用例设计方法是什么？
1、白盒测试：
逻辑覆盖；循环覆盖；基本路径覆盖。
2、黑盒测试：
边界值分析法；等价类划分；错误猜测法；因果图法；状态图法；测试大纲法；随机测试；场景法。
八、如何测试一个 纸杯？
1、功能度：用水杯装水看漏不漏；水能不能被喝到；
2、安全性：杯子有没有毒或细菌；
3、可靠性：杯子从不同高度落下的损坏程度；
4、可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用；
5、兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等；
6、易用性：杯子是否烫手、是否有防滑措施、是否方便饮用；
7、用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述；
8、疲劳测试：将杯子盛上水（案例一）放 24 小时检查泄漏时间和情况；盛上汽油（案例二）；
9、放 24 小时检查泄漏时间和情况等；
10、压力测试：用根针并在针上面不断加重量，看压强多大时会穿透。
九、测试计划工作的目的是什么？测试计划文档的内容应该包括什么？其中哪些是最重要的？
1、软件测试计划是指导测试过程的纲领性文件。
2、包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。
3、其中最重要的是测试策略和测试方法（最好是能先评审）。
十、一条软件缺陷（或者叫 Bug ）记录都包含了哪些内容？如何提交高质量的软件缺陷（ Bug ）记录？
1、传统的 BugZilla 中，BUG 描述应该包括以下的信息
和 BUG 产生对应的软件版本和模块
开发的接口人员
BUG 的优先级
BUG 的严重程度
BUG 可能属于的模块，如果不能确认，可以用开发人员来判断
BUG 标题，需要清晰的描述现象
BUG 描述，需要尽量给出重新 Bug 的步骤
BUG 附件中能给出相关的日志和截图。
预期结果和实际结果
2、高质量的 BUG 记录就是指很容易理解的 BUG 记录，所以，对于描述的要求高，能提供的信息多且准确，很好的帮助开发人员定位。
十一、请说明黑盒测试和白盒测试各自的优缺点。
1、黑盒测试的优点：
比较简单，不需要了解程序内部的代码及实现；
从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题；
基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；
在做软件自动化测试时较为方便。
2、黑盒测试的缺点：
不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的 30%；
自动化测试的复用性较低。
3、白盒测试的优点：
帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。
4、白盒测试的缺点：
程序运行会有很多不同的路径，不可能测试所有的运行路径；
测试基于代码，只能测试开发人员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求；
系统庞大时，测试开销会非常大。
十二、软件测试分为几个阶段？各个阶段的测试策略和要求是什么？
1、按阶段划分为单元测试、集成测试、系统测试和验收测试。
2、各阶段测试策略：
单元测试：
自顶向下的单元测试策略：比孤立单元测试的成本高很多，不是单元测试的一个好的选择。
自底向上的单元测试策略：比较合理的单元测试策略，但测试周期较长。
孤立单元测试策略：最好的单元测试策略。
集成测试：
大爆炸集成：适应于一个维护型项目或被测试系统较小
自顶向下集成：适应于产品控制结构比较清晰和稳定；高层接口变化较小；底层接口未定义或经常可能被修改；产口控制组件具有较大的技术风险，需要尽早被验证；希望尽早能看到产品的系统功能行为。
自底向上集成：适应于底层接口比较稳定；高层接口变化比较频繁；底层组件较早被完成。
基于进度的集成：具有较高的并行度；能够有效缩短项目的开发进度。但是桩和驱动工作量较大；有些接口测试不充分；有些测试重复和浪费。
3、各阶段要求和成果物：
单元测试阶段：各独立单元模块在与系统地其他部分相隔离的情况下进行测试，单元测试针对每一个程序模块进行正确性校验，检查各个程序模块是否正确地实现了规定的功能。生成单元测试报告，提交缺陷报告。
集成测试阶段。集成测试是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。该阶段生成集成测试报告，提交缺陷报告。
系统测试阶段。将通过确认测试的软件，作为整个给予计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行全面的功能覆盖。该阶段需要提交测试总结和缺陷报告。
十三、当开发人员说不是BUG时，你如何应付？
1、首先，开发人员说不是 bug，有以下两种情况：
2、一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3 方商量确定好后再看要不要改。
3、二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是 BUG 的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是 bug，我也只是建议的方式写进 TD 中，如果开发人员不修改也没有大问题。如果确定是 bug 的话，一定要坚持自己的立场，让问题得到最后的确认。