软件测试概念篇

软件测试的目的和原则

• 目的:验证软件有或没有问题,可以分为两类：为了验证程序能正常工作的测试；为了验证程序不能正常运行的测试

  1. 测试并不仅仅是为了找出错误。通过分析错误产生的原因、阶段及错误发生的趋势。

​ (1) 帮助项目管理者了解当前软件开发过程中的缺陷，以便及时纠错、改进。

​ (2) 帮助测试人员设计出有针对性的测试方法，改善 测试的效率和有效性。

​ (3) 让开发人员知道错误产生的重灾区，加强自测试，

​ (4) 让客户清楚我们专业的质量保证团队,可以向他们提交一份满意的答卷。

2. 没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法。

• 原则：以客户/用户为中心，遵循软件测试的规范、流程、标准和要求。

  1. 测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。

  2. 在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。

  3. 充分注意测试中的群集现象。

     发现错误数目多，则残存错误数目也比较多。这种错误群集性现象，已为许多程序的测试实践所证实 这种现象对测试基于不同的立场，存在着两种完全不同的测试目的。

为什么会出现群集现象？

从用户的角度出发，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否可以接受该产品。而从软件开发者的角度出发，则希望测试成为表明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的要求，确立人们对软件质量的信心。因此，他们会选择那些导致程序失效概率小的测试用例，回避那些易于暴露程序错误的测试用例。同时，也不会着意去检测、排除程序中可能包含的副作用。

4. 严格执行测试计划，排除测试的随意性。

   测试计划应包括：所测软件的功能，输入和输出，测试内容，各项测试的进度安排，资源要求，测试资料，测试工具，测试用例的选择，测试的控制方式和过程，系统组装方式，跟踪规程，调试规程，以及回归测试的规定等以及评价标准。

5. 应当对每一个测试结果做全面检查。

   有些错误的征兆在输出实测结果时已经明显地出现了，但是如果不仔细地全面地检查测试结果，就会使这些错误被遗漏掉。

6. 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。

   如果发现某一程序模块似乎比其他程序模块有更多的错误倾向时，则应当花费较多的时间和代价测试这个程序模块。

什么是需求

满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求:

• 用户需求：

  可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。该需求一般比较简略。

• 软件需求：

  详细描述开发人员必须实现的软件功能。

• 联系

  软件需求是用户需求转换来的

什么是BUG

1. 当需求规格说明书存在时，程序和规格说明之间的不匹配才是BUG
2. 当前没有需求规格说明书时，判断标准以最终用户为准，当程序没有实现其最终用户合理预期的功能需求时，就是BUG

什么是测试用例

为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境，测试步骤，测试数据，预期结果，实际结果，测试功能模块，前置条件，重要性等

软件开发和测试模型

• 软件生命周期

需求分析->计划->设计->编码->测试->运行和维护

• 瀑布模型

特点

1. 瀑布模型在软件工程中占重要地位，是所有其他模型的基础框架
2. 瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模型

优点

1. 强调开发的阶段性
2. 强调早期计划及需求调查
3. 强调产品测试

缺点

1. 依赖于早期进行的唯一一次需求调查，不能适应需求的变化
2. 是单一流程，开发中的经验教训不能反馈应用于本产品的过程
3. 风险往往在后期的测试阶段才显露，因而是去及早纠正的机会

• 螺旋模型

特点：

一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。
这对于那些规模庞大、复杂度高、风险大的项目尤其适合。这种迭代开发的模式给软件测试带来了新的要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。因此，回归测试就显得尤为重要。

优点：

1. 强调严格的全过程风险管理
2. 强调各阶段的开发质量
3. 提供机会检讨项目是否有价值继续下去

缺点:

引入非常严格的风险管理，风险分析和风险控制，这对风险管理的技能水平提出来很高的要求，这需要人员，资金和时间的投入

• 增量，迭代模型

增量模型： 增量是逐块建造 ,

增量开发模型，鼓励用户反馈，在每个迭代过程中，促使开发小组以一种循环的、可预测的方式驱动产品的开发。

迭代模型: 迭代是反复求精

从一些软件规范开始, 然后开发该软件的第一个版本。在第一个版本之后, 如果需要更改软件, 则使用新的迭代来创建该软件的新版本。迭代模型的每个版本都在一个精确且固定的周期内完成, 这称为迭代。

区别：

增量通常和迭代混为一谈，但是其实两者是有区别的,增量是逐块建造 ,迭代是反复求精

举例

一个系统A B C D四个模块的功能需要完成 两周时间

迭代：第一周完成A B C D四个模块的基础功能，搭好基础框架

​ 第二周完成A B C D四个模块的后续功能，做功能的完善

增量：第一周 A B模块功能

​ 第二周 C D模块功能

• 敏捷开发模型

敏捷开发是一种以人为核心，以迭代方式循序渐进开发的方法，其软件开发的过程称为“敏捷过程”。

在这一过程中，软件项目的构建被切分成多个子项目，各个子项目的成功都经过测试，具备集成和可运行的特征。

价值观

开发方式：

1. SCRUM

SCRUM是一种迭代的增量化过程，用于产品开发或工作管理。它是一种可以集合各种开发实践的经验化过程框架

scrum的角色

1. 产品负责人
2. 流程主管
3. 开发团队

产品负责人/产品经理(Product Owner)

1. 定义产品的所有特性
2. 负责产品的投入产出
3. 负责最大化产品和开发团队工作的价值

流程主管/项目经理(Scrum Master)

1. 负责召开各种会议，协调项目，为研发团队服务，
2. 使得团队紧密合作，保持高效的生产率，
3. 保护团队不受外来无端影响

研发团队( Scrum Team )

由不同技能成员组成，通过紧密协同完成每一次迭代的目标，交付产品

scrum流程

1. 产品负责人负责整理用户故事(user story)，形成需求列表(product backlog)。

**user story: **

软件开发和项目管理中用日常语言或商务用语写成的句子 ， 是用户需求的简化表达，用一两句话表达完整的想法 。 只要求写下最有价值不能被忘记的东西，而这些内容足够帮助估算工作量以及与客户沟通。

user story的好处：

1. User Story强调通过一个简单的情境，具体的描述出软件在「使用人」的手上，是怎样被「操作」的。这样的描述可以让开发人员尽快能的贴近使用者的真实需求，而不是做错重点。
2. User Story可以帮助与客户之间进行很好的沟通，因为是情境描述文字，客户可以很轻松的根据这些情境排定优先顺序。

User Story 怎么写：

作为 <xxx角色> 我想要做 <yyy 的功能>，以便<实现 zzz 的好处>一条 User Story 只能有一个 User 角色。

**product backlog: **是一个具有优先级的需求列表， 并对每个需求进行了粗略的估算 ，根据需求的相对重要性进行排序( 优先级排序的目的是以保证每个项目按正确的次序交付以获得最高的直接和长期价值。 )

2. 发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。

sprint: 一次跌代开发的时间周期，一般最多以30天为一个周期.在这段时间内，开发团队需要完成一个制定的backlog,并且最终成果是一个增量的，可以交付的产品。

sprint backlog: 一个sprint周期内所需要完成的任务。由Scrum Team(开发团队)去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；

3. 迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计。
4. 每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。
5. 演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由product owner整理，形成新的story。
6. 回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。

测试人员在敏捷开发过程中怎么完成测试任务

1. 需求分析：依据需求文档提取测试点

通过分析需求描述中的输入、输出、处理、限制、约束等，给出对应的验证内容，并分析各个功能模块之间的业务顺序，和各个功能之间的传递信息和数据，对存在功能交互的功能项，给出对应的验证内容（功能交互测试）

2. 编写测试计划和测试用例

为项目需求而编制的一组测试步骤，测试数据以及预期结果，以便测试某个程序是否满足客户需求

3. 用例评审：确认用例是否覆盖到各个场景以及用例是否符合需求

用例评审主要是产品、开发和测试人员，针对测试用例能否用于项目的测试而做的工作。主要是为了减少测试人员执行阶段做无效工作（提交无效问题等），以避免三方需求理解不一致

4. 测试执行

测试执行是执行所有或部分选定的测试用例，并对结果进行分析的过程

5. 转化测试后的bug:

将执行完的有bug的测试用例关联敏捷协作中的缺陷。在敏捷协作中一个缺陷可以快速定位到测试用例，帮助开发者快速获取测试结果

6. 回归bug测试

通过敏捷中的迭代规划，制定团队的回归方案，积极跟开发人员沟通问题原因、修复的方案和影响

敏捷开发中测试人员扮演怎样的角色

1、测试工作的核心内客是没有变的，就是不断地找Bug，只是要调整好自己的心态，一切以敏捷的原则为主。

2、测试人员不能依赖文档，测试用例作用减弱，更多的采用思维导图、探索性测试（强调自由度，设计和执行同 时执行，根据测试结果不断调整测试计划）、自动化测试

3、敏捷讲求合作，在敏捷项目组中，测试人员应该更主动点，多向开发人员了解需求、讨论设计、一起研究Bug 出现的原因

2. XP
3. FDD
4. Crystal Methods
5. DSDM
6. ASD
7. 轻量型RUP

软件测试模型

测试模型总结

• 软件测试V模型

特点/优点：

明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系(左边的阶段开发和右边的测试阶段一一对应，并且是右边每一个测试阶段的依据)
V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求

缺点：

项目前期的风险和错误到后期测试阶段才发现，会失去问题及时纠正的机会

• 软件测试W模型

W模型增加了软件各开发阶段中应同步进行的验证和确认活动。

1. W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。
2. W模型特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的

优点：

有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，显著减少总体测试时间，加快项目进度。

缺点：

开发和测试依然是线性的关系，需求的变更和调整，依然不方便；
如果没有文档，根本无法执行w模型；对于项目组成员的技术要求更高！