《软件测试52讲》中的测试基础知识详解
《软件测试52讲》
1、测试基础知识篇——(0~11讲)
2、GUI自动化测试篇——(12~21讲)
3、API自动化测试篇——(22~24讲)
4、代码测试篇——(25~27讲)
5、性能测试篇——(28~34讲)
6、测试数据准备篇——(35~38讲)
7、测试基础架构篇——(39~42讲)
8、测试新技术篇——(43~47讲)
9、测试人员的互联网架构核心知识篇——(48~52讲)
测试基础知识篇
01——你真的懂测试吗?从“用户登录”测试谈起
从“用户登录”测试谈起,“用户登录”功能作为测试对象
作为测试工程师,你的目标是要保证系统在各种应用场景下的功能是符合设计要求的,所以你需要考虑的测试用例就需要更多、更全面。
等价类划分方法,是将所有可能的输入数据划分成若干个子集,在每个子集中,如果任意一个输入数据对于揭露程序中潜在错误都具有同等效果,那么这样的子集就构成了一个等价类。后续只要从每个等价类中任意选取一个值进行测试,就可以用少量具有代表性的测试输入取得较好的测试覆盖结果。
边界值分析方法,是选取输入、输出的边界值进行测试。因为通常大量的软件错误是发生在输入或输出范围的边界上,所以需要对边界值进行重点测试,通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。
基于等价类划分和边界值分析方法,设计的测试用例
显式功能性需求和非功能性需求
显式功能性需求:软件本身需要实现的具体功能
非功能性需求:安全性、性能、兼容性
安全性测试用例包括:
1、用户密码后台存储是否加密;
2、用户密码在网络传输过程中是否加密;
3、密码是否具有有效期,密码有效期到期后,是否提示需要修改密码;
4、不登录的情况下,在浏览器中直接输入登录后的URL地址,验证是否会重新定向到用户登录界面;
5、密码输入框是否不支持复制和粘贴;
6、密码输入框内输入的密码是否都可以在页面源码模式下被查看
7、用户名和密码的输入框中分别输入典型的“SQL注入攻击”字符串,验证系统的返回页面;
8、用户名和密码的输入框中分别输入典型的“XSS跨站脚本攻击”字符串,验证系统行为是否被篡改;
9、连续多次登录失败情况下,系统是否会阻止后续的尝试以应对暴力破解;
10、同一用户在同一终端的多种浏览器上登录,验证登录功能的互斥性是否符合设计预期;
11、同一用户先后在多台终端的浏览器上登录,验证登录是否具有互斥性。
性能压力测试用例包括:
1、单用户登录的响应时间是否小于3秒;
2、单用户登录时,后台请求数量是否过多;
3、高并发场景下用户登录的响应时间是否小于5秒;
4、高并发场景下服务端的监控指标是否符合预期;
5、高集合点并发场景下,是否存在资源死锁和不合理的资源等待;
6、长时间大量用户连续登录和登出,服务器端是否存在内存泄露。
兼容性测试用例包括:
1、不同浏览器下,验证登录页面的显示以及功能正确性;
2、相同浏览器的不同版本下,验证登录页面的显示以及功能正确性;
3、不同移动设备终端的不同浏览器下,验证登录页面的显示以及功能正确性;
4、不同分辨率的界面下,验证登录页面的显示以及功能正确性。
测试的不可穷尽性,即绝大多数情况下,是不可能进行穷尽测试的。“穷尽测试”,是指包含了软件输入值和前提条件所有可能组合的测试方法,完成穷尽测试的系统里应该不残留任何未知的软件缺陷。
在绝大多数的软件工程实践中,测试由于受限于时间成本和经济成本,是不可能去穷尽所有可能的组合的,而是采用基于风险驱动的模式,有所侧重地选择测试范围和设计测试用例,以寻求缺陷风险和研发成本之间的平衡。
02——如何设计一个“好的”测试用例“
好的”测试用例必须具备哪些特征?
在具体的用例设计时,首先需要搞清楚每一个业务需求所对应的多个软件功能需求点,然后分析出每个软件功能需求点对应的多个测试需求点,最后再针对每个测试需求点设计测试用例。
具体到测试用例设计本身的设计,两个关键的点:
1、从软件功能需求出发,全面地、无遗漏地识别出测试需求是至关重要的,这将直接关系到用例的测试覆盖率。
2、对于识别出的每个测试需求点,需要综合运用等价类划分、边界值分析和错误推测方法来全面地设计测试用例。
用例设计的其他经验
1、只有深入理解被测试软件的架构,你才能设计出”有的放矢“的测试用例集,去发现系统边界以及系统集成上的潜在缺陷。
2、必须深入理解被测软件的设计与实现细节,深入理解软件内部的处理逻辑。
3、需要引入需求覆盖率和代码覆盖率来衡量测试执行的完备性,并以此为依据来找出遗漏的测试点。
03——什么是单元测试?如何做好单元测试
单元测试
单元测试是批,对软件中的最小可测试单元在与程序其他部分相隔离的情况下进行检查和验证的工作,这里的最小可测试单元通常是指函数或者类。
如何做好单元测试?
第一,代码的基本特征与产生错误的原因
第二,单元测试用例详解(单元测试的用例是一个“输入数据”和“预计输出”的集合。)
第三,驱动代码,桩代码和Mock代码(驱动代码是用来调用被测函数的,而桩代码和Mock代码是用来代替被测函数调用的真实代码的。)
驱动代码、桩代码和Mock代码三者的逻辑关系。
驱动代码(Driver)指调用被测函数的代码,在单元测试过程中,驱动模块通常包括调用被测函数前的数据准备、调用被测函数以及验证相关结果三个步骤。
桩代码(Stub)是用来代替真实代码的临时代码。
Mock代码和桩代码的本质区别是:测试期待结果的验证(Assert and Expectiation)
实际项目中如何开展单元测试?
1、并不是所有的代码都要进行单元测试,通常只有底层模块或核心模块的测试中才会采用单元测试。
2、你需要确定单元测试框架的选型,这和开发语言直接相关。Java(Junit和TestNG),Python(Pytest、Unitest)
3、为了能够衡量单元测试的代码覆盖率,通常你还需要引入计算代码覆盖率的工具。Java(JaCoCo)
4、最后你需要把单元测试执行、代码覆盖率统计和持续集成流水线做成集成,以确保每次代码递交,都会自动触发单元测试,并在单元测试执行过程中自动统计代码覆盖率,最后以“单元测试通过率”和“代码覆盖率”为标准来决定本次代码递交是否能够被接受。
04——为什么要做自动化测试?什么样的项目适合做自动化测试
自动化测试
自动化测试是,把人对软件的测试行为转化为由机器执行测试行为的一种实践
什么样的项目适合自动化测试?
第一,需求稳定,不会频繁变更
第二,研发和维护周期长,需要频繁执行回归测试
第三,需要在多种平台上重复运行相同测试的场景
第四,某些测试项目通过手工测试无法实现,或者手工成本太高
第五,被测软件的开发较为规范,能够保证系统的可测试性
第六,测试人员已经具备一定的编程能力
第六点的阻力:
(1)前期的学习成本通常会比较大,很难在短期内对实际项目产生实质性的帮助,此时如果管理层对自动化测试没有正确的预期,很可能会叫停自动化测试;
(2)测试工程师通常会非常热衷于学习使用自动化测试技术,以至于他们的工作重点会发生错误的偏移,把大量的精力放在自动化测试技术的学习与实践中,而忽略了测试用例的设计,这将直接降低软件整体的质量。
05——你知道软件开发各阶段都有哪些自动化测试技术吗?
单元测试的自动化技术
第一,用例框架代码生成的自动化
第二,部分测试输入数据的自动化生成
第三,自动桩代码的生成
第四,被测代码的自动化静态分析
静态分析主要指代码的静态扫描,目的是识别出违反编码规则或编码风格的代码行。目前比较常用的代码静态分析工具有Sonar和Coverity等
第五,测试覆盖率的自动统计与分析
Web Service测试的自动化技术
Web Service测试,主要是指SOAP API和REST API这两类API测试,最典型的是采用SoapUI或Postman等类似的工具。但这类测试工具基本都是界面操作手动发起Request并验证Response,
所以难以和CI/CD集成,于是就出现了API自动化测试框架。
Web Service测试自动化包括:
第一,测试脚本架代码的自动化生成
第二,部分测试输入数据的自动生
第三,Response验证的自动化
Response验证自动化的核心思想是自动比较两次相同API调用的返回结果,并自动识别出有差异的字段值,比较过程可以通过规则配置去掉诸如时间戳、会话ID(Session ID)等动态值。
第四,基于SoapUI或者Postman的自动化脚本生成
GUI测试的自动化技术
GUI自动化测试主要分为两大方向:传统Web浏览器和移动端原生应用(Native Appp)的GUI自动化。附加(小程序)
传统Web浏览器的GUI自动化测试:Selenium、Puppteer
移动端原生应用:Appium
06——你真的懂测试覆盖率吗?
测试覆盖率
测试覆盖率通常被用来衡量测试的充分性和完整性,从广义的角度来讲,测试覆盖率主要分为两大类,一类是面向项目的需求覆盖率,另一类是更偏向技术的代码覆盖率。
需求覆盖率
需求覆盖率是指测试对需求的覆盖程度,通常的做法是将每一条分解后的软件需求和对应的测试建立一对多的映射关系,最终目标是保证测试可以覆盖每个需求,以保证软件产品的质量。
代码覆盖率
代码覆盖率是批至少被执行了一次的条目数占整个条目数的百分比。
三种代码覆盖率指标
代码覆盖率的价值
统计代码覆盖率的根本目的是找出潜在的遗漏测试用例,并有针对性的进行补充,同时还可以识别出代码中那些由于需求变更等原因造成的不可达的废弃代码。
代码覆盖率的局限性
总结来讲,高的代码覆盖率不一定能保证软件的质量,但是低的代码覆盖率一定不能保证软件的质量。
代码覆盖率工具
JaCoCo是一款Java代码的主流开源覆盖率工具
Javascript的代码覆盖率:JSCoverage和Istanbul
07——如何高效填写软件缺陷报告?
一份高效的缺陷报告主要由哪些部分组成及各部分的关键点。
1、缺陷标题
缺陷标题通常是别人最先看到的部分,是对缺陷的概括性描述,通常采用“在什么情况下发生了什么问题”,的模式。
2、缺陷概述
缺陷概述通常会提供更多概括性的缺陷本质与现象的描述,是缺陷标题的细化。
3、缺陷影响
4、环境配置
5、前置条件
6、缺陷重现步骤
7、期望结果和实际结果
8、优先级(Priority)和严重程度(Severity)
9、变通方案(Workaround)
10、根原因分析(Root Cause Analysis)
11、附件(Attachment)
08——以终为始,如何才能做好测试计划?
一份好的测试计划要包括:
1、测试范围
明确“测什么”和“不测什么”
2、测试策略
明确“先测什么后测什么”和“如何来测”
(1)功能测试(2)兼容性测试(3)性能测试 等
3、测试资源
明确“谁来测”和“在哪里测”
4、测试进度
明确开始时间、所需工作量、预计完成时间、上线发布时间
行为驱动开发,BDD,最典型的框架是“Cucumber”
5、测试风险预估
明确如何有效应地各种潜在的变化
09——软件测试工程师的核心竞争力是什么?
测试开发岗位的核心其实是“测试”,“开发”的目的是更好地服务于测试
传统测试工程师的核心竞争力
1、测试策略设计能力
(1)测试要具体执行到程度;
(2)测试需要借助于什么工具;
(3)如何运用自动化测试以及自动测试框架,以及如何选型;
(4)测试人员资源如何合理分配;
(5)测试进度如何安排;
(6)测试风险如何应对。
2、测试用例设计能力
提高测试用例设计能力,平时要多积累,对常见的缺陷模式、典型的错误类型以及遇到过的缺陷,不断总结、归纳、举一反三。
3、快速学习能力
4、探索性测试思维
5、缺陷分析能力
6、自动化测试技术
7、良好的沟通能力
测试开发工程师的核心竞争力
1、测试系统需求分析能力
2、更宽广的知识体系
10——软件测试工程师需要掌握的非测试知识有哪些?
1、网站架构的核心知识
2、容器技术
Docker和Kubernetes
3、云计算技术
Sauce Labs 测试执行环境公有云服务
Appium+Selenium Grid集群 搭建移动终端设备的测试执行私有云
4、DevOps思维
Jenkins
5、前端开发技术
11——互联网产品的测试策略应该如何设计?
发布流程通常包含了代码静态扫描、单元测试、编译、打包、上传、下载、部署和测试的全流程
传统软件产品的测试策略设计
互联网产品的测试策略设计
互联网产品的菱形测试策略(重量级API测试、轻量级GUI测试、轻量级单元测试)
1、以中间层的API测试为重点做全面的测试。
2、轻量级的GUI测试,只覆盖最核心直接影响主营业务流程的E2E场景。
3、最上层的GUI测试通常利用探索式测试思维,以人工测试的方式发现尽可能多的潜在问题。
4、单元测试采用“分而治之”的思想,只对那些相对稳定并且核心的服务和模块开展全面的单元测试,而应用层或者上层业务只会做少量的单元测试。
上一篇: 软件测试中的风险分析及应对策略
下一篇: 软件测试的基本概念和常见知识
推荐阅读
-
如何评估软件测试中的质量风险?记住以下 5 个核心要点
-
5.1.3 边界值法--二元基本边界值分析 边界值测试的另一个关键假设是,故障很少是由两个(或两个以上)缺陷同时出现造成的,这在可靠性理论中称为 "单一缺陷 "假设。基于 "单一缺陷 "假设的边界值测试称为基本边界值分析。 在边界值测试中,我们通常使用两值边界,然后辅助以正常值来设计输入变量的值。 对于只有 x 和 y 两个输入变量的软件,输入域在二维坐标系中呈阴影状。使用基本边界值分析法得到的测试用例就是黑点所在的位置,总共有九个测试用例。 如果有一个 n 变量的软件输入域,则选择其中一个变量略小于最小值、最小值、正常值、最大值和略大于最大值这五个值,其余全部取正常值。对这个 n 个变量的软件输入域进行边界值分析,可产生 4n+1 个测试用例。 三值基本边界值分析
-
软件开发中的形式主义 - 单元测试
-
什么是可用性测试?有效性(Effectiveness)-- 用户完成特定任务和实现特定目标的正确性和完整性程度;效率(Efficiency)-- 用户完成任务的正确性和完整性程度与所用资源(如时间)之比;满意度(Satisfaction)-- 用户在使用产品时的主观满意度和接受程度。 2.如何获得可用性? 可以参考以下原则:Gould、Boies 和 Lewis(1991 年)为以用户为中心的设计定义了 4 个重要原则: 早期以用户为中心:设计者应在设计过程的早期就努力了解用户的需求。 综合设计:设计的所有方面都应同步发展,而不是按顺序进行。使产品的内部设计始终与用户界面的需求保持一致。 早期和持续测试:当今唯一可行的软件测试方法是经验主义方法,即如果实际用户认为设计可行,该设计就是可行的。通过在整个开发过程中引入可用性测试,用户就有机会在产品推出之前对设计提出反馈意见。 迭代设计:大问题往往掩盖了小问题的存在。设计人员和开发人员应在整个测试过程中对设计进行迭代。 3...什么是可用性测试? 可用性测试是根据可用性标准对图形用户界面进行的系统评估。 可用性测试是衡量用户与系统(网站、软件应用程序、移动技术或任何用户操作设备)交互时的体验质量。4.如何进行可用性测试? l 实验室实验
-
软件设计中的可用性和可用性测试
-
纯干货分享 | 研发效能提升——敏捷需求篇-而敏捷需求是提升效能的方式中不可或缺的模块之一。 云智慧的敏捷教练——Iris Xu近期在公司做了一场分享,主题为「敏捷需求挖掘和组织方法,交付更高业务价值的产品」。Iris具有丰富的团队敏捷转型实施经验,完成了企业多个团队从传统模式到敏捷转型的落地和实施,积淀了很多的经验。 这次分享主要包含以下2个部分: 第一部分是用户影响地图 第二部分是事件驱动的业务分析Event driven business analysis(以下简称EDBA) 用户影响地图,是一种从业务目标到产品需求映射的需求挖掘和组织的方法。 在软件开发过程中可能会遇到一些问题,比如大家使用不同的业务语言、技术语言,造成角色间的沟通阻碍,还会导致一些问题,比如需求误解、需求传递错误等;这会直接导致产品的功能需求和要实现的业务目标不是映射关系。 但在交付期间,研发人员必须要将这些需求实现交付,他们实则并不清楚这些功能需求产生的原因是什么、要解决客户的哪些痛点。研发人员往往只是拿到了解决方案,需要把它实现,但没有和业务侧一起去思考解决方案是否正确,能否真正的帮助客户解决问题。而用户影响地图通常是能够连接业务目标和产品功能的一种手段。 我们在每次迭代里加入的假设,也就是功能需求。首先把它先实现,再逐步去验证我们每一个小目标是否已经实现,再看下一个目标要是什么。那影响地图就是在这个过程中帮我们不断地去梳理目标和功能之间的关系。 我们在软件开发中可能存在的一些问题 针对这些问题,我们如何避免?先简单介绍做敏捷转型的常规思路: 先做团队级的敏捷,首先把产品、开发、测试人员,还有一些更后端的人员比如交互运维的同学放在一起,组成一个特训团队做交付。这个团队要包含交付过程中所涉及的所有角色。 接着业务敏捷要打通整个业务环节和研发侧的一个交付。上图中可以看到在敏捷中需求是分层管理的,第一层是业务需求,在这个层级是以用户目标和业务目标作为输入进行规划,同时需要去考虑客户的诉求。业务人员通过获取到的业务需求,进一步的和团队一起将其分解为产品需求。所以业务需求其实是我们真正去发布和运营的单元,它可以被独立发布到我们的生产环境上。我们的产品需求其实就是产品的具体功能,它是我们集成和测试的对象,也就是我们最终去部署到系统上的一个基本单元。产品需求再到了我们的开发团队,映射到迭代计划会上要把它分解为相应的技术任务,包括我们平时所说的比如一些前端的开发、后端的开发、测试都是相应的技术任务。所以业务敏捷要达到的目标是需要去持续顺畅高质量的交付业务价值。 将这几个点串起来,形成金字塔结构。最上层我们会把业务目标放在整个金字塔的塔尖。这个业务目标是通过用户的目标以及北极星指标确立的。确认业务目标后再去梳理相应的业务流程,最后生产。另外产品需求包含了操作流程和业务规则,具需求交付时间、工程时间以及我们的一些质量标准的要求。 谈到用户影响的地图,在敏捷江湖上其实有一个传说,大家都有一个说法叫做敏捷需求的“任督二脉”。用户影响地图其实就是任脉,在黑客马拉松上用过的用户故事地图其实叫督脉。所以说用户影响地图是在用户故事地图之前,先帮我们去梳理出我们要做哪些东西。当我们真正识别出我们要实现的业务活动之后,用户故事地图才去梳理我们整个的业务工作流,以及每个工作流节点下所要包含的具体功能和用户故事。所以说用户影响地图需要解决的问题,我们包括以下这些: 首先是范围蔓延,我们在整张地图上,功能和对应的业务目标是要去有一个映射的。这就避免了一些在我们比如有很多干系人参与的会议上,那大家都有不同想法些立场,会提出很多需求(正确以及错误的需求)。这个时候我们会依据目标去看这些需求是否真的是会影响我们的目标。 这里提到的错误需求,比如是利益相关的人提出的、客户认为产品应该有的、某个产品经理需求分析师认为可以有的....但是这些功能在用户影响地图中匹配不到对应目标的话,就需要降低优先级或弃掉。另外,通常我们去制定解决方案的时候,会考虑较完美的实现,导致解决方案括很多的功能。这个时候关键目标至关重要,会帮助我们梳理筛选、确定优先级。 看一下用户影响到地图概貌 总共分为一个三层的结构: 第一层why,你的业务目标哪个是最重要的,为什么?涉及到的角色有哪些? 第二层how ,怎样产生影响?影响用户角色什么样的行为? (不需要去列出所有的影响,基于业务目标) 第三层what,最关键的是在梳理需求时不需一次把所有细节想全,这通常团队中经常遇到的问题。 我们用这个例子来看一下 这是一个客服中心的影响地图,业务目标是 3个月内不增加客服人数的前提下能支持1.5倍的用户数。此业务目标设定是符合 smart 原则的,specific非常的具体,miserable 是可以衡量的,action reoriented是面向活动的, real list 也是很实际的。 量化的目标会指引我们接下来的行动,梳理一个业务目标,尽量去量化,比如 :我们通过打造一条什么样的流水线,能够提高整个部署的效率,时间是原来的 1/2 。这样才是一个能量化的有意义的目标。 回到这幅图, how 层级识别出来的内容,客服角色:想要对它施加的影响,把客户引导到论坛上,帮助客户更容易的跟踪问题,更快速的去定位问题。初级用户:方论坛上找到问题。高级用户:在论坛上回答问题。通过我们这些用户角色,进行活动,完成在不增加客户客服人数的前提下支持更多的用户数量。 最后一个层级,才是我们日常接触比较多的真正的功能的特性和需求,比如引导到客户到论坛上,其实这个产品就需要有一个常见问题的论坛的链接。这个层次需要我们团队进一步地在交付,在每个迭代之前做进一步的梳理,细化成相应的用户故事。 这个是云智慧团队中,自己做的影响地图的范例,可以看下整个的层级结构。序号表示优先级。 那我们用户影响地图可以总结为:
-
刘韧工作手册(2023年版)-17 共同学习,共同进步,搭建共识。一起工作的基础,是对彼此能力的认可,继续一起工作的基础,是能力的共同提高。共同进步的基础,就是共同学习,共同学习的基础,是看过同样的书。 年轻时,男女谈恋爱,双方世界观趋同,差距不大。后来,世界观逐渐拉大,对话成了鸡同鸭讲,我讲,你听不懂。你讲,我不感兴趣,甚至闹离婚,双方自然而然走不下去了。工作也一样,同事间如果差距越来越大,最终,无法一起工作。 我为了和别人搭建共识,会处心积虑向其推荐读书。听什么歌,观什么电影,看什么书,能在一定程度了解一个人。 有人说,金庸的书是文学。我说,那是娱乐。文学是“真、善、美”,首先是要“真”,就是情感真实。而在金庸的小说里,类似“九阴真经”、“葵花宝典”的秘籍是假的,小说里的人物寻得秘籍,一夜之间就能武功猛增……这样的情节,在现实中可能吗?生活中,漂亮的富家女黄蓉会爱上傻小子郭靖吗?金庸看多了,人会追求走捷径,工作生活“走捷径”会害死自己。 18 礼物,是人际交往中的情感润滑剂。互相送礼物,增进感情。不知道买什么,就买吃的。 英国人做客,会送主人红酒、鲜花和小卡片,回家后,会写感谢信。在新加坡,朋友们来家,常带些做好的熟食,大家一起吃。 2000年,我听说谷歌在办公室给员工备吃的。当时不太理解,后来才知道,“在一起吃”这个行为,有助于消除紧张和敌意,人更容易感到温暖和轻松,更愿意敞开心扉,是社交中增进感情的好方式之一。脸书新加坡总部,午餐,公司会请高级厨师做六种风格的菜,每一道菜都做的极好,甚至比五星级酒店的饭菜都好吃。他们的员工告诉我,根本不想回家,就想在公司吃饭。 19 坦诚,不装懂,打破沙锅问到底。想当然半天,不如简单试一下。要学会积攒各种低成本测试方法,并勤快地去试。超大额跨国汇款,先汇1元,测试路径是否畅通。没有招,没有策略库,一筹莫展。 有句古话,叫“以其昏昏,使人昭昭”。很多人对“学而优则仕”这句话的理解,是典型的“以其昏昏,使人昭昭”。这句话常被人解释为“学习好了就去当官”,若照此解释,下一句“仕而优则学”只能解释为“当官当好了就去学习”!这显然说不通。这里的“优”,不是“优秀”,而是“空闲”的意思。很多人不清楚,却到处教人解释这句话。 《水浒传》是中国版的黑帮小说,讲的是厚黑学,没有道德底线。梁山人为了拉扈三娘入伙,杀光了她全家,把原本是千金小姐,花容月貌的扈三娘指婚丑陋的王英。直到今天,《水浒传》常被解释为“侠义”。 在群里,遇到信口雌黄国学的人,我会问他们,论语中,第一句话“学而时习之不亦说乎”中的“习”是什么意思?很多人解释为“复习”。其实,繁体字中,“习”的写法是“習”,下面一个“白”,上面一个“羽”,指的是“雏鸟学飞”。意思是,雏鸟利用老鸟教的技巧,终于飞起来了。因此,“习”的本意是指老师手把手把心得教给你,让你学会了,有了收获和进步,绝不是指反复“复习”和“练习”的意思。 维特根斯坦说:“凡是可说的就要说清楚,凡是不可说的就该保持沉默。”别不懂装懂。 20 善待帮助你的人。一个人能否成功,要看有没有人愿意帮你。有多大成功,要看有多少人愿意帮你。 别人发现你出错了,提醒你,这些都是你所能得到的“举手之劳”的帮助,你知道了,能改掉,你容易成长。 如何做一个有很多人愿意帮你的人呢? 首先,滴水之恩,当涌泉相报。每次收到礼物,我一定会表示感谢。 其次,得到帮助,一定要反馈。很多帮助不一定非得要你用物质来交换,可能仅仅是你要领情。我会记录所有受到的帮助,并广而告之。我写书时,会把帮助我的人都列举出来,这样做成本不高,但被提到的人会感动。 你们可以回忆一下,有多少人帮过你?如果脱口说出的人数越多,说明你离成功越近。要是发现世界上,愿意帮你的人只有父母,那就要反思了。(完) 刘韧商业写作通识
-
统计学习 04:假设检验(以 t 检验为例)和 P 值 - 要点 I. 假设检验的一般思路 假设检验 清楚你的问题是什么?期望得出什么结论? 例如,两种药物的疗效是否存在差异,自变量与因变量之间是否存在回归关系 .... 请始终牢记,假设检验回答的是是否存在某种关系的问题:它并不衡量这种关系有多大。 提出两种假设:零假设 (H0) 和备择假设 (H1) 零假设与备择假设相反,一般来说,研究的目的是证明原假设是错误的,即得出备择假设的结论。 例如,如果实验预期希望两种药物的疗效存在差异,那么 H0:μ1 - μ2 = 0;H1:μ1 - μ2 ≠ 0 H0:μ1-μ2 = 0 的一般形式称为双侧检验,而 >、<等零假设称为单侧检验。一般来说双侧检验更为常见,下面也主要介绍这种方法。 单尾或双尾测试 根据原始数据计算零假设概率分布的统计量(t 值、Z 值、F 值等)。 根据问题的性质选择合适的概率检验方法,从而计算出相应的统计量值;因此,不同情况的统计量值有不同的计算方法。 根据计算出的统计量值,利用统计软件,可以知道相应的 p 值是多少 也可以先确定一个合适的显著性水平(0.0.001....),并计算其临界值,再与我们计算出的统计量值进行比较,从而做出判断。 根据第四步的比较结果,如果 p 值小于预期的显著性水平(α,通常设定为 0.05),则认为该统计量远离原假设分布,属于小概率事件,则拒绝原假设,从而接受备择假设。 决定 要点 2:以 t 检验为例,演示上述假设检验思路。 t 检验基于 t 分布,常见的 t 检验有三种,如下图所示,但我认为第三种配对设计可能更常用(零假设:差异是否为零),下面介绍的例子就是一种配对设计 三次 t 检验 举例测量两组大鼠肝脏中维生素 A 的含量,比较两组大鼠维生素 A 含量是否有差异。数据如下 数据 (1) 预计两组大鼠的维生素 A 水平存在差异 (2) H0:μd=0,H1:μd≠0,α=0.05,双侧检验 (3) t 统计量的计算 配方 计算 上述程序计算的是*度为 7 的 t 分布情况下的 t 值。只需理解公式即可,不同的方法有不同的公式,这些交给统计软件即可。
-
玩转Kotlin性能测试:JMH入门指南一 - 测试基础" "深入理解JMH在Kotlin中的应用:基准测试实战解析" "轻松实践Kotlin基准测试:JMH工具详解与实例总结
-
软件测试详解 - 接下来的篇章:深入分析