《软件测试的艺术》读后感

背景

​ 公司开始推荐相关阅读书籍，其中有一本书的要求是：“针对该行业的入门级必读书籍”，回头一看自己看过很多相关测试的书籍（囫囵吞枣模式┑(￣。。￣)┍ ），但确实没法一下说出来哪本书属于入门级必读书籍（毕竟自己刚进入测试行业的时候，完全是来靠自己摸爬滚打，在整个工作经验中慢慢的阅读相关书籍😂，当时也没有想到要针对性的指导自己去学习测试这门技术）。

入门级人群的定义

​ 入门级必读书籍面对的人群我个人认为大概画像是：从未接触过测试或刚进入测试行业的人群（不一定工作年限为0，可能存在其他领域转到测试行业）。

行动

​ 通过网上找了一些相关比较热门的推荐，其中一个是《软件测试的艺术》（豆瓣评分8.4分）。虽然原来也读过，但没有从入门这个维度去思考整本书籍，借此机会又重新阅读了整本书籍。

​ 阅读完后， 根据我已知的国内测试行业的现状以及书内的内容做了以下的一些总结。

• 适合入门阅读的章节；
• 不适合入门阅读的章节（也可以理解为适合：1～2年测试工作经验的人群，存在一定的测试基础以及相关经验的人群）；
• 其他章节（此章节属于通用能力的提升，不一定仅仅适用在测试行业，如果时间允许还是建议阅读）。

比较适合阅读的章节

• 章节1：简单的通过一个简单的小测试，来说明做好测试这件事并不是一个简单的事，从而也间接的体现了测试这个行业的挑战。

• 章节2：从心理学和经济学的层面解释如何进行测试，并且梳理了一系列的软件测试原则。
  以下展示个人觉得比较有同感的原则（有兴趣的可以自行阅读相关章节）。

  1. 测试用例中必须部分是对输出和结果的定义（是能量化或者有标准能衡量的） ，应该必须包含的两个部分：对程序的输入数据描述以及相应的正确输出结果描述。
  2. 应避免测试用例用后即弃，除非软件本身就是一个一次性的软件。
  3. 程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比。
  4. 软件测试是一项极富创造性、极具智力挑战性的工作。
  5. 一次成功的测试用例能够发现未知的错误；
  
  

• 章节4：分别对白盒/黑盒测试的测试用例设计方法进行介绍，但实际网络上有更多翻译的形式（建议了解到存在此类型的设计方法后，多查看几个网上的样例，最终形成自己的理解）。
  白盒测试用例设计方法

  • 语句覆盖；
  • 判定覆盖；
  • 条件覆盖；
  • 判定/条件覆盖；
  • 多重条件覆盖。
  
  

  黑盒测试用例设计方法（前三种基本属于最常用的，建议深入）

  • 等价类划分；
  • 边界值分析；
  • 错误猜测；
  • 因果图分析。
  
  

• 章节6：比较全面的介绍了除了平时做的功能测试，实际还存在各种各样的测试类型（比如：安装测试、存储测试、易用性测试等），这些测试类型可以去帮助发现那些不常见但又严重的缺陷。
  在大部分刚入职做测试的同学，可能刚开始做的都是界面上的点点点（当然也有接口测试或者其他方面的测试）。此章节比较全面的介绍了除了功能测试，还能进行哪些测试。
  比如（此处未全部列举，有兴趣的可以深入阅读相关章节）：强度测试、易用性测试、性能测试、存储测试、配置测试、兼容性测试、安装测试等等。

• 章节9：更加细致的去介绍了现在互联网下，测试行业面临的一个困难和挑战。
  具体的难点可以分为以下三个层面（大部分行业内测试主要集中在表现层以及业务层，业界也有相应的分层测试概念，有兴趣的可以深入了解）：

  • 表现层一一主要目的是发现应用程序的GUI或前端中的错误。测试点为：
    内容测试：包括整体审美、字体、色彩、拼写、内容准确性和默认值；
    用户环境：包括浏览器版本和操作系统配置，移动设备的操作系统以及版本等。
  • 业务层一一主要目的是发现应用系统的业务逻辑中的错误。测试点为：
    数据有效性：发现从客户那里采集到的数据中的错误；
    事务：发现事务处理过程中的错误，包括：信用卡处理、下单处理、打款处理等；
    业务性能。
  • 数据层一一对应用系统用于存储和获取信息的数据库管理系统的测试。测试点为：
    响应时间： 量化Sql中的 Insert、Update、Delete、Select以及事务的完成时间；
    数据完整性：验证数据存储适当且正确；
    容错性和可恢复性： 最大化MTBF，最小化MTTR。

不适合阅读的章节

• 章节3：详细的介绍了代码检查以及走查两种方法论，通过该方法可以更加快速的发现问题并解决。
  不推荐的原因：从已知的经验中，暂未发现有 哪个测试团队 在这方面做的比较好或者是有公开的最佳实践经验。该环节是一个比较繁琐的一个环节（并且现在也出了部分静态扫描工具），即使存在该环节，大部分也是流于形式。

  该章节比较适合开发人员阅读，或者是测试人员阅读后在开发团队进行推广。

• 章节5：详细的介绍了如何去进行单元测试，从更小的模块更快的去发现问题。
  不推荐的原因：从已知的经验中，暂未发现有 哪个测试团队 在这方面做的比较好或者是有公开的最佳实践经验。大致归于代码内部严重耦合、函数未满足单一功能以及版本迭代过快等原因，导致该环节可能费时且收益小。对于测试来说，该难度较大。

  该章节比较适合开发/专职测试开发的人员进行阅读。

• 章节8：章节名叫 “极限测试”。
  一个高大上的名词，但整体看下来属于敏捷迭代中的一个缩略版，仅包含测试中的单元测试以及验收测试，主要靠程序员本人进行相关测试（看起来都无需测试人员了）。其中用了一个比较小的 Java 程序进行说明该方法。

  该章节比较适合开发/专职测试开发人员阅读。

其他章节

• 章节7：详细的介绍了定位/发现问题根本原因的方法论。通过掌握这些方法论后，可以更得心应手的去深入挖掘问题，而不是简单是只发现某个缺陷的表象。
  此章节优先级相对较低，可以理解如果想做的更好可以阅读。（这些章节的内容需要花费较多的精力，但收益也比较客观）

总结

​ 以上所有内容根据个人经验判断（ 也可能是本人经验比较少，未发现相关好的实践 😂，如果存在不认同的地方欢迎讨论）。