51Testing软件测试论坛

标题: [有奖问答3]您认为一个好的测试流程应该包括哪些部分？ [打印本页]

作者: 默默巫 时间: 2009-11-9 10:18
标题: [有奖问答3]您认为一个好的测试流程应该包括哪些部分？
您认为一个好的测试流程应该包括哪些部分？如何使用工具管理流程？

答题前请复制以下回贴格式(蓝字部分)，并填写好个人真实有效信息，以确保奖品发送无误。

答题:

复制代码

作者: hellinangel 时间: 2009-11-9 12:07

答题
:一、测试计划-根据测试项目的要求来制定测试计划，制定测试计划的目的是确定和描述要实施和执行的测试。
二、测试用例设计-包含了测试用例设计、评审、修改、评审通过，确定测试用例。
三、测试准备-测试环境的搭建，测试数据准备，测试所需设备准备。
四、测试执行-执行用例，提交BUG。
五、缺陷管理-对于测试中提交的BUG进行修复，修复后进行回归测试。
六、测试停止-测试结果通过评估决定通过后终止测试阶段。
七、测试总结-对于整个测试流程中的问题及结果进行总结。

作者: ermine 时间: 2009-11-9 12:23

答题:
1.测试工作开展流程，计划→方案→设计→执行→报告总结。
2.需求确认和变更的流程。确认需求被覆盖程度，当需求变更时，能快速对应到测试用例的变更。
3.缺陷管理流程。能有效的管理缺陷的生存周期，确认缺陷的状态。
4.测试执行的流程。产品在各个版本，各个阶段测试的顺序，测试用例执行的优先等级。
工具管理流程：
用的是QC，设置版本，添加需求，编写需求对应的测试用例，设置执行顺序后执行，用defects管理缺陷，最后根据数据，写测试报告。

[ 本帖最后由 ermine 于 2009-11-9 12:24 编辑 ]

作者: 月上百合 时间: 2009-11-9 14:14

答题：您认为一个好的测试流程应该包括哪些部分？如何使用工具管理流程？
1、了解需求。了解需求时提出自己对用户需求的理解和对开发规格的要求。
2、测试计划。根据软件开发的需求，及开发的时间，来制定一个测试计划，为了保证在有效的时间里更好的做好测试工作；
3、设计测试用例。制定好测试计划后，就要根据需求来设计测试用例了，一定要很好的覆盖各种情况
4、评审测试用例。因为一个人的思维是有限的，所以最好有评审团来对测试用例进行评审，补充。
5、执行测试。搭建测试环境，执行测试用例
6、缺陷管理。在缺陷管理工具中提交bug，或者用execl提交bug
7、回归测试。在每个模块，或者修复好每一个bug后都要进行回归测试。以防引起其它bug出来。

作者: 原点 时间: 2009-11-9 15:08
在百合的基础上我觉得还需要增加结果评审

作者: wy51testing 时间: 2009-11-10 11:57

答题:同意百合的说法

作者: 断寒 时间: 2009-11-10 11:57

答题:
1.好的测试流程包含从测试需求到测试结束过程中所有的要素,其中包含对于这个流程中每个阶段的评审及部分阶段的迭代.
2.用工具管理流程?用工具来体现流程和监督流程这个说法更好一点吧.工具要能够管理测试流程中每个阶段的工作项,工作结果及评审结果.能够设置检查每个阶段开始的要素是否满足,能够根据实际情况裁剪过程中的可选要素,能够即时管理测试过程具体的执行状态,能够提示测试过程中存在的或即将产生的风险

作者: yolander 时间: 2009-11-10 12:12

答题:
一个完整的测试流程应包括以下几个方面
1、系统需求分析：尽早参与需求分析过程，有助于测试工程师对需求的理解，同时也能提高需求的可测试性，另外也能将不能执行测试的需求尽早发现，提醒研发进行设计评审等手段来保证质量
2、测试策略制定：根据需求分析结果，首先确立是使用基于风险的测试策略还是基于功能的测试策略，在测试策略中，需要明确测试手段、方法、技术、流程等方面的要求
3、测试计划制定：根据测试策略明确测试资源、测试环境、测试工具、时间进度等安排
4、测试策略和计划的评审
5、测试设计：根据系统需求，参考测试策略中明确的技术、方法等，开始着手进行测试需求分解，并进行测试设计，其中包括自动测试和手动测试两个方面，分别有不同的或者交叉覆盖的testcase
6、测试设计评审
7、测试环境搭建：包括测试系统平台、测试管理平台、缺陷跟踪平台、测试配置管理平台等
8、测试执行：利用测试管理平台，指派工作任务到每个工程师，工程师根据任务安排，在测试系统平台上执行测试用例，记录测试结果，提交缺陷报告到缺陷跟踪平台，最后还要提交测试记录到配置管理平台
9、缺陷跟踪管理：对提交的缺陷进行跟踪管理，如审核、指派、分析、修改、评审（主要是指缺陷评审）、验证、确认、关闭等
10、测试报告与总结：总结测试过程，对测试过程和测试产品进行客观评价，如果要做到评价的客观，那么就要在之前的测试过程中注意测试数据的收集，利用这些测试数据进行度量与分析，得到客观的评价结论

作者: dqar 时间: 2009-11-11 13:34

答题:
我认为一个完整的好的测试流程应该包括：
测试需求分析-〉测试计划制定（同时包含用于控制和跟踪测试进度的mpp文档）、测试说明编写-〉[可以单独将测试策略从测试计划中拿出来作为一个单独的过程]-〉设计测试用例-〉测试执行（测试报告、测试结果分析用于改进测试过程，制定更详细的测试计划）-〉测试总结

在测试执行阶段最好进行如下所有过程：
开发人员进行单元测试-〉开发人员自己进行功能确认测试-〉测试人员进行确认测试、集成测试、系统测试和每轮的回归测试

时间仓促，以上只列出了每个节点，对于每个节点内部的详细内容有时间补上。
欢迎大家批评指正！

作者: laoxin511 时间: 2009-11-11 16:44

答题:您认为一个好的测试流程应该包括哪些部分？如何使用工具管理流程？

一.流程

一个好的流程要兼顾成本，进度和质量三个要素
在成本和进度足够的情况下，要保证质量是很容易的，一个正规完整的流程就可以实现；
但是在成本和进度不是很富裕的时候，还要保证质量，那就要有所舍弃。
现在大部分的项目都是后者，所以我们这里应该谈的也主要是后者。
首先，流程是为人服务的，应该根据公司的实际情况分析，各个流程是不是都需要
像8楼的朋友说的，测试策略里选择是基于风险还是基于功能的策略，一般的公司只会有一个策略，基于功能。
还有如果项目进度很紧张，那就要考虑流程是不是要简化，甚至取消不是很重要的流程
其次，新项目和旧系统升级改造的项目流程应该有所区别
像我们公司的升级改造项目就不用把搭建环境算在流程里了，因为旧系统的环境还运行在公司的服务器上
我认为一个相对完整的测试流程是(这里暂不涉及工具)：
1.需求分析-需求评审：
   这里有两个问题，第一个问题是面向目标是客户还是用户，第二个问题是不同的公司对测试参与需求的过程不会一样的，有的公司是测试来做需求设计，有的公司是开发设计，我们公司也是开发设计，测试只参与评审。
   对于第一个问题，如果是客户，那需求就会明确的多，要努力的方向的只是用最短的时间确定需求，最好客户和开发项目组双方对软件的主体流程都了解透彻。一般来说，客户对流程了解透彻，以后需求的改动就不会很大；开发项目组对需求了解透彻，在主体流程上的bug就不会太多，这样在需求分析的步骤就最大限度的为项目节省了成本和进度。
   如果是用户，首先要确定面向的用户群体，然后重点关注用户潜在的需求，即隐式需求，这时最好找到相当数量的合适用户作详细的调查。
   对于第二个问题，如果是测试设计需求，那么只要按照第一个问题做就可以了，如果是开发设计需求，那就要在做需求分析的时候，尽早尽可能的找到所有需求不明确的地方，与需求设计人员和客户沟通，让所有跟项目有关的人员加深对需求的理解。
   最后如果没有过程管理工具，在这个阶段最好建立需求跟踪矩阵。
2.测试计划设计-测试计划评审：
   明确测试资源、测试环境、测试工具、时间进度等安排
3.测试用例设计-测试用例评审：
   测试用例的设计最好按照公司的模版和范例一致，因为很可能测试执行和测试用例设计不是同一个人，在编写用例的时候要考虑，如何写的明白明确，如果换一个人根据用例执行测试，是不是能完全领会你的测试思路，是不是能看懂你用到的测试手段和方法。毕竟人和人的思维模式不同，要让别人最大限度的理解你的思路，最好按照统一的标准把你的思路完整清晰的表达出来。
4.测试执行-缺陷管理：
   执行测试用例-记录测试结果-提交缺陷报告-执行回归测试-验证缺陷。
5.验收测试-客户培训：
   项目组人员在模拟的客户环境下运行系统以便公司验收-指导客户或模拟用户进行真实全面的功能和性能模拟-对客户进行系统操作培训-结项并验收项目所有文档。

二.工具
我用过的工具不多
除了在51学过的，也就多一个bugfree。
要说管理流程的话，我觉得rose+QC+LR+QTP就够了
rose用来分析流程和设计用例
QC管理测试过程
LR进行性能测试
QTP进行功能测试
QC用来做权限管理，需求管理，用例管理和缺陷管理足够强大了，还可以和LR，QTP联通
不过，还是要具体问题具体分析
限于成本的考虑，小公司会选择visio+需求跟踪矩阵+jira/bugfree+自制的压力测试工具

作者: 蓑衣干子 时间: 2009-11-11 19:41

答题:
1. 设计测试计划：需求分析阶段与需求设计人员沟通需求并着手设计测试计划。
2. 确认测试计划：根据需求的变动以及沟通结果最终敲定测试计划。
3. 设计测试用例：总体设计阶段根据需求和测试计划开始设计待测对象的测试用例。
4. 审核测试用例：经过多个需求设计人员或者更多人的商议审核测试用例以求达到覆盖更完善，设计更科学。
5. 执行测试用例：开发代码完毕后，执行测试用例进行测试，包括单元测试，内部测试，系统测试，集成测试等
6. 分析录入bug：利用bug管理工具执行bug管理流程。
7. Bug的回归测试：bug修复完毕后进行回归测试以确保该bug不再重现，以及不会引起其他的新的问题出现。
8. 分析测试结果：对整个测试阶段的结果进行分析统计。
9. 待测对象执行性能测试：功能确保的情况下观察其性能是否达标。
10. 测试审核：审核该次测试是否达标。

作者: 11111 时间: 2009-11-12 12:06

答题:
2#，4#对测试流程说得已经很详细了~~~
我觉得在工具管理部分，要根据各公司的情况而定。
管理方面主要针对用例和缺陷。
1、对于人数较多的公司，用工具管理比较方便，以前用过ibm的CQ，感觉很强大，可以将没有通过的用例直接提交到CQ里，很方便。
2、对于人数较少的公司，首先这样的工具，需要的成本高。其次用文档管理会显得比较方便，但是有个小型的CQ那就好了。

作者: 欣欣虫子 时间: 2009-11-12 16:47

答题:
需求评审-用例编写-用例评审-执行用例-回归测试-线上验收

作者: IUHK 时间: 2009-11-12 23:08

答题:
1.参与了解需求
2.对获得资源并进行分配
3.进行测试计划
4.进行测试准备
5.架构测试框架以及分解功能点
6.编写用例以及评审
7.执行用例提交缺陷
8.跟踪缺陷
9.阶段性总结，对用例进行修改或者对设计进行修改
10.循环6-9
11.交付UAT测试
12.总结测试，并协助系统上线维护

作者: xsheep 时间: 2009-11-13 15:41

1.参与需求分析和设计评审，了解原始需求
2.测试计划-包括测试策略，测试资源，测试范围，测试人员，测试周期，风险分析等
3、测试用例设计-用例设计、评审、修改和测试过程中的更新调整等。
4、测试准备-环境搭建，数据准备等。
5、测试执行-执行用例，提交缺陷，。。。。回归测试等。
6、缺陷管理-总结，分析
7、项目总结，测试总结分析等等
每个阶段都要包含评审

作者: sunxue1012 时间: 2009-11-14 13:32

答题:
1.测试工作开展流程，计划、方案、设计、执行、报告总结。
2.需求确认和变更的流程。确认需求被覆盖程度，当需求变更时，能快速对应到测试用例的变更。
3.缺陷管理流程。能有效的管理缺陷的生存周期，确认缺陷的状态。
4.测试执行的流程。产品在各个版本，各个阶段测试的顺序，测试用例执行的优先等级。
工具管理流程：
用的是QC，设置版本，添加需求，编写需求对应的测试用例，设置执行顺序后执行，用defects管理缺陷，最后根据数据，写测试报告。

作者: prettyyangxj 时间: 2009-11-18 17:35
标题: 回复 1# 的帖子

答题:一个好的流程应该包括：
1、熟悉需求、设计文档
2、确认测试需求
3、编写测试计划
4、编写测试方案
5、编写测试用例
6、测试用例评审
7、执行测试（包括回归测试）
8、测试总结
可以使用TestDirect、bugfree管理测试流程

作者: yangzheng 时间: 2009-11-19 16:05

答题：1.在项目计划、软件需求规格说明书出来后，指定系统测试计划
   2.熟悉需求，根据软件需求规格说明书编写系统测试用例
   3.在概要设计说明书评审后，编写集成测试用例
   4.在详细设计评审后，根据模块设计说明书编写单元测试用例
   5.在编码阶段，进行局部单元测试
   6.编码结束后，单元测试完成，进行集成测试
   7.集成测试结束后，进行系统测试
   8.最后进行验收测试并编写测试报告

作者: xiaoking 时间: 2009-11-23 17:47

原帖由 yolander 于 2009-11-10 12:12 发表
**** 本内容被作者隐藏 *****
答题:
一个完整的测试流程应包括以下几个方面
1、系统需求分析：尽早参与需求分析过程，有助于测试工程师对需求的理解，同时也能提高需求的可测试性，另外也能将不能执行测试的需求 ...

答题:我觉得，这是一个很规范，全面的流程
但是呢？一个好的流程需要针对具体的公司，具体的环境而言
很通用的流程不一定很适用
对于测试流程更多的是测试思想，工具方面：QC提供了很好的测试管理过程

[ 本帖最后由 xiaoking 于 2009-11-23 17:49 编辑 ]

作者: stjd139 时间: 2010-3-11 13:55
测试需求、测试计划、测试用例、测试执行、测试报告

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)