上次走到了具體測試執行的地方，感覺缺乏一個全域性觀，有點走不下去。

還是再回頭看看整個設計思路，所有的模組文件都可以從這裡訪問到：

使用文件：

http://robotframework.org/robotframework/

介面文件：

http://robot-framework.readthedocs.io/en/3.0.2/autodoc/robot.html

在看這些keywords之前先記錄一下對為什麼要用keywords這種方式而不是傳統的程式設計方式的思考：

1. 有大師曰過，所有的程式設計抽象，本質上都是DSL，也就是最後會變成一種領域專用語言，任何我們呼叫的庫都是。所以keywords本質上也是一種DSL。

2. 作為測試領域的DSL，好的keywords設計可以極大的降低測試的編寫門檻和開發效率

3. 內建的Keywords應該提供一種測試邏輯完備性，包括各種判斷和迴圈

4. kewords使用上由於是基於英文設計的，應該更符合英語使用者的思維，如果有相應的中文版本那就可以更方便中文使用者，當然可以自己開發中文版

Robotframework自帶的預設keywords和庫如下，如果要熟練使用，最好都能仔細看看，尤其是builtin的。

BuiltIn
Contains generic often needed keywords. Imported automatically and thus always available.
Collections
Contains keywords for handling lists and dictionaries.
DateTime
Supports creating and verifying date and time values as well as calculations between them.
Dialogs
Supports pausing the test execution and getting input from users.
OperatingSystem
Enables performing various operating system related tasks.
Process
Supports executing processes in the system.
Remote
Part of the remote library interface. Does not have any keywords of its own.
Screenshot
Provides keywords to capture and store screenshots of the desktop.
String
Library for manipulating strings and verifying their contents.
Telnet
Supports connecting to Telnet servers and executing commands on the opened connections.
XML
Library for verifying and modifying XML documents.

Builtin的keywords可以和應該能夠解決我們平時常用的測試邏輯，如果不行還能夠保持原生python語言的靈活性。用這個思路，看看大概有哪些。

首先提示了，大部分關鍵字都提供了對錯誤資訊的支援，而且可以是HTLML格式的，目的應該是可以讓錯誤資訊更醒目。然後說有些keywords是可以支援python的語句，會用eval執行。內建的keywords如下：

一一看過還是比較花時間，先跳過。

再大概過一下有哪些庫吧：

All packages

All robot packages are listed below. Typically you should not need to import anything from them directly, but the above public APIs may return objects implemented in them.

• run(): Function to run tests.
• run_cli(): Function to run tests with command line argument processing.
• rebot(): Function to post-process outputs.
• rebot_cli(): Function to post-process outputs with command line argument processing.
• libdoc: Module for library documentation generation.
• testdoc: Module for test case documentation generation.
• tidy: Module for test data clean-up and format change.

robot.api對外的API都通過這個模組暴露出來，包括：

• logger module for test libraries’ logging purposes.
• deco module with decorators test libraries can utilize.
• TestCaseFile, TestDataDirectory, and ResourceFile classes for parsing test data files and directories. In addition, a convenience factory method TestData() creates either TestCaseFileor TestDataDirectory objects based on the input.
• TestSuite class for creating executable test suites programmatically and TestSuiteBuilder class for creating such suites based on existing test data on the file system.
• SuiteVisitor abstract class for processing testdata before execution. This can be used as a base for implementing a pre-run modifier that is taken into use with --prerunmodifier commandline option.
• ExecutionResult() factory method for reading execution results from XML output files andResultVisitor abstract class to ease further processing the results. ResultVisitor can also be used as a base for pre-Rebot modifier that is taken into use with --prerebotmodifiercommandline option.
• ResultWriter class for writing reports, logs, XML outputs, and XUnit files. Can write results based on XML outputs on the file system, as well as based on the result objects returned by the ExecutionResult() or an executed TestSuite.

robot.model package

Package with generic, reusable and extensible model classes.

This package contains, for example, TestSuite, TestCase, Keyword and SuiteVisitor base classes. These classes are extended both by execution and result related model objects and used also elsewhere.

robot.running package

Implements the core test execution logic.

The main public entry points of this package are of the following two classes:

• TestSuiteBuilder for creating executable test suites based on existing test case files and directories.
• TestSuite for creating an executable test suite structure programmatically.

It is recommended to import both of these classes via the robot.api package like in the examples below. Also TestCase and Keyword classes used internally by the TestSuite class are part of the public API. In those rare cases where these classes are needed directly, they can be imported from this package.

*** Settings ***
Library    OperatingSystem

*** Test Cases ***
Should Activate Skynet
    [Tags]    smoke
    [Setup]    Set Environment Variable    SKYNET    activated
    Environment Variable Should Be Set    SKYNET

from robot.api import TestSuiteBuilder

suite = TestSuiteBuilder().build('path/to/activate_skynet.robot')

from robot.api import TestSuite

suite = TestSuite('Activate Skynet')
suite.resource.imports.library('OperatingSystem')
test = suite.tests.create('Should Activate Skynet', tags=['smoke'])
test.keywords.create('Set Environment Variable', args=['SKYNET', 'activated'], type='setup')
test.keywords.create('Environment Variable Should Be Set', args=['SKYNET'])

result = suite.run(critical='smoke', output='skynet.xml')

assert result.return_code == 0
assert result.suite.name == 'Activate Skynet'
test = result.suite.tests[0]
assert test.name == 'Should Activate Skynet'
assert test.passed and test.critical
stats = result.suite.statistics
assert stats.critical.total == 1 and stats.critical.failed == 0

from robot.api import ResultWriter

# Report and xUnit files can be generated based on the result object.
ResultWriter(result).write_results(report='skynet.html', log=None)
# Generating log files requires processing the earlier generated output XML.
ResultWriter('skynet.xml').write_results()

好了，今天到這裡，明天繼續，看看有沒有什麼新思路