在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？
一条Bug记录最基本应包含：编号、Bug所属模块、Bug描述、Bug级别、发现日期、发现人、修改日期、修改人、修改方法、回归结果等等；要有效的发现Bug需参考需求以及详细设计等前期文档设计出高效的测试用例，然后严格执行测试用例，对发现的问题要充分确认肯定，然后再向外发布如此才能提高提交Bug的质量。
根据自己的理解什么是测试用例和测试规程，设计一个测试用例应当从哪几方面考虑？
狭义的讲，一个测试用例就是测试人员用以测试被测软件的某个特性或特性组合的一组数据。这组数据可能是从用户处得来的实际的一组数据，也可能是测试人员专门设计出来的测试软件某些功能的一组数据。
测试规程就是详细的对测试用例设计方法、测试方法、测试工具、测试环境和测试数据进行描述的文档，还可以包括能把某个或某一组测试用例应用到被测软件上完成某项测试的一系列的操作步骤。
设计测试用例应当从以下几方面考虑：边界值，等价类划分，有效/无效值等。
什么是回归测试?
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误的过程。
回归测试策略包括：部分回归测试及完全回归测试。
回归测试引入自动回归，大幅降低系统测试、维护升级等阶段的成本、提升了回归测试的效率。
设计用例的方法、依据有那些？
白盒测试：逻辑覆盖法，主要包括语句覆盖，判断覆盖，条件覆盖，判断-条件覆盖，路径覆盖
黑盒测试：等价划分类，边界值分析，错误推测法。
什么是白盒测试？什么是黑盒测试？如果进行了充分的黑盒测试，还需要进行白盒测试吗？为什么？
白盒测试是基于代码的测试，黑盒测试是针对软件的功能需求/实现进行的测试。即使执行了充分的黑盒测试，也不能测试程序内部特定部位，若规格说明本身有误，也不能发现问题。但是白盒测试能对程序的内部特定部位进行覆盖测试，所以黑盒和白盒测试为互补关系，结合起来进行测试用例的设计更为合理。
按阶段划分测试分为那几种类型？各自的侧重点是什么?
1、单元测试 系统的模块，包括子程序的正确性验证等——检验软件基本组成单位的正确性。
2、集成测试 模块间的衔接以及参数的传递等——检查软件单位之间的借口是否正确
3、系统测试 整个系统的运行以及与其他软件的兼容性。——按照测试计划进行，实现软件输入输出和动态运行行为与规约进行对不
4、验收测试 向软件购买者展示该软件系统满足其用户的需求。——验证软件功能实现的正确性
你认为开发人员自己测试和测试人员测试的区别是什么?
开发人员测试会产生盲点，会认为自己做的东西不会有错，这导致的结果就是测试不出软件的Bug，测试人员因为没有参与开发，所以不会产生这种盲点，测试出来的结果更直观和可信更正确。
对一个由三个模块组成的系统执行功能测试，第一轮测试完成后，统计发现其中一模块Bug比例为65％，其它模块发现数量为35％，当开发人员对这些Bug修复后，第二轮测试开始，首先针对已发现的Bug进行修复确认测试通过后，需要再进行一次全面的功能回归测试，测试组长决定不将发现大量Bug的模块做为重点，而是将其它两模块做为重点进行测试，你认为这个测试策略是否正确？为什么？
“
我认为这个测试策略不正确，因为根据bug分散性原理，发现bug越多的模块越容易产生新的bug。
如何测试一个 纸杯？
功能性：用水杯装水看漏不漏；水能不能被喝到
安全性：杯子有没有毒或细菌
可靠性：杯子从不同高度落下的损坏程度
可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用
兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等
易用性：杯子是否烫手、是否有防滑措施、是否方便饮用
用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述
疲劳测试：将杯子盛上水（案例一）放 24 小时检查泄漏时间和情况；盛上汽油（案例二）放 24 小时检查泄漏时间和情况等
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透
现有要求你对一根签字笔做测试，你如何进行测试？请先确定测试策略，再写出尽可能多的测试用例（注意策略及条理）
1、功能测试：笔的部件完整性；笔的大小规格；笔能否书写；笔水从笔管里能否倒流；在书写过程中，笔水是否流出来；笔头是否容易掉出来
2、性能测试：压力测试,看用多久能用烂,把它绑在电动机上划纸盒
3、用户体验：找尽量多的群众,搜集反馈
4、破坏测试：看在几楼掉下会摔坏,记录高度和地面硬度,烧,看燃点是多少,煮,看煮完坏不坏
5、安全测试：潜入机场,把这个扔在飞机进气孔里,看能不能引起爆炸;让白鼠吃笔心,看是否中毒
你认为一个优秀的测试工程师应该具备哪些素质？
1、具有良好的计算机编程基础
2、具有创新精神和超前意识
3、不懈努力，追求完美
4、具有整体观念，对细节敏感
5、团队合作精神
6、责任心、耐心、细心、信心
7、沟通能力
8、时时保持怀疑态度，并且有缺陷预防的意识。
什么是兼容性测试？兼容性测试侧重哪些方面？
兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行，即是通常说的软件的可移植性。
兼容的类型，如果细分的话，有平台的兼容，网络兼容，数据库兼容，以及数据格式的兼容。
兼容测试的重点是，对兼容环境的分析。通常，是在运行软件的环境不是很确定的情况下，才需要做兼容。根据软件运行的需要，或者根据需求文档，一般都能够得出用户会在什么环境下使用该软件，把这些环境整理成表单，就得出做兼容测试的兼容环境了。
我现在有个程序，发现在Windows上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题？
1、检查系统是否有中毒的特征；
2、检查软件/硬件的配置是否符合软件的推荐标准；
3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务；
4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；
5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况。
正交表测试用例设计方法的特点是什么？
用最少的实验覆盖最多的操作，测试用例设计很少，效率高，但是很复杂；
对于基本的验证功能，以及二次集成引起的缺陷，一般都能找出来；但是更深的缺陷，更复杂的缺陷，还是无能为力的；
具体的环境下，正交表一般都很难做的。大多数，只在系统测试的时候使用此方法。
Beta测试与Alpha测试有什么区别？
Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场
Alpha testing (α测试),是由一个用户代表在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试
软件的评审一般由哪些人参加？其目的是什么？
在正式的会议上将软件项目的成果（包括各阶段的文档、产生的代码等）提交给用户、客户或有关部门人员对软件产品进行评审和批准。其目的是找出可能影响软件产品质量、开发过程、维护工作的适用性和环境方面的设计缺陷，并采取补救措施，以及找出在性能、安全性和经济方面的可能的改进。
你认为做好测试计划工作的关键是什么？
软件测试计划就是在软件测试工作正式实施之前明确测试的对象，并且通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划，保证有效的实施软件测试；
做好测试计划工作的关键 ：目的，管理，规范
1. 明确测试的目标，增强测试计划的实用性
编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确
2．坚持“5W”规则，明确内容与过程
“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
3．采用评审和更新机制，保证测试计划满足实际需求
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
4. 分别创建测试计划与测试详细规格、测试用例
应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。
软件的安全性应从哪几个方面去测试？
(1)用户认证机制：如数据证书、智能卡、双重认证、安全电子交易协议
(2)加密机制
(3)安全防护策略：如安全日志、入侵检测、隔离防护、漏洞扫描
(4)数据备份与恢复手段：存储设备、存储优化、存储保护、存储管理
(5)防病毒系统
软件系统中除用户文档之外，文档测试还应该关注哪些文档？
软件需求说明书
数据库设计说明书
概要设计说明书
详细设计说明书
可行性研究报告
管理文档
项目开发计划
测试计划
测试报告
开发进度月报
开发总结报告
文档测试主要包含什么内容？
在国内软件开发管理中，文档管理几乎是最弱的一项，因而在测试工作中特别容易忽略文档测试也就不足为奇了。要想给用户提供完整的产品，文档测试是必不可少的。文档测试一般注重下面几个方面：
文档的完整性：主要是测试文档内容的全面性与完整性，从总体上把握文档的质量。例如用户手册应该包括软件的所有功能模块。
描述与软件实际情况的一致性：主要测试软件文档与软件实际的一致程度。例如用户手册基本完整后，我们还要注意用户手册与实际功能描述是否一致。因为文档往往跟不上软件版本的更新速度。
易理解性：主要是检查文档对关键、重要的操作有无图文说明，文字、图表是否易于理解。对于关键、重要的操作仅仅只有文字说明肯定是不够的，应该附有图表使说明更为直观和明了。
文档中提供操作的实例：这项检查内容主要针对用户手册。对主要功能和关键操作提供的应用实例是否丰富，提供的实例描述是否详细。只有简单的图文说明，而无实例的用户手册看起来就像是软件界面的简单拷贝，对于用户来说，实际上没有什么帮助。
印刷与包装质量：主要是检查软件文档的商品化程度。有些用户手册是简单打印、装订而成，过于粗糙，不易于用户保存。优秀的文档例如用户手册和技术白皮书，应提供商品化包装，并且印刷精美。
功能测试用例需要详细到什么程度才是合格的？
这个问题也是测试工程师经常问的问题。有人主张测试用例详细到每个步骤执行什么都要写出来，目的是即使一个不了解系统的新手都可以按照测试用例来执行工作。主张这类写法的人还可以举出例子：欧美、日本等软件外包文档都是这样做的。
另外一种观点就是主张写的粗些，类似于编写测试大纲。主张这种观点的人是因为软件开发需求管理不规范，变动十分频繁，因而不能按照欧美的高标准来编写测试用例。这样的测试用例容易维护，可以让测试执行人员有更大的发挥空间。
实际上，软件测试用例的详细程度首先要以覆盖到测试点为基本要求。举个例子：“用户登陆系统”的测试用例可以不写出具体的执行数据，但是至少要写出五种以上情况（），如果只用一句话覆盖了这个功能是不合格的测试用例。覆盖功能点不是指列出功能点，而是要写出功能点的各个方面（如果组合情况较多时可以采用等价划分）。
另一个影响测试用例的就是组织的开发能力和测试对象特点。如果开发力量比较落后，编写较详细的测试用例是不现实的，因为根本没有那么大的资源投入，当然这种情况很随着团队的发展而逐渐有所改善。测试对象特点重点是指测试对象在进度、成本等方面的要求，如果进度较紧张的情况下，是根本没有时间写出高质量的测试用例的，甚至有些时候测试工作只是一种辅助工作，因而不编写测试用例。
因此，测试用例的编写要根据测试对象特点、团队的执行能力等各个方面综合起来决定编写策略。最后要注意的是测试人员一定不能抱怨，力争在不断提高测试用例编写水平的同时，不断地提高自身能力。
没有产品说明书和需求文档地情况下能够进行黑盒测试吗？
这个问题是国内测试工程师经常遇到的问题，根源就是国内软件开发文档管理不规范，对变更的管理方法就更不合理了。实际上没有任何文档的时候，测试人员是能够进行黑盒测试的，这种测试方式我们可以称之为探索测试，具体做法就是测试工程师根据自己的专业技能、领域知识等不断的深入了解测试对象、理解软件功能，进而发现缺陷。
在这种做法基本上把软件当成了产品说明书，测试过程中要和开发人员不断的进行交流。尤其在作项目的时候，进度压力比较大，可以作为加急测试方案。最大的风险是不知道有些特性是否被遗漏
测试中的“杀虫剂怪事”是指什么？
“杀虫剂怪事”一词由BorisBeizer在其编著的《软件测试技术》第二版中提出。用于描述测试人员对同一测试对象进行的测试次数越多，发现的缺陷就会越来越少的现象。就像老用一种农药，害虫就会有免疫力，农药发挥不了效力。这种现象的根本原因就是测试人员对测试软件过于熟悉，形成思维定势。
为了克服这种现象，测试人员需要不断编写新的测试程序或者测试用例，对程序的不同部分进行测试，以发现更多的缺陷。也可以引用新人来测试软件，刚刚进来的新手往往能发现一些意想不到的问题。
完全测试程序是可能的吗？
软件测试初学者可能认为拿到软件后需要进行完全测试，找到全部的软件缺陷，使软件“零缺陷”发布。实际上完全测试是不可能的。主要有以下一个原因：
-完全测试比较耗时，时间上不允许；
-完全测试通常意味着较多资源投入，这在现实中往往是行不通的；
-输入量太大，不能一一进行测试；
-输出结果太多，只能分类进行验证；
-软件实现途径太多；
-软件产品说明书没有客观标准，从不同的角度看，软件缺陷的标准不同；
因此测试的程度要根据实际情况确定。
软件测试的风险主要体现在哪里？
我们没有对软件进行完全测试，实际就是选择了风险，因为缺陷极有可能存在没有进行测试的部分。举个例子，程序员为了方便，在调试程序时会弹出一些提示信息框，而这些提示只在某种条件下会弹出，碰巧程序发布前这些代码中的一些没有被注释掉。在测试时测试工程师又没有对其进行测试。如果客户碰到它，这将是代价昂贵的缺陷，因为交付后才被客户发现。
因此，我们要尽可能的选择最合适的测试量，把风险降低到最小
发现的缺陷越多，说明软件缺陷越多吗？
这是一个比较常见的现象。测试工程师在没有找到缺陷前会绞尽脑汁的思考，但是找到一个后，会接二连三的发现很多缺陷，颇有个人成就感。其中的原因主要如下：
-代码复用、拷贝代码导致程序员容易犯相同的错误。类的继承导致所有的子类会包含基类的错误，反复拷贝同一代码意味可能也复制了缺陷。
-程序员比较劳累是可以导致某些连续编写的功能缺陷较多。程序员加班是一种司空见惯的现象，因此体力不只时容易编写一些缺陷较多的程序。而这些连续潜伏缺陷恰恰时测试工程师大显身手的地方。
“缺陷一个连着一个”不是一个客观规律，只是一个常见的现象。如果软件编写的比较好，这种现象就不常见了。测试人员只要严肃认真的测试程序就可以了
所有的软件缺陷都能修复吗？所有的软件缺陷都要修复吗？
从技术上讲，所有的软件缺陷都是能够修复的，但是没有必要修复所有的软件缺陷。测试人员要做的是能够正确判断什么时候不能追求软件的完美。对于整个项目团队，要做的是对每一个软件缺陷进行取舍，根据风险决定那些缺陷要修复。发生这种现象的主要原因如下：
-没有足够的时间资源。在任何一个项目中，通常情况下开发人员和测试人员都是不够用的，而且在项目中没有预算足够的回归测试时间，再加上修改缺陷可能引入新的缺陷，因此在交付期限的强大压力下，必须放弃某些缺陷的修改。
-有些缺陷只是特殊情况下出现，这种缺陷处于商业利益考虑，可以在以后升级中进行修复。
-不是缺陷的缺陷。我们经常会碰到某些功能方面的问题被当成缺陷来处理，这类问题可以以后有时间时考虑再处理。
最后要说的是，缺陷是否修改要由软件测试人员、项目经理、程序员共同讨论来决定是否修复，不同角色的人员从不同的角度来思考，以做出正确的决定。
软件测试人员就是QA吗？
软件测试人员的职责是尽可能早的找出软件缺陷，确保得以修复。而质量保证人员（QA）主要职责是创建或者制定标准和方法，提高促进软件开发能力和减少软件缺陷。测试人员的主要工作是测试，质量保证人员日常工作重要内容是检查与评审，测试工作也是测试保证人员的工作对象。
软件测试和质量是相辅相成的关系，都是为了提高软件质量而工作。
和用户共同测试（UAT测试）的注意点有哪些？
软件产品在投产前，通常都会进行用户验收测试。如果用户验收测试没有通过，直接结果就是那不到“Money”，间接影响是损害了公司的形象，而后者的影响往往更严重。根据作者的经验，用户验收测试一定要让用户满意。
实际上用户现场测试更趋于是一种演示。在不欺骗用户的前提下，我们向用户展示我们软件的优点，最后让“上帝”满意并欣然掏出“银子”才是我们的目标。因此用户测试要注意下面的事项：
（1）用户现场测试不可能测试全部功能，因此要测试核心功能。这需要提前做好准备，这些核心功能一定要预先经过测试，证明没有问题才可以和用户共同进行测试。测试核心模块的目的是建立用户对软件的信心。当然如果这些模块如果问题较多，不应该进行演示。
（2）如果某些模块确实有问题，我们可以演示其它重要的业务功能模块，必要时要向用户做成合理的解释。争得时间后，及时修改缺陷来弥补。
（3）永远不能欺骗用户，蒙混过关。道理很简单，因为软件是要给用户用的，问题早晚会暴露出来，除非你可以马上修改。
和用户进行测试还要注意各种交流技巧，争取不但短期利益得到了满足，还要为后面得合作打好基础。
如何编写提交给用户的测试报告？
随着测试工作越来越受重视，开发团队向客户提供测试文档是不可避免的事情。很多人会问：“我们可以把工作中的测试报告提供给客户吗？”答案是否定的。因为提供内部测试报告，可能会让客户失去信心，甚至否定项目。
测试报告一般分为内部测试报告和外部测试报告。内部报告是我们在测试工作中的项目文档，反映了测试工作的实施情况，这里不过多讨论，读者可以参考相关教材。这里主要讨论一下外部测试报告的写法，一般外部测试报告要满足下面几个要求：
-根据内部测试报告进行编写，一般可以摘录；
-不可以向客户报告严重缺陷，即使是已经修改的缺陷，开发中的缺陷也没有必要让客户知道；
-报告上可以列出一些缺陷，但必须是中级的缺陷，而且这些缺陷必须是修复的；
-报告上面的内容尽量要真实可靠；
-整个测试报告要仔细审阅，力争不给项目带来负面作用，尤其是性能测试报告。
总之，外部测试报告要小心谨慎的编写。
测试工具在测试工作中是什么地位？
国内的很多测试工程师对测试工具相当迷恋，尤其是一些新手，甚至期望测试工具可以取代手工测试。测试工具在测试工作中起的是辅助作用，一般用来提高测试效率。自动化测试弥补了手工测试的不足，减轻一定的工作量。实际上测试工具是无法替代大多数手工测试的，而一些诸如性能测试等自动化测试也是手工所不能完成的。
对于自动测试技术，应当依据软件的不同情况来分别对待，一般自动技术会应用在引起大量重复性工作的地方、系统的压力点、以及任何适合使用程序解决大批量输入数据的地方。然后再寻找合适的自动测试工具，或者自己开发测试程序。一定不要为了使用测试工具而使用。
写出bug报告流转的步骤，每步的责任人及主要完成的工作。
测试人员提交新的Bug入库，错误状态为New。
高级测试员/测试经理验证错误，如果确认是错误，分配给开发组。设置状态为Open。如果不是错误，则拒绝，设置为Declined状态。
开发经理分配bug至对应的模块开发人员。
开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。
对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。
测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决，置Bug的状态为Closed，如没有解决,置bug状态为Reopen。
为什么要在一个团队中开展软件测试工作？
因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样，软件同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。
您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？
根据项目经验不同，灵活回答即可）,我曾经做过web测试，后台测试，客户端软件，其中包括功能测试，性能测试，用户体验测试。最擅长的是功能测试
您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）
测试类型有：功能测试，性能测试，界面测试。
功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）？做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试
您认为做好测试用例设计工作的关键是什么？
白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题
测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？
软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法（最好是能先评审）
您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用
1．等价类划分
划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
2．边界值分析法
边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
3．错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.
4．因果图方法
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.
请以您以往的实际工作为例，详细的描述一次测试用例设计的完整的过程。
首先：得到相关文档（需求文档和设计文档），理解需求和设计设计思想后，想好测试策略（测试计划简单点就OK了），考虑到测试环境，测试用例，测试时间等问题。
第二步：设计测试用例，测试策略是：把网站部分的功能点测试完，然后在进行系统测试（另外个模块呢有另一个测试人员负责，可以进行联调测试），网站模块的测试基本是功能测试和界面测试（用户并发的可能性很小，所以不考虑）：这次的网站的输入数据呢是使用数据库中的某张表记录，如果表中某一数据记录中新加进来的（还没有被处理的，有个标志位），网站启动后会立刻去刷那张表，得到多条数据，然后在进行处理。处理过程中，会经历3个步骤，网站才算完成了它的任务。有3个步骤呢，就可以分别对 这3个步骤进行测试用例的设计,尽量覆盖到各种输入情况（包括数据库中的数据，用户的输入等），得出了差不多50个用例。界面测试，也就是用户看的到的地方，包括发送的邮件和用户填写资料的页面展示。
第三步：搭建测试环境（为什么这个时候考虑测试环境呢？因为我对网站环境已经很熟了，只有有机器能空于下来做该功能测试就可以做了），因为网站本身的环境搭建和其他的系统有点不同，它需要的测试环境比较麻烦，需要web服务器（Apache,tomcat），不过这次需求呢，网站部分只用到了tomcat，所以只要有tomcat即可
第四步：执行测试
你以前工作时的测试流程是什么？
（灵活回答）
公司对测试流程没有规定如何做，但每个测试人员都有自己的一套测试流程。我说下我1年来不断改正（自己总结，吸取同行的方法）后的流程吧。需求评审（有开发人员，产品经理，测试人员，项目经理）－>需求确定(出一份确定的需求文档)－>开发设计文档（开发人员在开始写代码前就能输出设计文档）－>想好测试策略，写出测试用例－>发给开发人员和测试经理看看（非正式的评审用例）－>接到测试版本－>执行测试用例（中间可能会补充用例）－>提交bug（有些bug需要开发人员的确定（严重级别的，或突然发现的在测试用例范围之外的，难以重现的），有些可以直接录制进TD）－>开发人员修改（可以在测试过程中快速的修改）－>回归测试（可能又会发现新问题，再按流程开始跑）。
当开发人员说不是BUG时，你如何应付？
开发人员说不是bug，其原因一般不会是开发故意不改，无非有两种原因，
其一就是需求没有明确，这么做是可以的，这时我们可以找产品经理来确认，3方商量确认后明确改与不改；
第二种原因这种bug不可能发生，所以不需要修改，这时候我们可以尽可能地指出bug可能引起的后果，尽量说服开发去改，
如果不能达成一致，则需要测试经理和开发经理进行确认。如果有些确实不是很明显的bug，我们可以提建议级别bug，
如果开发人员不修改也没有大问题。如果认为是bug就一定要坚持，并最终要得到确认。
简述一下c/s模式或者b/s模式？
C/S模式：客户端/服务器模式。工作原理：Client向Server提交一个请求；Server则使用一些方法处理这个请求，并将效果返回给Client。
B/S结构，即Browser/Server(浏览器/服务器)结构，是随着Internet技术的兴起，对C/S结构的一种变化或者改进的结构。在这种结构下，用户界面完全通过WWW浏览器实现，一部分事务逻辑在前端实现，但是主要事务逻辑在服务器端实现。B/S结构，主要是利用了不断成熟的WWW浏览器技术，结合浏览器的多种Script语言(VBScript、JavaScript…)和ActiveX技术，用通用浏览器就实现了原来需要复杂专用软件才能实现的强大功能，并节约了开发成本，是一种全新的软件系统构造技术。
产品上线之后出现了bug，相关负责人过来质问，“为什么测试的时候没有发现这个bug”？
1、首先要了解bug信息，重现bug并确认其重要程度
2、如果是测试的问题，没有发现该bug，就要主动承担责任并作出总结，避免下次再犯错
3、如果是其他的问题，如团队协作的问题，需要将相应的问题反馈给上级，同时作出总结，避免下次犯
4、作为测试人员，我们应该尽可能地做好多种场景的预测，防患于未然
UI用户界面测试测试要点？（web）
1） 各页面的风格是否统一
2） 各页面的大小是否一致；同样的LOGO图片在各个页面中显示是否大小一致；页面
及图片是否居中显示
3） 各页面的title是否正确
4） 栏目名称、文章内容等处的文字是否正确，有错别字或乱码；同一级别的字体、大
小、颜色是否统一
5） 提示、警告或错误说明应该清楚易懂，用词准确，摒弃模棱两可的字眼
6） 切换窗口大小，将窗口缩小后，页面是否按比例缩小或出现滚动条；各个页面缩小
的风格是否一致（按比例缩小或出现滚动条，不可二者兼有）
7） 父窗体或主窗体的中心位置应该在对角线交点附近；子窗体位置应该在主窗体的左
上角或正中；多个子窗体弹出时应该依次向右下方偏移，以显示出窗体标题为宜
8） 按钮大小基本相似，忌用太长名称，免得占用太多的页面位置；避免空旷的页面放
置很大的按钮；按钮的样式风格要统一；按钮之间的间距要一致
9） 页面颜色是否统一；前景色与背景色搭配合理协调，反差不宜太大，最好用深色或
刺目的颜色
10） 若有滚动信息或者图片，将鼠标放置其上，查看滚动信息或图片是否停止
11） 导航处是否按栏目相应的级别显示；导航文字是否在同一行显示
12） 所有的图片是否被正确装载，在不同的浏览器，分辨率下图片是否能正常显示（包
括位置、大小）
13） 文章列表页，左侧的栏目是否与一级、二级栏目的名称、顺序一致
14） 调整分辨率验证页面风格是否有错误现象
15） 鼠标移动到Flash焦点特效上是否实现，移出焦点特效是否消失
链接测试的要点有？（web）
链接测试主要分为以下几个方面
1） 页面是否有无法连接的内容；图片是否能正常显示，有无冗余图片，代码是否规范，
页面是否存在死链接（可用HTML Link Validator工具查找）
2） 图片是否有无用链接；点击图片上的链接是否跳转到正确页面
3） 页面点击LOGO下的一级栏目或二级栏目名称，是否可进入相应的栏目
4） 点击首页或列表页的文章标题的链接，是否可进入相应的文章详情页
5） 点击首页栏目名称后的【更多】链接，是否正确跳转到相应页面
6） 文章列表页、左侧栏目的链接，是否可正确跳转到相应的栏目页面
7） 导航链接的页面是否正确；是否可按栏目级别跳转到相应的页面 （例，【首页-服务与支持-客服中心】，分别点击“首页”，“服务与支持”，“客服中心”，查看是否可跳转到相应页面）
搜索测试测试要点？（web）
搜索测试主要分为以下几个方面
1） 搜索按钮功能是否实现
2） 输入网站中存在的信息，能否正确搜索出结果
3） 输入键盘中的特殊字符，是否报错：特别关注 :_? ’ . \ /–；特殊字符
4） 系统是否支持快捷键回车键，Tab
5） 搜索出的结果页面是否与其他页面风格一致
6） 在输入框输入空格，点击搜索系统是否会报错
7） 本站内搜索域中不输入任何内容，是否搜索出是全部信息或者是给与提示
8） 精确查询还是模糊查询，如果是模糊查询输入：中%国。查询信息是不是包含中国
两个字的信息
9） 焦点放置搜索框中，搜索框内容是否被清空
10） 搜索输入域是否实现回车监听事件
11） 输入超长字符查询
12） 空格或空、null条件查询
13） 关键字前、后、中间有空格，显示搜索结果是否一致
14） 选择框各种条件查询数据是否正确
15） 请选择查询是否为所有数据
16） 输入数据库中不存在的信息
17） 必填查询条件验证
18） 默认查询条件
19） 输入不符合要求的数据，看是否有提示：如日期格式：YYYY-MM-DD；范围：月份
中输入13等，一般这些数据都是枚举型数据，以下拉框的形式出现
20） 敏感字查询
21） 搜索内容显示，是否可以按照文章搜索关键字进行排名（标题关键字相当于文章3-4个关键字）
表单提交测试的测试点？
表单测试主要分为以下几个方面
1） 注册、登陆功能能否实现
2） 提交、清空按钮是否实现
3） 修改表单与注册页面数据项是否相同，修改表单是否对重名做验证
4） 提交数据是否能正常保存到后台数据库中（后台数据库中数据应与前台录完内容完全一致，数据不会丢失或被改变）
5） 表单提交，删除，修改后是否有提示内容
6） 浏览器前进、后退、刷新按钮，是否会造成数据库重现或页面报错
7） 提交表单是否支持回车键和Tab键
8） 下来菜单功能是否实现和数据是否完整（例如：省份和市区下拉列表数据是否实现
互动）
输入域测试测试要点？（web）
输入域测试主要分为以下几个方面
1） 对于手机、邮箱、证件号等的输入是否有长度及类型的控制
2） 输入中文、英文、数字、特殊字符（特别注意单引号，反斜杠）及这四类混合输入，
是否会报错
3） 输入空格、空格+数据、数据+空格，是否会报错
4） 输入html语言的
5） 输入全角、半角的英文、数字、特殊字符等，是否报错
6） 是否有必填项的控制；不输入必填项，是否有有好提示信息
7） 输入超长字段，页面是否被撑开
8） 分别输入大于、小于、等于数据表规定字段长度的数据，是否报错
9） 输入非数据表中规定的数据类型的字符，是否有有好提示信息
10） 在文本框中输入回车，显示时，是否回车换行
11） 密码输入域数据是否可见
分页测试测试要点？（web）
分页测试主要分为以下几个方面
1） 当没有数据时，首页、上一页、下一页、尾页标签全部置灰
2） 在首页时，“首页”,”上一页”标签置灰，在尾页时，“尾页”,”下一页”标签置灰，在中间页时，四个标签均可点击，且跳转正确
3） 翻页后，列表中的数据是否仍按照指定的顺序进行排序
4） 各个分页标签是否在同一水平线上
5） 各个页面的分页标签是否一致
6） 分页的总页数及当前页数显示是否正确
7） 是否能正确跳转到指定的页数
8） 再分页处输入非数字字符（英文，特殊字符等），输入0或超出总页数的数字，是
否有友好提示信息
9） 是否支持回车键的监听
易用性测试测试要点？（web）
整体界面测试
（1）给用户的整体感：舒适感；凭感觉能找到想要找的信息；设计风格是否一致
控件测试
（2）各控件的功能
多媒体测试
（1）图形要有明确的用途，图片、动画排列有序且目的明确
（2）图片按钮链接有效，并且链接的属性正确（比如是新建窗口打开、当前页面打开）
（3）背景图片应该与字体颜色和前景颜色相搭配
（4）检查图片的大小和质量：一般jpg、gif、png；不影响图片质量的情况下能使图片的大小减小到30kb以下
（5）gif动画是否设置了正确的循环模式，颜色是否正常
（6）Flash、Silverlight元素是否正常
导航测试
（1）站点地图和导航条：位置是否合理；页面结构
内容测试
（2）提供信息的正确性、准确性、相关性
容器测试
（1）DIV
（2）表格：作为控件，设置是否正确；长宽是否足够。作为较早的网页布局方式，考虑浏览器窗口尺寸的变化；内容动态增加或删除对界面的影响
安全性测试要点？（web）
安全性测试要求：
（1）能够对密码试探工具进行防范
（2）能够防范对Cookie攻击的常用手段
（3）敏感数据保证不用明文传输
（4）能防范通过文件名猜测和查看html文件内容获取重要信息
（5）能保证在网站收到工具后在给定时间内恢复，重要数据丢失不超过1小时
测试要点
（1）应用级的安全
应用级的安全测试目的在于查找Web系统自身程序设计中存在的安全隐患，测试区域有：
（1.1）注册与登录：有效、无效的用户名和密码；要注意是否存在大小写敏感；可以尝试多少次的限制；是否可以不登录而直接浏览某个页面
（1.2）在线超时：超时限制
（1.3）操作留痕：相关信息是否写入日志
（1.4）备份与恢复：数据库增量备份；数据库完全备份；系统完全备份
（2）传输级的安全
传输级的安全测试目的在于测试数据经过客户端传送到服务器可能存在的安全漏洞，服务器防范非法访问的能力，测试要点：
（2.1）HTTPS和SSL测试；服务器端的脚本漏洞检查；测试未经授权，就不能在服务器端放置和编辑脚本问题
（2.2）防火墙测试：防火墙功能；防火墙设置
（2.3）数据加密测试：对介入信息的传送、存取、处理人的身份和相关内容进行验证
（2.4）密钥：密钥的产生、分配保存、更换与销毁
兼容性测试要点？（web）
平台测试：windows；unix；macintosh；linux
浏览器测试：不同厂商的浏览器对Java、Javascript、ActiveX、plug-ins或不同的HTML的规格不同的支持；框架和层次结构在不同浏览器也不同的显示
软件测试常用工具有哪些？
1、基本测试工具：（所有测试都会用到）
bug管理工具：bugfree、Bugzilla、mantis
数据库工具：plsql developer（Oracle）、Navicat（MySQL）
测试管理工具：Testlink、禅道、ALM
版本控制工具：SVN 、git
2、中级测试：
常用自动化测试工具：
web端：RobotFramework、Selenium
移动端：appium
开发工具：java ：eclipse 、myeclipse 、IDEA
python ：PyCharm 、vscode、eclipse
3、高级测试：
常用性能测试工具：loadrunner、Jmeter、Monkey（移动端）
常用接口测试工具：loadrunner、Jmeter、SoapUI、postman
抓包工具：fidder 、charles、firebug、wireshark
虚拟机：vm 、xshell
单元测试：junit（java）、testng（java）、unittest（python）、pytest（python）
mysql与Oracle的区别？
简述解释：
MySQL比较小，而且免费，开源的缘故，现在也很健壮，若不是大型应用的话，MySQL足以应付一切。
oracle比较庞大，整个体系都很健全。
简单的说MySQL是实用很好用，oracle就是很好很强大
MySQL在安全性上没有Oracle做的强大
详细解释：
1.Oracle是大型数据库，Mysql是中小型数据库
2.Oracle占有内存空间大，Mysql占有小
3.Oracle支持大并发访问量，是OLTP最好的工具，Mysql并发小，面对大访问量可以做分表分库优化
4.Oracle没有自动增长类型，Mysql一般使用自动增长类型
5.Oracle处理翻页的SQL语句就比较繁琐了。每个结果集只有一个ROWNUM字段标明它的位置,并且只能用ROWNUM<100,不能用ROWNUM>80，MYSQL处理翻页的SQL语句比较简单，用LIMIT开始位置,记录个数
6.MYSQL的非空字段有空的内容，ORACLE里定义了非空字段就不容许有空的内容。按MYSQL的NOT NULL来定义Oracle是is null
7.MYSQL里用 字段名 like ‘%字符串%’,ORACLE用 字段名like ‘%字符串%’但不能使用索引,速度不快。【like ‘%’开头 无法使用索引 不使用开头 可以使用索引】
8.Oracle实现了ANSII SQL中事务的隔离级别、传播特性等比Mysql强；
9、MySQL使用三个参数来验证用户，即用户名，密码和位置；Oracle使用了许多安全功能，如用户名，密码，配置文件，本地身份验证，外部身份验证，高级安全增强功能等。