软件测试规范.doc

软件测试规范试行版 受控文件名称：软件测试规范试行版文件编号：作者： 别致版本：V1.0修订日期：审 批 人： 生效日期：审批日期：更新记录版本编制/修改人修改日期修改对象备注（原因、进一步的说明等） 目 录1概述31.1文档目的31.2主要内容31.3术语32软件测试工作参与角色33测试类型和范围44测试方法54.1功能测试和联合测试54.2性能测试和稳定性测试64.2.1性能测试64.2.2稳定性测试65缺陷管理机制76测试流程87发布要求91 概述1.1 文档目的本文档旨在制定天大天科软件的测试规范，以指导软件测试工作有效率、高质量的完成。1.2 主要内容本文档主要包括如下内容：1. 软件测试工作的参与角色；a) 描述天大天科的软件测试工作中参与的角色有哪些，每个角色的工作内容是什么；2. 测试类型和范围a) 软件测试工作包括哪些类型的测试，每一种的目的和意义；3. 测试方法a) 说明每一种测试类型的测试方法，以及常用的工具软件；4. 缺陷管理机制a) 说明“缺陷”如何管理和跟踪；5. 软件测试流程a) 描述一个软件从提交测试到完成测试的流程；1.3 术语1. TD全称Mercury TestDirector，一种测试管理工具。2. 黑盒测试：黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。2 软件测试工作参与角色软件测试工作中涉及的如下“角色”，这些角色在实际工作中可以是1个人身兼多个角色：1. 测试负责人；2. 测试工程师；3. 研发负责人；4. 研发工程师；5. 项目经理；6. 研发部门经理；7. 技术中心相关人员；每个角色的工作内容为：1. 测试负责人；a) 软件测试工作的负责人，通常在软件测试开始前指定，通常为对软件熟悉的测试骨干；b) 主持测试方案的设计和评审，对测试方案、用例的质量负首要责任；c) 带领测试工程师按期保质完成软件测试工作；d) 主持测试轮次评审会议；2. 测试工程师；a) 按照测试方案完成软件测试工作，参与必要的设计和评审会议；3. 研发负责人；a) 被测试软件的研发负责人，在软件测试过程中，带领研发工程师对缺陷进行修正；b) 参与测试方案的设计和评审，对测试方案、用例的质量负责（次于测试负责人）；c) 参与轮次测试总结工作；4. 研发工程师；a) 被测试软件的研发工程师，对缺陷进行修正，参与必要的设计和评审会议；5. 项目经理；a) 被测试软件的项目经理，通常参与负责软件的测试方案之设计和评审，以及轮次测试总结等工作；6. 研发部门经理；a) 被测试软件的软件部门经理，通常参与本部门软件测试方案的设计和评审，以及轮次测试总结等工作；7. 技术中心相关人员；a) 通常情况下，如果某个软件版本研发的主要目的是针对某个项目，而这个项目对应的项目经理或解决方案经理应当被邀请参加该软件测试方案的评审；3 测试类型和范围软件测试工作通常分为4个类型，这4个类型的测试工作也是一个软件发布前通常都要做的，它们是：1. 功能测试；2. 软件联合测试；3. 性能测试；4. 稳定性测试；每种类型测试的意义：1. 功能测试；a) 确保功能符合需求定义；b) 确保所有功能可以正常完成工作；2. 软件联合测试；a) 一个新软件或一个软件的新版本发布时，要确保与之向配合的软件可以正常配合使用；（此项属于当前薄弱环节，需要加强）3. 性能测试；a) 在软件有性能要求的部分，进行性能测试和调优，确保软件性能符合需求；4. 稳定性测试；a) 模拟用户真正的使用情况，设计相应的测试用例，确保软件可以稳定可靠的长时间运行；（此项属于当前薄弱环节，需要加强）4 测试方法4.1 功能测试和联合测试1. 以手工黑盒测试为主手工执行功能测试用例。2. 正规测试和随机测试相结合根据需求文档撰写测试方案及测试用例来进行常规测试，考虑到测试用例有可能写的不全面，所以在进行常规测试过程中，可以加入随机测试。同时，对预测试出来的缺陷，将其执行过程写成一个测试用例，添加到测试用例集合中，以完善测试用例。3. 采用测试工具进行测试管理采用TD进行测试用例的管理和缺陷记录、跟踪。4. 黑盒测试过程的参考准则：n 必须采用边界值分析法。n 必要时采用等价类划分法补充测试用例。n 采用错误判断法，追加测试用例；n 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当补充更多的测试用例；n 测试数据应准备充分，应采用有效数据、无效数据、边界数据分别测试验证；n 如果程序的功能说明中含有输入条件的组合情况，则应考虑使用因果图法或者决策表法。关于“软件联合测试”的特别说明：软件联合测试要求每个软件“发布”前，必须进行相关软件的联合测试。“相关软件”的确定原则是在市场上存在交互关系的相互配合使用的软件。在目前天大天科的测试工作中，功能测试做的相对完善些，软件联合测试是以前做的比较弱的，当前需要重点加强。4.2 性能测试和稳定性测试4.2.1 性能测试性能测试要求满足两种情况：1. 为了达到宣传目的软件在特定工况下可以达到的最高性能（例如：测试时将日志等影响性能的选项关闭）；2. 为了了解软件真实性能模拟用户真正的使用环境（如：日志功能打开，在一定的用户数量的情况下），软件真实可以达到的性能；（此项属于当前薄弱环节，需要加强）4.2.2 稳定性测试稳定性测试要求模拟用户真正的使用情况，设计相应的测试用例，确保软件可以稳定可靠的长时间运行；（此项属于当前薄弱环节，需要加强）稳定性测试时经常容易出现的问题是对用户真正使用情况分析不够，采取的测试用例不能模拟用户真实环境，例如：1. 稳定性测试时，测试人员有时简单的认为只要把性能测试用例长时间运行就可以了；（性能测试用例通常只关注某几项指标，而稳定性测试用例关注的指标要更全面，更能给模拟用户真实情况）；2. 软件提供很多种服务，在稳定性测试时，仅测试其中比较的1-2种；例如：物供可能只关注了入库功能的稳定性，而忽视了查询功能稳定性；3. 稳定性测试时，数据库中的各种数据远小于用户实际场景中的数据；（实际场景数据库中可能是2000用户，实际作测试时可能只有50，这就不能模拟实际环境）；性能测试和稳定性测试主要使用的测试工具是LoadRunner，用于进行两种类型的测试： 1. 非界面功能的稳定性测试a) 这类功能主要以服务端口的形式对外提供，例如：服务端口，网关的业务服务端口，签名服务器的对外服务端口等，这个端口提供的服务在软件正常运行时将承担比较大的访问压力。b) 对于所有服务端口，模拟非法数据进行压力测试，在非法数据的压力下，服务不会崩溃，能够进行正常业务数据处理。例如：服务器开启调试模式，人为的telnet调试端口或者有防火墙频繁扫描调试端口等，服务会僵死。2. 界面功能稳定性测试（管理员频繁使用的界面功能）a) 可以用户模拟软件用户实际频繁使用软件界面上的各种功能；就是用户需要频繁通过操作UI界面来使用的软件（网关则不是这样的软件，网关在正常运行时主要通过业务服务端口，用户很少使用网关UI界面），对于这样的软件，应当对UI界面上提供各类频繁使用功能进行长时间、高并发的测试，模拟实际的使用场景。通过这个测试用以验证，软件在实际使用中是否可以稳定运行。特别说明：通过LoadRunner进行稳定性测试应当满足下列要求：1. 通过LoadRunner应当模拟多种业务访问情况，不能只模拟其中一种，这样将不能确保软件稳定性。2. 软件应当可以长时间、高并发下运行稳定，此时软件的响应速度会减慢，但必须能够稳定运行，否则软件稳定性则不过关，需要进一步查找原因，并优化软件。3. 在LoadRunner压力消失后，应该能够恢复正常响应速度。5 缺陷管理机制缺陷通过测试管理工具TD/QC/JIRA进行管理。6 测试流程软件测试流程如下，对于流程中的具体参与人和评审人见软件开发流程中对于不同类型软件开发的规定。说明：上图中绿色字体代表测试过程中需要完成的各种文档；