关于测试的问题（100分）

Question

谁给我讲讲怎么样能成为一个好的测试员，怎么做测试，测试一般都会测出哪些问题等，说的越多越好，本人刚做测试，想学习学习。辛苦各位。

Answer 1

好的测试员同时也是一个好的业务员和程序员要对整个程序的实现方式有了解，还要对业务有了解，什么样的bug严重，什么地方重要，什么是临界情况，这些都要心里有数才可以。

Answer 2

摘自
 liufei8463(武汉小兵) ( ) 信誉：100 
白盒测试.黑盒测试,单元测试,回归测试,自动化测试,这些你可以在网上查查,白盒是看代码.黑盒是测功能,单元测试是针对类或者函数,自动化测试是用一些测试工具,测试有临界值,空值,单纯的功能性测试比较容易点,还要学会写测试用例很精辟！ 

Answer 3

好的测试员不是测试出已经有的错误，而是测试出没有出现过的错误！！
跟做一个好的程序员是一样的道理，整天CTRL+C、CTRL+V就是你想得到的！！！

Answer 4

控件测试 
1．静态文本、标签，其作用都是显示一个静态的、用户不能改变的字符串。
测试对象： 
a．其所在的位置；包括对齐、文字大小、颜色、显示的边框等与整个界面是否协调。 
b．显示的字符串文字表达是否清晰，有无错别字、显示是否完全，有无中、英语言混排等。 
c．如果是某些控件的提示，则提示与控件的功能、作用是否一致，有时通过代码可以修改提示，这往往是根据用户的输入或选择来调整的，则检查是否及时地修改文字。 
d．有时，对静态文本进行了扩展，例如可以称为一个超级链接，链接到一个web窗口。所以还要检查选择前后的链接颜色是否改变等。 
2．文本框 
a．输入一个测试数据，验证正确。再次输入是否发生覆盖。 
b．输入中包含特殊的字符，例如空格、\n、™、【※※®§¶不可显示字符后，系统是否处理 
c．一些隐含的规则，例如：年销售额、应收金额、预收金额等需要限定输入数字的情况，检验保存前和保存后的格式是否有变化，经常会出现四舍五入、科学计数的情况。 
d．长度方面的测试，例如：没有输入、输入等于要求长度、超出长度等。一定要有该项的测试，否则容易出现界面变形的情况，最好是能在界面上进行限制。 
e．是否支持键盘快捷键，单击鼠标右键是否出来菜单，支持剪切、复制、粘贴操作否？ 
f． 违反规则后，系统给出的提示是否准确？用户能够理解？ 
3．命令按钮 
a．主要考虑控件上的文字、、多个按钮的格式、布局是否标准。 
b．对删除、修改等操作给予确认。 
4．单选按钮 
单选按钮通常表示一组相互排斥的选择。例如：选择表示时间的格式、对或错，男或女等。 a．在显示单选按钮时，一般都会给用户一个默认的选择，用户可以修改选择，修改后，原来的选中标识要取消。每个按钮都要至少覆盖一次。 
5．UpDown控件 ，如图所示： 
这种控件一般是循环控制，当显示的数字到达边界时，应该循环回到相反的边界。该控件中的编辑框，一般也允许用户输入。 
a．对该控件中的编辑框进行检查，比如该控件的范围为1－10，验证没有输入、输入等于要求长度、超出长度等三种情况，系统是否处理。 
b．编辑框中是空白时，按下上、下箭头如何反应。 
6．组合列表框，如图所示： 该控件一般在查询模块中出现， 
a．项目比较多时，验证是否容易查找，是否有模糊查找功能。 
b．有的编辑框允许用户输入，这样相当于一个编辑框，可以按照测试编辑框的方法进行测试，但是同时保证用户的输入是合法的项，是被系统所接受的。
7．列表框 
有多个下拉列表框同时需要选择时，验证一下保存后的信息是否跟所选择的信息一致。 
8．滚动条 
测试滚动条时，注意，滚动块的长度是否与被滚动的窗口中的内容对应，有时，滚动条还没有滚动到最下端，已经全是空白了，这样打开窗口时，往往给用户一个错觉。 
9．登陆窗口 
 a．输入正确的和不正确的用户名和密码，进行测试。 
b．密码的字符、长度有无限制。 
C．输入错误次数有无限制。 
d．输入为默认值、空时有什么现象。 
10．日期控件 
 a．在查询模块中，检查在查询前和查询后日期显示是否有变化？ 
在查询模块中，应该验证所有查询条件在查询前和查询后内容是否有变化。

Answer 5

1、测试准备工作 　　 在测试工作伊始，软件测试工程师应该搞清楚软件测试工作的目的是什么。如果你把这个问题提给项目经理，他往往会这样回答： “ 发现我们产品里面的所有 BUG ，这就是你的工作目的 ” 。作为一名软件测试新手，如何才能发现所有的 BUG ？如何开始测试工作？即便面对的是一个很小的软件项目，测试需要考虑的问题也是方方面面的，包括硬件环境、操作系统、产品的软件配置环境、产品相关的业务流程、用户的并发容量等等。该从何处下手呢？ 　　 2、向有经验的测试人员学习 　　 如果你进入的是一家运作规范的软件公司，有独立的软件测试部门、规范的软件测试流程、软件测试技术有一定的积累，那么，恭喜你！你可以请求测试经理委派有经验的测试人员作为你工作上的业务导师，由他列出软件测试技术相关书籍目录、软件测试流程相关文档目录、产品业务相关的文档目录，在业务导师的指导下逐步熟悉软件测试的相关工作。其实，在很多运作规范的软件公司，已经把上述的师父带徒弟的方式固化到流程中。 　　 如果你进入的是一个软件测试一片空白的软件企业，那么，也恭喜你！你可以在这里开创一片自己的软件测试事业，当然，前提是老板确实认识到软件测试的重要性，实实在在需要提高产品的质量。这时候，可以到国内的软件测试论坛和相关网站上寻找软件测试资源，这种情况下，自学能力和对技术的悟性就至关重要了。 　　 3、阅读软件测试的相关书籍 　　 现在，中文版的软件测试书籍越来越多，有的是国人自己写的，有的是翻译国外经典之作。可以到 www.chinapub.com 或者 www.cnforyou.com 等网络购书的站点查找软件测试相关的书籍。目前，从国外引入的软件测试书籍有很多经典之作，但是，翻译成中文后，翻译质量对阅读效果有很大的影响。 

Answer 6

4、 走读缺陷跟踪库中的问题报告单 　　 如果您所在的公司已经有软件缺陷跟踪库了，无论采用的是商用工具，如 ClearQuest 、 TestDirecter 等工具，还是采用的 Bugzilla 、 Mantis 等开源工具，这都无关紧要，缺陷跟踪库中的缺陷报告单才是有价值的。缺陷跟踪库中的问题报告单是软件测试工程师工作绩效的集中体现，同时也是软件产品问题的集中体现。一般来说，缺陷报告单中最关键的几个部分包括：第一部分是发现缺陷的环境，包括软件环境、硬件环境等；第二部分是缺陷的基本描述；第三部分是开发人员对缺陷的解决方法。通过对上述缺陷报告单的三个部分作仔细分析，不知不觉你已经吸收了其他软件测试人员的工作经验，并掌握了软件产品常见的基本问题。这是迅速提高软件测试经验的好方法。 　　5、 走读相关产品的历史测试用例 　　 如果你所在的公司有测试用例管理系统，那么，走读相关产品的软件测试用例是迅速提高测试用例设计水平的一条捷径。走读测试用例也是有技巧的。测试用例写作一般会包括测试用例项和根据测试用例项细化的测试用例，下面举例说明。 “ 测试用户登录的功能 ” 是一个测试项，该测试项的目的是测试用户登录功能是否正确，是否能够完成正常的登录功能，是否能够对非法用户名和密码做异常处理等等。因此，根据该用例项，可以设计出若干个测试用例，大多数情况下，测试用例项和测试用例是一对多的关系。 　　 通过走读测试用例项目，你可以掌握应该从哪些功能点着手未来的测试工作；通过走读软件测试用例，你可以了解如何根据被测试的功能点开展软件测试用例的设计工作，包括如何确定测试用例的输入、测试用例的操作步骤和测试用例的输出结果等。 　　 总之，走读其他软件测试人员设计的优秀软件测试用例，是提高自身用例设计水平的好方法。 　　6、学习产品相关的业务知识 　　 软件测试人员不仅要掌握软件测试技术相关知识，对产品相关的业务知识也要学习。这很好理解，如果从事财务软件的测试工作，一定要学习财务知识；如果从事通讯产品测试工作，那么相关的通讯理论知识也是必须的；如果从事银行软件的测试，银行的业务流程也是不可或缺的知识点。 　　 因此，在学习软件测试技术的同时，千万不要忽略产品相关业务知识的学习。如果你是一个软件测试技术专家，但是对产品业务知识一无所知，那么也只能测试出来纯粹的软件缺陷，而面对眼前出现的产品业务相关的缺陷，很可能是视而不见，如此这般，软件测试的效果会大打折扣。 　　7、 识别测试需求 　　 识别测试需求是软件测试的第一步。如果开发人员能够提供完整的需求文档和接口文档，那固然好。可以根据需求文档中描述的每个功能项目的输入、处理过程和输出，来设计测试用例。如果开发人员没有提供软件需求文档，那该如何是好？下面给出几个有效的方法： 

Answer 7

8、 主动获取需求 　　 开发人员通常不会更好地考虑软件测试，如果没有开发流程的强制规定，他们通常是不愿意提供任何开发文档，即便有强制规定，需求文档也未必能够真正指导软件系统测试工作。因此，需要测试人员发挥主观能动性，与相关的软件开发项目经理和软件开发人员保持沟通，了解软件实现的主要功能是什么，并记录得收集到的信息。一般来说，开发人员即便没有提供相关需求文档，也会保存一些简单的过程文档，主动向开发人员索要这些文档，可以作为测试的参考。此外，可以与公司的技术支持人员交流，技术支持人员是最贴近用户的人，因此，通过交流可以获取第一手的用户使用感受，在测试的过程中会更加贴近用户。 　　 当拿到相关的资料后，从哪些方面分析需求？如何与开发人员交流需求？其实，只要把握需求分析的几个关键的点就可以解决问题：输入、处理过程、输出、性能要求、运行环境，下面针对每一个项目逐一分析： 　　 软件输入： 与该需求相关的一切可能输入，可以从这几方面考虑，输入来源、输入参数的数量、输入参数的度量单位、输入参数的时间要求、输入参数的精度和输入参数的有效输入范围。在测试用例设计中，这部分内容作为测试用例输入的依据。 　　 处理过程： 描述对输入数据所执行的所有操作和如何获得输出的过程。测试人员了解处理过程即可，在测试过程中发现 BUG 时候，如果对处理过程了解的深入，对定位问题根源有很大的帮助。 　　 软件输出： 描述每个需求的输出结果，包括输出的位置（如计算机显示器、打印机，文件），输出参数的数量、输出参数的度量单位、输出参数的时序、输出参数精确度、输出参数的有效输出范围、错误消息。在测试用例设计中，这部分内容作为测试用例的预期输出。 　　 性能要求： 与该需求相关的性能要求，比如 “ 插入 ATM 取款卡后， 3 秒钟内弹出提示用户取款的图形界面 ” 。 3 秒钟这一限制，就是对需求的基本性能要求。 　　 运行环境： 软件的运行所需的环境，包括硬件平台的要求、操作系统的要求、数据库的要求，以及其它相关支撑软件的要求。 　　9、 确认需求的优先级 　　 确认需求的优先级是很必要的，如果在产品进度比较紧的情况下，测试人员可以考虑优先测试优先级高的需求项，如果进度允许，那么在测试优先级低的需求项，如果进度不允许，那么就放弃测试优先级低的需求项。如果软件公司有规范的流程支撑，开发人员在提供软件需求文档的时候，应该在文档中确定需求的优先级。但是，如果开发人员连基本的软件需求文档都没有提供，又怎能指望他们确定软件需求的优先级？如果是这样，需求的优先级只能由测试人员完成了。 　　 10、加入开发小组的邮件群组 　　 测试人员需要通晓被测试产品，但是，产品在开发的过程中往往是不断变化的。如果软件开发团队有一套变更控制流程，测试人员会对产品的变更了如指掌。如果没有变更控制，那就要采用其他的土方法了。如果公司里面有自动化办公系统，也许采用的是 Lotus Notes 系统，也许使用的是 E-mail 系统，测试人员应该加入到开发人员的邮件群组中。当开发人员通过邮件讨论问题、通知召开技术会议的时候，测试人员可以及时知晓，如果必要，可以参加开发人员的技术会议。即便公司里面有了软件变更控制流程，加入到开发邮件群组也是一个很好的习惯。 　　11、 与开发人员为邻 　　 建议测试人员与开发人员为邻。我所在的测试组曾经与开发组是在相邻的写字间里，开发人员与测试人员的关系非常融洽，抛去同事关系，大家还是不错的朋友。不管开发人员有什么样的活动，测试人员都能第一时间获得信息。无论从事软件测试工作，还是从事其它的工作，与工作中上下游环节的同事保持良好的个人关系对工作有很大便利。一般的公司内部都存在部门墙，良好的人际关系是打通部门墙的手段之一。向领导建议测试人员与开发人员为邻，这很必要。