小组成员有吕晓芬，马涵韵，马钰言，苗萌，孙涛，田蜜
Discuss your test plan
关键词(Keywords):基于web的网上书店系统的设计和实现
摘要(Abstract)：该图书馆管理信息系统是基于Internet及Web技术，建立Browser/Server 为结构模式、以数据库为后台核心应用、以服务为目的信息平台，对资源进行科学的加工整序和管理维护，为教学和科学研究提供文献信息保障和提高网上书店的效率而设计的系统。
1.测试计划目的
本测试计划作为指导此测试项目循序渐进的基础，帮助我们安排合适的资源和进度，避免可能的风险。本测试计划有助于实现以下目标：
确定现有项目的信息和相应测试的软件构件
列出推荐的测试需求（高级需求）.
推荐可采用的测试策略.并对这些策略加以详细说明
确定所需的资源，并对测试的工作量进行估计。
列出测试目的可交付元素，包括用例以及测试报告等。
2.测试计划范围
由于活动的相互影响和制约，系统的设计完成中可能存在某些错误,软件测试主要是对电子化存储管理系统进行全面的检査，及时发现系统中的逻辑错误，以保证产品的正确性和可靠性。
具体结合到操作，应该测试以下内容：
易用性：即人机交互。
性能：即检查快速载入和导出数据、检查系统响应等。
功能:即用户在系统中可以进行的各种操作。
业务规则：即检查对业务流程的描述是否准确、考虑与目标用户的业务环境是否契合等。
事务准确性:即保证事务正确完成、确保被取消的事务回滚正确等。
数据有效性与完整性：即检查数据的格式是否正确、确保字符集适当等。
3.测试计划（Test Plan）
3.1 资源需求（Resource Requiremenls）
3.1.1 软件需求（Software Requirements）
| 资源(Resource) |
描述(Description) |
数量（Qty） |
| 操作系统 |
Windows xp,Windows 10
|
2 |
| 数据库 |
MySQL |
1 |
| 编译器 |
Eclipse |
1 |
| 测试工具 |
JUnit（单元测试） |
2 |
3.1.2 硬件需求(Hardware Requirements)
| 资源(Resource) |
描述(Description ) |
数量(Qty) |
| 计算机 |
模拟浏览器环境 |
1 |
| 浏览器 |
实际测试系统的功能 |
1 |
3.1.3 其他设备(Other Materials)
无。
3.1.4 人员需求(Personnel Requirements)
| 资源(Resource ) |
技能级别(Skill Level) |
数量(Qty) |
到位时间(Date) |
工作期间(Duration) |
| 单兀测试工程师 |
高级 |
1 |
|
|
| 集成测试工程师 |
中级 |
1 |
|
|
| 系统测试工程师 |
中级 |
1 |
|
|
| 功能测试工程师 |
中级 |
2 |
|
|
| UI测试工程师 |
中级 |
2 |
|
|
3.2 过程条件(Process Criteria)
启动条件(Entry Crileria)
需求规格说明书完成以后
结束条件(Exit Criteria)
各项测试完成，项目交付。
3.3 挂起条件(Suspend Criteria)
（1）项目进度出现问题,程序不能按时完成,无法进行相关测试。
（2）测试人员缺乏相关测试技术，不能很快完成测试工作。
3.4 恢复条件(Kesume Crileria)
（1）要求开发人员加快开发速度,按时完成程序。
（2）进行相关测试培训，提高测试人员的技能。
3.5 测试目标(Objectives)
程序能正常运行，实现了需求中的各项功能，人机交互良好，程序健壮，经过测试，系统无严重缺陷，设计的测试用例90%执行,确定的所有缺陷都已得到了商定的解决结果，而且没有发现新的缺陷。
3.6 导向/培训计划( Orientation/Training Plan)
（1）培训可包括用户指引、操作指引、维护控制组指引测试人员学习测试规格说明书。
（2）对测试人员进行相关测试培训。
3.7 回归测试策略(Strategy of Regression Test)
在下一轮测试中,对本轮测试发现的所有缺陷对应的用例进行回归，确认所有缺陷都已经过修改。
4.测试用例（Test Cases）
| 需求功能名称 |
测试用例名称 |
作者 |
应交付日期 |
| 用户登录测试 |
用户登录测试用例 |
* * * |
2020-01-05 |
| 管理员登录测试 |
管理员登陆测试用例 |
* * * |
2020-01-05 |
| 普通用户修改密码测试 |
普通用户修改密码测试用例 |
* * * |
2020-01-05 |
| 管理员修改密码测试 |
管理员修改密码测试用例 |
* * * |
2020-01-05 |
| 普通用户修改个人信息测试 |
普通用户修改个人信息测试用例 |
* * * |
2020-01-05 |
| 管理员修改个人信息测试 |
管理员修改个人信息测试用例 |
* * * |
2020-01-05
|
| 用户注册测试 |
用户注册测试用例 |
* * * |
2020-01-05
|
| 书籍查询测试 |
书籍查询测试用例 |
* * * |
2020-01-05
|
| 系统设置 |
系统设置测试用例 |
* * * |
2020-01-05 |
5.工作交付件(Deliverables)
| 名称(Name) |
作者(Author) |
应交付日期(Delivery Date) |
| 测试计划评审报告 |
* * * |
2020-01-05 |
| 测试计划 |
* * * |
2020-01-05 |
| 测试用例说明书 |
* * * |
2020-01-05 |
Do we need to test until our software is PERFECT?
我们认为没有完美的软件，只有需要更加完善的软件。我们测试时不仅要证明软件的正确性，更应该证明软件是错的，测试人员不能只考虑正确的流程，往往出错最多的是通过逆向思维测试，反逻辑测试，违背常规的测试所测试出来的。所以说测试不是为了证明软件的正确性，而是恰恰相反的证明软件的错误性。
我认为应该尽可能地去让一款软件去趋近于完美，但是要想真正的去做，我个人认为是不可能的，因为一款软件最终的结果是面向大众的，工程师口中所说的完美应该是站在大多数人的角度上来讲的，程序员无法让每个人都满意这一款软件，但是能让大多数人满意就行。一款软件在做测试的时候，是为了发现问题，并且去解决问题，正如现在的很多软件来说，在用户使用的过程中发现了错误，只要不是造成巨大的损失，都是可以接受的。我们要尽力做到让我们的软件变得完美，这本来就是我们软件设计时的初衷，从开始的由无到有，一步步完善都是为了得到一个更好更齐全更完美的成果，软件效果要满足用户需求，所以要不断去完善，尽量尽快做到契合用户的需求就是我们软件的设计方向，要做就要尽量做到完美。
What is “good enough” for testing?
Good Enough Testing是形成一个充分的质量评估的过程，这个过程建立在合理的代价之上，用于支持对产品作出明智的、及时的决定。
把定义分解成4部分：
（1）产品质量的评估：
产品的正确性和完整性如何？
（2）测试的代价：
测试消耗的合理的程度如何？是否在项目限制范围内？对测试的投入是否有好的回报，例如，每次测试后，是否有额外的信息可提供？
（3）决定：
产品质量的评估是否很好地服务于项目和业务？
（4）及时性：
对评估、决定的及时性，是否足够快，从而发挥作用？
有些测试员会被告知他们所做的测试不会影响产品发布的决定。如果是这样的话，测试就应该停止了。
相反，如果继续测试会提供技术支持或为公司的某些其它类型的决定提供基础支持，那么就应该继续测试。因为测试与某些要作出的决定联系在一起，或为提供某些数据以备将来使用。
某些测试是在组织或某些所谓的权威人士要求下进行的，有些测试仅仅是因为测试计划制定了，所以执行。这与Good Enough Testing的原则是违背的，Good Enough Testing是有意识的、有目的的测试，不是迷信和仪式。其实很多制定的测试计划中提到的测试是可以抛弃的，因为它们对测试项目或对利益相关方完全没有什么影响。
很多时候，测试计划的编写是因为某些人说：“教科书上说我们应该有这种测试”。
评估的组成
1.评估产品质量
（1）我们是如何评估和报告产品质量的？
（2）我们是否确定质量的评估是可被证实正确的？
（3）我们是否清楚明示和暗示的产品需求？
（4）我们能在产品创建出来后多快地找到产品中的重要的问题？
（5）我们的测试是否覆盖了需要覆盖的产品的各个方面？
（6）我们是否应用了足够的测试方法类型或采用了足够的关于质量信息的资料来源来消除测试覆盖的误差？
（7）是否在产品中存在我们不知道的重大问题的可能性？
（8）是否存在本应该是测试发现的问题而测试员未发现，而是被其它渠道发现并报告？
2.评估测试代价
（1）测试的消耗有多大？我们能承受的测试代价是多大？
（2）我们能否从测试覆盖中消除不必要的冗余？
（3）是什么让测试执行困难（代价高）？
（4）产品的可测性能否再提高？
（5）是否有工具或技术可以使测试过程更加高效？
（6）早点测试好还是迟点测试好?哪种情况下测试的整体成本低一些？
3.检查测试对决策的作用
（1）测试过程是否清楚管理者、开发人员或其它客户需要做的决定？
（2）测试过程是否关注潜在产品和项目风险？
（3）测试过程是否依赖变更控制过程和项目管理？
（4）测试报告是否及时递交？
（5）测试报告是否用易于理解的方式沟通？
（6）测试过程和测试结果一样被传达吗？我们是否报告评估的基础以及融入我们的信心在里面？
（7）测试过程是否对技术支持、发行、市场或其它需要使用质量评估的任何业务过程提供服务？
4.是否及时
以上三方面都是时间驱动的。所以带来了问题：我们永远也没有足够的时间去做每一件事，所以我们要做的每一件事都是与时间赛跑。
整合分析
1.我们的测试有多好？
（1）综合前面的几个问题，考虑我们现在的测试过程中是否存在紧迫的问题？
（2）我们的测试流程是否充分，是否能在产品质量未能达到预期目标时对项目管理提出预警？
（3）是否存在某些潜在类型的问题是不可忍受的，如果有，我们是否有信心我们的测试流程能发现并定位这些问题？
2.是否值得改进？
（1）我们能用什么策略改进测试？
（2）我们有能力应用这些测试策略吗？我们知道怎样应用吗？
（3）改进测试会有多大消耗？会有多麻烦？是否是利用资源的最佳方式？
（4）能否暂时不改进？能否在一个可接受的时间范围内达到改进？
（5）改进是否会造成反效果，引入新的bug，对士气造成影响？
（6）改进会带来明显的不同吗？
测试经理不愿意面对“毫无遗漏的测试是不可能的”这一事实的话，他就会选择一个不可能完成的测试。
Good Enough Testing 的目的是帮助软件测试工程师摆脱测试的条条框框、主观性、被动的局面，把结构化的、合理的方法应用到复杂的、多维的问题集合中去。