用以下的方式可以監控登入登出的用戶:
創建如下的兩張表:
create table login_log -- 登入登出信息表 ( session_id int not null, -- sessionid login_on_time date, -- 登入進間 login_off_time date, -- 登出時間 user_in_db varchar2(30), -- 登入的db user machine varchar2(20), -- 機器名 ip_address varchar2(20), -- ip地址 run_program varchar2(20) -- 以何程序登入 ); create table allow_user -- 網域用戶表 ( ip_address varchar2(20), -- ip地址 login_user_name nvarchar2(20) -- 操作者姓名 ); |
創建如下的兩個觸發器:
create or replace trigger login_on_info -- 記錄登入信息的觸發器 after logon on database Begin insert into login_log(session_id,login_on_time,login_off_time,user_in_db,machine,ip_address,run_program) select AUDSID,sysdate,null,sys.login_user,machine,SYS_CONTEXT('USERENV','IP_ADDRESS'),program from v$session where AUDSID = USERENV('SESSIONID'); --當前SESSION END; create or replace trigger login_off_info --記錄登出信息的觸發器 before logoff on database Begin update login_log set login_off_time = sysdate where session_id = USERENV('SESSIONID'); --當前SESSION exception when others then null; END; |
方法二:
用如下的方式可以審記執行drop動作的事件:
/** * drop語句的審計日志表 */ create table drop_log ( session_id int not null, -- sessionid drop_time date, -- drop的時間 ip_address varchar2(20), -- ip地址 object_owner varchar2(30), -- 對象的所有者 object_name varchar2(30), -- 對象名稱 object_type varchar2(20), -- 對象類型 drop_by_user varchar2(30) -- 執行drop語句的用戶 ); create or replace trigger drop_info after drop on mfg0513user.schema -- 在mfg0513user用戶上創建審記DROP的觸發器 begin insert into drop_log (session_id, drop_time, ip_address, object_owner, object_name, object_type, drop_by_user) values(USERENV('SESSIONID'), sysdate, SYS_CONTEXT('USERENV','IP_ADDRESS'), sys.dictionary_obj_owner, sys.dictionary_obj_name, sys.dictionary_obj_type, sys.login_user); end; |
這幾天
面試幾個想做安卓
Linux驅動的,總體感覺上驅動基礎還是比較薄弱,大部分情況是雖然做過驅動,但是基本上都是采用內核現成的,或者是開發板上已經有的,單獨寫過模塊驅動很少,驅動機制理解不是很透徹.以下是幾個隨口問過的基礎問題,供參考.
1、字符型驅動設備你是怎么創建設備文件的，就是/dev/下面的設備文件，供上層應用程序打開使用的？
2、寫一個中斷服務需要注意哪些？如果中斷產生之后要做比較多的事情你是怎么做的？
3、自旋鎖和信號量在互斥使用時需要注意哪些？在中斷服務程序里面的互斥是使用自旋鎖還是信號量？還是兩者都能用？為什么？
4、原子操作你怎么理解？為了實現一個互斥，自己定義一個變量作為標記來作為一個資源只有一個使用者行不行？
5、insmod 一個驅動模塊，會執行模塊中的哪個函數？rmmod呢？這兩個函數在設計上要注意哪些？遇到過卸載驅動出現異常沒？是什么問題引起的？
6、在驅動調試過程中遇到國oops沒？你是怎么處理的？
7、ioctl和unlock_ioctl有什么區別？
8、設備驅動模型三個重要成員是？platfoem總線的匹配規則是？在具體應用上要不要先注冊驅動再注冊設備？有先后順序沒？
這些應該都是比較基礎的問題吧，但是從實際情況上來看，回答的都不是很正確。
核心代碼如下：
if(addX){ x+=3; }else{ x-=3; } if(addY){ y+=6; }else{ y-=6; } if(x<=0||x>=(width-50)){ addX=!addX; } if(y<=0||y>=(height-50)){ addY=!addY; } |
根據x和y遞增的值，來決定角度
一個網站項目的確立是建立在各種各樣的需求上面的，這種需求往往來自于客戶的實際需求或者是出于公司自身發展的需要，其中客戶的實際需求也就是說這種交易性質的需求占了絕大部分。面對對網站開發擁有不同知識層面的客戶，項目的負責人對用戶需求的理解程度，在很大程度上決定了此類網站開發項目的成敗。因此如何更好地的了解、分析、明確用戶需求，并且能夠準確、清晰以文檔的形式表達給參與項目開發的每個成員，保證開發過程按照滿足用戶需求為目的正確項目開發方向進行，是每個網站開發
項目管理者需要面對的問題。
需求分析活動其實本來就是一個和客戶交流，正確引導客戶能夠將自己的實際需求用較為適當的技術語言進行表達(或者由相關技術人員幫助表達)以明確項目目的的過程。這個過程中也同時包含了對要建立的網站基本功能和模塊的確立和策劃活動。所以項目小組每個成員、客戶甚至是開發方的部門經理(根據項目大小而定)的參與是必要的。而項目的管理者在需求分析中的職責有如下幾個方面：
1、負責組織相關開發人員與用戶一起進行需求分析。
2、組織美術和技術骨干代表或者全部成員(與用戶討論)編寫《網站功能描述書(初稿)》文檔。
3、組織相關人員對《網站功能描述書(初稿)》進行反復討論和修改，確定《網站功能描述書》正式文檔。
4、如果用戶有這方面的能力或者用戶提出要求，項目管理者也可以指派項目成員參與，而由用戶編寫和確定《網站功能描述書》文檔。
5、如果項目比較大的話，最好能夠有部門經理或者他授權的人員參與到《網站功能描述書》的確定過程中來。
二、完整的需求調查文檔記錄體系
在整個需求分析的過程中，將按照一定規范的編寫需求分析的相關文檔不但可以幫助項目成員將需求分析結果更加明確化，也為以后開發過程中做到了現實文本形式的備忘，并且有助于公司日后的開發項目提供有益的借鑒和模范，成為公司在項目開發中積累的符合自身特點的經驗財富。
需求分析中需要編寫的文檔主要是《網站功能描述書》，他基本上是整個需求分析活動的結果性文檔，也是開發工程中項目成員主要可供參考的文檔。為了更加清楚的描述《網站功能描述書》往往還需要編寫《用戶調查報告》和《市場調研報告》文檔來輔助說明。各種文檔最好有一定的規范和固定格式，以便增加其可閱讀性和方便閱讀者快速理解文檔內容，相關規定將在本文后面討論。
三、向用戶調查些什么
在需求分析的工程中，往往有很多不明確的用戶需求，這個時候項目負責人需要調查用戶的實際情況，明確用戶需求。一個比較理想化的用戶調查活動需要用戶的充分配合，而且還有可能需要對調查對象進行必要的培訓。所以調查的計劃安排：時間、地點、參加人員、調查內容，都需要項目負責人和用戶的共同認可。調查的形式可以是：發需求調查表、開需求調查座談會或者現場調研。調查的內容主要如下：
1、網站當前以及日后可能出現的功能需求。
2、客戶對網站的性能(如訪問速度)的要求和可靠性的要求。
3、確定網站維護的要求。
4、網站的實際運行環境。
5、網站頁面總體風格以及美工效果(必要的時候用戶可以提供參考站點或者由公司向用戶提供)。
6、主頁面和次級頁面數量，是否需要多種語言版本等7、內容管理及錄入任務的分配。
8、各種頁面特殊效果及其數量(js，flash等)
9、項目完成時間及進度(可以根據合同)
10、明確項目完成后的維護責任。
調查結束以后，需要編寫《用戶調查報告》，《報告》的要點是：
1、調查概要說明：網站項目的名稱;用戶單位;參與調查人員;調查開始終止的時間;調查的
工作安排。
2、調查內容說明：用戶的基本情況;用戶的主要業務;信息化建設現狀;網站當前和將來潛在的功能需求、性能需求、可靠性需求、實際運行環境;用戶對新網站的期望等。
3、調查資料匯編：將調查得到的資料分類匯總(如調查問卷，會議記錄等等)
四、市場調研活動內容
通過市場調研活動，清晰的分析相似網站的性能和運行情況。可以幫助項目負責人更加清楚的構想出自己開發的網站的大體架構和模樣，在總結同類網站優勢和缺點的同時項目開發人員可以博采眾長開發出更加優秀的網站。
但是由于實際中時間、經費、公司能力所限，市場調研覆蓋的范圍有一定的局限性，在調研市場同類網站的時候，應盡可能調研到所有比較出名和優秀的同類網站。應該了解同類網站的使用環境與用戶的詫異點、類似點，同類產品所定義的用戶詳細需求(需要公司或者項目負責人有一定的關系)。市場調研的重點應該放在主要競爭對手的作品或類似網站作品的有關信息上。市場調研可以包括下列內容：
1、市場中同類網站作品的確定。
2、調研作品的使用范圍和訪問人群。
3、調研產品的功能設計(主要模塊構成，特色功能，性能情況等等)
4、簡單評價所調研的網站情況。
調研的目的是明確并且引導用戶需求。
對市場同類產品調研結束后，應該撰寫《市場調研報告》主要包括一下要點：
1、調研概要說明：調研計劃;網站項目名稱、調研單位、參與調研、調研開始終止時間。
2、調研內容說明：調研的同類網站作品名稱、網址、設計公司、網站相關說明、開發背景、主要適用訪問對象、功能描述、評價等項目管理者聯盟
3、可采用借鑒的調研網站的功能設計：功能描述、用戶界面、性能需求、可采用的原因。
4、不可采用借鑒的調研網站的功能設計：功能描述、用戶界面、性能需求、不可采用的原因。
5、分析同類網站作品和主要競爭對手產品的弱點和缺陷以及本公司產品在這些方面的優勢。
6、調研資料匯編：將調研得到的資料進行分類匯總。
五、清晰的需求分析輸出——《網站功能描述書》：在擁有前期公司和客戶簽訂的合同或者是標書的約束之下，通過較為詳細具體的用戶調查和市場調研活動，借鑒其輸出的《用戶調查報告》和《市場調研報告》文檔，項目負責人應該對整個需求分析活動進行認真的總結，將分析前期不明確的需求逐一明確清晰化，并輸出一份詳細清晰的總結性文檔――《網站功能描述書(最終版)》以供作為日后項目開發過程中的依據。《網站功能描述書》必須包含以下內容：
1、 網站功能
2、 網站用戶界面(初步)
3、 網站運行的軟硬件環境
4、 網站系統性能定義
5、 網站系統的軟件和硬件接口
6、 確定網站維護的要求
7、 確定網站系統空間租賃要求
8、 網站頁面總體風格及美工效果。
9、 主頁面及次頁面大概數量。
10、管理及內容錄入任務分配。
11、各種頁面特殊效果及其數量。
12、項目完成時間及進度(根據合同)
13、明確項目完成后的維護責任。
綜上所述，在網站項目的需求分析中主要是由項目負責人來確定對用戶需求的理解程度，而用戶調查和市場調研等需求分析活動的目的就是幫助項目負責人加深對用戶需求的理解和對前期不明確的地方進行明確化，以便于日后在項目開發過程中作為開發成員的依據和借鑒。
當然一次成功的需求分析不僅需要項目負責人甚至是客戶等所有項目相關人員的共同努力，還和公司的能力范圍有一定關系。需要說明的是本文所述的需求分析活動內容是建立在較為理想的基礎上的。由于各個公司現實情況的不同，讀者可以根據自身情況不一借鑒吸收利用。重要的是能構根據本公司的情況，系統的規范此類文檔做好保存和收集，相信對公司以后其他網站項目的進行以及公司自身實力的增強都會有很大幫助。
今天想和大家說的，其實無非是和我們如影隨形的需求邊變更。似乎自我入行一來一直聽到這個詞語。先說何為需求？我按照廣義和狹義簡單的區分了下。
所謂廣義需求，及時一切和項目有關的想法，建議反饋，都叫做需求。所以狹義，就是產品經理提出的需求文檔。其實一定時期內，我們不得不承認，廣義需求是相對穩定的，并且有一定的經驗可談。何意？廣義需求可以是用戶的一個反饋，可以是今年流行的一種設計風格，可以是近幾年流行的聚焦區域。再具體點說，就是，用戶可以希望音樂播放軟件提供高品質，免費，且海量的搜索結果，這個要求可能是幾年不變。或者，近幾年流行扁平設計風格，再或者這幾年
移動支付比較火熱。這些都是需求，這些需求有共同特點就是相對穩定。
與之相較，所謂狹義需求，就是產品經理提出的需求，很可能朝令夕改，很可能半途而廢，很可能淺嘗輒止。比如做一個按鈕，可能今天要求放在屏幕中間，明天要求放在底部。再比如今天設想了一個定位功能，做到一半可能就放棄了。
說到這里大家不禁有個疑惑。我們姑且關起們來說話，既然外界的需求相對穩定何故內部的
需求變更頻頻？我自我總結，目前所處的項目中需求變更重要有三種類型：
1）老大看著不爽強制要求改。
2)產品經理自作主張朝令夕改。
3)業界有競爭對手新出一個功能不得不趕超。
好吧，我們從這開始抽絲剝繭，首先老大的需求我們稍后再議。競爭對手的變更就真的這么緊迫？這么巧？恰好非要插在本來周期不長的
互聯網項目中？互聯網的一次版本迭代周期也就一兩周，甚至好多一周，有多少猝不及防的競爭對手總能在你開展一期需求的時候，讓你不得不顧及他們的新功能？我想很少，甚至可以說沒有。除非自己公司請來的產品經理都是腦殘什么都要等著別家出來功能，慢慢抄襲。這種假設一般是不成立的，兩個公司之所以成為競爭對手，是因為實力相當。即便是抄襲也是互相抄襲，不會不給喘息的機會。如果需求因此而亂恐怕是自亂陣腳！
順便提下，老大的強制需求，首先肯定老大直接干預的并不多，即便有這么事必親躬的CEO，何不先問問為何要這么要求？何不想想變更后的利與弊，如果你說的客觀合理，老大不會糊涂到即便錯了也要堅持吧。再者就是，事實上來自老大，和競爭對手的層面導致需求變更的情況概率相當小，如果一個產品經理常常把這些掛在嘴邊，恐怕是不稱職的一種體現。
最重要的原因，似乎已經發現了，就是產品經理自作主張朝令夕改。既然知道病因，就不難醫治。但是需要對癥下藥。對此我總結的集中典型情況如下：
1)病情一：產品經理自己缺少經驗，說白了就是還沒真的想好就說設計已經完成。就開始開發。
癥狀：開發過程中研發常常詢問細節邏輯，產品經理常常改變原有需求。
危害：讓所有的評審
工作的成果付之東流，讓
測試參考的依據化為烏有，實在百害無一利，這就是典型的欲速不達
對策：客觀的放映情況，如果您再公司有足夠的權利，把這些稚嫩的產品經理調到不足輕重的小項目中去磨練。
諸葛亮尚且可以揮淚斬馬謖，我們也不愿意看到長平之戰的趙括毀了一個項目。
實在沒辦法，我們只能強制要求評審需求，多問問幾個“你確定嘛”
2)病情二：當初設計太多完美，以至于提出了很多研發技術不能實現的炫酷效果。
癥狀：產品經理為了成品高大上，設計很理想的效果，但是實際的情況不理想，導致一直僵持PK，需求不斷調整
危害：可能消磨團隊的斗志和信心，有很大的延期風險。
對策：誠知，畢其功于一役乃產品大忌，其實凡事講究實事求是，硬要在現在安卓
手機上實現iPhone類似的指紋 識別功能似乎不太現實。其實軟件設計大多是帶著鐐銬跳舞。即便是所謂的研發大牛，也是用人家的API吧。
我們測試人員，要合適的時候曉以利害，讓產品經理明白，快速迭代積極改進，才是互聯網的制勝之道。
此外，可以加強概要設計評審，以加強需求能實現的評估。
3）病情三：產品缺少主見，覺得這樣也行，那樣也行。設計出多套方案相對比，選取更好的。
癥狀：一次設計出多套方案，讓研發測試都實現，最后選取效果最好的一套。
危害：有目的的嘗試是好的，盲目的嘗試大多徒勞無功。
對策：我挺多有很多人鼓吹，我們的產品多么精致，我們的圖標是從一百張里面一張張的篩選出來的。
我承認精益求精的品質。但更相信中庸之道，過猶不及，所有的事情都要因地制宜，因時制宜。
對此我們可以強調項目的實際情況，可以綜合考慮時間，人力，技術經驗等因素，制定出合理方案。
實際工作中可能還有各種各樣的情況，只要我們勤于總結，勤于思考，總能找到一條適合自己的應對之策略。其實還有個大前提就是傳統互聯網和移動互聯網，傳統互聯網項目周期長，可以憑借強有力的評審制度，有效的控制需求變更。移動互聯網求快為主。這只是希望大記得磨刀不誤砍柴工的道理。與此同時也要不斷的革新。比如你身處移動互聯網公司，可以將傳統的幾個小時的需求評審，壓縮到晨會的十幾分鐘。當然這也提出了對人員的要求，要求你對需求足夠敏感。能及時的提出問題，切莫讓
敏捷流于口號，切莫讓晨會流于形式。
關于應對需求變更，其中的技巧和經驗還有很多，相信只要大家有心，也能積累更多的經驗。
最近在跑穩定性
測試 3 X 24小時的時候,發現負載機產生的日志還運行記錄等等竟然有100多G! C盤空間不足,但是D盤還有700多G空間呢,怎么讓臨時文件轉移到D盤?
此處分兩種情況:
一. 修改本機的臨時文件
1. 觀察壓力機產生的臨時文件都是在 %USERPROFILE%\Local Settings\Temp 下,于是在“我的電腦”——“屬性”——“高級”——“環境變量”里修改了TEMP和TMP變量
此處設置它們的值都未 "D:\TEMP"，運行發現結果仍然保存在%USERPROFILE%\Local Settings\Temp下。
2.
百度發現, loadrunner執行時用的"NT AUTHORITY\SYSTEM"用戶,修改此用戶的 TEMP和TMP變量路徑要用到WMI相關的知識.
在MS-DOS窗口執行
wmic ENVIRONMENT where "name='temp'" get UserName,VariableValue
wmic ENVIRONMENT where "name='tmp'" get UserName,VariableValue
wmic ENVIRONMENT where "name='temp'" get UserName,VariableValue
wmic ENVIRONMENT where "name='tmp'" get UserName,VariableValue
查看‘NT AUTHORITY\SYSTEM’ TEMP和TMP 環境變量仍然是%USERPROFILE%\Local Settings\Temp ,并沒用因為上面的設置而改變,所以沒有起到效果
為了修改它們,分別執行
wmic ENVIRONMENT where "name='temp' and username like '%SYSTEM'" set VariableValue='%temp%'
wmic ENVIRONMENT where "name='tmp' and username like '%SYSTEM'" set VariableValue='%temp%'
wmic ENVIRONMENT where "name='temp' and username like '%SYSTEM'" set VariableValue='%temp%'
wmic ENVIRONMENT where "name='tmp' and username like '%SYSTEM'" set VariableValue='%temp%'
將NT AUTHORITY\SYSTEM的環境變量指向系統的Temp變量! 執行成功. 再次運行壓測,發現臨時文件已經到d:\temp文件夾了..
二. 修改其他負載機(協作施壓)
1 .“我的電腦”——“屬性”——“高級”——“環境變量”里修改了TEMP和TMP變量
此處設置它們的值都為 "D:\TEMP"，
2. 進入loadrunner controller ,菜單 secnario --- load generator --- 設置協作負載機的臨時文件路徑
單擊 Details按鈕 --->
在如圖選項卡中中,選擇第二個選項....
即可...
每次新版本要出貨時, 常常被詢問是否
測試結束了? 質量是否有信心? 你依據的標準是甚么?
我想很多人都會覺得很難回答這個問題. 基本上, 可以根據以下五種狀況, 來決定是否測試可以結束.
1. 老板說了算
基本上, 老板是無敵的. 他說甚么時候就是甚么時候. 我想大家不會, 也不敢不同意. XD
2. 團隊有共識要停止
如果團隊討論完后, 決定要何時停止測試, 這樣也是可以結束
3. 當代價太高
如果要找到下一個 bug 的代價, 會超過這個 bug 所帶來的損失, 那確實沒有必要再測下去, 是可以即刻結束
4. 如果 bug 被發現的比例下降到預期的目標
有時候你會觀察每一段時間內找到多少 bug, 如果你發現它一直在下降, 并且低于你所定的目標, 這時候你就可以出貨. 像是低于5 個 bugs/per day, 并且這些 bugs 都不是嚴重的 bugs
如何你會度量你的測試個案, 已經涵蓋了多少東西, 便可以知道你的測試范圍夠不夠. 像是 90 % line coverage, 75% branch coverage 等等. 當達到設定的目標, 自然你也可以說測試可以結束了.
目前看起來只有后面兩個, 比較有數據來參考, 前面三個比較是自由心證. 事實上, 這些都是心安的說法. 因為只要給妳時間和資源, 其實都還是可以找到 bugs的.
因為, < 1 bugs/per day 或是 100% line/branch coverage, 其實都沒有保證甚么. 最多只是賬面上給你信心. 出貨后被抓到問題, QA 還是等著被罵沒有做好. 不公平, 但是是事實. XD
在各種不同分辨率、固件版本、CPU的android設備中測試最主要且頻率使用較高的功能，查看是否滿足需要。選擇最主要的功能點：安裝、啟動、卸載、完成一局游戲、以及頻率較高的功能點。
android性能測試工具分為2種：
一種是apk形式的，直接將應用安裝到
手機，監控手機的CPU、內存、流量等信息。
第二種是使用eclipse插件，通過使用手機和電腦usb連接，使用該插件監控手機的CPU、內存、流量等信息。
做性能測試的時候，需要分析測試結果。為了更好的記錄測試過程，可以使用動態手機錄屏。
接入測試：
測試在不同的網絡下，游戲是否正常運行，如：聯通2G、3G、4G；電信2G、3G、4G；移動2G、3G、4G；不同的wifi。
其RET HAT鏡像文件無法掛載，
#mount /dev/cdrom /mnt
錯誤提示：
mount: you must specify the filesystem type //必須區分文件類型
可指定其文件類型
就是在mount命令后面加個選項，用-t就行啦。
#mount -t /dev/cdrom /mnt
但這種處理方式仍不能解決。
之后查看其文件目錄結構
/dev
dev 是設備(device)的英文縮寫。這個目錄對所有的用戶都十分重要。因為在這個目錄中包含了所有linux系統中使用的外部設備。但是這里并不是放的外部設備的驅動程序。這一點和我們常用的windows, dos操作系統不一樣。它實際上是一個訪問這些外部設備的端口。我們可以非常方便地去訪問這些外部設備，和訪問一個文件，一個目錄沒有任何區別。例如：我們在系統中鍵入：cd /dev/cdrom 我們就可以看到光驅中的文件了。同樣道理，我們鍵入：cd /dev/mouse 就可以看看鼠標的相關文件。在這個目錄下，有一個null設備，這個東西本身沒有任何意義。如果你向這個目錄寫入文件或內容，他們統統有去無回。
/cdrom
這個目錄在你剛剛安裝系統的時候是空的。你可以將光驅文件系統掛在這個目錄下。例如：mount /dev/cdrom /cdrom
經圖像化桌面 查看其文件名 。 是cdrom光驅名錯誤造成的。。
應為 mount /dev/cdroml/ /mnt/
放一個hello的文件到Hadoop 文件系統 根目錄：
[root@hadoop local]# touch hello
[root@hadoop local]# vi hello
[root@hadoop local]# hadoop fs -put hello /
代碼：
package hadoop.jack.javacallhadoop; import java.io.InputStream; import java.net.URL; import org.apache.hadoop.conf.Configuration; import org.apache.hadoop.fs.FsUrlStreamHandlerFactory; import org.apache.hadoop.io.IOUtils; public class App1 { public static String HDFS_PATH="hdfs://hadoop:9000/hello"; /** * @param args */ public static void main(String[] args) throws Exception{ URL.setURLStreamHandlerFactory(new FsUrlStreamHandlerFactory()); final URL url =new URL(HDFS_PATH); InputStream in = url.openStream(); IOUtils.copyBytes(in, System.out, new Configuration()); } } |