测试【一】：软件测试、软件测试的目的和原则、需求、BUG、测试用例、软件的生命周期、开发模型、测试模型、软件测试的生命周期、BUG的级别和生命周期

1.什么是软件测试？

答：软件测试就是证明软件不存在错误的过程，为了证明程序能够正确运行。

2.软件测试的目的是什么？

答：验证软件有没有问题。

3.软件测试的原则是什么？

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

4.什么是需求？

答：满足用户的期望或规定的文档(合同，规范，标准)所需要的条件或权限，需求包括用户需求和软件需求。
软件需求从用户需求转换而来。
用户需求转换为软件需求的核心是沟通。
软件需求是测试人员进行测试工作的基本依据。

5.什么是bug？

答：
（1）当且仅当规格说明存在并且正确，但程序和规格说明之间不匹配，称之为软件错误（BUG）。
（2）当用户的需求存在并且正确，程序没有满足用户的需求，则称之为BUG，就是软件错误。

6.什么是测试用例？

答：
测试用例(Test Case)是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

7.软件的生命周期

答：
软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。 如果把软件看成是有生命的事物，那么软件的生命周期可以分成6个阶段，即需求分析、计划、设计、编码、测试、运行维护。

8.软件开发模型

（1）瀑布模型（Waterfall Model）

瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。
优点：强调开发的阶段性；强调早期计划及需求调查；强调产品测试。
缺点：依赖于早期进行的唯一一次需求调查，不能适应需求的变化；由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程；风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。

（2）螺旋模型（Spiral Model）

螺旋模型是渐进性开发模型。
适用于前期需求不明确，项目规模庞大、复杂度高、风险大的项目。
优点：强调严格的全过程风险管理；强调各开发阶段的质量；提供机会检讨项目是否有价值继续下去。
缺点： 引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平提出了很高的要求。这需要人员、资金和时间的投入。

（3）增量模型

逐块建造的概念。
例如：一个项目，分了四个模块（1,2,3,4），第一天先完成1,2模块，第二天完成3,4模块，这就是增量模型。

（4）迭代模型

反复求精的概念。
例如：一个项目，分了四个模块（1,2,3,4），第一天先完成1,2,3,4模块的基础部分，第二天完成复杂的部分。

（5）敏捷

scrum：scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。
scrum的基本流程：
产品负责人负责整理user story，形成product backlog。
发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。
迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计。
每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。
演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story。
回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。

9.测试模型

（1）V模型

目的是改进软件开发的效率和效果。是瀑布模型的变种。
局限性：仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试。

（2）W模型

W模型由两个V字型模型组成，分别代表测试与开发过程。测试与开发是并行关系。
W模型特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的
W模型优点：有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，显著减少总体测试时间，加快项目进度。
局限性：需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑

10.软件测试的生命周期

需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估

11.BUG的级别

Blocker（崩溃）：造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。
Critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。
Major（一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。
Minor（次要）：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。

12.BUG的生命周期

New：新发现的Bug，未经评审决定是否指派给开发人员进行修改。
Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
Fixed：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
Rejected：如果认为不是Bug，则拒绝修改。
Delay：如果认为暂时不需要修改或暂时不能修改，则延后修改。
Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
无效的bug：open->closed open-rejected-closed。