关注的是与代码内部结构相关的缺陷, 因此,需要测试人员掌握一定的编程技术。
关注的是与产品的外部行为相关的缺陷, 此时并不考虑产品的内部结构或运行逻辑。
综合运用黑盒测试和白盒测试技术的 一种混合测试方法。
人工执行测试。即根据测试用例中描述的规程,不借助特殊的软件工具,人工来运行被测系统,观察系统实际输出是否符合测试用例的预期输出。
通过阅读需求、阅读代码对被测系统进行测试,不需要撰写测试用例。
软件测试的自动化,是一个将以人为驱动的测试行为转化为机器执行的过程。目的是节省人力、时间或硬件资源,并提高测试效率。
针对每个单元的测试。用于验证一个单元模块的功能是否正常。一个单元模块可以包括几行或上百行代码。单元测试与编码过程是紧密联系的,单元测试有时也认为是编码阶段的一个活动。 对应编码阶段
将不同单元模块组合在一起,形成更大组件的过程。 用于查找单元或组件间的接口错误, 其关注的重点是那些在单元测试中不能被发现的缺陷。 对应详细设计阶段
检验软件产品能否与系统的其他部分 (比如,硬件、数据库及操作人员)协调工作。用于评估整个系统的行为并确保系统行为符合用户需 求,并评估系统与硬件设备、运行环境和应用程序 等之间的接口。 对应概要设计
部署软件之前的最后一个测试操作。测试范围类似系统测试,通常由系统提供者和客户共同完成的。验收测试使客户确信应用程序具有所需的特性并且能够正确的运行。 对应需求阶段
在目标环境中通过安装来验证软件及其安装 过程。目的是确保该软件在正常或异常情况的不同条件下都能进行安装,且安装后可立即正常运行。
针对软件功能需求进行测试,目的是检查应用程序的行为是否符 合预期。
用于验证系统是否满足规格说明的性能需求,例如容量和响应时间等。
由一个用户在开发环境下进行的测试,也可以由公司内部的用户在模拟实际操作环境下进行的受控测试。 程序员和测试人员不能参与
软件的早期版本被发布给具有代表性用户群来测试, 称为β测试。β测试常被用于面向大众市场的系统、计算机游戏和类似的应用程序。 程序员和测试人员不能参与
软件版本修改后的重新测试,可应用于所有测试级别,目的是 为了确保被修改组件的行为没有改变,不会造成意外结果。
以设计的最大负载或超过最大负载来运 行软件,用于确定系统运行的负载界限。
是对产品进行检验,以验证产品符合 安全需求定义和产品质量标准的过程 。用于测试系 统在遭遇未授权访问、计算机犯罪和破坏时是否能 保护自己。
通过测试系统在资源超负荷情况下的表 现,以发现设计上的错误或验证系统的负载能力。
当开发的系统需要应用于多种环境配置时, 需要对每种配置进行测试,以检测系统行为是否符合规 格要求。包含硬件配置和软件配置。
用于评估系统使用的简易程度,交互是否 具有人机工程学设计以及用户文档使用的有效性 用户体验
在不同操作系统中的测试
用于检验系统在灾难或意外宕机后的重 启能力。
The process of running or testing the system manually or automatically by using tools, in order to verify whether it satisfies the requirements or to make clear the differences between the actual outcome and the expected outcome. 软件测试是人工地,或通过使用工具来自动地运行被测软件系统,或静态检查被测系统的过程,其目的在于校验被测系统是否满足需求, 或要弄清楚实际的系统输出与预期系统输出之间的差异。
根本目的:验证需求
核心关键:测试设计
整体思路:比较预期输出和实际输出
存在不足: 1)没有说明具体如何做测试 2)通过什么办法验证软件质量?
软件测试在实际的开发环境中的境遇 (衡量时间、成本、质量三者的问题) 1、时间压力: 开发工期往往比预期的要长,导致前期 开发大量占用实际测试的时间。 1)要求在最短的时间内、找到最严重的、最多的缺陷,最大限度的保证软件产品符合已知需求。
1)能代表需求的小的测试单元 2)描述用户预期输出 3)反映系统实际执行结果
1)通过需求设计测试用例, 2)用测试用例去执行程序, 3)验证实际结果与预期结果。 但测试用例是否需要穷尽来保证万年泉与需求重叠?
用测试用例是否能够将软件中的所有缺陷测试完呢?
3、成本控制: 据当前的调查数据可知,手工动态测试占主导地位 很多测试属于基础测试,不需要太高级的测试人员,那么人力成本就会受到控制。
(1)测试用例是一组输入(运行前提条件)和为某特定的目标而生成的预期结果及与之相关的测试规程的一个特定的集合,或称为有效地发现软件缺陷的最小测试执行单元。
(2)测试用例是一个文档,详细说明测试的输入、期望输出和为一测试项所准备的一组执行条件。
为了高效地找出软件缺陷,我们可以通过精心设计并执行少量测试数据,并利用这些数据去运行程序,以发现程序错误,这些少量测试数据成为测试用例。
输入:前提条件、测试数据和操作步骤
输出:系统预期执行结果
测试环境:是系统环境设置,即进行软件测 试所必需的工作平台和前提条件。
即软件可以接受的数据
满足数据类型,不在有效取值范围内
不完全满足数据类型
输入条件缺失
是介于正常数据与错误数据之间的临界数据,属于高风险数据
操作步骤
测试环境
测试用例示例.png
1)哪里是系统输入输出中最可能潜伏缺陷的地 方?
2)以怎样的流程操控系统更有利于发现缺陷?
3)如何保证测试用例对系统的全覆盖?
2)可测试性: 一个测试用例的预期输出必须是可以检验 的,可以根据相关开发文档得到明确的、可判定的结论。
1)典型性: 能揭示最有可能存在缺陷的地方,能代表和覆盖合理与不合理、合法或不合法的情况。 有利于快速发现最高风险的缺陷。
3)可重现性: 对于相同的测试用例,系统的预期执行结 果应该完全相同,否则,如果系统预期输出存在不确 定性,一旦实际运行该测试用例,也无法进行校验.
4)独立性:测试用例应尽量独立。
1、使用成熟的测试用例设计方法来进行设计。
2、 保证测试用例数据的正确性和操作的正确性。
3、 确保测试用例应该针对单一的测试项。
4、 每个测试用例应该针对单一的测试项。
5、 保证测试结果是可以判定并且可以再现的。
6、 保证测试用例的描述准确、清晰、具体。
7、 测试用例设计应满足项目的时间、人员和资金约束。
1、把测试用例设计等同于测试输入数据的设计
2、 测试用例设计得越详细越好
3、 追求测试用例设计“一步到位”
4、 将多个设计用例混在一个用例中
一个好的测试用例在于它能发现至今未发现的错误。
设计测试用例比测试用例的执行重要
basicfunction (基本用例)
Limitation (有条件限制的用例)
Interaction (交互用例)
Multi windows (多窗口用例)
Audio-performation test (声音性能测试)
测试用例设计思路.png