【N年测试总结】测试的分类

继学先生

于 2023-08-23 23:45:00 发布

阅读量134

点赞数

分类专栏：测试文章标签：测试类型测试分类

本文链接：https://blog.csdn.net/liao152/article/details/132425835

版权

测试专栏收录该内容

3 篇文章 0 订阅

订阅专栏

一、概述

测试的分类一般有按照测试的内容进行划分和按照测试阶段划分两种大的方式。

按测试内容划分

1、需求测试
2、单元测试
3、接口测试
4、功能测试
5、UI自动化测试
6、性能测试
7、测试开发

按测试阶段划分

1、需求测试
2、单元测试
3、集成测试
4、系统测试
5、验收测试
6、回归测试

其他分类

1、α测试
2、β测试
3、λ测试

二、按测试内容划分

1、需求测试

需求测试，对于测试人员来说其实包含了两个阶段，分别是需求分析及需求评审阶段，另一个阶段就是需求分析并编写用例阶段。在需求评审会上，其实除了正式的测试人员，参会的所有人都是测试，对需求的完整性、正确性、一致性、可行性、无二义性、健壮性、必要性、可测试性、可修改性、可跟踪性进行测试（评审）。

完整性（重要）：每一项需求都必须将所要实现的功能描述清楚，以使测试人员获得测试所需信息和开发人员获得设计和实现这些功能所需的所有必要信息。
正确性（重要）：每一项需求都必须准确地陈述其要开发的功能，需求没有公式、业务、逻辑上的错误。
一致性：一致性是指与其它软件需求或相关标准规定不相矛盾。
可行性（重要）：需求在现有的系统和环境的限制范围内是可以实施的。
无二义性：对所有需求说明都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的语言表达出来，同一功能用同一术语表达。
健壮性（重要）：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。
*必要性：每项需求的制定都是必要的且能够追溯的。
*可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。
*可修改性：每项需求只应在软件需求说明书中出现一次，这样更改时易于保持一致性。
*可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接，这种可跟踪性要求每项需求以一种结构化的方式编写并单独标明。

需求测试对测试人员的能力要求比较高，尤其是正确性和可行性，正确性要求测试具备相关的业务知识，可行性要求测试具备一定的开发知识。

一般需求评审会上，由于时间有限，并不能对需求进行深入的分析，深入的分析往往会后移到测试人员编写用例阶段和开发人员开发阶段，更深入细致的问题才能发现。不论在哪个阶段，运用上面的框架进行需求测试，基本能够发现需求中百分之八十的问题。问题发现的越早，解决的成本越低。

单元测试

对软件中的最小可测试单元进行检查和验证。至于“单元”的大小或范围，并没有一个明确的标准，“单元”可以是一个函数、方法、类、功能模块或者子系统。
单元测试的一个重要的衡量标准就是代码覆盖率，尽量做到代码的全覆盖。常见单元测试覆盖标准：

语句覆盖
分支覆盖
条件覆盖
分支-条件覆盖
条件组合覆盖
路径覆盖

由于单元测试在国内的环境下，很少有公司的测试能做到，大部分都是研发自己做了，都是理想很丰满，现实不允许，所以这里也就不多介绍了。

接口测试

接口测试就是对后端研发提供的接口进行测试。接口测试第一阶段可以使用Postman进行单接口的连通性和主要入参的简单测试，第二阶段就可以使用接口自动化代码项目进行接口测试了。接口测试的内容主要如下图所示，优先级从上往下，如果业务有需要或侧重点要求不同，可以调整编写接口用例时主要测试点的优先级。
在这里插入图片描述
由于有些接口入参非常多，排列组合可能有成千上万种情况，所以需要测试人员对接口用例的编写根据优先级进行选择测试。优先级的判断参考如下：
１、需求文档要求校验字段有较高优先级
２、需求文档要求必填字段有较高优先级
３、影响金额的数据参数
４、日期参数

接口自动化测试是自动化测试中应用最广泛的自动化测试，它的适用场景限制比UI自动化测试少很多，所以一般首先建设接口自动化测试，再建设UI自动化测试。接口自动化测试项目可以使用python+pytest+allure的技术栈。

功能测试

功能测试是测试入门的第一个测试内容，也是测试最基础的工作。按照需求文档或者测试用例，对完成的功能软件进行人工的点击和使用操作，发现软件的问题。功能测试主要考虑一下内容：

功能：需求文档所描述的功能是否都已经正确实现
界面：需求功能是否符合UI设计、是否合理、美观
兼容性：需求功能是否可以在多个不同的系统平台上正确运行
安全性：需求功能是否有安全漏洞方面的问题
稳定性：弱网断网、高并发访问、高温低温等场景下，是否能稳定运行
易用性：功能是否符合使用习惯，方便容易使用

UI自动化测试

UI自动化测试就是使用工具或者脚本对需要测试的软件的前端界面在预设的条件下和已给的测试数据下运行系统或者应用程序，并获取其前端页面显示的数据结果进行校验，评估得出测试结论。UI自动化测试的使用所受限制会比较多，一般要考虑以下情况：
1、需求不能频繁变动（主要）
2、UI稳定（UI自动化就是基于UI层面的，UI界面总变化无法开展）
3、项目周期长（UI自动化脚本编写和调试耗时，项目周期短纯手工更高效）
4、回归测试频繁

UI自动化测试其实不是很难，实践中最困难的是对UI自动化代码脚本的维护，是比较费时费力的。

性能测试

性能测试就是是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。
并发测试是性能测试的重点，性能测试操作起来不是很难，难的是对性能指标的分析。工具有LoadRunner、Jmeter等，一般只有大公司用户量在十万级别以上的公司才有可能做性能测试，小公司和非抢购活动性质的需求，基本不会做性能测试，好的测试工具也都是收费的。

测试开发

测试开发具体还可以分为：自动化测试，性能压测，平台研发，白盒测试，工具研发等，跟代码相关的都可以定义为测试开发。包含了上面的一些跟代码相关的测试类型，这里单独列出来，主要还是因为测试开发这里主要指的是测试平台开发和测试工具开发。
测试平台和工具的开发主要是在公司的测试部门或业务发展到一定的阶段，有大量的固定的测试的流程或者操作需要管理，或者是为了部分功能测试人员服务，提高测试效率而研发的平台和工具。其实从本质上讲，测试平台和工具的开发，已经不是传统的测试了，而是开发，但是是测试部门自己的开发所以还是归为测试的一类。