子系统X质量特性相对重要性举例
步骤6：建立要使用的测试技术
测试策略的最后一步包括测试规范技术的选择，这些技术用来测试已选质量特性的组合和子系统。高的重要性，就意味着该技术的使用，具有较高的涵盖范围或使用一种以上的技术，低重要性，意味着该技术的使用具有较低的涵盖范围和较少技术的使用。
在选择其中的一个技术时，也应考虑到其它各种因素，其中的一些因素列举如下：
要测试的质量特性
一个技术是适合测试一项质量特性还是多项质量特性。有些质量特性最好用一系列技术进行测试，其它质量特性适合用其它测试方法。
应用区域
有些技术非常明确的适合测试系统和用户之间的交互性（屏幕，报告，在线），其它的更适合测试系统的运行（批处理过程）。用于发现错误的技术和错误的类型是有关系的，比如：错误的输入检查，不正确的处理或者集成错误。
测试基础的可用性
每一种技术都来源于一定的测试基础。这可能是功能性的规格说明，技术设计，程序代码或终端用户组织的种类。但具体形式的测试基础也涉及到所选择的一种技术，例如：决策表，伪代码，结构化语言或非结构化散文。
形式化程度
非正式的测试规范较之正规技术，为测试者编写测试用例提供更大的自由度。
资源的使用
一种技术的应用要使用一定数量的特定资源，无论是人力还是物力。资源的使用直接与成本挂钩。
需要的知识和技巧
不是每一个测试者都掌握每一种技术。对于一些技术的有效运用，知道一些业务知识是必须的。而对于其它一些技术，较好的分析能力可能是必要的。所以，测试人员的知识和技能也影响了技术的选择。
基于实践的原因，一名测试者应尝试以最小的一套测试规范技术涵盖所有被选中的质量特性。
测试规范技术的选择必须在测试过程的较早阶段进行，这样测试团队在技术培训时能够采取适当的行动，也可以制订必要的检查单或者对具体情况的相应调整。
作为这一步的结果，用于每个子系统的技术将被定义。作为可选的，特别是在大型的测试项目，这项测试策略的最后一步是在这个过程中稍晚些时候实现，即在准备阶段。作为这项测试优先顺序工作的一部分，从而得以完成。此项活动的目的是为了尽早开始最重要的测试工作。
3) 测试过程中的策略
事先确定的测试策略，往往受制于较后阶段的测试项目。在这种情况下，测试经理往往要用较少的测试或者较短的测试来应付调整过的计划的要求。其后果主要出现在制定的策略的最后一步：一些测试突然就被取消了或者必须进行较浅深度的测试。测试经理用测试策略作为参考，可能需要与客户进行讨论，以确定哪些测试要删除或者在哪儿进行不彻底的测试。为了明确进行较少测试部分与风险评估的关系（在策略里转化为重要性层次），测试经理可能在测试阶段后，对增加的风险以原来的方式报告出来。所以不要改变步骤1至5，这是至关重要的：风险和重要性层次并没有改变。结果是，当测试减少时，该系统运行后将有更多的风险。
除了这些，在测试时还存在一种情况，就是系统的一部分含有过多的错误或者很少的错误。这两种情况下要实时的调整测试策略，也就是说要相应的增加或者减少测试工作量。与前一段提到的情况不同的是，在这里，当系统运行后，风险将保持不变。所做的修改概括如下：
在测试过程中寻找和纠正错误的成本要低于发生在生产过程中与错误有关的花费。
在“发现和纠正错误”事付出的更多的成本，而不仅仅是测试成本，发挥了作用；另外，要注意可能与延迟出货的产品有关的额外成本。“发生在生产过程中的错误”，我们应当计算它实际可能发生的机率：没有错误（缺陷）的错误是不会发生的！
4) 维护中的策略
开发一个新系统和维护一个系统所采用的测试策略，最主要的不同是错误发生的概率。当维护带来的变化作用于现存的信息系统时，这些改变就需要进行测试。在维护中将会带来新的错误风险，导致系统质量的下降。
在维护中隐含的不同错误机率，意味着为测试子系统相对重要性制定的策略可能有所改变：当一个有高重要性的子系统被开发时，可能在维护时没有什么改变。这里只存在回归发生而引起的风险，而测试重要性带来的风险很小。所以，为测试层次制定的测试策略，可以在“改变”的那一步，通过改变 “子系统”的概念来调整 。对于每一个变化，都要分析系统的哪一个部分发生了突变，哪一个部分可能会因为变化收到影响，哪一个质量特性与之相关。依赖于风险的每一个变化的测试，有各种可能性。
有限的测试，只着重于变化；
对已经变化了的功能的完全测试；
测试变化了的功能的连贯性以及与之相邻的功能。
应该把系统作为一个整体，进行一次回归测试。既然在这里进行回归的概率很高，测试的重点应该放在系统中变化了的和没有变化的部分的连贯性上。如果测试策略对新开发的系统是有用的，对子系统有关的重要性层次在这里可以派上用场。
除了改变的错误概率外，在系统开发和系统维护之间有更多的不同点。然而，它们对测试策略制定技术没有什么影响。这些不同的例子包括：
测试技术的丢失，不完整或者不切合时宜
在这种情况下，频繁的维修，对测试技术规范技术的选择有影响
可预见的对随发性情况的维护
大部分的维修情况是可以预见的，因此可以加以规划。策略的制定可以很容易的应用于这种类型的维护。而随发行情况的维护比较难，它的重点是纠正一个产品的突发错误，使系统尽可能快的恢复。在这里传统的策略要花费太多的时间。但是，得到一些测试策略有用的情景是可行的：如果程序X发生错误，然后被修改，怎么进行测试？这些情景支持一个最佳的测试方法来进行随发性情况的维护。
4、 结论
信息系统的测试，必须基于使用它的组织，实际使用软件时的商业风险而进行。实践中，测试经理常常采取措施，把来自测试覆盖率的风险，以一个直观的方式表示出来。本文中，明确了为定义一个测试策略需要采取的步骤。这种测试策略，为参与各方更好地理解提供了保障，同时创造了一个良好的协商测试深度的平台。
好的风险评估是这些步骤的一部分。认识到仅由测试经理或者测试人员来找出风险是不行的，这一点至关重要。而且有必要确认用户和客户组织的管理者，审计人员，项目参与人员，比如开发人员，测试人员，质量保证人员和项目经理等的参与。实践中，通过这种方法，可以使参与的各方以一种透明的方式，进行关于风险和相关测试策略的讨论。同时和用户交流，来协商测试的深度，以确定哪些元素该如何彻底的进行测试。
逐步定义的测试策略可以用于任何测试层次（例如系统测试，验收测试）以及一个整体策略（主测试计划），包括统筹和协调所有测试层次和检查/审查工作。
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。
