软件测试之ATM 模拟项目完成后的感想

软件测试之ATM 模拟项目完成后的感想  软件测试工具

在这个项目结束后，确切的说，在整个项目的实施过程中，我的感想就随着现场的气氛开始逐步溢出。整个学习过程应该分为5个部分：

  一.老师给我们讲解“大学体育寻呼项目”的设计概要、用例规约等文档。这个部分整整占用了将近一天的课时。我们真的全都明白了吗？说实话，答案应该是否定的。为什么没有人站出来提问呢？别人的想法我不清楚，但是就我自己而言，感觉无从问起，多少有点云里雾里。抱着可以“边实践边学习”的想法，我也就把原本含糊的问题放在了心里的深处……
 
  二.开始写“ATM取款机项目”的设计文档。从这里开始，我个人的想法必须容入到团队中去。也就是说，任何的问题都将是我们团队的问题。可是，我现在想想，那个时候还是犯了致命的错误。那就是，我们写这个设计，到底是按照我们所感性认识的“ATM”为基准，还是以“模拟ATM程序”为基准。在项目开始时，我和组员做过关于这个问题的讨论。但是让我不明白的是，我偷偷的观察了一下别的组，他们居然已经开始飞速敲击起键盘，而我们整整为了“如何开始写”这个问题耽误了大半个小时。这时，我的个人心态开始有所浮躁，但是最终还是很快自我平息了。由于我把老师参作为“上级”，我很快和组员商量猜测“上级”的项目用意，决定以“模拟ATM程序”为基准，在“插卡”、“取款”、“查询”和“打印”这几个最主要功能上下手，不要偏离主线。最终证明，这个猜测在写“设计概要”这个阶段是错误的。现在已经深刻明白了什么叫“设计概要”。。还不算晚。

  三.然后是和别的小组交换“设计文档”写测试用例。这个时候我发现教室里的吵闹声开始多了起来。老师也开始暗暗的笑。不过让我感到欣慰的是，至少在写“设计概要”时所做的错误判断是有利于写“测试用例”和“执行测试”的。因为我一开始就认为，任何项目都不应该脱离测试的主线。

  四.紧接着是再交换回来执行测试用例。这个阶段教室里的吵闹声到了沸腾的顶点。因为有同学一开始没有确立“基准”，导致了很多问题的发生。然而这个时候我们组却显得有些被孤立。因为我们这个步骤执行的太快了，几乎没有阻碍（因为全是阻碍）。这个问题也是因为，和我们交换的小组，其“设计概要”的基准和我们的不同，直接造成多数用例不用去执行了，因为无法执行了。。

  五.“上级”点评阶段。我写这个感想的时候，还没有实行到这个阶段。但是我想先一步自我检讨，或者说做个总结。以上的感想问题就不多说了，说几点项目实施中的技术问题。这些问题是我们组最后总结出来的问题，别的组如果没有，最好，说明比我们强；但如果有，请原谅我的冲动，先“汇报上级”！
 
  问题：
    1. 关于“后置条件”的详细定义。因为这个问题导致原本可以写对的测试用例写错了。希望老师指导。
    2. “用例规约”和“测试用例”中关于某个功能点的描述混淆。我下载了其他小组的项目文件，发现有的组写了一个“小键盘”的用例规约，其中关于步骤和功能的描述感觉很象“测试用例”。我们小组在开始实行的过程中也同样遇到类似问题。老师教育我们：“测试是注重细节的”，那么就在此再一次请教关于这两种文档在细节上该如何区分，以便撰写。或许我的这个描述很含糊，因为我们本身就没有清晰的思路去把它分析出来，就象我在先前写到“第一节课云里雾里，却无从提问。”的那样。
    3. 还是细节问题。或许由于我们项目经验浅（这个在老师眼里可能是借口），无法在执行测试后准确使用术语“通过、忽略、阻塞、警告、失败”。希望能够举例说明。再次谢过！！
    4.还有没有想到的其他问题……

  最后还是要谢谢老师和各位同学。。
  我们通过这个项目的演练，最终明白了老师的用意：“在整个项目过程中，设计概要的好坏将在以后的测试用例撰写和测试执行中起到主导和决定作用。” 所以，这次的失败将激励我们真正地开始走向测试。

  （如有白字，尽请谅解！！^_^）

以下是其他同学的回帖：

03班学员李孟佳：

做的太久了，都忘了当时我们是怎么过来的了。写一下我的理解好了，仅供参考。
1.后置条件就是这个用例以后要做的事，其实有一个流程图就好了。
2.“用例规约”是写给项目开发看的，告诉他们怎么设计程序。
“测试用例”是写给测试执行人员看的，也可以从“用例规约”上拿些东西过来，因为它和测试需求很像了，“用例规约”写的越详细，“测试用例”就越好写。
3.我们基本只用通过、失败和警告（最爱用这个），忽略是bug很轻微时用，阻塞是当前置的测试用例失败时使用。
4.把真实的ATM和模拟的ATM合起来有什么问题？程序虽然是模拟的，但是判断对错却是以真实的情况为准。
5.LZ说出了我们的心声，问题不是没有，就是没有办法问出来。

09班学员钱喆：

我们也是，其实我觉得在飞速动键盘之前还是多做分析思考，有的学员太急于动手，什么都不考虑，喜欢在边做中思考问题，这样就和瀑布模型类似了，结果就是不停的返工前面的内容还容易漏掉。有时候每个模块我们都制定的和老师的意见一致，就是模块内的内容一直不能够很明确清楚的整理出来，发现做组长事还真不少 
当老师一布置好任务，组员就会催促组长分工，要在短时间内了解业务流程及正确平均的分工，处理模块细节还真不是那么简单的。毕竟大家都刚起步，应该说水平差不多，很难统一思想，各抒己见的事常有发生

原文转自：http://www.ltesting.net