软件测试（一）-CSDN博客

本文链接：https://blog.csdn.net/weixin_59055853/article/details/135439834

软件测试——测试用例

🏐测试用例要素（四个重要的要素）
🏐测试用例的设计方法
🏐测试分类
🏐什么是自动化测试
💬总结

👀先看这里👈
😀作者：江不平
📖博客：江不平的博客
📕学如逆水行舟，不进则退
🎉欢迎关注🔎点赞👍收藏⭐️留言📝
❀本人水平有限，如果发现有错误的地方希望可以告诉我，共同进步👍

🏐测试用例要素（四个重要的要素）

测试环境，操作步骤，测试数据，预期结果
测试用例有没有执行结果这个要素？
答：测试用例要素没有执行结果，因为执行结果需要执行完测试用例才能知道，没有测试用例就没有执行结果。
测试用例要花费不少时间，我们为什么还要写测试用例呢？
1）提高测试效率，节省测试时间
2）测试用例是自动化测试用例的前提

🏐测试用例的设计方法

有很多测试方法，我们先说基于需求的设计方法，

🏀基于需求的设计方法

在这里插入图片描述
这样的测试方法，需求以内的需求点测试到了，这些数据是无穷无尽的，怎么保证是没有问题的呢？
如何基于需求设计测试用例
基于需求的测试方法是一个大概的测试方法，具体的看下面几个

🏀等价类

概念：将输入数据集合划分成许多类别，测试的时候，从每一类中抽取一个测试点，如果测试通过，此时就代表这一类测试通过

有效等价类：满足用户需求的输入集合
无效等价类：不满足用户需求的输入集合

等价类思想设计测试用例步骤

充分理解需求
划分等价有效类，划分无效等价类
从有效等价类中抽取其中一个数据进行测试用例设计；从无效等价类中抽取一个进行测试用例设计

🏀边界值

有了等价类这个思想，为啥还要对边界进行测试呢？底层肯定会先去获取输入字符的长度吧
边界点
上点：边界上的点
内点：边界内的点
离点：边界值附近的一个点（闭区间区间外距离上点最近的一个点，开区间区间内距离上点最近的一个点）
以数轴为例
在这里插入图片描述
此图为闭区间，
上点：3，12
内点：6
离点：2，13

此图为左开右闭区间，
上点：3，12
内点：6
离点：4，13

边界值设计测试用例步骤

充分理解需求
找边界点
针对边界点设计测试用例

经常将等价类和边界值一起使用，比如

🏀判定表

判定表(Decision table)是另一种表达逻辑判断的工具。
关系

与：所有条件必须满足，如果有一个条件不满足，结果为假
或：满足其中一个条件，结果为真，如果条件全部为假，结果就为假
恒等：条件为真，结果一定为真
非：条件为假，结果才为真

如何设计测试用例

分析所有可能的输入和可能的输出
找出输入与输出的对应关系
设计判定表
把判定表对应到每一个测试用例

🏀正交表法

在设计时如果说遇到的条件非常多，若还是一个一个去想就太复杂了，这个时候就需要正交表了
什么是一个正交表？
在这里插入图片描述

（来自百度百科，详情点击正交表）
名词解释：

因素：变量
水平：变量取值

性质

每一列中各数字出现的次数都一样多
任何两列中的各有序数对出现的次数都一样多

如何通过正交表设计测试用例

充分理解需求
确定因素水平
画正交表
补充正交表
将正交表转换成测试用例

🏀场景设计法

🏀错误猜测法

测试人员经验

测试用例设计万能公式
功能，界面，性能，易用，兼容，安全，网络，中断……
功能：

物体：这个物体用来干嘛的
软件：软件实现功能

界面

物体：外表，材质，大小，容量
软件：字体大小，字体颜色，页面布局

易用

经验（操作简单，使用流畅）
人性化

兼容

物体：除了本质功能，是否具有其他功能
软件：操作系统，浏览器版本，设备

性能

物体：使用寿命
软件：吞吐量，并发数，响应时间，CPU占用率

安全

物体：材质是否有毒，对人体健康是否有害
软件：sql注入，xss漏洞，密码加密保存，密码加密传输，权限控制

网络

弱网，2G~4G，WIFI

🏐测试分类

🏀按照测试对象划分

⚽界面测试

用户和软件进行交互的时候，通常都是通过界面和软件来进行交互的
测试界面的时候，参考软件规格说明书，UI设计稿

⚽可用性测试

可靠性=正常运行时间/（正常运行时间+非正常运行时间）*100%
比例越高，说明软件可靠性越高

⚽容错性测试

容错性测试是指系统能够处理异常，用户的错误操作而不至于系统崩溃，从而能够提高系统的可用性。
分为两种

灾难恢复性测试。通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失，系统和数据是否能尽快恢复。
如果服务崩溃，大部分情况重启大法。
输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好，系统只给出提示或内部消化掉，而不会导致系统出错甚至崩溃。
比如数据级测试，校验测试，环境容错性测试，界面容错性测试
例子：Java中设计一个除法计算器，让分母等于0，此时就会触发一个异常，捕获异常
界面容错性例子比如在网址处搜索某个官网，后面不小心加了1111，tttt这样的字符，仍然可以进入到该官网。

⚽文档测试

可分为三大类

开发文件：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。
用户文件：用户手册、操作手册，用户文档的作用：改善易安装性；改善软件的易学性与易用性；改善软件可靠性；降低技术支持成本。
管理文件：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。

平常我们接触比较多的是测试文件，开发文件，产品文件
测试文件是什么呢？总结了许许多多的测试技巧，测试方法。

⚽兼容性测试

这个非常重要，兼容性测试需求是指明确要测试的兼容环境，考虑软，硬件的兼容，就软件兼容来说，主要考虑以下几个方面：

系统自身版本的兼容，用户已有数据的兼容，数据兼容是重中之重，对用户来说，数据是最有价值的。
测试与应用环境的兼容性，比如操作系统，应用平台，浏览器的兼容
测试与第三方系统以及第三方数据的兼容性
例子：装了A软件（购物相关的），又装了B软件（购物相关的），同时运行，发现运行其中一个软件时，另一个不能运行。

⚽易用性测试

易用性在ISO25020标准中指容易发现，容易学习和容易使用。易用性包含七个要素：符合标准和规范，直观性，一致性，灵活性，舒适性，正确性和实用性。我们主要讨论以下几个方面

1.标准性和规范性
对于现有的软件运行平台，通常其UI标准已经不知不觉地被确立了，成为大家的共识。多数用户已经习惯并且接受了这些标准和规范，或者说已经认同了这些信息所代表的的含义。比如安装软件的界面的外观，在什么场合使用恰当的对话框等。
所以用户界面上的各中信息应该符合规范和习惯，否则用户使用起来会不舒适，并得不到用户的认可。
测试人员需要把与标准规范，习惯不一致的问题报告为缺陷
2.直观性
用户界面的直观性，要求软件功能特性易懂，清晰。用户界面布局合理，对操作的响应在用户的预期之中。比如数据统计结果用报表的形式（条形图，扇形图等）展示清晰直观；现在主流的很多搜索引擎和日历的设计也有直观性的特点；

⚽安装卸载测试

应用的安装和卸载在任何一款APP中都属于最基本功能。一旦出错，就属于优先级为紧要Critical的缺陷。主要需要考虑以下方面：

软件不同的安装和卸载方式；例：应用市场；下载apk包；技术脚本/命令也可以下载或者卸载
应用是否可以在不同的环系统，版本下安装（安装兼容性）
安装或者卸载过程中是否可以手动暂停，或者取消
安装空不足的时候系统是否有提示
是否可以正常的卸载，以及应用软件的各种卸载方式
卸载和安装过程中出现环境问题，软件是否可以正常并且合理的应对，比如死机，断电，断网等

⚽安全测试

安全性是指信息安全，是指计算机系统或网络保护用户数据隐私，完整，保护数据正常传输和抵御黑客，病毒攻击的能力。安全性测试属于非功能性测试很重要的一个方面，系统常见的安全漏洞和威胁如下

输入域，如输入恶性或者带有病毒的脚本或长字符串；
代码中的安全性问题，如SQL/XML注入
不安全的数据存储或者传递
数据文件，邮件文件，系统配置文件等里面有危害系统的信息或者数据；
有问题的访问控制，权限分配等
假冒ID：身份欺骗篡改，对数据的恶意修改，破坏数据的完整性

⚽性能测试

我们在使用软件的时候有时会碰到软件网页打开时越来越慢，查询数据时很长时间才显示列表，软件运行越来越慢等问题，这些问题都是系统的性能问题引起的。
要进行软件产品的性能问题，要对产品的性能需求进行分析，然后基于系统的性能需求和系统架构，完成性能测试的设计和执行，最后要进行持续的性能调优。常见的性能问题如下：

资源泄露
资源瓶颈，比如带宽，网络的上限下限出现了瓶颈
线程死锁，线程阻塞
查询速度慢或效率低
受外部系统影响越来越大（理解：随着业务越来越复杂，如A软件要调B软件，B软件要调C软件，C软件要调D软件，然后再一个一个返回结果。这时如果出现问题，排查起来就麻烦很多。）

衡量一个系统性能好坏的关键性指标有，用户响时间，事务平均响应时间（TPS），吞吐率，每秒点击次数，内存和CPU使用率等。

用户响应时间，影响因素比如电脑配置，服务器的查询速度慢，是不是要考虑缓存等等
事务的四大特性：原子性，一致性，隔离性，持久性

⚽内存泄漏测试

很多软件系统都存在内存泄露的问题，尤其是缺乏自动垃圾回收机制的“非托管”语言编写的程序，例如C、CH、Delphi等。从用户使用的角度来看，内存泄露本身不会造成什么危害，一般用户可能根本不会感觉到内存泄露的存在。但是内存泄露是会累积的，只要执行的次数足够多，最终会耗尽所有可用内存，使软件的执行越来越慢，最后停止响应。可以把这种软件的问题比喻成软件的“慢性病”。
造成内存泄露的原因有很多，最常见的有以下几种。

分配出去的内存忘记回收。
程序写法有问题，造成没办法回收（如死循环造成无法执行到回收步骤）。
某些API函数的使用不正确，造成内存泄露。

内存泄漏的检测方法

人工静态法：代码走读，人工查找未被回收的内存。
自动工具法：借助相应测试内存泄漏的工具，如Visual Leak Detector，记录每次内存分配，清楚告诉用户内存是如何泄漏的。

比较推荐人工静态法，工具虽有好处，但是工具是人写的，可能出错。

🏀按照是否查看代码划分

⚽黑盒测试

什么是黑盒测试？
黑盒测试就是在完全不考虑程序逻辑和内部结构的情况下，检查系统功能是否按照需求规格说明书的规定正常使用、是否能适当的接收输入数据而输出正确的结果，满足规范需求。
所以，黑盒测试又称之为数据驱动测试，只注重软件的功能。
黑盒测试的优点：

不需要了解程序内部的代码以及实现，不关注软件内部的实现。（对于测试人员的代码能力要求不高）
从用户角度出发设计测试用例，很容易的知道用户会用到哪些功能，会遇到哪些问题，锻炼测试人员的产品思维（对产品思维，发散思维要求高）
测试用例是基于软件需求开发文档，不容易遗漏软件需求文档中需要测试的功能。

黑盒测试的缺点是不可能覆盖所有代码，代码覆盖率低。

那是不是就说黑盒测试就不好呢，这要看现在的业务是处于什么样的类型，一个功能都没有稳定下来，就没有必要进行白盒测试，如果一个功能已经稳定，只是迭代的时候需要技术方面的改进，再考虑白盒测试。

⚽白盒测试

白盒测试又称为结构测试或逻辑测试，它一般用来分析程序的内部结构，针对程序的逻辑结构来设计测试用例进行测试。
白盒测试的测试目的是，通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。
主要包含六种测试方法：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。
白盒测试优点：白盒测试关注的是代码逻辑，代码覆盖率比较高
缺点：对业务功能有一定漏洞，业务功能覆盖较低。

⚽灰盒测试

灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。

🏀按照开发阶段划分

测试金字塔
在这里插入图片描述
越往上越接近用户，界面排查成本高
一般先去看接口，看看是前端渲染写死的数据，还是后端的数据导致的，通常是服务器获取的数据，就要去看是哪个接口获取数据出现了问题，此时是服务端出现问题，我们就要去排查接口的问题，而又是由一个个单元组成的，所以又要往下去排查。单元就是我们的类，我们的方法啊

⚽单元测试

单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：模块。又称为模块测试
测试阶段：编码后或者编码前（TDD）
测试对象：最小模块（在Java中是一个一个类方法，C语言中函数
测试人员：白盒测试工程师或开发工程师
测试依据：代码和注释+详细设计文档
测试方法：白盒测试
测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
Java中如何进行单元测试？Junit；TestNG

⚽集成测试

集成测试也称联合测试（联调）、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确。

测试阶段：一般单元测试之后进行
测试对象：模块间的接口
测试人员：白盒测试工程师或开发工程师
测试依据：单元测试的模块+概要设计文档
测试方法：黑盒测试与白盒测试相结合
测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响

⚽系统测试

将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。

测试阶段：集成测试通过之后
测试对象：整个系统（软、硬件）
测试人员：黑盒测试工程师
测试依据：需求规格说明文档
测试方法：黑盒测试
测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等

⚽回归测试

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。随着系统的庞大，回归测试的成本越来越大，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。可以考虑自动化测试，节省成本。

⚽冒烟测试

冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件主要功能和核心流程正常，在正式进行系统测试之前执行。冒烟测试一般在开发人员开发完毕后提交给测试人员来进行测试时，先进行冒烟测试，保证基本功能正常，不阻碍后续的测试。
如果冒烟测试通过，则测试人员开始进行正式的系统测试，如果不通过，则测试人员可以让开发人员重新修复代码直到冒烟测试通过，再开始进行系统测试。
回归测试和冒烟测试都属于系统测试。
需求测试讲解——>梳理测试点——>评审测试用例——>测试——>项目上线
测试环节中，先去执行冒烟测试用例，如果测试通过，此时进入正式测试，如果测试不通过，此时测试停止