工作原因，看见一篇好文章，希望能在未曾通知原作者之前贴一下。如果原作者觉得不恰当，可以与我联系。
好的测试工程师应具备的素质
人是测试工作中最有价值也是最重要的资源，没有一个合格的、积极的测试小组，测试就不可能实现。然而，在软件开发产业中有一种非常普遍习惯，那就是让那些经验最少的新手、没有效率的开发者或不适合干其他工作的人去做测试工作。这绝对是一种目光短浅的行为，对一个系统进行有效的测试所需要的技能绝对不比进行软件开发需要的少，事实上，测试者将获得极其广泛的经验，他们将遇到许多开发者不可能遇到的问题。
①、沟通能力
一名理想的测试者必须能够同测试涉及到的所有人进行沟通，具有与技术（开发者）和非技术人员（客户，管理人员）的交流能力。既要可以和用户谈得来，又能同开发人员说得上话，不幸的是这两类人没有共同语言。和用户谈话的重点必须放在系统可以正确地处理什么和不可以处理什么上。而和开发者谈相同的信息时，就必须将这些活重新组织以另一种方式表达出来，测试小组的成员必须能够同等地同用户和开发者沟通。
②、移情能力
和系统开发有关的所有人员都处在一种既关心又担心的状态之中。用户担心将来使用一个不符合自己要求的系统，开发者则担心由于系统要求不正确而使他不得不重新开发整个系统，管理部门则担心这个系统突然崩溃而使它的声誉受损。测试者必须和每一类人打交道，因此需要测试小组的成员对他们每个人都具有足够的理解和同情，具备了这种能力可以将测试人员与相关人员之间的冲突和对抗减少到最低程度。
③、技术能力
就总体言，开发人员对那些不懂技术的人持一种轻视的态度。一旦测试小组的某个成员作出了一个错误的断定，那么他们的可信度就会立刻被传扬了出去。一个测试者必须既明白被测软件系统的概念又要会使用工程中的那些工具。要做到这一点需要有几年以上的编程经验，前期的开发经验可以帮助对软件开发过程有较深入的理解，从开发人员的角度正确的评价测试者，简化自动测试工具编程的学习曲线。
④、自信心
开发者指责测试者出了错是常有的事，测试者必须对自己的观点有足够的自信心。如果容许别人对自己指东指西，就不能完成什么更多的事情了。
⑤、外交能力
当你告诉某人他出了错时，就必须使用一些外交方法。机智老练和外交手法有助于维护与开发人员的协作关系，测试者在告诉开发者他的软件有错误时，也同样需要一定的外交手腕。如果采取的方法过于强硬，对测试者来说，在以后和开发部门的合作方面就相当于“赢了战争却输了战役”。
⑥、幽默感
在遇到狡辩的情况下，一个幽默的批评将是很有帮助的。
⑦、很强的记忆力
一个理想的测试者应该有能力将以前曾经遇到过的类似的错误从记忆深处挖掘出来，这一能力在测试过程中的价值是无法衡量的。因为许多新出现的问题和我们已经发现的问题相差无几。
⑧、耐心
一些质量保证工作需要难以置信的耐心。有时你需要花费惊人的时间去分离、识别和分派一个错误。这个工作是那些坐不住的人无法完成的。
⑨、怀疑精神
可以预料，开发者会尽他们最大的努力将所有的错误解释过去。测式者必须听每个人的说明，但他必须保持怀疑直到他自己看过以后。
⑩、自我督促
干测试工作很容易使你变得懒散。只有那些具有自我督促能力的人才能够使自己每天正常地工作。
11、洞察力
一个好的测试工程师具有“测试是为了破坏”的观点，捕获用户观点的能力，强烈的质量追求，对细节的关注能力。应用的高风险区的判断能力以便将有限的测试针对重点环节。
UML软件工程组织
--------------------------------------------------------------------------------
软件测试之我见
mume（转载自CSDN） 2002年09月16日
我做软件测试有一段不短的时间了，可大量的盲目测试几乎没有增长我的测试经验，每次测试前总有些茫然，不知道自己怎样才能有效的发现软件中存在的缺陷；测试后也不能肯定是否可以放心的发布被测软件。我想可能很多初涉测试的工作者都同我有相似的感觉，我们需要有关测试的理论知识的引导，以下是我读了一些讲解测试技术的书籍后的收获，以及我对我国当前软件业中测试这一领域的认识，希望也能给测试同行点滴的收益。
一、软件测试员的目标是尽可能早一些找出软件缺陷，并确保其得以关闭。
或许大家会认为软件测试员的工作目标是不言而喻的：就是找软件缺陷，然而《软件测试》这本书为软件测试人员提出了更确切的目标：尽可能早一些找出软件缺陷，并确保其得以修复。在阅读全书并仔细思考后，我觉得此目标包含三大点含义：
1． 软件测试员的基本目标是发现软件缺陷。
我觉得在这里有必要把这不言而喻的事实再次强调一下，因为有时产品的开发小组要测试员只是为了证实软件可以运行，而不是找缺陷。在这种情况下，测试人员也就缺乏不懈努力发现缺陷的探索精神和热情。所以我觉得在心里坚信不移的认为：软件测试员的基本目标是发现软件缺陷，是做好测试的首要条件。
2． 软件测试员追求的是尽可能早的找出软件缺陷。
因为软件的修复费用，随着时间的推移，将数十倍的增长，所以软件测试员应尽可能早的找出软件缺陷。对大型的软件，在软件开发的同时，就应该有紧随其后的测试，如果等到产品已经开发完毕才开始测试，非常有可能引起大量耗时费力的返工。而如何尽可能早的找出缺陷？《软件测试》这本书向我们介绍了一些理论上的测试方法：静态黑盒测试、动态黑盒测试、静态白盒测试、动态白盒测试；配置测试、兼容性测试、易用性测试……，怎样才能有效的用这些方法尽早的发现软件缺陷，需要大家在工作实践中不断的摸索、总结，进而不断的提高自己的测试能力。
3． 软件测试人员必需确保找出的软件缺陷得以关闭。
请注意，我们这里提的是软件测试人员必需确保找出的软件缺陷得以关闭，而不是要软件缺陷得以修复。我们软件测试员需要对自己找出的软件缺陷保持一种平常心：并不是我们辛苦找出的每个软件缺陷都是必要修复的。可能是由于没有足够的时间、不算真正的软件缺陷、修复的风险太大等原因，产品开发小组决定对一些软件缺陷不作修复。
另外，测试员对软件缺陷描述不清楚，也会使软件测试员发现的缺陷被忽略。所以我们测试员必须在描述软件缺陷方面狠下功夫：用简单明了的语句描述软件缺陷；每一件报告尽量针对一个软件缺陷，避免多个缺陷混杂在一起，以致其中一些被忽略或忘却；记录引出软件缺陷的操作步骤，使缺陷得以再现。
虽然我们软件测试员需要对自己找出的软件缺陷保持一种平常心，但同时又必须坚持有始有终的原则，跟踪每一个软件缺陷的处理结果，确保软件缺陷得以关闭。关闭软件缺陷的前提可以是缺陷得以修复或决定不作修复。而缺陷是否需要修复的最终决定权在软件的最终负责人，检查缺陷得以关闭的责任在测试人员。
二、测试一个软件最首要也是最重要的是测试其产品功能说明书。
1 概念
产品功能说明书：对产品最终需要实现的功能的描述。这些功能是最终确定的需要满足的客户需求，也包括是一些软件必须具备的能力。
在规范的软件生成的流程中，产品功能说明书应在用户需求评审会议召开后，进行系统的概要设计前确定。
2 原因
（１）很多软件的缺陷都是因为产品功能说明书不够全面，经常更改造成的；
（２）只有详细的阅读了产品功能说明书，确认产品需要实现的功能，才能拟定切实可行的测试方案；
3 方法
（１）参照需求说明书，检查产品功能说明书描述的产品将要实现的功能是否已经完整、准确、一致、合理的描述了产品的功能，并确保这些功能是可测试的
（２）研究产品说明书是否符合现有的软件设计开发的标准或规范；
（３）研究同类软件，预测产品的最终结果；
如果测试人员发现产品说明书不符合以上几点，该怎么做？
测试人员需要明白，我们的责任是反映产品的缺陷，我们不需要也不能修正产品，所以同发现软件的其它缺陷一样，在发现产品说明书的缺陷后，应该把它们如实并详细的记录下来，呈报给此软件的最终负责人，对并此缺陷的处理情况进行跟踪。
注意同发现的软件其它缺陷一样，缺陷列表应该呈报给软件的最终负责人，而不是给相关技术人员或技术主管，因为技术人员可能会以在技术的实现上有难度为推托，拒绝对缺陷的修改。
4 目前的可执行度
（１）很多软件在开发前并没有书面形式的产品说明书
目前我国的许多软件公司都是小型的手工作坊式的公司，在程序开发前都没有一个正式的、完整的、确定的产品说明书，即便是这种情况，产品说明书也是存在的，它存在在软件设计人员、项目负责人的脑海里，在他们心中都有一个软件的轮廓，假定了软件将要实现的功能。我们的测试人员可以在同他们的交流和不断的询问中获得这个非正式的产品说明书，值得注意的是在我们得到这些信息后还需要以书面的形式把它们一一列举出来，再向相关人员请教，最后做到能完整、准确、一致、合理的描述了产品的功能。
（２）测试人员一般不会在项目初期就参与项目
当前还存在着这样一种问题，公司一般不会让软件测试人员在项目的初期就参与项目，一般要等到软件的雏形出来后才会让软件测试人员着手进行测试。对这种情况，测试人员可以通过已经建立的软件的雏形，揣摩产品说明书，然后也是同上段所说一样，向相关人员请教，拟定一份书面的完整的、准确的、一致的、合理的产品说说明书。值得注意的是，测试人员在运行软件的雏形时，往往会发现一些软件缺陷，这时千万不要局限在这些缺陷上耗费经历，以致忘了拟定产品说明书的主要任务，一定要记住：测试一个软件最首要也是最重要的是测试其产品说明书，在产品说明书明确后，再制定具体的测试案例。
以上两点是指在公司体系不太正规的情况下给测试员的建议，但我认为要能更好的保证软件的质量，或许规范生成软件的整个运作流程更为有效：产品说明书由项目负责人来主持定版比较好，因为他把握着产品发展的方向；在产品说明书定版时的会议应请负责测试的人参加，使他们对产品有一个宏观的认识，我也不赞成测试人员过早的局限于某一项目，如果那样他们会觉得无所事事。
三、完全测试软件是绝不可能的，必须对测试的各项进行等价划分。
1 概念
等价分配：软件有无限的测试案例，我们要想办法把软件的相似输入、输出、操作分成一组，来使无限的测试案例减小到同样有效的小范围，这个过程称为等价分配。
边界条件：软件计划的操作界限所在的边缘条件，即如果超出这个边界条件，就可能会引出错误。
2 原因
输入量太大
输出结果太多
软件实现途径太多
软件说明书没有客观标准。从不同的角度看，软件缺陷的标准不同。
3 方法
（１）数据测试：
1） 确定输入的边界条件，对边界线上的及边界线两边的数据进行测试；
2） 边界线可能是2的乘方，默认值、空白值、零值等；每一个软件测试问题各不相同，可能包含格式各样边界的不同数据。
（２）状态测试（软件的状态是指软件当前所处的情况或者模式）
1） 每种状态至少访问一次；
2） 测试看起来最常见最普遍的状态转换；
3） 测试状态之间最不常用的分支；
4） 测试所有错误状态及其返回值；
5） 测试随机状态转换。
4 目前的可执行度
如果为了减少测试案例的数量过度进行等价分配，测试漏掉软件缺陷的风险就会增加。对初涉软件测试者，一定要请经验丰富的测试员审查预定的等价类别。