“随机”方式—考虑了吗？
　　通常，任何软件模块或系统都有输入域，从这个域里选择并使用测试输入数据建和/或执行测试用例。
　　现在，如果一个测试人员从必要输入域中随机选择输入，准备测试用例，并用它们来测试应用程序，这种方法被称为“随机测试”。
　　例如，如果一个模块的有效输入域是1到100之间所有的正整数，然后用这种方法测试人员会随机或胡乱地从该领域内选择值，如，选15 ， 27和33。
　　但是，使用这种方法，也有一些一直无解的问题：
　　值（上面的例子中三个值）足以表明，执行测试用或运行例测试时，模块符合其规格吗？
　　是否有其他输入值，比那些（在本例中）被选中的值，更能找缺陷？
　　抑或有效输入域外的任何值应该作为执行测试用例的测试输入？
　　这是说，测试数据应包括大于100的浮点值，负值或整数值？
　　因此，上述问题可以立即通过更加结构化的黑盒测试设计方法解决，尽管使用随机测试输入可以节省一些时间和精力，其他测试输入选择方法要求。
　　但是，根据许多测试专家，随机选择测试输入会产生一个有效的用于执行测试用例的测试数据集的机会非常小，并且对于一个更结构化的方法，随机方法生成测试输入的相对有效性总成为自省和/或研究的课题。
　　测试用例必不可少的部分—概念化
　　首先，设计一个测试用例用来回答这个问题：“我要测试什么？ ” 。因此，对于测试人员来说，开发测试用例时周到地考虑很重要，这能够明确界定和/或提供需被验证以确保系统如期运行且能反映出它是用高质量创建的信心的项目（模块，应用程序，子系统，或SUT ）的完整概述。
　　现在，无论开发测试用例时用了什么设计技术/战略，测试人员都必须确保基本涵盖以下主要内容：
　　摘要 -应该反映实际的主题，类别和功能特性，使测试人员可以轻易地组织测试用例成逻辑组，并相应地对它们进行分类。
　　这部分可能具有关于基于测试时间，工作单元，和优先级等的执行工作的细节。它经常被称为测试用例的权重。
　　测试用例设计 - 这部分反映了测试用例的整体设计，其中可能包括一些高层次的描述。
　　正式审查 - 包含了关于必须审查或批准测试用例、并定义审批流程的团队清单的详情。
　　这部分主要是用来建立一个正式的审查程序，以确保业务流程符合标准。
　　此外，它可能包括关于测试用例所有人，工作项目，通知和成果总结等的细节
　　要求 - 本部分旨在：当要求被添加到测试计划中时，联系要求与一个特定的测试用例。
　　因此，一旦需求和测试用例间的联系被建立，测试人员可以继续创建覆盖报告来了解和确定被测试用例覆盖的要求的比例有多大。重要的是，通过保持这种关联，有助于设置和检查整个项目的可追溯性。
　　先决条件 - 描述了形成前提的或必须在测试人员可以真正开始运行/执行测试用例之前发生的事物。
　　后置条件 - 不像先决条件，后置条件说明了需在测试用例运行/执行完成之后发生的事物。通常是产生适当的确认，如发送电子邮件通知等。
　　预期结果 - 本部分详细介绍了必须在测试员认为测试运行已取得成功前获得的结果列表。它可能包含了结果代码的文件或图像。
　　测试脚本 - 本部分概述了与特定的测试用例相关的测试脚本。通常，测试脚本有几种类型，包括手动测试脚本，关键字启用测试脚本，及其中每个测试脚本都包含用来实现一个测试用例的指示的自动化功能测试脚本。
　　在执行过程中，不像使用工具自动运行的自动化测试脚本，手工测试脚本是用语句处理语句。
　　测试执行记录 - 通常测试执行记录包含测试用例的详细信息，及从测试用例执行产生的高层次结果的细节。
　　重要的是，它们提供测试执行所需的相关硬件和软件环境的细节。例如，如果当运行在两个不同的操作系统和两个不同的硬件平台上，且使用了不同的浏览器的测试用例通过了，那么测试员可以为这些组合中的每一个创建测试执行记录。
　　测试执行记录还包含与该测试用例运行，测试运行的详细记录，以及所有执行结果的详细历史相关的的整体结果。
　　附件 – 本部分通常包含了支持测试用例的所有文档和文件。
　　风险评估表 - 本部分意在列出与某个特定的测试用例相关的风险。
　　所以，当上述所有部分都与测试用例相关，且如果这样的测试例被执行，那么是一个好的迹象：关于实现完整的测试覆盖率，效率等方面的标准已达到。