随笔分类 -  【软件测试】

你必须学会的几个常用网络命令
摘要:如果你是一个网络维护人员,那么肯定要经常处理网络故障,了解和掌握下面几个命令将会有助于您更快地检测到网络故障所在,从而节省时间,提高效率。【1】pingPing是测试网络联接状况以及信息包发送和接收状况非常有用的工具,是网络测试最常用的命令。Ping向目标主机(地址)发送一个回送请求数据包,要求目标主机收到请求后给予答复,从而判断网络的响应时间和本机是否与目标主机(地址)联通。如果执行Ping不成功,则可以预测故障出现在以下几个方面:网线故障,网络适配器配置不正确,IP地址不正确。如果执行Ping成功而网络仍无法使用,那么问题很可能出在网络系统的软件配置方面,Ping成功只能保证本机与目标主机 阅读全文
posted @ 2013-06-25 11:45 @雨欣@ 阅读(277) 评论(0) 推荐(0)
测试用例注意点
摘要:测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。测试数据应该选用少量、高效的测试数据进行尽可能完备的测试;基本目标是:设计一组发现某个错误或某类错误的测试数据,测试用例应覆盖方面:1、 正确性测试:输入用户实际数据以验证系统是满足需求规格说明书的要求;测试用 例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能,并且正常。2、 容错性(健壮性)测试:程序能够接收正确数据输入并且产生正确(预期)的输出, 输入非法数据(非法类型、不符合要求的数据、溢出数据等),程序应能给出提示 并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户,在进行任意操作。3、 完整(安全)性测试:对 阅读全文
posted @ 2013-06-25 11:33 @雨欣@ 阅读(852) 评论(0) 推荐(0)
好的接口/单元测试用例应满足哪些
摘要:一个好的接口/单元测试用例应该做到: 1、对环境没有依赖 2、验证点检验完全(不能因为用例编写经常拷贝而忽略或遗漏) 3、用例分类合理,命名通俗易懂 4、对数据没有依赖,数据由所测的代码自动创建。一定需要测试数据的情况下,也要将数据准备完全 5、每一个用例运行完成后都要删除测试数据 6、能够在一个用例中覆盖到的测试点,尽量在一个用例中完成,以减少后续对测试数据和用例本身的维护成本。 7、各个测试用例相互独立,不相互依赖 8、尽量减少和开发代码的耦合,能够从上层覆盖到的情况尽量从上层覆盖 9、通俗易懂,注释完全,后人很容易根据用例理解业务 10、用例结构清晰,测试用例也可以学... 阅读全文
posted @ 2012-11-20 09:11 @雨欣@ 阅读(283) 评论(0) 推荐(0)
测试人员入门编程建议
摘要:1、选择一门自己喜欢的、实用的语言,对测试人员而言动态脚本类的语言会更合适,比如python、ruby等2、对任何编程语言,只要掌握以下几点就足够用于辅助软件测试了:2.1数据类型、变量定义及初始化2.2 掌握判断语句2.3 掌握循环语句2.4 掌握调用标准库、系统API和第三方库的方法2.5 熟悉标准库、系统API、及常用第三方库的大致功能2.6 掌握代码分装组织2.7 了解数据结构2.8 了解常用的算法:比如排序、查找另外再加上一个面向对象的类,掌握类的定义方法和使用就可以了我想只要对上述几天有所有理解应当能很快的掌握一门编程语言。总而言之,学习编程,应是应用为主,少去纠缠其中的细节原理。 阅读全文
posted @ 2012-11-19 10:03 @雨欣@ 阅读(205) 评论(0) 推荐(0)
测试理论
摘要:Alpha测试,指软件开发公司组织内部人员模拟各类用户行为对即将面世软件产品进行测试,试图发现错误并修正。该测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作,并尽最大努力涵盖所有可能的用户操作方式。Beta测试:是一种验收测试。即软件产品完成了功能测试和系统测试之后,在产品发布之前所进行的软件测试活动,它是技术测试的最后一个阶段,通过了验收测试,产品就会进入发布阶段。验收测试一般根据产品规格说明书严格检查产品,逐行逐字地对照说明书上对软件产品所作出的各方面要求,确保所开发的软件产品符合用户的各项要求。通过综合测试后,软件完全组装起来,接口方面的错误也已排除,软件测试的最后一步- 阅读全文
posted @ 2012-10-22 13:49 @雨欣@ 阅读(145) 评论(0) 推荐(0)
软件测试阶段
摘要:按照尽早进行测试的原则,测试人员应该在需求阶段就介入,并贯穿软件开发的全过程。就测试过程本身而言,应该包括以下几个阶段:测试需求的分析和确定测试计划测试设计测试执行测试记录和缺陷跟踪回归测试测试总结和报告该阶段就是一个PDCA循环,是一种质量改进模型。P(plan)代表计划,D(do)代表执行,C(check)代表检查,A(action)代表处理。测试需求对于需求文档,应遵照尽早测试的原则,对其进行测试。通常,需要检查需求规格说明书的以下几个方面,来衡量需求规格说明书的质量:【检查要点】正确性:对照原始需求检查规格说明书必要性:不能回溯到出处的需求可能是多余的优先级:乔当地划分并标识明确性:不 阅读全文
posted @ 2012-10-10 12:09 @雨欣@ 阅读(333) 评论(0) 推荐(0)
软件缺陷的状态有哪些??
摘要:New(新的):bug提交到缺陷库中会自动的被设置成New状态Assigned(已指派):当一个bug被认为New之后,将其分配开发人员,开发人员将确认这是否是一个bug,如果是,开发组的负责人就将这个bug指定给某位开发人员处理,并将bug的状态设定为“Assigned”Open(已打开):开发人员开始处理bug时,他将这个bug的状态设置为“Open”,表示开发人员正在处理这个“bug”Fixed(已修复):当开发人员进行处理(并认为已经解决)之后,他(她)就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人,然后开发组的负责人将这个bug返还给测试组Rejected(被 阅读全文
posted @ 2012-09-28 11:17 @雨欣@ 阅读(8726) 评论(0) 推荐(1)
软件测试用例的编写技巧【摘记】
摘要:现状原因:复杂的业务会贯穿于整个软件,涉及众多功能点,里面组合的分支更不可胜数。功能用例依赖程序界面,业务描述依赖需求文档。(功能与业务的分离的缺点)没有很好的积累业务上的用例,才使得执行用例时发现的bug不多。如何解决以上涉及测试用例中遇到的问题:测试驱动开发(TDD)。其基本思想是:在开发功能代码之前,先编写测试代码。为用例标明时间(版本)和优先级。标明时间或版本可以起到一种基准的作用,标明项目进度过程中的每个阶段,使用例直接和需求基线、软件版本对应。同样这需要规范流程,也是对变更的一种确认和控制。或者可以为用例增加一个状态,致命这个用例目前是否与程序冲突,当程序变更时改变用例的状态,并更 阅读全文
posted @ 2012-09-27 10:00 @雨欣@ 阅读(302) 评论(1) 推荐(0)
经典杯子测试
摘要:【测试项目】:杯子需求测试:查看杯子使用说明书界面测试:查看杯子外观功能度:用水杯装水看漏不漏水;水能不能被喝到安全性:杯子有没有毒或者细菌可靠性:杯子从不同的高度落下的损坏程度可移植性:杯子在不同的地方、温度等环境下是否都可以正常使用兼容性:杯子是否能够容纳果汁、白开水、酒精、汽油易用性:杯子是否烫手、是否有防滑措施、是否方便饮用用户文档:使用手册是否针对杯子的用法、限制使用条件等有详细描述疲劳测试:将杯子盛上水(案例一)放24小时检查泄露时间和情况;盛上汽油(案例二)放24小时检查泄露时间和情况等压力测试:用针尖对住杯底不断往杯子里面加水,看压强多大时会穿透震动测试:杯子将包装(有填充物) 阅读全文
posted @ 2012-09-25 17:23 @雨欣@ 阅读(704) 评论(1) 推荐(1)
软件【黑盒测试】的测试用例的设计方法
摘要:http://www.ltesting.net/ceshi/ceshijishu/csyl/list_94_2.html 阅读全文
posted @ 2012-09-25 11:29 @雨欣@ 阅读(420) 评论(1) 推荐(0)