軟工概論：利用軟件測試的策略

軟工概論：利用軟件測試的策略軟工概論：利用軟件測試的策略2什么是軟件質(zhì)量？軟件質(zhì)量的定義不明確，就談不上軟件測試。高質(zhì)量的軟件是一個重要目標(biāo)，在一般意義上，軟件質(zhì)量可以這樣定義：在一定程度上，應(yīng)用有效的軟件過程，創(chuàng)造有用的產(chǎn)品，為生產(chǎn)者和使用者提供明顯的價值。軟工概論：利用軟件測試的策略3軟件質(zhì)量保證延伸前述的質(zhì)量定義，軟件質(zhì)量保證就是為了保證軟件高質(zhì)量而必需的“有計劃、系統(tǒng)化的行動模式”。軟件質(zhì)量保證（質(zhì)量管理）是適用于整個軟件過程的一種普適性活動，而不僅僅是在編碼完成之后才開始進(jìn)行。軟工概論：利用軟件測試的策略4軟件質(zhì)量保證軟件質(zhì)量保證是由兩個不同人群相聯(lián)系的多種任務(wù)組成——分別是做技術(shù)工作的軟件工程師和負(fù)有質(zhì)量策劃、監(jiān)督、記錄、分析和報告責(zé)任的軟件質(zhì)量保證組。其中，軟件工程師通過采用可靠的技術(shù)方法和措施，進(jìn)行技術(shù)評審，并進(jìn)行周密計劃的軟件測試來獲得質(zhì)量?？梢?，軟件測試是軟件質(zhì)量保證活動中的一部分。軟件測試測試是在交付產(chǎn)品給最終用戶之前，帶著特定的目的在運(yùn)行程序的過程中發(fā)現(xiàn)錯誤。測試的目的是為了發(fā)現(xiàn)測試對象的問題，而不是證明測試對象沒有問題。軟工概論：利用軟件測試的策略軟工概論：利用軟件測試的策略6測試可以提高軟件的質(zhì)量嗎？軟件公司一般都有自己的測試中心或測試部門，他們的職責(zé)和作用是什么呢？讀者可能會不加思索地回答：“測試可以提高軟件產(chǎn)品的質(zhì)量！”

我們說：“回答錯了”，為什么？因?yàn)闇y試只能發(fā)現(xiàn)軟件產(chǎn)品的“不符合項(xiàng)”或錯誤(Bug)，不能改正軟件產(chǎn)品的錯誤，所以不能直接提高軟件產(chǎn)品的質(zhì)量。這個問題就是軟件測試的作用。優(yōu)秀的測試團(tuán)隊(duì)可在早期發(fā)現(xiàn)錯誤，使軟件維護(hù)的費(fèi)用降到最低點(diǎn)。測試顯示了什么錯誤需求符合性性能質(zhì)量跡象errorsrequirementsconformanceperformanceanindicationofquality軟工概論：利用軟件測試的策略策略性方法測試策略為軟件開發(fā)人員提供了測試模板，且具備下述一般特征：為完成有效的測試，應(yīng)該進(jìn)行有效的技術(shù)評審。通過評審，許多錯誤可以在測試開始之前排除。測試開始于構(gòu)件層，然后向外“延伸”到整個基于計算機(jī)系統(tǒng)的集成。不同的測試技術(shù)適用于不同的軟件工程的方法和不同的時間點(diǎn)。測試由軟件開發(fā)人員和（對大型項(xiàng)目而言）獨(dú)立的測試組執(zhí)行。測試和調(diào)試是不同的活動，但任何測試策略都必須包括調(diào)試。軟工概論：利用軟件測試的策略V&V（驗(yàn)證與確認(rèn)——VerificationandValidation）軟件測試是通常所講的更為廣泛的主題——驗(yàn)證與確認(rèn)的一部分。驗(yàn)證是指確保軟件正確地實(shí)現(xiàn)某一特定功能的一系列活動。

確認(rèn)指的是確保開發(fā)的軟件可追溯到客戶需求的另外一系列活動。Boehm[Boe81]用另一種方式說明了這兩者的區(qū)別：驗(yàn)證：我們在正確地構(gòu)造產(chǎn)品嗎？確認(rèn)：我們在構(gòu)造正確的產(chǎn)品嗎？軟工概論：利用軟件測試的策略誰測試軟件？開發(fā)者獨(dú)立測試者理解系統(tǒng)，但是測試很“溫和”，由“交付”驅(qū)動。開發(fā)者的軟件分析與設(shè)計連同編碼是建設(shè)性的任務(wù)。其精心地設(shè)計和執(zhí)行測試，試圖證明其程序的正確性，而不是發(fā)現(xiàn)錯誤。必須了解系統(tǒng)，但試圖打破它，由質(zhì)量驅(qū)動。以開發(fā)者的觀點(diǎn)，可以認(rèn)為測試是破壞性的。由一種微妙但確實(shí)存在的企圖，試圖摧毀軟件工程師所建造的大廈。developerindependenttester軟工概論：利用軟件測試的策略測試策略系統(tǒng)工程需求分析模型設(shè)計模型代碼生成單元測試集成測試確認(rèn)測試系統(tǒng)測試SystemengineeringAnalysismodelingDesignmodelingCodegenerationUnittestIntegrationtestValidationtestSystemtest軟工概論：利用軟件測試的策略測試策略我們首先以‘小的測試’開始，隨后轉(zhuǎn)向‘大的測試’對于傳統(tǒng)的軟件我們最初關(guān)注模塊（構(gòu)件）隨后關(guān)注集成模塊對于面向?qū)ο筌浖覀兊年P(guān)注點(diǎn)從單獨(dú)模塊“小的測試”（傳統(tǒng)的觀點(diǎn)）變化到一個包含屬性和操作以及暗含溝通和協(xié)作的面向?qū)ο箢悺＼浌じ耪摚豪密浖y試的策略策略問題早在測試之前，就要以量化的方式規(guī)定產(chǎn)品需求。明確地陳述測試目標(biāo)。了解軟件的用戶并為每類用戶建立用戶描述。指定強(qiáng)調(diào)“快速周期測試”的測試計劃。建立能夠測試自身的“健壯”軟件。測試之前，利用有效的正式技術(shù)評審作為過濾器。實(shí)施正式技術(shù)評審以評估測試策略和測試用例本身。為測試過程建立一種持續(xù)的改進(jìn)方法。軟工概論：利用軟件測試的策略軟工概論：利用軟件測試的策略14單元測試單元測試是對軟件的基本組成單元進(jìn)行測試。單元可以是：函數(shù)、子過程類或類的方法獨(dú)立的過程和函數(shù)一個菜單或顯示界面單元測試被測試的模塊測試用例結(jié)果軟件工程師moduletobetestedtestcasesresultssoftwareengineer軟工概論：利用軟件測試的策略單元測試接口局部數(shù)據(jù)結(jié)構(gòu)邊界條件獨(dú)立路徑錯誤處理路徑測試用例被測試的模塊interfacelocaldatastructuresboundaryconditionsindependentpathserrorhandlingpathsmoduletobetestedtestcases軟工概論：利用軟件測試的策略軟工概論：利用軟件測試的策略17單元測試的主要任務(wù)模塊模塊接口局部數(shù)據(jù)結(jié)構(gòu)獨(dú)立路徑測試出錯處理邊界條件軟工概論：利用軟件測試的策略18

模塊接口這是對模塊接口進(jìn)行的測試，檢查進(jìn)出程序單元的數(shù)據(jù)流是否正確。模塊接口測試必須在任何其它測試之前進(jìn)行。若數(shù)據(jù)不能正確的輸入輸出，那么其他測試都是沒有意義的。軟工概論：利用軟件測試的策略19

局部數(shù)據(jù)結(jié)構(gòu)在模塊工作過程中，必須測試模塊內(nèi)部的數(shù)據(jù)能否保持完整性，包括內(nèi)部數(shù)據(jù)的內(nèi)容、形式及相互關(guān)系不發(fā)生錯誤。對于局部數(shù)據(jù)結(jié)構(gòu)，應(yīng)該在單元測試中注意發(fā)現(xiàn)以下幾類錯誤：（1）不正確的或不一致的類型說明。（2）錯誤的初始化或默認(rèn)值。（3）錯誤的變量名，如拼寫錯誤或書寫錯誤。（4）下溢、上溢或者地址錯誤。軟工概論：利用軟件測試的策略20獨(dú)立路徑測試在單元測試中，最主要的測試是針對路徑的測試。測試用例必須能夠發(fā)現(xiàn)由于計算錯誤、不正確的判定或不正常的控制流而產(chǎn)生的錯誤。執(zhí)行控制結(jié)構(gòu)中的所有獨(dú)立路徑以確保模塊中的所有語句至少能執(zhí)行一次。軟工概論：利用軟件測試的策略21出錯處理測試出錯處理的重點(diǎn)是模塊在工作中發(fā)生了錯誤，其中的出錯處理設(shè)施是否有效。好的設(shè)計要求能夠預(yù)置出錯條件并設(shè)置異常處理路徑，以便當(dāng)錯誤確實(shí)出現(xiàn)時重新確定路徑或徹底中斷處理。檢驗(yàn)程序中的出錯處理可能面對的情況有：（1）對運(yùn)行發(fā)生的錯誤描述難以理解。（2）所報告的錯誤與實(shí)際遇到的錯誤不一致。（3）出錯后，在錯誤處理之前就引起系統(tǒng)的干預(yù)。（4）例外條件的處理不正確。（5）提供的錯誤信息不足，以至于無法找到錯誤的原因。軟工概論：利用軟件測試的策略22邊界條件邊界測試是單元測試的最后一步，必須采用邊界值分析方法來設(shè)計測試用例，測試邊界條件，確保在達(dá)到邊界值的極限或受限處理的情形下，看模塊是否能夠正常工作。邊界測試是最重要的單元測試任務(wù)之一。軟件通常在邊界出錯。也就是說，錯誤行為往往出現(xiàn)在處理n維數(shù)組的第n個元素，或者第i次循環(huán)的第i次調(diào)用，或者遇到允許出現(xiàn)的最大、最小數(shù)值時。使用剛好小于、等于或者大于最大值或最小值的數(shù)據(jù)結(jié)構(gòu)、控制流和數(shù)值作為測試用例就很有可能發(fā)現(xiàn)錯誤。軟工概論：利用軟件測試的策略23何時進(jìn)行單元測試單元測試常常是和代碼編寫工作同時進(jìn)行的，在完成了程序編寫、復(fù)查和語法正確性驗(yàn)證后，就應(yīng)進(jìn)行單元測試用例設(shè)計。在單元測試時，如果模塊不是獨(dú)立的程序，需要設(shè)置一些輔助測試模塊。輔助測試模塊有兩種：（1）驅(qū)動模塊(Drive)

用來模擬被測試模塊的上一級模塊，相當(dāng)于被測模塊的主程序。它接收數(shù)據(jù)，將相關(guān)數(shù)據(jù)傳送給被測模塊，啟動被測模塊，并打印出相應(yīng)的結(jié)果。軟工概論：利用軟件測試的策略24何時進(jìn)行單元測試（2）樁模塊(Stub)

用來模擬被測模塊工作過程中所調(diào)用的模塊。它們一般只進(jìn)行很少的數(shù)據(jù)處理。驅(qū)動模塊和樁模塊都是額外的開銷，雖然在單元測試中必須編寫，但并不需要作為最終的產(chǎn)品提供給用戶。單元測試環(huán)境被測模塊樁模塊樁模塊驅(qū)動模塊結(jié)果接口局部數(shù)據(jù)結(jié)構(gòu)邊界條件獨(dú)立路徑錯誤處理路徑測試用例ModulestubstubdriverRESULTSinterfacelocaldatastructuresboundaryconditionsindependentpathserrorhandlingpathstestcases軟工概論：利用軟件測試的策略集成測試策略集成測試是構(gòu)造軟件體系結(jié)構(gòu)的系統(tǒng)化技術(shù)，同時也是進(jìn)行一些已在發(fā)現(xiàn)與接口相關(guān)的錯誤的測試。選擇：?

“大爆炸”方法，非增量式的?

增量構(gòu)建策略軟工概論：利用軟件測試的策略軟工概論：利用軟件測試的策略27非增量式測試非增量式測試是采用一步到位的方法來構(gòu)造測試：

——對所有模塊進(jìn)行個別的單元測試后，按照程序結(jié)構(gòu)圖將各模塊連接起來，把連接后的程序當(dāng)作一個整體進(jìn)行測試。非增量式測試的缺點(diǎn)：

——當(dāng)一次集成的模塊較多時，非增量式測試容易出現(xiàn)混亂，因?yàn)闇y試時可能發(fā)現(xiàn)了許多故障，為每一個故障定位和糾正非常困難，并且在修正一個故障的同時，可能又引入了新的故障，新舊故障混雜，很難判定出錯的具體原因和位置。軟工概論：利用軟件測試的策略28增量式測試增量式測試的集成是逐步實(shí)現(xiàn)的：

——逐次將未曾集成測試的模塊和已經(jīng)集成測試的模塊（或子系統(tǒng)）結(jié)合成程序包，再將這些模塊集成為較大系統(tǒng)，在集成的過程中邊連接邊測試，以發(fā)現(xiàn)連接過程中產(chǎn)生的問題。按照不同的實(shí)施次序，增量式集成測試又可以分為三種不同的方法：（1）自頂向下增量式測試（2）自底向上增量式測試（3）三明治測試——混合增量測試軟工概論：利用軟件測試的策略29自頂向下增量式測試自頂向下增量式測試表示逐步集成和逐步測試是按照結(jié)構(gòu)圖自上而下進(jìn)行的，即模塊集成的順序是首先集成主控模塊（主程序），然后依照控制層次結(jié)構(gòu)向下進(jìn)行集成。從屬于主控模塊的按深度優(yōu)先方式（縱向）或者廣度優(yōu)先方式（橫向）集成到結(jié)構(gòu)中去。深度優(yōu)先方式的集成：

——首先集成在結(jié)構(gòu)中的一個主控路徑下的所有模塊，主控路徑的選擇是任意的。廣度優(yōu)先方式的集成：

——首先沿著水平方向，把每一層中所有直接隸屬于上一層的模塊集成起來，直到底層。自頂向下集成帶樁的頂層模塊測試一次替換一個樁模塊，“深度優(yōu)先”當(dāng)集成新的模塊時，重新運(yùn)行某些測試子集ABCDEFGtopmoduleistestedwithstubsstubsarereplacedoneatatime,"depthfirst"asnewmodulesareintegrated,somesubsetoftestsisre-run軟工概論：利用軟件測試的策略軟工概論：利用軟件測試的策略31自底向上增量式測試自底向上增量式測試表示逐步集成和逐步測試的工作是按結(jié)構(gòu)圖自下而上進(jìn)行的，即從程序模塊結(jié)構(gòu)的最底層模塊開始集成和測試。由于是從最底層開始集成，對于一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經(jīng)集成并測試完成，所以不再需要使用樁模塊進(jìn)行輔助測試。在模塊的測試過程中需要從子模塊得到的信息可以直接運(yùn)行子模塊得到。自底向上集成一次替換一個驅(qū)動模塊，“深度優(yōu)先”集成工作模塊并將其分組為簇ABCDEFG簇driversarereplacedoneatatime,"depthfirst"workermodulesaregroupedintobuildsandintegratedcluster軟工概論：利用軟件測試的策略三明治測試帶樁測試頂層模塊ABCDEFG簇集成工作模塊并將其分組為簇TopmodulesaretestedwithstubsWorkermodulesaregroupedintobuildsandintegratedcluster混合增量式測試是把自頂向下測試和自底向上測試這兩種方式結(jié)合起來進(jìn)行集成和測試。這樣可以兼具兩者的優(yōu)點(diǎn)，而摒棄其缺點(diǎn)。軟工概論：利用軟件測試的策略回歸測試回歸測試重新執(zhí)行已測試過的某些子集，以確保變更沒有傳播不期望的副作用。無論什么時候修正軟件，軟件配置的某些方面（程序、文檔或支持?jǐn)?shù)據(jù)）也發(fā)生變更?；貧w測試有助于保證變更（由于測試或其他原因）不引入無意識行為或額外的錯誤?；貧w測試可以手工進(jìn)行，方法是重新執(zhí)行所有測試用例的子集，或者利用捕捉/回放工具自動進(jìn)行。軟工概論：利用軟件測試的策略冒煙測試為生產(chǎn)軟件創(chuàng)建“每日構(gòu)建”的一種常見方法冒煙測試步驟：將已經(jīng)轉(zhuǎn)換為代碼的軟件構(gòu)件集成到“構(gòu)建”中去。

一個構(gòu)建包括所有的數(shù)據(jù)文件、庫、可復(fù)用的模塊以及實(shí)現(xiàn)一個或多個產(chǎn)品功能所需的工程化構(gòu)件。設(shè)計一系列測試以暴露影響構(gòu)建正確地完成其功能的錯誤。其目的是為了發(fā)現(xiàn)極有可能造成項(xiàng)目延遲的“業(yè)務(wù)阻塞”錯誤。每天將該構(gòu)建與其他構(gòu)建及整個軟件產(chǎn)品（以其當(dāng)前的形式）集成起來進(jìn)行冒煙測試。這種集成方法可以是自頂向下，也可以自底向上。軟工概論：利用軟件測試的策略面向?qū)ο鬁y試通過評估分析和設(shè)計模型的正確性和一致性開始測試策略改變由于封裝，‘單元’的概念擴(kuò)展。封裝的類通常是單元測試的重點(diǎn)，類中包含的操作是最小的可測試單元。面向?qū)ο筌浖念悳y試等同于傳統(tǒng)軟件的單元測試。集成側(cè)重于類和它們跨線程的執(zhí)行或使用場景的環(huán)境確認(rèn)使用傳統(tǒng)的黑盒方法測試用例的設(shè)計借鑒了傳統(tǒng)方法，但是也包含了特殊的特征。軟工概論：利用軟件測試的策略擴(kuò)展“測試”的視野可以肯定，面向?qū)ο蠓治龊驮O(shè)計模型的評審非常有用，因?yàn)橄嗤恼Z義結(jié)構(gòu)（例如，類、屬性、操作、消息）出現(xiàn)在分析、設(shè)計和代碼層。因此，在分析期間所發(fā)現(xiàn)的類屬性的定義問題會防止副作用的發(fā)生，如果問題直到設(shè)計或編碼階段（或者是分析的下一輪迭代）還沒有發(fā)現(xiàn)，副作用就會發(fā)生。軟工概論：利用軟件測試的策略測試CRC模型檢查CRC模型和對象-關(guān)系模型。檢查每一張CRC索引片的描述以確定委托責(zé)任是定義協(xié)作者的一部分。反轉(zhuǎn)連接，確保每個提供服務(wù)的協(xié)作者都從合理的地方收到請求。使用步驟3中反轉(zhuǎn)后的結(jié)果，確定是否真正需要其他類，或者責(zé)任在類之間的組織是否合適。確定是否可以將廣泛請求的多個責(zé)任組合為一個責(zé)任。將步驟1到步驟5反復(fù)應(yīng)用到每個類及分析模型的每一次評估中。軟工概論：利用軟件測試的策略O(shè)O測試策略類測試相當(dāng)于單元測試測試類中的操作檢查類中的狀態(tài)行為集成測試應(yīng)用三種不同的策略基于線程的測試——對響應(yīng)系統(tǒng)的一個輸入或事件所需的一組類進(jìn)行集成基于使用的測試——對響應(yīng)系統(tǒng)的一個使用用例所需的一組類進(jìn)行集成簇測試——對演示一個協(xié)作所需的一組類進(jìn)行集成軟工概論：利用軟件測試的策略WebApp測試-I對WebApp的內(nèi)容模型進(jìn)行評審，以發(fā)現(xiàn)錯誤。對接口模型進(jìn)行評審，保證適合所有的用例。對WebApp的設(shè)計模型進(jìn)行評審，以發(fā)現(xiàn)導(dǎo)航錯誤。測試用戶界面，發(fā)現(xiàn)表現(xiàn)機(jī)制和（或）導(dǎo)航機(jī)制中的錯誤。對每個功能構(gòu)件進(jìn)行單元測試。軟工概論：利用軟件測試的策略WebApp測試-II對貫穿體系結(jié)構(gòu)的導(dǎo)航進(jìn)行測試。在各種不同的環(huán)境配置下，實(shí)現(xiàn)WebApp，并測試WebApp對于每一種配置的兼容性。進(jìn)行安全性測試，試圖攻擊WebApp或其所處環(huán)境弱點(diǎn)。進(jìn)行性能測試。通過可監(jiān)控的最終用戶群對WebApp進(jìn)行測試。對他們與系統(tǒng)的交互結(jié)果進(jìn)行評估，包括內(nèi)容和導(dǎo)航錯誤、適用性、兼容性、WebApp的可靠性及性能。軟工概論：利用軟件測試的策略高階測試確認(rèn)測試關(guān)注點(diǎn)是軟件需求確認(rèn)測試也稱為合格性測試，是檢驗(yàn)所開發(fā)的軟件是否能按用戶提出的要求進(jìn)行。軟件確認(rèn)要通過一系列證明軟件功能和要求一致的黑盒測試來完成，傳統(tǒng)軟件、面向?qū)ο筌浖癢ebApp之間的差別已經(jīng)消失。系統(tǒng)測試關(guān)注點(diǎn)是系統(tǒng)集成由于軟件只是計算機(jī)系統(tǒng)中的一個組成部分，軟件開發(fā)完成之后，最終還要和系統(tǒng)中的硬件系統(tǒng)、某些支持軟件、數(shù)據(jù)信息等其他部分配套運(yùn)行。這些測試已經(jīng)超出軟件過程范圍，而且不僅僅由軟件工程師執(zhí)行。α/β測試關(guān)注點(diǎn)是客戶使用α測試是由有代表性的最終用戶在開發(fā)者的現(xiàn)場進(jìn)行的，開發(fā)者在后面觀看，并記錄錯誤和使用問題。β測試是在一個或者多個最終用戶場所進(jìn)行。開發(fā)者通常不在場。軟工概論：利用軟件測試的策略軟工概論：利用軟件測試的策略43高階測試恢復(fù)測試通過各種方式強(qiáng)制地使軟件發(fā)生故障，并驗(yàn)證其能適當(dāng)恢復(fù)。安全測試驗(yàn)證建立在系統(tǒng)內(nèi)的保護(hù)機(jī)制是否能夠?qū)嶋H保護(hù)系統(tǒng)不受非法入侵。壓力測試

以非正常的數(shù)量、頻率或容量的方式執(zhí)行系統(tǒng)。測試是想要破壞程序。舉例：

—

如果正常的中斷頻率為每秒5次，強(qiáng)度測試設(shè)計為每秒50次中斷。

—

把輸入數(shù)據(jù)的量提高一個數(shù)量級來測試輸入功能會如何響應(yīng)。

—

若某系統(tǒng)正常運(yùn)行可支持200個終端并行工作，強(qiáng)度測試則檢驗(yàn)1000個終端并行工作的情況。軟工概論：利用軟件測試的策略44高階測試性能測試用來測試軟件在集成環(huán)境中的運(yùn)行性能，特別是針對實(shí)時系統(tǒng)和嵌入式系統(tǒng)，僅提供符合功能需求但不符合性能需求的軟件是不能被接受的。性能測試可以在測試過程的任意階段進(jìn)行，但只有當(dāng)整個系統(tǒng)的所有成分都集成在一起后，才能檢查一個系統(tǒng)的真正性能。性能測試常常和強(qiáng)度（壓力）測試結(jié)合起來進(jìn)行，而且常常需要硬件和軟件測試設(shè)備，這就是說，常常有必要在一種苛刻的環(huán)境中衡量資源的使用（比如，處理器周期）。調(diào)試：一個診斷過程調(diào)試出現(xiàn)在成功的測試之后。也就是說，當(dāng)測試用例發(fā)現(xiàn)錯誤時，調(diào)試是使錯誤消除的過程。調(diào)試就是查找問題癥狀與其產(chǎn)生原因之間的聯(lián)系尚未得到很好理解的智力過程軟工概論：利用軟件測試的策略調(diào)試過程回歸測試測試用例附加測試修正識別的原因調(diào)試推測的原因結(jié)果軟工概論：利用軟件測試的策略調(diào)試結(jié)果診斷癥狀并確定原因所需的時間修正錯誤并執(zhí)行回歸測試所需的時間timerequiredtodiagnosethesymptomanddeterminethecausetimerequiredtocorrecttheerrorandconductregressiontests軟工概論：利用軟件測試的策略癥狀和原因癥狀原因癥狀與原因出現(xiàn)的地方可能相隔很遠(yuǎn)癥狀可能在另一個錯誤被改正時消失實(shí)際上可能是由非錯誤因素引起的可能是由系統(tǒng)或編譯錯誤引起的可能是人們堅信的假定引起的癥狀可能是間斷的symptomcausesympt