软件测试架构师知识能力模型

软件产品为特定的任务和用户目标提供一组合适功能的能力

适合性

软件产品提供具有所需精度的正确或相符的结果及效果的能力

准确性

软件产品与一个或多个特性、系统相互配合的能力

互操作性

软件产品保护信息和数据的能力，以保证未授权的用户或系统不能阅读和修改这些信息与数据，而合法用户或系统不会被拒绝访问

安全性

软件产品符合和该功能相关的标准、规范、规则或特定的能力

功能性的顺从型

功能性

软件产品为避免因软件故障而导致失效的能力

成熟性

软件产品在软件发生故障或者违反指定接口的情况下，维持规定的性能级别的能力

容错性

软件产品在失效发生的情况下，重建规定的性能级别并自动恢复受直接影响的数据的能力

可恢复性

软件产品遵循与可靠性相关的标准、约定或规定的能力

可靠性的顺从型

可靠性

软件产品使用户能理解软件是否适合以及如何能将软件用于特定的任务和使用环境的能力

易理解性

软件产品使用户能学习其应用的能力

易学性

软件产品使用户能够操作和控制它的能力

易操作性

软件产品吸引用户的能力

吸引性

软件产品遵循与易用性相关的标准、约定、风格指南或法规的能力

易用性的依从性

易用性

在规定条件下，软件产品执行其功能时，提供适当的响应和处理时间以及流量（吞吐量）的能力

时间特性

在规定条件下，软件产品执行其功能时，使用合适数量和类别的资源能力

资源利用率

软件产品遵循与效率相关的标准或约定的能力

效率的依从性

效率

软件产品诊断软件中的缺陷、失效原因或识别待修改部分的能力

可分析性

软件产品能够被修改的能力

可修改性

软件产品不会因为修改而造成意外结果的能力

稳定性

软件产品已修改的部分能够被确认修复的能力

可测试性

软件产品遵循与维护性相关的标准或约定的能力

可维护性的依从性

可维护性

软件产品无需采用额外的活动或手段就可适应不同指定环境的能力

适应性

软件产品在指定环境中被安装的能力

可安装性

软件产品在公共环境中同与其分享公共资源的其他独立件共存的能力

共存性

软件产品在同样的环境下，替换另一个相同用途的指定软件产品的能力

易替换性

软件产品遵循与可移植性相关的标准或约定的能力

可移植性的依从性

可移植性

软件产品质量六属性

下面3个层层递进的句子，可以帮助我们来理解用户可靠性方面的要求:第一层:设备最好不要出故障;第二层:设备出现故障了不要影响主要的功能和业务;第三层:如果影响了主要功能和业务，系统可以尽快定位并恢复。

软件产品质量属性中的功能性是指软件产品在指定条件下使用时，提供满足明确和隐含要求的功能的能力。从功能性的定义来看，产品的功能并不像表面上看起来那么简单一除 了满足“明确”的要求，还有更深- -层的“隐含”的要求。“明确”+“隐含”才构成了用户对产品真正的、完整的功能要求。

软件产品质量属性中的易用性是指用户在指定条件下使用软件产品时，产品被用户理解、学习、使用和吸引用户的能力。这个能力，简单地说就是10个字:易懂、易学、易用、漂亮好看。易用性对消费类的产品显得尤为重要。例如我们在购买手机的时候，手机的外观是否漂亮，界面是否漂亮、好用会成为影响我们购机的一个重要因素;再如我们在下载一个移动应用后，很少有人会去阅读它的手册，这个应用能不能被看懂、好不好用往往成了决定这个应用能否继续保留在移动设备上的关键因素。

软件产品质量属性中的效率是指在规定条件下，相对于所用资源的数量，软件产品可提供适当的性能的能力。通常，效率就是我们常说的产品性能。一般性能测试考核参数：多（并发多少）快（速度多快）好（错误率多少）省（资源使用）。

软件产品质量属性中的可维护性是指软件产品可被修改的能力。这里的修改是指纠正、改进软件产品，和软件产品对环境、功能规格变化的适应性。

软件产品质量属性中的可移植性是指软件产品从一种环境迁移到另外--种环境的能力。这里的环境，可以理解为硬件、软件或组织等不同的环境。

软件产品质量模型

质量属性和测试类型的关系

功能测试：验证产品能否满足用户特定功能要求并做出正确响应安全性测试：验证产品是否有保护数据的能力，并能在合适的范围内承受恶意攻击兼容性测试：验证产品是否能够和其他相关产品顺利对接配置测试：验证产品是否能够在推荐配置上流畅运行;验证产品为了完成特定功能的输人是否会出现故障可靠性测试：验证产品在长时间运行下能否满足保证系统的性能水平;在存在异常的情况下系统是否依然可靠易用性测试：验证产品是否易于理解、易于学习和易于操作性能测试：测试产品提供某项功能时的时间和资源使用情况安装测试：测试产品能否被正确安装并运行

测试类型

产品测试车轮图

单运行正常值输入法

单运行边界值输入法

多运行顺序执行法在和用户的操作习惯相关的地方使用非常有效。例如，用户登录、用户选择商品、用户提交订单这几个运行，有的用户的操作习惯是先登录，再选择商品;有的用户的操作习惯可能是先选择商品然后再登录。这就需要我们先分析这些操作可能的先后顺序再来进行测试。

多运行顺序执行法

多运行相互作用法

功能测试方法

系统不允许输入的数值，或者不完整的数值

异常值输入法

把系统放在有问题的环境中测试，容错性和成熟性。

故障植入法

多、并、复、异

稳定性测试法是在一- 段时间里，长时间大容量运行某种业务的一种可靠性测试法，它能够非常有效地测试到系统的“ 成熟性”，是非常重要的一种可靠性测试法。

稳定性测试法

我们希望系统在突发的情况下不会像纸牌屋那样脆弱，而是有切实的应对措施，如不处理超过系统规格的负载、记录日志供用户分析突发原因等。不会因为突发情况导致死机、反复重启等致命问题，这才是我们进行压力测试的真正目的。

压力测试法

恢复测试法是指使用持续超过规格的负载进行了测试后，再将负载降到规格以内的测试方法。

恢复测试法

可靠性测试方法

性能瓶颈

分析会影响性能的因素，测试它们对性能的影响

以场景为单位来测试性能

性能测试方法

测试时可以对需要测试的设计规范制定简明的checklist(清查表)，让测试人员可以基于对设计规范的理解来进行测试，而不是机械地进行比对。如果抽测发现的问题很多，最好的办法不是加大测试量，而是反馈给UI的设计者和实现者，请他们进行改进。

一致性测试法

我认为，适合进行可用性测试的人选，排序是专职验收测试者=需求工程师>售前/售后工程师>功能测试人员。即可用性测试最佳的人选是又懂用户又懂测试的人，如果能力不能兼具，懂用户、会使用的人更适合。

可用性测试法

易用性测试方法

测试方法

正是因为软件产品有很多质量属性，这些都需要软件测试去验证，所以软件测试才会有如此多的测试类型。每一种测试类型又包含了很多测试方法，去验证确认产品的这种质量属性。这就构成了一个软件测试者要从哪些方面(测试类型) 用哪些方法(测试方法)去测试产品(质量属性)的关系图从“车轮图”中能够分析出产品测试的两个关键问题：一是如何保证测试验证的“全面性”的问题。显然，只要我们使用的测试方法能够覆盖六大质量属性，我们的测试就不会出现大方向性的遗漏。二是如何确定测试“深度”的问题。一般来说，测试团队使用的测试方法越多，对产品就测试得越深。这些都会影响测试的效果，影响测试对产品质量的评估。除此之外，“车轮图”还能帮助我们评估测试团队的能力。软件测试人员能够驾驭的测试方法越多，他的测试能力就越强;相应地，一个测试团队能够驾驭的测试方法越多，这个团队的测试能力就越强。这为我们如何提升团队能力，提供了思路。需要特别指出的是，测试团队的能力强，能够驾驭很多测试方法，不等于在测试中都要使用这些方法一测试不是越多越好，而是需要根据产品的质量目标、产品的风险分析来确定测试的重点和难点、深度和广度，这就是测试策略。

易用性测试法测试的是用户在理解、使用产品时产品的能力。在产品日益重视易用性的今天，易用性测试的现状却不容乐观。很多人都认为易用性测试并不是有严格标准的测试，而是带有很强的主观性。这使得开发和测试在问题确认上常会出现分歧。很多人会认为易用性测试发现的问题对产品质量来说是“锦上添花”，和开发新功能、修改其他的bug相比优先级被放得很低，得不到应有的重视。对于易用性测试来说，确定以些客观的测试验收标准，保证必要投入是非常必要的。

而测试用例是在测试点“加工”的基础上得到的。首先把测试点“去重”(去掉重复的内容)、“合并”(把太细的测试点合并起来)、“细化\

测试点不等于测试用例

对“流程”类，可以通过绘制“ 流程图”来建立测试模型。

流程

对“参数”类，可以通过“输入输出表”来建立测试模型。

参数

对“数据”类，可以通过“等价类分析表”来建立测试模型。

数据

对“组合”类，可以通过“因子表”来建立测试模型。

软件测试“因子表”使用测试工具PICT下载安装，PICT中文乱码问题，pict下载百度网盘分享

组合PICT

建模

为什么我们称此时的测试用例为基础测试用例呢?测试用例和基础测试用例最大的差别在于，测试用例确定了测试条件(类似“在xx情况下，进行xx的测试”的描述)和测试数据(就是输人的“参数值\"或“数值\

设计基础测试用例

补充测试数据，这时基础测试用例就升级成真正的测试用例了

补充测试数据

模型不是银弹，不能解决测试设计的所有问题。我们还需要根据经验，特别是对系统哪些地方容易发生缺陷的认识，补充- -些测试用例，增加系统的有效性。

扩展

四步测试设计法

流程类测试点有哪些特征

参数类测试点有哪些特征

数据类测试点有哪些特征

组合类测试点有哪些特征

对测试点进行分类

对流程类的测试点，建模就是绘制这些测试点代表的业务流程图。在这个步骤中需要特别注意的地方是:1.测试者要充分理解和测试点相关的功能业务流程，确保流程图的正确性。2.测试者要和产品设计者充分交流，保证绘出的流程图能够正确覆盖产品的设计。3.如果开发已经提供了该功能的流程图，测试者需要仔细审核流程图的正确性，如有必要可以重新绘制。

通过绘制业务流程图来建模

语句覆盖是指覆盖系统中所有判定和过程的最小路径集合。

语句覆盖

分支覆盖是指覆盖系统中每个判定的所有分支所需的最小路径数。

分支覆盖

全覆盖是指100%地覆盖系统所有可能的路径的集合。

全覆盖

我们希望能有这样的一种覆盖方式，仅保证流程图中每个路径片段能够被至少执行一次，在这种覆盖策略下得到的最少路径组合，就是最小线性无关覆盖

最小线性无关覆盖

使用路径分析法“覆盖”这个流程，设计基础测试用例所谓路径分析法，就是指对能够覆盖流程的各种路径进行分析，得到一个路径的集合。在测试时，我们只需要按照这个路径集合进行测试即可。不同的覆盖策略，能够得到不同的路径集合。常见的覆盖策略有语句覆盖、分支覆盖、全覆盖和最小线性无关覆盖。

路径分析法

使用路径分析法来设计基础测试用例

确定测试数据，完成测试用例

是否要增加一-些需要覆盖的路径?是否要增加一-些测试数据?有哪些地方是容易出问题的，是否还需要补充--些测试用例?

根据经验补充测试用例

流程类测试设计：路径分析法

“输入一输出表”是一张分析测试点在某种条件下，特定的“输人”会有怎样“输出”的表

使用输入输出表来建模

覆盖输入输出表，完成测试用例

是否需要考虑一些别的条件？

有哪些地方是容易出问题的，是否需要补充一些测试用例？

参数类测试设计：输入输出表分析法

等价类和边界值

使用等价类分析表来建模

覆盖等价类分析表完成测试用例

是否要在“等价类”中增加一些除“边界值”之外的测试数据?有哪些地方是容易出问题的，是否还需要补充一些测试用例?

数据类测试设计：等价类和边界值分析法

使用因子表来建模

使用PICT工具来生成测试用例

组合类测试设计：正交分析法

用例粒度总数维持在合理的范围内

不同的用例粒度，可能会发现产品不同层次的问题

控制用例粒度

同等重要可以使用轮询

不同等重要按照内容的重要性分配

考虑到测试的便利性

策略覆盖

控制用例粒度：测试点的组合和拆分

错误推断法是测试者根据经验来判断产品在哪些地方容易出现问题，然后针对这些地方来设计测试用例的方法。错误推断法是一种基于经验的测试设计方法。使用错误推断法来设计测试用例，优点是测试用例的有效性会比较高(所谓测试用例的有效性，就是指测试用例发现产品缺陷的能力)。但错误推断法的缺点也是显而易见的:这时测试专注于发现缺陷，可能会测试得很严苛，却忽视或遗漏掉对一些基本功能和场景的测试验证，造成测试遗漏。因此对软件测试架构师来说，在测试设计中控制错误推断法的使用，将其维持在一个合适的度上，是非常重要的一件事情。将错误推断法用到四步测试设计法中的第4步，根据经验补充测试用例，是一个比较推荐的方法。在保证测试用例对功能、场景能够有一定的基本覆盖的基础上，再使用错误推断法来增加测试用例的有效性。

错误推断法

测试设计技术

把测试点加工为测试用例，就叫测试设计，在这个过程中使用的方法就叫测试设计方法。路径分析法、判定表、正交分析法、等价类、边界值等都是常见的测试设计方法。

在使用四步测试方法之前，我们首先要对测试点进行分类。分类的依据，就是看测试点是否有“流程”类的特征、“参数”类的特征、“数据”类的特征、“组合”类的特征。

探索式测试(exploratory testing) 最早由测试专家Cem Kanner博士在1983年提出，是一种强调测试人员同时开展测试学习、测试设计、测试执行，并根据测试结果反馈及时优化的测试方法。

在实际项目中，以传统式测试为主线，将探索式测试作为很好的补充是比较不错的方式，两种思想结合起来，能比较不错地将探索式测试的思想运用到各种测试活动中。

探索式测试的基本思想：CPIE

选择合适的探索式测试方法

开展探索式测试

探索式测试

自动化并不廉价，相反，自动化很贵

自动化脚本往往没有想象中那么可靠

自动化测试不是单靠测试就能搞定

需要知道的一些自动化测试真相

自动化测试的实施成本=前期开发成本+后期的维护成本

自动化测试的收益=自动化测试的运行次数%x

k——手工执行自动化用例所花费的时间成本;n——自动化测试用例执行的次数;c1——花费在自动化测试前期的成本(时间成本+人力成本+金钱成本);c2——花 费在自动化测试后期的成本(时间成本+人力成本+金钱成本)。这个公式可以帮助我们评估当前自动化测试的收益，还可以帮助我们确定适合当前项目的自动化测试和手工测试比。

如何评估自动化的收益

子主题

自动化测试工具介绍

自动化测试

软件测试架构师知识能力模型