系统测试全过程

上传人:人*** 文档编号:488919157 上传时间:2024-02-21 格式:DOCX 页数:4 大小:12.36KB
返回 下载 相关 举报
系统测试全过程_第1页
第1页 / 共4页
系统测试全过程_第2页
第2页 / 共4页
系统测试全过程_第3页
第3页 / 共4页
系统测试全过程_第4页
第4页 / 共4页
亲,该文档总共4页,全部预览完了,如果喜欢就下载吧!
资源描述

《系统测试全过程》由会员分享,可在线阅读,更多相关《系统测试全过程(4页珍藏版)》请在金锄头文库上搜索。

1、我一直感觉系统测试总像马拉松总是测试不完,什么时候上线,什么时候算终点。虽然提交客户了,可是 对于质量仍然心里没底,对于测试的效果没有评价的依据。后来经过高人指点,终于领悟到至关重要的精 髓:明确测试目标!如果要将系统进行全面测试,那么就要有一套完整的测试阶段,每个阶段都以测试目标为标准,科学、 有序地进行测试,那么测试效率也就会自然而然跟着提高。测试阶段分为:测试前准备、需求分析、测试计划、测试设计、测试执行、测试结果。1. 测试前准备阶段主要是相关业务的学习。业务知识是测试的根本依据,只有业务过关了,以后才能有效的进行测试工 作。了解业务步骤:a、7解业务名词;b、对现有系统的学习:功能点

2、、业务场景等;c、分析现有系统数据库,了解数据的走向。2. 需求分析阶段需求是项目开发的基础,也是测试的依据。所以需求分析一定要做。但是很多公司是没有详细的需求 文档的,那如何进行需求分析呢?此时分析数据库就是一个非常好的方法:a、每张表的索引和约束条件;b、数据的来源、走向;c、数据的存储、变化;d、数据间的关联;e、表与表间的关系;这些分析都可以为了解业务场景和之后的测试用例设计打好基础。3. 测试计划阶段我们总是觉得被测试进度紧逼、计划失控、测试不完全等等状态,其实解决这些情况的最好方法就是: 制定测试目标。在计划初期先明确测试目标,制定不同层次目标的执行标准,指导后期设计不同级别的测试

3、用例,跟 踪不同级别的缺陷修改。在测试时间较紧情况下,至少可以先把保证所有功能正常操作的最低目标版本先 提交给客户,不会再有手忙脚乱,心里没底的状况。测试目标分为:最低目标基本目标较高目标最高目标等级别可以使用表格形式来规范目标准侧,例如:测试目标准则表目标测试范围需求覆盖率最低目标:正常的输入+正常的处理过程,有一个正确的输出(明确的功能点全部列出来)1. 功能:正常功能异常功能单功能业务场景非功能:16种测试类型2. 输入覆盖率:有效无效处理过程:基本流备选流状态变化:正常、异常输出SRS00001SRS00002SRS00003基本目标:对异常的输入有错误的捕获,并进行相应提示或屏蔽较高

4、目标:对隐式需求进行测试根据公司规模不同,确定测试目标级别也可不同。一般小公司有最低标、基本目标即可,大公司可以 提高目标标准,直接从基本目标开始,直至最高目标。4. 具体的ST用例的编写以及执行测试用例设计的粒度一直是个讨论对象,很多时候总会强调时间很紧啊,如果时间再多点,我的用例 肯定会设计的再细一些!是不是设计的越细就一定越好呢,不一定,测试是无穷尽的,使用穷举方法来进行测试是不科学的。因为制定了测试目标,那么就应该根据测试目标,在设计测试用例时也要制定设计用例目标。比如:按照最低目标选择测试用例输入一 有效处理 有效输出一 有效按照最低目标的宗旨,只要是设计出来的测试用例足以覆盖和验证

5、系统基本功能可以正常使用,那么 这些测试用例的粒度就足够细了!从而提高了设计用例效率,同时也提高了测试效率。5. 测试之后的评估实现一级测试目标之后都要进行评审工作,根据评审结果进行系统版本发布。例如:1. 保证所有需求都有测试用例2. 保证所有功能的正常操作和正常操作有对应的测试用例V1.0版本3.保证所有功能的异常校验有对应的测试用例V2.0版本4. 各功能组合形成的业务流有对应的测试用例V3.0版本5. 各功能或整体软件所需满足的非功能性需求有对应的测试用例 V4.0版本这样做既可以对代码版本进行控制,也可以应对需求变更的问题。也许“确定测试目标”还不能彻底解决复杂测试工作中出现的问题,但是我觉得这最起码可以让你的测 试工作变得有条理;跟领导汇报工作的时候业绩和工作效率有凭可据;面对需求变更的时候有理可依!

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 学术论文 > 其它学术论文

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号