杂谈测试这东西

本文深入解析软件测试的全过程,从理论角度阐述了V模型中的验证与确认过程,并详细介绍了各个测试阶段的目标、方法及关键文档的撰写技巧。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

关于软件测试这东西,玩了四年,仍然没有摸透它的脾气。

  有人说,软件测试是为了发现更多的缺陷,也有人说,软件测试是为了保证产品的质量。都没错啊,一个是从职责的角度来看,一个是从控制的角度来看。

  软件测试,其实就是一个验证的过程,软件测试人员竭尽所能的折腾一套软件,看它是否符合客户要求的标准,是否能经得起折腾,借以评价产品的质量好不好。不就是这样吗?:-)

  常规的软件测试理论是遵循了V模型中的V&V过程,也就是Validation and verification。Validation是对客户需求的验证,比如通常所说的验收测试、Beta测试。Verification指的是软件过程中每一次确认活动,包括客户需求确立以后的每一阶段关键产物的评审与测试。

  按照V模型的概念,我们将软件过程分为了客户需求、需求规格、概要设计、详细设计、编码、系统测试这几个关键的阶段。每一个阶段都会有相关的评审与测试,因此,以客户需求为主要依据的测试,我们称之为验收测试,着重于用户需求的验证,通常由客户来做;以需求规格为主要依据的测试,被称为系统测试,着重于对产品综合能力的验证,通常由专业的测试人员来做;以概要设计为依据的测试叫做集成测试,着重于对各级别的接口所进行的验证,通常会由编码人员与测试人员一起完成;以详细设计为依据的测试就成为了单元测试,着重于对代码的最小级别进行验证,通常由编码人员实现。看到这样的一个规则,我们很容易理清,每一个测试阶段,所要测试的对象是不同的,而相应的依据一旦通过了评审,便可以着手进行该项测试的准备。

  相对于之前的每一个关键阶段而言,测试阶段的执行顺序刚好相反。编码阶段只能执行单元测试,只有单元测试通过了,才可以对单元与单元之间进行集成,测试它们之间的接口,这被称之为集成测试。当软件所有的模块完成之后并且通过了集成测试,那么就可以进入系统测试阶段了。这个时候,测试人员摩拳擦掌,跃跃欲试,不找出Bug不罢休。

  然而,到底每一个测试阶段的测试工作是怎样开展的呢?这样的一个过程,我们称之为测试管理过程。每一个测试阶段,都会包括测试计划、测试设计、测试执行这三部分,有些人会把它划分得更细,比如获取测试需求、测试实施、搭建测试环境等。

  测试计划并不是单纯的写一个时间表,它是当对应的作为测试依据的文档定格之后(通常我们叫做基线化)就开始做的,最主要的目的是要告诉你的项目组成员,你要做什么(明确测试目的)?对什么来做(明确测试对象及测试需求)?怎么做(制定测试策略)?要使用什么来做(确定测试资源)?何时做(安排测试进度)?需要注意跟控制什么(估计测试风险,使用规避手段)?

  测试设计是要在测试计划通过了评审之后才做的,主要的产物是测试用例,是将你的测试策略升级为详细的步骤,对你确定的测试对象进行验证,应该要出现的理想结果是什么。当执行测试的时候,人们依据这份文档,会发现实际的结果与预期的不一样,于是便把它判定为缺陷。辅助的测试设计产物还包括测试环境的搭建、测试脚本、测试使用的数据等。关于测试脚本,是要衡量开发成本与预期收益的,不可以为使用了自动化的测试就是测试高手,这是个极其严重的误区。测试脚本的目的是要提高你的测试效率,怎样设计还是依赖于一个人的测试水平,如果片面的追求编程技能,把这认为是测试技能的提高,那么你不用做测试了,去做开发吧。在单元测试跟集成测试过程中会使用较多的测试脚本,是因为这些代码的复用率极高,几乎编码过程中的每天都会执行N遍。而系统测试阶段,由于测试重点不同,测试脚本的复用率也远远达不到前两个阶段的效果,自然就更要慎重了。要知道,一个常规的80/20法则,描述了一个事实,就是80%的缺陷是手工测试出来的,只有20%的缺陷是使用自动化测试得到的。你花费了两个月的时间去做了一套测试脚本,却只需要执行四五遍,发现的缺陷也寥寥可数,毕竟测试中的很多验证点是程序无法实现的。那么,如果使用两个月的人工测试,收到的效果会是天壤之别。你会选择哪一种方式呢?

  测试执行是在必备的代码实现之后才可以做的。拿着文档做设计,却不在真正的环境中执行,就变成了纸上谈兵的赵括。因此,你可以说测试设计是最重要的,我毫不反对,但是,测试执行却是最关键的。只有这个时候,你才能了解软件的质量如何,存在多少问题,需要怎样修复。在这时,才是我们经常说的测试阶段(单元测试阶、集成测试阶段、系统测试阶段)。测试阶段中,缺陷管理变成了重中之重,缺陷的追踪与控制成为弥补软件缺陷、控制产品质量的最直接有效的手段。

  在测试的每个环节都会产生相应的文档:测试计划、测试用例、测试报告,这三份文档成为最基本的资源。一份文档的好坏,关键不在于文笔怎样,而是能否清晰的表达你的意图,并让所有的人员能够了解,使得你所做的工作是可见可控的,不会出现较大的偏差。因此,写文档不是随便完成任务那么简单,它融入了你全部的思想、你的技能、你的沟通水准,是站在一定的高度上来完成的。即使你是个捉虫能手,但你不会写文档,不会把自己的思路清晰的表达出来,这至少能表明你不是个优秀的测试人员。

  我绝对不赞同一个测试新手去写什么测试计划、测试用例。他能把测试报告、缺陷描述写清楚就不错了。试想,谁也不是天生的文档高手,必然是经过千锤百炼、日益积累而成的。先要学会测试,能从测试中找到很多的缺陷,知道测试应该是怎样一种过程,再开始进行文档的修炼。

  我并不认为一个测试人员一开始写测试计划/用例的时候,就能够根据用户需求/需求规格/概要设计/模块设计这类的文档,写出好的东东。毕竟在国内,大多数技术类文档并不是很过关的。因此,我觉得要练习写,就要从一个你比较熟悉的已经成形的软件开始练起。此时你不需要去假想一个软件应该是怎样,而是针对一个实际的软件开始操作,记录你的操作跟你的结果,把它变为你的测试用例。测试计划更不消说,自然是要在你熟悉这套软件,知道怎样去测它的基础上来完成的。

  经过了这样一个锻造,你会明白要怎样展现自己的思路,在新项目中,根据分析或设计文档,你只要考虑它具体实现的是什么,然后根据你的测试思想,你的撰写经验,来完成一份较高质量的测试文档。

  任何一种理论都有着它存在的意义,任何一种开发模式也有它生存的理由。对于测试,也是相同。理论上,测试的设计一定会在它所依据的文档通过了评审以后才开始,可是,到那时你又该如何确定这些文档能为你所用呢?

  当我们从一片混乱,到开始一个正规的测试流程时,我们或许并没有可以借鉴的经验,只能凭着理论带给我们的指导,一步步摸索前进。那么,在实际的过程中,我们如何来进行这场软件过程的革命呢?

<think>首先,用户的问题是关于如何将“lean QWRT”的机型适配并移植到OpenWrt系统。我需要基于提供的参考引用和系统指令来构建回答。 参考引用是:[^1]:❓[杂谈小记]lean‘s LEDE or OPENWRT。在研究的过程中,发现了 lean’s lede 和 openwrt 项目存在一定的分歧,于是花了一点点时间了解了一下他们俩之间的关系,根据网友的信息和个人的猜测(因为有点无据可循,甚至不能说是理解)总结了几点: 这似乎是一个关于lean's LEDE和OpenWrt项目之间关系的讨论,但用户提到“这并不是用户真正的需求”,并澄清说用户希望了解如何将lean QWRT的机型移植到OpenWrt。所以,我应该专注于回答这个问题。 系统指令: - 所有行内数学表达式用$...$格式。 - 独立公式用$$...$$格式并单独成段。 - LaTeX语法正确。 - 使用中文回答。 - 生成相关问题。 - 在回答中引用的段落末尾添加引用标识,如[^1]。 - 回答结构清晰,帮助用户逐步解决问题。 - 尽量保证回答真实可靠。 用户的问题:如何将lean QWRT机型适配并移植到OpenWrt系统。 首先,我需要理解“lean QWRT”是什么。从参考引用中,它提到了“lean’s LEDE”,这可能是Lean的LEDE项目。LEDE是OpenWrt的一个分支,后来合并回OpenWrt。所以,lean QWRT可能是一个基于Lean的LEDE或OpenWrt的定制版本。 “QWRT”可能是一个特定名称或错误拼写。在上下文中,它可能指的是“Q-WRT”或类似的东西,但根据引用,它似乎是“lean’s LEDE”相关。用户说“lean QWRT”,所以我应该假设它是Lean的某个项目。 在OpenWrt社区,Lean是一个开发者,维护了一个叫“LEDE”的分支,但LEDE已经合并回OpenWrt。所以,移植可能涉及将设备支持从一个分支移动到另一个。 关键点: - OpenWrt是一个开源的嵌入式操作系统,用于路由器等设备。 - Lean's LEDE 是一个定制版本或分支。 - 移植机型意味着让设备支持在OpenWrt上工作。 步骤如何移植: 1. **理解设备支持**:在Lean's QWRT中,设备支持是通过配置文件、内核模块等实现的。 2. **获取源代码**:需要获取Lean's QWRT的源代码和OpenWrt的源代码。 3. **比较差异**:分析Lean's分支和上游OpenWrt之间的差异,特别是针对特定设备的支持。 4. **移植配置文件**:将设备特定的配置文件、DTS(设备树源)文件、内核配置等移动到OpenWrt树中。 5. **调整兼容性**:由于分支可能不同步,需要调整代码以兼容当前OpenWrt版本。 6. **编译和测试**:编译OpenWrt固件,测试在设备上是否工作。 7. **提交上游**:如果可能,贡献到OpenWrt官方项目。 结构化回答: - **介绍**:简要解释背景。 - **步骤**:逐步指导如何移植。 - **注意事项**:提到潜在问题。 - **生成相关问题**:在最后添加相关问题。 使用中文回答。 添加引用:由于参考引用是关于分歧的,我可以引用它来讨论背景,但用户说它不是真正需求,所以或许只在相关时引用。 生成相关问题:像示例中一样,在最后添加“相关问题”部分。 确保LaTeX:问题中没有数学内容,但如果有,我会使用。例如,如果提到公式,但这里可能不需要。 最终回答结构: 1. 引言:解释lean QWRT和OpenWrt的关系。 2. 移植步骤:详细步骤。 3. 注意事项。 4. 相关问题。</think>### 将lean QWRT机型适配并移植到OpenWrt系统的指南 在OpenWrt生态系统中,lean's LEDE(也称为lean QWRT)是一个基于OpenWrt的定制分支,由开发者Lean维护。它针对特定硬件进行了优化,但可能与上游OpenWrt项目存在分歧(例如在代码库、内核版本或设备支持上)[^1]。移植lean QWRT机型到OpenWrt系统,本质上是将设备特定的驱动、配置文件和固件支持从lean分支迁移到上游OpenWrt代码库中。这需要一定的嵌入式Linux开发经验,包括熟悉OpenWrt构建系统、设备树(DTS)和内核模块。以下我将逐步解释移植过程,确保内容清晰、可靠,并基于OpenWrt社区的最佳实践。 #### 步骤1: 准备工作与环境设置 在开始移植前,确保您拥有必要的工具和源代码: - **获取源代码**: - 下载lean QWRT的源码(通常从GitHub仓库获取,例如`https://github.com/coolsnowwolf/lede`)。 - 下载上游OpenWrt的源码(从官方仓库`https://git.openwrt.org/openwrt/openwrt.git`)。 - 使用Git命令克隆并切换到稳定分支,例如: ```bash git clone https://github.com/coolsnowwolf/lede.git lean-qwrt git clone https://git.openwrt.org/openwrt/openwrt.git openwrt-upstream cd openwrt-upstream git checkout v23.05.0 # 使用最新稳定版本 ``` - **设置构建环境**: - 安装依赖包(在Ubuntu/Debian上): ```bash sudo apt update sudo apt install build-essential libncurses5-dev gawk git libssl-dev zlib1g-dev ``` - 运行`make menuconfig`在OpenWrt目录中初始化配置。 #### 步骤2: 识别和提取设备特定配置 lean QWRT机型的支持通常存储在特定目录中。您需要找出这些文件并复制到OpenWrt树中: - **关键文件位置**: - 设备树源文件(DTS):位于`lean-qwrt/target/linux/<arch>/dts/`(例如`<arch>`可能是`ramips`或`mediatek`)。 - 内核模块和驱动:在`lean-qwrt/target/linux/<arch>/patches-5.10/`(版本可能不同)。 - 设备配置文件:在`lean-qwrt/target/linux/<arch>/image/`和`lean-qwrt/package/lean/`中的自定义包。 - **提取和复制**: - 使用diff工具比较lean分支和OpenWrt的差异: ```bash diff -r lean-qwrt/target/linux/ openwrt-upstream/target/linux/ > diff.log ``` - 复制缺失的文件到OpenWrt目录。例如,如果lean分支有特定DTS文件: ```bash cp lean-qwrt/target/linux/ramips/dts/mt7621_mydevice.dts openwrt-upstream/target/linux/ramips/dts/ ``` - 注意:如果文件路径不同,需要手动调整Makefile和Kconfig以集成到OpenWrt构建系统。 #### 步骤3: 调整代码和解决兼容性问题 由于lean分支可能使用较旧或修改过的内核版本,您需要确保代码与上游OpenWrt兼容: - **内核版本对齐**: - 检查OpenWrt当前使用的内核版本(通过`make kernel_menuconfig`)。 - 如果lean的驱动基于旧内核,使用`git format-patch`生成补丁并应用到OpenWrt: ```bash cd lean-qwrt/target/linux/ramips/patches-5.10/ git format-patch -n 5 # 导出最近5个补丁 cd openwrt-upstream/target/linux/ramips/ git am /path/to/patches/*.patch # 应用补丁 ``` - 如果补丁冲突,手动编辑文件解决(例如使用`git apply --reject`)。 - **设备树和固件配置**: - 修改DTS文件以匹配OpenWrt的标准。例如,确保内存映射、GPIO设置和时钟源与上游一致。 - 更新Makefile:在`openwrt-upstream/target/linux/<arch>/image/Makefile`中添加设备定义,例如: ```makefile define Device/mydevice DEVICE_VENDOR := MyBrand DEVICE_MODEL := QWRT-Device DEVICE_DTS := mt7621_mydevice SUPPORTED_DEVICES := mydevice endef TARGET_DEVICES += mydevice ``` - **测试编译**: - 运行`make menuconfig`,选择目标设备(在"Target Profile"中)。 - 编译固件:`make -j$(nproc) V=s`。如果出现错误,检查日志(通常在`logs/`目录),常见问题包括内核符号未定义或DTS语法错误。 #### 步骤4: 测试和优化 移植后,必须验证设备功能: - **刷机和测试**: - 使用`scp`或TFTP将生成的固件(在`bin/targets/`中)刷入设备。 - 测试关键功能:Wi-Fi、以太网、USB等。使用OpenWrt的LuCI界面或SSH检查日志:`logread | grep error`。 - **性能优化**: - 如果设备不稳定,调整内核参数(通过`make kernel_menuconfig`)。 - 添加缺失的软件包:如果lean分支有自定义包(如QoS工具),在`openwrt-upstream/package/`中创建新目录并复制代码。 #### 注意事项 - **兼容性挑战**:lean分支可能与OpenWrt存在分歧,例如使用私有内核补丁或非标准工具链[^1]。如果遇到无法解决的冲突,考虑在OpenWrt论坛寻求帮助。 - **上游贡献**:一旦移植成功,建议将更改提交到OpenWrt官方(通过邮件列表或GitHub PR),以惠及社区。 - **风险提示**:错误移植可能导致设备变砖,务必在测试设备上进行,并备份原厂固件。 - **工具推荐**:使用QEMU模拟器进行初步测试,减少硬件风险。 通过以上步骤,您可以高效地将lean QWRT机型迁移到OpenWrt系统。整个过程需要耐心和调试,但OpenWrt的文档和社区支持丰富(参考[OpenWrt官方Wiki](https://openwrt.org/docs))。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值