提高测试效率的方法

1、精选优质文档-倾情为你奉上1. 存储过程和数据订正脚本如何测试？2.软件测试的目的到底是发现软件的错误还是检验软件是否符合用户规定的需求或是弄清预期结果和实际结果之间的差距?3.如何设计或者挑选有效的回归测试用例？随着系统的逐步成熟，每个版本包含的新特性越来越少，但是新功能对原系统的影响有多大是我们在测试时需要重点考虑的问题。此时，就势必要进行回归测试。而 且系统越成熟，回归测试的比重也会越大。这将会对测试工作带来不小的挑战。在实际工作中，经常是一方面求全，希望覆盖面尽量广，避免漏测。另一方面求产 出，大量的回归测试用例，可能只发现很少的问题，投入与产出不太匹配，会影响测试人员的士气，甚至测试

2、管理者也会对这种投入产出有所质疑。并且，设计大量 的自动化测试脚本，会占用大量的时间。4. 如果在测试过程中遭遇到需求变更，怎么做，才能最好完成对变更后的软件测试任务？1）一般公司的解决方法是改变一下原有的流程，测试计划的工作可以跳出细节,只描述框架。然后十分细的测试用例等待开发过程中在同步编写。关于这种风险,真正要治理,需求阶段，大公司就要多评审,小公司就要勤开会确定和交流需求了。需求变更申请确定后，一定要把它记录下来，归在需求变更文档中，以备日后追查。2）限定开发人员提交测试版本的周期。不要一有修改，就提交给测试一个新版本，使测试人员做过多的重复工作。3）按照公司制定好的制度来按部就班的规

3、范项目，项目经理的管理风格（如项目组召开例会，各方人员充分参与需求沟通会议，需求变更后更新的文档及时发送），测试人员主动性4） 在设计自动测试剧本时，试图使其有一些灵活性。在对应用软件进行自动测试时，要把注意力集中在看来不大会改变的部分。对变更进行适当的风险分析，以减少回归测试的要求。5）对于测试人员来说，最为重要的一点其实就是心理的适度调整。需求的变更导致自己的很多工作都成了无用功，很多东西要从头做起。但是一定不要抱怨，因为那样解决不了问题，事实就是事实。已经无法更改。要有积极地心态，全新的去面对新的需求。分析，设计，一切重来。5.如何根据不同的项目制定不同的测试流程？6. 如何发现客户端软

4、件中的内存泄露？C/S模式下的软件的话,使用一些专业的内存检测工具, purify、boundchecker都可以B/S模式下的软件,可以使用LR,在LR运行的时候,查看操作系统性能计数器中的Private Bytes(Windows)和Resident size(KB)(UNIX/Linux).要测试客户端是否存在内存泄露,其实原理都一样.我们要换位思考,把服务端当成客户端来发送请求,客户端做为服务端来接受请求.我们要多做一个工作就是除了要监控服务器端还要监控客户端的计数器信息.以下是简单的步骤:step1:场景设计step2:脚本录制和完善step3:计数器的选择(特别是客户端计数器选择:

5、在windows自带的性能监控器里一般选择监控某个process 的private byte & virtual byte2个计数器)step4:运行场景step5:监控测试最后关于场景的运行时间,在适当的压力下,我们一般选择运行72小时.从之前的测试经验来看,我们发现内存泄露一般都发生在场景运行的前10个小时之内.有的甚至在一个小时之内就发生了内存泄露.客户端内存泄漏，公司一个用VC+开发的产品遇到过此类问题。1.BoundsChecker；2.调试工具包Debugging Tools for Windows (x86)下的 windbg.exe和Gflags.exe；3.Pageh

6、eap.exe；4.Windows自带的性能监控器perfmon；5.C+ Test；6.Rational PurifyPlus；以上这些工具更多是调试用的，需要源代码，对开发人员可能用处更大些7.和开发人员沟通，获得最有可能发生内存泄漏的模块或功能点，再执行测试；8.分析系统特性，制定计划。如果是用C语言编写的话，在开发的时候需要代码走读或者用purify来检查1、用malloc或new申请内存之后，应该立即检查指针值是否为NULL。防治使用指针值为NULL的内存。2、动态内存的申请与释放必须配对，以防止内存泄漏。3、用free和delete释放了内存之后，立即将指针设置为NULL,防止产生

7、“野指针”。4、不要忘记为数组和动态内存赋值。5、避免数组或指针的下标越界，特别要当心发生“多1”或者“少1”的操作7. 如何衡量测试效率？1）发现缺陷的质量； 2）测试的有效性； 3）测试组员交叉测试，发现漏测问题数量；4）遗漏到客户缺陷的比例； 5）递交的缺陷数量； 6）执行用例的数量；7）编写测试文档的速度和质量； 8）评审发现问题的效率； 9）测试工具使用的熟练程度； 10）测试结果的分析水平；8. 如何提高测试效率1）首先要有一个合理的详细的测试计划，测试任务尽量能细化到测试的功能和测试的case这个级别去监控进度；2）测试尽早介入项目详细了解项目的业务需求，做好测试的前期准备、了解

8、产品属性和准备测试数据；3）对测试项目前景充满信心，调整最佳心态，保持愉悦的工作心情；4）提高测试接受的标准，减少测试版本送测次数，一旦发现有重大问题，立即拒绝测试，送回开发人员修改。可以减少很多次反复测试，重复测试；5）测试负责人认真做好测试文档的评审，尽量使用较少的测试用例，发现较多的Bug；6）加强项目组成员的相互沟通工作和项目信息收集工作，测试工作是一项沟通要求比较高的工作，一般需要同项目经理、产品经理、开发人员、业务人员、客户沟通；7）积极配合开发人员工作，努力赢得开发人员的尊重和支持，首先需要正视自己、改进自己，通过自身的不断努力让开发人员，真正体会到测试的价值；8）按照项目的大小

9、不同，必要的情况下引入自动化测试工具；9）测试部门内部成员的工作业绩数据化，每天给每个人分配的任务非常具体，并且随时关注他们的进展情况，完成百分比，不断督促他们。并且，把每个人每天的工作成果（发现缺陷的数量和工作的质量） 数据化，通过邮件的形式发给组内的成员，让大家有个比较。大家都有自尊心，看到自己落后，后面就加油赶工，形成一种良好的测试氛围；10）提高测试人员的专业技能和工作能力，不断的给自己充电，补充测试理论知识，让自己工作技术能力去弥补专业技能的不足9.如何做好系统测试?10. 如何使自动化测试与手工测试达到最优的结合？11. 没有需求文档的时候如何来设计测试用例？没有需求文档，最头疼的

10、问题就是不知道开发的产品应该是个什么样，要完成哪些功能，达到什么指标。在条件允许的情况下，可以通过与各方面的沟通，得到尽可能多的信息，总之一句话，有什么要什么，过程中我们要尽量避免想当然的思维方式。然后广纳建议结合QA对产品熟悉的基础上来确定一个比较粗的框架需求。在需求没有得到进一步确认之前，千万记住此时QA的主要工作应该只是写框架，而不是写具体到哪个button放在哪个位置。办法一：由开发部门补充文档，可以不要求太正规，只要让测试员想得清楚：什么输入应该产生什么输出就OK了。查找其他相关文档。比如产品策划书、Feature List。办法二：尽量多参加该项目组内的会议。比如需求讨论、设计讨论

11、、计划讨论等会议，在对产品有了初步了解后，才有针对性的去咨询相关人员。办法三：由开发部门做基本功能测试，测试部门补充用例；由于已有基本用例，测试员根据现有用例就可以判断程序功能。或者在程序员编码时，边开发边测试代码的基本功能，测试部门只是补充用例；与前者的区别是：前者是事后测试，后者是测试驱动开发。办法四： 如果当前开发的产品是以前做过产品的升级版，或者和以前某个项目类似，这样就有个“demo”给你用，理解也更深入。办法五：召集相关人员，对你整理的结果进行讨论。将测试需求点总结成文档，发给相关人员，包括项目负责人、市场部代表、开发人员等，让他们帮助评审check，根据意见对文档不断进行补充完善

12、。当最后通过评审后，文档就可当作依据来设计你的测试用例了。12. 我觉得测试人员应做好以下几点：  1、掌握测试理论知识如测试概念、流程、目的、原则、策略、方法等等；  2、掌握html，了解css；  3、掌握c/c#/java语言的编程基础知识；  4、掌握测试文档如测试计划、用例、报告、使用手册等的编写；  5、掌握至少一个自动化测试工具及bug管理工具的使用；  6、掌握SQL Server/Oracle/Sybase数据库系统的使用；  7、掌握

13、设计测试用例最常用的几种方法；  8、掌握与专业相关的英文术语，当然越多越好；  9、多上网或到图书馆查资料课外补充学习。13. 如何对测试过程进行可见的有效的管理？14. 如何对Bug进行清晰的描述？需要进行哪些方面的描述，即需要哪些关键的字段？15. 在网站测试中如何做好安全性测试？问题的题目： 在网站测试中如何做好安全性测试？该从哪些方面入手？问题的描述：随着网络发展的趋势，对于网站的安全性的要求也越来越高，很多网站都存在被黑客攻击的漏洞，你在网站测试中有做到安全性测试吗？你觉得安全测试应该从哪些方面来检查？16. B/S和C/S的架构测试有哪些测

14、试点？两者的区别有什么？在测试B/S架构和C/S架构的时候，有一些可以归纳的通用的测试点，比如UI测试，功能测试，异常情况下测试，不同ie，操作系统下测试，文档测试，安 全测试等等，我想请同仁们总结一下一个比较全面的测试点list，也可以稍微再细化些，这样大家在设计测试用例的时候，就可以在这个list上在不同的应 用上再做细分，避免一些遗漏，同时提高工作效率，另外测试B/S架构和C/S架构还是有一些区别和差异，比如C/S就要考虑安装测试，17. 要清晰描述bug我觉得应写明以下4点：1）bug发生的地方即在系统的哪个模块；2）bug的优先/严重性级别；3）bug产生的前提及后果，包括环境条件、

15、操作步骤、非常影响等等；4）是否可重现另外再加上bug截图就会更让人一目了然了！18. 如何在有限的时间内编写完整有效的测试用例？19. 性能测试和压力测试的要点和常用方法？20. 请问常用的缺陷统计分析的常用方法有那些？每个方法的作用?21. 如何编写有效的测试报告？测试报告是QA进行监督的重要依据，为项目负责人提供软件质量信息的报告。22. 如何在QC的管理下实现自动化测试脚本之间的参数传递在QC管理工具中，有一项功能叫做Test Lab（测试实验室），通过该实验室，我们可以将一个业务流程中存在的多个基本功能的测试脚本组合起来，对整个业务流程的实现进行检测。而在测试过程中， 有可能会在测试

16、脚本之间实现参数的传递。例如：A脚本申请了一个基本客户采购服务，系统内部根据已有规则产生相应的一个采购服务单据编号。而在B脚本中， 将会调用该编号对采购服务单进行查询和其他操作。该编号能否利用QC测试管理工具在A、B两个脚本之间传递，如何进行？23. 常用软件缺陷预防技术和缺陷分析技术有哪些？24. 如何衡量测试效率？一是利用客观数据，比如每天跑多少case，每天报多少bug，编写case的速度数量及质量.这些都体现一个测试人员的素质，基本上测试经理都通过这些基本方法观察团队成员的工作。有了数据就有了比较，你跑得case比人家快，报得bug比人家多，确实能令人感到些许自豪感。 但是就像楼上几位

17、说的确实有漏洞导致衡量方法不是很全面很合理，不过目前这还是评估一个测试人员效率的主要手段。第二就是加入主观评判。我们经理就经常说要多报bug而且要报好bug.好bug意味着什么？首先是bug report的质量，bug的信息描述得很准确，很简洁很清楚，有时甚至要求测试人员很准确的找到导致bug的根本原因，要求你对项目很深的理解。有时项目进度很紧张，所以在这种时间敏感的条件下更要求要写great bug report。另外有时需要你很快的了解项目，很快的阅读test plan，test spec，并能够很快地写出test case尽可能多地覆盖spec嗯简而言之就是学习、领悟及创新创造的能力。

18、关于提高效率.管理好测试数据，可能你会参与到多个项目中，每个项目又有区别，甚至每次测试都有区别，一大堆的测试准备数据，测试文档，甚至与测试相关的其他信息，比如邮件，聊天记录等等。这就要求你将日常工作中的分类、记录以及有效的存放管理，以便用时很快的找到。团队协作，有时你苦想三天的问题其实早就有人知道怎么解决了结果你没提出来，白白浪费时间。 还有就是也不能什么问题都拿来问，容易让人觉得很傻很天真，而且有时也会打断别人的思路，影响别人的效率，所以还是自己先找找答案吧先。有一公司老总跟我 说他们公司新来一女员工，什么都问，什么都得教，最后教完了还是什么都不会，有一次吃饭的时候甚至还问他是用勺还是用筷子吃. 有时要求你对t