软件测试指导手册张宝良为了提高测试效率，保证产品测试质量，从而保证产品开发工期与质量，统一测试思想是十分必要的。

本文就用友软件测试相关内容进行阐述，力求给大家启示与参考。

第一章测试概念第一节测试要点测试要点是依据等价类方法（或其他方法），经过对被测试内容进行分析后，以清单方式进行描述要测试的内容。

注意事项：1.针对任何一个被测试内容，均要考虑是否涉及系统提供的公用功能。

2.测试要点尽可能穷举，避免遗漏。

3.测试要点给出代码实现正确实现是什么，什么样实现是错误的。

4.测试要点是针对最小功能单元，可以是一个功能结点，也可以是一个操作按钮，但不允许多个内容一起描述举例：U8产品XXX产品测试要点第二节测试用例测试用例是指数据测试用例，针对测试要点，必须以数据形式才可描述清楚，作为测试要点的补充。

测试要点不一定必须有测试数据用例，但测试数据用例必须对应有测试要点。

注意事项：1.测试用例一般会涉及多个功能配合。

2.描述中要体现操作次序3.数据准备考虑以下情况●小数●外币●表体一条记录●表体满记录●表体满记录多一条4.数据准备不要太复杂，要便于操作。

如果复杂可拆开描述。

第二章测试策略测试策略：针对某项具体任务，安排最合适的人选，采用最佳的测试方法，在规定的时间内，保质保量完成。

策略要点（1）在测试策略中，人员能力的培养是最重要的，是完成任务的关键。

（2）针对被测试对象的不同，测试策略应有差异。

（3）测试计划是保证被测试对象完全测试的关键，同时也是提高测试人员工作效率的关键。

（4）被测试对象在分解任务时要有主次之分（5）测试资源安排时要有主次之分（6）测试进度安排要有主次之分（7）合理设计各测试阶段测试内容，充分体现早期测试思想，及早稳定产品。

（8）最大限度地提高测试经理的作用（任务安排、测试设计、问题分析、产品把握）（9）建立监督、检查机制。

每个阶段都要有报告产生，对报告要进行详细分析，以便掌握进度和质量。

（10）向过程要效益，过程不同效益不同。

任务计划任务计划分两类：测试经理使用的“阶段任务计划”，测试人员使用的“每日任务计划”XXX测试组阶段任务计划理反馈XXX测试员每日任务计划该计划根据阶段测试任务制定，由测试经理编写，测试人员执行。

切不可以由测试人员编写，理由是缺乏全面考虑，尤其是测试覆盖度方面。

测试人员每日向测试经理反馈。

工作内容分类以是否改动可以分为改动部分和非改动部分。

以是否是重点可以分为重点内容和非重点内容。

次序（1）改动部分（30%资源）（2）重点部分（40%资源）（3）非改动部分（10%资源）（4）全面测试（20%资源）内容（1）测试人员与各开发角色充分沟通（2）编写、评审、执行测试要点及测试用例（3）每日测试问题分析（原因、影响、补充测试要点）测试资源目前测试资源主要有三种：正式员工、外包测试人员、实习生；针对每个版本重点的不同在资源配备上要合理安排。

1．资源分析（1）正式人员正式员工是公司测试的核心力量。

他们是经过严格筛选的，大部分都具有实际工作经验，工作心态比较稳定，为此在分配任务时，核心产品、核心内容要由他们来负责。

（2）外包测试人员外包测试人员是公司测试的辅助力量，他们也是经过严格筛选的，大部分也都具有实际工作经验，但在专业知识方面没有正式员工那样严格。

他们的工作心态相对稳定，归属感差一些。

但是合理使用，同样会达到正式员工的效果，甚至会比个别正式员还好。

为此在分配工作任务时，择优考虑。

（3）实习生实习生是公司测试的边缘力量，他们来公司的主要目的是学习软件产品测试知识，相关业务知识，为自己择业增加筹码。

录用他们时主要考察他们的专业知识与综合素质，在分配工作任务时，产品的边缘测试任务一般由他们来完成，表现优异者可以考虑接触一些核心内容。

2．资源培养培养测试人员的手段有很多，比如：产品知识培训、测试方法培训、测试技巧培训等。

这些都是传统的方法。

一个测试人员由不合到合格需要很长的时间。

建立业务员能力提升系统，可以缩短培养时间，这一系统即包括业务知识，又包括测试理论。

3．指导思想在软件产品测试过程中，所有测试人员都要树立正确的工作观念，任何消极的工作态度都会影响自己的未来发展，所以，必须明白当前的工作是在为自己工作，为自己的未来工作。

为此，测试经理除了安排测试任务外，沟通工作是重点。

沟通包括各环节、各角色的工作内容沟通；下属员工思想沟通，随时关注每个人的思想动态，及时调整，确保每个员工全身心的进行测试工作。

测试误区1．测试人员只要了解业务知识就可以了，开发知识不需要了解。

2．测试工作很简单，任何人都可以做，没什么技术可言3．我只为找产品错误，其他不管4．测试是给程序员打下手的5．测试人员与程序员的关系是对立的6．我是程序员，测试不是我的事7．测试很苦，很枯燥8．测试很难有成就感，开发还可以说哪个功能是我开发的。

9．测试工作不受重视第三章测试方法最常规测试分黑盒测试与白盒测试，针对管理软件而言，目前主要集中应用的是黑盒测试。

黑盒测试顾名思义就是将被测系统看成一个黑盒，从外界取得输入，然后再输出。

整个测试基于需求文档、测试文档、产品帮助、支持问题，看是否能满足文档中的所有要求。

黑盒测试要求测试者在测试时不能使用与被测系统内部结构相关的知识或经验，它适用于对系统的功能进行测试。

黑盒测试的优点有：1）比较简单，不需要了解程序内部的代码及实现2）与软件的内部实现无关3）从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题；4）基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；5）在做软件自动化测试时较为方便。

黑盒测试的缺点有：1)不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%；2)自动化测试的复用性较低。

此处暂不讨论白盒测试第一节功能验证法（点测试法）依据产品功能清单，详细分析理解具体的功能描述，检查产品实现是否正确。

1）参考产品随机帮助2）参考需求文档3）参考测试要点4）参考测试用例注意事项1）考虑逆向操作2）考虑极限情况3）考虑界面规范4）考虑提示语规范5）利用等价类方法设计数据测试范围6）如果没有以上测试依据，必须编写测试要点，也就是所有测试必须提前编写或想好测试点再测试举例：测试凭证审核1.单张审核2.成批审核3.按凭证类别过滤审核凭证4.按月份和凭证号范围过滤审核凭证5.按日期范围过滤审核凭证6.选择全部凭证审核7.查看所有作废凭证8.查看所有有错凭证9.按外部系统过滤凭证审核10.按制单人、审核人、主管签字过滤凭证审核11.联查明细账•不能联查现金、银行科目•只有有此科目查询权限的操作员才可查询12.审核人和制单人不能是同一个人13.若想对已审核的凭证取消审核，单击〖取消〗取消审核。

取消审核签字只能由审核人自己进行。

14.凭证一经审核，就不能被修改、删除，只有被取消审核签字后才可以进行修改或删除。

15.审核人除了要具有审核权外，还需要有对待审核凭证制单人所制凭证的审核权，这个权限在"基础设置"的"数据权限"中设置。

16.采用手工制单的用户，在凭单上审核完后还须对录入机器中的凭证进行审核。

17.作废凭证不能被审核，也不能被标错。

18.已标错的凭证不能被审核，若想审核，需先按〖取消〗取消标错后才能审核。

已审核的凭证不能标错。

19.预算审批通过的凭证，只能进行审核，不能进行凭证其它操作。

20.取消审核时，无论预算管理系统返回何值全部认为成功，系统只提示不进行控制。

21.企业可以依据实际需要加入审核后方可执行领导签字的控制，同时取消审核时控制领导尚未签字。

可在"选项"中选中"主管签字以后不可以取消审核和出纳签字第二节流程测试法（线测试法）依据产品功能相互之间的依存关系，以列表形式描述出功能的操作次序，主要检查功能节点之间的耦合情况。

注意事项：1）测试逆向操作2）测试传输字段之间的数据类型、字段宽度的一致性3）在测试之前要将所测试内容以清单形式进行列示，以便检查。

举例：银行对账流程流程11．银行会计科目指定2．结算方式设定3．部门、职员准备4．支票登记5．录入银行会计科目凭证6．银行科目凭证签字7．查询银行日记账（包含未记账凭证）流程21．银行会计科目指定2．结算方式设定3．部门、职员准备4．支票登记5．录入银行会计科目凭证6．银行科目凭证签字7．银行科目凭证审核8．银行科目凭证记账9．查询银行日记账（不包含未记账凭证）10．期初对账情况录入●单位日记账情况●银行对账单情况11．本期银行对账单处理a)导入本期银行对账单b)录入本期银行对账单12．银行对账13．查询以下内容●长期未达账项●对账勾对情况●银行存款余额调节表14．核销已达账项第三节项目测试法（面测试法）对被测试项目，检查系统提供的公用功能进行测试。

比如功能权限、数据权限、并发测试、互斥测试、预警、审批流、单据格式、单据编号、自定义项、UFO函数等注意事项：1.对任何一个产品而言，凡是涉及到得测试项目必须全面测试。

2.注意平台公共部分改动对本产品的影响3.针对每一个测试项目都要有对应的测试方案举例：单据编号测试方案●完全手工编号测试：测试特殊字符、极限、重号、单据查询中录入手工编号●手工改动，重号时自动重取：测试前缀（测试要穷举）、规则、重号、单据查询中录入●所有单据均要测到●编号设置测试方案●对照表测试方案●流水号测试方案在以上三个测试方案中要体现以下内容：1.特殊字符2.编号极限长度3.重号4.前缀各种组合5.前缀与规则各种组合6.日期情况下考虑特殊日期、闰年、闰月7.单据修改保存后编号不能改变应收款管理第四节参考测试法参考测试就是依据已经发生的测试活动结果，作为当前测试的依据。

以此发现新的产品问题，一方面能过拓展测试思路，另外也可以检查当前产品问题是否还存在。

有三种情况可以作为测试依据，它们是：（1）支持问题支持问题反映的是当前产品在不同版本中遗留的问题，检查当前版本是否还存在。

因为同一产品进过多人开发和测试，每个人的开发思路与测试思路存在很大差异，同时对不同客户的使用也存在很大差异，完全测试全面，几乎是不可能的事情。

作为测试工作，只能最大限度地降低产品问题。

所以认真分析支持问题，并积累分类问题是完全必要的。

在支持问题分析上，重点分析用户的应用场景，能够分析出客户的使用规律。

（2）他人测试记录分析他人测试记录，主要分析他人的测试思路，尤其是数据错误和控制错误。

因为每个人的测试结果都是该人对产品的理解深度的体现，产品理解越深。

（3）自己以前测试记录分析自己测试的问题，检查测试的不足，看一下还有哪些没有测试到。

看一下自己的是问题的种类，是否还只停留在表面问题上。

第五节高危模块测试法任何一个软件产品，影响它的质量因素有很多，其中最重要的是程序员能力。