软件测试求生法则

.了解测试类型 29
面对挑战的应对措施 33
提高管理层对培训的关注 33
抽出时间参加培训 34
提高个人能力 36
认证你的测试技能 37
实践障碍 37
成功指南 38
行动计划 39
第四章 挑战9 与开发人员建立良好的关系 40
概述 40
案例分析 40
对测试的影响 41
对测试进度的影响 42
对团队士气的影响 43
面对挑战的应对措施 44
采纳双赢的方法 44
扩展测试视野 45
从"我们对他们"转变到"我们和他们" 45
实践障碍 46
成功指南 48
行动计划 49
第五章 挑战8 无工具测试 50
概述 50
实践问题 50
对测试的影响 51
面对挑战的应对措施 57
使管理人员了解测试工具 57
进行工具调查 58
定义需求 58
进行投资/收益分析 59
调查工具来源 59
在测试过程中集成测试工具 60
实践障碍 60
成功指南 61
行动计划 62
第六章 挑战7 使管理人员了解测试 64
概述 64
案例分析 64
对测试的影响 65
测试管理的反对意见 66
测试管理的战略性观点 68
面临挑战的应对措施 69
确定管理层中的干系人 70
增加测试功能的影响力 70
增加与其他企业的交流，借鉴他们处理类似的问题的方法 71
明确测试工作目标、制定测试章程 71
定义可以衡量的测试目标 71
测试工作的负责人要深入了解测试工作的本质、问题和挑战 72
定义测试流程 72
实践障碍 73
成功指南 74
行动计划 75
第七章 挑战6 与客户保持交流 76
概述 76
案例分析 76
对测试的影响 77
面临挑战的应对措施 79
团队协作 81
沟通 81
持续参与 83
用户满意度测试 84
实践障碍 85
成功指南 86
行动计划 87
第八章 挑战5 分配测试时间 88
概述 88
案例分析 89
对测试的影响 90
测试范围缩小 91
出现"回归错误"的可能性增加 92
测试人员疲劳，士气低落 92
面临挑战的应对措施 93
控制测试范围 93
控制管理层对测试的期望 93
基于独立评价标准设计测试用例 93
进行风险评估 94
重用测试系统 94
基于可衡量的标准估计测试工作量 94
使用自动测试 95
实践障碍 95
成功指南 97
行动计划 97
第九章 挑战4 测试"扔过墙"的软件 99
概述 99
案例分析 99
对测试的影响 101
面临挑战的应对措施 102
在定义角色和责任时争取领导层支持 102
建立测试标准和流程 102
定义开发人员的所有权和义务 103
训练开发人员成为优秀测试者 103
增进开发人员和测试人员之间的交流 104
持续评估和改善流程 104
建立基本测试原则 104
实践障碍 105
成功指南 105
行动计划 106
第十章 挑战3 满足不断变化的需求 107
概述 107
案例分析 107
对测试的影响 109
面对挑战的应对措施 110
更新软件测试系统 111
使用模块化方法设计测试脚本 111
对已经测试过的软件进行回归测试 111
快速变化带来的问题和机遇 114
实践障碍 114
成功指南 115
行动计划 116
第十一章 挑战2 解决两难问题 117
概论 117
案例分析 117
对测试的影响 119
公司的流程成熟度很难提高 119
削弱测试流程的效率和重要性 119
使测试人员丧失士气 120
导致对测试的错误观点 120
面临挑战的应对措施 120
与公司其他成员交流、确定测试在项目中的位置 120
确定测试人员可以完成的合理测试范围 121
确定和管理客户对软件产品的期望 121
实践障碍 122
成功指南 124
行动计划 124
第十二章 挑战1 学会如何说不 126
概述 126
案例分析 126
对测试的影响 127
测试报告是你的朋友！ 128
面临挑战的应对措施 128
标准化测试报告 129
在测试流程之中集成测试报告 130
管理"观众"的期望 130
采用创造性的报告方法 131
强调事实 131
保持诚实正直 132
记录你的测试 132
营造成熟的企业文化 133
实践障碍 134
成功指南 135
行动计划 135
第十三章 制定优化测试的行动计划 137
确立改变的信念 137
采用正确的方法 139
第1步 确定变化范围 140
第2步 确定优化目标 141
第3步 制定计划 141
第4 步 获得支持 142
第5 步 监督和衡量变化 144
第6步 奖励参与者 145
优化测试是永无止境的挑战 146

.　　本书将着重介绍测试人员1可能会面临的力不能及的十种挑战。对测试人员1而言，学习掌握测试人员2的"其他"能力所面临的最重要、最基础的问题是首先明确这些能力的必要性，进而通过有效的使用它们来提高软件测试的效率。
　　
　　"人际"因素挑战的根本来源
　　软件测试涉及许多变化的因素，它不能被简单的看成一个单纯的、高度可重复的过程。实际上，整个测试过程需要根据被测系统的不同进行相应的调整。软件测试这种变化的实质使与他人合谐地工作变得极为重要。
　　下面让我们分析一下影响软件测试过程的五种变化因素，如参考图1.2所示。
　　● 开发过程
　　● 软件风险
　　● 客户参与
　　● 测试流程
　　● 测试人员的技能
　　开发软件可以遵循多种不同的流程。从随机的、极不统一的流程到结构化的、可预期结果的流程，软件开发流程可以划分为多种成熟度级别。如果开发流程是比较成熟的、可以预期结果的，测试人员就可以更好的进行测试，因为在测试以前他就已经能够全面了解开发过程的长处和弱点，进而着重对弱点可能导致的缺陷进行测试。
　　被测试软件的风险可以从高到低进行分级。软件工程领域有许多种风险模型可以用来进行分析，但它们的基础都是相似的，即那些涉及大笔资金流动的系统、对企业成败起决定性作用的系统、以及规模庞大同时结构复杂的系统使用的软件，被视为是高风险的。
　　显然，相对于低风险的软件，测试人员应该将更多精力放在高风险的软件上。质量保证协会（QAI）的研究结果表明，客户和终端用户的参与是影响软件发展流程效率最重要的因素。更多的参与有利于降低软件开发的成本，同时提高软件质量。在较少用户参与的条件下开发出的软件更容易遇到诸如客户不满意之类的问题，因为在开发过程中软件极少有机会直接面对客户和终端用户，进而缺少及时的用户反馈和设计改进。软件测试人员受益于较多用户介入的软件开发流程，因为被测试软件通常都会有相对较好的设计质量。
　　与软件开发流程相似，软件测试流程也可以从随意、极不标准到高度结构化、协调统一进行分级。软件测试流程的随意性越大，测试人员有效开展工作的难度也就越大；相反，如果测试过程比较规范，测试人员就可以更多的依赖流程本身发现缺陷，提高效率。
　　软件测试人员的个人能力对软件测试过程有显著的影响。因为对不同被测系统的测试流程不尽相同，而且测试流程通常也不会被十分详细地记录在文档之中，所以测试流程一般不会详尽包括那些有经验的测试人员熟知的工作步骤。这就要求根据测试流程进行测试的必须是一些具备一定的专业能力的人员。退一步讲，就算有详细的文档描述软件测试，如果测试人员能力不足、或没有接受过系统的培训，他仍然不能有效的利用这些文档进行测试。
　　以上只是列举了影响软件测试的五个典型因素，而不是全部。实际上还有其它许多因素可以影响软件测试，如测试工具是否充足、有效；测试预算；测试日程安排；来自管理层的指导以及测试人员的工作态度等等。
　　对于每个软件系统，这些影响因素都是连续分布并且可以量化分级的。例如，如果软件开发过程比完全随意要稍微规范一些，我们就可以将其定位在25%参考点上。类似的，软件风险、客户参与、软件测试流程、以及测试人员能力都可以被看作是连续分布的，可以被分级评定。
　　对这些影响因素的分级评定可以为测试提供一个系统基准，用来指明与该被测系统相关的"人际"问题的性质与程度。通常评分越靠近左边，出现"人际"问题可能性就越大，换言之，如果各个因素的评分都靠近左边界，这个被测系统
　　● 是相对随意的开发流程的产品
　　● 高风险
　　● 整个开发过程缺乏用户参与
　　● 使用的测试流程不规范
　　● 测试人员缺乏专业素质
　　所以测试人员在测试过程中遇到"人际"问题的可能性很大。
　　
　　测试人员面临的十大"人际"挑战
　　近些年来，我们花了大量时间和精力来发展测试流程，撰写有关测试的书籍和新闻组，以及举办各种培训班来教会人们如何进行测试，而所有这些都基本集中在测试人员1的能力上，即软件测试工作本身。但是，测试人员所面临的最棘手的问题看起来却来源于如何与周围的人和谐相处，而这正是测试人员2的强项所在。通过与上百个软件测试人员的交流，我们确定了软件测试面临的十大挑战，它们无一例外都是与人相关的。下面我们将根据它们的难度给出这十大挑战的简单介绍。首先介绍相对最容易的解决的，最难的放在最后。本书第3章到12章会更详尽地探讨这些挑战并推荐应对措施。第2章介绍评判软件测试当前状态的自我评价材料，你可以用它评价自己对这十种挑战的理解程度和软件测试工作的现状，以更有针对性地阅读以后的章节。
　　● 挑战10 获得软件测试培训（评价类别：软件测试培训）
　　测试人员通常没有接受过任何有关测试的培训。测试人员面临的挑战是在根本没学过如何测试的情况下进行测试。大部分测试人员都参加过软件开发流程的培训，而这里面涉及软件测试的通常只有开发流程结束时的一句话--"顺便提一下，完成开发以后就可以开始测试了"。在1996年QAI建立起软件测试人员的通用技能体系和相应的认证程序以前，我们甚至连一套基本的测试知识体系都没有，尽管有些个人对测试有些自然的想法，但测试工作需要的知识和技能不是与生俱来的。软件测试人员是培养出来的，绝不是天生的。
　　● 挑战9 与开发人员保持良好关系
　　（评价类别：建立开发人员和测试人员组成的项目团队）
　　在很多企业中，测试是一种"我们对他们"的精神斗争，而测试人员通常都会被看成扰乱产品开发的"坏家伙"。只要整个软件生产流程被人为划分成软件开发和测试两个部分，这种类似敌我斗争的关系就会存在。而解决它的方法只有一个，即建立由开发人员和测试人员组成的统一的项目团队，使成功和失败都不会只归咎于开发与测试之中的某一个，而是"有福同享，有难同当"。
　　● 挑战8 无工具测试
　　（评价类别：测试工具）
　　从实践角度来看，测试不象是一个工程门类，倒更象一门手艺。人们对任何能想到的问题进行测试，大部分情况都会涉及大量的重复性劳动。有时候，即使软件测试工具是现成的，而且也被测试流程明确地要求使用，实际的测试工作仍然不使用这些工具。软件测试人员面临的挑战是在不使用工具的情况下，进行那些可能会涉及成千上万数据的测试。随着被测系统越来越庞大、越来越复杂、更新的速度越来越快，不使用测试工具就进行测试已经是不可能的了。
　　● 挑战7 使管理人员了解测试
　　（评价类别：管理介入软件测试）
　　信息系统的经理们对测试几乎从来不感兴趣，认为测试是那种不得不做、却没有任何创造性和不值得花精力去做的事情。在某些企业中，员工被派去做测试简直就是一种惩罚。花在开发和测试上的时间、以及测试人员与开发人员收入水平的差距都说明经理们的这种态度。但是，如果缺乏管理人员在时间和金钱上的投入，有效的管理测试是根本不可能实现的。一种最极端的情况是许多经理人将他们对测试的投入简化成一个字--钱，因为对他们而言任何没有投入的事情都只是说说而已。
　　● 挑战6 与客户保持交流
　　（评价类别：与客户和用户的互动）
　　正确因对这个挑战需要首先确定客户和终端用户，并对他们进行区分。客户对软件测试的兴趣来源于他们是软件的购买者，是整个软件开发的资金来源；终端用户的兴趣则源于他们是软件的最终用户。出于不同的目的，他们的兴趣所在是大不相同的。客户着重于软件可以满足产品目标、支持所需的功能；而终端用户则对软件的可用性和易用性更为关心。软件测试人员应该尽可能了解客户和终端用户的情况，鼓励他们参与软件的开发和测试，并将这种交流很好地保持下去。
　　● 挑战5 分配测试时间
　　（评价类别：为测试制定计划和预算）
　　软件测试人员经常会因为他们被定位于推迟软件投产和上市的位置而承受很大压力。在最初制定的项目计划中确实为测试分配了的时间，但开发人员总是为满足额外的需求而将这些时间用的所剩无几。而且测试工作也总是没有足够的人手来做。解决的方法是让测试人员也参与制定项目计划，同时要将需要测试的各个部分划分好优先级，以确保即使时间紧迫，那些针对最重要部分的测试也可以正常进行。
　　● 挑战4 测试"扔过墙的"的软件
　　（评价类别：开发人员与测试人员的沟通）
　　通常测试人员与开发人员之间几乎没有任何交流，开发人员完成开发以后，将软件"扔过墙去"，供测试人员进行测试；当测试结束时，测试人员又会将结果"扔回墙那边"，要求开发人员解决测试发现的问题。战胜挑战4就意味着测试人员必须与开发人员直接交流，而非"住在墙两边，老死不相往来"。从项目开始就建立起来的有效而持续的交流实际上对"墙"两边的开发人员和测试人员都有利。
　　● 挑战3 满足不断变化的需求
　　（评价类别：建立测试标准）
　　这项挑战是有关变更管理的。多数情况下，我们无法保证在项目启动时就拿到完整而准确的产品需求，它会随着项目的进行而不断发生变化。这就意味着测试人员要尽力"打移动靶"来满足变化的需求。同时，软件测试本身的技术环境也可能随着项目的进展而发生变化，这就要求测试人员要不断修正测试标准来适应各种变化。除非测试标准和测试计划总能够随着需求的变化及时更新，否则测试人员就可能"瞄准错误的靶子"，用过时的标准来测试最新的系统，结果只能是白费时间和精力。
　　● 挑战2 解决两难问题
　　（评价类别：对可接受的质量级别达成一致）
　　测试人员经常会在软件质量问题上面临两难问题，一方面，如果他们报告说软件的质量不符合要求，则会被指责拖延的产品的发展计划；另一方面，如果他们认为产品质量过关，可以投产，一旦产品在使用过程中出了问题，他们又会被指责没能及时发现问题--失职。解决这个问题的最佳方法是明确地定义和区分开发人员和测试人员对软件质量和系统可靠性各自应该承担的责任。
　　● 挑战1 学会如何说不
　　（评价类别：信任测试人员的测试结果和意见）
　　软件测试人员面临的最大"人际"挑战是如何告诉开发人员和客户软件存在质量问题、问题的具体信息、软件的当前状态、以及他们关于如何解决问题的意见和建议。糟糕的是，在报告坏消息时，测试人员一般都会成为大家的"敌人"。解决这个问题的方法是事先明确定义测试人员的角色和责任，定义测试结果应该如何报告给开发人员和客户，以及如何描述系统缺陷，如何提出合理建议以改进系统性能等等。
　　
　　如何使用本书
　　本书将帮助你正确分析和面对测试人员面临的"人际"挑战。下面的三个步骤会有利于你有效地使用本书。
　　● 步骤1 通过完成自我评估来分析你在软件测试"人际"挑战方面面临的问题
　　第2章提供了很好的自我评估材料，你可以用它来发现自己的弱点所在，并将它们与上面介绍的十大挑战联系起来。
　　● 步骤2 学习如何面对并克服你及下属的弱点
　　以自我评估的结果为基础，你可以有针对性地阅读第3章到第12章。这些章节将分别详尽地描述上面介绍的十个挑战，如何解决它们、以及如何实践解决方案等。第3章到第12章基本都遵循下面的结构。
　　1. 概述：描述本章的概貌；
　　2. 案例分析：通过简单而恰当的案例分析，说明本章介绍的人际问题在测试环境中的实际表现。
　　3. 对测试的影响：说明本章介绍的人际问题对测试工作可能产生的影响。
　　4. 面对挑战的应对措施：这是每章的核心内容，我们将逐个介绍解决问题的一个或多个方法。
　　5. 实践障碍：这部分通过提出诸如"如果发生，我怎么办？"之类的问题，说明如何处理在实践解决方法时可能会遇到的问题。
　　6. 成功指南：介绍一系列有效的步骤以最大程度推进解决问题的进程。
　　7. 行动计划：介绍解决问题的具体行动计划。
　　● 步骤3 制定解决问题的行动计划
　　基于第3章到12章给出的方法、指导和计划，最后一章（第13章）介绍了一套行之有效的战术计划来帮助你面对最困难的人际挑战。通过实践这三个步骤，你可以全面地了解你和下属所面临的软件测试"人际"挑战，并制定出一套行之有效的解决方案。然后，你需要将这套方案付诸于行动。在方案实施若干月以后，建议你通过重新进行自我评估并比较评估结果来了解你的测试工作是否得以优化，并根据实际情况对行动计划做出调整。