前端工程重要分支——前端自动化测试初探

敏捷软件测试指的是在敏捷软件开发过程当中跟质量相关的一系列活动，和传统意义上的软件测试有不少区别，由于敏捷软件测试的概念一直比较模糊，因此常常会有人走入误区，我曾经在瀑布型的软件开发模式下作过几年的测试人员，因此在刚刚接触敏捷项目的时候也曾有过一些误解，可是在敏捷软件开发团队工做将近5年后，对不少问题有了新的认识，如下针对几个常见的误区和你们分享一下个人理解。

不须要测试策略

测试策略关注的是目标和方法，即怎样在限定的时间内有效利用有限的资源达到提早制定的目标，通常制定测试策略时会首先明确测试目标，而后肯定须要哪些测试类型，各类测试类型所占的大概比例，选择测试框架，最后规划一下软件发布前须要经历哪些测试阶段。

不少人认为，敏捷软件开发以用户故事为单元，是否是集中精力在用户故事测试就足够了？是否是根本不须要考虑测试策略？

其实这是一个很大的误解，由于敏捷软件开发一般都是迭代式的发布，周期比较短，资源很是有限，这就更须要咱们统筹规划，小到一个用户故事，大到一个完整的用户特性，都须要考虑怎么合理利用测试资源，因此敏捷项目是很是须要测试策略的。

具体到实际项目中，一般团队会在项目初期（迭代0）制定测试策略，明确目标(包括功能性需求的目标以及非功能性需求的目标)，而后肯定在开发阶段须要添加哪些自动化测试(包括单元测试，接口测试，契约测试，集成测试，系统级别的UI的用户场景测试)，并规定这些测试的大概比率(符合测试金字塔)，选择自动化测试框架（好比XUnit）以及须要哪些手动测试(包括探索性测试，可用性测试等)，还要规划每一个发布周期须要进行的测试阶段（好比新功能测试，回归测试等），以后测试策略会对敏捷团队的开发及测试起到很是重要的指导做用，固然，每一个团队由于项目的不一样策略也会不一样。

下图就是一个简单的敏捷测试策略介绍:

不须要测试文档

测试文档一般包括测试计划，测试用例，测试报告，测试缺陷等文档以及相对应的能够指导测试的一部分需求文档。

不少人会认为，敏捷软件测试是不须要文档的，敏捷宣言中有一句“工做的软件 高于 详尽的文档”，尽管敏捷宣言最后提到了“右项也有价值，咱们更重视左项的价值”，但人们每每会忽视右项的内容，致使在不少刚开始实施敏捷开发的团队中彻底否认了测试文档的做用。

首先不能否认，在实际的敏捷项目中，确实不多见传统意义上的正式的专门的需求文档和测试文档，但这并不表明敏捷项目没有文档，好比用户故事自己就是需求的载体，用户故事中的验收条件就是敏捷测试文档的一部分， 另外不少敏捷软件项目都会采用BDD的方式进行开发，将测试用例用业务人员可以看懂的天然语言描述，并结合自动化实现，造成一个融需求和测试为一体的文档，并且为了应对敏捷软件测试变化快文档更新不及时致使的问题，不少敏捷项目都在使用Living document。

敏捷测试

纯自动化测试 or 纯手动测试

有些刚接触敏捷的人认为敏捷软件开发发布周期很短， 测试人员根本没有时间作手动测试， 因此应该采用纯自动化测试。

也有一些人认为，敏捷开发强调快速响应变化，若是投入成本在自动化测试上，那么确定会致使维护自动化测试带来的资源浪费，因此应该采用纯手动测试。

这是两种极端的误解，虽然这两种观点所考虑到的难点确实存在， 由于在敏捷软件开发过程当中， 迭代一般比较短，确实不会预留足够多的时间来作手动测试， 因此必需要有足够多的自动化测试来保障。

然而由于测试代码自己可能存在缺陷，并且有不少部分难以被自动化测试覆盖(好比界面的测试，可用性测试，探索性测试等)，因此敏捷测试也一样离不开手动测试。

至于关于自动化测试维护成本的顾虑，敏捷项目也确实存在变化比较多的特色，但一般变的都是比较接近用户的部分，因此应该尽可能减小用户级别的依赖界面的自动化测试，而多增长一些不容易变化的底层的单元测试接口测试等。

推荐敏捷测试以自动化测试为主，手动测试为辅。

敏捷测试

敏捷QA = 敏捷Tester

在不少刚接触敏捷实践的团队中，你们对敏捷QA的认识还停留在Tester的阶段，认为只要用户故事开发完成以后，QA去专职地作测试，发现缺陷就够了。

这是一个很大的误解，首先QA(Quality Assurance/Analyst)，不是单纯意义的测试人员，经过这个角色的名称咱们能够看的出来敏捷QA强调的是质量保障和分析，而不单纯是测试产品。

在实际的项目中，敏捷QA一般会从需求分析阶段就开始参与整个软件开发过程，经过在不一样阶段和团队中的不一样角色合做，帮助整个团队对质量达成共识，并经过在不一样阶段的确认和验证作到缺陷预防，而不是等到软件开发完成后再去发现缺陷，因此对于敏捷QA来讲，其目标是软件开发完成后可以发现的缺陷越少越好，而对于Tester来讲，发现越多的缺陷证实工做作得越优秀。

敏捷测试

非功能性测试不重要

非功能性测试指的是针对非功能性需求（软件自己知足用户需求所必需的功能性需求之外的一些特性，好比安全，性能，可用性，兼容性等）的测试，一般包括安全测试，性能测试，可用性测试，兼容性测试等。

在敏捷软件项目中，需求被切割成了很小的单元，在切割的过程当中，非功能性需求是最容易被人忽略的一部分，而这致使的问题就是非功能性测试常常被团队忽略，长此以往，就会造成这样一个误解，认为非功能性测试是不重要的。

这个观点很是不对，首先非功能性测试的重要性并不会由于软件开发模式的不一样而有所不一样，尤为安全测试和性能测试的重要性正愈来愈多地被重视起来，由于不少产品必须考虑到用户敏感信息的安全以及性能致使的用户满意度，在敏捷项目中因为软件会尽早发布，若是这些非功能性需求出现问题，就会更早地形成影响，极可能在软件刚步入市场就损失掉大多数的用户。

因此非功能性的测试和功能性测试同等重要，在实际的项目中，比较好的作法是将这些非功能性需求也加入到用户故事的验收条件中，在整个敏捷开发流程中对这些非功能性需求进行验证。

质量是QA的事儿

受传统观念的影响，不少人仍是会认为质量是QA的事儿，若是产品发布后质量很差是QA的问题，其余角色和质量没有太大的关系。

首先这种认识过高估了QA对质量的做用，软件的质量是在软件开发过程当中逐步造成的， 从需求分析阶段是否真正的了解到了客户想要的功能，到开发阶段是否增长了足够多的自动化测试保障，是否写了足够健壮的产品代码，到最后测试阶段是否测试了功能引入后整个系统的可用性，不一样用户路径是否能正常工做等等，这些都是软件质量的组成部分。

能够看得出来，在整个过程当中，软件的质量离不开敏捷团队各类角色的付出，其中有业务分析人员对需求的准确把握，有开发人员对产品代码的高标准实现，对自动化测试覆盖率的保障，还有QA在整个过程当中对质量相关活动的实施和保障，包括需求分析阶段从QA的视角对业务的补充，开发阶段对自动化测试的审查，以及探索性测试可用性测试等对产品质量的进一步保障。

因此在敏捷测试中更多时候咱们会淡化角色的概念，强调团队人人都为质量负责，这样更有助于团队的每一位成员都把质量做为很是重要的一部分，而不是依赖于某我的或者某个角色。

敏捷测试

开发能够写测试，再也不须要QA了

由于敏捷团队强调人人都为质量负责，开发人员会采用TDD等方式写大量的自动化测试，那么是否是就不须要QA了？

对于这个观点，在社区有过不少激烈的讨论，好比这篇文章《咱们须要专职的QA吗？》就曾经引发了很大的争议，其实我的认为这篇文章里提到的QA指的是Tester，具体二者的区别可参考前面的观点；抛开这个，做者的某些观点实际上是颇有价值的，好比做者最后提到了质量不是测出来的，要经过软件生命周期各个阶段相关活动的保障，而这些活动都离不开QA的参与。

首先需求分析阶段，QA能够从不一样的视角对于需求提出疑问，补充，修改，由于QA特有的技术背景，对于软件的可用性等有更深刻的理解，因此每每能够提出不一样于业务分析师和开发人员的观点；开发阶段，QA也会审查开发人员写的自动化测试，经过QA的专业测试背景帮助开发人员写更有价值的测试，好比咱们在项目中曾经发现开发人员写了不少没有业务价值的测试；测试阶段，探索性测试，可用性测试，安全测试，性能测试等都是QA们在作的事情。

固然，若是业务分析师从各类视角把业务分析的透彻完美，开发人员能够写很是有价值的测试，也能够作各类类型的手动测试，那么去掉专职QA也不是不能够，那样的话不是不须要QA，而是人人都是QA。

敏捷测试

结论

以上列出来的七点是刚刚接触敏捷测试时很容易进入的误区，甚至有的观点在一些已经施行敏捷很长时间的团队中仍然存在，这些观点很容易致使敏捷测试走上弯路，以上是结合实际项目经验我的的一些思考，但愿对你们有所帮助。