1.1 编写目的
-编写本测试计划的目的是为整个测试阶段的管理工作和技术工作提供指
南；同时确定测试的内容和范围。
1.2 背景
说明本测试计划所属测试对象的名称、特征、要求和难点，以及在开始执行本测试计划之前必须完成的各项任务。
1.3 参考资料
《软件测试技术教材》
2.1 测试计划标识符
Version：20190511
2.2 测试项目简介
一、人员信息管理主要包括以下模块
== 1.人员登陆==
==2.添加人员==
==3.编辑人员==
==4.删除人员==
二、相关工具技术
主要技术：java EE tomact mysql QTP loadrunner
（1）链接测试
（2）处理事务的速度
（3）连接速度测试
（4）负载测试
（5）压力测试
（6）不同设备兼容性测试
（7）用户界面测试(侧重于可用性/易用性测试)
4.1功能测试
（1）登录测试
验证的主要内容注册登录提交应当模拟用户提交，验证是否进入主界面，要测试这些功能，需要验证存储器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。还有数据正确性验证，异常处理等，最好结合易用性要求等。
4.2性能测试
（1）处理事务速度测试
要是测试软件处理事务的速度性能测试即测试软件处理事务的速度,是为了检验性能是否符合需求,二是为了得到某些性能数据供人们参考(例如用于宣传)。有时人们关心测试的“绝对值”，如数据送输速率是每秒多少比特—在获取测试的“绝对值”时，我们要充分考虑并记录运行环境对测试的影响。例如网络环境、计算机主频，总线结构和外部设备都可能影响软件的运行速度。有时人们关心测试的“相对值”，如某个软件比另一个软件快多少倍。
（2）连接速度测试
当用户连接到 web 应用系统的速度根据上网方式的变化而变化,他们或许是电话拨号,宽带上网。当下载一个程序时,用户可以等较长的时间,但如果仅仅访问一个页面就不会这样。如果 web 系统响应时间太长(例如超过5秒钟)用户就会因没有耐心等待而离开。另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
（3）负载测试
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。
例如: 该通讯录系统能允许多少个用户同时在线?如果超过了这个数量， 会出现什么现象? 通讯录系统能否处理大量用户对同一个页面的请求?负载测试-般使用工具完成，loadrunner, webload,等。
（4）压力测试
压力测试也叫负荷测试，即获取系统能正常运行的极限状态和故障恢复能力。了解“极限”是很有价值的，例如潜艇下潜极限深度.。压力测试的主要任务是:构造正确的输入，使劲折腾系统却让它刚好不瘫痪。在实际的网络环境中进行测试。压力测试一般应该安排在应用系统发布以后，在实际的网络环境中进行测试——因为一个企业内部员工，特别是项目组人员总是有限的，而一个应用系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet 上，接受负载测试，其结果才是正确可信的。
（5）不同设备上的兼容性测试
不同设备上的兼容性测试，
内核决定了浏览器如何显示网页的内容以及页面的格式信息，不同的浏览器所使用的内核及所支持的HTML等网络语言标准不同，以及用户客户端的环境不同（如分辨率不同）造成显示的效果不能达到理想的效果，最常见的就是网页元素位置的错位、混乱。
（6）注意事项
5.1白盒测试
白盒测试：又称为结构测试或逻辑驱动测试，是一种按照程序内部逻辑结构和编码结构，设计测试数据并完成测试的一种测试方法。
白盒测试具体方法如下（只例举本次试验采用的）：
5.2黑盒测试
黑盒测试（Black-box Testing，又称为功能测试或数据驱动测试）是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。
采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。
黑盒测试试图发现以下类型的错误：
1）功能错误或遗漏；
2）界面错误；
3）数据结构或外部数据库访问错误；
4）性能错误；
5）初始化和终止错误。
一、黑盒测试的测试用例设计方法
· 等价类划分方法
· 边界值分析方法
· 错误推测方法
· 因果图方法
等价类划分：
是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的，常用的黑盒测试用例设计方法。
划分等价类：
等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试。因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据。取得较好的测试结果。等价类划分可有两种不同的情况：有效等价类和无效等价类。
有效等价类：是指对于程序的规格说明来说是合理的，有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
无效等价类：与有效等价类的定义恰巧相反。
设计测试用例时，要同时考虑这两种等价类。因为，软件不仅要能接收合理的数据，也要能经受意外的考验。这样的测试才能确保软件具有更高的可靠性。
2）划分等价类的方法：下面给出六条确定等价类的原则。
① 在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。
② 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类。
③ 在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。
④ 在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。
⑤ 在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
⑥ 在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。
3）设计测试用例：在确立了等价类后，可建立等价类表，列出所有划分出的等价类：
输入条件 有效等价类 无效等价类
然后从划分出的等价类中按以下三个原则设计测试用例：
① 为每一个等价类规定一个唯一的编号。
② 设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖地有效等价类，重复这一步。直到所有的有效等价类都被覆盖为止。
③ 设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步。直到所有的无效等价类都被覆盖为止。
边界值分析法
边界值分析方法是对等价类划分方法的补充。
（1）边界值分析方法的考虑：
长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。
使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。
（2）基于边界值分析方法选择测试用例的原则：
1）如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。
2）如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少一，比最大个数多一的数作为测试数据。
3）根据规格说明的每个输出条件，使用前面的原则1）。
4）根据规格说明的每个输出条件，应用前面的原则2）。
5）如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。
6）如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。
7）分析规格说明，找出其它可能的边界条件。
错误推测法
错误推测法： 基于经验和直觉推测程序中所有可能存在的各种错误， 从而有针对性的设计测试用例的方法。
错误推测方法的基本思想： 列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。 例如， 在单元测试时曾列出的许多在模块中常见的错误。 以前产品测试中曾经发现的错误等， 这些就是经验的总结。 还有， 输入数据和输出数据为0的情况。 输入表格为空格或输入表格只有一行。 这些都是容易发生错误的情况。 可选择这些情况下的例子作为测试用例。
因果图方法
前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系， 相互组合等。 考虑输入条件之间的相互组合，可能会产生一些新的情况。 但要检查输入条件的组合不是一件容易的事情， 即使把所有输入条件划分成等价类，他们之间的组合情况也相当多。 因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例。 这就需要利用因果图（逻辑模型）。
因果图方法最终生成的就是判定表。 它适合于检查程序输入条件的各种组合情况。
利用因果图生成测试用例的基本步骤：
（1） 分析软件规格说明描述中， 那些是原因（即输入条件或输入条件的等价类），那些是结果（即输出条件）， 并给每个原因和结果赋予一个标识符。
（2） 分析软件规格说明描述中的语义。找出原因与结果之间， 原因与原因之间对应的关系。 根据这些关系，画出因果图。
（3） 由于语法或环境限制， 有些原因与原因之间，原因与结果之间的组合情况不不可能出现。 为表明这些特殊情况， 在因果图上用一些记号表明约束或限制条件。
（4） 把因果图转换为判定表。
（5） 把判定表的每一列拿出来作为依据，设计测试用例。
从因果图生成的测试用例（局部，组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况，构成的测试用例数目达到最少，且测试用例数目随输入数据数目的增加而线性地增加。
前面因果图方法中已经用到了判定表。判定表（DECision Table）是分析和表达多逻辑条件下执行不同操作的情况下的工具。在程序设计发展的初期，判定表就已被当作编写程序的辅助工具了。由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。
5.3测试模板
1）功能测试用例通用模板：
2）性能测试用例通用模板：
3）压力测试用例参考模板：
6.1编辑人物，删出人物，查找人物功能
结合组员实际能力而定，将精力放在了登录功能，其他的留给以后再战
6.2页面切换功能测试
页面切换是web中自带的post 或者 get 发起,利用servlet控制的功能，是开发工具已经完善好了
8.1缺陷数量过多导致程序无法继续运行时，考虑中断测试
8.2有严重缺陷时（登录加载时出现问题、查询客户信息没有达到预期结果等）考虑中断测试
8.3测试环境未达到要求，或先行条件没有满足时考虑中断测试
8.4关键路径上有未完成任务，考虑中断测试
8.5因缺陷过多导致的中断，停止该功能的测试并标记多缺陷
8.6因严重缺陷导致测试无法进行的，可选择性跳过此缺陷进而恢复测试
8.7因测试环境没有达到要求的中断，再调配至合适的环境下恢复测试
9.1软件测试计划文档
9.2测试用例设计文档
9.3缺陷报告文档
9.4测试总结报告
Eclipse ee tomact mysql
本测试由武汉纺织大学软件测试技术课程参课同学自由组成，小组成员包括胡兵 王金经 施琴琴 张春帅四名同学，其中胡兵担任本测试组组长。
测试任务方面，经小组成员共同选择，最终决定测试web项目–人员管理系统
此系统大都在之前课程中已经做出来了，由组长将其再次优化，然后进行统一测试。
