软件测试52讲学习笔记(一)-测试基础知识
一、测试用例设计
不仅要考虑显性功能的用例设计,还要考虑非显性如安全性、兼容性和性能的需求。
二、如何设计好测试用例
好的用例衡量标准并不是发现缺陷,而是取决于测试用例设计的完备性,好的测试用例一定是能覆盖所有等价类以及各种边界值。
测试用例设计方法有很多种,但常用的主要是等价类法、边界值法和错误推测法,边界值法也可以说是等价类方法的扩展。
要设计好测试用例,要从软件的功能需求出发,只有全面了解业务,从业务中提取出测试需求,再采用测试用例设计方法设计出完备的测试用例集。
如用户登录功能的等价类设计,首先就要对用户名和密码进行等价类和无效等价类的划分,无效等价类可以采用错误推测法如用户名包含特殊字符。在划分好等价类后,要采用边界值法对两个输入项设计测试用例,如用户名为空,用户名刚好大于允许的长度等。
三、什么是单元测试?如何做好?
单元测试的概念:
对软件中的最小单元通常是指函数或类进行测试,一般是由开发工程师完成的。单元测试的具体表现形式就是对函数以各种不同输入参数的组合来调用。
单元测试的对象是代码,要做好单元测试得了解代码的基本特征和产生错误的原因,知道什么是驱动代码、桩代码和MOCK代码。
单元测试的具体实践过程:
要确定好输入,并根据逻辑功能确定好预期的输出,输出不能根据阅读开发的代码来推算而要根据需要的逻辑来确定。
通常的单元测试数据输入有以下几种:
- 被测试函数的输入参数;
- 被测试函数内部需要读取的全局静态变量;
- 被测试函数内部需要读取的成员变量;
- 函数内部调用子函数获得的数据;
- 函数内部调用子函数改写的数据;
- 嵌入式系统中,在中断调用时改写的数据;
常见的输出有:
- 被测试函数的返回值;
- 被测试函数的输出参数;
- 被测试函数所改写的成员变量;
- 被测试函数所改写的全局变量;
- 被测试函数中进行的文件更新;
- 被测试函数中进行的数据库更新;
- 被测试函数中进行的消息队列更新;
驱动代码是指调用被测函数的代码,桩代码和MOCK代码是指代替真实代码的临时代码。
如测试A函数,A函数内部调用了未开发完成的B函数,此时就可以用一个假的B函数来代替真实函数,这个假的B函数就是桩函数。
桩代码和MOCK代码的区别是对测试结果的验证:
桩代码主要侧重控制被调函数的执行路径,对测试结果的验证主要在驱动代码中。
MOCK主要侧重是否调用MOCK方法,以什么参数调用,调用次数和多个mock函数的调用顺序等,对测试结果的验证主要在mock代码中。
在实际工程中,主要是底层模块或核心模块才会采用单元测试。
单元测试框架和开发语言有关,如JAVA常见的有Junit和TestNG,C/C++常用的有CppTest,具体的框架选型由开发和测试架构师决定。
衡量单位测试的代码覆盖率也会引入计算代码覆盖率的工具,如JAVA的JaCoCO等。
四、为什么要做自动化测试?
自动化测试的优势
- 替代大量重复的手工操作
- 适合敏捷开发,提升回归测试效率
- 实现手工测试无法实现的场景,如持续运行的系统稳定性测试和高并发测试场景
- 保证每次测试执行的一致性,避免遗漏
自动化测试的劣势
- 并不能取代手工测试,不能应对被测系统的变化
- 开发和维护成本高,特别是初期开发效率很低
- 手工测试发现的缺陷远比自动化测试多
- 自动化测试的用例设计质量决定着测试效率
- 若测试工程师没有编程能力,自动化测试实行起来很困难
- 业务测试和自动化测试结合才能高效开展测试
自动化测试适合什么项目
- 需求稳定
- 研发和维护周期长,需要频繁进行回归测试
- 需要在多种平台上重复运行相同测试的场景
- 某些测试项目通过手工测试无法实现,或者手工成本太高
- 被测软件开发规范,有可测性
- 测试人员具有编程能力
如果维护自动化测试的代价高过了节省 的测试成本,那么在这样的项目中推进自动化测试就会得不偿失。
五、开发各阶段的自动化测试技术?
单元测试阶段
- 框架代码的自动化生成
- 部分测试数据的自动化生成
- 自动桩代码生成
- 被测代码的自动静态分析
- 测试覆盖率的自动统计
web service:
API自动化测试
测试脚手架代码自动生成:api调用,测试数据和脚本分离
测试数据的自动生成
response验证自动化
基于工具如postman的自动化
GUI测试
- web自动化 selenium
- app自动化 appium
六、测试覆盖率
需求覆盖率
将软件需求转化为测试需求,基于测试需求来设计测试点,这就是基于需求的测试覆盖率。
代码覆盖率
至少被执行力一次的条目数占整个条目数的百分比,条目数可以是语句、函数、路径,三种覆盖率指标如下:
行覆盖率(语句覆盖率):已经被执行的语句占总语句的百分比,语句不包含头文件、代码注释和空行等。
判定覆盖(分支覆盖):测试每个判断的取真分支和取假分支,如if(a>0&&b>0),就是a>0&&b>0为true和false。
条件覆盖:测试每个条件的可能取值,如if(a>0&&b>0),就是a>0为true、false各一次和b>0为true、false各一次。
统计代码覆盖率的根本目的是找出潜在的遗漏测试用例,可以识别出需求变更等原因产生的废弃代码。
高代码覆盖率不一定能保证软件的质量,但低代码覆盖率一定不能保证。
常用的代码覆盖率工具有JaCoCo,是一款Java代码的开源覆盖率工具。
七、如何高效填写测试缺陷?
高效的缺陷报告要包含哪些内容
缺陷标题:尽量简洁,要具体说明问题,如商品金额输入可以输入英文就不要说商品金额输入有问题或者可以输入英文,而是直接描述商品金额没有对输入内容做校验。
缺陷概述:细化标题,描述问题本质。
缺陷影响:缺陷的影响范围和严重程度。
环境配置:如浏览器、操作系统和被测软件版本等,一般只描述重现缺陷的敏感信息,如浏览器不兼容时就重点描述是哪个浏览器。
前置条件:主要描述该测试步骤开始前的系统状态,不用太详细描述实现该状态的操作步骤。
重现步骤:可重现性,去掉非必要步骤,对测试数据进行描述。
期望结果和实际结果:描述期望要说明应该发生什么,不发生什么;实际结果要说清楚发生了什么,而不是说没有发生什么。
优先级和严重程度:优先级指修复缺陷的紧急程度,严重程度是缺陷对产品的影响程度。优先级会随着项目进度变动,严重程度一般确定了就不会变。先级和严重程度是没有关系的,像有些严重的缺陷会由于修复成本大等而优先级低;有些缺陷对用户影响不大,但可能会影响测试工作,那么优先级就高。
根原因分析(RCA):发现缺陷的同时定位出问题的根本原因,可以给开发清晰地反馈产生缺陷的原因。
附件:截图、日志等证明缺陷的证据,测试数据等。
八、如何做好测试计划?
随着敏捷开发的模式出现,现在的测试计划已经不像传统意义上的一次性集中制定的文档,而是体现在每一轮迭代里的短期测试计划。
明确测试范围:测哪些,不测哪些。
明确测试策略:测试顺序和如何测试。
明确测试的重点,先测哪些后测哪些。
测试方法,具体的实施,如功能测试、兼容性测试、性能测试等。
明确测试资源:测试人员和测试环境。
明确测试进度:测试的开始时间,所需工作量,预计完成时间。
测试风险预估:如需求变更,要重新进行测试需求分析,确定变更后的测试范围,重新评估测试进度。
九、测试工程师的核心竞争力
传统测试工程师
1、测试策略设计能力
测试具体要执行到什么程度?
测试需要借助什么工具?
如何运用自动化测试以及自动化测试框架,如何选型?
测试人员资源如何合理分配?
测试进度如何安排?
测试风险如何应对?
2、测试用例设计能力
熟悉业务领域的测试用例设计,把系统性的测试设计方法和具体业务结合。
积累常见的缺陷模式、错误类型,遇到过的缺陷,形成体系化的用例设计思维。
3、快速学习能力
对不同业务需求和功能的快速学习能力
对测试新技术和方法的学习能力
学习新知识时可以寻找知识源头,不被网上参差不齐的信息所影响;学习东西不要浮于表面,只去学操作使用,而是要去学习它的原理。
4、探索性测试思维
通过学习被测系统,结合基于自己经验的错误猜测和逻辑推理,分析出更多的有针对性地测试点,帮助实现“精准测试”。精准测试可以理解为针对开发代码的变更,有针对性的对变更点及关联点执行测试。
5、缺陷分析能力
针对已发生的缺陷,可以预测及定位缺陷发生的原因,结合错误上下文日志等,可以明确指出错误的代码行。
根据已发生的缺陷,结合探索性思维可以找出相关的潜在缺陷。
可以针对一段时间内发生的缺陷和趋势,分析出整体的质量,对高频缺陷类型进行发现和预防,由此来调整后续的测试策略。
6、自动化测试技术
7、沟通能力
和开发沟通,确保缺陷及时修复和验证。
和产品、项目经历沟通,确保需求的正确实现和项目质量达标。
测试开发工程师
1、代码开发能力
2、测试系统需求分析能力
不是纯粹的开发一个系统,而是要理解产品要更好地为测试服务。
3、宽广的知识体系
要理解测试架构部署和生产架构部署,测试平台常常需要接入到CI/CD的流水线和运维的监控系统。
十、测试工程师需要了解的非测试知识
小到 Linux/Unix/Windows 操作系统的基础知识,Oracle/MySQL 等传统关系型数据库技 术,NoSQL 非关系型数据库技术,中间件技术,Shell/Python 脚本开发,版本管理工具与 策略,CI/CD 流水线设计,F5 负载均衡技术,Fiddler/Wireshark/Tcpdump 等抓包工具, 浏览器 Developer Tool 等; 大到网站架构设计,容器技术,微服务架构,服务网格(Service Mesh),DevOps,云计 算,大数据,人工智能和区块链技术等
容器技术Docker概念 Docker官网教程
云计算技术 理解服务在云端部署的细节,知道如何使用云提供的基础设施和各类服务(数据库服务、配置服务等),可以尝试用云服务去部署自己的应用,用云平台建立自己的小应用集群,在云平台上直接使用 Docker 部署发布你的服务。
Devops思维
DevOps 强调的是,开发、测试和运维等组织团队之间,通过高效自动化工具的协作和沟通, 来完成软件的全生命周期管理,从而实现更频繁地持续交付高质量的软件,其根本目的是要提升 业务的交付能力。
可以从深入掌握 Jenkins 之类的工具开始,到熟练应用和组合各种 plugin 来完成灵活高效的流水线搭建,之后再将更多的工具逐渐集成到流水线中以完成更多的任务,能够将各个工具有机结合,提供高效的 CI/CD 流水线。