Software Testing Overview

软件测试是软件对需求的评估来自用户和系统规范。测试是在软件开发生命周期的阶段水平或在程序代码模块级。软件测试包括确认和验证。

Software Vapdation

验证是检查过程是否满足用户需求的软件。它是在SDLC的结束。如果软件匹配要求它,这是验证。

Vapdation ensures the product under development is as per the user requirements.

Vapdation answers the question – "Are we developing the product which attempts all that user needs from this software ?".

Vapdation emphasizes on user requirements.

Software Verification

验证是一个过程,确认软件是否满足业务需求,开发和坚持正确的规范和方法。

Verification ensures the product being developed is according to design specifications.

Verification answers the question– "Are we developing this product by firmly following all design specifications ?"

Verifications concentrates on the design and system specifications.

测试的目标是- - -

错误——这些都是由开发人员实际编码错误。此外,还有不同软件的输出和期望输出值,被认为是一个错误。

错误——错误存在故障发生时。错,也称为一个错误,是一个错误的结果可以导致系统失败。

失败——据说是系统的能力来执行所需的任务。故障发生在系统中存在故障。

Manual Vs Automated Testing

测试可以是手工完成的,或者使用一个自动化测试工具:

手动执行这个测试没有利用自动化测试工具的帮助。软件测试人员编写测试用例的不同部分和级别的代码,执行测试和结果报告给经理。

手动测试时间和资源消耗。测试人员需要确认是否使用正确的测试用例。测试包括手动测试的主要部分。

这个测试是一种测试过程自动完成自动化测试工具的援助。手工测试的限制使用自动化测试工具是可以克服的。

一个测试需要检查是否一个网页可以打开在Internet Explorer。这可以很容易地完成了手动测试。但检查服务器是否可以装载100万用户,是相当不可能的手动测试。

有软件和硬件工具帮助测试人员进行负载测试、压力测试、回归测试。

Testing Approaches

测试可以基于两种方法进行

Functionapty testing

Implementation testing

功能测试时没有采取实际实现的关注被称为黑盒测试。另一边被称为白盒测试,测试,但它不仅功能实现也进行了分析。

详尽的测试best-desired方法为一个完美的测试。每一个可能值的范围内测试的输入和输出值。不可能测试每一个值在真实世界场景中如果值的范围很大。

Black-box testing

进行测试程序的功能。它也被称为“行为”测试。测试人员在这种情况下,有一组输入值和各自想要的结果。提供输入,如果输出匹配与期望的结果,程序测试“ok”,否则有问题。

在这种测试方法中,代码的设计和结构是测试人员不知道,和测试工程师和最终用户进行这个测试软件。

黑盒测试技术:

等价类,输入分为相似的类。如果一个元素类的通过了测试,假设所有的类都是过去了。

边界值,输入分为高和低端值。如果这些值通过测试,它假定所有值之间也可能通过。

因果绘图——在之前的方法,只有一个输入值测试。原因(输入)——结果(输出)是一个测试技术,输入值的组合是一种系统化的方式测试的。

双向测试——软件的行为取决于多个参数。在成对测试中,多个参数进行测试的成对的不同的值。

基于状态的测试——对提供输入系统变化的状态。这些系统都是基于它们的状态和输入测试。

White-box testing

进行测试程序及其实现,为了提高代码效率或结构。它也被称为“结构”测试。

在这种测试方法中,代码的设计和结构测试人员。程序员的代码进行这个测试代码。

以下是一些白盒测试技术:

控制流测试——控制流测试的目的建立测试用例涵盖所有的语句和分支条件。分支条件测试的真与假,这所有的语句都可以覆盖。

数据流测试,这种测试技术重点覆盖所有数据变量包含在程序。它测试变量被声明和定义,在那里,他们使用或改变。

Testing Levels

测试本身可以定义各级SDLC。测试过程并行软件开发。跳到下一个阶段,前一个阶段是测试,验证和验证。

分别测试是为了确保没有隐藏的缺陷或问题的软件。软件测试在不同的水平

Unit Testing

编码时,程序员对单位执行一些测试项目,知道这是没有误差的。测试在执行白盒测试方法。单元测试能够帮助开发人员决定个体单位的项目正在按照要求,无错。

Integration Testing

即使软件的单位是单独工作正常,需要找出如果单位综合在一起也没有错误。例如,参数传递和数据升级等。

System Testing

编译的软件产品,然后是作为一个整体进行测试。这可以通过使用一个或多个下列测试:

功能测试——测试软件的所有功能需求。

性能测试,这个测试证明了软件的效率。它测试的有效性和平均时间软件完成所需的任务。性能测试是通过负载测试和压力测试的软件是把高用户和数据加载在不同环境条件下。

安全与可移植性——这些测试完成时,软件是为了在各种工作平台和访问人员的数量。

Acceptance Testing

当软件准备移交给客户,必须经历最后阶段的测试,测试用户交互和响应。这是很重要的,因为即使软件匹配所有用户需求,如果用户不喜欢看起来或的工作方式,它可能被拒绝。

α测试——开发人员自己的团队执行α测试通过使用系统如果是用于工作环境。他们试图找出用户对一些行动在软件和系统应该如何应对输入。

内部测试,软件测试后,交给用户使用它只在生产环境中进行测试的目的。这不是尚未交付的产品。开发人员希望用户在此阶段将分钟问题,跳过参加。

Regression Testing

无论何时更新为新的代码,软件产品特性或功能,它是彻底地进行了测试来检测是否有添加代码的任何负面影响。这就是所谓的回归测试。

Testing Documentation

在不同阶段,测试文档准备

Before Testing

测试从测试用例开始。还需要以下文件,供参考

SRS文档,功能需求文档

测试策略文档——这描述如何测试应该发生在发布产品之前。

测试策略测试团队的文档——这提到的细节方面,职责矩阵和权利/测试经理和测试工程师的责任。

跟踪矩阵文档——这是SDLC文档,这是相关的需求收集过程。随着新的要求,他们被添加到这个矩阵。这些矩阵可以帮助测试人员知道需求的来源。它们可以追踪向前和向后。

While Being Tested

下列文件可能需要测试时启动和完成:

测试用例文档,该文档包含列表的测试要求进行。它包括单元测试计划,集成测试计划、系统测试计划和验收测试计划。

测试描述文档——这是所有测试用例的详细描述和程序来执行它们。

测试用例报告——这文档包含测试用例的测试报告。

测试日志,这个文件包含了每个测试用例测试日志报告。

After Testing

下列文件后可以生成测试:

测试总结——这个测试总结是集体所有测试报告和日志分析。总结,得出的结论是如果软件准备发射。下发布的软件版本控制系统如果是准备发射。

Testing vs. Quapty Control, Quapty Assurance and Audit

我们需要理解软件测试与软件质量保证不同,软件质量控制和审计。

软件质量保证——这些都是软件开发过程的监控手段,保证所有的措施按照的标准组织。这种监控是为了确保适当的软件开发方法。

软件质量控制——这是一个系统维护软件产品的质量。它可能包括软件产品的功能性和非功能性方面,加强组织的亲善。这个系统确保客户收到产品需求和产品质量认证为“适合使用”。

软件审计——这是一个复习的过程所使用的组织开发软件。审计,独立于开发团队检查软件过程,过程中,需求和SDLC的其他方面。软件审计的目的是检查软件及其开发过程,符合标准,规则和条例。