1.1.1 做好软件测试的一些关键点
1. 测试人员必须经过测试基础知识和理论的相关培训。
2. 测试人员必须熟悉系统功能和业务。
3. 测试必须事先要有计划,而且测试方案要和整个项目计划协调好
4. 必须事先编写测试用例,测试执行阶段必须根据测试用例进行
5. 易用性,功能,分支,边界,性能等功能性和非功能性需要都要进行测试
6. 对于复杂的流程一定要进行流程分支,组合条件分析,再进行等价类划分准备相关测试数据
7. 测试设计的一个重要内容是要准备好具体的测试数据,清楚这个测试数据是测哪个场景或分支的
8. 个人任务平均每三个测试用例至少应该发现一个 BUG,否则只能说明测试用例质量不好
9. 除了每日构建的冒烟测试可以考虑测试自动化外,其它暂时都不要考虑去自动化。
1.1.2 软件测试的步骤是什么?
1) 测试过程按 4 个步骤进行,即单元测试(Unit Testing)、集成测试(Integrated
Testing)、确认测试(Validation Testing)和系统测试(System Testing)及发版测试。
2) 开始是单元测试,集中对用源代码实现的每一个程序单元进行测试,检查各个程序模块是否正确地实现了规定的功能。
3) 集成测试把已测试过的模块组装起来,主要对与设计相关的软件体系结构的构造进行测试。
4) 确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求,以及软件配置是否完全、正确。
1.1.3 如何录制测试脚本?
1) 新建一个脚本(Web/HTML 协议)
2) 点击录制按钮,在弹出的对话框的 URL 中输入”about:blank”。
3) 在打开的浏览器中进行正常操作流程后,结束录制。
4) 调试脚本并保存。可能要注意到字符集的关联。
5) 设置测试场景
6) 针对性能设置测试场景,主要判断在正常情况下,系统的平均事务响应时间是否达标
7) 针对压力负载设置测试场景,主要判断在长时间处于满负荷或者超出系统承载能力的条件下,系统是否会崩溃
1.1.4 应该考虑进行如何测试的测试方法
黑盒测试 (Black box testing) ── 不考虑内部设计和代码,根据需求和功能进行测试。
白盒测试 (White box testing) ── 根据应用软件的代码的内部逻辑,按照代码的语句、分支、路径和条件进行测试。
功能测试(functional testing)——对一个应用软件的功能模块进行黑盒测试。这种测试应当由测试人员进行。但这并不意味着程序员在推出软件之前不进行代码检查。(这一原则适用于所有的测试阶段。) 系统测试 ── 针对全部需求说明进行黑盒测试,包括系统中所有的部件。
回归测试 (regression testing) ── 每当软件经过了整理、修改、或者其环境发生变化,都重复进行测试。很难说需要进行多少次回归测试,特别是是到了开发周期的最后阶段。进行此种测试,特别适于使用自动测试工具。
负荷试验 (load testing) ── 在大负荷条件下对应用软件进行测试。例如测试一个网站在不同负荷情况下的状况,以确定在什么情况下系统响应速度下降或是出现故障。
压力测试 (stress testing) ── 经常可以与“负荷测试”或“性能测试”相互代替。这种测试是用来检查系统在下列条件下的情况:在非正常的巨大负荷下、某些动作和输入大量重复、输入大数、对数据库进行非常复杂的查询,等等。
性能测试 (performance testing) ── 经常可以与“压力测试”或“负荷测试”相互代替。理想的“性能测试”(也包括其他任何类型的测试) 都应在质量保障和测试计划的文档终予以规定。
可用性测试 (usability testing) ── 是专为“对用户友好”的特性进行测试。这是一种主观的感觉,取决于最终用户或顾客。可以进行用户会见、检查、对用户会议录像、或者使用其他技术。程序员和测试人员通常不参加可用性测试。
安装/卸载测试 (install/uninstall testing) ── 对安装/卸载进行测试 (包括全部、部分、升级操作)。
安全测试 (security testing) ── 测试系统在应付非授权的内部/外部访问、故意的损坏时的防护情况。这需要精密复杂的测试技术。
兼容性测试 (compatability testing) ── 测试在特殊的硬件/软件/操作系统/网络环境下的软件表现。
α 测试 (alpha testing) ── 在开发一个应用软件即将完成时所进行的测试。此时还允许有较小的设计修
改。通常由最终用户或其他人进行这种测试,而不是由程序员和测试人员来进行。 β 测试 (beta testing) ── 当开发和测试已基本完成,需要在正式发行之前最后寻找毛病而进行的测试。通常由最终用户或其他人进行这种测试,而不是由程序员和测试人员来进行。
1. 测试人员必须经过测试基础知识和理论的相关培训。
2. 测试人员必须熟悉系统功能和业务。
3. 测试必须事先要有计划,而且测试方案要和整个项目计划协调好
4. 必须事先编写测试用例,测试执行阶段必须根据测试用例进行
5. 易用性,功能,分支,边界,性能等功能性和非功能性需要都要进行测试
6. 对于复杂的流程一定要进行流程分支,组合条件分析,再进行等价类划分准备相关测试数据
7. 测试设计的一个重要内容是要准备好具体的测试数据,清楚这个测试数据是测哪个场景或分支的
8. 个人任务平均每三个测试用例至少应该发现一个 BUG,否则只能说明测试用例质量不好
9. 除了每日构建的冒烟测试可以考虑测试自动化外,其它暂时都不要考虑去自动化。
1.1.2 软件测试的步骤是什么?
1) 测试过程按 4 个步骤进行,即单元测试(Unit Testing)、集成测试(Integrated
Testing)、确认测试(Validation Testing)和系统测试(System Testing)及发版测试。
2) 开始是单元测试,集中对用源代码实现的每一个程序单元进行测试,检查各个程序模块是否正确地实现了规定的功能。
3) 集成测试把已测试过的模块组装起来,主要对与设计相关的软件体系结构的构造进行测试。
4) 确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求,以及软件配置是否完全、正确。
1.1.3 如何录制测试脚本?
1) 新建一个脚本(Web/HTML 协议)
2) 点击录制按钮,在弹出的对话框的 URL 中输入”about:blank”。
3) 在打开的浏览器中进行正常操作流程后,结束录制。
4) 调试脚本并保存。可能要注意到字符集的关联。
5) 设置测试场景
6) 针对性能设置测试场景,主要判断在正常情况下,系统的平均事务响应时间是否达标
7) 针对压力负载设置测试场景,主要判断在长时间处于满负荷或者超出系统承载能力的条件下,系统是否会崩溃
1.1.4 应该考虑进行如何测试的测试方法
黑盒测试 (Black box testing) ── 不考虑内部设计和代码,根据需求和功能进行测试。
白盒测试 (White box testing) ── 根据应用软件的代码的内部逻辑,按照代码的语句、分支、路径和条件进行测试。
功能测试(functional testing)——对一个应用软件的功能模块进行黑盒测试。这种测试应当由测试人员进行。但这并不意味着程序员在推出软件之前不进行代码检查。(这一原则适用于所有的测试阶段。) 系统测试 ── 针对全部需求说明进行黑盒测试,包括系统中所有的部件。
回归测试 (regression testing) ── 每当软件经过了整理、修改、或者其环境发生变化,都重复进行测试。很难说需要进行多少次回归测试,特别是是到了开发周期的最后阶段。进行此种测试,特别适于使用自动测试工具。
负荷试验 (load testing) ── 在大负荷条件下对应用软件进行测试。例如测试一个网站在不同负荷情况下的状况,以确定在什么情况下系统响应速度下降或是出现故障。
压力测试 (stress testing) ── 经常可以与“负荷测试”或“性能测试”相互代替。这种测试是用来检查系统在下列条件下的情况:在非正常的巨大负荷下、某些动作和输入大量重复、输入大数、对数据库进行非常复杂的查询,等等。
性能测试 (performance testing) ── 经常可以与“压力测试”或“负荷测试”相互代替。理想的“性能测试”(也包括其他任何类型的测试) 都应在质量保障和测试计划的文档终予以规定。
可用性测试 (usability testing) ── 是专为“对用户友好”的特性进行测试。这是一种主观的感觉,取决于最终用户或顾客。可以进行用户会见、检查、对用户会议录像、或者使用其他技术。程序员和测试人员通常不参加可用性测试。
安装/卸载测试 (install/uninstall testing) ── 对安装/卸载进行测试 (包括全部、部分、升级操作)。
安全测试 (security testing) ── 测试系统在应付非授权的内部/外部访问、故意的损坏时的防护情况。这需要精密复杂的测试技术。
兼容性测试 (compatability testing) ── 测试在特殊的硬件/软件/操作系统/网络环境下的软件表现。
α 测试 (alpha testing) ── 在开发一个应用软件即将完成时所进行的测试。此时还允许有较小的设计修
改。通常由最终用户或其他人进行这种测试,而不是由程序员和测试人员来进行。 β 测试 (beta testing) ── 当开发和测试已基本完成,需要在正式发行之前最后寻找毛病而进行的测试。通常由最终用户或其他人进行这种测试,而不是由程序员和测试人员来进行。