BM Business Automation Workflow是原IBM BPM+IBMCaseManager+IBMECM組合之后的新產(chǎn)品，屬于業(yè)務(wù)流程自動(dòng)化產(chǎn)品。下面是登錄Proce Center之后的界面：

在上圖中可以打開現(xiàn)有的流程，以及新建流程，也可以歸檔流程。下圖我們打開一個(gè)流程可以看到以下界面。左側(cè)是松耦合的各個(gè)功能，右側(cè)可以看到各種設(shè)置，包括公開的項(xiàng)，以及可以定制主題（界面），以及指定流程應(yīng)用程序管理員。

在下圖中基于每個(gè)模塊點(diǎn)“+”號(hào)做相應(yīng)的操作，下圖是“服務(wù)”模塊點(diǎn)“+”之后出現(xiàn)的選擇，可以添加外部服務(wù)、服務(wù)流、Web Service等。

下圖是添加一個(gè)WebService服務(wù)之后，在“操作”上面點(diǎn)“+”號(hào)出現(xiàn)的界面

下圖是可以繼續(xù)添加“策略”

我們可以將設(shè)計(jì)好的流程、用戶界面、服務(wù)、數(shù)據(jù)等復(fù)制或移動(dòng)到其他項(xiàng)目中，可以節(jié)省大量的重復(fù)工作。如下圖：

下圖是流程設(shè)計(jì)界面，標(biāo)準(zhǔn)的BPMN2.0標(biāo)準(zhǔn)，在每個(gè)流程節(jié)點(diǎn)可以選擇如下圖的功能，包括寫JS腳本、調(diào)用軟件機(jī)器人等。

在用戶界面中也可以設(shè)置流程，以及在流程節(jié)點(diǎn)自定義各種服務(wù)，實(shí)現(xiàn)短流程。也就是說當(dāng)用戶的流程節(jié)點(diǎn)調(diào)用了這個(gè)用戶界面，流程到達(dá)該流程節(jié)點(diǎn)的時(shí)候會(huì)自動(dòng)觸發(fā)相應(yīng)的短流程實(shí)現(xiàn)一些服務(wù)的調(diào)用。

在用戶界面（表單）可以針對(duì)添加的控件使用定制各種功能，使用各種服務(wù)。

在UI界面時(shí)支持下面各種控件，近80個(gè)輕量級(jí)的響應(yīng)式組件（HTML5 / CSS3），不依賴第三方。

服務(wù)支持：

內(nèi)置文檔管理

支持AI功能，下圖在審批時(shí)會(huì)有AI提示。

重要的是，IBM現(xiàn)在將上述產(chǎn)品打包進(jìn)IBM Cloud Pak For Business Automation了，里面包含了下圖的所有授權(quán)，以及企業(yè)級(jí)中間件、數(shù)據(jù)庫的授權(quán)，并支持基于OpenShift部署，也包含了OpenShift的授權(quán)。用戶可以購買48vCPU授權(quán)，并靈活配置合適下圖中的功能模塊。

、腳本模板

2、 場景模板

性能測試工具選擇

1. 數(shù)據(jù)建模工具

DataFactory是一種強(qiáng)大的數(shù)據(jù)產(chǎn)生器，它允許開發(fā)人員和QA很容易產(chǎn)生百萬行有意義的正確的測試數(shù)據(jù)庫,該工具支持DB2、Oracle

、 Sybase、SQL Server數(shù)據(jù)庫，支持ODBC連接方式，無法直接使用MySQL

數(shù)據(jù)庫，可間接支持。

2. 腳本開發(fā)工具

（1） 若考慮腳本運(yùn)行效率，則可考慮底開發(fā)語言C或支持異步通信的語言JS,我們可以分別選擇：Loadrunner 或 Node.js

的IDE環(huán)境進(jìn)行開發(fā)。

（2） 若考慮腳本開發(fā)效率，則可考慮代碼復(fù)用性，可以選擇面向?qū)ο笳Z言C#或Java，為此我們可以分別選擇：VS2008及以上版本 +對(duì)應(yīng)LR.NET

控件 或者 Eclipse4.0及以上版本 + JDK1.7及以上版本。

3. 壓力模擬工具

（1） 若為Java類接口且單機(jī)并發(fā)數(shù)控制在500內(nèi)，則可選擇Jmeter或者 Loadrunner。

（2） 若為WebService類接口且單機(jī)并發(fā)數(shù)控制在500內(nèi)，則可選擇SoapUI或者Loadrunner。

（3） 若單機(jī)并發(fā)數(shù)超過500且控制在5000內(nèi)，則可選擇Loadrunner。

（4） 若單機(jī)并發(fā)數(shù)超過5000，則建議采用負(fù)載集群，即采用“中控（Control Center）+ 多機(jī)部署（LoadGenerator）”方案。

4. 性能監(jiān)控工具

4.1 監(jiān)控工具

無論Windows或Linux

平臺(tái)，一般存在的是一個(gè)或一組進(jìn)程實(shí)例，我們可以選擇Loadrunner 或 Nmon 來監(jiān)控。有時(shí)為了獲取被測應(yīng)用的一些特性指標(biāo)，可以選擇被測組件自帶的性能工具集或監(jiān)控系統(tǒng)。常見應(yīng)用服務(wù)器監(jiān)控工具推薦如下：

4.2 監(jiān)控平臺(tái)

監(jiān)控機(jī)器主要對(duì)被測集群服務(wù)器的服務(wù)或資源使用情況進(jìn)行監(jiān)控，比如各種開源的監(jiān)控工具，MRTG：流量監(jiān)控；CACTI：流量預(yù)警，性能報(bào)告Smokeping:IDC 質(zhì)量監(jiān)控；綜合監(jiān)控：Nagios、Zenoss、Ganglia 、Zabbix、Sitescope、Hyperic HQ 等，如下所示：

4.3 第三方監(jiān)控云服務(wù)（APM）

APM提供端到端應(yīng)用性能管理軟件及應(yīng)用性能監(jiān)控軟件解決方案,包含移動(dòng),瀏覽器,應(yīng)用,基礎(chǔ)設(shè)施,網(wǎng)絡(luò),數(shù)據(jù)庫性能管理等，支持Java、.NET、PHP

、Ruby、Python

、Node.js、iOS

、Android

、HTML5

等應(yīng)用性能監(jiān)控管理，主流云服務(wù)包括聽云、OneAPM等，如下所示：

性能測試結(jié)果分析

1. 指標(biāo)分析

性能測試的指標(biāo)可分為產(chǎn)品指標(biāo)和資源指標(biāo)兩類。對(duì)測試人員而言，性能測試的需求來自于用戶、開發(fā)、運(yùn)維的三方面。用戶和開發(fā)關(guān)注的是與業(yè)務(wù)需求相關(guān)的產(chǎn)品指標(biāo)，運(yùn)維人員關(guān)注的是與硬件消耗相關(guān)的資源指標(biāo)。

（1） 從用戶角度關(guān)注的指標(biāo)

用戶關(guān)注的是單次業(yè)務(wù)相關(guān)的體驗(yàn)效果，譬如一次操作的響應(yīng)快慢、一次請(qǐng)求是否成功、一次連接是否失敗等，反映單次業(yè)務(wù)相關(guān)的指標(biāo)包括：

a.成功率b.失敗率c.響應(yīng)時(shí)間

（2） 從開發(fā)角度關(guān)注的指標(biāo)

開發(fā)人員更關(guān)注的是系統(tǒng)層面的指標(biāo)。

a.容量：系統(tǒng)能夠承載的最大用戶訪問量是多少?系統(tǒng)最大的業(yè)務(wù)處理量是多少?

b.穩(wěn)定性:系統(tǒng)是否支持7*24小時(shí)(一周)的業(yè)務(wù)訪問。

（3） 從運(yùn)維角度關(guān)注的指標(biāo)

運(yùn)維人員更關(guān)注的是硬件資源的消耗情況。

以上說明了測試人員在選擇指標(biāo)時(shí)需站在用戶角度去思考，另外為了后續(xù)能夠更好地分析問題，更需掌握與被測組件特性或運(yùn)行原理相關(guān)的性能指標(biāo)。

舉例來說，通常接口系統(tǒng)均會(huì)直接或間接地訪問數(shù)據(jù)庫層介質(zhì)（如Mysql、Oracle、SQLServer等），此時(shí)我們需考慮由接口系統(tǒng)產(chǎn)生壓力下存儲(chǔ)介質(zhì)的性能情況，通常我們會(huì)選擇分析指標(biāo)如下：

（1） 連接數(shù)（Connections）
（2） 每秒查詢數(shù)/每秒事務(wù)數(shù)（QPS/TPS）
（3） 每秒磁盤IO數(shù)（IOPS）
（4） 緩存命中率（Buffer Hits）
（5） 每秒發(fā)生的死鎖數(shù)（Dead Locks/sec）
（6） 每秒讀/寫字節(jié)數(shù)（Read/Write Bytes/sec）

2. 建模分析

2.1 理發(fā)店模型

圖中展示的是1個(gè)標(biāo)準(zhǔn)的軟件性能模型。在圖中有三條曲線，分別表示資源的利用情況（Utilization，包括硬件資源和軟件資源）、吞吐量（Throughput，這里是指每秒事務(wù)數(shù)）以及響應(yīng)時(shí)間（Response Time）。圖中坐標(biāo)軸的橫軸從左到右表現(xiàn)了并發(fā)用戶數(shù)（Number of Concurrent Users）的不斷增長。

在這張圖中我們可以看到，最開始，隨著并發(fā)用戶數(shù)的增長，資源占用率和吞吐量會(huì)相應(yīng)地增長，但是響應(yīng)時(shí)間的變化不大；不過當(dāng)并發(fā)用戶數(shù)增長到一定程度后，資源占用達(dá)到飽和，吞吐量增長明顯放緩甚至停止增長，而響應(yīng)時(shí)間卻進(jìn)一步延長。如果并發(fā)用戶數(shù)繼續(xù)增長，你會(huì)發(fā)現(xiàn)軟硬件資源占用繼續(xù)維持在飽和狀態(tài)，但是吞吐量開始下降，響應(yīng)時(shí)間明顯的超出了用戶可接受的范圍，并且最終導(dǎo)致用戶放棄了這次請(qǐng)求甚至離開。

根據(jù)這種性能表現(xiàn)，圖中劃分了三個(gè)區(qū)域，分別是Light Load（較輕的壓力）、Heavy Load（較重的壓力）和Buckle Zone（用戶無法忍受并放棄請(qǐng)求）。在Light Load和Heavy Load 兩個(gè)區(qū)域交界處的并發(fā)用戶數(shù)，我們稱為“最佳并發(fā)用戶數(shù)（The Optimum Number of Concurrent Users）”，而Heavy Load和Buckle Zone兩個(gè)區(qū)域交界處的并發(fā)用戶數(shù)則稱為“最大并發(fā)用戶數(shù)（The Maximum Number of Concurrent Users）”。

當(dāng)系統(tǒng)的負(fù)載等于最佳并發(fā)用戶數(shù)時(shí)，系統(tǒng)的整體效率最高，沒有資源被浪費(fèi)，用戶也不需要等待；當(dāng)系統(tǒng)負(fù)載處于最佳并發(fā)用戶數(shù)和最大并發(fā)用戶數(shù)之間時(shí)，系統(tǒng)可以繼續(xù)工作，但是用戶的等待時(shí)間延長，滿意度開始降低，并且如果負(fù)載一直持續(xù)，將最終會(huì)導(dǎo)致有些用戶無法忍受而放棄；而當(dāng)系統(tǒng)負(fù)載大于最大并發(fā)用戶數(shù)時(shí)，將注定會(huì)導(dǎo)致某些用戶無法忍受超長的響應(yīng)時(shí)間而放棄。所以我們應(yīng)該保證最佳并發(fā)用戶數(shù)要大于系統(tǒng)的平均負(fù)載。

2.2 壓力變化模型

隨著單位時(shí)間流量的不斷增長，被測系統(tǒng)的壓力不斷增大，服務(wù)器資源會(huì)不斷被消耗，TPS 值會(huì)因?yàn)檫@些因素而發(fā)生變化，而且符合一定的規(guī)律。

圖中：
a 點(diǎn)：性能期望值
b 點(diǎn)：高于期望，系統(tǒng)資源處于臨界點(diǎn)
c 點(diǎn)：高于期望，拐點(diǎn)
d 點(diǎn)：超過負(fù)載，系統(tǒng)崩潰

2.3 容量計(jì)算模型

以一網(wǎng)站性能測試為案例：

1. 通過分析運(yùn)營數(shù)據(jù)，可以知道當(dāng)前系統(tǒng)每小時(shí)處理的PV數(shù)
2. 通過負(fù)載測試，可以知道系統(tǒng)每小時(shí)最大處理的PV數(shù)

即整理得

系統(tǒng)每小時(shí)PV處理剩余量 = 系統(tǒng)每小時(shí)最大處理的PV數(shù) — 系統(tǒng)每小時(shí)處理的PV數(shù)

假設(shè)該網(wǎng)站用戶負(fù)載基本呈線性增長，現(xiàn)有系統(tǒng)用戶數(shù)為70萬，根據(jù)運(yùn)營推廣計(jì)劃，1年內(nèi)該網(wǎng)站發(fā)展用戶將達(dá)到1000萬，即增長了14倍。即整理得：

系統(tǒng)每小時(shí)PV處理增加量 = 當(dāng)前系統(tǒng)每小時(shí)處理的PV數(shù) * 14 — 當(dāng)前系統(tǒng)每小時(shí)處理的PV數(shù)

每天系統(tǒng)負(fù)載增加率 = 100% / 365 = 2.74 % （備注：此處將未來系統(tǒng)用戶數(shù)達(dá)到1000萬的負(fù)載定義為 100% ）

系統(tǒng)每天PV處理增加量 = 系統(tǒng)每小時(shí)PV處理增加量 * 每天系統(tǒng)負(fù)載增加率 * 24

所以，我們可以知道在正常負(fù)載條件下：

系統(tǒng)可支持正常運(yùn)行天數(shù) = 系統(tǒng)每小時(shí)PV處理剩余量 * 24 / 系統(tǒng)每天PV處理增加量

假設(shè)該網(wǎng)站后續(xù)部署升級(jí)天數(shù)已知，這樣我們可以知道提前升級(jí)的天數(shù)：

系統(tǒng)可支持正常運(yùn)行天數(shù) — 部署升級(jí)天數(shù)。

性能測試通過標(biāo)準(zhǔn)

1. 所有計(jì)劃的測試已經(jīng)完成。

2. 所有計(jì)劃收集的性能數(shù)據(jù)已經(jīng)獲得。

3. 所有性能瓶頸得到改善并達(dá)到設(shè)計(jì)要求。