转载:应该考虑进行何种测试

本文全面介绍了软件测试的各种类型,包括但不限于黑盒测试、白盒测试、功能测试等,并详细解释了每种测试的目的和实施方式。

收藏于 2010-04-11 来自于百度空间
黑盒测试(Black box testing) ____不考虑内部设计和代码,根据需求和功能进行测试

白盒测试 (White box testing) ── 根据应用软件的代码的内部逻辑,按照代码的语句、分支、路径和条件进行测试。

部件测试 (Unit testing) --最小范围的测试,针对特定的函数和代码模块进行测试。因为需要了解程序的设计和代码的细节才能进行,所以部件测试一般是程序员。而不是由测试人员来做。除非应用软件的结构设计良好,而且代码也写得清楚,否则部件测试并非易事。也许需要开发测试驱动模块或测试工具。

递增的综合测试(incremental integration testing)--不断进行的测试过程,每增加一个新的功能模块,都进行测试。这要求一个应用软件在最终完成之前,各功能模块要相对独立,或者已根据需要开发出测试驱动软件。这种测试可由程序员或测试人员进行。

综合测试(integration testing)--对应用软件的各个部分进行组合测试,来检查各功能模块在一起工作是否正常,“部件“可以是代码模块、独立的应用程序、也可以是网络中的客户/服务器应用软件。这种测试特别使用客户/服务器环境和分布式系统

功能测试(functional testing)--对一个应用软件的功能模块进行黑盒测试。这种测试应当由测试人员进行。但这并不意味着程序员在推出软件之前不进行代码检查。(这一原则适用于所有的测试阶段。)

系统测试 -- 针对全部需求说明进行黑盒测试,包括系统中所有的部件

端到端测试 (end-to-end testing) ── 类似于系统测试,但测试范围更“宏观”一些。模仿实际应用环境,对整个应用软件进行使用测试。例如与数据库进行交互作业、使用网络通信、与其他硬件、应用程序和系统之间的相互作用是否满足要求。

健全测试 (sanity testing) ── 是一种典型的初始测试。判断一个新的软件版本的运行是否正常,是否值得对它作进一步的测试。例如,如果一个新的软件每 5 分钟就破坏系统、大大降低系统的运行速度、或者破坏数据库,那么这样的软件就算不上是“健全”的,不值得在目前状态下进行进一步的测试。

回归测试 (regression testing) ── 每当软件经过了整理、修改、或者其环境发生变化,都重复进行测试。很难说需要进行多少次回归测试,特别是是到了开发周期的最后阶段。进行此种测试,特别适于使用自动测试工具。

认同测试 (acceptance testing) ── 基于说明书的、由最终用户或顾客来进行的测试。或者由最终用户/顾客来进行一段有限时间的使用。

负荷试验 (load testing) ── 在大负荷条件下对应用软件进行测试。例如测试一个网站在不同负荷情况下的状况,以确定在什么情况下系统响应速度下降或是出现故障。

压力测试 (stress testing) ── 经常可以与“负荷测试”或“性能测试”相互代替。这种测试是用来检查系统在下列条件下的情况:在非正常的巨大负荷下、某些动作和输入大量重复、输入大数、对数据库进行非常复杂的查询,等等。

性能测试 (performance testing) ── 经常可以与“压力测试”或“负荷测试”相互代替。理想的“性能测试”(也包括其他任何类型的测试) 都应在质量保障和测试计划的文档终予以规定。

可用性测试 (usability testing) ── 是专为“对用户友好”的特性进行测试。这是一种主观的感觉,取决于最终用户或顾客。可以进行用户会见、检查、对用户会议录像、或者使用其他技术。程序员和测试人员通常不参加可用性测试。

安装/卸载测试 (install/uninstall testing) ── 对安装/卸载进行测试 (包括全部、部分、升级操作)。

恢复测试 (recovery testing) ── 在系统崩溃、硬件故障、或者其他灾难发生之后,重新恢复系统的情况。

安全测试 (security testing) ── 测试系统在应付非授权的内部/外部访问、故意的损坏时的防护情况。这需要精密复杂的测试技术。

兼容性测试 (compatability testing) ── 测试在特殊的硬件/软件/操作系统/网络环境下的软件表现。

认同测试 (acceptance testing) ── 看顾客是否对软件满意。

比较测试 (comparison testing) ── 与竞争产品进行比较,以找出弱点和优势。

α 测试 (alpha testing) ── 在开发一个应用软件即将完成时所进行的测试。此时还允许有较小的设计修改。通常由最终用户或其他人进行这种测试,而不是由程序员和测试人员来进行。

β 测试 (beta testing) ── 当开发和测试已基本完成,需要在正式发行之前最后寻找毛病而进行的测试。通常由最终用户或其他人进行这种测试,而不是由程序员和测试人员来进行。

航拍图像多类别实例分割数据集 一、基础信息 • 数据集名称:航拍图像多类别实例分割数据集 • 图片数量: 训练集:1283张图片 验证集:416张图片 总计:1699张航拍图片 • 训练集:1283张图片 • 验证集:416张图片 • 总计:1699张航拍图片 • 分类类别: 桥梁(Bridge) 田径场(GroundTrackField) 港口(Harbor) 直升机(Helicopter) 大型车辆(LargeVehicle) 环岛(Roundabout) 小型车辆(SmallVehicle) 足球场(Soccerballfield) 游泳池(Swimmingpool) 棒球场(baseballdiamond) 篮球场(basketballcourt) 飞机(plane) 船只(ship) 储罐(storagetank) 网球场(tennis_court) • 桥梁(Bridge) • 田径场(GroundTrackField) • 港口(Harbor) • 直升机(Helicopter) • 大型车辆(LargeVehicle) • 环岛(Roundabout) • 小型车辆(SmallVehicle) • 足球场(Soccerballfield) • 游泳池(Swimmingpool) • 棒球场(baseballdiamond) • 篮球场(basketballcourt) • 飞机(plane) • 船只(ship) • 储罐(storagetank) • 网球场(tennis_court) • 标注格式:YOLO格式,包含实例分割的多边形坐标,适用于实例分割任务。 • 数据格式:航拍图像数据。 二、适用场景 • 航拍图像分析系统开发:数据集支持实例分割任务,帮助构建能够自动识别和分割航拍图像中各种物体的AI模型,用于地理信息系统、环境监测等。 • 城市
<think> 我们面对的问题是:在统信系统(或其他基于RHEL的Linux发行版)中安装glibc-compat-2.17时出现“Unable to find a match: glibc-compat-2.17”的错误。这通常是因为软件包名称不匹配或仓库中不存在该包。下面我们将提供几种解决方案。 ### 1. 检查软件包实际名称 在统信系统中,软件包名称可能与CentOS/RHEL不同。我们可以尝试搜索兼容包的名称: ```bash sudo dnf search compat-glibc sudo dnf search glibc-legacy sudo dnf list | grep -i glibc.*compat ``` ### 2. 添加EPEL仓库 EPEL(Extra Packages for Enterprise Linux)仓库提供了许多额外的软件包,包括一些兼容包。我们可以安装EPEL仓库并再次尝试安装: ```bash # 安装EPEL仓库 sudo dnf install epel-release # 更新缓存 sudo dnf makecache # 再次尝试安装 sudo dnf install compat-glibc ``` 如果找不到`compat-glibc`,也可以尝试搜索其他名称,如`glibc-legacy`等。 ### 3. 手动下载安装包 如果仓库中没有,我们可以尝试从其他来源手动下载安装包。例如,从CentOS 7的仓库中下载,因为CentOS 7默认使用glibc 2.17。 ```bash # 下载glibc 2.17的RPM包(注意:需要根据系统架构选择,这里以x86_64为例) wget http://mirror.centos.org/centos/7/os/x86_64/Packages/glibc-2.17-317.el7.x86_64.rpm # 安装依赖(根据引用[2][3]提到的依赖) sudo dnf install elfutils-libelf-devel binutils-devel # 强制安装(注意:强制安装可能会引起依赖冲突,谨慎操作) sudo rpm -ivh --nodeps glibc-2.17-317.el7.x86_64.rpm ``` **注意**:强制安装可能会破坏系统稳定性,建议在测试环境中进行,或者使用容器方案。 ### 4. 容器化解决方案(推荐) 为了避免直接修改系统环境,我们可以使用容器(如Docker或Podman)来运行需要glibc 2.17的用程序。这样不会影响宿主机的glibc版本。 ```bash # 使用Podman(或Docker)创建一个CentOS 7容器 sudo podman run -itd --name glibc_env \ -v /path/to/your/app:/app:Z \ docker.io/library/centos:7 # 在容器内执行程序 sudo podman exec -it glibc_env /app/your_program ``` 这样,用程序将在CentOS 7容器中运行,该容器自带glibc 2.17。 ### 5. 源码编译GLIBC 2.17 如果以上方法都不适用,我们可以考虑从源码编译glibc 2.17,并将其安装到独立目录,以避免替换系统glibc。 ```bash # 下载glibc 2.17源码 wget http://ftp.gnu.org/gnu/glibc/glibc-2.17.tar.gz # 解压并进入编译目录 tar xvf glibc-2.17.tar.gz mkdir glibc-build && cd glibc-build ../glibc-2.17/configure --prefix=/opt/glibc-2.17 make -j$(nproc) sudo make install # 使用独立目录的glibc运行程序 LD_LIBRARY_PATH=/opt/glibc-2.17/lib:/usr/lib64 ./your_program ``` ### 关键注意事项 1. **兼容性风险**:直接安装旧版glibc到系统目录可能导致系统不稳定,甚至系统崩溃[^1]。 2. **容器方案优先**:推荐使用容器方案,因为它隔离了环境,不影响宿主机。 3. **静态编译**:如果可能,重新编译用程序为静态链接,避免动态链接glibc。 ```bash gcc -static -o program_static program.c ``` 4. **32位支持**:如果是32位程序,需要安装32位兼容库: ```bash sudo dnf install glibc.i686 ``` ### 错误排查 - **依赖冲突**:如果强制安装后出现依赖冲突,可能需要使用`--nodeps`,但需谨慎。 - **文件冲突**:如果系统已有更高版本的glibc,安装到独立目录(如`/opt`)是更好的选择。 - **符号链接问题**:手动创建软链接(谨慎操作): ```bash sudo ln -s /opt/glibc-2.17/lib/libc.so.6 /usr/lib64/libc.so.6 ``` - **SELinux阻止**:临时禁用SELinux:`sudo setenforce 0`(生产环境不推荐)。 > **安全提示**: > 1. 避免直接替换系统glibc,可能导致系统无法启动[^1]。 > 2. 容器方案是最安全的隔离方式[^2]。 > 3. 安装后使用`ldd your_program`检查动态库链接情况。 §§相关问题§§ 1. 如何在统信系统中安全降级glibc版本? 2. 容器方案与chroot环境在运行效率上有何差异? 3. 如何检测用程序的glibc依赖版本? 4. 静态编译的程序在统信系统中有哪些运行限制? [^1]:转载】Glibc version `GLIBC_2.17’ not found问题解决办法。注:本人上述的解决办法,只依赖于本人所遇到的类似问题。但是该问题的本质原因就是用程序所依赖的GLIBC环境与运行环境中GLIBC版本不匹配导致的,解决方式无非两种: 修改用程序编译的选项或配置,使其去掉较高本的环境依赖,类似于本次解决方式;重新配置运行环境的glibc,使其适用程序的依赖环境。 [^2]: 系统所需依赖包: binutils-2.17.50.0.6 compat-libstdc+±33-3.2.3 compat-libstdc+±33-3.2.3 (32 bit) gcc-4.1.2 gcc-c+±4.1.2 glibc-2.5-58 glibc-2.5-58 (32 bit) glibc-devel-2.5-58 glibc-devel-2.5-58 (32 bit) ksh libaio-0.3.106 libaio-0.3.106 (32 bit) libaio-devel-0.3.106 libaio-devel-0.3.106 (32 bit) libgcc-4.1.2 libgcc-4.1.2 (32 bit) libstdc+±4.1.2 libstdc+±4.1.2 (32 bit) libstdc+±devel 4.1.2 libXext-1.0.1 libXext-1.0.1 (32 bit) libXtst-1.0.1 libXtst-1.0.1 (32 bit) libX11-1.0.3 libX11-1.0.3 (32 bit) libXau-1.0.1 libXau-1.0.1 (32 bit) libXi-1.0.1 libXi-1.0.1 (32 bit) make-3.81 sysstat-7.0.2 查询依赖包安装情况: rpm -q binutils compat-libstdc++ gcc gcc-c++ glibc glibc-devel ksh libaio libaio-devel libgcc libstdc++ libstdc++-devel libXext libXtst libX11 libXau libXi make sysstat [^3]: binutils-2.17.50.0.6compat-libstdc++-33-3.2.3compat-libstdc++-33-3.2.3 (32 bit)elfutils-libelf-0.125elfutils-libelf-deve </think> ### 解决 "Unable to find a match: glibc-compat-2.17" 的完整方案 #### 1. **验证软件包实际名称** 在统信系统中,尝试搜索兼容包的实际名称: ```bash # 搜索可能的兼容包名称 sudo dnf search compat-glibc sudo dnf search glibc-legacy # 检查可用软件包列表 sudo dnf list available | grep -i glibc ``` #### 2. **启用EPEL仓库(推荐方案)** ```bash # 安装EPEL仓库(引用[2][3]) sudo dnf install epel-release # 更新仓库元数据 sudo dnf update --refresh # 再次尝试安装(使用可能存在的替代名称) sudo dnf install compat-glibc # 或尝试 glibc-legacy ``` #### 3. **手动安装兼容包** 若仓库中没有,从CentOS 7获取兼容包: ```bash # 下载CentOS 7的glibc 2.17包 wget http://vault.centos.org/7.9.2009/os/x86_64/Packages/glibc-2.17-317.el7.x86_64.rpm # 安装必要依赖(引用[3]) sudo dnf install elfutils-libelf-devel binutils-devel # 强制安装(需谨慎) sudo rpm -ivh --nodeps glibc-2.17-317.el7.x86_64.rpm ``` #### 4. **容器化方案(最安全)** ```bash # 创建CentOS 7容器(自带glibc 2.17) sudo podman run -itd --name legacy_app_env \ -v /path/to/app:/app:Z \ docker.io/library/centos:7 # 在容器内运行程序 sudo podman exec -it legacy_app_env /app/your_program ``` #### 5. **源码编译GLIBC 2.17** ```bash # 下载并编译(引用[1]) wget http://ftp.gnu.org/gnu/glibc/glibc-2.17.tar.gz tar xvf glibc-2.17.tar.gz mkdir glibc-build && cd glibc-build ../glibc-2.17/configure --prefix=/opt/glibc-2.17 make -j$(nproc) sudo make install # 使用指定库路径运行 LD_LIBRARY_PATH=/opt/glibc-2.17/lib:$LD_LIBRARY_PATH ./your_program ``` ### 关键注意事项 1. **兼容性风险**:直接安装旧版glibc可能导致系统不稳定(如动态链接器冲突)[^1] 2. **优先推荐容器方案**:完全隔离环境,不影响系统稳定性 3. **备选方案**: - 静态编译用:`gcc -static -o app_static app.c` - 安装32位支持:`sudo dnf install glibc.i686`(引用[2]) 4. **验证安装**: ```bash ldd --version # 查看当前glibc版本 ldd your_program # 检查程序依赖库 ``` ### 错误处理指南 | 错误类型 | 解决方案 | |---------|----------| | `依赖冲突` | 使用容器方案或安装到`/opt`独立目录 | | `文件已存在` | 添加`--replacefiles`参数:`rpm -ivh --replacefiles ...` | | `符号链接错误` | 手动创建链接:`sudo ln -sv /opt/glibc-2.17/lib/libc.so.6 /usr/lib64/` | | `权限不足` | 临时禁用SELinux:`sudo setenforce 0` | > **安全提示**: > 1. 避免替换系统核心glibc(可能导致系统无法启动)[^1] > 2. 容器方案不会修改宿主系统,风险最低[^2] > 3. 生产环境建议使用用重编译方案(引用[1])
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值