2. 異常處理
2.1 概述
在流程開發(fā)中距境，進行異常處理是非常關(guān)鍵的一部分泛粹。一個流程的異常處理框架的好壞直接影響到整個項目的代碼質(zhì)量以及后期維護成本和難度。
2.2 常用異常處理控件
2.2.1 常用異常處理控件
2.2.1.1 Rethrow
只能在Try/Catch塊的Catch塊中使用肮疗，顯式的拋出之前在異常處理塊中捕獲的異常晶姊，并且可以保持異常的原始源
2.2.1.2 Terminate Workflow
終止正在運行的工作流實例，并報告錯誤信息伪货。使用此控件中止流程们衙，一旦流程終止钾怔，它就不能被恢復(fù)。
2.2.1.3 Throw
拋出異常信息
2.2.1.4 Try Catch
在Sequence或FlowChart中捕獲指定的異常類型蒙挑，并做相應(yīng)的處理動作御雕。
在此控件中包含三個分塊：
Try：用來包圍可能會出現(xiàn)異常的邏輯代碼拨与，它單獨無法使用范删，必須配合catch/finally使用嘁扼；
Catch：在此控件中，可以指定多種可能存在的異常類型馋袜，在有多個catch塊的時候男旗，是按照catch塊的先后順序進行匹配的，一旦異常類型被一個catch塊匹配欣鳖，則不會與后面的catch塊進行匹配察皇。
Finally： 同其他語言的異常處理塊一樣，在Finally里泽台，不管是否發(fā)生錯誤什荣，此塊的內(nèi)容是一定被執(zhí)行的，可以在此塊中時下關(guān)閉文件流怀酷、數(shù)據(jù)庫連接等操作
2.2.1.5 Retry Scope
只要不滿足條件或拋出錯誤稻爬，就重試所包含的活動。僅適用于查找元素蜕依，不利于邏輯重試
Retry Scope控件必須放在Try/Catch控件的Try塊中桅锄，這樣是為了保證在Retry Scope中重試N次之后，都可能存在異常而做的保護處理笔横。如果Retry Scope中重試N次無果，則在Catch中拋出異常信息咐吼。
2.3 流程中異常分類
2.3.1 業(yè)務(wù)處理異常
在關(guān)鍵用戶和業(yè)務(wù)分析人員在流程評估時吹缔，需要將流程中的異常分為兩種：已知和未知異常兩種。
- 已知異常
即在之前有遇到過此種異常信息锯茄，并且有明確的處理方式厢塘。如果機器人在執(zhí)行過程中遇到此類的異常，則需要設(shè)置相應(yīng)的處理機制肌幽，并且保證機器人執(zhí)行不中斷晚碾。
- 未知異常
即在這之前從未遇到過的異常。這種異澄辜保可能是由多種因素引起格嘁，并且無法準確的預(yù)知，如果發(fā)生這種情況廊移，則需要發(fā)送郵件獲取通過其他方式通知到相應(yīng)的用戶糕簿。
2.3.2 系統(tǒng)錯誤或應(yīng)用程序異常
系統(tǒng)錯誤和應(yīng)用程序引起的異常在自動化流程中還是比較常見探入，通常會通過多次重試的機制以保證流程的正常。舉個例子：
? 登錄系統(tǒng)：在登錄某個使用用戶名懂诗、密碼進入的系統(tǒng)時蜂嗽，有可能會由于某些不可描述的原因?qū)е乱淮蔚卿浭 Ｔ趪L試失敗之后殃恒，機器人需要關(guān)閉該系統(tǒng)植旧，重新打開，再次輸入憑證离唐，再去判斷登錄成功標志病附。
2.4 異常處理和設(shè)計
2.4.1 在有必要使用異常的地方使用，不要在流程的任何地方都用
謹慎地使用異常侯繁，異常捕獲的代價非常高昂胖喳，異常使用過多會嚴重影響程序的性能。如果在程序中能夠用if語句和Boolean變量來進行邏輯判斷贮竟，那么盡量減少異常的使用丽焊，從而避免不必要的異常捕獲和處理。
2.4.2 不要使用空的Catch塊
在捕獲了異常之后什么都不做咕别，相當于忽略了這個異常技健。千萬不要使用空的catch塊，空的catch塊意味著你在程序中隱藏了錯誤和異常惰拱，并且很可能導(dǎo)致程序出現(xiàn)不可控的執(zhí)行結(jié)果雌贱。如果你非常肯定捕獲到的異常不會以任何方式對程序造成影響偿短，最好用Log日志將該異常進行記錄欣孤，以便日后方便更新和維護。
2.4.3 注意catch塊的順序
按照C#中異常繼承的關(guān)系昔逗，不要把最上層的異常放在最前面的Catch塊中降传，盡可能的縮小異常類型的范圍。
2.4.4 不要將給用戶的提示信息和代碼混在一起
為了把給用戶的提示信息和代碼分開勾怒，可以將用戶提示信息放在配置文件中統(tǒng)一管理婆排。
同時也不要把流程中代碼報錯信息直接拋出給用戶，會大大降低用戶的體驗效果笔链。
2.4.5 盡量將異常拋給上層處理
如果在每個出現(xiàn)異常的地方都直接進行處理段只，會導(dǎo)致程序異常處理流程混亂，不利于后期維護和異常錯誤排查鉴扫。由上層統(tǒng)一進行處理會使得整個程序的流程清晰易懂赞枕。
2.4.6 在Finally中釋放資源
如果有使用文件讀取、網(wǎng)絡(luò)操作以及數(shù)據(jù)庫操作等，記得在finally中釋放資源鹦赎。這樣不僅會使得程序占用更少的資源谍椅，也會避免不必要的由于資源未釋放而發(fā)生的異常情況。
3. 測試場景模板
3.1 概述
主要用于測試RPA流程功能實現(xiàn)古话、業(yè)務(wù)邏輯雏吭、異常處理機制是否完善
RPA實施人員代碼開發(fā)完畢后根據(jù)用戶提供的測試用例去模擬用戶在使用軟件時的各種場景：
主要模擬兩種情景：
1、模擬用戶正確的業(yè)務(wù)操作過程—驗證的是功能是否正確
2陪踩、模擬用戶錯誤的業(yè)務(wù)操作過程—驗證的是程序的異常處理能力（健壯性）
根據(jù)以下測試場景模板杖们，測試流程各項功能。若用戶提供測試模板肩狂，以用戶為準
測試編號 流程名稱 場景描述 必要測試數(shù)據(jù) 預(yù)期結(jié)果 重要性 狀態(tài) 測試執(zhí)行者 測試日期 錯誤信息 錯誤出現(xiàn)原因 錯誤解決方案
TS01 Main.xaml 機器人獲取發(fā)票信息 滴滴電子發(fā)票.pdf 取到開票日期及金額 中 未通過 張三 2020/1/11 Read PDF File: One or more errors occurred. 未判斷PDF文件是否存在 使用Path Exists判斷文件是否存在摘完，結(jié)果為True則執(zhí)行讀取PDF文件操作
4. 用戶交流
同用戶溝通時，業(yè)務(wù)需求變更或需代碼進行調(diào)整等討論溝通后都要進行文檔化傻谁，郵件等方式發(fā)予同用戶進行確認孝治，避免后期用戶及自身遺忘。
