软件测试（2）

软件测试

什么是需求？

（1）软件是如何产生的
需求——开发软件及对应功能——测试软件功能——上线
（2）需求的概念
需求就是满足用户的期望；用户需求
规定的文档（合同，标准，规范）所需要的要求和权限；软件需求
产品经理收集用户需求从而转化为软件需求
（3）测试人员角度看待需求
需求是测试人员测试软件的依据；
需求是测试人员编写测试用例的依据，验证需求是合理的，需求的细化，从需求中提取测试项，然后再根据测试项去找出测试点，最后编写测试用例
需求是测试人员开展软件测试工作的依据。

为什么需求对软件测试人员如此重要

• 从软件功能需求出发，无遗漏的识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率，测试覆盖率比较高，会比较有条理
• 对于识别出的每个测试需求点，需要采用具体的设计测试用例的方法来进行测试用例的设计

什么是测试用例？

软件测试人员向被测试系统发起一组集合，包含测试环境，测试数据，测试步骤，预期结果。

什么是BUG？

如果软件需求规格说明书存在且合理，软件功能不符合软件需求规格说明书，我们就说是BUG。
如果软件需求不存在，如果用户的需求存在且合理，软件功能和用户需求不符合，我们就说是软件错误。

软件开发的五大模型

软件开发的生命周期：
需求分析——计划——设计——编码——测试——运行维护

（1）瀑布模型

特点：串行的，每个阶段独立，强调早期的需求分析，以及后期的测试工作
缺点：测试介入晚，前期的问题后期才会发现，导致错误失去了及时纠正的机会
（2）螺旋模型

特点：注重每一个迭代风险分析，适合于项目比较庞大，前期风险大的项目
缺点：风险分析需要投入专业的人力资源，成本比较高
（3）增量模型，迭代模型
增量模型：按照一定的增量去开发系统的功能。假如一个系统开发A、B、C、D四个模块，2周之内完成，那么第一周完成A、B模块，第二周完成C、D模块
迭代模型：第一周完成A、B、C、D四个模块的基本功能，第二周在上一周基础上完成剩余的较为复杂的功能
特点：抗风险能力强
（4）敏捷模型
拥抱变化，不会单纯的去注重文档，注重用户和研发团队之间的及时沟通和交流；注重在短期内交付一个高质量的可用软件，而不是各种文档
Scrum模型

角色：
PO产品经理：收集用户需求；把用户需求转化为user story
SM项目经理：保证整个敏捷流程的实施，负责召开各种会议，统计项目进度
ST研发团队：各种技能的人组成，开发人员、测试人员等
产品发布会：PO负责讲解user story，进行排序，确定出本期迭代的user story 形成Sprint backlog（本期迭代的内容）
迭代发布会：细化user story，分解任务，分配任务，确定任务完成时间
开发阶段每日站会：昨天干了什么，遇到的问题，今天的计划
产品演示会议：给甲方演示开发完的产品（软件系统），甲方会提出意见，PO整理后形成user story，加入下一次迭代
回顾会议：回顾一下本期迭代，哪做的好/不好，不好的地方下期迭代进行改进，优化敏捷流程

软件测试模型

（1）软件测试V模型

特点：串行，瀑布模型的变种
左边每一个阶段和右边每一个测试阶段一一对应，左边的每一个阶段都是右边每一个阶段的依据
缺点：测试介入比较晚，编码后才开始，导致前期问题，后期才发现，错误失去了最好的解决时机；不支持需求的改变
（2）软件测试W模型

双V模型，开发的每一阶段，测试的每一个阶段分别构成V字型
特点：测试和开发同时进行，测试在需求阶段就开始介入，有利于风险控制，测试的每一阶段和开发每一阶段一一对应
缺点：串行，不能够适应需求的变化，无法适应敏捷开发