测试理论
一、测试背景
当企业场景发展到一定程度时必然会需要测试开发,目前市场上需要测试+开发的双料人才
个人职业发展
- 功能测试人员
- 自动化测试人员
- 测试开发人员
二、软件测试
在规定条件下对程序进行操作,从而发现错误,对软件质量进行评估的一个过程
定义:
- 使用人工或自动手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求 或者 弄清预期结果和实际结果之间的差别
- 软件测试是一种实际输出与预期输出之间的审核或者比较的过程
目的:
- 为了发现错误而执行程序的过程
- 为了证明程序有错,而不是证明程序无错
- 记录软件使用过程中的一些数据,从而为决策者提供依据
- 降低开发风险
- 以最少的人力,物力和时间找出软件中潜在的各种错误与缺陷,通过修正各种错误和缺陷提高软件质量,回避软件发布后由于潜在的软件缺陷和错误造成的隐患以及带来的商业风险
三、软件测试分类
1、按照阶段划分
1.1、单元测试(Unit Testing)
单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位:模块。
- 测试阶段:编码后
- 测试对象:最小模块
- 测试人员:白盒测试工程师或开发工程师
- 测试依据:代码和注释+详细设计文档
- 测试方法:白盒测试
- 测试内容:模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
1.2、集成测试(Integration Testing)
集成测试也称为联合测试、组装测试,将程序模块采用适当的集成策略组装起来,对系统的接口及集成后的功能进行正确性检测的测试工作。主要目的是检查软件单位之间的接口是否正确
- 测试阶段:一般单元测试之后进行
- 测试对象:模块间的接口
- 测试人员:白盒测试工程师或开发工程师
- 测试依据:单元测试的模块+概要设计文档
- 测试方法:黑盒测试与白盒测试相结合
- 测试内容:模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响
补充说明: 单元测试是一个模块内部的测试,集成测试是在模块之间进行测试(至少两个)
1.3、系统测试
将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统测试执行阶段,包括回归测试和冒烟测试。
- 测试阶段:集成测试通过之后
- 测试对象:整个系统(软、硬件)
- 测试人员:黑盒测试工程师
- 测试依据:需求规格说明文档
- 测试方法:黑盒测试
- 测试内容:功能、界面、可靠性、易用性、性能、兼容性、安全性等
补充说明:
- 系统测试是从完整的角度,广面去看待问题,不再看模块
- 虽然系统测试包括冒烟测试和回归测试,但三者之间是有严格的先后顺序的,即: 先冒烟、再系统、后回归
1.4、按是否覆盖源码
黑盒测试(Black-box Testing)
黑盒测试也称功能测试,测试中把被测的软件当成一个黑盒子,不关心盒子的内部结构是什么,只关心软件的输入数据与输出数据。黑盒测试又分为功能测试和性能测试
- 功能测试
- 业务测试 :测试人员将系统的整个模块串接起来运行、模拟真实用户实际的工作流程。满足用户需求定义的功能来进行测试的过程
- 易用性 (Useability):是交互的适应性、功能性和有效性的集中体现。又叫用户体验测试。
- 界面测试 (简称UI测试):测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯,此外还要测试界面操作便捷性、导航简单易懂性,页面元素的可用性,界面中文字是否正确,命名是否统一,页面是否美观,文字、图片组合是否完美等。
- 安装测试 :是指测试程序的安装、卸载。最典型的就是APP的安装、卸载。
- 兼容性测试 :主要是指软件之间能否很好的运作,会不会有影响、软件和硬件之间能否发挥很好的效率工作,会不会影响导致系统的崩溃。例如最常见的是浏览器的兼容性测试,不同浏览器在css、js解析的不同会造成页面的不同
- 性能测试
检查系统是否满足需求规格说明书中规定的性能。 通常表现在以下几个方面:
- 对资源利用(如内存、处理机周期等)进行的精确度量
- 对执行间隔
- 日志事件(如中断,报错)
- 响应时间
- 吞吐量(TPS)
- 辅助存储区(例如缓冲区、工作区的大小等)
- 处理精度等进行的监测
白盒测试(White-box Testing)
白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒指的打开盒子,去研究里面的源代码和程序结果
灰盒测试(Gray-Box Testing)
灰盒测试,是介于白盒测试与黑盒测试之间的一种测试,灰盒测试多用于集成测试阶段,不仅关注输出、输入的正确性,同时也关注程序内部的情况
灰盒测试: 功能 + 接口
2、按是否执行程序划分
2.1、静态测试(Static testing)
静态方法是指不运行被测程序本身,仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。
- 检查项:代码风格和规则审核;程序设计和结构的审核;业务逻辑的审核;走查、审查与技术复审手册。
- 静态质量:度量所依据的标准是ISO9126。在该标准中,软件的质量用以下几个方面来衡量,即功能性(Functionality)、可靠性(Reliability)、可用性(Usability)、有效性(Efficiency)、可维护性(Maintainability)、可移植性(Portability)。
静态测试: 代码静态分析和文档测试都属于静态测试
2.2、动态测试(Dynamic testing)
动态测试方法是指通过运行被测程序,检查运行结果与预期结果的差异,并分析运行效率、正确性和健壮性等性能。这种方法由三部分组成:构造测试用例、执行程序、分析程序的输出结果。
动态测试有三部分组成:
- 构造测试用例
- 执行程序
- 分析程序的输出结果
大多数软件测试都属于动态测试。
3、按是否自动化分
3.1、手工测试(Manual testing)
手工测试就是由人去一个一个的输入用例,然后观察结果,和机器测试相对应,属于比较原始但是必须的一个步骤。优缺点:
- 优点:自动化无法替代探索性测试、发散思维类无既定结果的测试。
- 缺点:执行效率慢,量大易错。
3.2、自动化测试(Automation Testing)
就是在预设条件下运行系统或应用程序,评估运行结果,预先条件应包括正常条件和异常条件。简单说自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。
- 自动化测试有:测试自动化、性能测试自动化、安全测试自动化。(一般情况下,我们说的自动化是指功能测试的自动化)
- 自动化测试按照测试对象来分,还可以分为接口测试、UI测试等。
自动化实施的步骤:
- 完成功能测试,版本基本稳定
- 根据项目特性,选择适合项目的自动化工具,并搭建环境
- 提取手工测试的测试用例转换为自动化测试的用例
- 通过工具、代码实现自动化的构造输入、自动检测输出结果是否符合预期
- 生成自动测试报告
- 持续改进、脚本优化
4、其他
4.1、冒烟测试(Smoke Testing)
该术语来自硬件,指对一个硬件或一组硬件进行更改或修复后,直接给设备加电。如果没有冒烟,则该组件就通过了测试,也可以理解为该种测试耗时短,仅用一袋烟的功夫就足够了。
冒烟测试的目的是确认软件基本功能正常,可以进行后续正式的测试工作。冒烟测试的执行者是版本编译人。
冒烟测试一般在开发人员开发完毕后送给测试人员来进行测试时,测试人员会先进行冒烟测试,保证基本功能正常,不阻碍后续测试。
4.2、回归测试
回归测试是指修改了旧的代码之后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。 自动回归测试将大幅度降低系统测试、维护升级等阶段的成本。
在整个软件测试过程中占有很大的工作比重,软件开发的各个阶段都会进行多次回归测试。随着系统的庞大,回归测试的成本越来越大,通过正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。
4.3、随机测试
随机测试主要是根据测试者的经验对软件进行功能和性能抽查。
根据测试说明书执行用例测试的重要补充手段,是保证测试覆盖完整性的有效方式和过程。
随机测试主要是对被测软件的一些重要功能进行复测,也包括测试那些当前的测试用例(TestCase)没有覆盖到的部分。
4.4、验收测试
验收测试是部署软件之前的最后一个测试操作, 也称为交付测试。验收测试的目的是确保软件准备就绪,按照项目合同、任务书、双方约定的验收依据文档,向软件购买者展示该软件系统满足原始需求。
- 测试阶段:系统测试通过之后
- 测试对象:整个系统(包括软硬件)。
- 测试人员:主要是最终用户或者需求方。
- 测试依据:用户需求、验收标准
- 测试方法:黑盒测试
- 测试内容:同系统测试(功能… 各类文档等)
验收测试按照实施的组织不同分为: α测试 和 β测试
α测试(内测)
- α测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试。
- α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。
- 大型通用软件,在正式发布前,通常需要执行Alpha和Beta测试。α测试不能由程序员或测试员完成。
β测试(公测)
- Beta测试是一种验收测试。Beta测试由软件的最终用户们在一个或多个客房场所进行。
α测试与β测试的区别
- 测试的场所不同:Alpha测试是指把用户请到开发方的场所来测试,beta测试是指在一个或多个用户的场所进行的测试。
- Alpha测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。beta测试的环境是不受开发方控制的,用户数量相对比较多,时间不集中。
- alpha测试先于beta测试执行。通用的软件产品需要较大规模的beta测试,测试周期比较长。
三、软件开发模型
软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段,有时也包括维护阶段。 软件开发模型能清晰、直观地表达软件开发全过程,明确规定了要完成的主要活动和任务,用来作为软件项目工作的基础。对于不同的软件系统,可以采用不同的开发方法、使用不同的程序设计语言以及各种不同技能的人员参与工作、运用不同的管理方法和手段等,以及允许采用不同的软件工具和不同的软件工程环境。
软件开发过程模型:是软件开发人员在公司里工作的过程。
敏捷开发
- 敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。
- 在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。
优点:
- 敏捷开发的高适应性,以人为本的特性。
- 更加的灵活并且更加充分的利用了每个开发者的优势,调动了每个人的工作热情。
缺点:
- 由于其项目周期很长,所以很难保证开发的人员不更换,而没有文档就会造成在交接的过程中出现很大的困难。
四、测试模型
软件测试和软件开发一样,都遵循软件工程原理,遵循管理学原理,所以理解好软件的开发模型会便于理解测试模型。
软件测试的一般流程:
V模型
V模型中的过程从左到右,描述了基本的开发过程和测试行为。
优点:
- 每一个阶段都清晰明了、便于控制开发的每一个过程
- 既包含单元测试又饱含系统测试
缺点:
- 测试介入的较晚,对于前期的一些缺陷无从发现和修改
- 测试和开发串行
W模型
V模型的局限性在于没有明确地说明早期的测试,无法体现“尽早地和不断地进行软件测试” 的原则。在V模型中增加软件各开发阶段应同步进行的测试,演化为W 模型(如下图)。在模型中不难看出,开发是“V”,测试是与此并行的“V”。
W模型是V模型的发展,强调的是测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求、功能和设计同样要测试。测试与开发是同步进行的,从而有利于尽早地发现问题。
优点:
- 测试伴随软件的整个生命周期,例如,在需求分析结束后就可以进行需求分析测试
- 测试于开发是并行独立进行
缺点:
- 对需求和测试技术要求高
- 适用于大中型企业
五、项目管理工具
项目管理工具(一般指软件)是为了使工作项目能够按照预定的成本、进度、质量顺利完成,而对人员(People)、产品(Product)、过程(Process)和项目(Project)进行分析和管理的一类软件。
常用项目管理工具
TAPD
- TAPD(Tencent Agile Product Development)腾讯敏捷协作平台,是一款由腾讯公司自主研发的协作及软件研发管理平台。
云效
- 云效,创立于2012年 ,是阿里巴巴旗下一站式研发提效平台。通过项目流程管理和专项提效自动化工具 ,真正实现24小时持续集成持续交付。
teambition
- Teambition是国内团队协作工具的创导者 ,通过帮助团队轻松共享和讨论工作中的任务、文件、分享、日程等内容,让团队协作焕发无限可能。





浙公网安备 33010602011771号