:Web前端测试与集成金鑫等 pdf下载

基本信息

书名：Web前端测试与集成

定价：69.00元

作者：金鑫 等

出版社：清华大学出版社

出版日期：2017-08-01

ISBN：9787302472759

字数：

页码：381

版次：1

装帧：平装

开本：16开

商品重量：0.4kg

编辑推荐

内容提要

　　全书共分为四部分。一部分为基础篇，总览了前端开发测试中的挑战与测试转型，介绍了测试基础环境的搭建；第二部分为单元测试篇，深入介绍了如何基于Jasmine单元测试框架和gulp、Karma等构建、执行工具对前端代码进行单元测试，以及AngularJS单元测试的实践和代码覆盖率等；第三部分为自动化测试篇，基于Protractor介绍了在Node.js环境下通过Selenium WebDriver全面覆盖各个主流浏览器，进行自动化测试的实践，包括页面对象模型、性能测试和分布式测试等；第四部分为集成篇，阐述了基于持续集成以实现更快、更可靠的软件交付，展示了如何通过Jenkins与TFS、VSTS和GitHub的集成，实现Web应用的持续测试。

目录

作者介绍

　　金鑫，微软专家级工程师，目前和微软平台即服务产品（PaaS）Azure App Service的产品组合作，为微软Azure App Service的支持工程师提供技术咨询、解决方案和自动化诊断工具。自2000年加入微软亚太区全球技术支持中心以来一直专注于企业级Web应用和分布式系统，精通IIS，ASP.NET，Windows Workflow Foundation, + 等技术。近几年致力于现代Web开发技术和云计算，包括开源的AngularJS, TypeScript以及Azure App Service。 武帅，微软专家级支持工程师。于2011年加入微软后一直专注于企业级应用的开发与技术咨询工作，精通ASP.NET MVC, Entity Framework和AngularJS等Web前端技术。目前主要致力于微软公有云Azure、Visual Studio Team Service、Xamarin和.NET Core等新兴技术的开发咨询与推广。

文摘

　　章前端开发测试总览第2章搭建测试基础环境

　　3章前端开发测试总览和ASP等生成这样的字符串。换句话说，所谓的“前端”是由后端服务器动态输出而成的HTML网页。在这样的传统Web应用中，前端只是充当一个展示层，服务调用、网页跳转流程等都需要由后端服务器处理。每当网页功能有所变化时（即使网页内容只有细微变动），浏览器都需要重新发起一个请求到服务器，然后由后端服务器重新生成整个页面如图1-1所示。这种方式不但增加服务器的负担，降低响应速度，而且浏览器重复下载整个网页会浪费网络带宽，对于移动应用很不经济。服务器浏览器初始请求HTMLHTMLPageReloadFormPOST图1-1传统网页生命周期而在现代Web应用中，当网页的部分内容需要更新时，运行在浏览器内的代码通常会向服务器发送Ajax请求，而服务器端只需输出必要的数据，不需要重新构造整个HTML页面，如图1-2所示。Web前端应用接收到来自服务器的数据后，只需重绘界面上需要变化的部分。这种方式提高了应用的响应速度，改善了用户的使用体验。同时，因为很多用户交互的处理工作可以在浏览器内完成，无需向服务器发送请求，服务器和浏览器之间交换的数据量大幅减少，所以服务器负荷降低，响应速度也更快了。Web应用渐渐开始拥有和桌面应用一样的响应速度和使用体验。服务器浏览器初始请求HTMLJSONAjax｛.｝图1-2现代单页应用（SPA）生命周期除了网页内容的更新，Web应用一部分业务逻辑的处理也从后端服务器慢慢移到前

　　端，Web前端开发变得越来越重要。而这一切都离不开。

　　是1995年由Netscape工程师BrendanEich花了10天的时间创造出来的，其初目的是为了满足用户浏览网页时产生的交互需求。可以说，是为开发Web应用而诞生的。

　　自其诞生起的相当长一段时间内，这门在浏览器内执行一些简单的校验和互动的脚本语言常被称之为“玩具语言”，堪称世界上被人误解深的编程语言a。在简洁的外表下，其实有着强大的语言特性。它是一种面向对象的动态语言，包含类型、运算符、标准内置对象和方法。其语法来源于Java和C，所以这两种语言的许多语法特性同样适用于。

　　随着Web应用的普及，自身也在不断演化以适应更复杂的编程需求，目前已经成为Web前端的实际标准，也是热门的编程语言之一。各种前端框架，包括Ember、AngularJS、React和Vue等不断涌现。

　　正因为基于前端应用越来越重要，功能越来越复杂，对前端开发测试带来了极大的挑战。如何保证Web前端应用的正确性和可靠性成为了各大企业关注的问题。

　　在市场需求的推动下，Web前端应用规模不断扩大，一个应用可能有成千上万行代码。这些代码用于执行各种复杂的功能，为用户提供不同的交互体验。为了确保它们能实现预期的功能，因此Web前端应用测试的工作量也需要相应增加。相对于传统的桌面应用，用户只要重新刷新浏览器就可以获得新版本的网页，所以Web前端应用具有天生的快速迭代特征，可以频繁地更新和发布。而激烈的商业竞争也使得Web前端应用开发周期缩短，对应的测试周期也非常短。除了代码，Web前端应用还有各种超链接、表单以及图片等信息，需要保证在不同的操作系统和浏览器上可以正确显示网页的内容。1.2传统开发流程的局限性在过去二十年或更长的时间中，传统的、非敏捷的瀑布式软件开发模式通常依赖于一

　　aDouglasCrockford.TheWorld'sMostMisunderstoodProgrammingLanguage...crockford./..

　　章前端开发测试总览

　　个严格的模式化开发流程。通常认为瀑布模型a是WinstonW.Royce在1970年提出的软件开发模型（虽然他并没有使用瀑布waterfall这个单词）。这种方法源自传统工业生产，严格遵循预先计划的需求、分析、设计、编码、测试和部署的步骤顺序进行，每个步骤都有严格分工，由不同的技术人员分别执行。执行步骤的成果作为衡量进度的途径，例如需求规格、设计文档、测试计划和代码审阅等。但随着各种新兴技术的蓬勃发展，特别是在产品快速迭代的需求背景下，这种传统开发流程的局限性日益明显：

　　1.自由度低，缺乏灵活性传统模式在项目早期即作出承诺，基于稳定的目标进行阶段性的开发，这种方式自由度低，应对突发情况时缺乏灵活性。众所周知，需求会随着时间而变化，经常出现开发人员努力在设计前完成文档，在编写代码前完成设计，后却因为需求有变化而不得不完全推倒重来的情况，不仅大量工作被浪费，甚至导致对后期需求的变化难以应变，代价高昂。

　　2.缺陷发现晚，无法及时反馈传统流程一般在开发阶段接近尾声时才开始测试。虽然在这个阶段进行测试相对容易，但是一些在早期的单元测试中可以轻易发现的缺陷可能要到后阶段才会发现，增加了被遗漏的风险。

　　由于缺陷发现得很晚，如果要解决问题，则有可能导致错过发布的后期限，再加上手工测试效率低下，任何一次代码变更或缺陷修复对产品的影响都无法迅速反馈给开发人员。随着发现的缺陷越来越多，开发人员只会对变更没有信心，失去持续完善的动力。

　　3.协同合作缺失，容易引起团队冲突传统流程中每个步骤都有严格分工，不同阶段的技术人员与上下游的工种往往沟通较少，甚至对产品本身的理解也存在差异。例如，开发人员和测试人员在思维和工作方式上的不同，使得他们对软件需求和测试场景的表述发生歧义，从而引起双方的沟通问题。而这些理解上的差异如果直到测试阶段才被发现的话，则实在太晚，此时双方的冲突与指责对解决问题没有任何帮助。

　　4.产品质量无法保证传统流程中常见的一个场景是在项目后期将要交付的阶段，技术人员仓促地从开发环境构建转为脚本配置，而长期在开发环境内依靠手工管理，构建脚本的时候就可能会遇到各种各样的问题，例如接口没有定义、配置文件丢失、组件不工作等。为了解决这些问

　　aWikipedia.Waterfallmodel..sen.wikipedia.org/wiki/Waterfall_model.

　　题，技术人员不得不把主要精力放在软件构建上，结果时间成本越来越高，产品质量无法保证，甚至出现产品无法按时交付的情况。

　　1.3传统手工测试的局限性软件测试是在规定的条件下对程序进行操作，以发现程序中的错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。软件测试的目的是希望以小的代价尽可能多地找出软件中潜在的错误和缺陷。

　　首先，测试人员会针对开发人员开发的功能写出测试用例，例如表单应该填入的数据，页面单击顺序，以及后页面期待的显示效果。然后，测试人员会按照用例一步步进行手工检验，如果发现页面行为异常，例如无法打开页面或生成的数据不正确，则会在企业缺陷管理系统中提交缺陷记录，供开发人员进行修正。在开发过程中，如果有新版本编译出来，测试人员需要根据测试用例重新测试，确认是否有新缺陷，或者老缺陷是否已经得到了修正。

　　长久以来，这种传统的手工测试模式在各大公司广泛应用，并已被证明其能够行之有效地保证产品质量。但伴随着互联网技术的发展，这种传统的测试模式已经显示出越来越多的瓶颈。

序言