回归测试

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 【Alpha测试】 Alpha测试是由用户在开发环境下进行的测试，也可以是开发机构内部的用户在模拟实际操作环境下进行的测试 测试环境受开发方控制 用户数量相对较少 时间比较集中 先于Beta测试 【Beta测试】 Beta测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。 测试环境不受开发方控制 用户数量较多 测试时间比较长 【验收测试】 验收测试是以用户为主的测试，软件开发和QA人员也应该参加，测试一般在用户所在地进行，由用户验证软件产品是否满足了所有的需求的一系列的验收测试工作 验收测试的目的是为了以发现”未实现的需求”为目的，以评估”适合使用”为目标，该类测试的不是以发现缺陷为主要目的。 【灰度测试】 灰度测试，也叫灰度发布或金丝雀发布，就是在某项产品或应用正式发布前，选择特定人群试用，逐步扩大其试用者数量，以便及时发现和纠正其中的问题。 灰度发布能及早获得用户的意见反馈，完善产品功能，提升产品质量，让用户参与产品测试，加强与用户互动，降低产品升级所影响的用户范围。 在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来 灰度发布可以保证整体系统的稳定

软件=程序+软件工程 （程序=数据结构+算法） 软件工程的核心：构建管理、源代码管理、软件设计、软件测试、项目管理。 结合企业得到的推论：软件企业=软件+商业模式。 软件工程包括的领域：软件需求分析、软件设计、软件构建、软件测试和软件维护。 软件的特殊性：复杂性、不可见性、易变性、服从性、非连续性。 软件工程的目标——创造“足够好”的软件，即包括用户的满意度、可靠性、软件流程的质量、可维护性。 什么是bug？ 简单地说，就是软件的行为和用户的期望值不一样，就叫bug。 有实际用处的同时又是完美的软件，在世界上是不存在的。 单元测试也能帮助程序员记录这个模块的历史和设计变更的理由。 单元测试应该准确、快速地保证程序基本模块的正确性。 最好是在设计的时候就写好单元测试，这样单元测试就能体现API的语句。 单元测试不能解决所有的问题，不能期望它会发现所有的缺陷。 一般情况下，单元测试中的模块可以直接引用其他的模块，并期待其他的模块能返回正确的结果。 单元测试应该覆盖所测单元的所有的代码路径，包括错误处理路径。 100%的代码覆盖并不等同于100%的正确性。 回归测试最好要自动化，因为这样就可以对每一个构建快速运行所有回归测试，单元测试是回归测试的基础。 工程师在"需求分析"和“测试”这两方面明显要花更多的时间。 如何保证质量——回归测试。 个人感受： 过去只知道，程序=数据结构+算法

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 冒烟测试，是微软首先提出来的一个概念，和微软一直提倡的每日build（构建版本）有很密切的联系。具体说，冒烟测试就是在每日build（构建版本）建立后，对系统的基本功能进行简单的测试。这种测试强调程序的主要功能进行的验证，也叫版本验证测试，提交测试。 冒烟测试 这个名称的来历，是从电路板测试得来的。因为当电路板做好以后，首先会加电测试，如果板子没有冒烟在进行其它测试，否则就必须重新来过。类似的如果冒烟测试没有通过，那么这个build也会返回给开发队伍进行修正，测试人员测试的版本必须首先通过冒烟测试的考验。 冒烟测试的说法据说是：象生产汽车一样，汽车生产出来以后，首先发动汽车，看汽车能否冒烟，如果能，证明汽车最起码可以开动了。说明完成了最基本的功能。 冒烟测试一般用于每日构建(Nightly build)，构建服务器首先从CVS服务器上，下载最新的源代码，然后编译单元测试，运行单元测试通过后，编译可执行文件，可执行文件若可运行，并能执行最基本的功能，则认为通过了冒烟测试，这时，构建服务器会把程序打包成安装文件，然后上传到内部网站，第二天一早，测试人员来了以后，会收到构建服务器发来的邮件提示昨晚是否构建成功。若构建成功，则测试人员进行相关的功能测试。所有这些功能的完成，一般是靠编写脚本完成的

此作业要求参见： https://edu.cnblogs.com/campus/nenu/2018fall/homework/2381 一、本周PSP 类型 任务 开始时间 结束时间 中断时间（分钟） Delta时间（分钟） 小组会议 β阶段第二周分配任务 2018.11.21 17:04 2018.11.21 17:20 0 16 项目 完成自己不能帮取自己快递的逻辑判断 2018.11.21 22:31 2018.11.21 23:21 3 47 小组会议 加强回归测试 2018.11.22 16:57 2018.11.22 17:23 0 26 项目 解决回归测试中的问题 2018.11.22 17:32 2018.11.22 17:49 0 17 博客 小组立会博客 2018.11.22 20:23 2018.11.22 20:57 0 34 小组会议 页面修改及新页面添加 2018.11.23 16:23 2018.11.23 16:59 0 36 小组会议 视频剪辑 2018.11.24 10:34 2018.11.24 17:23 0 21 小组会议 展示博客 2018.11.25 17:13 2018.11.25 11:25 0 22 小组会议 上传β阶段展示视频 2018.11.26 15:32 2018.11.26 15:55 0 23 小组会议 β阶段最后完善

一、背景 高德 App 经过多年的发展，其代码量已达到数百万行级别，支撑了高德地图复杂的业务功能。但与此同时，随着团队的扩张和业务的复杂化，越来越碎片化的代码以及代码之间复杂的依赖关系带来诸多维护性问题，较为突出的问题包括： 不敢轻易修改或下线对外暴露的接口或组件，因为不知道有什么地方对自己有依赖、会受到影响，于是代码变得臃肿，包大小也变得越来越大； 模块在没有变动的情况下，发布到新版本的客户端时，需要全量回归测试整个功能，因为不知道所依赖的模块是否有变动； 难以判断 Native 从业务实现转变为底层支撑的趋势是否合理，治理是否有效； 这些问题已经达到了我们必须开始治理的程度了，而解决此类问题的关键在于需要了解代码间的依赖关系。 二、高德 APP 平台架构 为了消除一些疑惑，在讨论依赖分析的实现前，先简单说明一下高德 APP 的平台架构，以便对一些名词和场景有一些背景了解。 高德 APP 从语言平台上可以分为 4 个部分，JS 层主要负责业务逻辑和 UI 框架；中间有 C++层做高性能渲染（主要是地图渲染），同时实现了一些切面 API，这样可以在双端只维护一套逻辑了；Android 和 iOS 层主要作为适配层，做一些操作系统接口的对接和双端差异化的（尽可能）抹平。 这里的切面是指 JS 层与 Native/C++ 层的分界线，这里会实现一些切面 API，也就是 JS 层与

用户界面（UI）测试初学者指南 本指南介绍了有关GUI测试的关键问题：它是什么？ 它为什么如此重要？ 什么是主要的GUI测试类型和技术？ 阅读此综合指南以发现这些问题的答案，并学习如何创建GUI测试计划并编写GUI测试用例。 什么是GUI测试？ 如果智慧的开始是术语的定义，那么对GUI测试的理解必须从术语 GUI 的定义开始 。 这是 图形用户界面 的缩写 ，或用户可见的应用程序的一部分。 GUI可能包含诸如菜单，按钮，文本框和图像等元素。 第一批成功的图形用户界面之一是Apple Macintosh，它通过文件夹，日历，垃圾桶和计算器来推广用户“桌面”的概念。 早期的GUI：1984年发布的Apple Macintosh。 图片来源： folklore.org CC许可 在当今的GUI测试环境中，“简单计算器应用程序”不再局限于计算机的桌面。 它可能是在所有主要移动平台上可用的移动应用程序。 或者，它可能是所有主流浏览器都必须支持的云应用程序。 测试人员必须执行跨浏览器和跨平台测试来识别缺陷并确保应用程序满足所有要求。 因此，GUI测试是指测试用户可见的应用程序的功能。 在计算器应用程序的示例中，这将包括验证应用程序是否正确响应诸如单击数字和功能按钮等事件。 GUI测试还会确认外观元素（如字体和图像）符合设计规范。 UI测试与GUI测试一样吗？

测试流程规范 编写 ：XXX 1. 测试流程 1. 目标 2. 主要流程 3. 自动化测试在测试流程中的作用 4.一般的项目测试流程 5. 需求评审 6. 设计评审 7. 测试计划 8. 测试用例 9. 冒烟测试 10. 测试执行 11. 测试报告 12. 验证发布 1.1. 目标 目标： 为了更好的保证产品质量，提高测试效率，沉淀积累测试流程，特制定该流程，并在一段时间内推动并落实： 1.2. 主要流程 1.3. 自动化测试在测试流程中的作用 1.4. 一般的项目测试流程 1 、需求阶段：需求熟悉、需求评审 2 、设计和代码阶段：设计评审、准备测试计划（评审）、测试用例（评审） 3 、测试环境搭建、测试工具准备 4 、测试执行（代码走查、冒烟测试、安全扫描、性能测试、易用性测试、回归测试） 5 、生产环境验收测试。 1.5. 需求评审 对于任意的项目，都需要进行需求评审，充分了解需求，目的。在需求评审中发现需求的不足，遗漏等，尽量把问题消灭在萌芽阶段，这个阶段发现问题是效率最高的，能够节约大量项目时间。在需求评审之前，请各位仔细阅读需求说明，做好充分准备，避免会议上才开始阅读需求，或者需求评审的时候不能及早提出异议。 1.6. 设计评审 通过参与设计评审，了解设计架构，对了解系统的设计，逻辑处理等有很大的帮助，能帮助我们设计测试计划，测试用例 1.7. 测试计划 测试开始之前

软件生命周期 软件测试要经过一个什么样的过程呢，这就要从软件的生命周期开始说起了。 软件生命周期又称为软件生存周期或系统开发生命周期，是软件的产生直到报废的生命周期。 整个生命周期包括问题定义与规划、需求分析、系统设计、软件编程、软件测试、软件运维等阶段。 在周期内，无论是开发还是测试都依赖于某个模型进行作为依据，有效地提高开发、测试效率。 软件开发模型 在软件开发的实践中，总结了很多软件的开发模型来描述和表示一个复杂的开发过程，如果瀑布模型、快速原型模型、螺旋模型等。 软件测试与软件开发模式有着紧密的关系，作为一名测试人员，应该充分理解软件的开发模式，尽快的找准自己的位置，从而尽快的发挥自己的价值。 瀑布模型 瀑布模型是线性模型的一种，在所有的模型中占有重要的地位，是所有其他模型的一个基础。 瀑布模型如同工地里的建造盖房流程，使用里程碑的方式，严格定义了各开发阶段的输入和输出。如果达不到要求的输出，下一阶段的工作就不展开。 测试的切入点，开发完成后，必须留给测试足够的时间给测试人员，否则可能会导致测试不充分，导致很多问题到项目的后期才体现出来。 优点 明确划分了软件生命周期的各个环节。 强调早期软件计划，需求分析比较重要。 清晰的工作流程，便于分工协作。 适合需求稳定的产品开发。 每个阶段都有一个检查点。 缺点 线性的开发流程，存在巨大的风险。 依赖于早期的需求调查

冒烟测试是自由测试的一种，由开发人员与测试人员共同进行。在测试过程中发现问题，测试人员找到了一个Bug，然后开发人员会来修复这个Bug， 冒烟测试是否通过 决定了下一轮系统测试是否可以执行。 冒烟测试与回归测试的区别 冒烟测试，是版本验证测试，主要确认新的版本是否存在致命性bug，功能可以正常运行（不会出现跑不通的状况），不会影响下一轮测试的进行，如果上述都符合那么这个版本就可以进行下一轮测试。个人理解冒烟测试最大的优点在于节约测试的时间成本，减少测试轮数。 而回归测试，是软件维护阶段对软件修改后进行的测试，指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。 来源： https://www.cnblogs.com/itplay/p/11881482.html

维护一套checklist，借鉴测试，较少常规测试和常规bug。 新增模块 修改模块 影响范围 测试注意事项 界面控件标题是否正确 界面控件必填项检查（null，空格等） 下拉框选择项检查 文本输入框检查（最大最小字符数等长度限制） 输入合法性检查（文本OR数值，是否支持小数） 联动关系检查（地区等） 按钮功能是否实现（重置/取消/是否跳转等） 界面布局检查 界面提示信息准确性检查 查询操作显示结果是否符合常规（日期格式，金额，排序等） 分页检查 是否进行过自测或冒烟测试 代码是否提交完成 代码是否提交了与本次新增/修改无关的内容 是否进行过自测或冒烟测试 新建的数据库表（表名） 修改的数据库表结构（表名，变动内容） 寄存数据是否需要脚本修改 新功能测试： 大颗粒度保证各个功能点被覆盖，不必过于详细，进行持续验证；功能满足后进行bug大扫除，细粒度验证。 回归测试： 通过code diff了解代码变动的地方，做关联分析，明确哪些地方需要回归测试。 回归测试主要保证功能点没有问题，忽略细节问题。 为各系统维护一套测试点的checklist，精简列出需要关注和易被遗漏的测试点，可以放到wiki，不断补充完善。 文章来源: 项目提测CheckList通用版