软件测试杂记_h(一)

软件测试杂记_h(一)

ID:36050224

大小:309.50 KB

页数:49页

时间:2019-05-02

软件测试杂记_h(一)_第1页
软件测试杂记_h(一)_第2页
软件测试杂记_h(一)_第3页
软件测试杂记_h(一)_第4页
软件测试杂记_h(一)_第5页
资源描述:

《软件测试杂记_h(一)》由会员上传分享,免费在线阅读,更多相关内容在教育资源-天天文库

1、Testing目录1.测试组是助力研发软件质量还是拉软件周期后腿?22.关于软件项目后期Fixbug的意义之我见23.只会黑盒测试算专业的软件测试人员吗?44.PS是什么意思85.软件测试员----你的路在哪里?86.由“游戏测试”引发“手机测试”的一些感想107.专业测试人员发展的未来128.软件测试工程师的分类从新手到专家139.在浏览器地址栏按回车、F5、Ctrl+F5刷新网页的区别1610.从一个测试实验想到的1711.手机测试之详谈1912.软件测试之敏捷的质量2113.PRD2314.软件测试随想2315.要想做

2、好软件测试工作,就要学会思考并问为什么2416.浅谈软件测试用例编写及要点2717.什么是探索性软件测试2718.关于接口测试2819.由单元测试看功能自动化软件测试2920.从BUG的“一生”闲谈软件测试工程师面试3121.关于API测试3322.软件开发中的破窗效应3423.软件测试管理之绩效考核3724.软件测试的Bug统计是在浪费时间3925.聊聊自动化软件测试为什么推广难4226.回归测试的策略及方法4327.基于会话的探索性测试管理4528.软件测试人员的核心技术能力,应该是什么?4629.如何入门软件测试的职位

3、4730.需求的来源4849Testing1.测试组是助力研发软件质量还是拉软件周期后腿?软件测试团队作为软件研发部门的一个组成部分,一度听到的都是软件测试很重要,要重视软件测试。可在当下现实环境中,你有想过软件测试也会拉后腿?!  当研发团队中开发人员资源比较紧缺,而任务比较重,项目比较急的情况下,若全部经过测试组,在软件质量保证的同时,必然出现了软件周期延长,项目上线延迟的问题。倘若测试人员对任务周期安排不恰当,对很早提交的任务进行测试,发现问题让开发人员重新熟悉程序进行解决,又必然占用大量精力和时间。在开发人员原本就很

4、紧张的情况下,加剧了问题的严重性。  这就出现了测试组测与不测的问题。若测试,软件周期太长,影响项目上线和客户使用;若不测,软件质量没保证,影响上线维护和客户使用。这是一个很矛盾的问题。  有一个解决方法,任务开发完直接升级到现场,由开发人员和设计人员进行测试验收。这样测试组干嘛?  为什么会出现这种问题呢?  很显然,开发人员紧缺是个很关键的问题,因为开发人员既要开发代码,也要改代码bug,还要支持现场代码版本等问题。所以开发人员可以不充裕,但是不能紧缺。可能目前还存在开发人员技术水平和业务经验的问题,这也影响了开发速度和

5、开发质量。  另外,说说测试组吧。曾经测试流程出现过问题,测试组在家里测过的程序升级到现场仍会出现不可用。后来改进流程,程序升级至现场测试环境进行测试,增强程序运行环境真实性和程序版本兼容性。现在面临的上述问题,跟测试组本身也有很大关系。  从两方面讲,第一缺乏技术含量。为什么开发人员不能缺,而测试人员可以没有。因为测试人员目前所做的大部分工作可以被开发人员和工程人员所取代,只是不那么全面专业罢了。测试人员没有自己特有的测试技术。有的话可以说是对业务逻辑的测试经验了,但是我仍然认为这不是真正的测试技术。不要怪我讲的这么露骨,

6、我认为这是事实,不用掩饰的。  第二不了解实际需求。尽管工程人员做的测试可能相对没那么全面,但是他们至少比我们更清楚客户的实际需求。他们可以避轻就重的进行测试,这样就可以满足客户使用的主要功能没有问题,其他小问题慢慢解决了。作为测试人员,要尽可能测试全面,不遗漏任何功能点,因为不清楚客户实际会怎么使用。这种方法和思想是正确的,只是在项目中客户群体比较小和使用频度不高的情况下,相对花费了不少时间。2.关于软件项目后期Fixbug的意义之我见众所周知:基本上所有的软件项目到后期必不可少的是fixbug,一个软件在交付客户后或交给

7、测试人员测试时都存在一些程序员意想不到的问题。现在有一些成熟的bug跟踪系统,譬如:bugzero,bugzilla,redmine等等。49Testing  解bug是很头痛的问题,一般是以下原因引起的:  (1)设计上的缺陷;  (2)写代码时考虑不周全;  (3)测试人员无中生有;  (4)所依赖的插件,框架本身的缺陷。  第一种情况:最棘手,需要修改程序架构,费时又费力,但是不改又不行总不能要客户该需求,按照你的程序来吧。没办法,改吧。  第二种情况:还好,看看是那里出来问题,改改代码就可以了,但是改完后需要确认一下

8、会不会对其他模块或功能造成影响。一般如果影响很大的话,那就是模块之间的耦合度太高,不是高质量代码,会越改越乱。  第三种情况:  a、撰写需求文档时,对软件需求设计模糊不清,让人产生歧义。譬如在编写需求文档时考虑不周留下让人发挥想象的空间,或前后矛盾。  b、测试人员或者软件开发人员对没有

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。