论文部分内容阅读
摘要：广东省深圳市已经成为中国电子机械制造行业的中心，甚至也可以说是世界最重要的制造业中心之一。随着电子机械类产品的日趋复杂化、智能化，与电子机械类产品相关的软件规模以及需求也日趋扩大化。这一类软件和其他普通产品一样，都要经过严格的测试才可以最终大批量生产或者投入市场，本文的目的就是针对目前深圳大部分企业所采取的开发中后期大规模测试的现象，提出一种旨在开发前期就能发现产品缺陷，缩短产品开发周期以便应对多变的市场，减少大规模测试带来的高成本等目的而提出的一种新的测试理论。本文主要的内容包括对软件测试理论的介绍，软件测试左移的原因及目的，软件测试左移所需条件及具体操作案例，软件测试左移理论在其他行业的拓展应用。通过本文的介绍，我们可以看到电子机械类产品制造业测试方法的趋势，并可以引入其他领域应用的思考，进一步拓展出新的见解。
关键词：瀑布开发模型（waterfall development model）；敏捷开发模型（agile development mode）；测试左移（shift left testing）；測试右移（shift right testing）；传统式软件测试左移（Traditional Shift Left Testing）；迭代增量式软件测试左移（Incremental Shift Left Testing）；敏捷式软件测试左移（Agile/DevOps Shift Left Testing）；基于模型式软件测试左移（Model-Based Shift Left Testing）
1 软件测试的背景
在早期的软件开发设计中，软件功能和规模有限，通常都是开发设计人员独自完成软件构架、软件开发、软件测试和软件发布，并没有独立测试人员存在，也没有人系统的提出软件测试这个概念。但是随着近20年软件可以说深入了我们的生活当中，手机、电脑、汽车、甚至从电视机到洗衣机这种日常家电中软件都被广泛的应用，而且软件规模逐渐扩大、功能逐渐增多，随之而来的是软件开发设计中的缺陷也逐渐开始增多，应对缺陷开始占用开发设计人员大量的时间及预算，因此首先在很多大型电子和软件企业中提出了软件测试的概念，并逐渐形成了独立的软件设计检证和软件信赖性测试部门，并对软件测试这一领域进行持续深入的研究，正是在这一大背景下，测试左移的概念应运而生。
2 软件测试左移理论的介绍
在介绍软件测试左移之前，我们首先说明一下软件的常规开发设计测试流程，以便能更形象的介绍所谓左移的概念。现今软件开发工作主要有两种主要的开发模型。第一，瀑布式开发模型（waterfall development model），如图2-1所示，顾名思义，这种开发方式就像是瀑布一样，所有流程按照一定的顺序由上游向下游移动，并且整个过程是不可逆的。如图中所示的编码结束后就可以进入相应的测试阶段。
第二，敏捷开发模型（agile development mode），也有很多时候被称作迭代或者螺旋测试方法，如图2-2所示，开发阶段被分为若干小的阶段，前一个小的阶段都经历设计、编码、测试、计划、分析后再进入下一个小的阶段，如此反复迭代从而达到最后预期的结果。
通过介绍以上两种主要开发方式，我们可以看出无论是瀑布式开发方法还是敏捷开发方法，都有需求、设计、编码和测试的过程，下面我们就提出左移的概念。
2.1 软件测试左移理论的基本内容
如果我们把软件开发过程中除了测试以外的元素，需求、设计、编码放在如下图2-3所示的一条直线上以设计为原点就有了左和右的概念，我们把测试越靠近直线的左端称为测试左移（shift left testing），而把测试越靠近直线的右端称为测试右移（shift right testing）。顾名思义测试左移也就是尽量将测试工作向开发活动的初期阶段靠近，而不是被动的等待开发设计阶段完成后接受测试。
2.2软件测试左移理论产生的原因
导致软件测试左移这一理论产生的原因可以归纳为以下几点：
第一、在早期的测试工作中，测试人员较少参与软件工程的初始计划，通常导致分配给测试的资源不足，致使测试工作不能顺利的进行。
第二、许多需求、设计架构等前期工程本身就存在很多重大的缺陷，但是并没有被及早发现和修复，直到到了开发阶段的末期测试工作中才被发现，从而在需求分析、设计构架、编码工作上浪费了大量的时间和精力。
第三、随着更多软件的产生和集成，后期调试（包括识别、本地化、固定和回归测试）变得越来越困难。
第四，封装（面向对象的编程）使得在后期测试过程中执行白盒测试和实现高水平的代码覆盖测试变得更加困难。
第五，修复缺陷的时间在后期被压缩的较短，从而增加了缺陷修复被推迟到下一个版本的可能性，从而产生了技术债务的冲击波，如此下去则可能导致整个项目陷入困境。
通过合理地将测试工作左移可以很好解决或者缓解以上的五个问题。
2.3 软件测试左移的类型
在软件产品的开发设计生命周期中有四种测试左移的类型，包括传统式软件测试左移（Traditional Shift Left Testing）、迭代增量式软件测试左移（Incremental Shift Left Testing）、敏捷式软件测试左移（Agile/DevOps Shift Left Testing）、基于模型式软件测试左移（Model-Based Shift Left Testing）。
2.3.1 传统式软件测试左移
如图2-4是比较典型的软件开发的V型图，在V字的左端是开发设计的过程，其中包括了需求分析，具体设计以及编码的执行，而V字的右端是与开发设计过程对应的各个阶段的测试。所谓的传统式软件测试左移就是说我们将测试重点移向V字的底端，不再以传统的把系统测试和接收测试作为重点，取而代之，将测试重点放在软件的单体测试以及集合测试阶段。 2.3.2 迭代增量式軟件测试左移
如图2-5所示，我们可以将迭代增量式软件测试左移理解成许多传统式测试左移的迭代。在很多大型复杂项目中对软件的可靠性要求很高，我们将开发周期分解为期间相对较短的少量工作包，而针对每一个包我们将测试重点放在单体及集合测试上，这样我们就通过各个块的传统式软件测试左移实现了整个项目的软件测试左移。这种方法通常应用于大型复杂的软件，尤其是与大型硬件系统相配套的软件。
2.3.3 敏捷式软件测试左移
如图2-6所示，敏捷式项目中有大量可以被称为短程的区间取代了上述两个测试模型中的单一区间和少数量相对敏捷式软件测试左移模型中较长的区间。当早期的一个或多个短程无法满足达到最基本的要求时，又或者采取测试驱动开发方式的时候，短程区间就有可能会被修正，每一个短程的测试左移都可以映射整个项目的左移。
2.3.4 基于模型式软件测试左移
上述的三种测试左移模型都集中在开发周期早期的软件测试上，直到软件存在以后才开始进行测试，然而极大地限制了测试发现代码错误的能力。这种软件存在之后开始测试的延迟极其令人不安，因为据权威机构统计在需求、架构和设计活动中就潜藏了45%到65%的缺陷。如图2-7所示，测试已经完全移到了V字的左端，对需求、构架、设计模型进行审查及测试。这种左移方式可以随时开始测试，而不会发生传统测试左移、迭代增量左移、敏捷测试左移的等待时间。
3 软件测试左移所需条件
第一个条件就是需要对整个项目的了解。我们在上一章中提到了四种不同的软件测试左移模型，具体我们使用哪一种左移模型并不是随意决定，而是要根据项目的实际情况，例如我们在做大型项目的时候就不适合采用敏捷式测试左移而要采用迭代增量式测试左移模型。
第二个条件，就是需要从公司层面推进软件测试左移的实施。我们可以看到在测试左移的模型中，测试的重点已经由以前的系统和接收测试转换到了单体测试和集合测试，而基于模型式软件测试左移更涉及到了需求、架构和设计活动。如果没有整个开发周期中所有相关部门的参与，是无法实现测试左移。
第三个条件，需要测试人员具有很大的知识面宽度。测试人员不仅要熟悉系统测试及接收测试的方法和内容，同时要能够熟悉开发设计人员进行的单体测试和集合测试的结果以便进行二次检查，另外对产品需求，软件构架等知识也要掌握才能开展基于模型式软件测试左移活动。
表3-1，我们从项目、推进和人员三方面所需要具备的条件上，对传统测试和测试左移进行了比较。
4 软件测试左移理论在其他行业的拓展应用
以上我们简单的叙述了一下软件测试左移理论的背景、内容和类型，其实通过严谨的分析和思考我们可以将这一理论推广至其他领域和行业，比如硬件开发设计，如图4-1是一个比较典型的硬件开发的流程，其中包括分析阶段（需求调研分析），设计阶段（方案设计），实现阶段（原理图设计、PCB设计、结构设计），测试阶段（焊接调试、系统测试、小批量测试），从图中可以看出测试阶段主要集中在设计实现阶段之后，无法在设计阶段和实现阶段就排除掉可能隐藏的不良。我们可以将软件测试左移的思想引用到硬件设计当中，在分析阶段、设计阶段和实现阶段就进行审查及测试，在开发设计生命周期的早期阶段就发现不良现象，从而达到实现缩短开发设计时间，减少开发设计成本的目的。
通过硬件开发的例子我们可以看出，其实这一思想可以应用于很多的领域。随着现在市场变化快，用户群体对产品的质量要求越来越高，人力成本的逐渐提高等外部环境的变化，我相信将来测试左移理论将会有更广的应用空间，也会带来意想不到的效果。
参考文献：
[1]Paul Bahrs（6 November 2014）. “Shift Left：Approaches and Practices”. Retrieved 27 March 2015.
[2]Dibbe Edwards（18 September 2014）. “Enabling DevOps Success with Shift Left Continuous Testing”. Retrieved 27 March 2015.
[3]Donald Firesmith（11 November 2013）. “Using V Models for Testing”. Retrieved 27 March 2015.
[4]Microsoft（2013）. “Record and Playback Manual Tests”. Retrieved 27 March 2015.
[5]P Mohan；A Udaya Shankar & K JayaSriDevi（2012）. “Quality Flaws：Issues and Challenges in Software Development”. Retrieved 27 March 2015.
关键词：瀑布开发模型（waterfall development model）；敏捷开发模型（agile development mode）；测试左移（shift left testing）；測试右移（shift right testing）；传统式软件测试左移（Traditional Shift Left Testing）；迭代增量式软件测试左移（Incremental Shift Left Testing）；敏捷式软件测试左移（Agile/DevOps Shift Left Testing）；基于模型式软件测试左移（Model-Based Shift Left Testing）
1 软件测试的背景
在早期的软件开发设计中，软件功能和规模有限，通常都是开发设计人员独自完成软件构架、软件开发、软件测试和软件发布，并没有独立测试人员存在，也没有人系统的提出软件测试这个概念。但是随着近20年软件可以说深入了我们的生活当中，手机、电脑、汽车、甚至从电视机到洗衣机这种日常家电中软件都被广泛的应用，而且软件规模逐渐扩大、功能逐渐增多，随之而来的是软件开发设计中的缺陷也逐渐开始增多，应对缺陷开始占用开发设计人员大量的时间及预算，因此首先在很多大型电子和软件企业中提出了软件测试的概念，并逐渐形成了独立的软件设计检证和软件信赖性测试部门，并对软件测试这一领域进行持续深入的研究，正是在这一大背景下，测试左移的概念应运而生。
2 软件测试左移理论的介绍
在介绍软件测试左移之前，我们首先说明一下软件的常规开发设计测试流程，以便能更形象的介绍所谓左移的概念。现今软件开发工作主要有两种主要的开发模型。第一，瀑布式开发模型（waterfall development model），如图2-1所示，顾名思义，这种开发方式就像是瀑布一样，所有流程按照一定的顺序由上游向下游移动，并且整个过程是不可逆的。如图中所示的编码结束后就可以进入相应的测试阶段。
第二，敏捷开发模型（agile development mode），也有很多时候被称作迭代或者螺旋测试方法，如图2-2所示，开发阶段被分为若干小的阶段，前一个小的阶段都经历设计、编码、测试、计划、分析后再进入下一个小的阶段，如此反复迭代从而达到最后预期的结果。
通过介绍以上两种主要开发方式，我们可以看出无论是瀑布式开发方法还是敏捷开发方法，都有需求、设计、编码和测试的过程，下面我们就提出左移的概念。
2.1 软件测试左移理论的基本内容
如果我们把软件开发过程中除了测试以外的元素，需求、设计、编码放在如下图2-3所示的一条直线上以设计为原点就有了左和右的概念，我们把测试越靠近直线的左端称为测试左移（shift left testing），而把测试越靠近直线的右端称为测试右移（shift right testing）。顾名思义测试左移也就是尽量将测试工作向开发活动的初期阶段靠近，而不是被动的等待开发设计阶段完成后接受测试。
2.2软件测试左移理论产生的原因
导致软件测试左移这一理论产生的原因可以归纳为以下几点：
第一、在早期的测试工作中，测试人员较少参与软件工程的初始计划，通常导致分配给测试的资源不足，致使测试工作不能顺利的进行。
第二、许多需求、设计架构等前期工程本身就存在很多重大的缺陷，但是并没有被及早发现和修复，直到到了开发阶段的末期测试工作中才被发现，从而在需求分析、设计构架、编码工作上浪费了大量的时间和精力。
第三、随着更多软件的产生和集成，后期调试（包括识别、本地化、固定和回归测试）变得越来越困难。
第四，封装（面向对象的编程）使得在后期测试过程中执行白盒测试和实现高水平的代码覆盖测试变得更加困难。
第五，修复缺陷的时间在后期被压缩的较短，从而增加了缺陷修复被推迟到下一个版本的可能性，从而产生了技术债务的冲击波，如此下去则可能导致整个项目陷入困境。
通过合理地将测试工作左移可以很好解决或者缓解以上的五个问题。
2.3 软件测试左移的类型
在软件产品的开发设计生命周期中有四种测试左移的类型，包括传统式软件测试左移（Traditional Shift Left Testing）、迭代增量式软件测试左移（Incremental Shift Left Testing）、敏捷式软件测试左移（Agile/DevOps Shift Left Testing）、基于模型式软件测试左移（Model-Based Shift Left Testing）。
2.3.1 传统式软件测试左移
如图2-4是比较典型的软件开发的V型图，在V字的左端是开发设计的过程，其中包括了需求分析，具体设计以及编码的执行，而V字的右端是与开发设计过程对应的各个阶段的测试。所谓的传统式软件测试左移就是说我们将测试重点移向V字的底端，不再以传统的把系统测试和接收测试作为重点，取而代之，将测试重点放在软件的单体测试以及集合测试阶段。 2.3.2 迭代增量式軟件测试左移
如图2-5所示，我们可以将迭代增量式软件测试左移理解成许多传统式测试左移的迭代。在很多大型复杂项目中对软件的可靠性要求很高，我们将开发周期分解为期间相对较短的少量工作包，而针对每一个包我们将测试重点放在单体及集合测试上，这样我们就通过各个块的传统式软件测试左移实现了整个项目的软件测试左移。这种方法通常应用于大型复杂的软件，尤其是与大型硬件系统相配套的软件。
2.3.3 敏捷式软件测试左移
如图2-6所示，敏捷式项目中有大量可以被称为短程的区间取代了上述两个测试模型中的单一区间和少数量相对敏捷式软件测试左移模型中较长的区间。当早期的一个或多个短程无法满足达到最基本的要求时，又或者采取测试驱动开发方式的时候，短程区间就有可能会被修正，每一个短程的测试左移都可以映射整个项目的左移。
2.3.4 基于模型式软件测试左移
上述的三种测试左移模型都集中在开发周期早期的软件测试上，直到软件存在以后才开始进行测试，然而极大地限制了测试发现代码错误的能力。这种软件存在之后开始测试的延迟极其令人不安，因为据权威机构统计在需求、架构和设计活动中就潜藏了45%到65%的缺陷。如图2-7所示，测试已经完全移到了V字的左端，对需求、构架、设计模型进行审查及测试。这种左移方式可以随时开始测试，而不会发生传统测试左移、迭代增量左移、敏捷测试左移的等待时间。
3 软件测试左移所需条件
第一个条件就是需要对整个项目的了解。我们在上一章中提到了四种不同的软件测试左移模型，具体我们使用哪一种左移模型并不是随意决定，而是要根据项目的实际情况，例如我们在做大型项目的时候就不适合采用敏捷式测试左移而要采用迭代增量式测试左移模型。
第二个条件，就是需要从公司层面推进软件测试左移的实施。我们可以看到在测试左移的模型中，测试的重点已经由以前的系统和接收测试转换到了单体测试和集合测试，而基于模型式软件测试左移更涉及到了需求、架构和设计活动。如果没有整个开发周期中所有相关部门的参与，是无法实现测试左移。
第三个条件，需要测试人员具有很大的知识面宽度。测试人员不仅要熟悉系统测试及接收测试的方法和内容，同时要能够熟悉开发设计人员进行的单体测试和集合测试的结果以便进行二次检查，另外对产品需求，软件构架等知识也要掌握才能开展基于模型式软件测试左移活动。
表3-1，我们从项目、推进和人员三方面所需要具备的条件上，对传统测试和测试左移进行了比较。
4 软件测试左移理论在其他行业的拓展应用
以上我们简单的叙述了一下软件测试左移理论的背景、内容和类型，其实通过严谨的分析和思考我们可以将这一理论推广至其他领域和行业，比如硬件开发设计，如图4-1是一个比较典型的硬件开发的流程，其中包括分析阶段（需求调研分析），设计阶段（方案设计），实现阶段（原理图设计、PCB设计、结构设计），测试阶段（焊接调试、系统测试、小批量测试），从图中可以看出测试阶段主要集中在设计实现阶段之后，无法在设计阶段和实现阶段就排除掉可能隐藏的不良。我们可以将软件测试左移的思想引用到硬件设计当中，在分析阶段、设计阶段和实现阶段就进行审查及测试，在开发设计生命周期的早期阶段就发现不良现象，从而达到实现缩短开发设计时间，减少开发设计成本的目的。
通过硬件开发的例子我们可以看出，其实这一思想可以应用于很多的领域。随着现在市场变化快，用户群体对产品的质量要求越来越高，人力成本的逐渐提高等外部环境的变化，我相信将来测试左移理论将会有更广的应用空间，也会带来意想不到的效果。
参考文献：
[1]Paul Bahrs（6 November 2014）. “Shift Left：Approaches and Practices”. Retrieved 27 March 2015.
[2]Dibbe Edwards（18 September 2014）. “Enabling DevOps Success with Shift Left Continuous Testing”. Retrieved 27 March 2015.
[3]Donald Firesmith（11 November 2013）. “Using V Models for Testing”. Retrieved 27 March 2015.
[4]Microsoft（2013）. “Record and Playback Manual Tests”. Retrieved 27 March 2015.
[5]P Mohan；A Udaya Shankar & K JayaSriDevi（2012）. “Quality Flaws：Issues and Challenges in Software Development”. Retrieved 27 March 2015.