重读《从菜鸟到测试架构师》 -- 全面撒网，重点排查

前面我们说到小艾花了一个月时间才顺利完成组长给定的第一份任务，对安装流程有了基本的掌握，但是对于那句“一个好的可执行的测试计划是确保测试质量的关键”，却产生了不少的疑问，如何确定测试配置和测试场景，如何保证测试全面性及完成性呢？

带着疑问，小艾来到了组长面前，组长也用心地给小艾从头到尾仔细讲了起来。

选择测试配置

撰写测试计划时，首先要清楚地列出产品所有能够支持的测试配置。

测试配置是指待测软件所能支持的硬件环境、软件环境和配置方法的组合。

对于不同种类的待测软件，可以从各个角度来找出测试配置，对于Java EE应用软件来说，可以从以下几个角度来考虑：

    操作系统：Java EE应用是跨平台的应用，一般都能支持多种操作系统。

    应用服务器：Java EE应用需要部署到应用服务器才能发挥作用。

    数据库：Java EE应用一般都需要使用数据库来存取信息。

    网络服务器：Java EE应用一般都需要使用网络服务器来提高性能和支持可扩展性。

    拓扑：Java EE应用部署时一般都支持不同的拓扑结构来满足不同的对性能和可扩展性的支持。

    版本：为了适应不同客户群的需求，Java EE应用软件一般被包装成不同的版本。

    安装类型：一般的Java EE软件都会支持多种安装类型以满足不同的安装需求。 

组长告诉小艾，这里需要注意的是：每一个产品不尽相同，因此我们需要从设计文档中获得具体的信息。

在时间和人力有限的情况下，不可能每种组合都测试，此时需要根据一些限制条件来进一步缩小测试范围。

最佳实践

1. 每种支持的操作系统版本至少需要测试一次。

2. 每种支持的网络服务器版本至少测试一次。

3. 每种支持的数据库版本至少测试一次。

4. 设计文档中需要重点测试的配置必须测试。

5. 客户典型配置必须测试。

6. 以往版本产品由客户报告的问题分析和由测试人员报告的缺陷分析。

 

客户报告的问题非常有价值，为什么客户发现了这样的问题但测试人员并没有发现？从中能分析测试计划中可能存在的漏洞。

缺陷分析则可以发现哪些部分特别容易出问题，可能会在新版本中依然出现。

小艾发现，根据上述的原则选择之后，就能得到合适的测试配置覆盖。由于所有的测试点都有相应的测试覆盖，因此尽管没有测所有的测试配置，依然能够很好的保障测试的质量。

 

 

 

找出测试场景

测试场景是一系列紧密关联的操作步骤的组合。

可以根据一下信息来设计测试场景：

    需求说明书：设计测试场景的主要依据，从中能够找出最终用户对产品安装和卸载方面的各种需求。每一个测试人员都需要认真阅读，特别是测试计划的作者，需要对它非常清楚。

    用户手册：即安装文档，其中会陈述一些典型场景和注意事项。

 

基本及典型场景

从一个软件产品的生命周期来看，一个产品会经历安装、升级、卸载的过程，因此可以从中找出一些基本及典型的场景。

在选定的测试配置上安装产品：这是一个最基本的测试场景，确保在看安装手册的情况下，产品能够被正确、轻松地安装。

卸载产品：确保产品能够被正确地卸载，这也是一个基本的测试场景。

在卸载后重载安装产品：确保产品卸载后能被正确地重新安装，有些客户可能会用到此场景。 

文件权限检查和敏感数据检查：这个场景是确保软件产品的安全性的典型场景。

残障人员也能顺利安装产品：确保产品的可访问性的典型场景。

组合出测试用例

小艾听到这里，忍不住开口问：是不是有了上述的要点之后，就可以写出具体的测试用例了？组长笑着点头，不住夸赞小艾的聪明，事实也正是如此：测试用例 = 测试配置 + 测试场景。

一般来说，我们分配任务也是以测试用例为单位来分配的，跟踪项目状态也是以测试用例为单位的。

尾声

小艾明白了测试配置、测试场景和测试用例三项为测试计划的精髓之后，喜滋滋地开始尝试写起了测试计划，然而，没过多久，小艾的脑子里又开始了新一轮的疑惑，对于每一个具体的安装测试用例，写出来可能不难，但是如何才能保证测试质量达到了标准呢？

大家先别急，休息会，喝杯茶，思考思考，下回我们继续讨论~

 

想要第一时间看到这一系列文章的更新及更多精彩内容可以扫描下面二维码关注微信公众号: 倚楼听风雨的如月