软件测试-概念学习

软件测试基本概念：

软件测试定义：验证软件功能是否满足用户的需求。

目的：验证软件有或没有问题。
原则：顾客就是上帝。以客户为中心，遵循软件测试的规范、流程、标准和要求。

什么是需求/strong>

定义：满足用户期望或正式规定文档（如合同）所具备的条件和权能，包含用户需求和软件需求。

权能：权利范围 的大小。

用户需求：不能指导发人员编写代码，测试 人员编写测试用例。
软件需求：开发人员可以指导开发人员编写代码，测试人员编写测试代码。
用户需求转换成软件需求：需要不断沟通，引导用户，挖掘需求的真正的需求。

注册时登陆的前置模块，登陆是注册的后置模块。随参照物不同，定位不同。

声控灯：使用范围，高于30分贝，开关。

*需求不一定是正确的，需求也需测试。比如客户想要一个赵雅芝版本的白素贞，比产品经理将需求定义错误。设计成王祖蓝版本的白素贞。或者产品经理将需求定位准确，但是开发部门将需求理解错误。开发出一个王祖蓝版本的白素贞。

什么是BUG

吃鸡例子

一局吃鸡, 已经进了决赛了, 你一身神装, 离吃鸡只有一步之遥, 但是游戏崩溃了~~~
凡是实现效果和需求不相符的都可以认为是BUG.

BUG的后果: 用户流失, 绩效血崩.

BUG的处理: 生产环境上的问题, 要第一时间回滚, 再慢慢定位.
BUG的态度: 心存敬畏, 但是不要害怕. 程序猿身上背负的BUG, 就是一个老兵身上的疤痕, 最值得骄傲的军功章

*专业定义：程序与规格说明之前不匹配。*

注意：以上说法是片面的，准确的来说：当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误bug。

当没有需求规格说明书时，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。

BUG是测试不完的，BUG需要在需求下测试，才更有意义。提升用户感受。

测试用例

举个例子：

比如男朋友一直打游戏，女孩子就会问男朋友，：我和游戏谁重要的送命题。来测试男朋友是否爱自己。女孩子一般希望男朋友在游戏和自己之间选择自己。

在这个小测试中：
人物（一对情侣），场景（游戏中），问题（输入），预期结果（输出）等构成的集合就叫做测试用例。

在软件测试中，测试用例的定义：

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

在这些操作步骤，操作步骤，测试数据，预期结果步骤不可少。

测试用例和实际结果的关系就像C++中类和对象的关系。一个测试用例可能有多个实际结果，实际结果是测试用例的实例化。

2.为什么要有测试用例

测试过程中可能会遇到以下问题

• 不知道是否较全面的测试了所有功能。
• 测试覆盖率无法衡量
  覆盖率=测试用例个数/功能点的个数
  功能点个数：按文档页数，按代码行数算法较复杂
• 对新版本重复测试很难实施。
• 存在大量冗余测试，影响效率。
  增加功能，添加测试用例，删除功能，原来的相关测试用例便作废，测不出真实结果了。必须删除这些冗余的测试用例。

测试用例练习：

手机上添加联系人的测试用例

开发模型和测试模型

1.软件的生命周期：

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

瀑布模型：

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

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

适合需求比较稳定的模型，或公司以前做过类似的项目

V模型明确指出了测试过程中存在着不同的测试，并指出这些测试与开发过程中的关系。

单元测试和集成测试应该检查程序是否符合软件设计的要求，系统测试则是检测系统的功能和性能是够满足系统设计的要求。验收测试则是确定软件是否符合用户的需求。

局限性：仅把测试放在编码后半阶段，会让人误以为测试不重要，未在需求阶段进行测试。

软件测试W模型，也叫双V模式，开发和测试并行

W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。

W模型特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的

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

局限性：需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。

配置管理和软件测试

学校图收馆借书，先查阅想要借的书借位置，在去相应的位置找书。
试想这是如何完成的要先分类，大类、小类，书架有编 ，把书和书架的编 位置对应起来就有了书的坐标位置，

这种对图书的编 就是配置的一种。那么在软件测试中
.

配置管理：就是对代码，文档进行标识，确保项目的完整性和可追溯性

配置项：文档，代码，数据库，工具全部都是配置项，全部可配置。

配置管理与软件测试

软件开发过程中会产生大量软件产品（包括文档、源代码和数据等），且这些产品之间存在关联关系。同一软件产品也会发生变更，从而产生许多版本。

软件开发小组必须清晰地知道会有哪些产品、这些产品会有哪些不同的形式和版本。开发小组必须清晰地知道如何将产品的变更通知给受影响的小组。如果不能有效地了解软件产品及其变更，开发小组将很难组装这些软件产品，很难得到所需的软件产品

软件配置管理的好处

实施软件配置管理(SCM)，至少能给项目团队带来如下好处。
(1)能够对项目中的文档、代码等的变化进行有效管
理。
(2)能够方便地重现某个文件的历史版本。
(3)能够重新编译某个历史版本，使维护工作变得容易。
(4)能够使异地多团队开发、并行开发成为现实。
(5)从公司级看，实行统一的配置管理流程可提高项目组间人员流动时的工
作效率。

管理配置与软件测试

测试人员是SCM中的参与者，有些公司也会把测试人员和配置管理员合二为一。如果配置管理流程不规范，或者没有遵循一定的配置管理流程进行软件测试活动，也可能导致很严重的后果。

假设开发人员修正了一个Bug，然后找测试人员过去讨论，测试人员在开发人员的机器上重新测试了一下，发现Bug没再出现了，修复了，这时候，如果测试人员把缺陷关闭了，则可能导致缺陷莫名其妙地在用户那边又出现了。其实，原因可能仅仅是开发人员把这个Bug修改的代码没有提交的到配置管理数据库中。但是作为测试人员有没有责任呢然有，因为测试人员也没有按照规范的配置管理流程执行测试，测试人员应该从配置库取源代码编译后再测试，只有看到新的构建版本不再出现那个Bug，才能把缺陷库中的Bug关闭。

其次配置管理版本不对应，测不出bug