软件测试:软件外包项目测试(测试执行篇)

 　经过5个月的努力，我们和****大型国企（亚洲最赚钱的公司）软件系统的第三方测试终于告一个段落。本次测试由于整个团队的不懈努力，赢得了客户很高的满意度。

　　本次测试中我们经历前期的洽谈项目、设计方案、熟悉需求、更新方案、测试计划、测试用例设计、以及测试执行、回归测试、测试总结等阶段。本次要和大家交流的是：其中的一个阶段即测试执行阶段，测试执行阶段我们是如何度过的。有关软件测试的其他方面以后有时间再与大家分享。

　　前置条件：《***_TP_测试计划》,《***_TC_测试用例》

　　实施步骤：

　　步骤1：测试开始前一周向用户方、开发方、测试方输出测试期间的总体执行计划，本执行计划依据前期书写的《***_TP_测试计划》,《***_TC_测试用例》。执行计划是对《***_TP_测试计划》的进一步细化，包含的内容有两个大的方面：第一根据《***_TC_测试用例》安排测试时间；第二更新《***_TC_测试用例》和补充探索性测试用例。

　　步骤2：用户方、开发方、测试方填写《现场测试环境配置单》。该表单是在测试开始时，确认现场的软硬件环境，尤其要关注的软件的当前版本，以及服务器密码等信息。当三方都确认环境后，现在对于软件和硬件都形成一个基线。如有对环境进行改动都必须要三方确认后，才能实施改动。

　　步骤3：进行冒烟测试，输出《***_TR_冒烟测试》。冒烟测试报告应该包括冒烟测试环境配置、冒烟测试所用到的测试用例以及执行后测试用例的软件日志。冒烟测试的环境配置采用最典型的配置；冒烟测试的用例应该是《***_TC_测试用例》中挑选出来的，一般在50个左右，用来测试软件基本功能是否实现；执行测试用例后的软件日志在这里的目的主要是证明用例确实是执行过了。如果冒烟测试通过，在冒烟测试报告中最好一个bug别出现。

　　步骤4：第一天结束后，输出《***_TD_测试日报》。该日报主要描述下面几个方面的内容:

　　(1)当日工作成果。

　　比如可以这样写

　　任务

　　等格式。

　　(2)明日工作安排

　　(3)测试状态统计

　　主要统计当日测试用例的执行情况

　　例如

　　(4)发现的缺陷的数量以及严重程度

　　你需要说明当日新增Bug是多少，以及这些严重程度分布情况是怎么样的？以及大体描述发现的缺陷

　　整体来说日报比较突出数据。因为给领导看，领导比较关注的是测试的数据。当然这样做也利于我们后期数据统计。

　　步骤5：如果冒烟测试能够通过，然后锁定软件版本进行正式测试。

　　步骤6：正式测试开始后，有关测试进度主要依据测试前提交给用户的测试执行计划。而上面描述的《***_TD_测试日报》。是对测试执行计划以及测试成果的进一步细化。有关进度有一个比较关键的地方，如果开始测试比较顺利，能够很快的完成任务，那么就尽量的赶进度。因为测试到后面不知道会出什么事情，再说到测试后期，"人困马乏"测试效果肯定也没有前期好。

　　步骤7：具体测试过程中应该注意

　　1.有关用例。每个执行完的用例必须都要有所测软件日志。有两个用意：第一：让用户知道你确实是执行了用例；第二：如果发现问题，有利于开发人员定位Bug。

　　2.有关缺陷报告。每个缺陷报告一定要"图文并茂"。为了让开发人员尽快地重现Bug，测试人员尽量使用最少的步骤重现问题。但有的时候使用语言描述不清楚，可以使用抓图工具抓到发现问题时的图形，把图形抓下来固然好，有可能你抓的图里面有好多层叠窗口，但如果你不指明到底是哪个图发现了Bug，以及什么问题，那么开发也可能看的一头雾水。

　　步骤8：探索性测试。当我们写的用例，在测试执行的过程中没有发现问题。我们该怎么办呢？比如我们安排1天测试40个用例，执行完了却发现没有1个bug。这个时候我们是赶进度继续执行明天要执行用例还是做些其他的工作。如果开始正式测试前发现的问题太少，这个是很不正常的现象。用户也很容易怀疑我们测试的技术。这个时候一定要想方设法的发现一些比较严重性问题。所以我们要作探索性测试。如果探索性测试如果发现bug,我们要补充相应的用例以及要写缺陷bug。当然做探索性测试肯定要付出额外的时间，但这样做还是值得的。

　　步骤9：以后每天测试都是根据测试日报时分配的任务进行测试，如果用例有问题，我们更新用例。如果有额外的时间我们进行探索性测试。然后我们补充探索性测试用例和缺陷报告。然后再写日报直到测试结束写阶段性的测试总结。

　　预期结果:

　　步骤1：输出格式良好的且三方确认的《执行计划》

　　步骤2：输出格式良好的且三方确认的《现场测试环境配置单》

　　步骤3：输出格式良好的《***_TR_冒烟测试》

　　步骤4：输出格式良好的《***_TD_测试日报》

　　步骤8：输出格式良好的《探索性测试用例》《更新用例跟踪表》