目前，关于软件测试有各种各样的书籍，有讲工具用法的，有讲职业发展的，还有讲方法论的，……林林总总，令人眼花缭乱。所以我就想啊，如果能够在自己看书的时候，对书中的内容以及实用性做个笔记，或许能够帮助同行小伙伴们去挑选书籍。以前也零散的在各行业微信群，或者自己的笔记本中，发表过自己对所阅读书籍的只言片语，但是未经整理。所以在博客上新开一栏，系统整理一下自己的读书笔记。 本文中的出现的小标题并非原书章节标题，而是我对内容二次提炼后，作为本读书笔记的小标题出现，特此说明。 《测试架构师修炼之道》作者 刘琛梅购买渠道： 京东等各大电商有售 第一部分 软件测试职业解惑本书第一部分对软件测试工程的职业规划进 ...

起因因为自己用的是RED这个编辑器，发现每次跑完case之后，编辑器中Message Log一栏展示的log很赞，所以就想保存下来。 不了解RED的，可以戳官网:http://nokia.github.io/RED/help/可以理解成RIDE的升级版，官方已经抛弃了RIDE的更新，使用了全新的RED作为替代。 而我平常运行自动化测试case呢，是通过命令行的形式运行，并集成到Jenkins中，自动运行，不走RED，所以也不会看到这一栏啦。于是就开始探索这部分log的来源。搜索了无数资料，发现一个有用的：https://blog.csdn.net/wyb199026/article/det ...

引子之前就有个想法，整理一下自动化测试的相关工具，开始的时候以为不复杂，但是只是简单的列表似乎又单调了些，没什么意义。如果加上介绍和相关说明，放在一篇文章里，又会太过杂乱。干脆还是先从细节开始，写个系列文章来介绍工具，后面再做整理，可能会清楚一点。从哪儿开始呢，要不咱先唠唠Selenium？ Selenium这是鼎鼎大名家喻户晓的工具了，大家应该都知道，它是做Web UI自动化的。但是初次接触的朋友可能还是会有点懵逼，什么Selenium1.0, 2.0, 3.0, 什么seleniumRC、Selenium IDE，Selenium Grid，还有WebDriver又是什么鬼？所以咱也来先简 ...

在《测试之美》的一个章节中，有提到selenium的一点历史，觉得很有趣，摘录如下：

有时候会看到一些很好的资料。选出我认为最有用的部分，放到这里，与各位分享之。 My Personal Source Code: Books to Learn Analysis作者在第一段这么说道： 偶尔人们来找我,说他们想学到某些东西。他们会问“我怎么成为一个好的测试人员”或“我如何设计测试用例”或者“我如何自动化”具体。不过,这些都是不正确的问题。更好的问题,它解决了所有其他的,是“我如何成为一个称职的分析师?“分析是所有技术工作的根源。这是主几乎一切的关键。你几乎将自动成为一个好的测试人员,测试用例设计,或者自动化的无论你选择,如果你掌握分析。(是的,同等优先的还有其他因素,比如人性,节 ...

在自我成长的过程中，输出是非常重要的一步。我之前简单的理解为，输出可能就是类似博客写文章，团队内做个分享，或者在各大知识平台上开课之类的。昨天和一个朋友讨论“输出”的话题，把输出分为单向和双向，一下子使我对输出的认知更加清晰了起来。 单向为了培养影响力。 双向更多的是为了交流。 在学习没有达到十分稳妥的时候，是很难进行单向输出的，因为此时自己都不能确定，需要经过总结和验证。此时进行双向的输出，通过交流，可以进行查缺补漏，提升自己。最终做到可以单向输出，提升自己的影响力。 这么想来，我们经常写的一些文章或者读书笔记，看起来形式上很像是单向输出，实际上可能并没有达到十拿九稳的地步，不能够 ...

目录自动化测试人员需要知道的50件事(目录篇)上一章自动化测试人员需要知道的50件事（第四章 运行，记录日志，验证） 关于这部分的说明：非原文翻译，是我根据作者原文，加上自己的理解，写下的内容。算是半笔记半心得体会性质的原创内容。为了加以区分，尽量把纯粹是自己观点的大段文字做了加粗处理。 1. 写的测试要让非自动化工程师也能看懂测试应该写得很好，以便易于维护和修改，并使您能够轻松找到执行过程中出现故障的原因。 那么，如何确定测试是否写得好？一种方法是让自动化工程师编写一个测试，将其展示给不熟悉编程的测试人员。 如果测试人员了解测试的内容，那么测试被认为是很好的。 2. 避免无必要的优化根据约束 ...

由于内容过长，分章节来发表文章。目录自动化测试人员需要知道的50件事(目录篇)上一章自动化测试人员需要知道的50件事（第三章 环境） 关于这部分的说明：非原文翻译，是我根据作者原文，加上自己的理解，写下的内容。算是半笔记半心得体会性质的原创内容。为了加以区分，尽量把纯粹是自己观点的大段文字做了加粗处理。 第四章 运行，记录日志，验证当在被测应用上运行测试时，详细的记录报告是很重要的。怎样组织测试，以及多久运行一次测试，也是十分重要的。本章描述了一些这方面的最佳实践。 1. 尽可能经常的运行脚本通常，在出现新版本时运行测试很有用。但是，如果测试不稳定，在应用程序正确运行的情况下也会失败，那么要测 ...

翻译整理自Dorothy Graham 和 Mark Fewster的文章That’s no Reason To Automate, 发表在Better Software, July/August 2009. 并非全文翻译，只是根据自己的理解，提炼整理了文中的相关观点。 发现更多bug 目标背后的好想法 测试应该发现bug，所以自动化测试应该更快的发现它们 因为测试可以执行的更快，所以我们可以执行更多测试，发现更多bug 我们可以对系统测试更多，所以我们应该在那些不能执行手工测试的部分发现更多bug 测试质量决定是否发现bug 如果最初进行的是手工测试，发现的bug应当被修复 重复旧测试并 ...

目录自动化测试人员需要知道的50件事(目录篇)上一章自动化测试人员需要知道的50件事（第二章 测试） 关于这部分的说明：非原文翻译，是我根据作者原文，加上自己的理解，写下的内容。算是半笔记半心得体会性质的原创内容。为了加以区分，尽量把纯粹是自己观点的大段文字做了加粗处理。 第三章 环境 Environment在软件测试自动化中，有两个重要环境：一个环境是创建和debug测试用的，另一个用来执行测试的。 1. 选择一套适当的工具满足你的需要有这么两类人：一类想用一个工具来解决所有问题，而另一类人，则是有一个新任务，就选一个新工具。实际上，应该选择介于两者之间的方案：选一个可以满足大多数需要的工具 ...