LR性能测试;C语言
QTP功能测试;(C/S;B/S都可以) VB语言
QC测试流程测试需求的管理(就是TD)。
设计自动化测试工具的测试用例还是按照理论书籍上面的方法
只是手工设计出来要手工执行,自动化写出来的用例可以自动化执行
建立系统测试流程的总体思路 by ricky
C公司目前有整套的Mercury测试工具,包括QC, WR, LR 等,测试流程相对来说并不十分规范,而且测试工具的价值也没有完整体现出来,针对这种情况,仓促进行测试自动化的引入,并不是十分合适,我的总体思路是这样的:
以Mercury QualityCenter为核心,把整个测试流程理顺. 按照我们的理解,现在已经拥有了Mercury的很多产品,包括QualityCenter, WinRunner, LoadRunner等.我们可以以此为基础,进行二次开发,更好的发挥这些测试和管理工具的作用,提高他们的价值. 具体可以从以下几个方面进行.
<!--[if !supportLists]-->1. <!--[endif]-->测试需求的管理
利用QualityCenter的测试需求模块,把所有的测试需求进行管理, 新需求必须在提出的时候就录入系统,由流程进行自动跟踪,包括需求的更新,状态的改变等. 在此阶段需要输出一个测试需求分析文档。
<!--[if !supportLists]-->2. <!--[endif]-->测试计划的管理
利用QualityCenter的测试计划模块,进行测试计划的制订,包括测试用例的安排,测试资源规划,测试时间和测试进度的跟踪.测试风险的评估等.在此阶段需要输出一个测试总体方案文档。
<!--[if !supportLists]-->3. <!--[endif]-->测试用例的管理
测试用例包括手工测试用例和自动化测试用例, 分开进行.手工的测试用例必须统一录入QualityCenter,再正式测试进行之前,测试用例必须经过评审,评审通过的测试用例才能列入测试计划进行安排测试.目前的测试用例用Excel进行管理,有很多弊端,比如无法进行共享,测试用例的更新也不能很好的跟踪.在此阶段实际上是对测试总体方案按照系统模块进行细化,生成的测试用例一定要科学(具体的方法可以参见相应的资料),制定出合理的验证标准,必须邀请包含系统设计人员,开发人员,测试人员,甚至最终用户进行评审。
<!--[if !supportLists]-->4. <!--[endif]-->自动化测试脚本的管理
自动化测试用例的脚本,包括功能测试中的WinRunner,QTP的脚本,性能测试中LoadRunner的脚本以及第三方的测试脚本,统一在QualityCenter中进行版本的管理和控制. 包括脚本的创建,更新都需要进行严格的评审,必须按照代码规范编写. 测试的执行利用QualityCenter进行. 手工测试结果手工输入QualityCenter,自动化的测试结果自动导入到QualityCenter.必须明确,自动化测试不可能完全代替手工测试,就功能测试而言,自动化测试是回归测试的利器,是手工测试的补充。
<!--[if !supportLists]-->5. <!--[endif]-->测试报告的管理
利用QualityCenter的强大报表和报告功能,生成各种形式和格式的报告和报表,提交给管理层,作为控制整个项目进展的依据.测试报告中很重要的一项是缺陷描述,必须将缺陷对应的环境,版本,触发条件,是否可重现等描述清楚。
<!--[if !supportLists]-->6. <!--[endif]-->测试缺陷的管理
利用QualityCenter的流程管理,把测试需求,测试用例和测试过程中发现的缺陷自动关联起来.对提高整体的测试效率,提高整个产品的测试覆盖率都是有帮助的.缺陷的发现既是一个流程的结束,也是另一个流程的开始。
最后,对于自动化测试,可以考虑构建一个单独的自动化执行平台,自动化脚本的管理平台还是利用QualityCenter, 自动化的执行平台可以提供更加强大的功能, 包括测试的定制,测试资源的安排,测试日志的记录,测试结果的分析和问题的定位.