这些提高摸鱼效率的自动化测试技巧，提高打工人幸福感~

目录

一、技术手段是否能提高效率

二、一线人员分析工作耗时的原因

三、规范测试流程，借助技术方案进行卡口

容我废话两句
哈喽，兄弟们！

最近有许多小伙伴都在吐槽打工好难。

每天都是执行许多重复的任务

例如阅读新闻、发邮件、查看天气、打开书签、清理文件夹等等，

使用自动化脚本，就无需手动一次又一次地完成这些任务，

非常方便啊有木有？！

今天就来和大家一起学习一下，

用这些小技巧提高工作效率~ 快乐摸鱼~

一、技术手段是否能提高效率

 工程测试过程中，不可避免地会遇到构造测试数据的问题，如果业务比较复杂，构建测试数据将十分耗时。若不借助技术手段，走正常的业务流程去构建数据，那将会非常缓慢。曾碰到过这样的现象，新进公司后，先接触到业务测试，在接到测试任务后，需要构造相关的测试数据，就如何去构建老同学。于是他发给我一串接口测试工具请求文件，要做很多修改，然后发起请求，才能构造出相应的数据。首先不说方法比较笨拙，修改相关的请求时，需要先了解什么接口构造什么数据，以及接口的参数，这个开销还是比较大的。对数据构造平台的开发仍然十分重要，减少操作，提高效率。您是否需要在公司的测试环节中进行分析，采用什么技术可以完成什么工作?开发测试工具，通过相应的技术，减少测试步骤，提高测试效率。

二、一线人员分析工作耗时的原因

演讲结束后，根据项目的需要，开发同学和测试同学进行排期，然后按照排期推进项目。但在推进过程中，真的进行了按排期吗?是否曾发生项目延期提测的现象?考试期间，考试的同学们是否按照计划考试。由于测试环境、测试数据等问题会影响测试吗?曾碰到过一个大项目，在项目进度后，总是反馈测试任务重，不能按时完成，需要增加测试人员。周末加班加点情况比较严重，挺痛惜参加项目的同学，结果真正投入到项目中后，发现在开发中，测试人员部署了环境问题，因为环境问题要花上半天时间才能进行测试。影响工程进度的一个重要原因是，类似这样的问题，必须专门化地解决，否则投入多少人力也无济于事。

三、规范测试流程，借助技术方案进行卡口

 在测试过程中，一个规范的测试流程非常重要，例如，是否开发自测试项目需要回归到测试?未经过测试的开发同学是否可以发行产品?产品是否可以在测试环节修改需求，或者开发增加新功能?在线时能不能带上其他未经测试的在线功能呢?当然，如果你不是一个新手，上面的答案应该是否定的，但如何确保测试流程的规范，并且相关的参与者将严格执行?在没有卡口的技术方案下，很难保证流程遵守，必须借助与发布平台类似的工具规范过程，如果前面的环节没有通过，后续环节就无法执行。假如你还没有这样的工具平台，建议还是花时间来引进或者开发一个吧，投入产出比比较高。

1. 存储过程和数据订正脚本如何测试？

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.分析系统特性，制定计划。

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进行监督的重要依据，为项目负责人提供软件质量信息的报告。

22. 如何在QC的管理下实现自动化测试脚本之间的参数传递

在QC管理工具中，有一项功能叫做Test Lab（测试实验室），通过该实验室，我们可以将一个业务流程中存在的多个基本功能的测试脚本组合起来，对整个业务流程的实现进行检测。而在测试过程中， 有可能会在测试脚本之间实现参数的传递。例如：A脚本申请了一个基本客户采购服务，系统内部根据已有规则产生相应的一个采购服务单据编号。而在B脚本中， 将会调用该编号对采购服务单进行查询和其他操作。该编号能否利用QC测试管理工具在A、B两个脚本之间传递，如何进行？

23. 常用软件缺陷预防技术和缺陷分析技术有哪些？

24. 如何衡量测试效率？

一是利用客观数据，比如每天跑多少case，每天报多少bug，编写case的速度数量及质量...这些都体现一个测试人员的素质，基本上测试经理都通过这些基本方法观察团队成员的工作。
有了数据就有了比较，你跑得case比人家快，报得bug比人家多，确实能令人感到些许自豪感。 
但是就像楼上几位说的确实有漏洞导致衡量方法不是很全面很合理，不过目前这还是评估一个测试人员效率的主要手段。

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

关于提高效率...
管理好测试数据，可能你会参与到多个项目中，每个项目又有区别，甚至每次测试都有区别，一大堆的测试准备数据，测试文档，甚至与测试相关的其他信息，比如邮件，聊天记录等等。这就要求你将日常工作中的分类、记录以及有效的存放管理，以便用时很快的找到。

团队协作，有时你苦想三天的问题其实早就有人知道怎么解决了~结果你没提出来，白白浪费时间。 
还有就是也不能什么问题都拿来问，容易让人觉得很傻很天真，而且有时也会打断别人的思路，影响别人的效率，所以还是自己先找找答案吧先。有一公司老总跟我 说他们公司新来一女员工，什么都问，什么都得教，最后教完了还是什么都不会，有一次吃饭的时候甚至还问他是用勺还是用筷子吃... 

有时要求你对team里的其他成员有基本的了解，谁负责哪方面工作，相关的测试文档以前是谁写的等等，保证出现问题能够很快的找到责任人、原因及解决办法。
令我最记忆犹新的一次，在一个团队里，有一天开发人员突然站起来吼了一句，谁把数据库删了~:L 然后全场鸦雀无声，最后也不知道谁删的，还好有个几天前的备份数据库，否则大家可能整整一天都可以歇着了。不过还是造成了一定损失。

最后就是利用工具，有时在一些手工测试很浪费时间人力及成本的地方，比如回归测试，那么自动化工具或框架对项目的贡献度是很高的。而且有时必须引入一些工具，所以一些bug管理工具，case管理工具，项目管理工具，性能测试工具，功能自动化工具便应运而生。
提高工作效率的问题就变成高效使用工具的能力了，这里就要求更快的学习以及操作熟练度。
粗略算一下，假如1个人1天跑40个case，一个模块有100个case，有30个模块。那么需要这个人跑75天...要是项目再分成多个阶段，每个阶 段都要回归测试并加入新的测试，那么...写到这里我突然猜测这会不会是现在软件测试这么火并且各个公司都狂招测试人员的一个因素呢？ 
利用自动化，我想不光是提高效率的问题，更是一种测试思路的改变。
但是切忌自动化如果在build版本变化很快的情况下并不适用，也许等你录制完操作，编写好脚本，build就变了，结果你还没测呢...

如果这篇文章对你有帮助，请给小编点个赞！👍这样我才有动力继续更新下去！

今天的小知识学会了么

欢迎在留言区跟我们互动噢~

觉得有所帮助的话点个赞呗

最后是小编自己整理的一些学习资料、测试工具、课件、笔记相关资料点击下方小卡片