测试开发体系介绍
1 软件测试基础概念
1.1 软件测试作用
- 修复漏洞，提高用户体验
- 降低同类型产品开发遇到问题的风险
- 提高效率
1.2 软件测试原则
- 测试显示缺陷的存在
- 无论执行什么测试的操作都能够证明当前的软件是有缺陷的，但是我们没有办法预知（即只能显示缺陷，无法预知缺陷）
- 穷尽测试是不可能的
- 无法测试到所有情况，任何测试都是有结束时间的，因此一般是测主要功能
- 测试尽早介入
- 为了更早地发现问题，能够节约成本(测试左移)
- 缺陷集群性(2/8原则)
- 我们遇到的bug可能是集中在百分之二十的功能模块里，即我们在一个模块里发现了bug，那么这个模块可能还存在更多的bug等着我们去发现，所以我们要重点地去测试这个模块（对于bug较多的模块，我们需要更多地关注，做更深入的测试）
- 杀虫剂悖论
- 软件也会对同一个测试用例产生“抗药性”（同样的测试步骤、同样的测试方法、同样的测试数据），导致无法发现其他的问题
- 测试活动依赖于测试内容
- 没有两个系统可以使用完全相同的方式进行测试，要依据测试标准、测试工具等进行测试
- “没有错误是好”是谬论
- 不存在完美的产品，没有发现错误不代表产品没有错误
1.3 软件测试对象
- 需求分析阶段：需求文档、接口文档
- 编码实现阶段：源代码
- 系统功能使用：软件程序
1.4 测试用例
- 概念：为特定的目的而设计的一组测试输入、执行步骤和预期的结果，以便测试产品能够满足某个特定需求的文档
1.5 软件测试模型（简单了解了一下）
2 软件开发流程
- 软件：与计算机系统操作有关的计算机程序、可能有的文件、文档及数据。
软件开发流程的演变
传统瀑布模型 → 敏捷开发模型 → DevOps开发模型
瀑布模型
特点：
- 软件开发的各项活动严格按照线性方式进行
- 当前活动接受上一项活动的工作结果
- 当前活动的工作结果需要进行验证
缺点：
- 如果需求有变更，开发人员的编码也变更，那么这个流程会一遍一遍地走，知道需求不变，这这整个流程才能结束。
优点： - 开发的各个阶段比较清晰
- 强调早期计划及需求调查
- 适合需求稳定的产品开发（因此新产品不太适合瀑布模型）
缺点： - 由于开发模型是线性的，增加了开发的风险，早期的错误可能要等到开发后期的阶段才能发现，失去了及早纠正错误的机会
2.1 敏捷开发模型
针对有快速变化需求产生的模型
常见模型：
- XP极限编程
- SCRUM
XP极限模型
重构是为了减少程序当中重复的部分，提高程序的可复用性
代码集体所有：表示每个人都要对代码负责，反过来说，每个人都可以改代码
持续集成：集成指把大家的代码合并到一起，持续是经常集成代码。每次的集成都需要自动化的方式去构建，这里还包含了自动化的测试
构建：指我们从代码去生成用户可以使用的目标产品的过程
隐喻：指帮助团队的每一个人清楚地理解客户的需求，所以需要用到比喻来描述系统的工作（例如我们需要开发像百度一样的搜索引擎，我们的隐喻可以是我们需要一大群的蜘蛛，让它们到网上到处去抓东西，抓到了之后再带回来）
再XP模型中，客户和开发占主导地位，测试主要使用自动化的方式实现。要求整个团队的开发和测试水平较高。
2.2 SCRUM
先对产品功能排序，优先实现级别高的功能，然后按短周期（大概1-2周）迭代更新功能，知道所有功能都被实现
总结敏捷模型的特点：
- 增量迭代
- 小步快跑（迭代周期是1-2周）
2.3 DevOps
可以更快捷地上线（比敏捷模型更快）
适用于需求频繁变化，要求开发、测试、运维紧密结合，且都在需要在敏捷的情况下
2.3.1 DevOps生命周期
- 持续开发
- 持续测试
- 测试工具：web测试工具等
- 持续集成
- 持续集成工具：jekins（最流行），可以先从git库中获取最新的代码，然后生成的一个build构建，然后test测试，最后生成result结果）
- 持续部署
- 只有通过了测试的代码才可以部署到服务器上
- 持续部署工具：doker容器（所有测试环境保持一致）
- 持续监控
- 线上监控可以提高软件质量
- 可以监控软件的性能
- 涉及到运营团队的参与，因为运营也会监控用户在使用产品过程中的行为
2.3.2 DevOps对发布的影响
- 减少变更范围
- 加强发布协调（使用自动化发布工具，减少相关人员沟通的成本）
- 自动化（自动化部署可以减少出错的可能性）
2.3.3 CI/CD
2.3.4 CD与DevOps的关系
常用的测试平台
测试用例管理与bug管理平台
测试用例管理平台
- JIRA：推荐方案，定制性很强，可跨多部门协作（一般是大型企业，需要商业化支持）
- RedMine：推荐方案，开源，活跃，定制性很强（一般是中小型企业，可以快读搭建自己的测试用例管理平台）
- TestLink：流行的测试用例管理平台，体验不太好
- 其他：Tapd、云效、禅道、GitLab、在线协作文档
- 无协作模式：Excel、思维导图
bug管理平台
- 通常与用例管理平台一致（尽量不要跨平台，最好能把case和bug放在一起管理）
- 测试用例、Bug 都可以使用 issue 表达
- 关联关系设定
- 测试用例与 Bug 的属性设定
代码管理平台
- GitLab：可本地部署的 Git 代码管理平台，行业标准（大多数公司使用）
- SubVersion：SVN 管理，已经过时（只有老代码管理还在用）
- GitHub：开源项目运作（不提供本地部署，代码都得传云端，所以不适合企业去管理代码，更适合企业去管理开源的项目运作，而私有的代码一般不放在github，为了保密和安全性）
- BitBucket：与 JIRA 同属一家公司 Altassian（与gitlab在竞争）
持续集成管理平台
- Jenkins：持续集成与持续交付的主流平台（使用度最高）
- GitLab Runner：GitLab 的持续交付方案
- GitHub Action：GitHub 的开源方案
- 自建 DevOps 平台：企业定制平台，Tapd、云效等
持续集成与持续交付
- 研发
- 构建、单元测试 + 覆盖率分析
- 自动化代码审计
- 运维：自动化部署
- 测试
- 接口测试
- UI自动化测试
- 专项测试自动化
- 性能测试、安全测试
流程管理平台
JIRA管理平台
JIRA 中的基本概念
- Project 项目
- Issue 问题
- Field 字段
- Workflow 工作流
- Screen 视图
JIRA 平台管理测试流程
JIRA 管理测试用例流程
- 创建测试用例管理项目
- 录入用例
- 测试用例状态转化
JIRA 管理 Bug 流程
- 创建 Bug 管理项目
- 从用例关联到 Bug
- 在项目中录入 Bug
- Bug 状态转化
项目管理与 跨部门沟通合作
(待深入学习，简单了解了一下并不理解)