单元测试：文章源自玩技e族-https://www.playezu.com/25071.html
单元测试又称模块测试，针对软件设计中的最小单位——程序模块，进行正确性检查的测试工作。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。文章源自玩技e族-https://www.playezu.com/25071.html
单元定义:文章源自玩技e族-https://www.playezu.com/25071.html
C中指一个函数，Java中指一个类，在图形化的软件中，单元一般指1个窗口，1个菜单。如何进行单元测试：单元测试主要用白盒测试，先静态地检查代码是否符合规范，然后动态运行代码，检查其实际运行结果，检查程序的运行结果是否正确是一个最基本的要求，还要关注容错处理，程序的边界值处理等。文章源自玩技e族-https://www.playezu.com/25071.html
集成测试：文章源自玩技e族-https://www.playezu.com/25071.html
集成测试又叫组装测试，通常在单元测试的基础上，将所有程序模块进行有序的、递增的测试。重点测试不同模块的接口部分。文章源自玩技e族-https://www.playezu.com/25071.html
系统测试：文章源自玩技e族-https://www.playezu.com/25071.html
指将整个软件系统看为一个整体进行测试，包括对功能、性能、以及软件所运行的软硬件环境进行测试。文章源自玩技e族-https://www.playezu.com/25071.html
验收测试：文章源自玩技e族-https://www.playezu.com/25071.html
验收测试指按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。在系统测试的后期，以用户测试为主或有测试人员等质量保证人员共同参与的测试。文章源自玩技e族-https://www.playezu.com/25071.html
α测试：指的是指的是由用户，测试人员、开发人员等共同参与的内部测试。
β测试：指的是内测后的公测，即完全交给最终用户测试验收测试的重要性：验收签字,收钱。
静态测试：指不实际运行被测软件，而只是静态地检查程序代码、界面和文档中可能存在的错误的过程。
动态测试：指实际运行被测程序，输入相应的测试数据，检查实际输出结果与预期结果是否相符。（动态测试方法为结构和正确性测试；动态测试工具Robot、QTP等）
黑盒测试：指的是把被测的软件看做一个黑盒子，我们不关心盒子里面的结构是什么样子的，只关心软件的输入数据和输出
白盒测试：指的是把盒子打来，去研究里面的源代码和程序结构。软件公司中，往往采用黑盒测试&白盒测试相结合的方式。
静态黑盒测试：看文档，看页面等
静态白盒测试：看源代码等
动态黑盒测试：使用软件等
动态白盒测试：运行源代码等
灰盒测试：是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。
功能测试：是黑盒测试的一方面，它检查实际软件的功能是否符合用户的需求。
逻辑功能测试(functiontesting)
界面测试(UItesting)
易用性测试(usability testing)
安装测试(installationtesting)
兼容性测试(compatibilitytesting)
性能测试：是软件测试的高端领域，通常我们所说的高级软件测试工程师一般就是指性能测试或是白盒测试工程师。时间性能（事务响应时间等）空间性能（系统资源消耗）一般性能测试可靠性测试负载测试压力测试
回归测试：指对软件的新版本测试时，重复执行上一个版本测试时的用例。
冒烟测试：是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测试性。
随机测试：是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。
软件测试的过程：从软件开发的过程按阶段划分有：需求验证、单元测试、集成测试、确认测试、系统测试、验收测试
测试用例（英文为TestCase,缩写为TC）：指的是在测试执行之前设计的一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。测试用例可以针对黑盒测试设计用例，也可以针对白盒测试设计用例。编写测试用例的唯一标准就是用户需求,具体的参考资料是《需求规格说明书》。
设计测试用例的原因：软件测试是一项有组织、有计划、有步骤的活动，为了将软件测试的行为转换为可管理的、具体量化的模式，需要创建和设计测试用例。
测试用例的四性：
代表性：能够代表并覆盖各种合理的和不合理合法的和不合法的、边界的和越界的以及极限的输入数据、操作等。
针对性：对程序中的可能存在的错误有针对性地测试。
可判定性：测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。
可重现性：对同样的测试用例，系统的执行结果应当是相同的。
测试用例的基本原则：
利用成熟的测试用例设计方法来指导设计
测试用例的针对性
测试用例的代表性
测试用例的可判定性
测试用例的可重现性足够详细、准确和清晰的步骤
测试用例必须符合内部的规范的要求
语句覆盖：语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次；
判定覆盖（也称为分支覆盖）：设计若干个测试用例运行所测程序使程序中每个判断的取真分支和取假分支至少执行一次；
条件覆盖：设计足够多的测试用例，运行所测程序，使程序中每个判断的每 条件覆盖设计足够多的测试用例 行所测程序使程序中每个判断的每个条件的每个可能取值至少执行一次；
判定-条件覆盖：设计足够多的测试用例，运行所测程序，使程序中每个判断的每个条件的所有可能取值至少执行一次，并且每个可能的判断结果也至少执行一次，换句话说，即是要求各个判断的所有可能的条件取值组合至少执行一次；
条件组合测试：设计足够多的测试用例，运行所测程序，使程序中每个判断的所有可能的条件取值组合至少执行一次；
路径测试：设计足够多的测试用例，运行所测程序，要覆盖程序中所有可能的路径。
主要测试技术：分支条件覆盖，基本路径测试
主要测试技术：等价类划分（边界值分析），因果图法，（正交实验法）
软件缺陷：
是指存在于软件（程序、数据、文档）中的那些不符合用户需求的问题。
软件缺陷的来源：
需求说明书：需求说明书的错误或不清楚引起的错误，是缺陷第一大的来源。
设计文档：设计文档描述不准确、以及与需求说明书不一致，是缺陷的第二大来源。
编码：纯粹是由编码的问题引起。
其它：可能是系统集成、测试引起。
软件缺陷的根源：交流不充分（客户与开发人员、开发人员与测试人员等）软件的复杂性（功能复杂、开发复杂、测试复杂）开发人员的错误（对需求的理解、开发压力、能力与经验）需求的变化（需求说明书设计文档 程序的变更）进度压力（项目周期比较紧）
软件缺陷的发现手段：同行评审、测试、管理评审、QA发现、项目组内部发现、客户反馈为了便于缺陷的定位、跟踪和修改，要对所发现的缺陷，按照缺陷的严重程度、优先级、发现阶段、修复阶段、缺陷的性质、所属功能模块、系统环境等方面进行分类和统计。
二八定理：80%的软件问题总是发生在大约20%的功能模块中。
缺陷密度：基本的缺陷测量是以每千行代码的缺陷数(个/KLOC)来测量的，其测量单位是defects／KLOC。
常见寻找bug的方法：色彩、功能结构布局、图片、页面大小、字体、窗体大小、界面文字、容错处理（也为功能缺陷，所谓容错，就是容忍错误的能力。当用户在使用软件过程中发生错误后，软件应该能给出引导信息，指应用户进行正确的操作）、数据转换（增删改查）、性能缺陷（黑盒测试）。
Web测试：
Web测试即测试网站系统在不同客户端（浏览器）的运行情况及兼容性。
Selenium：
Selenium是一个用于Web应用程序测试的工具。Selenium测试直接运行在浏览器中,就像真正的用户在操作一样。
作者：
LangZXG
链接：https://www.cnblogs.com/LangZXG/p/6077441.html