26、软件测试的高效之道与策略-优快云博客

本文链接：https://blog.youkuaiyun.com/cicd6pipeline/article/details/153285412

软件测试的高效之道与策略

在软件测试领域，追求高效和全面的测试是至关重要的。下面将详细介绍软件测试的相关内容，包括测试用例、测试方法、测试流程以及高效测试的策略。

测试用例示例

以下是一系列测试用例的代码展示，涵盖了等待条件、点击操作、输入文本等操作：

ok 17 - wait_for_condition, try { selenium.isVisible('st-save-button-link') ? true : 
    false } catch(e) { false }, 55000
ok 18 - wait_for_condition, try { selenium.isElementPresent('st-edit-summary-text-area') 
    ? true : false } catch(e) { false }, 30000
ok 19 - click, st-edit-summary-text-area
ok 20 - type, st-edit-summary-text-area, A second summary for a wikitest
ok 21 - click, st-save-button-link
ok 22 - wait_for_condition, try { selenium.isVisible('st-edit-button-link') ? true : 
    false } catch(e) { false }, 60000
ok 23 - click, //a[@id='st-watchlist-indicator'], clicking watch button
ok 24 - wait_for_condition, try { selenium.isVisible('link=3 Revisions') ? true : 
    false } catch (e) { false }, 60000
ok 25 - click, link=3 Revisions
ok 26 - st-admin purge-page --workspace test-data --page edit_summaries_1234802223

这些测试用例是独立运行的，即使有一些预定义的测试数据，每个测试用例也能自主完成其测试任务。

测试结果处理与工具

当测试出现失败情况时，软件会给出相应提示，如 “It looks like you failed X of Y tests” 或 “Failed after X tests run”。为了更直观地查看测试结果，使用了 tap2html 工具，它可以将测试套件的结果进行汇总，让我们能一眼看出 10000 个测试步骤套件的成功与失败情况，并在需要时深入查看细节。

回归测试方法

进行回归测试时，需要运行测试套件，并将输出重定向到文件，然后在文件中搜索 “not ok”、“error”、“warning” 等信息。同时，还有一些脚本可以处理错误并告知哪些测试用例失败，以及一个可视化工具能将 ASCII 文本输出转换为浏览器中可查看的图形表示。

综合测试方法

目前采用了多种测试方法，包括验收测试、单元测试和维基测试。但维基测试存在一定局限性，无法发现所有的 bug。因此，每两周需要对所有功能进行回归测试，目标是在开始回归测试后的 48 小时内将代码迁移到内部预发布环境。

为了实现这一目标，创建了候选测试跟踪维基页面。通过该页面，可以分配测试人员对软件的不同部分进行测试，并报告已提交的 bug 报告。当页面上所有元素都显示 “ok” 时，该迭代的测试就完成了（“bz” 后面跟数字表示测试人员发现了 bug）。

以下是一个测试迭代结束于 2009 - 01 - 30 的候选页面测试情况示例：
| 浏览器 | 测试情况 | 详细问题 |
| ---- | ---- | ---- |
| FF2 | PASS | Widgets 测试在主版本中已修复，但在 01 - 30 版本中未修复 |
| FF3 | 进行中（Chris 认为已完成，PASS） | TC: Hidden Email Address for Public wiki 可能存在竞态条件 |
| IE7 | 大部分 PASS | 在 TC: Calc Watchlist 的第 5941 步数据库损坏，apache - perl 崩溃，无法重现；Stash 认为保存电子表格时可能存在竞态条件 |
| IE6 | PASS | TC: REST Workspace 重新运行通过；原始运行遇到单个 502 错误；TC: Hidden Email Address for Public wiki 手动运行通过，但可能因搜索结果的竞态条件失败；所有 Widgets 测试失败；所有 Reports 测试失败 |
| Safari | 部分失败 | test_case_revisions 中的 cheshire cast 按钮不起作用；test_case_preview 从简单文本模式切换到富文本模式在 Safari 中不可能；Widgets 测试失败，将手动测试 |

其他测试类型

Slideshow 测试 ：结合了维基测试和视觉检查，由产品质量经理 Ken Pier 发明。一次典型的 Slideshow 运行大约需要半小时，能捕捉到维基测试遗漏的视觉 bug。
HTTPS 测试 ：由于 Selenium 无法通过驱动浏览器访问 HTTPS 页面，所以有时需要手动运行 HTTPS 测试，以确保安全套接层正常工作。
软件升级测试 ：需要测试软件从一个版本到另一个版本的升级过程。由于提供托管版本和应用程序，且允许客户随时升级，所以有多种版本需要测试。为此，开发了工具和架构改进，使升级测试变得不那么痛苦。

新产品测试

对于 SocialCalc、People 和 Dashboard 等新产品，由于代码较新且图形复杂，用户界面不断发展，目前只是进行了一些在部分浏览器中有效的维基测试，并制定了文档化的测试计划。测试这些产品的步骤如下：
1. 运行维基测试。
2. 手动进行探索性测试。
3. 参考测试计划，检查遗漏的测试区域，并进行补充测试。

高效测试策略 - SLIME

SLIME（Security, Languages, RequIrements, Measurement, Existing）是一种用于对新应用程序或功能进行测试的顺序记忆法，其目的是减少需要重新测试的工作量。

Security（安全） ：测试新应用程序时，首先要考虑的是安全问题。因为安全问题深入应用程序的架构，如果安全方面发生变化，几乎需要重新测试所有内容。例如，更改数据库权限方案或应用程序与主机操作系统的交互方式，都需要重新测试与数据库或操作系统交互的所有功能。
- Cross - site scripting (XSS) ：检查应用程序中信任客户端的地方，输入应在存储或渲染之前进行验证，并尽可能进行编码。当需要存储实际的 HTML、JavaScript 或 CSS 时，使用白名单而不是黑名单。
- SQL injection ：避免使用原始用户输入直接访问数据库，可通过手动关联前端数据库交互与实际代码，或使用脚本提取所有数据库调用并进行检查。SQL 注入问题可通过参数化 SQL 和/或严格的转义来解决。
- Appropriate permissions ：确保特定权限类别的用户只能执行他们应该执行的操作。

以下是 SLIME 测试顺序的流程图：

graph LR
    A[Security] --> B[Languages]
    B --> C[RequIrements]
    C --> D[Measurement]
    D --> E[Existing]

通过合理运用这些测试方法和策略，可以在保证软件质量的同时，提高测试效率，减少测试团队的压力，为软件的顺利发布和使用提供有力保障。在实际测试过程中，还需要不断根据软件的特点和需求，灵活调整测试方案，以达到最佳的测试效果。

软件测试的高效之道与策略（续）

高效测试策略 - 脚本化测试

脚本化测试是提高测试效率的另一个重要方法。通过编写脚本，可以自动化执行一系列的测试步骤，减少人工操作的时间和错误。脚本可以根据不同的测试场景和需求进行定制，例如模拟用户的操作、验证数据的准确性等。

例如，在前面提到的测试用例中，我们可以将这些操作编写成一个脚本，让脚本自动执行这些点击、输入和等待的操作。这样，在每次进行回归测试时，只需要运行这个脚本，就可以快速完成测试，而不需要手动重复这些操作。

脚本化测试的优点不仅在于提高效率，还在于可以保证测试的一致性。由于脚本是按照预先定义的步骤执行的，所以每次测试的结果都是相同的，不会因为人为因素而产生差异。

高效测试策略 - 思维导图

思维导图是一种可视化的工具，可以帮助我们更好地组织和规划测试工作。通过绘制思维导图，可以将测试的各个方面，如测试用例、测试场景、测试方法等，以图形化的方式展示出来，使我们能够更清晰地看到测试的全貌。

在测试过程中，思维导图可以帮助我们发现潜在的测试点和漏洞。例如，在绘制测试用例的思维导图时，我们可以从不同的角度思考，如功能、性能、安全等，从而发现一些容易被忽略的测试点。

以下是一个简单的思维导图示例，展示了一个软件测试的主要方面：

graph TD
    A[软件测试] --> B[测试用例]
    A --> C[测试方法]
    A --> D[测试流程]
    B --> B1[功能测试用例]
    B --> B2[性能测试用例]
    B --> B3[安全测试用例]
    C --> C1[验收测试]
    C --> C2[单元测试]
    C --> C3[维基测试]
    D --> D1[测试计划]
    D --> D2[测试执行]
    D --> D3[测试报告]

测试架构与哲学思考

在软件测试中，我们面临着一个重要的问题：如何在有限的时间和资源下，尽可能全面地测试软件。这就需要我们思考“什么应该测试，什么可以不测试”，以及“哪些测试总是通过，只提供确认价值”等问题。

这些问题本质上是哲学问题，类似于“所有天鹅都是白色的”这一经典归纳问题。在测试中，我们不能仅仅依赖大量通过的测试来证明软件没有问题，而应该更加关注那些可能出现问题的边界情况和异常情况。

我们将各种测试方法和策略组合起来的过程，被称为“测试架构”。一个好的测试架构应该能够高效地发现软件中的问题，同时又不会过度消耗资源。这就需要我们从客户的角度出发，理解整个产品的需求和功能，将各个测试环节有机地结合起来。

内部预发布环境测试

当候选测试通过后，代码会被放入内部预发布环境。在这个环境中，我们使用自己的软件（如维基）来进行日常工作，包括创建项目计划、跟踪迭代、进行质量保证跟踪等。这样，预发布环境就成为了软件进入生产环境前的最后一个验证阶段。

在预发布环境中，员工可能会发现一些单元测试和功能测试未能发现的缺陷、可用性问题或性能问题。这些反馈对于进一步优化软件非常重要。

综合测试体系的挑战与应对

整个测试体系包括功能测试、维基测试、执行测试计划、探索性测试、收集预发布环境反馈、可用性测试、故事评审、beta 测试、日志记录与评估以及偶尔的性能研究等多个方面。如果试图全面且高质量地完成所有这些测试，测试团队的规模会急剧膨胀，导致公司难以承受，或者员工会很快疲惫不堪。

因此，我们需要权衡测试的范围和深度，思考“多少测试才足够”以及“可以放弃哪些测试”。我们的目标不是精确地了解软件的所有功能，而是能够快速评估软件是否符合预期用途。

以下是一些应对这些挑战的建议：
1. 合理分配资源 ：根据软件的重要性和风险程度，合理分配测试资源，优先测试关键功能和容易出现问题的部分。
2. 灵活调整测试策略 ：根据测试的进展和反馈，及时调整测试策略，如增加或减少某些测试的频率和深度。
3. 加强团队协作 ：测试团队、开发团队和其他相关部门之间要密切协作，及时沟通问题和解决方案。