一、测试的态度
知名足球教练米卢曾说过“态度决定一切”。在我们的生活和工作中，一个好的态度将是影响我们是否能够成功，是否能够取得进步的最重要因素。足球运动员有“足球的态度”，我们软件测试人员也应该有“测试的态度”，因此本书将“测试的态度”放在了第1章作为本书最重要的内容。先点燃读者心中积极的火焰，然后再带着良好的态度来吸收和了解其他软件测试的相关经验和观点。
二、精益求精
精益求精不仅仅是一种做事的标准，更是一种做人的态度。无论是测试用例设计、性能测试、回归测试、测试脚本开发还是测试工具开发等任何一个测试的分工，都需要用精益求精的态度来提高每个测试环节的质量，并相应地提高产品的测试质量。
案例
A是某著名软件公司的软件测试人员，工作的流程非常严谨而明晰，这自然也意味着重复劳动。但枯燥并没有淹没A的工作激情，发现一个bug会带来很大的成就感，特别是想到每天将会有几百万人通过使用没有这个bug的软件准确无误地达到他们的目的，A就特别有成就感。虽然可能一整天都为了一个小功能“循规蹈矩”地反复测试，但是这样的重复却被A当做一种重要的积累，在积累中不断地追求精益求精的完美。
正如新东方学校的徐小平在其著作《骑驴找马》中的一句话：“重复做汉堡，就是麦当劳；重复煮咖啡，就是星巴克；重复教托福，就是俞敏洪；重复做好事，就是活雷锋。”重复的过程也是追求精益求精的过程，每一次重复都需要比上一次做得更好、更精彩，你才能不断地进步，并做到极致的成功。
三、测试用例设计的精益求精
测试用例设计工作本身是一个很难直接定量的工作，也不可能像开发代码一样，只要编译通过可执行就认为完成了任务。那么在测试用例设计过程中，我们如何才能促进测试用例设计水平的提高呢？测试用例的设计和编写基本上只有依靠测试工程师自己精益求精的态度才能保证测试用例设计的质量。测试人员自身精益求精的态度，不但影响着测试用例的设计质量，而且直接影响着测试人员之间测试水平的高低。
在设计测试用例时，精益求精的精神需要我们在完成每一个功能测试点的基本测试方法设计后，再继续投入时间和大脑，并继续发散思维，在基本测试方法的基础上多写出一两倍的测试方法，希望所设计的用例能发现更多的bug，使测试的质量取得更好的效果。有一天你会发现正是这些多写出的测试方法更容易发现bug，帮助测试人员提高自己绩效的同时得到测试的乐趣。因为最基本的应用模式，90%的人都会比较容易地想到和覆盖到；而质量提升的最后10%，则可能只有很少的人，也许是10%的人才能去实现和达到。所以当我们在进行功能测试的测试用例设计时，每多想一个测试方法，就越接近99%的质量目标。
案例
一个即时通信产品的服务器与客户端通信功能模块的测试用例
基本测试要求：服务器与客户端之间传送文本信息的功能测试（不包括压力测试和性能测试）。
大多数人很容易就想到如下测试方法：
（1）服务器向客户端发送一段文字，如果客户端能收到完整的信息，则验证通过。
（2）客户端向服务器发送一段文字，如果服务器端能收到完整的信息，则验证通过。
倘若只是进行最基本的通信功能验证，好像如上两个测试方法已经覆盖了服务器与客户端通信的全部功能。可是，如果我们能追求测试用例设计的精益求精，则该功能的测试用例还可以再进行如下补充。
测试策略1——测试数据集
服务器与客户端通信的测试数据分为：全中文（不同编码格式）、英文、日文、中英文+数字+其他符号（@、#、!、～、&等）的组合、以数字及各类符号作为传送信息的最后一个字符。
以服务器能输入字符信息的最大数量为依据，输入一个最大化的数据，判断客户端能否完整显示。
以客户端能输入字符信息的最大数量为依据，输入一个最大化的数据，判断服务器能否完整显示。
应用测试策略1，服务器端与客户端1:1同时进行双向通信。
应用测试策略1，服务器端与客户端1:n同时进行双向通信。
应用测试策略1，服务器端与客户端n:1同时进行双向通信。
四、性能测试的精益求精
在进行性能测试时，我们需要细致地关注每一个数据的变化，不放弃任何一个怪异的数据变化是最基本的性能测试工作的态度要求。那么在性能测试中的精益求精可以体现在哪些地方呢？一个性能测试活动本身大致需要经历如下4个阶段。
第1阶段：选择可靠的性能测试工具。
第2阶段：调试及稳定性能测试环境。
第3阶段：正式的性能测试。
第4阶段：统计性能测试结果，输出性能测试报告。
在选择可靠的性能测试工具阶段，如何做到精益求精？可能有朋友看到这里会问：“选择工具还需要精益求精？那么如何精益求精？”。俗话说：“好的开始是成功的一半”。软件的性能测试非常依赖性能测试工具的长期高负荷运转的稳定性和测试数据统计的精确度，对性能测试工具的选择决定了后续工作的成功与否和成本消耗的代价。就是这样一个对后续工作至关重要的步骤，却在实际工作中没有得到足够的重视，这个过程很有可能就只是某个性能测试工程师花两三个小时的时间到网上搜索几篇文章，按网上文章推荐的工具来初选，然后根据个人主观的判断就决定了未来所用的性能测试工具。结果，有可能这个性能测试工具在后续的调试稳定测试环境阶段，以及正式测试阶段和统计结果阶段会出现各种各样的奇怪问题，并导致性能测试团队不得不花费数倍的时间来解决这些性能测试工具的问题。
因此，在选择性能测试工具时，建议除了在网上搜索介绍资料外，最好能亲自把所选的几个性能工具进行本地对比测试。在同等环境下，对后续关注的测试数据指标先进行测试观察，然后再将这些性能测试工具的各项性能参数、长期稳定性等关键指标，形成一个表格交由整个测试团队来决策并最终选出未来正式使用的性能测试工具。虽然在进行工具性能对比测试时，会消耗掉测试人员的部分时间和公司人力成本，但是却能避免以后在错误的道路上越走越远，造成无谓的成本消耗越来越大。
测试团队一致选定了性能测试工具后，负责该工具操作的测试人员，需要继续发扬精益求精的工作态度，去全面、深入地了解和掌握该性能测试工具的各类使用方式。笔者曾见过某公司花费重金购买了一个世界顶级的性能测试工具，结果，几年来该公司的性能测试人员只会使用该性能测试工具的少数几个基本功能，其中的大部分功能从未应用过，大大浪费了公司的资产。为什么会出现测试人员对性能测试工具使用不充分的现象呢？原因可能有如下几种可能：由于人的天生惰性，在完成了最基本的性能测试需求后，就不再对性能测试工具的其他功能花时间来了解、操作、学习。当然也可能是由于该工具的学习和使用难度较大，测试工程师在无客观压力的情况下，面对困难退缩了，不愿意继续钻研学习该工具。
所以，我们需要性能测试工程师在性能测试工具上同样能发扬精益求精的精神，在使用性能测试工具时能精益求精地多钻研该工具的其他功能，全面深入地了解该工具的使用特点，最大化地发挥性能测试工具的作用，提高公司资产的利用率。
在调试和稳定性能测试环境阶段，性能测试工程师可以在只完成最基本的环境搭建并让大部分设备和软件正常运转起来后，就直接开始正式的性能测试。但是，只是保证大部分设备和软件能够运转起来对于期望开展高质量的性能测试是远远不够的。只有保证整个性能测试环境能够长期稳定地工作，才能真正确保性能测试的效果和效率；否则会在后续统计测试结果阶段，付出很多时间和成本来分析测试结果中的“垃圾数据”。
一个稳定的性能测试环境是执行性能测试和准确统计性能测试结果的发动机。如果发动机不结实、不稳定，时而无动力，时而动力下降，那么驾驭这个测试环境进行性能测试的人将会非常痛苦。在笔者以前的性能测试经历中，就曾经出现过测试环境中的模拟器时而正常工作产生正常的数据，时而停发数据，时而效率下降，其直接结果就是大大影响了正式性能测试的项目进度，很难得到准确的性能测试效果。
因此，一个追求精益求精的性能测试工程师，应该用尽一切方法，确保性能测试的环境能够非常稳定，仔细地调试性能测试环境中的每个模拟器。如果物理连线环境有问题或设备有缺陷，则一定要事先准备好备用方案，绕开这些问题，来保证性能测试环境的稳定。如果性能测试工程师觉得只是保证性能测试环境的长期稳定还不够体现其精益求精的精神，则可以努力将性能测试环境再改造成一个半自动化测试的环境。一个半自动化测试的性能测试环境将会大大帮助提高性能测试环境的使用和搭建的效率，同时也是性能测试工程师对工作精益求精追求精神的体现。
正式的性能测试阶段，通常是性能测试工程师在所有性能测试工作的各阶段中最轻松也最有空闲时间的阶段。大多数情况下，很多性能测试工程师就觉得该自己休息、喝咖啡、聊天了。请先别忙着完全放松下来，虽然前期的测试准备工作非常辛苦，现在难得有空休息了，是应该短暂休息一下。但是，是否我们还可以更好地利用好这段唯一的休息时间来做一些让我们的工作更精益求精的事呢？例如：为了以后分析、定位问题更快，完成环境参数配置更快，我们是否可以利用这段时间开发一些自动化配置环境参数和自动化分析定位的小工具，每当遇到麻烦时，就可以大大提高解决麻烦的效率，为公司节约时间和人力成本。同时你还可以利用这段时间，多思考是否可以在现有的性能测试方案的基础上，针对性能测试方案再进行改进和优化，创造出更多新的性能测试方案，发现更多隐藏得更深的bug。
另外，你也可以利用这段较空闲的时间优化性能测试报告的内容，让其图文并茂，能更准确、简洁地展现性能测试的结果。因此，如何充分利用好这难得的大块空闲时间，取决于我们是否有着一颗精益求精的心。只要有一颗精益求精的心，在性能测试的执行阶段也能创造出更大的贡献和价值。
在统计性能测试结果和输出性能测试报告阶段，我们依然可以进行精益求精的改进。可以在查看性能测试仪器的统计数据结果时，仔细查看性能测试过程中的每一条log信息，从执行的log中不放过任何稍纵即逝的异常信息，毕竟每一个详细的log信息也是我们性能测试的劳动成果，很有必要充分利用起来。如果你现在还完全用手工和人眼来对大量的log信息进行处理，那么你很有必要通过编写自动化log分析工具来自动查找异常log信息的方式来大大减少工作量，提高log分析工作效率，而这也是体现精益求精的方式。
在性能测试报告中，你可以不只是简单地罗列本次测试的几个数据就算完成了任务，还可以加上丰富、详细的历次测试数据的趋势对照，并且图文并茂，以及除测试参数数据外的其他相关数据的变化。相信这样的性能测试报告应该会更让所有人满意，一位能做出这么完整的性能测试报告的性能测试工程师一定会因其精益求精的工作态度得到同事和领导更多的尊重和肯定。
五、回归测试的精益求精
前面两节谈了有关测试用例设计和性能测试中精益求精的方法，相信大家还是有所收获的。那么接下来我们应该如何进行回归测试的精益求精呢？笔者曾经做过手工回归测试，也做过自动化回归测试，从笔者自己的经验和身边看到的实例证明，在从事看似枯燥的回归测试工作时，我们同样可以调整自己，在回归测试工作中追求精益求精。
在手工回归测试时，我们除了需要按照测试用例的要求，保证每一步都是正常完成测试外，自己还可以利用空闲的时间和资源，尝试小范围地改变测试用例中的参数和方法，来进行一定的探索性测试。这样的行为有时能帮助我们得到意外的惊喜，发现新bug。毕竟创新是无止境的，没有哪个测试用例是完美的，按照测试用例执行回归测试可以保证90%的测试目标，但是靠自己想出的新点子找到的问题，却可以帮助测试团队和公司向最后10%的质量目标又前进一步。笔者相信，任何测试经理对于你在完成了本职工作后，还能发现新问题，都会感到非常高兴。能超出预期的员工肯定是一个追求卓越、追求精益求精的员工。
自动化回归测试阶段，与性能测试执行阶段类似，你将会有大量的空闲时间。在这段空闲时间中，最容易想到追求精益求精的方面是，自己编写一些自动化测试脚本结果的分析工具。当出现自动化测试脚本运行失败时，可以大大缩短分析、定位的时间，提高工作效率。同时，你还可以思考是否可以通过改变和优化脚本执行的顺序来大大降低自动化脚本运行失败的概率，从而达到缩短自动化测试脚本运行时间，提高运行效率的效果。
六、测试脚本开发的精益求精
精益求精的态度在测试脚本的开发中比较容易得到体现。例如：测试脚本优化；测试脚本的信息提示；测试脚本与测试工具的融合；测试脚本文档4个领域，都有着足够的空间让我们去发挥，去追求精益求精。
1．测试脚本优化领域
我们可以不断优化测试脚本，使其能够适应在不同的测试环境中运行。也可以通过优化脚本的测试代码，使其能够有很强的容错性，在有一定干扰或异常的情况下依然成功运行下去，不对测试环境的“纯净性”要求过高。通过使测试脚本的代码松耦合，当被测设备的命令风格发生变化时，只需要对测试脚本做尽可能少的修改，就能适应新的命令风格。
2．测试脚本的信息提示领域
当测试脚本在运行失败时，能打印出更多的错误信息和更详细的调试分析信息。在脚本运行失败后，通过报错信息直接告诉测试人员是脚本语法错误，还是测试环境错误，或者是某个正常的逻辑处理错误。这些提示信息可以让自动化回归测试执行的工程师高效地分析、定位出脚本失败的原因，越是详细的调试分析信息，越能帮助测试工程师提高工作效率。
3．测试脚本与测试工具的融合领域
一般情况下我们在进行手工测试时，常常需要借助一些第三方辅助小工具来完成测试。对于这种情况下的自动化测试脚本开发而言，要在测试脚本中完全模拟像手工测试一样的测试效果，脚本开发的难度是比较大的。不过，我们可以从如下几方面入手来实现目标。
（1）多了解一些开源的小工具来代替目前辅助测试的小工具。通过开源的小工具，可以更容易地开发出适合自己调用的API，便于集成到自己的测试脚本中。
（2）在脚本与工具的接口代码处，优化脚本代码使其松耦合，当以后需要更换测试工具时，依然能很容易地驱动新的测试工具。
（3）测试脚本能够对测试工具发生的异常和错误提供足够详细的log信息，便于以后因测试工具的错误而引起脚本运行失败时，可以快速地进行定位，节省分析、定位的时间和成本。
4．测试脚本文档领域
文档的编写也许是大多数工程师都不愿意从事的工作，但是它却对公司非常重要，公司要实现铁打的营盘、流水的兵，就必须有非常详细、规范的各类文档。虽然，我们可以在测试脚本中通过注释的方式来解释各个测试步骤的脚本代码，但毕竟注释方式所覆盖的信息量太少。我们最好是针对每个测试脚本有一个独立的测试脚本开发文档，告诉后来者这个脚本要干什么；各个测试步骤是怎么实现的；关键参数是什么；用了哪些变量，每个变量的含义；与其他测试脚本的层次关系如何等。
七、测试工具开发的精益求精
在测试工具开发过程中，对于工具的开发者不光要实现工具的功能要求，也要像对待一个商业产品一样，对代码规范及工具的功能稳定性、易用性和相关文档做到精益求精。
一个测试工具的开发并不是一次性的。因此，我们需要像对产品开发要求一样，尽量有一个规范的代码结构，以便于后来者进行二次开发和维护。虽然我们很少会利用自己开发的测试工具进行精确的性能指标统计测试，但是我们却常常利用测试工具进行流量的模拟。为了保证测试环境流量大小的稳定性，我们也需要对自己开发的测试工具进行测试，优化测试工具的性能，使测试工具能够在实际应用中尽量状态稳定地工作。因此，我们可以在测试工具开发这一环节进行尽可能精益求精的发挥。往往一个测试工具的稳定性效果就是优秀测试工具开发者追求精益求精、追求卓越的结果，也是与其他普通测试工具开发工程师的最大区别。
在测试工具的易用性方面，通常由于测试工具开发项目时间紧，使得测试工具的使用方式在风格上可能过于偏“开发化”，也就是说，开发者自己可以很容易理解和使用测试工具，而测试工具的用户——测试工程师却比较难全面搞懂所开发的测试工具的使用方式。因此，建议测试工具的开发工程师应在稳定了测试工具后，再从测试工具易用性的角度，来不断完善、改进开发的工具。
在测试工具的相关文档方面，如果开发者自己不希望未来每一个工具的使用者都亲自来向他请教工具如何使用，或是未来进行二次开发时，自己都回忆不起来所有的代码细节，那么测试工具的开发者还是最好能在工具的开发过程中，编写一份详细的开发文档，以及在完成测试工具的开发后，开发一个详细的使用手册。这样不但方便了未来的测试工具用户，也大大减轻了测试工具的开发者未来维护和支持的工作量。
八、测试的知己知彼
众所周知，“知己知彼”的思想在军事中和商业活动中已得到了广泛应用，但却很少有人会想到“知己知彼”在软件测试的工作中也同样可以得到广泛应用。在军事中无论是解放战争，还是抗日战争，共产党所领导的人民军队总能在装备落后的情况下胜多败少，其中情报工作做得比对手好，是一个非常重要的因素。
在测试活动中，当我们还在争论是否应该让黑盒测试人员了解和学习产品的设计原理、实现机制和实现方式时，我们是否考虑过是今天产品的质量重要还是未来的安全保密重要。如果没有今天的高质量，公司的产品就会没有销路，公司今天的生存都会有问题，何谈未来的发展，安全保密就更无从谈起了。
测试活动本身的找bug工作就可以理解为找目标的弱点。对于测试而言，有两个领域需要测试人员去知彼：
l 第一个领域：测试目标的设计原理、实现方式。
l 第二个领域：测试目标的实际应用环境。
当然不是所有的测试人员都要求对这两个方面去全面知彼，如同只有军事策略和军事计划的制定者才需要全面了解整个战局的情报，而非所有级别的军官和士兵都需要知道全部情报一样。在我们的测试组织中，只需要制定测试策略、测试计划的测试技术骨干能够对这两个方面的情况进行全面地了解即可。技术骨干对这两个领域了解得越准确、越全面，越利于我们设计出成功的测试策略和测试计划，并有利于提高后续测试方案开发的质量和测试执行生产力效率，从而让产品的质量更上一层楼，提高产品销量和品牌价值。
在了解这两个领域相关重要信息的过程中，有如下方法可帮助测试人员用最少的时间和成本达到尽量了解情报的效果。
1．了解测试目标的设计原理和实现方式
可以让系统设计人员和开发人员定期给测试设计人员进行培训和讲解。在他们的帮助下，测试设计人员可以少走不少弯路，集中精力、尽早、全面、准确地了解测试目标的内部情况。
案例：某即时通信软件服务器和客户端通信测试
首先，通过与开发人员交流、沟通了解到，服务器端是在UNIX平台上用C语言来实现的，而C语言在UNIX上较难调试，因此服务器端的软件在程序员的内测中会做得不够充分，服务器端软件出现bug的概率要高，所以在服务器端的软件模块要投入大部分的测试资源。同时了解到客户端软件的实现工具是用Delphi实现的，考虑到Pascal语言与C语言在字符串处理上的区别，因此针对客户端软件需要多在字符串转换上进行测试。
其次，通过阅读软件设计文档，了解到客户端与服务器之间自定义的通信协议中各数据结构元素大小，针对这些数据结构元素的大小可以进行溢出测试。假设所定义的传送数据块的字符数组大小为char Data[500]，那么在传送数据块时，就一定要测试数据块大小为500个字符和501个字符大小的情况。同时，通过了解服务器端的并发处理方式，是异步方式还是同步方式，是多线程还是多进程来处理多个用户的并发连接，就可以针对本产品实现的同步处理方式来制定不同的有针对性的测试策略。
最后，了解到后台存储数据的数据库是哪种数据库后，可通过上网去了解该种数据库已发现的缺陷和性能短板在哪里，然后针对数据库的这些问题结合所测试的项目特点进行测试，保证服务器端实现的软件代码能够很好地屏蔽数据库的短板。
九、了解测试目标的实际应用环境领域
可以先让技术支持小组和解决方案组提供所有已知的设备应用方案和设备配置参数。然后，测试设计人员可以在公司资源的支持下利用各种到用户现场与用户交流的机会，从测试和质量的角度听听用户对现在已有的产品问题和未来产品应用时的质量要求。最后，综合公司的已有资源和测试人员自己的第一手资料，来得到测试目标在实际应用环境中的质量要求，以及测试方向的重心。
案例：一个以太交换机产品的测试
某以太交换机厂商的产品，在市场应用中常出现各种工作不正常的情况，有些是客户使用环境的问题，有些则是产品对实际环境的适应能力不强的问题。因此，该公司测试部门先依托公司市场部的资源，将市场部已知的各种交换机产品应用的组网方式收集起来，统一进行逐一测试验证。同时，在外派测试调研小组前，先在研发部内部收集产品各功能开发小组对产品质量的调研需求。然后才到不同类型的用户现场与用户一起讨论交流，了解用户在使用以太交换机的过程中，常遇到哪些问题和故障现象影响了正常的工作；并询问用户对于产品的质量提升，最关注哪些方面，有哪些好的建议。
待测试需求调研小组回来后，首先按照产品的不同应用场合进行分类。然后按照用户最关注的质量点的优先次序排序。最后，把产品最常出现问题的地方和场景数据进行统一管理，以确保在测试设计时尽可能地接近产品出现问题的场景。结果，在此次外出调研后得知，以太交换机很多时候出现工作不正常的原因，就是由于真实网络环境中的数据混有大量的病毒，而这些病毒也能直接攻击公司交换机本身的资源，导致交换机无法正常运转调度各种功能。同时，用户也反馈IPv6之类的功能基本不用，建议减少测试投入力量；IP路由也主要使用静态路由，建议强化静态路由的测试。用户用得最多的功能就是访问控制列表，且使用到了该功能的很多小功能点，而这些功能点恰好是测试人员所不重视的简单功能。
通过测试调研，该公司以太交换机测试小组明白了下一步测试工作中的重点，以真正用户的思维角度来重新排序了测试功能的优先顺序，不再是以测试人员的纯技术角度按功能的实现复杂度来划分测试优先级。从此，对于一些实现简单，但用户爱用的小功能提高了重视；相应地，对于一些用户基本不用或只是使用极少基本功能的大模块，减少了测试资源投入。使得整个以太交换机产品的测试策略既没有忽视用户的真实困难，又将测试资源最科学地使用起来，大大提高了测试效率和测试质量。
前面谈了不少关于“知彼”的内容，相信读者也开始意识到“知彼”对于测试的重要性了。那么现在我们就来谈谈何为测试的“知己”。为什么本节直到现在才开始谈论“知己”的重要性，因为人最难的就是知己，毕竟人各有千秋，各有特长，各有所爱。例如：有的人擅长想和研究，有的人擅长做和实施，有的人擅长沟通，有的人就喜欢埋在代码堆中。在常见的测试团队中，通常有如下4种常见的人员特点。
A类人：擅长做和实施，不擅长想和研究
这类人可能敲键盘时速度飞快，进行设备配置和环境搭建时也速度飞快，分析定位问题时效率也挺不错的。但有可能缺乏足够的创造力和发散思维的特点，构思测试方法时可能就不如B类人。
B类人：擅长想和研究，不擅长做和实施
这类人虽然可能不如A类敲键盘快，设备配置和环境搭建时也没A类人快，甚至有可能看起来好像没A类人勤奋尽力，但却常常能在A类人找不到bug后，B类人可以通过新创造出的很多测试方法来找到更多的bug。
C类人：喜欢写代码，不喜欢找bug
这类人对代码是狂热的爱好者，只要让他写代码就兴奋不已，而对测试本身基本上就无兴趣和积极性。我们可以让他专注于自动化测试脚本的开发和测试工具的开发，让他在自己的爱好中工作。
D类人：擅长沟通和协调
这类人大家都知道啦，比较适合作为测试项目的PM与各部门进行协调，争夺测试资源和测试的权益，或是团队的管理。还有就是从测试的角度思考与产品用户进行沟通，深度挖掘出测试需要的市场信息。
以上4类人是大家比较常见的测试人员类型。现实中有许多测试人员同时兼具两种类型特点，甚至集多种特点于一身。当我们理清了测试人员的分类后，大家对“知己”也应该有了比较清晰的认识。再好的计划，也需要配上强有力的执行才能让计划得到完美实现。作为测试的管理者为了达到测试设计策略的科学与高效，最好的策略是：先选择具有D类特长的人去收集用户测试需求，接着选择B类人来进行高质量的测试设计。当好的策划和设计产生后，再让A类人和C类人来快速、高效地实施设计好的测试策略和测试方案。只有按照“知己知彼”的思路，才能得到一个高效率、高产值的测试团队，测试人员也才能在测试团队中找到快乐和激情。
十、测试中的金矿
本节的核心思想是把握住“势”，把时机抓在手中，把握住稍纵即逝的机会，取得更大的胜利。测试中有一个现象：不少埋藏较深的bug，正是在偶然地发现了一个异常时，把握住了一个也许是稍纵即逝的机会，深入地挖掘，才能发现。
在寻找bug的过程中，我们通常都会经历这样一个规律曲线：刚开始进行功能测试时，bug数开始逐渐上升，这是第一阶段。这个阶段的bug种类比较多，从P1到P5都有散布，属于遍地开花的局面，感觉不用花太多精力就可以很轻松地找到bug。
第一阶段结束和第二阶段开始的标志是bug数开始慢慢减少了，bug不再很容易就能找到。这时就需要测试人员不只进行功能测试，而要把系统测试、性能测试、负面测试的武器一起抬出来投入战斗。同时测试人员也需要再多开动脑筋，构造新的前期测试用例未包含的测试方法，依赖在第一阶段中对产品功能和内部原理的熟悉，测试人员可以在这一阶段更好地补充测试用例的方法和策略。
通过新的测试手段和测试武器在第二阶段的使用，结合测试人员更多的思考，在第二阶段常常可以找到一些埋藏较深的bug。因此，第二阶段的测试工作就很类似于挖金矿的工作，先通过一定的侦察和自己专业的知识经验，找出最容易出现金矿的地方，然后用工具开始坚持往下进行尝试。如果这时发现了一块金子，笔者相信任何掘金人肯定都会更兴奋地坚持往下挖。可是我们在测试时，很多情况刚好相反，当我们在经过一段时间的努力，发现了一个P1或P2问题时，人很容易就松懈下来。虽然很高兴通过努力又发现了新bug，却没有在出现bug的地方再加把劲，再努力地去试图挖出更多的金矿。
我曾听一位有15年以上经验的测试老兵谈过，大部分严重的bug都集中在少数地方。原因很可能是在软件开发过程中，这里是属于开发复杂度较大的地方，或者某类异常情况处理没有想到，又或者负责该模块的开发工程师经验不够。因此，当我们在这些地方发现了一个bug后，很容易采用同样的测试策略发现更多类似的bug。所以，我们需要像挖金矿一样，只要找到一个bug，就更需要继续沿着相同的方向深入下去，以期挖到更多的“金子”。
案例：电信网络设备的测试
因为很多电信网络设备的基本功能主要是数据转发，所以对该类产品进行性能转发功能的测试是非常重要的。通常业内会第一步对该产品进行性能指标的测试，判断是否可以达到产品规格说明书所要求达到的参数。然后，测试工程师会对产品进行长时间的压力测试，这个阶段基本上都会发现比较严重的bug。同样的测试环境和测试条件，连续跑2天流量和连续跑4天流量会出现不一样的bug。
有些测试人员容易犯这样一个简单的逻辑错误：认为同一个连续跑2天流量的测试方案，跑2次或3次的效果是一样的。可是测试经验却告诉我们，事实上同一个性能压力测试用例跑2次、3次有可能发现的bug是不一样的。假设该性能转发模块潜伏了A、B、C、D、E 5个bug，很巧合的是，当A bug发生了，设备就不会再运转了，因此B、C、D、E 4个bug就不会被发现。如果这时我们就停止了同一个方案的测试，就会把B、C、D、E 4个bug遗漏。所以即使是跑同一个测试方案，每次运行时都有可能出现不同的bug。
举例
寻找以太交换机的自身安全性bug。
在大多数情况下，很多厂商对以太交换机产品很少会进行网络安全测试。因为以太交换机产品的定义中并不包括网络安全测试，主要针对以太交换机的二层功能和三层功能进行测试。即使少数厂家的以太交换机加入了部分网络安全模块，会针对通过交换机交换的数据进行安全性检测，但还是对以太交换机本身的安全性很少进行测试验证。由于以太交换机的广泛应用，大家会发现以太交换机工作失灵的原因不是我们在测试功能时有遗漏，而是大家从未考虑到以太交换机本身会受到网络病毒的攻击。
有一次在处理市场问题时，我们发现如果持续对以太交换机的网管接口发出半连接的TCP连接，将会最终消耗完所有的TCP连接内存，导致设备最后重启。正是通过来自市场的实际应用问题，启发了我们对以太交换机的网管软件模块重点进行网络安全测试的想法。于是将常见的网络安全攻击测试，如UDP、TCP、SNMP的资源消耗的攻击，以及协议完整性的Fuzzing测试应用到了网络软件模块的测试工作中。
在对以太交换机的网管模块深入进行这些安全测试后，我们的确又发现了10个以上P1级别的严重bug。虽然我们先偶尔挖到一块“金子”，但却在发现bug的地方不但没有结束测试，反而进行了更大范围的深度挖掘，以至于最终在这块被大家疏忽的地方发现了更多严重的bug。
综上所述，在实战测试工作中需要在发现过bug的地方比未发现bug的地方花更多的精力，来研究出现bug的地方和触发原因，把握住这个已找到bug端倪的“势”。要抓住产品的弱点不放，争取把握住时机，实现一点突破带动全面突破，将发现bug的成就由小变大，取得最大的成绩。
十一、自动化测试实施策略
我们在制定自动化测试实施策略时，首先应该考虑其中可能存在的风险。
1．自动化测试时间不充足
有时根据项目计划的安排，测试人员往往被安排利用自己的个人时间或者项目后期介入自动化测试，使得没有充分的时间进行自动化测试，无法得到真正的关注。
2．对自动化测试期望过高
有很多好的理由去开展自动化测试工作，诸如自动化测试可以节省时间，使测试更加简单，提高测试的覆盖率，可以让测试人员保持更好的测试主动性。但是人们却经常过高地期望自动化测试实施后马上就能产生的效果目标。不同的公司及其投入自动化测试的资源状况，需要对自动化测试寄于不同的符合自身状况的目标，否则面对的很可能是失望。
3．缺乏自动化测试实施的经验
因为没有经验，结果初期计划投入的资源太少，导致自动化测试迟迟未能正常启动，无法按计划达到期望的目标。
4．自动化测试工具更新过于频繁
学习不同自动化测试工具的特性和脚本风格往往需要花费很多时间。当自动化测试工具更新换代频繁时，你就丧失了一部分刚刚学习到的自动化测试经验。
5．自动化测试工具对软件测试本身没有起到帮助作用
在很多软件项目中发生了这样的情况：自动化测试工程师认为实现产品的自动化测试比测试本身更有趣，他们不参与到软件测试的具体活动中。由于测试的自动化与测试的人为割裂，导致很多自动化测试工具对软件测试并没有太大的帮助。
当我们有了针对自动化测试实施风险的准备后，就可以开始考虑：需要在什么阶段开始启动自动化测试？自动化测试的人力投入方式如何？如何执行测试脚本才更高效？
首先，在何时启动自动化测试，每个公司的情况都不同。有的公司是在测试用例都手工执行过并且测试用例不再修改时，再开发相应的自动化测试脚本；而有的公司则是在开发测试用例的同时，就进行脚本的开发。如果团队中测试用例的设计者是一个有着丰富测试用例设计经验的工程师，他所开发的测试用例是高效的，未来改动较少，则可以考虑在开发测试用例的同时，同步开发自动化测试脚本。如果团队中测试用例的设计者是一个测试用例设计经验不丰富或是设计的测试用例质量不高效的人，其开发的测试用例需要在后期经常进行许多的改动，则还是考虑等到测试用例本身稳定后，再开始脚本开发。
其次，自动化测试人力投入方式的选择也是有讲究的。据笔者了解，大部分公司是由专人进行自动化测试脚本开发的，少部分大公司则是全民开发自动化测试脚本。这两种方式都各有利弊：专人进行脚本开发，优点是开发脚本的专业技能可以不断地得到强化，开发效率大大提高；缺点是由于对开发模块的测试用例了解并不深入，有可能开发出的自动化测试脚本只是“翻译”测试用例，发现bug的概率较小。而有的大公司，由于员工的整体素质较高，通常都具备一定的开发能力，则由每个模块的手工测试者自行开发自动化测试脚本。虽然，手工测试者脚本开发的熟练程度没有专门的脚本开发者熟练，但是由于手工测试者是最了解测试用例真谛的人，因此他开发出的测试脚本就不仅仅是“翻译”，而可能是对测试用例的“升华”，其测试脚本发现bug的概率会更大。
最后，如何执行测试脚本才更高效呢？
（1）N个测试环境同步并行执行测试脚本，可以将自动化测试脚本执行的总时间成本降低为1/N。
（2）由专门的自动化测试执行工程师来执行批量的自动化测试脚本。自动化测试脚本运行失败的前3大因素大致为：
● 测试环境问题；
● 脚本错误；
● 被测目标出现bug。
由于专门的自动化测试执行工程师对大量失败的脚本分析经验的积累，通常可以非常高效地定位脚本失败的原因，提高自动化测试脚本执行的效率。
（3）独立的自动化测试环境供脚本执行团队使用。如前所述，测试环境问题是测试脚本失败的原因。而测试环境影响测试脚本执行的两大杀手：一个是测试环境被前一个失败脚本破坏而未还原；另一个则是测试环境被其他项目的同事给破坏了。对于第一种情况，我们可以在测试脚本的代码结构中加入足够的系统恢复代码来解决；对于第二种情况，则只有依赖于公司领导的政策支持，是否愿意腾出足够的测试环境给自动化测试执行小组专用。
（4）在测试脚本中加入丰富的脚本失败的定位信息。自动化测试脚本一旦失败，我们就只有依靠脚本自身打印的信息进行定位了，定位问题的速度快慢除了依赖脚本执行人员自身的经验外，更依赖脚本中是否有着丰富的脚本打印信息。
（5）使用自动化测试基线软件版本。当出现大批量测试脚本失败的情况时，可以在排除了测试环境问题后，直接把这些失败的测试脚本在基线软件版本中运行。如果在基线版本中运行全通过了，则证明脚本失败原因是产品新bug引起的，而不用逐个地去阅读这些失败测试脚本的源代码来分析脚本自身原因。
当决定了自动化测试的开始时间、资源投入模式和执行方式后，就可以对自动化测试的目标进行梳理了。针对测试目标的不同，来选择是否进行自动化测试：
l 基本功能回归测试
如果准备在每个版本都运行同样的测试用例，则这个环节值得你在自动化测试上进行资源投入。
l 配置测试
如果希望软件支持多种不同的平台，并支持在所有平台上进行测试，也建议采用自动化测试。
l 测试环境建立
对于大量不同的测试用例，可能需要相同的测试环境搭建过程，可以用自动化测试来实现测试环境的搭建。
l 非GUI测试
实现命令行和API的测试自动化比实现GUI自动化测试容易得多。
案例
我们用以太交换机产品的自动化测试实施策略作为案例，来讲解如何进行自动化测试实施策略的制定。
1．自动化测试人力资源模式
鉴于我们已有的人力状况，决定实行1＋n方式。首先选出一名测试工程师作为自动化测试的总技术负责人，他将不再参与任何手工测试的工作任务，主要职责是开发一个标准的自动化测试脚本模板，以及自动化测试平台和测试脚本库函数的开发及维护，同时还担任所有自动化测试的技术支持工作。其他所有功能测试人员在经过简单培训后，由各自独立开发调试所测试模块的自动化测试脚本。
2．自动化测试工具选择标准
（1）首先寻找一个基于Linux的开源自动化测试平台，便于利用众多基于Linux开源的自动化测试工具的集成和后续维护。如果没有找到开源的自动化测试平台，可考虑申请投入1～2人用3个月时间开发一个简易可用的自动化测试平台，日后再不断完善和改进。
（2）优先直接利用Linux开源测试工具。
（3）任何自动化测试工具的选型，必须经过整个测试部门所有技术骨干的集体决策。
3．自动化测试脚本的开发语言
由于我们的产品主要是以基于命令行的操作为主，为了提高自动化测试效率，将采用Tcl语言作为脚本开发语言。
4．自动化测试脚本开发启动时间和工程师投入时间
由于我们公司进行测试用例设计的手工测试工程师都是具有1年以上实战测试经验的熟手，因此设计的测试用例质量较高，可以在完成测试用例评审，以及两轮手工测试后，安排40%的时间给手工测试工程师开始编写自己所需要的自动化测试脚本。
5．自动化测试脚本的执行方式
（1）由专人执行，即自动化测试脚本的总体负责人来执行。因为他不但可以利用脚本执行时间并行从事一些测试脚本优化的工作，同时也可以通过在执行过程中发现的脚本问题，来不断优化他所开发和维护的自动化测试脚本框架模板，以及总结出不同人在测试脚本编写过程中易犯的错误，形成一个所有自动化测试脚本错误经验的洼地，高效地把各类脚本编写错误统一起来，并定期为全体测试工程师进行脚本开发错误经验培训。
（2）采用并行方式执行测试脚本。鉴于我们已有的测试设备资源状况只能搭建3个并行的测试环境，因此，需要由自动化测试脚本的总体技术负责人进行合理的测试资源分配。
（3）自动化测试脚本的分组规则及执行优先顺序。由每个测试项目的测试项目经理与自动化测试技术总负责人共同制定执行优先顺序。
6．自动化测试应用的预期目标
（1）应用于所有的回归测试。
（2）功能测试部分：争取第一年达到30%的自动化率，第二年达到60%的自动化率。
（3）性能测试部分：争取第一年达到40%的自动化率，第二年达到70%的自动化率。
（4）系统测试部分：争取第一年达到10%的自动化率，第二年达到30%的自动化率。
7．自动化测试对测试用例的影响
（1）所有新开发的测试用例，在开发和评审过程中都必须考虑测试方法的可自动化。
（2）在正式开发自动化测试脚本前，由各手工测试工程师自行选出已有测试用例中急需转为自动化测试的部分，和可以容易转为自动化测试的部分。对于急需转为自动化测试，而又不易技术实现自动化的部分，可以集体开会讨论如何修改和优化测试用例，以保证实现自动化测试。
（3）在项目间歇期，让每名手工测试工程师必须选出一定数量的测试用例进行优化，通过改进使尽可能多的测试用例可转成自动化。该目标由各测试组长进行监督和跟踪。
经验提示
“罗马城不是一天建成的。”自动化测试的实施也需要一个积累经验、循序渐进的过程，不要期望在短期内实现所有测试的自动化。成功的自动化测试需要制定相应的自动化测试计划，在没有进行计划的条件下，实施测试自动化只会带来混乱。最开始我们可以从整个测试计划的一小部分开始实施自动化测试，然后再依据资源情况逐步添加自动化测试集合。同时自动化测试脚本开发的策略应该包括：可以在不同测试中应用的测试函数库和采用将代码与数据分离的方式进行脚本框架的开发。例如，最新的第三代自动化测试技术就是把测试数据写入到简单表格中，用一个解析器来解释表格中的数据，并执行测试。这种方法被称为表驱动或数据驱动（data-driven），该测试脚本架构最大的好处是，它允许把测试内容写在具有一定格式的表格中，这样方便数据设计和数据检视。
好的自动化测试策略是自动化测试实施是否成功的第一步。只有充分考虑到自身实施自动化测试的风险、资源和目标后，才能制定出适合自己的自动化测试策略，并最终对后面的自动化测试实施过程产生帮助。
十二、Troubleshooting
什么是Troubleshooting？Trouble的含义是困难，Shooting的含义是瞄准、射击。直译：困难瞄准。专业说法是分析定位问题。
对于从事IT技术的各种工种，都需要有足够的分析定位问题的能力，测试人员、开发人员和技术支持人员都需要。Troubleshooting是一种能力，它对IT技术人员的意义，类似于艺术家的创作灵感，销售人员对客户需求的理解能力。分析定位问题能力是每一个IT技术人员必备的能力，尤其对软件测试人员要求会更高。
为什么对软件测试人员要求会更高呢？
当软件测试人员发现了一个bug后，首先就应该确认是否可以重现该bug，而重现bug的前提就需要测试人员能分析自己的测试步骤是如何触发bug的，并定位到重现bug的最小操作集。
其次，软件测试人员会经常进行各种测试环境的搭建，并使用很多测试工具来辅助搭建测试环境。而在搭建测试环境时，常常会遇到各种各样的环境故障，排除这些环境故障就必须依赖测试人员的分析定位能力。
最后，软件测试人员要得到开发人员的尊重和信任，就必须能与开发人员一起分析定位各种bug，在讨论分析过程中，测试人员不但展现了自己的能力，而且还担任着一个系统级bug的定位总负责人的责任。例如：在压力测试过程中，某测试人员发现了一个协议状态异常的bug，因此他请来了协议开发人员，进行共同定位发现协议异常引发原因来源于驱动。于是测试人员又请来了驱动开发人员，与驱动开发人员一起讨论分析定位后，发现问题来自硬件。接着测试人员又请来硬件开发人员，并将前期所进行的所有分析定位过程和分析定位的结果向硬件开发人员描述，最后帮助硬件开发人员定位到了具体的硬件问题。
所以，对于软件测试人员而言，掌握和具备较强的分析定位问题的能力，无论对于解决测试环境搭建的问题，找到重现bug的方法，还是协助各类开发人员定位到bug产生的原因都是非常重要的必备能力。
那么对于一些不易重现的问题应该如何进行问题的分析定位呢？下面笔者和大家分享一点个人的经验。
（1）首先确保被测试目标的软件版本是发现问题时的版本——版本不一致就没有分析定位问题的前提了。
（2）如果被测试设备是硬件设备，要确保重现问题时是同一台硬件设备、同一张硬件板卡——因为有可能问题就是由某种硬件板卡的个性故障引起的。
（3）搭建测试环境的辅助软件和辅助设备要与发现问题时是同一台设备及同一软件版本——因为问题有可能是由于辅助软件和辅助设备的故障所引起的，或者由于辅助软件和辅助设备的某个异常才触发了被测试设备的问题。
（4）所有测试环境的硬件条件都确保一致后，就需要确保测试目标的功能配置及参数与发现问题时的数据是一致的，特别是输入值应该与出现问题时一样。
（5）完成前面4步准备工作后，至少要让一名开发人员陪同你一起开始重现问题，因为他会从实现内部原理的角度给你提供很多提高重现工作效率的意见和建议。同时，他还可以通过在测试过程中不断查看各种重要的系统数据来找到一些可帮助快速突破的蛛丝马迹。
（6）如果在第（5）步中没有找到可以定位问题的原因，就需要再回忆第一次遇到问题时的所有场景，查看自己有无遗漏信息，并继续坚持去尝试重现。因为确实有些问题是小概率发生的，是多种瞬间状态临界值的交集。即使定位到了触发条件和原因，在操作上也很难每次都掌握到那个临界状态。只有不断尝试和坚持才能把问题重现出来，帮助开发人员修改该问题。
案例：一个ATM性能bug定位的故事
当时我们搭建了一个由数十台辅助测试的发包路由器和两台专业性能测试仪器Smartbits构造压力流量的测试环境，确保设备ATM卡所能支持的所有通道数和最大带宽都达到了上限。在压力测试早期，48小时过去了，ATM卡依然正常地工作着，没有任何异常。但在第3天，我们忽然发现ATM卡重启了，ATM卡的协议开发人员和驱动人员都立刻来到了现场进行信息收集，在忙碌了三四个小时的信息收集和分析后，大家都没有在现场找到问题的原因。于是开发人员又回去分析讨论定位重现方案，最后他们在代码中新添加了一些辅助定位的打印信息，希望能在问题再现时，打印出更详细的信息以供定位。
于是我们开始了第一次的问题重现，压力测试继续跑起来，可是让人失望的是居然在72小时内都没有重现该问题。不过，我们没有把压力测试停下来，而是继续下去。在第5天，问题终于重现了，这次来现场收集信息的人更多了，当然问题发生时各模块统计打印的信息也更多、更全。后来经过开发人员2天的会诊，最后定位到了原来是驱动层的数据转发的发送指针跑到接收指针的前面去了，发送指针的调度速度比接收指针的调度速度快了。
之后我们开始了对该问题解决结果的验证，可奇怪的事又发生了，在测试的第2天设备又重启了。很多开发人员又跑来定位，大家都觉得不可思议。难道分析判断错了吗？大家带着极大的疑问，仔细地看完了所有的打印数据，发现这次的出错数据与上次的问题又不一样了。难道又有新问题发生了？开发人员又在代码中加入了更多的打印信息。
第三次问题重现又开始了，这次还好在测试的第3天重现了第二个问题。开发人员看了自己第二次加入的打印信息后，感到非常迷茫，“不可能，不可能啊”是挂在他们口中的惊讶。原来他们从打印的信息中发现居然转发芯片不工作了，导致上层驱动的指针又飞了，才导致设备重启的。可转发芯片怎么不工作了呢？没办法，开发人员只好把所有现场收集到的数据拿回去分析研究。几天后，他们得出了一个自己都觉得很奇怪的结论：芯片在停止工作前，收到了错误的ATM协议报文。可是错误的ATM协议报文是从哪里来的呢？由报文的源地址来源判断，居然是我们的测试用路由器产生的。原来，由于中低端路由器本身CPU频率不高，在长时间进行数据包构造后，在某一时刻把一个没有构造完全的残缺数据包发送出来了，导致ATM卡收到了一个自己从未预料到的报文结构，ATM芯片无法处理而停止转动。后经由芯片厂商确认，证实了确实是芯片的问题。我方的开发人员只好通过软件来补救芯片解决该问题。
第四次问题重现开始了，这次的重现既要验证发送指针跑到接收指针前面去的问题，又要同时验证补救芯片代码的实现。幸运的是，这次压力测试在经历了连续10天的测试后，ATM卡依然安然无恙。虽然中间观察到了几次瞬间复位的状态，但毕竟没有出现整个ATM卡重启或瘫痪的情况。现在看来前期发现的两个问题都应该被解决了。
这个案例是笔者测试职业生涯早期印象特别深刻的，印象深刻的原因就在于问题出现现象的诡异性，问题出现的场景及触发条件让人很难事先预料到。这场战斗持续了近1个月的时间，让开发人员多个夜晚加班分析，那段时间在笔者的办公桌边总是有几个人陪着一起盯着屏幕上不断打印出的各种信息，心里期盼着早点看到自己想看到的信息，可是偏偏信息就是不出现，而且出现的还不是自己想看到的信息，却是一个新麻烦的开始。在这个案例中的两个bug，都不是那种只要找到逻辑就能马上复现的bug。而是那种需要在某种临界瞬时状态下才会出现的问题，也就是大家最爱说的不易重现的问题。也正是这场bug定位战斗，让笔者坚信了一个真理：“没有重现不了的bug”。所以，以后只要有新员工对笔者说“这个bug不能重现”，笔者就会马上纠正他，应该是“这个bug不易重现，世上没有不能重现的bug”。
在以后的测试工作中，渐渐的在一次次找到“不易重现的bug”的必现原因和最小必现操作步骤后，笔者发现自己越来越自信了，越来越坚信自己的结论“没有重现不了的bug”，并且喜欢上了分析定位bug的过程，以及成功后给自己带来的成功感和业务水平上的提高。而且有时参与一个难重现和分析bug的过程，可以让测试人员把整个产品的内部实现流程和主模块实现原理全部都深入地学习一遍，其理解和感受之深刻，是看任何静态资料都无法达到的效果。如果要说在测试工作中，笔者最愿意让领导分配的工作是什么？那就是非常高兴地听到领导说：“董杰，那边又出现了一个难分析定位的bug，帮他们重现和定位一下吧。”一场战斗又打响了！
最后总结Troubleshooting的核心是：
● 头脑要清晰，思维要收敛，而非发散。
● 与开发人员保持良好、准确的沟通。
● 细心、耐心。
● 不轻言放弃，即使开发人员也快失去了信心，你也不要放弃。
● 自信，有些低水平的开发人员分析定位问题的能力比测试人员要弱。
十三、职业选择的象限
按照《穷爸爸，富爸爸》书中的说法：职业选择通常有4个象限，即雇员、自由职业者，做生意/创业者和投资者。作为软件测试行业的从业者，很显然大多数都属于雇员这一象限，可能不到1%的测试人能做到自己创业，开创一些第三方测试机构，或者一些测试外包公司、测试工具销售公司、测试咨询服务公司。
也许是经历的缘故，笔者个人不太赞同通过测试来创业或成为自由职业者。因为通过笔者的工作经验体会出，以测试作为创业和成为自由职业者的技能将非常难获得足够的商业机会，并取得成功。毕竟测试是一个服务性行业，它需要和开发密切联系在一起，两者是需要密切沟通配合的，才能做好各自的工作。离开了开发，测试本身就失去了所服务的对象和价值。
那么对于99%的测试人是否永远都只能处在雇员这个象限？答案是“测试人可以同时处在雇员和投资者两个象限”。笔者对“投资者”的理解不仅仅限制于手拿资金投资的人，或是进行风险投资的VC们。“投资者”的含义还应该包含如下两种情况：
l 第一种情况：将我们自己的职业生涯长期地投资到一些能取得高速成长的企业，并能与企业一起分享成长所带来的高额回报。
l 第二种情况：尽早进行一定的个人资金理财。
举例
第一种情况的案例是非常普遍的：一位测试工程师通过加盟一家企业，并长期坚持服务于这家企业，最后靠企业的股票或期权获得较多财富回报的案例在如今的中国是非常多的。这样的方式对于广大的普通测试工程师而言，基本上算是最好的发财致富成功的好方法了。我们唯一需要做的是，擦亮眼睛，寻找这样的潜力股。
虽然，第一种情况的回报会非常大，但同样风险也比较大。有很多测试工程师靠公司成功后股票发财，可也有更多的测试工程师由于公司创业的不成功，在付出了几年的机会成本和时间成本后，手中的股票或期权却成为了一张废纸。那么对于一部分不愿意去冒这些风险的测试工程师，又该如何选择自己的成功象限呢？第二种情况似乎是最好的选择，尽早进行一定的个人资金理财。通过把低风险的测试职业和高风险的投资相结合，两者取其平衡。理财投资让那些喜欢待在大公司的测试工程师或是厌恶风险的测试工程师也有了一定致富的可能，而测试工作所带来的稳定收入又可以抵御一定的投资风险，让你有了投资失败后东山再起的本钱。
笔者曾在一家外企工作过，在这家企业服务期间，接触到一些来自美国硅谷的测试同行。他们大多做了十多年，甚至二十年的工程师，有的人有好几百万美元的家产，有的人甚至拥有了上千万美元的家产。他们的这些主要收入来源就是靠工程师的工资和投资股票的收益，目前过着既健康、有规律，又比较富裕的生活。其中一位测试工程师的故事更加传奇：他在1990年加入思科后，依靠思科的期权拥有了第一桶金。在工作之余做了天使投资，投了另一家高科技企业，7年后这家高科技企业帮他赚了100倍以上的投资回报。现在这位老工程师已专职在家从事天使投资的工作。
最后再给大家讲一个老故事：古代有条河，河两边有两座山，每座山有一个寺庙。一个寺庙住着一个年轻的和尚，另一个寺庙住着一个老和尚。两个和尚每天都会下山打水，并互相打招呼，关心彼此。忽然，连续几天老和尚没来打水，年轻的和尚担心老和尚是否病了，就到老和尚所在的山上来慰问他。可当他来到老和尚的寺庙时，吃惊地发现老和尚居然在打太极拳，看似非常精神的状态。年轻的和尚满脸惊讶地问老和尚：“老师傅，好几天你都没打水了，寺庙里不缺水吗？”老和尚微笑着给年轻和尚指了指身边的一口井说：“有了它，我再也不需要下山打水了。”年轻和尚充满疑惑地问老和尚“既然你有井，为什么这么多年来还坚持每天下山打水呢？”老和尚说：“我这山上原本没有井。这10年来，我每天打水回来后，都坚持在这里挖1小时的井，功夫不负有心人，我终于挖出了一口好井。现在好啊，我再也不用下山打水了。”
做测试的朋友们看了这个故事后，是否觉得我们可以打好测试这桶水的时候，也应该开始准备自己的井。无论是加入创业公司，还是个人理财，都是为将来实现自己的幸福生活而准备。所以，很希望广大的测试工程师们能多利用一些个人休息时间和精力，学习如何选择一个好企业，去积极关注IT行业的发展趋势，让自己能有识别潜力股企业的能力，或是尽早开始个人的资金理财之路。
十四、测试是科学也是艺术
测试工作到底是科学还是艺术？国内有的网友认为，测试只是科学，不是艺术；而有的网友认为测试是艺术，不是科学。
（1）支持测试只是科学的观点
转载一段来自微软一位培训经理William Rollison的文章：软件测试曾在商业软件领域被认为是一种事后的亡羊补牢。初级的产品经理甚至开发人员认为软件测试是任何人都可以从事的工作。一些关于软件测试的书籍甚至冠以“艺术”、“手艺”之类的名字。这导致软件行业的某些读者误认为质量测试不是软件工程的一个学科。相反，通过缺陷鉴别、错误预防和合理风险分析的实测报告，有效的测试不仅是一门工程的学科，而且是提升软件质量和可靠性的关键部分。
（2）支持测试只是艺术的观点
对于一个大规模的计算机程序，测试需要比设计程序更多的创造力。这个观点一直存在争议。Glenford J. Myers在《软件测试的艺术》一书中支持了这个理论，他指出“测试是极度富有想象力和高智力的有挑战性的工作”。实际上，很多既设计又开发软件的人承认他们通过创造力的软件测试获得了更多艺术上的满足感。
笔者在从事软件测试的前3年，从未想过测试是科学还是艺术，在笔者心中测试只是一个公司不可或缺的研发工作。但当几年前，第一次从一位有着15年美国测试经验的测试总监的培训中听到“测试是门艺术”的时候，心里受到了非常大的冲击，第一次听说软件测试是艺术，而之前身边从未有测试同行讨论过测试是科学还是艺术，更无法想象测试居然是门艺术。带着极度的好奇和兴奋，听完了这位美国测试专家的培训后，终于明白了测试是艺术的原因。从此，对测试工作的价值和意义有了重新的认识，应该说对软件测试这种工作有了更高的兴趣和热情。
其实美国专家这句“测试是门艺术”的意思，并未将测试中具有的科学元素排除掉。软件测试过程中需要的数学基础和逻辑能力都是从事任何科学工作所必备的技术素质。计算机软件与科学假设类似，两者都固有易错性，软件测试过程的基本框架类似于科学假设的试验和错误实践。测试工程师通过严格的测试（主要用于证明缺陷存在）反驳无缺陷软件的假设，这种“造假”的过程和数据驱动的方法（如归纳和推理）形成鲜明的对照，数据驱动通过事实的重复来证明正确性。这些方式都是通过确认来支持论断的，通过使用特殊数据验证功能正常来证实不确定的无差错。这种方式仅能证明软件功能在某种情况下功能正常，它并不能证明软件无差错。而所有的这些思维方式也正是科学工作的思维方式。同时作者还有一种观点：诸如测试的规范、测试的流程、自动化测试技术这些知识，可以通过书籍达到自学提高的目的，而这也是大多数科学性质学科所具有的特点——任何人都可以轻易地通过大量相关书籍来学习和掌握大量的技能和知识。
可是测试中最核心的宝钻——测试设计方法，则基本没有一本书可以真正的教会你。虽然有的软件测试书中谈到一些所谓的测试理论如“等价类”等，但如果你真有3～5年软件测试经验，你会发现书上这些理论只会束缚你的思维，用处不大。事实上很少有公司会严格按照书中所谓的“等价类”等这些理论来设计测试方法。那么测试方法的设计靠什么呢？答案：测试经验和创造性思考。测试经验必须靠勤奋才能积累，而创造性的能力是不可能通过书本学到，或是听两次培训就具备了。下面还有一个很有力的证据来证明测试具有艺术的气质——管用的测试书好买吗？
无论是中国还是美国，如果你想自学任何开发的技能，基本上任何一类开发的书都可以买到很多，并顺利完成自学成为高手。但当你想学习测试，想了解测试，想买测试书时，才发现可以帮助你自学成才的书几乎买不到。因此，很少会有人没有在正规公司做过测试前，对测试能有所真正的了解。那么为什么测试的书这么难买？我们是否可以这样来理解：能买到很多书的领域，通常人们都可以通过自学进入这个领域；而书很少的领域则注定很难自学成才，而必须依靠大量实践经验的积累和自己点点滴滴的思考积累才能有所收获。例如，音乐的作曲创作、作词创作是很难通过大量书籍让你自学成才、成名。测试方法和测试思维的精华就如同毕加索的作品、达芬奇的作品是无法看书能学到的，所以软件测试的工作性质基本和艺术创作是一个道理，其真谛只能意会，很难言传。
测试的流程和规范、自动化测试技术是测试科学的一面，它们能满足测试基本的需求。但如果想得到尽善尽美的产品质量，想不断地提高测试水平，达到高水平的测试效果，就需要通过挖掘测试艺术的潜质来实现，所以测试天生就具有艺术的细胞和基因。
因此，软件测试不仅仅具有科学工程的基因，也具有艺术的基因。现在一些国内公司在选拔和培养测试技术骨干时，都会强调测试骨干具有非常好的发散性思维，而发散性思维就是任何艺术活动必备的基本素质。所以，不管人们怎么看待软件测试的性质，如何定位软件测试人员的地位，任何从事软件测试的人都应该清楚地看到自己所从事的这份职业对人综合素质的要求，既需要我们有一个严谨的科学工程头脑，又需要我们有一个艺术创造的思维习惯。如果测试人员能理解软件测试是一门既具有科学性又有艺术性的工作，就不会再抱怨工作的无聊、无趣和没意义了。
十五、测试经验杂谈
按测试用例完成了功能测试，只是测试走完的第一步。
测试人员在忙碌后，要适当休息一下，自学一些产品相关的开发知识。例如，如果产品是基于VxWorks平台实现的，则可以看一本介绍VxWorks开发入门相关的书；如果是基于Linux实现的IP包过滤，则可以看看Linux OS的代码结构、大致的数据结构，了解一些IP包转发的代码实现规律，修炼内功。
l 凡是有缺陷的产品，你不测试它，它就永远有bug。
l 测试不是女同事的专属地，男女思维有别，测试最好能男女各顶半边天。
l 无论测试设计还是测试执行，都要充分利用测试时间和测试设备资源，节约搞测试。
l 重视测试要年年讲、月月讲、天天讲，不要只是2～3个星期搞运动，过后大家又一潭死水。
l 测试人员互相帮助，共同进步，一起提高产品质量的同时一起提高测试水平的修炼。
l 测试和开发团结如一人，一起实现天下无敌的高质量产品。
l 测试人员若由能力差的人组成，则这样的测试团队很难得到开发人员的重视，也很难得到公司的重视和投入，更谈不上士气的提升、专业水平的提高。
l 测试人员别空喊：“公司不重视测试，开发不尊重测试”。先拿出自己的所有本领，尽可能多地找出重要的bug，并帮助开发人员快速地定位bug。用你的输出和业绩让开发人员从业绩和能力上尊重你，正如同笔者当年一个人负责测试的帧中继QoS的模块，该模块的开发人员同时维护3个功能模块，在经过笔者相当一段时间的折磨后，某日他主动对我说：“因为严重bug修改得多，我目前最放心的就是帧中继QoS的模块”。往往开发人员修改的严重bug越多，他们反而更放心，更钦佩相应的测试人员。
l 坚定信念，bug还会有的，先别归咎客观条件。
l 只有测试者的才智才是真正强大的测试力量。依赖测试工具，不可能完全保证产品质量的完美。
案例
深圳S公司的某款产品常在实际应用中出现一些无法在实验室测试时发现的bug。在经过两款业内顶尖的测试仪器测试后，只发现了一个严重bug。该S公司后将这款设备交由一家专业的测试公司进行系统测试时，却在4天的时间内找到了4个严重bug，让S公司不得不佩服这家专业的测试公司。而这家专业的测试公司，靠的不是所谓业内领先的测试仪器，而是依靠三四名有着20多年测试经验的优秀测试工程师，花了近半年的时间设计出的一个个高效的测试策略和测试方法，才达到这样的效果。
所以，只有人才是创造世界历史的动力。
1. 人是要有一点精神的，测试人员至少需要一点信念，坚信bug一定还有。
2. 测试就是找bug，以bug输出为业绩。如果仅听开发人员说已不可能测出bug，就不再测试的话，也就不需要专业的测试人员了。
3. 实践出真知，所有的测试策略和测试方法的实际效果一定要靠实际动手实施论证后，才能知道是否真正有效。
4. 世界上怕就怕“认真”二字，很多bug稍纵即逝，如果测试人员不和开发人员较真，就得不到100%的确认。
5. 不要轻易放过任何一个测试人员自己主观怀疑的问题疑点。
6. 漏测是犯罪，过度测试同样是犯罪。过度测试会浪费开发人员宝贵的时间，会让所有人忽视其他或许更重要、更需要深入测试的地方。
7. 测试人员不但要善于找bug，还要加强定位bug重现的能力。找bug是艺术，需要的是创造性；定位bug则是科学，需要严谨的逻辑推理能力。所以，笔者爱说：好的测试人员一半是工程师一半是艺术家，是严谨与创造性共存于一身的人。
8. 无限风光在险峰，当我们发现不了bug的时候，挑战自我、突破自我的时候就来了。
9. 测试是一个从没有止境做到100%完美的工作。
10. 虚心使人进步，骄傲使人落后。即使你是找bug数最多的测试人员，也要向身边的每一个测试人员学习他们的经验，毕竟每个人都有自己独特的思想和思路。而测试生存和发展的根基就是发散的思维和不断增加的新测试方法。
11. 对于软件测试新人而言，最难的是找到第一个bug，第一个严重bug。因为测试新人在第一次执行测试的时候，很可能从事的是回归测试或一个已长期测试过的产品。测试目标本身能容易被找到的bug就比较少，再加之测试新人所依赖的测试用例，也早已发现了用例能发现的所有bug了。所以，新人一开始就直接遇到一个大的挑战。因此，新人如果第一次开始测试时，第一周没找到bug，请不要灰心，坚定信念，发挥自己的创造性，去创造一些老员工没有用过的方法，至少先要乱想10个新的测试情景来一一尝试，试图找到一个bug，哪怕是一个拼写bug。只要有了第一个bug就如同销售人员开了第一单，你就可以星星之火，可以燎原了。
12. 测试人员不要指望一周时间就找到所有的严重bug，也不要期望一个测试人员或一种测试方案就可以保证整个产品的质量，饭要一口一口地吃，山要一点一点地移。一个产品的稳定，需要多人、多个版本、多个测试阶段、多种测试方案，一个一个的bug积累起来，才能最大化地保证产品的高品质。
13. 测试策略是一个测试项目成功与否的生命。
14. 测试部门真正的铜墙铁壁是从事各类测试相关工作的人，而且是真心实意拥护公司价值观和使命的人，并不是所谓的流程、仪器和工具。
产品的质量稳定要靠公司中测试人员的主观能动性、智慧和潜能的挖掘、高昂的士气来保证和提高。切不能迷信靠几台测试仪器、几次技术培训、一些外部流程就能保证质量的提升，关键还是发挥和挖掘自身的潜力。
十六、软件测试的黄金阶段
软件测试作为一种专业的社会活动，一定有着它价值闪光的黄金阶段。如同在20世纪70—80年代，对于很多刚解决了温饱的家庭都未曾想过购买家用小汽车，认为没必要，也没足够的经济实力来购买、供养小车。但到21世纪后，中国很多的家庭富裕起来后开始购买小汽车了。小汽车之于中国家庭，正如软件测试之于中国软件企业，只有当企业解决了最基本的生存问题，在追求下一阶段高质量发展时，才会用满足了生存后的资源来投入软件测试中。而在一个软件企业有着做“基业常青”的目标时，软件测试对于软件企业，一定会随着企业的不断成长，而不断地得到越来越多的重视和资源倾斜。
因为任何一个产品都会经历：“从无到有，从有到好，从好到优”3个阶段。不光指软件产品，还包括其他诸如汽车、家电等产品都有这样一个演进过程，这也是为什么许多老牌企业的成熟产品总要比新公司的新产品质量要高的原因。所以对于许多刚上市的第一版产品，企业为了最快时间推出第一版产品，抢占市场，在产品质量投入上都无法做到完全100%精益求精。因此，在第一阶段，企业要解决的问题是“从无到有”，最重要的目标是尽早推向市场，“时间”是第一关注要素。在产品的这一阶段，肯定企业内部的所有资源和工作计划的优先级都是为了能抢时间，对于软件测试的投入和关注度肯定会有所降低。这一阶段的软件测试关注的重点应该是确保产品能满足最基本的产品市场发布的基准。何为软件测试的基准，以及如何确定软件测试的基准？将在下一节的内容中进行讲解。
当第一版产品成功推向市场，撕开了竞争对手的防线，并抢到了后续生存和支撑发展的“面包”后，为了站稳市场并不断拓展市场空间，产品的信誉就显得特别重要了。而产品的信誉中第一重要的要素则是“质量”，一旦推出的产品质量有重大问题或小问题不断，在用户口碑中流传这些质量问题，对于企业基本就是毁灭性的。不但刚刚打开的市场会丢失，恐怕日后还会更难重新进入市场。因此，这时企业都会在第二阶段把不断优化和提高产品，提高产品性能放在一个重要的地位。这时，对于软件研发的重视重心，开始逐渐从开发向测试转移，虽然开发依然会不断投入开发新功能，但是测试投入的比例会比第一阶段大大增加。
在产品第一阶段，软件测试确保产品满足了推向市场的最基本的基线标准，这一阶段对测试人员的技术要求最低，对测试人员基本不要求进行发散探索性测试，即最基本的功能测试和最简单的性能压力测试，是“防守性测试”，而不是“进攻性测试”。在第二阶段为了提高产品的质量，尽早暴露产品的问题，这时就需要对软件测试人员要求“进攻性测试”，相应地对软件测试人员的技术要求也就更高了，需要软件测试人员开始进行大量的发散探索性测试，创造和设计出更复杂的测试方案，来加大对产品功能测试、性能测试、压力测试的测试力度，发现产品异常的问题。这一阶段软件测试人员的压力会比第一阶段大得多，不但要求能完成基本的基线标准工作，而且还要求发挥主动性，进行更多积极主动的攻击测试，提前暴露产品的潜在问题。企业已在第一阶段告诉了市场，产品的存在，更多的潜在用户很有可能会在产品的第二阶段成为真正的用户，如果软件测试人员不能在产品大面积使用之前提前发现更多的产品问题，那么很可能企业会在产品第二阶段把以前的全部成果都毁于一旦。因此企业在第二阶段推出的产品质量通常都比第一阶段推出的产品质量提高了不少，不但企业修改了第一阶段暴露的问题，而且对产品的各种潜在质量问题也提前解决了，虽然有不少用户并未在这一阶段感受到产品内在质量的大大提升，但对企业而言却在第二阶段对产品质量的提升投入了更多的力量。
在第三阶段，随着企业开始进入行业第一军团，产品质量也成为行业第一流的标准自然是毋庸置疑的要求；否则，在与第一流竞争对手竞争用户时，会被对手的质量比拼下去，而难形成第一流的品牌，这也是为什么知名大公司会更重视测试的原因。大公司要长期发展必须重视一流的品牌和质量信誉，一流的质量提升不光靠开发人员的高水平设计，还需要软件测试来帮助把握平衡。开发和测试在这个阶段如同一名运动员的双腿，只有双脚均衡有力才能决定最后整体的成绩。
第三阶段的软件质量提升方式已不仅仅是进行“大规模猛烈的进攻”就可以达到一流的质量水准。为什么有些企业把预算和测试人员数量增加了1倍，而产品质量却依然没有取得更大的提高？这是因为第三阶段软件测试技术层次的提升比第二阶段要难得多。这一阶段的软件测试水平的提升规律，已不仅仅是多投人、多投资源就能保证出新成果的。即使投入更多的人，如果工作方向和思维方式不改变，则只会使更多的人依然停留在原水平进行重复劳作。第三阶段的质量提升方式就应该如同“美羹小火熬制”的方式，讲究精准的雕刻手法，讲究科学精巧的干。讲究“智”的投入，应选用和投入资源让真正的“测试明白人”开拓创新。一方面，投入高水平的测试研究型人才采用引入和自己创新研究的方式，不断引入更多提高测试技术水平的新思路和新方法来找到更深层次的质量问题。另一方面，在内部已有的测试流程和测试方法中不断优化测试效率，从内部要效益。采用“内外结合”的方式，加上少量高水准的测试研究型人才，不断对测试的各环节进行提升,让企业的产品质量满足最高质量标准要求的顶级用户的需求，成为市场一流产品品牌。
综上所述，中国软件测试的黄金阶段一定出现在中国的企业度过生存期，开始进入高速发展期，和开始进入行业一流企业集团之时。中国过去不重视测试，导致测试长期处于低水平需求时代，是有其历史必然原因的，测试人员没有必要去埋怨过去和历史。但是现在中国越来越多的民族企业已度过了生存期，进入了高速发展期，对软件测试开始逐渐重视起来，最明显的表现就是测试人员的招聘数量开始大量提高。同时，中国的少量优秀企业已进入或马上进入所在行业的世界第一集团，对测试的需求和投入已开始追求高水准的测试技术阶段，高端测试人才的需求已悄然在猎头的列表中。测试人员的工作内容已不仅仅是编写测试用例、编写测试脚本的阶段，而是如何帮助企业在现有测试水平的基础上不断提高测试的技术方法，提高测试工作效率和科学性，挖掘更深的问题，从质量的角度来保证企业能进入第一集团并保住第一集团的市场地位。
十七、软件测试验收基准
软件测试什么时候可以结束？这是一个对于有一定经验的测试人员，特别是测试管理者在测试项目中常常会困惑的问题，因为大家都知道bug永远也不可能100%被找到。所以，对测试工作结束标准的度量，成为了很多公司测试项目和测试绩效考核的疑难问题。错误的测试结束标准如下：
● 对产品进行一轮全面测试后，在发现的bug数中，一级bug数少于1个，二级bug数少于2个，三级bug数少于3个。
● 产品测试的bug总数达到了N个，如500个。
以上两种测试结束的度量标准都是不科学的标准。即使测试的最终结果达到了这些数字，并不能说明产品的软件质量已能满足市场需求了，甚至反而因为受累于这些数字指标影响了产品正常的市场发布时间。
在前一节中，曾提到在软件测试的第一阶段，需要制定一个基线测试标准。在正式提出建议的基线测试标准前，笔者先谈一种软件测试的理论：正面测试与负面测试。
正面测试就是在大多数情况下产品的正常使用方式，以及满足大多数情况下的抗压力能力和性能指标。严格按用户正常习惯来测试，不做发散探索性测试，满足最原始的Marketing或产品规划部门提出的产品交付需求。
负面测试则是大家所理解的对软件进行各类进攻性破坏测试，构造各种异常场景，甚至是高于多数真实场景的压力测试指标，目标就是尽可能地找到产品的所有bug，即使这些bug可能在实际应用中10年也不会被用户遇到。负面测试对测试需求的要求标准高于原始的产品市场交付需求。
在产品第一阶段，为了最快地推出产品以满足市场需求，建议测试基线标准以正面测试为标准。测试人员尽力保证市场交付的原始需求，首先让产品在用户处使用起来，然后再通过升级的方式为用户提供第二阶段输出的更高质量的软件版本。那么这一阶段的基线标准，就应该由公司的Marketing或市场人员，与测试人员共同从市场的视角和需求来编写测试用例，评审测试用例。由Marketing确认基线测试用例，测试人员执行测试用例时，只要保证所有测试用例没有再发现bug，即证明产品的软件质量满足了最初的市场需求，便可以结束第一阶段的软件测试。
在产品第二阶段，为了提高产品的质量，提前暴露问题。满足用户更深层次的软件质量需求，必须在满足基线标准的基础上，加大负面测试的力量，包括各项测试人员进行自由发散探索性的攻击性测试，再加上安全性测试、负面测试、长期大压力测试等。尽可能去验证测试产品的健壮性，该阶段的测试用例可以先由开发人员和测试人员共同完成初稿评审。由于该阶段的测试工作中即时创造性内容较多，因此必须随时将找到了bug的测试方法补充固化到测试用例中。当使用所有的测试方法和测试方案进行一段时间测试后，bug出现的数量开始呈经过数轮测试出现不断减小收敛的趋势后，测试经理们应该与开发人员、产品市场经理一起针对当前发现的bug情况和各测试目标bug收敛的趋势情况，决定产品是否可以向市场发布，但必须保证产品能100%通过基线测试标准和第二阶段所有测试用例的测试。
1314
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
