测试规范及流程

[JulenePenn]

测试规范及流程



Version: 2.0
Date: 2005-07-19





Prepared by Limited

The information in this document shall not be disclosed outside of Axisoft. And shall not be duplicated, used, or disclosed in whole or in part for any purpose other than to evaluate the document. This restriction does not limit the right of Axisoft.







Table of Content

1 测试进入准则 1
1.1 说明 1
1.2 标准 1
2 质量保证要求 2
3 测试工作流程 3
3.1 说明 3
3.2 工作流程 3
3.2.1 测试进入时间 3
3.2.2 项目开发设计阶段 3
3.2.3 项目编码阶段 3
3.2.4 执行测试阶段 3
3.2.5 用户接受测试阶段 3
3.2.6 运行维护阶段 4
4 质量评审指南 5
4.1 说明 6
4.2 评审范围 7
4.2.1 功能性 7
4.2.2 可靠性 7
4.2.3 易用性 7
4.2.4 效率 7
4.2.5 可维护性 7
4.2.6 可移植性 8
4.2.7 用户界面 8
5 测试文档模板 10
5.1 测试计划模板 10
5.2 测试案例模板 10
5.3 测试缺陷模板 10
5.4 测试报告模板 10
5.5 测试缺陷跟踪报告模板 10
5.6 测试分析报告模板 10
5.7 测试文档约定 10
6 各部门协作约定 11
6.1 对PM的要求 11
6.2 对开发小组的要求 11
6.3 对测试小组的要求 12

测试进入准则
说明

制定本准则的目的是为了进一步提高公司软件产品的质量，以确保进入测试部门的软件产品的可测试性，尽量减少测试人员的重复工作。

本准则所称进入，是指软件产品从开发部门发布后，测试部门即将进行测试。

标准
开发部门提供的产品必须能通过所有由QA提供并由PM确认的重要（High Priority）测试案例的检测；否则QA有权提出取消测试。
质量保证要求

为了确保测试工作的质量，在测试过程中，软件测试工程师应当按照下列工作流程和要求：
PM、开发小组和测试人员共同确定当前阶段产品的质量标准；
Demo或进行产品可测试性的测试；
执行所有的（功能和业务流程）测试案例，确保测试的充分性；
编写缺陷报告；
填写工作日志；
提交当前阶段的测试报告；
完善测试案例；
PM、开发小组和测试人员进行当前阶段产品的质量评审以及上一阶段的测试工作的评审。
测试工作流程
说明
为了规范测试部门的测试工作、提高测试部门的工作效率、确保软件产品的质量，特制定此工作流程。

工作流程
测试进入时间
项目需求分析完成、需求分析说明书发布时进入。

项目开发设计阶段
阅读、理解和分析需求分析说明书，与PM讨论需求模糊的地方；提炼测试需求和测试内容
根据项目计划以及测试内容，确定每一个测试阶段的工作进度安排
编写测试计划初稿
编写测试案例

项目编码阶段
根据软件设计说明书，完成测试计划
根据软件设计说明书，完善测试案例
准备测试环境
制定第一阶段产品的测试内容
PM、开发小组和测试人员共同确定第一阶段产品的质量标准

执行测试阶段
Demo或进行产品可测试性的测试
执行测试
编写缺陷报告
填写工作日志
提交当前阶段的测试报告
完善测试案例
PM、开发小组和测试人员进行当前阶段产品的质量评审以及上一阶段的测试工作的评审


制定下一阶段产品的测试内容；
PM、开发小组和测试人员共同确定下一阶段产品的质量标准

用户接受测试阶段
重现、确认UAT出现的缺陷
编写用户手册
编写管理员手册

运行维护阶段
重现、确认用户反馈回来的缺陷
理解新需求
回归测试

质量评审指南
软件质量：与软件产品满足明确或隐含需求的能力有关的特征和特征的总和。有四个含义：
能满足给定需要的特性之全体
具有所希望的各种属性的组合的程度
顾客或用户认为能满足其综合期望的程度
软件的组合特性，它确定软件在使用中将满足顾客预期要求的程度

从用户最感兴趣的的角度来说，软件质量可以从三个不同的角度来看待：
如何使用软件、使用效果如何、软件性能如何；

从软件开发的团队的角度来说，不仅要生产出满足质量要求的软件，也对中间产品的质量感兴趣，也对如何运用最少的的资源、最快的进度生产出质量最优的产品感兴趣；

从软件维护者的角度看，对软件维护方面的特性感兴趣；对企业的管理层来说，注重的是总体效益和长远利益，就是说质量好的软件一般可以帮助企业扩大市场；反之，质量差的软件一般会造成企业市场萎缩。

软件的质量特性包括功能性、可靠性、易用性、效率、可维护性、可移植性等六个方面，每个方面都包含若干个子特性：
度量标准/目标 麦 考 尔 勃 姆 ISO 9126
正确性(Correctness) X X 可维护性
可靠性(Reliability) X X X
完整性(Integrity) X X
可用性(Usability) X X X
效率性(Efficiency) X X X
可维护性(Maintainability) X X X
可测试性(Testability) X 可维护性
互操作(Interoperability) X
适应性(Flexibility) X X
可重用性(Reusability) X X
可移植性(Portability) X X X
明确性(Clarity) X
可变更性(Modifiability) X 可维护性
文档化(Documentation) X
恢复力(Resilience) X
易懂性(Understandability) X
有效性(Validity) X 可维护性
功能性(Functionality) X
普遍性(Generality) X
经济性(Economy) X

正确性：系统满足规格说明和用户目标的程度，即，在预定环境下能正确地完成预期功能的程度
健壮性：在硬件发生故障、输入的数据无效或操作错误等意外环境下，系统能做出适当响应的程度
效率：为了完成预定的功能，系统需要的计算资源的多少
完整性（安全性）：对未经授权的人使用软件或数据的企图，系统能够控制（禁止）的程度
可用性：系统在完成预定应该完成的功能时令人满意的程度
风险：按预定的成本和进度把系统开发出来，并且为用户所满意的概率
可理解性：理解和使用该系统的容易程度
可维护性：诊断和改正在运行现场发现的错误所需要的工作量的大小
灵活性（适应性）：修改或改进正在运行的系统需要的工作量的多少
可测试性：软件容易测试的程度
可移植性：把程序从一种硬件配置和（或）软件系统环境转移到另一种配置和环境（需要的工作量多少，有一种定量度量的方法是：用原来程序设计和调试的成本除移植时需用的费用）
可再用性：在其他应用中该程序可以被再次使用的程度（或范围）
互运行性：把该系统和另一个系统结合起来需要的工作量的多少

说明
为了明确产品质量评审的范围、确定评价的方向。QA Company特提供该评审指南以供质量评审参考。

评审范围
功能性
软件所实现的功能满足用户需求的程度．功能性反映了所开发的软件满足用户称述的或蕴涵的需求的程度，即用户要求的功能是否全部实现了。
适合性
准确性
互操作性
依从性
安全性

可靠性
在规定的时间和条件下，软件所能维持其性能水平的程度（其主要指标是程序故障频率和临界值、程序故障被纠正速率）。可靠性对某些软件是重要的质量要求，它除了反映软件满足用户需求正常运行的程度，且反映了在故障发生时能继续运行的程度。
成熟性
容错性
易恢复性

易用性
对于一个软件，用户学习、操作、准备输入和理解输出时，所做努力的程度。易使用性反映了与用户的友善性，即用户在使用本软件时是否方便。
易理解性
易学性
易操作性

效率
在指定的条件下，用软件实现某种功能所需的计算机资源（包括时间）的有效程度。效率反映了在完成功能要求时，有没有浪费资源，此外,资源这个术语有比较广泛的含义，它包括了内存、外存的使用，通道能力及处理时间。
时间特性
资源特性

可维护性
在一个可运行软件中，为了满足用户需求、环境改变或软件错误发生时，进行相应修改所做的努力程度。可维护性反映了在用户需求改变或软件环境发生变更时，对软件系统进行相应修改的容易程度。一个易于维护的软件系统也是一个易理解、易测试和易修改的软件，以便纠正或增加新的功能，或允许在不同软件环境上进行操作。
易分析性
易改变性
稳定性
易测试性

可移植性
从一个计算机系统或环境转移到另一个计算机系统或环境的容易程度。
适应性
易安装性
遵循性
易替换性

用户界面
符合标准和规范；
直观性
用户界面是否洁净、不唐突、不拥挤
UI的组织和布局合理
允许用户轻松地从一个功能转到另一个功能
任何时刻都可以决定放弃或者退回、退出
下一步做什么较明显
菜单或者窗口简洁而明确
没有多余功能
软件整体抑或局部做得适度
没有太多特性把工作复杂化了
信息不庞杂
其他所有努力都失败时，帮助系统能帮忙解决问题


一致性
快速键和菜单选项
术语和命令
面向同一听众级别
按钮位置和等价的按键


灵活性
状态终止和跳过
数据输入和输出


舒适性
恰当：软件外观和感觉应该与所做的工作和使用者相符，金融商业应用程序不应该用绚丽的色彩和音效来表现狂放的风格
错误处理：程序应该在用户执行严重错误的操作之前提出警告，并且允许用户恢复由于错误操作导致丢失的数据
性能：快不见得是好事，不少程序的错误提示信息一闪而过，无法看清。如果操作缓慢，至少应该向用户反馈操作持续时间，并且显示它正在工作，没有停滞。

正确性
市场定位偏差
有没有多余的或者遗漏的功能，或者某些功能执行了与市场宣传材料不符的操作
语言和拼写
程序员知道怎样只用计算机语言的关键字拼出句子，常常能够制造一些异想不到的用户信息
不良媒体：
媒体是软件UI包含的所有支持图标、图像、声音和视频
图标应该同样大，并且具有相同的调色板
声音应该都有相同的格式和采样率
正确的媒体从UI选择时应该显示出来
所见即所得
保证UI所说的就是实际得到的。当单击Save按钮时，屏幕上的文档与存入磁盘的是否一样；从磁盘读出时与原文档是否相同。

实用性
具体特性是否实用
在审查产品说明书、准备测试或者实际测试时，想一想看到的特性对软件是否具有实际价值







测试文档模板
测试计划模板


测试案例模板


测试缺陷模板


测试报告模板


测试缺陷跟踪报告模板


测试分析报告模板


测试文档约定



各部门协作约定
对PM的要求

《项目计划》（项目规划阶段）
项目管理者应根据此项目的交付时间，制定一份比较完善的、合乎实际的项目计划，包括每个阶段的里程碑（里程碑之间应该有一天的间隔，以便开发人员和测试人员准备下一阶段的工作），并依此预定测试资源（人员和时间）
《需求分析说明书》（用户需求分析阶段）
此说明书必须与需求定义相吻合，必须详尽地说明此项目需要达到的目标和要求（比如性能指标）。测试小组依据此说明书制定测试计划，验证软件产品或项目是否与用户需求一致
项目需求分析完成、需求分析说明书发布时，应要求测试工作开始。（请参考“测试工作流程”）
PM应在每一个开发里程碑开始时，制定当前阶段要达到的质量目标。（请参考“测试工作流程”）
PM应在每一个开发里程碑结束时，进行当前阶段的质量评审和对当前阶段测试工作的质量评审（请参考“测试工作流程”）
PM应在每一个开发里程碑的例会上确定需要修改的缺陷
开发过程中的新需求以及经确认的测试人员提出的建议，应以文档的形式记录下来

对开发小组的要求

《详细设计说明书》
《详细设计说明书》应包含每一个模块的流程图，同时应有一个开发原型与《详细设计说明书》一起发布；测试小组依据此说明书完善测试计划和测试用例
开发小组需做内部交叉测试，排除比较浅显的错误，提交一个可测试的产品
在编码的第一个里程碑，开发小组需给项目成员（项目管理者，开发成员和测试人员）对提交的产品做一个演示，目的在于检测此产品的可测试性，警示开发人员避免出现一些不专业性的错误（请参考“测试工作流程”）
在编码的每一个里程碑里，要求所有high priority 的测试案例全部通过。
开发小组内如果分工明确，则可提供一份分工明细表给测试人员，或者开发小组指定一个对该项目比较专业、全面的开发成员，以支持解决测试小组在测试期间的问题

对于开发小组内部会议，如果涉及到功能需求的变更、模块接口的改变（如SQL Agent实现的功能改为由Windows Task Schedule来实现），则需测试人员；其他的会议只需将会议记录用邮件CC给测试人员即可

对测试小组的要求

严格、认真地完成“测试工作流程”中所要求的每一项任务
在执行测试之前，提交测试计划和测试案例，并准备测试所需环境
在每一个测试里程碑之前，提交下一个里程碑的测试内容
认真填写缺陷报告
详细填写工作日志
分析测试产品存在的问题，认真、仔细地填写对测试产品的评价
完善测试案例
完成测试分析报告