测试用例编写规范

在车载项目开发过程中，测试是关键中关键的一环，包括供应商释放每版软件时的全量测试，也包括主机厂的验收测试。那针对测试这块，测试用例设计的规范一般是怎么样呢？今天一起来探讨一下。

首先是规范测试用例的背景是什么呢？主要有两个维度，首先是为保证测试用例对需求的覆盖率，第二个就是对单个功能点，主要验证不同的输入及其组合所带来的各种输入动作，系统输出是否合理。

测试用例设计规范的目的是为测试用例的质量负责，使测试能有序、合理化的进行，从而提高实施测试时的测试质量。

那下面就来仔细聊聊测试用例设计的规范。首先是一条测试用例要包含哪些内容呢？

01.

编写用例原则

在上面对整体测试规范的背景和目的简单说明后，那先来看看测试用例编写的原则，主要包括系统性，全面性，正确性，可操作性，下面挨个来聊聊。

系统性：要能完整的说明整个系统的业务需求、系统由几个子系统组成以及间的关系；对模块业务流程要说明子系统内部功能、重点功能以及之间的关系；

全面性：应尽可能覆盖各种路径、尽可能覆盖各个业务点；

正确性：输入界面后的数据应与测试文档所记录的数据一致，而预期结果也应与测试数据发生的业务吻合。

可操作性：测试用例中要写清楚测试的操作步骤，以及不同的操作步骤相对应的测试结果。

02.

编写用例标准

讨论完测试用例的原则后，那用例实际应该怎么编写呢，其标准是什么呢？首先测试用例编写应该统一模板并约定模板的使用方法；其次测试用例编写应当根据实际情况编写测试用例编写手册，包括用例编号规则、编写方法、维护等内容等；然后则是用例编写应根据手册中约定的编写方法、内容等进行编写，并且写要明确步骤，输入输出要素清晰，并且与需求和缺陷相对应；最后按照用例编写原来中全面性，用例编写应严格根据需求及测试需求功能分析点进行，要求覆盖全部需求功能点。

最后用例编写要注重用例的可复用性，减少后续类似需求的测试设计工作量。

03.

用例设计步骤

在聊完用例原则和标准后，就要开始实操了，看用例设计的步骤了。

第一步是测试需求分析：从需求分析文档中，找出待测的需求点，通过分析、理解，整理成为测试需求，要清楚被测对象具体包含哪些功能点。

第二步则是业务流程分析：首先要对业务知识要熟悉，然后对被功能需求要进行全盘的整理出来。

第三部则是测试用例设计：测试用例设计的类型主要包括功能测试、边界测试、异常测试、性能测试、压力测试等，在设计用例时要尽量考虑边界、异常等情况。

第四部则是测试用例评审：由测试用例编写者发起，参加的人员需包括测试负责人、项目经理、开发人员及其他相关的测试人员。

第五步则是测试用例完善：测试用例编写完成之后需要不断完善，包括功能需求迭代，或者是在软件交付后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。

04.

用例维护

测试用例编写并不是一次性的工作，后续还需要定期的维护测试用例，为什么要维护呢？

删除过时的测试用例

因为需求的改变等原因可能会使一个基线测试用例不再适合被测系统，那么这些测试用例就会过时，需要对这些测试用例进行及时的删除。

修改测试用例

随着项目的进展，测试需求可能会有部分变更，甚至大范围的变更，这个时候就会根据需求的变化相应的对测试用例进行维护，修改已经不符合目前需求的内容，并备注加以说明。

删除冗余的测试用例

如果存在两个或更多测试用例对一组相同的输入和输入进行测试，则需要对其进行删除，只需留下其中的一个。

增添新的测试用例

对新增的功能、在评审过程及测试过程中发现缺少测试用例或者系统出现BUG但是没有与之对应的测试用例，需要按照测试用例的设计标准进行增添，增加测试用例时，需要在相应功能模块的最下方插入新增的测试用例，并在备注栏中加以说明。

05.

用例设计方法

测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。测试数据应该选用少量、高效的测试数据进行尽可能完备的测试；基本目标是：设计一组发现某个错误或某类错误的测试数据，测试用例应覆盖方面：

等价划分：将所有可能的输入数据（有效的和无效的）划分成若干个等价类。

边界值分析法：确定边界情况，针对系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。

场景法：通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。

基本流：是经过用例的最简单的路径；

正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。

健壮性测试：程序能够接收正确数据输入并且产生正确（预期）的输出；输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。

完整性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息的完整。

接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。

压力测试：输入10条记录运行各个功能，输入30条记录运行，输入50条记录运行，进行测试。

错误推测：主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。

效率：完成预定的功能，系统的运行时间。

可操作性：理解和使用该系统的难易程度（界面友好性）。

可移植性：在不同操作系统及硬件配置情况下的运行性。

回归测试：按照测试用例将所有的测试点测试完毕，测试中发现的问题开发人员。

比较测试：将已经发版的类似产品或原有的老产品与测试的产品同时运行比较，或与已往的测试结果比较。

兼容性测试：操作系统的兼容性测试内容不仅包括软件的安装，还需对关键流程和功能点进行检查。而需要测试哪些操作系统的兼容性，首先取决于软件用户文档上对用户的承诺，其次就需要对一些常用操作系统兼容的检查

历史版本兼容性测试：某些功能存在新版本和历史版本数据显示、页面展示不一致的问题。需要不同版本进行测试。

06.

用例评审

在完成用例编写后，就需要预约会议，对用例进行评审，为什么需要评审呢？主要是测试用例是软件测试的原则，但由于软件人员对在需求理解、设计等理解程度不同等因素的影响，首次产生的测试用例质量难以避免会有不同程度的差异，故对编写的测试用例进行评审是很有必要的，其作用是测试用例的评审过程能够起到用例结构清晰化、场景覆盖全面化以及优先用例的合理化安排等。

评审的内容包括用例设计的结构安排是否清晰合理，是否高效的需求进行覆盖用例的优先级别是否安排合理；是否覆盖了测试需求的所有功能点，包括需求中的业务规则、所有用户可能使用的流程或场景等；用例是否有很好的可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；是否已经删除了冗余的测试用例；是否包含充分的负面测试用例是否简洁、复用性强、是否易于管理。

那评审过程是怎样的呢？基于项目需求的测试计划完成之后，进行初审，主要是对测试范围和测试要点进行审查在测试用例的设计完成之后进行复审，主要是对测试用例的结构和覆盖率进行评审所有测试用例结束后，主要是对测试用例的具体描述是否有很好的可执行性，是否有冗余用例的存在进行评审。

评审之后，经评审的用例由用例设计者根据评审的建议或意见进行修改，更新用例，再次发起评审、修改、更新用例，反复评审后，直至用例达到要求。

在用例经过用例评审后，则就可以排计划让测试人员安排测试了。包括建立测试计划；建立对应的版本追溯；确认测试人员，测试报告输出等。

-end-