软件测试流程和测试规范标准文档
1、目的
通过制定公司测试流程规范，确保测试工作的规范性和有效性，以保证软件产品的质量满足用户的需求。测试作为质量控制的一种有效手段，运行测试用例找出软件中潜在的各种缺陷，通过协助开发人员修正缺陷来提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患和降低质量成本。通过测试管理为产品与过程改进提供可靠的数据分析，起到缺陷预防的作用。2、工作范围
2、工作范围
测试人员在软件开发过程中的任务：
1.与评审需求，评审通过后，编写测试计划；
2.根据根据用户需求相关的产品需求说明文档、原型设计文档、交互视觉设计文档、开发设计文档，编写软件测试用例；
3.在开发人员完成单元测试后，进行集成测试，尽早发现bug；
4.根据软件测试用例，执行功能测试，寻找尽可能多的bug；
5.对bug进行追踪与分析，保证bug及时得到修复；
6.对软件质量进行衡量，并进行测试总结，提交软件测试报告书
3、测试方法制定阶段
1兼容性测试 --测试人员
兼容性测试是指测试软件是否可以成功移植到指定的硬件或者软件环境中，如在win10环境下可以运行，在win7环境下是否也可以正常运行。
2用户界面测试-UI测试 --测试人员
用户界面测试是指测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字，图片组合是否完美，操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。
.3.随机测试
随机测试没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。
随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试样例 没有覆盖到的部分。另外，对于软件更新和新增加的功能要重点测试。重点对一些bug所在的模块进行测试。可以结合回归测试一起进行
4.功能测试 软件测试人员以用户的角度，通过各种输入和观察软件的各种输出结果来发现软件存在的缺陷，而不关心程序具体如何实现的一种软件测试方法。如：登录功能测试,主要输入正确的账号和密码或错误的账号密码验证是否能登录成功
4、测试方法制定阶段
在测试用例库中导入和版本有关的全部测试用例
按软件的功能顺序分布依次测试
注册模块：验证注册的邮箱或号码是否有效、验证码是否有效、验证码是能正常获取、密码是否按需求限制、使用条款是否勾选、注册成功后是否能正常登录
登录模块：账号密码不正确是否能登录、密码能否显示、是否能记住密码
忘记密码模块：验证码能否正常收发、密码是否按需求限制、修改过后新密码能否正常登录
首页模块：各个列表的服务器信息是否能正常显示、收藏功能是否正常、线路在各种网络环境下是否可以连接、服务器连接之后是否起到作用、服务器连接断开是否正常、线路收索功能是否能正常搜索、协议切换是否正常、协议作用是否发挥出来
购买模块：套餐是否可以正常购买、付费用户是否可以购买别的套餐、退款用户能否直接购买、支付页面是否可以正常的跳转
用户信息模块：手机号码&邮箱号码是否可以正常绑定或更换、是否可以绑定或更换成无效的手机号码&邮箱、密码更换是否按需求限制弹出
其他模块：页面显示是否清晰、链接跳转是否正常、消息弹窗是否能正常
版本迭代新增模块：按需求文档以及更新的测试用例测试进行重点测试
5、测试用例的基本要素
确保测试用例的目标明确，全面覆盖系统的不同场景，包括正面（有效输入）、负面（无效输入）、边界情况、异常处理，明确测试用例的输入数据，并预期输出结果。确保输入数据能充分验证功能的正确性，并且输出结果是可验证的。注意测试边界条件，如数组长度、数值上下限。验证系统在异常情况下的表现，例如输入非法数据、网络连接中断、资源不可用。
1. 清晰和简洁
标题：简明扼要地描述测试的目标。
描述：清楚地解释测试用例的目的和期望的行为。
步骤：明确列出每个操作步骤，使执行者能够轻松理解和操作。
2. 可重复性
测试用例应能够在不同的环境和时间点被重复执行，结果应当一致，前提是环境条件一致。
3. 可追溯性
每个测试用例应与特定的需求或功能相对应，能够追溯到其测试的需求或用户故事，确保所有功能都得到验证。
4. 独立性
测试用例应独立于其他用例。一个用例的执行不应依赖于其他用例的执行顺序或结果。
5. 明确的预期结果
测试用例应明确描述每个步骤的预期结果，帮助测试执行者快速识别问题。
6. 覆盖性
测试用例应涵盖系统的所有功能和业务流程，包括正面测试（功能按预期工作）和负面测试（不符合条件的情况）。
7. 适应性
测试用例应能够适应软件的变化，如功能改动或用户界面调整。设计良好的测试用例可以减少维护成本。
8. 可执行性
测试用例必须是可以执行的，应避免复杂的逻辑和假设，让测试人员能够轻松执行。
9. 测试数据
测试用例应定义所需的测试数据，包括有效数据和无效数据，确保所有情况都能被验证。
10. 结果判断标准
定义清晰的通过或失败标准，确保测试人员能够轻松判定测试用例的结果。
11. 优先级和分类
为测试用例指定优先级（高、中、低）和分类（功能测试、性能测试、安全性测试等），以便更好地组织和执行测试计划。
12. 适当的测试环境
描述测试用例应在何种环境下执行（如开发环境、测试环境、生产环境），确保测试结果的可靠性。
13. 记录实际结果
为每个测试用例提供记录实际测试结果的地方，以便与预期结果进行对比。
14. 文档化
测试用例应包括版本信息、创建日期、修改日期、作者等文档化信息，以便于版本管理和维护
示例测试用例结构：
用例编号：TC001
标题：用户登录功能测试
描述：验证用户是否能够使用正确的凭据登录系统。
前置条件：用户已在系统中注册，并记住了登录凭据。
测试步骤：
打开登录页面。
输入有效的用户名和密码。
点击登录按钮。
预期结果：用户成功登录，并重定向到主页。
实际结果：待填写（在测试执行时填写）。
优先级：高
环境：测试环境
通过以上标准，可以确保测试用例的质量，提高测试的有效性和可靠性。如果需要更具体的标准或模板，可以根据实际项目需求进一步细化。
6、用例总体规范
测试用例是为特定目的而设计的一组测试输入、执行条件和预期结果。设计测试用例不能只凭借一些主观或直观的想法，应该要以成熟的测试规范为指导，设计出风格一致、用词一致、精确、简洁、易懂、易确认的测试用例，减少测试用例理解偏差及用例管理成本，提升测试效率及质量；测试用例之间也需保持相互独立，不要依赖其他用例。
1、用例名称应体现测试用例的测试目的或测试点。
2、用例描述是对用例的额外说明。
3、前置条件是执行测试用例需要的“前提条件”，是测试步骤的先决条件。可以写需要的环境说明、参数设置、测试场景等。具有前置测试条件的测试步骤都应该归入“前置条件”进行描述，前置条件中的步骤并不关注其结果的验证，默认任务必须满足预期条件的要求方可开展用例步骤的测试。
4、测试步骤是对测试的“动作”描述，应简要客观地描述测试所需的实际操作。
5、预期结果是该测试用例针对对应检查点的描述。
7、测试用例书写规范
1、
测试用例编号 ：测试用例的唯一标记
用例标题 ：概述测试用例的主要内容，明确该测试用例的意图
预置条件 ：测试用例顺利执行的前提条件，如一些基本的配置
测试数据 ：测试时使用的测试数据
测试步骤 ：如何执行这个测试用例，每步的操作是什么
预期结果 ：和测试步骤对应起来，操作后希望系统的返回
测试用例标题不要超过30个汉字。
测试步骤不要多于7步，不要少于2步。
预期结果不要多于5个，不要少于1个。
2、测试用例标题要是一个完整的句子
在怎样的条件下， 谁 做了 怎样的事情， 得到了怎样的结果
状语 主语 谓语 宾语 补语（可选）
3、用条件而不是参数来描述测试用例标题
在描述测试用例标题时，更适合用条件，而不是参数。参数更适合在测试用例模板中的测试数据部分体现，不要把它们罗列在测试用例标题中。
4、如果一个用例中包含有多个参数，用例中应该是每个参数的取值
一个测试条件，可能会有多个参数，这些参数又可能会取不同的值。我们在写测试用例的时候，应该对涉及的每个参数给出确定的值。
假设一个测试条件包含3个参数，参数1有三个参数值（A1、A2、A3），参数2有两个参数值（B1、B2），参数3有四个参数值（C1、C2、C3、C4）。写测试用例的时候，测试数据应该是参数1、参数2、参数3分别取一个确定的值来构成的参数组。
5、不要在测试用例中引用别的测试用例
在编写测试用例时，不宜在测试步骤中又引用别的测试用例。
解决方法1：把测试用例1和测试用例2合并成一个大的测试用例
解决方法2：把测试用例1的主要内容总结概述，放到测试用例2的预置条件中
方法1比较适合测试用例1和测试用例2都比较简单的情况，相对来说方法2更通用一些。
6、避免测试用例中包含过多的用户接口细节
执行用例者应该是专业人士，测试用例不必写得面面俱到。过多的细节使得测试执行者无法抓住用例执行步骤的重点，而且一旦产品在细节的设计上有所变化，测试用例也需要修改，不利于测试用例的后期维护。所以用例步骤最好是对系统操作的概括描述，无须叙述所有细节。
7、明确测试步骤和预期结果的对应关系
一个测试用例通常会包含好几个测试步骤和多个预期结果。有时候不同的测试步骤可能会有相同的预期结果，为了描述简便，很多测试用例作者会省略相同的预期结果。另外，也不是所有的测试步骤都有预期结果，一般是重要、关键的测试步骤才会有预期结果。这时我们可以在测试用例中，增加简单的标记（如[check n]）来明确测试步骤和预期结果之间的对应关系，让测试执行人员一目了然。
测试用例没有必要写得面面俱到，非常细致，而应该简洁无歧义，突出测试用例的目的，描述清楚关键的步骤和检查点即可。好的测试用例，通过阅读标题，就能清楚地知道这个用例的测试目的。和测试目的密切相关的步骤才会放在测试步骤中，那些基础的操作步骤则是简洁地放在预置条件中，使得执行者能够快速抓住测试的重点，并且预期结果应该是清楚准确、没有歧义的。
8、避免在测试步骤中使用笼统的词
笼统的词如反复、长时间、大量等。因为这样的描述，不同的测试执行者的理解会有所不同。
8、测试用例实现规则
规则1：用例描述要求
每个用例必需要有至少一条操作步骤和预期结果；
操作步骤描述清晰。如：在什么页面，点击什么链接或按钮；页面入口、链接、按钮名称都要写清楚；
操作步骤中不要包含结果的检查；
预期结果中只能包含结果，不能有步骤；
用例描述中不允许出现假设性词汇，比如：假如，或许，可能等；
用例描述中不允许出现二义性语句。
用例命名格式：模块_用例标题；
用例名称不允许出现重复、包含关系，或者仅有数字编号差异；
用例名称简介易懂，不要包括具体操作步骤；
规则2：用例名称要求
规则3：用例要素要求
用例标识、用例标题、摘要、重要性、操作步骤、预期结果、用例编写者、状态、预期执行耗时为必填内容，不能为空，其他字段为选填内容。
规则4：用例重要性要求
由于User Story的优先级决定的是在一个版本中的开发优先级，用例的重要性参考的是模块对于系统功能的重要度，因此这里的重要性不以Use Story优先级为参考依据。
高（优先执行）：产品基本的功能验证，即关键路径的测试用例，包括最常执行的功能、基本流程的输入（正向流程+正向数据）。
中（次级执行）：包括界面数据有效性校验、默认值、边界值。
低（最后执行）：建议执行的测试用例，包括不常执行的功能、异常流程的输入以及异常数据的输入。
执行用例测试步骤前需要做的所有必备条件，原则上所有用例都有前置条件；
前提条件包括测试执行入口、账号类型和权限、数据准备；
不可将其他用例作为前置条件，但可以将其它用例执行结果作为前置条件。
每一测试步骤只能对应一条预期结果；
每一条预期结果与其对应的测试步骤的编号要求保持一致；
一个结果有多个检查点时，确保检查点完整；
规则5：用例执行前提要求
规则6：测试步骤与预期结果要求
ü 结果含需要验证的所有结果输出，如页面检查、存储检查、消息检查等；
ü 结果涉及页面，需明确页面提示结果、数据变化；
ü 结果涉及存储：需明确关键值变化、数据库具体的表和关键字字段值变化；
ü 结果涉及消息：需明确关键查看内容；
ü 结果对应不同输入数据有差别时需分别对应描述清晰。
规则7：测试数据要求
ü 测试数据在步骤里面明确列出
ü 测试数据编写形式为：[字段名：字段值]
ü 对于页面输入数据，需要区分系统字段与自定义字段
5 用例设计方法
5.1 等价类划分
把全部输入数据合理地划分成若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据取得较好的测试结果。等价类划分有两种不同的情况：有效等价类和无效等价类。
5.2 边界值测试
大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。
5.3 错误推测
基于经验和直觉推测程序中所有可能存在的各种错误，有针对性地设计测试用例的方法。
5.4 分类树
分类树方法是在软件功能测试方面一种有效的测试方法，通过分类树把测试对象的整个输入域分割成独立的类。按照分类树方法，测试对象的输入域被认为是由各种不同的方面组成并且都与测试相关。对于每个方面，分离和组成各种类别，而分类结果的各类又可能再进一步地被分类。这种通过对输入域进行层梯式的分类表现为树状结构。随后，通过组合各种不同分类的结果来形成测试用例。
5.5 常用功能测试点
检查类型
检查点
输入数据设计
边界值，边界值+1，边界值-1
最大个数，最大个数+1，最小个数，最小个数-1
空值、空表
极限值
0值，负数，非法字符
日期、时间控制
跨年度数据
数据格式
数据之间的关联性、逻辑性
计算方式以及计算结果准确性，数字精度的取舍问题，汇总数据与分项数据累加的误差问题
常用的较验
字段长度较验
必输项校验
重名校验
字符类型较验
标点符号检查
中文字符处理
按键处理
浏览器前进后退
常用快捷键检查
回车键检查
默认值
文本框
单选框
多选框
下拉列表
界面检查
只读项
文字拼写
字体
页面跳转
按钮功能