发布新日志

  • 存储过程的返回值

    2012-06-07 15:37:06

    MSDN关于存储过程,看到比较详细地说明返回值,就转载过来了。
    转载地址:http://msdn2.microsoft.com/zh-cn/library/ms188655.aspx
    存储过程中的返回值的类型(3种)

    使用 OUTPUT 参数返回数据

    说明如何使用 OUTPUT 参数将数据返回调用应用程序。

    使用返回代码返回数据

    说明如何使用返回代码。

    在 OUTPUT 参数中使用 cursor 数据类型

    说明如何使用 OUPUT 参数中的游标数据类型。


    1。使用 OUTPUT 参数返回数据

    如果在过程定义中为参数指定 OUTPUT 关键字,则存储过程在退出时可将该参数的当前值返回至调用程序。若要用变量保存参数值以便在调用程序中使用,则调用程序必须在执行存储过程时使用 OUTPUT 关键字。

  • 【转】做好测试计划和测试用例的工作的关键

    2012-05-04 17:55:37

    51testing每周一问的这个问题很精彩,于是我做了如下回答。51Testing软件测试网K m F_h!S Y

    问题如下:

    1t'Kf8Qkk7a3AE77325

    测试的流程中,测试计划是对整个测试活动的安排,而测试用例则是测试执行的指导,但是,现在仍然有很多的测试人员没有认识到测试计划和测试用例的重要性,在项目时间比较紧张的情况下,计划和用例往往成了形式上的东西,甚至有些测试人员脱离用例,完全凭借自己的经验在执行测试活动,对此,你有什么样的看法?51Testing软件测试网Y{c3k1c bGT@d

    这个问题问的非常好,也确实是很多人有过切肤之痛的问题,对我来说,我也一直在苦苦追寻这个问题的答案,现在我不能说完全找到了,只能说把自己的心得分享一下,希望大家的测试计划和测试用例不再是一个摆设。

    )g!m.s;XU9|Z77325

    (一) 先说测试计划吧51Testing软件测试网2Bp"M^?:A.]

    诚如magic_zhu所言,现在很多测试人员没意识到测试计划的重要性,很多时候测试计划成为一纸空文,其根本原因在于测试计划缺乏可执行性,也正是因为测试计划缺乏可执行性,导致下一次写计划的时候非常草率,甚至不写,就算写了也是一个花架子应付领导,这样形成了一个恶性循环,久而久之,测试计划纯属一个摆设,我们很多从业者不写测试计划,其理由是反正写了也不能按照计划执行,这种理由真的很荒唐可笑,这是典型的因噎废食,因为你的计划执行性差就不写?这样只能使测试更加失去控制,使你的测试过程彻底无计划,无目标,变成一个放任主流的状态,完全没有受控性。这样的产品质量保证显然是空谈。51Testing软件测试网AS2sez.S!b1~/o'z

    我觉得这个问题的解决方案不是不写,而是想办法写得更好,更有实效性,执行性。这个是问题的关键。

    pQ)|T(v77325

    一个好的测试计划是用来计划测试的,指导整个测试过程。所以一个好的测试计划一定是可以指导测试的,就是对整个测试过程中的人力,时间,资源,策略,范围的一个说明。

    ?1k+Wd S77325

    作为一个测试计划来讲,核心的三个要素是时间,资源,范围。(这句话摘自微软软件测试培训材料),时间就是什么时候做以及要花多久做,资源就是你要调用的人力、机器等资源,范围是你要测试的东西以及测试重点。51Testing软件测试网Oj I |:H5\

    除以上提到的3项之外,还有比较重要的项目有策略(具体就是怎么测)、风险控制(一旦有问题采取什么应急措施)等项目。51Testing软件测试网7eC)_(S#U^

    要把一个计划做得很有实用性,按照笔者的经验,要注意以下几个方面:51Testing软件测试网L1o)V F t^[!D

    a. 上面提到的三要素不能少51Testing软件测试网N;gWlA7GI Ad_

    b. 测试策略一定要交待清楚,就是大概怎么测试51Testing软件测试网3k0w:T6SF+d4d

    c. 需要其他人员(部门)协调的,要交待清楚

    ^On"fOs9h77325

    d. 在估计测试所需的时间、人力及其它资源时,尽量做到客观、准确、留有余地,特别是估计开发时间和debug时间,以及要对自己的执行用例速度,回归速度心里有数51Testing软件测试网:_N]N'[7K

    e. 测试计划中每个阶段要明确表明,并且测试阶段的输入、输出文档要清楚

    ,K,@"\i)Z9iPm/Ws77325

    f. 测试计划中的时间段不宜太长(最好以day为单位),太长就比较模糊,不好度量,不好check51Testing软件测试网2iW2o;O'I

    g. 一定要有风险控制,要不然计划缺乏可执行性

    ~*Dx:HY5z ].F77325

    h. 计划写完之后不是装在兜里,要组织PMDev进行评审51Testing软件测试网#C#a3o#x$FN.|7^

    i. 要不断更新计划,记住:每个计划都是动态的,不是一成不变的

    ;W[H:M3du?77325

    (二) 再说测试用例

    *e8z-V&v7n+v-\ }!Y77325

    和测试计划一样,测试用例很多时候也沦为形式,这是软件测试的可悲之处,软件测试的依据就是测试用例,如果用例弃之不用,你凭什么做好测试?这个很可笑。但是实际测试过程中很多时候测试用例并没用到实处,笔者认为还是用例实用性问题,有的时候用例洋洋洒洒数万字,到回归测试的时候根本用不上,至于如何选择回归测试用例,我曾经写过另一篇文章,欢迎查阅。51Testing软件测试网3[u9NQ7u4Gpi.j

    下面我就个人体会谈谈做好测试用例的关键。

    s+L\?"^H%q2Z-h77325

    首先,在做用例之前,要做两件事情。

    x/h;zzOg77325

    第一, 透彻了解程序(需求和架构)。

    TNw'fK77325

    第二, 做一个正式的测试设计(最好文档化)。然后再开始写用例。一般写用例的步骤和建房子一样,先搭框架,然后填材料,填材料的时候,主要根据需求做相关的设计,具体的设计方法就是那几种(郑老的书上写的很清楚)

    !G\H5o0ek#A0r77325

    一般来说,设计一个比较实用的测试用例,注意如下几个方面:

    /pUe$ZwHb-G;B6C77325

    a. 选用好的用例管理工具(这个很重要,千万不要用wordexcel

    0QQV6c6L d?77325

    b. 用例一定要及时更新(补充新的想法,删除过时的需求)

    rS R]j%Hm77325

    c. 做好用例分级51Testing软件测试网)L tH+K1NJ4@

    d. 做好用例评审,写用例之前可以征询相关人员的意见

    4u^A/].]?8LG77325

    e. 可以考虑结对编写,这个是不错的主意51Testing软件测试网4k?rd:y W

    f. 要全面,包括功能、性能、兼容性、安全性、易用性、容错性等等51Testing软件测试网Ub}"RJ"t8@V*Am

    g. 注意把握适当的颗粒度

    #s6w(Xqa&k77325

    OK,以上是我个人总结的一些心得,希望对您有些帮助,谢谢magic_zhu提这个问题,如果对读者您有些帮助,也不浪费我写到凌晨0点的心血,呵呵~~~~~~~~关于这两个话题太大了,欢迎大家展开讨论!!

    lMe%sY b!k0MB77325

    本文是godn_1981原创,如需转载,请注明出处。

  • 【转】面试进行曲之技术面试(项目经验)

    2012-05-04 17:14:29

    在前期已经讲过怎样分析自己,对自己进行一个准确的定位,选择一个合适的求职方向!并结合自己的实际个人情况来写一份针对性很强的个人简历!个人简历就是个人的广告!好的简历可以更受到用人需求单位青睐!好的简历才能让你获得面试的机会!我们还针对面试列出了j2ee方面的知识点!不管是笔试还是面试都是会考到这些非常重要的知识点!面试的技术内容并不会有想象中的那么难,主要注重基础和细节!细节决定一切!所以列罗的那些知识点是需要下功夫去准备的!当然列罗的那些知识点只是一些在面试中经常会出现的问题集!每家企业都可能超出这些知识点的可能(就不要骂我了)!自己去准备吧!

    技术方面的考核通常分为笔试,技术面试;其中技术面试又分为专业知识面试和项目经验考核。应该说来笔试和专业知识面试都是考核你对某方面(j2ee或.net)知识的掌握和熟练程度!而项目经验考核则是看你是不是拥有项目经验,是不是适合企业的用人需要,是不是需要企业为你付出培养的成本,是不是你能够马上投入到工作中去.企业是以你的项目经验作为衡量你的工资标准的!所以就是会出现有些同学可能在学校学习成绩很好而企业给他开的工资并不高,而有些同学的学习成绩一般反而得到高工资的原因!专业知识的考核只是企业了解你具有这方面的专业素养和能力!其实有时笔试成绩差一点或者你感觉在做笔试题的时候有些题目没有做出来或答错了并没有关系的。在技术面试的时候,在回答专业知识方面的题目不够理想,也并不起决定性的作用!总之笔试和专业知识面试的答题达到企业要求的70%就可以了!当然如果你在专业知识方面表现的太差,考官对你也就没有多大的兴趣了!但是最能决定企业下定决心录用你的关键在于你的项目经验(排除企业特别强调英文等其它方面能力外)。说了这么多好像都没有说到正题,这是因为让大家更清楚的了解回答好项目经验方面的问题是多么的重要。而这方面又正好是刚从学校出来的学员十分薄弱的,并且针对这方面介绍也十分少! 下面我们就来谈谈面试中关于项目经验的问题及应该从哪些方面进行回答!

    问题一、请简单的介绍一下你自己吧!

    分析:这是在任何面试中都会遇到一个题目,看起来这个问题是十分简单的,但是往往我们并不知道考官问这个题目是希望从你的回答中获得什么信息!所以我们就很容易走题,跑题,不入正题!不能马上就吸引考官。请记住抓住面试的每一个机会来推销自己。但是往往我们不知道从哪里谈起。所以我们得先了解考官想要获取什么信息呢?

    1. 你的从业时间 你从事相关的工作有多长了

    2. 你的教育背景 你是否受过良好的教育

    3. 你的工作经验 你是否有过具有一定的工作经验

    4. 你的项目经验 你是否有过丰富的项目经验

    5. 你与众不同之处 你是怎么进行项目开发的,有什么特别之处,或者你在哪些项目中

    取得过哪些成功,或者有哪些自己觉得骄傲的地方

    6. 你最擅长的地方 你最擅长的技术是什么?

    7. 你的性格 你是怎么样的一个人

    怎么回答: 我们一一来分析吧,首先从业时间一般回答你进行软件项目专业开发的时间.千万不要把你以前在大街上卖过鱼蛋或到夜市卖烧鸡等乱七八糟的时间计算进来.工作经验也是,你至少有在一家公司呆过吧.不要告诉我你只学过j2ee或.net半年时间,就想来我公司混饭吃.要和你的简历对应起来.一般至少1年半以上.

    教育背景:如果你上的大学及所上的专业比较对口,就说出来,非否就不要提了.总之是要扬长避短

    工作经验:也就是以前在什么公司上过班,与你简历上的一致就可以了.只说与软件开发的工作经验,其它的就不要提了

    项目经验:你曾经做过的自认为比较好的项目,这里特别重要,先用一句话来概括项目,然后把项目的功能及子功能全部叙述出来.

    你与众不同之处:也以说你在项目你以什么独特的方法获得什么不同的效果,主要是能够结果具体的项目或能举例说出来.

    最擅长的地方:主要告诉对方你最擅长哪方面的技术,是需求分析?编码,或数据库或架构

    你的性格:用一两个词来形容你自己,描述你的性格.

    回答实例:

    面试官:请简单的介绍一下你自己吧!

    令狐冲:您好,在下令狐冲.从事j2ee开发工作3年时间.20002年至2005年在大宋桃花岛软件谷皇室软件公司从事j2ee项目开发.其间开发过大宋侠士综合管理平台.大宋侠士综合管理平台能够自动收集大宋各路侠士,英雄好汉,隐居高人信息并对他们的个人信息及所作所为进行跟踪管理,实现侠士信息维护,查询.侠义事件维护,侠士等级管理,侠士奖惩管理,侠义活动发布,抗灾募捐管理等。鄙人在项目中主要负责需求分析,架构设计和框架类代码实现。在项目开发中善于与客户沟通,充分理解客户需求。具有极强自学能力,在大宋藏经阁中通读了大量的软件项目开发秘籍,具有藏文,印度文,金文的读写能力。

    问题之二、谈谈你的XXX项目吧!

    分析:考官通过看你的简历或者你的介绍来了解你所做的项目,那么考官肯定想更详细的了解您的项目,看是不是与你的简历写的项目经验一致。也就是考核你是否具有真实的项目经验。一般来说,在你的简历至少有一个重点项目,放在简历项目经验栏的第一位。把项目的业务功能描述清楚。在这里你就是重点谈一个项目就可以了。从下面几个方面来进行陈述

    1. 用一句话简述项目

    2. 详细的列出项目实现的功能

    3. 说出项目实现的技术和架构,能说出项目的不寻常之处,比如采用了某项新技术,采用了良好的架框等

    4. 能让别人感觉出项目的规模

    5. 说出你在项目中的责任

    通过这些来证明你是的确开发过了这个项目,并且这个项目是一个真实的。还有就是你是真正具有项目经验的。乎合企业的用人需要。

    特别注意要把项目所实现的功能描述得越详细越好。当然用词要简洁,表达要流利。其次要尽可能采用专业术语,显得你的专业。不要犯低级错误。

    请记住,你要描述的是整个项目而不仅仅是你做的那一个模块。有些项目你只参与了其中一个模块,但是你要把整个项目描述出来,不要仅仅描述你参与的那一个模块。

    说出你项目采用的技术及架构,还要能说明你在项目中的责任。

    回答实例:

    面试官:令狐冲,能介绍一下你做的大宋侠士综合管理平台吧!

    令狐冲:好的,大宋侠士综合管理平台是为大宋武林联盟开发的,实现武林联盟管理的自动化。大宋侠士综合管理平台能够自动收集大宋各路侠士,英雄好汉,隐居高人信息并对他们的个人信息及所作所为进行跟踪管理,实现侠士信息维护,查询.侠义事件维护,侠士等级管理,侠士奖惩管理,侠义活动发布,抗灾募捐管理等。

    系统基于B/S三层架构,采用Spring + Hibernate + Spring MVC框架.使用Oracle数据库.

    本项目只投入15个人,开发周期为6个月。本人在项目中进行了前期的需求分析,系统架构实现,数据库建模,及部分编码工作。

    问题之三、谈谈你们是怎么对这个项目进行开发的?(谈谈你们是怎么进行项目开发的?)

    分析:这个问题是考核你是否熟悉软件开发的流程,同时也是考核你的项目经验,你的专业素养,从这里可以判断出你参与过多少项目,可以判断你对软件工程的理解和熟悉程度。这个问题是十分关键的,你需要准备的知识点有:软件项目的生命周期、软件项目的开发模型、面向对象的分析和设计、软件质量保证等。

    软件项目的生命周期:

    项目计划

    需求分析

    设计(概要设计和详细设计)

    编码

    测试

    发布

    维护

    项目计划阶段:走访客户,进行交流沟通,获得客户原始需求。

    对客户的需求和市场等进行调研,分析,编写可行性分析报告。

    通过不断的与客户沟通,找客户不同环节的用户进行交流来获取需求。召开评审会议,报告可行性分析,报告用户原始需求,报告项目远景规化。

    需求分析阶段:

    在客户原始需求的基础上不断与客户沟通,充分的熟悉和深入客户业务,获得充分的业务需求,完善用户需求和功能性需求,了解客户的相关约束而获得非功能性需求。最终编写《需求规格说明书》;召开需求评审会议,客户确定需求,并签定合同;编写项目计划说明书;编写测试计划;召开项目启动会议,项目正式启动。

    概要设计阶段:根据《需求分析说明书》,进行用例分析,获得充分而有效的用例。编写界面原型,编写编码规范和界面风格规范,数据库设计规范。用uml工具画用例图,编写有效的用例规约文档。划分项目功能模块.评审用例及用例规约文档。

    详细设计阶段:根据完整的用例及需求进行分析,获得数据库所需的相关信息,画数据库E-R图,编写数据设计说明书.进行数据库建模。进行详细的分析,用uml工具画类图,确定每个功能模块的子功能,抽取项目的公共部分成为一个公共模块。确定项目的架构基础。确定需要用到的类及类成员和方法。确定一些辅助类及方法。对每一个用例都用uml工具画出顺序图。编写详细设计说明书,评审详细设计说明书, 进行基础框架搭建。列出任务清单,进行任务分配。

    编码阶段:以小组的形式进行代码编写,编写单元测试用例,每完成一个类都要进行单元测试。每完成一个功能点和模块都要进行集成测试。确保每一个功能点和模块完成后都是一个可以看得见、摸得着的产品。而不是等到最后才进行统一的调试和搭配。每天都要对代码进行检查和优化,也就是所谓的重构。

    测试阶段:根据测试计划对项目进行系统测试,以及用户的验收测试

    产品发布:交付完整的产品和设计文档。把产品布署到客户的计算机上,确保产品的正常运行。客户签收。

    维护阶段:为客户提供技术保障,对产品进行相应的维护和升级工作

    软件常见开发模型

    瀑布模型:最经典的过程模型,适用于需求明确,规模较小的项目

    喷泉模型:迭代,无间隙特点,适用于面向对象的软件开发过程

    螺旋模型:

    MSF模型:微软解决方案过程模型

    什么是极限(XP)编程:极限编程是对敏捷软件开发方法的一种实现。它强调测试先行,也就是在编写代码的时候先编写测试用例;循环迭代,每一次迭代都是一个可用的产品;重构,不断的对代码进行优化;结对编程,两个人为一对共同进行代码编写;它强调团队之间的知识传播,让团队的每个人都能熟悉软件开发的各种技术。如:支持熟悉数据库的人去做界面,做界面的人去做数据库等,通过不定期的角色转换来增强团队的能力。要求客户参与到软件开发中来,开发出最适合客户需求的产品。

    单元测试一般是在编码的时候同步进行的,一般是以类为单位进行测试,当一个类完成了编码,并编译正确后才进行的测试,测试这个类是否已经能够实现指定的功能。一个类能够正常的编译成功并不意味着这个类就已经完成了,还要通过测试,设置断言来确定他是否已经达到了预期的效果,实现了特定的功能。调试,编译通过只能证明代码的语法没有错误。

    单元测试由程序员自己来进行,也可以在项目小组内交互进行。单元测试是采用白盒测试

    集成测试一般指实现了一个功能点或一个模块后,为了测试这个模块是否已经实现了需求要求的功能。集成测试可能需要对多个类进行组装,也可能需要与以前已经测试通过的模块进行组装,是对产品组件的系统整合和执行。集成测试可以根据模块的大小分不同的级别,在现行的软件开发中,每完成一个功能模块都必须要进行一次集成测试,使得你完成的模块是一个可以运行的产品。集成测试一般可以由项目小组的负责人(或指定一个小组成员)来完成。集成测试采用白盒式测试和黑盒测试

    系统测试一般指项完代码已经全部完成,交给测试小组来进行测试。进行系统测试的人员独立于开发小组,系统测试人员把完成的产品布署在相应的计算机环境中,按照测试计划进行测试,验证系统是否满足了指定的需求。系统测试除了测试产品应满足基本的功能需求外,还要对产品的性能,用户界面,安全性,压力,可靠性,安装和反安装等几个方面进行测试

    系统测试采用黑盒测试

    验收测试一般指产品交付给客户,负责把产品布署在指定的计算机环境中。由用户根据需求文档,进行的总体测试。验收测试的内容和系统测试一样,只是执行者不同。都是除了测试系统完成基本功能外还要对性能,安全性,可靠性等进行测试。验收测试也是采用黑盒测试

    为什么需要测试?测试是对软件质量的保证,只能通过严格测试的软件才是合格的软件,测试并不是说让软件能够编译通过,测试是让软件产品最大程度的满足客户的需求度。

    回答实例:

    考官:令狐冲,能谈谈你们是怎么样对这个项目开发的吗?

    令狐冲:首先,我们这个项目已经有了一个基本的用户原始需求。但这是不够的,我们都知道需求分析是十分重要的,所以我们在用户原始需求文档的基础上,再次进行了分析,通过不断的与客户沟通,充分的了解和熟悉用户的业务,完善了业务需求和功能需求。还对用户业务需求和功能需求分析完善为实现软件的必须的非功能性需求。得出项目需求规格说明书,经过评审会议确认通过。

    根据需求规格说明书进行用例分析,通过分析和讨论找出充分的有效用例,并用Rose画用例图。对每一个用例进行详细的分析,完成每个用例的用例规约文档,并编写界面原型。划分项目模块。最后对用例及用例规约文档进行评审验证。编写”代码编写规范”及界面风格规范,数据库设计规范,编写概要设计说明书。

    根据需求规格说明书和分析各个用例规约文档,获得数据库的基本信息原型。也可以说是数据库表的草稿,根据数据库表草搞进行分析,进行数据库设计和优化。编写数据库设计说明书。采用PowerDesigner进行数据库建模,并生成SQL脚本。确定项目框架,设计公共模块和辅助类。根据对数据库模型和用例规约文档的分析,列出对象清单和理清对象关系。用Rose来画类图。对每一个用例都用rose画出时序图。编写详细设计说明书。列出任务清单,分组进行代码编写。

    在代码编写阶段,先统一完成所有的实体类。对于非实体类则先完成类的框架,也就是只写方法和注释文字。具体方法的实现暂时为空。然后再进行代码填写。每完成一个类的代码编译通过后都要进行重构和单元测试。每完成一个功能和模块都由会由小组长进行集成测试。使得完成的模块是一个真正可以运行的,可见的功能实现。

    在各个小组都完成自己的模块后就进行模块整合,进行一次大规模的集成测试。然后把产品产给产品测试小组进行系统测试。

    问题之四、你们是怎么保证软件开发的质量的?

    分析:这个问题其实上面的讲解已经给了答案了。软件质量是软件实现对需求的满足度。开发的软件越满足客户的需求,说明软件的质量越高。反之就是质量越低。尽管你开发的软件使用了新的技术,良好的设计,丰富的功能;但是这些功能都不是客户需要的,客户需要的功能没有实现或者是很多没有实现。这样的软件也是失败的软件。为了保证软件质量,也就是让开发的软件最大程度满足客户的需求,只有两个方法。一个是获得充分完整的需求,二是能过测试,以需求为中心编写测试计划。来保证软件合乎需求。

    回答实例:

    考官:你们是怎么来保证软件的质量的呢?

    令狐冲:要保证软件的质量首先就要获得完整的需求,在需求分析阶段做了大量的工作与客户各个环节的代表性用户进行沟通,充分了解和熟悉客户的业务。并且从需求到设计阶段都保持与用户的沟通和交流。让用户的业务专家一直参与我们的需求,分析和设计工作。

    其次我们会在需求分析后就编写测试计划,在开发的每个阶段都进行相应的测试来保证代码是乎合相应需求的。在代码编写过程中,每完成一个类都由程序进行单元测试,每完成一个功能点或模块都要进行集成测试,每一次集成测试都对上一次的已经测试通过的产品进行迭代, 也就是以前测试成功的都会加入到本次测试中来。使得每个完成的功能和模块完成后都是一个可以运行的,可以看得到的产品;同时也欢迎用户来见证我们的集成测试结果。代码编写完成后进行最后一次集成测试,然后交由独立的测试小组对项目进行系统测试。

    问题之五、你为什么离职的?(你为什么离开以前公司的?)

    分析:这个问题几乎在任何场合的面试都会有,有时是在技术面试的时候问,有时是在人事面试的时候问,有时会在技术面试和人事面试的时候都问。其实也比较好回答,回答的抽象一点比好。切记不要说以前公司的坏话,如果你这样做。人家会想,你以后离职后同样也会说这家公司的坏话.一般都是说为了某求更好的发展空间。让人感觉你是经过深思熟虑后才选择他们公司的。

    回答实例:

    考官:你为什么离开以前公司的?

    令狐冲:以前公司对我很好,我在以前公司干得也很愉快。我因为合同到期,为了获得更好的发展空间及谋求对自己能持续发展的环境。并向公司办理了离职手续,完成了工作交结。(后面这句也可以不谈)

    问题之六、谈谈你的职业规化

    分析:企业都希望他所招聘的人是潜力股,看你是不是一个追求上劲的人,还有想看看你能够在企业长期干还是仅把其当着一个跳板。总的说来,回答这个问题要让人觉得你是一个可培养,有潜力人。记住要看是什么样的人来面试你。如果是项目经理来面试你,你就不要说你以后的职业规化是项目经理。你就可以说你的职业规化是成为架构师,或者是技术专家等。否则他可能会认为你是一个对其有威胁的人。就算他内心知道这不算什么,可能心理总会有一点点不爽。如果是老总面试或人事问你这样的问题,你则可以说项目经理也无妨,不过要给人有一种觉稳的感觉。

    回答实例:

    考官:你的职业规化是怎么样的呢?(考官是项目经理)

    令狐冲:我思维能力比较强,擅于逻辑分析。在之前的工作中积累了一定的架构经验,以后就想成为一名架构师和技术专家

    写在最后:上面的这些问题都是面试中十分常见的的问题,比较难以回答的。有些看似简单却不知从何说起。有些看似复杂却又并不复杂。因为很多人都缺少项目经验,对软件开发的过程相对陌生,而老师讲这方面的知识也比较少,如果你没有一定的代码和项目积累就算老师讲你也很难去体会、理解。再说这方面的内容太要求实际经验和日月积累,老师也不好讲。现在我采用把枯燥的概念和实际的项目结合起来进行归纳,从而形成这样一个答题技巧。并且对其中的一些技术结合实际进行分析和总结。希望阅读者能快速的知其然也知其所以然。从而能够提高面试的成功率。当然这仅仅是一个答题技巧,关键还是需要知识的积累。有道是“不积跬步,无以至千里;不聚细流,不以成江河”。这次完成此文也是我自己对知识的一次梳理,我并没有去查阅和考证书本。我想完全通过自己的语言来描述项目开发的过程和一些细节。又因我实在是才疏学浅,真的希望大家能对我的不当及错误之处指出并加以指教,我就涕感泪流了。不管是技术还是人生,我才刚刚上路呢!



  • 【转】常见软件测试面试题

    2012-05-02 14:36:05

    问题一:为什么要在一个团队中开展软件测试工作
    任何软件在开发过程中都会留下缺陷,带有缺陷的软件产品如果提交出去,可能会给公司带来不可估量的损失,我们必须在客户之前发现尽可能多的问题,从而保障客户满意。而发现问题的这个过程称之为测试。

    问题二:简述你在以前的工作中做过哪些事情,比较熟悉什么。
          此问题每个人都不一样。我自己的答案如下。
    我主要的工作是系统测试自动化测试,也曾少量涉及性能测试。在系统测试中,主要是对BOSS系统的业务逻辑功能,以及软交换系统的Class 5特性进行测试。性能测试中,主要是进行的压力测试,在各个不同数量请求的情况下,获取系统响应时间以及系统资源消耗情况。自动化测试主要是通过自己写脚本以及一些第三方工具的结合来测试软交换的特性测试。

    问题三:你所了解的的软件测试类型都有哪些,简单介绍一下。
    1.
    基本功能验证。主要是对发布的版本进行一些最主要功能的测试。英文常见叫法是Smoking Test, Basic Verification Test或者Sanity Check
    2.
    功能测试。主要是依据需求或者需求分析文档,对所发布的版本进行测试,看看是否满足需求,是否出现了不必要的功能。
    3.
    单元测试。是开发人员进行的测试之一,一般是开发人员对很小的模块,比如函数进行测试,一般来说,开发人员还需要开发相应的测试桩来进行此类测试。
    4.
    集成测试。在大型的开发过程中,软件是模块化进行开发的,将不同的模块揉合在一起的话,需要进行的测试就是集成测试。
    5.
    系统测试。当软件提交给测试组后,是对整个系统的所有功能进行测试,一般来说,功能测试是系统测试的一个部分。
    6.
    压力测试。主要是在很大性能的情况下,这个性能已经接近了系统的极限,看看系统运转的情况。
    7.
    负载测试。主要是用各种不同的性能去检测系统,采集各个数据在这些性能情况下的数据。
    8.
    黑盒测试。指系统对你来说是完全不透明的,只给你留下了输入和最终输出,这个是功能测试的方法之一。
    9.
    灰盒测试。指在了解部分系统内部工作机制的情况下,对于系统进行的覆盖性测试。
    10.
    白盒测试。主要是在单元测试和集成测试的情况下,开发人员已知代码,对这一段的代码进行全路径的覆盖测试。
    11.
    界面测试。主要是看用户界面的友好性和易用性,是否有文字或者排版错误,是否有输入限制等等。
    12.
    回归测试。一般是系统发现BUG,开发人员修改后,和BUG直接相关以及可能相关的功能进行的测试。
    13.
    安装和卸载的测试。
    14.
    恢复测试。主要是一个系统在发生了灾难的情况下,从错误中是否容易恢复。
    15.
    兼容性测试。一个系统在不同的语言,操作系统下的系统测试。
    16.
    安全测试。系统在遇到攻击或者类似情况下的表现。
    17.
    Alpha
    测试。系统在给最终用户前,测试人员在实验室中模拟最终用户的测试。
    18.
    Beta
    测试。由部分最终用户通过使用来进行的测试。
    19.
    比较测试。和其他具有相同或者类似功能的系统进行对比的测试。
    20.
    验收测试。一般是最终用户在接受产品前,依据自己所提出的要求进行的测试,很多情况下,验收测试可能委托第三方机构完成。

    问题四:测试计划工作的目的是什么?测试计划文档的内容应该包括什么?其中哪些是最重要的?
    软件测试计划是指导测试过程的纲领性文件。
    包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划,参与测试的项目成员,尤其是测试管理人员,可以明确测试任务和测试方法,保持测试实施过程的顺畅沟通,跟踪和控制测试进度,应对测试过程中的各种变更。
    测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法(最好是能先评审)。

    问题五:你认为做好测试计划工作的关键是什么?
    1.
    明确测试的目标,增强测试计划的实用性
    编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷,因此软件测试计划的价值取决于它对帮助管理测试项目,并且找出软件潜在的缺陷。因此,软件测试计划中的测试范围必须高度覆盖功能需求,测试方法必须切实可行,测试工具并且具有较高的实用性,便于使用,生成的测试结果直观、准确
    2.
    坚持“5W”规则,明确内容与过程
    5W”规则指的是“What(做什么)”、“Why(为什么做)”、“When(何时做)”、“Where(在哪里)”、“How(如何做)”。利用“5W”规则创建软件测试计划,可以帮助测试团队理解测试的目的(Why),明确测试的范围和内容(What),确定测试的开始和结束日期(When),指出测试的方法和工具(How),给出测试文档和软件的存放位置(Where)。
    3.
    采用评审和更新机制,保证测试计划满足实际需求
    测试计划写作完成后,如果没有经过评审,直接发送给测试团队,测试计划内容的可能不准确或遗漏测试内容,或者软件需求变更引起测试范围的增减,而测试计划的内容没有及时更新,误导测试执行人员。
    4.
    分别创建测试计划与测试详细规格、测试用例
    应把详细的测试技术指标包含到独立创建的测试详细规格文档,把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。

    问题六:常见的测试用例设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

    1.         等价类划分

    划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

    2.         边界值分析法

      边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.

      使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

    3.         错误推测法

      基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.

      错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

    4.         因果图方法

    前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图(逻辑模型). 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

    5.         正交表分析法

    有时候,可能因为大量的参数的组合而引起测试用例数量上的激增,同时,这些测试用例并没有明显的优先级上的差距,而测试人员又无法完成这么多数量的测试,就可以通过正交表来进行缩减一些用例,从而达到尽量少的用例覆盖尽量大的范围的可能性。

    6.         场景分析方法

    指根据用户场景来模拟用户的操作步骤,这个比较类似因果图,但是可能执行的深度和可行性更好。


    问题七:您认为做好测试用例设计工作的关键是什么?

    白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果

    黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试,以最少的用例在合理的时间内发现最多的问题


    问题八:详细的描述一个测试活动完整的过程。

    1.         项目经理通过和客户的交流,完成需求文档,由开发人员和测试人员共同完成需求文档的评审,评审的内容包括:需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员,测试人员以及客户的意见,完成项目计划。然后SQA进入项目,开始进行统计和跟踪

    2.         开发人员根据需求文档完成需求分析文档,测试人员进行评审,评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档,测试计划包括的内容上面有描述。

    3.         测试人员根据修改好的需求分析文档开始写测试用例,同时开发人员完成概要设计文档,详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。

    4.         测试用例完成后,测试和开发需要进行评审。

    5.         测试人员搭建环境

    6.         开发人员提交第一个版本,可能存在未完成功能,需要说明。测试人员进行测试,发现BUG后提交给BugZilla。

    7.         开发提交第二个版本,包括Bug Fix以及增加了部分功能,测试人员进行测试。

    8.         重复上面的工作,一般是3-4个版本后BUG数量减少,达到出货的要求。

    9.         如果有客户反馈的问题,需要测试人员协助重现以及回归测试。


    问题九:以往是否曾经从事过性能测试工作?请尽可能的详细描述您以往的性能测试工作的完整过程。

           曾经做过一套网管系统的性能测试,主要测试该软件在同时管理大量终端的情况下,在响应时间,CPU/磁盘/内存等参数是否满足要求。

           也曾经做过软交换系统的呼叫性能测试,主要是测试软交换系统在有大量呼叫的情况下,响应时间,呼叫成功率,CPU/磁盘/内存等参数是否满足设计要求。


    问题十:您在从事性能测试工作时,是否使用过一些测试工具?如果有,请试述该工具的工作原理,并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。

           测试网管系统中,使用的Mimic来模拟终端,能够大量的节省成本。

           测试软交换系统的时候,使用的Prolab来模拟终端并发送呼叫软交换,他完成了同时数百人才能完成的摘机拨号工作,主要工作原理是产生一些符合要求的IP包并发送给软交换系统,同时对软交换系统的回应进行处理,决定下一步动作。


    问题十一:您认为性能测试工作的目的是什么?做好性能测试工作的关键是什么?

    主要是保障在大量用户的情况下,服务能正常使用。

    补充:

    性能测试目的:1、检验系统性能是否达到了预期目标;2、对系统性能进行进一步改进提高
    性能测试关键:1、做好性能需求分析和测试计划的制定
    2、合理的场景分析
    3、准确的瓶颈定位


    问题十二:在您以往的工作中,一条软件缺陷(或者叫Bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(Bug)记录?

    1.         在传统的BugZilla中,BUG描述应该包括以下的信息

    2.         和BUG产生对应的软件版本

    3.         开发的接口人员

    4.         BUG的优先级

    5.         BUG的严重程度

    6.         BUG可能属于的模块,如果不能确认,可以用开发人员来判断

    7.         BUG标题,需要清晰的描述现象

    8.         BUG描述,需要尽量给出重新Bug的步骤

    9.         BUG附件中能给出相关的日志和截图。

           高质量的BUG记录就是指很容易理解的BUG记录,所以,对于描述的要求高,能提供的信息多且准确,很好的帮助开发人员定位。

    问题十二:BUG管理工具的跟踪过程

           用BugZilla为例子      

    测试人员发现了BUG,提交到Bugzilla中,状态为new,BUG的接受者为开发接口人员

    开发接口将BUG分配给相关的模块的开发人员,状态修改为已分配

    开发人员和测试确认BUG,如果是本人的BUG,则设置为接收;如果是别的开发人员的问题,则转发出去,由下一个开发人员来进行此行为;如果认为不是问题,则需要大家讨论并确认后,拒绝这个BUG,然后测试人员关闭此问题。

    如果开发人员接受了BUG,并修改好以后,将BUG状态修改为已修复,并告知测试在哪个版本中可以测试。

    测试人员在新版本中测试,如果发现问题依然存在,则拒绝修改;如果已经修复,则关闭BUG。


    问题十二:您认为在测试人员同开发人员的沟通过程中,如何提高沟通的效率和改善沟通的效果?维持测试人员同开发团队中其他成员良好的人际关系的关键是什么?

           尽量能有面对面的沟通,如果做不到,那么尽量能直接通过电话沟通,如果只能通过Email等非及时沟通工具的话,强调必须对特性的理解深刻以及能表达清楚。

           一是真诚,二是团队精神,三是在专业上有共同语言,当然也可以通过直接指出一些小问题,而不是进入BUG Tracking System来增加对方的好感。


    问题十三:在您以往的测试工作中,最让您感到不满意或者不堪回首的事情是什么?您是如何来对待这些事情的?

           某次性能测试覆盖不足,造成系统崩溃。


    问题十四:你对测试最大的兴趣在哪里?为什么?

    最大的兴趣就是测试有难度,有挑战性!做测试越久越能感觉到做好测试有多难。曾经在无忧测试网上看到一篇文章,是关于如何做好一名测试工程师。一共罗列了11,12点,有部分是和人的性格有关,有部分需要后天的努力。但除了性格有关的1,2点我没有把握,其他点我都很有信心做好它。

    刚开始进入测试行业时,对测试的认识是从无忧测试网上了解到的一些资料,当时是冲着做测试需要很多技能才能做的好,虽然入门容易,但做好很难,比开发更难,虽然当时我很想做开发(学校专业课我基本上不缺席,因为我喜欢我的专业),但看到测试比开发更难更有挑战性,想做好测试的意志就更坚定了。

    我觉得做测试整个过程中有2点让我觉得很有难度(对我来说,有难度的东西我就非常感兴趣),第一是测试用例的设计,因为测试的精华就在测试用例的设计上了,要在版本出来之前,把用例写好,用什么测试方法写?(也就是测试计划或测试策略),如果你刚测试一个新任务时,你得花一定的时间去消化业务需求和技术基础,业务需求很好理解(多和产品经理和开发人员沟通就能达到目的),而技术基础可就没那么简单了,这需要你自觉的学习能力,比如说网站吧,最基本的技术知识你要知道网站内部是怎么运作的的,后台是怎么响应用户请求的?测试环境如何搭建?这些都需要最早的学好。至少在开始测试之前能做好基本的准备,可能会遇到什么难题?需求细节是不是没有确定好?这些问题都能在设计用例的时候发现。

    第二是发现BUG的时候了,这应该是测试人员最基本的任务了,一般按测试用例开始测试就能发现大部分的bug,还有一部分bug需要测试的过程中更了解所测版本的情况获得更多信息,补充测试用例,测试出bug。还有如何发现bug?这就需要在测试用例有效的情况下,通过细心和耐心去发现bug了,每个用例都有可能发现bug,每个地方都有可能出错,所以测试过程中思维要清晰(测试过程数据流及结果都得看仔细了,bug都在里面发现的)。如何描述bug也很有讲究,bug在什么情况下会产生,如果条件变化一点点,就不会有这个bug,以哪些最少的操作步骤就能重现这个bug,这个bug产生的规律是什么?如果你够厉害的话,可以帮开发人员初步定位问题。


    问题十五:你的测试职业发展目标是什么?

    测试经验越多,测试能力越高。所以我的职业发展是需要时间累积的,一步步向着高级测试工程师奔去。而且我也有初步的职业规划,前3年累积测试经验,按如何做好测试工程师的11,12点要求自己,不断的更新自己改正自己,做好测试任务。


    问题十六:你自认为测试的优势在哪里?

    有韧性

    有能力面对挑战

    有信心做好每一件事情

    有比较好的教育背景

    从以前的经理处都得到了很好的评价表明我做的很好


    问题十七:当开发人员说不是BUG时,你如何应付?

    如果确实是自己理解错误,则承认错误,没什么大不了

    如果是需求不明,请项目经理补充清楚

    如果双方理解不一致,且都不能互相说服,则请项目经理判断。


    问题十八:你为什么想离开目前的职务?


    问题十九:你对我们公司了解有多少?


    问题二十:你找工作时,最重要的考虑因素为何?

    工作的性质和内容是否能让我发挥所长,并不断成长。


    问题二十一:为什么我们应该录取你?

    您可以由我过去的工作表现所呈现的客观数据,明显地看出我全力以赴的工作态度。


    问题二十二:请谈谈你个人的最大特色。

    我的坚持度很高,事情没有做到一个令人满意的结果,绝不罢手。


    问题二十三:一个测试工程师应具备那些素质和技能?


    问题二十四:集成测试通常都有那些策略?

           自上而下,自下而上,平面集成


    问题二十五:测试结束的标准是什么?

           从微观上来说,在测试计划中定义,比如系统在一定性能下平稳运行72小时,目前Bug Tracking System中,本版本中没有一般严重的BUG,普通BUG的数量在3以下,BUG修复率90%以上等等参数,然后由开发经理,测试经理,项目经理共同签字认同版本Release。

           如果说宏观的,则是当这个软件彻底的消失以后,测试就结束了。


    问题二十六:软件验收测试除了alpha,beta测试以外,还有哪一种?

    第三方验收测试


    问题二十七:为什么选择测试这行?

    最开始么,公司安排的,然后么,干一行爱一行,发现测试中间还是有很多东西需要学习的,再就是测试中有很多东西值得改进和研究。


    问题二十六:为什么值得他们公司雇用?

          用自己的经验和其他同事一起发现更多的问题,同时不同行业的观点可以互相借鉴。


    问题二十七:如果我雇用你,你能给部门带来什么贡献?

          分享我的测试经验和测试技能,提高测试部门技术水平

Open Toolbar