软件测试架构师的核心技能

测试内容和测试策略中确定的范围、深度和广度一致。
测试执行的顺序和测试策略一致。
计划测试的内容能够被顺利执行。

测试人力不足。
测试时间不够。
测试环境不具备(包括测试工具、上下行配合的设备、软件等)。
由于其他缺陷导致该测试用例无法执行。

缺陷的趋势是否正常?
是否存在因为缺陷修改引入的缺陷?
在本版本中必须解决哪些缺陷?
在本版本中需要解决哪些缺陷?

我们很难在测试之前就知道系统中存在这样的错误一事实 上，出现这样的问题，往
往是开发人员对需求的理解出现了偏差;或是需求文档在描述这部分的时候没有说清楚,
导致开发人员的实现和测试人员理解的需求存在了分歧。

方法回顾

投入回顾

测试用例

测试覆盖度

测试过程

缺陷

非测试用例发现Bug的原因分析

组合缺陷分析

有条件必然重现

有条件概率重现

无规律重现

无法重现

致命缺陷

没有规避措施的缺陷

方法2的优势是，测试能够从一开始就保证需求的覆盖，从源头上避免了需求遗漏的
风险;还很容易通过不同的测试设计方法，让不同优先级的需求能够有不同的测试深度,
更利于软件测试架构师对整个项目进行把控。
但是方法2也有一些需要注意的地方:
1.需要注意需求变化的部分:特别是在项目后期“增加”“修改”和“删除”的需求，避免遗漏。
2.方法2和测试设计的关系变得比较紧密，测试设计遗漏可能会影响对需求覆盖度的评估。
另外在实际项目中，需求和测试用例的对应关系，可能也并不像前面表格的例子中那
样标准的一对一的关系，而是一对多、多对一或多对多这种比较混乱的情况，要想手工维
护好这些关系并不是-件容易的事情，特别是当遇到需求发生变化了，或是通过缺陷来增
加测试用例等情况的时候，要修改的地方就更多了。所以，方法2最好能够有工具支持。

1.可以将最小线性无关覆盖作为-一个基本的路径覆盖方式。
2.对优先级高的功能特性，可以在最小线性无关覆盖的基础上增加一些路径。
3.对优先级低的功能特性，可以在最小线性无关覆盖的基础上减少一些路径。
4.不建议使用全覆盖，也不建议使用语句覆盖。

可能会有以下情况影响测试用例的执行率：
1.测试阻塞:指测试用例因为产品开发(一般是指缺陷)、测试(如测试环境不具备)
等原因，无法被执行的测试用例。
2.未执行:指可以执行，但是因为进度、人力或其他原因等还没有被执行的测试用例。
对“阻塞"这种情况，软件测试架构师需要提前识别这些问题，进行风险识别和控制，
如果这些问题已经是“缺陷”了，就需要要求开发人员优先解决这些问题。
此外，软件测试架构师还需要对测试用例划分优先级。这样在项目进行或者人力紧张
的情况下，就可以优先保证高优先级的测试用例执行率，不执行某些低优先级的测试用例。
有时，一个测试用例会被反复执行多遍，在统计测试用例执行率时，反复执行的测试
用例只用被记录一一次。例如我们需要执行的测试用例有2000个，已经执行的测试用例有
200个，其中有100个测试用例执行了2遍，此时的测试用例执行依然为200/2000=10%，
而非( 100x 2+100 ) /2000=15%。

测试用例执行通过率是指“测试用例执行结果为‘通过’的测试用例数”和“已经执
行的测试用例数目”的比值。由于一个测试用例可能会被反复执行多次，按照测试用例是
在第一次执行时就通过的，还是在后续测试时通过的，我们将测试用例执行通过率细分为
如下两项:
1.测试用例首次执行通过率:指“第一次执行该测试用例的结果为‘通过’的测试用
例数”和“已经执行的测试用例数目”的比值。
2.测试用例累积执行通过率:指“测试用例结果为‘通过’的测试用例数”和“已经执
行的测试用例数目”的比值。
测试用例首次执行通过率可以帮助我们评估开发版本的质量一测试用例首次执行通
过率越高，说明开发的版本质量不错;相反，如果开发需要多次修复，最后才能使得测试
用例执行通过，说明版本质量可能不高，产品在设计、编码方面可能存在一些问题，即便
是修复bug,在修复时引入新bug的风险也会更大。
测试用例累积执行通过率可以帮助我们评估产品在发布时的质量。一般说来，测试用
例累积执行通过率越高，说明当前的版本质量可能已经达到了基本要求，可以考虑发布。

测试人员在按照测试用例执行测试的时候，也会抛开测试用例，自我发挥，做些随机测试。
显然，随机测试也能发现缺陷，有时候甚至比测试用例更能发现产品缺陷，而且“突
然一个灵感来了，然后去测试，并且真的发现了产品缺陷"的过程，会让人很有成就感。
因此在团队中，我们往往会鼓励大家在执行测试用例的时候适当进行--些发散测试，挖掘
bug，找找感觉。
我们希望“通过测试用例发现的缺陷”和“发散测试，也就是非测试用例发现的缺陷
的比值能够在一个合理的范围内。
如果比值过低，即大部分缺陷都是通过发散测试发现的，可能的问题是:
1.随机测试投入过多。
2.测试设计水平不高，存在测试设计遗漏。
3.对产品的需求或者设计的理解不正确、不准确或者不深人，存在测试设计错误。
如果比值过高，大多数缺陷都是通过测试用例发现的，可能的问题是:
4.测试人员不愿意进行发散测试(这样的测试团队可能也是一-个比较沉闷、缺乏激情、只是完成任务的测试团队)。
5.测试投人不足，没有时间进行发散测试。
6.测试思路还没有打开。如果存在这种情况，说明测试设计可能也不够全面。
软件测试架构师可以在测试之前先确定好-一个目标范围，并围绕目标来安排测试活动。
在项目过程中，如果出现偏差，需要对缺陷进行分析，更新测试策略。

严重程度

绘制缺陷趋势图

缺陷趋势曲线的“凹凸性”和“拐点”

缺陷是否收敛

确定缺陷的测试方法和测试类型

统计各种测试方法发现的缺陷数目，绘制分析图

进行缺陷触发因素分析

(1)预测产品可能会有多少缺陷;
(2)评估当前发现的缺陷总数是否足够多

发现的缺陷是否已经被有效修复

系统是否还能被继续发现缺陷

每个可能引人缺陷环节，可能引人的缺陷是否都已经被有效去除

测试是否已经足够全面

Step1:首先分析测试设计需要关注哪些内容。例如:
1.需要对某个重要的特性进行深入的测试，需要能够通过路径分析法来对开发人员的
设计流程进行全面的覆盖，不遗漏基本的流程。
2.需要能够通过功能交互分析对功能间的相互作用进行深入的测试。
3.需要能够进行压力、稳定性和性能方面的测试。
Step2:分析上述内容都能够保质保量顺利地进行，需要哪些条件。例如:
条件1 :开发能够提供相关的设计材料(如相关的概要设计文档)，并且能够保证材
料的内容是正确的。
条件2:有条件或者有机制能够保证开发人员和测试人员之间的有效沟通。
条件3:测试人员对产品的使用场景、多个特性都有一定的理解，能够进行全面的功
能交互分析。
条件4:测试人员能够理解并掌握压力、稳定性和性能方面的测试方法，有能力结合
测试方法和产品实现来进行测试设计。
Step3 :逐一分析这些条件是否能够满足。假如条件1和条件4可能无法满足，那么识
别出来的风险点就是:
风险1:开发可能会缺失重要的设计文档，或者一些设计文档更新不及时。
风险2:测试人员对压力、稳定性和性能方面的测试方法掌握不足，可能会出现测试设
计遗漏。
需要特别说明的是，虽然此处我们进行风险分析的对象是测试策略，围绕测试活动能
否正常展开，但并不等于我们只在测试内部识别风险点一我们依然要从整个项目 的角度
来进行风险识别。我们可以使用表6-17风险识别清单，来帮助我们进行风险识别。

机会成本告诉我们，要想用有限的资源获得最大的收益，就需要我们优先处理最可能
会发生、影响(如损失)最大的事件。这就需要我们对识别出来的风险点进行评估，确定风
险优先级，然后优先处理高风险的问题。简言之，风险评估的目标就是确定风险优先级。

“风险应对”举例:新需求在开发过程中不断被增加
1“回避风险”的做法:置之不理。
2“转移风险”的做法:将新需求外包。
3“减轻风险”的做法:寻求额外资源或裁剪其他优先级低的需求。
4“接受风险”的做法:将新需求加入项目范围，通过加班来完成新需求。

1.差异性分析

2.历史测试情况分析

1.总体测试策略:确定产品质量目标，进行项目整体的风险识别，从产品层面来确定测试重点和测试难点、测试深度和测试广度，是测试策略的纲。
2.阶段测试策略:确定测试设计策略和测试执行策略需要达到的质量目标(产品质量目标的分解)以及能够进行这些测试活动的入口条件。
3.测试执行策略:确定每个版本的测试目标、测试内容和每个版本的入口条件。

1.根据质量等级来分解产品的质量目标

2.为每个测试分层确定测试目标

1.使用产品质量评估模型来初步确定测试深度

2.考虑用老功能分析来更新测试深度

3.基于老功能分析来初步确定测试广度

质量目标分值表

分类分值表

优先级的分数范围

确定优先级特性后估算测试深度和广度

测试投入策略

1.基本功能类测试用例

2.单功能类测试用例

3.功能交互类和非功能类的测试用例

4.一些操作或是输入上比较严苛的测试用例

使用黑盒测试的方法来确认新合人的功能是否正确。
验证功能集成后系统功能的正确性。
确认原来的系统功能没有被新合人的功能所破坏。

条件1:第一个集成计划中的功能开发完成，并完成了单元测试
条件2:第一个集成计划中的功能集成完成，并可测
条件2的重点在于“可测”，即开发需要提供基于用户的输入输出接口，而不能是内部
的函数接口，确保测试能够进行系统级的黑盒测试。
条件3:测试团队已经做好了测试准备。
这里的测试准备，主要包括:
1.测试用例已经输出，并通过了评审。
2.测试资源已经到位。
3.测试环境已经准备好。

1.针对功能确认的测试，可以选择相关功能level 1的测试用例。
2.针对“测试新功能集成”的测试，可以选择相关功能level 2的测试用例和部分level 3
的测试用例。
3.针对“确认原系统”的测试，可以选择相关功能中level 1的测试用例。
其中“部分level3的测试用例”是指在集成测试后期，系统已经相对比较成熟和稳定
的时候，也可以适当选择-一些性能、稳定性和压力方面的测试用例来进行测试，以避免这
些“非功能”方面的问题在系统测试阶段密集爆发。

系统需要集成的功能已经全部开放、集成完成。
计划执行的测试用例已经完成。
缺陷分析的结果符合预期。
达到了集成测试阶段的产品质量目标。

现在我们来回答本节开头提的问题:我们在集成测试中执行了的测试用例，在系统测
试中还需要再执行一遍吗?
答案是，系统测试和集成测试的测试用例肯定会有相同的部分，但并不是简单地重复
一遍，而是存在一定的选择策略。
1.针对“系统角度的功能测试":可以选择levell和部分level2的测试用例。
2.针对“非功能的质量的正确性”:可以选择level3的测试用例和level4的测试用例。

测试执行顺序是指先执行哪些测试用例，再执行哪些测试用例，或者说先使用哪些测
试方法，再使用哪些测试方法。
我们在集成测试中并没有讨论测试执行顺序，是因为集成测试的测试对象很单一，就
是“功能”。虽然后面我们提到在集成测试的后期，可以考虑增加一些“非功能方面”的测
试，但是总的来说这并不会给测试带来先执行什么再执行什么的困扰。
和集成测试不同，系统测试需要对功能、可靠性、性能、易用性等各方面进行测试，
如果不考虑测试执行的顺序，很容易遇到阻塞，影响测试的顺利进行。

如果有两种测试方法，都能对测试对象进行测试，先进行复杂的，再进行简单的。
或者说，尽量先执行复杂的、难的测试用例，再进行简单的测试用例。这样考虑的
原因是，希望缺陷能够尽量在测试的前期发现，另外先执行难的测试用例也能保证
这些测试用例有充足的测试时间。
可以考虑组合多种测试方法，或者说让测试者想办法把一些测试用例放在一起执行。

计划执行的测试的用例已经完成。
缺陷分析的结果符合预期。
达到了系统测试阶段的产品质量目标。

Alpha测试

Beta测试