目录
一、如何制定测试计划（是否拥有测试计划的制定经验、具备合理安排测试的能力、文档输出的能力）
二、在项目中如何保证软件质量（对测试工作有一些自己的思考和认识）
三、功能测试用例一般包含哪些内容（测试用例编写包含的要素、测试用例要素的核心要素）
四、黑盒（或功能）测试用例设计方法有哪些（测试用例设计基本功、用例设计的理解）
五、APP测试和web测试有什么区别（测试类型、测试理论知识的掌握程度）
六、发现一个bug，怎么定位是app端还是服务器端的问题（问题排查的能力）
八、当开发人员说不是bug时，你如何应付？（沟通、人际关系）
九、遇到概率性bug怎么办？（对于偶现bug的规律总结、处理方式）
十二、Bug优先级和严重程度如何划分（对于优先级和严重程度的理解）
十四、给你一个网站，如何开展测试（对软件测试流程的理解、测试项目的计划安排能力）
十五、bug的生命周期（bug处理流程）
一、如何制定测试计划（是否拥有测试计划的制定经验、具备合理安排测试的能力、文档输出的能力）
测试计划包括测试目标、测试范围、测试环境的说明、测试类型的说明（功能、安全、性能、稳定性）、测试工具、模块的划分、测试负责人、测试执行轮次的时间安排、相关文档在文档管理库中的位置、测试的风险。其中模块划分需要根据测试人员对于业务的熟悉程度及个人能力进行分配，工作量的估算需要根据以往测试时的经验，结合本次需求的修改，可以大致估算出测试量
二、在项目中如何保证软件质量（对测试工作有一些自己的思考和认识）
项目质量不仅仅是某个人或某个团队来保障的，而是整个团队一起努力的结果，在公司级别需要有一个规范的项目流程
1、产品，保证迭代过程中的产品逻辑，对于可能的兼容，升级做出预判，并给出方案
2、设计，满足产品表达的同时，保证设计的延续性
3、开发，产品细节的保证，技术方案选型要严谨，考虑兼容、性能，开发完成后要充分自测，严格遵循开发规范操作
4、测试，验证产品逻辑，站在用户角度对交互设计进行系统验证，尽可能多地使用技术手段保证测试质量
三、功能测试用例一般包含哪些内容（测试用例编写包含的要素、测试用例要素的核心要素）
要素一般包括：用例编号、用例优先级、测试目的、所属模块、前提条件、测试环境、输入数据、测试步骤、预期结果、测试脚本等
核心要素：用用例优先级、测试目的、预期结果
四、黑盒（或功能）测试用例设计方法有哪些（测试用例设计基本功、用例设计的理解）
等价类划分法：等价类划分方法将程序所有可能的输入数据（有效的和无效的）划分为若干个等价类，然后从每个部分中选取具有代表性的数据当作测试用例进行合理的分类，测试用例由有效等价类和无效等价类的代表组成，从而保证测试用例具有完整性和代表性。
边界值方法：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
错误推断法：在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性的编写检查这些错误测试用例的方法。
因果图方法：因果图法是种适合于描述对于多中输入条件组合的测试方法，根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件设计的各种组合情况。
判定表驱动分析方法：判定表是黑盒测试的方法之一，判定表是把作为条件的所有输入的各种组合值以及对应输出值都罗列出来而形成的表格。
正交分解法：是研究多因素多水平的一种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。
全局探索式测试方法：测试人员根据应用程序所提供的信息自由发挥，不受限制，不受任何约束的探索程序的各种功能。一般分为：商业区测试类型，历史区测试类型，娱乐区测试类型，旅游区测试类型，旅馆区测试类型和破旧区测试类型。
场景分析法：分析软件应用的场景，从用户的角度出发，从场景的角度来设计测试用例，是一种面向用户的测试用例设计方法。关心用户做什么，而不是关心产品做什么。
五、APP测试和web测试有什么区别（测试类型、测试理论知识的掌握程度）
Web端测试和移动端测试类型基本相似都需要进行功能测试、性能测试、安全性测试，他们主要区分web端一般都是b/s架构，基于浏览器的。app是c/s架构，是有客户端的。
从系统架构来看：web测试只要更新了服务器端，客户端就会同步更新；而如果是app端下修改了服务器，意味着客户端用户所有使用和新版本都需要进行回归测试一遍。
客户端性能方便：wed端可能只会关注响应时间；app则还要关心流量、电量、cpu等；
兼容方面：web是基于浏览器的，所以更倾向于浏览器（IE、Chrome、Firefox）和电脑硬件，电脑系统方向的兼容；app测试则必须依赖于手机或者pad，不仅要看分辨率、屏幕尺寸、重要看设备系统。
六、发现一个bug，怎么定位是app端还是服务器端的问题（问题排查的能力）
1、抓包分析，通过对客户端进行抓包，分析服务器端返回的数据是否符合预期，如果服务器端数据是正确的，那就是客户端的问题
2、日志分析，可以通过查看客户端/服务端的日志，分析有没有异常的日志信息，从而确定具体原因
七、持续集成的目的是什么（具备参与持续集成的能力）
持续集成指的是，频繁地（一天多次）将代码集成到主干。
它的好处主要有两个：
1、快速发现错误，每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。
2、防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度偏大，甚至难以集成。
持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试，只要有一个测试用例失败，就不能集成。
八、当开发人员说不是bug时，你如何应付？（沟通、人际关系）
开发人员说不是bug，有2种情况：
一是需求没有确定，所以这个时候可以找产品经理进行确认，需不需要改动，商量确定好后再看要不要改。
二是这种情况不可能发生，所以不需要修改，这个时候可以尽可能的说出是bug的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那可以将这个问题提出来，跟开发经理和测试经理进行确认，如果要修改就修改，如果不要修改就不改。如果最终bug被确定不改，那么就要在测试报告里面记录一下，以便以后查阅。
九、遇到概率性bug怎么办？（对于偶现bug的规律总结、处理方式）
概率性bug，又叫幽灵bug，首先需要明确的是，该类bug也是需要提单的，描述清楚当时操作环境、操作步骤、数据、并提供必要日志，可备注上可能产生的原因。然后耐心一点，运用排除法、错误推断找规律，必要时找开发人员、项目经理一起定位分析讨论，如果最终仍未解决，那么需要在测试报告中体现，并分析可能造成的影响，大家一起权衡该bug是否可遗留。
十、什么是回归测试？如何做回归测试？
回归测试，即就是在软件生命周期中，只要软件发生了改变，就可能给该软件产生问题；所以，每当软件发生变化时我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否破坏原有的正常功能。
回归测试可以发生在任何一个阶段，包括单元测试、集成测试和系统测试，那我们该如何做回归测试呢？总结为以下几点
1、在测试策略制定阶段，制定回归测试策略
2、确定需要回归测试的版本
3、回归测试版本发布，按照回归测试策略执行回归测试
4、回归测试通过，关闭缺点跟踪单（问题单）
5、回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试
十一、如何提交一份高质量的缺陷跟踪单
首先要明确，缺点跟踪单不仅仅是给自己看的，所以高质量的缺陷单，最主要的一条判断标准是，别人一看就懂，标题简洁明了，步骤条理清晰。还需要考虑缺陷的完备性，比如缺陷等级、所属功能模块、版本、复现步骤、预期结果、实际结果、产生原因、日志截图等
十二、Bug优先级和严重程度如何划分（对于优先级和严重程度的理解）
Priority（优先级）和Severity（严重程度）是提交bug的两个重要属性。
通常测试人员在提交Bug时，制定一Bug的严重程度，即该Bug的严重程度，而将Priority交给Project Leader或Team Leader来定义，由他们来决定该Bug被修复的优先等级。某种意义上来说，优先级的定义要依赖于严重程度，在大多数情况下，严重程度越严重，那么这个Bug的优先级就越高。严重程度如下：
Blocker（有妨碍的）：即系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定
Critical（紧要的）：即影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性
Major（严重的）：即界面、性能缺陷、兼容性。
Minor/Trivial（次要的/不严重的）：即易用性及建议性问题
Priority（优先级）：Immediate（立刻）、Urgent（紧要、优先）、High（高度重视）、Normal（正常）、Low（稍缓）
十三、做好测试用例设计工作的关键是什么
关键点就是熟悉需求，但是需求可以分为以下几个方面：
1）熟悉本次业务需求
2）熟悉其他系统和本次需求的关联
3）熟悉开发设计文档，了解开发实现逻辑
4）熟悉数据库设计文档，了解数据存储
5）熟悉项目架构，发现隐藏需求
十四、给你一个网站，如何开展测试（对软件测试流程的理解、测试项目的计划安排能力）
1）查找需求说明、网站设计等相关文档，分析测试需求。
2）制定测试计划，确定测试范围和测试策略。
3）设计测试用例，包括功能、兼容、性能、安全等方面
4）开展测试执行
5）回归测试及测试总结
十五、bug的生命周期（bug处理流程）
New：发现bug，未经评审决定是否指派给开发人员进行修改
Open：确认bug，并且认为需要进行修改，指派给相应的开发人员
Fixed：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证
Rejected：如果认为不是Bug，则拒绝修改
Delay：如果认为暂时不需要修改或暂时不能修改，则延后修改
Closed：修改状态的Bug经测试人员的回归测试验证通过，则关闭Bug
Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改
2766
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
