测试文档_测试文档模板 - CSDN
测试文档 订阅
文档测试是检验样品用户文档的完整性、正确性、一致性、易理解性、易浏览性。测试文档通常情况下指软件测试文档,测试文档是提供测试信息的一组文档,而并非单纯地指文档测试。 展开全文
文档测试是检验样品用户文档的完整性、正确性、一致性、易理解性、易浏览性。测试文档通常情况下指软件测试文档,测试文档是提供测试信息的一组文档,而并非单纯地指文档测试。
信息
外文名
Documentation Testing
意    思
用户文档完整性、正确性、一致性
执行策略
哪些可以先测试
中文名
文档测试
注意事项
仔细阅读,跟随每个步骤
文档测试文档内容
测试方案主要设计怎么测试什么内容和采用什么样的方法,经过分析,在这里可以得到相应的测试用例表。测试执行策略可以主要包括哪些可以先测试,哪些可以放在一起测试之类的。测试用例主要根据测试用例列表,写出每一个用例的操作步骤、紧急程度、预置结果和备注信息。BUG描述报告主要可以包括,测试环境的介绍,预置条件,测试人员,问题重现的操作步骤和当时测试的现场信息。整个项目的测试报告从设计和执行的角度上来对此项目测试情况的介绍,从分析中总结此次设计和执行做的好的地方和需要努力的地方和对此项目的一个质量评价。
收起全文
精华内容
参与话题
  • 标准测试文档

    2020-07-30 23:33:24
    项目名称>的这一“测试计划”文档有助于实现以下目标: [确定现有项目的信息和应测试的软件构件。 列出推荐的测试需求(高级需求)。 推荐可采用的测试策略,并对这些策略加以说明。 确定所需的资源,并对测试的...
  • 如何编写测试文档

    万次阅读 2019-06-27 01:14:29
    如何编写测试文档 相信很多小伙伴都有过产品测试的经历,在测试环节之后,就是要编写合理的测试文档。那么一篇合格的测试文档是什么样的呢? 通常情况下,测试报告上会包含测试进度,测试环境,测试情况大致描述、...

    如何编写测试文档

    相信很多小伙伴都有过产品测试的经历,在测试环节之后,就是要编写合理的测试文档。那么一篇合格的测试文档是什么样的呢?

    通常情况下,测试报告上会包含测试进度,测试环境,测试情况大致描述、作为测试者对于当前版本的看法(是否可以上线),测试内容(测试场景),测试概况,新提交的bug汇总等内容。

    本文中将以我们的一个项目,TimeIsMoney,一款校园做任务挣钱的云平台为例。

     

    测试文档包含的要素

    一、项目背景

    本测试报告的具体编写目的,指出预期的读者范围。

    简单介绍项目的情况,令读者有一个较为明确的产品概念。

    例如:

    Time Is Money将是一款专门面向大学生的C2C的在线应用,是一个为广大高校生群体提供快速兼职的平台。Time Is Money面向所有高校生,用户可以发布任务获取便利,也可以完成任务获得赏金,平台将会保证每一个任务的真实性与可靠性。

     

    二、测试人员

    说明这次测试的人员有哪些,每个人的职责是什么。

    明确责任,明确测试投入人力。

     

    三、测试时间

    这个部分其实是在写测试报告时通常会遗漏的点,因为我们总是认为大家应该是知道时间的,就觉得不重要,但其实这是很基本的要呈现出来的测试要素。明确测试时间,也能让看报告的人知道测试精力投入情况,以此再做其他的评估。

    测试的时间要精准,如果是整个展品的测试,就要写明测试的时间点;如果是针对某个功能的测试,就要注明测试的模块,并写明测试的具体时间,以便于以后将其他模块的测试进行整合。

     

    四、测试平台/测试版本

    注明当前测试的平台,以便于之后的分析工作。

    注明当前测试的版本,如果之后产品进行迭代,可以清楚地区分,并且方便进行比较与整理。

     

    五、版本风险

    当前有哪些已知风险,可能有什么未知风险?基于要事先说的原则,在靠前的位置就需要把当前遇到的可能影响项目质量或者进度的问题列出来,如果是比较紧急的,可以标红或者加粗来引起收件人的注意。

    例如:

    1、设计风险

    (1)没有统一的界面设计规范。

    解决方案:与项目负责人确认测试标准。

    2、开发风险

    (1)所有模块开发没有统一设计,开发人员有自己的设计方式。

    解决方案:与项目负责人确认标准方式,与标准方式不一致的地方全部以BUG形式提交。

    3、测试风险

    (1)版本控制。

    解决方案:严格控制版本,BUG以版本为单位进行提交。在测试过程中及BUG确认阶段禁止任何代码更新。

    (2)测试时间不足。

    解决方案:动员测试人员完成测试任务。

     

    六、测试内容

    测试内容也就是测试场景,是测试文档中最为重要的部分。在这个环节中,我们需要说明在此次测试中测试了什么内容,是怎么测试的,采用的测试场景有哪些,是否符合测试预期,测试的结果是怎么样的。

    我们可以用文字的形式表达出来,具体列举测试中的每一项内容;也可以选择更为直观的方式,比如表格、绘图等。

    例如:

     

    七、测试结果

    测试结果是对于本次测试的一个总结和评价。一般包括:

    1、测试中存在的问题

    2、版本各个模块存在的bug情况

    3、是否有严重的问题,分别是什么问题?

    4、作为测试者对于当前版本的看法(例如从测试的角度上来说这个版本是否可以上线)

    5、项目评价

    如果项目测试效果较好,没有明显的bug,则可以针对需求和设计方面进行评价和总结。

    例如:

    当然也可以采用图表的形式:

     

    以上就是编写测试文档所需要注意的内容了,最后要说明的一点是,一定要注意格式的问题。清晰的层次,一目了然的架构会为你的文档增色不少。

     

    展开全文
  • 软件测试文档(终)

    2019-08-08 09:50:10
    软件测试计划文档 1.引言 1.1编写目的 满足大学生选课需求,解决选课难的问题 1.2项目背景 如今,网上选课已成为大学生必经之路,但是普通的官方系统难以满足大学生需求,我们拟在大学内推广该软件以解决大学...

    软件测试计划文档

    1.引言

    1.1编写目的

    满足大学生选课需求,解决选课难的问题

    1.2项目背景

    如今,网上选课已成为大学生必经之路,但是普通的官方系统难以满足大学生需求,我们拟在大学内推广该软件以解决大学选课难的问题

    1.3术语定义

    Ad hoc testing (随机测试),没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段,是保证测试覆盖完整性的有效方式和过程。

    Alpha testing (α测试),是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha测试不能由程序员或测试员完成。

    Automated Testing(自动化测试),使用自动化测试工具来进行测试,这类测试一般不需要人干预,通常在GUI、性能等测试中用得较多。

    Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta测试不能由程序员或测试员完成。

    Black box testing(黑盒测试),指测试人员不关心程序具体如何实现的一种测试方法。根据软件的规格对软件进行各种输入和观察软件的各种输出结果来发现软件的缺陷的测试,这类测试不考虑软件内部的运作原理,因此软件对用户来说就像一个黑盒子。

    Bug (错误),有时称作defect(缺陷)或error(错误),软件程序中存在的编程错误,可能会带来不必要的副作用,软件的功能和特性与设计规格说明书或用户需求不一致的方面。软件缺陷表现特征为:软件未达到产品说明书标明的功能;软件出现产品说明书指明不会出现的错误;软件功能超出产品说明书指明的范围;虽然产品说明书未指出但是软件应达到的目标;软件测试人员或用户认为软件难以理解,不易使用,运行速度缓慢等问题。

    Bug report(错误报告),也称为“Bug record(错误记录)”,记录发现的软件错误信息的文档,通常包括错误描述、复现步骤、抓取的错误图像和注释等。

    Build(工作版本),软件开发过程中用于内部测试的功能和性能等不完善的软件版本。工作版本既可以是系统的可操作版本,也可以是展示要在最终产品中提供的部分功能的部分系统。

    Compatibility Testing(兼容性测试),也称“Configuration testing(配置测试)”,测试软件是否和系统的其它与之交互的元素之间兼容,如:浏览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。

    Crash(崩溃),计算机系统或组件突然并完全的丧失功能,例如软件或系统突然退出或没有任何反应(死机)。

    Debug(调试),开发人员确定引起错误的根本原因和确定可能的修复措施的过程。一般发生在子系统或单元模块编码完成时,或者根据测试错误报告指出错误以后,开发人员需要执行调试过程来解决已存在的错误。

    Performance testing(性能测试),评价一个产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型。

    Regression testing(回归测试),在发生修改之后重新测试先前的测试以保证修改的正确性。理论上,对软件的任何新版本,都需要进行回归测试,验证以前发现和修复的错误是否在新软件版本上再现。

    Software life cycle(软件生命周期),开始于一个软件产品的构思,结束于该产品不再被使用的这段期间。

    Static testing(静态测试),不通过执行来测试一个系统。如代码检查,文档检查和评审等。

    User interface testing (用户界面测试),指测试用户界面的风格是否满足客户要求,文字是否正确,页面是否美观,文字,图片组合是否完美,操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

    1.4参考资料

    <<软件工程 方法与实践>>,<<软件工程 实验教程>>,<<数据库系统概论>>,<<Qt 快速入门>>

    2.任务概述

    2.1目标

    主要目标:能够与官方选课系统对接,帮助大学生选课

    覆盖范围:大学校内,用户拟定为在校大学生

    验收标准:可完成选课并实现数据共享即可验收

    2.2测试环境

    硬件环境:PC

    软件环境:eclipse SDKSQL server

    2.3需求分析

    2.3.1数据需求

    学生个人账户信息

    2.3.2事务需求

    2.4条件与限制

    硬件设备:PC一台

    软件系统保证:安装eclipse SDK

    人员齐备:全员到齐

    时间限制:一周

    3.计划

    3.1测试方案

    主要内容是需求,分析,设计,实现。

    3.2测试项目

    功能测试

    在线选课:利用鼠标和键盘实现选择需要的课程

    在线退课:利用鼠标和键盘退掉已选课程

    ●回归测试

    定义

    回归测试是指修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

    意义 

    1、避免在回归测试中应各种操作误差所引起的测试结果异常。

    2、可以保持和原始测试一直性。

    3、可以提高测试效率。

    4、测试经理可以更好的掌握测试存在的问题

    ●界面测试

    1,简介说明  说明文字是否合理,位置 ,是否正确。

    2,背景/色调 是否正确、美观、,是否符合用户需求

    3,登录界面是否正常,能否正常登录

    4,能否正常选课和退选

    5,测试登录后能否正常退出

    6,页面元素的容错性列表

    7,页面元素清单(为实现功能、是否将所需要的元素全部都列出来,如按钮,单选框,复选框,列表框,超链框,输入框等等)。

    8,页面元素的容错性是否存在。

    ●负载测试

    通过增加并发用户数和(或)事务数量来测量组件或系统能够承受的负载。

    ●文档测试

    1、测试方案(主要设计怎么测试什么内容和采用什么样的方法,经过分析,在这里可以得到相应的测试用列表)

    2、测试执行策略(可以主要包括哪些可以先测试,哪些可以放在一起测试之类的)

    3、测试用例(主要根据测试用例列表,写出每一个用例的操作步骤和紧急程度,和预置结果)

    4BUG描述报告(主要可以包括,测试环境的介绍,预置条件,测试人员,问题重现的操作步骤和当时测试的现场信息)

    5、整个项目的测试报告(从设计和执行的角度上来对此项目测试情况的介绍,从分析中总结此次设计和执行做的好的地方和需要努力的地方和对此项目的一个质量评价)

    3.3测试准备

    1.测试计算机,是相对比较“干净”的。 因为测试都是有风险的,有的时候会导致蓝屏,计算机重新启动,优势时候则要求更换操作系统。

    2.功能测试环境 和 性能测试环境 要分开。 性能测试是持续的,有的用例要一次运行十几天,只有单独的性能测试环境才能满足这个要求。

    3.提前准备好软件和硬件。

    4.测试支持平台。 测试用例管理程序,bug管理程序,测试报告生成程序。

    5.把搭建测试环境时遇到的问题和相应的解决办法记录下来。

    3.4测试机构及人员

    测试机构人员组成:罗骁,曾理,曾正旗,施宏飞,聂良疆

    测试文档书写:施宏飞,聂良疆

    软件运行人员:罗骁,曾理

    软件完善人员:曾正旗

    4.测试项目说明

    4.1测试项目名称及测试内容

    测试项目名称

    测试内容

    登录功能

    用户能否正常输入用户名、密码和正常登录

    选课功能

    用户能否正常选课

    退课功能

    用户能否对已选课程进行退课

    查看功能

    用户能否查看已选课程和自己的选课之前和之后课表

    4.2测试用例

     

     

     

     

    测试用例编号

    Test_001

    测试项目

    用户注册

    测试标题

    输入空的注册账号

    重要级别

    预置条件

    进入系统

    输入

    1234(密码)

    操作步骤

    1.输入空的账号,2.输入密码1234

    预期输出

    系统提示注册学号和密码不能为空

     

    测试用例编号

    Test_002

    测试项目

    用户注册

    测试标题

    输入空的注册密码

    重要级别

    预置条件

    进入系统

    输入

    1234(账号)

    操作步骤

    1.输入注册账号12342..输入空的密码

    预期输出

    系统提示注册学号和密码不能为空

     

    测试用例编号

    Test_003

    测试项目

    用户注册

    测试标题

    输入注册账号和密码

    重要级别

    预置条件

    进入系统

    输入

    1234(账号),1234(密码)

    操作步骤

    1.输入账号12342.输入密码1234

    预期输出

    注册成功

     

    测试用例编号

    Test_004

    测试项目

    用户登录

    测试标题

    输入空的账号

    重要级别

    预置条件

    进入系统

    输入

    1234(密码)

    操作步骤

    1.输入空的账号,2.输入密码1234

    预期输出

    系统提示学号和密码不能为空

     

    测试用例编号

    Test_005

    测试项目

    用户登录

    测试标题

    输入空的密码

    重要级别

    预置条件

    进入系统

    输入

    1234(账号)

    操作步骤

    1.输入账号12342.输入空的密码

    预期输出

    系统提示学号和密码不能为空

     

    测试用例编号

    Test_006

    测试项目

    用户登录

    测试标题

    输入账号和密码

    重要级别

    预置条件

    进入系统

    输入

    1234(账号),1234(密码)

    操作步骤

    1.输入账号12342.输入密码1234

    预期输出

    进入主页面

     

    测试用例编号

    Test_007

    测试项目

    用户退出

    测试标题

    用户退出系统

    重要级别

    预置条件

    进入系统

    输入

     

    操作步骤

    点击退出按钮

    预期输出

    退出系统

     

    测试用例编号

    Test_008

    测试项目

    用户查看所有课程信息

    测试标题

    查看课程信息

    重要级别

    预置条件

    进入系统

    输入

     

    操作步骤

    点击查看课程按钮

    预期输出

    系统显示所有课程信息

     

    测试用例编号

    Test_009

    测试项目

    从所有课程界面返回主界面

    测试标题

    用户返回

    重要级别

    预置条件

    进入系统

    输入

     

    操作步骤

    点击返回按钮

    预期输出

    系统从课程信息界面返回主界面

     

    测试用例编号

    Test_010

    测试项目

    进入选课界面

    测试标题

    用户点击选课按钮

    重要级别

    预置条件

    进入系统

    输入

     

    操作步骤

    点击选课按钮

    预期输出

    系统进入选课界面

     

    测试用例编号

    Test_011

    测试项目

    用户输入正确的课程名

    测试标题

    用户选课

    重要级别

    预置条件

    进入系统

    输入

    123

    操作步骤

    1.用户输入正确的课程名,2.点击确定选课

    预期输出

    选课成功

     

    测试用例编号

    Test_012

    测试项目

    用户输入错误的课程名

    测试标题

    用户选课

    重要级别

    预置条件

    进入系统

    输入

    qqqqqqq

    操作步骤

    1.输入课程名qqqqqqq2.点击确定选课

    预期输出

    系统提示课程不存在

     

    测试用例编号

    Test013

    测试项目

    退选课程

    测试标题

    退选不存在的课程

    重要级别

    预置条件

    进入系统

    输入

    000

    操作步骤

    点击退课并输入课程号

    预期输出

    弹出对话框“不存在该课程号”

     

     

    测试用例编号

    Test014

    测试项目

    退选课程

    测试标题

    退选未选择课程

    重要级别

    预置条件

    进入系统

    输入

    125

    操作步骤

    点击退课并输入课程号

    预期输出

    弹出对话框“你未选择过该课程”

     

    测试用例编号

    Test015

    测试项目

    退选已经选的课程

    测试标题

    退选课程

    重要级别

    预置条件

    进入系统

    输入

    123

    操作步骤

    1.输入123,2.点击退课,3.点击确定

    预期输出

    系统提示成功退课

     

     

    测试用例编号

    Test016

    测试项目

    退出系统

    测试标题

    退出选课系统

    重要级别

    预置条件

    进入系统

    输入

    操作步骤

    点击退出

    预期输出

    弹出对话框“是否退出系统”,点击“是”会退出

     

    测试用例编号

    Test017

    测试项目

    退出系统

    测试标题

    退出选课系统

    重要级别

    预置条件

    进入系统

    输入

    操作步骤

    点击右上角的×

    预期输出

    直接退出系统

     

    测试用例编号

    Test018

    测试项目

    查询

    测试标题

    查询已选课程

    重要级别

    预置条件

    进入系统

    输入

    操作步骤

    点击查询

    预期输出

    显示已选择课程

     

    测试用例编号

    Test019

    测试项目

    点击退出按钮,用户退出系统

    测试标题

    退出系统

    重要级别

    预置条件

    进入系统

    输入

    操作步骤

    点击退出按钮

    预期输出

    用户退出系统

     

    4.3进度

    小组成员全体参与每个测试用例。

    4.4条件

    硬件条件:正常可运行电脑,键盘鼠标。

    软件条件:Eclipse软件和SQLserver软件。

    人员条件:全体小组成员。

    4.5测试资料

    [1]计算机软件测试文档编制规范GB/T 9386-2008.

    [2]窦万峰.软件工程方法与实践[M].北京:机械工业出版社,2009.

    5.评价

    5.1准则

    质量准则:错误率在1%左右,点击按钮系统反应时间不超过0.5秒。

    覆盖准则:用例覆盖度99%

    5.2结束标准

    各个用例预期结果和实际结果一致。

     

     

    集成测试文档

    1.简介

    1.1目的

    本文档用于描述辅助选课系统集成测试所要遵循的规范以及确定测试方法、测试环境、测试用例的编写和测试整个进度的计划安排、人力资源安排等。

    测试目的:集成测试目的是测试组成辅助选课系统的各个子模块间的接口及功能实现等。

    1.2背景

    面对当前大学生选课时遇到选课时间慢、选的课程不满意等问题,我们团队准备开发出一个辅助选课系统,以帮助学生更好地选课。

    1.3范围

    需要集成的模块为登录模块、选课模块、退课模块和查看模块。

    1.4参考文档

    [1]计算机软件测试文档编制规范GB/T 9386-2008.

    [2]窦万峰.软件工程方法与实践[M].北京:机械工业出版社,2009.

    2.测试约束

    2.1测试进出条件

    2.1.1进入条件

    程序能够成功运行并显示系统登录界面

    2.1.2退出条件

    致命和严重级别缺陷清除率达到100%,致命和严重级别缺陷修复率达到100%一般缺陷的遗留个数小于等于2个。

    2.2测试通过和失败准则

    输入测试用例后的结果与预期结果相近或者相同,测试即为成功,否则测试失败。

    2.3测试启动/结束/暂停/启动准则

    2.3.1测试启动准则

    程序运行成功能够输入测试用例。

    2.3.2测试结束准则

    对程序的各个功能都进行覆盖测试成功修复错误以后退出测试

    2.3.3测试暂停/再启动准则

    测试过程中出现致命、严重以及一般级别缺陷测试工作需要暂停,当修复致命、严重以及一般级别缺陷重新启动测试工作。

    3测试需求

    需求功能用户登录,选课,退课,显示功能

    接口硬件接口,以及人际交互接口。

    4测试风险

    不可抗力因素:及时保存程序的代码,做好文档的整理工作

    测试环境风险:弄清楚测试环境和生产环境配置,测试环境交叉影响较大,尽量增多测试环境数据量

    回归测试风险:回归测试一般时间相对来说较少应该尽量测试多的回归功能,防止漏测;另外还有减少回归验证缺陷时业务流走不通导致的打回修复再验证造成的时间延后问题。

    5.集成策略

    采用自下而上的集成顺序,先将个模块实现的功能进行测试,在集成对整体功能进行测试,集成环境为Eclipse开发环境。

    6.集成计划

    小组成员前期先将个模块的功能实现比测试,中后期将各个模块之间的关系整理,在集成环境下各个功能模块进行整合并测试最终的功能

    7测试策略

    7.1策略描述

    先对最底层的各个小功能测试然后逐层上升出现集成,直到实现最终的预期功能

    7.2测试类型

    功能测试:登录功能:预期结果:出现运行成功后输入用户名和密码,登录成功显示选课系统的菜单;用户名不存在显示用户名不存在请重新输入密码不正确显示密码不正确请重新输入“。

    测试结果与预期相符。

                选课功能:预期结果:登录成功后点击选课按钮,显示选课界面,在选择合适的课程后点击课程后面的选课按钮,选课成功显示选课成功;选课人数达到上限显示人数已到上限,请重新选择

                          测试结果:与预期相符。

                退课功能:预期结果:选课成功后点击退课按钮,显示退课界面,选择想要退掉的课程后点击课程后面的退课按钮,退课成功显示退课成功

                          测试结果:与预期相符。

                显示功能预期结果:登录成功后点击我的课程按钮显示该用户的所以课程。

    测试结果与预期相符

    接口测试硬件接口:键盘和鼠标点击是否有效果

                软件接口:

    ●容错测试:暂无

    ●回归测试:暂无

     

    转载于:https://www.cnblogs.com/hazujk1601rg/p/9242894.html

    展开全文
  • 软件测试文档

    万次阅读 2018-06-29 09:18:47
    1.引言 本部分介绍测试基本情况和要求,包括编写目的、项目背景和术语等。1.1 编写目的 为软件测试建立计划,供软件测试人员作为软件测试实施时的参考。1.2 项目背景 网络技术越来越发达,大学生网购的频率近年来...
    1.引言
    本部分介绍测试基本情况和要求,包括编写目的、项目背景和术语等。
    1.1 编写目的
    为软件测试建立计划,供软件测试人员作为软件测试实施时的参考。
    1.2 项目背景
    网络技术越来越发达,大学生网购的频率近年来急剧增加,购买的物品增加导致许多物品没用几次或者根本未使用就闲置,造成了极大的资源浪费,大四毕业生搬运行李时通常为一些专业书、辅导书感到可惜,当废纸卖掉太可惜,搬走很麻烦以后用到的可能也很小。于是开发人员希望开发出一款用于校内的跳蚤市场软件来解决这一问题,即通过校内跳蚤市场,帮助同学们将闲置的物品,如:用过的专业书籍、辅导书甚至衣服等等,进行二次利用,与有需要的同学通过该软件平台进行交易
    1.3 术语定义
    本文档所提及的术语,其定义遵照GB/T11457标准。
    1.4 参考资料
    《软件工程方法与实践》
    2 任务概述
    本部分描述测试的目标、测试环境、软件的基本需求,以及测试的条件和限制等。
    2.1 目标
    能够基本实现用户的登录注册,发布交易信息,修改交易信息,删除交易信息,查询交易信息等基本功能,并且实现用户之间通过应用程序的沟通和交易过程。
    2.2 测试环境
    硬件环境:略;
    软件环境:wampserver64、Chrome
    2.3 需求概述
    用户:注册、登录、退出登录、发布物品交易信息、修改物品交易信息、删除已发布但不在交易过程中的物品交易信息(不允许删除正在交易和已经交易完成的物品交易信息)、查看自己/其他用户发布的物品交易信息、拍下他人发布的物品、确认交易、查看个人主页、查看自己已经完成的交易信息、在物品交易信息下发布留言。
    2.3.1 数据需求
    包括系统所涉及的内部数据和外部数据要求,如外部存储格式、访问格式、以及内部数据结构和类型等。
    web端:1、服务器ip地址
    • 2、项目在服务器中的路径地址
    • 3、通过网页登录到项目的url地址
    Android端:Bmob项目的AppKey
    2.3.2 事务需求
    包括完成测试需要哪些事务要求,如每组测试的过程和处理要求、需要哪些工作等。
    android端:测试中有两个用户,能够实现需求概述中的所有功能
    web端: 1、保证服务器正常运行
    • 2、测试中有起码两个用户,能够实现需求概述中的所有功能
    2.4 条件与限制
    测试过程需要具备哪些条件,如各硬件设备、软件系统保证、人员齐备、各方面互相配合、内部协调等。限制包括资金限制、时间限制、环境限制等。
    Android端:Android4.0以上、Bmob数据库正常运行
    web端:服务器正常运行,其他无。
    3 计划
    本部分描述测试方案、测试的项目、测试前的准备工作和人员配备等。
    3.1 测试方案
    测试方案包括测试策略、测试过程、测试内容、要采用的测试技术,以及技术标准等
    3.1.2 测试过程
    • 张君怡和华楠模拟两个用户进行交易
    • 李元杰模拟用户进入个人界面
    • 李元杰、刘云杰、华楠模拟用户进行交易
    • 刘云杰测试注册并登陆
    3.1.3 测试内容
    • 用户的注册、登录、发布物品、修改物品、拍下物品、查看买到/卖出的物品
    • 用户个人界面正确显示,能修改用户名能修改密码,能进入我发布的、我买到的、我卖出 的界面查看个人交易信息。
    3.1.4 测试技术
    • 黑盒测试
    3.1.5 技术标准
    • 数据库里存入用户信息,以及交易完成的信息。
    • 各个页面中数据信息显示正确
    3.2 测试项目
    包括功能测试、回归测试、界面测试、负载测试和文档测试等项目。
    ·功能测试:
    测试目标
    确保功能测试需求项以及用例场景能够实现
    测试方法和技术
    利用浏览器和MySQL数据库测试功能用例。主要核实以下内容:
    1.使用有效数据时得到预期的结果。
    2.在使用无效数据时显示相应的错误消息或警告消息。
    完成标准
    所有测试用例都使用到,且系统中的功能全部都测试到
    需考虑的特殊事项
    ·回归测试:
    测试目标
    确保在测试过程中发现问题能够及时修正
    测试方法和技术
    设置多个用户输入正常数据和非法数据,观察系统是否出现预期结果
    完成标准
    所有测试用例都使用到,且系统中的功能全部都测试到
    需考虑的特殊事项
    ·界面测试:
    测试目标
    对照软件需求规格说明书中规定的界面规定,检查各个界面设计是否规
    范,包括:界面风格、色彩搭配、对齐方式等是否符合规范、是否协调
    一致、是否便于操作
    测试方法和技术
    小组成员模拟使用,并在使用后提出修改意见
    完成标准
    所有测试用例都使用到,且系统中的功能全部都测试到
    需考虑的特殊事项
    ·负载测试:
    测试目标
    使用大量数据考验软件,以确定达到限制时是否引发错误
    测试方法和技术
    web采用阿里云性能测试 PTS模拟真实流量数据进行测试
    完成标准
    在输入大量数据的情况下,依然无重大问题发生
    需考虑的特殊事项
    ·文档测试:
    测试目标
    对需求文档、设计文档进行测试,保证其内容的正确性、准确性
    测试方法和技术
    主要采取走查的方式
    完成标准
    需求文档和设计文档无重大缺陷,内容合理准确
    需考虑的特殊事项
    3.3 测试准备
    1.与各模块的主要负责人共同协商讨论;
    2.阅读软件规格说明书、概要设计说明书、详细设计说明书,并以此作为总的提纲;
    3.选择合适的输入/输出数据;
    4.编写测试用例。
    3.4 测试机构及人员
    测试机构的组建和人员组成、每个人员的职责和任务等。
    测试人员:华楠、张君怡、刘云杰、李元杰、何临峰
    人员职责:
    web端:
    • 华楠:编写测试用例、测试文档、根据测试用例在软件上进行模拟测试。
    • 张君怡:根据测试用例在软件上进行模拟测试。
    • Android端:
    • 李元杰:编写详细设计文档、在Android模拟器上对个人界面进行测试。
    • 刘云杰:
    • 何临峰:详细设计文档,在Android端进行物品详情页面测试
    4 测试项目说明
    本部分是测试项目的情况说明,包括测试项目定义,测试用例编写和操作步骤,测试进度安排以及参考资料等。
    4.1测试用例
    1.登录与注销
    测试用例编号
    01-1
    测试项目名称
    登录注销
    设计者
    华楠
    测试目标状态和
    测试数据状态
    达到预期要求
    测试类型
    web端
    序号
    测试项目
    输入说明(操作)
    输出说明(预期结果)
    1
    登录系统
    输入正确的用户名和密码
    显示弹窗“登录成功”,进入主页
      
    输入错误的用户名或密码
    显示弹窗“用户名或密码不正确”
      
    不输入用户名或密码
    显示弹窗“用户名或密码不能为空”
    2
    退出系统
    点击“退出登录”按钮
    回到登录界面

    测试用例编号
    01
    测试项目名称
    登录注册
    设计者
    刘云杰
    测试目标状态
    测试数据状态
    达到预期
    要求
    测试类型
    Android端
      
    序号
    测试项目
    输入说明(操作)
    输出说明(预期结果)
      
    1
    登录系统
    输入正确的用户名和密码
    显示“登录成功”,进入主页
      
     
     
    输入错误的用户名或密码
    显示“用户名或密码不正确”
      
     
     
    不输入用户名或密码
    显示“用户名或密码不能为空”
      
    2
    注册系统
    点击“注册”按钮
    进入注册界面
      

    2.注册

    测试用例编号
    02-1
    测试项目名称
    注册
    设计者
    华楠
    测试目标状态和
    测试数据状态
    达到预期要求
    测试类型
    web端
    序号
    测试项目
    输入说明(操作)
    输出说明(预期结果)
    1
    用户注册
    输入正确的用户信息
    显示弹窗“注册成功”跳转到登
    录界面
      
    漏填学号/密码
    显示弹窗“请输入用户名或
    密码”
      
    两次输入的密码不一致
    显示弹窗“两次输入的密码
    不一致”
      
    漏填用户名/性别/专业班级
    /学院
    显示弹窗“请输入用户名/性别
    /专业班级/学院”
      
    重复注册
    显示弹窗“用户已存在”

    测试用例编号
    02
    测试项目名称
    注册
    设计者
    刘云杰
    测试目标状态和
    测试数据状态
    达到预期要求
    测试类型
    Android端
    序号
    测试项目
    操作
    输出说明(预期结果)
    1
    用户注册
    输入正确信息
    显示弹窗“注册成功”,跳转登录界面
      
    两次密码不同
    显示“两侧密码不一致”


    3.对交易信息的操作(发布/修改/删除)
    测试用例编号
    03-1
    测试项目名称
    对交易信息的操作
    设计者
    华楠
    测试目标状态和
    测试数据状态
    达到预期要求
    测试类型
    web端
    序号
    测试项目
    输入说明(操作)
    输出说明(预期结果)
    1
    发布交易信息
    点击主页悬浮的“+”号,
    输入物品的正确信息
    显示弹窗“发布成功”
      
    未填写标题/内容/价格
    显示弹窗“标题/内容/价格不能
    为空”
    2
    修改交易信息
    点击修改按钮,修改已发布
    的内容
    显示弹窗 “修改成功”
    3
    删除交易信息
    点击删除按钮
    显示弹窗“删除成功”

    测试用例编号
    03
    测试项目名称
    对交易信息的操作
    设计者
    刘云杰
    测试目标状态和
    测试数据状态
    达到预期要求
    测试类型
    Android端
    序号
    测试项目
    操作
    预期结果
    1
    发布交易信息
    点击主页“发布按钮”输入
    物品信息
    弹出“发布成功”,跳转到主页面


    4. 查看(交易信息/个人信息/留言)
    测试用例编号
    04
    测试项目名称
    查看
    设计者
    华楠
    测试目标状态和
    测试数据状态
    达到预期要求
    序号
    测试项目
    输入说明(操作)
    输出说明(预期结果)
    1
    查看信息
    点击我发布的/我卖出的
    /我买到的/主页 按钮
    显示信息
    2
    查看留言
    点击查看留言按钮
    显示留言

    测试用例编号
    04
    测试项目名称
    个人信息界面
    设计者
    李元杰
    测试目标状态和测试数据状态
    达到预期要求
    测试类型
    Android端
    序号
    测试项目
    输入说明(操作)
    输出说明(预期效果)
    1
    查看交易信息
    点击/我发布的/我买到的
    /我卖出的按钮
    显示信息
    2
    修改用户名/密码
    点击设置按钮,输入相应
    信息,点击确认修改
    修改成功
    3
    从相应发布/买/卖界
    面进入商品详情页
    点击相应界面的商品
    进入商品详情

    5.拍下
    测试用例编号
    05
    测试项目名称
    拍下
    设计者
    华楠
    测试目标状态和
    测试数据状态
    达到预期要求
    测试类型
    web端
    序号
    测试项目
    输入说明(操作)
    输出说明(预期结果)
    1
    拍下
    点击拍下按钮(其他用户
    发布)
    显示弹窗“您已拍下该物品”
      
    点击拍下按钮(自己发布)
    显示弹窗“您不能拍下自己
    发布的物品”

    测试用例编号
    05
    测试项目名称
    拍下
    设计者
    何临峰、刘云杰
    测试目标状态和
    测试数据状态
    达到预期要求
    测试类型
    Android端
    序号
    测试项目
    操作
    预期结果
    1
    拍下
    点击详情中的“拍下”
    返回浏览界面

    6.确认交易
    测试用例编号
    06
    测试项目名称
    确认交易
    设计者
    华楠
    测试目标状态和
    测试数据状态
    达到预期要求
    测试类型
    web端
    序号
    测试项目
    输入说明(操作)
    输出说明(预期结果)
    1
    确认交易
    卖家点击确认交易(买家
    未点击)
    显示弹窗“请等待买家确认
    交易”
      
    卖家点击确认交易(买家
    已点击)
    显示弹窗“交易成功”
      
    买家点击确认交易(卖家
    未点击)
    显示弹窗“请等待卖家确认
    交易”
      
    买家点击确认交易(卖家
    已点击
    显示弹窗“交易成功”

    7.留言
    测试用例编号
    07
    测试项目名称
    留言
    设计者
    华楠
    测试目标状态和
    测试数据状态
    达到预期要求
    测试类型
    web端
    序号
    测试项目
    输入说明(操作)
    输出说明(预期结果)
    1
    发布留言
    点击添加留言,输入留
    言内容
    显示弹窗“发布成功”

    4.2测试步骤及操作
    Android端:
    • 首先进行登录:
    • 进入主界面:
    进入浏览:
    点击一个进入详情页面:
    点击拍下后,在浏览界面消失:





    • 进入个人界面:
    • 点击我发布的/我买到的/我卖出的按钮:
    • 点击设置按钮:
    • 点击确认修改:
    • 再次点击设置进行修改密码:
    • 点击确认修改:
    4.2.4 允许误差
    误差标准:不允许出现重大误差,若出现误差及时修改。

    5 评价
    给出测试评价准则和结束标准。
    5.1 准则
    包括质量准则,如错误率、效率、可靠性等,以及覆盖准则,如用例的覆盖度等。
    质量准则:
    错误率:10%以下
    可靠性较高
    可移植性较高
    覆盖准则:
    使用穷举测试即黑盒测试,用例覆盖率达到90%以上。
    5.2 结束标准
    以时间为结束基准,以资金为结束标准,还是错误率为基准等。
    当测试结果完全贴合需求时,测试结束。


    6 测试日志
    测试类型
    web端
    测试人员
    华楠
    序号
    测试项名称
    操作步骤及现象
    错误修改及原因简述
    回测
    1
    注册
    未填写性别/班级/学院仍
    然注册成功
    未添加后台相关判断项
    合格
    2
    登录
    登录失败显示的弹框为
    “用户名或密码错误”
    字段描述错误,修改为“学号
    或密码错误”
    合格
    3
    查看
    显示的中文字符为问号
    字符集不正确,修改为utf-8
    合格
    4
    查看
    未登录但是能进入用户
    主页和物品主页(通过
    顶栏)
    未添加登录状态判断,添加登
    录状态判断
    合格
    5
    拍下
    用户能拍下自己发布的
    物品
    未添加相关判断项,添加相关
    判断项并添加弹窗“您不能拍
    下自己发布的物品”
    合格

    测试类型
    Android端
    测试人员
    刘云杰、李元杰
    序号
    测试项目名称
    操作及现象
    错误修改及原因
    回测
    1
    注册
    信息填写完善后没有将性
    别存入数据库
    后台没有成功获取信息
    合格
    2
    发布
    正确填入信息后,没有将
    价格存入数据库
    后台将赋值单词拼错
    合格
    3
    拍下
    详情界面拍下后没有反应
    没有将逻辑与按钮绑定
    合格

    部分测试截图:
    1.注册
    未填写密码
    输出结果:
    正确输入注册信息:
    输出结果:
    重复注册:
    输出结果:
    2.登录
    输入不正确的密码
    输出结果:
    正常登录:(略)
    输出结果:
    ( 点击确定后进入主页)
    主页:
    查看详情:
    点击拍下(拍下自己发布的物品):
    输出结果:
    点击拍下(拍下别人发布的物品):
    输出结果:
    点击留言:
    点击查看留言:
    输出结果:
    买家确认交易(卖家未确认)
    输出结果:
    卖家确认交易(买家已确认)
    输出结果:
    点击“用户”进入用户主页
    输出结果:

    展开全文
  • 一份标准的软件测试计划文档 | 新手可以拿走

    万次阅读 多人点赞 2018-06-26 16:09:23
    简介1.1目的项目名称>的这一“测试计划”文档有助于实现以下目标:[确定现有项目的信息和应测试的软件构件。列出推荐的测试需求(高级需求)。推荐可采用的测试策略,并对这些策略加以说明。确定所需的资源,并对...

    测试计划

    修订历史记录

    版本       

    日期      

    AMD      

    修订者     

    说明     

    1.0

    XXXX年XX月XX









    (A-添加,M-修改,D-删除)

    1.简介

    1.1目的

    <项目名称>的这一“测试计划”文档有助于实现以下目标:

    [确定现有项目的信息和应测试的软件构件。

    列出推荐的测试需求(高级需求)。

    推荐可采用的测试策略,并对这些策略加以说明。

    确定所需的资源,并对测试的工作量进行估计。

    列出测试项目的可交付元素]

    1.2背景

    [对测试对象(构件、应用程序、系统等)及其目标进行简要说明。需要包括的信息有:主要的功能和性能、测试对象的构架以及项目的简史。]

    1.3范围

    [描述测试的各个阶段(例如,单元测试、集成测试或系统测试),并说明本计划所针对的测试类型(如功能测试或性能测试)。

    简要地列出测试对象中将接受测试或将不接受测试的那些性能和功能。

    如果在编写此文档的过程中做出的某些假设可能会影响测试设计、开发或实施,则列出所有这些假设。

    列出可能会影响测试设计、开发或实施的所有风险或意外事件。

    列出可能会影响测试设计、开发或实施的所有约束。]

    2. 测试参考文档和测试提交文档

    2.1测试参考文档

    下表列出了制定测试计划时所使用的文档,并标明了各文档的可用性:

    [注:可适当地删除或添加文档项。]

    文档

    (版本/日期)

    已创建或可用

    已被接收或已经过复审

    作者或来源

    备注

    可行性分析报告

    是□ 否□

    是□ 否□



    软件需求定义

    是□ 否□

    是□ 否□



    软件系统分析

    (STD,DFD,CFD,DD)

    是□ 否□

    是□ 否□



    软件概要设计

    是□ 否□

    是□ 否□



    软件详细设计

    是□ 否□

    是□ 否□



    软件测试需求

    是□ 否□

    是□ 否□



    硬件可行性分析报告

    是□ 否□

    是□ 否□



    硬件需求定义

    是□ 否□

    是□ 否□



    硬件概要设计

    是□ 否□

    是□ 否□



    硬件原理图设计

    是□ 否□

    是□ 否□



    硬件结构设计(包含PCB)

    是□ 否□

    是□ 否□



    FPGA设计

    是□ 否□

    是□ 否□



    硬件测试需求

    是□ 否□

    是□ 否□



    PCB设计

    是□ 否□

    是□ 否□



    USB驱动设计

    是□ 否□

    是□ 否□



    Tuner BSP 设计

    是□ 否□

    是□ 否□



    MCU设计

    是□ 否□

    是□ 否□



    模块开发手册

    是□ 否□

    是□ 否□



    测试时间表及人员安排

    是□ 否□

    是□ 否□



    测试计划

    是□ 否□

    是□ 否□



    测试方案

    是□ 否□

    是□ 否□



    测试报告

    是□ 否□

    是□ 否□



    测试分析报告

    是□ 否□

    是□ 否□



    用户操作手册

    是□ 否□

    是□ 否□



    安装指南

    是□ 否□

    是□ 否□



    2.2测试提交文档

    [下面应当列出在测试阶段结束后,所有可提交的文档]

    3.测试进度

    测试活动

    计划开始日期

    实际开始日期

    结束日期

    制定测试计划




    设计测试




    集成测试




    系统测试




    性能测试




    安装测试




    用户验收测试




    对测试进行评估




    产品发布




    4.测试资源

    4.1人力资源

    下表列出了在此项目的人员配备方面所作的各种假定。

    [注:可适当地删除或添加角色项。]

    角色

    所推荐的最少资源(所分配的专职角色数量)

    具体职责或注释













    4.2测试环境

    下表列出了测试的系统环境

    软件环境(相关软件、操作系统等)




    硬件环境(网络、设备等)




    4.3测试工具

    此项目将列出测试使用的工具:

    用途

    工具

    生产厂商/自产

    版本

















    5.系统风险、优先级

    [简要描述测试阶段的风险和处理的优先级]

    6.测试策略

    [测试策略提供了对测试对象进行测试的推荐方法。

    对于每种测试,都应提供测试说明,并解释其实施的原因。

    制定测试策略时所考虑的主要事项有:将要使用的技术以及判断测试何时完成的标准。

    下面列出了在进行每项测试时需考虑的事项,除此之外,测试还只应在安全的环境中使用已知的、有控制的数据库来执行。]

    注意:不实施某种测试,则应该用一句话加以说明,并陈述这样的理由。例如,“将不实施该测试。该测试本项目不适用”。

    6.1数据和数据库完整性测试

    [要<项目名称>中,数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时,不应将测试对象的用户界面用作数据的接口。对于数据库管理系统(DBMS),还需要进行深入的研究,以确定可以支持以下测试的工具和技术。]

    测试目标:

    [确保数据库访问方法和进程正常运行,数据不会遭到损坏]

    测试范围:


    技术:

    [调用各个数据库访问方法和进程,并在其中填充有效的和无效的数据(或对数据的请求)。

    检查数据库,确保数据已按预期的方式填充,并且所有的数据库事件已正常发生;或者检查所返回的数据,确保正当的理由检索到了正确的数据]

    开始标准:


    完成标准:

    [所有的数据库访问方法和进程都按照设计的方式运行,数据没有遭到损坏。]

    测试重点和优先级:


    需考虑的特殊事项:

    [测试可能需要DBMS开发环境或驱动程序在数据库中直接输入或修改数据。

    进程应该以手工方式调用。

    应使用小型或最小的数据库(记录的数量有限)来使所有无法接受的事件具有更大的可视度。]

    6.2接口测试

    测试目标

    确保接口调用的正确性

    测试范围:

    所有软件、硬件接口,记录输入输出数据

    技术:


    开始标准:


    完成标准:


    测试重点和优先级:


    需考虑的特殊事项:

    接口的限制条件

    6.3集成测试

    [集成测试―主要目的检测系统是否达到需求对业务流程及数据流的处理是否符合标准,检测系统对业务流处理是否存在逻辑不严谨及错误,检测需求是否存在不合理的标准及要求。此阶段测试基于功能完成的测试。]

    测试目标

    检测需求中业务流程,数据流的正确性

    测试范围:

    需求中明确的业务流程,或组合不同功能模块而形成一个大的功能。

    技术:

    [利用有效的和无效的数据来执行各个用例、用例流或功能,以核实以下内容:

    在使用有效数据时得到预期的结果。

    在使用无效数据时显示相应的错误消息或警告消息。

    各业务规则都得到了正确的应用。]

    开始标准:

    在完成某个集成测试时必须达到标准

    完成标准:

    [所计划的测试已全部执行。

    所发现的缺陷已全部解决。]

    测试重点和优先级:

    测试重点指在测试过程中需着重测试的地方,优先级可以根据需求及严重来定

    需考虑的特殊事项:

    [确定或说明那些将对功能测试的实施和执行造成影响的事项或因素(内部的或外部的)]

    6.4功能测试

    [对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。此类测试基于黑盒技术,该技术通过图形用户界面(GUI)与应用程序进行交互,并对交互的输出或结果进行分析,以此来核实应用程序及其内部进程。以下为各种应用程序列出了推荐使用的测试概要:]

    测试目标

    [确保测试的功能正常,其中包括导航,数据输入,处理和检索等功能。]

    测试范围:


    技术:

    [利用有效的和无效的数据来执行各个用例、用例流或功能,以核实以下内容:

    在使用有效数据时得到预期的结果。

    在使用无效数据时显示相应的错误消息或警告消息。

    各业务规则都得到了正确的应用。]

    开始标准:


    完成标准:


    测试重点和优先级:


    需考虑的特殊事项:

    [确定或说明那些将对功能测试的实施和执行造成影响的事项或因素(内部的或外部的)]

    6.5用户界面测试

    [用户界面(UI)测试用于核实用户与软件之间的交互。UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外,UI测试还可确保UI中的对象按照预期的方式运行,并符合公司或行业的标准。]

    测试目标

    [核实以下内容:

    通过测试进行的浏览可正确反映业务的功能和需求,这种浏览包括窗口与窗口之间、字段与字段之间的浏览,以及各种访问方法(Tab键、鼠标移动、和快捷键)的使用

    窗口的对象和特征(例如,菜单、大小、位置、状态和中心)都符合标准。]

    测试范围:


    技术:

    [为每个窗口创建或修改测试,以核实各个应用程序窗口和对象都可正确地进行浏览,并处于正常的对象状态。]

    开始标准:


    完成标准:

    [成功地核实出各个窗口都与基准版本保持一致,或符合可接受标准]

    测试重点和优先级:


    需考虑的特殊事项:

    [并不是所有定制或第三方对象的特征都可访问。]

    6.6性能评测

    [性能评测是一种性能测试,它对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。性能评测的目标是核实性能需求是否都已满足。实施和执行性能评测的目的是将测试对象的性能行为当作条件(例如工作量或硬件配置)的一种函数来进行评测和微调。

    注:以下所说的事务是指“逻辑业务事务”。这种事务被定义为将由系统的某个Actor通过使用测试对象来执行的特定用例,添加或修改给定的合同。]

    测试目标

    [核实所指定的事务或业务功能在以下情况下的性能行为:

    正常的预期工作量

    预期的最繁重工作量]

    测试范围:


    技术:

    [使用为功能或业务周期测试制定的测试过程。

    通过修改数据文件来增加事务数量,或通过修改脚本来增加每项事务的迭代数量。

    脚本应该在一台计算机上运行(最好是以单个用户、单个事务为基准),并在多个客户机(虚拟的或实际的客户机,请参见下面的“需要考虑的特殊事项”)上重复。]

    开始标准:


    完成标准:

    [单个事务或单个用户:在每个事务所预期时间范围内成功地完成测试脚本,没有发生任何故障。]

    [多个事务或多个用户:在可接受的时间范围内成功地完成测试脚本,没有发生任何故障。]

    测试重点和优先级:


    需考虑的特殊事项:

    [综合的性能测试还包括在服务器上添加后台工作量。

    可采用多种方法来执行此操作,其中包括:

    直接将“事务强行分配到”服务器上,这通常以“结构化语言”(SQL)调用的形式来实现。

    通过创建“虚拟的”用户负载来模拟许多个(通常为数百个)客户机。此负载可通过“远程终端仿真(Remote Terminal Emulation)工具来实现。此技术还可用于在网络中加载“流量”。

    使用多台实际客户机(每台客户机都运行测试脚本)在系统上添加负载。

    性能测试应该在专用的计算机上或在专用的机时内执行,以便实现完全的控制和精确的评测。

    性能测试所用的数据库应该是实际大小或相同缩放比例的数据库。]

    6.7负载测试

    [负载测试是一种性能测试。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。]

    [注:以下所说的事务是指“逻辑业务事务”。这各事务被定义为将由系统的某个最终用户通过使用应用程序来执行的特定功能,例如,添加或修改给定的合同。]

    测试目标

    [核实所指定的事务或商业理由在不同的工作量条件下的性能行为时间。]

    测试范围:


    技术:

    [使用为功能或业务周期测试制定的测试。

    通过修改数据文件来增加事务数量,或通过修改脚本来增加每项事务发生的次数。]

    开始标准:


    完成标准:

    [多个事务或多个用户:在可接受的时间范围内成功地完成测试,没有发生任何故障。]

    测试重点和优先级:


    需考虑的特殊事项:

    [负载测试应该在专用的计算机上或在专用的机时内执行,以便实现完全的控制和精确的评测。

    负载测试所用的数据库应该是实际大小或相同缩放比例的数据库。]

    6.8强度测试

    [强度测试是一种性能测试,实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。]

    [注:以下提到的事务都是指逻辑业务事务。]

    测试目标

    [核实测试对象能够在以下强度条件下正常运行,不会出现任何错误:

    服务器上几乎没有或根本没有可用的内存(RAM和DASD)

    连接或模拟了最大实际(实际允许)数量的客户机

    多个用户对相同的数据或帐户执行相同的事务

    最繁重的事务量或最差的事务组合(请参见上面的“性能测试”)。

    注:强度测试的目标可表述为确定和记录那些使系统无法继续正常运行的情况或条件。

    客户机的强度测试在“配置测试”的第3.1.11节中进行了说明。]

    测试范围:


    技术:

    [使用为性能评测或负载测试制定的测试。

    要对有限的资源进行测试,就应该在一台计算机上运行测试,而且应该减少或限制服务器上的RAM和DASD。

    对于其他强度测试,应该使用多台客户机来运行相同的测试或互补的测试,以产生最繁重的事务量或最差的事务组合。]

    开始标准:


    完成标准:

    [所计划的测试已全部执行,并且在达到或超出指定的系统限制时没有出现任何软件故障,或者导致系统出现故障条件的并不在指定的条件范围之内。]

    测试重点和优先级:


    需考虑的特殊事项:

    [如果要增加网络工作强度,可能会需要使用网络工具来给网络加载消息或信息包。

    应该暂时减少用于系统的DASD,以限制数据库可用空间的增长。

    使多个客户机对相同的记录或数据帐户同时进行的访问达到同步。]

    6.9容量测试

    [容量测试使测试对象处理大量的数据,以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如,如果测试对象正在为生成一份报表而处理一组数据库记录,那么容量测试就会使用一个大型的测试数据库。检验该软件是否正常运行并生成了正确的报表。]

    测试目标

    [核实测试对象在以下高容量条件下能否正常运行:

    连接或模拟了最大(实际或实际允许)数量的客户机,所有客户机在长时间内执行相同的、且情况(性能)最坏的业务功能。

    已达到最大的数据库大小(实际的或按比例缩放的),而且同时执行多个查询或报表事务。]

    测试范围:


    技术:

    [使用为性能评测或负载测试制定的测试。

    应该使用多台客户机来运行相同的测试或互补的测试,以便在长时间内产生最繁重的事务量或最差的事务组合(请参见上面的“强度测试”)

    创建最大的数据库大小(实际的、按比例缩放的、或填充了代表性数据的数据库),并使用多台客户机在长时间内同时运行查询和报表事务。]

    开始标准:


    完成标准:

    [所计划的测试已全部执行,而且达到或超出指定的系统限制时没有出现任何软件故障。]

    测试重点和优先级:


    需考虑的特殊事项:

    [对于上述的高容量条件,哪个时间段是可以接受的时间?]

    6.10安全性和访问控制测试

    [安全性和访问控制测试侧重于安全性的两个关键方面:

    应用程序级别的安全性,包括对数据或业务功能的访问。

    系统级别的安全性,包括对系统的登录或远程访问。

    应用程序级别的安全性可确保:在预期的安全性情况下,Actor只能访问特定的功能或用例,或者只能访问有限的数据。例如,可能会允许所有人输入数据,创建新帐户,但只有管理员才能删除这些数据或帐户。如果具有数据级别的安全性,测试就可确保“用户类型一”能够看到所有客户消息(包括财务数据),而“用户二”看见同一客户的统计数据。

    系统级别的安全性可确保只有具备系统访问权限的用户才能访问应用程序,而且只能通过相应的网关来访问。]

    测试目标

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

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

    测试范围:


    技术:

    应用程序级别的安全性:[确定并列出各用户类型及其被授权访问的功能或数据。]

    [为各用户类型创建测试,并通过创建各用户类型所特有的事务来核实其权限。]

    修改用户类型并为相同的用户重新运行测试。对于每种用户类型,确保正确地提供或拒绝了这些附加的功能或数据。

    系统级别的访问:[请参见以下的“需考虑的特殊事项”。]

    开始标准:


    完成标准:

    [各种已知的Actor类型都可访问相应的功能或数据,而且所有事务都按照预期的方式运行,并在先前的应用程序功能测试中运行了所有的事务。]

    测试重点和优先级:


    需考虑的特殊事项:

    [必须与相应的网络或系统管理员一直对系统访问权进行检查和讨论。由于此测试可能是网络管理可系统管理的职能,可能会不需要执行此测试。]

    6.11故障转移和恢复测试

    [故障转移和恢复测试可可确保测试对象能成功完成转移,并能从导致意外数据损失或数据完整性破坏的各种硬件、软件可网络故障中恢复。

    故障转移测试可确保:对于必须持续运行的系统,一旦发生故障,备用系统就将不失时机地“顶替”发生故障的系统,以避免丢失任何数据或事务。

    恢复测试是一种对抗性的测试过程。在这种测试中,将把应用程序或系统置于极端的条件下(或者是模拟的极端条件下),以产生故障(例如设备输入/输出(I/O)故障或无效的数据库指针和关键字)。然后调用恢复进程并监测和检查应用程序和系统,核实应用程序或系统和数据已得到了正确的恢复。]

    测试目标

    [确保恢复进程(手工或自动)将数据库、应用程序和系统正确地恢复到预期的已知状态。

    测试中将包括以下各种情况:

    客户机断电

    服务器断电

    通过网络服务器产生的通信中断

    DASD和/或DASD控制器被中断、断电或与DASD和/或DASD控制器的通信中断

    周期未完成(数据过滤进程被中断,数据同步进程被中断)。

    数据库指针或关键字无效

    数据库中的数据元素无效或遭到破坏]

    测试范围:


    技术:

    [应该使用为功能和业务周期测试创建的测试来创建一系列的事务。一旦达到预期的测试起点,就应该分别执行或模拟以下操作:

    ²客户机断电:关闭PC机的电源。

    ²服务器断电:模拟或启动服务器的断电过程。

    ²通过网络服务器产生的中断:模拟或启动网络的通信中断(实际断开通信线路的连接或关闭网络服务器或路由器的电源)。

    ²DASD和DASD控制器被中断、断电或与DASD和DASD控制器的通信中断:模拟与一个或多个DASD控制器或设备的通信,或实际取消这种通信。

    ²一旦实现了上述情况(或模拟情况),就应该执行其他事务。而且一旦达到第二个测试点状态,就应调用恢复过程。

    ²在测试不完整的周期时,所使用的技术与上述技术相同,只不过应异常终止或提前终止数据库进程本身。

    ²对以下情况的测试需要达到一个已知的数据库状态。当破坏若干个数据库字段、指针和关键字时,应该以手工方式在数据库中(通过数据库工具)直接进行。其他事务应该通过使用“应用程序功能测试”和“业务周期测试”中的测试来执行,并且应执行完整的周期。]

    开始标准:


    完成标准:

    [在所有上述情况中,应用程序、数据库和系统应该在恢复过程完成时立即返回到一个已知的预期状态。此状态包括仅限于已知损坏的字段、指针或关键字范围内的数据损坏,以及表明进程或事务因中断面未被完成的报表。]

    测试重点和优先级:


    需考虑的特殊事项:

    ²[恢复测试会给其他操作带来许多的麻烦。断开缆线连接的方法(模拟断电或通信中断)可能并不可取或不可行。所以,可能会需要采用其他方法,例如诊断性软件工具。

    ²需要系统(或计算机操作)、数据库和网络组中的资源。

    ²这些测试应该在工作时间之外或在一台独立的计算机上运行。]

    6.12配置测试

    [配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中,客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件 例如,应用程序、驱动程序等 而且在任何时候,都可能运行许多不同的软件组合,从而占用不同的资源。]

    测试目标

    [核实测试可在所需的硬件和软件配置中正常运行。]

    测试范围:


    技术:

    ²[使用功能测试脚本。

    ²在测试过程中或在测试开始之前,打开各种与非测试对象相关的软件(例如Microsoft应用程序:Excel和Word),然后将其关闭。

    ²执行所选的事务,以模拟Actor与测试对象软件和非测试对象软件之间的交互。

    ²重复上述步骤,尽量减少客户机工作站上的常规可用内存。]

    开始标准:


    完成标准:

    [对于测试对象软件和非测试对象软件的各种组合,所有事务都成功完成,没有出现任何故障。]

    测试重点和优先级:


    需考虑的特殊事项:

    ²[需要、可以使用并可以通过桌面访问哪种非测试对象软件?

    ²通常使用的是哪些应用程序?

    ²应用程序正在运行什么数据?例如,在Excel中打开的大型电子表格,或是在Word中打开的100页文档。

    ²作为此测试的一部分,应将整修系统、Netware、网络服务器、数据库等都记录下来。]

    6.13安装测试

    [安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下 例如,进行首次安装、升级、完整的或自定义的安装 都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。]

    测试目标

    核实在以下情况下,测试对象可正确地安装到各种所需的硬件配置中:

    ²首次安装。以前从未安装过<项目名称>的新计算机

    ²更新。以前安装过相同版本的<项目名称>的计算机

    ²更新。以前安装过<Project Name>的较早版本的计算机

    测试范围:


    技术:

    ²[手工开发脚本或开发自动脚本,以验证目标计算机的状况 首次安装<项目名称>从未安装过;<项目名称>安装过相同或较早的版本。

    ²启动或执行安装。

    ²使用预先确定的功能测试脚本子集来运行事务。]

    开始标准:


    完成标准:

    <项目名称>事务成功执行,没有出现任何故障。

    测试重点和优先级:


    需考虑的特殊事项:

    [应该选择<项目名称>的哪些事务才能准确地测试出<项目名称>应用程序已经成功安装,而且没有遗漏主要的软件构件?。]

    7.问题严重度描述

    问题严重度

    描述

    响应时间

    例如使系统崩溃

    程序员在多长时间内改正此问题











    8.附录:项目任务

    以下是一些与测试有关的任务:

    ²  制定测试计划

    n确定测试需求

    n评估风险

    n制定测试策略

    n确定测试资源

    n创建时间表

    n生成测试计划

    ²设计测试

    n准备工作量分析文档

    n确定并说明测试用例

    n确定测试过程,并建立测试过程的结构

    ²复审和评估测试覆盖

    ²实施测试

    n记录或通过编程创建测试脚本

    n确定设计与实施模型中的测试专用功能

    n建立外部数据集

    ²执行测试

    ²执行测试过程

    ²评估测试的执行情况

    ²恢复暂停的测试

    ²核实结果

    ²调查意外结果

    ²记录缺陷

    ²对测试进行评估

    ²评估测试用例覆盖

    ²评估代码覆盖

    ²分析缺陷

    ²确定是否达到了测试完成标准与成功标准

    如果需要这份原始文档,请在今日头条,头条号内,私信回复【05】即可。

    作者:西边人,现更名马蚁蛋
    程序爬虫获取国内外测试资源分享给自学爱好者
    公众号:软件测试资源站(ID:testpu)
    关注后回复测试资料,自动下发打包资料
    自学联盟爱好者QQ群:330374464头条号:请搜索(马蚁蛋)
    微信:mcfmcfmcf

    展开全文
  • 测试文档

    2020-10-18 22:26:48
    一、测试用例 1.1 登录模块 所在模块 用户登录 序号 功能名称 输入 操作 预期结果 实际结果 1 登陆界面显示 界面显示label:登录; 输入框:账号输入框、密码输入框; 按钮:【登录】 正确 2 管理...
  • 软件测试相关文档

    2020-07-28 23:32:34
    测试用例、测试计划、测试报告等相关文档,不仅有模版,还有实际项目文档
  • 怎么才能做好文档测试

    千次阅读 2018-09-29 21:45:54
    做好文档测试需要注意的点有哪些?简单粗暴的以下几点内容,摘自腾讯面试题! 1、仔细阅读,跟随每个步骤,检查每个图形,尝试每个示例 2、检查文档的编写是否满足文档编写的目的 3、内容是否齐全,正确,完善 ...
  • 如何写测试案例

    千次阅读 2012-11-01 13:41:40
    测试文档主要包括:  1.测试计划  2.测试用例  3.测试记录报告  4.测试问题报告  5.测试评估报告  一、测试计划  1.引言 1  1.1编写目的 1  1.2项目背景 2  1.3定义 2  1.4参考资料 2  ...
  • 测试文档系列--测试报告

    千次阅读 2008-03-06 08:16:00
    测试文档系列--测试报告这个大家可能都需要,这里将会提供多种格式的测试报告模版给大家参考,大家也可以上传自己的模版,不过最好先看一下是否已经有人发过了,而且注明一下,这个测试模版是软件领域的还是硬件领域...
  • 文档测试

    千次阅读 2009-12-05 00:07:00
    软件测试在越来越受到大家关注和重视后,对软件测试的认识也由原来的功能测试、性能测试、安全测试、黑盒测试、白盒测试等大家所熟悉的概念扩展到了对文档测试、配置测试等等方面上,如大家所知,软件需求阶段所产生...
  • 用rand() 快速生成测试文档

    千次阅读 2018-04-13 17:45:28
    快速生成测试文档=rand()+回车键
  • 使用Postman,生成接口测试文档

    万次阅读 2018-04-03 14:27:20
    1、点击【view in web】2、自动打开浏览器,如图所示3、点击【publish】,如图所示,接着点击【publish】,会生成一个 public URL,这个链接就是生成的文档,所有人都可以查看...
  • 测试管理之--文档管理

    千次阅读 2018-05-05 17:46:13
    测试文档是整个测试中的重要输出;测试文档同时也贯穿测试活动的始末;在测试计划、测试设计、测试执行、测试验收等过程中会产生各种各样的文档。测试文档的最终目的是为了更有效的测试及保存测试组织资产。我们在...
  • 【软件测试基础】文档测试

    千次阅读 2018-12-18 17:56:49
    完整性:主要测试文档内容是否齐全,有没有内容的遗漏 正确性:文档的编写有没有错误,除了内容之外,还包括文档的格式、语法、拼写,这是我们 测试的时候应该检查的。 一致性:文档中相同部分的内容,前后是否...
  • 接口测试(详细文档

    万次阅读 多人点赞 2018-07-12 09:56:39
    接口测试接口测试常用工具:postman,jmeter (现在主流的两个测试接口工具)接口分类 :把接口分为两类:程序接口和协议接口。1.程序接口,也可以看作是程序模块接口,具体到程序中一般就是提供了输入输出的类、...
  • 测试文档是测试过程中输出的测试工作产品,类似于软件工作产品。然而实践中经常面临有很多的测试文档需要撰写,而使用文档的效果却是非常有限。本文阐述了测试文档深度与广度选择需要考虑的一些因素。 [正文] 测试...
  • 跪求软件测试标准文档模板。。。。如有关于数据库方面的测试最好
  • 接口测试常用文档模板介绍

    千次阅读 2018-10-16 15:01:20
    目录 1. 查询指定项目属性接口 1. 查询指定项目属性 接口功能 获取制定项目的分类信息 URL http://www.api.com/index.php 支持格式 JSON HTTP请求方式 GET 请求参数 参数 ... ...
  • 接口测试提测--接口文档规范

    万次阅读 2016-07-03 21:02:14
    接口测试的依据,往往不是需求文档,而是接口文档。 那么,接口文档的准确性便至关重要,本文推荐两种形式的接口文档,供大家参考。 接口文档不管以什么形式存在,需要包含的内容有: 接口名称接口类型输入...
1 2 3 4 5 ... 20
收藏数 985,384
精华内容 394,153
关键字:

测试文档