测试经典书籍中的观点（一）

《测试的艺术》

• 程序员应该避免测试自己所写的程序

备注：开发人员好比一座房子的建设者，测试好比是去找出房子的缺点漏洞，甚至是企图拆毁房子。

• 检查程序是否“未做其应该做的” 仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”

备注：项目测试的目的之一就是验证产品在特定条件下可以正常工作，而另一个目的则是找出项目的功能和性能极限。这也和测试的根本目标是想通的：测试不是用来找错误的，因为错误永远存在，测试只是验证某些条件下产品的能与不能。

• 程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比；

备注：正所谓80%的错误隐藏在20%的代码中，同样，80%的bug也会聚集于已发现bug多的地方。历经的项目来说，产生的bug除了分布集中之外，bug直接的关联性也极大，即一个bug的出现导致其他功能点不能实现，进而导致了更多的关联bug。

 

 

• 软件测试是一项极富创造性，挑战性的工作

备注： 通常情况下，测试人员只是对着一份需求文档在写用例，需要费尽脑细胞想尽需求点之间的关联，影响，特别要预测 对那些看似无关的功能可能产生的影响。而且，除了影响，更要有预见性。预测前后端开发中需要注意的坑，用例评审时，提醒可能的业务方面注意（对接产品），具体实现中的注意点（对接开发）。

• 代码检查

备注：通常情况下，测试人员对代码整体的要求也是为了开发团队。为了保证开发团队对代码质量的控制，一般测试人员会使用静态检查工具如sonar等对代码直接静态扫描，对扫出的严重级别的问题，推动开发及时修复。 甚至，在每次开发人员提测之前，先对代码质量进行扫描，如果有严重问题，直接让开发人员修复后再提测。目前经历的项目而言，虽然严格要求代码质量，最直接的影响是方便开发直接的合作，例如，不可能一个开发人员开发的代码完全违反代码的规范，极端的例子，这部分代码除了开发者本人，其他开发人员根本看不懂他的思路。其实代码质量也是评判开发人员本身素质的一个衡量标准，正如，可以很明显的区分一个应届毕业生写出的代码和 一个工作3~5年开发人员写出的代码。 当然，要求代码质量，其实也可以间接的减少测试人员的麻烦，毕竟一个开发人员的代码质量有严重问题的话，将给以后的项目和其他项目组的人员留下很大隐患。

 

ps : 其实 代码质量检查有可能有些难以推动的地方：项目的紧急程度（开发来不及修）；规范本身某些与开发的习惯相悖；与绩效无关，重视不够（或者，没有发生过看不懂别人代码的情况，只是偶尔吐槽一句：写的真乱）。

 

• 错误猜测法

备注： 实际项目中对测试猜测法的使用，就是判断产品在哪些情况下，不能正常工作，然后就是确认这些不能工作的场景对产品，业务方是可接受的。线下产品，特别是有使用前培训的产品，这种方法显得不那么重要，毕竟培训让使用者脱离了“小白”的范畴，使用也会更加规范。而对于线上产品，就要穷尽脑汁想想 当，用户“走偏”时，系统如何响应了。

 

• 开发与测试关系

 

 

• 极限编程与“测试优先于开发”

测试优先于开发的前提是：接口在开发完成前已经定义好了。但是这个针对接口临时需求变更的情况， 需要开发测试人员随机应变，及时变更。个人认为在实际的项目中有一定的局限性。针对需求中变化的部分[可控]的项目，接口只需要稍微改动便是新接口的情况，用例的准备相对简单，而且不容易因为变化白白做反复修改的无用功，从而直接找出接口中的bug。 但如果项目中的bug并非来自已定义的接口，或者说，bug的修改是针对需求中未明确定义的部分，或者开发人员的接口在发布之前，并非那么稳定，以及代码量很大的项目，测试优先于开发，未必适用。

 

《微软的测试之道》

• 微软测试工程师必备的十大核心能力

 分析问题和解决问题的能力。这个能力对测试人员非常重要，因为对问题进行分析并找出问题的症结所在是提高产品质量的关键。


 面向客户的创新。应聘者是否以客户为本，是否能够充分理解软件如何帮助客户解决问题，并对此充满兴趣和热情。


 精湛的技术。我们注重的是应聘者是否理解网络和操作系统，不仅能编写代码，而且能够优化代码。


 项目管理。对测试人员来说，这个能力是指如何有效支配个人的时间，以及如何策划和确保一个有许多互相依赖成分的计划得以按时完成。


 对质量的执着追求。如果不具备这个素质，应聘者就无法胜任任何工程技术工作，更不必说测试工作了。


 战略远见。开始时新员工这方面能力比较弱，但是如果我们旨在聘用能够帮助我们找到突破口的员工，以至于能够在竞争中遥遥领先，增加股东价值，那么应聘者一开始就必须具备这个素质。


 自信。在微软，测试人员找出的软件错误并不一定都能得到修正，必要时，测试人员需要有自信去据理力争。


 冲击力和影响力。影响力来自于自信和经验，冲击力来自于敢于革新。多数应聘者在谈到如何给自己的公司带来变革，或者如何在学校带领团队出色地完成项目时，都会体现这个特征。


 跨界合作。创新往往来自于各部门之间的合作，只顾埋头自己的项目，甘做井底之蛙的员工是不会成功的。


 人际意识。人际意识主要指自我意识，许多优秀的应聘候选人能够认识到自己的不足之处，并且知道如何不断地提高自己，也就是有一个不断提升自身素质的计划。

 

备注： 对面向客户的创新的理解。

始终以产品需求为导向，这不仅是对产品的要求，当开发，测试人员对一个需求决定做与不做，如何做的时候，是首要考虑的事情。面对一个需求的时候，首先考虑以下问题：

• 需求方真正的问题症结在哪里，真正的痛点在哪里？
• 痛点的解决有无其他非技术实现的方式（成本小）？到底做与不做？
• 现有的方案能否真正解决问题，如果不能，考虑即使实现，还有遗留哪些痛点？
• 按照现在计划方案有无可能再添加需求，使其能更“强大”？
• 现在的计划方案对需求方的帮助多大（痛点解决程度），技术人员的投入产出是否明显？

ps: 技术人员的high level 是做真正问题的解决者，而非仅仅是按照“需求”做事。一切工作的核心是围绕需求和痛点进行的。 这也是需要持续提高的地方。

• 开发和测试人员比例

微软开发人员和测试人员的比例=1：1，软件行业，典型的比例是5：1，有的是10：1，甚至更高。当比例如此悬殊时，测试组就只能抓根本而无暇顾及及测试技术和方法的改进了。

备注：开发与测试人员的比例并不是一定和测试人员的[繁忙]程度成正比。关键在于对于测试本身而言，可以留出多少时间来做测试技术的改进。如果项目过紧，测试人员的精力被跟项目耗尽，那么测试人员感到的不仅仅是[身心俱疲]，长久下去，必然会导致恶性循环，消耗测试人员的积极性和自身素质提高。

• 职业发展道路

ps: 看到书中竟然有[技术院士]的级别，果真很少见那。不过从职业发展历程来看，目前国内公司基本符合此过程。

测试经理必须很懂技术，但要求其成员更多精力放到测试工具和流程上，而非具体的功能测试上。

 

• PDCA

 

戴明循环研究起源于20世纪20年代，有“统计质量控制之父”之称的著名的统计学家沃特·阿曼德·休哈特（Walter A. Shewhart）在当时引入了“计划-执行-检查（Plan-Do-See）”的概念，戴明后将休哈特的PDS循环进一步发展成为：计划-执行-检查-处理（Plan-Do-Study-Act）。
P（Plan）--计划，确定方针和目标，确定活动计划；
D（Do）--执行，实地去做，实现计划中的内容；
C/S（Check/Study）--检查，总结执行计划的结果，注意效果，找出问题；
A（Action）--行动，对总结检查的结果进行处理，成功的经验加以肯定并适当推广、标准化；失败的教训加以总结，以免重现，未解决的问题放到下一个PDCA循环。

 

备注： 项目中的流程改进，极有可能为了改进而改进，导致其中部分步骤实际对项目质量的提高意义不大。 流程改进应该针对项目，依据项目中bug产生的原因做具体分析后进行，如果盲目引入过多的步骤，反而被流程所累。

 

• 测量路径复杂度

圈复杂度 ，它可以精确地测量路径复杂度。通过利用某一方法路由不同的路径，这一基于整数的度量可适当地描述方法复杂度。实际上，过去几年的各种研究已经确定：圈复杂度（或 CC）大于 10 的方法存在很大的出错风险。

• 测试缺陷数不能作为绩效
• 其他工具

代码改动量

• 用户反馈系统
• 质量归谁管

备注：人人有份。公司需要提倡质量文化，每个人对质量起到不同层面的质量保障。项目中因为这样那样的原因，或许会破坏质量保障中的某一个环节，找一个权衡。所以，当开发人员急于上线时，必然存在质量和速度之间的平衡了。

• 质量成本

备注： 每个环节对质量的投入和产出。

质量成本：

• 鉴定成本（测试人员薪资+发布的费用）
• 预防成本（实现和维护预防技术相关的开销）
• 失败成本（返工的花费）

我们很少会衡量预防成本，更少会去奖励它们。相反，通常更源于关注英雄行为-工作一整夜去修复最后的几个缺陷，或者在最后关头调研怎么绕开一个严重问题等。

质量成本提高的例子：

• 重新编写或设计一个组件或功能；
• 因测试失败而重新测试；
• 对一个具体实现进行反复修改
• 测试领导团队/测试架构师

PS：

跨事业部门提供或解决测试人员普遍面临的挑战和问题；
演化研发流程，使得质量控制向上游移动
通过自动化，高效工作方法，提高测试流程的吞吐量