或许项目组需要的不是测试，而是需要一个会写文档，有能力完成任务的人。 bug是造出来的，文档也是需要造的。实际如何，不必关注，只要弄个文档出来，交给领导看就行了。
组织架构调整了，换了老大，感觉这个老大有点压抑着我一方面又很多地方用到我，但是从不给我任何鼓励，貌似我做这些是应该做的一样，其实我同样需要认可跟鼓励。因为我不是工作狂，只知道做事情的那种。我现在分配到手里的三个项目，除此之外，还有一些短周期的测试任务，除此之外，还有很多杂事情需要协调处理，除此外还带了个徒弟，这个徒弟呢，不敢问别人，无论
服务器性能压力测试1.同场景承载人数（处理复杂逻辑，如打怪）2.并发操作，如登陆，打怪，聊天 ----增加多人同时跨场景的测试点 3.单服承载人数（处理复杂逻辑，如打怪）数据库测试1.并发读取数据（多用户同时登陆） ----增加数据库后台性能监控,cpu,内存占用等2.并发存储数据(多用户同时下线)3.增加服务器运行中，大规模数据的查询（为运营提供支
入行4年没有写过什么总结，现在没事干就随便写写咯。 1.新手最先看的就是项目的策划文档，还有早期测试员写的测试用例。（以此来熟悉这个项目的框架） 2.熟悉测试部门使用的工具（这个阶段必须掌握项目的BUG管理工具，测试工具） 2.熟悉项目的客户端配置，资源路径。（掌握所有的客户端知道每个配置和资源是什么用途，修改会影响什么。） 3.熟悉项目的服务器配置，服务器的资源路径，服务器与客户端搭配的各个文件
不只是会计，测试也应该会些哈~ 也许你已经在Excel中完成过上百张财务报表，也许你已利用Excel函数实现过上千次的复杂运算，也许你认为Excel也不过如此，甚至了无新意。但我们平日里无数次重复的得心应手的使用方法只不过是Excel全部技巧的百分之一。本专题从Excel2002中的一些鲜为人知的技巧入手，领略一下关于Excel的别样风情。 一、建立分类下拉列表填充项
最近在一本书上看见“测试用例是设计出来的，不是写出来的”。我的理解是，测试用例不是翻译需求文档，不是简单的把需求文档中的内容分成许多模块。而是根据需求文档，设计出有效的测试用例，即覆盖需求文档中的所有要求，也要包含隐含的功能（比如：可用性、性能、安全、可恢复等等），及一些破坏性的操作，程序对异常操作的处理；另一方面，要考虑测试的方法和测试用例模块的分配，尽可能将相似的测试放在一起，这样可以提高测试
最近感觉到在团队中慢慢的被边缘化，是因为做的东西不是最核心的东西，领导肯定是会把重心放在最重要的地方，但是我们做的事情也是必须有人要做的，陷入了这种苦恼中，我很不擅长对上沟通，也不会把心里的话说给头听，我知道这事沟通大忌，但是我就是做不到。。。
刚才又接了个电话面试，真它NND丢人，人家问测试用例的内容，我说了半天把预期目标和测试结果这么重要东西都忘了，人家提示了还说不出名字，丢人丢到姥姥家了，虽然没说什么，估计是被鄙视了。来吧，大家都来鄙视我下吧。不过鄙视之余一定要告诉我，你们做测试对BUG的定位到哪里？真的是到有问题的代码行吗?
本人刚进测试行业，想向自动化方向发展，感觉自学难度非常大迷茫中，有哪位大虾能出来指教
1. Windows性能计数器分析 对象 计数器 分析 processor %processor time 建议阈值85% memory Available bytes 建议阈值少于4MB需要添加内存； 另外，又建议至少要有10%的物理内存值 Pages reads/sec Page Reads/sec 是指为解析硬页错误而读取磁盘的次数，如果该值一直持续较大，表
