团队作业—第二周—软件测试计划

1.1目的

本计划将要对软件系统进行一系列的测试,黑盒、白盒、内测、试运营、公测、运营等阶段。


工作内容


人数(人)


工作时间(日)


产品策划、功能设计


1


3


交互设计


1


10


布局设计


2


10


界面设计


1


5


程序开发

Android客户端、server工程师)


4


15


产品测试


5


5


共计


*


48

产品测试一共5天,黑盒1一天,白盒2天,其余一共3天。

1.2名词解释


缩写词或术语


英文解释


中文解释


Debug

 
进行debug调试

1.3参考资料

《构建之法》、《软件工程导论》

1.4测试摘要

本次针对“医天下”系统进行各方面的测试,包括软件系统的性能,bug的修复程度,是否有卡顿,以及一些更强烈的用户体感。

1.4.1 重点事项

1、购物车支付过程中的安全事务。

2、路线规划的准确度。

3、是否有延迟问题。

1.4.2 争议事项

布局方面存在着较大争议。

1.4.3 风险评估

预计在系统的开发过程中,布局问题是用户体感觉得不好的地方,应该增强一下用户的体感,还有就是功能远远不能满足用户(功能量少)。

1.4.4 测试目标

 

首先,可以保证系统的运行情况;

其次,系统漏洞bug需要不断的修复;

再次,用户体感不断的增加;

最后,达到运营阶段。

2项目背景

2.1测试范围

说明本计划涵盖的测试范围,比如功能测试、集成测试、系统测试、验收测试等。通常说明什么是要测试的,什么是不要测试的是非常重要的。明确规定这些问题后,测试人员对该做什么有一个清晰的认识。

功能测试:

<1>测试路线规划功能是否准确

<2>测试在线挂号功能是否可行

<3>测试在线寻求专家是否卡顿

<4>测试在线购药系统是否出现一些致命性的漏洞

系统测试:

<1>测试系统是否能够正常运行

<2>测试系统运行是否卡顿

2.2联系方式

列出项目参与人员的职务、姓名、E-mail 和电话。


职务


姓名


E-Mail


电话


开发工程师


朱云铖


[email protected]


136****6326


CVS Builder


李伟


[email protected]


136****2372


开发经理


朱云铖


[email protected]


136****6326


测试负责人


刘世贤


[email protected]


136****9021


测试人员


黄彦潇


[email protected]


136****0071

2.3测试文档

列出测试过程中可能用到的参考文档、相关的设计文档以及保存位置,测试完成后应产生的文档。

2.5.1测试参考文档


文档说明


作者


文档位置(CVS


需求文档


朱云铖


https://github.com/zyc8023/Ivan/blob/master/


总体设计


朱云铖


https://github.com/zyc8023/Ivan/blob/master/


白皮书


刘世贤


https://github.com/zyc8023/Ivan/blob/master/


使用手册


李伟


https://github.com/zyc8023/Ivan/blob/master/


管理手册


李伟


https://github.com/zyc8023/Ivan/blob/master/


测试文档


黄彦潇


https://github.com/zyc8023/Ivan/blob/master/


API文档


朱云铖


https://github.com/zyc8023/Ivan/blob/master/

2.5.2测试提交文档


文档说明


作者


文档位置(CVS


《总体测试计划》


朱云铖


https://github.com/zyc8023/Ivan/blob/master/


《总体测试方案》(可根据项目情况进行裁剪)


刘世贤


https://github.com/zyc8023/Ivan/blob/master/


测试用例


刘世贤


https://github.com/zyc8023/Ivan/blob/master/


《性能测试方案(报告)》


李伟


https://github.com/zyc8023/Ivan/blob/master/


《测试报告》


黄彦潇


https://github.com/zyc8023/Ivan/blob/master/


《Readme》


朱云铖


https://github.com/zyc8023/Ivan/blob/master/


《产品操作手册(后台)》


刘世贤


https://github.com/zyc8023/Ivan/blob/master/


《产品操作手册(前台)》


朱云铖


https://github.com/zyc8023/Ivan/blob/master/


《产品安装维护手册》


李伟


https://github.com/zyc8023/Ivan/blob/master/


《产品错误代码说明文档》


李伟


https://github.com/zyc8023/Ivan/blob/master/

3章质量目标

3.1产品质量目标

可以是产品的质量达到什么样的目标,产品的流程联通性达到什么样的要求。


测试质量目标


确认者(如需说明)


测试已实现的产品是否达到设计的要求,包括:各个功能点是否以实现,业务流程是否正确


朱云铖


产品规定的操作和运行稳定


朱云铖

3.2测试质量目标

评价测试质量的目标可以有:


测试质量目标


确认者(如需说明)


所有的测试案例已经执行过


朱云铖


所有的自动测试脚本已经执行通过


李伟


所有的重要等级为1/2的Bug已经解决并由测试验证


刘世贤


每一部分的测试已经被Test Lead确认完成


朱云铖


重要的功能不允许有等级为1/2/3的Bug


刘世贤


一般的功能或与最终使用者不直接联系的功能不允许有等级为1/2的bug,且bug等级为3的问题不得超过1/功能


黄彦潇


轻量的功能允许有少量2/3等级的错误


刘世贤


发现错误等级为1/2/3的Bug的速率正在下降并接近0


李伟


在最后的三天内没有发现错误等级为1/2/3类的Bug


朱云铖

4资源需求

4.1培训资料


培训需求


培训内容


培训人员


开始时间


完成时间


业务流程


Andriod


Yul老师


6.15


6.20


安装配置


布局


Ivan老师


6.15


6.25


工具使用


Junit


---


6.15


6.20

4.2测试环境

4.2.1硬件测试环境

机型(配置)”:Android 2.2

软件及版本”:1.0

4.3测试工具


测试工具


用途


自动测试工具


用于测试软件系统的整体性能

5测试策略

5.1    整体测试策略

使用各方面性能测试的工具,对本系统整体的性能进行一系列的测试。

5.2开始/中断/完成标准

说明中断/开始/完成测试的标准。


开始/中断/完成测试


标准说明


开始测试标准


硬件环境可用且软件正确安装完成


中断测试标准


安装无法正确完成或程序的文档有相当多的失误或系统服务异常或发现Block Bug


完成测试标准


完成测试计划中的测试规划并达到程序和测试质量目标,并由Test Lead/R&D Manager确认

5.3测试类型


测试类型


是否采用


说明


功能测试


采用


根据系统需求文档和设计文档,检查产品是否正确实现了功能。


流程测试


采用


按操作流程进行的测试,主要有业务流程、数据流程、逻辑流程、正反流程,检查软件在按流程操作时是否能够正确处理


边界值测试


采用


选择边界数据进行测试,确保系统功能正常,程序无异常。


容错性测试


采用


检查系统的容错能力,错误的数据输入不会对功能和系统产生非正常的影响,且程序对错误的输入有正确的提示信息


异常测试


采用


检查系统能否处理异常


启动停止测试


采用


检查每个模块能否正常启动停止、异常停止后能否正常启动


安装测试


采用


检查系统能否正确安装、配置


易用性测试


采用


检查系统是否易用友好


界面测试


采用


检查界面是否美观合理


接口测试


采用


检查系统能否与外部接口正常工作


配置测试


采用


检查配置是否合理、配置是否正常


安全性和访问控制测试


采用


应用程序级别的安全性:检查Actor只能访问其所属用户类型已被授权访问的那些功能或数据。

系统级别的安全性:检查只有具备系统和应用程序访问权限的Actor才能访问系统和应用程序。


性能测试


采用


提取系统性能数据,检查系统是否满足在需求中所规定达到的性能。


压力测试


采用


检查系统能否承受大压力,测试产品应该能够在高强度条件下正常运行,不会出现任何错误。


兼容性测试


采用


对于 C/S 架构的系统来说,需要考虑客户端支持的系统平台。

对于 B/S 架构的系统来说需要考虑用户端浏览器的版本。


割接/升级测试


采用


进行专门的割接测试或升级测试,提供工程升级割接方案


文挡测试


采用


检查文档是否足够、描述是否合理


回归测试


采用


检查程序修改后有没有引起新的错误、是否能够正常工作以及能否满足系统的需求

5.4    测试技术


测试技术


是否采用


说明


里程碑技术


采用


里程碑的达成标准及验收方法在测试完后制订


自动测试技术


采用


核心业务流程采用自动测试技术


审评测试


采用


对软件产品功能说明文档和设计说明文档进行检查,在需求与设计阶段进行


编写测试用例


采用


在产品编码阶段编写测试用例


单元测试


不采用


由开发人员进行


集成测试


采用


检测模块集成后的系统是否达到需求对业务流程及数据流的处理是否符合标准、系统对业务流处理是否存在逻辑不严谨及错误以及是否存在不合理的标准及要求。


确认测试


采用


在产品发布前,对照feature list 进行基本需求的确认,确认产品是否正确实现了功能。


系统测试


采用


包括性能测试、压力测试和回归测试


验收测试


不采用


由工程实施人员进行

6测试计划

6.1进度计划

在此章节,对各阶段的测试给出里程碑计划,包括阶段、里程碑、资源等。

6.1.1测试时间进度


测试阶段


开始时间


完成时间


测试人员


制定测试计划


6.10


6.15


朱云铖


需求Review


6.10


6.18


李伟


设计Review


6.10


6.17


李伟


设计测试用例


6.10


6.19


刘世贤


测试开发


5.10


6.05


刘世贤


测试环境准备


6.10


6.15


黄彦潇


测试实施


6.15


6.30


黄彦潇

6.2测试准备

6.2.1  测试环境准备


准备事项


开始时间


完成时间


测试人员


测试环境准备


6.10


6.15


黄彦潇

6.2.2    安装测试


准备事项


开始时间


完成时间


测试人员


安装测试


6.30


6.30


朱云铖

6.3 具体测试实施任务和时间人员安排


测试功能点


开始时间


完成时间


测试人员


说明


路线检索


6.15


6.16


朱云铖


测试反应速度


路线规划


6.16


6.17


李伟


测试是否准确


在线挂号


6.17


6.17


刘世贤


测试是否卡顿


在线求医


6.17


6.18


黄彦潇


测试是否可行


在线购药


6.18


6.18


朱云铖


测试是否出现致命错误


智能控制


6.19


6.20


朱云铖


配合硬件测试

时间: 2024-10-05 23:25:05

团队作业—第二周—软件测试计划的相关文章

团队作业—第二周—SRS

一.系统整体用例图: 二.用户用例图: 三.医院用例图:

团队项目第二周 测试计划

第一章 引言     1.1目的 简述本计划的目的,旨在说明各种测试阶段任务.人员分配和时间安排.工作规范等. 测试计划在策略和方法的高度说明如何计划.组织和管理测试项目.测试计划包含足够的信息使测试人员明白项目需要做什么是如何运作的.另外,清晰的文档结构能使任何一个读者在浏览计划的前面几页后,就能对项目有一个大概的认识.测试计划只是测试的一个框架,很多细节需要跟开发人员或其他人员沟通,因此计划不包括测试用例的细节和系统功能的详细信息.在计划目的中需要指明读者对象.     1.2名词解释 列出

团队项目第二周-需求分析(五饭来了吗队)

团队项目2048---第二周计划 (1)项目内容: ? 2048拓展游戏,这款游戏结合了传统2048游戏以及传统俄罗斯方块游戏,并且将汉字作为基本元素,游戏难度增加的同时趣味性也会大大提升,通过消去的汉字来积累分数. (2)用户数量: ? 这次项目是在web端实现开发,用户数量预期1000. (3)开发价值: ? 作为一款游戏,真实性和可用性每位玩家都会感受到,不多赘述. ? 价值性:目前传统游戏的用户数量并不多,作为传统游戏与传统游戏的结合产物,上手简单,这款游戏将单调的数字变换变成了汉字的各

团队作业-第一周-团队分工和绩效评估

1.团队项目: 移动校园点名APP 2.团队成员: 张昊.曹金钰.郭翠.王建斌 3.团队分工: 张昊 负责编写代码并整合所有成员编写的代码 曹金钰 负责功能需求的分析和报告. 郭翠 负责测试软件的功能和性能. 王建斌 负责界面元素的美化,提供资源. 4.团队的绩效评估方法 目标:为了顺利完成团队任务,促进每一个成员的成长和发展. 每次集合是否按时到场 是否能促进团队的团结. 是否能按时在团队合作中按时完成编码任务 是否能按时提交每日的工作日志 每次提交代码是否写单元测试 达到以上要求者可以给予绩

第三次团队作业:记账软件软件设计

第一部分数据库设计 部分功能数据流图(Gane-Sarson) 记账软件顶层数据流图 1.1.2 细化记账功能数据流图 1.1.3 再次细化该数据流图 1.1.4 数据流图说明 该记账软件的功能主要分为记收入账和记支出账,记录相应的账单信息后,可以生成账单图表,表格可以在一张表中同时给出收入和支出的账单报告,也可根据用户需求将它们分开展示. 1.2 用户登录数据流图 1.3 查询功能数据流图 1.4 概念数据模型 1.5 物理数据模型 1.6 数据字典                      

个人博客作业第二周——是否需要有代码规范

1. 是否需要有代码规范 对于是否需要有代码规范,请考虑下列论点并反驳/支持: 这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率, 浪费时间的东西. 我是个艺术家,手艺人,我有自己的规范和原则. 规范不能强求一律,应该允许很多例外. 我擅长制定编码规范,你们听我的就好了. 首先,代码规范是一定要有的,这一点不容置疑.记得刚学C语言时,老师跟我们讲一些编码的例子,譬如说等号两边要加空格,运算符的两边也要加空格.那个时候打心眼里觉得这些规矩太过繁琐迂腐,觉得咱们中国人就是喜欢搞这种形

团队项目第二周spec设计

本系统针对局域网进行联机聊天.聊天室分为服务器端和和客户端俩部分,服务器端程序主要 负责侦听客户端发来的信息,客户端需要登录到服务器端才可以实现正常的聊天功能. 1.本软件是一款局域网聊天软件,不能进行网络聊天. 2.本软件主要功能是局域网聊天,附带局域网内文件互传. 3.使用前要先用自己的ip登录,成功登录后才能使用以上功能. 4.登录步骤:(1)启动服务器. (2)进入客户端界面. (3)登录聊天室. 4.此软件运行时一台主机只能启动一个服务器. 5.系统运行稳定.安全可靠.

课堂作业第二周

1 题目避免重复 用随机数生成两个数,将两个数分别存入两个数组,每出一道题都与以前的每组进行对比,如果两个数分别都与以前的相同,则重新产生两个随机数. 2 可定制(数量/打印方式) 设置参数,用for循环控制出题数量 3 可控制下列参数: 是否有乘除法,数值范围,加减有无负数,除法有无余数,是否支持分数(真分数,假分数) 设置参数,用if来判断是否有乘除法.由于用roud()函数产生随机数所以用变量控制数值范围.随机数生成后进行判断,若无负数则要求第一个随机数必须大于第二个否则重新产生. 若不产

JVM培训作业第二周

1. jre的运行时主要jar文件rt.jar都很大,这导致了用java做的桌面客户端程序很难发布绑定jre发布.这在很大程度上限制了java桌面软件 的分发.可是,jre并不是在所有的用户计算机上都有安装,即使安装了,也未必我们期望的版本.因此,对jre做精简,减少体积是有必要的.请你给出一个 方案,来说说如何给jre减肥,以方便我们的桌面程序绑定jre发布.并给出一个基本的实现.对这个实现的要求是:对于任意给定java程序A,应用你的 方案和实现,可以从一个完整的jre中,抽取这个程序A的必