谈软件测试资产的存储

在当今的测试领域，如何存储测试资产是绝对不能轻视的事情。关注以下两个重要因素有助于制定正确的策略：1）避免测试资产存储中几个常见的误区，2）设计能够满足测试团队对测试资产处理的最佳存储过程以及实现有效的工具支持。本文简要阐述了如何做好上述的两个因素。

　　大多数成熟的测试团队都会针对存储测试资产的常用需求制定各种策略。这些策略要考虑到测试资产的访问、限制必要的访问人员、以及确保资产不会丢失，还要考虑针对单个特定资产所需的具体存储需求，以证明该资产的存在并保持它的可用。很少有团队能够确保他们的存储方法在操作过程中不会存在任何问题，也很少有团队成功制定出最适合他们自己的高效存储过程。怎么确保在操作存储活动中不面临这类问题，在很大程度上取决于如何去避免几个常见的错误。设计高效的存储过程依赖于团队资产自身的具体需求以及存储这些资产所使用的工具，本文讨论了一些可以帮助实现这一目标的建议。

　　误区一：使用测试资产一览表

　　测试团队所面临的第一项艰巨的挑战是：让所有人都知道在哪里可以找到哪些资产。大多数团队采取的措施是，为新成员提供一份测试资产文档的一览表。然而，这基本上不是很有效果。有两个原因，第一，通常这种资产列表是一次性形成的并且很少更新，这意味着列表上的内容随着时间的推移越来越不准确；第二，老成员通常不会访问这种列表，因此资产列表会渐渐被遗忘。

　　最好的解决方法就是建立并持续维护一个资产地图（根据需要经常更新），有策略地将其放到所有人可以看见的地方，例如：显示在团队门户网站上、粘贴到办公室墙上等。资产地图要能够告诉每个团队成员两件重要的事情：第一，在哪里可以找到与他的角色相关的资产；第二，他应该将他的工作产物存储在哪里。

　　误区二：正规的存储方式不是很重要

　　无论何时，都不应该使用非正式的方式或者不按照规定的方式来存储测试资产。例如，网络共享文件夹、测试计算机、团队成员正在使用的台式机或笔记本电脑以及其他非正规方式都应避免。这些方式，限制了更广泛且必要的人群访问或使用资产，鼓励了测试过程中信息孤岛的存在。

　　误区三：同时使用多种存储工具能够确保测试资产不丢失

　　当存在多种方式来存储测试资产时，应只明确规定使用的存储方式（仅选择一种）并强制执行。例如，一份培训手册可以同时存储于版本控制工具和文档共享工具中；当这两个工具都可用时，通常情况下会同时使用两种工具来存储文档。但是，应避免这样做而是明确仅使用一种工具并遵照执行（在这种情况下最好使用文档共享工具）。对一份资产创建多个来源仅仅比丢失资产稍好一些，因为资产的冗余存储很可能会导致错误的副本（过期版本、不完整版本等）。

　　误区四：存储的测试资产越多越好

　　测试团队不应存储不属于他们的资产。例如，需求、应用程序版本等资产是测试团队所需的，但测试团队并不负责它们的可用性。真正要做的是：通过建立共享过程，使测试团队能够在正确的时间获得正确的资产。另一个类似的错误认识是存储过多的内容。不再使用的测试资产应该存档或者被清除。报告、沟通记录等不需要显式地存储，尤其对于那些很容易从测试管理工具、邮件服务器等地方导出来的资产。测试日志的有效存储期应该限制在使用它们进行分析的时间段内。存储过多的东西可能会引起很多问题，例如：不易查找到重要的资产以及不必要的开支。

　　建立最佳存储过程

　　存储过程是一个由一系列规则和惯例组成的框架，它通常是由一个团队制定的，并规定了重要的资产应如何存储以及在哪里存储。下表提供了不同测试资产的恰当的存储方式。这些方式都是从业界的最佳实践中收集来的。尽管这些方式有助于测试团队建立可靠的测试资产存储过程，然而建立最佳存储过程并不像表中所讲的那么简单。最佳存储过程并没有统一通用的模式。很多具体细节都决定了一个团队对最佳的定义，如：团队资产所需的存储容量，一定时间段内资产容量的预期增长情况，资产存储所需的工具和使用许可，组织目标和约束等。

　　选择适合的测试资产存储工具

　　测试资产存储工具的选择应该是尽量从测试团队、项目团队和组织（依照此顺序）中选择已有的工具。有时，尽管利用现有工具并不能实现大幅度的优化，但也不应仅由于存储测试资产的需要而购买工具。构建自定义工具或使用免费软件可能不承担购买费用，但需要考虑到如工作量、培训等间接费用。例如，虽然一套测试管理工具是用于存储测试用例的最佳途径，但不应该仅仅由于存储测试用例的唯一目的而购买一套测试管理工具。相反，使用项目团队的版本控制工具就足够了。在没有其他的策略时，一个最佳的存储过程应满足"方便使用"的原则，即从有利于使用该资产的人员的角度出发。例如，测试管理工具和自动化工具本身提供的版本控制功能都可以用于存储自动化测试的脚本；由于自动化测试人员通常使用自动化工具来工作，因此即使在测试管理工具可用的情况下，也应该选择自动化测试工具来存储测试脚本。

测试资产	存储方式建议
测试活动的项目计划	应与设计、编码等其他项目活动的计划共同存储。应利用内容发布工具...
估算结果	应利用内容共享工具
测试策略/主测试计划/其他测试计划	应利用内容共享工具
工作指南文档、模板和表单、行政表单	这些文档应该可以从公司网站、内网或门户网站下载。（维护下载链接）
工具评估报告	应利用内容共享工具
测试用例/测试数据	应利用测试管理工具
测试结果	应利用测试管理工具
缺陷	应利用缺陷管理工具
测试报告	应利用测试管理工具
日志/缺陷调查报告等	日志应明确保存期限，并定期清理。 缺陷调查报告附在缺陷管理工具中相应的缺陷中。
自动化测试脚本	应利用自动化工具提供的存储库或版本控制工具。
自动化功能库（Automation functional library）	应利用自动化工具提供的存储库或版本控制工具。
自动执行结果	应利用自动化工具提供的存储库或版本控制工具。
数据库文件、脚本等	应利用版本控制工具，最好与被测应用程序使用同一个版本控制工具。
培训手册	应利用内容共享工具
审计规程/日志和报告	应利用内容共享/发布工具
测试实验室访问和账户申请等表格	应利用内容共享工具

QA测试员需要掌握的新技能：脚本和安全

是时候成为一个QA测试员了。

　　这是4月28日至5月3日，在奥兰多市上STAREAST 2013会议上反复听到的一句话。讲演者一个接着一个地敦促测试专业人士接受他们的角色，作为软件生产的关键角色，但也会因为组织的业务而变。

　　对此主题的讨论的版本很多，但无论是哪一种，所有讲演者都传达到相同的元信息：质量保证（QA）专业人士需要承担起领导的角色，在对应用进行计划时，而不是只是等待测试需求，这些测试需求并不会对业务制做出好的软件。

　　总而言之，这给一群专业人员加深了对新工作的印象，曾经认为此工作只是对漏洞的修复，在软件发布之前找到最后的缺陷。

　　但这是现实：随着他们的职业声望的提升，软件测试人员需要一组惊人的技能，来交付他们所要求的所有。他们有这些技能或资源来获得这些吗？

　　在STAREAST之前的文章中，我写了关于开发领导力和管理技能方面的文章，从而获得成功。在本期的质量阶段方面，我来看看两个技术技能集合，这两个技能是现在的QA测试人员不能没有的：脚本和安全测试。

　　测试自动化脚本技能

　　虽然没有必要成为成为编程人员的上上等，但所有的测试人员都要学会编写一些代码。原因很简单：自动化测试会一直在那，而使用这些工具需要QA专业人员编写在测试中执行的脚本。

　　位于费尔吉尼亚州，费尔法克斯郡的软件咨询公司的CEO Jeff Payne在STAREAST演讲中指出了这点，测试在测试驱动的世界。公司希望雇佣那些会自动化的测试人员，而那些缺乏这种技能的人就不会优先考虑，他说。"所以要学习如何进行脚本测试，"他对听众说。"试一试脚本语言Ruby；但不要走错方向。"

　　在设置测试自动化的初期，脚本技能需求特别高。但是不要傻傻地以为一旦编写了第一组脚本后，需求就会消失，软件测试专家Robert Galen说，他是位于北卡罗来纳州，卡里的RGalen咨询集团的一员。有效的测试自动化需要QA专业人士不断地对他们是否做正确的测试集进行评估，而也要评估随着需求的变化，是否有能力编写新脚本，他说。

　　了解的关键是：自动化测试并不是一个全或无的命题。这只是QA测试的一个方面。人工测试一直以来也是有需求的，尤其是在进行检查进，如当应用程序产生错误信息时。在STAREAST Lightning Strikes的演讲中，Michael Bolton指出，"即使再大量的测试自动化也需要捕捉错误信息。"

　　安全大前景

　　还有一个领域是自动化测试帮不上忙的地方就安全。当听到"安全测试"这一词时，都会感到发抖，因为他们害怕他们会被要求深入挖掘应用和分析源代码。

　　没有人要求测试专业人士做这些。但是，越来越多的人要求他们承担起安全的责任，而且对于多数软件测试人员，这安全是一个全新的领域。

　　"现在安全确实很重要，" Payne在他的STAREAST演讲中说。与亲自实现代码的开发人员不同，软件测试人员擅长考虑应用开发从需求到开发的整个流程，这使得他们成为唯一个有资格进行基本安全测试的人，他说。

　　"攻击者想要从这个应用中偷走什么数据，他们将会采取怎样的方法来得到那些信息？" Payne说，这是一些关键问题，测试人员需要问一下他们自己。例如，全们应用指导基础的测试，从通过要求应用程序来验证用户输入的所有数据，而确保入口点是安全的。

　　在他的演讲中，Payne从来没有建议测试人员应用检查一下安全漏洞方面的代码。但是当我问一个测试员，她对Payne的安全建议有什么想法时，显然，她认为他只是给了建议。"安全测试是一项技术性技能；你必须关注代码——这对软件测试人员是不现实的，"测试管理说，她要求我不要提及她的名字。

　　我认为从她的评价中可以看到一个问题，这个问题是许多QA测试人员正在处理的："我怎么获得我的领域所需的技能？我能做一切别人要求我做的吗？"

　　作为一个专业领域，软件测试获得了尊重，这很好。但是软件测试人员是否具有这些技能，形成质的飞跃？他们怎么获得这些技能？

软件测试新技术的进展和应用

　　摘要：随着测试技术的发展和测试需求的扩大，自动化测试在软件测试中的优势越来越明显。本文通过对文献资料的阅读，介绍了自动化测试框架、自动化测试用例生成技术两种重要的自动化测试研究技术，对其目前的应用现状和实际使用情况进行了分析，提出了软件测试未来的发展趋势。 关键词：软件测试，自动化测试，测试框架，测试用例

　　1、引言

　　软件测试是软件质量保证的重要手段，通过软件测试可以发现软件缺陷，从而修改缺陷，提高软件的质量水平。软件产品的测试比硬件产品的检测要复杂得多，并且软件产品的测试不能充分利用检测工具，还需依赖测试人员的个人判断，对业务知识的掌握程度以及测试用例的设计能力，知识和经验。 随着计算机技术和软件技术的发展，近年来，软件测试在各个领域发挥着重要的作用。随着软件工程的发展，对系统化的软件测试技术和软件测试方法的研究也随之发展。软件测试从静态分析、动态测试等简单的查错行为发展成为系统化的工程行为。为了提高软件的测试效率，减少人员手工操作的次数，克服由于人员水平造成的测试差异，人们开始研究自动化测试技术。 本文通过对大量软件测试技术相关文献的阅读，分析了自动化测试框架、自动化测试用例生成技术两个软件自动化测试的热点问题，结合目前软件企业使用的测试工具，总结了软件自动化测试技术的应用现状和存在的问题，对未来软件测试技术的发展进行了展望。

　　2、自动化测试

　　随着软件系统规模的扩大和软件应用领域的不断扩展，软件系统的测试也变更越来越困难，传统的人工测试已无法满足人们的测试需要，虽然自动化测试不能从根本上解决问题，但其技术可以部分解决测试覆盖的问题和测试效率问题。 随着自动化测试技术的不断发展，自动化技术更加注重实用性、有效性和性能的不断提高，自动化软件测试技术同各种传统的人工测试技术相结合，大缩短了测试的时间和测试的开销，自动化测试已成为软件测试技术的重要研究方向。目前，自动化测试技术的主要研究内容包括：测试自动化框架、测试自动化脚本技术、自动化测试用例生成技术、测试自动化的预测、自动测试与可靠性分析、自动化安全测试技术等。

　　3、自动化测试框架

　　自动化测试框架模型的研究是为了使整个测试过程可以建立在一个框架模型之上，这些过程包括编制测试计划、安排测试活动、实现测试及检查和评估测试结果等。

　　3.1 基于程序结构的自动化测试框架

　　在文献中，作者提出了一种面向程序结构测试的一体化自动测试框架模型——C-ATFM模型。该模型是基于C语言的面向程序的测试框架，集成了自组织的环境，采用源码嵌入式的测试探针技术，模型包括5个模块。

　　1）语法分析器：用于对源程序进行分析，使用了有限自动机对正则表达式所表示的规则进行识别。

　　2）策略配置器：根据所要采用的测试方法来设计测试模型对测试活动的支持，使测试模型具有较好的适应性，对自动测试的有效性非常重要。

　　3）指令生成器：自动采集和分析程序结构的控制流信息，在测试策略的控制下，针对不同测试策略，计算程序动态测试过程，生成测试处理模块并插入到程序中，构成包含测试信息的被测程序，提交给仿真执行模块运行测试。

　　4）测试用例生成器：在自动测试过程中，为了尽量减少人工的介入，输入处理被实现为一个独立的模块，在需要时被调用，以模拟人工输入，为程序提供必要的输入数据。测试用例的自动生成技术也是自动化测试的一个重要的研究方向，将在后面的文章中进行介绍。

　　5）指令仿真执行器：提供测试框架内部的仿真执行环境。

　　以上测试框架是基于程序结构的测试方法，即主要被用于白盒测试过程中。

　　3.2 基于类的测试模型

　　面向对象的软件程序开发方法的出现，使软件测试者从传统的基于过程的测试转向基于类的测试。类的封装机制限制了对象对外部的可见性和外部以其的操作权限，而类的继承机制增加了软件测试的复杂性，多态和动态绑定为程序的执行带来了不确定性。由于以上问题的出现，人们开始讨论面向对象的软件测试模型。文献中给出了一种基于EDPN的类测试模型，作者基于面向对象软件测试的层次划分、测试方法，讨论了从UML图到EDPN图的转换，提出了一种基于EDPN的有标记的唯一输入输出测试用例的生成方式，并设计了基于EDPN模型的类测试模型。该模型可以通过唯一输入输出测试类的状态及状态转移；通过优化正交阵列测试类的交互；还可以通过生成协同路径方法测试类的层次。

　　4、自动化测试用例生成技术

　　测试用例可以定义为：①为了特定目标而设计的一组测试输入，执行条件和期望的输出结果；②为某一测试项记录的特定的输入、预测结果和一组执行条件。 软件测试用例生成是软件测试的核心问题，如何选择较好的测试准则，对提高测试用例发现软件错误的效率具有重要意义。

　　4.1 测试用例生成技术

　　软件工程技术对软件测试研究的影响表现在三个方面：软件开发过程模型决定了软件测试过程模型，软件体系结构决定了软件测试的层次划分，软件模型决定了软件测试用例生成方法。文献中提出了基于模型比较的测试方法，该方法将软件需求和软件实现转换为基准模型，通过比较得到需求模型和实现模型的差异，生成测试用例。文中采用了基于等价类的基于模型比较的测试方法和基于扩展有限状态机的基于模型比较的测试方法，并对两种方法进行了对比和分析。文献中针对不同的测试策略，设计了不同的测试用例自动生成的方法，其方法的设计和实现是基于程序规则说明的决策表技术。文中作者在其设计的自动化测试框架模型下，研究了基于程序规则说明的自动化测试技术，文中，作者采用了人工智能领域的问题求解方式，基于遗传算法的测试用例自动化生成技术和基于启发式学习的测试用例自动生成技术。文献的作者在给出基于EDPN的测试模型后，提出了一种基于带权EDPN迭代的面向对象系统的分割算法，以迭代的方法将面向对象系统分割成不同粒度而功能独立的测试子系统，并提出了基于组合EDPN模型的交互测试方法，解决了组合冲突和测试用例过多等问题。

　　4.2 测试用例集约简技术

　　测试用例集约简技术是生成最小测试用例集，最大限度地对软件进行高效率的测试，降低软件测试成本的关键技术之一。测试用例集约简技术也是今年来人们普遍重视和深入研究的话题。

　　早在1974年，文献的作者就提出了用于简化测试用例集的贪心算法。随着测试用例集约简技术的发展，文献提出一种根据测试用例的重要性来选择测试用例的启发式算法（H算法）。文献结合了贪心算法和启发式算法的借点为，提出了充分考虑剔除1-1冗余策略的简化方法。文献提出的测试用例选择方法把测试用例选择问题转化为整数规划问题，利用整数规划方法求出最优解。以上四种方法是测试用例集约简技术中的几种经典算法，目前，很多新的测试用例集约简算法都是对以上几种算法的改进和完善。如文献通过对传统的测试用例集约简技术的分析对比，提出了一种可在测试用例集简化期间，通过有选择性地保留测试用例来生成测试用例集的最小测试用例集生成方法。文献的算法允许保留在某个测试标准下的冗余，但在其他测试标准下不冗余的测试用例。文献则提出首先消除测试需求中存在的冗余，再对由该测试需求生成的测试用例集使用简化算法，得到无冗余的测试用例集。文献中，作者分别针对组合测试的最小测试集生成技术和基于测试需求集的测试用例集约简方法两个方面进行了系统深入的研究。文中，作者在系统地研究两两组合测试用例集的启发式生成方法基础上，对其进行有效改善和补充，提出了基于网络图模型和基于解空间树模型的两种新的测试用例集生成算法。另外，作者在系统研究多次单因素试验方法、均匀设计方法、正交试验设计方法等理论和应用的基础上，提出了软件测试的单因素覆盖方法、多因素覆盖方法等概念和相应测试用例生成方法。最后，作者给出了对软件系统进行全面测试的最小测试用例集生成框架，该框架可以有效地生成、管理、约简、分析和评估对软件系统进行全面测试的最小测试用例集。在文献中，所提出的软件测试用例生成技术也是运用正交试验设计法，应将其应用于一个简易的管理信息。

　　5、现状与展望

　　随着软件工程及软件测试行业的发展，软件测试更多的从手工测试转向自动化的机器测试，这样可以大大提高测试的效率，使人从反复枯燥的工作中解放出来。目前，大量测试工具的出现，使软件测试工作变得更加方便高效，但由于测试工具的使用对技术的要求不高，如自动化测试工具QTC已被测试人员广泛使用，LoadRunner更是压力测试离不开的工具，因此，对于这些工具内在所包含的技术却被测试人员忽视，测试人员更多的是根据测试需求去选择需要的工具，而对工具的具体实现方式知之甚少。而对于测试工具的开发者来说，自动化测试框架和自动化测试用例生成技术已成为自动化测试技术的两大关键研究方向。在这些测试工具中，不乏上文中介绍的各种技术的应用。例如用于C\C++语言单元测试的C++ Test，利用源代码扫描技术来提高代码质量的Klocwork等工具都具有与文献提出的测试框架类似的测试框架，这些工具直接访问被测试应用程序的代码，对其中的语句进行分析，输入各种测试数据，检查返回值，比较返回值与预期结果是否一致等。当然，所有自动化测试工具执行测试的过程中都需要生成测试用例，本文引用的所有文献中都给出了测试用例的生成方法。在我们使用工具进行测试的时候，测试用例已经被淡化，自动的测试过程中集成了所使用的测试用例，而我们在对结果进行分析时，可以查看到被执行的测试用例和测试用例的覆盖情况。这些测试工具使用了各种各样的自动化测试用例生成算法，为了提高工具的执行效率，测试用例集约简技术在工具设计过程中也是必需要考虑的内容。以我公司为例，公司没有专职的软件测试人员，软件测试工作由开发人员、事业部测试人员、公司测试人员三步完成。而事业部测试人员和公司测试人员大多是一人负责多个项目的测试，由于测试时间紧、任务重，而项目的复用情况也多，完全可以使用自动化测试技术进行测试。目前，我公司的测试用例是通过测试管理工具QC进行管理，其中存在大量冗余的测试用例，会造成重复测试，如果可以使用测试用例集约简技术对已有的测试用例集进行整理，可以大大提高测试效率，但由于现有的测试工具无法提供通用的自动化测试用例约简功能，或其功能不适用，迫使我们无法将这些技术直接应用于软件测试工作中。

　　软件质量越来越被人们重视，测试驱动的开发技术被人们所接受，软件测试已不再简单的是软件生命周期中的一部分。随着技术的发展，测试技术将被更多的应用于项目开发之中，而未来的软件开发更多的是以测试为目的的开发，通过工具的自动化测试功能，保证开发人员的代码质量和整个系统的质量。当然，自动化测试无法替代人工测试，但自动化测试可以帮助测试人员更快更好的完成工作，而对于测试人员，可能更多的是需要考虑如何持