Leo-Fighting的博客

测试方法抉择输入分类选等价给定范围加边界条件孤立想判定无限穷举取正交业务复杂场景法测试充分全覆盖实际设计的思路任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强必要时用等价类划分方法补充一些测试用例如果程序的功能说明中，含有输入条件的组合情况，则一开始就可选用判定表法如果程序业务复杂度比较高，则适当使用场景法补充一部分测试用例每条测试用例有唯一的测试目的提测阶段，优先做冒烟测试冒烟测试时间不超过整体测试时间的 10%；选取正向流

移动 APP概念：移动应用服务，就是针对手机这种移动连接到互联网的业务或者无线网卡业务而开发的应用程序服务设备：智能手机、平板电脑、智能手表网络：无线、WiFi平台：Andriod 、IOS移动 APP 测试与传统测试的区别用户关注点：传统web测试：屏幕大，可以同时非常多的显示信息移动 APP：屏幕小，显示信息有限，有价值信息放在主要位置场合复杂程度：传统web测试：地点、网络信号固定移动 APP：运动形态中；网络不稳定，电量问题输入种类：传统web测试：键

白盒测试知代码审查代码审查范围合格代码应该具备正确性、清晰性、规范性、一致性和高效性业务逻辑的审查算法的效率代码风格编程规则代码审查的方法：互查：在相同模块或者相近模块的编程人员之间相互检查对方的代码走查：从头到尾将写好的代码检查一遍代码审查Java 最基本语句的使用重载函数的审查内存分配和管理：确保内存的及时释放和避免缓冲区溢出程序性能的审查减少创建用户减少循环体的执行代码，能放在循环体外的代码要尽量放在循环体外提高处理异常出错的效率减少 I/O 操作时

测试执行测试执行过程主要任务确定测试用例的优先级开发测试规程并确定优先级，创建测试数据，同时也可以准备测试用例和设计自动化测试脚本根据测试规程创建测试套件，以提高测试执行的效率确认已经正确搭建的测试环境根据计划的执行顺序，通过手工或者使用测试工具来执行测试规程记录测试执行结果，以及被测软件，测试工具和测试件的标识和版本将实际结果和预期结果进行比较对实际结果和预期结果之间的差异，作为事件上报，并且进行分析与确定引起差异的原因缺陷修正后，重新进行测试活动测试准入准出准入标准：

测试设计与测试用例测试设计：将概括的测试目标转化为具体的测试条件和测试用例的一系列活动测试分析和设计的主要任务评审测试依据（需求、系统架构、设计和接口说明）评估测试依据和测试对象的可靠性通过对测试项、规格说明、测试对象行为和结构的分析，识别测试条件并确定优先级设计测试用例，并确定优先级确定测试条件和测试用例所需的必要测试数据确定测试条件依据在测试策划或者测试计划中确定的测试技术通过对策是依据与测试目标的分析，可以确定需要测试的内容，获得测试条件测试用例：通过使用在测

测试环境搭建原则搭建前确定测试目的功能测试：不需要大量数据，需要覆盖率高，测试数据要求尽量真实性能测试：可能需要大量存量数据，或者与实际硬件环境尽可能相似的硬件配置测试的软件环境尽可能模拟真实环境选用合适的操作系统与软件平台了解符合测试软件运行的最低要求及用户使用的硬件配置连接用户常用软件，避免发生冲突产品化的测试需要考虑兼容性的方案营造独立的测试环境不同项目，不同公司会对测试环境的独立性有不同的要求测试过程中尽量保证测试环境独立，不会受到其他测试人员以及项目研发人

基础知识软件概念：软件是计算机系统中，与硬件相互依存的另一部分，包括程序，数据及相关文档的完整集合程序：按事先设计的功能和性能要求执行的指令序列或者代码结构****数据：使得程序能正常操纵信息的数据结构（数据来自数据库）文档：与程序开发，维护和使用相关的图文资料， 是测试所需的依据内容特性形态特性：无形的、不可见的逻辑实体智能特性：是复杂的智能产品，它的开发凝聚了人类的大量脑力劳动，体现了知识实践和人类的智慧，具有一定的智能。可以帮助我们解决复杂的计算、分析、判断和决策问题开发

本章来分享APP测试的内容。APP测试跟Web测试有相通之处，相关的测试策略、方法及思路等都可以运用到APP测试中。但是由于运行在不同的硬件设备上，使得APP测试又变得那么的独特。APP测试与传统测试的区别1、用户关注点传统web测试：屏幕大，可以同时非常多的显示信息移动 APP：屏幕小，显示信息有限，有价值信息放在主要位置2、场合复杂程度传统web测试：地点、网络信号固定移动 APP：运动形态中；网络不稳定，电量问题3、输入种类传统web测试：键盘、鼠标移动 A

本篇文章，来分享Bug管理的内容。现在，假设我们已经进入了这么一个阶段，测试用例写完了，可能有人用Excel写，可能也有人用禅道或者其他的管理工具来写。而且，用例已经评审过了，那就开始执行测试用例了。在执行用例的时候，可能会遇到一个问题，这个测试用例不通过，这就形成一个Bug了。Bug的定义电脑程序里的错误，而现在更是将其延伸为漏洞，错误，可改进的细节，或与需求文档存在差异的功能实现等。那么Bug 与缺陷有什么区别或者联系吗？Bug是缺陷的一种表现形式，而一个缺陷是可以引起多种Bug的。

前后用了不少的篇幅来谈测试用例，包括它的方法、编写原则与标准。本篇文章来分享关于测试用例的剩余基础知识。测试用例级别划分描述此部分内容时，以淘宝作为参考对象。1、极为重要这一级别测试用例要重点关注，是不允许出一丁点错误的。淘宝中，与支付相关的测试用例，就属于此级别的。2、重要这一级别的测试用例主要涉及的是业务功能，比如淘宝中的浏览商品，加入购物车，下单等，这些功能没有处理好，会影响到营收。3、一般这一级别的用例主要涉及查询、下载、添加等功能，比如淘宝个人信息中的添加收货地址，虽然此功

本篇文章分享用例编写的标准。1、根据公司要求的统一模板编写；有些小公司会用Excel编写测试用例，有些公司会使用商业工具，例如禅道、JIRA 等。其实工具不是最重要的，用例的要素基本相似，重点需要掌握如何写出高质量的测试用例，工具只是在提高工作效率上起到作用。2、严格按照需求说明书的功能点，以及测试计划进行用例编写，将所有涉及系统的功能点涵盖全面。3、编写测试用例要逻辑清晰、精简、避免冗余以及重复的功能测试点；这是用例编写的重点，在使用场景法进行分析时，要注意逻辑顺序，再结合等价类划分法与边界

本篇文章分享用例编写的原则。系统性对系统业务流程，要完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的相互关系。由此来说明子系统内部功能、重点功能以及它们之间的关系。连贯性对系统业务流程，要说明各子系统之间是如何连接在一起的，若需要接口，各子系统之间是否有正确的接口；如果是依靠页面链接，那么，页面的链接是否正确；而对于模块业务流程，要说明统计模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯。比如，电商网站，注册之后才能登陆，这是一个连接；登陆之后才能进行购物，这又是一个连

常用的测试用例设计方法，前面基本都介绍完了，其中等价类划分法、边界值法与场景法是最常用的。本篇文章介绍剩余两种测试方法——错误推测法与正交实验法。错误推测法基于经验和直觉推测程序中所有可能存在的错误，从而有针对性地设计测试用例的方法错误推测法的基本思想：列举出程序中所有可能的错误和容易发生错误的特殊情况，再进行选择测试用例。要使用好此方法，基于两个要素：对开发人员的开发习惯很熟悉，你能推断出这位开发人员经常会在哪些地方出错；对同类型项目业务非常熟悉因此，不建议在设计测试用例时直接使

边界值法是等价类划分法的补充，所以，它们是一对搭档。那么，判定表法有没有它的搭档呢？答案是，有的。那就是本篇文章分享的用例设计方法——因果图法。定义因果图法：一种描述输入条件的组合及每种组合对应的输出的图形化工具用来处理等价类划分和边界值考虑不到的情况，适用描述多种条件的组合，产生多个相应动作的测试方法；从程序规格说明书的描述中找出因果关系因果图法，第一时间让我联想到的是，高中数学的排列组合。关于这个联想，可能看完整篇文章后，你就有恍然大悟的感觉。基本符号在实例分析之前，有些基本的因

接下来4篇分享的测试用例方法，实际工作中不常用，但是能够为测试用例提供设计思路。首先分享的是，判定表法。等价类划分法和边界值法着重考虑输入条件，但是忽略了输入条件的各种组合、输入条件之间的相互制约关系。因此，需要判定表法和因果图法作为辅助工具，协助梳理条件间的逻辑关系。定义判定表法：分析和表述若干输入条件下，被测对象针对这些输入做出响应的一种工具在遇到逻辑复杂的业务时，可以利用判定表理清期间的逻辑关系。重要概念条件：条件桩：需求规格说明书定义的被测对象的所有输入条件项：针对条件桩

本篇文章分享一个最易学，发现 bug 效率最高的测试用例设计方法——边界值法。定义边界值法：它是对等价类划分法的补充，它不是选择等价类的任意元素，而是选择等价类边界的测试用例基本思路正好等于边界值刚刚大于边界值刚刚小于边界值特殊：0与空、N/A、Null还是之前的例子，这里有两个边界：100999边界值法就是围绕这两个边界，进行用例设计。那么涉及到的边界值：99, 100, 101, 998, 999, 1000另外一个例子，微信中的红包金额。通过图片底部文字，

本篇文章，来分享大家比较熟悉的测试用例设计方法——等价类划分法。首先，我们可以使用上一篇文章介绍的场景法来梳理业务流程。其次，根据流程中的每个节点的需求说明，使用等价来划分来设计用例。定义等价类划分：依据需求，将输入域划分为若干部分，再从每个部分中选取少数代表性数据当做测试用例，每一类的代表性数据在测试中的作用等价于这一类中的其他值。在同一个等价类中的数据，如果该测试用例通过，则代表该等价类的所有数据都通过测试，否则，都不通过测试。图片中的输入框，是一个公司的用户 ID 输入框，限制输入

从本篇文章开始，进入到测试用例设计方法的分享，第一个要分享的方法就是，场景法。相信对测试有一定基础的你会感到奇怪：用例设计方法，不是应该从等价类划分法说起吗？为什么一上来就直接说场景法呢？对，如果从浅入深的角度，应该是等价类划分，到边界值，再到场景法。这也是很多转行测试的小伙伴在回答面试题——你知道有哪些测试用例设计方法？直接就抛概念：等价类划分法、边界值法、场景法、因果图法……听你这么回答，面试官心理大概有答案了：这个面试者没有工作经验，只是在背答案而已。而实际工作中呢？先是用场景法梳理流程

本篇文章，来谈谈软件测试生命周期的第二阶段——测试计划。软件测试是有计划、有组织和有系统的软件质量保证活动，而不是随意的、松散的、杂乱的实施过程。为了规范软件测试内容、方法与过程，在对软件进行测试之前，必须创建测试计划。定义那么，什么是测试计划？测试计划，是一个叙述预定测试活动范围（测试哪些模块）、测试资源（软硬件）及进度安排的文档，它确认了测试项、被测特征、测试任务、人员安排及任何偶发事件的风险。因此，一份完整的测试计划，应包含产品概述、测试策略、测试方法、测试范围、时间安排、测试人力、

本篇文章将从软件生命周期的第一步——需求分析开始，逐步深入地讲解软件测试实战工作。需求，是软件项目研发的开始，是组建研发团队后的第一次集体参与讨论的内容，同样也是保障质量的重要一环。为了让研发团队中各个岗位的人员充分理解需求，可以组织开展需求会议，进行需求澄清。那么，在做需求澄清之前，先来了解什么是需求？图片是一个网站的简单注册模块，比如，用户名长度40个字符、密码8-16位字母、数字下划线组合等，就是需求。明白了什么是需求之后，进行需求澄清的时候，测试人员要深刻理解需求，在需求评审会议中，针对

我们生而为人，会经历出生–> 婴儿–> 少年–> 青年–> 中年–> 老年–> 死亡的生命周期同样，软件测试，也有其生命周期：需求分析测试计划测试用例设计与开发测试执行测试评估1、需求分析前面开发测试模型的文章中提到，在敏捷模型中，测试人员在需求分析阶段就开始介入。这时，测试人员对需求文档进行分解，了解需求，得出测试点与测试需求。当然，需求文档不是专门为测试而制作的，所以，需要进一步邀请产品、研发等相关负责人一起开需求评审会议，对于需求文档

W 模型W 模型：相对于 V 模型更科学，开发和测试基本并行开展，有利于及时发现问题；增加了软件各开发阶段中应同步进行的验证和确认活动，明确表示了测试和开发的并行关系。缺点：仍然把开发看成是从需求开始到编码结束的串行活动，只有上一阶段完成后，才开始下一阶段的活动，不能支持迭代，自发性以及变更调整H 模型H 模型：将测试活动分离出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来特点：1、测试是一个独立的过程;2、测试达到准入条件，才可以执行;3、测试对象是整个

敏捷模型是在互联网的快节奏下应运而生的，也是当前最为主流的开发测试模型。在V模型中，描述了基本的开发过程和测试行为，它的优点在于，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了测试各阶段和开发各阶段的对应关系。同时，它的局限性也相当明显，测试介入时间太晚，只是把测试作为编码后的一个活动，需求分析等前期产生的错误，直到后期的验收测试才能发现。虽说“亡羊补牢”，但是测试越晚介入，付出的成本代价越大。基于V模型的痛点，引入了敏捷模型。采用敏捷模型，相当于项目一诞生，就给它打了预防针。关于敏

瀑布模型，适用于结构化的软件项目，是面向过程的软件测试模型。具体的流程如图所示：项目计划：投入多少人，时间进度如何安排；需求分析：产品经理输出需求文档，项目组的人员再对这份文档进行分析，对需求进行判断、改进、完善；软件设计：开发团队根据确认后的文档进行功能设计；程序开发：代码编写；软件测试：测试团队制定测试计划，设计与开发测试用例，实施测试，总结与评估；集成维护选择瀑布模型必须满足的条件：在开发时间内需求没有或者很少变化；分析设计人员对应用领域很熟悉；低风险项目（

本篇文章主要来谈软件测试的策略。第一，关于选择测试方法：选择最合适当前项目的测试方法，在做软件测试的时候，需要根据不同的项目，不同的开发模式，开发阶段，项目的轻重缓急来选择测试方法，做好测试工作的统筹。例如一款社交软件发版比较紧张，无论如何，首先需要保证它的聊天功能是正常的。而对于频繁发版的部分，适当地考虑使用自动化技术来代替重复的手工测试。第二，角色与职责：需要在测试策略中，明确定义各个角色，以及该角色的职责。在一个项目中，有产品经理（负责输出需求文档等）、项目经理（统筹项目的规划）、开发工程师

关于软件测试的原则，有以下五点：第一，测试应尽早进行，最好是能够在需求阶段就开始介入。千里之堤毁于蚁穴，对于测试，如果越早介入，问题就能越早被发现，修改或者调整方向的成本就会越小。测试在需求阶段就介入，最严重的错误，无外乎是系统不能满足用户的需求，但是如果按照传统的瀑布模型，等到软件开发完成之后再进行测试，那么，万一偏离了方向，纠正过来的成本将是巨大的。第二，负责软件开发的人员应避免检查自己的程序。当局者迷旁观者清，自己犯的错误，往往意识不到。当我们还是学生年代的时候，自己写的作文，如果是自己

本篇文章，从第六个角度来谈软件测试的方法，按测试实施的组织划分，可以分为：α测试β测试第三方测试1、α测试α测试，是指把用户邀请到开发方的场所进行的一种测试，也可称为内测。由定义来看，α测试的测试环境是由开发方来搭建的，因此，一般来说内部搭建的测试环境，各方面的干扰因素比较少，相对性能较优。同时，α测试的用户数量相对较少，而且是统一时间进行测试，目的是评价软件产品的功能、局域化、可食用性、可靠性、性能等，为下一步的公开测试查缺补漏。微信红包在正式对外公测之前，也是邀请内部员工作为

本篇文章，从第五个角度来谈软件测试的方法，按是否运行程序划分，可以分为：静态测试动态测试1、静态测试静态测试，指不运行被测程序本身，仅通过分析或者检查源程序的语法、结构、过程、接口等来检查程序的正确性，对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错以百度登陆为例，在不运行程序时，查看登陆对应的源代码或者需求文档，检查设计登陆这一块代码的语法逻辑，是否对用户名、密码长度有限制？如何检查已注册和未注册用户？如何校验密码正确性，是否区分大小写等等。2、动态测

本篇文章，从第四个角度来谈软件测试的方法，按测试对象划分，可以分为：性能测试安全测试兼容性测试文档测试易用性测试界面测试安装测试1、性能测试性能测试，检查系统是否满足需求规格说明书中规定的性能通常表现在以下几个方面：稳定性响应时间吞吐量以淘宝的双十一来举例，在双十一这个高并发的场景下，网站的表现是否稳定？零点时分，大量下单，网站能否承受如此大的订单量，支付的响应速度是否足够快？这些都是用户关注的性能点。同样的，货车，最大

本篇文章，从第三个角度来谈软件测试的方法，按是否查看代码划分，可以分为：黑盒测试白盒测试灰盒测试1、黑盒测试黑盒测试，也是功能测试，测试中把被测的软件当成一个黑盒子，不关心盒子的内部结构是什么，只关心软件的输入数据和输出数据以登陆百度为例，输入用户名，输入密码，点击登录即可，你只是在浏览器上，看到百度的登陆页面，不需要关心内部的源代码是怎么判断你的输入的。同样的，经常使用的手机，你也只是看到它表面存在的返回键、Home键、菜单键、音量键等，按下它们，是否能给你对应的反馈

本篇文章，从第二个角度来谈软件测试的方法，按是否需要手工执行来划分，可以分为手工测试自动化测试1、手工测试指的是由人来一个一个地按照测试用例进行操作，观察结果。由此可见，手工测试，并不是漫无目的地点点点。当然，也有相应的工具能模仿这种操作，例如，移动端会使用 monkey 来模拟人对一款应用的随机点击。其次，手工测试需要依据测试用例来逐步操作，将得到的结果与预期结果进行对比。很多人觉得手工测试非常原始，在人工智能的迅猛发展下，会被淘汰。其实不然，在相对长的一段时间里，手工测

从最基本的理解，软件测试的定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程在《软件测试的艺术》一书中，作者对于软件测试的一句话定义是：测试是为发现错误而执行程序的过程由此可见，软件测试，不是毫无目的地进行点点点。从最初的定义中，软件测试有4个关键点：规定的条件：以测试用例作为测试的依据，测试用例可以指引测试人员逐步操作；发现程序错误：指的是找出程序中的bug；衡量软件质量：对软件质量进行评估，它到底好不好用，稳不.