第二篇日志

  今天已经写了一篇日志，但是发现太过于潦草了，就撤下了。感觉自己应该写点什么的，但是这个不是我所擅长的，不知道言些什么，就随便说说吧，因此便有了这个“第二篇日志”。

  我毕业后就开始做软件测试，到现在也有几年了，但是感觉测试技术一直停留在某个阶段而难以突破。其实也不是自己不想提升只是感觉找不到那种感觉了。没有再遇到那种可以让自己专注的，可以痛痛快快的把整个软件测试一通的项目了。在现在的项目中，测试更多地处于一个可有可无的尴尬境地。

  不能总是说些丧气的话，我或许应该看到的是，测试其实是有很多事情可以去做的，只是不知道怎么去推广罢了。测试工程师对整个系统的业务特性是最了解的人，他不仅明白整个业务的所有特性，对整个系统的运行，他也是最了解的。那么这里面是有些事情可以做的。下面就说一些我在测试过程中遇到的一些问题，希望有朋友给些建议，也欢迎讨论。

1. 项目没有需求说明书，有的只是一个标准，以什么为参考写测试用例？
//我的做法：先熟悉标准，写一个功能清单，然后和项目经理确认要实现什么功能，什么功能不实现，确认完成后，就以此开展后续的工作
//问题：熟悉标准相当费时间，写功能清单也耗时，导致进度非常紧张

2. 项目的需求经常在变，等到测试执行时，才发现写的测试用例已经不适用了？
//我的做法：和项目经理沟通，需求变更要通知测试人员
//问题：项目经理毕竟不写代码，开发人员写代码的过程中发现实现有问题了，自己就修改了，很多时候都是口头讨论后就改了，根本就忘记了还要通知测试人员

3. 什么样的测试用例才算好用例？写详细和准确一点，但是预期结果却是一个未知数。
//这个问题很头疼，很多情况下，测试用例是需要开发人员做出原型来了，才知道测试步骤和预期结果怎么写

今天就暂时写这三点，后续再补充。写得太乱了，请大家不要见笑哈。