- 引言：
|
编 |
确定项目 |
描述 |
|
1 |
确定范围 |
确定被测项目中功能模块，子功能模块等需要测试的范围。 |
|
2 |
确定需求 |
确定每个功能结果定义，确定此功能是否存在缺陷。 |
|
3 |
确定策略 |
确定对项目做哪些测试。如：功能测试，性能测试等。 |
|
4 |
确定方法 |
确定对每个策略是用哪些方法。如：边界值，等价类等。 |
|
5 |
确定工具 |
如: 功能测试使用Seleium，性能测试使用Jmeter等。 |
|
6 |
确定资源 |
测试需要的设备，服务器、参与测试的人员、测试任务的分工，测试工作的进度。 |
|
7 |
交付文档 |
确定测试工作中生成哪些文档，可提交文档有哪些。 |
- 测试项目：
|
项目名称 |
XX项目 |
|
使用背景 |
// 用户 协会分会负责人、期刊客户 |
|
开发者 |
XX集团 |
|
项目简介 |
学术专著出版平台” 定位是一家图书产品联合创建、销售、返利的平台；平台联合各专业协会、学会、出版 等机构，组织大批专家人才建立“专家指导委员会”，为图书进行策划、上 、审校、出版、运营等服务；主要业务情景是：策划人寻求参编人，共同创建图书及销售，参编人支付参编图书的预购款，该笔资金作为公司运营图书的成本，等待图书出版后，让消费者以个人名片或链接的形式进行购买图书，参编人员不仅可以通过图书评职称、扩大知名度、传播学术价值，另外让参编人通过销售，实现“0”元出书并且获得额外收入；策划人在发展参编和策划人同时，获得相应奖励。 |
- 测试目的：
|
编 |
目的 |
|
1 |
软件测试是为了发现错误而执行程序的过程。 |
|
2 |
测试是为了证明程序有错，而不是证明程序无错。 |
|
3 |
一个好的测试用例在于它发现至今未发现的错误。 |
|
4 |
一个成功的测试是发现了至今未发现的错误的测试。 |
- 文档受众：
|
编 |
人员 |
原因 |
|
1 |
产品设计人员 |
明确说明测试范围，方法，工作周期信息。 |
|
2 |
产品研发人员 |
明确说明测试范围，方法，工作周期信息。 |
|
3 |
产品测试人员 |
明确说明测试范围，方法，任务分工，预计完成时间。 |
|
4 |
备注 |
此为内部开发文档，不做外部参考。 |
- 测试参考文档
|
编 |
文档名称 |
作用 |
|
1 |
需求文档 |
确定项目功能模块，功能运行结果。 |
|
2 |
技术文档 |
确定项目中使用开发语言，数据库数据限制。 |
|
3 |
项目模型文档 |
初步了解项目页面内容，方便编写用例。 |
- 测试提交文档：
|
编 |
文档名称 |
作用 |
|
1 |
测试计划 |
明确说明测试范围，方法，工作周期信息。 |
|
2 |
测试用例 |
明确说明测试工作的细节测试工作。 |
|
3 |
缺陷 告 |
明确说明项目中的缺陷描述，与修复情况。 |
|
4 |
测试 告 |
明确说明测试结果，测试模块，缺陷分布情况等等信息。 |
- 术语定义：
- 项目术语：
|
编 |
缩写、术语 |
解释 |
|
1 |
|
|
|
2 |
|
|
- 测试专业术语：
|
编 |
术语 |
解释 |
|
1 |
单元测试 |
开发者编写的一小段代码，检验被测代码的一个很小的、很明确的功能是否正确。 |
|
2 |
集成测试 |
开发者编写的多个段代码单元，组合到一起形成集成测试，检查多个单元组合功能是否正确。 |
|
3 |
冒烟测试 |
针对产品的基本功能进行测试。 |
|
4 |
功能测试 |
又称正确性测试，它检查软件的功能是否符合规格说明。 |
|
5 |
可靠性测试 |
对服务器施加一定压力，测试服务器是否可以长期稳定运行。 |
|
6 |
压力测试 |
对服务器施加一定压力后进行功能测试，测试服务器在一定压力下是够可以正常计算。 |
|
7 |
负载测试 |
对服务器施加压力，测试服务器可以容纳多少人访问，多少人访问后出现BUG。 |
|
8 |
易用性测试 |
主要从使用的合理性和方便性等角度对软件系统进行检查。用户来测。 |
|
9 |
兼容性测试 |
测试Web页面是否支持所有浏览器，访问后页面所有功能无异常。 |
|
10 |
安全测试 |
服务器数据安全性，用户数据安全性，用户操作安全性，用户财产安全性、公司财产安全性。 |
|
11 |
数据完整性测试 |
对数据及数据库能否正常运行访问的测试。 |
|
12 |
回归测试 |
开发修改后的BUG在测试一遍。 |
|
13 |
|
|
|
14 |
|
|
- 缺陷优先级：
|
级别 |
描述 |
|
P0 |
严重级别比较高的，影响测试进行或者系统无法继续操作，立即修复，1天。 |
|
P1 |
基本功能没有实现，对系统操作有影响，2－3天。 |
|
P2 |
一般性功能，页面缺陷，4－5天。 |
|
P3 |
准备在下一轮测试前修改完毕，准备在下一版本中修改。 |
- 严重程度定义：
|
级别 |
严重程度描述 |
|
S0 |
数据丢失，数据计算错误、数据传递错误、对数据库造成破坏，造成操作系统或其他支撑系统崩溃、非正常关闭和非正常死机。 |
|
S1 |
应用系统崩溃、非正常关闭和无响应，但没有造成数据丢失。系统的主要功能不能正确实现或不完整。 |
|
S2 |
规定的非主要功能没有实现或不完整、影响系统的运行；设计不合理造成性能低下。 |
|
S3 |
不影响业务运行的功能问题。 |
|
S4 |
软件设计和功能实现等不完全合理之处提出建议。 |
- 用例优先级定义：
|
级别 |
优先级描述 |
|
P0 |
确保系统基本功能及主要功能的测试用例 |
|
P1 |
确保系统功能的完善方面的测试用例 |
|
P2 |
关于用户体验，输入输出的验证；较少使用或辅助功能的测试用例。 |
- 测试策略：
1、单元测试
|
|
单元测试 |
|
测试目标 |
开发者编写的一小段代码，检验被测代码的一个很小的、很明确的功能是否正确。 |
|
测试范围 |
测试整个项目中的每一行代码进行测试。 |
|
完成标准 |
代码的一个很小的、很明确的功能都正确。 |
|
需要考虑的特殊事项 |
// |
|
使用工具 |
Python + Selenium + unittest |
2、集成测试：
|
|
集成测试 |
|
测试目标 |
开发者编写的多个段代码单元，组合到一起形成集成测试，检查多个单元组合功能是否正确。 |
|
测试范围 |
开发者编写的多个段代码单元，组合到一起形成的集合。 |
|
完成标准 |
多个单元组合功能正确。 |
|
需要考虑的特殊事项 |
// |
|
使用工具 |
|
3、冒烟测试：
|
|
冒烟测试 |
|
测试目标 |
版本是否值得系统测试 |
|
测试范围 |
1、返测上一版本提交的测试 告。 |
|
完成标准 |
基本功能通过，并继续测试。 |
|
需要考虑的特殊事项 |
此阶段不超过1天。 |
4、功能测试：
|
|
功能测试 |
|
测试目标 |
确保测试计划中所列出的测试范围，保证其功能正常。 |
|
测试范围 |
1、按照测试计划所规定的测试范围。 |
|
完成标准 |
按照测试计划的测试通过标准，完成测试。 |
|
需要考虑的特殊事项 |
确定或说明那些将对功能测试的实施和执行造成影响的事项或因素。（内部的或外部的） |
|
使用工具 |
Seleium + python + 谷歌 |
- 易用性测试：
|
|
易用性测试 |
|
测试目标 |
模拟真实用户，无经验用户，测试系统的易用性 |
|
测试范围 |
前台 |
|
完成标准 |
成功地核实出前台各个 页符合可接受易用性标准。 |
|
需要考虑的特殊事项 |
无 |
7、兼容测试：
|
|
兼容测试 |
|
测试目标 |
测试Web页面是否支持所有浏览器，访问后页面所有功能无异常 |
|
测试范围 |
前台 |
|
完成标准 |
使用多个不同浏览器访问后界面无异常即为通过。 |
|
需要考虑的特殊事项 |
浏览器版本；浏览器类型是否都测到。 |
8、可靠性测试：
|
|
可靠性测试 |
|
测试目标 |
使用LR模拟真实用户对服务器施加一定压力 |
|
测试范围 |
项目服务器。 |
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！
介绍一款国际性的本体 群聊天软件Discord
上一篇
2019年8月21日
Mongodb 安装
下一篇
2019年8月21日
|