目录
前言
入软件测试这一行至今已经10年多，承蒙领导们的照顾与重用，同事的支持与信任，我的职业发展算是相对较好，从入行到各类测试技术岗位，再到测试总监，再转行入测试讲师做技术分享，每一步都刚刚好。最近有很多刚入行的小伙伴问我软件测试的基础问题，我挺苦恼的，今天索性就给大家谈谈测试的理论基础吧。
软件测试（Software Testing）的定义
官方释义：
a.用来促进鉴定软 件的正确性、完整性、安全性和质量的过程；
b.是一种实际输出与预期输出间的审核或者比较过程；
c.使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别；
经典定义：
a.软件测试是为了发现错误而执行程序的过程。
b.软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例(即输入数据及其预期的输出结果)，并利用这些测试用例去运行程序，以发现程序错误的过程。
软件测试的分类
按开发阶段来分：单元测试、集成测试、系统测试、验收测试。
按测试的实施单位来分：开发方测试、用户测试、第三方测试。
按测试技术来分：白盒测试、黑盒测试、灰盒测试。
软件测试的常用种类
黑盒测试：把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。
黑盒测试方法包括：等价类划分、边界值分析、因果图分析、错误推测法、功能图分析等。
白盒测试：是对软件的过程性细节做细致的检查。是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。
白盒测试方法包括：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖等。
单元测试：是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。一个软件单元的正确性是相对于该单元的规约(详细设计)而言的。因此，单元测试以被测试单位的规约为基准。
单元测试方法包括：控制流测试、数据流测试、排错测试、分域测试等。
集成测试：是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。
系统测试：是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多，主要有功能测试、性能测试、随机测试等。
验收测试：由客户或最终用户执行，旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。
UAT测试：
UAT，(User Acceptance Test),也就是用户验收测试，或用户可接受测试，系统开发生命周期方法论的一个阶段，这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。 它让系统用户决定是否接收系统。 它是一项确定产品是否能够满足合同或用户所规定需求的测试。
功能测试：对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。
性能测试：是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
用户视角的软件性能：
- 从用户角度来说，软件性能就是软件对用户操作的响应时间。
系统管理员视角的软件性能：
- 系统的响应时间；
- 系统运行时服务器的状态，如CPU利用情况、内存使用情况等；
- 系统是否能够实现扩展；
- 系统支持多少用户访问；
- 系统性能可能的瓶颈在哪里；
- 系统是否支持7*24小时的业务访问。
软件性能指标：
- 并发用户：一给定时间内，某个时刻与服务器同时进行会话操作的用户数。
- 响应时间：客户端发出请求到得到服务器返回结果的整个过程所经历的时间。
- 吞吐量：单位时间内系统处理的客户请求的数量；一般来说，吞吐量用请求数/秒或页面数/秒来衡量；从业务的角度，吞吐量也可以用访问人数/天或处理的业务数/小时等单位来衡量；从网络的角度来说，也可以用字节数/天等单位来考察网络流量。
- 资源利用率：指系统资源的使用程度，比如服务器的CPU利用率、内存利用率、磁盘利用率、网络带宽利用率等。
负载测试：
- 定义
- 数据在超负荷环境下运行，测试软件系统是否能够承担。这种超负荷主要指多并发用户。
- 方法
- 人为生成大数据量，并利用工具模拟频繁并发访问
- 工具
- 一般需要使用自动化工具
- 考察指标
- 响应时间、交易容量、资源使用率等
压力测试：
- 定义
- 指系统不断施加越来越大的负载（并发，循环操作，多用户，网络流量）的测试。
- 目标
- 通过确定一个系统的瓶颈或者不能接收的性能点，来确定系统能提供的最大服务级别的测试。
恢复测试：恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。如果系统恢复是自动的（即恢复由系统自身完成），则应该检验以下内容：重新初始化、检验点设置机构、数据恢复以及重新启动是否正确。
可用性测试：
可用性测试是面向用户的系统测试。让一群有代表性的用户尝试对产品进行典型操作，- - 同时观察员和开发人员在一旁观察，聆听，做记录。
- 系统中是否存在繁琐的功能以及指令；
- 安装过程是否复杂；
- 错误信息提示内容是否详细；
- GUI接口是否标准；
- 登录是否方便；
- 需要用户记住内容的多少；
- 帮助文本是否详细；
兼容性测试：
- 定义
- 测试软件在一个特定的硬件、软件、操作系统、网络等环境下系统能否正常运行。
- 目的
- 检验被测软件对其他应用软件或者其他系统的兼容性。
安全性测试：
- 定义
- 安全测试检测系统对非法入侵的防范能力。
- 应用程序级别的安全性测试
- 数据库安全性测试
- 系统级别的安全性测试
Alpha测试：由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。开发者负责记录发现在错误和使用中遇到的问题。总之，Alpha测试是在受控的环境中进行的。
Beta测试：由软件的最终用户们在一个或多个客房场所进行。与Alpha测试不同，开发者通常不在Beta测试的现场，因Beta测试是软件在开发者不能控制的环境中的“真实”应用。用户Beta测试过程中遇到的一切问题（真实在或想像的），并且定期把这些问题报告给开发者。接收到在Beta测试期间报告的问题之后，开发者对软件产品进行必要的修改，并准备向全体客户发布最终的软件产品。
冒烟测试：可以根据其名称理解为该种测试耗时短，仅用一袋烟功夫足够了；其实是对软件基本的功能进行测试，测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本的功能正常，保证软件系统能跑的起来，可以进行后续的正式测试工作。
回归测试：是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误，回归测试的困难在于不好确定哪些内容应当被重新测试。
随机测试：主要是根据测试者的经验对软件进行功能和性能抽查。它是根据测试说明书执行样例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。
动态测试：是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率和健壮性等性能，这种方法由三部分组成：构造测试实例、执行程序、分析程序的输出结果。所谓软件的动态测试，就是通过运行软件来检验软件的动态行为和运行结果的正确性。目前，动态测试也是公司的测试工作的主要方式。
静态测试：是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。
UI测试：指测试用户界面的风格是否满足客户要求，文字是否正确，页面美工是否好看，文字，图片组合是否完美，背景是否美观，操作是否友好等；用户界面(UI)测试用于核实用户与软件之间的交互。UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI测试还可确保UI中的对象按照预期的方式运行，并符合公司或行业的标准。包括用户友好性，人性化，易操作性测试。UI测试比较主观，与测试人员的喜好有关。
自动化测试：利用软件测试工具自动实现全部或部分测试，它是软件测试的一个重要组成部分，能完成许多手工测试无法实现或难以实现的测试；正确、合理的实施自动测试，能够快速、全面的对软件进行测试，从而提高软件质量，节省经费，缩短软件发布周期。
桩测试：
桩的英文是stub；是指一个软件模块的框架或特殊目标实现，主要用于开发和测试一个组件，该组件调用或依赖这个模块。
桩模块：集成测试前要为被测模块编制一些模拟其下级模块功能的“替身”模块，以代替被测模块的接口，接受或传递被测模块的数据，这些专供测试用的“假”模块称为被测模块的桩模块。
测试桩一般是 自顶向下集成时需要使用
驱动测试：
所谓驱动测试（自底向上集成时使用），就是你负责测试模块/方法是中间的，没有main（）入口，怎么编译，怎么启动呢？就需要写一个带main()的方法来调用你的模块/方法
桩模块的使命除了使得程序能够编译通过之外，还需要模拟返回被代替的模块的各种可能返回值(什么时候返回什么值需要根据测试用例的情况来决定)。
驱动模块的使命就是根据测试用例的设计去调用被测试模块，并且判断被测试模块的返回值是否与测试用例的预期结果相符
public class ddd
{
//Test driver
public static void main(String[] args) {
ddd d = new ddd();
d.Add();
}
//My module
public int Add() {
int output=this.Stub1() + this.Stub2();
System.out.print("My module: return value is "+output+"\n");
return output;
}
//Stub1
public int Stub1() {
int output=3;
System.out.print("Stub 1 : return value is "+output+"\n");
return output;
}
//Stub2
public int Stub2() {
int output=7;
System.out.print("Stub 2 : return value is "+output+"\n");
return output;
}
}测试用例八大设计方法
测试方法分类：
- 黑盒测试 ：等价类划分 边界值分析 因果图分析 错误测试
- 白盒测试：语句覆盖 判定覆盖 条件覆盖 判定/条件覆盖 多重条件覆盖
等价类划分方法
等价类划分：指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，并合理地假定；测试某等价类的代表值就等于对这一类其它值的测试。因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据，取得较好的测试结果。
等价类划分可有两种不同的情况：有效等价类和无效等价类。
边界值分析方法
边界值：是对等价类划分方法的补充，测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。
错误推测方法
错误推测：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。
错误推测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。例如：在单元测试时曾列出的许多在模块中常见的错误。以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。
因果图方法
前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件,但未考虑输入条件之间的联系，相互组合等。考虑输入条件之间的相互组合，可能会产生一些新的情况。但要检查输入条件的组合不是一件容易的事情,即使把所有输入条件划分成等价类，他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图（逻辑模型）。因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。
判定表驱动分析方法
判定表：是分析和表达多逻辑条件下执行不同操作的情况的工具。
正交表设计分析方法
有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。
功能图分析方法
功能图：由状态迁移图和布尔函数组成，状态迁移图用状态和迁移来描述。一个状态指出数据输入的位置（或时间），而迁移则指明状态的改变。同时要依靠判定表或因果图表示的逻辑功能。
场景模拟分析方法
指根据用户场景来模拟用户的操作步骤,这个比较类似因果图,但是可能执行的深度和可行性更好。
今天分享就到这里了，更多软件测试基础知识我们下次再详谈吧。
下面是一份非常优质的学习资源，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！
以上软件测试资料需要的可以私信我都可以免费获取
这还有一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！，其中资料包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。
学习不要孤军奋战，最好是能抱团取暖，相互成就一起成长，群众效应的效果是非常强大的，大家一起学习，一起打卡，会更有学习动力，也更能坚持下去。
结语
欢迎留言，或是关注我的专栏和我交流。