软件测试的基础概念及理解

什么是软件测试？

软件测试就是为了验证一个软件的功能是否满足用户的需求。一款产品上线之前必须通过测试人员测试，测试它是否符合用户的要求，尽可能多的发现缺陷，以保证用户体验，测试在一个项目的开发过程中是非常重要的一环，测试人员就是产品上线前的最后把关者，只有测试通过了才可以发布上线。

软件测试的目的

软件测试首先是为了验证这个软件是正确的，然后尽可能多的找出软件中可能存在的问题，最后使它能够满足用户的需求。

什么是软件需求？

需求：满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求。
用户需求：可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。该需求一般比较简略。
软件需求：或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。
用一个例子来说，用户需求就是你的女朋友跟你说“我饿了”，而软件需求就是你跟女朋友沟通，你想吃什么，米饭炒菜还是油泼面，反复沟通理解了用户需求之后，再考虑怎么做等，这些步骤就是软件需求。

什么是bug？

bug就是需求的缺陷，当且仅当需求规格说明书存在并且是正确的，程序和规格说明书之间不匹配就是错误。如果是规格说明书没有提到的功能，判断标准以最终用户为准，当程序没有实现其最终用户预期的功能要求时，就是软件错误。

简单来说， 当软件的功能不能满足用户的需求，或者测试的时候界面出现的结果与合理的规格说明书不一致时，就可以认为这是一个缺陷。

软件的生命周期

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

5种开发模型

瀑布模型

瀑布模型的每个阶段都只执行一次，是线性顺序进行的软件开发模式。适用于需求稳定或需求变更小的模型。
优点：

• 强调开发的阶段性；
• 强调早期计划及需求调查。
• 强调产品测试

缺点：

• 依赖早期进行的唯一一次需求调查，不能适应需求的变化；
• 风险在后期的测试阶段才能发现，不能及时改正。
• 可以运行的产品用户很晚才能看到，给项目带来很大风险。

螺旋模型

一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型适用于规模庞大，复杂度高，风险大的项目。这种迭代开发的模式给软件测试带来了新的需求，它不允许有一段单独的测试时间和阶段，测试必须跟随开发的迭代而迭代。因此，回归测试比较重要。
优点：

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

缺点：

• 对风险管理的技能水平提出了很高的要求，需要人员、资金和时间的投入。

增量、迭代

增量开发能显著降低项目风险，它鼓励用户反馈，在每个迭代的过程中，促使开发小组以一种循环的、可预测的方法来进行产品的开发。在这种开发模式下，每次迭代都意味着需求有可能更改，也就意味着测试需要频繁进行，测试人员和开发人员需要更加紧密的合作。
增量和迭代通常混为一谈，但两者还是有区别的。比如说，画一幅人物画，增量是先画头部，再画身体，再画手脚，而迭代是先画整体轮廓，再逐步去细化。

敏捷

敏捷开发方式很多，scrum是比较流行的一种。scrum将产品的开发分成若干小迭代，迭代的周期比较频繁，一般是1-4周，参与的团队成员一般是5-9人。每日例会控制到10-15min，内容是昨天做了什么，有什么问题，今天预计做什么。每期迭代要完成的用户故事是固定的，并且每次迭代会产生一定的交付。

四个价值观：

• 强调人与人之间的沟通
• 轻文档（对文档要求比较低）
• 要求用户参与
• 拥抱变化

软件测试模型

V模型

V模型是一个串行的测试模型，当需求发生变化的时候会比较麻烦，并且测试介入比较晚，发现问题晚，这会导致我们认为测试不重要。

W模型

W模型是开发与测试同步的测试模型。优点是发现问题早，为解决问题减少成本，提高项目进度和效率，减少风险。缺点是对程序测试必须等编码完成，整体来说因为还是串行，所以不能适应敏捷开发模型这种需求变化大的开发模型。
解决方法：敏捷测试

软件测试的生命周期

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

在需求分析阶段，测试人员可以通过需求串讲等方法去了解需求的目的，然后根据需求去编写测试计划，测试方案等，根据对需求的分析，确定需求的范围，然后才能执行测试计划。接下来开始测试用例的编写，根据测试计划里的内容编写测试用例，最终还要进行评审，评审通过的测试用例才是可以用的测试用例。然后执行测试，这时开发人员已经写完了代码，把代码交给测试人员进行测试，首先需要进行冒烟测试，通过后再进入系统测试，不通过就要交给开发人员进行修改，改完还要再进行回归测试，避免因为修改了部分功能而影响了其他功能。
在测试的过程中，一旦发现缺陷要进行管理和跟踪，直到缺陷被修改，如果项目组时间充足还要进行交叉测试，自由测试。最后是根据上一步的测试结果来进行测试报告的编写，对缺陷进行分析并且给出最终结论，通过或者不通过。

如何描述一个bug?

一个合格的缺陷描述应该包括：
1、发现问题的版本，问题出现的环境
2、单一准确原则，即每份报告中只针对一个缺陷进行准确的描述
3、可以在现原则，即要提供缺陷的准确操作步骤，方便开发人员快速再现，能及时的修改
4、完整统一原则，提供完整的缺陷步骤和信息
5、短小简练，要求描述问题重现的最短步骤

bug的级别

• Blocker（崩溃、致命的）：
  一般指阻碍开发或测试工作的问题，比如说造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。
• Critical（严重）：
  一般指系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。
• Major（一般）：
  功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等。
• Minor（次要）：
  界面、性能缺陷，建议类问题，不影响操作功能的执行。比如说：错别字、界面格式不规范，提示语丢失，文字排列不整齐，光标位置不正确，用户体验不好等。

bug的优先级

立即解决，高优先级，正常排队，低优先级

bug的生命周期（缺陷的七种状态以及他们之间的转换关系）

bug的七种状态： NEW，OPEN，FIXED，REJECTED，DELAY，REOPEN，CLOSED

具体转换关系可以总结为下面这张图：

New代表新发现一个bug，如果确认是缺陷并且需要进行修改就分配给开发人员，并将状态置为Open。开发人员修改之后将标识改为FIXED修改状态，等待测试人员进行回归测试。
测试人员验证之后，如果通过就将状态改为CLOSED，不通过则改为REOPEN，再次发给开发人员进行修改。
如果开发人员认为不是BUG，就将状态置为REJECTED，而如果确定是缺陷，但不是大问题，就可以将状态改为DELAY，最后再进行修改。
注意：所有缺陷的最终状态都是Closed