1、 xx 公司测试流程及规范xx 限公司2017 年 9 月测试流程及规范I版本历史版本/状态 作者 参与者 起止日期 备注1.0 xx 2017-09-07测试流程及规范II目 录XX 公司 测试流程及规范 .1版本历史 .I目 录 .II1. 目的 .12. 测试流程介绍 .12.1. 产品验收前 .12.2. 产品验收后 .23. 编写测试用例的方法 .23.1. 等价类划分 .23.2. 边界值分析法 .33.3. 错误推测法 .33.3.1. 因果图分析 .34. 测试方法 .44.1. 黑盒测试（功能测试） .44.2. 用户界面测试-UI 测试 .44.3. 随机测试 .44.4.
2、 性能测试 .54.5. 测试 此方法针对的是非程序员和测试 .55. 缺陷等级划分 .55.1. 产品验收前定义 .55.2. 产品验收后定义 .66. 缺陷报告 .7测试流程及规范第 1 页 / 共 6 页1. 目的编写此文档是为了规范本公司的测试流程，为快速、高效和高质量软件测试提供基础流程框架。提高测试人员自身测试能力，使测试更加规范化和标准化。2. 测试流程介绍2.1. 产品验收前需求分析书提取测试需求设计测试用例搭建测试环境进行功能点测试进行系统测试提交 BUG追踪 BUG回归测试关闭 BUG测试流程及规范第 2 页 / 共 6 页2.2. 产品验收后3. 编写测试用例的方法3.1
3、. 等价类划分等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试。因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据取得较好的测试结果。等价类划分可有两种不同的情况：有效等价类和无效等价类。现场反馈 BUGBUG 生效提交禅道指派研发BUG 解决进行回归确认后关闭 BUG测试流程及规范第 3 页 / 共 6 页3.2. 边界值分析法边界值分析方法是对等价类划分方法的补充。大量的错误是发生在输入或输出范围的边界上，而不是发生在输入
4、输出范围的内部.因此针对各种边界情况设计测试用例, 可以查出更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况.通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。3.3. 错误推测法基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。错误推测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。例如，在单元测试时曾列出的许多在模块中常见的错误。以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数
5、据和输出数据为0 的情况。输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。3.3.1. 因果图分析前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系，相互组合等。考虑输入条件之间的相互组合，可能会产生一些新的情况。但要检查输入条件的组合不是一件容易的事情，即使把所有输入条件划分成等价类，他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图（逻辑模型）。因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况
6、。测试流程及规范第 4 页 / 共 6 页4. 测试方法基于公司的具体情况，介绍一下几种测试方法。4.1. 黑盒测试（功能测试）黑盒测试是根据软件的规格对软件进行的测试，这类测试不考虑软件内部的运作原理，因此软件对用户来说就像一个黑盒子。 软件测试人员以用户的角度，通过各种输入和观察软件的各种输出结果来发现软件存在的缺陷，而不关心程序具体如何实现的一种软件测试方法。4.2. 用户界面测试-UI 测试用户界面，英文是 User interface。是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。 用户界面测试是指测试用户界面的风格是否满足客户要求，文字是否正确，页面
7、是否美观，文字，图 片组合是否完美，操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性 测试。 用户界面测试用户分析软件用户界面的设计是否合乎用户期望或要求。它常常包括菜单，对话框及对 话框上所有按钮，文字，出错提示，帮助信息 (Menu 和 Help content)等方面的测试。比如，测试 Microsoft Excel 中插入符号功能所用的对话框的大小，所有按钮是否对齐，字符串字体大小，出错信息内容和字体大小，工具栏位置/图标等等。个人认为从目前来看，公司测试和开发不重视
8、这块的测试和修改。一个好的软件不止是功能完全正确，更为重要的就是有一个好的视觉效果，从用户角度来说功能相似的软件很多，但是界面舒畅，易用性高的软件使用率更好，尤其我们的客户是面向大众的，更应该重视界面测试。4.3. 随机测试随机测试没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。 随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试样例 (TestCase)没有覆盖到的部分。另外，对于软件更新和新增加的功能要重点测试。重点测试
9、流程及规范第 5 页 / 共 6 页对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其 对以前测试发现的重大Bug，进行再次测试，可以结合回归测试。这个方法也是使用率比较高的。4.4. 性能测试性能测试是在交替进行负荷和强迫测试时常用的术语。理想的“性能测试”(和其他类型的测试)应在需求文档或质量保证、测试计划中定义。性能测试一般包括负载测试和压力测试。 通常验证软件的性能在正常环境和系统条件下重复使用是否还能满足性能指标。或者执行同样任务时新版本不比旧版本慢。一般还检查系统记忆容量在运行程序时会不会流失(memory leak)。比如，验证程序保存一个巨大的文件新版本不比旧版本慢。这
10、个方法主要针对的是一些硬件和系统响应速度。4.5. 测试 此方法针对的是非程序员和测试 测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta 测试不能由程序员或测试员完成。 当开发和测试完成所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员完成，不能由程序员或测试员完成。目前这个方法和我们公司市场部和法院人员反馈的问题相似，不同的是我们产品已经验收了。5. 缺陷等级划分5.1. 产品验收前定义A 类严重错误，包括： o 由于程序所引起的死机,非法退出 o 死循环 o 导致数据库发生死锁 o 数据通讯错误 o 严重的数
11、值计算错误 测试流程及规范第 6 页 / 共 6 页B 类 较严重错误，包括：o 功能不符o 数据流错误 o 程序接口错误 o 轻微的数值计算错误 C 类一般性错误，包括：o 界面错误(详细文档) o 打印内容、格式错误 o 简单的输入限制未放在前台进行控制 o 删除操作未给出提示 D 类 较小错误，包括：o 辅助说明描述不清楚 o 显示格式不规范 o 长时间操作未给用户进度提示o 提示窗口文字未采用行业术语 o 可输入区域和只读区域没有明显的区分标志o 系统处理未优化 E 类 测试建议（非缺陷）5.2. 产品验收后定义缺陷等级 紧急程度I 级缺陷 为非常紧急的程度，要求半天之内修改完成II 级缺陷 为紧急程度，要求在一天之内修改III 级缺陷 为一般紧急程度，要求在三天之内修改IV 级缺陷 为不紧急程度，要求在一周之内修改
