测试相关理论

一、软件测试

1.概念：验证软件功能是否能够满足用户的需求。（找bug,验证它没有问题)

 1979年，《软件测试艺术》：软件测试是为了发现错误而执行程序或系统的过程。

 1983年，《软件测试完全指南》，测试是以评价一个程序或者系统属性为目标的任何一种活动。测试是对软件质量的度量。

1983年，IEEE软件工程标准术语：使用人工或自动手段，来运行或测试某个系统的过程。其目的在于检验它是否满足规定的需求或弄清楚预期结果与实际结果之间的差别。

2.目的：验证软件有或者没有问题。

3.原则;以客户为中心，遵循软件测试的规范，流程，标准和要求。

4.需求：满足用户期望或正式规定文档(合同，标准，规范)所具有的条件和权能，包括用户需求和软件需求

    1) 用户需求：一般比较粗略，不能指导开发人员和测试人员进行工作。

    2) 软件需求：一般更详细，更加具体，可以指导开发人员和测试人员进行工作。

5.bug：

  1) 当需求规格说明书存在且正确，程序与需求规格说明书不匹配就是bug.

  2) 当没有需求规格说明书时，判断标准最终以用户的期望为标准.(即当程序没有实现用户最终预期的结果就是bug)

6.测试用例：为了实施测试而向被测试的系统提供的一组集合。该集合包括：测试环境，操作步骤，测试数据，预期结果。

   测试用例的编号是唯一的。

7. 为什么编写测试用例?

1) 不知道是否较全面的测试了所有功能  

2) 测试的覆盖率无法衡量

3) 对新版本的重复测试很难实施

4) 存在大量冗余测试影响测试效率

二、开发模型和测试模型

1.软件的生命周期：需求分析-->计划-->设计-->编码--> 测试-->运行维护。

2.瀑布模型(Waterfall  Model)

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

缺点：1) 依赖于早期进行的唯一一次需求调查，不能适应变化

           2) 流程单一，开发中的经验教训不能反馈应用于本产品的过程

           3) 风险往往到了后期的测试阶段才能显露出来，因此会措施尽早纠正的机会

应用场景：1) 需求变更比较小的项 目    2) 和之前项目比较类似的项目

3.螺旋模型(Spiral   Model) （渐进式的开发模型）

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

缺点：引入了非常严格的风险识别，风险分析和风险控制，这对风险管理的技能水平提高了很高的要求.

应用场景：适用于规格庞大，复杂度高，风险大的项目.

4.增量、迭代

  增量：逐块建造的概念(直接进入一小块进行处理，处理完，在进行另一块的处理)

  增量开发的优势：能显著降低项目风险

  迭代：反复求精的概念(先整体，后细节)

5.敏捷

敏捷开发模式与传统开发模式的区别？

1) 强调人与人之间的沟通

2) 轻文档(对需求规格说明书的依赖少)

3) 用户参与项目开发过程

4) 拥抱变化

敏捷特点：人数少，周期短

scrum里面的角色：

产品负责人PO （product  owner）

项目经理 SM  （scrum  master）

研发团队 Team (包括所有成员PO,SM........)

敏捷中的测试：轻文档(依赖少，若没有文档，则与客户进行沟通)

                         快速迭代(eg：App 每1~4周就有更新)

6.软件测试V模型

V模型的缺点：测试时工作放在最后，让人误以为测试工作不重要

                        发现缺陷的时间比较晚，修改的工作复杂。

7.软件测试W模型

W模型的缺陷：解决不了需求要频繁更改的项目需求

三、软件测试的生命周期

1.软件测试的流程（生命周期）：

需求分析--->测试计划--->测试设计--->测试开发--->测试执行--->测试评估

2.软件开发的生命周期

需求阶段--->计划阶段--->设计阶段--->编码阶段--->测试阶段--->运行阶段

3.描述一个bug

版本号、环境、操作步骤、预期结果、实际结果(一条测试用例只有一个结果)......

4.定义一个bug的级别

Blocker (崩溃)  、Critical (严重)、Major (一般)、Minor (次要)

5.bug的生命周期

New:发现新的bug,未经评审决定是否指派给开发人员进行修改。

Open:确认是bug,并且认为需要进行修改，指派给相应的开发人员。

Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归验证测试。

Rejected:如果开发人员认为不是bug,则拒绝修改。

Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。

Closed:修改状态的bug经测试人员的回归测试验证并验证通过，则关闭bug.

Reopen:如果经验证bug仍然存在，则需要重新打开bug，开发人员重新修改。

无效的bug：open--->closed         open--->rejected--->closed

6.执行测试

1) 打开待测试的系统

2) 打开测试管理工具用例模块，开始执行用例

3) 发现bug,进行复现确认bug的复现步骤

4) 记录bug

5) 沟通bug

6) 验证以前提交的bug

7) 确认本次测试完成 

8) 编写测试报告

7.如何发现更多的bug 

1） 软件测试的二八原则，80%的故障集中于20%的模块。

2) 开发人员的二八原则，80%的故障集中于20%的开发人员。

3)多进行逆向思维和发散性思维

4) 不要局限于用例和需求文档

5) 尽早介入项目，不等到开发的差不多了再进入项目