测试用例包括：1、测试用例标识；2、测试说明；3、前提条件；4、测试数据；5、要执行的步骤；6、预期成果；7、后置条件；8、后置条件；9、实际结果；10、通过/失败。测试用例标识是指为每个测试用例创建一个唯一的 ID。
一、测试用例怎么写
1、测试用例标识
应为每个测试用例创建一个唯一的 ID。这些 ID 应遵循数字或字母模式，以减少在识别个案时的混淆。
2、测试说明
测试说明概述了正在测试的内容以及如何验证。测试描述的常见句子结构：“用’另一个动作’通过’动作’来验证’功能’。”比如，在Gmail中使用正确的密码来验证身份验证。
3、前提条件
前提条件（或先决条件）是在测试开始之前需要满足的条件。如果没有这些，测试覆盖率将无效。
4、测试数据
测试数据是执行测试所需的任何输入或数据。这些可能包括登录名和密码、测试脚本或确切的 URL。
5、要执行的步骤
需要从最终用户的角度遵循这些步骤来验证最终目标。它们必须写得清楚简洁，以便测试团队理解。使用可追溯性矩阵可以确保测试每个条件和功能。
6、预期成果
预期的结果是，如果遵循测试用例中的所有步骤，则无错误网站应该发生什么。
7、后置条件
后置条件是作为成功测试结果的结果而应该发生的事情。例如，如果在登录页面中输入用户名和密码的预期结果是获得主页的准入，则后置条件是加载主页。
8、实际结果
测试用例是否产生了预期的结果？如果没有，结果如何？这是实际结果，可能与预期结果不同，也可能没有差异。
9、通过/失败
如果达到预期结果，则测试通过。如果没有，它就失败了。如果测试失败怎么办？是时候报告错误了！需要遵循和纠正错误生命周期。然后必须进行回归测试。
二、编写测试用例的注意事项
1、根据风险和优先级考虑测试用例
根据项目时间线和应用程序的风险因素确定要编写的测试用例的优先级。计划在 6 周内交付的高风险功能的优先级可能高于将于下周发布的低风险功能的测试。大多数情况下，因为在项目的后期，您可能没有时间为高风险功能编写测试。没有给定的测试用例公式，您需要反复求解此等式。
2、记住 80/20 规则
20% 的测试将覆盖 80% 的应用程序，知识测试的一条实用原则。即使编写一个简短的场景也可以发现大部分错误。这就是为什么最好从端到端的健全性套件开始，然后才开始更深入地介绍特定功能。此外，在涵盖特定功能时，最好在深入之前进行端到端的简短测试。
3、确保在必要时其他人可以完成您的测试用例
在选择要编写的测试时，请关注如何“外包”它们。例如，编写测试，您可以提供给开发人员运行，而您正忙于测试那些无法提供给其他任何人的高风险任务。在某些情况下，不可能编写适合所有受众的单个测试，您可以考虑编写单个测试的2个独立版本。
4、“足够好”的测试用例
编写测试从来都不是一蹴而就的，很多时候最好写出目前“足够好”的测试用例。如果可能，请务必在将来修改它们。这种敏捷/迭代重构方法适用于测试用例编写，而不仅仅是开发任务。
5、创建测试用例，就像您正在跑马拉松而不是短跑一样
创建与未来的冲刺/构建/发布相关的测试;如果你把它们做得太具体，它们的相关性只会持续到项目的这个阶段。
6、在编写测试之前列出测试
根据风险创建主题及其优先级列表。这将有助于专注于您需要或想要测试的内容。即使列表不是最终列表，您也可以稍后分解测试或合并它们。
7、根据业务场景和功能对测试用例进行分类
这将允许您从不同的角度查看系统。这个过程背后的逻辑是知道要编写什么测试以及何时编写它。差异化还有助于在测试存储库中组织测试，因此您和您的团队可以根据将来测试计划的需要选择可以运行的测试。
8、不要太长或太短
测试服的定义应使其需要 45 到 90 分钟才能运行，同时仍然“一举”覆盖系统的重要区域。
9、试用测试
你最初编写的测试可能会在你完善它们时运行一两次。因此，在将它们发送给其他人或发布给客户之前，请确保您参加测试以进行试用。
10、定期运行测试以保持其相关性
您将需要根据约束（例如应用程序更改、环境修改和许多其他原因）不断对测试用例进行小的更改。进行小的更改既快速又简单，并且比进行全面检修并从头开始编写新的测试要好。
延伸阅读
测试用例的概念
测试用例(Test Case)是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，最终形成文档。简单地认为，测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。
文章标题：测试用例该怎么写，发布者：Z, ZLW，转载请注明出处：https://worktile.com/kb/p/48353
微信扫一扫 
支付宝扫一扫 
