见到题目，你或许会想起电影《喜剧之王》中尹天仇所看的《演员的自我修养》一书，还有那句经典的台词：我是一个演员，跑龙套的也是演员！更会对影片中周星驰所扮演角色对梦想成为一名出色的演员而孜孜以求的情节记忆犹新。人们说行行相通，一通百通。我们这里就说说测试人员的基本修养。
代码编写，不可或缺
乔布斯说：Design is not just what it looks like and feels like, design is how it works（设计不仅是外形和感觉，设计关乎如何运作）。那么可以说测试亦是如此，测试不是简单地拿过来用一用。当开发人员将开发完成的软件提交到测试人员那里以后，测试人员首先需要做的是迅速透彻地理解软件的功能。你会说这是需求讨论阶段已经介入的工作，没错，但除了理想状况，很多时候是赶鸭子上架，容不得按常理出牌。或者你会说要先做版本验证测试（BVT）查看其可测性，但这都是理想状况。
而无论如何，你首先要搞明白提交过来的东西具备哪些功能以及是如何工作的？事先准备好满足测试需要的软硬件环境自然不必多说。开发经验的作用不光局限于对编码及相关技术的理解，还会使你更加了解开发人员的心理感受，从编码心理和工作习惯的角度，更好地弄懂软件是如何工作的。这一点多多少少有点儿只可意会不易言传的感觉。我在工作中切身体会到，有些朋友搞定编码的思路，可以使人强烈感受到一股强大的、严密的逻辑气息。那思路和风格从头到尾自成一体——气派、美妙，令人赞叹不已。
世界著名计算机科学家，1984年图灵奖获得者Niklaus Wirth提出“算法+数据结构=程序”。清代人薛雪所撰《一瓢诗话》中有：如此体会，则诗神诗旨，跃然纸上。那么我要说：如此体会，则码神码旨，亦跃然纸上。
全面深入，T型路线
T字型知识架构是指在细分领域细致专精，相关技术领域也要有所了解。测试人员真的需要了解相关技术吗？答案是肯定的。这里说的相关技术并非指测试相关，而是指开发所用的相关技术。说得再直白些，最好是懂得相关技术，甚至是该领域的技术专家。
我曾亲身经历过这样一件事情：在一个有着广泛市场影响的项目中，新版本发布增加了新的功能，在HTML页面中使用JavaScript来控制控件的显现。而发布时间紧迫，不允许有更多的时间使用正向用例来验证功能的正确性。尽管如此，我们也针对这小小的控件设计了将近百条用例。涉及的方面包括从页面的正反向跳转来验证控件的版本升级，到控件的跨域调用、浏览器的兼容、服务设置及干扰，如此种种，无一不需要通过了解相关技术，才能设计出有价值的用例。当然，有些有价值的用例来自于使用习惯，这可以说是很难有章可循的，需要靠经验的积累。最后，还要检查JavaScript文件内容是否正确。这样一来，最大限度地保证了产品上线后该功能点万无一失。
理清思路，有的放矢
很多人会认为，在测试工作中引入巧妙的编程技巧或者使用酷炫无比的技术手段，就代表测试水平高超。这种做法显然舍本求末，没有明白测试行为本身的目的。对于专业测试人员，这点误区可以理解，但不可接受。软件测试的目的，一方面是为了尽可能发现软件存在的缺陷，追踪直至解决这些缺陷；另一方面是为了度量被测试对象质量的优劣程度，对可能出现的问题从技术和其他方面采取相应的措施。两者都是为了降低潜在的商业风险。
一般来说，我们首先会根据软件系统本身的特点，其应用场景及开发人员等相关资源，去制订相应的测试策略，其中包括制订测试计划、分配测试资源、设计测试用例等。测试工作前期的大部分内容，不仅需要相关的技术知识，还包括更多的相关应用领域的知识和经验，以及分析能力。而这一切行为皆为降低产品潜在的商业风险所服务。诚然，使用优美的代码和酷炫的技术完成测试任务无可厚非，而无论如何，主旨不可偏离。
积基树本，夯实基础
好比说，找来一些帮手来垒墙，这自然不需要什么高深的建筑理论，但要做对整体工程进行把控的建筑工程师则需要读过建筑理论，掌握相关的基础知识。计算机科学领域中的基础知识，包括数据结构、操作系统、编译原理、数据库原理等。基础知识越是夯实饱满，也才越容易被融会贯通、结合实践从而得到宝贵的升华。数据库产品种类繁多，各类软件开发框架也层出不穷，而不变的永远是基础知识和基本原理。假如你明白高级语言应用开发学习的内容无外乎语法、框架和类库这三部分，学习起来自然不会眉毛胡子一把抓。
在计算机科学领域，如果涉及性能优化（时间复杂度、空间复杂度、数据库、操作系统、网络、并行计算、向量计算等）、复杂的数据结构、协议模型等特殊的问题，那么基础知识也就成了解决问题的必要条件。不用多说，作为专业技术人员，牢牢掌握这些知识是走向一流水平的不二法门。顺便说句题外话，这些基础知识同时也被看做试金石，可以帮助你进入一流水平的研发团队。
与人分享，谈吐有致
与人打交道，就难免涉及人际方面的事宜。沟通的技巧和方式自然是举不胜举，说上三天三夜也未必穷尽。所以在这里对此高谈阔论多少会显得有些捉襟见肘。但很重要且有效的一点沟通技巧可能会被忽略，那就是“不抱怨，找方法”。当团队之间、成员之间需要就某个问题进行交涉，甚至可能会发生争论乃至争吵时，最好少说多做，提出解决办法并且付诸行动。这里向大家推荐阅读卡耐基的《人性的弱点》以及费希尔的《沟通力》。希望能汲取其中的营养，完善性格的弱点，潜移默化地在无形之中大显神威。
一丝不苟，持之以恒
在软件测试的整个周期中，可能会出现一些不是总能重现的问题，这类问题的处理方式可大有讲究。从工程学的角度说，遇到这样的问题，不能及时找到原因而修复的话，需要降低该问题的优先级，等待再次重现，保留现场抓取的相关记录。这样既不会影响当前版本的发布，又毫无疏漏地追踪了曾经偶然出现的问题。某个问题一旦出现，是不能轻易放过的。既然不是总能重现，那如何证明此问题是否已经解决呢？当然，反复验证是重要的一方面。经过反复验证，其实还不能有把握地说这类问题已经修复。是不是心里还是没底呢？那就去看一看源码。
每天反复做一件事，坚持10年，任何人都会有所成就。当企业和项目负责人，等待你那封Test Signoff邮件发出的时候，你是否可以满怀信心地点击Send按钮呢？是否可以对发布前提交的版本做到胸有成竹，锦囊之中自有乾坤呢？百年三万六千日，朝着自己的人生目标，努力过好每一天。修养的形成不在于猛攻，而在于点滴的积累和润物无声地打磨。
文章来源：《程序员》杂志2014年1月刊软件测试
文章链接：http://www.csdn.net/article/2014-01-08/2818071-Tester
