软件测试手段的多样化

　　本文为分享会而准备，保持一年一次的传统，照例开篇公告诸位：下面会有大量个人思想，不喜勿看。

　　国标：

　　这东东真不想讲，涵盖的内容非常多，这里摘录几个主要质量特性，有兴趣的可自行查阅资料。

　　功能性：与一组功能及其指定的性质有关的一组属性。

　　可靠性：与在规定的一段时间和条件下，软件维持其性能水平的能力有关的一组属性。

　　易用性：与一组规定或潜在的用户为使用软件所需作的努力和对这样的使用所作的评价有关的一组属性。

　　效率：与在规定的条件下，软件的性能水平与所使用资源量之间关系有关的一组属性。

　　维护性：与进行指定的修改所需的努力有关的一组属性。

　　可移植性：与软件可从某一环境转移到另一环境的能力有关的一组属性。

　　测试范围：

　　测试范围的确定过程其实就是测试需求分析的过程，如何进行分析呢?

　　如果是新系统，列举所需实现的功能，从每一功能的起点(入口)出发，需要经过多少步操作多少交互才能达到功能终点(数据提交，数据展现……)。在此过程中每步操作每次交互均可看成一个节点，我们并不关心节点与节点之间的上下文关系(那是场景法要考虑的)，我们关注的是需要经过多少节点多少条路径才能从起点到达终点。这些节点、路径就是我们的测试范围，也就是我们的测试需求。

　　如果是老系统改造，列举出所有的改造点，注意，是改造点不是影响点。从改造点的源头出发，需要经过多少节点、路径才能达到改进目标。这些节点、路径就包含影响点。但是，如果改造点无法准确评估怎么办?对系统进行优化，开发都不知道要改多少处代码怎么办?常规解决方式有以下三种：

　　业务关系分析：通过产品业务分析大概会有多少功能需要修改。这种方式需要对同类型业务进行长期维护。优点是对于大多数测试工程师而言效率比较高，缺点是范围不够精准。

　　代码依赖分析：通过代码间的依赖关系分析有多少关联代码需要修改。这种方式精度有所提高，但效率大大降低，特别是在对产品代码不熟悉的情况下实施起来会很吃力。

　　代码静态扫描：通过代码扫描查找类似代码片段以确定修改点。这种方式误差比较大精度不会太高，同时效率也一般，仍然需要不少人工分析工作。

　　以上方式均是治标不治本。那治本的是什么?代码重构。说白了这是软件维护性差的问题，注意，维护性由四个子特性组成，其中就包含可测性。那么我们要做的是在系统设计、代码实现阶段，对产品的维护性进行全面评估。具体如何评估本文不做详细论述，后续有专门文章进行介绍，下文会有少量涉及。

　　系统设计测试：

　　一句话，测试设计的过程就是对系统设计进行测试的过程。

　　好吧，就说一句估计会被扁。

　　记得在2009年，部门做了次测试方法大PK，过程轰轰烈烈，结果嘛，怪可惜的。PK过程中对测试设计如何做有很多争论，但核心思路高度一致，进行UML建模。通过建模梳理测试思路，通过图形明确待测产品的测试流程，此过程中我们的待测产品有哪些?需求、UC，还有就是系统设计(更多指的概设)。当然，与开发人员不同的地方是，在建模过程中，开发更多考虑的是如何实现，测试更多考虑的是此实现是否合理，并会思考具体用何种测试手段去支撑测试思路，同时对可测性会进行评估。另外补充一点，测试用例设计也是测试设计的一部分，不要分开。至于测试人员针对待测产品如何进行建模本文不做论述，大家可自行查阅资料。

　　测试有个经典概念：V&V，验证与确认，验证产品已实现的功能是否正确，确认产品是否正确实现了功能。其中验证过程主要集中在产品实现后，确认则贯穿全程，尤其是在产品建设前期，确认过程显得尤为重要。在确认过程中要针对产品各项质量特性进行全面评估，例如针对软件维护性，可通过质量检查表(比方说编码规范)对待测产品进行评分，还可以通过“90-10测试” 来衡量。具体方式有很多，本文不具体描述了，后续会有专门文章进行系统介绍。

　　看到这里也许有很多人会说，“我一直就是这么做的啊，原来我一直有对系统设计进行测试”。没错，你一直都在做，可惜你一直都不知道，知道自己为啥不知道吗?

原文转自：http://www.uml.org.cn/Test/201201042.asp