iDste

本页面只读。您可以查看源文件，但不能更改它。如果您觉得这是系统错误，请联系管理员。
 ====== 测试制度 ======

===== 1.目的 =====

为了规范测试团队的日常工作，减少开发与测试之间的沟通成本，更好的保证项目进度，提高产品质量，统一公司所有项目的软件测试流程，规范统一项目的执行标准，特制定软件测试部门制度。此制度侧重测试工作流程的实施和控制，明确测试小组任务、目标和测试人员的职责，对部门测试工作的开展起规范指导作用。

===== 2.范围 =====

 本制度适用于公司所有的项目，包括服务器组项目、嵌入式组项目。

===== 3.测试团队构成 =====

==== 3.1组织结构 ====
{{:idsterule:图1.png?direct|}}


注：依据项目不同划分不同的测试小组，每个测试包含测试组长与测试工程师

==== 3.2测试职能及职责划分 ====

测试工作从项目需求阶段开始介入，直至项目结束退出，测试小组人员参与整个项目活动。
    
**职责划分：**
^  角色  ^  职务  ^
|测试主管|指定测试组长，组建测试组，分配测试任务，跟踪测试进度；  |
|:::|了解跟踪项目进度，负责与开发部门协调等工作；  |
|:::|组织测试组开展同行评审会议；  |
|测试组长|根据项目进度指定测试计划；|
|::: |负责分配组内的测试任务，为测试成员安排工作；|
|::: |参与测试工作，同时监督组内成员的工作；|
|::: |根据测试结果对测试结果进行总结，编写测试报告；|
|测试工程师	|执行测试组长安排的测试工作；|
|::: |熟悉各功能模块逻辑|
|::: |编写用例、执行测试任务|

注：\\
1.在人力资源有限情况下，一个团队成员可同时承担多个角色；\\
2.测试主管可是测试组长，亦可是测试组员；

===== 4.测试流程及规范 =====

项目立项启动后，测试从需求分析开始参与项目流程，具体主要工作体现在集成测试，系统测试阶段，以下流程图主要说明测试参与过程。
{{:idsterule:tu2.png?direct|}}

==== 4.1测试流程 ====

=== 4.1.1需求、设计评审 ===

1.测试组在需求阶段介入，参与需求分析、评审会议，提出相关意见建议；\\
2.测试组参与设计评审会议，熟悉了解设计理念，对不认可的设计提出意见建议；

==== 4.2测试设计阶段 ====

=== 4.2.1 测试用例设计 ===

需求文档（需求规格说明书）确定后，测试组针对测试需求设计测试用例，在测试实施过程，用例将是实施测试的唯一标准，在测试用例设计过程中，具体任务与责任如下：

^过程要点	^  详细说明  ^
|输入条件	|需求说明书（需求文档），或要求明确的feature说明|
|工作内容	|根据测试计划、需求文档设计测试用例，设计参考原则：|
| :::|等价类划分|
| :::|边界值分析、场景分析等|
| :::|业务知识及相关流程|
|退出标准	|测试用例需要覆盖所有的测试需求|
|:::|测试用例集进行评审并通过|
|:::|项目进行过程中，适时的根据需求变更来对测试用例进行维护|
|  责任人  |测试组成员|

=== 4.2.2 测试用例评审 ===

^过程要点^  详细说明  ^
|输入条件|测试用例编写完成|
|工作内容|开发者、开发经理、测试负责人、用例设计者参与用例评审：用例是否达到全覆盖|
|退出标准|测试用例评审通过|
|责任人|测试组成员，项目负责人|

=== 4.2.3测试执行阶段 ===

开发团队完成相关功能开发，内部调试通过，发布开发版本，将相关功能交接测试，测试开始进行测试工作：

^过程要点^  详细说明  ^
|输入条件|测试组长定出测试计划，确定可用用例，做好用例划分|
|工作内容|测试工程师根据测试计划中分配给自己的测试任务和提供的测试用例，对相关功能进行测试工作|
|:::|记录执行用例的结果，提交当日测试记录|
|:::|提交缺陷（BUG）、跟踪缺陷（BUG）动态直至关闭|
|退出标准|测试用例中的所有任务被执行，结果被记录。|
|责任人|测试组成员|

=== 4.2.4回归测试 ===

在每轮测试结束之后，测试组需要重新安装最新发布的开发版本进行相关功能的回归测试。若版本发布属于每日发布，测试组根据测试进度灵活调整，在新版本上进行回归。

^过程要点^  详细说明  ^
|输入条件|测试过程发现的问题已解决|
|工作内容|测试组将按照测试计划中对于回归测试的策略对产品进行回归测试；|
|:::|回归测试的用例属于测试用例的一部分或全部测试用例；|
|:::|记录用例执行结果，提交回归测试记录；|
|退出标准|回归测试所执行的用例全部通过|
|:::|缺陷经过验证|
|责任人|测试工程师|

=== 4.2.5内部系统测试阶 ===

所有功能开发完成后，由测试组对最新的开发版本（整个测试过程中发现的问题全部解决）进行系统性验证，确保功能无遗漏，确保每个测试组内的人员均测试过每个功能，测试最终未发现新问题，发布alpha版本，提供测试报告，项目进入验收阶段。

===== 5.版本发布标准 =====

项目发布需符合以下标准。

|严重缺陷|高缺陷|一般缺陷|低缺陷|
|无	|无	|  无	|<=2%|

注：项目测试中发现有极少特殊条件下出现的缺陷异常，不影响使用、操作；暂时无法修正的，可以作为此版本的遗留缺陷，放置于版本说明的已知问题中。

注：附件{{ :idsterule:测试制度.docx |}}
iDste

用户工具

站点工具

页面工具
