1.我们的测试计划
测试目的：
初级编程者的我们难免有些漏洞，错误不可避免。测试对我们而言不可或缺。为了app更为流畅便捷的运行，为了提高用户的体验感，坚持通过测试来改进。
测试任务：
我们的测试较为简单,包括：功能测试、性能测试、用户界面（UI）测试、安全性与访问控制测试、兼容性测试、回归测试。
测试资源：
角色：我们的”经典用户及其场景描述”已经描述过（见个人博客）。
测试环境：
软件环境：
操作系统：win7 win8 win10
安卓开发：eclipse-ADT，jdk1.7
数据库：mysql5.7.10
服务器：myeclipse2014a jdk1.6
硬件环境：
见”测试矩阵”
测试工具：
LoadRunner性能测试工具、 TestDirector
测试设计安排：
| 测试活动 | 测试任务 | 技术 | 完成标准 |
|
第一阶段 功能测试 |
验证数据精确度、数据类型、业务功能等相关方面的正确性。 | 采用黑盒测试，使用边界值测试、等价类划分，数据驱动等测试方法 | 95%用例通过并且最高级缺陷全部解决 |
|
第二阶段 性能测试 |
大流量的数据与多用户操作时性能方面的测试 | 自动化测试 | app满足用户需求中所要求的性能需求 |
|
第三阶段 UI测试 |
1.导航、连接、Cookie、页面结构包括菜单、背景、颜色、字体、按钮名称、TITLE、提示信息的一致性等。 2.友好性、可操作性（易用性）。 |
WEB测试通用方法 | UI符合可接受标准、能够保证用户界面的友好性、易操作性、而且符合用户操作习惯。 |
|
第四阶段 安全性与 问控制测试 |
1.密码、登录、管理员、普通用户等。 2.权限。 3.非法攻击。 4.登录超时限制等。 |
代码包或者非法攻击工具 | 执行各种非法操作无安全漏洞且app使用正常。 |
|
第五阶段 兼容性测试 |
1.使用不同版本的不同浏览器、分辨率分别进行测试； 2.不同浏览器、分辨率等各种条件的组合测试。 |
黑盒测试 | 在各种条件下均能正常实现其功能。 |
|
第六阶段 回归测试 |
以上测试回返重新测试 | 手工测试和自动化测试 | 95%的测试用例执行通过测试 |
测试用例数估计：
| 功能点或测试类型 | 最多用例数 | 适中用例数 | 最少的用例数 | 合计 |
| 模块1（安全性测试） | 5 | 3 | 2 | 3 |
| 模块2（功能测试） | 60 | 50 | 40 | 50 |
| 模块3（功能测试） | 60 | 50 | 40 | 50 |
| 模块4（性能测试） | 5 | 3 | 2 | 3 |
| UI测试 | 6 | 6 | 6 | 6 |
| 回归测试 | 136 | 112 | 90 | 112 |
工作量估计：
| 阶段 |
最多工作量 （人小时） |
适中工作量 （人小时） |
最少工作量 （人小时） |
合计 （人小时） |
| 测试策划 | 6 | 5 | 4 | 5 |
| 测试设计 | 12 | 10 | 8 | 10 |
| 测试实现 | 60 | 50 | 40 | 50 |
| 测试执行 | 45 | 38 | 33 | 38.3 |
| 测试总结 | 6 | 5 | 4 | 5 |
人员安排：
| 角色 | 姓名 | 任务安排 |
| 测试经理 | 宋海龄 | 测试策划 |
| 测试设计员 | 宋海龄 | 测试方案与用户测试设计、测试总结 |
| 测试员 | 宋海龄、贾兆款、禹慧慧、张江鹏 | 测试执行 |
我们是否需要测试，直到我们的软件是完美的？
软件测试是建立对产品信心的过程，将产品引发最终用户损失的风险降低到一个“可接受”的程度。因此，“完美”只能是相对的，或者说测试永达不到完美的程度（这也是测试的魅力所在）。比如我们都知道的一个基本事实是，产品的缺陷是不可能100％消除的。
对于测试来说什么是“足够好”？
软件测试，描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说，软件测试是一种实际输出与预期输出间的审核或者比较过程。软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
所以一个足够好的测试应该保证软件的正确性、完整性、安全性和质量。
“退出的标准”是什么？
测试退出标准
产品的最终发布日期为2016年**月**日。测试退出标准为完成测试需求中列出的所有功能及测试过程中发现缺陷的回归测试。
单元测试退出标准
1) 单元测试用例设计已经通过评审
2) 核心代码100％ 经过Code Review
3) 单元测试功能覆盖率达到100％
4) 单元测试代码行覆盖率不低于80％
5)
所有发现缺陷至少60％都纳入缺陷追踪系统且各级缺陷修复率达到标准
6) 不存在A、B类缺陷
7) C、D、E类缺陷允许存在
8)
按照单元测试用例完成了所有规定单元的测试
9) 软件单元功能与设计一致
集成测试退出标准
1) 集成测试用例设计已经通过评审
2)
所有源代码和可执行代码已经建立受控基线，纳入配置管理受控库，不经过审批不能随意更改
3)
按照集成构件计划及增量集成策略完成了整个系统的集成测试
4)
达到了测试计划中关于集成测试所规定的覆盖率的要求
5)
集成工作版本满足设计定义的各项功能、性能要求
6)
在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准
7) A、B类BUG不能存在
8)
C、D类BUG允许存在,但不能超过单元测试总BUG的50％。
9) E类BUG允许存在
系统测试退出标准
1) 系统测试用例设计已经通过评审
2) 按照系统测试计划完成了系统测试
3) 系统测试的功能覆盖率达100％
4)
系统的功能和性能满足产品需求规格说明书的要求
5)
在系统测试中发现的错误已经得到修改并且各级缺陷修复率达到标准
6) 系统测试后不存在A、B、C类缺陷
7) D类缺陷允许存在，不超过总缺陷的5％
8) E类缺陷允许存在，不超过总缺陷的10％
每个项目团队定义什么是你的beta版本“足够好”？
1.代码错误率0%
2.功能实现98%
3.界面较为美观；
4.安全性达到普通要求；
5.性能稳定，用户使用较为流畅。
你的测试矩阵是什么？
我们的测试矩阵：
| 用户类型 | 屏幕分辨率 | 操作系统 |
操作系统 （缺省语言） |
网络速度 | 浏览器 | 组合总数 | |
| 管理员 | QVGA（240× 320像素） | win7 | 中文简体 | 拨号 |
UC浏览器 |
||
|
一般用户 |
HVGA（480×320像素） | win8.1 | 中文繁体 | ADSL | 百度浏览器 | ||
| 游客 | VGA（640×480像素） | win10 | 英文 | 局域网 | |||
| WVGA（800×480像素） | |||||||
| 变量数目 | 3 | 4 | 3 | 3 | 3 | 2 | 648 |