测试过程

● ○ ● 你会搭建测试环境吗？● ○ ● 导语：很多人在面试软件测试的过程中，经常被问到“你会搭建测试环境吗”？面对这样的提问，你知道怎么回答么？ ● ○ ● 如何回答● ○ ● 面试的时候，遇到这样的提问，很多人的都会感觉脑子一下一片空白，或者星星点点，不知道从何说起。一方面不知道面试官问这个问题的意图是什么？也不知道他想得到的答案是什么？更加不知道该从哪些方面来回答。作为一个测试行业从业8年有余的测试人员，我想跟大家分享一些我的经验和看法。 首先，毋庸置疑的是，面试官问这个问题，想要得到的是你肯定的答案，希望你是一个会搭建测试环境的优秀测试工程师。QA不管是做什么类型的测试，最基础的功能测试，需要搭建测试环境；进阶部分的性能压力测试，对搭建环境的要求更高。所以搭建测试环境是优秀测试工程师的必备技能之一，也是QA开展测试工作的前置条件。当然有些公司可能会有运维或者研发部门帮忙准备好测试环境，但是QA如果一味依赖别的部门，就会大大的局限测试工作的开展，如果别的部门没有时间或者进度滞后，会直接影响到测试工作的进度和效率；而且测试环境如果不是QA负责维护的，后期扩展业务需要优化测试环境的时候，或者遇到问题要调试的时候，都需要依赖其他部门，会导致测试工作不独立，也会显得测试工作人员不专业。 ● ○ ● 需掌握的知识● ○ ● 了解了QA具备搭建测试环境能力的重要性

DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。从定义来看，其实devops就是为了让开发、运维和QA可以高效协作的流程 来源： https://www.cnblogs.com/levin180425/p/11722329.html

第六章 低级程序设计语言与伪代码 6.1 计算机操作 我们所用的程序设计语言都必须反映出计算机能够执行的操作类型。让我们通过重述计算机的定义来开始新的讨论:计算机是能够存储、检索和处理数据的可编程电子设备。 这个定义中的操作字包括 可编程的 、 存储 、 检索 和 处理 。上一章指出了数据和操作数据的指令逻辑上是相同的，它们存储在相同的地方。这就是“可编程的”这个词的意义所在。操作数据的指令和数据一起存储在机器中。要改变计算机对数据的处理，只需要改变指令即可。 存储、检索和处理 是计算机能够对数据执行的动作。也就是说，控制单元执行的指令能够把数据 存储 到机器的内存中，在机器内存中 检索 数据，在算术逻辑单元中以某种方式 处理 数据。词语“处理”非常通用。在机器层，处理涉及在数据值上执行算术和逻辑操作。 6.2 机器语言 机器语言 ：由计算机直接使用的二进制编码指令构成的语言 Pep/8:一台虚拟机 虚拟机 ：为了模拟真实机器的重要特征而设计的假想机器 Pep/8反应的重要特征 回忆第5章中所说的，寄存器是中央处理器中算术/逻辑单元的一小块存储区域，它用来存储特殊的数据和中间值。Pep/8有七个寄存器，我们重点研究其中三个: 程序计数器(PC) , 其中包含下一条即将被执行的指令的地址。 指令寄存器(IR) , 其中包含正在被执行的指令的一个副本。 累加器 (是一个寄存器)。

程序设计层第6、7章读书笔记 第6章 低级程序设计语言与伪代码 6.1 计算机操作 计算机是能够 存储、检索和处理数据 的可编程电子设备。 要改变计算机对数据的处理，只需要改变 指令 即可。 存储、检索和处理 是计算机能够对数据执行的动作。 6.2 机器语言 计算机 真正执行 的程序设计指令是用 机器语言 编写的指令，这些指令固定在计算机的 硬盘 中。 机器语言（machine language） ：由计算机直接使用的 二进制编码指令 构成的语言。 在机器语言中，处理过程中每一个微小的步骤都 必须 被明确地编码。 目前 几乎没有 程序是用 机器语言 编写的，主要是因为编写这种程序 太费时间 。 Pep/8:一台虚拟机 虚拟机（virtual computer（machine）） ：为了 模拟 真实机器地重要特征而设计的假想机器。 Pep/8 有 39 个机器语言指令。这意味着每个Pep/8程序一定是由这些指令组合而成的 序列 。 Pep/8反映的 重要特征 ： 1.Pep/8的内存单元由 65536 个字节的存储空间构成。这些字节从0到65535（ 十进制 ）进行编号。 2.Pep/8的 字长 是两字节，或者16比特。这样向算术/逻辑单元（ALU）流入的数据或从 算术/逻辑单元 流出的数据在长度上就是 16比特 。 3.Pep/8有 7 个存储器。 累加器

1. Github地址及项目成员 https://github.com/zhengjinhuai/arithmetic-generators （进怀github） https://github.com/jezing/arithmetic-generators （曾霖github） 郑进怀 3117004637 ；曾霖 3117004602 2. PSP表格： PSP2.1 Personal Software Process Stages 预估耗时（分钟） 实际耗时（分钟） Planning 计划 20 20 · Estimate · 估计这个任务需要多少时间 20 20 Development 开发 1560 1490 · Analysis · 需求分析 (包括学习新技术) 70 60 · Design Spec · 生成设计文档 60 60 · Design Review · 设计复审 (和同事审核设计文档) 80 90 · Coding Standard · 代码规范 (为目前的开发制定合适的规范) 20 20 · Design · 具体设计 80 90 · Coding · 具体编码 1000 905 · Code Review · 代码复审 120 120 · Test · 测试（自我测试，修改代码，提交修改） 130 145 Reporting 报告 150 150 ·

一 、Github项目地址： https://github.com/Littlehui3/rg2 结对partner：郭绍华 二、PSP表格 PSP2.1 Personal Software Process Stages 预估耗时（分钟） 实际耗时（分钟） Planning 计划 45 60 · Estimate · 估计这个任务需要多少时间 40 42 Development 开发 1090 1205 · Analysis · 需求分析 60 70 · Design Spec · 生成设计文档 35 40 · Design Review · 设计复审 50 60 · Coding Standard · 代码规范 30 40 · Design · 具体设计 80 85 · Coding · 具体编码 700 750 · Code Review · 代码复审 45 55 · Test · 测试（自我测试，修改代码，提交修改） 90 105 Reporting 报告 120 150 · Test Report · 测试报告 60 80 · Size Measurement · 计算工作量 30 30 · Postmortem & Process Improvement Plan · 事后总结, 并提出过程改进计划 30 40 合计 1255 1415 三、设计过程 ： 来源：

软件工程自学 emmm我们专业不学习软件工程，自学一点，权当休闲。 1.概述 应对不断变化的需求 开发占比比测试和维护小得多。 1.2 软件开发的三个阶段 私人化的软件环境中，软件的水平与个人的关系很大。 专家系统：提供专业知识与服务 网格计算：云计算 软件开发的初期，一定要先花时间把需求搞清楚 可读性、可理解性越好，可维护性越好 软件开发追求一致性和标准性 技术先进，需求不清楚是中国的现状。没有技术解决不了的，但是主要问题是把需求提清楚 好的需求本身就是一种资源 维护对一个公司的信誉很重要，要考虑到开发公司的流动性 维护费：技术支持（电话、邮件）、上门解决，这是一个长期的盈利（对客户就是花费） 软件的维护是一件很困难的问题。 软件！=程序，软件是由一个完整的配置组成的，还包括文档和数据。 在软件开发的不同阶段进行修改，需要付出的代价是很不相同的。 一旦发生错误应该马上修改 开发费与维护费是两回事。签合同的时候要说好 1.3 软件工程概述 好的项目管理要尽量准时。 一种策略：快速迭代、抢占市场、尽早上架 开发目的的折中、最优化 易于维护的软件，可靠性一般也比较高 可靠性和性能是互斥的，一个是求稳，一个是性能导向的 软件工程的原则： 例如类，就是对一组有共同特性的对象的抽象 局部化：资源的声明、使用和释放应该放在同一个模块中并且应该尽量靠近 一致性：要培训员工使用公司统一的命名

一、软件开发过程模型： 需求分析、详细设计、编码、测试、运行维护 瀑布模型：需求分析、系统设计、软件编程、软件测试、软件维护 快速原型模型：快速分析、构造、运行、评价 增量模型：规格说明、设计、实现与集成、交付客户 螺旋模型：制定计划、风险分析、实施工程、客户评估 ************************************************************************************************************************************** 二、测试模型： 需求分析、详细设计、编码、测试、运行维护 V模型：需求分析、概要设计、详细设计、编码、单元测试、集成测试、系统测试、验收测试 W(双V)模型： 需求分析　　　　、概要设计　　 、详细设计　　、编码　　、集成　　、实施　　、交付　　 验收/系统测试设计、集成测试设计、单元测试设计、单元测试、集成测试、系统测试、验收测试 H模型：测试准备-----就绪点-------测试执行 　　 01、单元测试： 是模块测试，验证软件的基本组成单位的正确性，是白盒测试 　　 02、集成测试： 是模块间的测试，测试接口（软件各模块之间的接口和软件与硬件之间的接口）是否正确，是灰盒测试（白盒和黑盒结合) 　　 03、系统测试： 系统测试包括：冒烟测试 系统测试

七、测试评估方法和测试误区（第8章和第9章） 　　良好的测试是无法确认的。但是我们可以通过很多方法，知道或估算出不好的测试是什么样的。识别出有关测试的主要误区，可以更好的进行测试。　　 　　测试的评估方法　 　　1、永远无法确切地知道良好的测试 　　完美的测试具有如下特点：a)它会检测出一个系统中的所有缺陷；b)它永远不会将不是缺陷的情况判断为缺陷；3)它能让我们完全确信它完成了a和b；d)针对我们的需要，它可以足够迅速和廉价地实现a、b和c。你会发现完美的测试和很糟糕的测试具有惊人的相似性，一个很糟糕的测试也可能会满足a、b、c和d。 　　良好的测试是描述测试与某个实现之间的特定关系的属性。我们是无法知道测试是良好的，但是我们我们可以根据一些元信息知道测试是否糟糕。 　　2、根据事实来评估良好性 　　1）根据系统中缺陷的多少，来评估一组测试的良好性。 　　　　对这些缺陷进行追踪，分析他们的具体使用情况，可以得到一些信息。比如，测试有多好，以及好在哪些方面；将来可以如何对测试加以改进；测试会经常遗漏哪种缺陷。 　　2）根据长时间积累的缺陷，进行评估 　　3）其他评估方法 　　　　将测试覆盖范围和故障理论进行比较；随机改变测试来了解问题如何出现；对不同类型测试进行比较。 　　3、植入缺陷进行评估 　　　　插入已知的缺陷而不告诉测试人员

Github项目地址 WordCount 合作同学作业链接 201731091317 Part 1. PSP表格 PSP2. Personal Software Process Stages 预估耗时（分钟） 实际耗时（分钟） Planning 计划 60 80 · Estimate · 估计这个任务需要多少时间 60 80 Development 开发 700 785 · Analysis · 需求分析 (包括学习新技术) 60 45 · Design Spec · 生成设计文档 30 45 · Design Review · 设计复审 (和同事审核设计文档) 30 30 · Coding Standard · 代码规范 (为目前的开发制定合适的规范) 30 25 · Design · 具体设计 40 40 · Coding · 具体编码 300 400 · Code Review · 代码复审 90 80 · Test · 测试（自我测试，修改代码，提交修改） 90 120 Reporting 报告 90 120 · Test Report · 测试报告 30 60 · Size Measurement · 计算工作量 30 40 · Postmortem & Process Improvement Plan · 事后总结, 并提出过程改进计划 30 20 合计 850 985