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

　　国标：

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

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

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

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

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

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

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

　　测试范围：

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

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

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

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

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

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

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

　　系统设计测试

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

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

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

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

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

可测性：

　　软件维护性由四个子特性组成：易分析性、易改动性、稳定性、易测试性。

　　软件可测试性通常是指软件发现故障并隔离、定位其故障的能力特性，以及在一定的时间和成本前提下，进行测试设计、测试执行的能力。这里摘录下《软件可测试性需求设计》一文中的几个重点评估指标，详细信息大家可查看全文：

　　● 可控制性设计需求

　　● 可分解性设计需求

　　● 稳定性设计需求

　　● 易理解性设计需求

　　● 可观察性设计需求

　　● 测试驱动和桩的设置

　　● 适合增量式开发的可测性设计

　　● 可查询设计

　　● 自愈合功能

　　● 输出结果

　　● 提供统一的操作执行面板

　　每一条都有具体的评估标准，衡量待测产品可测性的优劣可以据此参考，我不添油加醋了。另外我推荐一款google的开源代码可测性度量工具“Testability explorer”，有兴趣的同学可以试用下。

　　全过程测试：

　　产品研发过程前期，静态测试采用的越多，这是和待测产品的特性有关。大家都知道测试越提前，产品质量风险越小，各项成本越少。但要真正落实测试提前必须有个大前提，是测试工程师个人能力的不断提升。不具备相应的测试能力，有再好的测试方法测试手段也没用。

　　一个测试团队的成长，一定是从发现缺陷到缺陷预防，真正能做到缺陷预防的团队才是成熟的团队。上文所说的大多仍是发现缺陷，如何做缺陷预防本文不探讨，但只有测试提前，只有真正做到了全过程测试，才有看到缺陷预防成功的那。

　　测试手段多样化并不仅仅是多几个测试工具，更主要的是丰富测试思路。不同业务背景、技术背景的产品我们首先要能清楚应该如何下手，然后再看需要何种技术手段支撑。先有测试思路，然后寻求技术支持。而不是先搞个技术，然后再硬生生的嵌入现有的测试过程中。当然，技术储备是持续要做的。

　　后用一副很简单的图来表达我的测试理念：

小记：本文借用了不少前人的观点，原创较少。主题虽是测试手段多样化，但更多的是希望开展全过程测试。本文多次提到的，针对质量特性的各种测试方法，是明年规划之一，后续有成果会一一呈现给大家。大家明年见。