软件测试流程、方法、原则
一、软件测试流程（5点）：
制定测试计划->测试设计->测试开发->测试执行->评估测试
软件测试阶段：
- 1、单元测试，又称为模块测试。对软件的组成单位进行测试，其目的是检验软件基本组成单位的正确性。
测试阶段：编码后或者编码前
测试对象：模块（软件测试的最小单位）
测试人员：白盒测试工程师或开发人员
测试依据：代码和注释+详细文档
测试方法：白盒测试
测试内容：模块接口测试、局部数据测试、路径测试、错误处理测试、边界测试
补充说明：
（1）学习测试依据时，我们可以对比软件测试的“V”模型结合记忆
（2）白盒测试不是单元测试，单元测试是白盒测试
（3）测试驱动开发：测试人员先编写测试用例，开发人员根据测试用例写程序
- 2、集成测试又称为组装测试或 联合测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。
测试阶段：一般是单元测试之后
测试对象：模块间的接口
测试人员：白盒测试工程师或开发工程师
测试依据：单元测试的文档+概要设计文档
测试方法：黑盒测试与白盒测试（灰盒测试）
测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能的正确性、全局数据结构、单模块缺陷对系统的影响
- 3、确认测试。确认测试的目标是验证软件的功能和性能以及其他特性是否与用户的要求一致。确认测试一般包括有效性测试和软件配置复查。一般有第三方测试机构进行。
- 4、系统测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。包括回归测试和冒烟测试。
测试阶段：集成测试阶段之后
测试对象：整个系统（软件、硬件）
测试人员：黑盒测试工程师
测试依据：需求规格说明文档
测试方法：黑盒测试
测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等
补充说明：先冒烟、再系统、后回归。
（1）回归测试（Regression Testing）：指修改了旧的代码之后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。（自动回归测试将大幅度降低系统测试、维护升级等阶段的成本）。
在整个软件测试过程中占有很大的工作比重，软件开发的各个阶段都会进行多次回归测试。随着系统的庞大，回归测试的成本越来越大，通过正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。
（2）冒烟测试（smoke testing）：该术语来自硬件，指对一个硬件或一组硬件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试，也可以理解为该种测试耗时短，仅用一袋烟的功夫就足够了。
冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续正式的测试工作。
冒烟测试的执行者是版本编译人。
冒烟测试一般在开发人员开发完毕后送给测试人员来进行测试时，测试人员会先进行冒烟测试，保证基本功能正常，不阻碍后续测试。
- 5、验收测试（交付测试）以用户为主的测试，软件开发人员和质量保证人员参加，由用户设计测试用例。目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买都展示该软件系统满足原始需求。
测试阶段：系统测试通过后
测试对象：整个系统（包括软硬件）
测试人员：主要是最终用户或者需求方
测试依据：用户需求、验收标准
测试方法：黑盒测试
测试内容：同系统测试（功能、各类文档文档等）
例子：针对买回来的新手机以及它的美颜功能来进行测试。
（1）我们只针对美颜功能的代码进行测试，就是单元测试。
（2）检测手机通讯录是否可以增添、删除、更改手机号码，打电话时需要手动的输入电话，也可以在手机中查找，这就是集成测试。
（3）新手机都会有一个合格标签，原因是出厂前手机厂商会对某一个型号的手机功能全部测试一遍，包括手机硬件本身，手机自带的APP等，这个叫系统测试。
（4）当修好新买回来的手机的美颜功能以后，用户除了会查看美颜功能是否完好，还会查看其他功能是否也完好，这个叫回归测试。
（5）对于新买回来的手机，我们做的第一件事是将常用的手机功能试一遍，第二件事情就是讲所有功能都试一遍，这个叫冒烟测试。
（6）对于新买回来的手机，一般都有7天包退，30天包换，我们一般都是在7天内把手机的所有功能都试一遍，这叫验收测试。
软件测试分类：https://blog.csdn.net/cherrydreamsover/article/details/81385643
二、软件测试方法
黑盒测试方法：
1.等价类划分：把程序输入域分成若干部分，从每部分取少数具代表性数据作为测试用例。
2.边界值分析法: 是对输入或输出的边界值作为测试用例
3.错误推测法：基于经验/直觉推测程序中所有可能存在的错误，有针对性地设计测试用例。
4.因果图/判定表：利用图解分析输入输出的各种组合关系，写出判定表，设计相应的测试用例
5.正交试验设计：从大量的实验数据中挑选适量的、有代表性的点来设计测试用例
6.随机数法
白盒测试的测试方法有（按照强度由低到高）：
（1）语句覆盖：设计若干测试用例，运行被测程序，使得每一可执行语句至少执行一次。
（2）判定覆盖：使设计的测试用例保证程序中每个判断的每个取值分支至少经历一次。
（3）条件覆盖：选足够测试用例，使判定中每个条件的所有可能结果至少出现一次，未必覆盖全部分支
（4）判定条件覆盖：条件覆盖基础上，要求各个判断的所有可能的条件取值组合至少执行一次。
（5）条件组合覆盖：选足够测试用例，使所有判定中各条件判断结果的所有组合至少出现一次
（6）路径覆盖：是每条可能执行到的路径至少执行一次。
补充：
1.语句覆盖在所有的测试方法中是一种最弱的覆盖。
2.满足判定/条件覆盖标准的测试用例一定也满足判定覆盖、条件覆盖和语句覆盖
3.路径覆盖也是一种比较强的覆盖，但未必考虑判定条件结果的组合，并不能代替条件覆盖和条件组合覆盖。
三、软件测试原则（7点）：
一、测试显示软件存在缺陷（Testing shows presence of defects）
测试只能证明软件中存在缺陷，但并不能证明软件中不存在缺陷。软件测试是为了降低存在缺陷的可能性，即便是没有找到缺陷，也不能证明软件是完美的。
二、穷尽测试是不可能的（Exhaustive testing is impossible）
现在软件的规模越来越大，复杂度越来越高，想做到完全性的测试是不可能的。在测试阶段，测试人员可以根据风险和优先级来进行集中和高强度的测试，从而保证软件的质量。
三、测试尽早介入（Testing early）
为什么测试要尽早介入呢，简单的说就是保证软件质量，降低风险和成本。测试人员一般在需求阶段就开始介入，使缺陷在需求或设计阶段就被发现，缺陷发现越早，修复的成本就越小。
四、缺陷集群性，2/8原则（Defect clustering）
缺陷集群性表明小部分模块包含大部分的缺陷。软件测试中存在Pareto原则：80%的缺陷发现在20%的模块中。
一个功能模块发现的缺陷越高，那存在的未被发现的缺陷也越高，故发现的缺陷与未发现的缺陷成正比。
五、杀虫剂悖论（Pesticide Paradox）
反复使用相同的杀虫剂会导致害虫对杀虫剂产生免疫而无法杀死害虫。软件测试也一样。如果一直使用相同的测试方法或手段，可能无法发现新的bug。
为了解决这个问题，测试用例应当定期修订和评审，增加新的或不同的测试用例帮助发现更多的缺陷。
测试人员不能一直依赖于现有的测试技术，而要不断的提升测试方法以提高测试效率。
六、测试活动依赖于测试内容（Testing is context dependent）
根据业务的不同，软件测试内部也分为不同的行业，比如游戏行业、电商行业、金融行业。不同的行业，测试活动的开展都有所不同，比如测试技术、测试工具的选择，测试流程都不尽相同，所以软件测试的活动开展依赖于所测试的内容。
七、没有错误是好是谬论（Absence of error - fallacy）
有可能99%没有bug的软件也是不能使用的。如果对错误的需求进行了彻底的测试，这种情况就发生了。软件测试不仅是找出缺陷，同时也需要确认软件是否满足需求。如果开发出来的产品不满足用户的需求，即便找到和修复了缺陷也作用不大。