随着互联网进入开源的时代。市场上的各路产品就竞争进入了一个更加严峻的挑战时代。各个产品各个理念像奇迹一样不断的充斥着市场，分割着市场。人们的选择性更多,要求越来越高。随着数据不断的增长，对于软件处理这些庞大数据的整体性结构就给出了一定的挑战。面对庞大的数据和复杂的结构，如何能够保证产品的质量，降低在市场上的风险成了棘手的问题。产品质量存在的问题不外乎人和技术所产生的原因。
对于人本身来讲，人们的想法、看法、思想、能动性、学习性、认知力等等都会随着时间的增加和环境的变化而改变，人们所经历每一分每一秒都可能影响工作的主动性和积极性。年龄越大经验越丰富，但是年龄本身也是一个容易产生问题的因素。随着年龄的增长，人的主动性会随着日益更新而更新，还是会随着沉淀而变得懒散，这就要看个人本身对自己的要求是怎样的。所有这些隐性的因素都渗透在人们每天的日常工作中。
技术本来就是要靠人去实现的。软件开发原本就是一个高技术含量的工作，需要技术人员时刻都要保持清醒的头脑、缜密的思维和高度思考。但不幸的是，这些潜在的问题都在一点点影响着软件的质量。如果说产品存在这样那样的缺陷，不如说人本身就先天存在这样那样的缺陷。在说技术吧，每个人跟每个人年龄不同、经验不同、IQ不同等等都明显的产生了差异。有编码好的，有编码差的。编出来的东西五花八门。在加上不同的架构不同的语言等等都在制造着无限的缺陷。
因为缺陷的产生，便有了质量保证。产品在进入市场以前，这就是个关卡。也是最重要的部分。但是它只能是一个关口吗？我觉得它可以是一个带关卡的桥梁。因为它既可以做到给前方市场人员补给，给后方开发人员提供支持。
如果我们仔细看看软件开发的方法，会发现软件开发由重量级开发不断的在像轻量级演变。随着开发时间的缩短和快速发布，使得软件质量在短期内很难得到保障。又因为轻量级的开发过程没有对大量正式文档有过多的要求，这便隐形的提升了软件后期潜在巨大的风险。
通过以往的测试工作我们会发现，随着软件需求不断的被大量快速更新，而文档又不充分的条件下。新加入的开发人员会出现无从入手的情况，因为没有旧文档的指引，外加上因为开发时间缩短而产生的培训不足的问题。我相信从开发人员对基本的设计都无从下手的时候，这一刻想法的产生就为缺陷的诞生奠定了基础。在本来就时间有限的前提下，在加上文档的不健全，bug会容易呈现几何数字的增长。
如果在这种条件下，质量保证只是一个关卡的话。对于开发的开销就会大大增加，因为改bug需要时间，需要金钱，当一个产品还在制造的过程中，市场上就已经出现了新的产品。无论是时间的增长开发的时间或是开发人员的增加，都无疑是加大成本d和市场快速竞争力的风险。尤其是在这个开源的时代。
轻量级开发虽然带来的一定的问题，但是它可以让只有关卡的质量保证更加灵活到成为一个带关卡的桥梁。使得测试工作达到轻量级优化。著名的轻量级开发方法极限编程（XP）。因为它的内层的过程是一个个基于测试驱动的开发（TestDrivenDevelopment）周期，诸如计划和设计等外层的过程都是围绕这些展开的。每个开发周期都有很多相应的单元测试（UnitTest）。刚开始，因为什么都没有实现，所以所有的单元测试都是失败的；随着一个个小的需求模块的完成，通过的单元测试也越来越多。通过这种方式，客户和开发人员都很容易检验，是否履行了对客户的承诺。XP提倡对于简单的设计（SimpleDesign），就是用最简单的方式，使得为每个简单的需求写出来的程序可以通过所有相关的单元测试。XP强调抛弃那种一揽子详细设计方式（BigDesignUpFront），因为这种设计中有很多内容是你现在或最近都根本不需要的。XP还大力提倡设计走查（Review）、代码走查以及重构（Refectory），所有的这些过程其实也是优化设计的过程；在这些过程中不断运行单元测试和功能测试，可以保证经过重整和优化后的系统仍然符合所有需求。
而且这种以测试驱动开发的好处就是可以在推动开发的同时检查代码的质量。因为XP就提倡在开始写程序之前先写单元测试。开发人员应该经常把开发好的模块整合到一起（ContinuousIntegration），每次整合后都要运行单元测试；做任何的代码走查和修改，都要运行单元测试；发现了BUG，就要增加相应的测试（因此XP方法不需要BUG数据库）。
除了测试驱动开发，还有通过cucumber来实现的以需求为基准的行为驱动开发（BDD）。行为驱动开发是测试驱动开发的进化，但关注的核心是设计。以定义系统的行为为主要工作，而对系统行为的描述则变成了测试标准。在行为驱动开发中，使用通用语言来定义系统行为。而通用语言，实际上是一个最小化的词汇表。我们使用这些词汇来书写故事。选入词汇表的词汇必须具有准确无误的表达能力和一致的含义。将需求变成一个个故事，逐条生成测试点，然后在通过这些测试点做进一步开发。
从测试入手引导开发，这样子不仅可以随时跟踪代码的状况，也可以随时掌握开发的进度和功能的覆盖率。相对于开发出成品在进行功能的一个覆盖率检查来讲更加有效率。也可以随时随地的让开发能够在工作的时候保持清醒的头脑。
单元测试无论是前端的页面也好，还是后面的逻辑处理也好。每一个层都有相对应单元测试工具。例如：js 单元测试软件可以有phantomjs来测试，html有html unit等等。如果每一层都能做好有效的单元测试，至少对代码的健壮性、后期代码的重构等等都会起到一定的效果。但是这就要求测试人员有很高的编码功底，至少要有5-10年以上的开发经验，也同时要熟悉软件测试的基础理论。测试如果能帮助开发做一些工作上的帮助，这样就可以大大支持开发的工作和时间上的节省。这就实现了根本的有测试驱动的开发的价值和意义。在成本上也可以进行一定的节省。
虽然单元测试很重要，但是我们也需要通过集成测试、性能测试、安全测试和功能测试这些测试对成型后的产品进行进一步检查。集成测试、性能测试和安全测试都需要测试人员具有扎实的理论基础和广泛的知识基础。
功能测试是测试中最基本也是最常用的测试方法。UI的功能测试通常分为手动和自动两种。手动是最接近用户真实使用软件的一种测试方法。而自动化是模拟手工来对ui进行测试的。无论这两种测试使用哪一种，都会面临一个问题，那就是投资回报率(return on investment，ROI)过低。
尤其是对于敏捷开发流程来讲。因为在进行手动测试之前要准备测试文档，准备文档需要时间，执行文档需要时间，在最初功能还不是很多的时候，这个时间可以充足，但是在随着功能不断的复杂化的时候，每一轮的回归测试都会随着时间的增加而增加。对于手动测试来说这还算是好的，如果是自动化的话那就要崩溃了。因为软件在最初的时候稳定性很差。无法把大量时间都用来写测试脚本。但是也不是没有可以解决的办法，可以通过badboy进行脚本录制，边测试边录制脚本。这些脚本还可以与jmeter结合用于性能测试。在alpha测试阶段，公司内部测试的时候。功能的手动测试可以结伴测试，几个人一组模拟真实的用户场景，通过不同平台进行结伴测试。效率可以大大提升，出现问题相互之间可以一起讨论，共同进步。
对于一般的提供于企业内部使用的软件来讲，beta测试是通过终端用户来测试的。但是如果是电子商务、即时通讯这样的产品，很难要求用户来测试。游戏产品的话可以公测。这个时候我们就需要新的测试理念。
在工作中，我总结出一种测试方法，叫做：“推广式测试”。通过推广产品的方式，与用户一起互动找出产品重要的潜在的缺陷，很准确的知道市场上用户的真实使用场景，第一时间得到反馈，能快速定位出软件出现的严重错误和用户对需求不满意的地方，也可以很好的体现出公司的服务质量，不至于让用户觉得产品出了问题没人受理的感觉。
这种方式可以有效帮助企业的产品度过市场磨合期的风险期，大幅度的提升企业的产品在市场上后期需求改进的精准度。此测试方式将产品推广出去，所以有效的控制了产品在市场中的竞争力。尤其是降低新产品新理念投放市场后在被客户认可的过程中存在的风险和阻力。也很好的推动产品设计和开发的工作。通过这种测试我们可以发现当软件存在某些缺陷，但无法在短暂的时间内通过技术来弥补的时候，可以找寻借助其他媒介弥补这些缺陷。例如：百度问答，博客使用说明书等等。
在这个测试过程当中，可以一点点的把功能写成详细的说明书。通过这个说明书将散乱的需求整理出来，而这份说明书不仅可以提供给开发人员用于对新员工的培养或者用于他们自己，也可以提供给销售，随时了解产品的最新进展，这便实现前方销售补给。
在功能测试前，都会面临一个很大的问题，那就是需求文档的整理。在快速、复杂、无头绪的需求文档面前我们如何有效的跟进，又能够提高工作效率，不防试试xmind的思维导图。横扫一切烦恼，可以达到准确、快速、及时的需求更新、筛选、规划。然后将现有定型的模块整理到测试用例中作为永久保存。大幅度提升测试人员日工作效率。
在功能测试的时候又想知道覆盖率的情况，但又不想写过多复杂的内容，可以使用以功能点为主的覆盖率表。将每一个功能点出现的bug都能有效的整理出来，并且直观的看到每个功能的情况都是如何。
以上便是我通过阅读大量书籍、查阅大量资料，学习、实践、整理出来。有些东西也许看的不是很准确，理解也不是很透彻。但是也不是空穴来风，无从根据随便讲。一寸光阴一寸金，寸金难买寸光阴。你的一秒钟失去便是他人一秒钟的获得。比尔盖茨说的对“This is a fantastic time to join the business world,because business will change in the next ten years more than it has changed for the last fifity years.”
https://www.linkedin.com/pulse/%E8%BD%AF%E4%BB%B6%E6%B5%8B%E8%AF%95%E8%B4%A8%E9%87%8F%E4%BF%9D%E8%AF%81%E4%B9%8B%E6%88%91%E8%A7%81-jin-song?trk=hp-feed-article-title-publish