软件中的破坏性测试是什么？
托马斯·汉密尔顿
什么是破坏性测试？
破坏性测试 破坏性测试是一种用于查找软件程序故障点的软件测试方法。该方法故意使应用程序出现故障，以便检查其健壮性并识别故障点。与验证应用程序预期功能的测试方法不同，破坏性测试会检查应用程序内部不可预测的用户行为。
破坏性测试并不需要了解原始要求。但是，了解一些原始要求确实有助于开发。ping 良好的测试策略。
下图生动地展现了这一理念——测试人员是在与产品对抗，而不是与产品合作。
为什么要进行破坏性试验？
- 了解软件在不当使用情况下可预测的行为很有帮助。
- 它有助于检查软件产品的稳健性。
- 它能发现普通用户永远不会触发，但在生产过程中后期才会出现的罕见缺陷。
破坏性测试与非破坏性测试
这两种方法是互补的，而不是竞争的。 非破坏性测试 ——也称为正向测试或正常路径测试——会正确地与软件交互，并且不会破坏构建版本。破坏性测试则恰恰相反：它会输入无效数据和错误的序列，直到出现问题为止。
| 方面 | 破坏性测试 | 非破坏性测试 |
| 意图 | 强制应用程序失败 | 确认应用程序按预期运行。 |
| 输入已使用 | 无效的、格式错误的、超出范围的、顺序错误的 | 有效数据在预期范围内 |
| 问题已解答 | 它在哪里以及如何断裂？ | 它能达到预期效果吗？ |
| 需求知识 | 可选 | Essential |
| 典型成本 | 更高层次——探索性和开放式 | 较低——脚本化且可重复 |
| 成果 | 故障点、范围限制、恢复行为 | 是否符合规范 |
破坏性试验中要检查哪些内容？
破坏性测试会考察行为边界的两端：
- 正确的软件行为
- 软件行为不当
- 使用不当
- 输入数据不正确
- 正确的输出数据
整个过程中必须满足两个条件：
- 该软件绝不会处理或接受无效的输入数据。
- 无论输入数据的有效性或正确性如何，软件都应该始终产生正确的输出数据。
如何进行破坏性测试？
破坏性测试涉及许多活动，例如设计一组测试脚本、执行这些脚本、提出错误、修复错误以及在迭代结束时向利益相关者提供通过或失败的指标。
运行它的方法有很多种。以下是一些示例。
- 故障点分析方法： 对系统进行全面演练，评估各个环节可能出现的问题。来自……的帮助 业务分析师 可以采用这种策略。
- 测试人员同行评审： 拿你的 测试用例 由对系统或功能不太熟悉的另一位测试人员进行分析或审核。
- 测试用例的业务审查： 最终用户或专家经常会想到测试人员忽略的有效场景，因为测试人员的注意力集中在已说明的需求上。
- 使用运行表进行探索性测试： 探索性测试 使用运行表记录测试内容，可以重复测试，并控制测试覆盖率。
- 使用其他信息来源： 请其他人对软件产品进行故障排查，并分析他们发现的问题。
破坏性测试示例
以银行应用程序的登录和个人资料页面为例。破坏性通行证可以通过以下情况实现：
- 将一个 5,000 个字符的字符串粘贴到限制为 50 个字符的字段中，并确认该字段拒绝该字符串而不是默默地截断它。
- 请将字母、符号和负值输入到数值金额字段中。
- 打破预期顺序——不完成上一步，直接打开付款确认页面。
- 快速连续多次按下提交键，查看是否创建了重复记录。
- 在事务处理过程中断开网络连接，并检查应用程序是否能完全恢复，还是会留下部分记录。
每个案例都有明确的预期结果：清晰的验证信息、无数据损坏、无未处理的异常。任何其他情况都属于故障点，应作为缺陷提交。
破坏性测试方法
在软件工程中，以下方法用于实现破坏性测试目标：
破坏性检测技术
以下技术可以稍作修改后使用：
当目标是提高鲁棒性时，值得添加的邻近技术包括： 负面测试, 压力测试, 恢复测试 和 模糊测试.
破坏性试验的优点和缺点
在将该技术纳入版本发布计划之前，有必要明确说明其中的权衡取舍。
优势
- Rev修复了规范驱动测试永远无法触及的故障点。
- 设定实际范围限制，因此可以在这些限制范围内放心地操作产品。
- 揭露产品发布很久之后才在生产过程中出现的罕见缺陷。
- 检查在滥用情况下的耐用性、可恢复性和错误处理能力。
缺点
- 由于其性质开放，因此无法保证或轻易衡量覆盖范围。
- 耗时，且依赖于测试人员的经验和创造力。
- 如果没有仔细记录所用步骤，研究结果可能难以复现。
- 控制不当的运行可能会破坏共享的测试数据，因此需要一个隔离的环境。
