性能测试负载测试压力测试

第9章：大型資訊系統上線前之執行工作大型專案之實務規劃與管理••課程章節關聯第9章：（計畫管理）第6七第10章：上線後工作（系統維護）專案執行準則（計畫管理及规劃分析）第2章：品定位（規劃分析）第4章：可衿性分析（風檢分析）第11章：澄在風險分析（風險分析及系統維護）第0章：專案啟》、_第1聿：礞《需求（需求定義）第3章：既有經驗（娩劃分析）第7聿：執行專案計畫軟體開發程序（計畫管理及规劃分析、系統設計）XV1：\1<1£第8章：計盡管远上線前工作（分析、設計及驗设測試）2大型資訊系統上線前之執行工作•系統測試之目的、內容及其困難性•軟體品質驗證與測試的控管程序•需求-分析•設計-測試-交貨認知差異性•大型系統上線前執行工作~1'(№8/0^61^系統為例•大型系統研發之測試程序一統為例•大型系統上線前驗證測試工作一系統為例新國稅案•非功能測試1^?要求•性能測試•負載測試-壓力測試軟體測試一理論與實作簡介•測試概論•軟體測試基礎•測試程序摘自中華電信研究所客服室孫如濱先生資料軟體測試之誤解■如果軟體品質有問題*那是軟體測試人員的錯。■軟體測試技術要求不高，至少比程式設計容易多了。■軟體測試隨便找一個能力差的人就能做。-經驗對軟體測試至關重要-除軟體測試技術問題外，還有測試管理問題。■有時間就多測試一些，來不及就少測試一些。■軟體測試是測試人員的事，與開發人員無關。■需求一設計一發展一測試，軟體測試是開發後期的一個階段。-生命週期的「測試階段」表示該階段測試是主要工作，而非測試工作只發生在「測試階段」。修正BUG之代價40〜1000倍*70倍/15〜40倍--*HarryBoehm(SoftwareEngineeringEconomics)6無論是測試準備工作，還是測試執行工作，都應貫穿於整個產品生命週期。需求分析設計程式發展內部測試外部測試上線10倍/，........................I常見之軟體測試投入作法■外聘更多測試人員-缺乏頜域知識人與人之間交流通路倍增■抽調原有_-普遍正規做法：*、建立規範化的測試流程*“組建一支相對穩定、有經驗和專業化的測試團隊■加強對消--費用與回報-國內缺乏專門培訓機構■購買或自主開發測試工具■測試工作外包須具備成熟且有效的內部管理體系測試工程師之素質•溝通能力•自信心•幽默感•超強的記憶力・足夠的耐心•懷疑精神•洞察力*自我督促CMMI工程領域一測試有關流程RequirementsiProductCustomerRDRequirementsVVERGustomerneeds9ProductcomponentsProduct&productcomponentrequirementsworkproducts,verificationandvalidationreports't•*，PI:ProductintegrationRD=RequirementsDevelopmentREQM=RequirementsManagementTS=TechnicalSolutionVAL=ValidationVER=VeriflcaltonAlternativesolutions«-f1r

，Productcomponents,\f1測試之策略與方法|$43I*I'-岣1確認及驗證之區別*驗證(Verification):偏向發展者自己對開發系統功能、效能、資料正確性等項目測驗=+即，你做對T(YouBuilditright)=+白箱測試(WhiteBoxTesting)•碟認(Validation):偏向使用者對開發系統功能、效能、資料正確性等項目測驗=+即，你做了正據的事(YouBuildtherightthing)=+黑箱測試(BlackBoxTesting)n軟體測試之定義■測試案例設計方法-白箱測試（結構測試）-黑箱測試（功能測試）■測試策略和步驟-單元測試-整合測試-系統測試-驗證測試-迴歸測試迴歸測試簡要說明迴歸測試玄要執行步林■在整體系統開發完成一個完整版本後（如，版本1.0），■曰後，若有某人子系統^1002功能修改，將會根據該整《系統開發完成後1.0版，相對應水平及垂直追溯表，找出該点1«02功能相關垂直功能及程式，以及水平相關功能（如，8子系統82003功能與152007功能）:再依據日前所錄製此相關41002、1120<»3與£42007功能測試的腳本進行測試，此為迴歸測試）_水平追溯表垂直追溯表I;軟體測試之原則■軟體發展者之座右銘：「儘早且不斷地進行軟體測試」■測試案例應由測試輸入資料和與之對應的預期結果所組成■測試案例應包括合理的輸入資料和不合理的輸入資料■程式設計師應避免檢查自己的程式-勿與除錯(debug)混淆■充分注意測試中之群集現象■嚴格執行測試計畫，排除測試的隨意性。■每一個測試結果應做全面檢查■妥善保存測試計劃、測試案例、錯誤統計和最終分析報告。測試資訊流程＞改正的軟髖＞預測的可靠性軟體開發與測試比較・微軟公司2000年-開發人員10,000人Microsoft-測試人員15,000人（測試費用佔研發費用60%）■開發2000-研發經理25人-開發人員140人-測試人員350人■開發Windows2000-研發經理250人-開發人員1,700人-測試人員3,200人■1£4,0-開發時間6個月-測試時間8個月Mleicsc/rExchangeServer,jcoDDevetoperCenterInternetExplorer測試類別之比較測試類別對象目的人員測試方法單元測試模組内部的程式單元去除局部模组的邏輯和功能上的錯誤或缺陷程式設計人員大量採用白箱測試方法整合測試模組間的整合和呼叫關係找出裎式結構'模组呼叫關係、介面之問題程式設計人員與測試■人員結合使用白箱與黑箱（灰箱）測试方法。系統測試螌個系統功能和非功能性之軟、硬逋系統之功能、品質、性能符合規格測试人員黑箱測試驗證測試繁個系統功能和非功能性之軟'硬體系統之功能、品質、性能符合使用者要求測試人貝協助使用者黑箱測試迴歸測試軟雜缺陷修正後或軟體整合後重新測試驗證已絛正後的錯誤或缺陷不再出現測試人員黑箱測試單元測試活動活動名稱輸入輸出參與人員制訂單元測試計畫設計模型實施模型單元測試計盡設計員設計單元測試單元測試計畫設計模型實施模型單元測試案例單元測試驅動模組設計員實施單元測試單元測試案例單元測試驅動模組程式設計員執行單元測試實施模型單元測試計畫單元測试案例被測试單元單元測試驅動模組測試结果程式設計員評估單元測試單元測試計畫測試結果測試評估摘要設計員史18整合測試活動活動名稱輸入輸出參與人員制訂整合測試計畫設計模型整合構建計晝整合測試計晝測試設計員設計整合測試整合測試計畫設計模型整合測試案例測試程序測試設計員賁施整合測試整合測試案例測試程序工作版本測試腳本＜可選＞測試程序（更新）測試設計員執行整合測試測試腳本（可選＞工作版本測試結果測試員評估整合測試整合測試計畫測試結果測試評怙摘要測試設計員相關組系統測試活動>5活動名稱輸入輪出參與人員制訂系統測試計畫軟體專案計晝軟遒需求系統測試計晝測試設計員設計系統測試軟體需求系統測試計畫系統測試案例系統測試程序測試設計員實施系統測試系統測試計晝工作版本系統測試腳本測試設計員執行系統測試系統測試計晝系統測試案例系統測試程序系統測試腳本測試結果測試員評估系統測試測試结果測試分析報告變更請求測試設計員相關組_20為何系統要進行驗證測試AnalyzeDesignjBuild—►Test一Rollout—►Production驗證測試之目的：100x•OptimalCostofQuality*CustomerSatisfaction•ReputationJ-SizeoftheGlobalTestingMarketis$13bnofwhichabout$6.1bnisoutsourcedOutsourcingtoIndiaissettotouchabout$700M-$1bnby2007摘自印度丁.\1\\公司測試簡報主要驗證測試之內容為何商業功能面(BusinessFunctionaHty)•UserInterface-Look&FeetandUsability•End-to**endBusinessTransactions■StaleTransitions•DataQuality•ConfigurationOptionsandCompatibility•Performance•TrainingManuals•ErrorHandling&Recovery資訊技術方面(InformationTechnology)•CodeCoverage•DataFlowCoverage•

Componentorsub-systeminterlaces•Performance,Capacityandvolume•Errorhandlingandrecovery•ReliabilityandStability•DateandTimehandling•Localization•Maintainability•StandardsCompliance摘自印度T:\TA公司測试簡報操作面向(Operations)•Installationandset-up•Backup&RecoveryProcedures•NetworkedandDistributedEnvironments•StandardsCompliance•Security•DocumentationandPackaging軟體驗證測試之困難性(1/2)•需求改變之管理(ChangeManagement)•ImplementationTechnology•ComplexInterfaces•TimeAvailable*跨多種專案及多種DomainKnowledge•Infrastructure■Skills■Tools■Environment摘自印度丁.江\公司測试簡報軟體驗證測試之困難性（2/2）此0湖摘自印度11丁.\公司台灣分公司測試簡稂24驗證測試之困難性-•小實例說明•0日8€1:*美國太空噴射中心實驗室PropulsionLaboratory）如何去驗證及測試新發展完成之人造衛星飛行（如需模擬與外太空通訊必須考量其延遲0.24-0.25秒狀況，0.25秒內會造成多少狀況必須考慮到）；•另人造衛星12年壽命將近，如何將新舊人造衛星進行切換且不能斷訊，否則將受合約罰款等處25衛星通訊意示EaithStation26衛星通訊的限制■延遲：GEOsatellite訊號往返平均延遲0,24〜0.25秒.＜註＞:LGEO(GeostationaryEarthOrbit)satellite平均離地約35,863km.2.電波傳輸速度=30萬km/sec.3.所耗時間=距離/速度，新視野號及先鋒十號太空船籌備及發射-簡要歷程（1/2）新視野號太空船：第_艘飛越和研究冥王星的衛星先鋒十號太空船：第一艘離開太陽系的「人造物體」先鋒十號在200】年4月28日太空船距離地球有丨17億3千萬公里，幾乎是距離太陽最遠冥王星59億公里的兩倍，距離是如此的遙遠，以致無線電來回一趟就需要21時45分一將近一天的時間共同思考：地球與先鋒十號每次通訊需花四小時又二十分鐘，先鋒十號以每秒鐘將近十四公里高速前進，如何非常精準控制好其軌道以及在非常非常短瞬間內與行星間的運用重力助推（重力彈弓效應）加速其前進？請參考補充資料："新視野號（NewHorizons）太空船的籌備及發射-簡要澄程"及”「一息尚存j的先鋒十號”Word檔案資料新視野號及先鋒十號太空船籌備及發射-簡要歷程(2/2)因NASA在大型發展案需整合跨領域，如»發射新視野太空船，需整合通信、資訊、軟髏、氣象、天文、航空、物理、材料科學、光學、電機、機械、化工…等)及跨機構/跨國等挑戰性工作；國稅系統只是資訊軟體一個領域，其整合性的複雜及挑戰性還不算太高！=+請回憶在”猪論”章節的”台灣在發展軟體專案上宜加強之項0”的小節中，所提如下內容，應該會有所感觸！以台灣有實際開發過系統工程案的教授於2014年也指出，女士對台灣發展軟«可能落後美國25年的評估似乎有些保守，應該是落後更多！因台灣的大學課程，幾乎沒有開系統工程的必修課程，如何培養整«性之整合能力的人才！29溝通及認知之差異性想要傳達的意念失真30%失真40%接收開發者角色佔丨失真30%幸40%責任認知想要傳達的意念;真實性21%(70嗒*70^*60%本70%>認知者佔責求色%需角60任30需求-分析-設計-測試-交貨認知差異性(1/10)客戶解釋他們想要的需求-分析-設計-測試-交貨認知差異性（2/10）專案主持人對客戶需求認知32需求-分析-設計-測試-交貨認知差異性（3/10）33需求-分析-設計-測試-交貨認知差異性（4/10）34需求-分析-設計-測試-交貨認知差異性(5/10)顧問所描繪的願景需求-分析-設計-測試-交貨認知差異性（6/10）專案的文件36需求-分析-設計-測試-交貨認知差異性（7/10）最後交付給客戶的軟體需求-分析-設計-測試-交貨認知差異性(8/10)38需求-分析-設計-測試-交貨認知差異性（9/10）39需求-分析-設計-測試-交貨認知差異性（10/10）客戶真正需要的40Built-inDesign測試策略系統品質屬性測試功能測試介面測試作業準備測試軟體環境測試硬體環境測試(^0!11£)0加姑Engine就ResourceUsageTes•I/OFunctiorRfcst\•Interface？J?1•F^kiInjectionTe；SmokiReadiness就執行順序執行項目台灣在發展大型資訊軟體專案不易成功之因素•大型資訊軟體專案需投入相當多人力、物力及累積經驗。•台灣大部份廠商無法接受長期投資之效益。42市面上國內外套裝軟體的品質愈來愈差之因素•目前市面上國內外套裝軟體或系統軟體的品質為何愈來愈差之因素？=+為了Timetomarket（搶佔市場）="＞從原先驗證測試品質標準調降來符合市場上市之時間點43軟體品質驗證與測試的控管程序環境管理1缺失管理計畫管理1測試管理整合測試^線上測試客戶需求及1品需求審4______定義測試揉的物及範圍定義測試之階段、行動方案及權贵確锶測試工具、技術及實做方法設計測試案例建立測试脚本及說明建立測試資料執行測試案例及結基分析提出缺失教告重新測試提出測試摘要報告提出缺失摘要報告摘自印度丁.\1\\公司測試簡報44測試自動化生命週期建立並驗執*行自動化哪些要自動化如何自動化證自動化及撰寫報告TestDesignTestScripts>執行工作TestReportsTestLogs摘自印度丁.\1\\公司測試簡報測試自動化之好處•Reuseofautomatedscriptsduringmaintenancephase•FasterTest-Fix-Deploycycle•ReducedTestingeffort(manhours)inSubsequentCycles•ConsistencyinTesting•Possibilityofexecutingtestsbeyondusualworkinghours•IncreaseinmotivationandefficiencyforTesters摘自印度丁.\1\\公司測試簡報46系統測試的目標（軟想工程-*務專家作^17^5）*測試是為發現錯誤而執行程式的過程♦好的測試案例具有極高可能性發現尚未發現的錯誤*成功的測試可發現尚未暴露的錯誤47好的測試屬性（軟题工程-*務專家作法卩17

8）*好的測試：具有發現錯誤較高的機率*好的測試：不會太冗長*好的測試：應是”最好的訓練”---類似企圖、時間與資源限制下的測試……•好的測試：不應太簡單或太複雜48測試人員之層次一般可區分三個等級：L較高層次：撰寫系統規劃書(systemengineer寫)，如需求規格書(SRS)、系統設計規格書(SDS):測試計畫書、整合測試案例(測試設計師)2.第二層次：撰寫Testingprocedure(開發工程師)，如需求分析、需求設計、白箱測驗案例(testpattern)等第三層次：performancetesting(—般人員)，如撰寫測試報告大型系統上線前執行工作--TOPS/Order實際狀況（1/4）❖程式修改版本之控管（如微軟VSS）❖新需求或MR（ModifiedRequirement）之追蹤與驗証❖測試工作•測試工具之評估及選用（或自行開發）•系統功能測試（研發版本，上線版本）•驗証程序工作＞驗証之標準案例設計（含整體功能面及介面，如帳務、Hinet等介面）＞系統功能整合測試＞oc’h，p2，，［^驗言正測試50大型系統上線前執行工作一1'0?8/0]^61^實際狀況（2/4）＞重要介面測試（與帳務、Hinet等系統測試）/驗証介面連線格式（含口1^01：0（301）/驗証介面內容正確性/雙轨測試＞負載測試（或壓力測試）/北區：？次，♦區：？次，南區：？次＞自動測試工作（功能性與負載性）大型系統上線前執行工作一1'0?8/0]^61^實際狀況(3/4)❖系統整體環境之建置•前端軟體自動派送機制•應用伺服器負載效能之參數調整•經負載測試後，系統復原機制之建置(含系統面及資料面)•資料庫之cluster機制、SAN架構建置(備援機制)•MQ(MessageQueue)與CA(ClientAgent)cluster機制建置•系統最佳效能之參數調整，如>資料庫之process數，connection數，sharememory大小設定>APserver之process與thread數>某幾台主機異常時，APServer對DB參數之自動切換機制為何？*大型系統上線前執行工作一1'0?5/0]^6『實際狀況（4/4）❖上線前準備工作•切換計劃書（與現有系統如何切換上線；含功能面、作業面及資料面等）•上線作業工作書・抽轉檔作業•分區上線困難度資料如何一致性，如>中區新系統已上線，北區要上線如何將已執行之跨區受理作業（作註銷方式及北區目前系統之資料如何與新系統之主檔工作檔同步）<•營運管理程序書及技術文件_53_TOPS/Order系統之研發測試程序1.需求人員與使用者確認需求及預定時程2-分析、設計人員規割及指派程式開發人員，同時測試人員開始準備測試計畫及案例設計3.開發人員根據指派工作向建構人員提領程式於發展區進行開發工作4.程式開發完成後，進行各自負責功能之單元測試，並須通過測試5.建構人員部署至品質測試區6.測試人員進行整合測試，並須通過品質測試7.送請區分公司行銷/帳務處進行上線前驗收工作＜註＞:研究所發展環境分為發展區(80)與品質測試區54大型資訊系統上線前…驗證與測試工作*測試案例0^31case):每個交付出去的程式副本都應該附帶一小組測試案例，好讓每個程式使用者可以例行性地確認安裝在他機器上的程式是正確可靠的。((^■15，?219)■主案例：用於測試程式的主要功能，以一般最常發生的狀況當作測試的輸入資料。■罕見合法案例：用於進行邊界值測試，包括輸入資料的最大可能值、最小可能值，以及所有例外但合理的情況。■罕見不合法案例：也是用於進行邊界值測試，所不同是採取相反的角度進行。即輸入不合理資料時，程式系統均能正常運作並帶出適當的偵錯訊息告知使用者。55大型系統上線前驗證測試工作—TOPS/Order實際狀況*驗證測試階段：--規刻階段°＞測試案例的規刻（1^6case101681€836）

--設計階段+測試規格、程序與步驟之擬定一實作階段+測試資料準備、操作方式熟練、測試環境建置--執行階段+安裝待測系統、執行測試、收集分析測試結果、測試報告*研擬了3000多個測試案例，做為系統驗證測試合格之基礎•進行多次的1^1）、（^及彡1、彡2、彡3及冷4整合測試*經歷了2年測試（密集測試半年），約12,000人次驗證測試、20,000訓練人次。_黑箱測試¥8.白箱測試（如，程式檢查：礞認所有指令及條件至少會被執行一次以上）57白箱測試I―I輪入TestCase不須關心■黑箱內之結構與流程n輸出O測試結果黑箱測試新國稅案之非功能測試•性能測試•負載測試•壓力測試(1/3)1.非功能測試之測試類型1,性能測試(PerformanceTesting)•性能測試是通過模擬正式環境之「平時交易量」以及「現行峰時交易量」，测試系統的性能並推算正式環境之預期回應時間，2,負載測試(LoadTesting>•負載測試是以「現行峰時交易量」以及「颢估3年後峰時交易量」進行測試，以驗镫系統的處理能力可滿足預估的業務成長需求，3,墨力測試(StressTesting)•«力測試是在被測試系統上逐漸增加模擬用戶的數量，觀察不同負載下之回應時問，直到發生逾時交易比率達到5%或負載已超過測試計盡之規劃。_新國稅案之非功能測試•性能測試•負載測試•壓力測試(2/3)2.測試模型之建立•依據本栈關與五地區困稅局確認後之「系統設計説明書」中各交易項自之預估使用者量及預估交易量，以模擬其貧狀況為原則建立性能測試*負載測試及壓力測試之測試模型-1.檢測項目之選擇方式：智慧稅務服務平台的所有線上交易項目之預估交易量由高至低排序後，取交易量總計達到前70%之各交易項自列入檢蜊之範圍•2.同時上線使用者(ConcurrentUsers):A.各檢測項吕：各列入檢測項3於「系統設計說明書j中之預估使用者量*同時上線使用者之總量須達10,000人；如各檢測項自之加總使用者數不足時，可採放大處理，2.最低交易量：A.平曰交易量3,000,000筆/日B.峰時交易量750,000