测试的态度

……
1.1  精益求精
精益求精不仅仅是一种做事的标准，更是一种做人的态度。无论是测试用例设计、性能测试、回归测试、测试脚本开发还是测试工具开发等任何一个测试的分工，都需要用精益求精的态度来提高每个测试环节的质量，并相应地提高产品的测试质量。
  案例
A是某著名软件公司的软件测试人员，工作的流程非常严谨而明晰，这自然也意味着重复劳动。但枯燥并没有淹没A的工作激情，发现一个bug会带来很大的成就感，特别是想到每天将会有几百万人通过使用没有这个bug的软件准确无误地达到他们的目的，A就特别有成就感。虽然可能一整天都为了一个小功能“循规蹈矩”地反复测试，但是这样的重复却被A当做一种重要的积累，在积累中不断地追求精益求精的完美。
正如新东方学校的徐小平在其著作《骑驴找马》中的一句话：“重复做汉堡，就是麦当劳；重复煮咖啡，就是星巴克；重复教托福，就是俞敏洪；重复做好事，就是活雷锋。”重复的过程也是追求精益求精的过程，每一次重复都需要比上一次做得更好、更精彩，你才能不断地进步，并做到极致的成功。
1.1.1  测试用例设计的精益求精
测试用例设计工作本身是一个很难直接定量的工作，也不可能像开发代码一样，只要编译通过可执行就认为完成了任务。那么在测试用例设计过程中，我们如何才能促进测试用例设计水平的提高呢？测试用例的设计和编写基本上只有依靠测试工程师自己精益求精的态度才能保证测试用例设计的质量。测试人员自身精益求精的态度，不但影响着测试用例的设计质量，而且直接影响着测试人员之间测试水平的高低。
在设计测试用例时，精益求精的精神需要我们在完成每一个功能测试点的基本测试方法设计后，再继续投入时间和大脑，并继续发散思维，在基本测试方法的基础上多写出一两倍的测试方法，希望所设计的用例能发现更多的bug，使测试的质量取得更好的效果。有一天你会发现正是这些多写出的测试方法更容易发现bug，帮助测试人员提高自己绩效的同时得到测试的乐趣。因为最基本的应用模式，90%的人都会比较容易地想到和覆盖到；而质量提升的最后10%，则可能只有很少的人，也许是10%的人才能去实现和达到。所以当我们在进行功能测试的测试用例设计时，每多想一个测试方法，就越接近99%的质量目标。
  案例
一个即时通信产品的服务器与客户端通信功能模块的测试用例
基本测试要求：服务器与客户端之间传送文本信息的功能测试（不包括压力测试和性能测试）。
大多数人很容易就想到如下测试方法：
（1）服务器向客户端发送一段文字，如果客户端能收到完整的信息，则验证通过。
（2）客户端向服务器发送一段文字，如果服务器端能收到完整的信息，则验证通过。
倘若只是进行最基本的通信功能验证，好像如上两个测试方法已经覆盖了服务器与客户端通信的全部功能。可是，如果我们能追求测试用例设计的精益求精，则该功能的测试用例还可以再进行如下补充。
测试策略1——测试数据集
服务器与客户端通信的测试数据分为：全中文（不同编码格式）、英文、日文、中英文+数字+其他符号（@、#、!、～、&等）的组合、以数字及各类符号作为传送信息的最后一个字符。
以服务器能输入字符信息的最大数量为依据，输入一个最大化的数据，判断客户端能否完整显示。
以客户端能输入字符信息的最大数量为依据，输入一个最大化的数据，判断服务器能否完整显示。
应用测试策略1，服务器端与客户端1:1同时进行双向通信。
应用测试策略1，服务器端与客户端1:n同时进行双向通信。
应用测试策略1，服务器端与客户端n:1同时进行双向通信。
测试策略2——临界状态测试
在服务器和客户端同时发送空数据信息给对方。
在服务器和客户端同时发送满数据信息给对方。
在服务器和客户端启动过程中，分别向对方发送空信息、满信息。
测试策略3——异常处理
模拟双向数据传输时，传输过程中不断发生传输中断和恢复，服务器和客户端不发生不合理的现象。
数据发送瞬间，接收端发生意外关闭、正常关闭或接收端重启，是否服务器和客户端不发生异常，接收端能正常接收完整的发送信息。
在对端软件未启动和传输通信不通时，如果数据发送失败，发送方进行合理处理。
测试策略4——长时间工作
通过转换为自动化测试的方式，将测试策略1、测试策略2和测试策略3按先后顺序循环执行多次或10小时以上，寻找测试策略1、测试策略2和测试策略3所能覆盖的逻辑处理代码中是否有内存泄漏的情况。
到目前为止，我们已在最开始的测试设计基础上进行了很多的扩展。那么我们现在是否还可以有新的测试策略来进一步提高测试用例的质量呢？
测试策略5——模拟资源紧张情况下的测试
长时间（10小时以上）同步模拟服务器和客户端在各自接收端口和发送端口同时受到网络攻击，在有限的通信系统资源紧张的情况下是否还能进行正常的文本通信，而不出现异常。
测试策略6——真实环境测试
将服务器和客户端挂在Internet上进行真实环境的测试，验证是否会有在真实环境应用中我们未想到的测试情形。
我们现在还能继续设计新的测试策略吗？只要你坚信测试无止境，坚持凡事精益求精，向自己的思维潜力挑战，肯定还可以设计出新的测试策略。
笔者于是在前面已有的测试策略的基础上又有新的突破，秉承对功能测试质量精益求精的态度，继续对该模块进行测试方法的挖掘。
测试策略7——安全性测试
服务器和客户端在通信过程中进行安全性测试。当两端正在持续正常通信过程中，同时启动对服务器和客户端的各类安全性测试攻击。例如：通过向接收端进行伪造的源IP数据攻击；向接收端发送一些畸形的数据文件格式；向接收端发送一些错误的协议报文等方式，来判断接收端是否会出现异常。
最后限于笔者对即时通信软件客户端与服务器通信测试的有限功力，这个功能点的测试设计先到此为止。希望通过这个案例如何进行精益求精设计的过程，来让读者体会“精益求精”对于提升测试用例设计水平的意义和价值。读者如果感兴趣，还可以在此基础上提出更多好的测试策略，不断完善这个案例的测试用例设计。
测试用例设计的精益求精除了多创造测试方法外，还有另一个很重要的领域——在测试用例设计规范上追求精益求精。笔者曾见过不少测试用例由于写得过于草率和简单，导致执行测试的人在工作时压力非常大，需要花费很大的精力和时间来啃测试用例中描述的真实含义。请大家不要误认为这只是因为我们中国测试起步晚，才有这样的现象。笔者曾见过两家欧美顶尖电信设备公司老外工程师写的测试用例，其测试方法过于简单，测试步骤描述基本没有，基本上每个执行这些测试用例的中国工程师都叫苦连天。
你说这些欧美企业没有规范的流程吗？可他们是CMMI5（软件能力成熟度模型集成模型5级）都过了的，这些测试用例也是经过了每一个需要评审的流程才正式进入测试用例库的。那为什么这些外国人写的用例方法如此简单？因为测试流程和测试规范只关注测试用例的骨架是否完成，而附着在骨架上的肌肉状况，则很难由流程来规范和考评。这样有的老外就偷懒，用一句简单的句子就描述完了一个测试方法，给后来者带来了极大的痛苦。
据笔者所知，后来在这两家欧美企业的中国工程师一改他们的老外同事留下的弊病，在写测试方法时，尽量做到非常详细的文字描述，并尽可能地把所有的操作步骤和命令都补充在对应的测试步骤后面。使用这种精益求精的态度写出的测试用例，完全可以让任何一位测试用例执行者只看一遍测试用例即可完成测试用例的执行。测试用例设计工程师通过自己多付出些时间来完善和丰富测试用例的描述，不但大大提高了未来测试用例执行的效率，而且为公司节省了时间和成本。
1.1.2  性能测试的精益求精
在进行性能测试时，我们需要细致地关注每一个数据的变化，不放弃任何一个怪异的数据变化是最基本的性能测试工作的态度要求。那么在性能测试中的精益求精可以体现在哪些地方呢？一个性能测试活动本身大致需要经历如下4个阶段。
第1阶段：选择可靠的性能测试工具。
第2阶段：调试及稳定性能测试环境。
第3阶段：正式的性能测试。
第4阶段：统计性能测试结果，输出性能测试报告。
在选择可靠的性能测试工具阶段，如何做到精益求精？可能有朋友看到这里会问：“选择工具还需要精益求精？那么如何精益求精？”。俗话说：“好的开始是成功的一半”。软件的性能测试非常依赖性能测试工具的长期高负荷运转的稳定性和测试数据统计的精确度，对性能测试工具的选择决定了后续工作的成功与否和成本消耗的代价。就是这样一个对后续工作至关重要的步骤，却在实际工作中没有得到足够的重视，这个过程很有可能就只是某个性能测试工程师花两三个小时的时间到网上搜索几篇文章，按网上文章推荐的工具来初选，然后根据个人主观的判断就决定了未来所用的性能测试工具。结果，有可能这个性能测试工具在后续的调试稳定测试环境阶段，以及正式测试阶段和统计结果阶段会出现各种各样的奇怪问题，并导致性能测试团队不得不花费数倍的时间来解决这些性能测试工具的问题。
因此，在选择性能测试工具时，建议除了在网上搜索介绍资料外，最好能亲自把所选的几个性能工具进行本地对比测试。在同等环境下，对后续关注的测试数据指标先进行测试观察，然后再将这些性能测试工具的各项性能参数、长期稳定性等关键指标，形成一个表格交由整个测试团队来决策并最终选出未来正式使用的性能测试工具。虽然在进行工具性能对比测试时，会消耗掉测试人员的部分时间和公司人力成本，但是却能避免以后在错误的道路上越走越远，造成无谓的成本消耗越来越大。
测试团队一致选定了性能测试工具后，负责该工具操作的测试人员，需要继续发扬精益求精的工作态度，去全面、深入地了解和掌握该性能测试工具的各类使用方式。笔者曾见过某公司花费重金购买了一个世界顶级的性能测试工具，结果，几年来该公司的性能测试人员只会使用该性能测试工具的少数几个基本功能，其中的大部分功能从未应用过，大大浪费了公司的资产。为什么会出现测试人员对性能测试工具使用不充分的现象呢？原因可能有如下几种可能：由于人的天生惰性，在完成了最基本的性能测试需求后，就不再对性能测试工具的其他功能花时间来了解、操作、学习。当然也可能是由于该工具的学习和使用难度较大，测试工程师在无客观压力的情况下，面对困难退缩了，不愿意继续钻研学习该工具。
所以，我们需要性能测试工程师在性能测试工具上同样能发扬精益求精的精神，在使用性能测试工具时能精益求精地多钻研该工具的其他功能，全面深入地了解该工具的使用特点，最大化地发挥性能测试工具的作用，提高公司资产的利用率。
在调试和稳定性能测试环境阶段，性能测试工程师可以在只完成最基本的环境搭建并让大部分设备和软件正常运转起来后，就直接开始正式的性能测试。但是，只是保证大部分设备和软件能够运转起来对于期望开展高质量的性能测试是远远不够的。只有保证整个性能测试环境能够长期稳定地工作，才能真正确保性能测试的效果和效率；否则会在后续统计测试结果阶段，付出很多时间和成本来分析测试结果中的“垃圾数据”。
一个稳定的性能测试环境是执行性能测试和准确统计性能测试结果的发动机。如果发动机不结实、不稳定，时而无动力，时而动力下降，那么驾驭这个测试环境进行性能测试的人将会非常痛苦。在笔者以前的性能测试经历中，就曾经出现过测试环境中的模拟器时而正常工作产生正常的数据，时而停发数据，时而效率下降，其直接结果就是大大影响了正式性能测试的项目进度，很难得到准确的性能测试效果。
因此，一个追求精益求精的性能测试工程师，应该用尽一切方法，确保性能测试的环境能够非常稳定，仔细地调试性能测试环境中的每个模拟器。如果物理连线环境有问题或设备有缺陷，则一定要事先准备好备用方案，绕开这些问题，来保证性能测试环境的稳定。如果性能测试工程师觉得只是保证性能测试环境的长期稳定还不够体现其精益求精的精神，则可以努力将性能测试环境再改造成一个半自动化测试的环境。一个半自动化测试的性能测试环境将会大大帮助提高性能测试环境的使用和搭建的效率，同时也是性能测试工程师对工作精益求精追求精神的体现。
正式的性能测试阶段，通常是性能测试工程师在所有性能测试工作的各阶段中最轻松也最有空闲时间的阶段。大多数情况下，很多性能测试工程师就觉得该自己休息、喝咖啡、聊天了。请先别忙着完全放松下来，虽然前期的测试准备工作非常辛苦，现在难得有空休息了，是应该短暂休息一下。但是，是否我们还可以更好地利用好这段唯一的休息时间来做一些让我们的工作更精益求精的事呢？例如：为了以后分析、定位问题更快，完成环境参数配置更快，我们是否可以利用这段时间开发一些自动化配置环境参数和自动化分析定位的小工具，每当遇到麻烦时，就可以大大提高解决麻烦的效率，为公司节约时间和人力成本。同时你还可以利用这段时间，多思考是否可以在现有的性能测试方案的基础上，针对性能测试方案再进行改进和优化，创造出更多新的性能测试方案，发现更多隐藏得更深的bug。
另外，你也可以利用这段较空闲的时间优化性能测试报告的内容，让其图文并茂，能更准确、简洁地展现性能测试的结果。因此，如何充分利用好这难得的大块空闲时间，取决于我们是否有着一颗精益求精的心。只要有一颗精益求精的心，在性能测试的执行阶段也能创造出更大的贡献和价值。
在统计性能测试结果和输出性能测试报告阶段，我们依然可以进行精益求精的改进。可以在查看性能测试仪器的统计数据结果时，仔细查看性能测试过程中的每一条log信息，从执行的log中不放过任何稍纵即逝的异常信息，毕竟每一个详细的log信息也是我们性能测试的劳动成果，很有必要充分利用起来。如果你现在还完全用手工和人眼来对大量的log信息进行处理，那么你很有必要通过编写自动化log分析工具来自动查找异常log信息的方式来大大减少工作量，提高log分析工作效率，而这也是体现精益求精的方式。
在性能测试报告中，你可以不只是简单地罗列本次测试的几个数据就算完成了任务，还可以加上丰富、详细的历次测试数据的趋势对照，并且图文并茂，以及除测试参数数据外的其他相关数据的变化。相信这样的性能测试报告应该会更让所有人满意，一位能做出这么完整的性能测试报告的性能测试工程师一定会因其精益求精的工作态度得到同事和领导更多的尊重和肯定。
1.1.3  回归测试的精益求精
前面两节谈了有关测试用例设计和性能测试中精益求精的方法，相信大家还是有所收获的。那么接下来我们应该如何进行回归测试的精益求精呢？笔者曾经做过手工回归测试，也做过自动化回归测试，从笔者自己的经验和身边看到的实例证明，在从事看似枯燥的回归测试工作时，我们同样可以调整自己，在回归测试工作中追求精益求精。
在手工回归测试时，我们除了需要按照测试用例的要求，保证每一步都是正常完成测试外，自己还可以利用空闲的时间和资源，尝试小范围地改变测试用例中的参数和方法，来进行一定的探索性测试。这样的行为有时能帮助我们得到意外的惊喜，发现新bug。毕竟创新是无止境的，没有哪个测试用例是完美的，按照测试用例执行回归测试可以保证90%的测试目标，但是靠自己想出的新点子找到的问题，却可以帮助测试团队和公司向最后10%的质量目标又前进一步。笔者相信，任何测试经理对于你在完成了本职工作后，还能发现新问题，都会感到非常高兴。能超出预期的员工肯定是一个追求卓越、追求精益求精的员工。
自动化回归测试阶段，与性能测试执行阶段类似，你将会有大量的空闲时间。在这段空闲时间中，最容易想到追求精益求精的方面是，自己编写一些自动化测试脚本结果的分析工具。当出现自动化测试脚本运行失败时，可以大大缩短分析、定位的时间，提高工作效率。同时，你还可以思考是否可以通过改变和优化脚本执行的顺序来大大降低自动化脚本运行失败的概率，从而达到缩短自动化测试脚本运行时间，提高运行效率的效果。
1.1.4  测试脚本开发的精益求精
精益求精的态度在测试脚本的开发中比较容易得到体现。例如：测试脚本优化；测试脚本的信息提示；测试脚本与测试工具的融合；测试脚本文档4个领域，都有着足够的空间让我们去发挥，去追求精益求精。
1．测试脚本优化领域
我们可以不断优化测试脚本，使其能够适应在不同的测试环境中运行。也可以通过优化脚本的测试代码，使其能够有很强的容错性，在有一定干扰或异常的情况下依然成功运行下去，不对测试环境的“纯净性”要求过高。通过使测试脚本的代码松耦合，当被测设备的命令风格发生变化时，只需要对测试脚本做尽可能少的修改，就能适应新的命令风格。
2．测试脚本的信息提示领域
当测试脚本在运行失败时，能打印出更多的错误信息和更详细的调试分析信息。在脚本运行失败后，通过报错信息直接告诉测试人员是脚本语法错误，还是测试环境错误，或者是某个正常的逻辑处理错误。这些提示信息可以让自动化回归测试执行的工程师高效地分析、定位出脚本失败的原因，越是详细的调试分析信息，越能帮助测试工程师提高工作效率。
3．测试脚本与测试工具的融合领域
一般情况下我们在进行手工测试时，常常需要借助一些第三方辅助小工具来完成测试。对于这种情况下的自动化测试脚本开发而言，要在测试脚本中完全模拟像手工测试一样的测试效果，脚本开发的难度是比较大的。不过，我们可以从如下几方面入手来实现目标。
（1）多了解一些开源的小工具来代替目前辅助测试的小工具。通过开源的小工具，可以更容易地开发出适合自己调用的API，便于集成到自己的测试脚本中。
（2）在脚本与工具的接口代码处，优化脚本代码使其松耦合，当以后需要更换测试工具时，依然能很容易地驱动新的测试工具。
（3）测试脚本能够对测试工具发生的异常和错误提供足够详细的log信息，便于以后因测试工具的错误而引起脚本运行失败时，可以快速地进行定位，节省分析、定位的时间和成本。
4．测试脚本文档领域
文档的编写也许是大多数工程师都不愿意从事的工作，但是它却对公司非常重要，公司要实现铁打的营盘、流水的兵，就必须有非常详细、规范的各类文档。虽然，我们可以在测试脚本中通过注释的方式来解释各个测试步骤的脚本代码，但毕竟注释方式所覆盖的信息量太少。我们最好是针对每个测试脚本有一个独立的测试脚本开发文档，告诉后来者这个脚本要干什么；各个测试步骤是怎么实现的；关键参数是什么；用了哪些变量，每个变量的含义；与其他测试脚本的层次关系如何等。
1.1.5  测试工具开发的精益求精
在测试工具开发过程中，对于工具的开发者不光要实现工具的功能要求，也要像对待一个商业产品一样，对代码规范及工具的功能稳定性、易用性和相关文档做到精益求精。
一个测试工具的开发并不是一次性的。因此，我们需要像对产品开发要求一样，尽量有一个规范的代码结构，以便于后来者进行二次开发和维护。虽然我们很少会利用自己开发的测试工具进行精确的性能指标统计测试，但是我们却常常利用测试工具进行流量的模拟。为了保证测试环境流量大小的稳定性，我们也需要对自己开发的测试工具进行测试，优化测试工具的性能，使测试工具能够在实际应用中尽量状态稳定地工作。因此，我们可以在测试工具开发这一环节进行尽可能精益求精的发挥。往往一个测试工具的稳定性效果就是优秀测试工具开发者追求精益求精、追求卓越的结果，也是与其他普通测试工具开发工程师的最大区别。
在测试工具的易用性方面，通常由于测试工具开发项目时间紧，使得测试工具的使用方式在风格上可能过于偏“开发化”，也就是说，开发者自己可以很容易理解和使用测试工具，而测试工具的用户——测试工程师却比较难全面搞懂所开发的测试工具的使用方式。因此，建议测试工具的开发工程师应在稳定了测试工具后，再从测试工具易用性的角度，来不断完善、改进开发的工具。
在测试工具的相关文档方面，如果开发者自己不希望未来每一个工具的使用者都亲自来向他请教工具如何使用，或是未来进行二次开发时，自己都回忆不起来所有的代码细节，那么测试工具的开发者还是最好能在工具的开发过程中，编写一份详细的开发文档，以及在完成测试工具的开发后，开发一个详细的使用手册。这样不但方便了未来的测试工具用户，也大大减轻了测试工具的开发者未来维护和支持的工作量。