软件测试中如何编写单元测试用例(白盒测试)

合集下载

单元测试方法之黑盒测试与白盒测试

单元测试方法之黑盒测试与白盒测试单元测试是软件开发中的一项重要工作，它用于验证程序中的最小功能单元（代码块、函数、方法等）是否按照预期工作。

在进行单元测试时，我们可以采用黑盒测试和白盒测试两种方法。

本文将介绍黑盒测试和白盒测试的概念、原理和使用方法，并对它们进行比较。

黑盒测试（Black Box Testing）是一种测试方法，它基于对被测试程序的输入和输出进行验证，而不考虑程序内部的实现细节。

在黑盒测试中，测试人员只关注被测试程序的规格说明，以及预期结果是否与实际输出一致。

黑盒测试可以帮助发现用户可能遇到的问题，从而提高软件的质量。

在进行黑盒测试时，测试人员需要根据软件需求和功能规格说明书，设计测试用例来验证程序的各个方面。

这些测试用例应该覆盖所有的输入情况和可能的异常情况，以确保被测试程序的正确性和可靠性。

常用的黑盒测试方法包括等价类划分、边界值分析和决策表测试等。

等价类划分是一种根据输入空间的特征将其划分为若干等价类的方法。

在进行等价类划分时，测试人员需要确定输入参数的有效等价类和无效等价类，并设计测试用例来覆盖这些等价类。

例如，对于一个接收年龄参数的函数，有效等价类可以是18岁到60岁的范围，无效等价类可以是负数或超过120岁的范围。

边界值分析是一种根据输入空间的边界情况设计测试用例的方法。

在进行边界值分析时，测试人员需要确定输入参数的边界值和边界值加一和减一的值，并设计测试用例来覆盖这些情况。

例如，对于一个接收年龄参数的函数，边界情况可以是17岁和61岁。

决策表测试是一种基于程序逻辑的测试方法，它根据程序中的分支和条件语句设计测试用例。

在进行决策表测试时，测试人员需要确定程序中的条件和动作，并根据这些条件和动作设计测试用例。

例如，对于一个需要判断学生成绩等级的函数，测试人员可以根据不同的学生分数和分数范围设计测试用例。

相比黑盒测试，白盒测试（White Box Testing）是一种根据程序内部结构和实现逻辑来设计测试用例的方法。

基于白盒测试的用例设计与验证(一)

学号：《软件测试技术》实验报告与习题册2014 / 2015 学年第2学期系别计算机科学与技术专业计算机软件班级一班姓名指导教师目录实验一：基于白盒测试的用例设计与验证（一）一.实验目的（1）熟悉Eclipse开发环境（2）掌握Java语言的基本语法，能够利用Java实现简单的程序开发（3）熟悉白盒测试基本原理（4）掌握白盒测试的逻辑覆盖法，能够依据语句覆盖、判定覆盖、条件覆盖、判定\条件覆盖、条件组合覆盖的原理进行相应测试用例的设计工作。

二.实验内容（1）选择一门语言，完成指定的单元程序开发。

（2）分别依据白盒测试逻辑覆盖法中的语句覆盖、判定覆盖、条件覆盖、判定\条件覆盖、条件组合覆盖的原理设计相应的测试用例。

（3）根据给定的流程图，实际运行测试用例，检测程序的实现是否正确。

三.程序流程图运行结果示例程序源码#include<stdio.h>void main(){int m;int n;int p;int q;printf("请输入m的值：");scanf("%d",&m);printf("请输入n的值：");scanf("%d",&n);printf("请输入p的值：");scanf("%d",&p);printf("请输入q的值：");scanf("%d",&q);printf("输入完毕\n");if(m>0 && n<6){m=n+3;n=n*2;}if(p>5 || q<0){p=2*q+5;q=q++;}printf("m:%d\n",m);printf("n:%d\n",n);printf("p:%d\n",p);printf("q:%d\n",q);}1.语句覆盖程序中的每个可执行语句至少被执行一次2.判定覆盖3.条件覆盖4.判定-条件覆盖判断条件中的所有条件可能取值至少执行一次，同时，所有判断的可能结果至少执行一次。

第2讲-单元测试(白盒测试)

5
单元测试的方法
单元测试主要采用白盒测试方法，辅以黑盒测试方法。白盒测试方法应用于代码评审、单元程序检验之中，而黑盒测试方法则应用于模块、组件等大单元的功能测试之中
6
黑盒方法和白盒方法
黑盒测试方法（Blake-box Testing），是把程序看作
一个不能打开的黑盒子，不考虑程序内部结构和内部特性，而是考察数据的输入、条件限制和数据输出，完成测试
60代码审查代码审查的范围和方法代码规范性的审查代码缺陷检查表61代码审查的范围和方法代码审查的目的就是为了产生合格的代码检查源程序编码是否符合详细设计的编码规定确保编码与设计的一致性和可追踪性审查的内容编程规则62代码规范性的审查代码规范性的审查将助于更早地发现缺陷代码质量的提高而且可以帮助程序员遵守规则养成好的习惯以达到预防缺陷的目的代码风格和编程规则两者不可缺一都应列入代码评审的范围里命名规则缩进与对齐注释和函数处理63代码缺陷检查表把程序设计中可能发生的各种缺陷进行分类以每一类列举尽可能多的典型缺陷形成代码缺陷检查表
16
判定覆盖
判定覆盖：通过执行足够的测试用例，使得程序中的每个判定至少都获得一次“真”值和“假”值，也就是使程序中的每个取“真”分支和取“假”分支至少均经历一次，也称为“分支覆盖”。
要实现DoWork函数的判定覆盖，需要设计两个测试用例
测试用例的输入为：{x=4、y=5、z=5}；{x=2、y=5、z=5} 程序执行的路径分别是：abd；ace
使用acd、abe两条路径的用例也满足判定覆盖
分析：上述两个测试用例不仅满足了判定覆盖，同时还做到语句覆盖。从这点看似乎判定覆盖比语句覆盖更强一些，但仍然无法确定判定内部条件的错误。例如把第二个判定中的条件y>5错误写为y<5，使用上述测试用例，照样能按原路径执行而不影响结果。因此，需要有更强的逻辑覆 17 盖准则去检验判定内的条件。

白盒测试中的测试工具与自动化脚本编写

白盒测试中的测试工具与自动化脚本编写白盒测试是软件测试中的一种重要测试方法，它主要关注内部的程序代码和结构，通过对软件内部逻辑的验证来检测是否存在错误和缺陷。

为了提高白盒测试的效率和准确性，测试工程师通常会使用各种测试工具和自动化脚本来辅助完成测试任务。

本文将介绍一些常用的白盒测试工具，并探讨如何编写高效的自动化脚本。

一、白盒测试工具1.代码静态分析工具代码静态分析工具是一类能够对软件源代码进行全面扫描和分析的工具。

它能够识别出代码中的潜在问题和潜在缺陷，如未初始化的变量、内存泄漏、死代码等。

常见的代码静态分析工具有Coverity、PMD、FindBugs等。

2.单元测试框架单元测试框架是一种用于执行单元测试的工具。

它可以帮助开发人员编写和执行测试用例，并提供丰富的断言方法和自动化报告生成。

常见的单元测试框架有JUnit（Java）、Pytest（Python）、NUnit（.NET）等。

3.覆盖率工具覆盖率工具用于测量测试用例对软件源代码的覆盖程度。

它可以通过统计代码执行信息，告诉测试人员哪些代码没有被测试到，从而指导测试用例的编写和执行。

常见的覆盖率工具有Jacoco（Java）、Cobertura（Java）等。

4.性能测试工具性能测试工具可以模拟出多样的负载情况，并对软件在不同负载条件下的性能表现进行测量和评估。

通过使用性能测试工具，测试人员可以发现系统性能瓶颈和资源消耗情况，优化软件的运行效果。

常见的性能测试工具有JMeter、LoadRunner等。

二、自动化脚本编写自动化脚本是白盒测试过程中不可或缺的一部分，它可以帮助测试人员提高测试的效率和一致性。

以下是编写高效自动化脚本的几个要点：1.选择合适的脚本语言根据被测系统的特点和测试需求，选择合适的脚本语言是非常重要的。

脚本语言应该具备良好的库支持和生态系统，以便于编写和维护脚本。

常见的脚本语言有Python、JavaScript、Ruby等。

测试方案范例

测试方案范例一、背景介绍在软件开发和系统维护过程中，测试是确保系统质量的关键环节之一。

一个完善的测试方案可以有效地保证软件系统的正常运行，提升用户的使用体验。

本文将为大家提供一个测试方案的范例，帮助读者了解如何编写一份高质量的测试方案。

二、测试目标测试的目标是确保软件系统的功能完备、性能稳定、安全可靠，并且符合用户需求。

针对不同类型的系统，测试的重点可能有所不同，但总体目标都是保证软件系统的质量和稳定性。

三、测试策略1. 测试方法根据软件系统的特点和需求，选择合适的测试方法。

常用的测试方法包括黑盒测试、白盒测试、灰盒测试等。

根据测试需要，可以采用单元测试、集成测试、系统测试、验收测试等不同层次的测试方法。

2. 测试环境建立符合实际运行环境的测试环境，包括硬件资源、网络环境、操作系统等。

确保测试环境和实际运行环境的一致性，以便能够准确地模拟用户实际使用情况。

3. 测试数据设计合适的测试数据，覆盖各种边界情况和异常情况，确保软件系统在各种情况下都能正常工作。

测试数据应该具有代表性，能够覆盖用户使用系统的常见场景。

4. 测试计划根据项目的时间安排和资源分配，编制详细的测试计划。

测试计划应包括测试的时间安排、测试人员的分工、测试用例的设计和执行等内容。

5. 缺陷管理建立缺陷管理系统，及时记录和跟踪发现的缺陷，并与开发团队进行有效的沟通和协作。

确保发现的缺陷能够得到及时修复，并进行验证和确认。

四、测试活动1. 需求分析阶段在需求分析阶段，通过与需求方进行沟通和交流，明确系统的功能和性能需求。

同时，考虑系统可能存在的风险和不确定性，为后续的测试活动做好准备。

2. 测试计划阶段在测试计划阶段，制定详细的测试计划，包括测试用例的设计、测试环境的准备、测试数据的准备等。

根据测试计划，组织测试团队进行测试活动。

3. 测试设计阶段在测试设计阶段，根据需求分析和测试计划，设计测试用例和测试数据。

测试用例应覆盖系统的各个功能点和各种可能的情况，确保系统的功能和性能能够得到充分的验证。

白盒测试的主要有以下哪些步骤

白盒测试的主要步骤白盒测试是软件开发过程中的一种测试方法，通过查看和分析软件的内部结构和代码来评估其质量。

在进行白盒测试时，测试人员需要按照一系列步骤来完成这个过程，以确保软件系统的功能和性能符合预期。

下面是白盒测试的主要步骤：1. 确定测试的目标和范围在进行白盒测试之前，首先需要明确测试的目标和范围。

测试人员需要了解要测试的软件系统的功能和特性，并确定需要覆盖的代码范围和测试重点。

2. 分析需求和设计文档测试人员需要仔细分析软件系统的需求和设计文档，以了解系统的架构和功能。

这有助于测试人员确定哪些部分需要进行测试以及如何设计测试用例。

3. 编写测试用例根据需求和设计文档，测试人员编写白盒测试用例。

测试用例应涵盖不同的代码路径和边界条件，以确保软件系统的每个功能都得到充分测试。

4. 执行测试用例测试人员执行编写的测试用例，同时记录测试结果。

在执行测试用例的过程中，需要验证软件系统的功能是否按照需求文档的规范工作，同时检查是否存在潜在的缺陷和问题。

5. 分析测试结果一旦测试完成，测试人员需要分析测试结果并检查是否存在失败的测试用例。

通过分析测试结果，可以确定软件系统的稳定性和质量，并识别需要改进的地方。

6. 跟踪和修复缺陷测试人员应该跟踪所有发现的缺陷，并确保这些缺陷得到及时修复。

跟踪缺陷的过程可以协助开发团队更好地理解和解决问题，提高软件系统的质量。

结语白盒测试是软件开发过程中必不可少的一环，通过深入了解和分析软件系统的内部结构来确保其质量和可靠性。

遵循上述步骤可以帮助测试人员高效地完成白盒测试，并为软件系统的发布提供有力的支持。

白盒测试测试报告模板

白盒测试测试报告模板：测试报告模板测试白盒测试方法黑盒测试和白盒测试接口测试是白盒测试吗篇一：白盒测试实验报告-范例广西科技大学计算机学院《软件测试技术》实验报告书实验一白盒测试学生姓名：xxxx 学号：xxxx 班级：xxxx 指导老师：xxxxx 专业：计算机学院软件工程提交日期：2014年10月20日白盒测试实验报告一实验内容1、系统地学习和理解白盒测试的基本概念、原理，掌握白盒测试的基本技术和方法；2、举例进行白盒测试，使用语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合覆盖、路径覆盖进行测试。

3、通过试验和应用，要逐步提高和运用白盒测试技术解决实际测试问题的能力；4、熟悉C++编程环境下编写、调试单元代码的基本操作技术和方法；5、完成实验并认真书写实验报告（要求给出完整的测试信息，如测试程序、测试用例，测试报告等）二实验原理白盒测试原理：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否已经过检查。

它是把测试对象看作装在一个透明的白盒子里，也就是完全了解程序的结构和处理过程。

这种方法按照程序内部的逻辑测试程序，检验程序中的每条通路是否都能按预定要求正确工作。

其又称为结构测试。

对于该实验的例子给出其流程图如下图所示，我们来了解白盒测试的基本技术和方法。

语句覆盖是指选择足够的测试用例，使得程序中每个语句至少执行一次。

如上例选择测试用例x=1,y=1和x=1,y=-1可覆盖所有语句。

判定覆盖是指选择足够的测试用例，使得程序中每一个判定至少获得一次”真”值和“假”值，从而使得程序的每个分支都通过一次（不是所有的逻辑路径）。

选择测试用例x=1,y=1和x=1,y=-1可覆盖所有判定。

条件覆盖是指选择语句多数的测试用例，使得程序判定中的每个条件能获得各种不同的结果。

选择测试用例x=1,y=1和x=-1,y=-1可覆盖所有条件。

判定/条件覆盖是指选择足够多的测试用例，使得程序判定中每个条件取得条件可能的值，并使每个判定取到各种可能的结果（每个分支都通过一次）。

1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

软件测试中如何编写单元测试用例（白盒测试）测试用例（T est Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

测试用例（T est Case）目前没有经典的定义。

比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。

内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

不同类别的软件，测试用例是不同的。

不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。

笔者主要从事企业管理软件的测试。

因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。

测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。

对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。

随着中国软件业的日益壮大和逐步走向成熟，软件测试也在不断发展。

从最初的由软件编程人员兼职测试到软件公司组建独立专职测试部门。

测试工作也从简单测试演变为包括：编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试。

测试方式则由单纯手工测试发展为手工、自动兼之，并有向第三方专业测试公司发展的趋势。

要使最终用户对软件感到满意,最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。

测试用例反映了要核实的需求。

然而，核实这些需求可能通过不同的方式并由不同的测试员来实施。

例如，执行软件以便验证它的功能和性能，这项操作可能由某个测试员采用自动测试技术来实现；计算机系统的关机步骤可通过手工测试和观察来完成；不过，市场占有率和销售数据（以及产品需求），只能通过评测产品和竞争销售数据来完成。

既然可能无法（或不必负责）核实所有的需求，那么是否能为测试挑选最适合或最关键的需求则关系到项目的成败。

选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。

确定测试用例之所以很重要，原因有以下几方面。

测试用例构成了设计和制定测试过程的基础。

测试的“深度”与测试用例的数量成比例。

由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，您对产品质量和测试流程也就越有信心。

判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和/或执行的测试用例的数量为依据的。

类似下面这样的说明：“95 % 的关键测试用例已得以执行和验证”，远比“我们已完成95 % 的测试”更有意义。

测试工作量与测试用例的数量成比例。

根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。

测试设计和开发的类型以及所需的资源主要都受控于测试用例。

测试用例通常根据它们所关联关系的测试类型或测试需求来分类，而且将随类型和需求进行相应地改变。

最佳方案是为每个测试需求至少编制两个测试用例：·一个测试用例用于证明该需求已经满足，通常称作正面测试用例；·另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。

前段时间公司进行有关测试的培训，集成测试，性能测试，压力测试说了很多。

由于本人还处于Coder阶段，只是对单元测试有了些了解。

写下来怕以后自己忘记了。

都是些自己的看法，不一定准确，欢迎高手指教。

一、单元测试的概念单元通俗的说就是指一个实现简单功能的函数。

单元测试就是只用一组特定的输入(测试用例)测试函数是否功能正常，并且返回了正确的输出。

测试的覆盖种类1.语句覆盖：语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次。

2.判定覆盖（也叫分支覆盖）：设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次。

3.条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次。

4.判定——条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次，并且每个可能的判断结果也至少执行一次。

5.条件组合测试：设计足够的测试用例，运行所测程序，使程序中每个判断的所有条件取值组合至少执行一次。

6.路径测试：设计足够的测试用例，运行所测程序，要覆盖程序中所有可能的路径。

用例的设计方案主要的有下面几种：条件测试，基本路径测试，循环测试。

通过上面的方法可以实现测试用例对程序的逻辑覆盖，和路径覆盖。

二、开始测试前的准备在开始测试时，要先声明一下，无论你设计多少测试用例，无论你的测试方案多么完美，都不可能完全100%的发现所有BUG，我们所需要做的是用最少的资源，做最多测试检查，寻找一个平衡点保证程序的正确性。

穷举测试是不可能的。

所以现在进行单元测试我选用的是现在一般用的比较多的基本路径测试法。

三、开始测试基本路径测试法：设计出的测试用例要保证每一个基本独立路径至少要执行一次。

函数说明：当i_flag=0；返回i_count+100当i_flag=1；返回i_count *10否则返回i_count *20输入参数：int i_count ，int i_flag输出参数：int i_return;代码：1 int T est(int i_count, int i_flag)2 {3 int i_temp = 0;4 while (i_count>0)5 {6 if (0 == i_flag)7 {8 i_temp = i_count + 100;9 break;10 }11 else12 {13 if (1 == i_flag)14 {15 i_temp = i_temp + 10;16 }17 else18 {19 i_temp = i_temp + 20;20 }21 }22 i_count--;23 }24 return i_temp;25 }1.画出程序控制流程图图例：事例程序流程图：圈中的数字代表的是语句的行号，也许有人问为什么选4,6,13,8......作为结点，第2行，第3行为什么不是结点，因为选择结点是有规律的。

让我们看程序中；第2行，第3行是按顺序执行下来的。

直到第4行才出现了循环操作。

而2，3行没有什么判断，选择等分支操作，所以我们把2，3，4全部合并成一个结点。

其他的也是照这个规则合并，然后就有了上面的流程图。

2.计算圈复杂度有了图以后我们要知道到底我们有写多少个测试用例，才能满足基本路径测试。

这里有有了一个新概念——圈复杂度圈复杂度是一种为程序逻辑复杂性提供定量测试的软件度量。

将该度量用于计算程序的基本独立路径数目。

为确保所有语句至少执行一次的测试数量的上界。

公式圈复杂度V（G）=E+N+2，E是流图中边的数量，N是流图中结点的数量。

公式圈复杂度V（G）=P+1 ，P是流图G中判定结点的数量。

通俗的说圈负责度就是判断单元是不是复杂，是不是好测试的标准。

一般来说如果圈复杂度如果大于20就表示这个单元的可测试性不好，太复杂（也许有人觉得无所谓，但是如果你们公司实行了CMMI5的话，对这个是有规定的）。

从图中我们可以看到，V（G）=10条边-8结点+2=4V（G）=3个判定结点+1=4上图的圈复杂图是4。

这个结果对我们来说有什么意义呢？它表示我们只要最多4个测试用例就可以达到基本路径覆盖。

3.导出程序基本路径。

现在我们知道了起码要写4个测试用例，但是怎么设计这4个测试用例？导出程序基本路径，根据程序基本路径设计测试用例子。

程序基本路径：基本独立路径就是从程序的开始结点到结束可以选择任何的路径遍历，但是每条路径至少应该包含一条已定义路径不曾用到的边。

（看起来不好理解，让我们看例子）。

让我们看上面的流程图：从结点4到24有几条路径呢？1 B（4，24）2 C，E，J（4，6，8，24）3 C，D，F，H，A，B（4，6，13，15，22，4，24）4 C，D，G，I，A，B（4，6，13，19，22，4，24）还有吗？？5 C，D，C，I，A，C，E，J（4，6，13，19，22，4，6，8，24）算吗？不算，为什么？因为上面的4条路径已经包括了所有的边。

第5条路径已经不包含没有用过的边了。

所有的路径都遍历过了。

好了，现在我们有了4条基本独立路径根据独立路径我们可以设计测试用例。

1 B（4，24）输入数据：i_flag=0，或者是i_flag<0的某一个值。

预期结果：i_temp=0.2 C，E，J（4，6，8，24）输入数据：i_count =1;i_flag=0预期结果：i_temp=101.3 C，D，F，H，A，B（4，6，13，15，22，4，24）输入数据：i_count =1;i_flag=1预期结果：i_temp=10.4 C，D，G，I，A，B（4，6，13，19，22，4，24）输入数据：i_count =1;i_flag=2预期结果：i_temp=20.这里的输入数据是有路径和程序推论出来的。

而要注意的是预期结果是从函数说明中导出，不能根据程序结构中导出。

为什么这么说？让我们看程序中的第3行。

int i_temp=0;假如开发人员一不小心写错了，变成了int i_temp=1;根据程序导出的预期结果就会是一个错误的值，但是单元测试不出来问题。

那单元测试就失去了意义。

有人也许会问这么简单的函数就有4个测试用例，如果还复杂一些的怎么办？上面的测试用例还可以简化吗？答案是可以。

我们来看路径1 B（4，24）和4 C，D，G，I，A，B（4，6，13，19，22，4，24），路径1是路径4的真子集，所以1是可以不必要的。

上图的圈复杂度是4。

这个结果对我们来说有什么意义呢？它表示我们只要最多4个测试用例就可以达到基本路径覆盖。

所以说圈复杂度标示是最多的测试用例个数，不是一定要4个测试用例才可以。

不过有一点要申明的是测试用例越简化代表你的测试越少，这样程序的安全性就越低了。

四、完成测试接下来根据测试用例使用工具测试NUNIT，VS2005都可以。

接下来根据测试结果编写测试报告，测试人，时间，结果，用例，是否通过，格式网上一大把，每个公司的格式也不一样就不说了。