B/S 只需要操作系统和浏览器就行，可实现跨平台，客户端零维护，个性化能力低，响应速度慢。 C/S 响应速度快，安全性高，一般用于局域网，因为要针对不同的操作系统需要针对性的开发，并且维护成本高
2、HTTP协议
1、https协议需要申请证书，一般免费证书较少，因而需要一定费用。
2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
3，POST与GET区别
1，get是不安全的，因为在传输过程中数据被放在请求的URL中；post所有操作对用户来说都是不可见的。 2，get传输量小，这主要是因为受URL长度限制；post传送的数据量较大，一般被默认为不受限制。 3，get限制form表单数据集的值必须为ASCII字符；而post支撑整个IS010646字符集。 4，get执行效率却比post方法好。Get是form提交默认方法。
4，Cookie和Session的区别与联系
1、Cookie和Session都是会话技术，Cookie是运行在客户端，Session是运行在服务器端。 2、Cookie有大小限制以及浏览器在存cookie的个数也有限制，Session是没有大小限制和服务器的内存大小有关。 3、Cookie有安全隐患，通过拦截或本地文件找得到你的cookie后可以进行攻击。 4、Session是保存在服务器端上会存在一段时间才会消失，如果session过多会增加服务器的压力
5，测试的目的
软件测试的目的是为了保证软件产品的最终质量，在软件开发的过程中，对软件产品进行质量控制。一般来说软件测试应由独立的产品评测中心负责，严格按照软件测试流程，制定测试计划、测试方案、测试规范，实施测试，对测试记录进行分析，并根据回归测试情况撰写测试报告。测试是为了证明程序有错，而不能保证程序没有错误
6，软件测试原则
1，测试显示软件是否存在缺陷 2，穷尽测试时不可能的 3，测试尽早介入 4，缺陷集群性 5，杀虫剂悖论 6，测试活动依赖于测试内容 7，没有错误是好是谬论
7，软件测试分为哪几个阶段？
单元测试：比如说对Java中的类和方法的测试，一般由软件开发人员实施（尽可能保证测试用例相对独立，测试过程中不要调用其他类的方法，而是在测试用例中重写模拟方法）
集成测试：（测试各个单元模块的接口）在单元测试的基础上，把软件单元按照*概要规格说明书*要求，组装模块，测试看是否模块达到了规格技术指标。
系统测试：（黑盒测试）在经过集成测试的单元模块，按照整体*需求规格说明书*，进行一套有效严格的测试，保证软件的正常运行。（集成测试偏重于技术角度，系统测试偏重于业务角度）
回归测试：（回归测试在测试生命周期中是很重要的一部分，会进行多次回归测试），是指在发生修改之后，再重新回去测试一下，避免修改的内容导致了其他的错误。验证之前出现过但已修复好的缺陷不再重新出现。
冒烟测试：（是自由测试的一种）是指开发者功能完成后的完整性功能测试，发现问题后反馈给开发者进行修改，然后看这次修改是否真的修复解决了这bug，或者对其他模块造成了影响，这个时候就需要冒烟测试来进行验证，缺点就是覆盖率低。
验收测试：也叫交付测试，是针对用户需求、业务流程进行的整体测试，确认是否满足验收标准，由用户、客户看是否接受系统，可以部署上线。
Alpha测试：用户在开发者的场所进行测试，是一个可控的环境中测试的。
Beta测试：是用户在对软件产品进行测试，开发者不在现场，用户对测试过程中遇到的bug进行记录，开发并对它进行修改，再测试，直到用户觉得可以了，就部署上线。
8，单元测试与集成测试的侧重点
单元测试
是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试，测试重点是系统的模块，包括子程序的正确性验证等。
集成测试
也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求，组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。测试重点是模块间的衔接以及参数的传递等。
9，系统测试范围
指的是将整个软件系统看做一个1个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。 系统测试由黑盒测试人员在整个系统集成完毕后进行测试，前期主要测试系统的功能是否满足需求，后期主要测试系统运行的性能是否满足需求，以及系统在不同的软硬件环境的兼容性等
10，a测试与ß测试的区别
它们都是验收测试！
α测试是指把用户请到开发方的场所来测试 β测试是指在一个或多个用户的场所进行的测试。
α测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。 β测试的环境是不受开发方控制的, 用户数量相对比较多,时间不集中。
α测试先于β测试执行。通用的软件产品需要较大规模的β测试,测试周期比较
11，验收测试怎么做？
-
制定测试计划，测试项，测试策略及验收通过准则，并经过客户参与的计划评审。
-
建立测试环境，设计测试用例，并经过评审。
-
准备测试数据，执行测试用例，记录测试结果。
-
分析测试结果，根据验收通过准则分析测试结果，作出验收是否通过及测试评价。 测试项目通过； 测试项目没有通过，并且不存在变通方法，需要很大的修改； 测试项目没有通过，但存在变通方法，在维护后期或下一个版本改进； 测试项目无法评估或者无法给出完整的评估。此时必须给出原因。如果是因为该测试项目没有说明清楚，应该修改测试计划。
-
提交测试报告。
12，白盒、黑盒和灰盒测试区别
白箱测试或白盒测试(White-box testing 或glass-box testing)是通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代码在算法，溢出，路径，条件等等中的缺点或者错误，进而加以修正。
黑箱测试或黑盒测试(Black-box testing)是通过使用整个软件或某种软件功能来严格地测试, 而并没有通过检查程序的源代码或者很清楚地了解该软件或某种软件功能的源代码程序具体是怎样设计的。测试人员通过输入他们的数据然后看输出的结果从而了解软件怎样工作。通常测试人员在进行测试时不仅使用肯定出正确结果的输入数据，而且还会使用有挑战性的输入数据以及可能结果会出错的输入数据以便了解软件怎样处理各种类型的数据。
灰箱测试或灰盒测试(Gray-box testing):灰箱测试就像黑箱测试一样是通过用户界面测试，但是测试人员已经有所了解该软件或某种软件功能的源代码程序具体是怎样设计的。甚至于还读过部分源代码。 因此测试人员可以有的放矢地进行某种确定的条件/功能的测试。这样做的意义在于:如果你知道产品内部的设计和对产品有透过用户界面的深入了解，你就能够更有效和深入地从用户界面来测试它的各项性能。
13，冒烟测试的目的
为正式测试前，验证是否产品或系统的主要需求或预置条件是否存在bug。
14，回归测试怎么做？
1、在测试策略制定阶段，制定回归测试策略 2、确定需要回归测试的版本 3、回归测试版本发布,按照回归测试策略执行回归测试 4、回归测试通过，关闭缺陷跟踪单（问题单） 5、回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试
15，全部回归与部分回归的区别？
对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止出现“以前应用没有的问题现在出问题了”，这是全部回归；当在测试过程中，发现某个模块存在缺陷，开发修复后，测试人员重新验证该缺陷是否被修复，以及验证相关联的模块是否受影响，这叫部分回归。
16，需求分析的目的
第一、把用户需求转化为功能需求：1）对测试范围进度量 2）对处理分支进行度量 3）对需求业务的场景进行度量 4）明确其功能对应的输入、处理和输出 5）把隐式需求转变为明确。
第二、明确测试活动的五个要素：测试需求是什么、决定怎么测试、明确测试时间、确定测试人员、确定测试环境：测试中需要的技能，工具以及相应的背景知识，测试过程中可能遇到的风险等等。测试需求需要做到尽可能的详细明确，以避免测试遗漏和误解。
17，测试计划的目的
1.尽早地明确测试工作内容（范围）、测试工作的方法以及测试工作所需要的各种资源 2.所有涉及到测试工作的人员，尽快将下一步测试工作需要考虑的问题和准备的条件落实。 3.测试计划工作的重点在于：对当前工作任务的准备和规划以及信息的交流。
18，什么时候开始写测试计划
开立项会之后由测试人员开始写测试计划
19，由谁来编写测试计划
测试人员
20，测试计划的内容
1.简介
2.参考文档和提交文件
3.进度安排
4.测试资源
5.严重程度和优先级
6.风险分析
7.测试策略
21，结束条件(项目上线的条件)
1) 软件系统在进行系统测试过程中，发现一、二级缺陷数目达到项目质量管理目标要求，测试暂停返回开发； 2) 软件项目在其开发生命周期内出现重大估算和进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份暂停或终止点数据； 3) 如有新的需求变更过大，测试活动应暂停，待原测试计划和测试用例修改后，再重新执行测试； 4) 若开发暂停，则相应测试也应暂停，并备份暂停点数据； 5) 所有功能和性能测试用例100％执行完成； 此外，测试是有成本的，当你2周发现2个bug有类似此种情况时，在产品质量要求不是十分严格的情况下，即可以停止测试了。
22，常见的测试风险
需求风险
测试用例风险
缺陷风险
代码质量风险
测试环境风险
测试技术风险
回归测试风险
沟通协调风险
研发流程风险
其他不可预计风险
23，测试用例的要素
1、*用例编号*：测试用例的编号有一定的规则，比如系统测试用例的编号定义规则：MS-ST-001，命名规则是项目名称+测试阶段类型(系统测试阶段)+编号。编号是为了查找测试用例，便于测试用例的跟踪。
2、*测试项目*：要测试项目的名称，可以是测试用例所属的大类，被测需求，被测模块或者是被测的单元。
3、*测试标题*：对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如”测试用户登录时输入错误密码时，软件的响应情况“。
4、*重要级别*：定义测试用例的优先级别，可以分为”高“、”中“、”低“三个级别。
高：保证系统基本功能、重要特性、实际使用频率比较高的用例；
中：重要程度介于高和低之间的测试用例；
低：实际使用频率不高，对系统业务功能影响不大的模块或功能的测试用例。
一般如果软件需求的优先级是”高“，那么针对该需求的测试用例优先级也是”高“；反过来也是一样。
5、*预置条件*：就是执行当前测试用例的前提描述，如果不满足这些条件，则无法进行测试。
6、*测试输入*：测试用例执行时，需要输入的外部信息。
7、*操作步骤*：执行当前测试用例所要经过的操作步骤，需要给出每一步操作的详细描述，测试人员根据测试用例操作步骤，完成测试用例的执行。
8、*预期结果*：当前测试用例的预期输出结果，用来与实际结果比较，如果相同则该测试用例通过，否则该测试用例失败。
以上八个要素是最重要的，下面这些选写：
9、*作者*：谁写的
10、*创建时间*：写用例的日期
11、*修改日期*：最后一个修改用例的日期
12、*测试结果*：执行用例后的结果：pass、fail、block
24，测试用例级别的划分
优先级一般都是和缺陷的严重程度对应的。
一般可以把优先级分为三种：
高（Highs）：保证功能性是稳定的，是按照需求的正常使用和实现点进行用例设计的，重要的错误和边界测试的测试用例的集合。
中（Mediums）：更全面的验证功能的各方面，包括流程中的各个节点出错情况、异常情况测试、中断、UI展示、用户体验等方面的测试用例设计
低（Lows）：不常被执行的测试用例。比如压力和性能测试用例设计，接口测试用例设计随着时间的推移已经从低级别变化到了中级别。
我们将测试用例分成：高，中和低。
25，怎样保证覆盖用户需求？
用户需求：描述了用户使用产品必须要完成的任务，在软件开发活动中，属于基本的需求。
系统需求：描述了软件设计人员、编程人员必须要完成的任务。系统分析员通过分析用户需求，把用户的需求转变成开发设计人员看得懂的系统需求。
测试需求：描述了软件测试人员必须要完成的任务。测试工程师通过分析系统需求，产生测试需求，作为测试活动的指导。
26，写好测试用例的关键 /写好用例要关注的维度
编写测试用例主要有以下6个主要作用： 1.便于理清测试思路，确保需覆盖测试的功能点无遗漏 2.便于测试工作量的评估 3.便于提前准备测试数据 4.便于把控测试工作进度 5.便于回归测试 6.便于测试工作的组织，提高测试效率，降低测试交接成本
1、UI 测试
2、功能
3、易用性
4、容错性：特殊字符测试
5、性能
6、兼容性测试：IE8/9/10/11 谷歌浏览器 火狐浏览拿起
7、安全
27，测试用例的状态
*排队：*测试用例已经指定给某个测试人，不准备在这一个测试阶段运行。
进行中：该测试正在进行，并且会持续一段时间。
阻塞：一些因素会导致测试不能进行到底，我通常会在测试用例总结工作表的意见栏记录下阻塞的状态。
跳过：你决定在当前测试阶段跳过某个测试，可能是因为它的优先权相对较低。
通过：测试运行结束，测试人得到了预料中的测试结果状态和测试行为。
失败：在很多情况下，测试人得到预料之外的测试结果，状态或行为，这些结果与测试目标相差甚远。这就引发了关于系统质量的疑问。一个或多个测试错误需要记录下来。
警告：在很多情况下，测试人得到预料之外的测试结果，状态或行为，但是这些结果与测试目标差别不是很大，只和延期的或不是一定要改的错误相关的测试可以标记为警告，而不是失败。
关闭：一个测试在第一个循环中被标为失败或警告，第二个测试发布中将第一个测试循环出现的错误修改了。重新运行了整个测试用例后，没有错误出现。将这类测试标记为关闭而不是通过，
28，常见的测试用例设计方法
等价类划分，边界值，错误推测，因果图，场景法，正交表 应用的场景 等价类划分 多用于输入框：注册/登录 边界值（掌握上点和离点的取值） 多和等价类划分结合使用，有边界限制的:注册的密码长度，， 场景法 从基本流开始，再将基本流和备选流结合起来，可以确定用例场景 银行取钱 正交表 用于多个下拉框之间的组合，可以通过正交助手生成测试用例 错误推测 错误猜测法是测试经验丰富的人喜欢使用的一种测试用例设计方法。 一般这种方法是基于经验和直觉推测程序中可能发送的各种错误，有针对性地设计。只能作为一种补充 因果图 因果图法比较适合输条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出 自动贩卖机
29，判定表用在哪些时候/哪些功能
判定表bai方法是黑盒测试方法的一种du，主要zhi用于输入和输dao出比较多，功能zhuan逻辑比较复杂的情况，通过画shu出判定表缕清需求中的功能逻辑，还能确保找到输入的所有组合情况获得更多关于测试的知识，
30，什么时候用到场景法
场景法：通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。
30，什么时候用到场景法
1、现在在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景，而同一事件不同的出发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动的描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使用测试用例更容易理解和执行。
31，测试环境怎么搭建的？
1、搭建测试环境，确定测试目的
测试环境尽可能的模拟真实环境
确保环境无毒
营造独立的测试环境
构建可复用的测试环境
2、安装依赖软件
拿python项目举例
安装python3、pymysql、redis等需要的工具。
导入Django、pymysql、redis等需要的第三方模块
拿Java项目举例
安装JDK、tomcat、数据库等需要的工具。
3、拉取代码
需要知道SVN地址或者Git地址
4、修改配置文件
修改数据库、redis等配置文件的配置信息，修改成测试环境的配置信息
5、编译、打包（python不需要编译直接可以运行，如果是Java、c、 c++需要编译）
6、导入基础数据
建表、导入管理员账号之类的信息，即把sql在测试数据库执行一次
7、启动程序。
32，偶然性问题的处理
一、一定要提交
1、记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。
2、尽力取查找出错误的原因，比如有什么特别的操作，或者一些操作环境等。
3、程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重现，程序员也会了解问题所在
4、无法重现的问题再次出现后可以直接叫程序员来查看问题。
5、对于测试人员来说，没有操作错误这条既然遇到了就是问题。即使真的操作错了，也要推到程序员哪里，既然程序员员犯错误，用户可能会犯同样的错误。错误发生的时候，Tester最大。
33，当我们认为某个地方是bug，但开发认为不是bug，怎么处理？
1 首先，将问题指派给开发人员。
2 然后，要获取判断的依据和标准：
3 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；
4 如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
5 根据用户的一般使用习惯，来确认是否是缺陷；
6 与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；
7 合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。
8 等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。
9仍不确定为BUG在上线前的测试总结中写入这个BUG
34，产品在上线后用户发现bug，这时测试人员应做哪些工作？
评估BUG的严重程度当程度高的时候应立即提示用户下线止损。
测试复现后提交缺陷管理软件，考虑bug的优先级别，再考虑修复的影响范围和难易度，然后出对应得补丁包。 在分析bug的原因，判断是什么因素导致的问题，再前往bug内容对相近的模块和类似的接口处进行复查。出现问题进行风险预防。
当BUG的程度不高为中等时提示用户维护或在下次版本迭代时进行修复进行回归测试
35，二八定理
二八定律是一种社会准则，符合大多数社会现象的规律。同样也适用于互联网领域。
比如一个网站有成千上万的用户，但是80%的用户请求是发生在20%的时间内，比如大家去网上购物，基本也都集中在中午休息或晚上下班后。二八定律的核心原则是关注重要部分，忽略次要部分。系统性能如果能支撑发生在20%时间内的高并发请求，必然也能支持非高峰期的访问。
36，如何跟踪缺陷
发现缺陷-->提交缺陷-->将缺陷指派给开发-->开发确认缺陷-->研发去修复缺陷-->回归测试缺陷-->是否通过验证-->关闭缺陷
37. 缺陷的状态
-
New（新的）：bug提交到缺陷库中会自动的被设置成New状态
-
Assigned（已指派）：当一个bug被认为New之后，将其分配开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”
-
Open（已打开）：开发人员开始处理bug时，他将这个bug的状态设置为“Open”，表示开发人员正在处理这个“bug”
-
Fixed（已修复）：当开发人员进行处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组
-
Rejected(被拒绝)：测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，开发组负责人就将这个bug的状态设置为“Rejected”
-
Postponed（延期）：有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为“Postponed”
-
Closed（已关闭）：测试人员经过再次测试后确认bug已经被解决，将bug的状态设置为“Closed”
-
Reopen（再次打开）：如经过再次测试发现bug仍然存在，测试人员将bug再次开发组，将bug的状态设置为“Reopen”
38. 缺陷的等级
bug缺陷等级一般划分为四个等级，致命、严重、一般、提示
致命（一级bug） **通常表现为:主流程无法跑通，系统无法运行，崩溃或严重资源不足，应用模块无法启动或异常退出，主要功能模块无法使用。
比如：1.内存泄漏；2.严重的数值计算错误；3.系统容易崩溃；4.功能设计与需求严重不符；5.系统无法登陆；6.循坏报错，无法正常退出。
严重（二级bug） 通常表现为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。
比如：1. 功能未实现；2.功能存在报错；3.数值轻微的计算错误。
一般（三级bug）** 通常表现为：界面、性能缺陷。
比如：1.边界条件下错误；2.容错性不好；3.大数据下容易无响应；4.大数据操作时，没有提供进度条。
提示（四级bug） 通常表现为：易用性及建议性问题
比如：1.界面颜色搭配不好；2.文字排列不整齐；3.出现错别字，但是不影响功能；4.界面格式不规范。
39. 缺陷单应该包含这些要素
缺陷标题，缺陷描述，重现步骤，预期结果，实际结果，缺陷优先级，缺陷严重程度，附件
40. 测试报告的主要内容
概述、测试过程、功能实现清单、测试统计、测试总结及测试风险
1. 概述：一般会在概述中添加项目背景、需求描述等信息。
-
测试过程主要包含评审记录、测试范围、测试用例
-
罗列出是否已按本次测试计划实现功能
-
包括资源统计、执行情况、问题统计、问题列表、遗留问题
-
主要总结本次测试测了哪些内容、用例覆盖程度、bug解决程度等，以及最终是否决定通过本次测试。
-
测试风险没有放在测试总结里，而是单独划分为一个模块，可见其重要性。
41，如何定位bug：
1、发现bug，首先要查看bug的详细信息，根据描述初步分析是哪个模块哪段代码的问题
2、检查引发bug的测试环境、测试代码段和测试数据，排除测试人员的误操作导致的程序异常
3、确认测试代码、测试环境和数据都正确后，再进一步分析bug根源。这里就需要看具体的测试业务了，可借助相关的工具进行分析，比如firebug插件等
4、如果产品或业务有相关的日志记录，可通过分析日志来确认bug
5、当测试人员经过一系列的分析，可以基本确认bug产生的原因后，就可以直接找开发提bug了（注意沟通技巧）
6、如果各方面都分析完还不能确认bug的原因，可以找开发一起定位（注意保留bug现场或者可以复现bug场景）
7、确认bug后，提单给开发进行bug跟踪。
问题单上要描述清楚以下信息：
具体的测试时间、测试环境、测试场景、测试的具体业务和功能、使用的测试代码和测试数据、测试执行步骤、测试结果、bug现象（最好截图）、日志记录、预期结果、bug确认相关人员等
8、跟踪bug，等开发人员修复bug后进行回归测试。（关注bug是否完全修复、有没有对其他功能造成影响、有没有引入新的问题）
42，开发没时间修复，如何推进bug的修复：
在测试过程中，不免会遇到开发人员因为一些原因不想修改个别bug的情况。那一般遇到这种问题时，我们该如何去推进开发修改bug呢？
我们先来分析下到底会有哪些原因会导致开发不修改bug
1、 开发与测试对bug的定义理解不一致产生的问题，例如暴力操作、非常规操作出现的问题、问题路径深、服务器返回的数据不规范、竞品同样有的问题、个别机型问题等情况，开发可能会不愿意修改。
2、 工作流程方面的原因，例如开发有更高优先级的任务没有时间修改、上线时间紧急，来不及修改、开发不关注名下的bug、开发认为目前的实现比产品需求好等情况
3、 当然还有个人能力原因，例如找不到好的解决方案、影响范围大、找不到bug原因，没有解决方案、技术实现难，不知道怎么修改等等原因
4、 另外还有一些不可抗力的客观因素，例如系统问题，第三方应用问题等等
我的观点
开发不修改bug有这么多原因，但我们测试推动开发修改bug却只有一个原因~那就是责任。关子少卖，对策拿来~通过一个案例帮你分析解决方案~
小明来也~
小明测试输入法时发现，更换皮肤后，在某鹅应用中调起键盘并转屏，键盘会显示异常，无法正常使用。
提交bug后，开发调研原因，发现输入法并有没有针对转屏做特殊处理，猜测可能是某鹅应用的问题，如果我们做适配改动会比较大。并且这个操作用户不易遇到，并且软件上线在即，所以不太想修改。测试认为转屏属于常用操作，用户一但触发此bug，输入法则无法正常使用，非常影响用户的体验。在测试的坚持下，开发人员为输入法做了些保护，并将问题反馈给该应用，应用负责人答应在下个版本修复。问题很快得到了解决。
分析上述案例，开发不修改bug的原因有四：bug路径较深、上线时间紧急、改动影响范围大、第三方应用问题。我们逐条分析解决方案
1、 针对路径较深的bug，测试在推动开发修复bug时，需要注意以下几点
a) 从用户的角度分析问题的严重性，分析用户的遇到此问题的概率，引导开发站在用户角度去思考，从而使开发意识到问题的严重性
b) 可以和开发人员列举一个之前的类似问题，为开发提供参考
c) 产品是负责这个软件的人员，当测试与开发意见无法达成一致时，不要因为无法推动开发修改而放弃，一定要找产品确认，最终的决定权交给产品人员。
2、 上线时间紧张，开发来不及修改了，这个时候测试应该分析问题的严重性，和产品人员商议是否需要修改
3、 修改bug改动较大，影响范围广，没有最优的解决方案等情况在项目即将上线的节点比较忌讳这种事情的发生。面对这种情况，建议开发人员做调研工作，请教其他的同事，或者组织一个临时会议，集众人之力研究好的修改方案
4、 第三方应用问题，开发无法修改。确认原因之后需要找相关的工作人员，例如产品，联系第三方输入法的工作人员，反馈问题，尽量推动应用解决问题
小结
总之，bug修不修，测试应该有一个自己的原则，同时也要权衡利弊。不能因为推不动开发，就放弃，由着bug上线，也不能揪着一个小bug不放，影响上线时间。推动开发人员修复bug需要技巧，你get了吗？
43，软件测试流程
立项(确定项目)--编写需求(需求人员)--需求评审(编写需求人员发起)--开发编写概要和详细设计(编码并自测[开发环境]) 测试:测试用例-测试用例评审(测试人员发起)--部署环境--冒烟测试(通过)--提交bug--回归测试(测试报告)--验收测试--上线
44，项目介绍
我们一般在项目进行开立项会【产品经理 项目经理 开发人员 测试人员】的时候进行参与， 讨论需求并提出建议，在立项会中制定需求文档，由ui设计原型图，开发根据需求文档进行编码， 我们测试会根据需求文档进行编写 测试计划，根据模块的（颗粒度）划分并编写测试用例以及对用例的评审， 开发结束侯测试对主要功能进行冒烟测试，执行测试用例，提交bug 开发进行修改，修改成功后关闭bug， 进行回归测试，在上线前进行测试总结。
45，对一支圆珠笔进行测试，要从哪些方面进行测试？
1.功能测试： 圆珠笔按下是否能正常书写。
2.性能测试： 笔芯弹出弹回的快慢。
3.负载测试： 连续按，看弹簧能经受多少次伸缩。
4.兼容性测试： 看是否可以使用其他笔芯。
5.强度测试： 用力过度会有什么影响
6.可恢复性测试： 长时间按住弹簧，松开后看弹簧是否可以恢复
7.界面测试： 笔的外观，舒适度
8.安全性测试： 是否会对使用者造成伤害
三角形测试用例设计
在三角形计算中，要求三角形的三个边长：A B C 。
1、 当三边不可能构成三角形时提示错误，可构成三角形时计算三角形周长。
2、若是等腰三角形打印“等腰三角形”， 若两个等腰的平方和等于第三边平方和，则打印“等腰直角三角形”。
3、若是等边三角形，则打印：“等边三角形”。
4、画出程序流程图并设计一个测试用例。
分析一下：
1、构成三角形的条件：任意两边之和大于第三边；
2、构成等腰三角形的条件：任意两边相等；
3、构成等腰直角三角形的条件：任意两边相等，而且两条边的平方和等于第三边的平方和；
4、构成等边三角形的条件：三条边都相等。
那么用什么样的设计方法进行测试用例的设计呢？
一、等价类划分：三角形三条边A、B、C的数据类型不同
二、边界值分析：由于三角形的边长可以是正整数或正小数，所以就不对长度进行测试，那么边界值分析就不用了
三、因果图法：三角形的三条边数据输入组合
我们再分析一下三角形的等价类：
有效等价类：
输入3个正整数或正小数：
1、两数之和大于第三数，如A<B+C；B<C+A；C<A+B
2、两数之和不大于第三数
3、两数相等，如A=B或B=C或C=A
4、三数相等，如A=B=C
5、三数不相等，如A！=B，B！=C，C！=A
无效等价类：
1、空
2、负整数
3、非数字
4、少于三个数
46，在项目中发现哪些经典bug？什么原因导致的？
1.支付后，状态没有同步。
2.金额是不足1元，会显示为小数点前面的0不见了
3.查询功能第二页的内容与第1页的内容完全相同
4.导出为excel文件，内容乱码（后台管理员端会涉及导出）
5.导入：商品上架可以支持导入，导入上千个商品曾发生卡死。（线上Bug）
6.查询订单时，系统提示订单不存在。
7.按钮不起作用，比较容易发生在返回按钮，上一步按钮
8.付款账号和收款账号相同，会导致交易失败
9.存在页面某个数据显示为Null，这个数据没有同步过来。响应中没有这个数据
10.错误信息显示为错误代码，在测试环境比较容易出现。
11.同一个账号显示为不同格式，比较容易出现在手机号的显示。13800138001 138 0013 8001
12.时间的显示格式不正确，没有做出适合中国人的显示格式
13.数据的状态不正确，有一笔订单是已经支付，但在某些地方显示为未支付。
14.偶尔可能出现乱码，只有中文乱码
15.输入框输入过长的内容，也能够提交。
47，一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由。
48，在需求文档不太详细的情况下，如何开展测试？
-
解决用户问题或达到用户目标需要具备的条件或能力
-
遵守合同、协议、规范或其他要求
49，如何尽快找到软件中的bug?
1.尽快熟悉软件的需求和业务，只有熟悉了产品的业务流程、你才能迅速找出软件中存在的一些重要的缺陷 2.把自己当成用户，把自己当成是用户去使用该系统，比如在使用该系统过程中是这样操作的吗？ 3.善于怀疑，不要开发人员的能力 4.不要让程序开发人员的观点：“用户不会进行这样的操作”而说服自己 5.使用完整的流程去测试软件系统，有些子流程在单独测试时没有问题，但按流程走的时候问题就可能出来了。
50，什么是bug？
产品说明书中规定要做的事情，而软件没有实现。 产品说明书中规定不要做的事情，而软件确实现了。 产品说明书中没有提到过的事情，而软件确实现了。 产品说明书中没有提到但是必须要做的事情，软件确没有实现。 软件很难理解，很难使用，速度超慢，测试人员站在最终用户的角度看到的问题是平常的但不是正确的。
注：产品说明书中没有提到但是必须要做的事情，软件确没有实现。软件实现了产品的功能，但是没有考虑软件在弱网络、低电量的情况下也能正常使用，而做出来的产品在弱网络或低电量的情况下报错，那么这也是一个bug。
或者
1.不符合客户确认过的需求 2.已超越客户确认过的需求 3.和用户的交互习惯不一致 4.与用户的界面审美不一致
51，ATM机吞卡的吞卡现象是不是BUG?
不是
是特意设置的安全措施 防止有人马虎，操作后忘记取走银行卡而被人冒领卡中的钱款 所以特意设置了倒计时，限时内没有取走银行卡就会吞卡
52，如何减少非问题单的提交？
53，有个程序，在windows上运行很慢，怎么判断是程序存在问题，还是软硬件系统存在问题？
1、检查系统是否有中度的特征，如：浏览器窗口连续打开，系统中文件图标改成统一图标，CPU使用率保存90%以上等 2、检查软件/硬件的配置是否符合软件的推荐标准 3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务，如：虚拟机运行 4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的； 5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况，
性能监视器打开方法：
一、【开始》运行】输入perfmon，回车 二、右键【计算机》管理】