. 测试的目的
1）软件测试是为了发现错误而执行程序的过程。
2）测试是为了证明程序有错，而不是证明程序无错。（发现错误不是唯一目的）
3）一个好的测试用例在于它发现至今未发现的错误。
4）一个成功的测试是发现了至今未发现的错误的测试。
注意：
1、测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征。可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，通过分析也能帮助我们设计出有针对性的检测方法，改善测试的有效性。
2、没有发现错误的测试也是有价值的，完整的测试是评定测试质量的一种方法。详细而严谨的可靠性增长模型可以证明这一点。例如Bev Littlewood发现一个经过测试而正常运行了n个小时的系统有继续正常运行n个小时的概率。
6. 软件测试原则
1）应当把“尽早地不断地进行软件测试“作为软件开发者的座右铭。
2）测试用例应由测试数据和与之对应的预期输出结果这两部分组成。
3）程序员应避免检查自己的程序。
4）在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。
5）充分注意测试中的群集现象。
6）严格执行测试计划，排除测试的随意性。
7）应当对每一个测试结果做全面的检查。
8）妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便
7. 软件测试分为哪几个阶段？
软件测试分类
按照阶段
单元测试：是指对软件中的最小可测试单元进行检查和验证
集成测试：集成测试是单元测试的下一个阶段，是指将通过测试单元模块组装成系统或者子系统，再进行测试，重点测试不同模块的接口部分。
系统测试：指的是将整个软件系统看做一个1个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。
验收测试：以用户为主的测试，软件开发人员和质量保证人员参加
按照是否查看源代码划分
白盒测试:指的是把盒子盖打开，去研究里边源代码和程序结构(单元测试，ui/接口自动化测试)
黑盒测试:把被测试的软件看做一个黑盒子，我们不去关心盒子里边的结构是什么样子，只关心软件的输入数据和输出结果
功能测试
**逻辑功能测试:**测试应用是否符合逻辑，比如应该先注册账号之后，才能进行登录,登录之后才能看我的购物车
界面测试:窗口大小，按钮大小，点击按钮弹出什么样的提示框，是否有滚动条，下拉菜单是否有展示内容
易用测试:从软件使用的合理性和方便性等角度对软件系统进行检查,比如，软件窗口长宽比例是否合适，颜色色彩是否赏心悦目，字体大小是否合适
**安装测试:**安装磁盘空间不足，安装中断(关闭程序，关机，，)下次安装时是否继续上次的安装等。。。
兼容测试:硬件兼容性测试和软件兼容性测试（硬件兼容性:比如一款软件在pc机，笔记本,主机上是否兼容，软件兼容性测试:比如一款软件在window8和window10上是否兼容）
性能测试
一般性能测试
稳定测试:
负载测试: 让被测系统在其能够忍受的压力范围之内连续运行，来测试系统的稳定性。（测试载重）
压力测试:持续不断的给被测试的系统增加压力，直到被测试的系统压垮为止，用来测试系统所承受的最大压力。（测试强度）
其他
回归测试：回归测试是指修改了旧代码后，重新在新环境上进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
冒烟测试：指对一个软件进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。
随机测试：是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误
8. 单元测试与集成测试的侧重点
单元测试
是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试，测试重点是系统的模块，包括子程序的正确性验证等。
- 1
集成测试
也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求，组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。测试重点是模块间的衔接以及参数的传递等。
- 1
9. 系统测试范围
指的是将整个软件系统看做一个1个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。
系统测试由黑盒测试人员在整个系统集成完毕后进行测试，前期主要测试系统的功能是否满足需求，后期主要测试系统运行的性能是否满足需求，以及系统在不同的软硬件环境的兼容性等
10. a测试与ß测试的区别
α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。
β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。
它们都是验收测试！
α测试是指把用户请到开发方的场所来测试
β测试是指在一个或多个用户的场所进行的测试。
α测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。
β测试的环境是不受开发方控制的, 用户数量相对比较多,时间不集中。
α测试先于β测试执行。通用的软件产品需要较大规模的β测试,测试周期比较长
11. 验收测试怎么做？
验收测试主要包含两个阶段：二轮测试和冒烟测试。在测试阶段的先后顺序上，二轮测试在一轮测试(需求的系统性测试)之后，在冒烟测试之前。在测试粒度上，按照由细到粗的顺序，依次为二轮测试和冒烟测试;冒烟测试，众所周知是对功能主路径的回归验证，而二轮测试则是执行较冒烟更细粒度的测试，另外也包含了一轮测试阶段中出现bug较多的场景等等。
一轮测试：系统的测试验证需求的阶段，包含全部功能点的验证、兼容性验证、性能验证等等;
二轮测试：作为一轮测试后的整体回归验证阶段，主要侧重验证功能的主流程和一轮测试中问题较多的场景的相关用例
开始标准
一、测试自身
1、一轮测试执行完毕;
2、一轮阶段的待检验bug回归完毕;
3、发起内核代码迁移邮件，确认内核开发要集成到正式发布分支的代码，且均已验证完毕。
二、配合方
1、各配合方均已上线验证完毕;
2、例如：产品配置项、服务端、前端、第三方等;
3、反例：小编最近碰到个问题，由于没有在二轮测试开始前做好上线验证工作，导致在二轮执行阶段遇到多方联调问题，影响项目进度。
4、具体表现：在二轮测试执行阶段，发现已经上线了的服务端和第三方相关功能无法顺利走通，经过定位排查发现是在上线时，服务端和第三方的接口没有联调成功。
5、三方(开发、产品、测试)确认无阻塞二轮测试的bug;
6、代码集成完毕;(视具体项目组而定)
7、新功能或有较大改动模块，产品&交互验收通过并已回复邮件;
8、新功能或有视觉改动模块，视觉走查通过并已回复邮件;
9、备注：当项目发版紧张时，开发评估一轮未结束的模块对其他模块均无影响(如，独立插件的功能模块)，可以先执行其他不受影响的模块的二轮测试
12. 白盒、黑盒和灰盒测试区别
白盒测试:指的是把盒子盖打开，去研究里边源代码和程序结构(单元测试，ui/接口自动化测试)
黑盒测试:把被测试的软件看做一个黑盒子，我们不去关心盒子里边的结构是什么样子，只关心软件的输入数据和输出结果
灰箱测试或灰盒测试(Gray-box testing):灰箱测试就像黑箱测试一样是通过用户界面测试，但是测试人员已经有所了解该软件或某种软件功能的源代码程序具体是怎样设计的。甚至于还读过部分源代码。 因此测试人员可以有的放矢地进行某种确定的条件/功能的测试。这样做的意义在于:如果你知道产品内部的设计和对产品有透过用户界面的深入了解，你就能够更有效和深入地从用户界面来测试它的各项性能
13. 冒烟测试的目的
冒烟测试：指对一个软件进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。
使用冒烟测试是为了正式测试前，验证是否产品或系统的主要需求或预置条件是否存在bug
14. 回归测试怎么做？
回归测试：回归测试是指修改了旧代码后，重新在新环境上进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
1、在测试策略制定阶段，制定回归测试策略
2、确定需要回归测试的版本
3、回归测试版本发布,按照回归测试策略执行回归测试
4、回归测试通过，关闭缺陷跟踪单（问题单）
5、回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试
15. 全部回归与部分回归的区别？
对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止出现“以前应用没有的问题现在出问题了”，这是全部回归；当在测试过程中，发现某个模块存在缺陷，开发修复后，测试人员重新验证该缺陷是否被修复，以及验证相关联的模块是否受影响，这叫部分回归。
16. 需求分析的目的
1、把用户需求转化为功能需求：
1）对测试范围进度量 2）对处理分支进行度量 3）对需求业务的场景进行度量 4）明确其功能对应的输入、处理和输出 5）把隐式需求转变为明确。
- 1
2、明确测试活动的五个要素：测试需求是什么、决定怎么测试、明确测试时间、确定测试人员、确定测试环境：测试中需要的技能，工具以及相应的背景知识
，测试过程中可能遇到的风险等等。测试需求需要做到尽可能的详细明确，以避免测试遗漏和误解。
- 1
17. 测试计划的目的
1、测试的目的是为了bai发现du尽可能多的缺陷，不是为了说zhi明软件中没有缺陷。
2、成功的测试在于发现了迄今尚未发现的缺陷。所以测试人员的职责是设计这样的测试用例，它能有效地揭示潜伏在软件里的缺陷
18. 什么时候开始写测试计划
在项目开始后，在前期你需要了解测试的背景，范围和工作量，以及人员的分工，所需的资源，工期等，在这些了解清楚后开始撰写测试计划
19. 由谁来编写测试计划
测试计划一般由资深的测试人员来做， 要对整zhi体的项目有非常好的掌控，有丰富的测试经验的人员来编写测试计划。
1. 测试计划一般由测试经理来编写。
2. 测试组其他人员， 会针对自己分配的任务估算自己任务的时间，统一汇总到测试经理那里
- 1
- 2
- 3
20. 测试计划的内容
测试背景 测试目标 测试范围 测试输出文档 测试策略 测试规模工作量分析 测试进程 测试进度及时间安排 测试资源 人力，设备， 风险管理
（1）测试环境：测试环境+生产环境
（2）测试范围：新增需求+全功能回归
（3）测试重点：优先级为high的
（4）注意事项：开发提供修改点
（5）测试级别：常规啥的
（6）测试方法：功能测试？性能测试
（7）测试文档：测试依据、测试条件、测试用例
（8）计划测试资源：人员以及安排的工作日
（9）是否需要外部支持：是/否
（10）测试出口：发布时间
21. 结束条件(项目上线的条件)
结束条件：
1.测试用例执行比例，一般功能测试用例全部执行完毕，非功能测试用例执行达95%以上
2.测试缺陷修改数量，一般及以上的用例全部修复并验证通过，已修复缺陷占比95%以上
3.测试覆盖需求程度，测试覆盖全部的需求且达到上线的要求或标准
上线条件：
1.编写目的：明确软件测试工作的开始和结束标准。
2.软件测试合格标准：以上比例为错误占总测试模块的比例。
3.缺陷修复率标准
1) A、B、C级错误修复率应达到100%
2) D级错误修复率应达到96%以上
4.覆盖率标准
测试需求执行覆盖率应达到100%（业务测试用例均以执行）。
5.错误级别
A级：不能完全满足系统要求，基本功能未完全实现；或者危及人身安全。系统崩或挂起等导致系统不能继续运行。
B级：严重地影响系统要求或基本功能的实现，且没有更正办法（重新安或重新启动该软件不属于更正办法）。使系统不稳定、或破坏数据、或产生错误结果，或部分功能无法执行，而且是常规操作中经常发生或非常规操作中不可避免的主要问题。
C级：严重地影响系统要求或基本功能的实现，但存在合理的更正办法（重新启动该软件不属于更正办法）。系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题