模块测试

目录 优质集成实践 使用pip安装包 Python测试发现的约定 选择测试布局结构/导入规则 在应用程序代码外测试 测试作为应用程序代码的一部分 tox 返回: Pytest权威教程 优质集成实践 使用pip安装包 对于开发,我们建议你将[venv来安装应用程序和任何依赖项,以及 pytest 包本身。这可确保你的代码和依赖项与系统Python安装隔离。 接下来, setup.py 使用以下最低内容将文件放在包的根目录中： from setuptools import setup,find_packages setup(name="PACKAGENAME",packages=find_packages()) PACKAGENAME 包裹的名称在哪里。然后,你可以通过从同一目录运行,以“可编辑”模式安装程序包： pip install -e . 它允许你更改源代码(测试和应用程序)并随意重新运行测试。这与运行类似,或者使用符号链接将你的包安装到开发代码中。 pythonsetup.pydevelop``condadevelop Python测试发现的约定 Pytest 实现以下标准测试发现： 如果未指定参数,则从`testpaths(如果已配置)或当前目录开始收集。或者,命令行参数可以用于目录,文件名或节点ID的任意组合。 递归到目录,除非它们匹配 norecursedirs 。

目录 片状测试 为什么片状测试是个问题 潜在的根本原因 Pytest特性 其他一般策略 研究 资源 Pytest导入机制和sys.path/PYTHONPATH 包中的测试模块及conftest.py文件 独立测试模块及conftest.py文件 调用通过python -m pytest调用pytest 返回: Pytest权威教程 片状测试 为什么片状测试是个问题 当使用连续集成(CI)服务器时,片状测试尤其麻烦,因此在合并新代码更改之前必须通过所有测试。如果测试结果不是一个可靠的信号 - 测试失败意味着代码更改破坏了测试 - 开发人员可能会对测试结果产生不信任,这可能导致忽略真正的失败。它也是浪费时间的一个来源,因为开发人员必须重新运行测试套件并调查虚假故障。 潜在的根本原因 系统状态 从广义上讲,一个片状测试表明测试依赖于一些未被适当控制的系统状态 - 测试环境没有充分隔离。更高级别的测试更有可能是因为他们依赖更多的状态。 当测试套件并行运行时(例如使用pytest-xdist),有时会出现片状测试。这可以表明测试依赖于测试排序。 也许不同的测试是在自身之后无法清理并留下导致片状测试失败的数据。 片状测试依赖于先前测试的数据,该测试不会自行清理,并且并行运行以前的测试并不总是存在 修改全局状态的测试通常不能并行运行。 过于严格的断言

需求分析： 整体流程图： 需求提取 -> 需求分析 -> 需求评审 -> 更新后的测试需求跟踪xmind 分析流程： 1. 需求提取： 分析依据（包括：需求矩阵、产品交互图、需求说明书） 获取需求的纬度 客户价值 可以为客户带来哪些价值？ 可以解决哪些问题？ 根据以上问题定位功能是否合理 UI功能 - 展示功能 模块关联-历史模块 新功能模块关联 考虑是否关联？耦合部分是否需要支持？ 客户使用场景-部署方式 网络特性 客户使用服务器常见外设 性能参数-性能要求 网卡最低速率 硬件支持 输出（提取最原始的测试需求） 2. 需求分析： 分析依据（五维分析） 用户场景 功能是否和场景强关联 网络拓扑能否满足客户需求 和竞争对手比较差异 功能是否能满足客户实际应用场景 是否考虑了用户的实际操作 明确性 范围明确性（参数、类型长度范围） 清晰性限制等范畴 无法预知影响的需求提出进行确定，风险 二义性 概念模糊【大概念、第三方支持、与上个版本相同】 支持与不支持等范畴 一个需求描述能出现多种理解 完整性 需求一致性【用户需求、需求规格、需求矩阵三者是否同意】 需求完整【隐形需求】 关联性【与新老功能、与外置软件设备】 可测试性 实现测试需要的工具、方法【调试、接口命令】 定位方式【日志等形式观察】 复杂环境、容量边界、操作时过程不可见 输出 测试需求跟踪 缺陷预防bug 工具需求

Top12原则： 主要资源，重要功能，依据需求重要度进行资源分配， 项目100功能 1 day -> 100Task -> 10 Dev 20% 80% 开发各阶段流程及规范 　　　　 需求、架构、设计、开发、测试等阶段流程及规范 　　　　　　　　　　　　　　　　　　　　 需求是基石 　　　　 总流程 ：战略规划 3-4年->产品立项-> 用户调研+竞品分析->业务信息 -> 需求分析 -> 指导 开发 与测试规范 -> 标尺【功能清单 + 4 要素： 界面 + 逻辑 + 交互 + 数据】-> 架构过程 -> 主体结构【系统模块/接口/分层/框架】-> 项目管理分工->详细设计【模块代码 结构定义】-> 代码实现 -> 迭代开发 + 迭代测试 + 持续集成 -> 系统测试 -> alpha test -> 用户验收测试 -> Beta Test -> 商用 产品效率质量 =团队能力 + 写作流程 改进收益： 需求>测试>架构>编码 软件研发完成过程 -> 迭代画开发 ->敏捷开发 敏捷开发过程 ： REQ ->Architecure -> Iteration[Desing + Coding + Test] -> System Test 迭代过程 ex :24month project HLR(高阶需求，只列出功能列表) 5% 2 week 400 Feature->

软件测试分类 1. 按照阶段进行划分 1.1 单元测试(Unit Testing) 单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：模块。 测试阶段：编码后 测试对象：最小模块 测试人员：白盒测试工程师或开发工程师 测试依据：代码和注释+详细设计文档 测试方法：白盒测试 测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试 1.2 集成测试(Integration Testing) 集成测试也称联合测试、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。主要目的是检查软件单位之间的接口是否正确。 测试阶段：一般单元测试之后进行 测试对象：模块间的接口 测试人员：白盒测试工程师或开发工程师 测试依据：单元测试的模块+概要设计文档 测试方法：黑盒测试与白盒测试相结合 测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响 补充说明： 单元测试是一个模块内部的测试，集成测试是在模块之间进行测试（至少两个） 1.3 系统测试(System Testing) 将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统测试执行阶段,包括回归测试和冒烟测试 测试阶段

1. 按照阶段进行划分 1.1 单元测试(Unit Testing) 单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：模块。 测试阶段：编码后 测试对象：最小模块 测试人员：白盒测试工程师或开发工程师 测试依据：代码和注释+详细设计文档 测试方法：白盒测试 测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试 1.2 集成测试(Integration Testing) 集成测试也称联合测试、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。主要目的是检查软件单位之间的接口是否正确。 测试阶段：一般单元测试之后进行 测试对象：模块间的接口 测试人员：白盒测试工程师或开发工程师 测试依据：单元测试的模块+概要设计文档 测试方法：黑盒测试与白盒测试相结合 测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响 补充说明： 单元测试是一个模块内部的测试，集成测试是在模块之间进行测试（至少两个） 1.3 系统测试(System Testing) 将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统测试执行阶段,包括回归测试和冒烟测试 测试阶段：集成测试通过之后 测试对象

软件开发流程（Software development process）即软件设计思路和方法的一般过程，包括设计软件的功能和实现的算法和方法、软件的总体结构设计和模块设计、编程和调试、程序联调和测试以及编写、提交程序。首先，开发者需要对软件系统进行系统设计。在概要设计的基础上，开发者需要进行软件系统的详细设计。详细设计应当足够详细，能够根据详细设计报告进行编码。编码完成后，需要测试编写好的系统。交给用户使用，用户使用后一个一个的确认每个功能。在软件测试证明软件达到要求后，软件开发者应向用户提交开发的目标安装程序、数据库的数据字典、《用户安装手册》、《用户使用指南》、需求报告、设计报告、测试报告等双方合同约定的产物。 ​ 开发流程： 第一步：需求调研分析 1.相关系统分析员向用户初步了解需求，然后用WORD列出要开发的系统的大功能模块，每个大功能模块有哪些小功能模块，对于有些需求比较明确相关的界面时，在这一步里面可以初步定义好少量的界面。 2.系统分析员深入了解和分析需求，根据自己的经验和需求用WORD或相关的工具再做出一份文档系统的功能需求文档。这次的文档会清楚利用系统大致的大功能模块，大功能模块有哪些小功能模块，并且还列出相关的界面和界面功能。 3.系统分析员向用户再次确认需求。 ​ 第二步：概要设计 首先，开发者需要对软件系统进行概要设计，即系统设计

软件开发流程（Software development process）即软件设计思路和方法的一般过程，包括设计软件的功能和实现的算法和方法、软件的总体结构设计和模块设计、编程和调试、程序联调和测试以及编写、提交程序。首先，开发者需要对软件系统进行系统设计。在概要设计的基础上，开发者需要进行软件系统的详细设计。详细设计应当足够详细，能够根据详细设计报告进行编码。编码完成后，需要测试编写好的系统。交给用户使用，用户使用后一个一个的确认每个功能。在软件测试证明软件达到要求后，软件开发者应向用户提交开发的目标安装程序、数据库的数据字典、《用户安装手册》、《用户使用指南》、需求报告、设计报告、测试报告等双方合同约定的产物。 ​开发流程 第一步：需求调研分析 1.相关系统分析员向用户初步了解需求，然后用WORD列出要开发的系统的大功能模块，每个大功能模块有哪些小功能模块，对于有些需求比较明确相关的界面时，在这一步里面可以初步定义好少量的界面。 2.系统分析员深入了解和分析需求，根据自己的经验和需求用WORD或相关的工具再做出一份文档系统的功能需求文档。这次的文档会清楚利用系统大致的大功能模块，大功能模块有哪些小功能模块，并且还列出相关的界面和界面功能。 3.系统分析员向用户再次确认需求。 ​第二步：概要设计 首先，开发者需要对软件系统进行概要设计，即系统设计。概要设计需要对软件系统的设计

一、软件开发流程 需求分析 1.通过系统的分析从而向用户初步了解需求，然后用相关的工具软件列出要开发的系统的大功能模块，每个大功能模块有哪些小功能模块，对于有些需求比较明确相关的界面时，在这一步里面可以初步定义好少量的界面。 2.系统分析员深入了解和分析需求，根据自己的经验和需求用WORD或相关的工具再做出一份文档系统的功能需求文档。这次的文档会清楚列出系统大致的大功能模块，大功能模块有哪些小功能模块，并且还列出相关的界面和界面功能。 3.系统分析员向用户再次确认需求。 概要设计 首先，开发者需要对软件系统进行概念设计，即系统设计。概要设计需要对软件系统的设计进行考虑，包括系统的基本处理流程、系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等，为软件的详细设计提供基础。 详细设计 在概要设计的基础上，开发者需要进行软件系统的详细设计。在详细设计中，描述实现具体模块所涉及到的主要算法、数据结构、类的层次结构及调用关系，需要说明软件系统各个层次中的每一个程序(每个模块或子程序)的设计考虑，以便进行编码和测试。应当保证软件的需求完全分配给整个软件。详细设计应当足够详细，能够根据详细设计报告进行编码。 编码 在软件编码阶段，开发者根据《软件系统详细设计报告》中对数据结构、算法分析和模块实现等方面的设计要求，开始具体的编写程序工作，分别实现各模块的功能

采访工业界的软件团队（通过邮件，微博，微信，阅读博客等方式），询问他们的软件开发流程分组讨论 投票选出你们小组成员最喜欢的两个团队类型 辩论你们在这门课程中最应该采取哪种类型 列出优劣 答：通过阅读博客的方式，《微信诞生记：从无到有的开发历程》（ https://lusongsong.com/info/post/721.html），软件开发流程分为以下几个方面。 需求分析 1.相关系统分析员向用户初步了解需求，然后用相关的工具软件列出要开发的系统的大功能模块，每个大功能模块有哪些小功能模块，对于有些需求比较明确相关的界面时，在这一步里面可以初步定义好少量的界面。 2.系统分析员深入了解和分析需求，根据自己的经验和需求用WORD或相关的工具再做出一份文档系统的功能需求文档。这次的文档会清楚列出系统大致的大功能模块，大功能模块有哪些小功能模块，并且还列出相关的界面和界面功能。 3.系统分析员向用户再次确认需求。 概要设计 首先，开发者需要对软件系统进行概要设计，即系统设计。概要设计需要对软件系统的设计进行考虑，包括系统的基本处理流程、系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等，为软件的详细设计提供基础。 详细设计 在概要设计的基础上，开发者需要进行软件系统的详细设计。在详细设计中，描述实现具体模块所涉及到的主要算法、数据结构