请描述如何划分缺陷与错误严重性和优先级别？
给软件缺陷与错误划分严重性和优先级的通用原则：
（1）表示软件缺陷所造成的危害和恶劣程度。
（2）优先级表示修复缺陷的重要程度和次序。
严重性：
（1）严重：系统崩溃、数据丢失、数据毁坏。
（2）较严重：操作性错误、结果错误、遗漏功能。
（3）一般：小问题、错别字、UI布局、罕见故障。
（4）建议：不影响使用的瑕疵或更好的实现。
优先级：
（1）最高优先级：立即修复，停止进一步测试。
（2）次高优先级：在产品发布之前必须修复。
（3）中等优先级：如果时间允许应该修复。
（4）最低优先级：可能会修复，但是也可能发布。
一套完整的测试应该由哪些阶段组成？分别阐述一下各个阶段。
一套完整的测试应该由五个阶段组成：
1.测试计划
首先，根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求报告，即制订黑盒测试的最高标准，以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的。
同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。
2.测试设计
将测试计划阶段制定的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例（测试用例选择的好坏将直接影响到测试结果的有效性）。
3.测试开发
建立可重复使用的自动测试过程。
4.测试执行
执行测试开发阶段建立的自动测试过程，并对所发现的缺陷进行跟踪管理。测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成，测试人员应本着科学负责的态度，一步一个脚印地进行测试。
5.测试评估
结合量化的测试覆盖域及缺陷跟踪报告，对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。
一条软件缺陷都记录了哪些内容？
1.通用UI要统一、准确
缺陷报告的UI要与测试的软件UI保持一致，便于查找定位。
2.尽量使用业界惯用的表达术语和表达方法
使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化。
3.每条缺陷报告只包括一个缺陷
每条缺陷报告只包括一个缺陷，可以使缺陷修正者迅速定位一个缺陷，集中精力每次只修正一个缺陷。校验者每次只校验一个缺陷是否已经正确修正。
4.不可重现的缺陷也要报告
首先缺陷报告必须展示重现缺陷的能力。不可重现的缺陷要尽力重现，若尽力之后仍不能重现，仍然要报告此缺陷，但在报告中要注明无法再现，缺陷出现的频率。
5.明确指明缺陷类型
根据缺陷的现象，总结判断缺陷的类型。例如，即功能缺陷、界面缺陷、数据缺陷，合理化建议这是最常见的缺陷或缺陷类型，其他形式的缺陷或缺陷也从属于其中某种形式。
6.明确指明缺陷严重等级和优先等级
时刻明确严重等级和优先等级之间的差别。高严重问题可能不值得解决，小装饰性问题可能被当作高优先级。
7.描述 (Description)
描述要简洁、准确，完整，揭示缺陷实质，记录缺陷或缺陷出现的位置。
描述要准确反映缺陷的本质内容，简短明了。为了便于在软件缺陷管理数据库中寻找制定的测试缺陷，包含缺陷发生时的用户界面（UI）是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称。
8.短行之间使用自动数字序号
短行之间使用自动数字序号，使用相同的字体、字号、行间距，可以保证各条记录格式一致，做到规范专业。
9.每一个步骤尽量只记录一个操作
保证简洁、条理井然，容易重复操作步骤。
10.确认步骤完整
保证快速准确的重复缺陷，“完整”即没有缺漏，“准确”即步骤正确，“简短”即没有多余的步骤。
11.根据缺陷，可选择是否进行图象捕捉
为了直观的观察缺陷或缺陷现象，通常需要附加缺陷或缺陷出现的界面，以图片的形式作为附件附着在记录的“附件”部分。
为了节省空间，又能真实反映缺陷或缺陷本质，可以捕捉缺陷或缺陷产生时的全屏幕，活动窗口和局部区域。为了迅速定位、修正缺陷或缺陷位置，通常要求附加中文对照图。
附加必要的特殊文档和个人建议和注解。如果打开某个特殊的文档而产生的缺陷或缺陷，则必须附加该文档，从而可以迅速再现缺陷或缺陷。
有时，为了使缺陷或缺陷修正者进一步明确缺陷或缺陷的表现，可以附加个人的修改建议或注解。
12.检查拼写和语法缺陷
在提交每条缺陷或缺陷之前，检查拼写和语法，确保内容正确，正确的描述缺陷。
13.尽量使用短语和短句
软件缺陷管理数据库的目的是便于定位缺陷，因此，要求客观的描述操作步骤，不需要修饰性的词汇和复杂的句型，增强可读性。
简述一下缺陷的生命周期
打开：表示问题被提交等待有人处理。
重新指派：问题被重新指派给某人处理。
处理：问题在处理中，尚未完成。
固定：确认此问题存在，但暂时不进行处理。
回归：对已经修复的问题进行回归确认。
关闭：问题的最后一个状态。
测试用例设计方法都有哪些？
1.等价类划分法
顾名思义，等价类划分，就是将测试的范围划分成几个互不相交的子集，他们的并集是全集，从每个子集选出若干个有代表性的值作为测试用例。
2.边界值分析法
长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。
因此针对各种边界情况设计测试用例，可以查出更多的错误。选出的测试用例，应选取正好等于、刚刚大于、刚刚小于边界的值，例如，对于在区间min、max的值，测试用例可以记为min、min+、max、max-。
3.错误推测法
错误推测法是指：在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法。
4.判定表法
又称为策略表，基于策略表的测试，是功能测试中最严密的测试方法。该方法适合于逻辑判断复杂的场景，通过穷举条件获得结果，对结果再进行优化合并，会得到一个判断清晰的策略表。
5.正交实验法
用语言描述正交实验法会很抽象难懂，简单说，就是在各因素互相独立的情况下，设计出一种特殊的表格，找出能以少数替代全面的测试用例。
其中，上面所说的特殊表格就是正交表，是按照一定规则生成的表。
虽然说是特殊的表格，实际表现形式跟一般的表格没有什么区别，正交表的主要特征是，“均匀分布，整齐划一”，正是因为“均匀”的，所以才能以少数代替全部。
等价区间问题
一个文本框要求输入6位数字密码，且对每个账户每次只允许出现三次输入错误，对此文本框进行测试设计的等价区间有哪些？
1.密码为空 登录。
2.正确输入（输入正确的值）登录。
3.错误输入（输入错误的值，输入数据例如：特殊符号、英文字母、汉字及非法字符等一些非正确值；输入方法例如：不足六位，超出六位，最大输入值）登录/取消。
4.连续错误输入三次以上（查看连续错误输入后的提示信息及结果）。
5.其他（是否支持剪贴板操作，例如：复制/剪切/粘贴）。
什么时候开始进行性能测试？
性能测试一般分前期阶段和后期阶段。
前期阶段是功能实现后还没有到系统集成时期，可以针对功能实现进行性能测试，看看单独功能实现的响应时间。
后期阶段是指系统功能通过功能性测试完毕后，到整体的性能测试阶段。
什么是性能测试、负载测试、压力测试？
性能测试（Performance Test）：通常收集所有和测试有关的所有性能，被不同人在不同场合下进行使用，关注点：how much和how fast。
负载测试（Load Test）：负载测试是一种性能测试，指数据在超负荷环境中运行，程序是否能够承担，关注点：how much。
压力测试（Stress Test）：压力测试（又叫强度测试）也是一种性能测试，它在系统资源特别低的情况下软件系统运行情况，目的是找到系统在哪里失效以及如何失效的地方。
简述Loadrunner的步骤
使用LoaderRunner进行性能测试的几个步骤：
a、开发脚本（在Vugen中执行）：涉及到，脚本的录制、参数化、事务的添加、检查点的设置、同步点的设置。loaderRunner脚本是符合c语言语法的。
b、场景建立（在Controller中执行）：加入脚本（如果脚本中有集合点，应该然集合点在这里生效）、用户设置。
c、测试结果的分析。
