1.啥是软件测试？

提到软件测试，可能我们一开始都认为，这不过是熟练使用一个测试软件，在软件开发完成后对软件的功能进行测试，找找BUG就算完成了。其实远不止如此，软件测试不仅要对软件的功能进行测试，此外还有软件性能的测试，大规模的自动化测试以及从各方面考验软件是否满足客户的需求等等。

我制定了以下的测试学习计划，从现在开始一起探索测试的世界吧！

2.测试和开发的区别

之前总听有人说测试多简单啊，开发可真是太难了！直到自己了解了测试后，才清楚上述言论：谬论！谬论也！
我们将从测试和开发的概念、广度和专业度来分析两者的区别：

3.测试和调试的区别

测试和调试的工作角色和执行时期以及目的都不太相同，如下图：
ps:其中，测试的参与角色包含开发的原因是：开发可能会在项目的单元/集成测试中也进行必要的测试工作.

4.软件测试人员需具备的素质

软件测试的地位可以说甚至不亚于软件开发，它关系到我们项目能否在预期时间完成，以及项目发布的重要阶段。同时，它贯穿于软件的整个生命周期，与最终软件的质量密切相关，更与公司的收益密切相关。因此，软件开发的从事人员必须要有明确的责任意识，刻意地培养自己的工作素质，我认为软件测试开发的从业者需要具备以下几种素质：

1. 综合能力：包括但不限于沟通能力，快速学习能力，开发能力以及测试能力。
   沟通能力能够帮助我们的测试人员提高事务开展的效率；快速学习的能力能够帮助测试人员在专业性和广度上有进一步的提升；开发能力能够帮助测试人员进行测试工具的开发；测试能力能够帮助测试人员更快，更精的完成软件测试，推动整个项目的开发进展
2. 优秀的测试用例设计能力以及自动化测试能力：优秀的测试能够能够帮助测试人员更快的发现缺点，自动化测试能够帮助测试人员更高效的完成项目功能的测试，推动项目进展。
3. 兴趣和探索性思维：兴趣就不用说了；探索性思维能够帮助测试人员进行系统错误的猜测和逻辑推理，有助于整理和分析出更多有针对性的测试关注点。

5.测试入门

在这个章节，我们将学习一些软件测试里边的术语具体是什么意思。

5.1 需求介绍/从测试人员的角度看需求

需求指的是满足用于期望和正式规定文档，例如合同、标准、规范所具有的条件和权能。通俗来说就是满足客户的需要，同时也要符合规范。我们常说的需求通常包含两部分，用户需求和软件需求：

• 用户需求：可以简单理解为是甲方提出的需求（合作需求），或者是终端用户使用产品时的需求（像市面上的游戏）。通常这种需求概括地较为简略且可行性有待研究，因此很少用来作为测试/开发人员的工作依据。
• 软件需求：也叫作功能需求，该需求详细的描述了开发人员需要实现的功能，因此常作为开发和测试人员工作的直接依据。
  
  

例如通过注册功能的需求，我们来对用户需求和软件需求进行比较：
再比如，站在测试的角度我们来根据软件需求——登陆需求对该需求完成以下测试，那么需要做下面的工作：

5.2 测试用例

测试用例是向被测试系统提供的一组数据集合。这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

5.3 bug介绍

什么是Bug？当程序没有实现最终的软件需求时，就是bug。

提到bug我们并不陌生，bug的种类可真是太多了，bug的出现可真是防不胜防！我们在开发中也可能会遇到各种各样的bug，阻止我们期待程序实现预期效果。但是，bug并不单单是程序中出现bug这么简单，通常情况下公司还对它进行了定级操作，以便根据不同级别的bug做出对应的应对策略。关于bug的详细信息，我们在下面的章节进行学习总结。

5.4 软件的生命周期

软件的生命周期是指从软件的设计开始到软件不再使用或使用结束的接个过程，软件的生命周期可以分为以下六大部分：

1. 需求分析
2. 计划
3. 设计
4. 编码
5. 测试
6. 运行维护

其中，每个阶段以及每个阶段所做的事情如下图所示：

6.开发模型

6.1 瀑布模型

瀑布模型是与软件完整生命周期最为一致的，该模型几乎对应上了软件生命周期的各个阶段。瀑布模型的流程如下：

瀑布模型在软件工程中具有重要地位，是所有其他开发模型的基础。与其他的开发模型相比，瀑布模型更加强调开发的阶段性，但是因为各个阶段是按照时间的先后顺序执行的，它的缺点也十分明显，当项目的需求发生变更时，可能需要从头复工程序；同时，因为线性的项目开发顺序，最终的成品在接近项目开发尾声时才能够被看到，而这也可能包含之前各阶段中遗留下来的错误，最终可能导致需要逐层追溯错误原因，演唱程序的开发周期和开发成本。

---

6.2 螺旋模型

一般的软件的需求在开发的初阶段需求不是很明确，会去采用渐进式的开发模型。螺旋模型就是开发模型的代表。螺旋模型的模型图如下：

对于规模大，复杂度高，风险大的项目，这种开发模型非常适用。它不再像瀑布模型那样只有在项目基本成型后才会进行测试，而是在每一次迭代的过程中，开发和测试都彼此迭代，降低了项目开发和需求变更带来的风险。与此同时，由于风险分析，控制和识别机制非常严格，这必然需要更高的风险管理的技能水平，因此也带来了更多的人员，资金和时间的投入。

---

6.3 增量、迭代模型

①增量模型就是将一个项目划分成多个不同的增量，这些个增量之间并发且独立地进行开发和上线，以求在最短时间内交付给客户使用。增量模型地模型图如下：

---

6.4 敏捷模型(scrum)

提到敏捷模型，就会联想到敏捷宣言：强调高效沟通，实现可交付软件。而在敏捷模型中最为流行的一种模型为scrum模型，关于上述模型，我们主要了解其中的三个角色和五个会议：

1. 三个角色：产品经理、项目经理和研发团队
2. 五个会议：需求发布会议、迭代计划会议、每日会议、发布会议和回顾会议

关于这五次会议的内容及产物我画了下面这张图：

---

7. 测试模型

7.1 测试V模型

V模型是瀑布模型的一种延申，它使得测试与开发的各个阶段相对应，如下图所示：

根据对应关系我们可以得到：单元测试和集成测试用来检验程序是否满足软件设计的要求；系统测试主要用来测试软件的功能和性能是否达到要求的水平；验收测试用来确定软件是否满足客户的需求或者是软件合同上的要求。缺点同样也是在开发工作结束后才进入测试阶段，会具有较大的潜在风险和修复成本。

---

7.2 测试W模型

w模型的特点就是测试和开发并行，在提高效率的同时也能够一定程度上规避在后期才能够发现的某些软件风险。w模型的模型图如下：

如上图所示，测试会在软件开发的各阶段中并行进行，同时进行软件设计可行性的验证和对应测试单元的准备工作；由于测试的加入，因此也更有利用更早发现软件缺陷以及制定应对措施，也能够进行软件测试阶段的测试计划指定和测试风险的预估工作。但同时由于需求、设计和编码等工作在工作上本质还是线性进行的，因此无法有效支持敏捷开发模式。

---

8.Bug的详细介绍

8.1 正确的描述bug && bug的级别

一个合格的bug描述应当至少包含以下几部分：

1. 明确bug出现代码版本
   ——让开发人员找到对应版本排bug
2. 明确bug出现环境
   ——进行bug故障的针对定位
3. bug重现步骤
   ——bug重现，有利于对比排除bug
4. 预期结果以及现bug结果
   ——更好的分析bug
5. 描述只包含一个bug
   ——条理清晰

比如，你要说某个网站的图片显示异常，你就不能说”XXX网站图片显示异常“，而要说：

关于Bug的级别：
可能每个公司对于bug的定级都不同，这样我们自己学习具体公司的规范文档。这里我们总结了几种常见的bug级别：

1. 崩溃-Blocker
   这是领导最不想见到的bug级别！该级别的bug可能会造成系统崩溃、死机、数据库数据丢失…很严重，写出这个bug大概率＝😨，我们一定要避免犯这种错误！
2. 严重-Critical
   该级别的bug可能会导致系统的主要功能丧失，用户数据丢失、功能和需求不符，等等。
3. 一般-Major
   该级别的bug通常指软件的某个功能没有正常实现，但是基本不影响软件的正常使用。
4. 次要-Minor
   性能缺陷、建议类问题或者是可以优化的方案，像文字排版、用户体验等等。

以上这些只是常见的bug级别，具体bug有哪些级别还是得去学习具体公司的文档规范。在开发中写出bug不可避免，但我们必须认真负责，做一个负责任的、头脑清醒的软件工程师！共勉！

---

8.2 bug的生命周期

bug不是只要解决就行了嘛？bug还有生命周期？是的！同样的，每一个公司对于bug生命周期的定义可能都是不太相同的，我们主要总结了常见的bug生命周期：

• New
  新发现的bug，需要进行bug评审确认
• Open
  确认是bug，提bug给对应的开发人员解决
• Fixed
  开发人员修复bug完成，交给测试人员进行回归测试
• Rejected
  认为不是bug，拒绝修改的状态
• Delay
  bug级别低，认为暂不需要修改，延后修改的状态
• Closed
  测试人员回归测试通过，关闭bug
• Reopen
  回归测试未通过，重新提该bug，开发人员重新修复

关于这几种bug状态之间的转换，我总结成了以下一张流程图：

---

9. 人际关系

9.1 “我与开发"之bug引起的"争执”

在测试工作中，因为测试向开发提bug而引起的彼此之间的争执我想应该很常见且不可完全避免。
😄作为测试人员，我们首先不能怕争执的发生，在争执发生后，我们要要具有辩证思维能力，要先从自己的身上找原因，比如，我的bug描述是否足够清楚；确认无误后，我们要试着让自己和开发站在用户的角度考虑问题，让彼此都能过考虑到该bug为用户带来的困扰以及公司的效益问题；促使并监督开发人员完成bug的修复工作。
😄同时，作为开发人员，当测试人员向我们提起bug时，我们不应当推脱，而应认真反思总结，并虚心学习，尽快修复bug并交由测试人员进行测试，推动项目进展并且保障公司收益。总之，冲突发生并不可怕，可怕的是不去解决，无脑推拖，这只会造成更加恶劣的影响。

---

**//写在最后//**
😄我想：能够让开发人员修改bug最多的测试人员才是好的测试工程师，能够接收测试人员提的bug并修复最多的开发人员才是一个优秀的开发工程师。不论扮演何种角色，我们都应该对自己的职业负责，对客户和公司负责，切实做好自己的本职工作，才能够称得上是一个合格的软件工程师！加油，共勉！