一、基础概念
1、什么是软件测试
软件测试就是在软件的开发过程中，根据需求规格说明设计测试用例，手工或者利用测试工具有计划的执行程序，以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，并追踪和验证这些bug，保证bug被修复的过程。
测试是软件开发中不可或缺的一环，测试通过经济，高效的方法，捕捉软件中的错误，从而达到保重软件内在质量的目的。
自动化测试有时候还需要根据不同的测试需要编写不同的测试工具，设计和维护测试系统。
测试是为了证明程序有错，而不是为了证明程序无错。
测试不仅需要正向思维，还需要反向思维。
2、软件测试的目的
1）通过修正错误和缺陷可以提高软件质量，避免软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险。
2）利用测试过程中得到的测试结果和测试信息，作为后续项目开发和测试过程改进的重要输入，避免在将来的开发和测试中重复同样的的错误。
3）采用更加高效的测试管理手段提高软测的效率和软件产品的质量。
3、软件测试的原则
1)所有的软件测试应该溯源到用户的需求
2)尽早的将软件测试贯穿到软件开发的全过程中
3)完全测试是不可能，测试需要中止
4)测试无法保证软件中完全没有缺陷
5)充分注意测试中错误集群现象
6)应避免自己检测自己的程序
7)应避免测试的随意性
4、软件测试的分类
4.1 按照开发阶段分类
- 单元测试、集成测试、系统测试、验收测试
4.2 按照软件特性分类
1）功能测试
功能测试是一个试图发现程序与其外部规格说明之间存在不一致的过程。外部规格说明是一份从最终用户的角度对程序行为的精确描述。测试时按照科学方法设计的测试用例执行测试，在优先保证测试用例执行完全的前提下，再根据对业务的了解和经验性的判断进行探索性测试。
2）性能测试
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
3）界面测试
界面测试简称UI测试，界面为用户与软件交互最直接的层，所以更注重用户的体验性，主要从用户的感官、交互、浏览、情感和体验出发。具体测试用户界面的功能模块布局是否合理，整体风格是否统一，各个控件的放置位置是否符合客户使用习惯，是否符合操作便捷，导航是否简单易懂，界面中文字是否正确，命名是否统一，页面美观，文字、图片组合是否完美等等。测试时可以按照最终用户具体的需求，以及通用的用户体验原则进行测试list的编写，然后测试人员根据list执行。
4）兼容测试
兼容性测试是指测试软件在特定的硬件平台上、不同的应用软件之间、不同的操纵系统平台上、不同的网络等环境中是否能够很友好的运行的测试。通常兼容性测试为软件在不同浏览器、操作系统和分辨率下的兼容测试。测试时测试人员按照软件的具体兼容性需求进行测试。
5）易用性测试
考察评定软件的易学易用性，各个功能是否易于完成，软件界面是否友好等方面进行测试。测试时可以根据用户需求，以及同类行业软件对易用性的通用原则列出测试list，然后测试人员根据list执行。
4.3 按照测试技术分类
- 黑盒测试
- 白盒测试
- 灰盒测试
4.4 按照测试运行主体分类
- 手工测试（功能测试）：点点点
- 自动化测试：利用测试工具或者写代码的方式测试
4.5 按照代码运行分类
- 静态测试、动态测试
4.6 其他测试
- 回归测试、冒烟测试、随机测试、猴子测试
5、为什么想做测试
1）逻辑性还可以，可以理性分析问题、思考比较全面，有耐心。
软件测试在前期需要分析需求文档和各种项目需求书，制定测试计划，设计测试用例，后期执行测试用例的时候需要判断逻辑的正确性、对可行性逻辑分析、
2）有团队协作能力、善于沟通
做软件测试需要和技术人员、产品人员、上下级沟通，和组员配合完成测试任务，配合开发人员重现缺陷。
3）有责任
要敢承担责任，敢坚持自己的意见
缺陷洞察能力，一般缺陷的发现能力、隐性问题的发现能力、发现连带问题的能力、发现问题隐患的能力、尽早发现问题的能力、发现问题根源的能力；
4）专业技术能力，
掌握测试基础知识、计算机网络、数据库等基础知识，熟练运用测试工具
5）学习能力，适应性强，抗压
6、怎么看待软件测试的潜力和挑战
软件测试是正在快速发展，充满挑战的领域。尽管现在许多自动化测试软件的出现使得传统手工测试的方式被代替，但自动化测试工具的开发、安全测试、测试建模、精准测试、性能测试、可靠性测试等专项测试中仍然需要大量具有专业技能与专业素养的测试人员，并且随着云计算、物联网、大数据的发展，传统的测试技术可能不再适用，测试人员也因此面临着挑战，需要深入了解新场景并针对不同场景尝试新的测试方法，同时敏捷测试、Devops的出现也显示了软件测试的潜力。
7、软件测试的核心竞争力是什么
测试人员的核心竞争力在于提早发现问题，并能够发现别人无法发现的问题。
1、早发现问题：问题发现的越早，解决的成本越低。如果一个需求在还未实现的时候就能发现需求的漏洞，那么这种问题的价值是最高的。
2、发现别人无法发现的问题：所有人都能发现的问题，你发现了，那就证明你是可以被替代的。别人发现不了，而你可以发现，那么你就是无法被替代。
8、自动化测试与手动的优缺点
手工测试缺点：
- 1、重复的手工回归测试，代价昂贵、容易出错。
- 2、依赖于软件测试人员的能力。
手工测试优点：
- 1、测试人员具有经验和对错误的猜测能力。
- 2、测试人员具有审美能力和心理体验。
- 3、测试人员具有是非判断和逻辑推理能力。
自动化测试优点：
-
1、可以对程序的新版本自动执行回归测试，看以前发生在旧版本中的错误和缺陷是否在新版本中出现。用自动化的方式做回归测试，可以极大提高测试效率，缩短回归测试时间。
-
2、更好地利用资源，节省时间和人力。利用自动化测试去做一些繁琐且重复的测试，测试人员就可以去设计更好的测试用例，或者去做那些不适合自动测试的测试，可以提高测试的效率。
-
3、自动化测试可以执行一些手工测试困难或不可能进行的测试，比如压力测试、并发测试。
-
4、测试具有一致性和可重复性。由于测试是自动执行的，每次测试的结果和执行的内容的一致性是可以得到保障的，也就不存在执行过程中由于人为因素出现错误，因此一旦测试通过，就会提高用户对于软件的信任度。
-
5、测试的复用性。由于自动测试通常采用脚本技术，这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。
自动化测试缺点：
-
1、不能取代手工测试， 手工测试比自动测试发现的缺陷更多
-
2、对测试质量的依赖性极大
-
3、测试自动化不能提高有效性
-
4、测试自动化可能会制约软件开发。由于自动测试比手动测试更脆弱，所以维护会受到限制，从而制约软件的开发。
-
5、 工具本身并无想像力
自动化测试流程：
- 首先判断这个项目是不是和推广自动化测试
- 然后对项目做需求分析，制订测试计划
- 搭建自动化测试框架
- 设计测试用例
- 执行测试
- 评估
9、软件测试要学什么
一、功能测试
计算机基础，软件生命周期、开发模型、测试模型。软件测试概念，软件测试方法及分类、热门领域测试技巧。Linux系统，数据库的定义及基本概念，MySQL、Oracle。搭建功能测试实战环境，Linux环境下B/S结构产品测试项目等内容。
二、自动化测试
Python，自动化测试分类及自动化适用的项目。Selenium，使用Selenium对网站的核心功能进行自动化测试。Appium，Monkey，使用Appium对APP核心功能进行测试验证，对APP功能进行评估等内容。
三、接口测试
接口测试，Postman安装使用，Fiddler安装使用，Web和手机抓包，基本设置方法。Jmeter，搭建接口测试环境，分析业务流程，设计测试用例，使用Jmeter执行测试用例。Web安全核心理论、Web漏洞及防御、渗透测试、SQL注入、XSS跨站脚本、AppScan等内容。
四、性能测试
性能测试，VuGen，Controller，Analysis，性能测试调优，数据库调优，性能测试指标，Jmeter在性能测试中的应用。搭建测试环境，编写测试计划和测试用例，设置和运行场景，监控和收集数据，写分析报告，项目综合评审等内容
需要的知识：
软件测试基础理论知识，如黑盒测试、白盒测试等；
考编程语言基础，如C/C++、java、python等；
自动化测试工具，如Selenium、Appium、Robotium等；
计算机基础知识，如数据库、Linux、计算机网络等；
测试框架，如JUnit等。
10、测试项目的具体工作是什么
搭建测试环境
撰写测试用例
执行测试用例
写测试计划，测试报告
测试，并提交BUG表单
跟踪bug修改情况
执行自动化测试，编写脚本，执行，分析，报告
进行性能测试，压力测试等其他测试，执行，分析，调优，报告
11、测试的基本流程
- 获取测试需求
- 编写测试计划
- 制订测试方案
- 设计和开发测试用例
- 执行测试
- 提交缺陷
- 测试分析和评审
- 测试总结
- 准备下一版本测试
需求的覆盖程度 = 被测试用例覆盖的需求数/需求总点数
二、软件开发模型
软件生命周期：
- 需求分析—>概要设计—>详细设计—>编码—>测试—>验收
常见开发模型：
- 瀑布模型、快速原型模型、增量模型、迭代模型、螺旋模型
1、瀑布模型
最早提出的软件开发的过程模型。
特点：
-
瀑布模式所有一切都有完整细致的说明。当软件提交到测试小组时，所有细节都已确定并有文档记录，而且实现在软件之中。由此，测试小组得以制定精确的计划和进度。
-
测试对象非常明确，即程序。
-
在瀑布模型中，测试被认为是在软件开发过程的后期阶段进行的“一次性”活动，这带来一个巨大的缺点，因为测试仅在最后进行，所以一些根本性问题可能出现在早期，但是直到准备发布产品时才可能发现。
-
强调时间顺序的严格执行，前阶段不完成，后阶段不开始
-
不适应用户需求的变化
-
线性开发，用户等到整个过程的末期才能见到开发成果，从而增加了开发风险
2、螺旋模型
引入了风险分析
特点：
-
螺旋模式中包含了一点瀑布模式（分析、设计、开发和测试的步骤）、一点边写边改模式（螺旋模式的每一次）和一点大爆炸模式（从外界观察）。加上该模式发现问题早、成本低的特点，可以算做相当好的开发模式。
-
软件测试员喜欢该模式。因为通过参与最初设计的设计阶段，可以尽早地影响到产品，可以把产品的来龙去脉弄得很清楚；并且在项目末期，不至于最后一分钟还在匆匆忙忙地进行全面测试。软件测试员的测试一直都在进行，所以最后一步只是一个验证表面所有部分都没有问题。
3、敏捷开发模型
敏捷宣言：敏捷软件开发宣言
这不是一份抽象的方法论集合，并没有提供任何死板僵化的开发方法和复杂的 技术结构层次，而更像是一份针对客户和开发个体的箴言警句集。
特点：
-
敏捷开发提倡迭代式和增量式的开发模式，并强调测试在其中的重要作用。
-
敏捷开发是以用户为中心、以客户需求为导向的开发过程，在此过程中随时做 好“迎接变化”的准备，客户是敏捷的关键环节。
-
敏捷开发没有单一固定的开发方法或过程，很多快速的开发模式都可以看作是敏捷。但这些模式都有三个共同点：依赖客户的参与、测试驱动以及紧凑的迭 代开发周期。
测试驱动开发是其核心实践。
- 测试驱动开发：在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行。
4.其他模型
迭代模型：
- 强调开发的深入；初级版本稳定可运行
增量模型：
-
把软件分割成独立的模块，分批次的完成与交付。
-
打破了原有的软件结构和框架，可能带来一定的风险
-
一般与迭代模型一起用
快速原型模型：
-
就是一个模型，可以模拟操作，简单运行
-
Axure，制作原型
三、软件测试模型
1、V模型
优点：
- V 模型明确地将测试分为不同的级别或阶段。
- 每个阶段都与开发的各阶段相对应。
- V 模型的测试策略包括低层测试和高层测试，低层测试是为了源代码的正确性，高层测试是为了整个系统满足用户的需求。
缺点：
- 测试是开发之后的一个阶段。实际应用中容易导致需求阶段的错误一直到最后 系统测试阶段才被发现。
- 测试的对象就是程序本身。忽视了测试活动对需求分析，系统设计等活动的验证和确认的功能，直到后期的验收测试才被发现。
- 过程是线性的、顺序的，不能反复和迭代。
2、W模型
优点：
- W 模型从 V 模型演化过来，实际上开发是 V，测试是并行的 V，测试与开发 同步进行，有利于尽早地全面的发现问题。
- 测试伴随整个软件开发周期。
- 测试的对象不仅仅是程序，需求、设计等同样要测试。
缺点：
- W 模型中，需求、设计、编码等活动被视为串行的，同时测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。
3、H模型
特点：
- 它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。测试贯穿产品整个生命周期，与其他流程并发地进行。
- 软件测试不仅仅指测试的执行，还包括很多其他的活动（计划、需求分析、用例设计、环境搭建、提交缺陷、评估总结等）。
- 当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。
- 软件测试要尽早准备，尽早执行。
- 软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。
测试和开发需要怎么结合才能使软件的质量得到更好的保障
参考回答：
测试和开发应该按照W模型的方式进行结合，测试和开发同步进行，能够尽早发现软件缺陷，降低软件开发的成本。
在V模型中，测试过程被加在开发过程的后半部分，单元测试所检测代码的开发是否符合详细设计的要求。集成测试所检测此前测试过的各组成部分是否能完好地结合到一起。系统测试所检测已集成在一起的产品是否符合系统规格说明书的要求。而验收测试则检测产品是否符合最终用户的需求。
V模型的缺陷在于仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析、系统设计的验证，因此需求阶段的缺陷很可能一直到后期的验收测试才被发现，此时进行弥补将耗费大量人力物力资源。
相对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。
W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。
W模型中测试的活动与软件开发同步进行，测试的对象不仅仅是程序，还包括需求和设计，因此能够尽早发现软件缺陷，降低软件开发的成本。
四、按照开发阶段进行测试
1、单元测试
完成最小的软件设计单元（模块）的验证工作，目标是确保模块被正确的编码，使用过程设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误，通常情况下是白盒的，对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早的发现和解决不易显现的错误。
意义以及是否可行：
-
单元测试可以有效地测试某个程序模块的行为，是未来重构代码的信心保证。事前可以保证质量，事后可以快速复现问题，并在修改代码后做回归自测。
-
可行性考虑的是要用一些可行的方法做到关键的代码可测试，如通过边界条件、等价类划分、错误、因果，设计测试用例要覆盖常用的输入组合、边界条件和异常。
2、集成测试
集成测试指的是通过测试发现与模块接口有关的问题。
目标是把通过了单元测试的模块拿来，构造一个在设计中所描述的程序结构，应当避免一次性的集成（除非软件规模很小），而采用增量集成。
-
自顶向下集成：模块集成的顺序是首先集成主模块，然后按照控制层次结构向下进行集成，隶属于主模块的模块按照深度优先或广度优先的方式集成到整个结构中去。
-
自底向上集成：从原子模块开始来进行构造和测试，因为模块是自底向上集成的，进行时要求所有隶属于某个给顶层次的模块总是存在的，也不再有使用稳定测试桩的必要。
3、确认测试
也称为冒烟测试，一般不作为正式的测试环节，通过了确认测试的软件才具备了进入系统测试的资格。
-
确认（validation）：通过检查和提供客观证据来证实特定目的的功能或者应用是否已经实现。
-
验证（verification）：通过检查和提供客观证据来证实指定的需求是否满足
-
先确认是否有，在验证是否满足需求。
4、系统测试
系统测试是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。
系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。
系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。
因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下来进行测试。
系统测试能够对软件所有功能进行功能测试，能够覆盖系统所有联合的部件，是针对整个产品系统进行的测试，能够验证系统是否满足了需求规格的定义，因此系统测试是很重要的测试。
4、回归测试
回归测试是指在发生修改之后重新测试先前的测试用例以保证修改的正确性。
理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再次出现。根据修复好了的缺陷再重新进行测试。
回归测试的目的在于验证以前出现过但已经修复好的缺陷不再重新出现。一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。
5、验收测试
验收测试是指系统开发生命周期方法论的一个阶段，这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。
验收测试包括Alpha测试和Beta测试。
-
Alpha测试：是由用户在开发者的场所来进行的，在一个受控的环境中进行。开发者对用户的指导下进行测试，开发者负责记录发现的错误和使用中遇到的问题
-
Beta测试：在开发者不能控制的环境中的真实应用，由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，由用户记录测试中遇到的问题并报告给开发者，开发者对系统进行最后的修改，并开始准备发布最终的软件。
验收测试合格通过的准则是：
- 1）软件需求分析说明书中所定义的功能全部实现，性能指标全部达到要求。
- 2）所有测试项中没有残余的一级、二级、三级错误
- 3）立项审批表、需求分析文档、设计文档和编码实现一致
- 4）验收测试工件齐全（测试计划、测试用例、测试日志、测试通知单、测试分析报告）
6、集成测试和系统测试的区别以及应用场景
区别：
- 1、计划和用例编制的先后顺序：
从V模型来讲，在需求阶段就要制定系统测试计划和用例，HLD的时候做集成测试计划和用例，有些公司的具体实践不一样，但是顺序肯定是先做系统测试计划用例，再做集成。
- 2、用例的粒度：
系统测试用例相对很接近用户接受测试用例，集成测试用例比系统测试用例更详细，而且对于接口部分要重点写，毕竟要集成各个模块或者子系统。
- 3、执行测试的顺序：
先执行集成测试，待集成测试出的问题修复之后，再做系统测试。
应用场景：
集成测试：
-
完成单元测试后，各模块联调测试；
-
集中在各模块的接口是否一致、各模块间的数据流和控制流是否按照设计实现其功能、以及结果的正确性验证等等；
-
可以是整个产品的集成测试，也可以是大模块的集成测试；
-
集成测试主要是针对程序内部结构进行测试，特别是对程序之间的接口进行测试。
-
集成测试对测试人员的编写脚本能力要求比较高。
-
测试方法一般选用黑盒测试和白盒测试相结合。
系统测试：
- 针对整个产品的全面测试，既包含各模块的验证性测试（验证前两个阶段测试的正确性）和功能性（产品提交个用户的功能）测试，又包括对整个产品的健壮性、安全性、可维护性及各种性能参数的测试。
- 系统测试测试软件《需求规格说明书》中提到的功能是否有遗漏，是否正确的实现。
- 做系统测试要严格按照《需求规格说明书》，以它为标准。
- 测试方法一般都使用黑盒测试法。
五、自动化测试
自动化测试框架
1、模块化测试框架
模块化测试脚本框架（TEST MODulARITY FRAMEWORK）需要创建小而独立的可以描述的模块、片断以及待测应用程序的脚本。这些树状结构的小脚本组合起来，就能组成能用于特定的测试用例的脚本。
在一个组件上方建立一个抽象层使其在余下的应用中隐藏起来，这是众所周知的编程技巧。这样应用同组件中的修改隔离开来，提供了程序设计的模块化特性。模块化测试脚本框架使用这一抽象或者封装的原理来提高自动测试组合的可维护性和可升级性。
2、测试库框架
测试库框架（Test Library Architecture）与模块化测试脚本框架很类似，并且具有同样的优点。
不同的是测试库框架把待测应用程序分解为过程和函数而不是脚本。这个框架需要创建描述模块、片断以及待测应用程序的功能库文件。
3、关键字驱动或表驱动的测试框架
对于一个独立于应用的自动化框架，关键字驱动（KEYWORD DRIVEN）和表驱动（TABLE DRIVEN）测试是可以互换的术语。
这个框架需要开发数据表和关键字。这些数据表和关键字独立于执行它们的测试自动化工具，并可以用来“驱动＂待测应用程序和数据的测试脚本代码，关键宇驱动测试看上去与手工测试用例很类似。
在一个关键字驱动测试中，把待测应用程序的功能和每个测试的执行步骤一起写到一个表中。这个测试框架可以通过很少的代码来产生大量的测试用例。同样的代码在用数据表来产生各个测试用例的同时被复用。
4、数据驱动测试框架
测试的输入和输出数据是从数据文件中读取（数据池，ODBC源，CSV文件，EXCEL文件，ADO对象等）并且通过捕获工具生成或者手工生成的代码脚本被载入到变量中。
在这个框架中，变量不仅被用来存放输入值还被用来存放输出的验证值。
整个程序中，测试脚本来读取数值文件，记载测试状态和信息。
这类似于表驱动测试，在表驱动测试中，它的测试用例是包含在数据文件而不是在脚本中，对于数据而言，脚本仅仅是一个“驱动器”，或者是一个传送机构。然而，数据驱动测试不同于表驱动测试，尽管导航数据并不包含在表结构中。
在数据驱动测试中，数据文件中只包含测试数据。这个框架意图减少需要执行所有测试用例所需要的总的测试脚本数。数据驱动需要很少的代码来产生大量的测试用例，这与表驱动极其类似。
5、混合测试自动化（Hybrid Test Automation）框架
最普遍的执行框架是上面介绍的所有技术的一个结合，取其长处，弥补其不足。这个混合测试框架是由大部分框架随着时间并经过若干项目演化而来的