4.3商業(yè)工具分類 本節(jié)介紹了用于汽車行業(yè)的各種測(cè)試工具。 這些工具可分為四大類：基于模型的測(cè)試生成，測(cè)試建模，驗(yàn)證和資源分析工具。 每個(gè)類別說(shuō)明如下。 4.3.1基于模型的測(cè)試生成工具 鑒于所需系統(tǒng)行為的模型，這些工具由模型生成測(cè)試，在目標(biāo)系統(tǒng)上執(zhí)行測(cè)試以檢查系統(tǒng)是否表現(xiàn)的與要求的一樣。 測(cè)試是通過(guò)由模型按一定的度量“覆蓋”其結(jié)構(gòu)產(chǎn)生的。 大多數(shù)的由基于模型的測(cè)試生成工具所提供的覆蓋度量的往往是控制流定向的，例如測(cè)試可以由覆蓋模型的所有分支生成。 4.3.2測(cè)試建模工具 不是由系統(tǒng)模型生成測(cè)試，這些工具是由一個(gè)可能針對(duì)測(cè)試系統(tǒng)特定區(qū)域、可用于不同情況的抽象測(cè)試模型生成測(cè)試的。 該工具支持不同的符號(hào)來(lái)說(shuō)明這些測(cè)試模型。 此外，這些工具能夠在目標(biāo)機(jī)器上進(jìn)行所生成的測(cè)試，并評(píng)估相應(yīng)結(jié)果。 4.3.3驗(yàn)證工具 有了所需系統(tǒng)行為的模型，這些工具就可以進(jìn)行形式驗(yàn)證，就是說(shuō)他們證明或否決該模型關(guān)于那些使用形式化方法的特定屬性的正確性。 一個(gè)屬性通常表現(xiàn)一個(gè)不良情況。一個(gè)驗(yàn)證技術(shù)是證明或反證是否不良情況在模型中保持不變的一種手段。當(dāng)這種情況不變時(shí)，它產(chǎn)生一個(gè)反例證明。如果沒(méi)有反例產(chǎn)生，這意味著該系統(tǒng)內(nèi)沒(méi)有這種情況。 有兩種主要方法：模型檢驗(yàn)和定理證明，被認(rèn)為是汽車領(lǐng)域的形式驗(yàn)證。 對(duì)這些方法的文獻(xiàn)綜述超出了本文的范圍，感興趣的讀者可以指向別處。 4.3.4資源分析工具 工具的第三類分析非功能特性，例如時(shí)間，內(nèi)存使用情況等。舉例來(lái)說(shuō)，當(dāng)危險(xiǎn)發(fā)生時(shí)，重要的是要了解最壞執(zhí)行時(shí)間（ WCET ）的防鎖制動(dòng)系統(tǒng)。此類分析在安全苛求的系統(tǒng)中極為重要。 過(guò)去，這樣的分析是用一個(gè)特設(shè)的方式進(jìn)行的：要么手動(dòng)分析大量的系統(tǒng)仿真，要么通過(guò)在一些測(cè)試場(chǎng)景中運(yùn)行該系統(tǒng)，觀察其性能。然而，這些方法已經(jīng)變得不切和實(shí)際，因?yàn)橄到y(tǒng)的尺寸和目標(biāo)執(zhí)行平臺(tái)的設(shè)計(jì)的復(fù)雜性增加了，特別是在處理器里。 今天，專門的工具正在成為系統(tǒng)的驗(yàn)證過(guò)程用以覆蓋這些方面的一個(gè)組成部分。 由于時(shí)間和內(nèi)存特性與目標(biāo)平臺(tái)的結(jié)構(gòu)特色一致，分析主要是對(duì)循環(huán)X測(cè)試的先進(jìn)水平進(jìn)行的。表1.主要在用工具 1 對(duì)于目標(biāo)平臺(tái)，請(qǐng)查看：http://www.absint.com/ait/trial.htm 2 IBV（基于儀器的驗(yàn)證）[10]是一項(xiàng)指定屬性為一個(gè)連接到模型的顯示器的技術(shù)。然后，它用制導(dǎo)模擬來(lái)尋找侵犯知識(shí)產(chǎn)權(quán)。筆者將這項(xiàng)技術(shù)歸類為驗(yàn)證技術(shù)的一個(gè)變體。 4.4主要在用工具 本節(jié)提供了汽車行業(yè)精選在用工具的一份比較。這些工具是根據(jù)上面解釋的術(shù)語(yǔ)分類的。 表1提供了工具信息表，包括：他們的供應(yīng)商，類別，輸入格式支持和循環(huán)X測(cè)試級(jí)別。大部分的輸入格式是標(biāo)準(zhǔn)建模符號(hào)，可以參考相關(guān)文獻(xiàn)了解詳情。 5 .汽車軟件測(cè)試工具/服務(wù)供應(yīng)商 5.1主要競(jìng)爭(zhēng)者 表2按生產(chǎn)國(guó)順序列出了在歐洲提供軟件測(cè)試工具和/或相關(guān)服務(wù)的主要競(jìng)爭(zhēng)者名單，還包括那些在歐洲市場(chǎng)占有不可忽視份額的工具。這份名單包括公司提供的服務(wù)，主要工具，及其主要專業(yè)領(lǐng)域。名單中還包括在汽車行業(yè)深受肯定的工具應(yīng)用筆記。 5.2其他競(jìng)爭(zhēng)者 有些公司擅長(zhǎng)嵌入式軟件測(cè)試，但很少接觸汽車系統(tǒng)。盡管這份名單并不詳盡，但它包含了Testing Technologies（ DE ） ， Elvior （ EE）和Conformiq （ FI ）公司 。 有些公司擅長(zhǎng)于汽車軟件測(cè)試，但沒(méi)有緊密結(jié)合V模型（參見(jiàn)圖1 ），沒(méi)有大量應(yīng)用代碼級(jí)技術(shù)。其中最值得注意的是LDRA （GB ） ，Prover（ SE ） ， Coverity（US） ，Wind River（US）公司 。6．潛在機(jī)會(huì) 鑒于上述討論，本節(jié)將會(huì)討論一些技術(shù)以及潛在的機(jī)會(huì)。他們能夠成為未來(lái)商用車領(lǐng)域軟件測(cè)試的獨(dú)特賣點(diǎn)。 6.1實(shí)時(shí)和連續(xù)行為 商用車嵌入式系統(tǒng)對(duì)硬實(shí)時(shí)約束規(guī)范很敏感。特別是，微秒范圍內(nèi)工作的傳動(dòng)系和底盤。沒(méi)有實(shí)時(shí)性，就可能有溝通問(wèn)題，尤其是連續(xù)變化的信號(hào)間。此外，實(shí)時(shí)行為在保證可重復(fù)的測(cè)試案例里是一個(gè)重要要求。 這篇文章中討論的大多數(shù)工具是事件驅(qū)動(dòng)性質(zhì)的，極少能夠表現(xiàn)連續(xù)信號(hào)和連續(xù)時(shí)間問(wèn)題。 因此，應(yīng)重點(diǎn)研究這方面的問(wèn)題，尤其對(duì)于即將到來(lái)的新一代混合動(dòng)力商用車。 6.2黑盒組件分析 汽車行業(yè)的黑盒組件分析還沒(méi)有被充分挖掘。 如前所述，許多組件是從供應(yīng)商那作為黑盒解決方案收集的。很難理解在系統(tǒng)中測(cè)試組件及其集成的行為[ 6 ] 。在第4節(jié)提到的種類繁多的工具中有幾個(gè)提供這樣的功能。其中一個(gè)就是從傳統(tǒng)代碼生成Simulink模型來(lái)檢查是否反向工程模型符合代碼行為的Reactis Tester。 當(dāng)代碼不可用時(shí)，弗勞恩霍夫商學(xué)院的RALT是唯一已知工具，能夠保證基于運(yùn)行時(shí)的系統(tǒng)觀察的形式分析。表2．主要競(jìng)爭(zhēng)者 1 AbsInt tools已經(jīng)被應(yīng)用于Bosch，BMW， Daimler， Honda， Mitsubishi和 Volkswagen。 2 RALT是從運(yùn)行時(shí)系統(tǒng)觀察派生出形式模型的黑盒系統(tǒng)的一種逆向工程工具。RALT已被應(yīng)用于車門控制系統(tǒng)[8]。 3 EXAM是奧迪和大眾汽車集團(tuán)合作開(kāi)發(fā)的，并已在內(nèi)部使用[ 15 ] 。 4 TPT提供反應(yīng)測(cè)試，反應(yīng)測(cè)試就是：當(dāng)傳感器信號(hào)超過(guò)某一臨界值時(shí)，立即精準(zhǔn)地反應(yīng)給系統(tǒng)。 5 MaTeLo已被應(yīng)用到奧迪，Johnson Controls，Magneti，雷諾和大眾汽車的汽車系統(tǒng)中。 6 SCADE已被用于商用車領(lǐng)域，尤其是在Liebherr公司的控制系統(tǒng)中[ 14 ] 。 7 Safety TestBuilder已用于測(cè)試Johnson Controls公司的 [ 12 ]輪胎壓力監(jiān)測(cè)系統(tǒng)。 8 CertifyIt已被應(yīng)用于雷諾公司的汽車系統(tǒng)。 9 ENEA已成為DYSCAS （動(dòng)態(tài)自配置汽車系統(tǒng)）項(xiàng)目（ 2006-2008年）的一員，目前已被加入AUTOSAR標(biāo)準(zhǔn)[ 5 ] 。TD- Frame用于LabVIEW測(cè)試管理框架，并與美國(guó)國(guó)家儀器――TestStand的測(cè)試生成及執(zhí)行相掛鉤。 10 Reactis Tester還可以為了應(yīng)用基于模型的測(cè)試技術(shù)，從源代碼反向設(shè)計(jì)模型。Reactis Tester/Validator已經(jīng)應(yīng)用到Robert Bosch[10]公司的汽車系統(tǒng)中。 6.3安全性和可靠性分析 安全性和可靠性是商用車關(guān)注的重點(diǎn)。 現(xiàn)行做法中并沒(méi)有用來(lái)分析可靠性的被認(rèn)可的工具。對(duì)于安全性分析，一方面是進(jìn)行最壞執(zhí)行時(shí)間和內(nèi)存使用情況分析，目前正使用專門的工具，如aiT WCET Analyzers和StackAnalyzer來(lái)執(zhí)行。進(jìn)一步增加安全性和可靠性方法以覆蓋更多方面的潛力是很大的。 6.4工具鏈和GUI 對(duì)于嵌入式軟件測(cè)試的各種不同的準(zhǔn)則，一個(gè)適當(dāng)?shù)墓ぞ呒侵陵P(guān)重要的。從可用性的角度來(lái)看，易用性和圖形化界面是非常重要的。這方面的合理投資，加上幾個(gè)案例研究的例子將有助于吸引汽車行業(yè)的從業(yè)者。7．結(jié)論 本文介紹了商用車領(lǐng)域的軟件測(cè)試的當(dāng)前做法的調(diào)查，也從軟件測(cè)試的角度預(yù)測(cè)了這個(gè)領(lǐng)域的主要特性和潛在的未來(lái)機(jī)會(huì)。 調(diào)查發(fā)現(xiàn)，用于商用車的主要測(cè)試技術(shù)已被用于一般的汽車行業(yè)了。主要的原因是，商用車分享了其大部分的特征給其他類別的道路車輛。 但是，商用車需要優(yōu)秀的方法來(lái)處理特定的工程問(wèn)題。 值得注意的是，這些問(wèn)題在現(xiàn)在的市售工具集行業(yè)里還沒(méi)有得到充分解決。例如：硬實(shí)時(shí)功能，沒(méi)有特殊的工具存在的安全性和可靠性問(wèn)題。 此外，軟件測(cè)試界還沒(méi)有具體關(guān)注混合動(dòng)力商用車將在不遠(yuǎn)的將來(lái)占據(jù)主要市場(chǎng)份額的問(wèn)題。 盡管從業(yè)者已經(jīng)開(kāi)始在汽車行業(yè)宣傳測(cè)試，但這與商用車領(lǐng)域的情況是不同的。 還有許多非正式的工具和方法，但關(guān)于質(zhì)量和生產(chǎn)力的實(shí)際效用的經(jīng)驗(yàn)數(shù)據(jù)卻收集得很少。 因此，有相當(dāng)大的機(jī)會(huì)，讓利益相關(guān)者集中努力創(chuàng)立一個(gè)共同的平臺(tái)，正式通過(guò)商用車領(lǐng)域里的最先進(jìn)技術(shù)。
介紹 測(cè)試是汽車開(kāi)發(fā)過(guò)程中的一個(gè)重要部分。隨著軟件越來(lái)越多地被應(yīng)用于現(xiàn)代汽車，對(duì)嚴(yán)格軟件測(cè)試方法的需求也變得越來(lái)越多。一個(gè)一直被忽略的特殊方面是：具有很多獨(dú)特特色的商用車領(lǐng)域的軟件測(cè)試的實(shí)踐。 本文是對(duì)商用車領(lǐng)域軟件測(cè)試的第一個(gè)全面的研究。但是，許多特征和相關(guān)結(jié)果可以外推到汽車行業(yè)的其他部分，而且更廣泛地，還可以外推到嵌入式系統(tǒng)領(lǐng)域。我們通過(guò)對(duì)用于汽車行業(yè)的26工具和歐洲市場(chǎng)的20個(gè)工具/服務(wù)提供商的調(diào)查研究了現(xiàn)行做法。最后，還預(yù)測(cè)了未來(lái)潛在機(jī)會(huì)的一些方向。 本文希望能給汽車行業(yè)從業(yè)人員提供現(xiàn)被用于汽車領(lǐng)域的軟件測(cè)試工具和服務(wù)的深刻見(jiàn)解。 由于本文重點(diǎn)是商用車領(lǐng)域，工具/服務(wù)提供商可以熟悉這一領(lǐng)域的潛在機(jī)會(huì)。 最后，對(duì)學(xué)生和研究人員來(lái)說(shuō)，了解汽車嵌入式軟件測(cè)試是如何在實(shí)踐中進(jìn)行的，及塑造汽車行業(yè)的新概念有哪些或許也挺有意思的。商用車領(lǐng)域 2.1定義 歐盟根據(jù)其結(jié)構(gòu)及設(shè)備類型的設(shè)計(jì)目的來(lái)定義”商用車”，能夠運(yùn)載：a）超過(guò)九人，包括司機(jī)在內(nèi)；b）貨物和標(biāo)準(zhǔn)油箱[ 1 ] 的任何機(jī)動(dòng)道路車輛都屬于”商用車”。 輕型商用車（ LCV ）是車總重≤3.5噸的商用車的歐盟正式術(shù)語(yǔ)，符合該類別的車輛有面包車，小巴和輕型卡車等；重型商用車（ HCV）是車總重>3.5噸的商用車的歐盟正式術(shù)語(yǔ)，符合該類別的車輛有貨車，卡車，油罐車等。HCV的一個(gè)更廣泛的定義里還包括農(nóng)用車輛（拖拉機(jī)，收割機(jī)等），及施工車輛（巖石鉆機(jī)，推土機(jī)，輪式裝載機(jī)等）在內(nèi)的重型設(shè)備和機(jī)械。 本文的研究范圍涵蓋了輕型和重型商用車。 2.2市場(chǎng)規(guī)模和潛力 商用車輛占有了汽車行業(yè)的一個(gè)具體且不可忽略的市場(chǎng)份額。按照ACEA （歐洲汽車制造商協(xié)會(huì)）數(shù)據(jù)顯示，2012年全世界生產(chǎn)的超過(guò)20萬(wàn)臺(tái)的商用車占據(jù)了歐盟市場(chǎng)11.3％的份額。較2011年，2012年歐盟產(chǎn)的LCV / HCV出口收入增加了22.9 ％[3] 。 同樣， Frost＆Sullivan公司[ 2 ]指出，歐洲對(duì)輕型商用車的需求已經(jīng)遠(yuǎn)遠(yuǎn)超過(guò)其他大洲。特別是混合商用車，在不久的將來(lái)將占據(jù)主要市場(chǎng)份額。一直會(huì)用到大約2016年的大多數(shù)混合LCVs將包括梅賽德斯－奔馳Sprinter和福特Transit Connect的電動(dòng)版本。這兩款車型有望占據(jù)歐洲混合輕型商用車市場(chǎng)的三分之一。 不看生產(chǎn)數(shù)據(jù)統(tǒng)計(jì)，伴隨著全世界24%的年復(fù)合增長(zhǎng)率[ 2 ]，所有主要地區(qū)均有望保持商用車遠(yuǎn)程信息技術(shù)的增長(zhǎng)速度。 2.3質(zhì)量保證的挑戰(zhàn)概述 在現(xiàn)代汽車的發(fā)展趨勢(shì)已從純機(jī)械轉(zhuǎn)向廣泛地電子化。 一輛典型現(xiàn)代汽車?yán)锏碾娮涌刂茊卧‥CU）粗略估計(jì)大約有70個(gè)，包括100多萬(wàn)的目標(biāo)代碼指令和近1 GB的軟件[ 4 ] 。 這一趨勢(shì)也反映在商用車的發(fā)展中。對(duì)嵌入式控制器越來(lái)越多的使用已或多或少地充當(dāng)了商用車遠(yuǎn)程信息的催化劑。 這類車的價(jià)值創(chuàng)造主要是由嵌入式軟件決定的，這不僅增加了成本和復(fù)雜性的，還增加了嵌入式軟件的潛在缺陷。機(jī)械缺陷逐漸減少的同時(shí)，電子系統(tǒng)造成的缺陷卻正在迅速增加[ 5 ] 。傳動(dòng)、線控、導(dǎo)航、人機(jī)工程學(xué)和信息娛樂(lè)類技術(shù)的進(jìn)步要求嵌入式系統(tǒng)方法中有嚴(yán)格的質(zhì)量保證措施。全球汽車業(yè)也普遍如此。 但是，商用車行業(yè)尤其受到旨在提高環(huán)境保護(hù)，安全（ ISO 26262/IEC 61508 ）和質(zhì)量保證措施（ IEEE 610 ） [ 9 ]的嚴(yán)格法規(guī)的影響， 。 為了滿足當(dāng)下目標(biāo)，就要完全更新?lián)Q代正在開(kāi)發(fā)中的發(fā)動(dòng)機(jī)，底盤和車身。所需解決的問(wèn)題是：應(yīng)該在商用車先進(jìn)的嵌入式系統(tǒng)中使用什么樣的，以及如何運(yùn)用恰當(dāng)?shù)馁|(zhì)量保證策略。 3．視覺(jué)測(cè)試領(lǐng)域特征 本節(jié)從測(cè)試的角度來(lái)描述：商用車領(lǐng)域的特征是相當(dāng)重要的。 3.1安全性高要求 安全性是商用車的一個(gè)極其嚴(yán)格的要求。 歐洲道路評(píng)估計(jì)劃的目的是：到2020年，要把歐洲交通事故的概率減少到零死亡。——該項(xiàng)目被稱為Vision Zero。相關(guān)的標(biāo)準(zhǔn)，如ISO 26262 [ 9 ] ，也對(duì)汽車行業(yè)施加壓力，使之為了讓工程道路更安全去開(kāi)發(fā)協(xié)議，工具和最佳實(shí)踐準(zhǔn)則。 還有一些其他專門針對(duì)商用車的安全措施。例如，重型卡車對(duì)由于開(kāi)車時(shí)不經(jīng)意地超出側(cè)翻閾值而直接造成的翻車事件要多加注意。因此，制造商已經(jīng)投入了相當(dāng)多的時(shí)間和資源建立安全措施（例如：翻滾穩(wěn)定控制系統(tǒng)）以應(yīng)付重型商用車的這種情況。 3.2可靠性高需求 可靠性關(guān)注的是系統(tǒng)中故障率的量化。軟件可靠性是一定執(zhí)行時(shí)間內(nèi)軟件不會(huì)失敗的概率。 迄今為止在汽車領(lǐng)域，相較于其他嵌入式系統(tǒng)領(lǐng)域如航空電子設(shè)備[4]，可靠性并未受到正式管理。 此外，商用車應(yīng)該在艱苦的，安全性很苛刻的環(huán)境下也能正常工作，如重型卡車裝載數(shù)噸燃料，巖石鉆機(jī)鉆探不規(guī)則表面。因此，低可靠性會(huì)導(dǎo)致運(yùn)行過(guò)程中出現(xiàn)危險(xiǎn)情況。 他們的預(yù)期壽命要比正常客車長(zhǎng)。所有這些情況都對(duì)車輛的可靠性和耐用性附加了要求。 3.3實(shí)時(shí)電子控制單元（ECU）功能 商用車嵌入式系統(tǒng)的復(fù)雜性很大程度上是因?yàn)榇蠖鄶?shù)汽車系統(tǒng)的其它類并不正視實(shí)時(shí)性和界面限制。 對(duì)汽車軟件工程實(shí)踐的研究[ 4 ]表明，大部分車輛功能是由硬質(zhì)和軟質(zhì)實(shí)時(shí)任務(wù)實(shí)現(xiàn)的。 極端情況下，多達(dá)95 ％的功能由硬實(shí)時(shí)任務(wù)模擬，最有可能是商用車，因?yàn)閷?duì)于商用車，像具有離散事件軟實(shí)時(shí)功能的多媒體功能和人體舒適感功能并不太重要。 此外，要求不軟不硬但有時(shí)又介于兩者之間的功能，往往模擬為硬質(zhì)[ 4 ]的 。典型的要求包括任務(wù)間的優(yōu)先關(guān)系和抖動(dòng)。 時(shí)間限制，例如截止時(shí)限在單個(gè)應(yīng)用程序中可以變化多達(dá)三個(gè)數(shù)量級(jí)，通常從毫秒到幾秒。 這方面的測(cè)試是極具挑戰(zhàn)性的，因?yàn)橐粋€(gè)系統(tǒng)的正確性不僅取決于其邏輯正確性，還取決于結(jié)果生成的確切時(shí)間。 往往很難追蹤和再現(xiàn)錯(cuò)誤，因?yàn)檫@需要對(duì)決定何時(shí)模擬系統(tǒng)及何時(shí)期望反應(yīng)有很高的精確度。 3.4交錯(cuò)配置及變體
商用車的產(chǎn)品體積通常比客車小。而且，用戶往往對(duì)諸如發(fā)動(dòng)機(jī)扭轉(zhuǎn)力，有效載荷等[5]技術(shù)規(guī)范要求更多。因此，汽車制造商經(jīng)常用產(chǎn)品變體滿足更大的客戶群，從而增加市場(chǎng)份額及產(chǎn)品生產(chǎn)量。所以，商用車輛的嵌入式系統(tǒng)包括來(lái)自多個(gè)供應(yīng)商的組件，且存在于大量的配置和變體里。
這就導(dǎo)致了為了覆蓋龐大的產(chǎn)品變體而進(jìn)行的測(cè)試活動(dòng)方面的巨大的工作量。
3.5分布式開(kāi)發(fā)
由于商用車部件變體的不一致性，汽車制造商不可能開(kāi)發(fā)其所有的內(nèi)部產(chǎn)品。相反，他們更愿意依賴第三方供應(yīng)商成熟的專業(yè)知識(shí)。
由于這個(gè)原因，部分還因?yàn)閲?yán)格的成本要求，商用車的發(fā)展在很大程度上被分散和外包[ 6 ]了 。這就形成了許多供應(yīng)鏈關(guān)系使得規(guī)范最新及各級(jí)一致很困難。
事實(shí)上，制造商最終也沒(méi)能在一個(gè)“黑盒”元件的內(nèi)部設(shè)計(jì)出什么細(xì)節(jié)[4]。這就增加了定位單元和集成層次的組件測(cè)試誤差的復(fù)雜性。
4 .汽車軟件測(cè)試實(shí)踐
本節(jié)概述了汽車軟件測(cè)試?yán)锏膶?shí)踐情況。
本研究著眼于商用車領(lǐng)域，但本節(jié)的研究結(jié)果適用于整個(gè)汽車行業(yè)。
請(qǐng)注意，本節(jié)中的經(jīng)驗(yàn)僅限于汽車行業(yè)主要名人們使用的主流做法。還有其他一些包括研究和技術(shù)創(chuàng)新的做法，被排除在本研究之外。
這里，我們的目的是提供一些明確的汽車行業(yè)的主要做法。
4.1基于模型的開(kāi)發(fā)和測(cè)試
根據(jù)作者與主要汽車制造商、供應(yīng)商合作的經(jīng)驗(yàn)，現(xiàn)代汽車開(kāi)發(fā)過(guò)程中模型驅(qū)動(dòng)工程有著強(qiáng)勁的發(fā)展勢(shì)頭。這包括開(kāi)發(fā)過(guò)程的各個(gè)階段，即從需求到驗(yàn)證。
模型是表示系統(tǒng)行為一部分的一個(gè)抽象視圖。
工程師很早期就使用特定領(lǐng)域建模技術(shù)為系統(tǒng)行為建模，使他們能夠通過(guò)模型自動(dòng)生成代碼并在實(shí)施前測(cè)試系統(tǒng)，快速開(kāi)發(fā)系統(tǒng)。
基于模型的測(cè)試的基本思想是：應(yīng)用選定的算法由模型[13]自動(dòng)生成測(cè)試，而不是手動(dòng)創(chuàng)建測(cè)試用例。
除了自動(dòng)化程度高，基于模型的測(cè)試還有助于由抽象層面來(lái)維持系統(tǒng)模型間的可追蹤性并由系統(tǒng)執(zhí)行層面來(lái)測(cè)試輸出間的可追蹤性。這就使得錯(cuò)誤的來(lái)源容易追蹤，也降低了整體測(cè)試活動(dòng)的精力和成本。
4.2循環(huán)X測(cè)試水平
基于模型的開(kāi)發(fā)和測(cè)試的不同階段是用汽車SPICE開(kāi)發(fā)標(biāo)準(zhǔn)所推薦的V模型（見(jiàn)圖1）手動(dòng)描述的。
V模型通常被設(shè)計(jì)來(lái)進(jìn)行符合開(kāi)發(fā)流程的不同水平的測(cè)試工作。
這些水平的測(cè)試被稱為循環(huán)模型，循環(huán)軟件，循環(huán)處理器（HIL）和循環(huán)硬件（又名循環(huán)X [ 7 ] ）測(cè)試，說(shuō)明如下。
MIL （循環(huán)模型） ：
MIL提供可用系統(tǒng)（或子系統(tǒng)）模型的測(cè)試，且該模型及其環(huán)境沒(méi)有任何物理硬件就可以進(jìn)行仿真模擬。該系統(tǒng)的輸入、輸出界面被定義為關(guān)于不同的測(cè)試場(chǎng)景。
輸入信號(hào)值進(jìn)行了模擬，且相應(yīng)的輸出信號(hào)值與在該場(chǎng)景中定義的預(yù)期值進(jìn)行了比較。
很早期甚至早在實(shí)施之前，MIL測(cè)試就可以進(jìn)行系統(tǒng)的功能驗(yàn)證。
由于在同一臺(tái)機(jī)器上的模型和環(huán)境類似，所以就不需要實(shí)時(shí)硬件了。
SiL（循環(huán)軟件） ：
SIL進(jìn)行可執(zhí)行代碼段（或?qū)嵤┒危┑臏y(cè)試。
在同一個(gè)機(jī)器上的操作情況相似。因此，此水平不需要實(shí)時(shí)硬件。
所有關(guān)于存儲(chǔ)容量，數(shù)據(jù)結(jié)構(gòu)等的細(xì)節(jié)都是由被模擬的環(huán)境控制的。這確保了任何“運(yùn)行時(shí)錯(cuò)誤”（緩沖區(qū)溢出，除以零，非法類型轉(zhuǎn)換錯(cuò)誤等）在實(shí)施時(shí)的檢測(cè)。
此外，它還使系統(tǒng)行為可以通過(guò)運(yùn)行MIL里同樣的測(cè)試場(chǎng)景對(duì)模型進(jìn)行驗(yàn)證。
PIL （循環(huán)處理器） ：
PIL確保在目標(biāo)處理器或目標(biāo)處理器模擬器上運(yùn)行時(shí)，可以測(cè)試實(shí)施過(guò)程。
執(zhí)行環(huán)境通常仍是通過(guò)一個(gè)專用的實(shí)時(shí)仿真器模擬的。
這個(gè)階段的故障可以與目標(biāo)編譯器（聯(lián)動(dòng)，優(yōu)化選項(xiàng)，等等）或目標(biāo)處理器架構(gòu)聯(lián)系起來(lái)。
MIL和SIL的測(cè)試場(chǎng)景在這可以用來(lái)與原結(jié)果進(jìn)行比較，確保代碼功能正確，即使是在它已被編譯并在目標(biāo)處理器上運(yùn)行后。
HiL（循環(huán)硬件） ：
HiL使現(xiàn)被嵌入實(shí)際硬件（ECU）中的實(shí)施得以被測(cè)試。這是通過(guò)把ECU和一個(gè)專用的實(shí)時(shí)仿真器連接起來(lái)完成的，此仿真器闡明了ECU對(duì)分析結(jié)果的測(cè)試環(huán)境的實(shí)際輸入/輸出。
ECU用來(lái)交流的嵌入式系統(tǒng)的其他部分仍然可以被模擬。
然而，它們與真實(shí)的電子信號(hào)進(jìn)行交互。
HiL里的測(cè)試可以在實(shí)時(shí)環(huán)境中分析代碼和硬件集成。
此水平的故障，也與輸入/輸出界面間的低水平通信，與嵌入式系統(tǒng)的其他部分的實(shí)時(shí)通信有關(guān)。
MIL和SIL的測(cè)試場(chǎng)景可以用來(lái)驗(yàn)證先前觀察到的系統(tǒng)行為。
圖1. V模型闡明循環(huán)X測(cè)試階段
無(wú)論缺陷預(yù)防工作貫徹落實(shí)地多好，軟件組件總有缺陷。這很明顯，因?yàn)?/span>開(kāi)發(fā)商無(wú)法阻止/消除軟件開(kāi)發(fā)周期的所有缺陷。因此，軟件必須進(jìn)行徹底的測(cè)試，然后才交付給最終用戶。測(cè)試人員的責(zé)任是：設(shè)計(jì)既可以（ⅰ）找軟件缺陷，又能（ii ）評(píng)估該軟件的性能，可用性和可靠性等方面的測(cè)試。
現(xiàn)在，為了實(shí)現(xiàn)這些目標(biāo)，測(cè)試人員必須（往往是從一個(gè)非常大的執(zhí)行域中）選擇和/或制定測(cè)試用例的有限數(shù)量。不幸的是，完整的測(cè)試通常不是在這個(gè)范圍，預(yù)算和時(shí)間的約束內(nèi)實(shí)現(xiàn)和/或執(zhí)行的。重要的是，當(dāng)測(cè)試開(kāi)始失控且不按計(jì)劃地運(yùn)行時(shí)，由于預(yù)期無(wú)法實(shí)際，測(cè)試人員往往承受了來(lái)自管理層和利益相關(guān)者的巨大壓力。
因此，測(cè)試人員必須有效地計(jì)劃測(cè)試并制定正確的測(cè)試用例，選擇并執(zhí)行合適的用例，監(jiān)控過(guò)程，以確保有效利用工作資源和時(shí)間。所以，要列出這些無(wú)疑是一項(xiàng)艱巨的任務(wù)；要有效地實(shí)施，測(cè)試人員需要受過(guò)適當(dāng)?shù)慕逃团嘤?xùn)并擁有贏得管理層支持的能力。
一般情況下，測(cè)試人員會(huì)用兩種不同的測(cè)試方法，其中，使用常規(guī)方法，測(cè)試人員主要是嘗試用所有可能的輸入去測(cè)試一個(gè)模塊或組件，用所有可能的軟件結(jié)構(gòu)去實(shí)踐。盡管這種做法仍在使用，測(cè)試人員卻在慢慢灌輸推理軟件的一切的價(jià)值，最終使他們能夠檢測(cè)出所有可能存在的缺陷。但見(jiàn)多識(shí)廣且有學(xué)問(wèn)的測(cè)試員們都明白，這在現(xiàn)實(shí)或經(jīng)濟(jì)上是不可行，不可實(shí)現(xiàn)的目標(biāo)。
現(xiàn)在，另一種方法可能就是讓測(cè)試員們隨機(jī)選擇測(cè)試輸入，希望這些測(cè)試能將大的缺陷找出來(lái)。不過(guò)，測(cè)試專家認(rèn)為，隨機(jī)生成的測(cè)試輸入在評(píng)估系統(tǒng)的質(zhì)量屬性方面表現(xiàn)紀(jì)錄欠佳。所以，從測(cè)試的角度來(lái)看，這是一個(gè)無(wú)休止的爭(zhēng)論和懸而未決的問(wèn)題。盡管如此，我們還是認(rèn)為，測(cè)試員的最終目標(biāo)是了解測(cè)試的功能、輸入/輸出域和使用環(huán)境，等等。
同樣，對(duì)于某些特定類型的測(cè)試，測(cè)試人員也需要詳細(xì)地了解代碼是如何構(gòu)造的。此外，測(cè)試人員也需要利用關(guān)于常在軟件開(kāi)發(fā)或維護(hù)過(guò)程中生成的特定缺陷的知識(shí)。有了這些信息，測(cè)試者就必須明智地選擇測(cè)試輸入的子集，以及被認(rèn)為最有可能找測(cè)試過(guò)程中條件和限制內(nèi)的缺陷的測(cè)試輸入組合。然而，這個(gè)過(guò)程需要時(shí)間和精力。所以，測(cè)試人員知道且贊同：只有開(kāi)發(fā)出基于執(zhí)行的測(cè)試的有效測(cè)試用例，才能最大化和/或優(yōu)化對(duì)時(shí)間和資源的利用。
“有效測(cè)試用例”我們是指：“一個(gè)很可能找出缺陷的測(cè)試用例” 。因此，制定有效測(cè)試用例的能力對(duì)于一個(gè)組織邁向一個(gè)更高質(zhì)量的測(cè)試過(guò)程來(lái)說(shuō)是非常重要的；反過(guò)來(lái)， 一個(gè)組織邁向一個(gè)更高質(zhì)量的測(cè)試過(guò)程對(duì)制定有效測(cè)試用例的能力也有許多積極影響。
例如，如果測(cè)試用例是有效的，那么：
檢測(cè)缺陷的概率更大。
更有效地利用組織資源。
測(cè)試再用的可能性更高。
更符合測(cè)試、項(xiàng)目進(jìn)度、預(yù)算，更重要地，提供更高質(zhì)量的軟件產(chǎn)品的可能性。
測(cè)試用例設(shè)計(jì)方法 - 概念化
上面介紹了有效測(cè)試用例的種種好處，但縝密考慮測(cè)試人員用來(lái)設(shè)計(jì)這些有效測(cè)試用例的方法也同樣重要。為了回答這個(gè)問(wèn)題，有必要把軟件作為一個(gè)精心設(shè)計(jì)的產(chǎn)品來(lái)查看和/或檢查。現(xiàn)在，有了這個(gè)觀念，就有兩個(gè)基本方法可以用來(lái)設(shè)計(jì)測(cè)試用例：
黑盒（有時(shí)也稱為功能或規(guī)格）測(cè)試方法。
白盒（有時(shí)也稱為clear或透明盒 ）測(cè)試方法。
使用黑盒測(cè)試方法，測(cè)試人員把SUT （測(cè)試中的軟件）當(dāng)作一個(gè)不知道其內(nèi)部結(jié)構(gòu)（即如何運(yùn)作）的不透明盒子，測(cè)試人員只知道它的作用。使用這種方法的SUT的大小可以是一個(gè)簡(jiǎn)單的模塊、成員函數(shù)、對(duì)象群、一個(gè)子系統(tǒng)、或一個(gè)完整的軟件系統(tǒng)。此外， SUT的基礎(chǔ)行為或功能的描述可以由正式規(guī)格，輸入/處理/輸出圖（ IPO），或一套定義明確的先決、后置條件來(lái)提供；重要的是，另一個(gè)值得一提的信息來(lái)源是：需求規(guī)格說(shuō)明文檔，通常描述SUT的功能，輸入及預(yù)期輸出。現(xiàn)在，鑒于上述來(lái)源，測(cè)試員提供指定輸入到SUT，進(jìn)行測(cè)試運(yùn)行，然后確定所產(chǎn)生的輸出是否與說(shuō)明文檔中提供的一致。因?yàn)楹诤袦y(cè)試方法只考慮了軟件的行為和功能，它通常被稱為功能測(cè)試，或基于規(guī)范的測(cè)試。這種方法特別有用，極有助于找到要求和規(guī)格中的缺陷。
與此相反，白盒測(cè)試方法關(guān)注將被測(cè)試的軟件的內(nèi)部結(jié)構(gòu)。因此，使用白盒測(cè)試方法來(lái)設(shè)計(jì)測(cè)試用例，測(cè)試人員應(yīng)該先了解結(jié)構(gòu)，且為了實(shí)現(xiàn)這一目標(biāo)，必須可隨時(shí)參考和理解代碼或適當(dāng)?shù)念悅未a的要求。一旦對(duì)結(jié)構(gòu)有了必要的了解，測(cè)試者就可以選擇合適的測(cè)試用例去實(shí)踐特定的內(nèi)部結(jié)構(gòu)要素，并確定它們是否正常工作。例如，測(cè)試用例通常被設(shè)計(jì)來(lái)實(shí)踐所有語(yǔ)句或發(fā)生在一個(gè)模塊或成員函數(shù)中的真/假分支。但是，由于白盒測(cè)試的設(shè)計(jì)，執(zhí)行和結(jié)果分析非常耗時(shí)，這種方法被限制和/或通常只適用于軟件的小部分，如模塊或成員函數(shù)。然而，白盒測(cè)試方法對(duì)于找出設(shè)計(jì)和基于代碼的控件的邏輯缺陷和順序缺陷，初始化缺陷和數(shù)據(jù)流缺陷等特別有用。
然而，從測(cè)試員的角度來(lái)看，要實(shí)現(xiàn)向用戶提供低缺陷高質(zhì)量的軟件的目標(biāo)，必須把這兩種方法都用來(lái)設(shè)計(jì)測(cè)試用例。另外，這兩種方法都支持測(cè)試員選擇有限數(shù)量的將被用于測(cè)試的測(cè)試用例。這兩種方法可以相互補(bǔ)充，因?yàn)槊總€(gè)都或許有助于找到某些特定類型的缺陷。重要的是，有了使用這兩種方法設(shè)計(jì)出的一組測(cè)試用例，測(cè)試員找到SUT中各種不同類型缺陷的機(jī)會(huì)就增加了。
測(cè)試員還有一套有效的可再用的用來(lái)進(jìn)行回歸測(cè)試（更改后的重新測(cè)試），以及軟件測(cè)試的新版本。
上面是一份概要：使用任一設(shè)計(jì)方法制定測(cè)試用例的各種可用方法。
但是，在使用任一設(shè)計(jì)方法準(zhǔn)備測(cè)試用例前有一些因素需要考慮清楚。它們分別是：
測(cè)試相關(guān)風(fēng)險(xiǎn)。
預(yù)期缺陷類型。
測(cè)試員的知識(shí)和經(jīng)驗(yàn)。
測(cè)試水平和必須進(jìn)行分組和管理的小組活動(dòng)。
用于執(zhí)行測(cè)試用例的工具。
應(yīng)用程序，軟件和問(wèn)題域的類型。
客戶要求，等等。
現(xiàn)在除了上述因素，以下幾個(gè)要點(diǎn)和/或問(wèn)題在選擇正確的測(cè)試用例設(shè)計(jì)技術(shù)中發(fā)揮了至關(guān)重要的作用：
基于“經(jīng)驗(yàn)”的測(cè)試用例設(shè)計(jì)
在基于經(jīng)驗(yàn)的技術(shù)中，是人們的知識(shí)，技能和專業(yè)知識(shí)（關(guān)于域，技術(shù)等）構(gòu)成了測(cè)試條件和測(cè)試用例的基礎(chǔ)，且對(duì)制定測(cè)試條件和測(cè)試用例很重要。
在這兒，人們技術(shù)和業(yè)務(wù)兩方面的經(jīng)驗(yàn)都是絕對(duì)必需的，必要的，因?yàn)檫@給測(cè)試分析和設(shè)計(jì)過(guò)程提供了不同的角度。
重要的是，有了他們使用類似系統(tǒng)工作的豐富（前）的經(jīng)驗(yàn)，他們或許對(duì)什么會(huì)出錯(cuò)，什么有助于測(cè)試有了想法和/或深入的理解。
因此，基于經(jīng)驗(yàn)的技術(shù)與基于規(guī)范既與基于結(jié)構(gòu)的技術(shù)偕行，又可用于沒(méi)有規(guī)格，或者規(guī)格不足或過(guò)時(shí)的時(shí)候。
這可能是用于設(shè)計(jì)測(cè)試低風(fēng)險(xiǎn)系統(tǒng)的測(cè)試用例的唯一技術(shù)，但是這種方法可能在非常緊急的情況下特別有用，事實(shí)上，這是導(dǎo)致探索性測(cè)試的一個(gè)因素。
“隨機(jī)”方式—考慮了嗎？
通常，任何軟件模塊或系統(tǒng)都有輸入域，從這個(gè)域里選擇并使用測(cè)試輸入數(shù)據(jù)建和/或執(zhí)行測(cè)試用例。
現(xiàn)在，如果一個(gè)測(cè)試人員從必要輸入域中隨機(jī)選擇輸入，準(zhǔn)備測(cè)試用例，并用它們來(lái)測(cè)試應(yīng)用程序，這種方法被稱為“隨機(jī)測(cè)試”。
例如，如果一個(gè)模塊的有效輸入域是1到100之間所有的正整數(shù)，然后用這種方法測(cè)試人員會(huì)隨機(jī)或胡亂地從該領(lǐng)域內(nèi)選擇值，如，選15 ， 27和33。
但是，使用這種方法，也有一些一直無(wú)解的問(wèn)題：
值（上面的例子中三個(gè)值）足以表明，執(zhí)行測(cè)試用或運(yùn)行例測(cè)試時(shí)，模塊符合其規(guī)格嗎？
是否有其他輸入值，比那些（在本例中）被選中的值，更能找缺陷？
抑或有效輸入域外的任何值應(yīng)該作為執(zhí)行測(cè)試用例的測(cè)試輸入？
這就是說(shuō)，測(cè)試數(shù)據(jù)應(yīng)包括大于100的浮點(diǎn)值，負(fù)值或整數(shù)值？
因此，上述問(wèn)題可以立即通過(guò)更加結(jié)構(gòu)化的黑盒測(cè)試設(shè)計(jì)方法解決，盡管使用隨機(jī)測(cè)試輸入可以節(jié)省一些時(shí)間和精力，其他測(cè)試輸入選擇方法要求。
但是，根據(jù)許多測(cè)試專家，隨機(jī)選擇測(cè)試輸入會(huì)產(chǎn)生一個(gè)有效的用于執(zhí)行測(cè)試用例的測(cè)試數(shù)據(jù)集的機(jī)會(huì)非常小，并且對(duì)于一個(gè)更結(jié)構(gòu)化的方法，隨機(jī)方法生成測(cè)試輸入的相對(duì)有效性總成為自省和/或研究的課題。
測(cè)試用例必不可少的部分—概念化
首先，設(shè)計(jì)一個(gè)測(cè)試用例用來(lái)回答這個(gè)問(wèn)題：“我要測(cè)試什么？ ” 。因此，對(duì)于測(cè)試人員來(lái)說(shuō)，開(kāi)發(fā)測(cè)試用例時(shí)周到地考慮很重要，這能夠明確界定和/或提供需被驗(yàn)證以確保系統(tǒng)如期運(yùn)行且能反映出它是用最高質(zhì)量創(chuàng)建的信心的項(xiàng)目（模塊，應(yīng)用程序，子系統(tǒng)，或SUT ）的完整概述。
現(xiàn)在，無(wú)論開(kāi)發(fā)測(cè)試用例時(shí)用了什么設(shè)計(jì)技術(shù)/戰(zhàn)略，測(cè)試人員都必須確保基本涵蓋以下主要內(nèi)容：
摘要 -應(yīng)該反映實(shí)際的主題，類別和功能特性，使測(cè)試人員可以輕易地組織測(cè)試用例成邏輯組，并相應(yīng)地對(duì)它們進(jìn)行分類。
這部分可能具有關(guān)于基于測(cè)試時(shí)間，工作單元，和優(yōu)先級(jí)等的執(zhí)行工作的細(xì)節(jié)。它經(jīng)常被稱為測(cè)試用例的權(quán)重。
測(cè)試用例設(shè)計(jì) - 這部分反映了測(cè)試用例的整體設(shè)計(jì)，其中可能包括一些高層次的描述。
正式審查 - 包含了關(guān)于必須審查或批準(zhǔn)測(cè)試用例、并定義審批流程的團(tuán)隊(duì)清單的詳情。
這部分主要是用來(lái)建立一個(gè)正式的審查程序，以確保業(yè)務(wù)流程符合標(biāo)準(zhǔn)。
此外，它可能包括關(guān)于測(cè)試用例所有人，工作項(xiàng)目，通知和成果總結(jié)等的細(xì)節(jié)
要求 - 本部分旨在：當(dāng)要求被添加到測(cè)試計(jì)劃中時(shí)，聯(lián)系要求與一個(gè)特定的測(cè)試用例。
因此，一旦需求和測(cè)試用例間的聯(lián)系被建立，測(cè)試人員就可以繼續(xù)創(chuàng)建覆蓋報(bào)告來(lái)了解和確定被測(cè)試用例覆蓋的要求的比例有多大。重要的是，通過(guò)保持這種關(guān)聯(lián)，有助于設(shè)置和檢查整個(gè)項(xiàng)目的可追溯性。
先決條件 - 描述了形成前提的或必須在測(cè)試人員可以真正開(kāi)始運(yùn)行/執(zhí)行測(cè)試用例之前發(fā)生的事物。
后置條件 - 不像先決條件，后置條件說(shuō)明了需在測(cè)試用例運(yùn)行/執(zhí)行完成之后發(fā)生的事物。通常是產(chǎn)生適當(dāng)?shù)拇_認(rèn)，如發(fā)送電子郵件通知等。
預(yù)期結(jié)果 - 本部分詳細(xì)介紹了必須在測(cè)試員認(rèn)為測(cè)試運(yùn)行已取得成功前獲得的結(jié)果列表。它可能包含了結(jié)果代碼的文件或圖像。
測(cè)試腳本 - 本部分概述了與特定的測(cè)試用例相關(guān)的測(cè)試腳本。通常，測(cè)試腳本有幾種類型，包括手動(dòng)測(cè)試腳本，關(guān)鍵字啟用測(cè)試腳本，及其中每個(gè)測(cè)試腳本都包含用來(lái)實(shí)現(xiàn)一個(gè)測(cè)試用例的指示的自動(dòng)化功能測(cè)試腳本。
在執(zhí)行過(guò)程中，不像使用工具自動(dòng)運(yùn)行的自動(dòng)化測(cè)試腳本，手工測(cè)試腳本是用語(yǔ)句處理語(yǔ)句。
測(cè)試執(zhí)行記錄 - 通常測(cè)試執(zhí)行記錄包含測(cè)試用例的詳細(xì)信息，及從測(cè)試用例執(zhí)行產(chǎn)生的高層次結(jié)果的細(xì)節(jié)。
重要的是，它們提供測(cè)試執(zhí)行所需的相關(guān)硬件和軟件環(huán)境的細(xì)節(jié)。例如，如果當(dāng)運(yùn)行在兩個(gè)不同的操作系統(tǒng)和兩個(gè)不同的硬件平臺(tái)上，且使用了不同的瀏覽器的測(cè)試用例通過(guò)了，那么測(cè)試員可以為這些組合中的每一個(gè)創(chuàng)建測(cè)試執(zhí)行記錄。
測(cè)試執(zhí)行記錄還包含與該測(cè)試用例運(yùn)行，測(cè)試運(yùn)行的詳細(xì)記錄，以及所有執(zhí)行結(jié)果的詳細(xì)歷史相關(guān)的的整體結(jié)果。
附件 – 本部分通常包含了支持測(cè)試用例的所有文檔和文件。
風(fēng)險(xiǎn)評(píng)估表 - 本部分意在列出與某個(gè)特定的測(cè)試用例相關(guān)的風(fēng)險(xiǎn)。
所以，當(dāng)上述所有部分都與測(cè)試用例相關(guān)，且如果這樣的測(cè)試?yán)粓?zhí)行，那么就是一個(gè)好的跡象：關(guān)于實(shí)現(xiàn)完整的測(cè)試覆蓋率，效率等方面的標(biāo)準(zhǔn)已達(dá)到。
之前做了一個(gè)項(xiàng)目，使用的是
oracle數(shù)據(jù)庫(kù)，
數(shù)據(jù)庫(kù)是建在本地
測(cè)試服務(wù)器上的；現(xiàn)需要將整個(gè)數(shù)據(jù)庫(kù)數(shù)據(jù)結(jié)構(gòu)及數(shù)據(jù)放到正式服務(wù)器上，現(xiàn)將整個(gè)
移動(dòng)過(guò)程做一下記錄，以做備用。
1、首先需要在正式數(shù)據(jù)庫(kù)上創(chuàng)建和測(cè)試數(shù)據(jù)庫(kù)相同名稱的庫(kù)名CSSP，創(chuàng)建之后可以到$ORACLE_HOME$\product\10.2.0\db_1\network\admin\tnsnames.ora這個(gè)文件下看到CSSP庫(kù)的端口號(hào)。
2、打開(kāi)瀏覽器進(jìn)入http://localhost:1158/em 此處的端口可以到$ORACLE_HOME$\product\10.2.0\db_1\install\portlist.ini 下邊查看。使用sys用戶的超級(jí)管理員權(quán)限進(jìn)入em管理，在“管理”模塊下的“表空間”處創(chuàng)建測(cè)試服務(wù)器上相同的表空間名稱，這里創(chuàng)建了 CSSPSPACE。
3、在客戶端機(jī)器上使用oracle的客戶端工具“Net Configuration Assistant”創(chuàng)建CSSP連接。
4、安裝PL/SQL工具。
5、通過(guò)PL/SQL工具使用sys用戶的sysdba權(quán)限連接CSSP數(shù)據(jù)庫(kù)，找到user模塊，創(chuàng)建用戶duxiu，并給予connect和resource權(quán)限，退出PL/SQL程序。
6、使用PL/SQL連接測(cè)試服務(wù)器的數(shù)據(jù)庫(kù)，在“Tools”-》“export user objects ”選項(xiàng)中，導(dǎo)出所有創(chuàng)建表，索引，主鍵，自增長(zhǎng)序列，函數(shù)，存儲(chǔ)過(guò)程，作業(yè)等
sql命令。
7、使用PL/SQL連接正式數(shù)據(jù)庫(kù)，在“file”-》“open”-》“command file”中將上一步導(dǎo)出的腳本導(dǎo)入，并執(zhí)行；這樣數(shù)據(jù)庫(kù)的結(jié)構(gòu)都已創(chuàng)建成功了。接下來(lái)需要導(dǎo)一些數(shù)據(jù)進(jìn)來(lái)。
8、使用PL/SQL連接測(cè)試服務(wù)器的數(shù)據(jù)庫(kù)，在“Tools”-》“export tables”下，選中要導(dǎo)出數(shù)據(jù)的表，下邊導(dǎo)出選項(xiàng)中選擇“PL/SQL Developer”（“Oracle Export”導(dǎo)出選項(xiàng)試過(guò)不知道為什么導(dǎo)出之后，無(wú)法將導(dǎo)出的數(shù)據(jù)再導(dǎo)入進(jìn)去，也沒(méi)報(bào)任何錯(cuò)誤提示；“SQL Inserts”只是生了插入的sql語(yǔ)句，導(dǎo)出效率等操作太差不推薦使用）。“compress file”，“include storage”，“include privileges”也都選中，在“Output file”中選中要導(dǎo)出的文件，點(diǎn)擊“Export”進(jìn)行導(dǎo)出。
9、使用PL/SQL連接正式服務(wù)器的數(shù)據(jù)庫(kù)，在“Tools”-》“Import tables”選項(xiàng)中找到“PL/SQL Developer”選項(xiàng)，在這里只用勾選“Disable triggers”和“Disable foreign key constraints”，在“Import file”選項(xiàng)中找到剛才導(dǎo)出的數(shù)據(jù)文件，點(diǎn)擊“Import”按鈕將數(shù)據(jù)導(dǎo)入。
到此整個(gè)遷移過(guò)程已完成。
1.用system.IO 讀寫來(lái)實(shí)現(xiàn)，如果使用這個(gè)方式，每個(gè)測(cè)試生成一個(gè)報(bào)告，容易開(kāi)啟太多的線程，占用內(nèi)存太多
FileStream ofs1 = new FileStream(path1, FileMode.Create);
StreamWriter owr = new StreamWriter(ofs);
2.開(kāi)發(fā)幫助說(shuō)使用vs com組件里邊的引用，如下鏈接，感覺(jué)這個(gè)實(shí)現(xiàn)方式還更麻煩哪
http://blog.csdn.net/gisfarmer/article/details/3738959
3.再詢問(wèn)一個(gè)測(cè)試網(wǎng)友，他說(shuō)可以用NPOI來(lái)實(shí)現(xiàn)，直接引用dll，寫幾句代碼就能實(shí)現(xiàn)了，
下載地址：http://npoi.codeplex.com/releases
新建ecxel表格，在第一行第一列添加內(nèi)容
excel行從1開(kāi)始，NPOI內(nèi)部從0開(kāi)始；excel列從字母開(kāi)始，NPOI是數(shù)字表示，記得轉(zhuǎn)換
public void NPOITest() { HSSFWorkbook hssWorkbook = new HSSFWorkbook(); ISheet hssSheet = hssWorkbook.CreateSheet("new sheet"); hssSheet.CreateRow(0).CreateCell(0).SetCellValue("This a sample"); FileStream fs = new FileStream(@"d:\temp\test.xls", FileMode.Create); hssWorkbook.Write(fs); fs.Close(); } |
在已有的
test.xls添加數(shù)據(jù)
public void TestExcel() { FileStream file = new FileStream(@"d:\temp\test.xls", FileMode.Open, FileAccess.Read); HSSFWorkbook hssfWork = new HSSFWorkbook(file); ISheet iSheet = hssfWork.GetSheet("new sheet"); //獲取所有行數(shù)，然后再+1的基礎(chǔ)上加入數(shù)據(jù) （lastRowNum是當(dāng)前數(shù)據(jù)的最后一行） iSheet.CreateRow(iSheet.LastRowNum+1).CreateCell(0).SetCellValue("testtest"); FileStream fss = new FileStream(@"d:\temp\test.xls", FileMode.Create); hssfWork.Write(fss); file.Close(); } |
Bugfree是一款優(yōu)秀的
bug管理和追蹤工具，因此受到不少公司的青睞。但實(shí)際的
工作中，我發(fā)現(xiàn)不少開(kāi)發(fā)或是
測(cè)試的同事有一些不好的使用習(xí)慣，使得我們對(duì)Bugfree的利用不夠高效。我下面列出使用Bugfree的一些壞習(xí)慣，以此與各位測(cè)試同仁切磋使用這個(gè)工具的高效的方法。
對(duì)開(kāi)發(fā)的同事而言，可能會(huì)有下面幾條壞習(xí)慣。
壞習(xí)慣一：只采用默認(rèn)的解決方案。
周圍不少開(kāi)發(fā)的同事，在解決掉一個(gè)bug的時(shí)候，往往只采用默認(rèn)的解決方案：fixed。事實(shí)上，Bugfree提供了7種解決bug的方案供程序員選擇。它們分別是：By Design、Duplicate、External、Fixed、Not Repro 、Postponed、Won't Fix 。這7種解決方案反應(yīng)了程序員解決bug的理由。By Design的意思是，設(shè)計(jì)上就是這么定的，bug無(wú)效；Duplicate的意思是，這個(gè)bug已經(jīng)有人提過(guò)，重復(fù)了；External的意思是，軟件本身沒(méi)有問(wèn)題，是外部因素（比如
操作系統(tǒng)）造成的問(wèn)題；Fixed的意思是：bug被解決掉了；Not Repro的意思是，這個(gè)bug無(wú)法重現(xiàn)；Postponed的意思是，這個(gè)bug推遲到以后解決；Won't Fix的意思是，是個(gè)問(wèn)題，但是不值得解決。為什么會(huì)有這種習(xí)慣呢？我詢問(wèn)過(guò)一位開(kāi)發(fā)的同事，他說(shuō)看不懂英文，又懶得去查。另一位開(kāi)發(fā)同事說(shuō)，一開(kāi)始沒(méi)注意到這一項(xiàng)是可選的，時(shí)間久了，自然而然就視而不見(jiàn)了。
改掉這個(gè)習(xí)慣不是更好嗎？我的理由：給bug設(shè)置正確的解決方案，一方面可以減少開(kāi)發(fā)和測(cè)試的溝通障礙，讓測(cè)試員知道程序員為什么要關(guān)掉這個(gè)bug；另一方面可以給bug歸類，便于查找bug和開(kāi)發(fā)后期集中解決bug。
壞習(xí)慣二：只在詳細(xì)信息里寫上：已解決。
由Bugfree提供的7種解決方案，不難看出詳細(xì)信息這一欄多數(shù)情況下是為第四種解決方案Fixed提供補(bǔ)充的。很多bug在被fixed掉以后，如果只在這一欄注明已解決字樣會(huì)有不好的影響。因?yàn)闀r(shí)間久了，或許程序員自己都不清楚這個(gè)bug是怎么被fixed掉的，如果再碰到類似的問(wèn)題又要花很長(zhǎng)時(shí)間去想辦法解決，影響工作的效率。
改掉這個(gè)習(xí)慣不是更好嗎？我的理由：在詳細(xì)信息欄里注明bug被fixed掉的理由，一方面像上面所說(shuō)的可以給開(kāi)發(fā)人員提個(gè)醒，便于解決類似的bug；另一方面對(duì)測(cè)試員也有好處。測(cè)試員在碰到類似的bug以后，能夠知道哪兒出了問(wèn)題，這樣就可以準(zhǔn)確及時(shí)地提醒開(kāi)發(fā)人員，便于bug的修改。
對(duì)測(cè)試的同事而言，可能會(huì)有下面的幾條壞習(xí)慣。
壞習(xí)慣一：創(chuàng)建bug時(shí)，選錯(cuò)了項(xiàng)目。
周圍有測(cè)試同事，在發(fā)現(xiàn)了bug后，就急急忙忙去bugfree里描述bug和指派bug，往往會(huì)忽略其他的選項(xiàng)。就拿這個(gè)項(xiàng)目來(lái)說(shuō)，登錄bugfree后里面就有默認(rèn)的內(nèi)容，但未必是和bug相對(duì)應(yīng)的。如果測(cè)試人員因?yàn)榘l(fā)現(xiàn)了bug，有點(diǎn)興奮，再加上一點(diǎn)粗心就會(huì)忽略這一項(xiàng)。
改掉這個(gè)習(xí)慣不是更好嗎？我的理由：設(shè)置正確的項(xiàng)目可以給bug歸類，便于bug的查找。若選錯(cuò)了項(xiàng)目，難免會(huì)抱怨找不到自己創(chuàng)建的bug，還得通過(guò)其他方式查找這個(gè)沉入“大海”的bug，影響了工作的
心情和效率。
壞習(xí)慣二：創(chuàng)建bug時(shí)，沒(méi)有選/選錯(cuò)了模塊。
創(chuàng)建bug時(shí)，模塊這個(gè)選填項(xiàng)，不僅看起來(lái)不起眼，而且會(huì)讓人誤以為它沒(méi)有用，所以測(cè)試人員往往會(huì)忽略它。 改掉這個(gè)習(xí)慣不是更好嗎？我的理由：設(shè)置正確的模塊，可以給bug分門別類。這樣，開(kāi)發(fā)人員就能很方便知道A模塊有哪些bug，B模塊有哪些bug，讓開(kāi)發(fā)人員對(duì)自己負(fù)責(zé)的項(xiàng)目模塊心里有底。所以，還請(qǐng)測(cè)試人員辛苦下，把模塊這一項(xiàng)設(shè)置好。
壞習(xí)慣三：設(shè)置錯(cuò)誤的嚴(yán)重等級(jí)。
周圍有同事，往往只注重對(duì)bug地描述，不去關(guān)注對(duì)bug等級(jí)的設(shè)置，不利于開(kāi)發(fā)人員優(yōu)先解決嚴(yán)重的bug。其實(shí)Bugfree提供可選的4種嚴(yán)重等級(jí)：1、2、3、4。1是最高等級(jí)，意思是這個(gè)bug導(dǎo)致系統(tǒng)死機(jī)，數(shù)據(jù)丟失或者與需求不符合；2是嚴(yán)重等級(jí)，意思是這個(gè)bug導(dǎo)致計(jì)算出現(xiàn)錯(cuò)誤，功能實(shí)現(xiàn)出現(xiàn)錯(cuò)誤；3是一般等級(jí)，意思是這個(gè)bug是個(gè)合法性問(wèn)題，界面問(wèn)題或是文檔問(wèn)題等；4是最低等級(jí)，意思是這個(gè)bug影響易用性。不少情況下是測(cè)試人員不清楚各種級(jí)別的含義，導(dǎo)致的分類錯(cuò)誤。
改掉這個(gè)習(xí)慣不是更好嗎？
我的理由：設(shè)置正確的嚴(yán)重等級(jí)，可以讓開(kāi)發(fā)人員優(yōu)先解決1、2bug，在項(xiàng)目時(shí)間允許的情況下，再著手解決3、4類bug，以保證產(chǎn)品的質(zhì)量。啰嗦一句，首先要保證產(chǎn)品能用，再去保證產(chǎn)品好用。
其實(shí)最好的習(xí)慣是按照bugfree的格式，把每一項(xiàng)該填的內(nèi)容填好！！
最近，在Sixt（德國(guó)比較大的一個(gè)汽車租賃網(wǎng)站）上，我們把我們的開(kāi)發(fā)環(huán)境從Eclipse遷移到AndroidStudio。這也就意味著我們進(jìn)入了新的編譯系統(tǒng)——Gradle，并且把TDD（
測(cè)試驅(qū)動(dòng)開(kāi)發(fā)）和CI（持續(xù)集成）納入我們的
軟件開(kāi)發(fā)流程。這里不是討論在軟件開(kāi)發(fā)中引入CI會(huì)帶來(lái)怎樣的好處，而是討論在
Android中當(dāng)測(cè)試UI之外的線程時(shí)會(huì)出現(xiàn)的問(wèn)題。
Android中的測(cè)試（寬泛的定義）是一個(gè)
單元測(cè)試集合的擴(kuò)展。涉及初始化、關(guān)閉測(cè)試，包含setUp()和tearDown()操作，使用反射的方式推斷出不同的測(cè)試方式（從JUnit4開(kāi)始我們就可以使用注釋來(lái)指定的優(yōu)先級(jí)和執(zhí)行所有測(cè)試）。一個(gè)典型的測(cè)試結(jié)構(gòu)如下：
publicclassMyManagerTestextendsActivityTestCase{ publicMyManagerTest(Stringname){ super(name); } protectedvoidsetUp()throwsException{ super.setUp(); } protectedvoidtearDown()throwsException{ super.tearDown(); } publicvoidtestDummyTest(){ fail("Failingtest"); } } |
這是一個(gè)非常明顯的示例：實(shí)際開(kāi)發(fā)中，我們想要測(cè)試?yán)鏗TTP響應(yīng)、
SQL存儲(chǔ)等等。在Sixt我們遵從一種Manager/Model方法：每個(gè)Model包含一個(gè)實(shí)體（車、顧客等）的表現(xiàn)。每個(gè)Manager用不同的模型（例如，我們的LoginManager可能需要用戶與之交互的模型）聚合成一套功能。
大多數(shù)的Manager集中執(zhí)行HTTP請(qǐng)求是要從后臺(tái)獲取數(shù)據(jù)。例如，我們用下面的代碼來(lái)執(zhí)行用戶的登錄：
mLoginManager.performLoginWithUsername("username","password",newOnLoginListener(){ @Override publicvoidonFailure(Throwablethrowable){ fail(); } Override publicvoidonSuccess(Usercustomer){ //.. } }); |
應(yīng)用到我們自己的測(cè)試集合后，當(dāng)?shù)玫筋A(yù)期之外的結(jié)果時(shí)，只是讓這一結(jié)果失敗。我們可以看到為什么在onFailure()函數(shù)中我們調(diào)用了fail()。接下來(lái)，即使我用一個(gè)錯(cuò)誤的用戶名也能通過(guò)這個(gè)測(cè)試。思前想后，測(cè)試似乎是按照代碼順序執(zhí)行的，但并沒(méi)有等到回調(diào)函數(shù)的結(jié)果返回再向下執(zhí)行。
這顯然不是一個(gè)好方法。因?yàn)楝F(xiàn)在的程序經(jīng)常通過(guò)異步任務(wù)和回調(diào)方法從后臺(tái)獲取數(shù)據(jù)。嘗試UIThread測(cè)試仍然不行。
最后，我發(fā)現(xiàn)下面這種方法可以行得通。只是用簡(jiǎn)單的CountDownLatch信號(hào)對(duì)象來(lái)實(shí)現(xiàn)wait-notify機(jī)制（你也可以用syncronized(lock){...lock.notify();}，只是這樣代碼并不美觀而已）
那么之前的代碼就變成了下面的模樣：
finalCountDownLatchsignal=newCountDownLatch(1); mLoginManager.performLoginWithUsername("username","password",newOnLoginListener(){ @Override publicvoidonFailure(Throwablethrowable){ fail(); signal.countDown(); } Override publicvoidonSuccess(Usercustomer){ signal.countDown(); } }); signal.await(); |
提到
Windows的UI自動(dòng)化，不得不能不說(shuō)Coded UI測(cè)試。Coded UI測(cè)試是
微軟在VS2010里面推出的一個(gè)新功能，概念其實(shí)也不是很新，就是通過(guò)錄制回放的功能來(lái)盡可能的簡(jiǎn)化Windows的UI自動(dòng)化。
個(gè)人的理解，Coded UI的底層仍然是基于Windows TestAutomation SDK的Code，它的最大的作用就是把Code封裝了一層，使之能為可以調(diào)用的方法，大大簡(jiǎn)化了
測(cè)試人員對(duì)于編碼的硬需求，不懂C#或者VB的測(cè)試人員可以很容易的利用Coded UI開(kāi)展自動(dòng)化。
Coded UI不僅可以測(cè)試Windows的應(yīng)用程序(據(jù)說(shuō)對(duì)WPF支持的特別好)，它也可以對(duì)Web瀏覽器開(kāi)展測(cè)試，VS2010支持微軟的IE和Firefox，我用的是VS2013，還沒(méi)有來(lái)得及用這個(gè)東西測(cè)網(wǎng)站，我一般都用Robotframework + Selenium2library進(jìn)行測(cè)試。
筆者最近在做一個(gè)和SCCM相關(guān)的項(xiàng)目，希望通過(guò)Coded UI能實(shí)施一些UI自動(dòng)化的
工作，嘗試了一下，感受如下
怎么用Coded UI
1. 先分析Windows應(yīng)用程序是啥技術(shù)
這個(gè)估計(jì)測(cè)試人員用肉眼看不出來(lái)，可以請(qǐng)教開(kāi)發(fā)，或者用一些工具幫忙看。Coded UI據(jù)說(shuō)對(duì)WPF支持的比價(jià)好，對(duì)MFC支持的一般。
知道了這點(diǎn)，心里面可以有個(gè)數(shù)，對(duì)后面測(cè)試中可能的風(fēng)險(xiǎn)有個(gè)心理準(zhǔn)備
2. 錄制
打開(kāi)VS，建立一個(gè)
Test Project，然后選Coded UI，VS2013的步驟大概就是這樣，VS2010會(huì)復(fù)雜一點(diǎn), anyway,然后差不多就可以開(kāi)始錄制了
錄制的窗口很小，點(diǎn)擊紅色的按鈕就可以開(kāi)始錄制了，錄制沒(méi)什么特別的，Coded UI會(huì)記錄你的鼠標(biāo)和鍵盤的操作，并把他們變成一些可以用術(shù)語(yǔ)表現(xiàn)得事件。
備注：錄制的時(shí)候可以加入Assertion，這是為了判斷測(cè)試結(jié)果的需要，否則錄下來(lái)的就是一步一步的UI操作，特別注意。加入Assertion需要對(duì)Windows的控件屬性有一點(diǎn)了解。
3. 調(diào)整錄制結(jié)果
錄制完了要點(diǎn)停止，之后點(diǎn)擊中間的階梯的按鈕，就會(huì)出現(xiàn)錄制的動(dòng)作，這些動(dòng)作都用很容易理解的步驟呈現(xiàn)在面板上。之后點(diǎn)擊最右邊的按鈕就可以生成代碼了。
需要給生成的代碼取個(gè)名字，做為一個(gè)動(dòng)作次序的標(biāo)志
4. 調(diào)整UI操作次序以及其他屬性
雙擊右側(cè)Panel的UIMap.uitest，就可以打開(kāi)UI操作的面板
重構(gòu)是對(duì)軟件內(nèi)部結(jié)構(gòu)的一種調(diào)整，目的是在不改變軟件之可察性前提下，提高其可理解性，降低其修改成本。關(guān)于重構(gòu)的至理明言如下：
任何一個(gè)傻瓜都能寫出計(jì)算器可以理解的代碼，唯有寫出人類容易理解的代碼，才是優(yōu)秀的程序員；
事不過(guò)三，三則重構(gòu)；
當(dāng)你接獲bug提報(bào)，請(qǐng)先撰寫一個(gè)
單元測(cè)試來(lái)揭發(fā)這個(gè)bug;
當(dāng)你感覺(jué)需要撰寫注釋，請(qǐng)先嘗試重構(gòu)，試著讓所有的注釋變得多余；
當(dāng)你發(fā)現(xiàn)自己需要為程序增加一個(gè)特性，而代碼結(jié)構(gòu)使你無(wú)法方便的這樣做，就先重構(gòu)那個(gè)程序；
重構(gòu)之前，必須建立一套可靠的測(cè)試機(jī)制；
寫軟件就像種樹(shù)，優(yōu)秀的程序員挖成小坑后隨及填好，繼續(xù)挖下一個(gè)，只會(huì)產(chǎn)生一系列小坑，不會(huì)有大坑，菜鳥(niǎo)則不會(huì)意識(shí)到所挖的坑正在變大，還是不停的挖，直到自己掉進(jìn)大坑，爬不出來(lái)，陷入無(wú)盡的痛苦深淵；
開(kāi)發(fā)時(shí)間越長(zhǎng)，越能體會(huì)垃圾代碼的痛苦，卻不知道如何改進(jìn)；
Kent Beck:我不是一個(gè)偉大的程序員，我只是個(gè)有著一些優(yōu)秀習(xí)慣的好程序員而已；
變量(Variable)
不要定義一個(gè)臨時(shí)變量多次重復(fù)使用，臨時(shí)變量定義仍然應(yīng)該可以自解釋，從變量名稱能夠很好的理解變量的含義和作用。在定義一個(gè)臨時(shí)變量后需要有一段業(yè)務(wù)邏輯才能夠完成對(duì)臨時(shí)變量的賦值的時(shí)候，可以考慮將這段邏輯抽取到一個(gè)獨(dú)立的方法。
doublegetPrice(){ int basePrice = _quantity* _itemPrice; double discountFactor; if (basePrice > 1000) discountFactor = 0.95; else discountFactor = 0.98; return basePrice * discountFactor; } |
重構(gòu)為：
double getPrice(){ return basePrice()* discountFactor(); } private int basePrice(){ return _quantity* _itemPrice; } private double discountFactor(){ if (basePrice()> 1000) return0.95; else return 0.98; } |
當(dāng)遇到復(fù)雜的表達(dá)式的時(shí)候，需要引入解釋變量，因?yàn)閺?fù)雜的表達(dá)式很難進(jìn)行自解釋。
if ((platform.toUpperCase().indexOf("MAC")> -1)&& (browser.toUpperCase().indexOf("IE")> -1)&& wasInitialized()&& resize> 0 ) { // do something } |
重構(gòu)為：
final booleanisMacOs = platform.toUpperCase().indexOf("MAC")>-1; final boolean isIEBrowser =browser.toUpperCase().indexOf("IE") > -1; final booleanwasResized = resize >0; if (isMacOs&& isIEBrowser&& wasInitialized()&& wasResized){ // do something } |
減少對(duì)全局變量的使用，第一個(gè)是全局變量的生命周期很難控制，資源本身無(wú)法得到很快的釋放，其二是過(guò)多使用全局變量導(dǎo)致在調(diào)用方法的時(shí)候很難完全清楚方法說(shuō)需要的入口數(shù)據(jù)信息，其三，多處都可以對(duì)全局變量賦值，我們很難立刻定位到當(dāng)前全局變量的值來(lái)源自哪里?
分解方法(Extract Method)
一個(gè)較大的方法往往也會(huì)分為多個(gè)小的段落，step1,step2,step3，在每一個(gè)步驟都會(huì)考慮添加注釋說(shuō)明。而這些相對(duì)較為獨(dú)立的步驟就可以分解為不同的方法，在分解后方法名可以自解釋方法的功能而不再需要額外的注釋。在一個(gè)類里面如果方法里面有一段代碼在多個(gè)方法中重復(fù)出現(xiàn)，需要抽取該類的公用方法。在多個(gè)不同的類中有一段代碼重復(fù)出現(xiàn)，需要考慮將公用代碼放到公用類中形成公用方法。
方法名需要很好的自解釋方法的功能，方法的返回盡量單一，方法的入口參數(shù)太多的時(shí)候應(yīng)該考慮使用集合，結(jié)構(gòu)或數(shù)據(jù)對(duì)象進(jìn)行參數(shù)的傳遞。參數(shù)的傳遞可能出傳遞的是引用，但不要去修改入口參數(shù)的值。
不要因?yàn)橐粋€(gè)方法里面只有一行，兩行很短而不考慮去分解，分解的時(shí)候更多的是考慮代碼的自解釋性。代碼本身不是解釋的技術(shù)實(shí)現(xiàn)機(jī)制，而是解釋的業(yè)務(wù)規(guī)則和需求。如果代碼不是解釋的業(yè)務(wù)規(guī)則和需求，那么其它人員就很難快速理解。
引入方法對(duì)象來(lái)取代方法，當(dāng)發(fā)現(xiàn)一個(gè)方法只用到該類里面的幾個(gè)關(guān)鍵屬性，方法和類里面其它的方法交互很少，輸出單一。由于該方法和這幾個(gè)屬性內(nèi)聚性很強(qiáng)而和該類其它部分松耦合，因此可以考慮將方法和這部分屬性移出形成一個(gè)單獨(dú)的方法對(duì)象。
移動(dòng)方法，類的職責(zé)要單一，一個(gè)類的方法更多用到了別的類的屬性，這個(gè)方法可能更適合定義在那個(gè)類中。
class Account... private AccountType_type; private int_daysOverdrawn; double overdraftCharge(){ if (_type.isPremium()){ double result = 10; if (_daysOverdrawn > 7) result += (_daysOverdrawn -7)* 0.85; return result; } else return _daysOverdrawn * 1.75; } double bankCharge(){ double result = 4.5; if (_daysOverdrawn > 0) result +=overdraftCharge(); return result; } |
重構(gòu)為：
classAccount... private AccountType _type; private int _daysOverdrawn; double overdraftCharge(){ return _type.overdraftCharge(_daysOverdrawn); } double bankCharge(){ double result = 4.5; if (_daysOverdrawn > 0) result += _type.overdraftCharge(_daysOverdrawn); return result; } classAccountType... double overdraftCharge(Account account){ if (isPremium()){ double result = 10; if (account.getDaysOverdrawn()> 7) result += (account.getDaysOverdrawn()- 7)* 0.85; return result; } else return account.getDaysOverdrawn()* 1.75; } |
分解類(Extract Class)
類的職責(zé)的劃分不容易在初次設(shè)計(jì)時(shí)就準(zhǔn)確把握，所以在編碼時(shí)重構(gòu)是必要的。職責(zé)定位不清！——典型特征是擁有太多的成員變量；而在這里面最重要的就是職責(zé)要單一，屬性和方法是否合適的類中。如果不是就需要考慮分解或合并，擴(kuò)展類的功能，或者抽象相應(yīng)的接口。面向?qū)ο蟮脑O(shè)計(jì)原則如下：
1.單一職責(zé)原則(SRP)-就一個(gè)類而言，應(yīng)該僅有一個(gè)引起它變化的原因
類的職責(zé)要單一，類里面的方法只做類的職責(zé)范圍里面的事情。MVC即是一種粗粒度的職責(zé)話費(fèi)，模型類重點(diǎn)是提供數(shù)據(jù)，控制類重點(diǎn)是處理業(yè)務(wù)邏輯，而V視圖類則是關(guān)注數(shù)據(jù)獲取后的呈現(xiàn)。
數(shù)據(jù)和數(shù)據(jù)操作可以考慮分解，如形成專門的DTO數(shù)據(jù)傳輸對(duì)象類。界面類和界面數(shù)據(jù)提供類也可以考慮分離，如形成專門的Facade層專門負(fù)責(zé)數(shù)據(jù)的準(zhǔn)備和形成。界面層不應(yīng)該有太多的數(shù)據(jù)處理操作。
當(dāng)發(fā)現(xiàn)一個(gè)大的類里面的屬性和方法存在明細(xì)的分組特性的時(shí)候，而且分組直接松散耦合，需要考慮分解為多個(gè)類。
引入方法對(duì)象來(lái)取代方法，當(dāng)發(fā)現(xiàn)一個(gè)方法只用到該類里面的幾個(gè)關(guān)鍵屬性，方法和類里面其它的方法交互很少，輸出單一。由于該方法和這幾個(gè)屬性內(nèi)聚性很強(qiáng)而和該類其它部分松耦合，因此可以考慮將方法和這部分屬性移出形成一個(gè)單獨(dú)的方法對(duì)象。
胖接口也是違反職責(zé)單一，胖接口會(huì)導(dǎo)致所有實(shí)現(xiàn)接口的類都Override所有的接口方法，而有些接口方法往往是子類并不需要的。因此對(duì)于胖接口仍然要從職責(zé)的角度對(duì)接口進(jìn)行拆分。
2.開(kāi)放——封閉原則(OCP)-對(duì)擴(kuò)展開(kāi)放，對(duì)修改封閉
當(dāng)發(fā)生變化時(shí)，只需要添加新的代碼，而不必改動(dòng)已經(jīng)正常運(yùn)行的代碼：軟件人的夢(mèng)想！而要達(dá)到這個(gè)目的，關(guān)鍵是要能夠較為準(zhǔn)確的預(yù)測(cè)業(yè)務(wù)變化會(huì)導(dǎo)致的可能會(huì)發(fā)送變化的模塊或代碼。
3.Liskov替換原則(LSP)
子類型必須能夠替換掉他們的基類型。正是子類型的可替換性，才使得使用基類類型的軟件無(wú)須修改就可以擴(kuò)展。案例參考正方形駁論。矩形的合理假設(shè)：長(zhǎng)、寬可以獨(dú)立變化；而正方形的合理假設(shè)：長(zhǎng)、寬始終相等。因此正方形并不能從矩形繼承。
4.依賴倒置原則(DIP)-高層模塊不應(yīng)該依賴于低層模塊；抽象不應(yīng)該依賴于細(xì)節(jié)。
依賴倒置原則的重點(diǎn)是高層模塊類不要去依賴底層模塊的類，而應(yīng)該去依賴接口，特別是當(dāng)我們預(yù)見(jiàn)到底層模塊的類本身可能會(huì)擴(kuò)展和變化的時(shí)候。這樣在變化的時(shí)候最大的好處就是高層類和接口不用變化。
類是否考慮抽象為接口，一方面是根據(jù)LSP原則進(jìn)行重構(gòu)，一方面是需要觀察我們建立的類，是否有多個(gè)類本身存在相同的行為或方法，如果存在則需要考慮抽象接口。
在當(dāng)今競(jìng)爭(zhēng)激烈的市場(chǎng)上一個(gè)APP的成功離不開(kāi)一個(gè)可靠的用戶界面（UI）。因此，對(duì)功能和用戶體驗(yàn)有一些特殊關(guān)注和照顧的UI的全面測(cè)試是必不可少的。當(dāng)涉及到安卓平臺(tái)及其提出的獨(dú)特問(wèn)題的數(shù)量（安卓就UI提出顯著挑戰(zhàn)）時(shí)，挑戰(zhàn)變得更加復(fù)雜。關(guān)鍵字“碎片化”象征著移動(dòng)應(yīng)用全面測(cè)試的最大障礙，還表明了發(fā)布到市場(chǎng)上的所有形態(tài)、大小、配置類型的安卓設(shè)備所引起的困難。本文將介紹安卓模擬器如何能通過(guò)使用一些技巧和簡(jiǎn)單的實(shí)踐提供覆蓋大量設(shè)備類型的廣泛測(cè)試。
簡(jiǎn)介—分散裝置里的測(cè)試
一般安卓開(kāi)發(fā)者在其日常工作中面臨的最大挑戰(zhàn)之一是：終端設(shè)備和[url=]操作系統(tǒng)[/url]版本的范圍太廣。OpenSignal進(jìn)行的一項(xiàng)研究表明，2013年7月市場(chǎng)上有超過(guò)11，828的不同安卓終端設(shè)備，所有設(shè)備在類型/大小/屏幕分辨率以及特定配置方面有所不同。考慮到前一年的調(diào)查僅記錄有3，997款不同設(shè)備，這實(shí)在是一個(gè)越來(lái)越大的挑戰(zhàn)障礙。
圖1. 11，828 款安卓設(shè)備類型（ OpenSignal研究， 2013年7月[ 1 ] ）分布
從一個(gè)移動(dòng)APP開(kāi)發(fā)角度出發(fā)，定義終端設(shè)備有四個(gè)基本特征：
1．操作系統(tǒng)：由“API指標(biāo)”（ 1 ～18 ）專業(yè)定義的安卓操作系統(tǒng)版本（ 1.1～ 4.3 ），。
2．顯示器：屏幕主要是由屏幕分辨率（以像素為單位），屏幕像素密度（ 以DPI為單位），和/或屏幕尺寸（以英寸為單位）定義的。
3．CPU：該“應(yīng)用程序二進(jìn)制接口” （ABI ）定義CPU的指令集。這里的主要區(qū)別是ARM和基于Intel的CPU。
4．內(nèi)存：一個(gè)設(shè)備包括內(nèi)存儲(chǔ)器（ RAM）和Dalvik 虛擬存儲(chǔ)器（ VM堆）的預(yù)定義的堆內(nèi)存。
這是前兩個(gè)特點(diǎn)，操作系統(tǒng)和顯示器，都需要特別注意，因?yàn)樗麄兪侵苯佑勺罱K用戶明顯感受，且應(yīng)該不斷嚴(yán)格地被測(cè)試覆蓋。至于安卓的版本， 2013年7月市場(chǎng)上有八個(gè)同時(shí)運(yùn)行導(dǎo)致不可避免的碎片的不同版本。七月，近90％這些設(shè)備中的34.1 ％正在運(yùn)行Gingerbread版本（ 2.3.3-2.3.7 ），32.3 ％正在運(yùn)行Jelly Bean（ 4.1.x版），23.3 ％正在運(yùn)行Ice Cream Sandwich（ 4.0.3 - 4.0.4 ）。
圖2. 16款安卓版本分布（OpenSignal研究，2013年7月[1]）
考慮設(shè)備顯示器，一項(xiàng)TechCrunch從2013年4月進(jìn)行的研究顯示，絕大多數(shù)（79.9％）有效設(shè)備正在使用尺寸為3和4.5英寸的“正常”屏幕。這些設(shè)備的屏幕密度在“MDPI”（～160 DPI），“hdpi”（～240 DPI）和“xhdpi”（～320 DPI）之間變化。也有例外， 一種只占9.5％的設(shè)備屏幕密度低“hdpi”（～120 DPI）且屏幕小。
圖3. 常見(jiàn)的屏幕尺寸和密度的分布（谷歌研究，2013年4月）[2]
如果這種多樣性在質(zhì)量保證過(guò)程中被忽略了，那么絕對(duì)可以預(yù)見(jiàn)：bugs會(huì)潛入應(yīng)用程序，然后是bug報(bào)告的風(fēng)暴，最后Google Play Store中出現(xiàn)負(fù)面用戶評(píng)論。因此，目前的問(wèn)題是：你怎么使用合理水平的測(cè)試工作切實(shí)解決這一挑戰(zhàn)？定義測(cè)試用例及一個(gè)伴隨測(cè)試過(guò)程是一個(gè)應(yīng)付這一挑戰(zhàn)的有效武器。
用例—“在哪測(cè)試”、“測(cè)試什么”、“怎么測(cè)試”、“何時(shí)測(cè)試”？
“在哪測(cè)試”
為了節(jié)省你測(cè)試工作上所花的昂貴時(shí)間，我們建議首先要減少之前所提到的32個(gè)安卓版本組合及代表市場(chǎng)上在用的領(lǐng)先設(shè)備屏的5-10個(gè)版本的顯示屏。選擇參考設(shè)備時(shí)，你應(yīng)該確保覆蓋了足夠廣范圍的版本和屏幕類型。作為參考，您可以使用OpenSignal的調(diào)查或使用手機(jī)檢測(cè)的信息圖[3]，來(lái)幫助選擇使用最廣的設(shè)備。
為了滿足好奇心，可以從安卓文件[5]將屏幕的尺寸和分辨率映射到上面數(shù)據(jù)的密度（“ldpi”，“mdpi”等）及分辨率（“小的”，“標(biāo)準(zhǔn)的”，等等）上。
圖5. 多樣性及分布很高的安卓終端設(shè)備的六個(gè)例子（手機(jī)檢測(cè)研究，2013年2月）[3]
有了2013手機(jī)檢測(cè)研究的幫助，很容易就找到了代表性的一系列設(shè)備。有一件有趣的瑣事：30％印度安卓用戶的設(shè)備分辨率很低只有240×320像素，如上面列表中看到的，三星Galaxy Y S5360也在其中。另外，480×800分辨率像素現(xiàn)在最常用（上表中三星Galaxy S II中可見(jiàn)）。
“測(cè)試什么”
移動(dòng)APP必須提供最佳用戶體驗(yàn)，以及在不同尺寸和分辨率（關(guān)鍵字“響應(yīng)式設(shè)計(jì)”）的各種智能手機(jī)和平板電腦上被正確顯示（UI測(cè)試）。與此同時(shí)，apps必須是功能性的和兼容的（兼容性測(cè)試），有盡可能多的設(shè)備規(guī)格（內(nèi)存，CPU，傳感器等）。加上先前獲得的“直接”碎片化問(wèn)題（關(guān)于安卓的版本和屏幕的特性）， “環(huán)境相關(guān)的”碎片化有著舉足輕重的作用。這種作用涉及到多種不同的情況或環(huán)境，其中用戶正在自己的環(huán)境中使用的終端設(shè)備。作為一個(gè)例子，如果網(wǎng)絡(luò)連接不穩(wěn)定，來(lái)電中斷，屏幕鎖定等情況出現(xiàn)，你應(yīng)該慎重考慮壓力測(cè)試[4]和探索性測(cè)試以確保完美無(wú)錯(cuò)。
圖6. 測(cè)試安卓設(shè)備的各個(gè)方面
有必要提前準(zhǔn)備覆蓋app最常用功能的所有可能的測(cè)試場(chǎng)景。早期bug檢測(cè)和源代碼中的簡(jiǎn)單修改，只能通過(guò)不斷的測(cè)試才能實(shí)現(xiàn)。
“怎么測(cè)試”
將這種廣泛的多樣性考慮在內(nèi)的一種務(wù)實(shí)方法是， 安卓模擬器 - 提供了一個(gè)可調(diào)節(jié)的工具，該工具幾乎可以模仿標(biāo)準(zhǔn)PC上安卓的終端用戶設(shè)備。簡(jiǎn)而言之，安卓模擬器是QA流程中用各種設(shè)備配置（兼容性測(cè)試）進(jìn)行連續(xù)回歸測(cè)試（用戶界面，單元和集成測(cè)試）的理想工具。探索性測(cè)試中，模擬器可以被配置到一個(gè)范圍廣泛的不同場(chǎng)景中。例如，模擬器可以用一種能模擬連接速度或質(zhì)量中變化的方式來(lái)設(shè)定。然而，真實(shí)設(shè)備上的QA是不可缺少的。實(shí)踐中，用作參考的虛擬設(shè)備依然可以在一些小的（但對(duì)于某些應(yīng)用程序來(lái)說(shuō)非常重要）方面有所不同，比如安卓操作系統(tǒng)中沒(méi)有提供程序特定的調(diào)整或不支持耳機(jī)和藍(lán)牙。真實(shí)硬件上的性能在評(píng)價(jià)過(guò)程中發(fā)揮了自身的顯著作用，它還應(yīng)該在考慮了觸摸硬件支持和設(shè)備物理形式等方面的所有可能終端設(shè)備上進(jìn)行測(cè)試（可用性測(cè)試）。
“何時(shí)測(cè)試”
既然我們已經(jīng)定義了在哪里（參考設(shè)備）測(cè)試 ，測(cè)試什么（測(cè)試場(chǎng)景），以及如何（ 安卓模擬器和真實(shí)設(shè)備）測(cè)試，簡(jiǎn)述一個(gè)過(guò)程并確定何時(shí)執(zhí)行哪一個(gè)測(cè)試場(chǎng)景就至關(guān)重要了。因此，我們建議下面的兩級(jí)流程：
1 ．用虛擬設(shè)備進(jìn)行的回歸測(cè)試。
這包括虛擬參考設(shè)備上用來(lái)在早期識(shí)別出基本錯(cuò)誤的連續(xù)自動(dòng)化回歸測(cè)試。這里的理念是快速地、成本高效地識(shí)別bugs。
2 ．用真實(shí)設(shè)備進(jìn)行的驗(yàn)收測(cè)試。
這涉及到：“策劃推廣”期間將之發(fā)布到Google Play Store前在真實(shí)設(shè)備上的密集測(cè)試（主要是手動(dòng)測(cè)試），（例如，Google Play[ 5 ]中的 alpha和beta測(cè)試組） 。
在第一階段，測(cè)試自動(dòng)化極大地有助于以經(jīng)濟(jì)實(shí)惠的方式實(shí)現(xiàn)這一策略。在這一階段，只有能輕易被自動(dòng)化（即可以每日?qǐng)?zhí)行）的測(cè)試用例才能包含在內(nèi)。
在一個(gè)app的持續(xù)開(kāi)發(fā)過(guò)程中，這種自動(dòng)化測(cè)試為開(kāi)發(fā)人員和測(cè)試人員提供了一個(gè)安全網(wǎng)。日常測(cè)試運(yùn)行確保了核心功能正常工作，app的整體穩(wěn)定性和質(zhì)量由測(cè)試數(shù)據(jù)透明地反映出來(lái)，認(rèn)證回歸可以輕易地與最近的變化關(guān)聯(lián)。這種測(cè)試可以很輕易地被設(shè)計(jì)并使用SaaS解決方案（如云中的TestObject的UI移動(dòng)app測(cè)試）從測(cè)試人員電腦上被記錄下來(lái)。
當(dāng)且僅當(dāng)這個(gè)階段已被成功執(zhí)行了，這個(gè)過(guò)程才會(huì)在第二階段繼續(xù)勞動(dòng)密集測(cè)試。這里的想法是：如果核心功能通過(guò)自動(dòng)測(cè)試就只投入測(cè)試資源，使測(cè)試人員能夠?qū)Ｗ⒂谙冗M(jìn)場(chǎng)景。這個(gè)階段可能包括測(cè)試用例，例如性能測(cè)試，可用性測(cè)試，或兼容性測(cè)試。這兩種方法相結(jié)合產(chǎn)生了一個(gè)強(qiáng)大的移動(dòng)apps質(zhì)量保證策略[ 7 ] 。
結(jié)論 - 做對(duì)測(cè)試
用正確的方式使用，測(cè)試可以在對(duì)抗零散的安卓的斗爭(zhēng)中成為一個(gè)有力的工具。一個(gè)有效的測(cè)試策略的關(guān)鍵之處在于定義手頭app的定制測(cè)試用例，并定義一個(gè)簡(jiǎn)化測(cè)試的工作流程或過(guò)程。測(cè)試一個(gè)移動(dòng)app是一個(gè)重大的挑戰(zhàn)，但它可以用一個(gè)結(jié)構(gòu)化的方法和正確的工具集合以及專業(yè)知識(shí)被有效解決掉。