1了解linux系统吗，会做什么
参考答案：
Linux可以运行在服务器和其他大型平台之上，如大型机和超级计算机，是一个领先的操作系统。世界上500个最快的超级计算机90%以上运行Linux发行版或变种，最快的前10名超级计算机运行的都是Linux操作系统。
Linux也广泛应用在嵌入式设备上，如手机、平板电脑、路由器、电视和电子游戏机等。在移动设备上广泛使用的Android操作系统就是创建在Linux内核之上。
Linux是一款免费的操作系统，用户可以通过网络或其他途径免费获得，并可以任意修改其源代码。来自全世界的无数程序员参与了Linux的修改、编写工作，程序员可以根据自己的兴趣和灵感对其进行改变，这让Linux吸收了无数程序员的精华，不断壮大。
1、跨平台的硬件支持
由于Linux 的内核大部分是用C语言编写的，并采用了可移植的Unix标准应用程序接口，所以它支持如i386、Alpha、AMD和Sparc等系统平台，以及从个人电脑到大型主机，甚至包括嵌入式系统在内的各种硬件设备。
2、丰富的软件支持
与其他的操作系统不同的是，安装了Linux系统后，用户常用的一些办公软件、图形处理工具、多媒体播放软件和网络工具等都已无需安装。
而对于程序开发人员来说，Linux更是一个很好的操作平台，在Linux 的软件包中，包含了多种程序语言与开发工具，如gcc、cc、C 、Tcl/Tk、Perl、Fortran77 等。
3、完善的网络功能
Linux 内置了很丰富的免费网络服务器软件、数据库和网页的开发工具，如Apache、Sendmail、VSFtp、SSH、MySQL、PHP和JSP 等。近年来，越来越多的企业看到了Linux 的这些强大的功能，利用Linux 担任全方位的网络服务器。
2可以维护测试环境吗
参考答案：
搭建良好的测试环境是执行测试用例的前提，也是完成测试任务顺利完成的保证。测试环境大体可分为硬件环境和软件环境，硬件环境包括测试必须的PC机，服务器，设备，网线，分配器等硬件设备；软件环境包括数据库，操作系统，被测试软件，共存软件等；特殊条件下还要考虑网络环境，比如网络带宽，IP地址设置等。
搭建测试环境前后要注意以下几点：
1>搭建测试环境前，确定测试目的
即是功能测试，稳定性测试，还是性能测试，测试目的不同，搭建测试环境时应注意的点也不同。比如要进行功能测试，那么我们就不需要大量的数据，需要覆盖率高，测试数据要求尽量真实，这对硬件环境配置的好坏要求不是太苛刻，为提高覆盖率，就要配置不同的硬件环境。如要进行性能测试，就需要大量的数据，测试数据应尽可能的达到符合实际的数据分配，这时可能需要大量的设备来给测试对象施加压力，要提前准备大量设备。
2>测试环境时尽可能的模拟真实环境。
这个要求对测试人员要求很高，因为很多测试人员没有去过用户使用现场，要完全模拟用户使用环境根本不可能。这时我们就应该通过技术支持人员，销售人员了解，尽可能的模拟用户使用环境，选用合适的操作系统和软件平台，了解符合测试软件运行的最低要求及用户使用的硬件配置，了解用户常用的软件，避免所有配置所有操作系统下都要进行测试，没有侧重点，浪费时间。这样一方面，可以在测试执行过程中发生软件产品与其他协同工作产品之间的兼容性，避免软件发布给用户之后才发现的问题；另一方面也可以用来检验产品是不是用户真正需要的。多说情况下，测试环境都是真空环境，完全纯净的平台，测试时，没有问题，一旦拿到现场，与其它软件并存，硬件配置等原因，问题多多，这个就是搭建测试环境时没有考虑用户的使用环境。
3>确保无毒环境
我测试过几个项目都是因为搭建的测试环境感染病毒，导致测试软件经常出现莫名的崩溃，运行不起来等现象，导致测试中断。这是杀毒是必要的，但是杀毒的时间也应掌握好，具体可按照下列步骤：选择PC机-à安装操作系统—>安装杀毒软件杀毒—>安装驱动程序及用户常用软件及浏览器à杀毒à安装测试软件—>杀毒，安装测试软件后杀毒，要注意如果我们不是使用正版杀毒软件，很可能我们安装的测试软件的一些文件被当做可疑文件或者病毒被清除，导致测试软件直接不可用。要确保杀毒软件正版，如果不是正版，建议在安装测试软件前，卸载掉杀毒软件。测试过程中，要注意U盘的使用以及测试环境与外网的控制。每次使用U盘前，要在其它机器上先杀毒；当测试环境与外网联通时，不建议使用共享方式互访测试机。当小范围PC机与外界隔离起来做测试环境时，可以禁掉可移动存储设备的使用，只允许一台PC使用，这台PC机上安装杀毒软件，进行资料传送时，先拷贝到这台机器上杀毒，然后以共享的方式进行资料的传送。经过这些措施可以很好的防止病毒感染测试环境，确保无毒环境。
4>营造独立的测试环境
测试过程中要确保我们的测试环境独立，避免测试环境被占用，影响测试进度及测试结果，比如设备连网后，是不是其他测试组也在共用，这样就可能影响我们的测试结果。有时开发人员为确定问题会使用我们的测试环境，这样会打乱我们的测试活动，更严重的是影响测试进度。为避免这种情况，测试人员在提交缺陷单时，提供详细的复现步骤以及尽可能多的信息。让开发人员根据缺陷单，在开发环境中复现和定位问题。
5>构建可复用的测试环境
当我们刚搭建好测试环境，安装测试软件之前及测试过程中，对操作系统及测试环境进行备份是必要的，这样一来可以为我们下轮测试时直接恢复测试环境，避免重新搭建测试环境花费时间，二来在当测试环境遭到破坏时，可以恢复测试环境，避免测试数据丢失，重现问题。构建可“复用”的测试环境，往往要用到如ghost、Drive Image等磁盘备份工具软件;这些工具软件，主要实现对磁盘文件的备份和还原功能;在应用这些工具软件之前，我们首先要做好以下几件十分必要的准备工作：
A．确保所使用的磁盘备份工具软件本身的质量可靠性，建议使用正版软件;
B．利用有效的正版杀毒软件检测要备份的磁盘，保证测试环境中没有病毒
C.对于在测试过程中备份时，为减少镜像文件的体积，要删除掉Temp文件夹下的所有文件，要删除掉Win386.swp文件或_RESTORE文件夹，这样C盘就不至于过分膨胀，选择采用压缩方式进行镜像文件的创建，可使要备份的数据量大大减小;
D.最后，再进行一次彻底的磁盘碎片整理，将C盘调整到最优状态。
对于刚安装的操作系统，驱动程序等安装完成之后，测试程序安装之前，也要进行备份工作，这样可以防止不同项目交叉进行时，当使用相同操作系统时，直接恢复即可。
完成了这些准备工作，我们就可以用备份工具逐个逐个的来创建各种组合类型的软件测试环境的磁盘镜像文件了。对已经创建好的各种镜像文件，要将它们设成系统、隐含、只读属性，这样一方面可以防止意外删除、感染病毒;另一方面可以避免在对磁盘进行碎片整理时，频繁移动镜像文件的位置，从而可节约整理磁盘的时间;同时还要记录好每个镜像文件的适用范围，所备份的文件的信息等内容。
测试环境的搭建和维护处在重要的位置，它的好坏直接影响测试结果的真实性和准确性。维护测试环境需要大量的精力，不是一个人能完成的，需要我们大家积极配合。
31-3年职业规划
参考答案：
由于国内软件测试行业目前的发展迅速、需求旺盛，在国内的软件测试职位晋升一般要比国外快，但因行业本身太年轻，大家对软件测试中软件测试职业的发展了解不够，从而导致许多有志在此发展的年轻人举步不前。所以下面介绍一下海外公司成熟的软件测试行业职位分布情况，我国一些在软件测试行业中处于前端的公司与之也相仿，这可以作为软件测试职业规划的参考，给新人一个导向。
第一阶段：(测试员)初级测试工程师
自身条件：初入行具备计算机专业学位或一些手工测试经验的个人。
具体工作：执行测试用例，记录bug，并回归测试，通过qtp等测试工具录制回归测试脚本，并执行回归测试脚本。
学习方向：开发测试脚本并且开始熟悉测试生存周期和测试技术。
第二阶段：(测试工程师)程序分析员
自身条件：有1~2年工作经验的测试工程师或程序员。具有初步的自动化测试能力，完善自动化测试脚本。
具体工作：设计和编写测试用例，编写自动测试脚本程序且担任测试编程初期的领导工作。
学习方向：拓展编程语言、操作系统、网络与数据库方面的技能 。
第三阶段：(高级测试工程师)程序分析员
自身条件：有3~4年经验的测试工程师或程序员。具有一定的行业业务知识，储备系统分析员的能力。
具体工作：帮助开发或维护测试或编程标准与过程，分析软件需求，获得测试需求。确定测试需求相应的测试方法，获得测试策略方案。参与同行的评审(软件需求，软件测试计划等)，并为其它初级的测试工程师或程序员充当顾问。
学习方向:继续拓展编程语言、操作系统、网络与数据库方面的技能。
第四阶段：测试组负责人
自身条件：有4~6年经验的测试工程师或程序员。具有丰富的行业业务知识，具有系统分析员的能力，专长性能测试。
具体工作：负责管理1~3名测试工程师或程序员。集中于技能方面，担负一些进度安排和工作规模/成本估算职责。分析性能瓶颈的原因，为开发团队提供bug解决策略。
负责进度安排、工作规模/成本估算、按进度表和预算目标交付产品，负责开发项目的技术方法，能够为用户提供支持与演示；
学习方向：性能测试，测试技能
第五阶段：(资深安全或性能测试工程师)测试/编程高级负责人
自身条件：有6~10年经验的测试工程师或程序员。
具体工作：负责管理8~10名技术人员。性能测试整体方案设计，软件系统性能问题定位和性能优化，内存优化及分析数据溢出等，分析系统的安全漏洞等。负责进度安排、工作规模/成本估算、按进度表和预算目标交付产品。负责开发项目的技术方法。为一些用户提供支持与演示。
学习方向：开发一些特定领域的技术专长
第六阶段：测试/质量保证/开发(项目)、经理
自身条件：有10多年的工作经验。
具体工作：管理8名或更多的人员参加的1个或多个项目。负责这一领域(测试/质量保证/开发)内的整个开发生存周期业务。为一些用户提供交互和大量演示。负责项目成本、进度安排、计划和人员分工
第七阶段：(公司级质量总监)计划经理
自身条件：有15年以上开发与支持(测试/质量保证)活动方面的经验。
具体工作：管理从事若干项目的人员以及整个开发生存周期。负责把握项目方向与盈亏责任
职业生涯规划是人生的大事，下面我结合亲身经历，谈谈自己的观点：
step1：校园阶段 (毕业前1年～1.5年)
很多人的职业规划 是到了工作以后才开始进行的，其实，这样做，有很大的局限性。凡是工作过的人，都有一个体会，就是自己的第一份工作，会影响到5～10年的发展轨迹，甚至会对一生产生影响。因此，选择一份合适的工作作为起点，是必须要在校园内思考清楚的问题。
由于中国的教育基本是理论教育，大家在工作前的实践能力大多比较弱，固然有其不足，但也有好的一面，那就是可塑性比较好。可塑性好代表了选择的余地可以很大，因此，大家在选择第一份工的时候，要充分结合自己的教育背景、个人能力、兴趣爱好、长期目标等等，作出理性的决策。
软件测试，特别是黑盒软件测试是一种入门起点较低、上手迅速、且发展空间比较大的职业，因此，对于很多学生而言，作为进入IT就业的初级岗位，是非常合适的。
校园阶段的规划，主要是选择大的入门方向，当然，此时也可以给自己一个长期的目标，但是不必规划过细，因为，在没有入行前，一切都还未知，把握好路线即可。
下文假设大家选择的是软件测试～～
step2：入门阶段 (入行后3个月～1年)
对于刚刚入行的新人，这个时期是一个全面熟悉期，最能够学习到新的知识，也最有拼搏的热情和动力。建议大家可以借着这股冲劲，尽可能了解所在领域的全貌，了解各个主要分支的内容、特性、优势、局限性等等，并考察自己当前的工作环境，结合个人匹配程度和兴趣爱好，根据前述内容调整自己的规划。
对于测试行当而言，技术方面一般有几类：黑盒测试、白盒测试、自动化测试、测试工具、专用业务技能等;相关的管理方面一般有：测试管理、质量管理、项目管理等。
面对上述形形色色的方向，建议大家可以都稍稍了解下内涵，然后确定1～2个，作为中长期的主攻方向，达此标准，基本已经实现了入门，至于能否进得厅堂，就要看后期的努力了。
step3：提高阶段(入门后3年～5年)
对于入门后选择管理还是选择技术，其实这种问题，是无可无不可的，关键是看对自己的长期的定位了。不过，我个人建议当前阶段还是技术为重吧。毕竟，在一个技术环境中，要做好管理，没有扎实的基础，也难服众嘛。
本阶段是人最容易懈怠的阶段。毕竟，刚刚入行的热忱早已被日复一日的繁复工作给冷却，有了一定的工作经验，胜任本职，对于大多数人而言，绝不是问题。家庭、娱乐方面开始占据了业余生活的主流。可是，毕竟大家还很年轻，大多数人此时也不过20多岁，就此懈怠也是非常可怕的。因此，有规划的提高自身核心竞争力，在这个时候尤为关键。
提高是要提高的，但是对于大多数人而言，也没有必要很拼搏，此时处在一个比较稳定的职位上的你，可以考虑进行细化自己的中期规划了。根据选定的方向，制定一个自我提升的计划，并定义好自我检查的里程碑(譬如：每个季度或半年算一个阶段)，每天或者每周，有规律的学习一点即可。抱定一个目标——“每天进步一点点”，几年一大成不是问题。
我个人是反对急功近利的，倾向于稳打稳扎，这个阶段忌做“万金油”，而应努力成为有一技之长的“专家”。
对于选择做技术的人而言，这个阶段的达成标准，一般至少要能够熟悉你所选技术方向的大多数技术细节，“细节决定成败”嘛，虽然把握全局的能力是必要的，但是作技术而言，倘若不能钻的很细很深，恐怕也很难以高手自居吧。
对于选择做管理的人而言，我个人倾向是：此阶段接触管理的理念，并可以介入管理，但是此阶段不宜全面进入管理(除非你有更深层次的考虑，可以不去稳打稳扎)。学习管理的理念是非常重要的，其实管理更多一种思维和做事的方式，这门学问很深入，也不像技术，会不会是那么的显著，因此，建议多看多学，取长补短，并努力形成自己的做事风格。高级软件测试工程师，测试组长等，都是不错的含有技术特征的管理职位，此时的你应该能够胜任于此。
这个阶段的达成后，你也可以跻身老手行列，不必为求职犯愁，你应该可以很容易跳槽或时不时被猎头骚扰下，达成此阶段，你要做更深入的规划。
step4：升华阶段(老手后5年～10年)
此时的你，即将步入中年，不论是曾经专注技术还是偏爱管理的，都面临着家庭和社会的双重压力，你不可能像年轻人一样整天拼搏了，你需要稳定，因此，不能频繁的跳槽，建议考虑比较正规且有潜力的企业，要考虑给自己一个长远的发展规划。
正因为有前期的细节的背景的支撑，此时，你需要努力提升自己的宏观把握能力。哪怕做技术的，也要考虑适当的转型管理(中国特色是：工程师很难超过35岁的，一般人到了30岁不是转管理就是转商务了)。当然，一般人是技术做得越好，管理的时候，越容易切中项目要害。但是，对于从技术上来的人，关键是要开始培养和人打交道的能力。此阶段的关键是，需要逐步形成自己的管理风格，具备协调并行事务的能力。
当然，纯管理和技术型管理还是有所区别的。对于纯管理的人，熟练应用管理的科学理念，形成自己的风格尤为重要。纯管理的测试经理人，不仅仅可以做好测试方面的管理，其实也可以做好项目甚至其他的管理。其实，不管管理的对象是什么，它们的管理理念还是相通的。从测试管理中摸索出来的很多经验，可以很好的推广于其他的管理领域。而对于技术型管理的人，主要是带好技术团队，同时，不断补充新的技术知识，跟紧技术潮流。此时的你，有强大的技术背景支撑，不需要过分钻研细节，只需洞察核心，合理安排好你的团队成员即可。
这个阶段，也可能少数的人会选择离开具体的企业，而开始从事测试咨询，那是一个充满挑战的崭新开始，也必须有前期的积累方能胜任。
对于大多数人而言，此阶段中一个需要重点考虑的问题是，是否将测试作为自己的终生职位，如果是，基本上达到上述的目标，保持状态，基本可以做到退休的。如果不是，那就比较可怕了。其实我不建议此阶段的人转型，除非有充分的理由和很好的机遇。毕竟，达到此阶段，你已经付出了至少5年的努力，而且还是人生的黄金时段，时光一去不复返啊。当前状态下转行，请务必慎重。
4期望薪资
参考答案：
根据自己情况而定
5搭建环境
参考答案：
搭建良好的测试环境是执行测试用例的前提，也是完成测试任务顺利完成的保证。测试环境大体可分为硬件环境和软件环境，硬件环境包括测试必须的PC机，服务器，设备，网线，分配器等硬件设备；软件环境包括数据库，操作系统，被测试软件，共存软件等；特殊条件下还要考虑网络环境，比如网络带宽，IP地址设置等。
搭建测试环境前后要注意以下几点：
1>搭建测试环境前，确定测试目的
即是功能测试，稳定性测试，还是性能测试，测试目的不同，搭建测试环境时应注意的点也不同。比如要进行功能测试，那么我们就不需要大量的数据，需要覆盖率高，测试数据要求尽量真实，这对硬件环境配置的好坏要求不是太苛刻，为提高覆盖率，就要配置不同的硬件环境。如要进行性能测试，就需要大量的数据，测试数据应尽可能的达到符合实际的数据分配，这时可能需要大量的设备来给测试对象施加压力，要提前准备大量设备。
2>测试环境时尽可能的模拟真实环境。
这个要求对测试人员要求很高，因为很多测试人员没有去过用户使用现场，要完全模拟用户使用环境根本不可能。这时我们就应该通过技术支持人员，销售人员了解，尽可能的模拟用户使用环境，选用合适的操作系统和软件平台，了解符合测试软件运行的最低要求及用户使用的硬件配置，了解用户常用的软件，避免所有配置所有操作系统下都要进行测试，没有侧重点，浪费时间。这样一方面，可以在测试执行过程中发生软件产品与其他协同工作产品之间的兼容性，避免软件发布给用户之后才发现的问题；另一方面也可以用来检验产品是不是用户真正需要的。多说情况下，测试环境都是真空环境，完全纯净的平台，测试时，没有问题，一旦拿到现场，与其它软件并存，硬件配置等原因，问题多多，这个就是搭建测试环境时没有考虑用户的使用环境。
3>确保无毒环境
我测试过几个项目都是因为搭建的测试环境感染病毒，导致测试软件经常出现莫名的崩溃，运行不起来等现象，导致测试中断。这是杀毒是必要的，但是杀毒的时间也应掌握好，具体可按照下列步骤：选择PC机-à安装操作系统—>安装杀毒软件杀毒—>安装驱动程序及用户常用软件及浏览器à杀毒à安装测试软件—>杀毒，安装测试软件后杀毒，要注意如果我们不是使用正版杀毒软件，很可能我们安装的测试软件的一些文件被当做可疑文件或者病毒被清除，导致测试软件直接不可用。要确保杀毒软件正版，如果不是正版，建议在安装测试软件前，卸载掉杀毒软件。测试过程中，要注意U盘的使用以及测试环境与外网的控制。每次使用U盘前，要在其它机器上先杀毒；当测试环境与外网联通时，不建议使用共享方式互访测试机。当小范围PC机与外界隔离起来做测试环境时，可以禁掉可移动存储设备的使用，只允许一台PC使用，这台PC机上安装杀毒软件，进行资料传送时，先拷贝到这台机器上杀毒，然后以共享的方式进行资料的传送。经过这些措施可以很好的防止病毒感染测试环境，确保无毒环境。
4>营造独立的测试环境
测试过程中要确保我们的测试环境独立，避免测试环境被占用，影响测试进度及测试结果，比如设备连网后，是不是其他测试组也在共用，这样就可能影响我们的测试结果。有时开发人员为确定问题会使用我们的测试环境，这样会打乱我们的测试活动，更严重的是影响测试进度。为避免这种情况，测试人员在提交缺陷单时，提供详细的复现步骤以及尽可能多的信息。让开发人员根据缺陷单，在开发环境中复现和定位问题。
5>构建可复用的测试环境
当我们刚搭建好测试环境，安装测试软件之前及测试过程中，对操作系统及测试环境进行备份是必要的，这样一来可以为我们下轮测试时直接恢复测试环境，避免重新搭建测试环境花费时间，二来在当测试环境遭到破坏时，可以恢复测试环境，避免测试数据丢失，重现问题。构建可“复用”的测试环境，往往要用到如ghost、Drive Image等磁盘备份工具软件;这些工具软件，主要实现对磁盘文件的备份和还原功能;在应用这些工具软件之前，我们首先要做好以下几件十分必要的准备工作：
A．确保所使用的磁盘备份工具软件本身的质量可靠性，建议使用正版软件;
B．利用有效的正版杀毒软件检测要备份的磁盘，保证测试环境中没有病毒
C.对于在测试过程中备份时，为减少镜像文件的体积，要删除掉Temp文件夹下的所有文件，要删除掉Win386.swp文件或_RESTORE文件夹，这样C盘就不至于过分膨胀，选择采用压缩方式进行镜像文件的创建，可使要备份的数据量大大减小;
D.最后，再进行一次彻底的磁盘碎片整理，将C盘调整到最优状态。
对于刚安装的操作系统，驱动程序等安装完成之后，测试程序安装之前，也要进行备份工作，这样可以防止不同项目交叉进行时，当使用相同操作系统时，直接恢复即可。
完成了这些准备工作，我们就可以用备份工具逐个逐个的来创建各种组合类型的软件测试环境的磁盘镜像文件了。对已经创建好的各种镜像文件，要将它们设成系统、隐含、只读属性，这样一方面可以防止意外删除、感染病毒;另一方面可以避免在对磁盘进行碎片整理时，频繁移动镜像文件的位置，从而可节约整理磁盘的时间;同时还要记录好每个镜像文件的适用范围，所备份的文件的信息等内容。
测试环境的搭建和维护处在重要的位置，它的好坏直接影响测试结果的真实性和准确性。维护测试环境需要大量的精力，不是一个人能完成的，需要我们大家积极配合。
6测试流程
参考答案：
提取测试需求（根据产品整理的需求规格说明书）-->"测什么"
=> 编写测试计划
=> 制定测试方案
=> 设计测试用例 （测试需求告诉咱们"测什么"，具体"怎么测"，放在用例中）
=> 执行测试 (拿上开发出来的软件,按照测试用例设计的测试场景,执行测试)
=> 提交缺陷
=> 测试分析与评审
=> 提交测试报告 （测试人员脸面担当，测试在整个过程中做了哪些事情）
=> 准备下一个版本的测试
7系统测试是什么，需要考虑哪些方面
参考答案：
去搭建测试环境是软件测试实施的一个重要阶段，测试环境适合与否会严重影响测试结果的真实性和正确性。测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、网络连接设备，以及打印机/扫描仪等辅助硬件设备所构成的环境；软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境 一 确定测试环境的组成： 1．所需要的计算机的数量，以及对每台计算机的硬件配置要求，包括CPU的速度、内存和硬盘的容量、网卡所支持的速度、打印机的型号等； 2. 部署被测应用的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本； 3. 用来保存各种测试工作中生成的文档和数据的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本； 4. 用来执行测试工作的计算机所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本； 5. 是否需要专门的计算机用于被测应用的服务器环境和测试管理服务器的环境的备份； 6. 测试中所需要使用的网络环境。例如，如果测试结果同接入Internet的线路的稳定性有关，那么应该考虑为测试环境租用单独的线路；如果测试结果与局域网内的网络速度有关，那么应该保证计算机的网卡、网线以及用到的集线器、交换机都不会成为瓶颈； 二、管理测试环境 1. 设置专门的测试环境管理员角色 每个测试项目或测试小组都应当配备一名专门的测试环境管理员，其职责包括：测试环境的搭建。包括操作系统、数据库、中间件、WEB服务器等必须软件的安装，配置，并做好各项安装、配置手册的编写；记录组成测试环境的各台机器的硬件配置、IP地址、端口配置、机器的具体用途，以及当前网络环境的情况；测试环境各项变更的执行及记录；测试环境的备份及恢复；操作系统、数据库、中间件、WEB服务器以及被测应用中所需的各用户名、密码以及权限的管理； 2. 记录好测试环境管理所需的各种文档： 测试环境的各台机器的硬件环境文档，测试环境的备份和恢复方法手册，并记录每次备份的时间、备份人、备份原因以及所形成的备份文件的文件名和获取方式；用户权限管理文档，记录访问操作系统、数据库、中间件、WEB服务器以及被测应用时所需的各种用户名、密码以及各用户的权限，并对每次变更进行记录 3. 测试环境访问权限的管理 为每个访问测试环境的测试人员和开发人员设置单独的用户名和密码。访问操作系统、数据库、WEB服务器以及被测应用等所需的各种用户名、密码、权限，由测试环境管理员统一管理；测试环境管理员拥有全部的权限，开发人员只有对被测应用的访问权限和查看系统日志（只读），测试组成员不授予删除权限，用户及权限的各项维护、变更，需要记录到相应的“用户权限管理文档”中 4. 测试环境的备份和恢复 测试环境必须是可恢复的，否则将导致原有的测试用例无法执行，或者发现的缺陷无法重现，最终使测试人员已经完成的工作失去价值。因此，应当在测试环境（特别是软件环境）发生重大变动时进行完整的备份，例如使用Ghost对硬盘或某个分区进行镜像备份。
8你自身的哪些特点适合做软件测试这个工作
参考答案：
1、工作积极主动 工作态度如何，是评价一个测试人员最主要的方面，一个高水平的测试人员（指纯技术能力）如果没有一个好的工作态度，在测试团队中有时候不但不能对测试工作起到推动作用，有时候还起到阻碍作用，而一个愿意工作的测试人员，哪怕他的技术水平不高，人也不聪明，但对自己的工作认真负责，你告诉他的事情，他都可以认真去做，这个测试人员也会对测试工作起到很大的促进作用。这也是为什么很多企业愿意让刚参加工作的人员做测试工作的一个主要原因。另外，测试人员对工作是否主动也会很影响一个测试人员的发展，举一个例子，我的一个测试人员在自己工作空闲的时候会自己去学习QTP,提高自己的技术水平，这样在下一个测试的时候，他可以熟练的使用这个测试工具去进行自动化测试，不但提高了工作效率降低了工作强度而且为自己创造了更好的发展机会（后来被提升为测试组长）。所以说有效的利用工作时间，主动学习对一个人发展是很重要的。另外一个例子也差不多，我的一个测试人员，在自己的测试任务异常终止的时候，而其他测试组任务很忙的情况下，主动要求参加其他组的测试工作，先不说他的技术水平如何，这种主动要求工作的态度就让他从其他人中脱映而出，引起了我的重视，自然对他的工作会格外注意，而我们的每一次的交流都会让他学到很多新东西。 2、认真，细心，不怕麻烦 不能不说的是，测试工作是一个烦琐的工作，如果你不是认真、细心，不怕麻烦的人，建议你最好不要进入这个行业，否则，最后难受的肯定是你自己。 有那么一句话：细节决定成败，这句话格外适用于测试人员。测试人员的在做测试需求的时候，开发人员人员的写的系统需求报告中的每一个需求点都会在测试需求中成为几个测试需求点（你要验证正常情况，异常情况），有时候给人的感觉就象在玩排列组合的游戏，但这个游戏排列组合的情况实在太多了，如果你不够耐心，不够细心是很容易遗漏测试需求点的，而这些遗漏的地方往往是问题点（开发人员也容易忘记考虑这些地方，从而产生问题），另外测试工作输入的数据是一个很烦琐的事情举一个例子来说，一个日期合法性测试，很容易总结三、四百个测试数据，你想全部测试工作会是一个什么数量。而更可怕的是，测试不是一次性的工作，经常需要做回归测试，所有烦琐的工作必须不断的重复，而在重复的时候测试人员往往会因为怕麻烦，减少测试用例数，造成测试的不全面。所以说认真、细心、不怕麻烦是一个好的测试必备的素质要求。 3、学习能力强，善于总结 92年我参加工作的时候想找一本软件工程的书那叫一个困难，97年刚接触测试的时候，测试方面的书也几乎没有，这些都对我的水平的提高产生了很大的妨碍，但也并不能成为我们提高自己水平的借口，97年我们做的测试主要是功能测试，开始也是大猩猩测试，后来一方面从专业书籍里搜寻测试的资料，一方面总结我们自己的经验，1年以后我们基本形成了自己的测试流程和方法，我们有自己的测试计划的编写方法，测试用例编写的规范，测试总结的方法，新来的测试人员可以这些文件很快的提高自己的水平，后来的测试工具学习我们也是采用这种方法，在QTP的学习过程中，我的一个部下，学习了3个月，就基本掌握了QTP的使用，而且还总结了使用QTP常遇到的问题发表到了论坛上，很多了都认为他是一个技术大拿，其实他只是一个工作了8个月，学习了3个月的新手。不断的学习新技术，不断总结在实际工作遇到的问题，解决的方法，并把他们整理归纳，是一个测试人员提高自己的技术水平的最好的方法。还有两点需要说明的是：1、随着测试工作日益专业化，原来的低水平测试人员越来越不能满足测试的需要，测试工具的使用，测试理论的更新，新技术的应用都要求测试人员要不断提高自己的水平；2、好的测试人员不但要理解测试技术，对被测试系统以及开发环境和工具以及系统架构都要很了解才能制定合理的测试方案，也就是说测试负责人不要要了解测试技术，还要了解主流的开发技术、架构和工具（虽然不用成为专家），这一切都要测试人员不断的学习和总结。 4、掌握测试理论 开发工具在变，测试工具在变，被测试的系统在变，一切的东西都在边，那么作为一个测试人员最重要的是学习什么，个人认为是测试理论的学习，拿我自己的例子来说，我原来是做纯软件的，可是现在接触到了很多和硬件相关的测试，比如手机测试，但不管你测试的是什么系统基本理论是不变的，首先都需要开发人员提供比较好的需求文档。概要设计文档，详细设计文档，需求文档是我们制定测试需求的标准，也是我们判断系统是否存在问题的标准，而概要设计文档，详细设计文档是我们制作测试用例的依据。我们的划分等价类，边界值测试等基本测试的方法都需要这些文档的支持，当然每一种不同类型的测试，都有其特殊的地方，比如手机的测试就需要你对通讯理论有一定的了解（也就是系统环境），所以说好的测试人员必须数量掌握测试理论。如果你认为你的测试理论已经不错了，那就回答一下性能测试，负载测试，压力测试有什么区别这个问题吧。 5、不清谈，而是冲锋在前 我的一些测试人员，总是喜欢给我出主意，但却从来不考虑如何实施，他们喜欢的一句话就是，看我多聪明，一眼就可以问题的实质，头我这个参谋不错吧（我原来也是这样）。我要告诉大家这样的人实际已经落入了一个技术生涯的误区，看到问题可以说明你有一定的水平，但如何解决问题，如何实施才是真正体现一个人水平，中国文人当初因为怕杀头，产生了一个极为可怕的现象就是什么光清议，而从不肯去实践。这个不好的习惯我们现在叫做眼高手低。只有在解决实际问题的时候我们才能发现我们的解决方法有那些不足，会产生什么新的问题，从而不断改进我们的工作，一个简单的例子，我用TD已经很长时间了，可今天我还是能发现TD一些新的特点，并把这些特点用到我的工作中去，改进我的测试管理，所以个人认为好的测试人员总是那些冲锋在前的测试人员，在实际工作中才是提高功能能力的最好方法。
9编写过哪些必要的测试文档
参考答案：
一般情况下，项目相关的测试文档主要有以下几个 ：
1.测试计划。（详情可参考一份标准的测试计划包含哪些要素文章）测试计划由测试小组编写完成后，需同项目中相关人员进行评审，以确保当前的计划与项目进度等方面是一致的。
2.测试策略。一般情况下，较大型的项目会有附加的测试策略文档 ，即详情测试设计。与开发小组中的概要设计文档类似。测试策略文档编写完成后也需要由相关项目经理、开发人员进行评审 。了解测试设计的同时可以针对自己的开发习惯与出错点进行分析比较，使开发人员在项目早期避免一些Bug的产生。
3.测试用例文档。前边已提到过如何提升测试用例设计思维，可见测试用例是考察测试人员真实测试技能与水平的一项活动。同时测试用例一般根据测试计划及测试策略来编写，测试计划中会写清楚case设计的颗粒度及测试范围等等，并运用测试策略中提到的一些设计方法，同时结合当前项目中业务的特性来完整、有序的编写。与项目小组评审时，目的是查漏补缺，让项目经理清楚覆盖面，从而更准确评估项目风险。
4.测试报告 。主要供项目相关人员如项目经理、产品经理、开发经理、测试组成员及管理层查阅，以获得对本次项目的测试进度、产品问题等信息。并为后期迭代项目提供参考依据。
5.缺陷报告。主要记录产品的相关质量信息，以使项目相关成员了解缺陷集中区域，及缺陷类型，利用统计好的图表更直观展示。
测试成员个人的文档主要是为了辅助测试，同时可在测试过程中不断总结，以增强自身的技能。
1.测试需求架构图。即测试人员依据产品文档来重新设计的测试需求文档 ，目的是在编写测试文档时更好梳理。并静态检查其可测性。
2.用户文档。对于第三方测试或是专业业务的系统，用户文档需由测试编写。换句话说， 就是系统使用说明书，需要图文并茂，让非专业领域的用户也可以轻易按说明书上手。
3.测试草稿。即测试过程中对于复杂场景或需要计算的功能来设计方案，或是有些测试输入数据需要记录。
4.测试笔记。在测试过程中学习到的新技能或是有疑问的做好记录。用来在总结时参考 。
5.测试共享库。可以在项目开始前编写好模板，在项目过程中每个测试组成员都可以协同编写。如，出现频率较高的Bug， 较奇葩的Bug ，通用功能测试点的补充，顿悟到的一些测试理念等等，都可以写入共享库中， 在测试过程中大家可随时查阅，可以节省大量时间，项目结束后作为测试经验来记下，以在后续项目中注意。
10Linux命令
参考答案：
1.# 表示权限用户(如:root),$ 表示普通用户 开机提示ogin:输入用户名 password:输入口令 用户是系统注册用户成功登陆后，可以进入相应的用户环境. 退出当前shell,输入:exit
2.useradd netseek 添加一个netseek用户 passwd netseek 给netseek这个用户设置密码. (/etc/passwd /etc/group) userdel netseek 删除账号 userdel -r netseek 删除账号连同自家目录. [更详细的操作请参阅man page,和账号管理篇]
3.查看命令 ls -l 显示文件列表 ls -al -a 显示所有档案及目录 (ls内定将档案名或目录名称开头为"."的视为隐藏档，不会列出) ls -al |grep ''^d'' 显示目录 ls -al |grep ''^[^d]'' 在一个目录中查询不包含目录的所有文件 ls -sh (man ls 查看man帮助.) linux几种文件类型: d 表示此文件是一个目录 - 表示此文件是一个普通文件 b 表示此文件是一个特殊的块设备I/O文件 c 表示此文件是一个特殊的字符设备I/O文件 l 表示此文件是一个连接文件。在其文件名称后紧跟与它连接的文件路径及名称
file 命令通过探测文件内容判断文件类型
4.建立文件和目录 touch 1.txt cat > 2.txt (用定向符创建文件，填写内容后，按ctrl d保存内容) mkdir mywork 建立mywork这个目录
5.拷贝文件或目录 cp filename1 filename2 cp -r dir1 dir2 复制目录 cp -rf 参数f是删除已经存在的目标文件而不提示 cp -i 参数i和f相反，在覆盖目标文件之前将给出提示要求用户确认，回答y时目标文件将被覆盖，是交互式拷贝.
6.删除文件和目录(删除文件或目录都可以用rm搞定) rm 1.c //将1.c这个文件删除 rm -rf (强制删除文件或目录,删除时不提示.)
7.移走目录或者改文件名 mv [opitons] 源文件或目录 目标文件或目录 [options]主要参数 -i:交互方式操作，如果mv操作将导致对已存在的目标文件的覆盖，此时系统询问是否重写，要求用户回答“y”或“n”， 这样可以避免误覆盖文件. -f:禁止交互操作。mv操作要覆盖某个已有的目标文件时不给任何指示，指定此参数后i参数将不再起作用。 mv hello ../ 将hello目录或者文件移动上一级. 8.alias 别名 alias dir=''ls -l'' 输入dir，其实就相当于执行了ls -l
9.权限的控制(rwx 421) chmod x hello.sh 赋于可执行权限. (详细介绍一下权限的控制) chmod 命令 权限修改 用法：chmod 一位8进制数 filename (rwx 421) eg: chmod u x filenmame 只想给自己运行，别人只能读 chown netseek.netseek mydir 改变用户属组
u：表示文件所有者 g：表示同组用户 o：表示其它用户 a：表示所有用户 opt则是代表操作，可以为： ：添加某个权限 -：取消某个权限 =：赋予给定的权限，并取消原有的权限 而mode则代表权限： r：可读 4 w：可写 2 x：可执行 1
10.pwd 显示当前目录完整路径和改变目录 cd netseek 进入netseek这个目录 cd 退出当前目录 cd ../ 进入上一级目录. cd - 返回上一次目录 cd ~ 返回主目录
11. cat,more,less 命令 将某个文件的内容显示出来，两个命令不同的是:cat 把文件内容一直打印出来，而more则分展显示. less 可以上下翻滚查看内容. cat > 1.txt 可以填写或者复制内容,按ctrl d保存 cat 1.c more 1.c head -n filename 显示第N行的内容 tail -n filename 显示后N行的内容 tail -n 20 /var/log/message 显示最新的20行日志
12.设置linux时间和日期 date 命令("date MMDDhhmmYYYY.ss") 2006年7月24日12:37 ,30秒 date 072412372006.30 date -s 20:30:30 #设置系统时间为20: 30:30 date -s 2006-7-24 #设置系统时期为2006-7-24 clock -r #对系统Bios中读取时间参数 clock -w #将系统时间(如由date设置的时间)写入Bios
13.查看找文件(find,grep,awk更多的请参照man page或shell编程专题讲解) 几种介绍: find 路径 -name 文件名 find /etc -name named.conf locate 通过文件名搜索文件的工具(要先通过updatedb建立索引数据库) localte named.conf whereis 是寻找二进制文件，同时也会找到其帮助文件 which 和where 相似，只是我们所设置的环境变量中设置好的路径中寻找；比如；
14.查杀进程 ps aux ps -ef |grep kill -9 看看哪个进程占用的内存最大 ps -aux|sort 5n
将程序放在前后台执行 cp file1 file2 & &与ctrl z 你可以使用&或ctrl z来将命令放在后台执行. fg 是将放在后台执行的程序再放回前台. jobs
15.dd命令备份 dd if="input_file" of="out_file" bs="block_size" count="number" 参数: if:就是input file可以是设备 of:就是output file也可以是设备 bs:规划的一个block的大小，如果没有设定时，预设是512bytes count:多少个bs的意思.
dd if=/etc/password of=/tmp/passwd.bak 备份
16.mount 加载一个硬件设备 用法:mount [参数] 要加载的设备 载入点 eg: mount /dev/cdrom cd /mnt/cdrom //进入光盘目录 u盘: mkdir /mnt/usb；（注：创建挂载目录） mount /mnt/sda1 /mnt/usb；(注：挂载U盘) 现在就可以使用U盘了，在/mnt/usb目录下的内容就是U盘里的内容了； 使用完后，用以下命令卸载U盘即可。 umount /mnt/usb mount 列出系统所有的分区 mount -t iso9660 /dev/cdrom /mnt/cdrom 挂载光盘 mount -t vfat /dev/fd0 /mnt/floppy 挂载软盘 mount -t vfat -o iocharset=utf8,umask=000 /dev/hda2 /mnt/hda2 挂载fat32分区 mount -t ntfs -o nls=utf8,umask=000 /dev/hda3 /mnt/hda3 挂载ntfs分区 Linux-NTFS Project: http://linux-ntfs.sourceforge.net/ umount /mnt/hda3 缷载 注:挂载设备前，请先fdisk -l 看一下.
17.su在不退出登陆的情况下，切换到另一个身份 用法: su -l 用户名(如果用户名缺省,则切换到root状态) eg:su -l netseek (切换到netseek这个用户，将提示输入密码),加上-表示切换到用户的环境变量. sudo 利用他可以执行root执行的权限
18.whoami,id,w,lastlog,users,groups w 查看用户登陆信息 who 查看当前登陆用户 last 最近一个月用户登陆情况 lastlog 检查某特定用户上次登录的时间，并格式化输出上次登录日志/var/log/lastlog的内容 whoami 确认自己身份. id 打印出自己的UID以及GID.(UID:用户身份唯一标识.GID:用户组身份唯一标识.每一个用户只能有一个唯一的UID和GID.) users groups 用户所归属的用户组查询； finger -l netseek root finger -s 或者直接finger 可以让使用者查询一些其他使用者的资料 eg: finger //查看所用用户的使用资料 finger root //查看root的资料
19.用户用过的命令和执行历史执行的命令 history 显示用户过去命用的命令 !!执行最近一次的命令
20.uname 查看linux系统信息 参数:-a 所有信息 -r 版本号 -n 主机名
21.建立软连接 ln [-sf] source target ln souce-file hard-link ln -sf source-file soft-link s表示软连接,f表示，若有同名文件在，则将它覆盖过去. 注：硬链接不能为目录创建，只有文件才能创建硬链接。
22.查看目录 du -sh 目录或者文件 du -m du系统默认输出是以KB,以参数-m表示以MB显示. cat /etc/fstab 查看分区列表 fdisk -l df -h df -ah
23.查看linux系统占用的资源(top,free,uptime) top 查看后台程序，监控系统性能 top -d 2 每两秒列新一次 top -d -2 -p3690 查看某个PID top -b -n 2 >/tmp/top.txt 将top的信息进行2次，然后将结果输出到/tmp/top.txt free -m 查看系统内存使用情况
uptime 显示目前系统开机时间(查看开机多久，多少人登陆，过去1,5,15分钟系统的负载)
24.文件比软件: cmp cmp（“compare”的缩写）命令用来简要指出两个文件是否存在差异，它的使用权限是所有用户 diff diff命令用于两个文件之间的比较，并指出两者的不同，它的使用权限是所有用户
25.远程操作与文件传输 ssh user@remote.machine scp user@remote.machine:/remote/path /local/path scp /local/path user@remote.machine:/remote/path
26.编译c/c 文件 gcc gcc -v 查看GCC版本 gcc -o test test.c 2>errfile 编译test.c时若有错误信息，则将错误信息重定向到errfile
27.chattr i filename 禁止删除，chattr -i filename 取消禁止 lsattr 查看隐藏档属性
28.自动化执行 at 执行一次 crontab 定时循环执行程序 crontab 介绍 1 以root登录 2 # crontab -e 3 加入一行 1 */12 * * * /usr/sbin/ntpdate pool.ntp.org 分钟 （0-59） 小時 （0-23） 日 期 （1-31） 月份 （1-12） 星期 （0-6）//0代表星期天
29.关机和重启: shutwond [-t 秒数] [-rkhncff] 时间 [警告信息] -t 秒数:设置在切换至不同的runlevel之前，警告和删除两信号之彰间的延迟时间(秒) -k 发出警告信息，但不是真的要shutdown -r shutdown这后重新开机 -h shutdown这后开机 -n 不经过init,由shutdown命令本身来做开机工作(不建议你使用) -f 重新开机时，跳过fsck指令，不检查文件系统. -F 重新开机时，强迫做fsck检查. -c 将已经正在shutdown的动作取消 shutdown -h now 立刻关机，其中now相当于时间为0,halt,poweroff也可以关机,或者直接init 0 shutdown -h 20:30 系统将在今晚的8:30关机 shutdown -h 10 系统再过十分钟后自动关机. shutdown -t3 -r now 立刻重新开机，但在警告和删除processes这间， shutdown -k now ''Hey! Go away! now...'' 发出警告信息，但没有真的关机. reboot: shutdown -r now 几乎与reboot相同，不关建议用reboot执行如下: shutdown -r 30 ''The system wiil reboot'' shutdown -r 10 ''Hey!Go away!'' 10分钟后系统重启. #sync; sync; sync; reboot 注：sync将数据同步写入硬盘 halt命令相当于shutdown -h now ，表示立刻关机。 reboot命令相当于shutown -r now ，表示立刻重起。
30.如何改变启动模式运行级别 vi /etc/inittab 将5改成3，启动后就可以变成字符模式。 startx 或者 init 5 就可以进入图形化界面. runlevel 显示当前运行级别
如何切换至单用户模式 利用telinit或init(其实telinit只是一个synbol link to init) telinit 1 或者 init S 即可，当然telinit S也是可以的.
如何使ctrl alt del 三键失效的方法 #vi /etc/inittab 在ca::ctrlaltdel:/sbin/shutdonw -t3 -r now之前加上注释# 然后执行#telinit q ,参数q是要telinit重新检查一次/etc/inittab
31.TAB 巧用tab键，当你不知道文件或命令的全名是请连续按两下tab键.
32.clear 清屏
33.dmesg |more 显示开机信息(查看系统启动时硬件信息) 34.改变程序执行的优秀级 nice 设置优先权 nice -n -5 vi & 用root给一个nice值为-5,用于执行vi renice 调整已存在优先权
35.模块相关的命令 lsmod 显示已经载入系统的模块 depmod 分析可载入系统的相依性 modinfo 显示kernel模块的信息 insmod 载入模块 modprobe 自动处理可载入模块 rmmod 删除模块 36.chkconfig --list 显示各种服务的状态，利用chkconfig可以轻松管理init脚本.
37.linux的几种解压缩命令 compress aaa 将aaa文件压缩成为aaa.Z compress -d aaa.z 将aaa.z文件压缩成aaa gzip aaa 压缩命令 gzip -d aaa.gz 解压命令 bzip2 -z filename 压缩,同上加-d参数解压 bzcat filename.bz 查看压缩文件内容 tar czvf aaa.tar.gz aaa 将目录aaa压缩成aaa.tar.gz tar -N ''2007/03/01'' -zcvf home.tar.gz /home 在/home当中,比2007/03/01新的文件才备份. tar --exclude /home/cao -zxvf myfile.tar.gz /home/* /etc 要备份/home,/etc，但不要/home/cao cd /tmp; tar -cvf -/etc | tar -xvf - 将/etc/打包后直接解开/tmp底下，而不产生文件. tar zxvf aaa.tar.gz 解压缩命令. tar jxvf aaa.tar.bz2 解压命令 tar zxvf aaa.tar.gz -C /var/www 将aaa.tar.gz解压到/var/www目录下 cpio -covB > [file|device] 备份 cpio -icduv < [file|device] 还原
38.网络命令 ifconfig 显示或设置网络设备,可以查看当前ip,类似于windows里的ipconfig service network restart(/etc/rc.d/init.d/network restart) 重启网卡 ifdown eth0 关闭网卡 ifup eth0 开启网卡 route -n 查看路由表 route add -net 192.168.20.1 netmask 255.255.255.0 dev eth0 netstat 查看网络连接情况 netstat -i 显示网卡运行情况 netstat -r 查看主机的路由列表 traceroute hostname 显示主机名 hostname -i 显示当前主机名的IP.
39.系统集成管理菜单. setup 系统服务管理命令 ntsysv 设置系统服务
40.fdisk /mbr 删除GRUB
41.数据库启动 启动mysql： service mysqld start(/etc/rc.d/init.d/mysqld start) mysql -uroot -p 输入密码即可操作mysql数据库.
启动Oraclesu - oraclelsnrctl stoplsnrctl startsqlplus /nologconn /as sysdba(connected)startup
42.安装软件包 rpm包安装: rpm -ivh xxx.rpm 安装rpm包 rpm -qa --last | less 根据安装日期显示已经安装的包 rpm -qa |grep mysql -i 查询系统是否安装mysql包(-i,忽略大小写) rpm -e 删除安装的软件包 rpm -e mysql* --nodpes 强制删除相关的软件包 rpm --test 测试安装 rpm -qi 查询mysql套件的说明资料 rpm -qpl xxx.rpm 查看rpm包内含的内容. rpm -qc[d] 设定档与说明档 rpm -Uvh 升级安装 rpmbuild --bb SPECS/xxx.spec 重新装将xxx.spec编译成rpm包. rpmbuild --rebuild packagename.src.rpm 重新把.src.rpm编译成rpm包.
源码编译安装(经典) ./configure 检查系统信息(./configure --help | more 帮助信息，可以看到相关的参数设定) make clean 清除之前留下的文件 make 编译 make install 安装 注:源码包安装，一般先将文件解压，安装过程大致上面几步，具体说明一般见解压后目录里的(INSTALL,READEME说明.)
11数据库基本功能
参考答案：
数据库管理 系统(Database Management System)是一种操纵和管理数据库的大型软件，用于建立、使用和维护 数据库，简称 DBMS。它对 数据库进行统一的管理和 控制，以保证 数据库的安全性和完整性。用户通过 DBMS访问 数据库中的数据， 数据库管理员也通过 dbms进行数据库的维护工作。它可使多个 应用程序和用户用不同的方法在同时或不同时刻去建立，修改和询问 数据库。大部分 DBMS提供 数据定义语言DDL（Data Definition Language）和 数据操作语言 DML（Data Manipulation Language），供用户定义 数据库的模式结构与权限约束，实现对数据的追加、删除等操作。
数据库管理系统是数据库系统的核心，是管理数据库的软件。数据库管理系统就是实现把用户意义下抽象的逻辑数据处理，转换成为计算机中具体的物理数据处理的软件。有了数据库管理系统，用户就可以在抽象意义下处理数据，而不必顾及这些数据在计算机中的布局和物理位置。
主要功能编辑
1. 数据定义：DBMS提供 数据定义语言DDL（Data Definition Language），供用户定义 数据库的三级模式结构、两级映像以及完整性约束和保密限制等约束。DDL主要用于建立、修改 数据库的库结构。DDL所描述的库结构仅仅给出了 数据库的框架，数据库的框架信息被存放在 数据字典（Data Dictionary）中。
2.数据操作：DBMS提供 数据操作语言DML（Data Manipulation Language），供用户实现对数据的追加、删除、更新、查询等操作。
3. 数据库的运行管理：数据库的运行管理功能是DBMS的运行控制、管理功能，包括多用户环境下的 并发控制、安全性检查和存取限制控制、完整性检查和执行、运行日志的 组织管理、 事务的管理和自动恢复，即保证事务的原子性。这些功能保证了数据库 系统的正常运行。
4.数据 组织、存储与管理：DBMS要分类组织、 存储和管理各种数据，包括 数据字典、用户数据、存取路径等，需确定以何种文件结构和存取方式在存储级上组织这些数据，如何实现数据之间的联系。数据 组织和存储的基本目标是提高 存储空间利用率，选择合适的存取方法提高存取效率。
5. 数据库的保护：数据库中的数据是信息社会的战略资源，所以数据的保护至关重要。DBMS对 数据库的保护通过4个方面来实现：数据库的恢复、数据库的 并发控制、数据库的 完整性控制、数据库安全性控制。DBMS的其他保护功能还有 系统缓冲区的管理以及数据存储的某些自适应 调节机制等。
6. 数据库的维护：这一部分包括数据库的数据载入、转换、转储、 数据库的重组合重构以及性能监控等功能，这些功能分别由各个使用程序来完成。
7.通信：DBMS具有与操作系统的 联机处理、 分时系统及远程作业输入的相关接口，负责处理数据的传送。对网络环境下的 数据库系统，还应该包括DBMS与网络中其他软件系统的通信功能以及数据库之间的互操作功能。
12测试方法有哪些
参考答案：
软件测试的方法根据软件工程的组织和实现方式，有很大差别，有些是比较技术化的方法，有些则是工程方法，主要分为： 黑盒测试方法群：等价类划分、边界值、因果图、基路径法、专家测试法、smoking、场景测试等 白盒测试方法群：同行评审、需求审查、代码审查、接口测试（调用测试和返回测试，需要结合等价类和因果图方法）等。 当在单元层面黑盒而在集成层面白盒时，基本上两类方法就会有结合了，就会出现习惯上说的灰盒测试（说实话，不做到纯产品级开发，基本上都是用的灰盒测试）。
13测试流程
参考答案：
参考答案：
提取测试需求（根据产品整理的需求规格说明书）-->"测什么"
=> 编写测试计划
=> 制定测试方案
=> 设计测试用例 （测试需求告诉咱们"测什么"，具体"怎么测"，放在用例中）
=> 执行测试 (拿上开发出来的软件,按照测试用例设计的测试场景,执行测试)
=> 提交缺陷
=> 测试分析与评审
=> 提交测试报告 （测试人员脸面担当，测试在整个过程中做了哪些事情）
=> 准备下一个版本的测试
14测试环境是否和开发同一个环境
参考答案：
开发环境要不要和测试环境隔离？要就是说，是不是要各用一套数据库等基础设施？
能隔离当然最好，开发人员和测试人员不会互相干扰。但隔离是有代价的，它意味着你要多引一个数据库，如果你的系统是分布式的，你还要多维护一套MQ、RPC中间件等。
依我看，需不需要隔离要看系统是否满足下面的三个条件：
1、两个环境的系统总是要接触到同一份数据
2、数据被一个系统接触后，业务状态会改变；导致这份数据对另一个系统不再可用
3、很难禁止两个系统在同一时刻接触到同一份数据
解释：
条件1.如果两个环境共享数据库，但开发环境只处理北方数据，测试环境只处理南方的，那不用隔离
条件2.即使两个环境都会处理北方数据，但如果这种处理是只读的，也就是开发环境用了，测试环境可以再用，那也无所谓
条件3.即使数据被一个环境处理后，另一个不能用；但如果对数据的接触是人为触发的，也就是说开发环境被人触发数据改动时，不会干扰测试环境的测试，那也无所谓。
具体的场景：
1、纯读的网站不必隔离，它不满足条件2
2、有写、但所有操作都由用户触发的网站也不必隔离，因为它不满足条件3
3、以全局数据为目标的自启应用需要隔离，比如Quartz，Cron，MQ消费者等，因为它们不满足条件1。以MQ应用为例，如果外部发来的某个数据被测试环境消费过了，开发环境就无法再消费了，这时你应该为开发和测试环境各配一个MQ
4、对自启应用，如果实在不想隔离，就要在代码里做一些env-specific的东西，使得不同环境不会访问到相同的数据，比如开发环境只能访问数据库里flag=Dev的记录。不过，这种作法对程序和数据的侵入都很大，不值得提倡。但这种做法可以应用到其他环境的隔离上，比如预发环境和正式环境，它们必须使用相同的数据库。
15上家公司加班吗？来我们这边的话，会加班，995能接受吗
参考答案：
自己酌情回答
16微信加一个视频功能你怎么设计用例
参考答案：
使用移动网络环境下会提示“影响视频和音频质量，并产生手机流量” 发起视频通话，可点击挂断取消通话 发起视频通话，是否可以听到铃声 对方接听前是香可以切换到语音通话 对方正在视频通话是否会有提示信息“对方忙” 发起视频通话后，对方无响应 发起视频通话后，对方不在线 发起视频通话后，对方拒接 声音画面是否同步 是否可以切换到语音通话前后摄像头转换是否正常插拔耳机是否能正常通话 视频通话中 点击对方视频窗口，窗口交换点击音量键，是否可以调节音量点击返回键 点击Home键与其他应用切换 视频通话接通后，立即挂断视频通话视频通话结束，发起者结束通话 视频通话结束，接收者结束通话 通话结束后，是否会返回聊天页面
.频繁发起视频通话 网络质量差是否有提示信息 邀请的用户是否都可以进入视频通话 未被邀请的用户能否进入视频通话 多人视频通话 不勾选邀请好友是否可以发起视频通话勾选好友后，确定按钮才可以点击 在群聊里发起视频通话是否有消息显示 在群里视频通话结束是否有通话已经结束提示 无网络能否发起视频通话 无网络能否接受视频通话 网络质量不好的情况下发起视频通话网络质量不好的情况下接受视频通话视频通话中有新的视频邀请 视频通话中断电 视频通话中断网 视频通话中来电话、短信 视频通话时手机重启 视频通话中手机死机 视频通话时微信版本升级
视频通话接听后响应速度 多人视频通话可容纳的人数上限 长时间视频是否保持正常 cpu 内存消耗流量消耗 不同网络测试 2G、3G、4G不同网速 不同手机 不同操作系统 不同微信版本 与其他音视频软件的兼容性 可切换为语音通话 操作的提示信息 界面布局合理，颜色搭配合理 界面文字、图片显示正常 操作过程中的各种提示信息显示正常
17对这个岗位的规划？
参考答案：
由于国内软件测试行业目前的发展迅速、需求旺盛，在国内的软件测试职位晋升一般要比国外快，但因行业本身太年轻，大家对软件测试中软件测试职业的发展了解不够，从而导致许多有志在此发展的年轻人举步不前。所以下面介绍一下海外公司成熟的软件测试行业职位分布情况，我国一些在软件测试行业中处于前端的公司与之也相仿，这可以作为软件测试职业规划的参考，给新人一个导向。
第一阶段：(测试员)初级测试工程师
自身条件：初入行具备计算机专业学位或一些手工测试经验的个人。
具体工作：执行测试用例，记录bug，并回归测试，通过qtp等测试工具录制回归测试脚本，并执行回归测试脚本。
学习方向：开发测试脚本并且开始熟悉测试生存周期和测试技术。
第二阶段：(测试工程师)程序分析员
自身条件：有1~2年工作经验的测试工程师或程序员。具有初步的自动化测试能力，完善自动化测试脚本。
具体工作：设计和编写测试用例，编写自动测试脚本程序且担任测试编程初期的领导工作。
学习方向：拓展编程语言、操作系统、网络与数据库方面的技能 。
第三阶段：(高级测试工程师)程序分析员
自身条件：有3~4年经验的测试工程师或程序员。具有一定的行业业务知识，储备系统分析员的能力。
具体工作：帮助开发或维护测试或编程标准与过程，分析软件需求，获得测试需求。确定测试需求相应的测试方法，获得测试策略方案。参与同行的评审(软件需求，软件测试计划等)，并为其它初级的测试工程师或程序员充当顾问。
学习方向:继续拓展编程语言、操作系统、网络与数据库方面的技能。
第四阶段：测试组负责人
自身条件：有4~6年经验的测试工程师或程序员。具有丰富的行业业务知识，具有系统分析员的能力，专长性能测试。
具体工作：负责管理1~3名测试工程师或程序员。集中于技能方面，担负一些进度安排和工作规模/成本估算职责。分析性能瓶颈的原因，为开发团队提供bug解决策略。
负责进度安排、工作规模/成本估算、按进度表和预算目标交付产品，负责开发项目的技术方法，能够为用户提供支持与演示；
学习方向：性能测试，测试技能
第五阶段：(资深安全或性能测试工程师)测试/编程高级负责人
自身条件：有6~10年经验的测试工程师或程序员。
具体工作：负责管理8~10名技术人员。性能测试整体方案设计，软件系统性能问题定位和性能优化，内存优化及分析数据溢出等，分析系统的安全漏洞等。负责进度安排、工作规模/成本估算、按进度表和预算目标交付产品。负责开发项目的技术方法。为一些用户提供支持与演示。
学习方向：开发一些特定领域的技术专长
第六阶段：测试/质量保证/开发(项目)、经理
自身条件：有10多年的工作经验。
具体工作：管理8名或更多的人员参加的1个或多个项目。负责这一领域(测试/质量保证/开发)内的整个开发生存周期业务。为一些用户提供交互和大量演示。负责项目成本、进度安排、计划和人员分工
第七阶段：(公司级质量总监)计划经理
自身条件：有15年以上开发与支持(测试/质量保证)活动方面的经验。
具体工作：管理从事若干项目的人员以及整个开发生存周期。负责把握项目方向与盈亏责任
职业生涯规划是人生的大事，下面我结合亲身经历，谈谈自己的观点：
step1：校园阶段 (毕业前1年～1.5年)
很多人的职业规划 是到了工作以后才开始进行的，其实，这样做，有很大的局限性。凡是工作过的人，都有一个体会，就是自己的第一份工作，会影响到5～10年的发展轨迹，甚至会对一生产生影响。因此，选择一份合适的工作作为起点，是必须要在校园内思考清楚的问题。
由于中国的教育基本是理论教育，大家在工作前的实践能力大多比较弱，固然有其不足，但也有好的一面，那就是可塑性比较好。可塑性好代表了选择的余地可以很大，因此，大家在选择第一份工的时候，要充分结合自己的教育背景、个人能力、兴趣爱好、长期目标等等，作出理性的决策。
软件测试，特别是黑盒软件测试是一种入门起点较低、上手迅速、且发展空间比较大的职业，因此，对于很多学生而言，作为进入IT就业的初级岗位，是非常合适的。
校园阶段的规划，主要是选择大的入门方向，当然，此时也可以给自己一个长期的目标，但是不必规划过细，因为，在没有入行前，一切都还未知，把握好路线即可。
下文假设大家选择的是软件测试～～
step2：入门阶段 (入行后3个月～1年)
对于刚刚入行的新人，这个时期是一个全面熟悉期，最能够学习到新的知识，也最有拼搏的热情和动力。建议大家可以借着这股冲劲，尽可能了解所在领域的全貌，了解各个主要分支的内容、特性、优势、局限性等等，并考察自己当前的工作环境，结合个人匹配程度和兴趣爱好，根据前述内容调整自己的规划。
对于测试行当而言，技术方面一般有几类：黑盒测试、白盒测试、自动化测试、测试工具、专用业务技能等;相关的管理方面一般有：测试管理、质量管理、项目管理等。
面对上述形形色色的方向，建议大家可以都稍稍了解下内涵，然后确定1～2个，作为中长期的主攻方向，达此标准，基本已经实现了入门，至于能否进得厅堂，就要看后期的努力了。
step3：提高阶段(入门后3年～5年)
对于入门后选择管理还是选择技术，其实这种问题，是无可无不可的，关键是看对自己的长期的定位了。不过，我个人建议当前阶段还是技术为重吧。毕竟，在一个技术环境中，要做好管理，没有扎实的基础，也难服众嘛。
本阶段是人最容易懈怠的阶段。毕竟，刚刚入行的热忱早已被日复一日的繁复工作给冷却，有了一定的工作经验，胜任本职，对于大多数人而言，绝不是问题。家庭、娱乐方面开始占据了业余生活的主流。可是，毕竟大家还很年轻，大多数人此时也不过20多岁，就此懈怠也是非常可怕的。因此，有规划的提高自身核心竞争力，在这个时候尤为关键。
提高是要提高的，但是对于大多数人而言，也没有必要很拼搏，此时处在一个比较稳定的职位上的你，可以考虑进行细化自己的中期规划了。根据选定的方向，制定一个自我提升的计划，并定义好自我检查的里程碑(譬如：每个季度或半年算一个阶段)，每天或者每周，有规律的学习一点即可。抱定一个目标——“每天进步一点点”，几年一大成不是问题。
我个人是反对急功近利的，倾向于稳打稳扎，这个阶段忌做“万金油”，而应努力成为有一技之长的“专家”。
对于选择做技术的人而言，这个阶段的达成标准，一般至少要能够熟悉你所选技术方向的大多数技术细节，“细节决定成败”嘛，虽然把握全局的能力是必要的，但是作技术而言，倘若不能钻的很细很深，恐怕也很难以高手自居吧。
对于选择做管理的人而言，我个人倾向是：此阶段接触管理的理念，并可以介入管理，但是此阶段不宜全面进入管理(除非你有更深层次的考虑，可以不去稳打稳扎)。学习管理的理念是非常重要的，其实管理更多一种思维和做事的方式，这门学问很深入，也不像技术，会不会是那么的显著，因此，建议多看多学，取长补短，并努力形成自己的做事风格。高级软件测试工程师，测试组长等，都是不错的含有技术特征的管理职位，此时的你应该能够胜任于此。
这个阶段的达成后，你也可以跻身老手行列，不必为求职犯愁，你应该可以很容易跳槽或时不时被猎头骚扰下，达成此阶段，你要做更深入的规划。
step4：升华阶段(老手后5年～10年)
此时的你，即将步入中年，不论是曾经专注技术还是偏爱管理的，都面临着家庭和社会的双重压力，你不可能像年轻人一样整天拼搏了，你需要稳定，因此，不能频繁的跳槽，建议考虑比较正规且有潜力的企业，要考虑给自己一个长远的发展规划。
正因为有前期的细节的背景的支撑，此时，你需要努力提升自己的宏观把握能力。哪怕做技术的，也要考虑适当的转型管理(中国特色是：工程师很难超过35岁的，一般人到了30岁不是转管理就是转商务了)。当然，一般人是技术做得越好，管理的时候，越容易切中项目要害。但是，对于从技术上来的人，关键是要开始培养和人打交道的能力。此阶段的关键是，需要逐步形成自己的管理风格，具备协调并行事务的能力。
当然，纯管理和技术型管理还是有所区别的。对于纯管理的人，熟练应用管理的科学理念，形成自己的风格尤为重要。纯管理的测试经理人，不仅仅可以做好测试方面的管理，其实也可以做好项目甚至其他的管理。其实，不管管理的对象是什么，它们的管理理念还是相通的。从测试管理中摸索出来的很多经验，可以很好的推广于其他的管理领域。而对于技术型管理的人，主要是带好技术团队，同时，不断补充新的技术知识，跟紧技术潮流。此时的你，有强大的技术背景支撑，不需要过分钻研细节，只需洞察核心，合理安排好你的团队成员即可。
这个阶段，也可能少数的人会选择离开具体的企业，而开始从事测试咨询，那是一个充满挑战的崭新开始，也必须有前期的积累方能胜任。
对于大多数人而言，此阶段中一个需要重点考虑的问题是，是否将测试作为自己的终生职位，如果是，基本上达到上述的目标，保持状态，基本可以做到退休的。如果不是，那就比较可怕了。其实我不建议此阶段的人转型，除非有充分的理由和很好的机遇。毕竟，达到此阶段，你已经付出了至少5年的努力，而且还是人生的黄金时段，时光一去不复返啊。当前状态下转行，请务必慎重。
18薪资要求
参考答案：
我在上家有13k，这家至少也得20k
19项目启动，拿到一个需求，怎么测试？
参考答案：
一、目标
结合公司现有的项目情况制定合理规范的测试流程，提高测试效率和产品质量，尽可能减少客户对产品的问题反馈，
核心还是要加强项目组成员之间的工作交流和沟通，保证整个项目的高效率的按质按量的交付。
二、测试流程说明图
三、测试流程
1.需求分析
参与人员：客户、项目经理
由项目经理(项目负责人)与客户相关人员开会确定需求，明确主要功能点，具体到某一个的小功能，一旦和客户那边确定了需求，就可以开始启动整个项目的工作
2.需求评审
参与人员：开发、测试、设计、产品
所有的从零开始的项目都需要需求评审，在需求评审过程中，开发从技术角度来分析实现方案，实现的难易程度。设计(美工)人员从视觉交互的角度给出适当的建议，有没有不合理的交互流程，哪些地方需要再优化，测试从用户角度来给出产品的用途逻辑上是否存在不合理的建议，在需求评审结束之后，明确相关人员的具体职责工作，评估设计，开发周期，测试周期，制定项目计划
项目计划由项目经理制定，内容分为：成员职责(把开发任务分配到每一个成员身上)、项目进度(成员在限定日期前需完成哪些功能，版本打包上线的最后时间期限)
3.测试计划
参与人员：测试组长、测试成员
测试组长把任务下发到具体的测试人员，对应具体的测试模块或任务
测试组长制定测试计划，计划的内容有以下：
①测试内容：所测试的功能清单
②测试规则：测试方法、测试要点、测试工具
③测试环境：硬件环境、软件环境、其他特定环境
④项目任务：测试规划、测试设计、执行测试的准备、测试执行、测试总结
最终以文档形式输出：测试计划
4.编写测试用例
参与人员：测试人员
测试人员依据制定的测试计划和功能点，编写高质量的测试用例
最终以文档形式输出：测试用例(excel表格)
5.用例评审
参与人员：开发、测试、产品
目的：确认细节规则和测试结果的准确性，避免功能点的遗漏
根据项目大小或者项目的上线时间来决定是否需要开评审会，此项视情况而定，若时间紧急，可直接测试组长和测试成员进行评审，由测试组长把关测试用例的质量。
6.执行测试用例，提交缺陷
参与人员：测试人员
在执行测试用例之前，先做个冒烟测试，验证项目基本的主要功能点是否通过，这项操作的目的是来评判这个版本的功能是否可测，若初步的冒烟测试都没有通过，则打回开发组，要求开发组返工。第一轮简单的系统测试后，开始执行测试用例，发现缺陷，在bug管理工具JIRA上提交缺陷，分配到对应的开发人员，由他们进行修改。
测试内容：
①功能测试 核心业务流程，功能完整性，需求的覆盖性，体验性
②兼容性测试 多个测试平台覆盖
③接口测试 权限的处理，状态的约束
④性能测试 压力测试，并发测试
⑤安全测试 传输数据加密，用户访问认证，日志记录等
文档输出：缺陷记录，测试的数据，已执行的测试用例
7.Bug跟踪直至缺陷关闭
Bug内容：编号，功能模块，缺陷描述，截图，优先级，严重程度，版本号，处理 人，状态，开始时间，结束时间，环境（测试）
缺陷状态：新建，已处理，已拒绝，已解决，已关闭，延迟处理，重复缺陷
缺陷处理流程：
①开发认为是缺陷的处理：
测试人员发现并提交缺陷，由开发人员进行处理，开发人员修改了这个缺陷就会将 这个缺陷的状态置为已解决状态让测试人员进行验证。测试人员对这个已修复的缺 陷进行回归测试，如果回归测试通过，则将缺陷状态置为已关闭，如果回归测试没 有通过，则将缺陷状态置为新建状态等待开发再次修复，直到修复成功。
②开发认为不是缺陷的处理：
测试人员发现并提交缺陷，由开发人员进行处理。但是开发人员认为不是缺陷，则 将该缺陷的状态置为已拒绝状态并提交回测试人员，可简单描述拒绝原因。测试人 员如果认为确实误报了缺陷，则直接关闭，如果经过测试人员和开发人员沟通交流 过后认为是bug，则测试人员重新打开（新建）让开发人员继续修改，开发人员修 复这个缺陷置为已解决，提交给到测试人员进行回归测试，直到回归测试通过为止。
③开发认为重复缺陷的处理：
测试人员发现并提交缺陷，由开发人员进行处理。但是开发人员认为是重复缺陷， 则将该缺陷状态置为重复缺陷，测试人员一定要确认该缺陷是否确实重复，如果确 实是同一个缺陷，则将重复的缺陷直接关闭。如果不是同一个缺陷，则重新打开该 缺陷，继续跟踪。
④延迟缺陷的处理：
测试人员发现并提交缺陷，由开发人员进行处理。但是因为项目和时间等因素，某 些缺陷无法在项目周期内完成，则需要进行延迟处理（备注：延迟处理的缺陷本身 被确定为有效缺陷），对于延迟的缺陷需要经过开发、测试、项目经理、客户代表 共同认可方可延迟。对于延迟的缺陷，置状态为延迟处理。到了下一个版本，测试 人员就应该把所有延迟处理状态的缺陷重新置为新建状态，让开发人员继续修复。
经过两到三轮或四轮的测试后，直到没发现新的问题。或暂时无法解决，或不紧急的问题，跟项目负责人确认后，可以通过。
8.测试结束，生成测试报告
当测试通过后，需生成一份测试报告，测试报告内容（重点）：
①测试项目的版本，测试项目内容的概述
②测试用例的执行情况
③测试结果的统计：总bug数，bug级别分类统计，已解决数，遗留数
④测试评估：基于软件缺陷的质量评估，写明在当前版本，已实现的功能和未实现 的功能
测试报告文档输出：说明该项目软件的开发是否达到预定目标，是否可以交付使用
记录测试结果与发现及本项目测试工作所得到的各项输出的承载体
根据输入与计划、要求的对比来总结此次项目所获得的经验
9.备注
前期的准备工作和最后的交付件：
20功能点和用例的区别，xmind做功能点的作用是什么？
参考答案：
用例与功能的区别:
1、功能是计算机术语，是用来描述计算机的， 而非定义需求的术语。功能实际描述的是输入 - > 计算 ->
输出。DFD图， 就是典型的面向过程分析模式。困此把用例当做功能点的分析员实际在做面向过程的分析。
2、用例不是计算机术语， 是针对参与者来说的，是从参与者的角度来说的。是参与者可以做什么。
用例的几个特征：
a.相对独立
b.执行结果对参与者来说是可观测的和有意义的
c.必须由一个参与者发起
d.以动宾短语形式出现
用例的核心是以参与者的为中心，从参与者的角度来描述他要做的日常工作（区别以业务流程描述的方式）
，并分析 这些日常工作之间是如何交互的（区别于数据流的描述方式。）换句话说， 用例分析的首要目标
不是要弄清楚某项业务是如何一步步完成的， 而是要弄清楚有多少参与者？每个参与者都做什么？业务流程
分析则是后续的工作。其次，用例就是为面向对象而生的，其思想完全符合OO。用例分析方法试图找到问题
领域内所有相对独立的参与者和事件， 并把业务流程当成是这些参与者和事件之间的交互结果（在UML用活动图或序列图来描述）
21备选流是个什么概念？基本流和备选流是怎么定义的
参考答案：
场景法
概念：模拟用户操作软件时的场景
运用场景：用于测试系统的业务流程
优点：涉及业务流程的业务需求适合用场景法
缺点：只验证业务流程，不验证单点功能
组成：基本流、备选流
例：
使用场景法测试QQ登录
四角圆滑的矩形—终端框(起止框)
矩形----处理框(执行框)
菱形—判断框
（可在ProcessOn在线画图）
基本流：输入正确的账号密码，点击登录，登录成功
备选流：
1、错误的密码
2、错误的账号
3、密码为空
4、账号为空
5、账号密码都为空
构造场景：
1、输入正确的账号密码，点击登录，登录成功
2、输入正确的账号、错误的密码，点击登录，登录失败，报错
3、输入错误的账号、正确的密码，点击登录，登录失败，报错
4、输入正确的账号，密码为空，点击登录，登录失败，报错
5、账号为空，输入正确的密码，点击登录，登录失败，报错
6、账号密码都为空，点击登录，登录失败，报错
22场景，基本流也好，备选流也好，是基于什么区设计的？
参考答案：
场景法
概念：模拟用户操作软件时的场景
运用场景：用于测试系统的业务流程
优点：涉及业务流程的业务需求适合用场景法
缺点：只验证业务流程，不验证单点功能
组成：基本流、备选流
例：
使用场景法测试QQ登录
四角圆滑的矩形—终端框(起止框)
矩形----处理框(执行框)
菱形—判断框
（可在ProcessOn在线画图）
基本流：输入正确的账号密码，点击登录，登录成功
备选流：
1、错误的密码
2、错误的账号
3、密码为空
4、账号为空
5、账号密码都为空
构造场景：
1、输入正确的账号密码，点击登录，登录成功
2、输入正确的账号、错误的密码，点击登录，登录失败，报错
3、输入错误的账号、正确的密码，点击登录，登录失败，报错
4、输入正确的账号，密码为空，点击登录，登录失败，报错
5、账号为空，输入正确的密码，点击登录，登录失败，报错
6、账号密码都为空，点击登录，登录失败，报错
23查询每科成绩都大于80的学生姓名？
参考答案： select sname
from student
where grade >80
24怎么确定某个模块的用例条数的？
参考答案：
一、测试用例的切面设计
1、功能点切面
2、特定切面
3、隐含切面
（1）、后台功能
（2）、完整业务流程的测试
（3）、某种特定情况下的系统运行
（4）、其它相关系统
（5）、除功能测试外的其它测试类型
二、详细用例的设计
1、功能切面表面用例设计
（1）、具体功能测试
（2）、组合操作的测试
（3）、GUI界面的测试
（4）、数据初始化情况测试
（5）、业务需求实现是否正确
2、功能切面隐含测试项用例设计：
（1）、数据完整性的测试
（2）、后台的特殊处理
（3）、功能业务之间的关联与转换
（4）、从设计实现发掘测试点
（5）、并发操作时的测试
3、特定切面用例设计
4、隐含切面用例设计
（1）、无界面的后台功能
（2）、与业务流相关的测试
（3）、其它测试类型
三、测试数据的设计
一、测试用例的切面设计
所谓测试切面设计，其实就是测试用例大项的划分。测试用例划分的经典方法是瀑布模型，也就是从上到下，逐渐细分，大模块包括小模块，小模块包括更小的模块。但仅仅如此是不够的，我们还要从更多的角度切入系统，从不同的角度把系统切分成一块一块的，来进行测试，从而确保测试大项的完整性。
1、功能点切面
这是最常见的切面，通常我们认为页面上的一个按钮就是一个功能点。然后我们可以根据功能的复杂程度，按每个功能；或一个功能点分多页；或多个功能点合成一页来进行用例的撰写。
2、特定切面
除此以外，还有一种特定切面的划分方法，也是用例撰写时经常会用到的。所谓的特定切面，就是忽略掉表面上的功能点，而关注测试对象的某一个面。比如我们的内部管理系统提供了销售录入导入、注册录入导入等功能，从菜单划分上对应了七八个功能点。但这些功能处理后台有个共同的处理项就是授权记录的生成，这时我们就可以把“授权记录生成”单独拿出来做一个测试项，而在其它测试项中涉及这一部分的用例就不必再一一撰写。此外象一些界面共通的操作用例单独写成一页，也是一种特定切面。所以如果说将用例按功能点划分是一种纵向划分法，那么特定切面就是从横向的角度分析所得到的切面。在普通功能点划分上再根据实际情况设计特定切面，可以使我们的用例阅读性、理解性、操作性更强。
3、隐含切面
这类用例是最容易被忽略的。它往往不是明显的某个功能项，可能是功能项后台的隐含处理，也可能是多个功能项之间的关联处理，甚至可能是在某种特定情形下的处理。这都需要测试人员通过对软件的学习了解，来进行挖掘。
（1）、后台功能
常见的如一些定时自动启动的服务；以及某种特定情况下自动执行的操作等。它们在界面上往往是不体现的，但许多在需求设计中还是会提到，也有一些比较细小的功能可能会被忽略，就需要测试人员根据对项目的了解程度来进行挖掘。所以说一个熟悉项目的和一个不熟悉的测试人员，写出来的用例就完全是两个层次的。
（2）、完整业务流程的测试
我们都知道测试用例的设计是从点、线、面三个层次去考虑的。完整的一个功能项是线，其中的某个按钮是点，多个相关功能结合成完整业务流就是面。从实际来看这类用例往往被我们忽略。
事实上目前公司的软件本来都是业务型应用软件，将各种功能从业务流中切割出来单独写用例，肯定也会有涉及到整体流程的情况。若不加以区分，将细节与全局搅在一起，不仅思路混乱，也容易考虑不周。因此在系统测试阶段，建议用例设计要有分有合，针对具体功能的就只围着这个功能转：而在业务流程测试项中，再完全从整体的业务流角度出发去考虑用例，这样不仅不容易产生疏漏，用例阅读与执行也更清楚。
（3）、某种特定情况下的系统运行
这类用例的设计往往与系统实际业务情况密不可分。比如财务软件，通常需要在月尾一天、月头一天、年尾一天、年头一天，对所有相关功能中的日期处理进行测试；又比如WIN 2000环境开发测试的系统，要测试在98、XP、2003等操作系统下是否能运行自如；再有如存在大量动态图片视频等的网页，在普通网速下的展现速度等等。总之就是要尽可能从实际应用的角度出发考虑，来进行测试补充。
（4）、其它相关系统
即指在当前项目中直接使用的其它成果，包括公司自有的系统模块、组件、函数；以及购买或免费得到的一些功能组件。对这些内容需要预先与开发组长等讨论清楚，是否需要测试。若时间紧张或其它原因决定不测的，应在测试计划中说明。若需要测试的，则具体可根据实际情况来设计，可以是通过系统某个功能的测试来涉及，此时就不需要单独划分测试项；若相对比较独立的，也可以通过单独的测试项来对其专门进行测试。
（5）、除功能测试外的其它测试类型
包括可靠性、安全性、恢复性、配置安装测试等等，这些测试类型都是一个单独的测试项。
所谓好的开始是成功的一半，保证测试项划分的完整、合理、正确，会直接影响到本次测试的成效。通常建议该阶段工作要花1-2天的时间来考虑，并要在测试过程中随着对软件的深入了解，不断进行调整补充。可千万不要认为把分析设计中的功能模型图搬搬过来就可以了。
二、详细用例的设计
划分好了测试项，接着就是针对各个测试项，考虑具体的测试用例了。根据测试项的特点，测试用例的设计角度也有所不同。下面我们就来看看通常的功能点测试用例，该从哪些角度出发来进行设计：
1、功能切面表面用例设计
（1）、具体功能测试
根据需求分析设计，按页面提供的各个功能项，采用黑盒测试的各种方法，设计用例。比如页面提供了增、删、改、查功能，那么这四个功能是否正确实现就是我要验证的。这是最简单、最基本，同时也是必须的测试用例，通常我们的编码人员自测也就是做到这个程度。
（2）、组合操作的测试
这是从上一角度扩展出来的，相对而言也是编码人员不会去测试的，所以需要测试人员多作考虑。
所谓组合操作测试，也就是选择某几个操作项，按一定的顺序进行操作，验证系统不会出现意外错误。当然要将所有功能项排列组合一遍来测试不仅不必要，也是不可能的。所以具体要将哪些功能项进行结合，要按怎样的步骤来操作，还是需要测试人员根据实际情况来作设计（所以说在IT业人才就是一切呀，呵呵：）。
一般来说我们会考虑功能项之间的数据是否会存在关联，若有就需要考虑这种组合了。常见的如查询功能，需要将各条件逐一累加进行测试；增完的数据能否改，改完能否删，删完能否再增，这之间能否查询到正确结果；按钮的连续多次点击会否出现异常；有严格前后顺序要求的几个操作，尝试颠倒顺序去操作，系统能否控制等等。
不仅在某功能内部，扩展到有关联的多个功能项之间，同样有组合操作测试的存在。如申报完了能才反馈；如申报成功或失败后再尝试申报等。当然对于这类用例既可以写到某个功能切面中，也可以单独写到完整业务流程的切面中，这就取决于可能涉及用例的数量了，若关系比较复杂，当然是单独写比较好；若也就是三五个用例数，那就直接在某个功能的用例中补充好了。
（3）、GUI界面的测试
这类测试是测试人员的强项，具体测试项目如限长、非法输入等等，就不必赘述了。要提醒的是在测试时，一定要从实际使用者的操作习惯出发。要知道界面原型所能确定的也只是页面的摆放显示，而实际操作时的控制实现仍是编码人员自行实现的，即使有编码指南，其所及范围也是十分有限。而许多编码人员在用户操作方便性上的考虑往往差强人意。所以测试人员就必须要把好这一关。
（4）、数据初始化情况测试
不该为空的数据是否有校验；该有默认值的数据默认值是否正确；引用其它功能生成的数据，是否会实时刷新；页面关闭或系统重启后，数据的初始化设置等都是这类用例。
（5）、业务需求实现是否正确
这类问题往往是由于我们的需求说明欠详细，而编码人员的需求了解程度又较低造成。作为测试人员自然要对需求进行深刻研究，来对软件实现进行把关。这里常见的一些关注点有：
数据的长度、类型控制是否合理（比如控制纳税人识别号只能为数字，但实际业务中是会有字母出现的）；
业务逻辑控制是否合理（比如某数据项不提供修改，但实际业务中该数据项经常会需要改动）；
提供的实现方式是否合理（比如只在某一页面提供某数据的获取功能，但根据业务划分有些人员不能操作此页面，却必须要能看到该数据）；
所做的数据控制是否合理（比如必须在A功能中新增数据，然后才能在B功能中操作，但实际业务中有可能会出现相反操作）；
所做的数据控制是否完整（如授权的方式有普通按月、有买断、有按数量控制，那么当同一企业尝试同时存在以上几种授权方式时，系统是否能有必要的控制）；
还有其它一些操作细节上的满足（如业务上需要批量操作的数据有否提供批量操作功能、导入失败的结果文件是否能修改后直接再导入等）。
对于不满足的需求，经开发组长、需求经理等确认不作修改的，就要作为软件的缺限或限制在测试报告中进行说明民。
2、功能切面隐含测试项用例设计：
（1）、数据完整性的测试
当某数据被其它功能引用；或当前功能要引用其它来源的数据，就会涉及到数据完整性的测试。最常见的如被引用的数据删除了，或关键字被修改了，引用的数据会否出错；两个途径进入的数据会否冲突或重复；此外还有因为相关的几个功能由不同人员编码，从而导致彼此的控制不一致，如A功能进入的数据在可允许的极端情况下，到B功能中引用会否异常（最常见如用户名录入时允许长度10，但引用到某个单子填写时允许长度是8，此时就会异常了）。
（2）、后台的特殊处理
是指某功能除了表面所见以外的程序处理。比如订单录入，表面所见的就是订单的保存，但后台还会有重复数据的判断、非法数据的处理、业务逻辑上冲突情况的处理以及其它种种根据需求设计所特有的处理。又比如备份功能，在备份前可能有数据的清空、备份目录的清空、备份目标是否存在的校验、备份文件重复时的处理等等。类似这些在分析设计中就未必会写全了，还是要测试人员多花心思去思考挖掘。
（3）、功能业务之间的关联与转换
相关联的几个功能之间数据的传递，会否产生影响。比如新增录入的某种特殊字符，要查询时会引起查询SQL语句异常；又如某下载文件名中存在中文等字符，下载时由于编码问题导致乱码的出现；再有报表填写时到小数点后四位，生成报文时会不会被忽略成两位了等等。象这种问题，通常只能是在每个功能设计用例时，尽量保证用例中的数据能涉及到允许范围的各种情况，即充分运用等价类划分 边界值的方法设计出各种“稀奇古怪”的数据，并需验证这些数据从头流到尾，都还是能保持其正确性，而不仅仅是在当前功能中正确。
（4）、从设计实现发掘测试点
这个就是我们测试中最难捉的BUG了，它往往是由编码人员自己在编码时创造出来的，连设计人员都不会知道。
比如内部管理系统中，正常的产品，其类别通常是2位数字；如果是模块，其类别就以产品代码来取代。这时如何来判断该产品是模块呢？最保险的当然是校验其产品类别字段的值能否在产品表中找到；也有比较简单的方法就是直接判断类别代码大于2位还是小于等于2位。此时若能确切知道采用的是哪种实现方法，就可以直接找到其漏洞所在。比如采用后一种方法，当产品类别长度变化时，明显系统会出错。那么即使确认该实现方式不改，测试人员也应将其作为限制写入测试报告，。让大家知道这个产品类别长度是不能随意变化的。
而让人郁闷的是，类似这样的实现，有太多的编码人员都是随性处理的，它们细而隐蔽，在系统数据正常情况下根本不会被发现；而在漫漫的软件使用道路中，由于需求变更等原因对原有一些设计做维护变化，这种问题就会突然暴发出来让人措不及防。所以要杜绝这类漏洞，除了测试人员要做土拨鼠，不停地对软件各功能的实现细节进行挖掘外，也要多给编码人员灌输完美实现的理念，多用复杂但抗压性高的代码，来替代简单但依赖性强的代码。
（5）、并发操作时的测试
即两个或多个用户同时操作同一功能时，会否引起数据的混乱。通常在C/S结构下，如果有同时操作的可能，是需要作此测试的；而在B/S结构下由于其特殊性，此问题通常难以解决。除非就是某用户一旦使用过某功能后，在一定时间内锁定不允许再用，但这也会带来实际应用中的不便，所以除非是特别核心的数据，一般我们也不会去做此控制，当然对于可能出现的并发冲突也就作为系统的限制进行遗留了。
3、特定切面用例设计
所谓特定切面，其实就是从另一个角度切割出来的用例面，所以具体的用例撰写方式其实与功能切面是一致的。
4、隐含切面用例设计
隐含切面分以下几种情况：
（1）、无界面的后台功能
对这类测试项，需要通过参数设置、代码调用等方式来实现测试，但具体的测试设计其实与普通功能测试并无二致。这里要注意，因为测试时往往前台、后台是分开来分别进行的，而实际运行时两者很可能是交集的，所以测试时要多注意后台功能的执行与前台的一些功能执行会否产生冲突？比如后台有个文件搬运的服务，那有没有可能在前台文件生成过程中，后台执行文件搬运了？若有可能就要注意会否出现问题了。
（2）、与业务流相关的测试
这类测试用例的设计，就要从完整业务角度来设计数据了。从理论上来讲，应该要将各个功能可能出现的各种数据排列组合到一起，按业务流程逐一进行测试。但实际上我们不可能去做全覆盖。所以设计这类用例时，最好有一张草稿，将所有相关功能按业务流程逐一列示，然后再将每个功能可能出现的特定数据一一标上，最后将图中最可能出现的、最可能出错的、最核心的数据取出来，分别组合成一个个完整的业务数据用例，来进行测试。这样就可以按清晰的思路，找出最实用、最有效的测试数据。
（3）、其它测试类型
这一类的测试通常都有其特定的方法。如要测可靠性就准备大量数据不停地执行；要测安全性就考虑数据的加密、数据的传输、数据的破坏；恢复性一般从网络、电源方面着手；配置安装则根据系统可支持的配置，搭建相应环境进行功能验证，此处的验证也要掌握技巧，即要多测试那些涉及到：数据库读写、磁盘文件读写、文件上传下载、文件加解密、数据统计、图表展现、打印等方面的功能。
三、测试数据的设计
每一个测试思路最终都要转化成具体的数据才能来执行。关于测试数据设计的方法也不外乎那几种，就不再赘述了。此处单就一些经常易犯的错误，提出一些注意点，作为用例数据设计时的参考：
1、尽量避免可能出现歧义测试结果的数据：即你设计的数据必须能唯一正确地反映出你所希望测试的结果。比如一组测试数据，有可能得到结果A或结果B，此时单用此数据来测试预期结果为A的用例，那明显就产生了歧义。
2、对于不便具体列示的数据，则必须详细描述其各项特性：有时我们在设计用例时为节约时间，不一定要到具体的一个数值，这也是允许的，但前提是你必须要详细描述清楚你要测试的数据特性。比如数据库字段限长20，要测试超长数据时，可以描述为：尝试输入长度为21位的半角英文字符；尝试输入长度为19位的半角英文字符，然后切换到中文全角再输入一位全角字符等。千万不能写成：尝试输入超长字符，因为这只能是测试方案，作为方案是可以这样写，但到用例阶段，必须要是具体的、明确的、可操作的。
3、测试数据的设计必须有明确目的性：即测试数据是从测试方案衍生而来的。如上例测试方案是测超长字符输入控制，所以测试数据就要根据具体字段长度来录入超长数据，如果一味录入长15位、长16位的数据那就没意义了。好的测试数据是可以同时针对多个测试方案的，此时可以在用例边注明一下该数据的测试目的，因为随着时间推移，对着具体的数据你也许会忘了它到底是测什么的，而这对你最后总结测试，查验测试覆盖率是非常不利的，所以随时记下你的思路想法吧，好记性不如烂笔头。
4、测试数据可省略描述：测试数据描述以能让人看懂为准则。所以写用例时当碰到连续几个用例，仅某几个关键数据值改动，其余均是一样的情况下，不必每个用例都要重复描述所有数据，可以在第一个用例描述完整之后，其余用例中仅列示不同的数据，并标明其余数据同上第X个用例，即可。这样测试时仍能复原测试数据，且该用例的测试目的一眼就明，增加了用例的清晰性。
25说几条你在上家公司设计的用例？
参考答案：
拿登录注册举例
一.功能性测试用例
1.输入已注册的用户名和正确的密码，验证是否登录成功；
2.输入已注册的用户名和不正确的密码，验证是否登录失败，并且提示信息错误；
3.输入未注册的用户名和任意密码，验证是否登录失败，并且提示信息错误；
4.用户名和密码都为空，验证是否有相应非空提示，是否登录失败；
5.用户名和密码其中一个为空，验证是否有相应非空提示，是否登录失败；
6.如果登录功能启用了验证码，在用户名和密码都正确的前提下，输入正确的验证码验证是否登录成功；
7.如果登录功能启用了验证码，在用户名和密码都正确的前提下，输入错误的验证码验证是否登录失败，并提示信息错误；
8.用户名和密码是否大小写敏感；
9.密码框是否加密；
10.忘记用户名和密码的功能是否能用；
11.是否限制了用户名和密码的长度；
12.用户登录成功但是会话超时后，继续操作是否会回到登陆界面；
13.不同级别的用户，比如管理员和普通用户，登录系统后的权限是否正确；
14.光标是否能自动定位在用户名的输入框中；
15.是否支持第三方登录；
16.被停用的用户登录，验证是否登录失败；
17.登录之后的操作日志记录是否正确；
二.安全性测试用例
1.是否可记住密码，记住之后的密码是否会加密；
2.记住密码是否有有效期，过期之后是否会清空密码；
3.用户密码后台存储是否加密；
4.密码是否具有有效期，到期后是否会提示修改密码；
5.不登陆的情况下直接输入登录后的URL地址，验证是否会重新定向到用户登录界面；
6.密码输入框是否不支持复制粘贴；
7.密码框输入的密码是否不支持在页面源码模式下被查看；
8.用户名和密码的输入框中分别输入典型的“SQL 注入攻击”字符串，验证系统的返回页面；
9.用户名和密码的输入框中分别输入典型的“XSS 跨站脚本攻击”字符串，验证系统行为是否被篡改；
10.连续多次登录失败情况下，系统是否会阻止后续的尝试以应对暴力破解；
11.同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期；
12.同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性。
三.性能压力测试用例
1.单用户登录的响应时间是否小于 3 秒；
2.单用户登录时，后台请求数量是否过多；
3.高并发的场景下用户登录的相应时间是否小于5秒；
4.高并发场景下服务端的监控指标是否符合预期；
5.高集合点并发场景下，是否存在资源死锁和不合理的资源等待；
6. 长时间大量用户连续登录和登出，服务器端是否存在内存泄漏。
四.兼容性测试用例
1.不同浏览器下，验证登录页面的显示以及功能正确性；
2.相同浏览器的不同版本下，验证登录页面的显示以及功能正确性；
3.不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性；
4.不同分辨率的界面下，验证登录页面的显示以及功能正确性
26测试过程中遇到的最大的问题，怎么解决
参考答案：
1. 提测质量差 问题描述：第一个提测版本差，有些均未通过冒烟测试 问题分析 A. 版本提测质量差，但基于发布时间已在，因此，在提测差时就开始测试 提测质量差的点：- 基于上每项功能的完成度都不高 - 有些功能均未实现 - B. 新的团队，团队处于磨合期 C. 在提测时，对提测要求不明确，在时间点到后，匆忙提测 解决方式： 明确版本提测要求，并且开发得到了足够的时间。 2. 版本控制 问题描述： 最初阶段，每天出一个版本，基于新版本测试，记录每个版本上测试的功能。版本过于频繁，质量把控不好 问题分析： A. 基于版本提测质量差，而且每天出一个版本，差上加差， B. 虽然记录每个版本上测试的功能，但仍然无法把控当前版本的质量状况。 解决方式：暂停每天发布一个版本 前期：将全功能版本作为下一个版本发布目标，但由于一些功能并没有完成，因而，全功能版本分成了好几个阶段 后期：以测试一轮周期，发布最新版本 3. 功能反复 问题描述：在上一个版本是OK的功能，在新版本中功能失常 功能反复分两点：一是大功能反复， 二是小功能（如：某个bug）反复 问题分析： 大功能反复：情况主要发生成项目前期和中期 A. 功能未完成，在完善功能时，未考虑到与该功能相关的点 B. 在提测之后，发现一些问题，导致了整个模块重构，重构后导致了问题的反复 小功能反复：这个情况主要发生在项目中后期 A. 因为项目里的部分开发是外援的，在项目中期时，撤出了团队，新接手的人员，对代码不熟悉，在修改bug时，经常出来顾此失彼 B. 开发小一在修改代码时，动到了小二的代码，导致了小二出了问题 解决方式： 对大功能反复，是这么处理：冒烟测试由开发来完成，冒烟通过后，再交由测试 对小功能反复 ，没有有效的处理方式，测试这边可以做的是，加强测试，这个问题，在发布前夕好了很多，但问题仍然存在 4. 需求不明确，前后不一致 问题描述：需求不明确，特别在一些边界，各端统一上 问题分析： A. 交互文档经历6任交互，最后一任交互只参与两个模块的定义，现任交互对于以往交互了解不够深入 B. 产品提测时，交互验证不足 解决方式： 由于项目已提测，因此在整个周期里，对于交互需求方面的疑问直接找相关人员去确认。 在后期的小版本中，我们把这类问题尽量控制在提测之前（详见小版本里的改进与问题） 5. 测试和开发信息不对称 问题描述：测试获取到的消息，与产品实现的方式不一致，如：有的功能定义了，但产品并未实现或实现方式与定义不一致 问题分析： A. 在开发阶段，测试并未参与讨论需求，还在其他项目里 B. 需求重新确认后，没有及时通知测试 解决方式： 强调消息需要通知到测试，现在阶段，如果因这种类型而引起的问题，将建ticket，指派给相关人员 小版本里的改进与问题 现存在问题： 1. 现对Release版本会做RC checklist, 进行最后版本的质量控制， 但会存在一些问题，在小版本提测时，就已经存在，而冒烟测试是测不到的，在最后做checklist时，才发现 改进点： 1. 需求疑问在提测之前尽量提出，并且通知到开发，在开发阶段便把该问题解决 测试在开发阶段跟踪产品进度 在写测试用例时，就把问题抛出。 2. 提测流程： 对功能方面的ticket，交互在提测之前便在开发机器上验证，通过后再提测 把不符合交互预期的问题，在提测之前更改，节约了时间，避免问题在提测后才提出 另外一些测试过程中遇到的问题和沟通方式 从一开始，测试就要关注需求。 往往在讨论设计时，开发和需求很容易忽略了测试成员，他们潜意识里觉得这不关测试什么事。可是，测试也要熟悉业务，熟悉功能，熟悉各种设计，而且测试需要站在用户的角度来去考量他们的设计是否有不合理的地方，并提出自己的建议。这些工作，测试成员需要主动，积极参加，多提建设性意见，这样可能会让开发慢慢发现测试成员的重要性。其次，沟通最频繁应该还是关于bug的讨论。下面列出几个遇到的沟通问题，及我的解决办法。 1、这个bug我这边重现不了 解决办法 Bug应该简明扼要，重点突出。 如果描述存在歧义，一定要总结并尽快改进。有时会遇到概率性的bug，要告诉开发概率是多少，尽可能多的提供重现的条件。在复现问题时，希望能大致判断几个问题点，然后和测试人员沟通下，需要如何捕获信息，捕获那类信息？是不是提供debug版本进行复现，或者根据预判的点增加打印信息版本进行复现？ 2、这个不是代码问题，需求这么定义的 解决办法 需求也是人定的，如果觉得有异议， 可以找需求人员询问清楚，为什么这样定义，把自己的想法告诉他们，看他们怎么决定。如果被需求说服了当然是最好的，如果自己还是不同意需求的看法，需求又不同意我的提议，那只能听他的，毕竟权力在他那里。但是我们可以保留交流的记录，证明曾经在这里发生过歧义。 3、这块是别人负责的，我负责的部分没有问题 解决办法 如果bug是由开发的项目经理来分发到程序员，那就是项目经理来面对这样的问题，而不是测试。当然，项目经理当然有项目经理的处理办法。可是，测试遇到这样的问题怎么办呢，把负责相关内容的开发都邀请到一个讨论组里，让他们自己讨论，这样更清楚，不必在测试这里中转。如果他们都觉得代码没问题，而我也有强有力的截图和真相，那就只有上交给上级领导，让他们来决定怎么解决。 4、有问题吗？（也就是开发不认为这是个问题） 解决办法 测试人员一定比开发要敏感，对bug 的容忍度也要低一些。特别是一些不符合用户习惯的bug ，开发总觉得无大碍。比如，一个列表默认的宽度太小了，导致初次打开，有一些内容被隐藏在后面，但是这个宽度可以手动调节。开发觉得问题很小，不影响功能，而且也有解决办法，所以不认为是bug。这个时候，就要发挥测试的本事了，嘴甜一点，说说好话，态度柔和一些。因为既然是小问题，解决起来一定不难，耐心地催开发的改过来就好。催一次不行催两次，记住态度一定要好。 5、用户不会像你这样操作的！ 解决办法 用户怎么操作，谁都预料不到。我们不可能覆盖所有可能性，但是大多数用户会出现的操作， 我们当然要测试。慢慢地把开发从代码的世界里带出来，带到用户的世界里，让他换个角度思考问题，毕竟软件开发不是为了实现功能，是要满足用户需求的。如果最后还是没能说服他，第一向上级反映，第二做好沟通的记录，将来备份在测试报告里。总结起来，测试在工作上要主动询问，态度上不能轻易妥协，习惯上要善于记录细节，方法上软硬兼施。
27如果你提的bug开发跟你说没时间给你改你怎么办？
参考答案：
这个你需要先把这个问题说清楚，问题影响范围有多大，然后给PM或者项目经理还有拉上开发一起评审，说明这个问题遗留的风险，如果PM和项目经理接受这个风险，那就可以发布，否则必须修改了才能发布
即使他们接受了，发布之后，也要注意线上的表现，并知会出来
如果线上这个问题表现超过预期，那么就要要求发布hotfix
28数据库倒序使用什么？
参考答案：
desc
29数据库分组使用什么？
参考答案：
group
30linux命令说几个
参考答案：
cd ls cp mkdir tail man bz2 tar
31开发就是不改你的bug怎么办
参考答案：
在测试过程中，不免会遇到开发人员因为一- 些原因不想修改个别bug的情况。那一般遇到这种问题时，我们该如何去推进开发修改bug呢? 我们先来分析下到底会有哪些原因会导致开发不修改bug 1、开发与测试对bug的定义理解不- -致产生的问题， 例如暴力操作、非常规操作出现的问题、问题路径深、服务器返回的数据不规范、竞品同样有的问题、个别机型问题等情况，开发可能会不愿意修改。 2、工作流程方面的原因，例如开发有更高优先级的任务没有时间修改、上线时间紧急， 来不及修改、开发不关注名下的bug、开发认为目前的实现比产品需求好等情况 3、当然还有个人能力 原因，例如找不到好的解决方案、影响范围大、找不到bug原因，没有解决方案、技术实现难，不知道怎么修改等等原因 4、另外还有 一些不可抗力的客观因素，例如系统问题，第三方应用问题等等 我的观点 开发不修改bug有这么多原因,但我们测试推动开发修改bug却只有一一个 原因~那就是责任。关子少卖，对策拿来“通过一一个案例帮你分析解决方案~ 小明来也~ 小明测试输入法时发现，更换皮肤后，在某鹅应用中调起键盘并转屏，键盘会显示异常，无法正常使用。 提交bug后，开发调研原因，发现输入法并有没有针对转屏做特殊处理，猜测可能是某鹅应用的问题，如果我们做适配改动会比较大。并且这个操作用户不易遇到,并且软件上线在即，所以不太想修改。测试认为转屏属于常用操作，用户一但触发此bug,输入法则无法正常使用，非常影响用户的体验。在测试的坚持下，开发人员为输入法做了些保护，并将问题反馈给该应用，应用负责人答应在下个版本修复。问题很快得到了解决。 分析.上述案例，开发不修改bug的原因有四: bug 路径较深、上线时间紧急、改动影响范围.大、第三方应用问题。我们逐条分析解决方案 1、针对路径较深的 bug，测试在推动开发修复bug时，需要注意以下几点 a)从用户的角度分析问题的严重性，分析用户的遇到此问题的概率，引导开发站在用户角
度去思考，从而使开发意识到问题的严重性 @cc b)可以和开发人员列举-一个之 前的类似问题，为开发提供参考 c)产品是负责这个软件的人员，当测试与开发意见无法达成一一致时， 不要因为无法推动开 发修改而放弃，- -定要找产品确认，最终的决定权交给产品人员。 2、.上线时间紧张， 开发来不及修改了，这个时候测试应该分析问题的严重性，和产品人员商议是否需要修改 3、修改bug改动较大，影响范围广，没有最优的解决方案等情况在项目即将上线的节点比较忌讳这种事情的发生。面对这种情况，建议开发人员做调研工作，请教其他的同事，或者组织-一个临时会议，集众人之力研究好的修改方案 4、第三方应用问题，开发无法修改。确认原因之后需要找相关的工作人员，例如产品，联系第三方输入法的工作人员，反馈问题，尽量推动应用解决问题 小结 总之，bug修不修，测试应该有一个自己的原则，同时也要权衡利弊。不能因为推不动开发，.就放弃，由着bug上线，也不能揪着一个小bug不放，影响上线时间。推动开发人员修复 bug需要技巧，你get 了吗?
32测试报告怎么写
参考答案：
1、编写目的：说明这份测试分析报告的具体编写目的，指出预期的阅读范围。
2、测试概要：用表格的形式列出每一项测试的标识符及其测试内容，并指明实际进行的测试工作内容与测试计划中预先设计的内容之间的差别，说明作出这种改变的原因。
3、测试结果及发现：把本项测试中实际得到的动态输出（包括内部生成数据输出）结果同对于动态输出的要求进行比较，陈述其中的各项发现。
4、对软件功能的结论：简述该项功能，说明为满足此项功能而设计的软件能力以及经过一项或多项测试已证实的能力。说明测试数据值的范围（包括动态数据和静态数据），列出就这项功能而言，测试期间在该软件中查出的缺陷、局限性。
测试原则
对计算机软件进行测试前，首先需遵循软件测试原则，即不完全原则的遵守。不完全原则即为若测试不完全、测试过程中涉及免疫性原则的部分较多，可对软件测试起到一定帮助。
因软件测试因此类因素具有一定程度的免疫性，测试人员能够完成的测试内容与其免疫性成正比，若想使软件测试更为流畅、测试效果更为有效，首先需遵循此类原则，将此类原则贯穿整个开发流程，不断进行测试，而并非一次性全程测试。
33测试用例包含的必要内容是什么
参考答案：
测试用例是测试设计的成果，也是绝大多数测试活动的指导性文档。他用测试的语言，把需要测试人员的执行的动作和检查点描述出来。从而规范测试人员的测试点，并保证一个足够的测试覆盖率（Test Coverage）
规划和组织得好的测试用例，使用起来应该像飞翔的龙一样舒展和迅捷。设计和构思测试用例时，要像织网一样把测试点设计周密，分布均匀，使之有效和有意义。
标准的测试用例，一般包含这样一些内容：
编号：每个测试用例的唯一编号，有助于其和测试结果、错误报告等其他文档的链接。
测试模块：讲述此测试用例的大模块；
标题：用简单的一句话来描述此测试用例；
测试目的：描述设计此测试用例的目的是什么；
测试级别：按照测试用例的重要性来给不同的测试用例分级别；
先决条件：执行此测试用例之前需要做的准备；
输入：测试人员执行测试所需的动作；
期望输出：在检查点上，待测设备应有的正常反应、动作或显示。
要写出高质量的测试用例，需要测试工程师认真思考下面几个问题：
如何保证合适的测试用例覆盖率；
如何确保紧跟开发文档的变化；
如何把测试用例的重复率限定在适度的范围；
如何实现“以测养测”式的测试用例更新；
如何实现测试用例在不同产品间重用。
34如果在测试用例评审中，参与人员积极性不高怎么办
参考答案：
员工的评审积极性不高，可能是因为组织的规划不合理，或之前没说明白，比如：没有说明评审的重要性，认为评审可有可无，要积极的说出评审的重要性，说出了重要性，这样才能有人配合，并且要做好宣传工作，最后再来个任务，分配给每个小组组长，要求必须有几名员工投参与，怎么参与也要规划好。总之，是之前规划的问题，那就改方案，重新规划方案，合理分配人员进行用例评审。
35如果时间很紧急，没有需求，但是要全面测试不能漏测你准备怎么办
参考答案：
这个情况下我们就要进行探索性测试，把软件当成用户需求，一步步进行测试。凭借经验判断功能正确与否，有的时候还可以与项目经理、开发人员一起进行交流沟通，从而进行更好的测试。
36以下三个是Linux题目
37文件中查找字符串 ？
参考答案：
grep 'word' filename
38对未知路径的目录如何查找？
参考答案：
一、find 命令格式说明
path find命令查找的目录路径。
-print find命令将匹配到的文件输出到标准输出。
-exec find 命令对匹配的文件执行该参数所给出的Shell命令。
-ok 和 -exec的作用相同，只是更安全，在执行每个命令之前，都会给出提示，让用户来确定是否执行。
二、find命令常用参数说明
-name 按照文件名查找文件
-cpio：对匹配的文件使用 cpio 命令，将这些文件备份到磁带设备中
-prune 按照文件权限进行查找文件
-user 按照文件属主来查找文件
-group 按照文件所属的组来查找文件
-mtime -n n 按照文件更改的时间来查找文件，-n 表示更改时间距现在 n 天以内， n 表示更改时间距现在 n 天以前
-nogroup 查找无效所属组的文件
-nouser 查找无效属主文件
-newer file1 ！file2 查找更改时间比 file1 新但比 file2 旧的文件
-follow 如果 find 查找的为链接文件，就跟踪至连接所指向的文件
-mount 在查找文件时不跨越文件系统 mount 点
-fstype 查找位于某一类型文件系统中的文件
-depth 在查找文件时，首先查找当前目录中的文件，然后再在其子目录中查找
-size n 查找文件长度为 n 块的文件，带有 c 时表示文件长度以字节计
-type 查找某一类型的文件
-amin n 查找系统中最后 n 分钟访问的文件
-atime n 查找系统中最后 n*24 小时访问的文件
-cmin n 查找系统中最后 n 分钟被改变文件状态的文件
-ctime n 查找系统中最后 n*24 小时被改变文件状态的文件
-mmin n 查找系统中最后 n 分钟被改变文件数据的文件
-mtime n 查找系统中最后 n*24 小时被改变文件数据的文件
-empty 查找系统中空白的文件或目录，或目录中没有子目录的文件夹
-false 查找系统中总是错误的文件
-gid n 查找系统中文件数字组ID为 n 的文件
-daystart 测试系统中从今天开始 24 小时以内的文件，用法类似于 -amin
-help 显示命令摘要（帮助）
-maxdepth levels 在某个层次目录中按照递减方法查找
三、find基本用法
find 如不加任何参数，表示查找当前路径下的所有文件和目录
find -print 将结果打印到标准输出
find /data/log 指定路劲查找
find / -name "abc.txt" 在系统中查找 abc.txt 如果执行完毕没有找到，则说明系统中不存在该文件
find 还支持正则表达式查找
find /data/logs -mame "*.log" -type f -printf 查找符合指定字符串的文件
find . -name "[0-9]" -type f 查找以数字开头的文件
find / -mtime -1 |head 查找系统内最近24小时修改过的文件
find / -mmin -15|head 查找系统内最近15 分钟修改过的文件
find 使用 type 选项可以查找特定的文件类型，常见类型如下
b 块设备文件
d 目录
c 字符设备文件
p 管道文件
l 符号链接文件
f 普通文件
find . -type d 查找当前路径中的所有目录
find . -type f 查找当前路径中的所有文件
find . -type l 查找当前路径中的所有符号链接文件
39如何在文件中对字符串进行替换？
参考答案：
vi/vim 中可以使用 :s 命令来替换字符串。以前只会使用编辑软件进行替换，今天发现该命令有很多种写法（vi 真是强大啊，还有很多需要学习），记录几种在此，方便以后查询。
:s/well/good/ 替换当前行第一个 well 为 good
:s/well/good/g 替换当前行所有 well 为 good
:n,$s/well/good/ 替换第 n 行开始到最后一行中每一行的第一个 well 为 good
:n,$s/well/good/g 替换第 n 行开始到最后一行中每一行所有 well 为 good
n 为数字，若 n 为 .，表示从当前行开始到最后一行
:%s/well/good/（等同于 :g/well/s//good/） 替换每一行的第一个 well 为 good
:%s/well/good/g（等同于 :g/well/s//good/g） 替换每一行中所有 well 为 good
可以使用 # 作为分隔符，此时中间出现的 / 不会作为分隔符
:s#well/#good/# 替换当前行第一个 well/ 为 good/
:%s#/usr/bin#/bin#g
可以把文件中所有路径/usr/bin换成/bin
（二）Sumly法直接替换文件中的字符串。(此法不用打开文件即可替换字符串，而且可以批量替换多个文件。)
40数据库题目
41左连接和右连接的区别
参考答案：
Left Join / Right Join /inner join相关
简单的来说，左连接只影响右表，右连接只影响左表
下面给一个例子就比较清楚了
现有表1 user(user_id,user_name)，表2 grade(user_id,coure,number)
左连接：
select user.*,grade.* from user left outer join grade on(user.user_id=grade.user_id)
右连接：
select user.*,grade.* from user right outer join grade on(user.user_id=grade.user_id)
42写出查询成绩在80---90之间学生姓名
参考答案：
select sname
from student
where grade between 80 and 90
