软件测试基础：外文翻译版

3星 · 超过75%的资源需积分: 10 187 浏览量更新于2024-07-26 收藏 379KB PDF 举报

"这篇资源是一篇关于软件测试的外文文章的中文翻译，适合作为测试领域的外文翻译参考。作者是Nick Jenkins，发布于2008年，并遵循Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License协议。文章主要介绍了软件测试的基础知识，包括测试的必要性、不同类型的测试方法等内容。" 本文是Nick Jenkins编写的《软件测试基础》的简介，旨在向读者提供软件测试的基本概念。测试在软件开发过程中至关重要，因为它能确保产品质量，降低潜在的错误和缺陷，提高用户满意度。作者首先强调了测试的必要性，指出在软件开发的各个阶段，无论是需求分析、设计、编码还是维护，都应进行相应的测试。文章可能涵盖了以下测试相关知识点： 1. **测试的重要性**：测试不仅发现错误，还能验证软件是否符合预期的功能和性能要求，同时有助于识别潜在的系统风险。 2. **测试类型**：包括单元测试（针对代码模块进行的测试）、集成测试（多个模块组合后的测试）、系统测试（整个系统作为一个整体进行的测试）和验收测试（用户或客户参与的最终测试）。 3. **测试方法论**：可能涉及传统的黑盒测试（仅关注输入和输出，不考虑内部结构）和白盒测试（了解代码结构，检查内部逻辑），以及灰盒测试（结合两者特点）。 4. **测试策略**：如冒烟测试（初步验证软件核心功能是否正常）、回归测试（修改代码后确保未破坏原有功能）和压力测试（评估软件在极端条件下的表现）。 5. **自动化测试**：如何利用工具自动化执行重复性测试任务，提高效率，减少人为错误。 6. **持续集成与持续测试**：在敏捷开发环境中，如何集成测试到持续集成流程中，确保每次代码变更后都能快速得到反馈。 7. **测试文档**：包括测试计划、测试用例、测试报告等，它们在测试过程中的作用和创建标准。 8. **缺陷管理**：如何记录、追踪和优先级排序发现的缺陷，以及与开发团队的沟通协作。 9. **质量保证与质量控制**：测试在质量保证体系中的角色，以及如何通过质量控制确保软件达到预定的质量标准。 10. **测试道德和许可**：文章遵循的Creative Commons许可协议意味着可以自由复制、分发和创作衍生作品，但需保留作者署名，且不能用于商业目的。由于只给出了文章的目录，具体的细节内容未能提供。完整文章将深入探讨这些话题，并可能包含实践案例、最佳实践和指导原则，帮助读者理解和应用软件测试的知识。

C o n c e p t s o f T e s t i n g

The Testing Mindset

There is particular philosophy that accompanies “good testing”.

A professional tester approaches a product with the attitude that the product is already broken - it

has defects and it is their job to discover them. They assume the product or system is inherently

ﬂawed and it is their job to ‘illuminate’ the ﬂaws.

This approach is necessary in testing.

Designers and developers approach software with an optimism based on the assumption that the

changes they make are the correct solution to a particular problem. But they are just that –

assumptions.

Without being proved they are no more correct than guesses. Developers often overlook

fundamental ambiguities in requirements in order to complete the project; or they fail to recognise

them when they see them. Those ambiguities are then built into the code and represent a defect

when compared to the end-user's needs.

By taking a sceptical approach, the tester offers a balance.

The tester takes nothing at face value. The tester always asks the question “why?” They seek to

drive out certainty where there is none. They seek to illuminate the darker part of the projects

with the light of inquiry.

Sometimes this attitude can bring conﬂict with developers and designers. But developers and

designers can be testers too! If they can adopt this mindset for a certain portion of the project,

they can offer that critical appraisal that is so vital to a balanced project. Recognising the need for

this mindset is the ﬁrst step towards a successful test approach.

Test Early, Test Often

There is an oft-quoted truism of software engineering that states - “a bug found at design time

costs ten times less to ﬁx than one in coding and a hundred times less than one found after

launch”. Barry Boehm, the originator of this idea, actually quotes ratios of 1:6:10:1000 for the costs

of ﬁxing bugs in requirements,design, coding and implementation phases.

If you want to ﬁnd bugs, start as early as is possible.

That means unit testing (qqv) for developers, integration testing during assembly and system

testing - in that order of priority! This is a well understood tenant of software development that is

simply ignored by the majority of software development efforts.

Nor is a single pass of testing enough.

Your ﬁrst past at testing simply identiﬁes where the defects are. At the very least, a second pass of

(post-ﬁx) testing is required to verify that defects have been resolved. The more passes of testing

you conduct the more conﬁdent you become and the more you should see your project converge

on its delivery date. As a rule of thumb, anything less than three passes of testing in any phase is

inadequate.

Regression vs. Retesting

You must retest ﬁxes to ensure that issues have been resolved before development can progress.

So, retesting is the act of repeating a test to verify that a found defect has been correctly ﬁxed.

Regression testing on the other hand is the act of repeating other tests in 'parallel' areas to ensure

that the applied ﬁx or a change of code has not introduced other errors or unexpected behaviour.

For example, if an error is detected in a particular ﬁle handling routine then it might be corrected

by a simple change of code. If that code, however, is utilised in a number of different places

throughout the software, the effects of such a change could be difﬁcult to anticipate. What appears

to be a minor detail could affect a separate module of code elsewhere in the program. A bug ﬁx

could in fact be introducing bugs elsewhere.

You would be surprised to learn how common this actually is. In empirical studies it has been

estimated that up to 50% of bug ﬁxes actually introduce additional errors in the code. Given this,

it's a wonder that any software project makes its delivery on time.

Better QA processes will reduce this ratio but will never eliminate it. Programmers risk

introducing casual errors every time they place their hands on the keyboard. An inadvertent slip of

a key that replaces a full stop with a comma might not be detected for weeks but could have

serious repercussions.

Regression testing attempts to mitigate this problem by assessing the ‘area of impact’ affected by a

change or a bug ﬁx to see if it has unintended consequences. It veriﬁes known good behaviour

after a change.

It is quite common for regression testing to cover ALL of the product or software under test.

Why? Because programmers are notoriously bad at being able to track and control change in their

software. When they ﬁx a problem they will cause other problems. They generally have no idea of

the impact a change will make, nor can they reliably back-out those changes.

If developers could, with any certainty, specify the exact scope and effects of a change they made then

testing could be conﬁned to the area affected. Woe betide the tester that makes such an assumption

however!

White-Box vs Black-Box testing

Testing of completed units of functional code is known as black-box testing because testers treat the

object as a black-box. They concern themselves with verifying speciﬁed input against expected

output and not worrying about the logic of what goes on in between.

User Acceptance Testing (UAT) and Systems Testing are classic example of black-box testing.

White-box or glass-box testing relies on analysing the code itself and the internal logic of the

software. White-box testing is often, but not always, the purview of programmers. It uses

techniques which range from highly technical or technology speciﬁc testing through to things like

code inspections.

Although white-box techniques can be used at any stage in a software product's life cycle they

tend to be found in Unit testing activities.

剩余42页未读，继续阅读

lvyangwei123

粉丝: 0
资源: 1

软件测试基础：外文翻译版

Spring框架入门：外文文献翻译

SSM框架必备：Spring外文文献及翻译整理

Java技术及SSH框架毕业论文外文翻译文献

Java Spring 的框架简介外文文献加翻译

Python-掘金翻译计划翻译掘金上优质的英文文章

门户网站构建CSS框架的几种规则

基于J2EE框架的个人博客系统项目毕业设计论文(源码和论文）

Visual_Studio.NET相关词汇中英翻译

周炜(翻译)的NeHe中文教程-OpenGL

.NET 中常用英文解释

最新资源