搜索
第1章测试的态度知名足球教练米卢曾说过“态度决定一切”。在我们的生活和工作中，一个好的态度将是影响我们是否能够成功，是否能够取得进步的最重要因素。足球运动员有“足球的态度”，我们软件测试人员也应该有“测试的态度”，因此本书将“测试的态度”放在了第1章作为本书最重要的内容。先点燃读者心中积极的火焰，然后再带着良好的态度来吸收和了解其他软件测试的相关经验和观点。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阶段：统计性能测试结果，输出性能测试报告。在选择可靠的性能测试工具阶段，如何做到精益求精？可能有朋友看到这里会问：“选择工具还需要精益求精？那么如何精益求精？”。俗话说：“好的开始是成功的一半”。软件的性能测试非常依赖性能测试工具的长期高负荷运转的稳定性和测试数据统计的精确度，对性能测试工具的选择决定了后续工作的成功与否和成本消耗的代价。就是这样一个对后续工作至关重要的步骤，却在实际工作中没有得到足够的重视，这个过程很有可能就只是某个性能测试工程师花两三个小时的时间到网上搜索几篇文章，按网上文章推荐的工具来初选，然后根据个人主观的判断就决定了未来所用的性能测试工具。结果，有可能这个性能测试工具在后续的调试稳定测试环境阶段，以及正式测试阶段和统计结果阶段会出现各种各样的奇怪问题，并导致性能测试团队不得不花费数倍的时间来解决这些性能测试工具的问题。因此，在选择性能测试工具时，建议除了在网上搜索介绍资料外，最好能亲自把所选的几个性能工具进行本地对比测试。在同等环境下，对后续关注的测试数据指标先进行测试观察，然后再将这些性能测试工具的各项性能参数、长期稳定性等关键指标，形成一个表格交由整个测试团队来决策并最终选出未来正式使用的性能测试工具。虽然在进行工具性能对比测试时，会消耗掉测试人员的部分时间和公司人力成本，但是却能避免以后在错误的道路上越走越远，造成无谓的成本消耗越来越大。测试团队一致选定了性能测试工具后，负责该工具操作的测试人员，需要继续发扬精益求精的工作态度，去全面、深入地了解和掌握该性能测试工具的各类使用方式。笔者曾见过某公司花费重金购买了一个世界顶级的性能测试工具，结果，几年来该公司的性能测试人员只会使用该性能测试工具的少数几个基本功能，其中的大部分功能从未应用过，大大浪费了公司的资产。为什么会出现测试人员对性能测试工具使用不充分的现象呢？原因可能有如下几种可能：由于人的天生惰性，在完成了最基本的性能测试需求后，就不再对性能测试工具的其他功能花时间来了解、操作、学习。当然也可能是由于该工具的学习和使用难度较大，测试工程师在无客观压力的情况下，面对困难退缩了，不愿意继续钻研学习该工具。所以，我们需要性能测试工程师在性能测试工具上同样能发扬精益求精的精神，在使用性能测试工具时能精益求精地多钻研该工具的其他功能，全面深入地了解该工具的使用特点，最大化地发挥性能测试工具的作用，提高公司资产的利用率。在调试和稳定性能测试环境阶段，性能测试工程师可以在只完成最基本的环境搭建并让大部分设备和软件正常运转起来后，就直接开始正式的性能测试。但是，只是保证大部分设备和软件能够运转起来对于期望开展高质量的性能测试是远远不够的。只有保证整个性能测试环境能够长期稳定地工作，才能真正确保性能测试的效果和效率；否则会在后续统计测试结果阶段，付出很多时间和成本来分析测试结果中的“垃圾数据”。一个稳定的性能测试环境是执行性能测试和准确统计性能测试结果的发动机。如果发动机不结实、不稳定，时而无动力，时而动力下降，那么驾驭这个测试环境进行性能测试的人将会非常痛苦。在笔者以前的性能测试经历中，就曾经出现过测试环境中的模拟器时而正常工作产生正常的数据，时而停发数据，时而效率下降，其直接结果就是大大影响了正式性能测试的项目进度，很难得到准确的性能测试效果。因此，一个追求精益求精的性能测试工程师，应该用尽一切方法，确保性能测试的环境能够非常稳定，仔细地调试性能测试环境中的每个模拟器。如果物理连线环境有问题或设备有缺陷，则一定要事先准备好备用方案，绕开这些问题，来保证性能测试环境的稳定。如果性能测试工程师觉得只是保证性能测试环境的长期稳定还不够体现其精益求精的精神，则可以努力将性能测试环境再改造成一个半自动化测试的环境。一个半自动化测试的性能测试环境将会大大帮助提高性能测试环境的使用和搭建的效率，同时也