软件测试学习

软件测试

硬件系统

运算器

计算机硬件中的运算器主要功能是对数据和信息进行运算和加工。运算器包括以下几个部分：通用寄存器、状态寄存器、累加器和关键的算术逻辑单元。运算器可以进行算术计算（加减乘除）和逻辑运算（与或非）。

控制器

控制器和运算器共同组成了中央处理器（CPU）。控制器可以看作计算机的大脑和指挥中心，它通过整合分析相关的数据和信息，可以让计算机的各个组成部分有序地完成指令。

存储器

主存(内存)和辅存(外存)，内存分为RAM和ROM，

RAM是随机存储器，断电后数据丢失，决定一个计算机能运行多少应用程序，既能读出又能写入的半导体存储器。

ROM是只读存储器，断电后数据不丢失，存储的内容是固定不变的，只能读出而不能写入的半导体存储器。

外存 主要用于存放当前不活跃的程序和数据，其速度慢、容量大、每位价位低。如硬盘、U盘、光盘。

输入设备

输入设备和输出设备都是进行人机互动的关键设备。鼠标、键盘等输入设备的出现，给计算机带来了天翻地覆的变化。现有的鼠标主要有两类：光电鼠标和机械式鼠标。通过鼠标，我们可以很方便地在计算机屏幕上进行坐标的定位，可以很好地操作图形和软件处理，为人类提供了最大的便捷。键盘也是一类非常重要的输入设备，计算机大部分的指令都是通过键盘输入来进行的。

输出设备

输出设备也是计算机人机互动的关键设备，它的特点是可以将计算机的信息以画面的形式展现出来，具有很好的直观性。常见的输出设备有显示器、打印机、语音和视频输出装置等。

osi七层模型

物理层

负责传输二进制的比特流

数据链路层

建立逻辑连接、进行硬件地址寻址、差错校验 等功能。（由底层网络定义协议）

将比特组合成字节进而组合成帧，用MAC地址访问介质，错误发现但不能纠正。

将上层数据封装成帧，根据端口与MAC地址，做分组（VLAN）隔离、端口安全、访问控制。（MAC地址在这一层）处理VLAN内的数据帧转发，跨VLAN间的访问，需要上升到网络层。

网络层

进行逻辑地址寻址，实现不同网络之间的路径选择。

协议有：ICMP IGMP IP（IPV4 IPV6）

传输层

定义传输数据的协议端口号，以及流控和差错校验。

协议有：TCP UDP，数据包一旦离开网卡即进入网络传输层

会话层

建立、管理、终止会话。（在五层模型里面已经合并到了应用层）

对应主机进程，指本地主机与远程主机正在进行的会话

表示层

数据的表示、安全、压缩。（在五层模型里面已经合并到了应用层）

格式有，JPEG、ASCll、EBCDIC、加密格式等

应用层

主要为互联网中的各种网络应用提供服务

tcp/ip网络模型

应用层

主要为互联网中的各种网络应用提供服务

传输层

主要使网络程序进行通信，可采用tcp协议、udp协议

网络层

网络层主要用于将传输的数据进行分组，将分组数据发送到目标计算机或网络

链路层

链路层用于定义物理传输通道，通常是对某些网络连接设备的驱动协议

IP地址和端口号

IP地址指互联网协议地址，IP协议中还有一个非常重要的内容，那就是给因特网上的每台计算机和其它设备都规定了一个唯一的地址

IPv4协议的IP地址由4个字节的二进制数来表示，它只有4段数字，每一段最大不超过255，一共32为数字

IPv6协议由16个字节来表示IP地址

IP地址由两部分组成，即网络地址和主机地址。可以根据网络地址分类为：A类地址，一般用于大型网络。B类地址，一般用于中型网络。C类地址，一般用于小型网络。D类地址为多播地址，E类地址保留今后使用

IP地址分类：

A类IP地址：

1.0.0.0到127.255.255.255 (二进制表示为：00000001 00000000 00000000 00000000 – 01111111 11111111 11111111 11111111)。最后一个是广播地址。其子网掩码为255.0.0.0，每个网络只能包含 (2^24) - 2=16777214台计算机(除去一个网络地址和一个广播位)，由第一段的网络地址和其余三段的主机地址组成。

B类IP地址：

128.0.0.0-191.255.255.255(二进制表示为：10000000 00000000 00000000 00000000–10111111 11111111 11111111 11111111)。 最后一个是广播地址。其子网掩码为255.255.0.0，每个网络最多只能包含 (2^16) - 2=65534台计算机。由前两段的网络地址和后两段的主机地址组成。

C类IP地址：

192.0.0.0-223.255.255.255(二进制表示为: 11000000 00000000 00000000 00000000 - 11011111 11111111 11111111 11111111)。最后一个是广播地址。其子网掩码为255.255.255.0，每个网络最多只能包含 (2^8) - 2=254台计算机。由前三段的网络地址和最后一段的主机地址组成。

服务器域名

域名就是我们常见的网址

上传网站

新浪云使用方法

1.打开网址 https://www.sinacloud.com/

2.点击控制台-云应用SAE-创建应用

3.输入二级域名，创建版本号，上传代码包

软件测试含义

软件测试是使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果的差别。在规定的条件下对软件进行操作，从而发现问题，对软件质量进行评估。

软件测试目的

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

软件测试的原则

1.所有的测试都应追溯到用户需求

2.应当把尽早和不断测试作为座右铭

3.合理控制测试深度与广度，完全测试不可能，测试的投入与产出要均衡。

4.80-20原则，软件中80%的bug可以在分析、设计与评审阶段就能被发现与修正，16%的缺陷在系统的软件测试中发现，最后剩下的4%是用户长期使用的过程中才能暴露出来。

5.发现错误较多的程序段，应进行更深入的测试。

6、软件项目一启动，软件测试也就是开始，而不是等程序写完，才开始进行测试 。
7、软件开发人员即程序员应当避免测试自己的程序
8、严格执行测试计划，排除测试的随意性，以避免发生疏漏或者重复无效的工作

9.设计测试用例时，要考虑各种情况。

10.妥善保存一切测试文档

产品质量模型(ISO9126)

软件的内部质量（中间产品的静态测量）
外部质量（测试其外部属性，即代码执行时的行为）
使用质量（软件产品的使用）

外部质量:软件系统作为完整的整体运行时所表现出来的各方面的质量特征。
-测量活动:动态测试: ST

使用质量:最终用户在其真实环境中运行软件系统时,所感受到的软件各方面特性与其目标的符合程度。
测量活动:验收测试、 a、β测试

过程质量、内部质量、外部质量由软件组织内部人员评估: SQA、开发、测试。
使用质量由软件组织外部人员评估:用户。

外部和内部质量分别有6个特性：

功能性：

软件产品在指定的条件下使用时，提供满足明确和隐含要求的功能的能力。

适应性：软件产品为特定的任务和用户目标提供一组合适功能的能力。
准确性：软件产品提供具有所有所需精度的正确或相符的结果及效果的能力。
互操作性：软件产品与一个或多个特性、系统相互配合的能力。
安全性：软件产品保护信息和数据的能力，以保证未授权的用户或系统不能阅读和修改这些信息与数据，而合法用户或系统不会被拒绝访问。
功能顺从性：软件产品符合该功能相关的标准，规范或特定的能力。

可靠性：

是指在指定的条件下使用时，软件产品维持规定的性能级别能力，第一层：软件最好不要出故障。第二层：软件出故障不影响主要的业务和功能。第三层：软件故障影响主要功能时，能快速地定位和解决问题

成熟性

容错性

可恢复性

可靠性的顺从性

易用性：

易用性是指用户在指定条件下使用软件产品时，产品被用户理解、学习、使用和吸引用户的能力。这个能力，简单地就是10个字：易懂、易学、易用、漂亮好看。

易理解性

易学性

易操作性

吸引性

易用性的依从性

效率性：

效率是指在规定条件下，相对于所用资源的数量，软件产品可提供适当的性能的能力，通常，效率就是我们常说的产品性能。

时间特性：在规定条件下，软件产品执行其功能时，提供适当的相应和处理时间以及流量（吞吐量）的能力。
资源利用率，在规定条件下，软件产品执行其功能时，使用合适数量和类别的资源的能力。
效率依从性：软件产品遵循与效率相关的标准或约定的能力

可维持性：

可维护性是指软件产品可被修改的能力。这里的修改是指纠正、改进软件产品，和软件产品对环境、功能规格变化的适应性。

可分析性

可修改性

稳定性

可测试性

可维护性的依从性

可移植性：

可移植性是指软件产品从一种环境迁移到另外一种环境的能力。这里的环境可以理解为硬件、软件或组织等不同的环境。

产品质量模型保证(SQA)

目的：是软件制作的过程对于领导可见的

定义：它是一套计划和方法来向领导层保证。

五个基本目标：

1.保证有计划的进行

2.保证遵循了步骤和需求

3.及时通知给对应人员

4.高管可以接触到项目内部

5.软件质量需要测试工作来保证

QC和QA

QC：检验产品的质量，Quality Control 我们翻译为“质量控制”，对每一个阶段或者关键点的产出物（工件）进行检测，评估产出物是否符合预计的质量要求，对产出物的质量负责。

QA：审计过程的质量，QA的英文为：Quality Assurance 我们翻译为“质量保证”，监控公司质量保证体系的运行状况，审计项目的实际执行情况和公司规范之间的差异，并出具改进建议和统计分析报告，对公司的质量保证体系的质量负责。

工作关系：QC进行质量控制，QA是确保QC按照步骤执行

软件测试基本流程

1.需求分析

2.指定测试计划

3.编写测试用例

4.评审测试用例

5.搭建测试环境

6.等待开发提交测试包

7.部署测试包

8.冒烟测试(对软件主体基本功能进行基本测试)

9.执行测试用例

10.BUG跟踪处理(提交及回归BUG)

11.N轮之后符合需求

12.测试结束

软件测试分类

按测试阶段划分：

单元测试

通过模块(类/方法/函数)测试，使代码达到设计要求 主要目的是针对编码过程中可能存在的各种错误，例如用户输入验证过程中的边界值的错误。

集成测试

将经过单元测试的模块逐步组装成完整的程序。 主要目的是检查各单元与其它程序部分之间的接口是否存在问题，各模块功能之间是否有影响。

自底向上集成测试

从系统结构的底层开始组装和测试，对于一个给定的子系统，因为它的下属模块已经测试完成，不需要桩模块。

自顶向下集成测试

从系统结构的顶层开始测试，先从主控模块开始，逐一把各个模块集成在一起，需要用到桩模块。能较早的发现错误，测试不充分。

增量测试

将测试模块组装到测试完成的模块集合中，再进行测试。且必须为每个模块准备一个驱动模块，但不需要桩模块

非增量测试

先独立地测试每个模块，再将这些模块组装成完整的程序。且测试单独的模块时，需要一个特殊的驱动模块和一个或多个的桩模块

驱动模块：

人们编写的一个小模块，用来将测试用例驱动或传输到被测模块中，也可以用测试工具替代，还必须向测试人员显示该模块的结果

桩模块：

一种能模拟真实模块，给待测模块提供调用接口或数据的测试软件模块

接口测试流程：

1.接口的功能测试(先要保证接口是正确的)

2.测试接口的数据(传递一些不同的数据，保证接口没有问题)

3.自动化测试脚本的编辑

4.测试的性能、压力测试

接口测试发现的典型问题：

1. 传入参数处理不当，导致程序crash；

2. 类型溢出，导致数据读入和写出不一致

3. 因对象权限未进行校验，可以访问其他用户敏感信息

4. 状态处理不当，导致逻辑出现错乱

5. 逻辑校验不完善，可利用漏洞获取非正当利益

restful风格

1. 查看-

   • 方法：GET
   • 响应码：200+查询的数据

2. 增

   • 方法：POST
   • 响应码：201+新增的数据

   3.改

   • 方法：put
   • 响应码：200或201+修改后的数据

   4.删

   • 方法：delete
   • 响应码：204+无

接口测试工具

Fiddler

集成测试的步骤：

1.确定子系统有哪些模块组成，保证这些模块都进行单元测试。

2.有开发人员组装这些模块，生成一个子系统，并保证在此子系统中，各个模块的功能尽可能地发挥出来。

3.测试前要设计测试用例，一个关键的模块要围绕核心展开，以功能和性能为两条主线，要注意模块间的接口。

4.搭建测试环境，按照所写测试用例进行模块连接的充分测试

5.记录测试结果，总结测试问题

系统测试

是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起进行测试。 系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方 ，进行改正。

功能测试：

是在规定的一段时间内运行软件系统的所有功能，以验证这个软件系统有无严重错误。

安全测试：

安全测试检测系统对非法入侵的防范能力。

性能测试：

性能测试是正常情况下的性能指标；

• 压力测试是测试系统的瓶颈所在；
• 负载测试是指系统重负荷性能指标;

兼容性测试：

测试软件在一个特定的硬件、软件、操作系统、网络等环境下系统能否正常运行。

• APP测试

  IOS测试

  Android测试

• WEB测试

易用性测试：

可用性测试是面向用户的系统测试。让一群有代表性的用户尝试对产品进行典型操作，- - 同时观察员和开发人员在一旁观察，聆听，做记录。

• 系统中是否存在繁琐的功能以及指令；
• 安装过程是否复杂；
• 错误信息提示内容是否详细；
• GUI接口是否标准；
• 登录是否方便；
• 需要用户记住内容的多少；
• 帮助文本是否详细；

健壮性测试(容错测试)：

主要测试系统遇到严重故障，能否在指定的时间间隔内修正错误并重启系统。

UI测试：

测试用户界面的功能模块的布局是否合理，整体风格是否一致和各个控件的放置位置是否符合客户使用习惯，更重要的是要符合操作便捷，导航简单易懂，界面中文字是否正确，命名是否统一，页面是否美观，文字、图片组合是否完美等等。

配置测试：

配置测试将验证软件与其所依赖的硬件环境的依赖程度

文档测试：

文档测试是对系统提交给文档进行验证，它要求检查系统的文档是否齐全

验收测试

验收测试是在软件产品完成了单元测试、集成测试和系统测试之后，产品发布之前所进行的最后一次软件测试活动，也称为交付测试。 通常由业务专家或用户进行，以确认产品能真正符合用户业务上的需要。

验收测试包括：正式验收测试和非正式验收测试

正式验收测试：

正式验收测试是一项管理严格的过程，它通常是系统测试的延续。计划和设计这些测试的周密和详细程度不亚于系统测试。选择的测试用例应该是系统测试中所执行测试用例的子集。不要偏离所选择的测试用例方向，这一点很重要。在很多组织中，正式验收测试是完全自动执行的。

非正式验收测试包括：α测试和β测试

α测试

1.Alpha测试是内测版本

2.通常只在软件开发者内部交流

3.一般而言，该版本软件的bug较多，普通用户最好不要安装

β测试

1.Beta是公测版本，是对所有用户开放的测试版本

2.这一版本通常由软件公司免费发布，用户可从相关的站点下载

3.通过一些专业爱好者的测试，将结果反馈给开发者，开发者们再有进行针对性的修改

γ测试

Gamma版本，指的是软件版本正式发行的候选版。该版本已经相当成熟了

按是否覆盖源代码划分：

黑盒测试(功能测试)

功能测试或数据驱动测试，在完全不考虑程序内部结构和内部特性的情况下，通过软件的外部表现来发现其缺陷和错误。

常见的黑盒测试方法有：等价类划分法、边界值分析法、因果图法、判定表法、正交法、场景法、错误推测法

白盒测试

白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构进行测试程序，通过测试来检测产品内部逻辑是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。

白盒测试方法：

静态测试

动态测试

白盒测试中的逻辑覆盖包括：

语句覆盖：每条语句都至少执行一次

条件覆盖：每个判定的每个条件应取各种可能的值

判定覆盖：每个判定的每一个分支都至少执行一次

判定/条件覆盖：同时满足判定覆盖条件覆盖

条件组合覆盖：每个判定中各条件的每一种组合至少出现一次

路径覆盖：使程序中每一条可能的路径至少执行一次

灰盒测试

介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。

按是否运行划分：

静态测试

是指不运行软件，测试包括代码检查、静态结构分析、代码质量度量等，主要对软件需求说明书、设计说明书、软件源代码进行检查与分析。

动态测试

指通过运行被测程序，检查运行结果与预期结果的差异，分析差异原因，并分析软件运行效率、健壮性等性能。 动态测试是目前公司主要的测试方式

按是否自动化划分：

人工测试

通过测试工程师手工对软件进行测试

自动化测试

通过编程写代码，通过程序自动测试软件是否有bug

按方向分类：

功能测试

功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能

性能测试

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。

负载测试，在负载环境中运行，程序能否承担。

压力测试，压力测试是在系统资源低耗的情况下，看程序是否工作

安全测试

安全测试是在IT软件产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程 。

按测试应用分类：

APP测试

APP专项测试

• 安装/卸载

• 消息推送

• 更新

• 弱网测试——2G/3G/4G/5G/WIFI

• 场景交互测试，比如来电话了，正在听音乐，调用相机，前后台的切换

• 权限测试

• 离线测试

WEB测试

和系统测试大致相同

冒烟测试

冒烟测试指对软件的基本业务和功能进行测试

回归测试

修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。

随机测试

随机测试是根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。 随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试用例(TestCase)没有覆盖到的部分。

探索测试

一种软件测试方法，也可以说是一种测试思维方法

这是一种强调个人自由与责任的测试方法，让独立测试人员可以借用不断的学习来改善测试

的规划与测试的执行，而在测试的过程中也会同时改善测试案例达到相辅相成的效果

软件开发模型

瀑布模型(软件生存周期模型)

它将软件生存周期的各项活动规定为依固定顺序连接的若干阶段工作，这些工作之间的衔接关系是从上到下、不可逆转，如同瀑布一样，因此称为瀑布模型。

顺序：可行性研究→需求分析→概要设计→详细设计→编码→测试→运行和维护

瀑布模型特点：

• 是线性模型的一种，每一步都是按顺序来执行
• 每一步都有文档产出

瀑布模型的优点：

1.每一阶段都很清晰

2.只需要关注后续阶段

瀑布模型的缺点：

1.依赖于早期的需求调查，不适应需求的变化

2.早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

快速原型模型

快速原型模型允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义，快速建造一个软件原型，向用户展示软件的原型，获得用户的更改意见以丰富细化软件需求，最终在确定的客户需求基础上开发客户满意的软件产品。

优点：

避免瀑布模型的缺点，可以适应早期需求的变化

缺点：

不适合大型项目，快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。使用这个模型的前提是要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新。

螺旋模型

它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。同时，在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。螺旋模型更适合大型的昂贵的系统级的软件应用。

优点：

1）设计上的灵活性,可以在项目的各个阶段进行变更。

2）以小的分段来构建大型系统,使成本计算变得简单容易。

3）客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。

4）随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。

5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。

缺点：

很难让用户确信这种演化方法的结果是可以控制的。建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。

螺旋模型的项目适用：

对于新近开发，需求不明确的情况下，适合用螺旋模型进行开发，便于风险控制和需求变更。

软件测试模型

V模型

V模型是瀑布模型的变种，是最具有代表意义的模型

• 需求分析
• 概要设计
• 详细设计
• 编码、调试
• 单元测试
• 集成测试
• 系统测试
• 验收测试

W模型

优点：

开发伴随着整个开发周期，需求和设计同样要测试；
　　 更早的介入测试，可以发现初期的缺陷，修复成本低；
　　 分阶段工作，方便项目整体管理。

缺点：

开发和测试依然是线性的关系，需求的变更和调整，依然不方便；
　　 如果没有文档，根本无法执行w模型；对于项目组成员的技术要求更高！

测试用例(Test Case)

测试用例是为特定的目的而设计的一组测试输入，执行条件和预期结果的文档

测试用例八大要素：

用例编号

由字母、字符、数字组合而成的字符串，有唯一性，易识别性。

在系统测试用例中，编号的一般格式为 A-B-C-D

A：产品或项目类型，如CMS(内容管理系统)、CRM(客户关系管理系统)

B：一般用来说明用力的属性，如ST(系统测试)，IT(集成测试)，UT(单元测试)

C：测试需求的表示

用例标题

测试标题是用来概括描述本条测试用例的关注点，原则上标题不可重复，每条测试用例对应一个测试目的。例如，输入包含特殊符号'的客户名称，提交新增信息，验证单引号SQL注入是否屏蔽。

测试项目

当前测试用例所在测试用例所属大类、被测需求、被测模块、被测单元等。

重要级别

分为高、中、低三等：

高级别：保证系统基本功能、核心业务、重要特性、实际使用频率比较高的用例；

中级别：重要程度介于高和低之间的测试用例；

低级别：实际使用的频率不高，对系统业务功能影响不大的模块或功能的测试用例。

预置条件

执行当前测试用例需要的前提条件，如果这些前提条件不满足，则后面测试步骤无法进行测试或无法得到预期结果。

测试输入

用例执行过程中需要输入的外部信息。根据软件测试用例的具体情况，有手工输入的内容、上传的文件、数据库记录等。

操作步骤

执行当前测试用例需要经过的操作步骤，需要明确的给出每一个操作的详细描述，测试人员可以根据测试用例操作步骤完成测试用例执行。

预期结果

当前测试用例的预期输出结果，包括返回值内容，界面的响应结果，输出结果的规则符合度等。

测试用例设计方法

等价类划分法

等价类划分法是典型的、重要的黑盒测试方法，它通过选取若干个适当的数据子集来代替整个数据集的。因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.

等价类划分可有两种不同的情况:有效等价类和无效等价类。

有效等价类：

对程序来说有意义的、合理的输入数据集

无效等价类：

对程序没有意义、不合理的输入数据集

边界值分析法

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

上点：处于边界上的点

离点：离上点最近的点

内点：范围内的点

判定表法

判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。，判定表法表示的是有多个输入，和多个输出，而且输入与输出又相互的依赖关系。能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用判定表能够设计出完整的测试用例集合。

在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。

判定表的四个组成部分：

条件桩：列出了系统的所有输入，问题的所有条件

动作桩：列出了问题规定可能采取的操作

条件项：列出针对它左列条件的取值，输入的各种组合

动作项：不同条件项产生的不同的动作结果

因果图法

用图解的方法表示输入的各种组合关系，写出判定表，从而设计相应的测试用例

因果图中的“因”————输入条件

因果图中的“果”————输出结果

非（～）：若原因出现，则结果不出现；若原因不出现，则结果出现。 （如果C1=1 ，那么E1=0，如果C1=0，那么E1=1）

或（∨）：若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现。

与（∧）：若几个原因都出现，结果才出现；若其中有一个原因不出现，则结果不出现（全0为0，有1为1）

E（互斥）：可以不选，如果选只能选1个

I（包含）：至少选1个（可以多选，不能不选，最少得选1个）

O（惟一）：必须要选，而且只能选1个

R（要求）：如果a=1 那么要求b必须是1，反之如果a=0，那么b值无所谓

M（屏蔽）：当a=1时，b=0,当a=0，b的值有可能是1，也有可能是0注意：唯一和互斥的区别：互斥可以不选,唯一必须要选1个

因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况

特点：

1.考虑输入条件的相互制约及组合关系

2.考虑输出条件对输入条件的依赖关系

正交排列法

在一个界面中，有多个控件，每个控件有多种取值，控件取值组合数量很大，不可能（没必要）为每一种组合编写一条用例。【若编写，则成穷举测试了】
使用最少最优的组合进行测试—–正交排列法

判定表（因果图）也是考虑控件组合，但是组合数量较少（一般不会超过20种），而且要求测试全面

Ln(m^k)

• n表示表的行数，也就是需要测试组合的次数
• m表示列的取值个数，表示每个控件包含的取值个数(因素的水平数，各因素的状态数)
• k是表的列数，表示每个控件的个数(因素的个数，或因子个数)

利用正交表设计测试用例，计算得到的测试用例个数的公式：因素个数*(因素的最大水平数-1)+1

使用allparis工具可生成测试用例

1.在allparis的解压目录下创建txt文件，txt文件存放因素和水平数的具体内容

例如，创建1.txt

2.在解压目录下使用cmd指令进入终端

3.输入命令

//1.txt为输入文件，1.xls为输出的文件
allparis.exe 1.txt >1.xls

4.查看生成的1.xls文件，test cases为我们需要的测试用例

转载自：https://zhuanlan.zhihu.com/p/328272644

场景法

通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。我们通常以正常的用例场景分析开始，然后再着手其他的场景分析。场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。

1、场景法是一种基于等价类划分的测试技术（技术层面）

2、场景法的应用是基于对软件业务（需求）的深入理解（业务层面）

基本流：模拟用户正确的操作流程

目的：验证软件的业务流程和主要功能

备用流：模拟用户错误的操作流程

目的：验证软件的错误处理能力

使用场景法分析程序：ATM取款

1、根据需求，找到基本流和备选流（找出正确的操作流程和可能出错的环节）

（1）基本流—正确取款

①插入银行卡：客户将银行卡插入ATM机的读卡器

②验证银行卡：ATM机从银行卡的词条中读取账号代码，并检查它是否属于可以接收的银行卡

③输入密码：ATM机要求输入密码

④验证密码：验证该密码是否正确

⑤进入ATM机主界面：ATM显示在本机中可用的各种选项

⑥取款并选择金额：客户选择“取款”，并选择取款金额

⑦ATM机验证：ATM机进行验证账户余额是否满足以及总取款金额是否满足要求，验证ATM机内现金是否够用

⑧更新账户余额、出钞：验证成功，更新账户余额，输出现金，提示用户收取现金

⑨返回主界面

（2）备选流—出错环节

①银行卡错误

②密码错误

③密码3次错误

④卡内余额不足

⑤超出当日可取

⑥ATM余额不足

2、根据基本流和备选流列出场景

3、根据场景编写用例

错误推测法

基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。

用例评审

• 同行评审
• 小组评审
• 部门评审
• 项目评审
• 第三方评审
• 邮件评审

测试策略

• 如果输入中包含条件组合，应优先使用因果图进行分析
• 在任何情况下都应该使用边界值进行分析
• 应为输入和输出定义等价类
• 使用错误猜测法增加更多的用例
• 针对上述用例，检查是否能够覆盖白盒测试中的几种测试设计类型

缺陷(bug)

缺陷的含义:

缺陷就是破坏软件正常运行的错误、潜在的功能缺陷。

缺陷的判定标准：

• 软件没有实现需求所规定的功能
• 软件出现了需求说明书中指明不会出现错误的错误
• 软件的功能超出了需求说明书指明的范围
• 软件没有实现需求说明书未指明但应该达到的目标
• 软件测试人员认为软件难以理解、操作复杂、运行速度慢，最终用户体验不好

缺陷产生的原因：

• 需求解释、记录或定义错误

• 设计文档说明存在错误

• 编码说明、程序代码错误

• 硬件或软件系统存在错误

缺陷产生的根源：

• 需求的变更
• 交流不充分
• 软件的复杂性
• 进度压力

缺陷的属性：

缺陷标识(Identifier)：

缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识。

缺陷标题(Summary)：

缺陷标题通过一个标题来描述缺陷

缺陷类型(Type)：

缺陷类型是根据缺陷的自然属性划分的缺陷种类

功能缺陷：

影响了系统的各种功能、逻辑。如：

新增记录失败、修改其实是新增了一条记录没有在原记录上更新、前端更新了但是数据库查询到未更新、逻辑走向错误等。

UI缺陷：

影响了用户界面、人际交互特性，包括屏幕格式、用户输入灵活性、结果输出格式等方面的影响。如：名称过长时被遮挡、文字部分被遮挡、图片只展示部分等。

文档缺陷：

影响发布和维护，包括注释、用户手册、设计文档等。如：

部署文档地址有误、用户手册操作步骤跳跃等。

软件包缺陷：

由于软件配置库、变更管理或版本控制引起的错误。如：

配置库基础数据不完整、提交的版本不是已修复的版本、变更版本时没有彻底完成、版本合并时冲突未全部解决等。

性能缺陷：

不满足系统可测量的属性值，如执行时间、事务处理速率等。如：

一个用户执行时没有响应，将导致多个用户执行时也会没有响应。

系统/模块接口缺陷：

与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突。

如传参个数与接口不匹配、传参类型与接口不匹配等。

缺陷严重程度(Severity)：

缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。

• Critical ：系统瘫痪、异常退出、死循环、严重的计算错误等
• VeryHight： 频繁的死机、系统大部分功能不可用
• Hight ：功能点没有实现、或不符合用户需求、数据丢失
• medium：影响一个相对独立的功能、仅仅在特定环境下发生、与产品需求定义不一致、断断续续的发生问题。
• low ：表面性错误，如错别字、没有提示信息

缺陷优先级(Priority)：

缺陷的优先级指缺陷必须被修复的紧急程度。

• Urgent 最高优先级
• VeryHight 很高优先级
• Hight 高优先级
• Medium 中优先级
• Low 低优先级

缺陷状态(Status)：

缺陷状态指缺陷通过一个跟踪修复过程的进展情况

• new：“新建状态”，测试人员或其他人员发现并确认提交的bug
• open：“打开状态”，开发人员打开缺陷报告并开始修复的状态
• fixed：“修复状态”，开发人员在修复的版本中验证该问题确实已修复
• closed：“关闭状态”，测试人员重新测试该bug确实已修复
• rejected：“拒绝状态”，开发人员接收到测试人员新建的bug后,不认同该bug,认为无需修复的bug
• postpone：“拖延状态”，开发人员接收到测试人员的bug后，如遇到临时有事的情况，可以延后修复，推延该bug的修复
• reopen：“再次打开状态”，bug被关闭了后重新打开

缺陷起源(Origin)：

缺陷起源指缺陷引起的故障或事件第一次被检测到的阶段，如编码阶段、测试阶段、设计阶段、需求阶段、构架阶段、用户阶段

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tTOUPbPf-1634879003514)(C:\Users\高耀基\AppData\Roaming\Typora\typora-user-images\image-20211008231919908.png)]

缺陷来源(Source)：

缺陷来源指引起缺陷的起因,如程序代码、数据库、需求说明书、设计文档、系统集成接口

缺陷根源(Root Cause)：

发生错误的根本因素

所属模块：

缺陷报告书写规范：

标题：应保持简短、准确，提供缺陷的本质信息

尽量按缺陷发生的原因与结果的方式书写

避免使用模糊不清的词语，例如：“功能不正确，行为不起作用”

复现步骤：应包含如何使别人能够很容易的复现步骤，简短

缺陷分析需要注意的点：

• 哪个模块问题最多

• 哪个测试工程师测试的缺陷最多

• 各类缺陷数量占比

• 开发人员能否及时修复缺陷

• 开发人员一次修复缺陷占比

• 软件是否能按时发布

测试报告

​ 1.对工作的总结

​ 2.对BUG的统计分析

• 测试
• 开发
• 软件模块
• 等级
• 解决的时间
• 每个版本
• 状态

​ 3.对被测软件的质量评估

• 一二级的BUG全部被关闭了
• 三级的BUG关闭了80%
• 四级的BUG无所谓

软件测试工具

禅道

下载路径：

https://www.zentao.net/download/zentaopms15.5-80415.html

注意：安装目录名不能是中文

安装后，执行xampp目录下的start.exe

启动禅道

点击访问禅道或在浏览器访问： http://127.0.0.1:81/index.php

输入账号密码，账号密码为客户端下方的红色字体

进入后要输入的账号密码

账号默认值为：admin

密码默认值为：123456

进入系统后修改密码

禅道基本流程如下：
1.产品经理创建产品

2.产品经理创建需求

3.项目经理创建项目

4.项目经理确定项目要做的需求

5.项目经理分解任务，指派到人

6.测试人员测试，提交BUG

新建测试用例：
点击测试——点击用例——点击建用例

JIRA

如何测试一个**

1.功能

2.性能

3.UI

4.兼容

5.易用

6.安全

7.稳定

测试环境介绍：

Linux下的环境搭建

• LNMP:

• Linux+Nginx+MySQL+PHP项目

Windows下的环境搭建

• WAMP：

• Windows+Apache+MySQL+PHP项目

phpStudy——快速搭建Apache+MYSQL+PHP+phpAdmin+ZendOptimizer环境

项目测试

• 熟悉项目的信息来源

  1.需求说明书、用户使用手册、测试用例等

  2.环境

  3.项目中的相关人员

1.提取业务模块

• 也叫子系统

• 了解项目有多少模块，以及有多少子模块，模块和模块之间的关系

• 一般到模块的具体功能，就不用再细分了

2.提取功能点

3.根据功能点设计测试用例

项目测试流程

1.需求评审

软件需求

软件需求是能解决用户的某一问题或达成某一目标的软件功能

需求评审

项目相关人员对软件需求的确认和评估的过程

目的

• 保证需求说明书的完整、准确
• 保证项目团队对需求的理解达成一致

测试人员在需求评审的职责

• 确认自己对需求要有清晰的理解，没有疑惑
• 确认需求文档完整，准确，能够知道后期工作
• 对需求中不合理的地方提出自己的修改意见

2.编写测试计划和测试方案

测试计划

描述要进行的测试活动的范围、方法、资源和进度的文档

测试计划的核心内容：

• 明确的测试目标与测试范围
• 执行计划的角色与职责
• 任务的进度安排与资源分配
• 风险的评估与应急计划
• 测试的准入准出标准

测试计划目录模板：

第一章 项目概述

1.1 项目背景

1.2 测试目的

1.3 对象框架(技术栈)

1.4 术语(技术相关的专有名词)

1.5 参考文档

1.6 受众、读者(项目相关人员)

第二章 测试说明

2.1 测试对象范围

2.2 测试资源

• 软、硬件设备
• 小组人员分配

2.3 进度安排及任务分配

第三章 风险控制

3.1 系统风险

3.2 影响计划的潜在因素

3.3 应急措施

3.4 测试的局限性

第四章 质量评估标准

4.1 测试模块通过标准

4.2 验收测试通过标准

第五章 附录及其他

测试方案

从测试的技术角度去分析需求，在方向上明确要怎么测，分析结果重点在于测试策略与技术实现

测试方案的核心内容：

• 测试策略
• 测试环境的规划
• 测试工具的设计与选择

3.编写测试用例以及评审

编写测试用例基本要求

编写测试用例的步骤：

1.需求分析

2.规划整理测试点

​ 测试点是测试中需要关注的具体功能点

​ 测试点的作用是用来拆分需求。辅助编写测试用例

3.编写测试用例

编写测试用例的原则：

1.能看懂

2.能执行——用例中每个步骤都能执行

测试结果的状态：

1. pass——通过
2. fail——失败
3. block——阻塞
4. NA——忽略

4.执行测试与bug跟踪

5.编写测试报告

http协议(超文本传输协议)

从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议

HTTP协议工作于C/S架构上，浏览器作为HTTP客户端通过URL向HTTP服务器发送请求

默认端口：80

web服务器有：Apache服务器，IIS服务器

服务器接收到http请求后，向客户端发送响应信息

HTTP是无连接，无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。

HTTP是媒体独立的，只要客户端和服务器知道如何处理的数据内容，任何类型的数据都可以通过HTTP发送。

HTTP是无状态的，无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

HTTP使用统一资源标识符（Uniform Resource Identifiers, URI）来传输数据和建立连接。

HTTP请求

HTTP请求报文

请求行

请求行有①②③

请求头

④

请求体

⑤

GET方法没有请求体，它把数据存放在URL提交到服务器中

POST方法有请求体，它把数据存放在报文中的请求体中

HTTP响应报文

响应行

①②

响应头

③

响应体

④

请求方法

HTTP状态码

• 200 - 请求成功
• 301 - 资源（网页等）被永久转移到其它URL
• 403-无访问权限
• 404 - 请求的资源（网页等）不存在
• 500 - 内部服务器错误