文章介绍了软件测试的核心依据是需求，包括用户需求和软件需求，测试人员依据需求设计测试用例。测试用例是执行测试的关键，包含环境、步骤、数据和预期结果。BUG是预期与实际不符的情况。软件的生命周期包括需求分析、计划、设计、编码、测试和维护阶段。文章还探讨了瀑布模型、螺旋模型、增量迭代模型和敏捷模型，特别是敏捷开发中的Scrum框架及其流程。
目录
1.衡量软件测试结果的依据—需求
满足用户期望或者正式规定文档(合同，标准，规范)所具有的条件和权能，包含用户需求和软件需求。
1.1用户需求
可以简单的理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的要完成的任务，该任务比较简略。简单的来说：假如我们是使用者，我们需要开发人员实现登录功能。这就是一个用户需求
1.2软件需求
也可以叫功能需求，该需求会详细描述开发人员必须实现的软件功能。其实大多数时候公司会把用户需求转化为软件需求，开发人员和测试人员的工作直接依据软件需求。所以说，软件需求是非常重要的，是开发人员和测试人员工作的基本依据。
2.作为测试人员，如何看待需求
2.1需求是测试人员展开测试的依据
在具体设计测试用例的时候，首先搞清楚每一个业务需求对应多个软件功能需求点，再分析出每一个软件功能需求点对应多个测试需求点，然后针对每个测试需求点编写测试用例
所以大致的过程如下：业务需求 --> 软件功能需求点 --> 测试需求点 --> 测试用例
- 从软件功能需求出发，毫无遗漏的识别出测试需求是至关重要的，这直接关系到用例的测试覆盖率
- 对于识别出来的测试点，要采用具体的设计测试用例方法来进行测试用例的设计
3.什么是测试用例
测试用例是为了实施测试而向被测试系统提供的一组集合，通俗的讲：就是把我们测试系统的操作步骤用按照一定的格式用文字描述出来。这组集合包括：测试环境，操作步骤，测试数据，预期结果等要素。
3.1一个测试用例
3.2测试用例的重要性
- 测试用例是测试人员执行测试的重要依据
- 测试用例可以降低测试人员工作重复性，提高测试效率
- 测试用例可以保证测试质量
- 测试用例是自动化测试的重要依据
4.什么是BUG
BUG简单的理解就是预期和实际有偏差，为满足预期目标，说明实际的软件中存在错误。官方点来说：当且仅当规格说明是存在并且正确的，程序与规格说明不匹配才是错误。或者当规格说明没有提到的功能，判断标准以用户为主：当程序没有实现最终用户合理预期的功能要求时，就是错误软件。
5.软件的生命周期
软件的生命周期是指从产品软件的设想开始到软件不再使用而结束的时间，如果把软件看成有生命的事务，那么软件的生命周期可以分为六个阶段：需求分析，计划，设计，编码，测试，运行维护。
- 需求分析：主要分析需求是否合理，和需求是否完整
- 计划：确定项目由谁开发，由谁测试，什么时候开发结束，什么时候测试结束，什么么时候上线等.....
- 设计：开发人员如何实现项目，底层用的什么技术，最终输出一个文档
- 编码：开发人员开发软件，测试人员设计测试工具，设计测试用例
- 测试：执行测试，提交BUG，验收BUG
- 运行维护：将项目推到线上环境使用，如果发现BUG，此时需要修复重新上线
6.软件开发模型
6.1瀑布模型
瀑布模型在软件工程中占有这重要地位，是其他模型的基础框架。瀑布模型每一个阶段只执行一次，因此是线性顺序进行的开发模型。
- 优点：由于是线性模型，所以每个阶段做什么事情都非常明确
- 缺点：
- 由于整个阶段只有一个需求调查，所以不能很好的适应需求的变化
- 由于是单一流程，开发中总结的经验教训不能很好的总结并反馈
- 测试人员参与的时机太晚，以至于发现问题也太晚，如果发现问题，要不断的回溯
所以该模型适合较小的项目
6.2螺旋模型
在软件开发初期，需求不是很明确的时候，采用渐进式的开发模式，螺旋模型是渐进式开发模型的代表之一。 这种开发模式给软件测试带来了新的要求，不允许有一段独立的测试时间个阶段，测试必须跟随开发。
- 优点：
- 强调严格的全过程风险管理
- 强调各个开发阶段的质量
- 风险分析可以避免一些未知的问题
- 缺点：
- 风险分析一旦分析出现错误，就会带来损失
- 风险分析需要一定的成本
该模型适合规模庞大，复杂度高，风险的项目
6.3增量，迭代模型
增量开发能显著的降低项目的风险，结合软件持续构建机制，构成了当今流行的软将工程最佳实践之一。增量开发模型，鼓励用户反馈，在每个迭代过程中，促使开发小组以一种循环的、可预测的方式驱动产品的开发。因此，在这种开发模式下，每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本，意味着测试需要频繁进行，测试人员需要与开发人员更加紧密地协作。
通常许多人会把增量模型和迭代模型混为一谈，其实不然，他两还是有区别的。增量是逐块建造的概念，例如画一幅人物画，我们可以先画人的头部，再画身体，再画手脚……而迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。
再例如：有一个软件开发，包含了4个模块
增量模型：首先开发1，2模块，再开发3，4模块
迭代模型：可能同时开发四个模块，首先确定好基础矿建，再添加具体实现
6.4敏捷模型
敏捷宣言：
- 个体与交互重于过程和工具
- 可用的软件重于完备的文档
- 客户协作重于合同谈判
- 响应变化重于遵循计划
- 在每对比对中，后者并非全无价值，但我们更看重前者。
总的来说，敏捷模型是：轻流程，重交互，拥抱变化
敏捷开发包含多种方式，其中scrum是其中比较流行的一种
6.4.1scrum
scrum由 product owner(产品经理)，scrum master(项目经理)，team(研发团队)组成。
- PO：负责整理 user story（用户故事），定其商业价值，对其进行排序，指定发布计划，对产品负责
- SM：负责召唤各种会议，协调项目，为研发团队服务
- Team：研发团队由不同技能的人员组成，通过紧密协作，完成一次迭代目标，交付产品
6.4.2scrum基本流程
- 产品负责人负责整理user story，形成左侧的product backlog。
- 发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出 就是制定出这一期迭代要完成的story列表，sprint backlog。
- 迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每 个任务都有明确的负责人，并完成工时的初估计。
- 每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什 么问题。
- 演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取 得的成果。期间大家的反馈记录下来，由po整理，形成新的story。
- 回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达 到持续改进的效果。
7.软件测试模型
7.1V模型
- 特点：V模型是一个线性顺序的，左边是开发，右边是测试
- 优点：每个阶段做什么事情都非常的清除，测试被划分为许多种类型
- 缺点：测试人员届入的太晚，未在需求阶段就届入测试
7.2W模型
- 特点：W模型是由两个V组成，一个全是开发，一个全是测试。W模型测试的不仅是程序，还有需求，设计也要被测，测试与开发是同步进行。
- 优点：测试人员尽早介入，有利于尽早地全面的发现问题，测试和开发是并行的
- 缺点：需求，设计，编码等活动被视为串行；测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，下一阶段才能开始。所以不适于敏捷开发模型，不能拥抱变化
1077
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
