软件测试之测试执行和总结

测试执行阶段

在完成测试设计的工作后，正常情况我们都迎来一段摸鱼的快乐时光，因为开发写代码的速度是没有我们写文档来的快的，所以我们需要等待开发完成对应的代码编写。

• 集成测试
  当开发写完接口的代码后，我们就可以开始做接口测试了。

• 系统测试
  当开发已经完成了整个软件的开发后，软件的所有要求的内容都已经完成了，这个时候，我们就可以开始对软件的功能、易用性、安全性、性能、UI、兼容性等等内容进行测试。在系统测试阶段，我们应该有限确保功能测试没问题，在功能没问题的条件下，再区做其他的测试内容。

正常情况下，我们应该是先做集成测试，然后再做系统测试的。但是在实际的工作中，不一定会按理论的顺序来进行，而是按老板的要求的顺序来进行，所以在工作中要学会灵活处理。甚至有的公司不要求做集成测试，直接上来就是系统测试了。

测试执行的过程

不管你是对什么内容进行测试，他们的测试执行的过程都是一样的。只是测试的内容不同而已。

1. 确认测试环境
   不管你是测试的接口、功能、性能或者其他的，首先你要确认的就是在哪里做测试。
   也就是说，测试环境有没有搭建好，如果已经被别人搭建好了，那么我们就问清楚具体的地址之类的信息，然后确认测试环境上的版本是正确的，就可以开始测试了。如果测试环境没有搭建，需要自己去搭建，那么我们就要问情况，服务器在哪里，需要哪些东西，搭建的步骤大概是什么，对应的所需要的代码包在哪里？然后自己去服务器上完成测试环境的搭建。

2. 执行测试用例
   对照着用例，一步步的去执行，照着做测试，预期结果和实际结果做对比。

3. BUG的跟踪管理
   在我们做测试执行的过程中，我们肯定就会发现BUG，发现了BUG我们就需要去记录BUG，BUG多了后，我们就需要实时的去关注BUG的情况，对他们进行管理。在这里我们一般就会使用BUG管理平台，比如禅道来进行操作。

4. 版本迭代
   我们在对BUG进行回归测试的过程中，这里还涉及到软件的版本的发布等内容。
   对于这一块我们可以分为2部分来进行讲解。

• 版本迭代
  版本迭代指的就是开发修改了BUG后，或者新增了功能后，发布新的版本的一个过程。当版本迭代后，我们也是去更新对应的测试环境上的代码的。让我们测试环境上运行的代码的版本和开发发布的版本是保存一致的。如果不一致，就会导致在工作中，做很多的无用功。在工作中，不同的公司有不同的叫法习惯，打包、发版、上线、迭代等等其实都是指的这个过程。

• 测试迭代
  1.全量测试
  每一次版本迭代后，我们除了做回归测试以为，我们还需要对整个软件，再次重新全部测试一遍，这个过程就叫全量测试。因为开发在修改代码的过程中，很可能在修改A功能的代码的时候，导致了B功能出现问题，并且开发自己都不知道。所以我们需要全部重新测试一遍，来保证不会出现这个情况。
  2.增量测试
  随着软件越来越大，功能越来越多，我们已经没有足够的时间和精力去完成全量测试的内容。在这种情况下，我们就可以考虑只做增量测试，也就是只测试修改的功能、新增的内容。而其他的功能我们就采用自动化测试的手段，帮进行覆盖，以此来达到全量测试的目的。

BUG的管理

BUG的记录

BUG六要素，我们在记录BUG的信息的时候，我们需要记录的内容很多，其中最基础的6个点，我们叫做BUG六要素。分别就是BUG的编号，BUG的名称，BUG的优先级、BUG的重要级、复现步骤、 附件。

注意：有时候发现的BUG是属于那种随机BUG， 或者又叫做不可复现BUG，就是说，你找不到这个BUG出现的规律。对于这种BUG的处理是我们在工作中的一个难点，因为无法正常的复现，所以开发就不知道应该如何去修改。对于随机BUG，如果等级比较低，那么就忽略了。如果等级比较高我们才需要进行关注。首先正常的去记录这个BUG，然后在不耽搁工作进度的情况下，花一定的时间尽可能的去找出他的规律，如果能找到规律那就不是随机BUG了，如果还是找不到，那这个BUG就进入了一个长期观察的环节。如果随着时间的推进，这个BUG依然没有出现，那么我们就不管的去调低BUG的等级，如果又出现了又把他调高，直到这个BUG彻底消失为止。

比如：

批改作业后，学分的增长不是得分X2的分数
编号：001，
名称：批改作业后学分没有按分数的两倍进行增加。
优先级：高
重要级：高
复现步骤：
1.后台管理员给用户所在的班级布置作业。
2.该班级的任意用户提交作业。
3.管理员在后台批改作业，得分设置为100.
4.查看前台用户的学分的变化。
附件：
截图。

编号只能必须是唯一的。

bug的名称要求言简意赅，看到这个名称就能直观的知道这个BUG是什么问题。

优先级，bug的优先级是给程序员看的，程序员会根据BUG的优先级的顺序去修改BUG。关于优先级的设置也是一个很主观的一个过程，你希望程序员优先去处理这个BUG，你就可以把优先级给调高。你觉得不着急，就可以设置抵一些。

重要级：BUG的等级

复现步骤：需要详细的描述要怎么去操作软件，才能让BUG再次的出现。这里的操作步骤就是复现B步骤。

附件： 附件是对BUG的一个佐证，作用是为了更直观的看到这个BUG，以及方式开发不认。

BUG可以随便以什么方式去记录，但是一般情况为了工作的效率更快，管理BUG更高效，我们一般都不会使用文档的方式来记录，而是会使用BUG管理工具来记录BUG。

BUG的等级

致命的，导致软件完全无法正常使用，比如主流程无法走通，软件闪退、崩溃之类的BUG，以及任何的和钱有关的BUG都是致命的BUG。

严重的，简单的判断方式就是正向场景的测试用例发现的BUG，就可以直接认为是严重的BUG，严重的BUG就是导致了软件的功能无法正常使用的。

一般的，简单的判断就是逆向场景的用例发现的BUG。一般的BUG就是无影响软件的正常使用的BUG。只在一些特殊的情况下才触发的BUG。

轻微的，建议性的BUG，比如UI测试发现的BUG，易用性测试发现的BUG等等。

BUG的管理平台

BUG管理平台有很多种。

比如：禅道、BUGfree、BUGzilla、testlink、jira等等。

不过这些工具其实本质上都是一样的，所以是不需要花时间逐个的去进行学习的。对于我们测试人员来说，都一样，只是换了一层皮而已。

至于为什么说他们都是一样的呢，因为不管是什么管理工具，他们都是居于BUG的生命周期来研发的。

以禅道为例，禅道是一个国产的BUG管理工具，已经很多年了，算是国内比较出名的BUG管理平台，用的公司也很多。每个公司的BUG管理系统都是互相独立的。比如A公司和B公司用的都是禅道，但是你是A公司的禅道的账号，那就只能在A公司用。

对于账号，是管理员分配给你，如果在公司中，你需要使用茶农，但是你没有账号，那么你应该主动的去找负责人，让他给你创建。不过一般情况，都是你入职的时候，就会给你创建好，把账号分配给你。

禅道核心的模块就以下三个。

产品，是给产品经理和项目经理用的，他们可以在这里发布任务，发布需求，管理项目的进入和相关的需求的完成情况。

项目，是给程序员用的，程序员完成了代码后，就可以在项目这里去发布新的版本。测试人员就可以在这里拿到最新的版本然后去更新测试环境上的代码，但是实际上这块的功能用的不多，因为不同的公司对于版本管理的方式可能不一样的，要根据实际的情况来。

测试，给测试人员用的，我们可以在这里去记录BUG，或者创建测试用例等等。

在我们的工作中，我们测试人员几乎每天打开电脑的第一件事情就是去看一下，昨天提的BUG开发有没有解决。我们要实时的了解开发改BUG的一个进度。

BUG的生命周期

所谓生命周期指的就是一个东西从出生到死亡的一个过程。

对于BUG的生命周期来说，就是我们发现了一个BUG到这个BUG被关闭掉的一个过程。

BUG的状态

在生命周期里面，在不同的阶段，就对应了不同的状态。

• 新建/激活/打开/open

• 已确认/

• 拒绝/

• 已解决/fixed

• 关闭/closed

• 重新打开/reopen

测试总结阶段

注意：软件测试的工作和开发的工作性质是不一样的，开发是一个产出性的工作岗位，工作中所做的事情是可以通过做出来的软件直观的看到的，而测试的工作是一个偏幕后的工作，是无法通过肉眼看到工作的成果的，所以我们一定要学会写测试报告，通过写测试报告的手段，可以让你的领导更加的直观的了解到你的工作的内容和重要性。

测试总结我们可以在每个版本的测试结束后进行，也可以在某一个大版本的测试结束后进行，或者说我们还可以在整个软件测试结束后再进行都可以的。

所以做测试执行这个事情，什么时候去做，主要看公司的安排。

当然，理论上是应该每个版本结束后都需要去做的。但是再实际的工作中，因为很多公司的研发流程的管理不规范，所以实际的操作和理论的操作是有偏差的。

在测试总结阶段，我们主要做的事情，就是对我们之前的工作进行总结。也就是编写【测试报告】。

在测试报告中，核心的内容有三部分，工作总结、BUG的统计和分析、软件的质量评估。

• 工作总结
  也就是对你做的工作进行总结，总结的内容不外乎就是回顾过去，展望将来。

• BUG的统计和分析

• 统计
  根据BUG的不同的属性去进行统计，比如按BUG的等级、模块、测试人、开发者、版本等等属性进行统计，就可以统计出对应的柱状图，饼图等等之类的东西。

• 分析
  分析就是对统计出来的结果进行解释。有的时候我们统计出来的数据，有可能是不符合规律，对于这种不符合规律的图表，我们就需要对它之所以会造成这种情况进行解释。所以我们需要根据公司实际的情况去做解释。

• 软件的质量评估
  一个软件是否测试结束，是否符合上线交付的标准是测试人员说了算的。
  所以在这里，我们就需要告诉别人，软件是否达到上线交付的标准。当这个软件的所有的需求全部都开发完毕，并且发现的BUG，其中一二三级BUG已经全部被关闭，只要达到了这个状态，就可以认为这个软件达到了上线交付的标准。
  如果已经达到了这个标准，那么已经完成的需求，已经关闭的BUG做一个总结性的描述，然后说明已经到了这个标准，允许上线交付就可以了。
  如果没有达到这个标准，那么我们需要列出未完成的需求，和未关闭的BUG，并且预估出一个完成的时间，以数据可视化的方式来告诉别人，目前的研发进度。