1，B/S架构和C/S架构区别
B/S架构需要重点考虑系统在不同的浏览器中的兼容性问题(浏览器的内核不同)
C/S 架构需要考虑系统在不同平台的安装、卸载、升级
2，HTTP协议
超文本传输协议，应用层协议，由请求与响应组成。
常见的请求方式有POST/GET,常见的状态码200ok，301永久移动，302临时移动，404找不到资源，500服务器内部错误。
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数据存放在客户的浏览器du上，session数据放在服务器上。
2、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗
考虑到安全应当使用session。
3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能
考虑到减轻服务器性能方面，应当使用COOKIE。
4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
cookie 和session 的联系：
session是通过cookieshu工作的
session和cookie之间是通过$_COOKIE['PHPSESSID']来联系的，通过$_COOKIE['PHPSESSID']可以知道session的id，从而获取到其他的信息。
5，测试的目的
发现软件的缺陷与漏洞，对软件的质量进行评估，提升软件质量。
6，软件测试原则
所有的软件测试都应追溯到用户需求。
尽早地和不断地进行软件测试
完全测试是不可能的，测试需要终止。
充分注意测试中的群集现象。
程序员应避免检查自己的程序。
尽量避免测试的随意性
7，软件测试分为哪几个阶段？
单元测试、集成测试、系统测试、验收测试
8，单元测试与集成测试的侧重点
单元测试是对程序最小可测试的模块进行测试
集成测试是把各个模块连接起来时，穿越模块接口的数据是否会丢失。
9，系统测试范围
功能测试、用户体验测试、性能测试、UI测试、兼容性测试、安装测试、文档测试、稳定性测试等
10，a测试与ß测试的区别
a测试：公司组织的内部人员进行的测试
ß测试：公司组织的典型客户在实际生活中使用。
11，验收测试怎么做？
在UAT测试之前，我们会制定测试方案，选择基线用例，即级别高的用例，在UAT测试环境上进行测试，如果测试通过，验收测试就通过了。
12，白盒、黑盒和灰盒测试区别
白盒测试：对程序的内部结构与算法进行的测试
黑盒测试：不考虑程序的内部结果，只检查程序是否实现了需求的功能
灰盒测试：关注系统接口所实现的功能，是否和需求一致。
13，冒烟测试的目的
检查程序的基本功能是否正常
14，回归测试怎么做？
首先，把bug单对应的用例执行一遍，还要检查有数据交互的模块会不会受影响，有没有引入新的问题；项目上线前，还要把当前版本的重要功能以及冒烟测试的用例都回归一遍，确保重要功能上线后不出问题。
15，全部回归与部分回归的区别？
全量回归：对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止以前没有的问题现在出问题了
部分回归：当开发修复某个bug时，我们需要去检查该bug是否被修复，还需要检查与之相关联的模块是否受到影响。
16，需求分析的目的
澄清需求，提取测试点
17，测试计划的目的
规范软件测试内容、方法和过程
18，什么时候开始写测试计划
需求分析之后
19，由谁来编写测试计划
一般都是由测试经理或者测试组长来编写
20，测试计划的内容
测试项目的背景、测试范围和测试策略、测试环境、测试开始和结束条件、进度安排，测试组织，以及与测试有关的风险等方面的内容。
21，结束条件(项目上线的条件)
需求的覆盖率、用例的执行率和缺陷的遗留率达到质量目标。
通常来说：需求覆盖率和用例执行率需要达到100%
致命/严重的缺陷需要当天解决，轻微/一般遗留率不得超过30%
22，常见的测试风险
进度风险、质量风险和需求变更
23，测试用例的要素
用例编号,用例名称,级别,预置条件,测试步骤,期望结果
24，测试用例级别的划分
一般是依据用户使用该场景的频率，和该功能对系统的影响程度来确定
25，怎样保证覆盖用户需求？
项目开始前，我们会先熟悉需求，画好流程图，保证整个流程都覆盖全面，小组之间每个人都要根据各自的流程图，各个功能点有哪些限制条件，来讲解一下自己对测试点的理解，防止之后编写测试用例时出现遗漏；用例编写完之后，再进行用例的评审，看看测试点有没有用遗漏，对需求理解有没有错误，测试场景是否覆盖完全。
26，写好测试用例的关键 /写好用例要关注的维度
覆盖用户的需求；
从用户使用场景出发，考虑用户的各种正常和异常的使用场景；
用例的颗粒大小要均匀。通常，一个测试用例对应一个场景；
用例各个要素要齐全，步骤应该足够详细，容易被其它测试工程师读懂，并能顺利执行；
做好用例评审，及时更新测试用例。
27，测试用例的状态
No Test 未执行状态
Pass 通过状态
Fail 失败状态
Block 阻碍状态。
Investigate 观察中状态。
28，常见的测试用例设计方法
等价类划分
多用于输入框：注册/登录
边界值
多和等价类划分结合使用，有边界限制的:注册的密码长度（掌握上点和离点的取值）
场景法
从基本流开始，再将基本流和备选流结合起来，可以确定用例场景
正交表
用于多个下拉框之间的组合，可以通过正交助手生成测试用例
错误推测
错误猜测法是测试经验丰富的人喜欢使用的一种测试用例设计方法。一般这种方法是基于经验和直觉推测程序中可能发送的各种错误，有针对性地设计。只能作为一种补充
因果图
因果图法比较适合输条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出
29，判定表用在哪些时候/哪些功能
判定法，是用在不同的输入组合，可能会产生不同的输出这种情况，比如，一个有多个查询条件的查询功能，输入不同的查询条件组合，输出的结果是不一样的，这样的功能就要用到判定表
30，什么时候用到场景法
使用场景法通常是在冒烟测试中或者 一些流程性比较强的软件/功能(比如安装，卸载等等)
32，偶然性问题的处理
发现bug之后，我们会先截图，如果确定是偶然性的问题，会将日志和截图一起提单给开发定位；
如果缺陷在当前版本无法复现，且缺陷的影响程度比较低，可以提交问题单进行跟踪，跟踪三个版本，如果后三个版本都无法复现，就可以关闭该缺陷；
如果是很严重的Bug，比如导致系统崩溃等，并且，实在没有再次出现，除了要及时反馈给上级之外，最后还要写到测试报告中，说明出现了什么现象，但无法再现！
33，当我们认为某个地方是bug，但开发认为不是bug，怎么处理？
先跟开发沟通，确认系统的实际结果是不是和需求有不一致的地方；有些地方可能需求没提及，但是用户体检不好，我们也可以认为是bug。
如果开发以不影响用户使用为理由，拒绝修改，我们可以和产品经理，测试经理等人员进行讨论，确定是否要修改，如果大家都一致认为不用改，就不改。
34，产品在上线后用户发现bug，这时测试人员应做哪些工作？
测试人员复现问题后，提交问题单进行跟踪；
评估该问题的严重程度，以及修复问题时的影响范围，回归测试需要测试哪些功能；
问题修复后，先在测试环境上回归，通过后再在生产环境上打补丁，然后再进行回归测试；
总结经验，分析问题发生的原因，避免下次出现同样问题。
35，二八定理
80%的缺陷出现在 20%的模块。
36，如何跟踪缺陷
发现缺陷-->提交缺陷-->将缺陷指派给开发-->开发确认缺陷-->研发去修复缺陷-->回归测试缺陷-->是否通过验证-->关闭缺陷
37，缺陷的状态
激活,确认,已解决,关闭
38，缺陷的等级
致命,严重,一般,轻微
39，缺陷单应该包含这些要素
缺陷标题，严重级别，问题所属模块，复现步骤，预期结果，实际结果，有关的日志和截图。
40，测试报告的主要内容
人力投入，用例统计，问题单分类统计，遗留bug情况，测试风险，测试对象评估，测试结论
41，如何定位bug：
检查测试环境配置是否有问题，测试数据是否有问题
用fiddler抓包，分析请求和响应数据是否存在问题
查看应用服务器的日志
然后再查看数据库的数据是否存在问题
42，开发没时间修复，如何推进bug的修复：
和开发说明该问题的严重性，会怎样影响产品的正常使用，如何还是坚持不改，就上报领导，让领导辅助推进；
确认问题的严重程度，如果影响不大，不是非要改的bug，并且修复风险比较大，和领导商量后，如果认为暂时可以不用修复，也可以不修复。
43，软件测试流程
我们这个项目是两个人负责测试的，按模块进行分工，我负责xxx模块。项目启动后，我们会到服务器上下载相关的需求文档，熟悉项目的流程，进行需求澄清，提取测试点；然后编写测试用例，再进行组内的评审，修改，定稿；在开发阶段，开发人员写完一个接口，我们就测试一个接口；等开发转测后，我们从svn上获取安装包，搭建测试环境；之后我们开始进行冒烟测试，冒烟通过后，我们就进入SIT测试，之后进行UAT用户验收测试，验收通过后，编写测试报告。
44，项目介绍
我就说一下最近的一个项目，是集书芸管理系统，主要是一款基于B/S架构的电商分销管理系统，前台模块有店铺首页，购物车，会员中心，申请分销等，后台模块有店铺管理，书籍管理，订单管理，分销管理等，在后台可以上架新的商品，设置店铺活动，管理订单等，用户可以在前台注册成为会员，然后登陆系统，搜索上架的商品，将商品加入购物车之后进行结算下单，或者直接进行结算下单，下单后在用户的‘我的订单’能看到该订单信息，订单状态为待付款，在系统后台的订单管理列表也能看到该订单的信息，买家付款后，订单状态为待发货状态 ，卖家就可以进行发货，买家收到产品后进行确认，评论，整个购物的流程就结束了。这就是我这个项目的大概情况。
45，对一支圆珠笔进行测试，要从哪些方面进行测试？三角形测试用例设计
1.功能测试：
圆珠笔按下是否能正常书写。
2.性能测试：
笔芯弹出弹回的快慢。
3.负载测试：
连续按，看弹簧能经受多少次伸缩。
4.兼容性测试：
看是否可以使用其他笔芯。
5.强度测试：
用力过度会有什么影响
6.可恢复性测试：
长时间按住弹簧，松开后看弹簧是否可以恢复
7.界面测试：
笔的外观，舒适度
8.安全性测试：
是否会对使用者造成伤害
46，在项目中发现哪些经典bug？什么原因导致的？
1、 当三边不可能构成三角形时提示错误，可构成三角形时计算三角形周长。
2、若是等腰三角形打印“等腰三角形”， 若两个等腰的平方和等于第三边平方和，则打印“等腰直角三角形”。
3、若是等边三角形，则打印：“等边三角形”。
4、画出程序流程图并设计一个测试用例。
分析一下：
1、构成三角形的条件：任意两边之和大于第三边；
2、构成等腰三角形的条件：任意两边相等；
3、构成等腰直角三角形的条件：任意两边相等，而且两条边的平方和等于第三边的平方和；
4、构成等边三角形的条件：三条边都相等。
那么用什么样的设计方法进行测试用例的设计呢？
一、等价类划分：三角形三条边A、B、C的数据类型不同
二、边界值分析：由于三角形的边长可以是正整数或正小数，所以就不对长度进行测试，那么边界值分析就不用了
三、因果图法：三角形的三条边数据输入组合
我们再分析一下三角形的等价类：
有效等价类：
47，一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由。
测试时的测试结果不为开发规定的5%可出现的BUG内也不属于严重程度较低的缺陷通过需求文档订立的测试用例不相符合所以认为他是BUG
48，在需求文档不太详细的情况下，如何开展测
试？
根据开发人员的编码进行功能测试 性能测试 冒烟测试 单元测试 集成测试 系统测试 兼容测试 安全测试 和易用性测试等
49，如何尽快找到软件中的bug?
-
解决用户问题或达到用户目标需要具备的条件或能力
-
遵守合同、协议、规范或其他要求
50，什么是bug？
1.尽快熟悉软件的需求和业务，只有熟悉了产品的业务流程、你才能迅速找出软件中存在的一些重要的缺陷
2.把自己当成用户，把自己当成是用户去使用该系统，比如在使用该系统过程中是这样操作的吗？
3.善于怀疑，不要开发人员的能力
4.不要让程序开发人员的观点：“用户不会进行这样的操作”而说服自己
5.使用完整的流程去测试软件系统，有些子流程在单独测试时没有问题，但按流程走的时候问题就可能出来了。
51，ATM机吞卡的吞卡现象是不是BUG?
需要看是什么情况下吞卡。如：输入三次密码错误吞卡是正常的，不属于BUG；若输入一次密码错误吞卡则是不正常的，属于BUG。
52，如何减少非问题单的提交？
熟悉项目需求，充分了解各个各个功能模块的功能、参数、约束条件，弄清存在数据交互的模块之间的数据来源、数据流向；
跟产品确认该问题是否属于非问题单。
53，有个程序，在windows上运行很慢，怎么判断是程序存在问题，还是软硬件系统存在问题？
1、检查系统是否有中度的特征，如：浏览器窗口连续打开，系统中文件图标改成统一图标，CPU使用率保存90%以上等
2、检查软件/硬件的配置是否符合软件的推荐标准
3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务，如：虚拟机运行
4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；
5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况，
性能监视器打开方法：
一、【开始》运行】输入perfmon，回车
二、右键【计算机》管理】
54，你们发现bug会怎么处理。
发现bug后，我们会先自己定位一下，比如，抓个包，看看是前端的问题，还是后端的问题，检查下数据库的数据是不是正确的，尽量把问题发生的原因或者产生的日志找出来，方便开发定位问题，然后就提单给开发，然后开发做出相应的处理，开发修复完后就进行回归测试，回归测试通过后就关闭这个bug，没有通过就继续给回开发修复。如果遇到开发认为这个不是bug的话，那么我们就要和开发沟通，然后我们要坚持自己的立场，通过讨论后一致认为是bug就给开发修复，不是就关闭这个bug。如果开发和我们意见一直不一致，那么就要将问题升级，召集开发经理和测试经理一起讨论，再做决定。