软件测试理论

https协议需要申请证书，一般免费证书较少，因而需要一定费用。

http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。

http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

3、POST与GET区别

GET使用URL或Cookie传参。而POST将数据放在BODY中。

GET的URL会有长度上的限制，2kb，则POST的数据则可以非常大。

POST比GET安全，因为数据在地址栏上不可见。

一般get请求用来获取数据，post请求用来发送数据。

4、Cookie和Session的区别与联系

cookie存储在客户端/session存储在服务器端

cookie和session有ID映射，通过ID映射可以管理不同用户的session对象

cookie数据存储不如session安全

session存储数据，加大服务器负载/考虑性能方面减轻服务器压力使用cookie

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

5、测试的目的

软件测试的目的：

是在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

软件测试是为了发现错误而执行程序的过程；

测试是为了证明程序有错，而不是证明程序无错误。

一个好的测试用例是在于它能发现至今未发现的错误；

一个成功的测试是发现了至今未发现的错误的测试。

以最少的人力，物力和时间找出软件中潜在的各种错误与缺陷，通过修正各种错误和缺陷提高软件质量，
回避软件发布后由于潜在的软件缺陷和错误造成的隐患以及带来的商业风险。

6、软件测试原则

1.应当把“尽早和不断的测试” 作为开发者的座右铭

2.设计测试用例时，应该考虑到合法的输入和不合法的输入，以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常终端，电源断电等情况

3.一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大关系

4.对测试错误结果一定要有一个确认的过程，一般有A测试出来结果，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析

5.指定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短的时间内我弄成一个高水平的测试

6.回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见

7.妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档

一、Testing shows presence of defects
    测试显示软件存在缺陷
    测试只能证明软件中存在缺陷，但并不能证明软件中不存在缺陷。软件测试是为了降低存在缺陷的可能性，即便是没有找到缺陷，也不能证明软件是完美的。

   二、Exhaustive testing is impossible
    穷尽测试是不可能的
    现在软件的规模越来越大，复杂度越来越高，想做到完全性的测试是不可能的。在测试阶段，测试人员可以根据风险和优先级来进行集中和高强度的测试，从而保证软件的质量。

   三、Testing early
   测试尽早介入
    为什么测试要尽早介入呢，简单的说就是保证软件质量，降低风险和成本。测试人员一般在需求阶段就开始介入，使缺陷在需求或设计阶段就被发现，缺陷发现越早，修复的成本就越小。

   四、Defect clustering
    缺陷集群性（2/8原则）
    缺陷集群性表明小部分模块包含大部分的缺陷。软件测试中存在Pareto原则：80%的缺陷发现在20%的模块中。
    一个功能模块发现的缺陷越高，那存在的未被发现的缺陷也越高，故发现的缺陷与未发现的缺陷成正比。

   五、Pesticide Paradox
   杀虫剂悖论
   反复使用相同的杀虫剂会导致害虫对杀虫剂产生免疫而无法杀死害虫。软件测试也一样。如果一直使用相同的测试方法或手段，可能无法发现新的bug。
   为了解决这个问题，测试用例应当定期修订和评审，增加新的或不同的测试用例帮助发现更多的缺陷。
   测试人员不能一直依赖于现有的测试技术，而要不断的提升测试方法以提高测试效率。

   六、Testing is context dependent
   测试活动依赖于测试内容
   根据业务的不同，软件测试内部也分为不同的行业，比如游戏行业、电商行业、金融行业。不同的行业，测试活动的开展都有所不同，比如测试技术、测试工具的选择，测试流程都不尽相同，所以软件测试的活动开展依赖于所测试的内容。

   七、Absence of error - fallacy
    没有错误是好是谬论
   有可能99%没有bug的软件也是不能使用的。如果对错误的需求进行了彻底的测试，这种情况就发生了。软件测试不仅是找出缺陷，同时也需要确认软件是否满足需求。如果开发出来的产品不满足用户的需求，即便找到和修复了缺陷也作用不大。

7、软件测试分为哪几个阶段？

软件测试一般分为4个阶段：

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

8、单元测试与集成测试的侧重点

    单元测试是指对软件中的最小可测试单元进行检查和验证。
    测试重点是系统的模块，包括子程序的正确性验证等。

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

在把各个模块连接起来时，穿越模块接口的数据是否会丢失。

各个子功能组合起来，能否达到预期的要求。

系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。
测试重点是整个系统的运行以及与其他软件的兼容性

9、系统测试范围

指的是将整个软件系统看做一个1个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。系统测试由黑盒测试人员在整个系统集成完毕后进行测试，前期主要测试系统的功能是否满足需求，后期主要测试系统运行的性能是否满足需求，以及系统在不同的软硬件环境的兼容性等

10、a测试与ß测试的区别

它们都是验收测试！

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

经过α测试调整的软件产品称为β版本。β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见在β测试中，采用的细节、数据和方法完全由各测试员决定：测试员负责创建环境，选择数据，并决定要研究的功能、特性或任务；
测试员负责确定自己对于系统当前状态的接受标准。
β测试由最终用户实施，通常开发组织对其很少或不进行管理。

11、验收测试怎么做？

测试步骤：

1、制定测试计划，测试项，测试策略及验收通过准则，并经过客户参与的计划评审。
2、建立测试环境，设计测试用例，并经过评审。
3、准备测试数据，执行测试用例，记录测试结果。
4、分析测试结果，根据验收通过准则分析测试结果，作出验收是否通过及测试评价。
       测试项目通过；测试项目没有通过，并且不存在变通方法，需要很大的修改；
       测试项目没有通过，但存在变通方法，在维护后期或下一个版本改进；
    测试项目无法评估或者无法给出完整的评估。此时必须给出原因。如果是因为该测试项目没有说明清楚，应该修改测试计划。
5、提交测试报告。

验收测试：在软件产品完成了功能测试和系统测试之后、产品发布之前所进行的软件测试活动。它是技术测试的最后一个阶段，也称为交付测试。
验收测试的目的：确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
验收测试的参与者：用户，还可能有软测工程师等。

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

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

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

验收标准和注意事项：

    验收测试完成标准: 完全执行了验收测试计划中的每个测试用例。
    在验收测试中发现的错误已经得到修改并且通过了测试或者经过评估留待下一版本中修改。
    完成软件验收测试报告。

注意事项：

    必须编写正式的、单独的验收测试报告
    验收测试必须在实际用户运行环境中进行由用户和测试部门共同执行。
    如公司自开发产品，应由测试人员，产品设计部门，市场部门等共同进行。

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

从测试目标和依据来说：黑盒面对的是产品设计，白盒针对的是程序功能的实现，灰盒针对兼而有之，既要考虑产品设计要求，又考虑到功能实现的效果。

从实现者而言：黑盒在意的是客户的角度，白盒测试针对的研发人员。

从测试模块颗粒度而言：白盒在意的是代码实现层面，而灰盒更加侧重模块之间，颗粒度大于白盒。

在版本层面上，白盒测试一般发生在debug版本，灰盒大多一般在release版本进行。

从测试效果而言，大量的bug在黑盒测试阶段测试出来，而白盒和灰盒测试的bug数目相对较少。

从耗时上来讲，在同等时间内，一般白盒和灰盒的耗时长，bug数量少，一般表现为时间产出比较低，很难大范围普及白盒。黑盒相对bug时间投入产出比较高。黑盒入门较为容易，其次是灰盒，白盒入门门槛教黑盒高很多。

任何工程产品（注意是任何工程产品）都可以使用以下两种方法之一进行测试。
黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。
白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。

黑盒测试

软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。

黑盒测试主要是为了发现以下几类错误：
1、是否有不正确或遗漏的功能？
2、在接口上，输入是否能正确的接受？能否输出正确的结果？
3、是否有数据结构错误或外部信息（例如数据文件）访问错误？
4、性能上是否能够满足要求？
5、是否有初始化或终止性错误？

具体的黑盒测试方法包括等价类划分、因果图、正交实验设计法、边值分析、判定表驱动法、功能测试等。
1、等价类划分：
等价类划分是一种典型的黑盒测试方法，用这一方法设计测试用例可以不用考虑程序的内部结构，只以对程序的要求和说明，即需求规格说明书为依据，仔细分析和推敲说明书的各项需求，特别是功能需求，把说明中对输入的要求和输出的要求区别开来并加以分解。
2、边界值分析：
软件测试常用的一个方法是把测试工作按同样的形式划分。对数据进行软件测试，就是检查用户输入的信息、返回结果以及中间计算结果是否正确。边界值分析（Boundary Value Analysis，BVA）是一种补充等价划分的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价类边界的测试用例。
3、错误推测法：是基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法. 错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.
4、因果图：考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）.
　　因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.
　就是使用已经造好了的正交表格来安排试验并进行数据分析的一种方法，目的是用最少的测试用例达到最高的测试覆盖率

 白盒测试

软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。

白盒测试主要是想对程序模块进行如下检查：
1、对程序模块的所有独立的执行路径至少测试一遍。
2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。
3、在循环的边界和运行的界限内执行循环体。
4、测试内部数据结构的有效性，等等。

白盒测试方法包括：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖等。

以上事实说明，软件测试有一个致命的缺陷，即测试的不完全、不彻底性。由于任何程序只能进行少量（相对于穷举的巨大数量而言）的有限的测试，在未发现错误时，不能说明程序中没有错误。

灰盒测试

灰盒测试，是介于白盒测试与黑盒测试之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。

13、冒烟测试的目的

主要目的
快速验证软件基本功能是否有缺陷，如果冒烟测试的测试例不能通过，则不必做进一步的测试。

概念
冒烟测试是在软件开发过程中的一种针对软件版本包的快速基本功能验证策略，是对软件基本功能进行确认验证的手段，并非对软件版本包的深入测试。冒烟测试也是针对软件版本包进行详细测试之前的预测试，执行冒烟测试的主要目的是快速验证软件基本功能是否有缺陷。如果冒烟测试的测试例不能通过，则不必做进一步的测试。进行冒烟测试之前需要确定冒烟测试的用例集，对用例集要求覆盖软件的基本功能。这种版本包出包之后的验证方法通常称为软件版本包的门槛用例验证。

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

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

14、回归测试怎么做？

对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止出现“以前应用没有的问题现在出问题了”，这是全量回归；当在测试过程中，发现某个模块存在缺陷，开发修复后，测试人员重新验证该缺陷是否被修复，以及验证相关联的模块是否受影响，这叫部分回归。

很多人在做回归测试的时候，都是原原本本的按bug步骤进行验证。事实上，这样做的回归测试是远远不够的。做回归时，不光要验证bug中的内容，还要对bug中所有相关业务都要做基本的验证，另外，bug中如果只提到一个导致bug的入口（举例：修改项目中某个人的信息，一定会存在新建与修改并存的地方，也会在其它地方可进行修改），那么在验证的时候也应该将所有入口都验证到，这在要求测试人员对测试业务非常熟悉的同时，还要求懂点代码，会根据开发的修改方案在代码上与业务上都进行回归。事实上，当每轮的bug都有根据业务的扩展与涉及来进行了验证的话，在回归测试里可以将冒烟完成大部分（具体依bug的数量与模块决定）。

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

15、全部回归与部分回归的区别？

对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止出现“以前应用没有的问题现在出问题了”，这是全部回归；

当在测试过程中，发现某个模块存在缺陷，开发修复后，测试人员重新验证该缺陷是否被修复，以及验证相关联的模块是否受影响，这叫部分回归。

16、需求分析的目的

（1）细化系统需求导出软件需求：建模的方法
（2）解决需求间的冲突：需求协商，与用户进行讨论，数据处理（功能、硬件要求、性能要求是否合理）
（3）确定软件边界（核心任务）：界面，use-case图，system类方法的前后置条件

把用户需求转化为功能需求：

对测试范围进度量

对处理分支进行度量

对需求业务的场景进行度量

明确其功能对应的输入、处理和输出

把隐式需求转变为明确。

明确测试活动的五个要素：

测试需求是什么

决定怎么测试

明确测试时间

确定测试人员

确定测试环境：测试中需要的技能

最低0.47元/天解锁文章

满洲里有象_

关注

2
点赞
踩
8

收藏

觉得还不错? 一键收藏
1
评论
软件测试理论

1、B/S架构和C/S架构区别 CS响应速度快，安全性强，用户体验好，一般应用于局域网中，但是开发维护成本高，； BS可以实现跨平台，客户端零维护，但是个性化能力低，响应速度较慢。所以有些单位日常办公应用BS，在实际生产中使用CS结构。## 2、HTTP协议 1、https协议需要申请证书，一般免费证书较少，因而需要一定费用。 2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。 3、http和https使用的...
复制链接

扫一扫