用以下的方式可以监控登入登出的用户:
创建如下的两张表:
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()); } } |