我想了解一些软件测试的内容(150分)

  • 主题发起人 主题发起人 yzc2000
  • 开始时间 开始时间
Y

yzc2000

Unregistered / Unconfirmed
GUEST, unregistred user!
如何得到这方面的资料?
能否介绍一些关于测试方面好的网站?
 
全国计算机等级考试(四级)考试大纲
软件测试:
⑴软件测试基本概念。
⑵软件测试方法。
⑶软件测试计划。
⑷单元测试、集成测试与系统测试。
⑸测试用例设计。
⑹测试分析报告。
 
软件工程里面有!
 
chinauml.com
playcase.com里的很多站点连接
。。。
 
你还是看一下清华大学出的《软件工程导论》
 
模板一份
软 件 测 试 报 告
项目编号: 项目名称:
任务编号/序号: 工作名称:
程序(ID): 程序名称:
编程员: 测试完成日期: 年 月 日
测试工程师: 测试完成日期: 年 月 日
1、 安装:
(1)程序运行环境已经正确设定 □ □
2、 程序代码检查:
(1)程序单位首部有程序说明和修改备注 □ □
(2)变量、过程、函数命令符合规则 □ □
(3)程序中有足够的说明信息 □ □
(4)修改注释符合要求 □ □
(5)类库的使用符合要求 □ □
3、 画面及报表格式检查:
(1)画面和报表格式符合规定需求 □ □
(2)程序命名符合格式需求 □ □
(3)画面和报表的字段位置和宽度与设计文档一致 □ □
4、 功能测试:
(1)多画面之间切换正确 □ □
(2)功能键、触发键、按钮、菜单、选择项功能正确 □ □
(3)数据项关联及限制功能正确 □ □
(4)设计文档规定的其它功能
测试内容:
5、 正确性测试:
(1)读/写/删除操作结果正确
(2)各种组合条件之查询或报表正确
(3)设计文档规定的其它操作
测试内容: □ □
6、 可靠性测试:
(1)非法键容错测试
(2)异常字符容错测试
(3)程序负作用检查
(4)残留文件检查
7、 效率测试:
单用户(机型) □ □ 多用户(终端数)□ □
(1) 输入画面效率测试:
延迟时间: □ □ □ □
(2) 报表及查询效率测试:
最小报表时间:□ □ □ □
最大报表时间:□ □ □ □
8、 多用户测试:
终端数: □ □
(1) 随机测试:
测试次数:□ □
(2) 共享测试:□ □
(3) 同步测试:□ □
9、 其它测试:
测试内容: □ □
测试备忘:

 
DUunit
http://dunit.sourceforge.net/
DUnit automates unit testing of Delphi code. The target audience for DUnit is developers
who are both writing the code to be tested and the unit tests for that code, an approach
advocated by Extreme Programming. Dunit is based on the product JUnit.
 
比较好的软件工程书中都讲的可以。
如果需要标准文档,我发一些我用的给你
 
jasper,可否发一份给我?
shkk@163.net
 
jasper,可否发一份给我?
w_w_f@sina.com
 
Give it to me, 3x!
mailto: g00d@263.net
 
silly讲的是XP development,我在用jUnit呢。 :)
 
http://python.home.sohu.com
 
jasper那份软件测试的标准文档可以给我一份吗?感谢!!
zxl9000@21cn.com
 
IEEE 测试计划纲要
IEEE 测试计划纲要
  以下是一个 IEEE 829 测试文档标准的中文纲要。其中,不是所有的项目需要写出两遍,如果以下所列的某些文档已经存在,那么测试计划就可以变成一个连接到那些文档的超文本文档。

测试计划标识。说明赋予该测试文档的唯一编号。
背景介绍。概述软件背景资料,及要测试的该软件的事项及性能。可以包括必要的各项目及其历史,以及与之相关的其它计划的参考材料。
测试项目。如果有以下材料的话,请提供参考资料:
需求说明书、设计说明书、用户指南、操作指南、安装指南、问题登记指南、测试外的其它各项。
要测试的特性。确定要测试的所有方面的特点。例如性能、移置性、或功能性。确定与各项性能关联的测试设计规格。
不测试的特性。在某些情况下,你知道某些需要测试的特性现在还不能测试,在此一一列出。
方法与步骤。说明整体的方法或步骤,指出用于测试每个特性组的主要活动、技术和工具。这里要作到足够详尽,以能够确定主要的测试任务,并能估计出每项照此作法所需的时间。说明想要的可理解度的最低要求。确定衡量测试工作的可理解度的技术。确定测试的重要约束条件,如测试条目的有效性、测试资源可用性、最后时限。
各项“通过/失败”的准则。说明用于确定每个条目测试是否通过或失败的准则。
测试中止的标准和恢复的条件。说明全部或计划中所列各部分测试活动中止及重启的条件,指出那些必须重复的测试活动。
测试的交付。确定下要提交的文档,可能包括:
测试计划、测试设计说明书、测试用例说明书、测试流程说明书、测试项目传输报告、测试记录、测试事件报告、测试汇总报告、测试输入数据和测试输出数据、测试工具。
测试任务。确定出需准备并执行的测试一系列任务,标识出所有任务间的依赖性和所需的特殊技能。
需要的环境。说明测试环境的必需资源、及必要的道具。这些应包括:硬件、通讯、系统软件、独立平台或局域网,及任何其他需要的专用软件,如用于侵蚀控制软件的do
S 下的 KERMIT 工具。
责任和角色。确定各个不同测试活动小组的责任,如管理、设计、开发、建造、执行、验证、问题登记以及问题解决。这些小组将包括系统管理员、开发者、质量保证员、测试分析人员、实际系统用户、帮助文书员、项目经理人员以及小组长。
人员配备和必要的培训。确定根据技能水平所需的测试人员配备,以及执行测试任务所需的培训。
时间计划安排。应包括项目计划里确定的各个转折点(Fixpoint/Milestone)。
风险和意外处理。确定测试计划中的可能的高风险,并说明各种意外事故的应对计划。
审批。标识出所有必须同意这个计划的人员的姓名和职务。

 
时间过长,斑竹强行结束!
 

Similar threads

后退
顶部