Chrome OS Factory开发测试流程

Factory SDK完全解读

方向分解：

factoryserver:

setup/FACTORY_SERVER.md

shopfloor:车间api，包含连接工厂服务器和工厂终端软件的接口

py/shopfloor/README.md

TestList:测试项列表

py/test/test_lists/README.md

一、Factory SDK介绍

1.1 SDK目录结构：

bin: factory源码中工具的symlink文件，基本上为sh脚本或py脚本。

build:用于构建Factory SDK的临时目录。
Makefile: 用于构建factory 源码和文档的make文件。
py: Python 源码. 该目录即 cros.factory 模块, cros.factory.system.board 模块 py/system/board 目录下.
py_pkg: 该目录作为PYTHONPATH 入口，包含了factory source. py_pkg/cros/factory 只是py 的一个symlink。比如如果查找 cros.factory.system.board 模块 py_pkg/cros/factory/system/board.py 实际是指向了 py/system/board.py。
sh: shell脚本
test_lists: 旧风格的测试列表 (新风格的在 cros.factory.test.test_lists 模块中. 可参考Declaring test lists.)

1.2 Makefile

make目标包含以下内容：

default: 构建工厂测试工具.
par: 构建Python archive，par包含了所有源码和依赖的库文件，可以用来运行各种各样的工具。
lint: 检查源码是否不规范。
test: 单元测试
overlay-board: 创建以overlay-{board} 未命名规范的目录，对应的目录包含了对板的factory源码 (e.g., in third_party/private-overlays/overlay-board-private/chromeos-board/factory-board/files). 对于特定板子的测试列表是非常有用的。
overlay-board-lint: 运行overlay-board-lint ,即在对应的overlay目录下执行 make lint。
overlay-board-test: 运行 overlay-board-test,即在对应的目录下执行make test。

注！一般情况下，我们可以在提交代码前执行make lint和make test来检查代码是否规范，测试功能是否ok。

1.3 编码规范和单元测试

编码规范需要遵循 Chromium Python Style Guide.

源码中以_unittest.py结尾的文件被认为是单元测试模块。

二、国家区域配置

像所的操作系统一样，CrOS支持用户可选的区域配置，包含键盘样式、语言、时区等。为了更好的体验，每个设备在发货的时候需要根据发货国家或区域进行相适应的配置。这些设置是通过RO VPD（read-only vital product data）的区域字段和cros-regions.json数据文件来管理的，下面我们来了解下Factory SDK如何管理这些区域配置的。

2.1区域和区域码（国家和国家码）

区域即设备发货的目标市场，同一个区域使用一个特定的keyboard布局、语言和时区。

每个区域是通过区域码（或国家吗）来定义的，如美国-us。

一个国家，如美国，对应的国家码参考 ISO 3166-1 alpha-2 code为两个字母，us；这里要说下UK的国家码是gb不是uk。
一个非国家的实体，如香港Hong Kong对应的是hk。
一个多国或国实体组织的联合体可以共享一个区域配置，如Hispanophone Latin American 拉美(包含墨西哥、哥伦比亚、秘鲁、阿根廷等），即为nordic。
一个国家或实体组织的部分也可具有特有的区域配置，如Francophone Canada即为ca.fr

当前CrOS通过region code来获取区域数据，如locales或Wi-Fi管理域。区域数据可以更新，但区域码本身是锁定在VPD RO中了。

2.2可用的区域

已定义已确定的：

已定义未确认的：

2.3键盘布局（输入法）

keyboards域是指输入法ID的列表。第一个是默认的。一般情况下，是与语言相匹配的。当指定了语言之后，只有该语言下可用的键盘才可以被设置。

每个keyboard的定义必须以xkb:、m17n:、ime:开头。截止到M38，可用的键盘布局包括如下：

xkb:...: XKB input methods listed in any file in JSON files in the Chromium src/chrome/browser/resources/chromeos/input_method directory. (Look for the id attributes of each input_components list entry.) For example, you will find xkb:us::eng in google_xkb_manifest.json.
ime:...: (M38+ only) Any hard-coded strings listed in kEngineIdMigrationMap in Chromium’s input_method_util.cc. Currently this is:
- ime:zh-t:quick
- ime:zh-t:pinyin (not yet supported as of this writing, but should be added in M38)
- ime:ko:hangul
- ime:ko:hangul_2set
m17n:...: (M38+ only) Strings with a prefix in kEngineIdMigrationMap. The prefix is rewritten according to the map, and there must be a corresponding input method ID in some file in the input_method directory. For instance, m17n:ar will be rewritten to vkd_ar according to the map. vkd_ar is present in google_input_tools_manifest.js.

2.4 时区

time_zone字段被用作默认时区。M35+以后的版本支持自动检测时区。

2.5 语言代码

可参考 kAcceptLanguageList ，在 l10n_util.cc中搜索 kAcceptLanguageList。

2.6测试区域配置

当添加一个新的区域，我们需要进行测试来验证有效性，以确保用户的开箱体验（OOBE）。

那么我们需要运行py/110/regions_unittests.py文件或者在对应主板的目录下执行 overlay-board && overlay-board/py/l10/regions_unittest.py。

为了提高开箱体验，我们可以运行 py/experimental/oobe/region/run_region_oobe.py 脚本。该脚本会通过ssh工具到CrOS上，并根据command line来设置设备的VPD字段，然后运行OOBE流程。设备上需要load测试镜像，且factory 工具套件需要是disable状态。

举例：ssh到一个corsdev设备，然后测试公共层一个命名为xx的区域：

cd ~/trunk/src/platform/factory

py/experimental/oobe/region/run_region_oobe.py crosdev xx

或者私有层的区域：

cd ~/trunk/src/platform/factory

make overlay-private

overlay-private/py/experimental/oobe/region/run_region_oobe.py crosdev xx

2.7 Region API

class cros.factory.test.l10n.regions.Region(region_code, keyboards, time_zone, language_codes, keyboard_mechanical_layout, description=None, notes=None)

FIELDS = ['region_code', 'keyboards', 'time_zone', 'language_codes', 'keyboard_mechanical_layout']，Region有这些字段来定义。

region_code = None//区域码或国家码

keyboards = None//输入法

time_zone = None//时区

language_codes = None//语言码

description = None//对应Region的描述性介绍

notes = None//对应Region的说明性介绍

GetFieldsDict()//返回实际字段对应的数据字典

cros.factory.test.l10n.regions.BuildRegionsDict() //该函数会返回所有定义好的区域数据字典，除了调用cros.factory.test.l10n.regions.REGIONS获取区域数据，一般情况下我们不直接调用BuildRegionsDict函数。因为cros.factory.test.l10n.regions.BuildRegionsDict(include_all=False)会构建一个数据字典映射到py.l10n.regions.Region对象中。这些对象包含在cros.factory.l10n.regions.REGIONS_LIST中，如果include_all=True，则会包含cros.factory.l10n.regions.UNCONFIRMED_REGIONS_LIST，这些事已定义但未确认使用的区域。

A region may only appear in one of the above lists, or this function will (deliberately) fail.

二、Device Data设备数据

Device Data是一个数据集，用来封装DUT的生产信息。包含很多外设，如触摸屏；也包含很多预设信息，也就是所谓的VPD（Vital Product Data），如序列号，发货区域；同样包含测试状态如SMT是否pass，FATP是否pass还有其他站位状态。

Device Data在测试过程中是共享的，如Chrome OS Factory Software、Goofy、Shopfloor Service API。所有的这些数据都是来自预先定义的值、或Shopfloor backend还有测试过程中人工选择的或者从条码扫描器得来的。

我们可以把Device Data看做一个数据字典或者映射。如下主要字段包含：

serials: A dictionary for serial numbers of device, components, and mainboard. All serial numbers here will be logged by testlog, including:
- serial_number: The serial number of “device” itself (printed on device panel).
- mlb_serial_number: The serial number of main logic board (mainboard).
component: A dictionary to indicate what peripherals should exist, for example:
- has_touchscreen=True: A touch screen should be available.
- has_dram=2: Two DRAM components should be available.
vpd: A dict for what VPD values need to be set, including:
- ro: VPD values in RO section (RO_VPD), usually including:
  - region: Region code as defined in http://go/cros-regions.
- rw: VPD values in RW section (RW_VPD), usually including:
  - ubind_attribute: User registration code.
  - gbind_attribute: Group registration code.
hwid: A value of probed Hardware ID.
factory: A dict for manufacturing flow control, used by shopfloor backends. See Shopfloor Service API for more details.

举例说明：

{

'serials': {

'serial_number': 'SN1234567890',

'mlb_serial_number': 'MLB1234567890'

'vpd': {

'ro': {

'region': 'us'

'rw': {

'ubind_attribute': '12345',

'gbind_attribute': '54321',

}

}}

使用Device Data的函数调用如下：

GetDeviceData('vpd.ro')

GetDeviceData('vpd.ro.region')

GetDeviceData('vpd').get('ro').get('region')

GetDeviceData(KEY_VPD).get(NAME_RO).get(NAME_REGION)

etDeviceData(KEY_VPD_RO).get(NAME_REGION)

GetDeviceData(KEY_VPD_REGION)

适应Serial Number（序列号）的函数调用

GetSerialNumber('serial_number')

GetSerialNumber(NAME_SERIAL_NUMBER)

GetSerialNumber(KEY_SERIAL_NUMBER)

GetDeviceData(KEY_SERIAL_NUMBER)

AIP定义：

cros.factory.test.device_data.CheckValidDeviceDataKey(key, key_prefix=None)

Checks if given key is a valid device data key.

Parameters:

key – A string of key for device data.

key_prefix – Key must start with this token.

Raises:

KeyError if the key is not valid.

cros.factory.test.device_data.GetDeviceData(key, default=None)

Returns the device data associated by key.

Parameters:

key – A string of key to access device data.

default – The default value if key does not exist.

Returns:

Associated value if key exists in device data, otherwise the value specified by default. Defaults to None.

cros.factory.test.device_data.GetAllDeviceData()

Returns all device data in a single dict.

cros.factory.test.device_data.GetDeviceDataSelector()

Returns the data shelf selector rooted at device data.

This is primarily used by invocation module to resolve TestListArgs.

cros.factory.test.device_data.DeleteDeviceData(delete_keys, optional=False)

Deletes given keys from device data.

Parameters:

delete_keys – A list of keys (or a single string) to be deleted.

optional – False to raise a KeyError if not found.

Returns:

The updated dictionary.

cros.factory.test.device_data.VerifyDeviceData(device_data)

Verifies whether all fields in the device data dictionary are valid.

Parameters: device_data – A dict with key/value pairs to verify.

Raises:

ValueError if the device data is invalid.

cros.factory.test.device_data.UpdateDeviceData(new_device_data)

Updates existing device data with given new dict data.

Parameters: new_device_data – A dict with key/value pairs to update. Old values are overwritten.

Returns: The updated dictionary.

cros.factory.test.device_data.GetAllSerialNumbers()

Returns all serial numbers available in device data as dict.

cros.factory.test.device_data.ClearAllSerialNumbers()

Clears all serial numbers stored in device data.

cros.factory.test.device_data.GetSerialNumber(name='serial_number')

Returns a serial number (default to device serial number).

cros.factory.test.device_data.SetSerialNumber(name, value)

Sets a serial number to give nvalue.

Parameters:

name – A string to indicate serial number name.

value – A string representing the serial number, or anything evaluated as False to delete the serial number.

cros.factory.test.device_data.UpdateSerialNumbers(dict_)

Updates stored serial numbers by given dict.

Parameters: dict – A mapping of serial number names and values to change. A value evaluated as False will delete the serial number from device data.

cros.factory.test.device_data.FlattenData(data, parent='')

An helper utility to flatten multiple layers of dict into one dict.

For example, {‘a’: {‘b’: ‘c’}} => {‘a.b’: ‘c’}

Parameters:

data – The dict type data to be flattened.

parent – A string to encode as key prefix for recursion.

Returns:

A flattened dict.

cros.factory.test.device_data.LoadConfig(config_name=None)

Helper utility to load a JSON config that represents device data.

Parameters: config_name – A string for name to be passed to config_utils.LoadConfig.

Returns: A dictionary as device data (already flattened).

cros.factory.test.device_data.UpdateDeviceDataFromVPD(key_map, vpd_data)

Update device data from VPD data.

Please see pytest read_device_data_from_vpd for more details. For both key_map and vpd_data, they should be a dictionary, with at most two keys: ‘ro’ and ‘rw’ (NAME_RO and NAME_RW). key_map[‘ro’] and key_map[‘rw’] should follow the format of ro_key_map and rw_key_map in read_device_data_from_vpd. If key_map is None, a default key_map will be used.

三、Factory Server

3.1Factory Server简介

Chrome OS Factory Server是一组运行在服务器上的软件的集合，该服务器被部署在工厂的生产线上。是DUT的唯一入口，Factory Server可以访问shopfloor backend，存储日志，同步系统时间还有其他相关的服务。

目前，server是一个Docker镜像(https://www.docker.com/)，包含以下组件：

- [Dome](../py/dome/README.md), 可以用于访问服务器web前端

- [Umpire](../py/umpire/README.md), 提供镜像功能和局部升级功能，同时管理其他服务。

- [Overlord](../go/src/overlord/README.md), 远程镜像服务

- [Instalog](../py/instalog), 日志系统

- [DKPS](../py/dkps), 用管理秘钥配置的服务

3.2先决条件

通常情况下我们可以通过浏览器下http://locallost:8000地址访问服务器，我们可以通过在该地址下进行其他组件的配置。

工厂服务器可以运行在所有支持Docker（http://docker.io）的机器上，推荐配置如下：

最低配置：

- CPU: x86-64 CPU

- Memory: 2G

- Storage: 256G

建议配置：

- Memory: 16G

- Storage: 4T

- CPU: Intel Core i7 or Xeon E5 series or an faster x86-64 CPU

安装Docker

工厂服务器支持Windows、Linux、MacOS，推荐如下：

#### Linux Server

1. Ubuntu Linux 16.04.1 server](http://releases.ubuntu.com/16.04/ubuntu-16.04.1-server-amd64.iso) (xenial).

2. 安装过程中，我们需要系统格式化磁盘为GPT，而不是MRB以求获得更大磁盘空间。

3. Docker 保存所有内容在`/var/lib`目录下，Chrome OS Factory Server服务器保存其数据在 `/cros_docker`目录下，所以我们要保证所在磁盘有足够的空间。最好的办法不要创建更多的分区，仅适用一个分区即可。

#### Mac OSX

1. 如果运行 factory sever 在Mac OSX, 则共享目录在`${HOME}/cros_docker` 下，而不是 `/cros_docker`, 如 `/Users/admin/cros_docker`.

#### Docker

1.在Linxu下运行sudo apt-get update && sudo apt-get install docker.io进行安装；并且可以通过访问(https://docs.docker.com/engine/installation/)来获取帮助。

2.键入"docker version“可以查看当前Docker版本，确保版本不低于"1.10.3“

3.3安装配置Factory Server

###获取部署脚本

ChromeOS Factory Server组件是通过“cros_docker.sh”（./cros_docker.sh）来管理的，我们有三种选择来获取此脚本：

1.确保系统中已安装“crul”和“base64”

然后执行：

curl -L http://goo.gl/gKCyo1 | base64 --decode >cros_docker.sh

sh ./cros_docker.sh update #修改脚本的执行权限，运行更新.

2.访问Factory 软件仓库

git clone https://chromium.googlesource.com/chromiumos/platform/factory

cd factory/setup#./cros_docker.sh位于此目录下

3.从CPFE中获取，如下；

https://www.google.com/chromeos/partner/fe/#home

脚本位于setup目录下

###下载安装Factory Server

1.运行./cros_docker.sh pull #如果服务器设备无法联网，拷贝cros_docker.sh和屏幕上显示的文件信息到目标机器上。

2../cros_docker.sh install

3../cros_docker.sh run

###更新配置脚本和服务器镜像

./cros_docker.sh update

四、Shopfloor 生产制造

4.1介绍

ChromeOS工厂软件平台未生产流程提供了完整的解决方案，但是有一些数据是需要ODM等生产厂商来提供的，如序列号、MAC地址、KSU信息等，包括追踪一台设备是否可以发布（发货）。那么这部分我们通常称之为Shopfloor System（制造信息系统），该系统有ODM厂商开发并安装在产线。那么该Shopfloor System必须包含ChromeOS Factory 软件平台。

不同ODM厂商可能实现Shopfloor所使用的技术不尽相同，如SQL database、web service、和通过CIFS进行数据交换。为了缩小集成成本和shopfloor实现的灵活性，Chrome OS Factory软件平台定义了一个shopfloor 抽象层，类似于anroid 的HAL层。我们称之为“Chrome OS Factory Shopfloor Service”简称为“shopfloor service”。

ODM和CM厂商通过实现和维护Shopfloor Service对应的接口，该接口会在后面详细介绍。且此部分的实现无需开源或提供给Chrome OS。该服务支持运行在所有操作系统(windows/linux/macos)的Chrome OS Factory Server上。DUT可以通过Chrome OS Factory Server内置的某些功能访问Shopfloor服务。

4.2网络技术

基本组件包含4个部分：

1.DUT即Chrome OS设备

2.Google Chrome OS Factory Server

3.Chrome OS Factory Shopfloor Service

4.ODM或者CM的Shopfloor Backend（真正意义上的有ODM或者CM开发实现的shopfloor system）

DUT和Google Chrome OS Factory Server相关联的代码的运行和维护是由Google Chrome OS来处理，而Factory Shopfloor Service和Shopfloor Backend相关代码的运行维护则是由ODM和CM来完成的。

为了方便开发，合作方会选择Google Chrome OS Factory Server同一服务器来运行Shopfloor Service。对于Google ChromOS Factory Server来说，只需要知道Shopfloor Service的URL地址即可。

4.3为Factory Server设置Shopfloor Service URL地址

Factory Server安装完成后，打开Dome web接口为Umpire设置shopfloor service url地址。

打开Dome UI（浏览器键入http://<dom_host>:8000）
登入并选择你的项目
在仪表盘的Services列表中找到shopfloor。
配置serviceUrl
点击DEPLOY进行部署

随后Umpire会自动把localhost翻译成“Docker host IP”。

4.4 Shopfloor Service API

Chrome OS Factory Shopfloor Service必须被实现为webservice。

Webservice可以支持XML-RPC(http://xmlrpc.scripting.com/spec.html)和Nil Extension(https://web.archive.org/web/20050911054235/http://ontosys.com/xml-rpc/extensions.php)的web service形式。默认端口是8090；

下面给出一段python实现的例子：

shopfloor_service.py

py:

import xmlrpclib

service = xmlrpclib.ServerProxy('http://localhost:8090', allow_none=True)

print('Service Version: %s' % service.GetVersion())

service.NotifyStart({'serials.mlb_serial_number': '123'}, 'SMT')

Webservice也可以支持JSON-RPC(http://www.jsonrpc.org/)或通过WSDL(https://www.w3.org/TR/wsdl)实现的SOAP(https://www.w3.org/TR/soap/)。使用JSON-RPC服务，当我们在Chrome OS Factory Software配置URL的时候需要添加一个前缀--'jsonrpc:"，形如"json:http://192.168.0.1:8090"。使用WSDL时，我们在Chrome OS Factory Software配置URL需要添加一个前缀--'wsdl:"，形如"wsdl:http://192.168.0.1:8090"。

py:

from cros.factory.utils import webservice_utils

url = 'jsonrpc:http://192.168.0.1:8090'

service = webservice_utils.CreateWebServiceProxy(url)

print(service.GetDeviceInfo({}))

如果通过WSDL+SOAP来实现Shopfloor Service，则会发现描述数据结构相当复杂，这是因为实际上他们是Generic Compound Types类型的。这里有一个特殊的方式可以帮助将输入参数和返回值进行JSON实例化，

py:

import xmlrpclib

from cros.factory.utils import webservice_utils

# Assume your real shopfloor service is here, and all its input and output

# must be JSON strings:

real_url = 'http://192.168.0.1:8090'

proxy = xmlrpclib.ServerProxy(real_url)

# The input is a JSON string. The output is also JSON, for example

# '{"vpd.ro.region": "us"}'

print(proxy.GetDeviceInfo('{}'))

# The webservice_utils provides 'json:' prefix to filter that.

url = 'json:http://192.168.0.1:8090'

service = webservice_utils.CreateWebServiceProxy(url)

# Input is real variable, and output is real dict, for example

# {'vpd.ro.region': 'us'}

print(service.GetDeviceInfo({}))

4.4.1 Data Format数据格式：设备数据

设备数据是值Shopfloor Service功能调用返回的数据结构；DUT软件版本通过调用"GetDeviceData"和"UpdateDeviceData“来更新设备数据(../test/device_data.py)；

DeviceData基于FactoryDeviceData，出于隐私和性能上的考虑，额外包含一些不会回传给Shopfloor Service的域。

vpd: vpd域用于配置Vital Product Data，包含ro或rw两个子域；如vpd.ro.region用于配置发货国家所对应的国家码或地区码；Chrome OS设备需要遵循VPD Field Requirements(https://www.google.com/chromeos/partner/fe/docs/factory/vpd.html)来配置必须的VPD信息，如：
- vpd.ro.region 国家码（组合了地区、时区、键盘配置和WIFI管理等信息）
- vpd.rw.ubind_attribute "User"注册码
- vpd.rw.gbind_attribute "Group"注册码
component: 一个用于定义SKU信息的可选域，用于标识一些特定的已安装的外围设备数量，使用下面格式的字段进行定义：

component.has_<peripheral_name> = True | # The DUT has exactly one that peripheral.

False | # The DUT doesn't have that peripheral.

举例如：component.has_camera = 2 #DUT有2颗camera。如果有一颗camer可以用component.has_camera = 1 或 component.has_camera = True;

提示：

没有必要在vpd域中定义device serial number(ro.vpd.serial_number)，因为该域会自动从serials.serial_number获取。

4.4.2 GetVersion（）函数

返回当前支持的协议版本号。

参数:

None

返回值:

A string for protocol version. "1.0" for current specification.

举例:

GetVersion() # Returns "1.0"

所有实现了这个定义的Shopfloor Service应返回字符串“1.0”

4.4.3 NotifyStart()函数

通知shopfloor backend，DUT当前已经进入生产站位（工位）；

参数:

- data: A struct FactoryDeviceData representing DUT information.

- station: A string (case-sensitive) as name of station.

返回值:

A struct DeviceData for values to update in the device_data.GetDeviceData.

举例:

NotifyStart({'serials.mlb_serial_number': 'C123'}, 'SMT')

# Returns {} and device_data.GetDeviceData('factory.start_SMT') is True.

典型的Chromebook 的 Shopfloor Service需要支持下面的站位（工位）：

SMT：Surface Mount Technology；表面铁桩技术工位测试，即贴片，用于验证主板。
FAT：Final Assembly Test；最终组装测试，即封板测试
RUNIN：Run-In；试运行测试；
FFT：Final Functional Test；包装之前的最终功能测试
GRT：Google Required Test；google 认证测试

对于有些项目不需要上面的测试工位的，可以直接pass或者返回空数据。还有一些项目需要选择性的添加额外的工位，那么他们就需要修改和维护这些自定义的测试列表。

当某个站位测试成功后，DUT会调用改API来自动设置DeviceData中的factory.start_<station>值为true。如"factory.start_smt = True";

4.4.4 NotifyEvent()函数

通知Shopfloor Backend，DUT执行了一个事件，该事件通常是指一个特定的检查点。

参数:

- data: struct FactoryDeviceData

- event: string (case-sensitive)

返回值:

A struct DeviceData for values to update in the device_data.GetDeviceData.

举例:

NotifyEvent({'serials.serial_number': 'A123'}, 'Finalize')

Returns {} and device_data.GetDeviceData('factory.event_Finalize') is

True.

当事件执行成功，DUT会调用改函数来自动设置对应事件的值为true（形如：factory.event_<event> = True），同样，该对应事件的key是factory.event_<event> 定义在DeviceData中。

一个典型Chromebook的Shopfloor Service的实现至少需要支持下面两个事件：

#### Finalize事件

DUT已经确认终版且恢厂等待发货，那么此时为Finalize事件。Finalize事件不包含隐私相关的字段，如MAC地址或者注册码等。如果厂商需要验证这些值，可以自定义相关测试项。

#### Refinalize事件

标识DUT被送往OQC（Outgoing Quality Control 出货质量控制），现在被送回进行重置和数据擦除，即恢厂。

同样地，“data”参数不应包含隐私信息，如MAC地址或者注册码等。如果厂商需要验证这些值，可以自定义相关测试项。

4.4.5 GetDeviceInfo()函数

获取DUT相关的配置信息；

参数:

- data: struct FactoryDeviceData

返回值:

A struct DeviceData for values to update in the device_data.GetDeviceData.

举例:

GetDeviceInfo({'serials.mlb_serial_number': 'C123'})

# Returns {'serials.serial_number': 'A1234', 'vpd.ro.region': 'us'}

该函数通过与backend shopfloor server进行通信，获取DUT设备配置信息，如VPD值和SKU等。

2.4.6 ActivateRegCode()函数

通知shopfloor backend，DUT设备已经成功配置了注册码（或者ECHO码）

参数:

- ubind_attribute: A string for user registration code.

- gbind_attribute: A string for group registration code.

- hwid: A string for HWID of the DUT.

返回值:

A struct DeviceData for values to update in the device_data.GetDeviceData.

举例:

ActivateRegCode('uuu', 'ggg', 'LINK A2C-B3D')

Returns {} and device_data.GetDeviceData('factory.activate_reg_code') is

True.

注册码应该被标记为“used”，并记录在shopfloor backend，然后回传给Google CPFE进行激活。由于涉及到隐私信息，该注册码不可以关联到序列号或者其他数据当中。所以该方法的设计与FactoryDeviceData没有任何关联。

4.4.7 UpdateTestResult()函数

发送指定的测试结果给Shopfloor Backend。

参数:

- data: struct FactoryDeviceData

- test_id: A string as identifier of the given test.

- status: TestState字符串（区分大小写）

- details: (optional) A struct to provide more details test results,

including at least one string member 'error_message' as message

reported from the error.

返回值:

A struct DeviceData for values to update in the device_data.GetDeviceData.

If a member 'action' is included, its value will be used to decide

how to proceed with testing flow.

举例:

UpdateTestResult(data, 'smt.type_c_left', 'PASSED') # Returns {}

UpdateTestResult(data, 'smt.type_c_left', 'FAILED',

{'error_msg': 'Unknown'})

# Returns {'action': 're-run'}

“TestState”在cros.factory.test.state中有定义（../test/state.py），status参数必须是下面的一种"PASSED,FAILED,SKIPPED,FAILED_AND_WAIVED"

Shopfloor也许会通过“DeviceData“的“action”和使用这些方法来标识DUT设备的下一个测试项。比如重新运行测试项、跳过测试项、中止测试项。

五、TestLists && PyTests

ChromeOS Factory Test Lists介绍

这部分主要介绍factory test lists，详细可参考“http://goto/cros-factory-test-list(http://goto/cros-factory-test-list)或者[JSON_TEST_LIST.md](./JSON_TEST_LIST.md)”

TEST LISTS

初始化阶段，test list ‘manager’会加载当前目录下的所有" *.test_list.json "文件。如果JSON文件定义为"tests”，那么该test list ID将会被导出为有效测试列表。执行命令“factory test-list --list”可以找到所有有效的测试列表（test lists）。执行命令“factory test-list <teste-list-id>”来激活对应的test list。

活动的测试列表（Test List）

正常情况下，活动的测试列表的ID保存在"/usr/local/factory/py/config/active_test_list.json"中。Goofy会通过该配置文件来首次尝试读取此ID。命令执行factory test-list <test-list-id>激活某个活动列表时，对应的id会保存到该文件当中去。如果没有配置活动的test list，则有两种方式来决定默认的test list。

1.ID-将会首先检查‘main_${model}’ ，通过命令"mosys platform model"来检查'${model}' 源自哪里。

2.有ID的测试项-如定义了“main”和“generic_main”

覆写激活的Test List

"setup/cros_docker.sh goofy try"允许开发者从本地源码运行工厂套件。那么，我们建议开发者在docker中，保存活动的测试列表到"/var/factory/config/active_test_list.json"。因为开发者电脑上的"py/config/active_test_list.json"将会使toolkit的构建更加容易。

六、List of Factory Tests（pytest）

这里通过factory的代码来介绍下所有可用的测试，如下：

pytest测试项 pytest name	description 测试项描述
ac_power	测试DUT电源类型和状态
accelerometers	测试加速度计
accelerometers_calibration	测试加速度计校准标定
accelerometers_lid_angle	测试基于加速度计角度
audio	测试音频播放功能
audio_basic	测试录音和播放基本功能
audio_diagnostic	测试音频录制和播放效果
audio_loop	测试音频功能
audio_quality	使用音频设备测试音质
backlight	测试显示背光
bad_blocks	通过运行磁盘检测指令验证存储设备
battery	测试DUT电池效果
battery_basic	电池基本测试
battery_current	电池当前是否处于充电或放电状态测试
battery_cycle	电池回路测试
battery_sysfs	硬件测试，包含电池是否在位及其基本的状态
bft_fixture	BFT fixture控制接口测试
blocking_charge	测试等待电池充电达到特定level
bluetooth	蓝牙设备功能性测试
bluetooth_host	使用hciconfig和hcitool.进行基于占位的蓝牙扫描配对测试
brightness.brightness	LED和LCD背光亮度测试
brightness.lcd_backlight	LCD背光模块功能测试
brightness.led_brightness	LED亮度测试
button	案件功能测试
buzzer	蜂鸣器测试
camera	无固定摄像头测试
cellular_switch_firmware	切换modem固件测试
chameleon	使用Chameleon（变色龙）工具进行自动化显示测试
charger	测试一定时间充放电的电池电量
check_cr50_board_id	检测CR50固件的BoardID
check_image_version	检测OS Image版本
check_serial_number	检查序列号设置是否正常
compass	指南针测试
countdown	run-in 测试中倒计时监视器用户接口测试
cr50_write_whitelabel_flags	如果当前是一个白标设备，则写入cr50白标。
display	显示功能测试
display_images	显示功能测试
display_point	显示面板功能测试
dsm_calibration	扬声器校准测试
ethernet	以太网连接基本测试
exec_python	运行任意python脚本测试
exec_shell	shell命令调用运行测试
external_display	外部显示测试（音频播放可选）
factory_state	PyTest FactoryStateLayer控制协助测试
fan_speed	CPU风扇功能测试
fastboot_flash	使用fastboot flash进行镜像升级
finalize	切换量产版本的封板测试
fingerprint_mcu	Fingerprint sensor测试
flash_netboot	刷ap固件到网络引导固件
gps	允许在Android DUT上进行GPS芯片相关的测试和验证
gyroscope	陀螺仪测试
gyroscope_calibration	陀螺仪校准测试
hwid	使用HWID v3来生成/编码和验证设备的硬件标识符
interrupt	测试测试中断次数是否超出预期
keyboard	键盘功能测试
keyboard_backlight	键盘背光测试
keyboard_smt	贴片测试中进行键盘引脚连接的测试
led	Uses ectool to control the onboard LED light, and lets either operator or SMT fixture confirm LED functionality.
lid_switch	LID切换测试
light_sensor	环境光感测试
light_sensor_calibration	光感校准测试
lightbar	警示灯测试
line_check_item	使用交互式shell脚本测试DUT
lte_verify_config	验证LTE模块配置
memory_size	参考固件中的信息测试存储大小是否正确
message	显示一条信息
model_sku	测试确认和设置KSU信息
modem_security	验证和关闭modem访问授权
mrc_cache	初始化也验证恢复模式内存测试
network_setup.network_setup	等待网络连接操作
nop	空操作测试
offline_test.offline_test	pytest offline_test.offline_test
offline_test.shell.deploy	pytest offline_test.shell.deploy
offline_test.shell.fetch_log	pytest offline_test.shell.fetch_log
partition_table	检查分区表是否延伸到存储末端，即覆盖整个磁盘。
pd_fw_min_version	检查PD(TCPC)固件版本大于等于EC驱动中最小版本。
ping_test	Ping测试
plankton_cc2_pull_test	夹具USB type-C CC2功能测试
plankton_cc_flip_check	检查USB type-C CC 线电极，反转操作测试
plankton_charge	USB type-c接口充电功能测试
plankton_display	Tests USB type-C DP function with Plankton-Raiden, which links/unlinks DUT USB type-C port to DP sink. And with Plankton-HDMI as DP sunk to capture DP output to verify.
power_under_stress	pytest power_under_stress
probe.probe	测试设备组件是否正常
probe_cellular_info	尝试从modem status中获取信息
probe_sim	尝试从modem status中后去SIM卡信息
probe_sim_card_tray	SIM卡卡托测试
read_device_data_from_vpd	从VPD中配置设备数据
removable_storage	测试访问热插拔存储设备
retrieve_config	从U盘或factory server获取JSON配置文件
retrieve_parameter	从Factory server获取参数文件
rf_graphyte.rf_graphyte	使用Graphyte.测试RF芯片负载能力
robot_movement	控制机器人来测试特定感应器
sample_customized_test	主板特定测试
sar_proximity_sensor	SAR金距离感应测试
scan	提示测试员输入字符串
select_for_sampling	决定当前设备是否可以进行抽样测试
serial_echo	检查DUT贴片测试的状态
shopfloor_service	远程调用与shopfloor backend的交互
shutdown	开关机/重启测试
spatial_sensor_calibration	空间传感器校准
start	检查测试列表设置就绪
station_entry	开始或结束站位测试
station_setup	为站位测试设置站位
storage_simple_stress	执行命令持续对单个文件进行读写操作
stressapptest	CPU/闪存/存储压力测试
stylus	手写笔功能测试
summary	显示当前站位测试状态
suspend_resume	指定周期性挂起和唤醒设备
sync_factory_server	连接工厂服务器查找可更新的固件，并上传日志
sync_time	时间同步
tablet_mode	平板电脑模式测试
tablet_rotation	屏幕旋转测试
thermal_load	热传感器负载响应测试
thermal_sensors	热传感器测试
thermal_slope	处理器高低温测试
touch_device_fw_update	检查和升级触摸设备固件
touch_uniformity	验证触摸均匀性
touchpad	验证触摸功能
touchpad_hover	触控板测试
touchscreen	通过绘制各种图案来测试触摸屏和手写笔功能
touchscreen_calibration.touchscreen_calibration	ouchscreen_calibration校准测试
tpm_clear_owner	测试下次重启时清除TPM用户
tpm_diagnosis	运行tpm_selftest进行TPM自我诊断
tpm_verify_ek	验证TPM签名密钥
update_cr50_firmware	更新Cr50固件
update_device_data	测试更新Device Data
update_firmware	执行ChromeOS固件升级，强制升级Main(AP)/EC/PD 固件
update_fpmcu_firmware	更新Fingerprint MCU固件
update_kernel	应用到新内核到DUT测试
update_sku	SKU ID和FW Config升级到EEPROM测试
urandom	通过生成伪随机数进行cpu压力测试
usb	usb测试
verify_component	验证外设测试
verify_root_partition	验证分区完整性
video_playback	pytest video_playback
vswr.vswr	VSWR 验证传输效率
vsync	VSync 引脚测试
wait_external_test	检测等待外部夹具测试结束
wait_fixture_ready	验证夹具状态
webgl_aquarium	WebGL 性能测试（包含一系列WebGL相关操作）
whale_check_voltage	电压检测
whale_cover	检查Whale’s cover开启/关闭状态
wifi_check_calibration	从/sys/kernel/debug/ieee80211/phy*/ath9k/dump_eep_power检测wifi校准表
wifi_throughput	WIFI负载测试
wireless_antenna	wifi连接基本功能测试
wireless_connect	测试无线连接
write_device_data_to_vpd	写入设备数据到VPD
write_protect_switch	测试写保护功能

Chrome OS Factory开发测试流程相关推荐

JavaWeb开发测试流程
JavaWeb开发测试流程 1.需求确定(最重要**) 2.分析与设计** (1)架构分析与设计 (2)业务逻辑分析 (3)业务逻辑设计 (4)界面设计 3.开发环境搭建 4.开发-测试-开发-测试 ...
app测试流程和重点_APP开发测试流程是怎么样的？
一款APP产品在上线之后的稳定性,取决于上线之前的软件测试,也就是说在上线之前,能找出更多的软件问题并解决,那么上线以后,APP软件自然就很少出现问题,系统性能自然就更加的稳定.那么正规的测试流程是怎 ...
TIMI游戏工作室开发测试流程
一.天美工作室的2018年游戏收入已超过暴雪等全球游戏厂商收入. 二.工作室平均1-1.5月一个版本三.TIMI工作室开发测试人数比3:1,Google公司是7:1 四.TIMI研发流程:策划产品- ...
chrome os简介
这篇文章是简单学习chrome os系统总结: 1.chrome os简介 Google 推出基于linux的操作系统,特点linux内核,使用第三方开源的代码,运行在chromium浏览器上.该操作 ...
Chrome OS 与 Android 的生死爱欲
Chrome OS 与 Android 融合的月经文,差不多每隔几个月就会出现一次,然而每次融合的声音出现,各大小讨论区都只顾忙于争论 Chrome OS 好不好用.有没有人要买 Chrome OS. ...
初级测试小宝典测试流程，不能复现bug，开发不认为是bug级2020测试点的热点提问的回答
1.测试流程 1.按阶段划分为单元测试,集成测试 ,系统测试,验收测试 2.按是否运行静态测试动态测试 3.按是否查看源代码自盒测试黑盒测试 ...
基于Jenkins的开发测试全流程持续集成实践
今年上半年一直在公司实践CI,本文将上半年来的一些实践总结一下,可能不太完善或优美,但的确初步解决了我目前所在项目组的一些痛点.当然这仅是一家之言也不够完整,后续下半年还会深入实践和引入Kuberne ...
Android 与 Chrome OS 中针对大屏幕设备的更新
随着智能终端硬件的不断革新,大尺寸设备的种类越来越丰富,比如手机.折叠屏设备.平板电脑.ChromeBook.外接显示器的 ChromeBox 和集成屏幕的 Chromebase 等.Google 团 ...
一路相伴，共同成长 | Chrome OS 100 回顾
作者 / Iein Valdez,Google Chrome OS 开发者关系主管 3 月 31 日,我们推出了 Chrome OS 的第 100 个稳定发布版本.一路走来,我们不断发展并成长为一个多 ...
travis ci_如何使用Travis CI和GitHub进行Web开发工作流程
travis ci by Vijayabharathi Balasubramanian 通过Vijayabharathi Balasubramanian 如何使用Travis CI和GitHub进行W ...

Chrome OS Factory开发测试流程

Chrome OS Factory开发测试流程相关推荐

最新文章

热门文章