怎样让测试更全面

怎样让测试更全面付文龙软件测试的现状软件产业发展到今天，如果还是用以前的思路、办法（公司里绝大部分、甚至全部都是开发人员在做产品，只要能做出来可以用就行），企业的产品肯定没有竞争力，从而导致这样的软件企业生存极其困难。正是因为这个原因，以前软件测试以往一直被中小IT企业所忽视，只有一些知名企业才有门的软件测试人员。现在，更多的国内企业认识到测试的重要性，设立了软件测试部门，配备了专业的软件测试人员。既然我们有了测试部门，有了专职的测试人员，按理来说就不会再有质量问题存在了，但客户还是反馈有或多或少的问题存在。那么这是为什么呢？我们应该从哪些方面来防止这些问题呢？

漏测的定义所谓漏测，是指软件产品的缺陷没有被测试组发现而遗漏到了用户那里，最终被用户所发现。进行漏测分析的目的是为了促进软件质量和开发测试过程得到持续改进。具体来讲，就是通过分析开发和测试过程中漏测的缺陷，制定相应的预防措施以避免今后再发生类似的漏测。测试过程的持续改进将提高测试环境的效果和测试执行的效率、降低遗留到用户处的缺陷数和缺陷解决成本，从而提升软件的质量、声誉和销售。在软件产品开发过程中重视漏测分析并参与到漏测分析工作中的团队越多，漏测分析的效果就越好。如果开发和测试团队都重视漏测分析、并密切配合进行漏测分析工作的话，漏测分析将取得非常好的效果。·需求评审·梳理需求·用例设计与评审·测试执行·Bug回归·发布前的功能回归需求评审

参加需求评审会，理解需求文档，在编码前找出需求的bug，与客户以及研发在需求的理解上达成一致的观念。但是也可能存在以下的问题：没有需求文档？客户对需要的产品目标不明确，研发人员也不明确，这个时候，只能使用敏捷开发，把产品开发出来之后，先给用户使用，然后再根据用户提示的问题进行修改，这样的bug都比较难确定；需求总是不能固定？不固定需求就会引出问题，然后引出一系列的bug；需求已经定义，是否吻合客户实际应用？

那么，这就需要我们在理解完需求之后，找负责人进行确认，并通知项目的参与人员，进行一个有效的需求评审会议。是大家对需求都达到一致的认识。日前一名张姓民众到

南京市秦淮区的超市购买一款牛肉松营养面包，但仔细阅读产品成分后，赫然发现小小一块面包，成分竟高达20多种，但里面居然没有牛肉相关成分。他愤而检举，认为店家故意欺骗消费者，痛斥“太不厚道了！”面对张先生的质疑，食品业者回应：“我们的意思是，这是很牛的肉松面包，而不是牛肉松面包”。业者表示，这个牛并非吃的牛，而是一种语气词，所以在包装袋上宣传并未不妥。而该公司的员工也认为，食品名称与成分其实没有相对等的关系，“红牛（redbull）里面有牛吗？”需求评审软件需求是开发工作和测试工作在制定计划、开展工作时所共同参照的源头和依据，而我们只有在源头上控制好，才能保证下面工作的平稳开展要保证软件需求的可测试性。对于“可测试性”，就是要保证所有的需要实现的需求都是可以用某种方法来明确的判断是否符合需求文档中的描述既要熟悉需求人员的工作，又要熟悉软件所涉及的行业的业务。需要对软件产品所涉及的行业的业务有一个全面的、深入的了解及时检测出软件需求文档中具有不可测试性的需求点。（某功能模块输入可见，输出不可见，无法验证模块功能是否正确；或是该功能模块的输出无参考标准来衡定）。及时发现软件需求文档的不完整性，从而提醒需求分析人员弥补描述。需求分析实例

题目：输入三个数a、b、c分别作为三边的边长构成三角形。通过程序判定所构成的三角形是一般三角形、等腰三角形还是等边三角形时。用等价类划分方法为该程序设计测试用例。在三角形计算中，要求三角形的三个边长：A

B

C。1、当三边不可能构成三角形时提示错误，可构成角形时计算三角形周长。

2、若是等腰三角形打印“等腰三角形”，若两个等腰的平方和等于第三边平方和，则打印“等腰直角三

角形”。

3、若是等边三角形，则打印：“等边三角形”。4、画出程序流程图并设计一个测试用例。

需求分析实例有效等价类：

输入3个正整数或正小数：两数之和大于第三数，如A<B+C；B<C+A；C<A+B两数之和不大于第三数两数相等，如A=B或B=C或C=A三数相等，如A=B=C三数不相等，如A！=B，B！=C，C！=A无效等价类：空负整数非数字

少于三个数梳理需求

在掌控了软件项目的背景，了解了产品的质量要求和软件测试的基本需求之后，同时，测试人员也会阅读相关软件需求文档，参与需求评审。在这些基础之上，可以进行测试的需求分析，即包括下面这些工作：明确测试范围，了解哪些功能点要测试、哪些功能点不需要测试；知道哪些测试目标优先级高、哪些目标优先级低；要完成哪些相应的测试任务才能确保目标的实现。用例的设计与评审1、要参与需求评审，评审需求的过程实际也是熟悉业务需求的过程。只有对业务比较熟悉了，才能更好的，更充分的设计出高质量的测试用例。2、要多阅读文档，其中包括产品策划书、规格说明书、需求文档，接口文档等，我们可以收集一切相关的文档来帮助理解所要测试的产品需要完成的目标。3、尽量多参加项目组内的会议。比如需求讨论、设计讨论、计划讨论等会议，这样在讨论过程中也能加深对产品的理解。4、要善于沟通，多和开发、PM进行沟通。遇到不明确的问题、有疑问的需求，可以咨询项目负责人或者客户等。这样才能提前解决需求理解偏差等。5、测试用例名称，也叫测试用例标题，一定要写得简洁、明了，需要用概括的语言描述该用例的出发点和关注点，使得测试人员第一眼看到测试用例名称就能够明白测试用例的目的。用例名称中一般要求不能存在假设性的语句，并且原则上每个用例的名称不能重复。用例的设计与评审6、预置条件要明确，包括测试环境、测试数据、测试场景。因为许多BUG只有在特定的环境、特定的场景下才可以重现。没有正确的前提条件，就无法进行后面的测试步骤或无法得到预期的结果。7、测试步骤描述要简单、清晰，并且要清楚每一个步骤的描述，我们平常的鼠标和键盘的每一动作都代表一个操作步骤。比如：第一步，输入用户姓名；第二步，输入登录密码；第三步，用户点击登录。步骤写的明确时就利于提高用例的可操作性。8、用例的预期结果要完整而且清晰，并且要将各个输出的结果写出来，包括：返回值的内容、数据库相关字段的记录、界面的响应结果、输出结果的规则符合度、日志的检查和对其它业务影响的检查。9、测试用例级别要划分清楚，这样在测试执行时有主次之分。

总是有些缺陷的出现是出乎我们意料的，或者说是已有的测试需求和测试用例未能覆盖的。那么，对于这部分缺陷，也应当添加到测试需求中，并设计相应的测试用例，以便于下次版本迭代时进行参考用例的设计与评审10、测试用例的划分也要单一，一个测试用例只检查功能点的一种情况。一个用例检查的情况太多，会导致用例的目的不明确。而且这样组织用例，有利于需求覆盖率的统计。一个功能点我们测试了哪些情况，以及哪些功能点我们在重点测试，一目了然。11、评审用例很关键，因为经过测试用例的评审可以发现：用例设计的结构安排是否清晰、合理；是否覆盖所有的需求功能点；是否存在冗余的用例；是否具有很好的可执行性；是否存在对需求理解上的差异等。评审需要项目经理、需求分析人员、架构设计人员、开发人员和测试人员都参与，也需要客户方的开发人员和测试人员。12、召开测试用例评审会议，在会议上大家可以提问互答，对模糊不清的地方可以进行讨论。这样可以站在不同的角度，站在很多人的思维和思考方式下设计用例。用例的设计与评审13、站在用户的角度来设计用例，以用户的使用逻辑及操作习惯为出发点，从用户实际可能的操作场景考虑，一定要脱离系统提供功能。14、测试用例需要不断更新和维护，不要认为测试用例的设计是一个阶段，测试用例的设计也需要迭代，在软件开发的不同的阶段都要回来重新审视和完善测试用例。并且需要在测试执行时利用发散思维不断的构造和完善测试用例测试执行在固定的时间内，尽可能全面地执行测试用例。1.在测试过程中不断的添加遗漏的用例，一定要在发现时及时补充，有些用例是无意间操作发现的；2.详细标识每一个被执行过的用例。问题回归

测试过程中，遇到过一个小小的参数变动可能引起一个比较远的功能点的大bug，开发不知道，测试不清晰，势必引发遗漏。在修改bug的这种情况下，有可能是牵一发而动全身的，是非常危险的。如果研发考虑的不周全，只修改了此bug，并没有考虑到与它接口的功能，那将会引发更多的bug。发布前的功能回归首先保证所有修改的bug验证通过，并且没有引起别的bug；在测试的过程中，最好自己编写checklist表，这样到