软件测试是为了发现错误而执行程序的过程。 QQ： 12585990 MSN：sunxy5291@hotmail.com Fetion：575908340/15902952035

我的最新日志

  • 测试管理的能力要求，看看自己还差多少

    2008-5-05

    低层管理者不论是作为一名执行者、还是一名领导者，都必须通过别人来完成任务。要做个“服众”的经理人，应该有意识地提高以下八项能力：
    1. 领悟能力
        做任何一件事以前，一定要先弄清楚上司希望你怎么做，然后以此为目标来把握做事的方向，这一点很重要，千万不要一知半解就开始埋头苦干，到头来力没少出、活没少干，但结果是事倍功半，甚至前功尽弃。要清楚悟透一件事，胜过草率做十件事，并且会事半功倍。
    2. 计划能力
        执行任何任务都要制定计划，把各项任务按照轻、重、缓、急列出计划表，一一分配部属来承担，自己看头看尾即可。把眼光放在部门未来的发展上，不断理清明天、后天、下周、下月，甚至明年的计划上。在计划的实施及检讨时，要预先掌握关键性问题，不能因琐碎的工作，而影响了应该做的重要工作。要清楚做好20%的重要工作，等于创造80%的业绩。
    3. 指挥能力
        无论计划如何周到，如果不能有效地加以执行，仍然无法产生预期的效果，为了使部属有共同的方向可以执行制定的计划，适当的指挥是有必要的。 指挥部属，首先要考量工作分配，要检测部属与工作的对应关系，也要考虑指挥的方式，语气不好或是目标不明确，都是不好的指挥。而好的指挥可以激发部属的意愿，而且能够提升其责任感与使命感。要清楚指挥的最高艺术，是部属能够自我指挥。
    4. 控制能力
        控制就是追踪考核，确保目标达到、计划落实。虽然谈到控制会令人产生不舒服的感觉，然而企业的经
    营有其十分现实的一面，有些事情不及时加以控制，就会给企业造成直接与间接的损失。但是，控制若是操之过急或是控制力度不足，同样会产生反作用：控制过严使部属口服心不服，控制不力则可能现场的工作纪律也难以维持。要清楚最理想的控制，就是让部属通过目标管理方式实现自我控制。
    5. 协调能力
        任何工作，如能照上述所说的要求，制定完善的计划、再下达适当的命令、采取必要的控制，工作理应顺利完成，但事实上，主管的大部分时间都必须花在协调工作上。协调不仅包括内部上下级、部门与部门之间的共识协调，也包括与外部客户、关系单位、竞争对手之间的利益协调，任何一方协调不好都会影响执行计划的完成。要清楚最好的协调关系就是实现共赢。
    6. 授权能力
        任何人的能力都是有限的，作为高级经理人不能象业务员那样事事亲历亲为，而要明确自己的职责就是培养下属共同成长，给自己机会，更要为下属的成长创造机会。孤家寡人是成就不了事业的。部属是自己的一面镜子，也是延伸自己智力和能力的载体，要赋予下属责、权、利，下属才会有做事的责任感和成就感，要清楚一个部门的人琢磨事，肯定胜过自己一个脑袋琢磨事，这样下属得到了激励，你自己又可以放开手脚做重要的事，何乐而不为。切记成就下属，就是成就自己。
    7. 判断能力
        判断对于一个经理人来说非常重要，企业经营错综复杂，常常需要主管去了解事情的来龙去脉因果关系，从而找到问题的真正症结所在，并提出解决方案。这就要求洞察先机，未雨绸缪。要清楚这样才能化危机为转机，最后变成良机。
    8. 创新能力
        创新是衡量一个人、一个企业是否有核心竞争能力的重要标志，要提高执行力，除了要具备以上这些能力外，更重要的还要时时、事事都有强烈的创新意识，这就需要不断地学习，而这种学习与大学里那种单纯以掌握知识为主的学习是很不一祥的，它要求大家把工作的过程本身当作一个系统的学习过程，不断地从工作中发现问题、研究问题、解决问题。解决问题的过程，也就是向创新迈进的过程。因此，我们做任何一件事都可以认真想一想，有没有创新的方法使执行的力度更大、速度更快、效果更好。要清楚创新无极限，唯有创新，才能生存。
    领导力更需提升
        那么，怎样才能提升领导力呢？除了提高以上八项能力之外，还有最重要的两点：
    1. 学会用老板眼光看企业。
        在老板看来，管理很简单，就是两件事：一是扩大业务范围，增加业务收人；另一件事就是降低管理成本，控制运作费用。其实这两件事，最终是一件事，收入减去成本，减去费用，就是利润。所以归根到底老板是看利润的，利润要从管理中来。
    2. 从被领导中学习领导。
        在领导人看来，领导也很简单，就是两件事：一是用人，内圈用德、外圈用才，用人所长、容人所短；二是激励，解人之难、记人之功，通过正面激励，引导下属往前跑，通过负面激励，推着下属往前走。要知道，任何领导都是从做下属开始的，谁都不可能一步登天当领导。在每个人的成长过程中，你会经历大大小小许多领导，只要你用心学习，不管是好领导、还是坏领导，你都可以从正反两方面学到经验和教训，这对你将来当好领导是十分珍贵的

    查看(150) 评论(0)

  • 测试人员存在的问题归纳

    2008-2-20

     


    一、根基不牢
    问题：利用等价类划分的方法，对某问题设计测试用例。

    分析：98%以上的应聘者只知道按照有效等价类和无效等价类进行划分，殊不知此种分类方法只是等价类划分的一个典型应用而已，等价类划分远非只能划分为有效和无效两类。根据种种划分依据，还可以进一步划分很多其他类别。

    问题：根据事件描述，画出对应的因果图。

    分析：标准答案中只画了“两条恒等，两条非，一个与，一个或”。如此简单的问题，上百名应聘者中竟然无一人答对，痛心啊。黑盒测试方法就那么几种，既然你已知这个名，怎么就不知道多看几眼。

    ★ 小结：

    上面提到的是软件测试的最基本的方法，作为从业测试实际工作已经有1-2年的应聘人员，未能真正领悟，实属不应该，心浮气躁，忽视了你身边最简单，也是最厉害的技能。根基不牢，怎么可能把测试做深。

    二、专业不精

    问题：音视频文件都有哪些格式，这些格式之间有什么差别？

    分析：此问题是问那些做过多媒体方面测试的，但是我们的应聘者向来都是拿来主义，别人给我什么媒体文件我就用什么做测试，而根本不管不问。“为什么MIDI文件比WAV文件小那么多？我们如何知道扩展名是.Mpeg的文件是Mpeg1格式的还是Mpeg2格式的？”，面对这些问题，应聘者默默无语，只是无奈的笑笑。不去看别人，想想自己测试涉及的专业，是否把那个行业知识搞清楚了呢？

    问题：测试脚本运行不畅如何调试？

    分析：此问题是问那些标明自己熟练掌握WinRunner、Robot、QTP等测试工具的应聘人员，但是当真正问到他们关于脚本的具体调试时，有7成以上人员表示他们只是参加测试培训时老师讲过，或者自己在网上看过相关资料，另外有2成以上人员表示他们虽然用过，但是只是简单的录制回放，根本不会自己调试。可能是迫于无奈吧，简历里面什么都不写，可能面试的机会都没有，但是简历如此夸大的来写，终归是浪费自己的面试时间和路费。

    ★ 小结：

    从事测试仅1-2年时间，要想测试也精通，专业也精通确实不易，但是不说精通，至少也该知道个60%才对的起你的测试工作。一两年时光如此荒废，静下心来反思一下，身边还有哪些技能我们应该掌握扎实一点呢。

    三、无测试体系概念，忽视理论

    问题：请说出软件测试的定义，BUG的定义。

    分析：99%的人不能说出这两个测试名词的定义，只是在给我解释测试是为了发现bug之类的片面理解，残留的几个人也说得不够准确。这两个词目前尚不能说业内已经有了成熟统一的定义，但是无论是对是错，身为测试人员已经数年，自己竟然说不出这两个词的概念，多少也说不过去啊。有些人和我说，理论名词概念不重要，我会做测试就是了。想想金庸老先生早就告诉我们，武功仅有招式是不够的，必须配合上什么心法口诀才能行。你只会测试执行的招式，却不懂测试理论的心法，怎么能够修炼成上乘的软件测试呢？

    问题：请介绍一下你们的测试流程，流程和过程有什么不同，为什么好的测试需要好的流程？

    分析：但凡做过1、2年测试的人都能给我说出他们先做什么后做什么，但是当我继续问“这是否可以叫做过程？流程和过程有什么差别”，应聘者一棒子被打晕，继续追问“为什么好的测试需要好的流程”的时候，早已经找不到东南西北了。每天公司各项制度叫你做什么你就做什么，让你怎么做你就怎么做，完全不管不顾为什么，那么自己岂不成了没头脑的工具。这样你能干的工作别人也能做，自己的优势不就没有了吗。

    ★ 小结：

    目前测试业内流传着学院派和实践派的说法，学院派的理论给人的感觉往往是好听但不实用，而实践派的知识，往往能够立即见效。所以眼下测试培训往往实践派的更受欢迎。继续引用金庸先生的观点，练武分练内气宗，练外剑宗，但是真正的高手是内外兼修。如果我们不想只做普通的测试小弟子的话，就要理论实践并重，方能有所作为。

    四、周边知识知之甚少

    问题：能给我介绍一下软件工程中的瀑布模型吗？

    分析：又是8成应聘者不会回答，都是曾在遥远的学生时代有所耳闻，现今早已忘得一干二净了。软件测试因何而生——软件危机，软件危机导致软件工程的兴起，软件工程中又包含软件测试，就好像鱼儿活在水里，如果没有软件工程这个水，哪里能够养活这软件测试的鱼，如果我们对于身边的软件工程不够了解，怎么可能在里面自由的畅游呢。

    问题：用你最熟悉的开发语言实现sum=1+2+3+…+100

    分析：保守统计7成以上的应聘者写出来的程序无法执行或者运行结果错误，更少有人能够一气呵成，而且精准。这道编程题难吗？肯定不难，那么为何答错，自己没有真正写过程序，即使写过几行，也早就是如烟往事了。做测试一定需要懂开发吗？这个问题讨论以久，当然不一定，但是如果要做好测试，做深测试，分析问题原因，提出问题解决方案，编写测试脚本或工具，哪一个又能离开软件开发呢？

    ★ 小结：

    我们学习测试也应该有个先后顺序，有步骤。掌握周边知识的紧迫程度可能不如测试知识和行业知识。但是对于我们已经从业1-2年的测试人员来说，学校里面学到的知识不应该丢，之后的发展中，周边知识的学习也应该开始了。周边知识的范畴其实很广，还包括各种其他测试理念的学习，机械工业出版社翻译的那套测试丛书就很不错，观点众多而新颖，博众家之长，集大成，向来都是大家风范。

    五、缺乏必要的责任心、细心、耐心、虚心等

    问题：请数出下图中三角形的个数（平面图，有几根弧线做干扰）

    分析：我总是问自己，这道题真有这么难吗？连中小学生都能数对的十几个三角形，到了我们这二十几岁的年轻人手中，正确率才1%，为什么？其实就是现在我们已经很少有人能够静下心来，耐心细致的去做事情了。很多应聘者告诉我她的优点就是“踏实，坐的住，正适合这繁琐的测试工作”。我需要的不是坐在那里不做事或者做错事的人，而是需要能够按时保质量完成测试工作的测试人员。

    问题：你离职的原因？

    分析：这是面试中最常见的问题了。应聘者往往也是充分准备，理由多种多样，但是看看应聘者的工作记录统计，70%应聘者平均跳槽频率是1年/次（实习情况除外），不会都那么凑巧吧，赶上什么公司倒闭，每隔一年就会想一次自己学不到东西，需要去外面看看。而在我看来，真正的原因更多的应该是希望通过跳槽提高工资，或者因为自身水平不足被公司炒鱿鱼吧。

    ★ 小结：

    我并不认为所有的人都适合做测试。非技术素质方面，这点或者那点不足够优秀也很正常，心浮气躁也可以理解。但是作为用人单位，理解归理解，却也不会用不胜任岗位，或性价比不高的人员。那么对于此类应聘者，我的忠告就是，要么你另谋高就，要么你就放低姿态，培养好你必备的素质后再谈。

    六、缺乏诚信

    这一点本应该被归在上一条素质中，但是这点的重要性我认为远超过了上一条所列各项，因此单独提出。相关表现主要体现在：

    ○ 报自己历史工薪；

    ○ 笔试题目作弊；

    ○ 编造离职原因；

    ○ 虚报学历，工作经验；

    ○ 夸大自己工作技能等。对于严重缺乏诚信的，一旦发现，其他表现再好，也无济于事了。

    查看(141) 评论(5)

  • 测试管理学习

    2007-11-07

    一、单元测试怎么做，如何保证单元测试质量
    讨论意见：
    1、开发人员不会好好做单元测试
    2、有一个标准，规定千行代码的bug数，而已他们的unite test sepc我们也可以提意见，如如果case写的不充分，我们可以不接收的

    我的看法：
    1、单元测试本身非常繁琐、枯燥、乏味，无论是开发人员做还是测试人员做都是一样难坚持
    2、需要通过外部监督来保证单元测试的质量
    3、单元测试计划、单元测试大纲、单元测试规范、单元测试报告都需要进行严格的评审
    4、从测试用例上可以根据代码的情况规定每千行代码所对应的测试用例数，保证有足够的测试用例
    5、从测试报告上可以规定每千行代码所对应的缺陷数，保证单元测试发现了足够多的问题
    4、对集成测试、系统测试中发现的缺陷进行归纳总结，针对那些应该在单元测试阶段发现而没有发现的缺陷进行分析，帮助单元测试过程的改进和提高


    二、测试管理者如何和测试人员进行良好的沟通
    讨论意见：
    1、作为主管，不应该总是给下属安排任务
    2、平时聊聊天，不要天天谈工作，多位属下争取福利
    3、特别不能平白的帮她顶包~~! 工作上不懂，可以帮助她
    4、攻心为上，呵呵，你要和她说明，她不是为了你而工作，所以，其实不存在所谓的 谁服谁的问题
    5、管理的精髓在于对 “人”的管理，而不是“物件”
    6、不要轻易跟别人流露出你对下属的意见
    7、好话可以多说，坏话绝不能说，对谁都不能说，这是我的理解
    8、同事就是同事，永远不可能是朋友。
    9、同事之间，是一种竞争关系，朋友之间是要想互相理解互相帮助的
    10、很多人都认为开发和测试有矛盾，因为出发点不一致，所以矛盾难免产生，如果大家都是为了把软件做好，那么其实开发和测试应该是很好的伴侣
    11、我想知道的就是，领导跟下属是不是本身就存在一点距离的
    12、我打算今后增加为下属做职业规划这一行为

    我的看法：
    1、管理者和下属，工作和生活要严格区分开，工作时大家是合作关系（不同意是竞争关系^_^），生活时大家可以成为朋友
    2、管理者不是用来管理下属的，是为下属服务的，这个观念要转变，帮助下属把工作做好，帮助下属提高自己，帮助下属有更好的发展，这样才能和下属良好沟通
    3、工作时领导和下属肯定是有距离的，要做到赏罚分明，一视同仁
    4、对于不能和团队整体保持一致的下属，该出手时就出手，该拿掉的就拿掉
    5、建议大家看看曾仕强的中国式管理


    三、过程改进
    讨论意见：
    1、我现在做软件过程改进方面的工作。另外监管一下CM、QC、QA
    2、主要是过程改进了，因为过程改进与CM、QC、QA，RD都有关系，所以都涉及一些，但都不深
    3、很正常的，我们公司现在也是QA部，质量管理部，同时监管 SCM 和 测试部门，当然还有QA
    4、其实业务、销售为主导是没错的，开发和测试 是为了这个环节而展开的。
    5、这种东西都是长期才能见到效益的
    6、企业的首要目的应该就是盈利，这是终极目标，而其他的是中间过程。过程改进也是奔着这个目标而去
    7、总体的感觉是：质量、过程是重要的，但是优先级是不高的
    8、我认为市场销售和软件生产过程是一个整体，任何一个木片短了，企业的盈利情况就不容乐观
    9、没错，现在都在说过程改进，其实 人 的因素也很重要，甚至可以说是最本质的
    10、你有没有和你的上级领导沟通过？实施过CMM的人应该知道，过程的改进需要组织级的推动，自顶向下的改进。首先让公司最大的leader首肯这件事，不是敷衍，是亲力亲为

    我的看法：
    1、非常同意市场销售和软件生产是一个整体的说法，为了提高效率产生了分工，但要明确的是分工而不是分离，如果领导是技术出身，应该不会忽视开发和测试的，如果是市场和销售出身，就需要好的沟通了
    2、都说过程改进需要领导点头，从上向下推动，其实过程改进还是要靠QA去推动，至于从上向下，还是从下向上都不是最重要的。
    3、不要想一下子就进行大刀阔斧的过程改进，先从容易入手、见效快的地方入手，上下见到了立杆见影的效果，自然会支持，领导不会无缘无故支持一个他看不到任何效果的改进
    4、过程改进整体而言是见效慢，但也有见效快的地方，这些就是比较好的过程改进切入点


    四、如何针对测试项目考虑测试
    讨论意见：
    1、看来你们还是比较幸福的，我们公司好多项目都是突发的，没有任何可以计划
    2、更讨厌的是，我们的测试任务还会临时调度下来不得不接
    3、没有计划没有文档所进行的测试，应用在V模型上确实显得特别的捉襟见肘
    4、就是针对不同的实际情况作出的反应以及处理方法
    5、举个例子，你现在有一个测试项目需要你负责测试，第一步你会做什么呢？指定测试计划，人力，设备，等等。第二步你会做哪些工作呢？熟悉设计文档，编写test spec
    6、其实在没有文档的情况下，我比较推崇XP的结对概念，不过我把它扩大了，XP里说，结对编程，而我认为应该 “凡事皆结对”，结对测试，结对管理
    7、我们公司从代码走查中想到进行用例走查
    8、在没有文档的时候，结对工作可以弥补文档不足带来的致命后果
    9、其实你可以这样想：为什么要结对？一个人做事容易错，容易把方向搞错；两个人会好很多。当然，这不是绝对的。一个泛泛之谈
    10、那你清楚你为什么选择在第二步去熟悉设计文档，编写测试用例呢，而不是选择研究软件需求和同类型的软件功能呢

    我的看法：
    1、无论是什么项目，不管是计划好的，还是突发的，做测试都应该有计划，这个计划既可以形成文档也可以存在于人的大脑里
    2、没有文档的测试和有文档的测试没有本质的区别，只不过后者需要寻找其它的方式来了解被测的对象到底要做成什么样了
    3、突发的测试任务，对测试负责人提出了更高的要求，他需要尽快确定如何来进行测试，确定测试策略，比如时间紧迫是采取基于风险的测试策略呢还是说采取探索式的测试策略，当然不同的测试阶段有不同的测试策略选择了
    4、不管是一个人测试还是结对测试，对被测对象信息的掌握都是一样重要的，对被测对象的原型越了解越有可能测试的更好，所以大家就不要局限在是做白盒测试还是黑盒测试还是灰盒测试的概念问题上了
    5、走查是静态测试的一种形式，任何阶段都可以使用
    6、即使是做单元测试，需求文档和设计文档一样都是要看的
    7、测试时即使只有设计文档没有真正的代码也一样可以“运行”软件，那就是在纸上进行，国外进行一些设计的评审时测试工程师就经常采用这种方式，在白板上让开发人员对每一个“运行”流程进行确认

    查看(105) 评论(0)

  • CVS使用速成配置 ---我给公司搭建CVS服务器就是参照这个的

    2007-8-06



    一 CVS服务器的安装：
    1    。查看你的操作系统上是否安装了CVS：
    #> rpm -qa|grep cvs

    如果没有安装你可以在Redhat 第2张光盘上找到，另外你也可以在网上下载到最新的rpm包。很容易找，其实不存在什么linux版本。

    2    。建立cvs用户组：

    #> groupadd cvs

    3    。建立cvs组的cvsroot用户和所属的目录：

    #> useradd -g cvs -G cvs –d /cvsroot cvsroot

    4    。为cvsroot用户添加密码：

    #> passwd cvsroot

    5    。改变 /cvsroot/ 的目录属性：

    #> chmod –R 770 /cvsroot

    6    。改变用户登陆身份：

    #> su cvsroot

    7    。开始创建单个项目：

    #> cd /cvsroot
    #> mkdir project1
    #>mkdir project2
    8    。开始建立仓库：

    #> cvs –d /cvsroot/project1 init
    #> cvs –d /cvsroot/project2 init
    #> chmod –R 770 ./project1/ ./project2/

    9    。建立CVS服务启动文件，我们使用xinetd方式：

    #> [Crtl]+[d]     切换到root用户身份
    #> cd /etc/xinetd.d
    #> vi cvspserver

    service cvspserver
    {
    disable = no
    flags = REUSE
    socket_type = stream
    wait = no
    user = root
    server= /usr/bin/cvs
    server_args= -f --allow-root=/home2/cvsroot/project1 --allow-root=/home2/cvsroot/project2 pserver log_on_failure += USERID
    }

    注：由于xinetd的server_args长度限制,当你想运行很多的单个仓库的时候,可以这么做：

    #> vi cvspserver

    service cvspserver
    {
    disable = no
    flags = REUSE
    socket_type = stream
    wait = no
    user = root
    server = /cvsroot/cvs.run
    log_on_failure += USERID
    }

    编写cvs.run脚本

    #> vi /cvsroot/cvs.run

    #!/bin/bash
    /usr/bin/cvs -f
    --allow-root=/cvsroot/project1
    --allow-root=/cvsroot/project2
    pserver

    #>chmod +x /cvsroot/cvs.run

    10    。加入cvs服务：

    #>vi /etc/services

    cvspserver 2401/tcp #pserver cvs service
    cvspserver 2401/udp #pserver cvs service
    11    。启动cvs服务：

    #> /etc/init.d/xinetd restart

    12    。检查cvspserver服务是否已经启动：

    #> netstat -l |grep cvspserver
    应该有如下结果：

    tcp 0 0 *:cvspserver *:* LISTEN

    二。CVS服务的用户管理：

    上面我们已经建立了project1和project2两个CVS仓库，下面我们分别给两个仓库建立cvs用户。

    13    。创建可以登陆cvs服务器的用户名和密码：

    #> su cvsroot
    #> vi /cvsroot/project1/CVSROOT/passwd

    trotter:*****:cvsroot
    mimi:*****:cvsroot

    #>vi /cvsroot/project2/CVSROOT/passwd

    trotter:*****:cvsroot
    gary:*****:cvsroot

    这两个文件的意思是有trotter，mimi，gary三个cvs用户，mimi拥有project1的使用权限，gary拥有project2的使用权限，trotter拥有project1和project2的使用权限。登陆后的权限是cvsroot权限。
    注意：这里的cvs用户和系统用户是不同的。

    14    。*****为密码，由以下文件生成：

    #> vi /cvsroot/passwd.pl

    #!/usr/bin/perl
    srand (time());
    my $randletter = "(int (rand (26)) + (int (rand (1) + .5) % 2 ? 65 : 97))";
    my $salt = sprintf ("%c%c", eval $randletter, eval $randletter);
    my $plaintext = shift;
    my $crypttext = crypt ($plaintext, $salt);
    print "${crypttext}
    ";

    #>chmod a+x /cvsroot/passwd.pl

    15    。如果你想生成一个密码是“123456”，则：

    #> /cvsroot/passwd.pl “123456”

    回车即可得到加密密码,用其替换passwd文件中的    *****

    16    。Ok，cvs现在已经全部安装完成了，如果你想让一个用户拥有project1的权限，你就在 /cvsroot/project1/CVSROOT/passwd中给他加入一个用户；如果你想让一个用户同时具有project1和project2 的权限，你就给/cvsroot/project1/CVSROOT/passwd和/cvsroot/project2/CVSROOT/passwd 里给他加一个用户名和密码相同的用户即可。最后，我们试用一下：

    #> cvs -d :pserver:trotter@192.168.1.200:/cvsroot/project1 login

    敲入命令回车后提示输入trotter的密码,你按照自己设置的密码输入,如果没有什么错误信息出现就是成功了(我的机器IP地址是    192.168.1.200)




    ***CVS    服务器建立和权限配置



    建立一个源代码库主要有以下几步：

    （1）初始化cvs服务器环境。
    #cvs -d/usr/local/source init
    之后进入/usr/local/source，可以看到有一个目录CVSROOT, 下面是初始化后的CVS服务器配置文件。暂且保持不动。

    （2）把cvs服务放到xinetd系统服务中。
    首先在/etc/xinetd.d目录下生成任务配置文件cvspserver，文件名称可以随便用。

    其中内容大致如下：

    service cvspserver
    {
    flags = REUSE
    socket_type = stream
    wait = no
    user = root
    protocol = tcp
    server = /usr/bin/cvs
    server_args = -f --allow-root=/usr/local/source pserver
    disable = no
    }



    其中server_args一个参数指定了源代码库路径，一个指定了服务器使用密码认证方式。
    第二，要确认/etc/services文件中，有cvspserver关键词，并分配了端口，如：cvspserver 2401/tcp。
    第三，重新启动xinetd服务，cvs服务就可以用了。

    （3）测试。假定cvs服务器在192.168.0.205上，系统上有一个用户cvs。登陆另一台linxu机器，执行下列命令可以完成测试：
    $export CVSROOT=:pserver:cvs@192.168.0.205:2401/usr/local/source
    $cvs login
    输入密码，没有出错提示表示登陆成功。

    如果想在一个linux系统上建多个源代码库，分别提供cvs服务。重复上面步骤就可以了。

    第一步时候要注意使用一个不同路径。
    第二步放到xinetd系统服务中稍微麻烦点。/etc/xinetd.d目录下要生成一个新的任务配置文件，例如cvspserver1，文件中service名称一定要区分第一个，例如service cvspserver1，server_args做相应变动。还要在/etc/services文件中，加入新的服务端口号，例如： cvspserver1 2402/tcp。重新启动xinetd服务    .

    第三步测试时候，可以这样设定：
    $export CVSROOT=:pserver:cvs@192.168.0.205:2402/usr/local/source1
    ......

    查看(134) 评论(0)

  • linux基本命令（培训新人而整理）

    2007-7-04

    linux基本命令


    --------------------------------------------------------------------------------
    ls
    这个命令就相当于dos下的dir命令一样

    ls -a

    Linux上的文件以.开头的文件被系统视为隐藏文件，仅用ls命令是看不到他们的，而用ls -a除了显示 一般文件名外，
    连隐藏文件也会显示出来。

    ls -l（这个参数是字母L的小写，不是数字1,这个命令最常用）

    这个命令可以使用长格式显示文件内容，如果需要察看更详细的文件资料，就要用到ls -l这个指令。

    ls –F（注意，是大写的F）

    使用这个参数表示在文件的后面多添加表示文件类型的符号，例如*表示可执行，/表示目录，@表示连结文件

    cd
    这个命令是用来进出目录的，它的使用方法和在dos下没什么两样

    mkdir、rmdir
    mkdir命令用来建立新的目录，rmdir用来删除以建立的目录，这两个指令的功能同dos下的md,rd功能和用法都是基本一样的。

    cp
    这个命令相当于dos下面的copy命令，具体用法是：cp –r 源文件(source) 目的文件(target)
    参数r是指连同元文件中的子目录一同拷贝。

    rm
    这个命令是用来删除文件的，和dos下面的rm（删除一个空目录）是有区别的，大家千万要注意。rm命令常用的参数有三个： -i,-r,-f。
    比如我现在要删除一个名字为text的一个文件：rm –i 123
    系统会询问我们：“rm:remove ‘123’?y”，敲了回车以后，这个文件才会真的被删除。
    rm –r 目录名：这个操作可以连同这个目录下面的子目录都删除，功能上和rmdir相似。
    rm –f 文件名（目录名）：这个操作可以进行强制删除。
    rm -rf 文件名（目录名）：这个操作可以进行强制删除带有子目录的目录，一般轻易不要操作该命令。

    mv
    这个命令的功能是移动目录或文件，引申的功能是给目录或文件重命名。它的用法同dos下面的move基本相同。当使用该命令来移动目录时，他会连同该目录下面的子目录也一同移走。另外因为linux下面没有rename的命令，所以如果你想给
    一个文件或目录重命名时可以用以下方法：mv 原文件（目录）名 新的文件（目录）名。

    du，df
    du命令可以显示目前的目录所占的磁盘空间，df命令可以显示目前磁盘剩余的磁盘空间。

    cat
    这个命令是linux中非常重要的一个命令，它的功能是显示或连结一般的ascii文本文件。

    more,less
    这是两个显示一般文本文件的指令。如果一个文本文件太长了超过一个屏幕的画面，用cat来看实在是不理想，就可以试试more和less两个指令。

    clear
    这个命令是用来清除屏幕的，它不需要任何参数，和dos下面的clr具有相同的功能。

    pwd
    这个命令的作用是显示用户当前的工作路径。

    man
    Man实际上就是察看指令用法的help。

    logout
    这是退出系统的命令。

    查看(111) 评论(0)

  • 测试管理最佳实践

    2007-6-20

    导言
            软件质量一个很重要的部分就是测试和验证软件有效性的流程。这篇文章的目的是介绍相关的概念，并提供测试管理领域常用的最佳实践。测试管理是组织和控制测试工作所需的流程和工件的实践。这篇文章探讨的是IBM® Rational® ClearQuest®, IBM® Rational® ClearCase®以及IBM® Rational® Requisite Pro®如何提高测试水平。
    导言

    目的

            很少人会反对提高软件开发质量的需求。使用软件的技术人员已经开始预估各种各样的故障和缺点，特别是在个人计算机世界里，我们认为频繁出现问题是完全正常的并且在意料之中。尽管如此，随着软件开发日趋成熟，我们开始对如何在质量方面作出必要改进有了进一步的理解。这篇文章的目的是介绍相关概念，并提供测试管理领域常用的最佳实践。

    什么是测试管理？

            软件质量一个很重要的部分就是测试和验证软件有效性的流程。测试管理是组织和控制测试工作所需的流程和工件的实践。用于测试管理的传统工具包括：

                       笔和纸
                       字处理程序
                       电子数据表

            更大的测试工作可以使用自己开发的软件测试管理解决方案，通常建立在电子数据表或数据库或者像 IBM® Rational® ClearQuest® Test Manager 或者 Mercury TestDirector 这样的商业测试管理应用软件的基础之上。

            测试管理的整体目标是允许团队在整个软件开发工作里计划、开发、执行并评估所有的测试活动。这包括调整测试工作中包含的所有工作，跟踪测试资产中的依赖关系和相互关联，并且最重要的是对质量目标进行定义、测量和跟踪。


    测试管理的各个方面

            测试管理可以被分成几个不同的阶段：组织、计划、创作、执行以及报告。这些在下面有更详细的描述。

            测试工件和资源组织是测试管理中显然必不可少的部分。这需要组织和维持测试项目的详细目录，以及用来执行测试的各类事物。这表现了团队如何跟踪测试资产中的依赖关系和相互关联。需要管理的测试资产中最普遍的类型是：

                       测试脚本
                       测试数据
                       测试软件
                       测试硬件

            测试计划是回答为什么测试、测试什么、在哪里测试和什么时间测试这些问题的全部任务设置。创建一个特定测试的原因被称作一个测试激发因素（例如，必须确定一个特定的必要条件）。为了一个项目需要被测试的内容被分成许多的测试用例。在哪里测试通过决定和记录所需的软件和硬件配置来回答。什么时间测试通过跟踪测试的迭代（或者循环，或者时间周期）来解决。

            测试创作是获得完成给定测试所需特定步骤的过程。它回答了如何测试的问题。这里是一些稍微抽象的测试用例被分成更详细的测试步骤的地方，这些步骤将变成测试脚本（要么是人工生成，要么自动生成）。

            测试执行通过将测试脚本的顺序集合成测试套件来运行这些测试。这是对如何测试这一问题的后续回答（更为准确地说，是如何管理这些测试）。

            测试报告是指如何对测试工作的不同结果进行分析和沟通。这用来决定项目测试的当前状态和应用软件或系统的质量的整体水平。

            测试工作将产生大量的信息。在这些信息里，可以提取为项目定义、度量及追踪质量目标的方法。不管使用什么沟通机制，这些质量度量方法需要被传递给其他项目作为测试度量的基础。

            测试产生的一个非常普通的数据类型是缺陷，它通常是质量度量方法的来源。缺陷不是静态的，而是随着时间在变化。此外，多种缺陷总是互相关联的。有效的缺陷跟踪对测试和开发团队来说都是十分重要的。

    测试管理中的其他因素

            除了软件和硬件测试工件和资源以外，必须管理 测试团队。测试管理必须调动致力于团队工作的所有团队成员的积极性。这需要对测试人员和工件控制 用户安全和进入许可。对于那些跨越一个或更多场所或团队的项目（这将迅速成为规范）来说，这也包括组织场所和团队协调。

            一个项目的特定测试流程对于测试管理来说意义十分明显。对于一个迭代的项目，测试管理将必须提供基础并重复地指导计划、执行和测试评估。而后，测试策略也将必须遵循测试管理框架。

    相关的软件开发规程

            虽然软件开发中所有的过程都与测试相关联，有几个与测试的关系尤为重要：

                        需求管理
                        变更管理
                        配置管理

            需求管理是大多数测试工作的先驱，提供了大量的测试动机和确认需求。一个项目特定的需求管理流程对测试管理流程有重要影响。这种关系类似于一场接力赛，第一个跑的人代表着需求管理，下一个接受接力棒的人代表测试管理。IBM® Rational® RequisitePro®是发现、记录、组织和跟踪需求说明的工具。更多的信息可以在 IBM® developerWorks® Requisitepro 资源页面上找到。

            变更管理影响软件开发的全部过程，但是被跟踪的与测试工作最相关的变更是缺陷。缺陷是测试与开发之间最常见的主要通信渠道。从缺陷得出的计算和方法也经常被用作质量度量方法。ClearQuest 是一种贯穿整个软件开发周期中用于管理诸多类型的变更和活动的强大的、高可配置的工具。更多的信息可以在 IBM® developerWorks® ClearQuest 资源页面上找到。

            配置管理对于测试管理来说很重要，因为在什么时候对哪一个要测试的版本进行跟踪对测试来说至关紧要。配置管理为测试执行控制着由测试管理跟踪的工作版本和环境。IBM® Rational® ClearCase® 是主要的配置管理工具。更多的信息可以在 IBM® developerWorks® Clearcase 资源页面上找到。


    测试管理的挑战

            总结测试管理目标的一个方法是回答下面的问题：

                      为什么我应该测试？
                      我应该测试什么？
                      我在哪里测试？ 
                      我什么时候测试？
                      我如何指导测试？

            从高层次的角度来看，这可能十分简单，但是在典型的软件开发中总会出现许多障碍。下面详细描述这些挑战。

    没有足够的时间来测试

            除了某些专门的或者任务十分重要的应用程序外，很少的软件项目在开发周期里拥有充足的时间完成高水平的质量度量。通常情况是，软件工程里本来就很短的“测试周期”总是不可避免地会被耽搁。即使是最好的项目也很有可能在测试工作上面临时间限制。在测试管理中这种障碍的影响是不断变换优先级，不断转换工作以及为测试结果和质量检测方法简化数据。

    没有足够的资源来测试

            除了缺少时间外，通常在取得执行必要的测试所需的合适资源方面也面临困难。资源可能被其他工作或项目分享。虽然测试的硬件资源会带来延迟和困难，但是人力资源的缺乏可能更加难以解决。在测试管理中这种障碍的影响和时间缺乏造成的影响大致相同。

    测试团队并不是总在一个地方

            这段时期更经常的情况是测试资源可能可以获得，但是它们不在同一个地方。在各地区协调人力以降低成本已成为家常便饭，但是这造成相当多的技术障碍。在另一区域的团队如何共享工件并保持协同合作，并不会造成延迟和影响整个团队的和谐？一个项目如何能将区域分布式开发的效率发挥到极至呢？

    需求方面的难题

            虽然有许多的测试策略，但是确认需求是需要完成的最主要的、优先级最高的测试工作。做到这一点需要完整的、明确的和可测试的需求。不够完美的需求管理会导致测试工作中更大的问题。使用像 RequisitePro 这样的工具可以帮助极大地提高需求管理并促进有效需求的开发。

            对于有效的测试管理来说，必须有对于最新系统变更和业务需求的无缝接口。这种接口必须不只是针对需求的描述，也要针对优先级、状态和其他属性。此外，这需要开发需求说明的团队和执行测试的团队之间最大限度的协调分工和沟通。这种沟通必须在确保质量的所有方面进行。

    与开发保持同步

            软件质量所需的另一种团队协作存在与测试人员与开发人员之间的。除了关键缺陷之外，软件开发中总有一个惯例，那就是测试团队的工作只有测试人员关注。尽管如此，对于每一个人，特别是对开发人员来说了解当前的质量水平以及哪些已经被测试、哪些还没有被测试是十分重要的。

            为了有效地使用他们的宝贵时间，测试团队必须跟上不断变化的代码、工作版本和环境。测试管理必须精确识别要测试的工作版本和测试的合适的环境。测试错误的工作版本（或功能）会导致时间的浪费，并严重地影响项目进度。测试人员必须也了解什么缺陷是已知的，不需要重新测试的以及哪些是需要确定的。而后测试人员必须将已发现的缺陷以及促进解决方案的充分信息提供给开发人员。

    报告正确信息

            如果能够为项目传达测试状态和一些质量评定标准，测试工作只是有用的。得出报告十分简单，但是提供恰当的信息（在合适的时间，为合适的人）是更加由意义的，主要有以下的原因：

            如果只有非常少的信息，那么除了对测试团队来说减少了感知缺陷的价值外，项目涉众将不能充分了解影响质量的问题。
            如果有过多的信息，那么主要信息的意义和影响就变得模糊。
            在如何将信息与不同地方的不同角色分享上总是有技术障碍。
            报告结果的另一个需要考虑的事项是如何安排信息以及以采用什么形式（也就是说，信息是基于工具的、基于浏览器的还是基于文件的形式）。如果有技术上或者其他限制报告的安排或形式上的约束，项目涉众对于测试和质量信息的了解将被减少。数据应该以一种清晰有逻辑的设计方式呈现出来，表示适当的意义，而不是以受局限的工具或技术的方式。因此对于项目管理来说在提供宽泛的报告格式方面考虑适应性和接受力的需要是十分重要的。

    什么是质量度量？

            测试团队的一个主要目标是评估并决定质量，但是如何准确地度量质量呢？有许多的方法可以实现，而且根据系统或应用软件的类型和开发项目的特殊性分为很多不同的种类。为了避免曲解，任何一个质量度量方法都是需要清晰明确的。更重要的是，测试方法必须可以获取和保存，否则它们可能不值得花费成本或者可能是不完整或者不准确的。


    测试管理的建议

            下面是可以提高软件测试管理的一般建议。

    尽早开始测试管理活动

            虽然这一点看起来像最显而易见的建议，但是很少软件项目真正地应用这一观念。在早期开始确定测试资源很容易而且很常见，但是许多测试分析（如识别关键的、优先的测试用例）可以而且应该尽快开始。一旦用例被充分开发产生事件流，就可以得到测试程序。如果一个项目没有使用用例需求，那么仍可以从确认初始需求说明中得到测试。尽快开发测试能帮助减轻未来不可避免的时间限制。

    迭代化测试

            软件测试应该是一个反复的过程，在整个项目周期的早期生成有价值的测试工件和工作。这是遵循尽早开始测试流程的首要建议：一个迭代的测试流程应该很早就关注测试管理。测试管理通过组织迭代的各类工件和资源来指导这一点。这个基于风险的方法有助于确保以最有效的方式处理项目时间线里可能出现的变更、延迟和其他一些不可预见的障碍。

    重用测试工件

            在一个项目或多个项目里重用测试工件能够极大地提高测试团队的有效性。这样可以极大地缓解时间和资源有限造成的压力。可以重用的工件不仅包括自动操作测试对象，还包括测试程序和其他的计划信息。为了有效地重用工件，测试管理必须在组织和描述给定项目的与测试相关的各种信息方面做得很好。在创建工件时，重用总是需要一些预先计划，而且这一原则通常可以应用于测试管理。

    使用基于需求的测试

    测试可以被分成两种常用的方法：

                          确认事情按照计划进行
                          尽力找出什么使得事情停止下来

            虽然后面的探索性测试对于发现导致错误的难以预测的场景或情形来说非常重要，但是确认基本的需求可能是测试团队执行的最重要的评估。

            基于需求的测试是确认一个应用软件或系统的主要方式，它既适用于传统需求也适用于用例需求。基于需求的测试往往没有探索性测试那么主观，它也可以带来其他的益处。软件开发团队的其他部分可能质疑或者谴责探索性测试的结果，但是他们不能怀疑直接确认需求的测试。另一个好处是它可以更容易地计算所需的测试工作（与探索性测试相反，它总是受限于可以利用的时间）。

            它也可以提供各类统计数据，他们可能是有用的度量，例如测试覆盖率。测试用例是由需求产生的，并且随着事情变化对其关系的跟踪也更为重要，这是一件复杂的工作，应该通过工具进行处理。RequisitePro 和 ClearQuest 中的测试管理能力提供了满足这一需求的结果方案。

            这一流程的局限性是它信赖于一个好的系统需求和一个十分有效的合理的需求管理计划。从另一方面来说，探索性测试可能更加特殊。它很少依赖软件开发团队的其他部分，这有时会导致测试工作很少被关注在确认需求的重要任务上。虽然较好的测试工作应该将不同的方法集成起来，但是不应该忽视基于需求的测试。

    协调远程测试资源

            为了避免资源不足或者只是为充分利用人员，您应该协调可以运用的任何资源，不管它们在什么地方。这些重要的资源很可能存在于多种区域，通常在不同的地方。这需要仔细有效的协同合作使得各地区的大多数测试人员和其他人参与到测试管理中。为了使之生效可能有相当多的技术挑战，因此需要适当的处理。ClearQuest 的 MultiSite 版本的测试管理能力能够帮助简化区域分布式测试协调的复杂度。

            我应该使用 Web 客户还是自动复制的数据呢？有两种解决方案使得相距较远的参与者能够协同工作。前者简单并且相对容易，但是如果从各地进行访问，仍有网络方面的潜在约束。对于受到人员或者功能限制的远程访问来说，这是一个好的解决方案。但是，对于由许多不同地方的人组成一个测试团队的情况，您需要具有复制到本地服务器上的数据使得他们的运行速度达到最大化。这也意味着您将需要一个简单无缝的方式使得每个地方的数据自动同步。这是 ClearQuest MultiSite 对于测试管理来说十分重要的地方。

    定义并执行灵活的测试流程

            一个好的、可重复的流程能够帮您了解项目的当前状态，并通过预测了解其趋势。尽管如此，不同的项目对测试工作将有不同的特定需要，因此使得工作流程自动化的测试管理流程需要是灵活的并且可以定制的。流程应该是可重复的（为了提供预测），但是更重要的是，它必须允许改进。它必须使得修正十分容易，包括在迭代项目过程中的调整，因此它可以通过改变需要使其达到最优。

            如果不能以任何方式执行，那么定义一个指导团队成员的带有工作流程的过程意义并不大。需要怎样的力度来执行根据不同的企业和项目而有所不同。许多企业的软件项目需要遵循不同的法规，如 SOX 和 HIPPA。有些需要变更审核、项目历史和其他像电子签名等严格的遵守确认。不管您的项目测试管理需要严格地执行流程还是有更多的临时选择，您都需要一个机制来定义和执行某些事情。像 ClearQuest 这样测试管理工具是能够提供测试管理所需的所有能力。

    调整并整合开发的剩余部分

            从传统意义来看，软件测试与开发的其他部分是严格分开的。这样做部分源于保持评估公正和有更多的机会发现开发中可能没有察觉的缺陷的合理需要。这一需要在验收测试中尤为明显，因为在验收测试中最好的测试人员往往对设计和执行因素缺乏判断力。尽管如此，这种特定需要仅仅代表软件测试中的一个方面，不应该对最终要进行的软件质量开发制造障碍。

            软件测试必须与软件开发的其他部分结合起来，特别是像需求管理和变更管理这样的规程。这包括不同的流程角色和活动之间重要协作、重要信息的高级沟通以及支持这一点的集成工具。没有这些协同分工，质量将会由于缺少或误解需求、没有测试代码、没有发现缺陷和缺少关于现行软件质量水平的信息而降低。

    沟通状态

            工作的价值等取决于它被认知的程度，而工作如何被认知取决于传递给涉众的信息。好的测试管理必须提供所有相关信息的完整和正确的报告。在软件开发项目里实时状态、目标的测量方法以及结果应该提供给所有相关的团队成员。

            报告应该不仅仅只是传统意义的静态文件。假定变化是持续的，为了准确地交流信息需要有多种形式的易更新的输出。所有这些会帮助不同的项目角色在随着项目的进展对变化如何做出反应方面做出正确的决策。

            来自不同的软件规程的信息不是完全独立的。这篇文章已经提到了测试管理和其他像需求、变更和配置管理和开发这样的规程之间的重要关系。因此来自测试管理的输出可以很容易地与其他项目数据结合起来是至关重要的。当前的技术使得将所有的项目方法结合成为统一视图成为可能，这样可以确定所有项目的健康状态。工具也使得清楚地展示和评估测试、开发和其他项目工件的关系成为可能。

    关注目标和结果

            为项目确定质量目标并决定如何有效而准确的测量这些目标。测试管理是详细说明目标、用于测量这些目标的方法以及将如何收集这些数据的地方。测试中许多工作可能没有明显的完成标准。定义正在进行的流程和变更的特定输出和测量方法将更详细地说明测试工作的活动和任务。牢记测试的特定目标和测试方法不仅有助于跟踪状态和结果，还能避免最终将所需报告混在一起。

            在一个单一的、公共的知识库或数据库储存测试管理的结果以确保更加容易地对他们进行分析或使用。这也促进了工件（包括工作）的版本控制，避免出现过时或无效信息的问题。这一切将有助于项目成员了解流程并在测试工作的基础上做出决策。

    通过自动化来节约时间

            测试管理的内容有很多，而且许多工作非常耗时。为了节约时间，可以使用工具让许多工作自动化，或者至少半自动化。虽然像字处理程序和电子数据表这样的简单的工具提供了很大的灵活性，但是专门用于测试的自动化工具更加有效，更加有助于节约时间。通过自动化收益极大的工作包括：

                           跟踪需求测试和其他测试激发因素的关系
                           组织和重用测试用例
                           记录和组织测试配置 
                           计划和协调各种工作版本和应用软件的测试执行
                           计算测试覆盖率
                           各种各样的报告工作 
                           在测试管理中对适当工作的使用工具以使其自动化将极大地提高其价值和收益。
     

     

    总结

            提高软件质量的一个重要步骤是超越旧的和基于文档的方法，并促进测试管理实践。测试管理包含各种功能，包括计划、创作、执行和报告测试，以及如何使测试并与软件开发工作的其他部分结合起来。对于测试管理来说有许多令人生畏而且不可避免的挑战，如缺乏时间和资源、测试团队分布在相距较远的地方、将测试与需求和开发相结合的问题以及报告正确的信息。

            好消息是有大量的最佳实践可以有助于应对这些挑战。尽早地并重复地进行测试活动、把重点放在目标和结果上以及协调并整合开发的其他部分，将使得测试工作不会成为对软件的事后弥补工作。充分地重用测试工件、协调距离较远的测试资源、定义并执行一个灵活的测试过程以及自动化都有助于克服资源的局限。

            一个可以实现这些实践的工具是 ClearQuest 中的测试管理功能。它直接满足了许多特定的技术需要，例如：通过 ClearQuest MultiSite 与远方团队一起工作。它也为创建满足任何项目或组织需要的正确测试管理解决方案提供了一个灵活的框架。

    查看(72) 评论(0)

  • cvs服务器端配置（笔记整理）2007.6.20

    2007-6-20

    先查看Linux服务器操作系统上是否安装了CVS
    [root@localhost /]# rpm -qa|grep cvs
    如果没有安装你可以在Redhat 第2张光盘上找到，另外你也可以在网上下载到最新的rpm包。很容易找，其实不存在什么linux版本
     
    建立cvs用户组
    [root@localhost home]# groupadd cvs

    建立cvs组的cvsroot用户和所属的目录
    [root@localhost home]# useradd -g cvs -G cvs –d /cvsroot cvsroot

    为cvsroot用户添加密码
    [root@localhost home]# passwd cvsroot

    改变 /cvsroot/ 的目录属性：
    [root@localhost home]# chmod –R 770 /cvsroot

    改变用户登陆身份
    [root@localhost home]# su cvsroot

    以下开始正式建立项目
    [root@localhost /]# cd /home/cvsroot/egov/
    [root@localhost egov]# su cvsroot
    [cvsroot@localhost ~]$ mkdir projectsxy
    [cvsroot@localhost ~]$ ls -l

    ...
    drwxrwx---  4 cvsroot cvs 4096  6月 19 14:00 OAchanp
    drwxr-xr-x  2 cvsroot cvs 4096  6月 20 15:23 projectsxy
    drwxrwx---  4 cvsroot cvs 4096  6月 19 14:12 qiyjcxx
    ...
    [cvsroot@localhost ~]$ cvs -d /home/cvsroot/egov/projectsxy/ init
    [cvsroot@localhost ~]$ chmod -R 770 projectsxy/
    [cvsroot@localhost ~]$ ls -l

    ...
    drwxrwx---  4 cvsroot cvs 4096  6月 19 14:00 OAchanp
    drwxrwx---  3 cvsroot cvs 4096  6月 20 15:24 projectsxy
    drwxrwx---  4 cvsroot cvs 4096  6月 19 14:12 qiyjcxx
    ...
    [cvsroot@localhost ~]$ cd projectsxy/
    [cvsroot@localhost projectsxy]$ ls -l

    drwxrwx---  3 cvsroot cvs 4096  6月 20 15:24 CVSROOT
    [cvsroot@localhost projectsxy]$ exit
    [root@localhost egov]# vi /etc/xinetd.d/cvspserver
    按i进入到编辑
    service cvspserver
    {
    disable = no
    flags = REUSE
    socket_type = stream
    wait = no
    user = root
    server = /usr/bin/cvs
    server_args = -f --allow-root=/home/cvsroot/egov/test --allow-root=/home/cvsroot/egov/projectsxy pserver
    log_on_failure += USERID
    }


    ~
    ~
    ~
    ~
    -- 插入 -- 
    编辑完后Shift+：
    ：wq 保存退出   

    [root@localhost egov]# cd projectsxy/
    [root@localhost projectsxy]# ls -l
    总用量 8
    drwxrwx---  3 cvsroot cvs 4096  6月 20 15:24 CVSROOT
    [root@localhost projectsxy]# cd CVSROOT/
    [root@localhost CVSROOT]# ls -l
    总用量 192
    -rwxrwx---  1 cvsroot cvs  495  6月 20 15:24 checkoutlist
    -rwxrwx---  1 cvsroot cvs  698  6月 20 15:24 checkoutlist,v
    -rwxrwx---  1 cvsroot cvs  760  6月 20 15:24 commitinfo
    -rwxrwx---  1 cvsroot cvs  963  6月 20 15:24 commitinfo,v
    -rwxrwx---  1 cvsroot cvs  991  6月 20 15:24 config
    -rwxrwx---  1 cvsroot cvs 1194  6月 20 15:24 config,v
    -rwxrwx---  1 cvsroot cvs  602  6月 20 15:24 cvswrappers
    -rwxrwx---  1 cvsroot cvs  805  6月 20 15:24 cvswrappers,v
    -rwxrwx---  1 cvsroot cvs 1025  6月 20 15:24 editinfo
    -rwxrwx---  1 cvsroot cvs 1228  6月 20 15:24 editinfo,v
    drwxrwx---  2 cvsroot cvs 4096  6月 20 15:24 Emptydir
    -rwxrwx---  1 cvsroot cvs    0  6月 20 15:24 history
    -rwxrwx---  1 cvsroot cvs 1168  6月 20 15:24 loginfo
    -rwxrwx---  1 cvsroot cvs 1371  6月 20 15:24 loginfo,v
    -rwxrwx---  1 cvsroot cvs 1151  6月 20 15:24 modules
    -rwxrwx---  1 cvsroot cvs 1354  6月 20 15:24 modules,v
    -rwxrwx---  1 cvsroot cvs  564  6月 20 15:24 notify
    -rwxrwx---  1 cvsroot cvs  767  6月 20 15:24 notify,v
    -rwxrwx---  1 cvsroot cvs  649  6月 20 15:24 rcsinfo
    -rwxrwx---  1 cvsroot cvs  852  6月 20 15:24 rcsinfo,v
    -rwxrwx---  1 cvsroot cvs  879  6月 20 15:24 taginfo
    -rwxrwx---  1 cvsroot cvs 1082  6月 20 15:24 taginfo,v
    -rwxrwx---  1 cvsroot cvs    0  6月 20 15:24 val-tags
    -rwxrwx---  1 cvsroot cvs 1026  6月 20 15:24 verifymsg
    -rwxrwx---  1 cvsroot cvs 1229  6月 20 15:24 verifymsg,v
    [root@localhost CVSROOT]# su cvsroot
    [cvsroot@localhost CVSROOT]$


    [cvsroot@localhost CVSROOT]$ vi passwd
    按i进入到编辑
    sunxiaoyong:ENSlmPaH.nb2Q:cvsroot
    ~
    ~
    ~
    ~
    -- 插入 --                                                                                                        0,1          全部

    上边密码得来是在另外打开一个窗口进行密码生成:
    [root@localhost ~]# cd /
    [root@localhost /]# /home/cvsroot/passwd.pl "sunxiaoyongprojectsxy"
    ENSlmPaH.nb2Q [root@localhost /]#    

    ......
    最后从客户机建立名称为projectsxy的项目并使用cvs客户端导入。

    查看(73) 评论(0)

  • 软件测试工具大全（简介）

    2007-6-08

    2007-06-08

    企业级自动化测试工具WinRunner

     

    提名理由：Mercury Interactive公司的WinRunner是一种企业级的功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作，WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。

    工业标准级负载测试工具Loadrunner

     

    提名理由：LoadRunner 是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner ，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。

    全球测试管理系统testdirector

     

    提名理由：TestDirector 是业界第一个基于Web的测试管理系统，它可以在您公司内部或外部进行全球范围内测试的管理。通过在一个整体的应用系统中集成了测试管理的各个部分，包括需求管理，测试计划，测试执行以及错误跟踪等功能，TestDirector极大地加速了测试过程。

    功能测试工具Rational Robot

     

    提名理由：IBM Rational Robot 是业界最顶尖的功能测试工具，它甚至可以在测试人员学习高级脚本技术之前帮助其进行成功的测试。它集成在测试人员的桌面 IBM Rational TestManager 上，在这里测试人员可以计划、组织、执行、管理和报告所有测试活动，包括手动测试报告。这种测试和管理的双重功能是自动化测试的理想开始。

    单元测试工具xUnit系列

     

    提名理由：目前的最流行的单元测试工具是xUnit系列框架，常用的根据语言不同分为JUnit（java），CppUnit（C++），DUnit （Delphi ），NUnit（.net），PhpUnit（Php ）等等。该测试框架的第一个和最杰出的应用就是由Erich Gamma （《设计模式》的作者）和Kent Beck（XP（Extreme Programming）的创始人 ）提供的开放源代码的JUnit。

    功能测试工具SilkTest

     

    提名理由：Borland SilkTest 2006属于软件功能测试工具，是Borland公司所提出软件质量管理解决方案的套件之一。这个工具采用精灵设定与自动化执行测试，无论是程序设计新手或资深的专家都能快速建立功能测试，并分析功能错误。 

    性能测试工具WAS

     

    提名理由：Microsoft Web Application Stress Tool 是由微软的网站测试人员所开发，专门用来进行实际网站压力测试的一套工具。透过这套功能强大的压力测试工具，您可以使用少量的Client端计算机仿真大量用户上线对网站服务所可能造成的影响。

    自动化白盒测试工具Jtest

     

    提名理由：Jtest是parasoft公司推出的一款针对java语言的自动化白盒测试工具，它通过自动实现java的单元测试和代码标准校验，来提高代码的可靠性。parasoft同时出品的还有C++ test，是一款C/C++白盒测试工具。

    功能和性能测试的工具JMeter

     

    提名理由：JMeter是Apache组织的开放源代码项目，它是功能和性能测试的工具，100%的用java实现。

    性能测试和分析工具WEBLODE

     

    提名理由：webload是RadView公司推出的一个性能测试和分析工具，它让web应用程序开发者自动执行压力测试；webload通过模拟真实用户的操作，生成压力负载来测试web的性能。

     测试工具大全

    Author: Vince

    工具类别 工具名称 生产厂商 相关网站
    通用功能自动化测试工具 Winrunner Mercury
    Quicktest pro Mercury
    Xrunner Mercury
    QARun Compuware
    TestPartner Compuware
    WebKing Parasoft http://www.parasoft.com
    Robot IBM Rational http://www.ibm.com/cn
    Visual Test IBM Rational http://www.ibm.com/cn
    Functional Tester IBM Rational http://www.ibm.com/cn
    SilkTest Segue
    SilkTest International Segue
    e-Tester Empirix
    WebFT Radview
    TestComplete AutomatedQA
    QA Wizard Seapine