一、软件测试背景
1、软件缺陷
1.1、软件缺陷的定义
对于软件缺陷的精确定义 通常有下列描述
1、软件出现了产品说明书指明不会出现的错误
2、软件未达到的《需求文档》中规定的功能
3、软件功能超出产品说明书指明范围
4、软件测试人员认为难以理解、不宜使用、运行速度缓慢、或者最终用户认为不好
1.2、软件缺陷产生的原因
第一大原因就是软件产品规格说明书，很多情况下，说明书没有写，或写的不够全面，经常修改，或者开发小组没有很好的沟通，造成说明书不一致
第二大原因是软件设计，没有做设计或设计不好，经常变动等和产品说明书不一样的问题
第三大原因是编写代码和其他原因
主要分为以下几个类型：
（1）需求解释有错误；
（2）用户需求定义错误
（3）需求记录错误
（4）设计说明错误
（5）编码说明有误
（6）程序代码有误
（7）测试错误
（8）问题修改不正确
（9）不正确的结果是由于其他的缺陷产生
2、测试流程
| 需求评审 | 测试计划制定 | 测试计划执行 | 发布与测试报告总结 |
|
1 从用户体验角度提供设计建议 2 从开发经验角度，分析设计是否存在风险，是否能够实现 3 联合其他模块分析，设计是否存在漏洞，逻辑功能存在缺陷 |
1 测试用例设计 2测试用例评审，和测试时间估计 3测试资源 |
1 用例执行 2 bug 修复验证和推动版本进度 3 性能监控，压力测试，兼容测试 |
1版本发布和线上质量监控 2 测试用例更新整合，测试计划评估 3 提供版本最终测试报告，包括用例覆盖率，bug数据分析等 |
| 全程跟进需求边更，与产品无缝沟通，在测试阶段有需求变更要第一时间了解改动范围如果影响版本的质量要说明风险，评估需求是否必须更改以及是否必须更改以及是否响应版本发布上线的时间线 | 规划测试项目需要的功能开发和自动化开发人员比例，规划整个测试流程需要的时间，要预留处理紧急事件的缓冲 | 执行 协调测试资源，部署测试环境，督促开发和产品提供一切需要的测试工具，测试数据等，推动版本速度，每日进行bug review （bug复盘），标识出bug解决的优先级和提交测试的时间点，每日提供当日产品质量报告 |
报告 项目发布上线后，对整个版本的bug进行数据分析，总结出用例同时测试人员之间进行分享，针对新接触的测试方法测试工具和有价值的bug进行经验总结 |
流程图
3、软件测试分类
4、测试分类占比
5、软件测试的原则
1、开发者应该尽早和不断地测试
2、设计测试用例时，应该考虑到合法的输入和不合法的输入，以及各种边界条件，特殊情况下要制造极端状态和意外状态
3、一定要注意测试中的错误集中发生现象，这和程序员的编程水平和水平和习惯有很大的关系
4、对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析
5、制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短的世间人完成一个高水平的测试
6、回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见
7、妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要测试文档。
6、软件的开发模式
6.1 迭代和增量的理解
迭代：反复求精的过程 先画整体，每个部分细化加色
增量：逐块增加 先画头，在画身子，在画手
7、软件生命周期模型
软件生命周期 同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为软件生命周期（软件生存周期）[1] 。软件生命周期模型是指人们为开发更好的软件而归纳总结的软件生命周期的典型实践参考。
7.1、边写边改模型
在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。
这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：
（1） 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；
（2） 忽略需求环节，给软件开发带来很大的风险；
（3） 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。
7.2、瀑布模型
瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位
瀑布型简单地说就是按照需求、设计、编码、测试、软件维护这个基本的顺序来研发软件，前面一个步骤不完成，后面的步骤不能开始，否则问题会滚到下个阶段，带来更多的问题
优点：
1) 为项目提供了按阶段划分的检查点
2) 当前一阶段完成后，只需要去关注后续阶段。
缺点：
1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4）瀑布模型的突出缺点是不适应用户需求的变化。
7.3、原型化模型
原型化模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，经过和用户针对原型的讨论和交流，弄清需求以便真正把握用户需要的软件产品是什么样子的。充分了解后，再在原型基础上开发出用户满意的产品。
7.4、增量模型
7.5、螺旋模型
螺旋模型是一个演化软件过程模型，将原型实现的迭代特征与线性顺序（瀑布）模型中控制的和系统化的方面结合起来。使得软件的增量版本的快速开发成为可能。在螺旋模型中，软件开发是一系列的增量发布。螺旋模型的整个开发过程如图所示。
图中的螺旋线代表随着时间推进的工作进展；开发过程具有周期性重复的螺旋线形状。4个象限分别标志每个周期所划分的4 个阶段：制定计划、风险分析、实施工程和客户评估。螺旋模型要点：统一了瀑布模型与原型模型，与增量模型相似，更强调风险分析。
1.软件分多个版本开发，每个版本就是一次螺旋。
2.每个版本按照这样的顺序进行：
1）确定软件目标，选取定实施方案，弄清项目开发的限制条件；（图中左上象限）
2）分析所选取方案，考虑如何识别和消除风险；（图中右上象限）
3）实施软件开发；（图中右下象限）
4）评价开发工作，提出修正建议，调整计划。（图中右下象限、左下象限）
3.需求不是一次获取和实现的，通过多个螺旋来完善。
4.计划也不是一次成型的，每次螺旋都需要调整。
优点：
1）设计上很灵活，可以在项目的各个阶段进行变更；
2）以小的分段来构建大型系统，使成本计算变得简单容易；(国企项目)
3）客户始终参与每个阶段的开发，保证了项目不偏离正确方向以及项目的可控性；
4）随着项目推进，客户始终掌握项目的最新信息 , 从而能够和管理层有效地交互；
5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。
缺点：
螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的。
因此，这种模型往往适应于内部的大规模软件开发。该模型建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。
7.6、V模型
V 模型的左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。
V 模型的优点在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发各阶段的对应关系。
V模型的缺陷及解决思路
V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。
解决的思路是，当一个软件开发的时候，研发人员和测试人员需要同时工作，测试在软件做需求分析的同时就会有测试用例的跟踪，这样，可以尽快找出程序错误和需求偏离，从而更高效的提高程序质量，最大可能的减少成本，同时满足用户的实际软件需求。
优点：
1 每一个阶段都清晰明了，便于控制开发的每一个过程。
2 既包含单元测试又包含系统测试。
缺点：
1 测试介入的比较晚，对于前期的一些缺陷无从发现和修改。
2 测试和开发串行。
7.7 w模型
测试与开发是同步进行的，从而有利于尽早地发现问题。
优点
1 测试伴随着软件的整个生命周期，例如，在需求分析结束后就可以进行需求分析测试。
2 测试于开发是并行独立进行的。
缺点
1 对有些项目，开发过程中根本没有文档产生，故W模型无法使用。
2 对于需求和设计的测试技术要求很高，实践起来很困难。
8、软件测试工具
软件测试工具是通过一些工具能够使软件的一些简单问题直观的显示，使测试人员更好的找出软件错误所在。
软件测试工具分为自动化软件测试工具和测试管理(禅道)工具。
软件测试工具存在的价值是为了提高测试效率，用软件来代替一些人工输入。
测试管理工具是为了复用测试用例，提高软件测试的价值。
一个好的软件测试工具和测试管理工具结合起来使用将会使软件测试效率大大的提高。
Bug管理工具： 禅道 Jira（付费）,Trac,gitlab
自动化 python+ selenium ，python+ appnium （ui自动化） pytest,unites,Junit (测试用例 单元测试) innerHtml （发送测试报告） request +python+allure 接口自动化
性能测试工具 jmeter ,Loadrunner、
抓包工具 Fiddler ,charles (弱网测试的)
接口工具 postman ，jmeter
录制脚本 bodyboy jmeter
云测 腾讯云 模拟不同的移动端或者是web浏览器
命令 Linux adb monkey
数据库 myql,oracle,redis
语言 python,java,c,c++
