B/S架构和C/S架构区别：

b/s：是浏览器和服务端   c/s：是客户端和服务器

http协议：

http协议又叫做文本传输协议，在做网络请求的时候，我们基本上使用http协议。

http协议包括请求和响应

        请求中包含：请求地址，请求方式，请求方式包括get和post请求，get和post的区别是get请求在地址栏后边跟随请求参数，但是请求参数大小有限制，不同浏览器是不同的。一般是4KB。post请求主要用于向服务器提交请求参数。post请求参数是放到请求实体中的，相对get请求更为安全些。

响应包括：200（），404（），500（），304（），307（）

还有各种响应头信息，比如设置缓存的响应头，Content-Type内容类型，设置cookie头信息

POST与GET区别：

get请求没有请求体，通过url携带数据，大小有限制，不安全

post请求通过请求体传输数据，大小没有限制，比get安全

Cookie和Session的区别与联系：

cookie数据放在客户端浏览器上，session数据存在服务器上

cookie不是很安全，别人可以分析存在本地的cookin并进行欺骗，考虑到安全应当使用session

session会在一定时间内保存在服务器上，当访问增多会比较占用你的服务器的性能，考虑减轻服务器性能方面，应当使用cookin

单个cookin保存的数据不能超过4K很多浏览器限制一个站点最多保存20个cookin

测试的目的：

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

软件测试原则：

1.测试证明软件存在缺陷：无论执行什么样的测试操作都能证明软件是有缺陷的

2.不能执行穷尽测试：有些功能是没有办法将所有的测试情况都逻辑出来，所以任何的测试操作都有结束时间

3.缺陷存在群集现象：对于软件功能来说，核心功能占20%，非核心占80%。在实际工作中我们会集中测试20%的核心功能，所以这个部分发现缺陷的几率就会高于80%。因此我们就回遇到缺陷都集中在20%功能模块里的现象

4.某些测试需要依赖特殊的环境

5.测试应尽早介入：为了更多的发现和更好的解决软件中缺陷。我们追求测试工作尽早开展

6.杀虫剂现象：同样的一个测试用例不能重的执行多次，因此软件会对他产生免疫

7.不存在缺陷谬论：任何软件不可能是完美的

软件测试分为哪几个阶段：

单元测试：按模块划分后的颗粒度进行分类测试

集成测试：功能模块的测试

系统测试：多个模块合成测试

验收测试：客户以及产品经理进行

单元测试：比如说对Java中的类和方法的测试，一般由软件开发人员实施（尽可能保证测试用例相对独立，测试过程中不要调用其他类的方法，而是在测试用例中重写模拟方法）

集成测试：（测试各个单元模块的接口）在单元测试的基础上，把软件单元按照概要规格说明书要求，组装模块，测试看是否模块达到了规格技术指标。

系统测试：（黑盒测试）在经过集成测试的单元模块，按照整体需求规格说明书，进行一套有效严格的测试，保证软件的正常运行。（集成测试偏重于技术角度，系统测试偏重于业务角度）

回归测试：（回归测试在测试生命周期中是很重要的一部分，会进行多次回归测试），是指在发生修改之后，再重新回去测试一下，避免修改的内容导致了其他的错误。验证之前出现过但已修复好的缺陷不再重新出现。

冒烟测试：（是自由测试的一种）是指开发者功能完成后的完整性功能测试，发现问题后反馈给开发者进行修改，然后看这次修改是否真的修复解决了这bug，或者对其他模块造成了影响，这个时候就需要冒烟测试来进行验证，缺点就是覆盖率低。

验收测试：也叫交付测试，是针对用户需求、业务流程进行的整体测试，确认是否满足验收标准，由用户、客户看是否接受系统，可以部署上线。

Alpha测试：用户在开发者的场所进行测试，是一个可控的环境中测试的。

Beta测试：是用户在对软件产品进行测试，开发者不在现场，用户对测试过程中遇到的bug进行记录，开发并对它进行修改，再测试，直到用户觉得可以了，就部署上线。

单元测试与集成测试的侧重点：

单元测试

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

集成测试

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

a（内测）测试与ß（功测）测试的区别：

α测试是指软件开发公司组织内部人员模拟各类用户对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的 用户操作方式。经过α测试调整的软件产品称为β版本。

β测试是由软件的多个用户在实际使用环境下进行的测试，这些用户返回有关错误信息给开发者。测试时，开发者通常不在测试现场。因而，β测试是在开发者无法控制的环境下进行的软件现场应用。在β测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告。β测试主要衡量产品的FLURPS，着重于产品的支持性，包括文档，客户培训和支持产品生产能力。 只有当α测试达到一定的可靠程度时，才能开始β测试。它处在整个测试的最后阶段。同时，产品的所有手册文本也应该在此阶段完全定稿。

验收测试怎么做：

验收测试(Acceptance Test)：在软件产品完成了功能测试和系统测试之后、产品发布之前所进行的软件测试活动。它是技术测试的最后一个阶段，也称为交付测试。

验收测试的目的：确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。

验收测试的参与者：用户，客户经理，还可能有软测工程师等。

1 、验收测试的过程和主要内容

前提:     系统或软件产品已通过了系统测试的软件系统。

测试内容:     验证系统是否达到了用户需求规格说明书（可能包括项目或产品验收准则）中的要求，测试试图尽可能地发现软件中存留的缺陷，从而为软件进一步改善提供帮助，并保证系统或软件产品最终被用户接受。主要包括易用性测试、兼容性测试、安装测试、文档（如用户手册、操作手册等）测试等几个方面的内容。

任务： 验证软件的功能和性能符合用户期待。

测试步骤：

制定测试计划，测试项，测试策略及验收通过准则，并经过客户参与的计划评审。

建立测试环境，设计测试用例，并经过评审。

准备测试数据，执行测试用例，记录测试结果。

分析测试结果，根据验收通过准则分析测试结果，作出验收是否通过及测试评价。 测试项目通过； 测试项目没有通过，并且不存在变通方法，需要很大的修改； 测试项目没有通过，但存在变通方法，在维护后期或下一个版本改进； 测试项目无法评估或者无法给出完整的评估。此时必须给出原因。如果是因为该测试项目没有说明清楚，应该修改测试计划。

提交测试报告。

验收标准和注意事项：

验收测试完成标准: 完全执行了验收测试计划中的每个测试用例。

在验收测试中发现的错误已经得到修改并且通过了测试或者经过评估留待下一版本中修改。

完成软件验收测试报告。

注意事项：

必须编写正式的、单独的验收测试报告

验收测试必须在实际用户运行环境中进行 由用户和测试部门共同执行。

如公司自开发产品，应由测试人员，产品设计部门，市场部门等共同进行。

白盒、黑盒和灰盒测试区别：

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

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

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

冒烟测试的目的：

为正式测试前，验证是否产品或系统的主要需求或预置条件是否存在bug。

回归测试怎么做：

1、在测试策略制定阶段，制定回归测试策略

2、确定需要回归测试的版本

3、回归测试版本发布,按照回归测试策略执行回归测试

4、回归测试通过，关闭缺陷跟踪单（问题单）

5、回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试

全部回归与部分回归的区别：

需求分析的目的：

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

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

测试计划的目的：

（1）为测试各项活动制定一个现实可行的、综合的计划，包括每项测试活动的对象、范围、方法、进度和预期结果。

（2）为项目实施建立一个组织模型，并定义测试项目中每个角色的责任和工作内容。

（3）开发有效的测试模型，能正确地验证正在开发的软件系统。

（4）确定测试所需要的时间和资源，以保证其可获得性、有效性。

（5）确立每个测试阶段测试完成以及测试成功的标准、要实现的目标。

（6）识别出测试活动中各种风险，并消除可能存在的风险，降低由不可能消除的风险所带来的损失。

什么时候开始写测试计划：

测试需求分析前总体测试计划书/测试需求分析后详细测试计划书

由谁来编写测试计划：

具有丰富经验的项目测试负责人

测试计划的内容：

1.简介 2.参考文档和提交文件 3.进度安排 4.测试资源 5.严重程度和优先级 6.风险分析

7.测试策略

结束条件(项目上线的条件)：

1、软件经过充分的测试

   开发人员测试---〉交叉测试---〉测试人员测试---〉用户的业务专家测试---〉一定数量的用户业务专家集中测试---〉上线前试运行----〉上线。

   压力测试是必须的

2、用户培训 ：管理员，一定厂或地区必须有一个人经过了培训。

3、基础数据导入完成 ：用户、组织机构、业务数据等基础必须数据导入完成。

4、授权必须完成

5、新老系统的切换必须提前演练过，各种老数据的导入工作完成。

6、应急方案必须有。

常见的测试风险：

需求风险，测试用例风险，缺陷风险，代码质量风险，测试环境风险，测试技术风险

回归测试风险，沟通协调风险，研发流程风险，其他不可预计风险

测试用例的要素：

用例编号 用例描述   执行条件  预期结果 测试输入  实际结果

测试用例级别的划分：

高，中，低

怎样保证覆盖用户需求？

分类：一次告知类，个人喜好，不合理需求类，合理需求类拓展关键词

写好测试用例的关键 /写好用例要关注的维度：

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

测试用例的状态：

排队（In Queue）：

测试用例已经指定给某个测试人，不准备在这一个测试阶段运行。

进行中（IP）：

该测试正在进行，并且会持续一段时间。

阻塞（Block）：

一些因素会导致测试不能进行到底，例如某个功能欠缺或者测试环境的某个部分欠缺。我通常会在测试用例总结工作表的意见栏记录下阻塞的状态。你可以把阻塞理解为：我希望运行测试，但是目前还不能运行测试。

跳过（Skip）：

你决定在当前测试阶段跳过某个测试，可能是因为它的优先权相对较低。

通过（Pass）：

测试运行结束，测试人得到了预料中的测试结果状态和测试行为。

失败（Fail）：

在很多情况下，测试人得到预料之外的测试结果，状态或行为，这些结果与测试目标相差甚远。这就引发了关于系统质量的疑问。一个或多个测试错误需要记录下来。

警告（Warn）：

在很多情况下，测试人得到预料之外的测试结果，状态或行为，但是这些结果与测试目标差别不是很大另一种想法是，警告意味着当前的错误是无关紧要的，或者对正在测试的特征是没有意义的。系统报出了更多的错。我处理这个问题的一个标准是只和延期的或不是一定要改的错误相关的测试可以标记为警告，而不是失败。

关闭（Close）：

一个测试在第一个循环中被标为失败或警告，第二个测试发布中将第一个测试循环出现的错误修改了。重新运行了整个测试用例后，没有错误出现。将这类测试标记为关闭而不是通过，使得你可以跟踪测试在某一个测试发布中失败的实事

常见的测试用例设计方法：

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

判定表用在哪些时候/哪些功能：

判定表是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期，判定表：编写程序的辅助工具

什么时候用到场景法：

基本流和备选流，一般基本流为正常的测试，测试结果为成功的测试，备选流为异常的情况测试

测试环境怎么搭建的：

1，在搭建测试环境前是需要和开发人员做个沟通交接工作的，一般他们会给到相应的系统发布手册，我们会根据这个手册操作流程来搭建。

2，虽然在当下，越来越多的平台开始使用linux操作系统，但也存在差异性，常见的linux包含redhat、centos以及ubuntu等。同样，不同平台使用的web服务器也不一样，当今主流的web服务器包括Tomcat，apache、nginx以及weblogic。而数据库则分为MySQL和oracle.

这个要看不同软件是采用什么类型的要素来进行开发的。

3，由于源码程序是使用JAVA编写的，所以在事先需要向开发拿到相关编译好的安装包。

4，接着需要用xshell(或CRT)远程连接上linux系统，把相关的服务器停掉。在这里以tomcat服务器为例，需要把java程序包放到webapps目录下。

5，接着就是需要启动tomcat服务器了，操作步骤如下：

     首先要停止tomcat服务器，命令如下

     ps -ef | grep tomcat -- 查询出tomcat的进程ID，

      然后，使用命令 kill -9 tomcat的进程ID。

6，最后就是要重新启动tomcat,首先是进入tomcat的bin目录，然后执行命令 ./catalina.sh start即可。

偶然性问题的处理：

一、一定要提交！！

1． 记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。

2． 尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。

3． 程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重现，程序员也会了解问题所在。

4． 无法重现的问题再次出现后，可以直接叫程序员来看看问题。

5． 记录bug要尽量描述清楚发生问题时的测试步骤、测试环境、测试数据。

二、尽量重现bug

对于整个项目或者产品而言，如果这些不可复现的Bug是很严重的Bug，比如导致系统崩溃等，如果不能及时、准确的定位和解决，最终发布出来的软件到达用户手中后，一旦出现势必会影响软件在用户心中的形象，严重的会“迫使”用户选择竞争对手的产品，这些显然都是公司所不愿看到的。而对于测试人员而言，出现了这些不可复现的Bug，实际上是一次很好的锻炼和提高机会，如果只是提交缺陷报告将这个大皮球踢给开发人员，不仅丧失了一次提高测试水平的机会，还有可能破坏和开发人员之间的关系。

要想复现不可复现的Bug，需要先提到一个概念就是ET（Exploring Test），也就是探索式测试，这种测试方法是由James Bach首先提出来的，在所掌握的被测对象的信息不是很充分的情况下，这是一种很有效的测试方法.当出现不可复现的Bug时，大家可以从以下五个方面来进行考虑：

1、被测对象的版本信息

我测试的到底是哪个版本，这主要是有两个作用：一是确认我测试的是正式的软件版本，如果不是就先记录下该问题，然后选择正式的版本进行测试（开发人员基于尝试的一次非正规的修改可能会导致不可复现的Bug）；二是可以和其它版本进行对比，如果其它的版本没有类似的问题，就可以去对比这两个版本之间的区别。

2、环境

这里的环境是指出现不可复现的Bug时所对应的测试环境等，比如测试所用的计算机，如果出现不可复现的Bug，那我换一台机器是不是还会出现类似的问题，也就是说通过环境的改变来进一步搜集不可复现Bug的相关信息。

3、模式

这里的模式是指我对这个Bug如何出现的一个理解，先给这个Bug设定一个模式，比如是不是<u>[<u>数据库</u>](javascript:;)</u>通信中断，然后再进行测试，收集更多的信息去修改和完善这个模式，这样不断进行，最终直到Bug能完全复现为止，这个时候只要使用这个模式就可以复现出Bug了。

4、人

这里提到的人有两个含义：一是测试是由人来进行的，人的操作、人的思维方式会有不同，通过分析这些信息也有可能找到这些不可复现的Bug的蛛丝马迹；二是想复现不可复现的Bug，往往需要多<u>个人</u>之间的相互协作，比如测试人员、开发人员等，通过大家的沟通和协作就能更容易去复现了。

5、测试工具

通过一些debug工具或者log工具等搜集内存等信息，根据这些信息来进行分析，找出不同信息之间的共同点，比如某一块内存始终都会被改写等，通过这种方式来去复现Bug。

上面的五个方面都是和ET的思想紧密相关的，通过不断的测试和不断的信息收集和分析，逐步的把模糊的、不确定的测试变成清晰的、确定的测试，这样就能复现那些不能复现的Bug了。考虑信息时可以从以上五个方面来进行考虑。

三、实在没办法重现

问题无法重现，也要提出，程序员那里可以回复无法再现。问题放在那里，等到再次出现的时候，就立刻叫程序员过来查看。

当我们认为某个地方是bug，但开发认为不是bug，怎么处理：

1.找到需求文档或者是原型图进行匹对

2.尝试多种测试环境和多种测试方式来确认是否为bug

3.整理bug的复现的步骤和出现的频率

4.开发坚持不认为是bug的时候找项目经理测试经理进行沟通来确认是否为bug

5.将客户经理 测试 测试经理和项目经理进行开确认会来判定是否为bug

6.测试人员需要将bug整理并写入测试总结中

产品在上线后用户发现bug，这时测试人员应做哪些工作：

1.测试人员可以做的是重现这个问题并及时反馈给开发人员，找到解决方案进行修复

2.由于疏忽造成测试用例执行遗漏，测试人员需要在下次执行测试的过程和下个版本上线的前要补全测试用例并避免这样的情况发生，

分析bug的根本原因，考虑如何避免此类问题再次发生

分析bug是在哪个阶段引入？是设计阶段、开发阶段、测试阶段？

分析bug引入的原因是什么？是流程问题、技术问题、管理问题？

处理问题的流程是否合理？是否有问题预警、是否有紧急上线规范。

出现问题后，根据问题的紧急性而决定解决方案，如有的必须的几个小时内解决，有的可以几天内解决，有的必须立刻修改错误数据让业务能继续运作......

你也可以谈根据问题严重程度而使用不同的修复、测试流程。

对于测试通过的补丁，也可以谈安装窗口的选择。

其实发现bug后的行动很多，不可能全部谈，找几个行动谈，让雇主相信你真的有运维经验就行。

二八定理：

二八定律又名80/20定律，帕累托法则也叫巴莱特定律、朱伦法则、关键少数法则、不重要多数法则、最省力的法则、不平衡原则、被广泛应用于社会学及企业管理学等。

是19世纪末20世纪意大利经济学家帕累托发现的。他认为，在任何一组东西中，最重要的只占其中一小部分，约20%，其余80%尽管是多数，却是次要的，因此又称二八定律。

如何跟踪缺陷：

首先，圈定该系统的应用范围，是单一的项目，是一个部门，还是多个组。 其次，商定跟踪模型，这是核心所在。这一步需要和项目成员一起讨论确定一个大家都接受的模型，包括设计变更的生命周期等一系列定义。接下来要设定一些角色，比如提出者，管理者，质量保证工程师或测试人员等。然后需要制定一个执行计划；再下来部署该缺陷跟踪系统，一个原则是尽量少的对系统进行修正；最后确保该系统正常运转，达到最初的目标。

缺陷的状态：

新建，已修复，关闭，重新打开，推迟，不能复现，重复，不是缺陷

缺陷的等级：

系统崩溃 ：严重，一般，次要，建议

分别为：致命的(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缺陷修改时间

测试报告的主要内容：

（一）bai测试项目背景介绍

主要介绍这份测试报告具体的编写目的、测试系统名称、测试环境、文中用到的专业术语，以及列出该份测试报告中引用的参考资料。

（二）测试计划

列出详细的测试计划，通过表格标出测试内容，逐项说明系统功能、系统输出等质量指标，以及测试进度等；

（三）测试结果及发现

逐项分析本项测试中实际得到的动态输出（包括内部生成数据输出）结果同对于动态输出的要求进行比较，陈述其中的各项发现。

（四）测试分析摘要

记录测试过程中软件缺陷和限制，同时说明每项缺陷和限制对软件性能的影响，并说明全部测得的性能缺陷的累积影响和总影响，最后统计本次测试过程中的资源损耗情况。软件测试报告也可以找测试机构做，需要第三方软件测试报告可以咨询卓码软件测评，独立的第三方测试机构，拥有完善的测试环境和先进的测试技术，帮助企业做好软件测试工作。

如何定位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的修复：

开发不修改bug的原因有四：bug路径较深、上线时间紧急、改动影响范围大、第三方应用问题。我们逐条分析解决方案

1、 针对路径较深的bug，测试在推动开发修复bug时，需要注意以下几点

a) 从用户的角度分析问题的严重性，分析用户的遇到此问题的概率，引导开发站在用户角度去思考，从而使开发意识到问题的严重性

b) 可以和开发人员列举一个之前的类似问题，为开发提供参考

c) 产品是负责这个软件的人员，当测试与开发意见无法达成一致时，不要因为无法推动开发修改而放弃，一定要找产品确认，最终的决定权交给产品人员。

2、 上线时间紧张，开发来不及修改了，这个时候测试应该分析问题的严重性，和产品人员商议是否需要修改

3、 修改bug改动较大，影响范围广，没有最优的解决方案等情况在项目即将上线的节点比较忌讳这种事情的发生。面对这种情况，建议开发人员做调研工作，请教其他的同事，或者组织一个临时会议，集众人之力研究好的修改方案

4、 第三方应用问题，开发无法修改。确认原因之后需要找相关的工作人员，例如产品，联系第三方输入法的工作人员，反馈问题，尽量推动应用解决问题

软件测试流程：

我们一般在项目进行开立项会（产品，项目，开发，测试）的时候进行参与，讨论需求并提出建议，在立项会中执行

需求文档，由UI设计原型图，开发根据需求文档进行编码，我们测试会根据需求文档进行编写 测试设计，根据模块模

块的（颗粒度） 划分并编写测试用例，开发结束后测试对主要功能进行冒烟测试，执行测试用例，提交bug开发进行

修改修改成功后关闭bug，用例执行结束后进行回归测试，在上线进行测试总结。

项目介绍：

对一支圆珠笔进行测试，要从哪些方面进行测试？

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

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

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

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

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

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

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

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

三角形测试用例设计:

1、 当三边不可能构成三角形时提示错误，可构成三角形时计算三角形周长。

2、若是等腰三角形打印“等腰三角形”，若两个等腰的平方和等于第三边平方和，则打印“等腰直角三角形”。

3、若是等边三角形，则打印：“等边三角形”。

4、画出程序流程图并设计一个测试用例。

1、构成三角形的条件：任意两边之和大于第三边；

2、构成等腰三角形的条件：任意两边相等；

3、构成等腰直角三角形的条件：任意两边相等，而且两条边的平方和等于第三边的平方和；

4、构成等边三角形的条件：三条边都相等。

在项目中发现哪些经典bug？什么原因导致的？

第一，出现这个bug,可以判断研发在最后保存数据时,并没有对数据的有效性进行判断,而是在相关控件进行操作时进行判断的.这样风险有点大,因为控件之间对数据也会有影响,如果仅在操作控件时判断，会产生问题.

第二，这种脏数据虽然不会在视图展示，但保存在服务器上,在各个平台上均会进行同步.这还需要保证其他平台对于脏数据进行处理，且不会出现问题.风险较大.

基于这两个原因，研发还是解决了这个问题.这对我还是有一定启发的.

看问题可能会更考虑多方面的影响.不单纯只是现象.

一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由。

在需求文档不太详细的情况下，如何开展测试：

软件生命周期中，需求是整个项目的源头。俗话说良好的开端是成功的一半，但是，不是每个项目都能遵从流程，花太多时间在需求分析上，而把精力投入到代码的编写中。这可能导致什么问题呢？开发和测试对需求理解都不充分，开发出来的功能与实际需求不符，测试要么凭自己的经验一步一步发掘潜藏的功能点，把项目往良性的轨道上引，要么就听从开发的脚步，亦步亦趋。那么测试人员要如何在需求不明确或者文档不全的情况下着手测试才能保证软件的质量呢？

一、参考同类型的网站：一般情况下，我们测的系统总会有原型可参考，比如我目前测的订票系统，就可以参照携程，主要功能基本一样，细节可能有出入，携程上操作一遍，然后再看看它提供的帮助，再有可以网上搜索资料，参考下行业的基础知识，这都是收集需求的方法，这样子下来也基本对订票系统也就有个认识了，然后与开发经理确认，再和开发一起把功能定下来，该改的改，该修的修，BUG一点不含糊。弱弱的吐槽下，这个项目的开发居然都不知道有需求说明书，虽然写的基本没太大的价值。

二、根据经验和常识判断：做项目多了就知道，万变不离其宗，系统不一样，思路可以套用，所谓的学以致用，举一反三。我上个项目做的银行测试，我照样可以测现在的订票系统，就在一个字：活。有需求照需求测，没有需求找参照，说个例子吧，订票系统中有个功能是积分，需求上就一句话提到有积分功能，怎么测？难道看到有这个功能就算过了？我后来就参照了淘宝的积分抵扣，下单了积分就被临时冻结了，取消订单又释放出来，但开发在做这个功能的时候也没有跟他们的头沟通，直接是要等支付完成后才扣除积分，这导致一个什么问题呢，可以重复使用积分，如果真上线使用了，说不定会造成不小的经济损失的。类似这样的问题太多太多，你总可以从一些地方获得参照，或者说是灵感，项目测的怎么样，跟测试人员的素养有很大的关系，尤其是在没有规范的流程下。

　三、沟通：毋庸置疑，这太重要了，需求不一定在文档中写出来，但道理上开发肯定知道需求的，但一般不会主动和测试沟通，因此，我们作为测试就要主动和开发人员沟通，不仅可以对系统有更深的了解，还可以对项目进度有把握。

　四、多和同事讨论

如何尽快找到软件中的bug：

尽快熟悉公司的产品业务

根据产品的业务属性来熟悉产品的业务流程，这样才能迅速找出软件中存在的一些重要的缺陷，这样发现的软件的价值才是有价值的，否则即使你能找到一些软件缺陷，那也是纯软件的缺陷，价值不大。

把自己当成是用户

把自己当成用户去使用该软件，比如在试用软件的过程中，思考用户是这样操作的么；

2.1 比如大量要求用户输入的软件界面中，有一些用户喜欢使用Tab键采用全键盘的输入，此时正确的接口应该是从左到右，从上到下的顺序。

2.2 比如有的用户喜欢使用快捷键进行操作（Ctrl+C），但是实际情况下一些开发出来的软件的快捷键根本不起作用。

2.3 比如软件在需要用户输入信息的时候（特别是在填写个人资料的时候），必填选项后面一律要用*等醒目的表示要让知道这个地方必须要填写。

2.4 下拉框不选的时候，应该有个默认值，并且要多检查程序中的多处下拉框，因为很多情况下下拉框取不到值。

善于怀疑

世界上没有绝对正确的，总有错误的地方，具有叛逆心理，别人认为不可能发生的事，我却认为可能发生；别人认为是对的，我却认为是错的。假如一个水平很高的程序员编写的程序，不要有“他写的这个程序应该没有问题吧”这种想法，这样很容以遗漏软件中的Bug。

不用让程序开发员“用户不会这样操作”的观点说服自己

遇到这样的情况，你要坚持自己的正确的观点，把这种现象作为一个Bug。

在测试的过程中要跟踪一条数据的完整流程。

比如“点击商品—收藏商品—加入购物车—订单结算—付款—消费二维码—消费—二维码失效”，如果在测试软件过程中业务流程逻辑都走不通的话，还么这个软件测试与不测试就没有什么区别的。

回归测试要注意的事项

程序员提交新的版本后，作为测试人员应该立即与程序员沟通这个修改的功能，并了解这个新修改的功能影响那些功能。而被影响的功能，是在回归测试中优先重点测试的地方，而且也是最容易产生Bug的地方。

与使用者互动的缺陷

7.1 如填写资料错误的时候，应该能够提示错误的位置，让用户知道这个地方输入的数据不对；

7.2 删除数据前一定要给定出是否删除的确认提示；

7.3 不要在软件中使用中英文混合的提示：比如对于用户在进行某个操作的错误提示，不要一会用“Error”，一会又用“错误”，一定要统一；

7.4 要对程序员的错别字进行检查，比如吧“登录”写成“登陆”；

7.5 在软件中不要对用户使用很专业的术语；

7.6 新增/修改信息白村提交后系统给出“保存/提交/修改成功”的提示信息，并自动更新显示；

7.7 在用户进行大量的输入后，点击保存按钮，仅仅是因为某个地方输入选择不正确，点击确定后所有的输入信息都被清空了，这样的Bug会大大降低软件的易用性；

7.8 对于软件的查询功能，测试的时候设置开始时间>结束时间，看看能否查询出记录；

软件的边界值

众所周知软件最容易在边界值上出现问题，所以作为测试人员一定要在边界值上多测试，比如测试用户输入框中的数值的最大数和最小数，以及为空的情况；

非法容错性

比如在需要输入数字的地方输入字母，在需要输入字母的地方输入数字，在需要用户输入的文本框中拷贝字数很多的整编文章到这里测试看看软件是如何做处理的；

软件接口测试

如果软件不同部部分是由不同程序员共同完成的，那么要在他们程序接口相关联的地方多检查，避免双方程序员互相认为做了接口处理，最后谁也没有做接口的处理，导致软件在运行中产生缺陷；

兼容性测试

软件测试要在不同的硬件、软件下（包括操作系统、浏览器）下的测试；

11.1 硬件 有时候软件在配置很高的机器上，有时会隐瞒一些错误，由于CPU运行过快的时候，很多现象一闪而过，发现不了缺陷；

11.2 软件 有时软件在不同版本的浏览器中的界面与权限是不一样的，这样的例子就是软件中的一个Bug了；

软件在压力之下容易出错

软件在压力之下容易产生的错误，是作为一名测试人员必须要知道的事情。所以在测试过程中，将软件在压力之下长时间运行，然后看看软件是否能在压力之下正常工作；

随机测试：

即使经过大量的充分测试，也不能发现软件中的所有缺陷，所以在测试的时候可以做一些随机测试，比如胡乱在界面上乱点，有时也会发现一些意想不到的软件缺陷；

学习他人经验：

什么是bug：

1.产品说明书中规定要做的事情，而软件没有实现。

2.产品说明书中规定不要做的事情，而软件确实现了。

3.产品说明书中没有提到过的事情，而软件确实现了。

4.产品说明书中没有提到但是必须要做的事情，软件确没有实现。

软件很难理解，很难使用，速度超慢，测试人员站在最终用户的角度看到的问题是平常的但不是正确的。

注：产品说明书中没有提到但是必须要做的事情，软件确没有实现。软件实现了产品的功能，但是没有考虑软件在弱网络、低电量的情况下也能正常使用，而做出来的产品在弱网络或低电量的情况下报错，那么这也是一个bug。

ATM机吞卡的吞卡现象是不是BUG：

这个不能绝对的说BUG.应为比如说输入三次错误的密码，需求上就是需要吞卡。那这个就是正常的，不是BUG。那如果说一直没有考虑到的操作，导致了吞卡，那这个就可以定位成BUG

如何减少非问题单的提交：

有个程序，在windows上运行很慢，怎么判断是程序存在问题，还是软硬件系统存在问题:

1、检查系统是否有中度的特征，如：浏览器窗口连续打开，系统中文件图标改成统一图标，CPU使用率保存90%以上等

2、检查软件/硬件的配置是否符合软件的推荐标准

3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务，如：虚拟机运行

4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；

5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况。

你们发现bug会怎么处理:

发现BUG后，接下来你提交到BUG管理平台，提交一个BUG包含哪些内容？

BUG标题—标题要清晰简洁，写明BUG描述；如果没有选择功能模块，最好在标题中标注功能模块。让查看BUG的人员清楚知道你所表达的意思。BUG的功能模块+BUG的操作+BUG的结果

重现步骤—步骤—简单写下发现BUG的测试过程，罗列下。能指导开发重现这个BUG。附上测试数据实际结果----出项BUG的结果，粘贴BUG截图，日志截图，截图直接粘贴就可以了，不要添加附件，附件：日志、测试数据（文件）图片，比如上传头像，就把图片放在文件中当附件上传，开发要重现这个BUG，那么根据你附件的图片来重现。预期结果----记得写清楚预期

BUG类型和严重程度-----便于后续测试结果分析，BUG的统计

BUG测试环境---例如：什么系统；哪个版本等。兼容性问题、难以重现问题

附件----日志文件、文件测试数据

所有以上的如何提交BUG，参考公司前辈写的BUG，依葫芦画瓢，拓展测试思维。

测试的BUG备注修改方案和操作信息

如果写了两条一摸一样的BUG或者提交的BUG不是BUG而是操作错误，问同事怎么删除，或者是在BUG标题前面备注“需删除”，然后跟老大说，老大会批量删除。或者不删除自己编辑下其他BUG.

BUG的跟踪管理-状态处理

1.已经指派的BUG---已经指派给开发的，请大家注意自己BUG的走向，随时关注并进行跟踪！如果一直未修复，提醒开发修改，以免开发忘记；如果已经修复等待测试环境更新后进行验证。催着改BUG

2.已解决的BUG----等待测试环境更新后进行验证，验证通过则关闭；验证不通过则重新开发指派给开发

3.重复BUG----先去查看下是否跟开发指定的BUG重复？如果确定时重复则关闭；如果不重复，说明原因，重新打开指派给开发。

4.不是缺陷----确认开发环境是否分测试环境一致，如果如开发所说不是缺陷则进行关闭；如果确认是缺陷跟开发沟通，沟通未达一致找产品/反馈老大确认，确认是BUG注明情况并在次指派给开发。

5.无法重现----确认开发环境是否跟测试环境一致？包括操作步骤，浏览器、环境、特定账号等，如果多个版本验证之后，如开发所说重现不了，依据BUG的严重程度跟产品，开发一起确认关闭；如果找到重现原因，注明清楚并再次指派给开发。

6.不予解决---找产品经理进行确认。确认不予解决进行关闭；确认需要解决请备注原因并打开指派给开发

7.设计如此---找产品经理进行确认。确认设计如此进行关闭；确认是问题，备注原因重现指派给开发。

8.延期修改---请看下BUG严重程度，是否影响当前版本发布？与产品经理进行确认。不予延期请根据情况进行激活与情况说明；确定延期则做好记录，后续版本进行关注。