一、(What)是软件测试

　　软件测试是一个确认和验证软件应用或软件程序的过程。主要确认和验证以下几点：

　　1.软件应用或程序是否符合用户需求

　　2.软件应用或程序是否符合引导它设计和开发的技术要求

　　3.软件应用或程序是否如预期中工作良好

　　软件测试通常可以发现程序代码中必须修复的严重错误或问题，之所以用“严重”这个词语，是因为我们都知道在软件测试过程中必须给每个发现的错误赋予一个相对应的严重性级别。 在测试的计划过程中，我们是通过审查需求文档和设计文档来决定什么是重要的缺陷。在审查文档的过程中，我们努力寻找一个问题的答案，这个问题是“这个应用程序主要面向的用户是谁?”一般来说，一个重要缺陷是从客户角度可以影响到应用程序的可用性或功能应用性的问题。在桌面仪表板上采取交通灯颜色的照明计划可能是在需求定义中不费脑子就可以想出的主意，而且在设计中也很容易实施。但实际上未必完全可行的，如果我们在测试中发现该应用程序的主要业务赞助商是色盲。突然间，它就会成为一个重要缺陷。(事实上，约8%的男性和0.4%的女性都会有一定程度或一定形式上的色盲。) 软件开发的质量保证方面有一些书籍列举出开发人员应该遵循的开发标准流程或非常好的做法，这在本文中就不一一详细列举了。保证软件质量不全部都是测试团队的责任，测试小组无法提高质量;他们只能衡量，虽然说目前存在一种争论：如果在编码之前设计测试可以提高软件质量，因为开发人员可以利用这些信息来思考自己如何设计代码以及调试程序。 软件测试有三个主要的目标：核查、验证、发现缺陷。

　　? 核查过程：证实该软件符合技术规范。一个“规范”是一个描述功能的条款，对特定先决条件下一个具体的输入值输出的可度量值进行描述。一个简单的规范实例“通过SQL对单一用户帐户的多月帐户汇总表进行查询检索并返回八个数据域，将返回的数据按月份排序。”

? 验证过程：证实该软件满足业务需求。一个简单的例子，一个业务需求是“通过选择一个分支机构的名称，分行的客户经理的相关信息将出现在一个新的窗口，例如该窗口提供对该经理客户群的简要说明：<list of data elements>“。其他业务需求对如何归纳并格式化显示数据提供更详细的说明。

? 缺陷是预期结果和实际结果之间的差异。该缺陷的最终来源可追溯到上文中提到的规范，软件设计或程序编码阶段。

　　二、为什么(Why)要测试软件

　　“聪明的人解决问题，明智的人避免问题”—Albert Einstein 为什么要测试软件? “要找到错误!”是本能的反应。许多人，包括开发商和程序员在内，认为在开发过程中进行调试和代码审查就可以找到和修复错误，从而认为正式的测试是多余的。除非“千年虫”的出现确实是代码引起的，软件测试的重点是发现最终产品的缺陷。 以下是一些严重的缺陷，如果更好地测试肯定会在产品投入应用前发现。

　　? 2003年2月，美国财政部寄出50000份社会安全检查书却没有受益者的名字。一名发言人说，名字的缺失是由软件程序维护错误造成的。

　　? 2001年7月，一个严重的缺陷在长期用于跟踪美国核材料的系统软件中被发现。该软件最近已被捐赠给另一个国家，那个国家的科学家发现了软件的这个缺陷并且告诉了美国官员。

　　? 1999年10月，美国宇航局1.25亿美元的星际气候卫星在太空中由于数据转换错误丢失。经调查发现，软件对航天器进行某些计算时在该应用公制单位“米”的时候却错误采用了英文单位“码”。

　　? 1996年6月，第一次飞行的欧洲航天局阿丽亚娜5号火箭发射后不久就失败了，从而造成保险损失$500，000，000。这场灾难是由于在64位整数转化为16位有符号整数时缺乏对浮点错误的异常处理。
软件测试可以回答代码审查和调试无法回答的问题：
? 软件真的如预期中那样工作吗？
? 软件满足了用户的需求吗？
? 它是用户所期盼的产品吗？
? 用户会喜欢使用它吗？
? 它与我们的其他系统兼容吗？
? 它的性能如何？
? 它能承受多少用户的访问量？
? 软件中的哪个组件需要更多的工作投入？
? 软件已经可以发布了吗？
有了以上问题的答案，我们可以做些什么？
? 尽早发现缺陷，节省时间和金钱。
? 避免或减少开发的滞停。
? 因为有了比较好的应用程序，我们可以提供更好的客户服务。
? 知道我们已满足用户的要求。
? 为后续版本做必要的修改和改进。
? 识别和分类可复用的模块和组件。
? 识别出程序员和开发人员在哪些方面需要培训。

　　三、测试什么(What)?

　　首先，测试最重要的。专注于核心功能—关键或者流行的部分，专注于比较常用的用户应用场景。例如，如果应用程序检索数据和性能是重要的，首先专注于测试通常负载情况下的合理查询，这个优先级要比测试负载高峰期要高。值得再强调一次：专注于最重要的。好的业务需求会告诉你什么是重要的。 软件测试的价值是它远远超出测试程序的基本代码，它还审查应用程序的功能行为。行为是代码的功能，但它并不总是遵循“行为是‘坏’的-〉代码是‘坏’的”这个规则。完全有可能的是，代码是牢靠的，但需求是不明确或由于沟通不充分导致信息不完全。应用程序正在做我们告诉它做的事情，但我们并没有告诉它做正确的事情。

　　一项全面的测试制度检查应用程序相关的所有部件。甚至，测试提供了一个机会来验证和核实某种假设情况被加入需求时系统能否正确的运行以及相对应的手册和文档。更可能的是，除非您的组织有真正的“软件工程”(想想洛克希德·马丁，IBM公司，或SAS研究所)，工作的重点将会是应用程序本身的功能和可靠性。 测试可以涉及部分或全部的下列因素，越多，越好。

　　? 业务需求

　　? 功能设计要求

　　? 技术设计要求

　　? 监管要求

　　? 编程代码

　　? 系统管理的标准和限制

　　? 企业标准

　　? 专业或行业协会的非常好的做法

　　? 硬件配置

　　? 文化问题和语言差异

　　四、(Who)做测试?

　　软件测试不是一个人的工作。它需要一个团队，但团队的规模可以根据被测程序的规模和复杂性可大可小。如果可能，写该应用程序代码的程序员在测试过程中不该承担重要的角色。原因是，他们已经如此密切地参与该产品，可能无法采取公平、公正的态度来看待他们的劳动成果。 测试人员必须谨慎，好奇，严格并不武断，并且具有良好的沟通能力。他们工作的一部分是发现开发人员自己可能发现的软件缺陷，不能为此故意让开发人员尴尬，甚至侮辱开发人员。例如：

　　? 程序怎么会如此运作?

　　? 你说“它正常工作”是什么意思?

　　? 你怎么知道它没问题?有什么证据?

　　? 采取了什么方法使程序看起来似乎可以正确工作，但实际上却有缺陷存在?

　　? 采取了何种方式使它似乎没有工作，但却真正的工作?

　　? 怎么可能会导致它不工作呢?

　　一个好的开发人员并不一定会成为一个好的测试人员，反之亦然，但测试人员和开发人员都共享至少一个主要特征，他们渴望让自己的手在键盘上舞动。 急于开始可能会导致重要的设计工作被忽略，微妙的情况也许会被错过。象代码审查、测试设计审查这样的过程都值得投入时间和精力进行理智的检查。 测试人员是IT人员中唯一从业务方面以使用该系统为重的专家用户。用户测试几乎无一例外地招募很多新手商业用户，原因是软件产品最后要由这些商业用户使用，所以可以让这些商业用户在产品被正式发布之前对系统进行一些测试。不过，新手通常不具备专家用户具有的商业经验，他们可能无法发现和意识专家用户可以发现的问题和错误。IT部门中的测试人员必须发现只有专家用户才能发现的缺陷，因为专家在发现缺陷后，如果觉得这个问题不值得他们花费太多的时间和努力，他们有可能不会向有关部门报告这个缺陷和问题，这就要求我们的测试人员具备专家的能力来挖掘软件中存在的问题。 软件生产过程中的关键人员以及他们的角色 商业赞助商和合作伙伴 √ 提供资金 √ 指定业务需求和交付的相关事项 √ 审核变更和测试结果 项目经理 √ 计划和管理项目 软件开发人员 √ 设计，编码，搭建应用 √ 参加代码审查和测试 √ 修正错误，缺陷，和缺点 测试协调员 √ 基于用户需求、功能以及技术文档来 创建测试计划和测试规范 测试人员 √ 执行测试并记载测试结果

　　五、什么(What)是软件测试的V模型

　　软件测试是如此的重要，绝对不能留到项目的结尾才进行。软件测试的V模型将软件测试融入到了整个软件开发生命周期。如下图中的V模型，V曲线由下及上、由左向右地描绘了软件开发和测试活动的基本顺序。该模型重点突出了不同级别的测试过程的存在并表示出一种关系：每一个级别上的测试过程都对应于一个不同的开发阶段。

　　软件测试应该在项目一开始的时候就开始进行。在需求收集阶段，用户需求可以通过验证和审核业务案例来对项目进行评价和衡量。同时，用户需求也可以用来指引UAT---用户接受性测试。模型阐述了每个后续阶段是如何来考核和验证前一阶段已完成的工作，也阐述了在开发阶段完成的工作是如何被用来指导单个测试阶段的。这样的交互关系让我们可以在产生严重后果之前就识别、判断出重要的错误、遗漏和其他的问题。

    

　　六、什么(What)是测试计划

　　测试计划是一个强制性的文档。你不能在没有测试计划的情况下进行测试。“美国国家标准学会和电子工程师协会标准829/1983的软件测试文档“中指明，在软件测试计划中应该涉及到以下内容。
       

　　测试计划可以减少风险 一个新项目的发布和升级之后通常伴随一定程度的风险，即不能完成一些预期功能。好的测试计划旨在减少这种风险的存在。确定哪些区域是高风险的区域后，我们可以对此区域重点进行测试。不仅要测试这些领域必须具备的功能而且还要测试在哪些领域里技术人员是缺乏经验的，例如利用复杂的ETL逻辑来实时加载一个网页表单的内容到数据库中。因为风险较高的区域需要更多的测试工作量来保证其工作的正确性，未能准确识别高风险的区域会使测试工作量分配不合理。

　　我们如何识别风险区域?问问大家的意见!从开发人员，销售和营销人员，技术文档写者，客户支持和用户那里收集信息。市场上类似的产品或产品以前版本的历史数据和测试报告都可以帮助确定哪些区域值得进一步的探索和研究。来自客户的缺陷报告是重要的，开发商自己提出的错误报告也是很重要的，这些资料深入到了技术领域，也许对我们找寻高风险区域能提供帮助。 IT方和商业用户此前对如何应对发现的问题而达成共识是很重要的，包括对缺陷严重性级别的定义法。对缺陷的修复工作应该把重点放在最重要、最严重的问题上。下面是在企业/商业应用中非常普遍应用的一套划分类别：在一个系统中，级别'1'是最严重的，‘6’则是几乎没有造成什么影响，一个缺陷的类别

　　应被准确衡量和选择。 1 阻碍-因为缺陷太严重而无法继续测试。 2 严重-测试工作可以继续进行，但直到此缺陷修复，应用程序才能发布。 3 主要-测试可以继续，但如这一缺陷修复之前将程序投入应用将会导致与业务需求的严重偏离。 4 中等-测试可以继续，但如这一缺陷修复之前将程序投入应用将会导致与业务需求的少许背离。 5 小-测试可以继续，缺陷不影响产品的发布。缺陷应该被更正，但这一缺陷不会造成与也许需求的偏离。 6 建议-产品改进的一些建议，如颜色，字体和大小。这些都不影响测试工作，也不影响产品的正式发布。有一种情况例外，如果这些功能都是重要的业务需求时，这些问题将应被分配较高的严重级别。

　　七、总结

　　软件测试是软件生命周期里的重要因素，好的软件测试将我们带来缺陷少的软件，进而带来众多好处，如节约产品开发耗时，减少产品成本，提高用户满意度。遗憾的是，软件测试在很多公司或者很多项目里是不正式的，主要原因是项目成员对软件测试的基本理论、方法和工具不是很熟悉。针对这种现状，本文围绕着3W—what，why，who介绍了软件测试的一些基本理论和术语。

　　参考文献和资源

　　? Better Software magazine. Free issue at http://www.zinio.com/offer?issn=1532-3579f&of=PF01&bd=1

　　? Ergo/Gero Hhttp://www.ergogero.com/FAQ/Part4/cfaqPart4.htmlH (information on color blindness)

　　? Goldsmith， Robin F. (2002). Software Development Magazine， 4-part series， July-October. Information on the V-Model is at http://www.sdbestpractices.com/documents/s=8815/sdm0208e/

　　? International Institute for Software Testing. Hhttp://www.testinginstitute.com/

　　? Marrik， Brian. ”Classic Testing Mistakes” (1997) and “New Models for Test Development” (1999). http://www.testing.com/writings/writings.html

　　? Parasoft Corporation. “Automated Error Prevention”. http://www.parasoft.com/jsp/aep/aep.jsp?itemId=170

　　? Patton， Ron (2000). Software Testing.

　　? Software Engineering Research Network， University of Calgary， Alberta， Canada. http://sern.ucalgary.ca/~sdyck/courses/seng621/webdoc.html#Unit

　　? Software Testing Education Hhttp://www.testingeducation.org/coursenotes/H

　　? Vanderbilt University， MIS Application Services. “MIS Development Methodology”. http://mis.vanderbilt.edu/methodology/

　　? Wachovia Bank， Training Solutions (2004). Software Testing Fundamentals.