从0到1开展软件测试——理论篇

lsekfe

1、水星计划与软件测试
　　说到软件测试，据说最早有记载的软件测试是在人类的第一次载人航天计划，也就是水星计划中提到的，我不确定是不是最早，但是我确实查到是有一些记载，因为载人航天涉及生命安全以及政治因素（1958年美国跟前苏联的冷战太空竞赛），所以美国非常重视，就引入了软件测试，所以也可以看到为什么现在非常多的企业不太注重测试，其实就是因为产品不涉及生命安全或者政治，大家没有碰到这些所谓的红线，也就对这部分没有那么重视了。
　　2、软件测试发展历程
　　图1展示了软件测试的发展史，初步可以分成五个阶段，最早从20世纪50年代开始，此时没有测试一说，更多的是叫作调试。到1957年，Charlesbaker才提出了测试的概念。
　　所谓的测试和调试的区别是，调试的目的是使程序符合开发人员的预期，而对于测试来说，就要确认程序是不是符合产品功能需求的预期。第三阶段就是不光要做测试，还要对程序进行一些探索性的测试，确认有没有做不该做的事情。第四个阶段就是测试人员都比较熟悉的V&V理论，对应软件测试中的V模型，这个模型的话目前在整个工业领域中还在广泛地应用，它第一次提出软件测试要被应用在整个软件的生命周期当中。我认为截止到今天，整个软件测试还在第五个阶段，就是要去做一些探索性的测试、敏捷测试，以及TDD、BDD这些新的概念的兴起带来的所谓自动化工具持续集成这类技术的应用。所以在整个第五阶段，我们的目的是在代码级别防止缺陷，而不仅仅是局限测试。这五个阶段不是完全独立的，更多的是继承。

3、软件测试分类
　　图2左上角是传统的软件分类，做测试的人员可能比较熟悉，它其实就是按照不同的维度对软件测试的方法进行了分类。但是这种所谓的传统分类容易出现概念的交叉，存在边界模糊的问题，这导致这一套分类理论会比较复杂。

对于初创型企业来说，如果企业内部有这么一套复杂的、模糊的概念体系存在，则不利于传播，也不易提升认知上的统一，或者说直接影响到了效率。为了解决这样的问题，就有了右上角的测试金字塔，这个金字塔把各种模糊不清的测试方法全部都进行了整合，形成了三段式或者多段式的，从底往上、从大变小的过程。这里的分层包括单元层、服务层和UI层，越往下，独立性越高；越往上，集成性越高。所以应该在下层写更多的测试用例，在上层做更少的测试，这才是一个健康的测试状态。
　　无独有偶，Google在《Google软件测试之道》中也对测试进行了重新的分类，它的分类方法是按照大、中、小型测试来做划分，这个划分从某种意义上来说，跟测试金字塔是相匹配的，小型测试对应金字塔测试中的单元层，就是说可以测一些单独的模块，在小型测试中可以处理独立的函数。同时它也给出了一个占比，Google认为所谓的小型测试应该占七成，中型测试占两成（模块之间的集成性测试占两成），最后全面的系统性测试只需占10%。图2下方是Google给出的分类。对于初创型企业来说，建议选择测试金字塔模型，分层的层数和名称企业可以自定义，但是对于这样的模型，首先要统一概念，否则如果测试人员和开发人员的语言不统一，那么在开展工作的时候会遇到很多的问题。
　　4、自动化测试工具
　　自动化测试伴随着敏捷开发、敏捷测试等概念得到了蓬勃的发展，通过图3大家可以看到主流的自动化测试工具，早期主要是线性测试，就是通过录制的方式生成脚本、宏，这种是比较常见的形式，后期测试工具有了更多的类型变化，比如支持结构化的、数据驱动的以及关键字驱动的测试。形式上来说主要有两种，一种是基于UI，一种是基于API，基于API的形式就是调用API，更多的是在接口层面进行操作。基于UI的形式就是模拟用户的操作，比如在界面上移动鼠标、点击鼠标、按键等。

5、自动化测试开展条件
　　自动化测试的优势我认为主要有两点，第一点就是它可以代替一些重复但必要的测试工作，解决重复劳动问题。第二点也很重要，因为重复性工作容易引入人为的差错，此时就应该通过工具来辅助。虽然自动化测试优势明显，但是它的劣势同样不可小觑，很多人认为自动化测试是万金油，在任何情况下都可以开展，其实并不是，它的劣势也包含两点，第一点就是成本较高，尤其是短期的开销比较大，如果要进行自动化测试，需要人才培养或者人才招聘、流程建立以及脚本编写和维护，这些都需要一个成本比较大的开销。此外，前面说了自动化测试的优势是可以代替做重复性劳动，相对应的劣势就是不容易发现新的bug，因为它只能做重复的任务，想让它发现新的bug是比较难的，虽然说现在有模糊测试、混沌工程，但它始终不像人一样擅长或者能够发现新的bug。
　　那在什么样的情况下，初创企业可以开展自动化测试，主要有三点：第一点就是产品周期比较长，这里指的是稳定的产品，如果是demo型产品，就没有必要进行自动化了。第二点是频繁的迭代，这一点是它的价值所在。第三点是产品相对稳定，这一点其实从某种意义上来说与第一点是捆绑的，因为产品稳定，才能有稳定的收益，才可以做投入。
　　所以对于自动化测试来说，更多的是与传统的手动测试的互补，而不是替代。互补是两方面的，第一个方面就是如果不具备自动化测试所需的条件，就可以做手动测试；另一方面就是针对自动化测试不容易发现新bug的特点，需要人先做探索性测试，然后再把这部分内容转变成自动化的脚本。
　　6、敏捷与软件测试
　　敏捷测试与敏捷开发一样，就是敏捷开发的一部分，它是一个思想，而不是一种方法。那么这个思想跟传统测试的区别是什么呢？我认为主要包括以下几点：
　　首先最主要的是沟通，要开展敏捷测试，最主要的是面向客户需求的全员测试，从产品、项目、开发到测试，要清楚地理解用户的需求，如果依靠传统的文档方式，消息的传递效率是比较低的，而且不及时，这是传统测试的局限所在。所以对于初创型的企业来说，即便一开始不采用敏捷测试，也可以借鉴它的思想来帮助解决测试人员不了解需求的现象。
　　第二点是说敏捷拥抱变化，但拥抱变化不是让大家肆无忌惮地频繁变更需求。因为敏捷始终强调慢思考，快行动，一拍脑门就往前冲不是敏捷，所以一旦把测试前置，那么又将是一笔不小的投入，此时公司管理层要思考和把控需求的变化，不能朝令夕改，否则非常容易伤害整个团队。
　　7、敏捷测试最佳实践
　　前面提到敏捷是一种思想，而不是具体的实践。虽然市面上有非常多的厂商（包括资金机构）提到最佳实践，但我认为它是一种通用的模型，每个企业的情况不一样，套用统一的方式去可能会形成反向的效果。
　　这里有几点跟大家分享，在标准模型中提到了测试前移，测试要参与到需求的评估过程当中，如图4左上角所示，这里显示在迭代开始之前，测试人员就要参与迭代的测试分析，这个分析主要指的是需求的拆解、细化，然后编写AC之类的内容。图中还提到全量的回归测试，这才是敏捷测试以及自动化测试的特点，就是进行全量的回归测试。每个迭代周期都要做测试，将之前测过的内容重新再测一遍，这就需要不断地完善和积累自动化测试的脚本。这对于敏捷和自动化测试来说，都是其充分发挥价值的地方。

从图中下方可以看到，企业开展敏捷测试一定要按需实践，逐步提升。对于小的团队来说，比如团队小于五人这种初创的不稳定阶段，还是不要一开始就全部应用自动化测试，我们的目的还是简单高效，内容太多反而会拖后腿。但还是需要具备这样的能力，因为要随时准备做规模化、正规化的业务。
　　8、DevOps与软件测试
　　现在很多企业在做DevOps转型，那么DevOps与软件测试又有怎样的关系呢？首先可以看图5左下角，这里的DevOps这个词用得不好，它只是把开发人员和运维人员的单词拆进去了，但实际上DevOps是软件开发、测试跟运维三方面的，这个词只是体现了两个方面。测试是DevOps中的重要一环，如图中右下角所示，其中提到DevOps跟敏捷开发的区别，最主要的是反馈的周期更快了，如果此时仍然用传统的方式做测试，那么其能力、频率都不足以满足这么快的交付频率，这对测试是一个非常大的挑战，同时也是其重要性的体现。


在DevOps中的测试扮演着怎样的角色呢？它其实更多的是扮演牵制和协同的角色。举一个简单的例子，我们的软件要发布上线，这个时候应该是开发人员提交代码，然后QA测试无误，才允许把制品交给Ops做部署。如果线上出了问题，Ops会通过监控平台第一时间先反馈给QA来验证，验证通过之后再反馈给开发，而并不是直接反馈给开发。所以在这个过程中它更多的是扮演牵制和协同的角色。
　　DevOps，这里Dev开发对应着CI/CD工具中的CI（持续集成），Ops对应的是CD（持续部署）。对测试来说对应的是CT（持续测试）。持续测试的概念介绍在图中左上角。