（2）测试数据

　　测试数据需要完整，如在某输入框中输入数据，需要写明需要输入的内容是什么，是“abcdefg”还是“1234567”，输入的账号也需要写明是什么账号，而不是写“输入正确的账号”，在别人测试过程中，是不知道什么才是正确的账号。如果这个账号不会变动（如管理员账号），则在测试数据中需写明“输入账号：admin，密码：123456”，如账号是常变动的（如用户账号），需在测试用例的前置条件中申明账号的可用性，如前置条件中写“系统存在账号为user123，密码为123456789的用户”，这时在测试数据中可以写“试用账号user123，密码为123456789进行登录”。

　　总之，写测试用例的时候，注意仔细与严谨。时常检查自己写的测试用例别人是否也能看懂。小组中有多么测试人员的，需要时常对测试用例进行评审，从而保证测试用例的高质量。


　　BUG单

　　提交BUG也是一门功课，既要简单易读，又要能说明问题。所以需要在BUG单中写清楚复现的步骤，错误出现的频率，严重性和优先级，一个BUG单讲述一个问题，不可将多个问题写于同一篇BUG单中，BUG单中需注意语气，不得带有情绪，如果BUG存在争议，需要提供证据进行证明，如需求说明说，可以咨询需求人员，如果什么都没有可以参考行业软件规范。

　　我谈一下我在实际项目中遇到的一些问题，一次参加客户方关于提交BUG单规范的会议，发现了如下问题：

　　（1）客户方想只使用一个数值，来定义严重性和优先级。真是不应该的，严重性和优先级是两个不同的概念，严重性高的BUG不一定优先级高，而严重性低的BUG很有可能优先级是高的。如一个很少用的功能在一定的操作下会导致程序无响应，但是决定在下一个版本再进行修复，则它的严重性虽然是高，但是优先级确是低，而一个马上要投入使用的功能点中，页面上显示的标题不正确不影响使用，虽然严重性是低，但优先级确实高。像这样的情况使用一个数值便很难描述出BUG的严重情况和优先情况。

　　（2）客户方的部分测试人员认为一张表单上的3种不同类型的问题可以写在一个BUG单上。这也是不可以的，有时候虽然是一个页面上的，但有可能3个错误点是由3个不同的开发人员开发的。这时，让一个开发修改完成而两个开发未修改时，无法正确调整BUG单状态，导致测试进度收集也不完全，很难定位到还有多少问题需要修改。

　　（3）客户方将BUG的数量和测试人员的效益与开发员工的效益挂钩，这个在管理中也是万万不可以的。会导致大量BUG冗余；开发修改大量严重程度非常低的小BUG导致延缓整个项目的进度；很少有测试人员会花更多的时间去找难以发现的BUG；造成开发和测试之间如仇家等等的问题。

　　（4）自动化

　　在进入公司后，客户方交给了我一个非常艰巨的任务，要做现有系统的自动化测试平台。还好对QTP比较熟悉，到目前为止，已经写好BPM 1.0系统的自动化测试框架，和不少表单脚本，并将BPM 1.0的脚本经过修改后，复用至BPM 2.0版本。

　　如何进行自动化测试框架的搭建，我会在以后的文章中写明。

　　所以在这里，我说几点关于自动化测试的一些简单的知识和我的一些经验。很明显，自动化测试从字面上来理解，是让电脑自动完成所需要的测试内容。如填写表单的测试，我可以预先将所要填写的内容写好，然后下班后，让电脑自动逐条进行填写，提交，记录测试的结果。看似很酷，但需要考虑的问题很多，主要的是，需要有一定的编程基础，毕竟，脚本是要靠“写”的。在很多网友来信中发现，很多人对自动化的理解和自动化所能做的功能有一点偏差。主要有以下几点：

　　只要开发出强大的自动化测试脚本，能将测试人员解放出来。其实不是的，很多的测试都是靠手工进行测试，自动化只是辅助。比如页面的排版是否好看，第一次测试时遇到的各种各样的问题，因为开发做了较大的改变等等一些问题时，自动化的执行会失败。

　　对于需求会经常修改的系统如何进行自动化脚本的编写。对于这样需求会经常变动的系统，不能开展自动化测试，还是老老实实的进行手工测试吧。

　　在软件测试理论知识还不是很牢固的情况下，不要进行自动化。对软件测试和自动化测试的错误理解会导致后期自动化进行十分的困难且根本没办法维护脚本。

　　在软件版本还没有稳定的情况下，不要进行自动化

　　领导不支持的情况下，不要进行自动化

　　系统中测试对象基本可以正常识别的情况下才进行自动化脚本的编写。

　　自动化测试一般的情况下是用来证明软件能正常运行，而不是用在证明软件这么操作一定会出错上。

　　记住，自动化测试主要的是提高工作效率，正确的使用是，用1天开发一个脚本能用3个月的测试，而不是花3个月开发出一个很牛的脚本来测试1天，非常多初学者会范这个错误，我曾经也范过。


　　分析

　　学会分析数据也是软件测试中必要的一项。的软件测试人员能通过各种数字，得到当前系统的各种信息。在性能测试中，分析数据显得尤为重要，一个做金融保险类系统性能测试的前辈和我说过，做性能测试，用使用Loadrunner，编写脚本设计场景，学的话几个月能搞定，但是分析执行脚本后的数据，可能需要2-3年的工作经验，才能看到你想看到的信息。

　　说些简单常用的，通过分析BUG数据，发现很多有用的信息。如：当系统刚刚开发完成，交给测试人员进行测试的时候，BUG数量一定是呈上升趋势，如果上升趋势不明显，一定是还没有做更完善的测试，说明需要投入更多的测试，随着测试的进行，BUG数量会成下降趋势，经过开发的几次调整，测试的几轮复测，BUG数量走势会在经过几次小波动后，趋于稳定，通过这些数字，可以清楚的了解测试的进度，测试何时需要加强，何时可以退出，何时可以自动化的介入，何时可以开始进行性能测试压力测试等。

　　同样的BUG单的数据，通过BUG单上模块进行分类进行分析，会发现80%BUG会出现在20%的模块中，这也是经典的“二八原则”，对于拥有80%错误的20%模块，测试人员需要进行更多的测试，很有可能有更多的错误藏在这20%的模块中。这样可以划分出测试的轻重，从而能更加好的计划出测试投入的时间。


　　书写和演讲

　　测试人员平时会遇到很多需要书写文档的地方，如：测试计划文档、测试总结报告、测试用例、自动化测试用例、自动化测试报告、性能测试报告等，也需要开不少的会议，进行较多的报告演讲。这些也是一个测试人员不可缺少的素质。

　　我总结的经验是：写报告要有理有据，图文并茂，提出一个点，需要给出足够的证据与分析过程来进行描述，而不是只写一个结论，要保证除测试人员外，开发、需求、架构人员也能从报告中，获取到相应的信息。至于演讲，尽量不要使用专有名词，简单明了，多做比喻，证据充足，由浅入深，才能让听的人接受你的观点，认同你的分析是正确的，能获得更多的帮助者与用户者，在日后的工作中，展开会更容易的多。

　　作为一名系统测试人员，还需要做到细心、耐心，多注意细节。平时也需要多做学习：系统的、网络的、软件的、硬件的、数据库的、语言的等等。总结也是必不可少的，把学到的、用到的知识，都记录下来，会对以后的工作带来非常多非常多的便利。

　　好了，也写了不少了，希望我写的东西，能对一些刚进入测试行业的、已进入测试行业的和一些像了解测试行业的一些开发一些帮助。

　　希望志同道合的朋友可以平时多交流，共同学习软件测试。

 

　　本文转自：http://hi.baidu.com/cydblack/item/2b5f2223f65110f851fd8709