软件测试基本概念：
软件测试定义：验证软件功能是否满足用户的需求。
目的：验证软件有或没有问题。
原则：顾客就是上帝。以客户为中心，遵循软件测试的规范、流程、标准和要求。
什么是需求？
定义：满足用户期望或正式规定文档（如合同）所具备的条件和权能，包含用户需求和软件需求。
权能：权利范围 的大小。
用户需求：不能指导发人员编写代码，测试 人员编写测试用例。
软件需求：开发人员可以指导开发人员编写代码，测试人员编写测试代码。
用户需求转换成软件需求：需要不断沟通，引导用户，挖掘需求的真正的需求。
注册时登陆的前置模块，登陆是注册的后置模块。随参照物不同，定位不同。
声控灯：使用范围，高于30分贝，开关。
*需求不一定是正确的，需求也需测试。比如客户想要一个赵雅芝版本的白素贞，比产品经理将需求定义错误。设计成王祖蓝版本的白素贞。或者产品经理将需求定位准确，但是开发部门将需求理解错误。开发出一个王祖蓝版本的白素贞。
什么是BUG
吃鸡例子
一局吃鸡, 已经进了决赛了, 你一身神装, 离吃鸡只有一步之遥, 但是游戏崩溃了~~~
凡是实现效果和需求不相符的都可以认为是BUG.
BUG的后果: 用户流失, 绩效血崩.
BUG的处理: 生产环境上的问题, 要第一时间回滚, 再慢慢定位.
BUG的态度: 心存敬畏, 但是不要害怕. 程序猿身上背负的BUG, 就是一个老兵身上的疤痕, 最值得骄傲的军功章
*专业定义：程序与规格说明之前不匹配。*
注意：以上说法是片面的，准确的来说：当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误bug。
当没有需求规格说明书时，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。
BUG是测试不完的，BUG需要在需求下测试，才更有意义。提升用户感受。
测试用例
举个例子：
比如男朋友一直打游戏，女孩子就会问男朋友，：我和游戏谁重要的送命题。来测试男朋友是否爱自己。女孩子一般希望男朋友在游戏和自己之间选择自己。
在这个小测试中：
人物（一对情侣），场景（游戏中），问题（输入），预期结果（输出）等构成的集合就叫做测试用例。
在软件测试中，测试用例的定义：
1.测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
在这些操作步骤，操作步骤，测试数据，预期结果步骤不可少。
测试用例和实际结果的关系就像C++中类和对象的关系。一个测试用例可能有多个实际结果，实际结果是测试用例的实例化。
2.为什么要有测试用例
测试过程中可能会遇到以下问题
- 不知道是否较全面的测试了所有功能。
- 测试覆盖率无法衡量
覆盖率=测试用例个数/功能点的个数
功能点个数：按文档页数，按代码行数算法较复杂 - 对新版本重复测试很难实施。
- 存在大量冗余测试，影响效率。
增加功能，添加测试用例，删除功能，原来的相关测试用例便作废，测不出真实结果了。必须删除这些冗余的测试用例。
测试用例练习：
手机上添加联系人的测试用例
开发模型和测试模型
1.软件的生命周期：
软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。 如果把软件看成是有生命的事物，那么软
件的生命周期可以分成6个阶段，即需求分析、计划、、设计、编码、测试、运行维护。
瀑布模型：
瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。
优点： –强调开发的阶段性； –强调早期计划及需求调查； –强调产品测试。
缺点： –依赖于早期进行的唯一一次需求调查，不能适应需求的变化； –由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程； –风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。
适合需求比较稳定的模型，或公司以前做过类似的项目
2.螺旋模型（Spiral Model）
一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。
这种迭代开发的模式给软件测试带来了新的要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。因此，回归测试的重要性就不言而喻了。
强调风险分析。适合规模庞大，复杂度比较高的项目
3.增量，迭代模型：增量：以块为单位，以整体为单位。画人例子
增量开发能显著降低项目风险，结合软件持续构建机制，构成了当今流行的软件工程最佳实践之一。
增量开发模型，鼓励用户反馈，在每个达代过程中，促使开发小组以一种循环的、可预测的方式驱动产品的开发。因此，在这种开发模式下，每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本，意味着测试需要频繁进
行，测试人员需要与开发人员更加紧密地协作。
增量通常和迭代混为一谈，但是其实两者是有区别的。增量是逐块建造的概念，例如画一幅人物画，我们可以先画人的头部，再画身体，再画手脚……而迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。
4.敏捷模式：
敏捷的主要贡献在于他更多地思考了如何去激发开发人员的工作热情，这是在软件工程几十年的发展过程中相对被忽略的领域。
《敏捷宣言》：1.强调人与人之间的沟通
2.对文档依赖不高
3.要求客户参与开发过程
4.拥抱变化。
敏捷开发有很多方式。其中scrum比较流行
1.scrum 的角色：
scrum由产品经理(Product Owner )和项目经理（Project Master）和研发团队(team)组成.
product owner 负责user story的整理，定义商业价值，指定产品发布计划，，对产品负责。职位最高，简称PO
srcum master 召开各种会议，协调项目，为研发团队服务。也称敏捷教练
team 研发团队：有不同技能的成员组成。通过协作。完成产品的迭代，交付产品。
迭代开发
与瀑布不同，scrum将产品的开发分解为若干个小sprint(迭代)，其周期从1周到4周不等，但不会超过4周。参与的
团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付
敏捷的基本流程
整理故事user story->讲解user story->迭代计划会议->每日例会(不超过15分钟)->演示会议->回顾会议，总结经验
敏捷中的测试
挑战1：轻文档，画思维导图
挑战2，快速迭代
1、测试工作的核心内客是没有变的，就是不断地找Bug，只是要调整好自己的心态，一切以敏捷的原则为主。
2、测试人员不能依赖文档，测试用例作用减弱，更多的采用思维导图、探索性测试（强调自由度，设计和执行同
时执行，根据测试结果不断调整测试计划）、自动化测试
3、敏捷讲求合作，在敏捷项目组中，测试人员应该更主动点，多向开发人员了解需求、讨论设计、一起研究Bug
出现的原因。
软测测试V模型，
测试放在最后阶段，会让人误以为测试不重要
V模型最早是由Paul Rook在２０世纪８０年代后期提出的，目的是改进软件开发的效率和效果。是瀑布模型的变种
V模型明确指出了测试过程中存在着不同的测试，并指出这些测试与开发过程中的关系。
单元测试和集成测试应该检查程序是否符合软件设计的要求，系统测试则是检测系统的功能和性能是够满足系统设计的要求。验收测试则是确定软件是否符合用户的需求。
局限性：仅把测试放在编码后半阶段，会让人误以为测试不重要，未在需求阶段进行测试。
软件测试W模型，也叫双V模式，开发和测试并行
W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。
W模型特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的
W模型优点：有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，显著减少总体测试时间，加快项目进度。
局限性：需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。
配置管理和软件测试
学校图收馆借书，先查阅想要借的书借位置，在去相应的位置找书。
试想这是如何完成的？书要先分类，大类、小类，书架有编号，把书和书架的编号位置对应起来就有了书的坐标位置，
这种对图书的编号就是配置的一种。那么在软件测试中
.
配置管理：就是对代码，文档进行标识，确保项目的完整性和可追溯性
配置项：文档，代码，数据库，工具全部都是配置项，全部可配置。
配置管理与软件测试
软件开发过程中会产生大量软件产品（包括文档、源代码和数据等），且这些产品之间存在关联关系。同一软件产品也会发生变更，从而产生许多版本。
软件开发小组必须清晰地知道会有哪些产品、这些产品会有哪些不同的形式和版本。开发小组必须清晰地知道如何将产品的变更通知给受影响的小组。如果不能有效地了解软件产品及其变更，开发小组将很难组装这些软件产品，很难得到所需的软件产品
软件配置管理的好处
实施软件配置管理(SCM)，至少能给项目团队带来如下好处。
(1)能够对项目中的文档、代码等的变化进行有效管
理。
(2)能够方便地重现某个文件的历史版本。
(3)能够重新编译某个历史版本，使维护工作变得容易。
(4)能够使异地多团队开发、并行开发成为现实。
(5)从公司级看，实行统一的配置管理流程可提高项目组间人员流动时的工
作效率。
管理配置与软件测试
测试人员是SCM中的参与者，有些公司也会把测试人员和配置管理员合二为一。如果配置管理流程不规范，或者没有遵循一定的配置管理流程进行软件测试活动，也可能导致很严重的后果。
假设开发人员修正了一个Bug，然后找测试人员过去讨论，测试人员在开发人员的机器上重新测试了一下，发现Bug没再出现了，修复了，这时候，如果测试人员把缺陷关闭了，则可能导致缺陷莫名其妙地在用户那边又出现了。其实，原因可能仅仅是开发人员把这个Bug修改的代码没有提交的到配置管理数据库中。但是作为测试人员有没有责任呢？当然有，因为测试人员也没有按照规范的配置管理流程执行测试，测试人员应该从配置库取源代码编译后再测试，只有看到新的构建版本不再出现那个Bug，才能把缺陷库中的Bug关闭。
其次配置管理版本不对应，测不出bug