B/S架构和C/S架构区别
B/S架构需要重点考虑系统在不同的浏览器中的兼容性问题(浏览器的内核不同)
C/S 架构需要考虑系统在不同平台的安装、卸载、升级
HTTP协议
超文本传输协议，应用层协议，由请求与响应组成。
常见的请求方式有POST/GET,常见的状态码200ok，301永久移动，302临时移动，404找不到资源，500服务器内部错误。
POST与GET区别
get:没有请求体，通过url携带数据、大小有限制，不安全、
post：通过请求体传输数据，大小没有限制，安全
Cookie和Session的区别与联系
1、Cookie和Session都是会话技术，Cookie是运行在客户端，Session是运行在服务器端。
2、Cookie有大小限制以及浏览器在存cookie的个数也有限制，Session是没有大小限制和服务器的内存大小有关。
3、Cookie有安全隐患，通过拦截或本地文件找得到你的cookie后可以进行攻击。
4、Session是保存在服务器端上会存在一段时间才会消失，如果session过多会增加服务器的压力。
测试的目的
发现软件的缺陷与漏洞，对软件的质量进行评估，提升软件质量。
软件测试原则
所有的软件测试都应追溯到用户需求。
尽早地和不断地进行软件测试
完全测试是不可能的，测试需要终止。
充分注意测试中的群集现象。
程序员应避免检查自己的程序。
尽量避免测试的随意性
软件测试分为哪几个阶段
单元测试：按模块划分后的颗粒度进行分类测试
集成测试：功能模块的测试
系统测试：多个模块合成测试
验收测试：客户以及产品经理进行
单元测试与集成测试的侧重点
单元测试是对程序最小可测试的模块进行测试
集成测试是把各个模块连接起来时，穿越模块接口的数据是否会丢失。
系统测试范围
功能测试、用户体验测试、性能测试、UI测试、兼容性测试、安装测试、文档测试、稳定性测试等
a测试与ß测试的区别
a测试：公司组织的内部人员进行的测试
ß测试：公司组织的典型客户在实际生活中使用。
验收测试怎么做
在UAT测试之前，我们会制定测试方案，选择基线用例，即级别高的用例，在UAT测试环境上进行测试，如果测试通过，验收测试就通过了。
白盒、黑盒和灰盒测试区别
白盒测试：对程序的内部结构与算法进行的测试
黑盒测试：不考虑程序的内部结果，只检查程序是否实现了需求的功能
灰盒测试：关注系统接口所实现的功能，是否和需求一致。
冒烟测试的目的
为正式测试前，验证是否产品或系统的主要需求或预置条件是否存在bug。
回归测试怎么做？
首先，把bug单对应的用例执行一遍，还要检查有数据交互的模块会不会受影响，有没有引入新的问题；项目上线前，还要把当前版本的重要功能以及冒烟测试的用例都回归一遍，确保重要功能上线后不出问题。
全部回归与部分回归的区别？
全量回归：对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止以前没有的问题现在出问题了
部分回归：当开发修复某个bug时，我们需要去检查该bug是否被修复，还需要检查与之相关联的模块是否受到影响。
需求分析的目的
澄清需求，提取测试点
测试计划的目的
规范软件测试内容、方法和过程
什么时候开始写测试计划
由谁来编写测试计划
一般都是由测试经理或者测试组长来编写
测试计划的内容
测试项目的背景、测试范围和测试策略、测试环境、测试开始和结束条件、进度安排，测试组织，以及与测试有关的风险等方面的内容
结束条件(项目上线的条件)
需求的覆盖率、用例的执行率和缺陷的遗留率达到质量目标。
通常来说：需求覆盖率和用例执行率需要达到100%
致命/严重的缺陷需要当天解决，轻微/一般遗留率不得超过30%
常见的测试风险
进度风险、质量风险和需求变更
测试用例的要素
用例编号 用例描述 执行条件 预期结果 测试输入 实际结果
测试用例级别的划分
高，中，低
怎样保证覆盖用户需求？
分类：一次告知类，个人喜好，不合理需求类，合理需求类
拓展关键词
写好测试用例的关键 /写好用例要关注的维度
覆盖用户的需求；
从用户使用场景出发，考虑用户的各种正常和异常的使用场景；
用例的颗粒大小要均匀。通常，一个测试用例对应一个场景；
用例各个要素要齐全，步骤应该足够详细，容易被其它测试工程师读懂，并能顺利执行；
做好用例评审，及时更新测试用例。
测试用例的状态
排队（In Queue）：
测试用例已经指定给某个测试人，不准备在这一个测试阶段运行。
进行中（IP）：
该测试正在进行，并且会持续一段时间。（如果一个测试所需要的时间少于一天，我就不会讲一个测试标为进行中，因为我每天会跟踪测试用例的状态）
阻塞（Block）：
一些因素会导致测试不能进行到底，例如某个功能欠缺或者测试环境的某个部分欠缺。我通常会在测试用例总结工作表的意见栏记录下阻塞的状态。你可以把阻塞理解为：我希望运行测试，但是目前还不能运行测试。
跳过（Skip）：
你决定在当前测试阶段跳过某个测试，可能是因为它的优先权相对较低。（同样地，我会在测试用例总结工作表的意见栏记录下我跳过这个测试的原因。）你可以把跳过理解为：我现在可以运行这个测试，但是我不想运行它。
通过（Pass）：
测试运行结束，测试人得到了预料中的测试结果状态和测试行为。
失败（Fail）：
在很多情况下，测试人得到预料之外的测试结果，状态或行为，这些结果与测试目标相差甚远。这就引发了关于系统质量的疑问。一个或多个测试错误需要记录下来。
警告（Warn）：
在很多情况下，测试人得到预料之外的测试结果，状态或行为，但是这些结果与测试目标差别不是很大（我通常会在测试包总结工作表的通过一栏记为警告，而不是另加一栏）。另一种想法是，警告意味着当前的错误是无关紧要的，或者对正在测试的特征是没有意义的。系统报出了更多的错。我处理这个问题的一个标准是只和延期的或不是一定要改的错误相关的测试可以标记为警告，而不是失败。
关闭（Close）：
一个测试在第一个循环中被标为失败或警告，第二个测试发布中将第一个测试循环出现的错误修改了。重新运行了整个测试用例后，没有错误出现。将这类测试标记为关闭而不是通过，使得你可以跟踪测试在某一个测试发布中失败的实事（同标记为警告的测试一样，我在测试包总结工作表中将标记为关闭的测试也纳入成功的范畴）。
常见的测试用例设计方法
等价类划分法，边界值分析法，错误推测法，因果图法，正交实验法，场景法
判定表用在哪些时候/哪些功能
判定法，是用在不同的输入组合，可能会产生不同的输出这种情况，比如，一个有多个查询条件的查询功能，输入不同的查询条件组合，输出的结果是不一样的，这样的功能就要用到判定表
什么时候用到场景法
使用场景法通常是在冒烟测试中或者 一些流程性比较强的软件/功能(比如安装，卸载等等)
测试环境怎么搭建的？
搭建环境前，开发都会给到我们一份系统发布手册，我们会根据这个手册来搭建。比如，我这个xx系统，是搭建在Unix系统下的，web服务器用的是Tomcat8，MySQL版本是5.7，程序是JAVA编写的，首先我们向开发拿到编译好的安装包，然后用xshell(或CRT)远程连接上Unix系统，把tomcat服务器停掉，把程序包放到webapps目录下，然后再启动tomcat服务器就可以了
偶然性问题的处理
发现bug之后，我们会先截图，如果确定是偶然性的问题，会将日志和截图一起提单给开发定位；
如果缺陷在当前版本无法复现，且缺陷的影响程度比较低，可以提交问题单进行跟踪，跟踪三个版本，如果后三个版本都无法复现，就可以关闭该缺陷；
如果是很严重的Bug，比如导致系统崩溃等，并且，实在没有再次出现，除了要及时反馈给上级之外，最后还要写到测试报告中，说明出现了什么现象，但无法再现！
当我们认为某个地方是bug，但开发认为不是bug，怎么处理？
1.找到需求文档或者是原型图进行匹对
2.尝试多种测试环境和多种测试方式来确认是否为bug
3.整理bug的复现的步骤和出现的频率
4.开发坚持不认为是bug的时候找项目经理测试经理进行沟通来确认是否为bug
5.将客户经理 测试 测试经理和项目经理进行开确认会来判定是否为bug
6.测试人员需要将bug整理并写入测试总结中
产品在上线后用户发现bug，这时测试人员应做哪些工作？
测试人员复现问题后，提交问题单进行跟踪；
评估该问题的严重程度，以及修复问题时的影响范围，回归测试需要测试哪些功能；
问题修复后，先在测试环境上回归，通过后再在生产环境上打补丁，然后再进行回归测试；
总结经验，分析问题发生的原因，避免下次出现同样问题。
二八定理
80%的缺陷出现在 20%的模块。
如何跟踪缺陷
首先，圈定该系统的应用范围，是单一的项目，是一个部门，还是多个组。 其次，商定跟踪模型，这是核心所在。这一步需要和项目成员一起讨论确定一个大家都接受的模型，包括设计变更的生命周期等一系列定义。接下来要设定一些角色，比如提出者，管理者，质量保证工程师或测试人员等。然后需要制定一个执行计划；再下来部署该缺陷跟踪系统，一个原则是尽量少的对系统进行修正；最后确保该系统正常运转，达到最初的目标。
缺陷的状态
新建，已修复，关闭，重新打开，推迟，不能复现，重复，不是缺陷
缺陷的等级
分别为：致命的(Fatal)，严重的(Critical)，一般的(Major)，微小的(Minor)。
A类—致命的软件缺陷(Fatal):造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。如代码错误，死循环，数据库发生死锁、与数据库连接错误或数据通讯错误，未考虑异常操作，功能错误等
B类—严重错误的软件缺陷（critical）：系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。问题局限在本模块，导致模块功能失效或异常退出。如致命的错误声明，程序接口错误，数据库的表、业务规则、缺省值未加完整性等约束条件
C类—一般错误的软件缺陷（major）：次要功能没有完全实现但不影响使用。如提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等，打印内容、格式错误，删除操作未给出提示，数据库表中有过多的空字段等
D类—较小错误的软件缺陷（Minor）:使操作者不方便或遇到麻烦，但它不影响功能过的操作和执行，如错别字、界面不规范（字体大小不统一，文字排列不整齐，可输入区域和只读区域没有明显的区分标志），辅助说明描述不清楚
E类- 建议问题的软件缺陷（Enhancemental）：由问题提出人对测试对象的改进意见或测试人员提出的建议、质疑。
常用的软件缺陷的优先级表示方法可分为：立即解决P1、高优先级P2、正常排队P3、低优先级P4。立即解决是指缺陷导致系统几乎不能使用或者测试不能继续，需立即修复；高优先级是指缺陷严重影响测试，需要优先考虑；正常排队是指缺陷需要正常排队等待修复；而低优先级是指缺陷可以在开发人员有时间的时候再被纠正。
缺陷单应该包含这些要素
软件缺bai陷报告单的意义是测试人员将发现du的BUG以书面的形式zhi提交给开发人员，作为定dao位缺陷的依据（zhuan明确职责，避免口角的方法之一），也作为日后缺陷度量的数据依据。之后，开发人员会依据缺陷报告但重现缺陷进行修改。
缺陷报告单就是由一个个附带多种属性的bug组成的。软件缺陷的相关属性一般有这些：1缺陷发现人 2缺陷发现时间 3缺陷状态 4缺陷的严重程度 5缺陷所属软件的版本 6缺陷修改时间
测试报告的主要内容
人力投入，用例统计，问题单分类统计，遗留bug情况，测试风险，测试对象评估，测试结论
如何定位bug：
检查测试环境配置是否有问题，测试数据是否有问题
用fiddler抓包，分析请求和响应数据是否存在问题
查看应用服务器的日志
然后再查看数据库的数据是否存在问题
开发没时间修复，如何推进bug的修复：
和开发说明该问题的严重性，会怎样影响产品的正常使用，如何还是坚持不改，就上报领导，让领导辅助推进；
确认问题的严重程度，如果影响不大，不是非要改的bug，并且修复风险比较大，和领导商量后，如果认为暂时可以不用修复，也可以不修复。
软件测试流程
我们这个项目是两个人负责测试的，按模块进行分工，我负责xxx模块。项目启动后，我们会到服务器上下载相关的需求文档，熟悉项目的流程，进行需求澄清，提取测试点；然后编写测试用例，再进行组内的评审，修改，定稿；在开发阶段，开发人员写完一个接口，我们就测试一个接口；等开发转测后，我们从svn上获取安装包，搭建测试环境；之后我们开始进行冒烟测试，冒烟通过后，我们就进入SIT测试，之后进行UAT用户验收测试，验收通过后，编写测试报告。
项目介绍：
参考思路：项目叫什么名字，什么架构，有哪些模块，用来干什么的，主要的操作流程
参考：我就说一下最近的一个项目，是集书芸管理系统，主要是一款基于B/S架构的电商分销管理系统，前台模块有店铺首页，购物车，会员中心，申请分销等，后台模块有店铺管理，书籍管理，订单管理，分销管理等，在后台可以上架新的商品，设置店铺活动，管理订单等，用户可以在前台注册成为会员，然后登陆系统，搜索上架的商品，将商品加入购物车之后进行结算下单，或者直接进行结算下单，下单后在用户的‘我的订单’能看到该订单信息，订单状态为待付款，在系统后台的订单管理列表也能看到该订单的信息，买家付款后，订单状态为待发货状态 ，卖家就可以进行发货，买家收到产品后进行确认，评论，整个购物的流程就结束了。这就是我这个项目的大概情况。
对一支圆珠笔进行测试，要从哪些方面进行测试？
1.功能测试：
圆珠笔按下是否能正常书写。
2.性能测试：
笔芯弹出弹回的快慢。
3.负载测试：
连续按，看弹簧能经受多少次伸缩。
4.兼容性测试：
看是否可以使用其他笔芯。
5.强度测试：
用力过度会有什么影响
6.可恢复性测试：
长时间按住弹簧，松开后看弹簧是否可以恢复
7.界面测试：
笔的外观，舒适度
8.安全性测试：
是否会对使用者造成伤害
三角形测试用例设计
1、 当三边不可能构成三角形时提示错误，可构成三角形时计算三角形周长。
2、若是等腰三角形打印“等腰三角形”，若两个等腰的平方和等于第三边平方和，则打印“等腰直角三角形”。
3、若是等边三角形，则打印：“等边三角形”。
4、画出程序流程图并设计一个测试用例。
1、构成三角形的条件：任意两边之和大于第三边；
2、构成等腰三角形的条件：任意两边相等；
3、构成等腰直角三角形的条件：任意两边相等，而且两条边的平方和等于第三边的平方和；
4、构成等边三角形的条件：三条边都相等。
在项目中发现哪些经典bug？什么原因导致的？
第一，出现这个bug,可以判断研发在最后保存数据时,并没有对数据的有效性进行判断,而是在相关控件进行操作时进行判断的.这样风险有点大,因为控件之间对数据也会有影响,如果仅在操作控件时判断，会产生问题.
第二，这种脏数据虽然不会在视图展示，但保存在服务器上,在各个平台上均会进行同步.这还需要保证其他平台对于脏数据进行处理，且不会出现问题.风险较大.
基于这两个原因，研发还是解决了这个问题.这对我还是有一定启发的.
看问题可能会更考虑多方面的影响.不单纯只是现象.
一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由。
测试是对软件的质量进行的把关，如果一个项目仍然有很多的缺陷未被修复，那么从质量的角度上我们会认为这个软件质量是不达标的，一般来说缺陷的遗留，是不允许严重、致命bug的遗留，轻微和一般的bug遗留率不超过30%。
在需求文档不太详细的情况下，如何开展测试？
首先，把需求文档中有异议的部分标识出来，再找产品和开发一起讨论，把需求明确下来；
提取测试点，然后再叫上产品和开发一起对测试点进行讨论，看有没有遗漏，是不是合理的，
然后再编写测试用例，再评审，评审通过后，再进行后续的测试。
如何尽快找到软件中的bug：
尽快熟悉公司的产品业务，只有熟悉了产品的业务流程、你才能迅速找出软件中存在的一些重要的缺陷；
把自己当成用户，把自己当成是用户去使用该系统
善于怀疑，不要过于相信开发人员的能力；
什么是bug：
软件未实现需求和规格要求的功能 ；
软件未实现需求和规格未明确提及但应该实现的内容 ；
软件难以理解，不易使用，运行缓慢，或者最终用户(估计会)认为不好；
测试用例执行中发现的与预期结果不符的现象
ATM机吞卡的吞卡现象是不是BUG?
不一定，看是什么情况下吞卡。如：输入三次密码错误吞卡是正常的，不属于BUG；若输入一次密码错误吞卡则是不正常的，属于BUG。
如何减少非问题单的提交？
熟悉项目需求，充分了解各个各个功能模块的功能、参数、约束条件，弄清存在数据交互的模块之间的数据来源、数据流向；
跟产品确认该问题是否属于非问题单。
有个程序，在windows上运行很慢，怎么判断是程序存在问题，还是软硬件系统存在问题？
将程序放在其他的windows上运行，如果运行的还是很慢则是程序的问题。
你们发现bug会怎么处理。
发现bug后，我们会先自己定位一下，比如，抓个包，看看是前端的问题，还是后端的问题，检查下数据库的数据是不是正确的，尽量把问题发生的原因或者产生的日志找出来，方便开发定位问题，然后就提单给开发，然后开发做出相应的处理，开发修复完后就进行回归测试，回归测试通过后就关闭这个bug，没有通过就继续给回开发修复。如果遇到开发认为这个不是bug的话，那么我们就要和开发沟通，然后我们要坚持自己的立场，通过讨论后一致认为是bug就给开发修复，不是就关闭这个bug。如果开发和我们意见一直不一致，那么就要将问题升级，召集开发经理和测试经理一起讨论，再做决定。
