一：软件测试的步骤是什么？
-
测试过程按4个步骤进行，即单元测试，集成测试，确认测试和系统测试及发版测试。
-
开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确的实现了规定的功能。
-
集成测试把已测试过的模块组装起来，主要对与设计相关的软件体系结构进行测试。
-
确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。
二：如何录制测试脚本？ -
新建一个脚本（Web/Html协议）
-
点击录制按钮，在弹出的对话框的URL中输入”about：blank“。
-
在打开的浏览器中进行正常操作流程后，结束录制
-
调试脚本并保存，可能要注意到字符集的关联
-
设置测试场景
-
针对性能设置测试场景，主要判断在正常情况下，系统的平均事务响应时间是否达标
-
针对压力负载设置场景，主要判断在长时间处于满负荷或者超出系统承载能力的条件下，系统是否会奔溃
三：应该考虑进行如何测试的测试方法？ -
黑盒测试：不考虑内部测试，只需要进行功能测试
-
白盒测试：根据软件的代码逻辑，按照代码的语句、分支、路径和条件进行测试
-
功能测试：一对一个应用软件的功能模块进行黑盒测试。这种测试应当由测试人员进行。但这并不意味着程序员在推出软件之前不进行自测
-
系统测试：针对全部需求说明进行黑盒测试，包括系统中的所有部件
-
回归测试：每当软件经过了整理、修改、或者其环境发生了变化，都重复进行测试，很难说明需求要进行多少次回归测试，特别是到了开发周期的最后阶段。进行次种测试，特别适于使用自动化测试工具
-
负荷测试：在大负荷条件下对应用软件进行测试。例如测试一个网站在不同负荷情况下以确定在什么情况下系统响应速度下降或者出现故障
-
压力测试：经常可以与”负荷测试“或者”性能测试“相互代替。这种测试是用来检查系统在下列条件下的情况：在非常大的巨大负荷下、某些动作和输入大量重复、输入大数、对数据库进行非常复杂的查询。
-
性能测试：经常可以与压力测试和负荷测试相互替代，理想的性能测试都应该在质量保障和测试计划的文档终予以规定
-
可用性测试：专门为”对用户友好的“特性进行测试。这是一种主观的感觉，取决于最终用户或顾客。可以进行用户会见、检查、对用户会议录像、或者使用其他技术。程序员和测试人员通常不参加可用性测试
-
安装/卸载测试：对安装/卸载进行测试（包括全部、部分、升级操作）
-
安全测试：测试系统在应付非授权的内部/外部访问、故意的损坏时的防护情况。这需要精密复杂的测试技术。
-
兼容性测试：测试在特殊的硬件/软件/操作系统/网络环境下的软件表现
四：怎样估计测试工作量？ -
效率假设：即测试队伍的工作效率。对于功能测试，这主要依赖于应用的复杂度，窗口的个数，每个窗口中的动作数目。对容量测试，主要依赖于建立测试所需要的数据的工作量大小。
-
测试假设：为了验证一个测试需求所需测试动作数目。
-
应用的维度：应用的复杂度指标。例如要加入一个记录，测试需求的维数就是这个记录中域的数目。
五：测试设计的问题？ -
不做测试设计，测试过程也是胡乱建立
-
测试设计不详细，不是基于可量度的测试策略，例如测试计划覆盖一个集合或者测试需求的一个子集
-
测试过程没有采用最好的技术来检验 Windows C/S 结构的测试需求
-
测试用例的选择规则
-
选择与测试需求的实质部分最相关的测试用例
-
选择的测试用例应该不容易应用程序的改变影响。
六：当测试过程发生错误时，有哪几种解决办法？ -
跳转到别的测试过程
-
调用一个能够清除错误的过程
-
退出过程，启动另一个
-
退出过程和应用程序，重新启动Windows,在失败的地方重新开始测试
七：测试执行的问题？
测试执行的问题： -
自动化测试没有有效的利用，使得手工测试太多
-
测试结果的捕获没有系统性，而且没有查看或调查
-
缺陷报告必须用手工加入缺陷跟踪系统
错误分类：
《1》测试用例失败
正常错误：
《2》脚本命令失败
当测试过程不能执行录制过程中的某个功能时，会产生这种错误，如鼠标单击按钮或选择菜单项等。它也能指示是缺陷还是测试的过程的设计问题。
《3》致命错误
导致测试停止，这种情况最好重启Windows。
具体步骤： -
建立测试系统
-
准备测试过程
-
运行初始化过程
-
执行测试
-
从终止的测试恢复
-
验证预期结果
-
调查突发结果
-
记录缺陷日记
)
