软件测试员工作经验分享

　　结合自己8年的工作经验，自己也总结出来8各方面的能力，可能有些方面感觉要求暂时还达不到，但这些确实是做软件测试工作所必备的能力，掌握了这8个方面的能力，你就成为了一名优秀的软件测试工程师！

　　文章长度四千多字，耐心看完，全部是我的工作经验分享，绝对原创。（老规矩，思维导图在文末，需要原图的直接找我）

　　了解整个业务里面所需的数据有哪些？哪些是需要用户提供的？哪些是自己提供的？有哪些可以是假数据？有哪些必须是真数据？添加数据的时候可以用哪个库？

　　明白了整个软件的数据库架构，才能知道哪一个数据是从哪一个头带出来的，它的逻辑是什么，有没有连带关系。

　　用什么语言开发的？用的是什么服务器？测试它的话需要用什么样的进行测试？整体的测试是什么样的？

　　如果缺少了，需要进行搭建，架构搭建。一般去一家新公司之后，架构是搭建好的，了解它即可，熟悉之前的这些老员工们使用什么样的架构去做的。

　　整个软件有哪些模块，比如说首页面、注册页面、登录页面、会员页面、商品详情页面、优惠券页面等等

　　比如测一个网站的性能的时候，电脑的配置达不到测试并发5000人的标准，要么升级电脑的硬件配置，要么多机联合，多机联合时需要几台电脑，都需要提前筹划。

　　性能目标，比如我要达到并发5000人的时候，CPU占用率不能高于70%，内存占用率不能高于60%，响应时间不能超过5秒

　　功能目标，比如整体的业务流程都跑通，所有的分支流程都没有问题，所有的接口都能够互相调用，整体的UI界面没有问题，兼容性没有问题等

　　至少你要满足一般缺陷的发现能力，这个是最基本的，如果要连最简单的一般的缺陷都发现不了的话，别说优秀测试工程师了，你说你是测试我都不信

　　在软件的测试过程当中有一些缺陷藏的比较深，有的是性能方面的问题，有的是功能方面的问题，它需要有一些设定特定的条件的情况下才会出现这样的问题。

　　比如说买双鞋必须选择的是什么品牌，必须选择是红颜色，必须选择44号，而且必须选择用特定的支付方式才会出现这样的bug的时候，那么这种就属于特别隐性的bug，对于这样的问题的发现能力一定要比别人更强，要找到一些别人可能发现不了的bug

　　当发现了一个缺陷之后，能够想到通过这个缺陷可能会引发其他哪个地方出现问题，这就叫做连带的问题。而不是说发现这一个bug之后提了这一个就算完了，一定要有一个察觉，可能其他地方也存在这样的问题。

　　有些软件里边可能有一些操作模块，或者是代码写的接口，表面上没有什么问题，但是它是有隐患的，比如说这个接口写的不稳定，当他传的数据有一些问题的时候，可能它最后返回的结果就是报错就是报404或者报乱码。

　　你必须要等到前端人员把每个界面都做好了之后才能进入测试，而我能比你早一个月进入测试了，然后我比你结束测试时间快一个月，而你又比我晚一个月，那么咱俩的薪资一下就拉开了

　　需要知道这个缺陷它到底是由什么原因产生的，是属于什么类型的缺陷，是ui前端人员做的问题，还是后台接口人员做的问题？

　　不仅要找到这个bug，还要知道这个bug产生的原因，这样的测试人员常棒的，而且很是受人尊敬，提bug的方式也就不一样了

　　比如说测试在赶进度，或者这个软件项目的质量把控是一个团队来把控的，协助组员解决问题就显得尤为关键

　　一个团队里边的人员分工，他们的任务都是不一样的，这就是咱们说的配合。你的东西做完了，要轮到我了，我的性能测完了之后该轮到你了，所以整个的一个流程下来之后，大家应该是各司其职，配合得非常紧密的一个过程

　　我给你提bug，你改我的bug，咱们的目的只有一个，就是让这个软件变得更好，所以在这样的情况下，咱们就一定要配合开发

　　既然是一个团队协作的过程，就一定要互相的去督促对方，包括督促开发去改bug，因为开发人员他们有时候工作很忙，他们不知道要先改哪些问题，要后改哪些问题，但是往往有一些缺陷，它影响了测试的这个时间，影响了测试的进度，那么这个时候就需要测试员去督促开发人员，让他尽快的去解决你棘手的问题。这个东西能够提高咱们的测试效率

　　基础知识就是根基，根基打好了，你才能够更有效地往后期发展，也就是为了以后的学习做一个铺垫。如果根基都没打好，功能测试不会，就想直接学性能，那性能是做不好的

　　熟悉工具和熟练使用工具完全是两个概念，熟悉工具基本上等同于不会，遇到过很多简历上写会使用什么什么工具，都没有实际能力。比如loadrunner只会一个简单的，增强一下脚本，觉得会用了，那知识会用了1/5，其他4/5 都不会。

　　它是怎么样给服务器发送请求的，是用什么样的方式去发送请的，是用什么样的方式去的，它的操作原理是什么样的，咱们要把这件事情搞清楚，这样的话能有助于更好的去使用这些东西。包括一些请求的协议，每个协议代表什么意思，它是用来干什么的。

　　一定要能够自己完成一个的内容，的工作，这件事情领导你交给我好了，放心我能给你搞定，要的是这样的人

　　测试报告能够说明你表达的清不清楚？领导能不能看懂？还有就是能不能够把你整个测试的过程给它梳理得非常详细，人家能够通过你的报告，能够了解到整个的项目的情况，而不是只了解一个片面的情况

　　面试官也经常会给测试人去出一些逻辑题，逻辑题能够分析出来你这个人思维有没有？活跃不活跃？还有他的维度，包括他想的问题的全面性，都能够判断得出来。

　　要去测一个网站的逻辑的时候，一定要先思考这一个业务流程可能会涉及到哪些逻辑，这些逻辑哪些是可行的，有些是正向逻辑，有些是逆向逻辑，都要考虑全面，而不是说只是把正向的逻辑测试全面了，逆向逻辑不考虑。其实往往更容易出错的地方就是逆向逻辑

　　去测试的时候，不要仅仅只是站在测试人员的角度上去对整个网站进行测试，还更多的要站在用户的角度，要替用户考虑

　　在任何的企业里边去工作，肯定会遇到一些工作当中的一些不愉快的事情，而不是什么事情都会让你很顺心。所以要去处理工作上的一些不顺心的事情，不要把它带到你的工作上，或者是你的生活上，尽可能的去跟别人沟通，去解决这个工作上遇到的麻烦

　　在工作当中可能会涉及到跟开发人员的沟通，跟产品人员的沟通，跟ui人员的沟通，跟这三方的人员去沟通的时候，就要用不同的沟通方式

　　如果你觉得你的领导不好，或者说你觉得对你的领导一些，不要的去跟同事之间去说他或者怎么样的，领导需要的是解决问题的人，而不是制造问题的人

　　跟开发人员阐述缺陷时要简洁明了、清晰易懂。当发现严重缺陷时，也不要大惊小怪，要站在开发人员的角度思考如何解决问题。而不是踩在开发头上，炫耀自己发现问题的能力。

　　当对产品提出意见时，要站在用户的角度去说明自己的想法，而不要主观认为不好而要求产品进行修改。

　　跟领导沟通时要有大局观，不能只考虑自己部门的情况。并且与领导沟通时，尽量直奔主题，不要拐弯抹角，当与领导意见不一致时，也不要直接反驳，应该先给予认可，再阐述自己的想法。

　　在集体会议中不要一味的突出自己的个人能力，不要当话痨，也不要默默无闻。适当的提出一些自己的见解，有助于让大家更加重视你的存在。不要在多人会议中，去别人和推卸问题。各个部门的同事，都要面子~

　　与下级沟通时不要摆高姿态，不要让下级产生感，应该更多的为下级解决问题。服务好部门的同事，才能更好的产生凝聚力。

　　测试周期的时间控制，应当采取多种方法去衡量，例如人员能力，人员数量，项目复杂程度，同类项目的测试经验等多方面去衡量。

　　测试成本指的是人员成本跟时间成本，不要浪费每个人的时间跟劳动力，要让每个人充分发挥最大的价值。

　　测试计划对于一个项目是核心关键，它的存在为了让测试进行中有依据可查。所以测试计划，一定要切合实际情况，要经过思考和衡量最后得出计划安排。

　　组员的情绪可以直接影响测试进度跟测试的质量，当有组员出现思想问题时，应当及时沟通，采取一些必要的措施去解决问题。而不能装看不见。

　　任何项目在进行期间都存在许多潜在的风险，例如，人员离职，生病请假，业务变更，需求变更，服务器或其他组件故障等。应当提前做出相应的解决方案，以免到时候手忙脚乱。

　　测试的方向是指测试的目标和测试的范围，很多项目的测试是有针对性的，例如性能测试，所以在测试中，一定要随时清楚测试的目标和目的是什么，以免把时间浪费在无关紧要的业务上。

　　本文由325棋牌 （www.325games.com）整理发布