文章目录
- 软件测试入门系列之一：软件测试基础
- 软件测试入门系列之二：软件测试职业规划
- 软件测试入门系列之三：软件测试的7条原则
- 软件测试入门系列之四：软件测试V模型
- 软件测试入门系列之五：软件生命周期
- 软件测试入门系列之六：手工测试
- 软件测试入门系列之七：自动化测试
- 软件测试入门系列之八：手工测试VS自动化测试
- 软件测试入门系列之九：单元测试
- 软件测试入门系列之十：集成测试
- 软件测试入门系列之十一：什么是系统测试？
- 软件测试入门系列之十二：什么是冒烟测试？
- 软件测试入门系列之十三：什么是回归测试？
- 软件测试入门系列之十四：非功能测试
- 软件测试入门系列之十五：测试文档
- 软件测试入门系列之十六：测试方案
- 软件测试入门系列之十七：测试用例
- 软件测试入门系列之十八：什么是测试分析
- 软件测试入门系列之十九：什么是需求追踪矩阵(RTM)
- 软件测试入门系列之二十：测试数据生成
- 软件测试入门系列之二十一：测试用例设计技术
- 软件测试入门系列之二十二：边界值分析和等价类划分
- 软件测试入门系列之二十三：决策表
- 软件测试入门系列之二十四：测试评估
- 软件测试入门系列之二十五：测试计划
- 软件测试入门系列之二十六：白盒测试
- 软件测试入门系列之二十七：静态测试
- 软件测试入门之二十八：代码覆盖率
- 软件测试入门系列之三十五：接口测试
软件测试入门系列之一：软件测试基础
已剪辑自: https://zhuanlan.zhihu.com/p/353345086
测试基础
什么是软件测试
软件测试是一种检查软件产品是否符合预期要求并确保软件产品质量的方法。它涉及使用手动或自动化工具执行软件/系统组件，以评估被测产品质量。
软件测试的目的是识别与实际需求设计不一致的错误，差距或遗漏的需求。有些人更喜欢将软件测试称为“白盒测试”和“黑盒测试”。简而言之，软件测试是指对被测应用程序（AUT）的验证。
- 什么是软件测试？
- 为什么软件测试很重要？
- 软件测试有什么好处？
- 软件工程测试
- 软件测试的类型
- 软件工程中的测试策略
- 程序测试
为什么软件测试很重要？
软件测试很重要，因为如果软件中存在任何缺陷，则可以及早发现并可以在交付软件产品之前解决。经过正确测试的软件产品可确保可靠性，安全性和高性能，从而进一步节省时间，降低成本并提高客户满意度。
测试很重要，因为软件缺陷可能代价高昂甚至危险。软件缺陷可能会导致金钱和人员损失，并且历史上充斥着此类示例。
2015年4月，由于软件故障影响了金融市场上300,000多名交易员，伦敦的彭博终端崩溃了。它迫使政府推迟30亿英镑的债务出售。
由于安全气囊感应器软件故障，日产汽车从市场召回了超过100万辆汽车。据报道，由于该软件故障，发生了两次事故。
由于POS系统软件故障，星巴克被迫关闭美国和加拿大约60％的商店。有一次，由于无法处理交易，该商店免费提供了咖啡。
亚马逊的一些第三方零售商由于软件故障而将其产品价格降低到了1便士。他们蒙受了沉重的损失。
Windows 10中的漏洞。此错误使用户可以通过win32k系统中的漏洞逃离安全沙箱。
2015年，战斗机F-35成为软件缺陷的受害者，使其无法正确检测目标。
1994年4月26日，中华航空空中客车A300因软件缺陷坠毁，造成264名无辜者丧生
1985年，加拿大的Therac-25放射治疗机由于软件错误而发生故障，并向患者提供了致命的放射剂量，造成3人死亡，并严重伤害了3人。
1999年4月，一个软件缺陷导致价值12亿美元的军用卫星发射失败，这是历史上最昂贵的事故
1996年5月，一个软件漏洞导致美国一家主要银行的823个客户的银行帐户记入9.2亿美元。
软件测试有什么好处？
以下是使用软件测试的好处：
- 经济高效：这是软件测试的重要优势之一。按时测试任何IT项目都可以帮助您长期节省资金。如果缺陷在软件测试的早期阶段被捕获，则修复成本会降低。
- 安全性：这是软件测试的最脆弱和最敏感的好处。人们正在寻找值得信赖的产品。它有助于尽早消除风险和问题。
- 产品质量：这是任何软件产品的基本要求。测试可确保将优质的产品交付给客户。
- 客户满意度：任何产品的主要目的都是使客户满意。UI / UX测试可确保最佳的用户体验。
软件工程测试
根据ANSI / IEEE 1059，软件工程测试是评估软件产品以验证当前软件产品是否满足需求设计的过程。测试过程涉及产品功能需求验证、安全性测试、可靠性测试和性能测试等。
软件测试类型
测试类型大体上可以分为三类。
- 功能测试
- 非功能测试或性能测试
- 维护测试（回归和维护）
| 测试类别 | 测试类型 |
|---|---|
| 功能测试 | 单元测试、集成测试、冒烟测试、UAT（用户验收测试）、本土化、国际化、可移植性 |
| 非功能测试 | 性能测试、稳定性测试、负载测试、安全性测试、可扩展性测试、易用性测试 |
| 维护测试 | 回归测试、维护测试 |
当然，并非所有测试类型都适用于所有项目，但取决于项目的质量要求。
软件工程中的测试策略
以下是软件工程中的重要策略：
- 单元测试：程序员遵循此软件测试方法来测试程序的单元。它可以帮助开发人员了解代码的各个单元是否正常工作。
- 集成测试：重点在于软件的构建，你需要查看集成单元是否正常运行。
- 系统测试：使用这种方法，你的软件将被整体编译，然后进行整体测试。此测试策略将验证功能，安全性，可移植性等。
程序测试
程序测试是一种执行实际软件程序的方法，旨在测试程序行为并查找程序中存在的错误。软件程序以测试用例驱动，以分析程序对测试数据的响应。
软件测试概要
- 将软件测试定义为一项活动，以检查实际结果是否与预期结果相符并确保软件系统无缺陷。
- 测试很重要，因为软件错误可能代价高昂甚至危险。
- 使用软件测试的重要原因是：成本效益，安全性，产品质量和客户满意度。
- 通常，测试分为三类功能测试，非功能测试或性能测试以及维护。
- 软件工程中的重要策略是：单元测试，集成测试，验证测试和系统测试。
软件测试入门系列之二：软件测试职业规划
已剪辑自: https://zhuanlan.zhihu.com/p/353387239
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hA9avuAq-1681309074012)(https://pica.zhimg.com/v2-040a44ade002526b3dbfbf53a21e34a6_720w.jpg?source=172ae18b)]
软件测试工程师技能要求
- Non-Technical Skills
以下技能对于成为一名优秀的软件质量测试人员至关重要。
- 分析能力：优秀的软件测试人员应该具有敏锐的分析能力。分析能力将有助于将复杂的软件系统分解为较小的单元，以更好地理解需求并设计测试用例。
- 沟通能力：优秀的软件测试人员必须具有良好的口头和书面沟通能力。软件测试人员创建的测试套件（如测试用例/计划、测试策略、错误报告等）应易于阅读和理解。
- 时间管理和组织能力：有时测试是一项艰巨的工作，尤其是在代码发布期间。软件测试人员必须有效地管理工作节奏，让自己持续保持高生产率。
- 积极心态：要成为一名优秀的软件测试人员，你必须具有积极的心态。对“打破测试”的态度，注重细节，愿意学习并改进测试流程。在软件行业中，技术发展势不可挡，优秀的软件测试人员应通过不断变化的技术来升级其技术软件测试技能。
- 热情：要想在任何工作中表现出色，必须对其充满热情。软件测试人员必须对其领域充满热情。
- Technical Skills
- 数据库基本知识：软件系统在后台存储大量数据。这些数据存储在后端的不同类型的数据库中，例如Oracle、MySQL等。在这种情况下，可以使用简单/复杂的SQL查询来检查后端数据库中是否存储了正确的数据。
- Linux基本知识：大多数软件应用程序（如Web服务，数据库，应用程序服务器）都部署在Linux机器上。因此，测试人员必须具备有关Linux命令的知识，这一点至关重要。
- 测试管理工具的知识：测试管理是软件测试的重要方面。没有适当的测试管理技术，软件测试过程将是非常失败的。测试管理本质不过是管理与测试相关的工件而已。例如：可以使用诸如Testlink之类的工具来跟踪团队编写的所有测试用例。
- 任何缺陷管理工具的知识：缺陷跟踪、管理和缺陷生命周期是软件测试的关键方面。正确管理缺陷并以系统的方式跟踪缺陷是至关重要的。整个团队都应该了解缺陷，包括经理，开发人员和测试人员，因此必须进行缺陷跟踪。有几种工具可用于记录缺陷，包括Bugzilla，Jira等。
- 自动化工具的知识：如果你在进行手动测试几年后想向自动化方向转型发展，那么你必须精通自动化工具的使用。
学历要求
软件测试一般要求从业者具备专科以上学历。
软件测试员的职业道路
在典型的CMMI 5级公司中软件测试员（QA Analyst）的软件测试职业发展情况如下所示：
- 质量检查分析师（新人）
- 高级质量检查分析师（2-3年经验）
- 质量检查团队协调员（5-6年的经验）
- 测试经理（8-11年经验）
- 高级测试经理（14年以上经验）
作为软件测试员的职业规划
如果手动测试遇到瓶颈，可以继续考虑以下方向转型：
- 自动化测试：作为自动化测试工程师，您将负责自动化手动执行测试用例，否则可能会很费时。使用的工具IBM Rational Robot，Silk Performer和QTP
- 性能测试：作为性能测试工程师，您将负责检查应用程序的响应能力（花费时间，应用程序可以处理的最大负载）等。工具使用了WEBLoad，Loadrunner。
- 业务分析师：测试人员相对于开发人员的主要优势在于，他们具有端到端的业务知识。对于测试人员而言，明显的测试职业发展趋势是成为一名业务分析师。作为业务分析师，您将负责分析和评估公司的业务模型和工作流程。作为学士学位，您将把这些模型和工作流程与技术集成在一起。
软件测试入门系列之三：软件测试的7条原则
已剪辑自: https://zhuanlan.zhihu.com/p/353387586
软件测试的7条原则
1）测试的不可穷尽原则
是的！任何产品不可能被穷尽测试。我们需要根据应用程序的风险评估来优化测试量。
而重要的是，你如何确定不可穷尽原则带来的测试不完全性风险？
为了回答这个问题，让我们做一个练习
你认为哪种操作最有可能导致你的电脑操作系统出现故障？
我相信大多数人都会猜到，同时打开很多个不同的应用程序。
因此，如果你正在测试此操作系统，你将发现多任务活动场景很可能会发现缺陷，需要对其进行深入的测试。
2）缺陷集群性（2/8原则）（Defect clustering）
缺陷群集，指出少数功能模块包含测试到的大多数缺陷。这是帕累托原理在软件测试中的应用：大约80％的问题出现在20％的功能模块中。
根据经验，你可以识别出有风险的模块。但是这种方法也有局限性，如果重复进行相同的测试，最终同质的测试用例将不会再找到新的缺陷。
3）杀虫剂悖论（Pesticide Paradox）
随着时间的推移，重复使用相同的杀虫剂消灭昆虫会导致昆虫对农药产生抵抗力，从而使杀虫剂对昆虫无效，这同样适用于软件测试。如果进行相同的重复测试，则该方法将无助于发现新的缺陷。
为了解决此问题，需要定期检查和更新测试用例，添加新的和不同的测试用例以帮助发现更多的缺陷。
测试人员不能简单地依靠现有的测试技术。他必须不断寻找改进现有方法的方法，以使测试更有效。
4）测试显示软件存在缺陷（Testing shows presence of defects）
测试显示软件存在缺陷原理指出：测试显示软件中缺陷的存在，但不能证明软件不存在缺陷。也就是说，软件测试可以降低软件中未发现的缺陷的可能性，但是即使没有发现缺陷，也不能证明其正确性。
5）没有错误是好事谬论（Absence of error-fallacy）
99％无错误的软件仍然可能无法使用，如果针对缺陷要求对系统进行了全面测试，则可能是这种情况。软件测试不仅仅是为了发现缺陷，而且还要检查软件是否满足业务需求。没有错误是谬论，即如果系统构建不可用并且无法满足用户的需求，则发现并修复缺陷将无济于事。
6）尽早介入测试（Testing early）
早期测试-测试应在软件开发生命周期中尽早开始。这样就可以在早期阶段捕获需求或设计阶段中的任何缺陷。在测试的早期阶段修复缺陷耗费成本要低得多。但是应该多早开始测试呢？建议你在需求评审环节就开始介入测试发现缺陷。
7）测试活动取决于上下文（Testing is context dependent）
测试是依赖于上下文的，这基本上意味着测试电子商务站点的方式将不同于测试其他应用程序的方式。所有开发的软件都不相同。你可以根据应用程序类型使用不同的方法、技术和测试类型。
软件测试入门系列之四：软件测试V模型
已剪辑自: https://zhuanlan.zhihu.com/p/353477883
软件测试V模型
V模型(Rapid Application Development)是非常重要的SDLC模型，此模型每个开发阶段要求一个测试阶段与之对应。V模型是瀑布模型的扩展，其中在每个阶段进行测试并与对应的开发同步进行，它也被称为验证模型。
关键软件工程术语：
SDLC： SDLC是软件开发生命周期。这包含开发人员设计和开发高质量软件的一系列开发活动。
STLC： STLC是软件测试生命周期。它由测试人员按测试方法进行的一系列测试活动组成。
瀑布模型：瀑布模型是一个顺序模型，分为软件开发活动的不同阶段。每个阶段都旨在执行特定的活动，仅在系统实施完成后，瀑布模型中的测试阶段才开始。
了解V模型
假设你被分配了一项任务，为客户端开发自定义软件。现在，无论你的技术背景如何，都可以对你将要完成的任务的步骤顺序进行有根据的评估。
| 软件开发周期 | 每个阶段进行的活动 |
|---|---|
| 需求收集阶段 | 从客户收集有关所需软件的详细信息和规格的尽可能多的信息。 |
| 设计阶段 | 计划使用Java，PHP等编程语言；数据库，例如Oracle，MySQL等，同时也包含一些高级功能和体系结构。 |
| 开发阶段 | 在设计阶段之后，是开发阶段，仅是对软件进行编码 |
| 测试阶段 | 对软件进行测试，以验证其是否按照客户给出的需求开发。 |
| 部署阶段 | 在相应的环境中部署应用程序 |
| 维护阶段 | 系统准备就绪后，你可能需要根据客户要求更改代码 |
所有这些级别构成了软件开发生命周期的瀑布模型。
瀑布模型的问题
你会看到，只有在产品实现之后才进行测试。
但是，如果你在系统复杂的大型项目中工作，很容易错过需求阶段本身的关键细节。在这种情况下，很有可能会将完全错误的产品将交付给客户，因此会有重新开发项目的风险。
对数千个项目的评估表明，在需求和设计过程中引入的缺陷几乎占缺陷总数的一半。
而且，修复缺陷的成本在整个开发生命周期中是逐渐递增的。在生命周期中越早发现缺陷，修复它的成本就越低。
解决方案：V模型
为了解决此问题，开发了V测试模型，其中在开发生命周期的每个阶段都有一个对应的测试阶段
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iOTh5RA2-1681309074013)(https://pic1.zhimg.com/v2-0ef6581b3678b784b61cc037e6780730_r.jpg)]
模型的左侧是软件开发生命周期-SDLC，模型的右侧是软件测试生命周期-STLC，整个图看起来像V，因此命名为V-模型。
除了V模型外，还有迭代开发模型，其中的开发是分阶段进行的，每个阶段都为软件增加了功能。每个阶段都包含其独立的一组开发和测试活动。迭代方开发模型的优秀案例就是是快速应用程序开发，敏捷开发。
总结
- 测试不是独立的活动，它必须适合项目选择的开发模型。
- 在任何模型中，都应在所有环节进行测试，即从需求阶段到维护阶段为止。
软件测试入门系列之五：软件生命周期
已剪辑自: https://zhuanlan.zhihu.com/p/353482270
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SEgIqR2g-1681309074014)(https://pic1.zhimg.com/v2-eef204fa53619c4232cd339f15bcbfb9_720w.jpg?source=172ae18b)]
软件生命周期
软件测试生命周期（STLC）包含测试过程中执行的一系列特定活动，以确保达到软件质量目标。STLC包含验证和确认的行为。软件测试不仅仅是一个相对独立的活动，它包含一系列通过方法论验证软件产品的活动。
STLC
每个软件测试生命周期模型（STLC模型）都有以下六个主要阶段：
- 需求分析
- 测试计划
- 测试用例设计
- 测试环境搭建
- 测试执行
- 测试周期结束
每个阶段都有一个确切的进入和准出标准，与之相关的活动行为和需要交付的成果。
什么是STLC中的准入和准出准则？
- 准入准则：达到的提测门槛，然后才能开始测试。
- 准出准则：项目交付之前必须达到的要求。
在理想条件下，只有满足上一个阶段的准出条件，才可以进入下一个阶段。
需求阶段测试
需求阶段测试（也称为需求分析），其中测试团队从测试的角度研究需求以识别可测试的需求，并且QA团队可能会与各种利益相关者进行互动以详细了解需求，需求可以是功能性的，也可以是非功能性的，测试项目的自动化可行性评估也在此阶段完成。
需求阶段测试中的活动
- 确定要执行的测试类型。
- 收集有关测试优先级和重点信息。
- 准备需求可追溯性矩阵（RTM）。
- 确定应该执行测试的测试环境详细信息。
- 自动化可行性分析。
- 需求阶段测试的交付物
- RTM
- 自动化可行性报告。
测试计划
STLC中的测试计划是一个阶段，在该阶段中，高级质量检查经理确定测试计划策略以及项目的工作量和成本估算。此外，还确定了资源、测试环境、测试限制和测试计划。在同一阶段准备并最终确定测试计划。
测试计划活动
- 准备用于各种类型测试的测试计划/策略文档
- 测试工具的选择
- 测试工作量评估
- 资源计划以及确定角色和职责。
- 培训要求
- 测试计划的可交付成果
- 测试计划/策略文档。
- 工作量评估文档。
测试用例设计阶段
该测试案例开发阶段涉及到创建，验证和测试案例和测试脚本返工后的测试计划已准备就绪。最初，确定测试数据，然后创建和检查，然后根据先决条件进行重新处理。然后，QA团队开始针对单个单元的测试用例的开发过程。
测试用例开发活动
- 创建测试用例，自动化脚本
- 审查基准测试用例和脚本
- 创建测试数据
- 测试用例开发的可交付成果
- 测试用例/脚本
- 测试数据
测试环境搭建
测试环境安装程序决定测试工作产品的软件和硬件条件。它是测试过程的关键方面之一，可以与测试用例开发阶段同时进行。如果开发团队提供测试环境，则测试团队可能不会参与此活动。测试团队需要对给定的环境进行准备情况检查（烟雾测试）。
测试环境设置活动
- 了解所需的体系结构，环境设置，并准备测试环境的硬件和软件要求列表。
- 搭建测试环境和构造测试数据
- 在构建上执行冒烟测试
- 交付冒烟测试结果
测试执行阶段
测试执行阶段由测试人员执行，在测试人员阶段，将根据准备的测试计划和测试用例对软件版本进行测试。该过程包括测试脚本执行，测试脚本维护和错误报告。如果报告了错误，则将其返回给开发团队进行更正并进行重新测试。
测试执行活动
- 按照计划执行测试
- 记录测试结果，并记录失败案例的缺陷
- 将缺陷映射到RTM中的测试用例
- 重新测试缺陷修复程序
- 跟踪缺陷以解决问题
- 测试执行的可交付成果
- 具有执行状态的已完成RTM
- 测试用例更新结果
- 缺陷报告
测试周期结束
测试周期结束阶段是测试执行的完成，其中涉及多项活动，例如测试完成报告，测试完成矩阵和测试结果的收集。测试团队成员会面，讨论和分析测试工件，以从当前测试周期中汲取教训，从而确定将来必须实施的策略。这个想法是为了消除将来测试周期的过程瓶颈。
测试周期关闭活动
- 根据时间，测试范围，成本，软件，关键业务目标，质量评估周期完成标准
- 根据上述参数准备测试指标。
- 记录项目中的学习情况
- 准备测试结束报告
- 向客户定性和定量报告工作产品的质量。
- 测试结果分析，以按类型和严重性找出缺陷分布。
- 测试周期结束的可交付成果
- 测试结束报告
- 测试指标
STLC各阶段以及准入和准出准则
| STLC舞台 | 入学标准 | 活动 | 退出条件 | 可交付成果 |
|---|---|---|---|---|
| 需求分析 | 需求文档可用（功能性和非功能性）定义了验收标准。可用的应用程序体系结构文档。 | 分析业务功能以了解业务模块和模块的特定功能。识别模块中的所有事务。识别所有用户配置文件。收集用户界面/身份验证，地理分布要求。确定要执行的测试类型。收集有关测试优先级和重点的详细信息。准备需求可追溯性矩阵（RTM）。确定应该执行测试的测试环境详细信息。自动化可行性分析（如果需要）。 | 退出RTM客户签署的测试自动化可行性报告 | RTM自动化可行性报告（如果适用） |
| 测试计划 | 需求文件需求可追溯性矩阵。测试自动化可行性文件。 | 分析各种可用的测试方法最终确定最适合的方法准备用于各种类型测试的测试计划/策略文档测试工具的选择测试工作量估算资源计划以及确定角色和职责。 | 批准的测试计划/策略文件。工作量估算文件已签署。 | 测试计划/策略文件。工作量估算文件。 |
| 测试案例开发 | 需求文件RTM和测试计划自动化分析报告 | 创建测试用例，测试设计，自动化脚本（如果适用）审查和基准测试用例和脚本创建测试数据 | 审查并签署测试用例/脚本审查并签署了测试数据 | 测试用例/脚本测试数据 |
| 测试环境设置 | 提供系统设计和体系结构文档提供环境设置计划 | 了解所需的架构，环境设置准备硬件和软件开发要求列表最终确定连接要求准备环境设置清单设置测试环境和测试数据在构建上执行烟雾测试根据烟雾测试结果接受/拒绝构建 | 环境设置正在按照计划和清单进行测试数据设置完成烟雾测试成功 | 准备好环境并设置测试数据烟雾测试结果。 |
| 测试执行 | 提供基准RTM，测试计划，测试用例/脚本测试环境已准备就绪测试数据设置完成提供了要测试的构建的单元/集成测试报告 | 按照计划执行测试记录测试结果，并记录失败案例的缺陷如有必要，更新测试计划/测试用例将缺陷映射到RTM中的测试用例重新测试缺陷修复程序应用程序的回归测试跟踪缺陷以解决问题 | 执行所有计划的测试记录缺陷并跟踪缺陷以将其关闭 | 具有执行状态的已完成RTM测试用例更新结果缺陷报告 |
| 测试周期结束 | 测试已经完成测试结果可用缺陷日志可用 | 根据时间，测试范围，成本，软件质量，关键业务目标评估周期完成标准根据上述参数准备测试指标。记录项目中的学习情况准备测试结束报告向客户定性和定量报告工作产品的质量。测试结果分析，以按类型和严重性找出缺陷分布 | 客户签署的测试结束报告 | 测试结束报告测试指标 |
软件测试入门系列之六：手工测试
已剪辑自: https://zhuanlan.zhihu.com/p/353488420
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KVK8TOuq-1681309074014)(https://picx.zhimg.com/v2-612b4134d2bb04f9fa3ddf85d129d8c2_720w.jpg?source=172ae18b)]
手工测试
手工测试是一种软件测试的类型，其中测试人员无需使用任何自动化工具即可手动执行测试用例。手工测试的目的是识别软件应用程序中的错误、问题和缺陷。手工软件测试是所有测试类型中最原始的技术，它有助于发现软件应用程序中的关键缺陷。
任何新应用程序都必须先进行手工测试，然后才能使其测试自动化。手工软件测试需要更多的精力，但对于检查自动化的可行性是必需的。手工测试概念不需要任何测试工具的知识。软件测试基础之一是“不可能实现100％自动化”。这使得手工测试势在必行。
手工测试的目的
手工测试的关键概念是确保应用程序无错误，并且符合指定的功能要求。
测试套件是在测试阶段设计的，应具有100％的测试覆盖率，它还可以确保提交的缺陷已由开发人员修复，并且测试人员已对已修复的缺陷进行了重新测试。
手工测试的类型
上图显示了手工测试类型。实际上，任何类型的软件测试类型都可以手工执行，也可以使用自动化工具执行。
- 黑盒测试
- 白盒测试
- 单元测试
- 系统测试
- 集成测试
- 验收测试
如何执行手工测试
- 阅读并了解软件项目文档/指南。此外，如果可用，请研究被测应用程序（AUT）。
- 涵盖文档中提到的所有要求的测试用例草稿。
- 与团队负责人，客户一起审查测试案例并确定基线
- 在AUT上执行测试用例
- 报告错误。
- 修复错误后，再次执行失败的测试用例以验证它们是否通过。
手工测试与自动化测试
| 手工测试 | 自动化测试 |
|---|---|
| 手工测试需要人工干预才能执行测试。 | 自动化测试是使用工具来执行测试用例 |
| 手工测试将需要熟练的劳动力，长时间且隐含高成本。 | 自动化测试可以节省时间，成本和人力。记录后，运行自动化测试套件会更容易 |
| 任何类型的应用程序都可以手动进行测试，某些测试类型（例如临时测试和猴子测试）更适合手动执行。 | 自动测试仅建议用于稳定的系统，并且主要用于回归测试 |
| 手工测试是无聊枯燥的。 | 一次又一次地执行相同测试用例的无聊部分由自动化测试中的自动化软件处理。 |
软件测试入门系列之七：自动化测试
已剪辑自: https://zhuanlan.zhihu.com/p/353489122
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-I4Mw1UGS-1681309074015)(https://pic1.zhimg.com/v2-7a7c59c2c13baf72456c53acc493eb8d_720w.jpg?source=172ae18b)]
什么是自动化测试？
自动化测试或测试自动化是一种软件测试技术，它使用自动化测试工具来执行测试用例套件。相反，手工测试是由坐在计算机前的人员仔细执行测试步骤来执行的。
自动化测试软件还可以将测试数据输入被测系统，比较预期结果和实际结果，并生成详细的测试报告。软件测试自动化需要大量的金钱和资源投资。
连续的开发周期将需要重复执行相同的测试套件。使用测试自动化工具，可以记录该测试套件并根据需要重复执行。一旦测试套件自动化，就无需人工干预。这提高了测试自动化的投资回报率。自动化的目标是减少手动运行的测试用例的次数，而不是完全消除手动测试。
为什么要进行自动化测试？
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fujkrMRc-1681309074015)(https://pic4.zhimg.com/80/v2-be4777574ff7a546e50e7fd5d0fa39e7_1440w.webp)]
自动化测试是提高软件测试的有效性、测试范围和执行速度的最佳方法。由于以下原因，自动化测试非常重要：
- 手动测试所有工作流、所有阶段都需要花费时间和金钱
- 手动测试多语言站点很困难
- 软件测试中的自动化测试不需要人工干预
- 自动化测试可提高测试执行速度
- 自动化有助于增加测试范围
- 长时间手工测试可能会变得很无聊，因此容易出错
哪些测试用例可以自动化？
可以使用以下标准选择要自动化的测试用例，以提高自动化的投资回报率
- 高风险-关键业务测试案例
- 重复执行的测试用例
- 非常繁琐或难以手动执行的测试用例
- 耗时的测试用例
以下类别的测试用例不适合自动化：
- 新设计的测试用例，并且至少一次不手动执行
- 需求经常变化的测试用例
- 临时执行的测试用例
自动化测试流程
自动化过程中遵循以下步骤
步骤1）选择测试工具
步骤2）定义自动化范围
步骤3）规划，设计和开发
步骤4）测试执行
步骤5）维护
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XnFQ4XBw-1681309074015)(https://pic1.zhimg.com/v2-9acb8ccf04623e987eb47f0fc7790528_r.jpg)]
测试工具的选择
测试工具的选择很大程度上取决于被测应用程序所基于的技术。例如Postman不能用于UI自动化，只能适用于接口测试。
定义自动化范围
自动化范围是被测应用程序中将被自动化的区域。以下几点有助于确定范围：
- 对业务很重要的功能
- 有大量数据的方案
- 跨应用程序的通用功能
- 技术可行性
- 业务组件的重用程度
- 测试用例的复杂性
- 能够使用相同的测试用例进行跨浏览器测试
规划，设计和开发
在此阶段，您将创建一个自动化策略和计划，其中包含以下详细信息：
- 选择自动化工具
- 框架设计及其功能
- 自动化项目
- 自动化测试环境准备
- 脚本和执行的时间表
- 自动化测试的交付物
测试执行
在此阶段执行自动化脚本需要输入测试数据才能运行。一旦执行，他们将提供详细的测试报告。
可以直接使用自动化工具执行执行，也可以通过将调用自动化工具的测试管理工具执行执行。
示例：质量中心是测试管理工具，它将依次调用QTP来执行自动化脚本。脚本可以在一台机器或一组机器中执行，可以在夜间执行，以节省时间。
自动化测试维护方法
自动化测试维护方法是一个自动化测试阶段，用于测试添加到软件中的新功能是否正常运行。当添加新的自动化脚本并需要对其进行检查和维护时，将执行自动化测试中的维护，以提高每个后续发布周期中自动化脚本的有效性。
自动化框架
框架是一套自动化准则，可帮助
- 保持测试的一致性
- 改善测试结构
- 最少使用代码
- 减少代码维护
- 提高可重用性
- 非技术测试人员可以参与代码
- 可以减少使用该工具的培训时间
- 适当时涉及数据
自动化测试中常用的四种框架：
- 数据驱动的自动化框架
- 关键字驱动的自动化框架
- 模块化自动化框架
- 混合自动化框架
自动化工具最佳实践
为了获得最大的自动化投资回报，请注意以下几点
-
在项目开始之前，需要详细确定自动化范围，这为自动化设定了期望。
-
选择正确的自动化工具：一定不能根据工具的流行程度来选择它，但是它符合自动化要求。
-
选择合适的框架
-
脚本标准-编写自动化脚本时必须遵循标准。他们之中有一些是-
-
- 创建统一的脚本，注释和代码缩进
- 适当的异常处理-系统故障或应用程序异常行为时如何处理错误。
- 用户定义的消息应进行编码或标准化，以供测试人员理解错误记录。
-
衡量指标-不能通过将手动工作与自动化工作进行比较，也可以通过捕获以下指标来确定自动化是否成功。
-
- 发现缺陷的百分比
- 每个发布周期进行自动化测试所需的时间
- 释放时间最短
- 顾客满意度指数
- 生产率提高
如果遵守上述准则，则可以极大地帮助你成功实现自动化。
自动化测试的好处
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4eJJYGcB-1681309074016)(https://pic1.zhimg.com/80/v2-b8c149cf7f1f17e623562e7374fb7bfc_1440w.webp)]
以下是测试自动化的好处：
- 比手动测试快70％
- 应用功能的测试范围更广
- 结果可靠
- 确保一致性
- 节省时间和成本
- 提高准确性
- 执行时不需要人工干预
- 提高效率
- 执行测试的速度更快
- 可重复使用的测试脚本
- 通过自动化可以实现更多的执行周期
- 产品提前上市
如何选择自动化工具？
选择正确的工具可能是一项艰巨的任务。遵循以下标准将帮助您选择最适合你需求的工具：
- 环境支持
- 易上手
- 数据库测试
- 对象识别
- 图像测试
- 缺陷修复测试
- 对象映射
- 使用的脚本语言
- 支持各种类型的测试-包括功能，测试管理，移动等。
- 支持多种测试框架
- 易于调试自动化软件脚本
- 能够在任何环境下识别事物
- 可扩展测试报告和结果
- 最大限度地减少所选工具的培训成本
综述
- 自动化测试是一种软件测试技术，它使用特殊的自动化测试软件工具来执行测试用例套件。
- 自动化测试是提高软件测试的有效性，测试范围和执行速度的最佳方法。
- 测试工具的选择很大程度上取决于被测应用程序所基于的技术。
软件测试入门系列之八：手工测试VS自动化测试
已剪辑自: https://zhuanlan.zhihu.com/p/354933305
关键区别
- 手工测试是由质量保障工程师手工完成的，而自动化测试是由测试人员使用测试脚本、代码和自动化工具（计算机）完成的。
- 手工测试过程会出现人为因素导致的测试不可靠性，而自动化测试则是可靠的，它是基于代码和脚本的。
- 手工测试相对比较耗时，而自动化测试则非常快。
- 没有编程知识可以从事手工测试，而没有编程知识就不能胜任自动化测试。
- 手工测试允许探索性测试，而自动化测试则不允许探索性测试。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1WKbCrfh-1681309074016)(https://pic3.zhimg.com/v2-c665e244e42f162c33fa43b709f6c7aa_r.jpg)]
手工测试和自动化测试的区别
| 范围 | 自动化测试 | 手工测试 |
|---|---|---|
| 定义 | 自动化测试使用自动化工具来执行测试用例。 | 在手工测试中，测试用例由测试人员手工执行。 |
| 效率 | 自动化测试比手工方法要快得多。 | 手工测试很耗时，并且占用人力资源。 |
| 探索性测试 | 自动化不允许探索性测试 | 可以在手工测试中进行探索性测试 |
| 投入成本 | 自动化测试的初始投资较高。尽管从长远来看投资回报率会更好。 | 手工测试的初始投资相对较低。从长远来看，与自动化测试相比，ROI较低。 |
| 可靠性 | 自动化测试是一种可靠的方法，因为它是由工具和脚本执行的，不存在测试疲劳。 | 由于人为错误的可能性，手工测试的准确性相对不高。 |
| 测试介质的变动影响 | 对于AUT的用户界面来说，即使是微不足道的更改，也需要修改自动测试脚本以使其按预期工作。 | 诸如按钮的id，class等的微小更改不会妨碍手工测试器的执行。 |
| 性价比 | 低容量回归的成本效益不高 | 高容量回归的成本效益不高。 |
| 测试报告 | 借助自动化测试，所有利益相关者都可以登录自动化系统并检查测试执行结果 | 手工测试通常记录在Excel或Word中，测试结果不易获得。 |
| 观察 | 自动化测试不涉及人为因素。因此，它永远无法保证用户友好性和积极的客户体验。 | 手工测试方法允许人工观察，这可能对提供用户友好的系统很有用。 |
| 性能测试 | 诸如负载测试，压力测试，峰值测试等性能测试必须由自动化工具强制进行测试。 | 手工进行性能测试是不可行的 |
| 并行执行 | 可以在不同的操作平台上并行执行此测试，并减少测试执行时间。 | 手工测试可以并行执行，但需要增加人力资源，这很昂贵 |
| 批量测试 | 您可以批处理多个测试脚本以每晚执行。 | 手工测试无法批量进行。 |
| 编程知识 | 在自动化测试中，必须具备编程知识。 | 无需在手工测试中进行编程。 |
| 理想方法 | 频繁执行相同的测试用例集时，自动化测试非常有用 | 当测试用例只需要运行一次或两次时，手工测试就非常有用。 |
| 建立验证测试 | 自动化测试对于构建验证测试（BVT）很有用。 | 在手工测试中，执行构建验证测试（BVT）非常困难且耗时。 |
| 截止期限 | 自动化测试错过预先确定的测试的风险为零。 | 手工测试可能会错过预定的测试期限。 |
| 框架 | 自动化测试使用诸如Data Drive，Keyword，Hybrid之类的框架来加速自动化过程。 | 手工测试不使用框架，但可以使用准则、清单、严格的流程来规范测试用例。 |
| 文献资料 | 自动化测试充当提供培训价值的文档，尤其是对于自动化单元测试用例。新开发人员可以研究单元测试用例并快速了解代码库。 | 手工测试用例没有任何培训价值 |
| 测试设计 | 自动化单元测试强制/驱动测试驱动的开发设计。 | 手工单元测试不会使设计进入编码过程 |
| 开发者 | 自动化测试有助于构建验证测试，并且是DevOps Cycle不可或缺的一部分 | 手工测试违反了DevOps的自动构建原则 |
| 适用场景 | 自动化测试适用于回归测试，性能测试，负载测试或高度可重复的功能测试用例。 | 手工测试适用于探索性，可用性和临时测试。在AUT频繁变化的地方也应使用它。 |
软件测试入门系列之九：单元测试
已剪辑自: https://zhuanlan.zhihu.com/p/354964397
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-b3XZsEsP-1681309074016)(https://picx.zhimg.com/v2-48c9fc8a65107a4ecdd04f64ccd3116c_720w.jpg?source=172ae18b)]
什么是单元测试？
单元测试是一种软件测试方法，测试软件的各个单元或组件。目的是验证软件代码的每个单元是否按预期执行得到预期结果。单元测试由开发人员在应用程序的开发（编码阶段）中完成。单元可以是单独的功能、方法、过程、模块或对象。
在SDLC、STLC、V模型中，单元测试是集成测试之前完成的第一层级测试。单元测试属于白盒测试技术，通常由开发人员执行。不过，由于时间紧迫或开发人员不愿进行测试，测试工程师也会进行单元测试。
为什么要进行单元测试？
单元测试非常重要，如果在早期开发中进行了正确的单元测试，则最终可以节省时间和金钱。
- 单元测试有助于在开发周期的早期修复缺陷并节省开发成本。
- 它可以帮助开发人员了解测试代码，并使他们能够快速进行更改。
- 好的单元测试可以作为项目文档。
- 单元测试有助于代码复用。
如何进行单元测试
为了进行单元测试，开发人员编写了一段代码来测试软件应用程序中的特定功能。开发人员还可以隔离此功能模块以进行更严格的测试，从而揭示出被测试功能与其他单元之间不必要的依赖关系，因此可以消除模块间的依赖关系。开发人员通常使用UnitTest单测框架来开发用于单元测试的自动化测试用例。
单元测试有两种类型
- 手动
- 自动化
单元测试通常是自动化的，但仍可以手动执行。软件工程并不偏爱哪一种，但自动化是首选。手动进行单元测试的方法可以使用分步指导文档。
自动化方法
- 开发人员在应用程序中编写一段测试某功能的代码。
- 开发人员还可以隔离功能以进行更严格的测试。这是一种更彻底的单元测试实践，其中涉及将代码复制和粘贴到其自身的测试环境中，而不是自然环境中。隔离代码有助于揭示被测代码与产品中其他单元或数据空间之间不必要的依赖关系。
- 编码人员通常使用UnitTest/junit/Pytest等框架来开发自动化测试用例。开发人员使用自动化框架将标准编码到测试中，以验证代码的正确性。在执行测试用例期间，框架记录失败的测试用例。许多框架还将自动标记并报告这些失败的测试案例。
- 单元测试的工作流程是1）创建测试用例 2）复查/返工 3）建立基准 4）执行测试用例。
单元测试技术
下面列出了单元测试中使用的代码覆盖技术：
- 声明范围
- 决策范围
- 分支机构覆盖率
- 条件覆盖
- 有限状态机覆盖率
单元测试示例：mock对象
单元测试依赖于创建的mock对象来测试尚不属于完整应用程序的代码部分。mock对象填充程序缺少的部分。
例如，你可能具有一个需要尚未创建的变量或对象的函数。在单元测试中，这些将以mock对象的形式解决，这些对象仅出于在该部分代码上进行单元测试的目的而创建。
单元测试工具
有几种自动化的单元测试软件可用于协助单元测试：
Junit：Junit是可免费使用的Java编程语言测试工具。它提供断言以标识测试方法。该工具首先测试数据，然后将其插入代码段中。
NUnit：NUnit被广泛用于所有.net语言的单元测试框架。它是一个开放源代码工具，允许手动编写脚本。它支持可以并行运行的数据驱动测试。
JMockit：JMockit是开源的单元测试工具。它是具有行和路径度量的代码覆盖工具。它允许带有记录和验证语法的模拟API。此工具提供“线路覆盖率”，“路径覆盖率”和“数据覆盖率”。
EMMA：EMMA是一个开源工具包，用于分析和报告用Java语言编写的代码。Emma支持覆盖类型，例如方法，行，基本块。它基于Java，因此它没有外部库依赖关系，并且可以访问源代码。
PHPUnit：PHPUnit是用于PHP程序员的单元测试工具。它只占用一小部分称为单元的代码，并分别测试每个单元。该工具还允许开发人员使用预定义断言方法来断言系统以某种方式运行。
这些只是一些可用的单元测试工具。还有很多，尤其是对于C语言和Java，但是无论使用哪种语言，您都一定会找到满足您的编程需求的单元测试工具。
测试驱动开发（TDD）和单元测试
TDD中的单元测试涉及测试框架的广泛使用。为了创建自动化的单元测试，使用了单元测试框架。单元测试框架不是TDD独有的，但对于它来说是必不可少的。下面我们看一下TDD带给单元测试领域的一些内容：
- 测试是在代码之前编写的
- 高度依赖测试框架
- 应用程序中的所有类均经过测试
- 快速简便的集成成为可能
软件测试入门系列之十：集成测试
已剪辑自: https://zhuanlan.zhihu.com/p/354967307
什么是集成测试？
集成测试被定义为一种测试类型，其中软件的不同模块被集成并作为一个整体进行测试。一个典型的软件项目由多个软件模块组成，这些模块由不同的程序员进行编码。集成测试的目的是在集成这些不同的软件模块时揭示它们之间交互中的缺陷。
集成测试专注于检查这些模块之间的数据通信。因此，它也被称为“ I＆T” （集成和测试）。
为什么要进行集成测试？
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rfCm533U-1681309074017)(https://pic3.zhimg.com/v2-4803fbf71f568a88c53b79c0e980bf7a_r.jpg)]
尽管每个软件模块都经过了单元测试，但由于各种原因，缺陷仍然存在，例如
- 通常，模块是由单个软件开发人员设计的，他们的理解和编程逻辑可能与其他程序员不同，必须进行集成测试，以验证软件模块可以统一工作。
- 在模块开发时，客户有很大的机会改变需求。这些新要求可能未经过单元测试，因此必须进行系统集成测试。
- 软件模块与数据库的接口可能是错误的
- 外部硬件接口（如果有）可能是错误的
- 异常处理不充分可能会导致问题。
- 新开发的功能模块代码合并到主分支代码需要进行集成测试。
集成测试用例示例
集成测试用例与其他测试用例的不同之处在于，它主要关注模块之间的接口和数据/信息流。在此优先考虑集成链接，而不是已经测试的单元功能。
以下场景的集成测试示例：应用程序具有3个模块，分别是“登录页面”，“邮箱”和“删除电子邮件”，并且每个模块都在逻辑上进行了集成。
这里不必过多地关注登录页面测试，因为它已经在单元测试中完成了。但是，请检查它如何链接到“邮箱页面”。
同样的邮箱：检查其与“删除邮件”模块的集成。
| 测试用例ID | 测试用例目标 | 测试用例 | 预期结果 |
|---|---|---|---|
| 1个 | 检查“登录”和“邮箱”模块之间的接口链接 | 输入登录凭据，然后单击“登录”按钮 | 被定向到邮箱 |
| 2个 | 检查邮箱和删除邮件模块之间的接口链接 | 从邮箱中选择电子邮件，然后单击删除按钮 | 所选电子邮件应显示在“已删除/已删除邮件”文件夹中 |
集成测试的方法、策略和方法论
软件工程定义了各种策略来执行集成测试：
-
大爆炸法
-
增量方法。进一步细分为以下几种
-
- 自上而下的方法
- 自下而上的方法
- 三明治方法-自上而下和自下而上的组合
以下是不同的策略，执行方式以及其局限性和优势。
大爆炸测试
Big Bang Testing是一种集成测试方法，其中所有组件或模块都立即集成在一起，然后作为一个单元进行测试。测试时，这组组合的组件被视为一个实体。如果单元中的所有组件均未完成，则集成过程将不会执行。
好处：
- 适用于小型系统。
缺点：
- 故障定位很困难
- 考虑到在这种方法中需要测试的接口数量众多，很容易会漏掉一些要测试的接口链接。
- 由于集成测试只能在设计完“所有”模块之后才能开始，因此测试团队在测试阶段的执行时间将减少。
- 由于所有模块都经过一次测试，因此高风险关键模块不会被隔离并优先进行测试。处理用户界面的外围模块也不是隔离的，并且不会进行优先级测试。
增量测试
在增量测试方法中，通过集成两个或多个彼此逻辑相关的模块来进行测试，然后对应用程序的正常功能进行测试。然后，其他相关模块以增量方式集成，并且该过程继续进行，直到所有逻辑相关的模块成功集成并测试为止。
增量方法又可以通过两种不同的方法来执行：
- 自下而上
- 自顶向下
插桩和驱动程序
插桩和驱动程序是集成测试中的伪程序，用于促进软件测试活动。这些程序可以替代测试中缺少的模型。它们没有实现软件模块的整个编程逻辑，但是它们在测试时模拟了与调用模块的数据通信。
插桩：由被测模块调用。
驱动程序：调用要测试的模块。
自下而上的集成测试
自下而上的集成测试是一种策略，其中首先测试较低级别的模块。然后，这些经过测试的模块将进一步用于促进更高级别模块的测试。该过程将继续进行，直到测试了所有顶层模块为止。一旦较低级别的模块经过测试和集成，便形成了下一个级别的模块。
图解表示法：
好处：
- 故障定位更容易。
- 不像Big-bang方法那样浪费时间等待所有模块的开发
缺点：
- 控制应用程序流程的关键模块（在软件体系结构的最高级别）最后经过测试，并且可能容易出现缺陷。
- 早期的原型是不可能的
自上而下的集成测试
自上而下的集成测试是一种按照软件系统的控制流程从上到下进行集成测试的方法。首先测试较高级别的模块，然后再测试和集成较低级别的模块，以检查软件功能。插桩用于测试某些模块是否尚未就绪。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kN2JaecW-1681309074018)(https://pic2.zhimg.com/v2-8d95717dbf17732f1945c4e47dea39e9_r.jpg)]
好处：
- 故障定位更容易。
- 有可能获得早期的原型。
- 关键模块按优先级进行测试；可以发现并修复主要的设计缺陷。
缺点：
- 需要许多插桩。
- 较低级别的模块未充分测试。
三明治测试
三明治测试是一种策略，其中顶层模块与底层模块同时进行测试，同时底层模块与顶层模块集成在一起并作为系统进行测试。它是自顶向下和自底向上方法的组合，因此被称为混合集成测试。它同时使用了插桩和驱动程序。
如何进行集成测试？
集成测试过程，与软件测试策略无关（如上所述）：
- 准备整合测试计划
- 设计测试方案，案例和脚本。
- 执行测试用例，然后报告缺陷。
- 跟踪并重新测试缺陷。
- 重复步骤3和4，直到成功完成集成。
集成测试计划的简要说明：
它包括以下属性：
- 测试方法/方法（如上所述）。
- 集成测试的范围和超出范围的项目。
- 角色和职责。
- 集成测试的先决条件。
- 测试环境。
- 风险和缓解计划。
集成测试的进入和准出标准
任何软件开发模型中集成测试阶段的进入和退出条件
准入标准：
- 单元测试的组件/模块
- 修复并关闭了所有高优先级的错误
- 所有要编码的模块都已成功完成并集成。
- 集成测试计划，测试用例，要签署和记录的方案。
- 设置集成测试所需的测试环境
准出条件：
- 集成应用程序的成功测试。
- 已执行的测试用例已记录在案
- 修复并关闭了所有高优先级的错误
- 要提交的技术文件，然后是发行说明。
集成测试的最佳实践
- 首先，确定可以采用的集成测试策略，然后相应地准备测试用例和测试数据。
- 研究应用程序的体系结构设计并确定关键模块。这些需要优先进行测试。
- 向建筑团队获取接口设计，并创建测试用例以详细验证所有接口。与数据库/外部硬件/软件应用程序的接口必须经过详细测试。
- 在测试用例之后，至关重要的是测试数据。
- 在执行之前，请始终准备好模拟数据。执行测试用例时不要选择测试数据。
软件测试入门系列之十一：什么是系统测试？
已剪辑自: https://zhuanlan.zhihu.com/p/354969262
什么是系统测试？
系统测试包括测试完全集成的软件系统。通常，计算机系统是通过软件集成制成的。换句话说，一组软件的计算机系统执行各种任务，但只有软件才能执行任务; 软件必须与兼容的硬件接口。系统测试是一系列不同类型的有目的的测试行使和审查针对需求的集成软件的计算机系统的全部工作。
系统测试是黑匣子
软件测试两种类型：
- 黑盒测试
- 白盒测试
系统测试属于软件测试的黑盒测试类别。
白盒测试是对软件应用程序内部工作或代码的测试。相反，黑盒测试或系统测试则相反。从用户的角度来看，系统测试涉及软件的外部工作。
系统测试验证什么？
- 测试包括外部外围设备在内的完全集成的应用程序，以检查组件之间以及整个系统之间如何交互。这也称为端到端测试方案。
- 验证对应用程序中每个输入的全面测试，以检查所需的输出。
- 测试用户对应用程序的体验。
这是系统测试所涉及内容的非常基本的描述，需要构建详细的测试用例和测试套件，以测试应用程序的各个方面，而无需查看实际的源代码。
软件测试层次结构
与几乎所有软件工程过程一样，软件测试具有规定的执行顺序。以下是按时间顺序排列的软件测试类别的列表。这些是对新软件进行全面测试以准备将其推向市场的步骤：
- 在开发过程中，对每个模块或代码块执行单元测试。
- 在将新模块集成到主软件包之前，之中和之后进行的集成测试。这涉及测试每个单独的代码模块。一件软件可以包含多个模块，这些模块通常由几个不同的程序员创建。测试每个模块对整个程序模型的影响至关重要。
- 在将完整的软件产品投放市场之前，由专业的测试代理对完成的软件产品进行系统测试。
- 验收测试-实际最终用户对产品进行的Beta测试。
不同类型的系统测试
下面列出了大型软件开发公司通常使用的系统测试类型
- 可用性测试-主要关注用户对应用程序的易用性，处理控件的灵活性以及系统满足其目标的能力
- 负载测试-了解软件解决方案将在实际负载下运行的必要条件。
- 回归测试-进行测试以确保在开发过程中所做的任何更改都不会引起新的错误。它还可以确保随着时间的推移添加新软件模块不会出现旧错误。
- 恢复测试-已完成以证明软件解决方案可靠，可信赖并且可以成功地从可能的崩溃中恢复来进行。
- 迁移测试-以确保可以将软件从较早的系统基础结构迁移到当前的系统基础结构，而不会出现任何问题。
- 功能测试-也称为功能完整性测试，功能测试包括尝试考虑任何可能缺少的功能。测试人员可能会列出产品在功能测试期间可能需要改进的其他功能的列表。
- 硬件/软件测试-IBM将硬件/软件测试称为“硬件/软件测试”。这是测试人员在系统测试期间将注意力集中在硬件和软件之间的交互上的时候。
软件测试入门系列之十二：什么是冒烟测试？
冒烟测试就是完成一个新版本的开发后，对该版本最基本的功能进行测试，如果通过测试，才会进行下一步的测试(功能测试，集成测试，系统测试等等)。冒烟测试的目的就是为了减小 软件的测试成本！试想一下，如果完成的一个版本，不去做冒烟测试，而是直接去做余下的测试，做着做着发现做不下去了，因为测试过程中发现最基本的业务功能模块都存在bug，更别说相关的其他功能模块了，更别说集成测试等其他测试了，而bug发现的越早其修复bug所耗费的成本越低，如果不做冒烟测试，可以想象成本代价风险多高！
回归测试我有两层理解，一是就是当你修复一个bug后，把之前的测试用例再次应用到修复后的版本上进行测试。二是当一个新版本开发好后，而且冒烟测试通过，此时可以先用上一个版本的测试用例对新版本进行测试，看是否有bug！其实回归测试用的很多，比如新增加一个功能模块等等，所以动化测试可以高效率的进行回归测试。
软件测试入门系列之十三：什么是回归测试？
已剪辑自: https://zhuanlan.zhihu.com/p/354972718
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sPhyX2yb-1681309074019)(https://picx.zhimg.com/v2-4713447b434475b2412af51a04ed56aa_720w.jpg?source=172ae18b)]
什么是回归测试？
回归测试被定义为一种软件测试类型，以确认新的程序或代码更改未对现有功能产生影响。
回归测试只不过是全部或部分选择已执行的测试用例，然后重新执行以确保现有功能正常运行。
是否需要回归测试
回归测试主要应用在代码变更的场景，我们需要测试修改后的代码是否影响软件应用程序的其他功能。此外，当将新功能添加到软件应用程序中并用于缺陷修复和性能问题修复时，同样需要进行回归测试。
如何进行回归测试
为了执行回归测试过程，我们需要首先调试代码以识别错误。一旦发现错误，就进行必要的更改以修复它，然后通过从涵盖代码的修改部分和受影响部分的测试套件中选择相关的测试用例来完成回归测试。
软件维护是一系列活动，其中包括增强、纠错、优化和删除现有功能。这些修改可能会导致系统无法正常工作。因此，回归测试变得必要。可以使用以下技术进行回归测试：
重新测试
这是用于回归测试的方法之一，在该方法中，应重新执行现有测试套件或套件中的所有测试。
回归测试的选择
回归测试选择是一种技术，其中执行从测试套件中选择的一些测试用例，以测试修改后的代码是否影响软件应用程序。测试用例分为两部分，可重用的测试用例可以在进一步的回归周期中使用，而过时的测试用例则不能在后续的周期中使用。
测试用例的优先级
根据业务影响，关键和常用功能对测试用例进行优先级排序。根据优先级选择测试用例将大大减少回归测试套件。
选择测试用例进行回归测试
从行业数据中发现，客户报告的大量缺陷是由于最后一刻的错误修复产生的副作用，因此选择测试用例进行回归测试不是一件容易的事，而是一门艺术。可以通过选择以下测试用例来完成有效的回归测试。
- 经常有缺陷的测试用例
- 对用户更可见的功能
- 验证产品核心功能的测试用例
- 经历了更多和最新变化的功能测试用例
- 所有集成测试用例
- 所有复杂的测试用例
- 边值测试用例
- 成功的测试用例样本
- 失败测试案例样本
回归测试工具
如果您的软件进行频繁更改，则回归测试成本将上升。在这种情况下，手动执行测试用例会增加测试执行时间和成本。在这种情况下，自动化回归测试用例是明智的选择。自动化程度取决于在连续的回归循环中仍可重复使用的测试用例的数量。
以下是在软件工程中用于功能测试和回归测试的最重要工具：
Selenium：这是一个用于自动化Web应用程序的开源工具。硒可用于基于浏览器的回归测试。
Quick Test Professional（QTP）：HP Quick Test Professional是旨在自动执行功能和回归测试用例的自动化软件。它使用VBScript语言进行自动化。它是一个数据驱动的基于关键字的工具。
Rational Functional Tester（RFT）：IBM的Rational Functional Tester是一种Java工具，用于自动化软件应用程序的测试案例。这主要用于自动化回归测试用例，并且还与Rational Test Manager集成。
回归测试和配置管理
在不断修改代码的敏捷环境中，回归测试期间的配置管理变得势在必行。为了确保有效的回归测试，请注意以下几点：
- 正在进行回归测试的代码应配置在管理工具
- 在回归测试阶段，不得更改任何代码。回归测试代码必须不受开发人员更改的影响。
- 用于回归测试的数据库必须是隔离的，不允许数据库更改
重新测试和回归测试之间的区别
重新测试意味着再次测试功能或错误以确保代码已修复。如果不是固定的，则需要重新打开缺陷。如果已修复，则关闭缺陷。
回归测试是指在对软件应用程序进行代码更改时对其进行测试，以确保新代码不会影响软件的其他部分。
| 回归测试 | 重新测试 |
|---|---|
| 进行回归测试以确认最近的程序或代码更改是否没有对现有功能产生不利影响 | 修复缺陷后，进行重新测试以确认最终执行失败的测试用例是否通过。 |
| 回归测试的目的是，新的代码更改不应对现有功能产生任何副作用 | 根据缺陷修复程序进行重新测试 |
| 缺陷验证不是回归测试的一部分 | 缺陷验证是重新测试的一部分 |
| 根据项目和资源的可用性，回归测试可以与重新测试同时进行 | 重新测试的优先级高于回归测试，因此它在回归测试之前执行 |
| 您可以对回归测试进行自动化，手动测试可能既昂贵又耗时 | 您无法自动化测试用例以进行重新测试 |
| 回归测试称为通用测试 | 重新测试是有计划的测试 |
| 对通过的测试用例进行回归测试 | 仅针对失败的测试用例进行重新测试 |
| 回归测试检查是否有意外的副作用 | 重新测试可确保原始故障已得到纠正 |
| 仅当对现有项目进行任何修改或更改成为强制性要求时，才进行回归测试 | 重新测试使用新的构建使用相同的数据和相同的环境以及不同的输入执行缺陷 |
| 可以从功能规范，用户指南和手册以及有关已纠正问题的缺陷报告中获取回归测试的测试用例。 | 在开始测试之前，无法获得用于重新测试的测试用例。 |
回归测试中的挑战
以下是进行回归测试的主要测试问题：
- 随着连续的回归运行，测试套件变得相当大。由于时间和预算的限制，无法执行整个回归测试套件。
- 在实现最大测试覆盖率的同时最大程度地减少测试套件仍然是一个挑战。
- 确定回归测试的频率，即在每次修改或每次构建更新之后或在修正了许多错误之后，都是一个挑战。
软件测试入门系列之十四：非功能测试
已剪辑自: https://zhuanlan.zhihu.com/p/354972820
什么是非功能测试？
非功能测试定义为一种软件测试类型，用于检查软件应用程序的非功能性方面（性能，可用性，可靠性等）。
非功能测试的一个很好的例子是检查可以同时登录软件的人数。
非功能测试与功能测试同等重要，并且会影响客户满意度。
非功能测试的目的
- 非功能测试应提高产品的可用性，效率，可维护性和可移植性。
- 帮助降低与产品的非功能性方面相关的生产风险和成本。
- 优化产品的安装，设置，执行，管理和监视方式。
- 收集并产生用于内部研发的度量和指标。
- 改进和增强对产品行为和所使用技术的了解。
非功能测试的特征
- 非功能性测试应该是可测量的，因此没有地方进行主观表征，例如好，更好，最好等。
- 在需求过程开始时不太可能知道确切的数字
- 优先考虑需求很重要
- 确保在软件工程中正确标识了质量属性。
非功能测试
1）安全性：
该参数定义如何保护系统免受内部和外部来源的蓄意和突然的攻击。这通过安全性测试进行了测试。
2）可靠性：
任何软件系统在没有故障的情况下连续执行指定功能的程度。这是通过可靠性测试来测试的
3）生存能力：
该参数检查软件系统是否继续运行，并在系统出现故障时自行恢复。这由恢复测试检查
4）可用性：
该参数确定用户在系统运行期间可以依赖系统的程度。这通过稳定性测试进行检查。
5）可用性：
通过与系统的交互，用户可以轻松学习，操作，准备输入和输出。这由可用性测试检查
6）可扩展性：
该术语是指任何软件应用程序可以扩展其处理能力以满足需求增长的程度。这是通过可伸缩性测试进行测试的
7）互操作性：
该非功能性参数检查软件系统与其他软件系统的接口。这由互操作性测试检查
8）效率：
任何软件系统可以处理容量，数量和响应时间的程度。
9）灵活性：
该术语是指应用程序可以在不同的硬件和软件配置中轻松工作。像最低RAM，CPU要求一样。
10）便携性：
软件从其当前硬件或软件环境进行传输的灵活性。
11）可重用性：
它是指软件系统的一部分，可以转换为在另一应用程序中使用。
软件测试类型
- 功能性
- 非功能性
- 维护
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LbMS2xiV-1681309074020)(https://pic3.zhimg.com/v2-2d0d45762f4c7943dcf8864764bb8b6e_r.jpg)]
非功能测试类型
以下是最常见的非功能测试类型：
- 性能测试
- 负载测试
- 故障转移测试
- 相容性测试
- 可用性测试
- 压力测试
- 可维护性测试
- 可扩展性测试
- 容量测试
- 安全测试
- 灾难恢复测试
- 符合性测试
- 便携性测试
- 效率测试
- 可靠性测试
- 基准测试
- 耐力测试
- 文件测试
- 恢复测试
- 国际化测试
- 本地化测试
软件测试入门系列之十五：测试文档
已剪辑自: https://zhuanlan.zhihu.com/p/356816430
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8vbFFlUX-1681309074020)(https://picx.zhimg.com/v2-23148a0a9465510d97c96ee8b69f8340_720w.jpg?source=172ae18b)]
第一节：什么是测试文档
测试文档是在软件测试之前或期间创建的工作文档。它可以帮助测试团队估算所需的测试工作量、测试覆盖范围、资源跟踪、执行进度等。它是文档集，记录测试活动过程的测试计划、测试设计、测试执行、测试结果等工作内容。
为什么要测试文档？
对于新手来说，很容易认为测试就是执行代码并得出验证结果。但是在现实世界中，测试是一项非常正式的活动，需要有详细测试记录。测试文档使测试计划，审查和执行变得容易且可验证。
测试文档示例
以下重要的测试文档类型：
| 测试类型 | 描述 |
|---|---|
| 测试政策 | 这是一份高级别文档，描述了组织的原则、方法和所有重要的测试目标。 |
| 测试策略 | 标识要为项目执行的测试级别（类型）的高级文档。 |
| 测试计划 | 测试计划是一个完整的计划文档，其中包含测试活动的范围、方法、资源、时间表等。 |
| 需求追踪矩阵 | 这是一个将需求与测试用例联系起来的文档。 |
| 测试方案 | 测试方案是软件系统各个功能模版可以被测试用例进行验证的文档。 |
| 测试用例 | 它是一组输入值，执行先决条件，预期执行后的结果。它是针对测试场景而开发的。 |
| 测试数据 | 测试数据是在测试之前为测试执行作准备的数据，它用来为执行测试用例提供数据基础。 |
| 缺陷报告 | 缺陷报告是有关软件系统中任何无法执行其预期功能的缺陷的书面报告。 |
| 测试报告 | 测试报告是一个高级文档，其中总结了进行的测试活动以及测试结果。 |
获得测试文档的最佳实践
- 质量检查团队需要参与项目的初始阶段，以便并行创建测试文档
- 不只是创建和保留文档，而是在需要时进行更新
- 使用版本控制来管理和跟踪您的文档
- 尝试记录您需要什么来理解您的工作以及需要向利益相关者生产什么
- 您应该将标准模板用于excel表格或doc文件之类的文档
- 将所有与项目相关的文档存储在一个位置。每个团队成员都应该可以访问该参考文件，并在需要时进行更新
- 创建测试文档时，没有提供足够的细节也是常见的错误
测试文档的优势
- 创建测试文档的主要原因是减少或消除有关测试活动的任何不确定性。帮助您消除在分配任务时经常出现的歧义
- 文档不仅提供了系统的软件测试方法，而且还充当了软件测试过程中新生的培训材料。
- 展示测试文档以展示成熟的测试过程也是一个很好的营销策略
- 测试文档可帮助您在特定时限内为客户提供优质产品
- 在软件工程中，测试文档还可以通过配置文档和操作员手册来帮助配置或设置程序。
- 测试文档可帮助您提高与客户的透明度
测试文档的缺点
- 文档的成本可能会超过其价值，因为这非常耗时
- 很多时候，它是由写得不好或不懂材料的人写的
- 跟踪客户请求的更改并更新相应的文档很累。
- 不良的文档直接反映了产品的质量，因为客户和组织之间可能会产生误解
概括
- 测试文档是在软件测试之前或期间创建的工件的文档。
- 测试形式的程度取决于1）被测应用程序的类型2）组织遵循的标准3）开发过程的成熟度。
- 测试文件的重要类型是测试策略，测试策略，测试计划，测试用例等。
- 质量检查团队需要参与项目的初始阶段，以便并行创建测试文档
- 创建测试文档的主要原因是减少或消除有关测试活动的任何不确定性。
- 文档的成本可能会超过其价值，因为准备测试文档非常耗时。
软件测试入门系列之十六：测试方案
已剪辑自: https://zhuanlan.zhihu.com/p/356816890
测试方案被定义为可被测试的任何功能，也称为测试可能性”。作为测试人员，你应该置身于用户角度，弄清楚被测应用程序的真实场景和用例。
软件测试中的场景测试是一种使用实际场景而不是测试用例来测试软件应用程序的方法。场景测试的目的是针对软件的特定复杂问题设计的端到端测试方案。测试场景有助于以更简单的方式测试和评估端到端的复杂问题。
为什么要创建测试方案？
创建测试方案的原因如下：
- 创建测试方案可确保完整的测试范围
- 测试场景可以由业务分析人员，开发人员，客户等各种利益相关者批准，以确保对被测应用程序进行全面测试。它可以确保该软件适用于最常见的用例。
- 它们可作为确定测试工作量的快速工具，从而为客户创建建议或组织工作人员。
- 它们有助于确定最重要的端到端事务或软件应用程序的实际使用。
- 对于研究程序的端到端功能，测试方案至关重要。
什么时候不创建测试方案？
在以下情况下可能无法创建测试方案
- 被测应用程序复杂、不稳定，并且项目时间紧迫。
- 遵循敏捷方法论的项目（例如Scrum、看板）可能不会创建测试方案。
- 可能无法为新的错误修复或回归测试创建测试方案。在这种情况下，测试方案必须在先前的测试周期中已被大量记录。当然对于维护项目尤其如此。
如何编写测试方案
测试人员可以按照以下五个步骤创建测试方案：
步骤1：阅读被测系统（SUT）的需求文档，例如BRS，SRS，FRS。还可以参考要测试的应用程序的用例、书籍、手册等。
步骤2：针对每个需求，找出可能的用户操作和预期目标，确定需求的技术实现方案，确定系统滥用的可能情况，并以黑客的心态评估用户使用场景。
步骤3：阅读需求文档并进行应有的分析后，列出不同的测试场景以验证软件的每个功能。
步骤4：列出所有可能的测试场景后，将创建一个需求追溯矩阵，以验证每个需求都具有相应的测试方案。
步骤5：创建的方案由主管牵头评审，项目中的其他参与者（产研测）也应参与评审。
创建测试方案的技巧
- 根据项目方法，每个测试场景应至少与一个需求或用户案例相关联。
- 在创建一次验证多个需求的测试场景之前，请确保你具有一个测试场景，用于单独检查该需求。
- 避免创建跨越多个需求的过于复杂的测试场景。
- 场景的数量可能很大，并且全部运行这些场景的成本很高。根据客户优先级，仅运行选定的测试场景。
软件测试入门系列之十七：测试用例
已剪辑自: https://zhuanlan.zhihu.com/p/356820412
什么是测试用例？
一个测试用例是一组执行，以验证您的软件应用程序的具体特征或功能的行为。测试用例包含为特定测试场景开发的测试步骤，测试数据，前提条件，后置条件，以验证任何要求。测试用例包括特定的变量或条件，测试工程师可以使用这些变量或条件来比较预期结果和实际结果，以确定软件产品是否按照客户的要求运行。
测试场景与测试案例
测试场景非常模糊，涵盖了广泛的可能性。测试都是非常具体的。
对于测试方案：检查登录功能，有许多可能的测试用例：
- 测试案例1：检查输入有效的用户ID和密码的结果
- 测试案例2：在输入无效的用户ID和密码时检查结果
- 测试案例3：在按下用户ID为“空”和“登录”按钮后，检查响应等等。
如何编写测试用例
让我们为该场景创建一个测试用例：检查登录功能
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-medd1Uvr-1681309074021)(https://pic1.zhimg.com/v2-85b4852736b123d28f916eed6199388c_r.jpg)]
步骤1）一个简单的测试用例来解释该场景是
| 测试用例 ＃ | 测试用例描述 |
|---|---|
| 1个 | 输入有效的电子邮件和密码后检查响应 |
步骤2）为了执行测试用例，您将需要测试数据。在下面添加
| 测试用例 ＃ | 测试用例描述 | 测试数据 |
|---|---|---|
| 1个 | 输入有效的电子邮件和密码后检查响应 | 电子邮件：qa@email.com密码：lNf9 ^ Oti7 ^ 2h |
识别测试数据可能很耗时，有时可能需要重新创建测试数据，需要记录的原因。
步骤3）为了执行测试用例，测试人员需要在AUT上执行一组特定的动作。记录如下：
| 测试用例 ＃ | 测试用例描述 | 测试步骤 | 测试数据 |
|---|---|---|---|
| 1个 | 输入有效的电子邮件和密码后检查响应 | 1）输入电子邮件地址2）输入密码3）点击登录 | 电子邮件：qa@email.com密码：lNf9 ^ Oti7 ^ 2h |
很多时候，测试步骤都不像上面那样简单，因此它们需要整理成测试文档。同样，测试用例的作者可能会离开组织或去休假、生病或忙于其他关键任务。可能会要求最近雇用的人来执行测试用例。记录在案的步骤将对他有帮助，也有助于其他利益相关者的审查。
步骤4）软件测试中测试用例的目标是检查AUT的行为是否达到预期的结果。这需要记录如下
| 测试用例 ＃ | 测试用例描述 | 测试数据 | 预期结果 |
|---|---|---|---|
| 1个 | 输入有效的电子邮件和密码后检查响应 | 电子邮件：qa@email.com密码：lNf9 ^ Oti7 ^ 2h | 登录应该成功 |
在测试执行期间，测试人员将对照实际结果检查预期结果，并指定通过或失败状态
| 测试用例 ＃ | 测试用例描述 | 测试数据 | 预期结果 | 实际结果 | 过关失败 |
|---|---|---|---|---|---|
| 1个 | 输入有效的电子邮件和密码后检查响应 | 电子邮件：qa@email.com密码：lNf9 ^ Oti7 ^ 2h | 登录应该成功 | 登录成功 | 通过 |
步骤5）除了测试用例之外，可能还有一个类似Pre-Condition的字段，它指定在测试可以运行之前必须具备的条件。对于我们的测试用例，先决条件是安装浏览器以访问被测站点。测试用例还可以包括“发布后条件”，该条件指定了在测试用例完成后适用的所有内容。对于我们的测试用例，后置条件将是登录的时间和日期存储在数据库中
标准测试用例的格式
下面是标准登录测试用例格式
| 测试用例ID | 测试场景 | 测试步骤 | 测试数据 | 预期成绩 | 实际结果 | 过关失败 |
|---|---|---|---|---|---|---|
| TU01 | 使用有效数据检查客户登录 | 前往网站http://demo.qa.com输入用户名输入密码点击提交 | 用户名= qa密码= pass99 | 用户应登录到应用程序 | 登陆成功 | 通过 |
| TU02 | 使用无效数据检查客户登录 | 前往网站http://demo.qa.com输入用户名输入密码点击提交 | 用户名= qa密码= glass99 | 用户不应登录到应用程序 | 失败 | 通过 |
整个表可以在Word，Excel或任何其他测试管理工具中创建。这就是测试用例设计的全部内容。
在起草测试用例以包括以下信息时
- 对要测试的需求的描述
- 有关如何测试系统的说明
- 测试设置，例如被测应用程序的版本，软件，数据文件，操作系统，硬件，安全性访问，物理或逻辑日期，一天中的时间，先决条件（例如其他测试）以及与被测试需求相关的任何其他设置信息
- 投入和产出或行动和预期成果
- 任何证明或附件
- 使用有效的案例语言
- 测试用例不应超过15个步骤
- 用输入，目的和预期结果对自动测试脚本进行注释
- 该设置提供了先决条件测试的替代方法
- 与其他测试一起，它应该是不正确的业务场景订单
编写良好的测试用例示例的最佳实践
1.测试用例必须简单透明：
创建尽可能简单的测试用例。它们必须清晰明了，因为测试用例的作者可能不会执行它们。
使用自信的语言，例如转到主页，输入数据，单击此按钮，依此类推。这使理解测试步骤变得容易，并且测试执行速度更快。
2.与最终用户一起创建测试用例
任何软件项目的最终目标都是创建满足客户要求并且易于使用和操作的测试用例。测试人员必须创建测试用例，并牢记最终用户的观点
3.避免重复测试用例
不要重复测试用例。如果需要一个测试用例来执行其他测试用例，请在前提条件栏中通过其测试用例ID调用该测试用例。
4.不确定性
准备测试用例时，请勿假定你的软件应用程序具有某功能。
5.确保覆盖率100％
确保编写测试用例以检查规范文档中提到的所有软件要求。使用可追溯性矩阵来确保没有任何功能/条件未经测试。
6.测试用例必须是可识别的
命名测试用例ID，以便在跟踪缺陷或在以后识别软件需求时容易识别它们。
7.实施测试技术
无法检查软件应用程序中的所有可能条件。软件测试技术可帮助您选择一些测试案例，以最大可能地发现缺陷。
- 边界值分析（BVA）：顾名思义，它是一种为指定范围的值定义边界测试的技术。
- 等效分区（EP）：此技术将范围划分为趋于具有相同行为的相等部分/组。
- 状态转换技术：当软件行为在特定操作后从一种状态变为另一种状态时，将使用此方法。
- 错误猜测技术：这是猜测/预测在进行手动测试时可能出现的错误。这不是一种正式的方法，它利用了测试人员在应用程序方面的经验
8.自清理
创建的测试用例必须使测试环境返回到测试前状态，并且保证测试环境可用。对于配置测试尤其如此。
9.可重复和独立
无论由谁进行测试，测试用例每次都应产生相同的结果
10.同行评审
创建测试用例后，请他们的同事对其进行审查。你的同事可以发现你的测试用例设计中的缺陷，而你可能很容易错过这些缺陷。
测试用例管理工具
测试管理工具是帮助管理和维护测试用例的自动化工具。测试用例管理工具的主要功能是
- 用于记录测试用例：使用工具，您可以使用模板来加快测试用例的创建
- 执行测试用例并记录结果：可以通过工具执行测试用例，并且可以轻松地记录获得的结果。
- 自动化缺陷跟踪：失败的测试会自动链接到Bug跟踪器，然后可以将其分配给开发人员并通过电子邮件通知进行跟踪。
- 可追溯性：需求，测试用例，测试用例的执行都通过工具相互链接，并且每个用例都可以相互跟踪以检查测试范围。
- 保护测试用例：测试用例应该是可重用的，并且应该避免由于版本控制不佳而丢失或损坏。测试用例管理工具提供的功能包括
- 命名和编号约定
- 版本控制
- 只读存储
- 受控访问
- 异地备份
流行的测试管理工具包括：JIRA
软件测试入门系列之十八：什么是测试分析
已剪辑自: https://zhuanlan.zhihu.com/p/356823992
软件测试中的“测试分析”是检查和分析测试工件以建立测试条件或测试用例的过程。测试分析的目的是收集需求并定义测试目标，以建立测试条件的基础。因此它也称为测试基础。
获得测试信息的来源
- SRS（软件需求规范）
- BRS（业务需求规范）
- 功能设计文件
测试人员可以通过查看被测应用程序来创建测试条件，也可以利用他们的经验。但是大多数情况下，测试用例是从测试工件中派生的。
让我们借助案例研究来了解测试分析
考虑一个场景，客户端发送以下内容
将搜索功能添加到电子商务商店
下面列出了你可能想到的许多测试用例
- 未输入关键字时检查搜索结果
- 当搜索到的关键词没有相应的产品时，请检查搜索结果
- 当搜索到的关键字有多个相应产品时，请检查搜索结果
在这里，您可以查看“测试基础”（客户端发送的要求），对其进行分析，然后将其转换为“测试条件”。
这是在V-Model的不同阶段发生的情况。使用在不同阶段可用的相应文档来创建测试计划/案例。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QBa26t3r-1681309074021)(https://pic1.zhimg.com/v2-4736589cf2d44dbb2c276370b61c0e44_r.jpg)]
软件测试入门系列之十九：什么是需求追踪矩阵(RTM)
已剪辑自: https://zhuanlan.zhihu.com/p/356824985
可追溯性矩阵是一个文档，它与需要多对多关系以检查关系的完整性的任何两个基线文档相关联。它用于跟踪需求并检查是否满足当前项目需求。
需求可追溯性矩阵（RTM）是一个文档，用于通过测试用例映射和跟踪用户需求。它在软件部署生命周期结束时提供的单个文档中捕获了客户提出的所有需求和需求可追溯性。需求可追溯性矩阵的主要目的是验证是否通过测试用例检查了所有需求，以便在软件测试期间不取消任何功能。
为什么RTM很重要？
每个测试人员的主要议程应是了解客户的要求，并确保输出产品无缺陷。为了实现此目标，每个质量检查人员都应彻底了解需求，并创建正面和负面的测试用例。
这意味着必须将客户端提供的软件需求进一步划分为不同的场景并进一步设计测试案例。每种情况都必须单独执行。
这里出现一个问题，即如何确保考虑所有可能的场景并对需求进行测试？如何确保在测试周期内不遗漏任何要求？
一种简单的方法是使用相应的测试方案和测试案例来跟踪需求。这仅称为“需求可追溯性矩阵”。
可追溯性矩阵通常是一个工作表，其中包含需求及其所有可能的测试方案和案例以及它们的当前状态，即它们是否已通过或失败。这将有助于测试团队了解针对特定产品完成的测试活动的级别。
需求可追溯性矩阵中应包括哪些参数？
- 需求编号
- 需求类型和说明
- 具有状态的测试用例
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wTZa1mbZ-1681309074021)(https://pic3.zhimg.com/v2-2afa6a0cd26c8f18c091b5abdb2249e6_r.jpg)]
以上是样本需求可追溯性矩阵。
但是在一个典型的软件测试项目中，可追溯性矩阵将具有比这些参数更多的参数。
如上所述，需求可追溯性矩阵可以：
- 在测试用例数量中显示需求覆盖率
- 特定测试用例的设计状态和执行状态
- 如果用户要进行任何用户接受测试，那么UAT状态也可以捕获在同一矩阵中。
- 相关的缺陷和当前状态也可以在同一矩阵中提及。
这种矩阵可以为所有测试活动提供一站式服务。
除了单独维护一个excel。测试团队还可以选择跟踪需求的可用测试管理工具。
可追溯性测试矩阵的类型
在软件工程中，可追溯性矩阵可分为以下三个主要部分：
- 前向可追溯性：此矩阵用于检查项目是否按期望的方向进行并且产品正确。它确保每个要求都适用于产品，并且每个要求都经过了彻底的测试。它将需求映射到测试用例。
- 向后或反向可追溯性：用于确保当前产品是否保持在正确的轨道上。这种类型的可追溯性的目的是通过添加代码，设计元素，测试或要求中未指定的其他工作来验证我们没有扩大项目范围。它将测试用例映射到需求。
- 双向可追溯性（向前+向后）：此可追溯性矩阵可确保测试用例满足所有要求。它分析了工作产品中受缺陷影响的需求变更的影响，反之亦然。
如何创建需求可追溯性矩阵
让我们通过Guru99银行项目了解“需求可追溯性矩阵”的概念。
根据业务需求文档（BRD）和技术需求文档（TRD），测试人员开始编写测试用例。
让我们假设，下表是我们针对Guru99银行项目的业务需求文档或BRD。
在这种情况下，客户应该能够使用正确的密码和用户#id登录到Guru99银行网站，而经理应该能够通过客户登录页面登录到该网站。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-M2BeN0sj-1681309074022)(https://pic4.zhimg.com/v2-02567df966b4cdc977f60cc8b0be8dfb_r.jpg)]
下表是我们的技术要求文档（TRD）。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rrsTXNij-1681309074022)(https://pic2.zhimg.com/v2-4367fded8f8ce93d8d92dd364582a28d_r.jpg)]
注意：质量检查团队不会记录BRD和TRD。此外，一些公司使用的功能需求文档（FRD）与技术需求文档相似，但是创建可追溯性矩阵的过程保持不变。
让我们继续，在测试中创建RTM
步骤1：我们的示例测试用例是
“验证登录名，输入正确的ID和密码后，它应该成功登录”
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jdq7Ez9M-1681309074022)(https://pic4.zhimg.com/v2-204cfb55fbbf0d40ed59a8b777583203_r.jpg)]
步骤2：确定该测试用例正在验证的技术要求。对于我们的测试用例，技术要求是正在验证的T94。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XNrVndb2-1681309074023)(https://pic2.zhimg.com/v2-6c10d14cf974629d29a2328f9220b119_r.jpg)]
步骤3：在测试用例中记录此技术要求（T94）。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-oriUfK3I-1681309074023)(https://pic3.zhimg.com/v2-1cd3e7d0030d0e097bb4ecd3fa204aee_r.jpg)]
步骤4：确定为此TR（技术要求-T94）定义的业务需求
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vq9oaOG0-1681309074023)(https://pic3.zhimg.com/v2-24d869eeb4cf4b145995ec96c7dbc706_r.jpg)]
步骤5：在测试用例中记下BR（业务需求）
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8QpeOorl-1681309074023)(https://pic1.zhimg.com/v2-1a22e1427df00a56be57083eafb78d84_r.jpg)]
步骤6：对所有测试用例执行上述操作。稍后从测试套件中提取前3列。测试中的RTM准备就绪！
需求可追溯性矩阵的优势
- 它确认100％的测试覆盖率
- 它突出显示了所有缺少的要求或文档不一致的地方
- 它显示整体缺陷或执行状态，并着重于业务需求
- 在重新访问或重新处理测试用例方面，它有助于分析或评估对质量检查团队工作的影响
软件测试入门系列之二十：测试数据生成
已剪辑自: https://zhuanlan.zhihu.com/p/356826726
作为一名测试人员，您可能会认为“设计测试用例足够具有挑战性，那么为什么要烦恼像测试数据这样琐碎的事情”。本教程的目的是向您介绍测试数据，其重要性，并提供实用的技巧和窍门，以快速生成测试数据。所以，让我们开始吧！
什么是软件测试中的测试数据？
软件测试中的测试数据是在测试执行过程中提供给软件程序的输入。它表示在测试期间会影响软件执行或受其影响的数据。测试数据既可以用于正面测试，以验证功能在给定的输入下产生预期的结果，也可以用于负面测试，以测试软件处理异常，异常或意外输入的能力。
设计不良的测试数据可能无法测试所有可能的测试方案，这会影响软件的质量。
什么是测试数据生成？为什么要在测试执行之前创建测试数据？
每个人都知道测试是一个产生和消耗大量数据的过程。测试中使用的数据描述了测试的初始条件，并表示测试人员通过其影响软件的媒介。这是大多数功能测试的关键部分。
根据你的测试环境，你可能需要创建测试数据（大多数情况下）或至少为测试用例标识合适的测试数据（是否已经创建了测试数据）。
通常，测试数据是与打算用于的测试用例同步创建的。
可以生成测试数据：
- 手动地
- 从生产到测试环境的海量数据复制
- 从旧客户端系统批量复制测试数据
- 自动化测试数据生成工具
通常，应该在开始执行测试之前生成示例数据，因为否则很难进行测试数据管理。由于在许多测试环境中，创建测试数据需要多个步骤或非常耗时的测试环境配置。。另外，如果在处于测试执行阶段的同时完成了测试数据的生成，则可能会超出测试期限。
下面介绍了几种测试类型以及有关其测试数据需求的一些建议。
白盒测试数据
在“白盒测试”中，测试数据管理源自直接检查要测试的代码。可以通过考虑以下因素来选择测试数据：
-
希望覆盖尽可能多的分支机构。可以生成测试数据，以便至少对程序源代码中的所有分支进行一次测试
-
路径测试：程序源代码中的所有路径至少要测试一次-测试数据准备工作可以覆盖尽可能多的情况
-
负面API测试：
-
- 测试数据可能包含用于调用不同方法的无效参数类型
- 测试数据可能包含无效的参数组合，这些参数用于调用程序的方法
性能测试的测试数据
性能测试是为了确定系统在特定工作负载下的响应速度而执行的测试类型。这种测试的目的不是发现错误，而是消除瓶颈。性能测试的一个重要方面是，所使用的样本数据集必须非常接近生产中使用的“真实”或“实时”数据。出现以下问题：“好，用真实数据进行测试很好，但是我如何获得这些数据呢？” 答案很简单：来自最了解的人—客户。他们可能能够提供一些已经拥有的数据，或者，如果他们没有现有的数据集，他们可能会通过提供有关真实数据看起来如何的反馈来帮助您。维护测试项目，您可以将生产环境中的数据复制到测试台中。制作副本时，匿名（扰乱）敏感的客户数据（如社会安全号，信用卡号，银行详细信息等）是一种很好的做法。
安全测试的测试数据
安全测试是确定信息系统是否保护数据免受恶意攻击的过程。为了完全测试软件安全性而需要设计的数据集必须涵盖以下主题：
- 机密性：客户提供的所有信息均严格保密，不会与任何外部人士共享。举一个简短的例子，如果应用程序使用SSL，则可以设计一组测试数据，以验证加密是否正确完成。
- 完整性：确定系统提供的信息正确。要设计合适的测试数据，您可以先深入了解设计，代码，数据库和文件结构。
- 身份验证：表示建立用户身份的过程。可以将测试数据设计为用户名和密码的不同组合，其目的是检查只有经过授权的人员才能访问软件系统。
- 授权：告知特定用户的权限。测试数据可能包含用户，角色和操作 的不同组合，以便仅检查具有足够特权的用户能够执行特定操作。
黑盒测试的测试数据
在“黑匣子测试”中，测试人员看不到该代码。您的功能测试用例可以具有满足以下条件的测试数据。
- 无数据：未提交数据时检查系统响应
- 有效数据：提交有效测试数据后检查系统响应
- 无效数据： 提交InValid测试数据时检查系统响应
- 数据格式非法：当测试数据格式无效时，检查系统响应
- 边界条件数据集：满足边界值条件的测试数据
- 等值分区数据集：测试数据，以验证您的等价分区。
- 决策表数据集：使您的决策表测试策略合格的测试数据
- 状态转换测试数据集：满足您的状态转换测试策略的测试数据
- 用例测试数据：与您的用例同步的测试数据。
注意：根据要测试的软件应用程序，您可以使用部分或全部上述测试数据创建
自动化测试数据生成工具
为了生成各种数据集，您可以使用各种自动测试数据生成工具。以下是此类工具的一些示例：
DTM测试数据生成器是一个完全可定制的实用程序，可以生成数据，表（视图，过程等）用于数据库测试（性能测试，QA测试，负载测试或可用性测试）。
Datatect是Banner软件公司的SQL数据生成器，可在ASCII平面文件中生成各种实际的测试数据，或直接为RDBMS生成测试数据，包括Oracle，Sybase，SQL Server和Informix。
结论
总之，精心设计的测试数据使你能够识别和纠正功能上的严重缺陷。在多阶段产品开发周期的每个阶段中，必须重新评估所选测试数据的选择。
软件测试入门系列之二十一：测试用例设计技术
已剪辑自: https://zhuanlan.zhihu.com/p/356829164
软件测试技术可帮助您设计更好的测试用例。由于不可能进行详尽的测试；手动测试技术有助于减少测试用例的数量，同时增加测试范围。它们有助于确定否则难以识别的测试条件。
边界值分析（BVA）
边界值分析基于对分区之间边界的测试。它包括最大值，最小值，内部或外部边界，典型值和误差值。
通常可以看到，许多错误发生在定义的输入值的边界而不是中心。它也被称为BVA，它提供了一些选择测试用例，这些测试用例具有边界值。
这种黑匣子测试技术是对等价分区的补充。这种软件测试技术基于以下原理：如果系统对于这些特定值运行良好，那么它将对介于两个边界值之间的所有值都运行良好。
边界值分析准则
- 如果输入条件限制在值x和y之间，则测试用例应设计为值x和y以及值分别高于和低于x和y。
- 如果输入条件是大量值，则应开发测试用例，该用例需要使用最小和最大数字。在此，还将测试高于和低于最小值和最大值的值。
- 将准则1和2应用于输出条件。它给出的输出反映了预期的最小值和最大值。它还会测试下面或上面的值。
例子：
输入条件在1到10之间有效
边界值0,1,2和9,10,11
等价类划分
等效类分区允许您将一组测试条件划分为一个分区，该分区应视为相同的分区。这种软件测试方法将程序的输入域划分为应设计测试用例的数据类别。
该技术背后的概念是，每个类别的代表值的测试用例等于对同一类别的任何其他值的测试。它使您可以识别有效和无效的等效类。
例子：
输入条件在
1至10和20至30
因此，有五个等价类
-到0（无效）
1至10（有效）
11至19（无效）
20至30（有效）
31至---（无效）
您可以从每个类别中选择值，即
-2、3、15、25、45
基于决策表的测试
决策表也称为因果表。此软件测试技术用于响应输入或事件的组合的功能。例如，如果用户输入了所有必填字段，则应启用“提交”按钮。
第一项任务是确定输出依赖于输入组合的功能。如果组合的输入集很大，则将其分为较小的子集，这对管理决策表很有帮助。
对于每个功能，您都需要创建一个表并列出所有类型的输入及其各自的输出的组合。这有助于确定测试人员忽略的状况。
以下是创建决策表的步骤：
- 征求行中的输入
- 在栏中输入所有规则
- 用输入的不同组合填充表格
- 在最后一行中，根据输入组合记下输出。
示例：仅当最终用户输入了所有输入后，才会启用联系表单中的提交按钮。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-a60hQK67-1681309074024)(https://pic4.zhimg.com/v2-2569df10c071c5731f1c54843fdeaf3b_r.jpg)]
状态转换
在状态转换技术中，输入条件的变化会更改被测应用程序（AUT）的状态。这种测试技术允许测试人员测试AUT的行为。测试人员可以通过依次输入各种输入条件来执行此操作。在状态转换技术中，测试团队提供正负输入测试值以评估系统行为。
状态转换准则：
- 当测试团队针对一组有限的输入值测试应用程序时，应使用状态转换。
- 当测试团队想要测试被测应用程序中发生的事件序列时，应使用该技术。
例子：
在以下示例中，如果用户在前三次尝试中的任何一次输入中输入了有效密码，则该用户将能够成功登录。如果用户在第一次或第二次尝试中输入了无效的密码，将提示用户重新输入密码。当用户第三次输入密码错误时，该操作已被执行，并且该帐户将被阻止。
状态转换图
在此图中，当用户提供正确的PIN码时，他或她将进入“访问许可”状态。下表是根据上图创建的
状态转换表
| 正确的PIN码 | PIN码错误 | |
|---|---|---|
| S1）开始 | S5 | S2 |
| S2）第一次尝试 | S5 | S3 |
| S3）第二次尝试 | S5 | S4 |
| S4）第三次尝试 | S5 | S6 |
| S5）授予访问权限 | – | – |
| S6）帐户被封锁 | – | – |
在上面给出的表中，当用户输入正确的PIN时，状态将转换为“已授予访问权限”。并且，如果用户输入了错误的密码，则他或她将进入下一个状态。如果他第三次执行相同的操作，则他将进入帐户被阻止状态。
错误猜测
错误猜测是一种基于猜测代码中可能普遍存在的错误的软件测试技术。该技术很大程度上基于经验，测试分析人员将根据经验来猜测测试应用程序中有问题的部分。因此，测试分析人员必须熟练且有经验，才能更好地猜测错误。
该技术计算出可能的错误或容易出错的情况的列表。然后，测试人员编写一个测试用例以暴露那些错误。为了基于这种软件测试技术设计测试用例，分析人员可以利用过去的经验来确定条件。
错误猜测准则：
- 该测试应使用以前测试类似应用程序的经验
- 了解被测系统
- 了解典型的实施错误
- 记住以前遇到麻烦的地方
- 评估历史数据和测试结果
结论
- 软件测试技术使您可以设计更好的案例。有五种主要使用的技术。
- 边界值分析正在分区之间的边界进行测试。
- 等效类分区允许您将一组测试条件划分为一个分区，该分区应视为相同的分区。
- 决策表软件测试技术用于响应输入或事件组合的功能。
- 在状态转换技术中，输入条件的变化会更改被测应用程序（AUT）的状态
- 错误猜测是一种软件测试技术，其基于猜测代码中可能普遍存在的错误。
软件测试入门系列之二十二：边界值分析和等价类划分
已剪辑自: https://zhuanlan.zhihu.com/p/356832889
实际上，由于时间和预算的考虑，不可能对每组测试数据都进行详尽的测试，尤其是在输入组合池很大的情况下。
- 我们需要一种简单的方法或特殊的技术，可以从测试用例池中智能地选择测试用例，从而涵盖所有测试用例。
- 我们使用两种技术-等价分区和边界值分析测试技术来实现此目的。
什么是边界测试？
边界测试是测试输入值的两个极端之间或边界之间的过程。
- 因此，这些极端值（例如开始-结束，下-上，最大-最小，仅内部-刚刚外部）称为边界值，而测试称为“边界测试”。
- 正常边界值测试的基本思想是在以下位置选择输入变量值：
- 最低限度
- 刚好高于最小值
- 标称值
- 略低于最大值
- 最大限度
- 在边界测试中，等效类划分起着很好的作用
- 边界测试是在对等类划分之后进行的。
等效分区
等效分区或等效类分区是黑盒测试技术的一种，可应用于所有级别的软件测试，例如单元，集成，系统等。在此技术中，输入数据单元被划分为等效分区，这些分区可用于导出测试用例，因为测试用例数量少，因此减少了测试所需的时间。
- 它将软件的输入数据分为不同的等效数据类。
- 您可以在输入字段中有一个范围的情况下应用此技术。
示例1：等价和边值
- 让我们考虑下面的“订购比萨饼”文本框的行为
- 披萨值1到10被认为是有效的。显示一条成功消息。
- 虽然值11到99被认为对订单无效，并且会出现错误消息，“只能订购10个比萨”
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UnD8Np8L-1681309074025)(https://pic3.zhimg.com/v2-067222f92353a13138f40381495ca7f6_r.jpg)]
这是测试条件
- 在“订购披萨”字段中输入的任何大于10的数字（假设为11）均被视为无效。
- 任何小于1的数字，等于0或小于0，则视为无效。
- 数字1到10被认为是有效的
- 任意3位数字表示-100无效。
我们无法测试所有可能的值，因为如果完成，测试用例的数量将超过100。为解决此问题，我们使用等价划分假设，在其中将票证的可能值划分为组或集，如下所示行为可以认为是相同的。
划分的集合称为等效分区或等效类。然后，我们从每个分区中仅选择一个值进行测试。该技术背后的假设是**，如果分区中的一个条件/值通过，则所有其他条件/值也将通过**。同样**，如果分区中的一个条件失败，则该分区中的所有其他条件都将失败**。
边界值分析-在边界值分析中，您测试等效分区之间的边界
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1338D4eO-1681309074025)(https://pic3.zhimg.com/v2-14c4c8ce81a4a43a43b02d0eecc4e146_r.jpg)]
在我们之前的等效分区示例中，您将检查0、1、10、11等分区上的值，而不是为每个分区检查一个值。您可能会看到，您在有效边界和无效边界都测试了值。边界值分析也称为范围检查。
等效分区和边界值分析（BVA）密切相关，可以在所有测试级别上一起使用。
示例2：等价和边值
以下密码字段接受至少6个字符，最多10个字符
这意味着分区0-5、6-10、11-14中的值的结果应相等
| 测试场景 | 测试方案说明 | 预期结果 | |
|---|---|---|---|
| 1个 | 在密码字段中输入0到5个字符 | 系统不应该接受 | |
| 2个 | 在密码字段中输入6到10个字符 | 系统应接受 | |
| 3 | 在密码字段中输入11到14个字符 | 系统不应该接受 |
示例3：输入框应接受数字1到10
| 测试方案说明 | 预期结果 |
|---|---|
| 边界值= 0 | 系统不应接受 |
| 边界值= 1 | 系统应接受 |
| 边界值= 2 | 系统应接受 |
| 边界值= 9 | 系统应接受 |
| 边界值= 10 | 系统应接受 |
| 边界值= 11 | 系统不应接受 |
为什么进行等效和边界分析测试
- 该测试用于将大量测试用例减少为可管理的块。
- 在不影响测试有效性的情况下确定测试用例的非常明确的准则。
- 适用于具有大量变量/输入的计算密集型应用
总结
- 当实际上不可能单独测试大量测试用例时，使用边界分析测试
- 两种技术-使用边值分析和等效划分测试技术
- 在“等效分区”中，首先，将一组测试条件划分为一个可以考虑的分区。
- 然后在边界值分析中测试等价分区之间的边界
软件测试入门系列之二十三：决策表
已剪辑自: https://zhuanlan.zhihu.com/p/356833045
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zKSMNtSN-1681309074026)(https://pic1.zhimg.com/v2-105ccd7eee7922d9259617a62a9bdfda_720w.jpg?source=172ae18b)]
决策表是输入对比规则/例/试验条件的表格表示。这是用于复杂软件测试和需求管理的非常有效的工具。决策表有助于检查测试条件的所有可能组合，并且测试人员还可以轻松识别错过的条件。条件表示为True（T）和False（F）值。
什么是决策表测试？
决策表测试是一种软件测试技术，用于测试不同输入组合的系统行为。这是一种系统的方法，其中以表格形式捕获了不同的输入组合及其对应的系统行为（输出）。这就是为什么它也被称为因果表的原因原因表捕获更好的测试覆盖范围。
让我们学习一个例子。
示例1：如何为登录屏幕制作决策基础表
让我们为登录屏幕创建决策表。
如果用户提供正确的用户名和密码，则条件很简单，该用户将被重定向到主页。如果任何输入错误，将显示一条错误消息。
| 情况 | 规则1 | 规则二 | 规则三 | 规则四 |
|---|---|---|---|---|
| 用户名（T / F） | F | Ť | F | Ť |
| 密码（T / F） | F | F | Ť | Ť |
| 输出（E / H） | E | E | E | H |
- T –正确的用户名/密码
- F –用户名/密码错误
- E –显示错误信息
- H –显示主屏幕
解释：
- 情况1 –用户名和密码均错误。向用户显示一条错误消息。
- 情况2 –用户名正确，但密码错误。向用户显示一条错误消息。
- 情况3 –用户名错误，但密码正确。向用户显示一条错误消息。
- 情况4 –用户名和密码均正确，并且用户导航到主页
将其转换为测试用例时，我们可以创建2个场景，
- 输入正确的用户名和正确的密码，然后单击登录，预期结果将是用户应导航到主页
- 还有一个来自以下场景
- 输入错误的用户名和错误的密码，然后单击登录，预期结果将是用户应收到一条错误消息
- 输入正确的用户名和错误的密码，然后单击登录，预期结果将是用户应收到一条错误消息
- 输入错误的用户名和正确的密码，然后单击登录，预期结果将是用户应收到一条错误消息
因为他们实质上测试了相同的规则。
示例2：如何为上载屏幕制作决策表
现在考虑一个对话框，该对话框将要求用户在某些条件下上传照片，例如–
- 只能上传“ .jpg”格式的图片
- 文件大小小于32kb
- 分辨率137 * 177。
如果任何条件失败，系统将抛出相应的错误消息，说明问题，如果满足所有条件，则照片将成功更新
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pXpxvXtI-1681309074026)(https://pic2.zhimg.com/v2-7f2f81c5652da6b97aeedea73b0547dd_r.jpg)]
让我们为这种情况创建决策表。
| 情况 | 情况1 | 情况二 | 情况3 | 案例4 | 案例5 | 案例6 | 案例7 | 案例8 |
|---|---|---|---|---|---|---|---|---|
| 格式 | .jpg | .jpg | .jpg | .jpg | 不是.jpg | 不是.jpg | 不是.jpg | 不是.jpg |
| 尺寸 | 小于32kb | 小于32kb | > = 32kb | > = 32kb | 小于32kb | 小于32kb | > = 32kb | > = 32kb |
| 解析度 | 137 * 177 | 不是137 * 177 | 137 * 177 | 不是137 * 177 | 137 * 177 | 不是137 * 177 | 137 * 177 | 不是137 * 177 |
| 输出 | 照片已上传 | 错误消息解析不匹配 | 错误消息大小不匹配 | 错误消息的大小和分辨率不匹配 | 格式不匹配的错误消息 | 错误消息格式和分辨率不匹配 | 格式和大小不匹配的错误消息 | 格式，大小和分辨率不匹配的错误消息 |
对于这种情况，我们可以创建8个不同的测试用例，并根据上表确保完整的覆盖范围。
- 上传格式为“ .jpg”，尺寸小于32kb，分辨率为137 * 177的照片，然后单击“上传”。预期结果是照片应该成功上传
- 上载格式为“ .jpg”，尺寸小于32kb，分辨率不为137 * 177的照片，然后单击“上载”。预期结果是错误消息分辨率不匹配应显示
- 上传一张格式为“ .jpg”，大小超过32kb，分辨率为137 * 177的照片，然后单击“上传”。预期结果是应该显示错误消息大小不匹配
- 上载格式为“ .jpg”，大小大于等于32kb，分辨率不为137 * 177的照片，然后单击“上载”。预期结果是错误消息大小和分辨率不匹配应显示
- 上载格式不是“ .jpg”，尺寸小于32kb，分辨率为137 * 177的照片，然后单击“上载”。预期结果是应显示格式不匹配的错误消息
- 上载格式不是“ .jpg”，尺寸小于32kb，分辨率不为137 * 177的照片，然后单击“上载”。预期结果是错误消息格式和分辨率不匹配应显示
- 上载格式不是’.jpg’，尺寸大于32kb，分辨率为137 * 177的照片，然后单击“上载”。预期结果是应显示格式和大小不匹配的错误消息
- 上载具有’.jpg’以外的格式，大小超过32kb且分辨率不是137 * 177的照片，然后单击上载。预期结果是应显示格式，大小和分辨率不匹配的错误消息
为什么决策表测试很重要？
决策表测试很重要，因为它有助于测试条件的不同组合，并为复杂的业务逻辑提供更好的测试覆盖范围。当测试大量输入的行为时，系统行为随每组输入而不同，决策表测试提供了很好的覆盖范围，并且表示很简单，因此易于解释和使用。
在软件工程中，边界值和等效分区是用于确保更好的覆盖率的其他类似技术。如果系统对大量输入显示相同的行为，则使用它们。但是，在每个输入值集的系统行为都不同的系统中，边界值和等效分区技术对确保良好的测试覆盖率无效。
在这种情况下，决策表测试是一个不错的选择。该技术可以确保良好的覆盖范围，并且表示很简单，因此易于解释和使用。
该表可以轻松理解并涵盖所有组合，因此可以用作需求和功能开发的参考。
随着输入数量的增加，该技术的重要性立即变得清晰。可能的组合数由2 ^ n给出，其中n是输入数。对于n = 10（这是基于Web的测试中非常常见的输入形式），组合的数量将为1024。显然，您无法测试所有组合，但是会使用基于决策的方法来选择可能组合的丰富子集。测试技术。
决策表测试的优势
- 当不同输入的系统行为不同而输入范围的系统行为不同时，等效分区和边界值分析均无济于事，但可以使用决策表。
- 该表示很简单，因此可以轻松解释，也可用于开发和业务。
- 该表将有助于进行有效的组合，并可以确保更好的测试覆盖范围
- 任何复杂的业务条件都可以轻松地转化为决策表
- 在输入组合很低的情况下，通常情况下我们要100％覆盖，这种技术可以确保覆盖。
决策表测试的缺点
主要缺点是，当输入数量增加时，表格将变得更加复杂
软件测试入门系列之二十四：测试评估
已剪辑自: https://zhuanlan.zhihu.com/p/356833446
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pFQ1YnHl-1681309074027)(https://pic1.zhimg.com/v2-ced7e250ca90afd487494dcf8134f45f_720w.jpg?source=172ae18b)]
测试评估是一种管理活动近似于多久任务才能完成。估算测试工作是对一个主要和重要的测试管理任务。
为什么要测试评估？
在讨论潜在的测试项目时，您可以从客户那里想到两个问题：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-S9VCrPm7-1681309074027)(https://pic3.zhimg.com/v2-420bf90baa71d484241417edaf645f6e_r.jpg)]
对于小型项目，这些问题相对容易回答。但是对于像测试 百度网站这样的大型项目，你必须认真思考才能回答这些问题。
评估什么？
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Uw5AX0Vs-1681309074027)(https://pic1.zhimg.com/v2-9bdddd17fe800bba15968bf77d147f48_r.jpg)]
- 资源： 执行任何项目任务都需要资源。它们可以是人员，设备，设施，资金或能够完成项目活动所需的其他任何能够定义的内容。
- 时间：时间是项目中最宝贵的资源。每个项目都有交付期限。
- 技术能力：技术能力是指团队成员的知识和经验。它们会影响您的估计。例如，一个团队的成员具有较低的测试技能，比具有较高测试技能的团队需要更多的时间来完成该项目。
- 成本：成本是项目预算。一般来说，这意味着完成该项目需要花费多少钱。
如何估算？
软件测试评估技术列表
- 工作分解结构
- 三点软件测试评估技术
- Wideband Delphi 技术
- 功能点/测试点分析
- Use–Case Point Method
- 百分比分布
- AD-HOT方法
以下是得出估算值的4个步骤
步骤1）将整个项目任务划分为子任务
任务是已经交给某人的一件工作。为此，您可以使用“工作分解结构”技术。
在这种技术中，将复杂的项目分为模块。这些模块分为子模块。每个子模块进一步分为功能。这意味着将整个项目任务划分为最小的任务。
使用“工作分解”结构将Bank项目分解为5个较小的任务，
之后，您可以将每个任务分解为子任务。该活动的目的是创建任务，详细的可能。
| 任务 | 子任务 |
|---|---|
| 分析软件需求规范 | 研究软需求规范 |
| 采访开发人员和其他利益相关者以了解有关该网站的更多信息 | |
| 创建测试规范 | 设计测试方案 |
| 创建测试用例 | |
| 审查和修订测试用例 | |
| 执行测试用例 | 建立测试环境 |
| 执行测试用例 | |
| 查看测试执行结果 | |
| 报告缺陷 | |
| 创建缺陷报告 | |
| 报告缺陷 |
步骤2）将每个任务分配给团队成员
在此步骤中，将每个任务分配给项目团队中的相应成员。您可以按以下方式分配任务
| 任务 | 会员 |
|---|---|
| 分析软件需求规范 | 所有成员 |
| 创建测试规范 | 测试员/测试分析师 |
| 建立测试环境 | 测试管理员 |
| 执行测试用例 | 测试员，测试管理员 |
| 报告缺陷 | 测试仪 |
第3步：任务的工作量估算
可以应用2种技术来估算任务的工作量
- 功能点法
- 三点估计
方法1）功能点法
在这种方法中，测试经理估算任务的大小，持续时间和成本
步骤A）估算任务的大小
在步骤1中，您已经使用WBS方法将整个项目任务分解为小任务。现在，您估计这些任务的大小。让我们练习一个特定的任务“创建测试规范”
此任务的大小取决于被测系统的功能大小。功能大小反映了与用户相关的功能量。功能越多，系统越复杂。
在开始实际的估算工作之前，将功能点分为三类，例如Complex，Medium Simple，如下所示：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2J6ZNGqG-1681309074028)(https://pic1.zhimg.com/v2-88e8950150c3bf6cbbf866b25d6334f4_r.jpg)]
基于复杂的软件功能，测试管理器必须为每个功能点赋予足够的权重。例如
| 团体 | 重量比 |
|---|---|
| 复杂的 | 5 |
| 中等的 | 3 |
| 简单的 | 1个 |
让我们通过一个简单的示例练习来更清楚地了解以下内容：
在这里看看百度网站的测试规格，软件工程师已经详细描述了软件模块，您能否通过给出每个模块的权重来确定网站功能的复杂性？
功能点越复杂，测试的精力就越多。该网站分为12个功能点，您可以按照以下步骤确定每个功能点的复杂度：
| 编号 | 模块名称 | 适用角色 | 描述 | 数量 |
|---|---|---|---|---|
| 1。 | 余额查询 | 经理客户 | 客户：一个客户可以有多个银行帐户。他只能查看其帐户的余额经理：经理可以查看在其监督下的所有客户的余额 | 3 |
| 2。 | 资金转账 | 经理客户 | 客户：客户可以将资金从其“自己的”帐户转移到任何目标帐户。经理：经理可以将资金从任何源银行帐户转移到目标帐户 | 5 |
| 3。 | 迷你声明 | 经理客户 | 迷你语句将显示一个帐户的最近5笔交易客户：客户只能看到其“自己”帐户的迷你语句经理：经理可以看到任何帐户的迷你语句 | 3 |
| 4， | 个性化声明 | 经理客户 | 定制的对帐单可让您根据日期和交易价值来过滤和显示帐户中的交易客户：客户只能看到“定制的”对帐单，他自己的“客户”对帐单经理：经理可以看到任何帐户的“对帐单”对帐单 | 5 |
| 5， | 更改密码 | 经理客户 | 客户：客户只能更改其帐户的密码。管理员：管理员只能更改其帐户的密码。他无法更改客户密码 | 1个 |
| 6， | 新客户 | 经理 | 经理：经理可以添加新客户。管理员：管理员可以编辑详细信息，例如客户的地址，电子邮件，电话。 | 3 |
| 7 | 新账户 | 经理 | 当前系统提供2种类型的帐户保存当前的一个客户可以有多个储蓄帐户（一个在他的名字，另一个在一个联合的名字，等等）。他可以为自己拥有的不同公司拥有多个经常账户。或者，他可以拥有多个活期帐户和储蓄帐户。经理：经理可以为现有客户添加新帐户。 | 5 |
| 8。 | 编辑帐户 | 经理 | 管理员：管理员可以为现有帐户添加编辑帐户详细信息 | 1个 |
| 9。 | 删除帐户 | 经理 | 经理：经理可以为客户添加删除帐户。 | 1个 |
| 10。 | 删除客户 | 经理 | 客户只有在没有活跃的活期账户或储蓄账户的情况下才能被删除。经理：经理可以删除客户。 | 1个 |
| 11。 | 订金 | 经理 | 经理：经理可以将钱存入任何帐户。通常在现金存入银行分行时完成。 | 3 |
| 12 | 退出 | 经理 | 经理：经理可以从任何帐户中提取资金。通常是在银行分行提取现金时完成的。 | 3 |
步骤B）估算任务的持续时间
在对功能点的复杂性进行分类之后，您必须估计测试它们的持续时间。持续时间表示完成任务需要多少时间。
- 总工作量：完全测试网站的所有功能的努力
- 功能点总数：网站的总模块数
- 每个功能点定义的估计：完成一个功能点的平均工作量。该值取决于负责此任务的成员的生产率。
假设你的项目团队估计每个功能点定义的时间为5小时/点。您可以按以下方式估算测试Guru99 Bank网站所有功能的总投入：
| 重量比 | 功能点数 | 全部的 | |
|---|---|---|---|
| 复杂的 | 5 | 3 | 15 |
| 中等的 | 3 | 5 | 15 |
| 简单的 | 1个 | 4 | 4 |
| 功能总分 | 34 | ||
| 估计每点定义 | 5 | ||
| 预计总工作量（人时） | 170 |
因此，完成Guru99 Bank“创建测试规范”任务的总精力约为170个工时
一旦了解了所需的工作量，就可以分配资源以确定任务将花费多长时间（持续时间），然后可以估算人工和非人工成本。
上面的示例还显示了团队中成员的重要性。如果你有才华和经验丰富的成员，可以完成分配的任务在小的时候，和你的项目将完成在最后期限或之前。
步骤C）估算任务成本
此步骤可帮助您回答客户的最后一个问题“它要花多少钱？”
假设您的团队平均每小时工资为5美元。“创建测试规格”任务所需的时间为170小时。因此，任务成本为5 * 170 = 850美元。现在，您可以计算WBS中其他活动的预算，并得出该项目的总预算。
作为项目经理，您必须决定如何从公司的投资中获得最大的回报。更准确的项目成本的估算是，在更好的能你会管理你的项目的预算。
方法2）三点估计
三点估计是可用于估计任务的技术之一。三点估算的简单性使其成为想要估算的项目经理非常有用的工具。
在三点估计中，将根据先前的经验或最佳指导为每个任务初始生成三个值，如下所示：
估计任务时，测试管理器需要提供三个值，如上所述。确定的三个值，估计在发生什么最佳状态，什么是最有可能的，或者我们认为这将是什么样 最坏情况的场景。
在下面的示例中，让我们看看如何使用以上三个值
对于“创建测试规范”任务，您可以估计测试工作量吗？请记住，您必须按照功能点方法的要求覆盖Guru99 Bank网站的所有模块
您可以估算如下
- 完成此任务的最佳情况是120个工时（约15天）。在这种情况下，您将拥有一支才华横溢的团队，他们可以在最短的时间内完成任务。
- 完成此任务的最可能案例是170个工时（约21天）。这是正常情况，您有足够的资源和能力来完成任务
- 完成此任务的最坏情况是200个工时（约25天）。您需要执行更多工作，因为您的团队成员没有经验。
现在，将值分配给每个参数，如下所示
可以使用双三角分布公式计算完成任务的工作量，如下所示：
在上式中，参数E称为加权平均值。它是对“创建测试规范”任务的估计。
但是你老板可能会问你
在以上估计中，您仅确定一个可能的值而不是某个值，我们必须知道估计正确的可能性。您可以使用其他公式：
在上面的公式中，SD表示标准偏差，此值可以为您提供有关估计正确的概率的信息。
现在，您可以完成任务“创建测试规范”的估计了
要完成Guru99 Bank网站的“创建测试规范”任务，您需要166.6±13.33工时（153.33至179.99工时）
步骤4）验证估算
为WBS中提到的所有任务创建汇总估算后，您需要将其转发给管理委员会，管理委员会将对其进行审核和批准。
管理委员会的成员可以包括首席执行官，项目经理和其他利益相关者。
管理委员会将与您一起审查并讨论您的估算计划。您可以在逻辑上合理地向他们解释您的估算，以便他们可以批准您的估算计划。
测试估算最佳做法
本主题介绍有关如何估计测试准确性的一般提示。
- 增加一些缓冲时间：您的项目可能会发生很多不可预测的事情，例如，一个才华横溢的团队成员突然辞职，测试花费的时间比估计的要多……等等。这就是为什么您需要在估计中包括一些缓冲的原因。在估计中具有缓冲器使得能够应对可能发生的任何延迟。
- 估算中的客户资源计划：如果团队中的某些成员休假很长，该怎么办？这可能会延迟项目。估算中的资源计划起着关键作用。资源的可用性将有助于确保估算是切合实际的。在这里，您必须考虑团队成员的休假，通常是长假。
- 使用过去的经验作为参考： 过去的项目的经验在准备时间估算时起着至关重要的作用。由于某些项目可能具有某些相似性，因此您可以重用过去的估计。例如，如果您曾经做过像测试网站这样的项目，则可以从中汲取经验，并尽量避免在过去的项目中遇到的所有困难或问题。
- 坚持您的估算： 估算只是估算，因为它可能会出错。在项目的早期阶段，您应该经常重新检查测试估算，并在需要时进行修改 。除非有重大更改，或者您必须与客户就重新估算进行协商，否则在修正后，我们不应扩展估算。
软件测试入门系列之二十五：测试计划
已剪辑自: https://zhuanlan.zhihu.com/p/356836809
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vF7rGc5q-1681309074029)(https://picx.zhimg.com/v2-bb2ec5b3ac52159ef594ed7388f8d97a_720w.jpg?source=172ae18b)]
什么是测试计划
一个测试计划是一个详细的文件，介绍了测试策略，目标，计划，评估，交付，并进行测试的软件产品所需的资源。测试计划可帮助我们确定验证被测应用程序质量所需的工作。测试计划是将软件测试活动作为已定义过程进行处理的蓝图，该过程由测试管理者进行细致的监视和控制。
根据ISTQB的定义：“测试计划是一份文档，描述了预期测试活动的范围，方法，资源和时间表。”
让我们从下面的测试计划示例/场景开始：在一次会议中，您想与团队成员讨论测试计划，但是他们并不感兴趣。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-j2LMi70i-1681309074029)(https://pic4.zhimg.com/80/v2-1d1e492bc69a875b819446302b6813db_1440w.webp)]
测试计划的重要性
- 帮助测试团队以外的人员，例如开发人员，业务经理，客户 了解测试的详细信息。
- 测试计划指导我们的思考。这就像一本规则手册，需要遵循。
- 测试计划中记录了测试评估，测试范围，测试策略等重要方面，因此管理团队可以对其进行审核，并重新用于其他项目。
如何编写测试计划
你已经知道制定测试计划是测试管理过程中最重要的任务。按照以下七个步骤，按照IEEE 829创建测试计划
- 分析产品
- 设计测试策略
- 定义测试目标
- 定义测试标准
- 资源规划
- 计划测试环境
- 时间表与估算
- 确定测试交付物
步骤1）分析产品
在没有任何信息的情况下如何测试产品？答案是不可能的。在测试产品之前，您必须彻底学习产品。
被测产品是Guru99银行网站。您应该研究客户和最终用户，以了解他们对应用程序的需求和期望
- 谁将使用该网站？
- 它是干什么用的？
- 它将如何运作？
- 产品使用什么软件/硬件？
可以使用以下方法来分析站点
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZebxzLbB-1681309074030)(https://pic4.zhimg.com/v2-0aad784c567f9dc78c0905796c7e0857_r.jpg)]
现在，让我们将以上知识应用于真实产品：分析银行网站http://demo.guru99.com/V4。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nUV9EYvB-1681309074030)(https://pic2.zhimg.com/v2-fb7728f9256bd7dc09ab6a5e81166399_r.jpg)]
您应该浏览一下该网站，并查看产品文档。查看产品文档可帮助您了解网站的所有功能以及如何使用它。如果您不清楚任何项目，则可以采访客户，开发人员，设计师以获取更多信息。
步骤2）制定测试策略
测试策略是制定软件测试中的测试计划的关键步骤。测试策略文档是高级文档，通常由测试管理器开发。本文档定义：
- 项目的测试目标以及实现这些目标的方法
- 确定测试工作量和成本
回到项目，您需要开发测试策略来测试该银行网站。您应该按照以下步骤
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AzSbItz9-1681309074030)(https://pic2.zhimg.com/v2-b423107b620fc969e4be2bfedb38de65_r.jpg)]
步骤2.1）定义测试范围
在开始任何测试活动之前，应该知道测试的范围。您必须认真考虑。
- 将要测试的系统组件（硬件，软件，中间件等）定义为“在范围内”
- 还需要将将不进行测试的系统组件明确定义为“超出范围”。
- 定义测试项目的范围对于所有利益相关者都非常重要。精确的范围可以帮助您
- 给大家一个关于您正在进行的测试的信心和准确的信息
- 所有项目成员都将对测试内容和未测试内容有清楚的了解
您如何确定项目范围？
要确定测试范围，您必须
- 精确的客户要求
- 项目预算
- 产品规格书
- 测试团队的技能和才能
- 现在应该清楚地定义“范围内”和“范围外”的测试。
- 作为软件需求规范，项目Guru99 Bank仅专注于测试网站Guru99 Bank的所有功能和外部接口（在范围测试中）
- 当前将不测试非功能性测试，例如压力，性能或逻辑数据库。（超出范围）
问题场景
客户希望您测试他的API。但是项目预算不允许这样做。在这种情况下，您会怎么做？
好吧，在这种情况下，您需要使客户相信Api Testing是额外的工作，并且会消耗大量资源。给他提供支持您事实的数据。告诉他，如果范围内包括Api Testing，则预算将增加XYZ金额。
客户同意，因此，超出范围的新范围是
步骤2.2）识别测试类型
一个测试类型是一个标准的测试程序，让预期的测试结果。
制定了每种测试类型以标识特定类型的产品错误。但是，所有测试类型均旨在实现一个共同的目标：“在将产品发布给客户之前及早发现所有缺陷”。
在通常使用的测试类型被描述为如下图
有大量用于测试软件产品的测试类型。您的团队没有足够的精力来处理所有类型的测试。作为测试管理员，您必须设置测试类型的优先级。
步骤2.3）记录风险和问题
风险是未来的不确定事件，具有发生的可能性和潜在的损失。当风险实际发生时，就成为“问题”。
在“风险分析和解决方案”一文中，您已经详细了解了“风险”分析并确定了项目中的潜在风险。
在质量检查测试计划中，您将记录这些风险。
| 风险 | 减轻 |
|---|---|
| 团队成员缺乏网站测试所需的技能。 | 计划培训课程以提高成员技能 |
| 项目进度太紧；很难按时完成这个项目 | 为每个测试活动设置“测试优先级”。 |
| 测试经理的管理技能很差 | 为经理计划领导力培训 |
| 缺乏合作会对您的员工的生产力产生负面影响 | 鼓励每个团队成员执行任务，并激励他们做出更大的努力。 |
| 预算估算错误和费用超支 | 在开始工作之前确定范围，非常注意项目计划并不断跟踪和衡量进度 |
步骤2.4）创建测试物流
在测试物流中，测试经理应回答以下问题：
- 谁来 测试？
- 什么时候 进行测试？
谁来测试？
您可能不知道将进行测试的测试人员的确切姓名，但是可以定义测试人员的类型。
要为特定任务选择合适的成员，您必须考虑其技能是否适合该任务，并估算项目预算。为任务选择错误的成员可能会导致项目失败或延迟。
具有以下技能的人员最适合进行软件测试：
- 理解客户观点的能力
- 对品质的强烈渴望
- 注意细节
- 良好的合作
在您的项目中，负责测试执行的成员是测试人员。根据项目预算，您可以选择内部或外部成员作为测试人员。
什么时候进行测试？
测试活动必须与相关的开发活动相匹配。
当您具有下图所示的所有必需项时，您将开始测试
步骤3）定义测试目标
测试目标是测试执行的总体目标和成就。测试的目的是要找到尽可能多的软件缺陷。在发布之前，请确保被测软件没有错误。
要定义测试目标，您应该执行以下两个步骤
- 列出所有可能需要测试的软件功能（功能，性能，GUI等）。
- 根据上述特征定义测试的目标或目标
让我们应用这些步骤来找到您的Guru99 Bank测试项目的测试目标
您可以选择“自上而下”的方法来查找可能需要测试的网站功能。通过这种方法，您可以将被测试的应用程序分解为component和sub-component。
在上一个主题中，您已经分析了需求规格并浏览了网站，因此可以创建一个思维导图来查找网站功能，如下所示
该图显示了Guru99网站可能具有的所有功能。
基于上述功能，您可以按以下方式定义项目Guru99的“测试目标”
- 检查网站Guru99的功能（帐户，存款…）是否按预期工作，在实际业务环境中没有任何错误或错误。
- 检查网站的外部界面（例如UI）是否按预期工作并满足客户需求
- 验证网站的可用性。这些功能是否方便用户使用？
步骤4）定义测试标准
测试标准是可以作为测试程序或测试判断依据的标准或规则。有以下两种测试标准
暂停条件
指定测试的关键暂停标准。如果在测试期间满足暂停标准，则将暂停活动测试周期，直到解决标准为止。
测试计划示例：如果您的团队成员报告说有40％的测试用例失败，则应该暂停测试，直到开发团队修复所有失败的用例为止。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lAFcaLPJ-1681309074031)(https://pic2.zhimg.com/v2-fa9e564c3faeb1c6675b36d2a5802be5_r.jpg)]
退出条件
它指定了表示成功完成测试阶段的标准。退出标准是测试的目标结果，在进入下一开发阶段之前是必需的。示例：所有关键测试用例中的95％必须通过。
定义退出标准的一些方法是通过指定目标运行速度和通过速度。
- 运行率是执行的测试用例数/测试规范的总测试用例之间的比率。例如，测试规范总共有120个TC，但测试人员仅执行了100 TC，因此运行速率为100/120 = 0.83（83％）
- 通过率是通过的测试用例/执行的测试用例数之比。例如，在执行的100多个TC中，有80个TC通过，因此合格率为80/100 = 0.8（80％）
- 可以在“测试指标”文档中检索此数据。
- 除非给出明确的原因，否则运行率必须为100％。
- 通过率取决于项目范围，但是要达到高通过率是一个目标。
测试计划示例：您的团队已经完成了测试执行。他们向您报告测试结果，并希望您确认退出标准。
在上述情况下，强制运行率是100％，但是测试团队仅完成了90％的测试用例。这意味着不满足运行速度，因此请勿确认退出条件
步骤5）资源计划
资源计划是完成项目任务所需的所有类型资源的详细摘要。资源可能是完成项目所需的人力，设备和材料
资源计划是测试计划的重要因素，因为它有助于确定要用于项目的资源（员工，设备……）的数量。因此，测试经理可以为项目制定正确的进度表和估算。
本部分代表您的项目的推荐资源。
人力资源
下表代表了您的项目团队中的各个成员
| 编号 | 成员 | 任务 |
|---|---|---|
| 1。 | 测试经理 | 管理整个项目定义项目方向获取适当的资源 |
| 2。 | 测试执行人 | 识别并描述适当的测试技术/工具/自动化架构验证和评估测试方法执行测试，记录结果，报告缺陷。测试人员可以是内部成员，也可以是外部成员，具体取决于项目预算对于需要低技能的任务，我建议您选择外包成员以节省项目成本。 |
| 3。 | 测试中的开发人员 | 实施测试用例，测试程序，测试套件等。 |
| 4， | 测试管理员 | 建立并确保管理和维护测试环境和资产支持测试人员使用测试环境进行测试执行 |
| 5， | SQA成员 | 负责质量保证检查确认测试过程是否满足指定要求 |
系统资源
为了进行测试，对于Web应用程序，您应该按照下表来计划资源：
| 编号 | 资源 | 内容描述 |
|---|---|---|
| 1。 | 服务器 | 安装被测Web应用程序这包括单独的Web服务器，数据库服务器和应用程序服务器（如果适用） |
| 2。 | 测试工具 | 测试工具是使测试自动化，模拟用户操作，生成测试结果的工具您可以在此项目中使用大量测试工具，例如Selenium，QTP等。 |
| 3。 | 网络 | 您需要一个包含LAN和Internet的网络来模拟真实的业务和用户环境 |
| 4， | 电脑 | 用户经常用来连接Web服务器的PC |
步骤6）计划测试环境
什么是测试环境
测试环境是测试团队将在其上执行测试用例的软件和硬件的设置。测试环境由真实的业务和用户环境以及物理环境（例如服务器，前端运行环境）组成。
如何设置测试环境
回到您的项目，如何为该银行网站设置测试环境？
要完成此任务，您需要测试团队与开发团队之间的强有力合作
您应该向开发人员提出一些问题，以清楚地了解要测试的Web应用程序。这是一些建议的问题。当然，您可以根据需要提出其他问题。
- 该网站可以同时处理的最大用户连接数是多少？
- 安装此网站有什么硬件/软件要求？
- 用户的计算机是否需要任何特定设置才能浏览网站？
下图描述了银行网站www.demo.guru99.com/V4的测试环境
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FRBtr2BK-1681309074032)(https://pic3.zhimg.com/v2-2676184fa349edb25356583a0a64ed7e_r.jpg)]
步骤7）时间表与估算
在“测试评估”一文中，您已经使用了一些技术来估算完成项目的工作量。现在，您应该将该估计以及测试计划的时间表包括在内
在“测试估算”阶段，假设您将整个项目分解为多个小任务，并按如下所示为每个任务添加估算
| 任务 | 会员 | 估算工作量 |
|---|---|---|
| 创建测试规范 | 测试设计师 | 170工时 |
| 执行测试执行 | 测试员，测试管理员 | 80工时 |
| 测试报告 | 测试仪 | 10工时 |
| 测试交付 | 20工时 | |
| 280工时 |
然后，您创建计划以完成这些任务。
制定时间表是项目管理中的常用术语。通过在测试计划中创建可靠的计划，测试管理器可以将其用作监视项目进度，控制成本超支的工具。
要创建项目进度表，测试管理器需要以下几种类型的输入：
- 员工和项目期限：工作日，项目期限，资源可用性是影响进度的因素
- 项目估算：根据估算，测试经理知道完成项目需要多长时间。这样他就可以制定适当的项目进度表
- 项目风险：了解风险有助于测试经理为项目时间表增加足够的额外时间来应对风险
让我们用一个例子来练习：
假设老板要完成项目Guru99中的一个月，你已经估计在测试估计每个任务的努力。您可以如下创建时间表
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KJ7t3cqS-1681309074032)(https://pic4.zhimg.com/v2-9bf4e448c0aeb63b7d3cfe8a44836ce3_r.jpg)]
步骤8）测试可交付成果
测试交付物是必须开发和维护以支持测试工作的所有文档，工具和其他组件的列表。
在软件开发生命周期的每个阶段，都有不同的测试可交付成果。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LwRTFSQx-1681309074032)(https://pic2.zhimg.com/v2-621518e0823b4a4e00f82b8401c265e5_r.jpg)]
在测试阶段之前提供了测试交付物。
- 测试计划文件。
- 测试用例文件
- 测试设计规范。
在测试过程中提供测试交付物
- 测试脚本
- 模拟器。
- 测试数据
- 测试追踪矩阵
- 错误日志和执行日志。
测试周期结束后，将提供测试交付物。
- 测试结果/报告
- 缺陷报告
- 安装/测试程序指南
- 发行说明
软件测试入门系列之二十六：白盒测试
已剪辑自: https://zhuanlan.zhihu.com/p/357921820
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9CtBkRKu-1681309074032)(https://pic1.zhimg.com/v2-ec5ae59ad2d810dca2da08821d4a83c8_720w.jpg?source=172ae18b)]
第一节：什么是白盒测试？
白盒测试是软件测试技术，白盒测试也称结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例，主要用于软件程序验证。白盒测试中也称为透明盒测试、基于代码的测试和玻璃盒测试。
它是Box Testing软件测试方法之一。与之相对应的黑盒测试是从用户角度对软件进行测试。另一方面，软件工程中的白盒测试基于应用程序的内部工作，并围绕内部测试。
由于透明盒的概念，因此使用了“ WhiteBox”一词。透明盒或WhiteBox名称象征着能够查看软件外壳内部功能的实现逻辑。与之相反，“黑盒测试”中的“黑匣子”无法看到软件的内部运行情况，因此只能从用户的使用角度进行测试。
白盒测试测试什么？
白盒测试涉及以下测试内容：
- 内部安全漏洞
- 编码规范
- 预期输出
- 条件循环的功能
- 分别测试每个语句、对象和功能
白盒测试可以在软件开发的系统、集成和单元测试阶段进行。
如何进行白盒测试？
为了简化对白盒测试的解释，将其分为两个基本步骤。这是测试人员使用白盒测试技术测试应用程序时所做的事情：
第1步）了解源代码
测试人员经常要做的第一件事是学习和理解应用程序的源代码。由于白盒测试涉及对应用程序内部工作的测试，因此测试人员必须非常了解所测试应用程序中使用的编程语言。另外，测试人员必须十分了解安全编码规范。软件安全性通常是软件测试的主要目标之一。测试人员应该能够发现安全问题，并防止黑客攻击。
第2步：创建并执行测试用例
白盒测试的第二个步骤是测试应用程序的源代码，以了解其正确的流程和结构。一种方法是编写更多测试代码以测试应用程序的源代码。测试人员将为应用程序中的每个函数开发一定的测试用例。这种方法要求测试人员必须对代码有深入的了解，并且这通常由开发人员来完成。
白盒测试案例
看一下以下代码
Printme（int a，int b）{ int结果= a + b; 如果（结果> 0） 打印（“正”，结果） 别的 打印（“负”，结果） }
软件工程中WhiteBox测试的目标是验证代码中的所有决策分支、循环、语句。
为了执行上述白盒测试示例中的语句，WhiteBox测试用例为
- A = 1，B = 1
- A = -1，B = -3
白盒测试技术
白盒测试的主要技术是代码覆盖率分析。代码覆盖率分析消除了测试用例套件中的空白。它标识一组测试用例未执行的程序区域。一旦发现用例覆盖空白域，就可以创建测试用例以验证未经测试的代码部分，从而提高软件产品的质量。
以下是白盒测试的几种覆盖率分析技术：
语句覆盖：这种技术要求在软件工程的测试过程中，至少对代码中的每个可能的语句进行一次测试。
**分支覆盖：**它要求覆盖软件应用程序的每个可能路径（if-else和其他条件循环）。
除上述内容外，还有许多覆盖类型，例如条件覆盖，多个条件覆盖，路径覆盖，功能覆盖等。每种技术都有其自身的优点，并尝试测试（覆盖）软件代码的所有部分。使用语句和分支覆盖率，通常可以达到80-90％的代码覆盖率，这已经很充足了。
以下是重要的白盒测试技术：
- 语句覆盖
- 决策覆盖
- 分支覆盖
- 条件覆盖
- 多条件覆盖
- 有限状态机覆盖
- 路径覆盖
- 控制流测试
- 数据流测试
白盒测试的类型
白盒测试包含几种用于评估应用程序，代码块或特定软件包的可用性的测试类型。
- 单元测试： 通常是在应用程序上进行的第一类测试。单元测试是在开发每个单元或代码块时执行的。单元测试本质上是由程序员完成的。作为软件开发人员，您需要开发几行代码，一个函数或一个对象，并对其进行测试，以确保其可以正常工作，然后再继续进行单元测试，以帮助在软件开发生命周期的早期识别出大多数错误。在此阶段发现的错误更便宜且易于修复。
- 测试内存泄漏：内存泄漏是导致应用程序运行缓慢的主要原因。如果您的软件应用程序运行缓慢，那么具有丰富的检测内存泄漏经验的质量保证专家至关重要。
除上述之外，黑盒和白盒测试均包含一些测试类型。它们列出如下
- **白盒渗透测试：**在此测试中，测试人员/开发人员具有应用程序源代码的完整信息，详细的网络信息，所涉及的IP地址以及应用程序在其上运行的所有服务器信息。目的是从多个角度对代码进行攻击以暴露安全威胁
- 白盒突变测试：突变测试通常用于发现用于扩展软件解决方案的最佳编码技术。
白盒测试工具
下面是顶级白盒测试工具的列表：
软件测试入门系列之二十七：静态测试
已剪辑自: https://zhuanlan.zhihu.com/p/358583864
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OxYKwFZC-1681309074033)(https://pica.zhimg.com/v2-e84dddf50631a98ad1f1b1dbdbfb01ef_720w.jpg?source=172ae18b)]
什么是静态测试
顾名思义，这里的静态是指程序的状态，即在不执行代码的情况下检查软件应用程序中的缺陷。进行静态测试是为了仅早在开发的早期阶段发现程序缺陷，因为这样可以更快速地识别缺陷并低成本解决缺陷，它还有助于查找动态测试过程找不到的缺陷。与静态测试对应的是动态测试(Dynamic Testing)，它指在代码执行过程测试应用程序。
静态测试技术的两种类型
- 人工检查：指人工完成的代码的分析，也称为CodeRreview。
- 工具自动分析：自动化分析基本上是借助于工具完成的静态分析。
什么是测试评审？
静态测试中的评审是为了发现任何程序设计中的潜在缺陷而进行的活动。评审的另一个好处是，帮助所有团队成员都了解项目本身，有时想法的多样性可能会产生出色的建议。项目文件直接由项目相关人员检查，并找出大家对统一需求理解的差异性。
评审可以为四个部分：
- 非正式评审
- 演示
- 技术评审
- 审查
在评审过程中，参与者分别是：
- 主持人：执行入场检查，跟进返工，指导团队成员，安排会议。
- 作者：负责修复发现的缺陷并提高文档质量
- 抄写员：在评审过程中记录缺陷并参加评审会议
- 审稿人：检查材料是否有缺陷并检查
- 经理：决定执行评审，并确保达到评审过程的目标。
在静态测试中更容易发现的缺陷类型为：
- 违背(编码)标准
- 代码可维护性差
- 代码存在缺陷
- 需求缺失
- 接口规范不一致
通常，在静态测试中发现的缺陷是变量未声明、边界逻辑处理考虑不全面、语法错误、接口设计不一致等因素引起的。
为什么要进行静态测试？
由于以下原因：
- 早期更容易发现缺陷和修复
- 缩短开发时间
- 降低测试成本和时间
- 为了提高开发效率
- 降低测试阶段出现缺陷的概率
静态测试测试内容是什么
在“静态测试”中，对以下内容进行测试
- 单元测试用例
- 业务需求文档（BRD）
- 用例
- 系统/功能要求
- 原型
- 原型规格文件
- 数据库字段字典电子表格
- 测试数据
- 需求跟踪矩阵文件
- 用户手册/培训指南/文档
- 测试计划策略文档/测试用例
- 自动化/性能测试脚本
如何进行静态测试
要做静态测试，它可以通过以下方式完成：
- 进行检查过程以完全检查应用程序的设计
- 对要审核的每个文档使用清单，以确保所有审核均被完全覆盖
执行静态测试的各种活动是：
- **用例需求验证：**它验证是否标识了所有最终用户操作以及与之关联的任何输入和输出。用例越详细和透彻，测试用例就越准确和全面。
- 功能需求验证：确保功能需求标识所有必要的元素。它还查看数据库功能，接口列表以及硬件，软件和网络要求。
- 架构评审：所有业务级别的流程，例如服务器位置，网络图，协议定义，负载平衡，数据库可访问性，测试设备等。
- 原型/屏幕模型验证：此阶段包括需求和用例的验证。
- 字段字典验证：UI中的每个字段都定义得足够好，可以创建字段级别的验证测试用例。字段用于检查最小/最大长度，列表值，错误消息等。
静态测试技术有哪些
-
非正式评审
-
演示
-
技术评审
-
审查
-
静态分析
-
- 数据流
- 控制流
静态测试的工具有哪些
静态测试的工具如下：
静态测试的技巧
静态测试的一些技巧：
- 只专注于真正重要的事情
- 明确计划和跟踪审核活动。通常将软件演练和检查综合到同行的评论中
- 解决人员问题
- 持续改进流程和工具
- 通过消除测试执行中的主要延迟，可以减少测试成本和时间
概括
- 静态测试是为了尽早发现缺陷。
- 静态测试不能替代动态测试，两者都会发现不同类型的缺陷
- 评审是进行静态测试的有效技术
软件测试入门之二十八：代码覆盖率
已剪辑自: https://zhuanlan.zhihu.com/p/358585328
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UDiZo8ky-1681309074033)(https://pica.zhimg.com/v2-32d32320872270c88caa8f3c2e226fd2_720w.jpg?source=172ae18b)]
代码覆盖率是一种度量，它描述了对程序源代码的测试程度。这是白盒测试的一种手段，它可以发现测试用例无法覆盖到的程序。测试人员可以创建代码覆盖缺失的测试用例，以增加覆盖率并确定代码覆盖率的定量度量。
在大多数情况下，代码覆盖系统会收集有关正在运行程序的信息。它还将其与源代码信息相结合，以生成有关测试套件的代码覆盖率的报告。
为什么要使用代码覆盖率？
以下是使用代码覆盖率的一些主要原因：
- 它可以帮助你评估测试的效率
- 它提供了定量测量手段
- 它帮助你了解对源代码测试程度。
代码覆盖方法
以下是主要的代码覆盖方法
- 语句覆盖
- 判定覆盖
- 分支覆盖
语句覆盖
语句覆盖是一种白盒测试技术，其中源代码中的所有可执行语句至少执行一次。它用于计算源代码中已执行的语句数。语句覆盖的主要目的是覆盖源代码中所有可能的路径、行和语句。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JfEvja5E-1681309074033)(https://pic2.zhimg.com/v2-848466c1dc2c688b522bb81f19b55c8d_r.jpg)]
在“白盒测试”中，测试人员专注于软件程序的“工作”方式。
通常，在任何软件中，如果我们查看源代码，都会有各种各样的元素，例如运算符、函数、循环、异常处理程序等。根据程序的输入，某些代码语句可能不会执行。
让我们通过一个示例来了解如何计算语句覆盖率。
在这里，我们采用两种不同的方案来检查每种方案的语句覆盖率。
源代码：
print（int a，int b）{------------ Printsum是一个函数 int result = a + b; if（result> 0） print（“Positive”，result） else print（“Negative”，result） } -----------源代码结尾
方案1：
如果A = 3，B = 9
黄色标记的是根据业务情景执行的语句
已执行的语句数= 5，语句总数= 7
语句覆盖率：5/7 = 71％
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Xh5ChY0M-1681309074034)(https://pic4.zhimg.com/80/v2-e45e715fe13ff576b43115613b652587_1440w.webp)]
方案2：
如果A = -3，B = -9
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qgHWUKdM-1681309074034)(https://pic2.zhimg.com/80/v2-50ba1b6fbd5bc2ce1f8e29a63d8e4f9d_1440w.webp)]
黄色标记的是根据业务场景执行的语句。
执行语句数= 6
语句总数= 7
语句覆盖率：6/7 = 85％
但是总的来说，所有的未覆盖的语句都被第二种方案所覆盖。因此我们可以得出结论，语句覆盖率为100％。
语句覆盖范围是什么？
- 未执行的语句
- Dead Code
- 未执行的分支
判定覆盖
判定覆盖是一种白盒测试技术，它指出源代码的每个布尔表达式正确或错误执行的情况。判定覆盖的目标是通过检查并确保每个判定点的每个分支至少执行一次来覆盖和验证所有可访问的源代码。
在这种情况下，表达式有时会变得复杂。因此，很难实现100％的覆盖率。这就是为什么有许多不同的方法来报告此指标的原因。所有这些方法都专注于覆盖最重要的组合，但是对控制流的敏感性更高。
判定覆盖示例
Demo（int a）{ if（a > 5） a = a * 3 print（a） }
方案1：
a=2
以黄色显示的代码将被执行，执行判定为否，判定覆盖率 = 50％
方案2：
a=6
以黄色显示的代码将被执行，执行判定为是，判定覆盖率= 50％
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-p9vO7ksB-1681309074035)(https://pic3.zhimg.com/v2-23a108a29cd71d284ebe90c5218eb0f2_r.jpg)]
分支覆盖
分支覆盖是一种白盒测试方法，其中对来自代码模块（语句或循环）的每个结果进行测试。分支覆盖的目的是确保来自每个分支的每个决策条件至少执行一次。它有助于测量独立代码段的百分比，并找出没有分支的部分。
例如，如果结果是布尔类型，则需要同时测试True和False结果。计算分支覆盖率的公式：
要了解分支机构的覆盖范围，让我们考虑之前使用的相同示例：
Demo(int a) {
If (a> 5) a=a*3 Print (a)
}
分支覆盖范围也将考虑无条件分支
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bokx3N8W-1681309074035)(https://pic2.zhimg.com/v2-1ffdfdfb7d431c7c6669b3415d4c8a6d_r.jpg)]
分支覆盖的优势：
分支覆盖率具有以下优点：
- 能让你验证代码中的所有分支
- 帮助你确保没有分支导致程序操作的任何异常
- 分支覆盖方法可消除由于语句覆盖测试产生的问题
- 使你可以找到其他测试方法未测试的区域
- 分支覆盖率会忽略布尔表达式内部的分支
条件覆盖
条件覆盖是一种测试方法，用于测试和评估条件语句中的变量或子表达式。条件覆盖的目标是检查每个逻辑条件的单个结果。与判定覆盖相比，条件覆盖对控制流的敏感性更高。
条件覆盖率的计算公式：
例子：
对于以上表达式，我们有4种可能的组合：
- TT
- FF
- TF
- FT
考虑以下输入
代码覆盖率与功能覆盖率
代码覆盖率工具
以下是重要代码覆盖率工具的列表：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-c1yvTy7Z-1681309074036)(https://pic2.zhimg.com/v2-cff42129765b7e2f43b35a61e4768f45_r.jpg)]
代码覆盖率的优点
- 有助于评估量化的代码覆盖率
- 它允许您创建额外的测试用例以增加覆盖范围
- 它使您可以找到一组测试用例无法执行的程序区域
代码覆盖率的缺点
- 即使在设计中未实现任何特定功能，代码覆盖率仍然可能报告为100％覆盖率。
- 无法确定是否在代码覆盖率的帮助下测试了功能的所有可能值
- 代码覆盖率也没有告诉您覆盖逻辑的程度和程度
- 如果指定的功能尚未实现或未包含在规范中，则基于结构的技术将找不到该问题。
概括
- 代码覆盖率是一种度量，它描述了程序源代码已经过测试的程度
- 它可以帮助你评估测试执行的效率
- 五个代码覆盖率方法是1.）语句覆盖率2.）条件覆盖率3）分支覆盖率
- 语句覆盖涉及至少一次执行源代码中的所有可执行语句
- 判定覆盖率报告每个布尔表达式的正确或错误结果
- 在分支机构中，将测试代码模块的所有结果
- 条件语句将揭示如何评估条件语句中的变量或子表达式
- 代码覆盖率告诉您测试平台对源代码的执行情况，而功能覆盖率则衡量设计功能被覆盖的程度
- Cobertura、JTest、Clover、Emma和Kalistick是一些重要的代码覆盖工具
- 代码覆盖率使你可以创建额外的测试用例以增加覆盖率
- 代码覆盖率无法帮助您确定我们是否测试了功能的所有可能值
软件测试入门系列之三十五：接口测试
已剪辑自: https://zhuanlan.zhihu.com/p/373683516
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3ttsyUIb-1681309074037)(https://picx.zhimg.com/v2-721075b3fbd62d008c92140b6caf0f75_720w.jpg?source=172ae18b)]
单接口测试
\1. json格式测试
通常POST/RPC接口请求参数都是json格式，那么就需要去测试 如果传递非json的情况，这时候程序会不会正确的处理，返回相应的error code。
\2. 默认值测试
很多情况一些参数会有默认值，比如说一个查询的接口，参数count定义为返回查询结果数量， 默认为10，那么就应该有一条case来测试，当然前置条件是数据库里面必须要存在超过10条的数据。
\3. 异常类型测试
比如上面的count参数，这个参数的类型一定是可以转换为int类型的，这时候我们需要测试如果传的一些不可以 转换为int类型值来测试代码是否加入判断
\4. 必传项测试
如果接口的参数有必传项，那么需要测试覆盖不传这个参数场景接口返回情况，检查是否会提示相应的error code
\5. 非必传项测试
如果接口有非必填项，当不传递这些参数的时候会不会正常的返回相应的结果 。
6.非空测试
无论是必传的和非必传的参数，传递的key是正确的，但是value=null，这时候返回结果是否正确 。
7.业务逻辑测试
传递正确的参数，接口对数据库进行查询的操作，需要去验证数据库查询是否正确，接口对数据库进行增删改的操作，也需要看数据库是否同步进行了这些操作。
8.兼容性测试
比如说今天接口进行了调整，但是前端没有进行变更，这时候需要验证新的接口是否满足旧的调用方式。
9.错误码测试
通用的错误码与业务错误码是否能够清晰的说明调用问题，错误码是否能够尽可能的全的覆盖所有的异常调用情况。
10.数据异常测试
假如数据库设计为32位varchar类型，那么如果传33位数据是什么情况，会不会抛出相应的错误码，而不会抛出数据库异常。
11.返回值测试
返回值除了内容是正确的，还需要数据类型也是正确的，保证调用方拿到这些数据能够正确的解析和使用。
12.加密测试
一般登陆接口会对用户输入的密码进行加密处理以防止用户明码泄露导致用户信息泄露。测试需要对加密后的数据进行测试，检查是否做正确加密。
组合接口测试
单接口测试通过后，需要将多个单接口组成连续的场景，比如说投资接口需要用到一个类似token的参数，而这个参数是登陆接口获取到的，所以就需要先调用登陆接口，然后再去调用投资接口。还有就是 像数据权限与操作权限这些，都会依赖一些其他的接口，那么把这些依赖的接口组成一个场景来测试数据的 正确性。还有一部分接口是内部调用的，比如说注册接口，在注册的时候通常需要获取一个验证码，然后输入 验证码再进行提交注册的操作，在这过程中，验证验证码的操作是在注册的内部完成的，那么其实在组合场景 的时候就不需要再去中间加入验证验证码的接口。
常用接口测试工具
1、 postman
2、jmeter
总结
1. 接口测试小结
1、检查接口返回的数据是否与预期结果一致。
2、检查接口的容错性，假如传递数据的类型错误时是否可以处理。例如上面的例子是支持整数，传递的是小数或字符串呢？
3、接口参数的边界值。例如，传递的参数足够大或为负数时，接口是否可以正常处理。
4、接口性能，接口处理数据的时间也是测试的一个方面。牵扯到内部就是算法与代码的优化。
5、接口的安全性，如果是外部接口的话，这点尤为重要。
2. 单接口与组合接口测试区别
1、单接口 单接口入参，出参 入参：参数边界值、类型、非必传、必传 出参：数据类型、结果与MySQL表数据比较、响应码(正确码、错误码)、数据的准确性(比如四舍五入的情况、浮点被强制成整型等) 权限（重要）：token失效（有效）
2、组合接口 结合测试场景(要结合业务)，编写相应的测试用例；场景：比如新建一个客群，验证将其转化为系统客群 是否成功；
3032
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
