测试理论
软件测试概念
在规定的条件下对程序进行操作（人工测试、自动化测试），以发现程序错误，衡量软件质量，并对其是否能满足需求进行评估。
软件测试目的
有特定的目的，有特定的方法，提交错误信息，跟踪错误信息，发现软件问题，检查系统是否满足用户需求
什么是软件测试
- 软件测试是为了检验出程序错误而执行的一系列若干操作
- 软件测试可以人力执行也可以借助工具执行
- 软件测试过程可以运行软件也可以不运行软件，指的是动态测试与静态测试
测试目的之证明（证明软件中不存在错误和问题，给与自己产品质量足够的信心。）
测试目的之检测（不懈的挖掘软件的错误，提供产品系统的质量报告，不断的完善产品。）
测试目的之预防（预防将来可能出现的问题）
软件测试主要工作：
- 执行软件测试需求分析，编写测试计划书，编写测试用例
- 执行测试过程，目的发现软件缺陷，进行软件缺陷管理，提交测试缺陷报告
- 衡量软件质量，检测易用性，兼容性，性能等
开发人员自己做测试的问题：
人性角度、思维惯性、测试环境复杂度等方面。
软件的生命周期：
产品定义->可行性分析->需求分析->系统设计->详细设计->软件编码->单元测试、综合测试->软件运维
一、问题的定义及规划
确定软件开发目的以及可行性，指定开发计划。
二、需求分析
在确定软件开发可行性正确下，对软件所需的功能进行详细分析，明确客户需求，输出原型图。
三、软件设计
概要设计：架构的实现，表述各模块功能、模块接口和数据传递等事务。
详细设计：对表述的各模块深入分析，要求达到代码级别，将程序具体的实现描述出来，以及数据库设计。
四、软件编码
按照详细的模块功能表，编程人员编写出计算机可运行代码。
常见测试活动分为：
- 单元测试，对每一个代码函数测试
- 集成测试，对代码组成的模块进行测试
- 系统测试，针对每一个功能需求，完整的设计测试环境，指派测试人员执行
常见运维问题：
- 由于用户增长造成的性能压力
- 服务器出现问题造成系统不可用
- 软件系统出现bug
- 系统升级出现未知bug
软件开发模型：
早期开发中，软件是边做边改，项目，需求没法管控，软件愈发复杂，开发越难。
开发模型开始演进，瀑布、原型、螺旋、敏捷等模式出现。
瀑布型生命周期：
瀑布模型如同工地里的建造盖房流程，使用里程碑的方式，严格定义了各开发阶段的输入和输出。如果达不到要求
的输出，下一阶段的工作就不展开。(银行体系用的最多，一个需求做一年，变化很少。以及印度开发者是瀑布模型的重度使用者)
优点：
明确划分了软件生命周期的各个环节。
强调早期软件计划，需求分析重要性。
清晰的工作流程，便于分工协作。
适合需求稳定的产品开发。
缺点：
线性的开发流程，存在巨大的风险。
依赖于早期的需求调查，不适应需求的变化，单一流程不可逆。
风险在后期可能才会暴露，且无法纠正。
无法保证用户的产品需求不变，开发过程无法更改。
(比如盖房子，照着图纸打好的地基可以承载7层楼，现在用户突然要加三层，那么地基就得重打，已经盖好的楼就
得爆破，这是不可能的操作。)
快速原型模型
客户与开发公司紧密联系，开发周期较长，开发受到需求经常变更的影响。
增加客户与系统的交互
根据用户的主要需求，建立一个软件原型，然后让用户进行评价，然后根据用户的评价和提出的更多的需求来开发出相应的软件产品。通过逐步调整原型使其满足客户的要求。(例如室内设计，客户想要客厅装修成xx样，待你画好了效果图、客户一看，不行，我想要这样、我想要那样..)
细化软件需求
快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。
优点：
快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。
提供学习手段，通过开发原型和演示原型对开发者和使用者对整个系统了解有积极作用。
真正理解客户的需求。
缺点：
快速建立的系统结构可能产品质量低下。
螺旋模型
螺旋模型结合了 瀑布模型与快速原型
将开发过程分为螺旋周期，每个螺旋周期和瀑布模型相符，沿着螺旋线旋转，坐标轴的四个象限表示四个活动。
1988年由巴里·勃姆提出的软件开发模型升级版，兼顾了瀑布模型的优点。
“螺旋模型”的核心就在于不需要在刚开始的时候就把所有事情都定义的清清楚楚。您轻松上阵，定义最重要的能实现它，然后听取客户的意见，之后再进入到下一个阶段。如此不断轮回重复，直到得到您满意的最终产品。
（1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；
（2）风险分析：分析评估所选方案，考虑如何识别和消除风险；
（3）实施工程：实施软件开发和验证；
（4）客户评估：评价开发工作，提出修正建议，制定下一步计划。
螺旋模型很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风
险评估。
优点：
引入了其他模型不具备的风险分析，使得软件遇见风险时可以停止，减少损失。
要求每个迭代阶段都需要构建原型，进行软件测试以减小项目开发风险。
整个过程有较高灵活性，开发过程的任意阶段自由应对变化。
缺点：
需要测试人员有丰富的风险评估经验和专业知识才能及时标识风险，减少软件缺陷损失，过多的评审迭代，造成开
发成本压力。
敏捷开发之Scrum方法
敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。
Scrum就是敏捷开发的具体方式。
Scrum的英文意思是橄榄球运动的一个专业术语，表示 “争球”的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。
而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。
Scrum团队中三个关键角色：Scrum Master，Scrum Product Owner和Scrum开发团队（开发，产品经理，敏捷主管）
产品负责人采集用户需求，放入产品列表，通过计划会议讨论要实现哪些功能
敏捷开发不强调一次性就确定软件需求，完成开发，而是通过短期内的多次迭代，完成产品开发。
（比如：先完成用户登录注册的功能，确保是可工作的状态，就可以上线，后续功能继续迭代更新。）
软件是在逐步的改进增减的过程，最终达到用户满意度。
敏捷开发就是迭代+增量。
敏捷开发对于自动化测试的要求较高，开发人员注重开发，测试人员注重测试过程。
软件测试模型
随着软件测试的发展，测试人员在大量实践中总结出一些测试模型，对测试活动进行抽象，如V模型、W模型等。
V模型：
V模型和瀑布开发模型有着一些共同的特性，V模型中的过程从左到右，描述了基本的开发过程和测试行为。
V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。
局限性：把测试作为编码之后的最后一个活动，需求分析等前期产生的错误直到后期的验收测试才能发现。
模型部分解释：
单元测试也叫做模块测试，进行正确性检查的工作。
单元测试要从程序内部结构设计测试用例，每个模块可以独立进行测试。
单元是什么？
比如Python中的类，图形化软件的一个窗口，一个功能菜单
集成测试也叫组装测试，也就是将所有单元测试，进行有序的组合测试
系统测试将整个软件系统看做一个整体进行测试，对功能，性能，硬件，软件所有环节进行测试。
单元测试目的：测试功能是否满足要求。
系统测试目的：测试系统是否满足性能的要求，以及不同的机器系统平台中运行,如一台机器我登陆多个qq，是否可
以运行，在windows，linux平台运行qq是否正常等方面。
验收测试α测试
Alpha测试模拟实际操作环境下验收测试，如删档内测，软件只是初步完成的产品，bug可能较多，不会进行上线提供用户访问。
β测试
Beta测试系统已经通过内部测试，大部分错误已经修复，即将正式发布，在多个真实环境下发布，如不删档公测。
对比α版本已经有了较大改进，但仍可能存在一些bug，需要大规模测试，例如DNF公司更新一个地图，提供公测免费下载，由专业游戏玩家进行游戏结果反馈，开发者啊、再进行修复。
γ版本
y版本指的是正式版本，与上线版本几乎无区别。
W模型
W模型就是开发流程一个V，测试一个V，组合而来的W
W模型优点
测试伴随整个软件开发生命周期，更早接入测试，可以更好的发现需求设计中的缺陷，修复成本也更低。
W模型缺点
依赖于软件开发和测试的前后线性关系，还是无法解决需求变更调整的问题
对于项目中不产出文档的事例，测试工作无法执行。(小型公司直接产出原型图，并不写需求说明书)
对于复杂业务，新人经验不足以测试需求，测试设计。
测试覆盖率
覆盖率=(至少执行一次的项目点)/ 项目点总数
特点
-
通过覆盖率数据，检验测试工作是否充足
-
分析出测试的弱点，对比测试人员的测试结果
-
指导我们设计能够增加覆盖率的测试用例，有效提高测试质量
-
测试覆盖率与黑盒
-
需求覆盖 在测试中，有哪些功能被测试了，被测试的频率
- 需求覆盖=(验证的需求数)/(总需求数)
-
用例覆盖 体现每轮测试验证通过的用例数在总比例中的比重
- 用例覆盖=(验证通过的用例数)/(总用例总数)
软件测试常见术语
- c/s：Client客户端、Server服务端，指的是互联网中一台服务器安装服务端软件，每个用户都需要安装客户端软件，例如QQ、微信、游戏。
- b/s：Browser浏览器，Server服务器，不需要安装客户端，只需要有浏览器即可，例如淘宝网、京东网，便于维护与升级。
- bug：指的是软件中不符合用户需求的问题，软件存在的缺陷。
- Testing Environment：软件运行的平台、包括硬件、软件、网络配置。
- Test Case：测试执行之前的详细测试方案，包括测试环境、测试步骤、测试数据、预期结果。
- 测试用例=数据输入+测试结果输出+测试环境配置
- Smoke Testing：在软件大规模测试之前，验证基本功能，决定是否有可测性，例如基本登录。
测试人员情商素养：
- 踏实细心
- 积极主动
- 好奇心、具有怀疑态度
- 良好的沟通交流能力
- 自我提高，持续学习
- 责任心
测试人员的原则：
所有测试动作必须追溯到用户需求
80%的产品缺陷都是在产品开发过程中的需求定义出现偏差引发的，如果需求得到准确的验证，可以消除80%的返工问题，节省投入成本40%。
尽早启动测试工作
Pareto法则应用于软件测试：
人们采用二八定律，用于计量投入和产出之间可能存在的影响关系。
管理学：通常一个企业80%的利润来自于20%的项目。
心理学：
-
20%的人集中了人类80%的智慧，出生就是鹤立鸡群。
-
20%的人买时间，80%的人卖时间
-
20%的人做事业，80%的人做事情
-
20%的人正面思考，80%的人负面思考
在项目管理认证中（PMP）Pareto法则成效是： -
抓住主要矛盾
-
科学分配时间和精力
-
把80%的资源花费在关键效益的20%的方面，这20%又能带动80%的发展，相辅相成，生生不息。
测试中的Pareto法则是指在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的缺陷，系统测试又能找出其余缺陷的16%，最后4%的缺陷可能在用户大范围、长时间试用下才会暴露。
不可能穷尽测试
很少会有对软件进行所有可能的测试，对大多数软件项目来说，应该使用适当的风险分析。这很看重测试经验，常识与感觉。
杀虫剂怪事
软件测试越多，对测试的免疫力也越强。例如开发和测试长时间相处，开发就知道测试人员的套路，也会尽量去避免。
为了克服杀虫剂怪事，测试人员必须不断编写更新的测试方案，对程序的不同部分进行测试，以找出更多软件测试。
前进两步、后退一步
测试中一个基本问题是，缺陷修复后总会以20%-50%的几率引入新的缺陷。每次修复后，必须重新运行先前所有的测试用例，确保系统不会以隐蔽的方式被破坏。
三心二意
细心(不要放过任何一个细节)
信心(对自己的测试结果有信心，防止开发人员说：我的程序不可能出错，你重新再去测！)
耐心
团队协作意识
软件缺陷预防意识