软件测试与质量保障之间的关系

 

　　这篇文将讨论测试人员日常工作，及怎样将质量灌输到软件中。我们将先讨论什么是软件测试，什么是质量保障，它们之间如何关联?软件测试和质量保障涉及到哪些日常工作，有哪些问题点和领域可改善，以及作为一个测试者，如何在任何软件开发生命周期中，都能对开发过程提供价值呢。

　　什么是软件测试?

　　软件测试是分析者用来发现软件缺陷的有组织的过程。你可能会问，什么是缺陷?缺陷是代码中导致软件应用中断的问题。没有任何软件是完全无缺陷的，测试者的目标是减少在项目中找到的缺陷，并且将质量灌输到软件应用中。软件测试包括检验软件不能满足用户需求规格说明中描述的需求及不能满足用户所需的过程。软件测试者通过分析软件来获知软件是否符合用户的期望。软件测试是一种设计来适当保障软件符合用户所需质量的活动。

　　什么是质量保障?

　　质量保障是恰当的确保软件过程在有效的方式下，被有条不紊地被执行的所有活动的汇总。它涉及到正确的做测试和做正确的测试。软件质量保障检查软件过程是否正确且符合组织内部运作的标准。质量保障涉及到软件测试外更多的内容，但软件测试依然是质量保障专业需要的内容。缺了它，就不能称保证质量保障过程是正确妥当的。它们之间如何互相关联呢?

　　就如你看到的，软件测试只是软件质量保障的一个方面。软件测试通常被称作为质量控制。在组织中，质量控制是质量保障计划中的一个组件。在一些组织中，软件测试角色从质量保障分析师角色中被剥离出来。在这样的组织中，软件质量保障涉及到完成技术检查列表和文档评审以检验软件和文档均能符合标准。

　　软件测试和质量保障的日常任务

　　软件需求规范一旦被产出，测试人员就“测试”文档确认需求是否完整、正确、一致，和可被测试。在一个敏捷的环境中，软件需求一旦编写出来就会被测试。在瀑布式的软件开发生命周期中，软件需求规范先被编写出来，然后测试它的完整性、正确性、一致性和可测试性。完整性通过需求是否能告诉你在哪里测试、如何测试及要测试什么来衡量。正确性意味着你知道要测试的应用的一些方方面面。你必须对你要测试的软件有些了解，才能知道需求是否正确。一致性是指需求中不存在逻辑缺陷。可测试的需求是指一份你可以为它编写测试案例的需求。

　　在需求评审之前或之后，一个主测试计划会被编写，包括介绍、背景、范围、缩略语、定义、将被测试的特性、不被测试的特性、约束、假设、风险和意外、日程表、角色/责任、和参考。主测试计划被测试团队用来决定测试工作将被执行多长时间。测试人员也使用主测试计划作为测试计划。介绍、背景、范围、术语、定义和参考是测试计划的前序。它们简述项目的背景，预期的读者是谁及项目的确切定义是什么(包括哪些内容和不包括哪些内容)。缩略语简要描述了测试计划中使用到的缩写。定义章节定义了在测试计划中使用到的新术语。参考章节列出了建立测试计划用到的文档资料。典型情况，测试计划引用了软件需求规格和软件设计文档。“将被测试的特性”章节包括所有软件需测试的功能特性的列表、性能需求、可用性需求、和安全需求。“不被测试的特性”章节包括不会被测试的特性。约束和假设章节鉴定出有那些会影响到项目和软件测试的因素，也包括任何项目所持有的基本信念。约束也表述了软件项目所受的限制。在风险和意外章节，所有的风险和意外处理计划及缓解策略一起被表述。没有人喜欢讨论风险，但是这应该是在规范项目计划时，最先的被讨论的问题之一。风险分析是缓解软件开发固有的风险的方法之一。风险分析是处理每个需求涉及到的风险的重要性和优先级的一个系统过程。日程表章节讨论测试活动发生的时间。角色/责任章节简述了谁负责交付什么。最后的一个章节是附录章节。章节之间通常并不是按照我所描述的顺序，但列出的内容已经包括了主测试计划的最主要的那些部分。

　　在需求评审结束后，测试人员开始依照软件需求规格写测试案例或用例。用例记录系统如何和多种角色进行交互，而测试案例的编写更加具体得多。依照使用的方法，一个测试案例或者用例文档被产出。我们假设测试人员编写测试案例。在测试案例文档中，测试者通常要放入描述、测试步骤、期望的结果、实际结果、通过/失败结果和屏幕截图。在测试已经开始以后，屏幕截图是一个用于证明测试已通过的必要附件。测试步骤通常也叫做测试脚本。为了简化问题的描述，这里我们假设采用的是手工测试的方法。迟一些，我们会转向自动化测试的讨论。

　　接下来，作为工作成果中正式评审的一部分，测试案例文档和主测试计划一起被提交评审。基于评审产生修订后的版本。所有的关系人需出席评审会议，包括需求分析师、开发人员、测试人员、项目经理。如果有一个独立的执行软件质量保障的分析师角色，他(她)也被要求参加评审。讨论每一页的文档，找到是否需要作出一些修改，或需要阐明一些问题。一旦问题被记下来，测试人员基于正式评审来修订主测试计划和测试案例。问题将被跟踪直到被关闭，并通过其它批准工作产出的会议制定决策，或者通过email处理工作产出评审。

　　测试人员还需要产出一个绑定软件需求规格到软件设计文档和测试案例文档的跟踪矩阵。在需求和测试案例之间最少需要建立一对一或者一对多的映射。在一些公司，质量保障分析员/测试人员还需要评审软件设计文档，确认每一个需求都已经在软件设计文档中进行了说明。用这种方法，测试人员能完全确认每一个测试案例可以跟踪到一个需求，及每一个需求可以跟踪到一个软件程序、选项，或者菜单。可跟踪性是一个软件测试过程里的关键质量属性。

　　在代码的开发完成且构建分发到测试人员手中时，实际的测试开始了。针对应用执行每一个测试案例，成功/失败结果被记录下来。同时，用屏幕截图截取结果 。 任何缺陷都被用缺陷跟踪工具(例如Rational ClearQuest、Mercury Quality Center或其他缺陷跟踪工具)记录下来。缺陷跟踪和缺陷解决需要有一个适当的过程。典型情况下，当测试人员在测试跟踪工具中记录一个缺陷，如果可能要包括测试的阶段、主题、问题的描述、重复的步骤及屏幕截图。问题的描述需要记录需要修正的错误是什么和错误在什么地方，而不是一条讨论的记录，因为没人能去确定那是否一个问题。我曾看到SharePoint站点被用来做缺陷跟踪。当这样的一个站点被使用，当缺陷被发现时，需要记录测试的阶段。甚至当你使用Rational ClearQuest和Mercury Quality Center，也要根据组织中使用的软件生命周期的类型来确定是否记录测试的阶段。

　　根据缺陷的严重性，需要修正找到的缺陷，并为此建立一个新构建。测试人员重新测试缺陷来确认它已经被修正，然后在缺陷的功能区域执行一个轻量的回归测试，确认没有其它问题被引发。一旦测试人员通知团队内容测试已经完成，依赖于软件开发生命周期，代码被作为产品发布，或根据需要发布到测试网站上做现场测试。如果测试网站发现有缺陷，将缺陷报告给开发团队，新的构建将被发布，然后先经过内部测试，再发布到测试网站。缺陷像以前一样被记录下来。

　　自动化测试

　　在自动化测试中，一份自化测试计划被编写出来，用于概述自动化将如何执行及被选中的测试方法。它可能是被用来完全替代主测试计划，又或者仅和主测试计划一起被编写。一旦文档被编写后，自动化测试脚本开始对应软件需求规格和需求研究文档中的需求进行编写。在构建被分发后，测试脚本针对应用运行来检查是否存在问题。如果确实是一个缺陷，那么缺陷被用和手工测试一样的工具记录下来。依赖修改的数量和严重程度，一个新的构建被分发，并再次针对应用运行自动化测试脚本。一旦测试人员发现已经不存在缺陷，他/她可以报告测试已经结束，构建已经可以成为产品。

　　可改善的问题点和领域

　　1、建立对软件质量保障测试人员的信任——我的一个开发经理有一次告诉我，项目经理需要很长时间才会信任测试人员。幸运的是，我碰到了这种特别的情况。但是让开发团队信任测试人员将会尽职尽责去执行工作有可能是困难的。那意味着，他/她将找出或揭露所有关于项目相关的事和可以帮助他或她完全测试项目的编码。很多时候，通过增加交流，并向项目经理和开发者解释为何要执行这些特别的活动，这个问题可以被克服。

　　2、开发人员不相信软件测试和质量保障的价值——测试人员会经常面对着和开发人员冲突的情形。 通常来说，这来自一种已过时的想法，测试人员并不知道开发人员所做的事或者没有人能测试系统。可事实是，测试是一种技能，而且人们花费了很多年来完善测试软件产品。有些时候，测试人员只有依赖于让一个有地位和背景，更资深测试人员去告诉开发人员，让他们去看测试人员发现的问题。

　　3、测试时间不足——很多时候，仅仅是项目计划中没有足够的时间进行充分的测试。一个解决这个问题的办法是在需求被编写时就同时测试它，并在需求被编写时，就构建测试案例。另外要做的事是找一个能够评估项目和分发日期的人。另外，在软件开发项目中，人员常规例会有助于鉴别出关键人物。

　　4、糟糕的需求撰写——有时候，需求没有被正确的捕捉，并在软件开发项目过程中需要修订。这种情形对于组织和测试团队的钱和时间都会有耗费。这种情形会导致范围渐增(Scope Creep)，从而使分发的代码超过需求中所编写的内容。对此问题，并没有一种真正的解决方案。最好的方法是当发现范围渐增发生时就即时制止。一个方法是通过获得用户在软件需求规格上的签字，预先使得决策变得稳定，这样范围渐增就不会发生。另外一个制止它的办法是，有一个变更控制委员来批准软件需求规格变更。改由变更控制委员来对费用超支负责。这避免了项目经理由于范围渐增而遭责难。

　　5、没有足够的测试资源——这个问题是需要高层去处理的情形。当没有足够的测试资源，它会影响到时间表，并且会导致那些过少的测试项目的测试人员们筋疲力尽。

　　6、测试人员没有足够的培训——这种情形会导致测试人员不能理解正在测试的软件。它会影响到需要的测试时间和涉及到测试成果的金钱。

　　7、计划将来的测试成果——当正在进行当前版本的测试时，同时进行下一个计划的版本的时间制定，这个问题会浮出。对于测试人员来说，正确的评估时间和将获得测试效果是困难的。

　　8、和开发人员讨论的时间——有些时候 ，没有足够的时间和开发人员讨论一个问题，当这发生时，会导致经常的传达错误。给开发人员打电话，并且将问题显示给他们看，比将问题通过电子邮件发给他们，并且在反复的邮件中捕捉问题要更容易些。

　　9、应对人的挑战。Randall W. Rice和William E. Perry写了本书叫《在软件测试的10大挑战中存活》，在这本书中他们写下了以下一些测试人员的日常交互中需要面对的挑战：

　　测试人员面对的10大来自人的挑战

　　挑战1：必须说不——当你正在测试当前应用时，你必须说出你没有足够的时间去测试其它应用。

　　挑战2：和不断失去的情形做战——这意味着很多事，但是经常是指组织的内部政策或是否组织对测试有支持。

　　挑战3：击中在移动中的目标——这常常指项目开始后，需求持续不断增加。这种情形通常指范围渐增。

　　挑战4：测试从墙那边扔来的东西——这通常指没有合理的过程来防止开发人员简单的将没有经过单元测试的代码交来测试，或将这些代码放入一个干净的构建中。

　　挑战5：花时间去测试——这通常指有充分时间去测试，回到我们先前申明的，你需要为测试计划时间，并更早和更频繁的执行测试。

　　挑战6：和客户及用户交流——通常指要确保开发团队宝库测试人员分发正确的产品给客户和用户，并为客户和用户提供不间断的培训支持。

　　挑战7：向管理者解释测试——一些管理者仅是不理解测试，测试分析师的工作之一，是对为何他要做正在做的事情要有充分的理由。

　　挑战8：没有工具的测试——这里与人相关的挑战是为购买工具获取足够的支持，及论证为什么需要工具。换句话说，挑战是如何促成购买测试软件的方案。

　　挑战9：建立与开发人员之间的关系——这里与人相关的挑战是培养和开发人员之间的关系，因为多数测试人员与开发人员紧密的在一起工作。

　　挑战10：获得测试相关的培训——在第3章中Rice和Perry写到：没有培训，相当于测试人员是坏掉的设备，要去适应测试的精密，特别是在技术困难的情形更是如此。后面与人相关的挑战是确保获得对于培训的足够支持。

　　为开发过程增添价值

　　无论组织使用敏捷开发方法或者传统的瀑布式或者迭代式开发方式，测试人员都能为组织增添价值。他/她增加了组织对于软件被正确构建和构建正确的软件的自信。这增加了组织的软件开发方法的效果与效率。组织如果没有测试团队和个人测试员工会导致不合适构建的软件、被缺陷折磨的软件，及超出预算并波及到组织的其它领域。简单的总结，在组织中没有测试的团队，所花费的会超过带来的利益。大多数测试人员会仔细和彻底的对待他们的工作，并且能找到那些不轻易显现的暇疵，因此增加了以前不存在的品质。更有价值的是，多数的测试人员拥有更好的沟通技巧，可以在客户和开发人员之间搭建起桥梁。在这点上，一些开发人员不能有效的和客户的社区和员工进行交流，因为他们不能解释他们正在努力去做的事。因为测试人员可以为开发团队管理测试站点并组织用户接受测试，所以测试人员这里作为一个关键的角色为交流者们进行服务。

　　最终结论，当测试软件时，测试人员每天都面对着挑战。它们其中的一些是来自企业固有的文化，但另外的来自对于测试人员的角色和他们实际工作的错误概念。这份文章试图解释测试人员工作的不同方面，及他们如何适应组织。文章试图解释了手动测试方法和自动化测试方法的不同。有一些类似性，有一些不同处。软件测试人员有很高的价值，软件测试也是IT产业很好的一个专业。