软件测试

祝衍军

目录

  • 1 软件测试概述
    • 1.1 软件测试概述
    • 1.2 软件缺陷(BUG)
    • 1.3 软件测试职业发展
    • 1.4 软件测试分类
    • 1.5 软件测试流程
    • 1.6 课程思政:秘书也疯狂的故事
  • 2 黑盒测试
    • 2.1 黑盒测试概述
    • 2.2 等价类划分法
    • 2.3 边界值分析法
    • 2.4 决策表法
    • 2.5 正交实验设计法
    • 2.6 场景测试法
    • 2.7 错误推测法
    • 2.8 功能需求分析
    • 2.9 测试用例设计
    • 2.10 课程思政:五笔输入法的故事
  • 3 测试执行
    • 3.1 测试计划
    • 3.2 测试执行BUG记录
  • 4 白盒测试
    • 4.1 白盒测试概述
    • 4.2 程序流程图设计
    • 4.3 白盒测试用例设计
    • 4.4 JUnit单元测试
    • 4.5 课程思政:WPS的故事
  • 5 Web应用软件自动化测试
    • 5.1 Python自动化测试基本框架
    • 5.2 登录页面测试脚本设计
    • 5.3 新增文章页面测试脚本设计
    • 5.4 基于Unitest的登录测试用例集脚本设计
    • 5.5 课程思政:大并发案例阿里云的小故事
  • 6 智能终端APP自动化测试
    • 6.1 企业案例
    • 6.2 Android智能终端设备连接
    • 6.3 Android APP应用自动化测试
    • 6.4 Monkey 压力测试
    • 6.5 课程思政:鸿蒙的故事
  • 7 JMeter性能测试
    • 7.1 性能测试需求分析
    • 7.2 文章新增脚本开发
    • 7.3 文章新增脚本完善
    • 7.4 场景设计与运行结果分析
    • 7.5 课程思政:12306网站的技术进步故事
  • 8 Postman接口测试
    • 8.1 Postman
    • 8.2 企业网站管理内容系统接口测试
  • 9 Loadrunner性能测试(1+x考证高级相关知识点)
    • 9.1 录制回放
    • 9.2 思考时间设置
    • 9.3 检查点设置
    • 9.4 参数化设置
    • 9.5 关联设置
    • 9.6 集合点设置
    • 9.7 场景设计与运行分析
  • 10 省技能大赛
    • 10.1 竞赛系统
    • 10.2 相关知识
  • 11 企业案例
    • 11.1 软件测试公司真实案例
软件测试分类


软件测试从杯具开始

给你一只纸杯,你如何去做测试?

Ø软件测试从杯具开始

ü需求测试:查看杯子的使用说明

ü界面测试:查看杯子的外观

ü功能测试:装物体时漏或不漏,能不能喝到杯子中所装物体

ü安全性测试:有没有毒或细菌

ü可靠性测试:从高处落下杯子的损坏程序

ü可移植性测试:在不同地方、温度一是否可正常使用

ü兼容性测试:装果汁、白水、酒精等

ü易用性测试:是否烫手,防滑,方便使用

ü疲劳测试:放24小时水

ü泄漏时间和情况测试:装汽油24小时看泄漏时间和情况

ü压力测试:放针不断加重,击穿


对于不同的项目和不同的阶段来说,往往需要用到不同的测试手段。没有哪类测试是可以包罗万象、照单全收的。测试人员需要在平时积累这些测试手段的特点和适用范围,不能到用的时候不辨仙源何处寻。


(1)白盒测试

白盒测试属于代码级的测试,深达代码内部寻找其内部结构的BUG。白盒测试的优点是从程序的内部结构设计入手,测试能够进行的非常深入。

白盒测试的缺点是投入人力资源的难度大,执行白盒测试需要测试人员有不亚于开发人员的技术背景和对代码的熟悉程度,而这往往是很难做到的。


(2)黑盒测试

黑盒测试属于系统级的测试,一般要到开发的后期,系统基本稳定之后,从功能和性能方面着手来进行的测试。


(3)自动测试

自动化测试有其特色和长处,但是也有致命的短处。

第一条长处就是自动测试的可重复性。

长处之二是执行的速度与效率。

第一个短处就是前期投入比较大,花钱买工具只是自动测试的第一笔投入。

缺点之二就是自动测试过于机械呆板。


                             


 

适合应用自动测试

 

 

不适合应用自动测试

 

 

待测软件成熟度

 

 

适合软件比较稳定,功能比较成熟的软件,比如:已经上市的软件的版本升级测试,这时的软件没有大的功能的变动,测试变成了重复性的纯体力劳动,最适合发挥自动测试的长处

 

 

开发阶段的软件,功能不够完善,自动测试无法顺利运行很长时间,效率无法得到体现。此外开发阶段如果设计有时变更,会严重打乱自动测试的进度,测试工程师需要经常根据测试的改动修改测试脚本,非常浪费人力

 

 

待测软件测试周期

 

 

测试的轮次越多越好,如果某单一产品测试轮次不够多,而其后续产品能够继承绝大多数的测试脚本,也在适合之列

 

 

产品单一,测试轮次很少,没有后续产品,功能点无法有效重用,这些都是不适合自动测试的因素

 

 

测试数据量

 

 

在大业务量测试时有时需要营造巨大的测试数据或测试输入,这时设计和应用自动测试工具是必需的选择。例如,如果要在实验室中模拟10000个用户同时访问某服务器,自动测试工具是唯一的选择

 

 

相反的,对于数据量很小的功能验证,与其花时间搭建自动测试的环境、脚本、还不如举手之劳地做了算了

 

 

待测软件输出类型

 

 

自动测试的核心难点是测试结果和期望结果的自动化比较。所以软件的输出结果必须是机器可识别的,比如数字、文本等

 

  如果待测软件输出的结果是未经数字化的图像、震动、声音等,机器识别起来有难度,这会加大自动测试系统的成本

 

(4)压力测试

一般的通信软件,尤其是服务器端的软件,对于性能,特别是在恶劣、繁忙、大数据量交互等特殊环境下的软件强壮性要求会很高,压力测试就应允而生,它是指为某个单一的目的,大强度的重复性的使用软件的某一功能,以期发现该功能在压力条件下的性能指标。压力测试英文称为Stress Test:当测试软件长时间运行的性能时,可能叫做疲劳测试;当聚焦在某一特定功能的循环使用时,可能叫做专项测试,英语叫Focus Test;还可能有其他五花八门的叫法,但这种不同更多是属于不同的命名法则,他们的概念和目的大抵是类似的。


(5)协议一致性测试

在通信方面的软件测试中,一个非常核心的内容就是协议一致性。比如数据通信协议,大家耳熟能详的TCP/IP协议栈。协议(Protocol)是通信系统的核心,它保证了所有通信设备能够正常工作。


(6)互操作性测试

互操作性测试就是验证自己的产品和其他的设备是不是能够正常通信。

(7)现场测试

现场测试是一种着重考察通信终端设备和不同网络设备之间信号特性相匹配的测试。


(8)用户界面测试

绝大多数软件都存在着与终端用户交互的问题。用户界面被设计得越来越方便,相应的也就出现了诸如用户界面测试这种测试手段来考察用户界面的易用性和功能的完善性。

一般有这样的指标:第一是界面的有效性,指执行特定操作所需花费的时间或步骤的数目,这个数目越少越好;第二是界面的连贯性,在不同窗口或不同子模块中,用户界面的风格应当是一致的,要不然愚蠢的用户们该抱怨不习惯了;第三是界面的传统性,界面的风格和术语是否符合使用者的习惯,大家都管关闭程序的命令叫做关闭,而你偏偏要叫做停止,谁看了都会觉得不舒服的。

(9)α测试是由用户在开发环境下对软件产品(α版本)进行的测试,也可以是开发机构内部的用户在模拟实际操作环境下进行的测试。它的特点是在一个受控的环境下进行测试。

(10)β测试是由软件的一个或多个用户在实际使用环境下进行的测试,它的特点是开发人员不在现场,是在开发人员无法控制的环境下进行的测试。

(11)第三方测试是指委托开发方、用户方以外的第三方非利益相关机构所进行的测试。

第三方测试有别于开发人员或用户进行的测试,其目的是为了保证测试工作的客观性。



软件测试原则

目前流行的软件测试有八项基本原则,这八项基本原则可以指导我们更有效的执行软件测试。

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

(2)程序员应该避免检查自己的程序,软件测试应该由第三方构造。程序员对自己的程序已经产生抗体,所以测试自己的程序无法测试深层次的缺陷。

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

(4)一定要注意测试中的错误集中发生现象,这和程序员的编程水平和习惯有很大的关系。测试中存在群集现象,错误喜欢发现在相同的模块以及相关的开发人员编写的程序。

(5)对测试错误结果一定要有一个确认过程。一般由A测试出来的错误,一定要有一个B来确认。

(6)制定严格的测试计划,并把测试时间安排的尽量宽松。

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

(8)妥善保存一切测试过程文档。