企業環境下的OpenStack自動化功能測試（轉載）

時間 2019-11-30

原文原文鏈接

原文地址：http://mp.weixin.qq.com/s?__biz=MzAxOTAzMDEwMA==&mid=2652502581&idx=1&sn=0c26519bcbb48efa44d916a08e2fa046&chksm=8020130eb7579a1880365bda09c1fc0be1059ff69bcc6f8300b40ac4c98b412a1f880b4d97fd&mpshare=1&scene=23&srcid=0410qVBJvXGbJLbLzyuTiWyK#rdhtml

1、OpenStack測試概要

隨着，雲計算在國內外的迅猛發展，OpenStack業已成爲這方面的既定事實標準，而衆多企業在基於OpenStack開發雲產品時，天然地，對測試方面的需求和質量提出了更高的要求。前端

目前，OpenStack社區已有近百個項目、數千名開發人員、數千萬行代碼和數百家公司參與其中。如何確保如此衆多且水平不一樣、目的不一樣的開發人員，按照某種規則貢獻智慧、提交代碼，促進OpenStack開源社區有序、穩定健康發展。爲此，社區在CI（持續集成）中提出了一種規則，——Gate，即門禁系統之意。凡開發人員提交代碼（站在門外），均務必測試成功後（門禁系統驗證身份經過），代碼纔會進入到Git倉庫中（站在門內）。python

OpenStack測試，是一個涉及層面很是普遍和多技術交叉應用的領域。根據不一樣層面，即緯度的劃分主要有：單元測試——>功能測試（也稱爲集成測試）——>系統測試（如驗收測試、性能測試）等。根據特定的測試對象和目標，又能夠分爲存儲測試、虛擬機網絡測試、故障HA測試等。以下圖所示。git

在測試方面，OpenStack社區作得很是完善，針對不一樣的測試層面，設計並實現了相應的測試工具或項目。具體如，使用Python PEP8等測試代碼編寫是否符合規範，Nose等框架用於單元測試、Tempest用於功能/集成測試、Rally用於性能測試、Shaker用於虛擬機網絡測試、DevStack用於部署測試等，除此外，還有各類環境兼容性測試，如Python2.7和Python3.四、Centos系和Debian系等環境測試。github

2、OpenStack功能測試設計與實現

以上，是對OpenStack測試的概要介紹，是一個面。這裏，針對一個點進行詳細闡述，即便用Tempest自動化測試OpenStack的功能，具體包括測試Keystone、Glance、Cinder、Nova、Neutron和Swift等項目功能。docker

因爲Tempest大部分功能社區已經開發實現，因此在企業的研發測試環境下，用戶能夠按照本身的需求進行擴展使用等。目前，Tempest已普遍應用於CI持續集成、OpenStack社區互操做性測試認證等領域。swift

1.在Docker中運行Tempest

「工欲善其事，必先利其器」。首先，須要安裝並配置好Tempest測試環境，因爲Docker具備輕量、環境隔離、一次打包到處運行的優秀特性，故此，這裏選擇將Tempest安裝部署在Docker容器中。vim

舉個簡單例子，當測試A環境的OpenStack時，須要構建好一個諸如Tempest在內的測試平臺；當測試B環境的OpenStack時，又須要構建好一個一樣的測試平臺；同時，因不一樣環境的反覆配置容易致使測試環境配置錯誤。綜上，選擇Docker運行是一種更好的方式。後端

Tempest測試的實現是基於Python的unittest2和nose框架。經過對Openstack後端發起一系列API請求，而且對後端的響應進行驗證。Tempest使用config配置文件來描述整個測試環境，包括Nova 、Keystone、Glance、Neutron等OpenStack相關服務。並同時支持 JSON、XML 兩種 REST API 格式類型的測試，以及 CLI 測試。centos

Tempest的優勢

Tempest能夠自動尋找，執行測試：自動查找當前目錄下全部以[Tt]est開頭的Python源文件，而且按此規則遞歸查找子目錄；全部以[Tt]est開頭的Python源文件裏全部以[Tt]est開頭的function和class，以及繼承自unittest.TestCase的class(不須要以[Tt]est開頭)都會被執行。
Tempest能夠指定文件、模塊、函數進行測試。
Tempest能夠指定類型進行測試。
Tempest可擴展性強，能夠方便的在tempest中添加其餘測試用例，能夠整合其餘類型測試例如壓力測試、場景測試等。
Tempest是經過nose驅動的，python語言編寫，使用testtools和testresources等幾個測試工具庫
Tempest.test.BaseTestCase,BaseTestCase聲明config屬性,讀取配置文件
Tempest.test.TestCase聲明不少工具函數，供調用。每一個測試能夠分別測試JSON格式和XML格式

固然，它的缺點是須要手動配置tempest.conf環境描述文件，工做量大，容易出錯。

Tempest 代碼主要結構，以下所示。其中，api和scenario部分的測試用例是咱們關注的重點。

tempest/
├── etc/        <--tempest相關配置文件目錄
├── tempest/       <--各個組件測試用例
    ├── api      <--OpenStack組件API接口測試用例 
    ├── common       <--測試通用類例如Rest Client
    ├── hacking     <--用於代碼風格檢測，如 pep8等
    ├── scenario    <--根據一些複雜場景進行測試，屬於系統測試
    ├── services    <--給相應的組件提供模塊接口
    ├── stress      <--壓力測試，目前能夠結合rally進行壓力測試
    ├── test_discover <--繼承unittest，從api等處查找用例
    ├── tests      <--針對tempest代碼自己的單元測試
├── tools/       <--搭建環境的腳本

測試用例和REST API交互流程，以下圖所示。

1）安裝Docker和Tempest

# yum install docker -y

編寫dockerfile文件，用於構建Tempest鏡像,內容以下所示

# cat dockerfile
FROM centos:7
MAINTAINER Xuchao <test@126.com>

# Install dependencies  tools
RUN yum -y install epel-release
RUN yum install -y gcc git libxslt-devel openssl-devel 
RUN yum install -y libffi-devel python-devel python-pip python-virtualenv
RUN pip install junitxml

# Cloning tempest
RUN git clone https://github.com/openstack/tempest.git

# Installing tempest dependencies
RUN cd tempest && python setup.py install
RUN pip install -r /tempest/requirements.txt
RUN pip install -r /tempest/test-requirements.txt

# Generate configuration files
RUN pip install tox
RUN cd tempest && tox -egenconfig

# Copy sample configuration
RUN cp tempest/etc/{tempest.conf.sample,tempest.conf}
RUN cp tempest/etc/{accounts.yaml.sample,accounts.yaml}

# Running tempest setup
RUN cd tempest && testr init

WORKDIR /tempest

執行鏡像構建命令

# docker build -t tempest_docker:1.0 .

查看構建的鏡像

# docker images | grep tempest
tempest_docker  1.0   02970e7ee390  5 hours ago  763.2 MB

之後臺運行方式啓動Tempest鏡像

# docker run -d -it tempest_docker:1.0 /bin/bash

查看運行中的Tempest容器

# docker ps | grep tempest
0a5cf6c1d4b8 tempest_docker:1.0  "/bin/bash"  49 seconds ago  Up 48 seconds silly_kilby8

進入到Tempest容器中，進行操做

# docker exec -u root -it 0a5cf6c1d4b8 bash

2）配置文件使用tempest，須要配置tempest.conf和accounts.yaml兩個文件。

這裏，首先配置accounts.yaml文件。該文件內容包括了Tempest測試OpenStack所須要的認證信息，如租戶、用戶和密碼等信息。示例以下：

# egrep "^[^#]" accounts.yaml
- username: 'demo1'
  tenant_name: 'demo1'
  password: '123456'
- username: 'demo2'
  tenant_name: 'demo2'
  password: '123456'
- username: 'demo3'
  tenant_name: 'demo3'
  password: '123456'
  roles:
    - 'fun_role'
- username: 'swift _user'
  tenant_name: 'swift_tenant'
  password: '123456'
  types:
    - ' SwiftOperator'
- username: 'admin'
  tenant_name: 'admin'
  password: 'admin'
  types:
    - 'admin'
resources:
    network: ' public_net '
    router: 'router'

接着，配置tempest.conf文件，這裏以配置[identity]部分測試Keystone服務爲例。若是須要測試諸如Compute、Network、Volume等服務，根據註釋提示配置相關選項便可。示例以下。

# egrep "^[^#]" etc/tempest.conf
[DEFAULT]
[alarming]
[auth]
Tempest_roles = Member//爲Tempest設置的角色
admin_username = admin   //管理員用戶名
admin_tenant_name = admin//管理員租戶名
admin_password = admin   //管理員用戶密碼
[baremetal]
[compute]
[compute-feature-enabled]
[dashboard]
[data-processing]
[data-processing-feature-enabled]
[database]
[debug]
[identity]
catalog_type = identity //測試的類型
uri = http://10.10.xx.xx:5000/v2.0 //Keystone服務的Endpoint
auth_version = v2 //Keystone服務的版本
region = RegionOne   //Keystone服務的Region
v2_admin_endpoint_type = adminURL//Keystone服務的Admin Endpoint
v2_public_endpoint_type = publicURL  //Keystone服務的Public Endpoint
username = demo //一個測試用戶
tenant_name = demo  //一個測試租戶
admin_role = admin   //一個測試角色
password = 123456   //測試用戶的密碼
[identity-feature-enabled]
api_v2 = true//指定測試v2版本的Keystone
api_v3 = false//指定不測試v3版本的Keystone
[image]
[image-feature-enabled]
[input-scenario]
[negative]
[network]
[network-feature-enabled]
[object-storage]
[object-storage-feature-enabled]
[orchestration]
[oslo_concurrency]
[scenario]
[service_available]
[stress]
[telemetry]
[telemetry-feature-enabled]
[validation]
[volume]
[volume-feature-enabled]

2.查看Tempest測試用例

在實際的測試環境中，QA測試人員會不斷地編寫各類類型的測試用例。對於咱們本身開發的測試用例，天然十分清楚用例執行的類型、名稱和內容等。對於Tempest、Rally和Shaker這種社區的自動化測試項目，咱們如何瞭解其測試用例呢？

下面，是一個用於獲取Tempest項目tempest/api目錄下測試用例的bash腳本。

#!/bin/sh
mkdir -p tempest_result && rm -f tempest_result/*
testcase_number=tempest_result/testcase_number.txt
testcase_list=tempest_result/testcase_list.txt

for openstack_projects in identity image compute network volume
do
    projects_dir=tempest/api/$openstack_projects
    projects_num=`grep -rn '\<def test_' $projects_dir | wc -l`
    echo "$openstack_projects testcase number: "$projects_num >> $testcase_number

    echo "Keystone(identity) testcase list: " >> $testcase_list && grep -rn '\<def test_' tempest/api/identity | awk '{print $3,NR}' >> $testcase_list
    echo "Glance(image) testcase list: " >> $testcase_list && grep -rn '\<def test_' tempest/api/image | awk '{print $3,NR}' >> $testcase_list
    echo "Nova(compute) testcase list: " >> $testcase_list && grep -rn '\<def test_' tempest/api/compute | awk '{print $3,NR}' >> $testcase_list
    echo "Neutron(network) testcase list: " >> $testcase_list && grep -rn '\<def test_' tempest/api/network | awk '{print $3,NR}' >> $testcase_list
    echo "Cinder(volume) testcase list: " >> $testcase_list && grep -rn '\<def test_' tempest/api/volume | awk '{print $3,NR}' >> $testcase_list

    sed -i 's/(self)//g' $testcase_list
done

將以上內容寫入腳本文件中，並放在Tempest目錄下。執行該腳本，會在tempestresult目錄下分別輸出testcaselist.txt和testcase_total.txt文件，前者用於存放tempest/api目錄下各項目服務的測試用例，後者用於存放每一個項目服務的測試用例統計數量。

打開testcase_list.txt文件，部份內容以下：

# cat testcase_list.txt
Keystone(identity) testcase list: 
test_list_endpoints: 1
test_create_list_delete_endpoint: 2
test_list_roles: 3
test_role_create_delete: 4
test_get_role_by_id: 5
test_assign_user_role: 6
test_remove_user_role: 7
test_list_user_roles: 8
test_list_roles_by_unauthorized_user: 9
test_list_roles_request_without_token: 10
……
……

查看testcase_number.txt文件，內容以下：

# cat testcase_number.txt
Identity testcase number: 172
Image testcase number: 63
Compute testcase number: 510
Network testcase number: 162
Volume testcase number: 154

3.Tempest代碼調試

1.安裝ipdb庫

# pip install ipdb

2.調試測試程序

若是某個用例執行出錯，可能須要加入斷點單步調試，能夠用pdb調試庫來完成調試工做，但筆者更建議用ipdb庫來調試，這個庫更智能易用，它的缺點是非Python系統庫，須要手工安裝才能使用。

若是要加入斷點單步調試，須要使用python -m testtools.run方法來執行被調試的用例，不然可能致使斷點沒法進入，也就沒辦法進行單步調試了，調試的第一步是在被調試的用例裏面加上斷點（下面以tempest.api.compute.servers.testserversnegative.ServersNegativeTestJSON.testrebootnonexistentserver用例爲例進行說明，這裏使用的是ipdb，pdb也是相似）。

@test.attr(type=['negative'])
@test.idempotent_id('d4c023a0-9c55-4747-9dd5-413b820143c7')
def test_reboot_non_existent_server(self):
    import ipdb;ipdb.set_trace()
    # Reboot a non existent server
    nonexistent_server = data_utils.rand_uuid()
    self.assertRaises(lib_exc.NotFound, self.client.reboot_server,
        nonexistent_server, type='SOFT')

以後，用python -m testtools.run運行這個用例便可進入斷點調試模式。命令以下所示。

# python -m testtools.run tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON.test_reboot_non_existent_server

4.運行Tempest測試

執行Tempest測試，既可使用testr也可使用nosetests、ostestr、run_tempest.sh腳本等命令，但社區推薦使用ostestr命令。這裏以testr使用爲例進行介紹。

這裏以測試Keystone v2版本的testlisttenantsreturnsonly authorizedtenants測試用例爲例。命令以下：

# testr run tempest.api.identity.v2.test_tenants

從下圖中能夠直接看到測試結果信息，這裏顯示該測試用例執行成功了，符合預期目的。

若是以爲這樣的測試結果不方便瀏覽、分析或者出於保存用例的須要，也能夠直接將該XML格式的結果文件拖放到Excel中瀏覽。

測試用例分析。

# vim tempest/api/identity/v2/test_tenants.py

from tempest.api.identity import base
from tempest.lib import exceptions as lib_exc
from tempest import test

class IdentityTenantsTest(base.BaseIdentityV2Test):

    credentials = ['primary', 'alt']

    @test.idempotent_id('ecae2459-243d-4ba1-ad02-65f15dc82b78')
    def test_list_tenants_returns_only_authorized_tenants(self):
        alt_tenant_name = self.alt_manager.credentials.tenant_name
        resp = self.non_admin_tenants_client.list_tenants()

        # check that user can see only that tenants that he presents in so user
        # can successfully authenticate using his credentials and tenant name
        # from received tenants list
        for tenant in resp['tenants']:
            body = self.non_admin_token_client.auth(
                self.os.credentials.username,
                self.os.credentials.password,
                tenant['name'])
            self.assertNotEmpty(body['token']['id'])
            self.assertEqual(body['token']['tenant']['id'], tenant['id'])
            self.assertEqual(body['token']['tenant']['name'], tenant['name'])
            self.assertEqual(body['user']['id'], self.os.credentials.user_id)

    # check that user cannot log in to alt user's tenant
    self.assertRaises(
        lib_exc.Unauthorized,
        self.non_admin_token_client.auth,
        self.os.credentials.username,
        self.os.credentials.password,
        alt_tenant_name)

該測試用例的主要內容是，檢查用戶是否只能夠看見同租戶下的其餘用戶；驗證用戶所使用的憑證和租戶名；最後檢查用戶不能登陸到名爲「alt」用戶的租戶。主要是調用assertEqual、assertRaises等斷言方法來判斷程序的執行結果和預期值是否相符。

以下，是一些testr測試的相關命令

1）使用testr,查看命令幫助信息

# testr help

執行如下命令前，首先須要加載測試環境

# source .tox/py27/bin/activate

直接運行測試

testr run --parallel
testr run --parallel test_name_regex

測試結束後，查看失敗的用例，並從新運行失敗用例

testr failing
testr run --failing

批量運行api、scenario兩個測試用例集

# ostestr --regex '(?!.*\[.*\bslow\b.*\])(^tempest\.(api|scenario))'

或者使用以下方法

# testr run

或者，並行運行測試

# testr run --parallel

或者，並行運行某一個測試用例集

# /root/tempest/tempest/api testr run --parallel

運行單個測試用例

# testr run 
tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON.test_reboot_non_existent_server

根據，OpenStack環境機器的CPU數量多少，設置併發量，好比這裏設置爲2。

# testr run --parallel -- concurrency=2

執行測試分析

# testr run --analyze-isolation

列出測試用例

# testr list-tests

執行 Tempest的場景測試

# testr run --parallel tempest.scenario

或者

# ./run_tempest.sh tempest.scenario

只從新運行失敗的測試用例

# testr run --failing

爲了更好的分析和瀏覽，咱們能夠將xml文件，直接拖放到Excel文檔中。

2）測試結果

Tempest的測試結果有四種：測試錯誤（Error）、測試失敗（Failure）、跳過（Skip）、成功（Success）。其含義分別以下。

測試錯誤：能夠理解成測試代碼執行時報錯。好比測試代碼中print a，而a沒有進行變量聲明。和setUp相似，若是代碼在這個階段出錯，也都會被認爲是測試錯誤（Error）。也多是配置環境有問題。
測試失敗：能夠簡單理解成測試代碼執行正常，但沒有獲得預期的測試結果，好比在測試代碼中調用功能代碼add(1, 2)，但返回結果不是3。
跳過：能夠理解爲測試忽略。好比某個用例只在CentOS系統下運行，這樣在其餘系統下就會被跳過，也就是忽略。還有多是被測試的服務有bug。
成功：測試用例執行成功,即測試程序返回的結果值符合預期的目的。

5.開發測試報告

如何讓Tempest API集成/功能測試自動化輸出有利於分析和瀏覽的測試報告，並捕獲測試中的失敗用例，是QA測試人員工做的內容之一。咱們須要儘量地讓看似模糊的測試結果可視化和數據化。

讓Tempest測試自動化輸出報告，須要使用HTMLTestRunner.py模塊文件。其下載地址是：http://tungwaiyip.info/software/HTMLTestRunner.html。

這裏假定Tempest源碼倉庫位於/tempest目錄下。則執行以下步驟。

# cd /tempest

將HTMLTestRunner.py和自動化測試程序文件（好比，這裏提供的用例程序tempest_keystone.py）一併存放在Tempest目錄下。代碼以下：

#!/usr/bin/env python
#coding=utf-8

import HTMLTestRunner
import unittest,time
import re,os,sys

def createsuite():
    #定義一個單元測試容器
    testunit=unittest.TestSuite()   
    #定義測試文件查找的目錄
    #此處，測試identity項目中v2目錄下的以test開頭的測試用例
    test_dir='tempest/api/identity/v2'  
    #定義discover方法的參數
    discover=unittest.defaultTestLoader.discover(test_dir,pattern='test*.py', top_level_dir=None)
    #將discover方法篩選出來的測試用例，循環添加到測試套件中
    for test_case in discover:
        print test_case
        testunit.addTests(test_case)
    return testunit

now = time.strftime("%Y-%m-%d")
#測試報告存放路徑
filename = '/home/'+now+'_keystone.html'  
fp = file(filename,'wb')
runner = HTMLTestRunner.HTMLTestRunner(
    stream=fp,title=u'OpenStack Keystone API功能測試',description=u'用例執行狀況:')

if __name__ == '__main__':
    alltestnames = createsuite()
    #運行全部測試
    runner.run(alltestnames)   
    fp.close()

代碼說明以下：

unittest模塊中的TestLoader類有一個discover方法。經過使用該方法，如discover(start dir, pattern='test*.py',topleveldir=None)，遞歸查找指定目錄（startdir）及其子目錄下的所有測試模塊，而後將這些測試模塊放入TestSuite對象中並返回。只有匹配pattern的測試文件纔會被加載到TestSuite中。

若是一個測試文件的名稱符合pattern，將檢查該文件是否包含 loadtests() 函數，若是loadtests()函數存在，則由該函數負責加載本文件中的測試用例；若是不存在，就會執行loadTestsFromModule()，查找該文件中派生自TestCase類的以test開頭的方法。

執行測試命令：

# python tempest_keystone.py

執行測試命令後，會在/home目錄下生成一份HTML格式的測試報告，使用瀏覽器打開該文件，以下圖所示。

須要說明的是，這裏是針對Tempest中的identity項目（Keystone認證服務）v2版本目錄下的用例進行測試。如若運行其餘項目測試，可參考此方法。

測試報告查看

對於測試結果報告，能夠經過郵件和瀏覽器等多種方式查看。好比，咱們能夠開發程序，自動將測試報告發送到相關人員的郵件中，或者自動發送到Web服務器中，這樣當咱們使用瀏覽器訪問某個URL地址，就可方便的看到測試結果。圍繞這一內容，還能夠將其應用到平常的QA測試、CI/CD等研發測試環節，起到以點帶面的效果。

3、人工智能AI對軟件測試的影響

自從，阿爾法狗（AlphaGo）在人機大戰中，以3:0的絕對優點打敗李世石以後，AI便火得一塌糊塗，彷彿一晚上之間不談AI，便已感受是來自外星球。那麼AI對軟件測試的影響如何呢。

軟件測試技術發展至今，能夠說基於頁面對象的模型測試（POM）是一種更接近於人工智能的測試方法。但人工智能AI明顯還要更進一步，要求能夠實現自動的構造測試場景和測試用例。它要求測試人員首先基於軟件功能構造出各類模型（或者叫作行爲），而後制定行爲和行爲之間的關係以及行爲和系統總體的關係，以後自動測試系統就能夠智能的根據當前的被測系統的狀態（場景）以及預設的規則，選擇下一步要執行的行爲。

理論上這種測試方法能夠儘量的遍歷被測試系統中各類可能經歷的行爲鏈，從而極大的提升測試覆蓋率。因爲它每次執行的路徑並不是固定不變，因此能夠構造出徹底不一樣的測試用例，咱們也能夠稱之爲智能的軟件測試。

基於模型的人工智能測試，首先就是要把各類OpenStack操做定義成模型。這裏咱們拿虛擬機的各類操做舉例。一般，虛擬機具備多種狀態，如運行、暫停、重啓、遷移、快照等等，此時，咱們能夠在狀態和狀態之間定義一些標準的操做。當把這些狀態和操做畫出來後，咱們就能夠獲得虛擬機的狀態遷移圖（或者說是虛擬機場景）。以下圖所示。

能夠看到，上圖中Running和Stopped的狀態之間能夠經過stop和start操做作成狀態環。那麼智能測試就能夠根據預先設定的規則，讓虛擬機在這個環裏作有限的測試。這一個看起來好像很簡單，可是要知道OpenStack裏面還有不少其餘資源的狀態遷移圖，並且不少資源之間是有相互依賴關係的，例如在其餘服務正常運行可用的前提下，虛擬機各類操做纔會順利執行。並且用戶在操做OpenStack的時候，也不會只作虛擬機狀態的改變，一般還會和其餘資源的行爲混合操做。因此，當把全部資源的遷移圖畫完，就會發現整個OpenStack的場景和可選的行爲之間的關係是很是複雜的。

最後，關於Tempest還有不少故事點和內容能夠進行研究，如測試用例和tempest.conf配置文件之間的關係、如何按照自身需求擴展Tempest測試用例等。本次分享內容整理自《OpenStack最佳實踐 —測試與CI/CD》一書5.5.1小節，現已發售。

提問環節

好比說創一個虛擬機，有bug，也就是host os上可能留有髒數據，DB中也可能，這些東西怎麼清理？或者說如何保證環境是乾淨的。尤爲是hostos上的乾淨？

就拿Tempest來講吧，當它建立一個VM後，若是沒有異常或錯誤（也有多是程序bug）發生，tempest會自動刪除掉vm及其相關的資源

請問如今大家開發是用什麼工具？調試又是如何作的？剛纔只看到測試部分，謝謝！

每一個開發人員使用的工具不一樣，好比說我吧，看代碼通常會用eclipse+pydev，調試通常用ipdb等等。

請問大家修改的代碼都會提交到社區嗎？若是有部分提交不了社區，請問大家是怎麼維護的？再下次OpenStack版本發佈是怎麼合併的？謝謝！版本怎麼作的控制？

針對軟件項目，咱們通常使用持續集成Jenkins來統一管理，對於DB數據字段更新多的業務，可能還須要其餘來完善。

安全性測試如何作的呢？

對於安全性測試，每一個人或者每一個團隊對它的側重點不同，好比會有常見的SQL注入、滲透、前端頁面的漏洞掃描

很想知道針對openstack存儲性能方面有什麼比較好的測試方法嗎？

針對openstack存儲性能方面的測試，能夠參見《OpenStack最佳實踐-測試與CI/CD》第5.6小節，好比在openstack+ceph集成的狀況下，從下往上，有服務器自己的，也有Ceph集羣、RBD塊存儲、虛擬機等