测试流程规范文档.docVIP

软件测试流程规范 测试人员要站在用户的角度来思考，这个产品是不是用户需要的。 一、 软件发布流程流程： 、产品需求分析：根据客户或者用户提出的功能需求，对产品 功能逻辑进行需求的分析，了解客户需要一个什么产品。 、设计测试用例：根据客户的需求，进行功能流程设计，主要 包括止确的逻辑和错误的逻辑，同时需要设计一些特殊内容输入，如 特殊字符、空格以及不同的环境。 、测试用例评审：将设计好的测试用例与领导开发同事一起进 行评审，检查是否有遗漏的地方。 、执行测试用例：开发人员在功能开发完毕后完成在开发环境的测试 后，提交到测试环境，测试人员开始执行测试用例。 、跟进测试问题：开发修复问题后，对BUG进行修复后的测试 跟进工作，在产品上线前需要将版本的BUG进行一次修复确认测试。 、提交测试报告：完成一个迭代版本的测试之后，需要提交次 版本的质量情况。 二、 软件测试类型： 、单元测试：对软件中最小的可测试单元进行检查和验证，这 个一般开发人员自己就做了。 、集成测试：是确保各单元组合在一起后能够按既定意图协作 运行，并确保增量的行为正确。这里测试人员可以根据设计的测试用 例来执行功能测试。 、系统测试：简单的说就是对整个软件进行测试，执行整个系 统的全部测试用例。(但是系统测试还包括恢复测试、安全测试、压 力测试) 、验证测试：通俗的可以理解为是对软件系统的检查，软件是 否满足功能需求，这个可以根据需求文档来进行，验证测试也可以理 解为客户的验收测试。 三、测试用例的编写规范 (1)、测试用例包括以下内容：用例编号、测试项目、功能模块测试小标题、 操作步骤、问题详细描述、PASSFAIL、优先级、研发确认、测试者时间、 验收结果、备注。 (2 )、测试用例表格文件命名规则：项目名称+版本号+更新日期(年月日)， 如果有自己习惯的方式可以不按照这样命名。 . BUG跟进表包括以下内容：编号、BUG小标题、开发者、优先级、创 建时间、是否完成、完成时间、类型、状态。 、测试结果数据：主要记录用例的执行情况和BUG的修复情况。详细信 息见下图： 测试日期 用例总数 累计BUG总数 本轮测试BUGR 本轮修复确认BUG 待处理 JR计修复确认 2018. 0912—2018. 0914 本轮测试BUG覆址率 本轮测试BUG修复率 本轮测试用例执行悄况 日期：2018. 0912—2018.0914 测试用例总数 PASS FAIL 未执行 用例数（条） 本轮测试BUG修复情况 日期：2018. 0912—201 0914 BUG总数 待处理 己确认 ?? 己修复 数量（个） （5）、用例设计方法: A：等价类划分法：顾名思义，就是指将界面上的输入框的输入域看 成一个大饼，然后又根据某方面输入值之间等价性进行划分，再而从 每个等价域中选取少量具有代表性的数据做为测试用例的输入数据。 每个等价类值又根据是否对程序有无作用，而分为有效等价类和无效 等价类。 有效等价类：此类中值对程序来说是有意义的、合理的，可检验 程序是否实现了需求说明中所规定的功能。 无效等价类：此类中的值正好相反，对程序来说是不合理的、无 意义，输入此类中值程序无法实现相应的功能和性能，但是不是说程 序不会对此类中值有反应，从程序的健壮性来考虑，程序也应该对此 类中的值做出正确的反应。 例1:三角形―等价类测试的例子 某程序规定：”输入三个整数a、b、c分别作为三边的边长构成三角形。通 过程序判定所构成的三角形的类型，当此三角形为一般三角形、等腰三角形及等 边三角形时，分别作计算…”。用等价类划分方法为该程序进行测试用例设计。 （三角形问题的复杂之处在于输入与-输出之间的关系比较复杂。） 分析题目中给出和隐含的对输入条件的要求： （1）整数 （2）三个数 （3）非零数 （4）正数 （5）两边之和大于第三边 （6）等腰 （7）等边 如果a、b、c满足条件（1 ） ~ （4 ）,则输出下列四种情况之一： 1） 如果不满足条件（5）,则程序输出为”非三角形” o 2） 如果三条边相等即满足条件（7）,则程序输出为”等边三角形” o 3） 如果只有两条边相等、即满足条件（6）,则程序输出为”等腰三角形”。 4） 如果三条边都不相等，则程序输出为” 一般三角形” o 列出等价类表并编号 有效等价类 型 无效等价类 号码 输 整数 入 「8为非整数 一边为非整数b为非整数 I C为非整数 厂db为非整数 两边为非整数J b,c为非整数 为非整数 三边①b C均为非整数 12 18 三个数 只给一边［ 只给两边{ 给出三个以上 C 8 b cabhac 给縉给给岛给 只只只只只只 19 25 非零数 正数 —8为0 一边为零Y tl为0 匚c为0 -a,b 为 0 二边为零彳匕c为0 「g