B/S结构：browser/server（浏览器/服务器）
B/S结构，Web应用程序，即在浏览器下运行的程序为Web应用程序。在浏览器中运行的程序为BS结构的程序。BS应用程序无需在本地存在文件。只需通过浏览器使用url地址访问即可
C/S结构：Client/Server或客户/服务器模式
C/S结构：Windows应用程序，即除了在浏览器中运行的程序为Windows应用程序。不在浏览器中运行的程序为CS结构的程序。CS应用程序需要在本地下有它的文件。如QQ、微信。
MVC模型：即 Model 模型、View 视图，及 Controller 控制器
控制器（serlvlet）接收浏览器发送过来的请求，控制器调用模型（JavaBean）获取数据，例如从数据库查询数据；控制器获取到数据后再交由视图（JSP）进行数据展示。MVC模型的好处是：各司其职、分工协作、利于组件重用。M：数据+业务逻辑部分，V：展示，C：控制页面跳转。
三层架构：表现层、业务层、持久层
表现层：web 层，接收 http 请求，完成 http 响应。
业务层：service 层，负责业务逻辑处理。
持久层：dao 层，负责数据持久化，即数据库和数据访问、操作。
分布式架构
分布式是将一个大的系统划分为多个业务模块,这些业务模块会分别部署到不同的机器上，通过接口进行数据交互。微服务的应用可以部署在是同一个服务器，不一定是分散在多个服务器上。微服务架构是一项在云中部署应用和服务的新技术。
微服务架构
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值；它将一个复杂的大型应用程序划分成多个微服务，这些小型服务都在各自独立的进程中运行。微服务应用都是单一职责的，只做一件事，一个微服务解决一个业务问题；微服务应用可以单独部署运行，通过轻量的通讯机制（基于HTTP/REST API）进行通信协作。每个微服务都是由独立的小团队开发，测试，部署，上线，负责它的整个生命周期；微服务是架构设计，分布式是系统部署方式；微服务相比分布式服务来说，它的微服务应用粒度更小，服务之间耦合度更低。
软件开发模型：
瀑布模型：遵循软件开发生命周期各阶段的固定顺序：计划、分析、设计、编程、测试和维护，上一阶段完成后才能进入到下一阶段， 整个模型就像一个飞流直下的瀑布，过程图如下：
缺点：过于理想化，缺乏灵活性，无法在开发过程中逐渐明确用户难以确切表达或难以想到的需求，直到软件开发完成之后才发现与用户需求的差距，此时必须付出高额的代价才能纠正这一偏差，这开发模型主要适用于需求非常明确的应用。
快速原型模型：采用了一种动态定义需求的方法，通过快速地建立个能够反映用户主要需求的软件原型，让用户使用它，了解它，再根据用户反馈进行修改，因此能够充分体现用户的参与和决策。原型化人员对原型的实施很重要，衡量他们的重要标准是能否从用户的模糊描述中快速地获取实际的需求。
增量模型：开发中，整个开发工作被分割为一系列短小的、固定长度的小项目，每次迭代都包括需求分析、设计、实现与测试。采用增量模型开发时，工作可以在需求被完整地确定之前启动，并在一次迭代种完成系统的一部分功能或业务，再通过客户的反馈来细化需求，并开始新一轮的迭代。
六大测试类型：
功能性测试：测试产品的功能实现是否符合产品需求说明书的规定；关注功能是否正确。功能测试例如：是否有不正确或遗漏了的功能，功能实现是否满足用户需求和系统设计的隐藏需求，输入能否正确接受？能否正确输出结果？
可用性测试：产品为特定用户用于特定目的时所具有的有效性、效率和主观满意度。常见的可用性测试大多都是基于界面的测试，体现在易用、易懂、简捷、美观等方面。关注产品是否好用。
兼容性测试：软件在不同的软硬件平台上是否可以正常的运行的一种测试。关注产品是否适用多种平台。如不同的操作系统、不同的浏览器、不同的数据库、不同的分辨率等。
可靠性测试：通过测试发现并纠正软件中的缺陷，提高其可靠性水平，并验证它是否达到了用户的可靠性要求。可靠性测试包含了软件的健壮、稳定、容错、自恢复等方面。关注产品是否稳定可靠。如：输入异常的数据、文件；长时间工作后保持正常，是否蓝屏、闪退等。
安全性测试：为验证应用程序的安全等级和识别潜在安全性缺陷的过程。关注产品是否存在漏洞。如：SQL注入、授权认证、用户权限等。
性能测试：用来测试软件在系统中的运行性能。负载、压力、容量测试等都属于这一范畴，关注产品是否能够高效运行。使用工具如Jmeter、locust等；关注CPU、内存、并发数、响应速度等。
前四种简单，安全性测试和性能测试门槛高，上限也高。
单元测试：集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能；
集成测试：把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试；
系统测试：把已经经过确认的软件纳入实际运行环境中，与其它系统成份组合在一起进行测试；
验收测试：分为Alpha测试和Beta测试，可能还包括第三方测试，而确认测试一般指的是Beta测试。确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。
测试的四个阶段：分析、设计、实现、执行四个阶段。
分析阶段：根据需求说明书进行测试需求分析，提取测试项，分析用户使用场景，制定测试计划。
设计阶段：设计测试用例，将测试项的细化，将更好的编写测试用例，制定测试方案（明确被测对象的特性、测试方法、测试环境和测试工具的规划、测试用例的设计方法、测试代码设计）
实现阶段：测试用例的实现，测试数据的预备，测试环境的配置好。
执行阶段：测试工程师执行测试用例，提交跟踪缺陷，维护测试用例，提交测试报告。
黑盒、白盒和灰盒测试
黑盒测试：也叫功能测试，是一种从用户角度出发的测试。把被测程序当作一个黑盒子，测试人员完全不用考虑盒子里面的逻辑结构和具体运作，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。主要的测试方法有等价划分类，错误推测法等。
白盒测试：也叫结构测试。它根据程序的控制结构设计测试用例，测试人员会利用程序内部的逻辑结构及有关信息，通过在不同点检查程序状态，检验程序中的每条通路是否都能按预定要求进行正确工作。
灰盒测试：是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑。
冒烟测试：是对软件的基本功能进行测试，测试对象是每一个新编译的需要正式测试的软件版本，目的是确认软件的基本功能正常，保证软件系统能正常跑起来，可以进行后续的正常测试工作的进行，如果最基本的测试都有问题了，就直接打回开发部了，所以正式交付的测试版本，必须先通过冒烟测试的考验
回归测试：就是对软件的原来状态重新进行功能和非功能的测试，确保先前开发并测试过的软件在缺陷修复、配置改变、软件更新等等这些变化后，仍能符合要求的运行（即：软件当前状态中那些没有被修改的部分的功能和非功能与原来状态保持一致）。
探索性测试：探索式测试是一种软件测试风格，不是一种具体软件测试技术。可以说是一种测试思维技术，它没有很多实际的测试方法、技术和工具，但却是所有测试人员都应该掌握的一种测试思维方式。探索性测试强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。探索性测试的最大特色是在对测试对象进行测试的同时学习测试对象并设计测试，在测试过程中运用获得的关于测试对象的信息设计新的更好的测试。探索测试的本质是测试策略，边学习、边设计、边测试、边思考。
探索性测试的基本过程包括如下：
识别软件系统的目的；
识别软件系统提供的功能；
识别软件系统潜在的不稳定的区域；
在探索软件系统的过程中记录关于软件的消息和问题；
创建一个测试纲要，使用它来执行测试。
极限测试法：向软件提困难的问题；例如如何使软件发挥到最大程度？哪些特性会使软件运行到其设计的极限？哪些输入和数据会耗费软件最多的运算能力？哪些输入可能欺骗它的错误检验程度？
常用的场景有：
高并发压力测试；如天猫双十一负载；
数据极限操作：如输入异常值、max值、清空所有数据。
存储空间测试：如空间不足情况；
CPU或内存不足测试：如运行应用，在内存、CPU不足情况下是否正常运行。
网络传输测试：在网速慢的情况下，是否传输文件正常等。
操作冲突测试：如在快速操作情况下，功能是否正常（用monkey）