1、开始测试1年半左右，一直在做的是游戏测试。现在对于黑盒的游戏测试感觉到迷茫，对于做游戏的黑盒测试来说，技术成长性在哪里？哪些知识能更好的帮助自己的工作？是这样的，测试入门的门槛相对其他技术工种来说不高，但可以提升空间是很大的。黑盒也好，白盒也好，其实所描绘的是测试立场和角度，最早国外上世纪提出的 是基于开发者了解内部结构去寻找问题（谓之白盒），黑盒是使用者的角度，不需要了解内部结构去验收（谓之黑盒），如果以测试策略来描绘的话，这个就是PDCA,P前面的target，这个阶段的测试目标是什么如你所言，接触服务端测试接触到了lr的基础（压力测试及负载测试），服务端相关测试还有对应的window...

在之前的文章和视频中，我分享过Groovy语法中def关键字的基本使用方法。当时对def理解是：不定类型变量，资料中也有说是无类型变量，感觉两个意思大差不差，就是不显式声明对象类型。基本使用方式如下：def a = 1def b = "FunTester"类似这样的方式，当时Java新版也已经支持了var可以替代一些显式声明变量类型的代码，但是除了使用范围上，Groovy的def还是明显优于var，而且功能上也是强不少（当然有人理解为弱不少，后续讲解）。本质区别在于Groovy的def不仅可以替代显式的类型声明，还...

前言开发人员与测试人员齐心协力，相爱相杀， 荣辱与共，方能打造出优秀的产品。若是bug描述不知所云，bug修复仓促随意，bug管理如同儿戏，则金玉其外已是造化，败絮其中当属必然。bug描述好的描述能降低沟通成本，让人审题时如沐春风，解题时酣畅淋漓。bug描述的主体，应该包含如下部分：标题：指明所测模块，简明扼要地描述问题现象[前提条件] 说明完成测试的预设条件是什么[重现步骤] 句子简练，步骤清晰，表达无歧义[实际结果] 按照步骤执行下来，实际结果是什么；不要有主观色彩[期望结果] 正确的结果应该是什么；应该有说服力，不要唯经验论Tips:其他如所测版本，附件信息，bug优先级等，不一而足，也...

　　质量监控的范围和概念　　1.用户体验是否舒服：　　以用户的角度对产品进行使用，以找到不合理，体验差的功能点。　　2.产品设计是否符合：　　以产品的角度对产品设计的完整性进行检验。　　3.性能状况是否稳定：　　以系统运维的角度找到产品性能的瓶颈。　　4.逻辑设计是否存在漏洞：　　以开发人员的角度检测产品的逻辑合理性。　　5.系统安全，数据安全是否有保障：　　以不法分子，黑客的角度对产品进行攻击，以检测产品的安全性。　　测试用例设计方法：　　软测行内共识的设计方法不再赘述，转帖一篇文章小白们可以自己去看：　　测试用例的几种常见设计方法：　　已有的常规方法我们可以照搬照用，但是从质量管理的整体性...