软件测试[3](Guru99软件测试教程翻译！！！)

软件测试【3】

来源：https://www.guru99.com

翻译！！！！！
接软件测试[2]

Test Scenario

测试场景是可以测试的任何功能。 它也称为测试条件或测试可能性。 作为一名测试人员，您可以将自己置身于最终用户的角色，并找出真实世界的场景和使用中的应用程序案例。

场景测试是软件测试的变体，其中场景用于测试。 场景有助于更简单的测试方式

为什么要创建测试场景？

• 创建测试场景可确保完整的测试覆盖率
• 测试场景可以得到业务分析师，开发人员，客户等各种利益相关方的批准，以确保对测试中的应用程序进行全面测试。 它确保软件适用于最常见的用例。
• 它们可以作为确定测试工作量的快速工具，从而为客户创建提案或组织员工。
• 它们有助于确定最重要的端到端事务或软件应用程序的实际使用。
• 为了研究程序的端到端功能，测试场景至关重要。

什么时候不创建测试场景？

• 被测应用程序复杂，不稳定，项目有时间紧迫。
• 遵循Agile Methodology（如Scrum，Kanban）的项目可能无法创建测试场景。
• 可能无法为新的错误修复或回归测试创建测试场景。 在这种情况下，必须在之前的测试周期中大量记录测试场景。 维护项目尤其如此。

怎样创建一个测试场景？

1. 步骤1：读取被测系统（SUT）的需求文档，如BRS，SRS，FRS。 您还可以参考要测试的应用程序的用例，书籍，手册等。
2. 步骤2：针对每个需求，确定可能的用户操作和目标。 确定要求的技术方面。 确定系统滥用的可能情况，并使用黑客的思维方式评估用户。
3. 步骤3：阅读需求文档并进行正当分析后，列出验证软件每个功能的不同测试方案。
4. 步骤4：列出所有可能的测试方案后，将创建可跟踪性矩阵以验证每个需求是否具有相应的测试方案
5. 第5步：创建的方案由您的主管审核。 之后，项目中的其他利益相关方也对其进行了审核。

创建测试场景需要注意什么？

• 根据项目方法，每个测试场景应至少与一个需求或用户故事相关联。
• 在创建一次验证多个需求的测试场景之前，请确保您有一个测试场景，可以单独检查该需求。
• 避免创建跨越多个要求的过于复杂的测试场景。
• 场景的数量可能很大，并且运行它们的成本很高。 根据客户优先级，仅运行选定的测试方案。

How to Write Test Cases: Sample Template with Examples

测试用例是为验证软件应用程序的特定功能而执行的一组操作。

• 测试用例必须有预期结果
• 测试用例 - 可能有类似Pre-Condition的字段，它指定在测试运行之前必须存在的东西。
• 此外，您的测试用例还可能包括Post-Conditions，它指定在测试用例完成后适用的任何内容。
• 运行期间，您将记录在“实际结果”列中观察到的结果，甚至可以附加一些屏幕截图，并根据结果给出“通过和失败”状态。
• 整个表可以在Word，Excel或任何其他测试管理工具中创建。这就是测试用例设计

Test Case ID	Test Scenario	Test Steps	Test Data	Expected Results	Actual Results	Pass/Fail
TU01	Check Customer Login with valid Data	Go to site http://demo.guru99.comEnter UserIdEnter PasswordClick Submit	Userid = guru99 Password = pass99	User should Login into application	As Expected	Pass
TU02	Check Customer Login with invalid Data	Go to site http://demo.guru99.comEnter UserIdEnter PasswordClick Submit	Userid = guru99 Password = glass99	User should not Login into application	As Expected	Pass

在起草测试用例时，请确保包含以下信息

• 正在测试的要求的描述
• 解释如何测试系统
• 测试设置如：测试中的应用程序版本，软件，数据文件，操作系统，硬件，安全访问，物理或逻辑日期，时间，其他测试等先决条件以及与要测试的要求相关的任何其他设置信息
• 输入和输出或行动和预期结果
• 任何证据或附件
• 使用活动案例语言
• 测试用例不应超过15步
• 自动测试脚本使用输入，目的和预期结果进行评论
• 安装程序提供了先决条件测试的替代方案
• 对于其他测试，应该是不正确的业务场景顺序

编写好的测试用例示例的最佳实践。

1.测试用例需要简单透明：

创建尽可能简单的测试用例。 它们必须清晰简洁，因为测试用例的作者可能不会执行它们。

使用断言语言，如转到主页，输入数据，点击此处等。 这使得理解测试步骤变得容易并且测试执行更快。

2.创建最终用户的测试用例

任何软件项目的最终目标都是创建满足客户要求且易于使用和操作的测试用例。 测试人员必须创建测试用例，同时牢记最终用户的观点

3.避免重复测试用例。

不要重复测试用例。 如果执行某些其他测试用例需要测试用例，请在前置条件列中通过其测试用例id调用测试用例

4.不要假设

在准备测试用例时，不要假设您的软件应用程序的功能和特性。 坚持规范文件。

5.确保100％的覆盖率

确保编写测试用例以检查规范文档中提到的所有软件要求。使用可追踪性矩阵确保没有未经测试的功能/条件。

6.测试用例必须是可识别的。

命名测试用例id，以便在跟踪缺陷或在稍后阶段识别软件需求时轻松识别它们。

7.实施测试技术

无法检查软件应用程序中的每个可能情况。测试技术可帮助您选择一些最有可能发现缺陷的测试用例。

边界值分析（BVA）：顾名思义，它是定义指定范围值的边界测试的技术。

等价分区（EP）：此技术将范围划分为具有相同行为的相等部分/组。

状态转换技术：当特定操作后软件行为从一种状态变为另一种状态时，使用此方法。

错误猜测技术：这是猜测/预测测试时可能出现的错误。这不是一种正式的方法，并利用了测试人员对应用程序的体验

8.自我清洁

您创建的测试用例必须将测试环境返回到测试前状态，并且不应使测试环境无法使用。对于配置测试尤其如此。

9.可重复和独立

无论是谁测试，测试用例每次都应生成相同的结果

10.同行评审。

创建测试用例后，请由同事进行审核。您的同事可以发现您的测试用例设计中的缺陷，您可能很容易错过。

Test Case Management Tools

测试管理工具是帮助管理和维护测试用例的自动化工具。 测试用例管理工具的主要特点是

对于记录测试用例：使用工具，您可以使用模板加快测试用例创建
执行测试用例并记录结果：测试用例可以通过工具执行，并且可以轻松记录获得的结果。
自动化缺陷跟踪：失败的测试会自动链接到错误跟踪器，而错误跟踪器又可以分配给开发人员，并可以通过电子邮件通知进行跟踪。
可追溯性：需求，测试用例，测试用例的执行都通过工具相互关联，并且每个案例都可以相互跟踪以检查测试覆盖率。
保护测试用例：测试用例应该是可重复使用的，并且应该防止由于版本控制不佳而丢失或损坏。 测试用例管理工具提供类似的功能。

命名和编号约定
版本
只读存储
受控访问
异地备份

Popular Test Management tools are : Quality Center and JIRA

What is Test Basis in Software Testing?

Test Basis被定义为创建测试用例的来源。 它可以是应用程序本身，也可以是SRS（软件需求规范），BRS（业务需求规范）等需求文档。

How to Create Requirements Traceability Matrix (RTM)

什么是可追溯性矩阵（TM）？

可追踪性矩阵是一个文档，它将需要多对多关系的任何两个基线文档联合起来，以检查关系的完整性。

它用于跟踪需求并检查当前项目要求是否得到满足。

什么是需求可跟踪矩阵(RTM)?

需求可跟踪性矩阵或RTM捕获客户端或软件开发团队提出的所有要求及其在生命周期结束时提供的单个文档中的可跟踪性。

换句话说，它是一个用测试用例映射和跟踪用户需求的文档。 需求可跟踪性矩阵的主要目的是确保涵盖所有测试用例，以便在进行软件测试时不会错过任何功能。

需求可跟踪矩阵包含的参数：

• 需求ID
• 风险
• 要求类型和描述
• 追溯设计规范
• 单元测试用例
• 集成测试用例
• 系统测试用例
• 用户验收测试用例
• 跟踪测试脚本

Types of Traceability Test Matrix

前向可追溯性：该矩阵用于检查项目是否按期望的方向和正确的产品进展。 它确保每项要求都适用于产品，并且每项要求都经过彻底测试。 它将需求映射到测试用例。

向后或向后可追溯性：用于确保当前产品是否保持在正确的轨道上。 这种可追溯性背后的目的是通过添加代码，设计元素，测试或其他未在需求中指定的工作来验证我们不扩展项目的范围。 它将测试用例映射到需求。

双向可追溯性（前向+后向）：此可追溯性矩阵确保测试用例涵盖所有要求。 它分析了受工作产品中的缺陷影响的需求变化的影响，反之亦然。

如何创建RTM？

案例：

在业务需求文档（BRD）和技术需求文档（TRD）的基础上，测试人员开始编写测试用例。

假设，下表是我们的业务需求文档或Guru99银行项目的BRD。

这里的情况是客户应该能够使用正确的密码和用户#id登录Guru99银行网站，而经理应该能够通过客户登录页面登录网站。

Enquiry:查询

Fund Transfer：资金转账

下表是我们的技术要求文件（TRD）。

注意：QA团队不记录BRD和TRD。 此外，一些公司使用与技术要求文档类似的功能需求文档（FRD），但创建可跟踪性矩阵的过程保持不变。

现在开始创建RTM：

Step 1: 我们的测试用例是：验证登录，输入正确的ID和密码后，应该成功登录

Step 2：确定此测试用例正在验证的技术要求。 对于我们的测试用例，技术要求是T94正在验证。

Step 3:请注意测试用例中的此技术要求（T94）。

Step 4：确定定义此TR（技术要求-T94）的业务需求

Step 5：请注意测试用例中的BR（业务要求）

Step 6:对所有测试用例做以上操作。 稍后从测试套件中提取前3列。 测试中的RTM就绪！

Advantage of Requirement Traceability Matrix

• 它确认了100％的测试覆盖率
• 它突出显示缺少的任何要求或文档不一致
• 它显示了整体缺陷或执行状态，重点关注业务需求
• 它有助于分析或估计QA团队在重新审视或重新处理测试用例方面的工作所产生的影响

Tips and Tricks to Generate Test Data

测试数据实际上是给予软件程序的输入。 它表示影响或受特定模块执行影响的数据。 一些数据可用于正测试，通常用于验证给定函数的给定输入集产生预期结果。 其他数据可用于否定测试，以测试程序处理异常，极端，异常或意外输入的能力。 设计不良的测试数据可能无法测试所有可能妨碍软件质量的测试场景。

测试数据的生成方法？

• 手动
• 从生产到测试环境的大量数据副本
• 从旧版客户端系统批量复制测试数据
• 自动测试数据生成工具

下面介绍几种测试类型以及有关其测试数据需求的一些建议。

Test Data for White Box Testing

在白盒测试中，测试数据源自对待测试代码的直接检查。 可以通过考虑以下因素来选择测试数据：

• 希望覆盖尽可能多的分支; 可以生成测试数据，使得程序源代码中的所有分支至少被测试一次
• 路径测试：程序源代码中的所有路径至少测试一次 - 测试数据可以设计为涵盖尽可能多的情况
• 负Api测试：
• 测试数据可能包含用于调用不同方法的无效参数类型
• 测试数据可能包含用于调用程序方法的无效参数组合

Test Data for Performance Testing（性能测试）

性能测试是一种测试类型，用于确定系统在特定工作负载下的响应速度。此类测试的目标不是发现错误，而是消除瓶颈。性能测试的一个重要方面是使用的样本数据集必须非常接近生产中使用的“真实”或“实时”数据。来自最了解客户的人。他们可能能够提供他们已有的一些数据，或者，如果他们没有现有的数据集，他们可以通过提供有关现实世界数据的样子的反馈来帮助您。如果您在维护测试项目中，您可以将数据从生产环境复制到测试台中。在制作副本时，匿名（加密）敏感的客户数据（例如社会保险号，信用卡号，银行详细信息等）是一种很好的做法。

Test Data for Security Testing

安全测试是确定信息系统是否保护数据免受恶意攻击的过程。为完全测试软件安全性而需要设计的数据集必须包含以下主题：

• 保密：客户提供的所有信息都严格保密，不与任何外部人员共享。举个简短的例子，如果应用程序使用SSL，您可以设计一组测试数据来验证加密是否正确完成。
• 完整性：确定系统提供的信息是否正确。要设计合适的测试数据，您可以从深入了解设计，代码，数据库和文件结构开始。
• 身份验证：表示建立用户身份的过程。测试数据可以设计为用户名和密码的不同组合，其目的是检查只有授权人员才能访问软件系统。
• 授权：告知特定用户的权限。测试数据可能包含用户，角色和操作的不同组合，以便仅检查具有足够权限的用户是否能够执行特定操作。

Test Data for Black Box Testing

在黑盒测试中，测试人员看不到代码。 您的功能测试用例可以使测试数据符合以下条件 -

• 无数据：未提交数据时检查系统响应
• 有效数据：提交有效测试数据时检查系统响应
• 无效数据：提交InValid测试数据时检查系统响应
• 非法数据格式：当测试数据格式无效时，检查系统响应
• 边界条件数据集：满足边界值条件的测试数据
• 等价分区数据集：验证等价分区的测试数据。
• 决策表数据集：验证决策表测试策略的测试数据
• 状态转换测试数据集：满足您的状态转换测试策略的测试数据
• 用例测试数据：测试数据与您的用例同步。

Automated Test Data Generation

为了生成各种数据集，您可以使用各种自动测试数据生成工具。以下是此类工具的一些示例：

GSApps的测试数据生成器可用于在几乎任何数据库或文本文件中创建智能数据。它使用户能够：

• 通过使用有意义的数据扩充数据库来完成应用程序测试
• 创建可用于演示的行业特定数据
• 通过创建现有数据的克隆并屏蔽机密值来保护数据隐私
• 通过简化测试和原型设计来加速开发周期
• DTM的测试数据生成器是一个完全可定制的实用程序，可为数据库测试（性能测试，QA测试，负载测试或可用性测试）生成数据，表（视图，过程等）。
• Datatect是Banner Software的SQL数据生成器，可以在ASCII平面文件中生成各种实际测试数据，或者直接为RDBMS生成测试数据，包括Oracle，Sybase，SQL Server和Informi。

Download Sample Test Case Template with Explanation of Important Fields

任何好的测试用例模板必须包含以下字段;

Test Case Field	Description
Test case ID:	Each test case should be represented by a unique ID. To indicate test types follow some convention like “TC_UI_1” indicating “User Interface Test Case#1.”
Test Priority:	It is useful while executing the test.LowMediumHigh
Name of the Module:	Determine the name of the main module or sub-module being tested
Test Designed by:	Tester’s Name
Date of test designed:	Date when test was designed
Test Executed by:	Who executed the test- tester
Date of the Test Execution:	Date when test needs to be executed
Name or Test Title:	Title of the test case
Description/Summary of Test:	Determine the summary or test purpose in brief
Pre-condition:	Any requirement that needs to be done before execution of this test case. To execute this test case list all pre-conditions
Dependencies:	Determine any dependencies on test requirements or other test cases
Test Steps:	Mention all the test steps in detail and write in the order in which it requires to be executed. While writing test steps ensure that you provide as much detail as you can
Test Data:	Use of test data as an input for the test case. Deliver different data sets with precise values to be used as an input
Expected Results:	Mention the expected result including error or message that should appear on screen
Post-Condition:	What would be the state of the system after running the test case?
Actual Result:	After test execution, actual test result should be filled
Status (Fail/Pass):	Mark this field as failed, if actual result is not as per the estimated result
Notes:	If there are some special condition which is left in above field

您可以根据项目要求选择具有以下字段

• 链接/缺陷ID：包括缺陷链接或在测试状态失败时确定缺陷编号
• 关键字/测试类型：要根据测试类型确定测试，可以使用此字段。 例如：可用性，功能，业务规则等。
• 要求：编写此测试用例的要求
• 参考/附件：它对于复杂的测试场景很有用，给出文档或图表的实际路径
• 自动化（是/否）：在测试用例自动化时跟踪自动化状态
• 自定义字段：由于客户/项目要求，字段特别针对您正在测试的项目。

Software Testing Techniques with Examples

软件测试技术可帮助您设计更好的案例。 由于无法进行详尽的测试; 测试技术有助于减少要执行的测试用例数量，同时提高测试覆盖率。 它们有助于识别难以识别的测试条件。

边界值分析（BVA）
边界值分析基于在分区之间的边界处进行测试。 它包括最大值，最小值，内部或外部边界，典型值和误差值。

通常可以看出，在定义的输入值的边界而不是中心处发生大量错误。 它也被称为BVA，并提供了一系列运行边界值的测试用例。

此测试用例设计技术补充了等价划分。 这种软件测试技术的基础是，如果一个系统适用于这些特定值，那么它将完美地适用于两个边界值之间的所有值。

边界值分析指南

如果输入条件在值x和y之间受到限制，那么测试用例应设计为值x和y以及高于和低于x和y的值。
如果输入条件是大量值，则应开发需要使用最小和最大数字的测试用例。 这里，还测试了高于和低于最小值和最大值的值。
将准则1和2应用于输出条件。 它给出的输出反映了预期的最小值和最大值。 它还测试以下或以上的值。

等价类划分
等效类分区允许您将一组测试条件划分为一个应该被视为相同的分区。 该软件测试方法将程序的输入域划分为应该设计测试用例的数据类。

这种技术背后的概念是每个类的代表值的测试用例等于对同一类的任何其他值的测试。 它允许您识别有效和无效的等价类。

基于决策表的测试。
决策表也称为因果表。 该软件测试技术用于响应输入或事件组合的功能。 例如，如果用户输入了所有必填字段，则应启用提交按钮。

第一项任务是确定输出取决于输入组合的功能。 如果存在大量输入组合，则将其划分为更小的子集，这有助于管理决策表。

对于每个功能，您需要创建一个表并列出所有类型的输入组合及其各自的输出。 这有助于识别测试人员忽视的情况。

以下是创建决策表的步骤：

在行中登记输入
输入列中的所有规则
使用不同的输入组合填充表格
在最后一行中，记下输入组合的输出

A submit button in a contact form is enabled only when all the inputs are entered by the end user.

状态转换：

在状态转换技术中，输入条件的变化会改变被测应用程序（AUT）的状态。 该测试技术允许测试人员测试AUT的行为。 测试人员可以通过按顺序输入各种输入条件来执行此操作。 在状态转换技术中，测试团队提供正输入测试值和负输入测试值，用于评估系统行为。

当测试团队针对一组有限的输入值测试应用程序时，应使用状态转换。
当测试团队想要测试在测试中的应用程序中发生的事件序列时，应该使用该技术。

在以下示例中，如果用户在前三次尝试中的任何一次中输入有效密码，则用户将能够成功登录。 如果用户在第一次或第二次尝试中输入无效密码，将提示用户重新输入密码。 当用户第三次错误输入密码时，操作已经执行，帐户将被阻止。

状态转换图如下：

状态转换表：

Correct PIN	Incorrect PIN
S1) Start	S5	S2
S2) 1st attempt	S5	S3
S3) 2nd attempt	S5	S4
S4) 3rd attempt	S5	S6
S5) Access Granted	-	-
S6) Account blocked	-	-

在上面给出的表中，当用户输入正确的PIN时，状态将转换为Access grant。 如果用户输入了错误的密码，他或她将被转移到下一个状态。 如果他第三次做同样的事，他将达到帐户被阻止的状态。

错误猜测
错误猜测是一种软件测试技术，它基于猜测代码中可能存在的错误。 这是一种基于体验的技术，测试分析师使用他/她或经验来猜测测试应用程序中存在问题的部分。

该技术计算可能的错误或容易出错的情况列表。 然后，测试人员编写测试用例以暴露这些错误。 为了基于这种软件测试技术设计测试用例，分析师可以使用过去的经验来识别条件。

错误猜测指南：

• 测试应该使用以前测试类似应用程序的经验
• 了解被测系统
• 了解典型的实施错误
• 记住以前困扰的地区
• 评估历史数据和测试结果

What is Use Case Testing?

用例是执行者或用户对系统的特定使用的描述。 它广泛用于开发系统或验收级别的测试。

用例测试是一种技术，可以帮助识别覆盖整个系统的测试用例，从事务开始到结束点逐个事务。

在用例中，actor由“A”表示，系统由“S”表示。

Main Success Scenario	Step	Description
A:ActorS:System	1	A: Enter Agent Name & Password
	2	S: Validate Password
	3	S: Allow Account Access
Extensions	2a	**Password not valid**S :Display Message and ask for re-try 4 times
	2b	**Password not valid 4 times**S :Close Application

- 考虑我们的Flight Reservation应用程序的登录功能的端到端场景的第一步，其中Actor输入代理名称和密码以登录Flight Reservation应用程序。
- 在下一步中，系统将验证密码
- 接下来，如果密码正确，将授予访问权限
- 这个用例可以扩展。 如果密码无效，系统将显示一条消息并要求重试四次
- 或者如果密码，无效四次系统将关闭应用程序

Software Test Estimation Techniques: Step By Step Guide

需要评估的东西有哪些？

• 资源：执行任何项目任务都需要资源。 它们可以是人员，设备，设施，资金或任何其他能够完成项目活动所需的定义。
• 时代：时间是项目中最有价值的资源。 每个项目都有一个交付截止日期。
• 人际技能：人类技能意味着团队成员的知识和经验。 它们会影响您的估计。 例如，一个团队的成员测试技能较低，他们将花费更多的时间来完成项目而不是具有高测试技能的团队。
• 成本：成本是项目预算。 一般来说，这意味着完成项目需要多少钱。

怎样去评估？

• Work Breakdown Structure
• 3-Point Software Testing Estimation Technique
• Wideband Delphi technique
• Function Point/Testing Point Analysis
• Use – Case Point Method
• Percentage distribution
• Ad-hoc method

步骤1）将整个项目任务划分为子任务
任务是给某人的一项工作。 为此，您可以使用工作分解结构技术。

在这种技术中，复杂的项目被分成模块。 模块分为子模块。 每个子模块进一步划分为功能。 这意味着将整个项目任务划分为最小的任务。

步骤2）将每个任务分配给团队成员
在此步骤中，每个任务都分配给项目团队中的相应成员。 您可以按如下方式分配任务

//以下涉及测试管理，目前不是我的重点，所以就不赘述了。

//后期会就测试技术认真写一篇

以上。