【odoo14】第十八章、自動化測試

老韓頭的碼字生活發表於2021-03-12

當我們開發大型應用的時候，通過自動化測試可以大幅提高應用的健壯性。每年，odoo都會發布新版本，自動化測試對於應用的迴歸測試非常有幫助。幸運的是，odoo框架有不同自動化測試用例。odoo主要包括三種測試方案:

Python test case: 用於測試Python的業務邏輯測試
JavaScript Qunit test: 用於測試JavaScript的實現
Tours: 用於測試Python和JavaScript的互動情況

本章包含:

新增python測試用例
執行python測試用例
為客戶端側的測試用例配置(Headless Chrome)
新增客戶端側的QUnit測試用例
新增嚮導的測試用例
執行客戶端側的測試用用例
除錯測試端側的測試用例
為失敗的測試用例生成視訊或螢幕截圖
為測試填充隨機資料

技術需求

本章，我們將詳細討論測試用例的情況。為了能覆蓋所有的應用場景，我們建立了一個新的模型。模型如下:

class LibraryBook(models.Model):
    _name = 'library.book'
    name = fields.Char('Title', required=True) 
    date_release = fields.Date('Release Date') 
    author_ids = fields.Many2many('res.partner',
    string='Authors')
    state = fields.Selection(
    [('draft', 'Not Available'), ('available', 'Available'), ('lost', 'Lost')],
    'State', default="draft") color = fields.Integer()
def make_available(self): 
    self.write({'state': 'available'})
def make_lost(self): 
    self.write({'state': 'lost'})

對於JavaScript的測試用例，我們將使用第十五章中"建立使用者小部件"一節中的int_color小部件。
你可以在 (github)[ https://github.com/PacktPublishing/Odoo-14-Development-Cookbook-Fourth-Edition/tree/master/Chapter18/00_initial_module]

新增python測試用例

Python的測試用例用於測試業務邏輯的可用性。第五章，“伺服器側開發-基礎篇”，我們瞭解瞭如何調整現有業務邏輯。由於對現有模型的修改有可能會破壞原有的邏輯，測試就顯得尤為重要。在本節，我們將建立用於驗證改變圖書狀態的業務邏輯。

準備

步驟

新增檔案tests/__init__.py

from . import test_book_state

新增tests/test_book_state.py檔案

from odoo.tests.common import TransactionCase

class TestBookState(TransactionCase):
	
	def setUp(self, *args, **kwargs):
		super(TestBookState, self).setUp(*args, **kwargs)
		self.test_book = self.env['library.book'].create({'name': 'Book 1'})
		
	def test_button_available(self):
		'''Make available button'''
		self.test_book.make_available()
		self.assertEqual( self.test_book.state,  'available', 'Book state should be changed to available')
	
	def test_button_lost(self):
		'''Make lost button'''
		self.test_book.make_lost()
		self.assertEqual( self.test_book.state, 'lost', 'Book state should be changed to lost')

執行測試用例

./odoo-bin -c server.conf -i my_library --test-enable

檢視執行日誌，測試用例資訊如下

... INFO test odoo.addons.my_library.tests.test_ book_state: Starting TestBookState.test_button_available ...
... INFO test odoo.addons.my_library.tests.test_book_state: Starting TestBookState.test_button_lost ...
... INFO test odoo.modules.loading: Module my_library loaded in 0.79s (incl. 0.12s test), 179 queries (+10 test)

如果報錯，"INFO"》》"ERROR"。

原理

在odoo中，測試用例新增在tests/目錄。odoo將自動識別該目錄並執行測試用例。

注意
我們需要在tests/__init__.py檔案中新增我們的測試用例。

Odoo中使用了python的unittest包。詳細瞭解見 https://docs.python.org/3.5/library/ unittest.html。odoo通過對unittest的簡單封裝，實現了多個非常有幫助的類，可用於簡化測試用例。在我們的例子中，我們使用了TransactionCase。現在TransactionCase可在單獨的食物中執行測試用例。在測試用例執行成功後，將會回滾。意味著，下一個測試用例也將在初始化的環境下執行。
以test_開頭的類方法將被認為是測試用例。在我們的例子中，我們新增了兩個測試用例。可用於檢查圖書的狀態。self.assertEqual方法可用於檢查測試用例是否執行正常。

重要資訊
setUp()方法將在每一個測試用例前執行，因此在本節，我們新增了兩個測試用例，因此setUp()將呼叫兩次。TransactionCase將負責在每次測試用例執行完後進行回滾。

測試單元中還提供瞭如下測試類:

SingleTransactionCase: 所有的測試用例將在一個事務中執行，因此第一個測試用例中對記錄的修改將體現在第二個測試用例中。所有的測試用例執行完成後再進行回滾。
SavepointCase: 測試用例將執行在特定的場景下(對記錄進行修改後save point，然後測試用例在此基礎上進行測試)。這可確保在進行大型的測試時，可快速的生成測試資料。我們可通過setUpClass()類進行生產測試資料。

執行python測試用例

當我們在啟動odoo例項時傳入--test-enabled，測試用例將在模組完成安裝後立刻執行。如果你想在所有的模組完成安裝後再執行，或者僅想執行某一個模組的測試用例，可通過tagged()裝飾器實現。本章，我們將介紹如何使用該裝飾器。

準備

步驟

新增tagged()裝飾器，並在所有模組完成安裝後執行

from odoo.tests.common import TransactionCase, tagged

@tagged('-at_install', 'post_install')
class TestBookState(TransactionCase):
···

執行測試用例

./odoo-bin -c server.conf -i my_library --test-enable

檢查服務日誌，顯示如下:

... INFO book odoo.modules.loading: 9 modules loaded in 1.87s, 177 queries (+0 extra)
... INFO book odoo.modules.loading: Modules loaded.
... INFO book odoo.service.server: Starting post tests
... INFO book odoo.addons.my_library.tests.test_book_ state: Starting TestBookState.test_button_available ...
... INFO book odoo.addons.my_library.tests.test_book_ state: Starting TestBookState.test_button_lost ...
... INFO book odoo.service.server: 2 post-tests in 0.14s, 10 queries

如上顯示在所有模組完成安裝後(post_install)執行測試用例。

原理

預設，測試用例被標記為standard, at_install及模組的名稱。因此，如果你並沒有使用tagged裝飾器，將預設是如上標識。
在我們的案例中，我們希望在安裝所有模組之後執行測試用例。為此，我們向TestBookState類新增了一個tagged()裝飾器。預設情況下，測試用例具有at_install標記。由於這個標記，您的測試用例將在模組安裝後立即執行;它不會等待其他模組被安裝。我們不希望這樣，所以為了刪除at_install標記，我們向標記函式新增了-at_install。以-為字首的標籤將刪除該標籤。
通過向tagged()函式新增-at_install，我們在模組安裝後停止了測試用例的執行。由於我們沒有在這裡指定任何其他標記，測試用例將不會執行。
因此，我們新增了一個post_install標記。這個標記指定測試用例需要在所有模組安裝完成後執行。
如您所見，預設情況下，所有的測試用例都是用標準標記標記的。Odoo將執行所有用標準標籤標記的測試用例，以防您不想一直執行特定的測試用例，而只想在被請求時執行測試用例。要做到這一點，你需要通過在tagged()裝飾器中新增-standard來移除standard標籤，你需要新增一個像這樣的自定義標籤:

@tagged('-standard', 'my_custom_tag')
class TestClass(TransactionCase):
···

在使用--test-enable時所有非標的測試用例將不會執行。可通過--test-tags=name執行目標測試用例，如下:

./odoo-bin -c server.conf -i my_library --test-tags=my_custom_ tag

在測試用例的開發過程中，只為一個模組執行測試用例是很重要的。預設情況下，模組的技術名稱是作為標記新增的，因此可以使用模組的技術名稱和--test-tags選項。例如，如果你想為my_library模組執行測試用例，那麼你可以這樣執行伺服器:

./odoo-bin -c server.conf -i my_library --test-tags=my_library

這裡給出的命令將執行my_library模組中測試用例，但是它仍然會根據at_install和post_install選項來決定順序。

為客戶端側的測試用例配置Headless Chrome

Odoo使用Headless Chrome來執行JavaScript測試用例和tour測試用例。Headless Chrome是一種不需要完整UI就可以執行Chrome的方法。這樣，我們就可以在與終端使用者相同的環境中執行JavaScript測試用例。在這個食譜中，我們將安裝Headless Chrome和其他包來執行JavaScript測試用例。

步驟

您將需要安裝Chrome來啟用JavaScript測試用例。對於模組的開發，我們主要使用桌面作業系統。因此，如果你的系統上安裝了Chrome瀏覽器，那麼就不需要單獨安裝。您可以使用桌面Chrome執行客戶端測試用例。請確保您的Chrome版本高於Chrome 59。Odoo也支援Chromium瀏覽器。

小貼士
Headless Chrome客戶端測試用例在macOS和Linux上執行良好，但Odoo不支援Windows上的Headless Chrome測試用例。

當您想要在生產伺服器或伺服器作業系統上執行測試用例時，情況會略有變化。伺服器作業系統沒有GUI，所以你需要安裝不同的Chrome。如果你使用的是基於debian的作業系統，你可以使用以下命令安裝Chromium:

apt-get install chromium-browser

重要資訊
Ubuntu 18.04伺服器版預設沒有啟用universe儲存庫。因此，有可能安裝鉻瀏覽器將顯示安裝候選錯誤。要修復此錯誤，可以使用以下命令啟用universe儲存庫:sudo add-apt-repository universe。

Odoo還支援WebSockets用於JavaScript測試用例。為此，Odoo使用websocket客戶端Python庫。要安裝它，使用以下命令:

pip3 install websocket-client

原理

Odoo使用無頭瀏覽器進行JavaScript測試用例。這背後的原因是它在後臺執行測試用例，所以它也可以在伺服器作業系統上執行。Headless Chrome更喜歡在後臺執行Chrome瀏覽器，而不需要開啟GUI瀏覽器。Odoo在後臺開啟一個Chrome標籤，並開始執行測試用例。它還使用jQuery的QUnit來進行JavaScript測試用例。在接下來的幾個食譜中，我們將為自定義JavaScript小部件建立一個QUnit測試用例。
對於測試用例，Odoo在一個單獨的程式中開啟了Headless Chrome，所以為了找到在這個程式中執行的測試用例的狀態，Odoo伺服器使用WebSockets。websocket-client Python庫用於管理WebSockets，以便從Odoo伺服器與Chrome通訊。

新增客戶端側的QUnit測試用例

在Odoo中，建立新的領域或檢視是非常簡單的。只需幾行XML，就可以定義一個新的檢視。然而，在底層，它使用了大量的JavaScript。在客戶端修改/新增新特性是複雜的，可能會破壞一些東西。大多數客戶端問題不會被注意到，因為大多數錯誤只顯示在控制檯中。因此，在Odoo中使用QUnit測試用例來檢查不同JavaScript元件的正確性。

準備

步驟

按照以下步驟向int_color小部件新增JavaScript測試用例:

新增/static/tests/colorpicker_tests.js

odoo.define('colorpicker_tests', function(require){
    'use strict';
    
    var FormView = require('web.FormView');
    var testUtils = require('web.test_utils');

    Qunit.module('Color Picker Tests',{
        beforeEach: function(){
            this.data = {
                book: {
                    fields: {
                        name: {string:"Name", type:"char"},
                        color: {string:"color", type:"integer"},
                    },
                    records: [
                        {id:1, name:'Book 1', color: 1},
                        {id:2, name:'Book 2', color: 3}
                    ]
                }
            };
        }
    }, function(){
        // 步驟2中內容
    });
});

新增QUnit測試用例:

QUnit.only('int_color field test cases', async function (assert) {
    assert.expect(2);
    var form = await testUtils.createView({
        View: FormView,
        model: 'book',
        data: this.data,
        arch: '<form string="Books">' +
            '<group>' +
            '<field name="name"/>' +
            '<field name="color" widget="int_color"/>' +
            '</group>' +
            '</form>',
        res_id: 1,
    });
    await testUtils.form.clickEdit(form);
    assert.strictEqual(form.$('.o_int_colorpicker .o_ color_pill').length, 10, "colorpicker should have 10 pills");
    await testUtils.dom.click(form.$('.o_int_colorpicker .o_color_pill:eq(5)'));
    assert.strictEqual(form.$('.o_int_colorpicker .o_ color_5').hasClass('active'), true,
        "click on pill should make pill active");
    form.destroy();
});

在/views/template.xml註冊測試檔案

<template id="qunit_suite" name="colorpicker test" inherit_id="web.qunit_suite">
    <xpath expr="." position="inside">
        <script type="text/javascript" src="/my_library/static/tests/ colorpicker_tests.js" />
    </xpath>
</template>

執行測試用例

./odoo-bin -c server.conf -i my_library,web --test-enable

檢查日誌

... INFO test odoo.addons.web.tests.test_js.WebSuite: console log: "Color Picker Tests" passed 2 tests.

原理

在odoo中，JavaScript測試用例新增在/static/tests目錄中。步驟1，我們新增了colorpicker_tests.js檔案。我們引入了formView及test_utils。因為我們建立的ini_color小部件是作用於form檢視的，因此我們還需要引入web.FormView。
web.test_utils為我們提供了構建js測試用例的實體。如果你不瞭解js的引入機制，可參考第十四章"擴充套件CSS及JavaScript"。
odoo的客戶端測試用例是通過QUit框架實現了，它是用於JS單元測試的JQuery框架。參考https://qunitjs.com/。beforeEach函式會執行測試用例前執行，可用於初始化測試資料。函式由QUit框架提供。
我們在beforeEach函式中初始化了一些資料。客戶端測試用例是執行在一個獨立(mock)的環境中，它並不與資料庫進行互動。因此，我們需要建立一些測試資料。在內部，odoo建立了虛擬環境模擬RPC，this.data模式資料庫。this.data中的keys相當於資料庫中表，values相當於表中的欄位及行。在我們的例子中，我們新增了book的表，book表有兩個欄位name(char)及color(integer)。在這，我們可以使用所有的欄位型別，比如，{string:"M2oField", type:"many2one", relation:"partner"}。我們在records中新增了兩條記錄。
下一步，我們藉助Quit.test函式建立了測試用例。函式的第一個引數是string型別，用於描述測試用例的用途。第二個引數是具體測試用例程式碼邏輯的函式。函式由QUnit框架呼叫，assert例項作為引數傳遞到函式體內。在我們的例子中，我們在assert.expect函式中傳入了測試用例的個數。我們一共有兩個測試用例，因此我們傳入2。
我們計劃測試編輯模式下的int_color小部件。所以我們通過testUtils.createView建立了編輯模式下的form檢視。createView接收不同引數:

View: 我們建立的檢視。
model: 檢視作用於的模型的名稱。
data: 模擬資料。
arch: 檢視的定義內容。
res_id: 展示的記錄的ID。該選項作用於form檢視。在我們的案例中，form檢視展示book 1的資料，因為res_id為1。

在使用int_color小部件建立表單檢視之後，我們新增了兩個測試用例。第一個測試用例用於檢查UI上彩色藥片的數量，第二個測試用例用於檢查藥片在單擊後是否被正確啟用。我們從斷言的QUnit框架的效用中得到了嚴格的函式。如果前兩個引數匹配，則strictEqual函式通過測試用例。如果它們不匹配，則測試用例將失敗。

還有一些assert函式可以用於QUnit測試用例，比如assert.deepEqual,assert.ok,assert.notOk。要了解有關QUnit的更多資訊，請參閱https://qunitjs.com/上的文件。

新增嚮導的測試用例

現在您已經看到了Python和JavaScript測試用例。它們都在一個孤立的環境中工作，它們彼此之間不相互作用。為了測試JavaScript和Python程式碼之間的整合，使用了嚮導測試用例。

準備

對於本節，我們將繼續使用上一節中的my_library模組。我們將新增一個巡迴測試用例來檢查圖書模型的流程。另外，確保您已經安裝了web_tour模組，或者已經將web_tour模組依賴項新增到清單中。

步驟

按照以下步驟新增圖書的嚮導測試用例:

新增一個/static/src/js/my_library_tour.js檔案:

odoo.define('my_library.tour', function (require) {
    "use strict";
    var core = require('web.core');
    var tour = require('web_tour.tour');
    var _t = core._t;
    tour.register('library_tour', {
        url: "/web",
        test: true,
        rainbowManMessage: _t("Congrats, you have listed a book."),
        sequence: 5,
    }, [tour.stepUtils.showAppsMenuItem(), // Place step 3 here
    ]);
});

新增測試步驟

{
    trigger: '.o_app[data-menu-xmlid="my_library.library_ base_menu"]',
    content: _t('Manage books and authors in <b>Library app</b>.'),
    position: 'right'
}, {
    trigger: '.o_list_button_add',
    content: _t("Let's create new book."),
    position: 'bottom',
}, {
    trigger: 'input[name="name"]',
    extra_trigger: '.o_form_editable',
    content: _t('Set the book title'),
    position: 'right',
    run: function (actions) {
        actions.text('Test Book');
    },
}, {
    trigger: '.o_form_button_save',
    content: _t('Save this book record'),
    position: 'bottom',
}

新增到test資源

<template id="assets_tests" name="Library Assets Tests" inherit_id="web.assets_tests">
    <xpath expr="." position="inside">
        <script type="text/javascript" src="/my_library/ static/tests/my_library_tour.js" />
    </xpath>
</template>

新增一個/tests/test_tour.py檔案，通過HttpCase執行tour，如下所示:

from odoo.tests.common
import HttpCase, tagged class TestBookUI(HttpCase):
    @tagged('post_install', '-at_install') 
    def test_01_book_tour(self):
    """Books UI tour test case"""
    self.browser_js("/web",
        "odoo.__DEBUG__.services['web_tour.tour']. run('library_tour')",
        "odoo.__DEBUG__.services['web_tour.tour']. tours.library_tour.ready",
        login = "admin")

執行測試用例

./odoo-bin -c server.conf -i my_library --test-enable

執行日誌如下:

...INFO test odoo.addons.my_library.tests.test_tour.TestBookUI: console log: Tour library_tour succeeded

原理

為了建立tour測試用例，您需要首先建立UI tour。如果你想了解更多關於UI tours的資訊，請參考第15章“Web客戶端開發”中的通過嚮導提升互動感一節。
步驟1，我們用library_tour註冊了一個新的tour。
步驟2，我們為嚮導測試用例新增了步驟。
與之前的嚮導案例相比，這裡有兩個主要變化。首先，我們為嚮導定義新增了一個test=true引數;其次，我們新增了一個額外的屬性，run。在run函式中，您必須編寫邏輯來執行通常由使用者執行的操作。例如，在嚮導的第四步中，我們要求使用者輸入書名。
為了自動化這個步驟，我們新增了一個run函式來設定title欄位中的值。run函式將操作實用程式作為引數傳遞。這提供了一些執行基本操作的快捷方式。最重要的問題如下:

actions.click(element): 點選元素
actions.dblclick(element): 雙擊元素
actions.tripleclick(element): 三擊元素
actions.text(string): 設定input的值
actions.drag_and_drop(to, element):拖放元素
actions.keydown(keyCodes, element): 在元素上觸發特定的按鍵事件
actions.auto(): 預設動作。當在tour步驟中沒有傳遞run函式時，將執行actions.auto()。這通常會單擊步驟中觸發的元素。這裡唯一的例外是輸入元素。如果觸發的是input，那麼tour將在輸入中設定預設值Test。這就是為什麼我們不需要向所有步驟新增run函式。
另外，如果預設操作不夠，您也可以手動執行整個操作。在下一個步驟中，我們想要為顏色選擇器設定一個值。注意，我們使用的是手動操作，因為預設值在這裡不起作用。因此，我們使用基本的jQuery程式碼新增了run方法來單擊顏色選擇器的第三個顏色圓點。在這裡，可通過this.$archor屬性獲取需觸發的元素。
預設情況下，註冊的嚮導將提高終端使用者的互動體驗。為了測試它們，你需要在Headless Chrome中執行它們。為此，您需要使用HttpCase觸發測試用例。這提供了browser_ js方法，該方法開啟URL並執行作為第二個引數傳遞的命令。如下所示:

odoo.__DEBUG__.services['web_tour.tour'].run('library_tour')

在我們的示例中，嚮導測試用例的名稱將作為browser_js的第一個引數。隨後的引數待執行的測試用用例，最後一個引數是執行測試用例使用者名稱。

執行客戶端側的測試用用例

odoo提供了通過UI執行客戶端測試用例的方法，我們可以看到測試用例每一步的執行情況。

步驟

我們可以通過UI執行QUit和嚮導測試用例。我們可以啟用開發者模式，檢視通過UI執行的選項。

通過UI執行QUit測試用例

點選BUG圖示，選擇Run JS Tests，如下:

這會開啟QUit例項，並逐個執行測試用例，如下圖。預設，僅展示測試失敗的用例。如果想顯示所有的測試用例，取消Hide passed tests選項。

通過UI執行嚮導測試

點選BUG圖示，選擇Start Tour，如下:

將展示嚮導測試用例的列表，我們可點選後面的start啟動相應的測試用例:

如果您啟用了測試資產模式，那麼測試之旅只會顯示在列表中。如果在列表中沒有找到library_tour，請確保已啟用測試資產模式。

原理

QUnit的UI是由QUnit框架本身提供的。在這裡，您可以為模組篩選測試用例。您甚至可以為一個模組執行一個測試用例。通過UI，您可以看到每個測試用例的進度，並且可以深入到測試用例的每個步驟。在內部，Odoo只是在Headless Chrome開啟相同的URL。
點選Run tours選項將顯示可用的tours列表。通過點選列表上的播放按鈕，您可以執行嚮導測試用例。注意，當嚮導通過命令列選項執行時，它將在回滾事務中執行，因此在嚮導成功後，通過嚮導所做的更改將被回滾。但是，當tour從UI執行時，它的工作方式就像使用者正在操作它一樣，這意味著tour所做的更改不會回滾並停留在那裡，所以要小心使用這個選項。

除錯測試端側的測試用例

開發複雜的客戶端測試用例是件非常頭痛的事。本節，我們將學習如何除錯客戶端測試用例，如何執行其中一個測試用例。

準備

步驟

用QUit.onlg替換/static/tests/colorpicker_tests.js中的QUit.test測試方法:

QUnit.only('int_color field test cases', function (assert) {

在createView中新增debug引數如下:

var form = testUtils.createView({ 
	View: FormView,
	model: 'book',
	data: this.data,
	arch: '<form string="Books">' +
		'<group>' +
		'<field name="name"/>' +
		'<field name="color" widget="int_color"/>' +
		'</group>' +
		'</form>', 
	res_id: 1,
	debug:true
});

點選 Run JS Tests:

原理

步驟1，我們用QUnit.only替換了QUnit.test。這將只執行這個測試用例。在測試用例的開發過程中，這可以節省時間。注意，使用QUnit.only將會終止通過命令列選項執行的測試用例。這隻能用於除錯或測試，並且只能在從UI開啟測試用例時使用，所以不要忘記在開發完成後將其替換為QUnit.test。
在我們的QUnit測試用例示例中，我們建立了表單檢視來測試int_ color小部件。如果您在UI中執行QUnit測試用例，您將瞭解到您不能在UI中看到建立的表單檢視。在QUnit套件的UI中，您只能看到日誌。這使得開發QUnit測試用例非常困難。為了解決這個問題，在createView函式中使用了debug引數。在步驟2中，我們在createView函式中新增了debug: true。這將在瀏覽器中顯示test form檢視。在這裡，您可以通過瀏覽器偵錯程式定位文件物件模型(Document Object Model, DOM)元素。

警告
在測試用例的最後，我們通過destroy()方法銷燬檢視。如果您已經銷燬了檢視，那麼您將無法在UI中看到表單檢視，因此為了在瀏覽器中看到它，請在開發期間刪除這一行。這將幫助您除錯測試用例。

為失敗的測試用例生成視訊或螢幕截圖

Odoo使用headless CHrome。這開啟了新的可能性。從Odoo 12開始，您可以錄製失敗的測試用例的視訊，也可以對失敗的測試用例進行截圖。

步驟

為測試用例錄製視訊需要一個ffmpeg包。

安裝包

apt-get install ffmpeg

要生成視訊或螢幕截圖，您需要提供一個目錄位置來儲存視訊或螢幕截圖。
如果你想生成一個測試用例的截圖(視訊)，使用——截圖命令，如下:

./odoo-bin -c server.conf -i my_library --test-enable --screencasts=/home/pga/odoo_test/

如果你想生成一個測試用例的截圖，使用——screenshosts命令，如下:

./odoo-bin -c server.conf -i my_library --test-enable --screenshots=/home/pga/odoo_test/

原理

為了為失敗的測試案例生成截圖/截圖，您需要使用儲存視訊或影像檔案的路徑執行伺服器。當您執行測試用例時，如果測試用例失敗了，Odoo將在給定目錄中儲存失敗測試用例的截圖/視訊。
為了生成測試用例的視訊，Odoo使用了ffmpeg包。如果您沒有在伺服器上安裝這個包，那麼它將只儲存一個失敗的測試用例的截圖。在安裝這個包之後，您將能夠看到任何失敗的測試用例的mp4檔案。

小貼士
為測試用例生成視訊會佔用磁碟上更多的空間，所以請謹慎使用此選項，並且只在確實需要時使用。

請記住，螢幕截圖和視訊只會為失敗的測試用例生成，所以如果您想要測試它們，您需要編寫一個失敗的測試用例。

為測試填充隨機資料

到目前為止，我們已經看到了用於檢測業務邏輯中的錯誤或bug的測試用例。然而，有時我們需要用大量的資料來測試我們的開發。生成大量資料可能是一項乏味的工作。Odoo提供了一套工具，可以幫助您為模型生成大量隨機資料。在本節，我們將使用populate命令為library.book模型生成測試資料。

準備

對於本節，我們將繼續使用上一節的my_library模組。我們將新增_populate_factories方法，它將用於生成測試資料。

步驟

在my_library模組中新增populate資料夾，新增__init__.py檔案。

from . import library_data

新增my_library/populate/library_data.py檔案:

from odoo import models
from odoo.tools import populate


class BookData(models.Model):
    _inherit = "library.book"
    _populate_sizes = {"small": 10, "medium": 100, "large": 500}

    def _populate_factories(self):
        return [
            ("name", populate.constant("Book no {counter}")),
        ]

執行命令

./odoo-bin populate -–models=library.book –-size=medium -c server.conf -i my_library

這將為圖書生成100個單位的資料。生成資料後，流程將被終止。要檢視該書的資料，執行不帶填充引數的命令。

原理

步驟1，新增生成資料檔案目錄。
步驟2，新增生成資料程式碼。使用populate_factories生成隨機資料。_populate_factories方法返回模型欄位的工廠，這些工廠將用於生成隨機資料。模型具有必需的name欄位，因此在我們的示例中，我們返回了name欄位的生成器。這個生成器將用於為圖書記錄生成隨機資料。我們已經使用了populate.constant;當我們在資料生成過程中進行迭代時，這將生成不同的名稱。
除了populate.constant，Odoo提供了其他幾個生成器來填充資料，如下:

populate.randomize(list):從給定的列表返回隨機元素
populate.cartesian(list): 與randomize類似，但儘可能保所列表中所有的內容。
populate.constant(str): 用於生成格式化字串。還可以傳遞formatter引數來格式化值。預設情況下，格式化程式是一個字串格式函式。
populate.compute(function): 當您想要根據您的函式計算一個值時使用。
populate.randint(a, b): 用於在a和b引數之間生成一個隨機數。

另一個重要的屬性是_populate_sizes。基於--size引數，表示想要生成的資料的數量。
步驟3，我們生成了圖書的模型。為了生成測試資料，我們需要使用--size和--model引數。odoo將使用_populate方法生成隨機記錄。_populate方法呼叫_populate_factories方法生成隨機資料。

小貼士
如果多次執行populate命令，資料也將生成多次。小心使用這一點非常重要:如果在生產資料庫中執行該命令，它將在生產資料庫中生成測試資料。這是你要避免的。

有時，您也希望生成關係資料。例如，對於書籍，您可能還希望建立作者或租借記錄。要管理這樣的記錄，可以使用_populate_dependencies屬性:

class BookData(models.Model):
	_inherit = 'library.book'
	_populate_sizes = {'small': 10, 'medium': 100, 'large': 500}
	_populate_dependencies = ['res.users', 'res.company']

這將在填充當前模型之前填充依賴項資料。一旦完成，你可以通過populated_models登錄檔訪問已填充的資料:

company_ids = self.env.registry.populated_models['res.company']

這裡給出的行將為您提供在為當前模型生成測試資料之前填充的公司列表。

自動化測試系列 —— UI自動化測試
2024-04-01
UI
【自動化測試入門】自動化測試思維
2020-08-23
自動化裝置測試與自動化測試的區別
2020-11-12
如何做自動化測試？什麼是自動化測試？
2020-12-11
軟體測試:自動化測試
2019-08-02
API自動化測試
2023-11-07
API
自動化測試框架
2020-10-19
框架
自動化測試理解
2020-04-04
自動化測試思路
2019-05-11
介面自動化測試
2021-01-10
airTest自動化測試
2018-11-01
AI
selenium自動化測試
2018-09-03
自動化測試篇
2018-07-10
python自動化測試
2018-08-07
Python
jest 自動化測試
2018-04-19
測試開發之自動化篇-自動化測試框架設計
2021-10-28
框架
如何學習自動化測試？從手工測試到自動化測試的過程…
2021-08-04
自動化測試面試點
2024-08-12
面試
自動化測試系列（三）|UI測試
2021-09-28
UI
手工測試和自動化測試 Battle
2020-08-05
BAT
小程式自動化測試--測試3
2018-06-24
“自動化測試解放雙手”，測試自動化好處大盤點！
2020-10-08
Web自動化-Selenium自動化測試-4-編寫測試用例
2020-12-03
Web
自動化測試工具QTP
2024-10-31
QT
自動化測試平臺
2024-06-12
面經-自動化測試
2024-05-31
Python 介面自動化測試
2019-09-09
Python
淺談自動化測試
2020-02-17
Selenium自動化測試（3）
2020-09-27
自動化測試的方向
2020-11-26
採用自動化測試的情形及自動化測試的優缺點
2019-08-19
API自動化測試平臺，高效實現對API的自動化測試
2021-08-16
API
AutoRunner 功能自動化測試專案實訓之自動化測試原理（一）
2020-12-04
自動化測試如何管理測試資料
2023-03-13
利用tox打造自動自動化測試框架
2020-07-19
框架
功能測試、自動化測試、效能測試的區別
2024-03-06
軟體自動化測試有什麼優勢?自動化測試框架有哪些?
2023-05-15
框架
2023年好用的自動化測試框架有哪些?如何提高自動化測試效果?
2023-03-10
框架