尽管没有统一的软件测试过程，但是有一些常见的测试活动，如果没有这些测试活动就不太可能实现既定的目标。这些测试活动就组成了一个测试过程。
在任何给定的情况下，适当的、特定的软件测试过程取决于很多因素。
测试过程中涉及哪些测试活动，如何实施这些测试活动，以及何时开始这些测试活动，都可以测试过程中涉及哪些测试活动，如何实施这些测试活动，以及何时开始这些测试活动，都可以在组织的测试策略中进行讨论。在组织的测试策略中进行讨论。

感兴趣的朋友可以去查一下测试过程、测试活动、测试策略的相关概念。

测试的过程并不是固定的，要灵活的变化

Boehm质量模型

Boehm模型着手于软件总体的功效，也就是说，对于一个软件系统而言，除了有用性以外，它的开发过程必定是一个时间，金钱和能量的消耗过程。考虑到系统交付时使用它的用户类型，Boehm模型从几个维来考虑软件的效用。

总功效可以被分解成可移植性，有效性，可维护性。

有效性可以细分为可靠性，效率，运行工程可维护性可以细分为测试性，可理解性，可修改性。

软件测试过程模型
V模型

开发活动和测试活动是对应的，并且是同等重要的.

优点

既有底层测试（单元测试）又有高层测试（系统测试）；

清楚的标识了开发和测试的各个阶段；

自上而下逐步求精，每个阶段分工明确，便于整体项目的把控，当所有阶段都结束时，软件开发就结束了。

缺点

由于它自上而下的顺序导致测试工作在编码后，正式进入测试时，这时发现的一些bug可能不容易找到其根源，不能及时的进行修改，并且代码修改起来很困难；

实际工作中，需求经常变化，导致V模型步骤反复执行，返工量很大，灵活度较低；

容易让人误解为测试是在开发完成之后的一个阶段。

W模型

优点

1.将测试贯穿到整个软件的生命周期中，且除了代码要测试，需求、设计等都要测试。

2.更早的介入到软件开发中，能尽早的发现缺陷进行修复。

3.测试与开发独立起来，并与开发并行。

缺点

1.对有些项目，开发过程中根本没有文档产生，故W模型无法使用。

2.对于需求和设计的测试技术要求很高，实践起来很困难。

H模型

特点

软件测试过程活动完全独立，贯穿于整个产品的周期，与其他流程并发地进行；

某个测试点准备就绪时，就可以从测试准备阶段进行到测试执行阶段;

软件测试可以尽早的进行;

软件测试可以根据被测物的不同而分层次进行；

H模型强调测试是独立的，只要测试准备完了，就可以执行测试了。
基本测试过程

要测试一个网站都需要进行哪些测试活动？

一、文档评审

1、测试需求分析（确定需要测试的功能性及非功能性需求）

需求文档是测试人员测试的唯一标准！

首先是 需求文档，

在系统开始开发之前，产品经理会根据收集到的用户意见和最终方案编写需求文档

编写完成后，要进行需求文档评审；

说是评审，实际上主要是需求讲解。

给开发们讲解业务知识、我们要做什么东西、为什么这么做、要做成什么样子。

从这个环节开始，测试人员就应该介入进来。

因为需求文档是测试人员测试的唯一标准！

将来做测试的时候，如果开发做出来的东西和需求文档里写的、画的不一样，都属于BUG！

如果开发说是需求改了或者说是产品经理说的，那么抱歉，请修改需求文档！

所以，严格来说，测试人员在测试时只认文档不认人。

可能有人会说，那这样测试人员就没必要参加评审了，直接等文档就行。

测试人员参加需求文档的评审的必要性：

测试人员也需要了解和学习相关的业务知识。
测试人员需要知道产品最终的上线目标是什么，来判断什么时候能达到交付的程度。
测试人员可以凭借经验对需求文档中的部分设计提出不同的意见。
测试人员可以凭借经验对需求文档中没有涉及到的一些异常情况和特殊场景进行讨论。

2、开发文档，

需求文档定型之后，开发经理会根据需求文档来编写开发文档。

开发文档的内容大概包括：开发模型、代码架构、代码规范、接口规范、数据库设计......

为什么测试要参加开发文档的评审？（其实主要是去听）

测试人员需要了解系统的基本架构和实现原理，方便分析问题原因
测试人员需要了解数据库表结构，对后续的测试很有必要
测试人员可以提出一些规范性的要求，便于后面的测试。（比如要求前端人员尽量给所有前端组件加上id或name属性，方便自动化测试时定位元素）
测试人员可以发现代码中缺少对某些异常场景的逻辑判断。

3、测试计划

测试计划是测试人员的工作量预估，也是将来测试人工作考核绩效的重要依据。

测试计划的内容包括：测试范围是什么、分为哪些阶段、什么时间点完成什么、测试的具体内容列表（流程、功能、接口）、测试资源的成本（人/天）等等。

测试计划是测试人员的工作守则和规范。

但是产品的诞生过程中，免不了出现各种各样的特殊情况，所以实际的测试可能会跟测试计划有所出入。

所以测试报告中需要写明与测试计划产生偏差的原因，并计算变差量，分析偏差的风险。

最终的测试过程和测试结果还是以测试报告为准。

二、单元测试（又称组件测试 component testing）

单元测试其实在平时比较少做，并不是因为它不重要，因为单元测试就是代码级别的测试

组件测试（也称为单元或模块测试）关注在可单独测试的组件。组件测试的目标包括：
 降低风险
 验证组件的功能和非功能行为是否符合设计和规定
 建立对组件质量的信心
 发现组件中的缺陷
 防止缺陷遗漏到更高的测试级别

简单的举个例子，现在开发做了一个新增的方法

单元测试就是要写一个测试类或测试方法，调用开发的新增方法（新增肯定还要传值），并且在调用过程中模拟一些异常情况或者传输错误的值

所以单元测试一般由开发人员来完成，

测试人员也可以去做，但是首先测试人员需要有一定的编码能力并搭建开发环境，其次测试人员需要去理解和分析开发的相关代码，甚至是要了解和学习相关架构

现在成熟的开发框架已经自带的很多测试的组件和工具，以Springboot为例，

可以直接导入测试依赖包

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-test</artifactId>
    <scope>test</scope>
</dependency>

使用idea自动创建测试类,也可以自己手动创建

写测试类

@RunWith(SpringRunner.class)
@SpringBootTest
public class TestImpl2Test {
     @Autowired
     @Qualifier("testImpl2")
     ITestServer iTestServer;
    @Test
     public void test(){
         iTestServer.showClassName();
     }
}

综上所述，由开发人员来进行单元测试，要更加便捷和高效，更节约成本，几乎是 举手之劳

而且能培养开发自测的良好习惯，关注代码质量的重要性

三、敏捷测试(Agile testing)（可选）

在开发人员进行开发的这个阶段，测试人员无法对产品直接进行测试，工作任务较轻

可以安排测试人员进行测试用例的编写。

对于一些紧急的项目，可以引进敏捷测试。

敏捷测试是最近几年比较流行的测试方法，也拥有了众多的拥护者。

还引出了一个测试思想——测试驱动开发（TDD ）

这个概念有时间我单拎出来写。

敏捷测试的最大特点是高频率的快速迭代，几乎是一天一个迭代版本，甚至是一天多个版本。

敏捷测试是遵循敏捷宣言的一种测试实践：
1、强调从客户的角度，即从使用系统的用户角度，来测试系统。
2、重点关注持续迭代地测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。
3、建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。

这种高频率的迭代测试，可以极大地提升产品成型的速度，bug能在最短时间内被处理。

这种测试非常考验测试人员的抗压、责任心、领导力和沟通协调能力。

但是敏捷测试也有很多的缺点，

在这里我只谈自己的感受，如果有不对的地方可以留言和我讨论：

测试人员工作压力大，休息时间少，几乎没有喘息的时间。
不同版本的bug管理比较混乱，验证起来需要梳理清楚，最好是借助专业的管理工具。
bug反复性高，可能在短时间内甚至不会出现bug逐步下降的正常趋势，而是产生较大的波动。
开发无法按照bug等级来确定工作优先级，因为可能在改一个中等bug，突然来了严重bug，也得等上一个bug改完的。
需求改动频繁，可能昨天做的功能或者做一半的功能突然就舍弃掉了

所以我们正常的测试中一般不会去做敏捷测试，但是有些公司比较推崇

四、集成测试（integration testing）、系统测试（system testing）

集成测试的重点就是测试各模块的接口，也就是组件或系统之间的交互。

集成测试侧重于集成测试的目标包括：
 减少风险
 验证接口的功能和非功能行为是否符合设计和规定
 建立对接口质量的信心
 发现缺陷（可能存在于接口本身，也可能存在于组件或系统内部
 防止缺陷遗漏到更高的测试级别

与组件测试一样，在某些情况下，自动化集成的回归测试可以增强信心，因为即使产品有变更

也不会破坏已有的接口、组件或系统。

系统测试侧重于整个系统或产品的行为和能力，通常会考虑系统可开展的端到端任务和开展这些任务时所展现的非功能行为。

系统测试的目标包括：
 减少风险
 验证系统的功能和非功能行为是否按照设计和指定的要求进行验证系统的功能和非功能行为是否按照设计和指定的要求进行
 确认已完成系统成且系统按预期工作确认已完成系统成且系统按预期工作
 建立对整个系统质量的信心建立对整个系统质量的信心
 发现缺陷发现缺陷
 防止缺陷遗漏到更高的测试级别或生产防止缺陷遗漏到更高的测试级别或生产

一般情况下，系统测试的测试环境应该与集成测试的相同。

我为什么把集成测试和系统测试放在一起，因为我们在做测试的时候，经常是集成测试和系统测试同时进行。

集成测试意味着开发已经完成所有模块的开发，并且对产品有了一定的信心。

所以我们通常是直接进行集成和系统测试，也就是全用例、全流程、全功能、全接口的测试

测试环境由测试人员进行搭建，尽量与生产环境一致。

测试期间测试环境不允许开发人员访问，直到一轮测试结束。

一轮结束后会将测试环境包括数据库移交给开发，用来复现相关问题，并查找问题原因。

开发提交新一轮测试后，测试人员重新搭建环境进行测试。

五、验收测试（acceptance testing）

验收测试通常侧重于整个系统或产品的行为和功能。

验收测试通常是由客户、业务用户、产品负责人或系统操作员负责，也可能涉及其他利益相关方

验收测试的目标包括：
 建立对整个系统质量的信心
 确认系统是否完整且系统将按预期工作
 验证系统的功能和非功能行为符合规范

六、其他（确认测试、回归测试）

确认测试：修复缺陷后，应该在软件的最新版本上，重新执行之前因该缺陷而导致失败的测试用例。为了覆盖修复缺陷所需的变化，也可以使用新的测试来测试软件。至少必须在新的软件版本上重新执行这些由缺陷引起失效的步骤。

确认测试的目的是确认是否已成功修复原来的缺陷。

回归测试： 部分代码所做的变更，无论是修复代码，还是其他类型的更改，都可能会意外地影响到除更改代码外的其他部分代码的行为，不管是在同一组件内，还是在同一系统的其他组件中，甚至在其他系统中。变更也可能包括环境的变化，例如操作系统或数据库管理系统的新版本。这种意外的副作用被称为回归。

回归测试的目的是运行测试来检测这些意外的副作用。

七、技术类测（自动化测试、性能测试、接口测试）

自动化测试我会单独写文章讲。

性能测试是非功能测试的一种。

可以看我的另外两篇文章

非功能性测试包括：易用性测试、性能测试、安全性测试、稳定性测试等等。

接口测试一般是用postman。

要测试一个网站都需要进行哪些测试活动？

——测试需求分析（确定需要测试的功能性及非功能性需求）

——测试计划（确定测试范围、人员、时间点、结束标准等）

——测试设计（撰写测试用例，准备测试数据）

——测试执行

——缺陷跟踪

——测试总结

本文来自软件测试的完整流程/过程（原创） - 知乎 (zhihu.com)
外加自己对于一些知识的整理

信创技术联盟

领路信创诚邀您共建高质量内容社区，投稿申请~

更多推荐

花非花，物非物，AI岂是池中物(人工智能篇)

转载请标明出处：http://blog.csdn.net/DJY1992/article/details/74979436本文出自:【奥特曼超人的博客】AI（Artificial Intelligence），即人工智能。人工智能领域的研究包括机器人、语音识别、图像识别、自然语言处理和专家系统等。人工智能从诞生以来，理论和技术日益成熟，应用领域也不断扩大所谓的人工智能，是可以对人的意识、思维的