软件测试52讲-笔记
2019-01-28 16:15:58 2 举报AI智能生成
软件测试52讲读书笔记
作者其他创作
大纲/内容
28-带你一起解读不同视角的软件性能与性能指标
不同类型的系统，软件性能点关注的是什么
web类应用和手机端应用，一般以终端用户感受到的端到端的响应时间来描述系统的性能
非交互式应用，响应时间关注更多的是事件处理的速度，以及单位时间的事件吞吐量
软件系统性能
终端用户
系统运维人员
软件设计开发人员
性能测试人员
05-软件测试技术
单元测试
用例框架代码生成的自动化
部分测试输入数据的自动化生成
自动桩代码的生成
被测代码的自动化静态分析
测试覆盖率的自动统计与分析
代码级集成测试
指将已经开发完成的软件放在一起测试
跟单元测试的区别：代码级集成测试中被测函数内部调用其他函数必须是真实的，不允许使用桩代码替代，而单元测试中允许使用桩代码来模拟内部调用的其他函数。
web service测试
主要指Soap API和REST API测试，典型的是采用soapUI或postman等类似的工具，但这类工具基本都是界面操作手动发起request并验证response，所以难以和CI／CD集成。 于是出现了API自动化测试框架。
API测试用例包含三大步骤
准备API调用时需要的测试数据
准备API的调用参数并发起API的调用
验证API调用的返回结果
内涵包括
测试脚手架代码的自动化生成
部分测试输入数据的自动生成
response验证的自动化
基于soapUI或者postman的自动化脚本
GUI测试
06-测试覆盖率
面向项目的需求覆盖率
指测试对需求的覆盖程度。
偏向技术的代码覆盖率
指至少被执行了一次的条目数占整个条目数的百分比
语句覆盖率：已经执行的语句占总执行语句的百分比。
分支覆盖率：每个判断的取真分支和取假分支是否各被至少覆盖了一次。
条件覆盖：判定中的每个条件值至少满足一次，度量判定中国年的每个条件的true 和 false是否都被测试到了。
价值
根本目的：找出潜在的遗漏的测试用例，并针对性的进行补充，同时还可以识别出代码中那些由于需求变更等原因造成的不可达的废弃代码。
代码覆盖率反映的仅仅是哪些逻辑被执行到了，哪些没有被执行到。 对于那些压根还没有代码实现的部分，基于代码覆盖率的统计指标就无能为力了。
未考虑某些输入
未处理某些情况
代码覆盖率工具
jaCoCo
总结：高的代码覆盖率不一定能保证软件质量，但低的代码覆盖率一定不能保证软件的质量。
07-高效填写软件缺陷报告
好的缺陷报告绝对不是大量信息的堆叠，而是以高效的方式提供准确有用的信息。
报告组成
缺陷标题
概括性描述，通常采用”什么情况下发生了什么问题“
标题应该尽可能的描述问题本质，而避免只停留在问题的表面
缺陷标题不宜过长，对缺陷更详细的描述应该放到缺陷概述里。
缺陷概述
提供更多概括性的缺陷本质与现象的描述
缺陷影响
缺陷引起的问题对用户或者对业务的影响范围以及严重程度
环境配置
比如操作系统类型，软件版本，被测软件配置信息等。
前置条件
指测试步骤开始前系统应该处在的状态。
缺陷重现步骤
缺陷报告中最核心的内容。
确保缺陷的可重现性
找到最短的重现路径
需要避免3个问题
笼统的描述，缺乏可操作性的具体步骤
出现于缺陷重现不相关的步骤
缺乏对测试数据的相关描述
期望结果和实际结果
优先级和严重程度
1.缺陷越严重，优先级就越高
2.缺陷影响范围越大，优先级也会越高
3.从用户角度影响不严重，但是影响自动化执行，这类属于典型的严重程度低，优先级高。
4.有些严重程度比较高，但是考虑修复成本以及技术难度，也会出现优先级较低的情况
变通方案
附件
08-如何做好测试计划
测试范围
明确“测什么” “不测什么”
在测试需求分析完成后进行，对测试需求分析的进一步校验。
测试策略
明确“先测什么” “如何来测”
说明要采用什么样的测试类型
功能测试
通常应该先实现主干业务流程的测试自动化
实际测试操作
先列出主要的功能测试点，并决定哪些测试点适合采用自动化测试，并且决定具体使用什么样的框架和技术
对于手工测试的测试点，决定采用什么类型的测试用例设计方法以及如何准备相关测试数据
需要评估被测软件的可测试性，如果有问题，要提前考虑变通方案或者要求开发人员提供可测试性的接口。
兼容性测试
web测试需要确定覆盖的浏览器类型和版本
移动设备测试需要确定覆盖的设备类型和具体的iOS或者android版本。
实施前提：功能基本稳定了 ，才会开始兼容性测试
性能测试
1.性能测试的实施往往要根据业务场景来决定需要开发哪些单用户脚本，脚本的开发会涉及到很多性能测试脚本特有的概念，比如思考时间，集合点 动态关联等等。
2.脚本开发完成后 还要以脚本为单位组织测试场景。
3.最后是具体场景的执行， 和自动测试功能测试不同，性能测试执行完成后性能报告的解读是整个测试过程中最关键的点。
其他测试：接口测试 集成测试 安全测试 容量验证 安装测试 故障恢复测试等
测试资源
需要明确“谁来测” “在哪里测”
测试工程师的数量
测试工程师的个人经验和能力
测试环境
建议：将具体的任务清晰的落实到每个人身上，有利于建议清晰的责任机制。
测试进度
主要描述各类测试开始的时间，所需工作量，预计完成时间，并以此为依据来建议最终产品上线发布时间。
测试风险评估
通常有需求变更 开发延期 发现重大缺陷 人员变动等都是引入项目风险的主要原因。
09-软件测试工程师的核心竞争力
功能测试工程师
测试策略设计能力
指对于各种不同的被测软件能够快速准确的理解需求，并在有限的时间和资源下，明确测试重点以及最适合的测试方法的能力。
可以解决这些问题
1.测试要具体执行到什么程度
2.测试需要借助于什么工具
3.如何运用自动化测试以及自动测试框架，以及如何选型
4.测试人员资源如何合理分配
5.测试进度如何安排
6.测试风险如何应对
测试用例设计能力
指无论对于什么类型的测试，都能色剂除高效的发现缺陷，保证产品质量的优秀测试用例
如何提高：多积累，对于常见的缺陷模式，典型的错误类型以及遇到过的缺陷，要不断的总结 归纳，才能逐渐形成体系化的用例设计思维。
快速学习能力
1.对不同业务需求和功能的快速学习与理解能力
2.对于测试新技术和新方法的学习与应用能力
探索性测试思维
指测试工程师在执行测试的过程中不断学习被测系统，同时结合给予自己经验的错误猜测和逻辑推理，整理和分析出更多的有针对性的测试关注点。
缺陷分析能力
1.对于已经发现的缺陷，结合发生错误的上下文及后台日志，可以预测或者定位缺陷发生原因，甚至可以明确指出具体出错代码行，由此可以大幅缩短缺陷的修复周期，并提高开发工程师对于测试工程师的认可及信任度
2.根据已经发现的缺陷，结合探索性测试思维，推断同类缺陷存在的可能性，并由此找出所有相关的潜在缺陷
3.对一段时间内所发生的缺陷类型和趋势进行合理分析，由点到面预估整体质量的健康状态，并能够对高频缺陷类型提供系统性的发现和预防措施，并以此调整后测试策略
自动化测试技术
自动化仅仅是手段，核心价值还是测试本身
良好的沟通能力
1.对接产品经理和项目经理，以确保需求的正确实现和项目整体质量的达标
2.要和开发人员不断的沟通协调，确保缺陷的及时修复与验证
测试开发工程师
测试系统需求分析能力
能够站在测试架构师的高度，识别出测试基础架构的需求和提高效率的应用场景
更宽广的知识体系
性能测试工程师
对于性能问题的直觉和定位能力。 需要扎实的基础理论知识和大量的时间才能培养出来。
10-软件测试工程师有哪些要掌握的非测试知识
网站架构的核心知识
容器技术
云计算技术
DevOps思维
前端开发技术
11-互联网产品的测试策略应该如何设计
传统软件的测试策略设计
互联网产品的测试策略设计
12-一个GUI测试例子
一个selenium的例子
13-效率为王：脚本与数据的解耦+page object模型
测试脚本和数据的解耦
测试脚本只有一份，其中需要输入数据的地方会用变量来代替
数据驱动
1.数据驱动很好的解决了大量重复脚本问题，实现了“测试脚本和数据的解耦”
2.数据驱动测试的数据文件中不仅可以包含测试输入数据，还可以包含测试验证结果数据，甚至可以包含测试逻辑分之的控制变量
3.数据驱动测试的思想不仅适用于GUI测试，还可以用于借口测试 API测试 单元测试等。
页面对象模型
核心理念是：
14-更接近业务的抽象：让自动化测试脚本更好的描述业务
收藏
0 条评论
下一页
为你推荐
查看更多
