一套軟件開發(fā)工程師筆試題
軟件開發(fā)是一個很吃香的行業(yè)，下面unjs小編整理了一套軟件開發(fā)工程師筆試題，歡迎閱讀!
1、試分析下面的SQL語句的優(yōu)劣，并用另外的方法實現(xiàn)，
一套軟件開發(fā)工程師筆試題
。(1) Select * from empe where e.No in (select a. No from amp a )
Select * from empe e where NOT EXISTS (Select a.No from amp a where e.NO=a.No)
(2) select * from emp e, anp a where e. No=a. No
2、用Decoole 重寫下面的socl 語句
SELECT COUNT(*)，SUM(SAL) FROM EMP WHERE DEPT_NO = 0020 AND ENAME LIKE ‘SMITH%’;
select count(*),sum(sal) from emp where dept_no = 0030 and ename like ‘smith%’;
select count(decode(dept_no,0020,’x',null)) d0020_count,
count(decode(dept_no,0030,’x',null)) d0030_count,
sum(decode(dept_no,0020,sal,0)) d0020_sal,
sum(decode(dept_no,0030,sal,0)) d0030_sal
from emp where ename like ‘smith%’;
3、下面哪幾種SQL不好。2,4,5
(1) update 語句 (2)in語句 (3)子查詢 (4)多查等值查詢 (5)笛卡爾乘積
4、請造出下列哪3種命名正確 A,B,D
A、ASD B、$abc C、const D、_asd E、3_asd
5、texarea java (1)寫出文件名 (2)補充代碼
6、型轉換
example:
public String getValue(Object a,Object b){}
當下列方法調(diào)用時將出現(xiàn)何種異常,如何修正
String c=new String(“aaa”);
int d =123;
my.getValue(c,d);
(1) Integer d=new Integer(123);
(2) My.getValue(c,(String)d);
7、在JSP上顯示Araylist中的元素
序號 姓名
8、解釋
beam:遠程接口的具體實現(xiàn)
Home:管理和創(chuàng)建遠程對象
Romate:提供給用戶的遠程接口
9、解釋Javabean與EJB的區(qū)別
10、SeSS’on bean與Entitybean區(qū)別
11、解釋Commend、DAO模式，試舉例說明。
Command定義
不少Command模式的代碼都是針對圖形界面的,它實際就是菜單命令,我們在一個下拉菜單選擇一個命令時,然后會執(zhí)行一些動作，將這些命令封裝成在一個類中,然后用戶(調(diào)用者)再對這個類進行操作,這就是Command模式,換句話說,本來用戶(調(diào)用者)是直接調(diào)用這些命令的,如菜單上打開文檔(調(diào)用者),就直接指向打開文檔的代碼,使用Command模式,就是在這兩者之間增加一個中間者,將這種直接關系拗斷,同時兩者之間都隔離,基本沒有關系了.
顯然這樣做的好處是符合封裝的特性,降低耦合度,Command是將對行為進行封裝的典型模式,Factory是將創(chuàng)建進行封裝的模式,
從Command模式,我也發(fā)現(xiàn)設計模式一個”通病”:好象喜歡將簡單的問題復雜化,
喜歡在不同類中增加第三者,當然這樣做有利于代碼的健壯性 可維護性 還有復用性.
如何使用
具體的Command模式代碼各式各樣,因為如何封裝命令,不同系統(tǒng),有不同的做法.下面事例是將命令封裝在一個Collection的List中,任何對象一旦加入List中,實際上裝入了一個封閉的黑盒中,對象的特性消失了,只有取出時,才有可能模糊的分辨出:
典型的Command模式需要有一個接口.接口中有一個統(tǒng)一的方法,這就是”將命令/請求封裝為對象”:
程序代碼:
public interface Command { public abstract void execute ( );}
//具體不同命令/請求代碼是實現(xiàn)接口Command,下面有三個具體命令
程序代碼:
public class Engineer implements Command {
public void execute( ) { //do Engineer’s command }
}
public class Programmer implements Command {
public void execute( ) { //do programmer’s command }
}
public class Politician implements Command {
public void execute( ) { //do Politician’s command }
}
按照通常做法,我們就可以直接調(diào)用這三個Command,但是使用Command模式,我們要將他們封裝起來,扔到黑盒子List里去:
程序代碼:
public class producer{
public static List produceRequests() {
List queue = new ArrayList();
queue.add( new DomesticEngineer() );
queue.add( new Politician() );
queue.add( new Programmer() );
return queue; }
}
這三個命令進入List中后,已經(jīng)失去了其外表特征,以后再取出,也可能無法分辨出誰是Engineer
誰是Programmer了,看下面如何調(diào)用Command模式:
程序代碼:
public class TestCommand {
public static void main(String[] args) {
List queue = Producer.produceRequests();
for (Iterator it = queue.iterator(); it.hasNext(); )
//取出List中東東,其他特征都不能確定,只能保證一個特征是100%正確,// 他們至少是接口Command的”兒子”.所以強制轉換類型為接口
Command((Command)it.next()).execute();
}
}
DAO：
由此可見,調(diào)用者基本只和接口打交道,不合具體實現(xiàn)交互,這也體現(xiàn)了一個原則,面向接口編程,這樣,以后增加第四個具體命令時,就不必修改調(diào)用者TestCommand中的代碼了.
12、談一下對“保障軟件質(zhì)量”的理解。
有效的軟件質(zhì)量管理
一、引言
隨著社會信息化水平的不斷提高，信息行業(yè)急速膨脹，信息企業(yè)快速成長，隨之帶來的信息市場競爭激烈，企業(yè)為了求生存，滿足客戶要求則成為各行各業(yè)的首要責任。依賴于質(zhì)量、成本和進度的客戶滿意度，質(zhì)量則是重點支撐之一，這樣要求我們對質(zhì)量管理需要加強認識。我們都知道pmbok把項目管理劃分為9個知識領域，即范圍管理、時間管理、成本管理、質(zhì)量管理、人力資源管理、溝通管理、采購管理、風險管理和綜合管理。質(zhì)量管理作為9大知識領域之一，可見其重要性。
質(zhì)量管理包括：質(zhì)量計劃編制、質(zhì)量保證和質(zhì)量控制三個過程域。質(zhì)量計劃是質(zhì)量管理的第一過程域，它主要結合各個公司的質(zhì)量方針，產(chǎn)品描述以及質(zhì)量標準和規(guī)則通過收益、成本分析和流程設計等工具制定出來實施方略，其內(nèi)容全面反應用戶的要求，為質(zhì)量小組成員有效工作提供了指南，為項目小組成員以及項目相關人員了解在項目進行中如何實施質(zhì)量保證和控制提供依據(jù)，為確保項目質(zhì)量得到保障提供堅實的基礎。質(zhì)量保證則是貫穿整個項目全生命周期的有計劃和有系統(tǒng)的活動，經(jīng)常性地針對整個項目質(zhì)量計劃的執(zhí)行情況進行評估、檢查與改進等工作，向管理者、顧客或其他方提供信任，確保項目質(zhì)量與計劃保持一致。質(zhì)量控制是對階段性的成果進行檢測、驗證，為質(zhì)量保證提供參考依據(jù)，它是一個PDCA循環(huán)過程。
二 質(zhì)量管理責任分配
我們公司在開發(fā)項目上按照規(guī)范化軟件的生產(chǎn)方式進行生產(chǎn)，在生產(chǎn)流程上采用ISO9000的標準進行。每個項目除配備了項目開發(fā)所需角色外，還專門配備了配置管理小組、測試小組和質(zhì)量保證小組確保質(zhì)量管理的實施，下面針對這三種角色進行說明：
1、配置管理小組職責
配置管理小組是保證項目開發(fā)完畢的同時，內(nèi)部文檔和外部文檔都同時完成。內(nèi)部文檔的及時產(chǎn)生和規(guī)范，是保證項目開發(fā)各小組能夠更好的接口和溝通的重要前提，從另一個方面講，也是保證工程不被某個關鍵路徑所阻塞而延滯的前提。如上所述，配置管理小組還是保證質(zhì)量保證小組得以發(fā)揮作用的基礎。配置管理小組的主要職責包括： 完善各個部門發(fā)送需要存檔和進行版本控制的代碼、文檔(包括外來文件)和階段性成果; 對代碼、文檔等進行單向出入的控制; 對所有存檔的文檔進行版本控制; 提供文檔規(guī)范，并傳達到開發(fā)組中。
2、測試小組職責
測試小組作為質(zhì)量控制的主要手段，負責軟件的測試設計和執(zhí)行工作。如同軟件開發(fā)一樣，測試在執(zhí)行之前，同樣需要進行測試計劃和測試策略的設計，通常情況下測試可以分為如下幾種類型，如：正確性測試、功能性測試、性能測試、安全測試和系統(tǒng)測試等。而這些測試均需要在測試計劃和測試策略中進行描述用以指導測試小組成員進行測試用例編寫和測試執(zhí)行，
資料共享平臺
《一套軟件開發(fā)工程師筆試題》(http://www.msguai.com)。程序員在交給測試人員之前是進行過一定的單元測試，確保程序編譯、運行正確。測試人員根據(jù)詳細設計的文檔對軟件要實現(xiàn)的功能進行一一測試，保證軟件的執(zhí)行正確的實現(xiàn)設計要求，在此也只證明了軟件正確的反映了設計思想，但是否真正反映了用戶的.需求仍需要進一步的功能性測試。
測試人員只有根據(jù)軟件需求規(guī)格說明書所提及的功能進行檢測，才能確保項目組開發(fā)的軟件產(chǎn)品滿足用戶需求。在正確性測試完成之后，需要測試的是軟件的性能，軟件的性能在本項目中占有重要的地位，性能要求有可能改變軟件的設計，為避免造成軟件的后期返工，測試在性能上需要較大的側重。如果有必要的話，測試小組還需要做安全測試，以確保系統(tǒng)使用安全可靠。
3、質(zhì)量保證小組職責
質(zhì)量保證小組作為質(zhì)量保證的實施小組，主要職責是保證軟件透明開發(fā)的主要環(huán)節(jié)。在項目開發(fā)的過程中幾乎所有的部門都與質(zhì)量保證小組有關。質(zhì)量保證小組對項目經(jīng)理提供項目進度與項目真正開發(fā)時的差異報告，提出差異原因和改進方法。
在項目進度被延滯或質(zhì)量保證小組認為某階段開發(fā)質(zhì)量有問題時，提請項目經(jīng)理、項目負責人等必要的相關人員舉行質(zhì)量會議。解決當前存在的和潛在的問題。質(zhì)量保證是建立在文檔的復審基礎之上，因而文檔版本的控制，特別是軟件配置管理，直接影響軟件質(zhì)量保證的影響力和力度。質(zhì)量保證小組的檢測范圍包括：系統(tǒng)分析人員是否正確的反映了用戶的需求; 軟件執(zhí)行體是否正確的實現(xiàn)了分析人員的設計思想; 測試人員是否進行了較為徹底的和全面的測試; 配置管理員是否對文檔的規(guī)范化進行的比較徹底，版本控制是否有效。
三 質(zhì)量管理實施
有了良好的資源配備，又如何在項目全生命周期內(nèi)實施質(zhì)量保證，讓我們從以下幾個方面來看質(zhì)量保證的實施過程：
1、項目進度的質(zhì)量保證
項目進度是項目進行是否順利的最直觀表現(xiàn)。顯然在項目開始之前，項目開發(fā)計劃是必須的。如果項目開發(fā)計劃的制定的是完全合理的，那項目進度也就真正表達了項目與最終的交付使用之間的距離，然而要制定完全合理的項目開發(fā)計劃幾乎不太可能�？梢娨ＷC項目進度，首先要保證項目開發(fā)計劃盡可能合理。
項目計劃的合理程度與項目計劃制定者從事類似規(guī)模和類似業(yè)務的項目的經(jīng)驗有直接關系，通過經(jīng)驗往往能夠預見潛在的阻礙，這樣要求項目計劃制定者需要集眾人之力來完善計劃。
當項目計劃制定初期，由質(zhì)量保證小組組織召開的項目計劃評審會，邀請公司技術專家、用戶以及項目組小組成員一起討論項目計劃的可行性，會議通常采用頭腦風暴法，各抒己見，會后由指定的記錄員形成質(zhì)量記錄，發(fā)送給相關人員，對其計劃中不合理的地方進行修改完善，并由質(zhì)量保證人員對其結果跟蹤，以確保項目計劃完整性、可行性，完善后的計劃交由配置管理人員進行版本控制。
然而在計劃實施過程中，計劃不是“固定化”。常有人道，“計劃趕不上變化”，但“要跟上變化”。項目計劃以里程碑為界限，將整個開發(fā)周期劃分為若干階段。根據(jù)里程碑的完成情況，適當?shù)恼{(diào)整每一個較小的階段的任務量和完成的任務時間，這種方式非常有利于整個項目計劃的動態(tài)調(diào)整。也利于項目質(zhì)量保證的實施。
實際運作中，當質(zhì)保小組發(fā)現(xiàn)計劃實施的差異后，報告項目經(jīng)理，由項目經(jīng)理組織負責對計劃進行周期性維護，對于已經(jīng)變動的計劃由質(zhì)保小組協(xié)助配置管理小組完成版本控制。本公司已經(jīng)開發(fā)湖南移動的集中客服系統(tǒng)，開發(fā)中的子項目多達六個，歷時十個月，目前多數(shù)項目已經(jīng)開發(fā)完畢，系統(tǒng)正在試運行階段，項目金額數(shù)千萬元。在這樣的項目中，從管理者到開發(fā)人員到測試人員都積累了較為豐富的經(jīng)驗，特別是項目開發(fā)計劃的制定，和項目進度的控制。
2、項目開發(fā)各階段的質(zhì)量保證
a、需求分析
需求分析是開發(fā)人員對系統(tǒng)需要做什么和如何做的定義過程。從系統(tǒng)分析的經(jīng)驗來看，這個過程往往是個循序漸進的過程，一次性對系統(tǒng)形成完整的認識是困難的。只有不斷地和客戶領域?qū)＜疫M行交流確認，方能逐步明了用戶的需求。從系統(tǒng)開發(fā)的過程得知，系統(tǒng)分析時犯下的錯誤，會在接下來的階段被成倍的放大，越是在開發(fā)的后期，糾正分析時犯下的錯誤所花費的代價越是昂貴，也越發(fā)影響系統(tǒng)的工期和系統(tǒng)的質(zhì)量。
解決系統(tǒng)分析錯誤的方法我們公司通常采用邀請用戶參與進行需求評定，然后對其用戶的意見由質(zhì)保成員跟蹤檢測是否納入需求規(guī)格說明書，同時與用戶簽字確認形成需求基線，交由配置管理員放入配置管理庫。
雖然盡早的邀請用戶參與，仍然避免不了項目進行中用戶的需求變更請求。對于開發(fā)過程存在的需求變動，我們要求用戶填寫變更申請單發(fā)送給項目配置管理員，在通過配置配置員轉交質(zhì)保小組，負責組織專家小組和項目組成員一起討論實施變更的可行性及實施后所帶來的影響，小的變更則直接記錄入變更記錄原因分析項和風險項欄，大的變更則需要形成正式的變更報告，無論那種變更都需要對相應的文檔實施同步變更(包括需求規(guī)格說明書、詳細設計文、安裝手冊、操作手冊等)。但是對于無法實現(xiàn)或是變更會帶來巨大的影響而將導致進度的延期，這時，我們將變更報告提交給用戶或邀請用戶進行協(xié)調(diào)會議，討論變更取舍問題或是項目進度變更問題。
決定變更之后，由項目經(jīng)理組織實施變更，測試人員檢測變更結果，而質(zhì)保小組成員監(jiān)督變更實施過程并協(xié)助配置管理員對變更后的成果物進行版本控制。變更實施完后，上線前還需要指定人員協(xié)助用戶一同測試并由用戶簽字后同意方可上線。
b、系統(tǒng)設計
優(yōu)良的體系結構應當具備可擴展性和可配置性，而好的體系結構則需要好的設計方法，自然設計選型成為了系統(tǒng)設計首要的工作，究竟是采用哪種設計方法好呢?
對于設計選型不能一概而論，需要針對項目的結構、項目的特征和用戶的需求來分析，同樣也要考慮到參與項目小組成員的素質(zhì)，如果其中大部分都沒有從事過面向?qū)ο蟮脑O計且項目進對緊迫，這樣沒有多余的時間來培訓小組成員來掌握面向?qū)ο蟮脑O計方法，盡管眾所周知面向?qū)ο笤O計方法的優(yōu)勢，我們還是不如采用面向過程的方式(除用戶指定開發(fā)設計方式外)可以減少項目承擔的技術風險。
我們公司有過一個項目，用戶指定需要采用面向?qū)ο蠓治�、設計和開發(fā)，且開發(fā)周期短，在無賴的情況下，項目小組只能選用面向?qū)ο蟮能浖_發(fā)過程，由于項目小組很少從事過面向?qū)ο蟮拈_發(fā)，經(jīng)驗缺乏，導致項目上馬后項目進度延誤，項目沒有達到預期的效果。
針對此次開發(fā)，我們分析其原因，發(fā)現(xiàn)小組成員在開發(fā)過程中對于新技術互相交流少，各自有各自的理解和想法，造成理解上的不一致性，導致工作重復性高，滯后項目進度。建議解決方法是項目組成員采用集中辦公，分塊學習，學習的成果馬上向項目相關人員發(fā)布，再由配置管理員對其發(fā)布的文檔進行整理、規(guī)類放入配置庫以供大家共享。這樣方便大家的互相學習，減少重復的工作。在這次開發(fā)中我們公司從管理人員、設計人員到開發(fā)人員都汲取了很多教訓，同時經(jīng)過此次項目的開發(fā)，小組成員也積累了豐富的面向?qū)ο蟮拈_發(fā)經(jīng)驗。
除設計選型，還有一個容易被忽視的問題，就是公共類開發(fā)。公共類開發(fā)可以減少工作中的重復工作，降低開發(fā)成本。這要求我們再設計階段通過對用戶需求的仔細研究，盡可能的識別出公共類，并進行定義指定專人負責設計通知其它設計人員，以減少重復工作。對于項目組提供的設計文檔，由質(zhì)保小組組織技術專家、項目組設計人員、開發(fā)人員和測試人員對其設計文檔的評審，檢測設計文檔對其下一階段工作的可行性，及時發(fā)現(xiàn)設計中可能存在的錯誤，降低項目開發(fā)風險，同時確保設計文檔能為開發(fā)人員、測試人員提供切實的指導。對于可復用的設計進行提取作為公共庫設計和開發(fā)，提供項目組或整個公司重用。最后交由配置管理員進行設計文檔的版本控制。
c、實現(xiàn)
實現(xiàn)也就是代碼的生產(chǎn)過程。這里不僅包括代碼的產(chǎn)生，同時也包括測試用例的產(chǎn)生。針對上一階段提供詳細設計，程序員開始編碼并且調(diào)試程序，測試人員則根據(jù)設計進行測試用例的設計，設計出來的用例需要得到項目組成員認可由項目經(jīng)理審核通過才能進入配置庫。同時程序員調(diào)試完程序提交測試人員進行程序正確性檢測。
d、文檔管理
文檔維護主要是配置管理小組的工作。文檔從用途上分主要分為內(nèi)部文檔和外部文檔。
內(nèi)部文檔包括： 項目開發(fā)計劃; 需求分析; 體系結構設計說明; 詳細設計說明; 構件索引; 構件成分說明; 構件接口及調(diào)用說明; 組件索引; 組件接口及調(diào)用說明; 類索引; 類屬性及方法說明; 測試報告; 測試統(tǒng)計報告; 質(zhì)量監(jiān)督報告; 源代碼; 文檔分類版本索引; 軟件安裝打包文件。
外部文檔主要包括： 軟件安裝手冊; 軟件操作手冊; 在線幫助; 系統(tǒng)性能指標報告; 系統(tǒng)操作索引。
如何保證文檔的全面性，使其真正為項目的進度提供保證，又不因為文檔的寫作而耽誤項目的進度，這仍然是一個比較難解決的問題。解決此問題，其核心仍然是個”度”的問題。在本項目的開發(fā)中，配置管理小組的一個非常重要的任務還是書寫文檔規(guī)范和文檔模板。當有文檔模板后需要書寫文檔的人員只剩下”填空”的工作，從某種意義上講，書寫文檔的速度會加快。如果書寫文檔的人員認為文檔的更細致的部分可以由他人幫助完成，則該文檔即交由他人完成，但此時文檔并不算被正式提交，當他人書寫完畢之后，必須由文檔的初寫者進行復審，復審通過后方可以正式提交，進入軟件配置管理的循環(huán)中。
配置管理小組真正核心的工作是對文檔的組織管理。根據(jù)文檔的不同，文檔的來源也不同，有些是通過質(zhì)量保證小組經(jīng)過復審之后轉交給配置管理小組，有些則會直接從文檔的出處到達配置管理小組。文檔的管理是一個非常煩瑣的工作，但是長遠來看它不僅使項目的開發(fā)對單個主要人員的依賴減少，從而減少人員流動給項目的帶來的風險，更重要的是在項目進行到后百分之十的時候起到拉動項目的作用。
從以往做大項目的經(jīng)驗來看，寫作文檔在項目開發(fā)的早期可能會使項目的進度比起不寫文檔要稍慢，但隨著項目的進展，各個部門需要配合越來越多，開發(fā)者越來越需要知道其他人員的開發(fā)思路和開發(fā)過程，才能使自己的開發(fā)向前推進。一個明顯的例子就是系統(tǒng)整合，或者某些環(huán)節(jié)是建立在其他環(huán)節(jié)完成的基礎之上時，就更顯現(xiàn)出文檔交流的準確性和高效性。
3、系統(tǒng)維護質(zhì)量保證
在我們公司，維護小組的任務一方面是保證對項目客戶的跟蹤服務，另一方面是確保該項目其它的開發(fā)人員從項目中盡快的解脫出來以便投入到下一個項目的開發(fā)中。所以通常項目維護小組成員主要由項目組的少部分開發(fā)人員承擔完成。他們不僅了解軟件的核心內(nèi)容，而且與客戶也不陌生，以便能夠以最快的速度修正錯誤。對于一般性的錯誤，如操作不當?shù)纫鸬膯栴}，全部由維護小組執(zhí)行完成，但需要用戶測試確認上線。如果較大的修改則需要走變更控制流程，用戶或者維護人員填寫變更申請，經(jīng)專家會議討論分析可行方案在由維護小組實施，通過測試后方可提交用戶。
維護小組的人員基本上是按項目跟進的。當一個項目剛剛交付用戶時，在維護小組有較多的人員進行跟進，隨軟件的穩(wěn)定，跟進的人逐步減少，并轉移到其它項目中去。
13 3.給出一個MVC結果圖，請簡單用文字對他進行一次前后臺交互的描述。(這個圖你去找啦)
14 PowerDesigner
15 項目經(jīng)驗
16 三層結構的理解
【一套軟件開發(fā)工程師筆試題】相關文章：
2.一套VC試題
3.一套ASP筆試題
7.360筆試題目
8.360筆試題目