软件测试经验与教训

本文分享了软件测试的一些重要经验与教训,强调测试员应理解测试目标,避免过度详细的过程,正确分析和报告错误,不过度依赖错误跟踪系统评估程序员表现,关注极端情况下的安全漏洞,并明智地决定哪些程序错误需要修改。测试员的角色不仅是执行测试,更是推动产品质量的提升。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

#####经验43 测试员要避免遵循过程,除非过程先跟随自己

警惕其他人的过程。测试用例和过程的描述,常常不提测试的内部设计目标。这非常容易使测试员在执行测试时并不太理解如何建立测试、或寻找什么。换句话说,测试员并没有真正跟上过程。一般来说,测试过程的编写和设计都比较差,因为没有多少优秀测试员像擅长计算机那样擅长程序设计人员的工作。如果要遵循测试过程,最后采用自己设计、自己拥有或已经完全了解的过程。
为了得到最好的结果,测试员必须掌握自己的测试,而不是自己的文档。要使过程跟随自己。
如果确信那些过程很好,也至少要眼睛一下过程的工作原理。

个人见解:需要更多的了解程序实现原理,了解的越多也就能发现更深层次的问题。


#####经验45 在创建测试过程时,避免“1287”

我们中的bach曾经见过一位测试员编写的测试过程包含“在字段中输入1287个字符。”这1287是从哪里来的?测试员解释说,她的测试想法只不过是在一个小输入字段中,输入非常多的字符。因为他听说测试过程必须具体,因此小心的数量自己已经输入的字符数,1287.这就是过程中的这个梳子的由来。一个任意数,现在却被供奉起来,就像是印在水泥人行道上的猫的脚印一样。
过于详细的没有什么好处。当编写测试过程时,要避免与测试概念无关的的细化。包含所有必要的信息和设计与解释测试所需要的细节,但是要让未来的测试员有创造性的判断力地执行,让未来的测试员引入变化以使现在所编写的测试过程新鲜,高效。

个人见解:对这个经验深有同感。见过很多人写的测试用例,自己也写过不少的测试用例。很多时候发现用例写的很详细,完全不给执行人员思考的余地。导致用例执行完了还不知道程序到底做了什么,更别说有更深层次的思考。


#####经验56 测试员的程序错误分析会推动改正所报告的错误

测试员写的错误报告是要求改正错误的分析文档。
有些错误永远也不会

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值