既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
**2.**软件测试的目的到底是发现软件的错误还是检验软件是否符合用户规定的需求或是弄清预期结果和实际结果之间的差距?
**3.**如何设计或者挑选有效的回归测试用例？
随着系统的逐步成熟，每个版本包含的新特性越来越少，但是新功能对原系统的影响有多大是我们在测试时需要重点考虑的问题。此时，就势必要进行回归测试。而 且系统越成熟，回归测试的比重也会越大。这将会对测试工作带来不小的挑战。在实际工作中，经常是一方面求全，希望覆盖面尽量广，避免漏测。另一方面求产 出，大量的回归测试用例，可能只发现很少的问题，投入与产出不太匹配，会影响测试人员的士气，甚至测试管理者也会对这种投入产出有所质疑。并且，设计大量 的自动化测试脚本，会占用大量的时间。
**4.**如果在测试过程中遭遇到需求变更，怎么做，才能最好完成对变更后的软件测试任务？
1）一般公司的解决方法是改变一下原有的流程，测试计划的工作可以跳出细节,只描述框架。然后十分细的测试用例等待开发过程中在同步编写。关于这种风险,真正要治理,需求阶段，大公司就要多评审,小公司就要勤开会确定和交流需求了。需求变更申请确定后，一定要把它记录下来，归在需求变更文档中，以备日后追查。
2）限定开发人员提交测试版本的周期。不要一有修改，就提交给测试一个新版本，使测试人员做过多的重复工作。
3）按照公司制定好的制度来按部就班的规范项目，项目经理的管理风格（如项目组召开例会，各方人员充分参与需求沟通会议，需求变更后更新的文档及时发送），测试人员主动性
4） 在设计自动测试剧本时，试图使其有一些灵活性。
在对应用软件进行自动测试时，要把注意力集中在看来不大会改变的部分。
对变更进行适当的风险分析，以减少回归测试的要求。
5）对于测试人员来说，最为重要的一点其实就是心理的适度调整。需求的变更导致自己的很多工作都成了无用功，很多东西要从头做起。但是一定不要抱怨，因为那样解决不了问题，事实就是事实。已经无法更改。要有积极地心态，全新的去面对新的需求。分析，设计，一切重来。
**5.**如何根据不同的项目制定不同的测试流程？
**6.**如何发现客户端软件中的内存泄露？
C/S模式下的软件的话,使用一些专业的内存检测工具, purify、boundchecker都可以
B/S模式下的软件,可以使用LR,在LR运行的时候,查看操作系统性能计数器中的Private Bytes(Windows)和Resident size(KB)(UNIX/Linux).
要测试客户端是否存在内存泄露,其实原理都一样.
我们要换位思考,把服务端当成客户端来发送请求,客户端做为服务端来接受请求.我们要多做一个工作就是除了要监控服务器端还要监控客户端的计数器信息.以下是简单的步骤:
step1:场景设计
step2:脚本录制和完善
step3:计数器的选择(特别是客户端计数器选择:在windows自带的性能监控器里一般选择监控某个process 的private byte & virtual byte2个计数器)
step4:运行场景
step5:监控测试
最后关于场景的运行时间,在适当的压力下,我们一般选择运行72小时.
从之前的测试经验来看,我们发现内存泄露一般都发生在场景运行的前10个小时之内.有的甚至在一个小时之内就发生了内存泄露.
客户端内存泄漏，公司一个用VC++开发的产品遇到过此类问题。
1.BoundsChecker；
2.调试工具包Debugging Tools for Windows (x86)下的 windbg.exe和Gflags.exe；
3.Pageheap.exe；
4.Windows自带的性能监控器perfmon；
5.C++ Test；
6.Rational PurifyPlus；
以上这些工具更多是调试用的，需要源代码，对开发人员可能用处更大些
7.和开发人员沟通，获得最有可能发生内存泄漏的模块或功能点，再执行测试；
8.分析系统特性，制定计划。
| 如果是用C语言编写的话，在开发的时候需要代码走读或者用purify来检查 1、用malloc或new申请内存之后，应该立即检查指针值是否为NULL。防治使用指针值为NULL的内存。 2、动态内存的申请与释放必须配对，以防止内存泄漏。 3、用free和delete释放了内存之后，立即将指针设置为NULL,防止产生“野指针”。 4、不要忘记为数组和动态内存赋值。 5、避免数组或指针的下标越界，特别要当心发生“多1”或者“少1”的操作 |
**7.**如何衡量测试效率？
1）发现缺陷的质量； 2）测试的有效性； 3）测试组员交叉测试，发现漏测问题数量；
4）遗漏到客户缺陷的比例； 5）递交的缺陷数量； 6）执行用例的数量；
7）编写测试文档的速度和质量； 8）评审发现问题的效率； 9）测试工具使用的熟练程度； 10）测试结果的分析水平；
**8.**如何提高测试效率
1）首先要有一个合理的详细的测试计划，测试任务尽量能细化到测试的功能和测试的case这个级别去监控进度；
2）测试尽早介入项目详细了解项目的业务需求，做好测试的前期准备、了解产品属性和准备测试数据；
3）对测试项目前景充满信心，调整最佳心态，保持愉悦的工作心情；
4）提高测试接受的标准，减少测试版本送测次数，一旦发现有重大问题，立即拒绝测试，送回开发人员修改。可以减少很多次反复测试，重复测试；
5）测试负责人认真做好测试文档的评审，尽量使用较少的测试用例，发现较多的Bug；
6）加强项目组成员的相互沟通工作和项目信息收集工作，测试工作是一项沟通要求比较高的工作，一般需要同项目经理、产品经理、开发人员、业务人员、客户沟通；
7）积极配合开发人员工作，努力赢得开发人员的尊重和支持，首先需要正视自己、改进自己，通过自身的不断努力让开发人员，真正体会到测试的价值；
8）按照项目的大小不同，必要的情况下引入自动化测试工具；
9）测试部门内部成员的工作业绩数据化，每天给每个人分配的任务非常具体，并且随时关注他们的进展情况，完成百分比，不断督促他们。并且，把每个人每天的工作成果（发现缺陷的数量和工作的质量） 数据化，通过邮件的形式发给组内的成员，让大家有个比较。大家都有自尊心，看到自己落后，后面就加油赶工，形成一种良好的测试氛围；
10）提高测试人员的专业技能和工作能力，不断的给自己充电，补充测试理论知识，让自己工作技术能力去弥补专业技能的不足
**9.**如何做好系统测试?
**10.**如何使自动化测试与手工测试达到最优的结合？
**11.**没有需求文档的时候如何来设计测试用例？
没有需求文档，最头疼的问题就是不知道开发的产品应该是个什么样，要完成哪些功能，达到什么指标。
在条件允许的情况下，可以通过与各方面的沟通，得到尽可能多的信息，总之一句话，有什么要什么，过程中我们要尽量避免想当然的思维方式。然后广纳建议结合QA对产品熟悉的基础上来确定一个比较粗的框架需求。在需求没有得到进一步确认之前，千万记住此时QA的主要工作应该只是写框架，而不是写具体到哪个button放在哪个位置。
办法一：由开发部门补充文档，可以不要求太正规，只要让测试员想得清楚：什么输入应该产生什么输出就OK了。查找其他相关文档。比如产品策划书、Feature List。
办法二：尽量多参加该项目组内的会议。比如需求讨论、设计讨论、计划讨论等会议，在对产品有了初步了解后，才有针对性的去咨询相关人员。
办法三：由开发部门做基本功能测试，测试部门补充用例；由于已有基本用例，测试员根据现有用例就可以判断程序功能。或者在程序员编码时，边开发边测试代码的基本功能，测试部门只是补充用例；与前者的区别是：前者是事后测试，后者是测试驱动开发。
办法四： 如果当前开发的产品是以前做过产品的升级版，或者和以前某个项目类似，这样就有个“demo”给你用，理解也更深入。
办法五：召集相关人员，对你整理的结果进行讨论。将测试需求点总结成文档，发给相关人员，包括项目负责人、市场部代表、开发人员等，让他们帮助评审check，根据意见对文档不断进行补充完善。当最后通过评审后，文档就可当作依据来设计你的测试用例了。
**12.**我觉得测试人员应做好以下几点：
1、掌握测试理论知识如测试概念、流程、目的、原则、策略、方法等等；
2、掌握html，了解css；
3、掌握c/c#/java语言的编程基础知识；
4、掌握测试文档如测试计划、用例、报告、使用手册等的编写；
5、掌握至少一个自动化测试工具及bug管理工具的使用；
6、掌握SQL Server/Oracle/Sybase数据库系统的使用；
7、掌握设计测试用例最常用的几种方法；
8、掌握与专业相关的英文术语，当然越多越好；
9、多上网或到图书馆查资料课外补充学习。
**13.**如何对测试过程进行可见的有效的管理？
**14.**如何对Bug进行清晰的描述？需要进行哪些方面的描述，即需要哪些关键的字段？
15. 在网站测试中如何做好安全性测试？
问题的题目： 在网站测试中如何做好安全性测试？该从哪些方面入手？
问题的描述：随着网络发展的趋势，对于网站的安全性的要求也越来越高，很多网站都存在被黑客攻击的漏洞，你在网站测试中有做到安全性测试吗？你觉得安全测试应该从哪些方面来检查？
16. B/S和C/S的架构测试有哪些测试点？两者的区别有什么？
在测试B/S架构和C/S架构的时候，有一些可以归纳的通用的测试点，比如UI测试，功能测试，异常情况下测试，不同ie，操作系统下测试，文档测试，安 全测试等等，我想请同仁们总结一下一个比较全面的测试点list，也可以稍微再细化些，这样大家在设计测试用例的时候，就可以在这个list上在不同的应 用上再做细分，避免一些遗漏，同时提高工作效率，另外测试B/S架构和C/S架构还是有一些区别和差异，比如C/S就要考虑安装测试，
17. 要清晰描述bug我觉得应写明以下4点：
1）bug发生的地方即在系统的哪个模块； 2）bug的优先/严重性级别； 3）bug产生的前提及后果，包括环境条件、操作步骤、非常影响等等； 4）是否可重现 另外再加上bug截图就会更让人一目了然了！
18. 如何在有限的时间内编写完整有效的测试用例？
19. 性能测试和压力测试的要点和常用方法？
20. 请问常用的缺陷统计分析的常用方法有那些？每个方法的作用?
21. 如何编写有效的测试报告？
测试报告是QA进行监督的重要依据，为项目负责人提供软件质量信息的报告。
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
辄止，不再深入研究，那么很难做到真正的技术提升。**
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
