软件测试从零开始

在昨天的文章中，谈了关于测试前准备和测试需求分析阶段的注意点，今天继续我们昨天的话题。另外关于这两个阶段还可以看看我公众号里的两篇文章《如何跟开发就测试范围进行沟通？ 》《如何学习？》

3、测试用例设计 测试需求收集完毕后，开始测试设计。测试用例是什么？测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。设计测试用例需要考虑以下问题： 3.1 测试用例的基本格式

多数公司都有自己的用例模板，作为新手前期先理解公司的用例模板即可。

有的公司模板规定的非常细致，也有的公司模板字段非常简单，这一般是跟公司所面临的现状有关。有能力的话可以尝试对模板进行优化——建议阅读这篇文章《如何使用测试文档》。

在我的QQ群（169974486）文件有一个PPT《测试用例&BUG描述》，里面有几个范例可以参考一下。

3.2 复用测试用例

现在很多软件公司都有意识建立自己的组织资产库（若没有你可以建议创建，一般老总都会同意的），在资产库里会有公司做过的项目的资料。在进行测试用例设计时，可以找一找其他项目中是否有可以复用的用例，特别是相同业务类型和相同软件结构项目的测试用例，会有很大的借鉴意义，甚至经过对测试用例简单修改就可以应用到当前被测试的软件。 “ 拿来主义 ” 可以极大的开阔测试用例设计思路，也可以节省大量的测试用例设计时间。

除此之外，建议自己整理一些常见功能的测试用例库（如登录）、测试点，比如， WEB 软件系统在系统测试过程中，会有一系列的范式，比如针对接口就会有很多测试点。在设计测试用例的时候，不妨到网上去搜索相关的测试点，然后，在设计测试用例的时候不断的去完善它，以作为下次测试用例设计的基础。

我的群空间文件里有我整理的《黑盒测试框架》，可以作为参考。 3.3 加强测试用例的评审

参加用例评审可以迅速发现自己思维方式和文档编写上存在的不足，并快速的成长。文档评审有很多需要注意的地方，不过今天本文不做细述，如有需要加我微信聊吧（shalayang）。

这几天我会准备课件，到时候在群视频中探讨。 3.4 定义测试用例的执行顺序

如何将测试用例跟版本迭代相结合，是让很多人包括资深测试人员苦恼的事情。

比较好区分的有如会导致服务器不稳定（或重启）的，这部分用例放在最后；或者测试进度紧张的情况下，把低优先级、耗时较多的用例进行裁剪......

不过更多的时候，我们的苦恼在于测试进度紧张，我们即使加班也难以完成工作，或者时间虽然相对宽裕，但某些用例看起来并没有必要一遍遍执行......在我带团队的时候，这类问题都是我负责决定，不会让测试工程师为这些事烦恼，所以作为新手，或许你可以在面临这类问题时跟领导进行沟通。这类问题的一般处理原则是根据重要程序分优先级，做测试任务裁剪。对我来说，可以接受下属十件工作完成8件（每件工作完成100%），但不能接受每一件都做，却都只完成80%。

另外，测试新手还会有一个困惑：当测试进度紧张时，是否可以抛开用例进行测试？对此我从测试管理角度说说我的看法。

如果测试的项目是一个不那么重要，或者业务逻辑比较简单的项目，而当我对测试负责人很熟悉，清楚他做事的态度和工作能力，那可以在这种时候抛开用例进行测试，以保证项目按时上线为主。

如果项目逻辑复杂或很重要，上线以后一旦出现问题非常严重，这个时候必须保证按照用例执行。如果项目经理以项目上线为理由来施压，那我们就以数据回答，告诉他以现在的人力资源，做了哪些事情，没做哪些测试，没做的测试可能带来哪些风险，让他自己决定是否一定要上线（他们一般会找高层或客户再次沟通）。如果是，那么上线后出现问题由他承担主要责任——这里顺便说一句，我坚持认为测试人员不应把自己当作“守门员”，我们在公司中应努力营造服务文化，而非“控制文化”。

4、测试用例执行 测试用例设计完毕后，接下来的工作是测试执行，测试执行中应该注意以下几个问题： 4.1 搭建软件测试环境，执行测试用例 全方位的观察测试用例执行结果： 测试执行过程中，当测试的实际输出结果与测试用例中的预期输出结果一致的时候，是否可以认为测试用例执行成功了呢？答案是否定的，即便实际测试结果与测试的预期结果一致，也要查看软件产品的操作日志、系统运行日志和系统资源使用情况，来判断测试用例是否执行成功了。全方位观察软件产品的输出可以发现很多隐蔽的问题。以前，我在测试嵌入式系统软件的时候，执行某测试用例后，测试用例的实际输出与预期输出完全一致，不过在查询 CPU 占用率地时候，发现 CPU 占用率高达 90 ％，后来经过分析，软件运行的时候启动了若干个 1ms 的定时器，大量的消耗的 CPU 资源，后来通过把定时器调整到 10ms ， CPU 的占用率降为 7 ％。如果观察点单一，这个严重消耗资源的问题就无从发现了。 加强测试过程记录：测试执行过程中，一定要加强测试过程记录。如果测试执行步骤与测试用例中描述的有差异，一定要记录下来，作为日后更新测试用例的依据；如果软件产品提供了日志功能，比如有软件运行日志、用户操作日志，一定在每个测试用例执行后记录相关的日志文件，作为测试过程记录，一旦日后发现问题，开发人员可以通过这些测试记录方便的定位问题。而不用测试人员重新搭建测试环境，为开发人员重现问题。 及时确认发现的问题：测试执行过程中，如果确认发现了软件的缺陷，那么可以毫不犹豫的提交问题报告单。如果发现了可疑问题，又无法定位是否为软件缺陷，那么一定要保留现场，然后知会相关开发人员到现场定位问题。如果开发人员在短时间内可以确认是否为软件缺陷，我们可以给予配合；如果开发人员定位问题需要花费很长的时间，我们就没必要因此耽误自己宝贵的测试执行时间，可以让开发人员记录重现问题的测试环境配置，然后，回到自己的开发环境上重现问题，继续定位问题。 与开发人员良好的沟通：测试执行过程中，当你提交了问题报告单，可能被开发人员无情驳回，拒绝修改。这时候，只能对开发人员晓之以理，做到有理、有据，有说服力。首先，要定义软件缺陷的标准原则，这个原则应该是开发人员和测试人员都认可的，如果没有共同认可的原则，那么开发人员与测试人员对问题的争执就不可避免了。很多时候开发并不是不认可我们提交的问题，而是因为项目上线时间在压着（他们的口头禅：我们改不完），我们提交的bug在他们看来并不影响使用（他们也认可确实是有问题），那么我们可以从客户角度来跟他们晓之以情动之以理，若还不行，请测试经理去沟通。 及时更新测试用例 ：测试执行过程中，应该注意及时更新测试用例。往往在测试执行过程中，才发现遗漏了一些测试用例，这时候应该及时的补充；往往也会发现有些测试用例在具体的执行过程中根本无法操作，这时候应该删除这部分用例；也会发现若干个冗余的测试用例完全可以由某一个测试用例替代，那么删除冗余的测试用例。 　　 总之，测试执行的过程中及时地更新测试用例是很好的习惯。不要打算在测试执行结束后，统一更新测试用例，如果这样，往往会遗漏很多本应该更新的测试用例。

4.2 学会安排自己的时间

要时刻认识到我们是不可能发现全部缺陷的。因为若要发现全部的程序错误，我们必须要检查所有可能有问题的地方，要在所有可能发生的不同条件下观察这些地方，还需要一种十分可靠的方法，当所有类型的程序错误发生时，都能够识别出来！如果测试员认为自己能够做到这些，那么要么是产品非常简单，要么测试员的想象力太差。

认识并承认自己不能做所有的事，并学习如何分配自己的时间。网上现在可以很方便的搜到一些时间安排的书籍，多看看。

4.3 当心“完备的”的测试

有一些测试员承认自己不知道是否发现了产品中的全部问题，但仍然不准确的讨论结束测试的含义。我们常常听到这样一句话：“对这个产品我需要测试5天”这句话可以理解为，你在五天内对产品进行完备的测试，也可以理解为你会在五天内发现所有问题，这显然不可能的。

“完备性”测试常常是隐含地表达出来的，而不是明说出来的。不管是哪种情况，我们都很有必要小心的对待这个概念。

“完备的测试”都有哪些含义呢？比如说：

• 完全发现了产品中每个问题
• 完全检查了产品的每个部分
• 完成了自认为是有用和经济的测试
• 尽自己所能，完全达到了项目团队制定的目标
• 完成了约定的测试
• 完成了在一定条件下人所能够测试的所有内容
• 完成了自己知道如何测试的全部内容
• 完成了自己所承担的测试部分，不考虑其他人的工作
• 完成了对产品很广、但是不深的测试
• 完成了对产品的一种测试
• 用完了分配给的测试的时间

在沟通测试周期时，特别需要注意措辞，不要有“完备”、“完成”、“结束”等含义，即让团队其他成员不产生误解，也可以在出现一些意外时让自己有辩解的余地。

请注意，“完备”的定义并不是在项目一开始就能够最终确定的，随着测试项目的进展，随着新测试任务的突然出现，需要重新考虑。

我的做法是让项目干系人详细了解测试过程，告诉他们这次任务要完成那些测试，为什么值得实施这些测试，并告诉他们自己没有做的其他值得的测试，以及为什么没有做这些测试。

4.4 重视自己最初的“困惑”

刚接到一个项目，我们会有很多困惑，甚至也说不清楚自己到底哪里不清楚。不过不要紧，这个时候你是有很大优势的。

资深的测试人员都知道，在一个项目待久了，会慢慢的发现自己提不出问题了——所以有经验的测试经理都会有意识的定期让测试人员调换项目或者安排对子测试。

所以，重视你最初的困惑，而且你可以换个角度来看待它。比如规格说明书不清楚——说明书中模糊的地方，也许意味着开发自己也不清楚逻辑，或者存在争议——再比如产品不清楚：产品这个模块可能设计上太复杂，也意味着用户也很可能会产生疑惑。

也许还有更重要的，就是当时明白自己在困惑时，你可以提出也许其他人没有勇气提出的问题。

4.5 提交一份优秀的问题报告单 参考我的PPT《测试用例&BUG描述》中关于bug的报告方式。

（未完待续......）