你知道什么是软件测试吗？很多人说是QA，也有人说是IT行业最低端的一份工作。在公司，不懂的上级领导会认为：测试不就是点点点，保证软件不会有bug出现，就可以了。

1、什么是软件测试？

在规定的条件下对程序进行操作，以发现程序的错误，衡量软件的质量，并对其是否能满足设计要求进行评估的过程。

软件测试的错误定义，例如：软件测试就是软件不存在错误的一个过程，这句话存在很大的误差的。这也就造成了很多入门的小白也就对此有了误解，那不就是QA。

或许在你将来的面试道路上，遇到这样的猎头或者HR，说：软件测试是IT行业最低端的工作。那么真的是这样的吗？

对于上述的说法，是错误的。如果这样的说法成立，那么生活中存在低端的人吗？任何职业都是高尚的，就看你用什么样的态度去对待，不盲从，不盲听。

1.1、测试只是点点点？

这句话从绝对角度上来说，是错误的，从相对角度来说也是对的。这也就是我上述所说的对，也不对！

软件测试中有很多的分类，多个分类联合在一起组成一个过程，这个过程叫做软件的测试过程，那么一个完整的过程是怎样的呢？

在这个过程中，每一个过程又有很多的类别，每一个类别的工作又有所不同。普通的问题或者界面化的问题不得不通过点点点来解决，但是上升一个层面后呢？点点点过后，很多重复性的东西还需要在人为的点吗？这就需要一定的代码能力才能解决了，叫做自动化，也可以称之为自动化测试，专门解决点点点过程中重复性的工作。

除了自动化测试，还有吗？当然有，软件总得解决安全问题吧。所以又有了安全测试。总的解决性能问题吧。所以有了性能测试。还有可能你们听起来比较厉害的就是白盒测试。

所以说，测试不只是点点点，点点点只是入门。

2、深入测试

我们来深入的看看软件测试都用到了哪些常用的测试理论。

2.1、测试策略

测试策列是每个软件测试成员必看的且必须知道的。一个好的测试员必须从多方面的角度去思考问题，测试是在一个产品中最了解产品的一个角色。比开发、产品经理还熟悉。不然，也不能够很好的去展开测试，及时发现问题，及时的查漏补缺。

下面来看看一则示例：

这是测试的开始阶段，也就是每一个产品要想上线，必须经过这么一个阶段。也可以说是必须的一个程序。不然上线了出了大问题，谁来承担呢？那么问题又来了？经过软件测试后就一定能不出问题吗？

这个谁又能保证呢。那么软件测试还有什么用呢？软件测试，并非是保证软件不出问题，而是尽可能的在用户的前面去发掘，去找寻软件的不合理的地方。用特殊的方式方法减少非必要的损失。就好比，你今天出门就一定能买到你想吃的零食吗。这些都是不确定性的因素。与其说软件测试是保证软件的质量，不如说是预防未知因素给用户带来不好的体验或者给公司带来经济上的损失。

2.2、设计用例方法

测试用例是每个测试人员必备的技能，也是测试过程中必须的程序。测试用例写的好，才能更大程度的避免一些已知或未知的风险。那么有人就会问了，为什么不能完全避免呢？

对于这个问题，需要了解到什么是缺陷(Bug)，一般人都会说，程序报错。那么高深一点的就是界面展示错误、需求不符合的都是Bug。那么真实的情况呢，通俗易懂不符合常规操作或者常规操作后得不到相对于的正确结果的都属于Bug。

很多的测试人员都知道不能够无穷尽的测试，那么，这到底是为什么呢。需求是可以变动的，每个测试人员的思考角度不一样，用户体验、理解的角度不一样，无穷尽的测试，是达不到的，也是非常的耗时且消耗精力的。

编写合格的测试用例，就需要了解常用的测试用例方法、例如等价类划分法、边界值分析法、因果图法等等。

2.3、测试执行类型

图中已经很明确的说明了情况，这里就不做多的解释了。这也是每一个版本迭代的必须操作。

3、自动化测试

上面也有说到自动化测试，这是一个分水岭，点点点测试跟实力测试之间的一个分水岭。点点点的过程中也有一会是可以自动化的，但是可能未被分配到自动化测试中来，这时候你可以自己写脚本来辅助进行测试。

自动化测试有一个优势，就是自动化测试报告，它可以在回归测试完成后，自动输出一份测试报告出来。这是一个非常便捷的事情。

3.1、接口测试

接口测试原则上来讲属于功能测试，但是不影响它进行自动化测试。并且接口测试后才有我们所说的点点点，或者自动化测试。接口测试也是一项比较繁琐的测试项目。

3.1.1、什么是接口测试？

接口就是前端与后端交互过程中用于传输数据的。如果此处发生错误，那么测试点点点过程中或者自动化过程中就会发现很多的错误。

接口可以说是测试开始，接口不通或者接口错误意味着数据传输错误，本来应该在前端界面上看到一张图片的，结果因为接口的原因导致看到是文字，或者一个超链接。这种情况在接口测试过程中非常的常见的。那么为什么会出现这种错误呢？可能就是代码写多了，或者业务场景比较的复杂弄混了。

3.1.2、接口测试过程

接口测试其实是比较的复杂的一个测试环节，并且接口测试在自动化的过程中属于比较容易的一种。除了接口还有WEB_UI测试，这是比较复杂的。为什么说复杂呢，因为考虑的因素比较的多，接口测试会有返回值，而WEB_UI需要自己根据实际情况来选定元素判定。这过程所做的判定比起接口只多不少。

3.2、WEBUI测试

WEBUI的自动化难度比较大，需求不稳定，那就是做UI测试人员的噩梦，他们需要对用例进行增删改查，需要对未变的模块进行回归测试，即使有自动化，在更多的时候显的更加的累赘。因为用例要变，自动化的代码也需要不停的变更。

除了WEB端还有移动端，不管是WEB还是移动端，从一定角度上来说都可以说是UI测试。但是移动端的讲究更多，需要考虑的情况更加的广：

4、敏捷测试

企业中现在敏捷测试用的是越来越多，特别是外包的项目，基本上走的是敏捷测试路线。

4.1、什么是敏捷测试？

这里就很明确的说到了，很关键的就是需求急，快速迭代。那么敏捷测试能否对软件有一个好的测试过程呢？答案是有的。

4.2、敏捷测试的原则是什么？

原则有五点，敏捷测试也是对测试人员一项极大的考核，不论是身体上还是精神上也是学习能力上的一种考核。

4.2.1、测试左移右移

测试过程中会有很多的小插曲发生，所以，测试左移右移也是常有的事情，就看怎么样去对待。特别是测试左移，开发自测是很多企业中没有的事情。

5、契约测试

如上图所示，契约测试比较的少，这个方法主要作为了解即可，也是一项不错的测试手段。

5.1、微服务应该如何测试？

服务独立测试：功能、数据检查、性能。服务间一致性测试：正常场景、异常场景。系统集成测试：功能、数据检查、性能。服务幂等测试：一个服务、服务之间。

5.1.1、什么是微服务？

loosely couped：松耦合。松耦合可以引申出其他概念，如各自独立，微服务应该是各自独立的，可以独立开发，独立测试，独立部署，独立运维，如果每个服务都需要同时被更新，那就不是松耦合。服务自理，高度内聚，对外界应该是没有依赖的。

bounded context：有界上下文。业务有界，每个微服务有着明确的业务功能，业务场景。数据有界，每个微服务自身数据不对外界暴露，外界只能通过微服务暴露的接口访问内部数据。

5.2、什么又是契约测试？

5.3、微服务测试又面临着什么问题？

5.3.1、Mock技术

Mock可以很好的解决这个问题，Mock也可以用来解决接口测试。来看看Mock在这里可以干些什么：

5.3.2、Mock测试的目标

Mock可以干的活可太多太多了。作为测试，这也是一项必须学会的技能，不论是在微服务测试还是接口测试，都是必不可少的。

6、各行各业面临的性能问题

性能问题可以说是比较严重的一个问题了，如果一个网页从点击开始计算时间，到打开用了5s甚至10s，那么你作为用户是不是很反感呢，从而就不想打开了，或者说点击量大大减少。从而流失用户。作为一家公司损失的就是经济。

7、可靠性测试

这里就没什么好说的了，可靠性测试比较重要，但是测试起来也是相当的简单的。同样也是不可忽视的。

8、什么是DevSecOps？

安全测试工程师，是一项可以与性能测试齐平的测试工作，甚至有过之而无不及。安全测试多涉及到用户的隐私、金钱等。所以是相当重要的。

9、什么是在线测试？

9.1、在线测试包含的测试活动有哪些？

各有其职，在各个阶段，都有阶段性的必须要保证的东西。在线测试可以很好的模拟并解决生产环境所可能产生的问题。降低产品上线时出问题的概率。

9.2、导流测试

在线测试过程中，这是一个比较重要的环节。那么我们如何部署在线测试呢。

9.3、部署测试

9.3.1、在线持续测试

部署完成后，当然是熟悉环境，并快速展开测试。对重要的用例进行测试，在线及时反馈问题，这也是在线持续测试的一大不可忽视的优点。

10、测试指标

测试过程中，总得有个指标吧，不然怎么去评估呢。然而这个指标就需要从多角度的去考虑了。什么时候才是测试退出的时候呢？依据公司的规定来定制，比如说，BUG的数量依据优先级，修改完后已经没有了严重的BUG了，也不影响体验了，测试标准达标了，那么测试就可以退出了。总的一句话就是：测试能否退出测试取决于缺陷带来的风险程度。

11、总结

测试是一门技术活，虽然门槛低了点，绝不是任何人都能够做的来的。做好测试的关键，除了本身的技术，你还需要具备有效的沟通能力，更需要从不同的角度去思考方方面面的问题。
https://bbs.huaweicloud.com/blogs/330939
任务11.华为高质量软件测试之道