标签：过程 模块 一个 包括 技术 建议 构建 自动化平台 思想
之前看了一些互联网公司的测试经验和技术介绍。最近又翻出来重新看了一遍，感触还是挺多的，可能也是由于工作时间长了后有了一些新的感悟。
主要有百度，腾讯，阿里下属的几个子公司，内容比较杂，有介绍测试经验和测试技术的，也有介绍自己的测试工具和自动化平台的。
总结了一下，主要优点体现在以下几个方面：第一，尽早测试；第二，尽可能深入，测试从最底层开始，逐步上升集成；第三，尽量减少手工执行用例的工作量，大量使用自动化测试；第四，各种测试工具的开发和应用；第五，测试人员可以直接接触到线上系统和最终用户，这个渠道是畅通的。
第一点:尽早测试
这个是测试行业公认的准则，一个BUG发现的越早，修复的成本就越低（说到这里，我非常佩服《软件测试的艺术》这本书的作者们，这些大师们在上个世纪提出的思想现在依然适用）。
最快最省事的就是程序员在编码阶段中发现并修改的，这个在目前最主要的保证手段就是单元测试。
看了好几家公司的介绍，对单元测试都非常看重，甚至在淘宝网的文档中有一个表格，专门对代码质量从各个角度进行打分，其中单元测试的覆盖率就是一项很重要的指标。
另外在以前听一个讲座的时候也讲到，一个正确的测试体系应该是金字塔形状的，单元测试是最底层，同时占测试的比例也是最大的，大量的基本功能和编码错误应该在这个阶段就暴漏出来，而不是延迟到后端。
第二点：尽可能深入
测试从最底层开始，逐步上升集成。
这个其实和第一点有类似的地方，同样也是强调单元测试的价值和重要性。除此之外又强调把测试的工作和思想融入到整个开发过程中，这其实又包含了全功能研发团队的思想。
开发人员在编码时就开始考虑如何测试并进行测试，测试人员从单元测试开始，依次到白盒测试，模块级别的接口测试，系统级别的集成测试，场景级别的验收测试。
在每个级别有不同的测试策略和侧重点，越向上测试的角度越高，同时发现的问题也应该越少，如果到集成测试或者验收测试还发现有基本功能问题，那是应该好好分析下原因了。
我始终坚持一个观点：测试人员应该深入了解产品，深入到代码级别，只有这样才能够发现产品的潜在问题，或者说才有资格去和开发人员PK。只是做黑盒测试，很多场景是考虑不到的，很多问题也是无法想到的。
这一点上和我们的领导有冲突，他们认为测试应该站的层次更高，视野更开阔。我只想说，我觉得我们现在欠缺的是基本功，阅读代码，分析代码，理解业务，先把这些能力培养起来再说，如果基本功能都保证不了，何来的高大上？
第三点：尽量减少手工执行用例的工作量
大量使用自动化测试
这些自动化测试框架有业界通用的如jenkins，RF等，也有自己开发的平台。目标和功能基本都是相同的，周期性的有持续集成的版本。
代码修改和提交后能够第一时间启动构建验证正确性，绝大部分的回归测试自动化执行。
甚至有篇文档中说验收测试是唯一需要手工执行用例的阶段，虽然我不太相信这样是否真的可行，不过也可以看出他们对自己产品质量和自动化测试能力的自信。
第四点：各种测试工具的开发和应用
我印象最深的有两个，一个是自己开发的持续集成，自动化执行用例并输出测试报告的平台，类似于jenkins。
另一个是支付宝开发的外部支付系统的模拟器，为了模拟各种不同银行的支付场景，方便测试。这个模拟工具和我之前开发并且一直在用的模拟器比较像，都是被测产品和外部系统有强交互关系，而外部系统又无法控制。
所以自己开发工具来模拟这些外部系统，来方便构造各种真实环境中存在，但是研发过程中又很难产生的场景。
第五点：测试人员可以直接接触到线上系统和最终用户
这个渠道是畅通的。这个真的非常重要，像我们现在的产品，将来发布出去如何部署，用户的使用场景是什么，整个研发内部都是很模糊的，仅有的一些信息都要经过好几层中转，往往是已经用到现场出现问题了以后，这才知道用户原来是这么用的。
而像淘宝，他们的研发人员自己就是自己产品的用户，可以直接接触到线上系统，直接对线上系统的运行状态和日志进行分析，这样可以最真实的了解到产品的使用场景和最终用户的需求，更好的完善优化产品。
最后还有一点，测试人员的价值体现在什么地方呢？有一篇文档中说的很好，原话我记不太清了，大概意思是：测试人员的价值体现在发现设计和编码人员思维狭隘的地方，帮助他们修正这个期间产生的错误，提出自己的建议，还有提前识别可能的风险和问题，预防缺陷的产生。
从这个角度来讲，测试人员的工作不仅仅是发现BUG，向后一步包括如何修改BUG，向前一步包括如何预防BUG。
标签：过程 模块 一个 包括 技术 建议 构建 自动化平台 思想
原文地址：https://www.cnblogs.com/vvvviptest/p/13328432.html
