测试用例编写规范
超级详细的测试用例设计规范
超级详细的测试用例设计规范当设计测试用例时，遵循一定的标准和规范可以确保测试的全面性、一致性和有效性。
以下是一个详细的测试用例设计标准和规范，可根据实际情况进行调整：1. 测试用例命名规范：•用例名称应简洁而具有描述性，清楚地说明被测功能。
•使用有意义的单词和短语，避免使用模糊或不清楚的术语。
2. 测试用例编写规范：•每个测试用例应该有一个明确的目标和预期结果。
•测试用例应尽量独立，避免相互依赖。
•每个用例应包含一个简短但详细的描述，涵盖用例的目标和步骤。
3. 测试用例结构规范：•用例编号：每个用例应有唯一的编号。
•测试优先级：指明用例的优先级，如高、中、低。
•预置条件：描述运行用例所需的初始条件。
•测试步骤：详细列出执行测试所需的步骤。
•预期结果：描述每个步骤的预期结果，以便进行比对。
4. 测试数据规范：•用不同的测试数据组合编写多个测试用例，覆盖不同情况。
•包括边界值、无效输入、正常情况等测试数据。
5. 预期结果规范：•预期结果应具体、明确，可以是文本描述或数值。
•预期结果应与实际结果进行比对，以判断测试是否通过。
6. 步骤的顺序：•用例中的步骤应按照逻辑顺序编写，确保测试流程清晰。
7. 特殊情况和异常处理：•包括测试异常输入、错误处理机制等。
•确保测试能够捕获并正确处理各种异常情况。
8. 重复性测试规范：•在必要时，包括对于相同操作的多次执行测试，以验证重复性。
9. 跨平台/浏览器/设备测试规范：•如适用，确保测试在不同的平台、浏览器或设备上都能正常运行。
10. 结果记录和报告规范：•每次测试运行后，记录实际结果和测试日期。
•创建详细的测试报告，包括测试用例执行情况、结果、问题和建议。
11. 审查和验证：•所有编写的测试用例应该经过审查和验证，确保完整和正确性。
12. 定期维护和更新：•定期审查测试用例，以确保其与应用程序的变化保持同步。
遵循这些测试用例设计的标准和规范，可以帮助您创建清晰、一致且有效的测试套件，确保对软件功能的全面测试和稳定性验证。
自动化测试用例规范 (2)
自动化测试用例规范一、引言自动化测试用例规范是为了确保测试用例的一致性、可读性和可维护性而制定的一套规范。
本文档旨在定义自动化测试用例的编写规则、命名规范、结构规范以及编写要求，以便测试团队成员能够编写高质量的自动化测试用例。
二、编写规则1. 用例编号：每一个用例都应有惟一的编号，用于标识和检索。
编号格式为“TC-模块编号-用例编号”，例如“TC-001-001”。
2. 用例标题：用于简要描述用例的目标和功能。
标题应该简明扼要，准确描述用例的主要功能。
3. 前置条件：描述用例执行前的环境和条件，包括必要的数据准备、系统状态等。
4. 测试步骤：按照逻辑顺序描述用例的测试步骤，每一个步骤都应该清晰明了，简单易懂。
步骤应该具有可执行性，即可以直接在自动化测试框架中执行。
5. 预期结果：描述每一个测试步骤的预期结果，即用例执行后的期望结果。
预期结果应该具体、明确，以便与实际结果进行对照。
6. 附件：如果用例需要附带一些额外的文件或者数据，应在用例中明确指出，并提供相应的附件。
7. 备注：用于记录一些额外的说明或者备注信息，如用例的优先级、相关的bug编号等。
三、命名规范1. 用例文件命名：用例文件应该以模块名称或者功能名称作为前缀，以便于组织和检索。
文件名应该使用小写字母，多个单词之间使用下划线分隔，例如“login_test_cases.py”。
2. 用例函数命名：用例函数应该以“test_”作为前缀，后面跟上具体的功能或者操作。
函数名应该使用小写字母，多个单词之间使用下划线分隔，例如“test_login_success”。
3. 用例类命名：如果用例需要组织成类的形式，类名应该使用大写字母开头的驼峰命名法，例如“LoginPageTest”。
4. 用例变量命名：用例中的变量名应该使用小写字母，多个单词之间使用下划线分隔，例如“username”、“password”。
四、结构规范1. 模块划分：根据系统的功能或者模块进行用例的划分，每一个模块对应一个用例文件。
测试用例编写规范
测试用例编写规范
（一）测试用例命名规则
以功能模块和业务流程进行命名。
（二）用例编号规则
以测试模块名称的第一个字母进行命名（大写），若测试模块名称比较长是，可进行简写。
一般简拼不超过5各字母。
如：
1.测试模块为“用户管理”，功能编号为“YHGL”
2.测试模块为“行政单位管理”，功能编号为“DWGL”
3.功能编号规则直接以001、002、003
（三）测试用例文档书写内容
1.被测试对象的介绍
2.测试范围与目的
3.测试环境与测试辅助工具的描述
4.功能测试用例主要元素
（四）前置/操作描述
1.前置条件（可选）：系统权限配置或前、后台配置描述（所有进行操作的前提条件）。
2.操作：测试的操作步骤描述。
（五）功能点
功能点描述
（六）输入数据
前期数据准备
（七）预期结果
描述输入数据后程序应该输出的结果
（八）测试结果
描述本条用例的实际测试情况，并判断实际测试结果与预期结果的差别。
（九）Bug编号/Bug简要描述：
需要进流程的对应事物流程的编号，及简要说明。
（十）备注
测试过程中遇到的问题等情况说明。
测试用例编写规范
测试用例编写规范一、测试用例编写准备从配置管理员处申请软件配置：《需求规格说明书》和《设计说明书》；根据需求规格说明书和设计说明书，详细理解用户的真正需求，并且对软件所实现的功能已经准确理解，然后着手制订测试用例。
二、测试用例制定的原则测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。
测试数据应该选用少量、高效的测试数据进行尽可能完备的测试；基本目标是：设计一组发现某个错误或某类错误的测试数据，测试用例应覆盖方面：1、正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。
2、容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出，输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理。
把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。
3、完整（安全）性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。
4、接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。
5、数据库测试：依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。
6、边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。
7、压力测试：输入10条记录运行各个功能，输入30条记录运行，输入50条记录运行。
进行测试。
8、等价划分：将所有可能的输入数据（有效的和无效的）划分成若干个等价类。
9、错误推测：主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。
10、效率：完成预定的功能，系统的运行时间（主要是针对数据库而言）。
11、可理解（操作）性：理解和使用该系统的难易程度（界面友好性）。
测试用例规范
测试用例规范测试用例规范是指在软件测试过程中对测试用例进行规范化的描述。
它包括用例编号、用例名称、前置条件、测试步骤、预期结果、实际结果、测试结果等内容，旨在提高测试用例的可读性和可维护性，提高测试效率和质量。
一、用例编号用例编号是对测试用例进行唯一标识的编号，通常由字母和数字组成。
编号的命名应该具有唯一性和规律性，便于查找和管理。
二、用例名称用例名称是对测试用例进行简洁明了的描述，以便于测试人员快速了解用例的功能和目的。
三、前置条件前置条件是指执行测试用例之前需要满足的条件或准备工作。
这些条件可以是软件环境、硬件环境等。
四、测试步骤测试步骤是对测试用例具体操作的描述，包括输入数据、操作步骤和操作环境等。
五、预期结果预期结果是在执行测试步骤后期望得到的结果，通常是软件的输出、显示或状态改变等。
六、实际结果实际结果是在执行测试步骤后实际观察到的结果，可以与预期结果进行对比，以判断测试是否通过。
七、测试结果测试结果是根据实际结果对测试用例进行评估的结果，通常包括“通过”、“失败”和“阻塞”等。
八、补充说明补充说明是对测试用例中一些特殊情况或要求的描述，包括限制条件、特殊操作和预期行为等。
九、用例状态用例状态是指用例的执行状态，可以是“未执行”、“执行中”和“已执行”等。
十、用例设计人员用例设计人员是指负责设计和编写该用例的测试人员，有助于追溯和沟通。
以上是测试用例规范的主要内容，通过规范化的测试用例描述，可以提高测试效率和质量，减少测试人员之间的沟通成本，便于测试管理和追溯。
在实际测试过程中，应根据项目需求和实际情况进行适当的调整和优化。
pytest写法
pytest写法Pytest是一种灵活的测试框架，适用于Python应用程序，允许用户编写简单、可扩展的测试用例。
以下是一些编写Pytest测试用例的规范写法：1. 测试文件命名：测试文件应以“test_”开头，以便Pytest能够识别并执行它。
例如，可以命名为“test_example.py”。
2. 测试类：如果需要编写多个测试用例，可以将它们组织到一个测试类中。
测试类必须以“Test”开头，并且不能包含__init__方法。
每个测试用例应该是一个以“test_”开头的方法。
例如：```pythonimport pytestclass TestExample:def test_example1(self):assert 1 + 1 == 2def test_example2(self):assert "hello".startswith("h")```3. 断言：在Pytest中，断言使用assert关键字实现。
断言用于比较实际结果与预期结果，如果它们不相等，则断言失败。
例如：```pythondef test_addition(self):result = 1 + 1assert result == 2```4. 参数化：Pytest支持参数化测试，这意味着可以使用不同的输入值多次运行相同的测试用例。
可以使用@pytest.mark.parametrize装饰器实现参数化测试。
例如：```pythonimport pytest@pytest.mark.parametrize("input, expected", [(1, 2), (2, 3), (3, 4)])def test_addition(input, expected):assert input + 1 == expected```5. Fixture：Fixture是Pytest中用于设置和清理测试环境的机制。
测试用例编写规范
测试⽤例编写规范1 ⽬的测试⽤例是测试⼈员执⾏测试的基本依据，因此测试⽤例质量的⾼低直接影响测试的有效性和效率。
为了保证测试执⾏⼈员使⽤最有效的测试⽤例，使测试⼯作能有序、合理化的进⾏，从⽽提⾼实施测试时对所测产品、系统或者模块的测试质量，最终提⾼仁科互动公司产品线的质量。
特编写统⼀测试⽤例编写规范，为测试设计⼈员提供测试⽤例设计编写指导，提⾼编写⽤例的可读性、可执⾏性、合理性。
2 ⽤途适⽤于对各业务线测试⼈员对功能测试⽤例和接⼝测试⽤例的编写。
3 ⽤例设计流程测试分析：进⾏测试⽤例编写的前提。
测试⼈员根据产品部门提供的PRD、⽤户故事以及研发部提供的设计⽂档进⾏测试需求分析，找出明显的和隐含的需求。
有些需求⽆法从需求⽂档中获得，可借助概要设计⽂档或者详细设计⽂档，或直接从最终的软件产品上获得。
测试设计：依据测试分析整理并编写出测试⽤例⼤纲，并将测试⼤纲细化为测试⽤例。
测试⽤例⼤纲⽤脑图的形式进⾏管理，在时间受限的情况下，测试⽤例评审对象是脑图，详细测试⽤例会抽取⼀些作为附加评审对象。
参加的⼈员应包括测试负责⼈、项⽬经理、开发⼈员及其他相关的测试⼈员。
测试⽤例完善：测试⽤例编写完成之后需不断完善，软件产品新增功能或更新需求后，测试⽤例必须定期修改更新；在测试过程中发现设计测试⽤例时考虑不周，需要对测试⽤例进⾏修改完善；产品上线后客户反馈的软件缺陷，⽽缺陷⼜是因测试⽤例存在漏洞造成，也需要对测试⽤例进⾏完善。
任何测试⽤例的新增和更新均需要经过评审流程。
4 规范要求4.1 测试⽤例整体要求• 测试⽤例编写应严格根据PRD、⽤户故事及测试需求功能分析点进⾏，要求覆盖全部需求功能点• 测试⽤例编写应该制订统⼀的模板进⾏，并约定模板的使⽤⽅法• 测试⽤例中要写清楚测试的操作步骤和预期结果，能被不同测试⼈员理解和执⾏• 测试⽤例中要明确⼀级模块、⼆级模块和三级功能• 同⼀个功能点的测试⽤例，移动端和PC端需要单独编写，因为它们的界⾯和操作不同• 界⾯显⽰、错误信息提⽰、⽤户界⾯友好性等界⾯相关检查暂不作为测试范围，由UI/UE部门负责验收• 注重测试⽤例的可复⽤性，即在以后相似系统的测试过程中可以重复使⽤• 测试⽤例编写和评审都⽤Excel表格，评审通过后的测试⽤例导⼊testLink系统4.2 测试⽤例组成部分⼀般的测试⽤例包括如下组成部分：需求标识、⽤例标识、⽤例标题、摘要、重要性、前提条件、操作步骤、预期结果、⽤例编写者、状态、预期执⾏耗时、测试⽅式。
测试用例编写规范
测试⽤例编写规范⽬录：⼀.测试⽤例包含的元素⼆.测试⽤例编写原则及规范1. ⽤例模块划分规范2. ⽤例颗粒度划分规范3. ⽤例编写要求规范4. ⽤例维护规范三.测试⽤例编号规则⼀.测试⽤例包含的元素1. 序号：就是按顺序下去的。
2. 模块：该功能点具体属于哪个模块的，如：注册/登录模块3. 编号：对每个⽤例进⾏编号，⽅便后期跟进。
建议编号设计的有点规则，⽅便快速定位查找。
如：A0001。
其中A表⽰注册/登录模块。
00表⽰账号登录，01 表⽰账号密码登录下的第⼀个测试⽤例。
4. 功能点：具体指某个功能，如：账号登录、⾸页、发布等。
5. ⼦功能点：具体指功能点，如：账号密码登录、⼿机验证码登录、邮箱登录、第三⽅授权登录等。
6. ⽤例名称：具体测试⽤例的名称。
如：输⼊账号、输⼊密码、密码不合规等等。
7. 前置条件：指要达到预期测试结果，需要满⾜哪些条件才能达到。
8. 操作步骤：指要达到预期测试结果，需要按这些步骤来。
最好说明在什么页⾯，点击或操作什么内容，输⼊什么内容。
9. 预期结果：说明按照前⾯写的应该呈现出怎样的结果。
10. 测试结果：如果符合预期结果，直接填写正常或OK，如果不符合，则说明不符合或NO，11. 结果描述：如果正常，可以不⽤填写，如果不符合预期结果，则说明哪⾥不符合。
12. 测试⼈员：填写测试⼈的名字，⽅便后期跟踪BUG。
13. 测试⽇期：填写测试的时间，⽅便后期查询。
14. BUGID：跟测试编号⼀样，⾃⼰设定ID规则，⽅便快速查询。
15. BUG负责⼈：此处应该由技术那边填写，具体落实到某个⼈⾝上，才能更好的解决到问题。
⼆.测试⽤例编写原则及规范统⼀测试⽤例编写的规范，为测试设计⼈员提供测试⽤例编写的指导，提⾼编写的测试⽤例的可读性，可执⾏性、合理性。
测试⽤例，不仅仅⽤于QA阅读和执⾏。
它们也可能会被开发、PD、PM等阅读审查或执⾏；也更可能被其他测试⼈员或者新员⼯作为业务学习、测试执⾏的参照。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
测试用例编写规范变更历史引言1.背景为保证测试用例对需求的覆盖率，即对一个系统从整体功能到单个功能，都尽可能的高的覆盖。
而单个功能点主要强调的是不同的输入及其组合所带来的各种输入动作，系统是否都做了处理；测试用例设计首先要明确该系统存在多少功能点，要通过各种常用的测试方法来保证用例的完整性，然后再对各功能点的边界范围进行考虑。
所以要保证测试用例的设计按照一种合理的结构组织进行，这样才能够更有效的保证系统所有功能点的覆盖率。
2.目的为测试用例的质量负责，使测试工作能有序、合理化的进行，从而提高实施测试时对所测产品、系统或者模块的测试质量，也是作为各测试人员在设计用例时的一种规范，使之设计的用例能有效的被管理。
3.概念是指为了实施测试而编写的一组有规范性、有据可依的输入数据与输出数据的组合，也指为了实施测试而向被测对象提供的一组输入、输出数据以及由各种执行条件和期望结果相组合的一个特定集合，以便测试某个程序路径或者来核实是否满足某个特定的需求。
4.适用范围本文档适用于测试人员本文档适用于系统进行测试时的测试案例设计本文档适用于案例补充时的测试案例用例规范用途特导江试工绘有壬亠实富対试为数畀勾抿可依确喂环实現曲項能与客户烈範的需丈观舛合完善软件不同版本之间的重复性测试跟踪测试进度，确定测试重点评估测试结果的度量标准增强软件的可信任度分析缺陷的标准。
设计依据需疽说阴书忑E淀试爵求功能恵所属行业的业务知识掌握程度测试工程师本人的理解程度（个人经验）用例内容编写用例原则系统性：对系统业务流程要完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系；对模块业务流程要说明子系统内部功能、重点功能以及它们之间的关系连贯性：对系统业务流程要说明各个子系统之间是如何连接在一起，若需要接口，各子系统之间是否有正确的接口，若是依靠页面链接，则页面的链接是否正确；对模块业务流程要说明同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯全面性：应尽可能覆盖各种路径、尽可能覆盖各个业务点，并要考虑跨年、跨月的数据以及大数据量并发测试的准备正确性：输入界面后的数据应与测试文档所记录的数据一致，而预期结果也应与测试数据发生的业务吻合符合正常业务规则：测试数据要符合用户实际工作中的业务流程，同时也要兼顾各种业务的变化以及当前该业务行业的法律、法规、人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例；不允许出现与知名人士、小说中人物名等雷同情况。
可操作性：测试用例中要写清楚测试的操作步骤，以及不同的操作步骤相对应的测试结果编写用例标准测试案例编写应该制订统一的模板进行，并约定模板的使用方法；测试案例编写应当根据项目实际情况编写测试案例编写手册，包括案例编号规则、案例编写方法、案例编写内容、案例维护等内容；案例编写应根据手册中约定的编写方法、内容等进行编写；案例编写要步骤明确，输入输出要素清晰，并且与需求和缺陷相对应；案例编写应严格根据需求规格说明书及测试需求功能分析点进行，要求覆盖全部需求功能点；注重案例的可复用性，即在以后相似系统的测试过程中可以重复使用，减少测试设计工作量。
用例设计步骤测试需求分析：从软件需求分析文档中，找出待测软件/ 模块的需求，通过自己的分析、理解，整理成为测试需求，要清楚被测对象具体包含哪些功能点。
业务流程分析：对所在行业的业务知识要熟悉，然后对被测软件/ 模块的业务流程要进行全盘的整理出来（可画简单的流程图作为参考），主要包含该业务流程的主流程、备选流程、数据流向、关键判断条件以及完成该操作的非必要条件。
测试用例设计：测试用例设计的类型主要包括功能测试、边界测试、异常测试、性能测试、压力测试等，在设计用例时要尽量考虑边界、异常等情况。
测试用例评审：由测试用例设计者发起，参加的人员需包括测试负责人、项目经理、开发人员及其他相关的测试人员。
测试用例完善：测试用例编写完成之后需不断完善，软件产品新增功能或更新需求后，测试用例必须配套修改更新；在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善；用例级别划分P0:确保系统基本功能及主要功能的测试用例P1 :确保系统功能的完善方面的测试用例P2:关于用户体验，输入输出的验证；较少使用或辅助功能的测试用例。
P0 （优先执行）：即关键路径的测试用例，包括最常执行的功能、基本流程的输入以及界面数据有效性校验作为高级别的测试用例；若该级别的测试用例完全执行通过，则表示该软件功能渐趋稳定；P1 （次级执行）：即可接收级测试的用例，包括不常执行的功能、异常流程的输入、边界值以及异常数据的输入作为中等级别的测试用例；若该级别的测试用例完全执行通过，则表示该软件可以进行发布了；P2 （最后执行）：即建议执行的测试用例，也就是说该级别的测试用例不是不重要，而是该级别的用例在整个项目的生命周期内不是常常被运行，包括：GUI、界面显示、错误信息提示不统一、可用性、压力和性能测试等。
备注：对已有的用例级别说明，包括A-正常流程测试、B-异常流程测试、C-页面元素正常输入测试、D-页面元素异常输入测试、E-页面元素显示测试，可具体归类如下（仅供参考）：P0：A-正常流程测试、C-页面元素正常输入测试P1：B-异常流程测试、D-页面元素异常输入测试P2：E-页面元素显示测试用例的维护删除过时的测试用例因为需求的改变等原因可能会使一个基线测试用例不再适合被测系统，那么这些测试用例就会过时，需要对这些测试用例进行及时的删除，在删除过程中，不能够将整行的测试用例删除，应该将要删除的测试用例整行置灰，并将该行的用例计数器清为空；当整个功能模块需要删除时，则将整个SHEET犬态置灰，并将用例计数器清空修改的测试用例随着软件项目的进展，测试需求可能会有部分变更，甚至大范围的变更，这个时候我们就会根据需求的变化相应的对测试用例进行维护，修改已经不符合目前需求的内容，并在备注栏中加以说明删除冗余的测试用例如果存在两个或更多测试用例对一组相同的输入和输入进行测试，则需要对其进行删除，只需留下其中的一个增添新的测试用例对新增的功能、在评审过程及测试过程中发现缺少测试用例或者系统出现BUG 但是没有与之对应的测试用例，需要按照测试用例的设计标准进行增添，增加测试用例时，需要在相应功能模块的最下方插入新增的测试用例，并在备注栏中加以说明用例设计方法测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。
测试数据应该选用少量、高效的测试数据进行尽可能完备的测试；基本目标是：设计一组发现某个错误或某类错误的测试数据，测试用例应覆盖方面：等价划分：将所有可能的输入数据（有效的和无效的）划分成若干个等价类。
边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值）针对我们的系统在测试过程中主要输入一些合法数据/ 非法数据，主要在边界值附近选取。
场景法：通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。
用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。
基本流：是经过用例的最简单的路径（无任何差错，程序从开始直接执行到结束）备选流：一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中，也可以起源于另一个备选流，或终止用例，不在加入到基本流中；（各种错误情况）因果图：利用图解法分析输入的各种组合情况，设计测试用例，检查程序输入条件的各种组合情况。
正交表：在界面中有多个控件，控件之间有多种组合关系，如果组合的数量巨大（一般超过20 种），没有必要将所有组合都测试，可以通过正交排列法将组合中最优，最少的组合进行测试。
正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。
容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出；输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理。
把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。
完整（安全）性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。
接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。
数据库测试：依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。
压力测试：输入10 条记录运行各个功能，输入30 条记录运行，输入50 条记录运行，进行测试。
错误推测：主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。
效率：完成预定的功能，系统的运行时间（主要是针对数据库而言）。
可理解（操作）性：理解和使用该系统的难易程度（界面友好性）。
可移植性：在不同操作系统及硬件配置情况下的运行性。
回归测试：按照测试用例将所有的测试点测试完毕，测试中发现的问题开发人员。
比较测试：将已经发版的类似产品或原有的老产品与测试的产品同时运行比较，或与已往的测试结果比较。
兼容性测试：操作系统的兼容性测试内容不仅包括软件的安装，还需对关键流程和功能点进行检查。
而需要测试哪些操作系统的兼容性，首先取决于软件用户文档上对用户的承诺，其次就需要对一些常用操作系统兼容的检查历史版本兼容性测试：某些功能存在新版本和历史版本数据显示、页面展示不一致的问题。
需要不同版本进行测试。
用例评审评审原因测试用例是软件测试的原则，但由于软件人员对在需求理解、设计等理解程度不同等因素的影响，首次产生的测试用例质量难以避免会有不同程度的差异，故对编写的测试用例进行评审是很有必要的，其作用是测试用例的评审过程能够起到用例结构清晰化、场景覆盖全面化以及优先用例的合理化安排等。
评审内容用例设计的结构安排是否清晰合理，是否高效的需求进行覆盖用例的优先级别是否安排合理是否覆盖了测试需求的所有功能点，包括需求中的业务规则、所有用户可能使用的流程或场景等用例是否有很好的可执行性。
例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确是否已经删除了冗余的测试用例是否包含充分的负面测试用例是否简洁、复用性强、是否易于管理评审过程基于项目需求的测试计划完成之后，进行初审，主要是对测试范围和测试要点进行审查在测试用例的设计完成之后进行复审，主要是对测试用例的结构和覆盖率进行评审所有测试用例结束后，主要是对测试用例的具体描述是否有很好的可执行性，是否有冗余用例的存在进行评审评审人员部门评审：测试部全体成员参与的评审项目评审：项目组全体测试人员与部分开发人员、产品人员等组成的小组内部评审：全部参与测试的人员评审方式会议评审（包括内部评审及客户评审）。