我们来谈谈软件测试

"Planning to fly away" 

---

什么是软件测试？

        如何理解软件测试呢？软件测试又是什么个东东呢？不知道各位看到测试二字有什么别的想法没有，反正就我个人而言，受过十几年应试教育的我，会把测试联想为 "检测"，无非换句话说，就是“考试”。

        如果我们将一个软件从开发、到上线推广给用户使用的这样一个生命周期，比喻为一个小小的学期，每一学期里包含的“测试”，像月考、期中考，甚至还有周考……每一个考试，其本质就是对一个阶段的检验。开发工程师就像那些支支吾吾、半天难以下笔的考生，而测试工程师更像那群威严的教师一般。

       诚然，学生考试是为了查缺补漏，帮助学生自己找到了缺失的漏洞，掌握不清楚的知识点。而对于软件测试来说，“就是找BUG，发现缺陷”。 

        “软件测试只是一个样本试验，具有不可穷尽性”。正如，一次所谓的卷面，不可能将所有你接触过、学习过的知识点考个精光。

        

软件测试  vs 调试:

目的:

● --调试: 确保程序做了程序员想它做的事情。

● --测试: 确保程序解决了它该解决的问题。 

参与角色不同:

● --调试: 由开发人员完成。

● --测试: 由测试人员和开发人员来执行，黑盒测试主要由测试人员完成、单元/集成测试主要是由开发人员执行。

执行的阶段不同:

● --调试: 一般在开发阶段。

● --测试: 贯穿整个软件开发生命周期。

 

测试岗位:

        一个软件的基本要求就是满足“需求”(至于如何理解需求，之后会细讲)，除此之外，还会牵涉到性能、安全等等问题，所以测试岗位的工程师是多样的。

      当然不仅仅只有这些，也有系统测试工程师，嵌入式测试工程师，硬件测试工程师等其他方面的测试岗位。
 

软件测试基础

(1) 如何理解需求？

        怎么理解需求呢？也许可以换一种问法，"你现在想要什么？"，比如说我现在想要一个心仪的offer，或者我想要花不完的money，亦或者好看的富婆……当然，这是开玩笑的。在软件测试中对于需求的定义有两种：

☀ 用户需求: 终端用户使用产品时必须要完成的任务。该需求一般比较简略。

☀ 软件需求: 或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。

        而我们开发、测试人员是着眼于软件需求，即开发这个软件出来是干什么的。比如，你想开发一个像"大麦"那样的抢票软件，但却阴差阳错地开发出来一款像"qq\微信"那样的聊天工具。当然，实际中并不会像举例那般无厘头。大多数公司在进行软件开发的时候会把用户需求转化为软件需求，所以开发人员和测试人员工作的直接依据就是软件需求。

        而软件需求是谁写的？当然不是作为打工仔的我们，毕竟我们不是提出问题，而是解决问题的人。

        

(2) 需求场景

        假如现在有一个以用户登录为场景用例:

        掌握需求的目的，是为了更好地编写测试用例。

如何才可以深入理解被测试软件的需求？

        从软件功能需求出发的，无遗漏的识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率。只有今早掌握软件需求，在需求和分析阶段介入，才有可能从业务需求的角度去设计针对性明确，从终端用户的使用场景到端到端的覆盖率较高的测试用例集。

(3) 测试用例的概念

        想必诸位读者一定用过LeetCode之类的刷题网站，当你的代码出现错误时或者不能达到预期结果时，这些刷题网站会反馈给你 一些测试数据，并且会告诉你这些测试数据是怎么使用的，以及它们最终输出的结果是什么，而预期结果又是什么……

        因此，测试用例不是单纯的测试数据，而是一组集合，它涵盖：

        “测试环境、操作步骤、测试数据、预期结果等要素”。

        例如，我们现在想要测试一款聊天软件的登录功能:

 

为什么需要测试用例？      

        测试用例解决了两个问题: "测什么，怎么测"。

        当你发现你测试的代码模块出现bug了，你直接甩给开发说，“诶，哥们你的代码我测试出来有问题，你自己看一看”。等着，人家问你哪里有问题，你怎样测时，你却不得不装傻，因为你其实没记录你测试的过程。开发也是苦笑，拿着自己编写的用例拿去调试，然而却没有出现任何问题时，我想他心中的怒火一定胜过了他的仁慈。显然，这么做是不好的。

● 测试用例提高测试人员的工作效率(降低测试的重复性)。

● 测试用例是建立自动化的基础(所谓自动化，就是替代人执行测试)。                

(4) Bug

        关于bug，想必诸位也一定不会陌生，那个卡在计算机中的神奇"臭虫"。在软件中，这种错误一般定义为:"程序与规格说明不匹配"。但这种说法是片面的，准确的来说:

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

        

如何描述一个BUG？

        描述一个BUG，通常需要一下几步:

● 发现问题的版本：开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。

● 问题出现的环境：详细的环境描述有利于故障的定位。

● 错误重现的步骤：描述问题重现的最短步骤。

● 预期行为的描述：要让开发人员知道正确的行为是什么，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。

● 错误行为的描述：描述错误的现象。crash等可以上传log，UI问题可以有截图。

        等等。

如何定义BUG的级别？

        bug的定义每个公司都不一致，在定义级别之前需要查看公司规范。

● Blocker(崩溃)：比如一些系统级的错误，会导致服务器直接挂掉，数据丢失等等。

● Critical(严重)：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失等等。

● Major(一般)：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。

● Minor(次要)：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。
 

BUG的生命周期                

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

    

---

开发模型和测试模型

(1) 软件的生命周期

        随着软件工程学科的发展，人们对计算机软件的认识逐渐深入。软件工作的范围不仅仅局限在程序编写，而是扩展到了整个软件生命周期。就像人一样，有他的出生，有他的生长，也有他的消亡。

        软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。

        可以分成6个阶段: "需求分析、计划、设计、编码、测试、运行维护"。 

(2) 开发模型 

瀑布模型（Waterfall Model)                

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

优点:

○ 强调开发的阶段性；

○ 强调早期计划及需求调查；

○ 强调产品测试；

缺点:

○ 依赖于早期进行的唯一一次需求调查，不能适应需求的变化；

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

○ 风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会(测试介入太晚)；

        在瀑布模型中，测试阶段处于软件实现后，这意味着必须在代码完成后有足够的时间预留给测试活动，否则将导致测试不充分，从而把缺陷直接遗留给用户。
 

螺旋模型(Spiral Model)

        一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。        

优点:
○ 强调严格的全过程风险管理；

○ 强调各开发阶段的质量；

○ 提供机会检讨项目是否有价值继续下去；
 

缺点:

○ 引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平提出了很高
的要求；

        

增量\迭代\敏捷

        增量开发能显著降低项目风险。增量开发模型，通过鼓励用户反馈，在每个迭代过程中，促使开发小组以一种循环的、可预测的方式驱动产品的开发。因此，在这种开发模式下，每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本，意味着测试需要频繁进行，测试人员需要与开发人员更加紧密地协作。        

       2001年，以Kent Beck、Alistair Cockbum、Ward Cunningham、Martin Fowler等人为首的“轻量”过程派聚集在犹他州的Snowbird，决定把“敏捷”(Agile)作为新的过程家族的名称。在会议上，他们提出了《敏捷宣言》: http://agilemanifesto.org/iso/zhchs/manifesto.html

        敏捷开发有很多种方式，其中scrum是比较流行的一种。

(3) 测试模型

软件测试v模型        

        V模型最目的是改进软件开发的效率和效果。是瀑布模型的变种。 

特点: 左边是开发，右边是测试。类似于瀑布开发模型。

优点:

○ 测试被划分为多种类型；

缺点:

○ 仅仅把测试作为在编码之后的一个阶段，测试人员介入太晚，发现问题时间延后；

软件测试W模型        

优点:

○ 试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的；
○ 测试人员今早介入需求，有利于尽早地全面的发现问题；

缺点:

○ 测试人员和开发人员本质仍然是串行的，保持着一种线性的前后关系；

○ 无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。

---

本篇到此结束，感谢你的阅读。

祝你好运，向阳而生~