α、β、RC等各种测试流程解释

Alpha:是内部测试版,一般不向外部发布,会有很多Bug.一般只有测试人员使用。

Beta:也是测试版,这个阶段的版本会一直加入新的功能。在Alpha版之后推出。

RC:(Release Candidate) 顾名思义么 ! 用在软件上就是候选版本。系统平台上就是发行候选版本。RC版不会再加入新的功能了,主要着重于除错。

GA:General Availability,正式发布的版本,在国外都是用GA来说明release版本的。

RTM:(Release to Manufacture)是给工厂大量压片的版本,内容跟正式版是一样的,不过RTM版也有出限制、评估版的。但是和正式版本的主要程序代码都是一样的。

OEM:是给计算机厂商随着计算机贩卖的,也就是随机版。只能随机器出货,不能零售。只能全新安装,不能从旧有操作系统升级。包装不像零售版精美,通常只有一面CD和说明书(授权书)。

RVL:号称是正式版,其实RVL根本不是版本的名称。它是中文版/英文版文档破解出来的。

EVAL:而流通在网络上的EVAL版,与“评估版”类似,功能上和零售版没有区别。

RTL:Retail(零售版)是真正的正式版,正式上架零售版。在安装盘的i386文件夹里有一个eula.txt,最后有一行EULAID,就是你的版本。比如简体中文正式版是EULAID:WX.4_PRO_RTL_CN,繁体中文正式版是WX.4_PRO_RTL_TW。其中:如果是WX.开头是正式版,WB.开头是测试版。_PRE,代表家庭版;_PRO,代表专业版。

α、β、λ常用来表示软件测试过程中的三个阶段,α是第一阶段,一般只供内部测试使用;β是第二个阶段,已经消除了软件中大部分的不完善之处,但仍有可能还存在缺陷和漏洞,一般只提供给特定的用户群来测试使用;λ是第三个阶段,此时产品已经相当成熟,只需在个别地方再做进一步的优化处理即可上市发行。

来自为知笔记(Wiz)

时间: 2024-10-10 02:45:09

α、β、RC等各种测试流程解释的相关文章

cts-verifier测试流程

测试目的: cts的补充测试,可以理解为没法自动化的cts测试,这个是人工测试. 测试前提: 1.发货user版本 2.selinux:Enable 5.外网环境 设备需求: 2个待测设备:1个手机或平板:u口带麦耳机: 测试准备: 准备版本,过开机向导,安装从Google下载的CtsVerifier.apk 测试流程&动作: 打开CtsVerifier.apk,按顺序开启测试.备注:测试结束记得点击测试通过的绿色对号按钮,整体报告保存在apk主页右上角 AUDIO -Audio Frequen

1.2软件生命周期&测试流程

软件的生命周期 可行性分析-需求分析-软件设计-软件编码-软件测试-软件维护 1.可行性分析 主要确定软件开发的目的和可行性(PM) 2.需求分析 对软件的功能进行详细的分析(PM),输出需求规格说明书(原型图) 3.软件设计(DEV) 把需求分析得到的结果转换为软件结构和数据结构,形成系统架构 概要设计:搭建架构.模块功能.接口连接和数据传输 详细设计:模块深入分析,对各模块组合进行分析,伪代码   包含数据库设计说明 4.软件编码(DEV) 可运行的程序代码 5.软件测试 5.1.单元测试(

软件测试中常见测试流程

测试的流程: 需求阶段流程图: 单元/集成测试阶段流程图 系统测试阶段流程图 压力测试流程图 性能测试流程图 仅仅了解就够复杂的了,实际操作过程中的问题肯定更多.像压力测试.性能测试,一般的情况下我哪里用得上啊.虽然也知道些什么分布式应用.海量存储之类的,但是我连1T的数据都没见过.光说说那是是空话=.= 第二个问题:软件测试的常规方法. 软件测试中常见测试流程,布布扣,bubuko.com

关于测试流程、维度和管理

测试流程 1. 了解需求(也可能是一些优化或Bug),分析需求,提出疑问: 2. 拆解功能点,准备测试文档: 3. 开发提测后,待开发人员讲解实现功能: 4. 两个人以上讨论测试大的方向: 5. 测试: 6. Lead Review: 7. 上线跟踪验证,观察线上数据,并及时给需求方做反馈: 8. 该需求停止,进行下线跟踪. 测试维度 1.从用户实际使用场景和习惯入手,可以覆盖到主要基本场景: 2.通过测试对象内部实现流程的路径及依赖关系分析入手,可填补维度一部分遗漏场景,特别是异常处理和交互处

【转】测试流程

规范的测试流程                                                                                       放弃上份悠闲的工作,感谢那个带我入行公司,我想了解真正的测试在公作中如何进行的.所以,来到了现在这家公司.我很欣喜的是这测试有自己的团队,专业(对当时的我来说)的流程,以及与开发等同的地位. 现在的测试流程: 需求分析: 需求分析由产品人员制定,他们要做的不是一份简单的文档,而是细化每一个功能的细节,每一个按钮

测试流程:一个版本是如何测试上线的--功能测试

在传统的软件行业中,每一个版本的迭代周期少则半年,多则几年.一个版本中如此多的功能最终发布,测试是如何进行质量的保障的呢,我将以我经历的一个项目版本为案例,讲述这个过程中的测试流程. 我们常说测试要尽早的介入到项目中去,从需求开始测试.在这个项目中,需求的测试,我们这边是针对每一个需求单的评审,具体负责该单据的测试人员都要求做需求评审的问题记录跟踪表,要求需求评审中要提出对于该需求单的疑问,不合理的地方要求指出来,在评审会议后要发布需求评审问题记录表给参与该单据的评审人员,并附上结果是否评审通过

【iOS】真机测试流程

1:进入苹果开发者平台 2:进入Member Center 3:输入开发者账号和密码 4:选择:Certificates, Identifiers & Profiles 5:选择Certificates 6:点击加号创建一个证书 证书分两种,Development开发证书,Production发布证书 测试的话使用发开证书 然后选择下一步 7:上传CSR文件 打开钥匙串 通过证书助理请求证书 填写对应信息,选择保存到本地即可 上传文件 创建完成 8:下载并安装证书 点击Download下载证书,

移动app传统测试流程优化

概述 在传统的软件测试流程中,每一期需求从开发到上线都要经历从需求分析与评审.测试用例评审.开发.测试.发布的流程.其中测试包含了后台测试.前端web测试.客户端测试.后台测试又包括后台代码逻辑测试.接口测试.接口压力测试等,web端测试包含了前端页面的UI界面测试.PC与移动端浏览器兼容性测试和功能测试等,而客户端测试包含的测试项目较多,而每项测试又相对技术含量较高,从而引入了专项测试的概念.和针对客户端每期需求所做的功能测试不同,专项测试的结果虽然与产品的具体功能相关,又包含独立于产品需求功

LoadRunner 使用虚拟IP测试流程

LoadRunner 使用虚拟IP测试流程 LoadRunner 使用IP欺骗的原因 1. 当某个IP的访问过于频繁,或者访问量过大是,服务器会拒绝访问请求,这时候通过IP欺骗可以增加访问频率和访问量,以达到压力测试的效果. 2. 某些服务器配置了负载均衡,使用同一个IP不能测出系统的实际性能.LR中的IP欺骗通过调用不同的IP,可很大程度上的模拟实际使用中多IP访问和并测试服务器均衡处理的能力. LoadRunner 使用虚拟IP测试流程设置虚拟IP地址 前提条件:load Generator