静态测试和动态测试之间的差异
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
静态测试和动态测试之间的差异
测试是检验和确认。我们都知道,它需要2个V(verification&validation),来使测试完成。
在今天的文章中,我们将进一步了解静态测试。它也被称为检验(verification)。我们将学习有关它的一切,并要特别强调这一点,因为动态测试往往受到更大的关注,并有无数的文章详细的进行了说明。
然而,如果不对与静态测试相对应的动态测试是什么进行解释,那讨论就将是不完整的。动态测试是验证(validation),另一个V。动态测试就是你使用实际的系统(不是什么代表系统的工件或模型),提供输入,获得输出并与预期运行输出的进行比较。它是以发现错误为目的的在系统上实际动手检验的工作。
在这个过程中,我们将了解关于测试以下两种常见误解为何都是错误的:
1.测试是在最后才开始的工作
2.测试只需由测试人员来进行,和其他人无关
让我们先从一个关于V模型的快速参考开始:
在V模型的左侧是不由QA团队参与的活动。
在右侧,我们有一些由测试者和用户对开发团队采取的的处理。
让我们从——需求收集开始。它由业务分析人员和其他更高级别的管理部门执行——该阶段的输出文档是商业需求文档(Business requirement document),简称BRD。
下一个阶段是在系统设计。在系统设计阶段,业务需求被转化为功能需求,在功能需求文档中(FRD,Functional requirements document)。当转换过程中,开发团队(此步骤的主要实施者)会对BRD文件一步一步,一页一页,并且一行行的仔细检查。尽管主要目标是为了翻译业务需求,BRD文件仍会被轮流审查。
举个例子:假设这是银行网站的BRD,有很大的安全需求。在其BRD的一节中谈到了对各种用户在网银网站创建帐户密码的规则。期中的一个规则是:一个用户不能使用他在其他帐户使用过的密码。这是不可行的,因为,一个站点可以建议用户应该如何设置其登录信息,但是没办法对其进行强制。所以,这个要求是不可行的——换言之,无法通过软件来实现。
现在让我们在此例子基础上考虑以下几点:
怎么确定这个需求是无法构建的,所以也无法测试(换句话说,是不可行的)?我们是否先要有银行的网站,然后设置登录名和密码,最后才意识到这是不可能的?不,我们只是对这个BRD进行了审查,当然还需要一些常见的商业常识。
我们我们是否在对这个要求进行测试?是的,但纯粹基于理论,概念意义上而不是实际通过AUT(测试应用)。
这是此试验的物理形式?——对BRD的简单的阅读,或正是审查BRD,或更正式的可行性分析报告。