注：不含主觀題第1題軟件工程方法是（）。A為了獲得高質(zhì)量軟件而實(shí)施的一系列活動(dòng)B為開發(fā)軟件提供技術(shù)上的解決方法C為支持軟件開發(fā)、維護(hù)、管理而研制的計(jì)算機(jī)程序系統(tǒng)D為了理解問題和確定需求而采取的一些技術(shù)和方法第2題下面的（）是正確的。A運(yùn)行正確的軟件就是高質(zhì)量的軟件。B軟件質(zhì)量是在開發(fā)過程中逐漸構(gòu)建起來的。C軟件產(chǎn)品質(zhì)量越高越好，最理想的情況是達(dá)到“零缺陷”。D軟件質(zhì)量是由產(chǎn)品的功能、性能、易用性等外在特性決定的。第3題在Garvin多維度模型中，可靠性是指（）。A軟件產(chǎn)品提供了讓用戶產(chǎn)生驚喜的特性B軟件實(shí)現(xiàn)了用戶需要的功能和性能C軟件在規(guī)定時(shí)間和條件下無故障持續(xù)運(yùn)行D軟件符合國家或行業(yè)的相關(guān)標(biāo)準(zhǔn)第4題（）是軟件從一個(gè)硬件或軟件環(huán)境轉(zhuǎn)換到另一環(huán)境的容易程度。A易用性B可維護(hù)性C可移植性D性能第5題下面的（）說法是正確的。A由于軟件是產(chǎn)品，因此可以應(yīng)用其他工程制品所用的技術(shù)進(jìn)行生產(chǎn)B購買大多數(shù)計(jì)算機(jī)系統(tǒng)所需的硬件比軟件更昂貴C大多數(shù)軟件系統(tǒng)是不容易修改的，除非它們在設(shè)計(jì)時(shí)考慮了變化D一般來說，軟件只有在其行為與開發(fā)者的目標(biāo)一致的情況下才能成功第6題造成大型軟件開發(fā)困難的根本原因在于（）。A開發(fā)人員缺乏足夠的開發(fā)經(jīng)驗(yàn)B對軟件開發(fā)的資金投入不足C項(xiàng)目開發(fā)進(jìn)度不合理D軟件系統(tǒng)的復(fù)雜性第7題軟件會(huì)逐漸退化而不會(huì)磨損，其原因在于（）。A軟件通常暴露在惡劣的環(huán)境下B軟件錯(cuò)誤在經(jīng)常使用之后會(huì)逐漸增加C不斷的變更使組件接口之間引起錯(cuò)誤D軟件備件很難訂購第8題“軟件工程”術(shù)語是在（）被首次提出。AFredBrooks的《沒有銀彈：軟件工程中的根本和次要問題》B1968年NATO會(huì)議CIEEE的軟件工程知識體系指南（SWEBOK）D美國卡內(nèi)基·梅隆大學(xué)的軟件工程研究所第9題Ariane5火箭發(fā)射失敗的事例告訴我們（）。A系統(tǒng)環(huán)境的變化可能影響軟件采集數(shù)據(jù)的精度、范圍和對系統(tǒng)的控制B軟件后備系統(tǒng)可以通過復(fù)制生成C軟件重用必須重新進(jìn)行系統(tǒng)論證和系統(tǒng)測試D選項(xiàng)A和CE選項(xiàng)A、B和C第10題軟件工程的基本目標(biāo)是（）。A開發(fā)足夠好的軟件B消除軟件固有的復(fù)雜性C努力發(fā)揮開發(fā)人員的創(chuàng)造性潛能D更好地維護(hù)正在使用的軟件產(chǎn)品測驗(yàn)題--作業(yè)第1題下面的（）不是良好編碼的原則。A在開始編碼之前建立單元測試B建立一種有助于理解的直觀布局C確保注釋與代碼完全一致D保持變量名簡短以便代碼緊湊第2題下面的（）是錯(cuò)誤的。A在程序設(shè)計(jì)中使用括號以改善表達(dá)式的清晰性B不要修補(bǔ)不好的程序，要重新寫C在程序設(shè)計(jì)中應(yīng)盡可能對程序代碼進(jìn)行優(yōu)化D不要在注釋中重復(fù)描述代碼第3題為了保證軟件的質(zhì)量，使其具有較好的可維護(hù)性，關(guān)鍵在于（）。A選擇合適的程序設(shè)計(jì)語言B選擇好的程序設(shè)計(jì)風(fēng)格C具有好的數(shù)據(jù)結(jié)構(gòu)D選擇好的運(yùn)行環(huán)境第4題下面的（）是對提高程序編碼效率沒有影響的。A變量名的使用B選擇良好的設(shè)計(jì)方法C選擇良好的算法D選擇良好的數(shù)據(jù)結(jié)構(gòu)第5題下面的（）不是一種好的做法。A好的注釋應(yīng)解釋為什么，而不是怎么樣。B好的命名應(yīng)一目了然，不需要讀者去猜，甚至不需要注釋。C如果項(xiàng)目中原有代碼不符合新的規(guī)范，應(yīng)允許其存在，同時(shí)在新的代碼中要延續(xù)原有的風(fēng)格。D如果項(xiàng)目中原有代碼不符合新的規(guī)范，應(yīng)允許其存在，但不應(yīng)在新的代碼中延續(xù)舊的風(fēng)格。第6題下面的（）不是模塊化設(shè)計(jì)的目的。A降低程序設(shè)計(jì)的復(fù)雜性B清楚地描述系統(tǒng)的功能和性能C易于維護(hù)和功能擴(kuò)展D提高模塊的可靠性和復(fù)用性第7題下面的（）說法是錯(cuò)誤的。A代碼審查用于檢查源代碼是否達(dá)到模塊設(shè)計(jì)的要求B代碼在審查之前必須要成功地編譯通過C代碼審查比運(yùn)行程序進(jìn)行測試的效率低D代碼審查可以發(fā)現(xiàn)不符合團(tuán)隊(duì)代碼規(guī)范的地方第8題關(guān)于代碼性能優(yōu)化，下面（）是錯(cuò)誤的。A任何優(yōu)化都不能破壞代碼的正確性B應(yīng)以提高程序的全局效率為主，局部效率為輔C應(yīng)先通過測試找出限制效率的真正瓶頸D要優(yōu)先改進(jìn)耗時(shí)最多的部分第9題下面的Python語句中，（）是沒有錯(cuò)誤且寫得最規(guī)范的。Aimportos,sys,random,mathBn+=1;m+=n;print(m)Cclass=Class()Dreturn[i**2foriinrange(n)]第10題下面的（）語句風(fēng)格是最不利于維護(hù)的。Areturns['name']ifs['age']>=18elses['nickname']ifs['age']>14else'anonymous'Bmain(sys.argv[1:])Cfrommy_moduleimport(Class1,Class2,Class3,Class4)Da,b=b,a測驗(yàn)題--作業(yè)第1題在單元測試中，（）是用來代替被測模塊的子模塊的。A驅(qū)動(dòng)模塊B樁模塊C通訊模塊D代理模塊第2題在下面列舉的測試覆蓋中，（）是最強(qiáng)的邏輯覆蓋準(zhǔn)則。A語句覆蓋B條件覆蓋C判定覆蓋D條件組合覆蓋第3題一個(gè)判定中的復(fù)合條件表達(dá)式為（A>2）or（B≤1），為了達(dá)到100%條件覆蓋率，至少需要設(shè)計(jì)（）測試用例。A1B2C3D4第4題條件覆蓋要求（）。A每個(gè)判定中每個(gè)條件的所有取值至少滿足一次B每個(gè)判定至少取得一次“真”值和一次“假”值C每個(gè)判定中每個(gè)條件的所有可能取值組合至少滿足一次D每個(gè)可執(zhí)行語句至少執(zhí)行一次第5題（）要求每個(gè)判定中所有條件的可能取值至少執(zhí)行一次，而且每個(gè)判定的可能結(jié)果也至少執(zhí)行一次。A判定覆蓋B條件覆蓋C判定條件覆蓋D條件組合覆蓋第6題單元測試內(nèi)容不包括（）。A出錯(cuò)處理B全局?jǐn)?shù)據(jù)結(jié)構(gòu)C獨(dú)立路徑D模塊接口第7題下面的（）是錯(cuò)誤的。A靜態(tài)測試是不運(yùn)行被測程序，僅通過檢查和閱讀等手段來發(fā)現(xiàn)程序中的錯(cuò)誤B動(dòng)態(tài)測試是實(shí)際運(yùn)行被測程序，通過檢查運(yùn)行的結(jié)果來發(fā)現(xiàn)程序中的錯(cuò)誤C動(dòng)態(tài)測試可能是黑盒測試，也可能是白盒測試D白盒測試是靜態(tài)測試，黑盒測試是動(dòng)態(tài)測試第8題關(guān)于等價(jià)類劃分，下面的（）說法是正確的。A等價(jià)類劃分是將輸入域劃分成盡可能少的若干子域B同一輸入域的等價(jià)類劃分是唯一的C用同一等價(jià)類中的任意輸入對軟件進(jìn)行測試，軟件都輸出相同的結(jié)果D對于相同的等價(jià)類劃分，不同測試人員選取的測試用例集是一樣的第9題白盒測試是根據(jù)程序的（）來設(shè)計(jì)測試用例。A功能B性能C內(nèi)部邏輯D內(nèi)部數(shù)據(jù)第10題關(guān)于測試覆蓋率，下面的（）說法是錯(cuò)誤的。A測試覆蓋率是度量代碼質(zhì)量的一種手段B測試覆蓋率是度量測試完整性的一種手段C測試覆蓋率意味著有多少代碼經(jīng)過測試D不要盲目地追求100%測試覆蓋率測驗(yàn)題--作業(yè)第1題下面的（）決策是在需求分析時(shí)做出的。A自動(dòng)售票機(jī)系統(tǒng)的開發(fā)時(shí)間預(yù)計(jì)是6個(gè)月B自動(dòng)售票機(jī)系統(tǒng)由用戶界面子系統(tǒng)、價(jià)格計(jì)算子系統(tǒng)以及與中心計(jì)算機(jī)通信的網(wǎng)絡(luò)子系統(tǒng)組成C自動(dòng)售票機(jī)系統(tǒng)已經(jīng)達(dá)到交付的要求D自動(dòng)售票機(jī)系統(tǒng)將為使用者提供在線幫助第2題下面的（）決策是在系統(tǒng)設(shè)計(jì)時(shí)做出的。A自動(dòng)售票機(jī)系統(tǒng)的開發(fā)時(shí)間預(yù)計(jì)是6個(gè)月B自動(dòng)售票機(jī)系統(tǒng)由用戶界面子系統(tǒng)、價(jià)格計(jì)算子系統(tǒng)以及與中心計(jì)算機(jī)通信的網(wǎng)絡(luò)子系統(tǒng)組成C自動(dòng)售票機(jī)系統(tǒng)已經(jīng)達(dá)到交付的要求D自動(dòng)售票機(jī)系統(tǒng)將為使用者提供在線幫助第3題下面的（）是軟件構(gòu)造活動(dòng)的任務(wù)。A構(gòu)建軟件組件B設(shè)計(jì)用戶界面C實(shí)施組件的單元測試D評估組件的質(zhì)量E選項(xiàng)A和CF選項(xiàng)A、B、C和D正確答案：E第4題瀑布模型是（）。A適用于需求被清晰定義的情況B一種需要快速構(gòu)造可運(yùn)行程序的好方法C一種不適用于商業(yè)產(chǎn)品的創(chuàng)新模型D目前業(yè)界最流行的過程模型第5題增量模型是（）。A適用于需求被清晰定義的情況B一種需要快速構(gòu)造核心產(chǎn)品的好方法C一種不適用于商業(yè)產(chǎn)品的創(chuàng)新模型D已不能用于現(xiàn)代環(huán)境的過時(shí)模型第6題原型化模型是（）。A適用于客戶需求被明確定義的情況B適用于客戶需求難以清楚定義的情況C提供一個(gè)精確表述的形式化規(guī)格說明D很難產(chǎn)生有意義產(chǎn)品的一種冒險(xiǎn)模型第7題開發(fā)一個(gè)支持3D打印的操作系統(tǒng)最適合采用（）。A瀑布模型B原型化模型C增量開發(fā)D可轉(zhuǎn)換模型第8題開發(fā)一個(gè)鐵路信號控制系統(tǒng)最適合采用（）。A瀑布模型B原型化模型C增量開發(fā)D可轉(zhuǎn)換模型第9題下面的（）不是敏捷開發(fā)方法的特點(diǎn)。A軟件開發(fā)應(yīng)該遵循嚴(yán)格受控的過程和詳細(xì)的項(xiàng)目規(guī)劃B客戶應(yīng)該和開發(fā)團(tuán)隊(duì)在一起密切地工作C通過高度迭代和增量式的軟件開發(fā)過程響應(yīng)變化D通過頻繁地提供可以工作的軟件來搜集人們對產(chǎn)品的反饋第10題關(guān)于Scrum的每一次沖刺（Sprint），下面的（）是正確的。ASprint是一個(gè)不超過4周的迭代，其長度一旦確定，將保持不變。BSprint的產(chǎn)出是一個(gè)可用的、潛在可發(fā)布的產(chǎn)品增量。CSprint在進(jìn)行過程中，其開發(fā)目標(biāo)、質(zhì)量驗(yàn)收標(biāo)準(zhǔn)和團(tuán)隊(duì)組成不能發(fā)生變化。D以上所有選項(xiàng)測驗(yàn)題--作業(yè)第1題在軟件開發(fā)的各種資源中，（）是最重要的資源。A開發(fā)工具B方法C硬件環(huán)境D人員第2題在攻克技術(shù)難題時(shí)，最佳的開發(fā)團(tuán)隊(duì)組織模型是（）。A民主式結(jié)構(gòu)B主程序員式結(jié)構(gòu)C矩陣式結(jié)構(gòu)D以上所有選項(xiàng)都不是第3題在選擇開發(fā)團(tuán)隊(duì)組織結(jié)構(gòu)時(shí)應(yīng)考慮（）因素。A溝通的復(fù)雜程度B最終程序的規(guī)模大小C發(fā)布日期的嚴(yán)格程度D項(xiàng)目預(yù)算的多少E選項(xiàng)A，B和CF選項(xiàng)A，B和D正確答案：E第4題下面的（）很有可能會(huì)促進(jìn)高效項(xiàng)目團(tuán)隊(duì)的建設(shè)。A團(tuán)隊(duì)成員超過20人B團(tuán)隊(duì)成員部分時(shí)間參與項(xiàng)目C團(tuán)隊(duì)成員向多個(gè)經(jīng)理匯報(bào)D團(tuán)隊(duì)成員被指派到項(xiàng)目中E以上選項(xiàng)都不是正確答案：E第5題下面的（）溝通方式最利于協(xié)助解決復(fù)雜的問題。A口頭B書面C電子郵件D即時(shí)通訊工具第6題下面的（）方法最不適合你向團(tuán)隊(duì)成員解釋他或她為什么表現(xiàn)不合格。A個(gè)人談話B項(xiàng)目團(tuán)隊(duì)會(huì)議C正式報(bào)告D電子郵件第7題軟件開發(fā)團(tuán)隊(duì)的每一個(gè)成員都應(yīng)該參與計(jì)劃活動(dòng)，以便（）。A降低計(jì)劃的粒度B深入地分析需求C所有成員同意該計(jì)劃D開始設(shè)計(jì)第8題功能點(diǎn)估算技術(shù)需要以（）為基礎(chǔ)進(jìn)行問題分解。A信息域B項(xiàng)目進(jìn)度C軟件功能D過程活動(dòng)第9題某大型化工產(chǎn)品公司計(jì)劃開發(fā)一個(gè)新的計(jì)算機(jī)應(yīng)用，用以跟蹤原材料的使用情況。這個(gè)應(yīng)用由公司內(nèi)部組成的開發(fā)團(tuán)隊(duì)進(jìn)行開發(fā)，已有多年開發(fā)類似應(yīng)用的經(jīng)驗(yàn)。假設(shè)初始估計(jì)的程序規(guī)模是32000行源代碼，使用基本COCOMO模型進(jìn)行估算，開發(fā)工作量大約是（）人月。A32B91C230D146第10題經(jīng)驗(yàn)估算模型是基于（）。A專家基于過去項(xiàng)目經(jīng)驗(yàn)的判斷B期望值估計(jì)的細(xì)化C來自歷史項(xiàng)目數(shù)據(jù)的回歸模型D反復(fù)試驗(yàn)決定參數(shù)和系數(shù)測驗(yàn)題--作業(yè)第1題下面的（）是有效的軟件配置項(xiàng)。A軟件工具B文檔C可執(zhí)行程序D測試數(shù)據(jù)E以上所有選項(xiàng)正確答案：E第2題敏捷開發(fā)方法通過（）管理不可預(yù)測性。A非常仔細(xì)地收集和定義需求B制定詳細(xì)的開發(fā)計(jì)劃C軟件增量必須在較短周期內(nèi)發(fā)布D軟件過程必須逐漸適應(yīng)變化E選項(xiàng)A和BF選項(xiàng)C和D正確答案：F第3題關(guān)于Sprint，下面的（）是錯(cuò)誤的。A一個(gè)Sprint通常是一個(gè)1-4周的迭代BSprint長度在開發(fā)過程中是可以調(diào)整的C需求在一個(gè)Sprint中是不允許變化的DSprint的產(chǎn)出是“完成”的、可用的、潛在可發(fā)布的產(chǎn)品增量第4題在每日站立會(huì)議上，下面（）不是每個(gè)團(tuán)隊(duì)成員需要回答的主要問題。A從上次Scrum站立會(huì)議后你做了什么？B你遇到哪些障礙或困難？C你所遇到問題的原因是什么？D你打算到下次Scrum站立會(huì)議完成什么？第5題下面的（）不屬于產(chǎn)品負(fù)責(zé)人（ProductOwner）的職責(zé)范圍。A組織每日站立會(huì)議B定義產(chǎn)品需求C確定需求優(yōu)先級D驗(yàn)收迭代結(jié)果E負(fù)責(zé)產(chǎn)品的投資回報(bào)第6題在敏捷開發(fā)方法中，用戶故事（UserStory）的作用是（）。A定義需要發(fā)布給最終用戶的軟件特性和功能B確定發(fā)布每一次增量的日程表C用于代替詳細(xì)的活動(dòng)計(jì)劃D用于估算構(gòu)建當(dāng)前增量所需要的努力E選項(xiàng)A和CF選項(xiàng)A和D正確答案：F第7題下面的（）是正確的。A故事點(diǎn)是一個(gè)絕對度量單位B故事點(diǎn)估算一定要做到非常精確C故事點(diǎn)表示開發(fā)一個(gè)用戶故事或特性的復(fù)雜度D故事點(diǎn)表示開發(fā)一個(gè)用戶故事或特性所要付出的工作量第8題軟件配置管理的目的是（）。A降低開發(fā)成本B控制軟件修改C減少混亂D提高軟件開發(fā)效率E提高正確率作業(yè)題--作業(yè)第1題小圖所在的某校信息學(xué)院有一位程老師，他對生命游戲特別感興趣，正巧他看到小圖最近在研究生命游戲。程老師想了一些生命游戲的新規(guī)則，他想檢驗(yàn)一下那些規(guī)則是否有效，于是拍了拍小圖的肩膀，語重心長地說：“生命游戲能不能成為游戲界的主流，能不能在游戲史上留下濃墨重彩的一筆，就靠你們年輕人了！”然后程老師就把實(shí)現(xiàn)那些規(guī)則的任務(wù)交給小圖了。什么？程老師為什么不自己實(shí)現(xiàn)？程老師這么多年的編程經(jīng)驗(yàn)，什么樣的程序沒見過！這是給小圖一個(gè)掌握編程經(jīng)驗(yàn)的機(jī)會(huì)！小圖自己已經(jīng)編寫了一個(gè)有bug的生命游戲。目前的代碼中存在一些bug，想到這小圖就更慌了。幸好，小圖有個(gè)從小穿一條褲子長大的好朋友。相信屏幕前那閃耀著智慧光芒的你已經(jīng)猜到了，這位好朋友就是你！快來幫小圖這個(gè)忙吧！小圖想請你幫他一起去完成程老師提出的那些新規(guī)則。為了更好地進(jìn)行協(xié)作，你們決定用git版本庫來管理代碼。1.小圖首先在Github上創(chuàng)建了一個(gè)版本庫（/ThssSE/MOOC_LifeGame），然后馬上在本地通過gitclone將它克隆到了本地，這時(shí)gitstatus中會(huì)提示Onbranch（）。AdevBmasterCreleaseDbranch第2題小圖首先把他已經(jīng)編寫好的代碼文件全部放入了本地版本庫中，然后想通過gitcommit提交，但提示提交內(nèi)容為空，不允許提交，于是你通過（）幫他解決了這個(gè)問題。Agitcommit--amend，進(jìn)行修補(bǔ)提交Bgitcommit-a，提交所有改動(dòng)Cgitcommit--allow-empty，允許空提交Dgitstatus查看狀態(tài)，再執(zhí)行g(shù)itadd命令選擇要提交的文件，然后提交第3題提交后，你才發(fā)現(xiàn)不小心把一些臨時(shí)文件（*.xxx）也提交進(jìn)去了，以下最好的解決方式是（）。A編輯.gitignore文件，增加*.xxx條目，然后gitcommit-a把.gitignore提交到版本庫Bgitrm刪除*.xxx，然后gitcommit提交Cgitrm刪除*.xxx后再編輯.gitignore增加*.xxx條目，最后gitcommit--amend進(jìn)行修補(bǔ)提交D幸好還沒進(jìn)行g(shù)itpush，重新clone然后重新添加文件后提交即可第4題折騰了半天，終于把小圖的現(xiàn)有代碼完整、干凈地提交并push到了服務(wù)器上，你也本地clone了同一個(gè)版本庫。請將版本庫（/ThssSE/MOOC_LifeGame）clone到本地，可以看到有多個(gè)分支，請切換到git-demo分支，然后先把git-demo-1合并至git-demo分支，會(huì)發(fā)生（）。A合并成功，且不產(chǎn)生新的提交B合并成功，且產(chǎn)生一個(gè)自動(dòng)merge的新提交C合并失敗，因?yàn)槌霈F(xiàn)了沖突（Conflicts）D合并失敗，因?yàn)間it-demo分支是git-demo-1的子分支第5題接著，請繼續(xù)把git-demo-2分支合并至上述合并后的git-demo分支，會(huì)發(fā)生（）。A合并成功，且不產(chǎn)生新的提交B合并成功，且產(chǎn)生一個(gè)自動(dòng)merge的新提交C合并失敗，因?yàn)槌霈F(xiàn)了沖突（Conflicts）D合并失敗，因?yàn)間it-demo-2分支是git-demo-1的子分支第6題接下來你們將進(jìn)行開發(fā)工作，做了分工，每人實(shí)現(xiàn)幾個(gè)功能。你在本地新增了一個(gè)名為feature1的branch，關(guān)于這個(gè)branch，以下說法正確的是（）。A在本地新增feature1后，遠(yuǎn)端服務(wù)器的版本庫中也會(huì)自動(dòng)出現(xiàn)一個(gè)同名分支Bfeature1分支在本地被刪除后，遠(yuǎn)端服務(wù)器的版本庫中不會(huì)自動(dòng)刪除同名分支C可以指定將feature1分支提交到遠(yuǎn)端服務(wù)器的其他分支，但這會(huì)導(dǎo)致其他分支被覆蓋，因此一般不這么做D可以指定將feature1分支提交到遠(yuǎn)端服務(wù)器的另一分支branch2，提交后可以手動(dòng)再把branch2之前的最新提交merge到branch2去，因此不會(huì)丟失原branch2的提交第7題終于開始愉快地編程了，你們先進(jìn)行bug的修復(fù)工作。你在修復(fù)某個(gè)bug時(shí)，非但沒有完成修復(fù)，還導(dǎo)致了更嚴(yán)重的bug，這時(shí)你想把一個(gè)名為game的文件恢復(fù)至原始版本，只要執(zhí)行（）就可以了。Agitcheckout--resetgameBgitrm--revertgameCgitcheckoutHEAD--gameDgitignoregame第8題你又繼續(xù)了bug修復(fù)，這回成功完成了修復(fù)。又過了一會(huì)兒，你在修復(fù)另一個(gè)bug時(shí)又不小心改亂了想恢復(fù)，于是用gitreset--hard來把另一個(gè)文件恢復(fù)，但小手一抖不小心把已經(jīng)完成修復(fù)的game文件恢復(fù)了導(dǎo)致數(shù)據(jù)丟失。丟失了的數(shù)據(jù)還能找回嗎？（）A不能，硬重置使工作區(qū)文件被覆蓋，導(dǎo)致數(shù)據(jù)丟失無法找回B不能，因?yàn)樯形刺峤籆能，可以通過gitcheckoutHEAD@{1}--game找回D不確定，如果在重置前執(zhí)行了gitadd命令將game加入了暫存區(qū)，則可以在對象庫中處于懸空狀態(tài)的文件中找到第9題你對一些文件進(jìn)行了修改后，通過執(zhí)行（）就可以把當(dāng)前工作區(qū)的所有被修改的文件都添加到暫存區(qū)且不添加新增的文件。Agitadd.Bgitadd-ACgitadd-mDgitadd-u第10題你和小圖都進(jìn)行了一些開發(fā)工作，然后進(jìn)行合并時(shí)，提示了出現(xiàn)conflicts，該怎么處理呢？（）A這是因?yàn)槟愫托D同時(shí)push到服務(wù)器導(dǎo)致的，只要你們倆輪流push就不會(huì)有問題B這是因?yàn)楹喜r(shí)你們修改了不同的文件，導(dǎo)致無法合并，只要將被修改的文件在另一個(gè)待合并的分支也相應(yīng)修改就能解決C這是因?yàn)楹喜r(shí)你們修改了同一個(gè)文件，因此合并后只能保留其中一個(gè)分支的該文件，要順利解決可以先將文件備份，然后合并后再手動(dòng)將變動(dòng)同步過來D這是因?yàn)槟銈儗ν粋€(gè)文件的同一個(gè)位置進(jìn)行了不同的改動(dòng)，合并后會(huì)有特殊標(biāo)記標(biāo)明沖突的部分，進(jìn)行處理后再提交即可解決沖突第11題以下文件片段，表示該片段發(fā)生代碼沖突的是（）A<<<<<<<feature-2if__name__=='__main__':=======ifos.path.basename(__file__)=='main.py':>>>>>>>HEADB<<<<<<<HEADif__name__=='__main__':=======ifos.path.basename(__file__)=='main.py':>>>>>>>feature-2C=======HEADif__name__=='__main__':<<<<<<<ifos.path.basename(__file__)=='main.py':=======feature-2D=======feature-2if__name__=='__main__':>>>>>>>ifos.path.basename(__file__)=='main.py':=======HEAD測驗(yàn)題--作業(yè)第1題答題卡(綠色代表正確，紅色代表錯(cuò)誤，無色代表未答）第2題小圖所在的某校信息學(xué)院有一位程老師，他對生命游戲特別感興趣，正巧他看到小圖最近在研究生命游戲。程老師想了一些生命游戲的新規(guī)則，他想檢驗(yàn)一下那些規(guī)則是否有效，于是拍了拍小圖的肩膀，語重心長地說：“生命游戲能不能成為游戲界的主流，能不能在游戲史上留下濃墨重彩的一筆，就靠你們年輕人了！”然后程老師就把實(shí)現(xiàn)那些規(guī)則的任務(wù)交給小圖了。什么？程老師為什么不自己實(shí)現(xiàn)？程老師這么多年的編程經(jīng)驗(yàn)，什么樣的程序沒見過！這是給小圖一個(gè)掌握編程經(jīng)驗(yàn)的機(jī)會(huì)！小圖自己已經(jīng)編寫了一個(gè)有bug的生命游戲。目前的代碼中存在一些bug，想到這小圖就更慌了。幸好，小圖有個(gè)從小穿一條褲子長大的好朋友。相信屏幕前那閃耀著智慧光芒的你已經(jīng)猜到了，這位好朋友就是你！快來幫小圖這個(gè)忙吧！小圖想請你幫他一起去完成程老師提出的那些新規(guī)則。為了更好地進(jìn)行協(xié)作，你們決定用git版本庫來管理代碼。1.小圖首先在Github上創(chuàng)建了一個(gè)版本庫（/ThssSE/MOOC_LifeGame），然后馬上在本地通過gitclone將它克隆到了本地，這時(shí)gitstatus中會(huì)提示Onbranch（）。AdevBmasterCreleaseDbranch第3題小圖首先把他已經(jīng)編寫好的代碼文件全部放入了本地版本庫中，然后想通過gitcommit提交，但提示提交內(nèi)容為空，不允許提交，于是你通過（）幫他解決了這個(gè)問題。Agitcommit--amend，進(jìn)行修補(bǔ)提交Bgitcommit-a，提交所有改動(dòng)Cgitcommit--allow-empty，允許空提交Dgitstatus查看狀態(tài)，再執(zhí)行g(shù)itadd命令選擇要提交的文件，然后提交第4題提交后，你才發(fā)現(xiàn)不小心把一些臨時(shí)文件（*.xxx）也提交進(jìn)去了，以下最好的解決方式是（）。A編輯.gitignore文件，增加*.xxx條目，然后gitcommit-a把.gitignore提交到版本庫Bgitrm刪除*.xxx，然后gitcommit提交Cgitrm刪除*.xxx后再編輯.gitignore增加*.xxx條目，最后gitcommit--amend進(jìn)行修補(bǔ)提交D幸好還沒進(jìn)行g(shù)itpush，重新clone然后重新添加文件后提交即可第5題折騰了半天，終于把小圖的現(xiàn)有代碼完整、干凈地提交并push到了服務(wù)器上，你也本地clone了同一個(gè)版本庫。請將版本庫（/ThssSE/MOOC_LifeGame）clone到本地，可以看到有多個(gè)分支，請切換到git-demo分支，然后先把git-demo-1合并至git-demo分支，會(huì)發(fā)生（）。A合并成功，且不產(chǎn)生新的提交B合并成功，且產(chǎn)生一個(gè)自動(dòng)merge的新提交C合并失敗，因?yàn)槌霈F(xiàn)了沖突（Conflicts）D合并失敗，因?yàn)間it-demo分支是git-demo-1的子分支第6題接著，請繼續(xù)把git-demo-2分支合并至上述合并后的git-demo分支，會(huì)發(fā)生（）。A合并成功，且不產(chǎn)生新的提交B合并成功，且產(chǎn)生一個(gè)自動(dòng)merge的新提交C合并失敗，因?yàn)槌霈F(xiàn)了沖突（Conflicts）D合并失敗，因?yàn)間it-demo-2分支是git-demo-1的子分支第7題接下來你們將進(jìn)行開發(fā)工作，做了分工，每人實(shí)現(xiàn)幾個(gè)功能。你在本地新增了一個(gè)名為feature1的branch，關(guān)于這個(gè)branch，以下說法正確的是（）。A在本地新增feature1后，遠(yuǎn)端服務(wù)器的版本庫中也會(huì)自動(dòng)出現(xiàn)一個(gè)同名分支Bfeature1分支在本地被刪除后，遠(yuǎn)端服務(wù)器的版本庫中不會(huì)自動(dòng)刪除同名分支C可以指定將feature1分支提交到遠(yuǎn)端服務(wù)器的其他分支，但這會(huì)導(dǎo)致其他分支被覆蓋，因此一般不這么做D可以指定將feature1分支提交到遠(yuǎn)端服務(wù)器的另一分支branch2，提交后可以手動(dòng)再把branch2之前的最新提交merge到branch2去，因此不會(huì)丟失原branch2的提交第8題終于開始愉快地編程了，你們先進(jìn)行bug的修復(fù)工作。你在修復(fù)某個(gè)bug時(shí)，非但沒有完成修復(fù)，還導(dǎo)致了更嚴(yán)重的bug，這時(shí)你想把一個(gè)名為game的文件恢復(fù)至原始版本，只要執(zhí)行（）就可以了。Agitcheckout--resetgameBgitrm--revertgameCgitcheckoutHEAD--gameDgitignoregame第9題你又繼續(xù)了bug修復(fù)，這回成功完成了修復(fù)。又過了一會(huì)兒，你在修復(fù)另一個(gè)bug時(shí)又不小心改亂了想恢復(fù)，于是用gitreset--hard來把另一個(gè)文件恢復(fù)，但小手一抖不小心把已經(jīng)完成修復(fù)的game文件恢復(fù)了導(dǎo)致數(shù)據(jù)丟失。丟失了的數(shù)據(jù)還能找回嗎？（）A不能，硬重置使工作區(qū)文件被覆蓋，導(dǎo)致數(shù)據(jù)丟失無法找回B不能，因?yàn)樯形刺峤籆能，可以通過gitcheckoutHEAD@{1}--game找回D不確定，如果在重置前執(zhí)行了gitadd命令將game加入了暫存區(qū)，則可以在對象庫中處于懸空狀態(tài)的文件中找到第10題你對一些文件進(jìn)行了修改后，通過執(zhí)行（）就可以把當(dāng)前工作區(qū)的所有被修改的文件都添加到暫存區(qū)且不添加新增的文件。Agitadd.Bgitadd-ACgitadd-mDgitadd-u第11題你和小圖都進(jìn)行了一些開發(fā)工作，然后進(jìn)行合并時(shí)，提示了出現(xiàn)conflicts，該怎么處理呢？（）A這是因?yàn)槟愫托D同時(shí)push到服務(wù)器導(dǎo)致的，只要你們倆輪流push就不會(huì)有問題B這是因?yàn)楹喜r(shí)你們修改了不同的文件，導(dǎo)致無法合并，只要將被修改的文件在另一個(gè)待合并的分支也相應(yīng)修改就能解決C這是因?yàn)楹喜r(shí)你們修改了同一個(gè)文件，因此合并后只能保留其中一個(gè)分支的該文件，要順利解決可以先將文件備份，然后合并后再手動(dòng)將變動(dòng)同步過來D這是因?yàn)槟銈儗ν粋€(gè)文件的同一個(gè)位置進(jìn)行了不同的改動(dòng)，合并后會(huì)有特殊標(biāo)記標(biāo)明沖突的部分，進(jìn)行處理后再提交即可解決沖突測驗(yàn)題--作業(yè)第1題我們在為一家互聯(lián)網(wǎng)電商開發(fā)訂單處理軟件，該公司從供應(yīng)商那里購買產(chǎn)品，然后銷售給客戶。這家公司在線發(fā)布商品目錄，并將其推送給客戶和其他感興趣的人?？蛻粢蕴峤簧唐妨斜聿⑾螂娚谈顿M(fèi)的方式購買商品。電商填寫帳單，并委托快遞公司把商品運(yùn)送到客戶的地址。訂單處理軟件記錄從收到訂單直到商品被運(yùn)送給客戶的整個(gè)過程。電商將提供快捷的服務(wù)，以最快、最有效的方法來發(fā)送客戶訂購的產(chǎn)品?？蛻艨梢酝素?，但有時(shí)要付運(yùn)費(fèi)。（1）電商訂單處理軟件系統(tǒng)的參與者不包括：A網(wǎng)絡(luò)電商B客戶C其他感興趣的人D快遞公司第2題（2）在網(wǎng)絡(luò)電商客戶定單處理應(yīng)用中與客戶有關(guān)的用例不包括：A退貨B計(jì)算運(yùn)費(fèi)C瀏覽商品D訂單查詢第3題（3）進(jìn)入訂購商品用例的前置條件是：A客戶對商品感興趣B客戶安裝了與系統(tǒng)兼容的瀏覽器版本C商品已經(jīng)放入購物車D客戶通過合法賬戶登入系統(tǒng)第4題（4）取消訂單用例與查詢訂單用例建模為以下哪種關(guān)系最合適？A關(guān)聯(lián)關(guān)系B依賴關(guān)系C包含關(guān)系D擴(kuò)展關(guān)系第5題（5）使用訂單處理系統(tǒng)一段時(shí)間以后，電商希望增加一種功能——為老顧客提供折扣。以下哪種方法比較合適？A建立老顧客折扣新用例B擴(kuò)展訂購商品用例C在訂購商品用例中包含老顧客提供折扣用例D為訂購商品用例建立兩個(gè)子用例：普通顧客訂購商品和老顧客訂購商品第6題（6）需求說明文檔通常不會(huì)采用以下哪種方式組織撰寫？A用戶手冊B用戶故事C用例模型D測試用例第7題（7）以下哪個(gè)關(guān)于用例建模的說法是正確的？A用例可以定義系統(tǒng)功能性需求的優(yōu)先級B用例建模是對系統(tǒng)進(jìn)行功能分解的過程C用例能夠描述非功能性的需求D用例的參與者只能是系統(tǒng)用戶第8題（8）以下哪種關(guān)于用戶故事和用例描述的說法是不正確的？A用戶故事用于敏捷過程；用例描述用于統(tǒng)一建模過程B用戶故事作為開發(fā)者與用戶交互面對面交互時(shí)的提示；用例作為項(xiàng)目文檔保存C用戶故事可以用于估算；用例描述則不能用于估算D用戶故事采用自然語言文本描述；用例主要采用圖形化的模型表示第9題（9）可以選用以下哪種工具進(jìn)行用例建模？AMicrosoftProjectBEnterpriseArchitectCEnterpriseArchitectureDIBMRationalDOORS第10題（10）用例圖中，當(dāng)一個(gè)用例只在一定條件下比另一個(gè)用例增加少數(shù)步驟時(shí)，用哪種關(guān)系建模最合適？AextendsBincludesCusesDinherits第10章面向?qū)ο蠓治雠c設(shè)計(jì)--測驗(yàn)題第1題下列哪項(xiàng)關(guān)于面向?qū)ο蠓治鰜碓吹恼f法不正確？A面向?qū)ο蠓治龅乃悸凡糠衷从诿嫦驅(qū)ο蟮某绦蛟O(shè)計(jì)B面向?qū)ο蠓治龅乃悸凡糠衷从跀?shù)據(jù)庫領(lǐng)域的實(shí)體關(guān)系圖C面向?qū)ο蠓治龅乃悸凡糠謥碓从诿嫦驅(qū)ο笤O(shè)計(jì)D面向?qū)ο蠓治龅乃悸凡糠謥碓从谌斯ぶ悄茴I(lǐng)域的知識表示方法第2題下列哪項(xiàng)關(guān)于對象服務(wù)的說法是不正確的？A創(chuàng)建新對象、撤銷就對象，修改對象屬性等瞬時(shí)完成的服務(wù)B為其他對象完成各種計(jì)算服務(wù)C持續(xù)檢查預(yù)設(shè)條件是否滿足的監(jiān)控服務(wù)D對象只有屬性和行為，不對外提供服務(wù)第3題采用CRC卡片分揀法的分析過程不含以下哪個(gè)步驟？A建立系統(tǒng)的類設(shè)計(jì)模型B定義每個(gè)類的職責(zé)C確定類之間的交互關(guān)系D識別對象類第4題面向?qū)ο蠹夹g(shù)中，封裝的含義是A用狀態(tài)機(jī)圖來描述對象的行為B將對象的狀態(tài)鎖定，使之不能被修改C保證對象內(nèi)部的數(shù)據(jù)只能通過操作來訪問D將對象放入集合第5題面向?qū)ο笤O(shè)計(jì)中，“設(shè)計(jì)抽象的接口”的含義是？A向用戶暴露盡可能多的系統(tǒng)實(shí)現(xiàn)細(xì)節(jié)B向用戶暴露盡可能少的實(shí)現(xiàn)細(xì)節(jié)C不僅僅考慮用戶的業(yè)務(wù)需求，還要考慮設(shè)計(jì)約束D讓用戶決定接口的定義，減少開發(fā)人員的決策負(fù)擔(dān)第6題面向?qū)ο笤O(shè)計(jì)方法中，開閉原則的含義是？A軟件實(shí)體在更改性方面應(yīng)該是開放的，在擴(kuò)展性方面應(yīng)該是封閉的B要盡可能多地使用接口進(jìn)行封裝，利用多態(tài)技術(shù)，擴(kuò)展時(shí)不需修改源代碼C盡可能多定義類的繼承關(guān)系，運(yùn)用抽象機(jī)制D采用契約式設(shè)計(jì)第7題面向?qū)ο笤O(shè)計(jì)方法中，LSP替換原則要求“子類可以替換父類出現(xiàn)在父類能出現(xiàn)的任何地方”，下面正確的說法是？A將正方形定義為矩形的子類，符合LSP替換原則的要求B要盡可能多地使用接口進(jìn)行封裝，利用多態(tài)技術(shù)，擴(kuò)展時(shí)不需修改源代碼C子類中方法的前置和后置條件不能弱于父類中相應(yīng)方法的前置和后置條件D采用契約式設(shè)計(jì)第8題類定義不會(huì)要求其對象實(shí)例具有以下哪個(gè)特征？A相同狀態(tài)B相同屬性C相同行為D相同的對象關(guān)系第9題UML類圖中對以下幾種類型關(guān)系的使用頻度從高到低應(yīng)為？A實(shí)現(xiàn)>關(guān)聯(lián)>依賴>泛化>聚合>組合B泛化>聚合>組合>關(guān)聯(lián)>實(shí)現(xiàn)>依賴C關(guān)聯(lián)>泛化>聚合>組合>依賴>實(shí)現(xiàn)D依賴>泛化>聚合>組合>泛化>關(guān)聯(lián)第10題關(guān)于UML類圖中泛化關(guān)系建模，不正確的說法是？A定義泛化關(guān)系的好處是當(dāng)環(huán)境發(fā)生變化時(shí)，便于添加新的子類B當(dāng)某個(gè)類中，存在屬性和操作略有不同的子類時(shí)，應(yīng)定義泛化關(guān)系C當(dāng)現(xiàn)有的多個(gè)類具有公共屬性和方法時(shí)，可以定義一個(gè)父類讓它們共同繼承D關(guān)聯(lián)關(guān)系也可以用于定義分類關(guān)系，可以替代泛化關(guān)系測驗(yàn)題--作業(yè)第1題UML2.0中對行為建模的圖不包括：A對象圖B狀態(tài)圖C順序圖D時(shí)間圖第2題順序圖中帶條件消息的發(fā)送，不能采用以下哪種方式進(jìn)行？A用文字說明，作為注釋添加B添加條件控制框C分成多個(gè)順序圖子圖來描述D在消息名字前加條件子句第3題順序圖的組合控制框（Frame）中，用于表達(dá)分支選擇關(guān)系的控制符是哪個(gè)？AoptBaltCparDloop第4題當(dāng)一個(gè)順序圖過大時(shí)，最好的處理方法是？A添加注釋，說明順序圖的各部分之間的接續(xù)關(guān)系B用不完整的箭頭，指明本頁的順序圖未完待續(xù)C去掉無關(guān)的細(xì)節(jié)，保持圖的簡潔性D添加ref框，建立順序圖間的引用關(guān)系第5題對順序圖與用例之間關(guān)系的闡述，錯(cuò)誤的是：A順序圖表達(dá)單個(gè)情景實(shí)例的行為，每個(gè)用例對應(yīng)一個(gè)順序圖B用例分析階段的順序圖要包含設(shè)計(jì)對象，并關(guān)注消息參數(shù)C順序圖用于表示為完成用例而在系統(tǒng)邊界輸入輸出的數(shù)據(jù)以及消息D順序圖可幫助分析人員對用例圖進(jìn)行擴(kuò)展、細(xì)化和補(bǔ)遺第6題下面關(guān)于對象狀態(tài)建模的說法中，正確的是：A大部分對象的狀態(tài)空間都是有限的B對象狀態(tài)建模要窮舉對象能夠到達(dá)的所有狀態(tài)，保證完整性C大部分對象的狀態(tài)空間大小是由它的屬性取值決定的D對象的狀態(tài)數(shù)量是由它對外提供的操作的數(shù)量決定的第7題狀態(tài)遷移的發(fā)生不會(huì)受到哪個(gè)因素的影響？A目標(biāo)狀態(tài)B外部事件C警戒條件D遷移動(dòng)作第8題下面關(guān)于UML狀態(tài)圖的說法正確的是：AUML狀態(tài)圖中的狀態(tài)可以分解為“與”狀態(tài)，以及“或”狀態(tài)，但是都可以轉(zhuǎn)化為基本狀態(tài)機(jī)來表示BUML狀態(tài)圖中的狀態(tài)是原子的，不可再分CUML狀態(tài)圖中的狀態(tài)只可以分解為“與”狀態(tài)，表示可以兩種狀態(tài)并存DUML狀態(tài)圖中的狀態(tài)只可以分解為“或”狀態(tài)，表示只能選擇其中之一第9題關(guān)于狀態(tài)圖與其他UML圖的關(guān)系，說法不正確的是：A狀態(tài)圖中的事件為順序圖中該對象的輸入消息B狀態(tài)圖中每個(gè)動(dòng)作對應(yīng)于其他類的一個(gè)操作C狀態(tài)圖中的動(dòng)作定義等價(jià)于類圖中的操作定義D狀態(tài)圖應(yīng)針對類圖中所有的類進(jìn)行建模第10題以下狀態(tài)遷移上的警戒條件定義中，哪一組是最合適的？Ax大于0，x等于0，X小于0Bx大于等于0，x小于等于0Cx大于0，x小于0Dx大于0，x等于0測驗(yàn)題--作業(yè)第1題隨著軟件系統(tǒng)的規(guī)模和復(fù)雜性越來越大，（）變得更加重要。A算法的選擇B數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)C數(shù)據(jù)庫的構(gòu)造D系統(tǒng)的全局結(jié)構(gòu)設(shè)計(jì)第2題下面的說法（）是錯(cuò)誤的。A軟件體系結(jié)構(gòu)的最佳表示形式是一個(gè)可執(zhí)行的軟件原型B軟件體系結(jié)構(gòu)描述是不同項(xiàng)目相關(guān)人員之間進(jìn)行溝通的使能器C良好的分層體系結(jié)構(gòu)有利于系統(tǒng)的擴(kuò)展與維護(hù)D設(shè)計(jì)模式是從大量成功實(shí)踐中總結(jié)出來且被廣泛公認(rèn)的實(shí)踐和知識第3題良好設(shè)計(jì)的特征是（）。A模塊之間呈現(xiàn)高耦合B實(shí)現(xiàn)分析模型中的所有需求C包括所有組件的測試用例D提供軟件的完整描述E選項(xiàng)B和DF選項(xiàng)B、C和D正確答案：E第4題Word、Excel等應(yīng)用系統(tǒng)適合采用（）結(jié)構(gòu)風(fēng)格。A層次系統(tǒng)B事件系統(tǒng)C解釋器D管道-過濾器第5題與C/S架構(gòu)的信息系統(tǒng)相比，B/S架構(gòu)的信息系統(tǒng)的優(yōu)勢是（）。A具備更高的安全性B更容易部署和升級維護(hù)C具備更強(qiáng)的事務(wù)處理能力，易于實(shí)現(xiàn)復(fù)雜的業(yè)務(wù)流程D用戶界面友好，具有更快的響應(yīng)速度第6題對于觀察者模式，下面的（）說法是錯(cuò)誤的。A觀察者的更新是被動(dòng)的B被觀察者可以通知觀察者進(jìn)行更新C觀察者可以改變被觀察者的狀態(tài)，再由被觀察者通知所有觀察者D以上所有選項(xiàng)第7題設(shè)計(jì)目標(biāo)可分成性能、可靠性、成本、維護(hù)和最終用戶等類型，下面（）描述的是性能目標(biāo)。A當(dāng)用戶發(fā)出任何命令后，系統(tǒng)必須在1秒內(nèi)將信息反饋給用戶。B即使在網(wǎng)絡(luò)失敗的情況下，火車票發(fā)售系統(tǒng)也必須能夠成功地提交火車票。C火車票發(fā)售系統(tǒng)的機(jī)器外殼必須允許安裝新按鈕以便增加新的不同票價(jià)。D系統(tǒng)用戶界面應(yīng)該防止用戶以錯(cuò)誤的順序執(zhí)行命令。第8題下面的（）架構(gòu)可以更好地實(shí)現(xiàn)Web應(yīng)用的前后端分離。AMVCBRestfulAPICRPC第9題一個(gè)創(chuàng)業(yè)團(tuán)隊(duì)想要開發(fā)一款社交App，但是他們對于可能的發(fā)展的業(yè)務(wù)仍不十分明確，此時(shí)希望能夠開發(fā)一個(gè)相對簡單的版本進(jìn)行原始的需求驗(yàn)證與測試，這種情況比較適合選擇（）數(shù)據(jù)庫。AMysqlBMongoCRedis第10題如今社交文化橫行，大數(shù)據(jù)分析遍地，幾乎所有的應(yīng)用與產(chǎn)品都多少會(huì)與社交網(wǎng)絡(luò)或大用戶量、大數(shù)據(jù)相關(guān)聯(lián)。如果準(zhǔn)備開發(fā)一個(gè)較完整的社交網(wǎng)絡(luò)應(yīng)用，支持10萬以上日活躍用戶進(jìn)行各種點(diǎn)贊、評論等交互活動(dòng)，應(yīng)該采用（）數(shù)據(jù)庫或數(shù)據(jù)庫組合。AMysqlBMongoCMysql+RedisDMongo+Redis作業(yè)題--作業(yè)第1題style="color:blue">假設(shè)你所在的開發(fā)團(tuán)隊(duì)負(fù)責(zé)系統(tǒng)的升級改造，請結(jié)合以下描述回答問題：1.為了提升搶票性能，開發(fā)團(tuán)隊(duì)提出了下面的數(shù)據(jù)庫優(yōu)化方案，其中（）方案是不合理的。A對頻繁檢索的鍵增加適當(dāng)?shù)乃饕↖ndex）B對頻繁檢索的表移除外鍵（ForeignKey），改為通過代碼層面保證安全性C對于已結(jié)束一段時(shí)間的活動(dòng)，將票的信息歸檔后即可從數(shù)據(jù)庫中刪除相關(guān)數(shù)據(jù)項(xiàng)D將票的信息存儲(chǔ)于Redis等內(nèi)存型數(shù)據(jù)庫，而不再存儲(chǔ)于MySQL等關(guān)系型數(shù)據(jù)庫中第2題對于一些頻繁查詢且不易變動(dòng)的信息，可以通過Redis等內(nèi)存型數(shù)據(jù)庫進(jìn)行緩存，下面的（）信息不需要進(jìn)行緩存。A活動(dòng)詳情B近期活動(dòng)列表C剩余活動(dòng)票數(shù)D已搶到票的信息第3題當(dāng)Redis緩存的數(shù)據(jù)過期時(shí)，下面的（）更新方案是比較合理的。A清空Redis數(shù)據(jù)庫B刪除所有受影響的Redis數(shù)據(jù)C計(jì)算得到所有受影響數(shù)據(jù)的新數(shù)據(jù)，緩存至Redis替換已有數(shù)據(jù)D無需處理，當(dāng)緩存有效時(shí)間過期后自然會(huì)更新數(shù)據(jù)第4題開發(fā)團(tuán)隊(duì)決定對已有系統(tǒng)進(jìn)行重構(gòu)，即將后端改寫為RESTful，這樣做的好處是（）。A易于優(yōu)化數(shù)據(jù)庫訪問B減少前后端耦合，方便分離開發(fā)C易于維護(hù)與測試D易于開放第三方接口E選項(xiàng)B和DF選項(xiàng)B、C和DG選項(xiàng)A、B、C和D正確答案：F第5題原有系統(tǒng)只支持單人搶單張票，而且是自動(dòng)分配座位。新的升級系統(tǒng)希望允許用戶在一次活動(dòng)中可以搶不超過設(shè)定最大票數(shù)的任意張票，而且可以為每張票選擇座位。針對這個(gè)需求，下面的（）實(shí)現(xiàn)方式是比較合理的。A在搶票開始前，將所有票及其對應(yīng)座位在數(shù)據(jù)庫中生成好。用戶搶票時(shí)，根據(jù)其請求搶票的張數(shù)，分配電子票。B設(shè)計(jì)電子票的數(shù)據(jù)表和座位的數(shù)據(jù)表，用戶搶票時(shí)的邏輯與原有系統(tǒng)類似，只是增加對一次搶多張票的支持。搶票完成后用戶可以進(jìn)行選座，選座即將電子票與座位建立對應(yīng)關(guān)系。C以上方式均不合理第6題當(dāng)管理員創(chuàng)建一個(gè)活動(dòng)后，希望之前參加過同類活動(dòng)的用戶能收到該活動(dòng)的推送。當(dāng)用戶搶到票后，活動(dòng)開始當(dāng)天早9點(diǎn)和活動(dòng)開始前30分鐘，用戶都能收到一條推送消息提醒及時(shí)檢票入場。針對這個(gè)需求，下面的（）實(shí)現(xiàn)方式是不合理的。A使用Linuxcronjob，在每天早9點(diǎn)運(yùn)行腳本向所有搶到票的用戶推送提醒消息B使用異步隊(duì)列的定時(shí)任務(wù)，在每天早9點(diǎn)向所有搶到票的用戶推送提醒消息C使用異步隊(duì)列，在用戶搶到票后啟動(dòng)異步任務(wù)，阻塞至活動(dòng)開始前30分鐘向用戶推送提醒消息D使用異步隊(duì)列的定時(shí)任務(wù)，每隔1分鐘檢查是否需要向用戶推送活動(dòng)開始前30分鐘的提醒消息測驗(yàn)題--作業(yè)第1題輸出一列數(shù)值時(shí)，需要考慮對齊方法，你會(huì)選擇（）方法。A左對齊B右對齊C兩端對齊D小數(shù)點(diǎn)對齊第2題用KLM自己計(jì)算課件上的兩個(gè)溫度轉(zhuǎn)換器軟件界面的操作時(shí)間。后者交互效率高，（）原因更本質(zhì)。A沒有在兩種輸入設(shè)備間切換B界面沒有需要用戶額外表達(dá)的信息C用戶操作的更快DKLM的計(jì)算結(jié)果小第3題訪問http://fww.few.vu.nl/hci/interactive/fitts/并對其中實(shí)驗(yàn)5的結(jié)果進(jìn)行分析，下面的（）是正確的。A所采用的兩種輸入設(shè)備都是目標(biāo)越大訪問時(shí)間越長B在所采用的兩種輸入設(shè)備上，只有其中一個(gè)是目標(biāo)越大訪問時(shí)間越長C在所采用的兩種輸入設(shè)備上，實(shí)驗(yàn)時(shí)間均與Distance/Width呈正相關(guān)第4題訪問/columns/022DesignedToGiveFitts.html并為每個(gè)問題答案尋找實(shí)例界面，其中環(huán)形菜單的設(shè)計(jì)是（）。A不知如何啟動(dòng)，毫無意義B對美工的設(shè)計(jì)能力要求很高C到達(dá)每個(gè)菜單項(xiàng)時(shí)手的移動(dòng)距離短且一樣第5題閱讀下面給出的文獻(xiàn)“ABriefHistoryofHuman-ComputerInteractionTechnology”，其中第一個(gè)裝載GUI操作系統(tǒng)的計(jì)算機(jī)是（）。A蘋果公司的MacintoshB微軟公司的WindowsC施樂公司的AltoD施樂公司的StarE施樂公司的Lisa第6題閱讀文獻(xiàn)：BradA.Myers.ABriefHistoryofHuman-ComputerInteractionTechnology.ACMinteractions.Vol.5,no.2,March,1998.pp.44-542、思考一下，喬布斯為蘋果公司制定的手機(jī)上的黃金法則是什么？為什么？采用現(xiàn)狀及其原因？這里的黃金法則是指（）。A單手操作手機(jī)，屏幕尺寸3.5英寸B單手操作手機(jī)，屏幕尺寸4.7英寸C雙手操作手機(jī)，屏幕尺寸4.7英寸D雙手操作手機(jī)，屏幕尺寸4.0英寸第7題同學(xué)們上網(wǎng)用一下谷歌界面、雅虎界面和bing界面，都是檢索任務(wù)的軟件，差異在哪里？這幾款產(chǎn)品目前用戶量的差異很大程度上是界面在注意力設(shè)計(jì)上的差異，請進(jìn)行分析。其中，最能使用戶集中注意力的界面設(shè)計(jì)是（）。A谷歌B雅虎Cbing第8題視頻（電影、電視、動(dòng)畫、數(shù)字視頻，等）幀律的設(shè)置依據(jù)是（）。A根據(jù)機(jī)器的處理能力B根據(jù)個(gè)人偏好C根據(jù)人的視覺暫留時(shí)間第9題分析課件中數(shù)字軟鍵盤布局上的不一致現(xiàn)象，為什么在同一款手機(jī)上，不同應(yīng)用中的數(shù)字鍵盤的布局不一致？其中（）應(yīng)用中的數(shù)字軟鍵盤布局是一致的。A電話撥號和計(jì)算器B通訊錄和電話撥號C計(jì)算器和通訊錄第10題人們不會(huì)把[]()[]中的“](”認(rèn)作一對，原因是視覺認(rèn)知中的（）定律在起作用。A連續(xù)律B接近律C相似律D對稱律測驗(yàn)題--作業(yè)第1題軟件測試的目的是（）。A避免軟件中出現(xiàn)錯(cuò)誤B證明軟件的正確性C解決測試中發(fā)現(xiàn)的錯(cuò)誤D發(fā)現(xiàn)軟件中潛在的錯(cuò)誤第2題下面（）說法是錯(cuò)誤的。A測試應(yīng)該盡早不斷地執(zhí)行B軟件錯(cuò)誤具有聚集性，對存在錯(cuò)誤的部分應(yīng)重點(diǎn)測試C軟件測試是提高軟件質(zhì)量的決定性因素D測試用例需要定期評審和修改，并且要不斷增加新的測試用例第3題下面的（）不是集成測試的內(nèi)容。A對軟件中最小可測試單元進(jìn)行檢查和驗(yàn)證B把各個(gè)模塊連接在一起時(shí)，穿越模塊接口的數(shù)據(jù)是否會(huì)丟失C一個(gè)模塊的功能是否會(huì)對另一個(gè)模塊的功能產(chǎn)生不利的影響D若干子功能組合在一起是否能產(chǎn)生預(yù)期的主功能第4題下面的（）是錯(cuò)誤的。A功能測試是根據(jù)需求規(guī)格說明驗(yàn)證產(chǎn)品的功能實(shí)現(xiàn)是否符合要求B壓力測試是檢測在極限環(huán)境中使用系統(tǒng)時(shí)施加在用戶上的壓力C安全測試是檢測系統(tǒng)中的保護(hù)機(jī)制是否可以保護(hù)系統(tǒng)免受非正常的攻擊D安裝測試是保證應(yīng)用程序能夠被成功地安裝第5題（）是為了有效地發(fā)現(xiàn)軟件缺陷而精心設(shè)計(jì)的少量測試數(shù)據(jù)。A測試計(jì)劃B測試用例C缺陷報(bào)告D測試報(bào)告第6題錯(cuò)誤推測法是（）。A將輸入數(shù)據(jù)劃分成若干個(gè)等價(jià)類，從中選取有代表性的數(shù)據(jù)作為測試用例B將所有可能的輸入數(shù)據(jù)作為測試用例C運(yùn)用場景對系統(tǒng)的功能點(diǎn)或業(yè)務(wù)流程進(jìn)行描述，對應(yīng)不同的業(yè)務(wù)場景生成相應(yīng)的測試用例D根據(jù)經(jīng)驗(yàn)或直覺推測程序中可能發(fā)生錯(cuò)誤的情況，編寫檢查它們的測試用例第7題Web鏈接測試不包括（）。A客戶端與服務(wù)器端的連接速度B無鏈接指向的頁面C錯(cuò)誤的鏈接D不存在的頁面第8題（）是檢測Web應(yīng)用系統(tǒng)提供信息的正確性、準(zhǔn)確性和相關(guān)性。A表單測試B鏈接測試C內(nèi)容測試DCookies測試第9題下面的（）不是軟件性能的指標(biāo)。A響應(yīng)時(shí)間B并發(fā)進(jìn)程數(shù)C吞吐量D資源利用率第10題下面的（）不是性能測試的目的。A達(dá)到百分之百的語句覆蓋B驗(yàn)證軟件系統(tǒng)是否能夠滿足預(yù)期的性能要求C發(fā)現(xiàn)軟件系統(tǒng)中存在的性能瓶頸D評估軟件系統(tǒng)的穩(wěn)定性和可靠性測驗(yàn)題--作業(yè)第1題下面的（）是錯(cuò)誤的。A軟件交付的主要工作是將程序代碼和相關(guān)文檔交給用戶B用戶培訓(xùn)是幫助用戶理解產(chǎn)品并掌握系統(tǒng)的使用和操作C軟件部署是通過配置、安裝和激活等活動(dòng)保證軟件系統(tǒng)的正常運(yùn)行D持續(xù)集成是頻繁持續(xù)地將團(tuán)隊(duì)成員的工作進(jìn)行集成第2題下面的（）是正確的。A只有質(zhì)量差的軟件產(chǎn)品才需要維護(hù)B軟件的維護(hù)成本通常比開發(fā)成本低C軟件的不斷修改將導(dǎo)致系統(tǒng)結(jié)構(gòu)的惡化D重新開發(fā)一個(gè)新系統(tǒng)通常要比再工程的成本要低第3題（）是由于計(jì)算機(jī)軟件和硬件環(huán)境變化而修改軟件的過程。A改正性維護(hù)B適應(yīng)性維護(hù)C完善性維護(hù)D預(yù)防性維護(hù)第4題下面的（）不是軟件再工程活動(dòng)。A增加新的功能B逆向工程C程序結(jié)構(gòu)改善D數(shù)據(jù)再工程第5題逆向工程通常用在軟件生命周期的（）階段，它是從源代碼或目標(biāo)代碼中提取設(shè)計(jì)信息。A需求分析B軟件設(shè)計(jì)C軟件測試D軟件維護(hù)第一部分：基礎(chǔ)知識第1題在選擇軟件需求獲取技術(shù)時(shí)，下面的（）策略是最優(yōu)的。A考慮尚不了解的那部分需求的特點(diǎn)B考慮需求工程師本身對各種獲取技術(shù)的駕馭能力C考慮目前系統(tǒng)所屬的行業(yè)及應(yīng)用領(lǐng)域的現(xiàn)狀D綜合考慮上述因素第2題下面的（）需求獲取方法最適用于身處多個(gè)不同地點(diǎn)的人在各自方便的時(shí)間參與，圍繞同一個(gè)主題表達(dá)自己的觀點(diǎn)。A問卷調(diào)查B面談C群體誘導(dǎo)D文檔分析第3題我們在為一家互聯(lián)網(wǎng)電商開發(fā)訂單處理軟件，該公司從供應(yīng)商那里購買產(chǎn)品，然后銷售給客戶。這家公司在線發(fā)布商品目錄，并將其推送給客戶和其他感興趣的人?？蛻粢蕴峤簧唐妨斜聿⑾螂娚谈顿M(fèi)的方式購買商品。電商填寫帳單，并委托快遞公司把商品運(yùn)送到客戶的地址。訂單處理軟件記錄從收到訂單直到商品被運(yùn)送給客戶的整個(gè)過程。電商將提供快捷的服務(wù)，以最快和最有效的方法來發(fā)送客戶訂購的產(chǎn)品?？蛻艨梢酝素?，但有時(shí)要付運(yùn)費(fèi)。在下面所列的用戶故事中，（）是與客戶無關(guān)的。A退貨B計(jì)算運(yùn)費(fèi)C瀏覽商品D訂單查詢第4題在一個(gè)校園微信搶票系統(tǒng)中，需要對活動(dòng)的相關(guān)信息進(jìn)行維護(hù)并支持搶票。具體包括發(fā)布活動(dòng)通知、管理搶票過程（定義搶票起止時(shí)間、電子票數(shù)量等）以及活動(dòng)現(xiàn)場檢票。這時(shí)，應(yīng)該采用下面的（）策略進(jìn)行用戶故事建模。A為每個(gè)主要活動(dòng)分別定義一個(gè)用戶故事，并為每個(gè)故事撰寫相應(yīng)的測試場景。B建立一個(gè)“團(tuán)委活動(dòng)搶票”用戶故事，為該故事定義若干個(gè)場景，分別對應(yīng)主要的交互過程。C定義四個(gè)用戶故事，添加活動(dòng)信息，修改活動(dòng)信息，查詢活動(dòng)信息，刪除活動(dòng)信息。D以上所有選項(xiàng)第5題需求說明文檔通常不會(huì)采用（）方式組織撰寫。A用戶手冊B用戶故事C用例模型D測試用例第6題關(guān)于軟件測試，下面的（）說法是正確的。A軟件測試的目的是證明軟件的正確性B窮舉測試是不現(xiàn)實(shí)的C如果單元測試做得足夠好，就不用進(jìn)行集成測試D自動(dòng)化測試一定比手工測試的效果好第7題下面的（）不屬于單元測試的內(nèi)容。A模塊接口B局部數(shù)據(jù)結(jié)構(gòu)C獨(dú)立路徑D用戶界面第8題下面的（）不是單元測試原則。A單元測試應(yīng)該是可以重復(fù)執(zhí)行的，并且結(jié)果是可以重現(xiàn)的。B單元測試應(yīng)相互獨(dú)立，某個(gè)測試不應(yīng)為下一個(gè)測試設(shè)定條件。C單元測試可以通過查看日志文件或人工分析結(jié)果來確認(rèn)是否通過。D單元測試應(yīng)該快速運(yùn)行。第9題黑盒測試是根據(jù)程序的（）來設(shè)計(jì)測試用例。A功能B需求規(guī)格說明C內(nèi)部邏輯D內(nèi)部數(shù)據(jù)E性能第10題下面的（）不是測試用例的設(shè)計(jì)要求。A具有代表性和典型性B尋求系統(tǒng)設(shè)計(jì)和功能設(shè)計(jì)的弱點(diǎn)C只需選取合理的輸入數(shù)據(jù)D考慮用戶實(shí)際的諸多使用場景第11題在下面列舉的測試覆蓋中，（）是最弱的邏輯覆蓋準(zhǔn)則。A語句覆蓋B條件覆蓋C判定覆蓋D判定條件覆蓋E條件組合覆蓋第12題關(guān)于等價(jià)類劃分，下面的（）說法是正確的。A等價(jià)類劃分是一種常用的白盒測試方法B等價(jià)類劃分是將輸入域劃分成盡可能少的若干子域C同一輸入域的等價(jià)類劃分是唯一的D為了提高測試效率，一個(gè)測試用例可以覆蓋多個(gè)有效等價(jià)類第13題（）是在強(qiáng)負(fù)載下對系統(tǒng)進(jìn)行測試，觀察系統(tǒng)在峰值使用情況下的表現(xiàn)行為，從而有效地發(fā)現(xiàn)系統(tǒng)可能存在的隱患。A壓力測試B負(fù)載測試C疲勞強(qiáng)度測試D可靠性測試E大數(shù)據(jù)量測試第14題下面的（）不屬于系統(tǒng)總體設(shè)計(jì)的任務(wù)。A明確系統(tǒng)設(shè)計(jì)目標(biāo)B確定子系統(tǒng)或模塊C設(shè)計(jì)數(shù)據(jù)結(jié)構(gòu)與算法D選擇系統(tǒng)部署方案第15題某游戲公司欲開發(fā)一個(gè)大型多人即時(shí)戰(zhàn)略游戲，游戲設(shè)計(jì)的目標(biāo)之一是能夠支持玩家自行創(chuàng)建戰(zhàn)役地圖，定義游戲?qū)ο蟮男袨榧捌渲g的關(guān)系。針對該目標(biāo)，最適合采用（）體系結(jié)構(gòu)風(fēng)格。A管道-過濾器B隱式調(diào)用C主程序-子程序D解釋器第16題網(wǎng)站系統(tǒng)是一個(gè)典型的（）。A倉庫體系結(jié)構(gòu)B胖客戶機(jī)／服務(wù)器結(jié)構(gòu)C瘦客戶機(jī)／服務(wù)器結(jié)構(gòu)D以上選項(xiàng)都不是第17題設(shè)計(jì)目標(biāo)可分成性能、可靠性、成本、維護(hù)和最終用戶等類型，下面（）描述的是最終用戶目標(biāo)。A當(dāng)用戶發(fā)出任何命令后，系統(tǒng)必須在1秒內(nèi)將信息反饋給用戶。B即使在網(wǎng)絡(luò)失敗的情況下，火車票發(fā)售系統(tǒng)也必須能夠成功地提交火車票。C火車票發(fā)售系統(tǒng)的機(jī)器外殼必須允許安裝新按鈕以便增加新的不同票價(jià)。D系統(tǒng)用戶界面應(yīng)該防止用戶以錯(cuò)誤的順序執(zhí)行命令。第18題（）是選擇合適的解決方案策略，并將系統(tǒng)劃分成若干子系統(tǒng)，從而建立整個(gè)系統(tǒng)的體系結(jié)構(gòu)。A系統(tǒng)總體設(shè)計(jì)B軟件詳細(xì)設(shè)計(jì)C數(shù)據(jù)庫設(shè)計(jì)D用戶界面設(shè)計(jì)第19題耦合表示一個(gè)模塊的（）程度。A可以被更加細(xì)化B聯(lián)接其他模塊和外部世界C僅關(guān)注在一件事情上D能夠適時(shí)地完成其功能第20題某創(chuàng)業(yè)團(tuán)隊(duì)打算開發(fā)一個(gè)簡單的社交網(wǎng)站，要求實(shí)現(xiàn)用戶登錄、內(nèi)容分享等功能，每秒同時(shí)在線人數(shù)（并發(fā)請求）大約為100人。在這種情況下，選擇（）數(shù)據(jù)庫比較合適。AMySQLBRedisCMongoDMySQL+Redis第21題下面的應(yīng)用場景采用（）數(shù)據(jù)庫更合適：有一個(gè)大型的新聞網(wǎng)站，新聞的內(nèi)容編輯完成后就不會(huì)再修改，同時(shí)因?yàn)闀r(shí)事熱點(diǎn)，一些新聞會(huì)被成千萬的用戶在短時(shí)間內(nèi)訪問。AMysqlBRedisCMongo第22題今年初，配合微信公開課PRO，微信發(fā)布了“我和微信的故事”。在HTML5頁面中，用戶可以看到自己的微信注冊時(shí)間、第一個(gè)朋友、第一條朋友圈以及2015年的朋友圈、紅包、地理位置、好友、運(yùn)動(dòng)等活躍情況。在測試狀態(tài)下，該網(wǎng)頁鏈接就已經(jīng)傳播開來，導(dǎo)致訪問量暴漲，所有用戶需要等待幾分鐘甚至幾十分鐘才能完成載入?？紤]到微信大約有5億的月活躍用戶，希望以盡量小的投入提高該頁面的加載速度，下面的（）方案是最不合理的。A通過緩存，避免用戶再次打開頁面時(shí)的重復(fù)計(jì)算B預(yù)先計(jì)算出所有用戶的“微信故事”存儲(chǔ)于數(shù)據(jù)庫中，用戶打開頁面只需要從數(shù)據(jù)庫中讀取即可C將靜態(tài)文件服務(wù)器與計(jì)算服務(wù)器分離（例如將靜態(tài)文件放在CDN即內(nèi)容分發(fā)網(wǎng)絡(luò)上）D當(dāng)用戶請求數(shù)據(jù)時(shí)，通過異步任務(wù)隊(duì)列將計(jì)算分散至大量服務(wù)器集群，提高并行計(jì)算能力第23題下面的（）界面設(shè)計(jì)原則不允許用戶保持對計(jì)算機(jī)交互的控制。A允許交互中斷B允許交互操作取消C對臨時(shí)用戶隱藏技術(shù)內(nèi)部信息D只提供一種規(guī)定的方法完成任務(wù)第24題下面的（）不是一種好的做法。A建立一種有助于理解的代碼布局B變量命名應(yīng)該一目了然C對每一行代碼都要進(jìn)行注釋D修改代碼的同時(shí)，也要維護(hù)代碼周圍的所有注釋第25題下面的（）是正確的。ABCD第26題（）是增加或修改系統(tǒng)功能，使其適應(yīng)業(yè)務(wù)的變化。A改正性維護(hù)B適應(yīng)性維護(hù)C完善性維護(hù)D預(yù)防性維護(hù)第27題（）是從現(xiàn)有的程序代碼中抽取有關(guān)數(shù)據(jù)、體系結(jié)構(gòu)和處理過程的設(shè)計(jì)信息，以便恢復(fù)設(shè)計(jì)結(jié)果。A代碼重構(gòu)B逆向工程C數(shù)據(jù)