mur*_*att 26
在编写代码时,您可以执行单元测试.这个测试是测试你的视图应该如何工作(在类/方法/算法的层面上),它在开发时支持你,因为你可以在进行更改之前和之后运行测试,看看事情仍然是根据测试你有到位.将此视为可以帮助程序员工作的东西.此外,测试还将提供一种方法来查看某些内容应该如何适用于任何查看代码的人.TDD(测试驱动开发)并没有改变这个概念,而是强调一个编码需要首先考虑它应该如何工作以及期望什么.
如果没有看到自己的问题,可以尝试配对编程,代码审查或其他方式来查看具有更多眼睛和大脑的事物.我仍然坚信单元测试是程序员的工具而不是其他任何人所做的事情.
进行其他类型的测试,如集成测试,功能测试甚至(系统)性能测试,让其他人这样做可能会很好.特别是如果您想要自动执行此测试,则需要您了解如何执行操作,并且可能需要更高级别的业务知识来测试测试内容和方式.
您的问题的答案还取决于文化以及您的组织如何运作,但是,我相信您在所有情况下都希望将单元测试作为开发代码的一部分.如果这会导致问题,那么组织中可能会出现其他问题或需要查看的内容.
更新
以下是我在组织中看到的一些影响单元测试实践的事情:
如果有单位测试的协议,上述事情可能是需要处理的问题,以便使组织进入一个事物刚刚自然解决的状态.如果您的人员拥有良好的单元测试实践和经验,那么让他们带领团队其他成员看到单元测试的神奇之处.
就个人而言,我相信如果人们看到单元测试的好处,可以编写好的单元测试,使用构建自动化它们,如果团队可以自己决定如何组织如何编写单元测试,那么它们将自然地落到实处.该开发人员编写单元测试而开发的代码,任何人都可以在任何时候添加更多的单元测试,因为他们正在寻找的任何代码.如果有测试人员,他们将专注于其他类型的测试,如功能测试或探索性测试.
Stu*_*ser 14
这个问题将邀请许多不同的答案,一些基于组织的工作方式,一些基于规划和测试的资格.有许多不同的方法来组织测试,特别是因为组织规模不同,可能有也可能没有资源来雇用不同的团队.
有不同类型的测试:
根据我的经验:
单元测试(孤立的功能原子,例如单个控制器动作)和 集成测试(那些一起工作的原子,例如使用域层对象的控制器,使用数据层对象的域层对象),应该通过该开发商.
功能测试(系统功能作为规范状态)应由单独的QA团队完成.
非功能测试可以由QA团队或架构师/技术负责人完成.
UAT(系统适合用途)应由客户完成.
这背后的原因是,由于自动化单元和集成测试是白盒(您可以在应用程序内部看到例如代码),它们需要由开发人员完成(不一定是负责测试代码的开发人员).
功能测试和UAT是黑盒子(您无法在应用程序内部看到)因此更有可能由非技术人员完成,但在测试分析方面非常熟练.
非功能性测试可以是黑色或白色盒子,具体取决于测试内容和整体策略.
重要的是要注意通过测试另一个人的工作而不是测试你自己的工作来发现更多的缺陷.测试人员会以不同的方式思考,因此寻找/尝试在开发过程中不会考虑的事情,人们自然会保护他们的代码(无论多么难以实现客观).
如果没有单独的测试团队,那么让开发人员测试彼此的代码是件好事.
为了回答你的问题,当我是一名测试人员时,我负责测试分析(决定测试规范需要哪些功能测试),编写测试脚本并手动执行测试.一旦编写了这些脚本,任何测试人员都可以执行它们,但重要的是测试分析是针对开发人员在应用程序上的工作单独完成的.
使用TDD,开发单元(读取程序员或对)应编写测试.
TDD(测试驱动开发) - 单元测试通常处于技术水平.开发单位应该在实施课程时编写.如果其他人编写测试,您可能遇到的问题是外力会影响设计.当开发人员进行设计时,TDD运行良好.
使用BDD/ATDD时,应该参与QA/PO.
BDD(行为驱动开发)和ATDD(验收测试驱动开发)测试通常以较低的粒度级别编写.更好的测试是在考虑利益相关者的情况下编写的.因此,更好的人写这些是QA(质量保证),PO(产品所有者)或BA(业务分析师).这并不是说开发人员不能写它们你只需要进入这个角色.
成对工作的美妙之处在于,如果您的对编写测试,则在编写测试时会对测试进行自动完整性检查.
| 归档时间： |
|
| 查看次数： |
15107 次 |
| 最近记录： |