25、软件测试与开发流程：从自动化测试到实际应用-优快云博客

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

软件测试与开发流程：从自动化测试到实际应用

在软件测试领域，自动化测试常常被误解为如同自动化制造一般，让计算机完全替代人类执行测试任务。然而，实际情况并非如此简单。

自动化测试的局限性

自动化测试看似能高效地执行预设的测试步骤，但它存在着明显的局限性。以一个简单的应用测试脚本为例：
1. 在第一个框中输入 4。
2. 在第二个框中输入 4。
3. 从操作下拉菜单中选择“乘法”选项。
4. 点击“提交”。
5. 期望答案框中显示“16”。

当我们让计算机执行这些步骤时，便称之为自动化测试。但每个这样记录的测试用例背后，都隐藏着一个潜在的期望：“并且没有其他异常发生”。若采用捕获整个屏幕并比较运行结果的方法来处理“没有其他异常”这一情况，一旦开发者移动了按钮、更改了屏幕分辨率或配色方案等，软件就会产生误报错误。

如今，更常见的做法是仅检查精确的断言，这就导致一些问题容易被忽略，例如：
- 图标背景颜色不透明。
- 提交后，操作下拉菜单恢复为默认的“加法”，显示为“4 + 4 = 16”。
- 输入第二个值后，取消按钮变为禁用状态。
- 答案框本应禁用（灰色显示）却可编辑。
- 操作耗时八秒才完成。
- 生成的新页面答案正确，但输入的第一个值被清零，显示为“0 + 4 = 8”。

一个有思考能力的人类测试人员能立刻注意到这些问题，而计算机却做不到。所以，“自动化测试”与人类进行测试有着本质的区别。此外，如果需求允许结果在十秒内得出，人类能察觉到简单乘法运算刚好在容忍范围内，并可能通过使用大数字或复杂操作来寻找其他错误，计算机则无法做到这一点。

不同类型的软件缺陷

这些不同类别的缺陷表明，应用程序可能以多种不同方式出现故障，测试策略需要通过多种方法来应对这些不同情况。

Socialtext 软件介绍

Socialtext 开发的软件允许人们进行交流而非单纯的交易，类似于 Facebook、博客或 Twitter，但应用于企业内部且具备安全性。其最初的产品是一个维基，它能创建一种企业内部网，任何人都可以随时使用简单的标记语言甚至类似 MS Word 的编辑器进行编辑。

Socialtext 的维基软件基于开源组件构建，采用 Linux（Ubuntu）操作系统、Apache 网络服务器、Postgres 数据库和 Perl 编程语言，本质上是一个 LAMP 堆栈。

Socialtext 的软件开发流程

Socialtext 遵循受极限编程启发的开发流程，其基本工作单元是“故事”，这是一种极其轻量级的需求文档。一个故事包含对某个功能的简要描述以及完成该故事所需满足的示例，这些示例被称为“验收测试”，并以通俗易懂的英语进行描述。

故事的目的是创建一个关于工作内容的共享心理模型，并提供一个单一的参考点和期望。每个故事都体现在 Socialtext 维基页面上，通过标记“需要审核”、“开发中”、“测试中”或“等待签字”来创建一个非正式的工作流程，以表明工作进度。

由于需求会随时间变化，并不期望故事是完整的。相反，会尽量使故事足够好，让开发人员能够开始工作，并在故事审核过程达到收益递减点时，宣布故事“足够好”。同时，也不期望故事完全正确，但有一个审核过程来改进它们。由于英语本身是一种模糊的语言，也不期望故事毫无歧义，但具体的示例肯定会有所帮助。

一个故事描述一个完整的功能，但该功能本身可能不具有市场价值或可销售性。因此，会在一个迭代中收集一系列故事，并将迭代时间限制为两周。不过，在圣诞节假期前后允许进行为期三周的迭代。

理想情况下，开发人员会在迭代第二周的周三完成故事并达到“代码关闭”状态。回归测试大约需要两天时间，然后在周一，所有人开始下一个迭代。但实际情况中，前一个迭代的回归测试常常会延续到下一个迭代。

以 Edit Summaries 功能为例的开发与测试流程

下面以 Edit Summaries 功能为例，详细介绍 Socialtext 的开发与测试流程。

需求提出与故事创建

产品经理注意到客户大量使用“最近更改”功能，但希望了解更改是重要的（如“Matt 修改了休假政策”）还是微小的（如“Matt 对合同政策进行了拼写和语法修改”）。Edit Summaries 功能可以让用户创建一个摘要，在查看修订历史（有什么新内容）或用户的操作流时显示。产品管理部门认为这是一个关键功能，为了向 Acme 公司销售产品，必须具备该功能，于是起草了一个故事。

故事最初由客户（可能是产品经理）发起，并对功能进行描述。此时，故事只是一段文本，尚未分配人员。产品经理、开发人员、架构师/教练，偶尔还有测试人员会开会讨论故事的整体规模、实现细节和故事测试。评估以点数记录，点数代表开发人员实现该功能理想情况下所需的工程半天数。由于配对编程、假期、中断等因素，理想情况很少能实现，因此会跟踪实际完成的点数，并以此预测未来的性能，这被称为“迭代速度”。

在这个过程中，产品管理团队可能会创建原型。例如，Edit Summary 对话框应该类似于特定的设计。

验收测试制定

故事包括标题、纯文本描述、一些示例屏幕截图和验收测试。在故事的初始阶段，产品所有者会真诚地首次尝试创建验收测试，在开发人员编写任何代码之前，这些测试会由开发人员和测试人员进行补充。故事创建和审核过程的目标不是创建一个详尽的列表，而是让团队真正理解问题领域，以便在后续发现问题时，整个团队能够一致认为“是的，这是一个 bug”，并作为一个整体团队致力于修复它，而不是抱怨有人改变了主意或需求不正确。

实际的软件有 35 个测试，包括本地化要求、供程序员在不使用网页浏览器的情况下编写编辑摘要的 API 要求，以及创建一定程度的测试自动化要求，这些要求会纳入故事评估。

开发过程

开发人员 Orlando 与 Stash（Jeremy Stashewsky）通过电话协作，共享编辑器屏幕，以结对编程的方式创建故事。他们使用 Perl 编写后端代码，并在过程中采用测试驱动开发（TDD）风格编写单元测试，以辅助设计和测试。

以下是 Orlando 在 TDD 过程中的部分代码示例：

# initialize some globals we'll use
setup_tests();
signal_edit_summary: {
     my $hub = setup_page(
         revision_id  => $save_revision_id,
         edit_summary => 'Dancing is forbidden!',
         signal_edit_summary => 1,
     );
     $hub->edit->edit_content;
     my $page = load_page_by_id(hub => $hub, page_id => $page_id);
     is $page->edit_summary, 'Dancing is forbidden!', 'proxy method works';
     # check that the signal was created
     signal_ok (
         viewer => $user,
         signaler => $user,
         body => "Dancing is forbidden!" (edited Save Page in Admin Wiki)',
         topic => {
             page_id => $page_id,
             workspace_id => $current_workspace->workspace_id,
         },
         msg => 'normal length edit summary with signal'
     );
     # check that the appropriate events were created
     is_event_count(2);
     event_ok (
         event_class => 'signal',
         action => 'page_edit',
     );
     event_ok (
         event_class => 'page',
         action => 'edit_save',
     );
}

当 Orlando 完成工作后，他会删除页面标签“开发中”，并添加“测试中”标签。下次开发人员查看跟踪该迭代工作的页面时，故事就会自动进入测试队列，由测试负责人接手。

测试过程

测试负责人会检出最新版本的代码，并在所有支持的浏览器（Internet Explorer、Firefox 和 Safari 的最新版本和上一版本）中快速执行故事测试。同时，还会尝试使用奇怪的字符组合、特殊字符以及无空格的纯文本。

在故事测试之后，会对故事及相关更改进行探索性测试。例如，在 Internet Explorer 中发现编辑框位置错误（在最右侧），测试负责人会将故事标记为“开发中”，并通过电子邮件通知开发人员。开发人员修复问题后，再次标记为“测试中”，测试负责人重新测试，若通过则将故事移至客户验收阶段。

偶尔，问题较为严重、难以修复，但对故事的成功并非至关重要。在这种情况下，测试人员会创建一个 Bugzilla（缺陷跟踪）工单，并将其作为注释添加到故事中。产品经理可以查看该缺陷，决定是否可以带着该缺陷发布产品。例如，在测试中发现可以输入 250 个无空格的字符，导致修订历史页面出现严重的滚动条和边距问题。经过快速讨论，决定：
- 使用英语词典中最大的单词时不会出现此问题。
- 该问题可能需要修复，但不一定是现在。
- 创建一个缺陷报告。

由于每两周会将软件发布到软件即服务（SaaS）生产服务器，其他地方的微小更改很容易产生连锁反应。如果每两周对每个浏览器的每个验收测试都进行重新测试，测试负担最终会使团队不堪重负。因此，使用了一个名为 wikitests 的框架进行部分测试自动化。

wikitests 测试框架

wikitests 是一种基于关键字驱动的测试框架，用于驱动浏览器。每个测试用例以表格形式表示为一系列命令，每行一个命令。这些命令采用 Selenese 语言，接近英语，具有一定编程基础的人都能读懂。由于这些命令存储在维基页面上，任何人都可以查看、修改和保存。此外，还可以构建自己的命令，如“st-login”，用于组合常见操作。

以下是 Edit Summaries 测试的一个缩写版本：

Comment
Test Case: Edit Summaries

Comment
Test Case: Edit Summaries—create a page from file

st-admin
updatepage workspace %%workspace%% email 
%%email%% page "Edit Summaries %%start_time%%" 
< %%wikitest_client_files%%wikitest_toc.txt
The “Edit
Summaries %
%start_time%
%” page has
been created

Comment
Test Case: Edit Summaries—create one Edit Summary

open_ok
/%%workspace%%/index.cgi?Edit Summaries 
%%start_time%%

wait_for_element_visible_ok
steditbuttonlink
30000
click_ok
steditbuttonlink
wait_for_element_visible_ok
link=Wiki Text
30000
click_ok
link=Wiki Text

wait_for_element_visible_ok
wikiwyg_wikitext_textarea
30000
wait_for_element_visible_ok
stsavebuttonlink
30000

Comment
Test Case: Edit Summaries—type the summary

wait_for_element_present_ok
steditsummarytextarea
30000
click_ok
steditsummarytextarea
type_ok
steditsummarytextarea
Quick
Summary for
my friends %
%start_time%
%
click_and_wait
stsavebuttonlink

Comment
Test Case: Edit Summaries—create a second Edit Summary

open_ok
/%%workspace%%/index.cgi?Edit Summaries 
%%start_time%%
wait_for_element_visible_ok
steditbuttonlink
30000
click_ok
steditbuttonlink
wait_for_element_visible_ok
stsavebuttonlink
30000
wait_for_element_visible_ok
link=Wiki Text
30000
click_ok
link=Wiki Text
wait_for_element_visible_ok
wikiwyg_wikitext_textarea
30000

Comment
Test Case: Edit Summaries—type the second summary

wait_for_element_present_ok
steditsummarytextarea
30000
click_ok
steditsummarytextarea
type_ok
steditsummarytextarea
A second
summary for a
wikitest %
%start_time%
%
click_and_wait
stsavebuttonlink
wait_for_element_visible_ok
steditbuttonlink
30000

Comment
Test Case: Edit Summaries—revision history

click_and_wait
link=3 Revisions
wait_for_element_visible_ok
link=Back To Current Revision
30000
text_like
qr/A second summary for a wikitest 
%%start_time%%.+Quick Summary for 
my friends %%start_time%%/

Comment
Test Case: Edit Summaries—teardown

st-admin
purgepage workspace %%workspace%% 
page edit_summaries_%%start_time%%
page was
purged

Comment
Test case: Edit Summaries COMPLETED

这种测试方式要求所有 HTML 元素都有一个 ID 名称，软件会四处点击链接并查看值。为了找到元素的名称，需要使用工具（如 Firefox 的 Firebug 和 Web Developer 插件，IE 的开发者工具栏）“检查”用户界面，或者在代码编写之前与开发人员合作确定名称。

整个过程是创建一个测试用例（即一个维基页面），运行测试，观察其失败情况，进行修改后再次尝试。在这个例子中，可以看到多次停滞和重试，可能是放弃一种测试策略而转向另一种，或者查看代码进行调试。通常，为一个功能编写自动化测试需要半天时间，而手动在所有浏览器中测试该功能只需一小时。

wikitests 的输出示例如下：

# st-login: wikitester@ken.socialtext.net, d3vnu11l, test-data -
/nlw/login.html?redirect_to=%2Ftest-data%2Findex.cgi
ok 1 - open, /nlw/login.html?redirect_to=%2Ftest-data%2Findex.cgi
ok 2 - type, username, wikitester@ken.socialtext.net
ok 3 - type, password, d3vnu11l
ok 4 - click, id=login_btn, log in
ok 5 - wait_for_page_to_load, 60000
# 
# comment: Test Case: Edit Summaries
# Set 'pt' to '5000'
# 
# comment: Test Case: Edit Summaries - create a page from file, because we can't type 
# newlines with type_ok st-admin update-page --workspace test-data --email 
# wikitester@ken.socialtext.net --page "Edit Summaries 1234802223" 
# < /opt/wikitest_files/wikitest_toc.txt
ok 6 - st-admin update-page --workspace test-data --email wikitester@ken.socialtext.net 
    --page "Edit Summaries 1234802223" </opt/wikitest_files/wikitest_toc.txt
ok 7 - open, /test-data/index.cgi?Edit Summaries 1234802223
ok 8 - click, st-edit-button-link
ok 9 - wait_for_condition, try { selenium.isTextPresent('Editing: Edit Summaries 
    1234802223') ? true : false } catch(e) { false }, 55000
ok 10 - wait_for_condition, try { selenium.isVisible('st-save-button-link') ? true : 
    false } catch(e) { false }, 30000
ok 11 - wait_for_condition, try { selenium.isElementPresent('st-edit-summary-text-area') 
    ? true : false } catch(e) { false }, 5000
ok 12 - click, st-edit-summary-text-area
ok 13 - type, st-edit-summary-text-area, Quick Summary for my friends
ok 14 - click, st-save-button-link
ok 15 - wait_for_condition, try { selenium.isElementPresent('st-edit-button-link') ? 
    true : false } catch(e) { false }, 30000
ok 16 - click, st-edit-button-link

wikitests 虽然不能判断编辑摘要对话框是否过宽、突然下移或颜色错误等问题，但能在短时间内提供一定的基本健全性覆盖，有助于实现快速迭代。

综上所述，软件测试与开发是一个复杂的过程，需要综合运用自动化测试和人工测试，结合不同的技术策略和工具框架，以确保软件的质量和稳定性。在 Socialtext 的实践中，通过合理的流程和方法，有效地管理了软件开发和测试工作，尽管面临诸多挑战，但仍能不断改进和优化。

软件测试与开发流程：从自动化测试到实际应用

wikitests 框架的特点与挑战

wikitests 框架有其显著的特点和优势，同时也面临一些挑战。

特点

易读性与可维护性 ：采用接近英语的 Selenese 语言，存储在维基页面上，使得具有一定编程基础的人员都能读懂、查看、修改和保存测试用例，方便团队协作。
自定义命令 ：可以构建自己的命令，如“st - login”，将常见操作组合，提高测试效率。
基本覆盖 ：能在短时间内提供一定的基本健全性覆盖，满足快速迭代的需求。

挑战

元素识别依赖 ：要求所有 HTML 元素都有 ID 名称，需要借助工具“检查”用户界面或与开发人员合作确定名称，增加了前期准备工作。
智能性不足 ：无法判断编辑摘要对话框是否过宽、突然下移或颜色错误等问题，缺乏对界面细节的智能判断能力。
编写成本 ：为一个功能编写自动化测试的时间（约半天）远长于手动测试时间（约一小时）。

不同测试方法的对比与选择

在软件测试中，自动化测试和人工测试各有优劣，需要根据实际情况进行选择。

测试方法	优点	缺点	适用场景
自动化测试（如 wikitests）	可重复执行、效率高、能覆盖大量基础测试用例	缺乏智能判断、前期编写成本高、对环境变化敏感	频繁执行的基础测试、回归测试
人工测试	能发现界面细节问题、具有思考和探索能力	效率低、容易疲劳、难以覆盖大量测试用例	探索性测试、界面设计验证、复杂场景测试

软件开发与测试流程总结

下面是 Socialtext 软件开发与测试的整体流程 mermaid 流程图：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px

    A([需求提出]):::startend --> B(故事创建):::process
    B --> C(验收测试制定):::process
    C --> D(开发过程):::process
    D --> E(测试过程):::process
    E --> F{是否通过测试}:::process
    F -->|是| G(客户验收):::process
    F -->|否| H(问题修复):::process
    H --> D(开发过程):::process
    G --> I([发布到生产服务器]):::startend
    E -.-> J(创建 Bug 报告):::process
    J --> K(产品经理评估):::process
    K -->|可发布| I([发布到生产服务器]):::startend
    K -->|需修复| H(问题修复):::process