官术网_书友最值得收藏!

1.3 大數據測試方法

傳統軟件測試過程中,由于測試成本的約束,測試用例的總數是小樣本的有限集合。但當軟件擁有復雜的結構或采用構件化設計時,測試人員很難設計出測試用例來完全覆蓋軟件中的所有構件組合;當軟件處于復雜的使用環境時,測試人員很難設計出測試用例來模擬軟件實際使用中的所有場景;當軟硬件緊密結合開發時,測試人員很難設計出測試用例來涵蓋每一次的軟硬件組合。

傳統軟件開發的生命周期是從需求分析開始,到軟件產品發布截止的。但隨著時代的發展,軟件并非是在發布之后就停止更新,往往會在很短的時間內繼續推出新的版本,如部分品牌的手機操作系統已經實現了一月甚至一周一更新。因此,從長時間看,軟件處于一個長期迭代的過程,可以在每一次軟件開發和修改時采用傳統軟件測試技術進行測試,并在軟件的某一版本發布之后實施大數據測試。

如圖1.1所示,在經典的瀑布式軟件開發流程中,軟件測試包含單元測試、集成測試、系統測試和驗收測試4個階段。單元測試往往不會過多地涉及其他程序或者模塊,因此軟件復雜程度對單元測試階段的影響是最小的。在集成測試和系統測試階段,軟件復雜程度的增加會導致測試成本的激增。但在這兩個測試階段,用戶參與程度低,因此很難獲得大量用戶使用軟件時產生的數據。一般在軟件的某個版本發布之后,用戶才會大量使用該軟件,這也為收集用戶的使用數據提供了可能。如果能對這些數據進行深入的大數據分析,就能發現傳統軟件測試階段不易發現的錯誤。這種做法的好處有兩點:一是節約了測試成本,海量的用戶在真實環境中對軟件進行了“操作性測試”,而且這個過程并不需要測試人員去構造和執行測試用例;二是大數據測試方法能夠發現傳統軟件測試階段難以發現的軟件錯誤。如在實際使用中,軟件的操作環境是極為復雜的,而在傳統軟件測試階段,測試人員很難模擬所有測試場景。又比如在對服務器的壓力測試中,用戶對軟件的某種極端操作會導致服務器不定期產生錯誤(小概率事件),而這些錯誤很難在傳統的壓力測試環節暴露出來。只有通過收集海量用戶使用軟件的數據,使用大數據測試方法才能有效地發現這種小概率事件。

圖1.2顯示了大數據測試方法的測試流程。傳統軟件的4個測試階段是在軟件版本發布之前完成的,大數據測試方法包括用戶使用、數據收集、大數據分析及缺陷挖掘4個階段。與敏捷開發方法類似,大數據測試方法同樣需要用戶的參與,不同的是參與用戶的數量。敏捷開發以用戶的需求進化為核心,采用迭代、循序漸進的方法進行軟件開發,因此僅需少量的用戶參與開發,提出并修改需求。而大數據測試方法需要收集海量的用戶使用數據,這相當于海量用戶對軟件進行測試。此外,如何收集海量用戶使用數據則是大數據測試的另一關鍵技術。傳統用戶使用數據的收集一般都是被動的,即軟件提示用戶書寫并發送軟件崩潰時的相關信息給軟件公司。這種方式原始又落后,因為大多數用戶會因為懶惰而不去做這件事情。大數據時代用戶使用數據的收集是主動式的,即自動模擬用戶的操作,并采用軟件自動抓取用戶操作失效時的數據,再在大數據分析階段利用大數據的一些相關技術來處理并分析海量的數據。在傳統關系數據庫中,同一字段屬性中有且僅有同一類型的數據,屬性中的每一個數據都是一個不可分割的項。但大數據則不同,同一屬性中的數據可以是不同的類型,也可以由多個項構成,因此,傳統數據庫的處理方法不能對大數據進行有效處理,需要運用專門的大數據處理技術。軟件缺陷挖掘是指從海量數據中發現一個軟件Bug后,采用大數據技術再次從數據中挖掘出更多具有相同特征的軟件Bug。

圖1.1 在瀑布式軟件開發流程中的4個測試階段

圖1.2 大數據測試的流程圖

大數據測試思想的核心是通過分析海量用戶的使用數據來發現傳統軟件測試階段不易檢測出來的軟件缺陷,而不是單純地從技術角度出發設計測試用例,探測軟件缺陷。注意:在實踐中,大數據測試方法并不能替代傳統的軟件測試方法,即使探測出了軟件缺陷,仍需要軟件測試人員采用傳統的軟件測試方法設計測試用例,進而發現軟件錯誤的位置并修復。

主站蜘蛛池模板: 山丹县| 永济市| 金寨县| 白山市| 道孚县| 涞源县| 万宁市| 科技| 苍山县| 于田县| 乌鲁木齐市| 潮安县| 高邑县| 桃江县| 思茅市| 阿合奇县| 西吉县| 宜丰县| 老河口市| 沐川县| 定结县| 临沧市| 石城县| 珲春市| 肇源县| 镇安县| 银川市| 宽甸| 奇台县| 无为县| 怀柔区| 沐川县| 恩平市| 五大连池市| 尼勒克县| 江西省| 桃园县| 武冈市| 临西县| 黄梅县| 贵德县|