测试概念篇
目录
1.软件测试的目的和原则
目的：验证软件有没有问题
原则：以客户为主，遵循软件测试的规范、流程、标准和要求
从软件测试的目的出发，可以分为两类：
为了验证程序能否正常工作的测试；为了验证程序不能正常工作的测试。
2.需求
用户需求：比较简略，粗；不能指导研发和测试人员工作
软件需求：或者叫功能需求，正式文档的条件和权能，比较详细，可以指导研发和测试人员工作，该需求会详细描述开发人员必须实现的软件功能
软件需求是测试人员进行测试的基本依据
权能：可以理解为权利
用户需求转换为软件需求最核心就是沟通；
产品经理和用户经常沟通；
3.Bug
有两种：
第一种：当且仅当规格说明存在并且正确，程序与规格之间的不匹配才是错误
第二种：当没有需求规格说明书时，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误
4.测试用例
测试用例视为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境，操作步骤，测试数据，预期结果等要素；
测试过程中会遇到以下问题：不知道是否较全面的测试了所有功能--测试的覆盖率无法衡量，对新版本的重复测试很难实施，存在大量冗余测试，影响测试效率；
测试用例的产生就是为了解决上述的问题。
eg:
手机打电话：
1.输入姓名，有对应的电话号码，进行拨打，没有对应的电话，不拨打
2.手机有信号，可进行拨打，没有信号，不能打出去
3.手机是否有电
4.手机中是否安装手机卡
5.拨打过去对方的手机占线，关机，无人接听
6.卡里是否有电话费，能否拨打过去
7.对方已将你拉黑，电话打不过去
8.此款手机是否有拨打电话的功能
9.自己的听筒和对方的听筒是否完好，能听到声音
10.用耳机的话，看耳机是否能听见，或者有外扩
11.电话号码的的长度
12.输入手机号是否有字符
13.手机号码的号段
14.设置快捷键
15.打座机，打短号
17.地域问题，同一省份，不同省份，国际之间
18.对方销号，封号
19.接听中，可不可以再接另外一条电话
5.开发模型和测试模型
随着软件工程学科的发展，人们对计算机软件的认识逐渐深入。软件工作的范围不仅仅局限在程序编写，而是扩展 到了整个软件生命周期，如软件基本概念的形成、需求分析、设计、实现、测试、安装部署、运行维护，直到软件 被更新和替换新的版本。软件工程还包括很多技术性的管理工作，例如过程管理、产品管理、资源管理和质量管 理，在这些方面也逐步地建立起了标准或规范。
5.1软件的生命周期
六个阶段：需求、计划、设计、编码、测试、运行维护
5.2瀑布模型（Waterfal Model）
串型的：需求-->计划-->设计-->编码-->测试
缺点：依赖与早期进行的唯一一次需求调查，不能适应需求的变化
由于是单一模型，串行的，开发中的经验教训不能反馈应用于本产品的过程，风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会
优点：各个阶段分配很明确；强调开发的阶段性；强调早起计划及需求调查；强调产品测试；
项目需求比较稳定，变化比较少的项目适合用瀑布模型
5.3螺旋模型（Spiral Model）
强调的是风险是渐进型的
适合模型庞大的、复杂度高、风险大的项目
优点：有着严格的全过程的风险管理
缺点：项目进度可能长一点，因为每一阶段都要进行风险分析，需要人员、资金和时间的投入，引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平提出了很高的要求
5.4增量、迭代
增量：它是逐块建造的概念，块与块之间没有联系
增量开发能显著降低项目风险，结合软件持续构建机制，构成了当今流行的软件工程佳实践之一。
迭代：是反复求精的概念，从轮廓先整体的概念
核心是降低项目的风险
5.5 敏捷
十二个宣言（核心的四个）
1）人与人之间的沟通：个体与交互重于过程和工具
2）轻文档：可用的软件重于完备的文档，他不等于没有文档（没有文档的敏捷是耍流氓）
3）客户全程参与：客户协作重于合同谈判
4）拥抱变化：响应变化重于遵循计划（注意时间点）
敏捷的开发方式：scrum是比较流行的一种
5.5.1 scrum
scrum组成成分：产品负责人（ product owner ,简称po） 敏捷教练（scrum master,，简称sm）团队（team）
沟通很重要
迭代开发：周期从一到四周不等，但不会超过4周；人数一般5到9周；开会不超过15分钟，一个人三句话；
基本流程：
1）产品负责人负责整理user story，形成左侧的product backlog
2）发布计划会议
3）迭代计划会议
4）每日例会
5）演示会议
6）回顾会议
5.6 敏捷中的测试
挑战1：轻文档
挑战2：快速迭代
1）测试工作的核心内客是没有变的，就是不断地找Bug，只是要调整好自己的心态，一切以敏捷的原则为主。
2）测试人员不能依赖文档，测试用例作用减弱，更多的采用思维导图、探索性测试（强调自由度，设计和执行同 时执行，根据测试结果不断调整测试计划）、自动化测试
3）敏捷讲求合作，在敏捷项目组中，测试人员应该更主动点，多向开发人员了解需求、讨论设计、一起研究Bug 出现的原因。总结：
调整好自己的心态
自动化测试代替手工测试
团队之间的合作
敏捷开发模型流程：
po整理 USER STORY----确定每次迭代需要的 user story----user story 分配，时间评估----开发中----开发完成-----测试中---测试完成-----发布上线
5.7 软件测试v模型
白盒测试：用自己的代码去测研发人员的代码
黑盒测试：手工测试
用户需求：测试人员了解需求的目的，大概的功能
需求分析与系统：测试人员制定测试计划
编码阶段：进行测试用例的编写
单元测试和集成测试一般由开发人员或者白盒测试工程师
单元测试：用白盒测试
集成测试：有白盒测试和黑盒测试
系统测试：测试人员核心的工作，做的最多的工作，
五个阶段为：数据准备，环境搭建，测试执行，缺陷管理，测试报告的输出
验收测试：测试人员为客户测试，策划人员对客户进行培训，指导，并收集用户使用中的反馈和建议
（和瀑布模型优缺点很相似）
优点：把每个阶段划分的更详细
缺点：发现问题比较晚，修改成本大，给人一种测试不重要的错觉
5.8软件测试W模型（双V模型）
测试与开发是并行的
用户需求：了解项目做什么
w模型的特点：测试的对象不仅是程序、需求、设计等同样要测试，测试与开发同步；
w模型的优点：有利于尽早的全面的发现问题，
局限性：需求、设计、编码等活动被视为穿行的，测试和开发活动也保持着一种线性的前后关系
6.配置管理和软件测试
在参与当代软件开发时，必须具备软件配置管理方面的基本素养。不懂软件项目的配置管理，就不懂软件开发管 理。没有对软件项目进行配置管理，其实就没有进行软件项目开发管理。
6.1 什么是配置管理
配置管理( Configuration Management)是通过对在软件生命周期不同的时间点上的软件配置进行标识，并对这些 被标识的软件配置项的更改进行系统控制，从而达到保证软件产品的完整性和可溯性的过程。
6.2 软件配置管理的应用
软件开发过程中会产生大量软件产品（包括文档、源代码和数据等），且这些产品之间存在关联关系。同一软件产 品也会发生变更，从而产生许多版本。软件开发小组必须清晰地知道会有哪些产品、这些产品会有哪些不同的形式 和版本。开发小组必须清晰地知道如何将产品的变更通知给受影响的小组。如果不能有效地了解软件产品及其变 更，开发小组将很难组装这些软件产品，很难得到所需的软件产品。
6.3 实施配置管理的好处
(1)能够对项目中的文档、代码等的变化进行有效管 理。
(2)能够方便地重现某个文件的历史版本。
(3)能够重新编译某个历史版本，使维护工作变得容易。
(4)能够使 异地多团队开发、并行开发成为现实。
(5)从公司级看，实行统一的配置管理流程可提高项目组间人员流动时的工 作效率。
6.4 配置管理与软件测试
测试人员是SCM中的参与者，有些公司也会把测试人员和配置管理员合二为一。如果配置管理流程不规范，或者没 有遵循一定的配置管理流程进行软件测试活动，也可能导致很严重的后果。
测试人员应该从配置库取源代码编 译后再测试，只有看到新的构建版本不再出现那个Bug，才能把缺陷库中的Bug关闭。
