重现环境：描述缺陷如何重现？或者说是重现该缺陷的具体操作步骤。　

　浏览器：针对B/S架构的系统要描述浏览器的版本。　　

操作系统：bug出现的操作系统。　

　bug类型　　1.可以按照代码出现的原因划分（代码错误，设计缺陷，界面缺陷，安装部署原因）　　2.可以按照缺陷的类型划分（功能，易用性）　　

缺陷等级　　根据需要划分：一般5级已经很完整　　建议：增加用户的体验以及使用起来更方便的建议类型的缺陷。　　轻微：一些不影响系统正常使用的缺陷，如错别字等。　　一般：输入输出，不规范，辅助说明或者描述不够准确的。　　严重：功能未正确实现的，输入输出错位的。　　致命：导致系统崩溃，内存泄露等。　　

严重度：（处理的优先级）　　分为低，中，高，紧急　

　缺陷状态：　　new：新发现一个缺陷。　　open：确认后打开。　　reopen：修改后经验证尚未改正的。　　rejected：开发人员认为不是缺陷，或者描述不清楚的，此时需要对缺陷回执的原因进行说明。　　fixed:bug修改后尚未被测试的。　　closed:缺陷被修改并被验证后的。

2. B/S和C/S的区别是什么？

1、简单解释：

B/S最大优势为客户端免维护，适用于用户群庞大，或客户需求经长发生变化的情况。

C/S功能强大，可以减轻服务器端压力，如果用户的需求特别复杂，用C/S。

全面：

Client/Server是建立在局域网的基础上的.Browser/Server是建立在广域网的基础上的. 

硬件环境不同: 

C/S 一般建立在专用的网络上, 小范围里的网络环境, 局域网之间再通过专门服务器提供连接和数据交换服务.

B/S 建立在广域网之上的, 不必是专门的网络硬件环境,例与电话上网, 租用设备. 信息自己管理. 有比C/S更强的适应范围, 一般只要有操作系统和浏览器就行 

对安全要求不同 

C/S 一般面向相对固定的用户群, 对信息安全的控制能力很强. 一般高度机密的信息系统采用C/S 结构适宜. 可以通过B/S发布部分可公开信息.

B/S 建立在广域网之上, 对安全的控制能力相对弱, 面向是不可知的用户群. 

对程序架构不同 

C/S 程序可以更加注重流程, 可以对权限多层次校验, 对系统运行速度可以较少考虑.

B/S 对安全以及访问速度的多重的考虑, 建立在需要更加优化的基础之上. 比C/S有更高的要求 B/S结构的程序架构是发展的趋势, 从MS的.Net系列的BizTalk 2000 Exchange 2000等, 全面支持网络的构件搭建的系统. SUN 和IBM推的JavaBean 构件技术等,使 B/S更加成熟. 

软件重用不同 

C/S 程序可以不可避免的整体性考虑, 构件的重用性不如在B/S要求下的构件的重用性好.

B/S 对的多重结构,要求构件相对的功能. 能够相对较好的重用.就入买来的餐桌可以再利用,而不是做在墙上的石头桌子 

系统维护不同 

系统维护是软件生存周期中,开销大, -------重要

C/S 程序由于整体性, 必须整体考察, 处理出现的问题以及系统升级. 升级难. 可能是再做一个全新的系统

B/S 构件组成,方面构件个别的更换,实现系统的无缝升级. 系统维护开销减到最小.用户从网上自己下载安装就可以实现升级. 

处理问题不同 

C/S 程序可以处理用户面固定, 并且在相同区域, 安全要求高需求, 与操作系统相关. 应该都是相同的系统

B/S 建立在广域网上, 面向不同的用户群, 分散地域, 这是C/S无法作到的. 与操作系统平台关系最小. 

用户接口不同 

C/S 多是建立的Window平台上,表现方法有限,对程序员普遍要求较高

B/S 建立在浏览器上, 有更加丰富和生动的表现方式与用户交流. 并且大部分难度减低,减低开发成本. 

信息流不同 

C/S 程序一般是典型的集权的机械式处理, 交互性相对低

B/S 信息流向可变化, B-B B-C B-G等信息、流向的变化, 更象交易中心

3.软件测试流程图

各个测试阶段测试流程图

1-1测试工作总体流程图

说明：集成测试和系统测试的反馈意见可能导致设计文档（需求或数据库）的修改。

1-2：需求阶段流程图

1-3：单元和集成测试流程图

1-4：系统测试流程图

1-5：压力测试流程图

说明：压力测试为模拟用户正常使用时，系统正常工作的最小时间。

1-6：性能测试流程图

说明：测试系统的崩溃极限（最多使用人数和数据库的极限容量）。

1-7 软件测试流程关系图

1-8：研发、测试、配置协作关系

4.  什么是软件缺陷 

简单的说，缺陷就是 ：

1，不满足用户确定的需求

2，软件使用当中出现的问题

3，不符合设计要求。

而BUG是程序代码当中的错误。

常常又被叫做Bug。所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983对缺陷有一个标准的定义：

从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；

从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。在软件开发生命周期的后期，修复检测到的软件错误的成本较高。

那我们如何判断发现的问题是否是缺陷呢？通过下面几点我们可以确定。

1，通过参考文档。

2，了解软件行业背景。

3，通过沟通。

5.根据水杯来写测试用例：

先从一个模块开始写，功能 ，性能，还有材质，界面

6.写出一下问题的至少2个测试用例（以下只是写思路，没有确定答案）

三个控键（文本编辑框，确认，取消）请问这三个控键，最危险的是哪个，请写出至少两个测试用例。

【

最危险的肯定是确定〜其次是文本编辑吧，最后才是取消吧，我猜的。因为文本编辑的输入还在浏览器这层，取消也是，确定很可能会涉及到action曾，服务层，数据访问层和数据库，涉及到数据的存取

至于文本编辑，有大小写，特殊字符，超常，为空，这些和确定之后存取的东西有关系，所以也算危险

文本框先考虑边界值等价类，组合一起可以考虑正交排列

错误猜测法这貌似用不上

】下载本文