几个常用常用软件面试问题
1、介绍一下整体项目流程答案:1. 搭建缺陷管理的环境和测试环境以及配置管理的环境搭建;2. 编写测试计划;3. 设计测试用例;4. 编写测试用例;5. 测试用例的评审;6. 执行测试;7. 缺陷管理; 8. 测试报告的输出2、在实际项目中你是如何做测试计划答案:1.对客户提供的或需求分析人员编写的用户需求文档或需求规格说明书进行分析,提炼出测试要点;2.根据测试要点编写测试用例。
3.由评审组对测试用例进行评审--修改--再次评审--初步定稿4.执行测试4.1 按照测试用例对系统进行功能验证及客户的需求验证4.2 将测试过程中产生的Bug录入缺陷管理系统4.3 新版本发布后,对本次版本新增加的功能以及开发人员修正的Bug进行回归测试4.4 根据项目需要提交测试报告。
3、你是如何制定测试过程中的时间进度表的答案:根据项目的需求、开发周期、开发人员的开发进度等时间安排来制定一个测试时间进度初 稿,并将测试时间进度表交与整个项目团队成员大家一起讨论和分析,最终和所有人达成共识制定出一个大家都可以执行的测试时间进度表。
时间表中包括了开发人员提交功能或功能模块的时间,以及为了更好的执行测试,配合测试人员进行功能培训的时间,以及测试执行时间等,都详细的写到WBS中,并按照这个时间进度表来执行项目的测试任务。
4、测试计划都包括那些项答案:1. 测试计划目标 2. 测试参考文档 3.测试术语与定义 4. 测试内容 5. 测试人员的分工 6. 测试进度 7. 测试流程8. 测试工具 9.测试缺陷管理 10. 测试的风险分析5、测试用例如何设计的答案:在测试用例设计之前首先要熟悉客户的需求文档或需求规格说明书,以做到对被测系统的熟悉,充分了解产品的详细功能,并在熟悉过程中即使与研发人员和客户人员进行有效的沟通。
然后从需求中提炼中各个模块的详细功能点编写出一个测试要点的文档。
根据测试要点设计测试用例,测试要点与测试用例是一个一对多的关系,一个测试要点可能会需要几个测试用例的验证,有正常的操作和异常的操作,甚至是几个正常与几个异常的操作,这要根据实际功能的要求来具体分析具体实现。
6、测试用例包括那些项答案:产品名称、功能模块、用例的编号、编写人、被测功能的简述,测试的预置条件,测试步骤,预期结果,实际结果。
7、缺陷处理流程1.讲缺陷的详细信息录入缺陷管理系统,并分配给对应的开发人员2.如果遇到一些难以再现的缺陷,在开发人员修正过程中配合开发人员进行Bug的再现。
3.开发人员修正Bug后,会在缺陷管理系统中将修正后的Bug状态更改,通常为Fixed状态。
4.新版本发布后,测试人员会讲bug状态已经更改为Fixed的Bug进行回归测试。
如果测试通过,则将该Bug关闭,如果仍未通过,则将该Bug从Fixed更改为Reopen状态,继续让开 发人员来修正。
并等待下一个新版本发布后的二次回归测试。
8、缺陷报告包括那些项答案:编写人、被测系统的版本号、测试环境、预期结果、实际结果、对于实际结果如有必要附上截图、测试用例数、测试用例通过 数,测试用例的通过率、对缺陷的一个分析汇总。
9、缺陷报告严重级别的划分严重级别的错误:影响系统整体基本流程运行的错误,由于某一操作造成系统死循环或服务器崩溃的错误较严重:功能实现错误、内部计算错误、一般:UI错误,一些易用性的错误或建10、开发人员修复缺陷后,如何保证不影响其他功能答案:Bug的修复以及新功能的添加都有可能对版本造成一些影响,为了避免,在新版本发布以后,首先会对新版本做一个基础的流程测试也叫做冒烟测试,如果测试基本流程都顺利通过没有任何问题,那么测试人员可以继续进行详细的测试,否则就将冒烟测试中出现 的问题以及问题有可能出现的原因反馈给开发人员,由开发人员修正后再次发版,进行测试。
这是一个迭代的过程。
10、发现问题后你是如何判断其是否是BUG,你是如何提交的?答案:测试用例是经过评审组严格的评审,完全按照客户的需求规格说明书作为最终依据来评审的,如果测试过程中,测试结果与实际结果不符就很可能是Bug,如果一些比较明显的问题就直接录入缺陷管理系统,如果是一些边界问题不容易确定的,可以通过和开发人员甚至是设计人员等进行沟通最后得出一个结果究竟是否是Bug,如果是Bug就录入,如果是一个需要增加的新功能等,可以录入缺陷管理系统,类型为新需求。
11、测试总结报告包括那些项答案:测试用例的通过数,测试用例的未通过数,以及测试用例的通过率,未通过的功能都集中在哪几个功能模块 ,根据测试经验以及测试结果进行一个缺陷的分析和建议。
软件需求分析阶段 产物有哪些
三个职业都很牛逼。
基本都是可以做一辈子的。
需求分析是将需求转化为软件的业务,目前针对比较大的企业,一般公司由软件开发人员担任,逻辑和分析能力要强。
架构师:一般一个公司也就一个,小公司一般没有架构师这个职称。
收入高,技术要求也高。
主要是会不会忽悠。
售前其实就是销售,牛逼一点的比架构师收入好。
如何做需求分析
一、 我们应当如何做需求分析需求分析不是一蹴而就的,它应当贯穿整个开发周期,不断的分析确认的过程。
这就是敏捷开发倡导的需求反馈。
敏捷开发认为,需求分析阶段不可能解决所有的需求问题,因此在设计、开发、测试,直到最终交付客户,这整个过程都应当不停地用开发的成果与客户交流,及时获得反馈。
只有这样才能及时纠正需求理解的偏差,保证项目的成功。
二、我们应当怎样做需求调研1.初识。
我们对客户提出的需求进行深入理解以后,运用我们专业知识,提出比客户的原始需求更加合理、可操作的解决方案,让客户感觉你说的正是他们想要的。
如果能够这样,客户不仅能够欣然接收你提出的方案,而且会感觉你非常专业,你在客户心目中的形象也会无形中提高,使你有更多的机会提出有利于开发的可行方案,降低开发的风险。
这毫无疑问会形成一个良性循环,但要做到这一点并不容易,毫无疑问,在与客户接触初期的表现起到了极其关键的作用。
(1)高层领导关心的是宏观的目标,因此软件研发目标、宏观统计报表、决策支持功能,我们应该怎样做需求分析,应当与高层领导谈。
(2)中层领导关心的是具体的效益,即软件给各个部门信息化管理方面带来的效益,因此,中层领导是各项业务流程、功能模块的需求决策者。
他们关心功能的定义、业务流转的衔接、查询报表的设计,但不太关心一些具体的操作,以及一些具体业务流程的细节。
(3)基层人员是每一项业务流程的操作者,也是软件今后真正的使用者。
他们是真正了解你所要开发的软件的业务需求的领域专家,是你进行需求调研的重点对象。
但是,基层人员往往受到自身视野的局限,可能只清楚自己工作涉及的十分狭小的一个范围,因此我们需要努力寻找那些业务涉及面广,经验丰富,又有一定大局观的真正的专家。
另外 ,他们就是软件今后真正的使用者,让他们参加,会让他们成为今后软件推行的忠实支持者,对其他操作人员的指导者,益处多多。
而他们关心的则是每项操作的细节。
俗话说:万事开头难。
如果你在项目开始的时候总感觉千头万绪不知如何着手,在这里我给大家的三点建议:1)树立良好的职业威信;2)进行详细角色分析,将与会各方代表对号入座;3)从宏观上制订目标与方案。
随后的工作,就是与各方代码建立联系,逐一拜访他们,将需求调研工作一步一步进行下去。
2.拜访。
需求调研不是一蹴而就的事情,是一件持续数月甚至数年的工作(假如项目还有后期维护) 。
在这漫长的时间里,我们需要依靠客户这个群体的帮助,一步一步掌握真实可靠的业务需求 。
不仅如此,技术这东西总有不如意甚至实现不了的地方,我们需要客户的理解与包容,这都需要有良好的客户关系。
尽管如此,我们也不能总是期望客户中的所有人都能与我们合作,很多项目都不可避免地存在阻碍项目开展的人。
3.研讨会。
(1)由于业务人员自身的局限 ,不可能对所有业务领域的细节全面掌握,往往总是有自己熟悉的部分,也有自己不熟悉的部分。
划分业务组,可以让业务人员分别在自己最熟悉的业务范围内参与讨论,可以有效提高业务讨论的质量;(2)集中式的业务研讨形式和分散式的业务研讨形式;(3)有效抑制个性化差异、分模块组织专项研讨会。
4.业务研讨在需求分析过程中,客户存在的最大问题就是提不出正确的需求,这表现为几种形式:(1)由于对软件不了解,客户提不出需求,不知道软件最终会做成什么样子。
这类客户在需求讨论过程中,往往只能描述目前自己手工管理的方式是怎样的,不知道计算机会怎样管理。
(2)能提出一些业务需求,但当软件做出来摆在自己面前时,需求就变了。
这类客户,他们能熟练使用电脑,对信息化管理是清楚的。
他们提出的业务需求从整体上应当是八九不离十的 。
但是,由于没有实物,在软件中的一些具体操作并没有完全想清楚。
(3)能非常详细地提出业务需求,甚至有时候该怎么做的提出来了。
这类客户,参与过很多软件信息化建设,甚至有些还是软件开发的半专业人士。
但是他们提出的业务需求过于具体 ,甚至怎样实现都说出来了,但这些有时候不是最佳设计方案、可能在技术上难于实现,甚至有些就是过于理想化而不可实现。
解决办法:业务领域分析:客户现有的业务流程是什么样的,都有些什么操作?客户在业务中都有些什么事物,什么专用名词,都是怎样定义的,相互之间的关系是什么?客户在每一项操作中的目的是什么,为什么要这样做,他们制作的手工报表都说明了什么问题?(1)我们做需求分析,眼界不能仅仅停留在软件本身,应当更开阔一些,应当扩展到跟这个业务有关的那些领域知识中。
(2)在客户提出的所有原始需求中那些与业务实现有关的需求都是无效的需求,它们仅仅只能作为我们的一个参考。
(3)还有一些是技术难于实现或者根本就无法实现的需求,我们应当耐心地说服和引导客户,并给他提出一个更加合理的方案。
(4)需求分析不是一种简单的你说我记的收集活动,而是在大量业务分析与技术可行性分析基础上的分析活动。
只有建立在这种分析基础上的软件研发,才能保证需求的正确与变更的可控。
5.迭代...
面试题:软件测试是否能够提高软件质量?
首先肯定这个观点,软件测试确实需要从需求分析入手,但是,国内大多数的软件公司的测试都是从集成测试开始的,甚至直接从系统测试开始,这样做不符合一般的流程,但是也没有什么办法,毕竟差距和国外有很大。
说说从需求分析开始的好处:首先,“尽早的了解被测系统”,这句经典的软件测试原则就体现出来了,早入手,早了解,至于能否深刻了解,还是看需求评审做的是否充足;第二,如果在需求分析阶段发现系统存在严重的Bug(此阶段的bug最多),或者发现不可测的地方,可以及时的进行修改,避免了后期修改bug的巨大的成本浪费。
以上两点是最主要的方面,把握住这两点就可以了。
什么叫做需求分析
所谓"需求分析",是指对要解决的问题进行详细的分析,弄清楚问题的要求,包括需要输入什么数据,要得到什么结果,最后应输出什么。
可以说,在软件工程当中的"需求分析"就是确定要计算机"做什么",要达到什么样的效果。
可以说需求分析是做系统之前必做的。
在软件工程中,需求分析指的是在建立一个新的或改变一个现存的电脑系统时描写新系统的目的、范围、定义和功能时所要做的所有的工作。
需求分析是软件工程中的一个关键过程。
在这个过程中,系统分析员和软件工程师确定顾客的需要。
只有在确定了这些需要后,他们才能够分析和寻求新系统的解决方法。
需求分析阶段的任务是确定软件系统功能。
软件行业分析报告
中国软件行业发展研究报告(2009资深版) 研究背景 研究方法 软件行业的界定和分类 1.行业定义、基本概念 2.行业基本特点 3.行业分类 第一章 软件行业国内外发展概述 一、软件行业国际发展总体概况 1.2005-2008年软件行业国际发展概况 2.主要国家和地区发展概况 3.软件行业国际发展趋势 二、中国软件行业发展概况 1.2005-2008年中国软件行业发展基本情况 2.中国软件行业发展中存在的问题 第二章 2009年中国软件行业发展环境分析 一、宏观经济环境 二、国际贸易环境 三、宏观政策环境 四、软件行业政策环境 五、软件行业技术环境 六、金融危机对软件行业发展环境的影响 第三章 软件行业市场分析 一、软件行业市场规模分析 1.2005-2008年软件行业市场规模及增速 2.软件行业市场饱和度 3.金融危机对软件行业市场规模的影响 4.2009-2012年软件行业市场规模及增速预测 二、软件行业市场结构分析 三、软件行业市场特点分析 1.软件行业所处生命周期 2.技术变革与行业革新对软件行业的影响 3.差异化分析 第四章 软件行业生产分析 一、软件行业生产总量分析 1.2005-2008年软件行业生产总量及增速 2.2005-2008年软件行业产能及增速 3.金融危机对软件行业生产的影响 4.2009-2012年软件行业生产总量及增速预测 二、子行业生产分析 三、细分区域生产分析 四、软件行业供需平衡分析 1.行业供需平衡现状 2.金融危机对软件行业供需平衡的影响 3.软件行业供需平衡趋势预测 第五章 软件行业竞争分析 一、软件行业集中度分析 二、软件行业竞争格局 三、软件行业竞争群组 四、软件行业竞争关键因素 1.价格 2.渠道 3.产品/服务质量 4.品牌 第六章 软件行业产品价格分析 一、价格特征分析 二、主要品牌企业产品价位 三、价格与成本的关系 四、行业价格策略分析 五、金融危机对软件行业产品价格的影响 第七章 软件行业用户分析 一、软件行业用户认知程度 二、软件行业用户关注因素 1.功能 2.质量 3.价格 4.外观 5.服务 三、用户的其它特性 第八章 软件行业替代品分析 一、替代品种类 二、替代品对软件行业的影响 三、替代品发展趋势 四、金融危机对软件行业替代品的影响 第九章 软件行业互补品分析 一、互补品种类 二、互补品对软件行业的影响 三、互补品发展趋势 四、金融危机对软件行业互补品的影响 第十章 软件行业主导驱动因素分析 一、国家政策导向 二、关联行业发展 三、行业技术发展 四、行业竞争状况 五、社会需求的变化 第十一章 软件下游行业分析 一、软件下游行业增长情况 二、软件下游行业区域分布情况 三、软件下游行业发展预测 四、金融危机对软件下游行业的影响 第十二章 软件行业渠道分析 一、渠道格局 二、渠道形式 三、渠道要素对比 四、各区域主要代理商情况 第十三章 中国软件行业盈利能力分析 一、2005-2008年行业销售毛利率 二、2005-2008年行业销售利润率 三、2005-2008年行业总资产利润率 四、2005-2008年行业净资产利润率 五、2005-2008年行业产值利税率 六、2009-2012年软件行业盈利能力分析预测 第十四章 中国软件行业成长性分析 一、2005-2008年行业销售收入增长分析 二、2005-2008年行业总资产增长分析 三、2005-2008年行业固定资产增长分析 四、2005-2008年行业净资产增长分析 五、2005-2008年行业利润增长分析 六、2009-2012年软件行业增长预测 第十五章 中国软件行业偿债能力分析 一、2005-2008年行业资产负债率分析 二、2005-2008年行业速动比率分析 三、2005-2008年行业流动比率分析 四、2005-2008年行业利息保障倍数分析 五、2009-2012年软件行业偿债能力预测 第十六章 中国软件行业营运能力分析 一、2005-2008年行业总资产周转率分析 二、2005-2008年行业净资产周转率分析 三、2005-2008年行业应收账款周转率分析 四、2005-2008年行业存货周转率分析 五、2009-2012年行业营运能力预测 第十七章 中国软件行业重点企业分析 一、行业前10家企业简介 二、行业前10家企业竞争力分析 三、行业前10家企业财务指标分析 第十八章 软件行业重点子行业分析 一、子行业发展现状 二、子行业发展特征分析 三、子行业发展趋势分析 四、金融危机对软件行业子行业的影响 第十九章 软件行业细分区域分析 一、华东地区 1.发展现状 2.发展特征 3.发展趋势分析 二、华南地区 1.发展现状 2.发展特征 3.发展趋势分析 三、东北地区 1.发展现状 2.发展特征 3.发展趋势分析 四、华北地区 1.发展现状 2.发展特征 3.发展趋势分析 五、华中地区 1.发展现状 2.发展特征 3.发展趋势分析 六、西部地区 1.发展现状 2.发展特征 3.发展趋势分析 第二十章 软件行业进出口现状与趋势分析 一、出口分析 1.出口量及增长情况 2.软件行业海外市场分布情况 3.经营海外市场的主要品牌 4.金融危机对软件行业出口的影响 二、进口分析 1.进口量及增长情况 2.软件行业进口产品主要品牌 3.金融危机对软件行业进口的影响 第二十一章 软件行业风险分析 一、软件行业环境风险分析 1.国际经济环境风险 2.汇率风险 3.宏观经济风险 4.宏观经济政策风险 5.区域经济变化风险 二、软件行业产业链上下游风险分析 1.上游行业风险 2.下游行业风险 3.其他关联行...
做图像类算法面试的时候会不会面试数学
我在《再谈逗我是怎么招程序员地》中比较保守地说过,逗问难的算法题并没有错,错的很多面试官只是在肤浅甚至错误地理解着面试算法题的目的。
地,今天,我想加强一下这个观点——我反对纯算法题面试!(注意,我说的是纯算法题)图片源Wikipedia(点击图片查看词条)我再次引用我以前的一个观点——能解算法题并不意味着这个人就有能力就能在工作中解决问题,你可以想想,小学奥数题可能比这些题更难,但并不意味着那些奥数能手就能解决实际问题。
好了,让我们来看一个示例(这个示例是昨天在微博上的一个讨论),这个题是——逗找出无序数组中第2大的数地,几乎所有的人都用了O(n)的算法,我相信对于我们这些应试教育出来的人来说,不用排序用O(n)算法是很正常的事,连我都不由自主地认为O(n)算法是这个题的标准答案。
我们太习惯于标准答案了,这是我国教育最悲哀的地方。
(广义的洗脑就是让你的意识依赖于某个标准答案,然后通过给你标准答案让你不会思考而控制你)功能性需求分析试想,如果我们在实际工作中得到这样一个题 我们会怎么做看我一定会分析这个需求,因为我害怕需求未来会改变,今天你叫我找一个第2大的数,明天你找我找一个第4大的数,后天叫我找一个第100大的数,我不搞死了。
需求变化是很正常的事。
分析完这个需求后,我会很自然地去写找第K大数的算法——难度一下子就增大了。
很多人会以为找第K大的需求是一种逗过早扩展地的思路,不是这样的,我相信我们在实际编码中写过太多这样的程序了,你一定不会设计出这样的函数接口 —— Find2ndMaxNum(int* array, int len),就好像你不会设计出 DestroyBaghdad(); 这样的接口,而是设计一个DestoryCity( City& ); 的接口,而把Baghdad当成参数传进去!所以,你应该是声明一个叫FindKthMaxNum(int* array, int len, int kth),把2当成参数传进去。
这是最基本的编程方法,用数学的话来说,叫代数!最简单的需求分析方法就是把需求翻译成函数名,然后看看是这个接口不是很二看!(注:不要纠结于FindMaxNum()或FindMinNum(),因为这两个函数名的业务意义很清楚了,不像Find2ndMaxNum()那么二)非功能性需求分析性能之类的东西从来都是非功能性需求,对于算法题,我们太喜欢研究算法题的空间和时间复杂度了。
我们希望做到空间和时间双丰收,这是算法学术界的风格。
所以,习惯于标准答案的我们已经失去思考的能力,只会机械地思考算法之内的性能,而忽略了算法之外的性能。
如果题目是——逗从无序数组中找到第K个最大的数地,那么,我们一定会去思考用O(n)的线性算法找出第K个数。
事实上,也有线性算法——STL中可以用nth_element求得类似的第n大的数,其利用快速排序的思想,从数组S中随机找出一个元素X,把数组分为两部分Sa和Sb。
Sa中的元素大于等于X,Sb中元素小于X。
这时有两种情况:1)Sa中元素的个数小于k,则Sb中的第 k-|Sa|个元素即为第k大数;2) Sa中元素的个数大于等于k,则返回Sa中的第k大数。
时间复杂度近似为O(n)。
搞学术的nuts们到了这一步一定会欢呼胜利!但是他们哪里能想得到性能的需求分析也是来源自业务的!我们一说性能,基本上是个人都会问,请求量有多大看如果我们的FindKthMaxNum()的请求量是m次,那么你的这个每次都要O(n)复杂度的算法得到的效果就是O(n*m),这一点,是书呆子式的学院派人永远想不到的。
因为应试教育让我们不会从实际思考了。
工程式的解法根据上面的需求分析,有软件工程经验的人的解法通常会这样:1)把数组排序,从大到小。
2)于是你要第k大的数,就直接访问 array[k]。
排序只需要一次,O(n*log(n)),然后,接下来的m次对FindKthMaxNum()的调用全是O(1)的,整体复杂度反而成了线性的。
其实,上述的还不是工程式的最好的解法,因为,在业务中,那数组中的数据可能会是会变化的,所以,如果是用数组排序的话,有数据的改动会让我重新排序,这个太耗性能了,如果实际情况中会有很多的插入或删除操作,那么可以考虑使用B+树。
工程式的解法有以下特点:1)很方便扩展,因为数据排好序了,你还可以方便地支持各种需求,如从第k1大到k2大的数据(那些学院派写出来的代码在拿到这个需求时又开始挠头苦想了)2)规整的数据会简化整体的算法复杂度,从而整体性能会更好。
(公欲善其事,必先利其器)3)代码变得清晰,易懂,易维护!(学院派的和STL一样的近似O(n)复杂度的算法没人敢动)争论你可能会和我有以下争论,如果程序员做这个算法题用排序的方式,他一定不会像你想那么多。
是的,你说得对。
但是我想说,很多时候,我们直觉地思考,恰恰是正确的路。
因为逗排序地这个思路符合人类大脑处理问题的方式,而使用学院派的方式是反大脑直觉的。
反大脑直觉的,通常意味着晦涩难懂,维护成本上升。
就是一道面试题,我就是想测试一下你的算法技能,这也扯太多了。
没问题,不过,我们要清楚我们是在招什么人看是一个只会写算法的人,还是一个会做软件的人看这个只有你自己最清楚。
这个算法题太容...