单元测试中设计测试用例的依据

一、需求规格说明书

• 功能需求描述
  • 需求规格说明书详细地阐述了软件系统应该具备的功能。例如，对于一个计算器软件的加法功能，说明书会明确指出用户输入两个数字后，系统能够正确计算它们的和并输出结果。测试人员就可以根据这个描述设计测试用例，如输入整数相加（如2 + 3）、小数相加（如2.5+3.5）等多种情况，来验证加法功能是否正确实现。
  • 对于一些复杂的业务逻辑功能，比如电商系统中的订单处理功能。需求规格可能会提到订单创建时，需要验证用户信息是否完整、商品库存是否足够等多个条件。测试用例就要考虑各种用户信息不完整（缺少联系方式、收货地址等）和库存不足的情况，来检查系统是否按照要求进行正确的反馈。
• 非功能需求描述
  • 非功能需求包括性能、可靠性、安全性等方面。以性能为例，如果需求规格说明书规定某个功能的响应时间应该在1秒以内。那么测试用例就要设计来验证在不同负载（如少量用户请求和大量用户请求）下，该功能是否满足响应时间的要求。
  • 对于安全性要求，若系统涉及用户登录和密码保护，需求可能规定密码要以加密形式存储。测试用例就可以包括检查密码存储是否加密、加密算法是否符合规定等内容。

二、软件设计文档（如详细设计、架构设计）

• 模块接口设计
  • 详细设计文档会描述各个模块之间的接口信息。比如一个软件系统有用户管理模块和订单管理模块，接口设计文档会说明用户管理模块提供的接口函数以及参数类型和返回值等信息，用于订单管理模块获取用户信息。测试用例可以依据这些接口信息，设计测试用例来验证接口参数传递是否正确、返回值是否符合预期。例如，测试调用用户管理模块获取用户年龄接口时，传入正确的用户ID，检查返回的年龄值是否正确；同时还要测试传入错误的用户ID时，是否返回正确的错误提示。
• 模块内部逻辑结构
  • 对于一个复杂的算法模块，设计文档会详细说明算法的实现步骤。例如，在一个图像识别软件中的图像特征提取模块，文档会描述如何对图像进行预处理、采用何种特征提取算法等内容。测试用例可以根据这些内部逻辑步骤，设计测试数据来验证每一个步骤的正确性。比如，针对图像预处理步骤，可以测试不同分辨率、不同色彩模式的图像经过预处理后是否符合后续算法的输入要求。

三、代码实现（代码结构、逻辑等）

• 代码逻辑路径覆盖
  • 通过分析代码中的条件语句（如if - else语句）、循环语句（如for循环、while循环），可以设计测试用例来覆盖不同的逻辑路径。例如，有一段代码用于判断用户输入的数字是否大于10，如果大于10则进行某种计算，否则进行另一种计算。测试用例就要设计输入大于10的数字和小于等于10的数字这两种情况，来确保两条逻辑路径都能正确执行。
  • 对于包含多层嵌套条件语句的复杂代码，如一个电商系统中根据用户等级、购买金额、商品类型等来计算折扣的代码，要设计足够多的测试用例来覆盖所有可能的条件组合路径，以验证代码逻辑的正确性。
• 异常处理情况
  • 代码中通常会包含异常处理机制，用于应对可能出现的错误情况。例如，在文件读取操作的代码中，会有对文件不存在情况的异常处理。测试用例就要设计测试文件不存在时，系统是否能够正确地抛出异常并进行合理的提示或处理，如是否记录错误日志、是否向用户返回友好的错误消息等情况。

四、以往的缺陷数据（缺陷报告、故障记录）

• 重现已知缺陷
  • 如果之前的测试或者用户反馈发现了软件中的某些缺陷，那么在新的单元测试中，要设计测试用例来重现这些缺陷。例如，之前发现一个计算器软件在计算较大数字相加时会出现精度丢失的问题，那么在新的测试用例设计中，要包含类似的大数据相加的测试场景，并且检查是否已经修复了精度丢失的问题。
• 预防类似缺陷
  • 对已知缺陷进行分析，找出可能导致类似缺陷的原因，然后设计测试用例来预防这些缺陷。例如，之前发现一个函数在处理边界值（如最大值、最小值）时出现错误，那么除了针对这个函数重新设计边界值测试用例来验证修复情况外，还要对其他类似功能的函数也进行边界值测试，以防止出现同样的问题。