CS响应速度快，安全性强，用户体验好，一般应用于局域网中，但是开发维护成本高，；BS可以实现跨平台，客户端零维护，但是个性化能力低，响应速度较慢。所以有些单位日常办公应用BS，在实际生产中使用CS结构

HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据

1、GET使用URL或Cookie传参。而POST将数据放在BODY中。
2、GET的URL会有长度上的限制，2kb，则POST的数据则可以非常大。
3、POST比GET安全，因为数据在地址栏上不可见。
4、一般get请求用来获取数据，post请求用来发送数据

Session和Cookie的主要区别在于：
Cookie是把数据保存在浏览器端的内存中
Session把数据保存在服务器端的内存中
cookie与session的联系：
当服务器端生成一个session时就会向客户端发送一个cookie保存在客户端，这个cookie保存的是session的sessionId。。这样才能保证客户端发起请求后客户端已经登录的用户能够与服务器端成千上万的session中准确匹配到已经保存了该用户信息的session，同时也能够确保不同页面之间传值时的正确匹配。

1.软件测试的目的是为了保证软件产品的最终质量，在软件开发的过程中，对软件产品进行质量控制。一般来说软件测试应由独立的产品评测中心负责，严格按照软件测试流程，制定测试计划、测试方案、测试规范，实施测试，对测试记录进行分析，并根据回归测试情况撰写测试报告。测试是为了证明程序有错，而不能保证程序没有错误。

所有测试bai的标准du都是建立在用户需求之上zhi的，测试的目的在于dao发现系统是否满足规定的需zhuan求；

“尽早地和不断地测试”，越早进行测试，缺陷的修复成本就会越低；

程序员应避免检查自己的程序，由第三方进行测试更客观有效；

穷举测试是不可能的；

充分注意测试中的群集现象，一段程序中一发现的错误数越多，其中存在的错误概率越大，因此对发现错误较多的程序段，应进行更深入的测试；

设计测试用例时应包括合理输入和不合理输入，以及各种边界条件、特殊情况下要制造极端状态和意外状态；

注意回归测试的关联性，往往修改一个错误会引起更多错误；

测试应从“小规模”开始，逐步转向“大规模”；

测试用例式设计出来，不是写出来的，应根据测试的目的，采用相应的方法设计测试用例，从而提高测试的效率，更多的发现错误，提高程序的可靠性；

重视并妥善保存一切测试过程文档（测试计划，测试用例，测试报告等）；
对测试错误结果一定要有一个确认的过程

单元测试、集成测试、系统测试、验收测试、回归测试

单元测试是在软件 bai 开发过程 du 中要进行的最低级别的 zhi 测试活动，在单元 dao 测试活动中，软件 zhuan 的独立单元将在与 shu 程序的其他部分相隔离的情况下进行测试，测试重点是系统的模块，包括子程序的正确性验证等。

集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求，组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。测试重点是模块间的衔接以及参数的传递等。

黑盒测试。不接触代码，只对整个系统做功能的测试和性能的测试。

用户验收测试是软件开发结束后，用户对软件产品投入实际应用以前进行的最后一次质量检验活动。它要回答开发的软件产品是否符合预期的各项要求，以及用户能否接受的问题。

用户验收测试可以分为两个大的部分：软件配置审核和可执行程序测试，其大致顺序可分为：文档审核、源代码审核、配置脚本审核、测试程序或脚本审核、可执行程序测试。

由于验收测试不只是检验软件某个方面的质量，而是要进行全面的质量检验，并且要决定软件是否合格，因此验收测试是一项严格的正式测试活动。需要根据事先制订的计划，进行软件配置评审、功能测试、性能测试等多方面检测

白箱测试或白盒测试(White-box testing 或 glass-box testing)是通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代码在算法，溢出，路径，条件等等中的缺点或者错误，进而加以修正。

黑箱测试或黑盒测试(Black-box testing)是通过使用整个软件或某种软件功能来严格地测试, 而并没有通过检查程序的源代码或者很清楚地了解该软件或某种软件功能的源代码程序具体是怎样设计的。测试人员通过输入他们的数据然后看输出的结果从而了解软件怎样工作。通常测试人员在进行测试时不仅使用肯定出正确结果的输入数据，而且还会使用有挑战性的输入数据以及可能结果会出错的输入数据以便了解软件怎样处理各种类型的数据。

灰箱测试或灰盒测试(Gray-box testing):灰箱测试就像黑箱测试一样是通过用户界面测试，但是测试人员已经有所了解该软件或某种软件功能的源代码程序具体是怎样设计的。甚至于还读过部分源代码。 因此测试人员可以有的放矢地进行某种确定的条件/功能的测试。这样做的意义在于:如果你知道产品内部的设计和对产品有透过用户界面的深入了解，你就能够更有效和深入地从用户界面来测试它的各项性能。

冒烟测试是为了在运行性能测试或压力测试之前，确保一切都已正确配置并可按预期运行

1、在测试策略制定阶段，制定回归测试策略
2、确定需要回归测试的版本
3、回归测试版本发布,按照回归测试策略执行回归测试
4、回归测试通过，关闭缺陷跟踪单（问题单）
5、回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试

第一、把用户需求转化为功能需求：
1）对测试范围进度量  
 2）对处理分支进行度量  
 3）对需求业务的场景进行度量  
 4）明确其功能对应的输入、处理和输出  
 5）把隐式需求转变为明确。

第二、明确测试活动的五个要素：测试需求是什么、决定怎么测试、明确测试时间、确定测试人员、确定测试环境：测试中需要的技能，工具以及相应的背景知识，测试过程中可能遇到的风险等等。测试需求需要做到尽可能的详细明确，以避免测试遗漏和误解。

1、测试的目的是为 bai 了发现尽可能多的缺陷，不是 du 为了说明软件中没有缺陷。
2、成功的测试在于发现了迄今尚未发现的缺陷。所以测试人员的职责是设计这样的测试用例，它能有效地揭示潜伏在软件里的缺陷。

有了详细的产品需求说明书后，在系统设计阶段就应该写系统测试方案，系统测试计划并开始详细设计测试用例了。

1.项目经理
项目经理当然是从整个项目角度出发，编写整体项目计划，那么其中就包括测试的计划了，他依赖于对应的开发计划，也就是首先要有开发计划、提测计划，再评估测试计划，最终得出上线时间

2.测试经理
测试经理主要是从测试组角度出发，编写项目的测试计划，重点就是项目的任务拆分、合理的安排人力资源、预估时间和风险等

3.测试人员
测试同学本人收到测试经理同步过来的具体分工后，也需要编写自己的测试计划，重点就是详细的说明自己的时间规划、每一个测试任务的前期准备以及开始和结束测试的时间等

 测试背景
测试目的
确定测试范围
制定测试策略（功能测试/业务测试..）
测试资源安排
测试时间安排
测试人员分配
风险评估

1、需求风险

产品需求的不明确，对产品需求理解不准确，导致测试范围存在误差，遗漏部分需求或者执行了错误的测试方式；另外需求变更导致测试用例变更，测试用例维护成本增加，实时更新时存在误差。

2、测试用例风险

测试用例设计不完整，忽视了边界条件、异常输入等情况，用例覆盖率没有做到足够覆盖，测试用例没有得到全部执行，有些用例被有意或者无意的漏测，需求变更导致的测试时间被压缩等情况。

3、缺陷风险

某些缺陷偶发，难以重现，容易被遗漏；缺陷跟踪不够积极主动，没做好缺陷记录和及时更新，同样的缺陷，导致的原因可能不同，对这点没意识到导致的线上生产问题等。

4、代码质量风险

代码质量差，可读性差，重构性差，没做好注释等原因导致缺陷较多，修改难度增大；另外还有系统架构设计的不足，导致的扩展性不足，性能兼容差等问题。

5、测试环境风险

测试环境和生产环境配置不同，测试环境交叉影响较大，测试环境数据量不足导致的测试结果误差等问题。

6、测试技术风险

某些项目存在技术难度，测试能力和经验所限，技术水平相对较差导致测试进展缓慢，测试结果准确性不够，项目发布日期延期等问题。

7、回归测试风险

回归测试，一般时间相对来说较少，且大多只回归主要的功能点用例，可能造成漏测；另外还有回归验证缺陷时业务流走不通导致的打回修复再验证造成的时间延后问题。

8、沟通协调风险
项目进行过程中需要多方沟通协调，不同部门，岗位之间的沟通、协作，难免存在误解、沟通不畅的情况，比如需求变更没有及时沟通，开发代码提交没有及时告知，测试结果的反馈不及时等问题。

9、研发流程风险

其中包括从产品需求评审、研发设计、代码提交、测试发布等一些列流程，流程的不规范不协调很可能导致很多问题；比如开发在不告知其他成员的情况下提交代码，发布没有预生产环境，生产出现

问题无法及时回滚等很多说烂了的情况。流程没必要一板一眼的执行，但没有流程是万万不行的。

10、其它不可预计风险
一些突发状况、不可抗力等也构成风险因素，且难以预估和避免。对于这种情况，往往一时无法解决，建议做好备份方案和容灾机制，或者采用灰度发布等措施。

PS:以上是测试过程中可能发生的风险及原因，其中有的风险是难以避免的，如缺陷风险；有的风险从理论上可以避免，如需求风险，沟通风险等；还有些风险在实际操作过程中出于时间和成本的考虑，

也难以完全回避，如回归测试风险等。
对于这些风险的存在，要尽量避免，也要做好备份方案和容灾机制，规范流程，明确职责，尽可能将风险降到可接受范围内。。。

用例编号，所属模块，用例描述，前置条件，优先级，输入数据，操作步骤，预期结果，实际结果，测试人员，测试时间

高（Highs）：保证功能性是稳定的，是按照需求的正常使用和实现点进行用例设计的，重要的错误和边界测试的测试用例的集合。

中（Mediums）：更全面的验证功能的各方面，包括流程中的各个节点出错情况、异常情况测试、中断、UI 展示、用户体验等方面的测试用例设计

低（Lows）：不常被执行的测试用例。比如压力和性能测试用例设计，接口测试用例设计随着时间的推移已经从低级别变化到了中级别。

首先，确认需求

面试官简单描述这道题后，你是否真的已经了解了他的需求呢，如上描述，需求范围过于笼统，也就是要明确用户故事。请问这个需求是怎样的项目背景或基于什么前提下而做的；会涉及到哪些支撑平台；具体需要怎样的权限可以上传操作；该功能的迭代会影响到哪些其他的存量功能等，是否有明确的性能需求等

第二，梳理需求，确认测试范围
是否需要考虑历史数据，数据来源，用户角色，支持哪些操作系统，兼容性要求（考虑平台兼容性、浏览器兼容性、手机型号 版本等），是否提供接口文档，DB 设计文档等等

第三，制订测试计划
通过测试需求与测试范围，制订测试计划，我需要运用到的测试方法，工作量预估，测试资源，每个节点的测试类型，以及结束测试标准等等（可以针对此面试题来描述）
测试计划需要经过项目组干系人评审通过后才可以进行下一步

第四，根据测试计划设计测试用例
当然，此步会根据个人习惯和经验来适当增减，如先使用思维导图理出测试想法， 然后再扩展。可以按可接受性测试用例、系统测试用例（接口、功能、性能、安全、UI、DB...）来开始设计用例。这样就可以按照所学的 N+测试方法来充分设计 Case 了，而有了测试计划中的相关策略来指导 ，也不会疏漏其他的需求点了。

第五，后续的执行测试步骤（可以依情况来作描述）我们暂且就此面试题展开分析 ，故不作深入探讨 。

做好测试用例工作的关 du 键是要充分考虑测试计划 zhi 的实用性，坚持 5W1H 的原则，dao 采用评审和更新机制以及测试策略。要充分考虑测试计划的实用性，即测试计划与实际之间的接近程度和可操作性。要坚持“5W1H”的原则，明确测试内容与过程。采用评审和更新机制，确保测试计划满足实际需求。因为软件项目是一个渐进的过程，中间不可避免地会发生需求变化，为满足需求变化，测试计划也需要及时地进行变更。测试策略要作为测试的重点进行描述。测试策略是测试计划中的重要组成部分，测试计划是从宏观上说明一个项目的测试需求、测试方法、测试人员安排等因素

通过，失败，未执行，无效，阻塞，不适用

等价类划分，边界值，错误推测，因果图，场景法，正交表

应用的场景
等价类划分
多用于输入框：注册/登录
边界值（掌握上点和离点的取值）
多和等价类划分结合使用，有边界限制的:注册的密码长度，，
场景法
从基本流开始，再将基本流和备选流结合起来，可以确定用例场景 银行取钱
正交表
用于多个下拉框之间的组合，可以通过正交助手生成测试用例
错误推测
错误猜测法是测试经验丰富的人喜欢使用的一种测试用例设计方法。
一般这种方法是基于经验和直觉推测程序中可能发送的各种错误，有针对性地设计。只能作为一种补充
因果图
因果图法比较适合输条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出
自动贩卖机  

判定表方法是黑盒测试方法的一种，主要用于输入和输出比较多，功能逻辑比 zhuan 较复杂的情况，通过画出判定表缕清需求中的功能逻辑，

 案例 1：ATM 取款

步骤 1：熟悉需求，整理业务过程，列出基本流和备选流。

    基本流：成功取款的流程

识别卡-->输入正确密码-->选“取款”功能-->选择正确的取款金额-->点击“确定”，给出提示，出钞，更新账户和 ATM 余额

备选流：取款失败的各个场景

      1）识别卡失败

      2）输入错误密码：

       3次以内--给出提示，重新输入

       3次--锁卡并吞卡

      3）账户余额不足

      4）每次取款上限5000元

      5）每天取款上限20000元

      6）ATM机余额不足

步骤 2：生成场景，填写《场景表》

步骤 3：根据场景，设计测试用例。

说明：场景和用例不一定是 1:1 的比例

    有可能1个场景需要多条用例

    也有可能1条用例能测试多个场景

测试环境=软件+硬件+网络+数据准备+测试工具

1.首先我会从自身去经过多次的测试发现 BUG 出现的次数和频率 记录复现 BUG 的方式 然后发送给开发人员 2.再根据需求文档来确认是否为 BUG 3.如果开发不认为是 BUG 的将复现 BUG 的记录和需求文档找产品经理和项目经理来确定是否 BUG 4.如果项目经理和产品经理都不认为是 BUG 我会将 BUG 记录在测试文档中 方便在下次评审会上将问题再次抛出

首先要做的是重现这个问题并反馈给研发人员，尽快出 patch 或者解决方案。

当 BUG 解决且上线没有问题之后，我们再看后续的处理。

追查原因及处理方法：这个 BUG 出现的原因是什么。这有分为几种情况：

1）测试环境无法重现：可能是线上的环境造成的 BUG 或者是测试环境无法模拟的情况。

解决方法：尽量完善测试方法、尽量模拟测试环境、增加线上测试。

2）漏测：

a.测试用例裁剪过度：错误预估优先级或者时间过于紧迫裁剪了用例

解决方法：在后续版本或者其他项目启动时重新评估测试时间，要求专家介入对优先级进行评估，避免此类事件再次发生。

b.测试用例执行期间遗漏：由于测试人员疏忽造成测试用例执行遗漏。

解决方法：调查该名测试人员的整个测试过程的工作情况，并随机抽测其他模块，对该名测试人员进行综合评估，给出结论，是因为偷懒漏测，还是因为负责模块过多漏测，还是有其他原因，对该名测试人员发出警告，对相关测试主管，项目经理，产品经理发出警告。

c.测试用例覆盖不全：由于用例评审的不严格造成的；中途需求变更造成的；由于某些其他因素造成的。

80%的缺陷出现在 20%的代码中；80%的 BUG 发现在 20%的时间中；80%的花费在 20%的错误代码上。

1.过程描述
测试人员按照测试用例依次进行，并针对缺陷整个生命周期进行跟踪 2.角色的定义
测试人员:负责具体测试执行及跟踪人员
测试组长:负责测试执行机跟踪包括 bug 单的一次审阅
项目经理:对测试人员的 bug 进行审核及分配
开发人员:对分配到个人的 bug 进行解决 3.状态的定义
新建，确认，解决，重新验证，关闭，重新打开

一个 Bug 由测试人员发现并提交,我们将状态标注为新建;开发人员接收了该
Bug,将 Bug 的状态修改为已分配(Assigned),表示已经认可;开发人员解决了该
Bug 后,就将 Bug 的状态修改为解决,并发给测试人员回归测试;测试人员对 Bug
进行回归测试，如果确实已经解决,就将 Bug 的状态修改为关闭,否则的话则发给
开发人员重新修改。还要说明的是,Bug 是可以“死而复生”的,以前版本已经关闭
的 Bug,如果新版本中重新出现,我们就需要将其状态修改为重新打开。

1.轻微缺陷
轻微缺陷是指对产品外观和下道工序可能会有轻微影响的缺陷 2.一般缺陷
一般缺陷是指不影响产品的运转和运行、不会成为故障起因，但对产品外观和下道工序影响较大的缺陷 3.严重缺陷
严重缺陷是指可以引起易于纠正的异常情况、可能引起易于修复的故障或对产品外观造成难以接受的缺陷。 4.致命缺陷
致命缺陷是指会造成安全问题的各类缺陷

所属产品，所属模块，当前指派（重要），bug 类型，操作系统，重现步骤(重要)，验证程度(重要),优先级(重要)，附件等

测试目标，测试的范围，测试环境，测试结果分析(多少轮测试，测试多少，失败多少，成功占比)，遗留缺陷，测试结论（本次测试涉及 xxx 个功能点，发现 xx 个缺陷，其中，xx 个已修复，xx 个遗留。）测试过程完整有效，系统测试通过

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 是否完全修复、有没有对其他功能造成影响、有没有引入新的问题）

1、 开发与测试对 bug 的定义理解不一致产生的问题，例如暴力操作、非常规操作出现的问题、问题路径深、服务器返回的数据不规范、竞品同样有的问题、个别机型问题等情况，开发可能会不愿意修改。

2、 工作流程方面的原因，例如开发有更高优先级的任务没有时间修改、上线时间紧急，来不及修改、开发不关注名下的 bug、开发认为目前的实现比产品需求好等情况

3、 当然还有个人能力原因，例如找不到好的解决方案、影响范围大、找不到 bug 原因，没有解决方案、技术实现难，不知道怎么修改等等原因

4、 另外还有一些不可抗力的客观因素，例如系统问题，第三方应用问题等等

1.需求分析 2.制订测试用例 3.评审测试用例 4.执行测试 5.提交 Bug 并推动 Bug 解决 6.回归测试 7.编写并提交测试报告

1.功能测试：
圆珠笔按下是否能正常书写。

2.性能测试：
笔芯弹出弹回的快慢。

3.负载测试：
连续按，看弹簧能经受多少次伸缩。

4.兼容性测试：
看是否可以使用其他笔芯。

5.强度测试：
用力过度会有什么影响

6.可恢复性测试：
长时间按住弹簧，松开后看弹簧是否可以恢复

7.界面测试：
笔的外观，舒适度

8.安全性测试：
是否会对使用者造成伤害

三角形

 1. 解决用户问题或达到用户目标需要具备的条件或能力 2. 遵守合同、协议、规范或其他要求

1.尽快熟悉软件的需求和业务，只有熟悉了产品的业务流程、你才能迅速找出软件中存在的一些重要的缺陷 2.把自己当成用户，把自己当成是用户去使用该系统，比如在使用该系统过程中是这样操作的吗？ 3.善于怀疑，不要开发人员的能力 4.不要让程序开发人员的观点：“用户不会进行这样的操作”而说服自己 5.使用完整的流程去测试软件系统，有些子流程在单独测试时没有问题，但按流程走的时候问题就可能出来了。

和预期不一致的软件行为。

一个软件行为既可能是 bug 也可能不是 bug，那是因为预期的主体千姿百态。

和测试员预期不一致的软件行为。
和程序员预期不一致的软件行为。
和文档预期不一致的软件行为。
和管理者预期不一致的软件行为。
和客户预期不一致的软件行为

不是
是特意设置的安全措施
防止有人马虎，操作后忘记取走银行卡而被人冒领卡中的钱款
所以特意设置了倒计时，限时内没有取走银行卡就会吞卡

1、检查系统是否有中度的特征，如：浏览器窗口连续打开，系统中文件图标改成统一图标，CPU 使用率保存 90%以上等
2、检查软件/硬件的配置是否符合软件的推荐标准
3、确认当前的系统是否是独立，即没有对外提供什么消耗 CPU 资源的服务，如：虚拟机运行
4、如果是 C/S 或者 B/S 结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；
5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对 CPU/内存的访问情况，