从其他帖子转运过来的，后面会持续更新          参考：https://www.nowcoder.com/discuss/358012785601634304        1.如果需求不明确的话你怎么办?        需求不明确的话我会在需求澄清会议上面提出来，问清楚这个需求只有明确需求，        才能更好的完成工作，后续工作中还是不清楚，可以找产品再去确认这个需求。         2.  用例包含哪些部分，哪些用例设计方法，你一般常用哪些方法        （1）用例包含 测试项目，用例编号、测试标题、优先级、预置条件、操作步骤、测试数据、预期结果         黑盒测试用例设计方法：主要是等价类、边界值、错误推测法、判定表、因果图、正交表、         流程分析法、状态迁移法、异常分析法。         常用的：等价类、边界值、判定表、流程分析法、错误推测法。         等价类是指某个输入域的子集合，在该子集合中，各个输入数据对于揭露程序中的错误都是等效的， 并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试，因此，可以把全部 输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件， 就可以用少量代表性的测试数据取得较好的测试结果， 等价类划分可有两种不同的情况有效等价类和无效等价类。         边界值的话就是对等价类划分方法的补充。测试工作经验告诉我，大量的错误往往是发生在输入或输出范围的边界上而不是发生在输入输出范围的内部，因此的话针对各种边界情况来设计测试用例，可以查出更多的错误，使用边界值分析方法设计测试用例的话，首先应该确定边界情况，通常输入和输出等价类的边界，就是应着重测试的边界情况应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。         对于错误推断法，这个是基于经验和直觉推测程序中所有可能存在的各种错误，         从而有针对性的去设计测试用例的方法的，主要就是列举出程序中所有可能有的错误和容易发生错误的特殊情况去根据这些情况来选择测试用例，例如，在单元测试时曾列出的许多在模块中常见的错误以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数据和输出数据为0的情况。 输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况，可选择这些情况下的例子作为测试用例。                  前面介绍的等价类划分方法和边界值分析方法都是着重考虑输入条件但都没有考虑输入条件之间的联系，相互组合等等的情况。考虑输入条件之间的相互组合，可能会产生一些新的情况，         但是要检查输入条件的组合并不是一件容易的事情，即使把所有输入条件划分成等价类，         他们之间的组合情况也相当多，因此的话可以考虑采用一种适合于描述对于多种条件的组合， 相应产生多个动作的形式来考虑设计测试用例，这就需要用到因果图(逻辑模型)。         因果图方法最终生成的就是判定表它适合检查程序输入条件的各种组合情况。                 3. 你提交的bug，开发不认可怎么办?         （1）首先我会再看需求文档，是不是我的理解有误，如果是我对需求理解错的话我就去关闭bug。         （2）如果是bug再去让其他测试人员看看听下他们的意见，然后自己先再三去复测，并目保存好截图和日志，确定这是一个bug之后我就去跟开发说明白，并且给他看bug重现的截图以及日志。        （3）如果开发还是不认可的话我就跟产品或项目经理说明白情况。       当开发人员说不是BUG时，你如何应付？         开发人员说不是bug，有2种情况，        一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要不要改。        二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。                 4.对应无法重现bug，应该怎么处理?         首先，我会多测几次，测了好多次都无法重现的话我就先把bug挂起，并且留意一下，看看往后的测试中，如果在后面的测试中重现bug就激活，如果经过几个版本都还没发现的话就关闭bug。            5. 界面中的乱码可以是哪里导致的?              (1)数据库中的编码设置    (2)前端页面编码    (3)后台代码也会编码              6. bug的级别有哪些，级别如何判断          （1）致命：对业务有至关重要的影响，业务系统完全丧失业务功能，无法再继续进行， 或业务系统丢失了业务数据且无法恢复，影响公司运营的重要业务数据出错。         （2）严重：对业务有严重的影响，业务系统已经丧失可部分的重要的业务功能，或业务系统丢失了业务数据且可以恢复，一般业务数据出错。         （3）一般：对业务有较小的影响，业务系统丧失了较少的业务功能，例如：界面错误，打印或显示格式错误。         （4）提示：对业务没有影响，不影响业务过程正常进行，例如：辅助说明描述不清楚，提示不明确的错误提示。            7. 测试中，如何判断是前端的bug还是后端的bug呢?          通常可以利用抓包工具来进行分析。可以从三个方面进行分析：请求接口、传参数、响应。         1）请求接口un是否正确如果请求的接口ur错误，为前端的bug         2）传参是否正确如果传参不正确，为前端的bug         3）请求接口u和传参都正确，查看响应是否正确如果响应内容不正确，为后端bug         4）也可以在浏览器控制台输入js代码调试进行分析            8. 项目上线后发现bug，测试人员应该怎么办          看严重级别：严重还是不严重         严重的：紧急变更上线         不严重：修复好后跟下个版本一起上线         用户会通过运维反馈到项目组这边，项目经理会根据功能模块的负责人，分给对应的开发与测试。         测试人员：编写对应的测试用例、测试环境中重现bug、提交bug、 交给开发进行修复、修复完成bug、进行bug的复测。         如果测试环境无法重现，可以导入生产环境的包到测试环境中测试， 还是不能复现，查看生产环境的日志去定位问题。            9. 如何保证质量           (1)需求要吃透，多问，多去了解。         (2)严格按照测试流程去执行：多考虑用户测试场景，使用测试用例设计方法，多评审。         (3)要有良好的测试执行：要求用例执行率达到100%，多轮测试，进行探索性测试，         需要测试之间交叉测试，用工具来管理我们的测试工作(禅道， testlink， excel，tapd)         (4)不断的反思与提升。            10. 为什么要写测试用例?              1)提高测试效率    2)提高测试覆盖率     3)监控测试进度情况    4)也是质量的标准指标              11.  什么是冒烟测试? 在什么时候进行冒烟测试?              冒烟测试一般我们是在系统测试之前，对所有主体的业务功能，测试看是否存在严重bug；如果存在严重bug，表示，冒烟测试不通过          12. 和开发沟通。是怎么沟通的         比如有一些不清晰的内容会去问开发，还有提完bug后会跟踪bug的进度，提醒开发尽快修复bug，还有测接口的时候去找开发拿接口文档，其实我们的工作跟开发都是息息相关的所以都经常都会有沟通的        13．兼容性测试你们是怎么测的?   app与web         Web： 不同的浏览器，E，谷歌，火狐，浏览器显示比例，浏览器前进，后退，刷新按钮。         App： 不同手机厂商，型号，系统版本，内存大小，分辨率，屏幕的大小，高端机与低端机，考虑平板        参考链接：https://www.nowcoder.com/discuss/360911376628371456 web 测试和 app 测试的区别?         面试官考查的目的：对 web 和 app 的认识         参考：网页（PC、手机），app（手机），web，app         （混合 APP，纯 APP），共同点：兼容性，客户端         不同点：app 手机，耗电量，网络差。                兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行，即是通常说的软件的可移植性。         兼容的类型，如果细分的话，有平台的兼容，网络兼容，数据库兼容，以及数据格式的兼容。         兼容测试的重点是，对兼容环境的分析。通常，是在运行软件的环境不是很确定的情况下，才需要做兼容。根据软件运行的需要，或者根据需求文档，一般都能够得出用户会在什么环境下使用该软件，把这些环境整理成表单，就得出做兼容测试的兼容环境了。             14. 测试过程中，发现很多用例重复的，有的人认为没必要再测，你怎么看?              如果是同一个横块，重复用例，我们可以考虑不再进行重复测试，如果不同模块，引用相同的测试用例，我们还是需要重复测试               15. 产品上线评判的标准?              1）测试用例执行率100%，通过率95%          2）1-2级bug修复率达到100%，3-4级bug修复率达到95%          16.测试中有哪些风险            1）测试，需求理解上面有偏差          2）测试人员水平不够，测试人员覆盖点不全          3）测试人员时间不够，导致测试不完全          4)测试环境上面不足，导致测试点不能完全测试完成          17.怎么保证测试质量或者你怎么保证你100%覆盖了需求             把需求了解通透，引用用例评审机制；          然后编写测试用例的时候用边界值，用等价类补充一些用例，根据过往经验用错误推断法来追加一些用例，；          如果存在组合情况的话我会用因果图或者判断表来编写；          如果业务场景清晰的情况下我会用流程分析法；          如果状态有发生改变的话我就会用状态迁移法。          编写用例一个极其考验耐心的事情，要考虑到各种场景，全面覆盖到会出现的场景。          ----------------------------------------------------------------------------------------------------        参考链接：https://www.nowcoder.com/discuss/353150428479168512        18.你的测试职业发展是什么？         测试经验越多，测试能力越高。所以我的职业发展是需要时间积累的，一步步向着高级测试工程师奔去。而且我也有初步的职业规划，前3年积累测试经验，按如何做好测试工程师的要点去要求自己，不断更新自己改正自己，做好测试任务。         优势在于我对测试坚定不移的信心和热情，虽然经验还不够，但测试需要的基本技能我有信心在工作中得以发挥。                 19. 你认为测试人员需要具备哪些素质        做测试应该要有一定的协调能力，因为测试人员经常要与开发接触处理一些问题，如果处理不好的话会引起一些冲突，这样的话工作上就会不好做。还有测试人员要有一定的耐心，有的时候做测试很枯燥乏味。除了耐心，测试人员不能放过每一个可能的错误。                 20. 你为什么能够做测试这一行         虽然我的测试技术还不是很成熟，但是我觉得我还是可以胜任软件测试这个工作的，因为做软件测试不仅是要求技术好，还有有一定的沟通能力，耐心、细心等外在因素。综合起来看我认为我是胜任这个工作的。        21.测试的目的是什么？        测试的目的是找出软件产品中的错误，是软件尽可能的符合用户的要求。当然软件测试是不可能找出全部错误的。                 22. 测试分为哪几个阶段？        一般来说分为5个阶段：单元测试、集成测试、确认测试、系统测试、验收测试         参考链接：https://www.nowcoder.com/discuss/360911376628371456        单元测试针对的是软件设计的最小单元--程序模块（面向过程中是函数、过程；面向对象中是类。）,进行正确性检验的测试工作,在于发现每个程序模块内部可能存在的差错.一般有两个步骤:人工静态检查\动态执行跟踪；         集成测试针对的是通过了单元测试的各个模块所集成起来的组件进行检验,其主要内容是各个单元模块之间的接口,以及各个模块集成后所实现的功能；         系统测试针对的是集成好的软件系统，作为整个计算机系统的一个元素,与计算机硬件\外设\某些支持软件\数据和人员等其他系统元素结合在一起,要在实际的运行环境中,对计算机系统进行一系列的集成测试和确认测试。        23. 单元测试的测试对象、目的、测试依据、测试方法？        测试对象是模块内部的程序错误，目的是消除局部模块逻辑和功能上的错误和缺陷。测试依据是模块的详细设计，测试方法是采用白盒测试。                 24. 根据你以前的工作或学习经验描述一下软件开发、测试过程，由哪些角色负责，你做什么        要有架构师、开发经理、测试经理、程序员、测试员。我在里面主要是负责所分到的模块执行测试用例。                 25．根据你的经验说说你对软件测试/质量保证的理解        软件质量保证与测试是根据软件开发阶段的规格说明和程序的内部结构而精心设计的一批测试用例(即输入数据和预期的输出结果)，并根据这些测试用例去运行程序，以发现错误的过程。它是对应用程序的各个方面进行测试以检查其功能、语言有效性及其外观排布。                 26. 软件测试的流程是什么？         需求调查：全面了解系统概况、应用领域、软件开发周期、软件开发环境、开发组织、时间安排、功能需求、性能需求、质量需求及测试要求等。根据系统概况进行项目所需的人员、时间和工作量估计以及项目报价。        制定初步的项目计划。         测试准备：组织测试团队、培训、建立测试和管理环境等。         测试设计：按照测试要求进行每个测试项的测试设计，包括测试用例的设计和测试脚本的开发等。         测试实施：按照测试计划实施测试。         测试评估：根据测试的结果，出具测试评估报告。                 27. Alpha测试与Beta测试有什么区别？         –Alpha testing (α测试),是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试        –Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场        28.我现在有个程序，发现在Windows上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题？         –1、检查系统是否有中毒的特征；         –2、检查软件/硬件的配置是否符合软件的推荐标准；         –3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务；         –4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；         –5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况。                  29. 测试的策略有哪些？         黑盒/白盒，静态/动态## 标题，手工/自动，冒烟测试，回归测试，公测（Beta测试的策略）                 30.你认为做好测试计划工作的关键是什么？         软件测试计划就是在软件测试工作正式实施之前明确测试的对象，并且通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划，保证有效的实施软件测试；         做好测试计划工作的关键 ：目的，管理，规范         （1）、明确测试的目标，增强测试计划的实用性编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确         （2）、坚持“5W”规则，明确内容与过程“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。         （3）、采用评审和更新机制，保证测试计划满足实际需求测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。         （4）、分别创建测试计划与测试详细规格、测试用例应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。                 31. 软件的安全性应从哪几个方面去测试？         (1) 用户认证机制：如数据证书、智能卡、双重认证、安全电子交易协议         (2) 加密机制         (3) 安全防护策略：如安全日志、入侵检测、隔离防护、漏洞扫描         (4) 数据备份与恢复手段：存储设备、存储优化、存储保护、存储管理         (5) 防病毒系统         参考：https://www.nowcoder.com/discuss/360911376628371456        软件安全性测试包括程序、数据库安全性测试。根据系统安全指标不同测试策略也不同。         用户认证安全的测试要考虑问题： 明确区分系统中不同用户权限 、系统中会不会出现用户冲突 、系统会不会因用户的权限的改变造成混乱 、用户登陆密码是否是可见、可复制 、是否可以通过绝对途径登陆系统（拷贝用户登陆后的链接直接进入系统）；         用户退出系统后是否删除了所有鉴权标记，是否可以使用后退键而不通过输入口令进入系统 、系统网络安全的测试要考虑问题 、测试采取的防护措施是否正确装配好，有关系统的补丁是否打上 、模拟非授权攻击，看防护系统是否坚固 、采用成熟的网络漏洞检查工具检查系统相关漏洞（即用最专业的黑客攻击工具攻击试一下，现在最常用的是 NBSI 系列和 IPhacker IP ） ；         采用各种木马检查工具检查系统木马情况 、采用各种防外挂工具检查系统各组程序的外挂漏洞数据库安全考虑问题： 系统数据是否机密（比如对银行系统，这一点就特别重要，一般的网站就没有太高要求）、系统数据的完整性（我刚刚结束的企业实名核查服务系统中就曾存在数据 的不完整，对于这个系统的功能实现有了障碍） 、系统数据可管理性 、系统数据的独立性 、系统数据可备份和恢复能力（数据备份是否完整，可否恢复，恢复是否可以完整）                          32. 一套完整的测试应该由哪些阶段组成？         需求评审（有开发人员，产品经理，测试人员，项目经理）        －>需求确定(出一份确定的需求文档)        －>开发设计文档（开发人员在开始写代码前就能输出设计文档）        －>想好测试策略，写出测试用例        －>发给开发人员和测试经理看看（非正式的评审用例）        －>接到测试版本        －>执行测试用例（中间可能会补充用例）        －>提交bug（有些bug需要开发人员的确定（严重级别的，或突然发现的在测试用例范围之外的，难以重现的），有些可以直接录制进TD）        －>开发人员修改（可以在测试过程中快速的修改）        －>回归测试（可能又会发现新问题，再按流程开始跑）                 33. 如何理解压力、负载、性能测试测试？         性能测试是一个较大的范围，实际上性能测试本身包含了性能、强度、压力、负载等多方面的测试内容。         压力测试是对服务器的稳定性以及负载能力等方面的测试，是一种很平常的测试。增大访问系统的用户数量、或者几个用户进行大数据量操作都是压力测试。        负载测试是压力相对较大的测试，主要是测试系统在一种或者集中极限条件下的相应能力，是性能测试的重要部分。         100个用户对系统进行连续半个小时的访问可以看作压力测试，那么连续访问8个小时就可以认为负载测试，1000个用户连续访问系统1个小时也可以看作是负载测试。实际上压力测试和负载测试没有明显的区分。测试人员应该站在关注整体性能的高度上来对系统进行测试。                 34. 如何编写提交给用户的测试报告？         ----根据内部测试报告进行编写，一般可以摘录；         ----不可以向客户报告严重缺陷，即使是已经修改的缺陷，开发中的缺陷也没有必要让客户知道；         ----报告上可以列出一些缺陷，但必须是中级的缺陷，而且这些缺陷必须是修复的；        -----报告上面的内容尽量要真实可靠；         ----整个测试报告要仔细审阅，力争不给项目带来负面作用，尤其是性能测试报告。                 35.您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。 （与第2题）        （1）等价类划分         划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.         （2）边界值分析法         边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.         使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.         （3）错误推测法         基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.         错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.         （4）因果图方法         前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.                 36. 简述一下c/s模式或者b/s模式？         C/S模式：客户端/服务器模式。工作原理：Client向Server提交一个请求；Server则使用一些方法处理这个请求，并将效果返回给Client。         B/S结构，即Browser/Server(浏览器/服务器)结构，主要是利用了不断成熟的WWW浏览器技术，结合浏览器的多种Script语言(VBScript、JavaScript…)和ActiveX技术，用通用浏览器就实现了原来需要复杂专用软件才能实现的强大功能，并节约了开发成本，是一种全新的软件系统构造技术。