数据库应用测试框架与关键问题探讨

需积分: 10 174 浏览量更新于2024-09-15 收藏 263KB PDF 举报

"A Framework for Testing Database Applications" 这篇文档是关于数据库应用程序测试的框架研究，由多位来自不同机构的作者共同撰写。该研究强调了数据库系统在现代组织中的重要性，但针对其测试方法的研究相对较少。论文探讨了在测试数据库系统时遇到的问题，并提出了一种数据库应用的测试方法。在测试数据库应用程序时，有以下几个关键知识点： 1. **数据库状态的重要性**：在用户操作前后，数据库的状态变化是测试的重要考量因素。这些状态包括数据的完整性、一致性以及事务处理后的结果。 2. **用户输入与系统输出**：除了数据库状态外，用户的输入（如查询、事务命令等）和系统的响应（如返回结果、系统日志）也是测试关注的重点。这涉及到功能测试和性能测试两个方面。 3. **有意义的数据填充**：为了有效地进行测试，需要创建符合数据库约束条件的有意义的数据集。这通常涉及到数据生成器的使用，它可以自动生成满足特定规则和约束的测试数据，以覆盖各种可能的场景。 4. **工具原型设计**：论文中提到已经开发了一个原型工具，用于填充数据库并确保数据满足预设的约束。这样的工具在测试中可以大大提升效率，减少手动创建测试数据的工作量。 5. **测试策略与方法**：论文中提出的测试方法可能包含白盒测试（基于代码理解）和黑盒测试（基于功能行为），以及可能的灰盒测试（结合两者）。测试策略可能涉及边界值分析、等价类划分、错误猜测和状态转换测试等。 6. **测试自动化**：由于数据库应用的复杂性和规模，测试自动化是必要的，以提高测试覆盖率和效率，减少人为错误。 7. **故障注入**：为了评估系统的健壮性和恢复能力，可能会采用故障注入技术，模拟数据库故障或异常情况，观察系统如何响应。 8. **性能和压力测试**：在高并发或大量数据的情况下，测试数据库应用的性能和稳定性至关重要。这可能包括查询速度、事务处理能力以及资源消耗等方面。 9. **安全性测试**：数据库通常存储敏感信息，因此需要进行安全性测试，确保数据的保密性和完整性，防止未授权访问和攻击。 10. **回归测试**：当数据库应用进行更新或修复后，必须执行回归测试以确认修改没有引入新的错误或影响到其他功能。这篇论文提供了对数据库应用测试的全面视角，涵盖了从数据准备、测试策略到工具实现等多个关键环节，对于数据库系统的质量保证具有重要的指导价值。

create table s (sno char(5), sname char(20), status decimal(3),

city char(15), primary key(sno));

create table p (pno char(6) primary key, pname char(20), color char(6),

weight decimal(3), city char(15));

create table sp (sno char(5), pno char(6), qty decimal(5),

primary key(sno,pno),

foreign key(sno) references s, foreign key(pno) references p);

Figure 1: A database schema denition in SQL

have the same entries in

both

of these columns. Referen-

tial integrity constraints indicate that each supplier number

(

sno

) appearing in table

must appear in table

and that

each part number (

pno

) app earing in table

must appear

in table

Software Testing

Testing is one of the most widely used means of validating

software. When testing a program, one executes the pro-

gram on selected inputs and checks that the resulting out-

puts agree with the specied values. Additional information

may also b e logged to help evaluate how thoroughly the soft-

ware has been tested. While no testing technique short of

exhaustive testing (testing on every p ossible input, whichis

almost always infeasible because of the numb er of possible

alternatives) can guarantee that a program is correct, test-

ing can often b e an eective practical means of discovering

software faults, as well as other system characteristics such

as performance under particular loads. A primary goal of

software testing research is the developmentof systematic

means of selecting test sets that are small enough to b e fea-

sible in practice, yet whichcover a wide variety of situations

the software could p otentially face.

The test generation technique described in this pap er is

loosely based on category-partition testing [16], which for-

malizes and partially automates a widely-used informal

specication-based testing technique. The tester identies

important categories of data (e.g. input parameters, envi-

ronment factors), provides sample values for each category,

and partitions each category into groups (called

choices

)

which might b e handled dierently by the application. A

tool then constructs test cases by combining elements of

dierent choices from the various categories. To keep the

numb er of test cases reasonable and to avoid generation of

impossible combinations (such as an unsorted arraywith0

elements), the tester can provide various constraints.

3. ISSUES IN TESTING DB APPLICA-

TIONS

In this section, we discuss several issues that arise in

testing database applications. We illustrate these issues

with the following simple hypothetical example, an appli-

cation program that a telephone company might use to pro-

cess customers' orders for new features (call-waiting, call-

forwarding, etc.).

Assume the database includes a customer-feature table, with

information ab out customers, including customer ID num-

ber, customer address, and features to which the customer

subscribes, and a billing table, with customer ID numbers

and information pertinent to issuing monthly bills, as well

as other tables. The application program's sp ecication is

as follows:

Input a customer's ID number and the name

of the telephone feature to which the customer

wishes to subscribe. If the ID number or the fea-

ture name is invalid, return code 0; otherwise, if

the customer lives in an area in which that fea-

ture is available, and that feature is not incom-

patible with any other feature to whichthecus-

tomer already subscribes, add the selected fea-

ture to the customer's customer-feature record,

update the billing table appropriately, and send

a notice to the provisioning department (which

will initiate the feature); return co de 1. If the

customer does not live in an area in whichthis

feature is available, return code 2; If the feature is

available in the customer's area, but it is incom-

patible with other features to which the customer

subscribes, return co de 3.

The role of the database state

A database application, like any other program, can be

viewed as computing a (partial) function from an input

space

to an output space

. Its sp ecication can be ex-

pressed as a function (or, more generally, a relation) from

. Thus, we can test a database application by select-

ing values from

, executing the application on them, and

checking whether the resulting values from

agree with

the sp ecication. However, unlike \traditional" programs

considered in most of the testing literature and by most

existing testing to ols, the input and output spaces havea

complicated structure, which makes selecting test cases and

checking results more diÆcult.

On the surface, it appears that the inputs to the program

are the customer ID and the feature name, while the output

is a numeric co de b etween 0 and 3. This suggests that gener-

ating test cases is a matter of nding various \interesting"

customer IDs and features, and that checking each result

involves examining a single integer. However, a moment's

reection reveals that the expected and actual results of exe-

cuting the application on a given (customer-ID, feature) pair

also depend on the state of the database before executing

the application. Similarly,knowledge of expected and actual

values of the database state after executing the application

are needed in order to determine whether the application

behaved correctly. For example, the intended b ehavior of

the program on a given (customer-ID, feature) pair dep ends

on whether the customer ID is valid, what features the cus-

148149

剩余10页未读，继续阅读

tlt19850902

粉丝: 0
资源: 1

数据库应用测试框架与关键问题探讨

Express in Action: Writing, building, and testing Node.js applications

Building.applications.with.Scala.epub

Spring.Boot.in.Action.2015.12.pdf

hibernate_reference.pdf

spring-boot-reference.pdf

Flask By Example.pdf 最新 原版

Professional_Linux_Programming.pdf

Flask Web Development.pdf 最新 原版

Apache Geronimo 2.1_ Quick Reference.pdf

Spring和Mybatis整合英文文档翻译.pdf

最新资源

Flask By Example.pdf 最新原版

Flask Web Development.pdf 最新原版