我們?nèi)绾握_使用Use Case查坪?

????Use case, 作為UML重要的組成部分和類圖,時序圖宁炫,狀態(tài)圖偿曙,活動圖等一同經(jīng)常出現(xiàn)在各類產(chǎn)品設(shè)計和開發(fā)文檔中,但Use case圖卻在實際運用UML圖例化表達中羔巢,顯得比較尷尬望忆。不知你有沒有這種感覺,我們的設(shè)計文檔對于Use case的要求往往只是形式化存在竿秆,不是寥寥草草畫幾個收場启摄,就是根本不畫。那Use case 真的就無用了嗎幽钢?

哪些人會用Use case歉备?

????和Use case相比,產(chǎn)品經(jīng)理更喜歡用界面原型來表達用戶和產(chǎn)品的交互匪燕,也難怪蕾羊,想想最早的Use case概念是:Ivar Jacobson在1967年定義愛立信AXE系統(tǒng)的構(gòu)架時開始提出的喧笔,畢竟那時的人機交互還是非常生澀難懂的,時隔半個世紀了龟再,現(xiàn)在的設(shè)計理念更提倡簡單溃斋,直觀,所見即所得的模式吸申。

架構(gòu)師和開發(fā)工程師會喜歡用Use case嗎梗劫?答案是:不,他們更喜歡用序列圖截碴,活動圖梳侨,狀態(tài)圖等更細節(jié)和系統(tǒng)化,參數(shù)化的設(shè)計方式日丹,來表達系統(tǒng)狀態(tài)走哺,數(shù)據(jù)變遷和行為,而用類圖表達信息的靜態(tài)結(jié)構(gòu)哲虾。

測試工程師會用嗎丙躏?也不會,她們直接根據(jù)功能設(shè)計和界面原型編寫測試用例束凑,測試用例(Test case)不同于Use case晒旅,測試用例更加系統(tǒng)化,更強調(diào)嚴謹?shù)妮斎胪羲撸敵龆x废恋。

那誰會用Use case呢? 呵呵扒寄,經(jīng)過上面的分析鱼鼓,你肯定覺得Use case就是雞肋啊,完全可以廢棄掉了该编。你先別忙迄本,我還沒有講完,這并不是上面這些角色的錯课竣,也不是Use case完全無用嘉赎,只是我們經(jīng)常把Use case用錯了地方,其實Use case是業(yè)務分析過程而不是設(shè)計過程稠氮,準確來說Use case是銜接業(yè)務分析和系統(tǒng)設(shè)計的承上啟下的過程曹阔。

那Use case 到底有什么用半开?

????在軟件工程中我們通常把軟件的研發(fā)過程大體分為:分析隔披,設(shè)計,開發(fā)和測試四個階段寂拆,而在目前以電商經(jīng)濟作為主導的互聯(lián)網(wǎng)產(chǎn)品研發(fā)體系中奢米,對于軟件的分析過程我們的確很容易忽略抓韩,這里不是說電商系統(tǒng)不用分析,而是由于這個行業(yè)同質(zhì)化的產(chǎn)品太多鬓长,借鑒和抄襲的效率更高谒拴,那誰還愿意認真分析業(yè)務本質(zhì)呢?

Use case被忽略的另一個原因是對敏捷開發(fā)的一些誤解涉波,敏捷開發(fā)提倡的是快速交付英上,用客戶檢驗設(shè)計優(yōu)劣,用市場檢驗產(chǎn)品成敗啤覆。這就容易讓我們誤解為軟件或者所服務行業(yè)的業(yè)務分析就不需要了苍日,其實分析-設(shè)計-開發(fā)-測試的過程就像語言中的主謂賓結(jié)構(gòu)一樣,無論你用什么樣的語速或者花哨的修辭手法窗声,基本結(jié)構(gòu)是不會變的相恃。

敏捷的研發(fā)體系其實是一改過去傳統(tǒng)的整體系統(tǒng)全部分析完成結(jié)束后,再進入設(shè)計和開發(fā)階段的方式為:單一業(yè)務過程場景分析到設(shè)計到開發(fā)到測試的方式笨觅。而至于單一業(yè)務過程場景的劃分粒度拦耐,可以參考我之前的文章:《初建電商優(yōu)先關(guān)注的7個流程(一)》赡矢。

如果大家認同以上觀點稚字,我們繼續(xù)聊聊Use case到底有什么用和怎么用英岭?本文并不是講解如何繪制UML的Use case圖腔长,因為網(wǎng)絡(luò)上有太多這方面免費的介紹画饥,你連書都可以不用買横侦,就能理解牵寺。我們重點聊的是怎么使用Use case才能讓它的功能發(fā)揮出來堂污。

前面我講到Use case是銜接業(yè)務分析和系統(tǒng)設(shè)計的承上啟下的過程柒啤,目前在軟件工程中對Use case常用的定義是:Use case是一種在開發(fā)新系統(tǒng)或者軟件改造時捕獲潛在需求的技術(shù)倦挂。其實仔細理解定義,你就能明白“捕獲潛在需求”其實就是一種系統(tǒng)的分析過程担巩。Use case最適合使用在對抽象業(yè)務過程活動開展進一步分解的過程方援。

下來我們將通過Use case和業(yè)務過程(Business process),界面原型和系統(tǒng)設(shè)計的相關(guān)關(guān)系討論來認清Use case定位和作用涛癌。

一. Use case和業(yè)務過程分析的關(guān)系:

????要講Use case就首先要講講什么是業(yè)務過程(Business process)犯戏,因為他們是相輔相成的,Business process?在維基百科中的定義中是:一組相關(guān)的拳话、結(jié)構(gòu)化的活動或任務先匪,它們?yōu)樘囟ǖ目蛻艋蚩蛻羧后w,提供特定的服務或產(chǎn)品(為特定的目標服務)弃衍。這里用Business process而不是用Business Flowing呀非,是想和workFlow 區(qū)分開,WorkFlow是更系統(tǒng)化,更嚴謹岸裙,更技術(shù)化的活動描述猖败。而Business process則和系統(tǒng)和技術(shù)無關(guān),有些時候純粹描述人工業(yè)務過程降允,這是真正描述業(yè)務需求的一種方式恩闻。而業(yè)務過程分析和Use case分析各有側(cè)重點,業(yè)務過程是采用流程化的方式表達業(yè)務發(fā)展的連續(xù)性和方向性剧董;而Use case則重點對單個業(yè)務活動幢尚,開展面向?qū)ο蟮慕鈽?gòu)分析。

例如:我在《初建電商優(yōu)先關(guān)注的7個流程(一)》中說到的:?Request-to-answer(請求到響應)過程中所繪制的:

Request-to-answer

Request-to-answer過程是一種業(yè)務過程翅楼,他是企業(yè)運營體系中若干業(yè)務過程中的一種侠草,因為他滿足了從客戶發(fā)起到滿足客戶為終止end2end的原則,所以我們可以可以單獨分析該過程犁嗅,這也符合敏捷理論的快速響應边涕,閉環(huán)分析,最小價值開發(fā)理念褂微。

Use case的作用是以人機交互和用戶為中心的方式通過分析業(yè)務過程中的這些業(yè)務活動實體場景(比如:上圖中的咨詢功蜓,判斷銷售前景,匹配產(chǎn)品宠蚂,提供銷售建議書等)式撼,獲取該活動詳細的功能性需求。對求厕,Use case是形成功能性需求的關(guān)鍵著隆,所以是需求分析/系統(tǒng)分析工具,所以如果你已經(jīng)先有了系統(tǒng)功能呀癣,再做Use case 分析你就會發(fā)現(xiàn)Use case完全是多余的美浦,這里再次重申Use case不是設(shè)計工具,而是業(yè)務分析工具项栏。

為了證明此觀點我們可以看看浦辨,UML 圖例的主要結(jié)構(gòu):

Use case主要結(jié)構(gòu)

從上圖中我們可以看到Use case 是由Actor,case沼沈,relation流酬,system/module構(gòu)成,而這中間的關(guān)系又主要分為:包含列另,泛化芽腾,使用,擴展页衙。怎么樣摊滔?看到這些圖例是不是覺得:這不就是用面向?qū)ο蟮南到y(tǒng)思維方式來分析和解釋業(yè)務活動嘛!對,當我們在處理陌生需求或者業(yè)務活動時惭载,要將純粹的業(yè)務需求和過程轉(zhuǎn)化為面向?qū)ο笏季S的系統(tǒng)需求旱函,就需要作Use case分析响巢。這時是沒有具體功能描滔,沒有類模型,沒有數(shù)據(jù)模型踪古,最多只有大致的系統(tǒng)或者模塊含长。

二.?Use case和界面原型的關(guān)系

????在做Use case分析的時候,也許你已經(jīng)有界面原型(因為當下的設(shè)計潮流是提倡界面原型和需求分析同步的伏穆,界面原型同時也是客戶需求確認的工具)拘泞,但你絕對不要在Use case中去表現(xiàn)界面需求或者用界面需求反推導出Use case,因為Use case的分析重點是分析業(yè)務過程的發(fā)生的本質(zhì)(采用5W1H分析)枕扫,有些可能有界面陪腌,有些則可能沒有,有些是抽象實體烟瞧,有些是實例實體诗鸭。而界面原型的重點是用顯性,可視化的表達手段参滴,把業(yè)務過程分析的結(jié)果表現(xiàn)出來强岸。?

例如上圖中的:用戶登錄,泛化出了昵稱登錄和手機號登錄兩個case(實體)砾赔,而在界面設(shè)計中也許是一個界面(通用登錄界面)蝌箍,也許是兩個界面(交互設(shè)計師會有一大堆理由告訴你那種設(shè)計更好,但一般沒有一種是按照用戶業(yè)務可能性驅(qū)動分析的暴心,因為交互設(shè)計師不喜歡研究業(yè)務過程妓盲,哈哈!交互設(shè)計師不要打我哈Wㄆ铡)本橙。如果我們用界面設(shè)計來反推導Use case,就非常容易限制我們業(yè)務發(fā)展的可能性脆诉,上面的例子中甚亭,按照業(yè)務過程的抽象和泛化的分析結(jié)果,你完全還可以得出用掃碼登錄方式的case击胜。所以Use case和界面原型是相互驗證的關(guān)系亏狰,而不是相互替換。而Use case的另外一個作用就是分析業(yè)務可能性偶摔。

三. Use case和系統(tǒng)設(shè)計的關(guān)系

????這里講的系統(tǒng)設(shè)計涵蓋了UML常見過程如:模塊設(shè)計暇唾,類設(shè)計,時序設(shè)計,系統(tǒng)活動設(shè)計策州,以及領(lǐng)域驅(qū)動設(shè)計中的信息模型設(shè)計瘸味。Use case 分析除了能產(chǎn)生功能型需求和提供業(yè)務可能性分析外,它還能為后續(xù)的系統(tǒng)設(shè)計提供了結(jié)構(gòu)化設(shè)計和行為設(shè)計的一手素材够挂,因為整個分析過程采用了系統(tǒng)化的面向?qū)ο蟮姆治龇椒ā?/p>

所以說Use case提供了用系統(tǒng)化語言翻譯客戶需求的能力旁仿,編寫或者繪制Use case的人一定是業(yè)務分析能力和系統(tǒng)思維能力的結(jié)合體。Use case是銜接業(yè)務過程分析和系統(tǒng)設(shè)計的關(guān)鍵環(huán)節(jié)孽糖,Use case的好壞直接關(guān)系業(yè)務的可能性枯冈,是否能在系統(tǒng)功能上體現(xiàn)。

要作好Use case就要求產(chǎn)品經(jīng)理要有足夠的系統(tǒng)化思維办悟,架構(gòu)師要有足夠的業(yè)務過程分析思維尘奏,但這卻是目前互聯(lián)網(wǎng)研發(fā)體系中比較弱的一環(huán)。在有些大型IT企業(yè)中病蛉,其實還有一類介于產(chǎn)品經(jīng)理和架構(gòu)師的角色:系統(tǒng)分析師或者業(yè)務架構(gòu)師炫加,只是因為由于目前產(chǎn)品經(jīng)理角色在行業(yè)內(nèi)興起,大有逐漸代替了他們的趨勢铺然,但他們的實際工作內(nèi)容卻容易被遺忘俗孝,所以如果你的企業(yè)看中業(yè)務分析的能力,要不就要求產(chǎn)品經(jīng)理具備有系統(tǒng)化分析思維探熔,架構(gòu)師具備業(yè)務過程分析思維驹针,要不就請設(shè)置系統(tǒng)分析師和業(yè)務架構(gòu)師的角色,只有這樣才能真正將行業(yè)內(nèi)的業(yè)務需求挖掘诀艰,轉(zhuǎn)換和擴展延伸為優(yōu)質(zhì)的產(chǎn)品柬甥。

到底我們該怎么做Use case呢?

????確定Use case 的分析粒度其垄,其實是整個分析過程中最麻煩的部分苛蒲,也是最容易被大家忽略的地方,被忽略的結(jié)果就是我們選擇的Use case既沒有代表性绿满,也沒有承接性(承接業(yè)務過程分析)臂外,更沒有全面性,而一旦Use case沒有辦法提供詳細喇颁,完整的功能性需求和系統(tǒng)設(shè)計需要的結(jié)構(gòu)和行為分析漏健,Use case就變成了一份如同雞肋般的形式化文檔。

一. 首先橘霎,需要確定Use case 表達的粒度:

Use case 是銜接業(yè)務分析和系統(tǒng)設(shè)計的承上啟下的過程蔫浆,所以它一定不是靠經(jīng)驗,孤立設(shè)置或者直接拍腦袋定義出來的姐叁,它必須遵循業(yè)務分析的延續(xù)性瓦盛,從業(yè)務過程分析到Use case的分析就是這是這種延續(xù)性洗显,而Use case的粒度定義可以設(shè)置在業(yè)務過程中的業(yè)務活動上。注意:設(shè)定Use case的基點就必須是業(yè)務過程中的活動而非界面結(jié)構(gòu)原环。


Order-to-confirmation(訂購到確認)

《初建電商優(yōu)先關(guān)注的7個流程(一)》的Order-to-confirmation(訂購到確認)為例挠唆,我們要建立Use case的分析粒度要從業(yè)務過程中的業(yè)務活動開始,也就是說我們需要對:發(fā)布訂單嘱吗,費用計算玄组,拆解訂單,交付產(chǎn)品柜与,評估和跟蹤巧勤,確認完成等這些活動嵌灰,分別建立Use case描述弄匕。

這邊特別要指明,Order-to-confirmation(訂購到確認)只是抽象業(yè)務過程沽瞭,由于行業(yè)的差異性和復雜程度不同迁匠,一個業(yè)務活動可能會繼續(xù)拆解成更多業(yè)務活動,比如:“拆解訂單”驹溃,就會分為“分解產(chǎn)品訂單城丧,分解服務訂單和分解資源訂單”等三個。請注意這里的業(yè)務活動不是指系統(tǒng)的具體操作步驟豌鹤,所以千萬不要把業(yè)務活動的最后分解為:增加亡哄,刪除,修改布疙,插入蚊惯,查詢等這些具體系統(tǒng)操作上,因為這些操作是建立在系統(tǒng)實現(xiàn)上的灵临,而非業(yè)務分析的基礎(chǔ)上截型。

把Use case建立在業(yè)務活動上的原因也正是看重業(yè)務活動無系統(tǒng)限制,無技術(shù)約束儒溉。業(yè)務活動一定是展現(xiàn)一種業(yè)務發(fā)展的可能性宦焦,而不是具體系統(tǒng)實現(xiàn),Use case的粒度也是如此顿涣。

二. 其次波闹,有了Use case 的粒度,我們怎么來生成Use case呢涛碑?我介紹一個生成Use case的方法精堕。

? ? 我們要為每個Use case提供一個腳本描述,描述要簡潔意駭锌唾,而且基本語句結(jié)構(gòu)要符合語句為:時間锄码,地點夺英,誰,做了什么滋捶,怎么做痛悯,為什么做的5W1H模式,而最終影響Use case 的變量需要系統(tǒng)分析師重窟、業(yè)務架構(gòu)師或者產(chǎn)品經(jīng)理根據(jù)業(yè)務特征決定载萌。

我們以O(shè)rder-to-confirmation(訂購到確認)中的“發(fā)布訂單”的業(yè)務活動為例,建立了如下Use case分析模型如下:

Use case分析模型

????這是一個最簡單也最有效的Use case生成工具巡扇,首先扭仁,由業(yè)務架構(gòu)師定義和選擇,可以影響該業(yè)務活動的業(yè)務可能性的維度厅翔,你可以參考5W1H方式乖坠,圖中所提到的“時間區(qū)間”,“客戶類型”刀闷,“渠道類型”熊泵,“訂購方式”,“產(chǎn)品類型”和“觸發(fā)條件”甸昏,只是我舉例的維度顽分,你可以根據(jù)自己行業(yè)的業(yè)務特征,定義自己的維度施蜜。定義維度的要點是尋找Case的差異性卒蘸,如果無差異維度,可以直接丟棄掉翻默,如:上午和下午對于發(fā)布訂單的活動并無差異性缸沃,就忽略掉。其次冰蘑,需要填充相關(guān)維度參數(shù)和泌,也許是某種類型或者具體的實例。最后將這些維度參數(shù)做笛卡爾積運算祠肥,就能得出最直接的Case武氓。

我們大多生成Use case的時候,都缺少方法仇箱,用經(jīng)驗也罷县恕,看界面原型也罷,以至于拍腦袋等方式都很難保證不遺漏我們分析的業(yè)務可能性剂桥,所以我建議你采用以上方法試試忠烛。當然你看到有432條Case的時候肯定要瘋了,什么权逗,這么多美尸?其實這432條Case只是業(yè)務可能性的Case冤议,你可以根據(jù)自己行業(yè)的業(yè)務特征,用排除法很容易的就能排除掉不可能的师坎,無效的恕酸,無差異的Use case,實際使用的Case胯陋,就能控制在2位數(shù)以內(nèi)蕊温。

也許保留下來的就是:“晚上新客戶,接受了平臺推薦的商品遏乔,在線上自有渠道采用商品比較分析的方式訂購了家電產(chǎn)品” 等义矛,這就是Use case的腳本。而基于這個腳本你就可以接下來繪制Use case 圖例了盟萨,而從中分析出業(yè)務的功能性需求凉翻,結(jié)構(gòu)模型和行為模型的初稿和業(yè)務可能性。這里就不再講述Use case UML圖例繪制的過程鸯旁,您可以參考UML 的Use case文稿噪矛。

三. 最后量蕊,我要再澄清一個業(yè)界關(guān)于Use case的概念爭議

????對于Use case 業(yè)內(nèi)有兩種不同看法铺罢,一種認為Use case是抽象視圖,往往不用帶上具體的業(yè)務參數(shù)残炮。另外一種認為Use case就是實例韭赘,是被參數(shù)化的視圖。這兩種說法都各有道理势就,前提是有沒有把業(yè)務過程分析納入和Use case的關(guān)聯(lián)分析中泉瞻,我們知道業(yè)務過程分析本身就是一種抽象分析,業(yè)務過程本身也有抽象過程和實例化過程之分苞冯,抽象過程用于系統(tǒng)分析袖牙,實例化過程用于系統(tǒng)工作流設(shè)計,而Use case承接的抽象化過程舅锄,所以對抽象化的業(yè)務活動進行實例化分析就是有必要的鞭达。而這個實例化其實也不是最終的系統(tǒng)實例化,因為在Use case創(chuàng)建過程中需要選擇有差異化的Case皇忿,從而進行業(yè)務差異化分析畴蹭,所以我們可以認為Use case的case實例化是有限度的實例化。

最后總結(jié)一下:

????本文并沒有去重點闡述具體UML 的Use case繪制方法鳍烁,因為你去百度一下叨襟,既能得到很多相關(guān)方法,我把重點放到了Use case到底有用無用和Use case如何生成的討論上幔荒,我14年的系統(tǒng)設(shè)計糊闽,開發(fā)經(jīng)驗告訴我梳玫,很多的工具和方法如果不關(guān)聯(lián)使用,不去了解它存在的意義和實際業(yè)務目的右犹,那我們往往做出來的是形式化設(shè)計汽纠,對產(chǎn)品和系統(tǒng)不會有太多幫助。

Use case就有這樣的問題傀履,首先我們要搞清楚它是分析過程虱朵,不是設(shè)計過程,它是對業(yè)務過程分析到系統(tǒng)設(shè)計的承上啟下的過程钓账,如果不搞清楚這個問題碴犬,Use case可能對產(chǎn)品研發(fā)各角色來說都是雞肋。

其次梆暮,我們要知道Use case到底能為我們提供什么服协? 它可以幫助我們分析功能性需求業(yè)務可能性,這是我覺得最為重要的部分啦粹,也就是說如果我們已經(jīng)有了功能性需求或者限制了業(yè)務可能性的分析偿荷,那你再做Use case都會覺得完全是多余的。

再有唠椭,我強調(diào)了Use case的粒度選擇一定要放到業(yè)務過程分析中的業(yè)務活動中跳纳,這樣的分析過程才具備設(shè)計的連貫性和最小代價的完整性,這也符合敏捷設(shè)計的理念贪嫂。

最后寺庄,我提供一套生成Use case的方法,可以幫助你快速生成有限實例化的Case力崇,我們可以通過差異化的case分析斗塘,生成功能性需求和業(yè)務可能性,并且為后面的系統(tǒng)結(jié)構(gòu)化設(shè)計和行為設(shè)計提供必要的設(shè)計參考亮靴。

好了今天就到這里了馍盟,年前希望能再寫一篇文章,題目待定茧吊。祝:各位新春快樂贞岭!

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市饱狂,隨后出現(xiàn)的幾起案子曹步,更是在濱河造成了極大的恐慌,老刑警劉巖休讳,帶你破解...
    沈念sama閱讀 206,126評論 6 481
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件讲婚,死亡現(xiàn)場離奇詭異,居然都是意外死亡俊柔,警方通過查閱死者的電腦和手機筹麸,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,254評論 2 382
  • 文/潘曉璐 我一進店門活合,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人物赶,你說我怎么就攤上這事白指。” “怎么了酵紫?”我有些...
    開封第一講書人閱讀 152,445評論 0 341
  • 文/不壞的土叔 我叫張陵告嘲,是天一觀的道長。 經(jīng)常有香客問我奖地,道長橄唬,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 55,185評論 1 278
  • 正文 為了忘掉前任参歹,我火速辦了婚禮仰楚,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘犬庇。我一直安慰自己僧界,他們只是感情好,可當我...
    茶點故事閱讀 64,178評論 5 371
  • 文/花漫 我一把揭開白布臭挽。 她就那樣靜靜地躺著捂襟,像睡著了一般。 火紅的嫁衣襯著肌膚如雪埋哟。 梳的紋絲不亂的頭發(fā)上笆豁,一...
    開封第一講書人閱讀 48,970評論 1 284
  • 那天,我揣著相機與錄音赤赊,去河邊找鬼。 笑死煞赢,一個胖子當著我的面吹牛抛计,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播照筑,決...
    沈念sama閱讀 38,276評論 3 399
  • 文/蒼蘭香墨 我猛地睜開眼吹截,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了凝危?” 一聲冷哼從身側(cè)響起波俄,我...
    開封第一講書人閱讀 36,927評論 0 259
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎蛾默,沒想到半個月后懦铺,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 43,400評論 1 300
  • 正文 獨居荒郊野嶺守林人離奇死亡支鸡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 35,883評論 2 323
  • 正文 我和宋清朗相戀三年冬念,在試婚紗的時候發(fā)現(xiàn)自己被綠了趁窃。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 37,997評論 1 333
  • 序言:一個原本活蹦亂跳的男人離奇死亡急前,死狀恐怖醒陆,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情裆针,我是刑警寧澤刨摩,帶...
    沈念sama閱讀 33,646評論 4 322
  • 正文 年R本政府宣布,位于F島的核電站世吨,受9級特大地震影響码邻,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜另假,卻給世界環(huán)境...
    茶點故事閱讀 39,213評論 3 307
  • 文/蒙蒙 一像屋、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧边篮,春花似錦己莺、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,204評論 0 19
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至思杯,卻和暖如春胜蛉,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背色乾。 一陣腳步聲響...
    開封第一講書人閱讀 31,423評論 1 260
  • 我被黑心中介騙來泰國打工誊册, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人暖璧。 一個月前我還...
    沈念sama閱讀 45,423評論 2 352
  • 正文 我出身青樓案怯,卻偏偏與公主長得像,于是被迫代替她去往敵國和親澎办。 傳聞我的和親對象是個殘疾皇子嘲碱,可洞房花燭夜當晚...
    茶點故事閱讀 42,722評論 2 345

推薦閱讀更多精彩內(nèi)容