王詩琹,李 彬,盧 葉

（中國電子科技集團公司第三十研究所，四川 成都 610041）

基于GJB5000A的項目全生命周期軟件測試實踐與分析*

王詩琹,李 彬,盧 葉

（中國電子科技集團公司第三十研究所，四川 成都 610041）

軟件測試作為檢驗軟件產(chǎn)品質(zhì)量最有效的方法，已成為軟件工程領(lǐng)域中一個非常重要的研究熱點。基于GJB5000A三級實施標準，分析軟件開發(fā)和測試的關(guān)系，介紹項目全生命周期的軟件測試步驟，提出滿足GJB5000A三級標準的軟件測試方法，旨在將測試工作與項目開發(fā)過程緊密結(jié)合，開發(fā)與測試工作交替進行，并貫穿于項目開發(fā)的全過程，為準備或正在實施GJB5000A三級的項目提供滿足軍用標準的測試指南。

軟件測試；生命周期；質(zhì)量；軟件工程

0 引 言

隨著國防科學技術(shù)快速發(fā)展和高新武器裝備跨越發(fā)展，裝備的復雜程度日益增高。武器裝備的功能結(jié)構(gòu)和系統(tǒng)集成越來越復雜，技術(shù)難度越來越大，質(zhì)量特性內(nèi)涵越來越豐富。自2010年11月1日起，由國務(wù)院﹑中央軍委頒布施行最新的《武器裝備質(zhì)量管理條例》（第582號），對裝備質(zhì)量和管理工作提出了更高的要求。因此，需要運用更科學的質(zhì)量管理方法和更先進的質(zhì)量管理手段，提高武器裝備質(zhì)量水平。

然而，產(chǎn)品的質(zhì)量是“設(shè)計”出來的。各軍工裝備承制單位主要依據(jù)軍用軟件研制能力成熟度模 型（Capability Maturity Model for Military Software Development-GJB5000A）來控制和加強軟件產(chǎn)品質(zhì)量。軟件測試作為保證產(chǎn)品質(zhì)量的主要手段，在軟件工程化實施過程中尤為重要。

軟件測試涉及到項目研制生產(chǎn)的各個階段。項目成員由于分工不同，對測試的側(cè)重點有所不同。開發(fā)人員需重點掌握需求分析階段﹑軟件設(shè)計階段﹑軟件實現(xiàn)階段的測試方法；測試人員需重點掌握單元測試階段﹑組裝測試階段的測試方法；售后服務(wù)人員需重點掌握系統(tǒng)集成階段﹑用戶試用階段﹑售后維護階段的測試方法。本文將打破傳統(tǒng)的單線測試技術(shù)和方法，基于GJB5000A中對測試的相關(guān)要求及規(guī)定，結(jié)合項目全生命周期模型，對軟件測試進行全面分析。

1 軟件測試與開發(fā)過程的關(guān)系

傳統(tǒng)的軟件測試，可以簡單描述為如圖1所示。開發(fā)人員完成任務(wù)后，交付給測試人員。這種模式下，測試人員不能及早發(fā)現(xiàn)需求階段的缺陷，且測試工作的開展也已滯后，無法實現(xiàn)對產(chǎn)品質(zhì)量有效的過程控制和分析，總體進度也可能會由于返工問題而拖延。

圖1 傳統(tǒng)交付測試

全生命周期軟件測試與開發(fā)活動的關(guān)系，如圖2所示。

圖2 全生命周期軟件測試流程

如圖2所示，整個軟件生命周期（SDLC）可分為三條角色主線和四個階段。三條角色主線分別為開發(fā)﹑QA﹑測試（文中主要講解測試）；四個階段分別為需求階段﹑開發(fā)階段﹑發(fā)布階段﹑日常運營。

對于產(chǎn)品而言，每次版本迭代都會經(jīng)歷需求﹑開發(fā)﹑發(fā)布三個階段，最后推向日常運營。此外，發(fā)布階段并不表示終止。如果發(fā)布階段產(chǎn)生設(shè)計變更需求，則將回到需求階段和開發(fā)階段，完成更改后，再重新發(fā)布。這是一個不斷迭代的過程。

測試人員貫穿于這四個階段（每個階段也有開發(fā)人員﹑QA人員對應的活動），主要開展的測試工作歸納如下。

（1）需求階段

在確定軟件開發(fā)可行的情況下，設(shè)計開發(fā)人員將詳細分析軟件需要實現(xiàn)的各個功能。需求階段至關(guān)重要，將為整個軟件開發(fā)項目的成功打下基礎(chǔ)。同樣，需求也是在整個軟件開發(fā)過程中不斷變化和深入的。因此，必須制定需求變更計劃來應付這種變化，以保護整個項目的順利進行。此階段，測試人員需參與需求分析，挖掘用戶描述得較含混的內(nèi)容，參考經(jīng)驗庫，對估算的開發(fā)時間提出質(zhì)疑，而描述也會隨著需求的變更變化。

（2）開發(fā)階段

此階段主要根據(jù)需求分析的結(jié)果，對整個軟件系統(tǒng)進行設(shè)計，并將設(shè)計結(jié)果轉(zhuǎn)換成計算機可運行的程序代碼。在軟件設(shè)計完成后，測試人員需進行嚴密的測試，以發(fā)現(xiàn)軟件在整個設(shè)計過程中存在的問題并加以糾正。整個測試過程分單元測試﹑組裝測試以及系統(tǒng)測試三個階段。測試的方法主要有白盒測試和黑盒測試兩種。此階段，測試人員需提出詳細的測試計劃，并嚴格按照測試計劃進行測試，以減少測試的隨意性；需進行功能要點確認，判斷是否滿足需求階段提出的指標；設(shè)計測試用例，并對用例進行評審；組織測試探索，發(fā)布燃盡圖；總結(jié)開發(fā)缺陷，提出解決方案，并向缺陷經(jīng)驗庫作出貢獻；通過不斷積累，提升開發(fā)自測質(zhì)量；參與集成測試階段的測試，持續(xù)反饋問題。

（3）發(fā)布階段及日常運營

這兩個階段都屬于用戶使用階段，是軟件生命周期中變化不大但持續(xù)時間最長的兩個階段。在軟件開發(fā)完成并投入使用后，由于用戶試用后產(chǎn)生的問題反饋﹑實際使用環(huán)境變化等因素，需要對軟件進行持續(xù)維護和修改。此時，售后服務(wù)人員將與測試人員配合。售后人員收集用戶反饋的問題和提出的改進建議，測試人員據(jù)此編制測試報告﹑缺陷分析統(tǒng)計報告﹑版本問題反饋報告，并向開發(fā)人員提出改進建議。開發(fā)人員完成設(shè)計更改后，測試人員進行回歸測試和確認，最后再次進行發(fā)布并投入運行。

2 全生命周期軟件測試活動

2.1 需求階段測試

在需求階段，開發(fā)人員進行用戶故事分析和評估時，QA人員保證并確認需求活動符合管理過程，管理用戶故事評審和需求變更。測試人員的主要實踐包括：參與用戶故事分析，挖掘故事含混性。

在sprint會議上，對用戶故事進行分析，檢查功能性需求和非功能性需求是否描述清晰。其中，可以將非功能性需求作為驗收要點，如一個用戶故事——“客戶希望提高響應時間”。測試人員應當協(xié)助開發(fā)人員消除故事的含混性“提高什么的響應時間和響應時間為多少”。因此，可以建議修改為“客戶信息普通查詢返回結(jié)果的響應時間為5 s內(nèi)”，說明在“客戶信息”模塊進行“普通查詢”操作，返回結(jié)果的時間在5 s內(nèi)。這個陳述句已經(jīng)清晰表達，也達到消除含混性的效果。同樣，測試人員可以編寫提高查詢效率的用戶故事“客戶在信息查詢模塊進行普通查詢，能夠在5 s內(nèi)返回結(jié)果”“備注：5 s為非功能性需求，也是驗收要點”。

sprint會議上，開發(fā)人員根據(jù)經(jīng)驗出牌（團隊自己定義的規(guī)則，用撲克牌）估算時間，當給出最終結(jié)果的時候，測試人員應當對其進行質(zhì)疑。測試人員借鑒歷史經(jīng)驗庫，分析開發(fā)人員在某方面的技能如何﹑該模塊曾經(jīng)產(chǎn)生過何種程度的缺陷﹑修復缺陷的消耗時間是多少等，綜合考慮，提出疑問，使開發(fā)估算最終的時間盡可能考慮這些因素。當然，測試人員能夠質(zhì)疑的一個前提，是測試人員具備相關(guān)開發(fā)經(jīng)驗。

可見，在需求階段，測試人員要發(fā)揮作用，減少含混性需求引入到開發(fā)階段，同時要協(xié)助開發(fā)人員做好時間估算。

2.2 開發(fā)階段測試

在開發(fā)階段，開發(fā)人員進行架構(gòu)評審，功能要點確認，編碼開發(fā)，單元測試，開發(fā)自測，代碼評審，Bug Fix；QA人員管理評審活動和文檔產(chǎn)物。測試人員的主要實踐如下。

2.2.1 功能要點確認

Xmind是一個非常好用的腦圖工具，通常在開發(fā)人員進行編碼前，測試人員會針對需求處理的用戶故事，與開發(fā)人員進行確認，修正理解偏差，確保需求理解一致。例如，如圖3所示，圖中的某軟件模塊腦圖用例提出，測試人員與開發(fā)人員需共同對測試要點﹑測試用例﹑測試目標﹑風險進行性評估，給出最終的功能要點，并將其作為編碼依據(jù)，為下一步設(shè)計工作做好準備。

圖3 腦圖用例模板

2.2.2 測試用例設(shè)計

測試人員需根據(jù)設(shè)計方案提出用例ID﹑用例名稱﹑測試目的﹑測試級別﹑測試環(huán)境﹑前提條件﹑測試步驟﹑預期結(jié)果﹑設(shè)計人員名單。在設(shè)計測試故事點時，可使用DSL（Domain Specific Language）﹑infoq文章（敏捷測試之借力DSL），對測試用例進行描述。這主要包括三個基本要素（Feature﹑Scenario﹑Example）和兩個補充要素（xmind﹑Requirement）。

Feature：把測試分類到某個模塊，并對這個特性本身的業(yè)務(wù)目的進行相關(guān)描述，引入業(yè)務(wù)目標，傳遞業(yè)務(wù)知識。

Scenario：標明這個Feature的測試場景，可以使用文字描述步驟，或者使用xmind腦圖。

Example：引出具體的數(shù)據(jù)表格，把用到的數(shù)據(jù)展示出來，避免相同步驟導致測試數(shù)據(jù)的變化而重復若干遍工作，造成冗余。

Xmind：腦圖文件，展示測試故事點。

Requirement：關(guān)聯(lián)需求管理系統(tǒng)中提出的需求id。

2.2.3 用例評審

用例評審需堅持同行評審的原則，主要在測試組內(nèi)進行，負責該任務(wù)的開發(fā)人員也會參與。簡單來說，就是對測試用例進行查漏補缺的工作。

2.2.4 測試探索

測試人員在進行“功能要點確認”和“用例評審”后，為保證測試場景的覆蓋率，需要再進行測試探索。在開發(fā)人員完成雛形后，使用探索式測試的策略，對功能基本流程進行有目的的快速走查，挖掘功能不確定的地方和補充測試場景，避免不確定的因素拖延到開發(fā)階段后期，造成返工。其中，功能測試﹑Bug Tracking﹑回歸測試﹑系統(tǒng)測試﹑驗收測試都是日常測試工作的所需環(huán)節(jié)。

2.2.5 燃盡圖發(fā)布

測試人員還有一項重要工作，就是每日發(fā)布燃盡圖，讓團隊了解當前進度情況，總結(jié)問題所在，尋求耗時超過預期時間任務(wù)的解決辦法。圖6為測試人員記錄的某界面軟件模塊開發(fā)任務(wù)進度燃盡圖?？v軸表示總工時數(shù)，橫軸表示計劃天數(shù)，虛線表示計劃完成的基準，實線表示實際剩余工時。

由圖4可知，某界面軟件模塊開發(fā)任務(wù)進度燃盡圖的圖形特點。

圖4 某界面軟件模塊開發(fā)任務(wù)進度燃盡圖

第一，剩余工時在計劃基準上方，代表進度有所延遲，應抓緊進度。發(fā)現(xiàn)此類問題，需要分析總結(jié)，原則是保證交付時間，對相應任務(wù)進行調(diào)整，發(fā)現(xiàn)任務(wù)粒度太大，該拆分的繼續(xù)拆分；對于重構(gòu)需要慎重，不要過度深入重構(gòu)，給測試帶來額外工作量，影響整個進度。對于整個版本而言，只有開發(fā)﹑測試在承諾的時間內(nèi)完成任務(wù)，才是真正完成，而僅僅開發(fā)完成交付算不上成功。

第二，剩余工時與計劃基準接近，代表進展良好，繼續(xù)保持。此時也需要查看在這種進度下，優(yōu)先級高的任務(wù)是否得到時間保證，而不是因為處理完簡單任務(wù)使燃盡圖長得好看。實際中，往往有開發(fā)人員喜歡挑任務(wù)，把簡單易做﹑優(yōu)先級高的任務(wù)先完成。因為這些總在預期內(nèi)能夠完成，所以前期燃盡圖的趨勢看起來沒有問題。因此，要點使跟蹤和控制開發(fā)中后期的進度。

2.2.6 缺陷經(jīng)驗庫

每個團隊都存在開發(fā)/測試新人和開發(fā)/測試老人。當測試人員與開發(fā)新人進行需求確認時，還需要進行缺陷經(jīng)驗教訓的提醒，兩者共同編寫缺陷總結(jié)報告，供后續(xù)開發(fā)人員借鑒。

例如，圖5為某界面軟件的缺陷總結(jié)報告。報告中，對界面軟件的構(gòu)造﹑時間控件﹑查詢條件﹑發(fā)送功能﹑接口﹑賬戶名﹑頁面等功能和性能模塊的缺陷進行了分類描述。

圖5 某界面軟件缺陷總結(jié)

2.2.7 提升開發(fā)自測質(zhì)量

測試人員可在開發(fā)過程中提供相關(guān)檢查單（Checklist），幫助開發(fā)人員在編碼過程中關(guān)注開發(fā)自測的要點，從而提升質(zhì)量。例如，表1為某界面軟件的測試檢查單，測試人員對界面控件﹑下拉框﹑文本輸入﹑按鈕功能﹑界面布局﹑查詢等功能進行檢查，并提出改進建議。

2.2.8 持續(xù)集成

基于成熟的測試工具，如持續(xù)集成（Jenkins）平臺，做到快速構(gòu)建開發(fā)代碼，自動單元測試化，來提高開發(fā)代碼的效率和質(zhì)量。Jenkins是目前業(yè)內(nèi)最流行的快速持續(xù)集成工具之一，其穩(wěn)定的性能和豐富的擴展性，使很多團隊都優(yōu)先選擇它作為項目的主要支持工具。

此平臺可靈活定制自動化測試，團隊成員通過登陸平臺Web界面，按照需求任意選擇部署在平臺上的自動化測試包﹑目標測試環(huán)境﹑測試集和測試用例，提交定制化的自動化執(zhí)行請求。執(zhí)行結(jié)束后，系統(tǒng)自動發(fā)郵件給予通知。此外，不同人員的請求可以實現(xiàn)并行執(zhí)行；所有的自動化執(zhí)行歷史記錄都可以保存在平臺上，可以通過Web方式隨時查閱；支持豐富的插件，用戶可以按照需求進行選擇安裝和配置，以實現(xiàn)生成執(zhí)行狀態(tài)表格，自動部署/更新自動化測試包等高級功能。

負責單元測試﹑集成測試﹑自動化測試（Selenium）的開發(fā)人員，都會收到失敗構(gòu)建的郵件。這種方式可確保單元測試﹑集成測試﹑自動化測試的有相關(guān)人員同時關(guān)注，并共同維護。

測試人員主要需反饋的問題如下：

①Code coverage：團隊要求代碼覆蓋率在80%以上；

②Test success：團隊要求測試成功率在100%；

③Duplication：團隊要求代碼重復率在10%以下；

④Violations：團隊要求Major類別的代碼規(guī)則缺陷在20以下；

⑤開發(fā)團隊必須保證每個環(huán)境的質(zhì)量目標，才能夠保證整個的質(zhì)量目標。

可見，測試人員與開發(fā)人員是協(xié)助關(guān)系，類似于質(zhì)量天枰的兩邊，任何一邊的工作沒有做好，天枰都將失去平衡。

表1 某界面軟件測試checklist

2.3 發(fā)布階段測試

在發(fā)布階段，開發(fā)人員需完成線上申請﹑線上部署﹑服務(wù)監(jiān)控等工作；QA人員主要負責管理評審活動和文檔產(chǎn)物。測試人員的主要實踐如下。

2.3.1 測試報告

完成驗收測試，提供測試報告，給出測試數(shù)據(jù)度量。

例如：

①測試發(fā)現(xiàn)缺陷總數(shù)：測試過程中產(chǎn)生的去除狀態(tài)為“無效”“不用改”的缺陷數(shù)目；

②測試發(fā)現(xiàn)嚴重缺陷數(shù)：測試過程中產(chǎn)生的并去除狀態(tài)為“無效”“不用改”的﹑且嚴重性為“Major”和“Critical”的缺陷總數(shù)目；

③測試發(fā)現(xiàn)缺陷修復數(shù)：測試過程中產(chǎn)生的狀態(tài)為“已關(guān)閉”的缺陷數(shù)量；

④未解決缺陷數(shù)：去除狀態(tài)為“無效”“不用改”“關(guān)閉”的缺陷總數(shù)；

⑤缺陷修復率：（測試發(fā)現(xiàn)缺陷的修復數(shù)）÷（測試發(fā)現(xiàn)缺陷總數(shù)）×100%；

⑥嚴重缺陷率：（測試發(fā)現(xiàn)嚴重缺陷數(shù)）÷（測試發(fā)現(xiàn)缺陷總數(shù)）×100%；

⑦嚴重缺陷修復率：（已修復的嚴重缺陷數(shù)）÷（測試發(fā)現(xiàn)嚴重缺陷數(shù)）×100%；

⑧測試需求覆蓋率：已測試需求個數(shù)÷需求總數(shù)×100%。

2.3.2 缺陷統(tǒng)計分析報告

測試人員還需對當前版本的缺陷進行統(tǒng)計分析。缺陷種類分為關(guān)鍵缺陷﹑主要缺陷﹑中等缺陷﹑輕微缺陷，并按軟件的功能模塊分別進行統(tǒng)計。表2為測試人員給某界面軟件提出的缺陷統(tǒng)計表，按9個功能模塊進行統(tǒng)計。其中，關(guān)鍵缺陷數(shù)0個﹑主要缺陷數(shù)5個﹑中等缺陷數(shù)10個﹑輕微缺陷數(shù)27個，并橫向統(tǒng)計出每個單一模塊的缺陷總數(shù)。

表2 某界面軟件缺陷統(tǒng)計表

根據(jù)軟件缺陷統(tǒng)計表自動生成柱狀統(tǒng)計圖表，如圖6所示，可直觀看出此軟件的缺陷分布情況，即主要集中在輕微缺陷上。

圖6 某界面軟件缺陷柱狀分布

測試人員需和開發(fā)人員共同分析缺陷來源，并按團隊統(tǒng)計出關(guān)鍵缺陷﹑主要缺陷﹑中等缺陷﹑輕微缺陷的來源，如表3所示。

表3 某界面軟件缺陷來源統(tǒng)計表

最后，測試人員將缺陷問題反饋給開發(fā)人員進行修改，并完成回歸測試，按缺陷狀態(tài)計算出測試度量數(shù)據(jù)，如表4所示。結(jié)果顯示，某界面軟件的缺陷總數(shù)為42，回歸測試后已關(guān)閉缺陷40個，嚴重缺陷數(shù)全部關(guān)閉，缺陷修復率為95%，嚴重缺陷修復率為100%。

2.3.3 測試進度和問題分析

通過對某界面軟件的缺陷統(tǒng)計表﹑來源統(tǒng)計表和缺陷狀態(tài)表的統(tǒng)計數(shù)據(jù)綜合分析，得出以下結(jié)論：從BUG嚴重級別分布來看，Major級別以上的BUG 占12%，比重不高，說明大部分的主要功能已經(jīng)實現(xiàn)。其中，在sonar定義級別的缺陷主要集中在代碼規(guī)范和單元測試覆蓋率，說明代碼質(zhì)量有待提高；版本測試的前期時間較充足，后期隨著開發(fā)提交完成的功能點增多，BUG數(shù)量增多，剩余測試時間變得緊張；在版本測試期間，發(fā)現(xiàn)測試環(huán)境存在1次代碼被覆蓋﹑2次因開發(fā)人員操作失誤影響測試執(zhí)行的情況，故需要QA加強配置管理的監(jiān)督工作。

可見，測試人員應當持續(xù)反饋﹑改進﹑總結(jié)每個版本發(fā)生的問題（不管是缺陷，還是過程中出現(xiàn)的），并對缺陷進行分析，總結(jié)規(guī)律，幫助開發(fā)人員建立良好習慣，改進代碼的質(zhì)量。

2.4 日常運營階段測試

日常運營階段并不表示項目已經(jīng)進入終止階段，即使需求﹑開發(fā)﹑發(fā)布階段的活動已完成，只要還在為用戶提供服務(wù)，項目的日常運營活動就將存在。開發(fā)人員需要按事件觸發(fā)時機進行生產(chǎn)故障登記；QA人員要對日常運營活動進行維護和管理。

測試人員的主要實踐如下。

第一，版本問題反饋和改進提議。對日常運營發(fā)生的問題，總結(jié)反饋，提出改進建議，并且跟蹤實施。

表4 某界面軟件缺陷狀態(tài)表

第二，生產(chǎn)故障分析。協(xié)助開發(fā)排查生產(chǎn)故障，避免測試場景的遺漏。

3 結(jié) 語

軟件開發(fā)工作，從開發(fā)初期的問題定義及規(guī)劃，到各個階段任務(wù)的有效推動，需做到層層相扣。而軟件測試作為軟件開發(fā)過程中的關(guān)鍵環(huán)節(jié)，把握著軟件的質(zhì)量，在項目全生命周期中發(fā)揮著至關(guān)重要的作用。本文提出的全生命周期軟件測試實踐，強調(diào)貫穿每個階段的測試活動，并嚴格遵循GJB5000A標準要求，為實施三級標準的項目提供完整的測試流程。但不論是開發(fā)還是測試，要理解雙方的活動價值，保證每個環(huán)節(jié)的質(zhì)量，才能夠保證產(chǎn)品的全程質(zhì)量。

參考文獻：

[1] 葉嫻.淺談計算機軟件工程化管理[J].電子世界,2014(08):261.

YE Xian.Discussion on Computer Software Engineering Management[J].Electronic World,2014(08):261.

[2] 肖云.淺析計算機軟件工程的管理和應用[J].電腦知識與技術(shù),2016(12):88-89.

XIAO Yun.Analysis on the Management and Application of Computer Software Engineering[J].Compu ter Knowledge and Technology,2016(12):88-89.

[3] 何寧.淺談計算機軟件工程化管理[J].信息系統(tǒng)工程,2014(10):58.

HE N ing.D iscussion on Com pu ter So ftware Engineering Management[J].In formation Systems Engineering,2014(10):58.

[4] 中國人民解放軍總裝備部.軍用軟件研制能力成熟度模型（GJB5000A）[S].2008.

General Armament Department of the People's Liberation Army.Capability Maturity Model for Military Software Development-GJB5000A[S].2008.

Practice and Analysis of Project Life-Cycle Software Test based on GJB5000A

WANG Shi-qin, LI Bin, LU Ye

(No.30 Institute of CETC, Chengdu Sichuan 610041, China)

As one of the most effective methods for testing the quality of software products, software testing now becomes a very important research focus in the field of software engineering. This paper, based on the implementation of GJB5000A three standards, analyzes the relationship of between software development and testing, describes the software testing procedures of project life-cycle, propose the software testing methods in satisfying GJB5000A three standards. For purpose to closely integrate test and project development process, the development and the testing work are alternately carried out throughout the whole process of project development, thus provide a testing guidance satisfying military standard for preparing to implement or being implemented GJB5000A three-standard projects.

software test; life cycle; quality; software engineering

TP311.5

A

1002-0802(2016)-11-1567-08

10.3969/j.issn.1002-0802.2016.11.029

王詩琹（1984—），女，學士，工程師，主要研究方向為GJB5000A三級標準實施管理﹑嵌入式設(shè)備硬件設(shè)計與測試；

李 彬（1979—），男，學士，工程師，主要研究方向為計算機科學技術(shù)﹑軟件測試與集成；

盧 葉（1982—），女，學士，工程師，主要研究方向為通信技術(shù)﹑品牌推廣與市場策劃。

2016-07-10；

2016-10-25 Received date:2016-07-10;Revised date:2016-10-25