计算机软件测试方法与用例设计手册

计算机软件测试方法与用例设计手册1.第1章测试概述与基础概念1.1测试生命周期与阶段1.2测试类型与目的1.3测试用例设计原则1.4测试工具与环境2.第2章需求分析与测试策略2.1需求文档与测试需求提取2.2测试策略制定与规划2.3风险评估与测试计划2.4测试环境与资源准备3.第3章测试用例设计方法3.1用例设计原则与步骤3.2用例设计方法与技巧3.3用例分类与结构设计3.4用例编写规范与评审4.第4章功能测试方法与用例4.1功能测试概述与目标4.2功能测试用例设计4.3功能测试用例分类与优先级4.4功能测试用例评审与验证5.第5章非功能测试方法与用例5.1非功能测试概述与目标5.2性能测试用例设计5.3安全性测试用例设计5.4可用性测试用例设计6.第6章软件测试流程与实施6.1测试流程与阶段划分6.2测试执行与执行记录6.3测试报告与缺陷跟踪6.4测试总结与复盘7.第7章测试用例维护与更新7.1测试用例版本管理与更新7.2测试用例复用与共享7.3测试用例失效与失效分析7.4测试用例的持续优化与改进8.第8章测试文档与规范8.1测试文档编写规范8.2测试用例文档结构与格式8.3测试报告编写规范8.4测试管理与质量保证第1章测试概述与基础概念1.1测试生命周期与阶段测试生命周期是指软件开发过程中从需求分析到维护的整个过程，通常包括需求分析、设计、开发、测试、维护等阶段。根据ISO/IEC25010标准，测试是软件质量保证的重要组成部分，贯穿于软件开发生命周期的各个阶段。在软件开发中，测试通常分为单元测试、集成测试、系统测试和验收测试四个主要阶段。单元测试关注代码的独立性，集成测试则关注模块之间的接口，系统测试验证整个系统的功能与性能，而验收测试则由用户或客户进行最终确认。依据IEEE829标准，测试阶段应明确测试目标、测试环境、测试用例和测试结果记录等要素，确保测试过程的可追溯性与可重复性。在实际项目中，测试阶段往往与开发阶段紧密衔接，采用迭代式测试方法，如敏捷测试中的测试驱动开发（TDD）和持续集成（CI）策略，以提高测试效率与质量。一项研究表明，合理的测试生命周期规划能有效降低软件缺陷率，提升产品交付质量，减少后期维护成本，符合软件工程中的质量控制原则。1.2测试类型与目的测试类型主要包括黑盒测试、白盒测试、灰盒测试和探索性测试。黑盒测试关注软件的功能与输入输出，白盒测试则侧重于代码逻辑与内部结构，灰盒测试介于两者之间，而探索性测试则用于发现未预见的问题。根据ISO/IEC25010，测试目的包括验证软件功能是否符合需求、评估软件性能是否满足要求、确保系统安全性以及发现潜在缺陷。在软件开发中，测试目的不仅是保证软件质量，还涉及风险控制、用户满意度提升以及符合行业标准与法规要求。例如，在金融系统中，测试目的还包括确保交易处理的准确性和安全性，避免因系统错误导致的经济损失。一项调查表明，有效的测试能显著提高软件的可靠性，降低后期修复成本，是软件项目成功的关键因素之一。1.3测试用例设计原则测试用例设计应遵循覆盖性、可执行性、可追溯性、简洁性与可重复性等原则。根据IEEE829标准，测试用例应明确输入、输出、预期结果及测试步骤。为了确保测试的有效性，测试用例应覆盖所有关键路径与边界条件，例如边界值分析、等价类划分等方法，以发现潜在的错误。测试用例的设计需结合测试阶段的特性，如单元测试注重代码逻辑，系统测试注重整体功能，而验收测试则关注用户使用体验。在实际操作中，测试用例通常由测试人员与开发人员协同设计，确保测试覆盖全面且不重复，符合软件工程中的测试驱动开发（TDD）理念。一份高质量的测试用例应具备可执行性，能够通过自动化测试工具实现，同时具备可追溯性，便于缺陷跟踪与分析。1.4测试工具与环境测试工具包括自动化测试工具、性能测试工具、安全测试工具等，如JUnit（Java）、Selenium（Web）、Postman（API）、JMeter（性能测试）等。自动化测试工具能够提高测试效率，减少人工测试的错误率，适用于回归测试与持续集成场景。测试环境应包括开发环境、测试环境、生产环境，各环境应保持隔离，确保测试结果的独立性与可靠性。根据ISO/IEC25010，测试环境应满足特定的硬件、软件与网络要求，以确保测试的准确性与稳定性。例如，在测试Web应用时，测试环境应配置与生产环境一致的浏览器、操作系统与数据库，以确保测试结果的可比性。第2章需求分析与测试策略2.1需求文档与测试需求提取需求文档是软件测试的基础，通常包括功能性需求、非功能性需求、接口需求等，其完整性直接影响测试的覆盖范围与有效性。根据IEEE830标准，需求文档应包含明确的用户需求、系统功能描述、输入输出规范等，确保测试人员能够准确理解系统行为。在测试需求提取过程中，应结合用户故事、用例设计、测试用例模板等工具进行需求分析，确保测试用例覆盖所有功能需求与边界条件。例如，根据ISO25010标准，测试需求应与系统需求保持一致，并通过测试用例的覆盖率分析验证需求的完整性。采用结构化需求分析方法，如使用需求优先级矩阵（PRM）对需求进行分类，区分核心需求、次要需求与可选需求，有助于制定合理的测试策略。研究表明，采用PRM方法可提高测试用例的针对性与效率。需求文档应包含测试边界条件、异常处理、性能要求等关键信息，测试人员需根据这些内容设计测试用例，确保系统在各种场景下的稳定性与可靠性。例如，根据IEEE12207标准，测试需求应与系统需求保持一致，并通过测试用例的覆盖率分析验证需求的完整性。在需求提取过程中，应与开发团队、用户代表进行充分沟通，确保需求理解一致，避免因需求不明确导致测试遗漏或误判。根据ISO9001标准，测试需求应与开发需求形成闭环管理，确保测试与开发的协同一致。2.2测试策略制定与规划测试策略是指导测试工作的总体框架，包括测试类型（如单元测试、集成测试、系统测试、验收测试）、测试方法（如黑盒测试、白盒测试、灰盒测试）及测试工具的选择。根据IEEE12207标准，测试策略应与系统开发阶段同步制定，确保测试覆盖全面。测试策略应结合项目规模、复杂度、时间安排等因素，合理分配测试资源与时间，避免测试遗漏或过度测试。例如，根据敏捷测试实践，测试策略应与迭代周期同步，确保每个迭代周期内有相应的测试覆盖。测试规划应包含测试目标、测试范围、测试资源、测试工具、测试时间表等要素，确保测试工作的有序进行。根据ISO25010标准，测试规划应与项目计划一致，并通过测试计划评审确保可行性与可操作性。测试策略应考虑测试的可执行性与可追溯性，确保每个测试用例都有明确的测试目标和预期结果。根据CMMI标准，测试策略应包含测试用例的可追溯性矩阵，确保测试结果可追溯至需求和设计。测试策略应结合测试用例设计方法，如等价类划分、边界值分析、因果图分析等，确保测试覆盖所有可能的输入条件与输出结果。根据IEEE12207标准，测试策略应与系统需求分析同步进行，确保测试用例的科学性与有效性。2.3风险评估与测试计划风险评估是测试计划的重要组成部分，包括技术风险、业务风险、环境风险等，应通过风险矩阵（RiskMatrix）进行量化评估。根据ISO25010标准，风险评估应与系统需求分析同步进行，确保测试计划具备风险应对能力。在测试计划中，应明确测试的优先级、资源分配、时间安排及风险应对措施。根据CMMI标准，测试计划应包含风险识别、风险分析、风险应对和风险监控等要素，确保测试工作的可控性与可预测性。测试计划应包含测试环境、测试工具、测试数据、测试人员配置等要素，确保测试工作的顺利开展。根据ISO25010标准，测试计划应与系统开发计划一致，并通过测试计划评审确保可行性与可操作性。测试计划应包含测试用例的编写、执行、评审与更新流程，确保测试工作的持续改进。根据IEEE12207标准，测试计划应包含测试用例的编写、执行、评审与更新流程，确保测试用例的科学性与有效性。测试计划应结合测试策略与测试策略制定的成果，确保测试工作的系统性与连贯性。根据ISO25010标准，测试计划应与系统开发计划同步制定，并通过测试计划评审确保可行性与可操作性。2.4测试环境与资源准备测试环境应与生产环境一致，包括硬件配置、软件版本、网络环境、数据环境等，确保测试结果的可比性。根据ISO25010标准，测试环境应与生产环境一致，并通过环境一致性检查确保测试结果的可靠性。测试资源包括测试人员、测试工具、测试数据、测试用例等，应根据测试计划合理分配，确保测试工作的高效开展。根据CMMI标准，测试资源应与测试计划一致，并通过资源分配评审确保测试工作的可行性与可操作性。测试工具的选择应根据测试类型（如单元测试、集成测试、系统测试）进行匹配，确保测试效率与质量。根据IEEE12207标准，测试工具应与测试策略一致，并通过工具选型评审确保测试工具的适用性与可操作性。测试数据应包括正常数据、边界数据、异常数据等，应根据测试用例设计进行准备，确保测试的全面性与有效性。根据ISO25010标准，测试数据应与测试用例设计一致，并通过数据准备评审确保测试数据的完整性与有效性。测试环境与资源准备应包括测试环境搭建、测试数据准备、测试工具配置、测试人员培训等，确保测试工作的顺利开展。根据ISO25010标准，测试环境与资源准备应与测试计划一致，并通过环境与资源准备评审确保测试工作的可行性与可操作性。第3章测试用例设计方法3.1用例设计原则与步骤用例设计应遵循覆盖性原则，确保所有功能需求和非功能需求都被充分覆盖，避免遗漏关键路径或边界条件。根据IEEE830标准，测试用例应包含输入、输出、预期结果及状态描述，确保测试的完整性与可追溯性。用例设计需遵循可重复性原则，测试用例应具备可复用性，便于在不同测试环境中重复使用，减少重复劳动，提高测试效率。根据ISO25010标准，测试用例应具备明确的输入、输出和预期结果，便于后续的测试执行与结果分析。用例设计应遵循可维护性原则，测试用例应具备良好的结构化设计，便于后期维护和更新。根据CMMI（能力成熟度模型集成）标准，测试用例应采用模块化设计，便于根据需求变更进行调整。用例设计需遵循可追溯性原则，测试用例应与需求文档、设计文档和测试计划保持一致，确保测试结果可追溯到需求来源。根据ISO25010标准，测试用例应包含需求编号、测试步骤、预期结果等信息，实现测试与需求的双向追溯。用例设计应遵循可执行性原则，测试用例应具备可执行性，确保测试人员能够按照用例执行测试，并产生可验证的结果。根据IEEE830标准，测试用例应包含明确的测试步骤、输入、输出及预期结果，确保测试过程的可操作性。3.2用例设计方法与技巧常用的测试用例设计方法包括等价类划分、边界值分析、决策表法、场景法和因果图法等。这些方法能够有效覆盖功能需求，减少测试用例数量，提高测试效率。根据《软件测试技术》（王珊等，2007）一书，等价类划分是常用的基础方法，适用于输入条件较多的情况。边界值分析是一种针对边界条件的测试方法，适用于输入范围的边界值。例如，对于一个输入范围为1-100的数值，应测试1、100、101、1000等边界值。根据《软件测试技术》（王珊等，2007）一书，边界值分析能够发现许多潜在的错误，特别是边界条件下的异常情况。场景法是通过构建测试场景来覆盖复杂业务流程，适用于涉及多个步骤或条件的系统。根据《软件测试技术》（王珊等，2007）一书，场景法能够帮助测试人员全面覆盖业务流程中的各种可能情况，提高测试的全面性。因果图法（也称逻辑覆盖法）用于分析输入条件之间的因果关系，确定测试用例。根据《软件测试技术》（王珊等，2007）一书，因果图法能够帮助测试人员识别输入条件之间的逻辑关系，从而设计出更有效的测试用例。决策表法是一种将复杂逻辑关系转化为表格的形式，便于测试用例设计和结果分析的方法。根据《软件测试技术》（王珊等，2007）一书，决策表法能够系统化地表示输入条件与输出结果之间的关系，提高测试的系统性和可操作性。3.3用例分类与结构设计测试用例通常分为功能测试用例、性能测试用例、安全测试用例、兼容性测试用例等类别。根据《软件测试技术》（王珊等，2007）一书，功能测试用例主要用于验证系统是否符合功能需求，而性能测试用例则关注系统的响应时间、吞吐量等指标。测试用例的结构通常包括输入、输出、预期结果、测试步骤、测试环境等部分。根据IEEE830标准，测试用例应包含明确的输入、输出、预期结果及状态描述，确保测试的可追溯性和可执行性。测试用例应具备可重复性和可维护性，以便在后续测试中重复使用，并根据需求变化进行调整。根据ISO25010标准，测试用例应采用模块化设计，便于根据需求变更进行调整。测试用例的可追溯性是确保测试结果与需求一致的重要依据。根据ISO25010标准，测试用例应包含需求编号、测试步骤、预期结果等信息，实现测试与需求的双向追溯。测试用例应具备可执行性，确保测试人员能够按照用例执行测试，并产生可验证的结果。根据IEEE830标准，测试用例应包含明确的测试步骤、输入、输出及预期结果，确保测试过程的可操作性。3.4用例编写规范与评审测试用例的编写应遵循统一格式，包括测试编号、测试标题、测试步骤、输入、输出、预期结果等。根据《软件测试技术》（王珊等，2007）一书，测试用例应采用标准化的格式，便于测试人员快速理解和执行。测试用例应具备清晰的描述，避免歧义，确保测试人员能够准确理解测试目的和操作步骤。根据IEEE830标准，测试用例应包含明确的测试步骤、输入、输出及预期结果，确保测试过程的可操作性。测试用例应经过评审，确保其有效性、可执行性和可追溯性。根据ISO25010标准，测试用例应由测试人员、开发人员和质量管理人员共同评审，确保测试用例符合项目要求和测试标准。测试用例的评审记录应包括评审时间、评审人员、评审意见和修改意见等。根据IEEE830标准，测试用例的评审应形成书面记录，便于后续的测试执行和结果分析。测试用例的持续改进是提升测试质量的重要环节。根据ISO25010标准，测试用例应定期进行评审和更新，根据测试结果和需求变化进行调整，确保测试用例的时效性和有效性。第4章功能测试方法与用例设计4.1功能测试概述与目标功能测试是软件质量保证的重要环节，其核心目标是验证软件系统是否符合需求规格说明书中的功能要求，确保系统在正常、异常和边界条件下都能正确运行。根据ISO25010标准，功能测试应覆盖所有用户需求，并通过测试用例的执行来验证系统的功能完整性与正确性。功能测试通常包括单元测试、集成测试、系统测试等阶段，其中功能测试主要关注模块间的接口交互及业务流程的正确执行。在功能测试中，测试用例的设计需遵循“覆盖率达到100%”的原则，确保每个功能点都有对应的测试用例进行验证。根据IEEE829标准，功能测试应包括测试用例的编写、执行、结果分析及缺陷记录，以确保测试过程的可追溯性。4.2功能测试用例设计功能测试用例设计应基于需求文档，采用等价类划分、边界值分析、因果图等方法，确保覆盖所有可能的输入条件和输出结果。等价类划分是常用的方法之一，用于将输入数据划分为若干等价类，每个类中的输入数据在测试中可以视为相同，从而减少测试用例数量。边界值分析则关注输入值的边界条件，例如最小值、最大值、临界值等，这些往往是系统出错的高发区域。因果图方法用于分析输入条件之间的因果关系，帮助设计更全面的测试用例，确保所有可能的组合都被覆盖。根据《软件工程中的测试方法》（王珊等，2018）建议，测试用例应包含输入数据、预期输出、测试步骤和测试结果等要素，以确保测试的可执行性。4.3功能测试用例分类与优先级功能测试用例可按测试类型分为功能正确性测试、功能完整性测试、功能性能测试等。功能正确性测试关注系统是否按照预期逻辑执行，例如数据处理是否准确、用户操作是否符合规范。功能完整性测试则验证系统是否覆盖所有功能需求，确保没有遗漏或误判。功能性能测试包括响应时间、吞吐量、并发处理能力等指标，用于评估系统在高负载下的表现。在用例优先级划分中，通常采用“关键性”与“一般性”分类，关键性用例应优先执行，以确保核心功能的正确性。4.4功能测试用例评审与验证功能测试用例的评审应由测试人员、开发人员及业务分析师共同参与，确保用例设计符合需求和技术实现。评审过程中需检查用例是否覆盖了所有功能需求，是否存在冗余或遗漏，以及是否具备可执行性。用例验证通常通过执行测试用例并记录结果，对比预期输出与实际输出，判断测试是否通过。验证过程中应记录测试结果、缺陷描述及修复建议，以支持后续的测试和修复工作。根据《软件测试白皮书》（IEEE12207）建议，测试用例的验证应形成文档记录，确保测试过程的可追溯性和可重复性。第5章非功能测试方法与用例5.1非功能测试概述与目标非功能测试是软件测试的重要组成部分，主要关注软件的性能、安全性、可用性、兼容性等非功能特性，其目标是确保软件在实际运行中能满足用户需求并具备良好的用户体验。非功能测试通常不直接验证软件的逻辑功能，而是关注软件在不同环境下的表现，如响应时间、资源消耗、系统稳定性等。非功能测试的目的是提升软件的可靠性和可维护性，确保软件在各种使用场景下都能稳定运行，减少因非功能缺陷导致的系统故障。非功能测试的成果通常以测试用例、测试报告和性能指标为核心，为软件的持续优化提供依据。非功能测试与功能测试并行进行，是软件质量保障体系中不可或缺的一环，有助于全面评估软件的综合性能。5.2性能测试用例设计性能测试用例设计需覆盖不同负载条件，如正常负载、峰值负载、突发负载等，以验证系统在不同场景下的响应能力。常用性能测试指标包括响应时间、吞吐量、并发用户数、资源利用率等，这些指标可通过性能测试工具（如JMeter、LoadRunner）进行采集。为确保测试结果的可靠性，性能测试用例应包含边界值、极端值和典型值，以全面覆盖系统可能的运行状态。性能测试应结合压力测试和负载测试，模拟真实用户行为，确保系统在高并发场景下的稳定性与可用性。在性能测试中，应记录并分析系统在不同负载下的性能表现，为优化系统架构和资源分配提供依据。5.3安全性测试用例设计安全性测试用例设计需涵盖常见攻击类型，如SQL注入、XSS攻击、CSRF攻击、权限越权等，以验证系统对潜在安全威胁的防御能力。安全性测试通常采用白盒测试和黑盒测试相结合的方法，结合代码审查和模拟攻击，确保系统在安全边界内运行。安全性测试用例应包括用户身份验证、密码保护、数据加密、日志审计等关键环节，确保系统在数据传输和存储过程中具备足够的安全防护。安全性测试应遵循ISO/IEC27001等国际标准，结合行业最佳实践，确保测试覆盖全面且符合规范。在安全性测试中，应关注系统漏洞的发现与修复，通过自动化工具和人工测试相结合，提升测试效率与覆盖率。5.4可用性测试用例设计可用性测试用例设计应关注用户操作的便捷性、界面的直观性以及系统的易用性，确保用户能够高效、顺利地使用软件。可用性测试通常包括界面设计、导航结构、操作流程、反馈机制等维度，以评估用户在使用过程中的体验感受。可用性测试应结合用户调研、任务分析和用户操作日志，结合眼动追踪、用户满意度调查等方法，获取用户真实反馈。可用性测试用例应覆盖不同用户群体，如普通用户、专业用户、老年人等，确保系统在不同用户需求下都能提供良好的使用体验。在可用性测试中，应关注系统的响应速度、错误提示的清晰度、帮助信息的完整性等，以提升用户满意度和系统接受度。第6章软件测试流程与实施6.1测试流程与阶段划分软件测试流程通常遵循“计划—设计—执行—评估—报告”五大阶段，符合ISO25010标准，确保测试活动有条不紊地推进。测试阶段划分依据软件生命周期模型，如瀑布模型、敏捷模型等，不同模型对测试阶段的划分方式有所不同。在敏捷开发中，测试通常与开发并行，分为单元测试、集成测试、系统测试和验收测试四个阶段，每个阶段有明确的交付物和验收标准。依据《软件工程可靠性》（IEEE12207）标准，测试流程应覆盖需求分析、设计、编码、测试、部署等全过程，确保软件质量。测试阶段划分需结合项目规模、复杂度及团队能力，如大型系统可能需增加测试用例数量和测试人员配置。6.2测试执行与执行记录测试执行是验证软件功能是否符合需求的关键环节，需遵循测试用例设计规范，确保覆盖所有边界条件和异常情况。测试执行过程中，应使用测试日志、测试报告等工具记录测试过程，包括测试用例执行结果、异常信息及修复情况。依据《软件测试实践指南》（IEEE12208），测试执行需由测试人员独立完成，避免测试人员主观影响测试结果。测试执行记录应包括测试环境配置、测试用例编号、执行时间、测试结果（通过/失败/阻塞）等信息，便于后续追溯与复盘。采用自动化测试工具（如JUnit、Selenium）可提高测试效率，但需注意测试数据的维护与版本控制。6.3测试报告与缺陷跟踪测试报告是评估软件质量的重要文档，应包含测试覆盖率、缺陷统计、测试用例通过率等关键指标。缺陷跟踪系统（如JIRA、Bugzilla）是管理缺陷的标准化工具，支持缺陷分类、优先级、状态跟踪与修复进度追踪。根据《软件缺陷管理规范》（GB/T14882），缺陷应按照严重程度（致命、严重、一般、轻微）进行分类，并记录发现时间、复现步骤、修复建议等信息。测试报告需由测试团队与开发团队协同完成，确保缺陷修复后重新测试，验证修复效果。采用缺陷跟踪与测试报告一体化系统，可提升测试效率，减少重复工作，提高软件质量。6.4测试总结与复盘测试总结是对整个测试过程的回顾与评估，需分析测试覆盖率、缺陷数量、测试效率等关键指标。根据《软件测试复盘指南》（IEEE12209），测试复盘应包括测试过程中的成功经验、不足之处及改进建议。测试复盘可结合测试用例覆盖率、缺陷密度、测试用例执行时间等数据进行分析，为后续测试提供依据。通过测试复盘，团队可优化测试策略，提升测试效率，降低测试成本，增强软件质量保障能力。建议在测试结束后进行总结会议，由测试负责人、开发人员、项目经理共同参与，形成测试总结报告并存档。第7章测试用例维护与更新7.1测试用例版本管理与更新测试用例版本管理是确保测试文档与实际测试环境一致的重要手段，通常采用版本控制工具（如Git）进行管理，以支持不同版本的测试用例的追踪与回溯。根据ISO25010标准，测试用例应具备版本号、创建时间、修改时间、修改人等信息，以明确各版本的变更内容与责任归属。在软件开发过程中，测试用例的版本更新需遵循“变更记录”原则，确保每次修改都有清晰的变更日志，避免因版本混乱导致测试遗漏或重复。采用阶段性版本管理策略，如按功能模块划分版本，有助于提高测试用例的可维护性与可追溯性。实践表明，定期进行测试用例版本审查与清理，可有效减少冗余用例，提升测试效率与质量。7.2测试用例复用与共享测试用例复用是指将已开发的测试用例在不同项目或模块中重复使用，以避免重复开发与测试工作，提高测试效率。根据IEEE829标准，测试用例应具备可复用性，包括测试环境、输入、预期输出等关键信息，确保复用时的稳定性与一致性。在软件开发中，测试用例复用可通过测试用例库（TestCaseLibrary）实现，支持多项目共享与协作，降低开发成本。复用测试用例时，需注意测试用例的边界条件与依赖关系，避免因复用不当导致测试失败或误判。实践中，测试团队应建立统一的测试用例共享机制，如通过JIRA、Confluence等工具进行管理，提升团队协作效率。7.3测试用例失效与失效分析测试用例失效是指测试用例在实际测试中未能覆盖预期功能或出现错误，导致测试结果不准确。根据ISO25010标准，测试用例失效需进行失效分析，找出失效原因并采取改进措施，以提升测试用例的可靠性。失效分析通常包括测试用例设计缺陷、测试环境问题、测试数据不充分等，需结合测试日志与缺陷报告进行诊断。实践中，测试团队应建立失效分析机制，定期对失效测试用例进行归类与归因，形成失效知识库。通过失效分析，可以识别出测试用例设计中的薄弱环节，从而指导后续测试用例的优化与改进。7.4测试用例的持续优化与改进测试用例的持续优化是提升测试质量与效率的关键环节，需结合测试反馈与业务需求进行动态调整。根据IEEE829标准，测试用例应具备